목차
- 1. 저자의 코멘트
- 2. 새로이 제안된 EIP들
- 2.1 Execution & Consensus Layer
- 2.2 URI / URL
- 2.3 Library / Packaging / Module
- 2.4 Storage / Registry
- 2.5 Token Standards / Extensions
- 3. 기존 EIP들의 진전
- 3.1 Transaction
- 3.2 On-Chain & Off-Chain Data Retrieval / Indexing
- 3.3 Contract - Execution / Scheme
- 3.4 Storage / Repository
- 3.5 Account / Meta Transaction / Wallet
- 3.6 Token Standards & Extensions
- 4. “생각해보기” - ERC-4337가 AA로써 최선인가?
관련 프로젝트
이더리움은 스마트 컨트랙트의 개념을 기존의 블록체인에 접목시켜 새로운 지평을 열었고, EIP를 통해 그 잠재력을 구체화해나가고 있다. 덕분에, 우리는 현재 블록체인을 통해 다양한 비즈니스 및 유스케이스들을 꿈꿀 수 있게 되었다. 하지만 다른 시각을 가진 오피니언리더들이 더욱 다양하게 등장하여 EIP의 트렌드를 함께 만들어간다면, 우리가 꿈꾸는 미래도 더욱 풍부해질 수 있을 것이다.
본 아티클은 매월 어떤 EIP들이 새로이 Draft로 채택되는 지 하이레벨로 트렌드를 리뷰한다. 바라건대, 이 아티클이 다양한 빌더/비즈니스 관계자들이 EIP의 역사를 이해하는데에 도움이 되고, 나아가 업계에 다양한 가치를 제안할 수 있는 계기가 되기를 희망한다.
1. 저자의 코멘트
지난 아티클에서 보았듯, 9월은 특히 Dencun 업데이트와 관련하여서 많은 Core EIP들이 제안되는 달이었다. 이에, 10월 한달 간은 Dencun 업데이트를 위해 추가적으로 EIP들이 제안된다기보다는 기제안된 EIP들을 테스트해보고 검증해보는 한달이었다 - 특히 Epoch Churn Limit(에포크 당 이탈 한도)의 조정이 성공적으로 테스트되었으며 이외에도 사소한 버그들이 수정되었다. 하지만 개발 일정상 여러 번의 테스트넷이 필요하다고 논의되었기 때문에 메인넷에 실질적으로 Dencun 업데이트가 통합되는 데에는 예정보다 더 오랜 기일이 걸리므로 내년 초로 미뤄질 가능성이 농후할 것으로 보인다.
이외에도, 주요한 논의 사항은 EIP Repository 내에서 ERC와 EIP가 마침내 각각 분리된다는 것이 있다. 사실 이에대한 논의는 과거 EIP의 규모가 점점 커지기 시작한 때부터 있어왔지만 구체적으로 실행하는데에 있어서 종종 논의가 중단되어왔다. 이더리움 네트워크가 미니멀리즘과 견고함을 달성해나가는 비전을 가지고 있기에 주로 Core와 관련된 EIP들은 소수의 인원들 중심으로 논의가 심화되고있는 반면에, 더욱 다양한 유스케이스를 위한 ERC는 점점 다양한 사람들에 의해 제안되고있으므로 해당 Repository의 분리로 인해 이제 EIP 및 ERC는 조금 더 생산적이고 효율적인 방식으로 논의가 진행될 것으로 예상된다.
한편 EIP 의 경우, 매우 다양한 영역의 표준들이 골고루 제안되거나 다음 단계로의 진전을 보였는데 특히 Transaction과 관련된 표준 혹은 ERC-4337과 연관이 있는 표준들이 논의되는 빈도수가 점점 증가하고 있다는 것이 괄목하다.
2. 새로이 제안된 EIP들
10월 한달 간 새로이 Draft로 채택된 EIP의 수는 총 11개로, 전월대비 12개가 감소하였다 - 이로써 10월 31일까지 제안된 EIP의 수는 총 698개를 기록하고 있다. 유난히 Core EIP가 많이 제안된 9월과 달리, 10월의 EIP는 다른 달들과 마찬가지로 ERC가 지배적이었다.
아래는 새로이 Draft로 채택된 EIP들을 더욱 세부적으로 분류해보고, 특별히 주요깊게 살펴볼만한 EIP들 및 그외(i.e., Others)를 나열하였다.
2.1 Execution & Consensus Layer
2.1.1 EIP-7251: Increase the MAX_EFFECTIVE_BALANCE
지난날동안 이더리움은 검증인당 이더리움의 예치금액이 32 ETH로 고정되어왔다. 이로 인해 지적할 수 있는 문제점은 크게 두 가지로 정의할 수 있다 - 1) 대규모의 이더리움을 예치하고싶은 주체는 검증인을 여러 개로 나누어 운영해야하므로, 네트워크에는 검증인의 수가 과도하게 증가한다. 2) 각 검증인들이 보상을 얻을 때 32 ETH가 넘어가는 물량들은 리스테이킹이 되지 않으므로 복리효과를 누릴 수 없다.
Source : https://beaconscan.com/stat/validator
실제로, 이더리움의 검증인 수는 그간 가파르게 증가하여 현재(10월 31일 기준) 약 100만명에 육박한다. 이러한 트렌드가 지속될 경우 검증인간 통신해야하는 P2P 메시지 수, 각 에포크마다 집계해야 하는 BLS 서명 수, BeaconState 메모리 풋프린트 등이 비약적으로 늘어 노드의 연산에 부하가 생길 수 있다 - 물론 이에 대해서는 지난 9월 포스팅에서 언급한 EIP-7514처럼 Epoch Churn Limit을 보수적으로 설정하는 방법도 있지만 이는 임시방편 솔루션임에, 더욱 근본적으로는 네트워크 내 검증인 수를 줄이는 방법이 현실적일 것이다.
“MIN_ACTIVATION_BALANCE → 32 ETH” & ”MAX_EFFECTIVE_BALANCE → 2048 ETH”
EIP-7251는 검증인들에게 요구되는 이더리움의 최소 예치량은 그대로 두되(i.e., 32 ETH) 상한선을 2048 ETH까지로 늘려 대규모 예치자들의 검증인 수를 낮추고 이를 통해 위와 같은 통신 부하 현상들을 완화하는 데에 메인 아이디어가 있다. 또한 이러한 조치는 검증인들이 유연한 양의 이더리움을 예치가능하게하기 때문에 스테이킹의 복리효과 역시 누릴 수 있도록 한다.
이처럼 해당 EIP는 분명히 많은 이점을 가져다 줌으로 그것의 도입이 매우 낙관적이다. 다만, 이더리움 노드가 합의하는 데에 필요한 위원회의 구성 역학 및 Epoch Churn Limit 의 재정의 등 여러가지 주요 사안들에 대한 수정을 요할수도 있을만큼 파급력이 클 수 있기 때문에 실제로 채택이 되는데까지는 신중히 논의돼야할 것이다.
2.1.2 EIP-7542: eth/69 - available-blocks-extended protocol
이더리움에서 새로운 노드가 네트워크에 진입하여 P2P 네트워크를 구축하고 다른 노드와 상호작용을 하기 위해서는 DevP2P라고 하는 프로토콜을 따르게 된다. 이 DevP2P 프로토콜에는 여러 가지 하위 프로토콜들이 있는데 해당 프로토콜들은 handshaking 과정을 통해 노드를 연결하고 트랜잭션을 교환하는 등의 통신 과정 일체를 포함한다.
EIP-7542는 이더리움 노드가 serve할 수 있는 범위에 대한 정보를 포함하여 peer node와 handshaking할 수 있도록 기존의 하위 프로토콜(i.e., wire protocol)을 확장시킴으로써 노드들이 저마다 필요한 데이터를 기반으로 선호하는 peer 노드와 연결되어 효율적인 동기화를 달성하도록 하는데에 목적이 있다.
하지만 이러한 방식의 문제점은, 노드들이 저마다 필요한 블록 범위를 가진 peer 노드와의 통신이 우선시되기 때문에 우선시되지 않는 peer node와의 통신을 끊을 수 있으며 결과적으로 네트워크 전체에 노드 간 통신의 다이나믹스에 불균형을 야기할 수 있다 - 특히 이더리움 네트워크는 비대칭적인 통신을 감수하면서 까지 효율성을 추구하는 네트워크보다는 안정적인 네트워크의 운영을 더욱 중요시하므로, 해당 제안이 실질적으로 finalize 되기까지에는 긴 논의가 필요할 것으로 예상된다.
2.1.3 Others
2.2 URI / URL
2.2.1 ERC-6860: Web3 URL to EVM Call Message Translation
우리는 uniswap과 같은 Dapp에 엑세스하기 위해 https://app.uniswap.org/ 를 브라우저 URL에 입력한다. 하지만 web3://uniswap.eth 으로 접속하면 어떨까? 현재 우리가 받아보고있는 대부분의 웹3 서비스들의 데이터는 각각의 자체적인 웹사이트 혹은 etherscan과 같은 node provider 서비스들에 의해서 주로 읽혀지고 있다. 다시 말해서, 아무리 탈중앙화된 어플리케이션을 구현했다한들 사용자들이 이러한 어플리케이션에 접근하기 위해서는 (검열가능성이 있는) http:// 와 같은 중앙화된 서버 혹은 프로토콜을 거쳐야만 하는 것이다.
이에, ERC-6860은 EVM에 대한 쿼리를 직접 실행할 수 있도록하여 사용자들이 중앙화된 서버 등을 통하지 않고 웹3 서비스들에 직접 액세스할 수 있도록 아이디어를 제안하며, 모든 서비스들이 보여지는 방식까지 검열 저항성을 가질 수 있도록 한다. OSI 7계층으로 따지자면 ERC-6860은 presentation layer에 해당하는데 - 사용자들은 해당 표준을 통해 사람이 읽을 수 있는 URL을 사용하여 모든 웹 콘텐츠(HTML/CSS/JPG/PNG/SVG 등 포함)를 온체인으로 렌더링할 수 있다.
Source : Twitter
이 표준은 기존 웹2 방식(i.e., HTTP-URL) 과도 호환이 됨에, 만약 Chrome Browser과 같은 기존의 브라우저 서비스들이 해당 표준을 채택할 경우, 웹3에 친숙하지 않은 사용자들도 단순히 url이 변경되는 것만으로도 탈중앙화된 방식으로 인터넷을 이용할 수 있게 되는 것이다.
2.3 Library / Packaging / Module
2.3.1 ERC-7521: General Intents for Smart Contract Wallets
대중들의 관심이 증가하고 채택에 대한 논의가 가속화되면서 업계 내외에서는 블록체인의 실질적인 유스케이스 혹은 UX에 대한 논의가 대두되기 시작하였다. 이에, 사용자들이 어플리케이션을 사용함에 있어 프로토콜 인프라의 세부사항을 이해해야하거나 관련된 부가적인 과정을 거쳐야하는 불편함을 제거하고 사용 경험을 대폭 개선할 수 있는 표준들이 상당히 많이 주목받고 있는 요즘이다 - 그리고, 이제는 우리에게 친숙한 (ERC-4337에 기반한) 계정 추상화가 이에 대한 대표적인 예시일 것이다.
한편, 계정 추상화 이외에도 사용자들로하여금 특별한 상호작용 경험을 선사할 수 있음에 최근들어 많은 주목을 받기 시작한 또 다른 개념이 있으니, 바로 ‘인텐트(Intent)’이다. 사용자가 원하는 결과(i.e., desired output, or end state)를 표현한 ‘인텐트’를 제출하면 Solver라고 하는 주체들은 ‘어떤 방식으로든’ 일련의 트랜잭션을 엮어 각 사용자에게 원하는 결과들을 가져다준다.
“네트워크에서 요구하는 가스비가 특정 한계치 미만일 때 Uniswap에서 USDC를 ETH로 스왑하고 싶습니다.”
하지만 이처럼 마법 주문 같이도 느껴지는 인텐트는 아직까지 그 구현과정이 구체화 되지 않은 부분이 많기에, 잠재적으로 인텐트를 활용하려는 이용자나 서비스들, 혹은 실질적으로 이들의 인텐트를 ‘풀어줄(solve)’ 주체들(i.e., Solver)이 공유할 수 있는 최소한의 프레임워크가 필요하였다 - 이것이 Essential 에 의해 ERC-7521 이 제안된 배경이다.
Source : xpara’s Twitter
기본적으로 ERC-7521의 작동방식은 ERC-4337의 작동방식과 매우 유사하다. 인텐트들은 UserIntents Mempool 라고 하는 별도의 mempool에 한데 모이게 되는데 Solver들은 각 인텐트를 해결하기 위해 각종 트랜잭션들을 엮는다 - 이 과정에서 엮이는 트랜잭션들은 Solver가 자율적으로 발생시킬 수도, 기존의 트랜잭션들을 활용할 수도, 오프체인의 소스를 활용하거나 심지어 다른 사용자의 인텐트의 일부분을 엮어서 구성할 수도 있다. 사용자는 어떤 IntentStandard를 통해 자신의 인텐트를 실행할 지 서명하게 되고, 서명된 IntentStandard는 EntryPoint라고 하는 컨트랙트에서 그 유효성이 검사된 뒤 내재한 로직이 실행된다.
결과에 초점을 맞춤으로써 과정을 더욱 추상화하는 인텐트의 개념은 어쩌면 우리가 날 것이라고 느꼈던 블록체인의 기본 상호작용 단위(i.e., 트랜잭션)가 사람이 쉽게 이해할 수 있는 우아한 형태로 표현될 수 있다는 점에서 블록체인 UX가 혁신될 수 있는 가능성을 제시한다. 그리고 ERC-7521은 이 가능성이 점점 더 구체화될 수 있도록 최소한의 프레임워크를 제시하는 데에 의의가 있다. 해당 프레임워크를 기반으로, 앞으로 더욱 구체화되어야 할 표준들(e.g., 기술적 구현, 소수 solver의 독점 문제 해결 등)까지 활발히 논의되어 빠른 시일 내에 인텐트의 유스케이스를 관찰할 수 있기를 기대해본다.
2.4 Storage / Registry
2.4.1 ERC-7484: Registries and Adapters for Smart Accounts
ERC-4337 기반의 계정 추상화는, 특정 기능이 정의된 다양한 모듈들을 계정에 활용할 수 있게 함으로써 스마트 컨트랙트 계정이라는 개념을 또 다르게 정의하였다. 그리고 이에 대한 관심이 증가하면서, 각종 서비스들은 저마다의 요구에 맞는 모듈들을 개발하기 시작하였다.
하지만 다양한 모듈들이 널리 퍼지다보니, 해당 모듈을 활용하고자하는 어플리케이션 혹은 사용자들은 어떠한 모듈을 사용해야하는 지, 그리고 해당 모듈들은 정말로 안전한 지 등에 대해 파악하기 힘들었다. 이러한 문제점들을 해결하기 위해 ERC-7484는 보안적으로 사용에 적합하다는 증명(attestation)과 함께 해당 모듈들이 쉽게 탐색될 수 있도록 모아둔 ‘(Singleton) Module Registry’ 의 인터페이스를 제안한다.
인터페이스만을 제안하기 때문에 구현 부분은 아직 많이 구체화되어 있지 않다 - 해당 Registry는 증명의 저장과 함께 증명의 생성자가 attester와 일치하는 지에 대한 검증, attester가 해당 증명을 revoke할 수 있도록 하는 기능, 그리고 ‘check’ 혹은 ‘checkN’ 이라고 하는 메소드를 구현해야한다. 여기서 check(checkN) 메소드는 특정 모듈에 대한 필요한 수의 증명이 부재할 시 revert되는 로직을 담은 간단한 메소드이다. Registry에 등록된 모듈들은 각각 Adapter에 의해 쿼리되어 설치되고, 실행된다.
Source : Rhinestone’s Blog
해당 ERC는 스마트 계정들의 기능 정의에 필요한 모듈들이 조금 더 안전하고 효율적인 방식으로 유통되게함으로, 스마트 컨트랙트 계정이 더욱 보편화되고 발전하는데에 상당한 기여가 될 수 있을 것이라 판단된다.
2.5 Token Standards / Extensions
2.5.1 ERC-7417: Token Converter
ERC-20 기반의 토큰이 ‘transfer’ 메소드를 통해 EOA가 아닌, 스마트 컨트랙트로 이동되었을 때 스마트 컨트랙트에서 상의 해당 토큰은 영원히 잠기며 되찾을 수 없게 된다. 그리고 이에 대한 한계점을 극복하기 위해 ERC-223 이 제안된 바가 있다 - ERC-223의 메인 아이디어는 대부분의 ERC-20 의 기능들에 ‘tokenReceived’ 라는 새로운 메소드를 추가하여 컨트랙트들에게 이를 강제로 구현하게 하는 데에 있다. 만일 토큰이 스마트 컨트랙트 상으로 transfer 되었는데 ‘tokenReceived’ 가 구현되어있는 경우 sender가 해당 토큰을 컨트랙트에 deposit 하는 것으로 인식하여 ‘transfer’ 만으로도 (ERC-20의) ‘approve + transferFrom’ 로직을 처리토록한다. 만일 컨트랙트에 ‘tokenReceived’ 메소드가 구현되지 않은 경우, 해당 트랜잭션은 유효하지 않다고 판단하여 revert된다. 즉, ERC-223은 기존의 ERC-20보다 더 가스효율적인 솔루션인 동시에, 오송금의 사례를 방지할 수 있는 표준인 셈이다.
하지만 이미 고유한 주소를 가지고 있는 ERC-20 토큰들이 ERC-223 으로 새로이 업그레이드를 한다면 새로운 주소를 가질 것이고, 이러한 변화로 인해 잠재적으로 많은 위험이 따를 수 있다. ERC-7417은 기존의 ERC-20 기반의 토큰들이 ERC-223 기반의 표준으로 자유롭게 업그레이드 (혹은 반대로 ERC-223 기반의 토큰들이 ERC-20으로 다운그레이드) 되도록 ‘Token Converter Contract’를 제안하는 데에 목적이 있다.
ERC-7417에는 두 가지 메인 컨트랙트가 있다 - Converter Contract와 ERC-223 Wrapper Contract이다.
Converter Contract의 ‘createERC223Wrapper’ 메소드는 각 ERC-20 토큰의 주소를 ERC-223 Wrapper와 1:1로 매칭시켜 생성하는 역할을 하고, ‘converERC20toERC223’ 메소드는 sender에 의해 전송된 특정량의 ERC-20 토큰을 해당 계약에 잠그고 해당 토큰에 대응하는 ERC223Wrapper 토큰을 sender에게 다시 보내는 역할을 한다. 만약 해당 Wrapper 토큰을 다시 ERC-20 토큰으로 변환하고 싶다면, ERC-223의 transfer 메소드를 통해 해당 토큰을 Converter Contract에 보내면 된다 - ERC-223의 transfer 메소드는 ERC-20의 ‘approve + transferFrom’ 로직을 처리할 수 있다.
ERC-7417을 채택하는 서비스들을 통해, 사용자들은 기존의 ERC-20기반의 자산들을 더욱 안정적이고 효율적으로 다룰 수 있을 것이다.
2.5.2 Others
3. 기존 EIP들의 진전
한편, 10월 한달간 11개의 새로이 Draft로 채택된 EIP들을 제외하고, 19개의 EIP의 상태가 변화하였다. 이 중 14개의 EIP들은 최종적으로 채택되기위한 다음 단계(i.e., Final, Last call, Review, Draft 등의 단계)로 격상되었다. 나머지 총 5개의 EIP의 경우, 다음 단계로 가지못하고 Stagnant 단계로 바뀌었다. 최종적으로 Withdrawn으로 바뀐 EIP는 없다.
또한 ERC들이 주로 진전이 있었던 지난달과 달리, 이번 달에 진전이 있었던 EIP 들은 모두 합의 & 실행 레이어, URI & URL, Module, Registry, Wallet, 그리고 Token Standards 등 다양한 범위에 걸쳐있다.
이들 중 주목할만한 것들을 일부 꼽아보자면 - EVM기반의 블록체인들이 각자 구현하고 있는 크로스체인 인터페이스를 통합하기 위한 표준인 ERC-5164, 스텔스 주소(stealth address)를 생성함으로써 수신자가 비공개로 특정 자산을 받을 수 있도록 하여 프라이버시 기능을 크게 향상시키는 ERC-5564, Dapp 혹은 사용자들이 여러 browser extension wallet들 중 선호하는 것을 선택할 수 있도록 UX를 개선하여 지갑 서비스들 간의 공존 및 공평한 경쟁을 지원하는 EIP-6963(참조 - Twitter Thread), 그리고 "번 앤 리민트(Burn and Re-mint)" 매커니즘을 ZKP와 함께 활용하는 새로운 접근 방식을 취함으로써 이더리움 네트워크 내에서 프라이빗 전송을 가능케하는 EIP-7503이 특히 주목할만하다(참조 - Twitter Thread).
3.1 Transaction
3.2 On-Chain & Off-Chain Data Retrieval / Indexing
3.3 Contract - Execution / Scheme
3.4 Storage / Repository
3.5 Account / Meta Transaction / Wallet
3.6 Token Standards & Extensions
4. “생각해보기” - ERC-4337가 AA로써 최선인가?
앞서 잠시 설명하였듯, ERC-4337 기반의 스마트 컨트랙트 계정(SCA, Smart Contract Address)은 계정 추상화의 내러티브를 널리 알리는 계기가 되었다. 더욱이, 이더리움 네트워크의 코어 변경 없이 어플리케이션 단에서 빠르게 배포해볼 수 있는 표준이다보니 근 몇개월 간 Wallet (e.g., Ambire, CyberConnect, Rhinestone, Safe, etc.) 및 Bundler/SDK (e.g., AA-Bundler, Alchemy, Biconomy, Gelato, Stackup Builder, etc.)를 포함하여 상당수의 ERC-4337와 관련된 프로젝트들이 등장하게 되었다.
EIP도 예외는 아니다. 지난 달 컨텐츠에서 살펴보았듯이 OIDC ID를 SCA에 통합하는 ERC-7522, SCA의 특정 기능들을 정의하기 위한 모듈 인터페이스인 ERC-6900, 그리고 이번에 살펴본 Module Registry 인터페이스인 ERC-7484까지 ERC-4337의 영향력은 나날이 확대되고 있다. 사실 AA는 다른 메인넷들에는 이미 예전부터 존재하던 개념임을 감안하면, 어쩌면 블록체인 트렌드는 이더리움 생태계의 변화에 의존도가 매우 크다는 것을 방증하는 사례일 수도 있겠다.
그런데, 우리는 ERC-4337의 영향력이 계속해서 커지는 것이 맞는 지에 대해 한번 되돌아볼 필요가 있다. 이더리움 네트워크 내에서도 AA의 구현에 대해서는 지금까지 오랜 기간동안 많은 방법론들이 논의되어왔는데 ERC-4337가 널리채택된데는 현재의 코어를 수정할 필요가 없다는 점이 가장 크게 작용했기 때문이다. 이를 반대로 말하면, 코어를 수정하며 AA를 구현하는 것(즉, native AA를 구현하는 것)이 장기적으로 네트워크에 더 이점이 있는 지는 따져봐야한다는 의미이다.
ERC-4337은 다음과 같은 한계점이 있을 수 있다.
EntryPoint 역시 하나의 스마트 컨트랙트라 수정이 매우 어렵고, 보안적으로 취약점이 발견될 경우 매우 위험할 수 있다.
Alt Mempool의 지속가능성 혹은 보안성 역시 보장이 될 수 있을 지 불투명하다.
다양한 어플리케이션들이 ERC-4337의 표준에 맞춰야하므로 활용성이나 운용성이 native AA에 비해 상대적으로 부족하다.
일반적인 트랜잭션 처리와 비교하여, 온체인 상에서 추가적인 검증 작업이 이루어지기 때문에 가스비의 운용이 매우 비효율적일 수 있다.
이외 다수.
물론 이것이, ERC-4337을 채택하는 것 대신 합의 계층을 수정하는 ERC-2938이나 ERC-3074 를 대안으로 다시 생각해보자는 의미는 아니다 - 이들 또한 완벽한 솔루션은 아니며 이더리움의 로드맵에 일치하여 생각해보았을 때 ERC-4337 만큼의 유연성을 가지는 지도 확인이 되지 않는다. 비슷한 맥락으로, 비탈릭은 최근 자신의 블로그에서 기논의되었던 AA 관련 EIP들이 프로토콜 미니멀리즘 측면에서 부적합한 이유들을 설명하고 있다.
더욱이, 결과적으로 현재의 ERC-4337 기반의 AA는 블록체인의 기술적 발전과 더불어 실 유스케이스들을 관찰해볼 수 있는 도구로써 매우 훌륭하며, 설령 native AA가 발현된다하더라도 지금과 비교하여 엄청나게 그 유스케이스가 달라지진 않을 것이다. 다만, 가장 널리 채택됨에도 불구하고 수많은 한계가 있는 ERC-20처럼, ERC는 항상 실험적인 표준이기에 완벽하지 않음을 인지해야하며 더 나은 솔루션에 대해서는 항상 논의를 열어둬야함을 강조하고 싶은 것이다.
이 글의 비주얼을 제공해주신 Kate에게 감사의 말씀을 전합니다.
