イーサリアムホワイトペーパー日本語版

以太坊とは何ですか？以太坊は新しいオープンなブロックチェーンプラットフォームであり、誰でもこのプラットフォーム上でブロックチェーン技術を用いて動作する分散型アプリケーションを構築し、使用することができます。ビットコインと同様に、以太坊は誰の管理下にもなく、誰の所有でもありません —— それはオープンソースプロジェクトであり、世界中の多くの人々によって共同で作成されています。ビットコインプロトコルとは異なり、以太坊の設計は非常に柔軟で、適応性に富んでいます。以太坊プラットフォーム上で新しいアプリケーションを立ち上げることは非常に簡単で、Homestead のリリースに伴い、誰でも安全にこのプラットフォーム上のアプリケーションを使用できるようになりました。

以太坊 DApp 実践開発コースは、分散型投票アプリケーション（Voting DApp）をコースプロジェクトとして、3 回のイテレーション開発プロセスの詳細な説明を通じてオンライン実践を行い、ブロックチェーンの理念と分散型思想をコース実践プロセス全体に貫通させ、ブロックチェーン開発に迅速に入門したい開発者に効率的な学習と価値向上の道を提供します。「以太坊 DApp 開発実践入門」は後で書かれます。

チュートリアルには開発環境がプリセットされています。チュートリアルに入ると、各知識点で即座に実践を行うことができ、開発環境の構築に時間を無駄にする必要はありません：

以太坊ホワイトペーパー中国語版中本聡が 2009 年 1 月にビットコインブロックチェーンを起動したとき、彼は同時に世界に 2 つの未検証の革命的な新概念を紹介しました。1 つ目はビットコイン（bitcoin）であり、これは分散型のピアツーピアのオンライン通貨であり、資産の担保、内在的価値、または中央発行者なしで価値を維持します。現在までに、ビットコインは大量の公衆の注目を集めており、政治的な観点からは中央銀行のない通貨であり、激しい価格変動を伴います。しかし、中本聡の偉大な実験にはビットコインと同等に重要な部分がもう 1 つあります：プルーフ・オブ・ワークに基づくブロックチェーンの概念は、人々が取引の順序について合意に達することを可能にします。アプリケーションとしてのビットコインは、先に申請した者が優先される（first-to-file）システムとして説明できます：もし誰かが 50BTC を持っていて、同時に A と B にこの 50BTC を送信した場合、最初に確認された取引のみが有効になります。どちらの取引が先に到着するかを決定する固有の方法はなく、この問題は分散型デジタル通貨の発展を何年も妨げてきました。中本聡のブロックチェーンは、最初の信頼できる分散型解決策です。現在、開発者たちの注意はビットコイン技術の第 2 の部分、すなわちブロックチェーンが通貨以外の分野にどのように応用されるかに急速に向けられています。よく言及されるアプリケーションには、チェーン上のデジタル資産を使用してカスタム通貨や金融ツール（カラードコイン）を表すこと、特定の物理デバイスの所有権（スマートアセット）、ドメイン名のような代替不可能な資産（ドメインコイン）、分散型取引所、金融派生商品、ピアツーピアギャンブル、チェーン上のアイデンティティと信用システムなどのより高度なアプリケーションが含まれます。もう 1 つのよく尋ねられる重要な分野は「スマートコントラクト」であり、事前に任意に定められたルールに基づいてデジタル資産を自動的に移転するシステムです。たとえば、ある人が「A は毎日最大 X コインを引き出せる、B は毎日最大 Y コインを引き出せる、A と B は自由に引き出せる、A は B の引き出し権を停止できる」というストレージ契約を持っているかもしれません。この契約の論理的な拡張は分散型自律組織（DAOs）であり、組織の資産を長期的に保持し、組織のルールをコーディングしたスマートコントラクトです。以太坊の目標は、内蔵された成熟したチューリング完全な言語を持つブロックチェーンを提供することであり、この言語を使用して任意の状態変換機能をコーディングする契約を作成でき、ユーザーは数行のコードでロジックを実現し、上記に言及したすべてのシステムや、私たちがまだ想像できない他の多くのシステムを作成できるようにすることです。

歴史的経緯分散型デジタル通貨の概念は、財産登録のような代替アプリケーションと同様に、数十年前に提案されました。

1980 年代と 1990 年代の匿名電子現金プロトコルは、ほとんどがチャウム盲署名技術（Chaumian blinding）に基づいていました。これらの電子現金プロトコルは高度なプライバシーを持つ通貨を提供しましたが、これらのプロトコルはすべて普及しませんでした。なぜなら、すべてが中央集権的な仲介機関に依存していたからです。1998 年、ウェイ・ダイ（Wei Dai）の b-money は、計算問題を解決し、分散型合意によって通貨を創造するという考えを初めて導入しましたが、この提案は分散型合意を実現する具体的な方法を示しませんでした。

2005 年、ハル・フィンニー（Hal Finney）は「再利用可能なプルーフ・オブ・ワークメカニズム」（reusable proofs of work）という概念を導入しました。これは b-money の考えとアダム・バック（Adam Back）が提案した計算困難なハッシュキャッシュ（Hashcash）問題を使用して暗号通貨を創造するものでした。しかし、この概念は再び理想化に迷い込みました。なぜなら、信頼できる計算をバックエンドとして依存していたからです。通貨は先に申請した者が優先されるアプリケーションであり、取引の順序が重要であるため、分散型通貨は分散型合意を実現する方法を見つける必要があります。ビットコイン以前のすべての電子通貨プロトコルが直面した主要な障害は、セキュアなバイザンチン問題耐障害（Byzantine-fault-tolerant）マルチパーティ合意システムを作成する方法に関する研究が数年にわたって行われてきたにもかかわらず、上記のプロトコルは問題の半分しか解決していなかったことです。これらのプロトコルは、システムのすべての参加者が既知であると仮定し、「N 人がシステムに参加する場合、システムは N/4 の悪意のある参加者に耐えられる」という形式のセキュリティ境界を生成します。しかし、この仮定の問題は、匿名の状況下で、システムが設定したセキュリティ境界がウィッチ攻撃にさらされやすいことです。なぜなら、攻撃者は 1 台のサーバーまたはボットネット上に数千のノードを作成し、単独で過半数のシェアを持つことを保証できるからです。中本聡の革新は、非常にシンプルなノードベースの分散型合意プロトコルをプルーフ・オブ・ワークメカニズムと組み合わせるというアイデアを導入したことです。ノードはプルーフ・オブ・ワークメカニズムを通じてシステムに参加する権利を得て、10 分ごとに取引を「ブロック」にパッケージ化し、成長し続けるブロックチェーンを作成します。大量の計算能力を持つノードはより大きな影響力を持ちますが、ネットワーク全体よりも多くの計算能力を得ることは 100 万のノードを作成するよりもはるかに困難です。ビットコインのブロックチェーンモデルは非常に簡素ですが、実践によって十分に機能することが証明されており、今後 5 年間で、世界中の 200 以上の通貨とプロトコルの基盤となるでしょう。

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

