從重新設(shè)計(jì)角度理解EigenLayer

訪客 1年前 (2024-03-19) 閱讀數(shù) 256 #區(qū)塊鏈

文章標(biāo)簽前沿文章

來(lái)源：登鏈社區(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] 對(duì)本文的評(píng)論和反饋。

雖然很多人熟悉 restaking 和 EigenLayer 這些術(shù)語(yǔ)，但只有少數(shù)人知道我們的核心合約包含數(shù)千行代碼[11] ，其架構(gòu)如下。

EigenLayer 簡(jiǎn)化架構(gòu)

一個(gè)看似簡(jiǎn)單的想法為何變得如此復(fù)雜？

在這篇博客文章中，我們將通過(guò)介紹 EigenLayer 當(dāng)前復(fù)雜架構(gòu)是如何從最初概念中產(chǎn)生的，來(lái)帶你了解該協(xié)議的演變。

本文的目標(biāo)讀者是對(duì)智能合約有基本了解并聽(tīng)說(shuō)過(guò) EigenLayer 或 restaking 的人。

由于本博客文章的目的是對(duì) EigenLayer 的設(shè)計(jì)演變進(jìn)行高層次解釋，因此接口、變量和邏輯可能與當(dāng)前 EigenLayer 核心合約[12]有所不同。

現(xiàn)在，讓我們開(kāi)始吧。

最終目標(biāo)：使構(gòu)建基礎(chǔ)設(shè)施變得簡(jiǎn)單

首先，讓我們先介紹 EigenLayer 要解決的問(wèn)題。如果你已經(jīng)熟悉這部分內(nèi)容，請(qǐng)?zhí)胶竺娴恼鹿?jié)。

在以太坊上構(gòu)建去中心化基礎(chǔ)設(shè)施的開(kāi)發(fā)人員面臨著建立自己的經(jīng)濟(jì)安全的挑戰(zhàn)。雖然以太坊為智能合約協(xié)議提供了經(jīng)濟(jì)安全，但橋或排序器等基礎(chǔ)設(shè)施需要自己的經(jīng)濟(jì)安全，以實(shí)現(xiàn)節(jié)點(diǎn)的分布式網(wǎng)絡(luò)達(dá)成共識(shí)。

共識(shí)機(jī)制對(duì)于促進(jìn)這些節(jié)點(diǎn)之間的互動(dòng)至關(guān)重要，無(wú)論是 L1、預(yù)言機(jī)網(wǎng)絡(luò)還是橋。

工作量證明[13]耗能嚴(yán)重，權(quán)威證明[14]過(guò)于集中化，因此權(quán)益證明[15] （PoS）已成為大多數(shù)基礎(chǔ)設(shè)施項(xiàng)目的主要共識(shí)機(jī)制。

然而，啟動(dòng)新的 PoS 網(wǎng)絡(luò)很困難。

首先，很難確定質(zhì)押者（提供質(zhì)押的人）在哪里。沒(méi)有一個(gè)好的地方供開(kāi)發(fā)人員找到質(zhì)押者。

其次，質(zhì)押者必須投入大量資金來(lái)獲得新網(wǎng)絡(luò)的質(zhì)押，通常是通過(guò)購(gòu)買網(wǎng)絡(luò)的原生代幣，他們通常是波動(dòng)的且難以獲得。

第三，質(zhì)押者必須放棄其他的獎(jiǎng)勵(lì)機(jī)會(huì)，比如以太坊提供的 5% 獎(jiǎng)勵(lì)。

最后，當(dāng)前的安全模型不理想，因?yàn)槠茐娜魏?dApp 的成本只是破壞其最脆弱的基礎(chǔ)設(shè)施依賴所需的成本。

暫時(shí)假設(shè)參與基礎(chǔ)設(shè)施項(xiàng)目的質(zhì)押者也負(fù)責(zé)操作離線軟件以保證其安全。但我們將在文章后面更改這一假設(shè)。

EigenLayer 被創(chuàng)建來(lái)解決這些問(wèn)題：

