イーサリアム・ホワイトペーパー

お読みになる前に

イーサリアムについて知りたいですか？

このホワイトペーパーは、イーサリアムがローンチされる前の2014年に公開されました。10年以上の開発、主要なアップグレード、エコシステムの成長を経て、オリジナルのホワイトペーパーは現在のイーサリアムの姿を反映していません。

現在のイーサリアムについて学ぶオリジナルのPDFをダウンロード (2014年)

2014年から何が変わったのか？

イーサリアムはプルーフ・オブ・ワーク (PoW) からプルーフ・オブ・ステーク (PoS) へ移行しました (マージ、2022年)

レイヤー2 (L2) のスケーリングソリューションは、現在数百万件のトランザクションを処理しています

分散型金融 (DeFi)、NFT、DAOが主要なユースケースとして台頭しました

スマート・コントラクトの標準 (ERC-20、ERC-721) が業界の基盤となりました

数年前のものですが、引き続き有用なリファレンスとして機能し、イーサリアムとそのビジョンを正確に表現しているため、以下のオリジナルの論文をそのまま掲載しています。

次世代のスマート・コントラクトおよび分散型アプリケーション・プラットフォーム

2009年のサトシ・ナカモトによるビットコインの開発は、裏付けや「本質的価値 (opens in a new tab)」を持たず、同時に中央集権的な発行者や管理者も存在しないデジタル資産の最初の例として、貨幣や通貨における画期的な進歩としてしばしば称賛されてきました。しかし、ビットコインの実験において、おそらくさらに重要なもう一つの部分は、分散型コンセンサスのツールとしての基盤となるブロックチェーン技術であり、ビットコインのこの別の側面に急速に注目が集まり始めています。ブロックチェーン技術の代替的な応用例としてよく挙げられるものには、ブロックチェーン上のデジタル資産を使用して独自の通貨や金融商品（「カラードコイン (opens in a new tab)」）を表現すること、基盤となる物理的デバイスの所有権（「スマートプロパティ (opens in a new tab)」）、ドメイン名のような代替不可能な資産（「Namecoin (opens in a new tab)」）のほか、任意のルールを実装したコードによってデジタル資産を直接制御するより複雑なアプリケーション（「スマート・コントラクト (opens in a new tab)」）や、ブロックチェーンベースの「分散型自律組織 (opens in a new tab)」（DAO）などがあります。イーサリアムが提供しようとしているのは、本格的なチューリング完全なプログラミング言語を組み込んだブロックチェーンです。これを使用することで、任意の状態遷移関数をエンコードできる「コントラクト」を作成でき、ユーザーは数行のコードでロジックを記述するだけで、上記で説明したあらゆるシステムや、まだ想像もつかないような他の多くのシステムを作成できるようになります。

ビットコインと既存の概念の紹介

歴史

分散型デジタル通貨の概念や、財産登録などの代替アプリケーションは、何十年も前から存在していました。1980年代および1990年代の匿名電子マネーのプロトコルは、主にChaumian blinding（ブラインド署名）として知られる暗号技術のプリミティブに依存しており、高度なプライバシーを備えた通貨を提供していましたが、中央集権的な仲介者に依存していたため、プロトコルはほとんど普及しませんでした。1998年、ウェイ・ダイのb-money (opens in a new tab)は、計算パズルを解くことによる貨幣の作成と分散型コンセンサスのアイデアを導入した最初の提案となりましたが、分散型コンセンサスを実際にどのように実装できるかについての詳細は乏しいものでした。2005年、ハル・フィニーは「再利用可能なプルーフ・オブ・ワーク (opens in a new tab)」の概念を導入しました。これは、b-moneyのアイデアとアダム・バックの計算的に困難なHashcashパズルを組み合わせて暗号資産の概念を作成するシステムでしたが、バックエンドとして信頼できるコンピューティングに依存していたため、再び理想には届きませんでした。2009年、サトシ・ナカモトによって初めて分散型通貨が実際に実装されました。これは、公開鍵暗号技術を通じて所有権を管理するための確立されたプリミティブと、誰がコインを所有しているかを追跡するための「プルーフ・オブ・ワーク (PoW)」として知られるコンセンサスアルゴリズムを組み合わせたものでした。

プルーフ・オブ・ワーク (PoW) の背後にあるメカニズムは、2つの問題を同時に解決したため、この分野における画期的な進歩でした。第一に、シンプルで適度に効果的なコンセンサスアルゴリズムを提供し、ネットワーク内のノードがビットコイン台帳の状態に対する一連の正規の更新について集合的に合意できるようにしました。第二に、コンセンサスプロセスへの自由な参加を許可するメカニズムを提供し、誰がコンセンサスに影響を与えるかを決定するという政治的問題を解決すると同時に、シビル攻撃を防ぎました。これは、特定のリストに一意のエンティティとして登録される要件などの参加に対する形式的な障壁を、経済的な障壁に置き換えることで実現しています。つまり、コンセンサスの投票プロセスにおける単一のノードの重みは、そのノードがもたらす計算能力に正比例します。それ以来、ノードの重みを計算リソースではなく通貨の保有量に比例して計算する、プルーフ・オブ・ステーク (PoS) と呼ばれる代替アプローチが提案されています。これら2つのアプローチの相対的なメリットについての議論はこのホワイトペーパーの範囲外ですが、どちらのアプローチも暗号資産のバックボーンとして機能するために使用できることに留意する必要があります。

状態遷移システムとしてのビットコイン

技術的な観点から見ると、ビットコインのような暗号資産の台帳は状態遷移システムと考えることができます。そこには、既存のすべてのビットコインの所有状況からなる「状態」と、状態とトランザクションを受け取り、その結果として新しい状態を出力する「状態遷移関数」が存在します。例えば、標準的な銀行システムでは、状態は貸借対照表であり、トランザクションはAからBへXドルを移動するリクエストであり、状態遷移関数はAのアカウントの値をXドル減らし、Bのアカウントの値をXドル増やします。そもそもAのアカウントにXドル未満しかない場合、状態遷移関数はエラーを返します。したがって、次のように正式に定義できます。

APPLY(S,TX) -> S' or ERROR

上記で定義された銀行システムでは、次のようになります。

APPLY({ Alice: $50, Bob: $50 },"send $20 from Alice to Bob") = { Alice: $30, Bob: $70 }

しかし、次のようになります。

APPLY({ Alice: $50, Bob: $50 },"send $70 from Alice to Bob") = ERROR

ビットコインにおける「状態」は、鋳造されてまだ消費されていないすべてのコイン（技術的には「未使用のトランザクション出力」またはUTXO）の集合であり、各UTXOには額面と所有者（本質的に暗号技術の公開鍵である20バイトのアドレスによって定義されます^fn1）があります。トランザクションには1つ以上の入力が含まれ、各入力には既存のUTXOへの参照と、所有者のアドレスに関連付けられた秘密鍵によって生成された暗号技術による署名が含まれます。また、1つ以上の出力が含まれ、各出力には状態に追加される新しいUTXOが含まれます。

状態遷移関数 APPLY(S,TX) -> S' は、大まかに次のように定義できます。

TX 内の各入力について：
- 参照されたUTXOが S にない場合、エラーを返す。
- 提供された署名がUTXOの所有者と一致しない場合、エラーを返す。
すべての入力UTXOの額面の合計が、すべての出力UTXOの額面の合計より小さい場合、エラーを返す。
すべての入力UTXOを削除し、すべての出力UTXOを追加した S を返す。

最初のステップの前半は、トランザクションの送信者が存在しないコインを消費するのを防ぎ、最初のステップの後半は、トランザクションの送信者が他人のコインを消費するのを防ぎます。そして、2番目のステップは価値の保存を強制します。これを支払いに使用するためのプロトコルは次のとおりです。アリスがボブに11.7 BTCを送金したいとします。まず、アリスは自分が所有する利用可能なUTXOのセットの中から、合計が少なくとも11.7 BTCになるものを探します。現実的には、アリスは正確に11.7 BTCを用意することはできないでしょう。例えば、彼女が用意できる最小の組み合わせが6+4+2=12だとします。次に、彼女はこれら3つの入力と2つの出力を持つトランザクションを作成します。最初の出力はボブのアドレスを所有者とする11.7 BTCであり、2番目の出力は残りの0.3 BTCの「お釣り」で、所有者はアリス自身になります。

マイニング

信頼できる中央集権的なサービスにアクセスできるのであれば、このシステムの実装は簡単です。中央集権的なサーバーのハードドライブを使用して状態を追跡し、説明したとおりに正確にコーディングするだけです。しかし、ビットコインでは分散型通貨システムを構築しようとしているため、誰もがトランザクションの順序に合意できるように、状態遷移システムとコンセンサスシステムを組み合わせる必要があります。ビットコインの分散型コンセンサスプロセスでは、ネットワーク内のノードが「ブロック」と呼ばれるトランザクションのパッケージを継続的に生成しようと試みる必要があります。ネットワークは、およそ10分ごとに1つのブロックを生成するように設計されており、各ブロックにはタイムスタンプ、ナンス、前のブロックへの参照（つまりハッシュ）、および前のブロック以降に発生したすべてのトランザクションのリストが含まれています。時間の経過とともに、これにより、ビットコイン台帳の最新の状態を表すために常に更新される、永続的で成長し続ける「ブロックチェーン」が作成されます。

このパラダイムで表現される、ブロックが有効かどうかを確認するアルゴリズムは次のとおりです。

ブロックによって参照されている前のブロックが存在し、有効であるかを確認する。
ブロックのタイムスタンプが前のブロックのタイムスタンプよりも大きく^fn2、かつ未来の2時間未満であるかを確認する。
ブロックのプルーフ・オブ・ワーク (PoW) が有効であるかを確認する。
S[0] を前のブロックの最後における状態とする。
TX を n 個のトランザクションを持つブロックのトランザクションリストとする。0...n-1 内のすべての i について、S[i+1] = APPLY(S[i],TX[i]) を設定する。いずれかの適用がエラーを返した場合、終了してfalseを返す。
trueを返し、S[n] をこのブロックの最後における状態として登録する。

基本的に、ブロック内の各トランザクションは、トランザクションが実行される前の正規の状態から何らかの新しい状態への有効な状態遷移を提供する必要があります。状態はブロック内にいかなる形でもエンコードされていないことに注意してください。これは純粋に検証ノードによって記憶される抽象概念であり、ジェネシス状態から開始し、すべてのブロック内のすべてのトランザクションを順番に適用することによってのみ、任意のブロックに対して（安全に）計算できます。さらに、マイナーがトランザクションをブロックに含める順序が重要であることに注意してください。ブロック内に2つのトランザクションAとBがあり、BがAによって作成されたUTXOを消費する場合、AがBの前にあればブロックは有効になりますが、そうでない場合は有効になりません。

