재설계 관점에서 아이겐 레이어 이해하기

출처: 덴체인 커뮤니티

이 블로그 게시물에서는 아이겐레이어 프로토콜의 진화 과정을 살펴보면서 아이겐레이어 아키텍처가 원래 개념에서 어떻게 등장했는지 설명해드리겠습니다.

이 블로그는 David Philipson의 계정 추상화 시리즈^[5]에서 영감을 받았습니다. 이 글에 대한 의견과 피드백을 제공해 주신 Noam Horowitz^[6], Shiva^[7], NashQ^[8], Mike Neuder^[9], Sina^[10] 커뮤니티에 특별히 감사의 말씀을 전합니다.

많은 사람들이 리스테이크와 아이겐 레이어라는 용어에 익숙하지만, 핵심 컨트랙트에 수천 줄의 코드^[11]가 포함되어 있으며 다음과 같이 설계되어 있다는 사실을 아는 사람은 극소수에 불과합니다.

EigenLayer 간소화된 아키텍처

단순해 보였던 아이디어가 어떻게 이렇게 복잡해졌을까요?

이 블로그 게시물에서는 프로토콜의 진화 과정을 설명함으로써 EigenLayer의 원래 개념에서 현재의 복잡한 아키텍처가 어떻게 등장하게 되었는지 살펴볼 것입니다.

이 글의 대상은 스마트 콘트랙트에 대한 기본적인 이해가 있고 아이겐레이어 또는 리스테이크에 대해 들어본 적이 있는 분들입니다.

이 블로그 게시물의 목적은 EigenLayer 설계의 진화에 대한 개괄적인 설명을 제공하는 것이므로 인터페이스, 변수 및 로직이 현재와 다를 수 있습니다. 아이겐레이어 핵심 컨트랙트^[12].

자, 이제 시작해보겠습니다.

최종 목표: 인프라 구축을 쉽게

먼저 EigenLayer가 해결하고자 하는 문제에 대한 소개부터 시작해 보겠습니다. 이 부분에 이미 익숙하다면 이후 섹션으로 건너뛰세요.

이더를 기반으로 탈중앙화 인프라를 구축하는 개발자는 자체적인 경제적 보안을 구축해야 하는 과제에 직면하게 됩니다. 이더는 스마트 컨트랙트 프로토콜에 경제적 보안을 제공하지만, 분산화된 노드 네트워크가 합의에 도달하기 위해서는 브리지나 시퀀서와 같은 인프라에 자체적인 경제적 보안이 필요합니다.

합의 메커니즘은 L1, 예측자 네트워크, 브리지 등 이러한 노드 간의 상호 작용을 촉진하는 데 매우 중요합니다.

작업증명[sup][13]은 전력 소모가 많고 권한증명[sup][14]은 지나치게 중앙화되어 있어 지분증명[sup][15](PoS)이 대부분의 인프라 프로젝트에서 주요 합의 메커니즘으로 자리 잡았습니다. 대부분의 인프라 프로젝트의 합의 메커니즘이 되었습니다.

그러나 새로운 지분 증명 네트워크를 시작하는 것은 어렵습니다.

우선, 플렛저(담보 제공자)가 어디에 있는지 파악하기 어렵습니다. 개발자가 담보 제공자를 찾을 수 있는 좋은 곳이 없습니다.

둘째, 새로운 네트워크에 대한 서약을 받으려면 보통 변동성이 크고 구하기 어려운 네트워크의 네이티브 토큰을 구입하는 방식으로 많은 돈을 투자해야 합니다.

셋째, 이더리움에서 제공하는 5% 보상과 같은 다른 보상 기회는 포기해야 합니다.

마지막으로, 현재 보안 모델은 가장 취약한 인프라 종속성을 깨는 데 드는 비용만 지불하면 되기 때문에 최적이 아닙니다.

현재로서는 인프라 프로젝트에 참여하는 플레저가 보안을 위해 오프라인 소프트웨어의 운영도 책임진다고 가정해 보겠습니다. 하지만 이 글의 뒷부분에서 이 가정을 변경할 것입니다.

EigenLayer는 이러한 문제를 해결하기 위해 만들어졌습니다:

• 이젠레이어는 담보 제공자와 인프라 개발자를 연결하는 플랫폼 역할을 합니다.