它作為一個(gè)平臺(tái)連接質(zhì)押者和基礎(chǔ)設(shè)施開(kāi)發(fā)人員。

質(zhì)押者可以使用任何代幣提供經(jīng)濟(jì)安全。

質(zhì)押者可以選擇 restaking(重新質(zhì)押) 他們?cè)匈|(zhì)押并為其他基礎(chǔ)設(shè)施的安全做出貢獻(xiàn)，同時(shí)獲得原生以太獎(jiǎng)勵(lì)。

通過(guò)重新質(zhì)押，EigenLayer 將安全性匯集在一起，而不是使其分散（碎片化）。

EigenLayer 的白皮書(shū)[16]對(duì)這些問(wèn)題進(jìn)行了深入探討。

EigenLayer 泛化了提供經(jīng)濟(jì)安全的概念。

目標(biāo) 1：創(chuàng)建連接質(zhì)押者和基礎(chǔ)設(shè)施開(kāi)發(fā)人員的平臺(tái)

EigenLayer 是一個(gè)平臺(tái)，質(zhì)押者可以為任何基礎(chǔ)設(shè)施項(xiàng)目提供質(zhì)押，基礎(chǔ)設(shè)施項(xiàng)目可以在 EigenLayer 上向潛在質(zhì)押者推介。該平臺(tái)的支柱是使質(zhì)押者能夠?yàn)椴煌幕A(chǔ)設(shè)施做出可信承諾。

這些承諾適用于所有權(quán)益證明系統(tǒng)，不僅僅是 EigenLayer。L1 質(zhì)押者通常承諾遵循協(xié)議規(guī)則，并冒著如果在同一區(qū)塊高度簽署沖突區(qū)塊而失去質(zhì)押的風(fēng)險(xiǎn)。

基礎(chǔ)設(shè)施開(kāi)發(fā)人員構(gòu)建基礎(chǔ)設(shè)施邏輯和軟件，而質(zhì)押者提供質(zhì)押以保障基礎(chǔ)設(shè)施。_這個(gè) 質(zhì)押作為承諾提供給基礎(chǔ)設(shè)施的用戶。_ 這個(gè) 承諾是為了協(xié)議的順利運(yùn)行，反對(duì)特定的不端行為。

從概念上，當(dāng)一個(gè)項(xiàng)目背后有 1 億美元的質(zhì)押時(shí)，這意味著如果它偏離了其承諾并表現(xiàn)出惡意行為，_這 1 億美元的一部分將被削減_。簡(jiǎn)單來(lái)說(shuō)，“削減”可以理解為銷毀這筆資金。

這個(gè)數(shù)字越高，就越能為其用戶提供更多的安全性和保障。

如果我們?cè)试S質(zhì)押者為各種承諾分配質(zhì)押，我們就可以在其上創(chuàng)建一個(gè)用戶友好的平臺(tái)。

我們需要一個(gè)無(wú)需信任且可編程的平臺(tái)來(lái)執(zhí)行不同的質(zhì)押者承諾，以太坊是最適合的。此外，以太坊持有最大的質(zhì)押，有助于啟動(dòng)質(zhì)押者市場(chǎng)。

這里的目標(biāo)是，質(zhì)押者應(yīng)該能夠通過(guò) EigenLayer 在以太坊上為橋協(xié)議提供安全性。如果一個(gè)質(zhì)押者在以太坊上惡意偽造消息并將其傳輸給 Gnosis，任何人都可以提交證據(jù)并削減該質(zhì)押者。

由于質(zhì)押者的質(zhì)押和承諾執(zhí)行發(fā)生在以太坊上，削減邏輯也是以以太坊智能合約的形式實(shí)現(xiàn)的。如果質(zhì)押者違反了他們的承諾，任何人都可以向削減合約提供證據(jù)并沒(méi)收惡意質(zhì)押者的質(zhì)押。

這構(gòu)成了 EigenLayer 的基礎(chǔ) - 任何質(zhì)押者都可以為任何基礎(chǔ)設(shè)施協(xié)議做出可信承諾。

