후사카 업그레이드의 모든 것

Introduction: 이더리움 재단의 새로운 목표, 그리고 첫 업그레이드

이더리움 재단은 올해 조직 개편과 함께 새로운 비전을 제시했습니다. 그 핵심은 다음 세 가지 목표로 요약됩니다.

1. L1 스케일링: 이더리움 레이어 1의 처리 효율 향상
2. L2 스케일링: 롤업 중심의 확장 구조 고도화
3. UX 개선: 사용자와 개발자가 체감하는 경험의 질적 향상

올해 12월 3일 메인넷에 적용될 후사카(Fusaka) 업그레이드는 이 세 가지 목표를 실제 네트워크 설계에 반영한 첫 번째 종합 업그레이드입니다. 즉, 이번 업그레이드는 단순히 “이더리움을 개선하는 패치”가 아니라, 이더리움이 앞으로 어떤 방향으로 확장성과 접근성을 추구할 것인지를 보여주는 중요한 분기점이라고 볼 수 있습니다.

그렇다면, 후사카는 과연 재단이 내건 이 세 가지 목표인 L1 스케일링, L2 스케일링 및 UX 개선을 얼마나 충실히 구현하고 있을까요? 이 글은 그 질문에 답하기 위해, 후사카 업그레이드에 포함된 모든 EIP의 배경, 해결하려는 문제, 그리고 설계 의도와 방식을 하나씩 자세히 살펴봅니다.

L2 스케일링

후사카 업그레이드가 가장 큰 임팩트를 내는 영역은 L2 스케일링이며, L2 네트워크들은 이에 큰 기대를 걸고 있습니다. 베이스는 후사카 이후 L2 확장성 개선을 기반으로 ‘체인을 두 달 안에 두 배 확장하겠다’는 발표를 하기도 했죠. 어떤 변화가 일어나기에 이러한 이야기가 나오는 걸까요? L2 스케일링의 기본 개념부터 차근차근 살펴보겠습니다.

롤업들은 오프체인에서 트랜잭션을 처리한 후 이더리움 메인넷에 그 결과를 제출합니다. 이때 ‘내가 트랜잭션을 잘 처리했음’을 수학적으로 증명할 수 있어야 합니다. 옵티미스틱이든 ZK이든 상관없이, 그 과정을 위해선 롤업이 처리한 트랜잭션 원본 데이터가 있어야 하죠. 즉, 롤업들은 이더리움에 트랜잭션 원본 전체를 제출합니다(지케이싱크, 스타크넷과 같은 상태 차이 롤업은 트랜잭션 전체가 아니라 각 트랜잭션이 만들어내는 상태 차이만을 제출하기는 하지만, 무언가 큰 크기의 데이터를 제출한다는 상황은 다르지 않습니다).

롤업들은 그럼 이더리움 내 정확히 어디에 데이터를 제출할까요? EVM에는 함수를 호출하는 데에 사용하는 콜데이터(calldata)라는 공간이 있으며, 원래 롤업들은 이 공간에 데이터를 제출했습니다. 그러나 이는 ‘데이터 저장’을 위해 설계된 공간이 아니었기 때문에, 비용이 비싸다는 단점이 있었죠. 이 때문에 롤업들의 트랜잭션은 꽤 비쌌으며, 이더리움 가스비가 높아질 땐 L2 트랜잭션 비용이 1달러가 넘어가기도 했습니다.

이를 해결하기 위해 2024년 이더리움은 데이터 저장 전용 공간을 새로 도입했고, 이를 블롭(blob)이라 이름 붙였습니다. 블롭은 2024년 3월 덴쿤(Dencun) 업그레이드의 EIP-4844를 통해 도입되었으며, 하나의 블롭은 최대 128KB의 데이터를 저장할 수 있도록 설계되었습니다. 참고로 이더리움 블록의 평균 크기가 약 100KB 수준이므로, 블롭 하나만으로도 상당히 큰 공간이라 할 수 있습니다.

덴쿤 업그레이드 당시 이더리움은 네트워크 안정성을 고려해

• 블록 당 평균 3개의 블롭(타깃),
• 최대 6개의 블롭만 허용한다

라는 보수적 설정을 채택했습니다.

또한 블롭 공간의 수수료는 기존 이더리움의 일반 가스 수수료와는 별도의 시장에서 결정됩니다. 이 구조 덕분에 블롭을 제출하는 비용은 일반 트랜잭션에 비해 현저히 저렴해졌고, 그 결과 롤업의 트랜잭션 비용은 트랜잭션당 약 0.005~0.01달러 수준으로 떨어졌습니다. 이는 이전보다 약 50~100배의 비용 절감 효과이며, 이에 따라 L2 사용자 경험 역시 눈에 띄게 개선되었습니다.

하지만 L2 네트워크가 빠르게 늘어나고 트랜잭션 수요가 급증하면서, EIP-4844이 설정한 ‘블록당 3개’라는 타깃 용량은 금세 포화 상태에 도달했습니다. 트랜잭션 양이 조금만 증가해도 블롭 개수가 타깃을 초과했고, 이때 블롭 수수료는 지수적으로 상승했습니다. 그 결과 롤업 내 트랜잭션의 비용은 증가했고, 블롭은 이더리움 L2 스케일링의 병목으로 작용하게 되었습니다.

(덴쿤 이후 블롭스페이스의 포화 | 출처: hildobby dune dashboard)

이 때문에 이더리움은 2025년 5월 펙트라(Pectra) 업그레이드를 통해 블록 당 블롭의 타겟 개수를 3개에서 6개로 100% 증가시키고, 최대 블롭의 개수는 9개로 50% 증가시켰습니다.

(펙트라로 2배 증가한 블롭스페이스 | 출처: hildobby dune dashboard)

이 덕분에 L2들은 한숨 돌릴 수 있게 되었습니다. 그러나 펙트라 업그레이드 이후 다섯 달이 지난 지금, 이더리움의 블롭스페이스는 다시 거의 포화에 이르렀습니다. 라이터(Lighter)와 같이 몇천 TPS를 소화하며 많은 데이터를 올리는 롤업도 새로 출시된데다가, 월드체인 등 기존 롤업의 수요가 크게 증가했기 때문입니다.

(현재 점점 포화에 가까워지는 블롭스페이스 | 출처: hildobby dune dashboard)

그러나 펙트라 업그레이드 때처럼 단순히 블록당 블롭 개수를 늘리는 방식으로는 더 이상 확장을 이어갈 수 없습니다. 블롭의 개수가 많아질수록 블록 전체의 크기가 커지고, 그에 따라 네트워크 리소스가 제한된 노드들은 블록을 다운로드하거나 전파하는 데 더 오랜 시간이 걸리기 때문입니다. 이 과정에서 일부 노드는 제때 블록을 받아보지 못해, 결국 합의 과정에 제대로 참여하지 못하는 상황이 발생할 수 있습니다.

그렇다면 블롭의 개수는 얼마까지가 한계일까요? 결론부터 말하자면, 현재로선 9개가 거의 한계점으로 평가됩니다. 이더리움에서는 매 슬롯마다 블록에 대한 투표가 이루어지며, 각 노드는 슬롯이 시작된 후 4초 이내에 블록을 전파받고 투표를 완료해야 합니다. 그러나 ethPandaOps의 연구에 따르면, 블롭 개수가 9개를 초과할 경우 최악의 상황에서 일부 노드가 4초 내에 블록을 수신하지 못할 가능성이 높아집니다. 이런 상황이 지속되면, 해당 노드들은 블록을 제시간에 전달하거나 받아보지 못해 합의에서 배제될 위험이 생기며, 이는 곧 네트워크의 탈중앙성 약화로 이어질 수 있습니다.

따라서 후사카 업그레이드의 핵심 목표는 블롭 용량을 무작정 늘리지 않고, 더 많은 데이터를 안전하게 처리할 수 있는 구조를 만드는 것에 있습니다. 이를 위해 후사카는 블롭 전파 및 저장 과정의 효율을 높이고, 안전하게 블롭스페이스를 확장하며, 현재의 블롭 수수료 시장의 비효율을 개선하기 위한 여러 EIP를 포함합니다.

후사카 업그레이드에서 L2 스케일링과 관련해 도입되는 주요 EIP는 다음과 같습니다.

• EIP-7594: PeerDAS — Peer Data Availability Sampling
• EIP-7892: Blob Parameter Only Hardforks
• EIP-7918: Blob base fee bounded by execution cost

이 세 가지 제안을 통해, 이더리움 재단은 L2 측면에서 “탈중앙화를 희생하지 않는 확장성 개선”을 달성하려고 하죠. 이제 각 EIP가 어떤 구조적 변화를 만들어내고, L2 스케일링 환경에 어떤 영향을 미치는지 하나씩 살펴보겠습니다.

EIP-7594: PeerDAS를 통한 L2의 8배 스케일링

PeerDAS라고도 불리는 EIP-7594는 후사카에서 가장 큰 변경사항 중 하나로, 롤업들의 가장 큰 병목을 해결해 처리량을 최대 8배 가량 높여주는 업데이트입니다.

기존에는 블롭 데이터를 모든 노드가 동일하게 보유해야 했습니다. 예를 들어 블록당 블롭이 3개, 총 384KB의 데이터가 있다면, 모든 노드가 그 384KB 전체를 주고받아야 했죠. PeerDAS는 이 데이터를 노드들이 나눠 일부만 보관하도록 변경하여, 노드들의 통신 부담을 획기적으로 줄입니다.

PeerDAS는 리드 솔로몬 인코딩(Reed-Solomon Encoding)을 사용합니다. 이 기술은 CD/DVD에서 데이터 손실을 방지하기 위해 쓰이던 방식과 유사합니다. 원본 데이터에 특정 인코딩을 적용해 크기를 두 배로 확장한 뒤, 확장된 데이터의 절반만으로도 원본을 복구할 수 있게 만드는 방식입니다. PeerDAS에서는 이 ‘복구성’을 활용해, 노드들이 데이터의 일부만을 나눠갖는 방식으로 네트워크 요구사항 증가 없이 더 많은 블롭을 감당할 수 있도록 하였습니다.

이에 대해 기술적으로 자세히 보면 다음과 같습니다.

(PeerDAS의 리드 솔로몬 인코딩 | 출처: Optimism Blog)

