フレームワーク：DLTシステムの分析

この作業は、分析されたオブジェクトがDLTシステムであるかどうかを判断することを目的としています。 得られた結果は、管理構造からトランザクションが参照するリンクの定義まで、さまざまなプロジェクトの比較分析に適しています。

分散台帳技術は情報ストレージ技術であり、その主な特徴は、コンセンサスアルゴリズムに基づくデジタルデータの共有と同期、世界中のさまざまなポイントでの同等のコピーの地理的分布、中央管理者の不在です。

テクニカル分析

プロトコルレベル

創世記

プロトコルレベル。ネットワークを開始する前に開発および実行する必要があるプロセスを指します。

他のネットワークへの依存。

他のプロトコルへの依存は、分析されたプロジェクトの境界に依存します。 これにより、システムが独立したシステムとして動作できるか（自給自足するため）、別のネットワークに依存しているかが決まります。

表1.他のシステムへの依存



プログラムコード

コードは、既存のフレームワークに基づいて作成することも、ゼロから作成することもできます。 最も一般的なフレームワークは、オープンソースシステム（ビットコイン/イーサリアム）のコードベースです。 また、Digital Asset / ClearmaticsやSETLなどのプロジェクトによって提供されるクローズドプラットフォーム用のクローズドソースデータベースもあります。

表2.プログラムコード



ルールの定義

ルールの導入とは、DLTシステムが動作する一連のルールの定義を指します。 このプロセスは、さまざまな参加者が実行でき、特定のDLTシステムに対して個別です。

プロトコル更新

プロトコルの更新は、システムルールを変更できる既存のプロセスに適用されます。 プロトコルの更新には、技術的なエラー（バグ）の排除、システムのセキュリティと機能の改善、および既存のプロトコルルールの拡張または制限が含まれます。

プロトコル管理

プロトコル管理とは、プロトコルを規則的かつ合法的に変更できる一連の意思決定プロセスを指します。 これは、より広範なプロジェクト管理のサブセットであり、調整とアクションを記述および定義するプロセスと規範の完全なセットを含みますが、DLTシステムに正式に統合することはできません。

プロトコルへの提案された変更の重要な要素は、それが採用され批准される方法、つまり、ネットワークメンバーの提案で正当性が提供される方法です。 この文脈での正当性は社会的概念であるため、DLTシステムで見られる「社会政治的」関係のいくつかを特定することが適切であると思われます。

表3.プロトコル管理



プロトコル管理には多くの形式があり、多くの場合不明確です。 当初、DLTシステムはアナキストの力（無料）によって特徴付けられ、意思決定を担当する企業やグループはありません。 何よりも、それらはオープンソースのトラフィック管理プロセスに似ています。 プロトコルの変更に関する議論の例として、チャット/ GitHub /会議での開発者のコ​​ミュニケーションがあります。 独裁的な条件の下では、変更を議論するプロセスはまったく同じかもしれませんが、最終的な決定は一人によって行われます。 場合によっては、プロトコル管理フォームは複数のタイプのボードで定義できます。 たとえば、EOSブロックチェーンは、EOS資産を所有するユーザーによって選択されるブロックメーカーの連合として機能します。 投票の重みは、アドレスに保持されているトークンの数によって決まります。 このタイプの政府は、プロトコルを「エリート」ユーザーと「通常の」ユーザーの2つのパーティに分割し、階層システムの特性を引き継ぎます。それは、連合、民主主義、および金権制です。

オンチェーン管理は、データレベルで管理機能を含めることを意味します。 目標は、ガバナンスを形式化し、それによって正当性を高め、紛争または矛盾したプロトコル更新によるネットワークの断片化を回避することです。 コミュニティムードバロメーターから国民投票まで、DLTシステム用の多様な一連のオンチェーン投票スキームが開発されています。 ただし、オンチェーン管理機能は、原則として、他の管理形態への追加にすぎません。

プロトコル変更

プロトコルを更新する実際のプロセスは、次のことを意味します。

1. GitHubがオープンソースプロジェクトである場合、GitHubのコードを更新します。
2. クローズドソースプロトコルの場合、クライアントの更新。
3. 古いプログラムコードで作業しているクライアントは、無関係でブラックリストに登録されていると見なされる場合があります。
4. 古いプログラムコードで作業しているクライアントは分岐を形成し、プロトコルの代替バージョンの作成につながります。

表4.プロトコル変更フォーム



