Explorer JavaScript et les contrats intelligents avec Dean Tribble, PDG d'Agoric

Dans cette AMA, nous avons eu le plaisir d'interviewer Dean Tribble. Dean est le PDG d'Agoric, et a eu un vaste parcours dans la technologie en étant impliqué dans divers projets logiciels et startups depuis les années 80. Il poursuit une vision des systèmes informatiques en réseau à grande échelle, ce qui l'a conduit aux contrats intelligents.

Ce fil de discussion de Sara Pinto, Dean Tribble, Dimitar Bochvarovski, Pawan Sharma, Mónica Freitas et Limarc Ambalina s'est produit sur la chaîne officielle #amas de slogging et a été modifié pour plus de lisibilité.

Hey @channel, veuillez vous joindre à moi pour souhaiter la bienvenue à notre prochain invité AMA, Dean Tribble, le PDG de http://agoric.com . Agoric est une société de développement open source qui lance une chaîne et une économie interopérables de preuve de participation.

N'hésitez pas à demander à Dean quoi que ce soit sur :

Bonjour! Merci de me recevoir!

Salut Dean Tribble, c'est super de t'avoir avec nous. Pouvons-nous commencer par vous parler un peu de votre parcours ?

J'ai eu mon premier job en informatique quand j'avais 15 ans, ma première startup (financée par le fondateur d'Atari, Nolan Bushnell) quand j'avais 17 ans. Je fais donc du logiciel et des startups depuis les années 80. Une grande partie a été consacrée à la construction de systèmes distribués à grande échelle.

Je poursuis une vision des systèmes informatiques en réseau à grande échelle depuis des décennies. J'ai travaillé chez Xerox PARC (avec quelques-uns de mes collègues ici chez Agoric) sur les premiers langages de programmation distribués sécurisés et les systèmes d'exploitation. Les promesses modernes en JavaScript et RUST découlent de ce travail. Je suis ensuite allé travailler sur l'hypertexte (avant le web) chez Xanadu. Quelque part là-dedans en 1989, j'ai travaillé sur le premier contrat intelligent de production (oui, 5 ans avant la naissance de Vitalik 🙂.

Depuis lors, j'ai travaillé sur de nombreux systèmes à grande échelle, des premiers systèmes d'information de courtage en Java à mon précédent concert d'un instrument de paiement de plusieurs milliards de dollars. Il s'agit généralement d'apporter de nouvelles technologies sur le marché pour permettre à un étranger de coopérer avec plus de succès !

C'est ce qui m'a amené aux contrats intelligents en premier lieu : "un logiciel appliquant les termes d'un accord de type contrat entre plusieurs parties" permet simplement beaucoup plus de coopération dans le monde. Toutes les entreprises d'eBay et PayPal à AirBNB et Lyft sont ce genre d'entreprise.

Ceux-ci nécessitent tous un intermédiaire de confiance, et comme nous le savons, ils ne sont pas toujours dignes de confiance 🙂. Mais ensuite est arrivée la blockchain qui permet à des ordinateurs indépendants dans différentes juridictions d'exécuter le même logiciel et de vérifier le travail de chacun, et tout à coup, vous pouvez gérer des entreprises de contrats intelligents sans l'intermédiaire de confiance. C'est ce qui m'a poussé à créer une infrastructure de contrat intelligente pour la prochaine génération de blockchains. Et nous y sommes 🙂

Cela me fait réaliser que j'ai sauté Sun et Microsoft là-dedans.

Chez Sun Labs dans les années 90, nous avions un projet de construction d'une plateforme de contrats intelligents. C'est une grande partie du travail de conception initial qui a conduit aux éléments de la plate-forme de contrats intelligents JavaScript d'Agoric.

Chez Microsoft, j'étais architecte sur le système d'exploitation Midori (recherche), un système d'exploitation de recherche utilisant la même approche d'architecture basée sur les messages aysnc/ocap/promesse que nous utilisons maintenant dans la vm/kernel d'Agoric.

Quelle carrière 🙂

Pourquoi Javascript ? Je veux dire, moi personnellement, je suis un développeur Web et j'utilise JS dans ma vie de tous les jours, et c'est le langage que je ne changerai pas pour autre chose, mais il y a beaucoup de discussions sur les problèmes qui viennent avec JS, comme types dynamiques, et la facilité de faire des erreurs avec la gestion de la mémoire...

Et je suis un grand fan de Kyle Simpson, pour le mentionner. Il a des cours intéressants sur les capacités d'objet en js

J'aime cette question parce qu'elle a des réponses à la fois surprenantes et surprenantes.

La réponse sans surprise est dans le « … est la langue que je ne changerai pour rien d'autre… ». 13,9 millions de développeurs ! Je veux voir plus de coopération dans le monde, et les contrats intelligents sont un outil incroyablement puissant pour y parvenir. Pour que cela soit important, il doit être disponible pour la plupart des programmeurs dans le monde. Ce n'est pas d'une grande aide si, pour obtenir un contrat intelligent, vous devez aller prier le sacerdoce de 10 000 développeurs Solidity coûteux. Il est plus facile de trouver un bon avocat et de le faire à l'ancienne ! Nous avons donc décidé de rencontrer les développeurs là où ils se trouvaient et de leur donner les moyens de créer des contrats intelligents.

La réponse surprenante est que JavaScript est plus sécurisable que la plupart des autres langages de programmation, en grande partie grâce aux contributions de notre scientifique en chef, Mark Miller. Depuis le début, il pilote les éléments nécessaires dans JavaScript à partir de notre travail antérieur sur le langage sécurisé. Son article de 2015 à la cryptographie financière sur les « instruments financiers basés sur les capacités » a montré des exemples dans le langage de programmation E que vous pouvez maintenant écrire en JavaScript sur Agoric.

La raison pour laquelle JS est plus sécurisable est aussi en partie un accident de l'histoire : le langage JS a été standardisé dans ECMA, alors que l'environnement d'hébergement du navigateur pour celui-ci a été standardisé dans W3C. Cela correspond à une séparation mode utilisateur/mode système requise pour les systèmes d'exploitation sécurisés. Vous n'avez jamais vu une frontière du design aussi bien défendue que les comités défendent leur territoire 😄. Ainsi, la seule façon pour un programme/module/quelque chose d'JS d'obtenir l'autorité sur quoi que ce soit dans le système est de le mettre dans l'objet global utilisé pour l'évaluation. Dans le navigateur, ce global inclut

 document

tel, alors que dans node, le global inclut

 fs

et

 process

etc. Mark et d'autres ont gardé JS sur cette voie. Et avec quelques fonctionnalités supplémentaires (par exemple,

 freeze

) nous sommes en mesure d'évaluer le code JS (par exemple, sur la blockchain ou dans les serveurs) où la seule autorité qu'il obtient est sur les services spécifiques que nous lui fournissons Il ne peut pas accéder au système de fichiers, au réseau, etc.

c'est le "JavaScript renforcé". Il est open-source, disponible pour web2 et web3 sur https://github.com/endojs/endo , et s'exécute dans n'importe quel environnement JS standard. C'est l'épine dorsale du portefeuille nouvelle génération de MetaMask, utilisé dans AppExchange de Salesforce, et bien sûr utilisé pour notre plate-forme de contrat intelligente.

Dean Tribble, c'est incroyable ! Vous avez fait tout un voyage. Je dois demander, au nom des gens pas si férus de technologie, pourriez-vous élaborer sur les contrats intelligents sur la blockchain ? Et qu'entendez-vous par composabilité ?

Quant à ce qu'est un contrat intelligent : "un logiciel appliquant les termes d'un accord de type contractuel entre plusieurs parties". Ça ! Par conséquent, eBay, PayPal, Lyft et StubHub sont tous en grande partie des contrats intelligents déployés par un "intermédiaire de confiance". Les contrats intelligents représentaient donc une capitalisation boursière de 1 000 000 $ + * avant * la blockchain. Nous comptons sur les intermédiaires pour exécuter fidèlement leur logiciel, et la plupart des transactions se déroulent sans aucune intervention humaine de la société d'hébergement.

Ces entreprises ont décollé beaucoup plus rapidement une fois qu'il y avait de bonnes bibliothèques et plates-formes pour composer rapidement de nouvelles entreprises sans tout coder à partir de zéro (par exemple, shopify, stripe, etc., tous fournissaient des composants que les développeurs pouvaient réutiliser).

Pourquoi était-il si difficile de trouver un "code qui peut être exécuté sur la blockchain", ce qu'est le contrat intelligent en général (corrigez-moi si je me trompe), et nous devions attendre qu'Ethereum vienne avec ça la solution?

Mais mon exemple de modèle de composant préféré est dans l'espace UI (j'ai travaillé sur les UI en tant que stagiaire dans le groupe Smalltalk au PARC après tout). Avant React/vue/etc., les experts pouvaient créer des trucs plutôt sympas en JavaScript. MAIS c'est un cauchemar de déboguer des applications fantaisistes écrites en HTML/JS brut (je me souviens encore de ma dernière série d'essais pour déboguer pourquoi le taux de taxe de certaines pages d'achat ne changeait pas lorsque l'utilisateur changeait son code postal). React fournit un cadre de composants pour les composants d'interface utilisateur qui résout complètement de nombreux problèmes difficiles liés à la création d'interfaces utilisateur sophistiquées, et plus encore, permet aux composants créés par plusieurs parties de fonctionner extrêmement bien ensemble.

