eODS（Enshrined Operator Delegator Separation）：委托模型提案

非常感谢 Barnabé Monnot、Vlladin、Michail Kalinin、Alex Stokes 和 Potuz 的卓有成效的
过去一年的讨论（这些并非认可）。虽然以下工作中提出的观点和看法植根于协议路线图和过去18个月的研发讨论，但它们并不一定代表参与该项目的审阅者和协议人员的观点。接下来，我将为更广泛的质押框架（例如Rainbowstaking）提出一个委托模型，概述其逻辑、结构和实施路径。本文附有该功能的 Pyspec，最终的 Pytest 和 POC 将推动该模型走向成熟。

0.摘要

委托——将权益或治理权分配给第三方的过程——是
在许多区块链生态系统中，委托机制至关重要。然而，以太坊在协议层面缺乏原生的委托支持，而是依赖于基于合约的质押服务。虽然这些服务在吸引资本方面卓有成效，但它们也带来了中心化风险和治理挑战，从而严重削弱了协议可信的中立性。

1. 授权现状

在以太坊中，委托主要是非正式的和链下的。权益质押服务抽象验证者
责任，向用户提供流动性质押代币（LST）。这导致了
在协议层之外，对两类参与者进行质押：

• 节点运营商：管理执行协议的验证者并确保网络安全
• 委托人：提供资金，但对验证者的选择或治理的影响有限

相比之下，Cosmos、Solana 和 Tezos 等其他生态系统将委托直接纳入
该协议允许委托人与验证者进行质押并参与治理，包括
共享削减风险（在 Cosmos 和 Solana 中）。

2. 现有模型中的有效成分

这些元素来自以太坊和其他 PoS 生态系统，已展现出可衡量的效用或与协议一致的成果。它们的成功可以归因于可用性、资本效率或协议设计一致性方面的切实改进。

• 权益抽象：通过中间件对权益机制进行抽象——最常见的是
  流动性权益协议（LSP）——大大降低了参与门槛。
• LST 可组合性：stETH 或 rETH 等流动性质押代币 (LST) 是 ERC-20
  质押 ETH 的表示，可以用作 DeFi 系统中的抵押品或流动性，同时仍可获得质押奖励。
• 验证者合并 (EIP-7251) ：以太坊的 Pectra 升级引入了 EIP-7251，它
  允许验证者持有高达 2048 ETH 的余额——远远超过之前的 32 ETH 的上限。
• 协议层问责：像 Cosmos 和 Tezos 这样的区块链实现了协议内委托和奖励追踪。委托关系对共识协议本身可见，从而允许在底层直接执行验证者选择、性能追踪和罚没操作。这种结构似乎已被证明能够有效地协调委托人的激励机制，并通过透明的权益分配来维持去中心化。

3. 确定现有模型中的挑战

这些是当前以太坊委托中的一些架构和经济限制
实践，直接源于当今授权模式的表现及其对
网络的去中心化和验证者动态：

• 委托中心化：委托权益高度集中在少数流动性权益中
  协议。这种中心化限制了协议级别的多样性和验证者集的自主性，
  形成寡头垄断结构，破坏以太坊的去中心化目标。
• 委托人的影响力有限：委托人在验证器中没有协议认可的声音
  选择或治理。他们唯一的办法就是退出并将资本转移到其他地方，通常
  这会造成延误和机会成本。如果没有一个机制来表达验证者的偏好或治理立场，委托人在经济上具有影响力，但在政治上却没有发言权。这降低了委托作为一种安全增强机制的有效性。
• 验证者流失率增加：验证者进入和退出的频率是人为的
  由于委托模型缺乏部分质押重新分配机制，流动性质押协议如今已膨胀。如果没有协议内对更快重新委托的支持，流动性质押协议必须退出验证者。
  完全放弃验证者，并创建新的验证者，只是为了重新分配资金。这会导致验证者频繁更替，增加共识层的负载（激活队列、退出队列、验证者清除），并增加签名验证的总负担。虽然 EIP-7251 引入的验证者整合可以独立地减少用户流失，但它并不能完全解决与委托调整相关的用户流失问题。
  当前的委托模型在验证者之间转移质押时仍然会造成不必要的流失。整合功能虽然提高了可扩展性，但仍然与委托相关的流失问题无关。