• 서약자는 경제적 보안을 제공하기 위해 모든 토큰을 사용할 수 있습니다.

• 서약자는 원래의 서약을 재설정하고 다른 인프라의 보안에 기여하는 동시에 기본 이더 보상을 받을 수 있습니다.

• 리플레깅을 통해 아이겐레이어는 보안을 분산(파편화)하지 않고 하나로 통합합니다.

EigenLayer의 백서 ^[16]에서 이러한 문제를 자세히 살펴봅니다.

EigenLayer는 경제적 보안 제공이라는 개념을 일반화합니다.

목표 1: 담보 제공자와 인프라 개발자를 연결하는 플랫폼 구축

EigenLayer는 담보 제공자가 모든 인프라 프로젝트에 담보 제공을 할 수 있는 플랫폼입니다. 아이겐레이어는 인프라 프로젝트를 아이겐레이어에서 잠재적 담보 제공자에게 홍보할 수 있는 플랫폼입니다. 이 플랫폼의 중추는 다양한 인프라에 대한 신뢰할 수 있는 약속을 할 수 있도록 하는 것입니다.

이러한 약속은 아이겐레이어뿐만 아니라 모든 지분 증명 시스템에 적용됩니다.L1 지분 증명자는 일반적으로 프로토콜의 규칙을 따르겠다고 약속하며, 동일한 블록 높이에서 상충되는 블록에 서명하면 서약을 잃을 위험이 있습니다.

인프라 개발자는 인프라 로직과 소프트웨어를 구축하고, 플레저는 인프라를 보호하기 위한 서약을 제공합니다. 이 서약은 인프라 사용자에 대한 약속으로 제공됩니다. 이 서약은 프로토콜의 원활한 운영과 특정 부정행위에 대한 방어를 위한 것입니다.

개념적으로, 프로젝트가 1억 달러의 서약금을 지원받는 경우, 이는 프로젝트가 약속에서 벗어나 악의적인 행동을 보일 경우, _ 해당 1억 달러 중 일부가 삭감된다는 것을 의미합니다. 간단히 말해, '삭감'은 자금을 파기하는 것으로 해석할 수 있습니다.

수치가 높을수록 사용자에게 더 많은 안전과 보안을 제공합니다.

서약자가 다양한 약속에 서약을 할당할 수 있도록 허용하면 그 위에 사용자 친화적인 플랫폼을 만들 수 있습니다.

다양한 서약자의 약속을 이행하기 위해서는 신뢰가 필요 없고 프로그래밍이 가능한 플랫폼이 필요하며, 이더는 이에 완벽하게 부합하는 플랫폼입니다. 또한 이더는 가장 큰 규모의 플레저를 보유하고 있어 플레저 시장을 도약시키는 데 도움이 됩니다.

여기서의 목표는 아이겐레이어를 통해 이더리움의 브리지 프로토콜에 보안을 제공할 수 있어야 한다는 것입니다. 위조된 메시지를 이더리움에서 악의적으로 위조하여 노시스에 전송하는 경우, 누구나 증거를 제출하고 해당 위조자를 차단할 수 있습니다.

서약과 약속 이행이 이더에서 이루어지기 때문에 컷 로직도 이더 스마트 컨트랙트로 구현됩니다. 서약자가 약속을 어기면 누구나 컷 컨트랙트에 증거를 제시하고 악의적인 서약자로부터 서약을 몰수할 수 있습니다.

이것은 아이겐 레이어의 기초를 형성하며, 모든 질권자는 모든 인프라 프로토콜에 대해 신뢰할 수 있는 약속을 할 수 있습니다.

이젠 레이어의 초기 설계

자, 이제 이를 구현해 보겠습니다. 가장 간단한 설계부터 시작하겠습니다. 질권자가 토큰을 컨트랙트에 예치하고, 증거가 제시되고 기준이 충족되면 질권자의 토큰을 삭감할 수 있는 기능이 포함된 컨트랙트에 토큰을 예치하는 것입니다. 그러면 사용자는 잔액을 인출할 수 있습니다.

다른 질권자들도 이 계약에 토큰을 질권하여 인프라의 보안을 강화할 수 있습니다. 이 컨트랙트를 <코드>TokenPool이라고 부릅니다.

