월간 EIP - 2026년 2월 (ft. 이더리움의 로드맵을 당기는 건 AI가 아닌, 거버넌스다)

Key Takeaways

• 2월에는 컨트랙트 및 코어 / 네트워킹 레이어 전반에서 이더리움의 확장성을 강화하기 위한 신규 EIP들이 다수 등장했으며, 기존 제안들도 블롭 메커니즘 최적화와 UX 개선을 중심으로 발전했다. 이는 롤업 중심 확장 구조를 유지하면서도 L1 효율성과 개발자 경험을 동시에 개선하려는 방향성을 보여준다.

• 글램스테르담 이후 업그레이드인 헤고타에서는 합의 레이어 헤드라이너로 FOCIL(EIP-7805)이 선정되었고, 실행 레이어 헤드라이너로는 프레임 트랜잭션(EIP-8141)의 채택 가능성이 높게 논의되고 있다. 동시에 저스틴 드레이크의 Strawmap 로드맵이 공개되며, 2029년까지 7개 포크를 통해 Fast L1, Gigagas L1, Teragas L2, Post-quantum 보안, L1 프라이버시를 구현하는 장기 발전 경로가 제시되었다.

• 한편, AI 기반 에이전틱 개발 스택의 확산으로 이더리움 로드맵 가속 가능성이 제기되고 있지만, 실제 프로토콜 진화 속도를 좌우하는 병목은 여전히 커뮤니티 거버넌스다. 따라서 거버넌스 프레임워크의 진화와 함께 이더리움의 비전·맥락·코어 기술을 깊이 이해한 참여자들의 온보딩이 로드맵 가속의 핵심 변수로 작용할 것이다.

이더리움은 스마트 컨트랙트라는 개념을 기존의 분산 원장 구조에 접목하며 블록체인의 새로운 지평을 열었다. 이러한 설계 철학은 EIP(Ethereum Improvement Proposal)라는 형태를 통해 점진적으로 구체화되었고, 그 결과 블록체인은 단순한 가치 저장 수단을 넘어 실제 비즈니스와 다양한 유스케이스를 담아낼 수 있는 인프라로 진화하고 있다. 이러한 발전의 흐름 속에서, 각기 다른 시각과 문제의식을 지닌 오피니언 리더들이 EIP 논의에 더욱 폭넓게 참여한다면, 우리가 그려보는 디지털 네이티브한 미래 역시 한층 더 풍부해질 수 있을 것이다.

본 아티클은 매월 새롭게 ‘Draft’ 단계로 채택되는 제안들과, 그 과정에서 상태(status)가 변화하는 주요 제안들을 하이레벨에서 조망하며 EIP 트렌드를 정리한다. 이를 통해 빌더와 비즈니스 관계자들이 EIP의 흐름과 맥락을 보다 입체적으로 이해하고, 나아가 각자의 영역에서 새로운 가치를 제안하는 데 참고할 수 있는 출발점이 되기를 기대한다.

본 아티클과 관련된 EIP 데이터는 EIP, ERC, RIP 공식 깃허브 레포지토리를 각각 활용해 수집·분석되었다.

1. 저자의 코멘트

2월의 EIP 흐름에서 가장 두드러진 점은 컨트랙트(Contract) 및 코어(Core) / 네트워킹(Networking) 레이어 전반에서 이더리움의 확장성을 강화하기 위한 신규 제안들이 다수 등장했다는 점이다. 특히 실행 환경과 프로토콜 구조를 보다 유연하게 만들기 위한 다양한 설계들이 논의되었으며, 기존 EIP들의 진전 역시 블롭(blob) 메커니즘 최적화와 사용자 경험(UX) 개선을 중심으로 이루어졌다. 이는 이더리움이 롤업 중심 확장 구조를 유지하는 동시에 L1의 효율성과 개발자 경험을 함께 개선하려는 방향성을 보여준다.

한편, 글램스테르담(Glamsterdam) 이후 예정된 업그레이드인 헤고타(Hegota)의 헤드라이너를 둘러싼 논의 역시 2월 한 달 동안 주요 화두였다. 합의 레이어 헤드라이너로는 FOCIL(Fork-choice Enforced Inclusion Lists, EIP-7805)*이 선정되었으며, 실행 레이어 헤드라이너 후보로는 여러 옵션이 논의되었지만 현재로서는 프레임 트랜잭션(Frame Transaction, EIP-8141)**이 채택될 가능성이 높은 상황이다.

*FOCIL은 특정 블록 빌더가 임의로 트랜잭션을 배제하지 못하도록 검증자 위원회(Committee)가 포함해야 할 트랜잭션 목록을 제시하고 이를 블록에 강제 반영하도록 하는 프로토콜 규칙을 제안하는 EIP이다. 결과적으로 EIP-7805는 이더리움의 핵심 가치인 검열 저항성과 신뢰할 수 있는 중립성(credible neutrality)을 프로토콜 수준에서 강화하는 메커니즘으로 평가된다.

**프레임 트랜잭션에 관한 설명은 이전 포스팅을 참조하기 바란다.

Source: Strawmap | Justin Drake

