Traducción al español del siguiente documento: CIP-32 | Inline datums
#32
Datums en línea
Creado el 29 de noviembre de 2021 por Michael Peyton Jones
Resumen
Proponemos permitir que los propios datums se adjunten a las salidas en lugar de los hashes de los datums. Esto permitirá una comunicación mucho más sencilla de los valores de los datums entre los usuarios.
Motivación: ¿por qué es necesario este CIP?
Conceptualmente, los datums son piezas de datos que se adjuntan a las salidas. Sin embargo, en la práctica, los datums se implementan adjuntando hashes de los datums a las salidas y requiriendo que la transacción de gasto proporcione el datum real.
Esto es bastante inconveniente para los usuarios. Los datums tienden a representar el resultado de la computación realizada por la parte que crea la salida y, como tal, casi no hay posibilidad de que la parte que gasta conozca el datum sin comunicarse con la parte que lo creó. Eso significa que el datum debe comunicarse entre las partes fuera de la cadena o comunicarse en la cadena incluyéndolo en el mapa de testigos de la transacción que crea la salida (“datums adicionales”). Esto también es inconveniente para la parte que gasta, que debe observar toda la cadena para detectarlo.
Sería mucho más conveniente simplemente poner el datum en sí en una salida, que es lo que proponemos.
Casos de uso
Esperamos que, siempre que podamos reducir el costo lo suficiente, una gran proporción de desarrolladores de dApps utilicen esta función, ya que simplificará sus sistemas sustancialmente.
Especificación
Las salidas de las transacciones se cambian para que el campo del datum pueda contener un hash o un datum (un “datum en línea”).
El valor mínimo de UTXO para una salida con un datum en línea depende del tamaño del datum, siguiendo el parámetro de protocolo “coinsPerUTxOWord”.
Cuando se gasta una salida con un datum en línea, la transacción de gasto no necesita proporcionar el datum en sí.
Contexto del script
Los scripts reciben información sobre las transacciones a través del contexto del script. Por lo tanto, el contexto del script debe aumentarse para contener información sobre los datums en línea.
Cambiar el contexto del script requerirá una nueva versión del lenguaje Plutus en el libro mayor para soportar la nueva interfaz.
Hay dos cambios en la nueva versión de la interfaz:
- El campo del datum en las salidas de las transacciones puede ser un hash o el datum real.
- El campo del datum en las entradas de las transacciones puede ser un hash o el datum real.
La interfaz de las versiones antiguas del lenguaje no se cambiará. Los scripts con versiones antiguas no pueden gastarse en transacciones que incluyan datums en línea, intentar hacerlo será un fallo de validación de la transacción de fase 1.
CDDL
El CDDL para las salidas de las transacciones cambiará como sigue para reflejar la nueva alternativa.
salida_transacción =
[ dirección
, cantidad: valor
, ? datum: $hash32 / plutus_data
]
PARA HACER: ¿debería haber una producción dedicada para datum-hash-o-datum? ¿Necesita ser etiquetada?
Racional: ¿cómo logra este CIP sus objetivos?
La idea clave de esta propuesta es simplemente restaurar la situación conceptualmente simple en la que los datums están adjuntos a las salidas. Históricamente, esta era la forma en que se diseñó el modelo EUTXO, y el cambio a hashes de datums en las salidas se hizo para evitar inflar las entradas UTXO, que en ese momento (pre- multi activos) eran de tamaño constante (ver *1).
Ahora que tenemos entradas UTXO de tamaño variable y la contabilidad para soportarlas, podemos restaurar los datums en línea.
Dado que los datums en línea cambian muy poco del modelo aparte de dónde se almacenan los datos, no necesitamos preocuparnos por violar ninguno de los otros requisitos del libro mayor, pero sí necesitamos preocuparnos por el efecto en el tamaño del conjunto de UTXO.
Tamaño del conjunto de UTXO
Esta propuesta da a los usuarios una forma de poner cantidades mucho mayores de datos en el conjunto de UTXO. ¿No llevará esto a una peor inflación del conjunto de UTXO?
La respuesta es que ya tenemos un mecanismo para desalentar esto, a saber, el valor mínimo de UTXO. Si los datums en línea resultan en un uso significativamente mayor del espacio, entonces podemos necesitar aumentar “coinsPerUTxOWord” para mantener el tamaño del conjunto de UTXO bajo control. Eso será costoso e inconveniente para los usuarios, pero aún les permitirá usar datums en línea donde sean más útiles y el costo sea soportable. Además, esperamos que de hecho podamos reducir “coinsPerUTxOWord” cuando se complete el próximo trabajo de mover el UTXO principalmente a almacenamiento en disco.
Otro guardarrail sería imponer límites superiores al tamaño de los datums en línea. En el extremo, podríamos limitarlos al tamaño de un hash, lo que garantizaría no más uso de espacio que hoy. Sin embargo, esto es mucho peor para los usuarios, ya que introduce una discontinuidad brusca donde un datum en línea es completamente aceptable, hasta que cruza el umbral de tamaño en el que se vuelve inaceptable, y no hay forma de evitar esto. En general, preferimos evitar tales discontinuidades en favor de un aumento gradual de los costos.
En la práctica, lo que se implemente aquí puede depender de si el trabajo de UTXO-en-disco se completa para cuando se implemente esta propuesta.
Otros modos de especificar datums
Podríamos descontinuar los otros métodos de especificar datums (hashes de datums o hashes de datums + datums adicionales). Sin embargo, los otros enfoques también tienen algunas ventajas.
Costos de transmisión: creador paga versus consumidor paga
- Datums en línea: paga el creador
- Hashes de datums: paga el consumidor
- Hashes de datums + datums adicionales: ambos pagan
Costos del valor mínimo de UTXO
- Datums en línea: depende del tamaño de los datos
- Hashes de datums: costo fijo
- Hashes de datums + datums adicionales: costo fijo
Privacidad
- Datums en línea: el datum es inmediatamente público
- Hashes de datums: el datum no es público hasta que se consuma
- Hashes de datums + datums adicionales: el datum es inmediatamente público, pero solo para los seguidores de la cadena
Comunicación de datums
- Datums en línea: fácil comunicación en cadena
- Hashes de datums: comunicación fuera de cadena necesaria
- Hashes de datums + datums adicionales: comunicación en cadena complicada
Cualquiera de estos factores podría ser importante para casos de uso particulares, por lo que es bueno conservar las otras opciones.
El contexto del script
Incluir información sobre los datums en línea
En principio, no necesitamos dejar que los scripts vean si un datum es en línea o no. Podríamos pretender que los datums en línea no son en línea e insertarlos en el mapa de testigos de los datums.
La pregunta subyacente es: ¿queremos que los scripts puedan hacer afirmaciones sobre si los datums son en línea o no? Hay razones para querer hacer esto: no usar datums en línea causa problemas de comunicación para los usuarios, por lo que es bastante razonable que un desarrollador de aplicaciones quiera poder hacer cumplir su uso.
Además, como principio general, tratamos de mantener el contexto del script lo más fiel posible a las transacciones reales. Incluso si el uso de la información no es inmediatamente obvio, tratamos de pecar de proporcionar y dejar que los usuarios decidan.
Por lo tanto, incluimos información sobre los datums en línea en el contexto del script.
Representación y compatibilidad con versiones anteriores
Hay un par de opciones sobre cómo cambiar la representación del contexto del script para incluir la nueva información y si hacer un esfuerzo de compatibilidad hacia atrás para las versiones antiguas del lenguaje.
Para el nuevo contexto del script:
- Coincidir con la representación del libro mayor tanto como sea posible: cambiar los campos en entradas y salidas para que sean un hash de datum o un datum.
- Tratar de tener solo una forma de buscar datums: poner los datums en línea en el mapa de testigos de los datums e insertar sus hashes en las entradas y salidas correspondientes; opcionalmente agregar un booleano a entradas y salidas para indicar si el datum era originalmente en línea.
Para la compatibilidad con versiones anteriores:
- No intentar representar datums en línea para scripts que usen versiones antiguas del lenguaje: los scripts antiguos simplemente no pueden ejecutarse en transacciones que usen datums en línea (ya que no podemos representar la información).
- Reescribir los datums en línea como datums no en línea: poner los datums en línea en el mapa de testigos de los datums e insertar sus hashes en las entradas y salidas correspondientes.
Para el nuevo contexto del script, la opción 1 tiene la ventaja significativa de coincidir con la representación del libro mayor de las transacciones. Esto facilita su implementación y también evita la sobrecarga conceptual para los usuarios que tendrían que distinguir las dos formas de representar las transacciones. Si bien la distancia conceptual aquí puede ser pequeña, si dejamos que crezca con el tiempo, puede volverse bastante confusa.
Luego tenemos la opción de qué hacer con la compatibilidad con versiones anteriores. La opción 2 funcionaría, pero es más complicada para el libro mayor y es inconsistente en la representación con nuestra elección para el nuevo contexto del script (los datums en línea a veces se representan fielmente y otras veces se ponen en el mapa de testigos). La opción 1 es simple, pero no permite que los scripts antiguos funcionen con datums en línea. Esto no sería tan malo si solo significara que los scripts antiguos no podrían gastarse en transacciones que incluyan datums en línea, pero también introduce una nueva forma de hacer una salida no gastable. Si un usuario crea una salida con un script antiguo y un datum en línea, cualquier transacción que gaste esa salida incluirá un datum en línea, lo cual no permitiríamos.
Desafortunadamente, no podemos evitar que los usuarios creen tales salidas en general, ya que las direcciones de script no incluyen el lenguaje del script, por lo que el libro mayor no puede decir si el datum en línea es permisible o no. El código del cliente generalmente podrá hacer esto, ya que normalmente conocerá el script.
El factor mitigante es que esperamos que esto sea poco común en la práctica, particularmente porque esperamos que la mayoría de los usuarios se trasladen a la nueva versión relativamente rápido, ya que esperamos que el soporte para datums en línea sea deseable y se libere junto con otras características deseables.
Por lo tanto, elegimos ambas opciones 1 y no proporcionamos compatibilidad hacia atrás para las versiones antiguas del lenguaje.
Camino a Activar
Criterios de Aceptación
- Completamente implementado en Cardano a partir de la actualización del protocolo Vasil.
Plan de Implementación
- Cumple con todos los requisitos de ambos equipos de Plutus y Ledger acordados para mejorar la eficiencia y usabilidad de los scripts de Plutus.
Copyright
Este CIP está licenciado bajo CC-BY-4.0.
*1 Chakravarty, Manuel M. T. et al., “The extended UTXO model” 