Ethereum's core developers discussed in detail about SSZ implementation in the Cancun upgrade in the latest EIP-4844 Implementors Call #18. The conversation focused on the crucial question of whether to pursue a complete migration from RLP to SSZ or opt for a more gradual, partial transition, carefully considering the potential benefits and challenges of each approach.
TL;DR
- SSZ Complexity
- C-KZG
- '0-Blob Txns' Omitted
- 4844 Specs includes KZG multi verify function
- CL Client Team Updates
SSZ Complexity
The full migration of the EL stack from RLP to SSZ is unlikely to happen during the Cancun upgrade due to its complexity and other factors. The developers agreed to partially implement SSZ for blob transactions (EIP-4844) during the Cancun upgrade. They are currently exploring the optimal format to balance factors like storage size and proof size. The partial SSZ implementation will have a different encoding but is planned to be compatible with the broader SSZ roadmap.
After the Cancun upgrade, a dedicated and comprehensive effort will be made to fully reform SSZ on EL. Developers were split on whether to postpone the complete SSZ formatting changes until after the Shanghai upgrade in order to simplify the Cancun upgrade process. Despite this division, it is clear that some minor adjustments will be necessary to accommodate the EIP-4844 code changes, as highlighted by Etan Kissling from the Ethereum Nimbus team.
C-KZG
C-KZG is an implementation of KZG commitments in the C programming language, using the high-performance Blst library from Supranational for field and curve operations. It closely follows the go-kzg implementation. C-KZG is scheduled for an audit on April 17th, and developers are currently seeking feedback on their interfaces.
'0-Blob Txns' Omitted
Previously, core developers have removed '0-Blob Txns' from EIP-4844 in Cancun Upgrade. Removing helps developers to enable a better structure in the code. There is no need for any new transaction type. This will simplify clients' initial implementation, and it's always easier to relax a constraint than add a new one.
4844 Specs includes KZG multi verify function
Also, 4844 Specs have included KZG multi verify function. This implementation enables efficient verification when each blob is accompanied by its commitment proof, as isolated proofs can be used instead of aggregated proofs. In addition, this allows clients to verify individual blobs using their respective proofs or batch verify blobs with slightly faster verification.
Client Team Updates
Client teams are working towards the next interop devnet, with Lodestar and Nethermind taking the lead. More teams are expected to join soon.
EIP-4844 Implementers' Call #19 is scheduled on April 3rd at 15:30 UTC. Core developers will further finalize the latest spec and testing updates of the Cancun upgrade.
Related Articles
- Shapella Testing
- Why Ethereum Clients prefer SSZ over RLP?
- Upcoming Changes to Ethereum Blockchain
- How Warm COINBASE helps in Gas Cost Reduction?
- Transient Storage for Beginners: EIP-1153 Explained
- How Layer 3 in Future will look like?
- An Overview of Beacon Chain API
Related Videos
- Client Diversity
- Reth: Ethereum Execution Layer Client Written in Rust
- Sign-In with Ethereum: EIP-4361
- TWAMM: Time-Weighted Average Market Maker
- MobyMask: An Initiative to Eliminate Phishers
- Fractional NFTs: EIP-4675 using EIP-1155 & EIP-1633
Disclaimer: The information contained on this web page is for education purposes only. Readers are suggested to conduct their own research, review, analyze and verify the content before relying on them.
To publish press releases, project updates and guest posts with us, please email at contact@etherworld.co.
Subscribe to EtherWorld YouTube channel for ELI5 content.
Support us at Gitcoin
You've something to share with the blockchain community, join us on Discord!