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

これは、2015年にプロジェクトが開始する前にイーサリアム創始者のVitalik Buterinにより2014年に公表されたホワイトペーパーです。コミュニティ主導の他のオープンソースソフトウェアプロジェクト同様、イーサリアムが、初期の創設時から進歩を遂げてきたことは注目に値します。

数年前のものですが、イーサリアムとそのビジョンに関する、正確かつ有用な参照情報となるため、本書を維持しています。イーサリアムの最新の開発や、プロトコルへの変更がどのように行われているかを学ぶには、こちらのガイドを参照してください。

ホワイトペーパー [2014年12月版] の履歴版または正規版をお求めの研究者・学術関係者の方は、こちらのPDFをご利用ください。

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

2009年にサトシ・ナカモトが開発したビットコインは、貨幣と通貨の画期的な発展として、これまでに多くの賞賛を受けてきました。後ろ盾や本質的な価値(opens in a new tab)を持たず、中央集権的な発行機関や管理者が不要なデジタル資産の先例となりました。しかし、ビットコインの試みにおいて、間違いなくより重要になる部分は、分散型コンセンサスのツールとしての基盤となるブロックチェーン技術であり、この側面に注目が急速に移り始めています。ブロックチェーン技術の別のアプリケーションとしてよく挙げられるものとしては、独自通貨や金融商品(カラードコイン(opens in a new tab))、物理的なデバイスの所有権(スマートプロパティ(opens in a new tab))、ドメインネームのような代替不可能な独自資産(ネームコイン(opens in a new tab))などを、ブロックチェーン上のデジタル資産を利用して表現することです。より複雑なアプリケーション例としては、デジタル資産を任意のルールを実装したコードで直接制御する(スマートコントラクト(opens in a new tab))や、さらにはブロックチェーンに基づいた分散型自律組織(opens in a new tab)(DAO)です。イーサリアムが意図しているのは、本格的でチューリング完全なプログラミング言語を内蔵したブロックチェーンであり、このプログラミング言語により、任意の状態遷移関数をエンコードできる「コントラクト」を作成できます。数行のコードでロジックを書き上げるだけで、上述したようなさまざまなシステムはもちろん、まだ想像もされていないような多くのシステムの実現を可能にします。

ビットコインとこれまでの概念

歴史

分散型デジタル通貨の概念、および不動産登録などの代替的なアプリケーションは、何十年も前から存在しています。 1980年代と1990年代の匿名電子マネープロトコルは、チャウミアンブラインドとして知られる暗号プリミティブに依拠しており、高度なプライバシーを提供しましたが、このプロトコルは中央集権型の仲介者に依存していたため、牽引力を得ることができず、大きな失敗に終わりました。 1998年Wei Daiによるb-money(opens in a new tab)が、数学的パズルを解くというアイディアを採用することにより、分散型コンセンサスを形成するといった構想を初めて提唱しました。しかし、この提案は分散型コンセンサスを具体的にどのように実装できるかについての詳細に関しては乏しいものでした。 2005年Hal Finleyはリユーザブル・プルーフ・オブ・ワーク(opens in a new tab)というコンセプトを導入しました。それはb-moneyとAdam Backによるハッシュキャッシュのパズル問題を組み合わせて、暗号通貨のコンセプトを作るというものでした。しかし、これもまたバックエンドで信頼できるコンピューティングに依存するという点で、理想的なものとはなりませんでした。 2009年、サトシ・ナカモトによって初めて分散型通貨が導入されました。これは公開鍵の暗号技術を通じて所有権を管理するための確立されたプリミティブと、「プルーフ・オブ・ワーク」と知られる、誰がコインを所有しているかを追跡するためのコンセンサスアルゴリズムを組み合わせたものです。

この「プルーフ・オブ・ワーク」の背後にあるメカニズムは、2つの問題を同時に解決したという意味で画期的なことでした。一つ目は、シンプルでほどよく効果的なコンセンサスアルゴリズムをもたらしたことです。これによって、ネットワークのノードが、ビットコインレジャーの状態への一連の正規の更新に対して、集団的に同意ができるようになりました。二つ目は、コンセンサスプロセスへの自由な参加を可能にするメカニズムを提供したことです。これにより誰がコンセンサスに影響を与えるかを決定するという政治的な問題を解決すると同時に、シビル攻撃の防御ともなりました。参加への障壁(例えば特定のリストに一意のエンティティとして登録することを要求するなど)のではなく、経済的な障壁を用いることによって行われます。すなわち、コンセンサス形成のための投票プロセスにおける単一ノードの重みは、ノードがもたらす計算能力に比例します。それ以降、ノードの重みを、計算リソースではなく、保有する通貨に比例して計算するプルーフ・オブ・ステークと呼ばれる代替アプローチが提案されました。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を返す。

第1ステップ前半は、トランザクション送信者が、存在しないコインを使用することを防ぎ、第1ステップ後半ではトランザクション送信者が、他者が所有するコインを使用することを防ぎます。第2ステップによって価値が保護されます。これを支払いに適用すると、プロトコルは次のようになります。 Aliceが11.7BTCをBobに送金するとします。最初にAliceは、少なくとも合計が11.7BTC以上で彼女が所有する、利用可能なUTXOセットを探します。現実には、Aliceは正確に11.7 BTCは用意できなく、Aliceが入手できる最小のBTCは6+4+2=12です。それで彼女はこれら3つの入力と2つの出力を持つトランザクションを生成します。最初の出力はBobのアドレスを所有者とする11.7BTCとなり、次の出力は差額となる「お釣り」の0.3BTCで所有者はAlice自身です。

マイニング

もし信頼できる一元化サービスを利用できれば、このシステムの実装は簡単でしょう。集中管理されたサーバのハードドライブを使って、単に上述した通りにコード化し、状態を追跡するだけです。しかしながら、ビットコインでは分散型通貨システムを構築しようとしているため、状態遷移システムとコンセンサスシステムを組み合わせ、全員が確実に合意できるようにする必要があります。ビットコインの分散型コンセンサスプロセスは、ネットワーク内のノードに対して、「ブロック」と呼ばれるトランザクションのパッケージ生成を絶えず試行することを要求します。ネットワークは大まかに10分毎に1ブロックを生成するように意図されており、各ブロックには、タイムスタンプ、ノンス (nonce)、前のブロックへの参照(ハッシュ)、そして前のブロック以降に行われたすべてのトランザクションリストが格納されます。この仕組みにより、ビットコインレジャーの最新状態を表し、絶え間なく更新され、永続的に大きくなる「ブロックチェーン」を生成します。

