EIP-7691: 블롭 처리량 증가
EIP-7691: 블롭 처리량 증가 /ul>
이러한 EIP 중 일부는 주로 합의(비콘) 계층과 관련되어 있고, 다른 일부는 실행 계층과 관련되어 있습니다. 특정 작업(예: 입금 및 출금)은 합의 레이어와 실행 레이어 간에 동기화된 변경이 필요하기 때문에 일부는 두 레이어에 걸쳐 있습니다. 이러한 상호의존성 때문에 일렉트라와 프라하를 분리하는 것은 비현실적이므로 각 EIP를 차례로 검토하고 각 경우에 영향을 받는 이더리움 구성 요소를 명시할 것입니다.
EIP-7251: 최대_효과_밸런스 증가
참고: EIP-7251
이더리움 지분 증명을 준비하는 첫 번째 0단계 하드포크 이후 일렉트라까지 검증인의 최대 유효 잔액은 32 ETH로 고정되었습니다. 검증인을 활성화하려면 최소 spec.min_activation_balance(32 ETH)가 필요합니다. 활성화 시 검증자는 이 최대 유효 잔액으로 시작하지만, 이 임계값에 도달하면 유효 잔액을 spec.injection_balance(16 ETH)로 낮추고 퇴출될 수 있습니다. 일렉트라에서는 이 '최소' 로직이 변경되지 않았지만, 이제 spec.max_effective_balance가 2048 ETH로 증가했습니다. 결과적으로 검증자는 32~2048 ETH를 예치하여 활성화할 수 있으며, 이는 모두 유효 잔액에 기여하게 됩니다. 이러한 변화는 "32 ETH- 지분 증명"에서 "지분 증명"으로의 전환을 의미합니다 :)
이 변수 Effective_Balance가 이제 사용됩니다:
블록 제안자가 될 확률을 유효 잔액에 비례하여 증가
동기화 위원회 위원이 될 확률을 유효 잔액에 비례하여 증가
합니다: 왼쪽;">상대적 삭감 및 비활동 패널티 금액 계산의 기초로
앞의 두 활동은 검증인에게 가장 보람 있는 작업입니다. 따라서 일렉트라 이후에는 많은 서약을 한 검증인이 유효 잔액에 비례하여 블록 제안과 동기화 위원회에 더 자주 참여하게 됩니다.
또 다른 영향은 삭감과 관련이 있습니다. 모든 삭감 패널티는 검증인의 유효 잔액에 비례합니다.
"즉시" 및 "지연" 삭감 패널티는 서약이 많은 검증인의 경우 더 큽니다.
"지연" 감액 패널티도 전체 서약에서 "감액" 부분이 더 커지기 때문에 서약이 높은 검증인의 감액 패널티가 더 큽니다.
활성 잔액이 높은 검증인을 보고하는 리포터는 더 많은 비율의 감액된 서약을 받게 됩니다.
일렉트라는 또한 내부 고발자가 검증인의 잔액에서 삭감하여 수령하는 부분을 정의하는 삭감 비율에 대한 변경을 제안합니다.
다음은 무효화 영향입니다. 검증인이 활동 중(증명 또는 제안) 오프라인 상태가 되면 무효 점수가 누적되어 매 주기마다 무효 페널티가 부과됩니다. 이러한 페널티는 검증인의 활성 잔액에 비례하여 부과됩니다.
유효 잔액이 증가함에 따라 검증인의 '교체 한도'도 변경됩니다. "일렉트라 이전" 이더리움에서 검증자는 일반적으로 동일한 유효 잔액을 가졌고, 퇴출 교체 한도는 "한 사이클에 총 공약의 최대 1/65536(spec.churn_limit_quotient)을 퇴출할 수 있다"로 정의되었습니다. 이렇게 하면 동일한 서약을 종료할 수 있는 '고정된' 수의 검증인이 생성됩니다. 그러나 '일렉트라 이후'에는 전체 서약의 상당 부분을 차지하는 소수의 '고래'만이 퇴장하는 경우가 발생할 수 있습니다.
또 다른 고려 사항은 단일 검증인 인스턴스에서 많은 검증인 키의 순환입니다. 현재 대규모 검증자는 대규모 서약을 수용하기 위해 단일 인스턴스에서 수천 개의 검증자 키를 실행하여 32개의 이더리움 부분으로 분할해야 합니다. 일렉트라에서는 더 이상 이러한 동작이 필요하지 않습니다. 재정적인 관점에서 볼 때, 보상과 확률은 서약 금액에 따라 선형적으로 확장되기 때문에 이러한 변화는 거의 영향을 미치지 않습니다. 따라서 각 32 이더리움의 검증인 100명은 3200 이더리움의 검증인 한 명과 동일합니다. 또한, 여러 개의 활성 검증자 키가 동일한 이더1 출금 자격 증명을 가질 수 있으므로 모든 보상을 단일 이더 주소로 출금할 수 있으므로 보상 통합과 관련된 가스 비용을 피할 수 있습니다. 하지만 많은 수의 키를 관리하면 관리 비용이 추가로 발생합니다.
검증자의 잔액을 집계하는 기능은 새로운 유형의 실행 레이어 요청을 추가합니다. 이전에는 입금과 출금만 있었습니다. 이제 또 다른 유형인 집계 요청이 추가됩니다. 이는 두 개의 검증자를 하나로 결합합니다. 작업 요청에는 소스 인증자의 공개 키와 대상 공개 키가 포함되며, 입출금과 유사하게 처리됩니다. 집계를 통해 보류 중인 요청과 잔액 교체도 입출금과 마찬가지로 제한됩니다.
요약:
소규모의 독립 검증인을 위해 일렉트라는 자동으로 유효 잔액을 늘리는 기능을 도입합니다. 잔액(및 보상)을 자동으로 증가시키는 기능을 도입했습니다. 이전에는 32 이더리움을 초과하는 잉여금은 인출만 가능했지만, 일렉트라에서는 이 잉여금이 유효 잔액에 추가됩니다. 단, 유효 잔액은 spec.effective_balance_increment(1 ETH)의 배수만큼만 증가시킬 수 있으며, 이는 다음 "1 ETH 한도"에 도달한 후에만 증가한다는 것을 의미합니다.
대규모 독립 검증인의 경우, 일렉트라는 여러 개의 활성 검증인 키를 하나로 통합할 수 있도록 하여 상당한 관리 간소화를 제공합니다. 이 기능이 획기적인 것은 아니지만, 1x2048 서약을 실행하는 것이 64x32 서약을 관리하는 것보다 훨씬 간단합니다.
사용자로부터 소량의 서약을 모아 검증인에게 분배하는 모바일 서약 제공자의 경우, 일렉트라는 서약 분배 방식에 유연성을 더하지만 고정된 32개의 이더리움 활성 잔액을 기반으로 검증인 회계의 심각한 리팩토링이 필요합니다.
위험과 보상을 평가하려는 신규 참여자에게 특히 중요한 또 다른 주제는 검증자의 과거 데이터와 수익 추정치입니다. 일렉트라 이전(그리고 이 글을 쓰는 현재)32에는 이더리움 상한선(최소 또는 최대, 사실상)으로 인해 과거 데이터에 균일성이 생겼습니다. 유효 잔액, 보상, 개별 컷 페널티, 블록 제안 빈도 및 기타 지표는 모든 검증자에게 동일하게 적용되었습니다. 이러한 균일성 덕분에 이더는 통계적 이상치 없이 합의 메커니즘을 테스트하여 네트워크 행동에 대한 귀중한 데이터를 수집할 수 있었습니다.
일렉트라 이후에는 서약의 분포가 크게 달라질 것입니다. 대규모 검증자는 블록 제안과 동기화 위원회에 더 자주 참여하고, 컷 이벤트에서 더 큰 페널티를 받게 되며, 지연된 컷, 활성화 대기열, 종료 대기열에 더 큰 영향을 미치게 될 것입니다. 이로 인해 데이터 집계에 문제가 발생할 수 있지만, 이더넷의 합의는 비선형 계산이 최소화되도록 보장합니다. 유일한 비선형 구성 요소는 모든 검증인에게 적용되는 기본 보상을 계산하기 위해 sqrt(total_effective_balance)를 사용합니다. 즉, 검증인 보상과 감소는 여전히 '1ETH당' 기준으로(또는 더 정확하게는 향후 변경될 수 있는 spec.effective_balance_increment에 따라) 추정할 수 있습니다.
자세한 내용은 검증인 동작에 대한 이전 게시글을 참조하세요.
EIP-7002: 트리거 가능한 실행 레이어 종료
참조: EIP-7002
참조: EIP-7002
References. align: left;">이더넷의 각 인증자는 활성 키와 인출 키의 두 가지 키 쌍을 가지고 있습니다. 활성 공개 BLS 키는 비콘 체인에서 검증자의 기본 신원 역할을 하며, 이 키 쌍은 블록 서명, 증명, 컷, 동기화 위원회 집계 및 (이 EIP 이전에는) 자발적 철회(지연 후 검증자의 합의 철회를 시작하기 위해)에 사용됩니다. 두 번째 키 쌍("출금 자격증명")은 다른 BLS 키 쌍 또는 일반 Eth1 계정(개인 키와 주소)일 수 있습니다. 이제 이더리움 주소로 출금하려면 활성 BLS 개인 키로 서명된 출금 메시지가 필요합니다. 이 EIP가 변경되었습니다.
실제로는 두 개의 키 쌍(활성 키와 출금 키)의 소유자가 다를 수 있습니다. 인증자의 활성 키는 서버 실행, 서버 가동 및 유지 등 인증 업무를 담당하며, 출금 자격 증명은 일반적으로 보상을 받고 자금에 대한 책임을 지는 플러지 소유자가 관리합니다. 현재는 출금 자격 증명을 제어하는 서약 소유자만 검증인의 출금을 시작할 수 있으며, 보상만 출금할 수 있습니다. 이러한 상황에서는 검증자의 활성 키 소유자가 검증자의 잔액을 '인질'로 효과적으로 보유할 수 있습니다. 검증자는 옵트아웃 메시지에 '사전 서명'을 하고 이를 서약 소유자에게 전달할 수 있지만, 이 해결 방법은 이상적이지 않습니다. 또한, 현재 출금과 탈퇴를 위해서는 전용 API를 통해 비콘 레이어 검증자와 상호작용해야 합니다.
최적의 해결책은 플레지 소유자가 일반 스마트 컨트랙트 호출을 통해 출금과 출금 작업을 모두 수행할 수 있도록 하는 것입니다. 여기에는 표준 이더리움 1 서명 확인이 포함되며 작업이 크게 간소화됩니다.
이 EIP를 사용하면 지분 소유자는 자신의 이더 주소에서 전용 스마트 콘트랙트로 표준 트랜잭션을 전송하여 출금과 출구를 트리거할 수 있습니다("입금" 콘트랙트를 사용하는 기존 입금 프로세스와 유사). 출금(또는 충분한 금액이 제거된 경우 종료) 절차는 다음과 같습니다:
약정자가 출금 요청("인" 요청)을 시스템의 "출금" 컨트랙트로 보냅니다.
컨트랙트는 잠재적인 악의적 공격을 완화하기 위해 특정 수수료(이더리움)를 부과하며, EIP-1559와 마찬가지로 요청 대기열이 바쁠 때 수수료가 증가합니다.
컨트랙트는 출금/탈퇴 요청을 스토리지에 저장합니다.
블록이 비콘 레이어에 제안되면 대기열에 있는 "중인" 출금/탈퇴 요청이 스토리지에서 검색됩니다.
비콘 레이어는 '인' 요청을 처리하고 활성 검증자의 잔액과 상호작용하며 검증자의 출금을 예약한 후 '아웃' 출금 요청을 형성합니다.
'아웃' 출금 요청은 실행 레이어에서 처리되고 청약자는 이더를 받습니다.
입금은 이더1 블록에서 트리거된 작업이며, 이후 '보류' 입금 대기열을 통해 비콘 레이어로 '이동'되지만, 출금은 다른 방식을 따릅니다. CLI를 통해 비콘 레이어에서 트리거된 다음 이더1 블록으로 '이동'됩니다. 이제 두 시나리오 모두 동일한 공통 프레임워크(아래 설명)를 통해 작동합니다. 요청은 이더1 수준에서 생성되고, '보류 중' 입금/출금/병합 대기열에서 처리되며, 비콘 수준에서 처리됩니다. 출금과 같은 '출력' 작업의 경우, 출력 대기열도 처리되고 결과는 Eth1 블록에서 '정산'됩니다.
이 EIP를 사용하면, 검증자 CLI와 직접 상호작용하거나 검증자의 인프라에 액세스하지 않고도 일반 이더 트랜잭션을 사용하여 검증자를 출금하고 종료할 수 있습니다. 이는 특히 대규모 서약 제공자의 경우 서약 운영을 크게 간소화합니다. 이제 활성 검증자의 키만 유지 관리하면 되고 모든 서약 작업은 다른 곳에서 처리할 수 있으므로 검증자의 인프라를 거의 완전히 격리할 수 있습니다. 이는 활성 검증자의 작업을 기다릴 필요성을 없애고 커뮤니티 스테이킹 모듈과 같은 리도 서비스의 오프체인 부분을 크게 간소화합니다.
그 결과, 이 EIP는 서약 작업을 "완료"하고, 이를 이더1 레이어로 완전히 마이그레이션하며, 인프라 보안 위험을 크게 줄이고, 독립적인 서약 이니셔티브의 탈중앙화를 강화합니다.
EIP-6110: 검증자 예치금의 온체인 프로비저닝
참고: EIP-6110
현재, 예치금은 는 시스템의 '예금' 컨트랙트에서 이벤트를 통해 이루어집니다(이전 게시물에서 자세히 설명한 대로). 컨트랙트는 이더와 검증자 자격 증명을 수락하고, 'Deposit()' 이벤트를 발생시킨 다음 비콘 레이어에서 파싱하여 입금 요청으로 변환합니다. 이 시스템에는 여러 가지 단점이 있습니다. 비콘 체인 레이어에서 eth1데이터를 폴링해야 하므로 상당한 지연 시간이 추가됩니다. 또한 비콘 레이어는 실행 레이어를 쿼리해야 하므로 복잡성이 더욱 가중됩니다. 이러한 문제는 EIP에서 자세히 설명합니다. 이러한 많은 문제를 처리할 필요가 없는 더 간단한 접근 방식은 지정된 위치의 이더1 블록에 직접 입금 요청을 포함하는 것입니다. 이 메커니즘은 이전 EIP에서 설명한 출금 처리 흐름과 유사합니다.
이번 EIP에서 제안된 변경 사항은 매우 고무적입니다. 이제 이더1 데이터 처리가 완전히 제거되어 이더1 측의 이벤트와 비콘 레이어의 예금 포함 사이에 폴링이나 긴 지연(현재 약 12시간)이 필요하지 않게 되었습니다. 또한, 예치 계약의 스냅샷 로직도 제거됩니다. 이 EIP는 입금 처리를 간소화하고 위에서 설명한 출금 처리 방식과 일치시킵니다.
예치자와 검증자 모두에게 이러한 변화는 입금과 검증자 활성화 사이의 지연을 크게 줄여줍니다. 검증인이 삭감될 때 필요한 보충도 더 빨라집니다.
이 EIP에 대해서는 오래된 로직을 제거하고, 프로세스를 간소화하며, 관련된 모든 사람에게 더 나은 결과를 창출한다는 점 외에는 더 이상 설명할 것이 없습니다.
EIP-7685: 일반 실행 계층 요청
참조: EIP-7685
이 EIP는 예전에 첫 세 개의 입금/출금/합병 관련 EIP에 포함될 예정이었으며, 해당 EIP의 토대를 마련하기 때문입니다. 그러나 Eth1(실행)과 비콘(합의) 체인 블록(레이어) 사이에서 독점 데이터를 일관되게 이동해야 할 필요성이 커지고 있다는 점을 강조하기 위해 여기에 제시되었습니다. 이 EIP는 두 레이어 모두에 영향을 미치며, 일반 이더리움 트랜잭션으로 트리거된 요청을 보다 효율적으로 처리할 수 있도록 합니다. 현재 저희는 다음과 같이 관찰하고 있습니다.
Eth1 블록의 입금 이벤트는 처리를 위해 비콘 블록으로 '이동'됩니다.
비콘 블록의 출금 요청(CLI 사용)은 처리를 위해 Eth1 블록으로 '이동'됩니다.
검증자 병합도 처리해야 하며, 이 역시 Eth1-& gt; 비콘 요청입니다.
이 세 가지 작업은 실행 계층과 비콘 계층 사이를 전환할 때 다양한 유형의 요청을 일관되게 처리해야 할 필요성을 보여줍니다. 또한, 검증자의 인프라를 서약 관리 인프라로부터 분리하여 보안을 강화할 수 있도록 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 증명 검증. 또한 덴쿤 하드포크로 도입된 대형 블록에 대한 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시간)의 과거 블록 해시를 블록체인 상태에 저장하여 스테이트리스 클라이언트(예: 롤업)와 스마트 컨트랙트에 확장된 기록을 제공할 것을 제안합니다. 이는 블록해시 연산 코드의 현재 동작을 유지하여 256개 블록의 제한을 유지하면서 기록 해시를 저장하고 검색하도록 특별히 설계된 새로운 시스템 컨트랙트를 도입할 것을 제안합니다. 이 컨트랙트는 블록이 실행 수준에서 처리될 때 set() 작업을 수행합니다. 누구나 get() 메서드에 액세스하여 링 버퍼에서 원하는 블록 해시를 검색할 수 있습니다.
현재 EVM에서 과거 블록 해시를 참조하는 것은 가능하지만 가장 최근 256개 블록(약 50분)으로만 접근이 제한됩니다. 그러나 이전 블록의 데이터를 증명해야 하는 크로스체인 애플리케이션과 주기적으로 이전 블록 해시에 액세스해야 하는 스테이트리스 클라이언트를 위해 이전 블록 데이터에 대한 액세스가 중요한 경우가 있습니다.
이 EIP는 롤업 및 크로스체인 앱이 외부에서 수집할 필요 없이 EVM에서 직접 과거 데이터에 액세스할 수 있도록 함으로써 사용 가능한 기간을 연장합니다. 결과적으로 이러한 솔루션은 더욱 견고하고 지속 가능하게 됩니다.
EIP-7623: 콜데이터 비용 증가
참조: EIP-7623
콜데이터 비용은 사용 가능한 트랜잭션 페이로드의 크기를 조절하며, 경우에 따라 상당히 클 수 있습니다(예: 대용량 배열이나 바이너리 버퍼를 인자로 전달할 때). 상당한 콜데이터 사용량은 주로 현재 롤업 상태가 포함된 콜데이터를 통해 페이로드를 전송하는 롤업에 기인합니다.
블록체인에 증명 가능한 대용량 바이너리 데이터를 도입하는 것은 롤업에 매우 중요하며, 덴쿤(Deneb-Cancun) 업그레이드는 이러한 사용 사례에 중요한 혁신인 블롭 트랜잭션을 도입했습니다( 블롭 트랜잭션에는 자체 전용 "블롭" 가스 비용이 있으며, 본체는 임시로 저장되지만 암호화 증명(KZG 커미트먼트)은 해시와 함께 합의 레이어에 통합됩니다. 결과적으로 블롭은 콜데이터를 사용하여 데이터를 저장하는 것보다 롤업에 더 나은 솔루션을 제공합니다.
롤업이 데이터를 블롭으로 옮기도록 장려하는 것은 '당근과 채찍' 접근 방식을 통해 달성할 수 있습니다. 블롭 가스 비용 절감은 '당근'으로 작용하고, 이 EIP는 콜데이터 비용을 높여 트랜잭션의 과도한 데이터 저장을 억제함으로써 '채찍'으로 작용합니다. 이 EIP는 블록당 허용되는 최대 블롭 수를 증가시키는 다음 EIP-7691(블롭 처리량 증가)을 보완합니다.
EIP-7691: 블롭 처리량 증가
참고: EIP-7691
이전의 덴쿤 하드포크 블롭이 도입되었을 때 '블록당' 블롭의 최대 및 목표 개수에 대한 초기 값은 보수적인 추정치였습니다. 이는 P2P 네트워크가 검증자 노드 간에 대규모 바이너리 객체의 전파를 어떻게 처리할지 예측하는 것이 복잡하기 때문입니다. 이전 구성이 잘 작동하는 것으로 입증되었기 때문에 지금이 새로운 값을 테스트하기에 적절한 시기입니다. 이전에는 블록당 목표/최대 블롭 수가 3/6으로 설정되었으나, 이제 이 제한이 각각 6/9로 증가했습니다.
이번 조정은 콜데이터 비용을 증가시킨 이전 EIP-7623과 결합하여 데이터를 콜데이터에서 블롭으로 이동하도록 롤업을 더욱 장려하게 됩니다. 최적의 블롭 매개변수에 대한 탐색은 계속되고 있습니다.
EIP-7840: EL 프로필에 블롭 스케줄링 추가
참조: EIP-7840
이 EIP는 목표 및 최대 '블록당' 블롭 수(앞서 설명한)와 baseFeeUpdateFraction 값을 이더넷 실행 계층(EL) 구성 파일에 추가할 것을 제안합니다. 또한 클라이언트는 노드 API를 통해 이러한 값을 검색할 수 있습니다. 이 기능은 블롭 가스 비용 추정과 같은 작업에 특히 유용합니다.
EIP-7702: EOA 계정 코드 설정
참조: EIP-7702
이것은 매우 중요하며 이더리움 사용자에게 큰 변화를 가져올 매우 중요한 EIP입니다. 아시다시피, EOA(외부 소유 계정)는 코드를 가질 수 없지만 트랜잭션 서명(tx.origin)을 제공할 수 있습니다. 반대로 스마트 콘트랙트는 바이트코드를 가지고 있지만, 직접 서명을 시작할 수는 없습니다. 자동화되고 검증 가능한 추가 로직이 필요한 모든 사용자 상호작용은 현재 외부 콘트랙트를 호출하여 원하는 작업을 수행해야만 수행할 수 있습니다. 그러나 이 경우 외부 컨트랙트가 후속 컨트랙트의 msg.sender가 되어 "사용자가 아닌 컨트랙트의 호출에서" 호출이 이루어집니다.
이 EIP에는 새로운 SET_CODE_TX_TYPE=0x04 트랜잭션 유형이 도입되었습니다(기존 0x1 트랜잭션, 베를린과 EIP-1559 업그레이드의 새로운 0x02 트랜잭션, 덴쿤에 도입된 0x03 블롭 트랜잭션이 있었습니다). 이 새로운 트랜잭션 유형을 통해 EIP-1559에 대한 새로운 트랜잭션을 생성할 수 있습니다. 이 새로운 트랜잭션 유형을 통해 EOA 계정에 대한 코드를 설정할 수 있습니다. 사실상 EOA가 "자체 EOA 계정의 컨텍스트에서" 외부 코드를 실행할 수 있도록 허용합니다. 외부에서 보면 트랜잭션이 진행되는 동안 EOA가 외부 컨트랙트에서 코드를 "빌려와" 실행하는 것처럼 보입니다. 기술적으로 이는 EOA 주소의 '코드' 저장소에 특수 인증 데이터 튜플을 추가함으로써 이루어집니다(이 EIP 이전에는 EOA에 대해 항상 비어 있었음).
현재 이 EIP에서 제안된 새로운 0x04 트랜잭션 유형에는 다음과 같은 배열이 포함되어 있습니다:
authorisation_list = [[chain_id , 주소, nonce, y_parity, r, s], ...]
각 요소는 계정이 지정된 주소(마지막으로 유효한 인증 항목의 코드)를 사용할 수 있도록 허용합니다. 이러한 트랜잭션을 처리할 때 지정된 EOA의 코드는 특수 0xef0100 || 주소 값(23바이트)으로 설정되며, 여기서 주소는 원하는 코드가 있는 컨트랙트를 가리키고 ||는 연결을 나타내며 0xef0100은 일반 스마트 컨트랙트에 포함할 수 없는 특수한 마법 값을 나타냅니다(EIP-3541에 따름). 이 마법 값은 이 EOA를 일반 컨트랙트로 취급할 수 없으며 일반 컨트랙트처럼 호출할 수 없도록 합니다.
이 EOA가 트랜잭션을 시작하면 지정된 주소가 EOA의 컨텍스트에서 적절한 코드를 호출하는 데 사용됩니다. 이 EIP의 전체 구현 세부 사항은 아직 알려지지 않았지만, 상당한 변화를 가져올 것임은 확실합니다.
주요 영향 중 하나는 EOA에서 직접 여러 번 통화(멀티콜)할 수 있는 기능입니다. 멀티콜은 탈중앙 금융의 지속적인 트렌드이며, 많은 프로토콜에서 이 기능을 강력한 도구로 제공합니다(예: 유니스왑 V4, 밸런서 V3 또는 오일러 V2). 이 EIP를 통해 이제 EOA에서 직접 여러 개의 호출을 시작할 수 있습니다.
예를 들어, 이 새로운 기능은 DeFi의 일반적인 문제인 apply() + anything()의 비효율성, 즉 두 개의 개별 트랜잭션을 필요로 하는 문제를 해결합니다. 이 EIP는 승인(X) + 입금(X)과 같은 작업을 단일 트랜잭션으로 처리할 수 있는 일반적인 "사전 승인" 로직을 허용합니다.
EOA를 통해 트랜잭션 실행을 '대신' 위임할 수 있는 또 다른 장점은 스폰서십이라는 개념입니다. 스폰서십은 신규 사용자의 이더리움 입문을 돕기 위해 자주 논의되는 기능으로 많은 관심을 받고 있습니다.
EOA와 관련된 프로그래밍 가능한 로직은 보안 제한 적용, 지출 한도 제한, KYC 요건 적용 등 다양한 가능성을 열어줍니다.
물론 이러한 변화는 여러 가지 설계 문제를 제기하기도 합니다. 한 가지 문제는 서명에 포함 또는 제외 여부에 따라 동일한 서명이 여러 네트워크에서 유효할 수 있는지 여부를 결정하는 chain_id의 사용입니다. 또 다른 복잡한 문제는 객체 코드의 주소를 사용할 것인지, 실제 바이트코드를 포함할 것인지에 대한 선택입니다. 이 두 가지 접근 방식에는 각각 고유한 특성과 한계가 있습니다. 또한 논스의 사용은 권한이 '다목적'인지 '단일 목적'인지를 정의하는 데 중요한 역할을 합니다. 이러한 요소는 대량 무효화 서명 및 사용 편의성과 같은 측면을 포함하여 기능 및 보안 문제에 영향을 미치며, Vitalik은 토론(여기)에서 이러한 문제를 제기했는데, 더 자세히 살펴볼 가치가 있습니다.
이번 변경은 이더의 보안 메커니즘 중 하나인 tx.origin에 영향을 미친다는 점에 주목할 필요가 있습니다. 이 EIP 구현에 대한 자세한 내용은 더 살펴봐야겠지만, require(tx.origin == msg.sender)의 동작이 변경될 것으로 보입니다. 이 검사는 항상 msg.sender가 컨트랙트가 아닌 EOA인지 확인하는 가장 신뢰할 수 있는 방법이었습니다. (컨트랙트인지 확인하기 위해) EXTCODESIZE를 확인하는 등의 다른 방법은 일반적으로 실패하며, 생성자를 호출하거나 트랜잭션 후 미리 정의된 주소에 코드를 배포하는 등 우회할 수 있습니다(예: 생성자 호출). 이러한 검사는 재진입과 플래시 렌딩 공격을 방지하기 위해 사용되지만, 외부 프로토콜과의 통합도 막는다는 점에서 이상적이지 않습니다. 이 EIP 이후에는 신뢰할 수 있는 require(tx.origin == msg.sender) 검사도 더 이상 사용되지 않는 것으로 보입니다. 프로토콜은 이러한 검사를 제거하여 적응해야 할 것입니다. 'EOA'와 '컨트랙트'의 구분이 더 이상 적용되지 않고 모든 주소에 관련 코드가 있을 수 있기 때문입니다.
기존 EOA와 스마트 컨트랙트 사이의 구분은 계속 모호해지고 있습니다. 이 EIP는 이더를 각 계정이 본질적으로 실행 가능한 코드인 TON과 같은 디자인에 더 가깝게 만듭니다. 프로토콜과의 상호작용이 더욱 복잡해짐에 따라 최종 사용자 경험을 개선하기 위해 프로그래밍 가능한 로직을 사용하는 것은 이러한 진화의 자연스러운 부분입니다.
결론
프라하/일렉트라(Pectra) 업그레이드가 2025년 3월에 예정되어 있습니다. 가장 주목할 만한 변경 사항은 다음과 같습니다.
가변 검증인 유효 서약은 최대 2,048 이더로, 서약의 분포와 검증인 일정을 크게 바꾸고 소규모 서약의 관리를 통합하여 단순화할 것입니다. 대규모 서약 제공자의 관리
실행 레이어와 합의 레이어 간의 상호작용을 개선하고 이더1 실행 블록과 비콘 체인 블록 간의 데이터 교환을 단순화합니다. 이는 입금, 활성화, 인출, 출금을 크게 간소화하여 이러한 프로세스의 속도를 높이고 합의 계층과 실행 계층 간의 추가적인 상호작용을 위한 토대를 마련할 것입니다
새로운 "페어링 친화적인" BLS12-381 사전 컴파일을 통해 스마트 컨트랙트에서 직접 저렴한 BLS 서명 지원 및 zkSNARK 검증
블롭 거래 임계값을 높이고 콜데이터 비용을 높여 롤업이 블롭 거래를 채택하도록 장려
EOA를 프로그래밍 가능한 계정으로 만들어 다중 인보케이션, 후원 및 기타 고급 기능을 제공
보시다시피, 펙트라는 서약 및 합의 계층과 실행 계층에서 최종 사용자 경험에 상당한 영향을 미칠 것입니다. 아직 개발이 진행 중이므로 현 단계에서는 코드를 통해 이러한 모든 변경 사항을 자세히 분석할 수는 없지만, 향후 포스팅에서 이러한 업데이트 내용을 다룰 예정입니다.
Anais
Catherine
Kikyo
Weatherly
Alex