PeerDAS 업그레이드에서는 이더리움 네트워크 전체를 128개의 서브넷(subnet)으로 나눕니다. 각 서브넷은 전체 블롭 데이터의 일부 조각만 저장하게 됩니다.

블롭을 전송하려는 사람은 먼저 리드 솔로몬 인코딩을 적용해 데이터를 두 배 크기로 늘린 뒤, 이를 128개의 조각(column)으로 분할합니다. 각 조각들은 이더리움 노드 간의 P2P 연결을 통해 각 서브넷에 하나씩 전달되죠. 이렇게 나눠진 조각들 중 절반, 즉 전체 128개 조각 중 절반인 64개만 확보하면 원본 블롭을 완전히 복원할 수 있습니다.

PeerDAS는 각 밸리데이터들이 저장하는 블롭 조각의 개수를 강제합니다. 즉, 밸리데이터들은 본인의 스테이킹 금액에 따라 여러 서브넷에 반드시 참여해야 합니다.

• 최소 스테이킹 금액인 32 ETH를 예치한 밸리데이터는 최소 8개의 서브넷에 참여해야 하고,
• 이후 32 ETH를 추가할 때마다 1개의 서브넷에 더 참여해야 합니다.

따라서 모든 128개의 서브넷에 참여하려면 총 3,872 ETH가 필요하며, 이렇게 모든 서브넷에 연결된 노드를 ‘슈퍼노드(Supernode)’라 부릅니다. 이 노드는 많은 돈을 스테이킹한 만큼, 좋은 하드웨어와 높은 네트워크 성능으로 블롭 조각들을 네트워크에 분배하는 데에 많은 기여를 하는 노드입니다.

다만 슈퍼노드는 반드시 이만큼의 ETH를 예치해야 하는 것은 아닙니다. 예를 들어 RPC 서비스나 인프라 제공자처럼 블롭 데이터를 전부 가지고 이를 서비스로 제공하려는 노드는, 단순히 클라이언트 설정을 통해 슈퍼노드가 되어 모든 서브넷에 참여할 수도 있습니다.

이러한 PeerDAS를 통해 노드들이 얻는 이점은 무엇일까요? 이전에 하나당 128KB 하던 블롭을 노드들끼리 전파하면, 한 번 전파에 128KB의 대역폭을 써야 했습니다. PeerDAS에서는 블롭이 리드 솔로몬 인코딩을 통해 2배로 늘어나 256KB가 되고, 이게 128개의 서브넷에 각각 2KB씩 분배되기 때문에, 32 ETH를 스테이킹해 8개의 서브넷에 참여하는 밸리데이터의 경우 한 블롭 당 16KB(2KB * 8)의 대역폭만 쓰면 됩니다. 즉, 일반적인 밸리데이터들에 대해 대역폭이 이전보다 8배가 줄게 되는 것이죠.

따라서, PeerDAS는 이론적으로 블롭의 최대 개수를 8배 증가시킬 수 있습니다. 현재 블롭 타겟이 6개, 최대가 9개이므로, 이론적으로 PeerDAS를 적용하면 타겟을 48개, 최대를 72개로 설정할 수 있습니다.

그러면 후사카에 바로 L2 처리량이 8배가 되는 걸까요? 답부터 이야기하면 아닙니다. 실제로 존재하는 여러 가지 추가적인 병목들 때문에, 바로 8배로 증가시킬 수는 없습니다. 이를테면 다음과 같은 이슈들이 있을 수 있습니다.

블롭 트랜잭션은 기본적으로 슬롯을 제안하는 프로포저가 네트워크 참여자들에게 전파하는 방식입니다. 다시 말하면, 프로포저는 블록에 들어가는 블롭을 모두 다 가지고 전파해야 하며, 블롭이 늘어나면 늘어날수록 네트워크 부담이 커지게 됩니다. 즉 이러한 구조대로라면, 프로포저는 PeerDAS의 장점을 보지 못하게 됩니다.

이를 해결하기 위해, PeerDAS가 본격적으로 도입되기 전부터 이더리움 코어 개발자들은 engine_getBlob API라는 것을 설계해 두었습니다. 이 API의 핵심 아이디어는 블록 합의 과정 중에 프로포저로부터 합의 클라이언트를 통해 블롭을 받는 대신, 실행 클라이언트의 멤풀에서 미리 가져오자는 것입니다. 이렇게 하면 노드들이 블롭을 미리 갖고 있을 수 있게 되어, 블록 프로포저가 블록 제안 시점에 블롭 전체를 직접 네트워크에 전파할 필요가 없어지기 때문에, 전파 지연과 대역폭 낭비를 줄일 수 있습니다.

이 접근법은 다음과 같은 가정에 기반합니다. 블롭은 원래 합의 클라이언트로 전달되기 이전에 실행 클라이언트의 멤풀에 먼저 들어가기 때문에, 대부분의 노드들은 이미 필요한 블롭 데이터를 보유하고 있을 것이라는 점입니다. 실제 연구에서도 블록이 전파될 때 약 75%의 클라이언트가 해당 블록에 포함된 블롭을 이미 가지고 있었으며, 이론적으로 engine_getBlob 메커니즘이 블롭 전파 병목을 크게 줄일 수 있음을 보여주었습니다.

하지만 실제 테스트에서는 예상치 못한 결과도 관찰되었습니다. 블롭의 개수가 많아질수록, 병목이 합의 레이어가 아니라 실행 레이어의 멤풀 쪽에서 발생하기 시작한 것입니다. 서니사이드 랩스의 실험 결과에 따르면, 블롭 개수가 증가할수록 실행 레이어 P2P 네트워크가 점점 더 큰 병목으로 작용했습니다. 예를 들어, 블록당 블롭이 22개일 때는 풀노드 전체 대역폭의 약 56.4%가 실행 레이어에서 소모되었고, 48개로 늘어나면 그 비율이 67.6%까지 상승했습니다. 따라서 향후 블록 당 블롭 개수를 타겟 48개 / 최대 72개 수준으로 확장하려면, 합의 레이어 뿐만 아니라 실행 레이어 멤풀 수준에서의 전파 및 대역폭 효율화가 이뤄져야 합니다.

(블록 당 블롭 개수에 따른 노드 평균 대역폭 사용량 다이어그램 | 출처: Sunnyside 9/30 Devnet Report)

또한 ethPandaOps가 수행한 분석에서도, 블롭 개수가 32개 가량 되었을 때, MEV-Boost를 사용하지 않는 프로포저는 제 시간 안에 블록을 제안하는 데에 어려움을 겪는다는 것이 밝혀졌습니다.

(블롭 개수에 따른 Head Correctness 비율 | 출처: ethPandaOps Blog)

즉 아직은 PeerDAS를 통해서 블록 당 최대 72개의 블롭을 감당하기엔 어려우며, P2P 측면에서 해결해야 할 문제들이 남았다고 볼 수 있습니다.

또한, 바로 블롭의 개수를 최대한까지 늘리는 것은 네트워크의 안정성에 좋지 않은 영향을 미칩니다. ethPandaOps와 서니사이드, 그리고 베이스가 메인넷의 11% 규모에 해당하는 대규모 테스트넷을 운영해 안정성을 시험해보긴 했으나, 실제 메인넷 환경에서 어떤 일이 일어날지는 100% 예상하기 어렵습니다. 자칫 잘못해 문제가 발생한다면, 이더리움은 안정성 측면에서 신뢰를 잃게 될 수 있죠.

따라서, PeerDAS는 바로 블롭 타겟을 8배로 올리지 않으며, 네트워크가 바로 붕괴하지 않게 시간에 따라 점진적으로 숫자를 증가시키는 보수적인 방식으로 이뤄질 가능성이 큽니다.

그러나 블록 당 블롭 개수의 타겟 및 최댓값은 프로토콜 내 파라미터로 정해져 있으며, 하드포크로만 변경될 수 있습니다. 그리고 현재 이더리움은 6~9개월의 간격마다 하드포크를 진행하고 있죠. 네트워크의 안정성을 보는 데에는 긴 시간이 소요되지 않음에도 6~9개월마다 블롭 개수를 점진적으로 증가시킨다면, L2의 확장 속도는 제약될 것이고, 결과적으로 L2 생태계의 혁신과 확장이 저해될 위험이 있습니다.

이를 해결하기 위해, ‘블롭 개수만을 조정하는’ 별도의 하드포크가 필요합니다. 이것이 바로 다음 섹션에서 설명할 EIP-7892: Blob Parameter Only (BPO) 하드포크입니다.

EIP-7892: 블롭 개수만 변경하는 하드포크를 만들 순 없을까?

Blob Parameter Only (BPO) 하드포크는 별도의 다른 업데이트 없이, 블롭 개수만을 조정하는 하드포크입니다. 윗 섹션에서 설명한 대로, P2P 단의 여러 비효율성 때문에 PeerDAS가 적용되더라도 이론적인 8배 처리량 증가를 바로 달성할 순 없으며, 네트워크의 안정성을 고려해 천천히 블롭 개수를 올려가는 방식으로 스케일링을 진행하는 것이 좋습니다. 이를 위해 EIP-7892는 블롭 개수만을 조정하는 BPO 하드포크를 도입하며, 각 클라이언트가 블롭 조정 일정과 조정 값을 설정으로 지정할 수 있도록 설계되었습니다.

현재 2개의 BPO 하드포크가 제안되어 있으며, PeerDAS 적용 후 약 2~3주 간격을 두고 적용될 예정입니다. 자세한 일정은 다음과 같습니다.

1. 후사카 하드포크

• 일정: 12월 3일
• 블롭 타겟: 6개 (현재와 같음)
• 최대 블롭: 9개 (현재와 같음)

2. BPO 1

• 일정: 12월 17일
• 블롭 타겟: 10개 (현재 대비 +67% 증가)
• 최대 블롭: 15개 (현재 대비 +67% 증가)

3. BPO 2

• 일정: 1월 7일
• 블롭 타겟: 14개 (현재 대비 +133% 증가)
• 블롭 타겟: 21개 (현재 대비 +133% 증가)

BPO 2까지 성공적으로 진행된다면, 이더리움 L2들은 약 800~1,000 TPS를 안정적으로 처리할 수 있을 것으로 예상되며, 이는 현재 기준 솔라나의 실제 TPS(보팅 트랜잭션 제외)와 유사한 수준입니다.

