出典: アンバー・グループ
最初のレベルのタイトル
「DAG」とは一体何を意味するのでしょうか？
「DAG」は「Directed Acyclic Graph」の略称です。コンピューター サイエンスに馴染みのない人にとって、これは一口になるほどの用語になるかもしれないので、次のように各単語について詳しく説明します。
- 有向: このデータ構造のデータは一方向にのみ送信されます。
・アサイクリック（acyclic）：データ構造上、現在の状態から前の状態に戻ることが不可能、つまり「アサイクリック」
- グラフ: データ構造の視覚化では、構造が複数の頂点間の相互関係のセットとして表示されます。
DAG 構造は正確にはどのようなものですか?データ構造が DAG であるかブロックチェーンであるかを判断するには、データの順序を確認することが最善の方法です。このソート方法は、トランザクションをタイムリーにソートする方法を指します。私たちは時間が直線的であると理解しているため、出来事が特定の順序で起こっていると考えることがよくあります。人間は時間の概念に同意しているため、出来事は順番に起こるということに同意します。
上図は「全シーケンス」の例です。どのイベントが最初に発生するかが決まると、すべてのイベントに正確な順序が設定されます。イベントの合計順序では、各イベントが合計順序のどの位置にあるかを正確に知っています。図に示すように合計順序を使用する場合、イベント A が最初に発生し、次にイベント B、イベント C の順に発生します。これが、イベントがブロックチェーンに記録される方法です。
ただし、分散台帳の全体的な順序により、スループットと遅延の点でスケーラビリティが制限される可能性があります。問題の一部は、「部分順序」台帳によって解決できます。部分的な順序では、他のすべてのイベントに対する各イベントの正確な順序は不明です。代わりに、関連するイベントのシーケンスのみがわかっています。すべてのイベントの順序はわかりませんが、相互依存するイベントの順序を判断することはできます。
たとえば、イベント B がイベント C の前に発生したと判断できます。ただし、部分的に順序付けされたシステムでは、イベント A がいつ発生するかはわかりません。イベント A は、これらのイベントの前、後、またはイベントの間に発生する可能性があります。イベント A は他のイベントとは何の関係もありません。
一般に、これらのトランザクションがどのように順序付けられるかを知りたいのはなぜでしょうか?それは、ある出来事がどのようにして別の出来事を引き起こしたのかを知りたいからです。部分順序には時間の概念がありません。では、各イベントがいつ発生したかを知らずに、どうやってイベントを並べ替えるのでしょうか?
この問題を解決するのが「因果的順序付け」です。因果的順序付けは、イベントの発生時刻を考慮せず、イベント間の因果関係のみを考慮する部分的な順序付けです。どのイベントが他のイベントを引き起こしたかを判断できる限り、これらのイベントを順序付けることができます。
上の図は因果関係の例です。上の画像のイベントにはタイムスタンプが付けられていないため、これらのイベントがいつ発生したかを正確に判断することは不可能です。ただし、A によって B が発生し、B によって C と E が発生することがわかります。そして、A が最終的に D と F を発生させると結論付けることができます。 C は D を引き起こし、E は F を引き起こすため、C と D、および E と F の因果順序を決定できます。ただし、C と E、または C と F の順序や、C または D に対する E の順序を決定する必要はありません。すべてのイベントが部分的に順序付けされており、互いに因果関係があるわけではありませんが、無関係なイベントを相互に相対的に順序付ける必要はないため、問題はありません。
因果的順序を使用することで、「イベントの連鎖」のような構造に制限されなくなり、DAG 構造を構築できるようになります。互いに何の関係もないイベントを並べ替える必要はまったくありません。因果関係のあるトランザクションの分散台帳構造は DAG ですが、全順序の台帳構造はブロックチェーンです。因果的順序付けにより、特定のトランザクションが順序付けを完全にスキップできるため、DAG ベースの台帳には、ブロックチェーン ベースの台帳と比較して、スループットとレイテンシの点でスケーラビリティの利点があります。
最初のレベルのタイトル
副題
完全に順序付けされたブロックチェーンは DAG をどのように使用しますか?
文章
Fantom: DAG テクノロジーを使用したゴシップ プロトコルに基づくブロックチェーン
画像の説明
高レベルでは、ノードは DAG を形成するイベント ブロックを作成します。 Fantom はこのイベント ブロックの DAG を使用して、ブロックチェーン (確認されたブロックのチェーン) を生成します。
Fantom は、財務情報、技術情報、その他の情報を含むデータをイベント ブロックに保存します。イベント ブロックは、ネットワーク全体でトランザクションとユーザー情報を共有するために単一ノードによって作成されるデータ構造です。上の図では、DAG 構造が示されており、円はノードを表し、イベント ブロックはノードによって生成されます。上図には示されていませんが、実際には各ノードがイベントブロックを生成しています。ノードがトランザクション情報を交換するたびに、新しい共有イベント ブロックが作成されます。イベント ブロックはネットワーク全体で共有されます。イベント ブロックが別のイベント ブロックと通信すると、通信されたイベント ブロックは前のイベント ブロックのトランザクション情報を保存し、新しいイベント ブロックを作成します。この情報は次のイベント ブロックに渡されます。トランザクション情報はハッシュ化されており、各イベント ブロックには 1 つ以上の前のイベント ブロックのハッシュ値が含まれています。これにより、ハッシュを変更せずに以前のイベント ブロックを変更または削除できないため、データが不変になります。
上の図に示すように、Opera チェーンの DAG 構造の緑色の領域はイベント ブロックであり、「Clotho」ブロックと呼ばれるイベント ブロック (上の図の青いブロック) が見つかるまで相互に通信します。 。 Clotho ブロックには、特定のイベントのブロック間のすべての接続データを保持するデータ構造である「タグ テーブル」が含まれています。 Clotho ブロックとみなされるには、Clotho は以前に設定されたイベント ブロックに対して 2/3 以上の超多数派の接続を持っている必要があります。 Clotho ブロックは、タグ テーブル データ構造を通じて DAG 構造内の他の Clotho ブロックと通信します。
相互間の通信情報に基づいて、Clotho ブロックは合意に達し、「Atropos」ブロック (上図の緑色のブロック) と呼ばれる別のイベント ブロックを作成します。各Clothoブロックには、作成時に特定のタイムスタンプが付けられます。すべてのノードの少なくとも 2/3 が同じノード時間を持っている場合、Clotho ブロックは Atropos ブロックになります。これらの Atropos ブロックは互いに連鎖して「主鎖」を形成します。メインチェーンは、DAG 構造におけるブロックチェーンとみなすことができます。各 Atropos ブロックは他の Atropos ブロックに接続され、Clothos ブロックから収集された情報を共有し、その後、Clothos ブロックは他のすべてのイベント ブロックから情報を取得します。
このメイン チェーンには、すべてのイベントの合計順序が含まれます。参加しているすべてのノードはメイン チェーンのコピーを持っており、Lachesis コンセンサス プロトコル内のブロックの過去の位置を検索できます。ノードは各イベント ブロックのすべての情報を保存する必要はなく、メイン チェーンを参照するだけで十分です。これにより、システムは以前のイベントに迅速にアクセスできるようになります。
最初のレベルのタイトル
因果的に順序付けされた出力を備えた DAG
ほとんどの人が「DAG」と呼ぶものは、実際には因果的に順序付けされた分散台帳です。これらの DAG はどのように機能するのでしょうか?また、相対的な合計順序との違いは何ですか? Avalanche の X-Chain、IOTA、Sui は、因果的順序付けを備えた分散台帳の例です。
Avalanche X-Chain、UTXO ベースの DAG。
ビットコインは、ウォレット間の送金ステータスを記録するために未使用トランザクション出力 (UTXO) モデルを導入しました。各 UTXO は所有権の連鎖であり、所有者は UTXO の所有権を新しい所有者のアドレスに移転するトランザクションに署名します。 UTXO の文脈では、ビットコインはブロックチェーンとして説明され、Avalanche の X チェーンは DAG として説明される必要があります。 X-Chain は、因果順序の Avalanche コンセンサス プロトコルを使用します。 AVAX を誰かに送信するときは、X-Chain を使用します。 Avalanche の DAG がどのように機能するかを理解するには、まず Avalanche の DAG 構造がどのように形成されるかを知る必要があります。
Avalanche コンセンサスは、Slush、Snowflake、Snowball、Avalanche の 4 つの主要フェーズに分かれています。 Avalanche コンセンサスの最終段階に相当するのは Snowman コンセンサスです。これについては後で説明します。まず、Slush コンセンサスがどのように機能するかを見てみましょう。 Avalanche ネットワークは多くのノードで構成されます。各ノードには、ステートレス、true、および false の 3 つの状態があります。以下では、より直感的に表現するために、無色、青、赤の色を使用します。
各ノードは最初は無色であり、そこで真か偽 (青か赤) を決定する投票に直面します。色が選択されると、ノードはネットワーク内の他の多数のノードと通信します。これらのノードにまだ色がない場合は、ノードと同じ色になります。大多数のノードが同じ色を持っている場合、元のノードがその投票を保持します。大多数のノードが異なる色である場合、元のノードはその色への投票を反転します。
すべてのノードが合意に達するまで、ノード間で複数回の通信が行われます。目標は、各ノードが一貫した色を形成するようにすることです。ノードが特定の色に傾くと、その傾きが強化され、正しい結果がその色に向けられます。このコンセプトは、Avalanche が構築され、すべてがその上に構築される基盤です。
Avalanche の 2 番目の構成要素は Snowflake プロトコルです。各ノードは、ノードがメモリをインポートするときにカウンターを持ちます。 Slush プロトコル通信が同じ色を返すたびに、カウンタは 1 ずつ増加します。そして、ノード反転結果が異なる色を返すたびに、カウンターはリセットされます。カウンタが十分な数に達すると、その状態がロックされ、ノードの色が変更されなくなります。これは、本来の色を定着させるのに役立ちます。
Snowball プロトコルの第 3 フェーズでは、ノードはより大きなメモリで値を記録します。 Snowball プロトコルは、Snowflake プロトコルに信頼性を追加します。 Snowflake プロトコルのノードは、通信する他のノードに基づいて色を変更するのではなく、自身のすべての色の変更履歴を確認し、ノードの信頼状態に基づいて色を変更します。これには、ノードの投票変更履歴データが考慮されます。
上記のすべての段階は、最終的に Avalanche プロトコルにつながります。 Avalanche は、追加専用 (前のトランザクションにトランザクションを追加する) DAG 構造です。 Avalanche は、コントラクト チェーン (C チェーン) およびプラットフォーム チェーン (P チェーン) 上の Avalanche の線形構造の場合と同様、DAG 構造なしで実行することもできます。 Avalanche コンセンサスの開発チームである Team Rocket は、DAG アーキテクチャの各トランザクションの投票が追加されるすべてのトランザクションにリンクされているため、DAG アーキテクチャがブロックチェーンよりも優れていると考えており、DAG 投票メカニズムの方が効率的です。
Avalanche コンセンサスは、すべての既知のトランザクションの動的な DAG を構築するための複数の Snowball イベントで構成されます。各 Snowball イベントはグラフの頂点です。頂点は、線形ブロックチェーンのブロックのようなものです。これには、親のハッシュとトランザクションのリストが含まれています。 Avalanche コンセンサスは Snowball に基づいており、信頼性の概念は依然として有効ですが、DAG の各ノードに適用されます。前述の赤青の決定とは異なり、Avalanche コンセンサスのノードは、トランザクションが正しいか、他のトランザクションと競合していないかを判断し、相互に合意に達します。すべてのトランザクションは親トランザクションにリンクされ、すべての親トランザクションはジェネシス頂点にリンクされます。トランザクションにはサブトランザクションを含めることができ、サブトランザクションはすべての親トランザクションにリンクされます。 Avalanche では、他のすべてのトランザクションの基礎となるトランザクションが必要であるため、ジェネシス頂点が必要です (IOTA にもジェネシス頂点があります)。追加操作のみをサポートするトランザクションには追加本体が必要であるため、ジェネシス頂点は重要です。ただし、Snowball をノードで構成される DAG に直接適用すると、トランザクションの競合や二重支払いなどの未解決の問題が発生します。そこで、Avalanche は Snowball に「チット」の概念を追加しました。信頼度がしきい値に達すると、chit と呼ばれるカウンターが値「1」でトランザクションに追加されます。割り当てられていない場合、伝票カウンタは「0」になります。このノードは、Snowball の信頼度と同様に、追加の信頼度設定として伝票値を合計します。次に、ノードは伝票の合計を使用して、トランザクションとそのすべての子トランザクション (ノードに追加された新しいトランザクション) の信頼性を判断します。
Avalanche は、Slush、Snowflake、Snowball を統合し、線形チェーンに調整できます。これは、Avalanche コンセンサスと並行して Snowman コンセンサスに対しても行われますが、これはまったく異なります。 Avalanche の UTXO モデルとは異なり、Snowman コンセンサスはアカウントベースです。 Snowman コンセンサスは、Avalanche ネットワークのプラットフォーム チェーン (P チェーン) とコントラクト チェーン (C チェーン) に使用されます。プロトコルは上記と同じように機能しますが、各頂点には複数の親ではなく 1 つの親しかありません。したがって、すべての頂点が全体的な順序を形成します。これにより、全体の構造が DAG ではなくブロックチェーンとしてレンダリングされます。これは、トランザクションの順序を知る必要があるアプリケーションに役立ち、Snowman コンセンサスはスマート コントラクトもサポートしています。
Avalanche コンセンサス プロトコルは通貨送金に驚くほどうまく機能し、他のさまざまなプロトコルにも適用できます。 Avalanche は、独自のプロジェクトである Bitcoin ABC へのハードフォークの前に、Bitcoin Cash の事前コンセンサス メカニズムとして使用されました。 Avalanche の DAG 構造はトランザクション速度を向上させます。また、ビットコイン キャッシュはスマート コントラクトを必要としないため、DAG がスマート コントラクトと互換性がないという欠陥はこれに影響しません。決済分野では、Avalanche はスマート コントラクトの必要性を無視することができ、DAG ベースの台帳がどのように機能をより効果的に拡張できるかのみを強調しています。
IOTA、Proof-of-Workを使用したトランザクションベースのDAG
IOTA の因果的順序構造は Tangle と呼ばれ、トランザクションを並列処理するネットワークです。 Tangle は、IOTA が DAG を形成するデータ構造です。 IOTA のタングルはトランザクションで構成されており、各トランザクションはグラフの頂点として表されます。新しいトランザクションが Tangle に参加すると、承認のために以前の 2 つのトランザクションが選択され、グラフに 2 つの新しいリンクが追加されます。
以下の図では、トランザクション G がトランザクション E と F を承認します。トランザクションには、「アリスはボブに 10 個の IOTA コインを与えました」などの情報が含まれます。承認されていない取引は「チップ」と呼ばれます。トランザクション G はまだ承認されていないため、ヒントとなります。新しく追加された各トランザクションは、2 つの保留中のヒントにリンクされる必要があります。ヒントの選択に役立つ戦略はいくつかありますが、最も簡単なのは、承認するヒントを 2 つランダムに選択することです。承認用のヒントを選択するプロセスは、新しいトランザクションに対して非常に拡張性があります。
赤色のトランザクション I および G は、他のトランザクションにリンクされていないため、未承認のヒントです。各トランザクションには他のトランザクションがリンクされているため、他のすべてのトランザクションはすでに承認されています。
同時に、IOTA は、IOTA DAG アーキテクチャを強化するための重要な概念であるウェイトを導入しました。取引が信頼できるものであるかどうかをどうやって知ることができるのでしょうか?一般的なブロックチェーンでは、ブロックチェーンの確認数を確認するのが一般的です。 IOTA は、トランザクションの重みを調べることで同様の機能を実現します。
画像の説明
各トランザクションには独自の重みがあり、タングルにチップが追加されるたびに、累積重みが増加します。
上の図では、トランザクション D がトランザクション E と H によって直接承認され、さらに間接的に G と I によって承認されていることがわかります。したがって、D の累積重みは 3+1+3+1+1=9 となり、これは D 自体の重みと E、H、G、および I の重みの合計です。
累積重みが大きいトランザクションは、累積重みが小さいトランザクションよりも重要です。タングルに追加される新しいトランザクションごとに、以前のトランザクションの累積重みが、それ自身のトランザクションの重みだけ増加します。古いトランザクションは時間の経過とともに重要になります。どのエンティティも短期間に十分な重みを持つトランザクションを生成できないと考えられるため、累積重みを使用することでスパム攻撃やその他のベクトル攻撃を回避できます。
Avalanche の X-Chain と同様に、このアプローチは拡張性が高いものの、スマート コントラクトを統合することをほぼ不可能にします。そのため、他のスマートコントラクトチェーンと競合するために、IOTAは「アセンブリ」と呼ばれる別のスマートコントラクトレイヤーを立ち上げています。アセンブリは、EVM および WASM スマート コントラクトをサポートするように設計された完全にオーダートされたレイヤー 2 です。
Sui、Proof of Stake を使用したスマート コントラクト DAG
このレポートでは、Sui は因果順序として分類されていますが、実際には、Sui は全順序と因果順序の両方を使用します。スイのトランザクション処理アーキテクチャは 2 つの部分で見ることができます。1 つの部分は完全な順序であり、依存するトランザクションが順番に実行され、もう 1 つの部分は因果的な順序であり、独立したトランザクションが並列で実行されます。依存トランザクションは、Sui の Narwhal プロトコルと Bullshark プロトコルを使用します。 Narwhal は DAG ベースのメモリプールですが、Bullshark はコンセンサスのために Narwhal と統合されたコンセンサス プロトコルです。依存トランザクションは、関連付けられている他のトランザクションと順番に実行するだけで済みます。ただし、トランザクションが完全に独立している場合、Sui は別のアプローチをとります。スタンドアロン トランザクションの場合、Sui はイッカクやブルシャークの代わりにビザンチン コンセンサス ブロードキャスト (BCB) と呼ばれる方法を使用します。この方法では世界的な合意が必要ないため、トランザクションをほぼ瞬時に処理して台帳に書き込むことができます。
画像の説明
トランザクションの順序に関係なく、すべてのトランザクションは同じネットワーク上で並行して処理されます。
トランザクションは、オブジェクトの特定のインスタンスのメタデータ変更にすぎません。トランザクションは、オブジェクトを入力として受け取り、それらの入力オブジェクトを読み取り、書き込み、または変更して、新しく作成または更新されたオブジェクトを出力として生成します。各オブジェクトは、それを生成した前のオブジェクトのハッシュを知っています。
画像の説明
スイの台帳は、データが DAG に保存される「オブジェクト リポジトリ」または「オブジェクト プール」です。たとえば、USDC を送信する行為は、1 つのオブジェクトの「所有者」プロパティを更新する行為であり、他のオブジェクトには影響しません。
スイの台帳は、データが DAG に保存される「オブジェクト リポジトリ」または「オブジェクト プール」です。この DAG では、ノードはオブジェクトであり、グラフ内の各矢印は、特定のオブジェクトのプロパティを更新するトランザクションを表します。この図にはジェネシス トランザクションは示されていませんが、これは入力を受け入れず、システムの初期状態でオブジェクトを生成します。
キーポイント
キーポイント
トランザクションの因果的順序付けは、速度とスループットの点で完全な順序付けよりも利点があるようです。ただし、順序の因果関係が欠如しているため、厳密な時系列順序を必要とするアプリケーションを作成しようとすると問題が発生し、多くのプロジェクトが DAG アーキテクチャ上でスマート コントラクトを適切に実行できません。 Fantom のブロックチェーン構造に似た完全に順序付けされたアーキテクチャは、EVM とスマート コントラクトをサポートします。 Fantom には合計注文出力がありますが、開発者は依然として DAG コンセンサス メカニズムの下でレイヤー 1 を最適化する方法を見つけました。 Avalanche は別のアプローチを選択し、EVM とスマート コントラクトの便利な開発をサポートする別のコンセンサス メカニズム Snowman を作成しました。 IOTA は別のアプローチも選択し、EVM をサポートするために IOTA 上にブロックチェーン インスタンスを簡単にデプロイできるフレームワークを作成し、完全に順序付けされたレイヤー 2 インフラストラクチャを効果的に作成しています。スイのユニークな設計は非常に有望です. トランザクションは必要に応じて完全に順序付けすることも、因果的に順序付けすることもできます. スマート コントラクトと互換性があり、レイテンシーを削減できます。
Sai は最新の DAG ベースのレイヤー 1 ですが、差別化を図り、従来のアーキテクチャの欠点を改善し、まさに DAG を分散台帳とする構造を実現しました。たとえ因果関係のあるトランザクションが将来的に主流にならないとしても、DAG ベースのテクノロジーは既存のブロックチェーンの拡張に役立つでしょう。スケーリング方法としての DAG はすべてのユースケースにとって最良の選択ではないかもしれませんが、Avalanche の X-Chain と IOTA では、DAG はレイテンシーとスループットの点で優れたパフォーマンスを発揮するようです。
副題
著者について
免責事項
免責事項
ここに含まれる情報 (「情報」) は、概要形式で情報提供のみを目的として提供されており、網羅的なものではありません。これらの資料は、有価証券または製品の売買の提案または提案の勧誘ではなく、またそれらを意図したものでもありません。そのような情報は提供されるものではなく、投資アドバイスを提供するものとみなされるべきではありません。
元のリンク
