이더리움 밸리데이터 키, 리워드와 패널티 추적하기

Published in

A41 Tech Blog

23 min read2 days ago

A41의 이더리움 인프라 전환 기술 포스트는 총 5편으로 구성되어 있습니다. 각 글은 빠르게 증가하는 이더리움 검증인의 수에 대응하며 2024년 상반기에 A41이 마주한 문제들과 이를 해결한 전략들에 대해 소개합니다.

Author: Zoe

확장 가능한 블록체인 인프라를 위한 A41 테크팀의 고민과 선택들에 대한 기술 포스트 목록입니다. 다른 편을 읽고 싶으시다면 아래의 리스트를 확인해주세요.

Intro

A41은 2024년 7월 기준 $2.2 billion 의 stake된 자산을 관리하는 블록체인 인프라 기업입니다. 이더리움의 경우 현재 총 스테이킹된 이더리움의 1.5%를 관리하고 있으며 A41은 Lido, Mantle, EtherFi 등의 다양한 LSP 와 협업하여 16,000 여개의 Validator Key를 관리하고 있습니다.

앞선 시리즈 글을 통해서 A41이 전문 밸리데이터로서 확장 가능한 인프라, 안전한 배포 시스템, 내부 모니터링과 외부 모니터링에 대해 알아보았습니다. 그렇다면 전문 밸리데이터로서 노드 오퍼레이션 및 키 관리 업무를 수행하고 얻게 되는 수익에 대해서는 어떻게 추적 할 수 있을까요? 수익에 대한 청구 기준으로 사용될 수 있는 자료를 만들기 위해서 밸리데이터의 리워드가 패널티가 발생하는 이벤트들의 종류와 이벤트들이 발생할 수 있는 구간에 대해 이해하고 수익에 대한 기준과 근거를 마련해야 합니다.

이번 글에서는 밸리데이터 키들이 어떤 경우에 리워드와 패널티를 얻게 되는지 알아보고, 수익을 집계하기 위해 어떻게 보상과 패널티에 대한 정보를 얻어 올 수 있는지, 그리고 빠짐없이 리워드와 패널티를 얻기 위해 탐색 구간을 어떻게 설정할지 고민한 과정들을 알아보겠습니다. 그리고 최종적으로 수익을 측정하는데 사용된 기준과 방식에 대해 공유하고자 합니다.

Validator Key?

이더리움에서 검증인이 되기 위해서는 Signing key(Validator key)와 Withdrawal key, 두 가지 타입의 키가 필요합니다. Signing key는 일반적으로 밸리데이터 키라고 하며, 이를 이용해 합의 과정에서 여러 가지 의무를 수행합니다. Withdrawal key는 Signing key가 활성화되는 데 필요한 자금에 대한 권한을 가지고 있습니다. 그렇다면, 수익을 측정하기 위해서는 Signing key의 활동만 추적하면 될까요? 결론부터 말하자면, Withdrawal key도 수익 측정에 주요한 역할을 합니다. (두 키의 자세한 관계와 스펙이 궁금하시다면 EIP-2333과 EIP-2334를 참고해보세요.)

먼저, 밸리데이터 키의 관점에서 의무를 수행하고 얻게되는 수익을 추적해보겠습니다. 밸리데이터 키의 수익 활동을 탐색하기 위한 구간을 설정하기 위해 키의 생애 주기(Lifecycle)를 개략적으로 살펴보겠습니다. 밸리데이터 키는 크게 다음 4가지 상태로 분류됩니다. 밸리데이터 키 상태의 세부 스펙은 이 문서에서 확인할 수 있습니다.

Pending — 32 ETH 예치 후 Active Validator Queue에 추가되어 Active되기를 기다리는 상태입니다.
Active — Validator로써 활성화되며 검증인으로서의 의무를 수행하고 리워드와 패널티를 받는 상태입니다.
Exited — 더 이상 검증인으로서 의무를 수행하지 않는 상태입니다.
Withdrawal — Exited 된 후 자금을 옮길 수 있는 상태입니다.

실행 계층에서의 32 ETH Deposit을 시작으로 밸리데이터 키가 Active될 때까지 잠시 Pending 상태가 됩니다. 주로 Active 상태와 Exited 상태 사이에서 보상과 패널티가 발생하며, 최종 자금 회수는 Withdrawal 상태에서 진행할 수 있습니다.

Deposit

