[Japanese]-White-Paper.md

次世代スマートコントラクトとディセントラルアプリケーションプラットフォーム

Satoshi Nakamotoが2009年1月にビットコインブロックチェインを最初に世に送り出した時、同時に二つの革命的な殆ど試験されていないコンセプトを示しました。一つはディセントラルなP2Pオンライン通貨であるビットコインで、それは何の後ろ盾も無く、本質的な価値 もなく、発行者もなく、価値を保持してるものです。これまでに通貨としてのビットコインは中央銀行がない通貨という政治的な観点からと、大きく上下する価格という観点から人々の注目を集めてきました。しかしながら、そこにはもう一つの、同じぐらい重要なSatoshiの大きな実験という役割がありました。: proof of workをベースとしたブロックチェインによって、トランザクションの順序を公的に合意するというコンセプトです。アプリケーションとしてのBitcoinは first-to-fileシステムとして説明できます。:もし一つのエンティティが50BTC持っており、同じ50BTCをAとBとに同時に送った時、最初に確定したトランザクションのみが実行されます。二つのトランザクションのうちどちらが先に行われたかを決定する本質的な方法はありません。そのため数十年ディセントラルなデジタル通貨の開発ができませんでした。Satoshiのブロックチェインは最初の信頼できるディセントラルな解決法です。今、人々の注目はこのBitcoinの二つ目のパートに向かい始めました。どのようにブロックチェインのコンセプトを単なるお金以上のものに適用するかということです。

良く引き合いに出されるアプリケーションとしては、ブロックチェイン上のデジタル資産をカスタム通貨や金融商品を表すために使用するもの(colored coins)、基礎となっている、実体のあるデバイスのオーナーシップを表すために使用するもの(smart property)、domain nameのような代替の効かない資産を表すために使用するもの(Namecoin)、等があります。さらに進んだアプリケーションとして、ディセントラルな両替所、金融デリバティブ、P2Pギャンブル、ブロックチェイン上の個人認証と評判システム等があります。その他の調査すべき重要な分野は”smart contract”です - 先に決められた任意のルールに従ってデジタル資産を自動的に動かして行くシステムです。例えば以下のような公庫契約を結ぶとしましょう「Aは一日にXまで通貨を引き出せる。Bは一日にYまで通貨を引き出せる。AとBは一緒にいくらでも引き出せる。AはBの権利をシャットオフすることができる」。この論理的な拡張が decentralized autonomous organizations(DAOs)です-それは、組織全体の資産と内規のエンコードを含む長期のsmart contractです。Ethereumが世の中に出そうとしているものは、完全に自立したチューリング完全なプログラミング言語をビルトインしたブロックチェインです。任意の状態遷移関数をエンコードしたcontractを作る事ができます。ユーザーは上に挙げた全てのシステムを作ることができます。さらに我々が未だ想像すらしていない他の物を単に少しの行数のコードを書く事で実現できます。

Table of Contents

• 目次
  • 状態遷移システムとしてのBitcoin
  • マイニング
  • マークルツリー
  • その他のブロックチェインアプリケーション
  • スクリプティング
• Ethereum
  • Ethereum アカウント
  • メッセージとトランザクション
  • Ethereum 状態遷移関数
  • コード実行
  • ブロックチェインとマイニング
• アプリケーション
  • トークンシステム
  • 金融デリバティブ
  • 個人認証と評価システム
  • ディセントラルファイルストレージ
  • ディセントラル自律組織
  • その他のアプリケーション
• 雑録と関心事項
  • 修正GHOST実装
  • フィー
  • 計算とチューリング完全
  • 通貨と発行
  • マイニング集中
  • スケーラビリティ
• 結論
• 参考文献とさらに進んだ情報

Bitcoinと現状のコンセプトの紹介

歴史

ディセントラルデジタル通貨のコンセプトは、プロパティ登録のようなアプリケーションと同様にここ数十年話題に上っていました。1980年代、90年代の匿名e-cashプロトコルは、主にChaumian blindingとして知られている暗号基礎に依存していましたが、強力なプライバシーを持った通貨を生み出しました。しかし、そのプロトコルは中央集権的な仲介人に依存していたため、牽引力を得る事に失敗しました。1998年、Wei Daiのb-moneyが最初のディセントラル的な合意をコンピューター計算のパズルを解く事で行うお金のアイデアの提案となりました。しかし、その提案は、どのようにディセントラル的な合意を実装するのかの詳細が欠けていました。2005年、Hal Finneyは再利用可能 proof of workのコンセプトを紹介しました。そのシステムはb-moneyからのアイデアと、Adam Backの暗号通貨のコンセプトを作り出す、ハッシュキャッシュパズルの計算困難さを組み合わせたものでした。しかし再び、バックエンドのtrusted computingに依存してることで理想どおりには行きませんでした。

通貨はトランザクションの順番が非常に重要な first-to-fileのアプリケーションなので、ディセントラル通貨の実現にはディセントラルコンセンサスの解決法が必要となります。Bitcoin以前の全ての通貨プロトコルが直面していた主な障害は以下の事実です。長年、セキュアなビザンチントレラントな複数パーティの合意システムが研究されてきていましたが、全てのプロトコルは問題の半分しか解決していませんでした。プロトコルは全てのシステムへの参加者が知られていると仮定しており、”もしN個のパーティが参加したならばシステムはN/4までのずるい参加者に耐えうる”というような形でのセキュリティマージンを決めていました。しかしながら、問題は匿名なので以下のようなsybil attackに対してセキュリティマージンが脆いということです。一人の攻撃者が数千個ものシミュレートノードをサーバーに作ったり、ボットネットを作ったりしてマジョリティシェアを脅かす手法です。 Satoshiによってもたらされたイノベーションは非常にシンプルなディセントラル合意プロトコルとproof of workを組み合わせたものです。合意プロトコルはノード間のトランザクションを１０分毎にブロックにしてブロックチェイン上に加え続ける方法に基づいています。proof of workはシステムにおいてどのノードが正しいかを選択していくメカニズムに基づいています。巨大な計算パワーを持ったノードはそれに応じた巨大な影響力を持ちますが、ネットワークにつながった全体の計算パワーに追いつく事は、百万ノードのシミュレーションを行うより遥かに困難です。Bitcoinのブロックチェインモデルはあまり洗練されて無くシンプルに感じますが、充分に実用的であることが証明されています。そして今後五年間で世界中で200種類を超える通貨やプロトコルの基礎をなすことでしょう。

状態遷移システムとしてのBitcoin

技術的な観点からすると、Bitcoinの元帳は、すべての存在するbitcoinのオーナーシップの状態と、トランザクションとその結果によって新しい状態に遷移させる状態遷移関数からなる状態遷移システムだと考える事ができます。標準的な銀行システムの場合、例えば、状態はバランスシートであり、トランザクションは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

Bitcoinにおける”状態”とは、生成されたがまだ使用されていない、すべてのコイン(技術的には、まだ使われていないトランザクションアウトプット:UTXO)の集合です。それぞれのUTXOは単位とオーナー(暗号の公開鍵である20byteのアドレス)をもっています。トランザクションは一つ以上のインプットを持っており、それぞれのインプットは存在しているUTXOへのリファレンスとオーナーのアドレスに紐づけられた秘密鍵へのリファレンスを持っています。また一つ以上のアウトプットを持っており、それぞれのアウトプットは状態に追加される新しいUTXOを含んでいます。

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

1. TXのそれぞれのINPUTに対して:
   • 参照されているUTXOが S, の中に無いとき、エラーを返す
   • 与えられた署名がUTXOのオーナーと一致しないとき、エラーを返す
2. すべてのインプットのUTXOの単位の合計がすべてのアウトプットのUTXOの単位の合計より小さい場合、エラーを返す。
3. 全てのインプットのUTXOを取り除き、全てのアウトプットのUTXOを追加した S を返す。

第一ステップの最初半分は存在していないコインを使用するトランザクションを防ぎます。第一ステップの後半半分は他人のコインを使用するトランザクションを防ぎます。第二ステップは価値の保持を保証します。これを支払いに使用するためのプロトコルは以下のようなものです。今、アリスがボブに11.7BTC送金したいとします。最初にアリスは少なくとも11.7BTC以上になる彼女が保持しているUTXOのセットを探します。現実的に、アリスはぴったり11.7BTCは見つからなかったとします。すなわち、最も小さいセットで6+4+2=12 BTCを得たとします。彼女はそこで、３インプット、２アウトプットのトランザクションを作成します。最初のアウトプットはボブがオーナーのアドレスに11.7BTC、二つ目のアウトプットは残った0.3BTCをおつりとして、アリス自身に送ります。

マイニング

もし信用できる中央集権サービスが欲しいならば、システムを実装するのは簡単です; ただ単にそのままコードを書けば良いだけです。しかしながら、ビットコインではディセントラル貨幣システムを創ろうとしているので、状態遷移システムを、全ての人がトランザクションの順番に合意するシステムと組み合わせたものを必要とします。Bitcoinのディセントラルの合意プロセスはネットワーク中のノードに継続的に”blocks”と呼ばれるトランザクションのパッケージを創り続けることを求めます。ネットワークは大まかに言って１０分毎に一つのブロックを生成しようとします。それぞれのブロックにはタイムスタンプ、nonce、一つ前のブロックに対するリファレンス（一つ前のブロックのハッシュです）、一つ前のブロック以降に発生した全てのトランザクションのリストが含まれています。これは延々と大きくなり続けるブロックチェインを創り続けます。そこではBitcoin元帳の最新の状態を表現したものが常にアップデートされつづけています。

このパラダイムで表されている、ブロックが正しいかチェックするアルゴリズムは以下のようなものです。

1. ブロックからリファレンスされている一つ前のブロックが存在していて有効であるかチェック
2. ブロックのタイムスタンプが一つ前のブロック^[2] よりも大きくかつ２時間以内であるかチェック
3. ブロックのproof of workが有効かどうかチェック
4. S[0] を一つ前のブロックの状態とする
5.  TX を n 個のトランザクションを持つブロックのトランザクションリストとする。 0...n-1,のすべてのiに対して S[i+1] = APPLY(S[i],TX[i]) どれか一つのアプリケーションでもエラーを返した場合、exitしてfalseを返す
6. trueを返し、 このブロックの最後に S[n] 状態として登録