이와 함께 저스틴 드레이크(Justin Drake)가 공개한 장기 로드맵 ‘Strawmap’ 역시 중요한 논의 주제로 떠올랐다. 해당 로드맵은 6개월 간격의 7개 포크를 통해 2029년까지 Fast L1(1초 슬롯), Gigagas L1(~10K TPS), Teragas L2(~10M TPS), Post-quantum 보안, L1 프라이버시 트랜잭션을 단계적으로 구현하는 것을 목표로 한다. 기존 로드맵이 기술적 방향성을 제시하는 데 초점을 맞췄다면, Strawmap은 각 기술이 어떤 포크에서 어떤 순서로 구현될지에 대한 실행 경로를 보다 구체적으로 제시했다는 점에서 의미가 있다.

2. 새로이 제안된 EIP들

2월 한달 간 새로이 ‘Draft’로 채택된 EIP의 수는 총 22개로, 전월대비 2개가 감소하였다. 당월의 새로운 드래프트 상태의 EIP는 코어(Core)와 ERC가 주를 이루었고, 적지않은 수의 네트워킹(Networking) 및 메타(Meta)에 해당하는 EIP가 제안된 것도 주목할만하다.

아래는 새로이 드래프트로 채택된 EIP들을 더욱 세부적으로 분류해보고, 특별히 주요깊게 살펴볼만한 EIP들을 살펴본다.

2.1 코어 / 네트워킹 레이어

2.1.1 EIP-8105: Universal Enshrined Encrypted Mempool

이더리움의 공개 멤풀(public mempool)의 구조는 오랫동안 네트워크의 개방성과 투명성을 상징하는 핵심 요소로 기능해 왔다. 하지만 이는 동시에, 트랜잭션이 블록에 포함되기 전에 누구에게나 노출된다는 의미이기도 하며, 결과적으로 프론트러닝(front-running)이나 샌드위치 공격(sandwich attack)과 같은 악의적인 MEV 전략을 가능하게 하는 근본적인 구조적 취약점으로 지적되어 왔다.

특히 디파이(DeFi) 활동과 규모가 증가하면서 이러한 공격은 점점 더 정교해졌고, 사용자 경험과 시장 공정성을 저해하는 주요 원인으로 자리 잡았다. 최근 몇 년간 프라이빗 오더 플로우(private order flow)와 MEV 릴레이가 빠르게 확산된 것도 이러한 문제를 우회하려는 시장의 자발적 대응이라 볼 수 있겠다. 하지만 이러한 접근 방식 역시 거래 흐름을 특정 인프라 사업자에게 집중시키는 부작용을 낳아왔으며, 이더리움이 추구해온 탈중앙성과 중립성을 약화시킬 가능성 또한 제기되어 왔다. EIP-8105는 이러한 문제를 해결하기 위한 프로토콜 레벨의 접근으로써, “Universal Enshrined Encrypted Mempool(EEM)”이라는 새로운 트랜잭션 전달 구조를 제안한다.

EIP-8105의 핵심 아이디어는 트랜잭션의 페이로드(payload)를 암호화된 상태로 멤풀에 전파하고, 블록에 포함되는 순서가 확정되기 전까지 그 내용을 누구도 확인할 수 없도록 만드는 것이다. 즉, 사용자는 암호화된 트랜잭션과 함께 최소한의 메타데이터만을 포함한 ‘envelope’를 제출하며, 블록 빌더는 해당 트랜잭션의 경제적인 정보를 알 수 없는 상태에서 이를 블록에 포함하게 된다.

이 구조에서 중요한 점은 페이로드가 암호화되어 멤풀에 존재한다는 것이다. 블록 빌더는 ‘envelope’만을 기준으로 트랜잭션을 블록에 포함시키며, 실제 실행에 필요한 정보는 이후 복호화 단계에서 공개된다.

트랜잭션 처리 흐름 역시 기존 이더리움과 다르게 작동한다. 현재 이더리움에서는 트랜잭션이 멤풀에 도달하는 순간 그 내용이 공개되기 때문에, 서처(searcher)나 빌더(builder)는 이를 기반으로 거래를 재정렬하거나 선행 실행할 수 있다. 반면 암호화된 멤풀(encrypted mempool)에서는 다음과 같은 흐름이 적용된다.

1. 사용자는 암호화된 트랜잭션을 제출한다

2. 네트워크는 암호화된 페이로드를 전파한다

3. 빌더는 블록에 암호화된 트랜잭션을 포함한다

4. 순서(ordering)가 확정(final)된다.

5. 복호화 과정이 진행되고, 트랜잭션은 실행된다

이 과정에서 핵심은 오더링 이전에는 누구도 트랜잭션 내용을 알 수 없다는 점이다. 따라서 서처가 거래를 앞질러 실행하거나 특정 거래를 의도적으로 재정렬하는 전략 자체가 구조적으로 불가능해진다. 결과적으로, 이러한 구조를 통해 MEV의 상당 부분을 차지하는 악의적인 전략을 제거하는 효과를 기대할 수 있다.