この枠組みで示された内容で、ブロックが整合しているかどうかを検証するアルゴリズムは次のようになります。

ブロックが参照する前のブロックが存在し、有効であるかどうかを確認する。
ブロックのタイムスタンプが前のブロック^fn2より大きく、2時間未満先のものであることを確認する。
ブロックのプルーフ・オブ・ワークが有効であることを確認する。
直前ブロックの最後の状態をS[0]とする。
そのブロックのトランザクションの配列をTXとし、その数を nとする。 0...n-1の範囲で1ずつ整数iを増加させ、S[i+1] = APPLY(S[i],TX[i])を実行する。もし何らかのエラーがあればループを中断し、Falseを返す。
Trueを返し、S[n]をこのブロックの最終の状態として登録する。

本質的には、そのブロック内の各トランザクションは、処理が実行される直前の基準状態から新しい状態に遷移するために、有効な状態遷移を行わねばなりません。状態はブロック内でエンコードされません。状態は検証ノードによって記憶される純粋な抽象化であり、誕生(ジェネシス)状態から開始してすべてのブロックのすべてのトランザクションを順次適用することによってのみ、任意のブロックに対して(安全に)計算できます。さらに、マイナーがトランザクションをブロックに含める順番も重要であることに注意してください。仮に、ブロック内に2つのトランザクションAとBがあり、BがAの作ったUTXOを使うような場合、AがBより先に来ればブロックは有効ですが、そうでなければ無効となります。

上記リストに挙げた有効判定条件のうち、他のシステムでは見られないものが「プルーフ・オブ・ワーク」の要件です。正確な条件は、256ビットの数値として扱われるすべてのブロックのダブルSHA256ハッシュが、動的に調整された目標値よりも小さくなければならないというものです。この目標値は執筆時点で約2¹⁸⁷程度です。ブロックの作成を計算上「難しい」ものにすることで、シビル攻撃者がブロックチェーン全体を自分の都合の良いように作り変えてしまうことを防ぐことが目的です。 SHA256は完全に予測不可能な疑似乱数関数として設計されているため、有効なブロックを作成する唯一の方法は、単純に試行錯誤により、ノンス (nonce)を繰り返し増加させ、新しいハッシュ値が条件に合致するかどうか確認することです。

現在(執筆時点)の目標値である~2¹⁸⁷では、ネットワークは有効なブロックを見つけるまでに、平均して~2⁶⁹回の試行を行わなければなりません。一般的に、平均して10分ごとにネットワーク内のどこかのノードで新しいブロックが生成されるように、目標値は2016ブロックごとにネットワークによって再調整されます。この計算作業の見返りとして、25BTCの報酬で、新しいトランザクションをブロックに追加する権利がすべてのブロックのマイナーに与えられています。さらに、トランザクションにおいて入力の合計価格が出力の合計価格より大きい場合、その差額は「トランザクションフィー」としてマイナーに支払われます。ちなみに、これはBTCが発行される唯一の仕組みです。創成期では、コインはまったく含まれていませんでした。

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

ある商品と引き換えに100BTCをその商品の販売者に支払う(迅速に配送されるデジタルグッズが好ましい)
商品の配送を待つ
同じ100BTCを自分自身に送信する別のトランザクションを生成する
自分への送金トランザクションが先であったことをネットワークに納得させる

ステップ(1)が実行されたら、数分後にあるマイナーがブロックにトランザクションを追加します。このブロックを270000番ブロックと呼ぶことにします。約1時間後には、そのブロックの後にさらに5つのブロックがチェーンに追加され、それぞれのブロックがそのトランザクションを間接的に指し、「確認」していることになります。この時点で、販売者は支払いが確定したものとして、商品を配送します。これはデジタル商品であると仮定しているので、配送は即時に行われます。ここで、攻撃者は100BTCを自分自身に送る別のトランザクションを作成します。攻撃者が単にそれを野に放つと、そのトランザクションは処理されません。マイナーはAPPLY(S,TX)を実行しようとし、TXがもはや状態には存在していないUTXOを消費しようとしていることに気づきます。そのため、代わりに攻撃者は270000番ブロックの別のバージョンをマイニングし、ブロックチェーンの「フォーク」を作成します。この270000番ブロックは、親として同じ269999番ブロックを指していますが、古いトランザクションが新しいものに入れ替えられています。ブロックデータが異なるため、プルーフ・オブ・ワークの再実行が必要になります。さらに、攻撃者が作成した新しいバージョンの270000番ブロックは、ハッシュが異なるため、オリジナルの270001～270005番ブロックは、それを「指す」ことはありません。したがって、元のチェーンと攻撃者の新しいチェーンは完全に分離します。フォークが生成された場合、最も長いブロックチェーンが真実であるとみなされるため、正当なマイナーは270005のチェーンで作業し、攻撃者だけが270000のチェーンで作業します。攻撃者が自分のブロックチェーンを最長にするためには、ネットワークのうち攻撃者以外を合わせたよりも多くの計算能力を持っていないと追いつくことができません(そのため、「51%攻撃」と呼ばれます)。

マークルツリー

左: ブランチの有効性を証明するには、マークルツリー内のわずかな数のノードを提示するだけで十分です。

右: マークルツリーのどの部分についても、変更しようとすると最終的にチェーンのどこかに矛盾が生じます。

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

マークルツリープロトコルは、長期の持続可能性に間違いなく不可欠なものです。ビットコインネットワークの「フルノード」とは、すべてのブロックを保存して処理するノードのことで、2014年4月現在、ビットコインネットワークで約15GBのディスクスペースを占めており、毎月1GB以上のペースで増加しています。現在は、一部のデスクトップPCで実現しており、携帯電話では実現していませんが、将来的には参加できるのは企業や愛好家のみになります。 SPV (簡易決済検証)と呼ばれるプロトコルにより、「ライトノード」と呼ばれる軽量のノードが存在します。ライトノードは、ブロックヘッダーをダウンロードし、ブロックヘッダー上のプルーフ・オブ・ワークを検証した後、自分に関係のあるトランザクションに関連する「ブランチ」のみをダウンロードします。これにより、ライトノードは、ブロックチェーン全体のごく一部をダウンロードするだけで、ビットコイントランザクションの状況や自分の現在の残高を、安全性を強く保証しながら判断することができます。

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

