Monthly EIP(Sep., 2023): 당분간 Core EIP를 지켜보자

이더리움은 스마트 컨트랙트의 개념을 기존의 블록체인에 접목시켜 새로운 지평을 열었고, EIP를 통해 그 잠재력을 구체화해나가고 있다. 덕분에, 우리는 현재 블록체인을 통해 다양한 비즈니스 및 유스케이스들을 꿈꿀 수 있게 되었다. 하지만 다른 시각을 가진 오피니언리더들이 더욱 다양하게 등장하여 EIP의 트렌드를 함께 만들어간다면, 우리가 꿈꾸는 미래도 더욱 풍부해질 수 있을 것이다.

본 아티클은 매월 어떤 EIP들이 새로이 Draft로 채택되는 지 하이레벨로 트렌드를 리뷰한다. 바라건대, 이 아티클이 다양한 빌더/비즈니스 관계자들이 EIP의 역사를 이해하는데에 도움이 되고, 나아가 업계에 다양한 가치를 제안할 수 있는 계기가 되기를 희망한다.

1. Author’s Note

EIP의 범위는 크게 3가지(i.e., Standard Track, Meta, Informational), 혹은 더욱 세분화해서 6가지(i.e., ERC, Networking, Interface, ERC, Meta, Informational)로 분류할 수 있다. 이중에서도, 특히 어플리케이션 단에서 널리 활용될 수 있도록 지원하는 ERC 표준과, 이더리움 네트워크가 본디 설계된 목적대로 구동되는 것에 필요한 Core 표준이 주로 논의되어오고 있다.

상대적으로 블록체인이 대중들로부터 많은 관심을 받은 2018년과 2022년, 그리고 현재 2023년에는 ERC 표준이 제안되는 비율이 가장 높아왔다. 하지만 곧 살펴볼 것이지만, 지난 9월은 이러한 흐름과 달리 ERC보다 Core에 대한 논의가 더욱 활발해지기 시작하였다.

그렇다고 이것이 ERC의 논의가 갑자기 적어졌다는 것을 의미하는 것은 아니다 - 제안된 ERC의 개수는 오히려 2023년 기준 평균치를 상회한다. 더욱이 계정 추상화, 토큰 바운드 계정 등 실질적으로 최종 사용자들이 웹3 어플리케이션을 채택함에 있어서 사용성을 크게 완화할 수 있는 미들웨어적인 표준들이 등장하기 시작하면서, 컨트랙트 및 상호작용과 관련된 표준들이 대거 Final 단계를 향해 진전하고 있다.

Core 표준들이 새롭게 많이 채택된데는 이더리움 네트워크에 곧 있을 Dencun 업데이트를 앞두고 개발자들 간에 Core와 관련한 논의가 많이 이뤄진 탓일 수도 있을 것이다. 이에, Dencun 업데이트가 더욱 코앞에 다가오는 10월의 EIP 트렌드 역시, 9월과 크게 다르지 않을 것으로 예상한다. 따라서 ERC를 관찰하며 새로운 비즈니스 기회를 포착하는 것도 좋지만, 이번에는 Core 표준들에도 조금 더 관심을 기울이며 이더리움 네트워크가 어떤 구조로 변해가고 있는 지를 생생히 관찰하는 것도 좋은 경험일 것이다.

2. Newly Drafted EIPs

9월 한달 간 새로이 Draft로 채택된 EIP의 수는 총 23개로, 전월대비 14개(155%p)가 증가하였다. 이는 2023년 전체로 보아서도 가장 많은 EIP가 Draft로 채택된 것이다 - 이로써 9월 30일까지 제안된 EIP의 수는 총 687개를 기록하고 있다. 또한 특이한 점은 1월부터 새로운 EIP Draft들은 ERC와 관련된 것들이 지배적이었는데, 지난 9월은 Core(i.e., 실행 & 합의 레이어)와 관련된 EIP가 많이 포함되었다는 것이다.

아래는 새로이 Draft로 채택된 EIP들을 더욱 세부적으로 분류해보고, 특별히 주요깊게 살펴볼만한 EIP들 및 그외(i.e., Others)를 나열하였다.

2.1 Execution & Consensus Layer

