이 문서에서 이더리움 Pectra 업그레이드에 대해 알아보세요: 각 EIP 전면 분석
저자: Tanay Ved, Coin Metrics
편집: GaryMa, 우설 블록체인
원문 편집 외에도, 본 문서는 원문에서 언급되지 않은 Pectra의 다른 EIP를 보완하여 소개합니다.
핵심 요점
Pectra는 이더리움의 다음 주요 업그레이드로, 실행 계층(Prague)과 합의 계층(Electra)의 변경을 포함합니다. 테스트넷 Pectra 업그레이드의 우여곡절을 겪은 후, 최종적으로 5월 7일 10:05 UTC 근처에 Pectra 메인넷 업그레이드가 활성화될 예정입니다.
이번 업그레이드는 스테이킹, Layer 2 확장성 및 사용자 경험(UX)에 대한 주요 개선을 이루며, 미래의 변화를 위한 기초를 마련합니다.
주요 변화에는 검증자의 스테이킹 한도 증가, 유연한 스테이킹 인출, 계정 추상화의 강화 및 blob 처리량 증가가 포함되어, 네트워크의 효율성과 보안을 향상시킵니다.
서론
"병합"(The Merge) 이후 31개월, "Shapella" 업그레이드 이후 24개월, "Dencun" 업그레이드 이후 13개월, 이더리움은 다음 주요 업그레이드인 Pectra 하드포크를 맞이하게 됩니다.
Pectra 메인넷 업그레이드 이전의 테스트넷 업그레이드는 우여곡절이 많았습니다.
Holesky 테스트넷의 Pectra 업그레이드는 2월 24일 21:55 UTC에 활성화되었으나, 클라이언트 소프트웨어 구성 오류(Geth, Nethermind 및 Besu의 예치 계약 주소 오류)로 인해 중단되어 체인이 분기되었습니다. 개발자들은 대규모 처벌 사건을 통해 네트워크를 복구할 계획을 논의하였으며, 이는 오류 검증자의 퇴출을 가속화하고 네트워크의 최종성을 달성하기 위한 것이었습니다. 최종적으로 3월 11일에 최종화가 이루어졌습니다.
Sepolia 테스트넷의 Pectra 업그레이드는 3월 5일 예정대로 진행되었으며, 사용자 정의 예치 계약 구성 문제로 인해 일부 실행 계층(EL) 클라이언트가 블록에 거래를 포함할 때 예외가 발생했으나, 문제는 곧 해결되었고 네트워크는 최종화되었습니다.
3월 19일, 검증자 퇴출을 테스트하기 위해 새로운 테스트넷 Hoodi가 출시되었고, 3월 26일에 Pectra 네트워크 업그레이드가 성공적으로 활성화되었습니다.
이더리움 Pectra 테스트넷의 업그레이드는 두 달의 우여곡절을 겪으며 메인넷 배포를 위한 길을 열었고, 최종적으로 5월 7일 10:05 UTC 근처에 Pectra 메인넷 업그레이드가 활성화될 예정입니다.
이더리움의 이전 업그레이드와 유사하게, Pectra는 실행 계층(EL)과 합의 계층(CL)을 동시에 포함합니다. 그 이름은 이러한 이중 초점을 반영합니다: Prague는 실행 계층 업그레이드를 나타내며, Devcon 4가 개최된 장소를 기념합니다; Electra는 합의 계층 업그레이드를 상징합니다.
Pectra는 이더리움 역사상 EIP(이더리움 개선 제안) 수가 가장 많은 하드포크 중 하나로, 총 11개의 EIP가 포함되어 있습니다. 이는 지난해 Dencun 업그레이드를 기반으로 추가 최적화를 이루어 사용자 경험(UX)을 개선하고 검증자 작업을 최적화하며 Layer 2 확장을 촉진하는 것을 목표로 하며, 이더리움 생태계에 깊은 영향을 미칠 것으로 예상됩니다.
본 문서에서는 각 EIP의 소속 분야에 따라 분류하여 각 EIP를 심층 분석합니다.
검증자 및 스테이킹 메커니즘 개선
Pectra는 세 가지 주요 EIP를 통해 이더리움 PoS 시스템 내 검증자 작업 경험을 최적화합니다:
EIP-7251: 최대 유효 잔액(MaxEB) 증가
현재 이더리움의 스테이킹 메커니즘은 단일 검증자의 유효 스테이킹 한도를 32 ETH로 제한하고 있습니다. 이는 독립 스테이커가 32 ETH 단위로 스테이킹해야 하며, 이 한도를 초과하는 보상은 유효 스테이킹에 포함되지 않음을 의미합니다.
EIP-7251은 최대 유효 잔액(MaxEB)을 2048 ETH로 증가시켜 단일 검증자의 스테이킹 범위를 32에서 2048 ETH로 확장할 수 있도록 제안합니다. 이로 인해 다음과 같은 영향이 있습니다:
· 스테이킹 유연성 향상: 스테이커는 모든 수익을 유효 스테이킹 잔액에 재투자할 수 있으며, 32 ETH의 배수에 제한받지 않습니다. 예를 들어, 33 ETH를 보유한 검증자는 이제 모든 33 ETH에 대해 스테이킹 보상을 받을 수 있어 자금 효율성과 유연성이 향상됩니다.
· 검증자 수 감소: 현재 이더리움에는 105만 개의 활성 검증자가 있으며, 이 EIP는 대형 운영자가 검증자를 통합할 수 있도록 하여 총 수를 줄이고 네트워크 부담을 경감합니다.
· 네트워크 부하 감소: 많은 검증자가 분산화에 기여하지만, 대역폭과 계산 부담을 증가시킵니다. MaxEB를 증가시키면 검증자 집합을 최적화하고 피어 투 피어 통신의 오버헤드를 줄일 수 있습니다.
EIP-7002: 실행 계층에서 인출 트리거
EIP-7002는 검증자 기능을 더욱 강화하여 실행 계층(0x01)에서 인출 증명을 통해 직접 퇴출 및 부분 인출을 트리거할 수 있도록 합니다.
현재 검증자는 두 개의 키를 가지고 있습니다:
활동 키: 검증 책임을 수행하는 데 사용됩니다;
인출 키: 스테이킹 자금을 접근하고 관리하는 데 사용됩니다.
이전에는 활동 키만 퇴출을 트리거할 수 있었고, 인출 키는 자율적으로 작동할 수 없었습니다. EIP-7002는 인출 키도 인출을 트리거할 수 있도록 허용하며, 이는 다음과 같은 이점을 가져옵니다:
· 자금 관리 권한 증가: 검증자는 노드 운영자에 의존하지 않고 직접 자금을 관리할 수 있습니다.
· 완전한 비신뢰 스테이킹 풀 지원: 보안성과 분산화 수준을 향상시킵니다.
EIP-6110: 체인 상에서 검증자 예치금 저장
현재 새로운 검증자가 실행 계층에 예치금을 한 후, 합의 계층이 이를 인식하고 처리할 때까지 기다려야 하므로 활성화가 지연됩니다.
EIP-6110은 실행 계층이 합의 계층에 직접 예치금 정보를 전달할 수 있도록 하여 추가 검증 단계를 줄이고, 검증자의 활성화 시간을 약 9시간에서 약 13분으로 단축합니다.
Layer 2 확장 능력 향상: Blob 처리량 증가
EIP-7691: Blob 처리량 증가
지난해 Dencun 업그레이드에서 Blobs가 도입되어 Layer 2 롤업의 데이터를 저장하는 효율적인 방법으로 사용되고 있습니다. 현재 매일 약 2.1만 개의 Blobs가 이더리움에 제출되고 있지만, 용량이 한계에 가까워져 수수료가 상승하고 처리량이 제한되고 있습니다.
현재 이더리움의 각 블록당 목표 Blob 수는 3개이며, 최대 6개입니다. EIP-7691은 목표 값을 6으로, 최대 값을 9로 증가시켜 데이터 저장 용량을 늘리고 처리량과 확장성을 향상시키는 것을 제안합니다. 이는 데이터 저장 비용을 낮추어 L2 거래 수수료를 줄이는 데 기여할 것입니다.
EIP-7623: calldata 비용 증가
Blob 메커니즘이 도입되기 전, L2는 주로 calldata를 사용하여 데이터를 저장하였으며, 특정 경우에는 여전히 사용되고 있습니다. 이는 더 비용 효율적일 수 있기 때문입니다.
EIP-7623은 calldata 비용을 증가시켜 L2가 주로 blob을 사용하여 데이터를 저장하도록 유도하여 롤업 거래 효율성을 향상시킵니다.
사용자 경험(UX) 향상
EIP-7702: EOA 계정 코드 설정
핵심 아이디어: EOA에 임시로 스마트 계약 기능 부여
EIP-7702는 새로운 거래 유형(0x04로 식별됨)을 도입하여 외부 소유 계정(EOA)이 거래를 수행하는 동안 임시로 스마트 계약 기능을 얻을 수 있도록 합니다. 즉, 전통적으로 EOA는 코드가 없고 거래 서명만 가능하지만, 이 제안을 통해 EOA는 거래 내에서 코드를 "로드"하여 스마트 계약 지갑처럼 복잡한 작업을 수행할 수 있습니다.
주요 장점
- 배치 작업: 사용자는 한 거래 내에서 여러 작업(예: approve + deposit 조합)을 완료할 수 있어 여러 거래가 필요한 비효율성을 피할 수 있습니다.
· 가스 후원: 이 메커니즘은 제3자가 거래 수수료를 후원할 수 있도록 지원하여 사용자 경험을 개선하고, 사용자가 ETH를 미리 보유하지 않고도 작업을 수행할 수 있게 합니다.
· 보안성 및 유연성 향상: 사용자는 거래에 대해 세밀한 권한 제어를 할 수 있어, 자식 계정이 제한된 조건에서만 작업을 수행하도록 허용하여 계정 보안성을 강화합니다.
직면할 수 있는 도전 과제
· 생태계 호환성 문제: EOA가 전통적으로 코드가 없다고 여겨지기 때문에, 일부 기존 스마트 계약이나 보안 검사(예: require(tx.origin == msg.sender))는 이 임시 코드 부여 메커니즘에 맞게 조정이 필요할 수 있습니다.
· 거래 구조 복잡성 증가: 새로운 거래 유형의 도입은 지갑과 클라이언트가 상당한 변경을 필요로 하여, 새로운 권한 튜플 및 임시 코드 설정을 처리할 때 보안 취약점이나 추가 비용이 발생하지 않도록 해야 합니다.
EIP-7702는 일반 EOA가 단일 거래에서 임시로 스마트 계약 기능을 얻을 수 있도록 하여 배치 거래, 거래 후원 및 더 유연한 권한 관리를 지원합니다. 이 메커니즘은 사용자 경험을 크게 개선하고 dApp 기능을 확장할 수 있지만, 일부 전통적인 가정을 깨뜨릴 수 있으며, 생태계의 모든 당사자가 적응하고 업데이트해야 합니다. 전반적으로 이는 계정 추상화를 위한 중요한 제안으로, 미래의 이더리움 계정이 안전하면서도 더 유연해지도록 하는 것을 목표로 합니다.
기타 EIP
EIP-7685: 일반 실행 계층 요청
배경 및 목적
현재 Eth1(실행 계층)과 신호 체인(합의 계층) 간에는 세 가지 주요 요청을 처리해야 합니다:
1. 예치: 사용자가 시작한 예치 이벤트는 처음에 Eth1 블록에 나타나지만, 결국 신호 체인에서 처리되어야 합니다.
2. 인출: 신호 체인에서 발송된 인출 요청(일반적으로 명령줄 도구를 통해)은 Eth1에서 처리되어야 합니다.
3. 검증자 병합: 이 요청도 Eth1과 신호 체인 간에 전달되어야 합니다.
왜 이 제안이 필요한가
현재 서로 다른 유형의 작업이 두 계층 간에 오가면서 혼란을 초래할 수 있습니다. EIP-7685가 제안하는 통합 처리 프레임워크는 다음을 목표로 합니다:
· 모든 요청을 표준화된 방법으로 처리하여 프로세스를 더 명확하고 효율적으로 만듭니다;
· 단지 Eth1을 통해 이러한 작업을 트리거하여 검증자의 운영 환경과 스테이킹 관리를 분리하여 보안을 향상시킵니다.
주요 내용
1. 요청 유형 식별: 각 작업에 대해 특정 식별자를 정의하며, 기존의 예치 및 인출 요청 유형 외에 병합 요청 유형도 추가됩니다.
2. 완전성 보장: 요청 데이터의 완전성과 보안을 보장하기 위해 해시 검증, 머클화 데이터 등의 메커니즘을 사용합니다.
3. 처리 큐 및 속도 제한: 처리 대기 중인 요청에 대해 일부 제한(예: 동시에 대기 중인 예치, 인출 또는 병합 요청의 수)을 설정하여 시스템 과부하를 방지합니다.
최종 의미
일반 사용자와 개발자에게는 앞으로 예치, 인출 또는 검증자 병합 작업을 수행할 때 통합되고 표준화된 프로세스를 통해 더 빠르고 안전하게 완료할 수 있다는 것을 의미합니다. 이는 시스템의 효율성을 높일 뿐만 아니라 전체적인 위험을 줄이는 데 기여합니다.
EIP-2537: BLS12--381 곡선 작업의 프리컴파일
핵심 목적
이 제안은 이더리움에 BLS12--381 곡선에서의 수학 연산을 처리하기 위한 내장 기능(프리컴파일 계약)을 추가합니다.
왜 이 프리컴파일이 필요한가
· 효율성 향상: 스마트 계약 내에서 복잡한 타원 곡선 연산(예: 서명 검증 및 집합)을 직접 구현하면 많은 가스를 소모합니다. 프리컴파일 계약은 이러한 연산의 비용을 크게 줄일 수 있습니다.
· 더 높은 보안성: 현재 사용되는 BN254 곡선(약 80비트의 보안성)과 비교할 때, BLS12--381 곡선은 약 120비트의 보안성을 제공하여 암호화 작업을 더 안전하게 만듭니다.
주요 용도
· BLS 서명 검증: BLS 서명은 여러 서명을 하나로 집합할 수 있도록 하여 검증 시 계산량을 크게 줄입니다.
· zkSNARK 증명 검증: 일부 개인 정보 보호 및 확장성 솔루션에서는 zkSNARK 증명을 검증해야 하며, 이러한 작업은 복잡한 타원 곡선 계산에 의존합니다.
실제 의미
이 EIP를 통해 개발자는 스마트 계약 내에서 BLS12--381 곡선 관련 암호화 연산을 더 효율적이고 저렴하게 사용할 수 있어, 더 많은 혁신적인 응용 프로그램을 지원할 수 있습니다. 예를 들어, 더 효율적인 합의 메커니즘, 크로스 체인 상호작용 및 다양한 분산형 응용 프로그램 등이 있습니다.
간단히 말해, EIP-2537은 체인 상에서 높은 보안성을 가진 암호화 연산을 수행할 때 과도한 가스를 소모하는 문제를 해결하기 위해 프리컴파일 계약을 통해 이러한 복잡한 연산을 더 효율적이고 실용적으로 만드는 것입니다.
EIP-2935: 상태에 역사적 블록 해시 저장
현재 문제
이더리움 가상 머신(EVM)에서 BLOCKHASH 연산 코드를 통해서는 최근 256개의 블록 해시(약 50분 내의)를 조회할 수 있으며, 이는 일부 응용 프로그램에 충분하지 않습니다. 예를 들어, 더 이전 블록 데이터의 증명이 필요한 크로스 체인 응용 프로그램이나 무상태 클라이언트(예: 롤업) 등이 있습니다.
제안의 핵심
EIP-2935는 블록체인의 상태에 추가로 8192개의 블록 해시(약 27.3시간 내의)를 저장할 것을 제안하여, 쿼리할 수 있는 역사적 블록 데이터 범위를 크게 확장합니다.
어떻게 구현할 것인가
기존 BLOCKHASH 연산 코드가 최근 256개의 블록만 접근할 수 있도록 유지하는 것 외에도, 제안은 새로운 시스템 계약을 도입합니다:
· set() 메서드: 각 블록이 처리될 때, 새로운 계약은 현재 블록 해시를 원형 버퍼에 자동으로 저장합니다.
· get() 메서드: 누구나 이 메서드를 통해 원형 버퍼에 저장된 역사적 블록 해시를 조회할 수 있습니다.
실제 이점
이렇게 되면 크로스 체인 응용 프로그램, 롤업 또는 더 이전 블록 데이터에 접근해야 하는 시스템은 외부 데이터에 의존하지 않고 체인 상에서 필요한 역사 정보를 직접 얻을 수 있어, 설계를 더 간단하고 안전하며 신뢰할 수 있게 만듭니다.
EIP-7840: blob 스케줄링을 EL 구성 파일에 추가
핵심 목적
이 제안은 blob 스케줄링과 관련된 주요 매개변수(예: 각 블록에서 허용되는 blob 수 및 기본 수수료 업데이트 비율)를 실행 계층(EL)의 구성 파일에 기록하는 것을 목표로 합니다.
구체적인 방법
· 구성 파일에 "목표 blob 수" 및 "최대 blob 수" 설정을 추가합니다.
· 또한 기본 수수료 업데이트 속도를 조정하기 위한 baseFeeUpdateFraction이라는 매개변수를 추가합니다.
· 클라이언트는 노드 API를 통해 이러한 매개변수를 조회하여 현재 네트워크의 blob 구성에 대한 정보를 알 수 있습니다.
왜 유용한가
이 정보는 개발자와 노드 운영자가 blob 가스 비용을 더 정확하게 추정하는 데 도움을 주며, 네트워크가 블록 내 대량 데이터의 스케줄링 및 처리를 더 잘 관리하는 데 기여합니다.
전반적으로 EIP-7840은 이더리움 실행 계층에 구성 가능한 blob 스케줄링 매개변수를 추가하여 네트워크가 대량 데이터(blob)를 처리할 때 더 효율적이고 투명하게 만듭니다.
EIP-7549: 위원회 인덱스를 증명에서 제거
핵심 아이디어
현재 검증 투표(Attestation) 메시지에는 세 가지 부분이 포함되어 있습니다:
· LMD GHOST 투표(블록 루트 및 시간 슬롯 포함)
· Casper-FFG 투표(소스 및 타겟 포함)
· 위원회 인덱스(index)
문제는 위원회 인덱스도 서명되어 있어, 투표 내용이 동일하더라도 인덱스가 다르면 생성된 서명 루트도 다르게 됩니다. 이는 동일한 내용의 투표가 집합될 수 없게 만듭니다.
EIP-7549가 제안하는 해결책은 위원회 인덱스를 서명된 투표 메시지에서 제거하는 것입니다. 이렇게 하면 투표의 핵심 내용(LMD GHOST 및 Casper-FFG 투표)만 서명 계산에 참여하게 되어, 동일한 투표의 여러 검증자가 동일한 서명 루트를 생성할 수 있게 되어 집합이 가능해집니다.
주요 이점
· 검증 작업량 대폭 감소: 현재 상황에서는 2/3 합의를 달성하기 위해 1366개의 투표를 검증해야 할 수 있습니다. 위원회 인덱스를 제거하면 약 22개의 투표만 검증하면 되며(약 62배의 계산량 절감), 이는 대량의 쌍 연산이 필요한 검증 과정에서 효율성을 크게 향상시킵니다. 특히 제로 지식 증명 기반의 Casper FFG 클라이언트에 대해 더욱 그렇습니다.
· 체인 상 데이터 저장 효율성 향상: 투표 정보를 더 효율적으로 집합할 수 있어, 각 블록에 더 많은 투표를 패키징할 수 있습니다. 현재 하나의 블록에는 2개의 시간 슬롯 투표만 포함될 수 있지만, 개선 후에는 최대 8개의 시간 슬롯 투표를 포함할 수 있으며, 제안자가 1/8만 온라인일지라도 모든 투표를 블록에 포함할 수 있습니다.
위원회 인덱스를 Attestation 메시지에서 제거함으로써, 검증 투표 시 처리해야 할 쌍 연산 수를 크게 줄일 수 있을 뿐만 아니라, 투표 데이터를 더 효율적으로 패키징하여 전체 합의 검증 과정의 성능과 체인 상 저장 활용률을 향상시킬 수 있습니다. 이 개선은 Casper FFG 합의 메커니즘 및 관련된 제로 지식 증명 검증에 특히 중요합니다.
결론
Pectra는 기록적인 수의 EIP를 포함하는 업그레이드로, 이더리움이 계정 추상화, 검증자 메커니즘 최적화, 네트워크 효율성 향상 및 Layer 2 확장 등 주요 방향으로 발전하는 데 기여할 것입니다. 또한, Vitalik Buterin이 최근 강조한 바와 같이, 이더리움은 Rollup 중심의 확장 경로를 채택하고 있지만, Layer 1을 지속적으로 최적화하고 있으며, 최근 가스 제한을 3600만으로 증가시켰고, 앞으로도 검열 저항 능력, 처리량 및 확장성을 더욱 향상시킬 가능성이 있습니다.
참고 링크:
https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7600.md