This is a revised transcript of our latest Q&A session with Agoric's CEO Dean Tribble that followed our podcast episode on the Agoric platform. Dean also brought on his colleague Mark Miller, Chief Scientist of Agoric and author of the Agoric Open Systems papers. Our discussion with the two lasted for almost one and a half hours and covered their long history of developing smart contracts, frameworks for smart contract development, advantages of Agoric's object-capability model to Ethereum's current identity-based design and more!
Welcome Dean! Why don't you start with giving us some background about you and Agoric?
Dean: Thank you for having me. I've been working on smart contract technology since I helped with the first production one in 1989 :)
Agoric was founded last year. Our Chief Scientist, Mark Miller, inspired lots of blockchain and distributed systems work with his Agoric Open Systems papers (in 1988). As you can imagine, that's where we got our name from.
That was really the first clear vision of software components creating and participating in markets.
So you have started to work with Mark straight after reading these papers? Or was your first production smart contract unrelated?
Dean: Mark and I worked together at Xerox PARC before that, starting around 1986. That was work on secure distributed programming lgnauges and operating systems.
So we were indeed working together at Xanadu (one of the origins of Hypertect before the Web), and our sister company, American Information Exchange (AMIX) was starting a business that was basically an online, hosted smart contract.
I helped with a big part of their smart contract design.
How closely aligned are the smart contracts of the 80s with those of today? What are similarities / differences?
It really combines both smart contracts and blockchains. Our definition of a smart contract: A contract-like arrangement, expressed in code, where the behavior of the program enforces the terms of the contract. The AMIX system hosted that on a "trusted 3rd party". Blockchain eliminates that need, which gives us much better ability to build new kinds of cooperation.
So the contracts are quite closely aligned, though the early focus was using markets to manage compute resources.
Other things are surprisingly the same: we observed at the time that the dominant paradigm of identity-based access control did not well support dynamically the changing "permissions" that smart contracts require. That's why we helped champion to "object-capability" model.
I think one of the big difference now is how powerful frameworks have shown themselves to be. The websites people build now are amazing. That's in large part because programmers of diverse skills can create components that other programmers use to build those sites. So that across the millions of developers, only a few need to be experts at for example creating new fancy animation and styling tools, and the others can just leverage them. We need the same thing for Smart Contracts if we are going to get a large and growing online economy.
Mark: Hello everyone. Happy to join you.
Hello Mark, great to have both you and Dean here!
Unlike 2015 (Etherem launch), one of the challenges in launching a smart contract platform today is the sheer glut of different platforms - Ethereum, Cardano, Tezos, Polkadot, Libra, Solana, etc. Smart contract platforms are starting to seem as diverse as programming languages. Do you think there is 1 winning way of building a smart contract platform, or will all of these different approaches coexist in the future?
Dean: I don't think there will be one language. But to bring the economy online, we need millions of programers, so that means at least some of those languages need to be much more familiar to mainstream developers.
The primary issue with several of the systems now is not their languages, but rather their security model.
The identity-based access control model (e.g., msg.sender in Solidity) really obstructs creating, combining, and reusing safe smart contracts.
What do you mean by "frameworks for smart contracts"? In the web2 model, I can see that somebody writes a framework like D3 (Mike Bostock) which carries elements for charts, movement in charts, transitions etc. and other developers can build charts. In Ethereum, somebody builds a token (Dai), and other smart contracts can make use of Dai. Does the issuance of tokens in one element of the system, and it's usage in another qualify as a framework for smart contracts?
Dean: I really do mean frameworks like that web2 model. If I'm an expert in the art industry and want to build an online app for digital art auctions, I shouldn't need to implement escrow and auctions myself. I should be able to find already-built components, already security-reviewed, by experts in those respective areas, and combine them with my little bit of art code to produce my business.
Those are the reusable components. In web2, that happens all the time. In existing smart contact platforms, that's so hard, every instance is notable.
What kind of frameworks do you imagine might exist in the future for smart contracts? Is there somewhere specifically we're seeing a lot of re-implementation of?
Dean: Well even the "Solidity by Example" shows a bunch of boilerplate code, e.g. returning funds to the losing bidders. If that money was instead put into an escrow contract created specifically for that bidder in the auction, then the "reused" escrow contract would handle that, not just for that auction, but other instances would handle that pattern for other applications.
In a React UI, for example, I can instantiate a nice menu from a menu module I found. In smart contracts, I want the same with escrow, call options, auctions, order books, catalogs, shopping carts, etc.
So I expect frameworks for DeFi innovation, gaming, freight, etc. But these frameworks should overlap and be able to combine safely.
So I would want to be able to use financial components tied to freight movement components to for example, provide a line of credit based on confirmed delivery via a package chain of custody smart contract.
You mentioned the problem is with the security model of existing systems - how does this fit in to building a generalized framework? It sounds like two different problems to me.
Dean: Ah! They are quite tied together. With the right security model, I can send you a concertn ticket with brian.enjoy(myConcertTicket). You could then sell it to someone, or build a call option around it and sell that (e.g., "for $10 you have the right to buy the concert ticket for $100 until Friday").
That works very simply with objects and is easy for lots of programmers to grasp.
With the identity model, instead, I would have to say concertTicket.changeOwner("brian"). Creating a call options that does something similar would be more complicated, and would require having added support to the concert ticket up front to support that.
Mark: The access-control model determines whether security abstractions compose well or badly. Solidity uses an identity-based access control model (concretely via checking msg.sender) that is known to behave poorly under composition --- in several different ways.
Dean: In our model, contracts by default create new "bearer instruments" like a concert ticket that I can send you. The call option is a bearer instrument that you can sell etc. That allows them both to participate uniformly in reusable components like my earlier-mentioned escrow.
Now that object capabilities have found their way into various other languages, have the designs of other systems and languages like Pony/Newspeak had an effect on how object capabilities are designed to be used on Agoric?
Dean: Mostly our work influenced those platforms, so we are delighted with the adoption of ocaps across those various systems.
Mark: Both of those are very nice ocap languages, and are part of our overall community of ocap language designs. We know their creators well (Gilad, Sylvan) and have bounced many ideas around, and learned from each other.
Pony is a particularly rich source of new ideas. They support both object-capabilities and reference-capabilities. My favorite explanation of reference-capabilities is from the creator of the closely related Kappa language (approximate quote):
An object-capability is one that, by virtue of having it, you can do certain things. A reference capability is one that, by having it, you know something about what others cannot do.
Are the benefits of using object capabilities in smart contracts similar to what could be gained using typed languages?
Dean: Absolutely. One of Mark's phrases is that with ocaps, the authorization graph is the object reference graph. Reasoning about graphs is straightforward in many ways. For example, if two graphs are not connected (no object in component A points at an object in component B), then *nothing* they can do can create access. Thus, I can have easy assurance *without reading the code* that for example the bank account object in component A cannot be manipulated by component B. So it's complimentary to typing.
I like strong typing, but in a distributed system, you cannot rely on the "types" of the machine on the other end of the wire. So fundamentally, type checking must be dynamic. Thus it may be useful for the construction of software, but it contributes little to hte security *model*. for example, on Ethereum, the Solidity type system helps programmers, but doesn't matter for security. What matters is the behavior of EVM.
In particular, I'm curious about ownership models.
Good catch. In our approach, we build ownership models *above* the layer of objects. In my example of sending the concert ticket to Brian, I passed him a concert ticket object, but I still have a pointer to the ticket object as well. Our Electronic Rights Transfer Protocol (ERTP) is part of the framework that allows Brian to take that shared access to a concert ticket, and claim exclusive access.
This relates to the type questions as well. While he was expecting a concert ticket, I might have passed him the string "punkt" instead.
This is interesting, can you expand more on the ERTP? How is this implemented?
Dean: So in ERTP, he claims the ticket by asking an authoritztive object he *already has* to claim the object: briansTicket = concertVenue.claim(concertTicket). That's like signing for a pckage and unwrapping it: at the end, Brian as taken delivery of the ticket and knows both that it is authentic and that he has exclusive access.
We have some high-level descriptions of our proof-of-concept version in existing presentations at web3 2018, a series of talks with Protocol Labs, etc. And of course it's up and running in our testnet. BUT evolving/completing ERTP is what we are in the midst of now. You can watch it as it happens in our ERTP github repo, and I plan to present a lot more details on the way to our SF Blockchain Week presentation and hackathon participations.
Mark: The latest of those talks are:
It provides a good summary of our overall architecture.
Dean's web3 talk is at:
What I find weird about this is that the receiver appears to need to do an operation to receive something. In Bitcoin, I can do lazy receipt, i.e. I don't need to do an operation to receive assets in my account. To me, this breaks the user experience. Does it concern you that receivers will need to be online for receipt?
Dean: Nope. the analogy doesn't really hold in practice. Receipt will generally happen when these capabilities are presented to a smart contract, which can take receipt. Also, in the framework in progress now, most deliveries will be from escrow, so there's no urgency in "claiming" it.
The reusable escrow component will be holding it until your wallet pulls it into a particular account.
Regarding Jessie, Agoric has a few proposals open for the EMCA specification. What kind of impacts could the Agoric project have on the JS community at large? Could these improvements help JS in other areas too, such as in the browser?
Dean: Great question. I'll let Mark dive into some details, but I will note that just yesterday (and still today) HackerNews has an article by Figma about how they use our SES (Secure EcmaScript) to provide secure extension in their product. Similarly, Salesforce LockerService (who helped build some of the tech), and MetaMask are using it to provide web2 security. The solution we found helps us run Figma plugins in a safe way — i.e. not eval(UNTRUSTED_CODE).
Mark: npm estimates that, of the typical JS app, only 3% is specific to that app. The other 97% is third party libraries that are incorporated with, necessarily, insufficient vetting. Everyone has this problem.
Dean: Obviously, MetaMask usage is bridging from Web2 to Web3, but their tool (sesify) is more generaly, and I expect to be used to secure a broad range of web2 and web3 frontends and dapps.
Related to that question, is there anything in the JS ecosystem that looks like it could be beneficial for smart contract platforms at the moment, or are the two areas relatively disconnected?
Dean: TC53 was recently established to standardize JS for embedded systems. It's adopted our SES as it's core model, and is helping push module and security standars that will indirectly benefit JS usage in blockchain.
Also, many of the enhancements being contemplated in the standards committees (of which we are a part) will indeed benefit blockchain. bignums, the recent adoption of weak references (that I was a champion for) by the various JS runtimes, even internationalization support will enhance the dapps that we are all building.
Mark: Kate's talk explains that, under current practices, everything in your app is fully vulnerable to every one of those libraries. Node has already adopted many elements of SES, available under an experimental flag.
Just a short question to the realms shim and the ses npm package. Isn’t it required to load/initiate the shim or the ses npm package as first before any other dependency get loaded? Because any dependeny which is loaded before the Realm is created could overwrite properties on the global object? 🤔
Mark: Yes, that is required. Sorry, but I need to go. Bye.
Dean: The Moddable team released a version of their standards-compliant JS implementation for embedded systems that directly supports SES. It as ra result doesn't need the shim for SES and so the startup sequence is different. We except to use that runtime for our production chain system.
Thank you Mark for your time. We look forward to meeting you in SF Cosmos Hackatom. What's the most mature Jessie smart contract we could study?
Dean: That's a great question. Right now it's probably the covered call option. BUT all the mature ones are being rapidly mutated as we evolve ERTP, so I'll have a better answer in a week or two. We are using a bonding curve DEX (uniswap-like abstraction) as an example but it's still settling down.
Dan Robinson and Mark started building competing "agoricswap" implementations using our PoC framework (which we know doesnt' include key elements to simplify contract creation). Much of our current development is to get the framework to where it's expression is clear and point you at that.
Bonding curve DEX sounds intriguing. Agoricswap = token swap with smart contract escrow?
Dean: Aye. We will have a Medium post or some such explaining an illustrative smart contract in detail in the next month or so.
I meant "the uniswap-like thing we build in our framework" but I like your definition better :D
In our ERTP repository is the very first uniswap implementation we did. It's interesting because it's both "the core of uniswap in ~100 lines of JS" but also it's "way too low level". So it's not the right thing to study since it's what you would build *when you don't have enough a framework*. The real one will be clearer and simpler.
Interesting. Looks very different visually from Solidity code.
Dean: Well yeah. Let me be very clear that it's NOT how contracts will be constructed in our system.
It's like building an auction in assembly language with no libraries: amazing that it's possible, has all the right security properties, but not how millions of programmers will conquer the world with smart contracts.
So we will come back with the "story of many uniswaps" when we have the real version :)
Look forward to that Dean! What does harden do in the context of your uniswap implementation?
Dean: "recursive freeze". Without it, JS objects are malleable (e.g., I could replace your toString() operation with a version that copies the contents to an attacker). With harden, I can rely on the object properties to stay the same.
Got it, in fact, regarding SES — currently in the FAQ there's a mention of separation between external and internal computation hinting that Agoric contracts are pure. There's also mention that for things like Math.random are solved through other ways. Are Agoric contracts meant to be pure?
Dean: Yes, Agoric contracts will be pure, with the top-level having some endowments provided (like the ability to access contract persistent state, send messages to accounts, etc.).
Time to get back to hacking. Thank you all for your time and questions! Happy to handle further question more asynchronously :)
Agoric Twitter: https://twitter.com/agoric
Agoric Telegram: https://t.me/agoricsystems
Agoric GitHub: https://github.com/Agoric
Agoric Open Systems Papers: https://agoric.com/papers/markets-and-computation-agoric-open-systems/abstract/