Hiểu EigenLayer từ góc độ thiết kế lại

Nguồn: Cộng đồng Denglian

Trong bài đăng trên blog này, chúng tôi sẽ hướng dẫn bạn hiểu về sự tiến hóa của giao thức EigenLayer, mô tả cách kiến ​​trúc EigenLayer xuất hiện từ ý tưởng ban đầu của nó.

Blog này được lấy cảm hứng từ loạt bài Tóm tắt tài khoản của David Philipson ^{[5]< /sup> truyền cảm hứng. Đặc biệt cảm ơn cộng đồng Noam Horowitz[6], Shiva[7], NashQ[8], Mike Neuder[9] và Sina[10] vì những nhận xét và phản hồi của họ về bài viết này.}

Trong khi nhiều người quen thuộc với các điều khoản đặt lại và EigenLayer, chỉ một số ít biết rằng hợp đồng cốt lõi của chúng tôi chứa hàng nghìn dòng code< sup>[11] , cấu trúc của nó như sau.

EigenLayer đơn giản hóa kiến ​​trúc

Tại sao một ý tưởng trông có vẻ đơn giản lại trở nên phức tạp đến thế?

Trong bài đăng trên blog này, chúng tôi sẽ giới thiệu cho bạn về giao thức bằng cách mô tả cách kiến ​​trúc phức tạp hiện tại của EigenLayer xuất hiện từ khái niệm ban đầuSự tiến hóa .

Bài viết này dành cho những người có hiểu biết cơ bản về hợp đồng thông minh và đã nghe nói về EigenLayer hoặc việc đặt lại.

Vì mục đích của bài đăng trên blog này là cung cấp giải thích cấp cao về sự phát triển thiết kế của EigenLayer, Do đó, giao diện, các biến và logic có thể khác với hợp đồng cốt lõi EigenLayer hiện tại ^[12].

Bây giờ, hãy bắt đầu.

Mục tiêu cuối cùng: giúp việc xây dựng cơ sở hạ tầng trở nên dễ dàng

Trước tiên, hãy bắt đầu với phần giới thiệu Vấn đề EigenLayer muốn giải quyết. Nếu bạn đã quen thuộc với phần này, vui lòng chuyển sang các chương sau.

Các nhà phát triển xây dựng cơ sở hạ tầng phi tập trung trên Ethereum phải đối mặt với thách thức thiết lập an ninh kinh tế của riêng họ. Mặc dù Ethereum cung cấp bảo mật kinh tế cho các giao thức hợp đồng thông minh,cơ sở hạ tầng như cầu nối hoặc trình sắp xếp chuỗi yêu cầu bảo mật kinh tế riêngđể cho phép mạng lưới các nút phân tán đạt được sự đồng thuận.

Các cơ chế đồng thuận rất quan trọng để tạo điều kiện thuận lợi cho sự tương tác giữa các nút này, cho dù đó là L1, mạng oracle hay cầu nối.

Bằng chứng công việc^[13] tiêu tốn năng lượng nghiêm trọng và bằng chứng về quyền hạn^[14] quá tập trung.Do đó, Proof of Stake^[15] (PoS) đã trở thành cơ chế đồng thuậnchính cho hầu hết các dự án cơ sở hạ tầng.

Tuy nhiên, việc ra mắt mạng PoS mới rất khó khăn.

Trước hết, rất khó để xác định người đặt cược (người đưa ra cam kết) ở đâu. Không có nơi nào tốt cho các nhà phát triển để tìm người đặt cọc.

Thứ hai, người đặt cược phải đầu tư một số tiền lớn để có được tài sản thế chấp cho mạng mới, thường bằng cách mua mã thông báo gốc của mạng, mà chúng thường dễ bay hơi và khó có được.

Thứ ba, người đặt cược phải từ bỏ các cơ hội nhận thưởng khác, chẳng hạn như phần thưởng 5% do Ethereum cung cấp.

Cuối cùng, mô hình bảo mật hiện tại không lý tưởng vì chi phí phá vỡ bất kỳ dApp nào chỉ được yêu cầu để phá vỡ các phần phụ thuộc cơ sở hạ tầng dễ bị tổn thương nhất của nó giá của.