다만 이보다 더 높은 48개, 72개 블롭까지의 처리량을 목표로 하려면, 단순히 블록당 블롭 개수를 늘리는 것만으로는 한계가 있을지도 모릅니다. 부분 메세지 확장(Partial Message Extension) 등 P2P 네트워크 레이어의 추가적인 최적화, 실행 레이어 내 멤풀의 블롭 전파 효율 개선(EIP-8070) 혹은 ePBS와 같이 블록 전파 시간을 늘려 효율을 근본적으로 개선하는 메커니즘이 함께 도입되어야 합니다. 이러한 변화들은 리서치 및 구현 중에 있으며, 테스트를 통해 안전성이 검증된 후 단계적으로 메인넷에 적용될 것으로 보입니다. 이러한 변화들이 모두 적용된다면, 이론적으로 블록 당 최대 블롭의 개수는 72개를 넘어 100~200개까지 증가할 수 있을 것으로 보이며, 이렇게 된다면 L2의 최대 처리량은 10,000 TPS를 넘을 수 있습니다.

EIP-7918: 고장난 블롭 수수료 시장을 고치자

EIP-7918은 이더리움의 블롭 수수료 체계를 안정화하기 위한 제안으로, 블롭의 기본 수수료에 하한선을 두자는 아이디어를 담고 있습니다.

현재 이더리움 블롭 시장의 핵심은 블롭 수수료가 수요와 공급에 따라 자동으로 조정된다는 점입니다. 블록이 블롭으로 가득 차면 수수료가 오르고, 반대로 사용이 적으면 내려가는 구조이죠. 이러한 구조는 일반적인 가스 수수료와 마찬가지로 시장 메커니즘을 통해 블롭 사용량을 효율적으로 조정하도록 설계되어 있습니다.

그러나 실제 네트워크 운용 과정에서 블롭 수수료 시장은 예상만큼 “가격 발견”이 잘 이루어지지 않는 비탄력적인 구조였습니다. 예를 들어, 블롭의 가격이 올라가면 롤업들은 블롭을 덜 올리거나 해서 가격이 다시 아래로 내려가는 등의 현상이 발생해야 했는데, 실제로는 블롭이 일정 가격까지 올라가더라도 롤업들이 블롭을 덜 올리는 현상이 발생하지 않았던 것이죠.

이는 블롭 가격이 특정 수준 아래로 떨어지게 되면, 블롭 트랜잭션에 드는 기본 수수료 비용(21,000 가스 + 컨트랙트 상호작용 비용)이 블롭 수수료보다 훨씬 크기 때문입니다. 이더리움의 트랜잭션 비용은 수요가 낮을 때에도 몇 백원 수준인 데에 비해 블롭의 기본 비용은 0.00001원보다도 작기 때문에, 블롭 사용량이 한 시간이 넘게 포화 수준에 달해도 블롭 비용은 체감상 크게 증가하지 않을 수 있다는 이야기이죠.

(블롭스페이스의 수요공급곡선 | 출처: EIP-7918)

실제로 위와 같이 수요공급곡선을 통해 확인해보면, 이 비탄력성을 확인할 수 있습니다. 이더리움의 기본 수수료가 3 Gwei인 경우(빨간색 곡선), 수요 곡선은 공급 곡선과 만나지 않아 균형점이 없는 상황이 발생하며, 블롭의 가격은 바닥으로 떨어집니다. 즉 현재까지 블롭은 ‘가격 비탄력 구간’에 너무 오래 있게 설계되어 있었던 것입니다.

EIP-7918은 이러한 문제를 해결하기 위해, 블롭의 기본 수수료가 지나치게 낮아지지 않도록, L1 실행 가스와 연관된 하한선을 설정합니다. EIP-7918에서는 BLOB_BASE_COST라는 상수(값: 8192)를 도입하여, 블롭 기본 수수료가 L1 기본 수수료의 일정 비율(1/16) 이하로 내려가지 않도록 수수료 계산식을 수정합니다. 이렇게 하면 블롭 기본 수수료가 더 이상 떨어지지 않고 일정 수준에서 멈추게 되어, 수수료 조정 루프가 끊기지 않게 됩니다. 즉, 본질적으로 EIP-7918은 블롭 시장의 하한가를 설정해 수요–공급 조정 메커니즘을 살려두는 장치라고 볼 수 있죠.

EIP-7918이 도입하는 하한 비용은, 블롭이 L1 풀노드에게 미치는 계산 비용도 고려하여 책정되었습니다. PeerDAS 내에서 블롭은 128개의 조각(cell)로 나눠지며, 각 조각은 한 개의 KZG 증명을 포함합니다. 노드들은 블록 검증 과정에서 이 KZG 증명들을 검증해야 하죠.

(블롭 개수에 따른 KZG 증명 검증 비용 | 출처: EIP-7918)

이러한 KZG 증명 검증에 드는 비용을 이더리움 내의 프리컴파일 가스 비용에 대입해서 계산하면, 노드들이 블롭 트랜잭션 처리에 받아야 하는 비용을 계산할 수 있습니다. 계산 결과에 따르면 BLOB_BASE_COST는 2¹⁵인 32,768이 되어야 하죠. 이러면 블롭 기본 수수료의 하한은 L1 기본 수수료의 4분의 1로 책정됩니다. 그렇지만 블롭 시장의 적절한 가격 발견 메커니즘을 위한 BLOB_BASE_COST 는 2¹¹인 2,048이면 충분합니다. 현재 EIP-7918의 설정값은 이 두 값의 중간 지점을 선택했다고 볼 수 있습니다.

현실적으로 현재 롤업들은 대부분의 상황에서 블롭에 거의 돈을 쓰고 있지 않습니다. 블롭 기본 수수료가 대부분의 경우 최소값인 1 wei로 유지되고 있기 때문이죠. EIP-7918은 이 최소값을 기본 수수료의 1/16 수준으로 올리겠다는 이야기와 같습니다. 그럼, 여기서 두 가지 질문을 해볼 수 있습니다.

1. 이 때문에 롤업 사용자의 비용도 유의미하게 올라, UX가 더 안 좋아질까요?
2. EIP-4844로 블롭에 들어가는 모든 수수료는 소각되는데, 이 소각량이 유의미한 수준으로 커질까요?

현재는 둘 다 아닐 가능성이 높습니다.

1번의 롤업 사용자 비용부터 보겠습니다. 베이스에서 발생한 이 트랜잭션의 경우, L1 데이터 비용으로 0.000000000390881 ETH만큼을 사용했습니다. ETH 가격을 $4,000으로 설정하면, 원화로 쳐도 이 비용은 0.002원 가량에 지나지 않습니다. EIP-7918이 적용되면 이 비용은 베이스와 같은 OP 스택 롤업에서 대략 39% 가량 증가하는데, 증가해도 0.003원을 넘지 않죠. L1 기본 수수료가 100배 증가한 100 Gwei가 되더라도, L2 사용자들의 데이터 비용은 약 0.25원에 해당할 것이며, 이 역시 크다고 보기는 어렵습니다. 따라서 EIP-7918이 적용되더라도 사용자들의 비용은 유의미하게 증가하지 않을 것입니다.

2번의 소각량도 계산해보겠습니다. 이더리움 기본 수수료가 1 Gwei를 유지한다는 가정 하에, 하루 동안 블록 당 6개의 블롭이 들어오는 상황에서 EIP-7918이 적용된다면 하루 간 블롭 비용으로 인한 ETH 소각량은 다음과 같습니다.

즉, 하루 소각량은 대략 0.32 ETH가 될 것입니다. 이더리움의 기본 수수료가 1 Gwei일 때 매일 기본 수수료로만 100 ETH가량이 소각된다는 것을 생각하면 그리 많은 양은 아니죠.

다만 기본 수수료가 지난 10월 10일 발생했던 시장의 불안정성으로 인해 높게 오른다면, 블롭 수수료 역시 기본 수수료와 함께 크게 올라갈 수 있으며, 이 경우 소각량 역시 증가할 것입니다. 또한 위 표는 블록 당 6개의 블롭을 가정한 결과라, 이더리움이 엔드게임인 ‘블록 당 512개의 블롭’에 더 가까이 다가갈수록, 저 수치는 최대 85배 가량까지 커질 수 있습니다.

L1 스케일링

후사카 업그레이드는 L2 스케일링에 초점이 맞추어져 있지만, L1 스케일링을 위한 여러 가지 개선 역시 포함하고 있습니다. 특히 후사카는 미래에 L1을 더 많이 스케일링했을때 발생할 수 있는 여러 엣지 케이스들을 사전에 방지하는 데에 초점을 맞추고 있으며, 이에 아래와 같은 네 가지 EIP를 포함합니다.

• EIP-7823: Set upper bounds for MODEXP
• EIP-7883: ModExp Gas Cost Increase
• EIP-7825: Transaction Gas Limit Cap
• EIP-7934: RLP Execution Block Size Limit

또한, L1 스케일링에 직접적으로 영향을 줄 수 있는 두 개의 EIP 역시 포함되었습니다.

• EIP-7642: eth/69 — Drop pre-merge fields
• EIP-7935: Set default gas limit to 60M

각각의 EIP가 L1 스케일링에 어떻게 기여하는지 자세히 알아보겠습니다.

EIP-7823: MODEXP 프리컴파일 입력값에 상한을 두자

EIP-7823은 MODEXP 프리컴파일 계산에 들어가는 입력값에 최대를 설정하자는 제안입니다. 제안에 대해 설명하기 전에, 먼저 프리컴파일 컨트랙트와 MODEXP에 대해 간단히 설명하겠습니다.

이더리움에는 자주 사용되고 중요한 연산들을 EVM 안에서 처리하는 것이 아니라, 오프체인 코드로 처리하는 ‘프리컴파일’이라는 개념이 존재합니다. 이는 솔리디티 코드로 구현하면 수백만 가스가 넘게 드는 연산을 훨씬 빠르고 저렴하게 계산할 수 있도록 하는 특징이 있습니다.

MODEXP는 RSA 서명이나 ZK SNARK 등의 암호학적 연산에 사용되는 ‘$a^b \ mod \ c$’ 형태의 연산을 의미합니다. 이는 솔리디티 코드로 구현했을 때 수억 가스가 들기 때문에 사실상 사용이 불가능한 수준이지만, 다양한 앱들에서 RSA나 ZK SNARK를 사용할 수 있어야 했기 때문에, 그들의 비용 문제를 해결하기 위해 2017년 비잔티움 하드포크에서 도입되었죠.

