a16z talks with the creator of Move language: Starting from programming language, why Move is an important direction for future smart contracts

Original title: "a16z talks with the father of Move language: starting from programming language, why Move is an important direction for future smart contracts"

Original author: Sui World DAO

Last year, a16z and other institutions strongly supported the Move public chain represented by Sui, making the Move language popular on the ruins of Meta Diem; at the same time, from the moment Sui Move appeared, there have always been pessimistic voices:

If it is just because the Move language has the potential to be better than Solidity or other development languages, do we really need a new smart contract language and are happy to build a new Layer1 from scratch?

Recently, the a16z Crypto team and Sam Blackshear, co-founder and CTO of MystenLabs and creator of the Move language, had a podcast conversation titled "Programming Languages & Crypto", discussing why Move is an important direction for future smart contracts.

In this podcast, a16z Crypto and Sam Blackshear discussed the design ideas, object-oriented and asset-oriented programming, and security of the Move language, from the differences and similarities between traditional programming languages and smart contract programming to debating the unique limitations and opportunities of blockchain, and shared topics such as formal verification, governance and community tools, and cross-platform adaptability.

The main sharing content includes:

1. History of programming languages and smart contracts

From traditional programming to smart contract programming, and then to Move programming. Move is one of the earliest languages to explore how to design a language to accommodate issues such as type systems, static typing, and compile-time checking.

2. Innovation in Move smart contracts

EVM is over-adapted to the implementation details of the platform, which were designed for Ethereum. Developers ultimately had to inherit many of the design decisions made by Ethereum, including some bugs that made Ethereum difficult to scale. Move was designed without adding anything blockchain-specific to the core language. Innovation at the source code language level will be quite important, and what Move will ultimately be able to provide is code verifiers and VM-level protection from attacks by other programmers.

3. Design idea of Sui Move

Move is an executable bytecode language for executing user transactions and smart contracts. In Sui Move, validators can be parallelized more efficiently, which makes storage and execution easier without having to encode these things into the protocol level and let users and programmers think about them.

4. Security

In the world of smart contracts, we are in a state of constraint. We write very small amounts of code, and it must be perfect, and security must be the first thing to consider. Move security is to prevent programmers from stepping on themselves, and to provide them with the correct primitives as much as possible so that they can defend against attacks.

5. Object-oriented and asset-oriented

Move is designed as an object-oriented and asset-oriented smart contract programming language. It is designed like this because most Web2 object-oriented programming languages are like this. In Sui Move, the center point of things is placed on objects, and there is a high incentive to express fine-grained access as accurately as possible. The structure of Sui Move's global storage is a mapping from object ID to object ID.

6. Security comparison

Move eliminates the problem of missing permission checks in reentry and smart contract programming by construction. In Move, object ownership information is actually stored in object metadata, which is not something that programmers can control. Move Prover is designed to prevent errors in language writing smart contracts, which can prevent developers from making many basic mistakes.

7. Governance of smart contract language

Originally, Move was developed at Facebook without real governance. We are very cautious in expanding the language. Simplicity is the main thing, but we will actively expand it. Sam Blackshear has a very specific wish, such as Move is designed as a cross-platform language, some of the basic functions of chain EDM should still be applicable, and cover smart contract development experts and Web2 newcomers, with great flexibility.

8. Learning suggestions for developers

Read a lot of code, this is the best way to understand the language. Be willing to share and discuss in depth, and find people who really like to share your code with others and build an open source community together. Any tool that can make your work easier, you should learn how it works.

Below is the full podcast, which is about 25,000 words and takes about 30 minutes to read.

Introduction by host Sonal Chokshi

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 is designed to help anyone who is seeking to understand and delve into things related to encryption and Web 3.0, whether they are developers, creators, architects, business leaders, or policymakers. We are now starting a brand new season. Today's show focuses on programming languages and cryptocurrencies, and is suitable for both existing smart contract programmers and other developers seeking to enter this field. It is also a good choice for those who are curious about the evolution and emergence of programming languages.

Our special guest today is Sam Blackshear, Co-Founder and CTO of MystenLabs, which is building the foundation for the decentralized future of Web 3.0. Sam has a long history in programming languages, from his PhD to working at Facebook to creating and becoming the author of Move and open source programming language for building smart contracts. We'll talk more about this topic.

Throughout the show, we also have Noah, a Smart Contract Research Engineer at a16z Crypto, who recently won a challenging gas optimization by developing a lightweight client called Helios for Ethereum.

We also have Eddy Lazzarin, Head of Engineering at a16z Crypto, who previously worked in software engineering at Netflix and data engineering and data science at Facebook. Please note that none of the following constitutes investment, business, legal or tax advice.

History of Programming and Smart Contracts

Moderator Sonal Chokshi:

We will start with the history of traditional programming, with Noah as the first speaker, followed by Sam Blackshear and Eddy.

a16z Crypto Noah:

We want to understand how the history of programming has influenced the history of smart contract programming, because I think there are three things, traditional programming, smart contract programming, and Move language. All three of these things have their own history, right?

Sui CTO Sam Blackshear:

Yeah, I like that framework. People use languages to design syntax or make people happy, that's right, but it's more than that. So I like that big picture framework.

a16z Crypto Eddy Lazzarin:

Just on that basis, traditional programming has all kinds of trends over the last 20 or 30 years. Traditional programming languages have changed, and there are some hot topics that come and go. There was a long time when dynamic programming languages and very loose type checking were very popular. It was often thought that jumping in, forgetting types, forgetting all the technical details, and just writing code was a more ergonomic way.

Sam Blackshear, CTO at Sui:

But recently, people have started to think more deeply about things like type systems, static typing, and compile-time checking, to understand as much of the details of a program as possible before it runs. These trends keep changing. However, for smart contract programming, because it's so new, we haven't seen this type of history in smart contract programming, which is very different.

I think the Move language is the earliest evidence we've seen of how languages are designed to accommodate this (things like type systems, static typing, and compile-time checking). I'm curious to hear about what changes we can expect to happen, such as topics like static and dynamic typing that might come up in smart contract programming? These topics may not have come up yet because there is only one language, Solidity.

Moderator Sonal Chokshi:

So how does this tie into the move to smart contract programming? Sam again?

Sam Blackshear, CTO of Sui:

In this smart contract space, with EVM being one of the first entrants into smart contract languages, there was a different trend. People didn't know what they wanted to do with smart contracts? How do we write them or any of these types of things. So I think flexibility is more important to try to understand the type of experts who need to discover the use cases. I feel like now we know, or at least we have some understanding of the building blocks.

The trend in smart contracts is to be extremely domain specific, you define templates for assets, you define policies for transferring assets, you check access controls and permissions.

That's the basics, you don't write compilers or operating systems or any of those types of things in smart contract languages. So they're very, very good, their advantages over general purpose programming languages.

I think people underestimate that even though the ERC-20 standard happened long after the EVM could be programmed, the EVM was even considered one of the fundamental building blocks for writing Ethereum programs. I just don't see any obvious evidence that the most basic things were clear before that.

So you're right, now you can take types for granted. I think that the bypassing of types and these things is acceptable to have a certain amount of technical debt. If you're small and you just want to move quickly and the code can be thrown away, then this technical debt is completely acceptable. But what's interesting is that you frame it in terms of the size of a company or a startup, a small company that is growing quickly and everyone understands the entire code base, this technical debt is tolerated.

But when it's very, very large, there are a large number of people changing the code who don't know the consequences of the new objects and systems that they're building. Putting that into the type system allows you to write code in an explicit, direct way with barriers in place, rather than accidentally creating glass fences that someone will later run into.

For example, like you guys talked about, being able to prevent copying, being able to set a maximum supply of an asset. Those constraints are very important and need to be maintained no matter the size of the project. They're very important constraints to maintain the soundness and safety of the project. Knowing those boundaries means that you can now create programming languages that allow you to enforce them. That's how I think about the Move language.

As we understand the types of constraints that are needed to do the right thing, we now have the ability to include them in the language itself. So I do think it's somewhat similar to types, like you said.

