まとめ
Supra は、長年にわたるイノベーションを強力で高性能なアーキテクチャに統合し、MultiVM スマート コントラクト サポートと、価格オラクル、オンチェーン乱数、クロスチェーン通信、自動化機能などのネイティブ サービスと完全に垂直統合されています。
これに基づいて、この記事では Supra ブロックチェーンのエンドツーエンドのトランザクション プロセスを詳しく説明し、検閲リスクと最大抽出可能値 (MEV) 攻撃の脅威を効果的に軽減する方法を示します。
Supra ネットワークは、共有セキュリティ プラットフォームに基づいて幅広いサービスと機能を提供します。これらには、分散 Oracle プロトコル (DORA)、分散検証可能ランダム関数 (DVRF)、ブロック遅延ゼロの自動化ネットワーク、AppChain からインスピレーションを得たコンテナ アーキテクチャ、マルチ VM サポート、並列トランザクション処理による最適化などの革新的なテクノロジが含まれます。ブロック実行。さらに、Supra のクロスチェーン設計 (HyperLoop と HyperNova) により、Supra はスマート コントラクト プラットフォーム ロジックを通じてマルチチェーン相互接続を実現する世界初の「IntraLayer」になります。
1. ブロックチェーンサービスのネイティブかつ完全な垂直統合
Supra は、画期的な研究と優れたエンジニアリング能力を通じてブロックチェーン技術の変革を促進することに取り組んでおり、その目標は、さまざまなブロックチェーン関連サービスを完全に統合して、個人ユーザー、機関顧客、開発者に統合ソリューションを提供する効率的なレイヤー 1 ブロックチェーンを構築することです。スムーズなユーザーエクスペリエンス。
この記事では、Supra テクノロジーが古代ギリシャの哲学者アリストテレスの有名な言葉「全体は部分の合計よりも優れている」をどのように解釈するかを示します。Supra は、完全な垂直統合の概念に準拠し、包括的なブロックチェーン機能と、サービス 、豊富なエコシステム開発と多様なアプリケーション シナリオをサポートします。
コア機能の概要
dApp 用の Supra ブロックチェーンによって提供されるネイティブ サービス (図 1 を参照) は、次のコア機能をカバーします。
レイヤ 1 ブロックチェーン
ネイティブ トークン、プログラム可能な代替可能および代替不可能なトークン、標準化されたクロスチェーン トークンなど、複数の資産タイプをサポートします。
スマートコントラクト実行環境
DeFiプロトコル、ブロックチェーンゲーム、宝くじ、サプライチェーン追跡などのさまざまなパブリックブロックチェーンアプリケーションに適した、チェーン上でさまざまなチューリング完全なスマートコントラクトプラットフォームを提供します。
オフチェーン データ サービス
仮想通貨の価格オラクル、外国為替レート、株価指数、気象データなどを含む、デマンドベース (プル) およびストリーミング (プッシュ) データ サービスを提供します。これらのデータは、Supra の Distributed Oracle Protocol (DORA) を通じて送信されます。DORA は、Supra ブロックチェーンにサービスを提供するだけでなく、他のブロックチェーン ネットワークもサポートします。
図 1 完全な垂直統合
プッシュおよびプルのオンチェーン乱数サービス<br/>乱数サービスを生成および配布するために、Web 2.0 および Web 3.0 ユーザーにストリーミングおよびオンデマンド形式で分散検証可能ランダム関数 (dVRF) を提供します。
オートメーション ネットワーク<br/>は、DORA を通じて提供される特定の時間ノード、オンチェーン イベント、またはオフチェーン イベントに基づいてトランザクションの実行をスケジュールするために使用されます。たとえば、クライアントは「2025 年 6 月 1 日、東部標準時ちょうど 12:00 に、ETH 価格が $4,000 を超えたら私の DOGE を売ってください」というリクエストを行うとします。
アプリケーション固有のチェーン (AppChain)
Supra 上のコンテナは、導入コストを大幅に削減しながら AppChain の柔軟性と自律性を提供し、Supra ネットワークの高いパフォーマンス、共有セキュリティ、統一された流動性の恩恵を受けます。
2. IntraLayer: Supra と他のブロックチェーンを接続する
Supra は一連のネイティブ サービスを提供していますが、私たちはマルチチェーン エコロジーの現実と価値を深く理解しています。相互運用性を向上させるために、スター トポロジを設計しました (図 2 を参照)。この構造では、Supra の L1 ブロックチェーンとその統合サービスが IntraLayer ネットワークのコアとして機能し、他の L1 および L2 ブロックチェーンを接続する相互運用性ソリューション HyperLoop および HyperNova を通じて問題を解決します。 。
独立した MultiVM スマート コントラクト プラットフォームとして、Supra は独自のサービスを提供するだけでなく、マルチチェーン エコシステムで重要な役割を果たすことにも取り組んでいます。この役割は、「ネットワーク間」または「ネットワーク内」での価値の交換に反映されており、ネイティブのスマート コントラクト、自動化機能、およびオラクル サービスを通じて安全かつ効率的な通信を可能にします。
ハイパーループ
HyperLoop は、従来のマルチシグネチャ クロスチェーン プロトコルに基づいており、ゲーム理論によって厳密に分析および検証されたセキュリティ ソリューションであり、クロスチェーン トランザクションの信頼性を確保するための業界初の革新的な設計です。
ハイパーノヴァ
HyperNova はトラストレスな相互運用性ソリューションとして、クロスチェーン通信に高いセキュリティを提供し、マルチチェーン エコシステムにおける情報と価値の交換のための強固な基盤を築きます。
HyperLoop と HyperNova を通じて、Supra は広範なチェーン間の相互接続を実現し、ユーザーと開発者に強力なツールを提供し、マルチチェーン エコロジーの徹底的な統合と開発を促進します。
図 2 Supra の IntraLayer
接続されたチェーンのセキュリティは、従来のクロスチェーンまたはリレー ノードのセキュリティの前提に依存しません。ここでは、HyperLoop と HyperNova が最適な具体的なシナリオの概要を説明します。
ハイパーループ
HyperLoop クロスチェーン ソリューションは、ファイナリティを達成するために必要な不正防止チャレンジ期間を排除できるため、Optimistic Rollup を Supra に接続するのに特に適していることがわかりました。ハイパーノヴァ
接続されたチェーンのセキュリティを維持するために、Supra インタラクティブ チェーンのコンセンサスを再計算することで L1 間のセキュリティを維持するため、Proof-of-Stake (PoS) L1 ブロックチェーンを Supra に接続するのに適しています。 Supra の L1 ブロックチェーンは、安全かつ効率的なクロスチェーン通信を促進するように特別に設計されています。
私たちの計画には、HyperNova を使用して Bitcoin を Supra にクロスチェーンすると同時に、HyperLoop を介したリバース接続を可能にすることが含まれています。さらに、クロスチェーンの相互運用性をさらに向上させるために、この環境でアトミックスワップを実装する方法を模索しています。
Supra IntraLayer テクノロジー スタックを活用したコア機能の一部を以下に示します。
DeFiイントラレイヤー
「プラットフォーム上のプラットフォーム」として、Supra はさまざまな主流の DeFi プロトコル (AMM など) をカプセル化します。 dApp 開発者は、複数のブロックチェーンの資産や情報に簡単にアクセスできるため、クロスチェーン開発プロセスが簡素化されます。クロスチェーン自動化サービス
ユーザーは複数のブロックチェーンからのイベントとデータに基づいて自動化されたタスクを設定できるため、ユーザーエクスペリエンスと運用効率が大幅に向上します。
私たちは、複数のネイティブ サービスを高性能 L1 ブロックチェーンに完全に垂直統合することが、世界初のクロスチェーン イントラレイヤーを構築するという私たちのビジョンと非常に一致すると確信しています。他のブロックチェーン上で当社のサービスに対する需要が増加し続けるにつれて、当社のトークンやオンチェーン資産を含むスープラネットワークの有用性により、価値に自然な変動が生じ、ユーザーや顧客が当社のインフラストラクチャを採用するようさらに奨励されることになります。
同時に、IntraLayer アーキテクチャがさまざまなエコシステムで広く使用されているため、ますます多くの開発者がネイティブ サービスと優れたパフォーマンスに惹かれ、Supra ブロックチェーン上で直接アプリケーションを開発および構築することを選択するでしょう。これにより、社内で開発されたプロトコルやサードパーティのプロトコルを含む DeFi レイヤーが強化されるだけでなく、ネットワーク全体の導入と魅力も促進されます。
私たちは、Supra がその優れたパフォーマンスとワンストップで多様なサービスにより、開発者コミュニティに Web 3.0 テクノロジーの普及の次の波をもたらし、エコシステム全体の急速な発展に貢献すると信じています。
3. Supra の核心 - 「部族と氏族」ノード モデル
Supra の基本的な哲学は、完全に垂直統合され、事実上すべてのブロックチェーン関連サービスを単一のプラットフォーム上で提供することです。このソリューションにより、ユーザーと開発者は統一されたスムーズなエクスペリエンスを確実に得ることができます。
完全な垂直統合 vs モジュラーレイヤー 2
Supra は、従来のモジュラー L2 ソリューションとは異なる垂直統合アーキテクチャを採用しています。
L2 では、コア機能 (コンセンサス、実行、データ可用性など) が独立したネットワークに分散されますが、この設計は「モジュール性の利点」と呼ばれますが、次のような多くの問題を引き起こします。
遅延の増加:ネットワーク間の通信により時間遅延が発生します。
経済セキュリティは分散化されています。異なるネットワークは独自のトークンを持ち、セキュリティを共有できません。
高度な複雑さ:全体的なアーキテクチャの保守と調整がより困難になります。
対照的に、Supra の完全に垂直統合された設計では、すべてのコンポーネントが単一のブロックチェーンに統合されます。
経済的安全性の共有と統一されたトークンエコノミー。
通信遅延を大幅に削減し、システムパフォーマンスを向上させます。
統合されたインセンティブ メカニズムによりネットワーク セキュリティが強化されます。
全体的な運用コストの削減。
ビザンチンフォールトトレランスのブレークスルー
分散システムの調査によると、非同期または部分同期ネットワークでは、従来のビザンチン フォールト トレランス (BFT) プロトコルでは、悪意のあるノードとしてノードの最大 3 分の 1 しか許容できません。しかし、スープラの革新的な進歩により、その許容誤差は半分に増加し、前例のない安全性と効率性が可能になります。
ソートサービスと整合性チェーン
Supra L1 ブロックチェーンの中核は順序付けサービスであり、そのコンセンサス プロトコルがトランザクションの順序付けを担当し、トランザクション データの配布は順序付けサービスから分離されています。したがって：
ブロックには、特定のトランザクション データではなく、トランザクション バッチのメタデータ (ダイジェストやデータ可用性の証明など) のみが含まれます。
これにより、Supra ブロックチェーンのブロックが非常に小さくなり、運用効率が大幅に向上します。
注文サービスは他のすべてのサービスの中核基盤であるため、私たちはスープラ ブロックチェーンを「インテグリティ チェーン」と呼んでいます。
より多くのビザンチン ノードを許容することが重要なのはなぜですか?
より多くの Byzantine ノードを許容することの直接的な利点は次のとおりです。
小規模な委員会: たとえば、50 の悪意のあるノードを許容するには、従来の方法では 151 人のメンバーが必要ですが、Supra では 101 人のメンバーのみが必要です。
コストの削減: コンセンサスノードの数が減るということは、補償する必要があるノードの数が減り、その結果、ユーザー料金が安くなるということを意味します。
実行速度の向上: コンセンサスノードが少なくなるため、強力なセキュリティを維持しながらプロセスが高速化されます。
図 3 部族、氏族、家族
部族、氏族、家族
このコアは、Supra ブロックチェーン上の複数のサービスの効率的かつ完全な垂直統合を促進します。 Supra は、部族、氏族、家族レベルでさまざまなアルゴリズムの実行をサポートする新しいネットワーク フレームワークを提案しています。
図 3 に示すように:
Tribe は、ビザンチン ノードの最大 3 分の 1 を許容するノードの委員会です。
クランは、ビザンチン ノードの最大半分を許容するノード委員会です。
ファミリは、少なくとも 1 つの正しいノードを必要とするノードの委員会です。
最適なパフォーマンスと強力なセキュリティを実現するために、当社のネットワークは次のように設計されています。アクティブ ノードは、コンセンサス プロトコルを実行し、順序付けサービスを強化し、最大 3 分の 1 のビザンチン ノードを許容するトライブに編成されます。
私たちの設計の重要なポイントは、Supra トライブ全体がトランザクションの実行に参加したり、完全な Supra 状態を維持したりする必要がないことです。代わりに、「クラン」と呼ばれる小さなサブセットが状態を管理し、トランザクションを実行し、ブロックの事後状態を計算し、状態のコミットメントに署名します。したがって、トランザクション データの配布は最初はクラン レベルでのみ発生し、その後さらにブロードキャストされます。
このアーキテクチャは、異なるクランが異なる状態のシャードを管理し、場合によっては個別の仮想マシンを使用する効率的な状態シャーディングに適しています。この設計によりスケーラビリティが向上し、クラン (またはシャード) を追加することでスループットを調整できるようになります。したがって、コンセンサス以外のすべてのプロトコル (データ配布、シャード実行、オラクル サービス、分散乱数サービスなど) は、正しいノードの単純過半数のみを必要とする小さな委員会 (クラン) で実行されます。
ノードをランダムに選択してクランにすることで、順序付けられたクランと複数のサービス クランをまとめて編成し、これらのクランが実際にクランのパーティションを形成するようにします。コンセンサスまたはグローバルな順序付けは部族で実行され、さまざまな検証可能な計算サービスはクランで実行されます。このノードのランダムな選択により、クラン レベルでの実行が可能になり、システムに確率の要素が導入されます。たとえば、トライブが 625 個のノードで構成され、最大 208 個のビザンチン ノードがあると仮定します。部族がそれぞれ 125 ノードを持つ 5 つの氏族に分割された場合、いずれかの氏族のノードの半分以上 (つまり 62) がビザンチン ノードである確率は約 35 × 10 ⁻⁶ です。言い換えれば、部族に 33% のビザンチン ノードがある場合、「悪い氏族」が存在する確率は 100 万分の 35 にすぎません。実際には、これらの確率は非常に低いです。期間や期間について議論する際には、これらの確率をさらに分析し、実際にはそれらがほとんど無視できることを示します。
4. お取引の流れ
Supra チェーンのトランザクション プロセスは大まかに次のとおりです。具体的な手順については、後続の章で詳しく説明します。
図 4 は、Supra ブロックチェーンにおけるエンドツーエンドのトランザクション プロセスを示しています
ユーザーは、Supra の Starkey ウォレット [3] または dApp を通じてトランザクションを送信します。ウォレットは、トランザクション ttt の送信先となるゲートウェイ RPC ノードに接続されます。
ゲートウェイ RPC ノードは、トランザクション ttt を、基本的な検証と分類に基づいて特定のバッチ プロポーザのプライマリ バケットに送信し、トランザクションを他のバッチ プロポーザのセカンダリ バケットに送信します。
バッチ プロポーザーは、プライマリ バケットからトランザクションをパックし、タイムアウトしたトランザクションをセカンダリ バケットからバッチに追加します。詳細についてはセクション 5 を参照してください。
バッチは、xRBC プロトコルを通じて対応する実行クラン ノードに伝播されます。バッチをブロックに含める前に、データ可用性クォーラム証明書 (DAQC) を形成する必要があります。これらの証明書はトライブ全体に伝播され、バッチはゲートウェイ RPC ノードに伝播されます。
Tribe ノードは Supra の Moonshot コンセンサス プロトコルを実行します。ブロック プロポーザーは、これらの DAQC と関連するバッチ メタデータをパッケージ化してブロックを構築します。
コンセンサス プロトコルはブロックを順序付けするため、バッチ全体でトランザクションを間接的に順序付けします。ブロックが完成すると、コンセンサスプロトコルを実行しているすべてのトライブノードとすべてのクランノードに表示されます。完成したブロックはゲートウェイ RPC ノードにも伝播されます。
クランノードは、最終ブロックから対応するトランザクションのバッチを実行し、現在のブロックチェーンの最後でブロックチェーンの状態を更新します。その後、事後状態を計算し、マークル化操作を実行し、新しいマークル ルートを計算します。異なるクランは異なるバッチを並行して実行することに注意してください。クラン ノードはこのマークル ルートに署名し、それをクラン全体およびゲートウェイ RPC ノードに伝播します。
ゲートウェイ RPC ノードはブロックを実行し、事後状態とそのマークル ルートを計算し、それが受信した署名付きマークル ルートと一致していることを確認し、トランザクションが完了したときにウォレットに通知します。
最終確認段階
私たちのワークフローでは、トランザクションは次の 3 つの異なるファイナリティ ステージを通過し、それぞれがブロックチェーン上のトランザクションのステータスについてより強力な保証を提供します。
事前確認段階
トランザクション ttt を含むバッチ bbb がデータ可用性クォーラム証明書 (DAQC) を取得すると、トランザクション ttt がブロックチェーンに含まれることが保証されます。この段階では、トランザクションが含まれることは保証されていますが、その具体的な場所や実行結果はまだ決定されていません。ソートファイナリティ
コンセンサスプロトコルがバッチ bbb を含むブロックの最終確認を完了すると、ブロックチェーン内のトランザクション ttt の位置は固定され変更不可能になり、他のトランザクションとの相対的な実行順序が決まります。実行のファイナリティ
これで最終段階は終了です。クランノードはバッチ bbb を実行し、トランザクション ttt の実行結果でブロックチェーンの状態を更新し、新しい状態のマークル化バージョンを作成し、生成されたマークル ルートに署名し、ブロードキャストして状態コミットメントを形成します。この段階が完了すると、トランザクションの実行結果は最終的なものとなり、元に戻すことはできません。
Supra L1 は高速ファイナリティタイムをサポートします。私たちの実験におけるこれらのさまざまな最終段階の観察時間は、セクション 7 で報告されています。
次の章では、上記のトランザクション プロセスの重要な手順について詳しく説明します。
図 5 メモリ プールを使用しないバケット化スキーム
5. メモリプールを使用しないバケットソリューション
まずイーサリアムとソラナの既存のメモリプールプロトコルについて説明し、次にスープラがそれらをどのように改善するかを示します。
イーサリアムメモリプールソリューション
従来の Ethereum メモリ プール プロトコルのプロセスは次のとおりです。
クライアント (ウォレット) はトランザクションを RPC ノードに送信し、RPC ノードはゴシップ プロトコルを通じてトランザクションをブロードキャストし、すべてのコンセンサス バリデーターに到達します。
バリデーターがブロック提案者になると、受信したトランザクションをパッケージ化しようとします。
ブロック提案者は、トランザクションをブロックに含めないようにすることでトランザクションを検閲しようとする場合がありますが、すべてのコンセンサスバリデーターがこれらのトランザクションを保持しているため、ブロック提案者となる次のラウンドのバリデーターには、見逃されたトランザクションまたは検閲されたトランザクションが含まれることになります。したがって、このプロトコルは検閲に耐性があります。
一般的なブロックチェーン アーキテクチャでは、クライアント (Web3 ウォレット) がトランザクションをパブリック RPC ノードに送信します。次に、RPC ノードは、ポイントツーポイント ゴシップ プロトコルを通じて、トランザクションを RPC ノード ネットワーク全体とコンセンサス バリデーター ネットワークに伝播します。これらのノードは、クライアントから送信されたトランザクションを一時的に保存するために「mempool」と呼ばれるデータ構造を維持します。
次に、ブロック ビルダーはメモリプールからトランザクションを取得し、それらをブロックにパッケージ化し、コンセンサス プロトコルを通じて処理します。ブロックがファイナリティに達すると、含まれているすべてのトランザクションも最終的なものとみなされます。
ビットコインとイーサリアムのメモリプールには未処理のトランザクションの大量のバックログがあるため、平均すると、トランザクションはブロックビルダーによって選択されるまで、メモリプールに長期間留まります。さらに、ポイントツーポイントのゴシップ プロトコルでは、トランザクションを伝播する際の遅延がさらに増加します。
Solana のメモリ プールなしソリューション
メモリ プールの待ち時間を短縮するために、Solana は次のプロセスを使用してメモリ プールレス プロトコルを採用しています。
ブロックは、ブロック提案者によって事前に決定された固定スケジュールに従って生成されます。
クライアント (ウォレットなど) はトランザクションを RPC ノードに送信します。RPC ノードは、読み取りおよび書き込みアクセス情報などの補助データをトランザクションに添付し、ブロックを提案しようとしている一部のプロポーザーに送信します。提案者がトランザクションを逃した場合、他の提案者はそのトランザクションを後続のブロックに含めます。
Solana ネットワークでは完全なファイナリティを達成するには 32 回のブロック確認が必要であることに注意することが重要です。 Solana はエンドツーエンドの遅延を最適化するように設計されていますが、それでもトランザクションの重複が時折発生し、ネットワークの停止を引き起こす可能性があります。 Ethereum の mempool プロトコルと比較して、Solana は意図されたブロック提案者への直接通信を使用します。これは、トランザクション伝播遅延を効果的に削減するアプローチです。
Supra メモリ プールレス プロトコル ソリューション
Solana と同様に、Supra はメモリプールレス プロトコルを使用しますが、従来のネットワーク全体のゴシップ プロトコルを対象を絞った通信に置き換えます。ただし、Supra のアプローチは 2 つの重要な点で異なります。
1. 即時ファイナリティ
Solana のタイムスロットベースのシステムとは異なり、Supra は Moonshot と呼ばれる古典的な Byzantine Fault Tolerance (BFT) PBFT スタイルのコンセンサス プロトコルを使用します (詳細は以下を参照)。 Moonshot プロトコルでは、Solana のように 32 回のブロック確認を待つことなく、ブロックが送信証明書 (QC) を受け取ると即座にファイナリティを達成できます。これにより、トランザクションの最終確認時間が大幅に短縮され、システムのパフォーマンスが向上します。
2. メタデータのバッチ保存
Supra のコンセンサス設計では、ブロックにはトランザクション データが直接含まれませんが、トランザクション バッチの DAQC とメタデータが格納されます (詳細についてはセクション 6 を参照)。図 5 に示すように、mempoolless プロトコルでは、クライアント ウォレットからのトランザクションは、指定されたバッチ プロポーザーによって管理されるバケットに入れられます。
当社のバケット化ソリューションの特徴は次のとおりです。
1) 重複排除メカニズム
各トランザクションには、トランザクションをバッチに含める責任を負う固有のマスター バッチ提案者が割り当てられます。この単一責任モデルにより、重複したトランザクションがブロックチェーンにパッケージ化されることが自然に防止されます。
2) 冗長性と検閲耐性
トランザクションが見逃されないように、バックアップとしてサブバッチ プロポーザーを導入しました。プライマリ バッチ プロポーザが時間内にトランザクションを含めることができなかった場合、セカンダリ バッチ プロポーザはタイムアウト後にトランザクションをバッチに含めます。
複数のセカンダリ プロポーザがトランザクションを同時に処理すると、パッケージ化が重複する可能性がありますが、Supra システムはトランザクションの最初の発生まで一貫性を維持します。
繰り返されるトランザクションは、オンチェーンのステータスに影響を与えることなく、無効なトランザクション シーケンス番号により実行フェーズ中に自動的に終了されます。
3) 変更できない責任記録
二次プロポーザーがトランザクションをブロックに正常に含めると、一次プロポーザーがその義務を果たせなかったことを証明する不変のレコードが生成されます。この記録は、その後のネットワーク分析に使用して、トランザクションを検閲したり、システムの公平性と信頼性を確保するために不必要な遅延を引き起こしたりするバッチ提案者にペナルティを与えることができます。
メモリ プールを使用しないバケット化ソリューションの具体的なプロセスは次のとおりです。
各バッチ プロポーザーは、プライマリ バケットとセカンダリ バケットの 2 つのバケットを維持します。
トランザクション ttt ごとに、システムはその一意で予測不可能な識別子 (ハッシュ) に基づいて、トランザクションを特定のバッチ プロポーザー ファミリに割り当てます。このファミリーでは、1 つのノードがトランザクション ttt のプライマリ バッチ プロポーザーとして指定され、残りのノードがセカンダリ バッチ プロポーザーになります。
RPC ノードは、ウォレットまたは dApp フロントエンドからトランザクション ttt を受信すると、トランザクションの識別子に基づいて、対応するバッチ プロポーザー ファミリにそれを転送します。プライマリ バッチ プロポーザはトランザクション ttt をプライマリ バケットに保存し、セカンダリ バッチ プロポーザはトランザクション ttt をそれぞれのセカンダリ バケットに保存します。
新しいバッチを構築するとき、バッチ提案者はすべてのトランザクションをそのプライマリ バケットに含める必要があります。ビザンチン動作 (特定のトランザクションをプライマリ バケットから除外することで検閲するなど) を防ぐために、セカンダリ バッチ プロポーザーはバックアップ メカニズムとして機能します。
バッチが完了し、バッチ プロポーザーによって監視されると、プロポーザーはバッチに含まれていたトランザクションをプライマリ バケットとセカンダリ バケットから削除します。
さらに、各トランザクション ttt には構成可能なタイムアウトがあります。タイムアウト前に完成したバッチに ttt が含まれていない場合、そのファミリー内のサブバッチ提案者は、次のバッチを構築するときにサブバケットからの ttt を含める必要があります。このメカニズムにより、トランザクションが見逃されることがなくなり、システムの検閲耐性が高まります。
図 6 既存ソリューションとの概念的な比較
この 2 層の設計は、効率的な重複排除と強力な検閲耐性の間で巧みなバランスをとっています。さらに、セカンダリ バッチ プロポーザがトランザクションをバッチに正常に組み込むと、プライマリ プロポーザがその義務を実行できなかったことを証明する不変レコードが生成されます。この記録はその後の分析に使用でき、トランザクションを検閲したり不必要な遅延を引き起こしたバッチ提案者にペナルティを課すことができます。
6. メモリ プールレス アーキテクチャ: トランザクション データの配布とトランザクションの並べ替えを効率的に分離する
次に、Supra が部族クラン アーキテクチャを通じてトランザクション データの配布とトランザクションの順序付けを効率的に分離する方法を紹介します。
近年、一部のプロトコル (Narwhal/Tusk [11] や Bullshark [20] など) はトランザクション データ送信の重要性を認識し、データ送信をトランザクション順序から切り離す新しい設計パラダイムを採用しました。この設計では、並行して実行される 2 つのサブプロトコルを通じて、それぞれデータ送信と並べ替えを実装します。
順序付け要件がない場合、データ送信は、分散システムで広く研究されている基本動作である信頼性の高いブロードキャスト (RBC) に縮小されます。
具体的には、ノードは RBC サブプロトコルを通じて新しいデータ ブロックを継続的に提案および伝播し、その後、これらのデータ ブロックが決定され、順序付けサブプロトコルを通じて出力されます。
この設計により、帯域幅リソースの利用が効果的に最適化され、従来の方法と比較してシステムのスループットが大幅に向上します。 Supra もこの原則に従っており、データ送信とトランザクション順序を切り離しています。ただし、現在の最先端のコンセンサス プロトコルでも、最適化の焦点は依然として主に順序付けサブ プロトコルにあり、実際にはシステムの実際のボトルネックとは逆であることがわかりました。
たとえば、Tusk [11] と Bullshark [20] の主な利点は、いわゆるゼロメッセージ ソートであり、ソート段階での通信オーバーヘッドが完全に排除されます。しかし、以前に指摘したように、通信コストの主な発生源は注文ではなく、データ送信です。
図 6 は、私たちのアプローチと既存のソリューションを比較しています。私たちの目標は、データ送信フェーズ中の各ノードの送信量を削減すること、特に単一ノードの最大送信負荷を削減することです。実際のアプリケーションでは、多くの場合、ネットワーク帯域幅がシステム スループットの主な制限要因になります。したがって、データ送信プロセスを最適化することで、システム全体のパフォーマンスと効率をさらに向上させることができます。
Supra の xRBC プロトコル
同じノードのセットによって実行される独立した順序付けサービスを使用するという革新により、データ転送の通信コストを大幅に削減します。
従来のアプローチでは、データ送信は通常、Reliable Broadcast (RBC) プロトコルを介して実行されます。 RBC は、放送局が異なるデータ バッチを異なるノードに送信することを防ぐために、システム内の 2/3 以上の正直なノードを必要とします (つまり、送信者の曖昧さの問題)。
ただし、独立した順序付けサービスを利用することで、データ転送を xRBC と呼ばれる緩和された RBC 操作に改善できることがわかりました。 xRBC では、データ送信を完了するために必要な誠実なノードの 1/2 以上だけが必要となるため、通信コストが大幅に削減されます。
xRBC の設計上の利点
xRBC では、参加ノードだけでは送信者の曖昧さを完全に防ぐのに十分ではありません。この問題を解決するために、順序付けサービスはブロードキャスターのバッチを認証し、正直なノード間の合意を確保し、意見の相違を排除します。順序付けサービスには依然として超過半数 (正直なノードの 2/3 以上) の保証が必要ですが、xRBC には次の点で従来の RBC に比べて大きな利点があります。
通信オーバーヘッドの低減: 大部分の正直なノードへの依存を減らすことにより、プロトコルの動作における通信の複雑さが軽減されます。
パフォーマンスの向上: xRBC は、従来の RBC と同等のセキュリティを維持しながら、データ転送をより効率的に処理するように設計されています。
クラン分散データ配信の活用
トランザクションはクラン (部族のランダムなサブ評議会) 内でのみ実行されるため、トランザクション データは最初はそのクランを実行しているノードにのみ転送されます。これにより、ネットワーク帯域幅の負荷が大幅に軽減され、部族全体にデータを分散するよりも効率的になります。各実行クラン内で、ノードのサブセットをバッチ プロポーザーとして指定します。バッチ プロポーザーは、それぞれのバケットからトランザクション バッチを構築し、クラン内のすべてのノードに送信する責任を負います。
異なるクランのバッチ プロポーザーは、プロトコル ステップを同期したり待機したりすることなく、トランザクション バッチを独立して並行して伝播できることは言及する価値があります。この並列非同期伝播メカニズムにより、データをプッシュする際のネットワーク帯域幅の利用効率が最大化されます。
さらに、状態の同期を達成するために、後続の段階でトランザクション データがトライブ全体にさらに伝播される可能性があります (エポック間のノードの再分配を容易にするため、詳細についてはセクション 9 を参照)。この段階的なデータ配布設計により、ネットワーク パフォーマンスを確保しながら、システムの一貫性と柔軟性が確保されます。
図 7 xRBC プロトコル
具体的なプロセス (図 7 に示す)
バッチ提案者は、トランザクション バッチを構築し、それをクラン内のすべてのノードに送信する責任があります。
クラン ノードが有効なバッチを受信すると、バッチのデータの可用性について投票し、投票結果をクラン内のすべてのノード、クラン内の他のノード、および指定されたゲートウェイ RPC ノードにブロードキャストします。
単純多数決が可決されると、システムはデータ可用性証明書 (DAQC) を生成し、少なくとも 1 つの正直なノードが完全なトランザクション データを保持していることを確認します。
ノードにバッチ データの一部が欠けている場合、単純に大部分のクラン ノードからデータを要求することができ、DAQC はこの要求が満たされることを保証します。
サイズのしきい値を超えるバッチの場合、またはすべてのクラン ノードがバッチ プロポーザーとして機能しない場合、クラン内でのデータの均一な分散を確保し、帯域幅の使用効率を最適化するためにイレイジャー コーディングを導入します。
ブロックの内容とファイナリティ
ブロックにはバッチ証明書のみが含まれます。コンセンサスプロトコルのバリデーター（トライブノード）がブロック提案者として機能する場合、受信した DAQC のすべてのバッチをブロックにパッケージ化します。ブロックがファイナリティに達し、バリデーターによって確認されると、含まれているこれらの DAQC はファイナライズされたブロックに記録されており、保持する必要がなくなったので、バリデーターはキャッシュから削除します。
ブロックにはバッチ証明書のみが含まれ、トランザクション データは直接保存されないため、Supra ブロックチェーンは実際には非常に軽量なブロックチェーンです。この設計により、ブロック サイズが大幅に縮小され、データ伝送効率が向上します。
7. コンセンサスプロトコル
ビザンチン フォールト トレランス (BFT) コンセンサス プロトコル: ブロックチェーンの中核
BFT コンセンサス プロトコルはブロックチェーンの中核コンポーネントであり、ブロックに標準的な順序を提供する役割を担っており、それによってブロック内のトランザクションにも標準的な順序があることが保証されます。私たちは、ムーンショット SMR と呼ばれる新しい BFT コンセンサス プロトコルを革新的に設計しました。これは、古典的な実用ビザンチン フォールト トレランス (PBFT) プロトコルに触発され、これに基づいてパフォーマンスの最適化を実行しました。
前述したように、コンセンサス プロトコルはトライブ内で実行されますが、トランザクションの実行はクランに限定されます。したがって、Moonshot は柔軟な設計を採用しており、実際のトランザクション スループット要件に応じて柔軟に適応できます。ブロックにはトランザクション データが直接含まれず、バッチ証明書のみが含まれるため、システムがより効率的かつ軽量になることに注目してください。
ムーンショットパフォーマンス
Moonshot は次の主要なパフォーマンス指標を達成します。
連続したプロポーザル遅延 (2 つのブロック プロポーザル間の最小遅延): 1 メッセージ遅延 (MD)。
提出遅延: 3 日。
バッチ伝播とデータ可用性証明書生成の累積遅延: 2 md。
ブロックはネットワーク ホップごとに提案されるため、データ可用性証明書をキューに入れて次のブロック提案を待つ必要があり、平均キュー遅延は 0.5 md です。
したがって、システムの全体的なエンドツーエンド遅延は 5.5 md です。
正式な検証: プロトコルのセキュリティを確保する
分散プロトコルには複雑な動作と無限の状態空間があることが多く、その正しさを証明することが非常に困難になります。形式検証は、プロトコルにエラーがないことを数学的に証明できるため、プロトコルのセキュリティを確保するためのゴールドスタンダードです。
この目的を達成するために、Microsoft の IvY 検証ツールを使用して Moonshot コンセンサス プロトコルのセキュリティ特性を正式に検証し、そのネバーフォーク機能を厳密に証明し、プロトコルの正確性とセキュリティの数学的保証を提供しました。
実験による評価
Google Cloud Platform (GCP) で広範な評価を実施し、ノードを 5 つの異なるリージョンに均等に分散しました。
us-east 1-b (サウスカロライナ州)
us-west 1-a (オレゴン州)
ヨーロッパ北 1-a (ハミナ、フィンランド)
アジア北東1-a（東京）
オーストラリア南東 1-a (シドニー)
実験設定は次のとおりです。
クライアントとコンセンサスノードは同じ場所に配置されます
各トランザクションは 512 バイトのランダム データで構成され、バッチ サイズは 500 KB に設定されます。
各実験は 180 秒間実行されます
レイテンシの測定: トランザクションの生成から障害のないすべてのノードによる送信までの平均時間を計算し、エンドツーエンドのレイテンシを決定します。
スループット測定: 1 秒あたりに完了したトランザクション数に基づいて評価
私たちがテストしたアーキテクチャは、60 ノードずつの 5 つのクランに分割された 300 ノードで構成されていました (GCP リージョンごとに 12 ノードがデプロイされています)。この構成では、300 ノードのネットワーク内のクラン (60 ノード) が内部不正多数により失敗する確率は 0.0107 です。
それにもかかわらず、私たちの目標は、このアーキテクチャの高いパフォーマンスを実証するだけでなく、大規模なシステムでも高スループットと低遅延を維持できることを実証することです。
ハードウェア構成:
それぞれ 32 個の vCPU、128 GB のメモリ、および最大 16 Gbps の出力帯域幅を備えた 2-standard-32 マシンを使用しました。
これらの実験を通じて、パフォーマンスとスケーラビリティの点で Supra アーキテクチャの強力な機能を検証しました。
図 8 スループットとエンドツーエンド遅延
図 8 に示すように、システム スループットとエンドツーエンド遅延の関係を観察しました。
スループットが 500,000 TPS に達しても、エンドツーエンドの遅延は 1 秒未満にとどまります。
300,000 TPS では、遅延は約 650 ミリ秒であり、これはアーキテクチャ設計の理論上の限界に近い値です。
さらに、データ可用性証明書 (DAQC) の生成時間を測定したところ、約 160 ミリ秒でした。
要約すれば：
トランザクションの事前確認遅延は約 160 ミリ秒です。
ソートファイナリティの待ち時間は 1 秒未満です。
DAGコンセンサスプロトコル
DAG (有向非巡回グラフ) コンセンサス プロトコルの研究に触発されて、私たちは Sailfish と呼ばれる新しい DAG コンセンサス プロトコルを設計しました。このプロトコルは、システム スループットを犠牲にすることなく、送信遅延を 1 信頼性の高いブロードキャスト + 1 メッセージ遅延 (MD) に最適化し、現在の最先端の DAG コンセンサス プロトコルのパフォーマンスを上回ります。
さらに、Sailfish のバリアントを開発し、それを部族一族のアーキテクチャと組み合わせて、システムのスループットをさらに向上させました。現在、この設計について広範な実験テストを行っています。大規模なネットワーク環境で Sailfish が既存の Moonshot プロトコルよりも優れたパフォーマンスを発揮する場合、コア コンセンサス プロトコルを Sailfish に切り替えて、より効率的なコンセンサス プロセスを実現する予定です。
図9 Supraの並列実行方法
8.実行
ブロックチェーンの現在の状態には、すべての資産とその所有権情報、およびすべてのスマート コントラクトの最新データが含まれています。ファイナライズされたブロックトランザクションを実行する場合、該当するステート部分をロードし、ブロック内のトランザクションの順序でステートを更新し、変更されたステートを永続的に保存する必要があります。
最新のブロックチェーンでは、トランザクション処理能力が継続的に向上しているため、トランザクションの最終確認のエンドツーエンドの遅延において、実行時間は無視できない重要な要素となっています。この傾向は、Solana、Sui、Aptos、Monad などのチェーンで特に顕著であり、実行を並列化することでレイテンシーを効果的に削減します。
当社の部族クラン アーキテクチャでもトランザクションの並列実行が可能ですが、ネットワーク レベルで最適化されています。具体的には、トランザクションの実行はクラン内に限定され、異なるクランがそれぞれのトランザクション バッチを並行して処理するため、システムの実行効率が大幅に向上します (図 9 を参照)。
8.1 トランザクションの並列実行
ネットワーク レベルでの並列処理の実現に加えて、単一ノード内のマルチコア プロセッサを最大限に活用してトランザクションを効率的に並列実行する方法も掘り下げました。現在、文献や業界で一般的な並列実行方法は、主に次の 2 つのカテゴリに分類されます。
楽観的/投機的実行テクニック
決定論的な依存関係に基づいた所定の手法
ソフトウェア トランザクション メモリ (STM)
STM テクノロジーは、マルチコア プログラムの並列実行のために従来のコンピューティングの分野で広く使用されています。 Aptos の BlockSTM は、ブロックチェーン トランザクションの実行に STM テクノロジーを導入します。その中心的なアイデアは次のとおりです。
利用可能なすべてのコアでトランザクションを並列に最適化して実行します。
次に、トランザクション間に依存関係の競合があるかどうかを確認します。
競合が見つかった場合、競合するトランザクションは協調スケジューラを通じて再実行されます。
超革新的なソリューション
私たちは、Aptos の BlockSTM とは異なり、スケジューラーなしで競合を効率的に解決できる革新的な STM 並列実行アルゴリズムを提案します。このアプローチは、パフォーマンスとアーキテクチャの点で BlockSTM に匹敵しており、現在、実際のアプリケーションにおける利点を検証するために設計の詳細な評価を行っています。
アクセス仕様に基づく並列化
一部のブロックチェーンは、トランザクションのアクセス パターンを指定することで並列化を実装します。
Solana の Sealevel では、トランザクションで読み取りおよび書き込みが必要なアカウントを明示的に宣言する必要があります。
Sui では、トランザクションが (オブジェクト識別子を介して) 読み書きされるオブジェクトを指定し、これらのオブジェクトが排他的であるか共有されるかを宣言する必要があります。
Polygon のアプローチは異なります。ブロック プロポーザーは BlockSTM テクノロジーを使用してブロックを実行し、トランザクション間の依存関係を事前に計算し、これらの依存関係情報をブロックに含めることで、他のバリデーターが独立したトランザクションを並行して実行できるようにします。
ただし、トランザクションでアクセス モードを明示的に宣言するか、ブロックに依存関係情報を含めると、ブロック サイズが大幅に増加することに注意することが重要です。これにより、帯域幅がより早く飽和し、システムが達成できる最大スループットが制限される可能性があります。
これらのメソッドを利用して、スマート コントラクトを静的に分析し、コントラクトのデプロイ時にそのアクセス仕様を自動的に導出し、RPC ノードやウォレットの提供アクセス モードを必要とせずにこれらの仕様をブロックチェーン状態に保存する決定論的並列実行アルゴリズムを開発しています。 。これらの仕様により、ファイナライズされたブロック内のトランザクションの線形順序を部分的な (緩和された) 順序に最適化し、独立したトランザクションの並列実行が可能になります。この方法では、帯域幅の使用量が削減されるだけでなく、システム全体のスループットと効率も向上します。
混合法
私たちは、静的に導出されたアクセス仕様を活用して STM アルゴリズムを改善するハイブリッド アプローチが、最適化された実行技術の究極の形であると信じています (図 9 を参照)。現在、この設計について総合的な評価を行っております。
8.2 執行命令の公平性
トランザクションの順序付けの公平性を確保するために、次の 2 段階のプロセスを設計しました。
初期ランダム順序付け: コンセンサス プロトコルは、最初にトランザクションの初期ランダム シード順序付けを生成します。
最終的な順序付け: ブロックベースの BLS しきい値署名によって生成されたオンチェーン乱数プロトコルを通じて、最終的なトランザクションの順序付けが導出され、トランザクションの実際の実行順序が決定されます。
この追加のランダム化レイヤーは、バッチ プロポーザーまたはブロック プロポーザーが最終的なランダム化されたトランザクションの実行順序を予測したり操作したりできないため、最大抽出可能値 (MEV) 攻撃を効果的に軽減します。
スパム問題に対処するために、私たちはローカル料金市場を導入しました。紛争状態では、トランザクションのコストが指数関数的に増加するため、システムの耐干渉能力が向上し、同時にトランザクションの順序付けの効率と公平性が確保されます。
8.3 マルチVM
イーサリアムはチューリング完全オンチェーンプログラミング環境であるEVMを導入し、dApp開発の創造性を大きく解き放ち、特にDeFiアプリケーションに強力なサポートを提供しました。 EVM は Web 2.0 プログラミング言語の経験を取り入れて、Solidity を誕生させました。しかし、ブロックチェーン技術の発展に伴い、コミュニティは徐々に、資産転送とオンチェーン資産管理用に特別に設計されたプログラミング言語が必要であることに気づきました。そのため、Meta の Diem チームは Move 言語を開発し、後に Aptos Move や Sui Move などの亜種を生み出しました。
Supra は、カスタマイズされたオンチェーン トランザクション プログラミング言語の重要性を深く認識しているため、スマート コントラクト プラットフォームの最初の選択肢として Move 言語を選択し、Move のサポートを受けて L1 ブロックチェーンを開始します。
同時に、マルチ VM エコシステムには大きな可能性があるとも考えています。異なる仮想マシンの開発者は相互に補完し、ブロックチェーン業界の革新と発展を共同で促進できます。したがって、効率的なマルチ VM アーキテクチャを設計しました。
トライブ クラン アーキテクチャの自然なシャーディング特性に基づいて、各クランはステート シャードをホストし、異なるクランは異なる仮想マシンをホストできます。
Move スマート コントラクト プラットフォームを統合した後、Supra はイーサリアム仮想マシン (EVM) までさらに拡張し、巨大なイーサリアム エコシステムとの互換性を実現します。次に、Rust、C、C++ などの広く使用されているプログラミング言語を使用してスマート コントラクトを構築する開発者をサポートするために、Solana 仮想マシン (SVM) を統合します。
最終的には、Supra も CosmWasm をサポートし、アクティブな Cosmos エコシステムとのシームレスな接続が可能になります。
仮想マシン間の通信
マルチ VM 環境では、ユーザーが異なる仮想マシン上に複数のアカウントを持ち、仮想マシン間で資産を転送したい場合があります。さらに、Supra のネイティブ トークン $SUPRA は、すべての仮想マシンで均一に管理する必要があります。この問題を解決するために、シンプルで効率的な 3 ステップのワークフローを提案します。
仮想マシン間転送トランザクションを送信する ユーザーは仮想マシン間アセット転送トランザクションを開始します。このトランザクションは次の 2 つの部分で構成されます。
ソース仮想マシンの借方トランザクション tdt_dtd
ターゲット仮想マシンの受信トランザクション tct_ctc。
トランザクション ttt が最初にソース仮想マシン上で実行され、推論が完了し、対応するイベントがトリガーされます。
イベントの監視と送信: ソース仮想マシンのクランからファミリをランダムに選択します (ファミリには少なくとも 1 つの正直なノードが含まれます)。これらのノードは控除イベントを監視し、アカウント トランザクション tct_ctc を送信します。
ターゲット仮想マシンを実行して、ターゲット仮想マシンの借方を実行します。ターゲット仮想マシンのクランは、tct_ctc を受信して実行し、資産の借方を完了します。この時点で、仮想マシン間の転送プロセスは完了します。
9. エポックとサイクル
Supra のアーキテクチャでは、トライブへの新しいノードの追加または既存のノードの削除は、エポックの境界でのみ許可されます。エポックの期間は構成可能で、通常はブロック数またはリアルタイムで定義されます。エポックの長さは約 1 週間に設定する予定です。各エポック中、トライブ内のすべてのノードはコンセンサス プロトコルを実行することによって順序付けサービスを実行します。
図 10 に示すように、エポックはさらに複数のサイクル (サイクル) に分割され、各サイクルの一般的な期間は約 1 日です。各サイクルで、トライブ内のノードは、Supra の VRF (検証可能なランダム機能) を通じて異なるクランにランダムに割り当てられます。例えば：
エポック 1 の期間 2 (e 1 c 2) では、ノードは DORA バリデーターの役割を果たすことができます。
エポック 1 の期間 3 (e 1 c 3) では、同じノードが EVM トランザクションを実行するタスクを担当する可能性があります。
サイクルごとにノードの役割をランダムに再割り当てするこのメカニズムにより、システムのセキュリティが大幅に向上し、特定の役割や機能をターゲットにしようとする悪意のある攻撃者による攻撃を効果的に防御できます。
図10 元号と週
特定のサービス (サービス SSS など) を攻撃する攻撃者は、サービス SSS を提供するクランのノードの一部を無効にすることで、そのサービスを妨害しようとする可能性があります。
この脅威に対抗するために、分散キー生成 (DKG) プロトコルがクラン再編成のサイクルごとに実行されます。この頻繁な組み換えを実現できるのは、DKG 分野における革新、つまり高性能のクラスグループベースの DKG プロトコルの開発のおかげです。
悪いクランの出現確率
セクション 3 で述べたように、625 ノードのトライブを 5 つのクラン (それぞれ 125 ノード) に分割した場合のセキュリティへの影響を分析します。
不適切なクラン定義: ビザンチン ノードがクランの単純過半数を占めています。
悪いクラン形成の確率: 悪いクランがランダムに形成される確率は、100 万分の 35 程度です。
各期間を 1 日とし、クランは毎日再編成を通じてノードを再配布すると仮定します。これは、最も極端なケース (部族内のノードの 33% がビザンチン アクターによって制御されている) であっても、不良クランが出現する確率は非常に低く、78 年に 1 回しか発生しないと予想されることを意味します。
この極めて低い確率はほとんど無視できるものであり、強力なセキュリティを提供するクラン形成メカニズムの信頼性を十分に示しています。
10.コンテナ
Supra Container は、開発者コミュニティ向けに設計された重要な機能であり、現在人気のある Appchain の概念からインスピレーションを得ています。
私たちはアプリケーション チェーンの利点、特に dApp 開発者とそのコミュニティに主権機能を提供するという独自の価値を十分に認識しています。さらに、アプリケーション チェーンはアプリケーション ベースのビジネス モデルもサポートできます。現在、レイヤー 2、サイドチェーン、Polkadot パラチェーン、Cosmos ゾーン チェーン (ゾーン)、および Avalanche サブネット (サブネット) が、アプリケーション チェーン分野の主要なソリューションです。
ただし、これらのソリューションは、Supra L1 などの高スループットのブロックチェーンのコンテキストでは理想的ではないことも認識しています。アプリケーション チェーンは通常、次の主要な機能を提供する必要があります。
スマートコントラクトの制限付き展開
カスタムガストークン
カスタムガス価格
これらのアプリケーション チェーンがセカンダリ チェーン (パラチェーン、リージョナル チェーン、サブネットなど) でホストされている場合、そのガス価格は対応するメイン チェーン (Polkadot リレー チェーン、Cosmos Hub、Avalanche C など) の価格と同じになりません。 -チェーン）ガス価格は競争を生み出し、メインチェーンの価格によって変動することはありません。このローカライズされた手数料市場は、実際のアプリケーションに最適な、より予測可能な取引手数料エクスペリエンスをユーザーに提供します。
Supra コンテナを通じて、これらのアプリケーション チェーンの利点と高性能 L1 ブロックチェーンの機能を組み合わせて、開発者とユーザーにとってより柔軟で安定したエコロジー環境を構築することを目指しています。
図 11 コンテナ
Supra Container は、ブロックチェーン分野におけるまったく新しいコンセプトです。これを、単一または関連する dApp のグループにサービスを提供するスマート コントラクトのコレクションまたはバンドルとして定義します。 Supra コンテナを通じて、Supra のランタイム フレームワークを最適化し、dApp 開発者に Appchain のようなエクスペリエンスを提供すると同時に、次の注目すべき機能も備えています。
カスタムガストークン
カスタムガス価格
スマートコントラクトの制限付き展開
これはすべて非常に低コストで実現できるため、まったく新しいセカンダリ ネットワーク (ステーキング インセンティブを必要とするバリデーター ネットワークなど) を立ち上げる面倒なプロセスが完全に排除されます。
流動性の断片化の問題を解決する
さらに重要なことは、コンテナ間メソッド呼び出しのアトミックなコンポーザビリティをサポートすることで、アプリケーション チェーンが通常直面する大きな問題である流動性の断片化を克服できることです。この設計により、流動性の集中化を維持しながら、コンテナ間の効率的な対話が保証されます。
並列実行を容易にする
Ethereum EVM モデルでは、各スマート コントラクトには独立したストレージ スペースがあります。 Supra コンテナを EVM モデルに導入した後、ブロックチェーンの状態を複数のパーティションに分割できます。
コンテナ内トランザクションは、他のコンテナの状態に影響を与えることなく、ターゲット コンテナの状態にのみアクセスします。
この状態の分離により、コンテナ内のトランザクションの実行時間が最適化され、異なるコンテナ間の競合が軽減されます。
この機能に基づいて、並列実行を最適化するためのシンプルで効率的な作業共有キューを構築しました。この設計により、Supra コンテナーはブロックチェーンの実行効率を大幅に向上させ、開発者のエクスペリエンスを簡素化し、エコシステム全体のパフォーマンスの向上を促進します。
11. 結論
完全に垂直統合された IntraLayer としての Supra の野心的なビジョンは、長年にわたる厳密な研究を経て形になりつつあります。当社は、IEEE Security Privacy、Network and Distributed Security Symposium (NDSS)、ACM Conference on Computer and Communications Security (CCS) など、複数のトップ学術会議で多数の研究成果を発表しています。さらに、次のようなコア コンポーネントに関する一連のホワイト ペーパーを発行しました。
Moonshot および Sailfish コンセンサス プロトコル
分散 Oracle プロトコル (DORA)
分散検証可能ランダム関数 (DVRF)
効率的なクラスター分散キー生成 (DKG)
スープラコンテナ
ハイパーループ
ハイパーノヴァ
今回、Supra は、完全に垂直統合されたブロックチェーン インフラストラクチャ スタックのビジョンに関する初めての包括的なプレゼンテーションを提供します。このシステムは、長年にわたって開発された多くの革新的なプロトコルを組み合わせて、非常に高性能なオールインワンのブロックチェーンを作成します。
