a16z对话Move语言之父：从编程语言说起，为何Move是未来智能合约的重要方向？

2023.03.24

a16z对话Move语言之父：从编程语言说起，为何Move是未来智能合约的重要方向？

Last year, a16z and other institutions heavily promoted Move-based public chains represented by Sui, bringing the Move language back into the spotlight from the ruins of Meta's Diem.

2023.03.24 - 03:15:36

a16zMove

Navigating Web3 tides with focused insights

Last year, a16z and other institutions heavily promoted Move-based public chains represented by Sui, bringing the Move language back into the spotlight from the ruins of Meta's Diem.

Compiled and translated by Sui World

Last year, institutions like a16z heavily backed Move-based public chains such as Sui, sparking a major resurgence of the Move language from the ashes of Meta’s Diem project. At the same time, skepticism has persisted since the moment Sui Move emerged:

If the only reason we need a new smart contract language is that Move might be better than Solidity or other development languages, does that necessarily mean we must tirelessly build an entirely new Layer 1 from scratch?

Recently, the a16z Crypto team hosted a podcast titled "Programming Languages & Crypto" with Sam Blackshear, co-founder and CTO of Mysten Labs and the creator of the Move language, to discuss why Move represents a crucial direction for the future of smart contracts.

During this podcast, a16z Crypto and Sam Blackshear explored the design philosophy of the Move language, object- and asset-oriented programming, security, formal verification, governance, community tools, cross-platform adaptability, and more—discussing both differences and similarities between traditional programming and smart contract programming, as well as the unique constraints and opportunities in blockchain.

Key discussion points include:

1. History of programming languages and smart contracts

From traditional programming to smart contract programming, and now to Move programming. Move was one of the first languages designed specifically to address type systems, static typing, and compile-time checks.

2. Innovations in Move smart contracts

The EVM over-adapts to implementation details specific to Ethereum. Developers ultimately inherit many of Ethereum's design decisions—including some that make scalability difficult.

Move avoids embedding any blockchain-specific features into its core language. The innovations at the source code level will be significant, and Move ultimately offers code verifiers and VM-level protections against attacks from other programmers.

3. Design principles of Sui Move

Move is an executable bytecode language used for executing user transactions and smart contracts. In Sui Move, validators can perform parallelization more efficiently, making storage and execution easier without requiring these mechanisms to be encoded at the protocol level for users and developers to manage.

4. Security

In the world of smart contracts, we operate under tight constraints. We write very small amounts of code that must be flawless—security must be the top priority. Move's security model protects programmers from shooting themselves in the foot while providing them with correct primitives to defend against attacks.

5. Object- and asset-oriented programming

Move is designed as an object- and asset-oriented smart contract programming language because most Web2 object-oriented programming languages follow this paradigm. In Sui Move, centering everything around objects incentivizes highly granular access control. The global storage structure in Sui Move is a mapping from object ID to object.

6. Security comparison

Move eliminates reentrancy and missing permission checks through its design. Object ownership information is stored in object metadata—a detail not controllable by programmers. The Move Prover is specifically designed to prevent common errors when writing smart contracts, helping developers avoid many basic mistakes.

7. Governance of smart contract languages

Initially developed at Facebook, Move had no real governance. We are cautious about expanding the language. Simplicity is paramount, but we actively evolve it. Sam Blackshear has a clear vision: Move is designed as a cross-platform language where fundamental functions remain applicable across chains, accommodating both experienced smart contract developers and Web2 newcomers with great flexibility.

8. Learning advice for developers

Read large volumes of code—it’s the best way to understand a language. Be open to sharing and deep discussions, and find people who enjoy sharing code and building open-source communities together. Learn how any tool that makes your work easier actually works.

Below is the full transcript of the podcast, approximately 25,000 words, with an estimated reading time of 30 minutes.

Host Sonal Chokshi Introduction

Welcome to Web 3.0, a show produced by the a16z Crypto team about building the next generation of the internet. I'm your host, Sonal Chokshi.

This show aims to help anyone seeking to understand and dive deeper into crypto and Web 3.0—whether you're a developer, creator, architect, business leader, or policymaker. We’re kicking off a new season today. This episode focuses on programming languages and crypto, relevant both to existing smart contract developers and those looking to enter the space. It’s also ideal for anyone curious about the evolution and emergence of programming languages.

