Runtime Verification audits the Proof of Neutrality Network

Runtime Verification is thrilled to announce the completion of the Proof of Neutrality Network audit. In this post, we give an overview of what the Proof of Neutrality Network is and describe the highlights of its audit.

Proof of Neutrality Network

The Proof of Neutrality Network (PoN) is an implementation of the Proposer-Builder Separation (PBS), where proposers (validators) auction their blockspace to builders who want to include their crafted blocks for MEV.

The key aspect of the PoN is that it is relayer-agnostic and relayer-neutral. Meaning that, except for the cryptographic scheme that relayers need to have for safety reasons, their implementation is largely unconstrained. A consequence of this relayer-agnosticism is that relayers can be lightweight and neutral. That is, by construction, the contents of the blocks sent to the PoN relayers are private and are not known by any party except the builder who created them. This is in contrast to existing solutions, where the relayer has full access to the proposed blocks and must be trusted not to misuse this information. To better understand how this neutrality can be achieved, we first need to talk about the cryptographic scheme that all PoN relayers must implement: the Restricted Partially Blind Signature scheme (RPBS).

RPBS Scheme and Relayer Neutrality

The RPBS scheme is at the center of relayer neutrality in the PoN. Simply put, this cryptographic scheme allows a signer (the builder) to reveal only partial information about what is being signed (the block contents). By using this scheme, a builder can sign the block that has been crafted, only revealing the last transaction. Thus keeping the rest of the block’s contents private to the relayer and the proposer.

Since only the last transaction of the block is public, it is enforced that this transaction be the bid offered to the relayer for including the crafted block in the blockchain. That is, the (only) public transaction is proof of the payment that would take place should the block be included in the blockchain.

Now we can better understand what it means that PoN relayers are neutral. Relayers are forfeit of any information regarding the block contents different from the promised payment for block inclusion. All MEV information is concealed from all agents except the builder. Thus no censorship or information theft should occur.

Each relayer can implement its own auction strategy. The Proof of Neutrality Network provides a default relayer implementation (sorting by highest bid), but it is not mandatory to use such an implementation for a relayer to be a part of a PoN.

PoN Agents

Before delving deeper into the PoN, we must explain which are the agents that constitute it. Here is a list of the four agents and a summary of their actions.

• Validators (also known as proposers): Standard Ethereum validators. They auction their blockspace when elected by the consensus layer to propose a block. Earnings from such auctions are shared with the rest of the PoN’s validators.
• Builders: Craft blocks and bid to win the validator’s auctions. If an auction is won by a builder, they must pay the PoN the winning bid amount.
• Relayers: Auction houses of the PoN. They enforce an auction mechanism and perform sanity checks on bids submitted by builders. Relayers must transparently forward information between builders and proposers.
• Reporters: Watchdogs of the PoN. They scan every slot in search of PoN’s rules violations. Will report any such violations to the PoN for a reward, ensuring that all wrongdoing has its associated penalty applied.

Auction Lifecycle

Now that we know the main agents of the PoN and their actions let’s explore the off-chain auction lifecycle. Besides the concealed signed block contents and the proof of payment, the additional information shared by the builder with the relayer and proposer is the block header. Once the proposer has chosen a bid offered by a relayer, it will sign the block header and forward the signed block header to the relayer, which in turn will forward it to the appropriate builder. Since the builder is the only party with the block contents, is the one in charge of broadcasting the full block. The picture below shows schematically the lifecycle of a PoN’s auction.

PoN Components

A crucial characteristic of the PoN is that every agent should be recognized on-chain. The information about the auctions kept off-chain is intended to be minimal, and every major action should eventually be reflected on-chain. To reflect every agent on-chain, the Proof of Neutrality Network is divided into four main components:

• Payout Pool: Where MEV rewards are gathered and distributed.
• Proposer Registry: Where proposers (validators) must register to share rewards.
• Builder Registry: Where builders must register to bid for the proposers’ blockspace.
• Reporter Registry: Where reporters register to be able to submit observed misbehaviors and where said misbehaviors are reported.

Let’s dive into the main components constituting the PoN!

Payout Pool

The Payout Pool is the central coordinating on-chain component of the PoN. All MEV auction payments must be directed to this smart contract. It also contains the payment distribution logic and the penalization logic for validators. 

MEV rewards are allocated in an equal proportion to all active validators in the PoN. Along with reward sharing, penalties on these rewards are applied should registered validators break the iron rule: the Payout Pool must receive payment for each slot belonging to a PoN validator.

Although rewards may be credited to well-behaving validators, these are not immediately withdrawable. To ensure better accountability, rewards are available for withdrawal after a challenge period for reporting validator misbehaviors has passed. This challenge period (called payout cycle) lasts 1575 epochs, 7 exact days.

Proposer Registry

The Proposer Registry contract keeps track of the PoN validators. Proposers that want to be part of the PoN must register in this contract. After a waiting period of a payout cycle (7 days), they become an active PoN validator, eligible for rewards.

Validators in an active state need not contribute to the Payout Pool to claim rewards since these are equally distributed to all active PoN proposers. However, they must pay the Payout Pool once a slot is assigned to them by the consensus layer. Failure to do so will result in a slashing of the MEV rewards accrued in the current payout cycle and any unclaimed rewards sitting in the Payout Pool.

There is a hosted service that checks the qualifying criteria for validators to join the PoN. This is because their BLS key needs to be associated with an ECDSA address from the execution layer by a trusted off-chain service, the Signature Swapper. The Signature Swapper will perform sanity checks on validators aspiring to join the PoN. These include having a full 32 ETH effective balance and possibly cross-referencing if the validator has been registered in other PoN instances or MEV pools.

