La Plataforma Plutus - Congreso Cardano Virtual 2020

Subtítulos traducidos al Español y Francés, y también corregidos al Inglés. La Plataforma Plutus - Congreso Cardano Virtual 2020. Con Michael Peyton Jones y Jann Mueller.

Hola a todos, mi nombre es Michael Peyton Jones y estoy aquí con Jann Mueller, a quien vas a escuchar un poco más tarde.
Trabajamos en el equipo de Plutus y vamos a contarles un poco acerca de lo que hemos estado haciendo en los últimos tiempos.

Así que, antes de empezar, necesito aclarar un poco la “publicidad falsa”. Así que, todos ustedes han sido invitados a la Cumbre Virtual de Cardano Edición Shelley, pero Shelley está básicamente acabado, ¿verdad? Ya sabes, está lanzado, ya sabes, todo está bien, todo arreglado, todos están pensando realmente en Goguen, que es la siguiente parte que viene después de Shelley, y eso es de lo que vamos a hablar.

Todo esto es material de la era Goguen, así que me gustaría darte la bienvenida a la edición Goguen de la Cumbre Virtual de Cardano, que es mucho más excitante que la otra… ¡No les digas que he dicho eso!

La primera pregunta que probablemente tengas en tu mente, o por lo menos espero que tengas en tu mente es:
qué estamos haciendo y, más importante, por qué lo estamos haciendo, o sea, ¿cuál es el objetivo de Goguen en general?
Honestamente, ya sabes, Shelley, está bien, la descentralización, ¿verdad? Sabes, en realidad haces que tu blockchain funcione
con mucha gente haciendo cosas de forma independiente.

Pero, ¿cuál es en realidad el objetivo de Goguen y de este asunto de Plutus?
Afortunadamente, creo que hay una respuesta relativamente clara a eso, y eso es aplicaciones, y eso es obviamente muy vago, así que tengo que desenvolver eso un poco, así que voy a tratar de dar, ya sabes, mi comprensión de lo que significa una aplicación en nuestro contexto.

Entonces, ¿qué es una aplicación, estas cosas que nos importan?
Y creo que una aplicación es, en primer lugar, es una especie de programa que interactúa con Cardano de alguna manera, hablaremos un poco más sobre cuáles son las formas interesantes de interactuar con Cardano un poco más tarde, es algo que en realidad está escrito por programadores de la comunidad, así que no sólo está escrito por IOHK, no es algo que tengas que, ya sabes, ser capaz de escribir un algoritmo de consenso para poder hacer, y también es usado por mucha gente, ya sabes, es potencialmente un producto de consumo que muchas personas usan y ejecutan en sus computadoras o teléfonos móviles o algo así,
y la imagen resultante es que en realidad tenemos un ecosistema de desarrollo de aplicaciones que se construye encima de Cardano, pero no está bloqueado por IOHK ni nadie, sabes, los desarrolladores pueden hacer sus aplicaciones, las envían a los usuarios y pueden hacer las cosas que quieran hacer, están empoderados para hacer.

Y lo que vamos a hacer en el resto de la charla es analizar cada uno de estos puntos con un poco más de detalle y explicar cómo se desarrollan en el contexto de Cardano y cómo eso ha influido en el diseño de la plataforma de Plutus, y lo que te traerá el futuro.

Bien, para empezar, ¿qué son estos programas de los que estamos hablando? ¿Qué hacen?
Así que sabes que es una aplicación, pero, ¿qué es una aplicación-qua-programa?
Así que al principio, en todos los diagramas, hay una sola caja en el medio, en este caso dice aplicación, este es tu programa,
está funcionando en un ordenador en alguna parte, pero no quieres que se quede ahí generando calor, probablemente se comunicará con algunas otras cosas, así que imaginemos un ejemplo muy simple, parte de un proceso de pago donde tal vez tengas el servidor web que respalda tu aplicación web, y el usuario toma alguna acción allí, y como resultado necesitas enviarles algo de dinero,
por lo que dice a tu aplicación, dice por favor, ¿puedes enviar al usuario algo de dinero?
La aplicación dice que sí, que lo lograré con el poder de la blockchain, y lo hace presentando una transacción a la blockchain
y hay información que va en sentido contrario, así que la blockchain dice ¡Sí!, tu transacción fue presentada o confirmada o lo que sea que te importe, entonces le dices al servidor web que sí, envié el dinero, está todo hecho, y luego le muestran un pequeño pop up al usuario, o lo que sea que hagan, y esta es la lógica de negocios de tu aplicación.

Pero, como siempre, la lógica de los negocios es sólo una parte de ello, cierto, sabes que siempre hay toneladas de otras cosas de las que tienes que preocuparte y lo mismo ocurre aquí.
Así que para empezar, en el mundo de hoy, los consumidores esperan tener múltiples instancias de sus aplicaciones, ya sabes, tal vez no este procesador de pagos, pero esto es algo que un usuario podría usar, pero podrían tener una instancia corriendo en su teléfono, una instancia corriendo en su ordenador, una instancia corriendo en una tableta, y realmente les gustaría que todos estuvieran en el mismo estado, esperan poder cambiar entre ellos y que esto funcione, así que necesitas hacer algún tipo de sincronización de estados entre esos dos, y más vale que sea bueno porque no quieres hacer lo mismo dos veces, enviar a alguien dinero dos veces, tus usuarios no estarían contentos si eso sucediera.