Le résultat est que peu de temps après la sortie de React, les nouveaux développeurs peuvent créer des applications plus sophistiquées, plus sûres, plus réactives et plus utiles que les experts ne le pouvaient l'année précédant React. C'est ce que vous apporte un framework de composants.

Notre objectif est un cadre qui fournit le même type de support, mais pour les contrats intelligents qui gèrent les actifs numériques, la tarification, etc. (au lieu d'utiliser les clics et le rendu). Dans des plates-formes comme Ethereum, il existe des risques de sécurité qui sont franchement trop risqués pour les cryptoexperts, sans parler des programmeurs d'applications qui essaient simplement de résoudre leur problème commercial. Notre cadre est conçu pour protéger les développeurs de ces dangers.

Ainsi, un contrat intelligent n'est pas un « code pouvant être exécuté sur une blockchain », car il y avait plus de 1 000 000 $ de valeur dans les contrats intelligents avant les blockchains !

Bitcoin est lui-même un contrat intelligent ; c'est un logiciel qui applique les règles de transfert de BTC. C'est le premier contrat intelligent qui n'a pas eu besoin d'un intermédiaire de confiance.

Eth a apporté un support pour l'exécution de logiciels d'autres personnes. Il y avait quelques exigences pour cela. L'étalon-or de la blockchain est

plusieurs ordinateurs dans différentes juridictions et différents domaines administratifs parvenant tous à un consensus sur les données, les choix et le calcul.

Je vais déballer ça, puis parler de pourquoi c'est important 🙂.

Hey Dean Tribble Pourriez-vous s'il vous plaît expliquer un peu la sécurité de l'offre dans Agoric et rembourse-t-elle l'actif d'origine plus les frais de transaction ou seulement l'actif d'origine ?

plusieurs ordinateurs dans différentes juridictions et différents domaines administratifs parvenant tous à un consensus

Cela signifie qu'aucun humain, organisation ou gouvernement ne peut modifier unilatéralement le comportement des systèmes. Ils devraient simultanément compromettre une majorité de machines (qui sont contrôlées par d'autres parties) pour compromettre l'intégrité du calcul.