技術的な観点から見ると、ビットコインの台帳は、すべての既存のビットコインの所有権状態と「状態変換関数」を含む状態変換システムと見なすことができます。状態変換関数は現在の状態と取引を入力として、新しい状態を出力します。たとえば、標準的な銀行システムでは、状態はバランスシートであり、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

ビットコインシステムの「状態」は、すでに採掘された未使用のビットコイン（技術的には「未使用の取引出力（unspent transaction outputs または UTXO）」と呼ばれます）の集合です。各 UTXO には額面と所有者（20 バイトの本質的に暗号学的な公開鍵のアドレスによって定義されます [1]）があります。1 つの取引には 1 つ以上の入力と 1 つ以上の出力が含まれます。各入力には既存の UTXO への参照と、所有者アドレスに対応する秘密鍵によって作成された暗号学的署名が含まれます。各出力には新しい UTXO が状態に追加されます。ビットコインシステムにおける状態変換関数 APPLY (S,TX)->S’は大まかに次のように定義できます：

取引の各入力：

参照されている UTXO が現在の状態（S）に存在しない場合、エラーメッセージを返します。
署名が UTXO 所有者の署名と一致しない場合、エラーメッセージを返します。

すべての UTXO 入力の額面の合計がすべての UTXO 出力の額面の合計を下回る場合、エラーメッセージを返します。
新しい状態 S’を返します。新しい状態 S’にはすべての入力 UTXO が削除され、すべての出力 UTXO が追加されます。最初のステップの最初の部分は、取引の送信者が存在しないビットコインを費やすのを防ぎ、2 番目の部分は取引の送信者が他人のビットコインを費やすのを防ぎます。2 番目のステップは価値の保存を保証します。ビットコインの支払いプロトコルは次のようになります。仮にアリスがボブに 11.7BTC を送信したいとします。実際、アリスは正確に 11.7BTC を持っていることはできません。仮に、彼女が得られる最小のビットコインの額は 6+4+2=12 です。したがって、彼女は 3 つの入力と 2 つの出力を持つ取引を作成できます。最初の出力の額面は 11.7BTC で、所有者はボブ（ボブのビットコインアドレス）であり、2 番目の出力の額面は 0.3BTC で、所有者はアリス自身、つまりお釣りです。

マイニング#

もし私たちが信頼できる中央集権的なサービス機関を持っているなら、状態変換システムは非常に簡単に実現できます。上記の機能を正確にコーディングするだけです。しかし、私たちはビットコインシステムを分散型の通貨システムとして構築したいと考えています。すべての人が取引の順序に同意することを保証するために、状態変換システムと合意システムを組み合わせる必要があります。ビットコインの分散型合意プロセスは、ネットワーク内のノードが常に取引を「ブロック」にパッケージ化しようとすることを要求します。ネットワークは約 10 分ごとに 1 つのブロックを生成するように設計されており、各ブロックにはタイムスタンプ、ランダム数、前のブロックへの参照（つまりハッシュ）、および前のブロック生成以来に発生したすべての取引のリストが含まれています。このようにして、時間の経過とともに持続的に成長するブロックチェーンが作成され、常に更新され、ビットコイン台帳の最新の状態を表すことができます。このパラダイムに従って、ブロックが有効であるかどうかを確認するアルゴリズムは次のようになります：

ブロックが参照する前のブロックが存在し、有効であるかどうかを確認します。
ブロックのタイムスタンプが前のブロックのタイムスタンプよりも遅く、かつ未来の 2 時間よりも早いかどうかを確認します [2]。
ブロックのプルーフ・オブ・ワークが有効であるかどうかを確認します。
前のブロックの最終状態を S [0] に割り当てます。
TX がブロックの取引リストであり、n 件の取引を含むと仮定します。0……n-1 のすべての i について、状態変換 S [i+1] = APPLY (S [i],TX [i]) を実行します。取引 i のいずれかが状態変換中にエラーが発生した場合、プログラムを終了し、エラーを返します。
正常に戻り、状態 S [n] はこのブロックの最終状態です。