También tienes que lidiar con todas las otras cosas de administración que vienen con la ejecución de una aplicación de producción, tienes que instalar estas cosas, tienes que poner tu programa en el ordenador donde se ejecutará de manera con la que su equipo de devops esté contento, no quieres que sean descontentos contigo, de lo contrario, vas a pasar un mal rato,
quieres hacer una copia de seguridad porque, bueno, Estoy seguro de que tu infraestructura y tu código son perfectos
y nunca habrá ningún problema, puede que quieras hacer algunas copias de seguridad por si acaso, para que no pierdas todo tu dinero, y quieres tener algún tipo de monitoreo, porque quieres saber cuando las cosas van mal, que estoy seguro que no lo harán, pero, ya sabes, por si acaso, y entonces probablemente también querrás, ya sabes, también estar extrayendo todos tus registros de rutina y mandarlos a tu favorito servicio de registro de la empresa en la nube, lo que sea que uses, así que hay un montón de cosas que hacer, e incluso las partes que parecían inicialmente algo simples, así que esta interacción con la blockchain donde todo lo que hacemos es presentar transacciones no es tan simple, como usuario, y una de las cosas más complicadas que podrían suceder es cuando hay un retroceso (rollback).

Así que tenemos retrocesos en Cardano y en realidad son bastante difíciles de manejar, como usuario en general, y también en particular como autor de una aplicación, porque tienes que hacer que tu programa sea lo suficientemente inteligente para hacer lo correcto. Esto sucede. Así que quiero pasar un poco de tiempo mostrándote un ejemplo de eso, para reforzar este punto.
Así que imaginemos que estamos haciendo una especie de simple intercambio a tres bandas, así que tenemos tres participantes, Alice, Bob y Carol. Alice y Bob quieren hacer un intercambio, tal vez Alice le dará a Bob algunas fichas especiales que significan algo, y Bob va a pagar por ellos en Ada o algo así, pero Bob está desollado, así que Bob llama a su amiga Carol, y dice a Carol, ¿puedes cubrirme para esto?

Carol dice que seguro, de acuerdo. Hay un protocolo muy simple aquí, Alice envía a Bob lo que sea que haya prometido enviar a Bob, Carol puede entonces ver en la blockchain que esto ocurrió, y luego Carol hace su parte, y envía lo que se supone que debe enviar a Alice. Hay un poco de confianza aquí, obviamente, porque Alice tiene que confiar en que Carol va a seguir adelante
y no sólo decir ja ja me voy a ir ahora, ahora que le pagaste a Bob. Y podemos hacer un pequeño diagrama para esto:
así el tiempo va hacia abajo, así que empezamos que Alice le paga a Bob en alguna transacción t1 algún tiempo después de eso Carol lo observa, algún tiempo después de eso Carol le paga a Alice en la sub transacción t2, pero entonces, supongamos que hay un retroceso…

Ahora, la forma en que los retrocesos funcionan en Cardano es que cualquier transacción que se elimine como parte de un retroceso se vuelve a poner inmediatamente en el fondo de las transacciones pendientes y por lo tanto se reaplican, siempre que sigan siendo válidas, aunque no quieras que lo sean. Así que supongamos que Alice ha gastado parte del dinero,
que algunos de los resultados de las transacciones que utilizó para t1 difieren en la nueva versión de la historia a la que nos transferimos como parte del retroceso, así que el t1 ya no es válido, no se aplica.

En esta versión del mundo, bueno, ya sabes, Carol nunca vería la t1 ya que la t1 no se aplicó, Carol nunca habría elegido pagarle a Alice, pero si la t2 sigue siendo válida, y supongamos que lo es, entonces la t2 puede ser reaplicada. Esto es terrible, pero lo que esto significa es que Carol acaba de perder su dinero. Carol le ha pagado a Alice a pesar de que ninguna de las condiciones previas que ella estaba esperando existen más.

Y esto es como la cosa arquetípica que no queremos, no queremos que la gente pierda su dinero, ya sea a través de fallos o a través de cosas que son este tipo de complicados " gotchas". Realmente nos gustaría que la gente no perdiera su dinero si, al menos, si siguen las mejores prácticas y esto es bastante difícil de manejar, porque tenemos una situación aquí donde las creencias de Carol sobre el estado de la blockchain terminan no coincidiendo con lo que realmente sucede.

Y te he dado un ejemplo que tiene humanos reales involucrados porque esto es algo que puede incluso afectar a humanos que entienden el sistema y saben lo que está pasando. En este caso probablemente podrían resolver - Carol puede llamar a Alice y decirle que eso fue raro, ¿puedes devolver el dinero y hacer como si no hubiera pasado nada? o necesitas hacer una transacción diferente para pagar a Bob.

Pero si tienes un programa de ordenador, el programa de ordenador es tan inteligente como tú lo haces, así que si no has tenido en cuenta este caso, vas a pasar un mal rato. Y por eso nos gustaría guiar a la gente a hacer esto, ya sabes, escribir sus aplicaciones de tal manera que son al menos algo resistentes a este tipo de problemas, y el enfoque general que vamos a tomar
es seguir una observación, que aquí está resumida de forma concisa por Rúnar, que es que “Las restricciones liberan, las libertades constriñen” y lo que eso significa es que cuanto más limitas algún componente de tu sistema, menos le permites hacer,
más fácil es trabajar con él.

