Substrate: del runtime al consenso propio

Artículo 1 de 20

5%

completado al llegar aquí

Sistemas distribuidosNota de investigación14 min de lectura

Qué es Substrate hoy: el Polkadot SDK por dentro

Qué es Substrate dentro del Polkadot SDK, cómo se reparten FRAME, Cumulus y XCM, y cómo ubicar un crate por su prefijo sc-, sp- o pallet-.

Ruta Substrate: 0/20

Imagina tu primer día en un equipo que mantiene una cadena construida con Substrate. Te pasan un enlace a un tutorial de 2021 que pide clonar substrate-node-template, un README que habla del Polkadot SDK y un archivo Cargo.toml con más de cien dependencias que empiezan por sc-, sp-, pallet- y frame-. Antes de escribir una línea necesitas saber tres cosas: qué es Substrate hoy, qué parte del sistema estás tocando y qué nombres cambiaron. Este capítulo arma ese mapa.

La respuesta corta: Substrate (Polkadot SDK) es el framework base con el que se construyen cadenas en el ecosistema Polkadot. Ya no se publica como un repositorio aparte. Vive dentro de paritytech/polkadot-sdk, junto a FRAME, Cumulus y XCM. La documentación del SDK lo define así: "the base blockchain framework used to power the Polkadot SDK. It is a full toolkit to create sovereign blockchains, including but not limited to those which connect to Polkadot as parachains."

Brújula de lectura

Actor, evidencia y estado

Antes de avanzar, ubica quién actúa, qué prueba queda y qué parte del sistema cambia.

Actor

Quien construye una cadena

Elige un template, escribe pallets con FRAME y, solo si hace falta, toca el nodo.

Evidencia

El prefijo del crate

sc- es nodo, sp- es puente compartido, pallet- y frame- son runtime.

Estado

Lo decide el runtime

El nodo guarda y transporta; la lógica que cambia saldos vive en el runtime.

Preguntas guía

  • ¿Qué es Substrate y qué relación tiene con el Polkadot SDK?
  • ¿Qué hacen FRAME, Cumulus y XCM, y cuándo los necesitas?
  • ¿Qué separa al nodo del runtime y por qué esa separación es la idea central?
  • ¿Cómo sé, mirando solo el nombre de un crate, en qué lado del sistema estoy?

Conexiones dentro de la serie

Del nombre suelto al Polkadot SDK

Durante años, "Substrate" fue un repositorio propio con su documentación propia. Hoy el código vive en un único repositorio, el Polkadot SDK, que según su README "provides all the components needed to start building on the Polkadot network". Substrate sigue existiendo como nombre y como carpeta (substrate/), pero se lo presenta como una pieza del SDK, no como un producto separado.

Esto importa al leer material viejo. Un tutorial puede pedirte clonar substrate-node-template. Ese template ahora se llama solochain template: la página de templates del SDK lo describe como «Formerly known as "substrate-node-template"», una cadena blanca (white-labeled) con un consenso básico y algunos pallets de FRAME. Una solochain es una cadena que se sostiene sola, sin conectarse a Polkadot como parachain.

La documentación antigua de substrate.io conviene leerla como material histórico. Los conceptos de fondo (nodo, runtime, pallets) siguen valiendo; los nombres de herramientas, rutas y comandos pueden haber cambiado. Si una guía y el código del SDK no coinciden, gana el código del SDK. Que el sitio antiguo siga en línea y qué páginas redirigen es un punto a validar.

Una analogía ayuda a fijar la idea antes de entrar en piezas. La propia documentación del SDK la propone: un nodo de Substrate es una consola de videojuegos, y un runtime Wasm, posiblemente escrito con FRAME, es el juego que se inserta en la consola. La consola sabe leer cartuchos, dibujar en pantalla y hablar por la red. El juego decide las reglas. Cambiar de juego no obliga a cambiar de consola.

Cuatro piezas con nombre propio

El SDK agrupa cuatro componentes principales. Conviene conocerlos de memoria porque aparecen en todos los capítulos siguientes.