이 문서에서 사용된 용어의 정의를 명확히 하기 위해 몇 가지 정의를 설명합니다:

• Pledging. 당사자: 아이겐레이어에 토큰을 제공하는 모든 사람.

• 토큰: 모든 유형의 토큰; 당분간은 ERC20 토큰으로 생각하시면 됩니다.

• TokenPool: 서약자의 토큰을 보관하는 스마트 컨트랙트입니다.

• 감축: 담보자의 토큰에 대한 접근 권한을 제거합니다.

이 TokenPool 인터페이스는 다음과 같이 표현할 수 있습니다:

계약 토큰풀 {
    매핑(주소 => uint256) 공개 잔액;
 & nbsp;  mapping(address => address[]) public slasher;

      function stake(uint256 amount) public;
     function withdraw() public;
      function enroll(주소 슬래셔) onlyOwner;
}

stake, withdraw, balance 함수와 변수 외에도 새로운 함수와 변수를 도입했습니다. 슬래셔 변수는 각 서약자에 대해 현재 등록된 AVS를 모니터링하고, 등록 함수는 서약자가 AVS에 참여할 수 있도록 합니다

따라서 AVS에 등록하면 실제로 '커터'에게 서약을 자르는 기능을 부여하는 것입니다. 서약을 삭감할 수 있습니다.

이 수정으로, 토큰풀에 서약한 후, 서약자는 enroll 함수를 호출하여 특정 AVS에 참여할 수 있으며, 여기에는 AVS별 커터 컨트랙트가 슬래셔에 포함되어 있습니다. 슬래셔 매핑.

여기의 등록 함수는 누구나 커터 컨트랙트에 등록할 수 있으므로 접근 제어가 적용됩니다. 이 토큰풀이 안전하게 관리되도록 하기 위해 당사는 신뢰할 수 있는 제3자가 관리한다고 가정합니다.

인출 과정에서 TokenPool 콘트랙트는 각 슬래셔에게 약정자가 인출할 수 있는 자격이 있는지 여부를 확인할 수 있습니다. 이는 슬래셔 컨트랙트의 is슬래셔 함수를 통해 확인할 수 있습니다. 이 담보자에 대해 isSlashed가 TRUE이면 담보자는 삭감되었으므로 담보물을 철회할 수 없습니다.

< 코드>컨트랙트 토큰풀 {
    mapping(address => uint256) public stakerBalance;
       &... nbsp;mapping(address =  uint256) public operatorBalance;
  mapping(address =  address) public delegation;
    mapping(address =  address) public delegation;
    ... nbsp;mapping(address => address[]) public slasher;

      function stake(uint256 amount) public;
    function withdraw() public;
      function delegateTo(주소 연산자) public;
    function enroll(주소 슬래셔) operatorOnly;
     function exit(주소 슬래셔) operatorOnly;
}

우리는 다음과 같이 나누었습니다. Balance 변수를 연산자용과 서약용의 두 부분으로 나누었습니다. 또한 위임자와 운영자 간의 위임 관계를 기록하기 위해 <코드>위임 매핑을 도입했습니다.

또한 슬래셔 매핑을 약간 변경했습니다. 이제 슬래셔 컨트랙트에 질권자 대신 운영자의 권한을 줄일 수 있는 권한을 부여합니다.

컨트랙트 토큰풀 {
    mapping(address => uint256) public stakerBalance;

    function stake(uint256 amount ) public;
     함수 withdraw() public;
}

TokenPool 컨트랙트는 다음을 수행합니다. 각 위임자의 잔액만 추적합니다.AVS 추적 및 참여는 DelegationManager가 처리합니다.

 계약 슬래셔 {
    매핑 (주소 => bool) isSlashed;

    함수 슬래시(주소 연산자, ??????. proof);

}

컨트랙트 구조를 정리하고 각 구성 요소를 모듈화한 후 아키텍처는 이제 다음과 같습니다:

이겐레이어 중간 설계: 오퍼레이터 역할과 플리지 역할을 분리한 후입니다.

목표: 더 많은 토큰을 지원

지금까지, 토큰을 단일로 유지하는 설계를 개발했는데, 이는 트랜잭션에 대해 하나의 토큰만 유지하기 때문입니다. 하나 매핑을 유지합니다.

LP 지분을 기반으로 하는 모델을 채택하고 토큰별 TokenPools를 생성하여 이 문제를 해결할 수 있습니다.

