Checkout our latest Litepaper here:

https://mirror.xyz/hyperoracleblog.eth/FKvpIGI7fiuNr5rnTlFWAdxk4QCNFIR9rmqDPxWLc2w

Layer2 Rollups greatly expand the overall throughput and block space of Ethereum, allowing Ethereum to accommodate more transactions.

The core of L2 Rollups is the need to use Ethereum's Layer1 block space for data distribution (L2 transaction data or state diff), called "data availability". Data availability guarantees the security of Optimistic Rollups (which requires data available to be challenged) and the liveness of Optimistic Rollups and ZK Rollups (which require data to be available to reconstruct state).

To meet Rollups’ data availability requirements, Ethereum introduces a new data layer (EIP-4844 Proto-danksharding → Danksharding) that allows the validator to store rollup data exclusively on a temporary basis.

Such a design can simultaneously meet the needs of Rollups with more bandwidth and a better pricing model, with less impact on the normal transactions of L1s, and also ensure that the hardware requirements of L1 validators are not excessively high, ensuring decentralization.

For the implementation of such a mechanism, a key building block for fast proving and verifying of the underlying data is a polynomial commitment. The polynomial commitment scheme that best meets the criteria are KZG commitments.

KZG is also widely used in zk proof systems. An interesting difference in KZG commitments between Danksharding and ZK systems is that Danksharding runs many small polynomial commitments simultaneously while ZK systems have few but big polynomials.

As per EIP-4844, KZG is an efficient vector commitment scheme, with fixed-size proof data, and forward-compatibility with data-availability-sampling. These commitments are used in the same scaffolding as the full "Danksharding" proposal.

The KZG scheme commits to a polynomial by evaluating it at a secret value (specifically, an elliptic curve point). Simply put, the use of KZG requires a secret value that should be generated by a “ceremony”.

A "Ceremony" is also commonly referred to as a "Trusted Setup". The purpose of a ceremony is to construct a secret value that no one can fully grasp at any time. As long as at least one of the parties destroys the random number in their hand - Paranoia is a virtue when it comes to trusted setup ceremonies - the whole ceremony is valid.

You may be thinking, since the use of KZG requires an additional trusted setup, why not just use a commitment scheme that doesn't require a trusted setup? It’s because the loss of functionality and increased complexity of using something else are far greater than the risk of KZG itself (including a trusted setup).

To summarize, a KZG ceremony is a prerequisite for Proto-danksharding and Danksharding to run a KZG scheme for these two mechanisms. A KZG ceremony will generate a secret value for the KZG.

In KZG Ceremony, there are three main roles.

• Sequencer: act as a common point of interaction and verify contribution

• Client: submit contribution to sequencer

• User: generate randomness to client for contribution

The overall flow is shown in the figure below. Note that many details may have been deliberately omitted for demonstration purposes.

The implementation of a KZG Ceremony Client can use different programming languages and underlying BLS libraries. Currently we have a very wide range of implementations, besides the implementation by Ethereum Foundation.

Each client implements the same specification with its own special code and understanding of the specification, using different underlying libraries and technical solutions. So why do we need so many different client implementations?

A Ceremony needs to prevent single points of failure that leak the randomness, not only by involving more people in the ceremony, but also by ensuring that the diversity of clients ensures that no single software error causes a failure.

Just as we want to ensure the diversity of the Ethereum client (especially execution client). Having multiple clients built on the same spec in different languages and technology stacks has the following two main benefits:

• Better decentralization: hedge against single client failure

• More features: more choices with different features and tech stacks for users

Hyper Oracle is proud to contribute to the client diversity of the KZG Ceremony. We completed the Halo2-based KZG Ceremony Client and an additional way to verify ceremony contribution with the help of the Ethereum Foundation's KZG Ceremony Grant.

Under the KZG Ceremony Client and new way to verify contribution by ZKP developed by Hyper Oracle, the entire KZG Ceremony contribution process can be implemented as follows:

Our work has contributed to both of the two essential KZG Ceremony components: Client and Sequencer.

• hyperoracle/kzg_ceremony_halo2: contribute to KZG Ceremony with random string + generate zk proof of contribution

• hyperoracle/kzg-ceremony-sequencer: sequencer can verify contribution by verifying zk proof of contribution, in addition to verifying contribution in the normal way

You can find the code and try to run the client for contributing to KZG Ceremony and generating ZKP for the contribution process with our open-source repo.

Our client has two major advantages, namely diversity and verifiability.

Diversity

The magic of our implementation is:

• Rust: We use Rust to write the client, the only Rust CLI Client in the public collection.

• Halo2: We use Halo2 (a common ZK framework for the Rust language), which means that our client has the ability to generate zk proofs.

Our KZG Ceremony Client uses the most "diverse" Rust language, even using a Halo2 framework that even the Ethereum Foundation didn't think of.

Verifiability

With the choice of our technology stack, Halo2 allows us to perform common computations while generating proofs for these computations. As we described earlier, we can generate Proof of Contribution and the modified sequencer can verify Proof of Contribution without checking the computation itself.

In almost all cases, the trusted setup or a ceremony client’s contribution verification happens in an off-chain environment. Our implementation allows any party to verify a zk proof faster and more trustlessly, and thus achieve a better representation of computational validity.

In addition, this also opens the potential to verify Proof of KZG Ceremony Contribution directly on-chain. However, it is important to note that this is impossible now and will require a lot of optimization before it is feasible and affordable in the future.

Since the computation itself is very computationally intensive, and the proof generation of zk further increases such challenges, we still encounter problems with proof generation latency and proof size in our implementation.

• Proof generation Time: We achieve this computationally intensive proof generation by splitting the circuit and extensive optimization. In order to make proof generation time meet the special contribution requirement, and even in the future to achieve proof generation times as small as 128 seconds for the normal contribution phase, we still need to improve performance by means of GPU acceleration or more.

• Proof Size: Even in KZG Ceremony Sequencer, we need special adaptations to allow Sequencer to successfully verify the final huge zero-knowledge proof. Despite the possibility of on-chain direct proof verification, the cost of direct on-chain verification is too high due to the large size of the final generated proofs combined (in megabytes).

After we’ve done our building, we have contributed to KZG Ceremony via the Hyper Oracle KZG Ceremony Client and generated the associated ZKP in production. The proofs and contribution data were uploaded to our repo.

We hope that users can experience our kzg_ceremony_halo2 implementation to add their contributions by themselves to the Ethereum KZG Ceremony to build a more diverse and decentralized Ethereum. We also hope that developers can be inspired from this example of client diversity.

The Ethereum Foundation has highly valued our development and ceremony contributions. "[Hyper Oracle's] proposal surprised us as we really didn’t consider using a general purpose SNARK to prove a contribution (when there is essentially a special purpose SNARK being verified by the sequencer anyway.) Very cool that you managed to pull this off.” Again, we are very grateful to the Ethereum Foundation for their communication and discussion during our development process and grant support.

Follow us on Twitter and join our Discord to stay up to date with Hyper Oracle. Learn more about Hyper Oracle on our website.