# Primev: a Blockbuilder Communication Network
## Table of Contents
[TOC]
### Actors
$$
builders := b_1, b_2, .. ,b_n\\
searchers := s_1, s_2, .. ,s_n\\
$$
Users include actors and any others who may utilize the network.
## Introduction
### What is Primev?
Primev is a domain-agnostic blockbuilder communication network. Primev's mission is to illuminate the blockbuilding and block confirmation process by sharing data about blocks being built, and allow actors to engage in execution bid/commit schemes with minimal trust using near real-time blockbuilding data. Primev network aims to solve for coordination inefficiencies that continue to arise in blockchain ecosystems as more roles are introduced into systems such as the MEV pipeline and more solutions arise for increased decentralization and censorship resistance.
### Why Primev?
Through our experience developing products for the Ethereum and broader crypto ecosystem, we've learned that users want to interact with networks as a whole as opposed to single actors that represent some % of the network, which is challenging to provide in decentralized systems that have goals beyond basic user needs. We believe a transparent protocol that can serve as the rails for an interface between actors to engage in bid/commit schemes related to their interactions with Ethereum and other blockchains can bridge this expectation gap while preserving Ethereum's generalized goals. In other words, preferences and intentions can be communicated in greater detail on Ethereum or other out of protocol methods over time, but how Ethereum or other protocol actors may meet those preferences may be communicated over a specialized network such as Primev that can bring those actors together for specific purposes. This will ensure that users are not only able to convey their needs to a blockchain network, but monitor the executors of those needs so they can confidently take actions based on their expectation being satisfied or not.
We're constructing Primev to be aligned with the ethos of the crypto ecosystem, specifically the vision being laid out by the Ethereum Foundation, and out of protocol services that supplement that vision such as the current MEV pipeline largely introduced by Flashbots. We don't aim to design an auction, or improve auctions mechanisms directly, and we don't aim to design a different MEV pipeline. Starting with builder hints, we are creating new avenues for efficiency in solving coordination problems between actors that can be used to have an expectation matching experience when engaging in the existing auctions and MEV pipeline. We plan to continue supporting Primev's evolution and adoption according to this mission as the existing landscape shifts and new paradigms are introduced.
## Use Cases
While accessing execution data in real-time can be used in many ways and we encourage the MEV community to develop different execution apps using Primev, we envision a few immediate net-new use cases we will optimize the protocol for:
### Inclusion Proofs & Indexed Execution
Primev's data layer uses a pubkey-based mechanism to authorize direct connections between builders and searchers, proving ownership of that address upon successfully establishing a connection. This authentication method can be leveraged to customize the data layer for the connection, and append merkle inclusion proofs to the shared payload for any matching transactions in the block, allowing connecting searchers to get transaction receipts from blockbuilders in real time. These receipts prove the presence of a transaction within a block template, but can't be used to infer guaranteed inclusion as the blockspace auction continues over the block slot. The pre-confirmation use case outlined below can be utilized to have the builder commit to keeping the transaction in their block.
Similarly, the builder can report the block index of a given transaction with its inclusion proof, and the searcher can use this to confirm their execution preference. The post-inclusion phase of a transaction is an important part of providing a more reliable execution experience for users. Primev's data layer will be increasingly important for users to consume as they convey richer inclusion criteria to builders and then rely on Primev to provide receipts and confirmations to receive real time feedback on meeting their expectations.
### Pre-confirmations
Prior to The Merge, it was sufficient to increment `priorityFee` introduced by EIP-1559 to gain probabilistic confirmation guarantees across the network. With the introduction of blockbuilding and PBS, we present that a novel bid mechanism "pre-conf" is the most efficient way to have a coalition of blockbuilders commit to including a transaction for a given slot, allowing users to engage in pre-confirmation bids. Users can leverage pre-confirmation bids to source an intra-block execution guarantee for their transaction over Primev.
This additional bidding mechanism, as facilitated by a high throughput network such as Primev, offers advantages ranging from a better user experience to unlocking increased liquidity for Primev enabled networks. By enabling users to submit bids directly to Ethereum blockbuilders, Primev creates an additive and dynamic market for transaction execution commitments that can result in increased block value represented by pre-confirmation bids. Users on Ethereum are currently able to bid for next block confirmation, and we pose that providing pre-confirmations will unlock additional value for the MEV and transaction pipelines on EVM networks.
The capacity to submit pre-confirmation bids as transactions on the Primev network, emanating from distinct addresses separate from those on Ethereum, bolsters the pseudonymous nature of bidder identities, aligning the system for privacy protections. This novel framework also permits any participant including EIP-4337 paymasters to contribute pre-confirmation bids or gas fees for transactions agnostic to their originator, provided they possess the transaction's hash. This feature paves the way for account abstraction within the fee mechanism on the Primev network, ultimately promoting greater flexibility and adaptability for users and service providers including dapps, wallets, and infrastructure providers in participating networks.
### Multi-transaction and Multi-chain Flash loans
Trade financing is a large problem in traditional finance but blockchain ecosystems especially, and is mainly addressed by financing agreements and investment partnerships off-chain, and with DeFi loans and flashloans on-chain. One of the key requirements of flashloans is that while virtually unlimited, the loan is atomic and paid off at the end of the same transaction. This provides much needed on-demand liquidity for single transactions, but there is no such mechanism to do this across multiple transactions, across an entire block, or across domains. The primary reason is that it's difficult to enforce the payback of the loan when the system does not exert control over the entity.
Since blockbuilders are able to see into the execution process of their builder instance, actors may engage in flashloan schemes that span multiple transactions and more, enforced by the builder and monitored by Primev. If the builder doesn't make sure the built block is sound in terms of the loan being paid back, or act in other means against the best interest of the protocol, then Primev can slash their stake. Moreover, builders may communicate about the underwriting and the enforcement of the loan terms over Primev to ensure the outcome is in the protocol's best interest.
Single transaction flashloans are sourced through lending protocols with liquid pools like Aave. For multi transaction flashloans we suggest a shared builder pool of funds that can be loaned to actors according to protocol rules, which can be supplemented by Primev's protocol revenue. A collaboration with lending protocols or re-staking mechanisms such as Eigenlayer can be leveraged in the future to further the efficiency and availability amount of the pool of funds.
A decentralized flashloan system minimizes both the economic risk a single builder might take and the regulatory burden a centralized system would have which would require necessary licensing for each country it operates in. Providing this service would create a new revenue opportunity for the protocol and the actors involved, and allow additional liquidity to be brought to Primev-enabled domains. We expect most of the additional value to flow downstream to Ethereum validators as builders can use it to prop up the value of their blocks.
### Order flow exchanges
One of the most compelling ways a blockbuilder communication network can be leveraged is to further the decentralization of blockbuilding for generating more valuable blocks. We devise a mechanism leveraging MPC technology on the block value received by Primev enabled builder instances to compute which builder has the most valuable block. Builders can configure their Primev instance and specify when they would like to engage in a block value comparison during the block slot. Once the process runs and the result of the comparison is known by participating builders, they can exchange their orderflow with the builder with the most valueable block. This creates network welfare, as:
1. More users from the builders' combined set will secure next block inclusion
2. The resulting block from the exchange will in most cases be more valueable than what the buying builder has built, while giving additional rewards to its proposer
3. The orderflow selling builder can receive some payment from the winning builder who can commit to a payment using a signature, whereas otherwise they would've made no revenue from their uncompetitive block
We plan to use the MPC primitive within the Primev instance for other data sensitive bid-commit schemes between competing MEV actors in the future, including the creation of megabundles for searcher bundles that share liquidity pools or other shared execution patterns.
## Protocol
Primev's core software is a blockbuilder sidecar module that can receive block templates as they’re built, and share and attest to relevant information about the block in near real-time without compromising the privacy of the underlying transactions. Data remains inherently private to external parties as Primev instances are ran by blockbuilders in their own environment, and Primev will let actors share proofs about sensitive data such that they can engage in bid/commit schemes on data they want to remain private.
We devise meeting the above vision with a network that has 3 key components:
1. **Data Layer**: Includes blockbuilding metadata, execution data, and builder hints. We further incorporate the use of cryptographic primitives on sensitive data blockbuilders want to remain private.
2. **Integrity**: An integrity protocol that ensures participants in the network run honest computation so actors can operate with other layers with minimal trust assumptions.
3. **Bid/Commit Schemes**: Participating in Signature and Transaction based economic execution games with actors on Primev based on shared data and attestations.
### Data layer & Builder Hints
While a block slot is 12 seconds on Ethereum, blockbuilders run their auctions and compute block templates much more frequently. This data is only visible to each blockbuilder today, and there is no network level view of the concurrent execution process. We propose a sidecar data module to builder instances that receives block templates as they're built and computes metadata and metrics about the block that can be subscribed to by other MEV actors.
In order to access this data, actors need to stake some ETH on the Primev network that the builders who share data with them can charge them for in order to open and maintain a connection to that builder instance. This is not only important for the sustainability of the network, but also acts as a sybil resistance mechanism that adds monetary friction to increase the cost for latency games and concurrent connections that hinder builder performance.
We abstract the searcher pubkey using a signature method to preserve searcher privacy. For builders, the privacy of the underlying transaction data and the blockbuilder auction remains unaffected directly, and the data payload only shares metadata and metrics about the block templates. An example payload may look like:
```
"block": {
"builder": "0x8888...abc",
"templateNo": 1,
"templateTimestamp": "2023-01-31T16:06:29.511Z",
"number": 16522248,
"blockHash": 0x1ee6ff67e361f05cd6cf95b9bc2e35061cc4bf65861a1206249cef0be1473afc,
"baseFee": 23,
"transactions": {
"count": 200,
"MinPriorityFee": 25,
"MaxPriorityFee": 7000
}
}
```
#### Malicious builders
Blockbuilders have an incentive to mischaracterize the block template characteristics they share to convince their users to increase their fee bids, or throw off other builders. We propose a builder integrity mechanism that leverages cryptographic techniques to create a trustless builder network, and aligns builder incentives with other actors in the network.
Once actors can trust this data, it can be used to engage in economic bid/commit schemes where searchers and other users can submit bids that adheres to logic and blockbuilders can provide execution commitments against to those bids.
Note that we intend to launch the network with existing blockbuilder trust assumptions as we incorporate the integrity mechanism and progressively decentralize all aspects of the network. The data layer is peer-to-peer between actors and is decentralized at the moment of Primev's inception.
### Integrity Sampling using Verifiable Delay Functions (VDFs)
To prove the integrity of messages and commitments over the Primev protocol, we propose a scheme where builders are randomly sampled and the integrity of their data is verified after some delay, allowing trustless operation by actors based on data shared without revealing the underlying transactions which stops the possibility of MEV stealing during the slot.
Builder integrity is an important piece for the protocol for permissionless scaling and work with lesser trust assumptions on the path to decentralization. We plan to upgrade Primev's integrity mechanism in the future to provide continuous attestations for each computation as zk technology matures.
#### Node Selection and Proof Generation
1. **Random Node Selection**: Primev will leverage the RANDAO approach present in Ethereum consensus layer (CL) to randomly prompt a node within the network to generate a proof. This maintains mechanism alignment with Ethereum and the inheritance of its robust unpredictability features.
2. **Snapshot-Based Proof Generation**: When a node is prompted, it creates a snapshot of the current block template and the builder hints computed from it. This snapshot serves as the basis for generating the VDF proof, ensuring consistency despite potential changes during the block slot and the delta between the template and the eventual confirmed block data.
3. **VDF Algorithm**: We will employ an efficient VDF algorithm, such as the RSA Group VDF (Wesolowski) or Class Group VDF (Pietrzak), to generate deterministic proofs that are both quick to create and fast to verify. Selection randomness and interval will ensure Primev instances don’t continuously consume proof resources.
#### Proof Submission and Verification
1. **Proof Submission**: The selected node submits its generated VDF proof to the rest of the network. This proof is then included in the next Primev block, and anyone on the network can access it to check its validity.
2. **Fraud Proof:** Actors on the network can submit a fraud proof to slash the builder that submitted the VDF proof. We envision a portion of the slashed funds being shared with the fraud proof submitter to incentivize protocol-aligned behavior.
A VDF proof essentially serves as a commitment to a specific block data snapshot at a particular time. The proof attests that the selected node has performed the required computations within the assigned delay period.
Consider the following scenarios for how one can detect fraud using a VDF proof:
1. **Incorrect Proof**: Suppose a malicious node submits an incorrect VDF proof, either by deliberately manipulating the block data or by calculating the proof faster than it should have. In these cases, when honest nodes in the network attempt to verify the VDF proof against the confirmed block data, the verification will fail, revealing the dishonest behavior.
2. **Proof from a Different Snapshot**: If a malicious node attempts to provide a VDF proof generated from an earlier or different block snapshot than the one it was assigned, honest nodes can still detect this fraudulent activity. Because VDFs are deterministic and tied to the specific input, the proof will not match the expected output based on the confirmed block data.
To prove fraud using the VDF proof, we rely on network participants who can be node operators or consumers of data to perform the following steps:
1. Compare the submitted VDF proof with the snapshot data. If the proof is valid, it must match the deterministic output of the VDF function applied to the block snapshot.
2. Check the consistency of the block snapshot used for generating the VDF proof. Ensure that the snapshot represents the correct block data at the time of assignment, by comparing it to the builder hint payload generated or by looking for the presence of a builder committed pre-confirmation in it.
By conducting these checks, honest nodes and participants in the network can identify and report fraudulent activity by builders.
#### Bid/Commit Schemes & Transacting on Primev
In order for actors to engage in bid/commit schemes for application logic such as pre-confirmations, a transaction platform with high throughput characteristics can be utilized to support intra-block execution guarantees.
We envision running a federated chain that inherits existing MEV pipeline trust assumptions to provide the desired capabilities to the current market. This will ensure actors can consume builder hints on the Primev network as well as engage in bid/commit schemes. The federated chain will be progressively decentralized as we build the integrity protocol and make it available in the Primev instance. Further, we anticipate anyone to operate nodes on the Primev network in a trustless manner once ecosystem developments around rollups mature sufficiently and allow for sustainable levels of transaction costs.
Our network incentive model and token issuance will be critical to take the Primev network from a federated chain with trust assumptions to one that is not only decentralized but also owned and governed by the participants and contributors of the network.
### Staking and Slashing
Primev v0.1 uses staking as a means of sybil resistance, requiring builders and searchers to stake `X eth` per BLS pubkey in order to gain access to the protocol and participate in the p2p network. The amount of ETH required to stake is customizable for each builder and will be adjustable in the future by the governing body of the protocol.
Primev will use slashing to penalize behavior that acts against the best interest of the protocol. Actors will be able to submit fraud proofs to prove a builder engaged in dishonest computation or broke their commitment in order to slash them.
### Tokenomics
The end goal of Primev is a decentralized and self sustaining communication network of builders, searchers, and validators. To achieve such harmony we need proper incentives and mechanism, both of which are largely dominated by the tokenomics of the protocol. To shine light on what could be reasonable expectations for costs and rewards of each party, let's begin with a naive construction and work our way forward. Some notation:
- Initial token supply ($S_0$)
- Token supply increase per reward period ($\Delta S_R$)
- Reward supply period in blocks ($T_R$)
- Protocol fee as a fraction of the pre-confirmed value per block ($F_p$)
- Value being pre-confirmed per block ($V_b$)
- Burn percentage per block ($B_p$)
- Cost in ETH of posting to the base chain every post period ($C_p$)
- Post period in blocks ($T_P$)
#### Equations
The equations governing economics for a given block number:
\begin{align}
\text{Supply:=}\ S_{n} &= S_0 + \Delta S_R \cdot \lfloor\frac{n}{T_R}\rfloor \\
\text{Revenue:=}\ R_{n} &= n \cdot V_b \cdot F_p \\
\text{Cost:=}\ C_{n} &= \lfloor\frac{n}{T_P}\rfloor \cdot C_p \\
\text{Burn:=}\ B_{n} &= n \cdot V_b \cdot B_p \\
\text{Protocol Profit:=}\ P_{n} &= R_{n} - C_{n}
\end{align}
Where $S_{n}$ is the protocol supply at block $n$, $R_{n}$ is the cumulative revenue, $B_{n}$ is the cumulative burn, $C_{n}$ is the cumulative cost, and $P_{n}$ is the cumulative profit at block $n$.
Token simulation can be found in the appendix.
#### Token Model
In order to align Primev with Ethereum, we plan for Primev's native token to be a derivative of ETH that has a dynamic peg, starting with 1:1000 ETH:Primev ETH. Half of all transaction fees on Primev will be burned, ensuring a deflationary tokenomic model that maintains long-term sustainability. The other half will be collected in a treasury, which will be managed by holders of a new governance token for the Primev network as the governing body decentralizes with the protocol.
We introduce a governance token for Primev, aimed at rewarding users for contributing to the network’s growth and evolution. Unlike Primev ETH, the governance token will be an ERC-20 token on the Ethereum network used to govern the Primev protocol. Governing token holders play a crucial role in shaping the development and direction of Primev technology by actively participating in network management decisions such as protocol upgrades, fee adjustments, and application integrations. Governance token holders not only ensure the continued evolution of the ecosystem but also maintain its alignment with the community’s vision and values.
The distribution of governance tokens will be designed to stimulate network-benefiting behavior through multiple incentive mechanisms. To promote long-term commitment to maintaining the network’s infrastructure, governance tokens will be distributed as rewards for operating a Primev enabled blockbuilder or sequencer, and user-engagement programs that encourage consistent network usage and adoption, such as participating in testnets or airdrops upon engaging with the network.
By leveraging this two-token model, Primev can facilitate cheap & quick transactions and the governance token can act as a means to control protocol variables. We aim to create a thriving environment for MEV actors to engage in bid/commit schemes that create efficiencies for blockchain ecosystems, and align their incentives for network promoting behavior to further the security of the network and promote decentralization of blockbuilding and related communication over Primev.
#### Future Protocol Security Directions
There are a couple important research areas to pursue in determining protocol specifics:
- Security Budget - what is a reasonable amount to pay those upkeeping the network, whether they be validators through eigenlayer or native?
- Dynamic Congestion Pricing - Primev network will always live within some resource bounds, can we better handle high throughput events using pricing similar to EIP 1559?
- Economic Attacks - what type of attacks can you do to leak data in the system?
#### P2P Network
##### Example Communication
```mermaid
sequenceDiagram
participant Searcher as Searcher
participant Builder as Builder
Note over Searcher, Builder: P2P Communication Network
Searcher->>Builder: auth
Builder->>Searcher: auth_acknowledged
Searcher->>Builder: sendPreconfBid
Builder->>Searcher: bid_received
Searcher->>Builder: subscribe_blockMetaData
Builder->>Searcher: blockMetaData_subscribed
```
```mermaid
sequenceDiagram
participant Builder1 as Builder1
participant Builder2 as Builder2
Note over Builder1, Builder2: Builder-to-Builder Communication
Builder1->>Builder2: auth
Builder2->>Builder1: auth_acknowledged
Builder1->>Builder2: send_blockMetaData
Builder2->>Builder1: blockMetaData_received
Builder1->>Builder2: subscribe_blockMetaData
Builder2->>Builder1: blockMetaData_subscribed
Builder1->>Builder2: aggregate_preconfAttestation
Builder2->>Builder1: preconfAttestation_aggregated
```
## Future Work
- **MPC:** We will continue researching into uses of MPC technology in the Primev protocol, particularly to support partial blockbuilding without revealing order flow. Primev will use MPC to compute comparisons for block or transaction values across actors in the near term (highlighted above under Order Flow Exchanges) while MPC technology scales enough to be performant in computing heavier payloads and complex functions to be used for partial blockbuilding or collective searching between MEV actors.
- **Zero Knowledge Proofs:** We've evaluated using zero knowledge proofs for actors to share proofs about the execution data they possess or prove material information about their transactions or blocks they don't feel comfortable sharing. While computing zero knowledge proofs will add a significant latency and cost to the system that is not currently feasible for Primev's near term target use cases, we anticipate developments in the ZK space to catch up to our needs by 2025. Note that this is separate from our use of SNARKs which is a form of ZK tech under Primev's Integrity mechanism with VDFs.
- **Compatibility with upcoming MEV primitives using TEEs, Encrypted Order Flow, and other privacy enhancing technologies:** Primev will continue providing a sidecar module under upcoming MEV paradigms, including but not limited to having software that are compatible with and potentially run alongside core software inside TEEs, and employing homomorphic encryption techniques such that encrypted information about transactions or blocks can be selectively engaged in for bid/commit schemes.
## Conclusion
Primev is a blockbuilder communication network whose goal is to solve coordination inefficiencies between MEV actors in an increasingly complex and decentralized crypto ecosystem. Primev brings off-chain execution data on-chain for actors to engage with an ever growing set of use cases that will increase the user experience in transacting in decentralized systems, and bring additional liquidity and rewards to stakeholders of blockchains.
As blockchain ecosystems continue to grow and MEV takes over the traditional finance world's methods both in terms of volume, impact, and non-value extracting welfare, Primev will be a key protocol for entities to communicate and make sure users have their transaction execution expectations met seamlessly similar to centralized services in decentralized ecosystems. We believe Primev will be a force that will make the world's transition into blockchain systems more friendly to users, service providers, and ecosystem participants by making actors more efficient in working with the rest of the networks they interact with.
## References
TBC
## Appendix
#### Simulation
*Above: A graph of the simulation showing the protocol supply, revenue, costs, and cumulative burn over the specified number of blocks.*
Simulation parameter:
- Initial token supply ($S_0$) = 1000
- Token supply increase per reward period ($\Delta S_R$)= 50
- Reward supply period in blocks ($T_R$)= 10
- Protocol fee as a fraction of the pre-confirmed value per block ($F_p$)= 0.01
- Value being pre-confirmed per block ($V_b$)= 100
- Burn percentage per block ($B_p$)= 0.02
- Cost in ETH of posting to the base chain every post period ($C_p$)= 0.1
- Post period in blocks ($T_P$)= 10
*variables are due to change before whitepaper finalization*
Sign in with Wallet
Connect another wallet