Exploring JavaScript and Smart Contracts with Agoric CEO Dean Tribble

In this AMA, we had the pleasure of interviewing Dean Tribble. Dean is the CEO of Agoric, and had a vast journey in tech by being involved in various software projects and startups since the 80s. He has been pursuing a vision of large-scale networked computer systems and that led him to smart contracts.

This Slogging thread by Sara Pinto, Dean Tribble, Dimitar Bochvarovski, Pawan Sharma, Mónica Freitas and Limarc Ambalina occurred in slogging's official #amas channel, and has been edited for readability.

Hey @channel, please join me in welcoming our next AMA guest, Dean Tribble, the CEO of http://agoric.com. Agoric is an open-source development company launching an interoperable Proof-of-Stake chain and economy.

Please feel free to ask Dean anything about:

Hello! Thank you for having me!

Hey Dean Tribble, it's great to have you here with us. Can we start off with you telling us a bit about your background?

I had my first computer job when I was 15, my first startup (funded by the founder of Atari, Nolan Bushnell) when I was 17. So I’ve been doing software and startups since the 80s. Much of it has been in building large scale distributed systems.

I have been pursuing a vision of large scale networked computer systems for literally decades. I worked at Xerox PARC (with a few of my colleagues here at Agoric) on early secure distributed programming languages and operating systems. Modern-day promises in JavaScript and RUST descend from that work. I then went and worked on hypertext (before the web) at Xanadu. Somewhere in there in 1989 I worked on the first production smart contract (yes, 5 years before Vitalik was born 🙂.

Since then I’ve worked on lots of large scale systems from early brokerage information systems in Java to my previous gig of a multibillion dollar payment instrument. Usually it’s about bringing new tech to market to enable mo stranger to cooperate more successfully!

That is what got me into smart contracts in the first place: “software enforcing the terms of a contract-like arrangement between multiple parties” just enables so much more cooperation in the world. All the businesses from eBay and PayPal to AirBNB and Lyft are that kind of business.

Those all require a trusted intermediary, and as we know they aren’t always trustworthy 🙂. But then along came blockchain that enables independent computers in different jurisdictions to run the same software and verify each others work, and suddenly you can run smart contract businesses without the trusted intermediary. That’s what got me into building smart contract infrastructure for next generation of blockchains. And here we are 🙂

That makes me realize I skipped Sun and Microsoft in there.

At Sun Labs in the 90s, we had a project to build a smart contract platform. That’s a big part of the early design work that led to elements of Agoric’s JavaScript smart contract platform.

At Microsoft, I was an architect on the Midori (research) operating system, a research operating system using the same aysnc message/ocap/promise based architecture approach that we now use in the Agoric vm/kernel.

What a career 🙂

Why JavaScript? I mean, me personally am a Web Developer and use JS in my day to day life, and is the language that I won't change for anything else, but there is a lot of discussion about the issues that come with JS, such as dynamic types, and the ease of making mistakes with memory management...

And I am a big fan of Kyle Simpson, to mention. He has interesting courses for object capabilities in js

I love that question because it has both unsurprising and surprising answers.

The unsurprising answer is in the “…is the language that I won’t change for anything else…“. 13.9M developers! I want to see more cooperation in the world, and smart contracts are an incredibly powerful tool for helping that happen. For that to matter though, it’s got to be available to most of the programmers in the world. It’s not much help if, to get a smart contract built, you have to go pray to the priesthood of 10k expensive Solidity developers. It’s easier to find a good lawyer and do it the old-fashioned way! So we set out to meet devs where they are at and empower them to build smart contracts.

The surprising answer is that JavaScript is more securable than most other programming languages, due in large measure to the contributions of our, Chief Scientist, Mark Miller. He’s has been driving the needed elements into JavaScript from our earlier secure language work since the beginning. His 2015 paper at financial cryptography on “Capability-based Financial Instruments” showed examples in the E programming language that you can now write in JavaScript on Agoric.

The reason JS is more securable is also partly an accident of history: the JS language was standardized in ECMA, whereas the browser host environment for it was standardized in W3C. That corresponds to a user-mode/system-mode separation that is required for secure operating systems. You have never seen a design boundary as well defended as committees defend their turf 😄. So the only way that a JS program/module/whatever gets authority to anything in the system is if it’s put into the global object used for evaluation. In the browser, that global includes

document

such, whereas in node, the global includes

fs

and

process

and the like. Mark and others have kept JS on that track. And with a few additional features (e.g.,

freeze

) we are able to evaluate JS code (e.g., on the blockchain or in servers) where the only authority it gets is to specific services we provide it It can’t get at the filesystem, the network, etc.

that’s the “hardened JavaScript”. It’s open-source, available for web2 and web3 at https://github.com/endojs/endo, and runs in any standard JS environment. It’s the backbone of MetaMask’s next gen wallet, used in Salesforce’s AppExchange, and of course used for our smart contract platform.

Dean Tribble, that’s incredible! You had quite the journey. I have to ask, in the name of the not-so-tech-savvy folks, could you elaborate on smart contracts on the blockchain? And what do you mean by composability?

As for what a smart contract is: “software enforcing the terms of a contract-like arrangement between multiple parties”. That it! Hence eBay and PayPal and Lyft and StubHub all are largely smart contract business deployed by a “trusted intermediary”. So smart contracts were $1T+ market cap *before* blockchain. We rely on the intermediaries to faithfully execute their software, and most transactions go through without any human involvement by the hosting company.

Such businesses took off much faster once there were good libraries and platforms to rapidly compose new businesses without coding everything from scratch (e.g., shopify, stripe, etc. all provided components that developers could reuse).

Why was it so hard to came up with a "code that can be executed on the blockchain", which is what the smart contract is in general (correct me if I am wrong), and we needed to wait for Ethereum to come with this solution?

But my favorite component model example is in the UI space (I worked on UIs as an intern in the Smalltalk group at PARC after all). Before React/vue/etc., experts could build some pretty cool stuff in JavaScript. BUT it’s a nightmare to debug fancy apps written in raw HTML/JS (I still recall my last round of trying to debug why the tax rate of some purchase page wasn’t changing when the user changed their zip code). React provides a component framework for user interface components that completely addresses many of the hard problems in building fancy UIs, and more, enables components built by multiple parties to work together extremely well.

The result is that shortly after React came out, new developers can build fancier, safer, more responsive, more helpful applications than experts could the year before React. That’s what a component framework gets you.

Our goal is a framework that provides the same kind of support, but for smart contracts that handle digital assets, pricing, etc. (instead of ouse clicks and rendering). In platforms like Ethereum, there are security hazards that are frankly too high-risk for cryptoexperts, let alone application programmers just trying to solve their business problem. Our framework is designed to protect developers from those hazards.

So a smart contract is not “code that can be executed on a blockchain”, since there was $1T+ of value in smart contracts before blockchains!

Bitcoin is itself a smart contract; it’s software that’s enforcing rules for transfer of BTC. It’s the first smart contract that didn’t need a trusted intermediary.

Eth brought support for running other people’s software. There were a couple of requirements for that. The gold standard of blockchain is

multiple computers in different jurisdictions and different administrative domains all coming to consensus about data, choices, and computation.

I’ll unpack that, and then talk about why it’s important 🙂.

Hey Dean Tribble Could you please explain a bit about offer safety in Agoric and does it refunds the original asset plus the transaction fee or just the original asset ?

multiple computers in different jurisdictions and different administrative domains all coming to consensus

Means that no human, organization, or government can unilaterally change the systems behavior. They would have to simultaneously compromise a majority of machines (which are controlled by other parties) to compromise the integrity of computation.

about data, choices, and computation.

Data: “Dean has $100 in his account”
Choices: “Dean tried to withdraw his offer before the auction closed. Did he win the auction and spend his money or did he get his money back?”
Computation: “the auction ran and determined that Dean would be the winner”

The novel hard technical part is “all coming to consensus”. If you know all the computers (you don’t) and you can rely on them all to not cheat (you can’t), then we know how to count votes and make sure it’s a majority. The area of Byzantine Fault Tolerance covers handling the “what if they cheat”. The most brilliant insight in BitCoin was how to address consensus when you don’t know all the participating computers.

Finally, for those computer to all check that they agree, they have to actually agree! So the same program run with the same arguments multiple times in multiple places have to produce the same answers (this is called “deterministic”). That turns out to be hard! If they can see the clock, they can behave differently. If they can see any memory address, they can behave differently. If they can see when garbage collection happens,…you get the idea.

So Solidity has a lot of issues, and is very low-level, but it does execute deterministically. Our hardened JavaScript lets you run JavaScript deterministically! That will make all this accessible to a lot more developers

Pawan Sharma asks about “offer safety” in Agoric. That’s one of the critical properties of the smart contract framework. Familiar safety properties are things like memory safety and type safety, where they just completely eliminate some large class of bugs. They don’t solve everything but they can take 80% of bugs off the table.

Offer safety is a safety property at the economic level.

First the setting: In existing blockchains smart contract systems, you execute transactions by sending money to a “random number” (an account address) and hoping something good happens. People have sent (and lost) assets to “addresses” that weren’t real accounts, that were wrong accounts, to contracts that then had failures, etc. This model is both error-prone and a horrible user interaction. I want to send money to my friend John, not to 0x234ag3453.

Real business involves quid pro quo: “I will give you $X if you give me concert ticket Y”. We support that directly. So in our API, clients invoke smart contracts by making

offer

s. Each offer says what they

want

, what they will

give

for, and under what circumstances they can

exit

with their assets. The payments in that offer then go into the framework itself and NOT to the smart contract. The only way the smart contract can get the assets is if it provides the assets that the offer wants.

So what’s offer safety look like for an auction?

Zoe holds all the assets, and notified the contract of each offer. When the auction closes, the auction contract atomically

reallocates

the concert ticket to the winning bidder and the winning bidder’s money to the seller. That reallocate will only succeed if the winning bid is enough for the seller and if the concert ticket is indeed what the bidder bid for.

No misbehavior, bug, etc. on the part of the auction contract can enable it to take money from the bidders that are not getting the concert ticket.

That means that the clients of the auction are MUCH safer. They don’t need to read the auction code to know that they get their desired ticket or their money back.

Also the creator of the auction contract is happy too: many of the hazards in Solidity are around handling money that you are not supposed to hold onto. There have been literally $1B+ lost/stolen due to sloppy handling of returning money from contracts. With Zoe and offer safety, you don’t need to write a single line of code in the contract to deal with that safely.

A related property is “payout liveness”: remember each off has an

exit

as part of its terms. The default for that (which you conveniently don’t need to specify) is “whenever I want; it’s my money dang it!“. Well OK it’s called “OnDemand” 🙂 That just means that you can exit whenever you want, and again, no bug or malicious behavior on the part of the contract can delay you exiting the offer and getting your assets back. Note however, that “your assets” might be after some reallocations have already happened. If you offer was “I’ll buy up to N tickets for X moola”, then it might have already reallocated some of those N to you and taken money for those, consistent with the

want

that you specified. But once your exit signal comes in, Zoe pulls your assets and returns them to you without the contract getting to intervene. Similarly, if the contract crashes, hangs, etc. Zoe will exit your offer. It’s astonishing just how much money is unintentionally “locked up” in contracts where users have no means to get their money back!

Dean Tribble, thank you so much for your detailed answer! What about the smart contracts vulnerabilities? How can they be reduced?

Dean Tribble Great explanation !!

For ways to reduce smart contract vulnerabilities, we discussed

Additional critical ways:

In Ethereum and other chains (most recently PolyNetwork), billions in losses have come from “re-entrancy”. That’s where if there are 2 components (or contracts) A plans to call B and then do something X, but B calls back into a (re-enters A) before it can get to X. For example, A is an auction, an B requests a refund from bid. B says “send me my refund”, and so A looks it up, and sends the refund to B, and then records that it has given a refund to B. BUT when B is sent the refund, instead of replying “thanks”, it immediately send the “send me a refund” message to A again. Since A has not yet recorded that B has received its refund, it goes ahead and sends the refund again. And again, B reacts to that with “send me a refund”. The A service never gets to the point of recording that B has received its refund, so B just does this until it has drained A’s account. It sounds absurb when said like this, but this was exactly the bug in 2017 that got folks wondering whether the tech behind Agoric could help blockchain. And one $660M exploit last year was the same basic problem. It’s because the architecture of Eth allows, supports, and even requires reentrancy.

The Agoric model is fundamentally asynchronous, meaning that when A sends a message to B, it doesn’t sit there waiting for B to do something. It moves on and finishes recording what it needs to record. It means that trivial example aren’t quite as trivial, but it also means that non-trivial examples (like DeFi) aren’t fraught with security hazards.

Hey Dean Tribble! Great to have you with us! What would you say are the main challenges when it comes to building an economy in DeFi?

Oh, I see. Thanks for explaining, Dean Tribble. Reentrancy can cause a lot of trouble. Is there any way to know when we are dealing with a reentrancy system?

re rentrancy; it’s part of the system architecture, and so cannot be papered over with different languages or helper libraries. A system in which calls between contracts or contract components are call-return (A calls B and waits for the answer) are almost always reentrant. If while A is calling B (“hey get me my refund”), someone else can call into A, then it’s likely reentrant. The architectures that aren’t either use asynchronous messaging (like agoric) or just have limited semantics (like e.g., Kadena).

re challenges in building an economy in DeFi

Dean Tribble, what about scaling web3 through JavaScrip developers? What do you mean by that? Is something Agoric is working on?

It’s at the heart of what we are working on. Lots of folks talk about scaling transaction speed or blocksize or latency. But the hardest thing to scale is the developer base. To reach a significantly larger community of developers, we cannot expect that they will drop their current languages and tools and work on yet another programming language. We must “meet them where they are at”.

So with agoric:

The specifics matter (e.g., JavaScript with async execution and such) but it also matters that the priority is enabling developers that just want to get something done. Our platform should grow like JS and Node did: from teh ground up because it enables programmers to get stuff done! :)

