Succinct 백서 전문

l to partic- ipate in the auction outright can form proving pools in which they can collectively bid for request slots, akin to mining pools in Bitcoin. We introduce the notion of proving pools, which are composed of many provers who jointly pool their capacity to bid in the proof contest mechanism. Pools allow provers with home setups to start generating proofs without having having to learn how to bid in auctions, by allowing for permissionless, bidding-free coordination. This allows the network to bootstrap a global distributed proving cluster that can be joined by anyone. Proving pools can serve as a counterweight to the potentially centralizing effects of specialized hardware and economies of scale. We depict the network with proving pools in Figure 7. Permissionless proving pools. Because members of proving pools do not nec- essarily have to participate in bidding, pools can themselves be permissionless and require minimal sophistication for home provers to join. Pool operators have an op- portunity use free market forces to aggregate proving capacity across the world and earn fees. Pool fees can be paid out in a fashion similar to Bitcoin mining pools, by querying pool members for capacity and paying them a fraction of fees based on the share of the total capacity they provide. The distributed, global nature of proving pools is a key hallmark of the network. Pools can be competitive. Proving pools have the additional benefit that they do not require the large upfront capital costs incurred by hardware teams to get started. Pools can set incentives to cause proving capacity to come online during times of high demand and go offline when there are relatively few proofs. Pools also do not face recurring operational costs such as utilities and rent if pools are primarily composed of home provers. Pools can search for capacity in low cost of electricity areas. Therefore, it is expected that well-run proving pools can remain competitive with hardware teams and optimize their operations, incentivized by the prospect of earning fees. This is similar to how mining pools in proof-of-work cryptocurrencies remain competitive. 17 Figure 7: Proving pools can dramatically expand the network’s capacity and enable home provers to join without bidding. Proof delegation. Pooling also allows for delegation of proving capacity to multi- ple pools. This means that provers with home setups can express their risk preferences by participating in pools that bid more or less aggressively in the mechanism. Pools can coordinate proving capacity depending on their needs. This model resembles dele- gation found in proof-of-stake currencies and especially in decentralized staking pools; it is expected that instruments to pool the risk of proving will arise with the emergence of global proving pools. 4 Network Architecture Having introduced the proof contest mechanism, we now turn to the question of how to implement the network in practice via an application-specific blockchain. We first illus- trate the desired properties of the network and how proof contests can be realized, and demonstrate that the implementation necessitates an application-specific blockchain. Next, we describe the architecture and how users and provers can participate; the architecture is depicted in Figure 8. 4.1 Implementation Requirements Any implementation of the proof contest mechanism for a network that assigns proof requests to provers should satisfy the following: 1. Low latency : The implementation needs to coordinate payments, bidding, and proof fulfillment. It is therefore essential that the system be low latency and high throughput. 18 Figure 8: Succinct Network architecture. 2. Censorship resistance : The implementation should afford downstream appli- cations censorship resistance guarantees for their requests. 3. Liveness: For some applications, delayed proofs can cause meaningful economic damage. The implementation should reliably, and with high liveness coordinate proof requests and fulfillment. For these reasons, we choose to coordinate users and provers via an application- specific blockchain as opposed to a system that runs on trusted intermediaries to coordinate proofs. The blockchain serves to provide censorship resistance and de- centralization required for downstream applications. Users submit requests to and provers bid and fulfill proofs on the blockchain. The blockchain is codesigned with SP1 to make fulfilling and verifying proofs seamless and to prevent spamming and other griefing vectors. It can be implemented as a modern layer 1 or rollup and is designed for progressive decentralization; the implementation details are outside the scope of this whitepaper. Permissionless participation and payments mean that any- one can bridge funds directly to the blockchain and begin requesting proofs, making for a desirable user experience. 4.1.1 Performance The blockchain is designed to be performant and to minimize excess latency in proof fulfillment. With short blocktimes, proof contests can be conducted quickly for each request. Bidding can take place in a short, preassigned window. The blockchain also benefits from ephemeral data storage, where data associated with proof requests can be temporarily stored. 4.1.2 Consensus The blockchain is designed for progressive decentralization, whereby requests can be given robust censorship resistance and liveness guarantees via nodes that operate the 19 network and come to consensus on requests, bids, and proof fulfillment. If imple- mented as a modern layer 1, this is done by having a decentralized validator set for the blockchain. If implemented as a rollup, this means having a decentralized sequencing layer that can come to agreement on the ordering of requests. 4.2 Participation There are two main parties in the network: users, who submit proof requests, and provers, who fulfill proofs. There are third parties called relayers who provide services that enhance the user experience, such as simulating program execution. We describe how users and provers participate (the role of relayers is described in Appendix A). 4.2.1 Users: Submitting Requests Users submit proof requests to the network by inputting a program, inputs stdin, a max_cycles parameter, the maximum fee fj, the deadline, and a vkey. The program and inputs are the data required by the prover to generate the proof. We provide additional details about how programs and inputs are stored in Appendix A. The quantity max_cycles is the maximum number of RISC-V cycles that the user expects the proof to consume and the fee fj is the maximum amount that the user wants to pay for the request. The fee can be independently set by the user or via suggestion from a functionality similar to gas estimation endpoints in Ethereum. Upon sending the request, the user’s fee is held in escrow to prevent griefing vectors. Finally, the vkey is a key that is used by the verifier to check the correctness of the proof and is generated during an initial setup phase. A unique proof_id is created for every submitted request. Proof requests can be sent to the network via standardized RPC endpoints. From the user’s point of view, the network is a high liveness, competitive interface for proof requests. Once completed proofs have been submitted by provers, users can relay them to their destination chains directly from the network. 4.2.2 Provers: Bidding and Fulfilling Proofs Provers can permissionlessly participate in the network by simply plugging in their hardware and running node software which allows them to bid for requests. Provers may have capacity limits and operating costs to generate proofs, as shown in Figure 8, but these may not be revealed to the network; the bidding process helps elicit this information. Bidding and fulfilling requests happen on the application-specific blockchain. Provers begin by seeing proof requests that have been submitted and fetching program and input data. Bidding. Provers then bid for the right to complete requests in a proof contest that computes a clearing price and assignment. Proof contests are conducted onchain, after the request is visible. The bidding window is fixed ahead of time for transparency. The blockchain is designed to have short blocktimes to enable bidding at timescales much smaller than proof generation times. 20 Figure 9: The network scales decentralized applications via server-side proving and enables ubiquitous privacy via client-side proving. Fulfilling proofs. Once the assigned prover is finished completing their proof, they can fulfill it on the application-specific blockchain. The prover inputs the proof_id, the program, stdin, and proof information. The vkey submitted alongside the proof request allows a verifier to check that the proof was generated correctly. SP1 allows for three types of proofs to be generated: CORE, COMPRESSED, and GROTH16/PLONK. CORE proofs have size proportional to the program’s execution, whereas COMPRESSED proofs have constant size but are more expensive to generate. GROTH16 and PLONK proofs are the most expensive to generate and have the benefit of being highly compressed; they can be verified onchain. Due to the variable and large proof sizes of CORE proofs, the network allows requesters to request COMPRESSED and GROTH16/PLONK proofs. 5 Proving the World’s Software The network has significant implications for accelerating verifiability on the Internet. Verifiability means that applications can outsource expensive computation and busi- ness logic without relying on trusted intermediaries, and users can receive guarantees that sensitive information will remain private and that the execution of the computa- tion is correct. The aggregation of proving capacity under one permissionless, global network means that decentralized systems can face shared standards and scale with minimal overhead. This drives down prices and enhances the user experience, creating tailwinds for applications that use ZK. There are two main modalities through which a user can interact with the network: as a standalone server-side prover, or mixed with client-side proving, as depicted in Figure 9. Server-side proving is useful for applications that require specialized prover nodes to outsource computation, such as public blockchains and rollups. Client-side proving is useful for privacy applications that can hold user information private to generate a large proof that can then be compressed via the network. We now describe several applications that can be built using or enhanced by the network. 1. Rollups. The rollup-centric roadmap of Ethereum is increasingly shifting to using ZK technology for transaction verification, compared to the heavy use of 21 fraud proof technology in the past. As transaction demand for ZK rollups rises due to their low costs and ease of use, the number of proofs demanded will cor- respondingly increase rapidly. Rollups can use the network for proofs that are delivered with competitive prices and high reliability. This enables all decentral- ized systems to scale their throughput without sacrificing their verifiability. 2. Oracles and bridges. Other components of decentralized systems that can use the network include oracles and bridges. ZK oracles can trustlessly provide blockchains with inputs from external data feeds, and ZK bridges can enable interoperability between all blockchains. Crucially, a decentralized prover set is important for these applications as they cannot rely on a single point of failure. 3. Identity and authentication. The zero-knowledge property ensures that pri- vate user inputs can be incorporated into proofs without being revealed to anyone else. This is essential for applications that require privacy, such as identity and authentication, in which user inputs might involve sensitive identifying informa- tion. To make sure that these inputs remain private during the proving process, client side proving can be used in tandem with the network. 4. Credit scoring and auditing. Currently, businesses that perform credit scor- ing, notarization, or auditing have high operational costs and have to manage complex, legacy databases. Applications that use the network could massively reduce the costs in these operations by leveraging ZK proving to provide proofs as audits. 5. V erifiable inference. AI applications can use the network to prove the output of an AI model on a given set of queries to an end user. The network enables applications to receive a large quantity of proofs required for high throughput inference applications. 6. Coprocessors. Blockchains can use the network to have coprocessors that of- fload heavy computation to off-chain actors. This can allow blockchains to access historical data, compute fees with high-fidelity economic models, and allow third parties to query blockchains trustlessly. 7. Outsourced cloud computing. The network can be used as a generalized out- sourced computing layer. Users can send programs to provers that they would ordinarily run in cloud servers, if not for the trust assumptions and loss of veri- fiability that these servers bring. 6 Conclusion We propose the Succinct Network, a protocol for coordinating a decentralized set of provers to satisfy user requests for ZK proof generation via a competitive auction called proof contests to create a global-scale distributed proving cluster. The network is co- designed and integrated with SP1, a zkVM that allows for the proving of arbitrary deterministic Rust programs. Proof contests balance cost competition and prover de- centralization to allocate requests to provers and are settled on an application-specific blockchain that is specially designed to coordinate users and provers. The network 22 allows for permissionless entry as a prover and induces free market competition. It enables a broad infrastructure buildout for proof generation akin to other cryptoeco- nomic systems, and ensures that applications from blockchain scaling to privacy have access to robust, competitive proving. By using incentives to dramatically expand the proving capacity of the world, the network leads to low cost, low latency ZK proof generation for all. 7 Acknowledgments We would like to thank Tarun Chitra, Ciamac Moallemi, Dave White, and Max Resnick for valuable feedback on this paper. References [Nak08] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system . 2008. url: https://bitcoin.org/bitcoin.pdf. [But13] Vitalik Buterin. Ethereum whitepaper. 2013. url: https://ethereum. org/en/whitepaper/. [BS+13] Eli Ben-Sasson, Alessandro Chiesa, Daniel Genkin, Eran Tromer, and Madars Virza. “SNARKs for C: Verifying program executions succinctly and in zero knowledge” . In: Annual Cryptology Confer- ence. Springer. 2013, pp. 90–108. [BS+14] Eli Ben-Sasson, Alessandro Chiesa, Eran Tromer, and Madars Virza. “Succinct {Non-Interactive} zero knowledge for a von neumann ar- chitecture” . In:23rd USENIX Security Symposium (USENIX Secu- rity 14) . 2014, pp. 781–796. [Dra24] Justin Drake. [AMA] We are EF Research (Pt. 12: 05 Septem- ber, 2024) . 2024. url: https://www.reddit.com/r/ethereum/ comments/1f81ntr/comment/llmfi28/?utm_source=share&utm_ medium=web3x&utm_name=web3xcss&utm_term=1&utm_content= share_button. [GMR85] Shafi Goldwasser, Silvio Micali, and Charles Rackoff. “The knowl- edge complexity of interactive proof-systems” . In: Proceedings of the Seventeenth Annual ACM Symposium on Theory of Computing . 1985, pp. 291–304. [Halo20] The Zcash Team. Halo2. https : / / github . com / zcash / halo2. 2020. [Plonky22] PolygonZero. Plonky2. 2022. url: https://github.com/0xPolygonZero/ plonky2. 23 [Plonky23] Polygon. Plonky3. 2023. url: https : / / github . com / Plonky3 / Plonky3. [SP124] Succinct Labs. Introducing SP1: A performant, open-source, contributor- friendly zkVM . Feb. 2024. url: https : / / blog . succinct . xyz / introducing-sp1/. [Ben17] Juan Benet. Filecoin: A Decentralized Storage Network . Protocol Labs. 2017. url: https://filecoin.io/filecoin.pdf. [Wu23] Howard Wu. The Aleo Whitepaper . https://hackmd.io/@aleo/ HJRwnnhM6. Oct. 2023. [KB23] Assimakis Kattis and Joseph Bonneau. “Proof of necessary work: succinct state verification with fairness guarantees” . In: Interna- tional Conference on Financial Cryptography and Data Security . Springer. 2023, pp. 18–35. [BTT80] James Buchanan, Robert Tollison, and Gordon Tullock. “Toward a theory of the rent-seeking society” . In: Texas A&M University economics series (1980). [LS20] Jacob D Leshno and Philipp Strack. “Bitcoin: An axiomatic ap- proach and an impossibility theorem” . In: American Economic Re- view: Insights 2.3 (2020), pp. 269–286. [BGR24] Maryam Bahrani, Pranav Garimidi, and Tim Roughgarden. “Cen- tralization in block building and proposer-builder separation” . In: arXiv preprint arXiv:2401.12120 (2024). [NGR24] Michael Neuder, Pranav Garimidi, and Tim Roughgarden. On block- space distribution mechanisms . https : / / ethresear . ch / t / on - block-space-distribution-mechanisms/19764/1 . June 2024. A Network Architecture A.1 Data Storage In practice, the program and input data can be very large in size and therefore diﬀicult to store on a blockchain. To account for this, the network makes use of external ephemeral storage where request data can be stored. The artifact ids of the relevant data in ephemeral storage can be used as a proof of data availability and to query the program and stdin required for proving. With the emergence of large scale, onchain data storage , over time, all data required to generate a proof can be trustlessly transferred from requesters to all the provers. 24 A.2 Relayers Relayers are third parties involved in the network to improve the user experience and to give provers additional information they may need to fulfill proofs. Simulating programs. Relayers simulate programs to compute public_values, which are public inputs associated to the request. This simulation step prevents a prover from spending resources on invalid or misconfigured requests. Further, the upper bound on the cycle count, max_cycles, inputted by the user may be overly pessimistic. Relayers execute the program to compute exact cycle counts sj before provers to ensure that the amount of work taken up by the proof does not exceed the maximum cycle count. The presence of the relayer prevents several attack vectors that cause delays and ineﬀiciencies in proving, such as a prover realizing partway through proving that a given request is not possible to fulfill or that the realized cycle count is higher than expected. Relayer payments. Since relayers provide a commodity service for all the requests that enter the network, they are paid a flat fee for posting the results of simulation and cycle counts to the network. In practice, program simulation is a small fraction of the cost of generating a proof. Therefore, permissionless entry into the relayer role combined with a flat fee ensures that provers have access to the information they need and that the network progresses on proof fulfillment. To ensure that relayers truthfully report the results of the simulation step and the cycle counts, they stake collateral. Since provers also go through the simulation step while proving, it is simple to check that a relayer misreported their outputs. B Prover Competition The proof contest mechanism incentivizes provers to compete on the bids that they submit to the auction. In the setting where these bids provide rebates to users over time, we can compute the effective price the user receives by f −∑mk=1 b∗k. To illustrate how this price deviates from a model in which there is a competitive auction between the provers with no preference for decentralization, we compare proof contests to a second price reverse auction. In this auction, the provers simply compete to lower the price of the user’s trade as much as possible; the lowest bidding prover wins at the second lo