Validator’s Note 26 — EIP-7251 핵심 정리

Published in

DSRV

13 min readAug 5, 2024

Disclaimer: 이 글은 정보 전달을 위한 목적으로 작성되었으며, 특정 프로젝트에 대한 투자 권고, 법률적 자문 등 목적으로 하지 않습니다. 모든 투자의 책임은 개인에게 있으며, 이로 발생한 결과에 대해 어떤 부분에서도 DSRV는 책임을 지지 않습니다. 본문이 포괄하는 내용은 특정 자산에 대한 투자를 추천하는 것이 아니며, 언제나 본문의 내용만을 통한 의사결정은 지양하시길 바랍니다.

이더리움의 다음 업그레이드인 Pectra 에는 밸리데이터 관련된 변경사항이 다수 포함되어 있습니다. 주요한 EIP중 하나인 EIP-7251(EIP-7251: Increase the MAX_EFFECTIVE_BALANCE)는 작년부터 논의되어왔던 주제로, 이더리움 밸리데이터의 MAX_EFFECTIVE_BALANCE를 높이자는 제안입니다. 오늘은 EIP-7251가 도입되는 배경과 새로운 기능, 또 이가 어떠한 영향을 가져올 수 있는지 핵심적인 내용을 정리해 보려고 합니다.

들어가기에 앞서..

생소하신 분들을 위해 용어를 잠시 짚고 넘어가겠습니다. 이더리움은 1) Effective Balance(유효 잔액, 이하 EB) 2) Actual Balance(실제 잔액)의 두 가지 밸리데이터 잔액 기록을 유지합니다. 실제 잔액은 밸리데이터 노드가 실제로 보유하고 있는 이더리움의 양을 의미하며, 보상과 페널티로 인해 매번 변경될 수 있습니다. EB는 네트워크상에서의 밸리데이터의 가중치를 의미하며, 밸리데이터에게 주어지는 보상과 페널티를 계산하는 데 사용되는 값입니다. EB는 실제 잔액을 가지고 계산되며, 실제 잔액이 특정 임곗값 이상으로 변경되었을 때 반올림 또는 반내림하여 정수 단위의 값을 가집니다. (더 자세한 매커니즘은 링크를 참고 하세요.)

EIP-7251: Increase the MAX_EFFECTIVE_BALANCE

EIP-7251은 이더리움 활성 밸리데이터 수가 계속 증가함에 따라, 합의를 이루기 위해 전파해야 하는 메시지가 증가하고, 이로 인해 이더리움의 P2P 네트워크에 가해지는 부담이 커지는 것에 대한 우려에서 시작되었습니다. 이더리움 재단이 테스트넷(holesky)에서 210만 대의 밸리데이터로 실험했을 때, 합의 과정 중 많은 밸리데이터가 높은 연산 부하를 겪으며 네트워크에 문제가 발생했고, 결국 체인이 확정(Finalize)되지 못하는 상황이 발생하였습니다 . [1] 현재 이더리움 활성 밸리데이터 수는 100만 대 이상이며 계속 증가 추세를 보이고 있습니다. 이에 따라 밸리데이터 수를 감소시키기 위한 여러 방법이 고민되었고, 그중 채택된 방법이 바로 EIP-7251입니다.

EIP-7251는 이더리움 밸리데이터의 활성화를 위한 EB의 최솟값인 MIN_ACTIVATION_BALANCE는 32ETH로 유지하고, EB의 최댓값인 MAX_EFFECTIVE_BALANCE_ELECTRA 를 2048ETH까지 높이는 제안입니다. 기존에는 밸리데이터 한 대에 아무리 많은 잔액을 가지고 있더라도, 오직 32ETH에 해당하는 리워드만을 받을 수 있었다면 이제는 2048ETH까지의 모든 잔액에 대한 리워드를 받을 수 있는 것입니다. 따라서 최대 기존 밸리데이터 64개 어치의 지분을 하나로 통합하여 운영할 수 있어 밸리데이터 수를 줄이고, 이를 통해 네트워크의 P2P 메시지, 집계해야 하는 BLS 서명 수 및 메모리를 줄이는 것을 목표로 합니다. 또한 기존에는 32ETH보다 많은 잔액을 가지고 있어도 32ETH를 넘는 리워드가 자동으로 부분 인출(partial withdrawal) 되었다면, 변경 시 2048ETH(상한값) 또는 사용자 설정값 이하의 리워드가 출금되지 않고 쌓이게 되어 복리 효과가 발생합니다.