더 중요한 점은 이러한 설계가 단순히 MEV 공격을 줄이는 기술적 개선에 그치는 것 이상의 의의를 가질 수 있다는 점이다. 암호화된 멤풀은 프라이빗 릴레이(private relay)의 의존도를 낮추고, 다시 공개 멤풀을 신뢰 가능한 조정 레이어(coordination layer)로 복원하려는 시도라는 점에서 이더리움의 네트워크 구조 전반에 영향을 미칠 수 있다. 특히 프로포저-빌더 분리(proposer-builder separation, PBS)이나 FOCIL과 같은 검열 저항성 메커니즘들과 결합될 경우, 암호화된 멤풀은 블록 생산 구조, 거래 오더링의 공정성, 검열 저항성을 동시에 강화하는 핵심 인프라로 작동할 수 있을 것이다.

2.1.2 EIP-8130: Account Abstraction by Account Configuration

이더리움의 장기적인 사용자 경험 개선 로드맵에서 가장 중요한 축(pillar) 중 하나는 계정 추상화(Account Abstraction)이다*. EIP-8130 역시 이러한 흐름 속에서 등장한 제안으로, 계정이 사용하는 인증 방식을 “Account Configuration(계정 구성)”이라는 구조(struct)로 선언적으로 정의하고 이를 프로토콜이 직접 해석할 수 있도록 만드는 것을 목표로 한다.

이더리움의 계정 모델은 오랫동안 단일 서명 방식에 기반한 단순한 구조를 유지해 왔다. 일반적인 EOA는 secp256k1 기반의 서명 검증을 통해 트랜잭션을 승인하며, 검증 방식 자체는 프로토콜에 사실상 고정되어 있다. EIP-8130은 이러한 구조적 한계를 확장하기 위한 제안으로, 계정이 사용하는 인증 방식을 ‘Account Configuration’ 형태로 선언하고 프로토콜이 이를 직접 해석하도록 설계한다. 이를 통해 계정은 더 이상 단일 키 기반의 인증에 제한되지 않으며, 다양한 인증 모델을 유연하게 수용할 수 있는 기반을 갖게 된다.

*계정 추상화를 다루는 수많은 표준들에 대한 설명은 본 아티클에선 생략한다. 한편, 지난 아티클에서는 새로운 트랜잭션 구조를 통해 확장성 있는 계정 추상화를 구현하려는 프레임 트랜잭션(EIP-8141)에 대해 설명한 바 있다. 서론에서 설명한 바와 같이, 프레임 트랜잭션은 다음 헤고타 업그레이드에 포함될 수 있는 유력한 표준이다.

EIP-8130의 핵심 구조는 계정이 인증 키와 정책을 구조화된 데이터 형태로 관리하도록 만드는 것이다. 제안된 IAccountConfig 인터페이스에는 계정의 인증 키와 관련된 여러 구조체가 정의되어 있으며, 그 중심에는 InitialKey와 AuthKey가 있다. InitialKey는 계정 생성 시 설정되는 기본 인증 키를 의미하며, AuthKey는 실제 트랜잭션 서명에 사용되는 인증 키를 나타낸다. 각 키는 verifier 계약과 keyId를 통해 식별되며, 서명 검증은 특정 검증 컨트랙트(verifier contract)가 수행하도록 설계된다.

또한 EIP-8130은 단순히 인증 방식을 확장하는 것에 그치지 않고, 계정 수준의 정책 및 보안 관리 기능을 함께 포함한다. AccountOperation 구조체는 계정 정책을 변경하거나 잠금 상태를 관리하기 위한 작업을 정의하며, KeyOperation은 인증 키의 추가 및 제거와 같은 키 관리 작업을 담당한다. 특히 requestUnlock과 unlockDelay와 같은 메커니즘은 계정 정책 변경에 시간 지연 기반 보안 모델(timelock)을 도입하여, 민감한 권한 변경이 즉시 실행되는 것을 방지할 수 있도록 할 수 있다. 이러한 설계는 계정 자체가 단순한 서명 주체가 아니라 정책과 보안 로직을 포함하는 실행 환경으로 확장 기능할 수 있음을 시사한다.

결국, 계정 추상화의 장기적인 발전 방향은 인증 방식의 진화에 대한 유연성 확보다. 이러한 점에서, EIP-8130의 계정의 검증 로직은 구성(configuration) 기반으로 정의되기 때문에 새로운 서명 스킴이나 인증 모델을 비교적 쉽게 도입할 수 있다 - 예를 들어 멀티시그 정책, 패스키 기반 인증, 키 회전(key rotation), 가스 스폰서십 등 다양한 계정 기능을 동일한 구조 안에서 표현할 수 있으며, 향후 등장할 새로운 암호학적 인증 방식에도 자연스럽게 대응할 수 있다.

2.1.3 EIP-8142: Block-in-Blobs (BiB)

이더리움의 확장 로드맵은 최근 몇 년간 실행(execution)과 데이터 가용성(data availability)의 역할을 점진적으로 분리하는 방향으로 발전해왔다 - 대표적으로 EIP-4844는 롤업 데이터 전용 공간인 블롭(blob)*을 도입하여 L2 데이터 게시 비용을 크게 낮추었고, 이더리움이 점차 실행 체인 중심 구조에서 데이터 가용성 중심 구조로 이동하고 있음을 보여주었다.

