分散ロールアップを 1 つの記事で理解する

元のタイトル:「分散型ロールアップ」

ロールアップの使用が増加し、エコシステムのアプリケーションをホストするようになると、ユーザーの移行コストが増加し、集中注文者が価格設定に対して独占的な影響力を得るようになります。集中注文者の管理者は、直接的 (例: 手数料を通じて) および間接的 (例: フロントランニング トランザクション、サンドイッチ攻撃などを通じて) の両方で、ユーザーからの価値抽出 (MEV) を最大化することが正当化されます。 - エスプレッソ

Espresso チームが述べたように、集中型ロールアップは最終的に独占価格と MEV の問題に直面することになります。さらに、一元化されたロールアップは本質的に構成可能性を損ない、断片化したロールアップにつながります。 **

ただし、分散型で権限のないスケーラブルなロールアップを構築するのは非常に困難であるため、現在のほとんどすべてのロールアップは依然として一元化されています。もう 1 つの理由は、最初に集中ロールアップを立ち上げることで、エコシステムを育成し、市場シェアを獲得できる可能性があることです。

そして、分散型ロールアップ、特に zkRollups について議論する場合、分散化には 2 つのレベルがあります。 1 つ目は証明者の分散化であり、2 つ目は注文者の分散化です。完全な分散化を実現するには、発注者と証明者間の調整問題も解決する必要があります。

モジュール化の傾向に伴い、現在、分散型ロールアップには主に 3 つのタイプの参加者がいます。最初のカテゴリは、完全に分散化されたロールアップを実現することを目的としており、完全なソリューションを提案します。 2 番目のカテゴリは、証明者ネットワークを解決するために設計されたプロトコルです。最後に、ソーターの分散化に取り組んでいるソリューションが複数あります。

分散型ロールアップ

zkRollups では、Polygon と Starknet がロールアップを分散化するソリューションを考案しました。

ポリゴン

POE (Proof of Efficiency) の導入前、Polygon zkEVM は POD (Proof of Donation) を採用し、仕分け業者が次のトランザクション バッチを作成する機会を入札できるようにしました。ただし、これにより、単一の悪意のある当事者が最高値を入札することでネットワーク全体を制御できるという問題が生じます。

POE の採用後、発注者と証明者は、独自のハードウェア条件下で最も効率的にパーミッションレス ネットワークに参加できるようになります。経済的に合理的であれば、誰でも Polygon zkEVM に参加できます。

Polygon zkEVM では、ソーターには 16 GB の RAM と 4 コア CPU が必要ですが、証明者には 1 TB の RAM と 128 コア CPU が必要です。さらに、アグリゲーターと呼ばれる役割があり、L1 データを収集し、証明者に送信し、証明を受信して L1 に送信する責任があります。集約者と証明者の関係は非常に単純であり、集約者は証明を作成するために証明者に支払いを行うため、集約者と証明者を同じ主体とみなすことができます。

このアーキテクチャは非常に単純です。どの注文者も許可なく L1 上の以前の状態に基づいてトランザクションをパッケージ化し、対応する状態を更新できます。同時に、アグリゲーターは更新された状態を検証するための証明を送信できます。

POE では、効率とは、互いに競争する参加者のネットワーク効率だけでなく、シーケンサーや証明者自体の経済効率も指します。 L2 では、注文者と証明者が取引手数料を共有し、注文者は証明を生成するためにバッチ手数料をアグリゲーターに支払います。これにより、参加者はネットワークの効率化に貢献するという経済的な動機が確実に得られ、より堅牢で持続可能なエコシステムが実現します。

選別機

  • 収入:L2トランザクション手数料
  • コスト:batchFee ($MATIC で計算) + L1 トランザクション手数料 (sequenceBatches メソッドの呼び出し)

アグリゲーター (証明者)

  • 収入:バッチ手数料 ($MATIC で計算)
  • コスト: 証明コスト + L1 トランザクション手数料 (verifyBatchesTrustedAggregator メソッドを呼び出す)

コーディネーター:バッチフィー

  • 初期パラメータ
  • バッチ手数料 = 1 $MATIC
  • VeryBatchTimeTarget = 30 分。これは検証バッチの目標時間です。プロトコルは、この目標時間を達成するために、batchFee 変数を更新します。 +乗数BatchFee = 1002。これはバッチ料金乗数であり、範囲は 1000 ~ 1024 (小数点以下 3 桁) です。
  • レギュレーター
  • diffBatches : 30 分を超える集計バッチ数から 30 分以下のバッチ数を引いた値。最大値は 12 です。

