Source: Sui Network
Recently, we had a conversation with Sam Blackshear, the Chief Technology Officer of Mysten Labs and the creator of the Move programming language, discussing why he developed the new smart contract programming language Sui Move, the capabilities that Sui can extend, and the benefits of decentralized technology for builders.
The following is the content of the interview:
Q1, first of all, could you give an overview of what a programming language is, what qualities developers are most concerned about when choosing a programming language, and what drove you to develop your own programming language?
A programming language is just a friendly, secure, efficient, and explicit tool for interacting with computers, which is particularly important for computers. We cannot communicate with computers using natural language because the entire meaning of natural language is rich and expressive. When you express vocabulary with slightly different tones or choose slightly different ways of expression, the meaning of your sentences or paragraphs will be completely different.
In a programming language, 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 a minor adjustment to it, you know what the change will result in. This needs to be maintained at multiple levels, for example, you can write code in a source language with a certain meaning, and then it should have the same meaning when it is converted to other representations, until it reaches the processing module of the machine.
I believe that, unlike natural language, the essence of a programming language is specific to a certain domain or specific task. Otherwise, you could just use one programming language to accomplish all tasks. But the reason why there are multiple programming languages is that you cannot perform well in all domains. They are striving to target specific problem domains and focus on solving these problems. For example, if you look at the Rust programming language we use to write the Sui blockchain and most other systems work at Mysten, it focuses on writing code that is both fast and high-performance while ensuring security. It allows you to access low-level details such as memory, thread structure, or concurrency, but it doesn’t allow you to make mistakes like previous languages such as C or C++.
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 would ask, “Is this language suitable for the tasks I want to accomplish?” But I think what might be more important is, “Does this language have a large community? Are there many available databases? Are there many programmers using it? Are there good educational resources?” These are all very important, so the threshold for creating a new language must be very high. Even if the language itself is better, if it does not have these factors, its advantages are meaningless. It is very difficult to build a large and vibrant community from scratch.
Q2: Can you share more about the development of Move?
Move originated from Facebook’s Libra project. My task at the time was not to create a new language, but to “figure out what we should do because Libra needs smart contracts.” I looked at various things. Can we use Solidity in EVM? Should we use conventional general-purpose languages like WASM or JVM and apply them to Libra? Or should we create our own thing?
The decision to create our own thing was based on research on existing smart contracts, understanding what programmers were trying to do, and where certain languages helped them and where they disappointed them. My conclusion was that, in many cases, existing smart contract languages did indeed disappoint them.
This can be clearly seen from the poor security record of Solidity, but more fundamentally, these smart contracts are not very conventional program types. Solidity was not built as a language for what people are doing now. I’m not criticizing it because it’s 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 Solidity language does not provide.
So these smart contracts are very simple, they basically do two things. They define the types of assets, including when assets can be transferred, what you can do with them, who can read them, and who can write rules for them. And they check access control policies to determine who owns the assets, who is allowed to use them, and who is allowed to operate on them. Everything revolves around assets, and you want these assets to have the same properties as physical assets. If I give something to you, then you should own it, and I no longer own it.
There are concepts of ownership and ownership transfer in smart contracts, but in computers, everything is just digits and bytes and can be freely copied. And you know, these concepts don’t exist in the real world. So you want a language that can provide you with good abstractions about ownership and fungibility. Just like in the real world, without forcing programmers to reinvent it. You want to get basic security guarantees.
This is the role of Move and why we ultimately created 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 hope to design the entire language around providing these basic functionalities so that programmers can write code safely and efficiently without reinventing 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 well-suited for building products in Web3?
The following factors have led to these changes, one of which is that the initial goal of the Libra project was to build a compliant payment network. Therefore, we tried to design Move (https://docs.sui.io/learn/sui-move-diffs) as a general-purpose language. However, we also did some things consciously because Libra wanted to have restrictions. One important thing is that they do not want people to be able to send certain assets anywhere. They want people to explicitly create an account and set some rules when creating the account, such as the account owner must undergo KYC authentication. Or it may require payment to create an account, or only a small group of people with account creation permissions can create an account. Because the whole purpose is that Libra wants to conduct compliant payments and compliant smart contracts, these restrictions exist. But in the more general Web3 field, the opposite is true. You don’t want compliance at the foundational level, which is the concept of smart contracts. You want things to be as free as possible and be able to send something to any address. And you shouldn’t have explicit account creation because it will 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 in Libra at that time. Therefore, when you reach the transaction level, you still only have this API, where you input things like numbers and boolean values that are not assets. And then in Move, you use these numbers to extract assets from accounts and perform other operations. It turns out that most of the code you run is this annoying bookkeeping work, which includes taking out this thing, taking out that thing, taking out other things, okay, I have all the assets I want. They are here, in my studio, and now I can start doing something meaningful. And 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 carefully considered whether we can abstract it if every program starts and ends in this way. Therefore, the logic for handling transactions will be handled by the programmers, and from the programmer’s perspective, they just need to prepare the required assets and immediately start doing interesting work. This is the object-centric data model that exists in Sui. In the original Move, we have an account-based data model where assets are stored under accounts and programmers have to explicitly extract them. In Sui, they are already obtained by the Sui runtime when entering the Move part of the transaction. This is more convenient for programmers because they don’t need to do all the bookkeeping work before and after, and this is also the secret weapon that allows us to determine whether one transaction can be run in parallel with another transaction, scale Sui horizontally, and perform other operations more efficiently without actually executing them.
We have also done some other very interesting work, such as using an object-based data model for programmable transaction blocks. This is a more technical topic that I am happy to discuss in depth. But these two factors are the main driving forces behind the divergence from the original Move.
Q4: Can you please share more information about programmable transaction blocks and their functions?
I like to use an analogy to explain it. Other blockchains are like food courts in a shopping mall. If you want to have an ice cream, you go to the ice cream booth and pay with your credit card. But if you also want to have a hamburger, then you go to the hamburger booth and pay again. I’m not a big eater, but if I want to have 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 for the buffet, you can do many things without any extra cost. You can have ice cream, you can have a hamburger, you can mix them together.
To make this concept more specific, in a simple scenario, if you want to send 100 transactions to mint 100 NFTs, you can send one transaction to mint 100 NFTs. The cost of doing this is almost the same as minting one NFT. You can also do heterogeneous transaction packaging, such as the first transaction in a block takes out a Mario character from your multi-signature wallet, and the second transaction requests a Mario and allows you to play the game. If you win the game and get a trophy, maybe the third transaction will put the trophy in a trophy cabinet shared with friends. What’s cool is that programmable transaction blocks allow programmers to write code in such a way that the game doesn’t need to know about the multi-signature wallet or how Mario is stored, nor does it need 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 it without worrying about where it comes from, and then pass its output to the object that needs it, without worrying about where it will be passed to. In other blockchains, the coupling is stronger, so the game has to integrate with the multi-signature wallet and trophy cabinet, or they both have to implement some common interfaces and have stronger coupling. Sui makes so-called ad hoc composition easier. Just like if the pipes match, we can do it in one transaction.
Q5: What are the benefits of programmable transaction blocks for users?
For users, the benefits of programmable transaction blocks include lower gas fees because you can pack all operations into one transaction instead of separate transactions. Additionally, the number of approvals required is reduced. If the system you’re using requires transaction approvals, you only need to approve once, and then all operations will be completed at once. Another benefit is atomicity. If you want to do three different things and want the third one to succeed only if the first two operations succeed, if these operations have to be independent transactions, you can’t achieve this. But if you can put them all in one transaction, then you can easily achieve this.
Q6: I have heard you and others talk about how developing on Sui can be a great experience for programmers, and 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 secure. I just participated in a podcast about the Bucket Protocol, where they are building a very cool DeFi project on Sui. When they showcased the system architecture, they talked about how different components work together. They said that if they were to write this project in Solidity, it might take eight months, but with Sui Move, it only took two months, and they have great confidence in its security. The way this language works is very close to how they envision their project composition in their minds. In the Solidity field, this connection is not as direct.
This is just an example, but we have heard many similar cases where people say they develop faster and have more confidence in this language. Hearing these makes me happy. But to some extent, this is not surprising because we have studied Solidity and understood its issues. We explicitly designed solutions around how to make it more secure and faster. We examined what developers using this language are trying to do and how to design a language that meets their needs, rather than catering to existing situations. This language is designed for the problems people encounter, so when they make the switch, they really appreciate this language.
They say that first-mover advantage is important, but I think in this case, the advantage of being a latecomer is even more important.
Exactly, that’s right.
Q7: You have already touched on this when you mentioned the object-oriented nature of Sui Move and Sui as a whole. But can you further clarify the connection between the design of Sui Move and Sui’s ability to achieve widespread adoption, low latency, low cost, and scalability in Web3?
One thing we are very cautious about when contributing to Sui, and something other platforms face as well, is that if your capacity is limited, whether it’s 15 transactions per second (TPS) like Ethereum or 100 or 1,000 transactions, if it’s a fixed number, then when the platform becomes too successful, it will reach the capacity limit. At this point, the experience of each user on the platform will decline. If there are only 1,000 available slots, you have to choose the most important 1,000, either through gas bidding or other means. For everyone, gas prices will rise, and there will be increased latency or a combination of both. Many use cases are excluded because only those that can afford the highest fees will succeed, while others have to turn elsewhere or wait longer. This is not a good situation.
Sui’s goal is horizontal scalability. If a certain amount of hardware is allocated, a certain amount of throughput can be achieved. If more throughput is needed, validating nodes can introduce more hardware infrastructure without any upper limit. This is how every Web2 service works. What I mean is, you have to address some engineering constraints, which is not a definite or simple thing, but everyone designing scalable Web services wants to achieve horizontal scalability.
If Sui has more customers or users, our goal is to enable Sui to continue to grow and everything should work fine. Of course, while maintaining very low latency. You don’t want to sacrifice latency while increasing throughput.
In the Libra system, these characteristics were not taken into account. It is just a small-scale payment system with hundreds of payment operators and possibly tens of millions of transactions per day, but no more. So we adopted a single-box architecture, which is simpler and sufficient. But in Sui, we know that the Libra system doesn’t work because it lacks the feature of horizontal scalability. So we thought about how to design a system from scratch that can achieve this. This is where the object-oriented data model comes from. We basically abandoned the old account-based data model because it makes implementing horizontal scalability very difficult. Instead, if you organize everything into objects, the global state is just a large mapping from object IDs to objects. This is a key-value store, and we know how to scale key-value stores, which is a simple engineering problem.
Then the question is, how do we design a transaction structure that adapts to the process of retrieving and updating data from the key-value store? How do we shard the key-value store? How do we decide where transactions should be processed? This is basically where it comes from. That is to say, we know how to scale these things. How do we turn it into something with blockchain properties, verifiable reads, and the ability to work with Move? And then how do we integrate them as smoothly as possible.
Q8, At a higher level, how do you discuss the potential of decentralized technology with developers who question it in Web2?
I think blockchain and cryptocurrencies are fundamentally friction-removing technologies. 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, it requires the help of certain third parties who charge a certain fee for their assistance.
A classic example that people like to use is buying a house. There is a buyer and a seller, but when it comes to actual payment, there must be an escrow agent who does nothing but hold the funds because the buyer and seller do not trust each other completely. This is the reality of life. We need to deal with this problem. However, if the escrow agent can be code that both parties can view or that has been verified by a third party, then it can do this job for free or at a lower cost. The purpose of blockchain is not to eliminate escrow agents in real estate. This is just one use case, but it is usually like this.
If there are no longer interoperability barriers between application A and application B, but they are built on the same underlying platform, then you can make things flow from one application to another, whether it’s 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 through cookies, but these cookies are only read-only metadata. What if these cookies could become currency? Or spendable items? Or loyalty programs and coupons? Everything is built with this capability. It’s very abstract, but that’s where the potential lies. Usually, someone who is building something thinks of these as new superpowers they can use to build something more attractive.
Q9: For end users, even if they don’t have technical knowledge, do you feel that they hesitate when considering code trust, even if the alternative is an opaque large central entity?
I don’t think so. Because we do this kind of thing every day, don’t we? When I log in to my email, I’m not worried that the code will delete one of my emails, or that it won’t actually send when I send an email. If that happens, then I might stop using email, or use another provider. I think this is very similar, of course, not everyone is able to actually read certain content and check how it works.
Also, you know, if I want to check the code for email, I can’t because the code isn’t there. So transparency is one of the important aspects. Although not everyone can do this, some people can do sampling checks. And, combined with the reuse of anything, plus immutability. That’s the key here. When I log in to email, I don’t know if the code has changed since the last time I did something. There’s no transparency about that. Even knowing this information, you can get it in Web3, but you can’t get it elsewhere.
Q10: What are your expectations for the future development of Sui Move?
Many of the features we are currently focusing on are based on the experience of the developers who released their initial batches of Sui Move packages, and then observing how they want to develop these features, which features are easy to develop, and which features are more difficult. Sui Move is a language that is very suitable for releasing packages for the first time, but for me to change this type, I want to add some fields, add some functions, and operate in a way that is cohesive but does not violate the trust of users who use the initial package. This has become a very challenging problem. Much of the work we do is researching this and figuring out what language-level features we can add that can provide flexibility for programmers while maintaining the trust of the original code users.
We are studying many related features, especially enumeration types. We have also done a lot of work to improve the experience of connecting Move with frontend code. We often joke that a typical Sui application is 5% Move code and 95% frontend code. Therefore, we pay a lot of attention to that 95%. We have spent a lot of time discussing Move, but we also pay great attention to how to make the other parts more efficient and make the connection easier. Overall, we pay great attention to how to make applications consist more of Move to gain more security. At the same time, how do we make this 95% of code easy to understand for Move programmers and non-Move programmers alike.
Like what you're reading? Subscribe to our top stories.
We will continue to update Gambling Chain; if you have any questions or suggestions, please contact us!