이러한 흐름 속에서 등장한 EIP-8142는 한 단계 더 나아가 실행 페이로드(payload) 자체를 블롭 데이터 구조로 이동시키는 새로운 블록 구조를 제안한다. 기존처럼 블록 본문에 트랜잭션 리스트와 관련 데이터를 직접 포함하는 대신, 실행 데이터는 블롭 단위로 패킹되어 저장되고 블록 헤더는 해당 블롭을 참조하는 방식으로 블록 구조가 재구성된다 - 이때 블록 헤더에는 해당 페이로드가 몇 개의 블롭으로 구성되는지를 나타내는 메타데이터(i.e., payload_blob_count 필드)가 포함되며, 검증 과정에서는 블롭 커밋먼트(commitment)와 KZG 증명(KGZ proof)를 통해 데이터 무결성이 확인된다.

*블롭은 롤업 데이터에만 한정될 필요는 없다 - 데이터의 압축 혹은 증명이 필요한 경우, 어느 데이터 타입이든 활용이 가능하다.

Source: bytes_to_blobs | EIP-8142

즉, 이 구조의 핵심은 실행 데이터를 블록 본문에서 분리하고, 이를 블롭 기반 데이터 가용성 레이어에 위임하는 것이다. 결과적으로 합의 레이어는 블록 헤더와 블롭 커밋먼트만 확인하면 되며, 실행 클라이언트는 필요할 때 블롭 데이터를 읽어 실제 트랜잭션 실행을 수행하게 된다.

이러한 설계는 단순한 데이터 포맷 변경 이상의 의의(implication)를 가진다. 실행 페이로드가 블롭으로 이동하면 블록 전파 과정에서 전달되는 데이터 구조가 단순해지고, 실행 데이터의 확장성 또한 보다 유연하게 확보할 수 있다. 특히 프로포저-빌더 분리(PBS) 환경에서는 빌더가 생성한 실행 페이로드를 블롭 형태로 제공하고 프로포저는 이를 헤더 수준에서 참조하는 방식도 가능해진다 - 이는 이더리움이 장기적으로 지향하는 댕크샤딩(danksharding) 기반 데이터 가용성 구조와도 자연스럽게 연결되는 설계다.

또한 EIP-8142를 주목해야하는 이유 중 하나는 이러한 구조가 zkEVM과 같은 증명 기반 실행 모델과도 잘 맞기 때문이다. zkEVM 프루버(prover)는 블록의 트랜잭션 데이터와 실행 내역(execution trace)을 읽어 증명을 생성해야 하는데, 기존 이더리움 블록 구조에서는 이러한 데이터가 실행 클라이언트 내부 구조에 깊게 묶여 있어 접근성이 제한적이었다. 반면 실행 페이로드가 블롭 형태로 제공되면 프루버는 데이터 가용성 레이어에서 데이터를 직접 읽어 증명 생성 파이프라인을 보다 단순하게 구성할 수 있다. 물론 zkEVM 지원이 EIP-8142의 직접적인 목적은 아니지만, 결과적으로 이더리움의 블록 데이터 구조가 zk에 친화적인 아키텍처(zk-friendly architecture)로 발전하는 방향성과 자연스럽게 맞물린다는 점에서 중요한 의미를 갖는다.

2.1.4 EIP-8148: Custom sweep threshold for validators*

*하기 내용은 기컨텐츠에서 다룬바 있다.

이더리움은 펙트라(Pectra) 업그레이드를 통해 최대 유효 잔액(Max Effective Balance)를 2,048 ETH까지 확장(EIP-7251)하며 벨리데이터(validator)의 수를 줄이고 합의 레이어의 대역폭 부담을 완화하려는 방향으로 나아가고 있다. 이는 단순히 상한을 조정하는 것이 아니라, 벨리데이터 통합(validator consolidation)을 통해 네트워크 확장성을 구조적으로 확보하려는 데에 의의가 있다.

이러한 전환은 실행 레이어 기반의 복리 출금 크레덴셜(compounding withdrawal credential)을 전제로 하며, 벨리데이터의 이더리움 잔액(balance)를 장기간동안 프로토콜 내부에 유지토록하는 운용 모델을 더욱 강화한다.

하지만 자동 스윕(sweep)이 사실상 고정된 임계값(i.e., 2,048 ETH)에 의존하는 구조에서는 보상이 오랜 기간 외부로 전송되지 않을 수 있고, 이는 벨리데이터로하여금 자본 회전율과 보상 가시성 측면에서 경직성을 초래한다. EIP-8148은 바로 이러한 구조를 정책 기반의 유연한 구조로 전환하려는 제안이다.

EIP-8148의 핵심은 벨리데이터가 자동 스윕 임계값(sweep_threshold)을 직접 설정할 수 있도록 허용하는 것이다. 즉, 벨리데이터의 잔액이 설정된 해당 한도까지는 복리로 누적되고, 이를 초과하는 보상만 출금지(withdrawal destination)로 자동 전송될 수 있도록 할 수 있다.

이 구조는 합의 안전성(consensus safety)을 해치지 않으면서 보상 라우팅의 타이밍만을 유연하게하는, 비교적 작은 변경(minimal state extension)에 해당한다. 즉, 슬래싱 조건이나 유효 잔액(effective balance) 계산을 변경하지 않으면서 자본 흐름 상에 정책 변수를 추가하는 설계인 셈이다.