MIN_ACTIVATION_BALANCE = Gwei(2^5 * 10^9) (= 32,000,000,000) 
MAX_EFFECTIVE_BALANCE_ELECTRA = Gwei(2^11 * 10^9) (= 2048,000,000,000)

새로운 기능

복리 밸리데이터 전환

EIP-7251는 COMPOUNDING_WITHDRAWAL_PREFIX라는 새로운 타입의 접두사(prefix)0x02를 도입합니다. 이전 상하이 하드포크 때 스테이킹 된 ETH를 출금하기 위해서 접두사를 0x00에서 0x01로 변경해야 했던 것처럼, 0x02로 변경하여 CL에서 복리 가능한 밸리데이터로 전환할 수 있게 됩니다. 전환 방법에는기존 밸리데이터에 추가 자금을 입금하는 방식과, 두 밸리데이터의 자금을 통합하는 방식 두가지가 있습니다.

BLS_WITHDRAWAL_PREFIX = Bytes1('0x00')
ETH1_ADDRESS_WITHDRAWAL_PREFIX = Bytes1('0x01')
COMPOUNDING_WITHDRAWAL_PREFIX = Bytes1('0x02') #New!

자금 통합(consolidation)은 밸리데이터 종료 및 시작 대기열의 혼잡 및 대기 시간 동안의 자금 손실을 최소화하고자, 기존 밸리데이터를 모두 종료하고 새로운 밸리데이터를 만드는 것이 아닌 프로토콜 내에서 통합이 가능한 방식으로 설계되었습니다. 통합 요청은 EL의 메세지로 촉발되어 CL의 상태를 변경하는 방식으로 이루어지며, 이 또한 Pectra 업그레이드에 도입된 EIP-7685(General purpose execution layer requests)로 활성화된 새로운 기능입니다.

def switch_to_compounding_validator(state: BeaconState, index: ValidatorIndex) -> None:
	validator = state.validators[index]
	if has_eth1_withdrawal_credential(validator):
		validator.withdrawal_credentials = COMPOUNDING_WITHDRAWAL_PREFIX + validator.withdrawal_credentials[1:]
		queue_excess_active_balance(state, index)

소스(source) 밸리데이터를 타겟(target) 밸리데이터로 통합하는 경우, 소스 밸리데이터가 EL에서 트랜잭션으로 통합 요청을 보내고, 이가 CL 블록에 포함되면 소스 밸리데이터의 종료 및 인출 과정이 시작됩니다. 소스 밸리데이터가 종료 대기열 및 256 에폭(약 27시간) 후 완전히 종료되고 인출 가능한 상태가 되면, 타겟 밸리데이터에 소스 밸리데이터의 잔액이 통합 완료됩니다. 단, 프로토콜 내 통합을 위해서는 소스 및 타겟 밸리데이터가 동일한 출금 주소(WC)를 가지고 있어야 한다는 점을 유의해야 합니다. [2] 이가 다를 경우 두 밸리데이터를 모두 종료하고, 자금을 합쳐 새로운 밸리데이터를 시작해야 할 수 있습니다.

class ConsolidationRequest(Container):
	source_address: ExecutionAddress
	source_pubkey: BLSPubkey
	target_pubkey: BLSPubkey

부분 인출(partial withdrawal)

