single slot PBS using attester committee

Author: @terencechain

Over the weekend, I reviewed Vitalik's post on Single-slot PBS using attesters as distributed availability oracle. The main idea is to use an attester committee of size N instead of a relayer and use this committee as an oracle for validating and ensuring the data availability of builder outsourced execution payloads. I took some notes and came up with some open design questions. Although I am interested in implementing this idea, we need to study its feasibility first. In the following sections, I will break down the steps and make some timing assumptions. Finally, I will discuss the challenges and potential attack vectors.

Step 1: Builder gossips chunked payload to attester committee

The first step of the process is for the builder to dismantle the payload by erasure coding it into N chunks with M needed to recover. The builder encrypts the chunk with the respected validator's public key. It could be i'th chunk to the public key of the i'th committee member. This means the trust assumption is M, where M validators will have to collude to reconstruct the decrypted payload for stealing or offline to affect liveness. It is builder's responsibility to construct a payload proof to prove that:

• The execution payload is valid
• The execution payload matches the bid value. Bid expresses the intent for the builder to pay the validator for payload inclusion

Given the timing to build and a broadcast at the start of the slot. This means the builder will need to start the dismantling process towards the end of the previous slot at seconds 10 and 11 for encryption and p2p wire time. The respected chunk must make it to the validator promptly. Builder broadcasts the encrypted and chunked payload to attesters over builder_chunked_payload_subnet

The open questions and unknowns for this section are:

• How to choose N and M
• How often does this attester committee shuffle. Peer discovery concerns.
• Builder sophistication. Builder has to dismantle the execution payload and broadcast it over the p2p network
• Execution payload release timing. The standard builder behavior is to wait until the last possible second. Unclear how long the p2p broadcast and builder encryption and attester decryption take
• Cryptographic primitives maturity. Standardized asymmetric encryption/decryption

Step 2: Attester committee validates the chunked payload

The second step of the process is for the attester committee to validate chunked payload using the previously constructed validity proof and payment proof. The individual attester in the committee will decrypt the chunked payload and validate that the proofs are valid. If the chunk is valid, the attester will blind the chunk payload and broadcast it to the attester_signed_blind_chunked_payload_subnet. Note that this opens up some DOS vectors to the attester committee. Attester in the committee has to endure some bandwidth and verification costs. It would make sense to have some Sybil defenses for the builders. Whether we want the builders to be registered on the chain or off-chain through a curated registry is unclear. Given that proposer is only interested in the highest bid payload, it would make sense to drop any bid amount that's lower than some threshold average amount as a cheap check.

The open questions and unknowns for this section are:

• Builder can DOS attester committee for bandwidth and compute. This will require some good p2p validations from the attester committee over the attester_signed_blind_chunked_payload_subnet.

Step 3: Attester committee broadcasts the signed chunked payload to the proposer

After the attester committee has verified that chunked payload proof is valid, the third step is for the attester committee to blind, sign and broadcast a signed chunked payload to the proposer over an attester_signed_blind_chunked_payload_subnet. It wouldn't make sense for the attester committee to repeat the same process for every received payload from the builder. Perhaps the attester committee can track broadcast of the top three bid values. The attester needs to broadcast these chunked payloads at the start of the slot or even 100ms earlier to account for p2p wire time. The individual attester in the committee will keep the clear_chunked_payload but it will not reveal it yet.

Step 4: Proposer commits to the payload

In this step, before the start of the slot, the proposer should receive the attester-signed blind chunked payload over attester_signed_blind_chunked_payload_subnet. Proposer will validate the chunked payload's signature and only cache the valid ones. Once the proposer has gathered enough chunks to know a full payload can be reconstructed or after some time has passed (Say 1s). The proposer will commit to just one full payload, sign over M shares, and broadcast them over proposer_signed_blind_chunked_payload_subnet. There is a grieving vector where the proposer can commit to multiple payload chunks and trick attesters into revealing them for free. There needs to be an equivocation condition for proposing signing duplicated blind chunked payload under the same index. Even with the equivocation condition, it's unclear what other attack the proposer could impose on the builder for cheap. Also, To reduce latency and avoid an extra trip, the proposer can also broadcast the signed block header at this time.

The open questions and unknowns for this section are:

• Proposer may grieve builder or self-slash for the unbundling attack through multiple slots in a row
• Proposer broadcast signed block header. New p2p subnet

Step 5: Attester committee unblinds the payload. Anyone can reconstruct and broadcast signed beacon block

After the individual attester in the committee receives the proposer signature for the chunked blind payload, the attester immediately reveals the unblind version over the attester_chunked_payload_subnet. Any node can listen over the subnet, and when over M threshold passes, the full payload can be reconstructed and broadcast it along with the signed beacon block.

Attack vectors and open questions

• How to choose N and M. A trade-off between security and latency
• Builder can DOS attester without reputation or on-chain identity
• Attesters can DOS proposer, some basic p2p validation steps should take care of this. Attesters are known
• Proposer can DOS attesters, again some basic p2p validation steps should take care of this. Proposer is known
• Proposers can grieve builders. Need equivocation condition. What if MEV > slashing
• How do we get censorship resistance from this scheme? Perhaps IL can be built into the protocol and builder -> attester proof includes
  • Execution validity
  • Proof of payment
  • IL property is satisfied
• Proposer can still use local EL client for block producing if the above step 2 starts to degrades