• 缺乏对委托协议的可见性：以太坊的共识协议不跟踪
  委托关系。它无法“看到” ETH 是否被委托、委托给谁、委托多长时间。
  如果没有可见性，该协议就无法支持委托感知的验证者选择或治理信号。这限制了其向更具响应性的共识和验证者问责模型演进的能力。

4. 委托模型需要什么？

概述任何可行授权的（非限制性）要求和设计约束列表
模型：

它应该实现什么

• 消除 LST 引发的合约（存款、委托）风险，同时保持协议的
  安全保障。
• 为家庭运营商进行协议优化。授权将为新的竞争对手创造公平的竞争环境
  质押市场，包括本地运营商，因此，一个可行的委托模型应该支持最去中心化、最多样化、但财务上最不可持续的验证者运营商参与规模经济，而不是中心化，这是合乎逻辑的。
• 为委托人（ETH 持有者）提供有意义的协议角色和发言权
• 协议原生支持未来引入治理信号，例如验证者评级和选择
• 为验证者运营商和资本提供者改进用户体验

预期功能：

• 从 ETH 持有者的钱包发起的无缝委托操作

• 更快地重新分配协议权重（更快地重新委托）

• 确立无需许可且安全的委托操作的责任制

  扩展的特性功能提高了协议复杂性与其收益之间的比率，因此委托不仅仅是从验证器操作中产生收入的安全渠道，而且还是一种选择机制推动器，以及 ETH 持有者向协议传输治理信号的一种方式。

约束

该功能应尽可能降低复杂性，同时实现预期
功能。从任何实际意义上讲，在我看来，授权应该是一个可选的协议功能。
支持间接协议参与。
理想情况下，授权应该与路线图中的升级很好地契合，并减轻一些
与以下相关的权衡：

• 实施 SSF ：SSF 强制减少验证器集合，可以通过限制验证器来实现
  设置或通过实施 Orbit SSF，将阻止或减少实体的协议参与
  控制的权益不足以满足要求。可能会引入轻量级协议角色
  与证明分离，将减轻这种权衡。一个可行的委托模型是
  与未来的验证者角色专业化兼容
• 限制发行曲线，同时针对大量协议进行优化
  参与者，尽管是轻量级的。在发行曲线限制的情况下，价值
  对于大型运营商来说，Staking 的提议可能会变得不那么有吸引力，而对于许多小型运营商来说，
  验证者或许会想要参与。在当前的发行曲线下，质押 ETH 是任何 ETH 持有者的正常理性行为。随着最终曲线的上限，在质押达到一定阈值后， 仅持有 ETH 资产就足够了，这在经济上是可行的。因此，质押或质押委托可能会演变为治理信号，ETH 持有者委托是为了支持韧性和去中心化，而非仅仅出于资本效率的考虑。一个可行的委托模型将为委托加权的治理信号提供无缝、安全的渠道。

对验证者运营商的信任期望

商业质押节点为 ETH 持有者提供质押服务，其先验可信度高，因为它们有法律和商业约束，能够良好履行代理职责并维护良好声誉。家庭运营商和商业运营商之间的区别实际上不在于绩效，而在于信任。家庭运营商通过加密经济学，或“参与其中”的方式，为其代理机构赢得信任。

可行的委托模型将为验证者运营者提供一种无缝的方式，让他们能够支付保证金并获得接受委托的资格。虽然“某种风险”在以太坊中很可能会持续存在，但在未来，如果基础设施完善，该协议可能会接受除了可信度之外的其他信任指标，例如与社区价值观的一致性。

5. 放弃模式

eODS（enshrined Operator Delegator Separation）提议将操作员和委托人之间的验证者角色分离，从功能上为以太坊的共识层添加委托。

演员和关系

以下部分说明了此委托模型中的核心角色：

EL侧

