原作者: Fu Shaoqing、SatoshiLab、Bihelix、All Things Island BTC Studio
注意事項を読んでください:
(1) この記事は、システムの基礎となる原理に関係しており、著者には分散システムに関する理論的および実践的な経験が限られているため、少しわかりにくいです。一般の読者は、セクション 3.3 大規模 Web3.0 アプリケーションのアーキテクチャの結論を直接読むことができます。
(2) 第2層構造の分類については、「ビットコインの第2層(レイヤー2)構造の基礎知識体系をまとめた記事」を参照してください。参考記事のシステム構造分類によれば、ビットコインのレイヤー2の第2層は、ブロックチェーン構造、分散型システム構造、集中型システム構造の3種類に分類されます。
(3) ビットコインの第 2 層構造をステート マシンの観点から観察すると、ステート マシンの原理は 3 つのシステム構造 (ブロックチェーン システム、分散システム、集中システム) のすべてに適用できることがわかりますが、その実装はシステムの構造上、方法が限定されます。
(4) 3 つの視野角: 分散台帳、ステートマシン、ブロック + チェーン構造
序文: 複数のレベルと視点
物事を複数のレベルと角度で観察することは、包括的な分析方法論に属します。その利点は、包括性、深い理解、包括性、正確性、実行の容易さなどのいくつかの側面に反映されています。包括的な分析手法の利点は、複雑で変化しやすい問題に強力な応用価値をもたらし、より包括的で詳細かつ正確な分析結果を提供し、問題の解決と開発の促進を強力にサポートすることができます。
(1)複数のレベル
マルチレベルは一般にマクロ、メソ、ミクロレベルで観測できますが、時間サイクルの観点からは短期、中期、長期レベルで観測することもできます。ビットコインエコシステムの発展においては、短期、中期、長期の3つのレベルからビットコインエコシステムを観察することで、より包括的で深く正確な知識と理解を得ることができます。
ダシャン先生の要約は次のとおりです。「ビットコイン エコシステムは、短期、中期、長期の 3 つの機会に分かれています。ビットコイン エコシステムの短期的な機会は、BRC-20 に代表される登録トラックです。中期的な機会は、Bitcoin Layer 2 トラックと Nostr Plus.Lightning Network トラックであり、長期的な機会は、RGB プロトコルと BitVM に代表されるオフチェーン ソリューション トラックです。これには、Inscription トラック、Layer トラックの 4 つのトラックが含まれます。 2 トラック、Nostr プラス ライトニング ネットワーク トラック、オフチェーン トラック (RGB と BitVM で表される)。
この記事のセクション 3.4 では、Layer におけるチェーンベースの第 2 層構築の初期段階も短期的な機会として分類されており、その理由はセクション 3.4 で紹介されています。
(2) 複数のアングル
同時に、私たちはビットコインのエコシステムをさまざまな角度から観察しており、それが包括的、客観的、詳細で柔軟かつ革新的な利点をもたらす可能性があります。このような多角的な観察は、物事をよりよく知り、理解するのに役立ち、イノベーションに役立ちます。
この複数の観点から、ビジネスの観点 - 分散台帳 (ビジネスの理解に役立つ)、抽象コンピューティングの観点 - ステート マシン (ブロックチェーン + 分散システムの実装の理解に役立つ)、および技術実装の観点 - ブロック + から始めます。チェーン構造 (エコシステムのブロックチェーン部分の理解に役立ちます)。
1. 3つの視野角
イーサリアムの文書「イーサリアムEVM図解」では、イーサリアムのブロック構造には3つの視野角があることが紹介されています（分散台帳、ステートマシン、ブロックチェーン）。この観察はビットコインにも当てはまり、ビットコインの生態構造を観察するのにより適しています。以下の紹介では、これら 3 つの観点から理解すると、さまざまなメリットが得られます。
ステートマシンの観点からは、ブロックチェーン上のステータスやステータス処理を理解しやすいだけでなく、分散システム内のステータス、ステータスチャネル、ステータス遷移も理解しやすくなります。分散システムの構造を理解すればルーティングを理解しやすくなりますが、問題は状態遷移の有向非巡回グラフの要件を理解することです。ステート マシンは、グラフ理論の基礎となる抽象的なコンピューティング原理に基づいており、これらの原理と特定の実装構造 (ブロックチェーン、分散型、集中型) に基づいて、解決する必要がある特定の問題と解決策のアイデアを理解することができます。
次に、ビジネスの観点から、なぜブロックチェーンが信頼データを処理できるのか、またブロックチェーン上のデータがデジタル通貨として使用できるのか、つまりブロックチェーン システムが台帳に似ているのかを簡単に理解できます。分散システムが台帳ではなく、台帳と連携する必要がある理由がわかります。同時に、分散システムが台帳と連携して台帳上のデータや流れをどのように扱うのかを理解します。
技術実装の観点から、ブロックチェーンのようなシステムはブロックチェーンの構造であることがわかり、この技術構造の長所と短所も簡単に要約して要約することができます。
ビットコインエコシステムの構造に関して、台帳とステートマシンの観点から、各構造の長所と短所、および Web3 を構築する場合でも、ビットコインの第 2 層を構築するために 3 つの代替構造を使用する方法をよりよく理解できるようになります。 0 アプリケーションのアーキテクチャ全体。
イーサリアムのドキュメント「イーサリアムEVM図解」を読んでいて感じたことがあります。イーサリアムと比較できるものを 3 つの異なる角度から観察することで、イーサリアムを解決するための思考アイデアと処理経験の参考が得られます。例えば、イーサリアムを状態ベースのオートマトンとみなした場合、コンピュータ分野のステートマシンに関する理論やアルゴリズムを、変換を通じてイーサリアムに適用することができます。イーサリアムを台帳ベースのデータベースとして考える場合、データベース内のシャーディングのアイデアなど、データベース内のいくつかの理論はイーサリアムに適用できます。この感覚はビットコインのエコシステムにも当てはまり、3つの大きなシステム構造で混在して利用され、柔軟性がさらに高まります。
1.1. ビジネスの観点 – 分散型台帳
台帳の観点から見ると、ブロックチェーンは、台帳に書かれたデータのページと同じように、トランザクションのグループです。
台帳の観点から見ると、そのビジネス能力と金融および財務機能を理解しやすくなります。これは、Web3.0 アプリケーションの全体的なアーキテクチャにおける台帳の役割でもあります。
台帳の観点から見ると、チェーンの第 2 層の構造を簡単に理解できます。さまざまなビジネスのアカウントをさまざまな台帳に記録し、これらの補助元帳を総勘定元帳にまとめることができます。
台帳+流通の観点から見ると、参加者にデジタル通貨が与えられた場合、その扱い方やアカウントの分割方法など、参加者自身が交渉して対応し、最終的に台帳に記録することができることが分かります。 。
1.2. 抽象コンピューティングの観点 - ステートマシン
ここではステート マシンに焦点を当てます。この観点からブロックチェーン システムと分散システムをよく理解できるからです。そして、ブロックチェーン システムでのデータ (または状態) の処理方法と分散システムでのデータの処理方法の違いを理解することができます。
状態の観点から見ると、ブロックチェーンはトランザクションベースのステートマシンです。トランザクションは、トランザクションのアクションの下で元の状態 σt を次の状態 σt+ 1 に変換させるトリガー条件です。
一連のトランザクションはデータ パッケージであるブロックチェーンにパッケージ化され、このデータ セットに関連付けられたステータスが変化します。
したがって、この観点から見ると、ブロックチェーンは状態チェーンです (分散システムでは、状態チャネルです)。状態の観点から見ると、ブロックチェーン システムは状態ベースのオートマトンとみなすことができます。
状態の観点からブロックチェーン + 分散システムを観察すると、2 つのシステムにおける状態の伝達と変化のルールが理解しやすくなりますが、実際にはどちらのシステムも状態ベースのオートマトンです。
ブロックチェーンを状態ベースのオートマトンとみなすと、コンピュータ分野のグラフ理論におけるステートマシンに関する理論やアルゴリズムをブロックチェーンに適用することができます。同様に、実装される技術構造がブロックチェーン構造ではなく分散構造である場合、ステートマシン理論を使用することもできます。有限非巡回グラフ DAG (ダブル フラワーの回避) と同様、状態チャネル、ワンタイム シーリングはすべて、分散システムで状態を処理するために使用する必要があるテクノロジです。
1.3. 技術実装の観点 - ブロック + チェーン構造
技術的な実装の観点から見ると、ビットコインやイーサリアムなどのシステムはブロックチェーンです。分散したデータは、内部のデータブロックとハッシュポインタによって結合されます。
これは、ブロックチェーンのようなシステムを運用するために維持される技術的な実装構造にすぎません。ブロックチェーン上のデータと計算はグローバルなアプローチを採用しており、この構造だけで台帳の機能を完成させることができます。外部システムと接続する場合は、この構造の実装の詳細と適用可能性を考慮する必要があります。
このブロック＋チェーン技術の実装構造の特徴を容易に把握でき、性能指標の計算も可能です。たとえば、ビットコイン ネットワークのブロック サイズは 1 M (Segregated Witness のサポート後の理論上の最大値は 4 M) で、サポートされるトランザクションの数は完全に計算できます。
計算式は、(ブロック サイズ / トランザクションの平均サイズ) / 平均ブロック時間間隔です。通常、ビットコインはブロックあたり約 2,000 ～ 3,000 のトランザクション、または 3 ～ 7 TPS に対応できます。
1.4. ブロックチェーンの基本特性と3つのレイヤー2構築構造の特徴
ビットコインの第 2 層構造を 3 つの分類に分けます。ブロックチェーン構造、分散システム構造、集中システム構造です。ビットコインの第 1 層構造と第 2 層構造のいくつかの基本的な特徴を比較すると、それらの違いが明確にわかります。以下の表に示すとおりです。後で、セクション 3.2 でアプリケーション要件を比較し、これらの基本システム構造から適切なアーキテクチャ構築の組み合わせを選択するのに役立てます。
上記の表を通して、ブロックチェーンの構造、分散システム構造、集中型構造の特徴を大まかにまとめることができます。
(1) ブロックチェーンの構造
ブロックチェーン構造の最大の利点は、信頼関連の問題を解決し、データ変更プロセス (状態遷移) を記録できるため、データと計算ルールが信頼できるデータと信頼できる計算になることです。これらの信頼できるデータの 1 つは基本的な元のデータ (通貨として表現される) であり、もう 1 つはデータを処理するための命令セット (コードおよびスマート コントラクトとして表現される) です。
ブロックチェーン構造の最大の問題はパフォーマンスの低下ですが、これには 2 つの理由があり、1 つはブロックチェーン構造が部分的な計算シナリオを削除できず、すべてのリクエストが完全な計算方式で処理されることです。たとえば、部分計算とグローバル計算、ローカル データとグローバル データ、一時データと永続データなどです。第二に、ブロックチェーンの構造には明らかなパフォーマンスの上限があります。第 2 層の拡張がチェーンを通じて実行される場合、サポートされるトランザクションの数も非常に制限されます。簡単な計算は次のとおりです。
ブロックチェーンシステムの上限は、単一のブロック容量で収容できるトランザクションの最大数ですが、多層ブロックチェーンの上限は、各層のブロック容量のトランザクション数の積になります。たとえば、ビットコインのレイヤーの処理能力が 1 秒あたり 7 TPS で、レイヤー 2 チェーンの処理能力が 100 TPS の場合、2 つの構造を組み合わせると 700 TPS になります。
ブロックチェーンを含む構造のパフォーマンスを拡張するには、多層構造が必要であり、異種システムと組み合わせて使用する必要があります。ブロックチェーン システム内で完了する必要がある作業については、グローバルに保存および計算する必要があるデータのみを記録する必要があり、その他の非グローバル データは他のレイヤーに割り当てて処理できるため、処理されたデータとコードは関連するだけです。可能な限り関係各所へご連絡申し上げます。
上の表から、トラストレス台帳機能を実現できるのはブロックチェーン構造だけであるため、トラストレス台帳機能を実現したいシステムにはブロックチェーンシステムが組み込まれなければなりません。ただし、大規模アプリケーションにはパフォーマンス要件があるため、ニーズを満たすためにブロックチェーン システムを他のシステムと組み合わせる必要があります。
(2) 分散システム
上の表では、分散システムの明らかな利点がわかります。分散化、パフォーマンス、スケーラビリティはすべて優れていますが、機能の実装にはさらに複雑な機能があります。さらに、分散システムには台帳を信頼する機能がありません。
したがって、ビットコインの第1層台帳機能をベースにした第2層構築で分散システムを利用できれば、理論的にはブロックチェーンの基本特性を維持したまま無制限の性能拡張が可能となります。この領域のケースは、ビットコイン + ライトニング ネットワークに代表され、この組み合わせのパフォーマンスはビットコインの 7 TPS * ∞ となります。
分散システムでチューリング完全性を達成する理由は、ブロックチェーン システムでのスマート コントラクトの記録と実行のコストが非常に高いためです。これは、スマート コントラクトはグローバル データでありグローバル コードであるためです。したがって、スマート コントラクトは、コードの保存とスマート コントラクトの実行を参加者に制限する階層理論にも適しています。これは、分散システムでクライアント側の検証が行われるシナリオでもあり、計算に参加するには関係者間で信頼できるデータ (状態、ワンタイム シール) のみが必要であり、チューリング完全計算はローカルでのみ実行されます。これは、分散システムにおけるネットワーク全体のコンセンサスと参加者のコンセンサスについてよく言われることですが、分散システム構造で第 2 層を構築する際の最大の難点は、技術的な実装が比較的複雑であることです。ライトニングネットワークのような、単に支払いの問題を解決するだけのネットワークは発展が遅く、多くの不完全性があります。分散システム上でチューリング完全コンピューティングを実装することはさらに困難です。 RGB の開発の遅さとバージョンの更新の遅さは参考事例です。
複雑さを解決する際の最大のコストは、セキュリティ問題に対する脆弱性と開発の敷居が高いことです。チューリング完全スマート コントラクト機能を分散システムに実装するには、基礎となるプラットフォームの開発サイクルが長く、開発が難しいだけでなく、多くの場合、コントラクト コードの脆弱性や継続的なハッカー攻撃につながります。
(3) 集中システム
上の表から、集中型システムの利点は、内部ロジック制御と計算が単純であるため、エンジニアリング実装が比較的簡単であることがわかります。同様に、集中型システムには台帳を信頼する機能がありません。集中型システムの利点は顕著ではありませんが、小規模なデータを処理する場合や、一時的なデータや一時的な計算を処理する場合には比較的適しています。
集中システムの 2 階の構築は、他の 2 つの方法に対する補足的または移行的なソリューションとして使用できます。
(4) 総合分析
バリュー時代においては、上記の内容を通じて、一つのシステムだけではニーズを満たす効果を得ることが難しいことが分かります。これは、ビットコインのエコロジー開発の第 2 層にとって実際的なニーズでもあります。しかし、これら 3 つのシステムをどのように組み合わせるかには多くの検討が必要です。まずは理論的に分析してみましょう。ニーズが異なれば、組み合わせ構造も異なります。
まず、プロトコル階層化の設計概念の観点から見ると、ビットコインネットワークはチューリング完全性を必要とせず、グローバルトラストマシンであり、グローバルトラストを必要とするデータとデータの変更を保存するだけで済みます。この最も基本的な要件に基づいて、ビットコインの命令セットを最小限に抑えることができます。他の機能は、上位層の拡張機能に任せて完了させます。この層の機能要件を満たすだけでなく、ビットコインの第 1 層と上位層のネットワークとの接続技術も更なる開発・改良が必要であり、また、この接続技術は機能を満たすことを前提としたものであり、ビットコインのデータ容量をできるだけ少なくする。
一般に、小規模なアプリケーションは単一のブロックチェーン上でのみ完了する必要があります。ブロックチェーン＋ブロックチェーンの第２層構築で完成させるには、少し大きめのシステムが適しています。ただし、大規模なアプリケーションの場合、ブロックチェーン システム + 分散システムを使用するソリューションが推奨されます。パフォーマンスの観点から見ると、分散システムの上限は理論的には無制限であるため、そのような組み合わせはビットコインの 7 TPS * ∞ となります。エンジニアリング実装は、いくつかの特定の要因によっても制限されます。通常、そのようなシステムの上限は、分散システムのルーティング機能、状態変化の有向非巡回グラフの処理能力、およびその他の特定の技術実装リンクによって制限されます。後ほど、Web3.0の代表的なアプリケーションアーキテクチャで、さまざまなシステムの組み合わせ図も見ることができます。
複数のシステム構造を組み合わせることで、単一システムの基本理論の限界を打ち破ることができます。例えば、ブロックチェーンシステムはDSS不可能三角形の限界によって制限されますが、ブロックチェーンシステム＋分散システムを利用すれば、分散性D、セキュリティS、スケーラビリティSの不可能三角形を解決できます。他の組み合わせ、ブロックチェーン + 集中システムでも、スケーラビリティの問題をある程度解決できます。分散システム + 集中システムは、分散システムにおける CAP トライアングルの制限を解決できます。
過去の技術開発の歴史の中には、併用する例もありました。たとえば、集中型データベースの機能が制限されている場合は、マスター/スレーブ構造を採用し、その後、サブデータベースやサブテーブル、分散型データベースに移行します。これは、集中型システムと分散型システムの使用例です。
この組み合わせは、哲学的なアイデアも具体化しています。問題の解決策は、問題を引き起こしたレベルでの答えを提供するものではありませんが、より高いレベルで問題を解決します。この文を明確に理解するのは特に簡単ではありませんが、「禅とオートバイ整備の技術」の中で特に優れた比喩を思いつきます。これは、私たち自身の問題を解決するためにシステム自体に依存することはできず、問題を解決するには外部システムを使用する必要があることを示しています。
2. ステートマシンの観点からビットコインの第 2 層の設計と開発を再考する
ステートとステート マシンは 3 つの 2 階建ての建物に存在しますが、名前が若干異なるため、ほとんどの人はこの観察角度に注意を払いません。
状態とステート マシンの観点から見ると、3 つの 2 層構造はすべて状態を処理するステート マシンですが、原理が少し異なります。これら 3 つのシステムを組み合わせて使用する場合、「状態」の概念が 3 つのシステムで一貫していること、および各システムのステート マシンが状態の変更を処理できるが、状態の一貫性を破壊できないことを確認する必要があります。
ステート マシンの観点から見ると、ビットコイン エコシステムまたは Web3.0 のアプリケーション アーキテクチャは、これらのシステムの組み合わせを使用して状態変換の処理を完了し、それによってビジネス ロジックの処理を完了します。
ステートマシンの考え方を用いてビットコインの2層のネットワーク構造を見ると、アーキテクチャの各層がその特性に応じた分業を行っていることがわかります。
2.1. グラフ理論における状態とステートマシンの基礎知識
グラフ理論では、状態とステート マシンに関する基本的な知識には次のものが含まれます。
州: 状態とは、グラフ理論におけるノードまたは頂点を指します。有向グラフでは、状態はノードとして表現でき、無向グラフでは、状態は頂点として表現できます。
状態遷移: 状態遷移とは、ある状態から別の状態へのプロセスを指します。有向グラフでは、状態遷移は有向エッジとして表現でき、無向グラフでは、状態遷移は無向エッジとして表現できます。
ステートマシン: ステート マシンは、一連の状態と状態間の遷移ルールを記述するために使用される抽象的なコンピューティング モデルです。ステート マシンは、状態セット、初期状態、遷移関数、および終了状態で構成されます。
有向グラフ: 有向グラフは、頂点と有向エッジで構成されるグラフ構造であり、有向エッジはある頂点から別の頂点を指し、状態間の遷移関係を表します。
無向グラフ: 無向グラフは、頂点と無向辺で構成されるグラフ構造であり、無向辺は 2 つの頂点を接続し、状態間の関連を表します。
トポロジカルソート: トポロジカル ソートとは、有向非巡回グラフ (DAG) の頂点を線形にソートすることを指し、任意の 2 つの頂点 u および v について、エッジ (u, v) がある場合、ソートでは u が v の前に表示されます。
有向非巡回グラフ (DAG): 有向非巡回グラフは、頂点から始まり、いくつかの辺を通過した後に頂点に戻るサイクルが存在しない有向グラフです。
最短経路: 最短パスとは、エッジの重みの合計が最小になるグラフ内の 2 つの頂点を接続するパスを指します。
最小スパニングツリー: 最小スパニング ツリーとは、接続されたグラフ内のすべての頂点を含み、ツリーのエッジの重みの合計が最小となるツリーを見つけることを指します。
これらの基本知識はグラフ理論の中核概念であり、状態間の関係と遷移ルールを記述および分析するために使用されます。関連する知識やグラフィックスは専門書で詳しく学ぶことができます。
この知識は少し抽象的で退屈に思えますが、この知識を私たちがよく遭遇するブロックチェーンの概念に変換すると、簡単に理解できます。たとえば、一部のシナリオでは、二重支出の問題を回避するために有向非巡回グラフが必要です。ワンタイム カプセル化は、ブロックチェーン内の状態を分散システム内の状態に変換します。ルーティング アルゴリズムは、分散システム内の最短パスを見つけることです。計算; ライトニング ネットワーク内で支払いコストが最小のルートは最小スパニング ツリー問題です; クライアント検証はステート マシンの一種とみなすこともできます。
2.2. ステートマシンと分散システム
ここでは、いくつかの分散ネットワークを使用して以下を紹介します。
(1) ライトニングネットワークの場合
ライトニングネットワークでは、ステートとステートマシンに関連するナレッジポイントは次のとおりです。
ライトニング ネットワークは、ステート チャネル テクノロジーに基づいたビットコインの第 2 層ソリューションです。ライトニング ネットワークの支払いチャネルは双方向のステート チャネルです。参加者はチャネル内で複数のトランザクションを実行し、チャネル ステータスを更新して、高速かつ低コストを実現できます。 -コスト取引 コストの支払い。
ライトニングネットワークのトランザクション（つまり、状態）は、ハッシュベースのタイムロックコントラクト（HTLC）を通じて実装され、これを通じて参加者は資金をロックし（状態はビットコインとライトニングネットワークシステム間で転送されます）、チャネル内で安全なトランザクションを実行できます。 (単純な状態処理)。
Lightning Network でのルーティング: クロスチャネル支払いを可能にするために、Lightning Network はルーティングと呼ばれるメカニズムを使用し、参加者は信頼できるパスを見つけて支払いを行うことができます。
ライトニングネットワークのリレーノード: リレーノードは支払いリクエストを転送できるノードであり、クロスチャネル支払いの実現に役立ちます。
Lightning Network での双方向支払い: Lightning Network を使用すると、参加者は支払いチャネルで双方向支払いを行うことができます。つまり、参加者は相手に支払うだけでなく、相手の支払いを受け入れることもできます。
ライトニングネットワークの支払いプライバシー：ライトニングネットワーク上の取引はチャネル内で行われるため、すべての取引をブロックチェーンに書き込む必要がなく、支払いのプライバシーを向上させることができます。
Lightning Network の制限 (主にステートおよびステートマシン実装テクノロジーの制限): Lightning Network には、チャネルの存続可能性、資金ロック時間などのいくつかの制限もあります。適切な支払いチャネルを設計するには、これらの制限を包括的に考慮する必要があります。
(2) RGB では、状態、状態マシン、および状態チャネルに関連する知識ポイントは次のとおりです。
RGB は LNP および BP プロトコルに基づいています。 RGB が第 2 層か第 3 層かという議論がありますが、BP に基づいて RGB を直接計算すると、ビットコインのチューリング完全関数を直接拡張したものとなり、第 2 層に属し、性能の拡張には限界があります。 RGB 計算が LNP に基づいている場合、それは第 3 層に属します (LNP はビットコインの第 2 層であるため) この方法はパフォーマンスとチューリング完全な計算能力の両方を拡張できますが、技術的な実装にはある程度の複雑さが伴います。 。通常、組み合わせて使用すると、コンピューティング能力を拡張できるだけでなく、パフォーマンスも拡張し、実装の複雑さを軽減できます。
RGB は、ビットコインまたはライトニング ネットワークのステート チャネル テクノロジーに基づいています。 RGB のステータス チャネルは、LNP と BP 上に構築された 2 つ以上の当事者間の通信チャネルを指し、チャネル内で複数のトランザクションとステータス更新を実行できるため、ブロックチェーン上のトランザクション数と手数料が削減されます。
RGB の状態チャネルは、ビットコインベースのマルチ署名スクリプトを使用して資金をロックし、特別なトランザクション タイプを使用してチャネルの状態を更新します。
RGB の状態チャネルは、支払いチャネル、分散型取引所、資産発行などのさまざまなシナリオに適用でき、トランザクションの効率とユーザー エクスペリエンスが向上します。
RGB のステート チャネルは、チャネルのステータスを更新することで支払いと資産の転送を実現します。チャネル内のトランザクションはブロックチェーンに書き込まれる必要はなく、最終状態のみがブロックチェーンに書き込まれます。
RGB の状態チャネルは、スマート コントラクトやマルチ署名スクリプトを通じて、アトミック スワップ、支払いルーティングなどのより複雑な機能を実装することもできます。
RGB の状態チャネルは、Lightning Network、LNURL などの他のテクノロジーやプロトコルと組み合わせて、より豊富な機能と優れたユーザー エクスペリエンスを提供できます。
RGB での状態チャネルの設計と実装では、システムの信頼性と可用性を確保するために、セキュリティ、プライバシー、スケーラビリティなどの要素を考慮する必要があります。
(3) Nostr では、状態、状態マシン、および状態チャネルに関連する概念。
Nostr では、情報を送信するため、状態 (信頼できるデータ、デジタル通貨) と状態マシンの概念がまだ反映されていません。しかし、Nostrの分散構造を少し変えてステータスの処理を強化すれば、ライトニングネットワークのような情報伝達と価値提供を両立できるシステムが構築できるのではないかと考えています。セクション 3.3 の Web3.0 のアプリケーション アーキテクチャ図では、この情報ベースの分散システムを価値処理を含む分散システムに段階的に変換する可能性についても説明しています。
現在の Nostr の簡単な紹介: Nostr には、クライアントとリレーという 2 つの主要なコンポーネントがあります。各ユーザーはクライアントを実行し、リレーを通じて他のユーザーと通信します。各ユーザーは公開キーによって識別されます。ユーザーが行うすべての投稿には署名が付いています。各クライアントはこれらの署名を検証します。クライアントは、選択したリレーからデータを取得し、リレーにデータを公開します。リレーは相互に通信せず、ユーザーとのみ直接通信します。
(4) 分散システムでは、ステート マシンに関連する知識ポイントには次のものが含まれます。
ステート マシン モデル: ステート マシンは、異なる状態間のシステムの遷移と動作を記述する数学的モデルです。分散システムでは、システムの動作や状態変化を記述するためにステート マシン モデルがよく使用されます。
有限状態マシン (FSM): 有限状態マシンは最も基本的な状態マシン モデルであり、状態の有限セットと状態間の遷移ルールのセットが含まれています。分散システムでは、有限状態マシンはシステムのさまざまな状態と状態間の遷移を記述することができます。
状態遷移: 状態遷移とは、システムがある状態から別の状態に移行するプロセスを指します。分散システムでは、メッセージの受信やタイムアウトなど、さまざまなイベントや条件によって状態遷移がトリガーされることがあります。
ステート マシンの動作: ステート マシンは、さまざまな状態でさまざまな動作を定義できます。分散システムでは、ステート マシンの動作には、メッセージの処理、操作の実行、メッセージの送信などが含まれます。
状態の一貫性: 分散システムでは、複数のノードが異なる状態を持つ可能性があります。状態の一貫性とは、システム内のさまざまなノードの状態を調整し、相互に一貫性を保つことを指します。
分散ステート マシン (DSM): 分散ステート マシンは、ステート マシン モデルを分散システムに適用するテクノロジを指します。システムの状態と状態遷移を複数のノードに分散し、ノード間の状態の一貫性を確保できます。
アトミック ステート マシン (ASM): アトミック ステート マシンとは、状態遷移中にアトミック性を維持するステート マシンを指します。分散システムでは、アトミック ステート マシンは、状態遷移中のシステムの一貫性と信頼性を保証できます。
整合性プロトコル: 整合性プロトコルは、分散システムにおける状態の整合性を確保するために使用されるプロトコルです。一般的なコンセンサス プロトコルには、Paxos、Raft、ZAB などが含まれます。
フォールト トレランス: 分散ステート マシンはフォールト トレラントである必要があります。つまり、ノード障害やメッセージ損失が発生した場合でも、システムは正しい状態と動作を維持できます。
スケーラビリティ: 分散ステート マシンはスケーラブルである必要があります。つまり、システムの規模が増加しても、効率的な状態遷移と一貫性を維持できなければなりません。
2.3. ステートマシンとブロックチェーンシステム
イーサリアムの文書「イーサリアム EVM の図解」によると、各ブロックはトリガー状態のセットであり、イーサリアム システム全体が状態プロセッサーです。 1.2 では、ブロックチェーン システムにステート マシン コンテンツを導入しました。イーサリアムのホワイトペーパーにはステートマシンについての説明も数多くあります。
ステートマシンは強力な処理能力を持っていますが、その上限はブロックチェーン構造の上限です。
UTXO モデルとアカウント モデル (EVM など) に基づくブロックチェーン相互接続の組み合わせアプリケーションの場合、ステートとステート マシンの実装方法はまったく異なります。 UTXO モデルに基づくブロックチェーンは、両方のシステムの状態が UTXO に基づいており、変換がないか単純な変換のみであるため、分散システムと組み合わせるのが容易であり、実装が容易です。アカウントモデルに基づくチェーンは、その状態と外部分散システムの状態との間でさらなるカプセル化と変換を必要とし、その実装が複雑であることも、イーサリアム上での雷電ネットワークの開発がスムーズでない理由の1つです。
2.4. ステートマシンと集中システム
ブロックチェーン + 集中型システムの使用例には、Ordinals や集中型取引所 CEX などがあります。
このようなシステムは比較的単純で、統計作業を完了するために集中インデックスのみを使用する Ordinals のように、状態の転送がまったく行われないシステムもあります。
集中型交換機と同様に、その状態の転送は集中型システムによって設定されたルールに完全に依存しており、内部のステートマシンも集中型システムのプログラムで構成される状態プロセッサであり、複雑な概念はありません。
今後のWeb3.0アプリケーションでは、ブロックチェーン＋集中システムを利用するケースが増えるはずです。
3. Web3 アプリケーションの構造はどのようなものであるべきですか?
この記事のこれまでの内容から、3 つのビットコイン 2 層アーキテクチャを組み合わせることで、より複雑な構造設計を完成させて、必要な機能要件を実現できることがわかりました。ビジネスの観点から見ると、アプリケーションの基礎となるロジックを状態とステート マシンに分解できれば、3 つのシステムを組み合わせて上位層のビジネス ロジック全体を完成させることができます。
では、これらの一般的な組み合わせは何でしょうか?ポートフォリオの構造を決定する要因は何ですか?一般的なアプリケーション分類とアプリケーション要件に基づいて、Web3.0 を満たす大規模アプリケーションの構造を推測します。
3.1. 一般的なアプリケーションの分類
第 48 回「中国のインターネット発展に関する統計報告」のアプリケーション統計を参考として使用します（以下、統計報告といいます）。 Web2.0 は成熟しており、アプリケーション分類やユーザー スケールの結果の分析に影響を与えていないため、使用するアプリケーション参照データは 2020 年と 2021 年の古いデータです。注意すべき点は、これは中国のインターネットの統計にすぎないということですが、Web3.0 段階では、多くのアプリケーションがグローバルであり、ユーザーの規模やパフォーマンスの要件もより高くなります。
統計レポートを見ると、Web2.0 のアプリケーションはすでに非常に充実しており、巨大なユーザー グループを抱えていることがわかります。これらのアプリケーションには、インスタント メッセージング、オンライン ビデオ、ショート ビデオ、オンライン支払い、オンライン ショッピング、検索エンジン、オンライン ニュース、オンライン音楽、オンライン ライブ ブロードキャスト、オンライン ゲーム、オンライン テイクアウト、オンライン文献、オンライン配車、オンライン オフィス、およびオンライン旅行予約、オンライン教育、オンライン医療など、人々の生活のほぼすべての分野をカバーしています。これらの消費者向けインターネット コンテンツに加えて、産業用インターネットにも多くのアプリケーションがあります。
すべての Web2.0 アプリケーションが Web3.0 に移行される場合、そのほとんどは非常に高いパフォーマンス要件を必要とします。 Visa 決済を例にとると、ピーク パフォーマンス要件は 65,000 TPS です。このようなパフォーマンス指標は、分散システムによってのみサポートされます。たとえば、ライトニング ネットワークの現在のパフォーマンスは 1 秒あたり 4,000 万トランザクションであり、ライトニング ネットワークのパフォーマンスは 1 秒あたり 4,000 万トランザクションです。ネットワークが理論的に十分ではありません。上限。
さらに、一般的なゲームを例に挙げると、ブロックチェーン上で最も高い TPS を備えた現在のフルチェーン ゲームは、約数千 TPS のピークに達する可能性があり、これは数十万の TPS を備えた従来の Web2 3A ゲームとは大きな違いがあります。 TPS。すべてのゲームを Web3.0 に移行したい場合、必要なインフラストラクチャのパフォーマンスが大きな課題となります。
さらに、ゲームは一般的なアプリケーション カテゴリの 1 つのアプリケーションにすぎず、他のアプリケーションにはより多くのパフォーマンスと特定の要件があります。
3.2. Web3.0 アプリケーションの要件
アプリケーションのニーズを理解するには、収益構造を指標として使用する方がより直接的です。 「Token Terminal, curated by FutureMoney Research 2022 Q2」レポートを参照していますが、このレポートは以前のものですが、決済やその他のアプリケーションは準備段階にあり、主要な分析結果には影響しません。ということで、著者はここで怠けてWeb3.0の本を書いた時のデータを使ってしまったので、2023年の第4四半期のデータがあればより正確になるでしょう。
(1) 収益報告による需要分析
レポートの収益分類は、Web3.0 の現在の中核製品構成をよりよく表しています。写真が示すように。
1) レイヤー 1 (ブロックチェーンの基本的なメインチェーン) の収益は 48% であり、総収益のほぼ半分を占めており、そのビジネス モデルは「ブロック スペースの販売」として理解できます。
2) NFT 取引プラットフォームの収益は 22% を占め、そのビジネス モデルはロイヤルティまたはマーケティング活動として理解できます。
3) DeFi における Dex 収益は 15% を占め、そのビジネスモデルは取引手数料と流動性マーケットメイキング収益です。
4) DeFi におけるステーキング収入は 8% を占め、そのビジネスモデルは資産運用からの手数料または金利スプレッドです。
5) Gamefi が 5% を占め、ビジネスモデルはロイヤルティ、送金手数料、NFT の販売など。
6) DeFi における融資収益は約 1% を占め、そのビジネスモデルは金利スプレッドです。
7) Tooling の収益は約 1% を占め、そのビジネス モデルはサービス料金であり、将来的にはトラフィック収益化料金も含まれる予定です。
Web3.0 に関連するその他の産業は Web3.0 アプリケーションではないため、Web3.0 の中核産業にはカウントされず、含まれません。例: Web3.0 メディア、研究機関、研修機関など。
収益構造から、BTC エコシステムの現在のアプリケーション ニーズは、基本的に、複雑なシステム アーキテクチャを必要とせず、ブロックチェーンとその第 2 層システムによって解決できることがわかります。ただし、Gamefi と SocialFi は比較的急速に発展しており、参考文献のゲーム例を使用すると、大規模なゲームにはシステム構造に対するより高度で明確な要件があることがわかります。
収益構造から、現在の BTC エコシステムのアプリケーション ニーズがわかり、イーサリアムや他のエコシステムのすべての製品をやり直す価値があります。イーサリアムエコシステムのチェーンベースの第 2 層構築テクノロジーをわずかに変革し、ビットコイン上に新しい第 2 層を確立することで、これらの主要なニーズをより適切に満たすことができますが、分散化、セキュリティ、プライバシー、および検閲耐性の程度においてのみです。作られた。 「ビットコインの第2層（レイヤー2）構築の基礎知識体系をレビューした記事」では、EVM型に基づく新たな第2層構築がすべてこの状況に該当する。
(2) 高いパフォーマンスが要求されるアプリケーションのゲームケースの分析
記事「不可能が可能になる: ライトニング ネットワーク上でフルチェーン ゲーム開発を実現する」では、機能とパフォーマンスの両方に対する要求が高まっています。 Web3.0 アプリケーションの実際のアーキテクチャが徐々に明らかになりつつあります。
記事内の問題の説明: セキュリティ、プライバシー、分散化の確保に基づいて、フルチェーン ゲームはスケーラビリティの最適な解決策を見つけていません。たとえば、最も人気のあるフルチェーン ゲーム エンジンの Mud と Dojo は、フルチェーン ゲームがより高い TPS を達成できるように取り組んでいますが、プレイヤーは依然として各操作に 2 秒以上のバッファリングを必要とします。実際、ブロックチェーン上で最も高い TPS を持つ現在のフルチェーン ゲームは、約数千 TPS のピークに達する可能性があります。これは、数十万 TPS を持つ従来の Web2 3A ゲームとは大きな違いです。フルチェーンゲームはブロックチェーンの利点を失わないという前提を追求しつつ、スケーラビリティを克服することができます。
技術的な説明の後半で説明するソリューションでは、パフォーマンスを拡張するために Lightning Network と RGB が使用され、一時チェーンと専用チェーンの概念も提案されています。
エフェメラルチェーン（一時チェーン）
一時的なブロックチェーンは、永久に存続せず、ブロックチェーンの目的 (トランザクションの記録など) が達成されるか、その状態が他の場所に永続的に保存されると破壊されるブロックチェーンとして定義できます。一時チェーンによって保存される終了ステータスは、一時チェーンに関連する終了事実に関するデータのみであるため、すべてが大幅に圧縮されます。一時チェーンは主に、ブロックチェーン上のトランザクション遅延とスループットによって制限されます。
一時的なチェーン VS ステート チャネル
一時的なチェーンに関する限り、パブリック チェーンの状態により、最終的には多数のユーザーが存在することになります。パブリック チェーンに挿入する必要がある状態は、枝刈り/圧縮/差分抽出によってサイズが縮小され、不定期ではなく定期的にパブリック チェーンに保存されます。 ＲＧＢステータスチャネルの設定は、一時チェーンの性能制約をバイパスし、一時チェーンと同じ機能を達成することができる。
アプリ固有のブロックチェーン
アプリケーション固有のブロックチェーンは、単一の分散アプリケーション (dapp) を実行するために作成されたブロックチェーンです。開発者は、既存のブロックチェーン上に構築するのではなく、ユーザーがアプリケーションと対話するためのトランザクションを実行するカスタム仮想マシン (VM) を使用して、新しいブロックチェーンを最初から構築します。開発者は、ブロックチェーン ネットワーク スタックのさまざまな要素 (コンセンサス、ネットワーク、実行) をカスタマイズして、特定の設計要件を満たすこともできます。スマート コントラクトの実行速度を向上させ、コンピューティング リソースの制約を解決することは、特定のアプリケーションへのブロックチェーンの実装に役立ちます。開発者がさまざまなユースケースに合わせてインフラストラクチャをカスタマイズできるため、開発が容易になります。同時に、Web3 開発者は強力な価値モデルを構築し、飛躍的な成長のニーズに対応してさらなるイノベーションを引き起こすために DAPP を拡張できます。
このゲームのケースと、これまでのいくつかのアーキテクチャの分析を組み合わせることで、将来の大規模アプリケーションのアーキテクチャを大まかに判断できます。
3.3. 大規模な Web3.0 アプリケーションのニーズを満たすアーキテクチャはどのようなものであるべきですか?
前回のコンテンツでは、Web2.0 の共通アプリケーション カテゴリについて説明しましたが、これらのアプリケーションはすべて Web3.0 にアップグレードされ、完全に Web3.0 時代に突入しています。上記の多くのアプリケーションを満たすことができるアーキテクチャはどのようなものでしょうか?
(1) Web2.0とWeb3.0の単純なアーキテクチャの違い
ここでは、ブロックチェーンの女神 Preethi Kasireddy が書いた記事「Web 3.0 アプリケーションのアーキテクチャ」の内容を参照します。ここで説明する Web3.0 アプリケーションの構造は、ブロックチェーン システムのみに依存する非常に単純な構造です。ただし、この構造は単純すぎるため、第 2 層の構造が反映されておらず、大規模なアプリケーションには適していません。
従来の集中型製品の技術実装事例とWeb3.0製品の技術実装事例を比較すると、技術実装の違いが理解しやすくなります。 Web3.0 の技術スタック ビジョンに関する Gavin Wood の説明と組み合わせると、Web3.0 の技術実装における最大の違いは背景にあり、ユーザー エクスペリエンス層の違いは比較的小さいことがわかります。
(2) Web3.0時代の大規模アプリケーション向けシステムアーキテクチャ
ブロックチェーンのない時代、アプリケーションは集中システムと分散システム上に構築されました。たとえば、ショッピング モール、IM、ビデオなどのアプリケーションは集中システム上に構築され、Thunder ダウンロードは分散システム上に構築されます。
ブロックチェーンシステムによりWeb3.0時代を迎え、この時代のアプリケーションはブロックチェーンシステム、分散システム、集中システムを基盤とした複雑なアーキテクチャとなっています。このうち、ブロックチェーン システムとその第 2 層拡張は価値の送信と処理を完了し、分散システムと集中型システムは情報の送信と処理を完了します。
以下に示すように、
具体的な内容は次のように説明されています。
(1) ビットコインのメインネットワークと第 2 層の構築はすべての価値の中心であり、価値のほとんどはこのネットワーク上に構築されます。ビットコインの第 2 層構造では、チェーンベースの第 2 層が性能拡張と価値の処理を完了し、すべての台帳データを処理します。ビットコインの第2層構築では、分散システムに基づく第2層構築で性能の拡張が完了し、ローカルの関連データを処理し、関係者の合意を利用しますが、最終的な計算結果はブロックチェーンに実装する必要がありますシステム。ビットコインの第 2 層構造は、集中型システムに基づく第 2 層構造により、上位層のアプリケーションに直接サービスを提供します。
(2) RGB に似たシステムでは、図の青い線で示すように、元帳の決済機能を完了するためにいくつかの一時的なチェーンまたは中間チェーンも必要になります。参考資料 1 のゲーム例では、このシナリオについて説明しています。 RGB に似たシステムの構築は複雑であり、まだ成熟していないため、大規模には登場しませんでした。
(3) ビットコイン エコシステムに加えて、さまざまなビジネス シナリオのニーズを満たす他のブロックチェーン システム エコシステムもあります。第 2 層インフラストラクチャに関する記事で説明したように、チェーンに基づいて第 2 層には多くのプロジェクトが存在し、ビットコイン以外のエコロジカル チェーンにも適用できます。他のブロックチェーン システムや第 2 レイヤーもライトニング ネットワークや RGB に参入することができ、これはテクノロジーが成熟するにつれて徐々に実現されるでしょう。
(4) Web3.0 エコシステムにも集中型システムが登場しますが、その割合は Web2.0 ほど大きくはなりません。集中型システムには多くの利点があります。
(5) 実際のアプリケーションでは、上図の内部配線はさらに複雑になり、RGBがBPプロトコルを使用する場合など、第2層を使用せずに第1層のネットワークを直接動作させる場合もあります。他のブロックチェーンも、イーサリアム上の雷電ネットワークのように分散システムを利用する可能性があり、未熟ではあるが、需要シナリオがあれば、いくつかの基本機能を変換することで利用シナリオが存在するだろう。上の図は、Web3.0 アプリケーション アーキテクチャを簡略化して説明したものです。
3.4. 実現可能な建設経路
収益構造から BTC エコシステムの現在のアプリケーション ニーズがわかり、一般的に使用されるアプリケーションの分類から、将来的に Web3.0 に本格的に参入する必要性がわかります。長い道のりになるでしょう。したがって、比較的工期が長いものについては段階的に対応する必要がある。
ここでの 3 つの段階は、ダシャン先生が言及した短期、中期、長期と非常によく似ています。チェーンベースの第 2 層構築の簡単な段階を構築の第 1 段階にまとめただけです。
(1) 第 1 段階は、碑文と鎖に基づく 2 層構造の初期段階です。
刻印ベースおよびチェーンベースの 2 層構造は比較的容易であり、現在多くの用途に使用されています。 BRC 20、SRC 20、ARC 20、インスクリプションなどのアプリケーション、またはチェーンベースの第 2 層建設プロジェクトのパーティーなど、それらはすべて豊富です。
この段階での構築は比較的単純で、そのほとんどは金融アプリケーションであり、イーサリアムの第 2 層を変換および模倣した経験のサポートにより、より簡単かつ高速になります。このプロセスは比較的単純ではありますが、不可欠かつ重要であり、生態系の繁栄を助け、トラフィックと資金を集め、クロスチェーン接続技術をテストし、ステーブルコインをテストし、さまざまな可能性をテストしました。この段階では主に、機能実現可能性のさまざまな検証を完了します。
(2) 第 2 段階は、チェーン型 2 層構築と分散システム型 2 層構築の中期・後期です。
この段階では、チェーンベースの第 2 層構築も含まれており、これはチェーンベースの構築の発展段階であり、第 2 フェーズでは、さまざまな分散第 2 層構築のテストと改善に重点が置かれています。ライトニングネットワークはより成熟し、RGB 機能と安定性が大幅に向上し、アプリケーションシナリオがより豊富になります。 BitVM など、RGB に似た競合他社が徐々に出現し、成熟するでしょう。同時に、Nostr のような分散システムにも価値関数が組み込まれるようになります。この段階では主に、機能およびパフォーマンスの実現可能性に関するさまざまな検証を完了します。
(3) ビットコインエコロジーを活用した大規模工事
最後の段階は成熟段階で、Web3.0 が大量に構築され始め、徐々に成熟していきます。 3.1 で説明した一般的なアプリケーションは Web3.0 時代に入り始めています。
もしかしたら、この段階に到達するまでにはさらに長い時間がかかるかもしれませんが、おそらく、多数の Web2.0 アプリケーションの参入を促進するような変曲点イベントが発生するかもしれませんが、その時間はそれほど長くないかもしれません。
何はともあれ、本当のWeb3.0時代が来れば、今までのPCインターネット＋モバイルインターネット全体よりも機能も生産価値も大きく輝くことは間違いありません。おそらくそれは、AI分野におけるソラの出現に似ており、非常に驚くべきことであり、衝撃的ですが、そのプロセスはそれほど突然ではありません。
参考説明
(1) ビットコイン生態学の短期、中期、長期の側面に関するダシャン氏の記事とコースの内容を参照してください。
(2)「不可能が可能になる：ライトニングネットワークでフルチェーンゲーム開発を実現」https://m.jinse.cn/news/blockchain/3667669.html(この記事によってさらにインスピレーションと検証が行われます)
(3) 3 つの観察角度は主に「図解イーサリアム EVM」、武信 T.、2018.3 を参照しています。
(4) アプリケーション分類に関連する内容については、主に著者が 2022 年に執筆した『Web3.0: Building a Digital Future for the Metaverse』を参照してください。
(5) 大学のデジタル論理におけるグラフ理論の知識を参照する。
(6) 分散システムに関するいくつかの記事を参照します。