Cuantas más suposiciones puedas hacer, más fácil es escribir herramientas que interactúen con él de forma correcta, más fácil es hacer las cosas por él automáticamente, porque sabes que sólo puede estar haciendo x, y, y z. Y por otro lado, cuantas más cosas se le permita hacer, más difícil es razonar sobre ello, o proporcionar una infraestructura de propósito general. Así que lo que vamos a intentar hacer es inyectar un poco de disciplina en la forma en que escribimos las aplicaciones, así que el primer paso es que vamos a decir que, bien, ya no vamos a asumir que una aplicación es cualquier programa, en lugar de eso vamos a insistir en que sea una máquina determinística de estado, pura y reproducible, encajonada (sandboxed).

Ahora, eso fue un montón de adjetivos, pero lo que eso significa es que es predecible y determinístico. Así que esto significa que podemos mirar a tu aplicación y podemos decir que si ve las mismas entradas varias veces producirá las mismas salidas, y esto nos da una buena vista externa del estado de la aplicación, podemos decir bien, si nos estrellamos y lo perdemos todo,
podemos alimentarla con las mismas entradas y eso la pondrá de nuevo en el mismo estado, o si necesitamos sincronizarlas, simplemente sincronizamos todas las entradas.

Y porque está en caja de arena sabemos que obtendremos el mismo resultado las dos veces, no puede ser como ir a Wikipedia para consultar el tiempo de modificación del artículo de Napoleón Bonaparte o algo así. Y esto es realmente muy bueno, y aquellos de ustedes que están familiarizados con las tecnologías del día puede reconocer algunas similitudes entre esto y la idea de la búsqueda de eventos para los programas, y no es una coincidencia, es un enfoque muy similar en un problema similar, pero esto hará nuestras vidas bastante más fáciles.

También significa que podemos empezar a alejarnos de un mundo en el que los usuarios son responsables de hacer toda la interconexión a todas esas diferentes partes del mundo, a uno en el que realmente podemos manejar mucho de eso para ellos, y podemos ejecutar aplicaciones en algún tipo de arnés que realmente maneja la interacción con la blockchain, o con la captura de datos, etc., para ellos.

Y en general, nos alejamos de un mundo donde todo lo haces tú mismo, te hundes o nadas, tienes que implementar todas estas cosas, si te equivocas, pierdes tu dinero, a uno donde hay una estructura y tal vez podamos hacer algunas promesas más sobre
cómo si sigues el esquema, haces lo que se supone que debes hacer, entonces las cosas no deberían ir mal, al menos no de esta manera.

Entonces, ¿qué aspecto tiene esto en realidad?
Tenemos nuestra aplicación, otra caja gris, excepto que ahora vive dentro de una caja de arena lo que le impide hacer lo que quiera, y todo esto vive dentro del arnés que llamamos el Backend de Aplicación de Plutus. Obviamente, las aplicaciones todavía tienen que hablar a todas las mismas cosas que antes, tenemos que hablar con la parte trasera de la billetera para que pueda gastar el dinero del usuario, necesita hablar con los nodos reales, podemos presentar algunas transacciones, pero ahora esto está mediado por el backend de la aplicación, así que eso es lo que habla a través de los protocolos de los nodos o lo que sea,
y la aplicación tiene una interfaz simplificada para eso.

Del mismo modo, la aplicación necesita hablar con sus clientes, así que, ya sabes, la aplicación web, ya sabes, algún Cli, quizás algún GUI genérico dentro de una billetera como Daedalus, quién sabe. Pero, de nuevo, podemos enviar eso a través de la Aplicación Backend de una manera transparente y agradable donde todavía podemos ver todo lo que pasa, y podemos hacer todas las repeticiones que nos interesan, y luego, agradablemente, muchas de las cosas como el registro, y el monitoreo, o la administración se pueden hacer de una manera bastante genérica, ya sabes, al menos podemos registrar todos los eventos que ocurren, podemos monitorear la cantidad de dinero que las cosas están gastando, y así sucesivamente, porque vemos todo lo que sucede y cómo sucede.

Otra cosa que es bastante agradable sobre esto, es que debido a que la aplicación no interactúa directamente con cualquiera de estos componentes, podemos simplemente reemplazarlos con versiones simuladas simplificadas de esos, que se ejecutan dentro de algún tipo de piloto de pruebas, lo cual es bueno por un par de razones: una es que significa que no tienes que ejecutar
un nodo Cardano completo para probar tu aplicación, lo cual es bueno, y dos porque a menudo no quieres realmente ejecutar
precisamente la versión de producción de estas cosas, porque te gustaría ser capaz de controlarlos en formas que no puedes controlar el nodo real.

Tal vez quieras decir: por favor, ¿puedes olvidar la mitad de las transacciones que yo hago? porque estoy tratando de probar el caso en el que tengo una mala conexión a la red y pierdo muchas de mis transacciones, y quiero asegurarme de que mi aplicación hace lo correcto. Y si tienes una versión que está diseñada para ser probada, entonces puedes realmente decir cosas como eso,
que es bastante agradable.

Bien, esto nos ha dado una idea de cómo es una aplicación, es un modelo un poco más restringido, pero uno que nos da un poco más de poder por eso.