• ETH 持有者作为提供资金并拥有提款密钥的实体
• 委托合约押金
• 委托操作请求合约（预编译）

CL 侧

• 委托人作为协议实体
• 委托验证器作为协议实体，作为现有验证器实体的包装器，并且
• Beacon-chain-accounting，一种协议会计工具

上面描述了一个委托构造，它不会改变验证者如何执行其
礼宾职责。

当事人关系

• ETH 持有者：提供资金的实体，也是提现凭证的持有者。
• ETH 持有者存款至DEPOSIT_TO_DELEGATE_CONTRACT
• 委托人，作为协议实体被创建，或者如果存在，其余额被充值
• 委托人由 ETH 持有者的提现密钥控制
• BeaconState 的委托验证者注册表正式化了以下关系：
  协议层面的委托人和验证人。在此模型下，验证人必须满足以下条件才能开始接收委托：
  • 验证器必须存在于状态注册表中
  • 它的提款凭证设置为复合，并且验证者选择成为运营商，
    即将validator.is_operator参数设置为True 。
• 委托后，委托人将明确链接到被委托的验证人。委托人
  每个委托验证器对象内的注册表包含两个并行列表： delegated_balances和delegators_quotas
• 信标链会计是一种神圣的会计工具，负责维护
  代表团专用资产负债表。

资本流程图

资本流动2731×1727 158 KB

委托生命周期

此 eODS 模型的委托生命周期包括以下可能的委托特定
操作：

存款给委托人

**ETH holder**└── sends ETH from execution address→ **Deposit to Delegate Contract** (ETH is burned)└── Contract emits → deposit to delegate event └── received by → **Consensus Client** via the execution payload└── deposit to delegate request is processed during epoch_transition└── creates new **Delegator** inside the Beacon Statetops-up existing **delegator**s balance with delegated amount└── links → **ETH holder** ⇄ **Delegator** via ETH holder s execution address

激活操作员

**Validator signs EL tx with withdrawal key**└── calls **Delegation Operations Requests Precompile**└── received by → **Consensus Client** via the execution payload└── activation request is processed during epoch_transition└── changes `validator.is_operator` parameter to `True`└── appends the **Delegated Validator** inside the Beacon state registry└── links → **Delegated Validator** ⇄ **target Validator**

委托（给验证者）

 **User (Delegator) signs EL tx from execution address**└── calls **Delegation Operations Requests Precompile**└── received by → **Consensus Client** via the execution payload└── delegation request is processed during epoch_transition└── asserts the delegation amount fits in the activation churn limit└── invokes → **beacon-chain-accounting**└── decreases **Delegator** s non delegated balance ( available balance ) with delegated amount└── increases **Delegated Validator**'s total delegated balance and the delegated balance from that specific Delegator with delegated amount└── recalculates delegators quotas under that specific **Delegated Validator**└── cumulates the **Validator**'s total delegated balance into its effective balance

取消委托（来自验证者）

 **User (Delegator) signs EL tx from execution address**└── calls **Delegation Operations Requests Precompile**└── received by → **Consensus Client** via the execution payload└── undelegation request is processed during epoch_transition└── calculates the undelegation s exit and withdrawability epochs└── appends the undelegation in the undelegation exit queue└── at withdrawal epoch, invokes → **beacon_chain_accounting** to settle undelegation└── decreases **Delegated Validator** s total delegated balance and the delegated balances from that specific Delegator with undelegated amount ( includes validator fee )└── recalculates delegators quotas under that specific **Delegated Validator**└── credits **Delegator**s non delegated balance with the undelegated amount minus validator fee└── credits **Validator**s actual balance with validator fee 

重新委托（从源验证器到目标验证器）

注意：重新授权由一次取消授权和随后的一次授权组成。

 **User (Delegator) signs EL tx from execution address**└── calls **Delegation Operations Requests Precompile**└── received by → **Consensus Client** via the execution payload└── redelegation request is processed during epoch_transition└── calculates the redelegation s exit and withdrawability epochs before balance re-allocation to target validator└── the redelegation is appended in the undelegation exit queue└── at withdrawal epoch, appends the redelegation in the delegations activation queue└── delegation request processed during epoch_transition└── asserts the delegation amount fits in the activation churn limit└── invokes → **beacon-chain-accounting**└── increases target validator s total delegated balance and the delegated balance from that specific delegator with delegated amount└── recalculates delegators quotas under that specific **Delegated Validator**└── cumulates the validator s total delegated balance into its effective balance 