本質的に、ブロック内の各取引は正しい状態変換を提供する必要があります。「状態」はブロックにコーディングされていないことに注意してください。それは純粋に検証ノードが記憶している抽象的な概念であり、任意のブロックについては創世状態から始めて、順番に各ブロックの各取引を加算することで（確実に）現在の状態を計算できます。また、マイナーが取引をブロックに含める順序にも注意が必要です。もしブロック内に A と B の 2 つの取引があり、B が A によって作成された UTXO を使用している場合、A が B の前にあるとこのブロックは有効ですが、そうでなければ無効です。ブロック検証アルゴリズムの興味深い部分は「プルーフ・オブ・ワーク」の概念です：各ブロックに SHA256 ハッシュ処理を行い、得られたハッシュを 256 ビットの数値として扱います。この数値は、動的に調整される目標数値よりも小さくなければなりません。本書執筆時の目標数値は約 2^190 です。プルーフ・オブ・ワークの目的は、ブロックの生成を困難にし、ウィッチ攻撃者が悪意を持ってブロックチェーンを再生成するのを防ぐことです。SHA256 は完全に予測不可能な擬似ランダム関数であるため、有効なブロックを作成する唯一の方法は、単に試行錯誤を繰り返し、ランダム数の値を増加させて、新しいハッシュ数値が目標数値よりも小さいかどうかを確認することです。現在の目標数値が 2^192 である場合、有効なブロックを生成するには平均して 2^64 回の試行が必要です。一般的に、ビットコインネットワークは 2016 ブロックごとに目標数値を再設定し、平均して 10 分ごとに 1 つのブロックを生成します。マイナーの計算作業に報いるために、成功裏にブロックを生成したマイナーは、ブロック内に自分自身に 25BTC を発行する取引を含める権利があります。また、取引の入力が出力を上回る場合、差額部分は「取引手数料」としてマイナーに支払われます。ちなみに、マイナーへの報酬はビットコイン発行の唯一のメカニズムであり、創世状態にはビットコインは存在しません。

マイニングの目的をよりよく理解するために、ビットコインネットワークに悪意のある攻撃者が現れた場合に何が起こるかを分析してみましょう。ビットコインの暗号学的基盤は非常に安全であるため、攻撃者は暗号学的に直接保護されていない部分、すなわち取引の順序を攻撃することを選択します。攻撃者の戦略は非常にシンプルです：

売り手に 100BTC を送信して商品を購入します（特に配送不要な電子商品）。
商品が発送されるまで待ちます。
同じ 100BTC を自分のアカウントに送信する別の取引を作成します。
ビットコインネットワークに自分のアカウントに送信された取引が最初に発信されたと信じ込ませます。
ステップ（1）が発生した後、数分後にマイナーはこの取引をブロックにパッケージ化します。仮にそれが第 270000 ブロックだとします。約 1 時間後、このブロックの後に 5 つのブロックが続き、それぞれのブロックがこの取引を間接的に指し示し、この取引を確認します。この時、売り手は代金を受け取り、買い手に商品を発送します。デジタル商品であると仮定すると、攻撃者は即座に商品を受け取ることができます。今、攻撃者は同じ 100BTC を自分のアカウントに送信する別の取引を作成します。攻撃者がこのメッセージを全ネットワークにブロードキャストするだけでは、この取引は処理されません。マイナーは状態変換関数 APPLY (S,TX) を実行し、この取引が現在の状態に存在しない UTXO を費やすことを発見します。したがって、攻撃者はブロックチェーンをフォークし、第 269999 ブロックを親ブロックとして再生成し、このブロック内で新しい取引で古い取引を置き換えます。ブロックデータが異なるため、再度プルーフ・オブ・ワークを行う必要があります。また、攻撃者が生成した新しい第 270000 ブロックは異なるハッシュを持っているため、元の第 270001 から第 270005 のブロックはそれを指し示しません。したがって、元のブロックチェーンと攻撃者の新しいブロックは完全に分離されます。ブロックチェーンがフォークすると、長いブランチが誠実なブロックチェーンと見なされ、合法的なマイナーは元の第 270005 ブロックの後でマイニングを続け、攻撃者は新しい第 270000 ブロックの後でのみマイニングを行います。攻撃者が自分のブロックチェーンを最長にするためには、彼以外の全ネットワークよりも多くの計算能力を持つ必要があります（すなわち 51% 攻撃）。

マークルツリー

左：マークルツリー（Merkle tree）上の少数のノードを提供するだけで、ブランチの合法的な証明を行うのに十分です。右：マークルツリーの任意の部分を変更しようとする試みは、最終的にチェーン上のどこかに不一致を引き起こします。ビットコインシステムの重要なスケーラビリティ特性は、ブロックが多層のデータ構造に保存されていることです。ブロックのハッシュは実際にはブロックヘッダーのハッシュであり、ブロックヘッダーはタイムスタンプ、ランダム数、前のブロックのハッシュ、およびすべてのブロック取引を格納したマークルツリーのルートハッシュを含む約 200 バイトのデータです。

マークルツリーは、葉ノードのセット、中間ノードのセット、およびルートノードで構成される二分木です。最下層の多数の葉ノードは基礎データを含み、各中間ノードはその 2 つの子ノードのハッシュであり、ルートノードもその 2 つの子ノードのハッシュであり、マークルツリーの頂部を表します。

マークルツリーの目的は、ブロックのデータを散発的に送信できるようにすることです：ノードは 1 つのソースからブロックヘッダーをダウンロードし、別のソースから関連するツリーの他の部分をダウンロードし、すべてのデータが正しいことを確認できます。これは、ハッシュが上に拡散するためです：もし悪意のあるユーザーがツリーの下部に偽造取引を追加しようとすると、引き起こされる変更はツリーの上層ノードの変更を引き起こし、さらに上層ノードの変更を引き起こし、最終的にルートノードの変更とブロックハッシュの変更を引き起こします。このようにして、プロトコルはそれを完全に異なるブロックとして記録します（ほぼ確実に不正なプルーフ・オブ・ワークを伴う）。マークルツリーのプロトコルは、ビットコインの長期的な持続性にとって重要です。

2014 年 4 月、ビットコインネットワーク内のフルノード —— すべてのブロックの全データを保存し処理するノード —— は 15GB のメモリ空間を必要とし、さらに毎月 1GB 以上の速度で増加しています。現在、このストレージ空間はデスクトップコンピュータにとっては許容可能ですが、スマートフォンはこのような巨大なデータを処理できません。将来的には、商業機関と愛好者だけがフルノードとして機能するでしょう。簡素化された支払い確認（SPV）プロトコルは、別のタイプのノードの存在を許可します。このようなノードは「ライトノード」と呼ばれ、ブロックヘッダーをダウンロードし、ブロックヘッダーを使用してプルーフ・オブ・ワークを確認し、その後、取引に関連するマークルツリーの「ブランチ」をダウンロードします。これにより、ライトノードは全ブロックチェーンのごく一部をダウンロードするだけで、任意のビットコイン取引の状態とアカウントの現在の残高を安全に確認できます。他のブロックチェーンアプリケーションは、ブロックチェーンの思想を他の分野に応用するアイデアがすでに登場しています。

