Explorando JavaScript y contratos inteligentes con el CEO de Agoric, Dean Tribble

En este AMA tuvimos el placer de entrevistar a Dean Tribble. Dean es el director ejecutivo de Agoric y tuvo un gran recorrido en tecnología al participar en varios proyectos de software y nuevas empresas desde los años 80. Ha estado persiguiendo una visión de sistemas informáticos en red a gran escala y eso lo llevó a los contratos inteligentes.

Este hilo de Slogging de Sara Pinto, Dean Tribble, Dimitar Bochvarovski, Pawan Sharma, Mónica Freitas y Limarc Ambalina se produjo en el canal oficial #amas de slogging y ha sido editado para facilitar la lectura.

Hola @channel, únete a mí para dar la bienvenida a nuestro próximo invitado de AMA, Dean Tribble, director ejecutivo de http://agoric.com . Agoric es una empresa de desarrollo de código abierto que lanza una economía y una cadena de prueba de participación interoperable.

No dude en preguntarle a Dean cualquier cosa sobre:

¡Hola! ¡Gracias por tenerme!

Hola Dean Tribble, es genial tenerte aquí con nosotros. ¿Podemos comenzar contándonos un poco acerca de sus antecedentes?

Tuve mi primer trabajo en una computadora cuando tenía 15 años, mi primera startup (financiada por el fundador de Atari, Nolan Bushnell) cuando tenía 17 años. Así que he estado haciendo software y startups desde los años 80. Gran parte ha sido en la construcción de sistemas distribuidos a gran escala.

