Exclusive Interview with the Founder of Move Language: Why is Sui Move Smart Contracts Language Suitable for Building Web3 Products?

Recently, we spoke with Sam Blackshear, the Chief Technology Officer of Mysten Labs and the founder of the Move programming language, about why he developed Sui Move, a new smart contracts programming language, the scalability features of Sui, and the benefits of decentralized technology for builders.

The following is the content of this interview:

Q1. First of all, can you give an overview of what a programming language is, what qualities developers pay the most attention to when choosing a programming language, and what drove you to develop your own programming language?

Programming languages are a tool for friendly, secure, efficient, and clear interaction with computers. This is especially important for computers. We cannot communicate with computers using natural language because the whole essence of natural language lies in its richness and expressiveness. When you use a slightly different tone or choose a subtly different way to express vocabulary, your sentence or paragraph can mean something completely different.

In programming languages, the most important aspect is having precisely defined semantics. When you write a program, you are clear about what it will do. If you make a slight adjustment to it, you know what result that change will produce. This needs to be maintained on multiple levels; for instance, you can write code in one source language that has a certain meaning, and then it is converted into another form of representation, it should still carry the same meaning until it reaches the machine's processing module.

I believe that, unlike natural languages, the essence of programming languages is targeted towards specific domains or tasks. Otherwise, one programming language would suffice for all tasks. The existence of multiple programming languages is due to the fact that you cannot excel in all fields. They are striving to target specific problem areas and focus on solving those problems. For example, if you look at the Rust programming language we use to write the Sui blockchain and most of the other systems at Mysten, it focuses on writing code that is both fast and high-performance while ensuring safety. It allows you to access low-level details like memory, thread structures, or concurrency, but does not allow you to make mistakes in the same way earlier languages (like C or C++) did.

Therefore, the story of Move is very similar to this. When I created it, it was not to create a new language. You mentioned earlier what developers look for in a language. They will ask, "Is this language suitable for the tasks I want to accomplish?" But I think it might be more important to ask, "Does this language have a large community? Are there many available databases? Are there many programmers using it? Are there good educational resources?" All of these are very important, so the threshold for creating a new language must be very high. Even if the language itself is better, if it doesn't have these factors, then its advantages are meaningless. Building a large and vibrant community from scratch is very difficult.

Q2. Can you share more about the development status of Move?

Move originated from Facebook's Libra project. My task at the time was not to create a new language, but to "Libra needs to have smart contracts, so figure out what we should do." I looked at all kinds of things. Can we use Solidity in EVM? Should we use a conventional general-purpose language like WASM or JVM for Libra? Or should we create our own?

The decision to create our own thing is based on the study of existing smart contracts, understanding what programmers are trying to do, and where certain languages help them and let them down. My conclusion is that, in many cases, existing smart contract languages do indeed let them down.

This can be clearly seen from Solidity's poor security record, but more fundamentally, these smart contracts are not a very traditional type of program. Solidity is not a language built for what people are doing now. I am not criticizing it, as it is the first smart contract language and it didn't know what people wanted to do with it. Once you see what people are trying to do with it, I think it becomes clear that you need a different set of abstractions and programming tools, which the Solidity language does not provide.

So these smart contracts are very simple; they basically do two things. They define the type of assets, including when the assets can be transferred, what you can do with them, who can read them, and the rules for who can write to them. They also check access control policies to determine who owns the asset, who is allowed to use it, and who is allowed to operate on it. Everything revolves around the asset; you want these assets to have the same properties as physical assets. If I hand something over to you, then you should own it, and I no longer own it.

The concept of ownership and ownership transfer exists in smart contracts, but on a computer, everything is just digits and bytes and can be freely copied. Moreover, you know that these concepts do not exist in the real world. Therefore, you want a language that can provide you with a good abstraction regarding ownership and fungibility. Just like in the real world, but without forcing programmers to reinvent it. You want to obtain basic security guarantees.

This is the purpose of Move and why we ultimately created this new language. These tasks are fundamental to smart contracts programming. They are difficult to recreate in other languages, including existing smart contract languages. We want to design a whole language around providing these basic functionalities so that programmers can write code safely and efficiently without having to reinvent the wheel every time they want to write some code.

Q3. Sui uses a variant of Move called Sui Move. What prompted these changes? What features of Sui Move are particularly suitable for building products in Web3?