EigenLayer 的初始設(shè)計(jì)

現(xiàn)在，讓我們嘗試實(shí)現(xiàn)這一點(diǎn)。我們將從最簡(jiǎn)單的設(shè)計(jì)開(kāi)始：質(zhì)押者將代幣質(zhì)押到一個(gè)合約中，該合約包括一個(gè)函數(shù)，允許在提交證據(jù)并符合標(biāo)準(zhǔn)時(shí)削減質(zhì)押者的代幣。用戶隨后可以提取他們的余額。

其他質(zhì)押者也可以將代幣質(zhì)押到這個(gè)合約中，增加基礎(chǔ)設(shè)施的安全性。我們將稱這個(gè)合約為 TokenPool。

為了更清晰，這里對(duì)本文中使用的術(shù)語(yǔ)進(jìn)行一些定義：

質(zhì)押者：任何提供代幣到 EigenLayer 的人。

代幣：任何類型的代幣；暫時(shí)簡(jiǎn)單地將其視為 ERC20 代幣。

TokenPool：保存質(zhì)押者代幣的智能合約。

削減：移除質(zhì)押者對(duì)其質(zhì)押代幣的訪問(wèn)權(quán)限。

這個(gè)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函數(shù)和變量外，我們還引入了一個(gè)新函數(shù)和一個(gè)新變量。變量slasher監(jiān)視每個(gè)質(zhì)押者當(dāng)前注冊(cè)的 AVS。函數(shù)enroll允許質(zhì)押者參與 AVS

因此，注冊(cè)到 AVS 實(shí)際上是賦予“削減者”削減你的質(zhì)押的能力。

通過(guò)這種修改，在向TokenPool質(zhì)押后，質(zhì)押者可以通過(guò)調(diào)用enroll函數(shù)加入特定的 AVS。該函數(shù)包含特定 AVS 的削減者合約到slasher映射中。

這里的 enroll 函數(shù)是受訪問(wèn)控制的，因?yàn)樗赡苁谷魏稳硕寄軌蜃?cè)到任何削減者合約。為了確保這個(gè) TokenPool 被安全管理，我們將假設(shè)它由一個(gè)受信任的第三方監(jiān)督。

在提取過(guò)程中，TokenPool合約可以要求每個(gè)slasher確定質(zhì)押者是否有資格提取。這通過(guò)slasher合約中的isSlashed函數(shù)進(jìn)行驗(yàn)證。如果對(duì)于這個(gè)質(zhì)押者，isSlashed為TRUE，則質(zhì)押者無(wú)法提取他們的質(zhì)押，因?yàn)樗麄円呀?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;}

我們已將余額變量分為兩個(gè)不同的部分：一個(gè)用于運(yùn)營(yíng)者，一個(gè)用于質(zhì)押者。此外，我們引入了一個(gè)delegation映射，用于記錄質(zhì)押者和運(yùn)營(yíng)者之間的委托關(guān)系。

我們還對(duì)slasher映射進(jìn)行了微小修改。現(xiàn)在，它授予了slasher合約削減運(yùn)營(yíng)者的權(quán)限，而不是質(zhì)押者。

contract TokenPool { ? ?mapping(address => uint256) public stakerBalance; ? ?function stake(uint256 amount) public; ? ?function withdraw() public;}

TokenPool合約將僅跟蹤每個(gè)質(zhì)押者的余額。AVS 的跟蹤和加入將由DelegationManager處理。

contract slasher { ? ?mapping (address => bool) isSlashed; ? ?function slash(address operator, ??? proof);}

在清理合約結(jié)構(gòu)并將每個(gè)組件模塊化之后，架構(gòu)現(xiàn)在如下所示：

EigenLayer 中間設(shè)計(jì)：將運(yùn)營(yíng)者角色與質(zhì)押者角色分離后。

目標(biāo)：支持更多代幣

到目前為止，我們開(kāi)發(fā)的設(shè)計(jì)僅支持質(zhì)押一個(gè)代幣，因?yàn)槲覀冎粸橘|(zhì)押者維護(hù)一個(gè)映射。

