Discussion on delegation

[mempirate]

In the context of L1 proposer commitments, delegation would be the act of delegating the operational duties of making commitments from the L1 proposer to a third-party. This discussion aims to find methods of delegation that have an acceptable level of censorship-resistance and trust assumptions.

Why delegate

Bolt will initially only support inclusion preconfirmations, which are "simple" proposer commitments from an operational & economic perspective. However, as we progress through the roadmap, some proposer commitments will require more operational & economic sophistication than many proposers inherently possess (state preconfirmations). It is extremely undesirable to overload them with these duties, because that would risk validator centralization. Instead, we should quarantine these economies of scale by easily supporting delegation, democratizing access to the revenue that these more complex commitments will bring.

Methods of delegation

Explicit delegation

Explicit delegation means that the proposer, ahead of time, explicitly delegates their operational duties AND stake to a third party (the operator or gateway). The proposer is then expected to honor any commitments made by the operator or they will get slashed. This might look like a design where the operator just delivers the full payload when the proposer has to propose (similar to PBS).
The operator might also stake to decrease the required trust assumptions, and slashing conditions can be tweaked to make this somewhat incentive-compatible, but in the end this is a trusted relationship where the proposer trusts the operator (and their reputation) to not commit any faults. This pattern is inherently supported in restaking protocols.

Any revenue from commitments is shared between the proposer and the operator. Operators could advertise their fee similar to how node operators advertise their fee on Cosmos chains. In fact, explicit delegation is very similar to DPoS and faces the same issues such as the principal-agent problem.

Advantages

• Simple
• Supports proposer pooling (which would be required for state preconfirmations due to high collateral requirements)

Problems

• More trust assumptions
• High barriers to entry

Market-based delegation

Market-based delegation or the "outsourcing" of operational duties through a permissionless / semi-permissionless market mechanism is more desirable and trustless, but brings with it a whole host of other problems, like the fair-exchange problem that arises between untrusted participants (like in PBS).

Market-based delegation, in the case of proposer commitments, would look like a slot auction where either the whole block or just the top of the block is sold ahead of time.

Advantages

• More permissionless
• Lower barrier to entry for operators

Problems

• When the slot is sold, the proposer actually doesn't really know what the buyer will do with it. The buyer can just as well use it solely for their own methods, which might not include preconfirmations at all.
• Fair exchange between untrusted parties

Explicit delegation seems like the right choice here, at least in the beginning. What's important is that our explicit delegation mechanism does not forgo all the proposers' agency, which would decrease the CR properties of the system.

Flavors of delegation

• Full delegation: the L1 proposer fully delegates their building rights ahead of time to a third party. This can either be through a permissionless market mechanism like slot auctions, or an explicit delegation to a third party.
• Partial delegation: the L1 proposer partially delegates their ToB proposing rights ahead of time to a third party. When the it's time to propose, the proposer can append a suffix of transactions to the ToB if they want to, to increase CR properties. Note that they can't guarantee inclusion anymore though, since any transaction in the ToB might invalidate what the proposer promised to include.

Partial delegation looks similar to proposer suffixes, and I personally like this approach. We'll have to figure out some of the problems outlined in the link though.

Questions

• How does the dynamic change if the operator is also the builder? Do we need all of these extra rounds of communication (constraints etc)?

[The-CTra1n]

Ephemeral keys and/or TEEs would be a third option. In-protocol delegation would be a 4th that should be available eventually, but not right now.

Right now, ephemeral keys would mean validators need to withdraw their funds after every proposer slot, which might be impractical, but would remove the barrier of low-resource proposers.

[mempirate]

Thanks for the response! Could you expand a bit on what you mean with ephemeral keys?

[The-CTra1n]

When I said ephemeral, I meant single-use, or probably more importantly, provable single use.

With such functionality, the proposer could theoretically prove to a preconfirmer that the key is single-use, and transfer it to the preconfirmer securely in a way that proves the proposer no longer has access to the signing key (through a TEE is the only approach I've seen work, but using MPC/threshold signatures might also work). With this functionality, the L1 proposer could fully insure themselves against the preconfirmer, as the preconfirmer theoretically would be the only person that can sign for the block, so should have no problem taking on all of the proposer's in-protocol slashing risk.

[piotr-roslaniec]

What are the latency constraints for the proposer? TEEs are generally faster, but there are publicly verifiable threshold signing schemes with comparable latency (CGGMP'21, say 2-of-3).

[mempirate]

@piotr-roslaniec if I understood the concept of ephemeral keys correctly, the ephemeral key could be transferred some time in advance to the delegatee (preconfirmer). It should grant the rights to propose for a specific slot (or multiple slots). I don't think the latency matters too much here (@The-CTra1n correct me if I'm wrong).