2005 年、ニック・サボ（Nick Szabo）は「所有権を財産に冠する」という概念を提案し、複製データベース技術の発展がブロックチェーンに基づくシステムを土地所有権の登録に適用できるようにする詳細なフレームワークを作成しました。たとえば、土地権、違法侵害、ジョージア州の土地税などの概念を含む詳細なフレームワークを作成しました。しかし、残念ながら、その時点では実用的な複製データベースシステムが存在しなかったため、このプロトコルは実行されませんでした。しかし、2009 年にビットコインシステムの分散型合意が成功裏に開発されて以来、多くの他のブロックチェーンアプリケーションが急速に登場し始めました。

ドメインコイン（namecoin）- 2010 年に設立され、分散型の名前登録データベースと呼ばれています。

Tor、Bitcoin、BitMessage のような分散型プロトコルは、他の人がユーザーと相互作用できるようにするためのアカウントの確認方法を必要とします。しかし、すべての既存の解決策の中で唯一利用可能なアイデンティティ識別子は、1LW79wp5ZBqaHW1jL5TciBCrhQYtHagUWy のような擬似ランダムハッシュです。理想的には、人々は「george」のような名前を持つアカウントを持ちたいと考えています。しかし、問題は、誰かが「george」アカウントを作成できる場合、他の人も同様に「george」アカウントを作成して偽装できるということです。唯一の解決策は先に申請した者が優先される原則（first-to-file）であり、最初の登録者のみが成功裏に登録でき、2 番目の者は同じアカウントを再登録できません。この問題はビットコインの合意プロトコルを利用できます。

ドメインコインは、ブロックチェーンを利用して名前登録システムを実現する最も早く、最も成功したシステムです。 - カラードコイン（Colored coins）- カラードコインの目的は、人々がビットコインブロックチェーン上で独自のデジタル通貨を作成すること、または、より重要な一般的な意味での通貨 – デジタルトークンを提供することです。カラードコインプロトコルに従って、人々は特定のビットコイン UTXO に色を指定することで新しい通貨を発行できます。このプロトコルは、他の UTXO を取引入力 UTXO と同じ色として再帰的に定義します。これにより、ユーザーは特定の色の UTXO のみを保持し、これらの UTXO を送信することは通常のビットコインを送信するのと同じように、全ブロックチェーンを遡って受け取った UTXO の色を判断します。

メタコイン（Metacoins）- メタコインの理念は、ビットコインブロックチェーン上で新しいプロトコルを作成し、ビットコインの取引を使用してメタコインの取引を保存することですが、異なる状態変換関数 APPLY’を使用します。メタコインプロトコルはビットコインブロックチェーン上の無効なメタコイン取引を防ぐことができないため、APPLY’(S,TX) がエラーを返す場合、このプロトコルはデフォルトで APPLY’(S,TX) = S とします。これにより、ビットコインシステムでは実現できない任意の先進的な暗号通貨プロトコルを作成するための簡単な解決策が提供され、開発コストは非常に低くなります。なぜなら、マイニングとネットワークの問題はビットコインプロトコルによって処理されているからです。

したがって、一般的に、合意プロトコルを確立する方法は 2 つあります：独立したネットワークを構築するか、ビットコインネットワーク上にプロトコルを構築するかです。ドメインコインのようなアプリケーションは最初の方法を使用して成功を収めましたが、この方法の実施は非常に困難です。なぜなら、各アプリケーションは独立したブロックチェーンを作成し、すべての状態変換とネットワークコードを構築、テストする必要があるからです。また、分散型合意技術の適用は冪乗分布に従うと予測されており、大多数のアプリケーションは自由なブロックチェーンの安全性を保証するには小さすぎます。また、大量の分散型アプリケーション、特に分散型自律組織は、アプリケーション間の相互作用を必要とすることにも注意が必要です。一方、ビットコインに基づく方法には欠点があります。それは、ビットコインが簡素化された支払い確認（SPV）の特性を継承していないことです。ビットコインは簡素化された支払い確認を実現できます。なぜなら、ビットコインはブロックチェーンの深さを有効性確認の代理として使用できるからです。ある時点で、取引の祖先が現在から十分に遠くなると、それらは合法的な状態の一部と見なすことができます。それに対して、ビットコインブロックチェーンに基づくメタコインプロトコルは、ブロックチェーンがメタコインプロトコルに準拠しない取引を含まないように強制することができません。したがって、安全なメタコインプロトコルの簡素化された支払い確認には、すべてのブロックを遡ってスキャンし、ブロックチェーンの初期点まで戻って、特定の取引が有効かどうかを確認する必要があります。現在、すべてのビットコインベースのメタコインプロトコルの「ライト」実装は、信頼できるサーバーにデータを提供させることに依存しています。これは、信頼を排除することを主な目的とする暗号通貨にとっては、かなり劣った結果です。

スクリプト#

ビットコインプロトコルを拡張しなくても、ある程度「スマートコントラクト」を実現できます。ビットコインの UTXO は、1 つの公開鍵だけでなく、スタックベースのプログラミング言語で書かれたより複雑なスクリプトでも所有できます。このモデルでは、このような UTXO を費やすためには、スクリプトを満たすデータを提供する必要があります。実際、基本的な公開鍵所有権メカニズムもスクリプトによって実現されています：スクリプトは楕円曲線署名を入力として受け取り、取引を検証し、この UTXO のアドレスを持つかどうかを確認します。検証が成功すれば 1 を返し、そうでなければ 0 を返します。より複雑なスクリプトは他の異なるアプリケーションシナリオに使用されます。たとえば、人々は 3 つの秘密鍵のうち 2 つを集めることを要求するスクリプト（マルチシグネチャ）を作成できます。これは、企業アカウント、貯蓄アカウント、および特定のビジネス代理人にとって非常に便利です。スクリプトは、計算問題を解決するユーザーに報酬を送信するためにも使用できます。人々は「あなたが私に一定の量のドージコインを送信したという簡素化された支払い証明を提供できれば、このビットコイン UTXO はあなたのものです」というスクリプトを作成することさえできます。

