Latest updates on the work towards stateless Ethereum, from Verkle Implementers Call #9! First, a quick refresher on the benefits we eventually get from all of this 📈 Not only will verkle/statelessness significantly improve the decentralization of the network (by reducing the amount of data most nodes will need to store), it will also help pave the way for additional performance/scalability work (potentially raising gas limit (tbd), improving i/o, etc). Verkle is also more compatible / gets us closer to a zkevm future we are likely working towards. But of course still work to be done to verify assumptions and evaluate tradeoffs of some of these decisions. Good thread here for further reading: xitter.cf/gakonst/status/1724978… On to this week’s agenda: 1. Client team updates 2. Small bug fix to MainStorageOffset 3. BLS curves & Verkle 4. Gas schedule changes: EIP-4762 5. State proof verification precompile: EIP-7545 === 1. Client team updates @gballet: Making good progress on the shadow fork. Attempted with the Holesky testnet, and because it's a real payload a few bugs were found that were not previously visible. Will have more to share soon (note: a shadow fork is a new testnet created by forking a live network with a small number of nodes, keeping the same state/history). @ignaciohagopian: completed some test vectors for cryptography libraries. Ran them in the Go implementation. Probably will work on the Rust implementation in the near term. Next up will be completing the other part of the test vectors for the Verkle tree data structure and witness generation. @Gajpower: for @EFJavaScript: working on stateless sync. Integrating the new gas schedule, and adding the charges for Verkle witness accesses. Have had some success there, and able to run a few of the transactions. Aim is to complete this week and then try again syncing into EthereumJS stateless implementation! @kt2am1990: for @HyperledgerBesu: working on having the same root hash for the genesis block. Fixed several issues. Last issue remaining was due to a small difference between the spec and the Geth implementation. Once we have the same generic state root, then should be able to join the testnet. Somnath: for @ErigonEth: have been able to join the network, but hit some issues on block 12 related to gas schedule mismatch. Working to resolve this issue soon, and then make further progress on syncing with the testnet. @jasoriatanishq: for @nethermind: working on fixing some issues with block production, and after that will get back on Verkle sync. Daniel: for @ethnimbus: finalizing the crypto library, and will integrate it into the Nimbus Verkle implementation in the next couple of weeks. Then can start seeing root hashes. === 2. MainStorageOffset fix @gballet took a few mins to flag this recent small fix, just to make sure all client teams are aware. Tldr: there was a mistake in the computation of the mainStorageOffset value. @kt2am1990 kindly spotted the issue, and Guillaume was able to put up a fix. When the testnet is next relaunched it’ll include the fix. See github.com/gballet/go-ethere… === 3. BLS curves & Verkle Next up, @CPerezz19 led a helpful discussion summarizing some conversations around BLS curves & Verkle, which was started in part from an exploration of a great paper recently put out by @asanso: github.com/asanso/bls-s/blob… Note: for a bit more general background on this topic I recommend this awesome resource put together by @benjaminion_xyz: hackmd.io/@benjaminion/bls12… The initial idea from @CPerezz19 was to see if it was worth it to try to find a new pair of curves which could have some nice gains. Feedback received from discussions with @dankrad/@GottfriedHerold/@ignaciohagopian and others was that the drawbacks of the curve used today shouldn’t actually cause significant issues. And the design of a new BLS curve isn’t worth the benefits at this point, considering the work it would take to actually put into a precompile etc. Also there is a good chance that BLS12-381 will make it into mainnet anyways via 4844, so it’s probably worth it to reuse this. Conclusion: sticking with BLS12-381 (plus Banderwagon) is the best path forward. === 4. Gas schedule changes: EIP-4762 Background: EIP-4762 outlines statelessness gas cost changes, and was initially created with the idea that this EIP would ship in the fork right before Verkle (to give time for dapps to adopt the new model, among other things). It’s no longer likely that these changes will ship prior to Verkle, because we can’t make the changes to lower gas costs for certain operations before implementing Verkle. Potential problem: a good bit of tooling breaks with gas schedule changes. For example, with each transaction, you have intrinsic gas which is gas that you pay upfront prior to execution of a transaction. With Verkle, this is something that we pay on the side, because we’d be paying the cost of adding it to the witness. So that means even sending a simple transaction might no longer be 21,000 gas with Verkle. This breaks some tooling because that value is hardcoded in a lot of places. Conclusion: should keep it at 21,000 with Verkle. When you start up a transaction, you'd read the sender account and read the recipient account, and those values won’t get charged. They are included in the 21,000. And those values get added to the witness with Verkle, so they don’t get charged later on. Guillaume to create a PR to update the EIP. === 5. State proof verification precompile: EIP-7545 Last up: there is a proposal to add a precompile that helps with state verification. This isn’t necessarily verkle-specific, as it could actually have the ability to verify merkle trees as well. How the precompile would work at a simplified, high-level: it gets the version from the first byte, and if version is zero it will deserialize the merkle proof. If the version is one, it will deserialize a verkle proof. The precompile returns one if it successfully verified the proof, and zero if it did not. Two points brought up by @ignaciohagopian: (1) this precompile should have a way to check which keys are being proven. Because if a contract is receiving a proof and using this precompile to verify, you will probably want to know specifically which keys are being verified. (2) other point is whether the support for merkle proofs is worth the added complexity, since at some point after verkle is on mainnet, merkle proofs may no longer have much usage. @CPerezz19: regarding complexity of implementation: it’s prob not that complicated to just support the precompile. The complex thing will be all of the logistics when it gets deprecated, or the maintenance burden, etc. The ongoing support costs even if no one uses it. @dankrad: regarding the precompile having a way to check which keys are being proven: ideally you'd want more for a really independent proof scheme. You want even logically to say what you want to access. Because even if you prove key values, then the proof is still dependent on the mapping. Conclusion: all agreed, and @gballet to think about how to implement the API. === That’s it for this week’s call! Check out verkle.info, or pop into the Eth R&D Discord (verkle-trie-migration channel) to stay up-to-date 🙏