Pero no hemos hablado mucho sobre lo que hace la aplicación, el ejemplo que te mostré fue bastante tonto, todo lo que hizo fue presentar transacciones que envían dinero de una persona a otra, podrías hacer esto en Bitcoin, podrías hacer esto en la Era Byron de Cardano, no necesitas ninguna característica especial para eso.

Entonces, ¿qué es lo que realmente estamos buscando en nuestro libro de contabilidad?
Y creo que la respuesta a eso es que normalmente lo que la gente busca es la capacidad de tomar parte de la lógica de su aplicación, y ponerla en la cadena para poder aprovechar de las propiedades de consenso de la cadena, para que tengamos una computación que se ejecuta en una manera sin confianza / bien confiada por todas las partes, para que todos puedan asumir que está funcionando correctamente, y si pones la suficiente lógica ahí, entonces eso te permite hacer algunas cosas que antes no podías hacer.

Y hacemos algunos cambios en el libro de cuentas de Cardano con el fin de apoyar algunas de estas técnicas, y hay tres a las que quiero llamar la atención que veremos a su vez: la primera es que ampliamos el modelo básico de libro mayor de Cardano, que es el modelo UTXO, a lo que creativamente llamamos el modelo UTXO Extendido; la segunda es que pasamos de un mundo en el que sólo podemos hablar de Ada a uno en el que realmente tenemos apoyo nativo para una amplia variedad de diferentes bienes que pueden ser emitidos por el usuario, lo que en realidad abre un montón de casos de uso interesantes; y luego, finalmente, mejoramos las capacidades de programación del libro mayor, así que en realidad Shelley tiene programas básicos de Multi-Sig, que creo que no es tan conocido, así que mucha de la funcionalidad básica ya está ahí, pero tenemos un lenguaje de programación mucho más avanzado para las características que necesitamos.

Así que vamos a repasar cada uno a su vez, en primer lugar el modelo UTXO Extendido:
Así que al principio estaba Bitcoin, y Bitcoin usó un modelo UTXO para representar su libro de registros, y UTXO significa “Unspent Transaction Output” (salida de transacción no gastada), y la razón de esto es el concepto fundamental del libro de registros que las transacciones tienen salidas con dinero en ellas, así que aquí tenemos una transacción, una caja gris, tiene una salida, ahora tiene algunas cosas en ella, y esas cosas se quedan en el libro de registros hasta que alguien las gasta.
Así que si quieres conseguir dinero, tienes que consumir una salida que está por ahí, y luego a su vez se producen más salidas que las hacen avanzar. Así que hay una forma un tanto extraña de pensar en ello de alguna manera, ya que tienes estas salidas que son una especie de receptáculos reales de valor, pero tiene una serie de ventajas, y este es el mismo modelo básico que sigue Cardano. Y por supuesto no quieres que la gente pueda gastar cualquier salida, ¿verdad? Así habría dinero, pero no sería el dinero de nadie…

…así que lo más simple que puedes hacer es empezar a bloquear las salidas, y la forma más simple de bloquear las cosas es usar criptografía de clave pública, así que le pones algún tipo de clave a la salida que dice esta es la clave, la clave pública de la persona que posee esto, y luego para gastar eso tienes que firmar tu transacción con la clave privada. Y entonces podemos decir que sí, esta transacción sólo pudo haber sido creada por alguien que controlaba la clave, por lo tanto, tienen derecho a gastar el dinero. Y esto es a menudo generalizado un poco a un modelo que incluye scripts, un lenguaje de programación más poderoso, y así, en lugar de tener sólo una clave pública, tenemos un programa que llamamos el validador, y en lugar de tener sólo una firma, tenemos una especie de entrada, que llamamos el redentor, y el validador recibe el redentor como argumento,
y dice sí o no, y así es como se decide si se te permite gastar la salida.

Y así es como funciona Bitcoin en la práctica, Bitcoin tiene un lenguaje de script, e incluso simples salidas bloqueadas con clave pública se implementan con scripts. El script sólo pregunta si esta firma es válida para la clave pública correspondiente,
pero no obstante es un script, todos se implementan de esa manera. Lo extendemos aún más, así que añadimos dos cosas más:
la primera cosa que hacemos es añadir un poco de datos a la salida, llamamos a esto un datum. Datum es el singular de los datos,
que nadie usa nunca pero mayormente es una palabra que suena como datos pero no son datos, porque la palabra datos está extremadamente sobreutilizada para casi todo. Así que este es un término de la jerga para el trozo de datos que va en una salida, y esto es bastante útil porque es una buena manera de adjuntar información adicional a las salidas sin modificar el validador, porque el validador típicamente determina la dirección de la salida, así que lo ideal es que no interfieras con eso.
Esto es muy útil para llevar el estado, por ejemplo.

La otra cosa es que el validador llega a ver este contexto vagamente nombrado, y este es el contexto en el que se está produciendo la validación, y lo que esto suele ser, es toda la transacción que está siendo validada. Así que lo que esto significa en la práctica es que el validador puede ver todo el contenido de esa transacción, lo que significa que puedes ver cómo vas a gastar el dinero, así que si sólo le das a alguien un redentor que es la firma, dices bien aquí está la firma, comprueba que la firma está bien, no tienes ni idea, y luego puedes hacer lo que quieras con el dinero en el resto de la transacción, la validación no puede saberlo. Pero en realidad dejamos que el validador lo vea, para que pueda ver las otras entradas, pueda ver las salidas, y en particular esto te permite hacer cosas interesantes, como afirmar que hay una salida bloqueada por el mismo validador que tiene, ya sabes, algo de dinero o algo así, y esto te permite crear cadenas de transacciones con el mismo validador, lo cual es clave para hacer patrones más avanzados como las máquinas de estado, y esta no es una idea súper nueva, es una idea similar a la de los pactos de Bitcoin, pero la forma particular en que lo hacemos
es ligeramente inusual y muy poderosa, porque puedes ver absolutamente todo.