2.1.1 EIP-6800: Ethereum state using a unified verkle tree

EIP-6800은 향후 로드맵 상에서 이더리움의 확장성과 지속가능성을 위해 필요한 요소들 중 ‘Statelessness’를 달성하기 위한 조건으로 새로운 Verkle State Tree의 도입을 제안하는 내용을 포함한다 - Statelessness를 달성하기 위해서는 1) 블록 제안자만 State 저장이 필요하고 검증 노드들은 State를 저장할 필요 없이 검증할 수 있도록 하는 ‘Weak Statelessness’, 그리고 2) 이더리움 풀노드가 유지하는 State Trie를 일정 주기마다 지우는 아이디어를 포함하는 ‘State Expiry’ 가 있다.

여기서, 특정 값이 특정 위치에 포함 여부를 알려줌으로써 검증 노드들이 State Trie를 가지고 있을 필요성을 제거하는 핵심적인 요소가 ‘Witness’ 라는 증명이다. 블록 제안자는 블록을 생성할 때마다 이 Witness를 함께 제출한다. 하지만 현재의 Hexary Patricia Tree 구조 상에서는 생성될 Witness의 크기가 Tree의 깊이와 너비에 비례하기 때문에, 이더리움 네트워크의 통신이 완전히 일정하고 지속가능한 형태로 구성되기 위해서는 witness 증명의 크기를 일정한 수준에 가깝게 만들어야 할 구조적 필요성이 논의되었다 - 해시 함수 대신 ‘Vector Commitment’을 사용하는 버클 트리의 채택은 이러한 맥락에서 긍정적으로 논의되어왔다.

Source : Verkle Tree

기존의 Hexary Patricia Tree는 존재하지만 동결된 상태이며, 새로이 도입되는 Verkle Tree는 빈 상태로 시작하고 액세스된 상태의 복사본이 트리에 저장된다.

2.1.2 EIP-7514 Add Max Epoch Churn Limit

현재 이더리움은 대기열 시스템 내 ‘Epoch Churn Limit(에포크 당 이탈 한도)’ 이라고 하는 매개변수를 설정함으로써 검증인의 활성화(activation) 및 종료(exit)를 동적으로 제어하며 네트워크의 안정성을 유지한다 - 예를 들어, 에포크 당 이탈 한도를 8로 설정할 경우, 6.4분의 한 에포크 당 최대 8명의 검증인이 새로이 활성화되거나 완전히 종료할 수 있다(i.e., 하루에 약 1800명). 따라서 이 매개변수가 보수적으로 설정될수록 네트워크 안정성의 Dynamics는 줄어든다.

“Epoch Churn Limit = max(n, Active_Validators/65536)"

EIP-7514는 이 매개변수에 상한을 두어, 이더리움 내에 지나친 양의 ETH가 급격히 스테이킹되는 시나리오(i,e., 과도한 검증인의 활성화)을 선형적으로 완화하기 위하여 제안되었다. 과도한 양의 ETH가 스테이킹이 된다면 합의 계층은 가십 메시지 증가, 비콘 상태 크기 증가, 그리고 인센티브 구조의 불균형 등으로 인한 보안 문제 등의 이슈를 야기할 수 있다.

본 표준은 1) 검증인이 활성화되기위한 대기열이 포화 상태인 현 상황에서 네트워크를 안정화하고 2) MEV, 블록보상 및 수수료 소각 매커니즘 등 ETH의 토크노믹스를 포괄적으로 정교화하기 위한 논의에 앞선 일시적인 솔루션임에 그 의의가 있다.

EIP-7514 역시 다음 EIP들과 더불어, 오는 Dencun 업그레이드에 포함될 예정이다 .

• 실행 레이어 EIP(i.e., EIP-1153, EIP-4788, EIP-5656, EIP-6780, EIP-7516)

• 합의 레이어(i.e., EIP-7044, EIP-7045, EIP-7514)

• 공통(i.e., EIP-4844)

2.1.3 EIP-7516: BLOBBASEFEE opcode