You mentioned that types are very important for the soundness and safety of a program. You guys said that dynamic typing might be appropriate for small projects, but as your project grows, you should use static typing. I kind of disagree, and I think completely static typing might be a better fit. That might be a novel take. It's for programmer sanity. The scariest thing I've ever seen is when I hit my shortcut "control k" it tells me what the function signature is. That terrifies me when I'm writing Python. I look at the function signature and just see the names of the parameters. I'm like, what the hell do you want me to do?

a16z Noah:

I can't believe that people are accepting that code is written and never looked at again.

a16z Eddy Lazzarin:

They're accepting the default assumption that they can keep the requirements of the system in their mind.

a16z Noah:

But even for a 100 line program, I don't think that's the default.

Sam Blackshear:

It works, but it's not perfect.

a16z Eddy Lazzarin:

I think you're right. And I think that mentality has evolved. Previously, type systems were used to protect programmers from their colleagues. It's useful when your startup gets too big. But now it's more like protecting myself.

In the context of smart contracts, it's protecting me from attackers. That's the real difference, because in normal programs, you don't deploy programs where attackers are constrained by the type system. Attackers can write machine code in other languages. You just have to protect your own firewall. But here, I write this nice typed object that will flow into the attacker's code and maintain its integrity. The type system has to keep me safe.

Like you said, it's a great tool, and it gives you different requirements that you need to enforce, like preventing copying. That's not something you need to think about in a normal type system, or preventing deletion or making sure you use or destroy a value in a certain way. These are all because we're working on smart contracts and trying to provide a type system that makes sense for these use cases, so we'll eventually put these things into move and probably into future smart contract languages.

Moderator Sonal Chokshi:

Actually, guys, let's talk a little bit more about the other differences between traditional programming and smart contract programming. But before we go any further, can you guys just quickly cover the languages that smart contract programmers can use? I think we need to understand the big picture because I want to understand the landscape, like Solidity, Viper, etc. Knowing what's out there will get us started faster.

Sui CTO Sam Blackshear:

Yeah, I think the basic situation is that if you want to write smart contracts, you will almost always use solidity. Unless you happen to be in one of a few other smaller ecosystems.

If you are in the Polkadot ecosystem, you will use ink! (Sui World Note: ink! is a smart contract language developed by Parity for writing smart contracts in Rust and compiling to Wasm code), which is an existing programming language. If you are in the StarkNet ecosystem, you use Cairo (Sui World Note: Cairo is one of the programming languages for the STARK proof system).

But for the most part, if I were to give advice and let you learn how to write smart contracts, I would recommend that you learn some Solidity and then learn the EVM. You might also want to use Viper, the only downside is that Viper is newer and may be more prone to vulnerabilities. I remember a few years ago, when verifying the deposit contract, they found a bunch of vulnerabilities in the Viper compiler. The guy who found these vulnerabilities now works at a16z, and that's Day June, and he's a formal verification expert.

Day June now works at a16z because he's a formal verification expert. And the reality is, you need to learn some content, you need to learn some languages.

You even need to know the EVM to a ridiculous degree if you want to be a really good smart contract engineer,so that you can tell the gas cost of each operation, and they can tell you the exact code that's related to the gas cost. That's the world we live in currently.

a16z Eddy Lazzarin:

Maybe one thing worth mentioning is that as a software engineer, you always have to know about the machine that you're running your code on. There's a lot to know about the programming environment. But in smart contract programming, the environment is very rich and very complex. There's a lot of context to know, which is almost independent of the language itself. It's what's going on around you, what objects are around, how different code is called. This is a very strange thing.

Moderator Sonal Chokshi:

So is it true that the people who are closest to learning Solidity are those who know JavaScript?

Sui CTO Sam Blackshear:

Everyone says it's JavaScript because it uses the keyword "function", just like JavaScript. But unfortunately, they are not very similar.

a16z Eddy Lazzarin:

Syntactically, Solidity does inherit a lot of JavaScript features. If you squint or are in a bad mood, you may think it's similar, but it's actually completely different. The virtual machine environments are very different, so there are few commonalities.

Moderator Sonal Chokshi:

Are there any similar programming languages?

a16z Noah:

Yes, I don't think there are any directly similar programming languages. If you're familiar with Was (Sui World Note: WebAssembly Studio, an online tool for compiling C/C++ and Rust code to WASM format.), and trying to write code in an environment that requires a high degree of isolation (such as Surplus), this may be the closest, where the code is to be executed independently but requires a certain degree of communication. But it's still not very similar, the way of thinking is completely different, and the superficial similarity may be dangerous.

a16z Eddy Lazzarin:

Perhaps related are some major mistakes in the history of programming languages. I don't know if there is some bad history of going down the wrong path in blockchain. Have we gone down some terrible paths?

Moderator Sonal Chokshi:

That's a good question.

Sui CTO Sam Blackshear:

That's a good question. 1977, the year C was released, was also the year Standard ML was released. Standard ML was hugely influential. Now, there's OCaml, Rust, Move, which was heavily influenced by it. But these ideas have been around for a long time. I think a lot of people are thinking about an alternative future, where C doesn't become mainstream, but the ideas of Standard ML are widely accepted, like strong typing, built-in safety.

Moderator Sonal Chokshi:

So what was this trend in computer technology? I'm not saying it's a mistake, but I think languages like Standard ML look very modern even today. It's an interesting thing to imagine that alternative universe, and I was blown away when I first discovered it.

a16z Eddy Lazzarin:

Out of curiosity, why do you think languages like C and similar languages, which are so straightforward and so imperative? They think about computers at a relatively low level, and they don't do a lot as programming languages, which is how I think about C, why did we go down this path?

Sui CTO Sam Blackshear:

I think the hardware limitations at the time forced you to use C, and if you wanted to write efficient programs, or push the boundaries of computers, I think if you pushed the hardware forward, you would choose another path. But I think functional programming is hard, it's counter-intuitive in a lot of ways. I'm not saying C isn't hard, but I think it's easier to get into. And then you realize, I've done something really complicated or hard to reason about, but it's too late. That's a good point, functional languages do have a steeper learning curve, but once you get the hang of it, you realize that I can think about my code pretty well in isolation and things work out pretty well.

a16z Eddy Lazzarin:

I think if you think a lot about how computers work at a hardware level, then languages like C are more straightforward. But if you don't know much about programming languages, then C is easier to get into. But if you know programming languages very well, then I think there's more to explore with these types of languages like ML and functional programming.

Sui CTO Sam Blackshear:

That's a big picture answer. But I want to talk about the small-scale "computer language bug" problem.

a16z Noah:

So, I was a little hesitant about this because I kept hearing about how great functional programming was, but I found it a little hard to wrap my head around. But the question I always wondered was, if functional programming was so great, why has it never been able to overcome the network effects of current programming languages? It's been surprising to me.

But one thing I would add is that I think the big contribution that functional programming has given us is that all the imperative languages we use are borrowed from. But the best thing is, like you just said, Rust is very influenced by standard email, but Rust is fundamentally an imperative language, right? But it has all the wonderful fairy dust that comes from gazing at them.

Sui CTO Sam Blackshear:

In general, I think the real problem is that the influence of imperative languages has been too great since 1977. And then there was PRFP, which, as you said, wasn't the greatest, it had its own great ideas, and in isolation, each had its own problems. We're only now seeing real hybrids like Rust marrying them beautifully. It's really changed the landscape.

So one thing I would like to mention is what Tony Hoare called the billion dollar mistake of node references. While he was probably trying to be hyperbolic at the time, it's obviously more expensive than not making that mistake.

a16z Eddy Lazzarin:

No, that's probably just the lower limit.

Innovative Development of Smart Contracts

 a16z Noah:

I'm actually curious that you didn't talk much about innovations at the VM layer and the programming language layer and how they affect the development of smart contracts.

Sui CTO Sam Blackshear:

That's a great question. I think people don't think enough about these distinctions, like the VM layer and the programming language layer. In fact, in addition to the EVM and the new VM layer, there are a lot of innovations, such as source code languages like Viper. These things are better than Solidity in many ways and are also very interesting.

I think that if Move is going to become the de jure standard for Web 3.0 that we expect, then innovation at the VM layer will be slow and incremental. Because the core is fixed, we will only add new things and not completely redesign.

However, I think innovation at the source code language level will be quite important. Right now, we only have one source code language, but it is tightly coupled to the bytecode format. However, as more and more clients use smart contracts, and emphasize security, I can imagine that there will be a lot of different source code languages to try, which is an interesting area of research. Maybe you can write down your previous facts first, and then synthesize their information for you in the program, or suggestions for limitations.

Maybe you can start with the facts before you wrote your Move, and then have the synthesis program fill in the program for you, or suggest restrictions.

For example, maybe you're writing Move in a very specific context of a game that looks like a scene hierarchy. Maybe it's written in a Python library, but compiled to Move's bytecode. Maybe you're thinking about integrating Move, like Solana or other platforms, but don't want to integrate a virtual machine, but instead compile Move's bytecode to Salina's bytecode format and then use Move source code language at the developer level.

I think there are a lot of different approaches, just like the JVM (Java Virtual Machine). The JVM is a wonderful general-purpose virtual machine that originally only supported Java. But it's stood the test of time, and now you have Scala, Groovy, and some other interesting ways to use these primitives to design different programming experiences that are very consistent with what people want to do.

So, I have a biased view that Viper can give you a lot of room to experiment at the source code language level.

a16z Eddy Lazzarin:

What do you think of all the alternative EVM bytecode languages? There are interesting efforts like FE, Iron, and Viper to build smarter, more sophisticated languages for the EVM, are you optimistic about that?

Sui CTO Sam Blackshear:

So these are all different source code languages that compile to EVM bytecode.

a16z Eddy Lazzarin:

Yes, compile to EVM bytecode.

Sui CTO Sam Blackshear:

When we started designing Move at Facebook, we looked at other source code languages to build EVMs, and we looked at Solidity and Viper, which was when we started building EVMs. We ultimately concluded that the hardest problem for people to write secure smart contracts is the underlying nature of the EVM, and how to get typed values to flow across trusted boundaries, and dynamic decision making, and so on, which are all features of the EVM.

If you build a better source code language, you can make it harder for developers to screw up. Maybe they can do more advanced verification, but ultimately, what Move is able to provide, and we think is important, is code verifiers and VM-level protection from other programmers.

Source code languages can't give you that, it has to be built into the VM, and no matter how many times you iterate on the perfect source code language on the EVM, I think Solidity is great and we can do better, but I think if you don't have these basic protections built into the VM, the result you get is ultimately inferior to some of the other paths. I'm not embarrassed because I think Half is cool, but because I think the end state is less attractive than other paths.

I think early smart contract languages, especially the EVM, were overfitted to the implementation details of the platform, which were designed for Ethereum, and internally included instructions about transaction structure, account structure, using specific types of cryptography, and so on.

I think this makes it very difficult to use the EVM on a chain that is not like Ethereum, and you end up having to inherit a lot of the design decisions that Ethereum made, and maybe in some cases, some of the bugs that made Ethereum hard to scale.

When designing Move, we were very conscious of not putting anything blockchain-specific into the core language, and making it as blockchain-agnostic as possible.

So that you can take Move and use it on a proof-of-work chain with a crazy transaction structure, and one chain might be doing this in Sweden, and another chain is doing this in Australia. That way, you don't have to bet on one specific chain to be a Move developer. You can use your skills across a variety of different chains, including future chains. We think this is critical to the survival of a smart contract language because a language's greatest asset is its community. And by making your skills cross-platform, rather than being overly specific to one language, you can scale the community and be better positioned for success. And then a big community is what makes it possible to invest a lot of money in tooling, invest a lot of money in common libraries, and all the things that you really need for a language to be big and successful.

That's something we've tried to do from the beginning, and now we're seeing multiple really different Move chains that are very different in how they integrate the language.

a16z Eddy Lazzarin:

This is a theme that's underlying node.js, in my opinion, right?

Moderator Sonal Chokshi:

Yeah.

a16z Eddy Lazzarin:

There are a lot of people who know JavaScript and they want to do a lot of things. They want to share all kinds of libraries. Existing code can spin up server-side JavaScript instances, which makes node useful. That means there are all kinds of developers who might not do backend programming but can start to come in and make it their own.

Sui CTO Sam Blackshear:

I think that's a great comparison. Also, we want to talk about the governance of programming languages because Node obviously has some very high-profile governance disagreements and splits, and every programming language community has many high-profile governance disagreements and directions. I've covered Node in the past and it's one of my favorites. But I want to make sure we finish this topic. Anything else to say? I feel like you're the resident fogy guy on our radio show, and I love that.

a16z Noah:

So I have a counter-argument, or I have a cool idea. I've been wondering why nobody has built an OP Rollup for Move, that would be really cool, considering the OP Rollup people are implementing on Ethereum, they use MetaMask and ECDSA signatures, but don't seem to be using the same signature format as us, like Move doesn't seem to be using ECDSA.

Sui CTO Sam Blackshear:

Yes, we support Ethereum's EdDSA and ECDSA signature formats.

a16z Noah:

That's perfect, but my point is that you could build something really interesting. But when I was trying to learn Move, I kept staring at desserts and actor dogs. I was confused.

Sui CTO Sam Blackshear:

It's a problem, right? When someone starts learning Move, they might be confused: I'm learning the smart contract language, but where is the blockchain? The differences between them also create problems if you try to write code for both platforms. So I think the challenge we're still working on is, pick a platform, pick a sweet spot, pick an Optus, learn it in depth, and then you'll find that your skills and your code can be easily transferred to another platform. I think there are some inherent problems here, and there are some documentation issues that need to be addressed to make this easier.

a16z Eddy Lazzarin:

Maybe an analogy, depending on whether you think of SQL as a portable skill. There are a lot of SQL dialects. There's an anti-SQL, where nobody really knows what it is, but they can learn SQL, and if you squint a little bit, you can use any database, maybe a little confused about specific function names or specific types, but it's roughly the same shape. I think that makes SQL powerful and durable. That's why it's still part of the lingua franca of data. Maybe that's the future of Move. I think we can do a little better.

Sui CTO Sam Blackshear:

I think that's a good goal in terms of being cross-platform, very application specific. That's the right language to talk about tables and to talk about databases. That's an indisputable fact, and that's why everyone uses it. So I'd love it if Move could be the SQL for blockchain.

Unique Things About Smart Contract Programming

Moderator Sonal Chokshi:

We've been going back and forth around traditional vs. smart contract programming, specific constraints and differences, and even some of the similarities between Tread and smart contract programming. Are there unique things about smart contract programming that we didn't cover?

a16z Eddy Lazzarin:

Another very important thing in the context of smart contracts is resource usage, like Gas Metering in Solidity. While in many cases, computational resources are relatively abundant and computational cost is very important. But outside of the context of smart contracts or outside of the context of blockchains, that means it's just been covered and considered less. I think the concept of what resources you consume in the language could be an interesting resource for smart contract programming.

Sui CTO Sam Blackshear:

This is something we are very concerned about. We built Gas Metering into EVM, which is very different from traditional programming languages, as you said.

I think the trend in the future is that Gas Meeting will become more and more coarse-grained, more to prevent serious problems such as resource abuse, rather than really calculating for each instruction.

I actually think that things like Gas Golfing, while very fun, are actually very harmful to both coding style and security.

Ironically, the reason we only know about the per-instruction model is probably because if you have a huge virtual machine, the difference between running 100,000 instructions and running 500,000 instructions is negligible when it comes to actually measuring runtime.

So why do we charge per instruction? So I think we'll see a trend towards how to make this more coarse-grained.