从委托人处提现（到执行地址）

 **User (Delegator) signs EL tx from execution address**└── calls **Delegation Operations Requests Precompile**└── received by → **Consensus Client** via the execution payload└── withdraw from delegator request is processed during block processing└── the withdrawal is appended in a withdrawal queue└── the withdrawal from delegator is processed in next block → ETH minting to delegator's address 

内部会计模式

信标链记账是 eODS 规范中的一组方法，用于维护委托的记账。协议会在状态转换期间调用该方法。该方法会在委托相关的操作（例如存款、从委托人提现、委托人和被委托验证人之间的余额变动，以及应用奖励、惩罚和罚没）期间操作“资产负债表”。

这种架构确保信标链会计功能能够作为协议小工具运行——
协议层面已确立，但与未来升级兼容，包括验证者角色
分离。

配额

在特定的委托验证者下，委托人和操作员配额是动态维护的，
奖励和惩罚的计算反映了委托人的比例。
每次委托相关的状态发生变化时， DelegatedValidator都会重新计算配额，使用
并行列表（ delegated_balances 、 delegators_quotas ）。

授权机制

委托操作是通过 EL 触发的请求发起的，这些请求在 CL 中执行。这
启用协议管理的委托流程。

执行层（EL）触发请求

在 EL 层，用户与委托操作请求合约进行交互。每个
委托相关操作发出一个操作请求，该请求被提交到
执行包中的execution_requests列表，由EL为提议者构建。

支持的 EL 触发的委托操作请求类型有：

(*) 限制为每区块 16 个，以最大程度地减少与委托相关的提现操作对执行负载占用空间的影响。这样，这些系统级操作的 Gas 成本就可以为零。

这些操作请求将在 epoch/block 处理期间进行处理，无效请求将被丢弃。

共识层（CL）处理

在共识层，委托操作请求在区块处理过程中排队，并且
在 epoch 执行，但从委托人余额中提取的请求除外，这些请求在区块处理期间执行。CL 解析这些请求，并在
信标链记账 (beacon-chain-accounting)。为了实现与委托相关的记账目的，委托生命周期逻辑将以模块化记账操作的形式执行。信标链记账模块不直接发起状态转换或管理注册表；其子程序由信标链调用，从而协调信标链的状态转换。

以下每个方法都实现了委托生命周期中的一个阶段：

eODS 中的可靠安全

弱主观性时期不受该提案的影响。详细分析了该模型如何
保持进入和退出协议的余额可追溯，可以在这里找到。

奖励与惩罚

对于所有委托验证者及其委托人，奖励和惩罚在每个时期按其参与配额比例分配。

削减

削减是权益证明系统中的核心安全机制，用于惩罚验证者的不当行为
例如模棱两可或停机。它通过对造成重大故障的参与者施加经济后果来保护共识的完整性。目前在以太坊中，罚没机制仅适用于验证者。
委托人（通常是质押池的用户）在协议层面不会被罚没。他们遭受的任何损失均由质押服务的条款而非协议本身承担。Cosmos、Tezos 和 Solana 等其他生态系统实现了原生委托追踪功能，并按比例对委托人进行罚没。

eODS 下的削减

该模型建议对持不同意见的验证者及其最终
代表的份额与其参与额度成比例。

削减模型的比较

所提出的削减方法确保资本供应商直接向验证者公开
风险，这不仅加强了一致性，还增加了被动利益相关者的风险，委托人被激励将事务委托给发出其所要求的可信度信号级别的验证者运营商。

协议	削减目标	协议级委托	可削减的委托人	委托人的影响
以太坊（当前）	仅限验证者			通过池策略间接
以太坊（采用此 eODS 模型）	验证者和委托人			直接比例削减
宇宙	验证者和委托人			直接比例削减
Tezos	验证者和委托人			不当行为的共同损失
索拉纳	验证者和委托人			委托权益直接被削减

