增加以太坊退出隊列的靈活性
本文推動了最近提出的EIP-7922 。
^src： https://www.youtube.com/watch? v=bl91wk5fB4g
作者： mike neuder 、 malesh pai 、 mikhail kalinin (mik-mal-mik) – 2025 年 4 月 1 日
\uparrow ↑但不是愚人節玩笑
內容
1. Introduction
2. Revisiting the current exit queue
3. Improving the exit queue
4. Connection to past work
總結；我們描述了EIP-7922中提出的以太坊出口隊列的潛在變化。我們的ELI5文章討論了以太坊今天如何管理驗證者退出以及布拉格/Electra 升級中即將發生的變化。這篇文章主張對佇列進行額外的改變，以提高其效率，而無需改變協議的安全模型。
1. 簡介
以太坊中的權益證明機制實現了退出隊列，以確保最終交易的可信賴安全性（更多背景資訊請參閱「為什麼要有退出隊列？」 ）。雖然限制驗證者退出率（有時稱為驗證者流失）是必要的，但過度限制會影響誠實的驗證者，因為他們如果需要退出則面臨長時間延遲的風險。這對協議來說也是成本高昂的：標準金融理論告訴我們，相對缺乏流動性的資產必須提供更高的報酬率才能吸引相同數量的資本。此項規定在必要的情況下也適用於質押。因此，在遵守協議安全約束的情況下，出口隊列應該盡可能有效率。
在本文中，我們提出了EIP-7922 ，該提案基於我們對出口隊列設計的研究，提出添加動態流失限制。這項變革大大提高了驗證者的生活質量，同時又不損害以太坊的安全性。
2. 重新檢視目前的退出隊列
如「 退出流程」所述，自願退出的第一階段是退出隊列。 「流失」限制決定了在給定時期內可以退出的驗證者數量，目前計算為\max(8, \lfloor \# \text{ validators} / 2^{16} \rfloor) max ( 8 , ⌊ # validators / 2 16 ⌋ ) （ get_validator_activation_churn_limit 03 月 20 月 25 月； lfloor 1,065,882/2^{16} \rfloor=16 ⌊ 1 , 065 , 882 / 2 16 ⌋ =每個時期16 次退出（例如，如果隊列中有 160 個驗證者，則新入隊的驗證者將在 10 個時期後退出）。
回想一下，我們限制利率是為了確保交易的經濟安全性不會下降太快。理解每個時期 16 次退出安全模型的另一種方式是，它圍繞驗證器退出編碼以下「約束」：
- 下一個 epoch 最多有 16 位驗證者退出，並且
- 在接下來的兩個時期內，最多有 32 名驗證者退出，並且
- 在接下來的三個週期內，最多有 48 位驗證者退出，並且
… - 在接下來的 n 個期間內，最多有 16 \cdot ⋅ n 個驗證者退出，
…
等效地，對於 1,065,882 個驗證者，我們可以將這些限制描述為最終交易的經濟安全性下降率。交易的經濟安全性減少的幅度不超過：
- 16/1,065,882 = 0.0015\% 16 / 1 , 065 , 882 = 0.0015 %在一個時期內，
- 32/1,065,882 = 0.0030\% 32 / 1 , 065 , 882 = 0.0030 %分為兩個時期，
… - 3600/1,065,882 = 0.34\% 3600 / 1 , 065 , 882 = 0.34 %在 225 個時期（一天）內，
… - 50,400/1,065,882 = 4.7\% 50 , 400 / 1 , 065 , 882 = 4.7 %在 3,150 個時期（兩週）內，
… - 108,000/1,065,882 = 10.1\% 108 , 000 / 1 , 065 , 882 = 10.1 % ，在 6,750 個時期（30 天），
… - 324,000/1,065,882 = 30.4\% 324 , 000 / 1 , 065 , 882 = 30.4 %在 20,250 個時期（90 天），
這些限制很容易解釋。例如，我們可以將（5）理解為「最終確定的交易在未來 30 天內的損失不會超過其可信賴安全性的 10%」。回想一下，雖然交易的經濟安全性隨著時間的推移而降低，但長期重組/安全故障的機率也會降低。因此，隨著時間的推移，交易的結算保證仍然保持極高水準。
關鍵觀察：上述一些限制對協議來說更為重要，因此，無論歷史提款情況如何，每個時期只允許 16 次退出是過於嚴格的。
我們透過一個例子來說明這一點。由於驗證者人數為一百萬，現行協議規定每個時期可以有 16 個驗證者退出。兩週內，這相當於 50,400 次退出。這直接意味著「兩週內退出的驗證者不得超過 5.04%（等同於股權）。」我們假設這是協議關心的唯一約束。現在想像一下，在過去的 13 天裡，沒有驗證者退出協議，因此，兩週的流失限制都沒有被使用。如果佔驗證者總數 3%（30,000 名驗證者）的大型質押業者想要立即提款，他們應該能夠這樣做 - 這並不違反兩週 5.04% 的限制。然而，由於每個時期只能處理 16 個退出，因此他們被迫等待 1875 個時期（相當於 8.33 天）。
關鍵觀察：如果我們啟用協議來回顧退出歷史記錄，我們就不再需要對每個時期進行嚴格的限制。
例如，在目前提出的EIP-7922中，我們明確選擇了以下約束：
建議的弱主觀性限制：在任何連續的兩週內，驗證者退出的數量不得超過 50,400 個。
然後，我們只需要確保在每個連續的兩週內都遵守約束，而無需在每個時期都設定退出限制。根據歷史驗證器退出資料動態調整的流失限制允許以太坊靈活地適應退出需求的高峰，同時在每兩週內保持相同的安全性。
3. 改善出口隊列
EIP-7922實現了這項變更。我們首先根據「 ETH數量」而不是「驗證者數量」來重新計算退出金額，因為根據EIP-7251 ，驗證者的餘額可能有所不同。再次，以今天的價值計算，我們大約有 34 毫米的ETH被質押。這相當於每個時期有 16 \cdot ⋅ 32 = 512 ETH符合流失條件。由於 EIP-7251 的複雜性，每個時期的退出流失限制上限為 256 ETH （有關更多詳細信息，請參閱“2.2 - 退出隊列流失限制變化” ）。在 3584 (= 256 \cdot ⋅ 14) 個時期內（約 17 天，下文中我們用其作為近似的弱主觀性時期），總計有 256 \cdot ⋅ 3584 = 917504 ETH （佔已質押的 3400 萬ETH %）可以退出。
我們提出的 EIP 將這些值編碼為出口佇列保證的單一約束：
EIP-7922 限制（使用現今的質押數量） －17 天內可流失的ETH不得超過 917504 (=256 \cdot ⋅ 256 \cdot ⋅ 14)（佔質押總量 3,400 萬ETH的 2.7%）。
至關重要的是，這一單一約束仍然是確保協議弱主觀性保持完整的關鍵。透過在更短的時間範圍內為出口隊列提供更大的靈活性，該機制可以提高響應速度而不會損害安全性。下圖展示了所提議的變更。
圖 1.兩個佇列都實現了相同的約束，確保在M+1 M + 1 個紀元時間範圍內不會發生超過16 \cdot (M+1) 16 ⋅ ( M + 1 )次退出。當前隊列透過設定每個時期允許退出次數的限制來強制執行這一點。我們提出了一個簡化的隊列，可以明確檢查過去M+1 M + 1 個時期的單一限制。
有關該機制如何實現的更多詳細信息，請參閱EIP-7922 。如1. Introduction中所提到的，目前退出隊列的限制對ETH資產產生了財務影響。我們相信這次升級將對以太坊的質押生態系統產生深遠的影響：
- 降低質押溢價：透過減少延遲和相關的流動性風險，這些機制可以降低吸引資本所需的質押獎勵。
- 提高資本效率：更靈敏的退出機制使更廣泛的以太坊生態系統中的資本配置更加動態。
- 增強協議穩健性：更好的退出機制降低了驗證者在市場波動事件期間被「困住」的風險。
值得注意的是，可處理的提款數量仍然存在硬性限制，且該提案不保證任何退出速度。相反，其目的是讓退出隊列在處理提款需求突然激增時有更大的彈性。我們歡迎社群提出回饋，我們致力於將其納入未來的網路升級。
4. 與過去工作的聯繫
這個 EIP 直接擴展了我們與Max Resnick合作撰寫的關於最佳出口隊列的先前論文。在這項工作中，我們引入了動態佇列系統MINSLACK 。與此 EIP 類似，MINSLACK 不是在每個時期處理恆定的最大驗證者數量，而是根據歷史資料和給定的安全約束集合來計算可以安全退出的驗證者數量。具體來說，它檢查「鬆弛」——最近幾個時期未使用的提款能力——以確定允許的退出。 MINSLACK 利用了這個鬆弛，它認識到如果前幾個時期退出的驗證者數量少於允許的最大值，則協議可以在當前時期安全地處理更多的退出，同時在整個時間窗口內保持相同的整體負責任的安全保障。
此 EIP 是 MINSLACK 的簡化版本，僅實作了3. Improving the exit queue中所述的單一約束。我們的分析證明，當所有驗證者的退出緊迫性相似（同質值）時，MINSLACK 是最佳的。簡單來說，在以太坊的安全性前提下，MINSLACK 實現了最快的退出速度。基於這個理論框架，我們相信具有對弱主觀性時期進行編碼的單一約束的 MINSLACK 演算法可以改善現狀。如果社群認為需要在不同時間範圍內增加更多約束，則此 EIP 可以輕鬆擴展以實現完整的 MINSLACK 演算法。此外，我們的論文也檢視了退出競標優先權的能力。我們表明，MINSLACK 的修改版本根據出價大小對佇列進行排序（實現優先權佇列）在異質值設定下幾乎是最佳的。這可以作為退出隊列流程的額外後續改進，如果社區感興趣，我們很樂意進行討論。
–
用
以及 mik-mal-mik 的 markdown