上記のリストに存在する、他のシステムには見られない1つの有効性条件は、「プルーフ・オブ・ワーク (PoW)」の要件です。正確な条件は、256ビットの数値として扱われるすべてのブロックのダブルSHA-256ハッシュが、動的に調整されるターゲット（執筆時点では約2¹⁸⁷）よりも小さくなければならないということです。この目的は、ブロックの作成を計算的に「困難」にすることで、シビル攻撃者が自分たちに有利になるようにブロックチェーン全体を作り直すのを防ぐことです。SHA-256は完全に予測不可能な疑似ランダム関数として設計されているため、有効なブロックを作成する唯一の方法は、単なる試行錯誤であり、ナンスを繰り返しインクリメントして新しいハッシュが一致するかどうかを確認することです。

現在のターゲットである約2¹⁸⁷では、有効なブロックが見つかるまでに、ネットワークは平均して約2⁶⁹回の試行を行う必要があります。一般に、ターゲットは2016ブロックごとにネットワークによって再調整され、平均して10分ごとにネットワーク内のいずれかのノードによって新しいブロックが生成されるようになります。この計算作業に対してマイナーに報酬を支払うために、すべてのブロックのマイナーは、無から自分自身に25 BTCを与えるトランザクションを含める権利があります。さらに、トランザクションの入力の合計額面が出力の合計額面よりも大きい場合、その差額も「トランザクション手数料」としてマイナーに支払われます。ちなみに、これはBTCが発行される唯一のメカニズムでもあります。ジェネシス状態にはコインがまったく含まれていませんでした。

マイニングの目的をよりよく理解するために、悪意のある攻撃者が現れた場合に何が起こるかを調べてみましょう。ビットコインの基盤となる暗号技術は安全であることが知られているため、攻撃者はビットコインシステムの中で暗号技術によって直接保護されていない唯一の部分、つまりトランザクションの順序を標的にします。攻撃者の戦略はシンプルです。

何らかの製品（できれば即時配達されるデジタル商品）と引き換えに、商人に100 BTCを送金する。
製品の配達を待つ。
同じ100 BTCを自分自身に送金する別のトランザクションを生成する。
自分自身へのトランザクションが先に行われたものであるとネットワークに納得させようとする。

ステップ(1)が行われると、数分後にマイナーがそのトランザクションをブロック（例えばブロック番号270000）に含めます。約1時間後、そのブロックの後にさらに5つのブロックがチェーンに追加され、それらの各ブロックが間接的にトランザクションを指し示すことで、トランザクションが「確認」されます。この時点で、商人は支払いがファイナライズ済みであると受け入れ、製品を配達します。これがデジタル商品であると仮定しているため、配達は即座に行われます。ここで、攻撃者は100 BTCを自分自身に送金する別のトランザクションを作成します。攻撃者が単にそれを実際にネットワークへ放ったとしても、トランザクションは処理されません。マイナーは APPLY(S,TX) を実行しようとし、TX がもはや状態に存在しないUTXOを消費していることに気付くからです。そのため、攻撃者は代わりにブロックチェーンの「フォーク」を作成します。親として同じブロック269999を指し示しつつ、古いトランザクションの代わりに新しいトランザクションを含む、ブロック270000の別のバージョンをマイニングすることから始めます。ブロックデータが異なるため、これにはプルーフ・オブ・ワーク (PoW) をやり直す必要があります。さらに、攻撃者の新しいバージョンのブロック270000は異なるハッシュを持つため、元のブロック270001から270005はそれを「指し示し」ません。したがって、元のチェーンと攻撃者の新しいチェーンは完全に分離されます。フォークでは最も長いブロックチェーンが真実であると見なされるというルールがあるため、正当なマイナーは270005のチェーンで作業しますが、攻撃者だけは270000のチェーンで作業します。攻撃者が自分のブロックチェーンを最も長くするためには、追いつくためにネットワークの残りの部分を合わせたよりも多くの計算能力を持つ必要があります（これが「51%攻撃」と呼ばれる理由です）。

マークル・ツリー

左：ブランチの有効性の証明を提供するには、マークル・ツリー内の少数のノードを提示するだけで十分です。

右：マークル・ツリーの任意の部分を変更しようとする試みは、最終的にチェーンの上のどこかで不整合を引き起こします。

ビットコインの重要なスケーラビリティ機能は、ブロックがマルチレベルのデータ構造に保存されることです。ブロックの「ハッシュ」は、実際にはブロック・ヘッダーのハッシュにすぎません。ブロック・ヘッダーは、タイムスタンプ、ナンス、前のブロックのハッシュ、およびブロック内のすべてのトランザクションを保存するマークル・ツリーと呼ばれるデータ構造のルートハッシュを含む、約200バイトのデータです。マークル・ツリーは二分木の一種であり、基礎となるデータを含むツリーの最下部にある多数のリーフノードのセット、各ノードがその2つの子ノードのハッシュである中間ノードのセット、そして最後に、同じく2つの子ノードのハッシュから形成され、ツリーの「最上部」を表す単一のルートノードで構成されます。マークル・ツリーの目的は、ブロック内のデータを少しずつ配信できるようにすることです。ノードは、あるソースからブロックのヘッダーのみをダウンロードし、別のソースから自分に関連するツリーの小さな部分をダウンロードしても、すべてのデータが正しいことを確信できます。これが機能する理由は、ハッシュが上に向かって伝播するためです。悪意のあるユーザーがマークル・ツリーの最下部に偽のトランザクションをすり替えようとすると、この変更によって上のノードが変更され、さらにその上のノードが変更され、最終的にツリーのルートが変更されるため、ブロックのハッシュが変更されます。これにより、プロトコルはそれを完全に異なるブロックとして登録します（ほぼ確実に無効なプルーフ・オブ・ワーク (PoW) となります）。

マークル・ツリーのプロトコルは、長期的な持続可能性にとって間違いなく不可欠です。ビットコインネットワークの「フル・ノード」（すべてのブロックの全体を保存および処理するノード）は、2014年4月時点でビットコインネットワーク内で約15 GBのディスク容量を占有しており、月に1ギガバイト以上のペースで増加しています。現在、これは一部のデスクトップコンピュータでは実行可能ですが、スマートフォンでは実行できず、将来的には企業や愛好家だけが参加できるようになるでしょう。「簡易支払い検証（SPV）」として知られるプロトコルにより、「ライト・ノード」と呼ばれる別のクラスのノードが存在できるようになります。ライト・ノードは、ブロック・ヘッダーをダウンロードし、ブロック・ヘッダーのプルーフ・オブ・ワーク (PoW) を検証してから、自分に関連するトランザクションに関連付けられた「ブランチ」のみをダウンロードします。これにより、ライト・ノードは、ブロックチェーン全体のほんの一部のみをダウンロードしながら、強力なセキュリティ保証をもって、任意のビットコイントランザクションのステータスと現在の残高を判断できます。

代替のブロックチェーンアプリケーション

基盤となるブロックチェーンのアイデアを取り入れ、それを他の概念に適用するというアイデアにも長い歴史があります。2005年、ニック・サボは「所有者権限を持つ安全な財産権 (opens in a new tab)」という概念を発表しました。これは、「複製データベース技術の新たな進歩」によって、誰がどの土地を所有しているかのレジストリを保存するブロックチェーンベースのシステムが可能になり、ホームステッド、取得時効、ジョージア主義の地価税などの概念を含む精巧なフレームワークを作成する方法を説明した文書です。しかし、残念ながら当時は効果的な複製データベースシステムが利用できなかったため、このプロトコルが実際に実装されることはありませんでした。しかし、2009年以降、ビットコインの分散型コンセンサスが開発されると、多くの代替アプリケーションが急速に出現し始めました。

Namecoin - 2010年に作成されたNamecoin (opens in a new tab)は、分散型の名前登録データベースとして最もよく説明されます。Tor、ビットコイン、BitMessageなどの分散型プロトコルでは、他の人が対話できるようにアカウントを識別する何らかの方法が必要ですが、既存のすべてのソリューションで利用できる識別子は、1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy のような疑似ランダムハッシュのみです。理想的には、「george」のような名前のアカウントを持てるようにしたいところです。しかし問題は、ある人が「george」という名前のアカウントを作成できる場合、他の誰かも同じプロセスを使用して自分用に「george」を登録し、なりすますことができるということです。唯一の解決策は、最初の登録者が成功し、2番目の登録者が失敗するという先願主義のパラダイムであり、これはビットコインのコンセンサスプロトコルに完全に適した問題です。Namecoinは、このようなアイデアを使用した名前登録システムの最も古く、最も成功した実装です。
カラードコイン - カラードコイン (opens in a new tab)の目的は、人々が独自のデジタル通貨を作成できるようにするプロトコルとして機能することです。あるいは、1単位の通貨という重要かつ自明なケースにおいては、ビットコインのブロックチェーン上でデジタル・トークンを作成できるようにすることです。カラードコインのプロトコルでは、特定のビットコインUTXOに公に色を割り当てることで新しい通貨を「発行」します。そして、プロトコルは他のUTXOの色を、それらを作成したトランザクションが消費した入力の色と同じになるように再帰的に定義します（色が混ざった入力の場合はいくつかの特別なルールが適用されます）。これにより、ユーザーは特定の色を持つUTXOのみを含むウォレットを維持し、通常のビットコインと同じように送金することができます。また、ブロックチェーンを遡って、受け取ったUTXOの色を判断することができます。
メタコイン - メタコインの背後にあるアイデアは、ビットコインの上に存在するプロトコルを持つことです。ビットコイントランザクションを使用してメタコイントランザクションを保存しますが、異なる状態遷移関数 APPLY' を持ちます。メタコインのプロトコルは、無効なメタコイントランザクションがビットコインのブロックチェーンに現れるのを防ぐことができないため、APPLY'(S,TX) がエラーを返した場合、プロトコルはデフォルトで APPLY'(S,TX) = S になるというルールが追加されています。これにより、任意の暗号資産プロトコルを作成するための簡単なメカニズムが提供されます。ビットコイン自体の中では実装できない高度な機能を備えている可能性がありますが、マイニングやネットワーキングの複雑さはすでにビットコインプロトコルによって処理されているため、開発コストは非常に低くなります。メタコインは、一部のクラスの金融契約、名前登録、および分散型取引所を実装するために使用されてきました。

したがって、一般的に、コンセンサスプロトコルを構築するには2つのアプローチがあります。独立したネットワークを構築することと、ビットコインの上にプロトコルを構築することです。前者のアプローチは、Namecoinのようなアプリケーションの場合はかなり成功していますが、実装が困難です。個々の実装ごとに独立したブロックチェーンをブートストラップし、必要なすべての状態遷移とネットワーキングのコードを構築してテストする必要があります。さらに、分散型コンセンサス技術のアプリケーションのセットは、大多数のアプリケーションが独自のブロックチェーンを正当化するには小さすぎるというべき乗則分布に従うと予測しています。また、互いに対話する必要がある分散型アプリケーション、特に分散型自律組織の大きなクラスが存在することにも注目しています。