基礎となるブロックチェーンのアイデアを別のコンセプトに適用するというアイデアもまた長い歴史を持っています。 2005年、Nick Szaboは「所有者権限がある安全な財産権念(opens in a new tab)」という概念を打ち出し、「複製データベース技術の新しい進歩」により、ブロックチェーンベースのシステムで誰がどの土地を所有しているかのレジストリを保存できるようになると説明し、ホームステディング、不利益所有、グルジア土地税といった概念を含む精巧なフレームワークを作成した文書を発表しています。しかし、残念ながら当時は有効な複製データベースシステムがなかったため、このプロトコルが実際に導入されることはありませんでした。しかし、2009年以降、ビットコインの非中央集権的なコンセンサスが開発されると、多くの代替アプリケーションが急速に登場し始めました。

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

このように、一般的にコンセンサスプロトコルの構築には、2つの方法があり、一つは独立したネットワークを構築すること、もう一つはビットコインの上にプロトコルを構築することです。前者のアプローチでは、ネームコインのようなアプリケーションの場合はそれなりに成功していますが、実装は困難です。個々の実装について、独立したブロックチェーンをブートストラップするだけでなく、必要な状態遷移やネットワークコードをすべて構築してテストする必要があります。また、分散型コンセンサス技術のアプリケーションはべき法則分布に従うと予測していますが、大多数のアプリケーションは独自のブロックチェーンを必要とするには小さすぎます。分散型アプリケーションの中には、特に分散型自律組織など、相互に作用する必要のある大規模なクラスが存在することもあります。

一方で、ビットコインベースのアプローチは、ビットコインの簡略化された決済検証機能を継承していないという欠点があります。 SPV (簡易決済検証)がビットコインに適しているのは、ブロックチェーンの深さを有効性の代用として利用できるからです。すなわち、ある時点で十分にさかのぼったトランザクションの祖先であれば、ルールの上においてこの祖先は状態の一部であると言ってよいということです。大して、ブロックチェーンベースのメタプロトコルは、自身のプロトコルのコンテキスト内で有効ではないトランザクションをブロックチェーンに含めないようにすることはできません。それゆえ、完全に安全なSPVメタプロトコル実装においては、特定のトランザクションが有効であるかどうかを判断するために、ビットコインブロックチェーンの最初まですべて遡ってスキャンする必要があります。現在、ビットコインベースのメタプロトコルの「軽量」な実装はすべて、信頼できるサーバーに依存して、データの提供を受けていますが、特に暗号通貨の主な目的の1つが信頼の必要性を排除することであるため、最適とは言えない結果です。

スクリプト

ビットコインプロトコルは拡張なしでも、「スマートコントラクト」の概念の弱いバージョンを実際に備えています。ビットコインのUTXOは、公開鍵だけでなく、シンプルなスタックベースのプログラミング言語で表現された、より複雑なスクリプトでも所有することができます。このパラダイムでは、そのUTXOを使用するトランザクションは、スクリプトの条件を満たすデータを提供しなければなりません。実際のところ、基本的な公開鍵による所有権の仕組みでさえもスクリプトで実装されています。スクリプトは入力として楕円曲線署名を受け取り、それをトランザクションおよびUTXOを所有するアドレスと照合し、照合が成功した場合は1を、そうでない場合は0を返します。その他、より複雑なスクリプトはさまざまなユースケースが存在します。例えば、3つの秘密鍵のうち、2つの秘密鍵による署名を必要とするスクリプト(マルチシグ)を構築することができます。これは、企業アカウントや安全な貯蓄口座、商取引のエスクロー(第三者預託)などに有効な設定です。スクリプトは、計算問題を解決するための報酬を支払うためにも使用できます。「この金額のドージコインのトランザクションを私に送ったというSPV証明を提供できれば、このビットコインUTXOはあなたのものです」というようなスクリプトを構築することもでき、本質的に分散型の相互暗号通貨交換を可能にします。

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

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

このように、暗号通貨の上に高度なアプリケーションを構築するには、「新しいブロックチェーンを構築する」「ビットコイン上でスクリプトを使用する」「ビットコイン上でメタプロトコルを構築する」という3つのアプローチがあります。新しいブロックチェーンを構築することで、機能を無制限に自由に構築することができますが、開発時間、ブートストラップの手間、セキュリティを犠牲にすることになります。スクリプトの使用では、実装や標準化が容易ですが、その機能は非常に限られています。また、メタプロトコルは簡単ですが、スケーラビリティに欠点があります。イーサリアムでは、開発のしやすさやライトクライアントの特性をさらに強化すると同時に、経済環境やブロックチェーンのセキュリティをアプリケーションで共有できるような代替フレームワークを構築したいと考えています。

イーサリアム

イーサリアムの目的は、分散型アプリケーションを構築するための代替プロトコルを作成することであり、迅速な開発時間、小規模で利用頻度の低いアプリケーションのセキュリティ、およびさまざまなアプリケーションが非常に効率的に相互作用できる状況に特に重点を置いて、大規模な分散型アプリケーションに非常に有用と思われる、異なる種類のトレードオフの組み合わせを提供します。イーサリアムは、本質的に究極の抽象的な基盤レイヤーを構築することでこれを実現します。つまり、チューリング完全なプログラミング言語を内蔵したブロックチェーンで、誰もがスマートコントラクトや分散型アプリケーションを書くことができ、所有権、トランザクションフォーマット、状態遷移関数に関する独自の任意のルールを作成することができます。ネームコインの基本的なバージョンは2行のコードで書くことができ、通貨や評価システムなどの他のプロトコルは20行以下で作ることができます。スマートコントラクトとは、値を格納し、一定の条件を満たした場合にのみアンロックされる暗号化された「箱」のことで、プラットフォーム上に構築できます。チューリング完全性、値の認識性、ブロックチェーン認識、状態の各機能が追加されているため、ビットコインのスクリプトよりもはるかに強力です。

イーサリアムアカウント

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

各トランザクションの処理が一度しか行えないようにするノンス (nonce)
アカウントの現在のEther残高
存在する場合には、アカウントのコントラクトコード。
アカウントのストレージ(デフォルトでは空)

「Ether」はイーサリアム内の燃料ともいえ、トランザクションフィーの支払いに必要です。イーサリアムには一般的に2種類のアカウントが存在します。秘密鍵コントラクトによって管理される外部所有アカウントと、コントラクトコードによって管理されるコントラクトアカウントです。外部所有アカウントはコードを持たず、トランザクションを作成し署名することで外部所有アカウントからメッセージを送信できます。コントラクトアカウントでは、コントラクトアカウントがメッセージを受信するたびにコードが起動し、内部ストレージへの読み書きや他のメッセージの送信、または順にコントラクトの作成ができます。

