Bitcoin

zkEVM Bootcamp – Week 2

This is the second week of the zkEVM Bootcamp by Encode.

Rust

We went over the most important highlights about Rust language. Since I’m following the Rust Essentials guide, I won’t add any notes related to Rust here. Check repo for work.

Categorising L2s

  • Generalized Layer 2s: Arbitrum 1, Optimism, Starknet … Anything possible in mainnet should be transferable to the L2.
  • Application specific Layer 2s: Aztec, zkSpace. These are optimised for specific application space.

Modular Rollup Theory

In 2020 rollups were monolithic. Then it was realized that proofs should be separated from execution, and should be general. Then projects started to break out the data availability, so we get 3 primary layers:

  • consensus
  • execution: where we take the state and compute the next state
  • settlement: the external view of the chain and the ability to prove that. We have a validation function based on the previous state, next state, execution layer and data availability

Consensus depends on:

  • data availability: there are different options where the data lives
    • pushed into Ethereum mainnet (batch data into tx’s)
    • use blobs for efficiency
    • move it to other chains (i.e. Celestia)
  • derivation: derive L2 payloads from anything on L1. We pick up details from L1 and use them in L2 (i.e. block numbers etc.). L1 has security features that we might want to take advantage of.

Rollup Stages

They indicate the maturity of the L2.

  1. Stage 0 – Full Training Wheels: the rollup is run by the operators but there is a source available that allows the reconstruction of the state from the data posted on L1
  2. Stage 1 – Limited Training Wheels: the rollup transitions to being governed by smart contracts. There is a fully functional proof system, decentralization of fraud proof submission, provision of user exists without operator coordinator
  3. Stage 2 – No Training Wheels: final stage

Agnostic Layer 2 Transaction Lifecycle

  • Single Sequencer: the default for the OP
  • Multiple Sequencer

ZKStack

  • Madera from Starkware is focused in providing a sequencer that can be used for L3
  • OP stack is harder to have interoperability
  • ZK stack: the prover has lower memory requirements

Validating Bridges and Rollups as a Scaling Solution for Cryptocurrencies

On Wednesday, we had a guest speaker, Patrick McCorry from Arbitrum.

A bridge from Ethereum to FTX: we have a deposit() function, a withdraw() and allowance(user, coins). There is trust assumption, before processing a withdrawal I need to check the database is OK (off-chain database / liabilities).

With a validating bridge, the executor must submit convincing evidence to update the state: update(proposed_update , evidence). Rollups don’t scale Ethereum, but extend the security of Ethereum.

The sequencer waits around for more off-chain transactions. Eventually the sequencer decides the final order and post it.

Rollups

  • The sequencer only orders transactions. They can be 2-3 parties
  • The executor takes the transactions and executes them. They should be an open set (anyone could be an executor)

What data needs to be publicly available?

  • transaction history: enforces the ordering of all tx’s and its execution. The honest party computes all tx’s to get a copy of the database
  • state diffs: bridge is not aware of individual transactions, just their aggregation. The honest party computes all state diffs to get a copy of the database (updates storage slots). I.e. zkSync uses state diffs

How do we guarantee the data is publicly available?

  • on-chain data availability challenge
  • comittee
  • rollup: post all the data to the blockchain

The State Transition Integrity (protecting the layer-2 database)

Fault Proofs vs Validity Proofs

Enforcing censorship resistance

Force inclusion: or send it to the contract directly

Fragmentation of assets:

  • liquidity issues across databases
  • competing bridges for the same asset

Computational Integrity: know that the Cairo program was computed correctly – go through transformations from the trace of the program to the proof.

  • Arithmetisation: taking our trace and turning into a set of polynomials
  • Then, the prover attempts to convince the verifier that the polynomial is of low degree
  • The verifier is convinced, i and only if the original computation is correct (probabilistic)

Arithmetisation for Stark

  1. Generate an execution trace and polynomials constraints
  2. Transform these two objects into a single low-degree polynomial

Our plan is to:

  1. Rephrase the execution trace as a polynomial
  2. Extend it to a large domain
  3. Transform that, using polynomial constraints, into yet another polynomial guaranteed to be of low degree if, and only if the execution

Decentralized Sequencers

  • collect transactions
  • prioritize transactions
  • process transactions by sending them to an executor
  • initial validation and acceptance
  • send execution results to a prover for validity rollups
  • batch transactions and send transaction data to the data availability layer

Splitting out the role would be:

  • Sequencer: propose transaction batches and submit those
  • Aggregator: checks the validity of the batches and organises the generation of the proof

Wormholes

  • Force inclusion

Leave a comment