「検証サブシステム」の版間の差分

提供: tezos-wiki
移動先: 案内、 検索
(ページの作成:「.. _validation: = The validation subsystem = This document explains the inner workings of the validation subsystem of the Tezos shell, that sits between the peer-to-pee...」)
 
 
1行目: 1行目:
−
.. _validation:
+
.. _validation：
  
−
= The validation subsystem =
+
=検証サブシステム=
  
−
This document explains the inner workings of the validation subsystem of the Tezos shell, that sits between the peer-to-peer layer and the economic protocol. This part is in charge of validating chains, blocks and operations that come from the network, and deciding wether they are worthy to propagate. It is composed of three main parts: the :ref:<code>validator&lt;validator_component&gt;</code>, the :ref:<code>prevalidator&lt;prevalidator_component&gt;</code>, and the :ref:<code>distributed DB&lt;DDB_component&gt;</code>.
+
このドキュメントでは、ピアツーピア層と経済プロトコルの間にあるTezosシェルの検証サブシステムの内部動作について説明します。この部分は、ネットワークから来たチェーン、ブロック、操作を検証し、伝播する価値があるかどうかを判断する役割を担います。 ：ref：<code>バリデータ<validator_component> </ code>、：ref：<code>プリバリデータ＆lt; prevalidator_component＆gt; </ code>、および：ref：<code> ; DDB_component＆gt; </ code>。
  
−
|Tezos validation diagram|
+
| Tezos検証ダイアグラム|
  
−
== Validator ==
+
==バリデータ==
  
−
.. _validator_component:
+
.. _validator_component：
  
−
The validator is the component responsible for checking that blocks coming from the network or a baker are valid, w.r.t. the rules defined by the economic protocol, and for selecting the block that it considers to be the current head of the blockchain.
+
バリデーターは、ネットワークまたはベイカーからのブロックが有効であるかどうかをチェックするコンポーネントです。w.r.t.経済プロトコルによって定義されたルール、およびブロックチェーンの現在のヘッドと見なされるブロックを選択するために使用されます。
  
−
The validator is written as a collection of workers: local event loops communicating with each other via message passing. Workers are spawned and killed dynamically, according to connected peers, incoming blocks to validate, and active (test)chains.
+
バリデーターは、ワーカーの集合として書かれています。ローカルイベントループは、メッセージパッシングを介して互いに通信します。ワーカーは、接続されたピア、検証する入力ブロック、アクティブ（テスト）チェーンに従って、動的に生成され、強制終了されます。
  
−
A ''chain validator'' worker is launched by the validator for each ''chain'' that it considers alive. Each chain validator is responsible for handling blocks that belong to this chain, and select the best head for this chain. A main chain validator is spawned for the main chain that starts at the genesis, a second one when there is an active test chain. Forking a chain is decided from within the economic protocol. In version Alpha, this is only used to try new protocols before self amending the main chain.
+
''連鎖バリデータ ''ワーカーは、それが生きていると考えている各連鎖に対してバリデーターによって起動されます。各チェーンバリデーターは、このチェーンに属するブロックを処理し、このチェーンに最適なヘッドを選択します。主鎖バリデーターは起源で始まる主鎖のために生まれ、能動的なテスト鎖があるときは第2のものです。チェーンをフォークすることは、経済的議定書の中から決定される。 Alpha版では、これは、メイン・チェーンを自己修正する前に新しいプロトコルを試すためにのみ使用されます。
  
−
The chain validator spawns one ''peer validator'' worker per connected peer. This set is updated, grown or shrunk on the fly, according to the connections and disconnections signals from the peer-to-peer component. Each peer validator will treat new head proposals from the associated peer, one at a time, in a loop. In the simple case, when a peer receives a new head proposal that is a direct successor of the current local head, it launches a simple ''head increment'' task: it retrieves all the operations and triggers a validation of the block. When the difference between the current head and the examinated proposal is more than one block, mostly during the initial bootstrap phase, the peer worker launches a ''bootstrap pipeline'' task.
+
チェーンバリデーターは、接続されたピアごとに1つの "ピアバリデータ"ワーカーを生成します。このセットは、ピア・ツー・ピア・コンポーネントからの接続および切断信号に従って、オンザフライで更新、拡張または縮小されます。各ピアバリデータは、関連するピアからの新しいヘッド提案をループで一度に1つずつ処理します。単純なケースでは、現在のローカルヘッドの直下にある新しいヘッド提案をピアが受け取ると、単純な「ヘッドインクリメント」タスクが起動されます。すべての操作が取得され、ブロックの検証がトリガーされます。現在のヘッドと検査された提案の差が1つ以上のブロックである場合、主に初期ブートストラップフェーズの間に、ピアワーカーは「ブートストラップパイプライン」タスクを起動します。
  
