# Request for Proposals: Decentralized Prover Coordination
**URL:** https://forum.aztec.network/t/request-for-proposals-decentralized-prover-coordination/2397
**Category:** Aztec
**Tags:** rfp
**Created:** [October 12, 2023, 6:20pm UTC](https://forum.aztec.network/t/request-for-proposals-decentralized-prover-coordination/2397 "2023-10-12T18:20:20Z")
**Posts on this page:** 10
**Page:** 1
### Author:  [@cooper-aztecLabs](https://forum.aztec.network/u/cooper-aztecLabs)
#### Post date: [October 12, 2023, 6:20pm UTC](https://forum.aztec.network/t/request-for-proposals-decentralized-prover-coordination/2397/1 "2023-10-12T18:20:20Z")
The next version of Aztec will be launched as a fully decentralized network. Community discussion and feedback both play a vital role in decentralization, and one of our goals is to build Aztec as transparently as possible. For key network decisions, similar to the [Sequencer Selection RFP](http://forum.aztec.network/t/request-for-proposals-decentralized-sequencer-selection/350) and [Upgrade RFP](http://forum.aztec.network/t/request-for-proposals-upgrade-mechanisms/605), we will be following a call for proposals method allowing anyone to submit proposals.
Up next on our roadmap: Decentralized Prover Coordination Protocols
Below, you will find more information and learn how to get involved.
## Overview
Aztec is foundationally built on privacy-preserving, client-side zero knowledge proofs (ZKPs). These client-side ZKPs get aggregated and eventually submitted to Ethereum L1 for verification. This request for proposals is attempting to define which nodes (provers, in this case) within the Aztec Network get to work on which portions of a block. Now that the sequencer selection protocol [Fernet](https://hackmd.io/@aztec-network/fernet) is defined, everyone knows who the leader is for a particular slot, and also knows what the block’s contents are. Now the goal is to define what’s next, in order to complete the lifecycle of block production on Aztec.
## Problem Statement
Each transaction in the Aztec Network is submitted to the mempool with a ZKP of correct execution generated by its sender. Transactions may also run through public functions, which are executed by the sequencer in a [Public Virtual Machine](https://docs.aztec.network/concepts/advanced/public_vm) (VM), and need to be proven as well. These proofs follow a similar structure to private proofs: each function call is individually proven, and these are accumulated by a [public kernel circuit](https://docs.aztec.network/concepts/advanced/circuits/kernels/public_kernel). Without going into too many details, it suffices to say that each transaction will require 2N proofs to be generated, where N is the number of public function calls, of which the first N (VM circuit) can be run in parallel and the next N (public kernel circuit) needs to be run sequentially. The end result is that each transaction is represented by a single proof that covers both its private and public execution.
Each of these individual proofs are then aggregated into a binary tree of so-called “rollup” proofs, where each node in the tree proves the correct execution of its children. The root of the tree is then a proof for the correct execution of all transactions in the block. This root is then submitted to and verified on an L1 contract.
_Here is one example of what this could look like, from the [B52 sequencer selection proposal:](http://forum.aztec.network/t/proposal-sequencer-selection-b52-pbs-with-a-federated-prover-network/351)_
We are currently targeting a minimum of 1,024 txs per block, and potentially even scaling with available compute/provers (up to, for example, 61,440 txs per block). While there is still more work to do and benchmarks to run, consider that each proof takes roughly 30 seconds to be generated. It is conservatively estimated that the public VM circuit will require no more than 64gb RAM and 32 cores to generate a proof in that time, while the public kernel and rollup circuits will require 16gb RAM and 8 cores. The proof size is at most 32kb.
Note that generating each public execution proof requires the execution trace for that function, along with network state information. Generating the base rollup proofs (i.e., the leaves of the proof tree) requires the individual transaction proofs and potentially the full state of the network. The merge rollup circuits (i.e., the internal nodes of the proof tree) require only their child proofs, and the root rollup circuit requires its child proofs along with network state roots. This means that most provers will need to be stateful network nodes, or need to receive all the information needed from a trusted source.
Given these computing needs, we want to design a prover coordination protocol, compatible with the current [sequencer selection protocol](https://hackmd.io/@aztec-network/fernet), that will allow the Aztec Network to generate proofs for its blocks in a reliable way.
## Further Reading
[This post in our forum](http://forum.aztec.network/t/ideas-on-a-proving-network/724) covers some ideas and tradeoffs when designing a proving network. [“Decentralized Proving, Proof Markets, and ZK Infrastructure”](https://figmentcapital.medium.com/decentralized-proving-proof-markets-and-zk-infrastructure-f4cce2c58596) from Figment Capital is also a good read on the topic. It’d also be useful to become familiar with the [Fernet](https://hackmd.io/@aztec-network/fernet) sequencer selection protocol and the design decisions made within.
If you have any questions along the way, please ask in this forum post!
## Requirements
1. Compatible with the [Fernet](https://hackmd.io/@aztec-network/fernet) sequencer selection protocol
2. Permissionless
- Anyone can run an Aztec Prover
3. Defining who submits the completed work to L1
- Is a particular node responsible for submitting to L1? The sequencer? Or is it anarchy?
4. Ability to verify who generated which proof
- Could the protocol potentially slash provers who do not do their jobs properly? Or reward them? Alternatively, is it possible to achieve these goals via other means?
5. Graceful recovery
- If X% of provers stop suddenly, can the network easily get back to “health”?
- How long does it take?
6. Graceful reorg resilience
- In the event of a reorg, can the network keep moving forward/progressing?
- Can the network reorg without losing Fernet’s preconfirmations?
7. Flexible for future cryptography improvements
- Does this enable the network to always use the latest relevant cryptography? At least, as much as the network’s defined [upgrade mechanism](http://forum.aztec.network/t/request-for-proposals-upgrade-mechanisms/605) allows?
8. Scaling with available compute
- If more compute (i.e., provers) is added to the network, can the protocol expand transaction throughput capacity to match?
9. Clearly articulated incentives for participants
- Can participants in this proposal be incentived or rewarded for their efforts?
- Note that it is not expected that the incentives are _fully_ defined, moreso to ensure that they are feasible to implement.
- Can other participants (e.g., sequencers) be rewarded in the event of a reorg?
10. Clearly articulated protocol parameters
- Are there any design considerations made within the protocol that may want to be changed over time, such as the maximum block size? Minimum number of provers needed? Minimum stake deposit requirements? The time to build each proof, e.g., the duration of the proving phase? etc.
#### Potentially nice to have features
1. Privacy for the partipants in the proving protocol
- Can others identify that I was a prover for a particular block?
- What about a particular transaction?
- Does this change ability to slash, or distribute rewards?
2. Ability for sequencers to produce proofs by another means
- As the current sequencer, if the proving network (&/or protocol) is obviously censoring me, can I still produce a rollup?
- It is unclear if this is fully necessary and therefore a “nice-to-have” that is potentially worth exploring!
## Submission Format
To ensure consistency and facilitate the review process, kindly adhere to the following format:
**Title:** A concise, descriptive title for your proposal
**Summary:** A brief, easy to understand summary of your proposal (about 300 words)
**Comparisons:** Explain what makes this solution unique and different from alternative solutions
**Details:** Explain the prover coordionation protocol, its components (including parameters), and its functionality
**Questions:** Any outstanding questions
Submissions should be created as a new post on this forum, tagged provers and RFP. Once the new post is created, please refer back to this RFP and post the link to your proposal as a comment.
## Submission Deadline
The deadline for submissions is Friday November 3rd, 2023.
## Grants
Complete proposals may be eligible for a retroactive cash grants and swag.
## FAQs
We anticipate that you may have questions regarding the call for proposals. The following frequently asked questions and their corresponding answers should provide some clarification. Otherwise, feel free to post a question in the forum, contact [cooper@aztecprotocol.com](mailto:cooper@aztecprotocol.com), or follow us on [Twitter](https://x.com/aztecnetwork) (or X..? are we saying that now?) for updates.
**Q1. How will a proposal be chosen?**
A1. Proposals will be evaluated based on their adherence to the requirements and design considerations, as well as the quality, feasibility, and innovation of the proposed solutions. The selection committee, consisting of Aztec Labs team members and possibly external stakeholders, will determine the winning proposal and share the chosen solution publicly.
**Q2. Who can submit proposals?**
A2. Anyone!
**Q3. May I submit more than one proposal?**
A3. Yes, you may submit multiple proposals if you have different ideas for proving coordination protocols.
**Q4. What if my proposal does not fully meet the requirements?**
A4. We still encourage you to submit your proposal and participate in the discussion, as your ideas could contribute valuable insights and help shape the final solution.
### A note on network incentives & fees
The fee structure for the network is still being designed, but it is safe to assume that each transaction will carry a fee that should cover all its costs, proving included. Inflationary block rewards are also a valid option to consider as part of the proposal.
## Acknowledgments
Thank you to [Palla](https://twitter.com/smpalladino) for your contributions to this post.
Thank you to Jakob & Jamsheed at [BlockScience](https://block.science/) for your feedback as well.
## DISCLAIMER
The information set out herein is only conceptual and describes Aztec’s future development goals. In particular, the network roadmap is being shared in order to outline some of the plans for Aztec and is provided solely for informational purposes only and does not constitute any binding commitment. Please do not rely on this information for any purpose - the development, release, and timing of any products, features or functionality remains subject to change.
---
### Author:  [@spalladino](https://forum.aztec.network/u/spalladino)
#### Post date: [October 12, 2023, 7:23pm UTC](https://forum.aztec.network/t/request-for-proposals-decentralized-prover-coordination/2397/2 "2023-10-12T19:23:42Z")
Getting the ball rolling with [A cooperative proving network for Fernet](http://forum.aztec.network/t/proposal-cooperative-proving-network-for-fernet/2400).
---
### Author:  [@Anon](https://forum.aztec.network/u/Anon)
#### Post date: [October 12, 2023, 8:30pm UTC](https://forum.aztec.network/t/request-for-proposals-decentralized-prover-coordination/2397/3 "2023-10-12T20:30:21Z")
> [@\[Proposal\] Provers: Bonded Prover Auction](http://forum.aztec.network/t/proposal-provers-bonded-prover-auction/2401):
>
> Summary Use proposers to run an auction for proof production. This proposal is compatible with both [PBS](http://forum.aztec.network/t/proposal-pbs-proposer-builder-separation/2283) and [Fernet](http://forum.aztec.network/t/proposal-sequencer-selection-fernet/533). Context Monero has a [decentralized mining pool](https://p2pool.io/), which uses a second blockchain to coordinate work. This proposal defines a fair structure under which such work pools may be created. Highly-available decentralized networks are expected to have the cheapest access to capital and compute, assuring liveness without adding complexity to the core protocol. Details (init) provers depos…
---
### Author:  [@cooper-aztecLabs](https://forum.aztec.network/u/cooper-aztecLabs)
#### Post date: [October 18, 2023, 10:23pm UTC](https://forum.aztec.network/t/request-for-proposals-decentralized-prover-coordination/2397/4 "2023-10-18T22:23:46Z")
> [@\[Proposal\] Prover Coordination: Sidecar](http://forum.aztec.network/t/proposal-prover-coordination-sidecar/2428):
>
> Sidecar Proving Proposal Summary I propose that we facilitate a very basic commitment and slashing scheme to delegate and coordinate proving rights for a given Aztec block. It’s expected that the sequencer chooses among a variety of 3rd party proving quotes, facilitated via an out of protocol marketplace. The Prover gets decided and signaled to the community by a staked proverDeposit on L1, paid for by the current sequencer. Proving then runs as a “sidecar” to the protocol, eventually published …
---
### Author:  [@jaosef](https://forum.aztec.network/u/jaosef)
#### Post date: [October 20, 2023, 3:51pm UTC](https://forum.aztec.network/t/request-for-proposals-decentralized-prover-coordination/2397/5 "2023-10-20T15:51:24Z")
> [@\[Proposal\] - Staking Proving Network for Fernet](http://forum.aztec.network/t/proposal-staking-proving-network-for-fernet/2439):
>
> warning This post is outdated. For the latest block production design refer to [this post](https://forum.aztec.network/t/request-for-comments-aztecs-block-production-system/6155). Staking Proving Network for Fernet Overview This document proposes a cooperative proving network, with two explicit goals: Ensuring that the role of sequencer and prover are 100% divorced to minimise the centralising forces that can arise from this. Better incentivising stakers, and ensuring sequencer machines are not idle when not proposing The proposal achieves these goals by re-using the existing s…
---
### Author:  [@cooper-aztecLabs](https://forum.aztec.network/u/cooper-aztecLabs)
#### Post date: [October 25, 2023, 4:53pm UTC](https://forum.aztec.network/t/request-for-proposals-decentralized-prover-coordination/2397/6 "2023-10-25T16:53:52Z")
> [@\[Proposal\] - Fernet on the Rocks](http://forum.aztec.network/t/proposal-fernet-on-the-rocks/2460):
>
> Fernet on the rocks - Sequencer-Prover Consolidation Proposal Summary This proposal has one goal: unify the role of sequencers and provers in Aztec, maximizing protocol simplicity. Specifically in the context of [Fernet](https://hackmd.io/@aztec-network/fernet) (a random leader election), I outline the most simple version of block production possible. The sequencer can only propose blocks that they have the ability to prove themselves. Their “proving period” begins immediately after the [proposal phase](https://hackmd.io/@aztec-network/fernet#Proposal-phase), and must end within the specified w…
---
### Author:  [@cooper-aztecLabs](https://forum.aztec.network/u/cooper-aztecLabs)
#### Post date: [October 25, 2023, 5:01pm UTC](https://forum.aztec.network/t/request-for-proposals-decentralized-prover-coordination/2397/7 "2023-10-25T17:01:05Z")
[[Proposal] - When the levee breaks](http://forum.aztec.network/t/proposal-when-the-levee-breaks/2457) by @PhilWindle
---
### Author:  [@ellie](https://forum.aztec.network/u/ellie)
#### Post date: [November 6, 2023, 12:43pm UTC](https://forum.aztec.network/t/request-for-proposals-decentralized-prover-coordination/2397/8 "2023-11-06T12:43:07Z")
> [@\[Proposal\] - Cooperative BFT proving using striped, redundant binary trees](https://forum.aztec.network/t/proposal-cooperative-bft-proving-using-striped-redundant-binary-trees/2515):
>
> Summary I propose a cooperative proving network with minimal alterations to Fernet. Provers are randomly from the stake table using a VRF. The proving network is a series of redundant binary trees that build the root proof in parallel. Provers inside the binary tree send their proof chunks across trees to compensate for Byzantine provers. The proving network can be parameterized for f faulty provers out of n total provers. If the sequencer does not distribute the data to provers in a timely…
Admittedly this proposal is a bit late - my sincerest apologies for this! I wasn’t aware of this RFP until the day of the deadline. I fully understand that this makes it ineligible for the RFP. However, I wanted to post my (slightly hasty) thoughts since I think this is an interesting distributed systems problem. This proposal does not offer any new ideas, but rather combines interesting ideas from others in a (hopefully) useful way.
---
### Author:  [@cooper-aztecLabs](https://forum.aztec.network/u/cooper-aztecLabs)
#### Post date: [November 7, 2023, 1:54pm UTC](https://forum.aztec.network/t/request-for-proposals-decentralized-prover-coordination/2397/9 "2023-11-07T13:54:57Z")
> [@\[Proposal\] AIP-01 Enhancement of Prover Incentivization and Dynamic Scaling in the Aztec Network](https://forum.aztec.network/t/proposal-aip-01-enhancement-of-prover-incentivization-and-dynamic-scaling-in-the-aztec-network/2513):
>
> Autor: Pintea Tudor Summary: This proposal introduces a dynamic scaling mechanism for prover workloads and an enhanced incentive structure to optimize network performance and reliability. By adjusting prover requirements based on network demand and introducing a tiered reward system, we aim to ensure high availability and efficiency while maintaining decentralization. Additionally, we propose a flexible emergency mode activation and a novel approach to proof batching that adapts to network con…
---
### Author:  [@cooper-aztecLabs](https://forum.aztec.network/u/cooper-aztecLabs)
#### Post date: [November 7, 2023, 1:55pm UTC](https://forum.aztec.network/t/request-for-proposals-decentralized-prover-coordination/2397/10 "2023-11-07T13:55:18Z")
> [@\[Proposal\] Decentralized Prover Network (Staking, Reputations and Proof Races)](https://forum.aztec.network/t/proposal-decentralized-prover-network-staking-reputations-and-proof-races/2489):
>
> Authors: [Norbert](https://github.com/vadasnorbert), [Nilu](https://github.com/niluferokay), [Rachit](https://github.com/rachit77) Special thanks to Barnabé Monnot (RIG/EF) for his review and suggestions. Summary We propose a simple mechanism that enables decentralization, permissionless entry, liveness and cost-efficiency. It’s an in-protocol mechanism that integrates staking for eligibility and slashing as a security mechanism to disincentivize malicious behavior. It also employs reputation score to measure prover uptime and failures. The provers are selected through a VRF from a pool with…