Dragon Chainアーキテクチャ日本語訳(ゴリラ翻訳)ディズニーとの関係性はいかに?


どうもゴリラです。

今回はディズニーで開発されたと言われているドラゴンチェーンのアーキテクチャドキュメントを日本語にゴリラ翻訳してみましたので公開しようと思います。

※注意点

このテキストはゴリラ翻訳でしておりその内容は英語の公式ドキュメントとは大きな違いがある場合があります。その場合は公式ドキュメントを参照してください。またゴリラ翻訳していますので専門的な用語やローカルの独特な言い回しには対応しきれておりません。

またこの原本のドキュメントもホワイトペーパーではありません。

ドラゴンチェーンの設計部分を説明しております。


ドラゴンチェーンアーキテクチャ

このドキュメントの目的は、実際のビジネスアプリケーションの統合を容易にするブロックチェーンプラットフォームのアーキテクチャと設計を概説し、伝えることです。
著者の意見では、ブロックチェーンの統合を簡素化する必要性が高まっています。
ブロックチェーンの実装に対する分散化された単一のアプローチは、情報を保護し、ビジネスプロセスを制御するための実際のビジネスニーズと時には矛盾します。
このドキュメントでは、列挙されたブロックチェーンアーキテクチャ要素の実装を成功に導くための例を提供しています。

目標

1.既存のシステムの統合の容易さ
2.ブロックチェーンに慣れていない伝統的なエンジニアやコーダーの開発が容易
システム、および暗号
3.クライアント・サーバー・スタイルとビジネス統合のための簡単なRESTful統合ポイント
4.シンプルなアーキテクチャー(予期しないアプリケーションに柔軟に対応可能)
5.デフォルトでビジネスデータを保護する
6.ビジネスに焦点を当てたプロセスの制御を可能にする
7.固定長期間ブロック
8.ショート/ファストブロック
9.通貨に依存しないブロックチェーン(複数通貨サポート)
10.基本通貨なし
11.他のブロックチェーンとの相互運用性
12.利用可能になった標準の採用については、W3C Blockchain Community Group
ブロックチェーンの標準化とディズニーブロックチェーンの標準化に関する注意

要素

