월간 EIP - 2026년 4월 (ft. 기관향 스테이킹 자산의 활용 시장, 준비된 프로토콜이 선점한다)

Key Takeaways

• 4월의 EIP 흐름은 1분기와 마찬가지로 코어 단의 신규 제안이 활발했으며, 특히 서명 스킴과 애플리케이션 단에서의 다양한 사례 지원들을 위한 EIP들이 두드러졌다.
• 커뮤니티 논의는 “글램스테르담/헤고타(Glamsterdam/Hegota) 업그레이드의 안전한 구성”과 “애플리케이션을 위한 신뢰할 수 있는 네트워크 기반의 강화”라는 두 축으로 전개되었다.
• 한편, 스테이킹 자산 시장의 무게중심이 온체인 활용도 높은 솔루션으로 이동하는 가운데, 웹3의 확장성과 웹2의 설명가능성을 동시에 빠르게 갖춘 프로토콜이 이 시장을 선점할 것이다.

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

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

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

1. 저자의 코멘트

4월의 EIP 흐름 역시, 1분기의 트렌드에 맞춰 코어(Core) 단에서 유의미한 수의 EIP가 새로이 제안되었다. 아래에서 더욱 살펴보겠지만, 대부분의 신규 EIP는 서명 스킴 및 어플리케이션 단에서의 다양한 사용 사례들을 확장 가능한 방식으로 지원하기 위한 EIP들이었다. 진전이 있었던 기존 EIP의 경우, 애플리케이션 단에서 구현되는 ERC 표준들이 대다수였다. 특이한 점은 지난 몇 달 간 진전이 있었던 ERC들이 연속적으로 진전이 되었다는 것이고, 또 Stagnant 단계로 격하된 EIP의 수가 지난달과 마찬가지로 4개에 달했다는 점이다.

한편, 4월의 이더리움 커뮤니티 논의는 크게 두 갈래로 전개되었다. 먼저 프로토콜 코어 단과 관련해서는 글램스테르담(Glamsterdam) 업데이트와 그 이후의 헤고타(Hegota) 업데이트를 어떤 방식으로 안전하게 구성할 것인가가 주요 쟁점이었다. ePBS, BAL, 가스 리프라이싱(gas repricing), 컨트랙트 사이즈 제한(contract size limit)처럼 서로 의존성이 큰 변경안들은 느리지만 신중하게 정리되고 있으며, 특히 이후 업그레이드인 헤고타에서는 FOCIL이 합의 레이어의 헤드라이너로 선택되면서 검열 저항성이 다음 업그레이드의 핵심 의제로 부상했다. 반면 EIP-8141 프레임 트랜잭션(Frame Transactions)은 계정 추상화(Account Abstraction), 서명 자유도(signature agility), 양자 저항성(post-quantum readiness)의 이슈를 함께 다루는 제안으로 주목받았지만, 개발자들 간에 구현 방향과 범위에 대한 합의가 좁혀지지 않아 여전히 CFI 단계에 머물러 있다.

애플리케이션 단과 관련해서는 AI 에이전트의 검증 가능성과 이더리움 재단의 생태계 지원 이니셔티브들이 주요 의제로 떠올랐다. Ethereum Magicians에서는 ERC-8126, ERC-8210, ERC-8203, ERC-8239 등 에이전트의 신원, 검증, 담보, 스킬, 정산 과정을 표준화하려는 제안들이 이어졌고, 솔리디티 설문은 AI 도구 사용이 보편화되는 한편 출력물에 대한 신뢰는 여전히 낮다는 점을 보여주었다. 그리고 이더리움 생태계 애플리케이션들의 안정적인 운영을 지원하기 위한 EAG(Ethereum Applications Guild)의 출범, 이더리움 재단 생태계 지원 프로그램(ESP)의 암호학/영지식증명/보안 프로토콜 연구 지원, 500 ETH 규모의 보안 펀딩 라운드 등의 이니셔티브는 이더리움 재단의 방향이 생태계 실사용 앱을 안전하게 검증하고 지원할 수 있는 기반을 마련하는 쪽으로 이동하고 있음을 보여준다.

2. 새로이 제안된 EIP들

4월 한달 간 새로이 ‘Draft’로 채택된 EIP의 수는 총 11개로, 전월대비 1개가 감소하였다. 당월의 새로운 드래프트 상태의 EIP는 전월과 마찬가지로 네트워크 단의 개선을 요하는 코어(Core) EIP가 주를 이루었다.

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

2.1 코어 / 네트워킹 레이어

2.1.1 EIP-8164: Native Key Delegation for EOAs