異なるDLTシステムは、異なる方法を使用してネットワークを更新します。 たとえば、イーサリアムは開発資金への寄付を受け入れ、助成金によって資金提供された開発者からのソフトウェアを使用してネットワークを更新します。

ネットワークレベル

DLTプロトコルネットワークは、プロトコルルールの実装の直接的な結果です。 ネットワークは、技術標準（プロトコル）に準拠し、特定の通信チャネルを介したデータと情報の交換に積極的に参加する参加者とプロセスの適切に調整された作業で構成されます。

通信プロセス

DLTシステムの参加者間でデータを転送するプロセス。

ネットワークアクセス

ネットワークへのアクセスは、プロトコルへの接続の可能性を意味し、制限されている場合もあれば、無制限の場合もあります。

• 無制限のアクセス -すべてのユーザーがいつでも自由に接続/切断できます。
• 制限付きアクセス -特定のユーザーのみがネットワークに接続できます。通常、これは指定されたエンティティによって制御されます。

原則として、無制限のアクセスを備えたシステムでは参加者の数に制限はありませんが、閉じたネットワークでは限られた数の参加者を確立できます。

通常、参加者はフルノードを起動してネットワークに直接アクセスします。参加者は、記録データを送信/検証および転送できるため、多数の権限を持つ「エリート」と見なされます。 ネットワーク参加者は、特別なサービス（API）を介して接続することにより、完全なノードからデータを要求する「ライトクライアント」を起動することにより、ネットワークへの間接アクセスも取得できます。

表5.ネットワークアクセスフォーム



原則として、システムを開くほど、攻撃を受けやすくなります。 特に、これらのシステムはSibyl攻撃に対して脆弱です。攻撃者が多くの偽のIDを作成して、ネットワークへの影響を増加させる場合です。

Sibyl攻撃は、攻撃者がアクセスを取得したり、プロトコルの変更を隠したりする攻撃の一種であり、多くの偽のIDを作成します。

識別は外因性の（つまり「実際の」）プロパティであるため、DLTシステムは攻撃データを防ぐことができず、外部の参加者（認証システム）または攻撃の可能性を減らすメカニズム（PoW / PoS）に依存する必要があります。

データを送信する

データ転送は、接続されたノードにデータを配布するプロセスです。 データは、未加工/フォーマットされていないか、特定の形式に標準化されている場合があります（たとえば、トランザクションまたはレコードの形式で）。 データは各ノードに送信されるか（ユニバーサル拡散）、またはノードの特定のサブセットにのみ送信されます（マルチチャネル拡散）。 後者の場合、データの配布は通常、トランザクションの参加者に限定されます。 これにより、データ転送用の「チャネル」を作成できます。通常、これはシャーディング/ Lightningネットワークを意味します。

初期のDLTシステム（ビットコイン、ライトコインなど）は、最も一般的なデータ配信方法である汎用データ配信モデルを使用しています。

企業の匿名性とプライバシーを維持するために、後のシステムではマルチチャネル拡散モデルが実装されています（たとえば、Hyperledger Fabric、Corda）。 Cosmosなどの他のシステムはハブとして機能するように設計されているため、シャーディングを介して独立したDLTシステムを相互接続できます。

表6.データ送信フォーム



マルチチャネルデータ拡散の例は、すべてのネットワーク参加者がチャネルの状態に関するコンセンサスに参加する必要がないことです。チャネル参加者のみが、このチャネルに格納されたデータの一貫性を達成する必要があります（「ローカル」コンセンサス）。 これは、個々のノードがシステムのグローバル状態に関するコンセンサス（「グローバル」コンセンサス）に到達する必要があるため、グローバルデータ拡散のあるシステムとは大きく異なります。 一部のノードのコンセンサスに達することができないと、それらの接続が切断されるか、フォークが作成される可能性があります。

トランザクションの作成

トランザクション作成プロセスには、トランザクションがネットワークに追加された後に実行される一連の命令が含まれています。 トランザクションの作成は、無制限（つまり、すべてにアクセス可能）にすることも、一部の参加者に制限することもできます。 トランザクションは、ユーザーが秘密鍵でメッセージに署名することにより作成されます。 ユーザーは、トランザクションを作成してネットワークに送信するためのさまざまなインターフェイスを使用できます（PCやモバイルウォレットなど）。

トランザクション処理