조금 더 전략적인 관점에서 보면, 이 제안은 스테이킹을 보다 “정책적으로 설계 가능한 수익 인프라”로 전환시킬 수 있다. 예를 들어 라이도 파이낸스(Lido Finance)와 같은 대형 LST 프로토콜은 벨리데이터 통합을 통해 운영 효율을 추구하는 동시에, stVaults와 같은 전략적 볼트(vault) 구조에서 수익 분배 타이밍을 세밀하게 조정하려 한다.

이 때, 스윕 기준(threshold)을 동적으로 설정할 수 있다면, 일정 수준까지는 복리로 자본 효율을 극대화하고, 그 이후에는 실행 레이어에서 재예치, 재스테이킹(restaking), 혹은 디파이 전략에 즉시 투입하는 하이브리드 운용 모델이 가능해진다. 즉, 이는 스테이킹 보상을 단순히 “발생하는 수익” 정도로 한정짓는 것을 넘어, “라우팅 가능한 유동성”으로 재정의를 할 수 있다는 의의가 있다.

결과적으로 EIP-8148은 표면적으로는 UX 개선 제안처럼 보이지만, 그 의의는 여러 이해관계자에 걸쳐 매우 구조적으로 보인다. MaxEB 확장과 벨리데이터 통합이라는 프로토콜 단의 거시적인 설계가 지속 가능하려면, 개별 벨리데이터의 자본 회전과 보상 가시성 또한 정교하게 조정되어야 한다. 이 제안은 그 간극을 메우는 미시적 보정 장치이자, 스테이킹 보상을 보다 프로그래머블한 수익 프리미티브(yield primitive)로 전환하는 과정의 일부로 볼 수 있는 것이다.

2.1.5 EIP-8159: eth/71 - Block Access List Exchange

최근 이더리움 실행 레이어의 중요한 연구 방향 중 하나는 실행 파이프라인의 병렬화(parallelization)와 상태 접근의 예측 가능성(predictability)을 높이는 것이다. 이러한 흐름 속에서 제안된 EIP-7928은 블록 실행 과정에서 접근된 모든 상태 위치(state location)를 기록하는 블록 수준 허용 리스트(Block-level Access List, BAL) 개념을 도입한다 - BAL은 블록 내에서 어떤 계정(account)과 스토리지 슬롯(storage slot)이 접근되는지를 사전에 명시함으로써, 클라이언트가 병렬 디스크 읽기, 병렬 트랜잭션 실행, 실행이 필요없는 상태 업데이트(executionless state update)와 같은 최적화를 수행할 수 있는 기반을 제공한다.

하지만 이러한 구조가 실제 네트워크 환경에서 활용되기 위해서는 단순히 현재 시점 이후의 블록 내부에 BAL을 포함하는 것만으로는 충분하지 않다. 즉, 특히 새로운 노드가 네트워크에 참여하여 과거 블록 동기화(historical block synchronization)을 수행할 때 역시, 기존 P2P 프로토콜을 통해 해당 데이터에 접근할 수 있어야 한다는 문제가 존재한다. 바로 이러한 문제를 해결하기 위해 EIP-8159가 제안되었다.

EIP-8159는 devp2p eth 프로토콜에 BAL 교환 메커니즘을 추가함으로써, 블록 실행 메타데이터가 네트워크 레벨에서도 자연스럽게 전파될 수 있도록 설계되었다. 구체적으로, EIP-8159는 블록 헤더에 block-access-list-hash 필드를 추가하고, 노드 간 BAL 데이터를 교환하기 위한 새로운 P2P 메시지를 정의한다. 이를 통해 실행 클라이언트들은 특정 블록의 BAL을 네트워크 피어로부터 요청하거나 제공할 수 있다.

Source: EIP-8159

또한 프로토콜 레벨에서는 다음과 같은 메시지 타입이 추가된다 ; GetBlockAccessLists(0x12), BlockAccessLists(0x13)

이 구조는 기존 블록 전파 구조를 크게 변경하지 않으면서도 실행 메타데이터의 별도 동기화 채널을 제공한다는 점에서 의미가 있다. 특히 BAL은 블록 본문(block body)과 달리 실행 최적화를 위한 보조 데이터이기 때문에, 이를 별도의 메시지 레이어에서 교환하도록 설계한 것은 네트워크 효율성과 역호환성(backward compatibility)를 동시에 고려한 접근이라 볼 수 있다.

2.1.6 기타

• EIP-8131: Add Auth Data to EIP-7623 Floor

• EIP-8134, 8135, 8138: Hardfork Meta - BPO

• EIP-8136: Cell-Level Deltas for Data Column Broadcast

• EIP-8149: Multi KZG Point Evaluation Precompile

2.2 데이터 / 메시징 / 트랜잭션

2.2.1 EIP-8151: Private Key Deactivation Aware ecRecover

이더리움의 계정 모델은 오랫동안 단일 프라이빗 키 기반의 EOA 서명 체계에 의존해왔다. 하지만 최근 등장한 계정 진화 흐름—특히 위임된 EOA(delegated EOA)를 도입하는 EIP-7702와 프라이빗 키 비활성화를 제안하는 EIP-7851의 조합—은 계정 보안 모델을 보다 동적인 구조로 전환하고 있다.

