feat(protocol): withdrawals without on-chain finalization

[Brechtpd]

This is a way to implement the rough idea Karl Floersch had when I talked with him at devcon where he was thinking of way to speed up withdrawals when some state hasn't changed for some time (but without knowing how it could be done).

Currently only describes a way to implement the most basic case for ETH, but I believe this could be extended further for other assets and with fewer constraints.

Also still very possible this method is flawed because I might have missed something that makes this approach impossible. So please let me know if you think there's a problem somewhere!

In the general case withdrawals can only be processed for a block that is proven and all its parent blocks are also proven. And so because of that withdrawal times are limited by the proof generation time for a block. In some cases however a full ZK-EVM proof is not required as long as certain conditions apply.

Let's say there's an onchain finalized block at X. At block X+n (n blocks later), a user submits an L2 transaction to the L2 ETH bridge to withdraw 1 ETH out of the rollup. Our goal is to be able to proof in another smart contract (on L1 or another L2) that the user's withdrawal transaction is a valid withdrawal transaction without requiring the onchain finalization of block X+n.

To do this we first have to know when a transaction is actually valid:

1. The signature is valid
2. The nonce is valid
3. The account has enough ETH to pay tx_gas_limit * tx_gas_price
4. tx_gas_limit is high enough to successfully do the required transaction

1 and 4 does not depend on any state so easy to check just by checking the transaction data itself. For 2 and 3 we do need to know some select (but not necessarily complete) data about the account at the point when the withdrawal transaction is done. But, taking some shortcuts, we know:

1. The nonce increases for each valid transaction.
2. The ETH balance of an EOA can only decrease when the EOA does a transaction. (An account can get sent ETH in all transactions but to know this requires fully executing all transactions so basically requires a full ZK-EVM proof).

If we simplify the problem as much as possible we can just require that the account did not do an transaction in blocks X+1 up to when the withdrawal transaction is done (this is certainly not a requirement for this system to work, it just makes things easier). This makes is easy to know from the proven data at block X:

• the correct nonce for the withdrawal transaction for the account
• the minimum amount of ETH the account has at the time of the withdrawal transaction

We can read this data directly from the post-state blockhash from block X. The transaction data we can read directly from the transaction data in block X+n. All that's left is for us to be able to efficiently prove that no transactions were done from the account in intermediate blocks (simplified case, otherwise we need to track the nonce and ETH balance, which should also be very doable). To do this efficiently we could depend on an optimized data structure to be attached to proposed blocks that allows this. The most basic one would be a hash of the list of originating addresses of each transaction in the proposed block which allows for a very cheap/simple ZKP to be generated.

This simplified system would already allow immediate withdrawals of ETH as long as (very roughly) the ETH in the account has not been transferred in too recently (roughly the time to generate a ZK-EVM proof). This seems very useful because this allows users to store ETH on L2 that is immediately available on both L2 and L1/other L2s, in a capital efficient manner and without any dependency on 3rd party liquidity providers. And on top of this basic system it seems likely that support for assets like NFTs can be built that cannot be sped up in different ways.

For optimistic rollups that seems like a very attractive system because with very minimal circuits/ZKP support they can support much faster withdrawals. For zkRollups the usefulness largely depends on how fast blocks can already proven with a full ZK-EVM proof.

[ameya-deshmukh]

@dantaik is this still available for brainstorming and collaboration?

[dantaik]

Yes, it is. But to be honest, this feature is not a priority for us (as you have noticed).

[ameya-deshmukh]

Sure! I'd still love to work on it, although a bit of guidance would help :)
Is the Taiko Discord the best platform for questions?

[github-actions]

This issue is stale because it has been open for 30 days with no activity.

[github-actions]

This issue was closed because it has been inactive for a week since being marked as stale.