トランザクション処理では、未確認のトランザクションを確認済みのリストに追加するために必要な一連のアクションについて説明します。 トランザクションは、リストに追加（「確認」）された後（予備）有効と見なされ、トランザクションに埋め込まれた命令の実行につながります。 ただし、このトランザクションが後続の操作の基礎になるには、確認だけでは不十分です。 トランザクション出力をシステムで使用する前に。

図1. DLTシステムでのトランザクション処理



レコードは、DLTシステムで使用される特定のコンセンサスアルゴリズムに従います。 これには、提案されたレコードが有効かどうかを判断するプロセス、無効なエントリ（たとえば、欠陥または互換性のないエントリ）を拒否し、異なるが同等に有効なエントリを選択するプロセスが含まれます。

記録候補

将来、確認済みトランザクションのリストに移動できるレコードは、ブロックの作成者によって送信されます。ブロックの作成者は、未確認トランザクションのリストからそれらを選択し、それらを組み合わせて確認済みレコードのリストに書き込む候補を形成します。 レコードを送信する権利と、そのレコードを確認済みレコードのリストに含めるかどうかを決定する2つのプロパティがあります。

表7.レコードフォーム



レコードはコンセンサスの対象であるため、プロトコルルールを遵守する必要があります。 まず、それらは正しくフォーマットされていて、無効または無効なトランザクションが含まれていない必要があります。 さらに、各エントリには前のエントリへのリンク/ポインタを含める必要があり、必要に応じて、PoWまたはSibyl攻撃の実行を困難にする他の方法を使用する必要があります。

コンセンサスアルゴリズムは、その複雑さのレベル（電気/金銭的コスト）に従って分類できます。 複雑さのレベルが無制限のアルゴリズムは、コンセンサスに達するために必要なリソースで測定されます。 たとえば、PoW Bitcoinを計算する場合、データをハッシュする複雑さが増すにつれて、適切なソリューションを見つけるのが難しくなります。 それどころか、他のアルゴリズム（たとえば、ビザンチン将軍/ BFTタスク）は、大きな計算コストを必要とせず、複雑さが制限されています。

オープンシステムでは、Sybil攻撃の可能性を減らすアルゴリズムを提供する必要があります。 プライベート（クローズド）システムは、ネットワーク接続へのアクセスを許可する前に各参加者をチェックし、攻撃の可能性を防ぎます。 閉じたシステムでは、ノードのグループは通常、ブロックを作成する単一のノードを選択する傾向があります。

紛争解決

競合は、いくつかの理由で発生する可能性があります。

1. 参加者は、プロトコルのどのバージョンが関連するかについて意見が一致しません。
2. 参加者は検証済みのトランザクションに同意しません。

ビットコインネットワークの最初のポイントの状況の場合、ネットワークはブロックの最も長いチェーンを有効として選択し、短いブロックを無視します。 Tezosでは、ブロックの有効性は異なる「ブロックの重み」で決定されます。ここでの重みは、スタッカーからランダムに受け取るバリデーターからの「承認」の数です。

コンセンサスアルゴリズムには多くのトレードオフがあります

表7.トランザクション処理の動機付けの形式



検証

検証とは、承認された一連の記録に関して、被験者が独立して同じ結論に達することを保証するために必要な一連のプロセスを指します。 これには、送信されたトランザクションのチェック/記録されたデータのチェック/ネットワークの一般的なステータスのチェックが含まれます。 これは、参加者がシステムの独立した監査を実施する機会を提供するため、非DLTシステムとの重要な違いです。

トランザクション検証

トランザクションを検証することは、個々のレコードが他のエンティティに転送する前にプロトコルルールに準拠していることを確認することです。 これには、トランザクション形式の正確性、適切な署名の存在、およびトランザクションが他と競合しないという条件が含まれます。 一部のシステムは、特定の時点または別の理由までトランザクションを禁止するシステムを運用する場合があります。 通常、このような条件はスマートコントラクトによって満たされます。

51％の攻撃とは、参加者または複数の参加者がコンピューティングパワー（音声）を組み合わせて、ネットワーク上のトランザクションを他のプロトコルよりも速く処理する場合です。 このような攻撃により、無効なトランザクションを実行し、有効なトランザクションとして記録することができます。 特に脆弱なのは、PoWを使用するシステムです

レコードを確認する

送信されるレコードをチェックすると、レコードがプロトコルルールに準拠していることを確認できます。 提案されたエントリが有効であると認識された場合、確認済みエントリのリストに追加され、ネットワーク内のすべての接続ノードに中継されます。 このプロセスはシステムごとに異なりますが、原則として、原則として、トランザクションでPoW作業が実行されていることを確認するなど、どこでも似ています。 送信されたトランザクションの検証と検証者によるその後の記録の組み合わせにより、システム全体の独立した監査が提供されます。

