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