Ethereum은 실행 계층과 합의 계층으로 나뉘어져 있습니다. 합의 계층의 밸리데이터 키를 활성화하기 위해서는 실행 계층에서 deposit contract의 deposit 함수를 32 ETH와 함께 트랜잭션을 실행해야 합니다. 실행 계층에서 수행한 정보를 어떻게 합의 계층에서 반영할 수 있을까요? 그리고 합의 계층에서 활성화 상태로 전환되는 시점은 언제일까요?

실행 계층의 정보를 합의 계층에 반영하는 방식은 크게 두가지가 있습니다.

하나는 특정 블록 높이에서 deposit contract state에 대해 합의하는 투표 프로세스입니다. 32 ETH를 가진 계정으로 deposit transaction을 실행 레이어에서 수행하고 나면, Beacon Chain에서는 state.eth1_data를 ETH1_FOLLOW_DISTANCE Eth1 blocks (~8 hours)에 EPOCHS_PER_ETH1_VOTING_PERIOD epochs (~6.8 hours)을 더한 시간이 지난 후 포함하게 됩니다. data가 추가되고 나면 state.validators에 추가되는 과정이 1~2 Epoch안에 시작됩니다. consensus-specs의 deposit 부분을 참고하시면 보다 자세한 과정을 알 수 있습니다.

다른 하나의 방법은 Eth1 클라이언트와 통신하여 deposit contract의 deposit event를 수신하고 receipts를 직접 가져오는 방식입니다.

위 두 방식 이외에도 합의 계층의 입금 처리 워크플로우 개선이 EIP-6110에서 진행되고 있습니다.

정확하게 활성화되는 시점은 beacon API의 getStateValidators 의 호출 후 응답값으로 activation_epoch 을 통해얻을 수 있습니다. 따라서 Deposit 이 발생한 후 Epoch단위로 getStateValidators 를 주기적으로 호출하여 밸리데이터 키 상태를 업데이트 해주는 과정이 필요합니다.

Validator Duties & Reward

밸리데이터 키가 Active되면, 합의 계층에서 다음 주요 의무 3가지를 수행해야 합니다.

합의 프로토콜의 일부로서 체인에 대한 견해를 증명을 발행합니다.
블록을 제안합니다.
라이트 클라이언트를 지원하는 Sync commitee에 참여하여 블록에 서명합니다.

주요 의무를 잘 이행한 경우 리워드을 제공하고 반대로 잘 이행하지 못한 경우 패널티를 부여합니다. 주요 의무와 리워드에 대해서 살펴보고 수익을 어떻게 집계할 수 있을지 살펴보겠습니다. 본격적으로 수익을 측정하기 전에 리워드를 측정하는데 자주 사용되는 주요 용어들에 대해서 살펴보겠습니다.

Base Reward, Effective Balance, Base Reward per Increment

Base Reward는 장기적으로 최적의 성능을 발휘하는 검증자가 Epoch마다 얻을 수 있는 평균 예상 수익입니다.

def get_base_reward(state: BeaconState, index: ValidatorIndex) -> Gwei:
    """
    Return the base reward for the validator defined by ``index`` with respect to the current ``state``.
    """
    increments = state.validators[index].effective_balance // EFFECTIVE_BALANCE_INCREMENT
    return Gwei(increments * get_base_reward_per_increment(state))

Base Reward을 계산하기 위한 공식은 다음과 같습니다

Effective Balance는 프로토콜 전반에 걸쳐 보상 수식에 사용되는 값입니다. 쉽게 말하자면 32 ETH입니다. 이 값은 검증자의 실제 잔액을 추적하는데 쓰이는데 MAX_EFFECTIVE_BALANCE인 32 ETH를 넘을 수 없으며, Gwei 단위 대신 EFFECTIVE_BALANCE_INCREMENT라는 1ETH 단위로 Increment라는 개념을 사용합니다. 따라서 현재 검증자는 최대 32개의 Increment를 보유할 수 있습니다. Increment라는 불연속적인 값을 사용하여 Effective Balance이 빈번하게 업데이트 되지 않도록하여 검증자 기록의 해시 트리루트를 너무 자주 재계산하지 않도록 합니다.
G는 상수로, 현재는 64로 설정되어 있습니다.
Base Reward Per Increment는 보상의 기본 단위가 됩니다. 자세한 내용은 다음에 이어서 설명드리겠습니다.

Base Reward Per Increment

