Las actualizaciones del Runtime (tiempo de ejecución) permiten a Polkadot cambiar la lógica de la cadena, sin necesidad de un hard fork.

Actualizaciones sin Bifurcación #

Es posible que hayas encontrado el término “hard fork” (bifurcación dura) antes en el espacio de blockchain. Un hard fork (bifurcación dura) se produce cuando la lógica de una blockchains cambia de tal manera que los nodos que no incluyen los nuevos cambios no podrán permanecer en consenso con los nodos que sí lo hacen. Estos cambios son incompatibles con el pasado. Los hard forks pueden ser políticos debido a la naturaleza de los upgrades (actualizaciones), así como logísticamente onerosos debido al número (potencialmente miles) de nodos en la red que necesitan actualizar su software.

En lugar de codificar el runtime (tiempo de ejecución) (la “lógica de negocio” de una cadena) en los nodos, los nodos de Polkadot contienen un host de ejecución de WebAssembly. Mantienen el consenso sobre un conjunto de instrucciones de muy bajo nivel y bien establecido. El runtime (tiempo de ejecución) de Polkadot se almacena en la propia blockchain de Polkadot.

Como tal, Polkadot puede actualizar su runtime (tiempo de ejecución) mediante la actualización de la lógica almacenada en la cadena, y elimina el desafío de coordinación de requerir que miles de operadores de nodos se actualicen antes de un número de bloque determinado. Las partes interesadas de Polkadot proponen y aprueban las actualizaciones a través del sistema de gobernanza en la cadena, que también las ejecuta de forma autónoma.

Nuevas Versiones de Clientes #

Se sigue la lógica del runtime (tiempo de ejecución) existente para actualizar el tiempo de ejecución de Wasm almacenado en la blockchain a una nueva versión. La actualización se incluye entonces en la propia blockchain, lo que significa que todos los nodos de la red la ejecutan. En general, no es necesario actualizar tus nodos manualmente antes de la actualización del runtime (tiempo de ejecución), ya que empezarán a seguir automáticamente la nueva lógica de la cadena. Sólo es necesario actualizar los nodos cuando el runtime (tiempo de ejecución) requiere nuevas funciones del host o hay un cambio en la red o en el consenso.

Las transacciones construidas para una determinada versión del runtime (tiempo de ejecución) no funcionarán en versiones posteriores. Por lo tanto, una transacción construida sobre la base de una versión de runtime (tiempo de ejecución) no será válida en versiones posteriores de runtime (tiempo de ejecución). Si no crees que puedas enviar una transacción antes de la actualización, es mejor esperar y construirla después de que se produzca la actualización.

Aunque generalmente no es necesario actualizar tus nodos para seguir una actualización, recomendamos seguir los lanzamientos de Polkadot y actualizar rápidamente, especialmente para las versiones de alta prioridad o críticas.

Actualizaciones de Runtime para Varios Usuarios #

Para Proveedores de Infraestructura #

Los servicios de infraestructura incluyen, entre otros, los siguientes:

• Validadores
• Servicios API
• Node-as-a-Service (NaaS)
• Gestión general de la infraestructura (por ejemplo, exploradores de bloques, custodios)
• Wallets (billeteras)

Para los validadores, mantener la sincronización con la red es fundamental. A veces, las actualizaciones exigen que los validadores actualicen sus clientes en un plazo determinado, por ejemplo, si una versión incluye cambios de última hora en la red. Es esencial comprobar las notas de la versión, empezando por la prioridad de actualización y actuando en consecuencia.

Los proveedores de infraestructura general, además de seguir las versiones de Polkadot y actualizarlas a tiempo, deben supervisar los cambios en los eventos de runtime (tiempo de ejecución) y en las herramientas auxiliares, como Substrate API Sidecar.

Las transacciones construidas para el runtime (tiempo de ejecución) n no funcionarán para runtimes (tiempos de ejecución) >n. Si se produce una actualización del runtime (tiempo de ejecución) antes de emitir una transacción previamente construida, necesitarás reconstruirla con la versión de runtime adecuada y los metadatos correspondientes.

Para los Nominadores #

Las actualizaciones de tiempo de ejecución no requieren ninguna acción por parte de un nominador, aunque siempre se recomienda mantenerse al día y participar con las últimas mociones y versiones de actualización de runtime (tiempo de ejecución), mientras se mantiene un ojo en cómo los nodos de la red están reaccionando a una nueva actualización.

Monitoreo de Cambios #

Puedes monitorear la cadena para las próximas actualizaciones. Las notas de la versión del cliente incluyen los hashes de cualquier propuesta relacionada con cualquier actualización en la cadena para facilitar su cotejo. Monitorea la cadena para:

1. eventos de democracy(Started) y registrar el index y el blockNumber. Este evento indica que un referéndum ha comenzado (aunque no significa que sea una actualización de runtime). Obtén la información del referéndum*; debería tener un estado de Ongoing. Busca el número de bloque final (end) y el delay de promulgación (delay). Si el referéndum se aprueba, se ejecutará en el número de bloque end + delay.
2. Los eventos democracy(Passed), democracy(NotPassed), o, democracy(Cancelled) citando el índice. Si Passed, necesitas mirar el evento scheduler(Scheduled) en el mismo bloque para el bloque de promulgación.
3. eventos democracy(PreimageNoted) con el mismo hash que el elemento ReferendumInfoOf(index). Esto puede ser hasta el último bloque antes de la ejecución, pero no funcionará si falta esto.
4. eventos de democracy(Executed) para la ejecución real. En el caso de una actualización en runtime, también habrá un evento system(CodeUpdated).

También puedes supervisar Polkassembly para las discusiones sobre las propuestas en cadena y los referendos.

* Por ejemplo, a través de pallets/democracy/storage/ReferendumInfoOf?key1=index&at=blockNumber en Sidecar.