sur les données, les choix et le calcul.

Données : "Dean a 100 $ sur son compte"
Choix : « Dean a tenté de retirer son offre avant la clôture des enchères. A-t-il remporté l'enchère et dépensé son argent ou a-t-il récupéré son argent ? »
Calcul : "l'enchère s'est déroulée et a déterminé que Dean serait le gagnant"

La nouvelle partie technique dure est « toutes parvenues à un consensus ». Si vous connaissez tous les ordinateurs (vous ne les connaissez pas) et que vous pouvez compter sur eux pour ne pas tricher (vous ne pouvez pas), alors nous savons comment compter les votes et nous assurer qu'il s'agit d'une majorité. Le domaine de la tolérance aux pannes byzantines couvre la gestion du "et s'ils trichent". L'idée la plus brillante de BitCoin était de savoir comment aborder le consensus lorsque vous ne connaissez pas tous les ordinateurs participants.

Enfin, pour que ces ordinateurs vérifient tous qu'ils sont d'accord, il faut qu'ils soient d'accord ! Ainsi, le même programme exécuté avec les mêmes arguments plusieurs fois à plusieurs endroits doit produire les mêmes réponses (c'est ce qu'on appelle «déterministe»). Cela s'avère difficile ! S'ils peuvent voir l'horloge, ils peuvent se comporter différemment. S'ils peuvent voir n'importe quelle adresse mémoire, ils peuvent se comporter différemment. S'ils peuvent voir quand la collecte des ordures a lieu,… vous voyez l'idée.

