Parachains con Cumulus: seguridad compartida

Un equipo opera una cadena soberana construida con Substrate (Polkadot SDK): Aura para producir, GRANDPA para finalizar y quince validadores propios. Cada trimestre discuten lo mismo: quince validadores es poco para la seguridad que quieren ofrecer, y conseguir más, con stake suficiente y operación confiable, es caro. Alguien propone otra opción: convertir la cadena en una parachain y dejar que los validadores de una relay chain, como Polkadot, se encarguen de validar y finalizar.

La propuesta suena a cambiar de proveedor de seguridad, pero cambia bastante más: quién produce los bloques, quién los valida, cómo se mide el costo de una transacción y de dónde viene la finalidad. Este capítulo recorre el camino de un bloque de parachain desde el collator hasta la finalidad en la relay chain, y muestra qué piezas agrega Cumulus a lo que ya conocemos de FRAME, Aura y GRANDPA.

De runtime FRAME a runtime de parachain

La documentación del SDK presenta Cumulus como la continuación natural de FRAME: si FRAME facilita crear un nodo y un runtime, "Cumulus aims to extend the same approach to creation of Polkadot parachains." [1] El README del proyecto agrega el objetivo práctico: que escribir la distribución, la red, la base de datos y la sincronización de una parachain cueste tan poco como escribir una cadena con Substrate. [2]

Un runtime de parachain es, ante todo, un runtime FRAME. Las diferencias son concretas. Necesita cumulus_pallet_parachain_system y parachain_info junto a frame_system. [1] Y como "all Cumulus-based runtimes use a simple Aura-based consensus mechanism", agrega pallet_timestamp, pallet_aura y cumulus_pallet_aura_ext. [1] Lo que aprendimos en el capítulo de Aura sigue valiendo: los collators se turnan por slots. Si una parachain puede usar otros esquemas de selección de collators es algo que queda a validar caso por caso.

La pieza que no existe en una cadena soberana es la función de validación de la parachain, o PVF (parachain validation function). Un macro genera una runtime API de validación, y la documentación es tajante sobre su papel: "Without this API, the relay chain is unable to validate blocks produced by our parachain." [1] La PVF es el runtime visto desde fuera: dado un bloque y los datos necesarios, dice si la transición de estado es válida.

Hay un detalle más que conecta con el capítulo sobre actualizaciones sin fork. En el ejemplo de Cumulus, frame_system configura OnSetCode = cumulus_pallet_parachain_system::ParachainSetCode<Self>. [1] Nuestra lectura: como la relay chain valida con el código de la parachain que ella misma guarda, una actualización de runtime no puede aplicarse solo localmente; tiene que pasar por la relay chain.

El collator y la prueba de validez

En una parachain, quien produce bloques es un collator. La documentación de Polkadot lo compara con algo conocido: su papel "is akin to Ethereum's sequencers but optimized for Polkadot's architecture." [3] El collator ordena transacciones, mantiene el estado de la parachain y arma bloques. El primer paso del proceso lo describe así: "Collators bundle transactions into PoV blocks (parablocks)." [3]

¿Qué es una PoV (proof of validity, prueba de validez)? La guía de PoV reclaim lo explica con precisión: la parachain envía "the block itself and a storage proof. Together they form the Proof-of-Validity (PoV). The PoV allows the relay chain to validate the parachain block by re-executing it." [4] La prueba de almacenamiento contiene los nodos del trie que el bloque lee, con sus caminos hasta la raíz, como las pruebas de Merkle del capítulo de sincronización.

La idea clave es que el validador de la relay chain no tiene el estado de la parachain, y no lo necesita. Con el bloque, la prueba y la raíz de estado anterior, puede re-ejecutar el bloque y comprobar que llega a la raíz que el collator declaró. Si alguna lectura no está en la prueba, o la prueba no cuadra con la raíz, el bloque es inválido.

Esto redistribuye la confianza de una forma que conviene tener clara. Nuestra lectura, a partir del flujo que describe la documentación: un collator deshonesto no puede hacer que la relay chain acepte una transición inválida, porque la validez la juzgan los validadores re-ejecutando. Lo que sí puede hacer un collator es dejar de producir, o censurar transacciones, porque la vitalidad de la parachain depende de que haya collators activos. La seguridad viene de la relay; la disponibilidad del servicio sigue siendo responsabilidad de la parachain.

Respaldo, inclusión y finalidad

El camino del parablock tiene cuatro pasos en la documentación de Polkadot. Primero, el collator empaqueta transacciones en un parablock con su PoV. Segundo, el bloque se envía a un subconjunto de validadores de la relay chain, los paravalidadores. Tercero, "Paravalidators use the parachain’s state transition function (already available on the relay chain) to verify transaction validity." [3] Cuarto, con suficientes validaciones positivas, el parablock queda respaldado e incluido como para-header en la relay chain. [3]

Los grupos de paravalidadores son pequeños: la documentación habla de "approximately five relay chain validators, randomly assigned to parachains and shuffled every minute". [3] Un grupo pequeño podría equivocarse o coludir. Por eso hay una segunda capa: un proceso de aprobación en el que más validadores revisan, una resolución de disputas cuando aparece un bloque inválido, y slashing para quien respaldó un bloque inválido. [3] Los detalles de cuántos validadores participan en la aprobación no están en las fuentes de este capítulo y quedan a validar.

