嵌入式操作者-委托者分离（eODS）规范

eODS (固化操作员-委托人分离) 规范

动机

该项目旨在解决什么问题？为什么它很重要？

目前，ETH 委托人通过质押池，在链下将他们的本金分配给节点运营者。

痛点在于链下的 ETH 委托容易受到外生因素的影响，正如今天在流动性质押中所见，导致质押池的中心化，损害了协议的安全性。委托人没有获得真正的投票权，也没有在协议中发挥有意义的作用。

该项目旨在解决与以太坊协议在委托权益证明的背景下，能够检测到的范围及其自我防御能力相关的低效问题：

• 协议无法“看到” ETH 委托，因此其对验证者的控制范围和能力在这方面受到限制。该项目旨在解决这个问题，帮助协议消除验证者角色的歧义，并“看到”质押场景中的参与者。

  以太坊协议的可信度来自于对执行该协议的验证者的控制。但它只能控制它能看到的东西，因此扩展这些限制非常重要，以便协议有能力对自动化防御系统作出反应。

• 目前，ETH 委托人在协议中没有发挥有意义的作用，因为他们没有积极参与共识。我们可以通过允许协议识别委托的权益并激励委托人角色选择来改善这一点。eODS 模型下的委托人不为 FFG 的经济安全做出贡献，即委托人不参与最终性，但他们能够发现小工具功能中的差异。

  在操作员-委托人分离下的委托人角色：

  • 操作员集合的管理：有主见的委托人可能会根据费用或可靠性等因素在不同的操作员之间做出选择。这些标准可能是 CL 客户端侧或链上开发的验证者评级系统的一部分。
  • 提供非 FFG 服务：委托人可能会被要求提供非惩罚性但至关重要的服务，例如将他们的观点输入到抗审查的小工具（如包含列表）或多重性小工具中。

  允许链上委托并为委托人赋予有意义的角色是任何质押系统的健康指标。当前本金提供者在委托权益证明中发挥的作用仅限于在池内投票，而这最终只是一种有缺陷的投票类型。

• 流动性质押中心化是该领域众所周知的问题，探索解决方案是协议路线图中的一个重要主题。

该项目提出了一个长期关键问题的解决方案：“对于希望通过参与协议获得回报的大型 ETH 持有者来说，以太坊的预期方式是什么”。在功能齐全的固化委托机制中，ETH 持有者将与他们的委托人（执行协议的验证者/运营者）建立直接关系，从而可能缓解流动性质押对质押的“控制”。

协议的哪个领域会受到影响？

实施该项目意味着对执行层 (EL) 和信标链 (CL) 规范进行更改。

项目描述

我提出的解决方案是 eODS 的实现，这意味着在协议层面实施的验证者角色的分离：

将验证者角色分解为操作员和委托人。

该项目提出了一种固化委托流程的方法，以便在 ETH 质押的背景下，在链上映射本金-代理关系。

它旨在通过为委托人提供一种明确的机制来存入/复投和委托他们的本金，从而解决上述低效问题。资本提供者将能够将权益委托给另一个（可能是新的）目标验证者（节点运营者），从而允许他们在选择的运营者方面有自己的主见。所有这些都在链上进行，特别是不以不同于常规存款的方式涉及存款合约。

验证者角色将被分解为两个独立的协议实体：

• 委托人 - ETH 持有者的可选协议角色，他们希望以一种比完整质押操作更轻量级但仍然有意义的方式参与。

• 操作员 - 协议角色，相当于今天的节点运营者，运行共识验证者并执行协议。在委托权益证明的背景下，操作员对委托人负责。

通过 eODS，我们将有两种类型的验证者：

• 参与协议最终性的重型验证者（或为简单起见，以及与当前 PoS 对应的验证者）

• 参与非最终性（轻型）协议服务提供的轻型验证者。

  验证者的操作集将通过将抗审查协议服务（例如 IL）和其他非 FFG 属性转移到轻型验证者的操作集来减少。

主动验证服务 (AVS)，作为委托人角色选择