イーサリアムにおける「コントラクト」は、「履行」や「遵守」されるべきものというよりも、イーサリアムの実行環境の中にいる「自律型エージェント」のようなものであり、メッセージやトランザクションによって「トリガーされる」と常に特定のコードを実行し、自身のEther残高や永続的な変数を追跡するために、独自の鍵/値ストアを直接制御するものです。

メッセージとトランザクション

イーサリアムにおいて「トランザクション」とは、外部アカウントが送信する署名済みのメッセージを格納したデータパッケージのことを意味します。トランザクションには、次の内容を含みます。

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

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

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

メッセージ

コントラクトは、他のコントラクトに「メッセージ」を送信する機能を持っています。メッセージはシリアル化されず、イーサリアム実行環境の中でのみ存在する仮想オブジェクトです。メッセージには、次が含まれます。

メッセージの送信者(暗黙的)
メッセージの受信者
メッセージと一緒に転送するEtherの量
オプションのデータフィールド
STARTGAS値

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

なお、トランザクションやコントラクトで割り当てられたガス許容量は、そのトランザクションとそこから派生するすべての副次的な実行で消費されるガスの合計に適用されます。例えば、外部アクターAがBに1000ガスでトランザクションを送信し、BがCにメッセージを送信する前に600ガスを消費し、Cの内部実行が戻り値を返すまでに300ガスを消費した場合、Bはガス切れになる前にさらに100ガスを使うことができます。

イーサリアムの状態遷移関数

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

トランザクションが正しく形成されているかどうか(正しい数の値が含まれているかなど)、署名が有効かつノンス (nonce)が送信者のアカウントのノンスと一致するかを確認する。違えば、エラーを返す。
STARTGAS * GASPRICEとしてトランザクションフィーを計算し、署名から送信元アドレスを特定する。送信者の残高から手数料を引き、送信者のノンス (nonce)を増やす。残高が足りない場合は、エラーを返す。
GAS = STARTGASを初期化し、1バイトあたりの一定量のガスを取り、トランザクションのバイトの支払いに充てる。
送信者のアカウントから受信者のアカウントにトランザクション額を送金する。受信アカウントがまだ存在しない場合は、アカウントを作成する。受信アカウントがコントラクトである場合は、コントラクトのコードを完了する、またはガスがなくなるまで実行する。
送信者が十分な残高を持っていなかったり、コードの実行がガス欠になったりして送金が失敗した場合は、手数料の支払い以外のすべての状態の変化を元に戻し、手数料をマイナーのアカウントに追加する。
それ以外の場合は、残っているすべてのガス代を送信者に返金し、消費したガスに対して支払われた料金をマイナーに送る。

例として、次のコントラクトのコードを考えてみましょう。

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

実際にはコントラクトコードは低レベルのEVMコードで書かれていることに注意してください。この例では、わかりやすくするため、高レベル言語の1つであるSerpentで書かれており、EVMコードにコンパイルされます。コントラクトのストレージが空の状態で開始され、トランザクションが10Ether値、2000 gas、0.001 Ether gasprice、64バイトのデータで送信され、0～31バイト目が数字の「2」、32～63バイト目が文字列の「CHARLIE」を表していたとします。この場合の状態遷移関数の処理は次のようになります。

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

もしトランザクションの受信側にコントラクトコードがなければ、トランザクションフィーの総額は、提供されたGASPRICEにトランザクション長(バイト)を掛けたものになるだけで、トランザクションと一緒に送られたデータには関係ありません。

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

コードの実行

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

値のプッシュとポップが可能な後入り先だし(LIFO)のコンテナであるスタック
無限に拡張可能なバイト配列のメモリ
キーや値の保管するコントラクトコードの長期ストレージ。計算が終わるとリセットされてしまうスタックやメモリとは異なり、ストレージは長期にわたって保持される。

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

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番目のアイテムを1番目のアイテムが指定したインデックスでコントラクトのストレージに挿入します。ジャストインタイム・コンパイルによってイーサリアム仮想マシンの実行を最適化する方法はたくさんありますが、イーサリアムの基本的な実装は、数百行のコードで行うことができます。

ブロックチェーンとマイニング

イーサリアムのブロックチェーンは、いくつかの違いがあるものの、ビットコインのブロックチェーンと多くの点で共通点があります。ブロックチェーンの構造に関するイーサリアムとビットコインの主な違いは、イーサリアムのブロックにはビットコインと違い、トランザクションリストと最新の状態の両方のコピーが含まれていることです。それ以外にも、ブロック番号と難易度という2つの値がブロックに入っています。イーサリアムの基本的なブロック検証アルゴリズムは以下の通りです。

参照された前のブロックが存在し、有効であるかどうかを確認する。
ブロックのタイムスタンプが、参照している前のブロックのタイムスタンプより大きく、15分未満の未来のものであることを確認する。
ブロックナンバー、難易度、トランザクションルート、アンクルルート、ガスリミット(イーサリアム特有の様々な低レベルの概念)が有効であることを確認する。
ブロック上のプルーフ・オブ・ワークが有効であることを確認する。
直前ブロックの最後の状態をS[0]とする
TXはブロックのトランザクションリストで、 n件あるとする。 0...n-1のすべての i について、S[i+1] = APPLI(S[i],TX[i])をセットする。いずれかのアプリケーションがエラーを返した場合や、この時点までにブロック内で消費されたガスの合計が GASLIMITを超えた場合は、エラーを返す。
S_FINALをS[n]にするが、マイナーに支払ったブロック報酬を追加する。
状態 S_FINAL のメルクルツリールートが、ブロックヘッダーで提供されている最終的な状態ルートと等しいかどうかを確認する。等しければそのブロックは有効、そうでなければ無効となる。

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

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

アプリケーション

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

トークンシステム

