Front-Running the Aggregate

Blockchain Proof Verification

• ❌ costly
• ❌ large (with few exceptions)
• ❌ high verification latency
• ❌ non-streamable
• ❌ limited flexibility

Cost

• 200-300k gas is industry standard,
• This supports Groth16 / Plonk, but not much else,
• Other provers add a Groth16 wrapper, adding 2-10 mins latency.
• See dashboard

Verification Latency

• Some blockchains are relatively fast, so inclusion is quick,
• But on-chain verification economics lead to aggregation models, batching proofs to share costs,
• Examples: AggLayer, Manta, zkVerify, Hylé …

Size Constraints

• Proofs are execution inputs,
• Execution inputs are stored permanently,
• because full nodes re-execute to hold validators accountable,
• so transaction size (and thus proof size) must be <2KB.

Streamability

• Proofs often form a sequence (zkGames, zkBridges, etc.),
• Even recursive proofs need to ensure continuity, e.g. linking each move in the same game,
• stateless zkCoprocessors only partly address this need.

Universality

• Some exceptions exist!
• concurrent proofs step on each other's toes,
• Aleo and Mina provide flexible state but have limitations: validators manage proof conflicts,
• Their model implies vendor lock-in.

Proofcoin

• ✔ cheap
• ✔ compact (STARKs included)
• ✔ very low E2E verification latency
• ✔ streamable
• ✔ no vendor lock-in

2020: Byzantine-Resistant Broadcast

• Fastpay (Meta/UCL), Astro (EPFL), Brick (ETHZ)…
• Users propose blocks,
• Shard state via user-driven micro-chains,
• Use broadcast, not full consensus,
• Inspired Sui's SO object "fast lane",
• Extended by Linera, an Argument partner, for multi-user objects (& consensus) as an L1.

Proofcoin Transactions

• Single validator set for all tasks,
• Sharded state ➡ No conflicts,
  only relevant parties interact in games (e.g., zkBattleship),
• Each transaction is a proof advancing your shard's state,
• Allows asynchronous cross-shard messages with ordering guarantees.

A transaction on Proofcoin

sequenceDiagram
    participant Validator1 as Proofcoin Validator 1
    participant Validator2 as Proofcoin Validator 2
    participant ValidatorN as ... Proofcoin Validator n
    actor Client as Client (or intermediary)
    participant Node as Node (another blockchain)

    rect rgb(191, 223, 255)
    Client ->>+ Validator1: Proof
    Client ->>+ Validator2: Proof
    Client ->>+ ValidatorN: Proof
    end

    rect rgb(191, 223, 255)
    Validator1 -->> Client: Signature
    Validator2 -->> Client: Signature
    ValidatorN -->> Client: Signature
    end

    Client ->> Client: assemble (2f+1) majority certificate
    Client ->> Node: make transaction
    rect rgb(191, 223, 255)
    Client ->> Validator1: next Proof (+ certificate)
    Client ->> Validator2: next Proof (+ certificate)
    Client ->> ValidatorN: next Proof (+ certificate)
    end

Proofcoin transactions

Receive:

• a certificate
• in 1 WAN roundtrip, containing
• a commitment to your shard’s new state,
• a majority validator signature on proof validity.

Is Proofcoin a Side Chain?

• No! It’s a decentralized L2 with strong security,
• Validators aggregate and post proofs on Ethereum,
• They’re bonded and slashed on Ethereum if dishonest,
• Proofcoin certificate provides an instant cryptographic proof that front-runs the aggregate,
• Verifiable on any chain, no precompiles needed.

Proofcoin Highlights

• Parallelized proof verification (each validator scales horizontally),
• Shards are full-fledged blockchains but can be temporary,
• Lurk is the main "smart contract" language, but entirely optional,
• Flexible transaction storage duration,
• Settle anywhere after Proofcoin transaction.

Proofcoin

• ✔ cheap: parallel verification,
• ✔ compact w/ STARKs: pay only for necessary storage,
• ✔ low E2E latency: <500 ms,
• ✔ streamable: your own proof-driven chain,
• ✔ no vendor lock-in: Proofcoin involved in first 1s only.