本質的に、ブロック内のそれぞれのトランザクションは有効な状態遷移を起こすはずです。ブロック内にはどのような方法でも状態はエンコードされていないことに注意しましょう； 有効なノードによって抽象的に記憶されており、どのブロックも起源となるステートから全てのブロックの全てのトランザクションを順次適用することで、セキュアに計算することができます。マイナーがトランザクションをブロックに入れる順序が重要であることに注意しましょう；もしAとBの二つのトランザクションがブロックの中にあるとしてBがAによって作られるUTXOを消費する場合、AがBより先にくればブロックは有効ですが、逆では有効ではありません。

ブロックのバリデーションの興味深いパートはproof of workのコンセプトです；条件は以下のようなものです。全てのブロックのSHA256ハッシュを256bitの数と考えた時に、その数が動的に最適化されるターゲット、これを書いている現在はおおよそ2¹⁹²ですが、より小さい数である事です。この目的は、ブロック生成をコンピュータにとって"hard"なものにすること、それによってsybil攻撃者が彼らの思い通りに全体のブロックチェインを作り直すことを防ぐ事にあります。SHA256は完全に予想不可能な擬似乱数関数となるように設計されているので、有効なブロックを作る方法は繰り返しnonceをインクリメントして新しいハッシュが条件に合うかをチェックするしかありません。現在のターゲッット2¹⁹²は平均的に2⁶⁴回のトライが必要になることを意味します；ターゲットはネットワークによって2016ブロック毎に再キャリブレーションされ、ネットワーク上のノードで新しいブロックを生成するのに毎回１０分かかるように変更されます。マイナーのこの演算に対して報いるために、それぞれのブロックの発掘者は誰からの送信でもない25BTCを自分自身に与えるトランザクションを含める権利が与えられます。加えて、もしどれかのトランザクションがアウトプットよりインプットの単位が多い場合、その差はマイナーに"transaction fee"として与えられます。ちなみに、これがBTCが発行される唯一の方法です；最初の状態はcoinを一つも含んでいません。

マイニングの目的を理解するために、ずるい攻撃者が何を起こすか考察してみましょう。Bitcoinのベースとなっている暗号は安全である事が知られていますので、攻撃者はBitcoinシステムの暗号によって直接守られていない部分を攻撃してくるでしょう：つまりトランザクションの順番です。攻撃者の戦略は簡単です：

1. 100BTCを商品との交換で小売り商人に送ります (即座に送付されるデジタルな商品が望ましい)
2. 商品の到着を待ちます
3. 同じ100BTCを自分自身に送るトランザクションを発生させます。
4. ネットワークに自分自身に送るトランザクションの方が先に発生したと信じ込ませるようにトライします。

マイナーがトランザクションをブロックに含めた数分後、ステップ１が発生します。そのブロックを270000番だとします。約一時間後、５個のブロックがそのブロックの後にチェインとなって加えられています。それぞれのブロックはトランザクションを示しており”confirm"されています。このタイミングで小売り商人は支払いが完了したと考え商品を送ります；我々はデジタル商品だと仮定していますので、配送は一瞬です。そこで、攻撃者は自分自身に100BTCを送るトランザクションを作ります。ただ単純に攻撃者がそのトランザクションを世に放ったとしても承認されません；マイナーは APPLY(S,TX) を実行し、TX が現在の状態にもう残っていないUTXOを使用していることを知るからです。その代わりに攻撃者はブロックチェインの”fork”を作ります。ブロック269999を指している他のバージョンのブロック270000、そこでは新しいトランザクションが古いものに置き換わっている、をマイニングし始めます。ブロックデータが異なりますので、この行為はproof of workを再び行うことが必要です。さらに、攻撃者が作った新しいバージョンのブロック270000は異なるハッシュを持っているので、オリジナルのブロック270001〜270005は、そこを指し示していません；それゆえ、オリジナルのチェインと攻撃者の新しいチェインは完全に分離しています。フォークしたものの中で最も長いブロックチェインが真であるというルールであるため、正当なマイナーは270005チェインに対して計算していきます。一方で攻撃者は自分のみで270000チェインに対して計算を続けて行きます。攻撃者が自分のブロックチェインを最も長くするためには、彼はキャッチアップするためには残りのネットワーク全部の計算パワーを上回る必要があります（よって、51%アタックと呼ばれます）。

マークルツリー

左: 枝の正当性を証明するのに、マークルツリー上の少数のノードのみで充分である

右: マークルツリーの一部を変更しようとすると結果的にチェインの上部のどこかで不整合が発生する

重要なbitcoinのスケーラビリティの特徴はブロックがマルチレベルのデータ構造にストアされていることです。ブロックの”hash”とは実際は200byte程のブロックヘッダのハッシュでそこにはタイムスタンプ、nonce、前のブロックのhash、ブロック内の全てのトランザクションのハッシュがおさめられているマークルツリーと呼ばれるデータ構造のルートハッシュが含まれています。マークルツリーは二分木の一種で、データを含むツリー下部の大量のリーフノードの集合と、二つの子供のハッシュを持っている中間ノードの集合と、自身の二つの子供のハッシュから作られるツリーの頂点となる一つのルートノードから構成されます。マークルツリーを使用する目的は、ブロックの中のデータを少しづつ引き出すことを可能にするためです：ノードは一つのソースからブロックヘッダのみをダウンロードすることが可能です。他のソースから自分と関連のある非常に小さい部分木をダウンロードできます。 そして、データが正しいことが保証されます。このようなことが成り立つ理由はハッシュが上部に向かって伝達していくからです：もしずるいユーザがマークルツリーの下部を嘘のトランザクションとと入れ替えようとした場合、この変更は上部のノードの変更を引き起こし、そしてさらに上部のノードの変更を引き起こします。最終的にツリーのルートとブロックのハッシュが変更されることになり、全く違うブロックを登録するプロトコルを引き起こします（ほぼ確実に不適合なproof of workとなります）。

マークルツリープロトコルは間違いなく長期のサステナビリティに必要不可欠なものです。全てのブロックを処理して記憶しているBitcoinネットワーク上の”full node”は2014年の4月現在15GB程のディスクスペースを必要とします。そして、一月毎にギガバイト以上増加中です。現在、この値はデスクトップコンピュータでは記憶可能ですが、スマートフォンでは不可能です。そして今後は、ビジネスもしくはホビーとしてのみ参加可能になります。”simplified payment verification(SPV)”として知られているプロトコルは他のクラスのノードの存在も認めています。それは”light node”と呼ばれ、ブロックヘッダをダウンロードし、ブロックヘッダのproof of workを検証し、それから自分に関係しているトランザクションに関連するbranchのみをダウンロードします。これらのことによってlight nodeはBitcoinトランザクションの状態や現在のバランスシートに関わらず、セキュリティの保証がありながら、全体のブロックチェインのほんの一部しかダウンロードせずに済みます。

その他のブロックチェインアプリケーション

ブロックチェインをもとにしたアイデアや他のコンセプトにブロックチェインのアイデアを適用させることには長い歴史があります。2005年, Nick Szaboは"secure property titles with owner authority" というコンセプトを発表しました。文献のなかでは新しいreplicated database技術について述べられています。ブロックチェインをベースにして誰がどこの土地をもっているかの登録や、居住地、不法占有やgerogian land tax(土地は皆のもの)等のコンセプトを含んだ洗練されたフレームワークを作り上げていました。残念な事に、その時には有効なreplicated databaseシステムは無かったので、そのプロトコルが実際に実装されることはありませんでした。しかしながら、2009年以降、ひとたびbitcoinのディセントラル合意システムが開発された後、いくつかの他のアプリケーションが急激に広がり始めました。

• Namecoin 2010年に作られた Namecoin は、ディセントラルの名前登録データベースとして説明できます。TorやBitcoinやBitMessageのようなディセントラルプロトコルでは他の人々と交流するためにアカウントを証明する何らかの方法が求められます。しかし、全てのソリューションにおいて、1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy のような擬似乱数ハッシュのみが識別子として使用されます。理想的には"george"のような名前をアカウントとして持ちたいと考えます。しかし問題は、ある人が"geroge"という名前のアカウントを作った後に他の人が同じ方法で"george"を登録してなりすますことが可能になってしまうことです。唯一の解法はfirst-to-fileパラダイムです。そこでは最初の登録者のみが成功し、それ以降の登録者は失敗します。これはBitcoinの合意形成プロトコルに完璧に適合します。Namecoinは最も古く、そして最も成功した、そのようなアイデアをつかった名前登録の実装です。
• Colored coins  - colored coins の目的は自分のデジタル通貨を作る事ができるようにするためのプロトコルを提供することです - または、流通単位が一つだけの通貨という重要なケースであるデジタルトークンをブロックチェイン上で提供するものです。 colored coinsのプロトコルでは、あるBitcoinのUTXOに対してcolorをパブリックにアサインした新しい通貨を発行します。 そして、プロトコルは再帰的に他のUTXOのcolorを、それを使ったトランザクションのインプットのcolorと同じものに決定していきます(inputが複数のcolorの場合は特別なルールが適用されます)。ユーザーにあるcolorを持ったUTXOのみのwalletsを保持することができ、通常のbitoinのようにそれを送る事ができます。そしてブロックチェインをバックトラックすることによって受け取ったいかなるUTXOのcolorも決める事ができます。
• Metacoins - metacoinの基底にあるアイデアは、bitcoinのトランザクションをmetacoinのトランザクションをストアすることに用いながら、異なる状態関数  APPLY' を持つプロトコルをBitcoin上に持つ事です。metacoinのプロトコルはBitcoinブロックチェイン上に表れる無効なmetacoinトランザクションを防ぐ事ができないため、APPLY'(S,TX) がエラーを返すならば、APPLY'(S,TX) = S というルールが付け加えられます。このことはBitcoin自体の中にインプリメントできない先進的な機能を追加した任意の仮想通貨を作るのに簡単なメカニズムを提供します。そして、すでにBitcoinプロトコルによって使用されているネットワークやマイニングを利用できるため非常にローコストとなります。