Our special guest today is Sam Blackshear, co-founder and CTO of Mysten Labs, a company laying the foundation for Web 3.0’s decentralized future. Sam has deep expertise in programming languages—from his PhD to his time at Facebook, to creating and authoring Move, an open-source programming language for building smart contracts. We’ll talk more about that.

We’re also joined by Noah, a smart contract research engineer at a16z Crypto, who recently co-developed Helios, a lightweight Ethereum client, winning a challenging gas optimization competition.

And we welcome Eddy Lazzarin, Engineering Lead at a16z Crypto, who previously worked in software engineering at Netflix and in data engineering and data science at Facebook. A reminder: none of what follows constitutes investment, business, legal, or tax advice.

1. History of Programming and Smart Contracts

Host Sonal Chokshi:

We'll begin with the history of traditional programming. First up is Noah, followed by Sam Blackshear and Eddy.

a16z Crypto Noah:

We want to explore how the history of programming influences the history of smart contract programming, because I think there are three things: traditional programming, smart contract programming, and the Move language. Each has its own history, right?

Sui CTO Sam Blackshear:

Yes, I like that framing. People often design languages to feel pleasant syntactically, which is valid—but it’s not just about that. I appreciate this broader perspective.

a16z Crypto Eddy Lazzarin:

Building on that, traditional programming has seen various trends over the past two or three decades. Programming languages have evolved, with certain topics rising and falling in popularity. For a long time, dynamically typed languages and loose type checking were very popular. The prevailing view was that jumping in, forgetting types, and ignoring technical details made coding more ergonomic.

Sui CTO Sam Blackshear:

But recently, people have begun thinking more deeply about type systems, static typing, and compile-time checks—to learn as much as possible about a program before it runs. These trends keep changing. However, for smart contract programming, due to its novelty, we haven’t yet seen this kind of historical progression in type-related matters, which makes it fundamentally different.

I believe Move is the earliest evidence we’ve seen of designing a language specifically to meet these needs (type systems, static typing, compile-time checks). I’d love to hear your thoughts on what changes we might expect—topics like static vs. dynamic typing in smart contract programming may emerge, though they haven't yet, partly because currently there’s really only one dominant language: Solidity.

Host Sonal Chokshi: So how does that connect to the shift toward smart contract programming? Let’s bring Sam back in.

Sui CTO Sam Blackshear:

In the smart contract space, with the EVM being one of the first entrants as a smart contract language, different trends emerged. At first, nobody knew what smart contracts would be used for, or how to write them. Therefore, flexibility was more important to allow experts to discover use cases. Now, I think we know—or at least have a sense of—the foundational building blocks.

The trend in smart contracts is extremely domain-specific: you define templates for assets, strategies for transferring assets, and access control and permission checks.

That’s essentially it—you don’t write compilers or operating systems in a smart contract language. That’s precisely where they excel compared to general-purpose programming languages.

I think people underestimate that even the ERC-20 standard came long after the EVM could be programmed—and the EVM was already considered one of Ethereum’s core building blocks. I just don’t see clear evidence that these basics were obvious beforehand.

So you’re right—now you can take types for granted. Bypassing types and similar things can carry technical debt, but if the scale is small, you just want to move fast, and the code can be discarded, that debt is acceptable. Interestingly, when you describe it at startup scale—small companies growing quickly, everyone understands the entire codebase—this technical debt is tolerable.

But when it gets very large, with many people modifying code and unaware of the consequences of new objects and systems, putting constraints into the type system creates explicit, direct barriers during coding—rather than accidentally creating glass fences that someone later crashes into.

For example, as you mentioned, preventing copying, setting maximum supply caps—these constraints are critical regardless of project size. They are essential for maintaining project soundness and security. Understanding these boundaries means you can now create programming languages that enforce them. That’s how I see the Move language.

As we learn the types of constraints needed to do things correctly, we now have the ability to embed them directly into the language itself. So yes, I agree it’s similar to what you described with types.

You mentioned that types are crucial for program soundness and security. You said dynamic typing might work for small projects, but as projects grow, static typing should be used. I somewhat disagree—I think fully static typing may be more suitable. This might be a novel view. It’s about programmer soundness. The scariest thing I’ve seen is pressing “Ctrl+K” in my editor and getting shown a function signature. When I write Python, that terrifies me—I look at the signature and only see parameter names. I’m left wondering, what exactly do you want me to do?

