Explorando JavaScript e contratos inteligentes com o CEO da Agoric, Dean Tribble

Neste AMA, tivemos o prazer de entrevistar Dean Tribble. Dean é o CEO da Agoric e teve uma vasta jornada em tecnologia ao se envolver em vários projetos de software e startups desde os anos 80. Ele tem perseguido uma visão de sistemas de computadores em rede em larga escala e isso o levou a contratos inteligentes.

Este tópico de Slogging de Sara Pinto, Dean Tribble, Dimitar Bochvarovski, Pawan Sharma, Mónica Freitas e Limarc Ambalina ocorreu no canal #amas oficial do slogging e foi editado para facilitar a leitura.

Ei @channel, junte-se a mim para dar as boas-vindas ao nosso próximo convidado do AMA, Dean Tribble, o CEO da http://agoric.com . Agoric é uma empresa de desenvolvimento de código aberto que está lançando uma cadeia e economia Proof-of-Stake interoperável.

Sinta-se à vontade para perguntar a Dean qualquer coisa sobre:

Olá! Obrigado por me receber!

Ei Dean Tribble, é ótimo ter você aqui conosco. Podemos começar com você nos contando um pouco sobre seu passado?

Tive meu primeiro emprego no computador quando tinha 15 anos, minha primeira startup (financiada pelo fundador da Atari, Nolan Bushnell) quando tinha 17. Portanto, trabalho com software e startups desde os anos 80. Muito disso tem sido na construção de sistemas distribuídos em larga escala.

