For evaluating the options I used the ZisK emulator ziskemu, which runs guest execution (without generating a proof) and accumulates AIR-cost. The cost derived from the execution trace translates to the proving complexity. While we ultimately care about proving time, using the emulator to measure AIR-costs is more practical.

Allocator options

All allocators can be selected via Cargo feature:

bump (default): The simplest possible allocator. Keeps a pointer to the next free byte and advances it on each allocation. Memory is never reclaimed.

dlmalloc (explainer): Each allocated block carries a small header with its size and a flag. When a block is freed, dlmalloc adds it to the free list and checks neighbors. If adjacent blocks are also free, it merges them into a larger block so future allocations can reuse the space.

talc: Similar mechanism to dlmalloc with merging of adjacent free blocks, but organizes free blocks into buckets.

tlsf (explainer): Instead of searching a list, it uses a two-level bitmap to jump directly to a free block of the right size. Amortized O(1) alloc/free.

How are the costs calculated

ZisK is a collection of specialised modules much like a modern CPU. Each module (state machine) has its own execution trace. Every instruction the guest executes fills rows in one or more traces. The emulator sequentially executes each instruction, looks up per-op cost constants, and accumulates into buckets:

• MAIN: Cost of processing, proportional to the number of instructions executed. Every instruction contributes one row here regardless of what it does. This is the baseline before any operation-specific overhead.
• OPCODES: Additional rows for the operation itself, on top of MAIN. These cover simple operations (add, sub, mul, shifts, bitwise). For example, a multiplication fills MAIN with one row and OPCODES with the multiplication cost.
• PRECOMPILES: Specialised circuits for operations too expensive to express as RISC-V sequences. An example for precompiles is a hash function call.
• MEMORY: Additional rows for memory reads and writes, including extra overhead for non-aligned accesses.
• BASE: Fixed overhead independent of the guest program. For example the overhead needed for lookup tables.

Total cost = MAIN + OPCODES + PRECOMPILES + MEMORY + BASE. Per-op costs are defined in zisk_ops_costs.rs. The current memory limit is set to 512MB in mem.rs.

50 Mainnet blocks

The first setting where I evaluated the allocator is on the mainnet blocks 24949787 - 24949836, by using zkevm-benchmark-workload to run the ZisK v0.16.1. I used the locally compiled ethrex stateless client from commit b112f94.

In all cases it holds: bump < dlmalloc < talc < tlsf. I wanted to check min and max gas block to see if there is noticeable difference in the costs, but it does not seem to be the case. The delta for bump and dlmalloc is consistent across the three rows (6%, 6.5%, 6.5%). We can also take a look at the distribution of the costs across the state machines.

As expected BASE and PRECOMPILES are identical across all allocators. The largest difference is in the MAIN costs (+9% to 16%). No matter if the allocator performs comparison or traversal to evaluate the free space, each of these steps adds complexity to the MAIN state machine. The difference on MEMORY is less significant (+5% to 8%). The allocators store some additional data in form of a header or metadata but this overhead is relatively small. The measurements in a table format can be viewed in the last section of the blog.

EEST Fixtures

The current mainnet (Fusaka) block gas limit is 60M. The next Glamsterdam fork raises it to 200M. How does this affect zkEVMs? Keep in mind that, average case performance matters less than worst-case. A single “prover killer” block that crashes on memory or exceeds the 12s block time is enough to halt proof generation.

I used fixtures generated using the EEST benchmark suite for 100M gas limit. To parse the generated tests for the zkevm-benchmark-workload I used witness-generator-cli. The exact commands are listed in the last section.

100M fixtures

In these EEST tests the bump allocator still performs the best however, we see the first OOM, which is a problem. The tests like ADD and MULMOD, which do not make many allocations, unsurprisingly, do not show much difference in the total cost. But other tests like SSTORE or SLOAD show more variety.

Aside from that, we can also measure the memory usage. Or more precisely the highest address touched from the PR1141 on ZisK. In this measurement keccak_max_permutation OOMs, and there are other tests like modexp and sha256 that also allocate a lot. This suggests that for higher gas limits they might also fail.

The memory usage across dlmalloc, talc, and tlsf is similar. Since memory is cleared between blocks, the choice between these three should come down to AIR-cost performance rather than memory footprint.

Allocator comparison