이더리움의 MODEXP 프리컴파일은 밑(base), 지수(exponent), 모듈러스(modulus) 세 개의 입력값을 받아, 다음과 같은 값을 반환합니다.

그동안 MODEXP 프리컴파일은 기능적으로 유용했지만, 한 가지 비효율적인 설계가 존재했습니다. 바로 입력 인자들의 길이에 제한이 없었다는 점입니다. 이 때문에 이더리움 클라이언트들은 테스트 과정에서 비정상적으로 큰 인자값을 처리하다가 여러 차례 버그를 겪었고, zkEVM 클라이언트들 역시 예상치 못한 큰 입력을 안전하게 처리하기 위해 상당한 리소스를 투입해야 했습니다.

이 문제를 해결하기 위해 제안된 것이 EIP-7823입니다. 이 제안은 MODEXP의 세 입력 인자(밑, 지수, 모듈러스)의 길이를 최대 8192비트(1024바이트)로 제한합니다. 역사적으로 MODEXP 프리컴파일이 도입된 이후, 실제 메인넷에서 사용된 인자 크기가 8192비트를 초과한 사례는 단 한 번도 없었습니다. 또한 이 범위는 MODEXP의 주요 활용 분야인 RSA 서명 검증이나 타원곡선 기반 연산을 수행하기에도 충분합니다.

이제 이더리움 클라이언트와 zkEVM 구현팀들은 이러한 엣지 케이스를 걱정하지 않고, 보다 단순하고 안정적인 방식으로 MODEXP를 구현할 수 있게 됩니다. 결과적으로 EIP-7823은 클라이언트와 ZK 측면의 안정성과 효율성 확보를 위한 합리적 안전장치로 볼 수 있습니다.

EIP-7883: MODEXP 프리컴파일의 가스 가격은 잘못되었다

MODEXP 프리컴파일은 EIP-7823에서 수정된 입력값 길이 문제 외에도, 특정 케이스에서 가스 비용이 너무 낮게 책정되었다는 이슈가 있습니다. 이는 향후 블록 가스 리밋을 높이는 스케일링 단에서 문제가 될 수 있죠. EIP-7883은 MODEXP 프리컴파일 컨트랙트의 비용을 증가시킴으로써 이러한 문제를 해결합니다.

EIP-7883은 다음과 같은 네 가지 영역에서 MODEXP의 비용을 증가시킵니다.

1. 최소 호출 비용 인상 모든 호출에 대해 최소 가스비를 200에서 500으로, 2.5배 상향했습니다.
2. 일반 연산 비용 3배 인상 RSA, ZK SNARK, BLS 검증 등 대표적인 사용 사례의 평균 연산량을 반영하여 기존 대비 약 3배 높은 비용으로 조정되었습니다.
3. 작은 모듈러스(modulus)의 언더프라이싱 해결 모듈러스 크기가 작을수록 실제 계산량 대비 가스비가 과도하게 낮게 책정되던 문제를 해결하기 위해, 모든 modulus를 최소 32바이트로 간주하여 비용을 계산합니다.
4. 대형 입력값에 대한 비용 상향 modulus가 32바이트를 초과할 경우, 곱셈 복잡도를 2배로 증가시켜 대형 연산이 네트워크에 미치는 부하를 충분히 반영합니다.

이러한 조정은 단기적으로는 ZK 증명 검증 등 MODEXP를 사용하는 일부 애플리케이션의 가스 비용을 높이는 결과를 가져오지만, 장기적으로는 이더리움 네트워크의 확장성과 안정성을 보장하기 위한 필수적인 조치라고 볼 수 있습니다.

현재의 낮은 가격 책정 상태에서 블록 가스 리밋을 단순히 올리면, 공격자가 MODEXP 호출만으로 블록을 채워 노드의 CPU 리소스를 과도하게 소모시키는 DoS 공격이 가능해집니다. 예를 들어, 블록 빌더가 연속적인 MODEXP 호출을 포함한 트랜잭션들로 블록을 가득 채워 전파하면, 저사양 노드는 연산 부하를 감당하지 못해 블록 처리 지연이나 네트워크 불안정이 발생할 수 있습니다. EIP-7883은 이러한 리스크를 사전에 차단하기 위해 MODEXP의 가스비를 실제 연산 자원 소비량에 맞게 재조정한 것입니다. 이는 단순한 비용 인상이 아니라, 향후 블록 가스 리밋 상향과 네트워크 스케일링을 위한 기반 정비라 할 수 있습니다.

허나 이는 반대로 얘기하면, 기존 MODEXP를 활용하는 애플리케이션들의 가스 비용이 전보다 증가하는 것과 같죠. EIP-7883이 적용되면, MODEXP 프리컴파일을 사용하는 실제 애플리케이션들의 가스비는 얼마나 늘어날까요? 이를 확인하기 위해 MODEXP를 다수 호출하는 대표적인 사례인 리니아(Linea)의 ZK 증명 검증 컨트랙트를 살펴볼 수 있습니다.

리니아가 ZK 증명을 제출할 때 쓰는 컨트랙트는 증명 검증 과정에서 MODEXP를 총 6번 호출합니다. EIP-7883 이전, 즉 기존 EIP-2565 기준으로는 이 연산들의 총 가스비가 약 4,600가스 수준이었지만, 새로운 가격 공식이 적용되면 약 13,600가스로 증가합니다. 결과적으로 약 9,000가스, 즉 2배가 넘는 상승이 발생하는 셈입니다.

그러나 리니아의 ZK 증명 검증 트랜잭션 전체 가스비가 약 400,000 가스 정도임을 감안하면, 이 증가분은 전체 트랜잭션 대비 2% 남짓에 불과합니다. MODEXP의 가스가 오르더라도 검증 과정에서 큰 비중을 차지하는 연산은 여전히 페어링이나 타원곡선 곱셈 같은 연산들이기 때문입니다.

결국 EIP-7883으로 인해 ZK 롤업이나 ZK 증명 검증 등 실제 애플리케이션의 비용이 폭발적으로 늘어나는 일은 거의 없다고 볼 수 있습니다. MODEXP의 가격 조정은 CPU 연산량에 맞게 현실적인 수준으로 보정한 것이며, 전체 트랜잭션 비용 관점에서는 미미한 상승에 지나지 않기 때문이죠.

EIP-7825: 트랜잭션에 크기 제한을 두자

EIP-7825는 한 트랜잭션 당 가스 리밋을 16,777,216 ($2^{24}$) 수준으로 제한해, 네트워크의 안정성을 높이고 향후 L1 스케일링을 더 용이하게 만들자는 제안입니다.

기존 이더리움의 트랜잭션에는 별도의 가스 리밋이 없었습니다. 이론적으로 한 개의 트랜잭션이 모두 블록을 채울 수도 있었죠. 이는 다음 두 가지 측면에서 좋지 않습니다.

1. 이더리움 병렬 검증의 효용을 매우 떨어뜨린다
2. zkEVM 증명 생성을 더 어렵게 만든다

각각에 대해 좀 더 자세히 알아보겠습니다.

1. 이더리움 병렬 검증의 효용

이더리움 메인넷은 현재 병렬 검증이 적용되어 있지 않지만, 내년 이더리움의 업그레이드를 통해 가능해질 예정입니다. 후사카 다음 업그레이드인 글램스터담에 포함된 EIP-7928: Block-level Access Lists(BAL)가 바로 이를 가능하게 만드는 EIP입니다.

EVM에서 병렬 실행이 어려웠던 이유는, EVM 내 각 트랜잭션이 직접 실행해보기 전까진 어떤 상태에 접근하는지를 알 수 없기 때문이었습니다. 만약 각 트랜잭션이 접근하는 계정이 같아서 서로에게 의존적인 구조라면, 이는 병렬 실행될 수 없고 순차 실행되어야 합니다. 그러나 이는 트랜잭션을 실행해보기 전에는 알 수 없기 때문에, EVM에서는 병렬 실행을 위한 리소스 분배(스케줄링)가 매우 까다로웠죠.

그런데 이때, 누군가 블록 내 트랜잭션을 전부 실행해본 뒤 각 트랜잭션이 어떤 계정 및 스토리지에 접근하는지 알려준다면, 이를 받아본 노드들은 어떤 트랜잭션들을 병렬로 실행할 수 있는지, 어떤 트랜잭션들은 순차적으로 실행해야 하는지 스케줄링을 잘 할 수 있을 것입니다. 이를 구현하는 EIP가 BAL입니다. BAL은 블록 빌더가 트랜잭션을 실행해본 뒤 각 트랜잭션이 접근하는 계정 및 스토리지를 정리해 블록에 담아 전파하도록 하여, 노드들이 병렬 검증을 할 수 있게끔 만드는 제안입니다. 병목을 ‘검증자’에서 ‘블록 빌더’로 옮기는 것이죠.

그런데 BAL이 도입되어도, 트랜잭션 한 개의 크기가 매우 크다면 병렬 검증의 효용은 크게 떨어질 수 있습니다. EVM에서의 ‘단일 트랜잭션 병렬화’는 매우 어려운 기술이기 때문입니다. 한 트랜잭션 내에서의 가스 소모량이나 상태 계산은 순서에 매우 민감하여 잘못 병렬화했을 때 다른 값을 내뱉을 수 있으며, 이는 체인 포크로 이어질 수 있습니다. 즉 단일 트랜잭션은 BAL이 도입되어도 병렬 검증하기 쉽지 않습니다.

즉, 공격자는 BAL이 적용되어도 병렬 검증의 이점을 살리지 못하도록 블록 가스 리밋을 모두 소모하는 트랜잭션 하나만을 지속적으로 보내는 DoS 공격을 수행할 수 있습니다. EIP-7825의 단일 트랜잭션 크기 제한은 이 공격 케이스에 대한 효과적인 방어책이 될 수 있습니다.

2. zkEVM 증명 생성의 효율성

일반적인 zkEVM들은, 증명 생성을 가속화하기 위해 트랜잭션 단위로 청크를 만들어, 청크 별로 병렬 증명을 생성합니다. 이때 만약 한 트랜잭션의 크기가 너무 크다면, 증명 병렬화에 어려움을 겪을 것이고, ZK 증명 생성의 확장성이 떨어지게 되죠. 위의 병렬 검증과 같은 논리로, EIP-7825의 트랜잭션 크기 제한은 거대한 단일 트랜잭션 때문에 병목이 생기는 걸 방지하고, ZK 증명 생성을 더 빠르게 만들어줄 수 있습니다.