Tenho buscado uma visão de sistemas de computadores em rede em grande escala por literalmente décadas. Trabalhei na Xerox PARC (com alguns de meus colegas aqui na Agoric) nas primeiras linguagens de programação distribuída segura e sistemas operacionais. As promessas modernas em JavaScript e RUST descendem desse trabalho. Então fui trabalhar com hipertexto (antes da web) em Xanadu. Em algum lugar lá em 1989, trabalhei no primeiro contrato inteligente de produção (sim, 5 anos antes de Vitalik nascer 🙂.

Desde então, trabalhei em muitos sistemas de grande escala, desde os primeiros sistemas de informações de corretagem em Java até meu show anterior de um instrumento de pagamento multibilionário. Normalmente, trata-se de trazer novas tecnologias ao mercado para permitir que mais estranhos cooperem com mais sucesso!

Em primeiro lugar, foi isso que me levou aos contratos inteligentes: “o software que impõe os termos de um acordo semelhante a um contrato entre várias partes” permite muito mais cooperação no mundo. Todos os negócios, do eBay e PayPal ao AirBNB e Lyft, são esse tipo de negócio.

Todos eles exigem um intermediário confiável e, como sabemos, nem sempre são confiáveis 🙂. Mas então veio o blockchain que permite que computadores independentes em diferentes jurisdições executem o mesmo software e verifiquem o trabalho uns dos outros e, de repente, você pode administrar negócios de contratos inteligentes sem o intermediário confiável. Foi isso que me levou a construir uma infraestrutura de contrato inteligente para a próxima geração de blockchains. E aqui estamos nós 🙂

Isso me faz perceber que pulei a Sun e a Microsoft lá.

Nos anos 90, no Sun Labs, tínhamos um projeto para construir uma plataforma de contrato inteligente. Essa é uma grande parte do trabalho inicial de design que levou aos elementos da plataforma de contrato inteligente JavaScript da Agoric.

Na Microsoft, fui arquiteto do sistema operacional Midori (pesquisa), um sistema operacional de pesquisa que usa a mesma abordagem de arquitetura baseada em mensagem/ocap/promessa aysnc que agora usamos no Agoric vm/kernel.

Que carreira 🙂

Por que JavaScript? Quer dizer, eu pessoalmente sou um desenvolvedor Web e uso JS no meu dia a dia, e é a linguagem que não troco por mais nada, mas há muita discussão sobre os problemas que vêm com o JS, como tipos dinâmicos e a facilidade de cometer erros com o gerenciamento de memória...

E eu sou um grande fã de Kyle Simpson, para mencionar. Ele tem cursos interessantes para recursos de objeto em js

Eu amo essa pergunta porque tem respostas surpreendentes e não surpreendentes.

A resposta nada surpreendente está no “…é a linguagem que não troco por mais nada…”. 13,9 milhões de desenvolvedores! Quero ver mais cooperação no mundo, e os contratos inteligentes são uma ferramenta incrivelmente poderosa para ajudar isso a acontecer. Para que isso importe, porém, ele deve estar disponível para a maioria dos programadores do mundo. Não é de grande ajuda se, para construir um contrato inteligente, você tiver que rezar para o sacerdócio de 10 mil caros desenvolvedores do Solidity. É mais fácil encontrar um bom advogado e fazê-lo à moda antiga! Então, nos propusemos a encontrar os desenvolvedores onde eles estão e capacitá -los a criar contratos inteligentes.

A resposta surpreendente é que o JavaScript é mais seguro do que a maioria das outras linguagens de programação, devido em grande parte às contribuições de nosso cientista-chefe, Mark Miller. Ele está direcionando os elementos necessários para o JavaScript de nosso trabalho anterior de linguagem segura desde o início. Seu artigo de 2015 sobre criptografia financeira em “Instrumentos financeiros baseados em capacidade” mostrou exemplos na linguagem de programação E que agora você pode escrever em JavaScript no Agoric.

A razão pela qual o JS é mais seguro também é em parte um acidente da história: a linguagem JS foi padronizada no ECMA, enquanto o ambiente de host do navegador foi padronizado no W3C. Isso corresponde a uma separação de modo de usuário/modo de sistema necessária para sistemas operacionais seguros. Você nunca viu um limite de design tão bem defendido quanto os comitês defendem seu território 😄. Portanto, a única maneira de um programa/módulo/qualquer coisa JS obter autoridade para qualquer coisa no sistema é se ele for colocado no objeto global usado para avaliação. No navegador, esse global inclui

 document

tal, enquanto no nó, o global inclui

 fs

e

 process

e similar. Mark e outros mantiveram JS nesse caminho. E com alguns recursos adicionais (por exemplo,

 freeze

) somos capazes de avaliar o código JS (por exemplo, no blockchain ou em servidores) onde a única autoridade que obtém é para serviços específicos que fornecemos Não pode chegar ao sistema de arquivos, rede, etc.

esse é o “JavaScript endurecido”. É de código aberto, disponível para web2 e web3 em https://github.com/endojs/endo e executado em qualquer ambiente JS padrão. É a espinha dorsal da carteira de próxima geração da MetaMask, usada no AppExchange da Salesforce e, claro, usada para nossa plataforma de contrato inteligente.

Dean Tribble, isso é incrível! Você teve uma jornada e tanto. Eu tenho que perguntar, em nome do pessoal não tão experiente em tecnologia, você poderia elaborar contratos inteligentes no blockchain? E o que você quer dizer com composição?

Quanto ao que é um contrato inteligente: “software que impõe os termos de um acordo semelhante a um contrato entre várias partes”. Isso! Portanto, eBay, PayPal, Lyft e StubHub são, em grande parte, negócios de contratos inteligentes implantados por um “intermediário confiável”. Portanto, os contratos inteligentes eram de $ 1T + valor de mercado *antes* do blockchain. Contamos com os intermediários para executar fielmente seu software, e a maioria das transações ocorre sem qualquer envolvimento humano da empresa de hospedagem.

Esses negócios decolaram muito mais rápido, uma vez que havia boas bibliotecas e plataformas para compor rapidamente novos negócios sem codificar tudo do zero (por exemplo, shopify, stripe, etc. todos os componentes fornecidos que os desenvolvedores poderiam reutilizar).

Por que foi tão difícil criar um "código que pode ser executado no blockchain", que é o contrato inteligente em geral (corrija-me se eu estiver errado), e precisávamos esperar que o Ethereum viesse com isso solução?

Mas meu exemplo de modelo de componente favorito está no espaço da interface do usuário (afinal, trabalhei em interfaces do usuário como estagiário no grupo Smalltalk no PARC). Antes do React/vue/etc., os especialistas podiam construir algumas coisas bem legais em JavaScript. MAS é um pesadelo depurar aplicativos sofisticados escritos em HTML/JS bruto (ainda me lembro da minha última tentativa de depurar por que a taxa de imposto de alguma página de compra não estava mudando quando o usuário mudou seu código postal). O React fornece uma estrutura de componentes para componentes de interface do usuário que aborda completamente muitos dos problemas difíceis na construção de UIs sofisticadas e, além disso, permite que os componentes criados por várias partes funcionem muito bem juntos.

O resultado é que logo após o lançamento do React, novos desenvolvedores podem criar aplicativos mais sofisticados, seguros, responsivos e úteis do que os especialistas no ano anterior ao React. Isso é o que uma estrutura de componentes oferece a você.

Nosso objetivo é uma estrutura que forneça o mesmo tipo de suporte, mas para contratos inteligentes que lidam com ativos digitais, preços etc. (em vez de usar cliques e renderização). Em plataformas como a Ethereum, existem riscos de segurança que são francamente de alto risco para especialistas em criptografia, quanto mais para programadores de aplicativos apenas tentando resolver seus problemas de negócios. Nossa estrutura foi projetada para proteger os desenvolvedores desses perigos.

Portanto, um contrato inteligente não é “código que pode ser executado em uma blockchain”, já que havia $ 1T+ de valor em contratos inteligentes antes das blockchains!

O próprio Bitcoin é um contrato inteligente; é um software que impõe regras para transferência de BTC. É o primeiro contrato inteligente que não precisava de um intermediário confiável.

Eth trouxe suporte para rodar o software de outras pessoas. Havia alguns requisitos para isso. O padrão ouro da blockchain é

vários computadores em diferentes jurisdições e diferentes domínios administrativos, todos chegando a um consenso sobre dados, escolhas e computação.

Vou descompactar isso e depois falar sobre por que é importante 🙂.

Ei, Dean Tribble, você poderia explicar um pouco sobre a segurança da oferta na Agoric e ela reembolsa o ativo original mais a taxa de transação ou apenas o ativo original?

vários computadores em diferentes jurisdições e diferentes domínios administrativos, todos chegando a um consenso

Significa que nenhum ser humano, organização ou governo pode alterar unilateralmente o comportamento do sistema. Eles teriam que comprometer simultaneamente a maioria das máquinas (que são controladas por outras partes) para comprometer a integridade da computação.

sobre dados, escolhas e computação.

Dados: “Reitor tem $ 100 em sua conta”
Escolhas: “Dean tentou retirar sua oferta antes do encerramento do leilão. Ele ganhou o leilão e gastou o dinheiro ou conseguiu o dinheiro de volta?”
Cálculo: “o leilão decorreu e determinou que Dean seria o vencedor”

A nova parte técnica difícil é “tudo chegar a um consenso”. Se você conhece todos os computadores (você não conhece) e pode confiar em todos eles para não trapacear (você não pode), então sabemos como contar votos e garantir que seja a maioria. A área de tolerância a falhas bizantinas abrange o tratamento do “e se eles trapacearem”. O insight mais brilhante no BitCoin foi como abordar o consenso quando você não conhece todos os computadores participantes.

Finalmente, para que todos os computadores verifiquem se concordam, eles precisam realmente concordar! Portanto, o mesmo programa executado com os mesmos argumentos várias vezes em vários lugares deve produzir as mesmas respostas (isso é chamado de “determinístico”). Isso acaba sendo difícil! Se eles podem ver o relógio, eles podem se comportar de maneira diferente. Se eles puderem ver qualquer endereço de memória, eles podem se comportar de maneira diferente. Se eles puderem ver quando a coleta de lixo acontece,… você entendeu.

Portanto, o Solidity tem muitos problemas e é de nível muito baixo, mas é executado de forma determinística. Nosso JavaScript reforçado permite que você execute JavaScript de forma determinista! Isso tornará tudo isso acessível a muito mais desenvolvedores

Pawan Sharma pergunta sobre “oferecer segurança” em Agoric. Essa é uma das propriedades críticas da estrutura de contrato inteligente. Propriedades de segurança familiares são coisas como segurança de memória e segurança de tipo, onde elas eliminam completamente uma grande classe de bugs. Eles não resolvem tudo, mas podem tirar 80% dos bugs da mesa.

Oferecer segurança é uma propriedade de segurança no nível econômico.

Primeiro, a configuração: nos sistemas de contrato inteligente de blockchains existentes, você executa transações enviando dinheiro para um “número aleatório” (um endereço de conta) e esperando que algo bom aconteça. As pessoas enviaram (e perderam) ativos para “endereços” que não eram contas reais, que eram contas erradas, para contratos que falharam etc. Esse modelo é propenso a erros e uma interação horrível do usuário. Quero enviar dinheiro para meu amigo John, não para 0x234ag3453.

O negócio real envolve quid pro quo: “Eu te darei $ X se você me der o ingresso do show Y”. Apoiamos isso diretamente. Portanto, em nossa API, os clientes invocam contratos inteligentes fazendo

 offer

s. Cada oferta diz o que eles

 want

, o que eles vão

 give

para, e em que circunstâncias eles podem

 exit

com seus bens. Os pagamentos nessa oferta vão para a própria estrutura e NÃO para o contrato inteligente. A única maneira de o contrato inteligente obter os ativos é fornecer os ativos que a oferta deseja.

Então, como é a segurança da oferta para um leilão?

Zoe detém todos os ativos e notificou o contrato de cada oferta. Quando o leilão fecha, o contrato do leilão atomicamente

 reallocates

o ingresso do show para o licitante vencedor e o dinheiro do licitante vencedor para o vendedor. Essa realocação só terá sucesso se o lance vencedor for suficiente para o vendedor e se o ingresso do show for de fato o que o licitante apostou.

Nenhum mau comportamento, bug, etc. por parte do contrato de leilão pode permitir que ele receba dinheiro dos licitantes que não estão recebendo o ingresso do show.

Isso significa que os clientes do leilão estão MUITO mais seguros. Eles não precisam ler o código do leilão para saber que receberão o ingresso desejado ou o dinheiro de volta.

Além disso, o criador do contrato de leilão também está feliz: muitos dos perigos em Solidity estão relacionados ao manuseio de dinheiro que você não deveria segurar. Houve literalmente $ 1 bilhão + perdidos / roubados devido ao manuseio desleixado da devolução de dinheiro de contratos. Com Zoe e oferece segurança, você não precisa escrever uma única linha de código no contrato para lidar com isso com segurança.

Uma propriedade relacionada é “vivacidade de pagamento”: lembre-se de que cada off tem um

 exit

como parte de seus termos. O padrão para isso (que você convenientemente não precisa especificar) é “sempre que eu quiser; é o meu dinheiro caramba!“. Bem, é chamado de “OnDemand” 🙂 Isso significa apenas que você pode sair quando quiser e, novamente, nenhum bug ou comportamento malicioso por parte do contrato pode atrasar a saída da oferta e a recuperação de seus ativos. Observe, no entanto, que “seus ativos” podem estar após algumas realocações já terem ocorrido. Se sua oferta foi “comprarei até N ingressos para X moola”, então ele já pode ter realocado alguns desses N para você e recebido dinheiro por eles, de acordo com o

 want

que você especificou. Mas uma vez que seu sinal de saída chega, Zoe puxa seus ativos e os devolve a você sem que o contrato interfira. Da mesma forma, se o contrato falhar, travar, etc. Zoe sairá de sua oferta. É impressionante quanto dinheiro é involuntariamente “bloqueado” em contratos em que os usuários não têm como reaver seu dinheiro!

Dean Tribble, muito obrigado por sua resposta detalhada! E as vulnerabilidades dos contratos inteligentes? Como podem ser reduzidos?

Dean Tribble Ótima explicação!!

Para formas de reduzir vulnerabilidades de contratos inteligentes, discutimos

Formas críticas adicionais:

Na Ethereum e em outras cadeias (mais recentemente na PolyNetwork), bilhões em perdas vieram da “reentrada”. É aí que, se houver 2 componentes (ou contratos), A planeja chamar B e então fazer algo X, mas B chama de volta para a (reentra em A) antes que possa chegar a X. Por exemplo, A é um leilão, um B solicita um reembolso do lance. B diz "me envie meu reembolso", e então A procura, e envia o reembolso para B, e então registra que deu um reembolso para B. MAS quando B recebe o reembolso, em vez de responder "obrigado", ele envia imediatamente a mensagem “envie-me um reembolso” para A novamente. Como A ainda não registrou que B recebeu seu reembolso, ele segue em frente e envia o reembolso novamente . E, novamente, B reage a isso com “me envie um reembolso”. O serviço A nunca chega ao ponto de registrar que B recebeu seu reembolso, então B apenas faz isso até esgotar a conta de A. Parece absurdo quando dito assim, mas esse foi exatamente o bug em 2017 que fez as pessoas se perguntarem se a tecnologia por trás da Agoric poderia ajudar o blockchain. E uma exploração de $ 660 milhões no ano passado foi o mesmo problema básico. É porque a arquitetura do Eth permite, suporta e até requer reentrância.

O modelo agórico é fundamentalmente assíncrono, o que significa que quando A envia uma mensagem para B, ele não fica esperando que B faça algo. Ele segue em frente e termina de gravar o que precisa gravar. Isso significa que exemplos triviais não são tão triviais, mas também significa que exemplos não triviais (como DeFi) não estão repletos de riscos à segurança.

Olá Dean Tribble! Ótimo ter você conosco! Quais você diria que são os principais desafios quando se trata de construir uma economia em DeFi?

Oh, eu vejo. Obrigado por explicar, Reitor Tribble. A reentrada pode causar muitos problemas. Existe alguma maneira de saber quando estamos lidando com um sistema de reentrância?

relocação; faz parte da arquitetura do sistema e, portanto, não pode ser ocultado por diferentes linguagens ou bibliotecas auxiliares. Um sistema no qual as chamadas entre contratos ou componentes do contrato são chamadas de retorno (A chama B e aguarda a resposta) são quase sempre reentrantes. Se enquanto A está ligando para B (“ei, pegue meu reembolso”), outra pessoa pode ligar para A, provavelmente é reentrante. As arquiteturas que não usam mensagens assíncronas (como agoric) ou apenas têm semântica limitada (como, por exemplo, Kadena).

re desafios na construção de uma economia em DeFi

Dean Tribble, que tal escalar o web3 por meio de desenvolvedores JavaScrip? O que você quer dizer com isso? Agoric está trabalhando em algo?

É o cerne do que estamos trabalhando. Muitas pessoas falam sobre escalar a velocidade da transação, o tamanho do bloco ou a latência. Mas a coisa mais difícil de escalar é a base de desenvolvedores. Para alcançar uma comunidade significativamente maior de desenvolvedores, não podemos esperar que eles abandonem suas linguagens e ferramentas atuais e trabalhem em outra linguagem de programação. Devemos “encontrá-los onde eles estão”.

Assim com agórico:

Os detalhes são importantes (por exemplo, JavaScript com execução assíncrona e outros), mas também é importante que a prioridade seja capacitar os desenvolvedores que desejam apenas fazer algo. Nossa plataforma deve crescer como JS e Node: desde o início, porque permite que os programadores façam as coisas! :)