Across almost all of the tests we are seeing bump < dlmalloc < talc < tlsf in terms of the AIR-costs. The profiling data also show the costs of the function calls. The average for the above 100M EEST tests is the following:

Bump does the least work resulting in lowest costs. After that dlmalloc is the second candidate. On native hardware, talc and tlsf can win through cache locality or fast bit operations. These advantages do not translate from standard computation to zkVM.

Without getting into too many allocator details, let’s look into tests with higher gas where the memory limits are a bigger problem. The following tests take long to compute, so I will compare just dlmalloc and bump.

200M fixtures

As expected the tests mentioned above (modexp, sha256) fail for the 200M gas limit. It is possible to avoid the OOM by increasing the memory limit for the bump allocator on a fork of ZisK. This prevents the crashes and is even more efficient on the modexp test.

However, these results cover only a small subset of 200M tests. Running all of the 200M tests is just too heavy to do locally. It is very possible that there exist some tests which fail even for the 1.5GB memory limit with bump allocator.

Below we compare the memory usage, where dlmalloc is consistently lower, making it safer for potential future L1 inclusion.

Conclusion

The trivial bump allocator performs better on AIR cost in almost all cases, however from just the few tests tried there are OOMs and more can be seen at zkevm-benchmark-runs. From the measured cases the most viable option seems to use dlmalloc.

Notes

Useful commands

Building ELF file

docker run --rm \
   -v "$PWD":/ere-guests \
   -v "$PWD/output":/output \
   -v "<path to ethrex>":/ethrex \
   -v "<path to zisk>":/zisk \
   "ghcr.io/eth-act/ere/ere-compiler-zisk:0.12.1" \
   --compiler-kind rust-customized \
   --guest-dir /ere-guests/bin/stateless-validator-ethrex/zisk \
   --output-dir /output \
   --elf-name stateless-validator-ethrex-zisk.elf

Generating EEST fixtures

 uv run fill \
  --gas-benchmark-values <gas limit> --fork Prague \
  --output <output name> --clean -n auto \
  -k "<test name>" \
  tests/benchmark/compute

Converting EEST fixtures to inputs:

EF_TEST_TRIE=default cargo run --release -p witness-generator-cli -- \
  -o <output file> \
  tests --eest-fixtures-path <input files>

Running ziskemu

RUST_LOG=info RAYON_NUM_THREADS=2 cargo run --release -p ere-hosts \ 
  -- --zisk-profile --zkvms zisk --bin-path <path to ere-guests>/output \ 
  stateless-validator --execution-client ethrex \
  --input-folder <path to generated inputs>

Data tables

Computation model

We are compiling for architecture riscv64im_zicclsm, which is a bare-metal target. There is no operating system, no standard library and you need to bring your own memory management. Every operation and branch must eventually be proven in the resulting proof of computation.

This instruction set is deliberately simple. There are no extensions like vectorized instructions, but we do have precompiles for computing hash functions. The Zicclsm feature adds support for misaligned loads and stores, more info about why we need it can be found in zkVM standards.

Looking at the ZisK costs table this is also different from conventional CPU. Arithmetic multiplication and division have the same cost. The compiler sometimes rewrites operations using bitwise tricks that are fast on real hardware, but this is counterproductive here. Every instruction pays a fixed cost and multiplication replaced by a series of bitwise operations is strictly worse.

Existing findings and constraints

The mentioned paper correctly identified the most relevant LLVM passes. For the beneficial optimizations it is possible to increase their impact by adjusting the parameters. However it is not easy to disable passes that regress the performance. The previous work patched the LLVM source code to turn off such optimizations, but we will limit ourselves to not doing this for the Ethereum (future) mainnet. If every team developing a zkVM has their own custom compiler the reasoning about the whole system is more complicated.

One clear outcome from the paper is that, applying the opt-level=3 optimizations significantly helps. At this setting, LLVM applies almost every optimization available to it. The tricky part is that some of those passes are harmful for zkVM workloads, and there is no clean --disable-pass <name> flag in the New Pass Manager.

I tried to enumerate the default passes using --print-pipeline-passes, strip the problematic ones, and feed the remainder back manually. However, when benchmarked, that approach regressed. The set of passes LLVM applies internally is apparently not equivalent to the list I fed back. Determining the exact passes seems to be hard. So manually reconstructing the pass pipeline is not a reliable approach.

