Los contratos inteligentes (Smart contracts) son scripts escritos en lenguaje de programación cuyas líneas reemplazan las cláusulas y términos de un contrato tradicional. Se ejecutan de forma automática sin que medie un tercero entre las partes.
La mayoría de los contratos inteligentes realizan cálculos basados en información procedente del mundo exterior. Estos datos deben ser transferidos a la plataforma a través de la capa de transacción. El costo de estas transferencias es generalmente significativo, ya que la plataforma debe valorar diferentes factores en las transferencias. Cada byte transferido:
- Consume ancho de banda.
- Retrasa la propagación del bloque (porque aumenta el tiempo de transferencia entre nodos).
- Retrasa aún más la propagación del bloque (porque los datos deben procesarse al verificar el bloque en cada salto).
- Debe ser almacenado en la cadena de bloques para siempre.
- Necesita ser leído desde un HDD/SSD cuando sea requerido
- Necesita ser almacenado en la RAM cuando se procesa.
Cada uno de estos elementos tiene un costo para la red. Algunos aplican sólo a los mineros, mientras que otros aplican a todos los nodos.
Pero todos esos ‘‘inconvenientes’’ tienen solución; al menos así lo asegura el especialista en seguridad del código Bitcoin, Sergio Demián Lerner, quien propone una nueva técnica para transferir datos a contratos inteligentes y a nodos de la red a muy bajo costo, permitiendo así nuevos casos de uso.
Introducción a los datos Efímeros.
La nueva técnica se denomina datos efímeros o datos no compactos, segregados, condicionalmente almacenados y datos retrasados opcionalmente.
Resulta bastante interesante que Demián traslade e introduzca la idea de datos efímeros hacia los contratos inteligentes, pero mucho más atractiva es la analogía que éste hace entre datos efímeros y la famosa paradoja cuántica del gato de Schrödinger.
La paradoja de Schrödinger trata sobre un experimento mental de naturaleza cuántica en la que un gato se encuentra encerrado en una caja y dentro con él se haya un dispositivo mortal que emite radiación a razón del tiempo de decaimiento del material radiactivo. Según la interpretación ortodoxa de la mecánica cuántica (interpretación de Copenhague) el gato está en un estado dual o mezclado (vivo y muerto al mismo tiempo) siempre y cuando el observador no abra la caja. Entonces, la probabilidad de que el gato se encuentre en un estado definido (vivo o muerto), está condicionada a la presencia del observador.
Pues bien, Demián traslada las consecuencias de este brillante ejercicio mental a las transacciones que se dan en los contratos inteligentes, de manera tal que los datos involucrados en dichas transacciones se pueden comportar como datos efímeros o datos de Schrödinger.
Los datos de Schrödinger pueden ser enviados a la cadena de bloques en un nuevo campo de transacción especial que permanece invisible para el consenso a menos que un contrato inteligente se refiera a él. Cuando se observan los datos, se convierte en parte de la cadena de bloques para siempre. Si los datos no se observan, los datos desaparecen y todo lo que permanece en la cadena para siempre son los datos de las hash digest involucrados.
Sergio Demián Lerner
Consultor de seguridad de criptomonedas
Demián además asegura, que el costo de agregar datos efímeros a una transacción está relacionado con el consumo de ancho de banda para transferirlo, pero el remitente no tiene que pagar (inmediatamente) por el almacenamiento eterno de bloques.
A continuación se definen algunos términos derivados de la técnica desarrollada por Demián Lerner y su equipo:
Efímero
Los datos efímeros están disponibles para ser referidos durante un cierto período predefinido (período efímero). Cuando este período ha terminado, los datos, en lo que respecta al consenso, se pierden para siempre. El coste de los datos efímeros dependerá, entre otros factores, del período efímero seleccionado por el remitente. Cuanto mayor sea el período, mayor será el costo. El tamaño de los datos efímeros también multiplica su costo.
Segregado
Los datos efímeros no son directamente contabilizados junto con los demás datos de la transacción que serán firmados, solamente el hash digest de los datos efímeros son los que se contabilizan. Por lo tanto, cuando se dispone de datos efímeros, sólo queda el resumen o hash digest. En algunos casos, ni siquiera el hash digest necesita ser almacenado, ya que el protocolo LTCP puede proporcionar una firma de un registro de transacción anterior, excluyendo el hash digest efímero. Esto sólo puede ocurrir si el período efímero culmina antes de que la siguiente transacción se incluya en un bloque.
Condicionalmente Almacenados
Un dato efímero sólo se convierte en parte de la cadena de bloque si se carga mediante un contrato utilizando el código de operación EDLOAD. Si no se utiliza antes de la fecha límite del período efímero, no se necesita almacenamiento. Los nodos completos se pueden optimizar para almacenar datos efímeros en la RAM, cuando el período efímero es corto. De esta forma, los nodos completos guardan un acceso de disco para el almacenamiento de datos y otro acceso al disco para la eliminación de datos.
Opcionalmente retrasado
Los datos efímeros pueden ser opcionalmente retrasados, a petición del propietario de la transacción, lo que significa que un contrato inteligente sólo puede acceder a los datos a partir del segundo bloque después del bloque de inclusión de la transacción. Esto reduce el coste del tiempo de propagación de datos efímeros, ya que los datos efímeros se pueden transferir con menos prioridad que las partes restantes (no efímeras) del bloque. Incluso si existe el riesgo de que un minero que cree un bloque no transmita los datos efímeros más tarde, forzando a los mineros restantes a retroceder, es el mismo riesgo aceptado por los mineros que realizan minería sin verificación durante algunos segundos después de recibir un encabezado de bloque.
Datos efímeros y escalabilidad
Los datos efímeros resultan ser una potente herramienta de escalabilidad que permite varios nuevos casos de uso. Por ejemplo, permite el uso de la red de criptomonedas como transporte cifrado para los mensajes peer-to-peer, como en el protocolo Bitmessage. Los datos efímeros obligan automáticamente a los nodos a almacenar temporalmente los mensajes en la red. Después del tiempo efímero, si el receptor no ha comprobado su bandeja de entrada, el mensaje se destruye automáticamente. La transacción no necesita tener destino, ni valor. El mensaje cifrado completo (incluyendo la dirección de destino del mensaje real) se puede ocultar en datos efímeros cifrados. Esta transacción, comprimida por LTCP, podría consumir sólo unos pocos bytes antes de ser eliminada. Si bien este hipotético sistema de mensajería puede no ser una solución de mensajería peer-to-peer escalable y barata a largo plazo, es realmente interesante y novedoso, y puede tener un caso de uso para la difusión anónima descentralizada.
Datos internos efímeros
Cada transacción tiene dos secciones de datos: datos normales y datos efímeros. La firma, en lugar de cubrir un resumen de hash de la transacción completa, cubre un resumen de hash de la transacción concatenada con el resumen de hash efímero. Aunque no se implementa en RSK, es posible que una transacción contenga varias piezas independientes de trozos efímeros, cada uno identificado por su propio resumen de hash.
Cuando se incluye una transacción en un bloque, los datos efímeros se separan del resto de la transacción. Las transacciones se almacenan en el árbol de transacciones estándar, los datos efímeros se transfieren en una lista aparte que puede no estar completa. Al igual que con LTCP, el protocolo de sincronización de cadenas de bloques se modifica para aceptar un bloque basando la decisión en la existencia de señales en los bloques siguientes. Para facilitar esta señalización, se puede incluir un resumen de hash que representa una raíz Merkle de la lista de datos efímeros referenciados en el encabezado de bloque.
Una transacción que utiliza datos efímeros puede especificar tres campos nuevos:
EDSize (unit): especifica el tamaño de los datos efímeros. Esto es necesario porque el costo de la transacción depende de este tamaño. Si no se especifica, se supone que es 32 bytes.
EDDelayed (booleano): indica si estos datos están disponibles de inmediato o se tarda 2 bloques. Si no se especifica, se supone que es falso.
EDBlockCount (uint): especifica cuántos bloques de datos estarán disponibles para los contratos. El conteo efímero debe ser inferior a un cierto límite fijo. Si los datos efímeros no se usan antes de la fecha límite, los datos efímeros se pueden eliminar de forma segura de la cadena de bloques para siempre. Sin embargo, la eliminación real de memoria en nodos completos debe ocurrir varios miles de bloques más tarde, hasta que esté claro que el bloque no será revertido por una reorganización de la cadena. Si no se especifica este campo, se supone que representa 24 horas en bloques.
Uso de datos efímeros en un contrato
Cualquier contrato puede utilizar datos efímeros ejecutando el código de operación EDLOAD. El argumento único del código de operación es el ID (hash digest) del fragmento de datos efímero. Los contratos pueden obtener el ID de un trozo efímero en una transacción ejecutando el código de operación EDID. Este código de operación empuja el ID de los datos efímeros de la transacción actual hacia la columna EVM. Si la transacción no tiene datos efímeros, desencadenan el valor ‘‘todo cero’’. EDLOAD falla si un contrato intenta cargar datos efímeros marcados como retrasados antes del segundo bloque después de la inclusión. Sin embargo, puede almacenar el valor ID para su uso futuro o recibirlo posteriormente en otra carga útil de transacción.
Datos Efímeros y Propagación de Bloques
Los ID efímeros se pueden utilizar durante la validación de bloques, pero los datos efímeros en sí no pueden interferir con la validación si los datos efímeros se marcan como retrasados. Por lo tanto, el procesamiento de bloques se puede llevar a cabo en su totalidad sin haber recibido estos datos.
Esto da a los mineros la oportunidad de comenzar a minar un bloque hijo, incluso si no se ha recibido toda la información del bloque anterior. Esto es similar, pero no es igual a la minería sin validación, ya que un bloque sin validación no puede incluir transacciones, mientras que un minero que aún no ha recibido datos efímeros retrasados puede incluir libremente nuevas transacciones en un bloque hijo. Sin embargo, el minero debe retroceder si transcurre algún tiempo (por ejemplo, 5 segundos) y no se recibieron los datos efímeros retrasados, para evitar que un minero ataque a la red reteniendo los datos efímeros.
El precio de los datos efímeros
Dado que los datos efímeros retrasados en un bloque no aumentan el tiempo necesario para propagar los datos de transacción críticos, los datos retrasados pueden tener un precio mucho menor que los datos de transacción normales.
Demián Lerner estima que en los datos efímeros retrasados se fijará un precio de 10 gas/byte, por lo que un bloque con un límite de 4M de gas puede contener 400 Kbytes de datos efímeros retrasados. Los datos efímeros no retardados se fijarán en 30 gas/byte. Cuando los datos efímeros son referenciados por el EDLOAD, el contrato debe pagar un adicional de 50 gas/byte. Para comparar, en RSK o Ethereum, cada byte de datos de transacción no nulo cuesta 68 gas/byte, por lo que los datos efímeros retrasados no referenciados costarán menos de 1/6 del coste de datos estándar.
Casos de uso de datos efímeros
Demián Lerner cuenta que los datos efímeros tienen muchos casos de uso. A continuación, se describen sólo algunos de ellos aquí.
Grandes juegos multi-jugadores:
Cuando el número de participantes que conforman un protocolo multi partes es alto, el riesgo de interrupciones de la comunicación aumenta considerablemente. Imagine un juego multipartidario justo con los siguientes requisitos:
· Cada participante debe hacer un movimiento a intervalos frecuentes.
. Cada movimiento consiste en una cadena de datos binarios grande que representa un conjunto de acciones del jugador, tal que la verificación de movimiento es demasiado costosa de hacer en la cadena de bloques.·
. Cada participante verificará que los movimientos hechos por los participantes restantes son válidos de acuerdo con las reglas del juego, porque eso es lo mejor para cada jugador.·
Sin embargo, los participantes no confían unos en los otros, así que si Alice detecta que Mallory trató de engañar, los participantes restantes no solo confiarán en Alice, sino que usarán un contrato inteligente como árbitro de confianza para validar el movimiento, aunque sea caro.
Es evidente que los datos de movimiento se pueden convertir en datos efímeros. Este caso de uso está estrechamente relacionado con los canales estatales. A los canales de estado se implementa con frecuencia como un contrato que funciona como un árbitro cuando una parte trata de engañar. Pero permitir que los datos sean enviados como datos efímeros es particularmente útil cuando la cantidad de datos y el número de participantes es alto. En ese caso, la red de criptomonedas puede, incluso, utilizarse como medio de difusión seguro cuando sea necesario.
Los datos efímeros mejoran los canales de estado para reducir la carga en la cadena. En el enfoque de canal de estado, todos los mensajes se intercambian en privado (por ejemplo, en un canal de IRC o sala de juegos), y si un jugador de Alice no recibe un movimiento de Bob antes de un tiempo de espera, debe desafiar a Bob para presentar el movimiento usando un medio de transmisión segura, tal como la cadena de bloques. Pero si Bob presenta un movimiento perfectamente válido al medio de difusión, no está claro de quién fue la culpa y quién debe pagar el costo de verificación. Si Bob puede presentar un movimiento válido en el medio de difusión, entonces hay dos posibles razones por las cuales Alice no recibió la fecha antes:
1. Alice espera que la recepción de los datos de movimiento se haya agotado debido a un problema de conexión a Internet.
2. Bob retuvo los datos de movimiento para Alice a propósito.
Debido a que Internet no garantiza la entrega cronometrada, ni Alice ni Bob pueden probar cuál fue el caso, entonces no está claro quién debe pagar por el costo del desafío y las transacciones de respuesta. Recordemos que el movimiento consistió en una parte grande de los datos, representando un coste alto para la cadena del bloque para almacenarlo para siempre. Si Alice paga, entonces habrá un incentivo para no desafiar a otros jugadores, ya que pueden retener información a propósito, lo que rompe la equidad. Si Bob debe pagar, entonces habrá un incentivo para desafiar a otros jugadores, incluso si no hay razón para hacerlos pagar más, por lo que la equidad también se rompe. Los datos efímeros resuelven este problema al reducir el coste de la transmisión del movimiento en respuesta a un desafío. El costo de un desafío falso será tan bajo que el costo puede ser dividido y pagado por ambos.
Oráculos de empuje seguros y baratos
Los contratos inteligentes requieren oráculos. Los oráculos traen información del mundo exterior a la máquina de estado consensual. Hay dos modelos para absorber la información de oráculos en un contrato inteligente: el modelo de halar y el modelo de empujar.
En el modelo de halar, el contrato de usuario consulta un contrato de oráculo en una transacción determinada en un bloque. El propietario del oráculo (en la práctica, un sistema informático que obedece los comandos del contrato del oráculo) realiza la consulta del mundo real y envía un mensaje al contrato del oráculo que contiene la información. Este mensaje se transmite en otra transacción, generalmente varios bloques después de la consulta. El contrato del oráculo entonces llama de nuevo el contrato del usuario, proporcionando la información solicitada. Este modelo es lento y costoso, ya que requiere una transacción externa e interna adicionales. Ambos incrementan la cantidad de gas consumido en promedio. Este modelo es generalmente útil cuando la información rara vez se solicita más de una vez: por ejemplo, una llamada compleja a un servidor expuesto JSON-RPC API.
Una caché en el contrato del oráculo puede disminuir el coste (en promedio) cuando se producen varias solicitudes de igualdad durante un período de tiempo corto (por ejemplo, el mismo bloque), pero la gestión de la memoria caché también cuesta gas. Pero, en cualquier caso, el contrato de usuario debe ser programado para considerar el caso de una respuesta retardada.
En el modelo de empuje, el propietario del oráculo periódicamente inserta información en el contrato del oráculo. Este modelo es más adecuado para los valores que son comúnmente solicitados y fácilmente tabulados, por ejemplo, los tipos de cambio en un mercado. Además, el modelo de empuje permite a los usuarios saber con mayor precisión qué información será consumida por el contrato antes de hacer una llamada a éste. Si la comisión del oráculo se retrasa, el usuario no tiene manera de saber con certeza el valor real que el oráculo proporcionará antes del hecho. Los creadores del oráculo pueden usar el modelo de empuje haciendo que los datos de éste sean efímeros. Por lo tanto, los datos del oráculo sólo persisten en la cadena de bloques si se consumen, y el costo de mantener el oráculo de empuje se reduce considerablemente. Ahorro de costes en la verificación consensuada de grandes conjuntos de datos Imagine una aplicación distribuida con las siguientes necesidades:
· Un usuario se compromete a obtener un extenso resultado de datos que un contrato inteligente puede verificar.
. Pero tal verificación es costosa de hacer en la cadena.
. En su lugar, la verificación será realizada por un conjunto de verificadores externos.
· Sin embargo, estos verificadores no confían entre sí, por lo que, si un verificador miente, los verificadores restantes solicitarán un contrato inteligente para ser el árbitro de confianza.
El bloqueo de los depósitos temporales por parte de todos los participantes permite que a cualquier tramposo se le castigue confiscando el depósito. Éste es exactamente el caso de uso para el sistema de recompensas de nodos completos de RSK, que se basa en Proof-of-Unique-Blockchain-Storage (PoUBS).
Datos efímeros y el sistema de premios RSK Full node
RSK utilizará datos efímeros para su protocolo y tecnología de Proof-of-Unique-Blockchain-Storage (PoUBS). El protocolo PoUBS permite que un contrato inteligente recompense los nodos que almacenan la cadena de bloques. El protocolo PoUBS requiere que los nodos completos envíen periódicamente fragmentos pseudo-aleatorios de datos de la cadena de bloques a un contrato inteligente especial de hash digest para comprobar que poseen una copia única de la cadena de bloques. Los nodos completos restantes que participan en el esquema de recompensa pueden comprobar las respuestas de otros nodos. La mayoría de las veces las pruebas serán válidas y por lo tanto no habrá necesidad de almacenarlas en la cadena de bloques ni verificarlas mediante un contrato inteligente. En los casos raros que un usuario trate de engañar, y proporcione datos no válidos como prueba, el contrato inteligente puede ser orientado para verificar la prueba y castigar al usuario infractor. En una próxima entrega Sergio Lerner, promete publicar más sobre el protocolo PoUBS, los parámetros elegidos y cómo el contrato lo implementa.