このように、一般的には、合意形成プロトコルを作るのに二つのアプローチがあります：独自のネットワークを作る方法、Bitcoin上のプロトコルを作る方法です。最初のアプローチはNamecoinのようなアプリケーションでは成功していますが、実装は難しいです：それぞれの独自の実装は独自のblockchainを立ち上げないといけませんし、ネットワークのコードと必要な状態遷移の全てを作ってテストせねばなりません。さらに、ディセントラルによる合意テクノロジーのアプリケーション集合はべきじょう則に従います。殆どのアプリケーションは自身のblockchainを保証するには非常に小さく、そして、ディセントラルアプリケーションの数自体、特にお互いにインタラクトする必要があるディセントラル自律組織、は非常に多いと我々は予測しています。

一方で、Bitcoinをベースとしたアプローチは、Bitcoinのsimplified pyament verification を引き継いでいないという欠陥があります。SPVはBlockchainの深さを有効性のプロキシとして使用することができるため、Bitcoin上ではうまく機能します：ひとたびトランザクションの子孫が充分に伸びれば合法的な状態だと言っても安全です。一方でblockchainをベースとしたメタプロトコルは、そのプロトコルで有効でないトランザクションをblockchainに含めないということを強制することができません。よって、完全にセキュアなSPVメタプロトコル実装は、トランザクションが有効か有効でないかを決定するためにBitcoinのblockchainの最初からバックワードスキャンする必要があります。現在のすべての”light”なBitcoinベースのメタプロトコル実装はサーバが提供するデータの信用に依存しています。仮想通貨の主要な目的は信用しなければならないということを無くすことですから、これらのことは間違いなく最高とは言いがたいものです。

スクリプティング

拡張無しでも、Bitcoinのプロトコルは弱いバージョンの”smart contracts”のコンセプトを容易にします。BitcoinのUTXOは公開鍵のみではなく、簡単なスタックベースのプログラミング言語で記述されたもっと複雑なスクリプトによって所有することができます。このパラダイムでは、そのUTXOを使用するトランザクションはスクリプトを満たすデータを提供せねばなりません。実際に、基本的な公開鍵によるオーナーシップのメカニズムさえもスクリプトによって実装されています：スクリプトは入力として楕円曲線署名を受け取り、UTXOを所有するアドレスとトランザクションに対して検証し、検証が正しければ１をそうでなければ０を返します。 もっと複雑な他のスクリプトも様々なユースケースのために存在しています。例えば、与えられた３つの秘密鍵のうち、二つの署名を要求する契約("multisig")のためのスクリプトを記述できます。会社のアカウントや、安全な救済可能な口座 、小売りとのエスクローにとって有益です。スクリプトはまた、コンピューティング問題の賞金を払うためにも使用できます。また、"これだけの額のDogecoinトランザクションを私に送った、というSPVの証明を示したらこのBitcoin のUTXOはあなたのものです"というような本質的にディセントラルの仮想通貨の交換スクリプト契約さえも可能です。

しかしながら、Bitcoinに実装されているスクリプティング言語はいくつかの重要な制限があります。

• チューリング完全性の欠如 - Bitcoinのスクリプティング言語は非常に多くのコンピューティングのサブセットをサポートしますが、全てをサポートしている訳ではありません。サポートされていない重要なカテゴリはループです。これはトランザクションの検証が無限ループに陥る事を避けるために決定されました：理論的にはこのことはスクリプティング言語にとって克服できる障害です。なぜなら、どのようなループもただ単にコードをif文とともに何度も繰り返すだけでシミュレーションできるからです。しかしこれはスクリプトにとってメモリが非常に非効率的です。例えば、他の楕円曲線署名アルゴリズムは256回の乗算の繰り返しがコードの中に含まれています。
• Value-blindness - 引き出し可能な量について細かくコントロールするようなUTXOスクリプトを記述する方法がありません。例えば一つの非常に強力なoracle contractユースケースはヘッジング契約で、そこでは、AとBが$1000相当のBTCを預け、30日後にスクリプトで$1000相当のBTCをAに、残りをBに送ります。これはoracleが1BTCのUSDでの価格を決定することが依然として必要となりますが、現状存在する方法では完全な中央集権型インフラストラクチャや信用が必要になるという観点から大幅な改善です。　しかしながら、UTXOはオールオアナッシングなので、様々な種類のUTXOを準備して（例えば３０まですべてKに対し2^KのUTXO）、OにどのUTXOをAに送るべきか、どのUTXOをBに送るべきかを選ばせるという非常に効率の悪いハックによってしか実現できません。
• Lack of state - UTXOは使われるか、使われないかを選べます：それ以上の内部状態を保持するような多段のcontractやスクリプトを記述する方法がありません。これはディセントラル交換所や二段の暗号コミットプロトコル(セキュアなコンピューティングの賞金には必要になります)のような多段オプション契約を作る事を難しくします。これはまた、UTXOは単純なワンオフ契約には使えるがディセントラル組織のようなもっと複雑な状態をもつ契約には使えない、メタプロトコルは実装するのが難しいということを意味します。二値状態のみかつValue-blindnessということは、引き出し制限のような他の重要なアプリケーションも不可能であるということを意味します。
• Blockchain-blindness - UTXOはnonceや一つ前のhashのようなblockchainのデータを参照できません。これは、スクリプティング言語にとって有益な乱数の素を奪うことになり、ギャンブルや他のカテゴリのアプリケーションを厳しく制限します。

これまで仮想通貨上の先進的なアプリケーションを作る３つのアプローチを見てきました：新しいBlockchainを作る、Bitcoin上のスクリプティングを使用する、Bitcoin上にメタプロトコルを作るです。新しいBlockchainを作る事は機能的に無制限の自由度を手に入れることができますが、開発コストと立ち上げに大きな労力を使います。スクリプティングの使用は簡単に実装できて標準化されていますが、できることは非常に限られています。メタプロトコルは、簡単なのですが、スケーラビリティに問題を抱えています。Ethereumを、これらの３つのパラダイムの優位性を同時にもたらす一般的なフレームワークを作ることを目的として開発しました。

Ethereum

Ethereumの目的はスクリプティング、altcoin、blockchain上のメタプロトコルのコンセプトを改善してマージし、開発者にスケーラビリティを持った、標準化された、完全な特性を持った、開発容易で相互運用可能な任意の合意ベースのアプリケーションの作成を可能にすることです。　Ethereumは、必須となる究極の抽象基本レイヤーを作る事によってこれを成し遂げます：任意のオーナーシップやトランザクションフォーマットや状態遷移関数を作る事ができる、smart contractやディセントラルアプリケーションを誰でも記述できるチューリング完全性を持ったプログラミング言語がビルトインされたblockchainです。Namecoinのべアボーンバージョンは二行のコードで記述できます。そして通貨や評判システムのような他のプロトコルは２０行以下で作る事ができます。smart contract、それは暗号的箱のようなもので、価値を持っていてある条件になった時に開ける事ができるものを我々のプラットフォーム上に作る事ができます。Bitcoinスクリプティングによってできるものよりも圧倒的に力を持つことができます。なぜならば我々はチューリング完全性、Value-awarenss, blockchain-awarenessと状態を追加したからです。

Ethereum アカウント

Ethereumでは状態は"accounts"と呼ばれるオブジェクトによって作られます。それぞれのacountは２０バイトのアドレスと、account間の値と情報の直接送受信である状態遷移を持ちます。Ethereum acountは以下の４つのフィールドを持っています。

• nonce それぞれのトランザクションが一度だけ起きることを保証するカウンター
• accountの現在の ether balance
• もし存在するならば、accountの contract code
• accountの storage (デフォルトでは空)

"Ether" はEthereumのメインの暗号燃料で、トランザクションフィーを払うために使われます。一般的に二種類のacountsが存在します。：秘密鍵によってコントロールされる外部に所有されているaccounts、contract codeによってコントロールされるcontract accountsです。外部に所有されるacountはコードを持っておらず、トランザクションを作ってサインすることによって外部に所有されるacountからmessageを送る事ができます：contract acountではるmessageを受け取るたび、codeがアクティベートされ、内部ストレージへの読み書きを許可し、他のmessageを送ったり、contractを作ったりできます。

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

Ethereumの”Messages”はBitcoinのtransactionになんとなく似ています。しかし、３つの重要な違いがあります。第一に、Ethereum messageは外部のエンティティまたはcontractから作る事ができます。一方、Bitcoinのtransactionは外部からしか作る事ができません。第二に、Ethereum messagesにはデータを含む明示的なオプションがあります。最後に、messageの受信者は、それがcontract accountであっても、レスポンスを返すオプションを持ってます:これはEthereum messageは関数のコンセプトを包含していることを意味します。

Ethereumで”transaction”という用語は、外部に所有されるaccountから送られるmessageを保持しておく署名されたデータパッケージへの参照です。トランザクションはmessageの受領者、送付者を明らかにする署名、送付するetherとdata、それから STARTGAS と GASPRICE. と呼ばれる二つの値を含みます。コード中の指数関数的爆発や無限ループを防ぐためにそれぞれのトランザクションは、生み出すコード実行の計算ステップの上限を決めることが求められます。それは初期messageや、実行時に生成される追加のmessageも含んだ値です。 STARTGAS は上限、 GASPRICE は計算ステップあたり、マイナーに支払う手数料です。トランザクションの実行が”燃料不足”に陥った時は全ての状態変化が逆行しますーフィーが払われる場合をのぞいて。そしてもしトランザクションの実行が燃料が残ったままストップした場合は残ったフィーは送付者に払い戻しされます。またcontract作成のため、分離されたトランザクションタイプや対応するmessageタイプが存在します:contractのアドレスは、acountのnonceとトランザクションデータのhashに基づいて計算されます。