一方、ビットコインベースのアプローチには、ビットコインの簡易支払い検証機能を引き継がないという欠点があります。SPVがビットコインで機能するのは、ブロックチェーンの深さを有効性の代用として使用できるからです。ある時点で、トランザクションの祖先が十分に遡れば、それらが正当に状態の一部であったと安全に言えます。一方、ブロックチェーンベースのメタプロトコルは、独自のプロトコルのコンテキスト内で無効なトランザクションを含めないようにブロックチェーンに強制することはできません。したがって、完全に安全なSPVメタプロトコルの実装では、特定のトランザクションが有効かどうかを判断するために、ビットコインのブロックチェーンの最初まで後方スキャンする必要があります。現在、ビットコインベースのメタプロトコルのすべての「ライト」な実装は、データを提供するために信頼できるサーバーに依存しています。暗号資産の主な目的の1つが信頼の必要性を排除することであることを考えると、これは間違いなく非常に最適とは言えない結果です。

スクリプティング

拡張機能がなくても、ビットコインプロトコルは実際には「スマート・コントラクト」の概念の弱いバージョンを促進します。ビットコインのUTXOは、公開鍵だけでなく、シンプルなスタックベースのプログラミング言語で表現されたより複雑なスクリプトによっても所有できます。このパラダイムでは、そのUTXOを消費するトランザクションは、スクリプトを満たすデータを提供する必要があります。実際、基本的な公開鍵の所有権メカニズムでさえ、スクリプトを介して実装されています。スクリプトは楕円曲線署名を入力として受け取り、トランザクションおよびUTXOを所有するアドレスと照合して検証し、検証が成功した場合は1を、そうでない場合は0を返します。さまざまな追加のユースケースのために、他のより複雑なスクリプトが存在します。例えば、検証のために指定された3つの秘密鍵のうち2つからの署名を必要とするスクリプト（「マルチシグ」）を構築できます。これは、企業アカウント、安全な普通預金アカウント、および一部の商人のエスクロー状況に役立つ設定です。スクリプトは、計算問題の解決策に対する報奨金の支払いにも使用できます。また、「この額面のDogecoinトランザクションを私に送信したというSPV証明を提供できれば、このビットコインUTXOはあなたのものです」といった内容のスクリプトを構築することもでき、本質的に分散型のクロス暗号資産交換を可能にします。

しかし、ビットコインに実装されているスクリプト言語には、いくつかの重要な制限があります。

チューリング完全性の欠如 - つまり、ビットコインのスクリプト言語がサポートする計算の大きなサブセットは存在しますが、すべてをサポートしているわけではありません。欠けている主なカテゴリはループです。これは、トランザクションの検証中の無限ループを回避するために行われます。理論的には、if文を使用して基盤となるコードを何度も繰り返すだけで任意のループをシミュレートできるため、スクリプトプログラマーにとっては克服可能な障害ですが、スペース効率が非常に悪いスクリプトになります。例えば、代替の楕円曲線署名アルゴリズムを実装するには、おそらく256回の繰り返しの乗算ラウンドをすべて個別にコードに含める必要があります。
価値の盲目性 - UTXOスクリプトが引き出し可能な金額をきめ細かく制御する方法はありません。例えば、オラクル・コントラクトの強力なユースケースの1つはヘッジ契約です。AとBが1000ドル相当のBTCを投入し、30日後にスクリプトが1000ドル相当のBTCをAに送信し、残りをBに送信します。これには、1 BTCの米ドルでの価値を決定するオラクルが必要になりますが、それでも、現在利用可能な完全に中央集権的なソリューションと比較して、信頼とインフラストラクチャの要件の点で大幅な改善となります。しかし、UTXOは「すべてかゼロか」であるため、これを達成する唯一の方法は、さまざまな額面の多くのUTXO（例えば、最大30までの各kに対して2^kのUTXOを1つ）を持ち、オラクルにどのUTXOをAに送信し、どのUTXOをBに送信するかを選択させるという、非常に非効率的なハックを使用することです。
状態の欠如 - UTXOは消費されるか未消費であるかのいずれかです。マルチステージのコントラクトや、それ以上の内部状態を保持するスクリプトの機会はありません。これにより、マルチステージのオプション契約、分散型取引所のオファー、または2段階の暗号技術によるコミットメントプロトコル（安全な計算報奨金に必要）を作成することが困難になります。また、UTXOはシンプルで1回限りのコントラクトを構築するためにのみ使用でき、分散型組織などのより複雑な「ステートフル」なコントラクトには使用できないことを意味し、メタプロトコルの実装を困難にします。バイナリ状態と価値の盲目性が組み合わさることで、もう1つの重要なアプリケーションである引き出し制限も不可能になります。
ブロックチェーンの盲目性 - UTXOは、ナンス、タイムスタンプ、前のブロックのハッシュなどのブロックチェーンデータに対して盲目です。これにより、スクリプト言語から潜在的に価値のあるランダム性のソースが奪われ、ギャンブルやその他のいくつかのカテゴリのアプリケーションが厳しく制限されます。

したがって、暗号資産の上に高度なアプリケーションを構築するには、新しいブロックチェーンを構築する、ビットコインの上でスクリプティングを使用する、ビットコインの上にメタプロトコルを構築するという3つのアプローチがあります。新しいブロックチェーンを構築すると、機能セットの構築において無制限の自由が得られますが、開発時間、ブートストラップの労力、およびセキュリティが犠牲になります。スクリプティングの使用は実装と標準化が容易ですが、その機能は非常に限られており、メタプロトコルは容易ですが、スケーラビリティの欠陥に悩まされます。イーサリアムでは、開発の容易さにおいてさらに大きな利益をもたらし、さらに強力なライト・クライアントの特性を提供する代替フレームワークを構築すると同時に、アプリケーションが経済環境とブロックチェーンのセキュリティを共有できるようにすることを目指しています。

Ethereum

イーサリアムの目的は、分散型アプリケーション (dapp) を構築するための代替プロトコルを作成することです。これは、迅速な開発時間、小規模でめったに使用されないアプリケーションのセキュリティ、および異なるアプリケーションが非常に効率的に相互作用する能力が重要となる状況に特に重点を置き、大規模なクラスの分散型アプリケーションにとって非常に有用であると私たちが信じる、異なるトレードオフのセットを提供します。イーサリアムは、本質的に究極の抽象的な基盤レイヤーを構築することでこれを実現します。つまり、チューリング完全なプログラミング言語が組み込まれたブロックチェーンであり、誰でもスマート・コントラクトや分散型アプリケーションを作成し、所有権、トランザクションのフォーマット、状態遷移関数のための独自の任意のルールを作成できるようにします。Namecoinの最小限のバージョンは2行のコードで記述でき、通貨やレピュテーション・システムのような他のプロトコルは20行未満で構築できます。スマート・コントラクト（価値を含み、特定の条件が満たされた場合にのみロックを解除する暗号技術的な「箱」）もプラットフォーム上に構築でき、チューリング完全性、価値の認識、ブロックチェーンの認識、および状態という追加の能力により、ビットコインのスクリプトが提供するものよりもはるかに強力です。

Ethereum Accounts

イーサリアムでは、状態は「アカウント」と呼ばれるオブジェクトで構成されており、各アカウントは20バイトのアドレスを持ち、状態遷移はアカウント間の価値と情報の直接的な転送です。イーサリアムのアカウントには4つのフィールドが含まれます。

ナンス: 各トランザクションが1回だけ処理されることを保証するために使用されるカウンター
アカウントの現在のイーサ残高
アカウントのコントラクト・コード（存在する場合）
アカウントのストレージ（デフォルトでは空）

「イーサ」はイーサリアムの主要な内部の暗号燃料であり、トランザクション手数料の支払いに使用されます。一般的に、アカウントには2つのタイプがあります。秘密鍵によって制御される外部所有アカウントと、コントラクト・コードによって制御されるコントラクト・アカウントです。外部所有アカウントにはコードがなく、トランザクションを作成して署名することで、外部所有アカウントからメッセージを送信できます。コントラクト・アカウントでは、メッセージを受信するたびにそのコードがアクティブになり、内部ストレージの読み書きを行ったり、他のメッセージを送信したり、順番にコントラクトを作成したりすることができます。

イーサリアムにおける「コントラクト」は、「履行される」または「遵守される」べきものと見なすべきではないことに注意してください。むしろ、それらはイーサリアムの実行環境内に存在する「自律エージェント」のようなものであり、メッセージやトランザクションによって「つつかれた」ときに常に特定のコードを実行し、永続的な変数を追跡するために自身のイーサ残高と自身のキー/バリューストアを直接制御します。

Messages and Transactions

イーサリアムでは、「トランザクション」という用語は、外部所有アカウントから送信されるメッセージを格納する署名付きデータ・パッケージを指すために使用されます。トランザクションには以下が含まれます。

メッセージの受信者
送信者を識別する署名
送信者から受信者へ送金するイーサの量
オプションのデータ・フィールド
トランザクションの実行に許可される計算ステップの最大数を表す STARTGAS 値
送信者が計算ステップごとに支払う手数料を表す GASPRICE 値

最初の3つは、あらゆる暗号資産で期待される標準的なフィールドです。データ・フィールドはデフォルトでは機能を持ちませんが、仮想マシンにはコントラクトがデータにアクセスするために使用できるオペコードがあります。ユースケースの例として、コントラクトがオンチェーンのドメイン登録サービスとして機能している場合、渡されるデータに2つの「フィールド」が含まれていると解釈したい場合があります。最初のフィールドは登録するドメインであり、2番目のフィールドはそれを登録するIPアドレスです。コントラクトはメッセージ・データからこれらの値を読み取り、適切にストレージに配置します。

STARTGAS および GASPRICE フィールドは、イーサリアムのサービス拒否 (DoS) 攻撃対策モデルにとって重要です。コード内の偶発的または悪意のある無限ループやその他の計算上の無駄を防ぐために、各トランザクションは、コード実行の計算ステップをいくつ使用できるかの制限を設定する必要があります。計算の基本単位は「ガス」です。通常、1つの計算ステップには1ガスかかりますが、一部の操作は計算コストが高いため、または状態の一部として保存する必要があるデータの量を増やすため、より多くのガスがかかります。また、トランザクション・データの1バイトごとに5ガスの手数料がかかります。手数料システムの目的は、攻撃者が計算、帯域幅、ストレージなど、消費するすべてのリソースに比例して支払うことを要求することです。したがって、ネットワークがこれらのリソースのいずれかをより多く消費することにつながるトランザクションは、その増加分にほぼ比例したガス代を持たなければなりません。

Messages

コントラクトは、他のコントラクトに「メッセージ」を送信する機能を持ちます。メッセージは決してシリアライズされることのない仮想オブジェクトであり、イーサリアムの実行環境内にのみ存在します。メッセージには以下が含まれます。

メッセージの送信者（暗黙的）
メッセージの受信者
メッセージと共に送金されるイーサの量
オプションのデータ・フィールド
STARTGAS 値

本質的に、メッセージはトランザクションに似ていますが、外部アクターではなくコントラクトによって生成される点が異なります。メッセージは、現在コードを実行しているコントラクトが CALL オペコードを実行したときに生成され、これによりメッセージが生成および実行されます。トランザクションと同様に、メッセージは受信者のアカウントにそのコードを実行させます。したがって、コントラクトは、外部アクターとまったく同じ方法で他のコントラクトと関係を持つことができます。

