メインコンテンツまでスキップ

ロールアップ概要

QoreChain の Rollup Development Kit (RDK) ―― x/rdk モジュール ―― を使うと、開発者は QoreChain 上で決済されるアプリケーション固有のロールアップを起動できます。各ロールアップは独自のブロックタイム、仮想マシン、手数料モデル、シーケンシングを持つ独立した実行環境でありながら、QoreChain のセキュリティ、耐量子暗号、データ可用性の保証を継承します。

初期段階の機能

RDK は両方のネットワークにデプロイされていますが、どちらのネットワークでもまだロールアップは作成されていないため、このセクションで説明するフローは第三者によってまだ検証されていません。メインネット（qorechain-vladi、EVM チェーン ID 9801）はチェーンバージョン v3.2.1 で稼働しており、テストネット（qorechain-diana、EVM チェーン ID 9800）はより新しいリリース（v3.2.2）で稼働しているため、詳細が異なる場合があります。このセクションではメインネットの挙動を説明します。すべてのデプロイはまずテストネットで検証し、各ページのステータスに関する注記を読んでください。いくつかの機能（ZK 検証、Celestia データ可用性、QCAI Copilot、クロス VM 呼び出し、決済レシート）は、現時点ではエンドツーエンドで利用できません。

現在存在するもの​

ステータス
登録済みのロールアップ（メインネットおよびテストネット）なし
x/rdk モジュールとそのパラメータ両方のネットワークにデプロイ済み。qorechaind query rdk config で確認できます
RDK クエリCLI と gRPC 経由で利用可能です。/qorechain/rdk/v1/… の REST ルートはメインネットでは提供されていないため、REST ベースの読み取り（TypeScript の rdk.params() を含む）はメインネットに対しては機能しません
RDK が書き込む決済アンカーなし。決済バッチは記録されますが、RDK はメインネットではまだ x/multilayer にアンカーを書き込みません
x/multilayer に登録されたロールアップレイヤーなし

より低レベルなモジュールリファレンス ―― モジュールパラメータ、ライフサイクルの内部仕様、バーン統合、マルチレイヤーアンカリング ―― については、アーキテクチャセクションの Rollup Development Kit ページを参照してください。本ロールアップセクションは開発者向けのハウツーです。RDK とは何か、どのパラダイムを選ぶべきか、どのようにデプロイするか、データ可用性の仕組み、L2 から L1 への出金の決済方法を扱います。

RDK が提供するもの​

RDK を通じて作成されたロールアップは、4 つの設定可能な要素をまとめています。

要素制御する内容選択肢
決済モードロールアップの状態遷移が QoreChain 上でどのように検証・確定されるかoptimistic、zk、based、sovereign
証明システム決済を裏付ける暗号学的または経済的メカニズムfraud、snark、stark、none
シーケンサーモード決済前にトランザクションを並べる主体dedicated、shared、based
データ可用性誰もが状態を再構築できるようトランザクションデータを公開する場所native、celestia、both

各ロールアップは一意の rollup-id で登録され、QOR によるステークボンドに裏付けられ、ライフサイクルステータス（pending、active、paused、stopped）が割り当てられます。作成とライフサイクルの完全なフローについては ロールアップのデプロイ を参照してください。

QoreChain RDK が他と異なる点​

どのロールアップキットにも共通する基本機能に加えて、QoreChain RDK は QoreChain のレイヤー1を軸に構築された QoreChain 固有の 3 つの機能と、ウォッチタワーの自動チャレンジャーを備えています。それぞれステータスが異なり、現在動作するものは表に記載しています。RDK は 5 つの言語（TypeScript、Python、Go、Rust、Java）で提供されています。現在の公開バージョン: npm 0.4.4、PyPI 0.5.0、Go v0.5.0、crates.io 0.4.4、Maven Central 0.4.4。v0.4.2 以降、mainnet と testnet のプリセットには公開の qore.host エンドポイントが組み込まれているため、createRdkClient({ network }) は手動のエンドポイント設定を必要としません（ただし、その REST 読み取りは RDK の REST ルートが提供されている環境でのみ機能します。メインネットは現在これらを提供していません）。

差別化要素機能
耐量子決済レシート決済アンカーを、耐量子（ML-DSA-87 / Dilithium-5）署名を持つ持ち運び可能なレシートにまとめます。初期段階: アンカーはまだ存在せず、レシートはチェーンの状態と照合して確認する必要がある主張です。
QCAI ロールアップ・コパイロット単一ロールアップ向けの読み取り専用アドバイザリヘルパー（手数料見積もり、レコメンデーション、不正調査）。参照するアドバイザリサービスは、まだ公開エンドポイントでは提供されていません。
マルチ VM のクロス VM 呼び出しクロス VM プリコンパイル（0x…0901）を通じて EVM → CosmWasm 呼び出しをエンコードするためのツール。このプリコンパイルは、ライブネットワークではまだ有効化されていません。
ウォッチタワーオプティミスティックロールアップ向けの自動チャレンジャーフレームワークで、新しいバッチとチャレンジウィンドウの締め切りを検出し、あなたの正当性述語に反する無効なバッチにチャレンジします。RDK の REST ルートが必要ですが、メインネットは現在これを提供していません。

詳細な根拠とコードサンプルについては Why QoreChain RDK を参照してください。

4 つの決済パラダイム​

QoreChain RDK は、信頼の前提、ファイナリティの特性、証明要件がそれぞれ異なる 4 つの決済モードをサポートします。決済モードと証明システムの組み合わせはオンチェーンで検証され、互換性のない組み合わせは作成時に拒否されます。以下の図は各決済モードとその有効な証明システムの対応を示しています。

Optimistic（オプティミスティック）​