−
A third scheme is planned (but not yet implemented) for validating alternative chains: the ''multipass validator''. This method is quite more complex, its goal is to detect erroneous blocks as soon as possible, without having to download all the chain data. This will work by first validating the block headers, then the operations that act on the fitness, and finally the remaining operations. The mechanism is actually a bit more flexible, and allows for an arbitrary number of lists of operations. The shell will only consider forks of a given length, that is exported by the protocol, so that block headers and operations are validated in the context of an ancestor block that is in a close enough time window. In version Alpha, the check performed on block headers is that the baking slots, baker signatures and timestamp deltas are right. It can also detect too large fitness gaps, as the fitness difference between two consecutive blocks is bounded in Alpha. The operations that act on fitness are endorsements, whose checks consist in verifying the endorsement slots and endorsers' signatures. For that to be sound, the fork limit is set to not allow rewinding before the baking and endorsing slots are set.
+
第3のスキームは、代替チェーンを検証するために計画されています（まだ実装されていません）： ''マルチパスバリデーター ''。この方法はかなり複雑です。その目的は、すべてのチェーンデータをダウンロードすることなく、できるだけ早く誤ったブロックを検出することです。これは、最初にブロックヘッダーを検証し、次にフィットネスに作用する操作、そして最後に残りの操作によって機能します。このメカニズムは実際には少し柔軟性があり、任意の数の操作リストが可能です。シェルは、プロトコルヘッダーと操作が十分近い時間ウィンドウにある先祖ブロックのコンテキストで検証されるように、プロトコルによってエクスポートされる所定の長さのフォークのみを考慮します。バージョンAlphaでは、ブロックヘッダーで実行されるチェックは、ベーキングスロット、ベーカーシグネチャ、およびタイムスタンプデルタが正しいことです。また、2つの連続するブロック間の適合度の差がAlphaに限定されているため、大きすぎるフィットネスギャップを検出することもできます。適性に基づいて動作するオペレーションは、裏書と裏書の署名を検証するチェックで構成されています。これが妥当であるためには、フォークリミットは、ベーキングおよびエンドーサングスロットが設定される前に巻戻しを許可しないように設定されています。
  
−
Each of these three peer validator tasks (head increment, bootstrap pipeline or multipass) will interact with the distributed DB to get the data they need (block headers and operations). When they have everything needed for a block, they will call the ''block validator''.
+
これらの3つのピアバリデータタスク（ヘッドインクリメント、ブートストラップパイプライン、マルチパス）のそれぞれは、必要なデータを取得するために分散DBとやりとりします（ヘッダーと操作をブロックします）。ブロックに必要なものがすべてあるときは、ブロックバリデーターを呼び出します。
  
−
The ''block validator'' validates blocks (currently in sequence), assuming that all the necessary data have already been retrieved from the peer-to-peer network. When a block is valid, it will notify the corresponding chain validator, that may update its head. In this case, the chain validator will propagate this information to its associated ''prevalidator'', and may decide to kill or spawn the test network according to the protocol's decision.
+
「ブロックバリデーター」は、すべての必要なデータがすでにピアツーピアネットワークから取得されていると仮定して、ブロックを（順番に）検証します。ブロックが有効な場合、ブロックは対応するチェーンバリデーターに通知します。この場合、チェーンバリデーターは、この情報を関連する「プリバリデーター」に伝播し、プロトコルの決定に従ってテストネットワークを強制終了または起動させることができます。
 +
==プリバリデータ==
  
−
== Prevalidator ==
+
.. _prevalidator_component：
  
−
.. _prevalidator_component:
+
各チェインバリデーターには、このチェインの操作のピアツーピア通信による送信を担う、「プリバリデーター」（これは、将来的にはオプションとなり、RAMの少ないマシンでノードを実行できるようになります）ピアネットワーク。
  