Figura 1

Camino de un parablock hasta la finalidad

Fuentes:

[3][1]

Cómo leer esta figura

Dos franjas separadas por una línea punteada. Arriba, la parachain: un collator, con Aura y Cumulus, produce un parablock con su PoV, que incluye la prueba de estado medida por proof_size. Una flecha baja a la franja de la relay chain, hasta el grupo de respaldo, que re-ejecuta y firma; a su izquierda, la PVF de la parachain, ya almacenada en la relay, alimenta al grupo. Del grupo sale una flecha al para-header respaldado e incluido, y de allí una flecha verde a finalizado por GRANDPA. Debajo del para-header, un recuadro de aprobación y disputas: más validadores revisan y quien respaldó un bloque inválido es castigado. Una nota dice que la relay chain guarda solo la cabecera del parablock y que el bloque completo vive en la red de la parachain.

Descargar SVGDescargar .tex

Código TikZ

Abrir `.tex` en otra pestaña

La finalidad llega por la relay chain. El README de Cumulus describe el motor de consenso de la parachain como uno que sigue a la relay chain: "This will run a Polkadot node internally, and dictate to the client and synchronization algorithms which chain to follow," qué finalizar y qué tratar como mejor. [2] La parachain ya no corre GRANDPA propio: un bloque de parachain es final cuando el bloque de la relay chain que incluye su cabecera es finalizado por el GRANDPA de la relay, el que estudiamos en el capítulo 13.

La documentación subraya una consecuencia de diseño: los bloques de la relay chain no guardan los parablocks completos, sino "para-headers, which serve as summaries of the backed parablocks". [3] Los datos de la parachain viven en la red de la parachain. La relay chain garantiza la validez y el orden, no el almacenamiento de cada transacción.

proof_size: la dimensión del peso que importa aquí

En el capítulo de pesos y comisiones vimos que el peso de FRAME tiene dos dimensiones. La documentación de benchmarking define la segunda así: "proof size: The amount of storage proof necessary to re-execute the block of code." [5] La misma documentación aclara que esa dimensión se necesita sobre todo para la verificación entre parachain y relay chain. En una cadena soberana, proof_size casi no limita. En una parachain, es un límite duro.

La razón está en la PoV. La guía de PoV reclaim lo explica: los validadores de la relay chain distribuyen la PoV entre ellos por la red, "This distribution is costly and limits the size of the storage proof." [4] Cada lectura de almacenamiento que hace una transacción agrega nodos del trie a la prueba. Una parachain con mucha capacidad de cómputo libre puede quedarse sin espacio de prueba mucho antes.

El benchmarking mide el peor caso, y en la práctica las operaciones suelen consumir menos. Para eso existe el reclamo de PoV: "PoV reclaim offers a mechanism to reclaim the difference between the benchmarked worst-case and the real proof-size consumption." [4] La documentación de pesos lo recomienda porque es "very useful for maximizing the throughput of parachains". [5]

El ritmo de producción también cambió con el tiempo. La guía de async backing explica que, antes, los parablocks "can only be built on the latest Relay Chain block", y que async backing permite construirlos sobre bloques más viejos de la relay y "create pipelines of multiple pending parablocks". [6] Estas mejoras cambian el tiempo y el rendimiento, no el principio: validar re-ejecutando con una prueba.

Qué cambia respecto de Ethereum

El paralelo obvio son los rollups, que estudiamos en rollups desde cero. Un rollup y una parachain comparten la idea de fondo: una cadena con su propio estado y su propio productor de bloques (secuenciador o collator) que hereda seguridad de una cadena base. La propia documentación de Polkadot hace la comparación entre collators y secuenciadores. [3]

La diferencia está en cómo se demuestra la validez. Un rollup optimista publica resultados y abre una ventana para que alguien pruebe fraude. Un rollup ZK publica una prueba criptográfica de validez. Una parachain no hace ninguna de las dos cosas: un grupo de validadores de la relay re-ejecuta el bloque con la PoV antes de incluirlo, y la aprobación y las disputas revisan después.

También cambia qué guarda la cadena base. Un rollup en Ethereum publica sus datos en la capa base para que cualquiera pueda reconstruir el estado. La relay chain guarda solo la cabecera del parablock. El siguiente capítulo, XCM, aborda la pregunta que queda abierta: si cada parachain tiene su propio runtime, ¿cómo le pide una cadena algo a otra?

Laboratorio propuesto

Estado: propuesta. Este laboratorio todavía no está publicado en lab.trautslab.dev; se ejecutará en local, sin red pública ni fondos reales.

Objetivo. Ver el camino completo de un parablock en una red local: producción por un collator, respaldo e inclusión en la relay chain, y finalidad heredada.

Pasos propuestos.

1. Describir en zombienet una relay chain local de dos validadores y una parachain del parachain template.
2. Verificar en los logs que los bloques de la parachain se respaldan y se incluyen en la relay chain.
3. Ejecutar el mismo parachain template con polkadot-omni-node y comparar el comportamiento.

Evidencia esperada. En los logs del collator, parablocks producidos por turnos de Aura. En los de la relay chain, cabeceras de parachain respaldadas e incluidas, y el número finalizado de la parachain avanzando al ritmo de la finalidad de la relay. Qué herramienta recomendar (zombienet v1 o zombienet-sdk) y los nombres de las opciones quedan a validar al construir el laboratorio.