协议级重新委托

协议级别的重新委托允许委托人将其委托权益的一部分从一个
验证者无需执行全额提现，然后再重新存入即可。这解决了
这是通过基于智能合约的权益池进行委托的核心限制之一。它也有助于
减少验证者流失，保持网络稳定性，并让委托人能够灵活地应对
运营商绩效或治理偏好。从高层次来看，重新授权由一次取消授权操作和随后的一次授权操作组成。

附录中提供了从开发人员的角度深入探讨委托、取消委托和重新委托的著作链接。

6. 用户故事和生命周期集成

为了理解 eODS 的实际意义，我们通过以下视角来构建其功能：
参与者体验。以下用户故事展示了以太坊利益相关者（ETH 持有者、验证者运营者和协议客户端）在此模型下如何与委托生命周期进行交互。
这些不是假设的最终用户界面，而是围绕角色构建的叙述
eODS 中提出的协议可供性。

ETH 持有者（委托人）

• 作为 ETH 持有者，我想将 ETH 存入DEPOSIT_TO_DELEGATE_CONTRACT ，
  这样我就成为了一个协议认可的委托人，拥有一个注册的execution_address ，并且
  平衡。
  →生命周期： DEPOSIT_TO_DELEGATE_REQUEST_TYPE → PendingDepositToDelegate ，通过 process_pending_deposits_to_delegate 在 epoch 边界进行处理。

• 作为委托人，我想将我的一部分非委托余额委托给验证人，
  这样我的权益就有助于协议安全，并可以通过该运营商获得奖励。
  →生命周期： DELEGATE_REQUEST_TYPE → PendingDelegateRequest ，添加到区块中，在 epoch 上通过process_pending_delegations进行处理。

• 作为委托人，我想将权益从一个验证者重新分配给另一个验证者，而无需退出
  系统，以便我能够有效地对运营商绩效或治理趋势做出反应。
  →生命周期： REDELEGATE_REQUEST_TYPE → PendingRedelegateRequest ，添加到块中，通过DelegationExitQueue触发重新委托路径。

• 作为委托人，我想从验证人处取消委托，并将其返回到我的非委托余额中，
  这样我就保留了稍后重新分配股份或将其撤回给 EL 的能力。
  →生命周期： UNDELEGATE_REQUEST_TYPE → PendingUndelegateRequest ，在区块中添加，在 epoch 耗尽，通过DelegationExitItem分阶段撤回。

• 作为委托人，我希望将 ETH 从我的非委托余额中提取回我的执行地址，以便我在质押系统之外重新获得全部流动性。
  →生命周期： WITHDRAW_FROM_DELEGATOR_REQUEST_TYPE → PendingWithdrawFromDelegatorRequest ，通过get_expected_withdrawals_from_delegators在 block 内处理。

• 作为委托人，我希望我的委托关系可以通过协议观察到，
  这样它们就可以作为验证者协调和潜在治理使用的公共信号。
  →生命周期：委托元数据在DelegatedValidator容器中公开，可通过状态检查查看，但不强制执行。

验证器操作员

• 作为验证者，我想激活我的操作员身份，以便我可以获得委托权益并担任委托验证者。
  →生命周期： ACTIVATE_OPERATOR_REQUEST_TYPE → PendingActivateOperator ，在区块上验证并通过process_pending_activate_operators立即处理。

• 作为验证者，我希望从多个委托人那里获得委托权益，这样我就可以通过声誉而不是仅仅通过资本来扩大我的验证者权重。

• 作为验证者，我想在退出期间与委托人协调早期流动性，以便我可以在完全提款队列延迟之前访问 ETH。
  →生命周期： EARLY_LIQUIDITY_REQUEST_TYPE在内部将委托人发起的提款与操作员凭证以及未来的验证方还款配对。

协议函数

