從重新設計角度理解EigenLayer
發表於 2024-03-19 19:05 作者： 登鏈社區
來源：登鏈社區
在這篇博客文章中，我們將帶你了解 EigenLayer 協議的演變，介紹 EigenLayer 架構是如何從最初的概念中產生的。
本博客受 David Philipson 的 账戶抽象系列[5] 啓發。特別感謝社區的 Noam Horowitz[6]、Shiva[7]、NashQ[8]、Mike Neuder[9] 和 Sina[10] 對本文的評論和反饋。
雖然很多人熟悉 restaking 和 EigenLayer 這些術語，但只有少數人知道我們的核心合約包含數千行代碼[11] ，其架構如下。
EigenLayer 簡化架構
一個看似簡單的想法爲何變得如此復雜？
在這篇博客文章中，我們將通過介紹 EigenLayer 當前復雜架構是如何從最初概念中產生的，來帶你了解該協議的演變。
本文的目標讀者是對智能合約有基本了解並聽說過 EigenLayer 或 restaking 的人。
由於本博客文章的目的是對 EigenLayer 的設計演變進行高層次解釋，因此接口、變量和邏輯可能與當前 EigenLayer 核心合約[12]有所不同。
現在，讓我們开始吧。
最終目標：使構建基礎設施變得簡單
首先，讓我們先介紹 EigenLayer 要解決的問題。如果你已經熟悉這部分內容，請跳到後面的章節。
在以太坊上構建去中心化基礎設施的开發人員面臨着建立自己的經濟安全的挑战。雖然以太坊爲智能合約協議提供了經濟安全，但橋或排序器等基礎設施需要自己的經濟安全，以實現節點的分布式網絡達成共識。
共識機制對於促進這些節點之間的互動至關重要，無論是 L1、預言機網絡還是橋。
工作量證明[13]耗能嚴重， 權威證明[14]過於集中化，因此權益證明[15] （PoS）已成爲大多數基礎設施項目的主要共識機制。
然而，啓動新的 PoS 網絡很困難。
首先，很難確定質押者（提供質押的人）在哪裏。沒有一個好的地方供开發人員找到質押者。
其次，質押者必須投入大量資金來獲得新網絡的質押，通常是通過購买網絡的原生代幣，他們通常是波動的且難以獲得。
第三，質押者必須放棄其他的獎勵機會，比如以太坊提供的 5% 獎勵。
最後，當前的安全模型不理想，因爲破壞任何 dApp 的成本只是破壞其最脆弱的基礎設施依賴所需的成本。
暫時假設參與基礎設施項目的質押者也負責操作離线軟件以保證其安全。但我們將在文章後面更改這一假設。
EigenLayer 被創建來解決這些問題：
它作爲一個平台連接質押者和基礎設施开發人員。
質押者可以使用任何代幣提供經濟安全。
質押者可以選擇 restaking(重新質押) 他們原有質押並爲其他基礎設施的安全做出貢獻，同時獲得原生以太獎勵。
通過重新質押，EigenLayer 將安全性匯集在一起，而不是使其分散（碎片化）。
EigenLayer 的白皮書[16]對這些問題進行了深入探討。
EigenLayer 泛化了提供經濟安全的概念。
目標 1：創建連接質押者和基礎設施开發人員的平台
EigenLayer 是一個平台，質押者可以爲任何基礎設施項目提供質押，基礎設施項目可以在 EigenLayer 上向潛在質押者推介。該平台的支柱是使質押者能夠爲不同的基礎設施做出可信承諾。
這些承諾適用於所有權益證明系統，不僅僅是 EigenLayer。L1 質押者通常承諾遵循協議規則，並冒着如果在同一區塊高度籤署衝突區塊而失去質押的風險。
基礎設施开發人員構建基礎設施邏輯和軟件，而質押者提供質押以保障基礎設施。_這個 質押 作爲 承諾 提供給基礎設施的用戶。_ 這個 承諾 是爲了協議的順利運行，反對特定的不端行爲。
從概念上，當一個項目背後有 1 億美元的質押時，這意味着如果它偏離了其承諾並表現出惡意行爲，_這 1 億美元的一部分將被削減_。簡單來說，“削減”可以理解爲銷毀這筆資金。
這個數字越高，就越能爲其用戶提供更多的安全性和保障。
如果我們允許質押者爲各種承諾分配質押，我們就可以在其上創建一個用戶友好的平台。
我們需要一個無需信任且可編程的平台來執行不同的質押者承諾，以太坊是最適合的。 此外，以太坊持有最大的質押，有助於啓動質押者市場。
這裏的目標是，質押者應該能夠通過 EigenLayer 在以太坊上爲橋協議提供安全性。如果一個質押者在以太坊上惡意僞造消息並將其傳輸給 Gnosis，任何人都可以提交證據並削減該質押者。
由於質押者的質押和承諾執行發生在以太坊上，削減邏輯也是以以太坊智能合約的形式實現的。如果質押者違反了他們的承諾，任何人都可以向削減合約提供證據並沒收惡意質押者的質押。
這構成了 EigenLayer 的基礎 - 任何質押者都可以爲任何基礎設施協議做出可信承諾。
EigenLayer 的初始設計
現在，讓我們嘗試實現這一點。我們將從最簡單的設計开始：質押者將代幣質押到一個合約中，該合約包括一個函數，允許在提交證據並符合標准時削減質押者的代幣。用戶隨後可以提取他們的余額。
其他質押者也可以將代幣質押到這個合約中，增加基礎設施的安全性。我們將稱這個合約爲 TokenPool。
爲了更清晰，這裏對本文中使用的術語進行一些定義：
質押者：任何提供代幣到 EigenLayer 的人。
代幣：任何類型的代幣；暫時簡單地將其視爲 ERC20 代幣。
TokenPool：保存質押者代幣的智能合約。
削減：移除質押者對其質押代幣的訪問權限。
這個TokenPool的接口可以表示如下：
contract TokenPool {
mapping(address => uint256) public balance;
mapping(address => address[]) public slasher;
function stake(uint256 amount) public;
function withdraw() public;
function enroll(address slasher) onlyOwner;
}
除了stake、withdraw和balance函數和變量外，我們還引入了一個新函數和一個新變量。變量slasher監視每個質押者當前注冊的 AVS。函數enroll允許質押者參與 AVS
因此，注冊到 AVS 實際上是賦予“削減者”削減你的質押的能力。
通過這種修改，在向TokenPool質押後，質押者可以通過調用enroll函數加入特定的 AVS。該函數包含 特定 AVS 的削減者合約到slasher映射中。
這裏的 enroll 函數是受訪問控制的，因爲它可能使任何人都能夠注冊到任何削減者合約。爲了確保這個 TokenPool 被安全管理，我們將假設它由一個受信任的第三方監督。
在提取過程中，TokenPool合約可以要求每個slasher確定質押者是否有資格提取。這通過slasher合約中的isSlashed函數進行驗證。如果對於這個質押者，isSlashed爲TRUE，則質押者無法提取他們的質押，因爲他們已經被削減。
contract TokenPool {
mapping(address => uint256) public stakerBalance;
mapping(address => uint256) public operatorBalance;
mapping(address => address) public delegation;
mapping(address => address[]) public slasher;
function stake(uint256 amount) public;
function withdraw() public;
function delegateTo(address operator) public;
function enroll(address slasher) operatorOnly;
function exit(address slasher) operatorOnly;
}
我們已將余額變量分爲兩個不同的部分：一個用於運營者，一個用於質押者。此外，我們引入了一個delegation映射，用於記錄質押者和運營者之間的委托關系。
我們還對slasher映射進行了微小修改。現在，它授予了slasher合約削減運營者的權限，而不是質押者。
contract TokenPool {
mapping(address => uint256) public stakerBalance;
function stake(uint256 amount) public;
function withdraw() public;
}
TokenPool合約將僅跟蹤每個質押者的余額。AVS 的跟蹤和加入將由DelegationManager處理。
contract slasher {
mapping (address => bool) isSlashed;
function slash(address operator, ??? proof);
}
在清理合約結構並將每個組件模塊化之後，架構現在如下所示：
EigenLayer 中間設計： 將運營者角色與質押者角色分離後。
目標：支持更多代幣
到目前爲止，我們开發的設計僅支持質押一個代幣，因爲我們只爲質押者維護一個映射。
我們可以通過採用基於LP 份額的模型來解決這個問題，並創建特定於代幣的TokenPool。
爲此，我們將創建一個名爲TokenManager的新合約。TokenManager將是質押者質押和提款他們的代幣的地方。
在TokenManager下，每個代幣將有一個TokenPool。TokenManager將充當所有代幣的記账中心；它本身不會存儲任何代幣。每個TokenPool將持有其自己對應的代幣。
設計的新組件，現在可以跟蹤質押者的不同代幣。
當用戶質押代幣時，它會由TokenManager處理。TokenManager然後調用與該代幣相關的相應TokenPool的stake函數。用戶的代幣將轉移到TokenPool。在函數結束時，totalShares和stakerPoolShares將被更新以反映新的質押。totalShares跟蹤TokenPool發行的份額總數，而stakerPoolShares記錄每個TokenPool中每個個體質押者持有的份額數量。
每個合約的接口將如下所示：
contract DelegationManager {
// ...
mapping(address => mapping(address => uint256)) operatorPoolShares;
// ...
}
現在，在相同的核心架構下，質押者可以將任何代幣質押到 EigenLayer 以保護其他 AVS。
目標：擴展 AVS 設計
考慮以下情況：一個質押者在參與可削減行爲後立即撤回他們的質押，在其他人削減他們的資產之前就進行撤回。
_例如_，假設有一個既是運營者又是質押者的運營者，在 AVS 中表現惡意。在任何其他人可以在鏈上削減之前，該運營者從 EigenLayer 合約中提取了他們的質押。這是可能的，因爲在提款時，slasher尚未更新以削減他們的資產。因此，AVS 不再能夠削減惡意的運營者/質押者，因爲沒有更多的代幣可以用於削減。
惡意運營者/質押者的潛在事件時間表。
因此，一個“安全”的 AVS 需要一個能夠在發生事件的同一個區塊中凍結惡意運營者的削減合約。這個限制極大地限制了 AVS 的設計，使大多數 AVS 都不安全。
一個解決方案是引入一個解綁期。我們不再允許質押者立即撤回他們的質押，而是在提款過程中引入一個稱爲解綁期的延遲。之後，質押者可以像以前一樣提款。
當一個質押者決定從系統中提款時，他們的請求被放入一個隊列。只有在運營者最長的解綁期到期後，這個排隊的提款才會被處理。這是因爲一個運營者可能管理多個 AVS，但一個質押者的提款只能與一個解綁期對齊。出於安全原因，系統將解綁期設置爲最長的那個。
例如，如果一個質押者將他們的質押委托給參與三個 AVS 的運營者，這三個 AVS 的解綁期分別爲六、五和七天，那么在從 EigenLayer 請求提款後，他們必須等待七天才能訪問他們的質押。這是因爲七天是這三個期限中最長的。
在七天期限結束後，質押者可以提款他們的質押。但是，如果在此期間他們委托的運營者被削減，那么待處理的提款也將被停止。
爲了引入這一變化，DelegationManager需要跟蹤每個運營者的解綁期，並在運營者加入新的 AVS 時更新它。
contract TokenManager {
mapping(address => address) public tokenPoolRegistry;
mapping(address => mapping(address => uint256)) public stakerPoolShares;
mapping(address => uint256) public withdrawalCompleteTime;
function stakeToPool(address pool, uint256 amount) public;
function queueWithdrawal(address pool) public;
function completeWithdrawal(address pool) public;
}
當質押者排隊提取時，TokenManager 將與 DelegationManager 驗證質押者委托的操作員是否被 slash。如果操作員未被 slash，TokenManager 將根據 DelegationManager 的 unbondingPeriod 和當前時間更新質押者的 withdrawalCompleteTime。
解除綁定期後，質押者可以通過 completeWithdrawal 完成其提取。該函數將驗證 withdrawalCompleteTime 是否已過。如果已過，質押者的代幣將按照之前的流程轉出。
這個流程的設計復雜，並在我們的流程中經歷了幾次迭代。我們甚至可以就這個主題撰寫一篇單獨的文章！目前，我們使用一個時間跟蹤系統來實現這種解綁跟蹤。這部分仍在進行中！
模塊化 slashers
由於我們正在使 slash 機制更安全，讓我們也嘗試使其更模塊化和高效。
目前，在提取過程中，TokenManager 需要與每個單獨的 slasher 進行檢查，以查看操作員是否被 slash。這會給質押者增加 gas 开銷，並可能顯著降低較小質押者的獎勵。
此外，由於 AVS 开發人員通常設計 slashers，將這個特定組件模塊化可以簡化各個 AVS 的开發流程。
與 TokenManager 類似，我們將爲 slash 機制採用兩部分設計。SlasherManager 維護每個操作員的狀態。單獨的 slasher 將處理每個 AVS 的 slash 邏輯。
更進一步模塊化 slash 合約以減少質押者的 gas 成本。
contract slasher {
function slash(address operator, ??? proof) public;
}
slasher 將是特定於 AVS 的，很可能由 AVS 开發人員开發。它將與 SlasherManager 交互，以更新不同操作員的狀態。
EigenLayer 已設計好！
回顧一下：EigenLayer 的目標是簡化基礎架構搭建。 我們從四個主要目標开始：
構建一個平台連接質押者和基礎架構开發人員。
允許質押者使用任何代幣提供經濟安全性。
使質押者能夠重新質押他們的質押，並在爲其他基礎架構提供安全性的同時賺取原生 ETH 獎勵。
通過重新質押來池化安全性，而不是使其分散化。
經過幾次迭代，我們开發了三個核心組件：TokenManager、DelegationManager 和 SlasherManager。每個組件都有特定的功能：
EigenLayer 的簡化架構
TokenManager：處理質押者的質押和提取。DelegationManager：允許操作員注冊和跟蹤操作員份額。SlasherManager：爲 AVS 开發人員提供確定 slash 邏輯的接口。
這些核心組件還相互通信，以確保整個系統的安全性。
除了這些核心合約之外，還有許多其他功能和合約，增強整個堆棧。這些附加功能支持各種 AVS 設計，簡化離线技術復雜性，並減少用戶和操作員的 gas 費用。
要了解更多關於這些其他功能的信息，你可以訪問我們的开源代碼庫：https://github.com/Layr-Labs/eigenlayer-contracts
附加 1：誰信任誰？
當系統是模塊化的時候，跟蹤協議中參與者之間的信任假設可能是具有挑战性的。 因此，明確概述協議中涉及的參與者之間的信任假設是至關重要的。
在 EigenLayer 中，有三個主要代理：質押者、操作員和 AVS 开發人員。
操作員依賴於 AVS 开發人員准確編寫客戶端軟件和鏈上 slash 條件。如果 AVS 軟件中存在 bug，最好的情況下，操作員可能會錯過潛在的費用支付。最壞的情況下，操作員可能會因此被 slash 全部質押。
鑑於所涉及價值的重要性，確保整個系統在投入使用之前具有輔助訓練輪是非常重要的。
否決委員會充當這些訓練輪。它有權力撤銷由於非惡意行爲導致的 slash。否決委員會是質押者、操作員和 AVS 开發人員之間的相互信任方。
這樣，對 AVS 开發人員的信任假設可以被移除。即使 AVS 中存在軟件 bug，質押者和操作員也不會受到懲罰。
質押者信任他們委托的操作員。如果操作員行爲不端，質押者可能會錯過潛在的費用支付，甚至失去全部質押。這一信任假設與現有的驗證服務（如幣安質押和其他質押服務）相同。
AVS 开發人員依賴於操作員誠實操作。如果操作員不誠實，AVS 服務將顯著下降，導致客戶流失和其他後果。
在參與者之間，通過否決委員會，信任假設如下：
質押者信任操作員誠實行事，不端行爲可能導致 slash。
AVS 开發人員信任操作員誠實操作 AVS 軟件。
質押者、操作員和 AVS 开發人員信任否決委員會來撤銷 slash。
附加 2：原生 Restaking
到目前爲止，我們已經討論了使用 LST 進行重新質押。但是，如果你不想通過流動質押協議對 EigenLayer 進行質押，你可以通過原生重新質押开始參與 EigenLayer。
讓我們定義原生重新質押：這是使用驗證器內的 ETH 進行額外承諾的過程。如果驗證器偏離承諾，它們將失去其驗證器內持有的 ETH。
這裏的挑战在於，這些驗證器內的 ETH 不是以 ERC20 代幣的形式表示。相反，ETH 存在於信標鏈上。如果你對執行層或共識層（信標鏈）不熟悉， 這篇解釋[17]是一個讓你快速了解的好資源。
爲了解決這個問題，我們可以使用 EigenPod 來跟蹤以太坊驗證器余額，並在必要時 slash 它們。
EigenPod 充當虛擬記账系統。通過 EigenPod，我們可以監視每個重新質押驗證器的 ETH 余額。
在高層次上，EigenPods 處理驗證器的提取過程。當驗證器從 EigenLayer 提取其質押時，ETH 首先通過 EigenPod，以檢查驗證器是否已被 slash。如果驗證器已被 slash，代幣將在 EigenPod 合約內凍結，有效地 slash 它們。
實現 EigenPod
實現 EigenPod 是棘手的，因爲以太坊驗證器余額存儲在信標鏈上，我們無法訪問執行層上的信標鏈數據。
爲了解決這個問題，我們利用一個預言機將信標鏈狀態根傳遞到執行層。通過獲取信標狀態根，我們可以通過提供相應的默克爾證明來訪問驗證者的余額。
有了 EIP-4788[18] 的實施，我們可以移除這個預言機，並直接從執行層查詢信標根。
爲了封裝記账系統，我們將採用類似TokenPool和TokenManager模型的模式，來模塊化本地的再質押系統。每個EigenPod將處理一個驗證者的提款過程。EigenPodManager將與其他核心合約協調，以跟蹤每個操作員和質押者再質押的以太幣數量。
<span ) 10px 10px / 40px no-repeat ;height: 30px;width: 100%;margin-bottom: -7px;border-radius: 5px;'>contract EigenPodManager{
mapping(address => uint256) public restakerShares;
function createEigenPod(address owner) public;
function stakeToPod(address pod, uint256 amount) public;
function withdrawFromPod(address pod) public;
}
contract EigenPod{
address BEACON_CHAIN_ORACLE;
address podOwner;
uint256 restakedAmount;
function stake(uint256 amount) public;
function verifyRestakedBalance(uint256 amount, MerkleProof proof) public;
function withdraw() public;
}
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/
標題：從重新設計角度理解EigenLayer
地址：https://www.coinsdeep.com/article/105959.html
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。