イーサリアムプロトコルの前史：涅槃からゆっくりと目覚める
TechFlow厳選深潮セレクト
イーサリアムプロトコルの前史：涅槃からゆっくりと目覚める
本稿は、イーサリアムプロトコルが開始からリリースに至るまでの進化の過程を振り返ることを目的としている。
Web3業界の深掘り報道に専念し潮流を洞察記事は2017年9月14日に執筆されました
編集者注：本稿は、ヴィタリックがイーサリアムプロトコルの構想から初期リリース、進化に至るまでの歴史を振り返ったものである。
現在のイーサリアムプロトコルの背後にある理念はここ数年でほぼ安定しているものの、今日の形になったのは一朝一夕のことではない。イーサリアムブロックチェーンの登場以降、そのプロトコルは数多くの重要な進化と意思決定を経てきた。
本稿では、イーサリアムプロトコルが発足からリリースまでどのように進化したかを回顧する。Geth、cppethereum、pyethereum、EthereumJといった各クライアント実装における膨大な作業や、イーサリアムエコシステム上のアプリケーションおよびビジネスの歴史については、本稿の範囲外とする。
また、Casperやシャーディング研究に関する歴史も対象外とする。確かに、フラッド（Vlad）、ギャビン（Gavin）、私自身、そして他の人々が提案し、後に捨て去られたさまざまなアイデアについて、さらに別の記事を書く余地はある。たとえば、プルーフ・オブ・ワークのためのプルーフ、ロータリー多チェーン、ハイパーキューブ、シャドウチェーン（ある意味Plasmaの前身）、チェインファイバー、Casperのさまざまな反復バージョン、あるいはフラッドが提唱したコンセンサスプロトコル内での参加者へのインセンティブ設計に関する急速に変化する考えなどがある。これらの背後にある物語自体が非常に複雑であり、別途一文を割くべき内容だ。ここではひとまずそれらには触れない。
最も初期のバージョンから始めよう。このバージョンこそが最終的にイーサリアムとなったものだが、当時はまだ「イーサリアム」という名前すらなかった。2013年10月、私はイスラエルを訪問し、マスタービット（Mastercoin）チームと多くの時間を過ごした。彼らにいくつかの機能追加を提案さえした。彼らの取り組みを熟考した結果、私は彼らに送った提案の中で、同プロトコルをより汎用的にし、巨大かつ複雑な機能セットを追加することなく、より多様なタイプの契約をサポートできるようにすることを提唱した：
https://web.archive.org/web/20150627031414/http://vbuterin.com/ultimatescripting.html
このバージョンは、後のイーサリアムの広範なビジョンとは大きく異なる点に注意されたい。これは純粋に、マスタービットが当時挑戦していた技術――すなわち、双方間契約――に集中していた。この契約では、A氏とB氏が資金を共同投入し、その後、契約に定めた特定の式に基づいて資金を引き出すことができる（例：「Xが起きたら全額をAに、そうでなければ全額をBに」）。この契約を実現するスクリプト言語はチューリング完全ではなかった。
マスタービットチームはこの提案に感銘を受けたが、自らの開発路線を捨ててこの方向に進む気はなかった。一方、私はこれが正しい道だとますます確信を持った。そこで、同年12月頃、第2のバージョンが登場した：
https://web.archive.org/web/20131219030753/http://vitalik.ca/ethereum.html
このバージョンでは、大幅な再構築が行われている。その多くは、11月にサンフランシスコでの長距離散歩中に思いついたものだった。この時点で、私はスマートコントラクトが完全に汎用化可能であることに気づいた。スクリプト言語が単なる双方向関係を記述するだけではなく、コントラクト自体が成熟したアカウントとなり、資産の保有・送受信、さらには永続ストレージの維持（当時は「メモリ」と呼ばれており、一時的な「メモリ」は256個のレジスタのみ）ができるようになった。言語はスタックベースの仮想マシンから、私の好みに合うレジスタベースの仮想マシンへと変わった。これに関して異論はほとんどないが、明らかに複雑さが増しているように思えた。
「イーサ（ether）」の文字通りの意味は「エーテル」（燃料、ガスに相当）である。すべての計算ステップの完了後、トランザクションによって呼び出されたコントラクトの残高はいくらか減少する。もしコントラクトの資金が尽きれば、実行は停止する。この受信者支払い方式により、コントラクト自体が送信者に手数料の支払いを要求しなければならない。その支払いがない場合、即座に実行が中止される。このバージョンのプロトコルでは、16ステップの無料実行枠が設けられており、手数料を払わないトランザクションを拒否できるようになっていた。
この時点まで、イーサリアムプロトコルは完全に私一人によって構築されていた。しかし、ここから新たな参加者が加わっていく。プロトコル面で最も目立った貢献をしたのはギャビンであり、彼は2013年12月にabout.meを通じて私に連絡してきた。
ジェフリー・ウィルキー（Jeffrey Wilcke）――Goクライアント（当時は「ethereal」と呼ばれていた）の首席開発者――も同じ時期に連絡をよこし、プログラミングを始めた。ただし、彼の貢献はクライアント開発に重きを置いており、プロトコル研究にはあまり関与しなかった。
ギャビンの初期の貢献は二つある。第一に、初期設計におけるコントラクト呼び出しモデルは非同期的であった点に注目してほしい。つまり、コントラクトAがコントラクトBに内部トランザクション（「内部トランザクション」はイーサリアムの専門用語。当初は単に「トランザクション」と呼ばれ、後に「メッセージ呼び出し」または「呼び出し」と呼ばれるようになった）を生成できても、最初のトランザクションの実行が完全に終了するまでは、内部トランザクションの実行は開始されなかった。つまり、トランザクションは内部トランザクションを使って他のコントラクトから情報を取得することはできず、代わりにEXTROというオペコード（他のコントラクトのストレージを読み取るために使うSLOADのようなもの）を使う必要があった。しかし、このオペコードは後にギャビンらの支持のもと削除されることになる。
ギャビンが私の初期仕様を実装する際、自然に内部トランザクションを同期的に実装した。彼は両者の意図の違いに気づかなかったのだ。つまり、ギャビンの実装では、あるコントラクトが別のコントラクトを呼び出すと、内部トランザクションが即座に実行され、その実行が完了すると仮想マシンは呼び出し元のコントラクトに戻り、次のオペコードを継続して実行する。私にとっても彼にとっても、この方法の方が優れているように思われたため、これを正式な仕様として採用することにした。
第二に、私とギャビンとの議論（サンフランシスコでの散歩中の出来事のため正確な詳細は歴史の流れの中に消え去ってしまったが、NSAの深層アーカイブには数部コピーが存在するかもしれない）により、手数料モデルがコントラクト支払いから送信者支払いへと改訂され、燃料（gas）モデルへと移行した。以前は各計算ステップごとに直ちに一定量のイーサが消費されたが、新しい方式では、トランザクションの発信者が一定の手数料を支払い、それに応じた量の燃料（計算ステップのカウンター）が割り当てられる。計算はこの燃料制限内で行われる。もしトランザクションが全ての燃料を使い切った場合、その燃料は失われるが、実行全体は巻き戻される。これは、コントラクトが部分的な実行攻撃を心配する必要がなくなるため、最も安全な方法と考えられた。トランザクションが正常終了した場合、未使用の燃料に対応する手数料は返金される。
ギャビンは、イーサリアムのビジョンに微妙ながらも重大な変化をもたらした。それは、「あらかじめ設定されたルールに従ってデジタル資産を保持・転送できるブロックチェーンベースのコントラクトを備えた、プログラム可能な通貨のプラットフォーム」から、「汎用計算プラットフォーム」への移行である。この変化は、イーサリアムの重点や用語のわずかな変化から始まり、Web3統合（イーサリアムを分散型技術スイートの一部と見なし、他にWhisperプロトコルとSwarmプロトコルを含む、図1参照）への注力が高まるにつれ、さらに強化されていった。
2014年初頭、他者の提案に基づいていくつかの修正も加えられた。アンドリュー・ミラー（Andrew Miller）らによるスタックベースアーキテクチャへの回帰提案を受け、最終的に私たちはそれを採用した（図2）。
チャールズ・ホスキンソン（Charles Hoskinson）は、ビットコインのSHA256から最新のSHA3（正確にはkeccak256）への切り替えを提案した。議論を経た末、ギャビン、アンドリュー、その他との協議の結果、スタック内の値のサイズを32バイトに制限することが決定された。無制限整数という代替案も検討されたが、加算・乗算などの操作に必要な燃料量の計算が困難であるという問題があり、結局採用されなかった。
2014年1月、私たちが最初に考えたマイニングアルゴリズムは「ダガー（Dagger）」と呼ばれるものだった：
https://github.com/ethereum/wiki/blob/master/Dagger.md
ダガーは有向非巡回グラフ（Directed Acyclic Graph, DAG）に由来する名称である。DAGはアルゴリズム内で使用される数学的構造であり、Nブロックごとに種となる乱数から擬似ランダムに新しいDAGが生成される。DAGの基層には数十億バイトのデータを格納するノード集合が必要となるが、任意の独立した値を生成するには数千項目の計算だけで済む。ダガー計算とは、この基層データセット内の任意の位置から一定数の値を取得し、それらをハッシュ化する処理を指す。つまり、高速な方法（メモリ内にデータを保持）と、遅いがメモリ負荷の少ない方法（DAGから都度生成）の両方が存在する。
このアルゴリズムの目的は、Scryptと同様のメモリ制限特性を持ちつつ、ライトクライアントにも優しいものにすることだった。マイナーは高速な方法を使い、マイニングはメモリ帯域幅に依存する（理論上、消費者向けメモリの最適化は十分進んでおり、ASICによるさらなる最適化は困難）。一方、ライトクライアントはメモリ負荷が少なく遅い方法で検証できる。高速法は数マイクロ秒、遅い方法でも数ミリ秒程度なので、ライトクライアントにとっても実用可能である。
ここから、イーサリアムの発展に伴い、このアルゴリズムは数回の変更を経ることになる。次に浮上したのが「適応型プルーフ・オブ・ワーク」だった。この方式では、プルーフ・オブ・ワークとしてランダムに選ばれたイーサリアムコントラクトの実行を含めるというもので、ASIC耐性の巧妙な仕組みもあった。つまり、ASICが開発された場合、競合するマイナーたちはそのASICが苦手とするコントラクトを作成・公開する動機を持つ。ASICは汎用計算には不向きであり、CPUそのものにすぎない。こうして、対抗的なインセンティブを利用することで、本質的に汎用計算を実行するプルーフ・オブ・ワークを実現できると考えた。
しかし、シンプルな理由によりこのアイデアは破綻した。それは「長期攻撃（long-range attack）」の可能性である。攻撃者はブロック1からチェーンを構築し、シンプルなコントラクトで埋め尽くすことができる。このようなシンプルなコントラクトに対しては、専用ハードウェアを設計でき、攻撃チェーンがメインチェーンを容易に追い抜くことが可能になる。こうして、私たちは再びゼロに戻った。
次のアルゴリズムは「ランダム回路（Random Circuit）」と呼ばれ、Googleドキュメントで詳細が説明されている。これは私とフラッド・ザンフィル（Vlad Zamfir）が提案し、マシュー・ワンプラー・ドティ（Matthew Wampler-Doty）らが分析したものである。このアイデアは、疑似ランダムに生成された回路の実行を通じて、マイニングアルゴリズム内で汎用計算を模倣することだった。今回も、こうした原理に基づくものが不可能であるという決定的証拠はなかった。しかし、2014年に相談したハードウェア専門家たちは皆、非常に悲観的だった。マシューはSATソリューションに基づくPoWも提案したが、最終的に却下された。
最終的に、私たちはダガー・ハシimotoアルゴリズム（略称Dashimoto）に行き着いた。これはハシimotoの多くのアイデアを採用している。ハシimotoはサディアス・ドライヤ（Thaddeus Dryja）が提案したプルーフ・オブ・ワーク機構で、「I/O制約型PoW」という概念を確立した。この方式では、マイニング速度の主な制約はハッシュ演算速度ではなく、RAMが毎秒アクセスできるメガバイト数にある。ダガー・ハシimotoは、このPoW機構を、ライトクライアントに優しいDAGデータセット（ダガー由来）と統合したものである。私、マシュー、ティムらによる幾度かの調整を経て、これらは現在「Ethash」と呼ばれるアルゴリズムに落ち着いた。
2014年夏までに、PoWが2015年初頭にEthashに到達する必要があることを除けば、プロトコルはかなり安定しており、半形式的な仕様はギャビンによる「黄皮書」として公開されていた。
2014年8月、私は叔ブロック（uncle block）メカニズムを開発・導入した。これは、イーサリアムのブロックチェーンが短いブロック時間と高い処理能力を持ちつつ、中央集権化リスクを低減することを可能にする。叔ブロックメカニズムの詳細はPoC6を参照。
BitSharesチームとの議論を経て、ヒープを第一級データ構造として採用する案も検討されたが、時間不足のため断念。後にセキュリティ監査やDoS攻撃を通じて、当時そのような機能を安全に実装するのは想像以上に困難であることが分かった。
9月、ギャビンとともにプロトコル設計の大きな変更を二つ計画した。第一に、状態ツリーとトランザクションツリーに加え、各ブロックに「レシートツリー」を含めること。レシートツリーは、各トランザクションが生成したログのハッシュと中間状態ルートを含む。ログにより、トランザクションがブロックチェーン上に保存可能な出力を生成でき、ライトクライアントがアクセス可能になる。ただし、将来の状態計算ではこれらのログは参照できない。この方式により、分散型アプリはトークン送金、購入、交換所注文の作成・マッチング、オークションの進行などを簡単に照会できるようになる。
また、トランザクションの完全実行履歴からメルクル木を抽出し、任意の内容を証明可能にする案も検討された。簡潔性と完全性のトレードオフを経て、最終的にログ方式を選択した。
第二に、「プリコンパイル（precompiled contracts）」のアイデアである。プリコンパイルは、EVMのオーバーヘッドを避けつつ、複雑な暗号計算をEVM内で利用可能にする解決策である。さらに、より野心的な「ネイティブコントラクト」のアイデアもあった。マイナーが特定のコントラクトをより効率的に実行できる場合、その燃料コストを投票で引き下げられるというものだ。そうすれば、大多数のマイナーが高速に実行できるコントラクトは自然に低い燃料価格を持つことになる。しかし、これらすべてのアイデアは、暗号経済学的に十分安全な実装方法を提示できなかったため却下された。攻撃者は、アクティブバックドア付きの暗号操作を実行するコントラクトを作成し、それを自分たちと仲間に配布することで、そのコントラクトを高速実行できる。その後、燃料価格を引き下げ投票し、ネットワークにDoS攻撃を仕掛けることができる。そのため、代わりに、ハッシュや署名スキームなどに使う少数のプリコンパイルをプロトコルに直接定義する、より控えめなアプローチを採用した。
ギャビンは、プロトコル抽象化の初期提唱者でもあった。これは、Ether残高、トランザクション署名アルゴリズム、nonceなどプロトコルの多くの要素を、プロトコル自体の中でコントラクトとして移行するというものである。理論上の最終目標は、イーサリアムプロトコル全体を「特定の初期化状態を持つ仮想マシンに関数呼び出しを行うこと」として記述できるようにすることだ。これらのアイデアを初期のフロンティア版に取り入れる時間はなかったが、「コンスタンティノープル」のいくつかの変更や、Casperコントラクト、シャーディング仕様を通じて徐々に統合されていくことが予定されていた。
これらの変更はすべてPoC7で実装された。PoC7以降、プロトコルに大きな変更はほとんどなく、若干の微調整のみが行われた。これらの詳細はセキュリティ監査後に公表される予定だった。
2015年初頭、ユッタ・シュタイナー（Jutta Steiner）らは、リリース前のセキュリティ監査を組織した。これにはソフトウェアコード監査と学術監査が含まれる。ソフトウェア監査は主に、ギャビンとジェフが率いるC++およびGo言語の実装に対して行われた。私のPyethereum実装も簡単な監査を受けた。学術監査は二つあり、一つは「利己的マイニング」で知られるイタイ・エイヤル（Ittay Eyal）が担当、もう一つはアンドリュー・ミラーとLeast Authorityのメンバーが担当した。エイヤルの監査により、チェーンの総難易度に叔ブロックを含めないという軽微なプロトコル変更が行われた。Least Authorityの監査はスマートコントラクト、燃料経済学、パトリシア木に重点を置いた。これによりいくつかのプロトコル変更が生じた。特に小さな変更としては、ツリーのキーとしてアドレスやキーそのものではなく、sha3(addr) と sha3(key) を使用するようになった。これにより、攻撃者がツリーに対して最悪のケース攻撃を行うのが難しくなった。
もう一つ重要な議題となったのは、燃料制限の投票メカニズムだった。当時、ビットコインのブロックサイズをめぐる議論が進展しないことに懸念を抱いており、イーサリアムでは時間とともに柔軟に調整可能な設計を望んでいた。しかし課題は、「最適な制限とは何か？」ということだった。当初の私の案は、実際の燃料使用量の長期指数移動平均（EMA）の1.5倍を動的制限とするというものだった。長期的には、平均ブロックが容量の2/3を使用することになる。しかし、アンドリューはこの制限が悪用可能であることを証明した。具体的には、制限を上げたいマイナーは、大量の燃料を消費しながら処理時間は極めて短いトランザクションを自分のブロックに含めればよく、満杯のブロックを作りつつコストをかけずに済む。結果として、このメカニズムの安全性は、単にマイナーが燃料制限を投票で決めるのと同等になってしまう。
より良い燃料制限戦略を提示できなかったため、アンドリューはマイナーが明示的に投票する方式を推奨した。デフォルトの投票戦略はEMAの1.5倍とする。なぜなら、最大燃料制限をどう設定すべきかの正しい方法がまだ分かっておらず、特定の方法が失敗するリスクは、マイナーが投票権を濫用するリスクよりも遥かに高いと思われたからだ。したがって、むしろシンプルにマイナーによる投票を許容し、燃料制限が高すぎたり低すぎたりするリスクを受け入れつつ、柔軟性と、必要に応じて迅速に調整できるメリットを享受するほうが良いと判断された。
私とギャビン、ジェフによるミニハッカソンの後、3月にPoC9がリリースされた。これは概念実証の最終版を目指したものだった。その後、「オリンピック」と呼ばれるテストネットを4か月間稼働させた。このテストネットでは、メインネットに使用する予定のプロトコルが使われた。同時に、イーサリアムの長期ロードマップも構築された。ビナ・グプタ（Vinay Gupta）が「イーサリアムのリリースプロセス」と題する記事を執筆し、メインネット開発の4段階に、「フロンティア」「ホーム」「メトロポリス」「シリエンス」という、今ではお馴染みの名称を与えた。
「オリンピック」テストネットは4か月間稼働した。前半2か月で、さまざまな実装において多数のバグが発見され、コンセンサス失敗などの問題も起きた。しかし6月頃にはネットワークは著しく安定した。7月に入り、コードの固定を決定。2015年7月30日、イーサリアムメインネットが正式にリリースされた。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@VitalikButerin