トランザクションまたはコントラクトによって割り当てられたガスのアローワンスは、そのトランザクションおよびすべてのサブ実行によって消費される合計ガスに適用されることに注意してください。たとえば、外部アクターAが1000ガスでBにトランザクションを送信し、BがCにメッセージを送信する前に600ガスを消費し、Cの内部実行が戻る前に300ガスを消費した場合、Bはガス切れになる前にさらに100ガスを消費できます。

Ethereum State Transition Function

イーサリアムの状態遷移関数 APPLY(S,TX) -> S' は、次のように定義できます。

トランザクションが整形式であるか（つまり、正しい数の値を持っているか）、署名が有効であるか、およびナンスが送信者のアカウントのナンスと一致するかを確認します。そうでない場合は、エラーを返します。
トランザクション手数料を STARTGAS * GASPRICE として計算し、署名から送信元アドレスを決定します。送信者のアカウント残高から手数料を差し引き、送信者のナンスをインクリメントします。支払うのに十分な残高がない場合は、エラーを返します。
GAS = STARTGAS を初期化し、トランザクション内のバイトの支払いとして、バイトごとに一定量のガスを差し引きます。
トランザクションの価値を送信者のアカウントから受信者のアカウントに送金します。受信者のアカウントがまだ存在しない場合は、作成します。受信者のアカウントがコントラクトである場合、コントラクトのコードを完了するまで、または実行がガス切れになるまで実行します。
送信者に十分な資金がなかったために価値の送金が失敗した場合、またはコードの実行がガス切れになった場合は、手数料の支払いを除くすべての状態の変更をリバートし、手数料をマイナーのアカウントに追加します。
それ以外の場合は、残りのすべてのガスの手数料を送信者に返金し、消費されたガスに対して支払われた手数料をマイナーに送ります。

たとえば、コントラクトのコードが次のようになっているとします。

if !self.storage[calldataload(0)]:
  self.storage[calldataload(0)] = calldataload(32)

実際には、コントラクト・コードは低レベルのEVMコードで記述されていることに注意してください。この例は、わかりやすくするために当社の高レベル言語の1つであるSerpentで記述されており、EVMコードにコンパイルできます。コントラクトのストレージが空の状態で始まり、10イーサの価値、2000ガス、0.001イーサのガス価格、および64バイトのデータを持つトランザクションが送信されたとします。ここで、バイト0〜31は数値 2 を表し、バイト32〜63は文字列 CHARLIE を表します^fn3。この場合の状態遷移関数のプロセスは次のとおりです。

トランザクションが有効であり、整形式であることを確認します。
トランザクションの送信者が少なくとも 2000 * 0.001 = 2 イーサを持っていることを確認します。持っている場合は、送信者のアカウントから2イーサを差し引きます。
gas = 2000 を初期化します。トランザクションの長さが170バイトで、バイト手数料が5であると仮定し、850を差し引いて、残りのガスが1150になるようにします。
送信者のアカウントからさらに10イーサを差し引き、それをコントラクトのアカウントに追加します。
コードを実行します。この場合、これは単純です。インデックス 2 のコントラクトのストレージが使用されているかどうかを確認し、使用されていないことに気付くため、インデックス 2 のストレージを値 CHARLIE に設定します。これに187ガスかかると仮定すると、残りのガス量は 1150 - 187 = 963 になります。
963 * 0.001 = 0.963 イーサを送信者のアカウントに戻し、結果の状態を返します。

トランザクションの受信側にコントラクトがなかった場合、合計トランザクション手数料は、提供された GASPRICE にトランザクションの長さ（バイト単位）を掛けたものに等しくなり、トランザクションと共に送信されたデータは無関係になります。

メッセージはリバートの観点からトランザクションと同等に機能することに注意してください。メッセージの実行がガス切れになった場合、そのメッセージの実行、およびその実行によってトリガーされた他のすべての実行はリバートされますが、親の実行はリバートする必要はありません。これは、コントラクトが別のコントラクトを呼び出すことは「安全」であることを意味します。AがGガスでBを呼び出した場合、Aの実行は最大でもGガスを失うことが保証されるためです。最後に、コントラクトを作成するオペコード CREATE があることに注意してください。その実行メカニズムは一般的に CALL に似ていますが、実行の出力が新しく作成されたコントラクトのコードを決定するという例外があります。

Code Execution

イーサリアムのコントラクトのコードは、「イーサリアム仮想マシンコード」または「EVMコード」と呼ばれる、低レベルのスタックベースのバイトコード言語で記述されています。コードは一連のバイトで構成されており、各バイトは1つの操作を表します。一般に、コードの実行は無限ループであり、現在のプログラム・カウンター（ゼロから始まります）での操作を繰り返し実行し、コードの終端に達するか、エラー、または STOP や RETURN 命令が検出されるまで、プログラム・カウンターを1つずつインクリメントすることで構成されます。操作は、データを保存するための3種類のスペースにアクセスできます。

スタック: 値をプッシュおよびポップできる後入れ先出しのコンテナ
メモリ: 無限に拡張可能なバイト配列
コントラクトの長期的なストレージ: キー/バリューストア。計算終了後にリセットされるスタックやメモリとは異なり、ストレージは長期的に持続します。

コードは、受信メッセージの価値、送信者、データ、およびブロック・ヘッダーのデータにもアクセスでき、出力としてデータのバイト配列を返すこともできます。

EVMコードの正式な実行モデルは驚くほどシンプルです。イーサリアム仮想マシンが実行されている間、その完全な計算状態はタプル (block_state, transaction, message, code, memory, stack, pc, gas) によって定義できます。ここで、block_state はすべてのアカウントを含むグローバルな状態であり、残高とストレージが含まれます。実行の各ラウンドの開始時に、現在の命令は code の pc 番目のバイト（pc >= len(code) の場合は0）を取得することによって見つけられ、各命令はタプルにどのように影響するかという点で独自の定義を持っています。たとえば、ADD はスタックから2つのアイテムをポップしてそれらの合計をプッシュし、gas を1減らし、pc を1インクリメントします。また、SSTORE はスタックから上位2つのアイテムをポップし、最初のアイテムで指定されたインデックスのコントラクトのストレージに2番目のアイテムを挿入します。ジャストインタイム・コンパイルによってイーサリアム仮想マシンの実行を最適化する方法は多数ありますが、イーサリアムの基本的な実装は数百行のコードで行うことができます。

Blockchain and Mining

イーサリアムのブロックチェーンは、いくつかの違いはありますが、多くの点でビットコインのブロックチェーンに似ています。ブロックチェーンのアーキテクチャに関するイーサリアムとビットコインの主な違いは、ビットコインとは異なり、イーサリアムのブロックにはトランザクション・リストと最新の状態の両方のコピーが含まれていることです。それとは別に、ブロック番号と難易度という2つの他の値もブロックに保存されます。イーサリアムの基本的なブロック検証アルゴリズムは次のとおりです。

参照されている前のブロックが存在し、有効であるかを確認します。
ブロックのタイムスタンプが、参照されている前のブロックのタイムスタンプよりも大きく、未来の15分未満であることを確認します。
ブロック番号、難易度、トランザクション・ルート、アンクル・ルート、およびガス・リミット（イーサリアム固有のさまざまな低レベルの概念）が有効であることを確認します。
ブロックのプルーフ・オブ・ワーク (PoW) が有効であることを確認します。
S[0] を前のブロックの終了時の状態とします。
TX をブロックのトランザクション・リストとし、n 個のトランザクションがあるものとします。0...n-1 内のすべての i について、S[i+1] = APPLY(S[i],TX[i]) を設定します。いずれかのアプリケーションがエラーを返す場合、またはこの時点までにブロックで消費された合計ガスが GASLIMIT を超える場合は、エラーを返します。
S_FINAL を S[n] としますが、マイナーに支払われるブロック・リワードを追加します。
状態 S_FINAL のマークル・ツリーのルートが、ブロック・ヘッダーで提供される最終状態のルートと等しいかどうかを確認します。等しい場合、ブロックは有効です。そうでない場合、無効です。

このアプローチは、各ブロックで状態全体を保存する必要があるため、一見すると非常に非効率的に見えるかもしれませんが、実際には効率はビットコインと同等になるはずです。その理由は、状態がツリー構造で保存されており、各ブロックの後にツリーの小さな部分だけを変更すればよいためです。したがって、一般に、隣接する2つのブロック間でツリーの大部分は同じであるはずであり、そのためデータは1回保存され、ポインター（つまり、サブツリーのハッシュ）を使用して2回参照することができます。これを実現するために、「パトリシア・ツリー」として知られる特別な種類のツリーが使用されます。これには、ノードの変更だけでなく、挿入や削除も効率的に行えるようにするマークル・ツリーの概念の変更が含まれます。さらに、すべての状態情報は最後のブロックの一部であるため、ブロックチェーンの履歴全体を保存する必要はありません。この戦略をビットコインに適用できた場合、スペースを5〜20倍節約できると計算できます。

よくある質問は、物理的なハードウェアの観点から、コントラクト・コードが「どこで」実行されるかということです。これには簡単な答えがあります。コントラクト・コードを実行するプロセスは、ブロック検証アルゴリズムの一部である状態遷移関数の定義の一部です。したがって、トランザクションがブロック B に追加された場合、そのトランザクションによって生成されたコードの実行は、ブロック B をダウンロードして検証する現在および将来のすべてのノードによって実行されます。

アプリケーション

一般的に、イーサリアム上には3種類のアプリケーションが存在します。1つ目のカテゴリーは金融アプリケーションであり、ユーザーが自分のお金を使って管理したりコントラクトを結んだりするための、より強力な方法を提供します。これには、サブ通貨、金融デリバティブ、ヘッジ・コントラクト、貯蓄ウォレット、遺言、そして最終的には一部の本格的な雇用契約までもが含まれます。2つ目のカテゴリーは半金融アプリケーションです。これにはお金が関与しますが、行われることの非金銭的な側面も大きなウェイトを占めます。計算問題の解決に対する自己執行型の報奨金がその完璧な例です。最後に、オンライン投票や分散型ガバナンスなど、全く金融的ではないアプリケーションがあります。

トークン・システム

オンブロックチェーンのトークン・システムには、米ドルや金などの資産を表すサブ通貨から、企業株式、スマートプロパティを表す個別のトークン、安全で偽造不可能なクーポン、さらには従来の価値とは全く結びつかず、インセンティブ付与のためのポイントシステムとして使用されるトークン・システムまで、多くのアプリケーションがあります。トークン・システムは、イーサリアム上で驚くほど簡単に実装できます。理解すべき重要なポイントは、通貨やトークン・システムが根本的に何であるかというと、1つの操作を持つデータベースに過ぎないということです。その操作とは、「AからX単位を差し引き、BにX単位を与える」というものであり、(1) トランザクションの前にAが少なくともX単位を持っていたこと、および (2) トランザクションがAによって承認されていること、という条件が付きます。トークン・システムを実装するために必要なのは、このロジックをコントラクトに実装することだけです。

Serpentでトークン・システムを実装するための基本的なコードは以下のようになります。