그러나 이러한 제한은, 매우 큰 트랜잭션을 나눠 보내야 한다는 제약을 가져옵니다. 예를 들어, 계정 추상화의 대표적인 표준으로 자리잡은 ERC-4337은, 기본적으로 트랜잭션을 릴레이하는 번들러가 여러 개의 사용자 트랜잭션(UserOperation)을 한 개의 단일 트랜잭션으로 배치 처리하는 메커니즘을 가지고 있습니다. EIP-7825가 적용된다면, 번들러는 수많은 사용자 트랜잭션을 한 트랜잭션에 배치 처리하기보단, 가스 리밋을 고려하여 쪼개는 형태를 택해야 합니다.

또한, 이는 이더리움 컨트랙트 배포의 크기도 제한합니다. 현재 이더리움의 세팅(Spurious Dragon)대로라면 약 24KB 이상의 컨트랙트 배포가 불가능합니다. 이 제한이 그대로 유지된다면 문제가 아니지만, 이 제한이 향후 확장성 등을 이유로 상향된다면 문제가 될 수 있습니다. 예를 들어, 후사카에서는 제외되었던 EOF(Ethereum Object Format) 업데이트에는 컨트랙트 최대 크기를 증가시키자는 제안이 있었습니다. 이게 만약 미래에 도입된다면, EIP-7825의 제한 때문에 최대 크기는 대략 70~80 KB 이상으로 커질 수 없습니다. 그 이상 크기의 컨트랙트 배포는 16.7M 가스 이상을 소모할 것이기 때문이죠.

물론 EIP-7825를 고려할 만큼 큰 트랜잭션은 이더리움 메인넷에선 일반적으로 생성되지 않습니다. 실제로 2025년 상반기 이더리움 메인넷에서 183일 분의 트랜잭션들을 분석한 결과, 99.96%의 트랜잭션이 EIP-7825에 정의된 가스 리밋을 넘지 않음을 확인할 수 있었습니다. 즉, EIP-7825가 트랜잭션 크기에 제한을 두기 시작하더라도 기존 이더리움 메인넷은 거의 영향받지 않고 운영될 수 있습니다.

(2025년 상반기 이더리움 트랜잭션들의 크기 분포 | 출처: EIP-7825)

또한 EIP-7825에서 정의된 한계는 ‘다차원 가스’ 모델이 도입되면 완화될 수 있습니다. EIP-8011로 대표되는 다차원 가스 제안은, 현재의 단일 가스 미터링 방식을 개선해 리소스별로 별도의 가스 제한을 두자는 아이디어입니다. 기존 이더리움에서는 하나의 가스 한도 안에서 CPU, 메모리, 스토리지, 네트워크 대역폭이 모두 경쟁하는 구조였습니다. 예를 들어, 노드가 16GB의 메모리와 10Mbps의 네트워크 대역폭을 보유하고 있더라도, 한쪽 리소스(네트워크)를 많이 쓰는 연산이 포함되면 다른 리소스(메모리)는 충분히 활용되지 못합니다. 이는 노드가 가진 자원을 온전히 활용하지 못하게 하여, 잠재적인 확장성을 제한하는 요인이 됩니다. 다차원 가스 모델은 이러한 문제를 해결하기 위해, 각 리소스(예: CPU, 메모리, 네트워크)에 개별적인 가스 리밋을 설정함으로써 노드의 자원을 최대한 활용하고, 결과적으로 네트워크의 확장성을 높이는 것을 목표로 합니다.

만약 이러한 다차원 가스 모델이 컨트랙트 배포에도 적용된다면, 컨트랙트 배포 트랜잭션에는 별도의 가스 차원이 부여되어 16.7M 가스 이상의 한도가 허용될 가능성이 있습니다. 그렇게 되면 EIP-7825로 인해 발생하는 컨트랙트 크기 제한 문제는 사실상 해소될 수 있습니다. 즉, 다차원 가스 모델은 EIP-7825의 안전성 유지라는 장점을 유지하면서도, 컨트랙트 크기나 번들 처리량에 대한 제약을 완화할 수 있는 잠재적 해결책으로 평가됩니다.

결론적으로, EIP-7825는 이더리움의 병렬 검증과 ZK 증명 생성 작업을 유리하게 만들기 위해 트랜잭션의 최대 크기를 제한하는 제안이며, 여기서의 제한이 미래의 개발자 경험에 제약을 가져올 수 있는 경우는 다차원 가스 모델이 적용되면 해결될 수 있습니다.

EIP-7934: 블록에 크기 제한을 두자

향후 L1 스케일링이 계속될수록 한 블록에 들어가는 최대 트랜잭션 개수는 증가할 것이고, 이에 따라 블록의 최대 크기 역시 커질 것입니다. EIP-7934는 이 블록 크기에 제한을 둠으로써, 보다 안전한 스케일링이 가능하도록 하는 제안입니다.

블록의 크기가 커지면 네트워크에는 여러 문제가 생길 수 있습니다. 예를 들어, 합의 레이어 단에서 블록에 투표하기 위해 블록을 받아보는 과정에서, 블록의 크기가 너무 크다면 적정한 시간 내에 투표를 하지 못하게 될 수 있습니다. 그러면 해당 블록은 체인에서 리오그되고 체인에는 liveness 이슈가 발생해 사용자 경험이 저하될 수 있죠. 또한, 블록이 너무 크면 새로 띄운 노드가 체인을 따라가려할 때도 문제가 될 수 있으며, 아예 최신 블록까지 싱크가 불가능해질 수도 있습니다.

EIP-7934는 블록 크기에 대해 최대 10MB, RLP 인코딩된 블록에 대해 2MB의 안전 마진을 적용해 최대 8MB의 제한을 적용합니다. 이 제한은 가스 한도와는 별개로 적용되며, 모든 클라이언트는 RLP 인코딩된 블록이 8MB를 초과할 때 블록을 유효하지 않은 것으로 간주하고 거부해야 합니다.

이 상한은 이미 합의 레이어 가십 프로토콜이 10MB 전파 제한을 가지고 있다는 점에 기반합니다. 다만, 가십 프로토콜 단에 제한이 존재하는 것만으로는 10MB 이상의 블록이 생성되는 것 자체를 막을 순 없으며, 악의적인 공격자는 이를 악용하여 큰 블록을 생성해 전파만 안 되게 만들며 네트워크에 DoS를 할 수 있습니다. 이러한 공격 시나리오를 방지하고, 향후 L1의 확장성을 개선할 때 더 안전한 확장이 가능하도록 하는 것이 EIP-7934의 역할이라고 볼 수 있겠습니다.

EIP-7642: 머지 이전의 데이터 때문에 발생하는 비효율을 개선하자

EIP-7642는 이더리움의 P2P 네트워크 단에서 발생하던 비효율을 개선하기 위한 제안입니다. ‘부분적 상태 만료(Partial History Expiry)’ 이후 많은 노드들이 과거 블록 데이터를 보관하지 않게 되면서, 새로운 노드의 초기 동기화 과정과 피어 간 데이터 전송 효율에 문제가 드러났습니다. EIP-7642는 이러한 상황을 해결하기 위해 노드 간 블록 범위 인식 및 불필요한 데이터 전송 제거를 중심으로 P2P 프로토콜을 개선합니다.

배경은 2025년 5월에 도입된 ‘부분적 상태 만료’ 업데이트에서부터 시작됩니다. 당시 이더리움 코어 개발자들은 자주 사용되지 않는 과거 데이터를 클라이언트가 선택적으로 제거할 수 있도록 하여, 전체 네트워크의 저장 공간 부담을 300~500GB 가량 줄이는 방안을 적용했습니다.

이더리움 노드들은 과거 블록마다의 모든 상태 트리를 들고 있는 아카이브 노드와, 과거 블록들과 현재 상태 트리만을 들고 있는 풀 노드로 나눠집니다. 위 부분적 상태 만료 업데이트는 풀 노드가 2022년 ‘더 머지(The Merge)’ 이전 과거 블록 데이터를 버리고 저장 공간을 덜 쓸 수 있게 한 업데이트였죠. 과거 블록 데이터를 모두 보관하지 않더라도, 이더리움의 체크포인트 기반 합의 메커니즘 때문에 과거 블록을 임의로 변경하는 공격은 사실상 불가능합니다. 또한 아카이브 노드들은 여전히 필요 시 이전 블록을 제공할 수 있으므로 앱 등에서 과거 데이터가 필요한 경우에도 문제가 되지 않죠. 결과적으로 해당 변경은 네트워크 확장성 개선을 위한 합리적인 업데이트로 평가할 수 있습니다.

그러나 이 작업으로 인해 머지 이전 블록 정보를 들고 있지 않는 노드들이 많아지자, 다음과 같은 문제들이 발생했습니다. 가장 대두되었던 문제는 ‘싱크’였습니다. 이더리움 네트워크에 처음 들어오려는 풀 노드는, 본인과 연결된 노드들로부터 처음 제네시스 블록부터 현재까지의 블록 정보를 모두 다운받아야 합니다. 그런데, 본인과 연결된 다른 노드(peer, 피어)들이 머지 이전 블록 정보를 이제 가지고 있지 않을 수 있게 되었기 때문에, 싱크가 실패하는 일이 발생했던 것입니다. 해당 피어와 연결을 끊고 머지 이전 블록 정보를 아직 가지고 있는 피어와 새로 연결을 맺으면 되겠지만, 이를 찾기까지 계속해서 싱크가 실패하는 일이 발생할 수 있죠.

또한 이전 데이터 제공과 관련해서, 통신 단의 비효율도 존재하였습니다. 원인은 트랜잭션 영수증(Receipt) 안에 있는 블룸 필터(Bloom Filter) 때문이었죠. 블룸 필터는 트랜잭션이 발생시킨 이벤트 로그의 주소와 토픽 정보를 기반으로, 해시 함수를 통해 특정 비트를 1로 설정한 2048비트짜리 요약 데이터입니다. 이를 통해 “특정 주소나 이벤트가 이 블록에 포함되어 있을 가능성”을 빠르게 판별할 수 있지만, 각 영수증마다 블룸 필터가 포함되다 보니 네트워크 전송 시 불필요한 대역폭 낭비가 발생했습니다. 실제로는 영수증 안에 이미 로그 원본 데이터가 존재하기 때문에, 수신 노드가 이를 기반으로 블룸 필터를 재계산할 수 있음에도 불구하고 모든 피어 간 통신에서 매번 256바이트를 반복적으로 전송하고 있었던 셈입니다.

