3월의 제안은 1,2월과 마찬가지로 프로토콜의 성숙에 따라 새롭게 대두되는 여러 복합적인 문제들을 반영하고 있으며, 이에 따라 코어(Core) EIP 제안이 확대되고 논의 또한 한층 세분화된 형태로 전개되고 있다.
올 하반기 헤고타(Hegota) 업그레이드 이후, FOCIL 도입으로 기존 빌더·릴레이 중심 구조의 한계가 드러날 것으로 보이며, 이에 따라 enshrined PBS, 암호화된 멤풀, 수수료 마켓 등과 관련된 후속 제안들에 대한 논의가 더욱 활발해질 것으로 보인다.
한편, 이더리움은 3월에 두 개의 블로그 글을 통해 자신의 정체성과 역할을 톺아보았다. CROPS 원칙에 기반한 ‘복제 불가능한 페르소나’를 중심으로 장기간 축적된 신뢰와 생태계 성숙도를 바탕으로, 이더리움은 더욱 견고한 공공 인프라로 진화해나갈 것이다.
이더리움은 스마트 컨트랙트라는 개념을 기존의 분산 원장 구조에 접목하며 블록체인의 새로운 지평을 열었다. 이러한 설계 철학은 EIP(Ethereum Improvement Proposal)라는 형태를 통해 점진적으로 구체화되었고, 그 결과 블록체인은 단순한 가치 저장 수단을 넘어 실제 비즈니스와 다양한 유스케이스를 담아낼 수 있는 인프라로 진화하고 있다. 이러한 발전의 흐름 속에서, 각기 다른 시각과 문제의식을 지닌 오피니언 리더들이 EIP 논의에 더욱 폭넓게 참여한다면, 우리가 그려보는 디지털 네이티브한 미래 역시 한층 더 풍부해질 수 있을 것이다.
본 아티클은 매월 새롭게 ‘Draft’ 단계로 채택되는 제안들과, 그 과정에서 상태(status)가 변화하는 주요 제안들을 하이레벨에서 조망하며 EIP 트렌드를 정리한다. 이를 통해 빌더와 비즈니스 관계자들이 EIP의 흐름과 맥락을 보다 입체적으로 이해하고, 나아가 각자의 영역에서 새로운 가치를 제안하는 데 참고할 수 있는 출발점이 되기를 기대한다.
본 아티클과 관련된 EIP 데이터는 EIP, ERC, RIP 공식 깃허브 레포지토리를 각각 활용해 수집·분석되었다.
3월의 EIP 흐름에서 가장 두드러지는 특징은, 1월과 2월에 이어 코어(Core) 단에서 유의미한 수의 신규 EIP가 다양하게, 또 지속적으로 제안되고 있다는 점이다. 이는 프로토콜이 점차 성숙함에 따라 동시에 해결해야 할 문제들의 수가 증가하고 있으며, 이를 대응하기 위한 EIP 파이프라인이 보다 병렬화(pipelined)된 형태로 이뤄지고 있음을 시사한다.
보다 구체적으로는 데이터 가용성 및 가스 최적화, 유연한 트랜잭션 타입 및 처리 방식, 암호화 기반 솔루션과 양자 저항 메커니즘 등 확장성, UX, 그리고 L1 보안 전반에 대한 수요가 복합적으로 증가하면서 프로토콜 레벨에서의 논의가 한층 활발해지고 있다. 이러한 흐름 속에서, 개별 기능을 보다 작은 단위로 나누어 빠르게 프로토콜에 반영하려는 방향성이 뚜렷해지고 있으며, EIP 설계 역시 점차 세분화되는 추세다.
업계 트렌드를 반영한다고도 볼 수 있는, 애플리케이션 단에서 구현되는 ERC 표준들 또한 유의미한 진전을 보였다. 후의 섹션에서 살펴보겠지만, 멤버십을 표현하는 표준, 크로스체인 메시징 표준, 그리고 보다 정교하게 로열티 관계를 정의하고 전파 범위를 제어할 수 있도록 하는 표준 등, 총 6개의 주요 진전이 있었던 EIP 중 무려 5개가 ‘Final’ 단계로 확정되었다는 점은 특히 주목할 만하다.
Source: forkcast
한편, 이더리움 커뮤니티 내에서는 지난 달에 이어 계속해서 차기 업그레이드인 헤고타(Hegota)의 헤드라이너 선정을 두고 한 달간 활발한 논의가 이어졌다. 합의 레이어(CL) 측면에서는 FOCIL(Fork-choice Enforced Inclusion Lists, EIP-7805)*이 SFI(Scheduled for Inclusion)로 선정되었으며, 실행 레이어(EL)에서는 프레임 트랜잭션(Frame Transactions, EIP-8141)**이 CFI(Considered for Inclusion)로 격상되어 지속적인 검토 대상에 올랐다. 이 두 EIP들을 제외하고 헤고타 업그레이드에 포함하기 적합한 다른 EIP 들에 대해서는 아직까지 논의가 진행 중인 상태다.
현재까지의 흐름을 종합하면, 헤고타 이후에는 FOCIL의 도입을 기점으로 특정 트랜잭션 포함(inclusion)이 더 이상 선택의 문제가 아니라 프로토콜이 강제하는 규칙으로 자리잡게 될 가능성이 높다. 이에 따라 기존처럼 빌더 및 릴레이어 중심으로 작동하던 블록 생산 구조는 점차 구조적인 한계를 드러낼 것으로 보이며, 이는 enshrined PBS(EIP-7732), 암호화된 멤풀(EIP-8184), 수수료 마켓 관련 EIP 등 블록 포함(inclusion)과 오더링(ordering)을 프로토콜 레벨에서 정렬하려는 후속 이니셔티브들의 필요성을 자연스럽게 부각시키는 방향으로 이을 것으로 보인다.
*FOCIL은 특정 블록 빌더가 임의로 트랜잭션을 배제하지 못하도록, 검증자 위원회(committee)가 포함해야 할 트랜잭션 목록을 제시하고 이를 블록에 강제 반영하도록 하는 프로토콜 규칙을 제안하는 EIP이다. 결과적으로 이는 이더리움의 핵심 가치인 검열 저항성과 신뢰할 수 있는 중립성(credible neutrality)을 프로토콜 수준에서 강화하는 메커니즘으로 평가된다.
**프레임 트랜잭션은 여전히 찬성 측과 구현 복잡성을 우려하는 반대 측 간의 논의가 진행 중이다. 해당 제안에 대한 보다 상세한 내용은 Four Pillars 리서처 r2jamong의 별도 포스팅을 참고하기 바란다.
3월 한달 간 새로이 ‘Draft’로 채택된 EIP의 수는 총 11개로, 전월대비 11개가 감소하였다. 당월의 새로운 드래프트 상태의 EIP는 네트워크 단의 개선을 요하는 코어(Core) EIP가 주를 이루었다.
아래에서는 새로이 ‘Draft’로 채택된 EIP들을 더욱 세부적으로 분류해보고, 특별히 주요깊게 살펴볼만한 EIP들을 살펴본다.
2.1.1 EIP-8163: Reserve EXTENSION (0xae) opcode
본 EIP에 대한 설명은 Four Pillars의 리서처 C4lvin에 의해 별도의 포스트를 통해 기설명되었다. 아래는 해당 포스팅에 대한 원문에 약간의 수정을 가한 것이다.
모나드(Monad) 측에서 제안된 EIP-8163은 이더리움 L1 EVM에서 ‘0xae’ 라고하는 OPCODE를 영구히 예약하자는 제안이다. 해당 OPCODE가 도입될 경우, L1 외부의 EVM 체인들은 이 OPCODE를 확장 명령어의 접두사로 자유롭게 활용할 수 있게 된다*. 이더리움이 "이 번호는 절대 쓰지 않겠다"고 공식 약속함으로써, 다른 EVM 체인들이 OPCODE 충돌 걱정 없이 독자적인 EVM 확장을 시도할 수 있는 네임스페이스를 보장하는 것이다.
이 제안의 의미는 EVM을 채택한 알트(alt) L1들이 겪는 이더리움 종속성 딜레마의 완화에 있다. 알트 L1들이 각각 독자적인 VM을 만들면 생태계를 처음부터 구축해야 하는 비용이 크고, EVM을 그대로 따르면 이더리움 L1의 프로토콜 변경에 수동적으로 끌려갈 수밖에 없다.
이에 대해서는 최근 EIP-8141(Frame Transaction)에 대한 논쟁이 잘 보여준다. EIP-8141은 트랜잭션의 유효성이 검증 프레임의 EVM 실행 결과에 따라 동적으로 결정되는 구조인데, 이는 템포(Tempo)처럼 자체 트랜잭션 설계를 가진 체인에게는 쓰이지 않을 dead code를 강제로 탑재하는 것과 같고, 합의와 실행을 분리하여 트랜잭션 순서에 대해 먼저 합의한 뒤 실행을 별도 파이프라인에서 처리하는 모나드와 같은 체인에게는 "합의 전 실행 필수"를 강제하여 아키텍처의 근간을 흔드는 문제가 된다. 요컨대, EVM 동등성을 유지하려면 받아들여야 하고, 거부하면 호환성을 포기해야 하는 딜레마가 생기는 셈이다.
모나드 측에서 EIP-8163을 제안했다는 점은 이러한 맥락에서 자연스럽게 읽힌다. L1의 프로토콜 변경에 일방적으로 종속되는 것이 아니라, 합의된 확장 공간 안에서 각 체인이 자기 아키텍처에 맞는 실험을 할 수 있는 구조를 확보하려는 시도인 것이다.
이 제안 자체는 이더리움 L1에 아무런 실질적인 프로토콜 변경을 가하지 않고, 성공적인 확장 기능은 별도 EIP를 통해 L1으로 역이식할 수 있다는 점에서 기술적 리스크가 낮다. 이더리움 프로토콜의 진화 속도는 결국 클라이언트 개발자와 툴링 빌더들이 감당할 수 있는 복잡도의 한계에 달려 있으며, EIP-8163의 접근은 그 한계를 우회하는 현실적 해법이 될 수 있을 것이라고 보여진다.
*이더리움 L1에서는 기존의 INVALID (0xfe)와 동일하게 동작하여 자체적인 프로토콜 변경 이슈가 전혀 없다.
2.1.2 EIP-8184: LUCID encrypted mempool
EIP-8184는 이더리움에서의 MEV 문제를 단순한 시장 구조의 부산물이 아니라, 공개 멤풀(public mempool)의 구조적인 투명성에서 비롯된 설계 한계로 인식하는 데서 출발한다.
현재의 공개 멤풀 구조에서는 트랜잭션이 전파되는 순간 내용이 노출되기 때문에 서처(searcher)와 빌더(builder)에게 비대칭적 정보 우위를 제공한다. 이로 인해 사용자는 의도치 않은 가격 불리, 샌드위치 공격, 검열 등의 리스크에 지속적으로 노출되어 왔다.
EIP-8184는 이러한 문제를 해결하기 위해, 트랜잭션을 암호화된 상태로 유지한 채 블록에 포함시키는 암호화된 멤풀(encrypted mempool)의 개념을 프로토콜 레벨에서 구현하려는 시도이다.
Source: EIP-8184
본 제안의 핵심 메커니즘은 트랜잭션을 평문이 아닌 암호문 형태로 제출하고, 이후 특정 시점에 일괄적으로 복호화하는 구조에 있다. 즉, ciphertext, commitment, 그리고 복호화를 위한 decryption key와 같은 요소들로 구성된 암호화된 트랜잭션이 전파(propagation)되면, 블록 빌더 또한 해당 내용을 해석하지 못한 채 오더링을 수행하게 되고, 이후 일정 조건이 충족되면 decryptor 혹은 key publisher에 의해 복호화가 이루어지며, 이 과정에서 트랜잭션의 실제 실행 내용이 드러난다.
또 하나 EIP-8184의 중요한 특징 중 하나는, EIP-8148이 완전한 프론트러닝 제거 자체에 초점을 맞추기보다는 “제어 가능한 리스크 관리”에 초점을 둔다는 점이다. 이는 프로포절 내에서 나타나는 max_preceding_commitments와 같은 파라미터를 통해 구현된다. 해당 변수는 내가 제출한 트랜잭션 앞에 올 수 있는 “선행 커밋 수”를 제한함으로써, 오더링에 대한 불확실성을 일정 수준 이하로 통제한다. 즉, 사용자는 완전한 오더링 개런티를 포기하는 대신, 예측 가능한 범위 내에서만 경쟁을 허용하는 구조를 선택할 수 있다. 이러한 접근은 네트워크의 유연성과 실용성을 유지하면서도, 과도한 MEV를 억제하려는 것의 절충적인 설계로 보여진다*.
EIP-8184가 도입되어 암호화된 멤풀이 프로토콜 레벨에서 정착될 경우, 블록 빌더의 역할은 정보 우위를 기반으로 한 전략적 최적화에서 벗어나, 보다 중립적인 오더링과 포함(inclusion)을 수행하는 주체로 재정의될 가능성이 크다. 이는 PBS(Proposer-Builder Separation) 구조와의 상호작용 속에서 빌더 시장의 경쟁 방식 자체를 재편할 수 있음을 시사한다.
동시에 복호화 과정에서의 지연이나 실패, 혹은 키 관리와 같은 새로운 리스크가 부상할 수 있으며, 이에 따라 네트워크의 신뢰 모델 역시 재설계가 불가피해질 수 있다. 그럼에도 불구하고 EIP-8184는 “정보 비대칭에 기반한 시장”에서 “암호학적 공정성에 기반한 시장”으로의 전환을 지향한다는 점에서, 이더리움의 장기적인 시장 구조에 구조적인 변화를 야기할 수 있는 중요한 제안으로 보여진다.
*이러한 설계는 EIP-8105와 비교했을 때 더욱 분명해진다. 암호화된 멤풀을 구현하려는 동일한 목적을 가진 EIP-8105는 key publisher 간의 trust graph를 기반으로, 신뢰하지 않는 주체가 내 트랜잭션 앞에 위치하는 것을 구조적으로 차단하려는 접근을 취한다. 즉, 오더링 자체를 신뢰 관계 위에서 결정하며, 프론트러닝의 가능성을 근본적으로 제거하려 한다. 반면 EIP-8184는 이러한 강한 제약 대신, 일정 수준의 경쟁을 허용하되 이를 파라미터화하여 관리하는 방식을 선택한다. 현재 EIP-8105 팀은 EIP-8184 이니셔티브를 완전히 서포트하기로 하였다.
2.1.3 EIP-8189: snap/2 - BAL-Based State Healing
EIP-8189는 이더리움의 상태 동기화(snap sync) 과정에서의 “힐링 단계(healing stage)”를 구조적으로 재설계하려는 제안이다. 기존의 동기화 과정은 누락된 상태를 보완하기 위해 개별 머클 트리(Merkle trie) 노드를 반복적으로 요청하는 방식에 의존하였고, 이는 높은 네트워크 왕복 비용(round trip)과 구현 복잡성을 유발했다.
EIP-8189는 이러한 기존 접근 방식을 폐기하고, 블록 단위 상태 변화 집합인 BAL(Block Access List, EIP-7928)을 활용해 상태를 재구성하는 방식으로 전환하는 것을 제안한다.
구체적으로, 다음과 같은 메시지 변경이 이루어진다:
제거 (Removed):
GetTrieNodes (0x06)
TrieNodes (0x07)
추가 (Added):
GetBlockAccessLists (0x08)
BlockAccessLists (0x09)
즉, 기존에는 어떤 상태가 누락되었는지 모르는 상태에서 탐색적으로 트리 노드를 요청해야 했지만, 이제는 특정 블록 범위의 BAL을 가져와 순차적으로 적용하면 되는 것이다*.
본 제안은 이더리움 네트워크의 확장성과 클라이언트 구현 복잡도에 중요한 의의를 가진다. 기존 트리 기반의 힐링 단계는 네트워크 요청이 많고, 레이턴시와 대역폭(bandwidth)에 민감하며, 클라이언트 구현도 복잡했다. 반면 BAL 기반으로 접근을 하게될 경우, 데이터의 흐름이 더욱 선형화(linearization)가 되고, 동기화(sync) 과정에서 필요한 정보의 범위를 사전에 확정할 수 있게 만든다. 이는 특히 라이트 클라이언트나 빠른 노드 부트스트랩 시나리오에서 매우 중요한 개선일 수 있다.
다만, 제안에서 제적하듯 BAL 데이터 자체의 크기 증가와 이를 안정적으로 전파해야 하는 새로운 네트워크 부담은 추가적인 고려사항으로 남는다. 그럼에도 불구하고, EIP-8189는 이더리움이 점점 더 모듈러 방식으로 진화하고 데이터 효율적인 방향으로 진화하고 있음을 보여주는 사례이며, 향후 state diff 기반의 동기화나 부분 상태 제공 모델로 확장될 수 있는 기반을 마련할 수 있다.
*EIP-7928에서 도입된 block-level access list(BAL)은 각 블록에서 발생한 상태 변경을 집합 형태로 기록하고, 이를 block-access-list-hash로 블록 헤더에 커밋한다. 따라서 syncing 노드는 BAL을 다운로드한 후, 해당 데이터가 블록 헤더와 일치하는지만 검증하면 되는 것이다.
2.1.4 EIP-8198: Quick Slots
EIP-8198의 출발점은 이더리움의 긴 레이턴시가 시장 구조 전반에 부정적인 영향을 미친다고 있다는 인식이다. 현재 이더리움은 임의로 정한 12초라고 하는 슬롯 시간을 기반으로 블록을 생성하지만, 이는 사용자 경험과 시장 효율성 측면에서 구조적인 병목으로 작용해왔다. 슬롯 시간이 길수록 거래 확정이 지연되고, 이는 DEX 가격 괴리, 아비트라지 손실, 그리고 MEV 추출 기회를 확대시키는 요인으로 작용한다. 특히 블록 생성 간격이 길수록 블록 빌더는 더 많은 정보를 기반으로 선택할 수 있는 “옵션(optionality)”을 가지게 되고, 이는 빈 블록 생성 등과 같은 비효율과 시장 왜곡을 심화시킨다.
EIP-8198 제안은 이러한 문제를 해결하기 위한 단계적인 접근을 취한다. 우선, SLOT_DURATION_MS를 컴파일 타임 상수가 아닌 런타임 파라미터로 전환하고, 이를 기반으로 해당 시점에서 최적의 슬롯 시간을 도출해내 향후 점진적으로 레이턴시를 단축할 수 있는 구조를 도입하는 것을 목표로 한다*.
흥미로운 점은, 이 제안이 절대적인 처리량(throughput) 자체를 늘리지 않는다는 데 있다. 대신 슬롯 시간이 짧아지는 만큼, 블록 가스 한도(block gas limit)과 블롭(blob) 관련 파라미터를 비례적으로 조정하여 단위 시간당 처리량을 일정하게 유지한다. 즉, “블록을 작게 만든다”라는 접근보다는, 시간 단축에 맞춰 리소스 단위를 정밀하게 리스케일링하는 구조이며 결과적으로 네트워크 부하는 유지하면서도 레이턴시만 선택적으로 줄이는 정교한 트레이드오프를 구현하는 것이다.
본 제안의 의의는 단순한 UX 개선을 넘어선다. L1 레이턴시의 감소는 곧바로 L2 시퀀싱 속도 개선으로 이어져 롤업 전반의 응답성을 자연스럽게 끌어올릴 수 있다. 동시에 MEV 압축, 가격 정합성 개선, 그리고 프리컨퍼메이션(preconfirmation)과 같은 오프체인 보완 메커니즘에 대한 의존도 감소도 기대할 수 있다.
다만 슬롯 시간 단축은 네트워크 전파(propagation), 클라이언트 성능, 검증자 운영 부담 등 새로운 리스크를 동반할 수 있다. 또한 이러한 구조적 전환 자체는 합의 레이어의 동작 방식을 변경하는 것이기 때문에, 초기 도입은 하드포크를 통해 이루어질 수밖에 없다. 그럼에도 불구하고, 본 제안은 향후 블록 타임 구조를 보다 유연하게 조정할 수 있는 기반을 마련하며, 설령 즉각적인 성능 개선이 제한적일지라도 더 정교한 클라이언트 아키텍처와 CL 성능 분석을 탐색하는데에 큰 의의가 있다.
*이후에는 하드포크 없이도 파라미터 조정을 통해 점진적인 성능 튜닝이 가능해지는 방향이 논의중이다. 예를 들어 epoch 단위로 슬롯 시간을 다르게 설정하는 방식이나, 네트워크 조건에 따라 시간 축을 유연하게 조정하는 방향도 열려 있다.
2.1.5 기타
2.2.1 EIP-8182: Private ETH and ERC-20 Transfers
EIP-8182는 한마디로, 이더리움에 “기본 내장 프라이버시 전송 기능”을 넣자는 제안이다. 현재 프로토콜을 통한 모든 거래는 공개되는 구조이기 때문에, 급여 지급이나 기업 자금 이동 같은 사례에서 트랜잭션 내역이 모두 노출될 수 밖에 없다. 이에, 프라이버시 기능이 앱 수준에서 각각이 따로 만들어지다 보니, 사람들이 한곳에 모이지 않아 익명성과 유동성이 약해지는 문제 역시 존재하게 되었다. EIP-8182의 골자는 이를 해결하기 위해 하나의 큰 공용 프라이버시 풀을 이더리움 프로토콜 차원에서 제공하자는 것이다.
기술적으로 이 제안의 핵심은 외부 서킷(outer circuit)과 내부 서킷(inner circuit)의 분리 구조(; Two-Circuit Architecture)의 구현에 있다. 전자는 자금 보존, nullifier(이중 사용 방지), Merkle 검증 같은 절대 깨지면 안 되는 규칙을 담당한다. 반면 후자는 서명 방식(ECDSA, 패스키, 멀티시그 등)을 담당하며 자유롭게 확장된다. 이렇게 구조를 나누개되면 새로운 로그인 방식이 나와도 전체 프로토콜을 업그레이드할 필요 없이 해당 방식을 유연하게 추가할 수 있다. 즉, 안전성은 유지하면서 유연성은 크게 늘린 구조인 셈이다.
실제로 해당 EIP가 동작하는 방식도 생각보다 직관적이다. 사용자는 돈을 프라이버시 풀에 넣고(deposit), 그 안에서는 거래가 보이지 않게 이동한다. 그리고 필요할 때 다시 밖으로 꺼낼 수 있다(withdraw). 이 과정에서 시스템 컨트랙트는 commitment tree, nullifier set, user registry, auth policy registry 등을 관리하며, 트랜잭션마다 증명 검증과 상태 업데이트를 수행한다. 또한 registerAuthPolicy를 통해 다양한 인증 정책을 등록할 수 있어, 하나의 주소가 복수의 인증 방식을 유연하게 사용할 수도 있다.
Source: EIP-8182
이 EIP가 특히 흥미로운 이유는, 단순한 익명성 기능을 제공하는것을 넘어 보다 유연한 방식으로 “절충형 프라이버시 계층”으로써 기능할 수 있다는 점이다. 기본적으로는 거래를 은닉하지만, optional origin-tagged note를 통해 필요 시 자금의 출처를 증명할 수 있다. 즉, 완전한 익명성과 완전한 투명성 사이에서 컴플라이언스 계층을 유연하게 얹을 수 있으며, 결과적으로 AML, 회계, 기관 요구사항과도 연결 가능한 실질적인 활용 구조를 구현할 수 있도록 한다.
물론 이 EIP는 강한 제약도 갖는다. 시스템 컨트랙트는 업그레이드가 불가능하며, 프라이버시 구조가 한 번 잘못 설계되면 하드포크 없이는 수정이 어렵다. 또한, 멤풀(mempool) 프라이버시나 네트워크 레벨에서의 익명성은 본 EIP의 범위(scope)의 밖 이라고 직접적으로 표현한다.
그럼에도 불구하고 본 제안의 방향성은 이더리움이 단순한 실행 레이어를 넘어 공유되는 결제(shared settlement) + 공유되는 프라이버시(shared privacy) 레이어를 동시에 갖춘 네트워크로 진화할 수 있는 가능성을 보여준다는 점에서 분명한 의의가 있다.
2.2.2 기타
2.3.1 ERC-8167: Modular Dispatch Proxies
ERC-8167은 기존 모놀리틱(monolithic) 프록시 구조의 한계를 보완하기 위해, 함수 selector 기반으로 로직 모듈(delegate)을 분리하고 이를 동적으로 라우팅하는 모듈러식 디스패치 프록시(modular dispatch proxy) 구조를 표준화하려는 제안이다.
기존의 프록시 구조에서는 하나의 구현(implementation)에 모든 로직을 위임하는 방식이었기 때문에 업그레이드 시 전체 컨트랙트 교체가 필요하고 리스크가 컸다. 반면 ERC-8167은 함수 단위로 delegate를 분리하여 delegatecall을 수행함으로써, 특정 기능만 선택적으로 교체하거나 확장할 수 있다. 이는 코드 사이즈 제한을 우회하는 동시에, 공유되는 로직의 재사용(shared logic reuse)와 상호결합성(composability)를 구조적으로 강화한다.
Source: ERC-8167
코드를 좀 더 들여다보자면, ERC-8167의 핵심은 calldata의 첫 4바이트(selector)를 기준으로 delegate를 매핑하고, 해당 selector에 대응하는 delegate 주소를 조회한 뒤, 동일한 calldata를 넘겨 실행한다는 점이다. 이때 프록시는 로직을 재구성하지 않고 단순 라우터 역할만 수행하기 때문에, 실제 기능은 각 delegate 모듈에 분산된다.
implementation(bytes4)는 특정 selector가 어떤 delegate를 가리키는지를 반환하고, selectors()는 프록시가 지원하는 전체 selector 목록을 노출한다. 이를 통해 인덱서나 익스플로러는 selector 목록을 수집한 뒤 각 delegate의 ABI와 매칭하여 프록시의 전체 인터페이스를 복원할 수 있다. selector에 대응하는 delegate가 존재하지 않을 경우에는 FunctionNotFound 에러로 revert하는 것이 권장된다.
ERC-8167은 스마트 컨트랙트의 업그레이드 방식을 전체적인 교체(batch replacement) 에서 점진적인 개선(incremental evolution)으로 전환시킨다는데에 의의가 있다. 즉, 기존에는 하나의 변경이 전체 시스템 리스크로 이어졌다면, 이제는 모듈 단위로 점진적 업데이트가 가능해진다. 또한 새로운 표준이나 기능이 등장했을 때, 기존 컨트랙트를 교체하지 않고 새로운 모듈만 추가하는 방식으로 확장이 가능하다. 이는 특히 계정 추상화(account abstraction), 스마트 계정(smart account), 토큰 확장(token extension) 등 모듈별로 기능이 빠르게 확장되는 영역에서 매우 중요한 유연성을 제공한다.
다만 이러한 구조는 새로운 복잡성과 보안 리스크도 동반한다. 본 EIP 설명의 보안 고려사안(Security Considerations)에도 언급되어있듯, delegatecall 기반 구조는 storage layout 충돌, access control 오류, 그리고 잘못된 delegate 등록 시 치명적인 권한 위임 문제를 야기할 수 있다. 또한 selector 단위로 로직이 분산되면서 시스템 전체의 추적 가능성과 감사 난이도도 증가한다.
그럼에도 ERC-8167이 제시하는 최소 표준 인터페이스는 이러한 복잡성을 일정 수준 통제하면서, 다양한 모듈로 프록시 기반의 설계들을 하나의 공통 프레임워크로 묶는 역할을 한고, 결과적으로 이더리움 스마트 컨트랙트가 단일 컨트랙트 중심 구조에서 모듈형 실행 레이어로 기능할 수 있게끔 할 수 있다.
2.4.1 ERC-8183: Agentic Commerce
본 표준에 대한 설명은 Four Pillars 리서처 Jun에 의해 별도의 포스트를 통해 설명되었다. 아래는 해당 포스트에 대한 요약본이며, 자세한 내용은 해당 포스팅을 참조바란다.
거래는 본질적으로 상대방에 대한 신뢰를 전제로 한다. 하지만 온체인 환경에서는 이러한 신뢰를 전제하기 어렵고, 그 결과 커머스의 활용 범위 역시 구조적으로 제한된다. 이더리움 재단(Ethereum Foundation)의 dAI 팀과 버추얼스 프로토콜(Virtuals Protocol)은, 특히 에이전트 기반 워크플로우가 확산되고 있는 현재의 맥락에 맞춰 에이전틱 커머스의 보다 폭넓은 사용사례를 지원하기 위해 ERC-8183을 통해 에이전틱 커머스를 위한 새로운 표준을 제안했다.
현재 온체인에서는 개별 주체의 신용을 평가하고 이를 강제할 수 있는 구조가 부재하기 때문에, 커머스는 필연적으로 제한된 형태로만 구현된다. 과거 스펙트럴 프로토콜(Spectral Protocol)과 같은 시도들이 온체인 신용 점수 모델을 도입하려 했지만, 시장에서 지속되지 못했다. 이는 단순히 데이터 부족의 문제의 문제를 넘어, 신용이 작동하기 위해 필요한 전제—강제력, 신원, 연속성—가 온체인에서는 성립하기 어렵기 때문이다.
이러한 맥락에서 ERC-8183은 에이전트 간 거래를 지원하기 위해, 상호 간 신뢰를 정교하게 추정하는 접근 대신 거래 구조 자체를 재설계하는 방향을 택한다. 즉, 신뢰를 제거하기보다는 그 위치를 구조적으로 재배치함으로써 거래 상대방 리스크를 완화하고, 결과적으로 온체인 커머스의 작동 원리를 근본적으로 재정의하려는 시도의 기반을 마련한다.
Source : ERC-8183
제안은 에이전트 간 상거래를 위한 최소 단위로 Job, Escrow, Evaluator, Hook이라는 네 가지 구성 요소를 정의한다. 모든 거래는 Job으로 표현되며, 클라이언트는 작업 시작 이전에 예산을 에스크로에 예치해야 한다. 상태는 Open → Funded → Submitted → Completed/Rejected/Expired로 전이되며, Funded 단계에서 자금이 선제적으로 잠기기 때문에 “대금을 받을 수 있을지”에 대한 불확실성이 제거된다. 즉, 거래 이행 자체는 구조적으로 보장이 되는 구조이다.
Source : ERC-8183
다만 결과물의 적정성에 대한 판단은 여전히 필요하며, 이 역할은 Evaluator가 담당한다. Submitted 이후에는 Evaluator만이 해당 Job의 완료 또는 거절을 결정할 수 있는데, 이는 신뢰를 완전히 제거했다기보다 특정 지점으로 재배치한 구조로 이해하는 것이 타당하다. 거래 당사자 간 신뢰는 제거되지만, 대신 Evaluator에게 판단 권한이 집중되기 때문이다. 제안은 이를 보완하기 위해 Hook 구조와 외부 평판 시스템 연동을 열어두고 있으며, 예를 들어 ERC-8004와 같은 레이어를 통해 Evaluator의 이력과 신뢰도를 추적하는 방식을 권장한다.
그럼에도 불구하고 Evaluator의 악의적 행동 가능성은 여전히 존재하며, 프로토콜 차원에서의 분쟁 해결이나 강제 집행 메커니즘은 포함되어 있지 않다. 하지만 ERC-8183의 의의는 완전한 신뢰를 구현하는 데 있는 것이 아니라, 신뢰가 요구되는 지점을 최소화하고 집중시키는 데 있다. 에스크로를 통해 이행을 강제하고, Evaluator의 평판을 선택 기준으로 활용하며, 인센티브 설계를 통해 정직한 행동이 합리적인 선택이 되도록 유도함으로써, 온체인 환경에 적합한 보다 효율적인 세로운 신뢰 구조를 제시하는 것이다.
한편, 3월 한달간은 11개의 새로이 ‘Draft’로 채택된 EIP들을 제외하고, 10개의 기존 EIP의 상태가 변화하였다. 이 중 6개의 EIP들은 최종적으로 채택되기위한 다음 단계(i.e., ‘Final’, ‘Last Call’, ‘Review’, ‘Draft’ 등의 단계)로 격상되었는데, 게중에서도 5개가 Final 단계로 격상되었다. 나머지 총 4개의 EIP의 경우, 다음 단계로 가지못하고 ‘Stagnant’ 단계로 바뀐 EIP가 4개(i.e., EIP-7768, EIP-7792, EIP-7898, EIP-8013)가 있다.
또한 특이하게도, 이번 달에 진전이 있었던 6개의 EIP 들은 모두 애플리케이션 수준에서 구현되는 ERC들이 자리하였다.
ERC들 중 특히 주목할만한 것들은 다양한 크로스체인 메시징 프로토콜을 플러그인처럼 교체 가능하게 추상화하는 Gateway 인터페이스 표준인 ERC-7786, 협업 참여자 간 권한과 수익 분배 관계를 표준화하여 공동 창작 NFT 컬렉션을 가능하게 하는 표준인 ERC-7832, rNFT 기반 DAG 구조에서 여러 NFT 간 로열티 분배와 전파 범위를 제어할 수 있도록 하는 확장형 로열티 표준인 ERC-8034*, 그리고 ERC-20 토큰의 잔액을 “멤버십 수준”으로 해석하여 온체인에서 그룹 구성원과 권한을 표현할 수 있도록 하는 표준인 ERC-8063 등이 있다.
*이에 대해서는 이전 아티클에서 다루었다.
이 외 참고할만한 다른 EIP들은 아래와 같다.
3월, 이더리움의 정체성과 역할을 다시 톺아보는 두 개의 중요한 글이 공개되었다. 하나는 이더리움 재단의 역할을 규정한 Mandate였고, 다른 하나는 L1–L2 구조 속에서 이더리움이 어떤 위치를 가져야 하는지를 설명한 글이었다. 두 글은 서로 다른 층위를 다루지만, 결국 하나의 질문으로 수렴하였다. 바로 “이더리움은 어떤 원칙 위에 존재하는 시스템인가”에 대한 답이다.
이더리움은 비트코인의 “불특정 다수의 참여자가 인센티브 기반으로 시스템을 유지하는 구조”를 통해 탈중앙화의 개념을 확장하였고, 스마트 컨트랙트 플랫폼의 새로운 지평을 열었다. 하지만 그 과정이 처음부터 순탄했던 것은 아니다. 글로벌 단위의 보안과 탈중앙성을 유지하는 p2p 네트워크를 처음 설계하는 과정이다보니, 확장성은 필연적으로 제약을 받을 수 밖에 없었고, 이는 낮은 실용성이라는 비판으로 이어졌다. 그 틈을 파고들며 수많은 알트 L1들이 등장했고, 이더리움의 지위가 흔들리던 시기도 존재했다.
그럼에도 불구하고 현재 이더리움은 여전히 가장 강력한 유동성과 개발자 생태계를 보유한 스마트 컨트랙트 플랫폼으로 자리잡고 있다. 네트워크 성능은 수많은 연구와 개선을 통해 점진적으로 발전해왔지만, 지금의 위치를 만든 것은 단순한 기술적 우위만은 아니다. 장기간에 걸쳐 축적된 신뢰, 그리고 그 신뢰를 가능하게 만든 일관된 방향성이 지금의 위치를 만들었다. 즉, 이더리움을 지탱해온 것은 성능이 아니라 ‘무엇을 포기하지 않는가’에 대한 이더리움의 근간 철학이었던 것이다.
이 지점에서 이더리움의 페르소나는 분명해진다. 스마트 컨트랙트 플랫폼은 본질적으로 오픈소스이기 때문에 멀티체인 환경에서는 기능적 차별화만으로 지속적인 채택을 이끌어내기 어렵다. 그렇다면 결국 중요한 것은 복제 불가능한(unforkable) 정체성이다. 이더리움은 CROPS(Censorship Resistance, Open Source, Privacy, Security)라는 원칙을 중심으로, 어떤 상황에서도 훼손되지 않는 기준을 유지해왔다. 이는 단순한 가치 선언이 아니라, 프로토콜 설계와 의사결정 전반을 관통하는 구조적인 제약이며, 바로 이 점이 이더리움을 다른 L1과 구별짓는다.
최근 발표된 두 블로그 글 역시 이러한 방향성을 더욱 선명하게 드러낸다. 이더리움 재단은 네트워크를 성장시키거나 통제하는 주체가 아니라, 오히려 그 영향력을 줄이며 네트워크의 독립성과 탈중앙성을 보장하는 역할을 수행한다. 동시에 이더리움은 L1에서 모든 것을 해결하려 하지 않고, L2와의 분리를 통해 신뢰 레이어로서의 역할에 충실히 집중한다.
이러한 구조는 결국 “생태계 성숙도(ecosystem maturity)”로 이어진다. 인프라 성능이 상향평준화된 현재, 스마트 컨트랙트 플랫폼 간의 경쟁력은 더 이상 단기적인 성능 지표로 결정되지 않는다. 다양한 애플리케이션이 등장할 수 있는 환경, 충성도 높은 사용자층, 폭넓은 참여자 기반, 그리고 고유한 문화와 운영 철학이 장기간 축적되며 형성되는 지속 가능한 시너지가 핵심이다. 이더리움은 이미 이 성숙도를 가장 깊게 축적한 네트워크이며, 이에 기저하는 페르소나에 공감하는 새로운 참여자들을 계속해서 끌어들이고 다시 생태계를 강화하는 선순환을 만들어낸다.
결국 이더리움은 지금까지 원칙에 근거한 선택을 통해 스스로를 증명해왔다. 명확한 철학에 공감하는 초기 기여자들로부터 출발해, 오랜 시간 동안 신뢰와 문화를 축적해온 결과, 이제는 쉽게 흔들리지 않는 기반층을 갖추게 되었다. 그리고 이제, 비록 정량화를 할 수는 없겠지만, 이더리움은 단순히 생존을 넘어 더욱 빠른 속도로 독보적인 인프라를 공고히 해 나가는 단계에 진입하고 있다.
Ethereum