熱門資訊> 正文
從重新設計角度理解EigenLayer
2024-03-19 19:24
來源：登鏈社區
在這篇博客文章中，我們將帶你瞭解 EigenLayer 協議的演變，介紹 EigenLayer 架構是如何從最初的概念中產生的。
雖然很多人熟悉 restaking 和 EigenLayer 這些術語，但只有少數人知道我們的核心合約包含數千行代碼[11] ，其架構如下。
一個看似簡單的想法為何變得如此複雜？
在這篇博客文章中，我們將通過介紹 EigenLayer 當前複雜架構是如何從最初概念中產生的，來帶你瞭解該協議的演變。
本文的目標讀者是對智能合約有基本瞭解並聽説過 EigenLayer 或 restaking 的人。
現在，讓我們開始吧。
首先，讓我們先介紹 EigenLayer 要解決的問題。如果你已經熟悉這部分內容，請跳到后面的章節。
在以太坊上構建去中心化基礎設施的開發人員面臨着建立自己的經濟安全的挑戰。雖然以太坊為智能合約協議提供了經濟安全，但橋或排序器等基礎設施需要自己的經濟安全，以實現節點的分佈式網絡達成共識。
共識機制對於促進這些節點之間的互動至關重要，無論是 L1、預言機網絡還是橋。
工作量證明[13]耗能嚴重， 權威證明[14]過於集中化，因此權益證明[15] （PoS）已成為大多數基礎設施項目的主要共識機制。
然而，啟動新的 PoS 網絡很困難。
首先，很難確定質押者（提供質押的人）在哪里。沒有一個好的地方供開發人員找到質押者。
其次，質押者必須投入大量資金來獲得新網絡的質押，通常是通過購買網絡的原生代幣，他們通常是波動的且難以獲得。
第三，質押者必須放棄其他的獎勵機會，比如以太坊提供的 5% 獎勵。
最后，當前的安全模型不理想，因為破壞任何 dApp 的成本只是破壞其最脆弱的基礎設施依賴所需的成本。
EigenLayer 被創建來解決這些問題：
EigenLayer 泛化了提供經濟安全的概念。
EigenLayer 是一個平臺，質押者可以為任何基礎設施項目提供質押，基礎設施項目可以在 EigenLayer 上向潛在質押者推介。該平臺的支柱是使質押者能夠為不同的基礎設施做出可信承諾。
這些承諾適用於所有權益證明系統，不僅僅是 EigenLayer。L1 質押者通常承諾遵循協議規則，並冒着如果在同一區塊高度簽署衝突區塊而失去質押的風險。
基礎設施開發人員構建基礎設施邏輯和軟件，而質押者提供質押以保障基礎設施。_這個 質押 作為 承諾 提供給基礎設施的用户。_ 這個 承諾 是爲了協議的順利運行，反對特定的不端行為。
從概念上，當一個項目背后有 1 億美元的質押時，這意味着如果它偏離了其承諾並表現出惡意行為，_這 1 億美元的一部分將被削減_。簡單來説，「削減」可以理解為銷燬這筆資金。
這個數字越高，就越能為其用户提供更多的安全性和保障。
如果我們允許質押者為各種承諾分配質押，我們就可以在其上創建一個用户友好的平臺。
我們需要一個無需信任且可編程的平臺來執行不同的質押者承諾，以太坊是最適合的。 此外，以太坊持有最大的質押，有助於啟動質押者市場。
這里的目標是，質押者應該能夠通過 EigenLayer 在以太坊上為橋協議提供安全性。如果一個質押者在以太坊上惡意偽造消息並將其傳輸給 Gnosis，任何人都可以提交證據並削減該質押者。
由於質押者的質押和承諾執行發生在以太坊上，削減邏輯也是以以太坊智能合約的形式實現的。如果質押者違反了他們的承諾，任何人都可以向削減合約提供證據並沒收惡意質押者的質押。
這構成了 EigenLayer 的基礎 - 任何質押者都可以為任何基礎設施協議做出可信承諾。
現在，讓我們嘗試實現這一點。我們將從最簡單的設計開始：質押者將代幣質押到一個合約中，該合約包括一個函數，允許在提交證據並符合標準時削減質押者的代幣。用户隨后可以提取他們的余額。
其他質押者也可以將代幣質押到這個合約中，增加基礎設施的安全性。我們將稱這個合約為 TokenPool。
爲了更清晰，這里對本文中使用的術語進行一些定義：
除了stake、withdraw和balance函數和變量外，我們還引入了一個新函數和一個新變量。變量slasher監視每個質押者當前註冊的 AVS。函數enroll允許質押者參與 AVS
因此，註冊到 AVS 實際上是賦予「削減者」削減你的質押的能力。
通過這種修改，在向TokenPool質押后，質押者可以通過調用enroll函數加入特定的 AVS。該函數包含 特定 AVS 的削減者合約到slasher映射中。
在提取過程中，TokenPool合約可以要求每個slasher確定質押者是否有資格提取。這通過slasher合約中的isSlashed函數進行驗證。如果對於這個質押者，isSlashed為TRUE，則質押者無法提取他們的質押，因為他們已經被削減。
我們已將余額變量分為兩個不同的部分：一個用於運營者，一個用於質押者。此外，我們引入了一個delegation映射，用於記錄質押者和運營者之間的委託關係。
我們還對slasher映射進行了微小修改。現在，它授予了slasher合約削減運營者的權限，而不是質押者。
TokenPool合約將僅跟蹤每個質押者的余額。AVS 的跟蹤和加入將由DelegationManager處理。
到目前為止，我們開發的設計僅支持質押一個代幣，因為我們只為質押者維護一個映射。
我們可以通過採用基於LP 份額的模型來解決這個問題，並創建特定於代幣的TokenPool。
為此，我們將創建一個名為TokenManager的新合約。TokenManager將是質押者質押和提款他們的代幣的地方。
在TokenManager下，每個代幣將有一個TokenPool。TokenManager將充當所有代幣的記賬中心；它本身不會存儲任何代幣。每個TokenPool將持有其自己對應的代幣。
當用户質押代幣時，它會由TokenManager處理。TokenManager然后調用與該代幣相關的相應TokenPool的stake函數。用户的代幣將轉移到TokenPool。在函數結束時，totalShares和stakerPoolShares將被更新以反映新的質押。totalShares跟蹤TokenPool發行的份額總數，而stakerPoolShares記錄每個TokenPool中每個個體質押者持有的份額數量。
每個合約的接口將如下所示：
現在，在相同的核心架構下，質押者可以將任何代幣質押到 EigenLayer 以保護其他 AVS。
考慮以下情況：一個質押者在參與可削減行為后立即撤回他們的質押，在其他人削減他們的資產之前就進行撤回。
_例如_，假設有一個既是運營者又是質押者的運營者，在 AVS 中表現惡意。在任何其他人可以在鏈上削減之前，該運營者從 EigenLayer 合約中提取了他們的質押。這是可能的，因為在提款時，slasher尚未更新以削減他們的資產。因此，AVS 不再能夠削減惡意的運營者/質押者，因為沒有更多的代幣可以用於削減。
因此，一個「安全」的 AVS 需要一個能夠在發生事件的同一個區塊中凍結惡意運營者的削減合約。這個限制極大地限制了 AVS 的設計，使大多數 AVS 都不安全。
一個解決方案是引入一個解綁期。我們不再允許質押者立即撤回他們的質押，而是在提款過程中引入一個稱為解綁期的延迟。之后，質押者可以像以前一樣提款。
當一個質押者決定從系統中提款時，他們的請求被放入一個隊列。只有在運營者最長的解綁期到期后，這個排隊的提款纔會被處理。這是因為一個運營者可能管理多個 AVS，但一個質押者的提款只能與一個解綁期對齊。出於安全原因，系統將解綁期設置為最長的那個。
例如，如果一個質押者將他們的質押委託給參與三個 AVS 的運營者，這三個 AVS 的解綁期分別為六、五和七天，那麼在從 EigenLayer 請求提款后，他們必須等待七天才能訪問他們的質押。這是因為七天是這三個期限中最長的。
在七天期限結束后，質押者可以提款他們的質押。但是，如果在此期間他們委託的運營者被削減，那麼待處理的提款也將被停止。
爲了引入這一變化，DelegationManager需要跟蹤每個運營者的解綁期，並在運營者加入新的 AVS 時更新它。
當質押者排隊提取時，TokenManager 將與 DelegationManager 驗證質押者委託的操作員是否被 slash。如果操作員未被 slash，TokenManager 將根據 DelegationManager 的 unbondingPeriod 和當前時間更新質押者的 withdrawalCompleteTime。
解除綁定期后，質押者可以通過 completeWithdrawal 完成其提取。該函數將驗證 withdrawalCompleteTime 是否已過。如果已過，質押者的代幣將按照之前的流程轉出。
由於我們正在使 slash 機制更安全，讓我們也嘗試使其更模塊化和高效。
目前，在提取過程中，TokenManager 需要與每個單獨的 slasher 進行檢查，以查看操作員是否被 slash。這會給質押者增加 gas 開銷，並可能顯著降低較小質押者的獎勵。
此外，由於 AVS 開發人員通常設計 slashers，將這個特定組件模塊化可以簡化各個 AVS 的開發流程。
與 TokenManager 類似，我們將為 slash 機制採用兩部分設計。SlasherManager 維護每個操作員的狀態。單獨的 slasher 將處理每個 AVS 的 slash 邏輯。
slasher 將是特定於 AVS 的，很可能由 AVS 開發人員開發。它將與 SlasherManager 交互，以更新不同操作員的狀態。
回顧一下：EigenLayer 的目標是簡化基礎架構搭建。 我們從四個主要目標開始：
經過幾次迭代，我們開發了三個核心組件：TokenManager、DelegationManager 和 SlasherManager。每個組件都有特定的功能：
這些核心組件還相互通信，以確保整個系統的安全性。
除了這些核心合約之外，還有許多其他功能和合約，增強整個堆棧。這些附加功能支持各種 AVS 設計，簡化離線技術複雜性，並減少用户和操作員的 gas 費用。
要了解更多關於這些其他功能的信息，你可以訪問我們的開源代碼庫：https://github.com/Layr-Labs/eigenlayer-contracts
當系統是模塊化的時候，跟蹤協議中參與者之間的信任假設可能是具有挑戰性的。 因此，明確概述協議中涉及的參與者之間的信任假設是至關重要的。
在 EigenLayer 中，有三個主要代理：質押者、操作員和 AVS 開發人員。
操作員依賴於 AVS 開發人員準確編寫客户端軟件和鏈上 slash 條件。如果 AVS 軟件中存在 bug，最好的情況下，操作員可能會錯過潛在的費用支付。最壞的情況下，操作員可能會因此被 slash 全部質押。
鑑於所涉及價值的重要性，確保整個系統在投入使用之前具有輔助訓練輪是非常重要的。
否決委員會充當這些訓練輪。它有權力撤銷由於非惡意行為導致的 slash。否決委員會是質押者、操作員和 AVS 開發人員之間的相互信任方。
這樣，對 AVS 開發人員的信任假設可以被移除。即使 AVS 中存在軟件 bug，質押者和操作員也不會受到懲罰。
質押者信任他們委託的操作員。如果操作員行為不端，質押者可能會錯過潛在的費用支付，甚至失去全部質押。這一信任假設與現有的驗證服務（如幣安質押和其他質押服務）相同。
AVS 開發人員依賴於操作員誠實操作。如果操作員不誠實，AVS 服務將顯著下降，導致客户流失和其他后果。
在參與者之間，通過否決委員會，信任假設如下：
到目前為止，我們已經討論了使用 LST 進行重新質押。但是，如果你不想通過流動質押協議對 EigenLayer 進行質押，你可以通過原生重新質押開始參與 EigenLayer。
讓我們定義原生重新質押：這是使用驗證器內的 ETH 進行額外承諾的過程。如果驗證器偏離承諾，它們將失去其驗證器內持有的 ETH。
這里的挑戰在於，這些驗證器內的 ETH 不是以 ERC20 代幣的形式表示。相反，ETH 存在於信標鏈上。如果你對執行層或共識層（信標鏈）不熟悉， 這篇解釋[17]是一個讓你快速瞭解的好資源。
爲了解決這個問題，我們可以使用 EigenPod 來跟蹤以太坊驗證器余額，並在必要時 slash 它們。
EigenPod 充當虛擬記賬系統。通過 EigenPod，我們可以監視每個重新質押驗證器的 ETH 余額。
在高層次上，EigenPods 處理驗證器的提取過程。當驗證器從 EigenLayer 提取其質押時，ETH 首先通過 EigenPod，以檢查驗證器是否已被 slash。如果驗證器已被 slash，代幣將在 EigenPod 合約內凍結，有效地 slash 它們。
實現 EigenPod 是棘手的，因為以太坊驗證器余額存儲在信標鏈上，我們無法訪問執行層上的信標鏈數據。
爲了解決這個問題，我們利用一個預言機將信標鏈狀態根傳遞到執行層。通過獲取信標狀態根，我們可以通過提供相應的默克爾證明來訪問驗證者的余額。
有了 EIP-4788[18] 的實施，我們可以移除這個預言機，並直接從執行層查詢信標根。
爲了封裝記賬系統，我們將採用類似TokenPool和TokenManager模型的模式，來模塊化本地的再質押系統。每個EigenPod將處理一個驗證者的提款過程。EigenPodManager將與其他核心合約協調，以跟蹤每個操作員和質押者再質押的以太幣數量。
EigenPodManager跟蹤每個質押者擁有的份額數量。它允許質押者創建EigenPod，對其進行質押，並從中提款。
EigenPod通過restakedBalance變量跟蹤信標鏈上各個驗證者的余額。每當任何再質押驗證者的余額發生變化時，任何人都可以通過調用verifyRestakedBalance()函數來更新該特定驗證者的余額。該函數將通過我們從BEACON_CHAIN_ORACLE獲取的信標狀態根來檢查更新后的余額是否正確。
這就是 EigenLayer 如何實現本地再質押。
參考資料
[1]登鏈翻譯計劃: https://github.com/lbc-team/Pioneer
[2]翻譯小組: https://learnblockchain.cn/people/412
[3]Tiny 熊: https://learnblockchain.cn/people/15
[4]learnblockchain.cn/article…: https://learnblockchain.cn/article/7657
[5]賬户抽象系列: https://learnblockchain.cn/article/5426
[6]Noam Horowitz: https://twitter.com/ProbablyNoam
[7]Shiva: https://twitter.com/ShivanshuMadan
[8]NashQ: https://twitter.com/NashQueue
[9]Mike Neuder: https://twitter.com/mikeneuder
[10]Sina: https://twitter.com/sina_eth_
[11]代碼: https://github.com/Layr-Labs/eigenlayer-contracts/tree/master/src/contracts
[12]合約: https://github.com/Layr-Labs/eigenlayer-contracts/tree/master/src/contracts
[13]工作量證明: https://en.wikipedia.org/wiki/Proof_of_work
[14]權威證明: https://en.wikipedia.org/wiki/Proof_of_authority
[15]權益證明: https://en.wikipedia.org/wiki/Proof_of_stake
[16]白皮書: https://docs.eigenlayer.xyz/overview/whitepaper
[17]這篇解釋: https://docs.prylabs.network/docs/concepts/nodes-networks
[18]EIP-4788: https://eips.ethereum.org/EIPS/eip-4788
[19]DeCert.me: https://decert.me/