a16z Noah: I can’t believe people accept writing code they’ll never look at again.

a16z Eddy Lazzarin: They assume by default that they can hold system requirements in their heads.

a16z Noah: But even for a 100-line program, I don’t think that assumption holds.

Sam Blackshear: It can work, but it’s not perfect.

a16z Eddy Lazzarin:

I think you’re right. And I believe this mindset has evolved. Previously, type systems protected programmers from their colleagues. When your startup grows too big, that becomes useful. But now it’s more about protecting myself.

In the context of smart contracts, it’s about protecting myself from attackers. This is truly different—because in regular programs, you don’t deploy code knowing attackers are bound by your type system. Attackers can write machine code in other languages. You only need to protect your own firewall. But here, I write this well-typed object, and it flows into attackers’ code while preserving integrity. The type system must guarantee my safety.

As you said, it’s a powerful tool that brings different demands—you need to enforce things like preventing copying. These aren’t concerns in ordinary type systems, nor preventing deletion or ensuring values are used or destroyed in specific ways. These arise because we’re working on smart contracts and trying to build meaningful type systems for these use cases, so we end up adding them to Move—and possibly future smart contract languages.

Host Sonal Chokshi:

Actually, let’s discuss other differences between traditional and smart contract programming. But before we go further—could you briefly introduce the languages available to smart contract developers? I think understanding the current landscape—like Solidity, Vyper, etc.—will help us get up to speed faster.

Sui CTO Sam Blackshear:

Yes, generally speaking, if you want to write smart contracts, you almost always use Solidity—unless you happen to be in one of several smaller ecosystems.

If you're in the Polkadot ecosystem, you'd use ink! (Sui World note: ink! is a smart contract language developed by Parity for writing smart contracts in Rust and compiling to WASM). If you're in the StarkNet ecosystem, you use Cairo (Sui World note: Cairo is one of the programming languages for the STARK proof system).

But mostly, if I were advising someone learning smart contract development, I’d recommend starting with Solidity and then learning the EVM. You might consider Vyper, but its main drawback is that it’s newer and potentially more vulnerable. I remember years ago, during validation of deposit contracts, they discovered numerous bugs in the Vyper compiler. The person who found them now works at a16z—Day June, a formal verification expert.

Because Day June is a formal verification expert, he now works at a16z. The reality is, you need to learn something—you need to learn a language.

You even need to deeply understand the EVM.If you want to become a truly excellent smart contract engineer, you need to understand the EVM to an absurd degree—to the point where you can recite the gas cost of every operation, and precisely explain code related to gas costs. That’s the world we live in today.

a16z Eddy Lazzarin: One point worth noting is that as a software engineer, you can always learn about the machine running your code. There’s a lot to know about the programming environment. But in smart contract programming, the environment is incredibly rich and complex. There’s so much contextual knowledge required—almost unrelated to the language itself. It’s about what’s happening around you, what objects exist nearby, how different codes are invoked. It’s quite strange.

Host Sonal Chokshi: Is it true that JavaScript developers are the closest match for learning Solidity?

Sui CTO Sam Blackshear: Everyone says JavaScript because it uses the keyword "function," just like JavaScript. But unfortunately, they aren’t very similar.

a16z Eddy Lazzarin: Syntactically, Solidity does borrow many features from JavaScript. If you squint or are in a bad mood, they might seem similar, but in reality, they’re completely different. The virtual machine environments differ greatly, so there’s little in common.

Host Sonal Chokshi: Are there any closely similar programming languages?

a16z Noah: Yes, I don’t think there’s a directly similar language. If you’re familiar with WAS (Sui World note: WebAssembly Studio, an online tool for compiling C/C++ and Rust code into WASM format) and tried writing code in a highly isolated environment (like Surplus), where code executes independently but requires some communication—that might be the closest. But it’s still not very similar; the mental model is completely different, and superficial similarities can be dangerous.

a16z Eddy Lazzarin: Perhaps relevant are some major historical mistakes in programming language evolution. I wonder if blockchain has taken similarly wrong paths. Have we gone down terrible roads?

Host Sonal Chokshi: Great question.

Sui CTO Sam Blackshear:

Great question. 1977 saw the release of C and Standard ML. Standard ML was hugely influential. Today, OCaml, Rust, and Move all bear its influence. But these ideas have existed for a long time. Many people imagine an alternate universe where C didn’t dominate, and instead Standard ML’s ideas—strong typing, built-in safety—prevailed.