Meu objetivo é que “se você pode construir um aplicativo web2 para a nuvem, você pode construir um aplicativo web3 para agoric”. É cedo, então ainda não chegamos lá, mas chegaremos.

Olá, Dean Tribble, obrigado por se juntar a nós! Minha pergunta é: por que código aberto? Quais são os benefícios e contras desse modelo e como os prós superam os contras?

Muitas razões para o código aberto.

Motivação pessoal: Tive a oportunidade de trabalhar em alguns projetos incríveis. O problema é que alguns dos mais incríveis não foram lançados e, portanto, essa parte da minha vida foi divertida, interessante, mas, no final das contas, muito menos tempo valioso gasto. Muito do que estamos fazendo é finalmente construir uma versão de código aberto de tecnologia realmente útil que construímos em várias encarnações, mas não conseguimos levar adiante facilmente em novos projetos.

Motivação cultural: JavaScript é um mundo amplamente de código aberto. E queremos muitos componentes reutilizáveis. Historicamente, esse tipo de reutilização floresce melhor em um ambiente de código aberto: os desenvolvedores sabem que outros desenvolvedores estão indo para a mesma pilha de tecnologia para componentes, então é onde eles irão construir e contribuir com seus componentes.

E, finalmente: o valor principal do blockchain é a alta integridade por meio da descentralização: os contratos inteligentes são executados em vários computadores administrados por operadores independentes em diferentes jurisdições. Se todos eles estiverem executando o mesmo software de código fechado, não obteríamos essencialmente nenhuma descentralização. Os implementadores são uma única fonte de falha. E realmente precisa crescer em código de propriedade da comunidade. Isso realmente só funciona com código aberto.

Isso é um embrulho! Muito obrigado por estar aqui respondendo nossas perguntas, Reitor Tribble. Você tem alguma ideia final ou há algo que gostaria de promover?

Estaremos lançando nossa “mainnet1” para fornecer um token estável apoiado pela comunidade para o ambiente interchain. Venha participar com a comunidade em http://agoric.com/discord e inscreva-se na newsletter e http://agoric.com/newsletter ! E se você for um desenvolvedor web2, confira endojs. Obrigado por me receber!

E, claro, nossos canais de anúncios Agoric,
Telegram ( https://t.me/agoric_ann ) e Twitter ( https://twitter.com/agoric ).