*調整プロセス

  • diffBatches > 0 の場合、アグリゲーターにインセンティブを与えるためにアグリゲーション報酬を増やします。

  • diffBatches < 0 の場合、集計報酬を減らしてアグリゲータを抑制し、集計プロセスを遅くします。

スタークネット

Starknet は、高速確認の許可不要でスケーラブルなロールアップを構築することも目指しています。分散型ソリューションの最終仕様にはまだ達していませんが、数か月前にフォーラムでいくつかの草案を公開しました。

Polygon zkEVM の単純なメカニズムと比較すると、Starknet のスキームは、証明ネットワークに L2 コンセンサスと連鎖された Proof-of-a-Protocol が含まれているため、より複雑です。

選別機

Starknet は、単に発注者レイヤー内にコンセンサスレイヤーを追加するのではなく、デュアルレジャーコンセンサスプロトコルを提案しています。このプロトコルでは、L2 はライブ プロトコルとして高速応答を提供し、L1 チェックポイントは安全なプロトコルとして最終確認を提供します。

L2 のライブ プロトコルでは、Tendermint や DAG などの Sybil 耐性 PoS システムなど、さまざまなコンセンサス メカニズムを採用できます。一方、L1 の安全なプロトコルには、ステーク管理、証明検証、ステータス更新をそれぞれ処理する複数のコントラクトが含まれます。

デュアルレジャーコンセンサスプロトコルの一般的なワークフローは次のとおりです。

  1. まず、L2 ライブ台帳の出力を L1 セーフ台帳の入力として使用して、チェック済みライブ台帳を生成します。

  2. 次に、チェックされたライブ台帳を入力として取得し、それを L2 の純粋なコンセンサス プロトコルに再度入力して、チェックされたライブ台帳が常にライブ台帳のプレフィックスになるようにします。

  3. 上記のプロセスを繰り返します。

デュアルレジャーコンセンサスプロトコルを構築する場合、コストと遅延の間にはトレードオフがあります。理想的なソリューションは、低コストと迅速な最終承認の両方を達成することを目指しています。

L2 のガスコストを削減するために、Starknet ではチェックポイントを「分レベル」と「時間レベル」に分割しています。 「分レベル」チェックポイントの場合、状態自体のみがチェーンにコミットされ、残りのデータ (有効性証明、データ可用性など) は StarkNet L2 ネットワーク経由で送信されます。これらのデータは、StarkNet フル ノードによって保存および検証されます。一方、「時間ごと」のチェックポイントは L1 で公的に検証されます。どちらのタイプのチェックポイントでも、同じ最終確認が行われます。 「分レベル」チェックポイントの場合、有効性証明は StarkNet フルノードによって検証され、L1 上の任意のノードによって発行されて、「分レベル」チェックポイントに L1 ファイナリティを与えることができます。したがって、証明者は、L2 ネットワークで広く配布される小さな証明を生成する必要があります。

待ち時間をさらに短縮するために、Starknet はリーダーを事前に決定するリーダー選出プロトコルを提案しています。基本的なロジックは次のとおりです。現在のエポック i のリーダーは、ステークされた L1 の量とランダム性に基づいて事前に決定されます。具体的には、エポック i-2 では、リーダー_選挙メソッドにより、エポック i-3 の誓約額に基づいてソーターが辞書順に並べられます。次に、トランザクションを送信してノンスを更新し、ランダムにポイントを選択します。ポイントが落ちた位置に対応するソーターがエポック i のリーダーになります。

認証者

POE モジュールでは、参加者間でオープンな競争が行われ、勝者総取りの状況が発生する可能性があります。 Starknet は、集中化のリスクを伴うことなく競争メカニズムを実現しようとしています。以下にいくつかのオプションがあります。

  • ローテーション: これは集中化の問題を部分的に解決できますが、研究を証明するのに最適な人材を見つけるインセンティブにはならない可能性があります。
  • 賭け金ベース: ソーターは、賭け金に基づいて証明者として選出される確率を決定します。
  • Commit-Reveal スキーム: 最初のコミッターは、短い独占の機会を得るためにトークンを誓約し、この時間枠内にプルーフを生成する必要があります。 DDoS 攻撃を回避するために、前者が時間内に証明を生成できない場合、後者が必要とする担保トークンは指数関数的に増加します。このメカニズムでは、ネットワークは最高のパフォーマンスを持つマシンを失う可能性がありますが、より多くの証明者を育成することができます。