Bien, entonces las dos claves que se desprenden de esto:
la primera es que las salidas llevan algunos datos adicionales, y la segunda es que los validadores son capaces de inspeccionar el contexto de la transacción.

Bien, entonces hablemos del soporte de múltiples valores. Para empezar, la mayoría de los libros de registro distribuidos empiezan con el registro de una cosa, y eso es el dinero, algún tipo de dinero, en Cardano es Ada, Bitcoin es Bitcoin, lo de siempre. Pero lo que a menudo se dan cuenta después de un tiempo es que sería muy bueno poder registrar otro tipo de cosas,
tienes este gran sistema para seguir las cosas, a dónde van, a quién les pertenece, pero lo único que puedes hablar es de dinero, y en realidad te gustaría hablar de otras cosas: sombreros, espadas, acciones, no sé, todo tipo de cosas.

Y estos son a menudo llamados tokens o multi, ya sabes, diferentes valores o algo similar a eso, y estamos añadiendo algo muy similar a Cardano.

Así que, volvamos a nuestra transacción y su salida, aquí hay una transacción con una salida y esa salida contiene cinco… ¿Cinco qué? Ada, eso es lo único que hay, no hay otro tipo de cosas, así que es sólo un número. Así que el tipo de valor con el que nuestro libro de cuentas trata son sólo números, es decir, Ada, así que es sólo la cantidad - de Ada - pero eso está implícito.

Bien, entonces, nos hemos dado cuenta que nos gustaría rastrear otro tipo de cosas así que pensamos: OK, vamos a añadir como una etiqueta de algún tipo que nos dice qué tipo de cosa es, qué unidad es, así que diremos que tenemos dos sombreros, no sólo dos,
y entonces podríamos tener dos Ada también, y de esa manera podremos mantenerlos separados y diremos bueno, los sombreros y Ada no son fungibles entre sí, son cosas separadas, y esto es bueno, así que podemos decir bien OK, podemos tal vez llamar a esto como el recurso y por eso tenemos un cierto número de recursos, y dentro de eso tenemos la cantidad de ellos.

Pero una vez que empiezas a pensar en esto un poco, te das cuenta de que a menudo tienes un montón de activos que van juntos,
normalmente se controlan de la misma manera, tienen el mismo dueño, la política similar para manejarlos, digo cosas vagas aquí porque voy a hacerlas precisas más tarde, pero por ejemplo, supongamos que diriges un juego, tal vez tengas Fortnight, y estás emitiendo fichas que reflejan los objetos del juego, así que tienes sombreros, tienes espadas, y la rara espada Excalibur, de la que sólo hay una, es muy valiosa. Y puede que quieras agrupar todo esto bajo algún tipo de dominio de norma, en este caso, ya sabes, Mi Juego, y mantenerlos separados de los demás, igual que antes, pero voy a llamar a esto una norma por ahora, te explicaré por qué en un momento.

Y esta norma es en realidad - parte de la forma ingeniosa en que esto funciona, es que la norma no es sólo una cuerda arbitraria, es en realidad un hash, y es el hash de un script que de hecho es la norma, así que esa es la parte ingeniosa de cómo funciona el sistema, es que el vínculo entre una representación de algunas fichas reales que pertenecen a algún dominio de norma, y la norma están integrados en la representación de las mismas así que no necesitamos hacer ningún paso de registro por separado para establecer esa asociación, y esto hace posible que hagamos esto de una manera muy ligera.

Antes de que hable un poco más sobre la norma quiero señalar que, como dije implícitamente, queremos mezclar estas cosas en una sola salida, no quieres que tu salida sea sólo Ada o sólo fichas de Fortnite, te gustaría ser capaz de mezclarlas libremente
así que en realidad el tipo de valor real es, ya sabes, un paquete de estas cosas. Así que, una vez que hemos pasado por todo eso, en lo que finalmente terminamos es que decimos es como un mapa que va desde los hashes de las normas hasta los tipos de activos y las cantidades, que parece un montón de cosas, pero espero haberte dado una idea por qué es realmente útil tener toda esa estructura.

Bien, hablemos de la norma, y la norma está íntimamente relacionada a cómo se consiguen estas cosas en primer lugar, porque hoy no hay fichas de sombrero en Cardano, estas cosas van a tener que venir de alguna parte.
¿De dónde vienen? Bueno, tienes que acuñarlas, y la forma en que acuñan las fichas es utilizando este campo de forja en las transacciones, así que dentro del campo de forja puedes poner algo de valor, puede ser positivo o negativo de hecho, y si es negativo entonces eso corresponde a la destrucción o quema de fichas.

Y cuando forjas algunas fichas, entonces eso se añade al balance de la transacción, así que si has creado algunos, puedes gastarlos en una salida, si destruyes algunos, entonces tienes que proporcionarlos en una entrada, de lo contrario la transacción no estará equilibrada.

