이더리움 Beacon deposit contract 이해하기

진행상황

date

Oct 31, 2024

slug

ethereum-network-4

author

status

Public

DepositContract

etherscan.io

https://etherscan.io/address/0x00000000219ab540356cBB839Cbe05303d7705Fa#code

contract review

컨트랙트 제한사항

DEPOSIT_CONTRACT_TREE_DEPTH = 32로 설정

MAX_DEPOSIT_COUNT = 2^32 - 1 까지만 가능

핵심 코드


  event DepositEvent(
      bytes pubkey,
      bytes withdrawal_credentials,
      bytes amount,
      bytes signature,
      bytes index
  );

function deposit(
    bytes calldata pubkey,
    bytes calldata withdrawal_credentials,
    bytes calldata signature,
    bytes32 deposit_data_root
) override external payable {}


  bytes memory amount = to_little_endian_64(uint64(deposit_amount));
  emit DepositEvent(
      pubkey,
      withdrawal_credentials,
      amount,
      signature,
      to_little_endian_64(uint64(deposit_count))
  );

컨트랙트가 ETH를 잠그는 방식은:

컨트랙트 구조:

입금 함수만 존재하고 직접적인 출금 함수는 없음

비콘체인의 합의를 통해서만 출금이 가능

단방향 브릿지

입출금 제어:

deposit() 함수로만 입금 가능

출금은 비콘체인의 exit 메시지를 통해서만 가능

컨트랙트 자체에는 출금 로직이 없어 완전히 비콘체인에 의존

검증자 등록:

32 ETH 입금시 자동으로 검증자 등록 절차 시작

deposit_data (공개키, 서명 등) 필요

비콘체인에서 이 정보를 기반으로 검증자 활성화

Validator Staking 관련 문서

Ethereum staking | ethereum.org

An overview of Ethereum staking: the risks, rewards, requirements, and where to do it.

https://ethereum.org/en/staking/#comparison-of-options

Withdrawal

Staking withdrawals | ethereum.org

Page summarizing what staking push withdrawals are, how they work, and what stakers need to do to get their rewards

https://ethereum.org/en/staking/withdrawals/

출금 프로세스

출금 프로세스:

비콘체인에서 validator exit 요청시 withdrawals queue에 들어감

검증자의 balance와 exit 정보는 비콘체인의 상태에 기록됨

비콘체인 블록에 withdrawal 정보가 포함되면 실행레이어로 전달

출금 실행:

실행레이어의 블록 생성자가 비콘체인의 withdrawal 정보를 받음

이 정보를 기반으로 system-level operation으로 ETH 전송을 실행

별도의 스마트 컨트랙트를 통하지 않고 블록 생성 과정에서 처리됨

핵심 포인트:

디파짓 컨트랙트는 일방향 (입금만 가능)

출금은 비콘체인의 합의를 통해 실행레이어에서 직접 처리

이건 EVM 내부가 아닌 프로토콜 레벨에서 이뤄지는 작업

exit 후 이더를 돌려받는 과정:

Exit 과정:

먼저 validator가 voluntary exit 요청을 비콘체인에 전송

exit queue에 들어가고 순차적으로 처리

exit이 완료되면 validator는 fully withdrawn 상태가 됨

Withdrawal 과정 동작 방식:

withdrawal_credentials 에 설정된 주소로 ETH가 전송

이 주소는 validator 등록할때 디파짓 컨트랙트에 제출한 값

0x01 으로 시작하는 withdrawal credential은 실행층 주소를 의미

실제 ETH 이동:

비콘체인에서 exit 완료된 validator 정보를 실행층에 전달

블록 생성자가 블록에 withdrawal 작업을 포함

시스템 레벨 operation으로 설정된 주소로 ETH 전송

요약:

디파짓할때 설정한 withdrawal 주소로

비콘체인이 exit 승인하면

실행층 블록 생성자가 그 주소로 ETH를 보내줌

💡

실행층 블록 생성자가 그 주소로 ETH를 보내주는게 이해가 안가는데 그 생성자가 32ETH를 보내줄리가 없을텐데

0x00000000219ab540356cBB839Cbe05303d7705Fa 여기에 다 쌓이고 있기 때문

디파짓 컨트랙트의 ETH는 그대로 있고:

블록 생성자가 withdrawal operation을 실행할 때

디파짓 컨트랙트의 잔액에서 차감되어

withdrawal_credentials 주소로 전송됨

이 과정이 가능한 이유:

블록 생성자는 프로토콜 레벨에서 특별한 권한을 가짐

EVM 내부가 아닌 프로토콜 레벨의 operation으로 실행

비콘체인의 합의를 통해 검증된 withdrawal 정보만 처리

실제 트랜잭션 형태:

일반적인 EOA나 컨트랙트간 전송이 아님

블록 헤더에 withdrawals 필드로 포함

프로토콜에 의해 강제되는 상태 변경

즉 블록 생성자가 자신의 ETH로 보내는게 아니라 프로토콜 레벨에서 deposit contract의 잔액을 withdrawal 주소로 이동시키는 것

Q&A

어떻게 실행레이어의 블록 생성자가 비콘체인의 withdrawal 정보를 받는지

실행레이어의 블록 생성자가 비콘체인의 withdrawal 정보를 받는 방식:

실행 클라이언트와 컨센서스 클라이언트는 Engine API로 통신
컨센서스 클라이언트가 withdrawals 정보를 Engine API를 통해 전달
실행 클라이언트는 이 정보를 받아서 블록 생성시 포함

어떻게 디파짓된 ETH는 합의 레이어에서 검증자로 참여할 수 있는 자격을 가졌는지 검증하는 지

검증자 자격 검증 방식

deposit() 함수 호출시 필요한 정보:

pubkey: 검증자의 공개키 ( BLS ? )
withdrawal_credentials: 출금 주소 정보
signature: 서명
deposit_data_root: 위 데이터의 해시값

검증 과정:

디파짓 컨트랙트가 deposit_data_root로 데이터 무결성 검증
비콘체인이 DepositEvent를 감지하고 validator pool에 추가
32 ETH가 맞는지 확인

validator가 되기 위한 상세한 준비과정

validator 키페어 생성 (deposit keys & signing keys)
deposit-cli로 deposit data 생성
32 ETH와 함께 deposit data를 디파짓 컨트랙트에 전송
validator 클라이언트에 signing keys 등록
활성화 대기 (현재 약 7일 정도 소요)