Alert Source Discuss
Standards Track: Interface

EIP-4736: 共识层提款保护

当共识层助记词可能被泄露时，为 BLSToExecutionChange 操作提供额外的安全性，而无需更改共识

Authors Benjamin Chodroff (@benjaminchodroff), Jim McDonald (@mcdee)
Created 2022-01-30

Table of Contents

摘要

如果共识层助记词短语泄露，共识层网络无法区分密钥的合法持有者和非法持有者。然而，有一些信号可以在更广泛的意义上考虑，而无需改变以太坊核心共识。本提案概述了链上证据（如执行层存款地址和已签名消息列表）如何创建社会共识，从而显著有利于（但不能保证）合法的助记词持有者在与攻击者的竞争中获胜。

动机

对于确定其密钥和助记词未被泄露的单个用户而言，共识层 BLSToExecutionChange 消息是安全的。但是，由于在 Capella 硬分叉之前，共识层上的验证者提款是不可能的，因此在 BLSToExecutionChange 上链之前，没有任何用户可以绝对确定其密钥未被泄露，而到那时再进行更改就为时已晚。所有合法的助记词短语持有者最初都控制着执行层存款地址。信标节点客户端和节点运营商可以选择加载可验证的 BLSToExecutionChange 消息列表以进行广播，这可能会创建社会共识，使合法持有者能够成功地赢得与攻击者的竞争。如果攻击者入侵了大量的共识层节点，将对整个以太坊社区构成风险。

直到 2021 年 3 月 23 日，v1.1.1 的以太坊 2.0 存款 CLI 才支持将提款地址设置为执行层地址，这使得早期采用者希望他们可以更早地强制将其执行层地址设置为存款地址。强制进行此更改在协议中是无法强制执行的，部分原因是信标链上缺少有关执行层存款地址的信息，部分原因是这从未被列为一项要求。执行层存款地址也可能不再受提款私钥的合法持有者的控制。

但是，各个节点可以以不改变共识的方式，在本地限制它们希望包含在它们提议的区块中，并在网络中传播的更改。客户端节点还可以帮助广播已签名的 BLSToExecutionChange 请求，以确保尽可能多的节点以公平的方式尽快见证此消息。此外，可以将此类 BLSToExecutionChange 已签名消息预先加载到客户端中，以进一步帮助节点过滤攻击请求。

本提案提供纯粹可选的附加保护。它旨在请求节点优先考虑提款凭证声明，在两个冲突的 BLSToExecutionChange 消息的情况下，该声明有利于可验证的执行层存款地址。它还建立了一个 BLSToExecutionChange 已签名消息列表，以帮助在网络支持时“尽快”广播，并鼓励客户端团队帮助使用这些列表来履行过滤和优先接受 REST 请求并通过 P2P 传输它们。这不会改变共识，但可能有助于防止传播攻击，在这种攻击中，提款密钥已被有意或无意地泄露。

至关重要的是要理解，本提案不是共识更改。本提案中的任何内容都不会限制协议内提款凭证操作的有效性。这是客户端团队自愿进行的一项更改，即将此功能构建到其信标节点中，也是节点运营商自愿进行的更改，即接受最终用户建议的任何或所有限制和广播功能。

由于上述原因，即使完全实施，也将取决于哪些验证者提议区块，以及这些验证者的信标节点正在运行哪些自愿限制。节点运营商可以尽其所能地帮助社区防止对任何已泄露的共识层密钥的攻击，但不能保证此举能够防止攻击成功。

规范

共识层 BLSToExecutionChange 操作具有以下字段：

  • 验证者索引
  • 当前提款 BLS 公钥
  • 建议的执行层提款地址
  • 前述字段的提款私钥签名

本提案描述了客户端信标节点可以实现的 OPTIONAL（可选）和 RECOMMENDED（推荐）机制，并且 RECOMMENDED（推荐）最终用户在其信标节点操作中使用。

BLSToExecutionChange 广播文件

信标节点客户端 MAY（可以）支持一个 OPTIONAL（可选）文件，该文件指定“验证者索引”、“当前提款 BLS 公钥”、“建议的执行层提款地址”和“签名”的行，如果已实现且已提供，则 SHALL（应）指示节点在 Capella 硬分叉时自动提交每个有效签名的一次性 BLSToExecutionChange 广播消息。此文件 SHALL（应）为所有节点运营商提供一个 OPTIONAL（可选）机会，以确保任何有效的 BLSToExecutionChange 消息在 Capella 硬分叉时被节点广播、听到和共享。此 OPTIONAL（可选）文件 SHALL（还应）指示节点永久优先接受和重复与文件中签名匹配的签名，并且 SHALL（应）拒绝接受或重新广播与给定提款凭证的签名不匹配的消息。

BLSToExecutionChange 处理

