Traducción al español de “No-surprises transaction validation: part 2”, escrito por Polina Vinogradova, ingeniera de software en IOG, el 6 de septiembre de 2021
La validación de las transacciones en Alonzo, en aras de garantizar una compensación justa a la labor de validación, se realiza en dos fases
En nuestro artículo anterior, tratamos la naturaleza determinista de la validación de transacciones y secuencias de comandos [scripts] en el libro mayor Alonzo, que proporciona la garantía de que el resultado de la aplicación de transacciones en la cadena y la validación de secuencias de comandos puede predecirse con precisión a nivel local, antes de que la transacción se envíe.
Basándonos en las garantías proporcionadas por el diseño determinista del libro mayor de Alonzo, implementamos un esquema de validación específico en dos fases. Ha sido diseñado para reducir al mínimo los recursos empleados por los nodos en la validación de las transacciones de la red, al tiempo que se eliminan los costes inesperados para el usuario. En este segundo artículo, detallamos el funcionamiento de la validación en dos fases.
En las eras de Shelley, Allegra y Mary, el proceso de validación de transacciones se realizaba en un solo paso. Se podía predecir el efecto de una transacción válida en el libro mayor antes de aplicarla. Cuando una transacción era válida, era incluida en un bloque y añadida al libro mayor. Si no lo era, un nodo la rechazaba tras un intento fallido de validación y la transacción no se incluía en un bloque. No obstante, al validar las transacciones entrantes, los nodos utilizaban tiempo y recursos, sin importar si la transacción se incluía o no en un bloque.
Alonzo añade las secuencias de comandos de Plutus, las cuales, en contraste con las simples secuencias de épocas anteriores, pueden requerir muchos más recursos para su validación. Como respuesta a la problemática de los nodos que gastan recursos en la validación de secuencias de comandos de transacciones que son rechazados, Alonzo presenta un enfoque de validación en dos fases. El resultado de esta estrategia es predecible a la hora de realizar transacciones en el libro mayor y también garantiza una compensación justa a los nodos por su trabajo y uso de recursos.
La validación de transacciones en dos fases
En Cardano, el proceso de validación de las transacciones se divide en dos fases. El motivo principal para introducir dos fases es reducir la cantidad de trabajo de validación no compensado por los nodos. Cada fase tiene un propósito para lograr este objetivo. A grandes rasgos, la primera fase comprueba si la transacción está construida correctamente y puede pagar su tarifa de procesamiento. La segunda ejecuta las secuencias de comandos que se incluyen en la transacción. En caso de que la transacción sea validada en la primera fase, se ejecutarán las secuencias de comandos de la segunda fase. En cambio, de fallar la primera fase, no se ejecuta ningún script y la transacción se desecha inmediatamente.
De este modo, puede esperarse que los nodos añadan transacciones procesables a un bloque incluso si las transacciones no son válidas en la segunda fase. Esto significa que:
- se realiza una pequeña cantidad de trabajo no compensado por parte de un nodo para determinar que una transacción no es procesable, pero sin que se realice la costosa validación de la segunda fase, o
- si la transacción es procesable, el nodo realiza la validación de la segunda fase de la transacción. Posteriormente, puede efectuar la validación de fase 2 de los secuencias de comandos, marcar la transacción como válida o invalida y añadirla a un bloque. En ambos casos, el nodo será compensado posteriormente por ambas fases de validación a través de la tarifa o la garantía recaudada de esta transacción.
Se espera que el fallo de la fase 2 se produzca con poca frecuencia, ya que un usuario que envíe una transacción con guiones fallidos perderá ada vez que no consiga nada. Eso es predecible localmente y por lo tanto un evento prevenible. La fase es una salvaguarda necesaria para garantizar la compensación del cálculo potencialmente intensivo de recursos de las secuencias de comandos.
Veamos con más detalle los detalles de cada fase.
- Primera Fase
La primera fase de validación debe ser simple. Si falla esta fase, el nodo no recibe compensación por el trabajo que ha realizado, ya que no puede aceptar tarifas por procesamiento de transacciones no procesables.
En la primera fase de validación se verifican dos cosas: que una transacción se construye correctamente y que es posible añadirla al libro mayor. Esta validación incluye las siguientes comprobaciones y algunas adicionales:
- paga el valor correcto de las tarifas y proporciona el valor correcto de la garantía (es decir, la ada recogida en caso de fallo de la secuencia de comandos, que se explica más adelante)
- recoge todos los datos necesarios para la ejecución de las secuencias de comandos de Plutus
- no supera ningún límite establecido en los parámetros del protocolo (sobre tamaños de salida, etc.)
- las entradas se refieren a UTXOs existentes en el libro mayor
- el presupuesto computacional declarado para la transacción no excede el límite máximo de recursos por las comprobaciones de integridad de la transacción, etc.
Antes de añadir una transacción entrante al mempool (y eventualmente, a un bloque), un nodo debe realizar todas las comprobaciones de validación de la primera fase. Si alguna de estas comprobaciones falla, la transacción es rechazada sin ser incluida en un bloque, y no se cobran tarifas. En eras anteriores, esta era la única fase de validación y Cardano manejaba todos los fallos de validación de esta manera.
No se espera que los nodos honestos y no comprometidos produzcan intencionadamente transacciones no procesables. También es posible que los nodos abandonen las conexiones que realizan la difusión adversa de transacciones inválidas de la primera fase.
** Segunda Fase**
En esta fase de validación se ejecutan las secuencias de comandos de Plutus, estos pueden ser más costosos desde el punto de vista informático. En consecuencia, en esta fase se cobran tarifas tras un éxito o fracaso. La ada recaudada va al fondo de las tarifas y así se compensa a los nodos por los recursos utilizados en el proceso de validación.
El éxito de la validación de la primera fase no asegura que todas las acciones de la transacción sean procesables, únicamente que el cobro de la garantía es posible. La segunda fase realiza la validación de la secuencia de comandos de Plutus, y la decisión de realizar el procesamiento completo o sólo el cobro de la garantía se toma en función del resultado de la validación:
- realizar el procesamiento completo de la transacción (la única posibilidad antes de Alonzo) - si las secuencias de comandos de Plutus validan todas las acciones de la transacción, o
- recoger el ada en garantía e ignorar el resto de la transacción - si uno de las secuencias de comandos de Plutus falla .
Recordemos que la validación de las secuencias de comandos tiene un resultado localmente predecible y se garantiza su finalización. Los usuarios pueden comprobar localmente los resultados de la validación de las secuencias de comandos, y no habrá desacuerdo entre los nodos honestos sobre cómo procesar una determinada transacción y las secuencias de comandos en ella.
Garantía
Si las secuencias de comandos no se validan, todavía tenemos que pagar a los nodos por su trabajo. Ahora bien, no podemos limitarnos a tomar el dinero de las entradas de las transacciones, porque éstas podrían haber sido bloqueadas con secuencias de comandos -¡las que fallaron! Así que en su lugar, Alonzo introduce una disposición especial para esto. La garantía de una transacción es la cantidad de ada que se cobrará como tarifas en caso de que falle la validación de un script en la fase 2. En una transacción procesable, esta cantidad debe ser al menos un determinado porcentaje de las tarifas de la transacción, especificado en un parámetro del protocolo.
Esta cantidad se establece en el momento de construir la transacción. No de forma directa, sino añadiendo entradas de garantías a la transacción. El saldo total de los UTXO correspondientes a estas entradas especialmente marcadas es el importe de la garantía de la transacción. Estos UTXOs deben tener direcciones de clave pública (en lugar de las secuencias) y no contener más tokens que ada.
Las entradas de garantía se eliminarán del libro mayor UTXO sólo si alguna de las secuencias de comandos no supera la fase 2 de validación. En caso de que todas las secuencias de comandos pasen, se recauda el importe de las tarifas de transacción especificadas, como en las eras anteriores. En concreto, el importe procede de las entradas normales, no garantizadas, y las entradas garantizadas simplemente se ignoran. Y, ¡buenas noticias! Se permite utilizar las mismas entradas como garantía y regulares, ya que sólo uno de los dos conjuntos se elimina del UTXO.
Las firmas necesarias para validar el gasto de las entradas de garantía también desempeñan un papel importante en el mantenimiento de la integridad de una transacción. Lo hacen impidiendo que los adversarios alteren su contenido de manera que siga siendo procesable pero falle la validación de la fase 2. Un ejemplo de ello sería que un agresor sustituyera a un canjeador. Las firmas de los titulares de las claves de garantía son necesarias para realizar dicho cambio. Estos son también los únicos usuarios que pueden perder cualquier ada si falla la validación de las secuencias de comandos.
Como la evaluación de las secuencias de comandos es determinista, los titulares de las claves de garantía pueden comprobar localmente si la transacción pasará la validación de la segunda fase en la cadena antes de firmarla. Si es así, pueden estar seguros de que también lo hará en la cadena y definitivamente no perderán su garantía. Un usuario que actúa de buena fe nunca debería perder su garantía. También significa que pueden reutilizar las mismas entradas de garantía para múltiples transacciones y estar seguros de que la garantía no se recoge.
Ahora que hemos lanzado la red de pruebas pública de Alonzo, invitamos a todos los usuarios y desarrolladores a evaluarla construyendo y ejecutando las secuencias de comandos de Plutus. Puede encontrar más información en el repositorio dedicado Alonzo testnet, o discutir temas de Plutus y Alonzo con nuestra amplia comunidad.
Artículos Relacionados:
Validación de transacciones en Cardano, sin sorpresas