이를 위해 TokenManager라는 새로운 컨트랙트를 생성할 것입니다. TokenManager가 토큰을 서약하고 인출하는 곳이 될 것입니다.

TokenManager 아래에 각 토큰에는 TokenPool이 있습니다. TokenManager는 모든 토큰의 장부 센터 역할을 하며, 토큰 자체를 저장하지는 않습니다. 각 <코드>TokenPool는 자체적으로 해당 토큰을 보유합니다.

이 새로운 구성 요소는 이제 약정자의 다양한 토큰을 다른 토큰을 추적하도록 설계된 새로운 구성 요소입니다.

사용자가 토큰을 서약하면 TokenManager가 이를 처리합니다. 그런 다음 TokenManager가 해당 토큰과 연결된 해당 TokenPool의 stake 함수를 호출합니다. 사용자의 토큰이 <코드>TokenPool로 전송됩니다. 함수가 끝나면 총공유량과 스태커풀공유량이 새로운 서약을 반영하도록 업데이트됩니다. 총주식수는 토큰풀이 발행한 총 주식 수를 추적하고, 스태커풀주식수는 각 토큰풀>에서 각 개별 지분보유자가 보유한 주식 수를 기록합니다.

각 컨트랙트에 대한 인터페이스는 다음과 같습니다:

계약 위임 관리자 {
    // ... 
    mapping(address => mapping(address => uint256)) operatorPoolShares;
    // ... 
}

이제, 동일한 핵심 아키텍처를 사용하여 다른 AVS를 보호하기 위해 모든 토큰을 아이겐 레이어에 예치할 수 있습니다.

목표: AVS 설계 확장

다음 시나리오를 고려해보세요: 다른 사람이 자신의 자산을 삭감하기 전에 즉시 자신의 서약을 철회하는 경우. 자산을 삭감합니다.

_예를 들어_, AVS에서 악의적인 행동을 하는 운영자이자 담보자인 운영자가 있다고 가정해 보겠습니다. 이 오퍼레이터는 다른 사람이 체인을 절단하기 전에 아이겐 레이어 컨트랙트에서 자신의 서약을 철회합니다. 이는 철회 시점에 <코드>슬래셔가 자산을 자르기 위해 업데이트되지 않았기 때문에 가능합니다. 결과적으로 AVS는 더 이상 절단할 수 있는 토큰이 없기 때문에 더 이상 악의적인 운영자/서약 보유자를 절단할 수 없습니다.

악성 운영자/서약자에 대한 잠재적 이벤트 타임라인.

따라서 "안전한" AVS는 이벤트가 발생한 동일한 블록에서 악의적인 오퍼레이터를 동결하는 컨트랙트 감소가 필요합니다. 이러한 제한은 AVS의 설계를 크게 제한하며 대부분의 AVS를 안전하지 않게 만듭니다.

한 가지 해결책은 구속 해제 기간을 도입하는 것입니다. 언바인딩 기간이라고 하는 인출 절차에 딜레이를 도입하는 것입니다. 그 이후에는 기존과 동일하게 철회할 수 있습니다.

약정자가 시스템에서 출금하기로 결정하면 해당 요청은 대기열에 들어갑니다. 이 대기열에 있는 출금은 운영자의 가장 긴 묶음 해제 기간 이 만료된 후에만 처리됩니다. 이는 운영자가 여러 개의 AVS를 관리할 수 있지만, 약정자의 출금은 하나의 번들 해제 기간에만 맞춰질 수 있기 때문입니다. 보안상의 이유로 시스템에서는 언번들 기간을 가장 긴 기간으로 설정합니다.

예를 들어, 언번들링 기간이 6일, 5일, 7일인 3개의 AVS에 참여하는 운영자에게 서약을 위임한 경우, EigenLayer에서 탈퇴를 요청한 후 7일을 기다려야 서약에 액세스할 수 있습니다. 이는 7일이 세 가지 기간 중 가장 긴 기간이기 때문입니다.

7일 기간이 끝나면 서약자는 자신의 서약을 철회할 수 있습니다. 단, 이 기간 동안 위임받은 운영자가 삭감된 경우 보류 중인 출금도 중지됩니다.

