この入門論文は、Ethereumの創設者であるVitalik Buterinが、2015年のプロジェクト立ち上げ前の2014年に発表したものです。多くのコミュニティ主導のオープンソースソフトウェアプロジェクトと同様に、Ethereumも最初の立ち上げから進化してきたことは特筆に値します。
数年前のものではありますが、本論文は引き続き有用な参考資料として、またイーサリアムとそのビジョンについて正確に表現しているため、維持しています。イーサリアムの最新の開発状況や、プロトコルの変更がどのように行われるかを知るには、このガイドをお勧めします。
A Next-Generation Smart Contract and Decentralized Application Platform
Satoshi Nakamoto’s development of Bitcoin in 2009 has often been hailed as a radical development in money and currency, being the first example of a digital asset which simultaneously has no backing or “intrinsic value” and no centralized issuer or controller. However, another, arguably more important, part of the Bitcoin experiment is the underlying blockchain technology as a tool of distributed consensus, and attention is rapidly starting to shift to this other aspect of Bitcoin. Commonly cited alternative applications of blockchain technology include using on-blockchain digital assets to represent custom currencies and financial instruments (“colored coins”), the ownership of an underlying physical device (“smart property”), non-fungible assets such as domain names (“Namecoin”), as well as more complex applications involving having digital assets being directly controlled by a piece of code implementing arbitrary rules (“smart contracts”) or even blockchain-based “decentralized autonomous organizations” (DAOs). What Ethereum intends to provide is a blockchain with a built-in fully fledged Turing-complete programming language that can be used to create “contracts” that can be used to encode arbitrary state transition functions, allowing users to create any of the systems described above, as well as many others that we have not yet imagined, simply by writing up the logic in a few lines of code.
Introduction to Bitcoin and Existing Concepts
History
The concept of decentralized digital currency, as well as alternative applications like property registries, has been around for decades. The anonymous e-cash protocols of the 1980s and the 1990s, mostly reliant on a cryptographic primitive known as Chaumian blinding, provided a currency with a high degree of privacy, but the protocols largely failed to gain traction because of their reliance on a centralized intermediary. In 1998, Wei Dai’s b-money became the first proposal to introduce the idea of creating money through solving computational puzzles as well as decentralized consensus, but the proposal was scant on details as to how decentralized consensus could actually be implemented. In 2005, Hal Finney introduced a concept of “reusable proofs of work”, a system which uses ideas from b-money together with Adam Back’s computationally difficult Hashcash puzzles to create a concept for a cryptocurrency, but once again fell short of the ideal by relying on trusted computing as a backend. In 2009, a decentralized currency was for the first time implemented in practice by Satoshi Nakamoto, combining established primitives for managing ownership through public key cryptography with a consensus algorithm for keeping track of who owns coins, known as “proof-of-work”.
The mechanism behind proof-of-work was a breakthrough in the space because it simultaneously solved two problems. First, it provided a simple and moderately effective consensus algorithm, allowing nodes in the network to collectively agree on a set of canonical updates to the state of the Bitcoin ledger. Second, it provided a mechanism for allowing free entry into the consensus process, solving the political problem of deciding who gets to influence the consensus, while simultaneously preventing sybil attacks. It does this by substituting a formal barrier to participation, such as the requirement to be registered as a unique entity on a particular list, with an economic barrier – the weight of a single node in the consensus voting process is directly proportional to the computing power that the node brings. Since then, an alternative approach has been proposed called proof-of-stake, calculating the weight of a node as being proportional to its currency holdings and not computational resources; the discussion of the relative merits of the two approaches is beyond the scope of this paper but it should be noted that both approaches can be used to serve as the backbone of a cryptocurrency.
次世代スマートコントラクトと分散型アプリケーションプラットフォーム
2009年にサトシ・ナカモトが開発したビットコインは、裏付けや「本質的価値」を持たず、同時に中央集権的な発行者や管理者を持たないデジタル資産の最初の例として、しばしば貨幣や通貨におけるラディカルな展開として歓迎されてきました。しかし、ビットコインの実験のもう一つの、間違いなくより重要な部分は、分散型コンセンサスのツールとしてのブロックチェーン技術の基礎であり、ビットコインのこの別の側面に注目が急速に集まり始めている。ブロックチェーン技術の代替用途としてよく挙げられるのは、ブロックチェーン上のデジタル資産をカスタム通貨や金融商品（「カラーコイン」）、基盤となる物理デバイスの所有権（「スマートプロパティ」）、ドメイン名（「Namecoin」）などの非化石資産、さらにはデジタル資産を任意のルールを実装したコード片で直接制御する（「スマートコントラクト」）、あるいはブロックチェーンベースの「分散型自律組織（DAOs）」などを含むより複雑なアプリケーションなどです。イーサリアムが提供しようとしているのは、本格的なチューリング完全プログラミング言語が組み込まれたブロックチェーンであり、これを用いて任意の状態遷移関数をコード化した「コントラクト」を作成し、数行のコードで論理を記述するだけで、上記のシステムだけでなく、我々がまだ想像もつかないような多くのシステムを構築することができるようになるのである。
ビットコインと既存概念の紹介
歴史
分散型デジタル通貨のコンセプトは、不動産登記などの代替アプリケーションと同様に、何十年も前から存在しています。1980 年代と 1990 年代の匿名電子マネープロトコルは、主に Chaumian Blinding として知られる暗号原始に依存しており、高度なプライバシーを持つ通貨を提供していましたが、集中型の仲介者に依存していたため、このプロトコルはほとんど普及することができませんでした。1998年、Wei Daiのb-moneyは、計算パズルを解くことで貨幣を生成するというアイデアと分散型コンセンサスを導入した最初の提案となったが、分散型コンセンサスを実際にどのように実装するのかについての詳細は乏しいものであった。2005年にはHal Finneyが「reusable proofs of work」という概念を導入し、b-moneyのアイデアとAdam Backの計算困難なHashcashパズルを併用して暗号通貨のコンセプトを作り上げたが、バックエンドを信頼できる計算機に依存することで再び理想から外れることとなった。2009年、Satoshi Nakamotoによって、分散型通貨が初めて実用化された。公開鍵暗号方式による所有権管理のためのプリミティブと、コインの所有者を記録するためのコンセンサスアルゴリズム（「プルーフ・オブ・ワーク」と呼ばれる）が組み合わされたもので、「プルーフ・オブ・ワーク」の背後にあるメカニズムは、暗号化されたコインの所有者を記録するためのものだった。
プルーフ・オブ・ワークを支える仕組みは、2つの問題を同時に解決するものであり、この分野でのブレークスルーとなった。まず、シンプルで適度に効果的なコンセンサスアルゴリズムを提供し、ネットワーク内のノードがビットコイン台帳の状態に対する一連の正規の更新に集合的に合意することを可能にしました。第二に、コンセンサスプロセスへの自由な参入を可能にするメカニズムを提供し、誰がコンセンサスに影響を与えるかを決定するという政治的問題を解決すると同時に、シビル攻撃を防止する。これは、特定のリストにユニークなエンティティとして登録される必要があるなど、参加に対する形式的な障壁を経済的な障壁で置き換えることによって実現されている。その後、proof-of-stakeと呼ばれる別のアプローチも提案され、ノードの重みは計算資源ではなく、保有する通貨に比例すると計算されている。2つのアプローチの相対的な利点の議論は本稿の範囲外だが、どちらのアプローチも暗号通貨のバックボーンとして利用できることは覚えておいてほしい。
From a technical standpoint, the ledger of a cryptocurrency such as Bitcoin can be thought of as a state transition system, where there is a “state” consisting of the ownership status of all existing bitcoins and a “state transition function” that takes a state and a transaction and outputs a new state which is the result. In a standard banking system, for example, the state is a balance sheet, a transaction is a request to move $X from A to B, and the state transition function reduces the value in A’s account by $X and increases the value in B’s account by $X. If A’s account has less than $X in the first place, the state transition function returns an error. Hence, one can formally define:
APPLY(S,TX) -> S’ or ERROR
In the banking system defined above:
APPLY({ Alice: $50, Bob: $50 },”send $20 from Alice to Bob”) = { Alice: $30, Bob: $70 }
But:
APPLY({ Alice: $50, Bob: $50 },”send $70 from Alice to Bob”) = ERROR
The “state” in Bitcoin is the collection of all coins (technically, “unspent transaction outputs” or UTXO) that have been minted and not yet spent, with each UTXO having a denomination and an owner (defined by a 20-byte address which is essentially a cryptographic public keyfn1). A transaction contains one or more inputs, with each input containing a reference to an existing UTXO and a cryptographic signature produced by the private key associated with the owner’s address, and one or more outputs, with each output containing a new UTXO to be added to the state.
The state transition function APPLY(S,TX) -> S’ can be defined roughly as follows:
For each input in TX:
If the referenced UTXO is not in S, return an error.
If the provided signature does not match the owner of the UTXO, return an error.
If the sum of the denominations of all input UTXO is less than the sum of the denominations of all output UTXO, return an error.
Return S with all input UTXO removed and all output UTXO added.
The first half of the first step prevents transaction senders from spending coins that do not exist, the second half of the first step prevents transaction senders from spending other people’s coins, and the second step enforces conservation of value. In order to use this for payment, the protocol is as follows. Suppose Alice wants to send 11.7 BTC to Bob. First, Alice will look for a set of available UTXO that she owns that totals up to at least 11.7 BTC. Realistically, Alice will not be able to get exactly 11.7 BTC; say that the smallest she can get is 6+4+2=12. She then creates a transaction with those three inputs and two outputs. The first output will be 11.7 BTC with Bob’s address as its owner, and the second output will be the remaining 0.3 BTC “change”, with the owner being Alice herself.
技術的な観点からは、ビットコインのような暗号通貨の台帳は、既存のすべてのビットコインの所有状態からなる「状態」と、状態と取引を受け取り、その結果である新しい状態を出力する「状態遷移関数」が存在する、状態遷移システムとして考えることができる。例えば、標準的な銀行システムでは、状態は貸借対照表であり、取引はAからBにXドルを移動する要求であり、状態遷移関数はAの口座の価値をXドル減らし、Bの口座の価値をXドル増やす。そもそもAの口座がXドル未満であれば、状態遷移関数はエラーを返す。したがって、形式的に定義することができる。
APPLY(S,TX) -> S’ または ERROR
上で定義した銀行システムにおいて
APPLY({ Alice: $50, Bob: $50 }, “send $20 from Alice to Bob”) = { Alice: $30, Bob: $70 }.
しかし
APPLY({ Alice: $50, Bob: $50 }, “send $70 from Alice to Bob”) = ERROR
ビットコインにおける「状態」とは、鋳造され、まだ使用されていないすべてのコイン（厳密には「未使用トランザクション出力」またはUTXO）のコレクションであり、各UTXOには額面および所有者（本質的に暗号公開鍵である20バイトのアドレスによって定義されますfn1） が存在します。取引は1つ以上の入力を含み、各入力は既存のUTXOへの参照と所有者のアドレスに関連付けられた秘密鍵によって生成された暗号署名を含む。また1つ以上の出力を含み、各出力は状態に追加される新しいUTXOを含む。
状態遷移関数APPLY(S,TX) -> S’は、おおよそ次のように定義できる。
TXの各入力に対して。
参照されたUTXOがSにない場合、エラーを返す。
提供された署名がUTXOの所有者と一致しない場合、エラーを返す。
すべての入力UTXOの額面の合計が、すべての出力UTXOの額面の合計より小さい場合、エラーを返す。
すべての入力UTXOを削除し、すべての出力UTXOを追加したSを返す。
前半のステップで取引送信者が存在しないコインを使うことを防ぎ、後半のステップで取引送信者が他人のコインを使うことを防ぎ、後半のステップで価値の保存を強制している。これを支払いに利用するためには、以下のようなプロトコルになる。アリスが11.7BTCをボブに送りたいとする。まず、アリスは自分が所有する利用可能なUTXOのうち、合計が少なくとも11.7BTCになるセットを探します。現実的には、アリスはちょうど11.7BTCを手に入れることはできません。最も小さいものは6+4+2=12とします。彼女はこの3つのインプットと2つのアウトプットを持つトランザクションを作成する。最初の出力は11.7BTCで、ボブのアドレスがその所有者となり、2番目の出力は残りの0.3BTCの「おつり」で、所有者はアリス自身である。
Mining
If we had access to a trustworthy centralized service, this system would be trivial to implement; it could simply be coded exactly as described, using a centralized server’s hard drive to keep track of the state. However, with Bitcoin we are trying to build a decentralized currency system, so we will need to combine the state transaction system with a consensus system in order to ensure that everyone agrees on the order of transactions. Bitcoin’s decentralized consensus process requires nodes in the network to continuously attempt to produce packages of transactions called “blocks”. The network is intended to produce roughly one block every ten minutes, with each block containing a timestamp, a nonce, a reference to (ie. hash of) the previous block and a list of all of the transactions that have taken place since the previous block. Over time, this creates a persistent, ever-growing, “blockchain” that constantly updates to represent the latest state of the Bitcoin ledger.
The algorithm for checking if a block is valid, expressed in this paradigm, is as follows:
Check if the previous block referenced by the block exists and is valid.
Check that the timestamp of the block is greater than that of the previous blockfn2 and less than 2 hours into the future
Check that the proof-of-work on the block is valid.
Let S[0] be the state at the end of the previous block.
Suppose TX is the block’s transaction list with n transactions. For all i in 0…n-1, set S[i+1] = APPLY(S[i],TX[i]) If any application returns an error, exit and return false.
Return true, and register S[n] as the state at the end of this block.
Essentially, each transaction in the block must provide a valid state transition from what was the canonical state before the transaction was executed to some new state. Note that the state is not encoded in the block in any way; it is purely an abstraction to be remembered by the validating node and can only be (securely) computed for any block by starting from the genesis state and sequentially applying every transaction in every block. Additionally, note that the order in which the miner includes transactions into the block matters; if there are two transactions A and B in a block such that B spends a UTXO created by A, then the block will be valid if A comes before B but not otherwise.
The one validity condition present in the above list that is not found in other systems is the requirement for “proof-of-work”. The precise condition is that the double-SHA256 hash of every block, treated as a 256-bit number, must be less than a dynamically adjusted target, which as of the time of this writing is approximately 2187. The purpose of this is to make block creation computationally “hard”, thereby preventing sybil attackers from remaking the entire blockchain in their favor. Because SHA256 is designed to be a completely unpredictable pseudorandom function, the only way to create a valid block is simply trial and error, repeatedly incrementing the nonce and seeing if the new hash matches.
At the current target of ~2187, the network must make an average of ~269 tries before a valid block is found; in general, the target is recalibrated by the network every 2016 blocks so that on average a new block is produced by some node in the network every ten minutes. In order to compensate miners for this computational work, the miner of every block is entitled to include a transaction giving themselves 25 BTC out of nowhere. Additionally, if any transaction has a higher total denomination in its inputs than in its outputs, the difference also goes to the miner as a “transaction fee”. Incidentally, this is also the only mechanism by which BTC are issued; the genesis state contained no coins at all.
In order to better understand the purpose of mining, let us examine what happens in the event of a malicious attacker. Since Bitcoin’s underlying cryptography is known to be secure, the attacker will target the one part of the Bitcoin system that is not protected by cryptography directly: the order of transactions. The attacker’s strategy is simple:
Send 100 BTC to a merchant in exchange for some product (preferably a rapid-delivery digital good)
Wait for the delivery of the product
Produce another transaction sending the same 100 BTC to himself
Try to convince the network that his transaction to himself was the one that came first.
Once step (1) has taken place, after a few minutes some miner will include the transaction in a block, say block number 270000. After about one hour, five more blocks will have been added to the chain after that block, with each of those blocks indirectly pointing to the transaction and thus “confirming” it. At this point, the merchant will accept the payment as finalized and deliver the product; since we are assuming this is a digital good, delivery is instant. Now, the attacker creates another transaction sending the 100 BTC to himself. If the attacker simply releases it into the wild, the transaction will not be processed; miners will attempt to run APPLY(S,TX) and notice that TX consumes a UTXO which is no longer in the state. So instead, the attacker creates a “fork” of the blockchain, starting by mining another version of block 270000 pointing to the same block 269999 as a parent but with the new transaction in place of the old one. Because the block data is different, this requires redoing the proof-of-work. Furthermore, the attacker’s new version of block 270000 has a different hash, so the original blocks 270001 to 270005 do not “point” to it; thus, the original chain and the attacker’s new chain are completely separate. The rule is that in a fork the longest blockchain is taken to be the truth, and so legitimate miners will work on the 270005 chain while the attacker alone is working on the 270000 chain. In order for the attacker to make his blockchain the longest, he would need to have more computational power than the rest of the network combined in order to catch up (hence, “51% attack”).
マイニング
もし信頼できる中央集権的なサービスを利用できるなら、このシステムを実装するのは簡単なことです。しかし、ビットコインでは分散型の通貨システムを構築しようとしているので、取引の順序に全員が同意することを保証するために、状態取引システムと合意システムを組み合わせる必要があるのです。ビットコインの分散型コンセンサスプロセスでは、ネットワーク内のノードが「ブロック」と呼ばれる取引のパッケージを継続的に生成しようとする必要があります。ネットワークはおよそ10分ごとに1つのブロックを生成することを意図しており、各ブロックにはタイムスタンプ、ノンス、前のブロックへの参照（つまりハッシュ）、前のブロック以降に行われたすべてのトランザクションのリストが含まれています。時間の経過とともに、これは永続的で成長し続ける「ブロックチェーン」を作成し、ビットコイン台帳の最新の状態を表すために常に更新されます。
ブロックが有効かどうかをチェックするアルゴリズムは、このパラダイムで表現すると、次のようになる。
ブロックが参照する前のブロックが存在し、有効であるかどうかを確認する。
ブロックのタイムスタンプが前のブロックのタイムスタンプfn2より大きく、かつ2時間以内の未来であることを確認する。
そのブロックのプルーフ・オブ・ワークが有効であることを確認する。
前のブロックの終了時の状態をS[0]とする。
TXはそのブロックの取引リストで、n個の取引があるとする。0…n-1のすべてのiについて、S[i+1] = APPLY(S[i],TX[i]) 何かアプリケーションがエラーを返した場合は、終了してfalseを返します。
真を返し、このブロックの終了時の状態としてS[n]を登録する。
基本的に、ブロック内の各トランザクションは、トランザクションが実行される前の標準的な状態から何らかの新しい状態への有効な状態遷移を提供しなければならない。それは純粋に、検証ノードが記憶する抽象的なものであり、開始状態から開始し、 すべてのブロックのすべてのトランザクションを順次適用することによってのみ、どのブロッ クに対しても（安全に）計算することができることに注意すること。さらに、採掘者がブロックにトランザクションを含める順序が重要であることに注意する。ブロック内に2つのトランザクションAおよびBがあり、BがAによって作成されたUTXOを消費する場合、ブロックはAがBより先に来るなら有効だが、そうでないなら無効となる。
上記の有効性条件のうち、他のシステムにはないものは「プルーフ・オブ・ワーク」の要件である。正確には、256ビットの数値として扱われる各ブロックのダブルSHA256ハッシュが、動的に調整される目標値（本稿執筆時点では約2187）より小さくなければならないという条件である。これは、ブロックの作成を計算上「難しく」することで、シビル攻撃者がブロックチェーン全体を自分たちに有利なように作り変えることを防ぐためです。SHA256は完全に予測不可能な疑似ランダム関数として設計されているため、有効なブロックを作成する唯一の方法は、単にnonceを繰り返し増やし、新しいハッシュが一致するかどうかを確認する試行錯誤だけです。
現在の目標値 ~2187 では、有効なブロックが見つかるまでに平均 ~269 回試行しなければならない。一般に、目標値はネットワークによって 2016 ブロックごとに再調整されるため、平均すると 10 分ごとにネットワーク内のいくつかのノードによって新しいブロックが生成されることになる。この計算作業に対する採掘者の報酬として、すべてのブロックの採掘者は、どこからともなく自分自身に25BTCを与える取引を含む権利がある。さらに、入力された取引額の合計が出力された取引額より大きい場合、その差額も「取引手数料」として採掘者に支払われる。ちなみに、BTCが発行される仕組みもこれだけで、創世記にはコインは全く入っていない。
マイニングの目的をより深く理解するために、悪意のある攻撃者がいた場合にどうなるかを検証してみよう。ビットコインの暗号は安全であることが知られているので、攻撃者は暗号で直接保護されていないビットコインのシステムの1つの部分、つまり取引の順番をターゲットにします。攻撃者の戦略は単純です。
商品（できれば速配のデジタルグッズ）と引き換えに100BTCを商人に送る。
商品の配送を待つ
同じ100BTCを自分宛に送る別のトランザクションを生成する。
自分への取引が先であったことをネットワークに納得させようとする。
ステップ(1)が行われると、数分後にどこかの採掘者がその取引をブロック（例えばブロック番号270000）に入れる。約1時間後、そのブロックの後にさらに5つのブロックがチェーンに追加され、それらのブロックはそれぞれ間接的にその取引を指し示し、その取引を「確認」している。この時点で、販売者は支払いが確定したことを受け入れ、商品を配送する。これはデジタル商品であると仮定しているので、配送は即座に行われる。ここで、攻撃者は別の取引を行い、100BTCを自分自身に送金する。採掘者がAPPLY(S,TX)を実行しようとすると、TXがもはやその状態にはないUTXOを消費していることに気付く。そこで攻撃者はブロックチェーンの「フォーク」を作成し、同じブロック269999を親とするブロック270000の別バージョンを採掘することから始めるが、古いトランザクションの代わりに新しいトランザクションが含まれる。ブロックデータが異なるため、これにはプルーフ・オブ・ワークをやり直す必要がある。さらに、攻撃者の新バージョンのブロック270000はハッシュが異なるため、元のブロック270001から270005はそれを「指して」いない。したがって、元のチェーンと攻撃者の新しいチェーンは完全に別物である。フォークでは最も長いブロックチェーンが真実とみなされるため、正規の採掘者は270005のチェーンで作業し、攻撃者だけが270000のチェーンで作業するというルールになっている。攻撃者が自分のブロックチェーンを最長にするためには、ネットワークの残りの部分を合わせたよりも多くの計算能力を持たないと追いつけない（そのため「51%攻撃」と呼ばれる）。
Merkle Trees
Left: it suffices to present only a small number of nodes in a Merkle tree to give a proof of the validity of a branch.
Right: any attempt to change any part of the Merkle tree will eventually lead to an inconsistency somewhere up the chain.
An important scalability feature of Bitcoin is that the block is stored in a multi-level data structure. The “hash” of a block is actually only the hash of the block header, a roughly 200-byte piece of data that contains the timestamp, nonce, previous block hash and the root hash of a data structure called the Merkle tree storing all transactions in the block. A Merkle tree is a type of binary tree, composed of a set of nodes with a large number of leaf nodes at the bottom of the tree containing the underlying data, a set of intermediate nodes where each node is the hash of its two children, and finally a single root node, also formed from the hash of its two children, representing the “top” of the tree. The purpose of the Merkle tree is to allow the data in a block to be delivered piecemeal: a node can download only the header of a block from one source, the small part of the tree relevant to them from another source, and still be assured that all of the data is correct. The reason why this works is that hashes propagate upward: if a malicious user attempts to swap in a fake transaction into the bottom of a Merkle tree, this change will cause a change in the node above, and then a change in the node above that, finally changing the root of the tree and therefore the hash of the block, causing the protocol to register it as a completely different block (almost certainly with an invalid proof-of-work).
The Merkle tree protocol is arguably essential to long-term sustainability. A “full node” in the Bitcoin network, one that stores and processes the entirety of every block, takes up about 15 GB of disk space in the Bitcoin network as of April 2014, and is growing by over a gigabyte per month. Currently, this is viable for some desktop computers and not phones, and later on in the future only businesses and hobbyists will be able to participate. A protocol known as “simplified payment verification” (SPV) allows for another class of nodes to exist, called “light nodes”, which download the block headers, verify the proof-of-work on the block headers, and then download only the “branches” associated with transactions that are relevant to them. This allows light nodes to determine with a strong guarantee of security what the status of any Bitcoin transaction, and their current balance, is while downloading only a very small portion of the entire blockchain.
Alternative Blockchain Applications
The idea of taking the underlying blockchain idea and applying it to other concepts also has a long history. In 2005, Nick Szabo came out with the concept of “secure property titles with owner authority”, a document describing how “new advances in replicated database technology” will allow for a blockchain-based system for storing a registry of who owns what land, creating an elaborate framework including concepts such as homesteading, adverse possession and Georgian land tax. However, there was unfortunately no effective replicated database system available at the time, and so the protocol was never implemented in practice. After 2009, however, once Bitcoin’s decentralized consensus was developed a number of alternative applications rapidly began to emerge.
Namecoin – created in 2010, Namecoin is best described as a decentralized name registration database. In decentralized protocols like Tor, Bitcoin and BitMessage, there needs to be some way of identifying accounts so that other people can interact with them, but in all existing solutions the only kind of identifier available is a pseudorandom hash like 1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy. Ideally, one would like to be able to have an account with a name like “george”. However, the problem is that if one person can create an account named “george” then someone else can use the same process to register “george” for themselves as well and impersonate them. The only solution is a first-to-file paradigm, where the first registerer succeeds and the second fails – a problem perfectly suited for the Bitcoin consensus protocol. Namecoin is the oldest, and most successful, implementation of a name registration system using such an idea.
Colored coins – the purpose of colored coins is to serve as a protocol to allow people to create their own digital currencies – or, in the important trivial case of a currency with one unit, digital tokens, on the Bitcoin blockchain. In the colored coins protocol, one “issues” a new currency by publicly assigning a color to a specific Bitcoin UTXO, and the protocol recursively defines the color of other UTXO to be the same as the color of the inputs that the transaction creating them spent (some special rules apply in the case of mixed-color inputs). This allows users to maintain wallets containing only UTXO of a specific color and send them around much like regular bitcoins, backtracking through the blockchain to determine the color of any UTXO that they receive.
Metacoins – the idea behind a metacoin is to have a protocol that lives on top of Bitcoin, using Bitcoin transactions to store metacoin transactions but having a different state transition function, APPLY’. Because the metacoin protocol cannot prevent invalid metacoin transactions from appearing in the Bitcoin blockchain, a rule is added that if APPLY'(S,TX) returns an error, the protocol defaults to APPLY'(S,TX) = S. This provides an easy mechanism for creating an arbitrary cryptocurrency protocol, potentially with advanced features that cannot be implemented inside of Bitcoin itself, but with a very low development cost since the complexities of mining and networking are already handled by the Bitcoin protocol. Metacoins have been used to implement some classes of financial contracts, name registration and decentralized exchange.
Thus, in general, there are two approaches toward building a consensus protocol: building an independent network, and building a protocol on top of Bitcoin. The former approach, while reasonably successful in the case of applications like Namecoin, is difficult to implement; each individual implementation needs to bootstrap an independent blockchain, as well as building and testing all of the necessary state transition and networking code. Additionally, we predict that the set of applications for decentralized consensus technology will follow a power law distribution where the vast majority of applications would be too small to warrant their own blockchain, and we note that there exist large classes of decentralized applications, particularly decentralized autonomous organizations, that need to interact with each other.
The Bitcoin-based approach, on the other hand, has the flaw that it does not inherit the simplified payment verification features of Bitcoin. SPV works for Bitcoin because it can use blockchain depth as a proxy for validity; at some point, once the ancestors of a transaction go far enough back, it is safe to say that they were legitimately part of the state. Blockchain-based meta-protocols, on the other hand, cannot force the blockchain not to include transactions that are not valid within the context of their own protocols. Hence, a fully secure SPV meta-protocol implementation would need to backward scan all the way to the beginning of the Bitcoin blockchain to determine whether or not certain transactions are valid. Currently, all “light” implementations of Bitcoin-based meta-protocols rely on a trusted server to provide the data, arguably a highly suboptimal result especially when one of the primary purposes of a cryptocurrency is to eliminate the need for trust
メルクルの木
左図：ある枝の正当性を証明するためには、メルクル木のごく少数のノードを提示するだけで十分である。
右：メルクル木のどこかを変更しようとすると、最終的にはチェーンのどこかで矛盾が発生する。
ビットコインの重要なスケーラビリティの特徴は、ブロックが多階層のデータ構造に格納されていることです。ブロックの「ハッシュ」は、実際にはブロックヘッダのハッシュのみで、タイムスタンプ、nonce、前のブロックハッシュ、ブロック内の全取引を格納するMerkleツリーと呼ばれるデータ構造のルートハッシュを含む約200バイトのデータである。マークルツリーは2分木の一種で、基礎となるデータを含むツリーの下部にある多数のリーフノード、各ノードがその2つの子のハッシュである中間ノード、そして最後にツリーの「トップ」を表す、やはり2つの子のハッシュから形成される単一のルートノードから構成されている。ノードがあるソースからブロックのヘッダーのみをダウンロードし、別のソースから自分に関連するツリーの小さな部分をダウンロードしても、すべてのデータが正しいことを保証することができるのです。悪意のあるユーザーが偽のトランザクションをMerkleツリーの一番下に入れ替えようとした場合、この変更が上のノードに影響を与え、さらにその上のノードにも影響を与え、最終的にツリーのルートとブロックのハッシュを変更し、プロトコルに全く別のブロック（ほぼ確実に不正なPoW）として登録させることになります。
メルクルツリープロトコルは、長期的な持続可能性にとって間違いなく不可欠なものである。ビットコインネットワークの「フルノード」、つまりすべてのブロックの全体を保存し処理するノードが、2014年4月時点でビットコインネットワークのディスク領域を約15GB占有し、毎月1GB以上増加している。現在は、一部のデスクトップパソコンで実行可能で、携帯電話では実行できず、将来的には企業や趣味の人だけが参加できるようになる予定です。SPV（Simplified Payment Verification）」と呼ばれるプロトコルにより、「ライトノード」と呼ばれる別のクラスのノードが存在し、ブロックヘッダをダウンロードし、ブロックヘッダ上のプルーフオブワークを検証し、自分に関係のある取引に関連する「ブランチ」だけをダウンロードすることができます。これによりライトノードは、ブロックチェーン全体のごく一部をダウンロードしながら、あらゆるビットコイン取引の状況や現在の残高を、安全性を強く保証して判断することができます。
代替ブロックチェーン・アプリケーション
ブロックチェーンの根底にあるアイデアを他の概念に応用するという考え方も、長い歴史を持っています。2005年、Nick Szaboは「所有者権限を持つ安全な不動産タイトル」というコンセプトを打ち出し、「複製データベース技術の新しい進歩」により、誰がどの土地を所有しているかのレジストリを保存するブロックチェーンベースのシステムを実現することを説明した文書で、ホームステディング、不利益所有、グルジア土地税といった概念を含む精巧な枠組みを作成しました。しかし、当時は残念ながら有効な複製データベースシステムがなかったため、このプロトコルが実際に実装されることはなかった。しかし、2009年以降、ビットコインの分散型コンセンサスが整備されると、多くの代替アプリケーションが急速に出現し始めた。
Namecoin – 2010年に作られたNamecoinは、分散型名前登録データベースとして最もよく表現されています。Tor、Bitcoin、BitMessageなどの分散型プロトコルでは、他の人々がアカウントとやり取りできるように、アカウントを識別する何らかの方法が必要です。しかし、既存のすべてのソリューションでは、利用できる識別子は1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWyなどの疑似ランダムハッシュだけです。 理想的には、「ジョージ」という名前のアカウントを持っていたいところです。しかし、問題は、ある人が「george」という名前のアカウントを作ることができれば、他の人が同じプロセスで自分も「george」を登録し、なりすますことができることです。唯一の解決策は、最初の登録者が成功し、2番目の登録者が失敗するという、first-to-fileパラダイムである。この問題は、ビットコインのコンセンサスプロトコルに完全に適合している。Namecoinは、このようなアイデアを使用した名前登録システムの最古の実装であり、最も成功しています。
カラーコイン – カラーコインの目的は、人々がビットコインブロックチェーン上で独自のデジタル通貨、または1単位の通貨という重要な些細なケースでは、デジタルトークンを作成できるようにするためのプロトコルとして機能することである。カラーコインのプロトコルでは、特定のビットコインUTXOに色を公的に割り当てることで新しい通貨を「発行」し、プロトコルは再帰的に他のUTXOの色を、それらを作成した取引が費やした入力の色と同じであると定義します（色が混在する入力の場合は、いくつかの特別なルールが適用されます）。これにより、ユーザーは特定の色のUTXOだけを入れたウォレットを維持し、通常のビットコインと同様に、受け取ったUTXOの色を決定するためにブロックチェーンをバックトラックしながら、それらを送信することができます。
メタコイン – メタコインの背後にあるアイデアは、ビットコインの上に住むプロトコルを持つことです。メタコインのトランザクションを格納するためにビットコインのトランザクションを使用しますが、異なる状態遷移関数、APPLYを持ちます。メタコインプロトコルでは、無効なメタコイン取引がビットコインのブロックチェーンに現れるのを防ぐことができないため、APPLY'(S,TX)がエラーを返した場合、APPLY'(S,TX)=Sをデフォルトとするルールを追加します。これにより、任意の暗号通貨プロトコルを簡単に作成する仕組みとなり、ビットコイン自体の内部に実装できない先進機能を潜在させ、かつマイニングやネットワークに関する複雑性は既にビットコインが担当しているので非常に低い開発コストとなることが期待されます。メタコインは、いくつかのクラスの金融契約、名前登録、分散型交換を実装するために使用されています。
このように、コンセンサスプロトコルの構築には、一般に、独立したネットワークを構築する方法と、ビットコインの上にプロトコルを構築する方法の2つのアプローチがある。前者は、Namecoinのようなアプリケーションではそれなりに成功していますが、実装が難しく、個々の実装では独立したブロックチェーンをブートストラップし、必要な状態遷移とネットワーキングのコードをすべて構築してテストする必要があります。さらに、分散型コンセンサス技術のアプリケーションはべき乗分布に従うと予想され、大半のアプリケーションは独自のブロックチェーンを保証するには小さすぎると考えられます。
一方、Bitcoinベースのアプローチは、Bitcoinの簡略化された支払い検証機能を継承していないという欠点があります。SPVがビットコインに有効なのは、ブロックチェーンの深さを有効性の代理として使えるからです。ある時点で、取引の祖先が十分に遡れば、合法的に国家の一員であったと言ってもよいのです。一方、ブロックチェーンに基づくメタプロトコルでは、自身のプロトコルのコンテキスト内で有効でない取引をブロックチェーンに含めないよう強制することはできません。したがって、完全に安全なSPVメタプロトコル実装は、特定の取引が有効かどうかを判断するために、ビットコインブロックチェーンの先頭まで後方スキャンする必要があります。現在、ビットコインベースのメタプロトコルのすべての「軽い」実装は、データを提供するために信頼できるサーバーに依存しており、特に暗号通貨の主要目的の1つが信頼の必要性を排除することである場合、間違いなく非常に最適とは言えない結果となっています。
Scripting
Even without any extensions, the Bitcoin protocol actually does facilitate a weak version of a concept of “smart contracts”. UTXO in Bitcoin can be owned not just by a public key, but also by a more complicated script expressed in a simple stack-based programming language. In this paradigm, a transaction spending that UTXO must provide data that satisfies the script. Indeed, even the basic public key ownership mechanism is implemented via a script: the script takes an elliptic curve signature as input, verifies it against the transaction and the address that owns the UTXO, and returns 1 if the verification is successful and 0 otherwise. Other, more complicated, scripts exist for various additional use cases. For example, one can construct a script that requires signatures from two out of a given three private keys to validate (“multisig”), a setup useful for corporate accounts, secure savings accounts and some merchant escrow situations. Scripts can also be used to pay bounties for solutions to computational problems, and one can even construct a script that says something like “this Bitcoin UTXO is yours if you can provide an SPV proof that you sent a Dogecoin transaction of this denomination to me”, essentially allowing decentralized cross-cryptocurrency exchange.
However, the scripting language as implemented in Bitcoin has several important limitations:
Lack of Turing-completeness – that is to say, while there is a large subset of computation that the Bitcoin scripting language supports, it does not nearly support everything. The main category that is missing is loops. This is done to avoid infinite loops during transaction verification; theoretically it is a surmountable obstacle for script programmers, since any loop can be simulated by simply repeating the underlying code many times with an if statement, but it does lead to scripts that are very space-inefficient. For example, implementing an alternative elliptic curve signature algorithm would likely require 256 repeated multiplication rounds all individually included in the code.
Value-blindness – there is no way for a UTXO script to provide fine-grained control over the amount that can be withdrawn. For example, one powerful use case of an oracle contract would be a hedging contract, where A and B put in $1000 worth of BTC and after 30 days the script sends $1000 worth of BTC to A and the rest to B. This would require an oracle to determine the value of 1 BTC in USD, but even then it is a massive improvement in terms of trust and infrastructure requirement over the fully centralized solutions that are available now. However, because UTXO are all-or-nothing, the only way to achieve this is through the very inefficient hack of having many UTXO of varying denominations (eg. one UTXO of 2k for every k up to 30) and having O pick which UTXO to send to A and which to B.
Lack of state – UTXO can either be spent or unspent; there is no opportunity for multi-stage contracts or scripts which keep any other internal state beyond that. This makes it hard to make multi-stage options contracts, decentralized exchange offers or two-stage cryptographic commitment protocols (necessary for secure computational bounties). It also means that UTXO can only be used to build simple, one-off contracts and not more complex “stateful” contracts such as decentralized organizations, and makes meta-protocols difficult to implement. Binary state combined with value-blindness also mean that another important application, withdrawal limits, is impossible.
Blockchain-blindness – UTXO are blind to blockchain data such as the nonce, the timestamp and previous block hash. This severely limits applications in gambling, and several other categories, by depriving the scripting language of a potentially valuable source of randomness.
Thus, we see three approaches to building advanced applications on top of cryptocurrency: building a new blockchain, using scripting on top of Bitcoin, and building a meta-protocol on top of Bitcoin. Building a new blockchain allows for unlimited freedom in building a feature set, but at the cost of development time, bootstrapping effort and security. Using scripting is easy to implement and standardize, but is very limited in its capabilities, and meta-protocols, while easy, suffer from faults in scalability. With Ethereum, we intend to build an alternative framework that provides even larger gains in ease of development as well as even stronger light client properties, while at the same time allowing applications to share an economic environment and blockchain security
スクリプティング
拡張機能がなくても、ビットコインのプロトコルは実際に「スマートコントラクト」のコンセプトの弱いバージョンを促進します。ビットコインのUTXOは、公開鍵だけでなく、単純なスタックベースのプログラミング言語で表現されたより複雑なスクリプトによっても所有することができる。このパラダイムでは、UTXOを使うトランザクションは、スクリプトを満たすデータを提供しなければならない。実際、基本的な公開鍵所有メカニズムでさえもスクリプトで実装されている。スクリプトは楕円曲線署名を入力として受け取り、それをトランザクションとUTXOを所有するアドレスに対して検証し、検証が成功すれば1を返し、そうでなければ0を返す。その他にも、さまざまなユースケースに対応する、より複雑なスクリプトが存在する。例えば、検証のために3つの秘密鍵のうち2つの署名を必要とするスクリプトを作成する ことができる(「multisig」)。これは企業口座、安全な預金口座、一部の商取引エスクローの 状況で有用な設定である。スクリプトはまた、計算問題の解決に対する報奨金を支払うために使用することもでき、「この額面のDogecoinトランザクションを私に送ったというSPV証明を提供できれば、このBitcoin UTXOはあなたのものです」というようなスクリプトも作成でき、本質的に分散型の暗号通貨間交換が可能である。
しかし、ビットコインに実装されているスクリプト言語には、いくつかの重要な制約があります。
チューリング完全性の欠如 – つまり、ビットコインのスクリプト言語がサポートする計算の大きなサブセットがある一方で、ほぼすべてをサポートしているわけではありません。欠けている主なカテゴリはループです。理論的には、スクリプトプログラマーにとって克服可能な障害です。なぜなら、どのようなループも、if文を使って基本コードを何度も繰り返すだけでシミュレートできるからです。例えば、楕円曲線署名の代替アルゴリズムを実装する場合、コードに含まれるすべての乗算ラウンドを個別に256回繰り返す必要があると思われます。
価値の盲点 – UTXOスクリプトは、引き出し可能な金額を細かく制御する方法がない。例えば、オラクル契約の強力な使用例として、AとBが1000ドル相当のBTCを投入し、30日後にスクリプトが1000ドル相当のBTCをAに、残りをBに送るというヘッジ契約があります。これは、米ドル建て1BTCの価値を決定するオラクルが必要ですが、それでも現在利用できる完全集中型のソリューションよりも、信頼性とインフラ要件の点で大きな改善となります。しかし、UTXOはオール・オア・ナッシングなので、これを実現するには、様々な額面のUTXOを多数用意し（例えば、30までのkごとに2kのUTXOを一つ）、どのUTXOをAに送り、どのBに送るかをOが選択するという非常に非効率な方法しかないのです。
ステートの欠如 – UTXOは使われるか使われないかのどちらかであり、多段契約やそれ以上の内部ステートを保持するスクリプトの機会はありません。このため、多段階のオプション契約、分散型取引所のオファー、2段階の暗号コミットメントプロトコル（安全な計算バウンティに必要）を作成することは困難である。また、UTXOは単純な一回限りの契約しか作れず、分散型組織のようなより複雑な「ステートフル」契約は作れず、メタ・プロトコルの実装が困難であることも意味している。バイナリステートとバリューブラインドネスの組み合わせは、もう一つの重要なアプリケーションである引き出し制限が不可能であることも意味しています。
ブロックチェーンブラインドネス – UTXOは、nonce、タイムスタンプ、以前のブロックハッシュなどのブロックチェーンデータに対して盲目です。これは、スクリプト言語から潜在的に貴重なランダム性の源を奪うことによって、ギャンブルや他のいくつかのカテゴリでのアプリケーションを厳しく制限します。
このように、暗号通貨の上に高度なアプリケーションを構築するには、新しいブロックチェーンを構築する、ビットコインの上にスクリプトを使用する、ビットコインの上にメタプロトコルを構築する、という3つのアプローチがあります。新しいブロックチェーンを構築することで、機能セットを無制限に構築できますが、開発時間、ブートストラップの労力、セキュリティが犠牲となります。スクリプトは実装や標準化が容易ですが、その機能は非常に限定的であり、メタプロトコルも容易ではありますが、スケーラビリティに欠ける欠点があります。イーサリアムでは、開発容易性をさらに高め、ライトクライアントの特性をさらに強化し、同時にアプリケーションが経済環境とブロックチェーンのセキュリティを共有できるような代替フレームワークを構築する予定です。
＜参考記事＞