RECOMMENDED（推荐）信标节点客户端允许接受可验证签名的“BLSToExecutionChange 广播”文件，然后 MAY（可以）回退以接受通过 P2P 发送的“第一个请求”。本提案的所有内容对于信标节点而言都是 OPTIONAL（可选）的，可以实现也可以不实现，但是 RECOMMENDED（推荐）所有客户端团队在 Capella 硬分叉之前允许本地加载“BLSToExecutionChange 广播文件”。此 OPTIONAL（可选）保护将允许用户在网络支持时尽快尝试设置提款地址消息，而无需更改共识。

理由

本提案旨在保护合法验证者助记词持有者，因为他们的助记词在知情或不知情的情况下被泄露了。由于没有安全的方法可以在不退出的情况下转移验证者的所有权，因此可以安全地假设所有验证者持有者都打算设置为他们指定的提款地址。在考虑共识时，不可能使用执行层中的存款地址来确定合法持有者，因为它可能追溯到很久以前的历史，并会维护这样一个列表造成过重的负担。因此，本提案概述了可选机制，该机制可保护合法的原始助记词持有者，并且不会对客户端节点软件或运营商造成任何强制性负担。

向后兼容性

由于在 Capella 之前没有现有的 BLSToExecutionChange 操作，因此没有记录在案的向后兼容性。由于该提案的所有内容在实现和操作上都是 OPTIONAL（可选）的，因此预计未实现此功能的客户端信标节点仍然与实现部分或全部此提案中描述的功能的任何或所有客户端完全向后兼容。此外，尽管 RECOMMENDED（推荐）用户启用这些 OPTIONAL（可选）功能，但如果他们决定禁用或忽略某些或所有功能，甚至故意加载与预期目的相反的内容，则信标节点客户端将继续与网络的其余部分完全兼容地执行，因为该提案中没有任何内容会更改以太坊核心共识。

参考实现

BLSToExecutionChange 广播文件

一个“change-operations.json”文件，旨在预加载所有共识层提款凭证签名和可验证的执行层存款地址。该文件可以由脚本生成，并且能够由社区成员使用共识层节点独立验证，并且旨在包含在所有客户端中，默认情况下启用。鼓励客户端节点启用随附客户端软件的此独立可验证列表的打包，并默认启用它，以帮助进一步保护社区免受意外攻击。

change-operations.json 格式是组合成单个 JSON 数组的“BLSToExecutionChange 文件 - 声明”。

BLSToExecutionChange 广播文件 - 声明

社区收集和独立可验证的“BLSToExecutionChange 广播”列表，其中包含将被收集的可验证声明。节点运营商可以独立验证这些声明，并建议在兼容的信标节点客户端中加载声明。

为了提出可验证的声明，用户 MAY（可以）将声明上传到文本文件“[chain]/validatorIndex.json”（例如“mainnet/123456.json”）中的任何公共存储库。

123456.json:

[{"message":{"validator_index":"123456","from_bls_pubkey":"0x977cc21a067003e848eb3924bcf41bd0e820fbbce026a0ff8e9c3b6b92f1fea968ca2e73b55b3908507b4df89eae6bfb","to_execution_address":"0x08f2e9Ce74d5e787428d261E01b437dC579a5164"},"signature":"0x872935e0724b31b2f0209ac408b673e6fe2f35b640971eb2e3b429a8d46be007c005431ef46e9eb11a3937f920cafe610c797820ca088543c6baa0b33797f0a38f6db3ac68ffc4fd03290e35ffa085f0bfd56b571d7b2f13c03f7b6ce141c283"}]

声明接受

为了将提交合并到公共存储库中，该提交必须具有：

  1. 格式为 validatorIndex.json 的有效文件名
  2. 在共识层上处于活动状态的有效验证者索引
  3. 可验证的签名
  4. 单个验证者的单个更改操作，文件中包含所有必需的字段，没有其他内容

所有失败的合并请求都将提供上述原因，必须在合并之前解决。对已接受声明的任何未来可验证的修改必须由同一提交者提出，否则将被视为争用。

BLSToExecutionChange 广播

社区中的任何人都将能够使用 Capella 规范和命令行客户端（例如支持该规范的“ethdo”）独立验证所提供声明中的文件。

如果收到的声明中，两个或多个提交之间的可验证共识层签名不同，并且任何一方都未证明执行层存款地址的所有权，则该声明将被视为有争议的。如果向存储库发送有争议但已验证的“BLSToExecutionChange 广播”请求，则可以通知所有各方，并且可以通过提供任何公开可验证的链上证据或链下证据来支持他们的声明，从而说服更广泛的社区将其声明包含在节点中。节点运营商可以根据社会共识决定他们希望包含哪些可验证的声明。

安全考虑

1：攻击者缺少 EL 存款密钥，无争议的声明

  • 用户 A：控制 CL 密钥和用于存款的 EL 密钥
  • 用户 B：控制 CL 密钥，但不控制用于存款的 EL 密钥

