목차
Key Takeaways
- 9월에는 신규 EIP 수가 전월과 같았지만 기존 제안의 진전은 줄었다. 코어(Core) 단에서는 새로운 인증 방식을 도입하고 검증 및 저장 부담을 줄이는 제안이, ERC에서는 거래 보호와 AI 에이전트의 상태 및 권한 관리, 컨트랙트 모듈에 공통 규격을 마련하는 제안이 주를 이뤘다.
- 또한 9월 EF는 2029년까지 양자내성을 확보한다는 목표 아래, 헤고타(Hegotá) 업데이트의 핵심으로 검열 저항성과 네이티브 계정 추상화를 제시하며 장기적인 연구 로드맵과 업그레이드 우선순위를 연결했고, ETH의 발행 정책은 생태계 전반의 논의가 필요하다는 입장을 밝혔다.
- 한편, 이더리움은 기관 도입과 ETH의 경제적 가치에 대한 요구 속에서, 기존 원칙을 실제 사용과 성장으로 연결해야 한다. 이를 위해 연구자와 개발자, 그리고 사업 운영자가 정책의 효과와 현장의 제약을 함께 검증하고, 각자의 선택이 이더리움에 무엇을 남기는지 입증해야 한다.
이더리움은 스마트 컨트랙트라는 개념을 기존의 분산 원장 구조에 접목하며 블록체인의 새로운 지평을 열었다. 이러한 설계 철학은 EIP(Ethereum Improvement Proposal)라는 형태를 통해 점진적으로 구체화되었고, 그 결과 블록체인은 단순한 가치 저장 수단을 넘어 실제 비즈니스와 다양한 유스케이스를 담아낼 수 있는 인프라로 진화하고 있다. 이러한 발전의 흐름 속에서, 각기 다른 시각과 문제의식을 지닌 오피니언 리더들이 EIP 논의에 더욱 폭넓게 참여한다면, 우리가 그려보는 디지털 네이티브한 미래 역시 한층 더 풍부해질 수 있을 것이다.
본 아티클은 매월 새롭게 ‘Draft’ 단계로 채택되는 제안들과, 그 과정에서 상태(status)가 변화하는 주요 제안들을 하이레벨에서 조망하며 EIP 트렌드를 정리한다. 이를 통해 빌더와 비즈니스 관계자들이 EIP의 흐름과 맥락을 보다 입체적으로 이해하고, 나아가 각자의 영역에서 새로운 가치를 제안하는 데 참고할 수 있는 출발점이 되기를 기대한다.
본 아티클과 관련된 EIP 데이터는 EIP, ERC, RIP 공식 깃허브 레포지토리를 각각 활용해 수집 & 분석되었다.
1. 이달의 이더리움 논의 요약
9월의 EIP 흐름에서 가장 두드러지는 특징은, 신규 제안 수는 전월과 같은 수준을 유지했지만 기존 EIP의 진전은 줄었다는 점이다. 신규 EIP는 총 10개로 8월과 동일했으며, 다음 단계로 진전된 기존 EIP는 전월 25개에서 10개로 감소했다. 철회된(withdrawn) 제안은 없었다.
새로 제안된 Core EIP 중 EIP-8355는 양자내성 서명인 ML-DSA를 컨트랙트에서 검증할 수 있는 프리컴파일을, EIP-8288은 여러 거래의 서명과 증명을 멤풀 단계부터 집계해 데이터와 검증 비용을 줄이는 구조를 제시했다. 한편 EIP-8360은 한 거래에서만 사용하는 임시 컨트랙트를 위한 TCREATE 명령어를 제안했고, EIP-8383은 합의 클라이언트가 다른 노드에 제공해야 하는 최소 블록 기록을 약 다섯 달에서 36일로 줄이는 방안을 제시했다. 전반적으로 새로운 인증 방식을 지원하는 동시에, 거래마다 반복하는 검증과 거래 이후에도 남겨두는 코드 및 데이터의 부담을 줄이려는 시도가 두드러졌다.
애플리케이션 레이어를 위한 ERC에서는 거래 보호와 AI 에이전트의 상태 관리를 공통 인터페이스로 정리하려는 흐름이 나타났다. ERC-8377은 거래를 만들 때 고정한 최소 수령량 대신 실행 시점의 오라클 가격을 기준으로 허용 손실을 계산하고, 실제 수령량이 그 기준을 충족하는지 확인하도록 했다. ERC-8350은 AI 에이전트의 기억 원문을 공개하지 않으면서, 변경 권한과 상태 변화의 순서를 온체인에서 확인할 수 있는 레지스트리를 제안했다.
기존 EIP의 진전에서는 검증자의 운영 위험과 컨트랙트의 모듈 관리, 토큰의 권한 구조를 다루는 제안들이 다음 단계로 이동했다. EIP-7716은 다수 검증자가 동시에 장애를 겪을 때 더 높은 페널티를 부과해 운영 환경의 분산을 유도했고, ERC-8153과 ERC-8167은 각각 다이아몬드 컨트랙트의 모듈 관리와 함수별 구현 연결 및 조회를 표준화했다. 이 밖에도 토큰의 투표권 위임과 과거 시점의 투표권 조회를 위한 ERC-5805, 공개키 해시와 서명으로 소유권과 전송을 관리하는 ERC-7962가 진전됐다.
요컨대, 8월에 장기적인 프로토콜 개편안의 진전이 집중됐다면, 9월에는 새로운 인증 기술을 실제로 사용할 기반을 마련하고 노드와 개발자가 부담하는 검증, 보관, 그리고 관리 비용을 조정하는 제안들이 함께 나타났다. 프로토콜 단에서는 보안 기능을 지원하는 데 필요한 자원 부담을, ERC에서는 거래 조건과 변경 권한을 일관되게 다루는 방법을 구체화한 달로 볼 수 있다.
Source: blog.ethereum.org
한편, 9월에는 이더리움 재단(EF)이 장기적인 연구 방향을 다음 업그레이드의 우선순위와 연결하는 움직임이 나타났다. 9월 7일 EF Protocol 조직은 프로토콜 연구 우선순위를 공개하며, 실행 & 합의 & 데이터 레이어 전반에서 2029년 12월까지 양자내성을 확보하겠다는 목표를 제시했다. 빠른 완결성과 프라이버시, 상태 관리, zkEVM도 주요 연구 토픽으로 유지하되, 여러 업그레이드의 연구와 구현을 병행해야 이 일정에 도달할 수 있다고 설명했다.
이러한 방향은 같은 날 공개된 Hegotá 후보 EIP 평가에서 더욱 구체적으로 드러났다. EF Protocol 조직은 62개 후보를 대상으로 처음 통합 평가를 발표하고, 검열 저항성을 강화하는 FOCIL과 네이티브 계정 추상화를 위한 프레임 트랜잭션(Frame Transactions)을 본 업그레이드의 핵심으로 제시했다. 특히 글램스테르담(Glamsterdam) 준비 과정에서 얻은 교훈을 바탕으로, 개별 기능의 장점뿐 아니라 다른 변경 사항과 결합했을 때의 복잡성과 테스트 부담, 후속 합의 개편과의 충돌 가능성까지 평가에 반영했다. 이 점에서 9월의 발표는 무엇을 추가할지와 함께, 장기적인 전환을 제때 진행하기 위해 무엇을 미루거나 제외할지도 명시하기 시작했다는 의미가 있다.
EF가 기술적 우선순위를 제시하면서도, 스스로 결정할 수 있는 범위에 선을 그었다는 점도 주목할 만하다. 같은 평가에서 발행량과 보상 정책을 바꾸는 제안들은 Hegotá 포함 대상으로 지지하지 않았지만(e.g., EIP-8363), 이를 제안 자체의 타당성에 대한 부정으로 설명하지는 않았다. 발행 정책은 스테이커와 ETH 보유자, 장기적인 네트워크 보안 예산에 영향을 주므로, EF Protocol 조직이나 특정 업그레이드의 범위 선정만으로 방향을 정하기보다 여러 생태계 주체가 참여하는 논의가 필요하다고 밝혔다. 이는 재단이 프로토콜 개발의 우선순위를 조율하는 역할과, 생태계 전반의 경제적 이해관계를 결정하는 역할을 구분하려는 태도로 볼 수 있다.
2. 새로이 제안된 EIP들
9월 한달 간 새로이 채택된 EIP의 수는 총 10개로, 전월과 동일한 수의 EIP가 제안되었다. 당월의 새로운 EIP는 네트워크 단의 개선을 요하는 코어(Core) EIP와 애플리케이션 단에서 구현되는 표준인 ERC가 주를 이루었다.
아래에서는 새로이 ‘Draft’로 채택된 EIP들을 더욱 세부적으로 분류해보고, 특별히 주요깊게 살펴볼만한 EIP들을 살펴본다.
2.1 코어 / 네트워킹 레이어
2.1.1 EIP-8355: Precompiles for ML-DSA Verification
블록체인 계정의 보안은 자산을 보유하는 동안 서명이 얼마나 오래 신뢰를 유지할 수 있는지와도 연결이 된다. 특히 양자컴퓨터의 위협에 대비하려면, 새로운 서명 방식으로 만든 승인도 온체인에서 검증할 수 있어야 한다. EIP-8355는 이를 위해 ML-DSA 검증용 프리컴파일을 제안한다(미국 국립표준기술연구소(NIST)가 표준화한 ML-DSA는 대규모 양자컴퓨터를 동원한 공격에도 안전할 것으로 평가되는 전자서명 알고리즘이다).
프리컴파일은 복잡한 연산을 실행 클라이언트가 직접 처리하고, 컨트랙트는 지정된 주소를 호출해 사용하는 기능이다. 기존에 제안된 EIP-8051도 ML-DSA 검증용 프리컴파일을 제안했지만, 세 가지 보안 수준 중 ML-DSA-44만 지원하고 검증할 메시지도 32바이트로 제한했다. EIP-8355는 더 높은 보안 수준인 ML-DSA-65와 ML-DSA-87까지 지원하고 메시지 길이 제한을 풀어 활용 범위를 넓히려는 제안이다.
호출할 때는 pubkey ++ signature ++ message, 즉 공개키와 서명, 승인할 메시지를 순서대로 붙여 전달한다. 공개키와 서명의 길이는 선택한 보안 수준에 따라 정해지므로, 나머지 데이터를 메시지로 읽는다. 덕분에 긴 메시지도 미리 해시값으로 줄일 필요 없이 검증할 수 있다. 표준 공개키와 서명 형식을 그대로 받기 때문에, 이를 지원하는 키 관리 서비스나 하드웨어 보안 모듈에서 비밀키를 꺼내지 않고 만든 서명을 온체인 인증에 활용할 수 있다.
비용 설계에서는 전송량과 계산량 사이의 절충을 고민한 흔적이 드러난다. EIP-8051은 검증에 필요한 계산을 일부 마친 “큰” 공개키를 받지만, EIP-8355는 “작은” 표준 공개키를 받고 추가 계산을 클라이언트에 맡긴다. ML-DSA-44 기준 공개키 크기는 20,512바이트에서 1,312바이트로 줄어드는 대신, 기본 검증 가스는 높아진다. 이는 반복해서 보내는 데이터의 부담을 줄이고 검증 연산에 비용을 부과하는 선택이며, 제시된 가스 수치는 벤치마크를 거쳐 확정해야 한다.
개발자는 호출 성공 여부와 서명 유효성을 구분해야 한다. 잘못된 서명에도 호출은 정상 종료하며, 32바이트 반환값의 1과 0으로 검증 결과를 알려준다. 또한 다른 체인이나 컨트랙트에서 같은 승인이 재사용되지 않도록, 애플리케이션이 메시지에 체인, 컨트랙트, 그리고 논스 정보를 포함해야 한다. 이 제안은 기존 계정을 자동으로 양자내성 계정으로 전환하지는 않지만, 지갑과 커스터디가 ML-DSA 인증을 설계할 때 함께 사용할 검증 기반을 마련하려는 시도로 읽을 수 있다.
2.1.2 EIP-8360: TCREATE Opcode
이더리움에 배포된 스마트 컨트랙트는 보통 여러 거래에서 반복해서 쓰인다. 하지만 특정 거래를 처리하는 동안에만 필요한 코드도 있는데, 이런 코드까지 계속 보관할 이유는 없다. 기존에는 컨트랙트를 만든 뒤 SELFDESTRUCT로 없애는 방식을 썼지만, 삭제에 따른 가스 환급이 사라지고 삭제 조건도 제한되면서 비용과 구현 부담이 남게 되었다. EIP-8360은 이런 일회성 코드를 처음부터 짧게 쓰고 정리할 수 있도록 새로운 배포 명령어 TCREATE를 제안한다.
TCREATE로 만든 컨트랙트는 하나의 거래가 진행되는 동안에는 일반 컨트랙트처럼 실행되고, 거래가 끝나면 코드와 저장 데이터가 사라진다. 다만 그 주소에 남은 ETH까지 없어지는 것은 아니므로, 계정 자체를 완전히 정리하려면 잔액도 비워야 한다. 주소는 배포자와 개발자가 지정한 salt, 초기화 코드를 바탕으로 미리 계산할 수 있다. 이 계산에 CREATE2와 다른 접두사(prefix)를 사용해, 기존 방식으로 배포한 컨트랙트와 주소가 겹치지 않도록 한다.
이 구조에서는 코드를 실행하는 비용과 거래 이후에도 보관하는 비용을 나눌 수 있다. 초기화와 연산, 메모리 사용에는 여전히 가스가 들지만, 거래가 끝나면 사라질 코드에 영구 보관 비용을 부과하지 않는다. 현재 공개 명세에서는 데이터를 읽고 쓰는 SLOAD와 SSTORE도 임시 저장 공간을 사용하므로, 실행 중 필요한 값을 기록하되 다음 거래까지 남기지는 않는다. 반면 ETH 잔액처럼 거래 이후에도 유지되는 정보에는 상태 보관 비용이 적용된다.
스마트 계정에서는 거래마다 필요한 추가 기능을 짧게 만들어 쓰는 데 활용할 수 있다. 예를 들어 거래 데이터에 담긴 코드를 임시 컨트랙트로 배포하면, 계정에 그 기능을 계속 설치해 두지 않고도 해당 거래에서 실행할 수 있다. 컨트랙트 배포를 중개하는 용도로도 쓸 수 있는데, 임시 컨트랙트가 CREATE로 만든 자식 컨트랙트는 거래 이후에도 남는다. 기존 CREATE3 배포 패턴에서 주소를 정하기 위해 거쳐 가는 중개 컨트랙트만 정리할 수 있다는 뜻이다.
다만 임시 컨트랙트의 수명과 그 컨트랙트가 남긴 결과는 구분해야 한다. 코드가 사라져도 다른 컨트랙트에 기록한 토큰 승인이나 권한은 남을 수 있고, 이후 같은 주소에 다시 배포된 코드의 동작도 달라질 수 있다. 따라서 주소가 같다는 이유만으로 이전과 같은 코드를 신뢰하거나 장기적인 권한을 맡겨서는 안 된다. 아직 저장 명령어와 가스 처리 방식에 대한 수정이 논의 중인 Draft 제안이지만, 일회성 실행에 필요한 비용과 정리 절차를 EVM이 직접 처리하도록 한다는 점에서 개발자의 부담을 줄일 수 있다.
2.1.3 EIP-8383: Reduce CL Block Retention Window
이더리움 노드를 운영하는 데 드는 비용은 최신 블록을 검증하는 것만으로 결정되지 않는다. 다른 노드의 동기화를 돕기 위해 과거 블록을 보관하고 전달하는 일도 운영자의 몫이다. 최근의 확정된 상태(status)에서 시작하는 ‘체크포인트 동기화’를 사용해도, 이 역할을 수행하려면 별도로 거의 다섯 달치 블록을 내려받아야 한다. EIP-8383은 현재 합의에 참여하는 데 필요한 데이터와 다른 노드에 제공할 과거 데이터의 범위를 구분하고, 후자의 부담을 줄이려는 제안이다.
이 배경을 이해하려면 체크포인트가 왜 필요한지부터 살펴볼 필요가 있다. 지분증명에서는 이미 지분을 회수한 검증자들이 과거의 키로 별도 체인을 만들어, 새로 접속한 노드를 속이는 롱 레인지 공격(long range attack)이 가능하다. 따라서 노드는 신뢰할 수 있는 최근 체크포인트를 출발점으로 삼고, 이후 블록을 직접 검증한다. 이때 체크포인트가 안전한 출발점으로 인정되는 기간을 ‘약한 주관성 기간(Weak Subjectivity Period)’이라고 하며, 너무 오래된 체크포인트는 과거 블록을 더 확보한다고 안전해지지 않는다.
구체적인 변경은 MIN_EPOCHS_FOR_BLOCK_REQUESTS = 8192로, 합의 클라이언트가 다른 노드의 요청에 응답해야 하는 최소 블록 범위를 기존 33,024에포크에서 8,192에포크로 줄인다. 에포크는 이더리움의 합의 진행 단위로, 8,192에포크는 약 36.4일에 해당한다. 기존 범위는 약한 주관성 계산에서 최대 안전성 저하를 가정한 값에 기반하지만, 현재 메인넷 정책에 따른 상한은 3,532에포크다. 제안은 이보다 넉넉한 8,192에포크를 고정값으로 사용해, 클라이언트가 보관 및 삭제의 범위를 예측하기 쉽게 만든다.
운영 측면에서는 체크포인트 이전의 블록을 채우는 ‘백필(backfill)’ 작업이 줄어드는 효과가 있다. 최신 상태까지 따라잡는 동기화와 별개로 수행하던 과거 데이터 다운로드가 줄어, 대역폭과 디스크 사용량, 쓰기 작업을 절감할 수 있다. 일부 합의 클라이언트는 과거 블록의 실행 데이터를 실행 클라이언트에서 가져오므로, 이 변경은 실행 클라이언트의 과거 데이터 보관 부담을 줄이는 데도 도움이 될 수 있다. 인프라 운영자에게는 새 노드를 구성할 때 현재 합의 참여와 과거 데이터 제공을 위해 각각 얼마의 자원이 필요한지 더 명확히 구분할 수 있게 된다.
다만 보관 범위를 줄이려면 안전 조건도 함께 유지해야 한다. 향후 프로토콜 변경으로 약한 주관성 기간이 늘어나더라도 8,192에포크가 그 상한보다 길어야 하며, 블록 확정이 장기간 멈추는 상황에서는 미확정 블록을 모두 보관하도록 권고한다. 하드포크는 필요하지 않고 더 긴 기록을 보관하는 것도 허용되지만, 일반 노드들이 반드시 제공해야 하는 과거 데이터의 범위는 좁아진다. 이 점에서 EIP-8383은 모든 노드가 부담할 최소 보관 의무를 실제 동기화의 안전 요건에 맞춰 조정하려는 시도로 볼 수 있다.
2.1.4 기타
2.2 데이터 / 메시징 / 트랜잭션
2.2.1 EIP-8288: In-mempool signature and proof aggregation
이더리움에서 새로운 보안 기술을 쓰려면, 거래 한 건을 처리하는 데 얼마나 많은 데이터와 연산이 필요한지도 따져야 한다. 양자컴퓨터 공격에 대비한 서명이나 프라이버시를 위한 증명은 크기가 커서, 거래마다 블록에 담고 검증하면 비용이 빠르게 늘어난다. EIP-8288은 여러 거래의 서명과 증명을 묶어 이 부담을 줄이려는 제안이다. 핵심은 각각을 검증한 결과를 하나의 증명으로 만들어, 네트워크가 같은 작업을 반복하는 비용을 줄이는 데 있다.
이를 위해 거래를 검증·실행 등 여러 단계로 나누는 EIP-8141의 ‘프레임(frame)’ 구조를 활용한다. 새로 추가하는 DEP_VERIFY_FRAME_MODE에는 “어떤 데이터에 대한 어떤 키의 서명을 확인해야 하는가”를 적는다. 이렇게 검증할 대상을 거래에 미리 명시하면, 노드는 거래 코드를 실행하기 전부터 필요한 서명을 확인하고 집계할 수 있다.
검증할 대상은 (scheme, data_hash, verification_key_hash)라는 세 값으로 표시한다. 각각 암호 방식, 검증할 데이터, 검증에 사용할 키를 식별하며, 실제 서명이나 증명은 거래와 함께 별도로 전달된다. 컨트랙트는 FRAMEPARAM과 FRAMEDATACOPY로 이 정보를 읽고, 지정된 데이터와 키가 자신이 요구하는 인증 조건에 맞는지 확인한다. 암호 검증은 집계 증명이 맡고, 그 검증이 해당 거래에 필요한 것인지는 컨트랙트가 판단하는 구조다.
거래가 블록에 들어가기 전 대기하는 멤풀에서도 집계가 이뤄진다. 노드는 여러 서명이나 기존 집계 증명을 다시 하나로 묶는 ‘재귀적 STARK(Recursive STARK)’를 만들고, 빌더는 이를 활용해 최종 블록에 담을 거래의 증명을 완성한다. 다른 노드들은 블록 헤더의 recursive_stark를 검증해 필요한 서명 검증이 모두 이뤄졌는지 확인한다. 따라서 빌더가 검증을 수행하더라도, 다른 노드들이 그 결과를 믿고 받아들일 필요는 없다.
실용적 의미는 큰 서명과 증명을 사용하는 거래의 비용을 낮출 공통적인 경로를 마련한다는 데 있다. 다만 현재 초안은 양자내성 서명인 leanSPHINCS만 허용하며, 일반 STARK 증명을 집계하는 경로는 아직 예약돼 있다. 또한 실질적인 도입에는 네트워크 업그레이드가 필요하고, 멤풀 노드와 빌더에는 증명을 생성하는 부담이 추가된다. 결국 이 제안에 있어 중요한 것은 블록의 데이터와 검증 비용을 줄이는 효과가, 새로 생기는 증명 생성 비용과 운영 부담을 얼마나 상쇄하느냐라고 할 수 있을 것이다.
2.2.2 기타
2.3 계정 / 컨트랙트 / 토큰 표준 / 지갑
2.3.1 기타
2.4 애플리케이션
2.4.1 ERC-8377: Reference-Relative Slippage Bounds
토큰을 교환할 때는 견적을 확인한 시점과 실제 거래가 실행되는 시점의 가격이 다를 수 있다. 이를 대비해 사용자는 “이 수량보다 적게 받으면 거래를 취소하라”는 최소 수령량인 minAmountOut라는 파라미터를 설정한다. 문제는 거래 실패를 피하려고 이 기준을 낮출수록, 공격자가 사용자의 거래 앞뒤에 주문을 넣어 가격을 불리하게 만드는 샌드위치 공격의 여지도 커진다는 점이다. ERC-8377은 최소 수령량을 정하는 기준을 거래 실행 시점의 시장 가격에 맞추려는 제안이다.
기존 방식이 “최소 990개를 받겠다”는 고정된 수량을 지정한다면, 이 제안은 “실행 당시 시장 가격을 기준으로 일정 수준의 손실까지만 허용하겠다”는 조건을 지정한다. 사용자는 가격 제공자와 예상 거래 비용, 추가 손실 허용치 등을 SlippagePolicy에 담아 전달한다. 실행 컨트랙트는 외부 가격을 온체인에서 제공하는 오라클에 ERC-7726의 getQuote()를 호출해, 투입한 토큰의 기준 교환 수량을 조회한다.
여기서 기준 수량은 수수료와 거래 자체가 가격에 미치는 영향을 반영하지 않은 값이다. 따라서 먼저 expectedCostBps로 이러한 정상적인 비용을 차감하고, 남은 예상 수령량에 maxDeviationBps라는 추가 손실 허용치를 적용한다. 정상 비용과 불리한 체결을 구분해 보호 범위를 좁히는 것이다. 여기에 시장 가격과 관계없이 지켜야 할 절대 최소 수령량인 hardFloor도 함께 적용한다.
거래 후에는 수령인의 토큰 잔액이 실제로 얼마나 늘었는지 확인하고, 계산한 하한에 못 미치면 거래 전체를 되돌린다. 거래 경로가 반환한 숫자를 그대로 믿지 않으므로, 지급되지 않은 토큰을 수령량으로 인정하는 문제를 막는다. 지갑과 여러 거래 경로를 비교하는 애그리게이터는 이 공통 인터페이스로 보호 조건을 전달할 수 있다. 또한 거래 유효기간인 deadline을 설정해, 현재 가격에는 부합하더라도 사용자가 오래전에 결정한 거래가 뒤늦게 실행되는 것을 제한한다.
다만 보호 효과는 오라클의 신뢰성과 가격 최신성에 달려 있다. 거래하는 풀의 현물 가격을 기준으로 쓰면 공격자가 체결 가격과 보호 기준을 함께 움직일 수 있어, 명세는 이를 금지한다. 또한 허용 범위 안의 샌드위치 공격은 여전히 가능하고, 오라클 가격과 거래 시장의 가격이 정상적으로 벌어져도 거래가 실패할 수 있다. 현재 Draft인 이 제안은 사용자가 감수할 거래 비용과 추가 손실을 구분하고, 이를 실제 수령량으로 검증하는 공통 규격으로 생각해볼 수 있다.
2.4.2 기타
3. 기존 EIP들의 진전
한편, 9월 한달간은 10개의 새로이 채택된 EIP들을 제외하고, 10개의 기존 EIP의 상태가 변화하였다. 해당 EIP 중, 모든 EIP들이 최종적으로 채택되기위한 다음 단계(i.e., ‘Final’, ‘Last Call’, ‘Review’, ‘Draft’ 등의 단계)로 격상되었고, ‘Withdrawn’ 상태로 격하된 EIP는 없었다.
격상된 ERC들 중 특히 주목할만한 것들은 - 토큰의 투표권 위임과 시점별 조회를 위한 표준인 ERC-5805, 공개키 해시와 서명으로 토큰 소유권과 전송을 관리하는 표준인 ERC-7962, 다이아몬드(Diamond) 컨트랙트의 모듈 관리와 업그레이드를 간소화하는 표준인 ERC-8153, 그리고 함수별 구현 모듈을 연결하고 조회하는 프록시 표준인 ERC-8167 등이 있다.
ERC를 제외한 EIP들 중 특히 주목할만한 것들은 - 검증자의 동시 장애에 더 높은 페널티를 부과하는 제안인 EIP-7716 등이 있다.
이 외 참고할만한 다른 EIP들은 아래와 같다.
3.1 코어 / 네트워킹 레이어
3.2 데이터 / 메시징 / 트랜잭션
3.3 계정 / 컨트랙트 / 토큰 표준 / 지갑
3.4 애플리케이션
4. 이더리움의 이상은 어떻게 현실이 되는가
이더리움은 탈중앙화와 검열 저항성, 특정 주체를 신뢰하지 않아도 되는 구조를 발전시키며 블록체인의 가능성을 넓혀왔다. 하지만 금융 서비스가 쌓이고 기관의 참여가 늘어나면서, 사용성과 사업성, 그리고 ETH의 경제적 가치까지 증명해야하는 요구도 커지고 있다. 이는 분명히 이더리움을 실제 수요와 연결하는 동력이지만, 눈앞의 성과에 논의가 쏠리면서 기존의 이더리움 설계 원칙과 긴장을 빚기도 한다.
Source: Ethereum Blog
이러한 변화 속에서 재단은 6월 조직 개편을 통해 프로토콜 조직이 이더리움을 더 잘 팔리게 하거나 단기적 이해관계에 집중하기 위해 존재하지 않는다고 밝혔다. 이는 특정 기업의 요구에 따라 개방된 네트워크의 원칙을 바꾸지 않겠다는 뜻으로 읽힌다. 다만 그 원칙을 지키면서도 사용자의 요구를 설계에 반영해야, 이더리움의 가치도 더 넓게 쓰일 수 있다.
하지만 최근 ETH 발행량 조정을 제안한 EIP-8363을 둘러싼 논쟁은 이 과정이 쉽지 않음을 보여준다. 제안자들은 스테이킹 집중을 억제하고 ETH의 화폐성을 지키려 했지만, 반대 측은 보상 축소가 독립 운영자를 먼저 밀어낼 수 있다고 지적했다. 양쪽 모두 탈중앙화를 주장하면서도, 이를 달성할 방법과 시장의 반응에 대해서는 다른 결론에 도달한 것이다.
Source: X(@dankrad)
사업 개발(BD) 논쟁에도 비슷한 간극이 있다. 한쪽은 기관 도입을 이끌 전담 조직이 필요하다고 보고, 다른 쪽은 BD 없이도 선택받을 만큼 차별화된 기술에 집중해야 한다고 주장한다. 물론 Etherealize처럼 기관용 솔루션과 도입을 지원하는 외부 조직도 있으므로, 재단이 모든 기능을 직접 맡을 필요는 없다. 다만 이들이 기관에 기술과 운영 파트너를 연결하고, 도입 과정에서 확인한 공통의 제약을 재단과 개발팀에 전달할 수 있도록 협력 경로를 구체화해야 한다.
이런 점에서 재단의 축소와 외부 조직의 역할 확대는 분업의 시작일 뿐이다. 도입 지원 조직은 기관의 문제를 구체화하고, 개발자는 기존 도구로 해결할지, 표준이나 프로토콜을 바꿔야 할지 판단해야 한다. 사업 성과도 파트너십이나 거래량에 그치지 않고, 안정성과 비용 예측 가능성, 기존 시스템과의 연동 등 기관의 요구를 얼마나 충족했는지로 평가할 필요가 있다. 나아가 이러한 도입이 L1 이용과 ETH의 경제적인 수요로 이어지는지도 살펴야 하는데, 기술의 확산만으로 네트워크와 자산의 성장까지 보장되지는 않기 때문이다.
이러한 분업이 실제로 작동하려면 현장의 자료가 개발 논의에 들어가는, 보다 통합적인 절차가 필요하다. 예컨대 재단은 발행량 같은 주요 제안에 대해 연구자와 개발자, 그리고 각종 사업 운영자들이 함께 검토하는 자리를 지원할 수 있다. 연구자는 예상 효과와 가정을, 운영자는 규모별 비용과 손익을 제시하고, 이를 바탕으로 어떤 조건에서 운영자 이탈이 발생할지 점검해 EIP와 코어 개발자 논의에 반영하는 방식이다. 기관 도입에서도 지원 조직이 사례와 요구사항을 정리하고, 개발팀이 해결 가능한 범위와 후속 담당자를 명시하면 의견 수렴을 실행으로 연결할 수 있다.
이 과정에서 모든 요구를 수용할 필요는 없지만, 무엇을 반영하거나 거절했고 그 이유가 무엇인지는 공개해야 한다. 그래야 연구자는 자신의 설계가 실제로 다양한 참여자를 남기는지 검증받고, 사업자 역시 도입 과정의 어려움과 성과를 구체적인 근거로 설명할 수 있다. 이상을 지킨다는 이유로 현장의 어려움을 외면하거나, 채택을 늘린다는 이유로 거래량을 곧 성공으로 간주해서는 서로를 설득하기 어렵다. 어떤 원칙을 양보할지에 앞서, 그 원칙을 현실에서 작동시키기 위해 각자가 무엇을 바꿔야 하는지부터 논의해야 한다.
본 보고서의 작성자는 본 보고서에서 언급된 자산 또는 토큰에 대해 개인적인 보유 또는 재산적 이해관계를 가질 수 있습니다. 다만, 연구 수행 또는 작성 과정에서 취득한 미공개중요정보를 이용하여 어떠한 거래도 수행하지 않았음을 밝힙니다. 본 보고서는 일반적인 정보 제공을 목적으로 작성되었으며, 법률, 사업, 투자 또는 세무 자문을 제공하지 않습니다. 본 보고서를 기반으로 투자 결정을 내리거나 이를 회계, 법률, 세무 관련 지침으로 사용해서는 안됩니다. 특정 자산이나 증권에 대한 언급은 정보 제공의 목적이며, 투자 권유 또는 종목에 대한 추천이 아님을 밝힙니다. 본 보고서에 표현된 의견은 저자의 개인적인 의견이며, 관련된 기관, 조직 또는 개인의 견해를 반영하지 않을 수 있습니다. 본 보고서에 반영된 의견은 사전고지 없이 변경될 수 있습니다. 또한, 각 보고서에 포함된 개별 공시 외에도 당사 포필러스는 본 보고서에서 언급된 일부 자산 또는 프로토콜에 대해 기존 투자나 향후 투자 계획을 보유하고 있을 수 있습니다. 아울러, 당사 계열사인 FP Validated는 본 보고서에서 언급된 프로젝트의 노드로 이미 참여 중이거나, 향후 참여할 예정일 수 있습니다. FP Validated의 네트워크 참여 관련 공시와 투명성 고지는 하단에 있는 링크에서 확인하실 수 있습니다.