Substrate es la base: red entre pares, base de datos, ejecutor de Wasm, motores de consenso, RPC. Con Substrate solo ya puedes armar una cadena soberana.

FRAME es el framework para escribir la lógica de la cadena, lo que la documentación llama runtime. El nombre viene de "Framework for Runtime Aggregation of Modularized Entities". Con FRAME escribes módulos llamados pallets (un pallet de saldos, uno de gobierno, uno propio) y los ensamblas. Lo veremos en FRAME: pallets que se ensamblan en un runtime.

Cumulus convierte runtimes y nodos en piezas compatibles con Polkadot. El SDK lo resume así: Cumulus "transforms FRAME-based runtimes into Polkadot-compatible parachain runtimes, and Substrate-based nodes into Polkadot/Parachain-compatible nodes". Una parachain es una cadena que delega su seguridad en la cadena de relevo de Polkadot (la relay chain).

XCM (cross consensus message) es el formato de mensajes entre cadenas. El SDK lo describe como el formato principal para comunicar parachains, pensado para extenderse a otros casos. La documentación lo llama un lenguaje para comunicar intenciones entre sistemas de consenso. No es un protocolo de transporte: expresa cosas como "transfiere este activo" o "ejecuta esta llamada".

Un detalle que ordena la cabeza: la propia red Polkadot es una cadena construida con Substrate, con los mismos dos componentes, nodo y runtime. La documentación insiste en que "no es especial" en ningún sentido técnico; solo tiene lógica especializada en ambos lados.

La idea central: un nodo que ejecuta un runtime

Toda cadena basada en Substrate tiene dos mitades. El runtime es la lógica de la aplicación: qué es una cuenta, cómo se transfiere un saldo, quién puede votar. El nodo es todo lo demás: el binario que se conecta a otros nodos, guarda datos en disco, participa del consenso y responde por RPC. El SDK lo dice sin rodeos: el runtime es la lógica de la aplicación y el nodo es "everything else".

Lo que vuelve particular a Substrate es dónde vive el runtime. Se compila a WebAssembly (Wasm), un formato de código portable, y ese blob se guarda dentro del propio estado de la cadena. El nodo actúa como ejecutor de ese blob. Como el código está en el estado, cambiar las reglas es, en principio, tan simple como cambiar un valor guardado, igual que se actualiza un saldo. Esa es la base de las actualizaciones sin bifurcación (forkless upgrades), que la ruta trata más adelante.

Otra consecuencia es menos obvia y más importante para quien viene de sistemas distribuidos: el consenso vive en el nodo, no en el runtime. La documentación del protocolo Wasm lo enumera: "the database, networking, and even consensus algorithm are all node-side components." El runtime decide qué es un bloque válido para la aplicación; el nodo decide, con el motor de consenso, qué bloque se acepta y cuándo es final. Esa frontera es la que, al final de la ruta, permite enchufar un consenso propio.

Figura 1

Mapa del Polkadot SDK: nodo, puente compartido y runtime

Fuentes:

[4][1]
Mapa del Polkadot SDK: nodo, puente compartido y runtime
Cómo leer esta figura

Tres columnas con encabezados lado nodo, puente compartido y lado runtime. En la primera, una caja azul sc-asterisco, carpeta client, con red, base de datos, RPC y consenso. En la segunda, una caja violeta sp-asterisco, carpeta primitives, con sp_api y sp_io, tipos y llamadas comunes. En la tercera, una caja verde pallet-asterisco y frame-asterisco, carpeta frame, con FRAME y la lógica de la cadena. Flechas rotuladas usa van desde las cajas de los extremos hacia la del centro. Bajo la primera columna, una flecha compila a lleva a binario nativo que ejecuta el runtime; bajo la tercera, otra flecha compila a lleva a blob Wasm que vive en el estado. Una flecha discontinua del blob al binario dice consola y juego: el nodo carga y ejecuta. Abajo, dos cajas ocre anchas: Cumulus vuelve parachain al nodo y al runtime, y XCM formato de mensajes entre sistemas de consenso. Arriba, una nota indica un solo repositorio: paritytech/polkadot-sdk.

