La prueba de descentralización de Cardano va más allá del número de nodos

Nick Regan, cofundador y presentador de Cheeky Crypto, ha publicado un análisis de 24 minutos sobre un riesgo menos visible dentro de la descentralización de Cardano: software desarrollado de forma independiente que puede discrepar sobre las reglas de la red. Cheeky Crypto es una plataforma de análisis y educación cripto fundada en 2020 por Nick y Chris Regan.

Regan vinculó su análisis a CPS-0034, un Cardano Problem Statement abierto que propone ampliar las pruebas de conformidad para los evaluadores de Plutus Core utilizados por implementaciones alternativas del nodo de Cardano. El debate va más allá de la distribución de stake pools, la participación en la gobernanza y el número de máquinas conectadas a la red.

Múltiples clientes no aumentan la seguridad de forma automática

Regan distingue entre la distribución física de una red y la distribución de su software. Cardano puede tener miles de nodos operados por distintas entidades en múltiples países, mientras que gran parte de esa infraestructura aún depende de la misma implementación central del nodo.

Si una implementación común contiene un defecto crítico para el consenso, un gran número de nodos distribuidos geográficamente podría encontrar el mismo problema de forma simultánea. Los clientes alternativos reducen esa concentración al permitir que equipos distintos usen diferentes lenguajes de programación, arquitecturas y decisiones de ingeniería.

Otro riesgo aparece cuando esas implementaciones interpretan el protocolo de manera diferente.

Un cliente podría aceptar una transacción que otro rechaza. Dos evaluadores de Plutus podrían procesar el mismo script pero devolver resultados diferentes o calcular costos de ejecución distintos. Dado que la validez de un bloque puede depender de esos resultados, el desacuerdo entre nodos podría producir una bifurcación de la cadena en lugar de una mayor resiliencia.

UPLC, o Untyped Plutus Core, es el lenguaje de ejecución al que se compilan los contratos inteligentes de Plutus. Un evaluador alternativo no necesita reproducir la estructura de la implementación de Haskell establecida de Cardano, pero sí debe reproducir el comportamiento relevante para el consenso que espera el protocolo.

Regan describe ese requisito como una necesidad de acuerdo independiente.

Bases de código separadas aportan una redundancia significativa solo cuando alcanzan de forma consistente la misma respuesta para entradas válidas, casos límite y versiones históricas del protocolo.

Regan utiliza el título "ADA Has a Decentralisation Problem" para distinguir este riesgo en la capa de software de los debates sobre descentralización que la mayoría de los tenedores encuentran. Su análisis se centra en trabajo preventivo de infraestructura en lugar de un incidente existente en mainnet.

CPS-0034 amplía las pruebas de conformidad de Plutus Core

El equipo de Plutus Core abrió la propuesta a revisión pública el 12 de agosto. Posteriormente, los editores de CIP le asignaron el número CPS-0034 tras su revisión inicial, mientras que la propuesta técnica sigue abierta a comentarios.

Según la propuesta CPS-0034, Cardano actualmente proporciona a desarrolladores externos aproximadamente 1.000 pruebas predefinidas de golden files. Estas permiten que un evaluador independiente ejecute un script proporcionado y compare su salida con el resultado esperado.

La batería existente ofrece una verificación inicial de compatibilidad pero tiene dos limitaciones identificadas. No expone las pruebas basadas en propiedades que usa internamente el equipo de Plutus, y solo cubre la combinación más reciente de versión de protocolo, versión del lenguaje del ledger y modelo de costos.

Las pruebas basadas en propiedades van más allá de una colección más pequeña de ejemplos preparados manualmente. Un generador puede producir cientos o miles de entradas variadas, construir con ellas scripts de Plutus y verificar si las propiedades de comportamiento definidas se siguen cumpliendo.

Este enfoque amplía la cobertura sobre combinaciones inusuales, valores límite y condiciones que pueden aparecer rara vez durante la actividad normal. Esas también son las situaciones en las que las implementaciones desarrolladas de forma independiente tienen más probabilidad de revelar supuestos diferentes sobre el comportamiento del protocolo.

CPS-0034 propone distribuir casos de prueba generados en un formato portátil que las implementaciones externas puedan consumir con un trabajo mínimo de integración. Cada prueba podría contener el programa, sus entradas, el resultado esperado y, cuando proceda, el presupuesto de ejecución esperado.

También se incluye la cobertura histórica. Cardano ha pasado por múltiples eras del ledger, hard forks, versiones del lenguaje de Plutus y cambios en el modelo de costos. Un nodo alternativo debe interpretar correctamente ese historial si se espera que reproduzca la cadena y valide bloques anteriores.

La propuesta se centra específicamente en la conformidad de los evaluadores de Plutus Core. No define un marco de pruebas completo para cada componente de red, ledger y consenso dentro de un nodo de Cardano. Su relevancia para la seguridad del nodo proviene del hecho de que distintos resultados de evaluación de scripts pueden cambiar si una transacción o un bloque se consideran válidos.

El código independiente debe demostrar un comportamiento consistente

CPS-0034 aún contiene varias cuestiones técnicas abiertas. Los desarrolladores están debatiendo cómo deben distribuirse las pruebas generadas, cómo deben informarse las diferencias entre resultados esperados y reales, cómo deben filtrarse los casos por versión de protocolo y cómo pueden ejecutarse miles de pruebas de forma eficiente.

Desarrolladores vinculados a Amaru ya se han sumado a la discusión pública. Amaru es un cliente de nodo de Cardano de código abierto escrito en Rust, que proporciona a los operadores una implementación desarrollada por separado de la cardano-node en Haskell establecida.

Un colaborador de Amaru informó que el proyecto ya consume las baterías de conformidad semántica y flat existentes. Los comentarios apoyaron pruebas más amplias de propiedades y versiones, al tiempo que solicitaron escenarios realistas en cadena, formatos de datos neutrales para el cliente y una vía sencilla para que terceros contribuyan con casos adicionales.

Las aproximaciones sugeridas incluyeron conjuntos de pruebas estructurados y etiquetar los casos según las versiones de protocolo y lenguaje que cubren. La discusión también planteó preocupaciones sobre implementar el generador exclusivamente en Haskell porque eso podría crear una barrera adicional para equipos que trabajan en otros lenguajes.

Un estándar de pruebas compartido no requeriría código fuente idéntico. Cada equipo podría conservar su propia arquitectura, lenguaje de programación y enfoque de desarrollo, mientras que el comportamiento de ejecución resultante permanecería compatible con las reglas de Cardano.

Para los holders de ADA, el tema atañe a la resiliencia de la infraestructura en lugar del rendimiento del mercado a corto plazo. Exchanges, wallets, aplicaciones descentralizadas y sistemas institucionales dependen de que distintos nodos lleguen a decisiones deterministas sobre transacciones, scripts y bloques.

Si CPS-0034 produce una batería de conformidad portátil y sensible a las versiones, un cliente alternativo de Cardano ya no demostrará compatibilidad solo por existir como una base de código separada. Podrá aportar evidencia reproducible de que el software escrito de forma independiente alcanza el mismo resultado y costo de ejecución a lo largo de la historia del protocolo de Cardano, exponiendo desacuerdos durante las pruebas antes de que puedan alcanzar un bloque en vivo.