La propuesta de Plutus de Cardano apunta a reducir la sobrecarga de ejecución de scripts

La canalización de desarrollo de Plutus de Cardano ha incorporado dos propuestas centradas en cómo los contratos inteligentes procesan los datos del ledger. CIP-0194 introduce comparación de patrones integrada para UPLC, mientras que CIP-0195 especifica cómo deben codificarse como Data los tipos de Plutus V4 como ScriptContext y TxInfo. Ambas siguen en revisión.

CIP-0194 ya cuenta con un prototipo de implementación funcional, con pruebas comparativas locales iniciales que muestran un tiempo de ejecución de CEK sustancialmente menor para varios patrones de acceso a datos. Las mediciones no están calibradas en unidades de ejecución en cadena, y los parámetros de costo de producción aún no se han finalizado.

CIP-0194 agrega comparación de patrones a Plutus Core

Los contratos inteligentes de Cardano inspeccionan con frecuencia Data estructurada, incluida la información de transacciones dentro de ScriptContext. Los programas UPLC existentes pueden descomponer estas estructuras mediante funciones como unConstrData, chooseData y operaciones sobre listas, con cada paso añadiendo trabajo dentro del evaluador CEK.

CIP-0194 propone una nueva operación Match que puede inspeccionar directamente valores anidados y capturar solo los campos que requiere un script. Cubre enteros, cadenas de bytes, listas, pares y Data estructurada, mientras que el mecanismo existente Case permanece disponible para operaciones más simples.

El cambio está dirigido principalmente a los validadores que inspeccionan repetidamente el contexto de las transacciones, incluidas lógicas de DeFi, trading y préstamos más complejas.

Ya existe un prototipo funcional en la base de código de Plutus. Su uso en producción todavía requeriría pruebas de conformidad, parámetros de costo calibrados, soporte en el ledger y una versión del nodo de Cardano.

Las primeras pruebas comparativas muestran un menor tiempo de ejecución de CEK

El CIP incluye pruebas comparativas locales que comparan Match con los métodos existentes para descomponer Data.

Al recuperar un único valor profundamente anidado, la ejecución de CEK medida fue entre 6.38 y 13.74 veces más rápida en los escenarios probados. Una prueba con 64 capas de Data anidadas registró 2.297 microsegundos con Match, frente a 31.068 microsegundos usando el enfoque existente.

La brecha de rendimiento se reduce cuando los scripts capturan múltiples valores, con mejoras probadas que van de aproximadamente 1.67 a 6.10 veces según la estructura y el método de referencia.

Estas cifras miden el rendimiento local de CEK en tiempo de pared en lugar de las unidades de ejecución finales de Cardano. El modelo de costos sigue sin calibrar. Los presupuestos preliminares de CPU y memoria en la propuesta mejoraron entre 10% y 90% en diferentes cargas de trabajo, con escenarios típicos de contexto de script mostrando aproximadamente entre 40% y 60% de mejora bajo los parámetros iniciales.

La propuesta asigna Match a la versión 1.2.0 del lenguaje de Plutus Core, lo que requeriría soporte en el ledger y activación mediante el proceso de hard fork de Cardano antes de que los scripts puedan usarlo en mainnet.

CIP-0195 define el modelo de Data de Plutus V4

CIP-0195 aborda el otro lado de la pila de Plutus al especificar cómo deben representarse como Data los tipos de la API de ledger de Plutus V4.

La propuesta cubre el ScriptContext de V4 y estructuras relacionadas, incluido un TxInfo ampliado. Sustituye el enfoque más informal usado en versiones anteriores de Plutus, donde los desarrolladores y herramientas alternativas a menudo tenían que derivar el comportamiento de codificación a partir del código de implementación en lugar de una especificación dedicada.

El diseño propuesto de V4 continúa usando listas para la codificación de tipos de datos. CIP-0195 sostiene que las operaciones UPLC más recientes hacen que el acceso a listas sea eficiente, al tiempo que evitan los constructores adicionales y la integración con el ledger que requeriría un modelo más amplio basado en arrays.

CIP-0194 y CIP-0195 pueden avanzar de forma independiente, pero en conjunto abordan cómo la próxima generación de Plutus estructura y accede a los datos del ledger. Si se adoptan, CIP-0195 estandarizaría cómo Plutus V4 expone esos datos, mientras que CIP-0194 daría a los validadores una manera de inspeccionarlos con menor sobrecarga. Ambos aún requieren la aprobación de la especificación, modelos de costo calibrados e integración en el ledger antes de llegar a la mainnet de Cardano.