Host Sonal Chokshi: So what’s the trajectory of computing technology? I’m not saying it was a mistake, but languages like Standard ML still seem very modern today. Imagining that alternate universe is fascinating—when I first discovered it, I was blown away.

a16z Eddy Lazzarin: Out of curiosity, why do languages like C and similar ones remain so straightforward and imperative? They think about computers at a relatively low level and don’t do much as programming languages—that’s my view of C. Why did we go down this path?

Sui CTO Sam Blackshear:

I think hardware limitations at the time forced the use of C if you wanted efficient programs or to push computer boundaries. I believe if hardware had advanced differently, we might have chosen another path. Functional programming is hard—it’s counterintuitive in many ways. I’m not saying C isn’t hard, but it’s easier to get started. Then you realize you’ve done something very complex—or hard to reason about—but by then it’s too late. Functional languages have steeper learning curves, but once mastered, you realize you can think about your code independently and things fall into place.

a16z Eddy Lazzarin: I think if you think deeply about how computers work at the hardware level, languages like C feel more direct. But if you’re less familiar with programming languages, C is easier to pick up. But if you deeply understand programming languages, I think ML and functional programming offer more to explore.

Sui CTO Sam Blackshear:

That’s a broad answer. But I want to touch on small-scale “computer language mistakes.”

a16z Noah:

I’ve been hesitant about this because I’ve heard functional programming praised so much, but I find it a bit hard to grasp. But I’ve always wondered: if functional programming is so good, why hasn’t it overcome the network effects of current languages? That surprises me.

But I’d add that functional programming’s greatest contribution is that all our imperative languages borrow from it. Best of all, as you just said, Rust is heavily influenced by Standard ML, but Rust is basically an imperative language, right? Yet it possesses all that magical dust from staring at it.

Sui CTO Sam Blackshear:

Overall, I think the real issue is that imperative languages have had overwhelming influence since 1977. Then PRFP came along—as you said, not the greatest, with great isolated ideas but each having their own problems. Now we’re seeing real hybrids like Rust beautifully marrying them. It’s truly changing the landscape.

One thing I’d mention is Tony Hoare’s billion-dollar mistake regarding null references. While he might have exaggerated, clearly the cost of this mistake exceeds the cost of avoiding it.

a16z Eddy Lazzarin: No, that might just be the lower bound.

2. Innovation in Smart Contract Development

a16z Noah: I’m actually curious you haven’t talked much about innovation at the virtual machine and programming language layers, and how they affect smart contract development.

Sui CTO Sam Blackshear:

Great question. I think people don’t sufficiently distinguish between the virtual machine layer and the programming language layer. Beyond the EVM and new VM layers, there’s innovation in source languages like Viper. These are in many ways better than Solidity and interesting.

I believe if Move becomes the legal standard for Web 3.0 as we hope, innovation at the VM layer will be slow and incremental. Because the core is fixed, we’ll only add new things, not redesign from scratch.

However, I think innovation at the source language level will be quite important. Right now, we have only one source language, tightly coupled to bytecode. But as more clients use smart contracts and emphasize security, I can imagine many different source languages emerging—an interesting research area. Perhaps you could start by stating prior facts, then synthesize information within the program, or suggest constraints.

Maybe you start by writing your pre-Move facts, then have the program synthesized for you or receive constraint suggestions.

For instance, you might write Move in a very specific game context resembling a scene hierarchy. Maybe it’s written using a Python library but compiled into Move bytecode. Or perhaps you’re considering integrating Move like Solana or other platforms, but don’t want to integrate the VM—instead compiling Move bytecode into Salina’s bytecode format and using Move source language at the developer level.

I see many possibilities, similar to the JVM. The JVM is a beautiful general-purpose virtual machine initially supporting only Java. It stood the test of time, and now you have Scala, Groovy, and other interesting ways to use these primitives for different programming experiences aligned with what people want to do.

So I have a biased view that Viper gives you room to experiment at the source language level.

a16z Eddy Lazzarin: What’s your view on alternative EVM bytecode languages? Efforts like FE, Iron, and Viper aim to build smarter, more sophisticated languages atop EVM—do you feel optimistic about them?

Sui CTO Sam Blackshear: So these are different source languages compiling to EVM bytecode.