Pero seguramente, hay algún control en esto, cierto, no estamos diciendo que cualquiera puede hacer esto en cualquier momento,
y el control es que también tienes que proporcionar en este campo de los scripts de forja un script s cuyo hash es la norma
y ese script será ejecutado, y se le dará el contexto que será la transacción que estás haciendo y así puede comprobar si se te permite hacerlo.

Así que un ejemplo muy simple podría depender de nuevo de las claves públicas, keys, y podría decir: bueno, si está firmado por esta clave en particular entonces pueden hacer lo que quieran, pueden crear o destruir fichas como quieran. Y esto sería en realidad lo suficientemente bueno para, digamos, las fichas de Fortnight, porque en última instancia, controlan el juego en sí mismo, y esto se supone que es una representación del juego, así que tienen el control final sobre la verdad del asunto, así que dándoles un control total sobre las fichas no te expone a más problemas de confianza.

Pero también podrías hacer cosas mucho más complicadas si quieres, si estás haciendo algún tipo de moneda algorítmica estable o algo así, y hay una pequeña complicación extra, porque en realidad los scripts forjados obtienen un redentor y otro contexto también, pero fundamentalmente el cuadro es como te he mostrado.

Así que la principal conclusión de esto es que:
a) que tenemos este bonito apoyo para los paquetes de fichas nativas,
y b) que tenemos este realmente ligero y sencillo proceso de forja, así que no tienes que hacer una especie de registro global
de una nueva moneda o cualquier cosa, puedes forjarla inmediatamente, y esto en realidad te permite hacer muchas cosas interesantes que no voy a entrar en mucho en esta presentación pero sobre las que puedes leer más en otros lugares.
Finalmente, un scripting más poderoso.

Así que nuestro lenguaje de scripting se llama Plutus Core. Plutus Core es un pequeño lenguaje de programación funcional,
es el Sistema F-Omega con tipos recursivos para aquellos de ustedes que les gusta ese tipo de cosas, y es básicamente nuestro lenguaje de ensamblaje en cadena. Eso significa que no esperamos que nadie escriba en esto, eso sería horrible, es un objetivo de compilación. Así que vas a escribir en algún otro lenguaje y lo compilarás en Plutus Core antes de ponerlo en la blockchain,
y crucialmente, no es muy novedoso, con lo que quiero decir que todo esto es teoría de lenguajes de programación de, ya sabes, hace 40 años y lo consideramos una virtud, porque significa que esperamos no estar reinventando la rueda, y no cometeremos muchos errores estúpidos, y también podemos aprovechar el trabajo de todos los demás que pensaron en este tipo de lenguajes.

Y es, ya sabes, lo que resulta es algo muy reducido, sabes, el evaluador cabe en una servilleta, como puedes ver ahí.
Así que eso es todo lo que hay que decir sobre eso, pero funciona razonablemente bien en ese sentido, eso es todo lo que hay que decir al respecto.

Por tanto, ahora sabemos lo que es una aplicación, sabemos lo que significa para ésta interactuar con Cardano, y cómo vamos a permitirle hacer cosas interesantes con Cardano.

También queremos que la gente escriba estas cosas, ya sabes, tienen que producir aplicaciones de alguna manera, y en última instancia esto no va a ser muy sorprendente. Estamos proporcionando una plataforma de aplicación, vamos a darles bibliotecas y SDKs para escribir aplicaciones, y para empezar el apoyo será básicamente todo en Haskell, así que va a ser un SDK de Haskell.
Tal vez algún día habrá SDKs en otros idiomas, pero no estoy haciendo ninguna promesa en este momento.

Y esto proporciona bastante funcionalidad útil, así que una de las grandes cosas es que tienes que producir estos scripts Plutus Core de alguna manera, y tenemos una tecnología de compilación bastante chula que incluso te permite compilar Haskell mismo en Plutus Core! Puse un pequeño signo de exclamación ahí porque eso es en realidad bastante difícil, así que estoy muy contento de que eso funcione, en realidad funciona muy bien.

Y de hecho, por eso, y por el hecho de que que el resto de la aplicación está en Haskell, puedes escribir todo esto juntos, puedes escribir en un mismo fichero, incluso podrías compartir tipos y funciones entre el código On- y Off-chain, que en realidad es muy bueno, y obviamente, también proporcionamos bibliotecas para escribir una aplicacion que sigue el modelo y puede hablar los protocolos correctamente, así que eso es todo lo que se espera.

La otra herramienta de desarrollo que proporcionamos es el Plutus Playground, que algunos de ustedes pueden haber visto en presentaciones anteriores, y esto es básicamente una especie de ambiente de desarrollo en línea, no tan completo como el que tienes si descargas y usas las bibliotecas locales, por supuesto, pero es genial para empezar, y tiene algunas cosas lindas,
como que puedes crear tus casos de prueba gráficamente y moviendo las cosas y luego ejecutarlos y visualizar las salidas,
que con suerte, ya sabes, las cosas locales también conseguirán esta elegante UI a la par, pero es una buena herramienta adicional.