Every time I see all these unsafe blocks and lots of inline assembly in Solidity code, it reminds me how early we are now, because this is not a programming challenge that smart contract developers should be thinking about, and it's not a sign of a mature development ecosystem. But we're moving in that direction. I agree that we need to think about the edge cases. Choosing the right algorithm, choosing the right data structure, choosing the right general approach, which is the case with most software engineering, is important. But trivial questions about exactly how much each instruction costs can be too much.

Moderator Sonal Chokshi:

We talked about optimizing gas, types, assets, and security. What other constraints are there to consider?

Sui CTO Sam Blackshear:

This is a similar thread to gas, but the specific subset I think of is state. That's a big one for me. When I think about gas operations, I like to do extreme gas optimizations.

But when we're dealing with actual smart contracts that hold real money, my general advice is that unless you can go to great lengths to use slightly less state than you were using before, you should make reasonable arrangements. That's the only time I would use big assembly blocks, if you can do something stupid to use less state, because it's like a forever resource, and we should put it just above execution or call data.

a16z Eddy Lazzarin:

I totally agree with that, because I think this is the fundamentally expensive problem. If a platform allows every contract to touch any piece of state, it's going to be very hard to parallelize. And the approach that Squeeze and some of the new blockchain platforms are taking is to explicitly limit the state that transactions can access, at least to the extent that I know of. That makes it easier for the platform to parallelize transactions at a high level, both execution and consensus. So that's something that some programmers have to think about: be as fast as possible when accessing state, and don't touch unnecessary state, so that validators can parallelize more effectively and achieve more block space.

a16z Noah:

Does this open up a world where not all validators need to download the entire state, even in non-role-playing situations? If you can easily separate the state and have a validator only serve transactions that it can handle, is this possible?

Sui CTO Sam Blackshear:

I think it is indeed possible to achieve such a world. This also opens up a path for different approaches.

Let me recap that from a programmer's perspective, being able to reach the entire world across different transactions is very valuable. However, we can't emphasize this advantage so much that we have to do it through Rollup or across multiple transactions, because this will reduce security and make users notice.

I think the value of blockchain comes from this abstraction: there is a ledger, all valuable states are on this ledger, and I can reach them all at once. From a programmer's perspective, this is the value of blockchain. The question is: how can we make things more efficient behind the scenes? How do you make it more sparse so that validators can parallelize more efficiently? In Sui, a validator can have multiple workers, each responsible for a portion of the state. But from the programmer's perspective, and even from the perspective of other validators, it looks like one logical entity that does everything.

This makes it easier to store, execute, and do things without having to code these things into the protocol level and have users and programmers think about them.

Changes in Mindsets for Smart Contract Programming

Moderator Sonal Chokshi:

We just talked about some of the unique things related to smart contract programming. What are some other changes in mindset? We've talked about some of them, like Eddie mentioned, a big shift is that in the world of programming, at least since the early days of computers, we were in a world of abundance, but in this world, we are in a world of constraints. That's an example of a mindset. What are some other changes in mindset? For each of you specifically, as programmers in your introduction to smart contract programming, what's something that surprised you or taught you or made you think differently about certain things?

a16z Eddy Lazzarin:

Maybe a slightly silly example is, I remember a few years ago when I first learned that the balance of an ERC-20 token is not something that your account has. Your address does not have a balance of tokens. Instead, there's a token contract that keeps track of which address has how much balance. When you want to transfer tokens to someone, you don't send them some tokens. Instead, you go into the contract and do all these low-level operations that change the balances held by your address and their address. You have permissions to operate and change that contract. It's a very counter-intuitive way that this was an interesting mindset shift that first caught my eye in the EVM and Slippery about Move. It's an interesting mindset shift because the English words that we often hear don't necessarily correspond to programming models.

Sam Blackshear, CTO of Sui:

I want to add that this is about when you're actually doing it. In the normal world, we focus a lot on developer productivity because the job of an engineer is to write a lot of code that has only a few bugs and those bugs are not too serious. In the smart contract world, your job is to write a very small amount of code, and it has to be perfect. It has to be perfect in every possible way. Otherwise, you will lose hundreds of millions of other people's money. It's a completely different mindset shift. Spending two months staring at 1,000 lines of code and trying to figure out how to make it better and, more importantly, how to make it perfect, and then the auditors have to do the same job and judge whether it's perfect.

Moderator Sonal Chokshi:

This is a big mindset shift. In the world of programming, we've been in a world of abundance since at least the early days of computers, but in this world, we're in a world of constraints.

a16z Eddy Lazzarin:

Another shift in thinking is that in the world of ERC 20 Tokens, your address does not have a token balance. You cannot send tokens, you have to access the token contract, find the token balance corresponding to the address in the token contract, and then complete the token transfer by modifying the address and balance. This is a counterintuitive way of thinking, but it is a very important shift in thinking in EVM and Move.

Sui CTO Sam Blackshear:

In smart contract programming, your job is to write a small piece of code, and it must be perfect because this code may involve the security of funds of hundreds of millions of people. You must carefully review the code to ensure the correctness of the code.

In addition, upgrading smart contracts is more difficult than upgrading mobile apps or websites because in smart contracts, the code is immutable. In smart contract programming, you must consider how to support secure upgrades and trust to make it look more like a traditional ecosystem.

But in smart contract programming, you need to have an adversarial mindset, which may be unfamiliar to people from other fields. This is because in the deployment model in smart contracts, you need to consider not only the expected use of your application, but also the unexpected use. Because in traditional programming, there are ways to hide yourself, limit yourself to a small API, or use firewalls to limit the attacker's actions, etc.

But the whole point of smart contracts is that what you do can interact with code that you never imagined, and you can do it safely. So you need to think about the pros and cons of that. It's definitely a mindset shift relative to traditional programming.

Moderator Sonal Chokshi:

Is this a very important question and one that should be a priority when we discuss how to write smart contracts and use smart contract programming languages?

Sui CTO Sam Blackshear:

Yes, absolutely. It's actually my favorite thing to talk about. It scares me very much that the issue that smart contract language designers need to think about is security. That's the main focus, maybe even the only focus, until we solve this problem.

I think smart contract security is an existential threat to broader cryptocurrency adoption. The reason I say that is, you can look at Ethereum and solidity, and the most popular platforms EVM and Solidity. You can look at the early programmers who wrote this code, they were very highly qualified, really understood the underlying blockchain, were very security conscious. They knew what they were doing. And I think they took very seriously the responsibility of writing code that governs hundreds of millions and billions of dollars.

But if you look at the smart contract security record anywhere, it's very abysmal, and that's not these people's fault. I think it's a very difficult problem. And I think the language makes it even more difficult. So if you look at my favorite site, rakt.news, you can look at the leaderboard or look at these ten hacks worth tens or hundreds of millions of dollars, and these hacks are very routine, happening on a weekly or monthly basis, depending on the size. At the same time, the smart contract developer community is very small, only about 5,000 full-time EVM programmers, which is very, very small compared to the traditional developer community.

So if you believe that the people we have are the most hardcore and security focused people out there, but the development practices and security record are unsustainable, then I think your conclusion is that there is no way for this space to continue to grow without making the security issues worse, which could mean it doesn't grow at all, or like large financial institutions or companies that want to get into Web3 are looking at, do they have to hire smart contract developers? I'm going to get hacked for tens of millions of dollars and get nervous. This is only going to get worse over time. They're probably going to stay on the sidelines. So as someone trying to design a new smart contract language, security has to be the first thing you consider.

Moderator Sonal Chokshi:

You guys have hinted at this actually in the context of not losing your assets, but what do you mean more specifically because it's so important?

Sui CTO Sam Blackshear:

What I mean by security is that we both prevent programmers from stepping on themselves, but also provide them with the right primitives as much as possible so that they can defend against attacks because smart contracts are a setup where your code is deployed next to an attacker who can directly call your code, can directly link to it. Your code is open source, or at least the bytecode is open source.

This is by far the most adversarial programming environment that we've ever seen, and the cost of getting it wrong is the highest. So I think if you're talking about smart contract programming design, security must always be at the forefront. Once we solve the security problem, we can think about other more expressive factors, but this is my somewhat boring, but I think very important answer.