Giả sử hiện tại rằng những người tham gia vào các dự án cơ sở hạ tầng cũng chịu trách nhiệm hoạt động ngoại tuyến phần mềm để đảm bảo sự an toàn của họ. Nhưng chúng tôi sẽ thay đổi giả định này ở phần sau của bài viết.

EigenLayer được tạo ra để giải quyết những vấn đề sau:

• Nó đóng vai trò như một nền tảng để kết nối những người đặt cược và các nhà phát triển cơ sở hạ tầng.

• Người đặt cược có thể sử dụng bất kỳ mã thông báo nào để cung cấp bảo mật tài chính.

• Người cầm cố có thể chọn thực hiện lại các cam kết ban đầu của mình và đóng góp vào sự bảo mật của cơ sở hạ tầng khác trong khi nhận phần thưởng Native Ether.

• Bằng cách đặt lại, EigenLayer tập hợp bảo mật lại với nhau thay vì phân mảnh nó.

Sách trắng của EigenLayer^[16] Những vấn đề này được thảo luận sâu sắc.

EigenLayer khái quát hóa khái niệm cung cấp an ninh kinh tế.

Mục tiêu 1: Tạo nền tảng kết nối những người đặt cược và nhà phát triển cơ sở hạ tầng

EigenLayer là một nền tảng nơi những người thế chấp có thể đưa ra các cam kết cho bất kỳ dự án cơ sở hạ tầng nào và các dự án cơ sở hạ tầng có thể được quảng bá cho những người thế chấp tiềm năng trên EigenLayer. Cốt lõi của nền tảng làcho phép các bên liên quan đưa ra các cam kết đáng tin cậy đối với các cơ sở hạ tầng khác nhau.

Những cam kết này áp dụng cho tất cả các hệ thống bằng chứng cổ phần, không chỉ EigenLayer. Người đặt cược L1 thường cam kết tuân theo các quy tắc giao thức và có nguy cơ mất cổ phần nếu một khối xung đột được ký ở cùng độ cao khối.

Các nhà phát triển cơ sở hạ tầng xây dựng logic và phần mềm cơ sở hạ tầng, trong khi các nhà đầu tư đưa ra cam kết bảo mật cơ sở hạ tầng. _Cam kết này được cung cấp như mộtcam kết đối với người sử dụng cơ sở hạ tầng. _ Cam kết này nhằm giúp thỏa thuận diễn ra suôn sẻ vàchống lại các hành vi sai trái cụ thể.

Về mặt khái niệm khi một dự án có 100 triệu USD được cam kết đằng sau, điều đó có nghĩa là nếu nó đi chệch _một phần trong số 100 triệu USD này sẽ bị cắt_ nếu vi phạm lời hứa và thể hiện thái độ xấu. Nói một cách đơn giản, “cắt” có thể hiểu là phá hủy quỹ này.

Số càng cao thì nó càng mang lại sự an toàn và bảo mật cho người dùng.

Nếu chúng tôi cho phép những người đặt cược chỉ định cổ phần cho các cam kết khác nhau, thì chúng tôi có thể tạo một nền tảng thân thiện với người dùng trên đó.

Chúng tôi cần một nền tảng không cần tin cậy và có thể lập trình để thực hiện các cam kết khác nhau của người đặt cược vàEthereum là lựa chọn phù hợp nhất. Ngoài ra, Ethereum nắm giữ số lượng cam kết lớn nhất, giúp khởi động thị trường staker.

Mục tiêu ở đây là những người đặt cược có thể cung cấp bảo mật cho giao thức cầu nối trên Ethereum thông qua EigenLayer. Nếu một người đặt cược cố ý giả mạo một tin nhắn trên Ethereum và truyền nó tới Gnosis, bất kỳ ai cũng có thể gửi bằng chứng và chém người đặt cược đó.

Vì cam kết và việc thực hiện cam kết của người đặt cọc diễn ra trên Ethereum nên logic giảm thiểu cũng được triển khai dưới dạng hợp đồng thông minh Ethereum. Nếu người đặt cược vi phạm cam kết của mình, bất kỳ ai cũng có thể cung cấp bằng chứng cho hợp đồng chặt chém và tịch thu lời cam kết của người đặt cược ác ý.

Điều này tạo nên nền tảng của EigenLayer - bất kỳ nhà đầu tư nào cũng có thể đưa ra cam kết đáng tin cậy đối với bất kỳ giao thức cơ sở hạ tầng nào.