EIP-7642는 P2P 프로토콜을 바꿔서 이러한 비효율들을 해결하자는 제안입니다. 우선 EIP-7642는 노드가 피어에게 본인의 상태를 알릴 때, 본인이 가진 블록의 시작과 끝을 명시하도록 합니다. 또한, 노드를 운영하던 중 이전 블록을 프루닝(pruning)하는 등 중간에 제공할 수 있는 블록의 범위가 바뀌는 상황에도 이를 피어들에게 알릴 수 있도록 하는 BlockRangeUpdated 메세지를 도입합니다.

또한 EIP-7642에서 도입하는 네트워크 사양에서는 트랜잭션 영수증을 피어들에게 전송하는 과정에서 블룸 필터 필드가 아예 제거되었습니다. 이제 노드들은 블룸 필터 데이터를 주고 받지 않고, 트랜잭션 영수증 데이터에 포함된 로그 데이터를 기반으로 블룸 필터를 필요 시 재계산하면 되죠.

즉 EIP-7642는 P2P 네트워크 단에서 비효율을 개선해, 향후 확장성 개선에 필요한 네트워크 리소스를 확보하는 업데이트라고 볼 수 있겠습니다.

EIP-7935: L1을 33% 더 스케일링하자

EIP-7935는 이더리움의 가스 리밋을 클라이언트별로 통일해, 블록 크기 조정을 보다 체계적이고 예측 가능한 방식으로 관리하기 위한 제안입니다. 그동안 이더리움은 사회적 합의에 기반해 밸리데이터들이 자율적으로 가스 리밋을 조정해왔지만, 이 방식은 참여율과 릴리즈 타이밍에 따라 조정 속도가 불균일하다는 한계를 안고 있었습니다. EIP-7935는 이러한 비효율을 해소하기 위해 각 클라이언트의 기본 가스 리밋을 60M으로 고정하고, 향후 하드포크마다 안전성이 검증된 값을 일괄 반영하는 방향으로 표준화합니다.

이더리움 L1은 지난 9년 동안 동일한 가스 리밋(30M)을 유지해왔습니다. 그러나 2024년 들어 이더리움 재단의 새로운 로드맵 중 하나로 L1 스케일링이 포함되면서, 이더리움은 9년 만에 처음으로 블록 크기(가스 리밋)를 상향 조정하기 시작했습니다.

흥미로운 점은 이 블록 크기 변경이 하드포크나 합의 메커니즘, 혹은 EVM의 수정으로 이루어지는 것이 아니라, 노드 간의 사회적 합의를 통해 이루어진다는 것입니다. 각 노드 소프트웨어에는 밸리데이터가 자신이 생성하는 블록의 가스 리밋을 직접 설정할 수 있는 기능이 탑재되어 있습니다. 따라서 더 많은 밸리데이터가 높은 가스 리밋을 설정할수록, 네트워크 전체의 블록 크기가 자연스럽게 증가하게 됩니다. 이런 구조 덕분에 블록 크기 조정은 하드포크 시점에 맞춰 정기적으로 이루어지는 것이 아니라, 커뮤니티의 자율적 합의에 따라 유연하게 조정될 수 있다는 장점을 지닙니다. 반면, 이는 동시에 커뮤니티의 참여를 적극적으로 이끌어내야만 한다는 한계를 의미하기도 합니다. 실제로 이더리움 리서처들은 ‘가스 리밋을 높이자’는 캠페인을 벌이며 gaslimit.pics 같은 사이트를 만들어 밸리데이터들의 참여를 독려한 바 있죠.

이러한 사회적 합의 기반 방식에는 몇 가지 단점도 존재합니다. 커뮤니티 활동에 적극적으로 참여하지 않는 밸리데이터는 이런 운동의 존재를 인지하지 못하고 가스 리밋 증가에 동참하지 않을 수 있습니다. 또한 이더리움에는 여러 실행 클라이언트가 존재하는데, 각 클라이언트 팀이 노드 소프트웨어의 기본 가스 리밋값을 상향 조정하는 시점이 제각각이라 릴리즈 일정이 맞지 않기도 합니다.

이런 것들을 다루기 위해 제안된 것이 바로 EIP-7935입니다. 이 제안은 각 클라이언트가 정의하는 기본 가스 리밋값을 60M으로 고정하자는 내용을 담고 있습니다. 어차피 L1 확장성 개선이 이더리움 재단의 주요 목표 중 하나이며 매 하드포크마다 관련 업데이트와 테스트가 진행되는 만큼, 하드포크 시점마다 안전성을 검증한 뒤 새로운 기본값을 일괄 반영하자는 접근입니다.

(밸리데이터들이 생성하는 블록 가스 리밋의 분포 | 출처: gaslimit.pics)

현재 대부분의 밸리데이터는 45M 가스 리밋으로 블록을 생성하고 있지만, 위 그림과 같이 약 15% 정도의 밸리데이터들은 이미 가스 리밋을 60M으로 설정해 운영하고 있습니다. 후사카 업그레이드가 메인넷에 적용되면 EIP-7935에 따라 모든 클라이언트의 기본값이 60M으로 통일되며, 이더리움은 곧바로 약 33%의 확장성 향상 효과를 얻게 되죠.

그렇다면 가스 리밋을 이렇게 한 번에 올려도 안전할까요? 결론부터 이야기하자면, 그럴 가능성이 높습니다. 가스 리밋이 증가하면 이론적으로 블록의 최대 크기도 커지지만, 60M 수준에서는 이더리움 합의 사양에서 정의하는 최악의 블록 크기인 10MB에 도달하지 않습니다. 게다가 PeerDAS의 적용으로 블롭 데이터에 대한 네트워크 부담이 크게 줄어든 만큼, 이번 변경이 네트워크 안정성에 미치는 영향은 제한적일 것으로 평가됩니다.

결국 EIP-7935는 사회적 합의 기반의 유연한 블록 크기 조정을 더 체계적이고 예측 가능한 방식으로 보완하는 시도이며, 이더리움은 이를 통해 실질적인 확장성 개선을 달성할 것으로 생각됩니다.

사용자 경험 개선

마지막으로, 후사카 업그레이드에서는 이더리움 L1의 사용자 경험을 개선할 수 있는 세 가지 EIP를 도입합니다. 각각은 사용자들이 체감하는 트랜잭션 컨펌 시간을 밀리초로 줄이는 데에 도움이 되기도 하고, 연산의 비용을 줄이며, 스마트 계정의 비용을 절감하기도 합니다.

• EIP-7917: Deterministic proposer lookahead
• EIP-7939: Count leading zeros (CLZ) opcode
• EIP-7951: Precompile for secp256r1 Curve Support

각 EIP에 대해 자세히 알아보도록 하겠습니다.

EIP-7917: 누가 프로포저가 될지 미리 알 수 있다면?

EIP-7917은 이더리움의 한 에포크에서 누가 프로포저가 될 지 적어도 한 에포크 전(32슬롯, 약 6.4분)에 알 수 있도록 하는 제안입니다. 이는 이더리움 메인넷에서 트랜잭션을 수십 밀리초 단위로 더 빠르게 컨펌해주는 기반 사전확인(based preconfirmation) 프로토콜에 매우 중요한 역할을 합니다.

기반 사전확인은 기반 롤업(Based Rollup) 개념에서 발전한, 이더리움의 사용자 경험을 크게 향상시키기 위한 솔루션입니다. 기존 롤업은 단일 시퀀서가 블록을 빠르게 생성하는 구조였다면, 기반 롤업은 이더리움의 밸리데이터들이 직접 시퀀서 역할을 수행하는 구조를 갖습니다. 즉, 롤업의 블록 생성이 L1 합의 레이어와 긴밀히 연결되어 있는 형태입니다. 과거 타이코가 대표적인 기반 롤업의 예시였죠(참고: 최근 업데이트를 통해 타이코는 더 이상 누구나 시퀀싱할 수 없으며, 이에 따라 기반 롤업이 아니게 되었습니다).

기반 롤업의 가장 큰 문제점은 긴 블록 타임이었습니다. 단일 시퀀서가 빠른 주기로 블록을 생산하는 일반적인 롤업과 달리, 기반 롤업은 이더리움의 블록 생성 주기(약 12초)에 맞춰 롤업 블록이 생성됩니다. 결과적으로 롤업임에도 이더리움과 동일한 속도의 블록 타임을 가지게 되었고, 이는 사용자 경험 측면에서 치명적인 단점으로 작용했습니다. 사용자는 트랜잭션을 제출하고도 10초 이상 기다려야 결과를 확인할 수 있었으며, 이는 롤업의 가장 큰 장점인 “빠른 UX”를 크게 훼손하는 요소였습니다.

이 문제를 해결하기 위해 등장한 개념이 바로 기반 사전확인입니다. 기반 사전확인은 미래의 프로포저가 사용자의 트랜잭션을 블록에 포함시키겠다는 약속을 사전에 제공하는 구조로 동작합니다. 구체적으로는 다음과 같죠.

1. L2 블록의 시퀀싱을 맡은 미래의 L1 프로포저가 사용자의 L2 트랜잭션을 자신이 제안할 블록에 포함하겠다는 서명된 약속(사전 확인)을 제공
2. 롤업 노드들은 이 약속을 미리 적용해 해당 트랜잭션을 포함한 블록을 생성
3. 지갑이나 애플리케이션은 이 정보를 기반으로 사용자에게 거래 결과를 즉시 보여줌

이렇게 하면 실제 블록이 생성되기 전에도 사용자는 자신의 트랜잭션이 어떤 결과를 낼지 미리 확인할 수 있습니다. 결과적으로 롤업 블록 타임이 12초로 유지되더라도, 사용자는 마치 “즉시 컨펌되는” 듯한 체감 속도를 경험하게 될 수 있죠.

