Silvio Micalli, Algorand.– Los Smart Contracts son uno de los obsequios más hermosos y poderosos de blockchain para el mundo. Pero también son técnicamente muy desafiantes. Los Smart Contracts tradicionales se implementan únicamente en la capa 2 y son lentos, costosos y frágiles. Por el contrario, los Smart Contracts de Algorand son mucho menos tradicionales, eficientes y seguros, y se implementan tanto en la capa 1 como en la capa 2.  

Los Smart Contracts de capa 1 de Algorand se ejecutan en la capa de consenso, la capa más segura en cualquier cadena de bloques, sin ralentizar la producción de bloques en lo más mínimo. Estos Smart Contracts son, por tanto, tan eficientes y seguros como los pagos ordinarios. También se denominan contratos TEAL, porque están escritos en un lenguaje especial: TEAL, abreviatura de Transaction Execution Approval Language .

La plataforma de Smart Contract de capa 1 de Algorand tiene dos componentes, a saber:

1. Contratos TEAL Stateless (sin estado).

Esta tecnología se lanzó en noviembre pasado (2019) y se ha discutido en mi blog anterior.

2. Contratos TEAL Stateful (con estado).

Esta tecnología se lanzará este agosto (2020) y es el tema de este blog.

El siguiente y último capítulo de la plataforma de Smart Contracts de Algorand consistirá en sus contratos Smart ² . Como discutí en mi último blog, dicho contrato opera en el nivel 2, pero de formas fundamentalmente novedosas. Esta tecnología se implementará el próximo año.

0. Stateless TEAL

Los contratos TEAL Stateless son programas lógicos muy eficientes diseñados para aprobar o aprobar una sección en el momento en que se envía.

Consisten en una secuencia de al menos 1 KB de unas 30 instrucciones básicas, como COMPARE (X.Y), donde X e Y son números enteros, y VERIFY (X), donde X es una signatura dligitall. Son estatales, porque solo acceden a la información disponible dentro de la propia transacción, que es una de las razones por las que son tan eficientes.

La tecnología TEAL sin estado es muy poderosa, ya que permite configurar restricciones altamente personalizadas sobre transacciones y grupos de transacciones para eliminar intermediarios de alto costo y agregar niveles de transparencia sin precedentes a actividades económicas a menudo opacas. Por ejemplo, con Stateless TEAL, puede publicar un artículo a la venta mucho tiempo con una posible lista de lo que puede aceptar a cambio.

Una vez hecho esto, no se necesita más interacción por su parte: ¡también podría irse de vacaciones! El contrato garantizará que su artículo se venda automáticamente al primer usuario que acepte su oferta. Si sus condiciones no se cumplen por completo, no se realizará ningún intercambio y su artículo permanecerá sin vender.

Al mismo tiempo, la otra parte también está protegida. De hecho, el comercio es «atómico». Cualquiera que sea la segunda parte, ambos tienen la garantía de obtener lo que desean respectivamente. De lo contrario, se mantiene el status quo.

Otros ejemplos de contratos TEAL sin estado incluyen préstamos garantizados, sistemas de depósito en garantía, conjuntos de pagos complejos e interdependientes y mucho más.

1. Stateful TEAL

Los contratos TEAL Stateless son geniales. Pero, ¿qué sucede si necesita un contrato para actuar condicionado a información que no forma parte de las transacciones entrantes? Para estas aplicaciones, hemos desarrollado programas TEAL Stateful.

Como sugiere el nombre, estos programas mantienen el estado y están escritos en TEAL. De hecho, TEAL se ha enriquecido con algunas instrucciones nuevas, no solo para manejar correctamente la información de estado, sino también para manejar árboles Merkle y otras valiosas funcionalidades.

EL RETO

Los contratos Stateful Teal deben respetar el principio fundamental de Algorand: asegurarse de que cada bloque continúe para generarse en unos pocos segundos, con la finalidad inmediata de la transacción.