하지만 문제는 이더리움의 핵심 서명 검증 프리미티브인 ecrecover가 완전히 무상태(stateless)하게 동작한다는 점이다. ecrecover는 단순히 서명으로부터 주소(address)를 복구할 뿐, 해당 계정의 상태—예컨대 프라이빗 키가 이미 비활성화되었는지 여부—는 전혀 고려하지 않는다. 그 결과, 계정 보안이 점차 정책에 기반한 인증 레이어(policy-driven authentication layer)로 확장되어나가는 과정에서 기존 서명 검증 메커니즘과 새로운 계정 관리 모델 사이에 구조적 괴리가 발생한다.

이러한 문제는 단순한 이론적 결함을 넘어, 이미 DeFi 전반에 자리 잡은 서명 기반의 인증(signature-based authorization) 패턴과도 직접적으로 연결된다. 대표적인 사례가 EIP-2612의 permit 메커니즘이다. EIP-2612는 ERC-20 토큰에 permit을 도입해 사용자가 온체인 approve 트랜잭션 없이 오프체인 서명(signature)만으로 allowance 를 설정할 수 있도록 한다. 이를 통해 기존의 두 단계 트랜잭션(approve → transferFrom) 대신 단일 서명으로 approval 과 실행을 동시에 처리할 수 있으며, 현재 유니스왑(Uniswap), 아베(Aave), 커브(Curve) 등 주요 디파이 프로토콜들이 이를 널리 채택하고 있다. 하지만 이러한 시스템들은 대부분 불변 계약(immutable contract)이며 내부적으로 ecrecover를 통해 서명자(signer)를 검증하기 때문에, 계정의 키 상태 변화와 같은 새로운 보안 정책을 인지하지 못한다.

따라서 프라이빗 키가 이후에 비활성화되더라도 기존 ecrecover 로직에서는 해당 서명이 여전히 유효하게 처리될 수 있다. 즉 EIP-7851을 통해 계정이 특정 키의 사용 중단을 선언하더라도, 기존 DeFi 및 permit 기반 계약들은 이를 반영하지 못한다. 그 결과 과거 키로 생성된 서명이 여전히 ‘allowance’를 생성할 수 있는 구조적 모순이 발생하는 상황이 연출될 수 있는 것이다.

EIP-8151은 이러한 문제를 해결하기 위해 ecrecover가 프라이빗 키 비활성화 상태를 반영하도록 수정하는 방안을 제안한다. 골자는 서명으로부터 주소를 복구한 뒤 해당 계정의 프라이빗 키가 EIP-7851 기준으로 비활성화되었는지 확인하고, 비활성화 상태라면 address(0)을 반환하도록 하는 것이다. 이를 통해 기존 불변 계약(immutable contract)을 수정하지 않고도 네트워크 레벨에서 “비활성화된 키는 더 이상 유효한 서명자가 아니다”라는 보안 불변 조건(security invariant)를 유지할 수 있게 된다.

EIP-8151은 단순한 프리컴파일 수정 이상의 의미를 가진다. 이더리움은 앞으로 프로그램가능한 계정(programmable accounts), 키 회전(key rotation), 실행 위임(delegated execution), 나아가 양자 내성 전환(post-quantum migration)과 같은 방향으로 발전해나아가고자 하고있는데, EIP-8151은 이러한 흐름 속에서 서명 검증 역시 계정 상태를 반영하는 방식으로 진화해야 한다는 점을 명확히 한다. 특히 기존 디파이 등 스마트컨트랙트를 수정하지 않고도 새로운 보안 모델을 도입할 수 있다는 점에서, EIP-8151은 이더리움 계정 구조가 EOA 중심 모델에서 보다 유연한 인증 구조로 전환되는 과정에서 중요한 연결 고리로 작용할 가능성이 높다.

2.2.2 기타

• EIP-8146: Block Access List Sidecars

2.3 계정 / 컨트랙트 / 토큰 표준 / 지갑

2.3.1 ERC-8153: Facet-Based Diamonds

이더리움의 생태계가 성숙해지면서 스마트 컨트랙트의 구조 역시 단일 컨트랙트 중심의 단순한 설계에서 점차 모듈화된 시스템 아키텍처로 발전하고 있다 - 디파이, 온체인 거버넌스, 계정 추상화, 인텐트 기반의 여러 상호작용 로직 등 복잡한 애플리케이션들은 수십 개 이상의 기능 모듈을 필요로 한다. 하지만 이러한 기능을 하나의 컨트랙트에 직접 구현하는 방식은 컨트랙트 사이즈 제한(contract size limit, EIP-170) 및 업그레이드 리스크 측면에서 구조적인 한계를 드러낸다.

Source: EIP-8153

이러한 문제를 해결하기 위해 등장한 대표적인 접근 방식이 EIP-2535 다이아몬드 표준(Diamond Standard)이다. 다이아몬드 컨트랙트 구조에서는 하나의 엔트리 컨트랙트가 여러 개의 로직 컨트랙트(“facets”)로 호출을 라우팅하며, 이를 통해 사실상 무제한에 가까운 기능 확장이 가능해진다.

Source: EIP-8153

하지만 기존의 다이아몬드 구현에서는 어떤 기능이 어떤 ‘facet’에 존재하는지, 그리고 어떤 인터페이스를 지원하는지 확인하기 위해 프로젝트별로 서로 다른 방법을 사용해야 했다. 이는 여러 툴링(e.g., Hardhat, Foundry), 인덱서, 월렛, 익스프로러 등 이더리움 생태계의 툴링 레이어들과의 통합을 어렵게 만드는 요인이었다.