이러한 기반 사전확인 구조는 기반 롤업뿐만 아니라 L1 UX 자체의 개선에도 기여할 수 있습니다. 미래의 프로포저가 사용자의 L1 트랜잭션 실행을 보증하면, 지갑이나 앱은 이 약속을 사용자 인터페이스에 반영하여 즉각적인 피드백을 제공할 수 있는 것이죠. 즉, 사용자는 실제 블록 포함 전에도 “거래가 확정되었다”고 느끼게 되는 것입니다. 이는 단순히 체감 속도의 향상을 넘어, 이더리움의 전반적인 사용자 경험을 개선할 수 있는 기술로 평가받습니다.

이 기반 사전확인에서 가장 중요한 요소 중 하나는, 프로포저가 사용자에게 이러한 약속을 안정적이고 신뢰성 있게 제공할 수 있는 인프라가 존재해야 한다는 점입니다. 이더리움에서 그 역할을 담당하는 것이 바로 Commit-Boost입니다.

Commit-Boost는 프로포저가 안전하게 사전 확인과 같은 약속을 제공할 수 있도록 하는 사이드카 소프트웨어입니다. 현재 Commit-Boost는 이더리움 네트워크의 다수 밸리데이터와 기업들의 지지를 받으며 빠르게 점유율을 확장하고 있으며, 실제로 최근 기준 이더리움 밸리데이터 중 약 31.2%가 Commit-Boost를 사용하고 있는 것으로 알려져 있습니다. Primev의 mev-commit과 같은 프로덕트는 Commit-Boost를 사용하여 이더리움 메인넷에서 수십 밀리초 단위의 컨펌을 지원하기도 합니다.

(이더리움 메인넷 밸리데이터들의 사이드카 사용 비율 | 출처: Commit-Boost)

그러나, 현재 기반 사전확인 프로토콜은 완벽하지 않으며, 엣지 케이스가 발생해 밸리데이터가 제공한 약속이 실현되지 않을 수 있는 가능성이 존재합니다. 이는 이더리움의 블록 프로포저 선정 로직 때문입니다.

이더리움의 블록들은 에포크 단위로 분류되며, 한 에포크마다 32개의 슬롯이 존재합니다. 하나의 슬롯에는 하나의 프로포저가 선정되며, 이들이 블록을 제안하게 됩니다. 이때 한 에포크 내 프로포저는, 이전 에포크의 정보를 기반으로 정해집니다. N+1번째 에포크 내 32개의 슬롯을 제안할 32개의 프로포저는 N번째 에포크의 정보를 기반으로 정해지죠. 이를 조금 더 자세히 설명하면 다음과 같습니다.

(기존 프로포저 선정 방식 | 출처: Lin Oshitani X)

먼저, 이더리움 프로포저들의 커밋으로 계산되는 RANDAO 값을 기반으로 랜덤 시드를 생성합니다. 이 RANDAO 값은 이전 에포크들의 값을 활용하므로, 에포크마다 고정되어 있습니다.

1. 이후, 현재 에포크 내의 활성 밸리데이터 목록을 가져옵니다.
2. 마지막으로, 밸리데이터 스테이크(활성 잔고, effective balance)를 가중치로 사용하여, 1번에서 생성한 랜덤 시드값을 기반으로 블록 프로포저를 선택합니다.

이때, 다음 에포크에서 블록을 제안할 32명의 프로포저를 계산하는 것은 결정론적이지 않았는데, 그 이유는 프로포저 계산 로직에 각 밸리데이터의 유효 잔액이 들어가기 때문입니다. 예를 들어, 에포크 N의 프로포저로 선정될 예정이던 밸리데이터 A가 에포크 N 직전에 슬래싱을 당하는 등 유효 잔액이 감소한다면, A는 더 이상 유효한 후보로 간주되지 않아 에포크 N의 프로포저 명단에서 제외될 수 있습니다. 결국, 에포크 N의 프로포저 셋은 이전 에포크(N-1) 시점에서 예측이 가능하기는 하지만, 그 예측의 결과가 에포크 N이 실제로 시작되기 직전의 상태 변화(슬래싱, 출금, 보상 등)에 따라 얼마든지 달라질 수 있었던 것입니다.

EIP-7917은 이러한 비결정적 프로포저 선정 과정에서 발생하던 엣지 케이스를 해결하기 위해 도입된 제안입니다. 이 개선안을 통해, 에포크 내에서 선정될 프로포저 리스트가 완전히 결정론적으로 계산되도록 변경되었습니다.

(EIP-7917에서의 프로포저 선정 방식 | 출처: Lin Oshitani X)

EIP-7917이 적용된 합의 레이어에서는 proposer_lookahead라는 새로운 필드가 비콘 체인의 상태에 추가됩니다. 이 필드는 현재 에포크와 다음 에포크의 슬롯에 대한 프로포저 정보를 미리 저장하는 배열로, 총 64개의 인덱스를 포함합니다(한 에포크당 32슬롯 × 2). 즉, 이 배열은 “지금 에포크와 그 다음 에포크의 각 슬롯에서 누가 블록을 제안할 것인지”를 명시적으로 기록합니다. 매 에포크가 종료될 때마다 밸리데이터들은 이 proposer_lookahead 배열을 갱신합니다. 이미 지난 슬롯의 프로포저 정보는 제거하고, 새롭게 다가올 “다다음 에포크”의 프로포저를 계산하여 배열의 뒤쪽에 추가하는 방식입니다. 이 과정을 통해 시스템은 항상 현재 및 다음 에포크에 대한 완전한 프로포저 스케줄을 보유하게 됩니다.

결과적으로 EIP-7917의 도입으로, 밸리데이터들은 다음 에포크의 블록 프로포저들을 에포크가 끝나기 전, 즉 6.4분에서 최대 12.8분 전에 미리 확인할 수 있게 되었습니다. 이러한 결정론적 프로포저 예측은 기반 사전확인 프로토콜의 신뢰성과 안정성을 크게 향상시킵니다. 프로포저가 미리 확정되므로, 사용자는 미래 블록 프로포저와 안전하게 상호작용할 수 있고, 이를 통해 사전확인의 보증력을 크게 높일 수 있게 되죠.

EIP-7939: 특정 연산 비용을 더 저렴하게, CLZ 명령어

EIP-7939는 EVM에 새로운 연산 명령어(opcode)인 CLZ(Count Leading Zero)를 추가하자는 제안입니다.

CLZ는 ‘주어진 바이트 앞에 얼마나 많은 0이 존재하냐를 계산’하는 명령어이며, 많은 프로그래밍 언어에서 기본 연산으로 내장되어 있습니다. 대표적인 예시는 다음과 같습니다.