Garantizar tal rendimiento no es fácil, especialmente si los costos de usuario deben mantenerse bajos.

PRIMERO, ENFOQUE NAIVE.

La información de estado de Storinq directamente en la cadena de bloques es sin duda el enfoque más fácil, pero difícilmente
el más eficiente.

En este enfoque, la información de estado de una aplicación que se ejecuta durante mucho tiempo se dispersaría en bloques muy separados, haciendo imposible, en la capa 1, recuperarla sin ralentizar significativamente la producción de bloques.

Además, los datos, una vez escritos en la cadena de bloques, no se pueden cambiar, pero la actualización eficiente de la información de estado requiere que se sobrescriba. Simular dicha sobrescritura agregando datos más nuevos hará que este primer enfoque sea enormemente ineficaz.

SEGUNDO, ENFOQUE DE BAJA CONCURRENCIA

En otro enfoque, una aplicación puede almacenar su información de estado Off-chain, mientras mantiene solo un compromiso con (por ejemplo, el hash Merkle de) esta información en la propia cadena, para garantizar su integridad.

En este enfoque, cambiar un dato de, digamos, X a Y, requiere presentar una prueba del valor de X, en relación con su compromiso anterior, y generar y almacenar un nuevo compromiso que refleje el reemplazo de X por Y.

Esta forma de proceder, sin embargo, no permite mucha simultaneidad.

Considere dos transacciones, cada una de cuyas ejecuciones se solicita en un momento dado.

La primera transacción requiere cambiar una parte del estado de X a Y, presentando así una prueba del valor de X relativo al último compromiso de la información del estado.

El segundo requiere cambiar otra parte de estado de U a V. Cada una de estas transacciones puede ser válida, no solo individualmente, sino también si se ejecutó después de que la otra se haya ejecutado.

Sin embargo, en este segundo enfoque, ¡cualquiera de las dos transacciones que se ejecute primero retrasará la ejecución de la otra!

Suponga que el compromiso del estado actual de la aplicación es C y que la primera transacción se ejecuta primero.

Luego, después de presentar una prueba, relativa a C, de la corrección del valor X, la primera transacción (a) off-chain, cambia X con Y, y (b) on-chain, cambia el compromiso con el estado de la aplicación de C a C’.

Así, una vez que llegue la segunda transacción, no se ejecutará porque su prueba de la corrección del valor U ya no es válida. De hecho, tal prueba permanece relativa al compromiso anterior C, en lugar de ser relativa al nuevo compromiso C’.

Si la escalabilidad no fuera un objetivo, este segundo enfoque podría, con un esfuerzo adicional, extenderse para hacer frente a unas pocas transacciones por segundo. Pero no podría manejar cientos de transacciones por segundo. El segundo enfoque es inaceptable porque no puede manejar la simultaneidad a escala. Necesitamos una solución diferente.

EL ENFOQUE DE ALGORAND

Algorand resuelve estos problemas almacenando el estado de la aplicación en las cuentas de las partes relevantes: es decir, el creador de la aplicación y los usuarios que han elegido participar.

Una primera razón para elegir este enfoque es que, en Algorand, las cuentas son generadas de manera extremadamente eficiente por sus propietarios, consultadas de manera eficiente y transparente por todos y, en conjunto, baratas de operar. Así que Algorand no impone ningún cargo por mantener una cuenta. El único requisito es mantener un equilibrio muy modesto de 0,1 Algos.

Si el propietario de una cuenta elige crear una aplicación, entonces se requiere un saldo adicional de 0.1 Algos, permitiendo que la cuenta mantenga hasta 64 pares (x, y), donde tanto X como Y son cadenas de 64 bytes.

Cada par adicional aumenta el equilibrio requerido por O.O5 Algos (en realidad, los aumentos de saldo pueden ser de solo 0,035 Algos, si el valor almacenado es un número entero en lugar de una cadena arbitraria de 64 bytes).

Por lo general, X especifica una clave pública y y una cantidad de un token fungible dado (o un token no fungible específico) controlado por la clave X.

