목차
관련 프로젝트
이더리움은 스마트 컨트랙트의 개념을 기존의 블록체인에 접목시켜 새로운 지평을 열었고, EIP를 통해 그 잠재력을 구체화해나가고 있다. 덕분에, 우리는 현재 블록체인을 통해 다양한 비즈니스 및 유스케이스들을 꿈꿀 수 있게 되었다. 하지만 다른 시각을 가진 오피니언리더들이 더욱 다양하게 등장하여 EIP의 트렌드를 함께 만들어간다면, 우리가 꿈꾸는 미래도 더욱 풍부해질 수 있을 것이다.
본 아티클은 매월 어떤 EIP들이 새로이 Draft로 채택되는 지 하이레벨로 트렌드를 리뷰한다. 바라건대, 이 아티클이 다양한 빌더/비즈니스 관계자들이 EIP의 역사를 이해하는데에 도움이 되고, 나아가 업계에 다양한 가치를 제안할 수 있는 계기가 되기를 희망한다.
1. 저자의 코멘트
11월 역시 지난 10월과 마찬가지로, Cancun / Deneb 업데이트를 위한 논의가 주를 이루었다 - 애초에 계획했던 기본 기능 구현 및 Blob 유스케이스 등을 위한 테스트넷인 데브넷 #11은 성공적으로 마무리 되었고, 11월 30일 개시된 데브넷 #12도 성공적으로 진행중이다. 다만, 현재 일부 Client들이 MEV-Boost와 연계하여 활성화되는 과정이 원활히 진행되고 있지 않아 이에 대한 테스트는 진행되고 있는 중이다. 해당 이슈가 해결이 된다면, 앞으로 1~2주 안에 모든 클라이언트를 대상으로 Goeril 섀도우 포크 환경에서 Cancun / Deneb 업그레이드가 테스트될 것으로 보이며, 나아가서 1월 중순 전후로는 하드 포크를 통한 활성화가 계획될 것으로 보인다.
Cancun / Deneb 업데이트 이후에는 Prague / Electra 업데이트가 시작될 것으로 보인다. 이미 해당 업데이트에 어떠한 스펙을 포함할지에 대한 논의는 본 스레드를 통해 열렸다 - Stateless Network를 위한 버클 트리의 도입, 롤업 및 암호화 사용 사례에서 수요가 많은 BLS12-381 에 대한 사전 컴파일, 스테이킹 제공업체의 조치 없이 사용자가 스스로 종료할 수 있게하여 독립적인 검증인들의 진입장벽을 낮출 것으로 예상되는 EIP-7002의 도입 등이 논의되고 있다.
따라서, 12월과 1월에는 다음 업데이트에 대비한 Core EIP가 상당수 제안되거나 다음 단계로 격상될 것으로 예상된다. 또한 Cancun / Deneb 의 업그레이드에 대한 기대에 부응하여 다양한 유스케이스 혹은 새로운 토큰 표준 및 확장과 관련된 ERC도 더욱 많이 제안될 것으로 기대된다.
2. 새로이 제안된 EIP들
한편, 지난 4월을 제외하고, 11월은 2023년 중 가장 적은 EIP가 제안된 달이었다. 11월 한달 간 새로이 Draft로 채택된 EIP의 수는 총 8개로, 전월대비 3개가 감소하였다 - 이로써 11월 30일까지 제안된 EIP의 수는 총 706개를 기록하고 있다. 제안된 EIP들은 2개를 제외하고 모두 Token Standards / Extensions & Contract Scheme과 관련된 EIP였다.
아래는 새로이 Draft로 채택된 EIP들을 더욱 세부적으로 분류해보고, 특별히 주요깊게 살펴볼만한 EIP들 및 그외(i.e., Others)를 나열하였다.
2.1 Execution & Consensus Layer
2.1.1 EIP-7549: Move committee index outside Attestation
Source : ethos.dev/beacon-chain
이더리움 2.0의 비콘 체인에는 12초마다 생성되는 ‘slot’과, 이 slot이 32개가 모여서 이뤄진 ‘epoch’ 라는 개념이 있다. 비콘 체인은 각 epoch마다 참여하는 검증인들을 32개의 slot에 고르게 나누고 각 slot마다 하나의 블록이 생성되게 한다. 한 slot 당 검증인은 최소 128명은 존재해야하는데, 슬롯에 배정된 검증인들은 RANDAO라고 하는 장치에 의해 블록을 제안하는 제안자가 될 수도, 제안된 블록을 증명하는 위원회(committee)의 구성원이 될 수도 있다. 각 slot 내에서 선정된 단 한명의 블록 제안자는 블록을 위원회에 제안하고, 그것이 나머지 위원회 구성원들로부터 집계된 Attestation 중 2/3 이상에 의해 승인을 받게되면 해당 블록은 생성될 수 있게 된다.
Source : eth2book
위원회 내의 검증인들이 제출하는 AttestationData Class는 위와 같이 구성이되는데 - 검증인에게 할당된 slot, slot 내에서 자신이 속한 위원회의 index, 그리고 검증인의 의견이 반영된 투표 내용 등이 포함되어 있다. 따라서 2^18(=262144)명 이상의 검증인이 있는 한, 한 epoch의 체크포인트가 justified 되기 위해서는 적어도 ceil(3264(2/3)) = 1366 개의 Attestation이 필요한 것이다.
하지만 이 때 각 slot 내에서 모든 위원회 구성원들은 사실상 동일한 정보에 대해서 투표를 하고 있다. 따라서 개별 AttestationData를 위원회 단위로 나누는 대신에 동일한 consensus vote를 한 AttestationData을 집계하여 Attestation을 구성하면 2/3 이상의 승인에 필요한 Attestation의 개수를 크게 줄일 수 있다.
이에 대한 방법론으로, EIP-7549는 AttestationData Class의 index 필드를 밖으로 꺼내어 Attestation Class 내로 이동하는 것을 제안한다. 체크포인트를 justify하는 과정을 효율적으로 만들 수 있다. 따라서 EIP-7549가 도입이 된다면, 이더리움 네트워크 내 Casper FFG 클라이언트들이 더욱 효율적으로 동작할 수 있을 것으로 기대된다.
2.1.2 EIP-7545: Verkle proof verification precompile
지난 게시물에서 설명한 바와 같이, 이더리움이 Statelessness에 진입하기 위한 조건으로써 Verkle Trie의 도입이 요구된다 - 여기서 Verkle Trie는 기존 Hexary Patricia Tree에 비해 증명의 크기를 일정하게 만들 수 있는 구조적인 장점(i.e., vector committment)을 가질 수 있음에, 이더리움 네트워크의 통신이 완전히 일정하고 지속가능한 형태로 구성되게 한다.
Source : Vitalik’s Twitter
하지만 Verkle Trie의 구조 덕분에 증명의 크기를 상수에 가깝게 만들 수 있다하여도 증명들이 검증되는 방식 자체가 쉽지 않다면 어플리케이션 단에서 데이터들을 검증하고 활용하는 작업 또한 매우 어려울 것이다 - 실제로 이더리움의 로드맵 중 The Verge는 현실적으로 가용한 다양한 증명 검증 방식을 점차 업데이트해나가며, 최종적으로는 ‘Fully SNARKed Ethereum’ 의 달성을 통해 블록 검증이 매우 쉬워질 수 있는 것을 목표로 한다. 즉, Verkle Trie가 도입되더라도 초기에는 그다지 고도화된 증명 검증 시스템의 부재로 인하여 데이터들이 비용효율적인 방식으로 조회(retrieve)되지 않을 수 있다.
EIP-7545는 이렇게 Stateless한 이더리움 네트워크를 위해 다양한 증명 검증 방법론들을 실험해나가는 과정 속에서 해당 방법론들을 사전컴파일*하는 컨트랙트의 도입을 제안한다 - 사전컴파일된 컨트랙트는 0x21 주소에 추가되는데 1) 증명 검증 함수에 대한 버전인 ‘version’, 2) 증명 데이터의 시작 부분을 찾는 메모리 주소인 ‘proof_data_location’, 3) 증명 데이터의 길이를 나타내는 ‘proof_data_size’, 4) 그리고 ‘state_root’ 등의 파라미터들을 포함한다.
Source : EIP-7545
해당 EIP가 도입이 된다면, 기존의 어플리케이션들은 새로운 증명 시스템들에 대응하여 자체적으로 컨트랙트를 업그레이드할 필요없이 verkle proof를 효율적으로 검증(verification)할 수 있을 것이다.
*사전컴파일(Pre-Compile)이란, 특정 사용자 정의된 작업에 대한 바이트코드가 유효하고 보안 및 최적화 기준을 충족하는지 등을 미리 확인하여 스마트 컨트랙트 개발자들이 EVM의 기본 내부 코어에 너무 많은 오버헤드를 가하지 않고도도 해당 기능을 활용할 수 있도록 한다.
2.2 Token Standards / Extensions & Contract Scheme
2.2.1 ERC-7496: NFT Dynamic Traits / ERC-7498: NFT Redeemables
대화형(Interactive) 또는 프로그래밍 가능한(Programmable) NFT이라고도 불리는 Dynamic NFT는 기존의 NFT를 뛰어넘는 수준의 상호 작용과 기능을 도입한다는 점에서 주목받아오고 있다 - Dynamic NFT는 미리 프로그래밍된 방식 혹은 사용자가 정의한 특정 컨텍스트에 맞추어 그 속성이 변경되거나 반응하기때문에 현실 자산들의 표현, 게임 내 캐릭터의 속성, 특정 이벤트에 대한 고유한 액세스권, 그리고 다이나믹 콘텐츠 등 매우 폭넓은 분야에서 사용자들에게 향상된 혹은 새로운 사용자 경험을 선사한다.
이러한 Dynamic NFT를 가능케하는 방법들 중 가장 직관적인 방법은, NFT의 속성을 정의하는 메타데이터들이 저장되고 쿼리되는 방식에 변화를 주는 것이다. 현재 NFT의 속성들을 표현하는 상당수의 메타데이터들은 보안, 비용, NFT 컨트랙트 스토리지의 한계 등 다양한 이유로 종종 온체인이 아닌 외부 저장소(i.e., 오프체인)에 저장된다. 즉, 현재 대다수의 NFT들은 구조적으로 자체 속성들을 동적으로 관리하기가 굉장히 복잡하고 비효율적이며, 따라서 온체인 상에서 해당 데이터들이 직접 쿼리되어 외부 컨트랙트와 연계 및 활용되기가 매우 어렵다 - 이에 우리는 Dynamic NFT와 구분하여 대다수의 기존 NFT를 Static NFT라 부르기도 한다.
“function setTrait(uint256 tokenId, bytes32 traitKey, bytes32 newValue) external;"
ERC-7496은 이러한 한계점을 보완하기 위해 기존 ERC-721 혹은 ERC-1155로 표현되는 NFT에 동적인 온체인 속성을 부여하여 그것들의 활용 범위를 확장한다. ‘setTrait’ 라고하는 메소드는 특정 NFT에 ‘traitKey’ 및 ‘newValue’ 라고 하는 key-value 데이터 쌍을 부여함으로써 메타데이터를 정의할 수 있는데, 사용자는 고유한 trait 이름 (혹은 byte32)을 자유롭게 정의할 수 있으며, 아래 4가지 type을 지원한다*.
string - 특성에 대해 문자열 값을 설정
decimal - 특성에 대해 십진수 형식으로 숫자 값을 설정
boolean - 특성에 대해 부울 값을 설정
epochSeconds - Unix Epoch로부터 현재까지의 흐른 시간을 초 단위로 표기한 타임스탬프 설정
*메타데이터에 대한 자세한 스키마 및 세부 파라미터들은 해당 링크를 참조하기 바란다.
Source : ERC-7496
key-value 형식을 통해 메타데이터의 저장 및 표현에 유연성을 더하는 구조는 LUKSO 메인넷이 채택하고 있는 범용 프로필 표준인 ERC-725Y와도 매우 구조가 흡사하다. 이외에도 Dynamic NFT와 관련된 ERC에는 여러 가지가 있는데 - 메타데이터가 업데이트될 시 이벤트를 발송하여 제3자가 후크 등을 활용할 수 있게 하는 ERC-4906, 다양한 종류의 메타데이터 URI를 폭넓고 효율적으로 참조할 수 있는 NFT표준의 확장인 ERC-7160, 그리고 NFT들이 유니코드 기반의 이모지를 활용하여 대화형 유틸리티의 구축을 돕는 ERC-7409 등이 있다.
다양한 타입의 온체인 속성들의 저장만을 위한 repository인 ERC-7508 도 있는데, 해당 표준에 비해 ERC-7496이 가지는 장점은, 1) 확장 표준으로써, 속성을 참조하는 방식 대신 NFT에 곧바로 속성을 부여한다는 점 2) 활용방식이 더욱 간단하고 속성을 정의함에 있어 더욱 유연한 구조를 채택한다는 점이 있다.
한편, ERC-7498는 디지털 서비스 및 경험, 그리고 실제 상품에 대해 상환가능한(reedemable) NFT 확장 표준을 제안한다 - 상환 이벤트의 경우 Campaign이라고 하는 단위에 의해 온체인 상에서 관리가 되며, 상환 시 온체인 NFT가 소각이 되는 구조이다. 다만 이때, ‘trait redemption’ 이라고 하여 NFT가 소각이 되는 대신, 상환을 표시하는 trait를 업데이트하는 방식으로 redeemable NFT를 구현할 수도 있다. 이 때 ERC-7498은 해당 기능을 위해 ERC-7496를 사용한다.
Opensea팀에 의해 제안된 ERC-7496과 ERC-7498은 현재 Seaport Protocol에서 활발히 활용되고 있다.
2.2.2 ERC-7410: ERC-20 Update Allowance By Spender
가장 유명한 토큰 표준 중 하나인 ERC-20의 ‘Allowance’ 메소드는 일반 사용자들이 ‘Spender’ 로 표현되는 제3자로 하여금 특정한 상호작용을 매개하도록 하기 위해 사용자의 지갑에서 얼만큼의 자산에 대한 권한을 Spender에게 부여하는 지를 결정하는 메소드이다 - 이 Spender는 DApp 혹은 DeFi 프로토콜이 될 수도 있으며, 다중 서명 지갑 (Multi-Signature Wallet) 등을 이용하는 경우 서명의 책임이 있는 개별 EOA일 수도 있다.
하지만 이러한 구조는 Spender가 해킹*당하였을 때 사용자의 자금이 탈취당할 위험을 증가시키거나, 사용자가 다중 서명 지갑일 때에 다수의 서명자들이 거래가능한 자산의 양을 유연하게 조정하는데에 있어 구조적인 어려움이 있다 - ERC-7410은 이를 개선하기 위하여 Spender가 주어진 Allowanece을 취소하거나 줄일 수 있도록 ERC-20의 기능을 확장한다.
“function decreaseAllowanceBySpender(address owner, uint256 subtractedValue) external;"
해당 ERC에서 지원하는 메소드는 매우 간단하다 - Spender는 subtractedValue 값을 늘림으로써 현재 주어진 Allownace에서 해당 양만큼의 수치를 제할 수 있다. 즉, 현재 Allowance보다 크거나 같은 값을 subractedValue로 설정한다면, 사실상 Spender의 Allownace는 0이되는 셈이다.
어플리케이션 단에서도 보안적 계층을 강화하기 위한 필요성이 강조되고있고, 트레저리 등의 관리를 위해 다양한 다중 서명 지갑 사례가 생기고 있는 만큼 해당 표준은 기존의 지갑 / 어플리케이션 서비스들 단에서 유의깊게 살펴보면 좋을 것이다.
*Allownace에 대한 리스크는 익히 알려져있는데 - 사용자가 Allownace를 통해 프로덕트 및 프로토콜에게 권한을 부여하는 자산의 양이 무제한이라면 프로토콜/프로덕트는 사실상 사용자의 자금을 마음껏 탈취할 수 있는 포지션에 놓이게 되므로 사용자에게는 프로토콜/프로덕트를 신뢰해야하는 이슈가 생긴다. 따라서 프로젝트 혹은 지갑 단에서 사용자가 허용한 allowance의 value를 사용자들에게 완벽하게 인지시켜주거나 특정 value의 allowance에 대해 서명을 한 프로젝트에 대해서 revoke를 할 수 있도록 하는 서비스들도 생겨나고 있다.
2.3.4 Others
3. 기존 EIP들의 진전
한편, 11월 한달간 8개의 새로이 Draft로 채택된 EIP들을 제외하고, 19개의 EIP의 상태가 변화하였다. 이 중 14개의 EIP들은 최종적으로 채택되기위한 다음 단계(i.e., Final, Last Call, Review, Draft 등의 단계)로 격상되었다. 나머지 총 5개의 EIP들 중 4개는 다음 단계로 가지못하고 Stagnant 단계로 바뀌었다. 최종적으로 Withdrawn으로 바뀐 EIP는 1개이다.
또한 합의 & 실행 레이어, URI & URL, Module, Registry, Wallet, 그리고 Token Standards 등 다양한 범위에 걸쳐 진전이 있었던 지난 달과 달리, 이번 달에 진전이 있었던 EIP 들은 몇몇 Core EIP와 더불어 Token Standards & Extensions가 지배적이었다.
Core EIP들 중 주목할만한 것들은 - 우선 오는 덴쿤(Dencun) 업데이트와 관련하여 실행 레이어에 상위(parent) 비콘 블록 루트를 노출함으로써 오라클 시스템의 필요성을 제거하는 EIP-4788와 롤업 컨트랙트들이 Blob 데이터 사용 비용을 효율/효과적으로 책정할 수 있게 하는 EIP-7516(참조 - 지난 아티클) 가 있다. 이외에 새로운 OPCODEs(i.e., AUTH, AUTHCALL)을 도입하여 호출자로하여금 기존 EOA owner의 권한을 위임하는 형태를 통해 계정 추상화를 달성하는 EIP-3074(참조 - 지난 아티클)도 매우 주목할만하다.
ERC들 중 주목할만한 것들은 - 국가별로 STO 가이드라인이 구체화되어감에 따라 증권형 토큰을 보다 효과적이고 안전하게 관리하기 위해 등장한 토큰 표준인 ERC-3643, 다양한 종류의 메타데이터 URI를 폭넓고 효율적으로 참조할 수 있는 NFT표준의 확장인 ERC-7160, 그리고 NFTFi를 위한 잠금 기능(locking)을 활성화하면서도 NFT 소유자가 NFT의 기능을 온전히 사용할 수 있도록 지원하는 표준인 ERC-7066 등이 있다.
3.1 Execution & Consensus Layer
3.2 Storage / Repository
3.3 Token Standards & Extensions
4. “생각해보기” - 스테이킹 시장의 잠재성
Source : Beaconcha.in
2020년 12월, 비콘체인의 도입 이후로 이더리움의 스테이킹 량은 꾸준히 우상향하여 현재 이더리움 네트워크에는 전체 이더리움 유통량 중 약 24%가 스테이킹되어있다 - 2023년 4월, 상하이 업데이트를 통해 이더리움은 출금이 가능해졌다. 이는 기존에는 검증인을 운영하기 위해 예치만 가능했던 이더리움에 대한 매도 압박을 우려하게 만들었다. 그러나 예상과는 달리, 이더리움의 예치량은 오히려 증가하고 있다.
물론 24%라는 수치는 다른 메인넷의 스테이킹 비율에 비하면 그리 높은 수치는 아니다 (e.g., 솔라나 ~ 약 70% / 코스모스 ~ 약 65% / 폴카닷 & 아발란체 ~ 약 50% / 폴리곤 ~ 약 38%). 하지만 이는 이더리움 네트워크의 분산화 정도를 유지하면서 과도한 검증인들의 확산으로부터 비롯되는 네트워크의 불안정성을 방지하고자 의도적으로 조절되고 있는 수치라고 설명을 하는 것이 더욱 정확할 것이며(참조 - 본 게시물의 EIP-7514 섹션), 현재 이더리움 네트워크 내에서 진행되고 있는 업데이트들도 일련의 EIP들의 도입을 통해 점진적으로 스테이킹된 이더리움의 규모를 향상시키는 것을 목표로하면서도 기존 네트워크의 안정적인 운영을 희생하지 않는 것을 최우선순위로 두고 진행되고 있다.
이에 일치하여, 이더리움 네트워크 외적으로 가장 많이 논의되고 있는 이슈들 또한 이더리움 네트워크의 안정적인 운영을 보조하기위한 논의들이다 - 주요 키워드로는 Lido의 지배적인 스테이킹된 이더리움의 점유율로 인한 리스크 및 안정적인 노드 운영 및 비전문적인 벨리데이터의 진입장벽 감소를 위한 DVT* 기술 등이 있을 것이다.
*DVT란 Distributed Validator Technology의 약자로, 여러 명이 벨리데이터 키를 공유하여 Active – Active 이중화 아키텍처를 구축하는 기술이다. 소수로 구성된 클러스터가 합의 하에 공통된 노드를 운영하기 때문에 다운타임을 대폭 개선하고, 비전문가 벨리데이터 ( e.g., 솔로 벨리데이터 ) 등도 쉽게 참여할 수 있도록 노드 운영의 진입장벽을 낮출 것으로 기대된다.
어쨌거나, 이더리움의 안정적인 네트워크에 대한 수요가 일정할 것이라고 가정을 하고 위와 같은 솔루션들로 인해 이더리움 노드 운영이 더욱 안정적이고 그 진입장벽이 개선이 되어간다면 이더리움의 스테이킹 수요 역시 계속해서 우상향할 것이다. 그렇다면 우리는 스테이킹된 이더리움을 더욱 다방면으로 활용할 수 있는 솔루션들을 눈여겨볼 필요가 있는데, 다양한 리퀴드 스테이킹 솔루션들(e.g., Coinbase Prime, Rocket Pool, Frax Ether, Stakewise, Binance, Stader Labs 등)이 내세우는 저마다의 경쟁요소와 더불어 특히 아이겐 레이어(Eigen Layer)의 활용이 주목할만하다.
아이겐 레이어의 메인 아이디어는 “리스테이킹(Re-Staking)” 이라는 개념이다. 리스테이킹이란, 이미 스테이킹된 ETH를 다른 프로토콜(AVS, Actively Validated Services)의 보안을 강화하기 위해 한번 더 활용할 수 있게 하는 것이다. 즉, 벨리데이터는 아이겐 레이어가 지원하는 프로토콜들에 한해서 이더리움에 대한 검증 보상 뿐만 아니라 AVS의 검증 보상까지 얻을 수 있게 된다 - 물론 이 때, 이더리움 네트워크 내에서의 슬래싱 위험 뿐만 아니라 AVS의 슬래싱 위험까지 이중으로 존재하긴 한다. 구현 방식도 스테이킹된 ETH의 출금 주소를 아이겐레이어의 스마트 컨트랙트에 위임하는 형식으로, 매우 간단하다고 할 수 있다.
프로세스 자체는 스테이킹된 ETH를 유동화하여 다른 프로토콜들과의 상호작용을 할 수 있게 하는 리퀴드 스테이킹 프로토콜들과 흡사하다. 하지만, 아이겐 레이어는 사용자로 하여금 부가적인 효용을 누릴 수 있게 하는 것 뿐만 아니라 블록체인 네트워크에 데이터들이 원활히 흐를 수 있게 하는데에 필수적인 브릿지나 오라클 등과 같은 프로토콜들에도 보안을 강화시킴으로써 생태계 전체가 활성화되는데에 크게 기여할 수 있다고 할 수 있다 - 현재 아이겐레이어는 Altlayer(RaaS), Blockless(Infrastructure Platform), Celo(L2), Espresso(Shared Sequencer Solution), Hyperlane(Interoperability Layer), Mantle(L2), 그리고 Near Protocol(L1) 등 10+가 넘는 파트너십을 진행 (혹은 논의) 중이다.
요컨대, 이더리움의 스테이킹 환경을 개선시켜줄 수 있는 여러가지 논의 및 기술들과 함께, 스테이킹된 이더리움 자체를 매개하여 시행되는 새로운 서비스들을 주목한다면 향후 스테이킹 시장이 어느 정도로 발전해나갈지, 그 속에서 어떤 기회를 모색할 수 있는 지에 대해서도 큰 인사이트를 얻을 수 있을 것이다.
이 글의 비주얼을 제공해주신 Kate에게 감사의 말씀을 전합니다.