복리가 가능한 밸리데이터가 잔액을 부분 인출하는 경우는 자동(sweep) 부분 인출과, EL 요청을 통한 부분 인출로 나누어 볼 수 있습니다. 먼저 2048ETH 이상 쌓인 잔액은 자동 부분 인출되며, 2048ETH에 도달하지 않더라도 밸리데이터가 2048ETH 이하로 MaxEB를 커스텀 설정하여 MaxEB 이상의 잔액을 자동 부분 인출 받을 수도 있습니다.

요청을 통한 부분 인출도 Pectra의 EIP-7002로 새로 활성화되는 기능입니다. EIP-7002 (Execution layer triggerable withdrawals)은 위에서 살펴본 밸리데이터 통합 요청처럼 EIP-7685를 활용하여 EL의 요청으로 밸리데이터 종료 및 출금을 가능하게 하는 제안입니다. 이 기능을 사용하면 해당 밸리데이터의 WC 소유자가 자동 부분 인출되는 MaxEB에 도달하기 전에 32 ETH 이상의 임의의 금액을 인출할 수 있습니다.

뿐만 아니라 기존에는 밸리데이터의 BLS키 소유자가 CL에서 메세지를 전파하여 종료가 가능하였는데, WC 소유자(자금 소유자)와 키 소유자(노드 운영자)가 다른 리퀴드 스테이킹의 경우 밸리데이터를 종료하기 위해서는 키 소유자를 신뢰하여야 한다는 문제가 있었습니다. EIP-7002는 이러한 부분을 해결하고 WC 소유자가 EL에서 직접 밸리데이터를 종료할 수 있어 리퀴드 스테이킹에 이점을 가져올 것으로 평가됩니다.

class PendingPartialWithdrawal(Container):
	index: ValidatorIndex
	amount: Gwei
	withdrawable_epoch: Epoch

시작 및 종료 대기열(activation & exit queue)

추가 입금의 경우 다른 입금 건과 같은 시작 대기열을 통해 처리되며, 자금 통합 요청 시의 소스 밸리데이터의 종료 또한 다른 종료 건과(VoluntaryExit) 동일한 종료 대기열을 통해 처리됩니다. 다만 대기열의 Churn Limit, 즉 처리 한도에는 변경사항이 있습니다. 기존에는 정해진 개수의 밸리데이터를 매 에폭마다 처리하는 방식이었습니다. 지난 Dencun 업그레이드에서는 밸리데이터 증가 속도를 억제하기 위해 EIP-7514(Add Max Epoch Churn Limit)를 통해 에폭당 최대 8명의 밸리데이터만 시작할 수 있도록 변수를 조정하기도 하였습니다.

이번 EIP-7251에서는 그 처리 한도에 밸리데이터 개수가 아닌 밸리데이터의 EB의 총합(gwei)를 사용하는 방식으로 변경되었습니다. 따라서 밸리데이터의 요청은 EB에 따라 가중치가 부여되며 한 에폭마다 EB의 총합이 최소 128ETH, 최대 256ETH인 개수의 밸리데이터 요청이 처리될 수 있습니다. 상한과 하한사이에서는 에폭마다 현재 네트워크 전체의 총 EB에 따라 처리 한도가 변경됩니다.

Name Value MIN_PER_EPOCH_CHURN_LIMIT_ELECTRA Gwei(2^7 * 10^9) (= 128,000,000,000) 
MAX_PER_EPOCH_ACTIVATION_EXIT_CHURN_LIMIT Gwei(2^8 * 10^9) (= 256,000,000,000)

따라서 처리 한도가 256ETH이라면 32ETH 밸리데이터라면 최대 8개, 더 큰 지분의 밸리데이터의 요청이라면 그 이하를 처리할 수 있을 것입니다. 현재 에폭 내에 처리 가능한 EB를 관리하기 위해서 처리 한도에서 밸리데이터의 EB를 차감한 값을 xxx_balance_to_consume으로 저장합니다. 만약 EB가 상한을 넘어가는 밸리데이터의 요청이 있다고 한다면, 밸리데이터의 EB에서 처리 한도를 차감하고 처리될 에폭을 +1합니다. 다음 에폭에서 같은 과정을 반복하여 남은 EB가 처리 한도 이하가 되는 에폭에서 처리될 것입니다. 예를 들어 처리 한도가 256ETH 일 때 에폭 n에서 600ETH 밸리데이터가 종료 대기열에 들어왔다고 가정한다면 600=256*2+88이므로 두 에폭이 지난 n+2에서 대기열을 벗어나 종료가 시작될 것이며, n+2 에폭에서는 처리한도를 88ETH 채워 exit_balance_to_consume 이 168(=256–88)ETH가 될 것입니다.

