[WIP] First Steps into Verkle support

[carver]

Context

During the Boulder summit, we decided to leapfrog supporting network access of current Merkle-Patricia Trie state, straight into Verkle state.

Eventual Goal

Once mainnet fully transitions off of the MPT, we can use the mainnet-generated block witness to execute the block and verify the post-state root against the header. Then we can host the batches of data on Portal, and request chunks on-demand.

Pre-transition awkwardness

Before the mainnet verkle transition is complete, though, here are some awkward bits:

1. The bridge needs to fully execute the block to generate the witness, because no witness is provided by the mainnet protocol, yet
2. The bridge needs access to the MPT state, which means we can't skip the step of implementing MPT access
3. We cannot verify verkle state roots (either pre or post execution) by simply looking at the header

We can address these issues, with temporary fixes, but addressing all of these at once is too large a step to aim at. We need intermediate validation that we're making progress. So what can we do along the way?

What Can We Trim?

First, we can ignore the idea of whether we have generated the same state as mainnet, and focus on whether different portal clients can generate the same post state as each other, given some arbitrary block witness.

Second, since the verkle states won't really match mainnet state (we're testing arbitrary inputs), we don't target any new network messages, yet. Whatever content we produce in this short term will be ephemeral. Although verifying the clients work is super-valuable, the content itself is not of any long-term value to us. So don't bother storing it in the network yet. Depending on how complex it is to agree on a serialized verkle witness format, we may want to add a json-rpc endpoint like portal_verkleMakeRoot(block_num, serialized_witness), so that we can verify the transitions in portal-hive most easily.

Third, implementing code execution is its own meaningful project, so let's see if there's anything we can accomplish without that. We could skip all transactions that execute code, and only process the simple transfers.

Fourth, we can skip the fee deduction and the transaction tip going to the coinbase/beneficiary, for now. Those things, and all the real code execution should be handled by whatever execution library we end up importing, so there's no reason to write it now, just to throw it away when we start executing transaction code.

Simplest Possible Verkle Test

So that leaves us with a tiny starting target, which will still take a significant amount of work to implement: locally generate a post-state verkle trie for a block using unvalidated pre-state input, considering only the block's simple transfer transactions, ignoring transaction fees. We can write tests using some simple way of generating pre-state input, like giving all transaction senders 10k eth before the block.

This approach should let us mostly focus on getting the verkle code running ASAP.

Useful links

Test vectors: https://github.com/jsign/verkle-test-vectors

[github-actions[bot]]

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

[github-actions[bot]]

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