Visual original de TrautsLab. Los crates sc-* forman el nodo, los sp-* son el puente que comparten nodo y runtime, y los pallet-* y frame-* forman el runtime. El nodo compila a un binario nativo; el runtime, a un blob Wasm que vive en el estado. Cumulus y XCM se apoyan sobre ambos lados.

Ubicar un crate por su prefijo

Substrate tiene cientos de crates (paquetes de Rust). La documentación los agrupa en tres familias según su prefijo, y aprender esa regla ahorra horas.

  • sc-* (Substrate client), en la carpeta client/. Todo lo que termina en el software del nodo: red (sc-network), base de datos, RPC, motores de consenso.
  • sp-* (Substrate primitives), en primitives/. Tipos y herramientas que usan tanto el nodo como el runtime. Dos son clave: sp_api y sp_io, que forman el puente de comunicación entre ambos lados.
  • pallet-* y frame-*, en frame/. Todo lo relacionado con FRAME: pallets listos para usar y la maquinaria para ensamblarlos.
Lectura de dependencias

Dónde estoy según el prefijo

sc-* (nodo)

Red, base de datos, RPC, consenso. Compila a binario nativo.

Ideal para
Cambios de operación, sincronización o motor de consenso.
Ojo con
Cambiar el nodo no cambia las reglas del estado, pero un consenso distinto exige que todos los nodos coincidan.
Precaución

sp-* (puente)

Tipos y llamadas compartidas: sp_api, sp_io, sp_runtime.

Ideal para
Entender cómo se hablan nodo y runtime.
Ojo con
Agregar llamadas nuevas al puente es un compromiso de largo plazo: el nodo debe seguir soportándolas.
Recomendado

pallet-* y frame-* (runtime)

Lógica de la cadena escrita con FRAME. Compila a Wasm.

Ideal para
Reglas de negocio: saldos, gobierno, módulos propios.
Ojo con
Un error aquí afecta a toda la cadena, no a un contrato aislado.
El prefijo del crate dice en qué mitad del sistema cae un cambio y quién lo revisa.

Un proyecto típico refleja esta división en carpetas. Bajo runtime/ hay un lib.rs que ensambla el runtime con las macros construct_runtime e impl_runtime_apis. Bajo node/ hay un main.rs y un service.rs que arma los componentes del nodo: red, base de datos, consenso. La documentación aclara que son convenciones, no reglas, pero casi todos los templates las siguen.

El SDK también ofrece un espectro de libertad. En un extremo, tomas un template y ajustas parámetros: tienes una cadena en minutos con poca libertad técnica. En el medio, escribes tus propios pallets con FRAME, que es lo que hace la mayoría. En el otro extremo, personalizas el nodo, que según la documentación "is the most technically demanding". Esta ruta recorre los tres, en ese orden.

Qué cambia respecto de Ethereum

Si vienes de la ruta de Ethereum, la palabra "capa" puede confundir. Ethereum separó su cliente en dos: la capa de ejecución, que aplica transacciones, y la capa de consenso, que acuerda qué bloques valen. Son dos programas que se hablan por una API. Substrate corta en otro lugar: la frontera no es entre ejecución y consenso, sino entre lógica de la aplicación (runtime) y todo lo demás (nodo). En Substrate, el consenso queda del lado del nodo, igual que la red y la base de datos.

La segunda diferencia es de alcance. Ethereum es un protocolo con varias implementaciones de cliente, y todas deben aplicar las mismas reglas. Substrate es una caja de herramientas para construir muchas cadenas distintas, cada una con sus reglas. Lo que en Ethereum es una especificación común, en Substrate es tu runtime: lo escribes tú y lo guarda la propia cadena.

La tercera tiene que ver con los nombres. En ambos ecosistemas cambió el vocabulario con el tiempo: "Eth2" dejó de usarse, y "Substrate" pasó a ser una pieza del Polkadot SDK. En los dos casos, leer documentación con fecha y contrastarla con el código evita errores de interpretación.

Qué llevarte de este capítulo