a16z Eddy Lazzarin:

What features can affect security? What are some examples of this?

Sui CTO Sam Blackshear:

I think the most important one is encapsulation, specifically, the sub-features of encapsulation. When you write code, you can't predict what an attacker will try, so you need to be able to reason without foreseeing what the attacker will do. So, you need a strong type system, not only at the source code level, but also at the bytecode level, so that the guarantees you get when you write the source code will continue to hold when you publish the code to the blockchain and others depend on it and interact with it.

We observed that some features that are popular in other fields are inherently inappropriate in smart contract programming, such as dynamic dispatch.

In traditional programming, things like interfaces and dynamic dispatch are key abstraction mechanisms and are ubiquitous. You can define an interface, and then someone else rewrites that interface with different logic, and then you can program against that interface, and everything is great. But we have a quip: "In a world where code is law, interfaces are a crime."

a16z Noah:

That's a joke, let's stop for a minute. In a world where code is law, interfaces are a crime.

Moderator Sonal Chokshi:

Before you go on, could you explain that statement a little bit more? I don't want to jump past it too quickly.

Sui CTO Sam Blackshear:

Yeah, exactly. The idea here is that an interface doesn't define behavior, it defines expected behavior. Like, when you read the specification of an interface, the parameter names and even the types, it tells you what you want to accomplish. But there's no guarantee that it's going to happen.

So, if you write code that's supposed to protect something, but you're actually leaving a blank check for an attacker, for someone else to fill in. That seems like a crime in contract law. It's an unspecified contract. I like this feature a lot, and it's popular in traditional programming languages. But we think that in smart contracts, this leads to a lot of different problems. For example, reentrancy requires dynamic dispatch. For example, if you take away dynamic dispatch, there's no reentrancy at all. Things like poison tokens in Ethereum happened because you overwrote the transfer function and everyone knew intuitively that it was just for transferring money and maybe didn't do anything else. But now you made it do something unexpected, like steal money. That's an example of a feature that, if removed, makes it much easier to reason about your code and have proper encapsulation because every time you see a call site, you know exactly what it's going to do and you don't have to worry about other people doing something that surprises you later.

a16z Eddy Lazzarin:

Exactly, I think the analogy is like if you define an interface about a chair, that it has four legs and a seat, you're describing the concrete aspects of it, not the behavioral aspects, and you're not describing other things about the chair that might be implicit or tacit, like it has some kind of structural integrity, it's made of a certain material, it's laid out a certain way.

a16z Eddy Lazzarin:

can be circumvented, which means the interface is just an arbitrary set of descriptions that don't capture the security constraints you want to enforce.

a16z Noah:

That's exactly the definition.

a16z Eddy Lazzarin:

Defining things at the wrong level. I'm curious.

Sui CTO Sam Blackshear:

But how do you modularize well outside of interfaces? If interfaces were a crime, I'd probably be a criminal because one of my favorite ways to build complex smart contracts is like have different contracts with different purposes. And especially in very complex systems where you have a module-based foundation where the modules adhere to some sort of interface and then the main contract can know how to call different modules. And those modules are often permissioned through governance, how do you get super expressive plug-and-play modularity? No standardized interfaces? How do you get inheritance?

a16z Eddy Lazzarin:

All these things to do with interfaces like?

Sui CTO Sam Blackshear:

That's exactly the right question to ask. They can argue against this all day, but how do you provide something that lets you write useful code? Like if you're not allowed to walk out of the house or something like that, there's no crime. But the way we do it is, interfaces and inheritance aren't the only way, I tend to think in terms of composition. We provide several composition primitives that don't require a dynamic dispatcher interface.

One of them is generics. We have runtime inheritance that looks a lot like what you have. CLR (Sui World Note: common language runtime, common language runtime) Let me give a very concrete example, otherwise this gets abstract very quickly.

Something like your ERC-20, which is obviously a fundamentally important crypto standard. If your platform, your language can't do this, then it won't be of much use. In a language like Move, you define a type point called t, where t is a generic type parameter, and then you implement functions for coin, for example there's a function for joining 2 points together. That applies to all coin types. That's not something that someone would want to override. You define splits.

When you want to let someone customize the behavior of a token, you use what's called the capability pattern, for example for a token, one of the things you might want to customize is what the total supply is, or more fundamentally what its policy is? You can express this like this: Okay, you have a point struct of type "t", and then you have different instantiations of t, like dollars, pounds, or whatever other currency type. For the things you want to customize, you provide it at the capability level, a function that creates a token. You say, this is the type parameter of my token, and then it gives you something called a "treasury capability." Then there's other logic that makes sure that only people who hold a treasury capability for t can mint and destroy tokens of type t. You can take this treasury capability and lock it into a different contract to enforce a limit on total supply. You can put it somewhere and say only comment on Tuesdays, but not on Thursdays. You invert the control flow, and that allows you to do any combination. This is an example of a trick, but this trick can be used almost everywhere, if you want the behavior to work a certain way, you need to hard code it. It sounds bad, but you implement specific two methods, and then you define these capabilities for the things you want to allow.

a16z Eddy Lazzarin:

Do you think capabilities are constraints that you can add to an interface that looks like a traditional programmer?

Sui CTO Sam Blackshear:

Yeah, I think most of these interface patterns can be very straightforward variants. It's a little harder to compile, but you can say, here's the equivalent capability pattern for what this interface wants to do.

Moderator Sonal Chokshi:

By the way, Sam, do you feel comfortable with that? Feel free to disagree, a little conflict is good.

Sui CTO Sam Blackshear:

I think that's pretty satisfying because I think if you can have modules or structs that have intrinsic capabilities that can be fed into modules that have very predefined behaviors, you can end up with exactly the same behavior that a module can do. The module takes in an abstract struct that's defined in that module, and then that struct has an intrinsic capability inside it. This actually works really well because you can get really nice permission style registries that almost naturally flow out of that, like what's called the DS-Off registry is like, right?

a16z Noah:

Exactly. These capabilities are extensible representations of what you're allowed to do. So there's a lot of other benefits to this. For example, if you want to know what my account can do, you can look at what capabilities I have. And then you can do program analysis and see what functions I can call if I have a treasure trove capability, and other things like that.

Object-Oriented and Asset-Oriented Programming

a16z Eddy Lazzarin:

So I may have gotten a little ahead of myself about the prover, but are these capabilities visible to the type system? At what point in the program are these capabilities visible when you're doing static analysis on the program? If I wrote some code for a particular instantiation where there are capabilities, would it be possible to find out very early on that I've violated the capabilities, before I even run it?

a16z Noah:

Yes, these capabilities are visible to the type system and are visible during the static analysis phase of the program. If I wrote some code for a particular instantiation where there are capabilities, would it be possible to find out very early on that I've violated the capabilities, without having to run it on a virtual machine.

Sam Blackshear, CTO of Sui:

Let me answer that question briefly and then give some background on that, they are visible to the compiler and they are part of the type system. That's a very important point that we exploit. But I want to talk a little bit about structs in the Move portability system and how that ties into the capability hierarchy of something like auditing. If that's not distracting.

In Move, you have struct types and structs similar to other languages, they can have fields, they can be fields of primitive types, they can be other structs. What's more interesting and maybe more different is that these structs have capabilities. If you're familiar with Rust, capabilities are kind of like token transactions. They declare the built-in operations that you're allowed to do on the struct.

Equally important, if you don't have the capability, you can't do those things. One of the simpler capabilities is very important, and that's the ability to copy. If you have a token type or something like a non-fungible token, in the computer, it's just a bunch of bits, but you don't want to allow people to copy that thing at will.

In Move, if you don't declare your struct to have the ability to copy, then you can't use our equivalent of "man copy".

So things like integers and strings have copy. But if you don't want your type to have the ability to copy, then you don't give it. And then there are other abilities, like discarding, which is called the drop ability. This gets into the interesting linear type stuff, where if you want to discard something, like put it out of scope, or overwrite it, then you give it the drop ability. But if you don't give it drop, then the only way to get rid of it is whatever policy the module that defines the type expects.

