Front-Running the Aggregate - HackMD

<style> .slides h1, .slides h2, .slides h3, .slides h4 { color: yellow } .slides ul { display: block!important; } </style> ![Argument_LogoSetup-02NEW](https://hackmd.io/_uploads/HJGZlfE1Je.svg) ---  # Front-Running the Aggregate ## Proofcoin as a New Paradigm for Security and Flexibility ---  ### [Argument](https://argument.xyz/) - creators of [**Lurk**](https://github.com/argumentcomputer/lurk): a micro-ZKVM, - a *direct* high-level language interpreter based on abstract machines, - safer (no compilation) and faster than CPU ISAs, - last release on Lisp, upcoming release on Ocaml, more coming soon™ - **not** the subject of this talk ---  ## Verifying Proofs - ✔ cheap - ✔ compact (SNARK: <2KB, STARK: 40-800KB) - ✔ fast verification - ✔ streamable (supports recursion: IVC, PCD) - ✔ universal (self-contained semantics) ----  ## 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](https://eth-groth16-dashboard-de81d88fe519.herokuapp.com/) ----  ## 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 ----  ## Proofcoin - ✔ cheap - ✔ compact (STARKs included) - ✔ very low E2E verification latency - ✔ streamable - ✔ no vendor lock-in ----  ## 2020: Byzantine-Resistant Broadcast - [Fastpay](https://arxiv.org/abs/2003.11506) (Meta/UCL), [Astro](https://arxiv.org/abs/2004.13184) (EPFL), [Brick](https://arxiv.org/abs/1905.11360) (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](https://linera.io/whitepaper). ----  ## 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 ```mermaid 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.