Thiết kế ban đầu của EigenLayer

Bây giờ, hãy thử triển khai điều này. Chúng ta sẽ bắt đầu với thiết kế đơn giản nhất: người đặt cược đặt cọc mã thông báo của họ vào một hợp đồng bao gồm chức năng cho phép cắt giảm mã thông báo của người đặt cược khi bằng chứng được gửi và tiêu chí được đáp ứng. Sau đó, người dùng có thể rút số dư của mình.

Những người cầm cố khác cũng có thể đặt cọc token vào hợp đồng này, tăng tính bảo mật cho cơ sở hạ tầng. Chúng tôi sẽ gọi hợp đồng này là TokenPool.

Để rõ ràng hơn, đây là một số định nghĩa về các thuật ngữ được sử dụng trong bài viết này:

< li >

Các bên liên quan: Bất kỳ ai cung cấp mã thông báo cho EigenLayer.

• Mã thông báo: bất kỳ loại mã thông báo nào; bây giờ chỉ cần coi nó là mã thông báo ERC20 .

• TokenPool: Một hợp đồng thông minh giúp tiết kiệm token của người đặt cược.

• Cắt: Loại bỏ quyền truy cập của người đặt cược vào mã thông báo đã đặt cược của họ.

< span style="text-align: center;">Giao diện của TokenPool này có thể được thể hiện như sau:

