FinalステートのERCは、正統性を確立できるのか？

執筆：Zhixiong Pan

最近、ERC-6551に関する議論がますます盛んになっている。「ERC-721に新たなユースケースをもたらす」という話題から、「NFTがERC-6551を利用してバズを生んでいる」、さらには「ERC統合後の実装」まで、さまざまなトピックが注目されている。しかし筆者は、問題の核心はこの標準自体ではなく、むしろ我々が理解すべきは「イーサリアム上におけるERCとは何か？」「ERCはコミュニティにおける正統性の源泉となるのか？」という点にあると考える。

ここではERC-6551の背景について詳しく触れるつもりはない。簡単に言えば、これはNFTが他の資産を保有できるようにする一連のスマートコントラクト標準であり、それによってより多くのユーザー体験が創出される。

豆知識1：ERCはアプリケーション層の標準であり、イーサリアムプロトコルそのものには直接関与しない。

イーサリアム改善提案（EIP）は、EIP-1において明確に三つの大分類に分けられている：標準化EIP、メタEIP、情報提供EIP。

その中で最も一般的なのが標準化EIPであり、これにはコア改善（Core）、ネットワーク層改善（Networking）、インターフェース層改善（Interface）、アプリケーション層標準（ERC）が含まれる。

具体的に言えば、ERC-6551標準は「レジストリ」スマートコントラクトとアカウント実装インターフェース、およびこれら二つの参照実装を定義している。たとえば、ERC-6551が定義するレジストリスマートコントラクトは、アカウント作成とアカウントアドレスの読み取りという2つのインターフェースのみを含んでいればよく、どのように実装するかについてはERC-6551が参照例を提示している。

例えば、イーサリアムで最も広く使われているトークン標準であるERC-20は、いくつかの基本的なインターフェースを定義しており、開発者は自身のニーズに応じて機能を実装することも、あるいはOpenZeppelinのオープンソース標準コントラクトをそのまま利用することもできる。

豆知識2：個々のEIPやERC提案には規定された表記法がある（EIP-1文書を参照）。ERC XXXやERCXXXではなく、正しくはERC-XXXと表記する。ERC以外のEIPについても同様に、EIP-XXXと表記する。

たとえばERC-20、ERC-6551、EIP-3540など。

ERC-6551はスマートコントラクトによって実現可能な標準であるため、この標準が登場する前でも、開発者は同様の機能を独自に実装できた。しかし、この標準があることで、ウォレットや取引マーケットプレイスなどがどうサポートするかといった、より大きなエコシステムの構築が可能になる。

もしERC-4337がなければ、各ウォレットが独自にアカウント抽象のスマートコントラクトを実装することは不可能ではないが、他ウォレットや他アプリケーションとの間での相互運用性（コンポーザビリティ）は失われる。ERC-20がなければ、各開発者が独自にトークン発行を実装することもできるが、その場合ウォレット側は個々のトークンを一つずつ対応しなければならず、不要な開発負荷が生じる。

しかし、だからといって「ERC標準になること」が業界標準になる唯一の道というわけではない。「最終状態（Final）のERC」よりも、「社会的コンセンサス」や「事実上の標準（デファクトスタンダード）」の方がはるかに重要なのである。

一部の人々は、業界標準になるにはイーサリアム財団やEIP編集チームによる審査を経て「Final」状態に変更されなければならないと考えるかもしれない。しかし実際には、すでに「業界標準」として認められているものでもほとんど注目されていないものもあり、逆に標準化されていない「実践」が社会的コンセンサスを徐々に形成することで、事実上の標準となるケースもある。

たとえばNFTはまさにその好例である。まずアプリケーションがあり、その後にERC標準が登場した。ERC-721は2018年1月に提出され、同年6月にようやく「Final」状態になったが、CryptoKittiesというゲームは2017年末ですでにリリースされており、これが事実上最初のERC-721対応アプリとして広く認識されている。

したがって、正しい理解は「ERC-721が標準になったから生態系と正統性が生まれた」ではなく、「非代替性トークンのニーズがあり、CryptoKittiesがそれを解決し、ERC-721という標準がそのニーズに対応できたため、コミュニティが採用し始めた」というべきだ。これが、後にERC-1155のようなさらに多様なニーズに対応する新たな非代替性トークン標準が登場した理由でもある。

まとめると、以下の2つの可能性はいずれも存在しうるが、後者の方が現実に近い：

1. 標準策定 → エコシステム

2. ニーズあり → 解決策の提示 → 標準策定 → エコシステム

どちらのパターンであれ、本質はユーザーのニーズを解決し、その解決策が広く受け入れられ利用されることにある。これが新しい標準を導入する真の目的なのである。