La cadena como función de transición de estado

Tres nodos de una cadena de pruebas reciben el mismo bloque: en él, Ana le paga 3 unidades a Beto. Antes del bloque, Ana tenía 10 y Beto 0. Dos nodos terminan con Ana en 7 y Beto en 3. El tercero termina con Ana en 7 y Beto en 4, porque alguien le agregó al código de ese nodo un "bono de bienvenida" que depende de la hora local. Desde ese momento, el tercer nodo ya no está en la misma cadena que los otros dos. Este capítulo explica por qué, con una sola idea: la cadena es una función de transición de estado.

El capítulo anterior, Qué es Substrate hoy, dejó dicho que una cadena Substrate es un nodo que ejecuta un runtime. Ahora vamos a precisar qué hace ese runtime y por qué todo lo demás existe solo para habilitarlo.

Preguntas guía

• ¿Qué es el estado de una cadena y qué es una función de transición de estado?
• ¿Por qué en Substrate esa función se llama runtime?
• ¿Qué hace el nodo, si no decide cómo cambia el estado?
• ¿Por qué el determinismo no es una preferencia de estilo sino una condición de supervivencia?

Conexiones dentro de la serie

• Antes: Qué es Substrate hoy: el Polkadot SDK por dentro presenta nodo y runtime.
• Base teórica: Replicación de Máquina de Estados (SMR) con manzanas y peras muestra por qué réplicas deterministas que aplican el mismo log llegan al mismo estado, y Consenso BFT desde cero explica cómo se acuerda ese orden con fallas bizantinas.
• Después: El runtime en Wasm: nodo y runtime hablan por dos puertas muestra dónde vive la función y cómo la llama el nodo.

Estado, bloque y función: tres palabras con significado preciso

Estado es el conjunto de datos sobre el que la red quiere ponerse de acuerdo. La documentación del SDK lo define como "the data around which the blockchain network wishes to come to consensus" y anota sus sinónimos: datos onchain, storage o, en cadenas UTXO, ledger. [1] En nuestro ejemplo, el estado incluye que Ana tiene 10 y Beto 0. En una cadena real incluye también cuentas, configuración, votos y, como veremos en el próximo capítulo, el propio código de la cadena.

Bloque es un paquete ordenado de entradas que vienen de fuera: transacciones de usuarios y datos que el productor del bloque agrega, como la marca de tiempo. A esas entradas Substrate las llama extrinsics: datos originados fuera del runtime que entran a un bloque, sean transacciones de usuarios o inherentes que pone quien arma el bloque. [1] Tendrán su capítulo propio. Por ahora basta con saber que un bloque es la lista de cambios propuestos, en un orden fijo.

Función de transición de estado (STF, por state transition function) es el componente que dice cómo cambia el estado al aplicar un bloque. La documentación lo pone en cursiva: "The component that dictates how this state alteration can happen is called the state transition function." [2] Es una función en el sentido matemático: recibe entradas y devuelve un resultado, sin mirar nada más.

La fórmula que usa el SDK es corta: [2]

STF = F(State_N, Block_N) -> State_{N+1}

Se lee así: el estado después del bloque N es lo que resulta de aplicar F al estado anterior y al bloque N. Si repites la operación desde el bloque génesis (el primero de la cadena), obtienes el estado actual. Una cadena, vista así, es la composición de una función consigo misma, una vez por bloque.

En Substrate, la STF se llama runtime

La documentación es directa: "In Substrate-based blockchains, the state transition function is called the Runtime." [2] El glosario agrega un detalle que adelanta el próximo capítulo: la STF es "the WASM Blob that dictates how the blockchain should transition its state upon encountering new blocks". [1] Es decir, el runtime no es una idea abstracta: es un archivo binario concreto que implementa F.

Todo lo que pertenece a las reglas del estado va en el runtime. La guía del protocolo Wasm lo resume con ejemplos: la lógica de moneda, gobierno, identidad o cualquier otra lógica propia de la aplicación que tenga que ver con el estado. [3] Si un cambio altera qué saldo queda después de un bloque, es un cambio de runtime.

El nodo es todo lo demás. El glosario lo define como el artefacto completo que contiene al host (el entorno que ejecuta el runtime) y además los módulos necesarios para participar de la red: "peer-to-peer networking, database and such". [1] La red trae los bloques, la base de datos guarda el estado, el consenso decide qué bloque viene después. Ninguno de ellos decide el resultado de aplicar un bloque.

Una analogía del propio SDK ayuda: "The consensus is to your runtime what HTTP is to a web-application." [3] HTTP lleva las peticiones al servidor y devuelve las respuestas, pero la lógica de la aplicación está en el servidor. Del mismo modo, el consenso hace que todos los nodos ejecuten el runtime sobre los mismos bloques, en el mismo orden, y lleguen a un resultado canónico.

Figura 1

La cadena como función de transición de estado

Fuentes:

[2][1]

Cómo leer esta figura

Arriba a la izquierda, una caja Estado N con Ana 10 y Beto 0; debajo, una caja ocre Bloque N con Ana paga 3 a Beto. Dos flechas verdes llevan ambas a una caja verde central F igual a runtime, función de transición de estado, STF. De ella sale una flecha a la caja Estado N más 1 con Ana 7 y Beto 3. Abajo, una caja azul ancha Nodo: red p2p, base de datos, consenso y RPC; transporta, ordena y guarda; no decide el resultado. Una flecha discontinua rotulada entrega sube del nodo al bloque, y otra rotulada guarda baja del estado N más 1 al nodo. Una nota final dice: mismo Estado N y mismo Bloque N en cualquier réplica implica mismo Estado N más 1, determinismo.

Descargar SVGDescargar .tex

Código TikZ

Abrir `.tex` en otra pestaña

Determinismo: la regla que no se negocia

Volvamos al tercer nodo del inicio. Su código agregaba un bono que dependía de la hora local. La hora local de cada máquina es distinta, así que el resultado de F dejó de depender solo de sus dos entradas. Eso rompe la propiedad que hace funcionar al sistema: con el mismo estado y el mismo bloque, todas las réplicas deben obtener el mismo estado siguiente. Esa propiedad se llama determinismo.

La teoría detrás está en la replicación de máquina de estados: si todas las réplicas parten del mismo estado, aplican las mismas entradas en el mismo orden y la función es determinista, terminan iguales. El consenso resuelve la parte del orden; el determinismo de la función es responsabilidad de quien la escribe. Si falla el determinismo, ningún consenso, por bueno que sea, puede mantener a las réplicas de acuerdo.

¿Cómo se nota la diferencia en la práctica? Cada bloque lleva en su cabecera la raíz de estado (state root): un resumen criptográfico de todo el estado después de aplicar el bloque. Al importar un bloque, nodo y runtime comprueban que la raíz que calcularon coincide con la declarada en la cabecera. [3] El tercer nodo calcularía una raíz distinta y rechazaría bloques válidos, o produciría bloques que los demás rechazan.

Las fuentes típicas de no determinismo son conocidas: leer el reloj del sistema, generar números aleatorios locales, iterar estructuras cuyo orden depende de la memoria, usar aritmética de punto flotante con resultados que varían entre plataformas o consultar servicios externos. Un runtime solo puede usar lo que llega en el bloque y lo que ya está en el estado. La hora, por ejemplo, entra como un extrinsic inherente que solo el autor del bloque puede incluir y que todos los nodos leen igual. [4]

Qué cambia en el estado y qué cambia en la réplica

Con el modelo de la STF puedes clasificar casi cualquier cambio de ingeniería en una de dos cajas. La pregunta es siempre la misma: ¿este cambio altera el estado que resulta de aplicar un bloque, o solo cambia cómo se transporta, guarda o acuerda ese estado?

La tercera fila es la que esta ruta va a recorrer en detalle. El consenso es un componente del nodo, pero no es independiente del runtime: la documentación del omni-node explica que la mayor parte de un motor de consenso vive en el nodo, aunque el runtime normalmente expone una API propia para que ese motor funcione. [5] Por eso, cambiar de consenso toca los dos lados.

Qué cambia respecto de Ethereum

En Ethereum la idea de fondo es la misma: el estado de cuentas avanza al aplicar transacciones en orden, y cada cliente debe llegar al mismo resultado. Si leíste Estado, storage y Merkle Patricia Trie o Una transacción Ethereum por dentro, ya conoces la raíz de estado y por qué todos los clientes deben coincidir en ella.

La diferencia está en dónde vive la función. En un diseño clásico, la STF está escrita dentro del software del cliente. La documentación del SDK describe ese modelo como un artefacto monolítico en el que "the entire node software is the specification of the blockchain's state transition function", y en el que actualizar cualquier parte implica actualizar todo. [3] Por eso los cambios de reglas en Ethereum se coordinan como bifurcaciones programadas (hard forks), como las que recorre Berlin, London y EIP-1559.

Substrate separa la función del binario. La STF es el runtime, y el runtime es un dato más dentro del estado. Eso no elimina la coordinación, pero la mueve: en vez de que cada operador instale un binario nuevo, la propia cadena cambia su código mediante una transacción con los permisos adecuados. El capítulo siguiente muestra cómo.

Qué llevarte de este capítulo

Una cadena es una función que se aplica bloque tras bloque: F(estado N, bloque N) da el estado N+1. En Substrate esa función se llama runtime y es lo único que decide cómo cambia el estado. El nodo transporta, guarda y acuerda, pero no decide el resultado. El determinismo es obligatorio: con las mismas entradas, cada réplica debe llegar a la misma raíz de estado. Con este modelo puedes clasificar cualquier cambio como de runtime o de nodo antes de escribir una línea de código.