Once a validator has emitted their will to exit the PoN, it will become effective after a payout cycle has passed, theoretically giving enough time for any wrongdoing to be reported to the network. An exited validator cannot become active again in the PoN.

Besides the voluntary exit, another exit vector for validators is to have two violations reported, be slashed by the consensus layer, or have an effective balance smaller than 32 ETH. Once the network is made aware of any of these situations, it will forcibly expel it, using its remaining rewards to cover for penalties.

Builder Registry

As its name indicates, the Builder Registry keeps track of registered PoN builders. Unlike proposers, builders can register in a permissionless manner in multiple PoNs or other MEV services. Upon registration, builders must stake an amount of ETH in the Builder Registry to account for possible misbehaviors. Relayers will consider builders’ bids if the Builder Registry considers the builders’ stake high enough. The amount of stake required is based on the past MEV rewards sent to the Payout Pool. This ensures that the PoN has enough stake to cover for possible grievings from the builders’ side. Penalties for grieving the PoN (e.g., by spending the promised payment in a transaction prior to the public one) are exercised by the Builder Registry.

Although builders are never forcibly removed from the network, they lose stake if they misbehave. After losing their stake, they need to re-stake the necessary amount to participate in auctions. On top of this, relayers can implement a filtering mechanism for publicly known bad builders. This could be done by having relayers fetch data from an on-chain black (or white) list.

Reporter Registry

Smart contract that tracks the registered reporters and entry point of rule violation reports. Any entity can permissionlessly register as a reporter. The reporter's actions consist of observing newly included blocks in search of PBS rules violations and reporting them. If such a violation is detected, reporters will submit a report to a trusted off-chain party, the Hosted Service. This service is in charge of querying the pertinent relayers and on-chain information to assess the validity of the report. If the Hosted Service agrees to the event being reported, it will sign the report and forward it to the reporter so that it can be submitted to the Reporter Registry for the corresponding penalty to be exercised.

Once a report has been submitted to the PoN (that is, a report signed by the Hosted Service has been submitted to the Reporter Registry by a registered reporter), the reporter will be awarded a part of the penalty. In this way, reporters are always incentivized to submit observed violations, even if the report concerns a builder or a validator that the registered reporter controls.

To mitigate illicit synergies between reporters and other PoN agents, a waiting period of 100 blocks is imposed for reporters to withdraw their accrued rewards from past reports.

Relayer’s Role

The only roles of the relayer in the PoN are to filter out bids and transparently forward information, such as the (signed) block header. If an unregistered builder or a registered builder who doesn’t have enough stake in the Builder Registry offers a bid, the relayer will immediately reject it. In addition to these sanity checks, each relayer implements its own auction mechanism. This could go from the expected max-value bid mechanism to more diverse auction mechanisms, such as auctions containing subscription-based whitelists for direct inclusion. Note that different auction mechanisms are possible to coexist in the same PoN since the validators would query different relayers and choose the winning bid they like the most.

Relayers obtain a maintenance fee based on the total amount of MEV rewards given to the Payout Pool to cover the cost and effort associated with running a relayer.

Relayers running and behaving well is part of the trust base of the protocol. If a relayer were unresponsive or misbehaved in any way, the information flow for truthfully determining penalties would be compromised.

For a more detailed description of the Proof of Neutrality Network, you can check out the description provided in the audit report or the off-chain model we produced during the audit (also found in the appendix of the report).

Audit Scope

The audit scope was limited to the Solidity source code of the on-chain smart contracts. Although important off-chain code was outside of scope, a model was produced during the audit in order to have a better understanding of the protocol. 

Any deployment and upgrade scripts, off-chain codebase, and client-side portions of the codebase were outside the scope of the audit. A detailed list of all the audited contracts can be found in the report.

Note that the specification and implementation of the RPBS scheme and the default relayer provided by the Proof of Neutrality team are not in scope.

Methodology

Runtime Verification conducted a manual code review for a period of 5 weeks and delivered a detailed report on March 10th, 2023.

The first step in the audit process consisted of reviewing the documentation in order to gain a better understanding of the protocol.

Then, rounds of discussions with the Proof of Neutrality team took place in order to expand on that understanding and to ensure that the code was functioning in the way the Proof of Neutrality team was expecting. 

Next, RV auditors checked the code for invariants and reasoned why they should hold in the contracts. This allowed auditors to find bugs in the code since not all the invariants held as expected.

Because the audited code works in conjunction with off-chain code that is out of scope, auditors created a mathematical model to have a clear understanding of the off-chain behavior. This allowed for a deeper understanding of the protocol and the ability to perform a more thorough analysis of the on-chain code.

Finally, the code was subject to a series of known attack vectors to ensure that its integrity held up to such attacks.

Results

The audit identified and highlighted some issues along with a number of informative findings. Although a review of fixes was not in the scope of this audit, the Proof of Neutrality team addressed all the issues and concerns raised during the audit and incorporated all the necessary changes in the smart contracts.

Users interested in a more detailed and technical explanation of the findings can go over the full report in our GitHub repository.

About Proof of Neutrality Network

The Proof of Neutrality (PoN) Network is a collection of protocols built to support credibly neutral infrastructure. The primary objective is to facilitate the widespread adoption of cryptocurrencies and promote financial inclusion. The current focus of PoN is on the expansion of the Ethereum ecosystem. PoN strives to be a reliable steward of an inclusive ecosystem, providing unrestricted access to all stakeholders and fostering fairness and democratization within the network.

About Runtime Verification

Runtime Verification is a technology startup based in Champaign-Urbana, Illinois. The company uses formal methods to perform security audits on virtual machines and smart contracts on public blockchains. It also provides software testing, verification services, and products to improve the safety, reliability, and correctness of software systems in the blockchain field.