本質的に、ビットコインシステムは異なる暗号通貨の分散型交換を許可します。しかし、ビットコインシステムのスクリプト言語にはいくつかの深刻な制限があります：

チューリング完全性の欠如 – これは、ビットコインスクリプト言語がさまざまな計算をサポートできる一方で、すべての計算をサポートできないことを意味します。最も重要な欠落はループ文です。

ループ文をサポートしない目的は、取引確認時に無限ループが発生するのを避けることです。理論的には、スクリプトプログラマーにとってこれは克服可能な障害ですが、なぜなら、任意のループは if 文を繰り返すことでシミュレートできるからです。しかし、これによりスクリプトの空間利用が低効率になります。たとえば、代替の楕円曲線署名アルゴリズムを実装するには 256 回の繰り返し乗算が必要であり、各回ごとに個別にコーディングする必要があります。

価値盲（Value-blindness）。

UTXO スクリプトはアカウントの引き出し限度を細かく制御することができません。

たとえば、オラクル契約（oracle contract）の強力なアプリケーションの 1 つはヘッジ契約であり、A と B がそれぞれ 1000 ドルのビットコインをヘッジ契約に送信し、30 日後にスクリプトが A に 1000 ドルのビットコインを送信し、B に残りのビットコインを送信します。ヘッジ契約を実現するには、オラクル（oracle）が 1 ビットコインの価値を何ドルにするかを決定する必要がありますが、現在の完全に中央集権的な解決策と比較して、このメカニズムは信頼とインフラの面で大きな進歩を遂げています。しかし、UTXO は分割不可能であるため、この契約を実現する唯一の方法は、非常に非効率的に異なる額面の UTXO を多数使用することです（たとえば、最大 30 に対応する各 k に対して、2^k の UTXO があります）。 - 状態の欠如 – UTXO は支出済みまたは未支出の状態しか持たないため、複数の段階の契約やスクリプトに必要な他の内部状態の生存空間がありません。これにより、複数段階のオプション契約、分散型交換オファー、または 2 段階の暗号化コミットメントプロトコル（計算報酬を確保するために非常に必要です）を実現することが非常に困難になります。これにより、UTXO は単純で一度限りの契約を構築するためにのみ使用でき、分散型組織のようなより複雑な状態を持つ契約を構築することはできず、メタプロトコルの実現が困難になります。二元状態と価値盲が組み合わさることで、もう 1 つの重要なアプリケーションである引き出し限度が実現不可能になります。 - ブロックチェーン盲（Blockchain-blindness）- UTXO はブロックチェーンのデータ（たとえば、ランダム数や前のブロックのハッシュ）を見ることができません。この欠陥は、スクリプト言語が持つランダム性に基づく潜在的な価値を奪い、ギャンブルなどの他の分野のアプリケーションを深刻に制限します。私たちは、暗号通貨上に高度なアプリケーションを構築するための 3 つの方法を検討しました：新しいブロックチェーンを構築する、ビットコインブロックチェーン上でスクリプトを使用する、ビットコインブロックチェーン上でメタコインプロトコルを構築する。新しいブロックチェーンを構築する方法は、任意の機能を自由に実現できますが、コストは開発時間と育成努力です。スクリプトを使用する方法は非常に簡単に実現でき、標準化されていますが、その能力には限界があります。メタコインプロトコルは非常に簡単に実現できますが、スケーラビリティの欠陥があります。以太坊システムでは、私たちの目的は、これら 3 つのモデルのすべての利点を持つ汎用フレームワークを構築することです。

以太坊#

以太坊の目的は、スクリプト、競争通貨、チェーン上のメタプロトコル（on-chain meta-protocol）概念を統合し、開発者が任意の合意に基づく、拡張可能で、標準化された、機能が完全で、開発が容易で、協調的なアプリケーションを作成できるようにすることです。以太坊は、チューリング完全なプログラミング言語を内蔵した究極の抽象的な基盤層を構築することによって、誰でも契約や分散型アプリケーションを作成できるようにし、その中で自由に定義されたすべての所有権ルール、取引方法、状態変換関数を設定できます。

ドメインコインの主体フレームワークは、わずか 2 行のコードで実現できます。通貨や信用システムなどの他のプロトコルは、20 行未満のコードで実現できます。スマートコントラクト —— 価値を含み、特定の条件を満たさなければ開けられない暗号箱 —— も私たちのプラットフォーム上で作成でき、チューリング完全性、価値認識（value-awareness）、ブロックチェーン認識（blockchain-awareness）、および多状態によって強化され、ビットコインスクリプトが提供できるスマートコントラクトよりもはるかに強力です。

以太坊アカウント#

以太坊システムでは、状態は「アカウント」と呼ばれるオブジェクト（各アカウントは 20 バイトのアドレスによって識別されます）と、2 つのアカウント間で価値と情報を移転する状態変換から構成されます。以太坊のアカウントは 4 つの部分を含みます：

ランダム数、各取引が一度だけ処理されることを決定するカウンター
アカウントの現在のイーサ残高
アカウントの契約コード（存在する場合）
アカウントのストレージ（デフォルトは空）

イーサ（Ether）は、以太坊内部の主要な暗号燃料であり、取引手数料を支払うために使用されます。一般的に、以太坊には 2 種類のアカウントがあります：

外部所有アカウント（秘密鍵によって制御される）と契約アカウント（契約コードによって制御される）。外部所有アカウントにはコードがなく、人々は取引を作成し、署名することで外部アカウントからメッセージを送信できます。契約アカウントがメッセージを受け取ると、契約内部のコードがアクティブになり、内部ストレージを読み書きし、他のメッセージを送信したり契約を作成したりすることができます。