Sin embargo, no se imponen restricciones ni a X ni a Y. Por lo tanto, en una aplicación TEAL con estado, (x, y) es un par variable-valor: es decir, X es el nombre de una variable e Y su contenido actual. Estas variables y contenidos almacenan la información de estado de la aplicación.

Específicamente, la cuenta del creador de la aplicación almacena el estado global de la aplicación y las cuentas de todos los usuarios que han optado por almacenar colectivamente el estado local de la aplicación.

Tenga en cuenta que cualquiera puede acceder a la información almacenada en una cuenta determinada. Sin embargo, solo la aplicación puede modificar sus propios estados globales y locales. Esto no es diferente de la forma en que la cuenta de un usuario almacena el número de Algos que posee, pero el usuario no puede modificar (por ejemplo, aumentar) el número de sus propios Algos.

CONCURRENCIA

También tenga en cuenta que el enfoque de Algorand permite una gran cantidad de simultaneidad. De hecho, dos transacciones válidas son libres de modificar legítimamente el estado interno de la aplicación sin que una bloquee a la otra.

Esta simultaneidad es de hecho una de las principales ventajas de fragmentar la información del estado de la aplicación entre las cuentas de todos sus usuarios, una ventaja que se vuelve cada vez más significativa a medida que crece el número de usuarios y transacciones.

RECURSOS, EFICIENCIAS, Y COSTES

Una aplicación TEAL con estado no tiene un estado de arbitrariamente grande.

Como se mencionó, la cuenta del creador de la aplicación puede almacenar hasta 64 pares de valor variable del estado global. Y cada cuenta opcional de suscripción puede almacenar hasta 16 pares de valores variables de estado local.

Estas limitaciones de almacenamiento son necesarias para garantizar que los contratos TEAL con estado de Algorand no ralenticen la generación de bloques. De hecho, este enfoque permite que Algorand maneje, ¡en capa 1!, mil transacciones TEAL con estado por segundo, sin importar cuán grande sea el número de usuarios que optan por participar.

Aunque la cantidad de estado local por cuenta puede parecer pequeña, tenga en cuenta que la información del estado local total crece linealmente con el número de usuarios que optan por participar.

Por lo tanto, será grande si hay muchos usuarios, por lo que es plausible que la cantidad de información de estado disponible sea adecuada en muchas aplicaciones. En cualquier caso, una vez más, la prueba está en el pudín: como veremos en la sección 4, el TEAL con estado puede manejar con éxito muchas aplicaciones cruciales.

En cuanto a los costos, como ya se mencionó, una cuenta de suscripción no paga ninguna tarifa para almacenar su porción del estado local. Más bien, se requiere mantener un saldo adicional de 0.05 Algos por cada par de valor variable de estado local que se requiere mantener. Dicho requisito de saldo adicional se cumple inmediatamente en el momento en que la cuenta se excluye de la aplicación, mediante la publicación de una transacción adecuada en la cadena.

En resumen, el TEAL con estado es una gran adición a la tecnología llayer-1 de Algorand y disfruta de la escala y la gran eficiencia económica a la que los usuarios de Algorand están acostumbrados.

2. Ejemplos de aplicaciones TEAL Stateful

Los contratos TEAL con estado pueden manejar de manera eficiente y segura todo tipo de aplicaciones. A continuación se muestran algunos.

Subastas

Stateful TEAL permite una variedad de subastas. Consideremos, por ejemplo, una subasta holandesa.

Supongamos que tengo N tokens nuevos para vender a través de una subasta holandesa. Luego, creo una nueva aplicación stateful TEAL, con tres variables de estado global:
(a) la cantidad de tokens disponibles, N,
(b) el precio actual P, inicializado a un precio inicial, y
(e) el dinero comprometido total, CM, inicialmente establecido en O.
A intervalos periódicos (por ejemplo, cada 50 bloques), mi aplicación reduce el precio actual P en una cantidad determinada (eq, 0,1 Algos), hasta que se alcanza un precio de reserva o se puede vender todo el suministro de tokens en función de las ofertas actuales. .