class BeaconState(Container):
...
	deposit_balance_to_consume: Gwei  # [New in Electra:EIP7251]
	exit_balance_to_consume: Gwei  # [New in Electra:EIP7251]
	earliest_exit_epoch: Epoch  # [New in Electra:EIP7251]
	consolidation_balance_to_consume: Gwei  # [New in Electra:EIP7251]
	earliest_consolidation_epoch: Epoch  # [New in Electra:EIP7251]

슬래싱

그러나 동시에 밸리데이터 한대가 많은 지분을 보유하고 있으면 슬래싱 위험이 높아지기도 하기에 지분을 어떻게 분배할지에 대한 고민이 필요하기도 합니다. 따라서 더 많은 밸리데이터가 지분 통합에 참여할 수 있도록, 밸리데이터의 EB가 증가할수록 그 위험이 커지는 패널티에 대한 수정이 제안되었습니다. [3]

출처: https://ethresear.ch/t/slashing-penalty-analysis-eip-7251

이더리움에서 밸리데이터에게 적용되는 첫 번째 잔액 감소를 의미하는 초기 슬래싱 페널티(initial slashing panalty)는 EB의 1/32로 설정되어 있기에, EB가 높은 밸리데이터일 수록 슬래싱 리스크가 선형적으로 증가합니다. 즉 EB가 2048 ETH인 밸리데이터는 64ETH를 잃게될 수 있습니다. 따라서 초기 슬래싱을 비율이 아닌 일정한 양으로 고정하거나 선형 이하로 확장되도록하는 방안이 고려되고 있습니다 그리고 일정기간 슬래싱된 밸리데이터가 많을수록 그 패널티가 증가하는 상관관계 패널티(correlation penalty)또한 EB에 비례해서 증가하기에, 선형이 아닌 이차로 증가하도록 하는 방식이 제안되었습니다.

마무리

오늘은 EIP-7251가 무엇인지 알아보았습니다. EIP-7251는 솔로 스테이커의 경우에도 32ETH 이상에 해당하는 자본에 모두 복리 효과를 누릴 수 있어 이점이 있지만, 특히 많은 지분을 관리하는 스테이킹 풀 및 대규모 운영자에게 큰 영향을 줄 수 있습니다. 기존에는 32ETH 제한으로 인해 지분을 쪼개어 많은 수의 밸리데이터 클라이언트를 운영해야 했지만, 이제는 밸리데이터 지분을 통합하여 키 관리나 운영 비용, 가스비 등의 측면에서 이점을 얻을 수 있습니다. 밸리데이터 한 대의 지분이 커질수록 커지는 슬래싱 리스크에 대응하기 위하여, 장애률을 감소시키고 안정성을 높일 수 있는 DVT의 중요도도 높아질 수 있을 것으로 보입니다. 현재 Pectra에서 EIP-7251구현이 포함된 devnet-2가 진행 중이지만, 아직 패널티 등 중요한 부분은 논의 중으로 지켜볼 필요가 있습니다. 읽어주셔서 감사합니다.

Written by
Youngbin Park, Research Engineer, DSRV Validator Team (Twitter @bin0_0bin)

Reference

[1] https://notes.ethereum.org/@parithosh/bigboi-beaconchain-test-2
[2] https://github.com/ethereum/consensus-specs/blob/dev/specs/electra/beacon-chain.md#execution-layer-consolidation-requests
[3] https://ethresear.ch/t/slashing-penalty-analysis-eip-7251/16509/1