Solidity a donc beaucoup de problèmes et est de très bas niveau, mais il s'exécute de manière déterministe. Notre JavaScript renforcé vous permet d'exécuter JavaScript de manière déterministe ! Cela rendra tout cela accessible à beaucoup plus de développeurs

Pawan Sharma s'interroge sur « la sécurité de l'offre » dans Agoric. C'est l'une des propriétés essentielles du cadre de contrat intelligent. Les propriétés de sécurité familières sont des choses comme la sécurité de la mémoire et la sécurité des types, où elles éliminent complètement une grande classe de bogues. Ils ne résolvent pas tout, mais ils peuvent éliminer 80 % des bogues.

La sécurité de l'offre est une propriété de sécurité au niveau économique.

Tout d'abord, le paramètre : dans les systèmes de contrats intelligents blockchains existants, vous exécutez des transactions en envoyant de l'argent à un "numéro aléatoire" (une adresse de compte) et en espérant que quelque chose de bien se produise. Les gens ont envoyé (et perdu) des actifs à des "adresses" qui n'étaient pas de vrais comptes, qui étaient de mauvais comptes, à des contrats qui ont ensuite échoué, etc. Ce modèle est à la fois sujet aux erreurs et à une interaction utilisateur horrible. Je veux envoyer de l'argent à mon ami John, pas à 0x234ag3453.

Le vrai business, c'est quid pro quo : « Je te donnerai X $ si tu me donnes le ticket de concert Y ». Nous soutenons cela directement. Ainsi, dans notre API, les clients invoquent des contrats intelligents en faisant

 offer

s. Chaque offre dit ce qu'elle

 want

, ce qu'ils feront

 give

pour, et dans quelles circonstances ils peuvent

 exit

avec leurs atouts. Les paiements de cette offre vont ensuite dans le cadre lui-même et NON dans le contrat intelligent. La seule façon pour le contrat intelligent d'obtenir les actifs est de fournir les actifs souhaités par l'offre.

Alors, à quoi ressemble la sécurité de l'offre pour une vente aux enchères ?

Zoe détient tous les actifs, et notifie le contrat de chaque offre. Lorsque l'enchère se termine, le contrat d'enchère atomiquement

 reallocates

le billet de concert à l'adjudicataire et l'argent de l'adjudicataire au vendeur. Cette réattribution ne réussira que si l'enchère gagnante est suffisante pour le vendeur et si le billet de concert correspond bien à l'enchère de l'enchérisseur.

Aucune mauvaise conduite, bug, etc. de la part du contrat d'enchères ne peut lui permettre de prélever de l'argent sur les enchérisseurs qui n'obtiennent pas le billet de concert.

Cela signifie que les clients de l'enchère sont BEAUCOUP plus sûrs. Ils n'ont pas besoin de lire le code de l'enchère pour savoir qu'ils obtiennent le billet souhaité ou qu'ils sont remboursés.

De plus, le créateur du contrat d'enchères est également heureux : de nombreux dangers dans Solidity concernent la manipulation d'argent que vous n'êtes pas censé conserver. Il y a eu littéralement plus de 1 milliard de dollars perdus / volés en raison d'une gestion bâclée du retour de l'argent des contrats. Avec Zoe et offrez la sécurité, vous n'avez pas besoin d'écrire une seule ligne de code dans le contrat pour gérer cela en toute sécurité.