Cada usuario de suscripción puede presentar una oferta al precio actual, porque P es parte del estado global y, por lo tanto, es público.

Específicamente, la llamada de un usuario a mi aplicación (1) especifica una oferta que consiste en una cantidad de Algos, A, y un precio máximo, B, y (2) transfiere A Algos a una cuenta de depósito en garantía. Con estas acciones, el usuario muestra su compromiso de utilizar hasta A Algos para comprar tokens a un precio máximo de B Algos por token (o, por supuesto, a un precio inferior). El precio elegido por el usuario: B suele ser igual al actual. prioe P, pero podría ser mayor.

En respuesta a su llamada, al verificar la transferencia de A Algos y asegurarse de que Bis sea al menos igual al precio actual P, mi aplicación:
• almacena el valor numérico A en el estado local del usuario, y
• aumenta en A la · variable de estado global CM.
Tenga en cuenta que la razón por la que el usuario necesita especificar su precio máximo por acción es que, debido a la asincronía, el precio P puede volverse más bajo cuando la oferta del usuario ingrese a la cadena de bloques.

Por supuesto, un usuario puede publicar múltiples ofertas. De hecho, hasta 16 ofertas, si usa una sola cuenta. Si quiere que usted agregue más ofertas, puede abrir cuentas adicionales y publicar todas las ofertas que desee.

Este proceso de licitación continúa hasta que la relación CM / P alcanza al menos N. En ese momento, la aplicación deja de bajar el precio actual y el precio de compensación C coincide con el precio P de la última oferta.

Una vez que finaliza la licitación, algo que se puede detectar fácilmente desde el estado global, todos los usuarios que anteriormente presentaron una oferta ahora pueden invocar la aplicación nuevamente.

Evitando los «casos de esquina» que pueden manejarse adecuadamente de todos modos, la actividad posterior a la licitación funciona de la siguiente manera.

Para cada una de sus ofertas, la aplicación determina, según su estado local y el estado global, si la oferta ganó algunas fichas o no.

En el último caso, los Algos A de su oferta se liberan inmediatamente del depósito en garantía y se devuelven a su cuenta. En el primer caso, la aplicación calcula cuántos tokens ha ganado realmente el usuario, al precio de compensación, debido a su oferta ganadora. (En ausencia de vínculos y otros casos de esquina, la oferta gana tokens de A / C para su usuario).

Este número de tokens se transferirá inmediatamente de mi cuenta a la de ella, y los Algos A que ella originalmente puso en custodia se liberan inmediatamente y transferido a mi cuenta

NOTA: La capacidad de Algorandi para manejar subastas en la capa 1 fue de hecho una de las principales razones por las que el Gobierno de las Islas Marshall eligió a Algorand para su CBDC.

Tokens de seguridad

Los activos estándar de Algorand (ASA) permiten al usuario crear tokens con direcciones de administrador, congelación, reserva y clawoack especializadas. Los ASA resuelven la mayoría de los casos de uso de tokens de seguridad sin necesidad de escribir ningún código de contrato.

Sin embargo, su caso de uso puede requerir más que los ASA. Por ejemplo, es posible que desee lanzar un token de seguridad que requiera restricciones personalizadas sobre quién puede intercambiar el token con quién.

Los contratos TEAL con estado de Algorand le permiten hacer precisamente eso. En mi nivel más alto, el estado global del contrato puede especificar los parámetros generales del token, como el administrador y las direcciones congeladas, la matriz de ‘grupos de autorización y cómo estos grupos pueden comerciar entre sí mientras el grupo de autorización asignado de cada cuenta se almacena en el propio estado local de la cuenta.

NOTA: La capacidad TEAL de estado de Algorand para manejar funcionalidades tan complejas en la capa 1 es de hecho una de las principales razones por las que Republic, un consorcio de cientos de miles de inversores acreditados, ha elegido a Algorand para lanzar su propio token de seguridad.

