Withdrawal Design

[karlfloersch]

Here to kickoff discussion about various withdrawal designs. This also includes a rough sketch of the withdrawal contract.

Withdrawal Contract Sketch

Quick sketch of the withdrawal contract:

https://gist.github.com/karlfloersch/02ce7938000680ce7820f39ba06bd9b1

Design Decisions

The main tradeoffs which we need to decide our stance on is whether or not we optimize the withdrawal costs for v1.0. There are two things we can do to optimize withdrawal costs:

1. Stick the withdrawals at the top of the state root
   a. This can be done by adding a "withdrawal root" for each state root that we post. Note that the tricky thing here is that because we submit state roots every n blocks, we will need to persist all state roots from the period somewhere. It's implementation complexity.
2. Move to verkle trees
   a. Not something that we'd want to do for a minimal v1.0 release, but including it here as it is something that we can consider long term - especially if it is implemented in L1.

TODO

Determine how complex it would be to implement optimization #1, and then determine if the complexity is worth the gas savings.

cc @K-Ho

[ben-chain]

Some of the questions on my mind here:

• Are we going to submit/dispute blockhashes, or just state roots?
• Are we willing to add a new field to blocks to reflect the root of recent withdrawals?
• Could we create a separate program which runs cannon with L2 blockhash as input and outputs a root of withdrawals?

[maurelian]

Determine how complex it would be to implement optimization #1, and then determine if the complexity is worth the gas savings.

From a planning perspective, I think we should not include the optimization in the Proposer / State Commitment milestone, and that we should create a new milestone for the optimizations.
That will allow us to:

1. continue making progress towards production without getting blocked
2. evaluate the complexity in parallel, and implement it if/when we feel the cost/benefit indicates we should.

[ben-chain]

I agree with this even if the optimization overhead is pretty minimal.