Une propriété connexe est la "vivacité de paiement": rappelez-vous que chaque off a un

 exit

dans le cadre de ses termes. La valeur par défaut pour cela (que vous n'avez pas besoin de spécifier) est "quand je veux ; c'est mon argent bon sang!“. Eh bien OK, ça s'appelle "OnDemand" 🙂 Cela signifie simplement que vous pouvez sortir quand vous voulez, et encore une fois, aucun bug ou comportement malveillant de la part du contrat ne peut vous retarder à quitter l'offre et à récupérer vos actifs. Notez cependant que « vos actifs » peuvent être après que certaines réaffectations ont déjà eu lieu. Si votre offre était "J'achèterai jusqu'à N billets pour X moola", alors il se peut qu'il vous ait déjà réaffecté certains de ces N et pris de l'argent pour ceux-ci, conformément au

 want

que vous avez spécifié. Mais une fois que votre signal de sortie arrive, Zoe retire vos actifs et vous les rend sans que le contrat n'intervienne. De même, si le contrat se bloque, se bloque, etc., Zoe quittera votre offre. Il est étonnant de voir combien d'argent est involontairement « enfermé » dans des contrats où les utilisateurs n'ont aucun moyen de récupérer leur argent !

Dean Tribble, merci beaucoup pour votre réponse détaillée! Qu'en est-il des vulnérabilités des contrats intelligents ? Comment peut-on les réduire ?

Dean Tribble Excellente explication !!

Pour les moyens de réduire les vulnérabilités des contrats intelligents, nous avons discuté

Manières critiques supplémentaires :

Dans Ethereum et d'autres chaînes (plus récemment PolyNetwork), des milliards de pertes sont dues à la « réentrée ». C'est là que s'il y a 2 composants (ou contrats) A prévoit d'appeler B puis de faire quelque chose X, mais B rappelle dans a (réintègre A) avant de pouvoir atteindre X. Par exemple, A est une enchère, un B demande un remboursement de l'enchère. B dit "envoyez-moi mon remboursement", et donc A le recherche et envoie le remboursement à B, puis enregistre qu'il a remboursé B. MAIS lorsque B reçoit le remboursement, au lieu de répondre "merci", il envoie immédiatement à nouveau le message « Envoyez-moi un remboursement » à A. Comme A n'a pas encore enregistré que B a reçu son remboursement, il continue et envoie à nouveau le remboursement . Et encore une fois, B réagit à cela avec "envoyez-moi un remboursement". Le service A n'arrive jamais au point d'enregistrer que B a reçu son remboursement, donc B le fait jusqu'à ce qu'il ait vidé le compte de A. Cela semble absurde quand dit comme ça, mais c'était exactement le bogue de 2017 qui a amené les gens à se demander si la technologie derrière Agoric pouvait aider la blockchain. Et un exploit de 660 millions de dollars l'année dernière était le même problème de base. C'est parce que l'architecture d'Eth permet, prend en charge et même exige la réentrance.

Le modèle Agoric est fondamentalement asynchrone, ce qui signifie que lorsque A envoie un message à B, il ne reste pas là à attendre que B fasse quelque chose. Il continue et finit d'enregistrer ce qu'il doit enregistrer. Cela signifie que les exemples triviaux ne sont pas aussi triviaux, mais cela signifie également que les exemples non triviaux (comme DeFi) ne présentent pas de risques pour la sécurité.

Salut Dean Tribble ! Quel plaisir de vous avoir avec nous! Selon vous, quels sont les principaux défis lorsqu'il s'agit de construire une économie en DeFi ?

Oh je vois. Merci pour l'explication, Dean Tribble. La réentrance peut causer beaucoup de problèmes. Existe-t-il un moyen de savoir quand on a affaire à un système de réentrance ?

re location; cela fait partie de l'architecture du système et ne peut donc pas être dissimulé avec différents langages ou bibliothèques d'assistance. Un système dans lequel les appels entre contrats ou composants de contrat sont à retour d'appel (A appelle B et attend la réponse) sont presque toujours réentrants. Si pendant que A appelle B ("hé, obtenez-moi mon remboursement"), quelqu'un d'autre peut appeler A, alors il est probablement réentrant. Les architectures qui n'utilisent pas la messagerie asynchrone (comme agoric) ou ont juste une sémantique limitée (comme par exemple Kadena).

re défis dans la construction d'une économie dans DeFi

Dean Tribble, qu'en est-il de la mise à l'échelle de Web3 via les développeurs JavaScrip ? Que veux-tu dire par là? Est-ce qu'Agoric travaille sur quelque chose ?

C'est au cœur de ce sur quoi nous travaillons. Beaucoup de gens parlent de la mise à l'échelle de la vitesse des transactions, de la taille des blocs ou de la latence. Mais la chose la plus difficile à faire évoluer est la base de développeurs. Pour atteindre une communauté de développeurs beaucoup plus large, nous ne pouvons pas nous attendre à ce qu'ils abandonnent leurs langages et outils actuels et travaillent sur un autre langage de programmation. Nous devons « les rencontrer là où ils sont ».

Donc avec agorique :

Les détails sont importants (par exemple, JavaScript avec exécution asynchrone, etc.), mais il est également important que la priorité soit de permettre aux développeurs qui veulent simplement faire quelque chose. Notre plate-forme devrait se développer comme JS et Node l'ont fait : à partir de zéro, car elle permet aux programmeurs de faire avancer les choses ! :)

Mon objectif est que "si vous pouvez créer une application web2 pour le cloud, vous pouvez créer une application web3 pour agoric". Il est tôt, donc nous n'en sommes pas encore là, mais nous le serons.

Salut Dean Tribble, merci de nous rejoindre ! Ma question est : pourquoi l'open source ? Quels sont les avantages et les inconvénients de ce modèle et comment les avantages l'emportent-ils sur les inconvénients ?

Beaucoup de raisons pour l'open source.

Motivation personnelle : J'ai eu l'opportunité de travailler sur des projets incroyables. Le problème est que certains des plus incroyables n'ont pas été expédiés, et donc cette partie de ma vie a passé du temps amusant, intéressant, mais finalement beaucoup moins précieux. Une grande partie de ce que nous faisons consiste enfin à créer une version open source d'une technologie vraiment utile que nous avons construite en plusieurs incarnations, mais que nous n'avons pas pu facilement transposer dans de nouveaux projets.

Motivation culturelle : JavaScript est un monde largement open source. Et nous voulons beaucoup de composants réutilisables. Historiquement, ce type de réutilisation s'épanouit mieux dans un environnement open source : les développeurs savent que d'autres développeurs utilisent la même pile technologique pour les composants, c'est donc là qu'ils construiront et apporteront leurs composants.

Et enfin : la valeur fondamentale de la blockchain est une haute intégrité via la décentralisation : les contrats intelligents sont exécutés sur plusieurs ordinateurs gérés par des opérateurs indépendants dans différentes juridictions. S'ils exécutent tous le même logiciel à source fermée, nous n'obtiendrons pratiquement aucune décentralisation. Les implémenteurs sont une source unique d'échec. Et vraiment, il doit devenir un code appartenant à la communauté. Cela ne fonctionne vraiment qu'avec l'open-source.

C'est un enveloppement ! Merci beaucoup d'être ici pour répondre à nos questions, Dean Tribble. Avez-vous une dernière réflexion ou y a-t-il quelque chose que vous aimeriez promouvoir ?

Nous lancerons notre "mainnet1" pour fournir un jeton stable soutenu par la communauté pour l'environnement interchaîne. Venez participer avec la communauté sur http://agoric.com/discord et inscrivez-vous à la newsletter et http://agoric.com/newsletter ! Et si vous êtes développeur web2, consultez endojs. Merci de m'avoir!

Et bien sûr nos chaînes d'annonce Agoric,
Télégramme ( https://t.me/agoric_ann ) et Twitter ( https://twitter.com/agoric ).