EIP-3198이 현재 이더리움 네트워크의 기본 수수료(i.e., BASEFEE, 0x48)를 위한 OPCODE를 제안한 표준이라면, EIP-7516는 이더리움의 롤업들을 위한 새로운 데이터 타입인 Blob의 기본 수수료(i.e., BLOBBASEFEE, 0x4a)를 위한 OPCODE를 제안하는 표준이다.

Source : notes.ethereum.org/@vbuterin

Blob은 이더리움의 확장성 솔루션인 롤업들에게 충분한 데이터 저장 공간을 제공하는 것을 목표로하는 데이터 타입이다 - Blob에 대한 상세한 설명은 EIP-4844를 참조하길 바란다. 기존의 데이터 타입인 콜데이터(Calldata)는 EVM에 접근하여 연산을 필요로하였기 때문에 이더리움 상에 데이터를 게시하는 것이 상대적으로 비쌌던 반면, Blob은 ‘데이터 가용성 샘플링(DAS, Data Availability Sampling)’ 이라고 하는, 단순히 일부 데이터를 샘플링하는 방식을 통해 더 저렴하게 검증될 수 있다.

EIP-3198의 도입 동기와 비슷하게, EIP-7516은 롤업 컨트랙트들이 Blob 데이터 사용 비용을 효율/효과적으로 책정할 수 있게 한다. Blob의 가격은 별도의 수수료 마켓에 의해 결정되며, 실질적으로 최종 사용자는 Blob 데이터를 어느 시점에 가장 효과적으로 활용할 수 있는 지에 대해 판단할 수 있게 된다.

EIP-7516 역시 다음 EIP들과 더불어, 오는 Dencun 업그레이드에 포함될 예정이다 .

• 실행 레이어 EIP(i.e., EIP-1153, EIP-4788, EIP-5656, EIP-6780, EIP-7516)

• 합의 레이어(i.e., EIP-7044, EIP-7045, EIP-7514)

• 공통(i.e., EIP-4844)

2.1.4 Others

• EIP-6690: EVM Modular Arithmetic Extensions (EVMMAX)

• EIP-6873: Preimage retention

• EIP-6916: Automatically Reset Tesnet

• EIP-7441: Upgrade block proposer election to Whisk

• EIP-7480: EOF - Data section access instructions

• EIP-7519: Atomic Storage Operations SCREDIT and SDEBIT

2.2 Transaction

2.2.1 ERC-7522: OIDC ZK Verifier for AA Account

Source : EIP-7522

OpenID Connect(OIDC)는 웹2 온라인 서비스에서 가장 널리 사용되는 인증 프로토콜 중 하나이다. OIDC를 통해 서비스 제공자들(i.e., RP, Relaying Party)은 구글과 같이 신뢰할 수 있는 IDP(Identity Provider)에게 사용자의 인증절차를 위임하고 그들의 데이터를 관리하게 하며, 사용자들은 해당 IDP에 대한 인증정보(i.e., OIDC ID) 하나로 여러 서비스를 간편하게 인증할 수 있다.

ERC-7522의 메인 아이디어는 OIDC에서 발생하는 사용자의 신원 정보가 담긴 액세스 토큰을 ZK Aggregator라고 하는 오프체인 서비스를 통해 영지식 증명으로 감싸고 ERC-4337 기반의 스마트 계정에 연결하는데에 있다.

이를 통해, 스마트 계정을 가진 사용자들은 구글 혹은 페이스북 계정과 같이 친숙한 OIDC ID를 통해서도 다양한 온체인 활동을 할 수 있게 된다. 단, 아직 영지식 증명을 온체인 상에서 검증하는데에는 그 비용이 매우 높기 때문에 현 단계에서 다양하게 활용되기에는 시기상조일 수 있다 - 현 상태에서는 계정 소유자의 키를 복구하는 정도에 활용될 수 있을 것이다.

2.2.2 Others

• EIP-7503: Zero-Knowledge Wormholes

2.3 Contract - Detection / Storage & Proxy Contract

2.3.1 ERC-7512: Onchain Representation for Audits

ERC-7512는 보안을 보장하기 위한 목적으로, 온체인 상에 게시할 수 있는 스마트 컨트랙트의 감사 보고서 양식 표준을 제시한다.