証明者間の競争に加えて、より多くの証明者がネットワークに参加できるように参入障壁を下げる必要があります。 Starknet は、連鎖プロトコル証明と呼ばれる再帰証明を利用した複雑なプロトコルを提案しています。

プルーフ・オブ・チェーン・プロトコルでは、ブロックチェーン自体がいくつかの異なるフォークに分割されます。このようにして、証明を再帰的に実行できるだけでなく、証明の生成も同時に行うことができます。たとえば、3 分岐設定では、12 個の黒いブロックが 3 つの行に分割され、各行が分岐を表します。各ブランチは、各ブロックが前のブロックを証明するサブチェーンとして考えることができます。チェーン全体の観点から、スロット n はスロット n-3 を証明する必要があります。 3 ブロックの間隔により、注文者が事前にプルーフを計算して購入するのに十分な時間が確保されます。これはシャーディングに似ており、攻撃者は 1 つのブランチを制御するだけで証明者のネットワーク全体を制御できます。

これらのブランチを結合するために、Starknet は、複数のノードを結合してトランザクションの正当性を共同で検証し、トランザクション記録の一貫性と信頼性を確保できるウィービング テクノロジーを提案しています。

1 つの解決策は、各スロットを同時に複数のブランチとマージする必要があることを要求することです。もう 1 つの解決策は、各ブランチを他のブランチとマージすることを交互に試行し、それによって証明の作業負荷を軽減することです。もちろん、これは未解決の問題でもあり、将来的にはより良い解決策が見つかる可能性があります。

調整

証明者が十分な利益余地を確保できるように積極的に確保するために、Starknet は EIP1559 スキームを参照する方法を提案しています。つまり、基本料金を証明者のリソース価格の下限として設定し、価格発見を積極的に行い、ソーターはチップを使用できます。証明者に動機を与えるため。このようにして、証明者には常に過大な報酬が支払われることになり、極端な場合のみ証明プロセスに影響を与えることになります。そうしないと、証明者が市場価格に近い報酬を受け取った場合、わずかな変動が証明者ロックアウトを引き起こす可能性があります。

認証者の分散化

ロールアップの観点から見ると、証明者はソーターよりも分散化を達成するのが簡単です。また、現在の証明者はパフォーマンスのボトルネックとなっており、ソーターのバッチ速度に対応する必要があります。ソーターの分散化が解決されていない場合、分散証明者は集中ソーターにサービスを提供することもできます。

実際、Rollups だけでなく、zkBridge と zkOracle にも証明者ネットワークが必要です。これらはすべて、証明者の強力な分散ネットワークを必要とします。

長期的には、さまざまなコンピューティング能力に対応できる証明者ネットワークの方が持続可能です。そうしないと、最高のパフォーマンスを発揮するマシンが市場を独占してしまいます。

プルーフマーケット

一部のプロトコルは、シーケンサーと証明者の間の関係を調整せず、調整をプルーフ マーケットに直接抽象化します。この市場では、証明は商品であり、証明者は証明の生産者であり、プロトコルは証明の消費者です。市場の均衡は「見えざる手」の影響下で最も効率的になります。

### 私の

ミナは、Snark プルーフが取引される Snarketplace と呼ばれるプルーフ マーケットプレイスを設立しました。ここでの最小単位は、単一トランザクションの Snark 証明です。ミナは、Scan State と呼ばれる状態ツリーの再帰的証明を使用します。

スキャン状態は、各トランザクションがノードとなるバイナリ ツリーのフォレストです。ツリー内のすべてのトランザクションを証明できる単一の証明がツリーの最上位に生成されます。証明者には 2 つのタスクがあります。1 つ目は証明を生成すること、2 つ目は証明をマージすることです。

証明者が作業を完了して入札を送信すると、Mina プロトコルのブロック作成者が最低価格の入札者を選択します。入札者はプルーフの価格を上回る入札を提出し、ブロックプロデューサーは金額に見合わないプルーフを購入しないため、これは均衡価格でもあります。

=なし。財団

mina のプルーフ マーケットは独自のプロトコル向けに設計されていますが、=nil; Foundation は市場全体にサービスを提供する一般的なプルーフ マーケットを提案しています。