That being said, there are a few passes that expose a specific disable option flag, but this is more of an exception. Alternatively it is possible to disable some passes by forcing thresholds to zero.

Search for optimal parameters

Okay so, this effectively leaves us with codegen options and llvm-args. There are way too many knobs that we can tweak. I picked the flags, specified in the paper reference implementation, and fed that to an Optuna optimizer commonly used to find hyperparameters in machine learning. The following parameters provided the best results:

--inline-threshold=4749
--inline-instr-cost=1
--inline-memaccess-cost=1
--inline-call-penalty=12
--unroll-threshold=378
--disable-licm-promotion
--licm-versioning-max-depth-threshold=0
--memdep-block-number-limit=2510
--memdep-block-scan-limit=98
--jump-threading-threshold=16
--jump-threading-implication-search-threshold=6
--max-speculation-depth=0
--max-uses-for-sinking=119
--available-load-scan-limit=23
--bonus-inst-threshold=5
--max-num-inline-blocks=6
--loop-interchange-threshold=2
--early-ifcvt-limit=29
--loop-distribute-scev-check-threshold=0
--loop-load-elimination-scev-check-threshold=7
--max-dependences=6
--max-nested-scalar-reduction-interleave=2

The results have a few interesting points. In the previous work it is already known that inlining is the most impactful optimization. That is why the optimizer set the threshold to roughly 21 times the default. Related flags (--inline-instr-cost, --inline-memaccess-cost, --inline-call-penalty) also push the optimizer to prioritize inlining. The flag --max-speculation-depth is pushed all the way to zero because we do not have any branch predictor. Beyond that, the memory dependence limits (--memdep-block-number-limit, --available-load-scan-limit) are adjusted to give LLVM more space for identifying redundant operations.

A few of the other remaining passes lower the thresholds to effectively disable features that the zkVM does not possess. The flag --disable-licm-promotion was added manually because the previous study found that licm was the most harmful pass.

Codegen options

The existing infrastructure in ere-guests already provides:

• codegen-units = 1: compiles everything as a single unit, giving LLVM full visibility across the codebase for cross-function optimizations like inlining
• lto = "fat": performs link-time optimization across the entire dependency tree
• panic=abort: crashes immediately on error, this eliminates the unwinding logic that would otherwise appear in the trace

I also tested optimising for size with opt-level=s, by reasoning that larger memory means a larger trace to prove. However, size-optimized builds underperformed compared to opt-level=3, suggesting that release passes are still better. Besides that, a popular feature is also target-cpu=native, but that is irrelevant, because we are running a VM not on a native CPU and it already has a specified target.

Results

The profiling was done using zkevm-benchmark-workload on mainnet blocks 24949787 - 24949811 and the results show a consistent reduction of the AIR-costs by something over 10%. The average cost per block on the baseline is 44.22B, and the optimized version 39.54B.

Unexplored directions

One could write custom LLVM passes with llvm-plugin. This would allow writing passes tailored to zkVM cost models without forking the compiler, since plugins load at compile time into an unmodified binary. This task seems to be quite complex, and potential improvement was unclear. Besides that it is also possible to give the compiler more context about the program with Profile Guided Optimization. Since we are compiling for bare-metal, this makes the instrumentation more complicated. For sure it is possible to make this work but the optimizations are calibrated for standard CPU cost models and in this case I did not have a reasonable estimate for benefit on the zkVM.

As an outcome, it is possible to get at least 10% improvement on top of opt-level=3, which is very reasonable for no-code change. But as the paper highlighted, the best approach is to use an optimizer to find the most suitable parameters for the specific zkVM.

This is a user-friendly overview of cryptographic primitives of Ethereum. This post does not describe the algorithms, but rather give and overview and useful references for detailed description.

…cover image is generated by AI

At the time of writing, Ethereum processes over a million transactions daily. The combined market capitalization sits at hundreds of billions of dollars, with tens of billions more locked in smart contracts (TVL). That is a lot of trust and value placed on a single protocol. But what exactly secures this value? In this post, we will look at the cryptographic primitives that make Ethereum secure. We will cover the use of algorithms ECDSA, BLS, keccak256 and KZG. Moreover, we will take a look at how is Ethereum positioned again the quantum computers.

Used primitives

ECDSA