def send(to, value):
  if self.storage[msg.sender] >= value:
    self.storage[msg.sender] = self.storage[msg.sender] - value
    self.storage[to] = self.storage[to] + value

これは本質的に、このドキュメントのさらに上で説明した「銀行システム」の状態遷移関数を文字通り実装したものです。そもそも通貨単位を分配する最初のステップや、その他のいくつかのエッジケースに対応するために、数行の追加コードが必要です。また、理想的には、他のコントラクトがアドレスの残高を照会できる機能を追加するべきです。しかし、必要なのはそれだけです。理論的には、サブ通貨として機能するイーサリアムベースのトークン・システムは、オンチェーンのビットコインベースのメタ通貨には欠けているもう1つの重要な機能、つまりその通貨で直接トランザクション手数料を支払う機能を含めることができる可能性があります。これを実装する方法としては、コントラクトがイーサの残高を維持し、それを使って送信者に手数料として支払われたイーサを返金します。そして、手数料として受け取った内部通貨単位を回収し、常時開催されるオークションで再販することで、この残高を補充します。したがって、ユーザーはイーサを使ってアカウントを「アクティベート」する必要がありますが、一度イーサがそこにあれば、コントラクトが毎回返金するため、再利用可能になります。

金融デリバティブと安定価値通貨

金融デリバティブは「スマート・コントラクト」の最も一般的なアプリケーションであり、コードで実装するのが最も簡単なものの1つです。金融コントラクトを実装する際の主な課題は、その大部分が外部の価格ティッカーへの参照を必要とすることです。例えば、非常に望ましいアプリケーションとして、米ドルに対するイーサ（または他の暗号資産）のボラティリティをヘッジするスマート・コントラクトがありますが、これを行うには、コントラクトがETH/USDの価値を知っている必要があります。これを行う最も簡単な方法は、特定の当事者（例：NASDAQ）によって維持される「データフィード」コントラクトを使用することです。これは、その当事者が必要に応じてコントラクトを更新できるように設計されており、他のコントラクトがそのコントラクトにメッセージを送信し、価格を提供する応答を受け取ることができるインターフェースを提供します。

その重要な要素が与えられれば、ヘッジ・コントラクトは以下のようになります。

当事者Aが1000イーサを入力するのを待つ。
当事者Bが1000イーサを入力するのを待つ。
データフィード・コントラクトに照会して計算された1000イーサの米ドル価値をストレージに記録する（これを$xとする）。
30日後、AまたはBがコントラクトを「再アクティベート」できるようにし、$x相当のイーサ（データフィード・コントラクトに再度照会して新しい価格を取得して計算）をAに送信し、残りをBに送信する。

このようなコントラクトは、暗号資産コマースにおいて大きな可能性を秘めています。暗号資産について指摘される主な問題の1つは、ボラティリティが高いという事実です。多くのユーザーや加盟店は、暗号資産を扱う際のセキュリティと利便性を求めているかもしれませんが、1日で資金の価値の23%を失うという見通しに直面することは望んでいないでしょう。これまで最も一般的に提案されてきた解決策は、発行者裏付け資産でした。これは、発行者が単位を発行および取り消す権利を持つサブ通貨を作成し、指定された原資産（金、米ドルなど）の1単位を（オフラインで）提供した人に、その通貨の1単位を提供するというアイデアです。その後、発行者は、暗号資産の1単位を送り返した人に、原資産の1単位を提供することを約束します。このメカニズムにより、発行者を信頼できるという条件付きで、あらゆる非暗号資産を暗号資産へと「引き上げる」ことができます。

しかし実際には、発行者が常に信頼できるとは限らず、場合によっては、そのようなサービスが存在するには銀行インフラが弱すぎるか、あるいは敵対的すぎることがあります。金融デリバティブは代替手段を提供します。ここでは、単一の発行者が資産を裏付ける資金を提供する代わりに、暗号資産の参照資産（例：ETH）の価格が上がると賭ける投機家の分散型市場がその役割を果たします。発行者とは異なり、ヘッジ・コントラクトが彼らの資金をエスクローに保持しているため、投機家には取引の義務を不履行にするという選択肢はありません。価格ティッカーを提供するために依然として信頼できるソースが必要であるため、このアプローチは完全に分散型ではないことに注意してください。しかし、インフラ要件の削減（発行者になるのとは異なり、プライス・フィードの発行にはライセンスが不要であり、おそらく言論の自由として分類できます）と詐欺の可能性の低減という点では、これでも間違いなく大幅な改善と言えます。

アイデンティティとレピュテーション・システム

最も初期の代替暗号資産であるNamecoin (opens in a new tab)は、ビットコインに似たブロックチェーンを使用して名前登録システムを提供しようと試みました。このシステムでは、ユーザーは他のデータとともに公開データベースに自分の名前を登録できます。挙げられている主なユースケースは、"bitcoin.org"（Namecoinの場合は"bitcoin.bit"）のようなドメイン名をIPアドレスにマッピングするDNS (opens in a new tab)システムです。その他のユースケースには、電子メール認証や、潜在的にはより高度なレピュテーション・システムが含まれます。イーサリアム上でNamecoinのような名前登録システムを提供するための基本的なコントラクトは以下の通りです。

def register(name, value):
  if !self.storage[name]:
    self.storage[name] = value

コントラクトは非常にシンプルです。それはイーサリアム・ネットワーク内にあるデータベースに過ぎず、追加はできますが、変更や削除はできません。誰でも何らかの値を持つ名前を登録でき、その登録は永遠に残ります。より洗練された名前登録コントラクトには、他のコントラクトがそれを照会できるようにする「関数句」や、名前の「所有者」（つまり最初の登録者）がデータを変更したり所有権を譲渡したりするためのメカニズムも備わっています。さらに、その上にレピュテーションやWeb of Trust（信用の輪）の機能を追加することもできます。

分散型ファイルストレージ

過去数年間で、Dropboxを筆頭に、人気のあるオンラインファイルストレージのスタートアップが多数登場しました。これらは、ユーザーがハードドライブのバックアップをアップロードし、月額料金と引き換えにサービスがそのバックアップを保存してユーザーがアクセスできるようにすることを目指しています。しかし、現時点ではファイルストレージ市場は比較的非効率的である場合があります。既存のさまざまなソリューションをざっと見てみると、特に無料枠もエンタープライズレベルの割引も適用されない20〜200GBの「不気味の谷」レベルでは、主流のファイルストレージの月額料金は、1ヶ月でハードドライブ全体のコスト以上の金額を支払うような設定になっています。イーサリアムのコントラクトは、分散型ファイルストレージ・エコシステムの開発を可能にします。そこでは、個々のユーザーが自分のハードドライブを貸し出すことで少額の資金を稼ぐことができ、未使用のスペースを利用してファイルストレージのコストをさらに引き下げることができます。

このような仕組みの重要な基盤となるのは、私たちが「分散型Dropboxコントラクト」と呼んでいるものです。このコントラクトは次のように機能します。まず、目的のデータをブロックに分割し、プライバシーのために各ブロックを暗号化して、そこからマークル・ツリーを構築します。次に、Nブロックごとに、コントラクトがマークル・ツリー内のランダムなインデックスを選択し（コントラクトのコードからアクセス可能な前のブロック・ハッシュをランダム性のソースとして使用）、ツリー内のその特定のインデックスにあるブロックの所有権を示す、簡易支払検証のような証明を伴うトランザクションを最初に提供したエンティティにXイーサを与える、というルールのコントラクトを作成します。ユーザーがファイルを再ダウンロードしたい場合は、マイクロペイメント・チャネル・プロトコル（例：32キロバイトごとに1サボを支払う）を使用してファイルを復元できます。手数料が最も効率的なアプローチは、支払者が最後までトランザクションを公開せず、代わりに32キロバイトごとに同じナンスを持つ少しだけ有利なトランザクションに置き換えることです。

このプロトコルの重要な特徴は、ファイルを忘れないように多くのランダムなノードを信頼しているように見えるかもしれませんが、秘密分散法によってファイルを多くの断片に分割し、各断片がまだどこかのノードに保持されているかをコントラクトで監視することで、そのリスクをほぼゼロに減らすことができる点です。コントラクトがまだ資金を支払っている場合、それは誰かがまだファイルを保存しているという暗号技術的な証明になります。

分散型自律組織

「分散型自律組織（DAO）」の一般的な概念は、特定のメンバーまたは株主のセットを持つ仮想エンティティであり、おそらく67%の過半数で、エンティティの資金を支出し、そのコードを変更する権利を持つというものです。メンバーは、組織が資金をどのように割り当てるべきかを共同で決定します。DAOの資金を割り当てる方法には、報奨金や給与から、労働に報いるための内部通貨のようなさらに風変わりなメカニズムまで、さまざまなものがあります。これは本質的に、伝統的な企業や非営利団体の法的な枠組みを再現するものですが、その執行には暗号技術を用いたブロックチェーン技術のみを使用します。これまでのところ、DAOに関する議論の多くは、配当を受け取る株主と取引可能な株式を持つ「分散型自律企業（DAC）」という「資本主義的」モデルを中心に行われてきました。おそらく「分散型自律コミュニティ」と表現される代替案では、すべてのメンバーが意思決定において平等なシェアを持ち、メンバーの追加または削除には既存のメンバーの67%の同意が必要になります。1人が1つのメンバーシップしか持てないという要件は、グループによって共同で強制される必要があります。

DAOをコーディングする方法の一般的な概要は以下の通りです。最もシンプルな設計は、メンバーの3分の2が変更に同意した場合に変更される、自己書き換えコードです。コードは理論的にはイミュータブルですが、コードの塊を別々のコントラクトに配置し、呼び出すべきコントラクトのアドレスを変更可能なストレージに保存することで、これを簡単に回避し、事実上の可変性を持たせることができます。このようなDAOコントラクトのシンプルな実装では、トランザクションで提供されるデータによって区別される3つのトランザクション・タイプが存在します。

[0,i,K,V]: ストレージ・インデックスKのアドレスを値Vに変更する、インデックスiの提案を登録する。
[1,i]: 提案iに賛成する投票を登録する。
[2,i]: 十分な投票が行われた場合、提案iをファイナライズする。

コントラクトには、これらのそれぞれに対する句が含まれます。すべての未解決のストレージ変更の記録と、誰がそれに投票したかのリストを維持します。また、すべてのメンバーのリストも保持します。いずれかのストレージ変更に対してメンバーの3分の2が投票すると、ファイナライズするトランザクションがその変更を実行できます。より洗練されたスケルトンには、トランザクションの送信、メンバーの追加、メンバーの削除などの機能に対する組み込みの投票機能もあり、リキッド・デモクラシー (opens in a new tab)スタイルの投票の委任（つまり、誰でも自分の代わりに投票する人を割り当てることができ、割り当ては推移的であるため、AがBを割り当て、BがCを割り当てた場合、CがAの投票を決定する）を提供する可能性さえあります。この設計により、DAOは分散型コミュニティとして有機的に成長することができ、最終的には誰がメンバーであるかをフィルタリングするタスクを専門家に委任できるようになります。ただし、「現在のシステム」とは異なり、個々のコミュニティメンバーが支持を変えるにつれて、専門家は時間の経過とともに簡単に現れたり消えたりする可能性があります。