hợp đồng TokenPool {
    mapping(address => uint256) số dư công khai;
   ;   ánh xạ(địa chỉ => địa chỉ[]) kẻ giết người công khai;

    hàm cổ phần(số tiền uint256) công khai;
    hàm rút() công khai;
     ;chỉ đăng ký chức năng(dấu gạch chéo địa chỉ)Chủ sở hữu;
>

ngoại trừ stake< /code> , rút và balance và các biến, chúng tôi cũng giới thiệu một hàm mới và một biến mới. Biến slasher giám sát AVS hiện đã được đăng ký của mỗi người đặt cược. Chức năng đăng ký cho phép người đặt cọc tham gia AVS

Do đó, việc đăng ký AVS thực sự mang lại cho "kẻ chém" khả năng cắt cổ phần của bạn .

Với sửa đổi này, sau khi đặt cược vào TokenPool, người đặt cược có thể tham gia bằng cách gọi hàm đăng ký AVS cụ thể . Hàm này chứa hợp đồng dấu gạch chéo dành riêng cho AVS vào ánh xạ slasher.

Chức năng đăng ký ở đây được kiểm soát quyền truy cập vì nó có thể cho phép bất kỳ ai có khả năng đăng ký bất kỳ hợp đồng giảm giá nào. Để đảm bảo rằng TokenPool này được quản lý an toàn, chúng tôi sẽ cho rằng nó được giám sát bởi bên thứ ba đáng tin cậy.

Trong quá trình trích xuất, hợp đồng TokenPool có thể yêu cầu mỗi slasherXác định xem người đặt cược có đủ điều kiện để rút tiền hay không. Điều này được xác minh thông qua hàm isSlashed trong hợp đồng slasher. Nếu isSlashed là TRUE đối với người đặt cược này thì người đặt cược không thể rút tiền đặt cược của mình vì chúng đã bị cắt.

hợp đồng TokenPool {< br>    mapping(address => uint256) public stakerBalance;
    mapping(address => uint256) public operatorBalance;
    mapping(address => address) ủy quyền công khai;
    ánh xạ(địa chỉ => địa chỉ[]) kẻ chém công khai;

    cổ phần chức năng(số tiền uint256) công khai;
    rút chức năng () public;
    function delegateTo(toán tử địa chỉ) public;
    hàm ghi danh(dấu gạch chéo địa chỉ) operatorOnly;
    function exit(dấu gạch chéo địa chỉ) operatorOnly;< br>>

Chúng tôi đã chia biến số dư thành hai phần khác nhau : Một cho người điều hành và một cho người cầm cố. Ngoài ra, chúng tôi giới thiệu ánh xạ ủy quyền để ghi lại mối quan hệ ủy quyền giữa người cầm cố và người điều hành.

Chúng tôi cũng đã thực hiện những thay đổi nhỏ đối với ánh xạ slasher. Bây giờ, nó trao quyền chém theo hợp đồng slasher cho người vận hành, thay vì cho người đặt cược.

hợp đồng TokenPool {
    mapping(address => uint256) public stakerBalance;
 
    cổ phần chức năng(số tiền uint256) công khai;
    rút chức năng() công khai;
>

TokenPoolHợp đồng sẽ chỉ theo dõi số dư của từng người đặt cọc. Việc theo dõi và tham gia AVS sẽ do DelegationManager xử lý.

dấu gạch chéo hợp đồng {
    ánh xạ (địa chỉ => bool) isSlashed;

    chữ gạch chéo chức năng (toán tử địa chỉ, ??? bằng chứng);

>

Sau khi dọn dẹp hợp đồng cấu trúc và Sau khi mô-đun hóa từng thành phần, kiến ​​trúc bây giờ trông như thế này:

Thiết kế trung gian EigenLayer: sau khi tách vai trò người vận hành và vai trò người đóng góp.

Mục tiêu: hỗ trợ nhiều token hơn

Cho đến nay, chúng tôi đã phát triển thiết kế chỉ hỗ trợ đặt cượcamã thông báo vì chúng tôi chỉ duy trì ánh xạa cho người đặt cược.

Chúng tôi có thể giải quyết vấn đề này bằng cách áp dụng mô hình dựa trên chia sẻ LP và tạo TokenPool.

Để thực hiện việc này, chúng ta sẽ tạo một hợp đồng mới có tên là TokenManager. Trình quản lý mã thông báo sẽ là nơi người đặt cược đến đặt cược và rút mã thông báo của họ.

Trong TokenManager, mỗi mã thông báo sẽ có TokenPool . TokenManager sẽ đóng vai trò là trung tâm kế toán cho tất cả các token; nó sẽ không lưu trữ bất kỳ token nào. Mỗi TokenPool sẽ giữ mã thông báo tương ứng của riêng mình.

Một thành phần mới được thiết kế để theo dõi các mã thông báo khác nhau của người đặt cược.

Khi người dùng đặt cọc mã thông báo, mã thông báo đó sẽ được xử lý bởi TokenManager. Sau đó, TokenManager gọi hàm stake của TokenPool tương ứng được liên kết với mã thông báo đó. Mã thông báo của người dùng sẽ được chuyển tới TokenPool. Khi kết thúc chức năng, totalShares và sakerPoolShares sẽ được cập nhật để phản ánh số cổ phần mới. totalShares theo dõi tổng số cổ phiếu do TokenPool phát hành, trong khi sakerPoolShares ghi lại số cổ phần nắm giữ của từng nhà đầu tư riêng lẻ trong mỗi TokenPool mã> số lượng cổ phiếu.

Giao diện của từng hợp đồng sẽ như sau:

Trình quản lý ủy quyền hợp đồng {
    // .. .
    mapping(địa chỉ => ánh xạ(địa chỉ => uint256)) operatorPoolShares;
    // ...

Giờ đây, theo cùng một kiến ​​trúc cốt lõi, người đặt cược có thể đặt cược bất kỳ mã thông báo nào vào EigenLayer để bảo vệ AVS khác. 
Mục tiêu: Mở rộng thiết kế AVS
Hãy xem xét các tình huống sau : Người đặt cược rút lại cam kết của họngay lập tứcsau khi thực hiện hành vi có thể bị chém và rúttrước khi bất kỳ ai khác chém tài sản của họ. 
_Ví dụ_, giả sử có một nhà điều hành vừa là người điều hành vừa là người đặt cược, hành động có ác ý trong AVS. Trước khi bất kỳ ai khác có thể đặt cược trên chuỗi, nhà điều hành sẽ rút cổ phần của họ khỏi hợp đồng EigenLayer. Điều này có thể thực hiện được vì tại thời điểm rút tiền, slasher vẫn chưa cập nhật để chém tài sản của mình. Do đó, AVS không thể chém các nhà khai thác/người đặt cược độc hại nữa vì không còn token nào để chém nữa. 
 Dòng thời gian tiềm năng của các sự kiện dành cho các nhà khai thác/kẻ đặt cược độc hại. 
Do đó, AVS "bảo mật" yêu cầu AVS có thể đóng băng nội dung độc hại trong cùng một khối nơi xảy ra sự kiện .Giảm hợp đồng của nhà điều hành. Hạn chế này hạn chế đáng kể việc thiết kế AVS, khiến hầu hết AVS không an toàn. 
Một giải pháp là áp dụng giai đoạn tách nhóm. Thay vì cho phép người đặt cọc rút tiền ngay lập tức, chúng tôi sẽ đưa ra một độ trễ trong quá trình rút tiền được gọi là thời gian hủy đặt cược. Sau đó, người đặt cọc có thể rút tiền như trước. 
Khi người đặt cược quyết định rút khỏi hệ thống, yêu cầu của họ sẽ được đưa vào hàng đợi. Việc rút tiền được xếp hàng này sẽ chỉ được xử lý sau khi khoảng thời gian không ràng buộc dài nhất của nhà điều hànhđã hết hạn. Điều này là do một nhà điều hành có thể quản lý nhiều AVS, nhưng việc rút tiền của người đặt cọc chỉ có thể được liên kết với một khoảng thời gian không liên kết. Vì lý do bảo mật, hệ thống đặt khoảng thời gian không ràng buộc thành khoảng thời gian dài nhất. 
Ví dụ: nếu người đặt cọc ủy thác cam kết của họ cho các nhà khai thác tham gia ba AVS, thì thời gian không liên kết của ba AVS này lần lượt là sáu, năm và bảy ngày, sau đó sau khi yêu cầu rút tiền khỏi EigenLayer, họ phải đợi bảy ngày để truy cập vào số cổ phần của mình. Điều này là do bảy ngày là thời gian dài nhất trong ba thời kỳ. 
Khi kết thúc thời hạn bảy ngày, người đặt cọc có thể rút số tiền đặt cược của mình. Tuy nhiên, nếu nhà điều hành mà họ được ủy thác bị hạn chế trong thời gian này thì các khoản rút tiền đang chờ xử lý cũng sẽ bị dừng. 
Để giới thiệu thay đổi này, DelegationManager cần theo dõi khoảng thời gian hủy liên kết của từng toán tử và cập nhật nó khi toán tử tham gia Cập nhật nó khi có AVS mới. 
hợp đồng TokenManager {
 ánh xạ(địa chỉ => địa chỉ) public tokenPoolRegistry;
 ánh xạ(địa chỉ => ánh xạ(địa chỉ => uint256)) public stakerPoolShares;
 ánh xạ(địa chỉ => uint256) rút tiền công khaiCompleteTime;

 chức năng stakeToPool(nhóm địa chỉ, số tiền uint256) công khai;
 chức năng queueWithdrawal(nhóm địa chỉ) công khai;
 chức năng hoàn thànhWithdrawal(nhóm địa chỉ) công khai ;


Khi người đặt cọc xếp hàng để rút tiền, TokenManager sẽ làm việc với < code>Trình quản lý ủy quyền Xác minh xem toán tử được ủy quyền bởi người cầm cố có bị gạch chéo hay không. Nếu toán tử không bị gạch chéo, TokenManager sẽ cập nhật withdrawalCompleteTime của người đặt cọc dựa trên DelegationManager của unbondingPeriod và thời điểm hiện tại. 
Sau khoảng thời gian không ràng buộc, người đặt cược có thể hoàn tất việc rút tiền thông qua completeWithdrawal. Hàm này sẽ xác minh rằng withdrawalCompleteTime đã trôi qua. Nếu vượt qua, mã thông báo của người đặt cọc sẽ được chuyển đi theo quy trình trước đó. 
Thiết kế của quy trình này rất phức tạp và đã trải qua nhiều lần lặp lại trong quy trình của chúng tôi . Chúng tôi thậm chí có thể viết một bài viết riêng về chủ đề này! Hiện tại, chúng tôi sử dụng hệ thống theo dõi thời gian để triển khai tính năng theo dõi tách nhóm này. Phần này vẫn đang được hoàn thiện! 
Dấu gạch chéo theo mô-đun
Vì chúng tôi đang tạo dấu gạch chéo an toàn hơn, chúng ta cũng hãy cố gắng làm cho nó trở nên mô đun và hiệu quả hơn. 
Hiện tại, trong quá trình trích xuất, TokenManager cần kiểm tra với từng slasher riêng lẻ để kiểm tra xem người điều hành đã bị cắt giảm. Điều này làm tăng thêm chi phí gas cho những người đặt cược và có thể giảm đáng kể phần thưởng cho những người đặt cược nhỏ hơn. 
Ngoài ra, do các nhà phát triển AVS thường thiết kế các dấu gạch chéo nên việc mô-đun hóa thành phần cụ thể này có thể đơn giản hóa quá trình phát triển cho từng AVS riêng lẻ. 
Tương tự như TokenManager, chúng tôi sẽ áp dụng thiết kế hai phần cho cơ chế gạch chéo. SlasherManager duy trì trạng thái của từng toán tử. Một slasher riêng biệt sẽ xử lý logic gạch chéo cho từng AVS. 
 Tiếp tục mô-đun hóa hợp đồng cắt giảm để giảm chi phí gas cho các nhà đầu tư. 
Dấu gạch chéo hợp đồng {
    chức năng dấu gạch chéo(toán tử địa chỉ, ??? bằng chứng) công khai;

slasher sẽ dành riêng cho AVS, rất có thể được phát triển bởi các nhà phát triển AVS. Nó sẽ tương tác với SlasherManager để cập nhật trạng thái của các toán tử khác nhau. 
EigenLayer đã được thiết kế! 
Để xem xét:Mục tiêu của EigenLayer là đơn giản hóa việc xây dựng cơ sở hạ tầng.  Chúng tôi bắt đầu với bốn mục tiêu chính: 
Xây dựng một nền tảng để kết nối những người đặt cược và nhà phát triển cơ sở hạ tầng. 
Cho phép người đặt cọc sử dụng bất kỳ mã thông báo nào để cung cấp bảo mật kinh tế. 
Cho phép người đặt cược đặt lại cổ phần của họ và kiếm phần thưởng ETH gốc đồng thời cung cấp bảo mật cho cơ sở hạ tầng khác. 
Bảo mật nhóm thông qua việc đặt cược lại thay vì phân cấp nó. 
Sau vài lần lặp lại, chúng tôi đã phát triển ba thành phần cốt lõi: TokenManager , DelegationManager và SlasherManager. Mỗi thành phần có các chức năng cụ thể: 
Kiến trúc đơn giản hóa của EigenLayer
< code>TokenManager : xử lý việc cầm cố và rút tiền của người cầm cố. 
DelegationManager: Cho phép đăng ký nhà điều hành và theo dõi cổ phần của nhà điều hành. 
SlasherManager: Cung cấp giao diện cho các nhà phát triển AVS để xác định logic dấu gạch chéo. 
Các thành phần cốt lõi này cũng giao tiếp với nhau để đảm bảo tính bảo mật cho toàn bộ hệ thống. 
Ngoài các hợp đồng cốt lõi này, còn có nhiều tính năng và hợp đồng khác giúp nâng cao toàn bộ hệ thống. Các tính năng bổ sung này hỗ trợ nhiều thiết kế AVS khác nhau, đơn giản hóa sự phức tạp về kỹ thuật ngoại tuyến và giảm chi phí gas cho người dùng và người vận hành. 
Để tìm hiểu thêm về các tính năng bổ sung này, bạn có thể truy cập kho lưu trữ mã nguồn mở của chúng tôi: https://github.com/Layr-Labs/eigenlayer -contracts< /p>
Bổ sung 1: Ai tin tưởng ai? 
Khi hệ thống ở dạng mô-đun, việc theo dõi các giả định về độ tin cậy giữa những người tham gia giao thức có thể gặp khó khăn. Do đó, điều quan trọng là phải phác thảo rõ ràng các giả định về niềm tin giữa các bên tham gia thỏa thuận. 
Trong EigenLayer, có ba tác nhân chính: người đặt cược, người điều hành và nhà phát triển AVS. 
Các nhà khai thác dựa vào các nhà phát triển AVS để viết chính xác phần mềm máy khách và các điều kiện cắt giảm trên chuỗi. Nếu có lỗi trong phần mềm AVS, trong trường hợp tốt nhất, nhà điều hành có thể bỏ lỡ các khoản thanh toán phí tiềm năng. Trường hợp xấu nhất, nhà điều hành có thể bị cắt toàn bộ cổ phần của mình. 
Do tầm quan trọng của các giá trị liên quan, điều quan trọng là phải đảm bảo rằng toàn bộ hệ thống có bánh xe phụ trợ trước khi đưa vào sử dụng vào sử dụng. 
Các ủy ban phủ quyết đóng vai trò như những bánh xe đào tạo. Nó có khả năng hoàn tác các dấu gạch chéo gây ra bởi hành vi không ác ý. Ủy ban phủ quyết là sự tin cậy lẫn nhau giữa các bên liên quan, nhà điều hành và nhà phát triển AVS. 
Bằng cách này, có thể loại bỏ sự tin tưởng vào các nhà phát triển AVS. Ngay cả khi AVS xảy ra lỗi phần mềm, người đặt cọc và người vận hành sẽ không bị trừng phạt. 
Người đặt cọc tin tưởng vào người điều hành mà họ giao phó. Nếu nhà điều hành hành xử sai, người đặt cược có thể bỏ lỡ các khoản thanh toán phí tiềm năng hoặc thậm chí mất toàn bộ cổ phần của họ. Giả định về độ tin cậy này giống như các dịch vụ xác minh hiện có như Binance Stake và các dịch vụ đặt cược khác. 
Các nhà phát triển AVS dựa vào các nhà điều hành hoạt động trung thực. Nếu các nhà điều hành không trung thực, dịch vụ của AVS sẽ suy giảm đáng kể, dẫn đến tình trạng khách hàng rời bỏ và các hậu quả khác. 
Giữa những người tham gia, thông qua ủy ban phủ quyết, sự tin tưởng được giả định như sau:
 
Người cầm cố tin tưởng người điều hành hành động trung thực, hành vi sai trái có thể dẫn đến bị chém. 
Các nhà phát triển AVS tin tưởng các nhà khai thác vận hành phần mềm AVS một cách trung thực. 
Các bên liên quan, nhà điều hành và nhà phát triển AVS tin tưởng vào ủy ban phủ quyết để hoàn tác các dấu gạch chéo. 
Bổ sung 2: Đặt lại gốc
Cho đến nay, chúng tôi đã thảo luận về việc sử dụng LST để đặt cược lại. Tuy nhiên, nếu bạn không muốn đặt cược EigenLayer thông qua Giao thức đặt cược lỏng, bạn có thể bắt đầu tham gia EigenLayer thông qua việc đặt cược lại gốc. 
Hãy xác định việc đặt cược lại gốc: Đây là quá trình thực hiện các cam kết bổ sung bằng cách sử dụng ETH trong trình xác thực. Nếu người xác thực đi chệch khỏi cam kết, họ sẽ mất ETH được giữ trong trình xác thực của họ. 
Thách thức ở đây là ETH trong các trình xác thực này không được thể hiện dưới dạng mã thông báo ERC20. Thay vào đó, ETH tồn tại trên Chuỗi Beacon. Nếu bạn không quen với lớp thực thi hoặc lớp đồng thuận (chuỗi báo hiệu), phần giải thích [17] này là một nguồn tài nguyên tốt giúp bạn bắt kịp tốc độ. 
Để giải quyết vấn đề này, chúng ta có thể sử dụng EigenPod để theo dõi số dư của trình xác thực Ethereum và cắt giảm chúng khi cần thiết. 
EigenPod hoạt động như một hệ thống kế toán ảo. Với EigenPod, chúng tôi có thể theo dõi số dư ETH của mỗi trình xác thực đặt cược lại. 
Ở cấp độ cao, EigenPods xử lý quy trình trích xuất của trình xác thực. Khi người xác thực rút cổ phần khỏi EigenLayer, ETH đầu tiên sẽ chuyển qua EigenPod để kiểm tra xem người xác thực đã bị cắt hay chưa. Nếu trình xác thực đã bị cắt, các mã thông báo sẽ bị đóng băng trong hợp đồng EigenPod, việc cắt giảm chúng một cách hiệu quả. 
Triển khai EigenPod
Việc triển khai EigenPod rất khó vì trình xác thực Ethereum số dư được lưu trữ trên chuỗi beacon và chúng tôikhông thể truy cập dữ liệu chuỗi beacon trên lớp thực thi. 
Để giải quyết vấn đề này, chúng tôi sử dụng oracle để chuyển gốc trạng thái của chuỗi beacon tới lớp thực thi. Bằng cách lấy gốc trạng thái báo hiệu, chúng tôi có thể truy cập số dư của người xác nhận bằng cách cung cấp bằng chứng Merkle tương ứng. 
Với việc triển khai EIP-4788[18], chúng tôi có thể xóa oracle này và truy vấn thông tin trực tiếp từ dấu lớp thực thi nguồn gốc. 
Để gói gọn hệ thống kế toán, chúng ta sẽ sử dụng các mô hình tương tự như mô hình TokenPool và TokenManager đến< strong>Mô-đunHệ thống cam kết lại cục bộ. Mỗi EigenPod sẽ xử lý quy trình rút tiền cho một trình xác thực. EigenPodManager sẽ phối hợp với các hợp đồng cốt lõi khác để theo dõi lượng ether được đặt cược bởi mỗi nhà điều hành và người đặt cược. 
<span ) 10px 10px / 40px không lặp lại ;height: 30px;width: 100% ;margin-bottom: -7px;bán kính đường viền: 5px;'>hợp đồng EigenPodManager{
    mapping(address => uint256) công khai khôi phụcChia sẻ;

    function createEigenPod(chủ sở hữu địa chỉ) công khai;
    function stakeToPod(nhóm địa chỉ, số tiền uint256) công khai;
     ;hàm rútFromPod(nhóm địa chỉ) công khai;

hợp đồng EigenPod{
    địa chỉ BEACON_CHAIN_ORACLE;
    địa chỉ podOwner;
    uint256 retakedAmount;< br>
    cổ phần chức năng(số tiền uint256) công khai;
    chức năng verifyRestakedBalance(số tiền uint256, bằng chứng MerkleProof) công khai;
    chức năng rút tiền() công khai;

EigenPodManagerTheo dõi số lượng cổ phần mà mỗi nhà đầu tư sở hữu. Nó cho phép người đặt cược tạo EigenPod mà Make một cam kết và rút khỏi nó. 
EigenPodĐã vượt quaretakedBalanceBiến theo dõi số dư của các trình xác thực khác nhau trên chuỗi báo hiệu. Bất cứ khi nào số dư của bất kỳ trình xác thực đặt lại nào thay đổi, bất kỳ ai cũng có thể xác minh nó bằng cách gọi verifyRestakedBalance()Chức năng cập nhật số dư của trình xác nhận cụ thể đó. Hàm này sẽ vượt qua BEACON_CHAIN_ORACLE mà chúng tôi nhận được từ Trạng thái đèn hiệu gốc để kiểm tra xem số dư cập nhật có chính xác không. 
Đây là cách EigenLayer triển khai việc đặt cược lại cục bộ. 
Tài liệu tham khảo
[1] Kế hoạch dịch liên kết: https://github.com/lbc-team/Pioneer
[2] Nhóm dịch: https://learnblockchain.cn/people/412
< span style="font-size: 14px;">[3]Gấu nhỏ: https://learnblockchain.cn/people/15
 < span style="font-size: 14px;">[4]learnblockchain.cn/article…: https://learnblockchain.cn/article/7657
[5] Chuỗi tóm tắt tài khoản: https://learnblockchain.cn/article/5426
[6]Noam Horowitz: https://twitter.com/ProbivelyNoam
[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_
< span style="font-size: 14px;">[11]Mã: https://github.com/Layr-Labs/eigenlayer-contracts/tree/master/src/contracts
[12]Hợp đồng: https://github.com/Layr-Labs/eigenlayer-contracts/tree/master/src / hợp đồng
[13]Bằng chứng công việc: https://en.wikipedia . org/wiki/Proof_of_work
[14] Bằng chứng xác thực: https:// en .wikipedia.org/wiki/Proof_of_authority
[15]Bằng chứng cổ phần: https ://en.wikipedia.org/wiki/Proof_of_stake
[16]Trắng giấy : https://docs.eigenlayer.xyz/overview/whitepaper
[ 17 ]Giải thích này: https://docs.prylabs.network/docs/concepts/nodes-networks
[18]EIP-4788: https://eips.ethereum.org/EIPS/eip-4788
< span style="font-size: 14px;">[19]DeCert.me: https://decert.me/