抽象的
此 EIP 草案引入了一種機制，讓擁有 BLS (0x00) 提款憑證但無法訪問其提款助記詞的以太坊驗證者可以安全地將其憑證更新為執行層 (0x01) 憑證。該機制受到共識層提款提案 (CLWP) 概念的啟發，使用驗證者控制和存款來源的加密證明。此外，它還為託管權益池運營的驗證者定義了一條途徑，通過合作驗證實現相同的更新，從而幫助廣泛受影響的參與者恢復。
動機（已更新）
在以太坊過渡到權益證明後，使用基於 BLS 的 (0x00) 提款憑證註冊的驗證者必須遷移到執行層 (0x01) 憑證才能訪問和提取其質押的ETH。然而，許多驗證者尚未完成此遷移 — — 有些驗證者已經失去了授權憑證更改所需的助記詞的訪問權限，導致其ETH被有效鎖定。
該提案使此類驗證者能夠使用對以下兩者的控制加密證明，以安全、可驗證的方式恢復訪問權限：
- 驗證者簽名密鑰，以及
- 原始存款地址。
此外，大量驗證者通過託管質押提供商（質押池）進行操作，其中驗證者簽名密鑰由提供商持有。該提案概述了一個受控的、基於同意的流程，其中存款人可以啟動恢復，而質押池通過生成所需的驗證者簽名進行合作 — — 但只有在獲得存款人的明確授權的情況下。
長期動機：BLS 貶值和量子風險
BLS 提款憑證 (0x00) 依賴於 BLS12-381 橢圓曲線加密，這種加密不具備量子安全性。在擁有足夠強大的量子計算機的情況下，可以使用 Shor 算法從公鑰中派生出私鑰，這使得 BLS 憑證容易被盜。
相比之下，執行層憑證（0x01）利用基於以太坊賬戶的加密技術，作為未來協議升級的一部分，該加密技術可以更容易地遷移到抗量子方案。
因此，以太坊生態系統將來可能需要完全棄用 BLS 憑證。此提案是該過渡的重要前期工作，其特點如下：
- 為當前無法訪問的 0x00 驗證器建立強大的恢復機制。
- 定義原始助記符流之外的驗證器憑證更新的標準模式。
- 為未來遷移到後量子提款格式準備驗證器集。
這確保了以太坊可以維護健康的驗證器集，防止永久性的ETH丟失，並減少網絡範圍內 BLS 棄用的最終協調負擔。
規格
範圍
此機制僅適用於：
- 具有 0x00 BLS 提款憑證的驗證者。
- 尚未退出或提取資金的驗證者。
- 助記詞（提現密鑰）丟失或者無法獲取的情況。
1. 非託管驗證者（自營）
所有權證明流程
驗證者可以通過提交兩個加密簽名來請求憑證更新。此過程概述於https://github.com/eth-educators/update-credentials-without-mnemonic和https://ucwm.xyz
- 驗證者密鑰庫簽名
驗證者使用其驗證者密鑰和以太坊 deposit-cli 創建密鑰存儲簽名。 - 存款地址簽名
原始存款地址（通過存款合約為驗證者提供資金的地址）通過 Beaconcha.in 簽署消息。
這些簽名連同元數據（驗證器索引、目標執行地址）一起提交給鏈上憑證更新合約或公認的鏈下協議。
驗證和更新
- 兩個簽名都會根據具有 BLS 憑證的驗證者列表進行驗證，並且存款地址也會經過手動驗證。
- 挑戰期（例如 XX-XX 個月）允許社區對任何欺詐性索賠提出異議。
- 如果成功，驗證者的提款憑證將從 0x00 更新為 0x01，並指定執行地址。
- 這些驗證者將被添加到退出隊列中，遵守現有的退出率限制，以避免破壞網絡穩定。
2. 託管權益池驗證者
問題背景
對於通過託管質押提供商運行的驗證者，驗證者私鑰由質押池而非存款人持有。這使得存款人無法自己生成驗證者密鑰簽名。
擬議的託管流程
- 存款人聲明（鏈上意圖）
存款人（資金地址的所有者）通過 Beaconcha.in 簽署一條消息並在鏈上提交，內容如下：
- 他們對特定驗證器的控制（通過索引或公鑰）。
- 他們要求更新提款憑證。
- 他們的目標執行地址。
- 運營商審核和權益池協調
- 值得信賴的多重簽名、DAO 或ETH Staker 社區機構審查該聲明。
- 他們驗證存款來源和驗證者狀態。
- 他們聯繫權益池來確認存款人的關係。
- 權益池簽名
經過驗證後，權益池將遵循與上述相同的流程來創建驗證者密鑰存儲簽名。 - 最終提交和挑戰階段
- 已提交與存款人的鏈上聲明相關聯的礦池驗證者簽名。
- 挑戰期開始。
- 經批准後，提款憑證將會更新。
- 最後，這些驗證器被添加到退出隊列。
基本原理
- 最大限度地減少ETH損失：幫助資金被永久鎖定的驗證者進行恢復。
- 雙重認證：使用驗證器密鑰和存款密鑰可確保強大的身份保證。
- 權益池路徑：為託管驗證者提供協作、安全且同意驅動的路徑。
