Cardano propone eliminar la verificación de alcance de Plutus

La propuesta CIP-0205 de Cardano eliminaría uno de los pasos utilizados para preparar los scripts de Plutus para su ejecución. El autor Jacco Krijnen propone manejar los errores de variables no enlazadas durante la ejecución en lugar de comprobar todo el programa de antemano. Presentada el 25 de septiembre, la propuesta sigue en revisión.

El costo de preparar scripts de Plutus

Antes de ejecutar un script, un nodo comprueba que sus variables estén correctamente definidas dentro del programa. Conocida como verificación de alcance, esta se realiza durante la segunda fase de la validación de transacciones.

Evaluaciones de rendimiento anteriores citadas por la propuesta encontraron que la verificación representaba aproximadamente el 20% del tiempo de preparación del script, incluyendo la decodificación y la comprobación de versión. En evaluaciones de validación completa, representó aproximadamente el 3% del tiempo total de validación. Estas cifras miden la participación de esa verificación en el tiempo de procesamiento de esas cargas de prueba.

Eliminarla reduciría el trabajo de procesamiento para los scripts aptos. Cualquier reducción resultante en las comisiones de transacción dependería de ajustes posteriores a los parámetros de comisiones, según la propuesta.

Cómo Plutus gestionaría los errores de variables

Plutus Core es el lenguaje utilizado para ejecutar scripts de contratos inteligentes en Cardano. Su motor de ejecución, la máquina CEK, ya maneja los intentos de usar variables sin un valor enlazado.

En la discusión de revisión de la propuesta, el desarrollador Seungheon Oh señaló que CEK no depende de la verificación preliminar de alcance. Intentar evaluar una variable no enlazada resulta en un fallo ordinario de ejecución.

Con las reglas propuestas, un programa podría tener éxito si una variable no enlazada aparece solo en código que nunca se ejecuta. Los programas con un alcance correcto conservarían los mismos resultados de ejecución.

Lenguajes de desarrollo como Aiken, Plinth y Plutarch ya imponen el alcance de variables mediante sus verificadores de tipos antes de que los scripts lleguen a la cadena de bloques, señala la propuesta.

Una nueva versión del lenguaje y una bifurcación dura

El borrador vincula el cambio a la versión 1.2.0 del lenguaje Plutus Core, lo que requeriría una bifurcación dura. La implementación incluiría actualizaciones a la especificación, el código de ejecución, el modelo formal y las pruebas de conformidad.

La propuesta recibió el número CIP-0205 el 29 de septiembre. El editor de CIP Robert Phair solicitó una difusión más amplia entre los grupos de trabajo antes de que continúe la revisión, citando el alcance del cambio.

Según el borrador actual, los scripts existentes que usan las versiones 1.0.0 y 1.1.0 del lenguaje conservarían su comportamiento. Tras la activación, los nuevos scripts que declaren la versión 1.2.0 podrían ejecutarse sin la verificación preliminar de alcance por separado.