New Smart Contract Languages

High stakes, big losses, new behaviors, and the path to a safer web3

Hi 👋 welcome to Brian’s Bulletin. I write essays about blockchains, cryptocurrencies, and NFTs to figure out what’s happening and where it’s going next.

---

Rekt News is a busy website; it tracks all the hacks across the crypto industry. There's about one per week lately, and the leaderboard would scare off any risk-averse business.

Many of these "rekt" companies employ the most highly-technical and security minded engineers with the deepest experience in crypto. If they're getting hacked for millions, then it's unlikely mass adoption of crypto will ever happen.

I wanted to know why this is happening and what's being done about it, so I listened (three times 😬) to an a16z podcast with leading smart contract engineers from a16z and their guest Sam Blackshear who they describe as “Co-founder/CTO of Mysten Labs, who has a long history in programming languages from his PhD to working at Facebook (and Libra/Diem) to being one of the authors of Move programming language.”

One thing seemed obvious from their conversation:

"The whole crypto space will not advance without a safer smart contract language." - Sam

Here's a walk through their topics of conversation:

• Traditional programming languages

• Smart Contract Problems

• New behaviors

• Designing a solution

• New language efforts underway

Let's dig in.

---

Traditional Programming Languages

"Programming languages are problem solving tools. What new problem arose? What new language came in to fill that niche?" - Sam (4:20)

Over the past several decades, many programming languages were created to solve problems that emerged from new behavior patterns.

For example, they spoke about how the rise of web development brought a need for programability beyond the existing CSS language. Wikipedia explains that in the early 1990s, "during these formative years of the Web, web pages could only be static, lacking the capability for dynamic behavior after the page was loaded in the browser. There was a desire in the flourishing web development scene to remove this limitation, so in 1995, Netscape decided to add a scripting language to Navigator."

Navigator was the most-used web browser at the time, and wanted websites to be dynamic and reactive. So Javascript was adopted, and then evolved in the following decades into a global community with many open-source libraries and support.

Anther language they mention is SQL which is now the lingua franca for handling databases and large data sets.

The key question, as Sam said, is: "What are programmers trying to do? Where is the language helping them, and where is it getting in the way?"

If its doing more harm than good, then theres a good case for something new.

Smart Contract Problems

"Solidity and EVM is the first effort in the space, so it didn't quite anticipate what folks are trying to do." - Sam (1:14:35)

The quantity of hacks and money lost is a sign that a new language may be in need.

Here’s the Rekt leaderboard with losses in the hundreds of millions:

Sam explains that smart contracts are the "most adversarial programming environment we've ever seen, with the highest stakes." Attackers can directly call into your code, and you need to enforce protections on assets that may engage with attacker's code you may not even imagine could exist. All the while millions of dollars are at stake.

He says it bluntly: "Smart contract safety is an existential threat to broader crypto adoption... If the developers today are the most hardcore, there's no way this space is going to grow without making security problems worse."

New Behaviors

"The key problem we identified is that smart contracts are all about assets and access control, yet early smart contract languages lack type/value representations for both" - Why We Created Sui Move

In the podcast, they discuss the new programming behaviors focus on tasks like:

• Define assets

• Define policy for transferring assets

• Access controls for interacting with assets

• Enforceable constraints such as

  • Cannot copy

  • Hard to delete

  • Set supply

They also mentioned changes in developer mindsets:

• Resource usage: Normally developers code in a world of abundance, but smart contracts involve resource constraints and transaction fees

• Developer productivity: ordinarily devs write lot of code with only a few errors, but in smart contracts you write a little code that must be perfect, otherwise lose peoples money

• Upgrades: the barrier to changing code is higher than any other environment due to the immutability of blockchains

• Adversarial mindset: devs need to think not only about intended usage, but think of attackers writing code you may not even imagine yet

Sam explains at 6:55 that at first, for designing solidity, flexibility was most important because we didn't know what would be the dominant use cases. But now we know the trends and types of constraints we need, so we can include the constraints and safety checks in the language itself.

Designing a Solution

Sam explained that the way the solidity code is written is indirect. Its like you're trying to talk about something but there's no vocabulary to say it (1:13:50).

