原文: Lido on Ethereum Block Proposer Rewards Policy
作者:Lido
發佈時間:2022-09-07
翻譯:satbalwyn - Lido中文社區
状态:v1.0 (合并后软部署)
A. 概要
作為DAO和協議,Lido on Ethereum應該有一個透明,可執行和可監控的策略,關於其組成節點運營商在為作為Lido的一部分運行的驗證者生產區塊的活動所產生的獎勵方面的預期行為,即優先費用和MEV提取,以及協議將如何分配由於這些活動而累積到協議中的獎勵。
B. 目的
本策略旨在概述Lido的節點運營商應如何分配因區塊提議而獲得的獎勵(包括潛在的MEV獎勵),可以使用哪些機製或基礎設施來執行,獎勵將如何分配,以及如何監控這些活動。
C. 範圍
此策略適用於Lido on Ethereum協議,參與該協議的節點運營商以及他們作為協議的一部分運行的驗證節點。
D. 策略陳述
D.1 常規目的
此策略解決了兩個關鍵問題:
節點運營商運行驗證器應該如何提議區塊?
節點運營商運行的驗證者應該如何分配區塊提議所產生的獎勵?
由於以太坊社區內的共識是轉向PBS系統,其中區塊的構建與區塊的提議分離,Lido應該尋求採用一種盡可能接近PBS草案的方法。 Lido可以成為此功能的測試平台,如果出現問題,它比完整的實現更加容易回滾。
在獎勵方面,質押者的存款為驗證者提供動力,因此質押者應始終獲得最大的獎勵份額。
為此,Lido作為一個協議應該:
在技術上可實現的範圍內,強制要求區塊不能由節點運營商構建的,而是由第三方構建的,並從開放透明的區塊構建市場獲得。
要求節點運營商確保將相關獎勵轉移到Lido執行層獎勵金庫,根據LIP-12,該金庫將定期將獎勵質押(減去Lido協議費用),從而從根本上增加質押者獎勵。
盡可能確保提議的區塊是有效的,並且不會損害基礎協議的正常和可持續運行。
監控節點運營商的行為(監控將是公開的)並懲罰被發現不符合上述目標的節點運營商
D.2 節點運營商的要求
D.2.I 優先交易費
優先交易費接收和分配
優先交易費將發送給為驗證節點配置的費用接收方。一般來說,節點運營商應確保優先交易費應發送到Lido執行層獎勵金庫。
以防費用接收方以其他方式被覆蓋(例如,由於執行提取的MEV的區塊,其中費用接收方指向區塊構建者的地址),該區塊必須包含一筆從區塊構建者到Lido執行層獎勵金庫的交易,這邊交易必須包含該區塊總的優先交易費(來自公共交易池的交易費),外加任何額外的MEV摘取的獎勵。
D.2.II MEV和MEV獎勵
Lido的最佳MEV策略是最大限度地提高質押APR和以太坊的安全性,同時最大限度地減少黑暗MEV的存在,並通過運行驗證器(即通過將區塊構建與提案分離)來降低Lido和節點運營商在網絡上的權力。
最大化質押APR
提取MEV對Lido有好處,因為作為一種質押協議,一方面它可以幫助擴大質押用戶規模,另一方面幫助爭取高質量的節點運營商。當質押APR最大化時,上述兩種好處都最大化。如果不執行最大化APR的政策,質押者將更有可能將質押委託給其它的質押提供商,而節點運營商將更有可能繞過Lido並直接向用戶直接推銷自己的業務,他們可能會繼續參與Lido協議,但會試圖以Lido無法監測的方式提取MEV並且不像Lido和其質押者公佈MEV獎勵(即“MEV隱藏”)。
最大化以太坊安全性
提取MEV從經濟層面對協議的安全性有益處: “驗證者'將MEV留在桌面上的'系統是一個明顯的攻擊者補貼很容易獲得的系統。這在純經濟理性模型中會弄巧成拙並降低安全性,因為它會導致集中化和寡頭壟斷。” 為了使區塊鏈最大限度地保持健壯,所有誠實的參與者都需要以最大的程度提取MEV,否則它們會大大降低不誠實的參與者攻擊系統的成本。
最小化隱藏的MEV
MEV隱藏問題定義如下:節點運營商被委託質押以得到質押獎勵的網絡費用。但是,由於節點運營商可以通過直接轉賬或鏈下接收資金,因此通過運行驗證器獲得的實際總獎勵可能會帶來很多不確定性。 Lido可以確保質押者獲得它能看到的獎勵,但無法保證獲得它看不到的獎勵。因此,作為一種協議,它應該嘗試確保所有獎勵都被記錄到鏈上。
一個隱藏MEV的場景是,節點運營商向Lido報告每個區塊包含1個ETH獎勵(他們獲得5%),但隱瞞0.5個ETH額外的獎勵(他們可以100%保留)。對於節點運營商來說,這是一個巨大的胡蘿蔔,但是是以犧牲Lido及其質押者為代價。
偷竊的可能性隨著對獎勵真實規模的了解程度增加而降低。換句話說,這是一個預言機問題。按照上面的例子,如果Lido知道區塊的真實獎勵值為1.5 ETH,節點運營商仍然可以嘗試向Lido報告1 ETH,但盜竊很容易被檢測到。
要解決MEV隱藏問題,需要有一個可靠的預言機報告真正的區塊獎勵(或者區塊獎勵需要從協議層面被確認,例如通過雙槽PBS體系實現)。在協議中實現這樣的解決方案之前,需要使用基礎設施來實現與PBS類似的結果,但必須確保在以太坊協議的當前技術限制範圍內。
最小化區塊控制權
Lido作為質押協議增長的潛力與它所帶來的風險成反比,該風險來源於協議本身的質押量所引出不受檢查的出塊權。通過最小化和分離來自一個協議的大量驗證者的權力(即分離區塊提案權和構建權),Lido可以專注於其職責:最大化質押獎勵並培養優秀的驗證者集。潛在的問題不是Lido想要傷害以太坊用戶,而是Lido無法證明它沒有,或者在某些時候不會,這是一個信任問題。因此,最佳行動方案是最大限度地減少用戶和以太坊生態對Lido和它的節點運營商所需要的信任。
節點運營商從開放市場獲取區塊可以有效地消除了協議對節點運營商正在構建的區塊內容進行影響的可能性,從而降低了協議可能對底層網絡構成的整體風險。
D.3 實現
為了實現上述目標,DAO應定期發現和評估市場上可用的解決方案。此外,所採用的基礎結構和整體解決方案應:
透明、開放(即理想情況下開源代碼)和可監測
在主網上使用之前,所有節點運營商都要進行全面測試
不降低Lido協議或底層網絡(以太坊)的安全性或正常運行
D.3.I 可用的基礎設施
截至最近一次方案更新時,Lido的貢獻者已確定以下基礎設施,這基礎設施可以滿足概述的目標和執行要求:
D.4 監控&懲罰
監控
應實施或利用適當的監控(例如來自第三方的監控),以便:
確定節點運營商的行為是否符合預期
在區塊構建過程中,參與者(例如區塊構建者、中繼器)是善意的,並且符合預期
正常的驗證器和協議操作不會受到MEV相關基礎設施運行的不利影響
懲罰
被發現從事違背策略精神和既定目標的行為的節點運營商將受到以下懲罰:
對於發現不正確或沒有合理分配給協議的金額的,可要求補款
可停止向驗證節點存入新的質押份額
可轉移驗證節點質押份額並結束驗證者任務(自願或通過可觸發的退出,如果可能的話)並從Lido以太坊上驗證者集中排除他們
可對他們在Lido生態系統中的總體地位產生不利影響(例如,減少他們在其他Lido所支持的網絡的委託質押份額,或者直接排除在外)
D.4.I 基礎設施和可用性
有關節點運營商獲取區塊獎勵和可能的MEV提取的表現情況監控可通過兩種方式實現:
由Lido貢獻者管理的基礎設施;此基礎設施應是開放且可公開訪問的
由第三方參與管理並包含Lido相關數據的基礎設施;Lido的貢獻者應與這些第三方合作,以確保與節點運營商相關的數據易於訪問,以便將其集成到第三方分析和報告工具中
有關不同的基礎結構解決方案的監控實現的詳細信息,請參閱每個基礎設施的相關附錄。
D.4.II 監控和懲罰規範
Lido應監控、記錄和評估不遵守本政策的行為。監控和後續行動應至少包括以下內容:
評估節點運營商是否為他們操作的驗證者配置了正確的費用接收地址
評估驗證者所提議的區塊的來源(以及該來源是否合適)
評估每個區塊被提議時所被允許的區塊競標來源的一般可用性
在沒有使用選定的MEV基礎設施構建區塊的情況下,評估提議的區塊是否包含公共內存池中不存在的交易
以區塊為單位,記錄通過選定的MEV基礎設施(以及區塊競價源,例如中繼器)提供的已知最有價值的區塊競標價,即參考區塊
以區塊為單位,記錄驗證者實際提議的區塊及其總交易費用價值,即實際提議區塊
根據每個區塊的數據和歷史數據,分析Lido的每個節點運營商的參考區塊和實際提議區塊之間的價值差異
對於潛在的網絡問題、中繼器錯誤或超出其控制範圍的軟件錯誤,應為節點運營商留出一些餘地。當節點運營商在滾動的DEV_WINDOW時間窗口的時期內,犯錯頻率超過ALLOWED_FREQ_DEV ,且獲得的價值偏離參考區塊超過ALLOWED_VALUE_DEV時,Lido DAO應有足夠的理由懲罰嚴重的不當行為。
D.5 目前採用的解決方案
該部分將由DAO審查,至少每年更新一次,如果需要,可以更頻繁。它詳細說明了節點運營商在當前時間可以使用哪些區塊生產解決方案。
适用期间:合并日- 2022/10/31(除非被最近的DAO投票所更新)
总结:合并后MEV-Boost的软部署
Lido應該幫助以太坊朝著其既定PBS目標前行。
合併後(計劃在9月10日至20日之間發生),節點運營商有大約六週的時間(直到2022年10月底)來測試和實施MEV-Boost,其中產生的塊來自經過DAO審查的中繼器(有關經過審查的中繼信息將存儲在何處以及節點運營商如何檢索它們的詳細信息,請參閱LIP-17 )。此時間段進行軟部署,以便節點運營商可以在策略完全生效之前正確測試和配置其基礎架構。
下面總結了在軟部署期內要努力實現的解決方案:
Lido協議的節點運營商運營的驗證者應通過附錄A.1中詳述的MEV-Boost基礎設施生成區塊,方法是從Lido的"必須包含列表"和"允許名單"中可選數量的中繼中獲取最大可能數量的中繼獲得密封區塊(由每個節點運營商根據自己的風險和法律評估確定)。
如果使用MEV-boost基礎設施導致任何操作故障或者問題(例如,無法生成有效的區塊、根本無法生成區塊、收到的獎勵不正確或缺少適當的中繼器),節點運營商可以回滾到默認的區塊構建方法。
驗證者產生的區塊將根據“監測&處罰”部分和相關附錄的監測部分進行監控。
違反策略規定的節點運營商將受到“監控&處罰”部分所述的處罰。
在軟部署期結束之前,DAO將審查並更新(通過投票)此策略,以便:
如有必要,重新確認或修改已製定的解決方案,並設定新的適用期限;
規定MEV監控和懲罰參數的值;
為最後確定的監測機制提供參考。
E. 定義
區塊構建者
負責組裝區塊的潛在內容(即構成區塊的交易列表)的代理。在工作量證明以太坊中,它是礦工。在權益證明以太坊中,它是驗證者,但此活動可以通過PBS從驗證者任務中分離出來,在這種情況下,為了區塊能被提議,構建者需要向區塊提議者提交要包含的區塊的競標出價。
區塊提議者
負責在區塊鏈中提議新區塊的代理。在工作量證明以太坊中,它是礦工。在權益證明以太坊中,它是驗證者。
MEV
最初應用於工作量證明區塊鏈的“礦工可提取價值”,可更全面的翻譯為“最大可提取價值”。該術語現在用於指代區塊提議者執行選擇,排序並將交易插入區塊的活動中可能提取的潛在價值。
節點運營商
運行驗證器的組織/實體/個人。在Lido協議中,他們作為Lido協議的一部分運行驗證器。
PBS
區塊提議者構建者分離體系,請看:
https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance
https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum (“協議原生區塊提議者構建者分離”章節)
優先交易費
請看: https://ethereum.org/en/developers/docs/gas/#priority-fee
驗證器
請看: https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/#validators 。在Lido協議中,驗證器由Lido協議的第三方節點運營商負責運行。
質押者
持有stETH或則wstETH的用戶或者組織等。
F. 相關資料和文獻
-
I. 修訂記錄
附錄A - Lido MEV實現細節
附錄A.1 MEV-Boost
MEV-Boost是Flashbots開發的非協議原生的PBS。它的工作原理是將出塊任務分離到至少三個角色中:
區塊構建者(負責組裝區塊內容並將其與競標出價一起發送給中繼器)
中繼器(負責聚合,排序和模擬來自構建者的出價,將其發送給區塊提議者(區塊內容事先加密,然後在區塊發布之前被接受後對提議者公開內容)
區塊提議者(負責與中繼器對接,並根據收到的出價選擇最終提議的區塊
注意:
可能有更多的參與者(尤其是區塊構建者的上游),但它們對於此策略並不是特別重要。
節點運營商可能會垂直整合集成上述幾個角色,但在Lido協議要求節點運營商不要運行自己的中繼器(因為這可能允許MEV隱藏或作弊)。
A.1.I 配置
根據A.1.II 中繼器和D.5目前採用的解決方案所述,節點運營商應確保他們正在為Lido運行的驗證器正確註冊相關中繼器。
A.1.II 中繼器
在MEV-Boost中,中繼器可以以驗證器為單位進行配置。 Lido的期望的是,Lido節點運營商將確保Lido on Ethereum協議運行的所有驗證器都能定期更新並正確配置適當的中繼列表。
目前,由節點運營商運行的MEV-boost軟件無法評估(例如通過模擬)從區塊構建者所發送的區塊中的獎勵是否正確,因此他們不能丟棄“壞”或“獎勵低”的區塊。
作為一個當前可用的解決方案,我們需要相信中繼器能做到這一點,這也是Flashbots旨在為中繼器建立一個監控+信譽系統的部分原因。
因此,如果使用MEV-Boost,Lido應該對節點運營商所使用中繼器採取以下要求:
Lido DAO,無論是通過直接方式還是指定的委員會或者小組,都將維護兩個MEV-Boost中繼器列表:
必須包括列表(“must-include list”):經過DAO審查的中繼器,被認為值得信賴、運行良好且可靠。
允許被包括列表(“allow list”):DAO批准但可能不太知名或沒經過實戰檢驗的中繼器,在納入"必須包括列表"之前需要進行測試考核。
對於Lido協議的驗證器,節點運營商應根據每個節點運營商的風險和法律評估,配置其MEV-Boost實例,以連接到“必須包含列表”中所包含的盡可能多的中繼器。此外,他們還可以連接“允許被包括列表”中所包含的任何中繼器。節點運營商不應從未被包含在任一列表的中繼器中獲取區塊。
“必須包括列表”和“允許被包括列表”都應以如下方式進行維護:
相對容易修改更新列表(例如通過公共請求添加新的中繼器或者刪除例如表現不佳的中繼器)
公開列表並方便檢索(對公眾,區塊構建者和節點運營商)。
作為一個開始,強烈建議希望加入這些列表的中繼器必須:
公開可用,
對整個市場開放和維護,
代碼開源
公開透明他們強制執行的(如果有的話)交易或地址過濾策略。
A.1.III 監控
隨著MEV-Boost規範和中繼器API的最終確定,監控規范正在完善,同時請參考https://hackmd.io/@george-avs/SyGqpItIc了解更多。