이 변경 사항을 도입하려면 DelegationManager가 각 운영자의 번들 해제 기간을 추적하고 운영자가 새 AVS에 추가될 때 이를 업데이트해야 합니다.

계약 TokenManager {
 mapping(address => address) public tokenPoolRegistry;
 mapping(address => mapping(address => uint256)) public stakerPoolShares;< br> mapping(address => uint256) public withdrawalCompleteTime;

 function stakeToPool(address pool, uint256 amount) public;
 function queueWithdrawal(주소 풀) public;
 function completeWithdrawal(주소 풀) public;
}

약정자가 출금을 대기하는 동안 TokenManager는 약정자가 위임한 연산자가 슬래시되지 않았는지 DelegationManager로 확인합니다. 연산자가 슬래시되지 않았다면, TokenManager가 DelegationManager의 언본딩 기간와 현재 시간을 기준으로 위임자의 withdrawalCompleteTime를 업데이트합니다.

기간을 언본딩한 후, 약정자는 completeWithdrawal로 인출을 완료할 수 있습니다. 이 함수는 출금 완료 시간이 만료되었는지 확인합니다. 만료된 경우, 이전 절차에 따라 서약자의 토큰이 전송됩니다.

이 프로세스의 설계는 복잡하며 여러 번의 반복을 거쳤습니다. 이 주제에 대한 별도의 글을 작성할 수도 있습니다! 현재 저희는 시간 추적 시스템을 사용하여 이 번들 해제 추적을 구현하고 있습니다. 이 부분은 아직 진행 중인 작업입니다!

모듈식 슬래셔

슬래시 메커니즘을 더욱 안전하게 만들고 있는 만큼, 더 모듈적이고 효율적으로 만들도록 노력해 봅시다.

현재, 추출 과정에서 TokenManager는 연산자가 슬래시되었는지 확인하기 위해 각 개별 슬래셔를 확인해야 합니다.이러한 작업은 담보자의 가스 오버헤드를 추가할 수 있습니다. 가스 오버헤드가 추가될 수 있으며 소규모 담보자의 보상이 크게 줄어들 수 있습니다.

또한, AVS 개발자가 슬래셔를 설계하는 경우가 많으므로 이 특정 구성 요소를 모듈화하면 개별 AVS의 개발 프로세스를 간소화할 수 있습니다.

TokenManager와 유사하게 슬래시 메커니즘을 두 부분으로 설계할 것입니다. SlasherManager가 각 연산자의 상태를 유지합니다. 별도의 <코드>슬래셔가 각 AVS에 대한 슬래시 로직을 처리합니다.

슬래시 컨트랙트를 더욱 모듈화하여 스테이저의 가스 비용을 절감합니다. 슬래시 계약을 더욱 모듈화하여 질권자의 가스 비용을 절감합니다.

 계약 슬래셔 {
    함수 슬래시(주소 연산자, ?????) 공개;
}

슬래셔는 AVS 전용이며, AVS 개발자가 개발할 가능성이 높습니다. SlasherManager와 상호 작용하여 다른 운영자의 상태를 업데이트합니다.

EigenLayer가 설계되었습니다!

요약: EigenLayer의 목표는 인프라 구축을 간소화하는 것입니다. 저희는 네 가지 주요 목표를 가지고 시작했습니다.

1. 플레저와 인프라 개발자를 연결하는 플랫폼을 구축합니다.

2. 서약자가 모든 토큰을 사용하여 경제적 보안을 제공할 수 있도록 허용합니다.

3. 서약자가 다른 인프라에 보안을 제공하면서 자신의 서약을 재서약하고 기본 이더리움 보상을 받을 수 있도록 합니다.

4. 탈중앙화 대신 리플레징을 통해 보안을 강화합니다.

여러 차례의 반복 끝에 세 가지 핵심 구성 요소인 TokenManager, DelegationManager, SecurityManager가 개발되었습니다. 코드>, 그리고 <코드>SlasherManager입니다. 각 구성 요소에는 특정 기능이 있습니다.

이겐 레이어의 단순화된 아키텍처 아이겐 레이어의 단순화된 아키텍처

• TokenManager: 서약자의 서약과 출금을 처리합니다.

• DelegationManager: 운영자 등록 및 운영자 지분 추적을 허용합니다.