보상은 검증자들이 네트워크에 기여한 바에 따라 계산되며, Base Reward Per Increment는 Eth2에 참여하여 얻는 총 보상(새 이더의 발행률)을 증가시키거나 감소시키고자 할 때 조절할 수 있는 주요 요소입니다.

def get_base_reward_per_increment(state: BeaconState) -> Gwei:
    return Gwei(EFFECTIVE_BALANCE_INCREMENT * BASE_REWARD_FACTOR // integer_squareroot(get_total_active_balance(state)))

Base Reward Factor는 64로 고정된 값입니다.
Total Balances는 네트워크에 있는 모든 검증자의 총 잔액입니다.

예시

검증인이 320,000만큼 존재한다면 Base Reward Per Increment는 다음과 같이 계산해 볼 수 있습니다.

Incentive weight

네트워크 수익에서 밸리데이터의 리워드의 비중을 따라 리워드가 분배되게 됩니다. Attestaion(Head, Source, Target)에 대한 리워드, Sync commitee에 참여한 경우 받게 되는 리워드와 블록 제안에 따른 제안자 리워드 있습니다. 또한 Slashing 규칙 위반을 보고한 Proposer는 추가 보상이 있습니다. 이 내용은 Slashing에서 같이 이야기 하겠습니다. 인센티브 가중치는 다음과 그림과 같습니다.

리워드와 관련된 기호는 다음과 같이 정의합니다.

전체 네트워크 수익에 인센티브 비중을 적용해보면 다음과 같습니다.

T: 모든 active validator set의 increment입니다. 매우 큰 수입니다.
b: base reward per increment

위 값들을 전체 검증자가 나누어 가지게 됩니다. 이제 각 리워드와 패널티를 얻게되는 규칙에 대해 본격적으로 살펴보겠습니다.

Attestation reward

합의 계층에서 Source, Target, Head 값에 대해서 투표하고 정확하고 빠르게 투표한 경우 다음 규측을 통해 리워드를 획득하게 됩니다. Head Vote에 대한 패널티는 없으며, Source와 Target은 존재합니다.

Source는 5 slot이내 attestaion이 제출되지 않으면 패널티를 받습니다. 패널티까지 포함한 attestation 최종 가중치는 다음과 같습니다.

최근 Dencun 업그레이드를 통해 EIP-7045가 적용됨에 따라 Target에 대한 늦은 제출에 대한 패널티는 사라졌습니다. 다음 Epoch의 마지막 Slot까지 attestaion을 제출한다면 패널티를 받지 않습니다.

하지만, 모든 attestation을 잘 제출했다고 할지라도 attester는 보상을 받는 것에 대해서 완전히 컨트롤 할 수 없습니다. 제안자가 오프라인되면서 다음 블록을 skip 할 수도 있고, 그럼으로써 head block reward를 받지 못할 수도 있습니다. 또는 다음 제안자가 소수 포크에 속해있을 경우 attester의 리워드가 없어질 수 있습니다. 또는 블록 제안자의 블록이 늦거나 고아 포크가 될 수도 있습니다. 따라서 Attestation 리워드는 제안자에 의존적인 상황을 함께 고려해야 합니다. 따라서 최종적으로 Epoch 확정된 후 집계하는 것이 필요합니다.

Sync committee rewards

네트워크의 현재 최종 상태를 나타내는 최신 블록(Head)에 서명하여 라이트 클라이언트가 네트워크 상태를 빠르게 파악할 수 있도록 돕는 역할을 합니다. 매 256 epoch마다 512 검증인들이 sync committee에 선택되며, 확률적으로 매우 낮습니다. 50만 검증인이 있을 경우 sync committee에 선정되는 것은 대략 37달 주기입니다.

하지만 sync commitee에 선정된다면 27시간 참여 기간동안 그 보상은 다른 보상에 비해 비교적 매우 큽니다. sync committee 참여자들은 매 slot마다 정확하게 네트워크 최신 블록에 서명한다면 보상을 획득하게 됩니다.

512 구성원으로 이루어진 Sync commitee는 epoch 당 32 슬롯 모두 정확한 참여를 한 경우 검증인당 보상은 다음과 같습니다.

T: 모든 active validator set의 increment입니다. 매우 큰 수입니다.

하지만, 참여하지 않거나 잘못된 헤드에 서명한 경우 수익과 동일한 양만큼의 패널티를 얻게 됩니다.

Proposal reward

블록 제안자의 리워드는 블록마다 고정 비율로 얻게 됩니다. R을 Validator Reward라고 한다면 다음과 같은 형태입니다.

현재 설정 값 기준으로 전체 리워드에서 12.5를 제외한 리워드의 7/8에 블록 제안자의 Reward Factor인 1/7=(12.5/(100–12.5)) 를 곱한 1/8*R이 Proposer 의 보상이 됩니다. 이러한 관계 설정을 통해 Attester와 블록제안자의 이해 관계가 일치시키게 됩니다. 또한 그밖에 Slashing에 대한 보고를 할 경우 추가 보상을 얻게 됩니다. 블록 제안자와 관련된 명시적인 패널티는 없습니다.

블록 제안자는 합의 계층만 아니라 실행 계층에서도블록을 제안함으로써 MEV 수익과 Trasaction Priority tips등을 추가 수익으로 얻을 수 있습니다.

그밖의 패널티

합의 계층의 주요 3개 의무 이행 이외에도 추가적인 패널티가 존재합니다.

Inactivity Leak는 네트워크 환경을 안정적으로 유지하기 위해 Offline 상태의 검증자를 대상으로 참여하지 않는 기간에 기하급수적으로 증가하는 패널티를 부여합니다. 부과하는 방식에 대해서는 여기에서 좀 더 확인하실 수 있습니다.

Slashing은 체인에 대한 공격의 일부가 될 수 있는 심각한 행위에 대한 처벌입니다. Slashing으로 이어지는 행동은 다음과 같습니다.

동일한 Target checkpoint에 대해서 두가지 다른 증명을 생성

예를 들면, 다음과 같이 타겟은 동일하지만 소스와 헤드 블록이 다른 경우, 체인 합의에 혼선이 발생할 수 있습니다.

첫 번째 Attestation: 소스: Epoch 10, 타겟: Epoch 20, 헤드 블록: 블록 A
두 번째 Attestation: 소스: Epoch 15, 타겟: Epoch 20, 헤드 블록: 블록 B

2. 동일한 검증자의 다른 증명에 있는 Source 및 Target 투표를 둘러 싼 증명을 생성

예를 들면, 동일한 타겟이 아니지만, 다음과 같이 제안할 경우 체인 합의의 혼선을 가져오게 됩니다.

첫 번째 Attestation: Epoch 10에서 Epoch 20
두 번째 Attestation: Epoch 5에서 Epoch 25

위와 같은 경우, 두번째 증명이 첫번째 증명 상태를 포함하게 되는데 이때 일관성을 해쳐, 체인 합의에 혼선을 가져오게 됩니다.

3. 같은 높이에 있는 두 개 이상의 개별 블록을 제안

위 행동이 발생한 경우, 어떤 규칙을 어겼는지 상관 없이 동일한 방식으로 처리됩니다.

초기 패널티 — 위반자는 즉시 유효 잔액에서 1/32가 삭감됩니다. 최초 패널티와 함께 종료 대기열에 들어가게 되고 출금은 8192 Epoch(약 36일)로 설정됩니다.
상관관계 패널티 — 인출 가능 기간 중간 지점(Slashing 된지 약 18일 후)에 두번째 패널티를 받게 됩니다. 이 두번째 패널티는 슬래싱된 전후 18일 동안 슬래싱 된 총량을 기준으로 합니다.

B: 슬래싱 당하는 검증인의 유효 잔액
S: 지난 36일간 슬래싱된 밸리데이터들의 increment의 총합
T: Total increment
기타 처벌 — 슬래싱될 경우 인출 가능 상태가 될 때까지 Inactive Leak의 영향을 받으며, 네트워크에 참여할 수 없기 때문에 추가 패널티를 받게 됩니다.

슬래싱을 보고한 경우 Proposer의 블록에 validator.effective_balance / WHISTLEBLOWER_REWARD_QUOTIENT (현시점 512) 에 해당 하는 보상을 받습니다. 자세한 내용은 여기에서 확인하실 수 있습니다.

수익의 측정

우리는 앞서 밸리데이터가 리워드와 패널티를 얻게 되는 경우와 그 금액을 계산하는 방법에 대해 알아보았습니다. 이번에는 검증인으로서 얻게 되는 수익을 측정하기 위해서는 어떻게 해야할까요? 이 모든 요소를 종합하여 의무 수행 여부와 비활성 누출, 슬래싱에 대한 상황까지 해야만 할까요? 수익을 청구하는 입장이라면 어느 시점에 어떤 항목까지 포함하여 요청해야 할까요? 납득할 만한 기준과 근거를 수립하는 것도 하나의 과제였습니다.

처음에 저는 두 가지 주요 방안을 고민했습니다. 첫 번째는 Beacon Reward API를 활용한 집계입니다. 밸리데이터 키가 활성화되면 ‘validator index’라는 밸리데이터 레지스트리의 인덱스가 부여됩니다. 이 인덱스를 활용하여 질의하거나 응답 결과에서 리워드와 패널티 항목에 속하는 밸리데이터 키를 분류할 수 있습니다. 따라서 밸리데이터 키 상태를 업데이트하면서 Validator Index를 저장해두고 변환하여 사용했습니다.

하지만 결론적으로 이 방법은 사용할 수 없었습니다. 이유는 Reward API 자체가 매우 무거운 요청이었고, 응답 속도가 20~30초 정도 걸렸기 때문입니다. Beacon API를 제공하는 RPC Provider들의 서비스도 연산을 많이 사용하는 리워드 관련 요청을 원활하게 제공하지 못하였습니다. 결국 내부적으로 구축한 Beacon Client를 사용할 수밖에 없었습니다. 개별 요청 속도가 오래 걸리다 보니, 최대한 요청을 묶어서 한 번의 요청에 Validator Index를 최대한 많이 포함하려고 시도했으나, 이는 결국 Beacon Client에 과부하를 주는 결과를 낳았습니다.

따라서, Beacon API 의 Reward API 를 호출하는 구조는 그대로 사용할 수 없었습니다. 다른 외부 서비스 사용도 고려하였습니다. Beaconcha에서도 리워드 관련 정보를 제공합니다. 하지만 집계에 대한 명확한 기준에 대해서는 안내되고 있지 않아 청구의 근거로 사용하기에는 모호한 부분이 있었습니다. 따라서, 앞서 학습한 내용을 바탕으로 직접 집계하는 로직을 구현하거나 다른 방법을 찾아야 했습니다. 우리는 그 답을 Reward를 최종 수령하는 과정에서 찾을 수 있었습니다.

바로, withdrawal key와 fee recipient입니다. withdrawal key로는 합의 계층의 수익이 전송되고, fee recipient로는 실행 계층의 수익이 적재됩니다. 이 과정을 정리하여 최종적인 수익을 집계할 수 있었습니다. withdrawal과 fee recipient로 수익이 적재되는 과정에 대해 좀 더 알아보겠습니다.

Beacon API의 Reward API 호출하는 방식이 아닌 실제 Slot의 Attestation, Proposer, Sync Commite 참여 상황을 모니터링하여 리워드와 퍼포먼스를 측정하는 과정은 ‘밸리데이터 인프라의 외부 모니터링 시스템 구축하기’에서 다루고 있으니 관심이 있으신 분들은 참고하시면 좋을 것 같습니다.

Withdrawal

Deposit 후 밸리데이터의 의무를 수행하고 얻게 되는 보상은 어떻게 다시 얻을 수 있을까요? 밸리데이터가 되기 위해서는 두 개의 키가 필요합니다. Signing key를 통해 검증인 의무를 수행하고, 얻게 되는 수익과 예치된 자산의 권리는 Withdrawal key가 가져갑니다.

Deposit을 수행할 때 매개변수로 Eth1 withdrawal credential을 포함합니다. 이때, Eth1 withdrawal credential은 withdrawal key에 0x01과 11개의 0x00의 접두어를 포함한 ithdrawal key 주소입니다. 이 값이 설정되어 있는 경우 두 종류의 Withdrawal이 발생합니다.

Validator가 Exit상태가 되었고 Withdrawable 상태가 되었고 잔액이 0이 아닌 경우 Full Withdrawal이 가능합니다. Full Withdrawal은 전액 인출을 의미합니다.
Validator가 Effective Balance(32ETH)를 가지고 있으며 실제 잔액이 그것보다 높은 경우 Partial Withdrawal이 가능합니다. Partial Withdrawal은 Validator의 실제 잔액이 MAX_EFFECTIVE_BALANCE (32ETH) 초과인 경우 초과한 금액을 인출하는 것을 의미합니다.

편의성과 효율성을 이유로 Beacon Chain에서 발생한 수익은 생성되는 블록에 Withdrawal 구조체에 최대 MAX_WITHDRAWALS_PER_PAYLOAD(16개)를 포함하여 합의 레이어에서 실행 레이어로 인출이 이루어집니다.

하지만 16개를 만들어내기 위해 너무 긴시간 동안 처리하는 것을 막기 위해MAX_VALIDATORS_PER_WITHDRAWALS_SWEEP 값에 도달하면 Withdrawal 목록을 생성을 종료하며 16개 미만의 Withdrawal 목록을 반환할 수 있습니다. Validator Withdrawal은 Round Robin 방식으로 처리되며, 별도 밸리데이터의 요청(Pull) 없이 Push 형태로 수행됩니다. 576,000명의 검증자가 모두 지급되는데 약 5일이 걸립니다.

출처: https://eth2book.info/capella/part2/deposits-withdrawals/

결과적으로, 합의 계층에서 적재된 수익은 밸리데이터 키의 잔액에 추가됩니다. 이후, 약 5일 주기로 Withdrawal을 통해 유효 잔액이 32 ETH 이상인 경우 Eth1 Withdrawal Address로 전송됩니다.

저희는 문제를 단순화하기 위해, 실질적으로 Execution Layer로 Beacon Layer 수익이 분배되는 Withdrawal을 기준으로 집계하였습니다. 즉, 실제 Execution Layer에 자금이 입금되는 시점을 수익 발생 시점으로 보고 계산하였습니다. 이 기준은 명확하며, 프로토콜에 의해 정리된 수익 분배 결과에 기반하기 때문에 정확합니다.

또한, 이 방법은 중간 계산 과정과 검산 과정을 불필요하게 하여 최종 수익 집계가 단순하고 효율적입니다. Deposit이 최초로 이루어진 블록 구간부터 탐색을 시작하여, 블록의 Withdrawal에서 Validator Index 가 저희가 관리하고 있는 밸리데이터 키에 해당하는 경우만 추적하여 수익을 추출하였습니다. Full Withdrawal(Exit)이 발생한 경우는 32 ETH를 제외하고 계산했습니다. Withdrawal 정보를 취합하여 실행 계층에서 발생한 수익을 집계할 수 있었습니다.

https://etherscan.io/txsBeaconWithdrawal?block=18595639

Fee recipient

Proposer의 경우 실행 계층에서도 블록 생성과 관련된 수익을 얻을 수 있습니다. 대표적인 수익은 MEV 수익입니다. 이 수익은 suggested_fee_recipient를 통해 전달됩니다. suggested_fee_recipient는 execution client가 수수료나 보상을 전달하기 위한 주소로 Merge 이후 suggested_fee_recipient는 validator client를 시작할 때 셋팅하게 되고, beacon client로 전송되며, beacon client는 이를 다시 execution client로 전달합니다. 이 주소로 수익이 전송되기 때문에 fee recipient로 전송되는 수익을 안전하게 관리하기 위해서는 반드시 beacon client와 execution client를 함께 운영해야 합니다.

MEV 수익을 얻기 위해 MEV replayer를 설정하여 운영하는 경우, 블록을 블록 빌더들에게 제안 받습니다. 따라서, 블록의 fee recipient는 검증인이 설정한 suggested_fee_recipient 주소가 아니라 블록 빌더들의 주소가 됩니다. MEV 수익을 극대화한 블록 빌딩 수익을 블록 빌더들이 가져가고, 블록의 마지막 트랜잭션으로 검증인이 원래 설정했던 suggested_fee_recipient로 수익을 공유합니다.

fee recipient로 전송되는 금액들을 집계하여 실행 계층 수익을 집계할 수 있게 됩니다. 하지만 LSP의 위임 받은 밸리데이터 키를 운영한 경우 동일한 fee recipient를 여러 밸리데이터들이 공유하여 사용하게 됩니다. 따라서, 다른 밸리데이터와 수익을 구분하기 위해서는 우리가 관리하고 있는 밸리데이터 키의 Validator Index로 제안된 블록의 수익만을 구분하여 추출했습니다. 이로서 실행 계층의 수익도 집계할 수 있게 되었습니다.

마치며

이 글에서는 검증자의 키 수명 주기, 의무 및 보상과 패널티와 실제 수익 집계에 대한 다루었습니다. 검증자는 네트워크 보안과 안정성을 유지하는 핵심 역할을 하며, 보상과 페널티 구조가 네트워크의 신뢰성을 강화합니다. 수많은 검증자들의 참여와 프로토콜의 인센티브 시스템을 통해 이더리움 생태계는 안전하고 건강한 발전을 이루어가고 있습니다.