−
To each chain validator is associated a ''prevalidator'' (this may become an option in the future, to allow running nodes on machines with less RAM), that is responsible for the transmission of operations for this chain over the peer-to-peer network.
+
スパムを防止するために、このプレバリデータは、有効と見なされる一連の操作と、ブロードキャストに選択された操作のセットを選択する必要があります。これは、ダミーブロックを常にベーキングし、現在のヘッドに浮かべて、新しい操作を受け取ったときに成長させることによって行われます。
  
−
To prevent spam, this prevalidator must select the set of operations that it considers valid, and the ones that it chooses to broadcast. This is done by constantly baking a dummy block, floating over the current head, and growing as new operations are received.
+
含まれる操作は、無条件にブロードキャストできます。
  
−
Operations that get included can be broadcasted unconditionally.
+
含まれるオペレーションはカテゴリに分類されます。いくつか（悪い署名やガーベジ・バイト・シーケンスなど）は破棄されます。それらは一時的に制限されたセットに入れられ、それを送信したピアが蹴られます。他の操作は一時的に拒否されます。早すぎたり遅すぎたりします。たとえば、Alphaでは契約にカウンタがあり、将来のカウンタでの操作は一時的に拒否されたものとして分類されます。悪意のあるピアは、そのような操作でmempoolを簡単に氾濫させる可能性があります。そのため、境界のあるセットに入れられます。もう1つの有界集合は、第3の種類の非包含のためにも保持されます。
  
−
Operations that are included are classified into categories. Some (such as bad signatures or garbage byte sequences) are dismissed. They are put in a temporary bounded set for quick rejection, and the peer that sent it is kicked. Some other operations are temporarily refused: they come too soon or too late. For instance, in Alpha, contracts have counters, and operations with counters in the future are classified as temporarily refused. A malicious peer could easily flood the mempool with such operations, so they are put in a bounded set. Another bounded set is also kept for a third kind of non inclusion: operations that could be valid in another branch.
+
==分散DB ==
  
−
== Distributed DB ==
+
.. _DDB_component：
  
−
.. _DDB_component:
+
検証のために必要なリソースの集約は、分散型データベースに集約されています。このコンポーネントは、リクエストされたリソースごとにスロットを割り当てます。優先順位は、要求するピアバリデータの数に依存します。
  
−
The gathering of resources needed for validation is centralized in the ''distributed db''. This component allocates a slot per requested resource, whose priority depends on the number of peer validators requesting it.
+
.. | Tezos検証ダイアグラム| image :: validation.svg
−
 
 
−
.. |Tezos validation diagram| image:: validation.svg
 

2018年5月31日 (木) 00:10時点における最新版

.. _validation：

検証サブシステム[編集]

このドキュメントでは、ピアツーピア層と経済プロトコルの間にあるTezosシェルの検証サブシステムの内部動作について説明します。この部分は、ネットワークから来たチェーン、ブロック、操作を検証し、伝播する価値があるかどうかを判断する役割を担います。 ：ref：バリデータ<validator_component> </ code>、：ref：<code>プリバリデータ＆lt; prevalidator_component＆gt; </ code>、および：ref：<code> ; DDB_component＆gt; </ code>。

| Tezos検証ダイアグラム|

バリデータ[編集]

.. _validator_component：

バリデーターは、ネットワークまたはベイカーからのブロックが有効であるかどうかをチェックするコンポーネントです。w.r.t.経済プロトコルによって定義されたルール、およびブロックチェーンの現在のヘッドと見なされるブロックを選択するために使用されます。

バリデーターは、ワーカーの集合として書かれています。ローカルイベントループは、メッセージパッシングを介して互いに通信します。ワーカーは、接続されたピア、検証する入力ブロック、アクティブ（テスト）チェーンに従って、動的に生成され、強制終了されます。

連鎖バリデータ ワーカーは、それが生きていると考えている各連鎖に対してバリデーターによって起動されます。各チェーンバリデーターは、このチェーンに属するブロックを処理し、このチェーンに最適なヘッドを選択します。主鎖バリデーターは起源で始まる主鎖のために生まれ、能動的なテスト鎖があるときは第2のものです。チェーンをフォークすることは、経済的議定書の中から決定される。 Alpha版では、これは、メイン・チェーンを自己修正する前に新しいプロトコルを試すためにのみ使用されます。