代替モデルは分散型企業であり、任意のアカウントがゼロ以上の株式を持つことができ、意思決定には株式の3分の2が必要になります。完全なスケルトンには、資産管理機能、株式の売買のオファーを出す機能、およびオファーを受け入れる機能（できればコントラクト内に注文マッチングメカニズムを備えていること）が含まれます。委任もリキッド・デモクラシースタイルで存在し、「取締役会」の概念を一般化します。

その他のアプリケーション

1. 貯蓄ウォレット。アリスが自分の資金を安全に保管したいと考えているが、秘密鍵を紛失したり、誰かにハッキングされたりすることを心配しているとします。彼女は銀行であるボブとのコントラクトに、次のようにイーサを預けます。

アリス単独では、1日あたり最大1%の資金を引き出すことができる。
ボブ単独では、1日あたり最大1%の資金を引き出すことができるが、アリスは自分の鍵を使ってトランザクションを作成し、この機能を停止させることができる。
アリスとボブが協力すれば、全額を引き出すことができる。

通常、アリスにとっては1日1%で十分であり、アリスがさらに引き出したい場合は、ボブに連絡して助けを求めることができます。アリスの鍵がハッキングされた場合、彼女はボブのところに駆け込み、資金を新しいコントラクトに移動させます。彼女が鍵を紛失した場合、ボブが最終的に資金を引き出します。ボブが悪意を持っていることが判明した場合、彼女はボブの引き出し機能を停止させることができます。

2. 作物保険。価格指数の代わりに天候のデータフィードを使用して、金融デリバティブ・コントラクトを簡単に作成できます。アイオワ州の農家が、アイオワ州の降水量に反比例して支払いが行われるデリバティブを購入した場合、干ばつになれば農家は自動的にお金を受け取り、十分な雨が降れば作物がよく育つため農家は満足します。これは一般的に自然災害保険に拡張できます。

3. 分散型データフィード。差金決済取引の金融コントラクトの場合、実際には「SchellingCoin (opens in a new tab)」と呼ばれるプロトコルを介してデータフィードを分散化できる可能性があります。SchellingCoinは基本的に次のように機能します。N人の当事者全員が特定のデータ（例：ETH/USD価格）の値をシステムに入力し、値がソートされ、25パーセンタイルから75パーセンタイルの間にいる全員が報酬として1トークンを受け取ります。全員が、他の全員が提供するであろう答えを提供するインセンティブを持っており、多数のプレイヤーが現実的に合意できる唯一の値は、明白なデフォルト、つまり真実です。これにより、ETH/USD価格、ベルリンの気温、あるいは特定の困難な計算の結果など、理論的にあらゆる数の値を提供できる分散型プロトコルが作成されます。

4. スマート・マルチシグ・エスクロー。ビットコインでは、例えば指定された5つの鍵のうち3つで資金を支出できるようなマルチシグ・トランザクション・コントラクトが可能です。イーサリアムではより詳細な設定が可能です。例えば、5つのうち4つで全額を支出でき、5つのうち3つで1日あたり最大10%を支出でき、5つのうち2つで1日あたり最大0.5%を支出できる、といった具合です。さらに、イーサリアムのマルチシグは非同期です。2人の当事者が異なるタイミングでブロックチェーンに署名を登録でき、最後の署名によって自動的にトランザクションが送信されます。

5. クラウドコンピューティング。EVMテクノロジーは、検証可能なコンピューティング環境を作成するためにも使用できます。これにより、ユーザーは他の人に計算の実行を依頼し、その後オプションで、ランダムに選択された特定のチェックポイントでの計算が正しく行われたことの証明を求めることができます。これにより、あらゆるユーザーがデスクトップ、ラップトップ、または専用サーバーで参加できるクラウドコンピューティング市場の構築が可能になります。また、スポットチェックと保証金を組み合わせることで、システムが信頼できること（つまり、ノードが不正行為によって利益を得られないこと）を保証できます。ただし、このようなシステムはすべてのタスクに適しているわけではありません。例えば、高度なプロセス間通信を必要とするタスクは、ノードの大規模なクラウド上では簡単には実行できません。しかし、他のタスクははるかに簡単に並列化できます。SETI@home、folding@home、遺伝的アルゴリズムなどのプロジェクトは、このようなプラットフォーム上に簡単に実装できます。

6. ピア・ツー・ピア・ギャンブル。Frank StajanoとRichard ClaytonのCyberdice (opens in a new tab)など、任意の数のピア・ツー・ピア・ギャンブル・プロトコルをイーサリアム・ブロックチェーン上に実装できます。最もシンプルなギャンブル・プロトコルは、実際には次のブロック・ハッシュに関する差金決済コントラクトに過ぎません。そこからより高度なプロトコルを構築し、不正行為が不可能で手数料がほぼゼロのギャンブルサービスを作成できます。

7. 予測市場。オラクルまたはSchellingCoinが提供されれば、予測市場も簡単に実装できます。予測市場とSchellingCoinの組み合わせは、分散型組織のガバナンス・プロトコルとしてのフューターキー（futarchy） (opens in a new tab)の最初の主流アプリケーションになることが証明されるかもしれません。

8. オンチェーンの分散型マーケットプレイス（アイデンティティおよびレピュテーション・システムを基盤として使用）。

その他の事項と懸念点

修正版GHOSTの実装

「Greedy Heaviest Observed Subtree」(GHOST) プロトコルは、Yonatan SompolinskyとAviv Zoharによって2013年12月 (opens in a new tab)に初めて導入された革新的な技術です。GHOSTの背景にある動機は、確認時間が短いブロックチェーンは現在、高いステール（stale: 古い、無効な）率によるセキュリティ低下に悩まされているという点です。ブロックがネットワークを伝播（ブロック伝播）するのには一定の時間がかかるため、マイナーAがブロックをマイニングし、そのブロックがBに伝播する前にマイナーBが偶然別のブロックをマイニングした場合、マイナーBのブロックは無駄になり、ネットワークのセキュリティに貢献しません。さらに、中央集権化の問題もあります。マイナーAが30%のハッシュパワーを持つマイニングプールであり、Bが10%のハッシュパワーを持つ場合、Aは70%の確率でステールブロックを生成するリスクがあります（残りの30%はA自身が直前のブロックを生成したため、マイニングデータを即座に取得できるからです）。一方、Bは90%の確率でステールブロックを生成するリスクがあります。したがって、ステール率が高くなるほどブロック間隔が短い場合、Aはその規模の大きさだけで大幅に効率的になります。これら2つの影響が組み合わさることで、ブロックを高速に生成するブロックチェーンは、1つのマイニングプールがネットワークのハッシュパワーの大部分を占め、マイニングプロセスを事実上支配する結果を招く可能性が非常に高くなります。

SompolinskyとZoharが説明しているように、GHOSTは、どのチェーンが「最も長い」かを計算する際にステールブロックを含めることで、ネットワークセキュリティの低下という最初の問題を解決します。つまり、ブロックの親やさらに前の祖先だけでなく、ブロックの祖先のステールな子孫（イーサリアムの専門用語では「アンクル」）も、どのブロックが最大の総プルーフ・オブ・ワーク (PoW) に裏付けられているかの計算に追加されます。中央集権化の偏りという2つ目の問題を解決するために、私たちはSompolinskyとZoharが説明したプロトコルを一歩進め、ステールブロックにもブロック・リワードを提供します。ステールブロックは基本報酬の87.5%を受け取り、そのステールブロックを含めたネフュー（甥）が残りの12.5%を受け取ります。ただし、トランザクション手数料はアンクルには与えられません。

イーサリアムは、7レベルまでしか遡らない簡略化されたバージョンのGHOSTを実装しています。具体的には、次のように定義されています。

ブロックは親を指定しなければならず、0個以上のアンクルを指定しなければなりません。
ブロックBに含まれるアンクルは、以下の特性を持たなければなりません。
- Bのk世代前の祖先の直接の子でなければなりません。ここで、2 <= k <= 7です。
- Bの祖先であってはなりません。
- アンクルは有効なブロック・ヘッダーでなければなりませんが、以前に検証されたブロックや有効なブロックである必要はありません。
- アンクルは、以前のブロックに含まれるすべてのアンクル、および同じブロックに含まれる他のすべてのアンクルと異なっていなければなりません（二重包含の禁止）。
ブロックB内のすべてのアンクルUについて、Bのマイナーはコインベース報酬に3.125%が追加され、Uのマイナーは標準のコインベース報酬の93.75%を受け取ります。

アンクルを最大7世代までしか含めることができないこの限定版のGHOSTが使用されたのには、2つの理由があります。第一に、無制限のGHOSTでは、特定のブロックに対してどのアンクルが有効であるかを計算する際に、複雑さが大きくなりすぎます。第二に、イーサリアムで使用されているような補償を伴う無制限のGHOSTは、マイナーが公開攻撃者のチェーンではなくメインチェーンでマイニングを行うインセンティブを奪ってしまいます。

手数料

ブロックチェーンに公開されるすべてのトランザクションは、それをダウンロードして検証する必要があるというコストをネットワークに課すため、乱用を防ぐために、通常はトランザクション手数料を伴う何らかの規制メカニズムが必要です。ビットコインで使用されているデフォルトのアプローチは、純粋に任意の手数料を設け、マイナーがゲートキーパーとして機能し、動的な最小値を設定することに依存しています。このアプローチは、マイナーとトランザクション送信者の間の需要と供給によって価格が決定される「市場ベース」であるという理由から、ビットコインコミュニティで非常に好意的に受け入れられています。しかし、この推論の問題点は、トランザクション処理が市場ではないということです。トランザクション処理をマイナーが送信者に提供するサービスと解釈するのは直感的に魅力的ですが、実際にはマイナーが含めるすべてのトランザクションはネットワーク内のすべてのノードによって処理される必要があるため、トランザクション処理のコストの大部分は、それを含めるかどうかを決定するマイナーではなく、第三者によって負担されます。したがって、コモンズの悲劇の問題が非常に発生しやすくなります。

しかし、市場ベースのメカニズムにおけるこの欠陥は、特定の不正確な単純化の仮定を与えられた場合、魔法のように相殺されることが判明しています。その議論は以下の通りです。次のように仮定します。

トランザクションは k 個の操作を引き起こし、それを含めるマイナーに kR の報酬を提供します。ここで、R は送信者によって設定され、k と R は事前にマイナーから（大まかに）見えています。
1つの操作は、どのノードにとっても C の処理コストがかかります（つまり、すべてのノードは等しい効率を持ちます）。
N 個のマイニングノードがあり、それぞれが完全に等しい処理能力を持っています（つまり、全体の 1/N）。
マイニングを行わないフル・ノードは存在しません。

