Replies: 1 comment 4 replies
-
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. |
Beta Was this translation helpful? Give feedback.
4 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
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
Problems
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
Problems
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
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
Beta Was this translation helpful? Give feedback.
All reactions