ERC-8153은 이러한 문제를 해결하기 위해 ‘facet’ 및 ‘function selector’ 정보를 온체인에서 표준화된 방식으로 조회할 수 있도록 하는 인터페이스를 정의한다. 이를 통해 외부 시스템은 특정 컨트랙트가 어떤 기능 모듈을 포함하고 있는지, 그리고 어떤 인터페이스를 지원하는지 기계가 읽을 수 있는(machine-readable) 방식으로 파악할 수 있게 된다.

Source: The Core Idea of ERC-8153 | ERC-8153

ERC-8153의 가장 중요한 의미는 스마트 컨트랙트의 구성가능성(composability)를 “구조적 수준(structural layer)”에서 표준화한다는 점이다. 지금까지 이더리움의 구성가능성은 주로 ABI와 인터페이스 표준(ERC-20, ERC-721 등)에 의해 이루어졌다. 하지만 프로토콜 규모가 커지면서 실제 기능은 여러 모듈에 분산되어 구현되는 경우가 많아졌고, 단순히 ABI만으로는 전체 시스템의 구조를 이해하기 어려워졌다.

결국 ERC-8153은 다이아몬드 표준(ERC-2535)이 제시한 모듈식 스마트 컨트랙트 패러다임을 개발 편의성 수준을 넘어 생태계 차원의 조정 레이어로 확장하려는 시도라 볼 수 있으며, 이는 이더리움이 점점 더 복잡한 온체인 시스템을 수용하는 과정에서 나타나는 자연스러운 진화라 보여진다.

2.3.2 기타

• ERC-8041: Fixed-Supply Agent NFT Collections

• ERC-8048: Onchain Metadata for Token Registries

• ERC-8049: Contract-Level Onchain Metadata

• ERC-8122: Minimal Agent Registry

• ERC-8126: AI Agent Registration and Verification

• ERC-8127: Human Readable Token Identifiers

• ERC-8152: Content-Addressable Logic Modules (CALM)

2.4 애플리케이션

2.4.1 기타

• ERC-8161: Transferable Tokenized Vault Requests

3. 기존 EIP들의 진전

한편, 2월 한달간은 24개의 새로이 ‘Draft’로 채택된 EIP들을 제외하고, 15개의 기존 EIP의 상태가 변화하였다. 이 중 10개의 EIP들은 최종적으로 채택되기위한 다음 단계(i.e., ‘Final’, ‘Last Call’, ‘Review’, ‘Draft’ 등의 단계)로 격상되었다. 나머지 총 5개의 EIP의 경우, 다음 단계로 가지못하고 ‘Stagnant’ 단계로 바뀐 EIP가 4개(i.e., EIP-3540, EIP-7762, EIP-7956, EIP-7957), 그리고 ‘Draft’ 단계에서 ‘Withdrawn’ 단계로 바뀐 EIP가 1개(i.e., ERC-8109)가 있다.

이번 달에 진전이 있었던 EIP 들은 기존에 논의되었던 L2 관련 EIP들부터 서명 관련, 그리고 애플리케이션 표준에서 구현되는 ERC들까지 고루 분포했다.

ERC를 제외한 EIP들 중 주목할만한 것들은 - 노드가 EIP-4844의 blob 데이터를 전체 다운로드 없이 샘플링과 KZG 증명으로 검증해 데이터 가용성을 확인할 수 있도록 하는 프로토콜로 댕크샤딩(Danksharding)을 위한 중간 단계 확장 메커니즘이기도 한 EIP-7594, EIP-7702 기반 위임된 EOA(delegated EOA)에서 기존 프라이빗 키 권한을 비활성화하고 필요 시 복구할 수 있도록 하는 메커니즘을 제안하는 EIP-7851, 블롭 기본 수수료(blob base fee)가 과도하게 낮아지는 것을 방지하기 위해 L1 가스 비용에 연동된 최소 가격을 설정하는 제안인 EIP-7918 등이 있다.

ERC들 중 주목할만한 것들은 - 지갑이 사용자 허용 정책을 기반으로 동일한 SIWE(Sign-In with Ethereum, EIP-4361) 로그인 메시지를 자동 서명할 수 있도록 하는 지갑-로컬 자동 로그인 표준인 ERC-8019, rNFT 기반 DAG 구조에서 여러 NFT 간 로열티 분배와 전파 범위를 제어할 수 있도록 하는 확장형 로열티 표준인 ERC-8034*, 그리고 ERC-20 토큰의 잔액을 “멤버십 수준”으로 해석하여 온체인에서 그룹 구성원과 권한을 표현할 수 있도록 하는 표준인 ERC-8063 등이 있다.

*이에 대해서는 이전 아티클에서 다루었다.

이 외 참고할만한 다른 EIP들은 아래와 같다.

3.1 코어 / 네트워킹 레이어

• EIP-7607: Hardfork Meta - Fusaka

3.2 데이터 / 메시징 / 트랜잭션

• ERC-8111: Bound Signatures

3.3 계정 / 컨트랙트 / 토큰 표준 / 지갑

