Cardano busca un estándar para el software productor de bloques

Un Cardano Problem Statement busca un método compartido para identificar el software utilizado para producir bloques individuales. La discusión de CPS-0036 se abrió el 2 de septiembre y recibió la etiqueta Confirmed el 16 de septiembre, pero la propuesta sigue abierta y no establece un estándar técnico.

Su propósito es definir el problema antes de que una Cardano Improvement Proposal separada especifique el formato de señalización, el registro de software y las reglas de implementación.

Cardano se expande más allá de una única implementación de nodo

Históricamente, Cardano ha dependido de cardano-node basado en Haskell, mientras que ahora se están desarrollando implementaciones adicionales bajo las mismas reglas de consenso. CPS-0036 menciona Amaru y Dingo, y el debate de la propuesta también hace referencia a Gerolamo.

En este contexto, un cliente es el software de nodo que valida el protocolo de Cardano y puede participar en la producción de bloques. Es distinto de las carteras y otras aplicaciones utilizadas para interactuar con la red.

Las implementaciones independientes pueden mejorar la resiliencia porque un defecto que afecte a una base de código puede no existir en otra. Ese beneficio depende de la adopción. Si un cliente sigue produciendo la mayoría de los bloques, la red continúa siendo operativamente dependiente de esa implementación aun cuando existan alternativas.

Actualmente, Cardano no tiene un campo estandarizado que atribuya cada bloque al software que lo creó. Los investigadores, los exploradores y las plataformas de monitoreo deben estimar la distribución de clientes de forma indirecta, lo que produce conjuntos de datos que pueden ser incompletos o difíciles de comparar.

La actividad en la red ha hecho que el problema sea más inmediato. El revisor yHSJ dijo que Dingo y Gerolamo ya han producido bloques utilizando el campo de versión menor del protocolo como identificador de software, mientras que Amaru planea seguir el mismo enfoque.

CPS-0036 describe una señalización de software voluntaria

CPS-0036 propone un mecanismo compacto, voluntario y neutral respecto del consenso. Los bloques sin un identificador de software seguirían siendo válidos, y cada operador de pool de participación decidiría si publica la información.

La discusión describe dos enfoques existentes. Uno utiliza cuatro bytes del campo de versión menor del protocolo en la cabecera del bloque. El otro utiliza una transacción marcador de aproximadamente 60 bytes. Sin una especificación común, las implementaciones podrían adoptar formatos diferentes y obligar a los proveedores de infraestructura a mantener reglas de decodificación separadas.

La propuesta también solicita un registro gobernado de forma abierta que asigne un identificador reconocible a cada implementación. Los exploradores, los investigadores y los paneles podrían entonces interpretar la señal de manera coherente en toda la red.

La identidad del cliente es el primer caso de uso propuesto. Más adelante, el mecanismo podría admitir declaraciones sobre la disponibilidad de funciones o la preparación del software antes de actualizaciones del protocolo.

Varias cuestiones de diseño siguen sin resolverse. Un identificador autodeclarado puede ser suplantado, mientras que vincularlo criptográficamente a credenciales KES o VRF añadiría complejidad. Publicar versiones de software detalladas también podría exponer a operadores que ejecutan versiones vulnerables. Cualquier especificación tendría que seguir siendo compatible con Leios y su estructura de bloques en evolución.

Los datos de cliente podrían fortalecer el monitoreo de la red de Cardano

Un identificador estándar permitiría a Cardano medir la diversidad de clientes declarada directamente a partir de los bloques producidos. Los operadores de red y los investigadores podrían calcular la cuota asociada a cada implementación, identificar una dependencia excesiva de una base de código y rastrear si los clientes alternativos están entrando en la infraestructura activa.

Los datos también podrían respaldar las actualizaciones del protocolo. Si el estándar más adelante incluye la preparación de funciones, el ecosistema podría obtener una visión a nivel de red antes de un hard fork o de un lanzamiento de software importante. Las pruebas y la coordinación seguirían siendo procesos separados, mientras que la señal en cadena proporcionaría un conjunto de datos operativos común.

La discusión indica que ya podría estar formándose una convención práctica en torno al campo de versión menor del protocolo. El editor de CIP Robert Phair dijo que un CIP enfocado en la solución basado en la práctica actual podría ofrecer un camino más directo que documentar solo el problema.

La señalización de software no puede crear diversidad de clientes ni prevenir fallos, pero puede facilitar la medición de la infraestructura de Cardano. Si se adopta, el estándar permitiría a los exploradores y a las herramientas de monitoreo sustituir estimaciones fragmentadas por datos coherentes a nivel de bloque sobre qué cliente declarado está produciendo los bloques de la red.