• SlasherManager: AVS 개발자가 슬래시 로직을 결정할 수 있는 인터페이스를 제공합니다.

이러한 핵심 구성 요소는 시스템 전체에서 보안을 보장하기 위해 서로 통신하기도 합니다.

이러한 핵심 컨트랙트 외에도 전체 스택을 강화하는 다른 많은 기능과 컨트랙트가 있습니다. 이러한 추가 기능은 다양한 AVS 설계를 지원하고, 오프라인 기술 복잡성을 간소화하며, 사용자와 운영자의 가스 비용을 절감합니다.

이러한 추가 기능에 대해 자세히 알아보려면 오픈 소스 코드 리포지토리(https://github.com/Layr-Labs/eigenlayer-contracts)를 방문하세요

추가 기능 1: 누가 누구를 신뢰하나요?

시스템이 모듈식인 경우 프로토콜 참여자 간의 신뢰 가정을 추적하는 것은 어려울 수 있습니다. 따라서 프로토콜에 참여하는 참여자 간의 신뢰 가정을 명확하게 설명하는 것이 중요합니다.

이겐 레이어에는 세 가지 주요 주체가 있습니다: 서약자, 운영자, AVS 개발자입니다.

운영자는 클라이언트 소프트웨어와 온체인 슬래시 조건을 정확하게 작성하기 위해 AVS 개발자에게 의존합니다. AVS 소프트웨어에 버그가 있는 경우, 기껏해야 운영자는 잠재적인 수수료 지급을 놓칠 수 있습니다. 최악의 경우, 운영자는 결과적으로 슬래시에 의해 전액 손실될 수 있습니다.

위태로운 가치의 중요성을 고려할 때 전체 시스템이 가동되기 전에 보조 보조 바퀴가 있는지 확인하는 것이 중요합니다.

거부권 위원회는 이러한 보조 바퀴 역할을 합니다. 거부권 위원회는 악의적이지 않은 행동으로 인한 삭감을 취소할 수 있는 권한을 가지며, 서약자, 운영자, AVS 개발자 간의 상호 신뢰 당사자입니다.

그러면 AVS 개발자에 대한 신뢰 가정을 제거할 수 있습니다. AVS에 소프트웨어 버그가 있더라도 약정자와 운영자는 불이익을 받지 않습니다.

원장은 자신이 위임한 운영자를 신뢰합니다. 운영자가 잘못 행동할 경우, 위탁자는 잠재적인 수수료 지급을 놓치거나 위탁금 전체를 잃을 수도 있습니다. 이러한 신뢰 가정은 코인 서약 및 기타 서약 서비스와 같은 기존 검증 서비스와 동일합니다.

AVS 개발자는 운영자가 정직하게 운영할 것을 신뢰합니다. 운영자가 정직하지 않으면 AVS 서비스가 크게 저하되어 고객 이탈 및 기타 결과를 초래할 수 있습니다.

참여자들 사이에서 거부권 위원회를 통해 신뢰 가정은 다음과 같습니다:

• Pledgator. 운영자가 정직하게 행동할 것을 신뢰하고, 잘못된 행동은 슬래시로 이어질 수 있습니다.

• AVS 개발자는 운영자가 AVS 소프트웨어에 대해 정직하게 행동할 것을 신뢰합니다.

.

• 서약 보유자, 운영자 및 AVS 개발자는 슬래시를 취소하기 위해 거부권 위원회를 신뢰합니다.

보너스 2: 네이티브 리스테이크

지금까지는 LST를 사용한 리플레깅에 대해 설명했습니다. 그러나 플로우 플레지 프로토콜을 통해 아이겐 레이어를 플레지하고 싶지 않다면 네이티브 리플레지를 통해 아이겐 레이어에 참여할 수 있습니다.

네이티브 리플레지를 정의하자면, 검증자 내부의 이더를 사용해 추가 플레지를 하는 과정입니다. 검증자가 서약에서 벗어나면 검증자 내부에 보유한 이더를 잃게 됩니다.

문제는 이러한 검증자 내부의 이더가 ERC20 토큰의 형태로 표시되지 않는다는 것입니다. 대신, 이더리움은 비콘 체인에 존재합니다. 실행 레이어나 합의 레이어(비콘 체인)에 익숙하지 않으시다면 이 설명 ^[17]을 참고하시면 도움이 될 것입니다.

이 문제를 해결하기 위해 EigenPod를 사용해 이더리움 검증자 잔액을 추적하고 필요한 경우 이를 삭감할 수 있습니다.

EigenPod는 가상 장부 시스템 역할을 합니다. EigenPod로 각 합의 검증자의 이더 잔액을 모니터링할 수 있습니다.

상위 레벨에서 EigenPod는 검증자의 추출 프로세스를 처리합니다. 검증자가 아이겐 레이어에서 자신의 서약을 추출하면, ETH 퍼스트가 EigenPod를 통과하여 검증자의 슬래시 여부를 확인하고, 검증자가 슬래시된 경우 토큰은 EigenPod 컨트랙트 내에서 동결될 것입니다. 강력한>동결되어 효과적으로 슬래시됩니다.

이겐포드 구현하기

이더 검증자 잔액이 비콘 체인에 저장되어 있고 이겐포드를 구현하는 것은 까다로운 작업입니다. 실행 레이어에서 비콘 체인 데이터에 액세스할 수 없기 때문입니다.

이 문제를 해결하기 위해 술어를 사용하여 비콘 체인 상태 루트를 실행 레이어에 전달합니다. 비콘 상태 루트를 얻으면 해당 머클 증명을 제공하여 검증자의 잔액에 접근할 수 있습니다.

EIP-4788^[18]을 구현하면 이 술어 머신을 제거하고 실행 레이어에서 직접 비콘 루트를 쿼리할 수 있습니다.

부기 시스템을 캡슐화하기 위해 TokenPool 및 TokenManager 모델과 유사한 패턴을 사용하여 로컬 대체 시스템을 모듈화할 것입니다. . 각 EigenPod는 하나의 검증자에 대한 출금 프로세스를 처리합니다. 이겐포드매니저는 다른 핵심 컨트랙트와 협력하여 각 운영자와 질권자가 리플지한 이더리움의 양을 추적합니다.

<span ) 10px 10px / 40px no-repeat ;height: 30px;width: 100%;margin-bottom : -7px;테두리-반경: 5px;'contract EigenPodManager{
    mapping(address => ; uint256) public restakerShares;

    function createEigenPod(주소 소유자) public;
    function stakeToPod( address pod, uint256 amount) public;
    function withdrawFromPod(address pod) public;
}
contract EigenPod{
        . 주소 BEACON_CHAIN_ORACLE;
       주소 podOwner;
     uint256 restakedAmount;

     함수 stake(uint256 amount) public;
      function verifyRestakedBalance(uint256 amount, MerkleProof proof) public;
     function withdraw() public;
}