ECDSA stands for the Elliptic Curve Digital Signature Algorithm. It is a variant of the Digital Signature Algorithm (DSA) which uses Elliptic Curve Cryptography (ECC) rather than the modular exponentiation found in earlier schemes like RSA. The advantage over RSA is that ECDSA can achieve the same level of security with a much smaller key size.

ECDSA is used to authorize state transitions initiated by network users (EOAs). In other words, it allows you to prove you are the owner of a wallet without revealing your private key. For every public key, there exists a corresponding private key. The private key is used to generate a signature, and the public key is sufficient to verify that the signature was generated by the owner.

Every time a user sends a transaction from an EOA address, they generate an ECDSA signature along with the transaction data to prove that they own the private key for that respective wallet. The core concept is that only the owner of the private key can generate a valid signature, but anyone can verify it. For each transaction, before submitting it to the execution layer, the node checks the validity of the signature. The user authorizes a transaction in the following way:

1. Data preparation: the account nonce is attached to the transaction data (recipient, amount, …) to prevent double-spending
2. Hashing: the transaction data is hashed using keccak256 to create a message digest
3. Signature Generation: apply the ECDSA algorithm on the message digest and private key to generate the resulting signature

Ethereum relies on public key recovery. Unlike standard verification where the output of the verification is true/false, Ethereum transactions provide the signature, and the network recovers the public key from the signature. If that recovered address matches the from field in the transaction, the transaction is considered valid.

The security of ECDSA relies on the Elliptic Curve Discrete Logarithm Problem (ECDLP). This problem currently secures the vast majority of online communication. The algorithm relies on an algebraic structure where the elements are points on an elliptic curve. To understand this better take a look at my math toolkit post. It is widely believed that calculating the discrete logarithm in this structure is infeasible because no we do not know any algorithm that would be significantly faster than brute-force. The specific curve used is secp256k1 which is the same curve used in Bitcoin. The ECDLP is also referred to as a one way function because in this structure it is easy to perform exponentiation (multiplicative notation) but hard to compute the logarithm. For a deeper look into how this structure works check the blog post “Elliptic Curve Cryptography: a gentle introduction” by Andrea Corbellini.

BLS signature scheme

This is a different type of scheme with a property that allows signature aggregation. While ECDSA is used at the execution level this scheme is useful in proof of stake where validators attest to blocks. Ethereum has hundreds of thousands of validators who vote on the proposed blocks and the blocks need a supermajority to get finalized. The BLS signature aggregation is useful for attestations in Ethereum’s consensus layer, where validators vote on blocks every epoch. Checking all of the signatures from validators for each block would be computationally expensive to say the least.

This signature algorithm is fairly similar to ECDSA but the underlying curve BLS12-381 has “special pairing properties”. This is well described in the blog BLS12-381 For The Rest Of Us. The pairing describes a bilinear mapping of a sort. The important thing is that this maps points from a source group to a target group and this property is used in the verification procedure.

In this case aggregation means that all signatures over the same message or vote can be checked with a single verification and the size of the signature is not related to the number of signers. This is because the whole algebraic structure has linearity and the public keys can be summed up into a new key. To the scheme this aggregate key is not different from any other key.

Besides this usage there is also RANDAO which is the source of randomness in Ethereum. For example, a block proposer is randomly selected and the randomness is determined by this mechanism. The usage of BLS is crucial here because BLS signatures are unique and deterministic. Unlike ECDSA where you can create many valid signatures for one message using different random nonces, a BLS signature is fixed for a given key and message. This prevents the block proposer from manipulating the randomness by trying different signatures until they get a favorable result. If you are interested in how this works here is a really nice explanation in the ethbook

The hardness of the BLS signatures comes from the Computational Diffie Hellman assumption and Pairing Inversion. The first assumes that even if you know the public points corresponding to secret numbers it is hard to compute the point corresponding to their product. The second states that the pairing function itself acts as a one way function meaning you cannot reverse the mapping to recover the original inputs from the target group.

Keccak-256 hash function

Now we get to the hash function of choice. We have already seen this in the ECDSA section where the signature is created from the message digest, where the digest is generated by the hash function. This is only one of many places where the hash function is used. The hash function takes arbitrary length input and generates a 256-bit output deterministically.

The prime concept in blockchain is that each block has a hash that is in a way dependent on the hash of the previous block. This chain of dependencies makes it possible to easily check if the finalized data has been modified. If any data in a previous block were modified, its hash would change, and all subsequent blocks would become invalid. This mechanism gives a blockchain immutability. Likewise we utilize hashes on transactions to make sure that the transaction details were not modified.