我們可以通過(guò)采用基于LP 份額的模型來(lái)解決這個(gè)問(wèn)題，并創(chuàng)建特定于代幣的TokenPool。

為此，我們將創(chuàng)建一個(gè)名為TokenManager的新合約。TokenManager將是質(zhì)押者質(zhì)押和提款他們的代幣的地方。

在TokenManager下，每個(gè)代幣將有一個(gè)TokenPool。TokenManager將充當(dāng)所有代幣的記賬中心；它本身不會(huì)存儲(chǔ)任何代幣。每個(gè)TokenPool將持有其自己對(duì)應(yīng)的代幣。

設(shè)計(jì)的新組件，現(xiàn)在可以跟蹤質(zhì)押者的不同代幣。

當(dāng)用戶質(zhì)押代幣時(shí)，它會(huì)由TokenManager處理。TokenManager然后調(diào)用與該代幣相關(guān)的相應(yīng)TokenPool的stake函數(shù)。用戶的代幣將轉(zhuǎn)移到TokenPool。在函數(shù)結(jié)束時(shí)，totalShares和stakerPoolShares將被更新以反映新的質(zhì)押。totalShares跟蹤TokenPool發(fā)行的份額總數(shù)，而stakerPoolShares記錄每個(gè)TokenPool中每個(gè)個(gè)體質(zhì)押者持有的份額數(shù)量。

每個(gè)合約的接口將如下所示：

contract DelegationManager { ? ?// ... ? ?mapping(address => mapping(address => uint256)) operatorPoolShares; ? ?// ...}

現(xiàn)在，在相同的核心架構(gòu)下，質(zhì)押者可以將任何代幣質(zhì)押到 EigenLayer 以保護(hù)其他 AVS。

目標(biāo)：擴(kuò)展 AVS 設(shè)計(jì)

考慮以下情況：一個(gè)質(zhì)押者在參與可削減行為后立即撤回他們的質(zhì)押，在其他人削減他們的資產(chǎn)之前就進(jìn)行撤回。

_例如_，假設(shè)有一個(gè)既是運(yùn)營(yíng)者又是質(zhì)押者的運(yùn)營(yíng)者，在 AVS 中表現(xiàn)惡意。在任何其他人可以在鏈上削減之前，該運(yùn)營(yíng)者從 EigenLayer 合約中提取了他們的質(zhì)押。這是可能的，因?yàn)樵谔峥顣r(shí)，slasher尚未更新以削減他們的資產(chǎn)。因此，AVS 不再能夠削減惡意的運(yùn)營(yíng)者/質(zhì)押者，因?yàn)闆](méi)有更多的代幣可以用于削減。

惡意運(yùn)營(yíng)者/質(zhì)押者的潛在事件時(shí)間表。

因此，一個(gè)“安全”的 AVS 需要一個(gè)能夠在發(fā)生事件的同一個(gè)區(qū)塊中凍結(jié)惡意運(yùn)營(yíng)者的削減合約。這個(gè)限制極大地限制了 AVS 的設(shè)計(jì)，使大多數(shù) AVS 都不安全。

一個(gè)解決方案是引入一個(gè)解綁期。我們不再允許質(zhì)押者立即撤回他們的質(zhì)押，而是在提款過(guò)程中引入一個(gè)稱為解綁期的延遲。之后，質(zhì)押者可以像以前一樣提款。

當(dāng)一個(gè)質(zhì)押者決定從系統(tǒng)中提款時(shí)，他們的請(qǐng)求被放入一個(gè)隊(duì)列。只有在運(yùn)營(yíng)者最長(zhǎng)的解綁期到期后，這個(gè)排隊(duì)的提款才會(huì)被處理。這是因?yàn)橐粋€(gè)運(yùn)營(yíng)者可能管理多個(gè) AVS，但一個(gè)質(zhì)押者的提款只能與一個(gè)解綁期對(duì)齊。出于安全原因，系統(tǒng)將解綁期設(shè)置為最長(zhǎng)的那個(gè)。