He estado persiguiendo una visión de sistemas informáticos en red a gran escala durante literalmente décadas. Trabajé en Xerox PARC (con algunos de mis colegas aquí en Agoric) en los primeros sistemas operativos y lenguajes de programación distribuidos seguros. Las promesas modernas en JavaScript y RUST descienden de ese trabajo. Luego fui y trabajé en hipertexto (antes de la web) en Xanadu. En algún lugar de 1989 trabajé en el primer contrato inteligente de producción (sí, 5 años antes de que naciera Vitalik 🙂.

Desde entonces, he trabajado en muchos sistemas a gran escala, desde los primeros sistemas de información de corretaje en Java hasta mi concierto anterior de un instrumento de pago multimillonario. ¡Por lo general, se trata de llevar nueva tecnología al mercado para permitir que un extraño coopere con más éxito!

Eso es lo que me llevó a los contratos inteligentes en primer lugar: "el software que hace cumplir los términos de un acuerdo similar a un contrato entre múltiples partes" simplemente permite mucha más cooperación en el mundo. Todos los negocios, desde eBay y PayPal hasta AirBNB y Lyft, son ese tipo de negocios.

Todos ellos requieren un intermediario confiable y, como sabemos, no siempre son confiables 🙂. Pero luego apareció la cadena de bloques que permite que las computadoras independientes en diferentes jurisdicciones ejecuten el mismo software y verifiquen el trabajo de los demás, y de repente puede ejecutar negocios de contratos inteligentes sin el intermediario de confianza. Eso es lo que me llevó a construir una infraestructura de contratos inteligentes para la próxima generación de cadenas de bloques. Y aquí estamos 🙂

Eso me hace darme cuenta de que omití a Sun y Microsoft allí.

En Sun Labs, en los años 90, teníamos un proyecto para construir una plataforma de contrato inteligente. Esa es una gran parte del trabajo de diseño inicial que condujo a elementos de la plataforma de contrato inteligente JavaScript de Agoric.

En Microsoft, fui arquitecto del sistema operativo Midori (investigación), un sistema operativo de investigación que usaba el mismo enfoque de arquitectura basado en mensaje/ocap/promesa de aysnc que ahora usamos en Agoric vm/kernel.

Que carrera 🙂

¿Por qué JavaScript? Quiero decir, yo personalmente soy un desarrollador web y uso JS en mi día a día, y es el lenguaje que no cambiaré por nada más, pero hay mucha discusión sobre los problemas que vienen con JS, como tipos dinámicos, y la facilidad de cometer errores con la gestión de memoria...

Y soy un gran admirador de Kyle Simpson, por mencionar. Tiene cursos interesantes para capacidades de objetos en js.

Me encanta esa pregunta porque tiene respuestas sorprendentes y sorprendentes.

La respuesta que no sorprende está en “…es el lenguaje que no cambiaré por nada más…”. ¡13,9 millones de desarrolladores! Quiero ver más cooperación en el mundo, y los contratos inteligentes son una herramienta increíblemente poderosa para ayudar a que eso suceda. Sin embargo, para que eso importe, tiene que estar disponible para la mayoría de los programadores del mundo. No es de mucha ayuda si, para construir un contrato inteligente, tienes que ir a rezar al sacerdocio de los 10k costosos desarrolladores de Solidity. ¡Es más fácil encontrar un buen abogado y hacerlo a la antigua! Así que nos propusimos conocer a los desarrolladores donde están y empoderarlos para construir contratos inteligentes.

La sorprendente respuesta es que JavaScript es más seguro que la mayoría de los demás lenguajes de programación, debido en gran medida a las contribuciones de nuestro científico jefe, Mark Miller. Ha estado introduciendo los elementos necesarios en JavaScript de nuestro trabajo anterior de lenguaje seguro desde el principio. Su artículo de 2015 en criptografía financiera sobre "Instrumentos financieros basados en capacidades" mostró ejemplos en el lenguaje de programación E que ahora puede escribir en JavaScript en Agoric.

La razón por la que JS es más seguro también es en parte un accidente de la historia: el lenguaje JS se estandarizó en ECMA, mientras que el entorno de host del navegador se estandarizó en W3C. Eso corresponde a una separación de modo de usuario/modo de sistema que se requiere para sistemas operativos seguros. Nunca has visto un límite de diseño tan bien defendido como los comités defienden su territorio 😄. Entonces, la única forma en que un programa/módulo/lo que sea JS obtenga autoridad sobre cualquier cosa en el sistema es si se coloca en el objeto global utilizado para la evaluación. En el navegador, ese global incluye

 document

tal, mientras que en el nodo, lo global incluye

 fs

y

 process

y similares. Mark y otros han mantenido a JS en ese camino. Y con algunas características adicionales (p. ej.,

 freeze

) podemos evaluar el código JS (por ejemplo, en la cadena de bloques o en los servidores) donde la única autoridad que obtiene es para los servicios específicos que le brindamos. No puede acceder al sistema de archivos, la red, etc.

ese es el "JavaScript endurecido". Es de código abierto, está disponible para web2 y web3 en https://github.com/endojs/endo y se ejecuta en cualquier entorno JS estándar. Es la columna vertebral de la billetera de próxima generación de MetaMask, que se usa en AppExchange de Salesforce y, por supuesto, se usa para nuestra plataforma de contrato inteligente.

¡Dean Tribble, eso es increíble! Tuviste todo el viaje. Tengo que preguntar, en nombre de las personas que no son tan expertas en tecnología, ¿podría dar más detalles sobre los contratos inteligentes en la cadena de bloques? ¿Y a qué te refieres con componibilidad?

En cuanto a lo que es un contrato inteligente: "software que hace cumplir los términos de un acuerdo similar a un contrato entre múltiples partes". ¡Eso! Por lo tanto, eBay, PayPal, Lyft y StubHub son en gran medida negocios de contratos inteligentes implementados por un "intermediario de confianza". Por lo tanto, los contratos inteligentes tenían una capitalización de mercado de más de $1 billón *antes* de blockchain. Confiamos en los intermediarios para ejecutar fielmente su software, y la mayoría de las transacciones se realizan sin ninguna participación humana por parte de la empresa de alojamiento.

Estos negocios despegaron mucho más rápido una vez que hubo buenas bibliotecas y plataformas para componer rápidamente nuevos negocios sin codificar todo desde cero (por ejemplo, Shopify, Stripe, etc., todos los componentes proporcionados que los desarrolladores podían reutilizar).

¿Por qué fue tan difícil encontrar un "código que se pueda ejecutar en la cadena de bloques", que es el contrato inteligente en general (corríjame si me equivoco), y necesitábamos esperar a que Ethereum viniera con esto? ¿solución?

Pero mi ejemplo de modelo de componente favorito está en el espacio de la interfaz de usuario (después de todo, trabajé en interfaces de usuario como pasante en el grupo de Smalltalk en PARC). Antes de React/vue/etc., los expertos podían crear algunas cosas geniales en JavaScript. PERO es una pesadilla depurar aplicaciones sofisticadas escritas en HTML/JS sin procesar (todavía recuerdo mi última ronda tratando de depurar por qué la tasa de impuestos de alguna página de compra no cambiaba cuando el usuario cambiaba su código postal). React proporciona un marco de componentes para los componentes de la interfaz de usuario que aborda por completo muchos de los problemas difíciles en la creación de interfaces de usuario sofisticadas, y más, permite que los componentes creados por múltiples partes funcionen juntos extremadamente bien.

El resultado es que, poco después de que saliera React, los nuevos desarrolladores pueden crear aplicaciones más sofisticadas, seguras, con mayor capacidad de respuesta y más útiles que las que podían hacer los expertos el año anterior a React. Eso es lo que te ofrece un framework de componentes.

Nuestro objetivo es un marco que brinde el mismo tipo de soporte, pero para contratos inteligentes que manejen activos digitales, precios, etc. (en lugar de hacer clic y renderizar). En plataformas como Ethereum, existen riesgos de seguridad que son francamente demasiado riesgosos para los criptoexpertos, y mucho menos para los programadores de aplicaciones que solo intentan resolver su problema comercial. Nuestro marco está diseñado para proteger a los desarrolladores de esos peligros.

Por lo tanto, un contrato inteligente no es un "código que se puede ejecutar en una cadena de bloques", ya que había más de $1 billón de valor en los contratos inteligentes antes de las cadenas de bloques.

Bitcoin es en sí mismo un contrato inteligente; es un software que hace cumplir las reglas para la transferencia de BTC. Es el primer contrato inteligente que no necesitaba un intermediario de confianza.

Eth trajo soporte para ejecutar el software de otras personas. Había un par de requisitos para eso. El estándar de oro de blockchain es

múltiples computadoras en diferentes jurisdicciones y diferentes dominios administrativos que llegan a un consenso sobre datos, opciones y computación.

Desempaquetaré eso y luego hablaré sobre por qué es importante 🙂.

Hola Dean Tribble ¿Podría explicar un poco sobre la seguridad de la oferta en Agoric y si reembolsa el activo original más la tarifa de transacción o solo el activo original?

múltiples computadoras en diferentes jurisdicciones y diferentes dominios administrativos, todos llegando a un consenso

Significa que ningún ser humano, organización o gobierno puede cambiar unilateralmente el comportamiento de los sistemas. Tendrían que comprometer simultáneamente la mayoría de las máquinas (que están controladas por otras partes) para comprometer la integridad de la computación.

sobre datos, opciones y computación.

Datos: “Dean tiene $100 en su cuenta”
Opciones: “Dean trató de retirar su oferta antes de que cerrara la subasta. ¿Ganó la subasta y gastó su dinero o lo recuperó?
Cómputo: “la subasta se realizó y determinó que Dean sería el ganador”

La parte técnica dura novedosa es "todo llegando a un consenso". Si conoce todas las computadoras (no las conoce) y puede confiar en todas ellas para no hacer trampa (no puede), entonces sabemos cómo contar los votos y asegurarnos de que sea una mayoría. El área de Tolerancia a fallas bizantinas cubre el manejo del "qué pasa si hacen trampa". La idea más brillante en BitCoin fue cómo abordar el consenso cuando no conoce todas las computadoras participantes.

Finalmente, para que todas esas computadoras verifiquen que están de acuerdo, ¡tienen que estar realmente de acuerdo! Entonces, el mismo programa que se ejecuta con los mismos argumentos varias veces en varios lugares tiene que producir las mismas respuestas (esto se llama "determinista"). ¡Eso resulta ser difícil! Si pueden ver el reloj, pueden comportarse de manera diferente. Si pueden ver cualquier dirección de memoria, pueden comportarse de manera diferente. Si pueden ver cuándo ocurre la recolección de basura,... entiendes la idea.

Entonces, Solidity tiene muchos problemas y es de muy bajo nivel, pero se ejecuta de manera determinista. ¡Nuestro JavaScript reforzado le permite ejecutar JavaScript de manera determinista! Eso hará que todo esto sea accesible para muchos más desarrolladores.

Pawan Sharma pregunta sobre la "seguridad de la oferta" en Agoric. Esa es una de las propiedades críticas del marco de contrato inteligente. Las propiedades de seguridad familiares son cosas como la seguridad de la memoria y la seguridad de tipo, donde simplemente eliminan por completo una gran clase de errores. No resuelven todo, pero pueden eliminar el 80 % de los errores.

Ofrecer seguridad es una propiedad de seguridad a nivel económico.

Primero, la configuración: en los sistemas de contratos inteligentes de cadenas de bloques existentes, ejecuta transacciones enviando dinero a un "número aleatorio" (una dirección de cuenta) y esperando que suceda algo bueno. Las personas han enviado (y perdido) activos a "direcciones" que no eran cuentas reales, que eran cuentas incorrectas, a contratos que luego fallaron, etc. Este modelo es propenso a errores y una interacción de usuario horrible. Quiero enviar dinero a mi amigo John, no a 0x234ag3453.

Los negocios reales involucran quid pro quo: “Te daré $ X si me das una entrada para el concierto Y”. Apoyamos eso directamente. Entonces, en nuestra API, los clientes invocan contratos inteligentes haciendo

 offer

s. Cada oferta dice lo que

 want

, lo que harán

 give

para y bajo qué circunstancias pueden

 exit

con sus bienes. Los pagos en esa oferta van al marco mismo y NO al contrato inteligente. La única forma en que el contrato inteligente puede obtener los activos es si proporciona los activos que desea la oferta.

Entonces, ¿cómo se ve la seguridad de la oferta para una subasta?

Zoe posee todos los activos y notifica el contrato de cada oferta. Cuando la subasta se cierra, la subasta se contrae atómicamente.

 reallocates

la entrada del concierto al postor ganador y el dinero del postor ganador al vendedor. Esa reasignación solo tendrá éxito si la oferta ganadora es suficiente para el vendedor y si la entrada para el concierto es de hecho lo que el postor pujó.

Ningún mal comportamiento, error, etc. por parte del contrato de subasta puede permitirle tomar dinero de los postores que no obtienen la entrada para el concierto.

Eso significa que los clientes de la subasta están MUCHO más seguros. No necesitan leer el código de la subasta para saber que obtienen el boleto deseado o que les devolvemos su dinero.

Además, el creador del contrato de subasta también está contento: muchos de los peligros en Solidity tienen que ver con el manejo de dinero que se supone que no debes retener. Literalmente se han perdido o robado más de $1000 millones debido al manejo descuidado de la devolución del dinero de los contratos. Con Zoe y ofrece seguridad, no necesita escribir una sola línea de código en el contrato para manejar eso de manera segura.

Una propiedad relacionada es la "vida de pago": recuerde que cada descuento tiene un

 exit

como parte de sus términos. El valor predeterminado para eso (que convenientemente no necesita especificar) es “cuando quiera; ¡Es mi dinero, maldita sea!“. Bueno, está bien, se llama "OnDemand" 🙂 Eso solo significa que puede salir cuando quiera y, de nuevo, ningún error o comportamiento malicioso por parte del contrato puede retrasar su salida de la oferta y recuperar sus activos. Tenga en cuenta, sin embargo, que "sus activos" pueden ser después de que ya hayan ocurrido algunas reasignaciones. Si su oferta fue "Compraré hasta N boletos para X moola", entonces es posible que ya le haya reasignado algunos de esos N y haya tomado dinero por ellos, de acuerdo con el

 want

que especificaste. Pero una vez que llega su señal de salida, Zoe extrae sus activos y se los devuelve sin que el contrato intervenga. Del mismo modo, si el contrato falla, cuelga, etc., Zoe saldrá de su oferta. ¡Es asombroso cuánto dinero se "bloquea" involuntariamente en contratos en los que los usuarios no tienen medios para recuperar su dinero!

Dean Tribble, ¡muchas gracias por tu respuesta detallada! ¿Qué pasa con las vulnerabilidades de los contratos inteligentes? ¿Cómo se pueden reducir?

Dean Tribble Gran explicación!!

Para conocer formas de reducir las vulnerabilidades de los contratos inteligentes, discutimos

Formas críticas adicionales:

En Ethereum y otras cadenas (más recientemente, PolyNetwork), miles de millones en pérdidas provienen del "reingreso". Ahí es donde, si hay 2 componentes (o contratos), A planea llamar a B y luego hacer algo X, pero B vuelve a llamar a (vuelve a ingresar a A) antes de que pueda llegar a X. Por ejemplo, A es una subasta, un B solicita un reembolso de la oferta. B dice "envíame mi reembolso", por lo que A lo busca y envía el reembolso a B, y luego registra que le ha dado un reembolso a B. PERO cuando B recibe el reembolso, en lugar de responder "gracias", inmediatamente envía el mensaje "envíame un reembolso" a A nuevamente. Como A aún no ha registrado que B haya recibido su reembolso, continúa y envía el reembolso nuevamente . Y nuevamente, B reacciona a eso con "envíame un reembolso". El servicio A nunca llega al punto de registrar que B ha recibido su reembolso, por lo que B solo hace esto hasta que ha vaciado la cuenta de A. Suena absurdo cuando se dice así, pero este fue exactamente el error en 2017 que hizo que la gente se preguntara si la tecnología detrás de Agoric podría ayudar a blockchain. Y un exploit de $ 660 millones el año pasado fue el mismo problema básico. Es porque la arquitectura de Eth permite, admite e incluso requiere reingreso.

El modelo agórico es fundamentalmente asíncrono, lo que significa que cuando A envía un mensaje a B, no se queda esperando a que B haga algo. Continúa y termina de grabar lo que necesita grabar. Significa que los ejemplos triviales no son tan triviales, pero también significa que los ejemplos no triviales (como DeFi) no están llenos de riesgos de seguridad.

¡Hola Decano Tribble! ¡Es genial tenerte con nosotros! ¿Cuáles diría que son los principales desafíos a la hora de construir una economía en DeFi?

Ah, claro. Gracias por explicar, Dean Tribble. La reentrada puede causar muchos problemas. ¿Hay alguna forma de saber cuando estamos ante un sistema de reentrada?

re alquiler; es parte de la arquitectura del sistema y, por lo tanto, no se puede tapar con diferentes idiomas o bibliotecas auxiliares. Un sistema en el que las llamadas entre contratos o componentes de contrato son devolución de llamada (A llama a B y espera la respuesta) casi siempre son reentrantes. Si mientras A está llamando a B ("oye, tráeme mi reembolso"), alguien más puede llamar a A, entonces es probable que sea un reingreso. Las arquitecturas que no lo son usan mensajería asincrónica (como agoric) o simplemente tienen una semántica limitada (como, por ejemplo, Kadena).

Re desafíos en la construcción de una economía en DeFi

Dean Tribble, ¿qué hay de escalar web3 a través de desarrolladores de JavaScrip? ¿Qué quieres decir con eso? ¿Hay algo en lo que esté trabajando Agoric?

Está en el corazón de lo que estamos trabajando. Mucha gente habla de escalar la velocidad de las transacciones, el tamaño de los bloques o la latencia. Pero lo más difícil de escalar es la base de desarrolladores. Para llegar a una comunidad de desarrolladores significativamente mayor, no podemos esperar que abandonen sus lenguajes y herramientas actuales y trabajen en otro lenguaje de programación. Debemos “encontrarlos donde están”.

Entonces con agórico:

Los detalles son importantes (por ejemplo, JavaScript con ejecución asíncrona y demás), pero también es importante que la prioridad sea habilitar a los desarrolladores que solo quieren hacer algo. Nuestra plataforma debería crecer como lo hicieron JS y Node: ¡desde cero porque permite a los programadores hacer cosas! :)