My goal is that “if you can build a web2 application for the cloud, you can build a web3 application for agoric”. It’s early, so we aren’t there yet, but we will be.

Hi Dean Tribble thanks for joining us! My question is: why open source? What benefits and cons does this model have and how do the pros outweigh the cons?

Lots of reasons for open source.

Personal motivation: I’ve had the opportunity to work on some amazing projects. The problem is that some of the most amazing didn’t ship, and so that part of my life had some fun, interesting, but ultimately much less valuable time spent. Much of what we are doing is finally building an open source version of really useful tech that we’ve built in multiple incarnations, but haven’t been able to easily carry forward into new projects.

Cultural motivation: JavaScript is a largely open-source world. And we want lots of reusable components. Historically, that kind of reuse flourishes best in an open source environment: devs know that other devs are goign to the same tech stack for components, so that’s where they will build and contribute their components.

And finally: the core value prop of blockchain is high integrity via decentralization: smart contracts are executed on multiple computers run by independent operators in different jurisdictions. If they are all running the same, closed-source software, then we would get essentially no decentralization. The implementors are a single source of failure. And really it needs to grow into community-owned code. Thatonly really works with open-source.

That's a wrap! Thank you so much for being here answering our questions, Dean Tribble. Do you have any final thoughts or is there anything you'd like to promote?

We will be launching our “mainnet1” to provide a community-backed stable token for the interchain environment. Come participate with the community in http://agoric.com/discord and sign up for the newsletter and http://agoric.com/newsletter ! And if you are web2 developer, checkout endojs. Thanks for having me!

And of course our Agoric announcement channels,
Telegram (https://t.me/agoric_ann) and Twitter (https://twitter.com/agoric).