이더리움의 외부 소유 계정(EOA)은 출범 이래 줄곧 secp256k1 ECDSA 단일 서명 스킴에 인증을 의존해왔다. 트랜잭션의 서명자가 곧 계정의 소유자라는 단순한 모델은 그동안 프로토콜의 근간을 이뤄왔지만, 이는 동시에 EOA 인증이 단 하나의 곡선과 단 하나의 알고리즘에 영구히 결박되어 있다는 한계점을 드러내기도 했다. 예를 들어, 트랜잭션을 한 번이라도 서명한 EOA는 secp256k1 공개키가 온체인에 노출된 상태이기 때문에, 충분히 강력한 양자 컴퓨터가 등장할 경우 Shor's algorithm 등을 통해 비밀키가 복원될 수 있다. 즉 ECDSA 종속은 알고리즘 다양성의 결여를 넘어, 이미 활동한 모든 EOA를 양자 위협에 노출시키고 있다는 점에서 점진적인 리스크로 누적되어 왔다.

이러한 문제의식에 가장 가까이 다가간 시도가 EIP-7702다. EIP-7702는 EOA가 자신의 코드 필드에 컨트랙트 코드를 위임함으로써, 트랜잭션마다 임의의 검증 로직을 실행할 수 있게 했다. 이를 통해 ERC-4337 계정과 유사한 기능을 EOA가 갖출 수 있게 됐지만, 핵심적으로 위임 자체를 승인하는 권한은 여전히 ECDSA 서명에 의해 결정된다는 한계점을 가졌다. 따라서 양자 위협에 대한 노출은 그대로 남았으며, 더욱이 EVM 실행을 거쳐 대체 서명 스킴을 검증하는 방식은 트랜잭션마다 부가적인 가스 비용을 발생시키는 문제점도 가지고 있다.

EIP-8164는 이러한 한계를 인식하고, EOA의 인증 알고리즘 자체를 영구히 교체할 수 있는 프로토콜 수준의 경로를 도입한다. 핵심 아이디어는 EIP-7702가 정의한 delegation designator 체계를 확장하여, 코드 위임이 아닌 키 위임(native key delegation)을 가능하게 만드는 것이다. 즉, EOA는 한 번의 마이그레이션을 통해 자신의 인증 키를 ECDSA에서 양자 내성 서명 스킴으로 영구히 전환할 수 있으며, 이 전환이 일어나는 순간 원래의 ECDSA 키는 프로토콜 수준에서 영원히 무효화된다. 첫 번째로 적용하는 네이티브 키 스킴으로 채택된 것은 NIST FIPS 204 표준인 ML-DSA-44다. ML-DSA-44는 모듈 격자 문제(Module-LWE / Module-SIS)에 기반한 NIST Level 1 (~128-bit post-quantum) 서명 스킴으로, 양자 내성을 가진다.

구체적으로 EIP-8164는 새로운 delegation designator 0xef0101 || pubkey를 정의한다*. 코드 필드 1,315바이트 중 앞 3바이트는 ML-DSA-44 native-key 계정을 식별하는 prefix이며, 뒤따르는 1,312바이트가 ML-DSA-44 공개키 그 자체다. 이는 인증에 쓰일 키가 코드 필드에 직접 박혀 있다는 점에서, EIP-7702의 "코드 주소를 가리키는 포인터" 구조와 근본적으로 다르다.

*본 제안은 후속적으로 다양한 스킴을 포용할 수 있게 하기위해 0xef01XX prefix를 예약한다.

함께 도입되는 새 트랜잭션 타입 0x06은 두 가지 모드를 단일 타입으로 지원한다.

첫 번째로 ECDSA 모드는 마이그레이션 시 한 번 사용되며, sender 필드를 비운 채 기존 ECDSA 서명으로 네이티브 키(native-key) 위임을 권한 부여한다.

두 번째로, ML-DSA-44 모드는 마이그레이션 이후 네이티브 서명 트랜잭션을 위한 것으로, sender 필드에 20바이트 주소를 명시하고 2,420바이트 ML-DSA-44 서명을 함께 실어 보낸다. ML-DSA-44는 ECDSA와 달리 서명에서 공개키 복원이 불가능하므로 sender를 명시적으로 적시해야 하지만, 그 대가로 트랜잭션 디코딩 단계에서 타원곡선 연산이 사라진다는 부수적 이점이 따른다.

이와 관련하여 키 라이프사이클 역시 native_key_authorization_list 안의 두 종류 튜플로 운용된다:

