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 倉庫中找到。它們分為：

• 信標鏈發生變化。
• 信標鏈會計新規範文件。
• 叉子選擇發生變化。
• 誠實驗證者指南發生變化。