이더리움의 다가오는 하드포크 분석: Pectra 업그레이드
작성자:Sergey Boogerwooger, Dmitry Zakharov, MixBytes
번역: AI 번역관,등사커뮤니티
소개
이전 글에서 우리는 이더리움 검증자의 수명 주기를 상세히 살펴보고 다가오는 Electra 하드포크와 관련된 여러 측면을 논의했습니다. 이제 Electra 및 Prague 업그레이드에서 이루어질 변화에 주목하고 이를 자세히 설명할 차례입니다.
이더리움 2.0 '지분 증명(PoS)' 하드포크의 역사는 복잡합니다. 기존 실행 레이어에 비콘 레이어를 추가하면서 시작되었고, 비콘 레이어가 지분 증명 합의를 활성화하는 동시에 실행 레이어는 작업 증명(PoW)을 유지한 상태였습니다(Phase0 및 Altair 하드포크). 이후 Bellatrix 하드포크에서 PoS가 완전히 활성화되었으며(출금 기능은 아직 활성화되지 않았음), Capella 하드포크에서는 출금이 가능해져 검증자의 수명 주기가 완성되었습니다. 최근의 Deneb 하드포크(Dencun(Deneb/Cancun) 업그레이드의 일부)는 비콘 체인 파라미터를 약간 수정하였는데, 예를 들어 증명 포함 시간 창, 자발적 탈퇴 처리, 검증자 교체 제한 등이 있습니다. Dencun의 주요 변화는 실행 레이어에서 발생했으며, blob 트랜잭션, blob 가스, blob에 대한 KZG 커밋을 도입하고 SELFDESTRUCT 연산을 폐기했습니다.
이제 Prague/Electra(즉, Pectra) 하드포크는 실행 레이어와 합의 레이어 모두에 중요한 업그레이드를 도입합니다. Lido 프로젝트의 감사자로서, 우리는 이번 하드포크에서 합의 및 스테이킹과 관련된 변화에 주로 집중합니다. 그러나 Prague의 실행 레이어 변화 또한 무시할 수 없으며, 이는 이더리움 네트워크와 검증자에게 중요한 기능들을 포함하기 때문입니다. 이제 이러한 변화들의 세부 사항을 깊이 있게 살펴보겠습니다.
Pectra 개요
Electra는 비콘 레이어에 다양한 기능을 도입합니다. 주요 업데이트는 다음과 같습니다:
-
검증자의 유효 잔액을 32 ETH에서 2048 ETH 사이로 변경 가능하게 함(기존의 고정된 32 ETH 대신).
-
검증자가 2차 '출금' 자격 증명을 통해 탈퇴를 시작할 수 있도록 허용함(활성 검증자 키가 더 이상 필요하지 않음).
-
비콘 레이어가 Eth1 예치금을 처리하는 방식을 변경함(예치금 계약에서 이벤트를 더 이상 파싱하지 않음).
-
일반적인 Eth1 계약에서 요청을 비콘 레이어에서 처리할 수 있는 새로운 범용 프레임워크를 추가함(Electra 이전의 예치금 관리 방식과 유사).
동시에, Prague는 실행 레이어에 다음과 같은 변화를 도입합니다:
-
zkSNARK 증명을 검증하기 위해 BLS12-381 곡선을 지원하는 새로운 프리컴파일된 계약(BN254 곡선 외에도).
-
최대 8192개의 과거 블록 해시를 저장하고 접근할 수 있는 새로운 시스템 계약(스테이트리스 클라이언트에 매우 유용함).
-
블록 크기를 줄이고 rollup과 같이 calldata 집약적인 작업을 Dencun에서 도입된 blobs로 이전하도록 유도하기 위해 calldata 가스 비용을 증가시킴.
-
각 Eth1 블록당 더 많은 blobs를 지원하고, 이러한 수량을 읽을 수 있는 API를 제공함.
-
EOA(외부 소유 계정)가 자체 계정 코드를 가질 수 있도록 하여 multicall 수행이나 다른 주소에 실행 위임 등 EOA가 수행할 수 있는 작업을 크게 확장함.
다음과 같은 관련 이더리움 개선 제안(EIP)을 참조하여 더 자세히 논의해 보겠습니다:
-
EIP-7251: MAX_EFFECTIVE_BALANCE 증가
-
EIP-7002: 실행 레이어에서 트리거 가능한 탈퇴
-
EIP-6110: 체인 상에서 검증자 예치금 제공
-
EIP-7549: 증명에서 위원회 인덱스 제거
-
EIP-7685: 범용 실행 레이어 요청
-
EIP-2537: BLS12-381 곡선 연산을 위한 프리컴파일
-
EIP-2935: 상태에 과거 블록 해시 저장
-
EIP-7623: calldata 비용 증가
-
EIP-7691: blob 처리량 증가
-
EIP-7840: EL 구성 파일에 blob 스케줄링 추가
-
EIP-7702: EOA 계정 코드 설정
이러한 EIP 중 일부는 주로 합의(비콘) 레이어와 관련되어 있고, 다른 일부는 실행 레이어와 관련되어 있습니다. 일부는 예치금 및 탈퇴와 같은 작업이 합의 레이어와 실행 레이어 간의 동기화된 변경을 필요로 하기 때문에 두 레이어 모두에 걸쳐 있습니다. 이러한 상호 의존성으로 인해 Electra와 Prague를 분리하는 것은 실용적이지 않으므로, 각 EIP를 차례로 검토하며 각 경우에 영향을 받는 이더리움 구성 요소를 명시하겠습니다.
EIP-7251: MAX_EFFECTIVE_BALANCE 증가
참조: EIP-7251
이더리움의 지분 증명 준비를 위한 최초의 Phase0 하드포크 이후, Electra 이전까지 검증자의 최대 유효 잔액은 32 ETH로 고정되어 있었습니다. 검증자를 활성화하려면 적어도 spec.min_activation_balance(32 ETH) 이상이 필요했습니다. 활성화 후, 검증자는 이 최대 유효 잔액에서 시작하지만, spec.ejection_balance(16 ETH)까지 유효 잔액을 줄일 수 있으며, 해당 임계값에 도달하면 추방됩니다. 이러한 '최소' 로직은 Electra에서도 그대로 유지되지만, 이제 spec.max_effective_balance가 2048 ETH로 증가하였습니다. 따라서 검증자는 32~2048 ETH 사이의 금액을 예치하여 활성화할 수 있으며, 이러한 모든 금액은 유효 잔액에 기여합니다. 이 전환은 "32ETH-지분 증명"에서 단순한 "지분 증명"으로의 전환을 의미합니다 :)
이제 이 가변 유효 잔액은 다음 용도로 사용됩니다:
-
유효 잔액에 비례하여 블록 제안자로 선정될 확률 증가
-
유효 잔액에 비례하여 동기화 위원회 멤버로 선정될 확률 증가
-
상대적 슬래싱 및 비활동 패널티 금액 산정 기준으로 활용
앞의 두 가지 활동은 검증자에게 가장 보람 있는 작업입니다. 따라서 Electra 이후, 큰 규모로 스테이킹하는 검증자는 유효 잔액에 비례하여 더 자주 블록 제안 및 동기화 위원회에 참여하게 됩니다.
슬래싱과 관련된 또 다른 영향은 다음과 같습니다. 모든 슬래싱 패널티는 검증자의 유효 잔액에 비례합니다:
-
'즉시' 및 '지연' 슬래싱 패널티는 고액 스테이킹 검증자에게 더 큽니다.
-
높은 잔액을 슬래싱 당한 검증자와 함께 있는 '지연' 슬래싱 패널티도 더 큽니다. 왜냐하면 전체 스테이킹에서 '슬래싱'된 부분이 더 커지기 때문입니다.
-
유효 잔액이 높은 검증자를 신고한 신고자는 더 큰 비율의 슬래싱된 스테이크를 받게 됩니다.
Electra는 슬래싱 비율의 변경도 제안하며, 이는 슬래싱된 검증자의 잔액 중 일부를 정의하고 신고자가 수령하게 됩니다.
다음은 비효율성 영향입니다. 검증자가 활성 상태(증명 또는 제안)에서 오프라인일 때, 비효율성 점수가 누적되어 매 사이클마다 비효율성 패널티가 부과됩니다. 이러한 패널티도 검증자의 유효 잔액과 비례 관계에 있습니다.
유효 잔액이 증가함에 따라 검증자의 '교체 제한'도 변경되었습니다. 'Electra 이전' 이더리움에서는 검증자가 일반적으로 동일한 유효 잔액을 가지고 있었고, 탈퇴 교체 제한은 '한 사이클 내에서 총 스테이크의 최대 1/65536(spec.churn_limit_quotient)까지만 탈퇴할 수 있다'로 정의되었습니다. 이는 동일한 스테이크를 가진 검증자의 고정된 탈퇴 수를 생성했습니다. 그러나 'Electra 이후',少数 '고래'들만 탈퇴하는 상황이 발생할 수 있는데, 이들은 총 스테이크의 중요한 부분을 대표하기 때문입니다.
또 다른 고려사항은 하나의 검증자 인스턴스에서 많은 검증자 키를 회전시키는 것입니다. 대형 검증자는 현재 고액 스테이킹을 위해 32 ETH 단위로 나누어 수천 개의 검증자 키를 하나의 인스턴스에서 운영해야 하는 강제 상황에 처해 있습니다. Electra 이후에는 이러한 행동이 더 이상 강제되지 않습니다. 재무적으로 보면 이 변화는 크게 영향을 미치지 않으며, 보상과 확률은 스테이크 금액에 따라 선형적으로 조정됩니다. 따라서 32 ETH씩 100개의 검증자는 3200 ETH의 검증자와 동일합니다. 또한, 여러 활성 검증자 키는 동일한 Eth1 출금 자격 증명을 가질 수 있어 모든 보상을 단일 ETH 주소로 인출함으로써 보상 통합과 관련된 가스 비용을 피할 수 있습니다. 그러나 다수의 키 관리는 추가적인 관리 비용을 초래합니다.
검증자 잔액을 집계할 수 있는 능력은 새로운 유형의 실행 레이어 요청을 추가합니다. 이전에는 예치금과 출금이 있었습니다. 이제 또 다른 유형이 추가됩니다: 집계 요청. 이것은 두 검증자를 하나로 병합합니다. 이 작업 요청은 소스 검증자의 공개키와 대상 공개키를 포함하며, 예치금 및 출금과 유사하게 처리됩니다. 집계 역시 보류 중인 요청과 잔액 교체 제한이 예치금 및 출금과 마찬가지로 적용됩니다.
요약하면:
-
소규모 독립 검증자의 경우, Electra는 유효 잔액(및 보상)을 자동으로 증가시킬 수 있는 능력을 제공합니다. 이전에는 32 ETH를 초과하는 잉여 금액은 인출만 가능했지만, Electra 이후에는 이 잉여 금액이 결국 유효 잔액에 기여하게 됩니다. 그러나 유효 잔액은 spec.effective_balance_increment(1 ETH)의 배수로만 증가할 수 있으므로, 다음 '1 ETH 한계'에 도달한 후에야 증가가 발생합니다.
-
대규모 독립 검증자의 경우, Electra는 여러 활성 검증자 키를 하나로 통합할 수 있도록 하여 현저한 관리 간소화를 제공합니다. 게임 체인저는 아니지만, 1x2048 스테이킹을 운영하는 것이 64x32 스테이킹을 관리하는 것보다 훨씬 간단합니다.
-
유동 스테이킹 제공자의 경우, 사용자로부터 소액 스테이킹을 수집하여 검증자들에게 분배하는데, Electra는 스테이킹 분배 방안에 더 많은 유연성을 제공하지만, 고정된 32 ETH 유효 잔액 기반의 검증자 회계에 대해 심각한 재구성을 요구합니다.
또 다른 중요한 주제는 검증자의 역사 데이터와 수익 추정이며, 이는 리스크와 보상을 평가하려는 신규 참여자에게 특히 관련이 있습니다. Electra 이전(본문 작성 시점까지)에는 최소 혹은 최대 상관없이 32 ETH 상한선이 역사 데이터에서 균일성을 만들어냈습니다. 모든 검증자의 유효 잔액, 보상, 개별 슬래싱 패널티, 블록 제안 빈도 및 기타 지표들이 동일했습니다. 이러한 균일성은 이상치 없이 이더리움이 합의 메커니즘을 테스트하고 가치 있는 네트워크 행동 데이터를 수집할 수 있도록 했습니다.
Electra 이후, 스테이킹 분포는 중대한 변화를 겪게 됩니다. 대형 검증자는 블록 제안 및 동기화 위원회에서 더 자주 참여하게 되며, 슬래싱 사건에서는 더 큰 패널티를 받고, 지연 슬래싱, 활성화 대기열, 탈퇴 대기열에 더 큰 영향을 미칠 것입니다. 데이터 집계에서 어려움을 초래할 수 있지만, 이더리움 합의는 비선형 계산을 최소화합니다. 유일한 비선형 컴포넌트는 sqrt(total_effective_balance)를 사용하여 기본 보상을 계산하는 것으로, 모든 검증자에게 적용됩니다. 즉, 검증자 보상과 슬래싱은 여전히 '1 ETH당' 기준(또는 더 정확히는 spec.effective_balance_increment에 따라, 미래에 변경될 수 있음)으로 추정할 수 있습니다.
자세한 내용은 이전에 검증자 행동에 대해 작성한 글을 참조하세요.
EIP-7002: 실행 레이어에서 트리거 가능한 탈퇴
참조: EIP-7002
이더리움의 각 검증자는 두 쌍의 키를 갖습니다: 하나는 활성 키, 다른 하나는 출금 키입니다. 활성 공개 BLS 키는 비콘 체인에서 검증자의 주요 신원으로 사용되며, 이 키 쌍은 블록 서명, 증명, 슬래싱, 동기화 위원회 집계, 그리고 (이 EIP 이전까지는) 자발적 탈퇴(검증자의 합의 탈퇴를 지연 후 시작)에 사용됩니다. 두 번째 키 쌍('출금 자격 증명')은 다른 BLS 키 쌍이거나 일반적인 Eth1 계정(개인키 및 주소)일 수 있습니다. 현재 ETH 주소로 인출하려면 활성 BLS 개인키로 서명된 인출 메시지가 필요합니다. 이 EIP은 이러한 방식을 변경합니다.
실제로, 이 두 키 쌍(활성 및 출금)의 소유자는 서로 다를 수 있습니다. 검증자의 활성 키는 검증 책임(서버 운영, 정상 작동 유지 등)을 담당하며, 출금 자격 증명은 일반적으로 스테이크 소유자가 통제하며, 이는 보상을 수령하고 자금을 관리합니다. 현재 출금 자격 증명을 통제하는 스테이크 소유자는 검증자의 탈퇴를 시작할 수 없으며, 보상만 인출할 수 있습니다. 이 상황은 검증자의 활성 키 소유자가 효과적으로 검증자의 잔액을 '인질'로 들고 있을 수 있게 합니다. 검증자는 탈퇴 메시지를 '미리 서명'하여 스테이크 소유자에게 넘겨줄 수 있지만, 이러한 우회 방법은 이상적이지 않습니다. 또한 현재 인출과 탈퇴 모두 전용 API를 통해 비콘 레이어 검증자와 상호작용해야 합니다.
최상의 해결책은 스테이크 소유자가 표준 스마트 계약 호출을 통해 인출 및 탈퇴를 동시에 수행할 수 있도록 허용하는 것입니다. 이는 표준 Eth1 서명 확인을 포함하며, 작업을 크게 단순화합니다.
이 EIP는 스테이크 소유자가 자신의 ETH 주소에서 전용 스마트 계약으로 표준 트랜잭션을 보내 탈퇴 및 인출을 트리거할 수 있도록 합니다(기존의 '예치금' 계약을 사용한 예치금 과정과 유사). 인출(또는 충분한 스테이크 제거 시 탈퇴) 과정은 다음과 같습니다:
-
스테이커가 시스템의 '출금' 계약에 출금 요청('in' 요청)을 보냅니다.
-
계약은 악의적인 공격을 완화하기 위해 특정 수수료(ETH 기준)를 부과하며, EIP-1559처럼 요청 대기열이 혼잡할 경우 수수료가 증가합니다.
-
계약은 'in' 출금/탈퇴 요청을 저장소에 저장합니다.
-
비콘 레이어에 블록이 제안될 때, 대기열의 'in' 출금/탈퇴 요청이 저장소에서 검색됩니다.
-
비콘 레이어는 'in' 요청을 처리하여 활성 검증자 잔액과 상호작용하고, 검증자 탈퇴를 예약하며, 'out' 출금 요청을 형성합니다.
-
'out' 출금 요청은 실행 레이어에서 처리되며, 스테이커는 ETH를 수령합니다.
예치금은 Eth1 블록에서 트리거되는 작업이며, 이후 '보류 중인' 예치금 대기열을 통해 비콘 레이어로 '이동'됩니다. 반면, 출금은 CLI를 통해 비콘 레이어에서 트리거되고, 이후 Eth1 블록으로 '이동'됩니다. 이제 두 방식은 아래에서 설명할 동일한 범용 프레임워크를 통해 작동합니다: Eth1 레이어에서 요청을 생성하고, '보류 중인' 예치금/출금/병합 대기열을 처리하며, 비콘 레이어에서 요청을 처리합니다. 출금과 같은 '출력' 작업의 경우 출력 대기열도 처리되며, 결과는 Eth1 블록에서 '결제'됩니다.
이 EIP를 통해 스테이커는 검증자 CLI와 직접 상호작용하거나 검증자 인프라에 접근하지 않고도 일반적인 ETH 트랜잭션을 사용하여 검증자를 인출하고 탈퇴할 수 있습니다. 이는 특히 대규모 스테이킹 제공자에게 스테이킹 작업을 크게 단순화합니다. 검증자 인프라는 이제 거의 완전히 격리될 수 있으며, 활성 검증자 키만 유지하면 되고, 모든 스테이킹 작업은 다른 장소에서 처리할 수 있습니다. 독립 스테이커가 활성 검증자의 동작을 기다릴 필요가 사라졌으며, Lido 서비스의 Community Staking Module과 같은 체인 외부 부분도 크게 단순화됩니다.
따라서 이 EIP는 스테이킹 작업을 '완성'하여 이를 완전히 Eth1 레이어로 이전하고, 인프라 보안 리스크를 크게 낮추며, 독립 스테이킹 이니셔티브의 탈중앙화를 강화합니다.
EIP-6110: 체인 상에서 검증자 예치금 제공
참조: EIP-6110
현재 예치금은 시스템 '예치금' 계약 내 이벤트를 통해 이루어집니다(이전 글에서 상세히 논의됨). 계약은 ETH와 검증자 자격 증명을 수락하고 'Deposit()' 이벤트를 발생시킨 후, 이 이벤트들은 파싱되어 비콘 레이어의 예치금 요청으로 변환됩니다. 이 시스템은 많은 단점이 있습니다: 비콘 체인 레이어에서 eth1data에 대한 투표를 요구하며, 이는 상당한 지연을 초래합니다. 또한 비콘 레이어는 실행 레이어를 조회해야 하며, 이는 복잡성을 더욱 증가시킵니다. 이러한 문제들은 EIP에서 상세히 논의됩니다. 이러한 문제들 대부분을 처리하지 않고도 더 간단한 방법은 지정된 위치에 예치금 요청을 직접 Eth1 블록에 포함시키는 것입니다. 이 메커니즘은 이전 EIP에서 설명된 인출 처리 프로세스와 유사합니다.
이 EIP에서 제안된 변화는 유망합니다. eth1data 처리는 이제 완전히 제거될 수 있으며, Eth1 측의 이벤트와 비콘 레이어 상의 예치금 포함 사이에 투표나 장시간 지연(현재 약 12시간)이 더 이상 필요하지 않습니다. 또한 예치금 계약 스냅샷의 로직도 제거됩니다. 이 EIP는 예치금 처리를 단순화하며 위에서 설명한 인출 처리 방식과 일치시킵니다.
스테이커와 검증자에게 이러한 변화는 예치금과 검증자 활성화 사이의 지연을 크게 줄입니다. 검증자가 슬래싱될 때 필요한 보충도 더 빨라집니다.
이 EIP에 대해 할 말은, 오래된 로직을 제거하고 프로세스를 단순화하며 모든 이해관계자에게 더 나은 결과를 만든다는 점 외에는 없습니다.
EIP-7685: 범용 실행 레이어 요청
참조: EIP-7685
이 EIP는 예치금/출금/병합과 관련된 앞의 세 EIP 이전에 제안되었어야 했으며, 왜냐하면 이들 EIP의 기반이 되기 때문입니다. 그러나 여기서 소개하는 이유는 Eth1(실행)과 비콘(합의) 체인 블록(레이어) 사이에서 전용 데이터를 일관되게 이동시키는 데 대한 수요가 증가하고 있음을 강조하기 위해서입니다. 이 EIP는 두 레이어 모두에 영향을 미치며, 일반적인 ETH 트랜잭션을 통해 트리거되는 요청 처리를 더 효율적으로 만듭니다. 현재 관찰되는 바는 다음과 같습니다:
-
Eth1 블록 내 예치금 이벤트가 비콘 블록으로 '이동'되어 처리됩니다.
-
비콘 블록 내 출금 요청(CLI 사용)이 Eth1 블록으로 '이동'되어 처리됩니다.
-
검증자 병합 처리도 필요하며, 이 또한 Eth1->비콘 요청입니다.
이 세 가지 작업은 실행 레이어와 비콘 레이어 간 전환 시 다양한 유형의 요청을 일관되게 처리할 필요성을 나타냅니다. 또한 이러한 작업을 오직 Eth1 레이어를 통해 트리거할 수 있는 능력이 필요합니다. 왜냐하면 이를 통해 검증자 인프라와 스테이킹 관리 인프라를 격리시켜 보안을 향상시킬 수 있기 때문입니다. 따라서 이러한 요청을 관리하는 범용 솔루션은 실용적이면서도 필수적입니다.
이 EIP는 예치금, 출금, 병합이라는 최소 세 가지 주요 사례를 위한 프레임워크를 마련합니다. 그래서 초기 EIP들이 WITHDRAWAL_REQUEST_TYPE 및 DEPOSIT_REQUEST_TYPE과 같은 필드를 도입했고, 이제 병합은 CONSOLIDATION_REQUEST_TYPE이라는 또 다른 필드를 추가할 것입니다. 또한 이 EIP는 요청 처리 제한에 대한 일반적인 메커니즘(상수 참조: PENDING_DEPOSITS_LIMIT, PENDING_PARTIAL_WITHDRAWALS_LIMIT, PENDING_CONSOLIDATIONS_LIMIT)을 포함할 수도 있습니다.
이 프레임워크의 상세 구현 세부 사항은 아직 이용할 수 없지만, 핵심 요청 유형, 무결성 메커니즘(예: 해시 및 머클화된 요청), 보류 중인 대기열 처리 및 속도 제한을 포함할 것입니다.
이 EIP는 아키텍처적 의미를 가지며, Eth1이 통합된 프레임워크를 통해 비콘 레이어의 핵심 작업을 트리거할 수 있게 합니다. 최종 사용자와 프로젝트에게는 Eth1 레이어에서 트리거된 모든 요청이 비콘 레이어에서 더 효율적으로 전달되고 처리된다는 것을 의미합니다.
EIP-2537: BLS12-381 곡선 연산을 위한 프리컴파일
참조: EIP-2537
깊이 들어가고 싶지 않다면, BLS12-381의 프리컴파일을 복잡한 암호학적 '해시' 연산으로 생각할 수 있으며, 이제 스마트 계약 내에서 사용할 수 있습니다. 관심 있는 분들을 위해 더 깊이 들어가겠습니다.
BLS12-381(그리고 대응하는 BN-254)과 같은 타원 곡선에서 수행되는 수학적 연산은 현재 주로 두 가지 목적에 사용됩니다:
-
BLS 서명, 여기서 '페어링'이라고 불리는 특수 연산을 사용하여 서명을 검증합니다. BLS 서명은 여러 서명을 하나로 집계할 수 있기 때문에 검증자들 사이에서 널리 사용됩니다. 검증자는 BLS12-381 곡선 기반의 BLS 서명을 사용합니다(비록 BN254와 같은 페어링 지원 곡선을 사용해 구현할 수도 있음).
-
zkSNARK 증명의 검증, 여기서 페어링은 증명을 검증하는 데 사용됩니다. 또한 Dencun 하드포크에서 도입된 큰 덩어리(blob)에 대한 KZG 커밋도 블록 커밋을 검증하기 위해 페어링을 사용합니다.
스마트 계약 내에서 BLS 서명이나 zkSNARK 증명을 검증하려면 이러한 '페어링'을 계산해야 하며, 이는 계산적으로 매우 비쌉니다. 이더리움은 이미 BN254 곡선 연산을 위한 프리컴파일된 계약(EIP-196 및 EIP-197)을 가지고 있습니다. 그러나 BLS12-381 곡선(현재 더 안전하다고 여겨지고 오늘날 더 널리 사용됨)은 아직 프리컴파일로 구현되지 않았습니다. 그러한 프리컴파일이 없으면 스마트 계약 내에서 페어링 및 기타 곡선 연산을 구현하려면 여기에 표시된 바와 같이 많은 계산이 필요하며 거대한 가스를 소비합니다(약 ~10^5 에서 10^6 가스).
이 EIP는 BLS12-381 곡선 기반의 저렴한 BLS 서명 검증과 같은 다양한 잠재적 응용 분야를 열어줍니다. 이를 통해 다양한 목적의 문턱 값(threshold) 방안을 구현할 수 있습니다. 앞서 언급했듯이, 이더리움 검증자는 이미 BLS12-381 기반 서명을 사용하고 있습니다. 이 EIP를 통해 표준 스마트 계약은 이제 집계된 검증자 서명을 효율적으로 검증할 수 있습니다. 이는 합의 증명 및 크로스 체인 자산 브리징을 단순화할 수 있으며, BLS 서명은 블록체인 전반에 걸쳐 광범위하게 사용되기 때문입니다. 문턱 값 BLS 서명 자체는 투표, 탈중앙화된 난수 생성, 다중 서명 등에 사용할 수 있는 많은 효율적인 문턱 값 방안을 구축할 수 있게 합니다.
더 저렴한 zkSNARK 증명 검증은 다시 많은 응용 분야를 해제할 것입니다. 많은 zkSNARK 기반 솔루션은 현재 높은 증명 검증 비용 때문에 어려움을 겪고 있으며, 이로 인해 어떤 프로젝트들은 거의 실현 불가능해집니다. 이 EIP는 이러한 상황을 바꿀 잠재력을 가지고 있습니다.
EIP-2935: 상태에 과거 블록 해시 저장
참조: EIP-2935
이 EIP는 블록체인 상태에 8192개(약 27.3시간)의 과거 블록 해시를 저장하여 스테이트리스 클라이언트(rollup 등) 및 스마트 계약에 확장된 역사 정보를 제공할 것을 제안합니다. BLOCKHASH 연산코드의 현재 동작을 유지하면서 최근 256개 블록에 대한 제한을 유지하는 동시에, 과거 해시를 저장하고 검색하기 위한 전용 설계된 새로운 시스템 계약을 도입합니다. 이 계약은 실행 레이어에서 블록을 처리할 때 set() 연산을 수행합니다. get() 메서드는 누구나 접근할 수 있으며, 원형 버퍼에서 원하는 블록 해시를 검색할 수 있습니다.
현재 EVM에서 과거 블록 해시를 참조하는 것은 가능하지만, 최근 256개 블록(약 50분)으로 접근이 제한됩니다. 그러나 과거 블록 데이터에 접근하는 것이 중요한 경우도 있습니다. 특히 크로스 체인 애플리케이션(이전 블록 데이터를 증명 필요) 및 정기적으로 초기 블록 해시에 접근해야 하는 스테이트리스 클라이언트의 경우 그렇습니다.
이 EIP는 rollup 및 크로스 체인 애플리케이션에 사용 가능한 시간 범위를 확장하여 EVM 내에서 직접 과거 데이터에 접근할 수 있게 하며, 외부에서 수집할 필요를 없앱니다. 따라서 이러한 솔루션은 더 강건하고 지속 가능해집니다.
EIP-7623: calldata 비용 증가
참조: EIP-7623
calldata 비용은 트랜잭션 페이로드의 사용 가능한 크기를 조절하며, 경우에 따라 매우 클 수 있습니다(예: 큰 배열이나 이진 버퍼를 매개변수로 전달할 때). 눈에 띄는 calldata 사용은 주로 rollup에 기인하며, 이들은 현재 rollup 상태를 calldata에 포함하여 페이로드를 전송합니다.
대규모, 증명 가능한 이진 데이터를 블록체인에 도입하는 것은 rollup에게 중요합니다. Dencun(Deneb-Cancun) 업그레이드는 이러한 용도에 중요한 혁신을 도입했습니다—blob 트랜잭션(EIP-4844). blob 트랜잭션은 전용 'blob' 가스 요금을 가지며, 본문은 일시적으로 저장되지만 암호학적 증명(KZG 커밋)은 해시와 함께 합의 레이어에 통합됩니다. 따라서 calldata에 데이터를 저장하는 것과 비교할 때 blob은 rollup에게 더 나은 해결책을 제공합니다.
rollup이 데이터를 blob으로 이전하도록 유도하는 것은 '당근과 채찍' 방식으로 가능합니다. 낮아진 blob 가스 요금은 '당근'이며, 이 EIP는 calldata 비용을 증가시켜 '채찍' 역할을 하여 트랜잭션에서 과도한 데이터 저장을 억제합니다. 이 EIP는 다음 EIP-7691(blob 처리량 증가)를 보완하며, 후자는 블록당 허용되는 blob 최대 수를 증가시킵니다.
EIP-7691: blob 처리량 증가
참조: EIP-7691
이전 Dencun 하드포크에서 blob이 도입되었으며, '블록당' blob의 최대 및 목표 수치는 보수적인 추정치로 설정되었습니다. 이는 p2p 네트워크가 검증자 노드 사이에서 대규모 이진 객체를 어떻게 처리할지 예측하는 복잡성 때문입니다. 이전 구성은 잘 작동함이 입증되었으며, 새로운 값들을 테스트하기에 적절한 시기입니다. 이전에는 블록당 목표/최대 blob 수치가 3/6으로 설정되었습니다. 이제 이 제한은 각각 6/9로 증가합니다.
이전 EIP-7623(calldata 비용 증가)과 결합하면, 이 조정은 rollup이 데이터를 calldata에서 blobs로 옮기는 것을 더욱 자극합니다. 최적의 blob 파라미터를 찾는 작업은 계속 진행 중입니다.
EIP-7840: EL 구성 파일에 blob 스케줄링 추가
참조: EIP-7840
이 EIP는 앞서 논의된 블록당 목표 및 최대 blob 수와 baseFeeUpdateFraction 값을 이더리움 실행 레이어(EL) 구성 파일에 추가할 것을 제안합니다. 또한 클라이언트가 노드 API를 통해 이러한 값을 검색할 수 있도록 합니다. 이 기능은 blob 가스 요금 추정 등의 작업에 특히 유용합니다.
EIP-7702: EOA 계정 코드 설정
참조: EIP-7702
이것은 이더리움 사용자에게 중대한 변화를 가져올 매우 중요한 EIP입니다. 알려진 바와 같이, EOA(외부 소유 계정)는 코드를 가질 수 없지만 트랜잭션 서명(tx.origin)을 제공할 수 있습니다. 반면 스마트 계약은 바이트코드를 가지지만, '자신의 직접 서명'을 적극적으로 제안할 수 없습니다. 추가적, 자동적, 검증 가능한 로직이 필요한 사용자 상호작용은 현재 외부 계약을 호출하여 필요한 작업을 수행하는 것 외에는 불가능합니다. 그러나 이 경우 외부 계약은 후속 계약의 msg.sender가 되어 '사용자가 아닌 계약에서 호출'이 됩니다.
이 EIP는 새로운 SET_CODE_TX_TYPE=0x04 트랜잭션 유형을 도입합니다(이전에는 0x1 트랜잭션, 베를린 및 EIP-1559 업그레이드에서 도입된 새 0x02 트랜잭션, Dencun에서 도입된 0x03 blob 트랜잭션이 있었습니다). 이 새로운 트랜잭션 유형은 EOA 계정에 코드를 설정할 수 있게 합니다. 실제로, 이는 EOA가 '자신의 EOA 계정 컨텍스트 내에서' 외부 코드를 실행할 수 있게 합니다. 외부 관점에서 보면, 트랜잭션 중 EOA는 마치 외부 계약의 코드를 '빌려' 실행하는 것처럼 보입니다. 기술적으로는, EOA 주소의 '코드' 저장소에 특별한 승인 데이터 튜플을 추가함으로써 이루어집니다(이 EIP 이전에는 이 '코드' 저장소는 EOA에 대해 항상 비어 있었습니다).
현재 이 EIP가 제안하는 새로운 0x04 트랜잭션 유형은 다음 배열을 포함합니다:
authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]
각 요소는 지정된 주소의 코드를 사용하도록 계정을 허용합니다(마지막 유효 승인 항목에서). 이러한 트랜잭션을 처리할 때, 주어진 EOA의 코드는 특별한 0xef0100 || 주소 값(23바이트)으로 설정되며, 여기서 주소는 필요한 코드를 가진 계약을 가리키고, ||는 연결을 의미하며, 0xef0100은 EIP-3541에 따라 일반 스마트 계약이 포함할 수 없는 특별한 마법값을 나타냅니다. 이 마법값은 이 EOA가 일반 계약으로 간주되거나 일반 계약처럼 호출될 수 없도록 보장합니다.
이 EOA가 트랜잭션을 시작할 때, 지정된 주소가 해당 EOA 컨텍스트 내에서 해당 코드를 호출하는 데 사용됩니다. 이 EIP의 완전한 구현 세부 사항은 아직 명확하지 않지만, 중대한 변화를 가져올 것임은 확실합니다.
주요 영향 중 하나는 EOA에서 직접 멀티콜(multicall)을 수행할 수 있다는 것입니다. 멀티콜은 DeFi에서 지속되는 트렌드이며, 많은 프로토콜이 강력한 도구로서 이 기능을 제공합니다(예: Uniswap V4, Balancer V3 또는 Euler V2). 이 EIP를 통해 이제 EOA에서 직접 멀티콜을 시작할 수 있습니다.
예를 들어, 이 새로운 기능은 DeFi에서 흔히 발생하는 approve() + anything()이 두 개의 독립된 트랜잭션을 필요로 하는 비효율성을 해결합니다. 이 EIP는 approve(X) + deposit(X)와 같은 일반적인 '사전 승인' 로직을 허용하여 단일 트랜잭션에서 완료할 수 있게 합니다.
EOA를 대신하여 트랜잭션 실행을 위임할 수 있는 또 다른 이점은 스폰서십(sponsorship)의 개념입니다. 스폰서십은 종종 논의되며 이더리움에 진입하는 신규 사용자를 돕기 위해 매우 열망되는 기능입니다.
EOA와 연관된 프로그래머블 로직은 보안 제한 시행, 지출 상한 설정, KYC 요구 강제 등 많은 가능성을 해제합니다.
물론, 이 전환은 많은 설계 문제도 제기합니다. chain_id 사용 여부는 동일한 서명이 여러 네트워크에서 유효할 수 있는지 결정하며, 서명에 포함되거나 포함되지 않는지에 따라 달라집니다. 또 다른 복잡한 문제는 대상 코드의 주소를 사용하는 것과 실제 바이트코드를 포함하는 것 사이의 선택입니다. 두 방법 모두 고유한 특징과 제한이 있습니다. 또한 nonce 사용은 권한이 '다중 사용'인지 '단일 사용'인지 정의하는 데 핵심적인 역할을 합니다. 이러한 요소들은 일괄적으로 서명을 무효화하거나 사용 편의성 등 기능 및 보안 문제에 영향을 미칩니다. Vitalik은 한 토론에서 이러한 문제들을 제기했습니다(여기), 더 깊이 탐구할 가치가 있습니다.
주목할 점은, 이 변화가 tx.origin이라는 이더리움의 보안 메커니즘에 영향을 준다는 것입니다. 이 EIP 구현에 관한 더 많은 세부 정보가 필요하지만, require(tx.origin == msg.sender)의 동작이 변경될 것으로 보입니다. 이 검사는 msg.sender가 스마트 계약이 아닌 EOA임을 보장하는 가장 신뢰할 수 있는 방법이었습니다. EXTCODESIZE를 확인하는 다른 방법들(계약인지 확인하기 위해)은 일반적으로 실패하며 우회될 수 있습니다(예: 생성자 호출 또는 트랜잭션 후 사전 정의된 주소에 코드 배포). 이러한 검사는 재진입 및 플래시론 공격을 방지하기 위해 사용되지만, 이상적이지는 않으며 외부 프로토콜과의 통합을 방해하기도 합니다. 이 EIP 이후에는 신뢰할 수 있는 require(tx.origin == msg.sender) 검사조차도 과시처럼 보입니다. 프로토콜은 'EOA'와 '계약' 간의 구분이 더 이상 적용되지 않기 때문에 이러한 검사를 제거하여 적응해야 합니다—이제 모든 주소는 관련 코드를 가질 수 있습니다.
전통적인 EOA와 스마트 계약의 분리는 계속해서 모호해지고 있습니다. 이 EIP는 이더리움을 각 계정이 본질적으로 실행 가능한 코드가 되는 TON과 같은 설계에 더 가깝게 만듭니다. 프로토콜과의 상호작용이 점점 더 복잡해짐에 따라 최종 사용자 경험을 향상시키기 위해 프로그래머블 로직을 사용하는 것은 이러한 진화의 자연스러운 과정입니다.
결론
프라하 / Electra(Pectra) 업그레이드는 2025년 3월로 예정되어 있습니다. 계획된 주요 변경 사항은 다음과 같습니다:
-
최대 2048 ETH까지 가변 검증자 유효 스테이킹으로, 스테이킹 분포와 검증자 일정을 크게 변화시키고, 작은 스테이킹을 통합함으로써 대규모 스테이킹 제공자의 관리를 단순화함
-
실행 레이어와 합의 레이어 간 상호작용 개선, Eth1 실행 블록과 비콘 체인 블록 간 데이터 교환 단순화. 이를 통해 예치금, 활성화, 인출, 탈퇴가 크게 단순화되고 빨라지며, 합의 레이어와 실행 레이어 간 추가 상호작용의 기반을 마련함
-
새로운 '페어링 친화적' BLS12-381 프리컴파일을 통해 스마트 계약 내에서 더 저렴한 BLS 서명 및 zkSNARK 검증을 직접 지원
-
blob 트랜잭션 임계값을 증가시키고 calldata 비용을 높여 rollup이 blob 트랜잭션을 채택하도록 유도함
-
EOA를 프로그래머블 계정으로 만들고, 멀티콜, 스폰서십 및 기타 고급 기능을 부여함
보시다시피, Pectra는 스테이킹 및 합의 레이어뿐만 아니라 실행 레이어의 최종 사용자 경험에도 중대한 영향을 미칠 것입니다. 이 단계에서 코드 수준에서 모든 변화를 상세히 분석할 수는 없으며, 개발이 계속 진행 중이므로, 우리는 미래의 글에서 이러한 업데이트를 다룰 것입니다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
@MixBytes
