Rollup Development Kit
El módulo x/rdk proporciona un Rollup Development Kit (RDK) completo que permite a los desarrolladores desplegar rollups específicos de aplicación en QoreChain. Admite cuatro paradigmas de liquidación, múltiples modos de secuenciador, backends de disponibilidad de datos conectables y optimización de configuración asistida por IA.
El módulo está desplegado en mainnet (versión de cadena v3.2.1) y en testnet, pero todavía no se ha creado ningún rollup en ninguna de las dos redes. Varias de las capacidades descritas a continuación no son utilizables de extremo a extremo hoy; el estado se indica donde se describe cada una. Para la guía práctica dirigida a desarrolladores, consulte Rollups Overview.
Paradigmas de liquidación
El RDK de QoreChain admite cuatro modos de liquidación distintos — optimistic, zk, based y sovereign — cada uno con diferentes supuestos de confianza, características de finalidad y requisitos de prueba.
Liquidación optimista
Los rollups optimistas asumen que las transacciones son válidas por defecto y dependen de pruebas de fraude para la resolución de disputas.
- Sistema de pruebas: pruebas de fraude interactivas
- Ventana de impugnación: 604.800 «segundos» (por defecto), convertidos por la cadena a bloques a razón fija de 6 segundos por bloque — 100.800 bloques. El tiempo real transcurrido depende del tiempo de bloque real (unos 3,7 días con los bloques actuales de ≈3,2 s de mainnet), así que planifique en bloques, no en días.
- Fianza de impugnación: 1.000 QOR (1.000.000.000 uqor) — requerida para presentar una impugnación con prueba de fraude (presets
nftycustom; los presetsdefi,gamingyenterpriseno establecen fianza porque no tienen ventana de impugnación) - Finalidad: retrasada hasta que expire la ventana de impugnación sin una impugnación válida
- Auto-finalización: el
EndBlockerfinaliza automáticamente los lotes una vez que la ventana de impugnación ha pasado sin disputa. Un lote impugnado nunca se finaliza automáticamente: el creador del rollup resuelve primero la impugnación (consulte Deploying a Rollup).
Ciclo de vida del lote:
Submitted → [challenge window expires] → Finalized
Submitted → [fraud proof submitted] → Challenged → Rejected
Liquidación ZK (Zero-Knowledge)
Los rollups ZK proporcionan pruebas criptográficas de validez que garantizan la corrección de las transiciones de estado.
- Sistema de pruebas: SNARK (Groth16 sobre BLS12-381) o STARK (transparente, sin configuración de confianza)
- Finalidad: instantánea al verificar la prueba — no se requiere ventana de impugnación
- Tamaño máximo de prueba: 1 MB (1.048.576 bytes)
- Profundidad de recursión: profundidad de agregación de pruebas configurable (por defecto: 1)
- Madurez: los lotes SNARK se verifican on-chain (Groth16 sobre BLS12-381) contra una clave de verificación almacenada junto con el rollup. Un rollup creado mediante
create-rollupno incluye actualmente una clave de verificación, por lo que los lotes ZK todavía no pueden finalizarse de extremo a extremo. La verificación STARK es experimental: es opcional y comprueba un circuito de demostración, no la transición de estado de su propio rollup. Trate la liquidación ZK como no apta para producción.
Ciclo de vida del lote:
Submitted + valid proof → Finalized (instant)
Liquidación based
Los rollups based delegan la secuenciación de transacciones a los proponentes de L1 (QoreChain), heredando las garantías de disponibilidad y resistencia a la censura de la cadena anfitriona.
- Sistema de pruebas: ninguno requerido — los proponentes de L1 son la fuente de verdad
- Secuenciador: debe usar el modo de secuenciador
based(impuesto por validación) - Finalidad: confirmación de 2 bloques en QoreChain
- Retraso de inclusión: bloques configurables antes de la inclusión forzada de transacciones del rollup
- Reparto de tarifas de prioridad: porcentaje configurable de las tarifas de prioridad pagadas a los proponentes de L1
Ciclo de vida del lote:
Submitted → [2 L1 blocks] → Finalized (auto)
Liquidación sovereign
Los rollups sovereign operan con consenso independiente y secuencian sus propias transacciones. Anclan el estado a QoreChain para verificabilidad, pero no dependen de la cadena anfitriona para la finalidad.
- Sistema de pruebas: ninguno
- Finalidad: independiente — determinada por el propio consenso del rollup
- Anclaje de estado: las raíces de estado se publican en QoreChain para transparencia y verificabilidad, pero no se imponen
- Auto-finalización: ninguna — los rollups sovereign gestionan su propia finalidad
Compatibilidad de sistemas de pruebas
| Modo de liquidación | Pruebas de fraude | SNARK | STARK | Ninguno |
|---|---|---|---|---|
| Optimistic | Requerido | -- | -- | -- |
| ZK | -- | Compatible | Compatible | -- |
| Based | -- | -- | -- | Requerido |
| Sovereign | -- | -- | -- | Requerido |
La verificación STARK es experimental y la liquidación ZK no está lista para producción; consulte la nota de madurez de Liquidación ZK más arriba.
Perfiles preconfigurados
El RDK incluye cinco perfiles preconfigurados que proporcionan configuraciones de rollup llave en mano optimizadas para casos de uso comunes. Cada preset agrupa un paradigma de liquidación, un modo de secuenciador, un backend de disponibilidad de datos, un modelo de gas y una VM ajustada a su dominio objetivo:
| Perfil | Liquidación (prueba) | Secuenciador | DA | Modelo de gas | VM | Caso de uso objetivo |
|---|---|---|---|---|---|---|
defi | zk (SNARK) | dedicated | native | EIP-1559 | EVM | Aplicaciones de trading, préstamos y estilo AMM |
gaming | based | based | native | flat | custom | Estado de juego y economías dentro del juego de alto rendimiento y baja latencia |
nft | optimistic (fraud) | dedicated | native (Celestia DA planificado) | standard | CosmWasm | Acuñación de NFT, mercados y coleccionables digitales |
enterprise | based | based | native | subsidized | EVM | Despliegues permisionados y de consorcio con tarifas patrocinadas |
custom | totalmente parametrizado | totalmente parametrizado | totalmente parametrizado | totalmente parametrizado | totalmente parametrizado | Cada campo es definido por el usuario |
El perfil custom deja cada campo para que usted lo configure. Los valores exactos agrupados en cada preset pueden evolucionar a medida que el RDK madura; consulte la configuración en vivo con qorechaind query rdk config (o RdkClient.params() de @qorechain/rdk) para los parámetros autoritativos por preset, y tenga en cuenta que la liquidación based siempre se empareja con el modo de secuenciador based.
Modos de secuenciador
El secuenciador determina quién ordena las transacciones dentro de un bloque del rollup.
On-chain, un lote solo puede ser enviado por la dirección de secuenciador configurada del rollup o, cuando no hay ninguna establecida (en todos los presets), por su creador. Los modos shared y based se registran en la configuración del rollup, pero QoreChain todavía no admite una lista de secuenciadores compartida ni a los proponentes de L1 como remitentes de lotes; esos modos describen el diseño previsto.
Secuenciador dedicado
Un único operador secuencia todas las transacciones del rollup.
- Operador: una única dirección designada
- Latencia: la más baja posible — ordenación de una sola parte
- Confianza: requiere confianza en el operador del secuenciador para la disponibilidad y la ordenación justa
Secuenciador compartido
Un conjunto de secuenciadores ordenan colectivamente las transacciones.
- Estado: hoy es solo una etiqueta — la lista todavía no se admite on-chain (consulte la nota anterior)
- Tamaño mínimo del conjunto: configurable (por defecto: 1)
- Latencia: ligeramente mayor debido a la coordinación entre múltiples partes
- Confianza: distribuida entre el conjunto de secuenciadores
Secuenciador based
Los proponentes de L1 de QoreChain secuencian las transacciones del rollup.
- Estado: hoy es solo una etiqueta — los proponentes de L1 todavía no se admiten como remitentes de lotes (consulte la nota anterior)
- Retraso de inclusión: bloques configurables antes de la inclusión forzada (por defecto: 10)
- Reparto de tarifas de prioridad: porcentaje configurable de las tarifas de prioridad pagadas a los proponentes de L1
- Confianza: hereda la seguridad del conjunto de validadores de QoreChain y la resistencia a la censura
- Requisito: el modo de liquidación based requiere el secuenciador based (impuesto en la validación)
Backends de disponibilidad de datos
Native DA
Almacenamiento de blobs en el KV-store on-chain dentro de la propia QoreChain.
El módulo define el almacenamiento, la retención y la poda de blobs, pero en las versiones actuales no existe ningún mensaje de transacción para publicar un blob. Un lote que nombre un hash de datos en un rollup native o both es rechazado porque no se puede almacenar ningún blob coincidente. Consulte Data Availability.
| Parámetro | Valor |
|---|---|
| Tamaño máximo de blob | 2 MB (2.097.152 bytes) |
| Período de retención | 432.000 bloques (unos 16 días con los bloques actuales de ≈3,2 s de mainnet; la cifra varía con el tiempo de bloque) |
| Auto-poda | Los blobs expirados se podan en el EndBlocker — los datos se eliminan pero se conservan los metadatos del compromiso |
| Compromiso | Hash SHAKE-256 (32 bytes) de los datos del blob |
Celestia DA
Disponibilidad de datos basada en IBC usando la capa de DA dedicada de Celestia.
- Estado: stub en la versión actual — devuelve un error si se selecciona como único backend
- Soporte de namespaces: los namespaces específicos del rollup están soportados en el esquema de blobs
- Planificado: integración IBC completa con el envío y la verificación de blobs de Celestia
Ambos (redundante)
Almacena blobs en los backends Native y Celestia simultáneamente.
- En la versión actual, solo se almacena realmente el blob native; se registra una advertencia para el componente Celestia.
Ciclo de vida del rollup
Pending → Active → Paused → Active → Stopped
↑ |
└──────────────────┘
(can resume from paused,
stopped is permanent)
| Estado | Descripción |
|---|---|
| Pending | Rollup registrado pero aún no activado |
| Active | El rollup está en vivo y procesando lotes |
| Paused | Detenido temporalmente por el creador (puede reanudarse) |
| Stopped | Desmantelado permanentemente — la fianza de stake se devuelve al creador |
En la creación, el estado del rollup se establece en Active inmediatamente después de que el escrow de stake y la quema de creación tengan éxito (se intenta el registro de la capa, pero no es fatal). Solo el creador puede pausar, reanudar o detener un rollup (impuesto desde la versión de cadena v3.2.0).
Ciclo de vida del lote
Los lotes de liquidación rastrean la progresión de estado de las raíces de estado del rollup:
Submitted → Finalized (happy path)
Submitted → Challenged → Rejected (fraud detected)
| Estado | Descripción |
|---|---|
| Submitted | Lote publicado en QoreChain, en espera de finalización |
| Challenged | Impugnación con prueba de fraude presentada (solo optimistic) |
| Finalized | Lote aceptado como canónico |
| Rejected | Lote invalidado por una impugnación exitosa |
Reglas de auto-finalización
| Modo de liquidación | Disparador de finalización |
|---|---|
| Optimistic | 100.800 bloques después del envío (ventana por defecto) sin impugnación |
| ZK | Instantánea al enviar una prueba válida |
| Based | 2 bloques de L1 después del envío |
| Sovereign | Ninguna — gestionada por el propio consenso del rollup |
La auto-finalización se ejecuta en el EndBlocker para los rollups optimistic y based. Los lotes ZK se finalizan en línea durante el envío del lote.
Parámetros del módulo
| Parámetro | Por defecto | Descripción |
|---|---|---|
max_rollups | 100 | Número máximo de rollups que pueden registrarse |
min_stake_for_rollup | 10.000.000.000 uqor (10.000 QOR) | Stake mínimo requerido para crear un rollup |
rollup_creation_burn_rate | 0.01 (1%) | Fracción del stake de creación quemada vía x/burn |
default_challenge_window | 604.800 (convertidos a 100.800 bloques) | Ventana de impugnación optimista por defecto |
max_da_blob_size | 2.097.152 bytes (2 MB) | Tamaño máximo de blob de disponibilidad de datos |
blob_retention_blocks | 432.000 bloques | Bloques antes de que se poden los blobs de DA |
max_batches_per_block | 10 | Lotes máximos de liquidación procesados por bloque |
Integración multicapa
El módulo RDK se integra con x/multilayer para la gestión de estado entre capas:
Registro de capa
Cuando se crea un rollup, el módulo registra una capa para él mediante RegisterSidechain, de modo que on-chain el tipo de capa es sidechain, comienza en estado proposed, cuenta para el límite de sidechains de multilayer (max_sidechains, por defecto 10) y bloquea el min_sidechain_stake del creador (1.000 QOR). El registro incluye:
- ID de capa (coincide con el ID del rollup)
- Tiempo de bloque objetivo y máximo de transacciones por bloque
- Tipos de VM y dominios soportados
- Intervalo de liquidación
El registro es no fatal: si falla (saldo insuficiente o límite alcanzado), el rollup se crea de todos modos, pero no tiene capa y no puede anclarse.
Anclaje de estado
Un lote de liquidación puede anclarse a x/multilayer, que registra el ID de capa, la altura de capa (el índice del lote), la raíz de estado, el hash del conjunto de validadores y el recuento de transacciones bajo una firma poscuántica del creador del rollup.
- Hoy en mainnet: los lotes se liquidan pero no se anclan — el RDK no aporta la firma del creador que requiere el anclaje, por lo que el paso de anclaje no tiene éxito y no se ha escrito ningún ancla. El anclaje es no fatal: nunca impide el procesamiento del lote.
Consulte Settlement Receipts para saber qué prueba y qué no prueba un ancla.
Integración de quema
Al crear un rollup, el 1% del monto del stake se quema vía el módulo x/burn a través del canal de quema rollup_create. Por ejemplo, crear un rollup con el stake mínimo de 10.000 QOR quema 100 QOR permanentemente. Los 9.900 QOR restantes se mantienen en escrow y se devuelven cuando se detiene el rollup. La quema de creación se impone desde la versión de cadena v3.2.0; las versiones anteriores no la aplicaban.