メッセージと取引
以太坊のメッセージは、ある程度ビットコインの取引に似ていますが、両者には 3 つの重要な違いがあります。

第一に、以太坊のメッセージは外部エンティティまたは契約によって作成されることができますが、ビットコインの取引は外部からのみ作成されます。

第二に、以太坊のメッセージはデータを含めることを選択できます。

第三に、以太坊のメッセージの受信者が契約アカウントである場合、応答を行うことを選択できるため、以太坊のメッセージには関数の概念も含まれます。

以太坊における「取引」とは、外部アカウントから送信されたメッセージの署名データパッケージを指します。取引にはメッセージの受信者、送信者を確認するための署名、イーサアカウントの残高、送信するデータ、および STARTGAS と GASPRICE と呼ばれる 2 つの数値が含まれます。

コードの指数的爆発と無限ループを防ぐために、各取引は実行コードによって引き起こされる計算ステップ（初期メッセージとすべての実行中に引き起こされるメッセージを含む）に制限を設ける必要があります。STARTGAS は制限であり、GASPRICE は各計算ステップに対してマイナーに支払う費用です。取引の実行中に「燃料が尽きた」場合、すべての状態変更は元の状態に戻りますが、すでに支払われた取引手数料は返金されません。取引が中止されたときに燃料が残っている場合、その燃料は送信者に返還されます。契約の作成には別の取引タイプと対応するメッセージタイプがあります。契約のアドレスはアカウントのランダム数と取引データのハッシュから計算されます。

メッセージメカニズムの重要な結果は、以太坊の「ファーストクラス」財産 —— 契約が外部アカウントと同じ権利を持ち、メッセージを送信したり他の契約を作成したりする権利を持つことです。これにより、契約は同時に複数の異なる役割を果たすことができます。たとえば、ユーザーは分散型組織（契約）のメンバーを仲介アカウント（別の契約）にし、偏執的な使用者にカスタマイズされた量子証明に基づくランボート署名（第三の契約）を提供し、5 つの秘密鍵で安全を保証されたアカウント（第四の契約）の共同署名エンティティを提供することができます。以太坊プラットフォームの強力な点は、分散型組織や代理契約が契約の各参加者がどのタイプのアカウントであるかを気にする必要がないことです。

以太坊の状態変換関数

以太坊の状態変換関数：APPLY (S,TX) -> S’は次のように定義できます：

取引の形式が正しいか（すなわち正しい数値があるか）、署名が有効か、ランダム数が送信者アカウントのランダム数と一致するかを確認します。そうでない場合、エラーを返します。
取引手数料を計算します：fee=STARTGAS * GASPRICE を計算し、署名から送信者のアドレスを特定します。送信者のアカウントから取引手数料を減算し、送信者のランダム数を増加させます。アカウントの残高が不足している場合、エラーを返します。
初期値 GAS = STARTGAS を設定し、取引内のバイト数に基づいて一定量の燃料値を減算します。
送信者のアカウントから受信者アカウントに価値を移転します。受信アカウントがまだ存在しない場合、このアカウントを作成します。受信アカウントが契約である場合、契約のコードを実行し、コードの実行が終了するまで、または燃料が尽きるまで実行します。
送信者アカウントに十分なお金がない場合やコードの実行が燃料を使い果たしたために価値の移転が失敗した場合、元の状態に戻りますが、取引手数料は支払われる必要があります。取引手数料はマイナーアカウントに追加されます。
そうでない場合、すべての残りの燃料を送信者に返還し、消費された燃料を取引手数料としてマイナーに送信します。たとえば、契約のコードが次のようなものであると仮定します：

注意すべきは、実際には契約コードは基盤となるイーサリアム仮想マシン（EVM）コードで書かれています。上記の契約は、私たちの高級言語である Serpent 言語で書かれており、EVM コードにコンパイルされます。契約のストレージが最初は空であり、10 イーサの値、燃料が 2000、燃料価格が 0.001 イーサであり、2 つのデータフィールドの値が [2, 'CHARLIE'] [3] の取引が送信された後、状態変換関数の処理プロセスは次のようになります：

取引が有効か、形式が正しいかを確認します。
取引送信者が少なくとも 2000*0.001=2 イーサを持っているかを確認します。もしそうであれば、送信者アカウントから 2 イーサを減算します。
初期設定 gas=2000、取引長が 170 バイトであり、各バイトの費用が 5 であると仮定し、850 を減算しますので、残りは 1150 です。
送信者アカウントから 10 イーサを減算し、契約アカウントに 10 イーサを追加します。
コードを実行します。この契約では、コードを実行するのは簡単です：契約ストレージのインデックス 2 が使用されているかどうかを確認し、使用されていないことに気づき、その値を CHARLIE に設定します。仮にこれが 187 単位の燃料を消費したとすると、残りの燃料は 1150 – 187 = 963 です。
送信者のアカウントに 963*0.001=0.963 イーサを追加し、最終状態を返します。契約が取引を受け取らない場合、すべての取引手数料は取引のバイト長に等しくなり、取引データは取引手数料とは無関係になります。また、契約が発信したメッセージは、それらが生成する計算に燃料制限を設定できます。もしサブ計算の燃料が尽きた場合、メッセージが発信されたときの状態に戻ります。したがって、取引と同様に、契約も生成するサブ計算に対して厳格な制限を設定し、計算リソースを保護できます。

コード実行#

以太坊契約のコードは、低レベルのスタックベースのバイトコード言語で書かれており、「イーサリアム仮想マシンコード」または「EVM コード」と呼ばれています。

コードは一連のバイトで構成され、各バイトは 1 つの操作を表します。一般的に、コードの実行は無限ループであり、プログラムカウンタが 1 増加するたびに（初期値はゼロ）、1 回の操作が実行され、コードが完了するか、エラー、STOP、または RETURN 命令に遭遇するまで続きます。操作は 3 つのデータストレージスペースにアクセスできます：