For example, Eddy, Head of Engineering at a16z Crypto, mentioned how ERC-20 tokens are not designed as you would expect. You don't hold tokens in your wallet, as many would assume; rather there is a mapping of owners and balances stored in a smart contract. It's like a central registry. When you transfer, what's literally happening is your balance is decreasing while someone else's is increasing. I did a breakdown of the code in a previous article, NFTs Literally.

Creating assets in solidity is like trying to explain American football without the game-specific terms. Try explaining it without touchdown, quarterback, and first down. Sure you could, but it would take longer and potentially leave gaps in understanding. If millions of dollars were on the line, it'd be much safer to use the specifically defined terms.

Sam's team explains their intentions for a new language is to "provide first-class abstractions for these key concepts, [that will] significantly improve both the safety of smart contracts and the productivity of smart contract programmers—having the right vocabulary for the task at hand changes everything.

To design a safer and more useful language, he mentions three specific elements:

1 & 2) A strong type system at the source and byte code level + Guarantees about constraints

Wikipedia explains a type system: "In computer programming, a type system is a logical system comprising a set of rules that assigns a property called a type (for example, integer, floating point, string) to every "term" (a word, phrase, or other set of symbols). Usually the terms are various constructs of a computer program, such as variables, expressions, functions, or modules.^[1] A type system dictates the operations that can be performed on a term. For variables, the type system determines the allowed values of that term. Type systems formalize and enforce the otherwise implicit categories the programmer uses"

In this case, the types could refer to an asset with the associated enforcement of values and operations allowed to be performed on it (e.g. can or cannot copy). The designers could also make more intuitive asset ownership model, instead of the central registry model.

Quick aside on source and byte code from Mastering Ethereum: "The EVM is a virtual machine that runs a special form of code called EVM bytecode... [which] is rather unwieldy and very difficult for programmers to read and understand. Instead, most Ethereum developers use a high-level language to write programs, and a compiler to convert them into bytecode."

3. Permission checks or Access control

OpenZeppelin describes access control: “That is, "who is allowed to do this thing"—is incredibly important in the world of smart contracts. The access control of your contract may govern who can mint tokens, vote on proposals, freeze transfers, and many other things. It is therefore critical to understand how you implement it, lest someone else steals your whole system."

Unfortunately, access control vulnerabilities have contributed to billions of dollars in exploits. A more tailored language design could be safer.

New Language Efforts Underway

They spoke primarily about two new language efforts, and then I'll add one they did not mention.

1) New languages that compile to the EVM. Vyper in particular.

Eddy said the reasons to pursue this avenue are that there are existing network effects in solidity and EVM, and there's plenty of space to improve the experience and safety at the source code level (22:25).

However, there's one big limitation that the low-level design of the EVM constrains how much a new high-level source language can help. At minute 21, Sam says "what's important is protection at the byte code verifier and VM level from other programmers... and a new source code language cant give you that. That has to be baked in to the VM. No matter how much you iterate at the source language... where you get to is not as good as where you get to if you have these protections built into the VM."

Eddy agreed: "The ability to do type checking for more useful blockchain native types or smart contract native types in the EVM is really difficult to solve" (22:10).

2) Move

This is a new language that Sam helped create starting at Libra/Diem. It's now used on a few blockchains like Sui and Aptos. It includes the design elements above, and its created to be flexible across different VMs, so developers can take their skills between blockchains.

Sam mentioned this tweet thread where he explains how hacks on Ethereum could have been prevented with Move.

3) Cadence

They did not mention this language but it’s similar to Move and also used by some of the largest web3 products like NBATopShot. It's also potentially a competitor to Move, and the two tech architects later had a little spicy twitter exchange, which may be why it wasn't mentioned.

The Cadence docs say its "use of resource types maps well to that of Move." And Cadence's other design features seek to solve many of the same fundamental issues that Move addresses.

From my research so far, it seems both Move and Cadence teams identified similar smart contracting behaviors, problems with existing languages, and possible designs for a better solution. Then they took their own paths to solve it, which are different, but appear directionally compatible.

A direct comparison is a topic for another day .

The Road Ahead

The creation and adoption, or not, of new languages will affect the safety and potential for web3.

The bigger the developer community, the more investment in tooling and libraries, which all attract more developers and support.

With this, we’ll start to see answers to Eddy's question kicking off the podcast:

"What are the types of things we expect to change that maybe haven't yet emerged because there's really only been one language?"