例如，如果一個(gè)質(zhì)押者將他們的質(zhì)押委托給參與三個(gè) AVS 的運(yùn)營(yíng)者，這三個(gè) AVS 的解綁期分別為六、五和七天，那么在從 EigenLayer 請(qǐng)求提款后，他們必須等待七天才能訪問(wèn)他們的質(zhì)押。這是因?yàn)槠咛焓沁@三個(gè)期限中最長(zhǎng)的。

在七天期限結(jié)束后，質(zhì)押者可以提款他們的質(zhì)押。但是，如果在此期間他們委托的運(yùn)營(yíng)者被削減，那么待處理的提款也將被停止。

為了引入這一變化，DelegationManager需要跟蹤每個(gè)運(yùn)營(yíng)者的解綁期，并在運(yùn)營(yíng)者加入新的 AVS 時(shí)更新它。

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ì)押者排隊(duì)提取時(shí)，TokenManager 將與 DelegationManager 驗(yàn)證質(zhì)押者委托的操作員是否被 slash。如果操作員未被 slash，TokenManager 將根據(jù) DelegationManager 的 unbondingPeriod 和當(dāng)前時(shí)間更新質(zhì)押者的 withdrawalCompleteTime。

解除綁定期后，質(zhì)押者可以通過(guò) completeWithdrawal 完成其提取。該函數(shù)將驗(yàn)證 withdrawalCompleteTime 是否已過(guò)。如果已過(guò)，質(zhì)押者的代幣將按照之前的流程轉(zhuǎn)出。

這個(gè)流程的設(shè)計(jì)復(fù)雜，并在我們的流程中經(jīng)歷了幾次迭代。我們甚至可以就這個(gè)主題撰寫一篇單獨(dú)的文章！目前，我們使用一個(gè)時(shí)間跟蹤系統(tǒng)來(lái)實(shí)現(xiàn)這種解綁跟蹤。這部分仍在進(jìn)行中！

模塊化 slashers

由于我們正在使 slash 機(jī)制更安全，讓我們也嘗試使其更模塊化和高效。

目前，在提取過(guò)程中，TokenManager 需要與每個(gè)單獨(dú)的 slasher 進(jìn)行檢查，以查看操作員是否被 slash。這會(huì)給質(zhì)押者增加 gas 開(kāi)銷，并可能顯著降低較小質(zhì)押者的獎(jiǎng)勵(lì)。

此外，由于 AVS 開(kāi)發(fā)人員通常設(shè)計(jì) slashers，將這個(gè)特定組件模塊化可以簡(jiǎn)化各個(gè) AVS 的開(kāi)發(fā)流程。

與 TokenManager 類似，我們將為 slash 機(jī)制采用兩部分設(shè)計(jì)。SlasherManager 維護(hù)每個(gè)操作員的狀態(tài)。單獨(dú)的 slasher 將處理每個(gè) AVS 的 slash 邏輯。

更進(jìn)一步模塊化 slash 合約以減少質(zhì)押者的 gas 成本。

contract slasher { ? ?function slash(address operator, ??? proof) public;}

slasher 將是特定于 AVS 的，很可能由 AVS 開(kāi)發(fā)人員開(kāi)發(fā)。它將與 SlasherManager 交互，以更新不同操作員的狀態(tài)。

EigenLayer 已設(shè)計(jì)好！

回顧一下：EigenLayer 的目標(biāo)是簡(jiǎn)化基礎(chǔ)架構(gòu)搭建。我們從四個(gè)主要目標(biāo)開(kāi)始：

構(gòu)建一個(gè)平臺(tái)連接質(zhì)押者和基礎(chǔ)架構(gòu)開(kāi)發(fā)人員。

允許質(zhì)押者使用任何代幣提供經(jīng)濟(jì)安全性。

使質(zhì)押者能夠重新質(zhì)押他們的質(zhì)押，并在為其他基礎(chǔ)架構(gòu)提供安全性的同時(shí)賺取原生 ETH 獎(jiǎng)勵(lì)。