• rust: [n.leading_zeros()](https://doc.rust-lang.org/std/primitive.u64.html#method.leading_zeros)
• Go: [bits.LeadingZeros64(n)](https://pkg.go.dev/math/bits#LeadingZeros64)
• C++: [std::countl_zero(n)](https://en.cppreference.com/w/cpp/numeric/countl_zero)
• C: [stdc_leading_zeros(n)](https://en.cppreference.com/w/c/numeric/bit/stdc_leading_zeros)

이 명령어는 수학적 연산(예: 로그, 제곱근, 거듭제곱)이나 비트맵 관리, 데이터 압축/해제, 바이트 스트링 비교 등에서 효율적으로 사용됩니다.

현재 이더리움 스마트 컨트랙트나 EVM은 이 기능을 네이티브하게 지원하지 않기 때문에, 동일한 기능을 구현하려면 여러 번의 시프트 연산(shr, shl)이나 조건문 등을 사용해야 합니다. 이런 방식으로 구현된 코드는 크기도 크고 가스 비용 역시 효율적이지 못하죠. 다음은 현재 가장 가스 효율적으로 설계된 CLZ 코드 중 하나이며, 이를 실행하는 데에는 약 180가스~300가스가 소모됩니다.

function countLeadingZeroBytes(x_) -> _r {
    _r := shl(7, lt(0xffffffffffffffffffffffffffffffff, x_))
    _r := or(_r, shl(6, lt(0xffffffffffffffff, shr(_r, x_))))
    _r := or(_r, shl(5, lt(0xffffffff, shr(_r, x_))))
    _r := or(_r, shl(4, lt(0xffff, shr(_r, x_))))
    _r := xor(31, or(shr(3, _r), lt(0xff, shr(_r, x_))))
}

따라서 이 CLZ opcode를 추가하면 계산 비용을 줄이고, 바이트코드 크기를 줄일 수 있습니다. 이는 특히 ZK 증명 환경에서 이득이 클 수 있습니다. 기존 CLZ 함수는 시프트 연산(shr,shl)을 기반으로 구현되어 있는데, 시프트 연산은 서싱트(Succinct)의 SP1 기준으로 증명 생성 비용이 곱셈(MUL)의 1.6배인, 상대적으로 비싼 연산입니다. CLZ 함수에서는 위와 같이 시프트 연산을 여러 번 수행하기 때문에, 이에 대한 ZK 증명 생성 비용도 꽤 들어갔죠. 이를 네이티브하게 EVM에서 구현하게 된다면, ZK 증명 생성이 더 저렴해질 수 있습니다.

EIP-7939로 도입되는 CLZ 명령어는 EVM 내 스택에서 하나의 256비트 값 x를 빼서, 그 값의 가장 상위 비트 기준부터 앞에 연속으로 있는 ‘0’의 개수를 계산해 스택에 다시 밀어넣습니다. 예를 들어 x = 0x00FF… 식이라면 상위부터 연속된 0 비트가 몇 개인지 계산해 2를 반환합니다. 만약 x = 0 이면 결과로 256을 리턴합니다.

이 연산의 가스 비용은 곱셈(MUL)과 같은 5로 설정되었으며, 앞에서 보았듯이 현재 가장 저렴한 CLZ 구현이 180가스~300가스 가량을 사용하는 것을 고려하면 약 36배에서 60배 가량 더 저렴한 수준입니다.

이러한 CLZ(Count Leading Zeros) 명령어의 도입은 개발자 경험을 크게 향상시킵니다. 기존에는 솔리디티 개발자들이 수학적 연산을 효율적으로 구현하기 위해 이른바 ‘매직 넘버(Magic Number)’ 또는 ‘데 브루잉 상수(De Bruijn Constant)’를 직접 계산해야 했습니다. 하지만 이제 CLZ를 사용하면, 복잡한 수학적 트릭 없이 단일 명령어 한 줄로 동일한 연산을 수행할 수 있습니다.

예를 들어 아래 코드(출처: Solady의 FixedPointLib)는 EVM에서 log2 함수를 구현하기 위한 전형적인 예시입니다. 이는 값 x의 최상위 비트(MSB, Most Significant Bit)의 위치를 찾는 과정으로, 반복문 없이 비트 조작과 데 브루잉 상수 및 룩업 테이블를 활용해 효율적으로 계산합니다.

/// @dev Returns the log2 of `x`.
/// Equivalent to computing the index of the most significant bit (MSB) of `x`.
/// Returns 0 if `x` is zero.
function log2(uint256 x) internal pure returns (uint256 r) {
    /// @solidity memory-safe-assembly
    assembly {
        r := shl(7, lt(0xffffffffffffffffffffffffffffffff, x))
        r := or(r, shl(6, lt(0xffffffffffffffff, shr(r, x))))
        r := or(r, shl(5, lt(0xffffffff, shr(r, x))))
        r := or(r, shl(4, lt(0xffff, shr(r, x))))
        r := or(r, shl(3, lt(0xff, shr(r, x))))
        // forgefmt: disable-next-item
        r := or(r, byte(and(0x1f, shr(shr(r, x), 0x8421084210842108cc6318c6db6d54be)),
            0x0706060506020504060203020504030106050205030304010505030400000000))
    }
}

코드 맨 아래줄에 보면 랜덤하게 보이는 긴 숫자 두 개가 있는데, 이 숫자를 각각 데 브루잉 상수와 룩업 테이블이라고 부릅니다. 이를 활용하면 반복문을 사용하지 않고도 정해진 길이의 바이트 내에서 최상위 바이트의 위치를 계산할 수 있기 때문에, 연산 비용이 중요한 솔리디티에서는 복잡한 수학 연산을 저렴하게 수행하기 위해 이러한 기법을 많이 사용합니다.

이제 개발자들은 수학적 연산을 구현하기 위해 복잡한 데 브루잉 상수와 룩업 테이블을 직접 계산할 필요 없이, 단순히 CLZ 명령어 하나로 동일한 결과를 얻을 수 있게 되었습니다. 이로 인해 코드가 훨씬 간결해지고, 연산 비용과 코드 사이즈 모두 감소합니다.

또한 CLZ 명령어는 ZK 증명을 생성할 때에도 큰 장점을 제공합니다. 복잡한 비트 연산을 줄이고 연산 경로를 단순화하기 때문에, 증명 생성 효율이 크게 향상되어 개발자 입장에서 성능 최적화까지 함께 기대할 수 있습니다

아래는 실제 CLZ 명령어로 효율화될 수 있는 몇 가지 예시들을, EIP-7939가 이미 적용된 세폴리아 네트워크 기준으로 테스트해본 결과입니다. 아래 표는 Solady 라이브러리 내의 함수 중 여러 입력값을 압축하는 케이스([LibZip.cdCompress](https://github.com/Vectorized/solady/blob/836c169fe357b3c23ad5d5755a9b4fbbfad7a99b/src/utils/LibZip.sol#L167))와 제곱근 연산에 대해, CLZ 명령어가 적용되었을 때와 그렇지 않은 때를 비교한 테이블입니다.

** 절대적인 가스량은 컨트랙트 호출 및 최적화 등의 변수가 끼어있어, 실제 사용에서와 값이 다를 수 있습니다.

CLZ 명령어가 적용되면 작게는 몇백 가스부터, 입력값에 따라 몇천 가스까지 아껴지는 것을 볼 수 있죠. 자세한 코드와 테스트 결과는 아래 레포지토리에서 확인하시길 바랍니다.

[embed]GitHub - sm-stack/efficient-clz: Test suites benchmarking the gas savings achieved with the CLZ… Test suites benchmarking the gas savings achieved with the CLZ opcode. - sm-stack/efficient-clzgithub.com

정리하자면, EIP-7939는 주어진 바이트 앞에 0이 몇 개인지 세는 CLZ 명령어를 도입함으로써 개발자 경험을 개선하고 연산 비용을 줄일 수 있게 도와줍니다.

EIP-7951: 패스키를 이더리움으로

이더리움은 ERC-4337로 대표되는 계정 추상화 기술을 성공적으로 도입하였습니다. 계정 추상화 기술의 핵심 이점 중 하나는, 기존 secp256k1 기반 ECDSA 서명 외에 다른 서명 알고리즘 지원이 가능하다는 점입니다. 예를 들어, 계정 추상화 지갑 사용자는 일반 지갑들과 같이 니모닉을 안전한 곳에 적어둘 필요 없이, 패스키와 같이 Web2에서 사용하던 인증 기법을 통해 지갑을 생성할 수 있죠.

다른 서명 알고리즘을 지원하는 행위는 어떻게 가능한 걸까요? 핵심은, 지갑을 컨트랙트 형태로 구성한 뒤 컨트랙트의 검증 함수에서 특정 서명의 검증 로직을 구현하는 것입니다. 사용자에게 해당 알고리즘으로 이뤄진 서명을 받아, 이 컨트랙트의 검증 함수를 호출해 권한 검증 후 액션을 수행하는 방식이죠.

여기서 중요한 점은 컨트랙트 위에 구현된 서명 검증 로직의 비용입니다. 이더리움에서 기본 서명 로직인 secp256k1 기반 ECDSA 서명 검증은 프리컴파일 컨트랙트로 구현되어 있어 3,000 가스 정도의 저렴한 비용만 소모되는 반면에, 커스텀한 서명을 검증하는 코드를 EVM 위에서 구현하려면 여러 암호학 관련 로직들의 오버헤드로 인해 매우 큰 비용이 들 수 있습니다. 예시로, 양자저항 서명 중 하나인 Dilithium 서명 알고리즘의 초기 구현체들은 검증에만 거의 현재 이더리움 블록의 2/3에 해당하는 30M만큼의 가스를 사용하기도 했죠.

이 때문에 서명 검증의 경우 오프체인 처리가 가능한 프리컴파일 컨트랙트로 구현되는 것이 비용 측면에서 압도적으로 유리합니다.

EIP-7951은 일반적으로 가장 많이 사용되는 서명 알고리즘 중 하나인 P-256(secp256r1)의 서명 검증 로직을 프리컴파일 컨트랙트로 구현합니다. 이 서명 알고리즘은 애플의 Secure Enclave, 안드로이드 키스토어, FIDO2/WebAuthn 디바이스 등 많은 하드웨어 기반 키 저장소와 보안 모듈에서 기본으로 지원되며, TLS 클라이언트 인증이나 기업용 PKI 등 기존 보안 인프라와도 널리 호환됩니다. 따라서 EIP-7951로 P-256 검증을 네이티브 프리컴파일로 제공하면, 휴대폰이나 브라우저에 내장된 하드웨어 키(예: 지문/생체인증으로 잠긴 개인키)를 직접 체인 상의 서명 검증에 사용할 수 있게 됩니다.

이 기능은 사실 이미 여러 L2에서 RIP(Rollup Improvement Proposal, 롤업 개선 제안) 형태로 먼저 실험된 바 있습니다. 그중 첫 번째 제안이자 P-256 서명 검증 로직을 프리컴파일로 구현한 RIP-7212는, 아비트럼/옵티미즘/베이스/지케이싱크 등 주요 이더리움 L2에서 모두 채택되었습니다.

이 기능을 가장 활발히 활용하는 대표적인 사례가 바로 베이스 앱(Base App)입니다. 베이스 앱은 패스키 기반 서명을 기반으로 구현된 스마트 컨트랙트 월렛을 내장하고 있으며, 별도의 니모닉 저장 등이 필요 없는 원활한 온보딩 프로세스와, FaceID 인증으로 트랜잭션을 보낼 수 있는 좋은 UX를 가지고 있습니다.

이번 EIP-7951은 이 RIP-7212에 존재하였던 보안 관련 엣지 케이스들을 보완하여 이더리움 메인넷 위에 적용하는 것으로 보아도 무방합니다. 즉, 이더리움 메인넷에서도 이제 패스키 서명을 기반으로 하는 베이스 월렛이나 포르투(Porto)와 같이 좋은 UX를 가진 스마트 월렛을 저렴하게 활용할 수 있을 것으로 기대되네요.

Conclusion

정리하자면, 후사카 업그레이드는 L2 스케일링, L1 스케일링, UX 개선이라는 세 가지 목표에 맞춰 프로토콜에 아래와 같은 크고 작은 개선들을 추가합니다.

• 블롭 수수료 시장 정상화
• L1 확장에 필요한 리소스 조정
• L1 확장 과정에서 발생하는 엣지 케이스 방어
• P2P 프로토콜의 효율 개선
• 사전확인 프로토콜의 신뢰성 증가
• 계산 비용 절감
• 스마트 계정 비용 절감

무엇보다도 후사카 업그레이드는 PeerDAS라는 기술을 통해 롤업을 위한 블롭 용량을 최대 8배까지 늘리는 기반을 다집니다. BPO 하드포크를 통해 이더리움 메인넷은 내년 초까지 L2에 800~1000 TPS만큼의 처리량을 안정적으로 제공할 수 있으며, 예정되어 있는 여러 개선들을 기반으로 내년 말 혹은 내후년까지 L2의 총 처리량을 최대 10,000 TPS 이상까지 올릴 수 있을 것이라 기대됩니다.

(TPS 추측치는 체인마다의 압축 효율 및 데이터 제출 형태에 따라 이보다 훨씬 커질 수 있습니다. 예를 들어, 라이터에서는 트랜잭션 데이터 전체 말고 상태 차이만을 제출하기 때문에, 현재 이더리움의 블롭 타겟 6개 내에서도 2000–3000 TPS를 안정적으로 처리하고 있기 때문에, 저 수치에 다다르면 롤업들의 TPS는 100K가 넘어갈 수도 있습니다.)

예정된 추가 개선들이 순차적으로 적용되면, 내년 말 혹은 내후년에는 L2 전체의 총 처리량이 10,000 TPS를 넘어설 가능성도 충분히 있습니다. 이는 단순한 수치 이상의 의미를 갖습니다. 베이스, 아비트럼, OP 메인넷, 월드체인, 지케이싱크, 스타크넷, 스크롤 등 주요 롤업들이 지금보다 훨씬 큰 사용자 수요를 감당할 수 있게 될 뿐만 아니라, 기관급 트래픽까지 수용 가능한 새로운 세대의 롤업 생태계가 열리는 전환점이 될 것입니다.