ロールアップ開発キット
x/rdk モジュールは、開発者が QoreChain 上にアプリケーション固有のロールアップをデプロイできる包括的なロールアップ開発キット (RDK) を提供します。4 つの決済パラダイム、複数のシーケンサーモード、プラグイン可能なデータ可用性バックエンド、AI 支援による構成最適化をサポートします。
決済パラダイム
QoreChain RDK は、optimistic、zk、based、sovereign という 4 つの異なる決済モードをサポートしており、それぞれ異なる信頼前提、ファイナリティ特性、証明要件を持ちます。
Optimistic 決済
Optimistic ロールアップは、トランザクションがデフォルトで有効であると仮定し、紛争解決のために不正証明 (fraud proof) に依存します。
- 証明システム: インタラクティブな不正証明
- チャレンジウィンドウ: 7 日間 (604,800 秒)、ロールアップごとに設定可能
- チャレンジボンド: 1,000 QOR (1,000,000,000 uqor) — 不正証明チャレンジの提出に必要
- ファイナリティ: 有効なチャレンジがないままチャレンジウィンドウが終了するまで遅延
- 自動ファイナライズ:
EndBlockerは、チャレンジウィンドウが紛争なく経過すると、バッチを自動的にファイナライズします
バッチライフサイクル:
Submitted → [challenge window expires] → Finalized
Submitted → [fraud proof submitted] → Challenged → Rejected
ZK (ゼロ知識) 決済
ZK ロールアップは、状態遷移の正しさを保証する暗号学的妥当性証明を提供します。
- 証明システム: SNARK (Groth16、PLONK) または STARK (透過的、トラステッドセットアップ不要)
- ファイナリティ: 証明検証時に即座に確定 — チャレンジウィンドウは不要
- 最大証明サイズ: 1 MB (1,048,576 バイト)
- 再帰深度: 設定可能な証明集約深度 (デフォルト: 1)
- 成熟度: 現在のリリースでは、ZK 決済は空でない任意の証明を受け入れるスタブ検証を使用します。完全な SNARK/STARK 証明検証は計画中のアップグレードであり、まだ本番環境向けに堅牢化されていないものとして扱うべきです。
バッチライフサイクル:
Submitted + valid proof → Finalized (instant)
Based 決済
Based ロールアップは、トランザクションのシーケンシングを L1 (QoreChain) プロポーザーに委譲し、ホストチェーンのライブネスと検閲耐性の保証を継承します。
- 証明システム: 不要 — L1 プロポーザーが信頼の源泉
- シーケンサー:
basedシーケンサーモードを使用する必要があります (検証により強制) - ファイナリティ: QoreChain 上で 2 ブロックの確認
- インクルージョン遅延: ロールアップトランザクションの強制インクルージョンまでの設定可能なブロック数
- 優先手数料の分配: L1 プロポーザーに支払われる優先手数料の設定可能な割合
バッチライフサイクル:
Submitted → [2 L1 blocks] → Finalized (auto)
Sovereign 決済
Sovereign ロールアップは独立したコンセンサスで動作し、自身のトランザクションを自己シーケンシングします。検証可能性のために状態を QoreChain にアンカーしますが、ファイナリティをホストチェーンに依存しません。
- 証明システム: なし
- ファイナリティ: 独立 — ロールアップ自身のコンセンサスによって決定
- 状態アンカリング: 状態ルートは透明性と検証可能性のために QoreChain に投稿されますが、強制はされません
- 自動ファイナライズ: なし — Sovereign ロールアップは独自のファイナリティを管理します
証明システムの互換性
| 決済モード | 不正証明 | SNARK | STARK | なし |
|---|---|---|---|---|
| Optimistic | 必須 | -- | -- | -- |
| ZK | -- | 対応 | 対応 | -- |
| Based | -- | -- | -- | 必須 |
| Sovereign | -- | -- | -- | 必須 |
STARK および完全な ZK 証明検証はまだ成熟途上です。上記の ZK 決済の成熟度に関する注記を参照してください。
プリセットプロファイル
RDK は、一般的なユースケースに最適化されたターンキー型のロールアップ構成を提供する 5 つのプリセットプロファイルを同梱しています。各プリセットは、対象ドメインに合わせて調整された決済パラダイム、シーケンサーモード、データ可用性バックエンド、ガスモデル、VM をバンドルしています:
| プロファイル | 決済 (証明) | シーケンサー | DA | ガスモデル | VM | 対象ユースケース |
|---|---|---|---|---|---|---|
defi | zk (SNARK) | dedicated | native | EIP-1559 | EVM | トレーディング、レンディング、AMM 型アプリケーション |
gaming | based | based | native | flat | custom | 高スループット・低レイテンシのゲーム状態とゲーム内経済 |
nft | optimistic (fraud) | dedicated | native (Celestia DA 計画中) | standard | CosmWasm | NFT のミント、マーケットプレイス、デジタルコレクティブル |
enterprise | based | based | native | subsidized | EVM | 手数料がスポンサードされる許可制およびコンソーシアム型デプロイメント |
custom | 完全にパラメータ化 | 完全にパラメータ化 | 完全にパラメータ化 | 完全にパラメータ化 | 完全にパラメータ化 | すべてのフィールドがユーザー定義 |
custom プロファイルでは、すべてのフィールドを自分で設定します。各プリセットにバンドルされる正確な値は RDK の成熟に伴って変化する可能性があります。権威あるプリセットごとのパラメータについては、qorechaind query rdk config (または @qorechain/rdk の RdkClient.params()) でライブ構成をクエリしてください。また、based 決済は常に based シーケンサーモードとペアになることに注意してください。
シーケンサーモード
シーケンサーは、ロールアップブロック内でトランザクションを順序付けする者を決定します。
Dedicated シーケンサー
単一のオペレーターがすべてのロールアップトランザクションをシーケンシングします。
- オペレーター: 単一の指定アドレス
- レイテンシ: 可能な限り最低 — 単一当事者による順序付け
- 信頼: ライブネスと公正な順序付けについてシーケンサーオペレーターへの信頼が必要
Shared シーケンサー
シーケンサーのセットが集合的にトランザクションを順序付けします。
- 最小セットサイズ: 設定可能 (デフォルト: 1)
- レイテンシ: 複数当事者の調整によりわずかに高い
- 信頼: シーケンサーセット全体に分散
Based シーケンサー
QoreChain L1 プロポーザーがロールアップトランザクションをシーケンシングします。
- インクルージョン遅延: 強制インクルージョンまでの設定可能なブロック数 (デフォルト: 10)
- 優先手数料シェア: L1 プロポーザーに支払われる優先手数料の設定可能な割合
- 信頼: QoreChain のバリデーターセットのセキュリティと検閲耐性を継承
- 要件: Based 決済モードは Based シーケンサーを必要とします (検証時に強制)
データ可用性バックエンド
Native DA
QoreChain 自体の中のオンチェーン KV ストアによる blob ストレージ。
| パラメータ | 値 |
|---|---|
| 最大 blob サイズ | 2 MB (2,097,152 バイト) |
| 保持期間 | 432,000 ブロック (6 秒ブロックで ~30 日) |
| 自動プルーニング | 期限切れの blob は EndBlocker でプルーニングされます — データは削除されますが、コミットメントのメタデータは保持されます |
| コミットメント | blob データの SHA-256 ハッシュ |
Celestia DA
Celestia の専用 DA レイヤーを使用した IBC ベースのデータ可用性。
- ステータス: 現在のリリースではスタブ化されています — 唯一のバックエンドとして選択された場合はエラーを返します
- ネームスペースサポート: ロールアップ固有のネームスペースが blob スキーマでサポートされています
- 計画中: Celestia の blob 提出と検証による完全な IBC 統合
Both (冗長)
Native と Celestia の両方のバックエンドに同時に blob を保存します。
- 現在のリリースでは、実際に保存されるのは native の blob のみであり、Celestia コンポーネントについては警告がログに記録されます。
ロールアップのライフサイクル
Pending → Active → Paused → Active → Stopped
↑ |
└──────────────────┘
(can resume from paused,
stopped is permanent)
| 状態 | 説明 |
|---|---|
| Pending | ロールアップは登録済みだがまだアクティブ化されていない |
| Active | ロールアップは稼働中でバッチを処理している |
| Paused | 作成者によって一時的に停止 (再開可能) |
| Stopped | 恒久的に廃止 — ステークボンドは作成者に返却される |
作成時、ステークのエスクローとレイヤー登録が成功すると、ロールアップのステータスは直ちに Active に設定されます。
バッチのライフサイクル
決済バッチは、ロールアップの状態ルートの状態進行を追跡します:
Submitted → Finalized (happy path)
Submitted → Challenged → Rejected (fraud detected)
| 状態 | 説明 |
|---|---|
| Submitted | バッチが QoreChain に投稿され、ファイナライズ待ち |
| Challenged | 不正証明チャレンジが提出された (optimistic のみ) |
| Finalized | バッチが正規のものとして受け入れられた |
| Rejected | 成功したチャレンジによりバッチが無効化された |
自動ファイナライズのルール
| 決済モード | ファイナライズのトリガー |
|---|---|
| Optimistic | 有効なチャレンジなしでチャレンジウィンドウ (~7 日) が終了 |
| ZK | 有効な証明の提出時に即座に確定 |
| Based | 提出後 2 つの L1 ブロック |
| Sovereign | なし — ロールアップ自身のコンセンサスにより管理 |
自動ファイナライズは、optimistic および based ロールアップでは EndBlocker で実行されます。ZK バッチは、バッチ提出中にインラインでファイナライズされます。
モジュールパラメータ
| パラメータ | デフォルト | 説明 |
|---|---|---|
max_rollups | 100 | 登録可能なロールアップの最大数 |
min_stake_for_rollup | 10,000,000,000 uqor (10,000 QOR) | ロールアップ作成に必要な最小ステーク |
rollup_creation_burn_rate | 0.01 (1%) | x/burn を通じてバーンされる作成ステークの割合 |
default_challenge_window | 604,800 seconds (7 days) | デフォルトの optimistic チャレンジウィンドウ |
max_da_blob_size | 2,097,152 bytes (2 MB) | データ可用性 blob の最大サイズ |
blob_retention_blocks | 432,000 (~30 days) | DA blob がプルーニングされるまでのブロック数 |
max_batches_per_block | 10 | ブロックごとに処理される決済バッチの最大数 |
マルチレイヤー統合
RDK モジュールは、クロスレイヤー状態管理のために x/multilayer と統合されています:
レイヤー登録
ロールアップが作成されると、RegisterSidechain を通じてサイドチェーンレイヤーとして自動的に登録されます。登録には以下が含まれます:
- レイヤー ID (ロールアップ ID と一致)
- ターゲットブロック時間とブロックあたりの最大トランザクション数
- サポートされる VM タイプとドメイン
- 決済間隔
登録は致命的ではありません: x/multilayer の登録が失敗しても、ロールアップは作成され、警告がログに記録されます。
状態アンカリング
RDK に提出されたすべての決済バッチは、AnchorState を通じて x/multilayer にアンカーされます。これにより以下が記録されます:
- レイヤー ID とレイヤーの高さ (バッチインデックス)
- 状態ルート
- トランザクション数
アンカリングは致命的ではありません: 失敗はログに記録されますが、バッチ処理を妨げることはありません。
バーン統合
ロールアップ作成時、ステーク額の 1% が rollup_create バーンチャネルを通じて x/burn モジュール経由でバーンされます。例えば、最小 10,000 QOR のステークでロールアップを作成すると、100 QOR が恒久的にバーンされます。残りの 9,900 QOR はエスクローに保持され、ロールアップが停止されたときに返却されます。