メインコンテンツへスキップ

ページの最終更新日時: 2026年2月26日

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

この入門書は、2015年のプロジェクトのローンチ前に、Ethereumの創設者であるVitalik Buterinによって2014年に初めて公開されました。 多くのコミュニティ主導のオープンソースソフトウェアプロジェクトと同様に、Ethereumも当初の構想から進化を遂げてきたことは特筆に値します。

_数年前のものですが、これはEthereumとそのビジョンに関する有用な参照情報であり、正確な表現であり続けるため、私たちはこの論文を維持しています。 Ethereumの最新の開発動向や、プロトコルへの変更がどのように行われるかについて学ぶには、こちらのガイドをお勧めします。

ホワイトペーパーの過去のバージョンまたは正規版[2014年12月版]をお探しの研究者や学術関係者の方は、こちらのPDFをご利用ください。

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

2009年のサトシ・ナカモトによるBitcoinの開発は、裏付けや「内在的価値 (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年代の匿名電子マネープロトコルは、チャウミアンブラインドとして知られる暗号プリミティブに依拠しており、高度なプライバシーを提供しましたが、このプロトコルは中央集権型の仲介者に依存していたため、牽引力を得ることができず、大きな失敗に終わりました。 1998年、Wei Daiのb-money (opens in a new tab)は、計算パズルを解くことと分散型コンセンサスによって通貨を作成するというアイデアを導入した最初の提案となりましたが、その提案では分散型コンセンサスが実際にどのように実装できるかについての詳細が欠けていました。 2005年、Hal Finneyは「再利用可能なプルーフ・オブ・ワーク (opens in a new tab)」という概念を導入しました。これはb-moneyのアイデアとAdam Backの計算上困難なHashcashパズルを組み合わせて暗号通貨の概念を作り出すシステムでしたが、バックエンドとして信頼できるコンピューティングに依存していたため、これもまた理想には及びませんでした。 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'は、おおよそ次のように定義できます。

  1. TXの各入力について：

    • 参照されたUTXOがSにない場合は、エラーを返します。
    • 提供された署名がUTXOの所有者と一致しない場合は、エラーを返します。
  2. すべての入力UTXOの額面の合計が、すべての出力UTXOの額面の合計より小さい場合は、エラーを返します。
  3. すべての入力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つのブロックを生成することを目的としており、各ブロックにはタイムスタンプ、ナンス、前のブロックへの参照（すなわちハッシュ）、および前のブロック以降に行われたすべてのトランザクションのリストが含まれています。 この仕組みにより、ビットコインレジャーの最新状態を表し、絶え間なく更新され、永続的に大きくなる「ブロックチェーン」を生成します。

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

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

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

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

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

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

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

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

マークルツリー

ビットコインにおけるSPV

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

右：マークルツリーのいずれかの部分を変更しようとすると、最終的にチェーンの上部のどこかで矛盾が生じます。

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

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

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

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

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

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

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

スクリプティング

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

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

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

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

イーサリアム

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

Ethereumアカウント

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

  • ナンス：各トランザクションが一度しか処理されないことを保証するために使用されるカウンター
  • アカウントの現在のEther残高
  • アカウントのコントラクトコード（存在する場合）
  • アカウントのストレージ（デフォルトでは空）

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

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

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

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

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

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

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

メッセージ

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

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

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

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

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

イーサの状態遷移

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

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

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

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

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

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

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

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

コード実行

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

  • スタック：値のプッシュとポップが可能な後入れ先出し（last-in-first-out）コンテナ
  • メモリ：無限に拡張可能なバイト配列
  • コントラクトの長期ストレージ：キーと値のストア。 計算が終わるとリセットされてしまうスタックやメモリとは異なり、ストレージは長期にわたって保持される。

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

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

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

Ethereum適用ブロック図

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

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

このアプローチは、ブロックごとにすべての状態を保存する必要があるため、一見非常に効率が悪いように見えますが、実際にはビットコインと同等程度です。 状態がツリー構造に格納されており、ブロックごとにツリーのごく一部を変更するだけで済むためです。 したがって、一般的に、隣接する2つのブロック間ではツリーの大部分が同じであるべきであり、そのためデータは一度保存され、ポインタ（すなわち、サブツリーのハッシュ）を使用して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）によって維持される「データフィード」コントラクトを通じて行うことです。これは、その当事が必要に応じてコントラクトを更新できるように設計されており、他のコントラクトがそのコントラクトにメッセージを送信して価格を提供する応答を得ることができるインターフェースを提供します。

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

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

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

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

IDおよびレピュテーションシステム

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

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

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

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

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

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

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

分散型自律組織

「分散型自律組織」の一般的な概念は、仮想エンティティの概念で、おそらく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)など、数多くのピアツーピアギャンブルプロトコルをEthereumブロックチェーン上で実装できます。 最も単純なギャンブルプロトコルは、実際には次のブロックハッシュの差分のコントラクトになりますが、そこからさらに高度なプロトコルを構築し、手数料がゼロに近く、不正行為ができないギャンブルサービスを作ることができます。

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

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