Common Language Runtime (CLR) To give a specific example, if you want to keep a total supply for your token, you don't give your token the drop ability. Then there's no other way to get rid of it except for the burn function defined in the module that declares it, which updates the total supply. These are all tricks you can use. There are a couple of capabilities related to storage, like whether it can be stored in global storage, which I won't go into because they're not very relevant to this question. But basically, the capabilities are baked into the auditor, and the auditor understands the type system and knows how to use the type system to solve problems. If I write a statement that says there is only one such thing, then the auditor can use this to prove that property. So the capabilities and the guarantees of the type system go hand in hand.

a16z Noah:

When you mentioned drop, I just wanted to talk about one of my favorite things. Can you talk about what the hot potato pattern is? If there are other cool things like that, it's one of my favorite weird things that came out of Move.

Sui CTO Sam Blackshear:

That's a really weird thing. This is very closely related to power. Often in programming languages, you don't have a lot of control over when you can destroy your value, maybe you have a destructor that says when your value is gone. But sometimes the destructor guarantees are weaker, or you can't just say something like "You can't delete my type." It sounds like a weird restriction, but it's actually very powerful, especially in the absence of dynamic dispatch.

Let me start with an example of a hot potato, and then we can get into things like flash loans. If you do a flash loan on Ethereum, it's a standard that you can override and basically you expose a callback function, like a flash loan contract, you give me money, my callback function then takes the money back or something like that, whereas in Move, the way you do it is somebody goes to the flash loan contract and they say, "Hey, give me 53 bucks, but they also give you what's called a hot potato object."

The hot potato object is a struct, it has no capabilities. It has no copy, so you can't copy it. It has no global storage capabilities, you can't just stash it away like you can put it in a contract. It also has no drop capability, so you can't drop it. So the only way to get rid of it is to pass it back to the flash loan contract. The code of the flash loan contract that makes you pass it back to it forces you to pay it back. If you don't pay it back, its program will fail at runtime and won't even pass type checking. So this is taking advantage of the interesting ability to control the destruction of your values, as a programmer, to impose arbitrary invariants at any time to decide when these objects can be destroyed. These look a lot like API call patterns are very explicit. Another very obvious example is if you want to force someone to call unlock after calling unlock. lock, but you can do whatever you want in between, and you can do it this way, too.

a16z Eddy Lazzarin:

When I first heard about the "hot potato" pattern, I thought of interesting uses of locks like "mute texas" that were just for ergonomic purposes, leveraging the type system to enforce certain ways that objects were used, almost at a business logic level. I think that's very clever, feels very modern, and is a high-quality use of ergonomics in programming languages that's not even very common in traditional programming languages yet, but is obviously very valuable in the context of smart contracts, where there are more logical requirements to consider the value and safety that might be involved.

Sui CTO Sam Blackshear:

Before we talk about any specific examples, could you just give us a quick high-level overview of our object system? What are objects, who owns them? How do objects own other objects, and how do modules work with them?

a16z Noah:

Yeah, exactly. This is about a dialect of the Move language, specifically Sui Move. The foundation of this thing is a different structure for global storage than the global storage scheme that we used to have with the original Move dialect. The original Move global storage scheme was very similar to the corporate model that Ethereum uses.

In Sui Move, we want to put the central point of things on objects, with a high incentive to be able to express fine-grained access as precisely as possible. This helps you do a lot of things that we won't go into detail on this podcast, like processing transactions more efficiently, telling wallet users what a transaction is going to do, and so on.

So in Sui Move, the structure of the global store is a map from object IDs to object IDs. And then objects are just Move structures that have a capability called a key. It says, "Hey, I can be a key." It can appear in the global object pool. And then every object must have a globally unique ID. And then you can write entry point functions for your modules, and they can just take objects as input. If you're writing a transaction, this WeRunTime has the object IDs. If you're writing a transaction, WeRunTime is able to use those IDs to resolve the IDs into objects and plug them into the functions.

This object-oriented and asset-oriented programming experience is great. It's much more direct than what we did in the original Move version. You also mentioned parent and child objects and object hierarchies. That's very useful, but you still want to be able to represent things like large collections.

For example, I'm building a registry similar to DNS, and I want to have millions of entries. We have an object size limit, an object can be a few megabytes, but no larger. But if you have something like DNS, it should be arbitrarily large. The way we represent that is using parent-child object relationships, where we basically have a way of treating an object as a heterogeneous map. And then you can add keys that have dynamically selected fields. It's very similar to JavaScript in a way. We can say, this object has a map in it, and then I can put something in this map. Or you can say, when I define this object, it has ten fields, but I actually want to add a new field later on, and I'm going to upgrade my contract. I want to add a new field after the fact.

The way we represent it is using these parent and child relationships, and each child object is associated with a key value, which can be any Move value, like a string or a u64, or whatever else you want.

a16z Noah:

Yeah, related to the concept of parent objects, I think the thing that made it really become a "light bulb moment" for me was actually a few months ago I spent time digging into Sui Move and went from writing a program with just one object all the way up to reimplementing most of the Uniswap V2 style card deck. A little project I did that really made me realize how valuable objects that own objects are. This project had just three objects, a lock, gold, and an empty barrier. There was a very basic module that you could imagine that created gold that was owned by a key object. And then the only way to get the gold out was to have a function that took the lock and the key and obviously destroyed the lock, gave you the gold, and then destroyed your key. This was a very interesting way to describe relationships between objects and describe permissions in a very fine-grained way. Sam Blackshear, CTO at Sui: That's exactly what we're thinking about. I like the way you describe the nesting of three different objects because it becomes more powerful as you go deeper. It makes it easier to structure as a programmer to make sure I can get to the second level and then I can reach the third level, but I can't get to the third level directly from the first level. I think it also makes it easier to understand for programmers who are coming from outside the smart contract space, like these people are very familiar with writing object trees, DOM object trees, if you're a game programmer, everything is a scene hierarchy, where there's a character, they have an inventory, and then there may be some little things in the inventory. You can encode these things very directly in Move, and then the type system allows you to set up this access control in a very direct and safe way. I think it's a very practical programming experience that really reflects intuition about the real world, or how to describe something, and then directly translates into the relevant code.

Move vs. Solidity Security Comparison

Moderator Sonal Chokshi:

By the way, before coming to Wired, I spent 6 days at Xerox Park, and it reminded me a little bit about the history of object-oriented programming. What you just said is super interesting because they invented Smalltalk, which is an early predecessor to many of today's object-oriented frameworks. Anyway, are there any other topics you want to discuss?

a16z Noah:

I just have a general question, but are there any hacks and so forth that have happened in the EVM world that you think would not have happened the first time around if Move was used, because of the type system.

Sui CTO Sam Blackshear:

In the EVM world, we've mentioned dynamic dispatch and reentrancy, and Move eliminates reentrancy by construction, and any issues with reentrancy go away, and I think people have done a good job of that. Now, I think it avoids react and look.

a16z Eddy Lazzarin:

But can you explain a little bit more about why Move would make those issues impossible?

Sui CTO Sam Blackshear:

Reentrancy, right? What happened? You write some code, and it calls a function. The problem is that someone provides an implementation of that function that you didn't initially expect. In order for that to happen, the function call has to be dynamic. It has to call code, which is basically a function pointer provided by the caller, which could be an attacker. If you don't have any dynamic function calls, if you always know the target of a function call, then this simply can't happen, like anything you call, you may not know what the code does, but you know what it is, you can test it, you can verify it, everything is there. So fundamentally, it's impossible for someone else to provide code that makes your module behave in a way that you didn't expect, because it's just a static function call. That's pretty cool.

a16z Eddy Lazzarin:

So this eliminates reentrancy attacks, which has been a perpetual problem in Solidity development.

Sui CTO Sam Blackshear:

Yeah, I think Move basically eliminates the problem of missing permission checks in smart contract programming. There are times when you write some code where you have to explicitly pass all the accounts around, and you have to say, do I have the rights to do this. You write a simple code, but forget to check if the sender is a certain person, or if this person has access to it. I think these problems happen quite often.