Mi objetivo es que "si puede crear una aplicación web2 para la nube, puede crear una aplicación web3 para agoric". Es temprano, así que aún no hemos llegado, pero lo estaremos.

Hola Dean Tribble gracias por acompañarnos! Mi pregunta es: ¿por qué código abierto? ¿Qué ventajas y desventajas tiene este modelo y cómo las ventajas superan las desventajas?

Muchas razones para el código abierto.

Motivación personal: He tenido la oportunidad de trabajar en algunos proyectos increíbles. El problema es que algunos de los más increíbles no se enviaron, por lo que esa parte de mi vida pasó un tiempo divertido, interesante, pero en última instancia, mucho menos valioso. Gran parte de lo que estamos haciendo es finalmente construir una versión de código abierto de tecnología realmente útil que hemos construido en múltiples encarnaciones, pero que no hemos podido trasladar fácilmente a nuevos proyectos.

Motivación cultural: JavaScript es en gran medida un mundo de código abierto. Y queremos muchos componentes reutilizables. Históricamente, ese tipo de reutilización prospera mejor en un entorno de código abierto: los desarrolladores saben que otros desarrolladores van a la misma pila tecnológica para los componentes, por lo que ahí es donde construirán y contribuirán con sus componentes.

Y finalmente: el valor principal de blockchain es la alta integridad a través de la descentralización: los contratos inteligentes se ejecutan en múltiples computadoras a cargo de operadores independientes en diferentes jurisdicciones. Si todos ejecutan el mismo software de código cerrado, esencialmente no obtendríamos descentralización. Los implementadores son una única fuente de falla. Y realmente necesita convertirse en código propiedad de la comunidad. Eso solo funciona realmente con código abierto.

¡Eso es un envoltorio! Muchas gracias por estar aquí respondiendo nuestras preguntas, Dean Tribble. ¿Tiene alguna idea final o hay algo que le gustaría promover?

Lanzaremos nuestra "mainnet1" para proporcionar un token estable respaldado por la comunidad para el entorno entre cadenas. ¡Ven a participar con la comunidad en http://agoric.com/discord y regístrate para recibir el boletín y http://agoric.com/newsletter ! Y si eres desarrollador web2, consulta endojs. ¡Gracias por invitarme!

Y, por supuesto, nuestros canales de anuncios Agoric,
Telegram ( https://t.me/agoric_ann ) y Twitter ( https://twitter.com/agoric ).