마이그레이션 튜플은 ECDSA로 서명되어 한 번 사용되고 끝나는 반면, 로테이션 튜플은 현재 설치된 ML-DSA-44 키로 서명되어 새 ML-DSA-44 공개키를 설치한다. 한 번 네이티브 키로 전환된 계정에서는 ECDSA 기반 트랜잭션(타입 0x00–0x04 및 0x06 ECDSA 모드)과 EIP-7702 위임이 모두 거부되며, 검증 클라이언트 간 합의 분기 위험을 차단하기 위해 모든 인코딩의 정규화/서명 계수 norm 검사/hint vector 정렬까지 검증 절차에 엄격히 명시되어 있다. 가스 측면에서는 ML-DSA-44 검증에 50,000 가스의 기본 비용(intrinsic cost)이 부과되어 기존 ecrecover 비용을 대체한다.

결과적으로 EIP-8164는 이더리움이 양자 위협 시대를 준비하기 위해 인증 레이어에 깔아두는 첫 번째 정식 마이그레이션 경로로 평가될 수 있다. 지갑 빌더와 커스터디 인프라 입장에서는 "ECDSA에서 양자 내성 스킴으로의 영구 마이그레이션"이라는 새 프리미티브가 처음 정식화된 셈이며, 특히 기관 보유 자산의 경우 단일 곡선 및 고전적인 보안 형식에 결박된 키 인프라가 점진적 리스크로 평가되고 있는 상황에서 프로토콜 레벨에서 "원본 ECDSA 키가 더 이상 유효하지 않음"을 증명할 수 있는 메커니즘을 도입할 수 있기에 컴플라이언스 및 감사 측면에서도 의미가 있다. 또한 0xef01XX designator 공간이 후속적으로 다양한 서명 스킴을 위해 예약되어 있다는 점은, EIP-8164가 단일 알고리즘 도입이 아니라 포스트 양자(PQ) 서명 스킴들이 슬롯 단위로 추가되는, 확장 가능한 인증 프레임워크로써 기능할 수 있음을 의미한다.

2.1.2 EIP-8188: State Tiering by Write Age

이더리움의 상태(state)는 한 번 기록되면 명시적으로 제거되지 않는 한 계속 남아 있으며, 오래전에 쓰인 상태와 최근에 반복적으로 갱신되는 상태가 동일한 쓰기 비용 구조 안에서 처리된다. EIP-8188은 이 점을 “renewal age is unpriced”라는 문제로 규정한다.

최근에 갱신되는 상태는 클라이언트의 가변 작업 세트(mutable working set)에 남아 있을 가능성이 높다. 하지만, 오랫동안 갱신되지 않은 상태는 더 깊은 레벨의 데이터베이스 조회와 더 큰 쓰기 오버헤드를 유발할 수 있다. 그럼에도 현재의 일정한(flat) 쓰기 비용 구조에서는 현재 활발히 활용되는 활성화된 상태 그룹(active set)에는 과금이 과하고, 오래 방치된 상태를 다시 쓰는 행위에는 과금이 부족한 구조를 만든다. EIP-8188의 출발점은 상태의 크기 자체보다, 반복적으로 다시 쓰이는 상태와 장기간 쓰이지 않은 상태의 리소스 프로파일이 다르다는 점에서 출발한다.

기존의 가스 모델은 트랜잭션 내부에서 처음 접근한 주소나 슬롯에 더 높은 비용을 부과하는 warm/cold 구분을 이미 갖고 있다(EIP-2929). 하지만 이는 “이번 트랜잭션 안에서 처음 접근했는가?” 수준에서만 본다(transaction-local first-touch). 반대로 EIP-8188이 보려는 것은 “이 상태가 마지막으로 쓰인 지 얼마나 오래됐는가?”이다. 즉 EIP-2929는 접근의 순서를 보고, EIP-8188은 쓰기의 나이를 본다. Access list 역시 EIP-2930을 통해 주소와 스토리지 키(storage key)를 미리 warm 처리할 수 있지만, 이는 읽기 접근의 처음 접근(first-touch)의 비용을 줄일 뿐 해당 상태가 오래전에 마지막으로 쓰였는지 여부를 지우지 않는다. 따라서 access list로 pre-warm된 스토리지 슬롯이라도 나중에 SSTORE로 쓰이면, 여전히 last_written_period에 기반한 티어 기반의 쓰기 비용(tiered write cost)를 지불해야 한다.

구체적으로 EIP-8188은 계정과 스토리지 슬롯의 RLP 인코딩에 last_written_period 필드를 추가한다. 계정은 기존 account = RLP([nonce, balance, storageRoot, codeHash])에서 account = RLP([..., last_written_period])의 구조로 확장되고, 스토리지 슬롯은 slot_value = RLP(value)에서 slot_value = RLP([value, last_written_period])로 바뀐다.