스마트 컨트랙트에 대한 감사는 일반적으로 컨트랙트의 기능이 의도대로 잘 구현이 되는 지, 내부적인 로직이 악의적인 공격에 취약하지 않은 지, 다른 컨트랙트에 의해 호출되거나 발생하는 이벤트 등으로 인한 상호작용이 2차 피해를 일으킬 여지는 없는 지 등 광범위한 조사를 수반한다. 하지만 비싼 비용때문에 각 감사는 잘 안이뤄지고 있으을 뿐만 아니라, 감사의 양식 자체 또한 감사자에 따라 상이하기 때문에 각 감사보고서에 대한 일관된 평가가 어려울 수 있다.

Source : EIPs Github

이에, 본 ERC는 감사 보고서에 대한 표준화된 양식을 도입하여 개별 스마트 컨트랙트가 감사가 진행됐다는 것을 온체인 상에서 표현할 수 있도록 한다. 이는 생태계 전반적으로 감사 혹은 그에 준하는 보안 수준이 확정된 스마트 컨트랙트가 널리 활용될 수 있도록하는 부가적인 이점또한 있을 수 있다.

하지만, 본 ERC가 만연하게 될 시, 스마트 컨트랙트가 활용되기 위해서 비용이 드는 감사를 강제해야한다는 분위기를 조성할 부작용 또한 있을 수 있다. 더욱이, 감사의 온체인 표현 자체가 컨트랙트의 보안을 보장하는 것은 아니며 그것의 구현 역시 복잡할 수 있다 - 업그레이더블 컨트랙트에 한해서는 그 복잡도가 증가할 우려가 충분하다. 레지스트리 컨트랙트 혹은 메타데이터로써 감사보고서의 표현을 대체할 수 있는 여러 대안도 존재하므로, 해당 ERC의 실효성은 재고해볼만하다.

2.3.2 ERC-7406: Multi-Namespace Onchain Registry

ERC-7406은 유연하고 확장가능한 키-값 매핑 구조를 활용하여 보편적으로 활용될 수 있는 다중-네임스페이스 레지스트리 표준을 제안한다.

온체인 레지스트리는 데이터를 안전하게 저장할 뿐만 아니라, 다양한 어플리케이션과 상호작용을 하는데에 있어서 중요한 역할을 한다. 하지만 이 레지스트리가 유연한 구조를 채택하지 않으면 저장되는 데이터값들의 형식은 매우 제한됨에, 다양한 어플리케이션과 폭넓은 상호작용이 어렵다.

ERC-7406 레지스트리를 통해 개발자는 여러 네임스페이스를 정의하여 다양한 종류의 데이터를 입체적으로 관리할 수 있으므로 도메인 관리, 데이터 카탈로깅 등 광범위한 영역에서 데이터들이 관리/활용될 수 있도록 한다.

2.3.3 ERC-7508: Dynamic On-Chain Token Attributes Repository

ERC-7508은 ERC-721 혹은 ERC-1155로 표현되는 NFT의 속성들(attributes)을 온체인 상에 저장하기 위한 레포지토리 표준이다.

그간 많은 경우에서 NFT들의 속성들은 온체인 저장소 대신 중앙화된 오프체인 저장소에 저장되어 URI를 참조하는 방식으로 구현이 되었다 - 이는 NFT 자체가 가지는 의미 및 그것의 활용 잠재력을 상당히 저하시켜왔다. 이 표준을 통해, NFT는 신뢰할 수 있는 온체인 상에 온전히 영구저장될 수 있기 때문에 온체인을 참조하는 것만으로 다양한 서비스 상에서 상호작용될 수 있다. 또한, 특정 온체인 활동에 따라 속성값의 변화를 유연하게 반영할 수 있다는 데도 큰 이점이 있을 수 있다(e.g., 게임 플레이어의 레벨업).

AccessType이라고 하는 변수를 통해 속성값을 관리할 수 있는 주체를 정의할 수 있으며, 이들은 특정 collection 내 tokenID에 대해 String, Uint, Bool, Address, Bytes 형태의 속성을 정의할 수 있다.

2.3.4 Others

• ERC-7085: NFT Relationship Enhancement

• ERC-6734: L2 Token List

