dark

從重新設計角度理解EigenLayer

2024-03-20

來源：登鏈社區

在這篇部落格文章中，我們將帶你了解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 的目標是簡化基礎架構建置。我們從四個主要目標開始：

  1. 建立一個平台連接質押者和基礎架構開發人員。

  2. 允許質押者使用任何代幣提供經濟安全性。

  3. 使質押者能夠重新質押他們的質押，並在為其他基礎架構提供安全性的同時賺取原生ETH 獎勵。

  4. 透過重新質押來池化安全性，而不是使其分散化。

經過幾次迭代，我們開發了三個核心元件：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將與其他核心合約協調，以追蹤每個操作員和質押者再質押的以太幣數量。

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/

Total
0
Shares
Share 0
Tweet 0
Share 0
Related Posts