Cardano Node 11.1.3 corrige la decodificación de IPv4

Cardano Node 11.1.3 se lanzó el 29 de septiembre y corrige la forma en que el software lee las direcciones IPv4 almacenadas en el ledger. La actualización sigue al aviso previo de actualización prioritaria de Intersect para los operadores de stake pools y otras organizaciones que ejecutan la infraestructura de Cardano.

Cómo funciona la corrección de IPv4

La versión 11.1.2 cambió inadvertidamente el orden de bytes utilizado para decodificar direcciones IPv4. La versión más reciente restaura el orden de bytes de red estándar que se usaba antes de la serie 11.1.x. La corrección está incluida a través de la versión 1.9.0.1 de la biblioteca cardano-ledger-binary.

Una dirección IPv4 consta de cuatro bytes cuyo orden determina cómo se interpreta la dirección. En Cardano, estas direcciones aparecen en los registros de relés de los stake pools. Los relés intercambian bloques y transacciones con otros nodos, por lo que una interpretación precisa de sus datos de dirección es relevante para la infraestructura de la red.

El registro de cambios de la versión sitúa la corrección en el componente del ledger y no enumera cambios en los componentes Network o Consensus.

Qué operadores de Cardano se ven afectados

La recomendación de Intersect abarca a los operadores de stake pools y a otros operadores de nodos. Su orientación de actualización anterior incluía la infraestructura que opera en Mainnet, Preprod y Preview.

Cardano Node procesa y valida transacciones, incluidas las transferencias de ADA, y respalda la producción de bloques por parte de los stake pools. Los operadores mantienen y actualizan esa infraestructura. Los usuarios que delegan ADA en un pool dependen de su operador para gestionar los nodos del pool.

La corrección de IPv4 aborda específicamente un comportamiento introducido en la 11.1.2. La recomendación más amplia de ejecutar al menos esa versión se debe a un problema anterior identificado en la testnet Preprod.

Recomendación de actualización de Intersect

Se recomienda a los operadores que ejecutan versiones anteriores a la 11.1.2 que pasen directamente a la 11.1.3. Quienes ya están en la 11.1.2 cumplen con el mínimo indicado por Intersect, mientras que la 11.1.3 añade la corrección de IPv4. El anuncio no especifica un plazo para pasar entre esas dos versiones.

Intersect confirma que no se requiere replay del ledger, lo que significa que los operadores no necesitan recalcular el estado del ledger a partir de bloques históricos como parte de la actualización.

Para los operadores que actualizan desde versiones más antiguas, los requisitos de migración introducidos en la serie 11.1 siguen siendo relevantes. Estos incluyen la eliminación del backend de almacenamiento LMDB y del sistema de trazado heredado. Los operadores que aún usan LMDB deben cambiar de backend de almacenamiento, mientras que quienes dependen del trazado heredado deben migrar su configuración de monitorización.