• ERC-7656: Generalized Contract-Linked Services

3.4 애플리케이션

• ERC-7893: DeFi Protocol Solvency Proof Mechanism

4. “생각해보기” - 이더리움의 로드맵을 당기는 건 AI가 아닌, 거버넌스다

지난 몇 달 사이 소프트웨어 개발의 방식 자체가 빠르게 재편되고 있다. Claude Code, Cursor, Cline 같은 에이전틱 코딩 도구와 v0(Vercel), Lovable, Bolt.new 같은 AI-네이티브 애플리케이션 생성 플랫폼이 확산되며 이제 개발자뿐 아니라 비개발자들도 자연어 프롬프트만으로 서비스를 구축하거나 업무를 자동화할 수 있는 환경이 등장하고 있다. 이러한 흐름은 단순한 코드 보조를 넘어 여러 AI 에이전트가 IDE, 데이터베이스, API 등을 호출하며 작업을 수행하는 에이전틱 개발 스택(agentic development stack)으로 발전하고 있으며, 그 결과 개인이 여러 AI 에이전트를 활용해 아이디어를 서비스로 구현하는 속도 역시 빠르게 높아지고 있다.

이러한 흐름 속에서 우리는 자연스럽게 하나의 질문을 제기할 수 밖에 없다:

“만약 개발 생산성이 기하급수적으로 증가한다면, 장기적인 기술 로드맵을 가진 이더리움 역시 예상보다 빠르게 진화할 수 있을까?”

Source: Twitter (@yq_acc)

실제로 알트레이어(AltLayer)의 공동창업자 YQ(Yaoqi Jia)는 AI를 활용해 이더리움의 2030년 로드맵을 반영한 프로토콜 구현을 몇 주 만에 프로토타이핑하는 실험을 공개했다. 이 시도에 대해 비탈릭 부테린(Vitalik Buterin) 역시 큰 관심을 보이며, 비록 많은 버그가 존재할 수는 있지만 AI가 코딩 속도를 크게 가속하고 있으며 이러한 접근이 장기적으로 이더리움 로드맵의 실행 속도를 앞당길 가능성이 있다고 언급했다. 불과 몇 달 전만 해도 현실적으로 어려웠던 실험이 가능해졌다는 점에서, AI 기반 개발 패러다임이 블록체인 프로토콜 연구와 구현 사이클을 단축시키는 촉매로 작용할 수 있다는 점이 더욱 분명해진 것이다.

하지만 이더리움의 발전은 일반적인 소프트웨어 프로젝트와는 본질적으로 다르다. 이 네트워크는 클라이언트 개발자, 연구자, 인프라 운영자, 애플리케이션 빌더 등 다양한 이해관계자들이 오랜 기간 합의를 통해 발전시켜 온 탈중앙적 시스템이며 앞으로도 그럴 것이기 때문이다. 특히 코어와 네트워킹 레이어에서는 하나의 설계 변화가 전체 프로토콜에 광범위한 영향을 미칠 수 있기 때문에, 단순한 구현 속도보다 보안 검증과 커뮤니티 합의가 더욱 중요하다. 즉 AI가 코드를 빠르게 생성하더라도 프로토콜 변화의 실제 속도를 결정하는 병목은 여전히 커뮤니티 거버넌스에 있다. 이러한 구조를 고려하면 이더리움 인프라는 앞으로 지금보다 다소 빠르게 발전할 수는 있겠지만, 동시에 논의는 훨씬 더 신중하고 보수적인 방식으로 진화할 가능성이 크다.

반면 ERC와 같은 애플리케이션 표준은 상대적으로 깊은 프로토콜 수준의 논의를 요구하지 않는 경우가 많기 때문에, 견고하고(robust) 보수적인 이더리움 인프라 위에서 더 빠른 실험과 반복이 가능하다. 따라서 AI 기반 개발 환경이 발전할수록 새로운 제안과 구현 속도가 크게 가속될 수 있다. 다시 말해 AI가 가져올 가장 즉각적인 변화는 프로토콜의 근본 구조보다는 애플리케이션 레이어의 다양한 제안과 실험에서 먼저 나타날 가능성이 높다. 다만, 이러한 시도가 실제 채택으로 이어지는 시점은 결국 이더리움 인프라가 이를 안정적으로 수용할 만큼 성숙했을 때일 것이다.

따라서 지금 시점에서 가장 중요한 질문은 이러한 변화 속에서 1) 이더리움의 거버넌스 프레임워크와 기술 논의 구조가 어떻게 진화하는가, 그리고 2) 이더리움의 비전과 맥락, 그리고 코어 기술을 깊이 이해한 참여자들이 얼마나 더 많이 온보딩되는가이다. AI가 구현과 실험의 속도를 높일수록 서로 다른 제안 간 의존성과 시스템 안정성을 판단할 수 있는 깊은 프로토콜에 대한 이해, 그리고 네트워크가 향해야 할 방향에 대한 신중한 판단의 중요성은 더욱 커진다. 이러한 맥락에서 이더리움 재단과 커뮤니티가 장기적인 비전에 대한 합의를 강화하고, 새로운 R&D 인력을 온보딩하기 위한 이니셔티브에 더욱 힘을 기울여야 하는 이유도 분명해진다.