スタック、後入れ先出しのデータストレージであり、32 バイトの数値をスタックに入れたり出したりできます。

メモリ、無限に拡張可能なバイトキュー。
契約の長期ストレージ、キー / 値のストレージであり、キーと値は 32 バイトのサイズであり、計算が終了するとリセットされるスタックとメモリとは異なり、ストレージの内容は長期間保持されます。コードはブロックヘッダーのデータ、送信者および受信者のメッセージ内のデータにアクセスでき、コードは出力としてデータのバイトキューを返すこともできます。EVM コードの正式な実行モデルは驚くほどシンプルです。

イーサリアム仮想マシンが実行されると、その完全な計算状態はタプル（block_state, transaction, message, code, memory, stack, pc, gas）によって定義されます。ここで block_state はすべてのアカウントの残高とストレージを含むグローバル状態です。各実行ラウンドでは、コードの pc（プログラムカウンタ）バイトを呼び出すことによって、現在の命令が見つかり、各命令はタプルにどのように影響を与えるかを定義します。

たとえば、ADD は 2 つの要素をスタックから出し、それらの合計をスタックに入れ、ガス（燃料）を 1 減らし、pc を 1 増やします。SSTORE は、スタックのトップの 2 つの要素を出し、最初の要素によって定義された契約ストレージ位置に 2 番目の要素を挿入し、最大 200 のガス値を減らし、pc を 1 増やします。イーサリアムを最適化するための多くの方法がありますが、イーサリアムの基本的な実装は数百行のコードで実現できます。

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

いくつかの違いはありますが、以太坊のブロックチェーンは多くの点でビットコインのブロックチェーンに似ています。彼らのブロックチェーンアーキテクチャの違いは、以太坊のブロックには取引記録と最近の状態だけでなく、ブロック番号と難易度値も含まれていることです。以太坊のブロック確認アルゴリズムは次のようになります：

ブロックが参照する前のブロックが存在し、有効であるかを確認します。
ブロックのタイムスタンプが参照された前のブロックよりも大きく、かつ 15 分未満であるかを確認します。
ブロック番号、難易度値、取引ルート、叔ルート、燃料限度（多くの以太坊特有の基盤概念）が有効であるかを確認します。
ブロックのプルーフ・オブ・ワークが有効であるかを確認します。
S [0] を前のブロックの STATE_ROOT に割り当てます。
TX をブロックの取引リストに割り当て、合計 n 件の取引があります。0……n-1 の i に対して、状態変換 S [i+1] = APPLY (S [i],TX [i]) を実行します。いずれかの変換でエラーが発生した場合、エラーを返します。
S-FINAL に S [n] を割り当て、マイナーにブロック報酬を支払います。
S-FINAL が STATE_ROOT と同じであるかを確認します。同じであれば、ブロックは有効です。そうでなければ、ブロックは無効です。
この確認方法は一見効率が非常に低いように見えます。なぜなら、各ブロックのすべての状態を保存する必要があるからです。しかし、実際には、以太坊の確認効率はビットコインと同等です。その理由は、状態がツリー構造（tree structure）に保存されているためであり、各ブロックが追加されるたびにツリー構造の一部だけを変更する必要があるからです。したがって、一般的に、隣接する 2 つのブロックのツリー構造の大部分は同じであるべきであり、データを 1 回保存することで、ポインタ（すなわちサブツリーハッシュ）を利用して 2 回参照できます。「パトリシアツリー（Patricia Tree）」と呼ばれるツリー構造は、これを実現でき、マークルツリーの概念に対する修正を含んでおり、ノードを変更するだけでなく、ノードを挿入および削除することも可能です。また、すべての状態情報が最後のブロックの一部であるため、すべてのブロック履歴を保存する必要はありません。この方法がビットコインシステムに適用できれば、計算によってストレージスペースを 10〜20 倍節約できることがわかります。

アプリケーション
一般的に、以太坊上には 3 種類のアプリケーションがあります。第一のタイプは金融アプリケーションであり、ユーザーに彼らの資金を管理し、契約に参加するためのより強力な方法を提供します。これにはサブ通貨、金融派生商品、ヘッジ契約、貯蓄パッケージ、遺言、さらにはいくつかの種類の包括的な雇用契約が含まれます。第二のタイプは半金融アプリケーションであり、ここにはお金が存在しますが、非金銭的な側面も非常に重視されます。完璧な例は、計算問題を解決するために設定された自己強制的な報酬です。最後に、オンライン投票や分散型ガバナンスのような完全な非金融アプリケーションがあります。

トークンシステム
チェーン上のトークンシステムには多くのアプリケーションがあり、ドルや金などの資産を表すサブ通貨から、企業の株式、独自のトークン、セキュリティの偽造防止クーポン、さらには従来の価値とは完全に無関係なポイント報酬のためのトークンシステムまで含まれます。以太坊でトークンシステムを実装することは驚くほど簡単です。

重要な点は、すべての通貨またはトークンシステムは、本質的には次の操作を持つデータベースであることを理解することです：A から X 単位を減算し、X 単位を B に加算する。ただし、前提条件は（1）A が取引の前に少なくとも X 単位を持っていること、（2）取引が A によって承認されることです。

トークンシステムを実装することは、このようなロジックを契約に実装することです。Serpent 言語でトークンシステムの基本コードを実装すると、次のようになります：

これは、本質的にこの記事でさらに説明する「銀行システム」状態変換機能の最小限の実装です。初期およびその他のいくつかの限界ケースで通貨を配布する機能を提供するために、いくつかの追加コードを追加する必要があります。理想的には、他の契約がアドレスの残高を照会できるようにする関数を追加します。それで十分です。