So in Move, the object ownership information is actually stored in the object metadata. It's not something that the programmer can control.

When you look at these objects, they say, "I'm owned by this address," or "I'm owned by this other object," or "I'm a shared object," or "I'm an immutable object." The programmer can't forget to check who owns it because the runtime will do that before executing the code that passes in this Sui object. The runtime says, "I see this exchange, and I see all the objects they want to use. I'm checking to see if they actually own these objects, or if they have an object that can mediatedly own them so that they have permission to use them."

A lot of the permission checks that we ask programmers to do end up happening in the We Run Time, and those checks are impossible to forget. I think that's really important because the hardest things to protect are the specifications that the programmer doesn't tell you about. Those specifications are easy to forget, and they're hard to catch using static analysis or other methods because you always need some human to determine which specifications are important.

Moderator Sonal Chokshi: By the way, in terms of long-term planning in the far or near term, what happens at enterprise scale when people collaborate more in this way, I think that's going to be very interesting because it's obviously distributed, it's not just one company, sometimes people collaborate. But I mean, when you think about the old way now, you have like developers and all these best practices and all these approaches. And then you have these very different ways of thinking about doing things, and we haven't fully formalized all of this in this world yet, it's still early, but I'm very curious what that kind of thing will look like. a16z Noah: Right now the tooling for the EVM is pretty good, so what about the tooling for Move? Are there any major changes that need to be made? Sam Blackshear, Sui CTO: I think our tooling is still in the very early stages. We are working on a package manager that can be used across chains, like Create.io or npm. Move The model system of Move is very suitable for this kind of thing, and we are working hard to achieve this goal. This package manager allows developers to easily share their code, which is difficult to do in Solidity because in Solidity, code can only be shared by copying and pasting.

We are also focusing on the development of correctness tools in the early days. We have a lot of such tools, but I think we still have a lot to do to make them easier to use. We have a unit testing framework and we can write tests directly in Move. We also developed a Move prover to assist us in formal verification.

The Importance of Move Prover

Moderator Sonal Chokshi:

Can you briefly talk about formal verification and why Move Prover is important?

Sui CTO Sam Blackshear:

Formal verification is challenging and usually requires experts or PhDs to use. We are working to promote it to every everyday developer without the need for expertise.

It is not clear whether this goal can be achieved, but we have seen some promising projects. For example, recently someone submitted all the specifications of a smart contract into a single file, and then only needed to write specifications for new functions, which made formal verification very easy. However, there is still a lot of room for improvement in formal verification, including improving ease of use and powerfulness.

There are also tools like fuzzers, which are not as good as formal verification, but are very helpful for some important correctness checks, especially when you need to write some very complex code. We also have some academic libraries developing these tools. In addition, we are also working on how to make writing programs easier, such as supporting more integrated development environments, program synthesis, and artificial intelligence.

Moderator Sonal Chokshi:

How to use Move Prover? What if I want to try it?

Sui CTO Sam Blackshear:

First you need to get the program you have tested. Verification is not a supplement to testing. Then you can write something that is difficult to test or difficult to check. This may be some simple function pre- and post-conditions. For example, if my function input meets this condition, then the output should meet that condition. You can also write data invariants, like if you have a counter and you want to prove that it always increases, you can write a specification that you attach to the counter structure to check if it holds.

It then looks at all the functions and makes sure those specifications hold. There are more advanced uses, like global storage and variables. You might want to say there's always only one of this object, or there's two of this object, then there's three of this object. And the relationship between the fields of this object and the fields of that object. These specifications are very application dependent.

The Move language can save you from a lot of basic mistakes, but there will always be some correctness conditions that are specific to your application for you as a programmer. Specification languages make it easy to write those conditions after you write your code, or in some cases even before you write your code, and make sure they hold for all possible executions of your program and all possible function calls.

So now, the specification language is integrated with the compiler, so you can pull it up in any of these modes and try to use it. It's also integrated with the build system. You just do move build -prove and it will check these specifications.

a16z Noah:

Cool! Can Prover understand the Sui object model and the Sui transaction system? Like, can I prove something about something that might modify global state across transactions?

Sui CTO Sam Blackshear:

It doesn't fully understand it yet, but it doesn't need to. For example, if you want to prove that a counter is always increasing, that's a Sui object, but it doesn't need to fully understand Sui to prove that. Even in the core Move prover, it really thinks at the level of objects and global storage, not at concepts like transactions. So today it really can only think at the level of functions and transactions, and that works fine. But I think we might do more on Sui in the future, especially around parent-child relationships and heterogeneous object mapping.

Governance of Programming Languages

Moderator Sonal Chokshi:

Can we talk about governance of programming languages? There is a long history of programming language evolution, but in the context of blockchain and cryptocurrencies, the topic of governance is obviously more important because there are many other aspects to consider, such as decentralization, open source, distributed communities, tokens and economic assets, which are sometimes involved as part of incentive programs.

a16z Eddy Lazzarin:

Especially because they are open source and can be used in many different contexts, they are considered public goods, but they are different and require design and attention to detail. How should programming languages evolve? There are a lot of programming languages today that seem to have different governance styles, such as the first two that come to mind are the C++ committee and the WG21 committee, and there are some very complicated names.

And then something like Python, which has Guido as its benefactor, has a benevolent dictator for life. So what do you think is the modern way of programming language governance? Especially in the cryptocurrency space, it's a unique situation because these programming languages may be connected to layer one, which is a different type of thing that relies on the programming language, it's a public good, but it has stakeholders, it has a lot of capital attached, there's a lot of value being transferred. Maybe there are some programming language governance models that are better suited for blockchain. I'm very interested in thinking about how programming languages should be governed or better said, how mobile evolves, given all the huge stakeholders and the importance of designing the language to protect its security properties.

Sam Blackshear, CTO of Sui:

Well, I wouldn't say that my insights apply to other programming languages. But for Move, I have a very specific view, which is this desire to be cross-platform. Move is designed to be a cross-platform language, where some of the basic functions of chain EDM should still apply, and cover both smart contract developers and Web2 newcomers, with great flexibility.

In addition to the benefits to programmers and platform designers, governance is another reason, almost all controversial decisions in blockchain languages, such as: Should we increase this limit? Or should we support this signature scheme? Or should we have this library? We try to set it at the adapter layer, that is, the platform built on top of the language form, and the core language is very concise. Simplicity is one of the key design principles of our language, and it is very independent of the blockchain.

So if we are going to have a debate with stakeholders in the community, it will not be questions like "Should we increase the gas limit." It's more like "should we have email?", which is a purer design question that can be influenced by one or more of the Move platform's problems or use cases, but is unlikely to move in a direction that's good for one stakeholder and bad for others. So far, that's been working pretty well, but we need to see what happens in the future.

Basically, the way the Move language is governed is that, originally, Move was developed at Facebook, and there was no real governance. It was just the way we used it, although we had these design principles.

Now, the team is a little more decentralized, and we have a lot of members from different institutions. Some are here with us, some are elsewhere. There are some third-party contributors from academia, the security community, and some other institutions like Interstellar for the Move chain. We meet every Thursday.

We discuss design issues for Move, and we're very cautious about extending the language. Simplicity is the main thing, but we're aggressive about extending it.

For example, adding this thing makes it easier to experiment with these layers on top of Move. Once we see results from these experiments, or everyone seems to be doing the same thing, then we move it into the core language. So our answer to governance is: avoid it as much as possible, by letting controversial things happen at a layer above Move, and by having simplicity as one of the core principles so that we only add new things when every programmer needs something.

Moderator Sonal Chokshi:

As programmers, do you really care about the other side of things, like Noah? Like what tools do you choose to use and how do you get involved? Do you care about the community or the governance of the programming language? Or do you just care about getting the tools you need?

a16z Noah:

I think it does to some extent, like you want to use a language that is used by a lot of people so that you can get more contributors, right? You also want a language that is not abandoned, right? Those should be the main considerations.

