Conversation
|
|
||
| 2. Deposit and Withdraw native ETH into smart contracts by calling custom functions. | ||
| - This is required by liquidity bridges. (Stefan - proof?) | ||
| - Currently, we don't support it. (Stefan - or do we?) |
There was a problem hiding this comment.
We support it in practice, but its with 2 proofs and there is a security bug regarding anyone being able to call the withdrawal only and break the composition
There was a problem hiding this comment.
can you point me to the second proof?
There was a problem hiding this comment.
I meant it can be implemented; we havent done it for the cross chain messenger which is an oversight. I can quickly do the function if you wanna see how it looks
| 1. Deposit and Withdraw native ETH into EOA. | ||
|
|
||
| 2. Deposit and Withdraw native ETH into smart contracts by calling custom functions. | ||
| - This is required by liquidity bridges. (Stefan - proof?) |
There was a problem hiding this comment.
I gotta check the contracts they got, but the basic premise is they need to move the native eth they give out around chains and the only way to move it is through the native bridge; as i said those bridges are DAOs so they can't be sending to private keys and need to be able to call contracts and pay them to execute the settling and repay the bonder/relayer who has done the early transfer to the user
| The ``LogMessagePublished.payload`` contains the receiver and the amount. | ||
|
|
||
| Stefan | ||
| - why is this not authenticated No newline at end of file |
There was a problem hiding this comment.
The authentication only matters when you are calling payable functions:
receiver.call{value: amount}(calldata)
The value transfer even right now is not authenticated - it directly calls a receiver and gives the amount; There is no way for the receiver to ask who is the cross chain sender, which is fine if all you ever do is receiver.call{value:amount}("")
The authentication issue is when you want to know who is the msg.sender on the other network as the msg.sender on the receiving network is non reliable. As to why would one ever need that to be authenticated, can't think of an example when exactly this is going to be necessary, but if the call is composed through a messenger that info will be exposed through the crossChainSender() function.
There are some contracts that I've seen who revert in their receive() methods and only allow for payable calls with calldata, that might need such authentication
2 participants
Why this change is needed
Please provide a description and a link to the underlying ticket
What changes were made as part of this PR
Please provide a high level list of the changes made
PR checks pre-merging
Please indicate below by ticking the checkbox that you have read and performed the required
PR checks