その他および懸念事項

修正GHOST実装

「Greedy Heaviest Observed Subtree」（GHOST）プロトコルは、Yonatan SompolinskyとAviv Zoharによって2013年12月 (opens in a new tab)に初めて導入されたイノベーションです。 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ブロックに含まれるアンクルは、以下の性質を持っていなければならない。
    • 2 <= k <= 7であるBのk世代の祖先の直接の子でなければなりません。
    • Bの祖先になることはできない。
    • アンクルは有効なブロックヘッダーである必要があるが、以前に検証されたブロックである必要はなく、有効なブロックであるかを問わない。
    • アンクルは、以前のブロックに含まれていたすべてのアンクル、および同じブロックに含まれていた他のすべてのアンクルとは異なったものでなければならない(二重包含は不可)。
  • ブロックBのアンクル U 1つにつき、Bのマイナーはコインベース報酬に3.125％追加され、Uのマイナーは標準のコインベース報酬の93.75％を獲得する。

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

手数料

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

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

  1. トランザクションはk個の操作につながり、それを含むマイナーには報酬kRが提供されます。ここでRは送信者によって設定され、kとRは（おおよそ）事前にマイナーに可視です。
  2. ある操作は、どのノードに対しても処理コストCがかかります（すなわち、すべてのノードの効率は等しい）。
  3. N個のマイニングノードがあり、それぞれが全く同じ処理能力を持っています（すなわち、全体の1/N）。
  4. マイニングを行わないフルノードは存在しない。

予測される報酬がコストよりも大きい場合、マイナーは意欲的にトランザクションを処理します。 したがって、マイナーが次のブロックを処理する確率は1/Nであるため、期待される報酬はkR/Nであり、マイナーの処理コストは単純にkCです。 したがって、マイナーはkR/N > kC、つまりR > NCとなるトランザクションを含めます。 Rは送信者から提供される操作ごとの料金であり、送信者がトランザクションから得る利益の下限です。そしてNCはネットワーク全体が操作を処理するためのコストです。 そのため、マイナーには全体的な実用的利益がコストを上回るようなトランザクションだけを処理するインセンティブがあります。

しかし、現実にはこの前提には当てはまらない重要なものがいくつかあります。

  1. マイナーは、他の検証ノードよりも高いコストを払ってでもトランザクションを処理する。その理由は余分な検証時間がブロックの伝播を遅らせ、その結果、ブロックがステイル化する可能性が高くなるため。
  2. マイニングを行わないフルノードは存在する。
  3. マイニングパワーの配分は、実際には非常に不平等になる可能性がある。
  4. ネットワークに害を及ぼすことを企てる投機家、政敵、精神異常者などが存在し、他の検証ノードが支払うコストよりもはるかに低いコストのコントラクトを巧みに設定できる。