But I don't care if Python is governed by a dictatorship or committee, as long as it achieves its goals. Although I think many people don't care, there are many arguments that governance by committee has broken a lot of programming languages, I think.

Moderator Sonal Chokshi:

Yeah, I always find that interesting.

Sui CTO Sam Blackshear:

I think it's important. I have some technical visions, like cross-platform programs and resources, and general ideas of what these things should be like. But this is a community project. A lot of contributors have contributed to a lot of aspects of the design, and I'm not the dictator of Move or anything else.But I see my role as a curator, making sure everyone is on the same page, and making sure that as ideas come in, we evaluate them against these principles, and these ideas can come from anyone.

But the most important thing is that we share a common vision. Every language is slightly different. I think they inherently reflect their use, the personalities of the creators and the community, and so on. So there's definitely not one rule that fits all.

Moderator Sonal Chokshi:

Yeah, absolutely, that makes a lot of sense.

How Sam got into Move

So in the last few questions before we wrap up, it occurred to me that we never heard how Sam got to Move. I'm primarily interested not only because I want to hear your story, which I'm sure is great, but I'm more interested in how you approached problem solving through thinking. So could you quickly share that process? Absolutely.

Sam Blackshear, CTO at Sui:

I started my career as a programming language researcher. I worked in static analysis and program verification, which meant that I spent a lot of time looking at real programs, looking for bugs, and trying to figure out what types of mistakes programmers often make and what causes them. Is it a fundamental problem with the language that makes certain types of mistakes too easy? Is it a problem with the frameworks they use? Or is it just something about human psychology that makes certain types of mistakes easier to find than others?

Basically, during my PhD, I spent a lot of time looking at real programs, looking for bugs, and then building these tools that try to look at the code without running it and try to catch these bugs before they happen. And this kind of thing can't be solved in the general case. You're always fighting the halting problem when you're doing static analysis, but in practice you can get infinitely closer to perfect results than you can get in theory with an average result. So I spent a lot of time doing this, looking at all the classic types of vulnerabilities, like null references, buffer overflows, security issues, and so on. I really enjoyed the work, but it was hard to find these examples and datasets that a lot of people really cared about.

But at the end of my PhD, I interned at Facebook. This was around 2013-2014, and they were transitioning from the web world to the mobile world, and they found that when I released a vulnerability into the mobile app, it would be there for two weeks, whereas in the web, I could fix it immediately. When I joined, the fragmentation problem on Android was the most problematic because it led to unfixable vulnerabilities. They were investing heavily in static analysis techniques. They acquired a research group from my field, and I had the opportunity to work with them and continue the work that I really enjoyed. But instead of ending up with bug fixes for individual programs, I started thinking about how to design a language to make this kind of vulnerability harder to create. I became more and more interested in language design and program security, and started to have some ideas about how to build a more secure language. Later, I joined the Libra project in 2018, a project to build a global payment network based on blockchain, and I was recruited as an expert in programming languages. This project required a new programming language, so I set out to build the Move language and used my previous experience to solve some language design challenges, such as how to ensure the security and correctness of Move smart contracts.

Moderator Sonal Chokshi:

So Libra was also renamed diem, which is what many people may know today. And a quick reminder, what was the actual topic of your doctoral thesis?

Sui CTO Sam Blackshear:

My PhD thesis focused on goal-oriented static analysis. Typically, when doing static analysis, you look at the entire program and build a database of facts about the program, and then find vulnerabilities by taking that database of facts. This approach works well, but it's not very scalable for very large programs because you have to look at the entire program and do everything. And you might have a very specific problem that only focuses on one specific part of the program. For example, if you're running an analyzer and reporting vulnerabilities in CI, you really want to report vulnerabilities that occurred in that pull request. You don't really care about the rest of the program.

In my PhD thesis, I studied goal-oriented static analysis. This means that I want the efficiency of static analysis to scale with the complexity of the specific property I care about, rather than with the size of the input program. If this property is very simple and only requires simple reasoning to determine its security or vulnerability, I want it to be very fast. Or if this requires looking at the entire program to reason, it will be correspondingly slower. That's a useful thing to do because one of the main problems with static analysis is that it's very slow, especially when you're running like huge multi-million line programs. I work on a new theory in this subfield of static analysis called abstract interpretation that aims to make abstract interpretation more goal-oriented and property-oriented, thereby increasing efficiency and precision.

Moderator Sonal Chokshi:

Very interesting. You mentioned that you were also interested in psychology in your background, when you designed your doctoral research and now your work, can you quickly talk about the psychology of programmers? Because you haven't satisfied my curiosity.

Sui CTO Sam Blackshear:

When I came to Libra in 2018, we basically needed to build smart contracts in Libra, and you needed to figure out what that meant. You can't reason in a vacuum, just like language is basically a problem-solving tool. So I looked at a lot of Solidity and smart contract code. I wondered what programmers do with this stuff? Where does the language help them? Where does it hinder them? The main takeaway from this question is that basically all of these programs are trying to do the same thing.

They're trying to talk about assets, trying to transfer them, trying to define them. But the way the code is written is always so indirect. It's like a crude design exercise where you're trying to talk about this thing, but there's no vocabulary to express it. That's the element of psychology where I can read a program and think, what is this person thinking? In their head, relative to the code they're actually writing? What are the barriers in this translation layer? How does the language help them by providing the right abstractions? There are no objective answers to these questions. It's like if I were the programmer too, how would I write this code? Or what would I find intuitive and what would be confusing?

So basically, the decision to create Move rather than building on the EVM or using an existing language was because, as we've said before, this smart contract need is so different from anything else that it doesn't make sense to use an existing language without the abstractions or features needed.

If you use something like Solidity in the EVM, it was the first attempt in this space. So it didn't reasonably anticipate what people were going to try to do. So I think we have all these advantages of being a second mover. We understand what people want to do, what works well, what doesn't work well. And we should use that to build a new language. Convincing people that a new programming language needs to be built is an interesting journey that we can talk about at another time, but there are people who tell you that you should say no. A lot of people have a healthy skepticism about whether Facebook has the vision to try this.

Moderator Sonal Chokshi:

Interestingly, it feels like this is almost the only place you can respond, and even better, you guys can now take it away from Facebook and move on. In fact, it's almost ideal conditions for its birth and development. In fact, this is a great opportunity for both of them.

Sui CTO Sam Blackshear:

It was a complete surprise.

Moderator Sonal Chokshi:

That's good to know.

Advice for smart contract programming language developers

Last question, if you have one piece of advice you want to give to those who want to learn about smart contract programming languages or are already in this field, if you can give one piece of advice in two seconds, what would you say?

Sui CTO Sam Blackshear:

Read a lot of code, understand the purpose of the code and how the underlying code actually does this, what it does well and what it doesn't do well.

Moderator Sonal Chokshi:

Why? Simply put?

Sui CTO Sam Blackshear:

I think that's the best way to learn about the language, it's a very abstract thing. But if you start with something and just try to figure out how to do this, I think that's a more concrete route and it's also easy to generalize from. Okay.

Moderator Sonal Chokshi:

Eddy, do you have any advice?

a16z Eddy Lazzarin:

That's a great question. I totally agree with what Sam said. I would also like to add that because we are still in the early stages, people love to share interesting things, like how crazy it is to program on the blockchain. There are a lot of people who are very happy to share and happy to discuss it in depth. Every time I have a question in any large social group or any forum, people are always happy to share with me. So I would recommend that everyone find people who you really enjoy sharing your code with others and building open source communities together.

a16z Noah:

My advice is that if you have any tool that you use regularly in your workflow, whether it is a compiler, a testing tool, or anything else that makes your life easier, you should learn how it works. And every time you find a bug, fix it. Be a good steward of open source software.

Moderator Sonal Chokshi:

You said it very well. Thanks again, Sam, Noah, and Eddie, for joining us for this episode of Web3@ACM. Thank you very much. Anyway, have a great day, bye.

Original link

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia