次世代スマート契約と分散アプリケーション・プラットフォーム

A Next-Generation Smart Contract and Decentralized Application Platform
次世代スマート契約と分散アプリケーション・プラットフォーム
White Paper
白書
Jump to bottom
頁の最後までジャンプ
James Ray edited this page 20 days ago · 174 revisions
ジェームズ・レイは20日前にこの頁を編集－174修正
An introductory paper to Ethereum, introduced before launch, which is maintained.
イーサリアム紹介論文、立ち上げ前に紹介され、補修中。
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.
２００９年のサトシ・ナカモトのビットコインの開発は貨幣における急進的な開発としてしばしば歓迎されてきていますが、同時に裏打ちのない、あるいは本質的な価値を持たないデジタル資産の最初の例であり、中央集権の発行者や管理者はありません。 しかしながら、もう１つのビットコイン実験の － 多分いっそう重要 － 部分は、分散合意のツールとして基礎をなしているブロックチェーン技術です。そして関心は急速に 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).
共通に引用されるにブロックチェーン技術は、注文製の通貨と金融契約書（着色されたコイン）を表すブロックチェーンのデジタル資産や、基礎をなしている物理装置（スマート財産）の所有権、ドメイン名のような代替可能でない資産（Namecoin）、同様に、一片のコード実装の任意の規則（スマートな契約）あるいはブロックチェーンベースの分散した自治組織（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.
イーサリアムが供給するつもりであるものは、ユーザーがただ、少数のコード行でロジックを書き上げることによって、我々がまだ想像しなかった多くの他のものと同様、上記のシステムのいずれでも作ることを可能にする任意の公式の推移関数をコード化するために使うことができる「契約」を作るために使われることができる組み込みの完全なチューリング - 完全なプログラム言語があるブロックチェーンです。
Contents
目次
• Introduction to Bitcoin and Existing Concepts
ビットコインと既存の概念の紹介
◦ History
歴史
◦ Bitcoin As A State Transition System
状態遷移システムとしてのビットコイン
◦ Mining
採鉱
◦ Merkle Trees
マークルツリー
◦ Alternative Blockchain Applications
代替ブロックチェーンアプリケーション
◦ Scripting
スクリプテイング
• Ethereum
イーサリアム
◦ Philosophy
哲学
◦ Ethereum Accounts
イーサリアムアカウント
◦ Messages and Transactions
メッセージと取引
◦ Messages
メッセージ
◦ Ethereum State Transition Function
イーサリアム状態遷移関数
◦ Code Execution
コード実行
◦ Blockchain and Mining
ブロックチェーンと採鉱
• Applications
アプリケーション
◦ Financial derivatives and Stable-Value Currencies
金融派生商品と安定した価値の通貨
◦ Identity and Reputation Systems
身元と評判システム
◦ Decentralized File Storage
分散ファイル記憶装置
◦ Decentralized Autonomous Organizations
分散自治組織
◦ Further Applications
さらなるアプリケーション
• Miscellanea And Concerns
その他と関係
◦ Modified GHOST Implementation
モディファイドGHOST実装
◦ Fees
料金
◦ Computation And Turing-Completeness
電算とチューリング-完全性
◦ Currency And Issuance
通貨と発行
◦ Mining Centralization
採鉱集中化
◦ Scalability
拡大縮小可能性
• Conclusion
結論
• Notes and Further Reading
メモとさらなる読み物
◦ Notes
メモ
◦ Further Reading
さらなる読み物

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.
分散デジタル通貨のコンセプトは、財産レジスツリーのような代わりのアプリケーションと同様、何十年間もあり今に至ります。1980年代と1990年代の匿名の電子通貨プロトコル、主として Chaumian盲検化として知られている暗号の根源に依存し、高度のプライバシイを通貨に提供しましたが、しかしプロトコルは主として中央集権仲裁人に対する彼らの信頼故に牽引力を獲得し損ねました。
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.
1998年に、ウェイ ダイのｂ金銭は、分散コンセンサスと同様、コンピュータパズルを解くことを通じて、金銭を作成するという考えを紹介する最初のプロポーザルになりましたが、しかし、分散コンセンサスがどのように実際に実装できるだろうかについて、そのプロポーザルは詳細が不十分でした。
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.
2005年に、ハル・フィニーは再利用可能な仕事の証明の概念、アダムバックの計算上難しい Hashcash パズルと共に暗号通貨の概念を作るために、ｂ金銭からアイデアを使うシステムを紹介するが、バックエンドとして信頼できる演算に依存することによって、もう一度理想に及びませんでした。
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".
2009年に、分散貨幣が、サトシ・ナカモトによって初めて実際は実装されました。それは、「仕事の証明」として知られている誰がコインを所有するかを記録・追跡するための合意アルゴリズムで公開鍵暗号方式を通して所有権を管理するための確立された根源を結合します。
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.
仕事の証明の背後のメカニズムはその空間で突破口でした。何故なら、それが同時に２つの問題を解決したからです。第一に、それは、単純な、そして適度に有効な合意アルゴリズムを提供しました。そして、回線網のノードがビットコイン元帳の状態への一組の規準的な更新に同意することを可能にしました。第二に、それは、自由な参加登録者が合意プロセスに入るのを可能にするメカニズムを提供しました。そして、誰が意見一致に影響を与えることができるか決める政治問題を解決して、他方同時に sybil攻撃を防ぎます。
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
それは、経済のバリヤで、特定のリストに関してユニークな実体として登録される必要のような、参加に正式のバリヤを代用することによって、これを行います － 合意投票処理での一つのノードの重みは直接ノードがもたらす計算能力に比例しています。 その時から、代わりのアプローチは、計算リソースではなく、その通貨保有に比例しているとして、ノードの重みを計算して、掛け金の証明と呼ばれて提案されました； ２つのアプローチの相対的な長所の議論はこの論文の有効範囲を越えていますが、しかし両方のアプローチがそうであり得ることは指摘されるべきです。
Here is a blog post from Vitalik Buterin, the founder of Ethereum, on Ethereum pre-history. Here is another blog post with more history.
ここにイーサリアムの創設者、Vitalik Buterin氏からの イーサリアム先史についてのブログの投稿があります。 ここにもう１つ別のさらなる歴史を持ったブログ投稿があります。
Bitcoin As A State Transition System
状態遷移システムとしてのビットコイン
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:
技術的見地から、 ビットコインのような暗号通貨の元帳は状態遷移システムとして、考えられ、そこにはすべての既存のビットコインの所有権状況と状態や遷移を取り、その結果である新しい状態を出力する「状態遷移関数」から成る「状態」があります。 標準的な銀行システムで、例えば、その状態は貸借対照表で、取引きは $X をＡからＢに動かすために要求で、そして状態遷移関数は A のアカウントにおける価値をＸドル減らして、そしてXドルだけＢのアカウントにおける価値を増やします。 もし A のアカウントが最初にＸドル以下しかないなら、状態遷移関数はエラーを返します。それ故、それは公式に下記のように定義することができます：
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 mined 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 keyfn. 1). 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.
ビットコインの「状態」はすべてのコイン（技術的に、「費やされていない取引きアウトプット」あるいは UTXO）のコレクションで、それは、採掘され、そして、まだ使われなかったものです。それぞれの UTXO が（本質的に暗号の公共のkeyfn. 1である20-バイト・アドレスによって定義された.）通貨単位と所有者を持っています。 取引きは、１つ以上のインプットを含んでおり、各インプットは、既存の UTXO と、所有者のアドレスと結び付けられる秘密キーによって作られる暗号の署名の照会先を含んでいて、さらに一つ以上のアウトプットを含んでいて、そのアウトプットは、状態に加えられる新しい UT XOを含んでいます。
The state transition function APPLY(S,TX) -> S' can be defined roughly as follows:
状態遷移関数 APPLY （Ｓ、 TX） -> ｓ’は次のようにざっと定義することができます：
1. For each input in TX :
それぞれの入力過程で TX で：
◦ If the referenced UTXO is not in S , return an error.
もし参照された UTXO がＳでないなら、エラーを返えす。
◦ If the provided signature does not match the owner of the UTXO, return an error.
もし提供された署名が UTXO の所有者に合致しないなら、エラーを返えす。
2. 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.
もしすべての入力 UTXO の通貨単位の合計がすべての出力 UTXO の通貨単位の合計未満であるなら、エラーを返してください。
3. Return S' with all input UTXO removed and all output UTXO added.
リターン‥S'…すべての入力 UTXO は削除され、すべての出力 UTXO は追加される。
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.
第一ステップの前半は取引き送信者が存在しないコインを使うのを阻止し、第一ステップの後半は取引き送信者が他の人々のコインを使うのを阻止します。そして第二ののステップは価値の保護を実施します。 支払いのためにこれを使うために、通信プロトコールは次の通りです。 アリスがボブに１１.７BTCを送ることを望むと考えてください。 最初に、アリスは最高少なくとも１１.７BTCを合計する彼女が所有する利用可能な UTXO のセットを探すでしょう。 現実的に、アリスは正確に１１.７BTCを手に入れることが可能ではないでしょう；彼女が受けとることができる最も小さいものが６ ＋ ４ ＋ ２ ＝ １２であるとしよう。
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.
彼女はそれから、それらの３つのインプットと２つのアウトプットで取引きを創造します。 最初の出力はボブのアドレスでその所有者として11.7BTCでしょう、そして２番目の出力は、所有者がアリス自身であるという状態で、残っている0.3 BTCの「お釣り」となるでしょう。
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 transition 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:
ブロックが妥当であるかどうか調べるためのアルゴリズムは、このパラダイムで表明されて、次の通りです：
1. Check if the previous block referenced by the block exists and is valid.
ブロックによって参照された前のブロックが存在して、そして妥当であるかどうか調べること。
2. Check that the timestamp of the block is greater than that of the previous blockfn. 2 and less than 2 hours into the future
ブロックのタイムスタンプが前の ブロックfn. 2のそれより大きいことと将来に向けて２時間未満であるか調べること。
3. Check that the proof of work on the block is valid.
ブロック上の仕事の証明が妥当であることを調べること。
4. Let S[0] be the state at the end of the previous block.
S[0]が前のブロックの終わりの状態であること。
5. Suppose TX is the block's transaction list with n transactions. For all i in , set S[i+1] = APPLY(S[i],TX[i]) If any application returns an error, exit and return false.
TX がｎ個の取引を持つブロックの取引きリストであるとしよう。0...n-1の すべてのiために、S[i+1] = APPLY(S[i],TX[i])で、もしアプリケーションがエラーを返すなら、終了して、そして偽を返すこと。
6. Return true, and register S[n] as the state at the end of this block.
真を返して、そしてこのブロックの終わりの状態としてにS[n]を登録すること。
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.
本質的に、ブロックでのそれぞれの取引きが、取引きが実行される前に、規準的な状態であったものから若干の新しい状態まで妥当な状態遷移を提供しなくてはなりません。 状態がどんな面にしてもブロックにコード化されないことに注意を払ってください； それは純粋に妥当性を検査しているノードによって覚えていられる抽象概念であって、そしてただ、起源状態から始めて、そしてすべてのブロックで連続的にすべての取引きに応用することによって、どんなブロックででも（安全に）計算することができるだけです。 さらに、鉱夫がブロックに取引を含む順番が重要であることに注意を払ってください； もし、ブロックにＢがＡによって作成された UTXO を費やすような２つの取引ＡとＢがあるなら、ブロックは妥当でしょう。もしＡがＢの前に来るなら、そうではないでしょう。
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.
他のシステムに見いだされない上記リストが上存在している１つの妥当性条件は「仕事の証明」ための必要条件である。その 正確な条件はすべてのブロックのダブル - SHA256 ハッシュが、256ビットの数として扱われて、ダイナミックに調整されたターゲット未満でなければならず、それはこの執筆の時点でがおよそ２１８７です。 これの目的は、それによって sybil 攻撃者が（彼・それ）らの是認でブロックチェーン全体を作り直すのを阻止して、ブロック創出を計算上「難しくする」ことです。 SHA256 が完全に予想できない擬似ランダム関数であるよう設計されるから、妥当なブロックを作る唯一の方法は、ただ試行錯誤で、繰り返し乱数を増加させて、そして新しいハッシュがマッチするかどうか見ています。
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 12.5 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.
~２１８７の現在のターゲットで、その回線網は、正当なブロックが見いだされる前に、平均~２６９の試みをしなくてはなりません； 一般的に、平均して新しいブロックが１０分ごとに回線網の若干のノードによって生産されるように、ターゲットは２０１６ブロックごとに回線網によって再調整されます。 この計算作業に対して鉱夫に補償するために、すべてのブロックの鉱夫はどこからともなく彼ら自身に１２.５BTC を与える取引きを含む権利を与えられています。 さらに、もしいかなる取引きもそのアウトプットよりそのインプットでより高い貨幣単位の合計を持っているなら、その相違は「取引手数料」として同じく鉱夫に行きます。 ついでに、これは同じく（それによって）BTCが発行される唯一のメカニズムです。；起源状態はまったくコインを含みませんでした。
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:
もっと良く採鉱の目的を理解するために、悪意がある攻撃者のイベントでは何が起きるか吟味しましょう。 ビットコインの基礎をなす暗号が安全であることが知られていますから、攻撃者は直接暗号によって保護されていないビットコインシステムの１つの部分に目標を定めるでしょう：それはトランザクションのオーダーです。 攻撃者の戦略は下記の通り単純です：

1. Send 100 BTC to a merchant in exchange for some product (preferably a rapid-delivery digital good)
若干の製品（なるべく急配信のデジタル商品）と引き換えに商人に100 BTCを送くる
2. Wait for the delivery of the product
製品の配信を待つ
3. Produce another transaction sending the same 100 BTC to himself
彼自身に同じ100 BTCを送って別の取引きを生産する
4. 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 270. 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 270 pointing to the same block 269 as a parent but with the new transaction in place of the old one.
ひとたびステップ（１）が起きたならば、数分の後に、いずれかの鉱夫がブロックに取引きを含めるでしょう、つまりブロック番号270と。 およそ１時間後、さらに５ブロックがそのブロック後にブロックチェーンに加えられてしまっているでしょう。それらのブロックのそれぞれが間接的に取引きを示して、そしてそれでそれを「確認する」ことになります。 この時点で、完結したとして、商人は支払いを受け入れて、商品を配信するでしょう；我々がこれがデジタル商品であると想定していますから、配信は即座です。 今、攻撃者は彼自身に100 BTCを送ってもう１つの取引きを作り出しします。 もし攻撃者がただそれを荒野に放すなら、取引きは処理されないでしょう；鉱夫がAPPLY(S,TX)の実行を試みて、そして TX がもう状態にない UTXO を消費することに気が付くでしょう。 それでその代わりに、攻撃者は、ブロックチェーンについて「フォーク」を作ります。親として同じブロック269を指し示しているブロック270のもう１つのバージョンを採鉱することによって、始めます。
Because the block data is different, this requires redoing the proof of work. Furthermore, the attacker's new version of block 270 has a different hash, so the original blocks 271 to 275 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 275 chain while the attacker alone is working on the 270 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").
そのブロックデータが異なっているから、これは仕事の証明をやり直すことを必要とします。 さらに、攻撃者の新しいバージョンブロック２７０は異なったハッシュを持ち、それで最初のブロック271から275がそれを「ポイント」しません；それで、オリジナルのブロックチェーンと攻撃者の新しいブロックチェーンは完全に別個です。その規則は分岐でフォークで最も長いブロックチェーンが真であると思われるということで、それで、攻撃者が単独で270のブロックチェーンで働いている一方で、正当な鉱夫が275のブロックチェーンで働いているでしょう。 攻撃者が彼のブロックチェーンを最も長くするために、彼は結束した回線網の残りが追いつくためにより多くの電算力を持つ必要があるでしょう。（それ故、「５１％が攻撃します」）
Merkle Trees
Merkle のツリ
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.
左：分岐のの妥当性の証明を与えるために Merkle ツリーでは単にノードの少数だけを提出することはすれば十分です。
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.
ビットコインの重要な拡大縮小可能性機能はそのブロックがマルチレベルのデータ構造に蓄積されるということです。ブロックの「ハッシュ」は実際はただブロックヘッダのハッシュで、タイムスタンプ、乱数、前のブロックハッシュとブロックのすべてのトランザクションをしまっている マークルツリーと呼ばれるデータ構造のルートハッシュを含むざっと言って200バイトの一片のデータに過ぎません。 マークルツリーはツリーの一番下のタイプの多数の枝葉のノードを持っている１セットのノードで構成された 2進ツリーで、基礎をなすデータや各ノードが、その２つの子ハッシュで、最終的にその２つの子ハッシュから同じく構成される一つのルートノードのハッシュで、ノードツリーの「トップ」を表す１セットの中間ノードを含んでいます。
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.
マークル ツリープロトコルは多分長期の持続可能性に間違いなく必須です。 ビットコイン回線網の中の「全ノード」、各ブロックの全部を蓄積し、処理するものが２０１４年４月の時点でビットコイン回線網でのおよそ１５ＧＢのディスク・スペースを取って、そして１カ月に１ギガバイト以上大きくなっています。 現在、これは電話ではなく、若干のデスクトップコンピュータのために実行可能で、そして後で将来単にビジネスと趣味に熱中する人だけが参加することが可能でしょう。 「単純化された支払い検証」として知られているプロトコール（SPV）が「ライトノード」と呼ばれて、ブロックヘッダをダウンロードするもう１つ別のノードのクラスが、ブロックヘッダの仕事の証明を検証して、そして次にただそれらに適切なトランザクションと結び付けられる「ブランチ」だけをダウンロードすることを可能にします。 これはライトノードがビットコイン取引きの状と現在の差し引き残高況が、ただブロックチェーン全体の非常に少しの部分だけをダウンロードしている間に、どうであるかセキュリテイの強い保証で決定することを可能にします。
Alternative Blockchain Applications
代替ブロックチェーンアプリケーション
The idea of taking the underlying blockchain idea and applying it to other concepts also has a long history.
基礎をなすブロックチェーンの考えを取り、そして同じくそれを他の概念に適用するという考えは長い歴史を持っています。
In 1998, 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.
１９９８年に、ニック・サボは所有者オーソリティで安全な不動産タイトルのコンセプトを公表しました。それは「複製データベース技術での新しい進歩」がブロックチェーンベースのシステムをどのように、家屋敷や他人の財産所有とグルジアの土地税のようなコンセプトを含む精巧な構想を作って、誰がどの土地を所有するかの登録を蓄積するための考慮に入れるであろうか記述する文書です。しかしながら、当時、不幸にも利用可能な効果的な複製データベース・システムがありませんでした、そしてそれでそのプロトコールは決して実際は実装されませんでした。 しかしながら、2009年の後に、 ビットコインの分散コンセンサスが開発された途端に、多くの代替アプリケーションが急速に出現し始めました。
 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.
ネームコイン－ 2010年に作成されて、 ネームコインは分散名前登録データベースだとして、最も良く記述されます。 Torや、ビットコインや ビットメッセージのような分散プロトコルで、他の人々がそれらと相互に作用することができるように、アカウントを特定するいずれかの方法である必要があります。しかしすべての既存のソリューションで唯一の利用可能な識別子の種類は 1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy のような擬似ランダムハッシュです。 理想的には、人は「george」のような名前におけるアカウントを持っていることが可能であることを望みます。 しかしながら、問題は、もし１人の人が「george」という名前のアカウントを作ることができるなら、ほかの誰かが同様に彼ら自身のために「george」を登録する同じプロセスを使って、そしてそれらに成りすますことができるということです。 唯一の解決はファイルへの最初パラダイムです、そこでは最初の登録は成功し、二番目は失敗します － それは完全にビットコイン合意プロトコールに適している問題です。 ネームコイン はこのような考えを使う最も古い、そして最も成功した、名前登録制度の実装です。
 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.
カラードコイン －カラードコインの目的は人々に彼ら自身のデジタル通貨を作成することを可能にするためにプロトコールとしての役をすることです － あるいは、そしてビットコインブロックチェーンについての１つの単位を持った通貨、デジタルトークン、の重要な取るに足りないケースでです。 着色されたコインプロトコールで、１つは、公的に特定のビットコイン UTXO に色を割り当てることによって、新通貨を「発行します」、そしてそのプロトコールはそれらを作成している取引きが使ったインプット（若干の特殊な規則が混ぜられた色のインプットのケースに適用します）の色と同じであるために回帰的に他の UTXO の色を定義にします。 これはユーザーがただ特定の色の UTXO だけを含んでいるウオレットを維持・管理して、そしてそれらをブロックチェーンを通して同じ道を引き返している通常のビットコインとほとんど同じようにそれらがとるどんな UTXO の色でも決定するために近くにいるようにすることを可能にします。
 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.
メタコイン－ メタコインの背後にある考えは、ビットコイン取引を メタコイン取引を蓄積するために使うが、しかし異なった状態遷移関数APPLY'を持って、ビットコインの上に生きているプロトコールを持つことです」。それは、メタコインのプロトコールは、ビットコインブロックチェーンで、現れる無効な メタコイントランザクションを防ぐことができないから、もしAPPLY'(S,TX)なら、APPLY'(S,TX) = Sへエラー、プロトコルデフォルトを返すという規則が加えられます。 これは、任意の暗号通貨プロトコールを作成することに対して、容易なメカニズムを供給し、潜在的に ビットコイン自身 の内部で実装することができない先進機能を持つが、採掘そしてネットワークの複雑さがすでにビットコインプロトコールによって処理されますから、非常に低い開発費です。メタコインは金融契約、名前登録と分散交換の若干のクラスを実装するために使われてきています。
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.
ビットコインベースのアプローチは、他方、ビットコインの単純化された支払い適合確認機能を継承しない欠陥があります。 それがブロックチェーンの深さを妥当性の代用として使うことができるから、 SPV はビットコインのために働きます；ある時点で、かつて取引きの先祖がはるかに十分に逆戻れると、それらが合法的にその状態の一部であったと言うことは安全です。 ブロックチェーンベースのメタプロトコルが、他方、ブロックチェーンにそれら自身のプロトコルの文脈の中で妥当でない取引を含まないよう強いることはできません。 それ故、完全に安全な SPV メタプロトコル製品がバックワードにある特定のトランザクションが妥当であるかどうか決定するビットコインブロックチェーンの始まりへのすべての道をさっと見渡す必要があるでしょう。 現在、ビットコインベースのメタプロトコルのすべての「ライト」実装は、暗号通貨の主要な目的の１つが信頼の必要を削除することであるとき、特に、データ、多分大いに次善の結果を提供するために信頼できるサーバーに頼ります。
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.
どんな拡張なしでさえ、ビットコインプロトコールは実際に「スマート契約」のコンセプトの弱いバージョンを促進します。 ビットコインでの UTXO は公開キーによってだけではなく、単純なパイルアップベースのプログラム言語でも表現されるいっそう複雑なスクリプトによる所有も可能です。 このパラダイムで、その UTXO を使っている取引きがスクリプトを満たすデータを提供しなくてはなりません。 本当に、基本的な公開キー所有権メカニズムさえスクリプトによって実装されます：入力として、そのスクリプトは省略法のカーブ署名をして、取引きと UTXO を所有するアドレスに対してそれを確認して、そして、もし適合確認が成功したら、１を返します。 さもなければ、０を返します。他の、いっそう複雑な、スクリプトは、種々の追加のユースケースのために存在します。 例えば、あるものは、所定の３の秘密キーのうち２つからの署名が（「多重署名」）法人アカウントのために有用なセットアップ、確かな貯蓄預金アカウントと若干の商業エスクロー状況を検証するため必要とするスクリプトを作ることができます。スクリプトは同じく電算の問題に対する解決に対して報奨金を支払うために使うことができます、また、あるものは何かが、本質的に分散した暗号通貨をまたがる交換を可能にして「もしあなたがあなたがこの通貨単位の ドッジコイン取引きを私に送ったという SPV 証明を提供することができるなら、このビットコイン UTXO があなたのです」と、いうようなスクリプトを作りさえすることができます。
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.
チューリング - 完全性の欠如 － すなわち、ビットコインスクリプト言語がサポートする電算の大きい下位グループがある一方で、それはほとんどすべてを支持するわけではありません。 欠けている主な種類はループです。 これは取引き検証の間に無限ループを避けるために行われます； 理論的にそれはスクリプトプログラマーのために克服可能な障害で、と言うのも、どんなループも、部分条件文で何度も単に基礎をなしているコードを繰り返すことによって、シミュレーションを行うことができますが、しかしそれは非常に空間の非能率的なスクリプトに導きます。 例えば、代替省略カーブ署名アルゴリズムを実行することは多分すべて個々にコードに含められた256の繰り返された逓倍ラウンドを必要とするでしょう。
 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.
価値盲目 － 引き出すことができる金額に UTXO スクリプトがきめ細かいコントロールを提供する方法がありません。 例えば、神託契約の１つの強力なユースケースは掛けつなぎ契約でしょうが、そこではＡとＢが１０００ドルの価値に相当する BTC を賭け、そして３０日の後にスクリプトはＡに１０００ドルの価値に相当する BTC を、そしてＢに残りを送ります。 これは神託がＵＳＤの１ BTC の価値を決定することを必要とするであろう、しかし、たとえそれでもそれは完全に中央集権化した今利用可能な解決にまたがる信頼とインフラストラクチャー必要条件に関する大規模な改良でです。 しかしながら、 UTXO がすべてか、さもなくばゼロであるから、これを達成する唯一の方法はさまざまな通貨単位の多くの UTXO （例えば、最高３０のすべてのｋための２ｋの１つの UTXO）を持っていて、そしてどの UTXO をＡにそしてどれをＢにOが選ぶようにする非常に非能率的なハッキングを通すことしかありません。
 Lack of state - a 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.
状態の欠如 － UTXO の欠如は費やされるかあるいは費やされないこともあり得ます；多段階オプション契約あるいはそれを越えて他のいかなる内部状態でも保持するスクリプトのための機会がありません。 これは多段階のオプション契約や、分散交換の申し出あるいは２段階の暗号のプロトコルの約束（安全な電算の報奨金に必要な）をすることを難しくします。 それは同じく UTXO が単純な、一回限りの契約を作るために使うことができるだけで、ただ分散組織のようないっそう複雑な「stateful」契約ではなく使えません、そして実装を難しくするメタプロトコルを作ります。 同じく価値盲目と組み合わせられる２進法の状態が他のの重要なアプリケーションや、引き出し限界が不可能であることを意味します。
 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.
ブロックチェーン盲目 － UTXO は乱数、タイムスタンプと前のブロックハッシュのようなブロックチェーンデータには盲目です。 潜在的に貴重な偶発性の源をスクリプト言語からを奪うことによって、これは賭博やいくつかの他のカテゴリーでのアプリケーションをひどくを制限します。
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.
スクリプト記述を使うことは実装して、そして標準化することが容易ですが、その能力で非常に限定されています、そしてメタプロトコルが、容易である一方で、拡大縮小可能性で障害を被ります。 イーサリアムで、我々は、同時にアプリケーションが経済環境とブロックチェーンセキュリテイを共有することを可能にする一方で、もっと強い軽いクライアント資産さえ同様に、開発の容易さのより大きい利得さえ供給する代替フレームワークを作るつもりです。
Ethereum
イーサリアム