マーケット サービスは、DROP DATABASE、zkLLVM、Proof Market の 3 つのコンポーネントで構成されます。

※ DROP DATABASE: データベース管理システムのプロトコルであり、DA 層とみなすことができます。

  • Proof Market: DROP DATABASE 上で実行されるアプリケーションで、zk-proof の「分散型取引所」と呼ばれるものに似ています。
  • zkLLVM: 高級プログラミング言語を証明可能なコンピューティング プロトコルの入力に変換するコンパイラーです。

各プルーフは異なる入力と回路で構成されているため、それぞれのプルーフは固有です。回路は、金融用語で「トランザクション ペア」が定義される方法と同様に、証明のタイプを定義します。さらに、異なる証明システムではさらに多くの回路が導入されます。

ワークフローは次のとおりです。プルーフのデマンド側は高級プログラミング言語でコードを記述し、それをツールチェーンを通じて =nil;zkLLVM に供給し、市場で固有の取引ペアとなる単一の回路を生成します。

需要を証明する側は、コストと時間の間でトレードオフを行うことができます。証明者は、計算能力と収入も考慮します。したがって、市場にはさまざまなコンピューティング能力が存在し、コンピューティング能力が高いとプルーフの生成は速くなりますが、コストは高くなります。一方、コンピューティング能力が低いとプルーフの生成は遅くなりますが、コストは安くなります。

2 段階コミット

最近、Opside は証明者ネットワークを分散化するための 2 段階コミット スキームを提案しました。このスキームは、最も速い証明者が常に勝つという状況を避けるために、証明の提出を 2 つのフェーズに分割します。

  • ステップ 1: T 番目のブロックのゼロ知識証明のハッシュを送信する
  • ブロック T+11 以降、新しい証明者はハッシュを送信できなくなります。
  • ステップ 2: ゼロ知識証明を提出する
  • T+11 番目のブロックの後、証明者はゼロ知識証明を提出できます。少なくとも 1 つのゼロ知識証明が検証に合格した場合、その証明は提出されたすべてのハッシュの検証に使用され、検証された証明者は住宅ローンの金額に比例して対応する PoW 報酬を受け取ります。
  • T+20 番目のブロックまでにゼロ知識証明が検証されなかった場合、ハッシュを提出したすべての証明者がペナルティを受けます。次に、ソーターを再度開き、新しいハッシュを送信して、ステップ 1 に戻ります。

この方法は、さまざまな計算能力に対応できます。ただし、必要な担保により、依然として集中化レベルが導入されます。

仕分け機の分散化

注文者の分散化は、バリデーターの分散化よりも複雑です。これは、仕分け業者が取引を梱包して整理する権限を持っており、MEV や所得分配などの問題を考慮する必要があるためです。

イーサリアムが応答性よりもライブ性を優先することを考えると、L2 ソリューションはライブ性よりも応答性を優先することでこのトレードオフを補完する必要があります。ただし、集中型ソーターと比較すると、分散型ソーターは本質的に応答性の点で犠牲になります。したがって、このジレンマを解決するには、さまざまな最適化を実装する必要があります。

現在、3 つの異なる分散型ソーターの提案があります。最初の解決策は、コンセンサス メカニズムを最適化することで実現されます。 2 番目のスキームには、共有シーケンサーのネットワークが含まれます。 3 番目のスキームは L1 バリデータに基づいています。

コンセンサス

コンセンサス プロトコルは主に、トランザクションの順序付けとその可用性の確保を担当し、トランザクションを実行するものではありません。ただし、前述のように、別のコンセンサス層を直接追加することは簡単な解決策ではありません。

応答性を向上させるための一般的なアプローチは、少数のバリデーターのセットに依存することです。たとえば、Algorand と Polkadot は、ランダムにサンプリングされた小規模な委員会を使用してトランザクションをバッチ処理します。すべてのノードはランダム ビーコンと検証可能なランダム関数 (VRF) を使用し、ステーク額に比例して一定期間内に委員会に含まれる確率が設定されます。

ネットワーク トラフィックを減らすために、より小規模なデータ可用性 (DA) 委員会を使用できます。または、VID (検証可能な情報分散) を使用します。 VID は、コンセンサスに参加しているすべてのノードにデータの消去コードを配布するため、十分に高いプレッジ率を保持しているノードのサブセットが協力してデータを復元できます。このアプローチのトレードオフは、ブロードキャストの複雑さは軽減されますが、データ回復の複雑さは増加することです。