该项目的第二部分包括用于未来集成轻量级协议服务的即插即用接口的概念设计，以及作为最低预期交付成果的接口 MVP 规范。

在 eODS 下，不同类型的协议服务之间的区别：

• 共识（最终性）服务 - FFG 类型

• 抗审查服务 - AVS 类型

  委托人可以使用在委托给参与 FFG 的操作员后收到的责任证明，来“支持”参与轻量级协议服务的操作员，即 CR 服务，承诺提供“主动验证服务” (AVS)，并可能因提供良好服务而获得奖励。

协议服务的可能分离（以 ePBS 为模型）：

用于添加轻量级协议服务的接口的概念设计：

• 一般设计原则
  • 设计约束
  • 识别轻型和重型操作员以及其他利益相关者
  • 识别服务
    • 最终性小工具
    • 抗审查小工具（例如，包含列表、多重性小工具）
  • 共识服务的经济学
  • AVS 的经济学
  • 不同协议服务的 MVI
• 参考的规范说明：
  • 调整惩罚机制以考虑部分可惩罚的轻量级服务
  • 活跃性
  • 协议安全

第一部分 - eODS 规范

你将如何实施你的解决方案？提供有关该项目的详细信息和更多技术信息。

eODS 设计的最低要求是什么？

• 信标状态中的新实体：委托人作为一个新的类别，类似于验证者，但具有不同的签名域和参与标志索引
• 添加状态委托人索引和余额
• 通过明确委托人向验证者转移 ETH 的方式并引入验证者对委托人的“责任”来映射链上本金-代理关系
• 允许委托人触发的 0x01 提款。

规范概述

下面包含拟议的执行层变更的草图：

Staking-deposit-cli

质押者将 ETH 存入协议，前提是 amount >= MIN_DEPOSIT_AMOUNT。在存款期间，一个派生的 staking-deposit-cli 将允许存款人将布尔值 is_delegator 字段设置为 True 或 False，以及一个智能合约（委托合约）的地址，该合约在被调用时输出目标验证者的索引和公钥。EL 上的存款操作的结构也将相应地获得这两个新字段。

存款合约

存款合约将获得以下参数：is_delegator 和 delegation_contract。DepositData 容器将进行相应的扩展。

下面包含拟议的共识层变更的草图：

eODS 规范将建立在现有以太坊组件规范之上，即 Electra 共识规范。

• 添加新的信标链 class Delegator
• 新的 get_delegator_from_deposit 函数
• 修改后的 apply_deposit 函数以适应委托
• 为新存入的验证者添加 is_delegator == False 条件以进入激活队列
• 将委托添加到区块处理：
  • 在 BeaconState 内构建与验证者注册表并行的委托人注册表。（add_delegator_to_registry）
  • 使 process_deposit_request 处理委托存款和 process_consolidation_request 处理委托验证者的合并
• 添加 state.balances[index] 和 state.delegator_balances[index] 之间的映射
  • 添加新的 Domaintype 以签署委托消息
  • 修改信标区块主体以添加包含的委托消息列表。
  • 添加包含委托验证者的公钥和提款凭证的 DelegationMessage。
  • 添加由签名的委托消息、签名和一个 epoch 参数组成的 Delegation 以设置委托消息的有效性。
  • 修改函数 process_operations 以支持所有新功能
• 启用委托人可触发的退出（0x01 凭证）。

:::warning 在项目实施期间，这些更改中的一些可能会被部分扩展、更改或删除。 :::

第二部分 - 研究委托人角色选择和激励

项目的第一部分开启了固化委托的可能性，并允许本金在代理人（验证者）选择方面有自己的主见。

该项目的第二部分将侧重于定义委托人的操作集或属性。

项目第二部分的最低要求是什么？

• 关于委托人可以拥有的共识角色以及协议如何激励该角色选择的概念设计

• 此功能的规范