オプティミスティックロールアップは、提出されたバッチをデフォルトで有効とみなし、紛争解決には**不正証明（fraud proof）**を利用します。

  • 証明システム: fraud ―― インタラクティブな不正証明
  • シーケンサー: dedicated または shared
  • ファイナリティ: 設定可能なチャレンジウィンドウが成功したチャレンジなしに終了するまで遅延
  • 紛争: 誰でもウィンドウ内に、ボンドと不正証明を提出して、提出されたバッチにチャレンジできます。チャレンジによりバッチは凍結され、その後ロールアップの作成者が解決し、チェーン自体が証明を検証します。不正が認められるとバッチは拒否されてチャレンジャーに報酬が支払われ、チャレンジが却下されるとバッチは submitted に戻ります。ロールアップのデプロイを参照してください。
  • ウィンドウの長さ: デフォルトのウィンドウは 604,800「秒」で、チェーンはこれを 1 ブロックあたり固定 6 秒でブロック数に換算します ―― つまり 100,800 ブロックです。実際の経過時間は実際のブロックタイムに従います（メインネットの現在の約 3.2 秒のブロックでは約 3.7 日）。したがって、日数ではなくブロック数で計画してください。

ZK（ゼロ知識）​

ZK ロールアップは各バッチに暗号学的な正当性証明を付与し、再実行なしに状態遷移の正しさを証明します。

  • 証明システム: snark（簡潔な証明）または stark（トラステッドセットアップ不要の透明な証明）
  • シーケンサー: dedicated または shared
  • ファイナリティ: 有効な証明の検証時 ―― チャレンジウィンドウは不要
  • 成熟度: SNARK バッチは、ロールアップとともに保存された検証鍵に対してオンチェーンで検証されます（BLS12-381 上の Groth16）。create-rollup で作成されたロールアップは現在検証鍵を持たないため、ZK バッチはまだエンドツーエンドで確定できません。STARK 検証は実験的です。オプトインであり、あなたのロールアップ自身の状態遷移ではなくデモンストレーション用の回路を検証します。ZK 決済は本番運用の準備ができていないものとして扱ってください。ZK / STARK と出金 を参照してください。

Based（ベースド）​

ベースドロールアップはトランザクションのシーケンシングを QoreChain（L1）のプロポーザーに委任し、ホストチェーンのライブネスと検閲耐性を継承します。

  • 証明システム: none ―― L1 プロポーザーが順序の真実の源
  • シーケンサー: based（必須 ―― オンチェーン検証によって強制される）
  • ファイナリティ: ホストチェーンの確定に追従
  • トレードオフ: QoreChain のバリデータがシーケンシングを担うため運用モデルは最もシンプルだが、専用シーケンサーによるレイテンシ制御は失われる
  • 現在のステータス: based はロールアップ設定に記録されますが、QoreChain はまだ L1 プロポーザーをバッチ提出者として認めていません ―― 提出するのはロールアップの作成者です（シーケンサーモードを参照）

Sovereign（ソブリン）​

ソブリンロールアップは独自のコンセンサスを運用し、自己シーケンシングを行います。検証可能性のために状態を QoreChain にアンカーしますが、ファイナリティについてはホストチェーンに依存しません。

  • 証明システム: none
  • シーケンサー: ロールアップによる自己管理
  • ファイナリティ: 独立 ―― ロールアップ自身のコンセンサスによって決定される
  • 状態アンカリング: 状態ルートは透明性のために QoreChain に投稿されるが、ホストチェーンはそれを強制しない

証明システムの互換性​

決済モードは、どの証明システムが有効かを制約します。これらの組み合わせはロールアップ作成時に強制されます。

決済モードfraudsnarkstarknone
optimistic必須———
zk—対応対応—
based———必須
sovereign———必須

シーケンサーモード​

シーケンサーは、決済前にロールアップブロック内でトランザクションを並べる主体を決定します。

モード誰がシーケンシングするか備考
dedicated単一の指定されたオペレーターアドレスレイテンシが最も低いが、ライブネスと公正な順序付けについてオペレーターへの信頼が必要
shared共有シーケンサーセット順序付けがセット全体に分散し、調整オーバーヘッドがやや高い
basedQoreChain L1 プロポーザーホストチェーンのバリデータのセキュリティと検閲耐性を継承する。based 決済には必須
現在強制されているもの

オンチェーンでは、バッチを提出できるのはロールアップに設定されたシーケンサーアドレスのみで、設定されていない場合（すべてのプリセットが該当）はその作成者のみです。shared と based のモードはロールアップ設定に記録されますが、QoreChain はまだ共有シーケンサーの名簿や L1 プロポーザーをバッチ提出者として認めていません。これらのモードは意図された設計を示すものです。

パラダイムの選び方​

こんな場合には…検討すべきもの
QoreChain バリデータがシーケンシングを行う、最もシンプルな運用構成を望むbased
暗号学的な保証による高速なファイナリティを望む（まだ本番運用には未対応）zk（snark / stark）
経済的な紛争解決を伴う、実績のあるモデルを望むoptimistic（fraud）
独自のコンセンサスによる完全な独立性を望みつつ、検証可能性のためにアンカーしたいsovereign

どこから始めればよいか分からない場合は、RDK が一般的なアプリケーションカテゴリ向けにこれらの選択をまとめたプリセットプロファイルを提供しています ―― プリセットプロファイル を参照してください ―― また、アドバイザリ RPC が利用可能な場合は suggest-profile ヘルパーもあります（現在は固定の defi フォールバックを返すため、プロファイルの表から選んでください）。

開発者向けには、RDK は公開の TypeScript SDK である @qorechain/rdk と create-qorechain-rollup スキャフォールダーとしても提供されており、同じオンチェーンモジュールをコードから駆動します ―― ロールアップのデプロイ を参照してください。

関連ページ​