Another important use is address derivation. User addresses (EOAs) are derived by taking the Keccak-256 hash of a public key and keeping only the last few bytes. Contract addresses are similarly derived using Keccak-256 over a combination of the creator’s address and nonce. This ensures that addresses are deterministic, unique, and infeasible to predict or reverse-engineer in a meaningful way.

Another important part is the connection to Merkle trees. The data is split into pieces, hashed, and arranged into a tree, and a root hash commits to the entire set of data in the leaves of the tree. This is used to commit to Ethereum’s entire state. These roots act as compact commitments to millions of accounts and transactions and allow nodes to prove the inclusion or absence of data using Merkle proofs. Moreover, the keccak256 hash is used in EVM to handle smart contract storage locations, but you get the point…the hash function is a crucial building block.

From a security perspective, it is designed to satisfy the standard assumptions for cryptographic hash functions:

• Preimage resistance: given a hash output $y$, it is computationally infeasible to find an input $x$ such that $h(x) = y$
• Second preimage resistance: given an input $x$, it is infeasible to find a different input $x’$ such that $h(x) = h(x’)$
• Collision resistance: it is infeasible to find any two distinct inputs $x, x’$ such that $h(x) = h(x’)$

Probabilistically from the birthday paradox, we would need to try approximately $2^{128}$ hashes in order to get a collision, which is beyond feasible. Now where does this function come from, how does it work, and why do we trust it? Keccak256 is closely related to the standardized SHA-3. This is the winning proposal for NIST’s standardized hash function competition where leading cryptographers submitted their proposals for an optimal hash function. Generally there is a consensus that this is safe to use. To get more information on the proposal you can directly check the keccak team website.

KZG commitment scheme

The KZG commitment scheme is one of the main components in Ethereum’s scaling roadmap. Specifically Danksharding provides a way to verify that large chunks of data have been published without requiring every node to process that data permanently.

To understand why KZG is necessary, we briefly explain how Layer 2 (L2) scaling works. L2s execute transactions off-chain to save costs. However, these transactions are secure only if an independent observer can verify that they are not fraudulent. If a Layer 2 sequencer claims, “I processed $n$ transactions and the new state is $X$,” but refuses to show the actual transaction data, no one can verify if they are telling the truth. Data availability guarantees that the transaction data is public so that honest actors can audit the state and dispute it if necessary. To get deeper into danksharding check the a16z post on danksharding.

Traditionally, data integrity is enforced using Merkle trees. While secure, Merkle proofs grow logarithmically $\mathcal{O}(\log(n))$ with the size of the data. KZG allows committing to an entire blob using a single, constant-size commitment, and later verifying parts of that blob with constant-size proofs, independent of the blob size.

To oversimplify, KZG represents the data blob as a mathematical polynomial $f(x)$. The commitment is essentially the evaluation of this polynomial at a specific secret value. Later, when a verifier wants to check that a certain piece of data belongs to the committed blob, the prover generates a small opening proof showing that the polynomial really evaluates to a certain value at a given point. The verifier can check this with a constant number of pairing operations. If even a single coefficient of the polynomial was modified, it would be computationally infeasible to create a valid proof for the original commitment. So if the data was changed, it would be almost impossible to construct a valid proof for the original commitment. For a clear description of KZG see my detailed write-up from a different blog.

When an L2 is acting honestly, the flow is as follows:

1. Batching: L2 transactions are batched into a “blob”
2. Commitment: the polynomial commitment to the blob is calculated
3. Submission: the transaction (containing the blob and the commitment) is sent to Ethereum
4. Verification: Ethereum nodes verify that the blob data matches the commitment. The network guarantees the data is available for a temporary period
5. Finalization: The state proposed by the L2 is tentatively accepted. Because the data is guaranteed to be available, other actors can download it, re-execute the transactions, and raise a dispute.

The KZG polynomial commitment scheme has multiple security properties which assume the ECDLP mentioned before and also a variant of the stong Diffie-Hellman Assumption, which is more specific than computational Diffie-Hellman Assumption for ECDSA.

Summary

Bits of security

Talk about the economic security as well at cryptographic security.

Hardness of the internet

