How Agoric’s JavaScript framework provides the best of both worlds

The first thing that economics teaches us is that trade-offs exist everywhere. People who want a little more of one thing usually have to give up a little bit of some other thing. Programmers often find themselves faced with a particularly difficult trade-off: Do I build out rich functionality, or do I lock down code for security?

“Sandbox Cycle” (xkcd.com)

The diagram below — familiar from Econ 101 classes — illustrates the problem: We are stuck on a trade-off curve, one in which gaining more security comes at the expense of getting less functionality, and vice versa. For example: I’m trading off security for functionality. As I get something more secure — as I sandbox it and isolate it — I lose functionality. In contrast, as I open it up, I get more functionality, but correspondingly get less security. Most developers are moving up and down the curve (as depicted along the line labeled A) to try to achieve their goals.

In the blockchain world of smart contracts, the either/or between security and functionality is an especially severe challenge. What makes the issue urgent for smart contracts is that they handle valuable assets on behalf of multiple parties with divergent interests (each party needing assurance that the other party is acting according to how the contract says they’ll act). Giving up security is not an option with value at risk, but lack of functionality means that no one will want to use a given service. How, then, does a developer guarantee security and safety, while still enabling all the rich cooperation to take place?

The solution is to shift the trade-off curve out: up and to the right. The trade-off between functionality and security still exists, but we can now get more security for a given level of functionality, and more functionality for a given level of security. By moving from A to A1, we can get more of both. This is what we’re accomplishing at Agoric: building technology that shifts the curve out.

Opposing Camps

One important manner in which this trade-off manifests itself in the world of smart contracts is in the choice of what programming language to use. We identify two opposing camps: special purpose versus general purpose.

On the one hand, we have seen a plethora of new special-purpose programming languages start to emerge that attempt to make it easier for developers to write secure smart contracts. These usually restrict what programmers can do in order to achieve greater security — whether by being Turing incomplete, or by trying to be more amenable to formal proofs. But the use of new languages comes at a cost: not only by making development more difficult, but requiring developers to work in the absence of the libraries, tooling, and rich ecosystems that should make their job easier. Moreover, these newer languages are by definition immature, and will take time to prove their security properties, and accrue a rich ecosystem.

On the other, we have seen an increasing number of blockchains adopting Wasm (WebAssembly) as their runtime engine, so developers can choose to program in familiar, general-purpose programming languages, whether it’s C++, Java, Rust, or whatever. This promises to make it easier for developers to take advantage of their existing knowledge and access to rich ecosystems to start developing smart contracts, but it does little to address the unique security problems of smart contracts. Programmers, thus, are left to fend for themselves, and no one wants to be the person who loses a hundred million dollars with their code.

We believe that both these approaches have merit. What developers want is a familiar programming language specifically created to meet the challenges of smart contracts. This is what Agoric delivers: the best of both worlds.

Best of Both Worlds

Agoric starts with JavaScript, the world’s most ubiquitous programming language, but we don’t stop there. We provide the additional support developers need to create robust and secure smart contracts. Our approach builds upon our founders’ decades of work on smart-contract programming languages (explore the Agoric canon, agoric.com/papers, for a deeper dive), and a decade of work by Agoric members of the JavaScript standards committee (TC39).

We take a layered approach starting with a secure, distributed JavaScript runtime. Next, we introduce a safe and secure subset of JavaScript that enforces POLA, the principle of least authority, and removes most of the foot-guns — those pesky language “features” that too often shoot developers in the foot. Finally, we add our Zoe contract framework that enforces offer safety, and thereby removes much of the risk from smart contract development.

Together these layers provide the best of both worlds: the power of a well-established, general-purpose programming language combined with the special-purpose support needed so that developers can write smart contracts with confidence. In future posts, we will dive into the specifics of each layer to show how they combine into a powerful new way to write smart contracts.

Trade-offs are everywhere, but they can be improved.

Thanks for reading! You can join the Agoric community on Twitter, Telegram, LinkedIn, and catch us at these upcoming events.