저자: Sergey Boogerwooger, Dmitry Zakharov, MixBytes
편집자: AI 번역가, 등련 커뮤니티
소개하다
이전 기사에서는 이더 검증자 수명 주기를 자세히 검토하고 다가올 Electra 하드 포크 와 관련된 여러 측면을 논의했습니다. 이제 다가올 Electra와 Prague 업그레이드의 변경 사항에 초점을 맞추고 이를 자세히 설명할 때입니다.
이더 2.0 "지분 증명" 하드 포크 의 역사는 복잡합니다. 기존 실행 계층에 비콘 계층을 추가하여 시작했는데, 이를 통해 실행 계층이 작업 증명을 유지하는 동안 지분 증명 합의가 시작되었습니다(Phase0 및 Altair 하드 포크). 이후 벨라트릭스 하드 포크 에서 PoS가 완전히 활성화되었습니다(출금은 활성화되지 않았습니다). 그런 다음 Capella 하드 포크 출금이 허용되어 검증자 수명 주기가 완료되었습니다. 최근의 하드 포크 Deneb은 Dencun(Deneb/Cancun) 업그레이드의 일부로, 증명을 위한 시간 창 포함, 자발적 종료 처리, 검증자 교체 한도 등 비콘 체인 매개변수에 대한 사소한 개정 사항을 도입했습니다. Dencun의 주요 변경 사항은 실행 계층에서 발생했으며, 블롭 트랜잭션, 블롭 가스, 블롭에 대한 KZG 커밋을 도입하고 SELFDESTRUCT 작업을 더 이상 사용하지 않습니다.
이제 프라하/일렉트라(일명 펙트라) 하드 포크 실행 및 컨센서스 레이어 에 중요한 업그레이드를 도입합니다. Lido 프로젝트의 감사 으로서 우리는 주로 이 하드 포크 의 합의 및 스테이킹 관련 변경 사항에 집중하고 있습니다. 그러나 프라하의 실행 계층 변경 사항은 이더 네트워크와 검증자에 영향을 미치는 중요한 기능이 포함되어 있으므로 무시할 수 없습니다. 이러한 변경 사항의 세부 사항을 살펴보겠습니다.
Pectra에 대한 개략적인 개요
일렉트라는 비콘 계층에 다양한 기능을 도입했습니다. 주요 업데이트 내용은 다음과 같습니다.
- 검증자가 32~2048 ETH의 유효 잔액 가질 수 있도록 허용합니다(고정된 32 ETH 대신).
- 검증자가 보조 "인출" 자격 증명을 통해 종료를 시작할 수 있도록 허용합니다(더 이상 활성 검증자 키가 필요하지 않음).
- 비콘 계층이 Eth1 입금을 처리하는 방식을 변경했습니다(더 이상 입금 계약에서 이벤트를 구문 분석하지 않음).
- 비콘 계층에서 일반 Eth1 계약의 요청을 처리하기 위한 새로운 일반 프레임 추가합니다(Electra 이전에 예치금을 관리했던 방식과 유사).
동시에 프라하는 실행 계층에 다음과 같은 변경 사항을 도입했습니다.
- zkSNARK 증명을 검증하기 위한 BLS12-381 곡선을 지원하는 새로운 사전 컴파일된 계약입니다(인기 있는 BN254 곡선 외에도).
- 최대 8192개의 과거 블록 해시를 저장하고 액세스하기 위한 새로운 시스템 계약(무상태 클라이언트에 유용)
- 블록 크기를 줄이고 프로젝트에서 콜데이터 집약적 작업(롤업 등)을 Dencun에서 도입된 blob으로 마이그레이션하도록 장려하기 위해 콜데이터 가스 비용을 늘립니다.
- Eth1 블록당 더 많은 수의 blob을 지원하고 해당 blob을 읽을 수 있는 API를 제공합니다.
- EOA(외부 소유 계정)가 자체 계정 코드를 가질 수 있도록 하면 EOA가 수행할 수 있는 작업(예: 멀티콜 수행 또는 다른 주소로 실행 위임)이 크게 확장됩니다.
추가 논의를 위해 관련 이더 개선 제안(EIP)을 참조해 보겠습니다.
- EIP-7251: MAX_EFFECTIVE_BALANCE 증가
- EIP-7002: 실행 계층 트리거 가능 종료
- EIP-6110: 검증자를 위한 온체인 입금
- EIP-7549: 증명에서 위원회 인덱스 이동
- EIP-7685: 일반 실행 계층 요청
- EIP-2537: BLS12-381 곡선 연산 사전 컴파일
- EIP-2935: 상태에 있는 과거 블록 해시를 저장합니다.
- EIP-7623: 통화 데이터 비용 증가
- EIP-7691: 블롭 처리량 증가
- EIP-7840: EL 구성 파일에 Blob 스케줄링 추가
- EIP-7702: EOA 계정 코드 설정
이러한 EIP 중 일부는 주로 합의(비콘) 계층과 관련이 있고, 다른 EIP는 실행 계층과 관련이 있습니다. 일부는 두 계층을 모두 포괄하는데, 입금 및 출금과 같은 특정 작업에는 합의 계층과 실행 계층 간의 동기화된 변경이 필요하기 때문입니다. 이러한 상호 의존성으로 인해 Electra와 Prague를 분리하는 것은 비현실적이므로 각 EIP를 차례로 검토하여 각 사례에서 영향을 받는 이더 구성 요소를 지정하겠습니다.
EIP-7251: MAX_EFFECTIVE_BALANCE 증가
참고문헌: EIP-7251
이더 의 지분증명을 준비하기 위한 첫 번째 Phase 0 하드 포크 이후, 일렉트라 이전까지 검증자의 최대 유효 잔액 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를 보유한 1명의 검증자와 동일합니다. 또한 여러 개의 활성 검증자 키는 동일한 Eth1 출금 자격 증명을 가질 수 있으므로 모든 보상을 단일 ETH 주소로 클레임 수 있으며 보상 풀링과 관련된 가스 비용을 피할 수 있습니다. 그러나 대량 키를 관리하려면 추가적인 관리 비용이 발생합니다.
검증자의 잔액 집계하는 기능은 새로운 유형의 실행 계층 요청을 추가합니다. 예전에는 입금과 출금이 있었죠. 이제 또 다른 유형인 집계 요청이 있습니다. 두 개의 검증기를 하나로 병합합니다. 작업 요청에는 소스 검증자의 공개 키와 대상 공개 키가 포함되며 입금 및 출금과 유사하게 처리됩니다. 집계자에도 입금 및 출금과 마찬가지로 보류 중인 요청과 잔액 변경 한도가 있습니다.
요약하자면:
- 소규모 독립 검증자의 경우 Electra는 유효 잔액(및 보상)을 자동으로 늘리는 기능을 제공합니다. 이전에는 32 ETH를 초과하는 잉여금은 클레임 만 가능했지만, Electra 이후에는 이 잉여금이 결국 실질 잔액 에 반영되게 되었습니다. 그러나 효과적인 잔액 spec.effective_balance_increment(1 ETH)의 배수로만 증가할 수 있습니다. 즉, 다음 "1 ETH 경계"에 도달한 후에만 증가가 발생합니다.
- 대규모 독립 검증자의 경우 Electra는 여러 개의 활성 검증자 키를 하나로 통합하여 관리를 상당히 단순화합니다. 이것이 게임 체인저는 아니지만 1x2048 스테이킹 운영하는 것은 의심할 여지 없이 64x32 스테이킹 관리하는 것보다 훨씬 간단합니다.
- 리퀴드 스테이킹 스테이킹 사용자로부터 수집하여 검증자들에게 분배하는 유동적 지분 공급자의 경우, Electra는 스테이킹 분배 방식에 더 많은 유연성을 제공하지만, 고정된 32 ETH 실질 잔액 기준으로 검증자 회계를 심각하게 리팩토링해야 합니다.
또 다른 중요한 주제는 검증자 과거 데이터와 이익 추정치인데, 이는 리스크 과 보상을 평가하려는 새로운 참여자에게 특히 관련이 있습니다. Electra 이전(이 글을 쓰는 시점)에는 32 ETH 한도(실제로는 최소 또는 최대)로 인해 과거 데이터에 균일성이 발생했습니다. 모든 검증자는 동일한 유효 잔액, 보상, 개별 슬래싱 페널티, 블록 제안 빈도 및 기타 지표를 갖습니다. 이러한 균일성 덕분에 이더 통계적 이상치 없이 합의 메커니즘을 테스트하고, 이를 통해 네트워크 동작에 대한 귀중한 데이터를 수집할 수 있습니다.
일렉트라 이후 스테이킹 분포가 상당히 변경될 것입니다. 대규모 검증자는 블록 제안과 동기화 위원회에 더 자주 참여하고, 슬래싱 이벤트에서 더 큰 패널티를 받으며, 지연 슬래싱, 활성화 대기열, 종료 대기열에 더 큰 영향을 미칩니다. 이것이 데이터 집계에 어려움을 겪을 수 있지만 이더 의 합의는 비선형 계산이 최소화되도록 보장합니다. 유일한 비선형 구성 요소는 sqrt(total_effective_balance)를 사용하여 기본 보상을 계산하는 것으로, 이는 모든 검증자에 적용됩니다. 이는 검증자 보상과 슬래싱이 여전히 "1 ETH당" 기준으로 추산될 수 있음을 의미합니다(또는 더 정확히 말해서, 향후 변경될 수 있는 spec.effective_balance_increment를 기준으로 추산될 수 있음).
자세한 내용은 검증자 동작에 관한 이전 기사를 참조하세요.
EIP-7002: 트리거 가능한 실행 계층 종료
참고문헌: EIP-7002
이더 의 모든 검증자에는 활성 키와 인출 키라는 두 개의 키 쌍이 있습니다. 활성 공개 BLS 키는 비콘 체인에서 검증자의 기본 ID 역할을 하며 블록 서명, 증명, 슬래싱, 위원회 집계 동기화 및(이 EIP 이전에는) 자발적 종료(지연 후 검증자의 합의 종료를 시작하기 위해)에 사용됩니다. 두 번째 키 쌍("인출 자격 증명")은 다른 BLS 키 쌍이거나 일반 Eth1 계정(개인 키 및 주소)이 될 수 있습니다. 현재 ETH 주소로 클레임 활성화된 BLS 개인 키로 서명된 출금 메시지가 필요합니다. 이 EIP는 변경 사항을 만듭니다.
실제로 이 두 가지(활성 및 인출) 키 쌍의 소유자는 서로 다를 수 있습니다. 검증자의 활성 키는 검증 업무를 담당합니다. 즉, 서버를 실행하고, 서버를 계속 가동하고, 기타 작업을 담당합니다. 반면 스테이킹 바우처는 일반적으로 보상을 받고 자금을 책임지는 스테이킹 소유자가 관리합니다. 현재는 스테이킹 인증서를 관리하는 지분 소유자만이 검증자의 종료를 시작할 수 없으며, 보상 클레임 가능합니다. 이런 상황에서는 검증자의 활성 키 소유자가 검증자의 잔액 효과적으로 인질로 잡을 수 있습니다. 검증자는 종료 메시지에 "사전 서명"하여 스테이킹 소유자에게 제공할 수 있지만 이러한 해결 방법은 이상적이지 않습니다. 또한, 클레임 과 종료 모두 현재 전용 API를 통해 비콘 계층 검증자와 상호 작용이 필요합니다.
최적의 해결책은 스테이킹 소유자가 정기적인 스마트 계약 호출을 통해 종료 및 인출 작업을 모두 수행할 수 있도록 하는 것입니다. 여기에는 표준 Eth1 서명 확인이 포함되어 운영이 크게 간소화됩니다.
이 EIP를 통해 스테이킹 소유자는 표준 거래를 ETH 주소에서 전용 스마트 계약으로 보내 인출 및 종료를 트리거할 수 있습니다(기존의 "예금" 계약을 사용하는 입금 프로세스와 유사). 클레임(또는 충분한 스테이킹 제거된 경우 종료) 프로세스는 다음과 같습니다.
- 스테이킹 시스템의 "인출" 계약에 인출 요청("인출" 요청)을 보냅니다.
- 이 계약은 잠재적인 악의적 공격을 완화하기 위해 특정 수수료(ETH)를 부과하며, EIP-1559와 유사하게 요청 대기열이 바쁠 때 수수료가 증가합니다.
- 해당 계약은 "입금" 출금/퇴장 요청을 저장소에 저장합니다.
- 블록이 비콘 계층에 제안되면 대기 중인 "인" 출금/퇴장 요청이 저장소에서 검색됩니다.
- 비콘 계층은 "수신" 요청을 처리하고, 활성 검증자의 잔액 과 상호 작용하고, 검증자 종료를 예약하고, "출금" 인출 요청을 형성합니다.
- "아웃" 출금 요청은 실행 계층에서 처리되고 스테이킹 ETH를 받습니다.
입금은 Eth1 블록에서 트리거된 후 "보류" 입금 대기열을 통해 비콘 계층으로 "이동"되는 반면, 출금은 다른 방식을 따릅니다. 이들은 비콘 계층(CLI를 통해)에서 트리거된 다음 Eth1 블록으로 "이동"됩니다. 이제 두 시나리오 모두 동일한 일반 프레임(아래 설명)를 통해 작동합니다. 즉, Eth1 계층에서 요청을 만들고, "보류"된 입금/인출/병합 대기열을 처리하고, 이를 비콘 계층에서 처리합니다. 인출과 같은 "출력" 작업의 경우 출력 대기열도 처리되고 그 결과는 Eth1 블록에 "정산"됩니다.
이 EIP를 통해 스테이킹 검증자 CLI와 직접 상호 작용하거나 검증자 인프라에 액세스하지 않고도 일반 ETH 거래를 사용하여 검증자를 클레임 하고 종료할 수 있습니다. 이를 통해 특히 대규모 스테이킹 의 경우 스테이킹 작업이 크게 간소화됩니다. 이제 활성 검증자의 키만 유지 관리하면 되므로 검증자 인프라를 거의 완전히 격리할 수 있으며, 모든 스테이킹 작업은 다른 곳에서 처리할 수 있습니다. 이를 통해 독립적인 스테이킹 활성 검증자의 조치를 기다릴 필요성이 없어지고 커뮤니티 스테이킹 모듈과 같은 Lido 서비스의 오프체인 부분이 크게 간소화됩니다.
따라서 이 EIP는 스테이킹 작업을 Eth1 계층으로 완전히 마이그레이션하여 인프라 보안 리스크 크게 줄이고 독립적인 스테이킹 이니셔티브의 탈중앙화 향상시켜 스테이킹 작업을 "완료"합니다.
EIP-6110: 검증자 입금의 온 온체인 프로비저닝
참고문헌: EIP-6110
현재, 입금은 시스템의 "입금" 계약에서 이벤트를 통해 구현됩니다(이전 게시물에서 자세히 설명). 해당 계약은 ETH와 검증자 자격 증명을 수락하고 "Deposit()" 이벤트를 내보내며, 이 이벤트는 구문 분석되어 비콘 계층에서 입금 요청으로 변환됩니다. 이 시스템에는 여러 가지 단점이 있습니다. 비콘 체인 수준에서 eth1data에 대한 투표가 필요하므로 상당한 지연 시간이 발생합니다. 또한, 비콘 계층은 실행 계층에 쿼리를 보내야 하므로 복잡성이 더욱 커집니다. 이러한 문제는 EIP에서 자세히 논의됩니다. 이러한 문제들을 많이 겪지 않고도 더 간단한 방법은 지정된 위치의 Eth1 블록에 직접 입금 요청을 포함하는 것입니다. 이 메커니즘은 이전 EIP에서 설명한 인출 프로세스와 유사합니다.
이 EIP에서 제안된 변화는 유망합니다. eth1data 처리를 이제 완전히 제거할 수 있으므로 Eth1 측에서 이벤트가 발생하고 비콘 계층에 예치금이 포함되는 사이에 폴링이나 긴 지연(현재 약 12시간)이 더 이상 필요하지 않습니다. 또한 입금 계약의 스냅샷을 찍는 논리도 제거됩니다. 이 EIP는 입금 처리를 간소화하고 위에 설명된 출금 처리 체계와 일치시킵니다.
스테이킹 와 검증자의 경우, 이러한 변경으로 인해 입금과 검증자 활성화 사이의 지연 시간이 크게 줄어듭니다. 검증자가 줄어들면 필요한 보충도 더 빨리 이루어집니다.
이 EIP에 대해 더 말할 것은 없지만, 구식 논리를 제거하고 프로세스를 단순화하며 관련된 모든 사람에게 더 나은 결과를 만들어낸다는 것입니다.
EIP-7685: 일반 실행 계층 요청
참고문헌: EIP-7685
이 EIP는 예금/인출/병합과 관련된 처음 3개의 EIP보다 먼저 제안되어야 했는데, 그렇지 않으면 해당 EIP의 기반을 마련하기 때문입니다. 그러나 여기서는 Eth1(실행)과 Beacon(합의) 체인 간에 전용 데이터를 지속적으로 이동해야 할 필요성이 커지고 있음을 강조하기 위해 포함되었습니다. 이 EIP는 두 계층 모두에 영향을 미쳐 일반 ETH 거래로 인해 발생하는 요청 처리를 더욱 효율적으로 만듭니다. 현재 우리는 다음을 관찰합니다.
- Eth1 블록의 입금 이벤트는 처리를 위해 비콘 블록으로 "이동"됩니다.
- 비콘 블록에서 출금 요청(CLI 사용)은 처리를 위해 Eth1 블록으로 "이동"됩니다.
- 검증자 병합을 처리해야 하는데, 이는 Eth1->Beacon 요청이기도 합니다.
이 세 가지 작업은 실행 계층과 비콘 계층 간을 전환할 때 다양한 유형의 요청을 일관되게 처리하는 것이 필요함을 보여줍니다. 또한, 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 하드 포크 로 도입된 대규모 블록에 대한 KZG의 약속도 페어링을 사용하여 블록 약속을 확인합니다.
스마트 계약에서 BLS 서명이나 zkSNARK 증명을 검증하려면 이러한 "페어링"을 계산해야 하는데, 이는 계산적으로 매우 비쌉니다. 이더 이미 BN254 곡선 연산(EIP-196 및 EIP-197)을 위한 사전 컴파일된 계약이 있습니다. 그러나 BLS12-381 곡선(현재는 더 안전하고 널리 사용되는 것으로 간주됨)은 아직 사전 컴파일로 구현되지 않았습니다. 이러한 사전 컴파일 없이 스마트 계약에서 페어링 및 기타 곡선 연산을 구현하려면 여기에 표시된 것처럼 대량 계산이 필요하고 막대한 양의 가스(약 10^5~10^6 가스)가 소모됩니다.
이 EIP는 많은 잠재적 응용 분야, 특히 BLS12-381 곡선을 기반으로 한 저렴한 BLS 서명 검증 분야의 문을 열어줍니다. 이를 통해 다양한 목적에 맞춰 임계값 체계를 구현하는 것이 가능해졌습니다. 앞서 언급했듯이, 이더 검증자는 이미 BLS12-381 기반 서명을 사용하고 있습니다. 이 EIP를 통해 표준 스마트 계약은 이제 통합된 검증자 서명을 효율적으로 검증할 수 있습니다. BLS 서명은 블록체인에서 널리 사용되므로 이를 통해 합의 증명과 네트워크 간 자산 브리징이 간소화될 수 있습니다. 임계값 BLS 서명 자체를 사용하면 투표, 탈중앙화 형 난수 생성, 다중 서명 등을 위한 여러 가지 효율적인 임계값 체계를 구성할 수 있습니다.
더 저렴한 zkSNARK 증명 검증을 통해 대량 응용 프로그램이 가능해질 것입니다. 현재 많은 zkSNARK 기반 솔루션은 높은 증명 검증 비용으로 인해 어려움을 겪고 있으며, 이로 인해 특정 프로젝트가 거의 실행 불가능해지고 있습니다. 이 EIP는 그것을 바꿀 수 있는 잠재력을 가지고 있습니다.
EIP-2935: 상태에 있는 과거 블록 해시를 저장합니다.
참고문헌: EIP-2935
이 EIP는 8192개(약 27.3시간)의 과거 블록 해시를 블록체인 상태에 저장하여 상태 비저장 클라이언트(예: 롤업)와 스마트 계약에 대한 확장된 기록을 제공하는 것을 제안합니다. 이 제안은 기존 BLOCKHASH 명령어의 동작을 유지하고, 블록 수를 256개로 제한하는 동시에, 과거 해시를 저장하고 검색하도록 특별히 설계된 새로운 시스템 계약을 도입하는 내용을 담고 있습니다. 이 계약은 실행 계층이 블록을 처리할 때 set() 작업을 수행합니다. get() 메서드는 누구나 접근할 수 있으며 링 버퍼에서 원하는 블록 해시를 검색합니다.
현재 EVM에서 과거 블록 해시를 참조하는 것이 가능하지만, 액세스는 최근 256개 블록(약 50분)으로 제한됩니다. 그러나 이전 블록 데이터에 액세스하는 것이 중요한 경우도 있는데, 특히 크로스체인 애플리케이션(이전 블록의 데이터를 증명해야 함)과 주기적으로 초기 블록 해시에 액세스해야 하는 상태 비저장 클라이언트의 경우가 그렇습니다.
이 EIP는 롤업 및 크로스체인 애플리케이션에서 사용할 수 있는 시간 범위를 확장하여 외부에서 데이터를 수집하지 않고도 EVM에서 직접 과거 데이터에 액세스할 수 있게 해줍니다. 결과적으로 이러한 솔루션은 더욱 견고하고 지속 가능해졌습니다.
EIP-7623: 통화 데이터 비용 증가
참고문헌: EIP-7623
calldata 비용은 트랜잭션 페이로드의 사용 가능한 크기를 조절하며 어떤 경우에는 커질 수 있습니다(예: 큰 배열이나 바이너리 버퍼를 인수로 전달하는 경우). 중요한 calldata 사용은 주로 롤업으로 인해 발생하며, 롤업은 현재 롤업 상태를 포함하는 페이로드를 calldata를 통해 전송합니다.
롤업을 위해서는 대용량의 입증 가능한 이진 데이터를 블록체인에 도입하는 것이 중요합니다. Dencun(Deneb-Cancun) 업그레이드는 이러한 사용 사례에 대한 중요한 혁신인 블롭 트랜잭션(EIP-4844)을 도입합니다. Blob 거래에는 전용 "blob" 가스 요금이 있으며 본문은 일시적으로 저장되는 반면 암호화 증명(KZG 커밋먼트)은 해시와 함께 컨센서스 레이어 에 통합됩니다. 따라서 blob은 calldata를 사용하여 데이터를 저장하는 것보다 롤업에 더 나은 솔루션을 제공합니다.
롤업이 데이터를 블롭으로 옮기도록 장려하는 것은 "당근과 채찍" 접근 방식을 통해 달성될 수 있습니다. 감소된 블롭 가스 수수료는 "당근" 역할을 하고, 이 EIP는 콜 데이터 비용을 증가시켜 "레버" 역할을 하여 거래에서 과도한 데이터 저장을 억제합니다. 이 EIP는 블록당 허용되는 최대 블롭 수를 늘리는 다음 EIP-7691(블롭 처리량 증가)을 보완합니다.
EIP-7691: 블롭 처리량 증가
참고문헌: EIP-7691
Blob은 이전 Dencun 하드 포크 에서 도입되었으며, "블록당" Blob의 최대 개수와 목표 개수에 대한 초기 값은 보수적인 추정치였습니다. 이는 검증자 노드 간에 대용량 바이너리 객체의 전파를 p2p 네트워크가 어떻게 처리할지 예측하는 데 있어 복잡성이 있기 때문입니다. 이전 구성이 좋은 것으로 입증되었으므로 이제 새로운 값을 테스트하기에 적절한 시기입니다. 이전에는 블록당 블롭의 목표/최대 개수가 3/6으로 설정되었습니다. 현재 이러한 제한은 각각 6/9로 상향 조정되었습니다.
이전 EIP-7623(호출 데이터 비용 증가)과 결합하면 이러한 조정으로 인해 롤업이 호출 데이터에서 블롭으로 데이터를 이동하도록 더욱 유도됩니다. 최적의 블롭 매개변수에 대한 검색은 아직 진행 중입니다.
EIP-7840: EL 구성 파일에 Blob 스케줄링 추가
참고문헌: EIP-7840
이 EIP는 블록당 대상 및 최대 블롭 수(앞서 논의)와 baseFeeUpdateFraction 값을 이더 실행 계층(EL) 구성 파일에 추가하는 것을 제안합니다. 또한 클라이언트가 Node API를 통해 이러한 값을 검색할 수 있습니다. 이 기능은 특히 블롭 가스 요금을 추정하는 것과 같은 작업에 유용합니다.
EIP-7702: EOA 계정 코드 설정
참고문헌: EIP-7702
이는 이더 사용자에게 상당한 변화를 가져올 매우 중요한 EIP입니다. 알다시피, EOA(외부 소유 계좌)는 코드를 가질 수 없지만 거래 서명(tx.origin)은 제공할 수 있습니다. 이와 대조적으로 스마트 계약은 바이트코드를 가지고 있지만, "그것"에 직접 서명을 적극적으로 요청할 수 없습니다. 추가적이고 자동화되고 검증 가능한 논리가 필요한 모든 사용자 상호작용은 현재 원하는 작업을 수행하기 위해 외부 계약을 호출하는 방식으로만 가능합니다. 하지만 이 경우 외부 계약이 후속 계약의 msg.sender가 되어, 해당 호출은 "사용자가 아닌 계약으로부터의 호출"이 됩니다.
이 EIP는 새로운 SET_CODE_TX_TYPE=0x04 트랜잭션 유형을 도입합니다(이전에는 0x1 트랜잭션, Berlin 및 EIP-1559 업그레이드의 새로운 0x02 트랜잭션, Dencun에서 도입된 0x03 blob 트랜잭션이 있었습니다). 이 새로운 거래 유형을 사용하면 EOA 계좌에 대한 코드를 설정할 수 있습니다. 실제로 이를 통해 EOA는 자체 EOA 계정의 컨텍스트 내에서 외부 코드를 실행할 수 있습니다. 외부 관점에서 보면, 거래 중에 EOA는 외부 계약에서 코드를 "빌려" 실행하는 것처럼 보입니다. 기술적으로 이는 EOA 주소의 "코드" 저장소에 특별한 권한 부여 데이터 튜플을 추가하여 달성됩니다(이 EIP 이전에는 EOA의 "코드" 저장소가 항상 비어 있었습니다).
현재 이 EIP에서 제안하는 새로운 0x04 트랜잭션 유형에는 다음 배열이 포함되어 있습니다.
인증 목록 = [[체인 ID, 주소, 논스, y_패리티, r, s], ...]
각 요소를 통해 계정은 지정된 주소(마지막 유효 승인 항목)의 코드를 사용할 수 있습니다. 이러한 거래를 처리할 때, 주어진 EOA의 코드는 특별한 0xef0100 || 주소 값(23바이트)으로 설정됩니다. 여기서 주소는 필요한 코드의 계약을 가리키고, ||는 연결을 의미하며, 0xef0100은 일반 스마트 계약이 포함할 수 없는 특별한 마법 값을 의미합니다(EIP-3541에 따라). 이 마법의 값은 이 EOA가 일반적인 계약으로 취급될 수 없고 일반적인 계약이라고 불릴 수 없음을 보장합니다.
이 EOA가 거래를 시작하면, 지정된 주소는 이 EOA의 컨텍스트에서 해당 코드를 호출하는 데 사용됩니다. 이 EIP의 전체적인 구현 세부 사항은 아직 알려지지 않았지만, 상당한 변화를 가져올 것임은 확실합니다.
가장 큰 영향 중 하나는 EOA에서 직접 멀티콜을 걸 수 있는 기능입니다. 멀티콜은 DeFi에서 지속적인 트렌드이며, 많은 프로토콜이 이 기능을 강력한 도구로 제공합니다(예: Uniswap V4, Balancer V3, Euler V2). 이 EIP를 통해 이제 EOA에서 직접 여러 통화를 걸 수 있습니다.
예를 들어, 이 새로운 기능은 DeFi에서 흔히 발생하는 문제, 즉 두 개의 별도 거래를 필요로 하는 approved() + anything()의 비효율성을 해결합니다. 이 EIP는 일반적인 "사전 승인" 논리를 허용하여 approved(X) + deposit(X)와 같은 작업을 단일 트랜잭션에서 수행할 수 있습니다.
EOA를 대신하여 거래 실행을 위임할 수 있는 또 다른 이점은 후원 개념입니다. 스폰서십은 새로운 사용자가 이더 에 참여하는 데 도움을 주는 자주 논의되고 많은 사람이 원하는 기능입니다.
EOA와 관련된 프로그래밍 가능한 로직은 보안 제한 구현, 지출 한도 설정, KYC 요구 사항 적용 등 많은 가능성을 열어줍니다.
물론, 이러한 변화는 많은 디자인 문제를 야기합니다. 한 가지 문제는 chain_id를 사용하는 것인데, 이는 서명에 포함되었는지 여부에 따라 동일한 서명이 여러 네트워크에서 유효한지 여부를 결정합니다. 또 다른 복잡한 문제는 객체 코드의 주소를 사용할지, 실제 바이트코드를 내장할 것인지 선택하는 것입니다. 두 가지 접근 방식에는 각각 고유한 특징과 한계가 있습니다. 또한, nonce의 사용은 권한이 "다목적"인지 "단일 목적"인지 정의하는 데 중요한 역할을 합니다. 이러한 요소는 서명의 대량 무효화 및 사용 편의성과 같은 측면을 포함하여 기능 및 보안 문제에 영향을 미칩니다. 비탈릭은 토론에서 이러한 질문을 제기했으며(여기) 더 탐구해 볼 만한 가치가 있습니다.
이 변경 사항은 이더 의 보안 메커니즘인 tx.origin에 영향을 미칠 것이라는 점에 유의해야 합니다. 이 EIP 구현에 대한 더 자세한 정보가 필요하지만 require(tx.origin == msg.sender)의 동작이 변경될 것으로 보입니다. 이러한 확인 방법은 msg.sender가 계약자가 아닌 EOA인지 확인하는 가장 신뢰할 수 있는 방법입니다. EXTCODESIZE(계약인지 확인하기 위한)를 검사하는 것과 같은 다른 접근 방식은 보통 실패하며, 우회가 가능합니다(예: 생성자를 호출하거나 트랜잭션 후 미리 정의된 주소에 코드를 배포). 이러한 검사는 재진입 및 플래시 론(Flash loan) 공격을 차단하는 데 사용되지만 외부 프로토콜과의 통합을 방해하기 때문에 이상적이지 않습니다. 이 EIP 이후로는 안정적인 require(tx.origin == msg.sender) 검사조차 더 이상 사용되지 않는 것 같습니다. "EOA"와 "계약"의 구분이 더 이상 적용되지 않으므로 프로토콜은 이러한 검사를 제거하여 적응해야 합니다. 이제 모든 주소에 관련 코드가 있을 수 있습니다.
기존 EOA와 스마트 계약 간의 구분이 점점 모호해지고 있습니다. 이 EIP는 이더 TON과 같은 설계에 더욱 가깝게 만들어 모든 계정이 본질적으로 실행 가능한 코드가 되도록 합니다. 프로토콜과의 상호작용이 더욱 복잡해짐에 따라, 프로그래밍 가능한 논리를 사용하여 최종 사용자 경험을 개선하는 것은 이러한 진화의 자연스러운 과정입니다.
결론적으로
프라하/일렉트라(펙트라) 업그레이드는 2025년 3월로 예정되어 있습니다. 가장 주목할 만한 계획된 변경 사항은 다음과 같습니다.
- 가변 검증자 유효 스테이킹, 최대 2048 ETH, 이는 스테이킹 분배, 검증자 일정을 크게 변경하고 더 작은 스테이킹 집계하여 대규모 스테이킹 공급자의 관리를 간소화합니다.
- 실행 계층과 컨센서스 레이어 간의 상호작용을 개선하고, Eth1 실행 블록과 비콘 체인 블록 간의 데이터 교환을 간소화합니다. 이를 통해 입금, 활성화, 클레임 및 퇴장이 크게 간소화되고 이러한 프로세스가 가속화되며 컨센서스 레이어 과 실행 계층 간의 추가 상호 작용을 위한 기반이 마련됩니다.
- 새로운 "페어링 친화적" BLS12-381 사전 컴파일을 통해 스마트 계약에서 직접 저렴한 BLS 서명 및 zkSNARK 검증 지원
- Blob 트랜잭션 임계값을 높이고 호출 데이터 비용을 늘려 롤업이 Blob 트랜잭션을 채택하도록 장려합니다.
- EOA가 프로그래밍 가능한 계정으로 작동하도록 하여 다중 통화, 스폰서십 및 기타 고급 기능을 제공합니다.
보시다시피 Pectra는 스테이킹 및 컨센서스 레이어 과 실행 계층에서 최종 사용자 경험에 상당한 영향을 미칩니다. 아직 개발이 진행 중이어서 이 단계에서는 코드를 통해 모든 변경 사항을 자세히 분석할 수 없지만, 향후 문서에서 이러한 업데이트에 대해 다룰 예정입니다.