通過(guò)重新質(zhì)押來(lái)池化安全性，而不是使其分散化。

經(jīng)過(guò)幾次迭代，我們開(kāi)發(fā)了三個(gè)核心組件：TokenManager、DelegationManager 和 SlasherManager。每個(gè)組件都有特定的功能：

EigenLayer 的簡(jiǎn)化架構(gòu)

TokenManager：處理質(zhì)押者的質(zhì)押和提取。

DelegationManager：允許操作員注冊(cè)和跟蹤操作員份額。

SlasherManager：為 AVS 開(kāi)發(fā)人員提供確定 slash 邏輯的接口。

這些核心組件還相互通信，以確保整個(gè)系統(tǒng)的安全性。

除了這些核心合約之外，還有許多其他功能和合約，增強(qiáng)整個(gè)堆棧。這些附加功能支持各種 AVS 設(shè)計(jì)，簡(jiǎn)化離線技術(shù)復(fù)雜性，并減少用戶和操作員的 gas 費(fèi)用。

要了解更多關(guān)于這些其他功能的信息，你可以訪問(wèn)我們的開(kāi)源代碼庫(kù)：https://github.com/Layr-Labs/eigenlayer-contracts

附加 1：誰(shuí)信任誰(shuí)？

當(dāng)系統(tǒng)是模塊化的時(shí)候，跟蹤協(xié)議中參與者之間的信任假設(shè)可能是具有挑戰(zhàn)性的。因此，明確概述協(xié)議中涉及的參與者之間的信任假設(shè)是至關(guān)重要的。

在 EigenLayer 中，有三個(gè)主要代理：質(zhì)押者、操作員和 AVS 開(kāi)發(fā)人員。

操作員依賴于 AVS 開(kāi)發(fā)人員準(zhǔn)確編寫客戶端軟件和鏈上 slash 條件。如果 AVS 軟件中存在 bug，最好的情況下，操作員可能會(huì)錯(cuò)過(guò)潛在的費(fèi)用支付。最壞的情況下，操作員可能會(huì)因此被 slash 全部質(zhì)押。

鑒于所涉及價(jià)值的重要性，確保整個(gè)系統(tǒng)在投入使用之前具有輔助訓(xùn)練輪是非常重要的。

否決委員會(huì)充當(dāng)這些訓(xùn)練輪。它有權(quán)力撤銷由于非惡意行為導(dǎo)致的 slash。否決委員會(huì)是質(zhì)押者、操作員和 AVS 開(kāi)發(fā)人員之間的相互信任方。

這樣，對(duì) AVS 開(kāi)發(fā)人員的信任假設(shè)可以被移除。即使 AVS 中存在軟件 bug，質(zhì)押者和操作員也不會(huì)受到懲罰。

質(zhì)押者信任他們委托的操作員。如果操作員行為不端，質(zhì)押者可能會(huì)錯(cuò)過(guò)潛在的費(fèi)用支付，甚至失去全部質(zhì)押。這一信任假設(shè)與現(xiàn)有的驗(yàn)證服務(wù)（如幣安質(zhì)押和其他質(zhì)押服務(wù)）相同。

AVS 開(kāi)發(fā)人員依賴于操作員誠(chéng)實(shí)操作。如果操作員不誠(chéng)實(shí)，AVS 服務(wù)將顯著下降，導(dǎo)致客戶流失和其他后果。

在參與者之間，通過(guò)否決委員會(huì)，信任假設(shè)如下：

質(zhì)押者信任操作員誠(chéng)實(shí)行事，不端行為可能導(dǎo)致 slash。

AVS 開(kāi)發(fā)人員信任操作員誠(chéng)實(shí)操作 AVS 軟件。

質(zhì)押者、操作員和 AVS 開(kāi)發(fā)人員信任否決委員會(huì)來(lái)撤銷 slash。

附加 2：原生 Restaking

