feat(protocol): add solver support for l2 to l1 eth bridging #18805
Conversation
Co-authored-by: xiaodino <[email protected]>
Co-authored-by: xiaodino <[email protected]> Co-authored-by: Daniel Wang <[email protected]> Co-authored-by: dantaik <[email protected]>
Co-authored-by: xiaodino <[email protected]>
packages/protocol/contracts/shared/bridge/EtherBridgeWrapper.sol
Outdated
Show resolved
Hide resolved
packages/protocol/contracts/shared/bridge/EtherBridgeWrapper.sol
Outdated
Show resolved
Hide resolved
packages/protocol/contracts/shared/bridge/EtherBridgeWrapper.sol
Outdated
Show resolved
Hide resolved
packages/protocol/contracts/shared/bridge/EtherBridgeWrapper.sol
Outdated
Show resolved
Hide resolved
packages/protocol/contracts/shared/bridge/EtherBridgeWrapper.sol
Outdated
Show resolved
Hide resolved
|
Solver logic for eth has been merged into |
| ctoken_ = _ctoken; | ||
| // Following the "transfer and burn" pattern, as used by USDC | ||
| if (_op.token == address(0)) { | ||
| balanceChangeAmount_ = _op.amount; |
There was a problem hiding this comment.
I think we should init ctoken_'s chainId, and inside onMessageInvocation, we should still check if _ctoken.chainId == block.chainid is true for Ether transfer...
There was a problem hiding this comment.
May I know what purpose this may serve for Ether? In the case of ERC20, I see this is required to choose between transferring a token if it is canonical or minting it if it is bridged.
There was a problem hiding this comment.
The difference between Ether and ECR20 tokens is the address being 0 or not. But since we have checked _ctoken.chainId for ERC20 tokens, we shall do the same for Ether. Otherwise, _ctoken.chainId == block.chainid check shall also be removed for ERC20, but I think that will not be OK.
|
@dantaik @cyberhorsey Would you mind managing the conflicts here? I am not sure where did these turn up from |
|
@AnshuJalan I helped you with the conflicts, but please double check if some of your changes are deleted by mistake :D |
This is an extension of #18616 for L2 -> L1 FnS ETH bridging.
Bridge.sol. Thus, the Bridge contract itself acts as the “ether vault”.Bridge.solto incorporate a solver condition, but that would fundamentally change the core of the message passing system. Therefore, a better alternative implemented in this PR is a separateEtherBridgeWrapper.solthat handles just the “Eth in” and “Eth out” part of bridging by including a solver condition, leaving the existing functionality ofBridge.soland surrounding infra untouched.Bridge.solcan still be used for standard slow withdrawals.