Several factors have contributed to these changes, one of which is that the original goal of the Libra project was to build a compliant payment network. Therefore, we attempted to design Move as a general-purpose language. However, we also consciously did some things because Libra wanted to have restrictions. One important thing is that they did not want people to be able to send certain assets anywhere. They wanted people to explicitly create an account and set certain rules at the time of account creation, such as the account owner must undergo KYC verification. Alternatively, there may be a fee required to create an account, or account creation could only be done by a small group of people who have the permission to create accounts. Since the whole purpose is that Libra wants to engage in compliant payments and compliant smart contracts, these restrictions exist. But in the more general Web3 space, the situation is quite the opposite. You do not want compliance at the foundational level; that is the concept of smart contracts. You want things to be as free as possible, allowing something to be sent to any address. Then you should not require explicit account creation, as this would block various use cases. This is an important factor.

Another factor is that, although we focused on assets in Move, we did not consider how to bring the focus on assets into the transactions themselves at the time in Libra. Therefore, when you reach the transaction level, you still only have this API where you input numbers and boolean values and other things that are not assets, and then in Move, you use those numbers to extract assets from the accounts and perform other operations. It turns out that most of the code you run is this tedious bookkeeping work, which includes taking this thing out, taking that thing out, taking other things out, okay, I have all the assets I want. They are here, in my workspace, and now I can start doing something meaningful. Then at the end of this process, you might say: "Okay, put these assets back into this account, put them back into that account, reorganize them."

In Sui, we have given it careful thought: if every program starts and ends in this way, can we abstract it? Therefore, the logic for handling transactions will do this for programmers. From the programmer's perspective, they only need to prepare the required assets and immediately start doing interesting work. This is the object-oriented data model that exists in Sui. In the original Move, we had an account-based data model where assets are stored under accounts, and programmers had to explicitly extract them. In Sui, when entering the Move part of the transaction, the assets have already been acquired by the Sui runtime. This is more convenient for programmers because they do not need to carry out all the bookkeeping work before and after, and this is also the secret weapon that allows us to determine whether one transaction can run in parallel with another without actually executing, enabling horizontal scaling of Sui and performing other operations more efficiently.

We have also done some other very interesting work, such as using object-based data models for programmable transaction blocks. This is a rather technical topic, and I would be happy to discuss it in depth. But these two factors are the main drivers of the divergence from the original Move.

Q4, could you please share more information about programmable trading blocks and their functions?

I like to use an analogy to explain that other blockchains are like a food court in a shopping mall. If you want to eat an ice cream, you go to the ice cream stall and take out your credit card to pay. But if you decide you also want a hamburger, then you go to the hamburger stall and pay again. I'm not a glutton, but if I want to eat eight different things, I have to make eight separate transactions. Sui, on the other hand, is more like a buffet where each transaction is not just one thing. Once you pay the buffet fee, you can do many things without extra cost. You can eat ice cream, you can eat hamburgers, and you can mix them together.

To make this concept more concrete, in a simple case, if you want to send 100 transactions to mint 100 NFTs, you can send a single transaction to mint 100 NFTs. The cost of this is almost the same as the cost of minting one NFT. You can also perform heterogeneous transaction bundling, for example, the first transaction in the block pulls out a Mario character from your multisig wallet, while the second transaction requests a Mario and allows you to play the game. If you win the game and earn a trophy, perhaps the third transaction will place the trophy in a trophy cabinet shared with friends. The cool thing is that programmable transaction blocks allow programmers to write code in such a way that the game doesn’t have to know how the multisig wallet or Mario is stored, nor does it need to know about your trophy cabinet or how it is implemented.

Programmable transaction blocks consist of transactions with input and output objects. If you need an input object, you can obtain it without worrying about where it comes from, and then pass its output to the object that needs it, again without worrying about where it will be passed to. In other blockchains, the coupling is stronger, so games must integrate with multi-signature wallets and trophy cabinets, or they must all implement some common interfaces and have stronger coupling. Sui makes so-called temporary combinations easier. Just like, if the pipes match, we can complete it in one transaction.

Q5, what are the benefits of programmable trading blocks for users?

The benefits of programmable trading blocks for users include lower gas fees, as you can bundle all operations into a single transaction instead of making separate transactions. Additionally, the number of approvals required will also decrease. If the system you are using requires transaction approvals, you only need to give approval once, and then it will complete all operations in one go. Another benefit is atomicity; if you want to do three different things and want the third operation to succeed only if the first two are successful, you cannot achieve this if these operations must be independent transactions. However, if you can put them all in one transaction, you can easily achieve this.

Q6. I have heard you and others talk about how developing on Sui is a great experience for programmers, and that it is important. Do you have any anecdotes to share for experienced and new Web3 programmers starting to use Sui Move?

For developers coming from other Web3 programming languages, their development experience on Move and Sui Move is indeed more efficient and safer. I just participated in a podcast about the Bucket Protocol, which they are building something very cool on Sui.