到目前為止，我們已經(jīng)討論了使用 LST 進(jìn)行重新質(zhì)押。但是，如果你不想通過(guò)流動(dòng)質(zhì)押協(xié)議對(duì) EigenLayer 進(jìn)行質(zhì)押，你可以通過(guò)原生重新質(zhì)押開(kāi)始參與 EigenLayer。

讓我們定義原生重新質(zhì)押：這是使用驗(yàn)證器內(nèi)的 ETH 進(jìn)行額外承諾的過(guò)程。如果驗(yàn)證器偏離承諾，它們將失去其驗(yàn)證器內(nèi)持有的 ETH。

這里的挑戰(zhàn)在于，這些驗(yàn)證器內(nèi)的 ETH 不是以 ERC20 代幣的形式表示。相反，ETH 存在于信標(biāo)鏈上。如果你對(duì)執(zhí)行層或共識(shí)層（信標(biāo)鏈）不熟悉，這篇解釋[17]是一個(gè)讓你快速了解的好資源。

為了解決這個(gè)問(wèn)題，我們可以使用 EigenPod 來(lái)跟蹤以太坊驗(yàn)證器余額，并在必要時(shí) slash 它們。

EigenPod 充當(dāng)虛擬記賬系統(tǒng)。通過(guò) EigenPod，我們可以監(jiān)視每個(gè)重新質(zhì)押驗(yàn)證器的 ETH 余額。

在高層次上，EigenPods 處理驗(yàn)證器的提取過(guò)程。當(dāng)驗(yàn)證器從 EigenLayer 提取其質(zhì)押時(shí)，ETH 首先通過(guò) EigenPod，以檢查驗(yàn)證器是否已被 slash。如果驗(yàn)證器已被 slash，代幣將在 EigenPod 合約內(nèi)凍結(jié)，有效地 slash 它們。

實(shí)現(xiàn) EigenPod

實(shí)現(xiàn) EigenPod 是棘手的，因?yàn)橐蕴或?yàn)證器余額存儲(chǔ)在信標(biāo)鏈上，我們無(wú)法訪問(wèn)執(zhí)行層上的信標(biāo)鏈數(shù)據(jù)。

為了解決這個(gè)問(wèn)題，我們利用一個(gè)預(yù)言機(jī)將信標(biāo)鏈狀態(tài)根傳遞到執(zhí)行層。通過(guò)獲取信標(biāo)狀態(tài)根，我們可以通過(guò)提供相應(yīng)的默克爾證明來(lái)訪問(wèn)驗(yàn)證者的余額。

有了 EIP-4788[18] 的實(shí)施，我們可以移除這個(gè)預(yù)言機(jī)，并直接從執(zhí)行層查詢信標(biāo)根。

為了封裝記賬系統(tǒng)，我們將采用類似TokenPool和TokenManager模型的模式，來(lái)模塊化本地的再質(zhì)押系統(tǒng)。每個(gè)EigenPod將處理一個(gè)驗(yàn)證者的提款過(guò)程。EigenPodManager將與其他核心合約協(xié)調(diào)，以跟蹤每個(gè)操作員和質(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跟蹤每個(gè)質(zhì)押者擁有的份額數(shù)量。它允許質(zhì)押者創(chuàng)建EigenPod，對(duì)其進(jìn)行質(zhì)押，并從中提款。

EigenPod通過(guò)restakedBalance變量跟蹤信標(biāo)鏈上各個(gè)驗(yàn)證者的余額。每當(dāng)任何再質(zhì)押驗(yàn)證者的余額發(fā)生變化時(shí)，任何人都可以通過(guò)調(diào)用verifyRestakedBalance()函數(shù)來(lái)更新該特定驗(yàn)證者的余額。該函數(shù)將通過(guò)我們從BEACON_CHAIN_ORACLE獲取的信標(biāo)狀態(tài)根來(lái)檢查更新后的余額是否正確。

這就是 EigenLayer 如何實(shí)現(xiàn)本地再質(zhì)押。

參考資料

[1]登鏈翻譯計(jì)劃: 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_