Verkle Proof Verification Precompile

EIP-7545 streamlines state proof verification in Stateless Ethereum via precompiled contract 0x21. By addressing evolving proof systems and leveraging BLS12 curves, it eliminates the need for frequent proving library development, ensuring adaptability without constant upgrades.

Verkle Proof Verification Precompile

The motivation behind EIP - 7545 is rooted in the evolving landscape of Stateless Ethereum. As new proof systems are developed, the tools and applications relying on these systems require a streamlined process to stay current. The goal is to avoid the need for frequent development and deployment of new proving libraries for each introduction of a new proof format.

How does it relate to the BLS12 Curve?

In the context of blockchain and Ethereum, BLS12 curves are commonly associated with cryptographic operations. These curves are known for their efficiency and are often employed in schemes like BLS (Boneh-Lynn-Shacham) signatures, which are particularly useful in the context of privacy and security. Therefore, it's plausible that the LRSC model, within the Ethereum ecosystem, may leverage cryptographic operations based on the BLS12 or similar curves to enhance security and functionality.

What is the goal of this precompile?

The proposed precompiled contract at address 0x21 aims to provide state proof verification capabilities to smart contracts in a stateless Ethereum context. In a stateless Ethereum system, where proofs are crucial for validating the state, having a dedicated precompile can significantly simplify the process of updating proving systems. The goal is to offer a standardized and efficient mechanism for applications and tools to keep their proving systems up-to-date without the need for developing and deploying new proving libraries every time a new proof format is introduced. This can enhance the overall efficiency and adaptability of the Ethereum ecosystem.

The precompile cost is:

cost =(POINT_COST+1)*len(get_commitments(input)) + POLY_EVAL_COST * [leaf_depth(key, get_tree(input)) for key in get_keys(input))]

Why do we need a state verification precompile?

Stateless Ethereum relies on advanced cryptographic proofs, and the field of cryptography is dynamic and ever-evolving. As new proof formats are introduced, applications such as bridges may face challenges in supporting these formats, especially if they were designed after the release of the bridge contract. The state verification precompile, as proposed, provides a version-aware solution. It allows applications to delegate the burden of proof verification to a precompile, ensuring they can seamlessly adopt newer proving primitives without requiring frequent upgrades to their contracts.

Read More

Disclaimer: The information contained in this website is for general informational purposes only. The content provided on this website, including articles, blog posts, opinions, and analysis related to blockchain technology and cryptocurrencies, is not intended as financial or investment advice. The website and its content should not be relied upon for making financial decisions. Read full disclaimer and privacy Policy.

For Press Releases, project updates and guest posts publishing with us, email to

Subscribe to EtherWorld YouTube channel for ELI5 content.

Share if you like the content. Donate at avarch.eth or Gitcoin

You've something to share with the blockchain community, join us on Discord!

Follow us at Twitter, Facebook, LinkedIn, and Instagram.

Share Tweet Send
You've successfully subscribed to
Great! Next, complete checkout for full access to
Welcome back! You've successfully signed in
Success! Your account is fully activated, you now have access to all content.