取引記録

確認済みのトランザクション/レコードは、必ずしも元に戻すことができません。 書き込み不可逆性は確率的（たとえば、記録されたすべてのトランザクションを再計算するのが実用的ではないPoWベースのシステム）、または各トランザクションに割り当てる必要のある「コントロールポイント」を含むシステムです。 確認済みのレコードは不変と呼ばれる場合がありますが、「事前確認済み」のレコードはキャンセルされる場合があります。 事前確認済みレコードは、「事前確認済み」から「確認済み」への移行状態を克服した後、変更されません。

図2. DLTシステムでのトランザクション処理



図2は、トランザクション処理中に発生するプロセスの概略説明を示しています。 まず、ユーザーはトランザクションを作成し、ネットワークに送信します。 各ノードは、トランザクションがプロトコルルールに準拠しているかどうかを確認します。 正しいと見なされると、ノードはトランザクションをそのリスト（mempool）に追加します。このリストには、未確認のトランザクションがすべて格納され、確認済みのトランザクションのリストに追加されるのを待ちます。

トランザクション処理の段階で、ノードはmempoolから未確認のトランザクションをランダムに選択し、それらを「事前承認済み」のトランザクションのリストに結合します。 次に、コンセンサスアルゴリズムに従ってトランザクションがチェックされ、これらのトランザクションが他のすべてのネットワーク参加者に提供されます。 ノードは受信したトランザクションとその内容を表示します;トランザクションが検証に合格すると、トランザクションはノードのリストに追加されます。 各ノードのトランザクションのリストは、最終的に確認済みトランザクションの単一の最も重要なリストに送信され、完了したと見なされます。

ただし、確認済みのトランザクションは代替トランザクションにより「キャンセル」できます。つまり、決済段階でトランザクションをキャンセルできます。この場合、トランザクションの新しいリストの作成を待機して、未確認のトランザクションとしてノードに戻ります。 「決済」段階でのトランザクション処理時間は、単一システムの設定に依存します。 一部のシステムはトランザクションとその取消不能の即時記録を実装しますが、一部のプロトコルは、トランザクションを理論的にキャンセルできるという意味で「確率的」に完了します。 ただし、実際には、PoWに関連付けられたノードのコストが高くなる可能性があるため、新しいトランザクションが追加されるたびにこのアクションの可能性は低下します。 トランザクションは「決済」段階にありますが、「完了」と見なすことはできません。 トランザクション決済プロセスは、トランザクションがローカルノードだけに保存​​されるのではなく、参加しているすべてのノードに正確にリストされるという保証を強化します。これにより、二重支出攻撃を防ぐことができます。

一部のシステムは、長距離攻撃の可能性を制限するために「チェックポイント」システムを実装しています。 この攻撃の場合、ノードはパーソナルトランザクション（それだけが保存する）を使用して代替チェーンを作成します。これらのトランザクションはネットワークに表示されませんが、「決済」段階ですぐにノードに送信され、他のノードがローカルトランザクションに置き換えられます。 チェックポイントは、元に戻されたり置き換えられたりしないブロックです。 コントロールポイントの結果として、攻撃の「範囲」が縮小されます。 ただし、マイルストーンはフォークのリスクを高めます。

表8.確認済みのトランザクションプロパティ

データレベル

プロトコルレベルは、システムの動作方法と従うルールを決定します。 ネットワーク層は、プロトコルの基本原則を実装します。 プロトコル層とネットワークはともに、データ層の基盤を形成します。データ層は、トランザクションが確認済みレコードのリストに書き込まれるにつれて蓄積されます。

運営

運用コンポーネントには、参加者がシステムと対話するためのすべてのプロセスが含まれます。

データソース

入力プロセスは、プロトコルのデータを取得するソースまたは方法に関連しています。 データソースは内部または外部であり、ユーザーとシステムとのアクティブな対話、内部システムプロセスによって引き起こされた、または外部から受信したプロトコル状態の変化（たとえば、別のプロトコルから送信されたトランザクション）、またはスマートコントラクトを反映できます。