Crowdsourcing

Un usuario puede usar la cuenta TEAL con estado de Algorand para construir su aplicación gofundme. Si el objetivo del fondo es rnet, el creador de la aplicación podrá reclamar los fondos. De otra manera, los fondos se devuelven a los donantes.

En este ejemplo, la aplicación utiliza el estado global para realizar un seguimiento de la meta del fondo, el total acumulado de donaciones, así como las horas de inicio y finalización. Cuando un usuario que participa en una donación, el monto de su donación se registra en su estado local.

Un contrato aparte, sin estado, retiene el total de las donaciones, con una lógica que permite el gasto en base a las condiciones antes mencionadas.

Exchanges descentralizados

Las transferencias atómicas, un ejemplo previo de la tecnología TEAL stateless de Algorand, permiten a los usuarios de la red intercambiar activos específicos que poseen de la manera más segura y eficiente, sin depender de terceros.

Sin embargo, para poder utilizar una transferencia atómica, debe saber quién está dispuesto a vender qué y a qué precio. Pero, ¿y si no tiene ese conocimiento?

Las aplicaciones TEAL con estado pueden llenar este vacío actuando como un libro arder. Un usuario puede publicar una orden de compra o venta que se almacena en su almacenamiento local en esa aplicación de libro de órdenes.

La lógica de la aplicación asegura que las transferencias solo pueden ocurrir si se cumplen tanto las condiciones del comprador como las del vendedor. Un contrato TEAL independiente y sin estado autoriza la transferencia desde una cuenta de usuario si se cumplen sus propias condiciones de compra / venta y las del otro usuario.

Banca transparente

Algorand permite a los usuarios almacenar libremente Algo y otros saldos de activos. Pero ese valor almacenado se desperdiciará simplemente sentado allí. Aquí es donde una aplicación bancaria de Algorand puede proporcionar valor tanto para los propietarios de activos como para las empresas potenciales o para las personas que buscan préstamos o financiación. ayuda.

En esencia, un usuario decide entregar un conjunto de fondos a una aplicación bancaria en la que confía, gracias a la total transparencia en torno a la aplicación que proporciona el blockchaln.

La aplicación bancaria realiza un seguimiento del saldo alto en el almacenamiento en libras del usuario y deposita los pagos de intereses a ese usuario por retener su dinero.

Por separado, el banco podría almacenar el valor total retenido y su monto de reserva en una variable global, que podría estar vinculada a una cuenta separada sin estado que contiene la reserva del banco.

La lógica de los contratos inteligentes tanto con estado como sin estado asegura que {1) el banco no puede bajar de un cierto mínimo en sus reservas, y (2) los usuarios pueden retirar fondos (con las restricciones adecuadas) libremente. Todo está en la cadena de bloques, seguro y transparente.

Ventas de activos condicionales

Imagine tener la capacidad de demostrar que cualquier venta de un activo en particular requiere una comisión del 5% al ​​creador del activo, o quizás a una entidad gubernamental como algún tipo de impuesto.

Esta condición es difícil de hacer cumplir fuera de la cadena de bloques, ya que debemos confiar únicamente en la honestidad de los vendedores y compradores, y en nuestras instituciones legales, que no siempre son tan rápidas como se desea.

En Algorand, podemos reforzar esta aplicación con una lógica de contrato inteligente que asegura tal honestidad. Específicamente, puedo crear un activo, congelado por defecto, que solo puede descongelarse y transferirse cuando se agrupa con un conjunto de transacciones que aseguren que se envíe un pago de comisión.

En particular, una de esas transacciones grupales es una llamada a la aplicación de gobierno que, utilizando su estado global para especificar el ID del activo y cualquier condición requerida para transferir el activo, puede verificar que esas condiciones se cumplen efectivamente.

El grupo de transacciones también incluiría transacciones para descongelar el activo, antes de verificar las condiciones, y luego volver a congelar el activo después de la transferencia