Substrate es la base del Polkadot SDK; FRAME escribe runtimes, Cumulus los conecta a Polkadot y XCM comunica cadenas. Una cadena Substrate es un nodo que ejecuta un runtime guardado como Wasm en su propio estado. El prefijo de cada crate te dice de qué lado estás. Con este mapa, el siguiente capítulo puede responder la pregunta de fondo: qué significa, exactamente, que el runtime sea la función de transición de estado.

Referencias

Bibliografía académica

Formato IEEENumerado para ingeniería, sistemas y protocolos.
  1. [1]

    Parity Technologies, "Polkadot SDK," polkadot_sdk_docs, paritytech/polkadot-sdk, docs/sdk/src/polkadot_sdk/mod.rs. [Online]. Available: https://raw.githubusercontent.com/paritytech/polkadot-sdk/master/docs/sdk/src/polkadot_sdk/mod.rs (consultado 2026-11-13).

    Componentes del Polkadot SDK: Substrate, FRAME, Cumulus, XCM y binarios.

  2. [2]

    Parity Technologies, "Polkadot SDK," README del repositorio paritytech/polkadot-sdk. [Online]. Available: https://raw.githubusercontent.com/paritytech/polkadot-sdk/master/README.md (consultado 2026-11-13).

    Alcance del repositorio y enlaces a la documentación actual.

  3. [3]

    Parity Technologies, "Templates," polkadot_sdk_docs, paritytech/polkadot-sdk, docs/sdk/src/polkadot_sdk/templates.rs. [Online]. Available: https://raw.githubusercontent.com/paritytech/polkadot-sdk/master/docs/sdk/src/polkadot_sdk/templates.rs (consultado 2026-11-13).

    Templates minimal, solochain (antes substrate-node-template) y parachain.

  4. [4]

    Parity Technologies, "Substrate," polkadot_sdk_docs, paritytech/polkadot-sdk, docs/sdk/src/polkadot_sdk/substrate.rs. [Online]. Available: https://raw.githubusercontent.com/paritytech/polkadot-sdk/master/docs/sdk/src/polkadot_sdk/substrate.rs (consultado 2026-11-13).

    Filosofía, analogía consola/juego, familias de crates y anatomía de un proyecto.

  5. [5]

    Parity Technologies, "FRAME," polkadot_sdk_docs, paritytech/polkadot-sdk, docs/sdk/src/polkadot_sdk/frame_runtime.rs. [Online]. Available: https://raw.githubusercontent.com/paritytech/polkadot-sdk/master/docs/sdk/src/polkadot_sdk/frame_runtime.rs (consultado 2026-11-13).

    Pallets, partes de un pallet, construct_runtime e impl_runtime_apis, con ejemplo mínimo.

  6. [6]

    Parity Technologies, "XCM," polkadot_sdk_docs, paritytech/polkadot-sdk, docs/sdk/src/polkadot_sdk/xcm.rs. [Online]. Available: https://raw.githubusercontent.com/paritytech/polkadot-sdk/master/docs/sdk/src/polkadot_sdk/xcm.rs (consultado 2026-11-13).

    XCM como lenguaje de intenciones entre sistemas de consenso.

  7. [7]

    Parity Technologies, "WASM Meta Protocol," polkadot_sdk_docs, paritytech/polkadot-sdk, docs/sdk/src/reference_docs/wasm_meta_protocol.rs. [Online]. Available: https://raw.githubusercontent.com/paritytech/polkadot-sdk/master/docs/sdk/src/reference_docs/wasm_meta_protocol.rs (consultado 2026-11-13).

    Runtime en el estado, host functions, runtime APIs, nodo frente a runtime y runtime nativo.

Fuentes primarias, papers seminales y especificaciones técnicas citadas en esta investigación.

Rutas vecinas

Si este tema te abrió hambre, sigue por aquí.

Series y labs que comparten área o dependen de esta ruta. Pocas opciones, para no convertir la curiosidad en menú infinito.

Sigue leyendo

Ideas conectadas con este artículo

Una ruta corta para continuar sin abrir veinte pestañas y perder el hilo.

Los comentarios se cargan al final de la lectura para no meter peso antes de tiempo.