単なる“技術”としてではなく、“人々のコーディネーションをするためのプロトコル”としての役割を志向するEthereum（以下、イーサリアム）。その思想の基盤は、早くも2014年1月23日のビットコインマガジン記事にて提唱者のヴィタリック・ブテリン（Vitalik Buterin）氏から示されており、時を経て”Infinite Garden”というビジョンとなり様々なステークホルダーの羅針盤として機能している。（Infinite Gardenについては2023年4月に東京・虎ノ門で開催された「ETHGlobal Tokyo」での宮口あや氏のスピーチレポートをご参照いただきたい）
グローバル規模で最も活発な開発コミュニティ＆エコシステムの一つとなっている同プロトコルでは日々多様なメンバーが様々な技術課題へと向き合っているわけだが、その中でも特に大きな技術的ブレイクスルーと目されているのが「Account Abstraction」（以下、アカウント抽象化）だろう。公式説明サイトには以下のように記されている。
アカウント抽象化により、クリプトは、小さなミスですべてを失う可能性のある単純な「EOAアカウント」という現在のアプローチから、スマートコントラクトを使用してアカウントをニーズに合わせてカスタマイズできる未来へと移行します。
引用元：What is Account Abstraction?
EOAから任意の検証ロジックを持つ「スマートコントラクトウォレット」への移行は、ウォレットの設計に一連の改善の道を開けるだけでなく、エンドユーザーにとっての使いにくさを軽減することになります。
具体的にどのような取り組みが進んでいるのか。今回は、シンガポールで開催された大型カンファレンス・TOKEN2049のサイドイベントとして2023年9月14日に催された勉強会「Web3 Transition Summit」（LongHash Ventures主催）にて行われたヴィタリック氏による講演 ”Transitioning to account abstraction and L2s: where to from here?” （アカウント抽象化とL2への移行：ここからどこへ向かうのか？）の様子をお伝えする。
アカウント抽象化エコシステムの生命線である「ERC-4337」
「ERC-4337は現在存在するアカウント抽象化エコシステムの生命線です」
このように始めるヴィタリック氏。ERC-4337とは、ヴィタリック氏をはじめ開発コアメンバーらがアカウント抽象化問題に関して7年間の研究の経てアウトプットした技術だ。コアプロトコルに変更を加えることなくアカウント抽象化を導入するもので、端的にお伝えすると、ユーザー自身がアカウントでスマートコントラクトを使えるようになるというものである。
「これまでイーサリアムを追いかけてきた人たちであれば、EIP86とかEIP208、EIP2938を聞いたことがある人もいるでしょう。こうしたEIPはアカウント抽象化に関する特定の技術的課題を解決してきたわけですが、その範囲は少しずつ広がってきました。私にとっての問題意識は、常にセキュリティに関するものだったと言えます。2013年にビットコインマガジンにマルチシグ・ウォレットについての記事を書いて以来、私はずっとマルチシグ・ウォレットを支持してきました」
マルチシグとは、複数の秘密鍵を前提に組まれたトランザクション署名の仕組みのことを指す。このマルチシグ含めた秘密鍵の保管等のあり方・可能性等については、ヴィタリック氏が2022年5月に発表した論文「Decentralized Society: Finding Web3’s Soul」を解説したこちらの記事（Soulbound Tokens(SBT)がいまいち分からない？じゃあVitalik Buterin氏の論文をイチから見ていくとしよう）（第7章）をご覧いただきたい。
「DeFiの世界では、人々に4％のAPR（年換算利回り）ではなく6％のAPRを提供するという問題を真剣に考えすぎて、人々が100％のAPRのマイナスになる可能性を最小限に抑えるという問題をあまり真剣に考えていないように感じます。基本的なセキュリティを向上させ、人々に対してマルチシグ・ウォレットをより簡単に使う方法を提供し、量子耐性への道を開き、Schnorr認証やBLS（ボネ・リン・シャチャム署名）のような、より優れた特性を持つ他の署名アルゴリズムを使う道を開くことは、まさに私にとってのインスピレーションのようなものです。一方で多くの人々は取引手数料をどうこうするということでアカウント抽象化を進めようとしているわけで、そのセキュリティへの無頓着さに苛立つと同時に、プロトコルの拡張を実現することでこれら多くの人々を満足させることができるんだ、なんて素晴らしいんだ！とも思うわけです」
アカウント抽象化によって志向されている様々なゴールの存在
まずはアカウント抽象化の現在地ということで、技術課題の解決によってどのようなゴールが存在するのかの概要マッピング図が示された。ヴィタリック氏によると、先ほどの台詞にある通り、アカウント抽象化のゴールは大きく分けてセキュリティに関するゴールと利便性に関するゴールに分類できるとしている。
セキュリティ関連ゴール
- マルチシグ・ウォレット（Multisig wallets）
- ソーシャルリカバリー・ウォレット（Social recovery wallets）
- 秘密鍵の失効（Key revocation）
- カスタム署名アルゴリズム（Custom signature algos）
利便性関連ゴール
- ERC20での手数料支払い（pay fees with ERC20s）
- アプリケーションによるトランザクションのスポンサー（Sponsored txs）
「例えばカスタム署名アルゴリズムについて、イーサリアムでは、量子耐性（Quantum-proof）についての議論が多くありますが、大きくは2つの見方があると思います。ひとつは、人々が量子セキュアなアドレスを持てるようにすること。そしてもうひとつは、人々が量子セキュアな“バックアップ”の仕組みを持つアドレスを作ることを可能にするということです」
イーサリアムでは（もちろんビットコインでも）、楕円曲線を用いた暗号化技術を用いて、秘密鍵と公開鍵という一対の組み合わせを生成している。ランダムな文字の羅列である秘密鍵に対して楕円曲線暗号技術を使って公開鍵を生成し、公開鍵から簡単に秘密鍵を算出できないように工夫をしている（この辺りの仕組みについてはこちらの記事がわかりやすいです）わけで、具体的にはsecp256k1と呼ばれる楕円曲線上で、ECDSA（Elliptic Curve Signatures）と呼ばれる署名方式を採用している（電子署名には複数の方式が存在する）。要するに、秘密鍵から公開鍵は簡単に算出できるが、その逆は不可能であることが前提となって、現在のように公開鍵がウェレットアドレスとして運用されているわけだ。
一方で量子コンピュータの登場によって、その前提が崩れる可能性があることも指摘されている。というか、量子コンピュータによってECDSAは破られてしまうことは既知の事実となっている（こちらを参照）。イーサリアムはECDSAベースなので基本的にはこの脅威が残り続けることになるわけで、ヴィタリック氏のいう量子耐性とは、この観点での議論というわけだ。
これに対する解決策として注目されているのがアカウント抽象化技術ということになる。アカウント抽象化を導入することで、「すべてのユーザーが、自分のニーズに合わせたカスタム認可ロジックを持つアカウントをデプロイして使うことができる」と、スマートコントラクト・ウォレット「Argent」のCo-FounderであるJulien Niset氏は説明している（詳細はこちら、日本語訳でわかりやすくまとまっている記事がこちら）。
このイーサリアムの量子耐性について、ヴィタリック氏は現状での対策案を説明しつつ、アカウント抽象化はさらなる可能性を広げるアプローチだと強調する。
「公平を期すために言っておくと、実際のところ、人々は現在の量子耐性について過小評価していると感じます。量子コンピュータを触ったことがある人なら、あるアカウントが1回でも取引に署名していれば、その1回の取引から公開鍵を復元できることを知っているでしょう。しかし、シードフレーズそのものは復元できません。だから現状であっても、緊急で量子コンピュータ対策で復元をしたい場合は、基本的にシードフレーズそのものを新しい鍵にすればいいわけです。さらに、量子移行が起きた場合も、シードフレーズのSTARKを新しい鍵として使うことができます。もちろん、アカウント抽象化を導入することで、これらの様々なものを実装するための柔軟性が大幅に向上することも間違いないでしょう」
各ゴールについて簡単に触れた上で、同氏は「複数のオペレーションを同時に行うことが重要だ」と続ける。
「例えばEIP1559がまだ存在せず、最初の取引が確認されるまで5分くらい待たされることが、2020年以前にはありましたよね。そういうことは基本的にはイケていないと思います。一方で、承認されたコールを行い、1回のトランザクションで取引を行うことができるという経験をしたい人もいるでしょう。アカウント抽象化によって、このようなことが可能になるわけです。これは利便性に関わる機能であると同時に、セキュリティに関わる機能でもありますよね？なぜなら、複数の操作を行いたい場合、安全でない中間段階が存在するようなユースケースが多いからです。だから、承認自体もある意味で安全ではないと言えます。というのも、あなたは基本的に「よし、承認しよう」と言っているわけで、そうするとユーザーは承認に飽きてしまう。そうすると、ユーザーは承認にうんざりして、なんでもかんでもダラダラと承認するようになるでしょう。一度怠慢な承認をしてしまうと、悪意のあるアプリが登場することになります。実際に存在し、問題になっていますよね。ですから、もしこのような常時承認という概念をなくすことができれば、そして、ただちに適切な量を承認し、すぐにトークンを取得して取引できるようなマルチ・オペレーションができれば、それは人々のセキュリティ上の問題も解決することになります。このようにアカウント抽象化にはたくさんのゴールがあり、それこそがエコシステムにとって本当に美しく、それ故に一致団結できる部分があると感じます」
イーサリアムのいいところは、イーサリアムアドレスを標準とするところにあり
現状認識が共有された上で、今度はアカウント抽象化に向けたチャレンジについて。ヴィタリック氏はここでも、大きく「既存」と「新規」という2つの分類で、それぞれの取り組み内容を説明した。
既存アプローチ
- ウォレット（Wallets）
- 分散型アプリケーション（Dapps）
- 開発者ツール（Dev Tools）
- 認証方式（Authentication methods）※共通
新規アプローチ
- レイヤー2（L2s）
- プライバシーインフラ（Privacy Infrastructure）
- MEVインフラ（MEV Infrastructure）
- 認証方式（Authentication methods）※共通
例えば開発者ツールの一例として、Uniswapでのシンプルな「承認→取引」という2ステップの取引を考えてみる。これについてアカウント抽象化を導入することで1つの処理にまとめることができるわけだが、問題は、基礎となるJavaScriptライブラリには、ウォレットに「複数の操作を行う」という命令を与える方法がない点が挙げられる。
「たとえERC-4337が導入されてそのようなオペレーションが可能だとしても、実際のところユーザーは2つのオペレーションを送信し続けなければならないかもしれません。これに対して私が話を聞いたところでは、独自のカスタムインターフェースを作ることでこの問題を解決しているウォレットもありました。でも最終的には、少数のアプリケーションにユーザーを集中させるだけでなく、汎用的なものにしたい。すべてのアプリケーションが恩恵を受けられるように汎用的にしたいのです。そのためには、基本的にWeb3のJavaScriptライブラリ・レベルのツールが必要になります。もちろん、付随してブロック・エクスプローラーも、アカウント抽象化操作をサポートする必要があるでしょう。このように、適応が必要なツールは実にたくさんあるわけです」
対して新規アプローチとしては、レイヤー2、プライバシーインフラ、MEVの3点が挙げられる。例えばレイヤー2のスケーリング問題については、直近だとヴィタリック氏による ”The Three Transitions” にて語られている通り、イーサリアムの持続的な成長（もっと言えば失敗しないため）のKFSの一つとして据えられている。
同様にプライバシーインフラについても3要素のうちの一つと掲示されており、プライバシーの保護とアカウント抽象化、さらにはプライバシーの保護と複数のレイヤー2を同時に進めるにはどうすれば良いのかという課題が参加者に投げかけられた。
それからMEVインフラだ。MEV（Maximal Extractable Value：最大抽出可能価値）とは、各トランザクションがブロックに取り込まれるまでのプロセスによって発生する現象で、バリデータによるトランザクションの検証プロセスにおいて受け取る対価を最大化すること、ないしは価値そのものを示す。このMEVを悪用しようとする諸問題への対処が、ここで言及されているMEVインフラのトピックとなる。2022年9月のThe Mergeが成功しProof of WorkからProof of Stakeへと移行したことから、マイナーの代わりにバリデータが取引を承認し、報酬を得るようになったわけで、バリデータはステーキングと呼ばれるプロセスで自分の持っているETHを担保にして取引を承認する役割を果たすのだが、バリデータも取引の順序や選択を自由に変更できるため、このMEVの問題は依然として存在することになる。マイナーではないがMEVは続いているということで、 以前は “Miner Extractable Value” の略語だったのだが、現在では “Maximal Extractable Value” へと意味合いが修正されたという経緯がある。
ヴィタリック氏はこのMEV問題について、先述のERC-4337がEthereumプロトコルに完全に統合されない限り、検閲に対する抵抗という点での利点を十分に享受できないことを懸念する。
「ここでいうMEVインフラについては、Bundlerや既存のPBS（Proposer-Builder Separation）のみならず、例えばプロトコルの変更も含まれます。一例として、プロポーザー（Ethereumのバリデータ）は基本的に、現在のブロックか次のブロックのいずれかに特定のトランザクションを含めるよう、ビルダーに強制することができます。インクルージョンリストは基本的に、ビルダーが検閲する力を排除します。ここでの問題は、ERC-4337がただのERCとして留まる場合、ERC-4337の運用はこの検閲に対する抵抗の恩恵を適切に受けられないということにあります。一方で、ERC-4337をプロトコルの機能として明記し、インクルージョンリストやIPでカバーするようにすれば、問題は解決しますよね？これが、私が長期的にERC-4337を明記することに価値があると考える理由の1つです」
そして既存と新規の両アプローチのトピックとして触れられたのが「認証方法」だ。ここについてヴィタリック氏は「イーサリアムのいいところは、イーサリアムアドレスを標準とするところにあると思う」と説明を続ける。
「例えば特定のsecp256r1キーを検証したい場合、そのキーを私に渡せば、私は決定論的な関数を持っていて、それをイーサリアムのアドレスに変えることができます。また日本政府によるデジタルIDカード（マイナンバーカード）を認証したいのであれば、そのカードから公開鍵を取り出し、RSA検証を行い、コントラクトを作成し、2つのアドレスを作成した上で、それをイーサリアムのアドレスに変換することができるでしょう。メールアドレスをイーサリアムのアドレスに変えたいならば、ZK Emailを使ってメールへのアクセス証明のSNARKを検証するzk-SNARK verifierを作れば、メールアドレスをイーサリアムのアドレスに変換できますよね。そして、マルチシグやソーシャルリカバリーの参加者としてイーサリアムアドレスを使用すれば、これらのさまざまな方法と互換性を持つことができます。こうなると、認証方法の存在自体が非常に重要なインフラストラクチャのようなものになり、複数の方法・用途で使用できるようになるのです」
ここで具体的な相互依存の例として、ENS（Ethereum Name Service）とレイヤー2の相互依存性について紹介がなされた。
レイヤー2技術が発展すれば、人々はレイヤー2上で完全に活動するようになる。これは、イーサリアムのトランザクション手数料が高騰し、ENSの更新コストが非現実的に高くなる問題を解決するためであると、ヴィタリック氏は説明する。もしEthereumのトランザクション手数料が2021年の水準に戻ると、ENSの更新コストが100ドルになる可能性があり、これはユーザーエクスペリエンス（UX）としては受け入れがたいだろう。だからこそレイヤー2に移行することで、ENSの更新などの操作が安価に行えるようになるというわけだ。
例えばCCIP（Cross-Chain Interoperability Protocol）というEIPでは、パブリックブロックチェーンとプライベートブロックチェーン間におけるセキュアな通信を可能にするもので、レイヤー1が特定のドメインを所有し、そのドメインのサブドメインを管理する権利をオフチェーンで行うことを可能にする。ヴィタリック氏はここで「bob.myl2.eth」という、レイヤー2上で使用される架空のENSドメイン名を例示する。ここで「bob」はサブドメイン、「myl2.eth」は親ドメインを表す。
ユーザーが「bob.myl2.eth」にアクセスする際、CCIPが親ドメイン「myl2.eth」を所有しているわけだが、先述の通り、ここではオフチェーンのデータ構造が返されることになる。ユーザーは返されたオフチェーンのデータ構造を用いて、証明を提供するノードにアクセスし、必要な情報を取得する。オフチェーンなので、このプロセスに関してはガスレスというわけだ。その上で最終的に、オフチェーンでのコールバック機能を通じて、ユーザーは「bob.myl2.eth」が実際に何を含むのかを知ることができるのだ。
「この事例のいいところは、ほとんど既にできているということです。まだ適切に実装されていないのは、基本的にMerkle証明の実装部分だけです。この例は、レイヤー2技術がENSとどのように統合され、UXを改善し、トランザクションコストを削減するかという観点で成功例の一つと言えるでしょう」
ソーシャルリカバリーで意識すべき「共通モード故障」の考え方
ここまでの内容を踏まえて、ヴィタリック氏は標準化の必要なトピックとして、以下の3点を列挙する。
- ガーディアンの選択
- レイヤー2ごとのアドレス
- プライバシーのためのデータ保護
まずは「ガーディアンの選択」ということで、ここでいうガーディアンとは、マルチシグにおける“参加者”と捉えると良いだろう。一般的な参加者の分類として、同氏は「機関的保護者」、「家族や友人」、そして「自身の他のデバイス」を列挙する。家族や友人についてはイメージがしやすいだろうが、その他の2つについては補足が必要だろう。
「機関的保護者には大きく2つの方法があり、ひとつは、自分が機関後見人の役割を果たしていることを認識し、特定の条件下でマルチシグのトランザクションに署名する役割を担うというものです。例えばCoinbaseなどの企業が機関的保護者としてのサービスを提供する例がが考えられるでしょう。この場合、Coinbaseはユーザーに対し、特定の条件下でメッセージに署名するサービスを提供するわけですが、ユーザーはCoinbaseがメッセージに署名するための条件を設定できます。例えば、将来的にメッセージに署名を求める際に、ビデオ通話を行い、最大限のKYC（Know Your Customer、本人確認）を提供する必要があるという条件を設定することができるわけです。セキュリティを本当に重視する人にとっては、良い選択肢かもしれません」
そしてもうひとつの方法は、既存の中央集権的なプロバイダーを共同利用して、彼らを機関的保護者にすることだと同氏は続ける。例として挙げられたのが、電子メールにおけるゼロ知識証明（以下、ZK proof）の活用だ。また、政府発行のデジタルIDの正当性を証明するためのZK proofの活用も提案された。これにより、個人が自分の身元を確認できるようになるが、そのプロセスで個人情報を露出することはないということになる。このように、ヴィタリック氏はZK proofを多くの異なるコンテキストに適用できると指摘しており、これによって様々な種類の情報をセキュアに扱うことが可能になると考えられる。
「そうすれば、既存のブロックチェーン領域以外ですでにセキュリティ・インフラを提供している企業を、イーサリアムのアドレスに変えることもできます。暗号学的に検証可能なあらゆるものを、オンチェーンの検証者を備えたイーサリアムアドレスに変換することができるというわけです」
また同氏は、NFCカードやチップを搭載したカードなどの「自身の他のデバイス」の活用についても、マルチシグの一部として使用することができると紹介する。
「Yubikeyのように、認証に特化したデバイスがたくさんあります。それらは1：1の署名者やリカバリーシステム、またはN：Nの一部として使用される可能性があるでしょう。ユーザーはこれらのデバイスをどのようなフォームファクターで使用するかを自由に決めることができます。これにより、ガーディアンのサービスとしてのコモディティ化を促進し、それぞれが固有のUIを作成することなく、単にその機能を果たすことに重点を置くことが、アカウント抽象化とセーフティエコシステムの成長に貢献すると考えています」
ここで会場から、「マルチシグ及びソーシャル・リカバリーにはそれぞれ欠点があるが、それを軽減するようなパターン等はあるか？」という質問が投げかけられた。これについてヴィタリック氏は「非常に良い質問だ」と笑顔で応え、「リスクをゼロにするようなセットアップなどは基本的に存在しない」と前置きした上で、自身の考えを述べた。
「実は面白いことに、一番簡単に復旧できたと思うのは、皮肉なことにWeChatのアカウントでした。WeChatには基本的なソーシャルリカバリーの仕組みが組み込まれているんです。つまり、アカウントを回復したい場合、連絡先のいくつかが表示されるので、その連絡先に連絡する他の方法を見つけて、WeChatの会話で特定の6桁の数字を入力するように伝えるだけなのです。それだけなのですが、建築的に一元化されたものよりもうまく機能しているように感じます。基本的に、中央集権的な現状があらゆる面で常に人々の期待を裏切っていることを忘れてはいけないと思っています」
システム周りをやっていると「共通モード故障（common mode failures）」という考え方を目にすることがある。つまり、何かしらのシステムにおいて冗長化設計をしたとしても、単一の要因によって冗長化した機器・要因群が同じモードで同時に故障するという現象を示す言葉だ。この共通モード故障の考え方をソーシャルリカバリーでもしっかりと意識する必要があると、ヴィタリック氏は強調する。
「例えば友人や家族で構成している場合、共謀のリスクが大きな問題になりますよね？だからこそ私が常々アドバイスしているのは、バラバラのグループの友人をチョイスしましょうということです。そして、お互いに誰なのかを教えないということもです。もしあなたが亡くなったら、彼らはソーシャルメディア上で大声で叫ぶだろうし、あなたの家族に叫ぶかもしれない。でも、もしあなたが死んでいない時にそんなことをしようとしたら、あなたが先に気づいて、彼らを追い出すことができますよね。だからこそ、基本的には共通モード障害はできるだけ避けるようにしているのです。あともう一つは、メールアドレスをイーサリアムのアドレスに変えて、それをガーディアンとして使うというアイデアを提唱しています。でも、例えば5人中3人くらいになるのは避けたいですよね。仮に3ヵ国に3人の友だちがいると思うかもしれないけど、その3人がみんなGmailアカウントのラッパーを使っていたら、どうなると思いますか？Googleはあなたのアカウントを奪う鍵を持っているんですよ？だから、共通モード障害を避けることは本当に重要な原則なのです。一方で、これはまだまだ未解決の問題であって、基本的には経験によってしか解決に近づくことができないと、僕自身は考えています」
アドレス管理の際に考えるべきENSとメタアドレス
標準化の必要なトピック2つ目は「レイヤー2ごとのアドレス」の存在だ。現在、イーサリアムでは全てのレイヤー2で同じアドレスを使用するのではなく、異なるレイヤー2で異なるアドレスを持つ方向に進んでいると、ヴィタリック氏は述べる。これは、様々な理由から良いアイデアである可能性があるものの、まだ議論の余地があるとも言及してしている。
非EVM（Ethereum Virtual Machine）互換のレイヤー2では、同じアドレスハッシュを持つことが難しいため、アドレスの管理がより複雑になる可能性があるという。そこで、アドレス管理のテクニックとして提示されたのが、先述のENSとメタアドレスの利用だ。ENSレコードを使うことで、L1アドレスやOptimismアドレス、その他のアドレスを指定することができる。一方でメタアドレスは、特定の関数に渡すと複数のアドレスを生成することができる属性のもので、ステルスアドレス（受信者も送信者も匿名性を担保した取引）の文脈で説明がなされた。よって、プライバシーを保持する形での寄付などを可能にするという。
ENSはオンチェーンで料金を支払うまではENS名を持つことができないという点がデメリットである一方で、メタアドレスはオフチェーンでありながら複数のネットワークにまたがるアドレスを生成するために使用できると同氏は説明する。
「自転車代を払うために70USDCをあなたに送ろうとしている人は、あなたがどのネットワークを使っているのか知らないかもしれません。だから、ある種のメタアドレスを標準化することも価値があるのです。また、ENSを拡張して異なるレイヤー2や、レイヤー2ではない異なる種類の新しいプロトコル、特にステルスアドレスやプライバシーを保護するプロトコル間のアドレスについて考えることも重要だと考えています」
そして標準化の必要なトピック、最後3つ目は「プライバシーのためのデータ保護」だ。
「まずは標準化と暗号化（Standardizing and encryption）ですが、これは少し停滞している分野のひとつですね。以前、MetaMaskなどのウォレットではアドレスに対して暗号化する機能がありましたが、署名用キーと暗号化用キーを混用する潜在的な危険性があることから、この機能は取り下げられました。しかしアカウント抽象化によって、ERC-1271のようなオフチェーン署名の検証メカニズムを活用して、特定のアドレスの現在の保持者が復号できるように何かを暗号化する方法を標準化する機会が生まれると思います。このように、暗号化と復号キーの標準化を実現することで、既存のPGP（Pretty Good Privacy）エコシステムとの相互運用性を確立することができると考えています」
また「データ保管形式の標準化（Standardizing “data vault” formats）についても検討すべき事項だ」と、ヴィタリック氏は説明する。つまり、プライバシーを保護するアプリケーションが一般化するにつれて、ユーザーは資産だけでなくデータの管理者にもなる。その際に暗号化キーを失うと、たとえ理論的にはまだデータを保持していたとしてもデータの利用ができなくなるため、データの保管にも注意が必要になるのだ。このほかに、「暗号化キーの復旧プロセスの標準化（Standardizing recovery of decryption keys）」についても、標準化課題の一つだと同氏は付け加えた。
エコシステムは今後数年間で、本当に重要な形でアップグレードされるでしょう
以上の説明を経て最後に、改めてこれからに向けて持つべきゴールについて、以下の4点が列挙された。
- 現在のEOAのように特定のアクターに依存しないこと
- 現在のEOAのようなウォレットポータビリティの確保
- 現在のEOAのような共有パブリックメモリプール（mempool）
- EOAがインクルージョン・リストを持つように、チェーン上での検閲に強い抵抗力を持つこと
「つまり、EOAが現在持っている非中央集権性、開放性、検閲耐性といった特性を、L2やアカウント抽象化の世界、さらにはプライバシーの世界でも維持できるようにするのです。これには多くの実作業が必要で、私たちが実際に行っていることを改めて確認することが重要だと考えています。その上で結論として、エコシステムは今後数年間で、本当に重要な形でアップグレードされるでしょう。スケーリングはとても重要です。協力することも重要です。エコシステムとしてこういったことを推し進め、包括的にみんなの目標を考慮しながら進めていくことで、より速く仕事ができることも証明してきたと思います。VCはみんな『さあ、イーサリアムをモノにするんだ！みんなパロアルトに引っ越して、1日14時間、ピザを食べながら会社として突き進むんだ！そうすれば成功する』なんていうけど、僕たちは一切無視して、結果大丈夫だったでしょ？だから、分散型エコシステムとして協力しあい、驚くほど効果的な方法でその恩恵を得られるようにしましょう。そして基本的には、作る必要のない依存関係を作らないように細心の注意を払いましょう。オープンで、グローバルで、パーミッションレスなエコシステムとして、人々が入ってきて参加できるという事実は、とても貴重なものです。私にとっては、それがこのスペースの核心なのです」
フル動画はこちら
取材／文：長岡武司
Web3 Transition Summit 2023 および TOKEN 2049 SINGAPORE 2023 関連の記事はこちら
