Rebase changes on top of stable upstream

[palango]

We need to rebase (at least that's what we have been doing in the past) our changes on top of the latest upstream changes.

While doing so, I found big changes to contract deployment. This work was mostly done in ethereum-optimism#10106 and follow-ups.

Tasks

Preview Give feedback

1. Rebase op-geth, will fix Re-add temporarily removed incorrect tracing test op-geth#44
2. eth_estimateGas RPC method returns error for pending block op-geth#136
   type:bug +1
   
3. Rebase optimism #137
   +0
   

   

[lvpeschke]

Hard to predict and assess progress, reactive work commit by commit.

[lvpeschke]

@palango can you provide a status update? how much is left to do?

[palango]

@palango can you provide a status update? how much is left to do?

• The rebase itself is finished
• I pulled out the migration tool changes to no delay this further and will remerge this once this is ready to go
• There are some CI failures to fix, Pavel has been helping me to get those fixed (see Add Fee Currency directory to predeploys #130)
• Next two weeks will be busy for me, but I hope to find some time during the events to push this forward

[tynes]

Some things that we did recently were:

• remove op-bindings, it was creating a lot of overhead for smart contract development with having to autogenerate the bindings and commit them in, diff for smart contract code was too high. We are better about doing specific contracts releases (necessary for upgrades with governance) so services that interact with contracts are responsible for managing their bindings themselves. This is an example on how to autogenerate bindings
• Use foundry to generate the L2 genesis. The custom Go code for manipulating storage was not as extensible and only supported certain types in storage. Now that foundry generates the L2 genesis, everything is more cohesive and the tests can utilize the foundry genesis setup for the unit tests
• Removal of typescript, right now the monitoring and sdk still exist but the plan is to move the monitoring services all to here and fully remove the sdk in the future as its no longer maintained

One question for you, do you use the devnet? Trying to figure out what to do with it, some of our devs use it for local development. I don't think it needs to run in CI on every PR, I think it could run hourly and be fine

[palango]

Thanks for the input here @tynes.

I worked on the rebase and agree that the changes you mention will make maintenance easier in the future (but cause some work now).
Moving the bindings to the places where they are used makes a lot of sense and the whole genesis creation in foundry scripts seems both easier and cleaner. Great work!
The removal of typescript didn't touch our changes so far, but great to know about it early.

Regarding the devnet: Our current plan is to extend it to allow testing of the migration process which will be quite useful. Do you intent to stop maintaining it or are you more interested in our use cases?

[tynes]

We don't intend to stop maintaining the devnet but we are working on a plan for how to make it maintainable long term. It has a lot of tech debt at this point with all of the various flags (use fault proofs, use plasma, use custom gas token) and its not super cohesive. We need it for application developers so that they can easily test cross chain applications. At some point, we will update it to support 2 L2s to app devs to build interop applications, see ethereum-optimism#10608. We did all of our migration testing for the migration in the cloud using ansible because it enabled us to use disk snapshots for faster feedback and also allowed us to develop the tooling we used in prod

[tynes]

Regarding the L2 genesis, I'd like to get to a point where we could do releases of a JSON file that represents a release of the L2 genesis allocs and its the same for all chains. I was thinking that other chains could decorate that standard release of the L2 genesis allocs. Not sure timeline wise when we can get to this because it requires ethereum-optimism/specs#194

[lvpeschke]

@palango how close to completion is the remaining work now?

[palango]

It's mostly blocked on celo-org/op-geth#136 and then we need to cherry pick some remaining commits.