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