We recently spoke with Sam Blackshear, CTO of Mysten Labs and creator of the Move programming language , about why he developed Sui Move, a new smart contract programming language, the capabilities that Sui can extend, and the impact of decentralized technology on building the benefit of the recipient.
First, can you provide an overview of what a programming language is, what qualities developers look for most when choosing a programming language, and what motivated you to develop your own?
A programming language is just a tool for friendly, safe, efficient and clear interaction with computers, which is especially important for computers. We cannot communicate with computers in natural language, because the whole meaning of natural language is to be rich and expressive. When you use a slightly different tone or choose subtly different ways to express words, your sentence or paragraph can mean something completely different. In programming languages, the most important thing is to have precisely defined semantics. When you write a program, you know what it is going to do. If you make small tweaks to it, you know where that change will go. This has to be maintained on multiple levels, like you can write code in a source language, it has a meaning, and then it is translated into other forms of representation, then it should also have the same meaning, until it reaches the machine's The same goes for processing modules.
I think that, unlike natural languages, programming languages are domain-specific or task-specific in nature. Otherwise, with just one programming language, you can do it all. But the reason there are multiple programming languages is because you can't be good at all areas. They are trying to target specific problem domains and focus on solving those problems. As an example, if you look at the Rust programming language that we use to write the Sui blockchain and most of the other system work we do at Mysten, it focuses on writing code that is both fast and performant while maintaining security. It gives you access to low-level details like memory, thread structures, or concurrency, but doesn't let you make mistakes like previous languages like C or C++.
So the story of Move is very similar to that. When I created it, it wasn't to create a new language. You mentioned earlier what developers look for in a language. They ask, "Is this language good for what I'm trying to accomplish?" But I think it's probably more important, "Is there a large community for this language? Are there many databases available? Are there many programmers Is it in use? Are there good educational resources?" These are very important, so the bar for creating a new language must be very high, even if the language itself is better, if it does not have these factors, then its advantage is meaningless . Building a large and vibrant community from scratch is very difficult.
Can you share more about the development of Move?
Move originated from Facebook's Libra project. My mission at the time was not to create a new language, but "Libra needs to have smart contracts, so find out what we should do." I looked at all kinds of things. Can we use Solidity in EVM? Should we take a regular general-purpose language, like WASM or the JVM, and use it for Libra? Or should we create our own? The decision to create something of our own was based on researching existing smart contracts, understanding what programmers were trying to do, and where certain languages helped them and where they let them down. My conclusion is that in many cases existing smart contract languages do let them down.
This is clear from Solidity's poor security record, but more fundamentally, these smart contracts are not very traditional types of programs. Solidity is not a language built for what people do now. I'm not criticizing it because it's the first smart contract language that doesn't yet know what people want to do with it. Once you see what people are trying to do with it, I think it's clear that you need a different set of abstractions and programming tools that the Solidity language doesn't provide.
So these smart contracts are very simple. They basically do two things. They define the types of assets, including rules for when assets can be transferred, what you can do with them, who can read them, and who can write to them. And check the access control policy to determine who owns the asset, who is allowed to use it, and who is allowed to operate on it. Everything revolves around assets, and you want those assets to have the same attributes as physical assets. If I hand something over to you, then you should have it and I won't have it anymore.
There are concepts of ownership and transfer of ownership in smart contracts, but on a computer everything is just bits and bytes and can be copied freely. And, you know, those concepts don't exist in the real world. So you want a language that gives you good abstractions about ownership and homogenization. Just like in the real world, but without forcing programmers to reinvent it. You want basic security guarantees.
This is what Move does and why we ended up creating this new language. These tasks are fundamental to smart contract programming. They are difficult to recreate in other languages, including existing smart contract languages, and we want to design the entire language around providing these basic functions so that programmers can write code safely and efficiently without having to write some code every time Both reinvent the wheel.
Sui uses a variant of Move called Sui Move . What prompted these changes? What features of Sui Move are ideal for building products in Web3?
Several factors drove these changes, one of which was the goal of the original Libra project to build a compliant payments network. Therefore, we tried to design Move as a general-purpose language. But we also consciously did some things because of the constraints that Libra hopes to have. One of the big things is that they don't want people to be able to send certain assets anywhere. They want people to explicitly create an account, and set some rules when the account is created, such as the owner of the account must be KYC verified. Or there may be a fee to be paid to create an account, or an account can only be created by a small group of people who have permission to create an account. These limitations exist because the whole purpose of Libra is to make compliant payments and compliant smart contracts. But in the more general Web3 realm, the opposite is true. You don't want to be compliant on a fundamental level, that's the concept of smart contracts. You want things to be as free as possible, and it's perfectly possible to send something to any address. Then you should not do explicit account creation as this will block various use cases. This is an important factor.
Another factor is that while we focused on assets in Move, at the time in Libra we didn't think about how to bring the focus of assets into the transaction itself. So when you get to the transaction level, you still just have this API, where you input numbers and booleans and things that aren't assets, and then in Move, you use those numbers to withdraw assets from accounts and do other things. It turns out that most of the code you run is this nasty bookkeeping of taking this thing out, taking that thing out, taking out something else, and ok, I have all the assets I want. Here they are, in my studio, and now I can start doing something meaningful. And then at the end of the process, you might say, "OK, put those assets back into this account, put them back into that account, reorganize them.
In Sui, we've thought through, if every program starts and ends this way, can we abstract it away? So the logic for processing transactions will do this for the programmer, and from the programmer's point of view, they just have the assets they need ready and they can start doing the interesting work right away. This is the object-centric data model that exists in Sui. In the original Move, we had an account-based data model, assets were stored under accounts, and programmers had to extract them explicitly. In Sui, when they enter the Move part of the transaction, the assets have already been acquired by Sui runtime. This is more convenient for programmers because they don't need to do all this before and after bookkeeping, and it also allows us to determine whether we can run one transaction in parallel with another without actually executing it. Sui's secret sauce for horizontal scaling and a few other things more efficiently.
We've also done some other really interesting work, like leveraging an object-based data model for programmable transaction blocks. This is a somewhat technical topic that I'm happy to discuss in depth. But those two factors were the main drivers of the divergence from the original Move.
Can you please share more information about programmable transaction blocks and their capabilities?
I like to use an analogy to explain that other blockchains are like a food court in a shopping mall. You want an ice cream, you go to the ice cream stand, take out your credit card and pay. But if you decide you still want a burger, then you go to the burger stand and pay again. I'm not a glutton, but if I wanted to eat eight things, I'd have to make eight separate transactions. Whereas Sui is more of a buffet where each deal is more than just one thing. Once you've paid for the buffet, there's a lot you can do at no extra cost. You can have ice cream, you can have burgers, you can mix them all up.
To make this concept a little more concrete, in the simple case, if you're sending 100 transactions to mint 100 NFTs, you can send a transaction that mints 100 NFTs. Such a cost is almost the same as the cost of minting an NFT. You can also do heterogeneous transaction packaging, such that the first transaction in a block takes a Mario character from your multisig wallet, and the second transaction requests a Mario, which then allows you to play the game. If you win the game and get the trophy, maybe a third trade puts the trophy in a trophy cabinet that you share with friends. What's cool is that programmable transaction blocks allow programmers to write code in such a way that the game doesn't have to know about multisig wallets or how Mario is stored, nor does it have to know about your trophy cabinet or how it's implemented.
Programmable transaction blocks consist of transactions with input and output objects. If you need an input object, you can get that object without caring where it came from, and pass its output to the object that needs it, and likewise don't care where it's passed to. In other blockchains, the coupling is stronger, so games have to integrate with multisig wallets and trophy lockers, or they all have to implement some common interface and have stronger coupling. Sui makes so-called ad-hoc combinations easier. Like, if the pipelines match, we can do it in one transaction.
So what are the benefits of programmable transaction blocks for users?
For users, the benefits of programmable transaction blocks include lower gas costs because you can pack all operations into one transaction instead of doing separate transactions. Also, fewer approvals are required. If you're using a system that requires transaction approval, you only need to do it once, and then it does it all in one go. Another benefit is atomicity, if you want to do three different things and you want the third to succeed only if the first two succeed, you can't achieve that if those operations have to be independent transactions. However, if you can put them all in one transaction, then you can easily achieve this.
I've heard you and others talk about how developing on Sui is a great experience for programmers, and it's important. Do you have any anecdotes to share for both experienced and new Web3 programmers getting started with Sui Move?
For those developers coming from other Web3 programming languages, their development experience on Move and Sui Move is indeed more efficient and more secure. I was just on a podcast about Bucket Protocol and they're building a really cool DeFi project on Sui. As they demonstrate the system architecture, they describe how the different components work together. They said that if they had written this project in Solidity, it might have taken eight months, but with Sui Move it took only two months, and they are very confident in its security. The way the language works is very close to the idea of a portfolio of projects in their head. In the Solidity world, the connection is less direct.
This is just one example, but we hear a lot of similar cases where people say they develop faster on the language and feel more confident when they finish. It makes me happy to hear that. But in a way, this is not surprising, we looked into Solidity and learned about the problems. We explicitly designed scenarios around how to make it safer and faster. We looked at what the developers of the language were trying to do, and how to design the language to meet their needs, rather than cater to what already existed. The language is designed for the problems people have, so when they switch, they really appreciate the language.
You touched on this when you mentioned Sui Move and the overall object-oriented nature of Sui. But can you articulate more clearly the connection between Sui Move's design and Sui's ability to achieve Web3 mass adoption, low latency, low cost, and scalability?
One of the things we're very wary of contributing to Sui, and the problem that other platforms face, is that if you have limited capacity, whether it's like 15 transactions per second (TPS) like Ethereum or 100 or 1,000 transactions, if is a fixed number, then when the platform becomes too successful, it will reach the upper limit of capacity. At this point, the experience for everyone using the platform is degraded. If there are only 1,000 vacancies, you must choose the most important 1,000, which can be selected through gas bidding or other methods. For all, gas prices will increase, latency will increase, or both. Many use cases were excluded, as only those able to pay the highest fees would succeed, while others would have to look elsewhere or wait longer. This is not a good situation.
Sui's goal is horizontal scalability. If you allocate a certain amount of hardware, you can achieve a certain amount of throughput. If more throughput is required, the validator can introduce more hardware facilities, with no upper limit. This is how every Web2 service works. I mean, there are some engineering constraints that you have to work around, it's not a sure or easy thing to do, but everyone wants to achieve horizontal scalability when designing scalable web services.
If Sui has more customers or users, our goal is for Sui to continue to grow and everything should work. Of course, while maintaining very low latency. You don't want to sacrifice latency while increasing throughput.
In the Libra system, we did not take these characteristics into account. It is only a small-scale payment system, with hundreds of payment operators, and there may be tens of millions of payments per day, but not more. So we adopted a single box architecture, which is simpler and sufficient. But in Sui, we know that the Libra system won't work because it doesn't have the feature of horizontal scalability. So we thought, how do we design a system from scratch that can do that. This is where the object-oriented data model comes in. We basically ditched the old account-based data model because it made it very difficult to achieve horizontal scalability. Instead, if you organize everything into objects, the global state is just one big map from object IDs to objects. It's a key-value store, and we know how to scale key-value stores, it's a simple engineering problem.
The question then becomes, how do we design a transaction structure that accommodates fetching and updating data from the key-value store? How do we shard a key-value store? How do we decide where transactions should be processed? That's basically where it comes from. That said, we know how to scale these things. How do we turn this into something that has blockchain properties, verifiable reads, works with Move, etc. And then how to bring them together as smoothly as possible.
On a high level, how do you discuss the potential of decentralized technology with skeptical developers in Web2?
I think blockchain and cryptocurrencies are fundamentally a technology that removes friction. There are barriers that make it very difficult for us to conduct financial transactions, build applications, or set up information because information cannot cross these barriers, or if it does cross these barriers, it requires the help of certain third parties, and these third parties provide There is a fee for being able to help.
A classic example that people like to use is buying a house. There's a buyer and a seller, but when you actually make the payments, there has to be an escrow agent who does nothing but sit there and escrow the funds because the buyer and seller don't fully trust each other. This is a fact of life. We're going to deal with this. However, if the escrow agent can be code that is viewable by both parties, or verified by some third party, then it can do the job for free or for much less. The purpose of blockchain is not to eliminate escrow agents in real estate. This is just one of the use cases, but it's often the case.
What if there were no longer interoperability barriers between app A and app B, but built on the same underlying platform so you could have things flow from one app to the other, whether it was in-app items, data, cross- Promotions, or third-party products built on top of both. Or imagine the internet, where websites share data with each other via cookies, but those cookies are just read-only metadata. What if these cookies could become currency? Or could it be an expendable item? Or could it be loyalty programs and coupons? Everything has this functionality built in. It's very abstract, but that's where the potential lies. Usually, a person who is building will think of these as new superpowers that he can use to build something more attractive.
For end users, even if they don't have technical knowledge, do you feel hesitation when they think about code trust, even if the alternative is a large central entity that is opaque?
I do not think so. Because we do stuff like this every day, right? When I log into my email, I'm not worried that the code will delete one of my emails, or that when I send an email, it won't actually send it. If that happens, then I'll probably stop using email, or use another provider. I think it's very similar, of course not everyone can actually read something and check how it works. And, you know, if I want to check the code for the email, I can't because the code isn't there. So transparency is an important aspect of that. While not everyone is able to do this, some can sample it. And, combine that with re-use of anything, plus immutability. That's the key here. When I log into my email, I don't know if the code has changed since the last time I did something. There is no transparency about this. Even knowing this information, you can get it in Web3, and you can't get it elsewhere.
What are your expectations for Sui Move's future development?
Many of the features we're focusing on right now are based on our experience with developers who released their initial batches of Sui Move packs, and then seeing how they want to evolve these features, which ones are easy to develop, and which ones are more difficult. Sui Move is a great language for a first release package, but for the type that I'm going to change, I'm going to add some fields, I'm going to add some functions, I'm going to do it in a way that's cohesive but doesn't go against the user who used the initial package operating in a trusted manner, this becomes a very challenging problem. A lot of what we do is look at this and determine what language-level features we can add that give programmers the flexibility to extend while maintaining the trust of users of the original code.
We're working on a lot of functionality related to this, especially enum types. We're also doing a lot of work on improving the experience of connecting Move with front-end code. We often joke that a typical Sui application is 5% Move code and 95% front-end code. So we're very focused on that 95%. We spent a lot of time talking about Move, but we also focused a lot on making other parts more efficient and making connections easier. In general, we are very focused on how to make the application consist more of Move for more security. At the same time, how do we make that 95% of the code understandable to both Move programmers and non-Move programmers.
About Sui Network
Sui is an L1 public chain redesigned and constructed based on first principles, aiming to provide creators and developers with a development platform capable of hosting the next billion users in Web3. Applications on Sui are based on the Move smart contract language and are horizontally scalable, allowing developers to support a wide range of application development quickly and at low cost. For more information: https://linktr.ee/sui_apac
Official Website｜Twitter｜Discord｜English Telegram Group｜Chinese Telegram Group