内部入力ソースは、ユーザーが作成したレコードまたはトランザクション、またはユーザーがプロトコルと対話した結果として定義されます。 一方、外部入力ソースは、プロトコルと相互作用する他のシステムからの入力の結果ですが、原則として、基盤となるプラットフォームから分離されています（つまり、依存または相互作用しています）。 ハイブリッドプロトコルを使用すると、ユーザーはいつでも「支払いチャネル-状態チャネル」を使用してトランザクションを転送できますが、これらのメソッドの開発はまだ初期段階です。

表9.データ入力フォーム



ソフトウェア実行可能トランザクション

すべてのデータレベルの変更が、内部または外部入力の直接的な結果であるとは限りません。 コード命令の実行により、システムにいくつかの変更が発生します。 顕著な例は、スマートコントラクトです。 埋め込みプログラムコードを実行すると、プロトコルのネットワークステータスが変化します。たとえば、トランザクションが発生し、確認済みのリストに記録されます。 一部のDLTシステムは、スクリプト言語（スクリプト）のみをサポートしています。 たとえば、Bitcoin Scriptは、限られたシンプルなプログラムを作成できるシンプルなスクリプト言語で動作します。 このようなシステムは、ステートレスと呼ばれます。 Ethereum（Solidity）、Tezos（Michelson）、およびEOS（WebAssembly）-これらのシステムは、複雑なスマートコントラクトを開発するためのチューリング完全なプログラミング言語をサポートしますが、BitcoinとMoneroは、限られた操作を可能にするスクリプト言語を使用します。

表10.ソフトウェアトランザクションプロパティ



計算の実際の実行

プログラムが実行される場所によって、計算が行われる場所が決まります。 原則として、実行場所はネットワーク内-オンチェーンまたはオフチェーン（ネットワーク外）です。 チェーン上の計算は各ノードで実行されます。 この環境は、スクリプト言語としての単純な仮想マシンとは異なり、チューリング完全プログラムの実行を保証する複雑なもの（EVM-Ethereum仮想マシン）である場合があります。 オンチェーンのスマートコントラクトは、ネットワーク内の各ノードによって起動されるため、多くの場合「自己実行」と呼ばれます。

オフチェーンコンピューティングは、プロトコルの外部の環境で実行されます。 プログラムコードを実行するイベントはチェーン上で発生し、計算はメインネットワークをロードせずに別のシステムで行われます。 また、アプリケーションを起動するためのハイブリッド（ハイブリッド）システムがあります。たとえば、Ethereumのプラズマです。 または、たとえば、メインネットワークが「中心」として機能するが、計算自体は補助ネットワークで行われるCosmos。

表11.ソフトウェアトランザクション実行プロパティ

ログコンポーネント

参照資料

ユーザーがDLTシステムとの対話を開始した瞬間から、ログは時間とともに更新されます。 ただし、雑誌は抽象概念です。 DLTシステムで発生するすべてのプロセスは、特定のプロトコルに関連しています。 たとえば、電子支払いに焦点を当てたプロトコルには、特定のユーザーが所有する資産に関する情報を含める必要があります。 一方、スマートコントラクトを含むDLTシステムには、プログラムコードの実行を実装する独自の仮想マシンが必要です。 したがって、雑誌の概念は抽象化です。

リンクの種類

入力データには、内生データ、外生データ、ハイブリッドデータ、自己参照データの4種類があります。

内因性（内部）リンクは、システムに「ネイティブ」な変数に関する情報を追跡するデータに関連しています。 たとえば、ビットコインでは、1つの内生参照変数を使用して、特定の時間にユーザーが持っているビットコインの数を追跡します。 この内部変数は、ユーザーが他のアドレスとビットコインを送受信すると更新されます。 外因性（外部）リンクは、システムの外部に存在する変数に関する情報を追跡するデータを指します。 ハイブリッド参照とは、内因性と外因性の両方の特性を持つデータを指します。 内因性でも外因性でもない、ハイブリッドではない4番目のタイプがまだあります。それはニュートラルまたは空のデータタイプであり、自己参照リンクです。 たとえば、スマートコントラクトは、特定の条件が満たされたときに実行できる単なるコードです。 スマートコントラクトには外部または内部システム変数に関する情報が必要な場合がありますが、コード自体には、外部の何かへの内部リンク（「空白リンク」）がありません。

表12.リンクのタイプとその意味

おわりに

この作業は、分析されたオブジェクトがDLTシステムであるかどうかを判断することを目的としています。 得られた結果は、管理構造からトランザクションが参照するリンクの定義まで、さまざまなプロジェクトの比較分析に適しています。