PEPC-DVT: PEPC with no changes to the consensus protocol

[OisinKyne]

Firstly, great work @diego!

I wanted to weigh in here, to answer some people’s questions, and slightly refine one piece the proposal.

The one issue here is with the idea that the proposer has 50% of the validator private key and other DV nodes have the other 50%. Within a DV cluster, each node has an equal amount of the private key (more specifically they each have a coefficient of a polynomial that represents the private key rather than pieces of the key itself), and the node that has the right to propose is rotated deterministically per the rules of the consensus algorithm the cluster is running. (Usually QBFT at the moment). The operator that happens to be the proposer uses its mev-boost or CL to craft a block, and proposes to the rest of the cluster that they approve it for signing. The rest of the nodes check it conforms to the agreed upon rules (for now, that the fee recipient is as expected), and if so, they play their part in the consensus game to approve it. Once consensus (within the cluster) is achieved on the block, the validator clients are given it to sign.

In a PEPC-DVT world, these DV clients would use their EL RPC APIs to run the block through Emily, and only agree to it if the commitment checks pass.

Now to answer some of the rest of the comments:

@nick-fc

1. Who do you imagine will serve as the supervising DVT nodes?

This depends on which operators make up a given distributed validator. If a builder wanted to only use a subset of doxxed validators, they would not bid for upcoming proposals by validator indices they don’t know. (e.g. validators that aren’t bound to honesty with eigenlayer, or validators that don’t belong to lido)

@nick-fc

2. Could PEPC-DVT use a rotation mechanism where the DVT validators change every epoch? It’d be easy to do OOP collusion with the supervising DVT nodes if they remain the same for a long period of time.

Every slot is proposed by a new validator, run by different (but static) operators. There is up to 32 slots of lookahead. Operators within a given DV can plan to collude with one another for the next time they get a proposal, so at its most basic, a PEPC-DVT proposal for a single slot could be compromised by 3 colluding operators. The risk of this could be reduced by introducing a PEPC-DVT++ type of setup, where the operators agree to be bound by restaking slashing rules if they propose something that doesn’t conform to their commitments.

@nick-fc

3. A big challenge with PEPC-DVT is the small DVT set. Eigenlayer provides a solution to easily scale the supervising set. What is the advantage of PEPC-DVT over just using Eigenlayer? I thought the value of normal PEPC over Eigenlayer was largely around the commitment logic being enshrined, but PEPC-DVT isn’t.

You can use eigenlayer with DVT as they are complementary Eigenlayer alone can only punish a validator up to all of its stake. With eigenlayer + DVT, you make it more difficult to ‘defect’ and break the commitments, as you need most of the operators in the cluster to agree to do so.

@mikeneuder

is there anything particular about DVT that this design hinges on? Would a simple multisig solve the same problem but without the need for DVT?

DVT basically is a consensus mechanism + multisig for validating

@mikeneuder

it seems like the selection of the “enforcement committee” is the most important feature here. If the proposer has 50% of the key, then they only need to bribe a single committee member to produce a valid signature, so the committee would have an N out of N honesty assumption right? I guess that parameter can be tuned, but its still for sure worth considering, especially if breaking the commitment could lead to outsized rewards, e.g., large MEV opportunities.

Check my nuance at the top of this post, but more or less yes. With this proposal you have M out of N honesty assumptions (where M must be > 2/3rds of N for consensus safety reasons). You can combine this with up the 32 ether of economic incentive via eigenlayer, but even together they still may not be enough for large defection opportunities to happen. I’m not sure there is an out of protocol mechanism that can do better than that.

@mikeneuder

could a proposer make a commitment to a builder, but then reorg the chain so that it looks like they didn’t make that commitment to trick the enforcement committee into signing their block? I guess in general these commitment schemes seem super latency sensitive, so I am curious about the games proposers could play with them.

I think at the very least a commitment scheme shouldn’t be allowed to be changed and used in the same block. A builder should probably wait until a commitment is finalized to be extremely safe. This design will definitely be latency sensitive, but more towards brittleness than vulnerability imo. Blinded beacon block headers are small (KBs), full blocks are large (MBs). Currently coming to consensus on a proposal takes little verification time, with PEPC DVT you now have to run the large block through an EL RPC api to simulate a solidity function call that involves signature verification (and can have lots of gas cost). All of this runs the risk of taking too long for a proposal to happen and the slot getting missed. However Diego is already exploring designs that might reduce this back down to light in size and verification time, either with ZK or MEVboost type approaches.

@nikete

Is it possible to provide economic incentives for this kind of distributed validators? is there any way to check or verify this?

The short answer here is yes they can be provided @nikete, but verifying these economic incentives are objective is pretty hard. We’ll be putting out some research by the Nethermind team over the coming weeks on the challenges relating to this topic.