• EIP-7523: Empty accounts deprecation

• ERC-7511: Minimal Proxy Contract with PUSH0

2.4 Token Standards

2.4.1 ERC-7507: Multi-User NFT Extension

ERC-7507은 ERC-721의 확장(Extension)으로, NFT의 원소유자(‘owner’)외에 여러 사람들(’user’)이 해당 NFT를 일정 기간(’expires’)동안 일시적으로 사용할 수 있도록 허가하는 표준이다.

NFT로 표현되는 자산의 임대 등의 유스케이스를 위하여 제안된 ERC-7507은 사실 기존의 EIP들 중 ERC-4907을 약간 개선한 버전이다 - ERC-4907은 ERC-7507과 달리, 둘 이상의 ‘user’ 가 개별 NFT를 임대할 수 없음에 그 활용성이 제한되었다. 이에, 구독 서비스와 같이 여러 사용자들이 함께 공유할 수 있는 IP 서비스 등 폭넓은 유스케이스를 지원하기 위해 ERC-7507가 제안되었다 - ‘expires’는 mapping(uint256 => mapping(address => uint64))로 표현되며, ‘setUser’ 메소드를 통해 특정 사용자마다 NFT의 만료 기한을 설정할 수 있다.

2.4.2 Others

• ERC-6604: Abstract Token

• ERC-6864: Upgradable Fungible Token

• ERC-7425: Tokenized Reserve

3. Progression of Existing EIPs

한편, 9월 한달간 23개의 새로이 Draft로 채택된 EIP들을 제외하고, 81개의 EIP의 상태가 변화하였다. 이 중 22개의 EIP들은 최종적으로 채택되기위한 다음 단계(i.e., Final, Last call, Review, Draft 등의 단계)로 격상되었다. 나머지 총 59개의 EIP들은 다음 단계로 가지못하고 Stagnant 단계로 바뀌었다. 최종적으로 Withdrawn으로 바뀐 EIP는 없다.

앞서 살펴본 23개의 새로운 EIP들은 합의 & 실행 레이어와 관련된 코어 EIP들이 많이 포함하는 반면, 기존의 EIP들은 특히 컨트랙트 및 토큰 표준과 관련된 ERC 계열의 EIP들이 상당수 진전을 보였다 - 주로 컨트랙트 간에 상호작용하는 방식 및 NFT의 활용/확장하는 표준들의 진전이 두드러졌다. 이외에도 BLS 서명 및 SNARKs의 검증을 위한 EIP-2539, 그리고 여러 이더리움 지갑 브라우저 확장을 설치할 때 충돌을 방지하기 위한 EIP-6963 표준이 주목할만하다.

3.1 Execution & Consensus Layer

• EIP-4881: Deposit Contract Snapshot Interface

• EIP-2539: BLS12-377 curve operations

3.2 API / RPC / Provider

• EIP-3085: wallet_addEthereumChain RPC Method

• EIP-3091: Block Explorer API Routes

• EIP-6963: Multi Injected Provider Discovery

3.3 Contract - Execution / Scheme

• ERC-223: Token with transaction handling model

• ERC-5247: Smart Contract Executable Proposal Interface

• ERC-5453: Endorsement - Permit for Any Functions

• ERC-5585: ERC-721 NFT Authorization

• ERC-6492: Signature Validation for Predeploy Contracts

• ERC-6617: Bit Based Permission

3.4 Contract - Detection / Storage

• ERC-7053: Interoperable Digital Media Indexing

• ERC-7201: Namespaced Storage Layout

• ERC-7401: Parent-Governed Non-Fungible Tokens Nesting

• ERC-7409: Public Non-Fungible Tokens Emote Repository

3.5 Token Standards

• ERC-5114: Soulbound Badge

• ERC-5725: Transferable Vesting NFT

• ERC-6808: Fungible Key Bound Token

• ERC-6809: Non-Fungible Key Bound Token

• ERC-7160: ERC-721 Multi-Metadata Extension

• ERC-7231: Identity aggregated NFT

3.6 Meta

• EIP-7329: ERC/EIP Repository split

이 글의 비주얼을 제공해주신 Kate에게 감사의 말씀을 전합니다.