オンブロックチェーンのトークンシステムは、米ドルや金などの資産を表すサブ通貨から、企業の株式、スマート・プロパティを表す個々のトークン、安全で署名不可能なクーポン、さらには、従来の価値とは全く関係なく、インセンティブを与えるためのポイントシステムとして使用されるトークンシステムまで、さまざまな用途があります。トークンシステムは、イーサリアムで驚くほど簡単に実装できます。ここで理解しておきたいのは、すべての通貨またはトークンシステムは基本的に、「AからX単位を引いてBにX単位を渡す」という1つの操作を持つデータベースであり、 (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つの重要な機能、すなわちトランザクションフィーをその通貨で直接支払うことができる機能を含めることです。コントラクトがEther残高を維持し、送信者への手数料の支払いに使用されたEtherを返金し、手数料で受け取った内部通貨単位を回収し、絶え間なく行われているオークションで再販して、この残高を補充するという方法で実施されます。そのため、ユーザーは自分のアカウントをEtherで「有効化」する必要がありますが、コントラクトが毎回払い戻しを行うため、一度Etherがあれば再度利用できます。

金融派生商品と安定価値通貨

金融派生商品は、「スマートコントラクト」の最も一般的な適用であり、コードで実装するのが最も簡単なものの一つです。金融コントラクトを実装する上での主な課題は、その大半が外部の価格ティッカーを参照する必要があることです。例えば、非常に望ましい用途には、米ドルに対するEther (または他の暗号通貨)の変動をヘッジするスマートコントラクトがありますが、これを行うにはコントラクトがETH/USDの価値を知る必要があります。これを行う最も簡単な方法は、特定の当事者(例: NASDAQ)が維持する「データフィード」コントラクトを通して行うことです。当事者が必要に応じてコントラクトを更新できるように設計されており、他のコントラクトがこのコントラクトにメッセージを送信したときに価格を返すものです。

この重要な要素を考慮すると、ヘッジコントラクトは次のようになります。

団体Aが1000Etherを入力するのを待つ。
団体Bが1000Etherを入力するのを待つ。
データフィードコントラクトにクエリし、計算された1000EtherのUSD価格をストレージに記録する。ここでは仮に$xとする。
30日後、AまたはBにコントラクトの「再有効化」を許可し、$x相当のEtherをAに、残りをBに送る(新しい価格を得るためにデータフィードコントラクトを再度照会して計算) 。

このようなコントラクトは、暗号化された電子商取引において大きな可能性を秘めています。暗号通貨の主な問題点として挙げられるのは、変動が激しいということです。多くのユーザーや販売者は、暗号資産を扱うことによる安全性や利便性を求めるものの、1日で資金の23％を失うような事態に直面することは望みません。これまで、最も一般的に提案されてきたのは、発行者担保型の資産です。これは、発行者がサブ通貨を作成し、単位を発行・失効させる権利を持ち、特定の原資産(金や米ドルなど)を1単位オフラインで提供した人に、その通貨を1単位提供するというものです。そして、発行者は、1単位の暗号資産を送り返してきた人に、1単位の原資産を提供することを約束します。この仕組みにより、発行者が信頼できる場合には、非暗号化資産を暗号化資産に「アップリフト」することができます。

しかし、実際には、発行者が必ずしも信頼できるとは限らず、また、銀行のインフラが脆弱であったり、敵対的であったりして、そのようなサービスが存在しない場合もあります。金融派生商品はこの場合の代替手段を提供します。単一の発行者が資産を裏付ける資金を提供するのではなく、暗号化された参照資産(例: ETH)価格が上昇することに賭ける投機家の分散型市場がその役割を果たします。発行者とは異なり、投機家はヘッジコントラクトによって資金をエスクロー(預託)されているため、契約を不履行することはありません。ただし、価格ティッカーを提供するためには信頼できるソースが必要なため、このアプローチは完全な分散型ではないことに注意してください。それでも、インフラ要件を減らし、発行者とは異なり、価格フィードの発行にはライセンスは必要なく、言論の自由と分類される可能性が高く、詐欺の可能性を減らすという点では、間違いなくこのアプローチは大きな進歩です。

IDとレピュテーションシステム

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

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

コントラクトは非常にシンプルで、イーサリアムネットワークのデータベースであり、追加はできても変更や削除は不可能です。誰でも価値のあるネームを登録することができ、その登録は永遠に残ります。より洗練されたネーム登録コントラクトでは、他のコントラクトがクエリを実行できる「関数句」や、ネームの「所有者」(つまり最初の登録者)がデータを変更したり所有権を移管できるメカニズムも備えています。さらに、レピュテーションや信用の輪の機能を追加することもできます。

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

ここ数年で、多くの人気のあるオンラインのファイルストレージのスタートアップが登場しました。最も有名なのがDropboxで、月額料金でユーザーはハードドライブのバックアップをアップロード、バックアップを保存・アクセスできます。しかし、この時点では、ファイルストレージ市場は相対的に非効率的です。様々な既存のソリューションをざっと見てみると、特に無料枠も企業レベルの割引も効かない「異様な谷」と呼ばれる20〜200GBのレベルでは、主流のファイルストレージ費用の月額料金は、1か月でハードディスク全体のコストを上回る金額になります。イーサリアムのコントラクトは、分散型ファイルストレージのエコシステムへの進歩を実現します。個々のユーザーは自分のハードディスクを貸し出すことで少量のお金を得ることができ、未使用のスペースはファイルストレージのコストをさらに下げるために使用することができます。

このようなデバイスを支える重要な要素は、私たちが「分散型Dropboxコントラクト」と呼んでいるものです。そのコントラクトコードは以下のように機能します。まず、目的のデータをブロックに分割し、プライバシーを守るために各ブロックを暗号化し、それをもとにマークルツリーを構築します。そして、次のようなルールのスマートコントラクトを作ります。Nブロックごとにマークルツリーのランダムなインデックスを選択し(コントラクトコードからアクセス可能な前のブロックハッシュをランダム性のソースとして使用) 、ツリーのその特定のインデックスにあるブロックの所有権について、簡略化された支払い検証のような証明をトランザクションに提供するため、最初のエンティティにX Etherを付与します。ユーザーが自分のファイルを再ダウンロードしたいときには、マイクロペイメント・チャネル・プロトコル(例: 32キロバイトごとに1szaboの支払い)を使って、ファイルを回復することができます。最も料金効率の良い方法は、支払者が最後までトランザクションを公開せずに、32キロバイトごとに同じノンス (nonce)を持つ、少しでも有利なトランザクションに置き換えることです。

このプロトコルの重要な特徴は、多くのランダムなノードがファイルを忘れないと信頼しているように見えるかもしれませんが、秘密共有によりファイルを多くのピースに分割し、それぞれのピースがまだどこかのノードが所有しているかコントラクトを監視することで、先のリスクをほぼゼロにすることができることです。あるコントラクトがまだお金を支払っていれば、それは誰かがまだファイルを保存しているという暗号論的な証拠となります。

分散型自律組織(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をファイナライズする

コントラクトにはこれらの1つずつに対して条項があります。開いているすべてのストレージの変更の記録と、誰が投票したかのリストが保持されます。また、すべてのメンバーのリストも保持します。ストレージへの何かしらの変更がメンバーの3分の2の投票を得ると、最終のトランザクションがその変更を実行します。さらに洗練された骨組みでは、トランザクションの送信、メンバーの追加や削除などの機能に投票機能が組み込まれており、リキッド・デモクラシー(opens in a new tab)方式の投票委任が可能です(誰もが自分に投票する人を割り当てることができ、割り当ては推移的であるため、AがBを割り当て、BがCを割り当てた場合、CがAの投票を決定します)。この設計により、分散型自律組織(DAO)は分散型コミュニティとして有機的に成長し、最終的に人々はメンバーを選別する作業をスペシャリストに委ねることができます。ただし、「現行のシステム」とは異なり、個々のコミュニティのメンバーが自分の同調や同盟を変更するにつれて、スペシャリストは時間とともに簡単に現れたり消えたりすることがあります。

もう一つのモデルは、どのアカウントでも0株超の株式を持つことができ、意思決定には3分の2の株式が必要となる分散型企業の場合です。完全な骨組みには、資産管理機能、株式売買のオファーを出す機能、オファーを受け入れる機能(可能であればコントラクト内にオーダーマッチングメカニズムを設ける)が含まれます。委任は「取締役会」の概念を一般化したリキッドデモクラシーのスタイルでもあります。

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

1. 定期預金: 仮にAliceは自分の資金を安全な保管を希望しているとします。しかし、自分の秘密鍵を紛失したり、誰かにハッキングされることを心配しています。 Aliceは、銀行であるBobと次のようなコントラクトにEtherを投入します。

Alice1人では、1日に最大1％の資金を引き出すことができる。
Bob1人では、1日あたり最大1%の資金を引き出すことができるが、Aliceは自身の鍵でBobの引き出しを遮断するトランザクションを作成できる。
AliceとBob2人の場合は、いくらでも引き出すことができる。

通常、Aliceは1日1％で十分ですが、もしAliceがさらに引き出したい場合、Bobに連絡して助けを求めることができます。もしAliceの鍵がハッキングされたら、AliceはBobに急いで行き、資金を新しいコントラクトに移します。もしAliceが鍵をなくしても、Bobが最終的には資金を回収してくれます。 Bobが悪意のあるものであることが判明した場合、AliceはBobの出金を無効にすることができます。

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％まで、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の実装

GHOST (最も計算量の多いチェーンをメインチェーンとする)プロトコルは、2013年12月(opens in a new tab)にYonatan Sompolinsky氏とAviv Zohar氏が初めて発表した革新的なプロトコルです。 GHOSTの背景には、確認時間が早いブロックチェーンは、現在、高いステイル率によるセキュリティの低下に悩まされているということがあります。ブロックがネットワークを伝搬するのには一定の時間がかかるため、マイナーAがブロックをマイニングした後、マイナーAのブロックがBに伝搬する前にマイナーBが別のブロックをマイニングすると、マイナーBのブロックは無駄になってしまい、ネットワークのセキュリティに貢献しません。さらに、集中化の問題もあります。マイナーAが30%のハッシュパワーを持つマイニングプールで、Bが10%のハッシュパワーを持つ場合、Aは70%の確率でステイルブロックを生成するリスクがあり(残りの30%の時間はAが最後のブロックを生成し、すぐにマイニングデータを取得するため)、一方でBは90%の確率でステイルブロックを生成するリスクがあります。したがって、ステイル率が高くなるほど十分に短いブロック間隔の場合、Aはサイズが大きいため、実質的により効率的になります。この2つの効果が相まって、素早くブロックを生成するブロックチェーンでは、1つのマイニングプールがネットワークのハッシュパワーの十分な割合を占め、マイニングプロセスを事実上支配する可能性が非常に高くなります。

Sompolinsky氏とZohar氏に説明されているように、GHOSTはどのチェーンが「最長」であるかを計算する際に、ステイルブロックを含めることで、ネットワークセキュリティ上の損失という1つ目の問題を解決します。つまり、どのブロックが裏付けとなるプルーフ・オブ・ワークの合計が最大であるかを計算する際に、ブロックの親やさらにその先の祖先だけでなく、ブロックの祖先のステイルな子孫(イーサリアム用語では「アンクル」) も加えられます。 2つ目の問題である集中化バイアスを解決するために、Sompolinsky氏とZohar氏によるプロトコルを超えて、ステイルブロックにも報酬を提供します。ステイルブロックは基本報酬の87.5%り、ステイルブロックを含むネヒューブロックは残りの12.5%を受け取ります。ただし、トランザクションフィーはアンクルには付与されません。

イーサリアムでは、GHOSTの簡易版を実装しており、7階層までしか下に行きません。具体的には以下のように定義されます。

ブロックは親を指定しなければならず、0以上のアンクルを指定しなければならない。
Bブロックに含まれるアンクルは、以下の性質を持っていなければならない。
- Bのk世代目の祖先の直系の子供でなければなりません（2 <= k <= 7）。
- Bの祖先になることはできない。
- アンクルは有効なブロックヘッダーである必要があるが、以前に検証されたブロックである必要はなく、有効なブロックであるかを問わない。
- アンクルは、以前のブロックに含まれていたすべてのアンクル、および同じブロックに含まれていた他のすべてのアンクルとは異なったものでなければならない(二重包含は不可)。
ブロックBのアンクル U 1つにつき、Bのマイナーはコインベース報酬に3.125％追加され、Uのマイナーは標準のコインベース報酬の93.75％を獲得する。

アンクルが7世代までしか含まれていない限定版のGHOSTを採用した理由は2つあります。第一に、GHOSTを無制限にすると、特定のブロックのどのアンクルが有効なのかを計算するのに、あまりにも複雑な要素が含まれてしまいます。第二に、イーサリアムで採用されている、報酬が提供される無制限のGHOSTでは、公開攻撃者のチェーンではなく、メインチェーンでマイニングするというマイナーへのインセンティブを取り除くことになってしまいます。

手数料

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

しかし、結局のところ、市場ベースのメカニズムのこの欠陥は、ある不正確で簡素化する仮定が与えられると、魔法のように相殺されます。議論は次のとおりです。例えば:

トランザクションはk個の操作が必要で、トランザクションを追加するすべてのマイナーに報酬kRを提供する。Rは送信者によって設定され、kとRは事前に(概算が)マイナーに表示される。
操作の処理コストは、どのノードに対しても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に設定されていますが、今後の分析により変更される可能性があります。

ビットコインでは、ブロックサイズが大きいと伝播に時間がかかり、ステイルになる確率が高くなるため、ブロックサイズが大きくすることを阻害するもう一つの要因があります。イーサリアムでは、ガスを大量に消費するブロックは、物理的に大きく、トランザクションの状態遷移を検証し処理するのに時間がかかるため、伝播に時間がかかる場合があります。この遅延の阻害要因はビットコインでは重要な考慮事項ですが、イーサリアムではGHOSTプロトコルがあるため、それほど影響は大きくなく、ブロック制限により、ベースラインがより安定します。

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

重要な点は、イーサリアム仮想マシンがチューリング完全であることです。これは、EVMのコードが、無限ループを含む、考え得るあらゆる計算をエンコードできることを意味します。 EVMコードは2つの方法でループを可能にします。第一に、プログラムをコードの前の場所にジャンプさせるJUMP命令と、条件付きのジャンプを行うJUMPI命令があり、while x < 27: x = x * 2のような記述が可能です。第二に、コントラクトは他のコントラクトを呼び出すことができ、潜在的に再帰的なループを可能にします。これは当然のことながら、悪意のあるユーザーは、マイナーを強制的に無限ループに陥らせて、本質的にマイナーとノード全体をシャットダウンできるかという問題につながります。この問題は、コンピューターサイエンスで「停止問題」と知られる問題が原因で起こるもので、一般に、特定のプログラムが停止するかどうかを判断する方法はありません。

状態遷移の項で説明したように、イーサリアムのソリューションは、トランザクションに許容される最大の計算ステップ数を必須で設定することです。実行に時間がかかる場合には、計算は元に戻されますが、料金は支払われます。メッセージも同じように動作します。私たちがソリューションを決めた背後となる理由を示すために、以下の例を考えてみます。

攻撃者は無限ループを実行するコントラクトを作成し、無限ループを始動させるトランザクションをマイナーに送信する。マイナーはトランザクションを処理して無限ループを実行し、ガス欠になるのを待つ。実行中にガス欠になって途中で止まってしまっても、取引は有効であり、マイナーは各計算ステップの手数料を攻撃者に請求する。
攻撃者は非常に長い無限ループを作り、マイナーに長時間の計算をさせることで、計算が終了する頃にはさらに数ブロックが出現し、マイナーが手数料を請求するのにトランザクションを追加できなくなることを試みる。しかし、攻撃者は実行にかかる計算ステップ数を制限するSTARTGASの値を提出する必要があるため、マイナーは計算に過度に多くのステップがかかることを事前に察知できる。
攻撃者はsend(A,contract.storage[A]); contract.storage[A] = 0のようなコードが書かれたあるコントラクトを見て、第一段階を実行するには十分なガスだが、第二段階の実行には不十分なガスを送る (つまり、引き出しはするが、残高は減らない) 。実行が途中で停止した場合、変更内容は元に戻されるため、このコントラクトの作成者はこのような攻撃に対する保護を心配する必要はない。
金融コントラクトは、リスクを最小限に抑えるために、9つの独自データフィードの中央値を取って機能する。攻撃者は、分散型自律組織(DAO)の項で説明した可変アドレス呼び出しメカニズムにより変更できるように設計されたデータフィードの1つを乗っ取り、無限ループを実行するように変え、金融コントラクトから資金を要求しようとするすべての試みをガス欠にさせようと企てる。この問題を防ぐため、金融コントラクトは、メッセージにガスリミットを設けることができる。

チューリング完全性の代わりのものとしては、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)

51回のトランザクションで、2⁵⁰回の計算ステップを必要とするコントラクトがあります。マイナーはこのようなロジック爆弾を事前に検知するために、各コントラクトと最大計算ステップ数を示す値を維持し、他のコントラクトを再帰的に呼び出すコントラクトに対してこれを計算することができます。ただし、そのためにはマイナーは他のコントラクトを作成するコントラクトを禁止しなければなりません(上記の26個のコントラクトの作成と実行は、簡単に1つのコントラクトにまとめることができるため) 。もう一つの問題点は、メッセージのアドレスフィールドは変数であるため、一般的には、あるコントラクトがどの他のコントラクトを呼び出すのかを事前に検知することさえできない可能性があるということです。従って、意外な結論となります。チューリング完全は驚くほど簡単に管理でき、チューリング完全でない場合は、まったく同じ制御をしない限り、管理が難しくなります。では、プロトコルをチューリング完全にする方が良いでしょう。

通貨と発行

イーサリアムのネットワークには、独自の通貨Etherが組み込まれており、これには次の2つの目的があります。様々な種類のデジタル資産間で効率的な交換を可能にするための主要な流動性層を提供することと、さらに重要なのは、トランザクションフィーを支払うためのメカニズムを提供することです。便宜上、また将来の議論を避けるため(現在のビットコインにおけるmBTC/uBTC/satoshiの議論を参照)、デノミネーションにはあらかじめラベルが付けられています。

1: wei
10¹²: Szabo
10¹⁵: Finney
10¹⁸: Ether

これは、「ドル」と「セント」、「BTC」と「satoshi」の概念を拡大したものと捉えてください。近い将来、通常の取引には「Ether」、マイクロトランザクションには「Finney」、手数料やプロトコルの実装に関する技術的な議論には「Szabo」と「wei」が使われるようになると予想しています。

発行モデルは次のとおりです。

Etherは、1BTCあたり1000～2000Etherの価格で通貨売却にリリース。これは、MastercoinやNXTなどの他のプラットフォームで成功を収めている、イーサリアムの組織の資金調達と開発費の支払いを目的とした仕組み。早期購入者にはより大きな割引が適用される。売却により受け取ったBTCは、デベロッパーへの給与や報酬の支払いに全額使用され、イーサリアムや暗号通貨のエコシステムにおける様々な営利・非営利プロジェクトに投資される。
初期のコントリビューターへの補償や、ジェネシスブロック前のETH建ての費用を支払うために、販売総額の9.9% (60102216ETH)が、組織に割り当てられる。
売却総額の9.9%を長期積立として維持する。
売却総額の26%が、その時点から永遠に1年ごとにマイナーに割り当てられる。

グループ	発売時	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倍にした場合、Etherの総量は16.5％減り、1Ether当たりの価値は19.8％高くなります。したがって、均衡状態では、売却で購入されるEtherの量が19.8%増え、1Ether当たりの価値は再び以前とまったく同じになります。また、組織は1.198倍のBTCを持つことになりますが、これは元のBTCと追加の0.198倍の2つに分けられます。つまり、この状況は基金のケースと全く同じですが、1つ重要な違いがあります。それは、組織が純粋にBTCを保有しているため、Ether単位の価値を支えるインセンティブがないということです。

永続的な線形供給成長モデルは、ビットコインへの過剰な富の集中と見なされるリスクを軽減し、現在および将来の時代に生きる個人に通貨単位を取得する公正な機会を与えると同時に、「供給成長率」は時間の経過とともに依然としてゼロになる傾向があるため、Etherを取得し保有する強いインセンティブを維持します。また、コインは不注意や死亡などにより時間の経過とともに必ず失われますが、コインの損失は1年間の総供給量に対する割合としてモデル化することができるため、流通している通貨の総供給量は、年間の発行量を損失率で割った値で事実上最終的に安定すると考えています(例: 損失率1％の場合、供給量が26Xに達すると、毎年0.26Xがマイニングされ、0.26Xが失われ、均衡が保たれることになります) 。

なお、将来的には、イーサリアムはセキュリティのためにプルーフ・オブ・ステーク・モデルに切り替わり、必要な発行は年間0～0.05Xまで減少します。イーサリアム組織が資金を失った場合、またはその他の理由で消滅した場合、「ソーシャルコントラクト」をオープンのままにします。誰もがイーサリアムの将来の候補バージョンを作成する権利を持ち、唯一の条件は、Etherの量が最大で60102216 * (1.198 + 0.26 * n)であることです(nは始まりのブロックからの年数です)。クリエイターは、プルーフ・オブ・ステークによる供給拡大と許容される最大の供給拡大との差額の一部または全部を、開発費としてクラウド販売などで自由に割り当てることができます。ソーシャルコントラクトに準拠していないアップグレード候補は、正当に準拠したバージョンにフォークされることがあります。

マイニングの集中化

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

イーサリアムの現在の意図としては、マイナーが状態からランダムなデータを取得し、ブロックチェーンの最後のNブロックからランダムに選択されたいくつかのトランザクションを計算し、その結果のハッシュを返す場合にマイニングアルゴリズムを使用することです。これには2つの重要な利点があります。第一に、イーサリアムのコントラクトにはあらゆる種類の計算が含まれるため、イーサリアムにおけるASICは基本的に一般的な計算用のASIC、つまり優れたCPUになります。第二に、マイニングにはブロックチェーン全体へのアクセスが必要なため、マイナーはブロックチェーン全体を保存、少なくともすべてのトランザクションを検証できる能力が必要となります。これにより、集中型のマイニングプールが不要になります。マイニングプールは、報酬の分配のランダム性を調整するという正当な役割を果たすことができますが、この機能は、中央管理を行わないピアツーピアのプールでも同様に果たすことができます。

このモデルは未検証であり、マイニングアルゴリズムとしてコントラクト実行を使用する場合、ある種の巧妙な最適化を避けるために、困難が発生する可能性があります。しかし、このアルゴリズムの面白いところは、あるASICを妨害するために特別に設計された大量のコントラクトをブロックチェーンに導入することで、誰もが「毒を盛る」ことができるという点です。 ASICメーカーがこのようなトリックを使って攻撃することには、経済的なインセンティブが存在します。このように、私たちが開発しているソリューションは、純粋に技術的なものではなく、究極的には適応経済的なヒューマンソリューションです。

スケーラビリティ

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

このような大きなブロックチェーンサイズの問題は、集中化のリスクとなります。ブロックチェーンのサイズが大きくなり、例えば100TBになったとすれば、ごく少数の大企業だけがフルノードを稼働させ、一般ユーザーはすべて軽量なSPVノードを使うというシナリオが考えられます。このような状況では、全ノードが団結して、不正を行い、利益を得ようとするおそれが生じます(ブロック報酬を変更し、不正にBTCを得るなど) 。ライトノードは、このような不正をすぐに検知することはできません。もちろん、誠実なフルノードが少なくとも1つは存在するでしょうし、数時間後にはRedditのようなチャネルを通じて不正行為に関する情報が伝わってくるでしょうが、その時点では遅すぎます。特定のブロックをブラックリストに登録するのは通常のユーザー任せとなり、これは、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]と一致しないことを確認できます。

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