• 作为共识层，我希望通过以下方式接收结构化委托请求
  execution_requests.delegation_operations ，以便我可以在正确的协议定义的时间解释、排队和处理它们。
  →生命周期： DelegationOperationRequest在区块上被调度，并由
  process_delegation_operation_request ，路由到适当的缓冲区。

• 作为协议状态机，我希望对委托执行时间约束，以便
  流失和排队率限制得以维持。
  →生命周期：缓冲区的清空（ process_pending_* ）发生在 epoch，除了
  withdraw_from_delegator在上限为 16 的区块处耗尽。

• 作为会计层，我希望动态维护委托人配额，
  这样奖励/惩罚的计算就能反映委托人和运营商的比例。
  →生命周期：每次与委托相关的状态发生变化时，在DelegatedValidator中重新计算配额，使用并行列表（ delegated_balances 、 delegators_quotas ）。

7. 后续步骤

在这篇文章中，我提出了一项功能，将验证者角色与操作员（
代理人 (代理人) 和委托人 (委托人) 之间的区别，揭示了授权的概念
在协议层面。我提出了一种以太坊可能的委托模型，作为最低规范。
eODS 的模型，可以在不久的将来进行测试和改进。该模型将授权作为一种
选择加入功能，不会修改验证者的共识职责或改变验证者的选择，
委托机制已在前几章中介绍过。可以进一步研究在最小模型的基础上开发新的机制，例如为验证者提供早期流动性，或者开发一种追踪委托及相关指标的方法。

验证者的早期流动性

在限制条件下，验证者可以通过提取以下资金来请求立即获得流动性：
注册委托人持有的闲置（非委托）余额。

• 验证者将发起早期流动性请求。参与的委托人同意
  将部分余额转移到验证者的地址，并收取费用。
• 委托人提取部分可用余额，将 ETH 发送到
  验证者的执行地址。
• 反过来，验证者需要通过标准部分提款来偿还委托人
  其实际余额，通过验证器出口队列路由。
• 还款不是即时的——它是通过现有的协议提款机制处理的——
  保留所有利率限制和削减保证。早期流动性平衡
  从协议的角度来看，可问责的安全是通过从委托人的剩余余额中征收等额的额外保证金来实现的，该保证金将被削减，直到验证人的提款达到exit_epoch为止，从而阻止委托人-验证人的女巫攻击。

此功能可允许验证者在时间敏感的情况下访问 ETH（例如，想要退出或支付应用层的罚款/清算），而不会损害共识的安全性或要求立即退出。

初步治理整合

委托人将根据其股份比例提交对验证者的非约束性偏好。
这些指标可以通过信标链会计扩展向委托人公开，以便
协议可以追踪，社区可以随着时间的推移研究这些可观察的治理偏好信号。协议可见的委托数据可以作为未来更动态的验证者问责制的基础。借鉴Cosmos等区块链的经验，验证者的正常运行时间和不当行为会直接影响委托决策，以太坊中的类似机制可以鼓励验证者保持高性能和透明度，与社区价值观保持一致，从而赢得委托者的更多信任。如果新的信任指标得以开发，验证者的选择就可以考虑到这一点，从而允许理性的资本流向可靠、一致的项目。
操作符。

附录

eODS 注释规范

从开发人员的角度深入了解 eODS，加上规范注释，可以
发现在这里。

执行层变化

在执行层，新增内容如下：

• DEPOSIT_TO_DELEGATE_CONTRACT，与当前的 DEPOSIT_CONTRACT 类似。此合约的事件将以与当前 DEPOSIT_CONTRACT 事件相同的方式在协议内解析：
  ETH 流语义

  • 合约接收 ETH 并发出事件。
  • EL 上的 ETH 资金被烧毁。
  • CL 将等值的 Gwei 记入委托人的余额

• 委托操作请求合约，这是一个专用智能合约，其设计灵感来自于EIP-7002提款请求合约，采用EIP-7685格式进行请求编码。

共识层变化

完整的共识变更可以在以下 GitHub 仓库中找到。它们分为：

• 信标链发生变化。
• 信标链会计新规范文件。
• 叉子选择发生变化。
• 诚实验证者指南发生变化。