messageメカニズムの重要な結果は、Ethereumの"第一級市民"の性質です。ーcontractは外部所有のacountに対して対等な力を持つというアイデアです。それはmessageを送る能力や他のcontractを作る能力が含まれています。これによって、contractsは同時に異なる種類の役割を果たします：例えば、誰かがディセントラル組織（一つめのcontract）のメンバに、(カスタマイズしたquantum-proofなLamport署名(３つめのcontract)を使用する変質的な個人と五個の鍵をセキュリティのために使うエンティティ（４つめのcontract）との間のエスクローaccount(二つ目のcontract)をもたせるかもしれません。Ethereumプラットフォームの力はディセントラル組織とエスクロー契約が、それぞれのパーティがどんなタイプのcontractをなのかをケアする必要がないことです。

Ethereum 状態遷移関数

Ethereumの状態遷移関数, APPLY(S,TX) -> S' は以下のように定義されます:

1. トランザクションが正しいフォーマットか(例えば、正しい個数の値をもっているか)、署名が有効か、nonceが送付者のaccountのnonceとマッチするかをチェックする。 正しくない場合、エラーを返す。
2. STARTGAS * GASPRICE で計算されるトランザクションフィーを計算し、署名から送付者のアドレスを決定する。送付者のaccountのバランスシートからフィーを引き、送付者のnonceを増加させる。使えるだけのバランスシートが存在しない場合、エラーを返す。
3. GAS = STARTGASに初期化する。 トランザクションのbyte数に対し支払いをするため、1byte単位のある一定量の燃料を引く。
4. 送付者のacountから受信者のaccountへトランザクションの値を送る。もし、受信者のacountが存在していない場合、それを作る。受信者のacountがcontractの場合、contractのコードを実行し、終了するか、燃料不足になるまで実行する。
5. もし、送付者が十分なお金をもっていないために値の送付に失敗した場合、またはコードの実行が燃料切れになった場合、全ての状態遷移をフィーの支払い以外は元に戻す。そしてフィーをマイナーのacountに追加する。
6. そうでない場合、送付者に残った燃料分のフィーを差し戻し、消費した燃料分のフィーをマイナーに送付する。

例えば、以下のようなコードで示されるcontractについて考えてみましょう:

	if !contract.storage[msg.data[0]]:
        contract.storage[msg.data[0]] = msg.data[1]

実際には、contractのコードは低レベルのEVMコードで書かれることに注意しましょう；この例は、分かりやすくするためにSerpentという我々の上位言語で記述されており、EVMコードにコンパイルすることができます。contractのストレージは空で始まり、トランザクションは10etherとともに送付され、燃料は2000、燃料単価は0.001ether そして二つのデータフィールド[ 2, 'CHARLIE' ]^[3].をもつと仮定しましょう。このケースの状態遷移関数プロセスは以下のように なります。

1. トランザクションが有効で正しいフォームであることをチェックする
2. トランザクションの送付者は少なくとも2000x0.001= 2 etherを持っている事をチェックする。もし持っているならば、送付者のacountから2 etherを引く。
3. gasを2000に初期化；トランザクションが170バイトでバイトあたりのフィーが5と仮定します。850を引く事になるので、1150gasが残っている事になります。
4. 10以上のetherを送付者のacountから引いて、contractのアカウントにそれを足す。
5. コードを実行します。このケースでは簡単です：contractのストレージのインデックス2が使われているかチェックし、もし使われていなければストレージのインデックス2に CHARLIE をセットします。これは187 gasを使用するので、残ったgasの量は 1150 - 187 = 963になります。
6. 963 * 0.001 = 0.963 ether を送付者のアカウントに戻す。結果の状態を返す。

トランザクションの最後を受信した時にcontractが無い場合、トータルのトランザクションフィーは単純に提供されたGASPRICEにトランザクションのバイト数を掛けたものになり、トランザクションと並んで送られたデータは無意味なものとなります。さらに、contractによって始められたmessageはそれが生み出す計算に対して燃料の上限を決めることができることに注意しましょう。さらに子計算が燃料切れになった時、messageコールが起きた所まで状態が戻ることにも注意しましょう。よって、トランザクションと同じように、contractは自分が生み出す子計算の上限をきちんときめることによって計算リソースの制限がセキュアとなります。

コード実行

Ethereumのcontractのコードは下位レベルのスタックベースのバイトコード言語で、"Ethereum 仮想マシンコード" もしくは "EVMコード"と呼ばれます。コードはオペレーションを表すバイトの並びで構成されます。一般的に、コード実行は現在のプログラムカウンター（０から始まります）のオペレーションを繰り返し実行しプログラムカウンターを１づつインクリメントする無限ループで、コードの最後に到達するか、エラーとなるか、もしくはSTOPまたは RETURN命令が実行されると止まります。オペレーションはストアされたデータの３種類の空間にアクセスします。

• stack, プッシュとポップができるlast-in-first-outのコンテナ
• Memory, 無限に拡張できるバイトアレイ
• contractの長期 storage, key/valueストア。計算が終わったらリセットされるstackやmemoryと異なり、storageは長期的に値が保持される。

コードはvalueや送付者や送付されて来たmessageのdataにアクセスでき、ブロックヘッダデータにもアクセスできる。コードはアウトプットとしてデータのバイトアレイを返すことができる。 EVMコードの公式な実行モデルは驚く程シンプルです。Ethereum仮想マシンが実行されるとき、その完全な計算状態は以下のTupleで定義されます。 (block_state, transaction, message, code, memory, stack, pc, gas) ここで block_state はbalanceとストレージを含む全てのアカウントを包含したグローバルステートです。　実行時のすべてのラウンドで、現在実行中の命令は pc番目 code,中のバイトです。そして全ての命令はtupleにどのように影響を与えるかという意味でそれぞれの定義をもっています。例えば ADD 命令は、二つのアイテムをスタックからpopして、その合計をpushし、 gas を１減らし、 pc を１増やします, SSTORE はスタックから上位二つのアイテムをpushし、1番目のアイテムで示されるcontactのストレージのインデックスに二番目のアイテムを入れます。EthereumをJITコンパイラで最適化する方法は沢山ありますが、Ethreumの基本的な実装は2,300行のコードで行えます。

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

Ethereumのブロックチェインは多くの点でBitcoinのブロックチェインに似ていますが、いくつかの違いがあります。EthereumとBitcoinのブロックチェインのアーキテクチャに関する主要な相違点は、Bitcoinと異なりEthereumのブロックはトランザクションリストと最も最近の状態のコピーを含んでいることです。それとは別に、ブロック番号とdifficultyの二つの値もブロックにストアされます。Ethereumに於けるブロックのバリデーションアルゴリズムは以下のとおりです：

1. 参照されている一つ前のブロックが存在していて有効であるかチェックする
2. ブロックのタイムスタンプが参照されている一つ前のブロックのものより大きく、かつ１５分後以内であるかチェックする
3. ブロック番号、difficulty,トランザクションのルート 、uncle root（訳注：注目するブロックの先祖の子孫） と燃料の上限(様々な低位のEthereum独自のコンセプト)が有効であるかチェックする
4. ブロックのproof of workが有効かチェックする
5. S[0] を一つ前のブロックの STATE_ROOT にする
6. TX をブロックチェインのn個のトランザクションリストとする。すべての0...n-1 に対して S[i+1] = APPLY(S[i],TX[i])
7. もしアプリケーションがエラーを返した場合やトータルの燃料がブロック内で GASLIMIT を超えた場合エラーを返す。
8. S_FINAL を S[n],にする。しかし、ブロックのリワードはマイナーに与えられる
9. S_FINAL が STATE_ROOT と同一かどうかチェックする。もしそうなら、ブロックは有効であるそうでないなら有効でない。

このアプローチはそれぞれのブロックにすべての状態をストアしないといけないので、一見、非常に非効率的なように見えます。しかし、実際の効率はBitcoinとそれほど変わりません。その理由は状態はツリー構造でストアされ、それぞれのブロックの後ろにはツリーの非常に小さな部分のみしか変更が無いからです。一般的に隣り合うブロック間のツリーの殆どの部分は同一であり、それゆえ、データは一度ストアされたら二度目以降はポインタ（サブツリーのハッシュ）で参照されます。"Patricia tree"として知られているツリーはこれを実現します。それはマークルツリーのコンセプトを修正したもので、ノードの変更だけでなく挿入や削除を効率的に行うことができます。さらに、全ての状態の情報は最後のブロックの一部ですので、全てのブロックチェインの履歴をストアする必要はありませんーもし、この戦略がBitcoinに適用可能ならば、１０−２０倍の記憶容量節約が可能になります。

アプリケーション

一般的に、Ethereum上では３つの種類のアプリケーションが存在します。最初のカテゴリーは金融アプリケーションで、ユーザーはお金を使ったcontractについてもっとパワフルなマネージメントと参入が可能になります。これは補助通貨、金融デリバティブ、ヘッジングcontract、救済可能な財布、 遺産、ある種の雇用契約全体等が含まれます。二番目のカテゴリーは準金融的なアプリケーションで、お金が絡んでいるが、お金と関係ない部分が非常に重要なものです；パーフェクトな例は自力執行される、コンピュータ計算問題の解法に対する賞金です。最後にオンライン投票やディセントラル統治のような全く金融と関係ないアプリケーションがあります。

トークンシステム

ブロックチェイン上のトークンシステムは、USDや金、会社株式のような資産を表現する通貨から、一つの単位でのみ発行される収集品やsmart propertyのようなものを表現するトークンや、偽造不可能なクーポン、そして従来の価値と全くリンクしていないトークンシステムまで幅広い範囲で沢山のアプリケーションが存在します。補助通貨はethereum上で信じられないぐらい簡単に実装できます。理解するためのキーポイントは全ての通貨やトークンシステムは基本的に一つのオペレーションを持ったデータベースだということです：AからX単位を引き、BにX単位を与える。但し書きとして(1)X(訳注：Aの間違い？）は少なくともトランザクションの前にX単位持っている (2)トランザクションはAによって認証されている。補助通貨を実装するということはこのロジックをcontractに実装することに他なりません。

Serperntによる通貨の実装は以下のとおりです：

from = msg.sender
to = msg.data[0]
value = msg.data[1]

if contract.storage[from] >= value:
    contract.storage[from] = contract.storage[from] - value
    contract.storage[to] = contract.storage[to] + value

これは本質的にこの文章のだいぶ前に述べた"銀行システム”状態遷移関数の実装です。数行の追加コードが、最初の通貨単位分配のためと、いくつかの特殊ケースのために必要となります。また理想的には、他のcontractが、アドレスのbalanceを問い合わせるための関数が追加されるでしょう。しかし、これで殆どすべてです。理論的にはEthereumベースの補助通貨は潜在的にBitcoinのブロックチェインベースのメタ通貨に欠けている重要な特徴を持っています：その通貨で直接トランザクションフィーを支払う能力です。この方法は、contractがフィーを払うために使われたetherを送信者に払い戻すことによりetherの差額を保持し、フィーとして使用する内部通貨単位を集め、それらをつねに実行されているオークションで売却することにより、差額を補充するということによって実装できます。　よって、ユーザーはaccountをetherによってアクティベートする必要があり、しかしひとたびetherがあれば、contractが毎回払い戻すので、再利用可能だということになります。

金融デリバティブと安定した価値を持つ通貨

金融デリバティブは、"smart contract"のもっとも一般的なアプリケーションで、最もシンプルなコードで実装できるものの一つです。金融contractを実装する際の主要なチャレンジは殆どのものが、外部の価格tickerを必要とするということです。例えば、もっとも望ましいアプリケーションはether(または他の仮想通貨)のUSドルに対するボラタリティをヘッジするsmart contractです。しかしこれを行うためには、contractはETH/USDの値を知ってないといけません。もっとも簡単にこれを実現する方法は、とある団体(例えばNASDAQ)によってメンテナンスされる「データを提供する」contractを通すことです。必要であればその団体がcontractをアップデートすることができ、他のcontractがこのcontractにメッセージを送って、価格を提供してもらうインターフェースを提供します。

クリティカルな構成要素が与えられた時、ヘッジングcontractは以下のようになります：

1. 団体Aが1000 ether入力するのを待つ
2. 団体Bが1000 ether入力するのを待つ
3. データフィードcontractに問い合わせる事で計算された、1000 etherのUSDでの価値をstorageに記録する。これを$xとする
4. ３０日後、AとBがcontractを再アクティーベートできるようにしておいて、(再びデータフィードcontractに問い合わせることによって得られた新しい値に相当する)$xの価値があるetherをAに送り、残りをBに送る。

このようなcontractは暗号通商において、重要なポテンシャルを持っています。仮想通貨に対して言われる主要な問題の一つはボラティリティが高いという事実です；沢山のユーザーと小売りが暗号的資産を安全に簡易に使用したいと思っていますが、一日に23%もの価値を失う見込みがあるものに向き合いたいとは思っていません。現在まで、発行者が資産を保証するというのがもっとも一般的なソリューションとして提案されてきました；発行者は、発行する権利と単位を無効にする権利を持った補助通貨を作ります、そして一単位の特定の基礎をなす資産(例：金やUSD)を(オフラインで)提供する人に一単位の通貨を供給します。発行者は１単位の暗号資産を送ってくれた人誰にでも、１単位の基礎をなす資産を送ることを約束します。このメカニズムは、信用できる発行者にとって、暗号的でない資産を暗号資産に持ち上げる方法をもたらします。

しかしながら、実際には発行者は常に信用できる訳ではありませんし、あるケースではそのようなサービスを行うには銀行インフラストラクチャはあまりにも弱かったり、適してなかったりします。金融デリバティブは他の方法を提供します。資産をバックアップするファンドを供給する一人の発行者の代わりに、暗号的に参照されている資産(例えばETH)が上昇する方に賭ける投機家によるマーケットが役割を果たします。発行者と異なり、投機家は 彼らに有利なバーゲンを行うオプションがありません。なぜならばヘッジングcontractはファンドをエスクローで保持しているからです。この手法は完全にディセントラル化されているわけではないことに注意しましょう。なぜならば、price tickerを供給する信用できるソースがやはり必要になるからです。そうは言っても、間違いなく、インフラへの要求(発行者と異なり、価格フィードを発行することはライセンスが必要でなく、フリースピーチにカテゴライズできます)を減らすという意味において、またシステムの欠陥の可能性を減らすという意味において非常に大きな改善です。

個人認証と評価システム

もっとも早く実現したアルトコインである、Namecoin は、名前登録システムにBitcoinのようなブロックチェインを使用します。そこではユーザは自分の名前をパブリックなデータベースに他のデータと共に登録できます。もっとも良く引用されているユースケースは DNSシステムです。 "bitcoin.org" のような(またはNamecoinの場合は”bitcoin.bit”)ドメインネームをIPアドレスにマッピングします。以下の物は、Ethereum上で、Namecoinのような名前登録システムを提供する基本contractです。

if !contract.storage[tx.data[0]]:
    contract.storage[tx.data[0]] = tx.data[1]

contractは非常に単純です；追加はできるが、変更や削除ができないEthereumネットワーク内部のデータベースそのものです。誰でも名前を何かの値と一緒に登録することができ、そしてその登録した内容は永久に残ります。もっと洗練された名前登録のcontractは”関数”をもっており、他のcontractが問い合わせできるようになっています。名前の”オーナー”(例：最初の登録者)がデータを変更したり、オーナーシップを譲ったりできるメカニズムです。評判や信用の網のような機能を付ける事さえできます。

ディセントラルファイルストレージ

ここ数年間、沢山の数の人気オンラインファイルストレージスタートアップがあります。もっとも有名なのはDropboxで、全てのユーザがハードディスクのバックアップをアップロードすることができ、月額フィーでユーザがバックアップを保持したりアクセスできるサービスを提供します。しかしながら、今現在のところ、ファイルストレージマーッケットはやや非効率的です；様々な現状のソリューションをざっくりと見回しても、20-200GBの所に不自然な谷が存在しており、そこは無料でもなく、エンタープライズレベルのディスカウントでもないレベルです。ユーザーが支払うファイルストレージのメインストリームの月額価格は1ヶ月単位のハードディスク全体にユーザが支払う額よりも大きいです。Ethereumのcontractはディセントラルファイルストレージエコシステムの開発を可能にします。そこでは個人ユーザがハードディスクを貸し出す事で小さい金額のお金を稼ぐことが可能であり、さらに空いているスペースを貸し出すことでファイルストレージのコストをドライブ価格以下にできます。

そのようなデバイスのキーとなる部品は我々が”ディセントラルDropbox contract”と呼んでいるものです。このcontractは以下のように機能します。最初に、データをブロックに分割し、それぞれのブロックをプライバシーのために暗号化し、そのマークルツリーを構成します。次に、Nブロック毎にcontractがマークルツリー(一つ前のハッシュが、contract codeからアクセス可能で、乱数の素となる)からランダムにインデックスを選び、ツリー内の特定したインデックスのブロックのオーナーシップを証明する、SPVのような、トランザクションを最初に供給したエンティティにX etherを与えるという内容のcontractを作ります。ユーザが自身のファイルを再びダウンロードしたい場合、マイクロペイメントのチャンネルプロトコルを使用して(例えば 1szaboを32キロバイト毎に支払う)ファイルをリカバーすることができます；もっともフィーの効率の良いアプローチは支払いをする人が、最後までトランザクションを発行せず、代わりに、32キロバイト毎に同じnonceに対してほんの少し儲かる条件のトランザクションに置き換える事です。

たくさんのランダムノードがファイルを捨てないことを信用しているように見えるかもしれませんが、このプロトコルの重要な特徴は、ファイルを秘密にして共有し、たくさんのピースに分割すること、およびそれぞれの分割された部分が未だにどこかのノードに所有されていることをcontractを通して確認することによって、殆どゼロにまでリスクを下げることが可能であることです。もし、contractがまだお金を払っているのであれば、誰かがファイルを持っていることの暗号証明となります。

ディセントラル自律組織

“decentralized autonomous organization”の一般的なコンセプトは、仮想的なエンティティで、ある人数のメンバーまたはシェアホルダーが、おそらく67%以上のマジョリティですが、エンティティのファンドを使ったり、コードを書き換えたりする権利を持っているというものです。メンバーは集団的に、組織がそのファンドをどのように配置するかを決定します。DAOのファンドを配置する方法は幅広く、賞金、給与から、内部の通貨を報償とするような変わったメカニズムまで存在します。これは本質的に伝統的な会社やNPOの法的な問題は変わらずに持っているのですが、強制力として暗号的なブロックチェインテクノロジーのみを用います。DAO周りの議論の多くはキャピタリストモデルで、分割で受け取れる株主や取引できる株を使用する"ディセントラル自律会社(DAC)"として語られています；それとはまた別に、"ディセントラル自律コミュニティ”として描かれるものは、全てのメンバーが等しい発言権を持ち、67%のメンバーがメンバーを追加、排除を決めることができます。一人が一つのメンバーシップのみしかもてないという事は、グループで全体的に強制力をもつことを意味します。

どのようにDAOをコードに落とすかの一般的なアウトラインは以下のようなものです。もっとも簡単な設計はもし三分の二のメンバーが変更に合意した時に自分自身を修正するコードです。コードは理論的には不変なのですが、以下のような方法で容易に回避できます。分離したcontractにコードのチャンクを持つ事によって変更ができるようにする、変更可能なストレージに呼び出すcontractのアドレスをストアします。そのようなDAO contractの簡単な実装では、３つのトランザクションタイプが存在し、トランザクションの中で供給されるデータによって区別することができます:

• [0,i,K,V] ストレージインデックスkのvalueをvに変更する提案iの登録
• [0,i] 提案iに対する賛成の登録
• [2,i] 提案iを充分な投票が行われた後、確定する

contractはこれらそれぞれに条項があります。すべてのオープンなストレージの変更と誰がそれに投票したかのリストの記録が維持されています。また全てのメンバーのリストを持っています。ストレージの変更に三分の二のメンバーが同意した時、最終トランザクションが変更を実行できます。もっと洗練された戦略はトランザクションを送ったり、メンバーを追加、削除したり、 Liquid Democracy-スタイルの投票権委任（例えば、誰もが誰かを自分の代理として投票できるようにする。そしてその委任は伝達することができるので、AがBに委任してBがCに委任した場合、CがAの投票を決定する）さえも投票の権利としてビルトインするということです。この設計はDAOが組織的にディセントラルコミュニティとして育たせ、結果的に、人々が誰が専門家の一人であるかを選び出す仕事を委託することができるようになりますが、”現在のシステム”の専門家と異なり、個々のコミュニティのメンバが組織を変更すれば、専門家は簡単に出現したり消えたりすることが可能です。

ディセントラル会社の別のモデルは、いかなるアカウントもゼロ、もしくはそれ以上の株式を持つ事ができ、意思決定をするためには三分の二以上の株式が必要とされるというものです。完全なものは資産マネージメント機能や、株式を売り買いする能力や、(contract内部でオーダーマッチングメカニズムがあることが望ましい）オファーを受け入れる能力が備わっています。liquid-democracyスタイルでは委任も存在します。それは"board of directors"のコンセプトの一般化です。

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

1. 救済可能 wallets. アリスは彼女のファンドを安全に保持したいと思っていますが、無くなったり、または誰かが彼女の秘密鍵をハックすることを心配しているとします。以下のような方法で、彼女はEtherをボブとのcontractに銀行のように入れることができます。

• アリスは一人で一日あたり最大でファンドの1%を引き出せる
• ボブは一人で一日あたり最大でファンドの1%を引き出せるが、アリスは自分の鍵でこの権利を終わらせる能力を持っている。
• アリスとボブは一緒であれば何でも引き出せる

通常は一日あたり1%はアリスにとって充分です。もしアリスがもっと引き出したいならば彼女はボブとコンタクトして助けてもらいます。もしアリスの鍵がハックされると、彼女はファンドをボブと新しいcontractに移動させます。もし彼女が鍵をなくしたなら、最終的にボブはファンドを引き出すでしょう。もしボブがずるい人間だとはっきりした場合、彼女は彼の引き出せる能力を終わらせます。

2. 農産物保険. 誰でもプライスインデックスではなく気候のデータフィードを使用した金融デリバティブcontractを簡単に作る事ができます。もしアイオワの農家がアイオワの降水量の逆ばりをするデリバティブを購入した場合、干ばつがあれば農家は自動的にお金を受け取り、充分な降水量があった場合、農家は作物が順調に取れるので幸せです。

3. A decentralized data feed.差異化のための金融contract用に、"SchellingCoin".というプロトコルによってディセントラルデータフィードが可能です。SchellingCoinは基本的に以下のように機能します：N個の集団すべてが、システムに必要なデータ(例えば ETH/USD価格)の値を入力し、値はソートされ、25〜75%に入るもの全てが報酬として１トークンを得ます。すべての人が他の人達が提供するであろう値を提供するインセンティブを持ちます。そして、多数のプレイヤーが現実的に合意できる値のみが明らかなデフォルト値：真実となります。これによって、理論的に、ETH/USD価格、ベルリンの温度、または計算が特に難しい結果でさえも供給するディセントラルプロトコルを作る事ができま す。

4. Smart 複数署名エスクロー取引. Bitcoinは複数署名トランザクションcontractを結ぶことができます。例えば与えられた五個の鍵のうち３個によってファンドを使用することができるというようなものです。Ethereumはもっと細かいものを可能にします；例えば、５個の内４個によって何でも使うことができ、5個の内３個で一日あたり10%使用することができ、5個のうち2個で一日あたり0.5%使用することができるというような物です。さらにEthereumの複数署名は非同期ですー二つの集団はそれぞれの署名をブロックチェイン上に異なるタイミングで登録できます。そして最後に署名された時に自動的にトランザクションが送られます。

5. クラウドコンピューティング.EVM技術はまた、検証可能なコンピュータ環境を作るのに用いる事ができます。そこではユーザは他の人にコンピュータ演算を依頼することができ、オプションとして、ランダムに選ばれたチェックポイントを正しく超えた証明を求めることができます。このことによって、どんなユーザも自分のデスクトップ、ラップトップ、または特殊なサーバでもクラウドコンピューティングマーケットに参入でき、安全なデポジットを使って、スポットチェッキングをお互いに行う事で、システムが信頼に足る事を保証できます（ノードは騙して利益を得る事ができない)。そのようなシステムは全てのタスクに向いている訳ではありません；例えば、ハイレベルのプロセス内通信が必要になるタスクは大量のクラウドノードで簡単に実行できません。しかしながら、SETI@home,folding@homeや、遺伝アルゴリズムのような簡単に並列化できるプロジェクトはそのようなプラットフォーム上に簡単に実装できます。

6. P2Pギャンブル. どのような数のP２Pギャンブルプロトコル、例えばFrank StanjanoやRichard Claytonの Cyberdiceのような物もEthereumのブロックチェイン上に実装できます。もっとも簡単なギャンブルプロトコルは次のブロックのハッシュの差異に対する簡単なcontractです。もっと複雑なプロトコルもそこから作り上げる事ができます。人を騙す事のない、フィーが殆どゼロのギャンブルサービスも作る事ができます。

7. 予測市場. お告げやSchellingCoinがあれば、予測市場も実装は簡単です、予測市場とSchellingCoinを一緒にすると、 ディセントラル組織の管理プロトコルとしてのfutarchyのアプリケーションの最初の例となるかもしれません。

8. チェーン上のディセントラル型マーケットプレイス, これは、アイデンティティと評判システムをベースとしたものです。

雑録と関心事項

修正GHOST実装

"Greedy Heavist Observed Subtree" (GHOST)は、Yonatan SompolinskyとAviv Zoharによって2013年12月に初めて紹介されたイノベーションです。GHOST開発のモチベーションはブロックチェインの確定時間を早くすることです。現在のシステムでは、確定時間を短くすると無効レートが高くなることによってセキュリティが減少してしまいますーブロックはネットワークを通じて伝わるのにある程度の時間がかかるため、もし、マイナーAがブロックを発掘して、つぎにマイナーBがたまたまAのブロックがBに伝わってくる前にその他のブロックを見つけた場合、マイナーBのブロックは最終的に無駄に終わり、ネットワークセキュリティには貢献しません。さらに、そこには中央集権の問題が存在します：もしマイナーAがマイニングプールで30%のハッシュパワーを持っており、Bが10%のハッシュパワーをもっているとすると、Aは無効ブロックを作り出すリスクを70%の時間で（なぜなら他の30%の時間は最後のブロックをAが作り出しているのでマイニングデータを即座に得る事ができる）持ってます。一方、Bは無効ブロックを作るリスクを90%の時間でもっています。つまり、無効ブロックを作る率が高くなるぐらいにブロック間のインターバルが短いと、Aは実質上、単にそのサイズの効能だけで、さらに効率的となります。これらの二つの効果が組み合わされて、ブロックを早く作り出すブロックチェインはネットワーク上のハッシュパワーのうち大きなパーセンテージを占め、マイニングプロセス全体をコントロールすることができるマイニングプールを生み出しやすい傾向があります。

SomopolinskyとZoharによって説明されたGHOSTは、最も長いチェインの計算上で無効ブロックを含めることで、一つ目のネットワークセキュリティの損失の問題を解決します：すなわち、親ブロックや先祖ブロックのみでなく、裏で合計最大のproof-of-workをもつ先祖ブロックの無効子孫ブロック(ethereum用語では “uncles”)が計算に加えられます。二番目の中央集権的バイアスがかかるという問題を解決するためには、SomopolinskyとZoharによって描かれたプロトコルのさらに先を考える必要があり、無効ブロックへの報酬を供給する必要があります：無効ブロックは87.5%のベース報酬を受け取り、無効ブロックを含む甥ブロックは残りの12.5%を受け取ります。しかしながら、トランザクションフィーはunclesには与えられません。

Ethereumの実装はGHOSTの単純化したバージョンで、一つのレベルしか関知しません。特に、無効ブロックは、自分の直接の兄弟ブロックの子供の場合のみuncleとして含むことができ、もっと距離のあるブロックから含まれることはできません。これはいくつかの理由によります。第一に制限無しのGHOST実装の場合、与えられたブロックのどのuncleが有効かの計算があまりにも複雑です。第二に、制限の無しのGHOST実装がEthereumに使用された場合、代償として、マイナーがメインチェインをマイニングするインセンティブが無くなってしまい、攻撃者が作ったチェインへの（miningへの）インセンティブが無くなりません。最後に試算の結果、一段のGHOSTは制限無しのGHOSTと比較して80%を超える利益をもたらし、無効ブロックを生み出す確率を2.5分のLitecoinと比較して40秒のブロックタイムで匹敵するものを実現できます。しかしながら、我々は保守的であり、個々のブロックが検証のためもっと長い時間を使うこともあるため、プライムコインのような60秒のブロックタイムを使い続けるつもりです。

フィー

すべてのトランザクションはblockchainに対して発行する度に、ネットワークにダウンロードと検証のコストを押し付けています。乱用を防ぐために何らかの調整メカニズム、典型的なものはトランザクションフィーです、が必要となります。Bitcoinでも用いられている一般的なアプローチは、純粋なボランティアフィーで、マイナーがゲートキーパーとして振る舞い、かつ動的に最小額を決めるということに依存しています。このアプローチはBitcoinコミュニティには好意的に受け入れられました。マイナーとトランザクション送付者の間の需要と供給で価格が決まるというマーケットベースであるのが理由です。しかしながら、この理由には問題があって、トランザクションの送付はマーケットではありません；トランザクションをマイナーが送付者にオファーするサービスだと解釈することは本質的な魅力がありますが、実際はマイナーが含めた全てのトランザクションはネットワーク内の全てのノードにおいて処理される必要があるため、トランザクション実行のための大きなコストはサードパーティによって担われ、それを含めるかどうか決定するマイナーに担われている訳ではありません。よって、コモンズの悲劇の問題がしばしば発生します。

しかしながら、マーケットベースのメカニズムには欠陥があると分かりましたが、不完全な簡単化した仮定のもとでは、それを手品のようにキャンセルすることができます。論拠は以下のようなものです。

以下のように考えます

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. ネットワークを傷つけようとする相場師、政敵、いかれた人達が存在する。彼らは頭が良く、自分たちのコストが他の検証ノードが払うコストよりもかなり低いcontractを作る。

(1)はマイナーが少ししかトランザクションを含めないようにする傾向を生み出します。(2)はNCを増加させます。よって、これら二つの効果が少なくともお互いに部分的にキャンセルします。(3)(4)は重要な問題です；これらを解決するために我々は単純に上限を儲けました；どのブロックもBLK_LIMIT_FACTOR回 x 長期の指数関数的移動平均以上のオペレーションを行うことはできません。 つまり、

	blk.oplimit = floor((blk.parent.oplimit * (EMAFACTOR - 1) + floor(parent.opcount * BLK_LIMIT_FACTOR)) / EMA_FACTOR)

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

計算とチューリング完全

重要な点はEthereumの仮想マシンはチューリング完全であるということです；これはEVMコードは無限ループを含む計算もエンコードできることを意味します。EVMコードは二つの方法でループを可能にします。第一に、JUMP命令はプログラムにコードの以前の部分のどこかにジャンプします。JUMPI命令はwhile x<27; x= x*2のような条件分岐を可能にします。第二にcontractは他のcontractを呼ぶ事ができ、潜在的に再帰によってループすることが可能になります。これは当然問題につきます。：ずるいユーザは無限ループに陥らせる事でマイナーを黙らせ、フルノードをダウンさせることが可能でしょうか？この問題はコンピュータサイエンスの実行停止問題として知られる問題を浮かび上がらせます。実行停止問題とは、一般的に与えられたプログラムがいつまでも停止しないかどうかを知る方法が無いというものです。

状態遷移の章で説明したように我々のソリューションは、トランザクションに許される最大のコンピュータ演算の実行ステップが設定されることで機能します。そして、もし実行が長引けば、実行を元に戻し、しかし費用は支払われます。メッセージも同じ方法で機能します。我々がこの解法を選んだモチベーションを理解するために、以下のような例を考えてみましょう。

• 攻撃者が、無限ループを引き起こすcontractを作り、マイナーに対してそのループを引き起こすトランザクションを送付する。マイナーはトランザクションを実行し、無限ループを実行する、そして燃料が切れるのを待つ。実行は燃料切れになり、途中でとまるが、トランザクションはまだ有効であり、マイナーはそれぞれの実行ステップのためのフィーを攻撃者に要求しつづけている。
• 攻撃者は非常に長い無限ループを作り、いくつかのブロックが認証されるぐらいの長い時間マイナーを計算させ続けて、マイナーにトランザクションを含めてフィーを要求することを不可能にさせる。しかし、攻撃者は計算ステップ数の上限を決めるSTARTGASの値を提供することが求められるので、マイナーは計算が非常に大きなステップ数であることを前もって知る。
• 攻撃者は send(A,contract.storage[A]); contract.storage[A] = 0のようなコードを持ったcontractを見つけ、最初のステップのみ実行できて二番目のステップは実行できないような量の燃料を持ったトランザクションを送付する（つまり、引き出しはするが差額を減らさせない）。contractの作者はそのような攻撃に対する防御を考える必要はない。なぜならば、実行が途中で終わる時には状態の変化は元に戻る。
• 金融contractがリスクを減らすために９個の固有のデータフィードの平均を利用している。DAOsの章で説明したような、variable-address-callメカニズムを通して変更可能な設計をされている一つのデータフィードを攻撃者は乗っ取り、無限ループを引き起こすように変更し、金融contractからファンドを要求するような物を燃料切れにしていく。しかしながら、金融contractは、メッセージ上に燃料の上限を設定できるので、このような問題は防ぐ事ができる。

チューリング完全の代わりはチューリング非完全です。JUMPやJUMPI命令は存在せず、コールスタックにはそれぞれのcontractの一つだけのコピーが存在できます。このシステムではこれまでに述べたフィーシステムや我々のソリューションの効果についての不確実性は必要なくなります。なぜならcontractを実行するコストはそのサイズによって上限が決まるからです。さらに、チューリング非完全性はそれほど大きな制限ではありません；我々が内部で想像した全てのcontractの例で、一つのみがループを必要としました。さらにそのループはコードを26回繰り返す事によって取り除くことができました。チューリング完全性のもたらす厳しさや限定された利益を考えた時、何故チューリング非完全性言語を使用しないのでしょう？しかしながら、実際にはチューリング非完全性は問題のきちんとした解決からはほど遠いものです。その理由を知るために、以下のcontractを考えましょう。

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⁵⁰の計算ステップを持つcontractがあります。マイナーはそれぞれのcontractに付随している、演算実行ステップの最大値や、contractが呼び出す他のcontractを前もって見る事によってそのような論理爆弾を事前に察知することが可能です、しかし、そのことはマイナーに、他のcontractを生み出すcontractを禁止する(なぜなら、上記の全ての26個(訳注：？）のcontractの生成と実行は簡単に一つのcontractにまとめることができる）ことになります。他の問題となるポイントはメッセージのアドレスフィールドが変数であり、一般的にcontractが呼び出す他のcontractを事前に理解することが不可能なことです。よって、我々は驚くべき結論を得ます：チューリング完全性は驚く程容易に管理でき、チューリング完全性の欠如は、全く同じコントロール（訳注：もし実行が長引けば、実行を元に戻し、しかし費用は支払われる、というEthereumのコントロール）が導入されなければ、同じぐらい驚く程管理が難しいーそのような場合、チューリング完全にしない理由はありません。(訳注：チューリング非完全で演算実行ステップ数を予測・計算することは、実はむづかしいため、Ethereumで導入したコントロールが必要で、結局チューリング完全にしても同じ、という説明）

通貨と発行

EthereumのネットワークはEtherという、ビルトイン通貨を持っています。それは二つの目的ための主要なレイヤーとなります。様々な種類のデジタル資産の効率的な交換と、もっと重要なのですが、トランザクションフィーを支払うメカニズムをもたらします。簡便性のためと将来の議論を避けるため（BitcoinでmBTC/uBTC/satoshiに関する現在の議論を参照）、単位は前もって付けられています。

• 1: wei
• 10³: lovelace
• 10⁶: babbage
• 10⁹: shannon
• 10¹²: szabo
• 10¹⁵: finney
• 10¹⁸: ether

これはドルとセント、またはBTCとsatoshiのコンセプトの拡張バージョンと考える事ができます。近い将来、Etherは通常のトランザクションで使用され、finneyはマイクロトランザクションで使用され、szaboとweiはフィーやプロトコル実装の技術討論で用いられると我々は予想しています；残りの単位は後ほど有益になるかもしれませんが、現在の所クライアントには含まれていません。

発行モデルは以下の通り：

• Etherは1BTCあたり1000-2000 etherの価格で通貨販売でリリースされます。このメカニズムはEtehereum organizationのファンドの目的と、MastercoinやNXTのような他のプラットフォームを引き継いで開発するための目的を意図しています。初期の購入者は大きなディスカウントを得る事ができます。販売で得られたBTCは、全て、開発者の給与や賞金、Etehreumや仮想通貨エコシステムの様々な利益、非利益プロジェクトへの投資に使用されます。
• 全体の量の0.3倍が、初期の貢献者へ報いるためにorganization(訳注：Ethereumの開発組織)へ与えられます。 ジェネシスブロックの前にETH建てで経費は支払われ、残りは長期に保有されます。この量は指数関数的に減少する式に従って分配されます；毎月、残った寄付の5.6%が開発者やプロジェクト開発に参加した者のために分配されます。この分配は12月にスタートします。
• 全体の量の0.3倍の販売が、永久にマイナーに割当てられます。

Group	At launch	After 1 year	After 5 years
Currency units	1.3X	1.6X	2.8X
Purchasers	76.9%	62.5%	35.7%
Reserve spent pre-sale	5.77%	4.69%	2.68%
Reserve used post-sale	17.3%	14.1%	8.04%
Miners	0%	23.1%	53.6%

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

リニアな通貨の発行に関わらず、時間をかけてBitcoinのように供給増加率はゼロとなる傾向となる

上記のモデルの二つの大きな選択は(1)寄付金プールが存在することとその大きさ(2)供給に上限があるBitcoinと異なり、永久に線形に増え続ける供給の存在です。寄付金プールが存在する正当性は以下のとおりです。もし寄付金プールが存在せず、同じインフレ率とするために線形な発行を0.231倍に減少させると、トータルのEtherの量は23%減り、一単位の価値は30%上昇します。(訳注：100　etherが23%減り、77　etherとなったあともether全体で同じ価値があるとすると、1 etherあたり100/77≒1.3倍値打ちが上がる、ということと思われる）よって、30%均衡の中で、もっと多くのetherがセールで購入され、1ユニットが以前と全く同じ価値を持ちます。組織は1.3倍のBTCを持ちますが、それは二つに分ける事ができます：オリジナルのBTCと追加の0.3倍のBTCです。よって、この状態は寄付と全く同じですが、一つだけ重要な違いがあります：組織は純粋にBTCをもっており、Etherの価値を維持するインセンティブを持たないということです。

永遠に線形に供給が増えるモデルはBitcoinで見られた、一部に富が集まりすぎるリスクを減らします。そして、現在生きている個人と未来の時代に通貨を獲得するフェアなチャンスを作ります。同時に、供給増加レートがゼロに向かうため、Etherを得て保持しようという強いインセンティブを与えます。不注意や死やその他の理由でコインは常に失われて行き、コインの損失は一年あたりの総供給量のパーセンテージでモデリングでき、循環するトータルの通貨供給量はゆっくりと年間発行量をロスレートで割った値に近づいて行くということから上記の理論化を行っています（すなわち、ロスレートが1%の場合、ひとたび供給量が30Xになったら、0.3Xが採掘され、0.3Xが毎年失われるところで均衡します)。

マイニング集中

Bitcoinのマイニングアルゴリズムは、基本的にマイナーにブロックヘッダの少しだけ変更したバージョンについて何百万回も繰り返してSHA256を演算をさせ、最終的に一つのノードがあるターゲット以下（現在は2¹⁹²)のハッシュ値になることによって成立しています。しかしながら、このマイニングアルゴリズムは二つの中央集権化に対する脆弱性を持っています。一つは、マイニングのエコシステムがASIC(application-specific integrated circuits)に支配されるようになってきています。ASICはマイニング専門にチップがデザインされているためビットコインマイニングのタスクに対して数千倍の効率を持っています。これはBitcoinのマイニングはもはやディセントラルではなく、効率的に参加するためには数百万ドルが必要となり、平等主義を追求していないことを意味しています。第二に殆どのBitcoinマイナーはブロックの認証プロセスを実際には一人では行っていません；その代わりにブロックヘッダを見つけるための中央集権化されたマイニングプールに依存しています。こちらの問題はおそらくもっとひどいものです：この文章を書いている時で、トップ３のマイニングプールは直接的ではないですが、Bitcoinネットワークの約50%をコントロールしています。マイナーはもしマイニングプールや連立が51%アタックをしようとしたときに他のマイニングプールに移動できるのですが、それでも良くないものです。

現在Ethereumが使用しようとしているアルゴリズムはマイナーが状態から得たランダムデータをフェッチし、ブロックチェインの最後のNブロックからランダムに選ばれたトランザクションを計算し、結果のハッシュを返すというものです。これは二つの重要な利点があります。第一に、Etehreumのcontractはどのような種類の演算も含める事ができます、つまりEtehreum用のASICを開発するとしたら、本質的にどのような演算も早いASIC ー　それはすなわち、より良いCPUということになります。第二に、マイニングにおいてブロックチェイン全体にアクセスすることが必要になり、マイナーにブロックチェイン全体を保持することと、少なくとも全てのトランザクションを検証できるということを要求する事になります。これは中央集権化したマイニングプールの必要性を取り除くことになります；マイニングプールは報酬の分配のランダムさを平等にする、正当な役割を果たす事はできますが、この機能はP2Pプールによって中央集権無しに実現できます。

このモデルはまだテストされていません。そしてマイニングアルゴリズムとしてcontractの実行をさせる時に、賢い最適化を利用されることを避ける難しさあると思われます。しかしながら、このアルゴリズムの面白い特徴は非常に大きな数のcontractを、特にあるASICの妨害をするように設計して、ブロックチェインに入れることで誰でも井戸に毒を盛る事ができるということです。ASIC製造者にはお互いにそのようなトリックを使って攻撃する経済的なインセンティブが存在します。よって、我々が開発中のソリューションは純粋なテクニカルなものというよりも究極の経済的なヒューマンソリューションとなります。

スケーラビリティ

Ethereumに関して皆が気にしていることの一つはスケーラビリティです。BitcoinのようにEtehreumはすべてのトランザクションがネットワーク上の全てのノードで実行される必要があるという欠点があります。Bitcoinでは現在のブロックチェインは約15GBであり、一時間あたり1MB増加しています。もしBitcoinネットワークがVisaのように一秒当たり2000transactionを処理する場合、3秒当たり1MB(１時間あたり1GB, 一年当たり8TB)もの増加をすることになります。Etehreumも同じような成長パターンに苦しむことになります。さらに悪い事には、単なる貨幣として使用されているBitcoinと異なり、Ethereumのブロックチェインは様々なアプリケーションが実行されることになります。しかし、Ethereumのフルノードはブロックチェインの履歴全てではなく、状態のみの保持で良いという事実が良い方向に働くでしょう。

そのような巨大なブロックチェインのサイズは中央集権化リスクが存在します。仮にブロックチェインのサイズが100TBになったとします。そのとき、もっともあり得るシナリオは非常に少ない数の巨大なビジネス組織のみがフルノードを動作させており、通常のユーザーは皆ライトSPVノードを使っているというものです。そのような状態では、なんらかの利益のためにお互いが手を組んでずるをして合意するという潜在的な危機が浮かび上がります（例えば、ブロックの報酬を変更して、彼らにBTCを与える)。ライトノードはこれを即座に見つけ出す方法を持っていません。もちろん少なくとも一つの誠実なフルノードが存在しているでしょう、そして、欠陥についての情報が数時間のちにRedditのようなチャンネルを通してじわじわ広まったとして、そのタイミングではもう遅すぎます：与えられたブロック をブラックリスト化する努力を計画するかは一般ユーザに委ねられ、またうまく出来た５１％アタックを抜き出すのと同じ規模の、巨大でおそらく不可能な整合作業となるでしょう。Bitcoinの場合、このことは現在問題になっています。しかしPeter Toddによって提案されたブロックチェインの修正がこの問題を緩和するでしょう。

近い将来、Ethereumはこの問題に取り組むために二つの戦略を追加する予定です。第一に、ブロックチェインベースのマイニングアルゴリズムのために、すくなくとも全てのマイナーがフルノードである必要があり、フルノードの数の下限を作ります。第二に、もっと重要なのですが、それぞれのトランザクションを処理した後にブロックチェイン内部に中間状態木のルートを含めます。もしブロック認証が中央集権化してしまったとしても、一つの正直な認証ノードが存在している限り、中央集権問題は認証プロトコルによって避ける事が可能です。もし、マイナーが有効でないブロックを提供した場合、そのブロックはフォーマットが間違っているか、もしくは状態S[n]が正しくないかです。 S[0]は正しい事が分かっているので、どこかにS[i-1]は正しいが、S[i]は正しくないという最初の状態が存在します。検証ノードは APPLY(S[i-1],TX[i]) -> S[i] を実行するのに必要なパトリシアツリーのノードのサブセットによる誤りの検証プロセスによって、index iを見つけます。ノードはこれらのノードを演算の一部として実行し、与えられたS[i]と異なるS[i]を見つけます。

他のもっと洗練された攻撃は、ずるいマイナーが不完全なブロックを提出することで、ブロックが有効かそうでないかを決定する情報が完全に足りてない状態をつくることです。これに対するソリューションはchallenge-responseプロトコルです：認証ノードは対象トランザクションのインデックスの形で”challenge”を発行し、ライトノードはノードを受け取った時に、マイナーか他の認証ノードである、他のノードが有効性の証明としてパトリシアノードのサブセットを送るまでブロックを信用できないものとして扱います。（訳注：トランザクション実行後の状態がパトレシアノード内にない状態で、ブロックが提出される攻撃を防ぐ方法の説明？？）

結論

Ethereumのプロトコルは元々、仮想通貨のアップグレードバージョンで、ブロックチェイン上のエスクロー、引き出しの上限、金融contract、ギャンブルマーケットのような先進的な特徴を高度に一般化したプログラミング言語を通して提供するものだと思われてきました。Ethereumのプロトコルはどんなアプリケーションも直接にはサポートせず、チューリング完全なプログラミング言語のみが存在します。それは、理論的にはどんなトランザクションタイプやアプリケーションのための任意のcontractでも作る事ができるということです。しかし、Ethereumについて、もっと面白い事は、Ethereumのプロトコルは単なる通貨を超えているということです。ディセントラルファイルストレージ、ディセントラル演算、ディセントラルマーケット予想や、その他の多数のコンセプト等のプロトコルは、コンピュータ業界の効率の増加に本質的なポテンシャルを持っているのですが、最初は経済のレイヤーでP2Pプロトコルを加速しました。最終的に、お金となんの関係もない沢山の本質的なアプリケーションの可能性が広がっています。

Ethereumのプロトコルによって実装されている任意の状態遷移関数のコンセプトはユニークなポテンシャルをもったプラットフォームとなります；閉じた単一の目的の、データストレージや、ギャンブルや金融のアプリケーション用のプロトコルと異なり、Ethereumは非常にオープンな設計です。我々は数年で、金融や非金融の両方のプロトコルにおいて、多数の基礎レイヤーとして使われる事になると信じています。

注意書きと参考文献

注意書き

1. 洗練された読者はBitcoinのアドレスは公開鍵そのものでは無く、楕円曲線公開鍵のハッシュであることに気がつくでしょう。しかしながら、じつのところ、暗号用語は公開鍵そのものとして公開鍵ハッシュを扱っても成立します。これはBitcoinの暗号がカスタムなデジタル署名アルゴリズムと考えることが可能で、そこでは公開鍵はECC公開鍵のハッシュで構成されており、署名はECC公開鍵をECC署名と重ねたもので構成されており、認証アルゴリズムは署名の中のECC公開鍵が公開鍵として与えられているECC公開鍵ハッシュに対して正しいかチェックすることを含んでおり、よって、ECC署名がECC公開鍵に対して正しいかのチェックになっているからです。
2. 技術的には、１１個前までのブロックの中央値です。
3. 内部的には2も"CHARLIE"も番号です。後者はビッグエンディアンの256ベース(訳注：256ビットベース）の表現です。　番号は最小で０、最大で2²⁵⁶-1を取る事ができます。

参考文献とさらに進んだ情報

1. Intrinsic value: http://bitcoinmagazine.com/8640/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt-have-it-and-why-bitcoin-does-have-it/
2. Smart property: https://en.bitcoin.it/wiki/Smart_Property
3. Smart contracts: https://en.bitcoin.it/wiki/Contracts
4. B-money: http://www.weidai.com/bmoney.txt
5. Reusable proofs of work: http://www.finney.org/~hal/rpow/
6. Secure property titles with owner authority: http://szabo.best.vwh.net/securetitle.html
7. Bitcoin whitepaper: http://bitcoin.org/bitcoin.pdf
8. Namecoin: https://namecoin.org/
9. Zooko's triangle: http://en.wikipedia.org/wiki/Zooko's_triangle
10. Colored coins whitepaper: https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit
11. Mastercoin whitepaper: https://github.com/mastercoin-MSC/spec
12. Decentralized autonomous corporations, Bitcoin Magazine: http://bitcoinmagazine.com/7050/bootstrapping-a-decentralized-autonomous-corporation-part-i/
13. Simplified payment verification: https://en.bitcoin.it/wiki/Scalability#Simplifiedpaymentverification
14. Merkle trees: http://en.wikipedia.org/wiki/Merkle_tree
15. Patricia trees: http://en.wikipedia.org/wiki/Patricia_tree
16. GHOST: http://www.cs.huji.ac.il/~avivz/pubs/13/btc_scalability_full.pdf
17. StorJ and Autonomous Agents, Jeff Garzik: http://garzikrants.blogspot.ca/2013/01/storj-and-bitcoin-autonomous-agents.html
18. Mike Hearn on Smart Property at Turing Festival: http://www.youtube.com/watch?v=Pu4PAMFPo5Y
19. Ethereum RLP: https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-RLP
20. Ethereum Merkle Patricia trees: https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-Patricia-Tree
21. Peter Todd on Merkle sum trees: http://sourceforge.net/p/bitcoin/mailman/message/31709140/