3. PyTEAL escribiendo contratos TEAL Stateful en Python

Escribir contratos inteligentes puede ser difícil. El código debe aprobar o rechazar transacciones con cuidado y puede implementar dApps meticulosas. Por lo tanto, es mucho más fácil escribir contratos inteligentes en Python en lugar de usar opoodes TEAL, al igual que es más fácil escribir en un lenguaje de nivel Mgh que en ensamblador. Por estas razones, Algorand ha desarrollado PyTEAL

EL PyTEAL ORIGINAL

A principios de este año, Algorand presentó PyTEAL, enlaces de Python en su plataforma de contratos inteligentes sin estado.

En lugar de lidiar con operaciones aritméticas y de condición básicas, empujar y extraer variables de la pila, PyTEAL permite al desarrollador crear objetos que representan variables locales y ejecutar operaciones como aritmética, comparaciones, verificación de firmas y hash en ellas.

El código de Python luego se compila en TEAL Esencialmente, PyTEAL le da al desarrollador el poder completo de TEAL a la velocidad completa de Algorand.

EL NUEVO PyTEAL

Hoy, ampliamos PyTEAL a contratos inteligentes con estado. Por lo tanto, los desarrolladores pueden concentrarse en la lógica de la aplicación mientras PyTEAL simplifica el acceso a la aplicación local y estado global.

Esencialmente, PyTEAL proporciona una API Pythonic simple que permite Colocar, Obtener y Eliminar al estado del contrato inteligente.

Bajo las sábanas, PyTEAL traduce estos comandos a los opcods de TEAL que los implementan. Por tanto, permite escribir aplicaciones sofisticadas de una manera mucho más sencilla y con comparativamente pocas líneas de codificación. Como ejemplo, hemos utilizado PyTEAL para crear un contrato inteligente que implementa tokens de seguridad. Esta nota de examen está disponible en línea: https://github.com/jasonpaulos/pyteal/blob/logicsig-v2-backup/examples/security_token.py

POR QUÉ AMAR PyTEAL

PyTeal es genial:

Modularidad: organice fácilmente el código de contrato inteligente en secciones lógicas utilizando un lenguaje popular y conocido.

Interoperabilidad: como su propia biblioteca de Python, úsela junto con otras bibliotecas de Python y aproveche sus capacidades para obtener un flujo más productivo.

Simplicidad: importe fácilmente datos a través de múltiples contratos inteligentes en un único entorno de desarrollo.

En suma

En resumen, TEAL con estado y la nueva extensión PyTEAL hacen que los contratos inteligentes de capa 1 de Algorand no solo sean más potentes y eficientes que nunca, sino también más fáciles de usar.

Por lo tanto, ¡no camine, sino que corra para usarlas!

Algorand

Silvio Micali ha estado en la facultad del Departamento de Ingeniería Eléctrica y Ciencias de la Computación del MIT desde 1983. Los intereses de investigación de Silvio son la criptografía, conocimiento cero, generación pseudoaleatoria, protocolos seguros y diseño de mecanismos y blockchain. En particular, Silvio es el co-inventor del cifrado probabilístico, pruebas de conocimiento cero, funciones aleatorias verificables y muchos de los protocolos que son la base de la criptografía moderna.

En 2017, Silvio fundó Algorand, una blockchain completamente descentralizada, segura y escalable que proporciona una plataforma común para crear productos y servicios para una economía sin fronteras. En Algorand, Silvio supervisa toda la investigación, incluida la teoría, la seguridad y las finanzas criptográficas.

Silvio ha recibido el premio Turing (en informática), el premio Gödel (en informática teórica) y el premio RSA (en criptografía). Es miembro de la Academia Nacional de Ciencias, la Academia Nacional de Ingeniería, la Academia Estadounidense de Artes y Ciencias y la Accademia dei Lincei.

Silvio recibió su Laurea en Matemáticas de la Universidad de Roma y su Doctorado en Ciencias de la Computación de la Universidad de California en Berkeley.