理論的には、以太坊に基づくサブ通貨としてのトークンシステムは、ビットコインのチェーン上のメタコインが欠けている重要な機能を含む可能性があります：この通貨を使用して取引手数料を直接支払う能力。この能力を実現する方法は、契約内にイーサアカウントを維持し、送信者の取引手数料を支払うために使用します。取引手数料として使用される内部通貨を収集し、それを継続的に実行されるオークションで販売することによって、契約はそのイーサアカウントに資金を注入し続けます。これにより、ユーザーはイーサでアカウントを「アクティブ化」する必要がありますが、一度アカウントにイーサがあれば、それは再利用されます。なぜなら、各契約はそのアカウントに再度資金を注入するからです。

金融派生商品と価値安定通貨
金融派生商品は「スマートコントラクト」の最も一般的なアプリケーションであり、コードで実装するのが最も簡単なものの 1 つです。金融契約を実現する上での主要な課題は、それらのほとんどが外部の価格発行者を参照する必要があることです。たとえば、非常に需要の高いアプリケーションは、イーサ（または他の暗号通貨）のドルに対する価格変動をヘッジするためのスマートコントラクトですが、この契約はイーサのドルに対する価格を知る必要があります。最も簡単な方法は、特定の機関（たとえば NASDAQ）が維持する「データ提供」契約を通じて行うことであり、この契約はその機関が必要に応じて契約を更新し、他の契約がその契約にメッセージを送信して価格情報を含む応答を取得できるインターフェースを提供します。

これらの重要な要素がすべて揃った場合、ヘッジ契約は次のようになります：
A が 1000 イーサを入力するのを待ちます。B が 1000 イーサを入力するのを待ちます。

データ提供契約を照会し、1000 イーサのドル価値（たとえば、x ドル）をストレージに記録します。30 日後、A または B が契約を「再アクティブ化」して、x ドルの価値のイーサを A に送信し、残りのイーサを B に送信することを許可します。このような契約は、暗号商取引において異常な潜在能力を持っています。暗号通貨はその価格の変動性がしばしば批判されます。多くのユーザーや商人が暗号資産の安全性と便利さを必要としているかもしれませんが、彼らは 1 日のうちに資産が 23% の価値を失う状況に直面することを好まないでしょう。これまでのところ、最も一般的な推奨策は、発行者が資産を裏付けることです。発行者がサブ通貨を作成し、そのサブ通貨に対して発行および償還する権利を持ち、（オフラインで）特定の関連資産（たとえば金、ドル）を提供する人に 1 単位のサブ通貨を与えるという考え方です。

発行者は、誰かが暗号資産の 1 単位を返還するときに、関連資産の 1 単位を返還することを約束します。このメカニズムにより、発行者が信頼できる場合、任意の非暗号資産を「アップグレード」して暗号資産にすることができます。しかし、実際には、発行者が常に信頼できるわけではなく、銀行システムがあまりにも脆弱であったり、誠実でないために、そのようなサービスが存在できない場合もあります。

金融派生商品は代替案を提供します。ここでは、資産を支えるための個別の発行者は存在せず、代わりに、ある暗号資産の価格が上昇することを賭ける投機者で構成される分散型市場が存在します。発行者とは異なり、投機者側には交渉の権利はありません。なぜなら、ヘッジ契約が彼らの準備金を契約の中に凍結させるからです。この方法は完全に分散型ではありませんが、価格情報を提供する信頼できるデータソースが依然として必要です。とはいえ、発行者とは異なり、価格発行者はライセンスを必要とせず、自由な言論の一部として分類されるように見えるため、基盤となるインフラの需要を減少させ、潜在的な詐欺リスクを軽減する大きな進歩となります。

アイデンティティと信用システム#

最初の代替通貨であるドメインコインは、ビットコインブロックチェーンを使用して名前登録システムを提供し、ユーザーが自分の名前やその他のデータを公共データベースに登録できるようにしようとしました。最も一般的なアプリケーションケースは、「bitcoin.org」（またはドメインコインでは「bitcoin.bit」）のようなドメイン名を IP アドレスに対応させることです。他のアプリケーションケースには、電子メール検証システムや、より高度な信用システムの可能性が含まれます。ここに、以太坊でドメインコインに類似した名前登録システムを提供する基本契約があります：

契約は非常にシンプルです。これは、以太坊ネットワーク内で追加可能ですが、変更または削除できないデータベースです。誰でも名前を値として登録し、永遠に不変にすることができます。より複雑な名前登録契約には、他の契約が照会できる「機能条項」を含むことができ、名前の「所有者」（すなわち「最初の登録者」）がデータを変更したり所有権を移転したりするメカニズムを含むことができます。さらに、信用と信頼ネットワーク機能を追加することもできます。

分散型ストレージ
過去数年間に、Dropbox のような一般的なオンラインファイルストレージのスタートアップがいくつか登場しました。これは、ユーザーがハードドライブのバックアップをアップロードし、バックアップストレージサービスを提供し、ユーザーがアクセスできるようにして、月ごとに料金を請求することを目指しています。

しかし、この時点で、このファイルストレージ市場は時折相対的に非効率的です。既存のサービスの粗い観察によれば、特に「ミステリー・バレー」の 20-200GB のレベルでは、無料スペースも企業向けユーザー割引もないため、主流のファイルストレージコストは、1 か月でハードドライブ全体のコストを支払うことを意味します。以太坊契約は、ユーザーが自分のハードドライブや未使用のネットワークスペースを貸し出して少額の利益を得ることによって、ファイルストレージのコストを削減できるようにする分散型ストレージエコシステムの開発を許可します。このような施設の基本的な構成要素は、私たちが「分散型 Dropbox 契約」と呼ぶものです。

この契約の動作原理は次のとおりです。

まず、誰かがアップロードする必要があるデータをブロックに分割し、各データブロックを暗号化してプライバシーを保護し、これを使用してマークルツリーを構築します。次に、次のルールを含む契約を作成します。N ブロックごとに、契約はマークルツリーからランダムインデックスを抽出します（契約コードがアクセスできる前のブロックのハッシュを使用してランダム性を提供します）。次に、最初のエンティティ X にイーサを提供し、特定のインデックスにあるブロック