我的项目最终产生的 EIP 很可能必须基于 ePBS 分支。将 eODS 与例如 IL 和 ePBS 叠加在 PoS 机制之上并非易事（甚至可能不是理想的），因此在委托人的操作集中抽象出“差异浮出水面”类型的协议服务，可以简化围绕例如 CR 小工具的一些设计。

作为 AVS 提供商，委托人的可能兼容的角色选择：

• 举报人

• 同步委员会

• 由委托人操作的轻量级 CL 客户端上的验证者评分

• 共同签署区块提案、证明

  插槽的验证者的质押公钥将设置为 validator_pubkey $+$ delegator_pubkey。 在这种情况下，将调整惩罚以考虑 delegator_pubkey（两个可惩罚的消息可能具有不同的委托人密钥，但它们将具有相同的验证者密钥）

• 签署抗审查小工具，例如包含列表 $Δ$ 评估、多重性小工具

:::success

可交付成果

可以在此处找到 eODS 功能的规范说明。

可以在此处找到固化的操作员委托人分离功能的 EL 规范：

• deposit-contract

可以在此处找到固化的操作员委托人分离功能的 CL 规范：

• beacon-chain
• validator
• fork-choice :::

  路线图

你提出的时间表是什么？

该项目的拟议时间表为 6 个月，分为 2 个工作包，如下所示：

概述项目的各个部分，并提供有关执行它们所需时间的见解。

I. 第一部分 - eODS 规范说明

1. 在 8 周内（第 6 周 - 第 13 周）原型化 eODS，包括获得导师的反馈。

2. 编写案例研究，并原型化 eODS 定义的协议对象的 API，包括在 4 周内（第 14 周 - 第 17 周）获得导师的反馈。

II. 第一部分 - 研究委托人角色选择和激励

1. 我已经在 EPF 之前的几周内完成了一些与此阶段相关的工作，尤其是在 EPS 期间，我计划在 4 周内（第 17 周 - 第 21 周）完成委托人提供的协议服务集成的概念设计，包括获得导师的反馈。
2. 我计划编写 eODS 规范，包括在额外的 4-8 周窗口内（第 21 周+）获得导师的反馈和案例研究测试。我将在 EPF 计划时间跨度之后继续进行，直到完成此功能为止。

可能的挑战

你需要克服哪些限制和问题？

• Electra 分支规范正在积极开发中

• 数据复杂性 :::warning 添加额外的信标链状态元素的内存成本 ::: 要考虑的消耗计算：

  • 签名验证

• 将 eODS 与正在进行的研发集成在一起，例如，ePBS、IL 最有可能不是一项简单的任务

• 定义委托人的属性必须考虑到诸如现有协议激励以及维持 PoS 安全假设等方面

项目目标

成功的样子是什么？描述项目的最终目标、范围、状态和影响，以便将项目视为已完成且成功。

该项目的最终目标是完全规范 eODS。

预期的影响/后续行动：

• eODS EIP
  • 第一部分可以自行发挥作用
  • 第二部分可以稍后添加
• 如果我的项目可以作为未来 POC 和客户端实现的基础，我将认为它是一个成功
  • 完整节点
  • 轻客户端

我看到以下现实情景：

• 在 EPF 期间完成第一部分，以及第二部分的概念设计以及尽可能多的第二部分规范。
• 如果未在 EPF 项目时间范围内完成，则在 EPF 之后的几个月内完成第二部分规范。
• 根据第一部分规范提出 eODS EIP
• 根据第二部分规范提出 EIP

合作者

研究员

目前，没有其他研究员与我合作进行此项目。

导师

Barnabé Monnot Potuz

资源

第 0 周研究笔记

[1] 解绑质押

[2] 可以改善去中心化并减少共识开销的协议和质押池更改

[3] 以太坊应该可以接受在协议中固化更多东西吗？

[4] EIP-7215

[5] EIP- 6110

[7] Electra 分支共识规范

[8] EPF.wiki eODS 页面

[9] Orbit SSF

版权和相关权利通过 CC0 放弃。

• 原文链接： github.com/eth-protocol-...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～