証拠の要約
Bitcoinや他の大部分の暗号化通信では、「信頼できない」システムのコンセンサスの基礎として、「実証実験」(PoW)アルゴリズムの使用が目撃されています。
このアーキテクチャでは、「証明」は抽象化され、特定のブロックチェーンに対して1つ以上の方法で実装されます。
いくつかの用途では、例えば、完全にプライベートなブロックチェーンシステムにおいて、信頼ベースのシステムを使用することを望む場合がある。
また、Proof of Workに加えて、攻撃に対して追加のセキュリティを追加するために信頼が適用されることが確認されているハイブリッドプルーフ構成の価値があります(潜在的な攻撃者は秘密鍵のセットを妥協または獲得する必要はなく、設定された証明を実行して所定のブロックチェーンを再構成する計算を実行します。

実証済みの実装:
1.信頼(デフォルト)
2.仕事の証明(PoW)
3.ステークの証拠(PoS)
4.まだ決定されている他のアルゴリズム

そのような抽象化が与えられれば、ユーザーはビジネスニーズに合わせて1つ以上の同時プルーフを構成することができますが、システム開発者はブロックチェーン技術の進歩に伴って新しいプルーフ実装を構築できます。

1つまたは複数のプルーフ実装をブロックにまたがって固定長ブロック構造の場合でもPoWを実行することができます(この記事の他の部分ではブロック構造の説明を参照してください)。
たとえば、通常のセキュリティより高いセキュリティを必要とする特定のユースケースがあるとします。
Trustがデフォルトで実装されていると仮定した場合、
信頼できない検証の量を増やすために、私たちはブロックチェーン上にいくつかのレベルの作業証明書を設定したいと思うかもしれません。
設定された難易度に応じて、PoWアルゴリズムの性質を考慮すると、すべてのブロックに対してPoWソリューションが表示されない場合があります。いくつかのブロックはPoWを持たず、PoW応答は時々しか現れない。
そのような場合、2つ以上のレベルのPoWを構成することが合理的であり得る。
難易度の高い証明は約20分ごとに表示され、難易度の低い証明は約2秒ごとに表示されるように調整できます。
同じ方法で、PoSのような他の証明が単一のチェーン内で同時に適用されてもよい。
興味深い哲学的ポイントは、そのような証明が、ブロック報酬のための他の鉱夫との競争ではなく、将来の攻撃者との競争で使用される可能性があることです。

存在のチェックと証拠
証明の抽象化におけるもう一つの要素は、他の(公的な)ブロックチェーンにチェックポインティングすることによってハイブリッド化する能力です。
これは、パブリックまたはプライベートのブロックチェーン間の第1レベルまたは単純な相互運用性として見ることができます。
特定の潜在的な価値のうち、公的なブロックチェーンの属性を測定することによってリスクを確かめる能力があります。
つまり、BitcoinなどのPoWを使用するパブリックブロックチェーンに接続すると、システムはチェックポイント以降に適用されたハッシュパワーの量を見積り、その計算能力を使用したドルに外挿することさえできます。
これにより、どのくらいの計算能力が必要になるかを示すリスクユニットが開発される可能性があります
(例えば、高い価値のある取引)を偽造しようとした場合の成功率を計算するために、そのコスト(およびその費用はいくらか)を計算する。
同じように、PoSに基づいてパブリックブロックチェーンにチェックポイントを割り当てることで、システムは問題のトランザクションを偽造するために保持する必要のある資産の量を測定できます(犠牲になる可能性があります)。
詳細については、下のレベル5検証の説明を参照してください。

トランザクションの定義

トランザクションは、すべてのイベントまたはデータ転送がブロックチェーンプラットフォーム内で記録される基礎となります。
システムは、柔軟で拡張可能な標準化されたトランザクション構造を定義する必要があります。
実装のオプション:
標準化された構造のJSON
JWT(JSON Webトークン)
他のコード化された構造(複数の言語のライブラリをサポート)

ヘッダ
トランザクションのシステムまたはネットワークで定義された標準標準メタデータフィールドが含まれます。
フィールドの例:
Transaction ID
Transaction type
Transaction class
Create timestamp
Transaction timestamp
Origin ID
Business organization and/or organization taxonomy
Actor
Entity

ペイロード
ビジネスレベルで定義され、レベル1の承認コード内で実装または管理される任意の構造およびコンテンツ。
ペイロード内のあるレベルの構造(例えば、フィールドおよび構造)は、ネットワーク全体のテンプレートとして実装され、オプションのトランザクションクラスヘッダフィールドに基づいて利用および注記される。
これにより、ノードは、エンタープライズレベルまたはネットワークレベルで定義されたいくつかの必要な動作を実装し、通貨などの機能を単純化することができます。
トランザクションクラスの例は以下を参照してください。

シグニチャ
トランザクションの部分で、署名の発行元(つまり、改ざんされていること)が原因でソースが証明され、トランザクションの内容が変更されないようにするための暗号署名を保持する部分。
トランザクションソース(例えば、クライアントまたは第三者システム)からのトランザクション内の署名は、暗号化されていないか、ブロックチェーンプラットフォームを認識していないクライアントである必要がありません。
あるいは、クライアントシステムは、例えば、トランザクション提出の前に複数パーティ署名のプロセスを呼び出すことができる。
いずれにしても、ブロックチェーンプラットフォームノードのTransaction Serviceコンポーネントは、(設定されたキーペアを使用して)処理のために受け入れるすべての受信トランザクションに暗号で署名する必要があります。

知覚される要件
構造は、複数のパーティーとネストされた署名を可能にするべきです
署名は、署名自体が改ざんされないように、署名構造自体内のすべてのフィールドをハッシュと署名から除外する必要があります
構造は、検証レコード(ブロック検証)の署名プロセスで再利用されるべきである

クラス
可能なトランザクションクラスの例をいくつか示します。
デフォルト(カスタムレベル1ビジネスペイロード構造)
通貨
プロビジョニング
ネットワーク通信
マーケットプレイス取引
情報の相互運用性(外部ブロックチェーン通貨または情報ペイロード)

ブロック定義

ブロック定義には複数の実装が含まれることがありますが、共通要素が多かれ少なかれ
以下を含む:
ブロックID
タイムスタンプ
トランザクション
前ブロックのハッシュ
証明(例えば、PoW、PoS)アーティファクト
署名
ブロック期間
検証属性

しばしば考慮されないブロック定義設計の興味深い部分は、ブロックがいつ形成されるかという問題です。
Bitcoinまたは他のPoWシステムでは、PoWアルゴリズムが解かれたときにブロックが形成される
現在のネットワークの難しさのために。
これは、30秒または30分後に発生する可能性があります。
それは可変でランダムであるが、ネットワークは平均ブロック時間を10分に調整するために難易度を調整しようとする。

トラストベースのシステムでは、可変時間ベースのブロックを維持する必要は絶対にありません。
実世界の多くのシステムでは、Bitcoinが平均ブロック時間を固定または高速にすることはできません。
このアーキテクチャでは、より適切なブロック時間を望むかもしれません。
固定時間(秒)(例えば、5秒)。
このような高速で固定されたブロック時間の定義は、コンセンサスの問題につながります。つまり、ネットワーク全体が5秒ごとにどのようにコンセンサスになるのでしょうか?
コンテキストベースの検証と「ブロックチェーンのブロックチェーン」(後述)の概念を使用すると、
個々のビジネスユーザーが管理するリスクでシステムは徐々にコンセンサスになります。

検証および合意

ここでは、ブロックチェーンの議論に「コンテキストベースの検証」という概念を導入します。
明らかにするには、Bitcoinや他の既存のブロックチェーン実装を検討してください。
それらは主に、時間の経過とともにブロックを組み立て、どのブロックおよびどの共通の合意された真実であるかについて合意に達するために、セットプルーフアルゴリズム(例えば、PoW)を使用する。

Dragonchainでは、コンテキストベースの承認を得て、そのデザインに別の次元を追加します。
最初のレベルは純粋なビジネスコンテキストで達成されます。つまり、ビジネスロジックを実装してトランザクション承認とシステムロジックを実装し、これらのトランザクションを連鎖するブロックに配置します。
これらのブロックには、PoW、PoS、または信頼などの統合された抽象的な証明があります。
この第1レベルの検証は、他のブロックチェーンと同様に考えることができます。
それは、他の検証コンテキストが追加されて、信頼ベースのシステムでさえも付加価値が見られるときです。
所与のノードは、理想的には、後述する1つまたは複数の検証フェーズをサポートまたは実行する構成を可能にするべきである。

レベル1 – ビジネス(承認)検証
承認機能は、ビジネスインテグレータによって実装および設定されます。
これは「現実世界」価値の統合のための配置です。組織またはブロックチェーンのプラットフォームユーザーによって定義されたビジネスロジックは、ブロックチェーンノードによって実行されるように構成されています。
また、トランザクションペイロードがビジネスによって必要なものであると定義されている場所もここにあります。
トランザクションは整理され、承認または拒否を決定する提供されたビジネスロジックに渡されます。
承認された取引は、「検証記録」と総称される「ブロック」にまとめられる。
各トランザクションのペイロードフィールドは、実際のビジネスデータの配信の制御を維持するために、最終ブロックを組み立てる前または後に取り除くことができる。
つまり、ビジネス・ペイロード・データはコンセンサス・プロセスの一環として提供されず、ビジネス所有者が別のノードにデータを明示的にプッシュしない限り(たとえば、バックアップ/ DRの場合)、データはレベル1ノード上にローカルに残ります。承認されたノードは、サブスクリプションフィードを介してデータをプルする。

レベル2 – エンタープライズ(検証)検証
このコンテキストは、エンタープライズまたはネットワーク全体で定義され、フォーム、署名、および必要なデータ要素でブロックおよび個々のトランザクションの有効性をチェックします。
検証済みの要素:
1.ブロック(検証記録)の構築と署名
2.個々の取引の署名
3.個々のトランザクションヘッダー要素(必要なすべてのヘッダーフィールドが存在する)
レベル2ノードは、次の内容を含む新しい検証レコードをアセンブルします。
1.有効なトランザクションのリストと無効なトランザクションのリスト。この方法で、個々のトランザクションの有効性に投票します。
2.同じ原点(レベル1)ノードに対してこのノードによって作成された以前のレベル2レコードのハッシュ(したがって、レベル2ブロックチェーンを作成する)
3.検証されたレベル1ブロックのハッシュ(したがって、ブロックチェーンに第2の次元を提供する)
ノード所有者識別情報
5.ノードの配置場所(データセンター)
ノードキー管理権限情報

レベル3 – ネットワークの多様性の検証
エンタープライズ全体で定義されたレベル3ノードは、検証(レベル2)検証の多様性を検証します。つまり、レベル3ノードは次の基準をチェックします。
レベル2検証記録の数が受信された
2.これらのレコードは、ユニークな事業単位(設定可能な数)から来たものであること
3.これらのレコードは、固有の展開場所(構成可能な数)から来たものであること
4。
これらのレコードは、固有の鍵管理機関の(構成可能なカウントから)得られたものであること。この検証コンテキストは、トランザクションの検証が十分に多様な分散ソースのセットから行われることを保証する。
また、ネットワーク効果の制御と測定を提供し、既存のデータを改ざんするために複数のシステム、企業、およびデータセンターを攻撃する攻撃者が必要となるため、分散セキュリティを提供します。
レベル3ノードは、以下を含む新しい検証レコードをアセンブルする。
1.基準の残りが満たされている(例えば、レベル2検証レコード数、ビジネスユニットのセット、データセンターのセット)。
2.同じ原点(レベル1)ノードに対してこのノードによって作成された以前のレベル3レコードのハッシュ(したがって、レベル3ブロックチェーンを作成する)
3.基準に合格したレベル2検証レコードのハッシュ
(したがって、第2の次元をブロックチェーンに提供する)

レベル4 – 外部パートナー(公証)検証
定義されたネットワークワイド(エンタープライズ+)では、レベル4ノードがコンセンサスプロセスに公証機能を提供します。
外部パートナーが主催するレベル4ノードは、受け取ったレベル3の検証レコードに暗号で署名します。
この機能により、レベル4ノードはレベル3検証に対する独立した証人として機能することができます。

レベル5 – 公衆チェックポイント
レベル5ノードは、1つまたは複数のパブリックブロックチェーンにブリッジを提供し、クライアントが相互作用できるようにします
(Bitcoin、Ethereum、Litecoinなど)を使用して
これが提供する重要な機能は、チェックポイントを設定すること、またはパブリックブロックチェーン上に「存在の証明」のアーティファクトのハッシュを配置することです。
チェックポイント操作の場合、レベル5ノードはトランザクション、任意のレベルのブロック検証、任意の文字列、または任意のハッシュを受け入れます。
引数はハッシュされ、このハッシュはパブリックブロックチェーンに置かれたトランザクションに追加されます。
このハッシュの存在は、パブリックブロックチェーンデータを使用して、アーティファクトが存在し、特定の状態にあることを証明するために使用できます。
組織は、この証明を使用して、その時間以降に消費されたハッシュパワーの見積もりまたは計算に基づいてリスクを測定し、軽減することができます(作業ブロックチェイン証明の場合)。
たとえば、Bitcoinブロックチェーン上にできるだけ早く配置するために、レベル2のノードに200万ドルのトランザクションを渡すことができます。そして、ある時点で、当事者はその情報をソースとして使用してハッシュパワーの量を測定します攻撃者が特定の割合のグローバルハッシュパワーを与えられたBitcoinブロックを偽造する確率を計算し、そのハッシュパワーを消費するためのコストを推定または推定します(ハードウェアおよび/または通貨の犠牲ネットワークが崩壊したため)。
このプロセスの結果、ビジネスにとって満足のいくリスク評価が得られれば、取引を信頼して受け入れることができます。
パブリックブリッジ機能のもう1つの重要な側面は、プライベート側とパブリック側の間でアセットを追跡する機能です。
つまり、Bitcoinアドレスを使用するために内部通貨が実装されているとします(
このドキュメントの他の箇所の通貨セクションを参照)、パブリックAPIまたはサービスを使用してBitcoin上でトークンを発行することができ、このトークンはプライベートブロックチェーンとBitcoinパブリックブロックチェーンの両方に存在する可能性があります。
キーまたはウォレットの所有者は、公開または非公開のブロックチェーン相互作用を使用してトークンまたはアセットを転送できます。
レベル5ノードを使用して、ブロックチェーン間でこのアセットを追跡することができます。
彼らはお互いに同期しているようにしてください。

レベルX – 固有コンテキスト検証
企業、エンタープライズ、またはネットワーク全体がカスタム検証コンテキストを定義し、ビジネスニーズを満たすためにそれを実行できるようにする必要があります。
ノードは、以下の方法でトリガされる任意の検証コンテキストを実行するように構成することができる。
別のノードからのブロードキャストの受信によって(順次または非順次のフェーズにおいて)
時限または周期的なトリガ(例えば、cron)によって、
3.オブザーバーパターンによる通知

このアーキテクチャは、「ブロックチェーンのブロックチェーン」として最もよく理解できます。
つまり、ビジネス承認機能ノード(下記レベル1を参照)は、1次元レベルの標準的なブロックチェーンとして機能します。
しかし、各ビジネス上の懸念事項には、通常、この作業を行う独自のノードがあり、それぞれに独自のブロックチェーンがあります。
これらのブロック鎖が合体してコンセンサスが達成される場所です。

通貨

このアーキテクチャは複数通貨対応でなければなりません。
すなわち、一般に、通貨ユースケースが定義されている場合、ノードは通貨を定義し、その使用をサポートすることができる。
ネットワーク上で複数の通貨が同時に使用されている可能性があります。
つまり、このアーキテクチャでは、「基本」通貨、またはシステム自体が稼働する通貨を定義するべきではありません。
このようなユースケースが発生した場合(実際に、ノードが検証のためにお金を支払う可能性がある通貨の可用性において価値を見出す可能性が非常に高い)、このアーキテクチャの哲学は、ノードを作成し維持するように構成する必要があります通貨。
これにより、プラットフォームの開発の早期段階でそれを定義しようとする試みよりも、マーケットプレイスのより柔軟な開発が可能になります。
このアーキテクチャの実装では、展開を容易にするために、1つ以上のテンプレート化または構成可能な通貨が提供されるはずです。
そのような実装は、採掘またはミントアルゴリズム、アドレス指定、ウォレット管理などを定義することができる。
さらに、実験やカスタマイズのためにできるだけユーザーが拡張する必要があります。

通貨モデリング
このアーキテクチャにより、ユーザーは通貨をモデル化し、設計の後半で収益を得ることができます。
ブロックチェーン上の多くのソースからの情報を配置し、時間の経過とともにその使用状況を監視し、ビジネスおよび顧客の優先順位に基づいて価値を判断することが可能です。
現時点では、資産や活動を収益化することができ、ビジネスの従業員、チーム、または顧客にインセンティブを与える鉱業または造幣アルゴリズムを開発することができます。
この定量化、収益化、インセンティブ化のプロセスは、無限の調整の1つであるかもしれませんが、透明な経済システムを提供します。
このフレームワークでは、データプロバイダが、通常、トップダウンを必要とするようなデータを表示しないプロジェクトに、研究データ、レポート、その他の情報を即時かつ早期にアクセスできるような組織で、機動性を提供する可能性があります高いコストとリスクで組織の承認を得ることができます。
そのようなデータの使用を追跡し、その価値を決定し、直接的な収益化とボトムアップの資金調達メカニズムにつなげることができます。

ビットコイン・アドレッシング
基本的な実装では、今後増加する外部Bitcoinエコシステムを活用するために、Bitcoinのアドレッシングと暗号化を利用することが予想されます(少なくとも近い将来)。
例えば、Bitcoin暗号を民間通貨で使用すると、内部使用のためにハードウェア署名ウォレット(例えば、KeepKey、Trezor、Ledger)を透過的に使用することができる。
もう1つの例はトークン化の例であり、内部ブロックチェーン(CounterpartyまたはTokenlyなど)で使用するBitcoinトークン化プロバイダテクノロジを直接統合することができます。

相互運用性
トランザクションクラスヘッダーフィールドを使用すると、外部の暗号化トランザクションをラップすることができます
プライベートなブロックチェーントランザクション内で実行されます。

スマート・コントラクト

ブロックチェーンに基づく「スマート契約」に関する多くの疑問が生じます…

完成度を上げる
このリストのトップはチューリング完全性です。 Bitcoinは意図的にチューリングが完了していません。
アプリケーションに必要な機能を提供するために必要なだけ複雑です。
Ethereumなどの一部のブロックチェーン実装では、チューリングが完了しています。
これにより、いくつかの非常に興味深いアプリケーションが可能になりますが、実装にはいくつかのリスクと困難が伴います。
特定の検証済みコンテナまたは仮想マシン内でスマートコントラクトを実行して、ノードが実行されているハードウェアまたはオペレーティングシステムに関係なく、確定的な結果を保証する必要があります。
スマートコントラクトの様々な態様は、失敗または予期しないまたは許可されていないアクションについて監視されなければならない(例えば、ループ)。

取引、アトミック、ロールバック
スマート・コントラクト・システムでは、あるレベルの制御または自動トランザクションおよびロールバック機能を提供して、トランザクション操作全体が正常に完了した場合にのみ所定のアクションが有効になるようにする必要があります。

ディストリビューション実行
スマート契約はどこで実行されていますか?それは分散(呼び出し)ノード上にありますか?

ドラゴンチェンスマートコントラクト
このアーキテクチャーは、レベル1のビジネス・ノードで構成またはデプロイされる「承認コンテキスト」コードの定義を要求します。
この承認コードはスマートな契約と見なすことができます。
デフォルトでは、このスマートコントラクトはそのレベル1のノードでのみ実行され、ビジネスオーナーの直接の管理下に置かれます。
これにより、スマートコントラクトを作成するための使い慣れたクライアント/サーバーインターフェイスが提供され、リスク評価が簡素化されます。
攻撃ベクトルは、より一般的であり、現代のエンジニアに知られている。
チューリングの完全性は、どのWebサービスプラットフォームと同様に提供されます。
スマートな契約はうまく配布され、プレイごとの支払い基準で実行される可能性があります。
この場合、上記のスマート契約のリスクの多くが当てはまりますが、当事者は組織内で信頼関係を結び、コードのプロビジョニングには必要な法的合意が含まれることが想定されます。
同様に、グループはITサポート事業としてスマート契約をホストし、チャージバック/支払いのためのさまざまな計画を提供することができます。
1:スマートコントラクトは、ノード上で以下の方法で使用することができる。
2:フォークされたコードベースでハードコードされる(システムに展開されたスマート契約コードで)
3:ブロックチェーンを介して配信されます(管理者はスマート契約、開始日などのマルチ署名トランザクションを送信します)

サブスクリプションデータフィード

コンセンサスプロセスでのブロードキャストに先立ってトランザクションのペイロードが削除されると、ノードはサブスクリプションデータフィードを介して必要に応じてビジネスデータを共有します。
これは、ノード・トランザクションのいくつかのサブセットが別のノードに連続的に供給されるプッシュまたはプル・メカニズムに相当します。
顧客にサービスするためにノードが別のノードのデータを自身のデータとマッシュアップする必要がある場合、そのノードはそのデータを所有する「起点ノード」からのアクセスを要求するように構成する。
この要求には、認証または認可情報が付属していてもよく、起点ノードは要求を承認または拒否できます。
また、要求ノードは、特定のトランザクションタイプのみ、ネットワーク上の一定レベルの検証を超えたトランザクション、または特定のアイデンティティのみを含むトランザクションなど、データフィードの基準を提供することもできる。
このようにして、要求側ノードは必要なデータだけのローカルキャッシュを持ち、データが変更されていないことを自信を持って顧客に返答することができます。未来。
起点ノードがそのデータを配布することを望む場合(すなわち、バックアップまたは災害復旧のために)、ノードは、そのようなサービスに対して支払いを行い、そのノードにデータを継続的にプッシュすることができる。
バックアップノードは、受信時および定期監査時にデータにエラーがないことを確認できます。

ネットワーク管理

ブロックチェーンネットワークシステムでは、プロビジョニング、発見、利用可能なノードや品質ノードのメンテナンスなど、多くの典型的な要素が必然的に存在します。
しかし、このアーキテクチャーは、ネットワークの構成とメンテナンスに関するいくつかの哲学的立場を取ります。
このアーキテクチャでは、ネットワークと通信の管理に関するすべての考慮事項は、個々のノードのコンテキストから行う必要があります。
接続すべきノードのような決定は、各ノードによって独立して行われる分散決定でなければならない。
エンタープライズ内のヒントや保証された使用可能なノードの開始リストの一元管理の仕組みがあるかもしれませんが、ネットワークの接続要件を集中化する試みは行われません。

データ配信
デフォルトでは、トランザクションペイロード(ビジネス)データは、起点(所有)ノードから離れず、ネットワーク全体に伝播する必要もありません。
コンセンサスおよびネットワーク通信の一環として、すべてのトランザクションペイロードは、ブロードキャストする前に削除されます。
起点ノードによって明示的に認可された場合にのみ、ペイロードと完全なトランザクションが許可されたノードにブロードキャストされる。

ノード発見
ノードの発見は、ピアツーピア要求を介して行われる必要があります。

ネットワークマーケットプレイス
重要:ノードが取引を照合する市場や通貨の概念は、システムインフラストラクチャではなく、ブロックチェーンネットワーク内のノード上のアドオン通貨の実装として実装する必要があります。
このように、アーキテクチャは柔軟性があり、新しいアイデアや予期しない要件に対応しています。

ノード品質評価
ノードは、接続されているか切断された個々のピアの品質を追跡して確認する必要があります。
現在接続されているピアと切断されているピアを別々に考えると、ノードは属性
といった:
接続の平均レイテンシ(定期的に評価)
署名成功率
再放送カウント
平均検証時間
配置場所(多様性基準のため)
所有者(多様性基準のため)
失敗した接続試行
最後の接続試行
コンテキストベースの検証のさらなるレベルを得る際のノードの成功
ノードは、接続ノードの定期的な評価を、切断されたノードよりも頻繁に行うべきであるが、合理的な範囲にわたって、ノードは、接続されたノードの大部分が利用不能になった場合にピア接続の優先順位を決定するために必要な情報を有するため、

確認の受け取り
より高いレベルの検証ノードへの検証レコードのブロードキャストは、成功または失敗を通知するレシートメッセージを提供し、成功した場合には、より高いレベルのノードによって署名された検証レコードを含むべきである。
この同じメカニズムは、起点ノードに到達するためにさらに線を通る必要があります。
それは設計上の考慮事項ですが、別のブロードキャストコールに対する非同期応答のようなものが、そのような機能を提供する適切なメカニズムである可能性があります。

実装オプション
カスタム(Apache Thriftなど)
RESTfulサービスコール
レプリケーションによる分散データベースフレームワーク

相互運用性と推奨規格

他のブロックチェーンシステムとの相互運用性の問題については、考慮すべき多くの手段があります。

チェック&ラッピング
チェックポイントを使用してトランザクションやその他のアーティファクトを接続することもできます
(上のレベル5 – パブリック・チェックポイントを参照)、またはDragonchainトランザクション内で外国トランザクションまたはアーティファクトをラップすることによって
(上記の外貨取引ヘッダを参照)。

SUBCONSENSUS
ビジネスは、検証プロセスのどのレベルでも、別のブロックチェーンを採用することを選択できます。
たとえば、分散型のレベル1承認の実装を提供するには、Bitcoinやその他の作業証明ベースのブロックチェーンを採用して、通貨取引のコンセンサスになることを選択できます。


いかがだったでしょうか?ブロックチェーンに詳しい方にとっては多少参考になると思います。

暗号通貨やブロックチェーンは聞き慣れない言葉や頭が痛くなることが多いですが暗号通貨歴の長い方はブロックチェーンを深く学習しホワイトペーパーや独自の判断材料を元に投資を行い成功を収めています。

日本ではいかんせんインフルエンサーの影響力が強く中身を判断せずに盲目的に参加する方が多いようですが中身を確認しインフルエンサーに惑わされないように投資判断を行なってください。

またドラゴンチェーンの公式?ツイッターには

Opinions are of the author and do not reflect the position of the Walt Disney Company.

意見は著者のものであり、ウォルト・ディズニー・カンパニーの地位を反映していません。

と書いてあります。ウォルトディズニーとどこまでの関係性があるのか紐解いて行く必要はありそうです。

ちなみにディズニーが行なっているオープンソースプロジェクトはこちらです。

 →https://disney.github.io/

(こちらでもちゃんとドラゴンチェーンは掲載されております。)

 →DragonChainICO情報はこちら


2 comments

最新情報&掲示板

メールアドレスが公開されることはありません。