Week 15 & 16 Update

Over the past two weeks, we have successfully finalized and submitted our decentralized prover network proposal to Aztec: [Proposal] Decentralized Prover Network (Staking, Reputations and Proof Races)

In summary, we present an innovative mechanism that facilitates decentralization, encourages permissionless entry, ensures liveness, and enhances 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 the highest reputation score. The design has a backup mechanism for emergencies in times of prover failure and network congestion. The backup mechanism is proof racing in a more confined environment, which promotes competition and liveness. Other features like proof batching and distributed proving can be added on top of this simple design.

I'm finishing up the last touches for the final development update and getting ready for the project presentation. After Devconnect, my plan is to dive deeper into the simulation, making it more detailed to gather valuable insights. The goal is to make the system more detailed and to address important questions. Key aspects to be added include:

• Prover Efficiency (
  ${\gamma }_i$): The efficiency of each prover, indexed by 'i,' which scales the cost and proving delay. More efficient provers have lower costs and shorter proving delays.
• Cost to Prove a Batch (Ci(D)): The cost to prove a batch of size 'D' by prover 'i' is determined by a simple scaling factor:
  $C_i(D)=\frac{D}{{\gamma }_i}$. This means that the cost to prove a batch increases linearly with its size, but the scaling factor γi depends on the efficiency of the specific prover. More efficient provers (higher γi) have lower costs.
• Proving Delay (Ti(D)): The time it takes prover 'i' to prove a batch of size 'D' is also scaled by its efficiency:
  $T_i(D)=\frac{D}{{\gamma }_i}$. This means that the proving delay is directly proportional to the size of the batch, and more efficient provers (higher γi) can prove larger batches in the same amount of time.
• Proving Capacity: Given the time interval Δt, a prover 'i' can prove
  ${\gamma }_i\cdot \mathrm{\Delta }t$ units of data. This means that if a prover is active for Δt units of time, they can process data equal to γi times Δt.
• Prover Failure (
  $p$): There is a probability 'p' that any given prover may randomly fail to prove a batch. This probability represents the likelihood of a prover failing to complete its task successfully.