チェーンバリデーターは、接続されたピアごとに1つの "ピアバリデータ"ワーカーを生成します。このセットは、ピア・ツー・ピア・コンポーネントからの接続および切断信号に従って、オンザフライで更新、拡張または縮小されます。各ピアバリデータは、関連するピアからの新しいヘッド提案をループで一度に1つずつ処理します。単純なケースでは、現在のローカルヘッドの直下にある新しいヘッド提案をピアが受け取ると、単純な「ヘッドインクリメント」タスクが起動されます。すべての操作が取得され、ブロックの検証がトリガーされます。現在のヘッドと検査された提案の差が1つ以上のブロックである場合、主に初期ブートストラップフェーズの間に、ピアワーカーは「ブートストラップパイプライン」タスクを起動します。

第3のスキームは、代替チェーンを検証するために計画されています（まだ実装されていません）： マルチパスバリデーター 。この方法はかなり複雑です。その目的は、すべてのチェーンデータをダウンロードすることなく、できるだけ早く誤ったブロックを検出することです。これは、最初にブロックヘッダーを検証し、次にフィットネスに作用する操作、そして最後に残りの操作によって機能します。このメカニズムは実際には少し柔軟性があり、任意の数の操作リストが可能です。シェルは、プロトコルヘッダーと操作が十分近い時間ウィンドウにある先祖ブロックのコンテキストで検証されるように、プロトコルによってエクスポートされる所定の長さのフォークのみを考慮します。バージョンAlphaでは、ブロックヘッダーで実行されるチェックは、ベーキングスロット、ベーカーシグネチャ、およびタイムスタンプデルタが正しいことです。また、2つの連続するブロック間の適合度の差がAlphaに限定されているため、大きすぎるフィットネスギャップを検出することもできます。適性に基づいて動作するオペレーションは、裏書と裏書の署名を検証するチェックで構成されています。これが妥当であるためには、フォークリミットは、ベーキングおよびエンドーサングスロットが設定される前に巻戻しを許可しないように設定されています。

これらの3つのピアバリデータタスク（ヘッドインクリメント、ブートストラップパイプライン、マルチパス）のそれぞれは、必要なデータを取得するために分散DBとやりとりします（ヘッダーと操作をブロックします）。ブロックに必要なものがすべてあるときは、ブロックバリデーターを呼び出します。

「ブロックバリデーター」は、すべての必要なデータがすでにピアツーピアネットワークから取得されていると仮定して、ブロックを（順番に）検証します。ブロックが有効な場合、ブロックは対応するチェーンバリデーターに通知します。この場合、チェーンバリデーターは、この情報を関連する「プリバリデーター」に伝播し、プロトコルの決定に従ってテストネットワークを強制終了または起動させることができます。

プリバリデータ[編集]

.. _prevalidator_component：

各チェインバリデーターには、このチェインの操作のピアツーピア通信による送信を担う、「プリバリデーター」（これは、将来的にはオプションとなり、RAMの少ないマシンでノードを実行できるようになります）ピアネットワーク。

スパムを防止するために、このプレバリデータは、有効と見なされる一連の操作と、ブロードキャストに選択された操作のセットを選択する必要があります。これは、ダミーブロックを常にベーキングし、現在のヘッドに浮かべて、新しい操作を受け取ったときに成長させることによって行われます。

含まれる操作は、無条件にブロードキャストできます。

含まれるオペレーションはカテゴリに分類されます。いくつか（悪い署名やガーベジ・バイト・シーケンスなど）は破棄されます。それらは一時的に制限されたセットに入れられ、それを送信したピアが蹴られます。他の操作は一時的に拒否されます。早すぎたり遅すぎたりします。たとえば、Alphaでは契約にカウンタがあり、将来のカウンタでの操作は一時的に拒否されたものとして分類されます。悪意のあるピアは、そのような操作でmempoolを簡単に氾濫させる可能性があります。そのため、境界のあるセットに入れられます。もう1つの有界集合は、第3の種類の非包含のためにも保持されます。

分散DB[編集]

.. _DDB_component：

検証のために必要なリソースの集約は、分散型データベースに集約されています。このコンポーネントは、リクエストされたリソースごとにスロットを割り当てます。優先順位は、要求するピアバリデータの数に依存します。

.. | Tezos検証ダイアグラム| image :: validation.svg

「http://tezos-wiki.jp/wiki/index.php?title=検証サブシステム&oldid=26275」から取得