Owners: @Antonio @Giacomo Pasini

Introduction

This document tracks the design and development of the Sovereign Zones PoC based on the findings of the preliminary research outlined in https://www.notion.so/Preliminary-Sovereign-Zones-Research-1bb8f96fb65c803faee2d8ba9e5c7f51?d=1c38f96fb65c80d49219001c306bdbc4#1c08f96fb65c80dca314e57882503776.

Design

Components

A diagram with the interactions among the components will follow.

• Client: User-controlled wallet.
  • We can use existing solutions
• Sequencer: Has a mempool, batches txs, maintains global state, requests ZK proofs from the prover, exposes RPC endpoints, and post relevant data to Nomos DA
  • We need to write this
  • We can use existing solutions for the execution layer for EVM-compatible and EVM-equivalent proof systems
• Prover: generates ZK proofs for a given batch of txs
  • We can play with different existing provers, as long as they expose the same I/O interface
  • Some non Eth-compatible provers will come with their own executor and their EVM-to-ZK translation logic

Interactions

1. Client sends a tx to the sequencer
   • Via the eth_sendTransaction endpoint
2. The sequencer validates and tries to apply the tx using the underlying executor (e.g., revm)
3. If valid, the sequencer stores the tx in the mempool and returns the corresponding result to the client

After the logic to create a new batch and generate a proof is triggered (e.g., every minute, or every N txs):

1. The sequencer batches the latest unfinalised txs
2. The sequencer requests the prover to generate a ZK proof of the batch
3. The sequencer publishes the batch for which the proof was requested to Nomos DA
4. The sequencer waits for the ZK proof generation process to be completed
5. The sequencer stores the generated proof locally to serve it to interested clients