a16z Eddy Lazzarin: Yes, compiling to EVM bytecode.

Sui CTO Sam Blackshear: When we started designing Move at Facebook, we looked at other source languages targeting EVM—studied Solidity and Viper when we began building on EVM. We concluded that the hardest problem for developers writing secure smart contracts was the underlying nature of the EVM—how typed values flow across trust boundaries, dynamic dispatch, and so on—these are inherent EVM characteristics.

With a better source language, you can make it harder for developers to mess up. Maybe enable higher-level verification. But ultimately, what Move provides—and we believe is crucial—is code verifiers and VM-level protection against attacks from other programmers.

A source language alone can’t give you that—it must be built into the VM. No matter how many times you iterate on a perfect source language for EVM, I think Solidity is great, we can do better, but without these fundamental protections built into the VM, the outcome will ultimately be less attractive than other paths. I’m not embarrassed because Half is cool, but because the end state is less appealing than alternatives.

I think early smart contract languages, especially EVM, over-adapted to platform implementation details designed specifically for Ethereum—including instructions about transaction structure, account structure, use of specific cryptography, etc.

This makes using EVM on chains unlike Ethereum very difficult—you end up inheriting many of Ethereum’s design decisions, and in some cases, inherit mistakes that make Ethereum hard to scale.

When designing Move, we were very conscious not to embed any blockchain-specific elements into the core language, keeping it as blockchain-agnostic as possible. This way, you can use Move on a proof-of-work chain with a crazy transaction structure—maybe implemented one way in Sweden and another in Australia.

This means you don’t have to bet on a particular chain to become a Move developer. Your skills transfer across various chains, including future ones. We believe this is vital for a smart contract language’s survival, as a language’s greatest asset is its community. By making skills cross-platform rather than over-specialized to one language, you expand community size and increase chances of success. A large community enables heavy investment in tools, public libraries, and everything needed for a language to become mainstream and successful.

This is something we’ve tried from the beginning, now seeing multiple genuinely different Move chains with very different integration approaches.

a16z Eddy Lazzarin: To me, this echoes Node.js’ core theme, right?

Host Sonal Chokshi: Yes.

a16z Eddy Lazzarin: Many people know JavaScript and want to do many things. They want to share libraries. Existing code can launch server-side JavaScript instances, making Node useful. This means various developers who don’t do backend programming can start entering and claiming it as their domain.

Sui CTO Sam Blackshear:

I think that analogy works well. Also, we should discuss programming language governance, because Node obviously had notable governance splits and divisions—every programming language community has compelling governance disagreements and directions. I reported on Node—it was one of my favorites. But I want to ensure we finish this topic. Anything else? I think you’re our resident grump on the show, and I love it.

a16z Noah: So I have a contrarian view—or a cool idea. I keep wondering why nobody has built a Move OP Rollup—that would be super cool. Considering OP Rollups implemented on Ethereum using MetaMask and ECDSA signatures, but Move doesn’t seem to use the same signature format.

Sui CTO Sam Blackshear: Yes, we support Ethereum’s EdDSA and ECDSA signature formats.

a16z Noah: Perfect, but my point is, you could build some very interesting things. But when I tried learning Move, I kept staring at desserts and actor dogs. I was confused.

Sui CTO Sam Blackshear: That’s a real issue, right? When someone starts learning Move, they might wonder: I’m learning a smart contract language, but where’s the blockchain? Differences between platforms also cause problems when writing for both. I think the challenge we’re still tackling is choosing a platform, a dessert, an Optus—deeply learning it—then discovering your skills and code transfer easily to another. I think there are inherent issues here, plus documentation challenges to solve to make this easier.

a16z Eddy Lazzarin: Perhaps analogous to whether SQL is considered a portable skill. There are many SQL dialects. There’s anti-SQL—nobody really knows what it is, but people learn SQL. If you squint slightly, you can use any database, maybe get confused by specific function names or types, but roughly it’s the same shape.

I think that’s what makes SQL powerful and durable. That’s why it remains part of data’s lingua franca. Maybe that’s Move’s future. I think we can do a bit better.

Sui CTO Sam Blackshear: I think cross-platform portability is a great goal—very application-specific. It’s the right language for discussing tables and databases. It’s an uncontested fact—that’s why everyone uses it. So if Move could become the SQL of blockchains, I’d be delighted.