マイナーは、期待される報酬がコストを上回る場合、トランザクションを処理しようとします。したがって、マイナーが次のブロックを処理する確率は 1/N であるため、期待される報酬は kR/N となり、マイナーの処理コストは単に kC となります。したがって、マイナーは kR/N > kC、つまり R > NC となるトランザクションを含めます。ここで、R は送信者が提供する操作ごとの手数料であり、したがって送信者がトランザクションから得る利益の下限となります。また、NC は、操作を処理するためのネットワーク全体にかかるコストです。したがって、マイナーは、全体的な功利主義的利益がコストを上回るトランザクションのみを含めるインセンティブを持ちます。

しかし、現実にはこれらの仮定からいくつかの重要な逸脱があります。

追加の検証時間がブロック伝播を遅らせ、その結果ブロックがステールになる可能性が高まるため、マイナーは他の検証ノードよりもトランザクションを処理するために高いコストを支払います。
マイニングを行わないフル・ノードが存在します。
マイニング能力の分布は、実際には極端に不平等になる可能性があります。
ネットワークに害を及ぼすことを効用関数に含む投機家、政治的敵対者、狂信者が存在し、彼らは他の検証ノードが支払うコストよりもはるかに低いコストで済むようなコントラクトを巧妙に設定することができます。

(1) はマイナーが含めるトランザクションを少なくする傾向をもたらし、 (2) は NC を増加させます。したがって、これら2つの影響は少なくとも部分的に互いに相殺されます。^{どのように？ (opens in a new tab)} (3) と (4) が主要な問題です。これらを解決するために、私たちは単に変動上限を設けます。どのブロックも、長期指数移動平均の BLK_LIMIT_FACTOR 倍を超える操作を持つことはできません。具体的には以下の通りです。

blk.oplimit = floor((blk.parent.oplimit \* (EMAFACTOR - 1) +
floor(parent.opcount \* BLK\_LIMIT\_FACTOR)) / EMA\_FACTOR)

BLK_LIMIT_FACTOR と EMA_FACTOR は当面の間65536と1.5に設定される定数ですが、さらなる分析の後に変更される可能性があります。

ビットコインにおいて大きなブロックサイズを抑制するもう1つの要因があります。大きなブロックは伝播に時間がかかるため、ステールになる確率が高くなります。イーサリアムでは、ガスを大量に消費するブロックも、物理的に大きいことと、検証のためのトランザクション状態遷移の処理に時間がかかることの両方の理由から、伝播に時間がかかる可能性があります。この遅延による抑制はビットコインでは重要な考慮事項ですが、イーサリアムではGHOSTプロトコルがあるためそれほど重要ではありません。したがって、規制されたブロック制限に依存する方が、より安定したベースラインを提供します。

計算とチューリング完全性

重要な点は、イーサリアム仮想マシン（EVM）がチューリング完全であるということです。これは、EVMコードが無限ループを含む、考え得るあらゆる計算をエンコードできることを意味します。EVMコードでは、2つの方法でループが可能です。1つ目は、プログラムがコード内の前の場所に戻ることを可能にする JUMP 命令と、条件付きジャンプを行う JUMPI 命令があり、while x < 27: x = x * 2 のようなステートメントを可能にします。2つ目は、コントラクトが他のコントラクトを呼び出すことができるため、再帰によるループが可能になる可能性があることです。これは当然、ある問題を引き起こします。悪意のあるユーザーが、マイナーやフル・ノードを無限ループに強制的に陥らせることで、実質的にシャットダウンさせることができるのではないか、という問題です。この問題は、コンピュータサイエンスにおいて停止性問題として知られる問題に起因しています。一般的なケースにおいて、与えられたプログラムがいつか停止するかどうかを判断する方法はありません。

状態遷移のセクションで説明したように、私たちの解決策は、トランザクションに許容される計算ステップの最大数を設定することを要求し、実行にそれ以上の時間がかかる場合は計算がリバートされますが、手数料は支払われるという仕組みで機能します。メッセージも同じように機能します。私たちの解決策の背景にある動機を示すために、以下の例を考えてみましょう。

攻撃者が無限ループを実行するコントラクトを作成し、そのループをアクティブにするトランザクションをマイナーに送信します。マイナーはトランザクションを処理して無限ループを実行し、ガスがなくなるのを待ちます。実行中にガスがなくなり途中で停止したとしても、トランザクションは依然として有効であり、マイナーは各計算ステップに対して攻撃者から手数料を請求します。
攻撃者が、計算が終了するまでにさらにいくつかのブロックが生成され、マイナーが手数料を請求するためにトランザクションを含めることができなくなるほど長い時間、マイナーに計算を続けさせることを意図して、非常に長い無限ループを作成します。しかし、攻撃者は実行可能な計算ステップ数を制限する STARTGAS の値を提出することが求められるため、マイナーは計算に過度に多くのステップがかかることを事前に知ることができます。
攻撃者が send(A,contract.storage[A]); contract.storage[A] = 0 のような形式のコードを持つコントラクトを見つけ、最初のステップを実行するには十分だが2番目のステップを実行するには不十分なガス（つまり、引き出しは行うが残高は減らさない）を付けてトランザクションを送信します。実行が途中で停止した場合、変更はリバートされるため、コントラクトの作成者はこのような攻撃から保護することを心配する必要はありません。
金融コントラクトは、リスクを最小限に抑えるために、9つの独自のデータフィードの中央値を取ることで機能します。攻撃者がデータフィードの1つを乗っ取ります。このデータフィードは、DAOのセクションで説明されている可変アドレス呼び出しメカニズムを介して変更可能に設計されており、それを無限ループを実行するように変換し、金融コントラクトから資金を請求しようとする試みをガス切れに追い込もうとします。しかし、金融コントラクトはメッセージにガス・リミットを設定することで、この問題を防ぐことができます。

チューリング完全性の代替案はチューリング不完全性であり、そこでは JUMP と JUMPI は存在せず、任意の時点でコールスタック内に各コントラクトのコピーが1つだけ存在することが許可されます。このシステムでは、コントラクトの実行コストはそのサイズによって上限が定められるため、説明した手数料システムや私たちの解決策の有効性に関する不確実性は必要ないかもしれません。さらに、チューリング不完全性はそれほど大きな制限でもありません。私たちが内部で考案したすべてのコントラクトの例のうち、これまでのところループを必要としたのは1つだけであり、そのループでさえ、1行のコードを26回繰り返すことで取り除くことができました。チューリング完全性の深刻な影響と限られた利点を考慮すると、なぜ単にチューリング不完全な言語にしないのでしょうか？しかし現実には、チューリング不完全性は問題に対するすっきりとした解決策には程遠いものです。その理由を理解するために、以下のコントラクトを考えてみましょう。

C0: call(C1); call(C1);
C1: call(C2); call(C2);
C2: call(C3); call(C3);
...
C49: call(C50); call(C50);
C50: (run one step of a program and record the change in storage)

ここで、Aにトランザクションを送信します。このようにして、51回のトランザクションで、2⁵⁰の計算ステップを消費するコントラクトが完成します。マイナーは、各コントラクトにそれが取ることができる計算ステップの最大数を指定する値を保持し、他のコントラクトを再帰的に呼び出すコントラクトについてこれを計算することで、このような論理爆弾を事前に検出しようと試みることができます。しかし、そのためにはマイナーが他のコントラクトを作成するコントラクトを禁止する必要があります（上記の26個のコントラクトすべての作成と実行は、簡単に1つのコントラクトにまとめることができるためです）。もう1つの問題点は、メッセージのアドレスフィールドが変数であるため、一般的に、特定のコントラクトがどの他のコントラクトを呼び出すかを事前に知ることさえ不可能かもしれないということです。したがって、全体として、私たちは驚くべき結論に達します。チューリング完全性は驚くほど管理が容易であり、チューリング不完全性の欠如は、まったく同じ制御が導入されていない限り、同様に驚くほど管理が困難です。しかし、その場合、なぜプロトコルをチューリング完全にしないのでしょうか？

通貨と発行

イーサリアムネットワークには、独自の組み込み通貨であるイーサが含まれています。これは、さまざまな種類のデジタル資産間の効率的な交換を可能にする主要な流動性レイヤーを提供するという目的と、さらに重要なことに、トランザクション手数料を支払うためのメカニズムを提供するという二重の目的を果たします。利便性のため、また将来の議論を避けるため（ビットコインにおける現在のmBTC/uBTC/satoshiの議論を参照）、単位にはあらかじめラベルが付けられます。

1: Wei
10¹²: サボ
10¹⁵: フィニー
10¹⁸: イーサ

これは、「ドル」と「セント」、または「BTC」と「satoshi」の概念の拡張版と捉えるべきです。近い将来、「イーサ」は通常のトランザクションに、「フィニー」はマイクロトランザクションに、「サボ」と「Wei」は手数料やプロトコル実装に関する技術的な議論に使用されると予想しています。残りの単位は後で役立つようになるかもしれませんが、現時点ではクライアントに含めるべきではありません。

発行モデルは以下のようになります。

イーサは、1 BTCあたり1000〜2000イーサの価格で通貨販売（プレセール）でリリースされます。これは、イーサリアム組織に資金を提供し、開発費を支払うことを目的としたメカニズムであり、MastercoinやNXTなどの他のプラットフォームで成功裏に使用されています。早期の購入者はより大きな割引の恩恵を受けます。販売から受け取ったBTCは、開発者への給与や報奨金の支払いに全額使用され、イーサリアムおよび暗号資産エコシステム内のさまざまな営利および非営利プロジェクトに投資されます。
販売総額の0.099倍（60102216 ETH）が組織に割り当てられ、初期の貢献者への報酬や、ジェネシス・ブロック前のETH建ての経費の支払いに充てられます。
販売総額の0.099倍が長期準備金として維持されます。
その時点以降、販売総額の0.26倍が毎年永久にマイナーに割り当てられます。

グループ	ローンチ時	1年後	5年後
通貨単位	1.198X	1.458X	2.498X
購入者	83.5%	68.6%	40.0%
プレセール前に消費された準備金	8.26%	6.79%	3.96%
プレセール後に使用される準備金	8.26%	6.79%	3.96%
マイナー	0%	17.8%	52.0%

長期的な供給成長率（パーセント）

線形な通貨発行にもかかわらず、ビットコインと同様に、時間の経過とともに供給成長率はゼロに近づきます。

上記のモデルにおける2つの主な選択肢は、（1）寄付金プールの存在とその規模、および（2）ビットコインのような上限のある供給とは対照的な、永続的に成長する線形供給の存在です。寄付金プールの正当性は以下の通りです。寄付金プールが存在せず、同じインフレ率を提供するために線形発行が0.217倍に減少した場合、イーサの総量は16.5%少なくなり、各単位の価値は19.8%高くなります。したがって、均衡状態では販売で19.8%多くのイーサが購入されるため、各単位は再び以前とまったく同じ価値になります。組織はまた、1.198倍のBTCを持つことになります。これは、元のBTCと追加の0.198倍の2つの部分に分割されていると考えることができます。したがって、この状況は寄付金と_完全に同等_ですが、1つ重要な違いがあります。組織は純粋にBTCを保持しているため、イーサ単位の価値をサポートするインセンティブが働かないということです。

