從重新設計角度理解EigenLayer

訪客 1年前 (2024-03-19) 閱讀數 206 #區塊鏈

文章標簽前沿文章

來源：登鏈社區

在這篇博客文章中，我們將帶你了解 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_