Arbitrumは、ConsenSys、Ethereum Foundation、L2BEAT、Mycelium、Offchain Labs、P2P、Quicknode、IFFの分散台帳研究センター(DLRC)、および仕分け委員会に参加するUnit 410など、バリデータセットを形成する信頼できるエンティティを選択しました。このアプローチのトレードオフは、分散化の質を向上させることで量の不足を補うことです。

共有シーケンサー ネットワーク

ソーターは、モジュラーブロックチェーン、特にロールアップにおいて重要な役割を果たします。通常、各ロールアップは独自のソーター ネットワークを構築します。ただし、このアプローチでは冗長性の問題が生じるだけでなく、構成可能性も妨げられます。この問題を解決するために、一部のプロトコルでは、共有ロールアップ ソーター ネットワークを構築することが提案されています。このアプローチにより、ユーザーと開発者がオープンなパーミッションレス ブロックチェーンで切実に必要とする機能である原子性、構成可能性、相互運用性を実現する際の複雑さが軽減されます。さらに、注文者ネットワーク用に別個のライト クライアントを用意する必要もなくなります。

アストリア

Astria は、独自の分散注文者のコレクションを含む Celestia のロールアップ エコシステム用のミドルウェア ブロックチェーンを開発しています。この順序付け者のセットは、複数のロールアップからトランザクションを受け入れ、それらを実行せずに基本レイヤーに書き込む責任があります。

Astria の役割は主にトランザクションの順序付けに焦点を当てており、ベース レイヤやロールアップとは独立して動作します。トランザクション データはベース レイヤー (Celestia など) に保存されますが、ロールアップ フル ノードは状態を維持し、操作を実行します。これにより、Astria がロールアップから切り離されることが保証されます。

最終的には、アストリアは 2 つのレベルのコミットメントを提供します。

  • 「ソフト コミットメント」: ロールアップがエンド ユーザーに迅速なブロック確認を提供できるようにします。 ※「しっかりとしたこだわり」:ベースレイヤーと同等の速度で、より高いセキュリティとファイナリティを確保します。

### エスプレッソ

エスプレッソはゼロ知識テクノロジーの分野で多大な貢献をしてきました。彼らの最新の開発は、Optimistic Rollups と zkRollups に適用できる分散ソーターのための包括的なソリューションです。

分散型発注者ネットワークは次のもので構成されます。

  • HotShot コンセンサス: 動的な可用性よりも高スループットと高速ファイナリティを優先します。
  • Espresso DA: 委員会ベースの DA ソリューションと VID を組み合わせたもので、高帯域幅のノードが他のすべてのノードにデータを供給します。個々のブロックの可用性は、ランダムに選出された小規模な委員会によってもサポートされています。 VID は信頼性は高いがバックアップが遅くなり、すべてのノードのステーク ウェイトの十分に高い割合が損なわれない限り、可用性が保証されます。
  • ロールアップ REST API: JSON-RPC と互換性のあるイーサリアム。
  • シーケンサー コントラクト: HotShot コンセンサスを検証し (つまり、ライト クライアントとして機能し)、チェックポイントを記録し (つまり、トランザクションに対して暗号化コミットメントを行います)、HotShot のプレッジ テーブルを管理します。 ※P2Pネットワーク:ゴシッププロトコル。

Astria と比較して、Espresso は DA を提供します。したがって、ワークフローは次のように若干異なります。

  1. ユーザーはトランザクションを作成してロールアップに送信します。

  2. トランザクションは発注者ネットワークを通じて伝播され、メモリプールに保持されます。

  3. HotShot 誓約メカニズムを通じてリーダーを指定し、ブロックを提案し、それを Rollup の実行者と証明者に伝播します。

  4. リーダーはトランザクションをデータ可用性委員会に送信し、フィードバックとして DA 証明書を受け取ります。

  5. リーダーはまた、ブロックの検証にコントラクトが使用する証明書とともに、ブロックへのコミットメントをレイヤー 1 ソーター コントラクトに送信します。

Espresso では、より柔軟なユーザー エクスペリエンスを提供するために、プルーフに Gossip プロトコルを導入しています。トランザクションのファイナリティに関して 3 つのオプションが提供されます。

  • 高速: ユーザーは、トランザクションを実行してプルーフを生成したロールアップ サーバーを信頼することも、HotShot の低遅延を利用してトランザクションを実行することもできます。
  • 中程度: ユーザーはプルーフが生成されるまでしばらく待ってから、それを確認できます。
  • 遅い: ユーザーは、信頼の仮定や計算を行わずに、L1 検証済み状態の更新を待って、更新された状態を取得できます。