まとめ

イーサリアムのプロトコルは、もともと暗号通貨のアップグレード版として考えられたもので、高度に汎用化されたプログラミング言語によって、オンブロックチェーンのエスクロー、引き出し制限、金融コントラクト、ギャンブル市場などの高度な機能を提供します。イーサリアムのプロトコルは、どのアプリケーションも直接「サポート」することはありませんが、チューリング完全なプログラミング言語があるということは、理論的にはあらゆるトランザクションタイプやアプリケーションに対する任意のコントラクトを作成できることを意味します。しかし、イーサリアムの面白さは、イーサリアムのプロトコルが単なる通貨の域をはるかに超えている点にあります。分散型ファイルストレージ、分散型計算、分散型予測市場などのプロトコルは、計算産業の効率を大幅に向上させる可能性を秘めており、経済的なレイヤーを初めて追加することで、他のピアツーピアプロトコルにも大きな影響を与えます。最後に、お金とは全く関係のないアプリケーションも充実しています。

イーサリアムは、データストレージ、ギャンブル、金融など特定の用途に限定されたクローズドな単一目的のプロトコルではなく、オープンエンドな設計になっており、今後数年間で非常に多くの金融・非金融プロトコルの基盤となるには非常に適していると考えています。

注意事項と参考文献

注意事項

眼の肥えた読者であれば、実際にはビットコインアドレスは楕円曲線公開鍵のハッシュであり、公開鍵そのものではないと思われるかもしれません。ですが、実際には、Pubkeyハッシュを公開鍵そのものと呼ぶのは、完全に正当な暗号用語用法です。ビットコインの暗号技術は、公開鍵がECC pubkeyのハッシュからなり、署名がECC pubkeyとECC署名を連結したものからなり、検証アルゴリズムは、署名のECC pubkeyを公開鍵として提供されたECC pubkeyのハッシュと照合し、さらにECC署名をECC pubkeyと照合するという、カスタムデジタル署名アルゴリズムであると考えられるからです。
技術的には、11個の前ブロックの中央値です。
内部的には、2も「CHARLIE」も数字^fn3で、後者は基数256のビッグエンディアン形式数列です。数字は最小0、最大2²⁵⁶-1です。

参考文献

ホワイトペーパーの履歴については、こちらのwiki(opens in a new tab)を参照してください。

多くのコミュニティ主導のオープンソースソフトウェアプロジェクトと同様、イーサリアムは開始当初から進化してきました。イーサリアムの最新の開発や、どのようなプロトコル変更が成されているかについて学ぶにはこちらのガイドをご覧になってください。