Before we sum up the primitives used in Ethereum, we make a quick detour to the traditional internet. The Transport Layer Security (TLS) is the cryptographic protocol that essentially secures the communication over the Internet. The protocol is used heavily in email, instant messaging, but most importantly, HTTPS. HTTPS is the implementation of TLS encryption layered on top of the traditional HTTP protocol.

Every time you see https:// in your browser, that communication is secured with TLS. In the most recent version, TLS 1.3, there has been a shift towards exclusively using Elliptic Curve Cryptography. From the specification of comparing TLS 1.2 to TLS 1.3:

“Elliptic curve algorithms are now in the base spec, and new signature algorithms, such as EdDSA, are included…”

There are multiple supported curves. If you want, you can check the specification yourself in section 4.2.7. Without getting tangled up in the details on which specific curve is being used where, we can oversimplify and claim that the ECDLP is the hardness problem of choice for internet communication. Now for an experiment, try going to your internet banking and check the connection you have to the banking server. Most probably this is going to be https that is relying on elliptic curve cryptography. From this, you can see that if people can break the hardness assumptions, there is not only a problem with Ethereum but also with your bank.

Now to sum it up, Ethereum relies on the ECDLP along with Computational and Strong Diffie-Hellman Assumptions. The Strong Diffie-Hellman assumption is more specific or rather mathematically a stronger assumption than the computational variant.

Now there is also the hash function, right? There is a slight difference between keccak256 and the accepted SHA-3, however this does not affect the security. While SHA-2 still remains very commonly used, the security of SHA-3 is assumed to be higher. These hash functions use entirely different constructions and while SHA-2 remains the most popular, SHA-3 is more secure.

To sum it up, if these problems are broken, the internet has a problem and with it goes Ethereum. For now we can overgeneralize to say that the hardness of Ethereum is actually breaking the internet:)

Post-quantum future

Okay great, now one question that is going to come up in this conversation is what about quantum computers. The truth is that Ethereum is not post-quantum secure. The cryptographic primitives we discussed, ECDSA, BLS signatures, and KZG commitments, all rely on hardness assumptions that a sufficiently powerful quantum computer could break. In the roadmap highlighted by Vitalik, the transition to post-quantum schemes is planned for the last phase, the Splurge.

There is a development team working on Lean Consensus that aims to ship post-quantum security among other improvements. Justin Drake and his team have been developing this lean Ethereum consensus protocol that should address quantum vulnerabilities while also improving efficiency and simplicity. You can follow their progress and technical specifications at leanroadmap.org.

STARKs

reed-colomon proximity conjecture hash based things etc etc

Quantum emergency

However, there has already been some discussion on Ethereum research forums about what to do in case of an overnight quantum breakthrough. The scenario being planned for is one where quantum computers suddenly become capable of breaking ECDLP, which would allow attackers to derive private keys from public keys and steal funds from any address that has ever made a transaction. In this emergency case, there would be a handbrake mechanism in the form of a hard fork. The proposed recovery mechanism is as follows:

1. Freeze and rollback: The chain undergoes a hard fork that rolls back to the state before the chain was affected
2. Disable EOAs: The fork disables all traditional transaction types. You can no longer send ETH by simply signing with your private key because the attacker can forge this.
3. Prove ownership: Users cannot safely reveal their private key. However, they can prove they know the seed phrase that generated their address. A new transaction type is added where users submit a STARK proof. This proof mathematically demonstrates: “I know the seed phrase that hashes to this address” without revealing the seed phrase itself.
4. Migration: Successful proof submission moves the user’s funds into a new wallet equipped with a quantum-safe signature scheme

In this article we explored the cryptographic primitives securing Ethereum: ECDSA for transactions, BLS signatures for consensus, KZG commitments for data availability, and Keccak-256 for hashing. These all rely on the similar hardness assumptions protecting the internet you use every day for everything. Breaking Ethereum means breaking the internet. Looking ahead, teams of really smart people are working on new cryptography to future-proof against tomorrow’s computers. It seems that the security of the protocol has a bright future.

Thanks for reading. In case I am spreading any misinformation, feel free to contact me.

This post was written as an outcome of the Ethereum Devconnect Scholars programme. Huge thanks to Ethereum Foundation for making it possible for me to attend the Devconnect 2025<3

1. Overview
2. Arithmetization
3. Math Preliminaries
4. KZG
5. Setup
6. Round 1
7. Round 2
8. Round 3
9. Round 4
10. Round 5
11. Verification