上記の最適化に加えて、Espresso は、Ethereum バリデーター セット全体を Espresso オーダラー プロトコルの実行に参加させることも計画しています。同じバリデーターのセットを使用すると同様のセキュリティが提供され、L1 バリデーターと値を共有するとより安全になります。さらに、Espresso は、EigenLayer が提供する ETH 再ステーキング ソリューションを利用することもできます。

半径

Radius は、L2 の収益が主にブロック スペースから得られるため、L2 における MEV 問題の解決に焦点を当てて、ゼロ知識証明に基づいたトラストレスな共有順序付けレイヤーを構築しています。考慮すべきトレードオフは、MEV と L2 の収益のバランスです。 Radius は、ユーザーにとって有害な MEV を排除することを目標としており、2 層のサービスを提案しています。

最上位層は通常のユーザー トランザクションをターゲットにし、タイムロック パズルを使用して不要な MEV に対する暗号保護を提供します。具体的には、実用的検証可能遅延暗号化 (PVDE) テクノロジーを採用しており、RSA ベースのタイムロック パズルのゼロ知識証明を 5 秒で生成します。この方法は、有害な MEV からユーザーを保護するための実用的なソリューションを提供します。つまり、シーケンサがトランザクションの順序を決定するまでは、トランザクションの内容はわかりません。

基礎となるレイヤーはブロック ビルダー向けに設計されており、ブロック ビルダーが MEV の悪影響を軽減しながら収益を生み出す活動に参加できるようにします。

ベースのロールアップ

Based Rollup は、Justin Drake によって最近提案された概念で、L1 ブロックの提案者が L1 検索者および構築者と協力して、許可なく次の L1 ブロックにロールアップ ブロックを含めます。これは、L1 上の共有シーケンサーのネットワークとして見ることができます。 Based Rollup の長所と短所は明らかです。

良い面としては、Based Rollup は L1 によって提供されるライブ性と分散化を利用しており、その実装はシンプルかつ効率的です。 Based Rollup は経済的にも L1 と整合性があります。ただし、これは、Based Rollup がその主権を侵害することを意味するものではありません。 MEV は L1 に引き渡されますが、Based Rollup は引き続きガバナンス トークンを所有し、基本料金を請求することができます。仮説に基づいて、Based Rollup はこれらの利点を活用し、優位性を達成し、最終的に収益を最大化することができます。

## 結論は

提案された提案を見ると、ロールアップの分散化にはまだ長い道のりがあることがわかります。これらの提案の中には、まだ草案の段階にありさらなる議論が必要なものもあれば、暫定仕様のみが完成したものもあります。これらのシナリオはすべて実装され、厳密にテストされる必要があります。

一部のロールアップは、対応する分散ソリューションを明示的に提案していない場合がありますが、多くの場合、集中注文者による単一障害点に対処するためのエスケープ メカニズムが含まれています。たとえば、zkSync は、ユーザーが L1 から直接資金を引き出すことができる FullExit メソッドを提供します。システムがエクソダス モードに入り、新しいブロックを処理できない場合、ユーザーは引き出し操作を開始できます。

検閲への耐性を実現するために、これらのロールアップでは、多くの場合、ユーザーが L1 でトランザクションを直接送信することもできます。たとえば、zkSync は、L1 で送信されるトランザクションに優先キューを使用します。同様に、Polygon zkEVM には、L1 コントラクトに強制バッチ メソッドが含まれています。 1 週間以内に集計が行われない場合、ユーザーは L1 でこのメソッドを呼び出し、トランザクションのバイト配列と BathFee を証明者に提供できます。

確かなことは、予見可能な将来において、Rollup の分散化は、上記の重要なソリューションやその他の革新的なバリエーションを含む組み合わせソリューションになるということです。

原文表示
内容は参考用であり、勧誘やオファーではありません。 投資、税務、または法律に関するアドバイスは提供されません。 リスク開示の詳細については、免責事項 を参照してください。
  • 報酬
  • コメント
  • 共有
コメント
0/400
コメントなし
  • ピン
いつでもどこでも暗号資産取引
qrCode
スキャンしてGate.ioアプリをダウンロード
コミュニティ
日本語
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • ไทย
  • Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)