永続的な線形供給成長モデルは、一部の人々がビットコインにおける過度の富の集中と見なすリスクを軽減し、現在および未来の時代に生きる個人に通貨単位を獲得する公平な機会を与えます。同時に、パーセンテージとしての「供給成長率」は時間の経過とともにゼロに近づくため、イーサを取得して保持する強力なインセンティブを維持します。また、不注意や死亡などによりコインは時間の経過とともに常に失われ、コインの損失は年間総供給量のパーセンテージとしてモデル化できるため、流通している総通貨供給量は、実際には最終的に年間発行量を損失率で割った値で安定すると理論付けています（たとえば、損失率が1%の場合、供給量が26Xに達すると、毎年0.26Xがマイニングされ、0.26Xが失われ、均衡が生まれます）。

将来的には、イーサリアムはセキュリティのためにプルーフ・オブ・ステーク (PoS) モデルに移行し、発行要件が年間ゼロから0.05Xの間に減少する可能性が高いことに注意してください。イーサリアム組織が資金を失ったり、その他の理由で消滅したりした場合に備えて、私たちは「社会契約」を開かれたままにしておきます。誰でもイーサリアムの将来の候補バージョンを作成する権利があります。唯一の条件は、イーサの量が最大でも 60102216 * (1.198 + 0.26 * n) に等しくなければならないということです。ここで、n はジェネシス・ブロックからの年数です。作成者は、PoS主導の供給拡大と許容される最大供給拡大との差額の一部または全部を、開発費を支払うためにクラウドセールしたり、その他の方法で割り当てたりする自由があります。社会契約に準拠していない候補アップグレードは、正当な理由で準拠バージョンにフォークされる可能性があります。

マイニングの中央集権化

ビットコインのマイニングアルゴリズムは、マイナーがブロック・ヘッダーのわずかに変更されたバージョンに対してSHA-256を何百万回も繰り返し計算し、最終的に1つのノードがターゲット（現在は約2¹⁹²）よりも小さいハッシュを持つバージョンを見つけることで機能します。しかし、このマイニングアルゴリズムは2つの形態の中央集権化に対して脆弱です。第一に、マイニングエコシステムはASIC（特定用途向け集積回路）によって支配されるようになりました。これは、ビットコインのマイニングという特定のタスクのために設計されたコンピュータチップであり、そのため数千倍も効率的です。これは、ビットコインのマイニングがもはや高度に分散化された平等な追求ではなくなり、効果的に参加するには数百万ドルの資本が必要であることを意味します。第二に、ほとんどのビットコインマイナーは実際にはローカルでブロック検証を行っていません。代わりに、ブロック・ヘッダーを提供するために中央集権的なマイニングプールに依存しています。この問題は間違いなくさらに深刻です。この記事の執筆時点では、上位3つのマイニングプールがビットコインネットワークの処理能力の約50%を間接的に制御しています。ただし、プールや連合が51%攻撃を試みた場合、マイナーは他のマイニングプールに切り替えることができるという事実によって、これは緩和されています。

イーサリアムにおける現在のインテントは、マイナーが状態からランダムなデータを取得し、ブロックチェーンの過去N個のブロックからランダムに選択されたいくつかのトランザクションを計算し、その結果のハッシュを返すことが要求されるマイニングアルゴリズムを使用することです。これには2つの重要な利点があります。第一に、イーサリアムのコントラクトにはあらゆる種類の計算を含めることができるため、イーサリアムのASICは本質的に汎用計算用のASIC、つまりより優れたCPUになります。第二に、マイニングにはブロックチェーン全体へのアクセスが必要であり、マイナーはブロックチェーン全体を保存し、少なくともすべてのトランザクションを検証できる能力を持つことが強制されます。これにより、中央集権的なマイニングプールの必要性がなくなります。マイニングプールは依然として報酬分配のランダム性を平準化するという正当な役割を果たすことができますが、この機能は中央制御のないピア・ツー・ピアのプールでも同様に十分に果たすことができます。

このモデルはテストされておらず、コントラクトの実行をマイニングアルゴリズムとして使用する際に、特定の巧妙な最適化を回避する過程で困難が生じる可能性があります。しかし、このアルゴリズムの特に興味深い特徴の1つは、特定のASICを妨害するために特別に設計された多数のコントラクトをブロックチェーンに導入することで、誰でも「井戸に毒を入れる」ことができる点です。ASICメーカーには、互いを攻撃するためにこのようなトリックを使用する経済的インセンティブが存在します。したがって、私たちが開発している解決策は、純粋に技術的なものではなく、最終的には適応性のある経済的・人間的な解決策なのです。

スケーラビリティ

イーサリアムに関する一般的な懸念の1つは、スケーラビリティの問題です。ビットコインと同様に、イーサリアムもすべてのトランザクションがネットワーク内のすべてのノードによって処理される必要があるという欠陥を抱えています。ビットコインの場合、現在のブロックチェーンのサイズは約15 GBであり、1時間に約1 MBずつ増加しています。もしビットコインネットワークがVisaの毎秒2000件のトランザクションを処理するとしたら、3秒ごとに1 MB（1時間に1 GB、1年に8 TB）増加することになります。イーサリアムも同様の成長パターンに苦しむ可能性が高いです。ビットコインのように単なる通貨ではなく、イーサリアムのブロックチェーン上には多くのアプリケーションが存在するという事実によって悪化しますが、イーサリアムのフル・ノードはブロックチェーンの履歴全体ではなく状態のみを保存すればよいという事実によって改善されます。

このような巨大なブロックチェーンサイズの問題は、中央集権化のリスクです。ブロックチェーンのサイズがたとえば100 TBに増加した場合、ごく少数の大企業のみがフル・ノードを実行し、すべての一般ユーザーは軽量なSPVノードを使用するというシナリオが考えられます。そのような状況では、フル・ノードが結託し、何らかの利益をもたらす方法（たとえば、ブロック・リワードの変更や、自分たちにBTCを与えるなど）で不正を行うことに全員が同意する可能性があるという懸念が生じます。ライト・ノードは、これを即座に検出する方法がありません。もちろん、少なくとも1つの誠実なフル・ノードが存在する可能性が高く、数時間後にはレディットのようなチャネルを通じて不正に関する情報が漏れ出るでしょう。しかし、その時点では手遅れです。該当するブロックをブラックリストに登録する取り組みを組織するのは一般ユーザーの責任となりますが、これは成功した51%攻撃をやってのけるのと同じ規模の、大規模で実現不可能な調整問題です。ビットコインの場合、これは現在問題となっていますが、この問題を軽減する、Peter Toddによって提案された (opens in a new tab)ブロックチェーンの変更が存在します。

短期的には、イーサリアムはこの問題に対処するために2つの追加戦略を使用します。第一に、ブロックチェーンベースのマイニングアルゴリズムにより、少なくともすべてのマイナーはフル・ノードになることを強制され、フル・ノードの数の下限が作成されます。第二に、そしてより重要なことですが、各トランザクションを処理した後に、中間状態ツリーのルートをブロックチェーンに含めます。ブロック検証が中央集権化されていたとしても、誠実な検証ノードが1つでも存在する限り、検証プロトコルを通じて中央集権化の問題を回避することができます。マイナーが無効なブロックを公開した場合、そのブロックはフォーマットが正しくないか、状態 S[n] が間違っているかのいずれかです。S[0] が正しいことがわかっているため、S[i-1] が正しく、S[i] が間違っている最初の状態が必ず存在します。検証ノードは、インデックス i とともに、APPLY(S[i-1],TX[i]) -> S[i] を処理するために必要なパトリシアツリーノードのサブセットで構成される「無効性の証明」を提供します。ノードはこれらのノードを使用して計算のその部分を実行し、生成された S[i] が提供された S[i] と一致しないことを確認できます。

もう1つのより洗練された攻撃は、悪意のあるマイナーが不完全なブロックを公開し、ブロックが有効かどうかを判断するための完全な情報すら存在しないようにすることです。これに対する解決策は、チャレンジ・レスポンス・プロトコルです。検証ノードはターゲットトランザクションインデックスの形式で「チャレンジ」を発行し、ノードを受信すると、ライト・ノードは、マイナーであれ別の検証者であれ、別のノードが有効性の証明としてパトリシアノードのサブセットを提供するまで、そのブロックを信頼できないものとして扱います。

結論

イーサリアムのプロトコルは当初、暗号資産のアップグレード版として考案され、非常に汎用性の高いプログラミング言語を通じて、ブロックチェーン上のエスクロー、引き出し制限、金融コントラクト、ギャンブル市場などの高度な機能を提供するものでした。イーサリアムのプロトコルは、どのアプリケーションも直接「サポート」するわけではありませんが、チューリング完全なプログラミング言語が存在するということは、あらゆるトランザクション・タイプやアプリケーションに対して、理論上任意のコントラクトを作成できることを意味します。しかし、イーサリアムのさらに興味深い点は、イーサリアムのプロトコルが単なる通貨の枠をはるかに超えているということです。分散型ファイル・ストレージ、分散型コンピューティング、分散型予測市場に関するプロトコルは、その他数十の同様の概念とともに、コンピュータ産業の効率を大幅に向上させる可能性を秘めており、初めて経済的レイヤーを追加することで、他のピア・ツー・ピア・プロトコルを強力に後押しします。最後に、お金とは全く関係のないアプリケーションも数多く存在します。

イーサリアムのプロトコルによって実装されている任意の状態遷移関数という概念は、独自の可能性を持つプラットフォームを提供します。データ・ストレージ、ギャンブル、金融などの特定のアプリケーション群を意図した閉鎖的で単一目的のプロトコルではなく、イーサリアムは設計上オープンエンドであり、今後数年間にわたり、金融および非金融の両方の非常に多くのプロトコルの基盤レイヤーとして機能するのに非常に適していると私たちは信じています。

注釈および参考文献

注釈

詳しい読者であれば、ビットコインのアドレスは実際には楕円曲線公開鍵のハッシュであり、公開鍵そのものではないことに気づくかもしれません。しかし、公開鍵ハッシュを公開鍵そのものと呼ぶことは、暗号学の用語として完全に正当です。なぜなら、ビットコインの暗号技術はカスタムのデジタル署名アルゴリズムと見なすことができるからです。このアルゴリズムでは、公開鍵はECC公開鍵のハッシュで構成され、署名はECC公開鍵とECC署名を連結したもので構成されます。そして検証アルゴリズムでは、署名内のECC公開鍵を公開鍵として提供されたECC公開鍵ハッシュと照合し、その後ECC署名をECC公開鍵に対して検証します。
厳密には、過去11ブロックの中央値です。
内部的には、2と"CHARLIE"はどちらも数値であり、後者はビッグ・エンディアンの256進数表現です。数値は最小で0、最大で2²⁵⁶-1になります。

参考文献

ホワイトペーパーの歴史については、こちらのWiki (opens in a new tab)をご覧ください。

イーサリアムは、多くのコミュニティ主導のオープンソース・ソフトウェア・プロジェクトと同様に、初期の構想から進化してきました。イーサリアムの最新の開発状況や、プロトコルへの変更がどのように行われるかについては、こちらのガイドをお勧めします。