전역 current_period는 current_period = max(0, (block_number - PERIOD_START_BLOCK) // PERIOD_LENGTH)로 계산되며, 상태의 티어는 period_age = current_period - last_written_period가 INACTIVE_MIN_AGE보다 작은지에 따라 ACTIVE 또는 INACTIVE로 결정된다.

쓰기 비용은 ACTIVE_ACCOUNT_WRITE, INACTIVE_ACCOUNT_WRITE, ACTIVE_STORAGE_WRITE, INACTIVE_STORAGE_WRITE등의 하위 요소로 나뉘며, 본문은 INACTIVE > ACTIVE 조건을 명시한다. 여기서 중요한 점은 티어가 쓰기 전에 먼저 평가된다는 것이다. Inactive 상태에 쓰는 트랜잭션은 그 쓰기 자체가 해당 상태를 Active로 갱신하더라도, 먼저 Inactive write cost를 지불한다.

본 EIP의 임플리케이션은 클라이언트가 쓰기 나이 메타데이터(write-age metadata)를 활용해 상태 저장 경로를 나눌 수 있다는 데 있다. 즉, EIP-8188은 특정 스토리지 아키텍처를 강제하지 않지만, 클라이언트가 Active 상태는 반복 쓰기에 최적화된 작은 가변 스토리지(mutable store)에 두고, Inactive 상태는 처리량에 최적화된 정적 스토리지(stable store)에 둘 수 있는 아이디어를 제공한다. 다만 이 제안은 상태 만료(state expiry)처럼 Inactive 상태를 합의 단에서 제거하지 않으며, 전체 상태 크기를 직접 제한(bound)하지도 않는다. 이러한 점에서 EIP-8188은 상태를 삭제하는 강한 개입이라기보다는, 오래된 상태를 다시 쓰는 비용 신호를 프로토콜에 넣어 가변 작업 세트와 전체 상태를 분리하려는 중간 단계의 상태 관리 메커니즘으로 생각해볼 수 있다.

2.1.3 EIP-8205: Withdrawal credentials preregistration

이더리움의 검증자 생성 과정에서 첫 입금은 특정 공개키에 대한 출금 크레덴셜(withdrawal credentials)을 사실상 확정한다. 이러한 구조는 자금을 제공하는 주체와 BLS 키 생성자가 동일한 솔로 스테이킹(solo staking) 상황에서는 문제가 작게 드러나지만, 스테이킹을 위임하는 서비스 등에서는 신뢰의 경계가 뚜렷하게 생긴다.

예를 들어, 유동화 스테이킹 프로토콜(Liquid Staking), 혹은 스테이킹 서비스 프로바이더(staking-as-a-service provider) 등과 같이 운영자와 자본이 분리되는 모델에서는 키 보유자가 자금을 제공한 자보다 먼저 출금 크레덴셜로 입금할 수 있고, 이 경우 자금을 제공한 주체가 출금 권한을 온체인에서 보장받을 방법은 없다. EIP-8205는 바로 이 “첫 입금 전 구간”을 프로토콜 레벨에서 직접 다루려는 제안이다.

지금까지 이 문제는 프로토콜이 아니라 애플리케이션 레벨에서 처리됐다. EIP-8205 본문에서는 최소 3분의 1 이상의 스테이킹된 ETH가 이처럼 위임된 아키텍처(delegated architecture)를 통해 흐르고 있으며, 각 애플리케이션들이 보증금 기반 사전 입금 방식(bond-based pre-deposit), 보호 위원회(guardian committee) 등의 형태로 자체적으로 구축해왔다고 설명한다. 지금껏 이러한 방어체계는 악용 사례(exploit)을 막는 데는 성공했지만, 설계와 감사, 그리고 운영이 모두 개별 애플리케이션의 부담으로 남았다.

EIP-8205의 핵심은 검증자 키 보유자가 입금 전에 pubkey와 withdrawal_credentials의 결합을 BLS 서명으로 사전등록하고, 합의 레이어가 이후 deposit ingestion 단계에서 이를 강제하도록 만드는 것이다: 실행 레이어(Execution Layer, EL)에서는 새 시스템 컨트랙트가 source_address, pubkey, withdrawal_credentials, signature 네 필드로 구성된 VALIDATOR_PREREGISTRATION_REQUEST_TYPE에 해당하는 EIP-7685 request를 큐에 넣는다. 합의 레이어(Consensus Layer, CL)에서는 StoredPreregistration이 pubkey, withdrawal_credentials, inclusion_slot을 저장하고, ExecutionRequests에는 preregistrations 리스트가 추가된다. 사전등록이 없는 pubkey의 deposit은 기존과 동일하게 처리되므로, 이 메커니즘은 기존 스테이킹 플로우 전체를 바꾸기보다는 위임 스테이킹 구조(delegated staking)에 필요한 선택적 안전장치를 추가하는 셈이다.

실무적인 변화는 라이도(Lido) 각 모듈의 예치 보안(deposit security) 구조의 예시를 보면 더 분명해진다. 위의 표 처럼, 라이도는 2021년부터 Deposit Security Module(DSM)을 통해 가디언 위원회(guardian committee)가 depositRoot 스냅샷에 서명한 뒤 예치 배치(deposit batch)를 허용하는 방식을 사용해왔고, 현재 구조에서는 4-of-6 쿼럼(quorum), 1-of-N 중단 역치(pause threshold), 블록당 예치율 제한(per-block deposit rate limit) 같은 운영 장치가 출금 크레덴셜 프론트러닝을 막는 데 쓰이고 있다. 하지만 Staking Router와 Community Staking Module(CSM)처럼 오퍼레이터 규모(operator set)가 커질수록 가디언 기반의 감시는 더 복잡해지고, stVaults처럼 볼트(vault)마다 별도의 출금 크레덴셜을 갖는 구조에서는 고정된 위원회가 모든 예치큐(deposit queue)를 감시하기 어렵다. 이 때문에 라이도는 stVaults에 대해 벨리데이터(validator)당 1 ETH의 담보를 먼저 걸고 EIP-4788 머클 증명으로 출금 크레덴셜을 확인하는 Predeposit Guarantee를 별도로 만들었으며, 결과적으로 DSM과 PDG라는 두 개의 예치 보호 시스템을 병행하게 됐다. EIP-8205가 도입되면 이러한 구조의 상당 부분은 프로토콜 보증으로 대체되거나 단순화될 수 있다.

이러한 점에서 EIP-8205는 단순히 벨리데이터의 예치 UX를 개선하는 제안을 넘어, LST와 많은 스테이킹 서비스 프로바이더(Staking-as-a-service provider)가 각자 유지해온 예치 보안 인프라를 이더리움의 공통 보안 속성으로 흡수하도록하고 스테이킹의 저변을 넓히려는 시도로 평가될 수 있다.

2.1.4 기타

• EIP-8133: Upgrade Nomenclature
• EIP-8173: Foundations of EVM Control Flow
• EIP-8200: EVMification
• EIP-8237: Independent CL/EL Sync

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

2.2.1 EIP-8202: Scheme-Agile Transactions

이더리움은 EIP-2718을 통해 새로운 기능이 추가될 때마다 새로운 트랜잭션 타입을 발행하는 방식으로 진화해 왔다: EIP-1559는 기본 수수료(base fee)와 우선 수수료(priority fee)를 분리하기 위해 0x02를, EIP-4844는 블롭 데이터를 첨부하기 위해 0x03을, EIP-7702는 EOA의 트랜잭션 단위 코드 위임을 위해 0x04를 신설하는 등 각각 별도의 EIP-2718 트랜잭션 타입을 신설했다. 하지만 이들 타입의 각 페이로드는 한 트랜잭션 내에서 서로 조합되어 사용되진 않는다. 즉, 블롭을 보내면서 동시에 set-code 위임도 하고 싶다면 그 조합을 위한 또 다른 top-level의 새로운 타입을 새로 만들어야 한다. 이러한 구조는 새로운 기능이 추가될수록 가능한 조합이 비약적으로 늘어나게되고 그때마다 이와같은 envelope를 새로 발행하는 방식은 지속가능하지 않다.

EIP-8202는 이 문제를 새로운 트랜잭션 타입을 계속 늘리는 방식으로 해결하지 않고, 하나의 공통 트랜잭션envelope 안에 인증 방식과 확장 기능을 붙이는 방향으로 정리한다. 즉 수수료와 실행 페이로드는 공통으로 두고, 나머지 기능은 필요할 때 선택적으로 결합하는 구조다.

구체적으로 EIP-8202는 트랜잭션 타입이 0x05인 SchemedTransaction을 도입한다. 해당 타입의 형태는 0x05 || rlp([..., authorizations, extensions])로 표현될 수 있는데, 여기서 앞부분은 공통 EIP-1559 수수료 헤더(fee header)와 일반 call/create 실행 페이로드를 담고, 뒤의 두 리스트 중 authorizations는 sender가 어떤 방식으로 인증되는지를, extensions는 블롭이나 set-code 같은 추가 기능을 담는다. 여기서 중요한 점은 서명 스킴을 트랜잭션 타입이 암묵적으로 결정하게 두지 않고, 트랜잭션 내부의 authorization 필드가 명시적으로 결정하게 한다는 것이다. 핵당 구조에 따르면 기존 secp256k1 ECDSA는 그대로 지원하면서도, ephemeral secp256k1처럼 장기 공개키 노출을 줄이는 방식이나 향후 패스키, 양자 저항 서명 스킴을 같은 envelope 안에 추가할 수 있도록 설계되어 있다.

실용적인 관점에서 이 EIP는 지갑, 클라이언트, 애플리케이션 개발자가 다뤄야 할 트랜잭션 조합의 폭을 줄여줄 수 있다. 예를 들어 지갑은 “블롭을 쓰는 트랜잭션”, “EIP-7702 기반의 set-code를 쓰는 트랜잭션”, “새 서명 스킴을 쓰는 트랜잭션”을 각각 별도의 최상위 포맷으로 구현하기보다, 공통 envelope 위에 해당 기능들을 선형적으로붙이는 방식으로 처리할 수 있다. 클라이언트와 블록 빌더 입장에서도 여러 트랜잭션 타입을 복합적으로 해석하기보다는 단일 트랜잭션 내에서 authorization과 extension 리스트를 검증하기만 하면 된다. 이는 특히 롤업, 스마트 지갑, 혹은 많은 데이터를 처리해야하는(data-heavy) 애플리케이션처럼 여러 프로토콜 특징을 동시에 요구하는 환경에서 구현의 복잡도를 낮춰줄 수 있다.

2.3 애플리케이션

2.3.1 ERC-8196: AI Agent Authenticated Wallet

AI 에이전트가 사용자를 대신해 온체인에서 자율적으로 거래를 수행하는 에이전트 커머스에 대한 논의와 개발은 끊임없이 이뤄지고 있다. 코인베이스(Coinbase)와 클라우드플레어(Cloudflare)가 추진하는 x402 결제 프로토콜, 에이전트 간 작업 발주 및 결제를 표준화한 ERC-8183, 에이전트 아이덴티티 표준인 ERC-8004 등이 빠르게 자리를 잡으면서, 에이전트는 이제 단순히 정보를 검색하는 것을 넘어 실제 자금을 움직이는 경제 주체로 편입되고 있다.

하지만 에이전트가 온체인 상에서 실질적으로 자금을 움직이려면 어떤 형태로든 키 또는 서명 권한을 위임받아야 하는데, 현재의 위임 모델은 두 극단 중 하나에 머물러 있다. 에이전트가 직접 프라이빗 키를 보유하면 호스팅 환경(host)이 언제든 키를 탈취할 수 있고, 사용자가 매 거래마다 직접 서명하면 자율성이 사라진다. 즉, 자율성과 통제권을 동시에 보장하는 위임 구조 없이 결제 인프라만 먼저 표준화되고 있는 셈이다.

이러한 한계를 인식하고 에이전트용 스택을 만들려는 시도가 2025년 후반부터 본격화되었다. ERC-8004는 ERC-721을 상속한 아이덴티티 레지스트리(Identity Registry)로 에이전트에 온체인 아이덴티티를 부여하고, ERC-8126은 그 아이덴티티에 대해 컨트랙트, 미디어, 웹 엔드포인트, 그리고 지갑 이력 등 다섯 가지 검증을 수행해 0~100 범위의 통합 위험 점수를 산출한다.

다만 두 표준은 "이 에이전트가 누구이며 얼마나 신뢰할 수 있는가"라는 질문에 대한 대답만을 제공할 수 있을 뿐, 실질적으로 "이 에이전트가 지금 이 거래를 수행할 권한이 있는가"라는 실행 시점의 질문에는 명쾌한 해답이 되지 않는다. ERC-4337 기반의 스마트 컨트랙트 계정이나 EIP-7702의 EOA 코드 위임도 위임을 담을 컨테이너만 제공할 뿐, 위임의 내용을 강제하는 정책 모델은 별도로 정의되지 않았다. ERC-8196은 이러한 문제의식에서 출발하여, 에이전틱 커머스 스택 중 실행 레이어를 담당하는 것을 명시적으로 목표한다.

ERC-8196의 핵심 아이디어는 위임의 단위를 키가 아니라 정책 해시로 바꾸는 것이다. 자산 소유자는 에이전트에게 키를 넘기는 대신, 어떤 액션을(allowedActions), 어떤 컨트랙트로(allowedContracts·blockedContracts), 얼마까지(maxValuePerTx·maxValuePerDay), 언제까지(validAfter·validUntil), 어떤 검증 조건 하에(minVerificationScore, EIP-8126) 수행할 수 있는지를 명시한 정책을 온체인에 등록한다. 이 정책은 ERC-712 기반의 데이터로 해시되며, 에이전트가 수행하는 모든 액션은 그 policyHash에 바인딩되어 서명된다. 동시에 매 액션은 호스트 조작에 대비한 엔트로피 커밋-리빌(entropyCommitment)과 변조 감지를 위한 해시체인 감사 엔트리(previousHash)를 포함한다. 결과적으로 에이전트는 키 없이도 자율 실행이 가능하고, 사용자는 위임 이후에도 모든 행동을 사후 검증할 수 있다.

결과적으로, ERC-8196은 에이전트 빌더, 지갑 인프라, 결제 프로토콜, 컴플라이언스 도구 등 다양한 영역에 영향을 미칠 것으로 보인다. 빌더에게는 에이전트가 키를 들고 있지 않아도 자율 실행이 가능한 표준 인터페이스가, 지갑 인프라에는 ERC-4337 모듈로 정책을 강제하도록 하는 기능을 얹는 형태로 도입되는 경로가 열릴 수 있다. x402와 ERC-8183 같은 결제 프로토콜은 그동안 가정해온 "에이전트 키의 합법성"을 외부 표준에 위임할 수 있게 되고, 컴플라이언스 도구는 에이전트의 모든 액션이 해시체인으로 묶인 감사 가능한 단위로 표준화되는 변화를 맞이할 수 있게 되는 것이다.

요컨대, ERC-8196는 ERC-8004로부터 기록되는 정체성과 ERC-8126로부터 매겨지는 신뢰도 점수가 실제 자금 흐름에서 어떻게 강제되는지를 정의함으로써, 에이전트 경제가 정보 교환에서 자금 운용 단계로 진입하는 데 필요한 스택을 완성해나가는 중요 요소 중 하나로 생각된다.

2.3.2 기타

• ERC-8199: Sandboxed Smart Wallet

3. 기존 EIP들의 진전

한편, 4월 한달간은 11개의 새로이 ‘Draft’로 채택된 EIP들을 제외하고, 14개의 기존 EIP의 상태가 변화하였다. 이 중 10개의 EIP들은 최종적으로 채택되기위한 다음 단계(i.e., ‘Final’, ‘Last Call’, ‘Review’, ‘Draft’ 등의 단계)로 격상되었는데, 게중에서도 3개가 Final 단계로 격상되었다. 나머지 총 4개의 EIP의 경우, 다음 단계로 가지못하고 ‘Stagnant’ 단계로 바뀐 EIP가 4개(i.e., EIP-7919, EIP-8012, EIP-8015, EIP-8025)가 있다.

또한 특이하게도, 이번 달에 진전이 있었던 10개의 EIP 중 이더리움의 블롭 용량 파라미터를 단계적으로 올리는 변경 사항을 공식 기록으로 남기는 Meta EIP인 EIP-8134 및 EIP-8135를 제외하고는, 모두 애플리케이션 수준에서 구현되는 ERC들이 자리하였다.

ERC들 중 특히 주목할만한 것들은 멀티체인 환경에서 address@chain#checksum 과 같이 사람이 읽기 쉬운 체인별 주소/ENS 을 표현하는 표준인 ERC-7828, 잔액과 전송 금액을 숨길 수 있는 기밀 트랜잭션을 지원하는 ERC-20 인터페이스인 ERC-7945, ERC-20 토큰의 잔액을 “멤버십 수준”으로 해석하여 온체인에서 그룹 구성원과 권한을 표현할 수 있도록 하는 표준인 ERC-8063, ERC-8004에 등록된 AI 에이전트의 신뢰도를 검증하기 위한 검증 및 리스크 스코어링 표준인 ERC-8126, 그리고 함수 selector 기반으로 로직 모듈을 동적으로 라우팅하는 모듈러 프록시 구조를 표준화하려는 제안인 ERC-8167* 등이 있다.

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

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

3.1 코어 / 네트워킹 레이어

• EIP-8134: Hardfork Meta - BPO1
• EIP-8135: Hardfork Meta - BPO2

4. “생각해보기” - 기관향 스테이킹 자산의 활용 시장, 준비된 프로토콜이 선점한다

코어 단에서의 논의와 실질적인 EIP 제안이 활발히 진행되고 있는 가운데, 지난 4월에는 이더리움의 스테이킹 비율이 역사상 최고치를 달성했다. 이러한 흐름의 배경에는 디지털 인프라 자산으로서 ETH에 대한 기관들의 투자 관심, 그리고 스테이킹된 ETH 자산을 온체인 상에서 능동적으로 활용함으로써 부가적인 가치 창출의 기회를 포착하려는 시도가 자리하고 있다.

Source: Korean Blockchain Guidebook for Institutions 2026 | Four Pillars & Pantera Capital

특히 기관향 스테이킹 자산 시장에서 플레이어들의 역할은 단순 스테이킹 서비스 제공자에서 종합 금융 인프라 제공자로 빠르게 체계화되고 있다. 이에 따라 스테이킹된 자산은 더 이상 "스테이킹 서비스"라는 단일 카테고리로 정의되지 않으며, 여러 기능 레이어가 결합된 “구조화된 상품 스택(structured product stack)”으로 진화 중이다. 글로벌 플레이어들 또한 각 국가의 규제 환경에 맞춰 이 스택의 각 레이어에 활발히 진입하고 있고, 이는 신규 진입을 검토하는 기관 입장에서 각 스택에서 가장 자신들에게 맞는 파트너들을 어떻게 엮어, 자신만의 수익화 솔루션을 구축할 것인가를 위한 선택지가 매우 다양해졌음을 의미한다.

그렇다면 이 다양한 선택지 위에서 신규 기관 진입자에게 가장 중요한 판단 기준은 무엇인가. 첫 번째는 설명가능성(accountability)이다. 여기에는 회계 처리 및 세무 보고, 리스크 관리, 유동성 계획, 규제 준수 등의 컴포넌트가 포함되며, 위에서 언급한 대로 각 영역마다 전문화된 플레이어들이 존재한다. 두 번째는 그 위에서 자산의 통제권과 온체인 활용도 사이의 스펙트럼을 어디에 위치시킬 것인가의 결정이다. 즉, 위 다섯 컴포넌트를 바탕으로 기관은 해당 프로토콜이 자산에 대한 통제권을 얼마나 보장하면서 동시에 그 자산을 온체인에서 활용할 여지를 얼마나 열어두는지를 진단해야 한다.

Source: Korean Blockchain Guidebook for Institutions 2026 | Four Pillars & Pantera Capital

예를 들어, 규제 라이선스를 보유한 스테이킹 사업자에게 ETH의 수탁(custody)과 스테이킹을 함께 위임하는 형태는 운영상 가장 직관적이지만 온체인 활용이 제한된다는 반대급부가 있다. 반면 비수탁형(non-custodial) 스테이킹, 화이트라벨링, 또는 LST를 활용하는 방식은 자산에 대한 통제권을 유지하면서도 온체인에서의 활용 여지를 크게 확장한다. 다만 온체인 활용 의지가 높을수록 활용 대상이 되는 프로토콜의 운영 리스크에 대한 노출도 함께 고려해야하기 때문에, 해당 프로토콜이 기저 네트워크에 얼마나 기술적으로 매끄럽게 정렬(align)되어 있고, 실제 사용자를 위해 얼마나 견고한(robust) 장치들을 구축해놓았는가가 결정적인 변수가 된다.

하지만 대다수의 온체인 솔루션은 서비스가 제공되고 운영되는 방식이 기존 웹2 서비스와는 본질적으로 다르기 때문에, 웹3의 운영 방식을 고도화하는 한편 웹2의 설명가능성까지 함께 갖추는 것이 쉽지 않다. 그럼에도 불구하고, 기관 자본의 본격적 유입이 가시화되는 지금의 시점에서는 둘 중 어느 하나도 포기할 수 없다.

예를 들어, 라이도와 같은 프로토콜은 이러한 두 축 모두에서 모범적인 사례를 보여준다. 우선 설명가능성 측면에서, 라이도는 최근 칸티나(Cantina)로부터 Web3SOC 인증을 획득함으로써 기존 stETH의 스테이킹 리워즈(Staking Rewards) 리스크 평가 및 크레도라(Credora) 디파이 평가와 결합해 자산 & 프로토콜 & 조직이라는 세 차원 모두에서 외부 평가 자료를 갖춘 디파이 프로토콜이 되었다. 정렬(alignment) 측면에서도, 라이도는 가장 큰 LST 제공자임에도 이더리움의 기술적인 방향성에 빠르게 정렬하여 검증인 통합(validator consolidation), EIP-7251에 맞춘 마이그레이션 및 EIP-8205 제안 등 핵심 이니셔티브를 적극 추진하며 기술적인 견고함을 달성하는 동시에 이더리움의 신뢰할 수 있는 레이어로서의 그 역할을 확장하는 협력자로 포지셔닝하고 있다.

기관 채택과 다양한 수익화 파이프라인 기회 포착은 이미 빠르게 가속화되고 있으며, 그 무게중심은 온체인 활용도가 높은 솔루션 쪽으로 점차 이동할 것이다. 하지만 모두가 이 흐름을 감당할 수 있는 것은 아니다. 시장에는 수많은 프로토콜이 존재하지만, 웹3 네이티브한 운영 방식을 견고하게 확장하면서도 웹2의 문법을 빠르게 적용하여 기관 자본을 감당할 만큼 성숙도를 먼저 갖춘 프로젝트들이 다음 단계의 온체인 인프라를 선점할 것이다.