는 각 질권자가 소유한 주식 수를 추적합니다. 이를 통해 공탁자는 EigenPod를 생성하고, 공탁하고, 인출할 수 있습니다.

EigenPodbyby restakedBalance비콘 체인에서 개별 검증자의 잔액을 추적하는 변수입니다. 회신된 검증자의 잔액이 변경될 때마다 누구나verifyRestakedBalance()함수를 호출하여 특정 검증자의 잔액을 업데이트할 수 있습니다. 이 함수는 BEACON_CHAIN_ORACLE에서 가져온 비콘 상태 루트를 통해 업데이트된 잔액이 올바른지 확인합니다. 가 올바른지 확인합니다.

이것이 아이겐레이어가 로컬 트랜잭션을 구현하는 방식입니다.

참고자료

[1]Dengchain 번역 프로젝트: https:// github.com/lbc-team/Pioneer

[2]번역팀: https://learnblockchain.cn/ people/412

[3]Tiny Bears: https://learnblockchain.cn/people/15< /p>

[4]learnblockchain.co.uk/article...: https://learnblockchain.cn/ article/7657

[5]계정 요약 시리즈: https://learnblockchain.cn/article/5426

[6]노암 호로위츠: https://twitter.com/ProbablyNoam

[7]시바: https://twitter.com/ShivanshuMadan

[8]내쉬큐: https://twitter.com/NashQueue

[9]마이크 노이더: https://twitter.com/mikeneuder

[10]마이크 노이더: https://twitter.com/mikeneuder

[10] 시나: https://twitter.com/sina_eth_

[11] 코드: https://github.com/ 레이어-랩스/이겐레이어-계약/트리/master/src/계약

[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/