Y la última cosa de la que tenemos que hablar, es que tenemos que hablar de los usuarios de estas cosas, y los usuarios tienen muchas necesidades, así que si quieres que tu aplicación sea usada por otras personas, tienes que poner la maldita cosa en sus ordenadores, tienes que distribuirlo de alguna manera, tienes que actualizarlo cuando sacas nuevas versiones, tienen que ser capaces de manejarlo, tienen que ser capaces de, ya sabes, controlar la cantidad de dinero que está usando, y tienen que auditar lo que está haciendo, para que puedan confiar en él, tiene que haber una IU para ello, probablemente IU gráfica, tal vez interfaces cli para tus usuarios avanzados, necesitan un montón de cosas.

Y todo esto es realmente un trabajo en progreso en este momento, así que espero que haya más para informar en el futuro,
pero por el momento, bueno, no tenemos suficientes usuarios para decir, pero espero que esto se desarrolle mucho a medida que pase el tiempo.

Y esa es realmente la situación, así que puedo mostrarles este diagrama de arquitectura algo feroz, que más o menos cubre básicamente las cosas que hemos discutido hoy, y un par de enlaces para leer más, así que está el Informe Técnico de la Plataforma Plutus que también cubre un terreno bastante similar, y también una de las charlas de Manuel en Lambda Jam el año pasado, que sigue siendo válida y bastante buena.

Y con eso te voy a entregar a Jan, que va a hacer una pequeña demostración.

Gracias Michael, soy Jan Mueller, y ahora voy a mostrarles la demostración de la plataforma de aplicación.
Bien, esta es la Plataforma de Aplicación de Plutus, está funcionando en mi máquina local aquí, y está conectada a un nodo emulado que también funciona en mi máquina, y ese nodo está validando la transacción Goguen que tenemos, y sólo está añadiendo nuevos bloques a la blockchain mientras está funcionando.

Y cuando se abre la Plataforma de Aplicaciones recibirás una lista de los contratos que has instalado. En este caso, he instalado dos contratos: uno se llama Atomic Swap (Intercambio Atómico) y otro se llama Currency ( Divisas).

Hablaremos del Atomic Swap en un segundo, por ahora, voy a usar el contrato de divisas para crear mis propias fichas en esta blockchain local. Así que haz clic en Activar, y Activar inicia una nueva instancia del contrato, y una vez que hayas instalado un contrato puedes tener cualquier número de instancias de él funcionando, y le voy a dar un nombre, el nombre de la nueva moneda, Mi Ficha, y una cantidad. Y cuando una instancia de contrato está en marcha, puede consultar al usuario para obtener información en cualquier momento, muy similar a la forma en que se manejaba en el Playground, donde teníamos puntos finales.

Obtienes una simple UI que se genera para los tipos de datos que el contrato espera, y en este caso hay un contrato que pide un nombre de ficha y la cantidad, que va a ser de 1.000 unidades. Así que voy a hacer clic en Enviar, y esto desencadenará una serie de transacciones enviadas a la blockchain y al validador, y eso va a tomar unos segundos, y mientras eso sucede, Voy a iniciar una segunda instancia de la Plataforma de Aplicaciones, y luego más tarde quiero intercambiar estas fichas.

Vamos a crearlo con esta otra instancia, localhost:8085
Ahora, este es otro proceso que está ejecutando la Plataforma de Aplicaciones, no está conectado a la primera plataforma de aplicaciones de ninguna manera, excepto que ambos están hablando con el mismo nodo, para que tengan una vista de la misma blockchain.

Y en este caso sólo tengo un contrato instalado, pero ahora veamos la pestaña de la blockchain. Aquí podemos ver las transacciones que están actualmente en la cadena y como ésta es una pequeña cadena emulada, no hay mucho sucediendo en ella,
sólo tenemos dos transacciones por ahora, la primera, hacemos clic en ella, muestra los detalles, la primera
es la transacción inicial que genera todo el Ada que tenemos en nuestra red de pruebas, y se pueden ver los resultados de estas transacciones, en el lado derecho aquí las cajas verdes son direcciones de clave pública, y esta transacción aquí paga 10 000 Lovelace a cada una de estas 10 direcciones de clave pública, y estas son las direcciones de los agentes que emulamos aquí en esta red de pruebas, así que tenemos 10 direcciones con 10.000 Ada cada una, y tenemos una segunda transacción que es
parte del proceso de creación de la moneda que está actualmente en la otra plataforma de aplicaciones, así que ya podemos verla en la cadena aquí, pero ésta no crea la moneda todavía, habrá otra transacción que haga eso, ésta está haciendo un trabajo de preparación para ella, y podemos ver que tiene dos salidas, y en particular produce una salida de script, la caja naranja aquí a la derecha, que bloquea a este Lovelace, bloqueado por la dirección del script.

Ahora, si volvemos aquí y actualizamos, deberíamos ser capaces de ver, sí, así que estamos viendo la misma blockchain, y podemos ver que se ha añadido una tercera transacción, y esta es la transacción que realmente crea las fichas, y sus entradas están aquí a la izquierda, esa caja naranja, la salida del script que se produjo antes, se gasta en esta nueva transacción, y en el lado de la salida vemos que paga algún valor a esta dirección de clave pública, y el valor que paga es un Lovelace, y también 1000 unidades de Mi Ficha, así que aquí es donde hemos creado la moneda, y el hash aquí en la parte superior, esta es la norma de este activo, que regula cuando nuevas fichas de esta divisa pueden ser forjadas.