用户 A 签名并将声明提交到 CLWP 存储库，客户端将用户 A 消息加载到“BLSToExecutionChange 广播”文件中。在第一个 epoch 支持 BLSToExecutionChange 时，许多（并非所有）节点开始广播该消息。用户 B 还尝试将不同的但有效的 BLSToExecutionChange 提交到与声明中的签名不匹配的地址。此消息已通过 REST API 成功接收，但某些（并非所有）节点开始静默删除此消息，因为签名与“BLSToExecutionChange 广播”文件中的签名不匹配。因此，这些节点不会通过 P2P 复制此消息。

2：攻击者既有 EL 存款密钥又有 CL 密钥，无争议的声明

  • 用户 A：控制 CL 密钥/助记词和用于存款的 EL 密钥，并提交声明以转移到新地址
  • 用户 B：控制 CL 和 EL 密钥/助记词（用于 EL 存款），但未能提交声明

用户 A 可能/很可能会注意到他们在 EL 存款地址中的所有资金已被盗。这可能表明他们的 CL 密钥也已泄露，因此他们决定为提款选择一个新地址。故事的结局与场景 1 相同，因为该声明是无争议的。

3：与 #2 相同，但攻击者提交了有争议的声明

  • 用户 A：控制 CL 密钥/助记词和用于存款的 EL 密钥，并提交声明以转移到新地址
  • 用户 B：控制 CL 密钥/助记词和用于存款的 EL 密钥，并提交声明以转移到新地址

这是一个有争议的声明，因此无法使用链上数据证明谁在控制。相反，任何一个用户都可以尝试说服社区他们是合法的拥有者（身份验证、社交媒体等），试图让节点运营商将他们有争议的声明加载到他们的“BLSToExecutionChange 广播”文件中。但是，没有办法完全证明这一点。

4：用户丢失了他们的 CL 密钥和/或助记词（没有提款密钥）

  • 用户 A：缺少 CL 密钥和助记词

无法通过本提案恢复此方案，因为我们无法证明用户已丢失其密钥，并且生成提款密钥需要助记词。

5：终局 - 攻击者

  • 用户 A：控制 EL 和 CL 密钥/助记词，成功完成设置地址提款
  • 用户 B：控制 CL 密钥，决定攻击

在注意到用户 A 已成功提交设置地址提款后，用户 B 可能会运行验证者并尝试让用户 A 被罚没。怀疑其验证者密钥或种子短语已泄露的用户应尽早采取行动退出其验证者。

6：密钥已泄露，但不会受到提款的影响

  • 用户 A：控制 EL 和 CL 密钥/助记词，但存在一个漏洞，该漏洞泄露了他们的 CL 密钥，但没有泄露他们的 CL 助记词
  • 用户 B：控制 CL 密钥，但缺少 CL 助记词

用户 A 可以生成提款密钥（需要助记词）。用户 B 可以通过让他们被罚没来攻击用户 A，但将无法生成提款密钥。

7：攻击者将恶意的 BLSToExecutionChange 广播文件加载到一个或多个节点中，用户 A 提交声明

  • 用户 A：提交有效的无争议声明，该声明由许多节点尽快广播出去
  • 用户 B：未提交任何声明，但通过他们的 BLSToExecutionChange 广播列表广播有效的恶意声明，并阻止用户 A 的声明从他们的节点发送。

用户 B 的声明将进入许多节点，但当它到达采用用户 A 的签名的节点时，它们将被删除且不会重新广播。从统计上看，用户 B 将更难在整个社区中达成共识，但这将取决于机会。

8：与 #7 相同，但用户 A 未提交任何声明

攻击者很可能在统计上获胜，因为他们将是第一个将其消息广播到许多节点的攻击者，并且除非用户 A 在支持时准确地提交请求，否则不太可能被足够的节点听到以获得共识。因此，鼓励所有用户提交声明，因为在为时已晚之前，没有人能确定其助记词未被泄露。

二阶效应

  1. 参与“BLSToExecutionChange 广播”的用户可能会导致攻击者提前放弃并开始进行罚没。对于某些用户而言，被罚没的想法胜过将任何资金交给对手。由于该提案是自愿的，因此如果用户担心这种情况，可以选择不参与。
  2. 攻击者可以设置自己的 BLSToExecutionChange 广播以拒绝与他们的攻击不匹配的签名。无论有没有本提案，这都是可能的。
  3. 攻击者可能是为本提案收集“BLSToExecutionChange 广播”声明的人，并且可能会故意拒绝合法的请求。任何人都可以自由地建立自己的社区声明收集并使用本提案中描述的相同机制来聚集他们自己的社区支持，以形成替代的社会共识。

版权

Copyright and related rights waived via CC0.

Citation

Please cite this document as:

Benjamin Chodroff (@benjaminchodroff), Jim McDonald (@mcdee), "EIP-4736: 共识层提款保护," Ethereum Improvement Proposals, no. 4736, January 2022. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-4736.