search

ensdomains / evmgateway

This repository implements a generic CCIP-Read gateway for fetching state proofs of data on other EVM chains. The intended use is for contracts on L1 to be able to fetch and verify data from contracts on L2 in a read context.
MIT License
128 stars 28 forks source link

[WIP] OP Fault Proof Dispute Game implementation for op-verifier and op-gateway #36

Open Chomtana opened 5 months ago

Chomtana commented 5 months ago

On March 19, 2024, Optimism initiated a significant upgrade on the Optimism Sepolia network to introduce a fault-proof system. Unfortunately, this upgrade broke the functionality of the op-verifier and op-gateway components of the ENS EVM Gateway. Below is an overview of the upgrade's key points.

The L2OutputOracle is being entirely removed and replaced by the OptimismPortal and DisputeGameFactory. The L2OutputOracle smart contract is currently used by the trusted Proposer role to store L2 state output proposals. Presently, developers use these outputs to prove that their withdrawals actually happened on L2. But with fault proofs, developers will have to change how their client software proves withdrawals in the first step of the two-step withdrawal process.

Reference: https://docs.optimism.io/builders/notices/fp-changes#overview-of-changes

You can see proof on Etherscan that L2OutputOracle has ceased on Optimism Sepolia: https://sepolia.etherscan.io/address/0x90E9c4f8a994a250F6aEfd61CAFb4F2e895D458F

Despite the lack of documentation on upgrading from L2OutputOracle to DisputeGameFactory, we have reverse-engineered the Optimism code and implemented the necessary upgrades to the op-verifier and op-gateway in this pull request. Here is a summary of the changes introduced:

L2OutputOracle DisputeGameFactory
l2OutputIndex disputeGameIndex
getL2Output(...) gameAtIndex(...)
outputRoot gameProxy.rootClaim().raw()
latestOutputIndex() gameCount() + findLatestGames(...)
outputProposal.l2BlockNumber disputeGame.l2BlockNumber()

To facilitate a smooth transition, it's crucial to incorporate an activation point system into the op-verifier smart contract. Moreover, to ensure our gateway remains adaptable to future updates, the op-verifier contract should be designed with an upgradeable pattern. However, it's been observed that the EVM Gateway is intended to be immutable, leading us to forego these enhancements for the EVM Gateway. Should you be interested in exploring the implementation of an activation point or an upgradeable smart contract, please let us know.

We have already applied the upgradeable design pattern to all contracts within our Opti.Domains CCIP Gateway and plan to introduce an activation point to our Opti.Domains CCIP Gateway shortly. This approach will enable us to upgrade without disrupting the user experience.

The source code for Opti.Domains CCIP Gateway is available at: https://github.com/Opti-domains/optidomains-ccip-contracts

The Opti.Domains team is eager to continue contributing to developing and maintaining the Optimism verifier and gateway implementations.

The integration of the fault-proof system is scheduled to merge into the Optimism Mainnet in Q3 2024.

Note: This is a work in progress and is not fully tested.

Arachnid commented 5 months ago

Please let me know when this is ready for review again!

Chomtana commented 5 months ago

It should be ready to review. However, let's review this sub PR first: https://github.com/ensdomains/evmgateway/pull/37

Chomtana commented 4 months ago

Hi @Arachnid following #37 I have made a PR to ccip-read to patch REDACTED case that https://ccip-v2.ens.xyz is sending as a sender. It would be great if we can get this merged and published to the NPM registry so that ENS UI can work with this gateway implementation correctly.

Chomtana commented 4 months ago

I have pushed a temporary fix for Cloudflare "The script will never generate a response". It works with the official ENS UI after deploying this fix.

Screenshot 2567-04-11 at 00 24 44

This removes the use of the app global variables. Changing global variable to server will not resolve this issue; we need to completely avoid using global variables.

However, this is not a good fix. We need to think of a more elegant way.

Chomtana commented 4 months ago

Should I merge this PR: https://github.com/ensdomains/evmgateway/pull/34 before continuing the development?

Arachnid commented 4 months ago

That PR is now merged, so please go ahead.

Can you explain why you think the global variable is causing your issue with REDACTED? This seems to be purely a logging issue and not anything that affects the actual operation of the service.

Chomtana commented 4 months ago

As per my temporary fix, I have commented server global variable and rebuilt server instance on each request and it fix the issue.

Also this blog: https://zuplo.com/blog/2022/03/04/the-script-will-never-generate-a-response suggests a similar cause about the use of global variables.

Arachnid commented 4 months ago

This is strange, because app/server isn't a promise here, it's a lazily initialized variable. The longer-term solution, however, is likely to be optimizing imports so that we don't hit the startup time limit in the first place.

Chomtana commented 4 months ago

I'm assuming I should start over from the main branch and incorporate diff...

Arachnid commented 4 months ago

Yes please!

Chomtana commented 3 months ago

@Arachnid I have updated the implementation in #45