También podemos ver que hay una caja azul aquí, debajo del cuerpo de la transacción, que detalla los valores que fueron forjados por esta transacción, para que podamos ver de nuevo, este es el hash del script, y creó 1000 unidades de mi ficha. Y el hecho de que esta entrada de script aquí fue gastada es bastante importante, porque esta entrada aquí está incluida en el hash de la norma de la ficha, así que si alguien quisiera crear más de mi ficha, tendrían que gastar la misma salida de nuevo, esta salida de aquí, pero no pueden porque la salida sólo se puede gastar una vez, y por lo tanto tenemos una garantía de que sólo habrá 1000 unidades de mi ficha, por lo que el suministro total de esta moneda es muy limitado, sólo hay 1000 unidades.

Podemos, por supuesto, escribir normas monetarias más complicadas en esto, pero este simple ejemplo dice de forjar 1000 unidades exactamente una sola vez, nadie más puede hacerlo de nuevo, y después de eso habrá 1000 unidades de esto.

Si miramos hacia abajo en esta vista, veremos los balances en la blockchain, y tenemos las 10 direcciones de clave pública de los agentes que tenemos, y la dirección del script. Actualmente hay cero, hay un valor cero bloqueado en la dirección del script, pero hay 1000 unidades de mi ficha bloqueadas en esta dirección de clave pública, y esa es la dirección del agente que ejecutó el contrato de creación de divisas.

Así que ahora intercambiemos esta moneda. Quiero dar algunas de estas fichas que acabo de crear al otro agente de aquí, a este proceso que se está ejecutando en esta pestaña, y para hacer eso quiero usar un contrato, y quiero usar el contrato porque
quiero estar seguro de que el dinero se intercambie realmente, no quiero enviarlo primero y luego tener que esperar a que esa persona haga otra transacción, quiero que se paguen al mismo tiempo, quiero que ambas cantidades se paguen al mismo tiempo, y para eso está el contrato de Intercambio Atómico.

Así que activé ese contrato, y tendremos que hacer esto en ambos lados así que primero pongamos la cantidad de Lovelace, 100 Lovelace, el símbolo de la moneda que acabo de copiar, es el hash, y el nombre de la ficha es mi ficha, y digamos que 100 fichas de eso, y la parte uno es la billetera 1, la parte dos es la billetera 2, y tenemos un plazo límite de digamos 2.000, y hacemos clic en enviar.

Mientras eso se carga tenemos que hacer lo mismo de este lado aquí, así que 100 Lovelace, es esta moneda, mi ficha, 100 unidades, billetera uno, billetera dos, y plazo límite 2000, y hagamos clic en enviar, OK.

Y mientras esto sucede, voy a explicar el contrato de intercambio atómico un poco más, voy a explicar lo que hace. Ya podemos ver que hay una nueva transacción, así que anteriormente teníamos tres transacciones, y ahora esta es la cuarta, y esta es parte del Intercambio Atómico, y la cuarta transacción aquí, podemos ver que paga 100 unidades de mi ficha a una dirección de script,
la caja amarilla aquí, 773, y esta es la dirección del script del contrato de intercambio, y la segunda parte, aquella cuya pestaña estamos mirando actualmente, va a crear otra transacción que también paga algo de dinero a esta dirección del script, a la misma cabecera 773, pero pagará 100 Lovelace, de modo que cuando la segunda transacción esté en marcha, tendremos 100 Lovelace y 100 mis fichas en esa dirección.

Y luego para gastarlos vamos a tener una tercera transacción, que se debería poder ver ahora haz clic en refrescar, y OK, así que vamos a empezar con esta, esta es la que paga 100 Lovelace a la dirección de script 773, y en este momento, el slot 481, si miras los balances puedes ver que el script aquí está bloqueando 100 Lovelace y 100 de mis fichas, por lo que actualmente están en la dirección del script en dos salidas diferentes, de dos transacciones diferentes, y se gastan por esa transacción, así que podemos ver la última transacción aquí, toma las dos salidas de script, ambas tienen la misma dirección pero diferentes cantidades, y las paga a las claves públicas que se especificaron.

Y el script validador de esta salida, se asegura de que las entradas aquí sólo pueden ser gastadas si estas salidas exactas están en la transacción, así que 100 de mis fichas van a esta dirección de clave pública, la primera, y 100 Lovelace van a esta clave pública como la segunda.

Y así es como el contrato obliga a que el intercambio se lleve a cabo, que el intercambio se realice según lo acordado, y podemos hacer esto sin depender de un tercero o una caja de intercambio o algo así, sólo usando el contrato en cadena y el libro de activos múltiples que facilita esto.

Y sólo una última mirada al balance, aquí podemos ver que esta dirección de clave pública, la tercera desde arriba, tiene 10.100 Lovelace, así que tiene 100 más de los que tenía al principio, y le quedan 900 de mis fichas, y luego la primera dirección aquí, así que 3d sólo tiene 9 900 Lovelace, pero recibió las 100 fichas mías, así que usamos el contrato para asegurarnos de que todos
juegan según las reglas de este pago, y si una de las partes no hubiera hecho su pago, entonces la otra parte habría podido
reclamar un reembolso del contrato sin siquiera involucrar a la otra parte, así que no tuvimos que confiar en nadie, sólo usar el contrato para hacer el intercambio en cadena.

Y así concluye la demostración de la Plataforma de Aplicación, gracias.
Bien, gracias a todos por vernos, y apreciamos mucho sus preguntas.