Today, ETH delegators allocate their principal to node operators off-protocol, via staking pools.
In current Ethereum, capital providers do not actively participate in Consensus. We can improve this by allowing the Protocol to identify delegated stake and incentivize the Delegator role selection.
Allowing in-protocol delegations and having a meaningful role for delegators is a health indicator of any staking system. The current role principal providers play in delegated proof-of-stake is limited to voting within pools, which ultimately is just a flawed type of voting.
In regards to enshrining delegations in the context of Ethereum staking, at least to the author's knowledge, there is no ongoing research or design reaching community consensus.
ETH holders currently delegate through staking pools; the existing mechanics of Ethereum staking have been analyzed in a myriad of papers and posts by many brilliant minds. This document will not add to that, however, I recommend as a prerequisite, 4 readings: a series of three posts by Barnabé Monnot, analizing the Principal-Agent accountability naturally forming off-protocol under today's liquid staking forces:
The series analyzes the off-protocol and in-protocol mechanisms and constructions of staking, re-staking, liquid staking, node operators, capital providers, and others, starting from the protocol’s own staking mechanism.
and the eODS write-up from EPF Study Group.
Tier | Current natural separation | Slashing risk |
---|---|---|
Delegators | ETH stakers with no minimum commitment and no strict requirement to participate in any other way beyond bringing in their principal | Slashable |
Operators | Node operators, home staking or providing validator services, with their reputation or some fixed amount of capital of their own at risk | Slashable |
eODS provides ETH holders, with an explicit, in-protocol mechanism to deposit and delegate their principal. Capital providers can then delegate stake to a targeted validator (node operator), thus allowing for delegators to be more opinionated in their operators of choice, compared to the powers they have today. In a functional enshrined delegation mechanism, ETH holders will have a direct relation with their delegates, the validators (operators) executing the Protocol, thus mitigating the "grip" liquid staking has over staking.
eODS also proposes a solution to the long-term key question of "what’s the intended Etherean way for the large ETH holders that want return for their participation in protocol”. Delegators in this model can participate in a lighter way, but still meaninfull way than a full staking operation, by:
Delegating capital towards FFG services provision. In this case, stake is being used to bring economic security for the protocol, thus this stake is slashable. FFG here is used more generally, in the context of protocol finality, i.e. GASPER + LMD-GHOST
Re-delegating capital towards AVS services provision. These services are considered "light", as they are not strictly related to protocol finality, but used as a sybil-control mechanism and as weight function, thus this stake is non-slashable.
When a party re-stakes, they commit to the provision of an “actively validated service” (AVS). In this model,[..] re-staking into light services may not burden you with slashing conditions, yet would offer rewards for good service provision. So we claim that the model [..] is a partial enshrinement of re-staking, in the sense that we determine a “special” class of protocol AVS for which rewards are issued from the creation of newly-minted ETH. We then allow holders of ETH to enter into the provision of these services, either directly as operators, or indirectly as delegators. - from "Towards rainbow staking" ethresearch paper.
In order to avoid single point of failure scenarios, enshrining delegations can be introduced as a parallel functionality to today's Deposit - Validator activation - Validator duties pipeline.
eODS does not imply the exclusive use of delegated PoS over undelegated PoS, the two should co-exist(capital providers can use deposit OR delegation routes as ETH gateways, in order to bring stake into the Protocol)
Although eODS might modify the actions set of validators, it DOES NOT change the way a validator participating in the Ethereum proof-of-stake protocol is expected to act, according to Phase 0 – Honest Validator specification.
We identify a basic suite of features essential for any viable implementation for introducing in-protocol delegations. By deciding on basic design constraints, the range of potential solutions becomes narrowed.
The Validator role will be unbundled in two separate protocol entities:
Delegator - an optional protocol role for ETH holders that want to participate in a way that is lighter than a full staking operation, but still meaningful.
Operator - a protocol role equivalent to today's node operators, running consensus validators and executing the Protocol. Operators are accountable to Delegators in the context of delegated proof-of-stake.
Depending on the type of validators they will be running, Operators will be split into two tiers:
class Validator
with their own participation flags and signature domains.Accounting protocol object - keeps track of balance sheets and operations in the beacon state and executes operations based on predefined conditional relations defined further down.
0x01
withdrawals.The diagrams also contain the current protocol functionality for funding Validators:
DEPOSIT_CONTRACT -> ACCOUNTING (PRINCIPAL)-> OPERATORS(VALIDATORS)
Check cap 6.2 New Delegator, with the intent to delegate to heavy Operators and light Operators for eODS functionality alone.
A central DEPOSIT_TO_DELEGATE_CONTRACT, deployed in a protocol-legible format, similar to the current DEPOSIT_CONTRACT
Any of the actors in the eODS construction, as shown in chapter 4.1. Can be Delegator, heavy Operator, or light Operator. It can also be the Accounting protocol object.
The accounting is operated by the Accounting protocol object that keeps track of balance sheets in the beacon state and executes operations based on Predefined conditional relations.
It's called "object", in the attempt to specificate the accounting part as an ENTITY of the overall system, that can act based on predefined logic. In practice, Accounting is just the group of protocol functions that keep the protocol's accounting. This part already exists under the current protocol, embodied by Beacon operations, or Beacon state mutators, like process_deposit
, increase_balance
.
The "accounting" term is used in the strictly etymological way it came to be used inside Ethereum protocol, i.e. Altair fork introduced the "accounting reforms"
For the scope of prototyping the feature, I felt it would be useful to group these functions in a virtual group based on functionality (i.e. accounting) rather than beacon-chain specification container appartenance.
The default "behaviour" of the Accounting object is the current protocol's "behaviour" in matters of operations and internal accounting. Chapters 5.6 Conditional inter-partes relations and 5.5 Design constraints, present how Accounting manages balance sheets between parties, and what proposed changes eODS brings to current protocol accounting.
The most basic “type” of eODS semantics is that of an asset.
There are three accepted assets types in the proposed construction:
There are three accepted token-type assets:
ETH, the native token of the Ethereum network, deposited in the delegation contract or the deposit contract, with the purpose of being staked.
PRINCIPAL, a virtual asset representing the virtual balance of depositors, received in the protocol's consensus layer, against which, the staker's ETH is redeemable. It's the equivalent of today's validator balance in the beacon state. Delegators can transfer PRINCIPAL to operators with the intent of being staked in FFG.
SHARE, a virtual asset representing the virtual balance of delegators, received in the protocol's consensus layer, against which, the delegator's PRINCIPAL balance is redeemable. It represents a share of the delegated PRINCIPAL, and can be "re-delegated" by Delegators towards light Operators with the intent of being staked in AVS.
A minted receipt that stands as a liability against Entity B, in the case of Entity A transferring ASSET to Entity B. It acts like a claim, allowing Entity A to eventually redeem ASSET, by running the same order of operations, backwards.
Similar to RECEIPT, but proving a certain action or event, that is not ASSET transfer (as in the case of an RECEIPT), e.g. a DEPOSIT_CONTRACT event parsed in protocol.
It can also be proof of ownership over a certain balance or delegated ASSETs, i.e. withdrawal credentials.
A liability is the opposite of an ASSET, referring to things that are owed or borrowed. Assets are things that are owned.
Balance sheets show the creation and transfer of assets between multiple involved entities.
Balance sheets will be used in the Workflow Diagram. I preserved the practical format used in the "Semantics of staking" paper:
- The first row represents the “pre-state”, denoting which assets are currently owned by each party.
- The last row represents the “post-state”, denoting which assets are owned by each party after all operations have concluded.
- The rows in between represent operations, with a new row simply denoting a new set of operations, divided from the others for the purpose of exposition.
There are two basic operations that take place repeatedly:
ASSET transfer
RECEIPT (claim) && PROOF (proof of a certain event), minting
Term | Type | Short description | Usage |
---|---|---|---|
PRINCIPAL | ASSET | Represents the virtual balances of Depositors, in the consensus layer | Used for backing Operators to fund Validators |
SHARE | ASSET | Represents the virtual balances of Delegators in the consensus layer | Used for backing light Operators to fund light Validators |
RECEIPT | CLAIM | Represents a claim held by the entity that initiated an asset transfer, against the receiving entity, allowing the former to eventually redeem the asset | Used for assets redeeming, by running the same order of operations that led to assets being transfered, only backwards. |
PROOF | PROOF | Represents the proof of a certain action or event | Used in Accounting to track balance sheets operations, other than asset transfer |
Operators run Validators to execute Consensus (Finality), as they do today. Validators are funded with PRINCIPAL. Rewards, penalties and slashing apply as today.
light Operators run light Validators to execute light Consensus (Non-Finality protocol services). light Validators are funded with SHARE. For AVS, only rewards and penalties apply, no slashing.
PROOF types:
PRINCIPAL is minted as liability in the balance sheet of beacon state Accounting, when a PROOF of the DEPOSIT_CONTRACT / DEPOSIT_TO_DELEGATE_CONTRACT deposit event is received, and considered an asset in the balance sheet of
SHARE, is minted as liability in the balance sheet of beacon state Accounting, when the RECEIPT of PRINCIPAL being transfered by Delegators towards delegated Operators is received. SHARE is then considered an asset in the balance sheet of Delegators.
ACCOUNTING & WITHDRAWALS
If an delegated or undelegated Operator running Validators performs its FFG consensus duties adequately, the Ethereum protocol credits its balance of PRINCIPAL with newly minted PRINCIPAL. Conversely, when the Operator receives penalties or is slashed, the protocol debits its PRINCIPAL balance.
If an delegated or undelegated light Operator running light Validators performs its light consensus (AVS) duties adequately, the Ethereum protocol credits its balance of SHARE with newly minted SHARE. There is no slashing for light consensus.
An ENTITY owning WITHDRAWAL CREDENTIALS or a RECEIPT, can redeem deposited or delegated ASSETs, by running backwards, the same order of operations that led to ASSET being transferred to another entity, thus:
Depositors with the proper withdrawal credentials have the option to withdraw their PRINCIPAL they have inside the protocol in the form of a Delegator's balance, against ETH, at parity (1:1), in both delegated and undelegated PoS.
When the Delegator wishes to withdraw their SHARE balance against the delegated PRINCIPAL from the delegated Operator, the withdrawal is NOT processed 1:1, i.e., for x units of SHARE, the Delegator might receive different that x PRINCIPAL in return, because even though SHARE - PRINCIPAL rate is 1:1, Operators work for a fee, and there is also a tripartite compensation to be done between Delegator, Operator and protocol Accounting, in matters of:
When the Delegator wishes to withdraw their delegated SHARE balance from the delegated light Operator, the in-protocol withdrawal is NOT processed 1:1, either, because light Operators work for a fee, that needs to be accounted for.
The balance sheet of the current deposit process in nondelegated PoS. Depositor and Validator are considered to be the same physical entity.
The balance sheet of the proposed deposit process in delegated PoS. Depositor and Delegator are considered to be the same physical entity.
The balance sheet of the proposed delegation process in delegated PoS, of a Delegator backing-up an Operator with the intent to fund a validator and participate in FFG. Delegator and Operator are not necessairly the same physical entity.
The balance sheet of the proposed delegation process in delegated PoS, of a Delegator backing-up a light Operator with the intent to fund a light validator and participate in AVS. Delegator and Operator are not necessairly the same phisical entiy.
The actions set of Validators would be reduced by transferring the Censorship Resistance protocol services e.g. IL, and other non-FFG attributes to the light Validator's actions set.
We can list a number of current (and in research i.e. CR), Validator attributes that could be removed from the Validator actions set and added to light Validator actions set:
Delegators can only delegate:
The two types of delegations (for the provision of FFG and AVS protocol services) MUST happen consecutively and the invalidation of one MUST attract the invalidation of the other. This is to generate "transferability" of the responsibility to run light Consensus and avoid cases where a Delegator delegates to a FFG Validator, but does not re-stake for AVS, so there would be no corresponding light Consensus validator running light protocol services.
Under this eODS model, there are two paths of validators entering activation queue:
An undelegated way
And a delegated way
Light Validators enter the activation queue, after a valid SHARE delegation message containing the delegated light Validator's pubkey has been included in a beacon block.
This case study is straightforward, as it depicts the current Deposit - Validator funding - Validator performing duties process, which eODS does not propose to be modified, as eODS is rather a parallel, opt-in functionality.
WORKFLOW
apply_deposit
class Delegator
in beacon-chainDelegatorIndex
and accounting increases the Delegator's PRINCIPLE
balance with the deposited amount, if the pubkey used in the deposit process does not match any existing Delegator from the BeaconState registry. Subsequent deposits made using the same pubkey
will compound to the Delegator's balance.When delegating in protocol, the delegator's balance (the PRINCIPAL) is being transferred to the delegate but a mapping of the delegation is created in the Delegator's accounting records.
Delegator sends a DelegationMessage
on the p2p network that contains the validating public key and the index of a delegate validator. The message will also contain the Delegator's BLS pubkey and withdrawal credentials, in order to verify the signature of the sender and the commitment to pubkey for withdrawals purposes. The delegation message will be signed over with the delegator's BLS signature.
Proposers listening to eODS gossip, would include delegation messages in a block and as soon as the block is included on-chain, the delegate validator receives the PRINCIPAL. The Delegator's SHARE balance in the BeaconState is credited with the same amount
by the Accounting protocol object.
Delegators re-delegate stake by transferring their SHARE balance to light Validators. The process is identical to delegating towards Validators, by sending a DelegationMessage
containing the public key and the index of a delegate validator, on the p2p network.
As mentioned in cap. 5.7, we can list a number of current (and in research i.e. CR), Validator attributes that could be removed from the Validator actions set and added to light Validator actions set, like:
Since light_Validators in this model, are funded with SHARE, which is re-delegated PRINCIPAL (stake), let us consider the light protocol services, as AVS services. For participating in protocol AVS, light_Validators receive rewards that are issued from the creation of newly-minted SHARE.
More research is needed on this topic, in order to assess IF and WHICH of these, or other attributes can be SAFELY abstracted from the Validator actions set, into the light Validator's actions set.
Inclusion lists and ePBS are in active research, and at least at this moment, the first FOCIL iteration seems to be based on an altruistic IL committee participation. This might change in time. Attesters receive one full attestation for evaluating the IL aggregate, as is the case for PTC committee in ePBS.