Recap 6/30 Sui AMA: Move Programming Language with Sam Blackshear

Jen:

Wherever you are in the world: good morning, afternoon, and evening. Really excited to get our Move programming language AMA started with our very own CTO and Co-Founder of Mysten Labs. I will let you introduce yourself, Sam.

Sam:

Absolutely. So I'm Sam. I'm the Co-Founder and CTO of Mysten as well as the creator of the Move language.

Let me tell you a little bit about my path to Mysten and Crypto. I started off my career as a programming language researcher; I was studying static analysis and automated bug finding tools. I spent all day doing fun, esoteric math to build and implement these tools to run them on open source software so that I can find some bugs to report to open source developers and see if they wanted to fix them. Sometimes they would, and that would be a great thrill. But mostly, this was just fun math and not something particularly practical.

Towards the end of my PhD, I had the chance to do an internship at Facebook. And there, they were trying to take the same technology that we were using in the academic world and try to make it work in production. This was back in 2014, when Facebook was making the transition from web to mobile. They were discovering that we have to keep bugs out of our mobile apps at all costs. So they invested in all sorts of technology to catch bugs up front instead of trying to do it after the fact. I was working on these automated bug finding tools and got to do the same kind of research work I was doing before, except now, I get to put it in front of tens of thousands of Facebook developers and get real time feedback about what they were doing.

All to say, it was a totally addictive experience.

For me, I really like working at this intersection of Research and Production. After my internship, I joined Facebook and spent many years working on this. I made a blog on technology and looked at all sorts of things, like buffer overflows data, races, node references, and some content analysis for security. This is where I formed a lot of opinions about language design, because we spent all day doing static analysis and trying to look for bugs.

From a language perspective, it’s hard to reason about code for automated tools like the one I was readying for end users. The story of Move is taking a lot of these ideas about safety, bugs, and avoiding bad behavior by construction and just thinking about what is the language designed from scratch trying to look like?

I joined the Diem effort of Facebook and created Move as part of that. This is also where I did a lot of work on protocol design and met the co-founders at Mysten. And then last year, we jumped out to join the company and I started working on the new integration of Move that we have with Sui.

. . .

Question #1: What is the development focus of the next stage of the project?

Sam:

There's a great opportunity to plug in announcements happening later today. I think it's officially dropping after the AMA, but we can give some early info to the folks that happen to be here. Today, we're announcing the date for our upcoming incentivized testnet. It's going to be organized in a series of waves to fit with the Sui-based water theme. Each wave will have two parts: one is what we call a Sink, which is an operational challenge about certain parts of the network – might be validator reconfiguration, it might be about staking all the core stuff, that's always gonna need to work – and then the other part we call a Swim, which is a Move developer facing challenge.

The first one, there are some details that we're not quite ready to release yet. But there's a code word that you'll be hearing more about in the future, which is Capybara as that's going to be the theme of the first Move related challenge. A big focus for us is getting the network ready for this Incentivized Testnet and making sure the stability features are all there, the developer tool chain is ready for these new challenges, and then just proceeding through a series of waves that builds operational experience.

Among the folks who are running the network, we’re making sure we're ready to do incident response as well as making sure everything is secure and ready for mainnet, which we hope to get to before the end of the year. So that's our focus right now. We're very much in crunch mode and trying to get to this Incentivized Testnet.

Question #2: What is the history of Move, and what sets it apart from other programming languages like Solidity?

Sam:

Yeah, let me cover these separately, although they're closely related. So when I joined the Libra project back in 2018, it was given a very broad mandate. The mandate said that Libra was supposed to be this global blockchain powered payments network and then it's supposed to run arbitrary smart contracts.

So you know, we're all just Facebook people, we know some things about crypto, but mostly, we're computer scientists. And so our prompt is to discover the nitty gritty of the smart contract, like what kinds of programs folks are intrigued by, and what's the ideal way to write these programs. Should we take an existing smart contract language and try to retrofit it and make it safer and better? Should we try to take a mainstream language and turn it into a smart contract language? Or should we try to design something from scratch?

So we looked at all three of these options. The first thing we really looked at was trying to retrofit a mainstream language for any language. The most important factor for this is community, having lots of libraries, having lots of programmers know it, having lots of tooling, having Stack Overflow and all this stuff. If you can tap into an existing language community, that's ideal. However, what we discovered is that with these smart contract languages, you can't use a mainstream language for a variety of reasons. There are basic requirements that pretty much no mainstream language satisfies.

One of them is determinism. When you have a smart contract language, you’re trying to run these transactions that multiple validators are executing and need to get the same answer. If your competition isn't deterministic, they're not going to be able to do that. So that takes a large number of conventional programming languages off the table because they don't have determinism built in and it's very hard to retrofit a language to take away determinism.

You can imagine, iterating over HashMap is non-deterministic, because it'll depend on what addresses are in the HashMap and you don't know if there's a HashMap they use somewhere deep in a library of some piece of code that you're using. Moral of the story: you can't use these programs because that language won't be safe. Then the other thing is that smart contract programs just look very different from mainstream programs. They're very much centered around assets. The typical transaction is going to take some assets as input, read them, write them, and then maybe it'll transfer them.

There's also these concepts of authority around someone who's an owner of the asset or maybe someone else that’s an owner, but these things don't exist at all in mainstream languages, which are a lot lower level. There's nothing that represents an asset. There's nothing about authority. There's no persistence. There's no accounts and there's nothing like transactions. Then there are all these things that you probably don't need. So what we thought is that although it would be nice to use a mainstream language, you basically have to take such a large subset of the language and build tooling that enforces it. That's going to be much more complicated.

We looked at solidity and EVM to see what's out there and what goes well with that. There we discovered that this has one of the major problems that mainstream languages have, which is, these programs are all about assets. They're about coins. They're about NFT's. They're about money. Yet in the language, there's no type or value that actually represents an asset. The data model of assets is that you have a hash table somewhere, the user addresses are keys in this hash table and the bytes of the assets are values in the hash table. If you want to write a program that's trying to say that as an asset from one user to another you don't call a function and pass that asset to the procedure, you go into the hash table and you muck around with some bits that try to transfer the thing around.

So it just makes it hard to do the very basic things that you'd naturally want to do in code that's using assets: things like passing an asset as an input to a procedure, returning an asset from a procedure, putting an asset inside a data structure, and wrapping an asset inside another asset. In Solidity and Ethereum, you aren’t able to do any of these things, because there's no representation of assets. The language has no types; at the low level, everything is just bytes. You can't have these notions.

So with Move, the main thing we're trying to do is provide the right abstractions for programming with assets and bake them into the language at the lowest level. We have this notion of resource types where you have something that looks like a struct in an ordinary programming language, but it has these nice protections that are what you would want from an asset in the physical world. For example, you can't just create this from scratch because that's a privileged operation. You also couldn’t copy it, either on purpose or by accident. Normally, when you write “let x equals y” in a programming language, what you're doing is you're actually copying “y”. But of course, if “y” is a coin that has some real world value, you don't want to copy it. It's very important that the old value of y can't be used anymore, and that the and y is sort of in one place at a time.

Another protection that we focus on is preventing the user from accidentally destroying assets by passing a coin around a program, and forgetting to return it. So we have these resource types where you get all of these guarantees via type system at the bytecode level. So they can't be subverted by malicious programmers or by mistakes, these are just part of your Bill of Rights as a Move programmer.

There are many other things that we also tried to improve. There were and still are lots of security issues with EVM programs like reentrancy. Back to the time we were designing Move, the DAO hack was something that was on everyone's minds, which was related to reentrancy in a way that it was trying to re-implement a scarce asset unsafely. In Move, every function call is static, you know exactly when you call a function, you know exactly at compile time what code is going to be called directly and you never get surprised by some attacker trying to inject malicious code in the middle of your call frame. It just makes it a lot easier to write safe code. And for folks who are trying to look at code and determine if it's safe, like auditors to do their job more quickly. And to build advanced tooling like the Move Prover that reasons about code.

Fitting my static analysis background and the background of the Move team who work in static analysis and program verification, we co-designed the language with a tool called the Move Prover, which is a really advanced formal verification tool where you write properties that are crucial for the correctness of your program. Maybe only this person should be able to access this resource or call this function. The total number of these objects in the system should be 10. This thing should exist until this time, and then it should be destroyed. The Move Prover checks for you that these properties hold across all possible transactions, all possible program executions, no matter what any attacker or anyone else does.

This is very, very powerful. It's sort of like the highest criterion for excellence and correctness that you can have. It's something that's integrated with the compiler, and with the Move tool chain as a whole. This makes it much easier to write safe code. It also makes it easier for auditors to understand, because instead of looking at the code, all they have to do is look at the specs and run the prover. Running the prover ensures that you've specified the right things and the tool chain is working correctly. We think it's going to make it much much easier for programmers to focus on writing the code and worrying less about these esoteric security issues that come up with things like reentrancy

So, that's what we're trying to do when we created Move and what we've been working on and what we worked on at Diem and Novi.

Question #3: Why do you use a custom variant of Move? Is there a big difference compared to the core Move programming language?

Sam:

So, we actually don't use a custom variant of Move. The nature of Move is an interesting language. We've intentionally designed it as this cross platform language where there's a core language that isn't specific to any blockchain. It has things like strux, booleans, integers and addresses, but it doesn't have a notion of accounts, transactions, the cryptography that's used by a given platform, or the consensus that's used by a given platform – all these things are abstracted away.

It's actually just a small core language that doesn't say anything about blockchains at all. You can actually use it for lots of different things. When you want to use Move in a particular blockchain, whether that's Sui, Star Coin, Aptos, or 0L – which are all platforms that are using Move – you can instantiate Move with some behaviors that sort of specialize it for your blockchain and what it's trying to do.

We think this is a really important part of the language compared to some other smart contract languages because if you use something like EVM, it overfits so many implementation details of the way Ethereum works. So all of the things I just mentioned, like the addresses, account structure, or even the consensus get baked into the EVM to some degree.

If you're trying to build a next generation blockchain, it’s going to address some of the limitations of Ethereum. You have to inherit them if the EVM overfits to these features. This makes it hard to build new blockchains that scale better than Ethereum does, have new cryptography that Ethereum doesn't use, have accounts that work in a different way, or just otherwise trying to innovate.

It’s very important to us that we don't tie Move to just one platform and make it so that you're stuck with the design decisions that platform has made forever. We want to give creators in new platforms a lot of leeway to experiment with different things so that we can push forward the space as a whole. But at the same time, you don't have to learn one new blockchain per platform that you go to, which is sort of the state of the art now.

You know, Solana does its own thing. Ethereum does its own thing, if you go to Polkadot, they have their own thing. If you have one language per platform, that's not a good recipe for creating a vibrant developer community, reusable tooling, or libraries that can be used everywhere. We have to work on lots and lots of different platforms that look very different under the hood, otherwise, we're never going to be able to build those vibrant communities. What we've done from the beginning is think very carefully about core Move by not overfitting to details of a platform.

There's a long winded way to come back to the original question, which is that we actually don't have a default Move, but Sui uses a different one. There's a default Move that can't be used on any platform. There's a specialization that was used in the original Diem, and then we're doing a very different specialization in Sui.

Originally, Diem was supposed to be a regulated payment network that did arbitrary smart contracts that had very tight restrictions on what accounts could exist, the kind of objects that could exist in those accounts, and the rules for moving stuff between accounts. There were decisions that were made like, you can't send an object to another address unless that person beforehand says, “I would like to get my permission to receive objects of this particular type”. This was appropriate because there were things like capital controls; you couldn't have an account receive US dollars if they were in a certain jurisdiction. So, it's very important that someone couldn't send them US dollars without their permission.

In the open Web3 world, this is very unfortunate. You want to be able to airdrop NFT's to someone or send them tokens or give them things without them having to explicitly opt-in beforehand. In Sui we allow you to do that. Objects have transfer as a built-in capability. When you create an object, an NFT, or anything, the transfer functionality in Sui isn't something that you have to implement yourself. It's just built in as a feature of the platform that’s also very performant.

If you have an NFT that you want to have a restricted transfer policy, you can only transfer it after a certain date to avoid speculation or maybe you want royalties to be paid when it's transferred, then there's a way to encode that instead. But by default, everything can be transferred freely, which makes it much easier to build an open platform than Diem and the other platforms that use Diem style instantiations.

Another thing was that we've been talking a lot about object centricity and how important assets are to Move. In the way we integrate into Diem, we really achieve that from the programming perspective. From the end user perspective, in terms of how transactions look to a user, it wasn't quite there. The function signature for a transaction would still take only a string, an address, or a Boolean. It was very hard to see what this transaction is going to do with objects and what it will touch.

The Sui transaction model is asset centric; when you have a transaction because a particular function is published on a chain, that function takes structured objects as input. If you’re transferring a Bored Ape, the function will be called transfer and then it'll have a type in the functions that are called Bored Ape. If you're putting up a Bored Ape in some kind of NFT marketplace, then that marketplace would also be an explicit signature of the transaction. The transaction can only touch these objects that come in as inputs. So when you look at a transaction, as an end user, or as someone who's working on tooling, it's very obvious what objects that transaction is going to touch, and then, via Moves type permissions, what it's going to do with them. Is it going to mutate it? Is it going to transfer? Or is it only going to read it?

It makes it a lot easier to take the advantages of Move and push them deeper into the stack, so that the end user can see them instead of just running the code and seeing what happens, which is the way it worked in Diem.

There's one other significant change we made, which I think is very important for NFT's because of its growth in the broader crypto space, which is you need the ability to create heterogeneous collections. These are collections that have elements of different types. When you have something like an NFT collection or a marketplace, it's not the case that every NFT below it would have the same Move type. That would be inconvenient because you'd like to be able to have a collection that has a painting in it, or a recording or something else. These are all different Move types with different fields that can be distinguished.

In the way we integrated Move into Diem and the core Move language, all collections have to be homogenous; that is they all have to have objects of the same type. In Move, we've solved that problem by having an explicit object hierarchy. Each object has an owner, which can be an end user's address, but the owner of an object can also be the ID of another object. This lets you create parent and child relationships between objects and represent an NFT collection as you would have a parent object that represents the collection and each of the the things in that collection are children of that object.

For example, the recording NFT might be one child, and then the painting NFT might be another one and then something else might be another one. This function lets you have large collections without paying for accessing every element in the collection each time you touch it, which is the way it worked in the old instantiation.

Those are some of the highlights of what we've done in Move on Sui that we think goes beyond the original instantiation of moving to Diem. But we also have lots of other ideas and interesting things to do here in the future. I'm also very excited to see what other folks are going to do with Move when they create new Move powered platforms. It's really part of the ethos of the language that we give you the base of safe abstractions for programming with objects and assets, but we also want folks to be really creative in the way they're creating new Move powered platforms.

Question #4: How does Move present objects for the user in different formats?

Sam:

I think this question is referring to how things are displayed in the Explorer. You have a lot of information about what's going on each transaction, you have the idea of every object, you have the function that's being called, you have which object was paid for to use, you have what was used to pay for gas, and things of this nature. What I hear about the question you're asking is that this seems like too much information for the end user. I agree with that. The Explorer is a platform for builders and builders really need all of this information so that they can decide which coin to use to pay for costs, debug what went wrong and also have the full details.

On the Explorer, we focused on features that make it easy to do all these things. Going forward, I think the Explorer is probably a little bit more for power users of the blockchain than it is for end users. For something like a wallet, where you abstract away a lot of these things, you only show relevant details of what the user cares about, like the tokens that are going in or the decks they are going to interact with.

We've been working on a lot of these things in our Sui wallet. I think you'll be very pleased with the user experience and how much of a gentler, more abstracted view of what Sui's transactions are doing. One particular thing about the wallet feature I'm excited about is, we're working on this thing called human readable signing requests. A big problem in Ethereum, Solana and every other blockchain I know, is that when you look at a transaction, you can see what it’s doing and what the function is called, but you don't really have any more information than that about what the function does. This makes it very hard to write to create secure wallets, because it's not possible to ask an end user to look up the code for that function and make sure it's doing the right thing.

That's always going to be too difficult for end users that are not technical. This leads people into a lot of scams. Basically, people sign things because the Signing Request comes from a trusted source, not because they actually know what the Signing Request does. Recently, there was this hack in the Bored Apes community where their discord got hacked when the mod said, "Hey, there's a giveaway that's happening here. Click to connect your wallet to this transaction and sign it and we'll drop you a limited edition thing". A lot of people did that because they trusted the source of the message. But it turned out that the discord had been hacked and then a lot of people's Apes, money and other things got stolen.

What we really want on Sui is to not have to rely on sources of signing requests for things to be safe. What we'd like is the Signing Request, from a tooling perspective, to be human readable and give you permissions, like you'd get on Android or iOS where it says, "Hey, here's a Signing Request". This would give permission to read your Bored Ape, which is harmless because it can't be transferred away or stolen. Whereas if someone's discord gets hacked, and they send you a message with a Signing Request, but the tooling says, "this is supposed to be doing a promotional giveaway" and gives permission to transfer your Bored Ape. At this point you might say, "Hey now, wait a minute, that doesn't seem safe to me. All I should need to do is to read this so I can get my promotional thing, but it's asking to transfer it, I think I'm probably not going to sign that”.

So we're going to have a feature like this in the Sui wallet. We think this is going to make web3 wallets much less intimidating and unsafe to users because they don't have to worry as much about all these scams and nasty things that can come along. The tooling will protect them by giving them permissions that are normal to have in a mobile platform, like an Android app asking you if it can access your phone book, your microphone, your location, and things like that. This is the type of vocabulary that the user can understand.

That's why we want to use this nice structured representation of Move on Sui, to provide at the object level so that we can serve that information to users. So long story short to answer the question, I think you're right that the Explorer isn't trying to provide the curated end user experience we want, but we're definitely going to be doing that on a wallet, which we're excited to showcase. We have the platform features to really make this a better experience than it is elsewhere.

Question #5: Will Sui’s standard library also provide a random generator?

Sam:

I think eventually, yes. If you're a nerd and follow Sui's consensus, you know that we use narwhal tusk. If you've read the narwhal tusk paper, there's a variant of Tusk that uses what's called a common coin for generating randomness from the consensus process. This isn't a feature that we've implemented yet. But once we do, we will actually be able to have randomness as a platform feature that can be exposed via Move. This would be a huge thing, because there's not another chain out there that has secure randomness. Insecure is a different story that I want to point out as a platform feature for smart contract programmers.

In the meantime, there's still lots of other ways to get randomness even though it can't be a platform feature. We've been working on some CryptoKitties style, genetic programming type things where you need randomness as part of the equation. There’s something interesting we can do:

• When you have a transaction, it has a hash. The hash on its own 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.
• Instead you can set it up so that the randomness incorporates both the transaction ID and a field on-chain that a lot of other folks have access to.
• This makes it very hard to predict what the random number is going to be, what the result of hashing this on-chain value and what the transaction hash is going to be.
• Ultimately, it makes it very hard to game randomness.

This is 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. In the long term, we're very excited to provide this as a platform feature.

Question #6: Are we offering tutorials? Is there an easy way for beginners to learn this language?

Sam:

From the feedback we got from our partner recently, if you’re coming from the Solidity world, it’s very easy to learn Move. The estimate we got is that you can pick it up in about 4 or 5 days compared to months trying to learn the smart contract programming framework for Solana.

There are some idiosyncrasies of smart contract programming that are fundamentally hard. I think the ideal background is to be someone who's a smart contract programmer from elsewhere. We also think it's very approachable for folks coming from more of a Web2 background who are approaching smart contract programming for the first time. Move has a strong type system, and a very opinionated compiler that will guide you toward doing the right thing. It might be a little bit difficult to get your code to compile at first, but the tool chain is designed to guide you toward getting code that works. Then once it does work, it'll be secure. You won't have to learn the hard way about these issues like reentrancy or other security issues that crop up if you're gonna instead start with Solidity.

I think Move is quickly approachable if you've used the Rust language. If you're a Rust fan, or if you've written in Rust, you'll look at Move and see a lot of syntactic similarities. We do that intentionally when the feature on Move is very similar or equivalent to the same Rust feature. We have intentional syntactic differences where something is quite different in Move just to remind folks that they're in the Move world here. Don't think that you're in Rust and assume that it's gonna behave the same because it will not. Especially in terms of the type system for references, which we call the borrow checker, Move has a much simpler version Rust’s borrow checker that will be familiar to Rust programmers, but hopefully also easier to learn.

We're very concerned with making Move easy to learn no matter where you're coming from. We're working on a variety of tutorials and educational content that hit those. We have one out now that's a series called Programming with Objectsthat was written by one of our Move team members that goes step by step on how do you get into Move via the particular lens of this variant. I think that's probably the best possible introduction that I know of, and then can be supplemented by looking at the Move book.

The Move book was created by the Move contributors that's hosted on the Move GitHub repo. There's lots of links to that in our Sui docs. There's also Move Book,which is written by one of our team members. It's another book that goes end to end through all the features of Move.

For me, I always like to start with tutorials or examples. There's a GitHub directory called Sui_Programmability/Examplesthat has example code of fungible tokens, non-fungible tokens, NFT 's, marketplaces, and games. That's really good too, if you like to learn by looking at code and then trying to imitate it or modify it. I think we have lots of good resources available, but there's much more that we would like to do and need to do to build a vibrant community.

Jen:

The good news is that our own internal engineering teams are very enthusiastic about getting that information out. In the coming weeks, we are working closely with them to see how we can provide different types of learning materials, like step by step walkthroughs that are screen recordings. We're also looking into creating them into GIF formats with blog posts that actually outlines how it's being done. In terms of the chat that we have here, we're happy to take suggestions and recommendations of how you, as the community, would like to learn. Because this will also help us in terms of how we want to structure the learning materials, and make sure that we're sharing this information in a way that's digestible and easy for you as well.

Sam:

Yeah, thank you for bringing that up Jen. We produce the resources that we think are best for learning Move, but we're also coming from an odd place being the creators of the language, having people who are working on design and folks who are very deep in it. So we very much appreciate your feedback on what's good about our existing documentation tutorials, the things you'd like to see and the things that would be most helpful to you. We really need your help with that and appreciate it greatly.

Question #7: What kind of community development plan is there, especially because we know that our developing community is super critical for our project on Sui?

Sam:

On Sui we are taking a multi pronged approach in this. This sort of gets a little bit into our go to marketing strategy, which is also related to community. The use cases we're most excited about on Sui is when people build a use case that caters to a large user base of tens of millions of users because these are the sorts of things that you just can't do elsewhere on existing blockchains in a cost effective way, and in some cases, not at all.

One of the things we're really excited about is gaming. If you look at a lot of our early partners, a lot of the early things we wrote and talked about, you can see a case where gaming is already a business that's built largely around digital assets. There are very natural synergies with NFTs and with turning some of these in game assets and on-chain assets to get broader access to liquidity for interoperability across different games by the same publisher for doing cross promotions with brands and other interesting things like this.

We're doing a lot of work with Game Studios, both large and small ; to figure out how we can leverage the unique capability of Sui to bring web3 features including NFTs and other interesting ideas like on chain anti-cheat checking, or creator monetization, etc. into their games and make all of that work.

The key pillar for us and the building community is, you just need a lot of users and you need a lot of big players, like these gaming companies on your platform, and ideally that have a lot of end users, you pull a couple of large games and you probably have more users on your platform than all of web3 combined, then you show the utility of what having a blockchain one that really scales can provide for this audience.

At the same time, we care a lot about things other than gaming, there's a lot of things that makes web3 repealing are the economic engines of web3 that are gonna come more from smart contract developer audience, things like building indexes, building NFT marketplaces, we want to make it really easy for folks who know how to build these things on other platforms, to keep doing so but on Sui. And then to build next generation versions of these things that are leveraging Sui’s high performance and unique capabilities and the nice move programming model that we have.

Then, there's a another class of entities that we've all ecosystem enablers, this is things like having good read API's that developers can use to serve their applications or querying for events that happen on chain and doing on chain analytics, bridging to bring liquidity and NF T's from other platforms to Sui. These are also things we're working on, on the partnerships and community building side.

Then of course, they're the guys who aren’t necessarily builders, and they're not necessarily partners, but they're excited about being a mod, and the Sui community are evangelizing Sui use cases, or the Sui’s token or working along or following Sui on social media or writing about Sui and educating users, or educating guys about how things work. All of these are super valuable to us, so community isn't just one thing, we need to think about what Sui needs, and then also just meet people where they are, what are they excited about? And how can they help us? So as you can tell I’m the CTO and technical person, I have a certain view on this. But I think I would also like to hear what Jen has to think about this as someone who's very involved in all of these things and as someone who's more experienced and articulate about these matters.

Jen:

I was definitely not expecting that, thanks for doing this. Well, in terms of community, I would say, so far, people have been really upfront about things that have been going wrong, I really appreciate the fact that people have reached out to me privately about things that have to be fixed or if we haven't been as reactive, for example: fullnode, we were just drowning in the reception from the community and obviously, when we go live with things, things do break, or there's issues that we have to fix, so while people have been also super upfront about the issues that we have, I would also like to point out how patient everyone has been when we're trying to address these issues.

In terms of our community program, I'm very happy to say that we recently brought on a lovely Developer Relations Lead, Brian, who will be helping with a lot of the programming that we're doing; he will also be on an upcoming AMA shortly. But through him, we're going to also build out proper programs. I know that the mod program itself has been a bit slow, we are still going through applications, I want to highlight that we received over 500 applications, which is an insane number in that short amount of time. So we want to have the respect of reading through each of the applicants and providing feedback as we can.

So our programs are not just based on mods, we're also looking through in the future of how we bring on creators who have really great visualization. I know a lot of you guys are super talented with graphic design.

Last but certainly not least is how do we bring in regional markets? People who have expertise within their local markets and can help us make sure that our translations and our information is accessible to people who aren't primarily English speakers. So we're looking at all of these to make sure that we're not only posting our own channels, but we're making sure that the materials are accessible for people who might want to share it within their own respective communities because a lot of you also have a lot of credibility that you've built, whether it's through Telegram, or Twitter or your own specific discord servers. So we don't want to stop that train and we certainly want to make sure that the materials are there, so that you can get the information out.

Hopefully, that answered some of the questions regarding our community initiatives and how much we're trying to make sure that we're not being blockaded and we're working with you hand in hand. So thanks for that reversal.

Question #8: What is the strength of Sui and what makes us different from others?

Sam:

Yeah, absolutely. 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 the growing demands and to keep fees stable and the network stable. Basically, our founding team, like a lot of us came from Diem and Novi where we spent many years building a nice blockchain there, but in the blockchain, and what we're building, this blockchain was designed to be an interbank settlement layer that had hundreds of vasps mostly the transactions off chain for privacy, but then eventually would do some payments on chain with some compliance checks. What we design there has some good things about it but it really wasn't designed to scale to handle arbitrary smart contracts and to have a validator software that could go beyond multiple machines and use sharding or to do a really high throughput beyond a couple of 1000 transactions per second. So, we thought that was all gonna be needed for the payments use case.

When we started Mysten, of course we thought about building on top of the DEM platform, but we knew about these limitations of it, because we had worked on the system, and we knew what it was designed to do and what it wasn't and we looked into how can we extend it to handle all of these tough challenges of running a high throughput L one, how do we deal with state bloat? How do we do sharding? How do we do horizontal scalability? How do we implement it? How do we make the developer experience better? And we just thought that, this wasn't designed for it, and there are 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 talking to lots of partners, especially in the gaming side, and they're saying, hey, I've got 10 million users, I want all of them to do 1000s of transactions a day, and we're like, okay, you do the math. There's one partner like this, and then another one comes on, we don't want to start turning people away when we don't have enough capacity, we want to welcome everyone to the platform, and be able to just keep having a scale no matter how much traffic there is.

This is how we came up with this new data model of Sui that allows horizontal scalability, that's the key property that we're going for here, if you're a validator you can run one machine, and you'll get a certain amount of throughput and a certain amount of storage but if demand spikes, then you can add another, you can provision another machine, now you've gotten more throughput and more storage, and the entire network can do this just keep growing as much as it needs to serve the demands of the community.

Importantly, we want to do this whether to distributed system scaling techniques, we don't want to do some fancy decentralized sharding protocol that validators have to know about which shard other validators run, users have to worry about details like cross shard transactions and see the cost that they just wanted to do something but discover that their data happened to live in different shards and now that has a different security model, or a different cost model. Users should just think, Okay, here's the global stake, I throw my transaction into a pond, and then the results come back to me, and that's it. An architecture lets you do that and then gives you this horizontal scalability.

This is really what we're focusing on. I think that's the thing that distinguishes it from all other projects, and that we don't think about scalability in terms of a specific TPS number or anything like that, we think about what's the TPS we can get per machine and how do we set up the system so that we can make that number go up as much as we need to, even as the as demand increases, because otherwise, web3 will only be as big as whatever the max TPS number a single machine or a single system can handle and we just want to make sure we have the flexibility to handle whatever people are gonna throw at us.

This is more of a philosophical position, but it goes deeply into system design into why we've done what we've done, and what we're targeting and even the things like the developer community where we people will be like, oh, you know, the EVM has now effects like you should have done solidity in the EVM and Sui and then we will look at the numbers and see there's 4000 developers who are building on the EVM, but if you want to build this is a small number compared to 16 million JavaScript developers or 12 million iOS developers and if you want a large developer community to be building the next generation of absolute world, you're really gonna need a lot more than 4000. So we need a strategy for developer acquisition that brings in folks in the mainstream and grows the smart contract developers not just convinces folks to switch.

So everything we're doing, we're really thinking about the next millions and billions of users and how to make crypto a big thing and not something that's a bit more niche.

Jen:

Those are the final questions we actually had from our forms that we reviewed but we have quite a few that have come through art lunch. This is a fun one, it's the first one actually came up. Audience, wrote out that he was writing a book on mood patterns, he's asking who came up with Hot-Potato? And where should he put it?

Sam:

We talked about this a long time ago at Facebook, I'm trying to remember, a lot of these ideas like different Move team members come up with it simultaneously, and then kick it around, and then we figure out how it'll work. I might have had the broad, I do have hot potato but there's a specific way it's used with Moves ability system and the ability system was designed by Todd Nowacki, who was also the one who built the Move compiler, you probably heard him in an AMA earlier.

I would give credit for hot potato to Todd, the idea of having something that you're forced to use is nice, but like, boom, the type system feature that allows you to do that are really flexible, and extensible way is all about ability, so I think Todd is the one who should get credit for that. But with that, everything with Move this is a team effort, we bounce ideas off each other and come up with the best version of something.

Question #9: What do you think about the future of testing with Move on Sui? Will it be more based of writing in Move? Or will people develop hard hat-like frameworks for writing in languages that are other than Move?

Sam:

We already have a unit testing framework where you can write tests in Move and I think that will continue to be the most popular way to test your Move code.

In the community people started off as the questioner mentioned, using things like hard hats where you write tests in JavaScript or somewhere else. But overtime we really want to be able to write tests directly in solidity, and you have newer frameworks, like foundry that let you do that and that are growing a lot of popularity, I think these are the experiences that people prefer.

In Move, we understood this and we started right away with a testing framework that lets you write tests in Move. So I think that will continue to be the most popular thing, we have some features that we're working on adding to that like, symbolic parameters so that you can write fuzz tests directly in Move, of course, we have the Move prover, which lets you go beyond testing or seeing if the contract works for a particular input or set of inputs. But when you're using the prover, it's testing works for all possible inputs, all possible transactions, all possible programming that are leaving. So you can get a lot more leverage out of your developer and testing effort than you can with writing tests.

Of course, this doesn't replace the need for tests, you should have both but it lets you check things that are very, very hard to check with tests, particularly if you're worried about adversarial behavior or things they didn't anticipate. So I think the future of testing in Move is growing the nice unit testing framework, they already have to support fancy new things like us testing, but then also the prover of any formal verification tool is a never ending research problem, you're trying to solve the halting problem and you can never concretely do that but you can asymptotically approach perfection it's at a very good place. But I think making it work better and better and letting you specify richer set of properties instead of running faster. These are things that will always be working on and are excited to work on.

Question #10: How does the Move Prover work with Move on Sui? And are there any changes?

Sam:

Well, yes it works, and we're working on integrating it into our build process for the Sui framework, which is the set of standard modules that basically are like the Sui standard library that all smart contract authors need to write. The main difference with Move on Sui is that a lot of fancy things that the provider is doing has to do with the storage model of core Move. Which is this global type base map and in Sui, we take that whole feature away and associated complexities so you don't need to write those facts in Sui.

In Sui, you can write things like data invariants, have a counter, you can write a spec that says the value of this counter is always increasing and then you have a function and you can write pre and post conditions that are checked by the prover. There’s going to be some Sui specific proof extensions that could be interesting to look into, like this feature of parent child objects. You might want to be able to say things to improve, or specifications about the parent child relationships between objects, for example, maybe this object is always the child of this parent or this parent has three children or something along those lines. We haven't added those yet nor require approval extensions but it'll really be driven by what kind of specifications do we Move programmers need to write and we'll make sure that we have the both the right expressive specification language for that, and the prover and also the the back end support for checking these properties.

This is something that we're gonna need to work more on in the future, verification tools. The Move prover is somewhat easy to get into, but the advanced usages of that require some more study and hand holding.

Question #11: What's the key differentiator of Move from Rust in a practical way?

Sam:

Why not Rust versus Move for smart contract development? This is a question I get asked frequently, and my answer to this question is rust is not a smart contract language. 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 for the EVM, that's EVM bytecode. And for us, that's Move by code but Rust doesn't have an equivalent of Move by code, it's a source language that to actually run it, you have to run the compiler, you go through LLVM and then you get out machine code, or wasum, or something else like that so you can't use an In addition as I talked about before, with these table stakes properties for smart contract languages, there are things that you have to have to be a smart contract language that Rust doesn't have, Rust doesn't have accounts, or Rust doesn't have coins Rust doesn't have a built in model for persistent storage. So if you're going to try to use Rust for smart contract development like Solana does, you're actually using Rust as a smart contract language, what you have is an SDK or an API for a smart contract language that happens to be embedded in Rust, but it could just as well be an API in Python or in Java or something else.

Sometimes you're going to use Rust features like hash maps that have non deterministic iteration and then those won't be able to be usable in a smart contract language, it gets at this thing that I mentioned before of, it would be great to be able to use a general purpose language as a smart contract language. It’s funny, we actually looked at using Rust before we created Move, we weighed the differences and evaluated what properties the language needs in order to be a smart contract language that Rust just doesn't have.

So with that said, we love Rust, all of Sui is written in rust, and there are a lot of aspects of Move that are strongly influenced by rust. What we've tried to do basically is take the things folks really love about rust development and the experience and then make those present both syntactically and semantically in the language. We've also tried to very aggressively simplify where Russ does something complex, because it needs to be a low level systems language where you can write efficient compilers and operating systems where Move is never going to be used for that, Move is for smart contracts.

So basically, we try to take the good parts of Ross, but then do this aggressive simplification to make Move much more approachable in any way that we can.

Question #12: What are your thoughts on scalability once the chain is exponentially greater in size, especially when it comes to throughput and the amount of time to verify it?

Sam:

I talked a little bit about this earlier, but I'll expand on that, and then talk about the time to verify, which is also a very relevant question.

For throughput, let me go a little bit more in detail on how this works, the way a transaction looks in Sui is, It declares the objects it's going to operate on and then the only thing that the runtime needs aren't actually the transaction is the values of those objects then runs the Move code that's reading those objects, writing them, updating them, whatever and then it produces some effects that need to be applied to the database again. So as as you need more throughput, all you need to do is once your database grows beyond a single machine, or your executor goes beyond a single machine, you just partition the objects across those machines and then when a new transaction comes in, you can say, Okay, this transaction is sent by Sam, let's go to the shard where AMS objects live and we can execute the transaction there and that makes it easy and then Jen's transaction will come and we'll send it to the shard where Jen's objects live, and that can be entirely executed there with no cross shard reads necessary and then you can just keep adding more and more machines to the scheme, and you keep getting more throughput, at least that's the idea.

And then there's the validation part of this where it's great for validators to be able to add more machines and get more throughput but it's not ideal if as an end user who wants to check the work of the validators, I now need to run a micro cluster, that's not going to be great for decentralization, there's a problem that a lot of people building high throughput chains don't think about, they're like, yeah, it's gonna be expensive to run validators and full nodes just deal with it, we think that's okay. And in fact, fundamental for validators, you can't get more throughput without adding more computing power, but for decentralization, you really want a large ecosystem of folks who can efficiently check what's happening in the chain to make sure the validators aren't doing anything malicious.

So the way we solve this problem is, in Sui we have a notion of a sparse node that leverages the Sui transaction model and with a sparse node, you say there's a certain set of addresses or objects, we call them causal routes that can be either those things that I'm going to track, and I'll track all transactions, track and re execute and validate all transactions in state that are relevant to these objects. So these addresses, but not the rest of the state, and for example, every wallet is a sparse node that tracks the objects that are owned by that wallet, and whatever else the wallet happens to care about or, if you're a game developer who's running a game server, you might have a sparse note that tracks the state of all your players and your game had been objects and the game state, but not the state of some other game, or the state of attacks or some other thing that's not relevant to you. So collectively, everyone can validate the transactions in the state that are relevant to their use case, without paying for the cost of validating everything, the many 10s of millions potentially of transactions that are going on in the system, this is a really nice way to scale this validation, because fundamentally, the cost of your validation is going to be proportional to the amount of state that you care about and for most end users, that's probably small and for use cases, like a game that depends on basically how big their game is, so it's appropriate that they pay for that.

This is super important, bull nodes and networks, they only really scale because TPS is really, really low. So anyone who's running a high throughput chain is going to need to have some good answer to this problem, that allows you to scale validation, otherwise, your decentralization is going to suffer a lot as your throughput goes up what you don't want.

Question #13: What are you personally excited about seeing built on Sui that you couldn't or shouldn't necessarily try to accomplish with Solidity?

Sam:

I'm very excited about the next generation of NFTs without standards, and what I mean by this is that when you have something like ERC 721, or 1155, 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, say I have an NFT with some metadata that can be mutated, that has to be yet 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 of whatever it wants to do, where 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 things of 721 and every object has this built in transfer functionality as I described and when you want to do beyond that is up to you, you can add new fields to your NFT and you can set it up to have logic for updating them, you can wrap your NFT and other NFTs, you can do this parent child object thing, it just really takes off the handcuffs in terms of what you can do with digital objects and makes it much 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 try to do the limited things that everyone wants to do in common. And shift their focus on to what they want to create from an NFT and a digital asset perspective.

I think that's going to be extremely interesting, especially when you couple it with the low cost and the scaling capabilities of Sui and the nice developer experience we have in Move.

Jen:

And there's a reason why Sui’s line is basically building without boundaries. We’re really excited to see what people create and their process of creating, on the platform that we're launching shortly. I'm fully aware of the time. Thank you so much Sam for giving us your time and walking us through the Move programming language.

Next week, still finalizing the topic, but it will not be Move-related. Just know that the week after, we will have something that's tied to this in the forum.

If you have any additional questions, please continue sharing it with our event chat, as well as our Twitter accounts. And we'll be sure to bring that question up in another AMA series. Any last words, Sam?

Sam:

Not for me. Thank you so much, and thanks to the community for your great questions. This was a lot of fun for me.

Jen:

We'll do another series soon. Thank you, everybody. Have a wonderful day morning, afternoon, evening wherever you are.

. . .