（1）はマイナーが含めるトランザクションを減らす傾向をもたらし、 （2）はNCを増加させます。したがって、これらの2つの効果は少なくとも部分的に 互いに相殺されます。 out.どのように？ (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のような形式のコードを持つコントラクトを見つけ、最初のステップは実行できるが2番目のステップは実行できないだけのガスでトランザクションを送信します（すなわち、引き出しは行うが残高を減らさない）。 実行が途中で停止した場合、変更内容は元に戻されるため、このコントラクトの作成者はこのような攻撃に対する保護を心配する必要はない。
  • 金融コントラクトは、リスクを最小限に抑えるために、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: (プログラムの1ステップを実行し、ストレージの変更を記録)

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

通貨と発行

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

  • 1: wei
  • 1012: Szabo
  • 1015: Finney
  • 1018: 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.198X1.458X2.498X
購入者83.5%68.6%40.0%
売却前に使用した積立8.26%6.79%3.96%
売却後に使用した積立8.26%6.79%3.96%
マイナー0%17.8%52.0%

長期供給成長率(パーセント)

イーサリアムのインフレ

通貨発行は線形であるにもかかわらず、Bitcoinと同様に、時間の経過とともに供給量の増加率はゼロに近づく傾向があります。

上記のモデルにおける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%の場合、供給量が26Xに達すると、毎年0.26Xが採掘され、0.26Xが失われ、均衡が生まれます）。

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

マイニングの中央集権化

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

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

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

スケーラビリティ

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

このような大きなブロックチェーンサイズの問題は、集中化のリスクとなります。 ブロックチェーンのサイズが大きくなり、例えば100TBになったとすれば、ごく少数の大企業だけがフルノードを稼働させ、一般ユーザーはすべて軽量なSPVノードを使うというシナリオが考えられます。 そのような状況では、フルノードが結託して、何らかの収益性の高い方法で不正を行う（例：ブロック報酬を変更し、自分たちにBTCを与える）ことに全員が同意する可能性が懸念されます。 ライトノードは、このような不正をすぐに検知することはできません。 もちろん、誠実なフルノードが少なくとも1つは存在するでしょうし、数時間後にはRedditのようなチャネルを通じて不正行為に関する情報が伝わってくるでしょうが、その時点では遅すぎます。特定のブロックをブラックリストに登録するのは通常のユーザー任せとなり、これは、51%攻撃を成功させる場合と同程度の大規模なものとなり、おそらく実行できない調整の問題となります。 Bitcoinの場合、これは現在問題ですが、この問題を軽減するPeter Toddによって提案された (opens in a new tab)ブロックチェーンの修正が存在します。

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

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

結論

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

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

注記と参考文献

注記

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

参考リンク

  1. 内在的価値 (opens in a new tab)
  2. スマートプロパティ (opens in a new tab)
  3. スマートコントラクト (opens in a new tab)
  4. B-money (opens in a new tab)
  5. 再利用可能なプルーフ・オブ・ワーク (opens in a new tab)
  6. 所有者権限付きの安全な財産権 (opens in a new tab)
  7. ビットコインホワイトペーパー (opens in a new tab)
  8. Namecoin (opens in a new tab)
  9. Zookoの三角形 (opens in a new tab)
  10. カラードコインホワイトペーパー (opens in a new tab)
  11. Mastercoinホワイトペーパー (opens in a new tab)
  12. 分散型自律組織、Bitcoin Magazine (opens in a new tab)
  13. 簡易ペイメント検証 (opens in a new tab)
  14. マークルツリー (opens in a new tab)
  15. パトリシアツリー (opens in a new tab)
  16. GHOST (opens in a new tab)
  17. StorJと自律エージェント、Jeff Garzik (opens in a new tab)
  18. Mike Hearn on Smart Property at Turing Festival (opens in a new tab)
  19. Ethereum RLP
  20. Ethereumマークルパトリシアツリー
  21. マークルサムツリーに関するPeter Toddの論文 (opens in a new tab)

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

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

最終更新： 2026年2月26日

HiroyukiNaitoH (opens in a new tab)
nonnon (opens in a new tab)
sekisanchis (opens in a new tab)
+33

この記事は役に立ちましたか?