Sui AMA recap (text version): Move Programming Language with CTO & Creator of the Move Programming Language
Record of the AMA is available on Sui Twitter
Sui does really have the potential to be a game changer in terms of how blockchain works and eventually delivers use cases that can onboard the next billion of users to Web 3.
Sam: I’m the cofounder and CTO of missed and I’m the creator of the Move language. I started off my career as a programming languages researcher. I was studying static analysis and automated. I spent all day doing fun esoteric math to build these tools and doing some implementation work to implement some of these tools and then run them on open source software and try to find some open source developers and see if they wanted to fix them. I had the chance to do internship at Facebook and there they were using the academic world and really try to make it work in production. In 2014 when Facebook was making the transition to mobile and they invested in all sorts of technology to catch bugs up front instead of trying to do it after the fact and one of the things these automated bug funding hunting tools that I was working on.
The story of Move is really one of taking a lot of these ideas about safety and avoiding bad behavior by construction. So forward this part I joined to Diem of Facebook. I did a lot of work on protocol design and met the cofounders of Mysten. And then last year I started working on Sui and the new integration of Move that we have. That is how I got to where I am now.
What is the development focus of the next stage of the project?
Today we’re announcing the date for our upcoming incentivized testnet. It’s going to start on august 1st and it’s going to be organized in a series of parts that we’re calling waves and each wave will have two parts. One is what we call “sync”, which is an operational challenge about certain parts of the network might be validated or reconfiguration. It might be about taking all the core stuff that’s going to need to work. The other part we call “swim”, which is a Move development and developer facing challenge. There are some details that we’re not quite ready to leave yet but there’s a code word that you’ll be hearing more about in the future. We need to make sure that the network, features, stability and developer tools ready for this upcoming incentivized testnet.
What is the history of move?
For any language the most important factor is community, having lots of libraries and lots of programmers. We discovered that these smart contract languages you can’t use a mainstream language for a variety of reasons. Smart contract languages don’t look very different from other mainstream programs. It’s a lot more different. These programming languages are all about assets, coins and NFTs. In Move the main thing we’re trying to do is the key concept of smart contracts. We are going to provide the right abstractions for programming with assets and will bake them into the language at the lowest level. We have this notion of resource types something that looks like a structure in an ordinary programming language, but it has these nice protections that are all the things you would want from an asset in the physical world.
Another protection that we focus on is you don’t want to accidentally destroy assets if you’re passing coin around a program and you just forget to return it you don’t want that to actually get dropped on the floor and destroy value unfortunate. So we have these resource types where you get all of these guarantees and you get these guarantees via type system at the bytecode level so they can’t be subverted by programmers or by mistake. These are just part of your bill of rights as a Move programmer. So that’s why we focus on it and why that is the biggest advantages over Solidity EVM.
There are many other things that we also tried to improve. There were and still are lots of security issues with EVM programs like this reentrancy thing. In Move every function call is static and you know exactly when you call a function, at compile time what code is going to be called directly and you never get surprised by some attack trying to inject malicious code in the middle of your call frame. This just makes it a lot easier to write safe code, and for people who are trying to look at code and determine if it’s safe, like auditors to do their job more quickly.
Move also has a tool called “Move prover” which is a really advanced formal verification tool where you write properties that are crucial for the correctness of your program. Like maybe only this person should be able to access this resource or call the function or like write the function “till this time and that should be destroyed”. Then the prover checks for you that these properties hold across all possible transactions and program executions, no matter what any attacker or anyone else does.
This is very powerful and it’s the highest criteria for excellence and correctness that you can have. It’s something that just integrated with the compiler and with the move tool chain as a whole. So this makes it much easier, safe code makes it easier for auditors because instead of looking at the code, all they have to do is run the prover and ensure that specified the right things and the tool chain is working correctly.
Why do you use a custom variant of move? Is there a big difference between the core move programming language?
W we actually don’t use a custom variant. Move is an interesting language where it’s an embedded we’ve intentionally designed it as this cross platform language where there’s a core language that isn’t specific to any blockchain and it’s very minimal. It has things like structs, booleans, addresses. But it doesn’t have a notion of accounts, transactions or the cryptography, consensus that’s used by a given platform. It’s just a small programming language that you can use for a lot of different things. When you want to use move in a particular blockchain whether that’s Sui, Aptos or something else, you can instantiate Move with some behaviors that sort of specialize it for your blockchain. We think there’s a really important part of the language compared to some other smart contract languages. If you are trying to build a next generation blockchain which is trying to address some of the limitations of Ethereum, you have to inherit them if the EVM overfits these features which makes it hard to build new blockchains that scale better than Ethereum does or that have a new cryptography that Ethereum doesn’t use. You’re stuck with the design decisions that platform is made forever. We want to give creators of new platforms a lot of leeway to experiment with different things so that we can push forward the leathery space as a whole.
But at the same time we didn’t have to learn one new blockchain per platform that you go to which is sort of the state of the art. Now Solana, Ethereum, Polkadot, Near do their own things and has their different features. So in Move we’re very much like this thing has to work on lots of different platforms that look very different. What we’ve done from the beginning is think very carefully about core Move and not overfitting to details of a platform and then have really nice features for specializing Move in a particular platform.
There is no default. There’s a specialization that was used in the original Diem and then we’re doing its very different specialization in Sui.
Originally Diem was supposed to be regulated payment network that didn’t really do arbitrary smart contracts but had like very tight restrictions on what accounts could exist the kind of objects that could exist in those accounts and the rules from moving stuff between them. In Sui the transfer functionality isn’t something you have to implement yourself it’s just built in as a feature of the platform.
Another thing was that we’ve been talking a lot about objects interested and how important assets are to Move, and we and the way we integrate into Diem. We really achieve that from the programming perspective. But then from the end user perspective, in terms of how transactions look to a user, it wasn’t quite transaction.
Function signature for transaction would still take only a string or an address or a boolean and it’s hard to see what this transaction actually is going to do and what objects will it touch. In Sui when you have a transaction it calls a particular function it’s published on chain and that function takes structured objects as input. For someone who’s working on tooling it’s very obvious what that transit which objects that transactions going to touch and then via Move type permissions what it’s going to do with them: mutate, transfer it or is it only going to read it. This really makes it a lot easier to take the advantages and move and push them deeper into the stack.
One other significant change we made which is very important for NFTS, but which is something that we weren’t thinking about a lot and we designed the original Move but is obviously grown in prominence a lot in the broader crypto space. You need the ability to create what are called heterogeneous collections these are collections where they have elements of different types of them when you have something like a collection or a marketplace. In the core Move language all collections have to be homogeneous and they all need to have objects and all of the same type. In Move we solved that problem by having an explicit object hierarchy. You can have each object has an owner which can be a user’s address but it can also be the ID of another object and so this lets you create parent and child relationships between objects and represent something like an NFT collection as you have a parent object that represents the collection and then each of the things in that collection are children of that object. If you have large collections without paying for accessing every element in the collection each time you touch it. This is the way it worked in the old instantiation.
We also have lots of other ideas and things to do here in the future.
How does Move present objects for the user in different formats?
I think this question is may be referring to how things are displayed in the explorer.
You can go to explore.sui.io and take a look at this for yourself. You have a lot of information about what’s going at each transaction, the idea of every object, the function that’s being called, which object paid for gas and things of this nature. The features we focused on the explorer are really about facing features that make it easy to do it. We are working on the wallet as well to have these features in it. When you look at transaction you see what it’s doing and the name of a function that’s called. You don’t really have any more information than that about what the function does and so this makes it very hard to create secure wallets because it’s hard to make sure it’s doing the right thing with its parameters.
In Sui we don’t want to have to rely on trusted signing which sources of signing requests for things to be safe. We want the signing request from a tooling perspective to be human readable and avoid people losing their assets by scammers. In Sui wallet the tooling will protect them by giving them permissions to decide like in a normal mobile platform like an android app that would ask you if it can access your camera, microphone or your location.
This is the vocabulary the user can understand and that’s what we want to use this nice structured representation of Sui to provide at the object level.
Will Sui library also provide a random generator?
I think eventually yes. This isn’t a feature that we’ve implemented yet but once we do, we’ll be able to have. This would be a huge thing. There’s not another chain, at least to my knowledge that has secure randomness the insecure randomness. When you have a transaction it obviously has a hash and then that thing is not good to use as a source of randomness because the user can control what goes into the transaction and then shift the hash. That’s a little bit hard to explain in detail without a diagram in the code but we have some nice approaches to randomness that work in certain cases and then in the long term we’re very excited to provide this as a platform feature.
Is there an easy way for beginners to essentially learn Move?
It depends on where the learner is coming from. Active feedback we have from partner recently is that if you’re coming from a Solidity world it’s very easy to learn Move. You can pick it up in about four or five days compared to months for trying to learn the smart contract programming framework of Solana. So I think the ideal background is to be someone who’s a smart contract programmer from elsewhere. Five days a very short time to learn any programming language. We also think it’s very approachable for folks coming from more of a web tube background who are approaching smart contract programming he first time. Move has the strong type system and a very tentative compiler will guide you toward doing the right thing where it might be a little bit difficult to get your code to compile it first but the tool chain is designed to guide you towards getting code that works and then once it does work it’ll be secure and you won’t have to learn the hard way about these issues like reentrancy or other security issues that crop up. If you’re a rest fan or if you’ve written in rust and you look at Move you will see a lot of syntactic similarities. We’re very concerned with making move easy to learn no matter where you’re coming from. We are working on a variety of tutorials and educational content.
Check our docs, it has lots of nice code examples. I think we have lots of good resources available, but there’s much more that we would like to do and that we would need to do to build a community.
The good news is that our own internal engineering team is very enthusiastic and they want to get that information out. We are also working closely with them to see how we can provide different types of learning materials whether it’s walkthroughs that are screen recordings where they’re taking people step-by-step. We’re looking into creating them into gif formats with blog posts.
What kind of community development plan is there?
One of the things we’re really excited about is gaming. It is already a business that’s built largely around digital assets and so there are very natural synergies with NFTs with turning some of these in game assets into on-chain assets to get broader access to liquidity for interoperability across different games with the same publisher and for doing cross promotions with brands. We’re doing a lot of work with game studios both large ones and small ones to figure out how we can attract new people to Web 3 other interesting ideas and other interesting ideas such as creating monetization or other things along these lines into their games and make all of that work. We think the key pillar for us in building community is just that you need a lot of users and big players like these gaming companies on your platform.
At the same time, we care a lot about things other than gaming like the traditional things that make economic engine of what Web 3 are going to come more from the smart contract developer audience like building DEXs, NFT marketplaces. We want to make it really easy for people who know how to build these things in other platforms to do that on Sui and then to build next generation versions of these things. There’s another class of entities we called “ecosystem enablers” like having good read APIs that developers can use to serve their applications, querying for events that happen on chain, doing on chain analytics, bring liquidity, NFTs and other platforms on Sui. These are also things we’re working on the partnerships and community building side.
Of course there are people who are not necessarily builders or partners but they’re excited about being a mod in the Sui community or like evangelizing Sui use cases/the Sui token or following us on social media or writing about Sui and educating others. All of these are super valuable to us and community is the thing we need to think about and then just meet people where they are, what are they excited about and how can they help us.
What makes Sui different from others? What is the strength of Sui?
If I had to say just one thing, it’s that Sui has really been designed from the ground up to be able to handle growing demands and to keep fees and network stable as demand grows.
Our founding team came from Diem where we spent years building a nice blockchain. This blockchain was designed to be an interbank settlement layer that had like hundreds of asks that mostly did transactions off chain for privacy but then eventually would do some payments on chain with some compliance checks. What we designed there has some good things but it wasn’t designed to scale, to handle arbitrary smart contracts, to have a validator software that could go beyond and use sharding. We thought about building on top of the Diem platform, but we knew about these limitations because we had to work on the system and we knew what it was designed to do. Then we looked into how can we extend it to handle all challenges of running a high throughput, how do we deal with state bloat, how do we do sharding and a horizontal scalability, how do we make the developer experience better and we just thought this wasn’t designed for it. There were really fundamental decisions that if we did it differently it would make a lot of these things easier and would enable a lot of the things we wanted in terms of Sui. And we knew we needed this because we were at the time we were talking to lots of partners especially the gaming side which has millions of users. We realized don’t have enough capacity and we want to welcome everyone to the platform and be able to just keep having at scale no matter how much traffic there is.
So this is how we came up with this new data model of squeeze that allows horizontal scalability that’s the key property we’re going for here where if you’re a validator you can run one machine and you’ll get a certain amount of the amount of storage but if demand spikes then you can add another one. We want do this with Web 2 distributed system scaling techniques. We don’t want to do some fancy decentralized starting protocol that validators have to know about which started other validators. Users don’t have to worry about details like cross transactions and see the cost that they just wanted to do something but discover that their data has 11 different shards. So we focus on making it very easy for users. We don’t think about scalability in terms of a specific TPS number, we think about what’s the TPS we can get per machine and how can we increase the number as demand increases. We need a strategy for developer acquisition that brings in folks in the mainstream and grows the piece of smart contract developers not just convinces them a switch. So everything we’re doing we’re really thinking about the next the millions and billions of users and how to make crypto a big thing and not something that bit more niche.
Who came up with “hot potato”?
We talked about this a long time ago at Facebook. A lot of these ideas like different Move team members come up with. I think I might have had the broad idea of “hot potato“. There’s a specific way it’s used with Move’s ability system that was designed by Tom Sawaki who is also the one who built the Move compiler that’s messed up. You probably heard him an AMA earlier.
What do you think about the future of testing with a Sui Move? See more based off writing tests in Move or do you think people will develop frameworks?
We already have a unit testing framework where you can write test. I think that will continue to be the most popular way to test your Move code in the theorem community people started off as the questioner mentions using things like hard hat where you write tests in JavaScript or somewhere else. but I think over time the communities like we really want to be able to write tests directly like Solidity and you have newer frameworks like found that let you do that.
In Move we started testing framework that lets you write tests. I think that will continue to be the most popular thing. We have some features that will work on adding to that symbolic parameters that you can write fuzz tests directly and move. Of course we have the Move prover which lets you go beyond testing in seeing if the contract works for a particular input or set of inputs. But when you’re using the prover it’s testing that it works for all possible inputs all possible transactions.
Of course that doesn’t replace the need for test. You should have both, but it lets you check things that are very hard to check with tests, particularly if you’re worried about adversarial behavior or things need to anticipate. I think the future of testing Move is growing the nice unit testing framework that we already have, supporting fancy new things like testing but any form of verification tool.
Does the move prover work fine with Sui Move? Are there any changes that have to be made?
It does work and we’re working on integrating it into our build process for the Sui framework which is the set of standard modules, standard library that all smart contract authors need to write. The main difference with Sui Move is that a lot of fancy things at the provers doing has to do with the storage model of core move which is this global type base map. In Move we take that whole feature away and the associated complexity so you don’t need to write these things in Sui Move. in Sui Move you can write things like data invariants, a spec that says the value of this counter is always increasing and then do the function and you can write pre and post conditions that are checked by the prover. I imagine there’s going to be some Sui specific prover extensions that could be interesting to look into. I mentioned this feature of “parent and child objects” you might want to be able to say things improves or specifications about the parent child relationships. Those we haven’t added yet or will require proper extensions, but I think it’ll really be driven by what kind of specifications do. Tween with programmers need to write and we’ll make sure that we have the both the right express specification language for that and the prover, and then also the back-end support for checking these properties. There’s a user guide in the Move documentation. I think it’s probably like two from the move book and if not it’s under the move proved Github repo. This is something that we’re are going to need to work more on in the future.
What is the key difference of Move from Rust in a practical way?
Rust is not a smart contract rust is not a smart contract. The key thing to recognize here is that for a smart contract language you have something that’s actually published on chain and then that’s what the validators run and so like for the EVM that’s EVM byte code and for us that’s Move byte code. Rust doesn’t have any byte code, it’s a source language. There are things that you need to have to be a smart contract language that Rust doesn’t actually have. Rust doesn’t have accounts, coins, a built in model for persistent storage. If you’re going to try to use Rust for smart contract development like Solana does and what you have is SDK or API for smart contract language that happens to be embedded in Rust. You could just as well embed an API, Python or Java or something else. And then sometimes you’re going to use Rust features like hash maps that have nondeterministic iteration and then those won’t be able to be usable in a smart contract language. It would be great to be able to use a Java purpose language is a smart contract language. We actually looked to using Rust before we created Move, but there are just differences and properties and what language needs to have to be a smart contract language that Rust doesn’t have.
What are your thoughts on scalability once the chain is exponentially greater in size?
the way a transaction looks answer is it declares the objects that’s going to operate on and then the only thing that the runtime needs is the values of objects that then runs the Move code that’s reading those objects writing them update or whatever. Then it produces some effects and that need to be applied to the database again. As you need more throughput once your database grows beyond a single machine, all you need to do is just partition the objects across those machines and then you can just keep adding more and more machines to the scheme. It’s also good for validators to be able to add more machines and get more throughput. But it’s not ideal for a user who wants to check the work of the validators. it’s going to be expensive to run validators and full nodes. In Sui we have a notion of a sparse node that leverages the Sui transaction model. And with a sparse node there’s a certain set of addresses or objects we call them “causal roots”. They can be either those things that I’m going to track and I’ll track all transaction, execute and validate transactions and state that are relevant to these objects. if you’re a game developer who’s running a game server you might have a sparse node that tracks the state of all your players and your game or the state of the DEX. Collectively everyone can validate the transactions in the state that are relevant to their use case but without paying for the cost of validating everything. This is the nice way to scale the validation.
What are you personally excited about seeing built on Sui Move that you couldn’t or shouldn’t necessarily try to accomplish with Solidity?
I’m very excited about next generation NFTs without standards. We think it caters to the lowest common denominator where every NFT has to satisfy these rules. So if you want to do something like NFT with some metadata that can be mutated that has to be another standard that the community gets together and agrees on and then it can only be mutated in ways that cater to the least common denominator whatever it wants to do. In Sui one way to think about it is that every object is an NFT every object has a unique ID which is one of the key thing that every object has its own transfer functionality as I described. You can add new fields to your NFT, you can have logic for updating them, you can wrap your NFTs, you can do this parent child object thing. I think it just really takes off the handcuffs in terms of what you can do with digital objects and makes it much easier to do this safely and quickly. I’m very excited to see what creators are going to do with this once they’re freed from the shackles of trying to conform to these restrictive standards and just focus on what they want to create in terms of NFT and digital assets perspective. I think that’s going to be extremely interesting especially when you couple it with low cost and the scaling capabilities of Sui.
