Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[lock/unlock] OP L1 finalization in bridge adapter #606

Merged
merged 9 commits into from
Mar 16, 2024

Conversation

makramkd
Copy link
Contributor

@makramkd makramkd commented Mar 13, 2024

Motivation

The Optimism L1 bridge adapter needs to be able to both prove withdrawals and finalize them on L1.

Solution

  • Add Optimism withdrawal proving and finalization on L1 functionality to the bridge adapter. Tweak the scripts to prove and finalize withdrawals through the adapters rather than on the Optimism contracts directly to prove that they work.
  • Fix a bug with ETH cross-chain transfers, on both L1 and L2 adapters: since Optimism transfers ETH rather than WETH cross-chain through their native bridge, stuff ends up reverting when we call withdraw on the WETH contract prior to bridging.
  • Fix a bug where we were using withdrawTo without actually sending the ETH along with the call. The Optimism contracts dependency we're using isn't bedrock so the withdrawTo function signature did not have payable. Instead we copy/paste the withdrawTo function signature directly from L2StandardBridge.sol, since we can't import it directly due to the exact 0.8.15 version specified in the contract's pragma.

Follow ups

  • Direct follow up: support multiple-stage finalization in Rebalancer.sol. Right now Rebalancer.sol assumes that a single successful call to finalizeWithdrawERC20 will give it access to funds, however this is not the case for Optimism. This will be implemented in an upcoming PR to keep diffs small and manageable.
  • Future work: Explore the differences between bridgeETHTo and bridgeERC20To, which are on StandardBridge.sol, vs. depositERC20To and withdrawTo which are on L1StandardBridge.sol and L2StandardBridge.sol respectively.
  • Future work: Use contracts-bedrock imports instead of plain contracts.

@smartcontractkit smartcontractkit deleted a comment from github-actions bot Mar 13, 2024
@smartcontractkit smartcontractkit deleted a comment from github-actions bot Mar 13, 2024
@makramkd makramkd marked this pull request as ready for review March 13, 2024 09:44
@makramkd makramkd requested review from RensR, matYang and a team as code owners March 13, 2024 09:44
@makramkd makramkd requested a review from dimkouv March 13, 2024 09:45
Copy link
Contributor

LCOV of commit f416505 during Solidity Foundry #2969

Summary coverage rate:
  lines......: 98.6% (935 of 948 lines)
  functions..: 95.1% (195 of 205 functions)
  branches...: 91.9% (364 of 396 branches)

Files changed coverage rate: n/a

@@ -45,7 +72,12 @@ contract OptimismL2BridgeAdapter is IBridgeAdapter {
// If the token is the wrapped native, we unwrap it and deposit native
if (localToken == address(i_wrappedNative)) {
i_wrappedNative.withdraw(amount);
i_L2Bridge.withdrawTo(Lib_PredeployAddresses.OVM_ETH, recipient, amount, 0, extraData);
// XXX: Lib_PredeployAddresses.OVM_ETH is actually 0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0000.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LMAO nice address

// This code path still works because the L2 bridge is hardcoded to handle this specific address.
// The better approach might be to use the bridgeEthTo function, which is on the StandardBridge
// abstract contract, inherited by both L1StandardBridge and L2StandardBridge.
// This is also marked as legacy, so it might mean that this will be deprecated soon.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

curious why not use bridgeEthTo if it's better supported?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm actually not sure what the difference is, it'd require a whole investigation. I should reach out to Optimism and ask them what's the dealio. I think changing this is better in another PR to keep this PR self-contained. The finalization process is the same either way.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sounds good, please do confirm with them, OP team is kinda known for not being the best with compatibility

core/scripts/ccip/rebalancer/opstack/finalize.go Outdated Show resolved Hide resolved
core/scripts/ccip/rebalancer/opstack/finalize.go Outdated Show resolved Hide resolved
tests encoding and if logic
Copy link
Contributor

LCOV of commit cf5e440 during Solidity Foundry #3012

Summary coverage rate:
  lines......: 98.6% (935 of 948 lines)
  functions..: 95.1% (195 of 205 functions)
  branches...: 91.9% (364 of 396 branches)

Files changed coverage rate: n/a

@smartcontractkit smartcontractkit deleted a comment from github-actions bot Mar 15, 2024
@smartcontractkit smartcontractkit deleted a comment from github-actions bot Mar 15, 2024
@smartcontractkit smartcontractkit deleted a comment from github-actions bot Mar 15, 2024
@makramkd makramkd merged commit b796fea into ccip-develop Mar 16, 2024
67 of 70 checks passed
@makramkd makramkd deleted the makram/CCIP-1438/opstack-l1-adapter branch March 16, 2024 06:27
makramkd added a commit that referenced this pull request Apr 24, 2024
#613)

## Motivation

PR #606 implements multi-stage finalization in the Optimism L1 bridge
adapter, however this is not functional end-to-end because the
Rebalancer assumes that finalization happens in a single step.

## Solution

Change the bridge adapter interface to return a boolean from
`finalizeWithdrawERC20` that indicates whether the funds are available
for use by the rebalancer.

The rest of the changes are to get test coverage for this new interface
change.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants