Earlier in June, we announced Sui Incentivized Testnet. We’re happy to share that registration to participate in Sui Incentivized Testnet is now open! You can register HERE. If you are a validator, developer or Sui Enthusiast, we highly encourage you to apply and join our incentivized testnet journey.

Validators will form the backbone of our Sui network. Each validator processing transactions and participating in consensus will enable Sui to become the most secure and safe network in the world. Our main testnet objectives include:

1. Foster an ecosystem for potential validator and fullnode operators
2. Establish and nurture operator behaviors to create a thriving Sui Mainnet

Incentives

• Sui Foundation will reward validators with 2,000 SUI for each testnet ‘wave’ they participate in.
• The Sui Foundation will commit to staking up to 10% of Sui’s token supply with the highest performing validators who continue to participate in Sui’s Mainnet.

Hardware requirements and bandwidth:

We are currently recommending: m5.2xlarge (8vCPU, 32GB RAM) + 128GB SSD

Who can participate?

Running a Sui fullnode is a prerequisite for joining our incentivized testnet. For more information on how to do that, see HERE.

To receive SUI rewards you’ll need to:

• Be at least 18 years of age.
• Verify your identity and complete sanctions screening with our partners at CoinList. You will receive an email with instructions on how to set up a CoinList account. If you are already a CoinList user, please use your existing account to expedite your KYC process.
• For US participants, qualify for and verify accredited investor status.

Other program details

Distribution of SUI rewards is subject to hitting minimum participation requirements that we will share prior to the start of each testnet wave. SUI token rewards will only be provided following the Mainnet launch of the Sui protocol, and will be subject to a one-year lockup period.

Learn more about Sui

• Sui Website — https://sui.io/
• Sui Developer Portal — https://docs.sui.io/
• Move Programming Language
• Sui Whitepaper
• Community forums

Build with us!!

We’re excited about what the future unfolds and invite creators and builders to join us.

Validator Registration Open was originally published in Mysten Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

Note: You can find further information regarding Sui Tokenomics on our Sui Developer Portal.

Introduction

Jen: Welcome to our AMA regarding tokenomics. I’ll hand the mic to our guest Alonso De Gortari and let him introduce himself.

Alonso: I’m super excited about this. It’s been almost a month since we released our tokenomics materials on the website. I think this is the first time we’ve had the opportunity to talk about this with the broader community and we’ll surely do this many times in the future.

I’m really excited to hear everyone’s thoughts and make sure that the tokenomics of Sui make the most sense for everyone.

My training was in economics, sort of the traditional economics. I went to grad school, did a PhD, worked on a bunch of supply chain issues during my PhD thesis, then did a post-doc with a professor of economics. At some point, I realized that what was happening out there in the real world is much more interesting, so I decided to join the very early stages of Libra and Facebook. Later, I was designing the Libra stable coin economic incentives around the Libra blockchain; now in many ways, it’s a train wreck compared to what we’re doing with Sui.

So, about six months ago I left Facebook to join Mysten labs, and ever since, I’ve become very much in love with the project. Building at Sui, I can understand how we really have the potential to be a game-changer in terms of blockchain. It actually delivers use cases. I can board the next billion users to web3, and it took a lot of design and engineering to make sure that we can view the Sui blockchain so that it is up to the same mechanics and economic point of view as the engineering of the blockchain.

Question #1: What’s your view on tokenomics and blockchain?

Alonso: In many ways, tokenomics is one of those parts of blockchain ecosystems that describe how different things work. It’s also a part of blockchains that are least developed, at least from a research point of view. So while it’s true that if you look at how different blockchains were in the engineering sense, especially regarding capabilities of L1s, if you look at it from building distributed systems, many of the engineering computer science models are available so you can figure out what you’re doing, what these networks are providing make sense or not. Tokenomics is not there at all if you look at the research, and you can even make very simple issues look not-so-simple, but things that should be well known like proof of work or proof of stake, the economics results are very behind.

So this is sort of both a good thing and a bad thing for tokenomics. It’s good, because it means that there’s a lot of room to improve the way that tokenomics work. A lot of these blockchain ecosystems, in terms of innovation, you can do tricks to solve new problems. For example, think about storage with early blockchains. They were so simple in their functioning that storage wasn’t even something you had to think about, which means that on the tokenomics front, you didn’t really have to think about economically: How you would create the right incentives to price and address those storage capabilities? What would that cost for future participants in those networks?

In Sui, for example, we can handle a large amount of on-chain storage, which means from a tokenomics perspective, we really need to sit down and think very seriously about how we’re going to address that. If we leave these issues unaddressed, that could potentially end up creating really bad dynamics on the network. For example, people might start storing a lot of data on the chain without paying for it, but someone ultimately has to pay for that storage. That creates a bad network externality that can end up killing your network. So tokenomics needs to take this into account. That’s sort of the good thing because there’s a lot of things that we can still think about, and there’s a lot of innovation being done to address these new problems.

The risky part of it is that tokenomics, as a field of research, is so nascent. There’s a lot of risk in what we do. If we change 10 things at the same time, we don’t know what their effects are going to be. Think of a simple analogy like a cake recipe. If you’re baking a cake and change one ingredient, you can likely predict what’s going to happen to the cake. But if you change 10 ingredients, then you might end up with an amazing cake that’s better than anything you’ve ever had or a disaster cake. It’s hard to figure out what’s going to happen. Tokenomics is a bit like that. Once you start opening up the design space and going across all these other verticals, you can dive into: how gas price mechanisms work, how the proof of storage mechanism works, how the storage dynamics work, and so on.

The more you start tweaking it, the possibility for creating a richer and more fulfilling ecosystem is very big, but also the risk is higher. From a high level point of view, the people that are designing tokenomics (us included), these are some of the risk/return trade-offs that we’re making. When we’re thinking about how to design a tokenomics framework that makes sense for Sui, we’re building one to the best of our ability that is somewhat stress-tested so we can forecast what it’s going to do.

Question #2: What’s special about Sui Tokenomics?

Alonso: That’s a great question. That’s a great question. I feel like right now crypto is becoming such a large space and it’s hard to keep track of everything that’s happening. There are a lot of things that are randomly emerging and they’re working in very different ways. So what’s special about Sui is that tokenomics are built very much in sync with the innovations and its engineering design.

This basically goes along two main avenues for Sui:

1. From an engineering perspective, everything that lives on the blockchain is designed as an object. When transactions on Sui are running with objects that are independent of each other, they can be executed in parallel.
2. Sui has the ability to handle arbitrary amounts of on chain data. We’ve designed Sui to make sure that anyone can use on chain storage. And if you’re going to use that storage, then you should pay for it.

This is different from what happens in more traditional blockchains, where every single transaction needs to be ordered relative to each other, even if the activities are completely independent. The implication for Sui here is that because of its ability to do causal ordering (in which only things that are somewhat related need to be ordered relative to each other but things that are completely independent can be executed in parallel), if demand for network activity increases at any given point in time, the chain can essentially scale horizontally. Each validator can add more computing power to make sure that they can execute these transactions in parallel, providing: high TPS, low latency, and good user experiences.

And here’s where the tokenomics comes in. If you have a chain that can handle a lot more of activity in any given moment in time, you don’t want the pitfalls of more traditional chains. In those instances, network activity increases in the short run, gas fees goes up, and it’s really bad for user experience. If I’m an ordinary user in an emerging market, and I have a lot of things that I wanted to on chain, I don’t want to live in a world where a lot of network activity means I’m gonna have to pay a lot of gas. That’s just bad user experience; it’s bad for my finances and it’s bad for the network.

And so Sui’s gas price mechanism is built in a way such that this horizontal scaling ability, of the chain to scale horizontally and to execute all these transactions at the same moment in time by adding more computing power, is built with a gas mechanism that ensures that gas fees are still low and predictable whenever this happens. That’s one of the big innovations of Sui. It goes hand-in-hand with this ability of making sure that everything that lives on the Sui blockchain is an object and executing these transactions in parallel.

The other big innovation that Sui has is the ability to handle arbitrary amounts of on chain data. For example, this is useful for people that may want to have metadata of their NFT to actually live on chain. From a tokenomics perspective, the main thing we’ve designed is to make sure that anyone should be able to use on chain storage, and if you’re going to use that storage then you should pay for it.

This opens up a lot of questions like:

• How do you actually make sure that whenever someone is executing a transaction (that’s going to store data on chain) that they pay for it?
• If they’re going to pay for it, are they going to pay for it for a finite amount of time or for an indefinite amount of time?
• If it’s going to be an indefinite amount of time, how do you make sure that those fees that they’re paying up front actually end up lasting in a way that is able to pay for those storage fees forever?

So from a high level, the tokenomics has been designed very much in sync with engineering innovations to deliver a tokenomics system that works very nicely with Sui’s infrastructure.

Question #3: How does the gas mechanism work and why is it particular to Sui?

Alonso: Yes, so Sui’s gas mechanism, when you first read about it, it sounds a bit complex; it really is designed to create the right incentives to align the interests of all of these participants. So basically, it delivers a really good user experience for the users, for the validators, and also for people that have an interest in the medium-to-long-term success as the owners of the Sui Token (the native asset of the Sui blockchain).

Essentially the high-level goal was to design a gas mechanism that could always deliver low predictable gas fees for users. One of the objectives of Mysten Labs is delivering a good user experience across the whole tech stack, and for us, the end users of Sui is what’s most important. So how do we do that? How do we create that?

First, let me talk a little bit about how Sui works. Sui basically divides time across epochs. An epoch is probably going to be about 24 hours. The epoch goes through user-submitted transactions, validators process those transactions, and they have the voting power over how the transaction proceeds, which is proportional to the amount of stake they have. At the end of the epoch, the stake rewards are referred to as rewards to the validators and participants in this proof of stake mechanism. And since we’ve run a delegated proof of stake mechanism, most of the stake that validators have actually comes from individual holders of the Sui token that are not running a validator themselves. Most of the reward that the validators make for executing transactions throughout an epoch will be paid out to the Sui token holders that delegated with them in the first place.

Now, how does this relate to the way gas fees work? In Sui, validators are the ones that set the gas free for the epoch. They set what is called a reference gas price. What happens is that validators collectively sit down at the beginning of an epoch and discuss what the reference gas price will be. That gas price is communicated to all the clients and all the participants in the Sui ecosystem so that an end user can know the reference gas price.

So that’s how it works. But then that opens up a bunch of questions. First of all, how do we make sure that validators don’t just set an extremely high gas price? Well, here’s where the gas mechanism is designed to create the right incentives for all participants. Essentially, what happens is that the stake reward distribution rule, which means the share of stake rewards that are distributed to validators at the end of the epoch, gets adjusted depending on what each validator submitted as their bid or quote for the reference gas price. What matters here is that the validators who said at the beginning of the epoch that they wanted the gas price to be relatively lower than others are going to get boosted rewards. This is a way of encouraging validators when they’re collectively setting low reference gas prices. At the end of the epoch, they will be rewarded with more stake awards.

Now, you might be concerned about how this might just be an optimal strategy for validators to get those stake rewards by setting a low reference gas price at the beginning of an epoch, but then start charging high gas prices as the epoch progresses. For that, we have an intricate mechanism in which the validators are in charge of evaluating each other all throughout the epoch. If a validator said, “Well, I want one reference gas price to be very low”, and they submit a quote at that level, but then throughout the epoch they do not execute transactions that come in at those low gas prices, they’re doing something wrong, right? The validators are going to be aggregating information about what each validator is doing. So at the end of the epoch, they submit their best evaluation of each other, and again, the stake reward distribution rule is adjusted given this evaluation.

Essentially, the stake reward distribution rule takes these two elements:

• It boosts the rewards of the validators that submit low reference gas prices.
• It penalizes the validators that don’t honor the quotes that they’d submitted originally.

Effectively, this ends up creating a gas mechanism that promotes low reference gas price because the validator is encouraged to set low reference gas prices. But not so low that validators’ business models become unprofitable that they are unable to process these transactions.

This is a win-win mechanism for everyone:

• End-users win by having low and predictable gas fees throughout the epoch.
• Validators win because they will only set reference gas prices at which they can operate with a viable business model, but it also encourages them to operate in a somewhat competitive landscape.
• Ultimately, Sui token holders also win because this promotes the long term growth of the ecosystem.

Question #4: How does the storage fund work and why is it suited to Sui?

Alonso: The gas mechanism is what would be related to more of the traditional workings of the Sui blockchain, except that here, we’ve created a mechanism that delivers low and predictable gas fees in a world where the blockchain is horizontally scalable. The storage fund comes hand in hand with the other part of the Sui blockchain, which is its ability to handle a lot of on chain data.

Now, the problem about the storage is the following:

If I’m a user today that is submitting a transaction and writing a lot of on chain data, that data in the future has to be stored by someone (e.g. validators, full nodes). In the future, once I have conducted my transaction, I can basically disappear off the face of the planet. But validators and full nodes still need to store that data.

What’s going to happen if I don’t pay for that storage today?

If those validators are going to pass those costs of storage to someone, they’ll probably have to pass it on to future users of Sui. And so that creates a negative externality because if I store a lot of data today and don’t pay for it, future users are going to have to pay for my storage and compensate for it. Now, that’s terrible for the network.

So then the economics point of view here is how do we solve that and how do we do it? We can solve it in a way that if you store data, you should pay for it. But this opens up a couple of questions:

• Should we do something simple like paying for storage for a finite amount of time?
• Or should we do something that has a much better user experience but is much harder to work out from an economic point of view, allowing data to be stored indefinitely?

So how do you make sure that the storage that you’re paying for will last potentially forever? What we’ve done is create a storage fund that recollects all the storage fees you pay when you store data. But the storage fund doesn’t actually pay future entities who are storing the data, it is used to adjust the share of stake rewards that are paid to validators relative to the ones that are paid to Sui token holders. If the validators have to store such a huge amount of upfront data that comes from users who previously stored data, they should get the proportionate amount of stake rewards to compensate for them. That’s how the storage fund works. It’s economically viable because the storage fund never pays out fees out of its principal, but is used to adjust the stake rewards that come from mainly the gas fees.

We wanted to make sure that from a storage perspective, we introduce the right incentive into the workings of Sui. What we’ve enabled is for users to essentially be able to delete their data and get a rebate. And so, in essence, if you keep data on chain today and decide that you no longer want that in six months time or whatever, you can get a pretty big refund of the storage fees that you paid initially. The storage fees are always intended to pay and to compensate for the entities that are storing the data. If you’re not a user and you deleted that data, this storage fee really shouldn’t be there. This is unlike what’s happening in web2. Let’s take DropBox as an example. You might be using DropBox today and paying an annual fee. But if in two years and you decide you no longer want to use DropBox, all that happens is that you close your account, and your data is deleted. No rebates.

Question #5: What will Sui token’s distribution look like?

Alonso: That’s a very important question. There will be 10 billion finite supply of tokens that will exist on the Sui blockchain. In a couple of weeks, we can share the exact percentages but what I can tell you right now is that the distribution of tokens will replicate what is standard in most protocols.

Some of the tokens will be set aside for the Mysten Labs team, Sui contributors, investors, and stake subsidies. There will be a public sale and we’ll deliver this information in the upcoming weeks. In terms of the distribution of tokens, I want to draw a lot of attention to the fact that a huge amount of tokens are being set aside for the Sui Foundation.

The Sui Foundation is an entity that is independent from Mysten Labs. The foundation’s goal is to promote the long-term growth and success of the Sui blockchain. The Sui Foundation will take tokens and use them for projects that support the cause:

• Fund hackathons, conferences, documentation, applications, and developers teams that are building on Sui, helping them create the right type of products that will bring users to Sui and let them benefit.
• Promote the strengths of Sui like interoperability, composability, etc.
• Develop ecosystem enablement. Funding projects like infrastructure, wallets, digital identity, standards type projects that are important for DeFi protocols and general functionality may be challenging to monetize now, but they will be really crucial for the network in the long term.

The real reason for these tokens to be set aside is to make sure that they can be distributed in a smart way across the community to create the projects that will enable the long term success of Sui.

We’ll give out a lot more information in the upcoming weeks specifically about the token allocation but also on the specifics on how the Sui Foundation will work, which as I said, is an independent entity. We’ll start releasing information on how the community members and developer teams can start accessing these grants and these tokens to start funding their own projects. This is so you can also start planning on what you’re going to build and what your business model is going to look like.

Question #6: What will this distribution look like on the mainnet?

Alonso: I think most of the tokens will actually be locked at the mainnet, and will be unlocked over the coming years. The public sale tokens will be liquid immediately and once Sui blockchain becomes live, so will the tokens accruing from stake subsidies that serve as stake rewards for the participants in the delegated proof of stake mechanism. But, the foundation tokens are delivered to the team, depending on the exact framework and the conditions in each specific arrangement. Those will also partially be liquid so that developer teams can actually start funding their projects in a business viable way.

Question #7: There are many different blockchains but in the end, it comes down to EVM. Is it hard to differentiate them? Do you have a perspective on the issue here?

Alonso: Yeah, and I think we have a surprise for everyone today, which is we brought one of our senior engineers and one of the most knowledgeable engineers that we have at Sui on crypto and blockchain-related issues, Mohan. I think it’s a great moment to bring him in, let him introduce himself and start answering questions too.

Mohan: Hi, this is Mohan! I work on Sui tokenomics as an engineer. I came from the Libra and Facebook team as well, and am now joining Mysten Labs. I have a prediction that in a few years, Sui’s structure and architecture will probably be very popular among other different experiments in this space.

We’re talking about the question of why everything comes down to EVM?

I think the core question that comes to that is, there’s not really much incentive to actually develop a new suitable-for-blockchain, virtual machine execution environment. There isn’t really a great monetization or incentive to actually do anything that is as complicated as a virtual machine in a runtime environment. It’s only made possible because world-class engineers were brought in, like our own Sam and all the other experts to come up with something like Move. I don’t think you can replicate that easily, especially in our space right now, where crypto is so young and propelled by speculation. And that’s probably the reason why everything comes down to VM. But I think that’s not good for the industry and I think pouring enough resources and effort to actually break the game and to actually think and build from first principles perspective, is the maximum value we can bring in Sui tokenomics. We’re the ones who broke the glass and really think from first principles.

I feel like that’s the value that we provide:

• Right incentive structure and innovation
• Sustainable growth of the network.

For example, I really love the storage fund design; I think that’s probably one of the most ingenious ones in the current space. All the problems we talked about were EVM compatible chains, they have these stake float issues, and it’s going to come and hit them in the future. But in the case of Sui having a storage account, it gives the user the incentive to free up some of the data in their space. When I think of someone who had been in crypto for almost 10 years and when I think about what’s stored on Ethereum, it sort of scares me. All the useless information that’s accumulated over the past decade, I don’t think storing all that is sustainable and I think a lot of experts in this field already know that.

Question #8: In terms of the overall landscape, what do you think are Sui’s main competitors? And how can we outperform them?

Alonso: Yeah, that’s a great question. We get asked this a lot. I think it’s useful to take a little bit of a step back and reframe this question.

In many ways, web3 is extremely early. If you ask an ordinary person whether they use crypto, they may say something about Bitcoin or their investments, but the truth of the matter is that use cases that web3 has been promising have not been delivered. And that’s both across financial services, digital commerce, NFTs, decentralized social media, anything you can think about. So the question is if web3 makes it, the pie will grow so much that there’s gonna be more than enough to go around. If anything, what’s probably going to happen in the future is multi-chain. Some chains may specialize in specific use cases, perhaps even specific demographics, there might even be really good cross-chain communication protocols.

When we think about Sui, it’s not on our best interest to think that we need to compete with other chains, but rather we need to think about the following:

• How do we actually onboard those next billion users?
• How do we create the user experience that is going to make it as simple for my mom that doesn’t know anything about crypto to do something on-chain as it is for her to communicate with her friends on WhatsApp, or to send an email on Gmail?

So, when I think about Sui competitors, we need to zone down and think about what is our product strategy for going to market and then having people build on Sui? And in that sense, we think about optimizing the user experience on all fronts. We’ve talked a lot about infrastructure today about Sui’s ability to have really high TPS and low latency, that’s great for applications. We haven’t talked so much about the Move programming language but, that’s something that’s very important for Sui because it’s really a language that was created to make it very safe for developers to build their products on the Sui blockchain. It’s created to make sure that developers can focus on what they do best, which is building stuff, and delivering new products and new use cases, and not having to spend enormous cycles on auditing their code and looking for bugs that just distracts and makes it very inefficient.

On the product side, we’re making a lot of effort to optimize our user experience. For example, having wallets that are very slick and smooth and let you interact with the blockchain without having to think too deeply about how you’re gonna manage private keys, how you’re going to discover other users on the blockchain, and how you’re going to interact with different applications that are running on the blockchain.

So I think this is really the way Sui should look at it. This is probably how all blockchain should look at it. We shouldn’t really be competing with each other, we should all be thinking about how we are actually going to bring those billion users that know nothing about crypto into web3, and actually build use cases that are going to serve their purposes. Because the vast majority of the world don’t really care about the tech that they’re using, they just care about having products that work and serve their interests. I think this is how we should think about it.

Question #9: How does Sui plan to expand users and markets?

Alonso: Yeah, for us in particular, we’re trying to address this across various verticals. We want to work very closely with the community but also, the Sui Foundation as an independent entity will work very closely with developer teams, to create all these use cases.

In addition to that, we’re working with external partners that will be able to either bring their existing web2 type applications to Sui or develop independent web3 native applications.

Here are the verticals that we particularly are most interested in pushing right now:

• The gaming front, where we think there’s a lot more terrain to be covered than has been so far.
• The finance front, this includes both traditional finance and DeFi, the use cases in DeFi that haven’t been successful yet (e.g. uncollateralized lending) are going to be very important for people that don’t have access to not only on-chain assets that they can use as collateral but just assets in general. So, we need to think about what is the complimentary type of infrastructure that we need, maybe it has something to do with digital identity, and maybe it has to do with reputation-based systems.
• Digital commerce, that has to do everything from payments to peer-to-peer transfers to letting big merchants distribute coupons on the blockchain and letting users redeem them, and even ticketing for concerts.
• Social media including everything related to it. Communication and content creation.

Our hope really is to make success on this promise of really onboarding the next billion users to web3. We’re really thinking about the applications, developing the new use cases, and documents to serve that purpose.

Question #10: How does the roadmap look and when will Sui launch it to the world?

Alonso: That’s a good question, I’m going to let Mohan tell a little bit about the technical stuff related to what’s already running. Just to give you a very high level of the roadmap, right now, the devnet is already live. If you haven’t tried it out, please do, you can go to Sui.io and all the information is there. Hopefully, we’ll give a precise date soon but in the coming weeks, we will start releasing the test net and the incentivized test net. The goal really is to make sure how we can be hard in the protocol and make sure that validators and network operations are operating smoothly.

Whilst we’ll be testing some of the tokenomics elements during that period, after we’re done with the incentivized tests that will go to the mainnet, hopefully, by the end of this year, the Sui token will be live. It will be a fully permissionless, fully decentralized blockchain and you’ll be essentially able to do everything you do with other decentralized and permissionless blockchains. Except that here, you will have all the power of the Sui’s infrastructure, you’ll have the Move programming language, and you’ll have hopefully, the good user experience of the Sui tokenomics will give you.

So that’s sort of a very high-level overview of our roadmap. Mohan, would you like to say anything from an engineering point of view in terms of how the devnet, testnet, and mainnet progression are going?

Mohan: Yeah, I think you pretty much covered most of it, and I’ll go to the basic stuff running for the devnet over the staking delegation, and the basic structure for the gas incentives has been implemented and some of them are on-chain using written loops on the off-chain written in Rust code. For the incentives, we’ll start testing the structure of some of the rules, where we try to make sure to produce a stable gas reference price. We can ensure our gas price is changing around that reference gas price. In the incentive test we’re also planning to get a storage fund up and running, to work on the refund of the storage rebate, and to monitor and collect some data on that as well. We’re gonna go with most of the future we described in the paper. That’s the plan right now.

Question #11: In terms of early contributors, they’re an important asset to the protocol. How do you reward them as the protocol grows?

Alonso: Yeah, that’s a great question. I want to underline one thing. Sui is nothing without its community. This is a community project, and early contributors are key elements of that. A lot of the things that the Sui Foundation does is making sure that the early contributors get incentives that will let them thrive both in the short term but also in the long run. We made a token allocation to incentivize good projects. These will essentially deliver the Sui token holder the ability to thrive and benefit from the network’s success.

Being an early contributor to Sui will give the contributors two things:

• The advantage of being on the protocol and knowing how to develop a smart contract on it. If you’re successful, because of the beautiful things that blockchains have like composability and interoperability, other blocks building on the Sui blockchain can interact with yours.
• The token allocations will end up being more valuable in the future, given as more activity runs on the blockchain.

If anyone has any more ideas, we have an active Discord and members that can answer questions on anything related to engineering, tokenomics, or testnet. If you have any feedback or anything you’d like to see, please do let us know.

Question #12: What happens when the big staking firms set their fees to zero to attract delegated stake, and smaller validators can’t afford to get started?

Alonso: Yeah, that’s a great question. I want to state again that Sui is a delegated proof of stake system. So for the vast majority of validators, most of the tokens that they get will not actually be made by them, but will actually be delegated by the people who own the Sui token and want to participate in the community. Having said that, there’s of course, the risk that big players can amass a large amount of tokens and in a sense “control the network”. That would be very detrimental to Sui’s long-term success. So the Sui Foundation has an enormous amount of tokens that they’ll use to fund projects throughout the lifetime of the Sui blockchain. In the beginning, most of the tokens will probably not be given out yet because the Sui foundation is not going to fund all projects on day one. Rather, it will distribute these tokens over several years.

In the meantime, most of those tokens are going to be used for staking and that’s also what’s great about Sui Foundation because that means you can get some of the rewards that are associated with that token. That will fund even more trajectory in the ecosystem.

What that means for validators, is that since the Sui Foundation’s interests are aligned regarding views of decentralization and distributed networks, Sui will see to find validators that are perhaps even owned by the community that has the resources and expertise to run a validator. The Sui foundation will lend them tokens and delegate tokens so that these small validators can compete with larger rigs. Because it’s a delegated proof of stake mechanism, those small validators getting large validator tokens from the Sui Foundation will be able to increase their own capital and fund their business model. And so while these concerns are very clear, multiple entities on the Sui ecosystem that exist to help community members that are running validators be successful.

Jen: So couldn’t the storage fund model be too costly for the use cases of short term data storage? Let’s take the DropBox analogy that was shared. You pay for a year upfront, then renew if you want to keep storing. If you had to pay for perpetual storage upfront, it really would lock up a lot of capital inefficiently. Is that the case?

Alonso: For the vast majority of use cases on this Sui blockchain, storage fees will be negligible. So everything that has to do with, for example, peer-to-peer transfers, payments, things that have to do with digital commerce, probably most of the stuff related to financial services, almost everything there will have negligible storage fees. So for the vast majority of people, this is not something they will have to worry about.

In some ways, the model is a little bit more capital heavy than what you would have in a world where you are paying for that storage on an ongoing basis, for example a rent model.

In a rent model, we’d say we’re going to pay for storage every year and whenever you stop paying that then the storage gets deleted. That’s why we went for our storage model, we think it just delivers a much better user experience in the sense that it’s much better to just rent and pay the storage fee, forget about it, and if you ever want to delete, you can delete and get the rebate. But the rent model in which you have to continuously think about how much data you’re storing, I pay a storage fee this year, maybe next year I think about it again, but for the vast majority of users this just introduces friction and makes things much more complicated. This sort of friction scales when you start having millions or even billions of users and transactions every year.

You might say fine, but some users just don’t have the capital to do that. Right? Some users might just not have to have the amount to pay the perpetual service fee. They might get a rebate in the future, but they just don’t have that liquidity.

I think what will happen is that you will see some DeFi-type protocols that will essentially lend to you what is needed to pay for that storage, they charge a small premium, and this contract might be such that the moment they stop paying that premium, the data gets deleted. So in many ways, once the financial ecosystem becomes more complete we’ll create solutions that will somewhat replicate what the rent model is, which is more capital efficient, but has worse user experience for the people who are interested in it.

Thank you for tuning into our Tokenomics AMA! If you have any feedback about how the AMAs were conducted, please don’t hesitate to reach out to social@mystenlabs.com with your input. We’re always looking to improve.

Learn more about Sui

• Sui Website — https://sui.io/
• Sui Developer Portal — https://docs.sui.io/
• Move Programming Language
• Sui Whitepaper
• Community forums

Build with us!!

We’re excited about what the future unfolds and invite creators and builders to join us.

Recap Sui AMA: Tokenomics was originally published in Mysten Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

Summary: Download the Sui Wallet V0.0.2 here.

It’s been an action-packed week where we announced the Sui incentivized testnet, Move VSCode, and Sui Move, and to close out the week with a bang we would like to introduce the Sui Wallet — a Chrome extension self-custody wallet.

What is the Sui Wallet?

The open-sourced Sui Wallet gives Sui users the ability to create an address, view and manage assets on the Sui network, and interact with dApps. The Sui Wallet serves as a reference implementation for other potential wallets and applications in the Sui ecosystem. To that end it will showcase the latest and most unique Sui capabilities. We believe the Sui Wallet repo will act as an important ecosystem enablement tool as Sui starts to support at scale use cases, Move-powered ownership models, and other features unique to Sui.

The Sui Wallet will adapt based on input from the developer community. Make sure to join our Sui Discord and provide feedback directly on the #general or #suggestions channels.

What’s Next?

The path to true Web3 adoption is an empowered developer community and the ecosystem at large. The Sui team is building the best, high performance blockchain for wide adoption — and the best ideas, applications, and businesses will come from the community.

The Sui Wallet is a tool for ecosystem enablement and education and not meant to be the de facto wallet. We are open to collaboration and are eager to see what our community will build. In fact, the current definitions of a crypto wallet can be limiting and not optimized for rapid user adoption and massive web2 migration. As wallet builders start to push for the next iteration of wallets we too look forward to seeing what the Sui community will dream up.

Select Features in V0.0.2

Create account or import an existing wallet

Transfer SUI tokens and NFTs

Simple wallet connect with example dApp that mints custom NFT

View history and verify on Sui Explorer

Human-readable transaction signing

Instead of only showing a serialized transaction signing request and letting you guess, Sui wallet clearly shows the contents of the transaction so that you can sign with confidence. More is work in progress!

Upcoming Features

• New designs
• Onboarding flow optimization
• Staking flow
• Wallet to application communication
• DApps discovery

Useful Links

• SDK Source Code/README
• Sui Wallet Repo
• Join Discord and share any feedback in the #general or #suggestions channels
• Request tokens in the #devnet-faucet channel
• Sui Website — https://sui.io/
• Sui Developer Portal — https://docs.sui.io/

Introducing Sui Wallet was originally published in Mysten Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

Highlights covered in this article:

• Sui Move is feature complete and ready for you to write safe and efficient smart contracts
• Sui is the first blockchain to improve on the original Diem design in how it integrates Move, and we share concrete examples of these improvements.

Introduction

Move was born in 2018 during the early days of the Libra project — two Mysten founders (Evan and myself) were also on the founding team of Libra. Before we made the decision to create a new language, the early Libra team intensely studied existing smart contract use cases and languages to understand what developers wanted to do and where existing languages were not delivering. The key problem we identified is that smart contracts are all about assets and access control, yet early smart contract languages lack type/value representations for both. The Move hypothesis is that if we provide first-class abstractions for these key concepts, we can significantly improve both the safety of smart contracts and the productivity of smart contract programmers — having the right vocabulary for the task at hand changes everything. Over the years, numerous folks contributed to the design and implementation of Move as the language evolved from a key idea into a platform-agnostic smart contract language with the bold goal of becoming the “JavaScript of web3”.

Today, we are excited to announce a milestone in our integration of Move into Sui: Sui Move is feature complete, supported by advanced tooling, and has extensive documentation and examples, including:

• A tutorial series on programming with Sui Move objects
• A cookbook of Sui Move basics, design patterns, and samples
• Enhanced VSCode plugin with support for code comprehension and error diagnostics built by the Mysten Move team!
• Integration of Move builds, tests, package management, documentation generation, and the Move Prover with the sui CLI
• A suite of examples including fungible tokens, NFT’s, DeFi, and games.

When we started working on Sui in late 2021, we took a fresh look at Move and reflected both on which early design decisions have not aged well and on how Move could be improved to leverage Sui’s unique features. We have previously written about what’s new in Sui Move at the language level, but we haven’t gone into depth on the motivation for introducing these differences. The remainder of this post covers this inquiry in detail in an example-driven fashion.

Wait, there are different Move’s?

Move is a cross-platform, embedded language. The core language itself is very simple: it has generic concepts, such as structs, integers, and addresses, but it does not have blockchain-specific concepts like accounts, transactions, time, cryptography, etc. These features must be provided by the blockchain platform that integrates Move. Importantly, these blockchains do not need their own fork of Move — each platform uses the same Move VM, bytecode verifier, compiler, prover, package manager, and CLI, but adds blockchain-specific features via code that builds on top of these core components.

Diem was the first blockchain to embed Move, and subsequent Move-based chains (including 0L, StarCoin, and Aptos) have largely used the Diem-style approach. Although Diem-style Move has some nice qualities, both the permissioned nature of Diem and certain implementation details of the Diem blockchain (particularly the storage model) make the implementation of some fundamental smart contract use cases difficult. In particular, the original designs of Move and Diem predated the popularity explosion of NFTs and have some quirks that make NFT-related use cases especially tricky to implement.

In this post, we will walk through three such examples that showcase a problem with the original Diem-style Move embedding and depict how we have addressed this problem in Sui Move. We assume some basic understanding of Move, but hopefully, the key points will be understandable to anyone with a programming background.

Frictionless mass asset creation

The ability to create and distribute assets in bulk is crucially important for both onboarding and engaging web3 users. Perhaps a Twitch streamer wants to distribute commemorative NFTs, a creator wants to send out tickets for a special event, or a game developer wants to airdrop new items to all of its players.

Here is a (failed) attempt to write code for mass minting of an asset in Diem-style Move. This code takes a vector of recipient addresses as input, generates an asset for each one, and attempts to transfer the asset.

struct CoolAsset { id: GUID, creation_date: u64 } has key, store

public entry fun mass_mint(creator: &signer, recipients: vector<address>) {
  assert!(signer::address_of(creator) == CREATOR, EAuthFail);
  let i = 0;
  while (!vector::is_empty(recipients)) {
    let recipient = vector::pop_back(&mut recipients);
    assert!(exists<Account>(recipient), ENoAccountAtAddress);
    let id = guid::create(creator);
    let creation_date = timestamp::today();
    // error! recipient must be `&signer`, not `address`
    move_to(recipient, CoolAsset { id, creation_date })
}

In Diem-style Move, the global storage is keyed by (address, type name) pairs — that is, every address can store at most one asset of a given type. Thus, the line move_to(recipient, CoolAsset { ... } is attempting to transfer the CoolAsset by storing it under the recipient address.

However, this code will fail to compile at the line move_to(recipient, …). The key problem is that in Diem-style Move, you cannot send a value of type CoolAsset to an address A unless:

1. A non-A address sends a transaction to create an account at A
2. The owner of A sends a transaction to explicitly opt-in to receiving objects of type CoolAsset

That’s two transactions just to receive an asset! The decision to do things this way made sense for Diem, which was a permissioned system that needed to carefully restrict account creation and prevent accounts from holding too many assets due to limitations in the storage system. But this is extremely restrictive for an open system that wants to use asset distribution as onboarding mechanism, or just generally allow assets to flow freely between users as they do on Ethereum and similar blockchains [1].

Now, let’s look at the same code in Sui Move:

struct CoolAsset { id: VersionedID, creation_date: u64 } has key

public entry fun mass_mint(recipients: vector<address>, ctx: &mut TxContext) {
  assert!(tx_context::sender(ctx) == CREATOR, EAuthFail);
  let i = 0;
  while (!vector::is_empty(recipients)) {
    let recipient = vector::pop_back(&mut recipients);
    let id = tx_context::new_id(ctx);
    let creation_date = tx_context::epoch(); // Sui epochs are 24 hours
    transfer(CoolAsset { id, creation_date }, recipient)
  }
}

Sui Move’s global storage keyed by object ID’s. Every struct with the key ability is a “Sui object” that must have a globally unique id field. Instead of using the restricted move_to construct, Sui Move introduces a transfer primitive that can be used on any Sui object. Under the hood, this primitive maps id to CoolAsset in the global storage and adds metadata to indicate the value is owned by recipient.

An interesting property of the Sui version of mass_mint is that it commutes with all other transactions (including others that call mass_mint!). The Sui runtime will notice this and send transactions that call this function through the Byzantine consistent broadcast “fast path” that doesn’t need consensus. Such transactions can be both committed and executed in parallel! This requires no effort from the programmer—they just write the code above and the runtime takes care of the rest.

Perhaps subtly, this is not true of the Diem variant of this code — even if the code above worked, both the exists<Account> and guid::create calls would create points of contention with other transactions generating GUIDs or touching the Account resource. In some cases, it’s possible to rewrite Diem-style Move code to avoid points of contention, but many of the idiomatic ways of writing Diem-style Move introduce subtle bottlenecks that frustrate parallel execution.

Native asset ownership and transfers

Let’s extend the Diem-style Move code with a workaround that will actually compile and run. The idiomatic way to do this is the “wrapper pattern”: because Bob can’t directly move_to a CoolAsset to Alice’s address, we ask Alice to “opt in” to receiving CoolAsset's by first publishing a wrapper type CoolAssetStore with a collection type (Table) inside. Alice can do this by calling the opt_in function. We then add code that allows Bob to move a CoolAsset from his CoolAssetStore into Alice’s CoolAssetStore.

In this code, let’s add one other wrinkle: we will only allow CoolAsset's to be transferred if it has been at least 30 days since they were created. This sort of policy is important for creators that (e.g.) want to discourage speculators from purchasing/flipping event tickets so it is easier for true fans to get them at a reasonable price.

struct CoolAssetStore has key {
  assets: Table<TokenId, CoolAsset>
}

public fun opt_in(addr: &signer) {
  move_to(addr, CoolAssetHolder { assets: table::new() }
}

public entry fun cool_transfer(
  addr: &signer, recipient: address, id: TokenId
) acquires CoolAssetStore {
  // withdraw
  let sender = signer::address_of(addr);
  assert!(exists<CoolAssetStore>(sender), ETokenStoreNotPublished);
  let sender_assets = &mut borrow_global_mut<CoolAssetStore>(sender).assets; 
  assert!(table::contains(sender_assets, id), ETokenNotFound);
	let asset = table::remove(&sender_assets, id);
  // check that 30 days have elapsed
  assert!(time::today() > asset.creation_date + 30, ECantTransferYet)
	// deposit
	assert!(exists<CoolAssetStore>(recipient), ETokenStoreNotPublished);
  let recipient_assets = &mut borrow_global_mut<CoolAssetStore>(recipient).assets; 
  assert!(table::contains(recipient_assets, id), ETokenIdAlreadyUsed);
  table::add(recipient_assets, asset)
}

This code works. But it’s a pretty complex way to accomplish the simple goal of transferring an asset from Alice to Bob! Again, let’s look at the Sui Move variant:

public entry fun cool_transfer(
  asset: CoolAsset, recipient: address, ctx: &mut TxContext
) {
  assert!(tx_context::epoch(ctx) > asset.creation_date + 30, ECantTransferYet);
  transfer(asset, recipient)
}

This code is much shorter. The key thing to notice here is that cool_transfer is an entry function (meaning it can be called directly by the Sui runtime via a transaction), yet it has a parameter of type CoolAsset as an input. This is Sui runtime magic at work again! A transaction includes the set of object ID’s it wants to operate on, and the Sui runtime:

• Resolves the ID’s to object values (removing the need for the borrow_global_mut and table_remove parts in the Diem-style code above)
• Checks that the object is owned by the sender of the transaction (removing the need for the signer::address_of part + associated code above). This part is especially interesting, as we will explain shortly: in Sui, safe object ownership ownership checks are part of the runtime!
• Checks the types of the object values against the parameter types of the invoked function cool_transfer
• Binds the object values and other arguments to the parameters of cool_transfer and invokes the function

This allows the Sui Move programmer to skip the boilerplate of the “withdraw” part of the logic and jump straight to the interesting part: checking the 30-day expiration policy. Similarly, the “deposit” part is vastly simplified via the Sui Move transfer construct explained above. And finally, there’s no need to introduce a wrapper type like CoolAssetStore with an internal collection—the id-indexed Sui global storage allows an address to store an arbitrary number of values with a given type.

One other difference to point out is that there are 5 ways the Diem-style cool_transfer can abort (i.e., fail and charge the user for gas without completing the transfer), whereas the Sui Move cool_transfer can only abort in 1 way: when the 30-day policy is violated.

Offloading object ownership checks to the runtime is a big win not only in terms of ergonomics, but also in terms of safety. Safe implementations of this at the runtime level prevents the mistakes of implementing these checks (or forgetting them entirely!) by construction.

Finally, notice how the Sui Move entry point function signature cool_transfer( asset: CoolAsset, ...) gives us a lot of information about what the function is going to do (in contrast to the Diem-style function signature, which is more opaque). We can think of this function as asking permission to transfer CoolAsset, whereas a different function f(asset: &mut CoolAsset, ...) is asking for permission to write (but not transfer) CoolAsset, and g(asset: &CoolAsset, ...) is only asking for read permissions.

Because this information is available directly in the function signature (no execution or static analysis required!), it can be used directly by the wallet and other client tooling. In the Sui wallet, we are working on human-readable signing requests that leverage these structured function signatures to provide an iOS/Android-style permissions prompt to the user. The wallet can say something like “This transaction is asking for permission read your CoolAsset, write your AssetCollection, and transfer your ConcertTicket. Proceed?”.

Human-readable signing requests address a massive attack vector present on many existing platforms (including ones using Diem-style Move!), where wallet users must blindly sign transactions without understanding what their effects might be. We think making the wallet experience less dangerous is a key step for promoting mainstream adoption of crypto wallets, and have designed Sui Move to support this goal by enabling features like human-readable signing requests.

Bundling heterogenous assets

Finally, let’s consider an example concerning bundling assets of different types. This is a fairly common use-case: a programmer might might want to package NFT’s of different types in a collection, bundle items to be sold together in a marketplace, or add accessories to an existing item. Concretely, let’s say we have to following scenario:

• Alice has defined a Character object to be used in a game
• Alice wants to support accessorizing her character with third-party accessories of different types created later
• Anyone should be able to create an accessory, but the owner of a Character should decide whether to add an accessory or not.
• Transferring a Character should automatically transfer all of its accessories.

This time, let’s start with the Sui Move code. We will take advantage of another facet of the Sui runtime’s built-in object ownership feature: an object can be owned by another object. Every object has a unique owner, but a parent object can have an arbitrary number of child objects. Parent/child object relationships are created by using the transfer_to_object function, a sibling of the transfer function introduced above.

// in the Character module, created by Alice
struct Character has key {
  id: VersionedID,
  favorite_color: u8,
  strength: u64,
  ...
}

/// The owner of `c` can choose to add `accessory`
public entry fun accessorize<T: key>(c: &mut Character, accessory: T) {
  transfer_to_object(c, accessory)
}

// ... in a module added later by Bob
struct SpecialShirt has key {
  id: VersionedID,
  color: u8
}

public entry fun dress(c: &mut Character, s: Shirt) {
  // a special shirt has to be the character's favorite color
  assert!(character::favorite_color(c) == s.color, EBadColor);
  character::accessorize(c, shirt)
}

// ... in a  module added later by Clarissa
struct Sword has key {
  id: VersionedID,
  power: u64
}

public entry fun equip(c: &mut Character, s: Sword) {
  // a character must be very strong to use a powerful sword
  assert!(character::strength(c) > sword.power * 2, ENotStrongEnough);
  character::accessorize(c, s)
}

In this code, the Character module includes an accessorize function that lets the owner of a character add an accessory object with an arbitrary type as a child object. This allows Bob and Clarissa to create their own accessory types with different attributes and functionality that were not anticipated by Alice, yet build on what Alice has already done. For example, Bob’s shirt can only be equipped if it is the character’s favorite color, and Clarissa’s sword can only be used if the character is strong enough to wield it.

In Diem-style Move, it is not possible to implement this sort of scenario. Here are a few attempts at implementation strategies that fall short:

// attempt 1
struct Character {
  // won't work because every Accessory would need to be the same type + have
  // the same fields. There is no subtyping in Move.
  // Bob's shirt needs a color, and Clarissa's sword needs power--no standard
  // representation of Accessory can anticipate everything devs will want to
  // create
  accessories: vector<Accessory>
}

// attempt 2
struct Character {
  // perhaps Alice anticipates the need for a Sword and a Shirt up front...
  sword: Option<Sword>,
  shirt: Option<Shirt>
  // ...but what happens when Daniel comes along later and wants to add Pants?
}

// attempt 3
// Does not support accessory compositions. For example: how do we represent a 
// Character with Pants and a Shirt, but no Sword?
struct Shirt { c: Character }
struct Sword { s: Shirt }
struct Pants { s: Sword }

The key problems are that in Diem-style Move:

• Only homogenous collections are supported (as the first attempt demonstrates), but accessories are fundamentally heterogenous
• Associations between objects can be created only via “wrapping” (i.e., storing an object inside another object); but the set of objects that can be wrapped must be defined up-front (as in the second attempt) or added in an ad-hoc fashion that does not support accessory composition (as in the third attempt)

Conclusion

Sui is the first platform to diverge substantially from the original Diem design in how it uses Move. Designing embeddings that fully leverage Move and the unique features of the platform is both an art and a science that requires a deep understanding of both the Move language and the underlying blockchain’s capabilities. We’re really excited about the advances Sui Move has made and the new use cases it will enable!

[1] Another argument made in favor of the Diem-style Move policy of “must opt-in to receive an asset of a given type” is that it is a good mechanism for spam prevention. However, we think spam prevention belongs to the application layer. Rather than asking users to send transactions that cost real money to opt in to receiving an asset, spam is easily addressed at (e.g.) the wallet level with rich user-defined policies and the aid of automated spam filters.

Learn more about Sui

• Sui Website — https://sui.io/
• Sui Developer Portal — https://docs.sui.io/
• Move Programming Language
• Sui Whitepaper
• Community forums

Build with us!!

We’re excited about what the future unfolds and invite creators and builders to join us.

Why We Created Sui Move was originally published in Mysten Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

Over the last few months, Mysten Labs has been working hard on new features for the Move language’s VSCode plugin (a plugin for the Visual Studio Code editor). And we are now finally ready to share what we have accomplished with the wider developer community. The plugin is intended to work both with the core Move language and with all existing Move language flavors such as Sui Move.

The VSCode plugin for Move is called move-analyzer and it is available in the Visual Studio Marketplace. The new features are supported via the Language Server Protocol; in order to unleash the full potential of the plugin, in addition to installing the plugin itself, you also need to install move-analyzer’s language server as described in installation instructions provided with the plugin distribution.

The Language Server Protocol (LSP) was originally introduced by Microsoft, but it is also supported by a range of other code editors and Integrated Development Environments (IDEs), such as Sublime Text or Eclipse. It is a standard protocol where an editor of an IDE can “ask” the language server for certain types of information concerning the code being edited. And it lets you visualize data obtained in a way that both enhances and simplifies the code development process. We hope to integrate these new features with other editors of IDEs, ideally with the help of the Move language community.

The new features provided by the current version of move-analyzer’s language server fall into two main categories: code comprehension and error reporting. They have been implemented by integrating the language server with the “standard” Move compiler (the compiler that was co-developed with the language and is part of the main Move source code repository). This integration not only guarantees accuracy of the information provided by the language server (e.g., error messages visualized by an editor or an IDE will directly correspond to error messages generated by the compiler), but it will also simplify the language server maintenance in the face of potential future Move language changes. You will find the description of the new features below, and you can also view a demo of the new features in this video:

Code comprehension

One of the problems with more traditional smart contract languages that the Move language design is trying to solve is code composition and reuse. To enable code reuse, the code can be grouped into packages (e.g., a standard library package), and these packages can be shared across different smart contract implementations. This means that developers writing new smart contracts may have to deal with a code base that is largely unknown to them.

The new VSCode plugin delivers a set of features that can aid developers in better understanding their entire code base.

Type on hover

When encountering an identifier in an unknown code base, you may not know the type of the identifier. If you hover a cursor over the name of an identifier (e.g., a name of a local variable or a name of a function), you will see the name of this identifier displayed in a tooltip. See this example.

Go to definition

Another piece of information about an identifier that may not be immediately obvious is where this identifier is defined — it may just as well be a local variable defined in the same function but also, for example, a function defined in a different module. If you right-click on the identifier name and choose the Go to Definition option from the menu, your cursor will be transported to the location of the identifier’s definition. See this example.

Go to type definition

Even if you know where the definition of a given identifier is, and you know the name of its type, it does not necessarily mean that it is trivial to locate its type definition. For example, you may already know that the identifier type is struct SomeStruct but you will still not know what are the fields of this struct. If you right-click on the identifier name and choose the Go to Type Definition option from the menu, your cursor will be transported to where the type of this identifier is defined. See this example.

Find references

The latest feature enhancing code comprehension is the ability to find all occurrences of a given identifier in the entire code base. This can be useful, for example, if you would like to know where a given function is being called. If you right-click on the identifier name and choose the Find All References option from the menu, all occurrences of this identifier will be displayed in the left pane of the VSCode editor window. See this example.

Error reporting

A standard method of obtaining compiler diagnostics (errors but also warnings) for a piece of Move code is to run the compiler on the command line and observe the output it produces. While this method is certainly sufficient, it may not be the most convenient. Instead, what we introduce in the new version of the VSCode plugin is displaying compiler diagnostics in the editor window. Whenever you save a file, the language server will run the compiler in the background and send the resulting output back to VSCode to be displayed (information concerning code comprehension is also recomputed at the same time). See this example.

Learn more about Sui

• Sui Website — https://sui.io/
• Sui Developer Portal — https://docs.sui.io/
• Move Programming Language
• Sui Whitepaper
• Community forums

Build with us!!

We’re excited about what the future unfolds and invite creators and builders to join us.

Announcing Enhanced Move VSCode Plugin was originally published in Mysten Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

It has been quite a whirlwind. While it was only four months ago that we announced Sui to the world, it feels like several lifetimes have since passed. Many crypto and blockchain community members — us included! — have witnessed repeated ups and downs. Yet, we believe these moments of extreme market volatility represent the best opportunity to hunker down and build the infrastructure to onboard web3’s next billion users.

Today, we are ready to announce that Sui’s Incentivized Testnet will kick off in August. This stage is the next step towards launching a secure, performant, and decentralized blockchain network.

Our team has been hard at work since our initial announcement. We:

• Finalized the design and implementation of Sui Move, an improvement on the original Move instantiation in Diem optimized for ergonomic and highly parallelizable code
• Open sourced Narwhal/Tusk consensus and integrated it with Sui to support shared object transactions
• Released a public DevNet for early Sui builders and partners
• Shipped the Sui Explorer that leverages Sui’s object-centric data model to display transactions and their effects in a human-readable fashion
• Launched fullnodes to an enthusiastic response from our community, with more than 5,000 nodes running in 65 countries and 271 cities and counting!

Speaking of our Sui community, we would like to take this opportunity to express our gratitude for your engagement, thoughtfulness, and commitment. We appreciate our partners, investors, DevNet builders, fullnode operators, GitHub contributors, Discord moderators and participants, social media followers, and everyone else who has dedicated their time and energy to Sui — we are fully dependent on you! Our community has repeatedly shown the value and importance of public feedback throughout the early phases of a major undertaking like Sui.

Sui Testnet Roadmap

Sui’s testnet will steadily progress from the first multi-entity Sui network toward a decentralized mainnet operated by an evolving set of independent and distributed validators. The testnet will gradually introduce and stress-test the key features, mechanisms required for a decentralized, production-ready Sui network. The testnet aims to validate our designs, test our validator, full node, wallet, and developer toolchains, and build operational experience with a cohesive group of high-quality operators. We will graduate from Testnet to mainnet when we are fully confident in the security and performance of our software, have seen sustained operational excellence from our initial validators, and validate our developer experience via compelling Move-powered applications deployed on testnet.

Sui’s Testnet is organized as a series of consecutive “waves” 🌊

Each wave consists of two challenges: a “sink” (an operational challenge) or a “swim” (a Move-based Sui developer challenge).

Here is what we know about the first three waves. We intentionally include more detail on earlier waves to give ourselves the flexibility to augment later waves based on what we learn:

Network

• Sink: A multi-entity public Sui network will come together for the first time. This will test our distributed genesis ceremony, validator configuration, operational coordination, and basic network operations.
• Swim: The first opportunity for Sui developers to deploy on Testnet. We have big plans for this challenge that we will announce shortly; but for now we will only give one cryptic hint: Capybaras!

Staking

• Sink: A Delegated Proof-of-Stake mechanism secures the Sui network through an array of network incentives aligning the interests of all Sui stakeholders. Any entity should be allowed to amass sufficient SUI tokens and participate as a validator in Sui’s DPoS mechanism. In this wave, we aim to test both the design and implementation of Sui’s key economic mechanisms.
• Swim: A challenge focused on building and deploying financial primitives, particularly staking derivatives and DeFi basics.

Updates

• Sink: Operating a stable and secure high-throughput network is no picnic. This wave will test our operators as they drill key network operations, such as validator set changes, software updates, and incident responsiveness.
• Swim: A challenge connected to our soon-to-be-announced Move hackathon during Science of Blockchain week.

Incentives

Sui’s Testnet will feature a menu of incentives to encourage and reward meaningful participation during the Testnet waves. These incentives will be available to network operators, users, developers, and other community members according to clear and well-specified guidelines. Our Incentivized Testnet will be a learning experience that will require hard work from both the Mysten Labs team and the Sui community for success. Our goal is to make the most out of the Incentivized Testnet and ensure that Sui is battle-tested and ready for mainnet.

In addition, the Sui Foundation will come live during the early waves of Testnet and become a crucial investment partner for the Sui network. The Sui Foundation’s mandate entrusts it with the mission of disseminating Sui education, promoting and bolstering use cases, applications, ancillary infrastructure and services, leading to the network’s long-term success. The Sui Foundation will achieve these goals by distributing token grants and providing developer support for users and builders of the Sui network. Stay tuned!

Land ahoy!

This blog post introduces what will now be a series of articles on Sui’s Incentivized Testnet to be released on a regular cadence starting this week. In the following weeks, we will be providing additional information related to specific dates, milestones, and requirements related to the Incentivized Testnet waves.

We hope this announcement serves the purpose of further rallying Sui’s early contributors, potential validators, developer teams, and other friends of Sui. A call to muster their fleets, unfsrc your sails and be prepared to ship, ship, ship and make Sui deliver on its promises.

As sailors might say, land ahoy! Mainnet is nigh, and Incentivized Testnet is a singular opportunity to harden Sui’s protocol, sharpen its code, and get Sui’s infrastructure cool and ready to catch those waves. As a community, we will sink unless we all swim together 🏊. Testnet is the last stage before Sui transitions into a fully-owned and fully-led community project. Join us in this endeavor. Be part of Sui today so that Sui can be yours tomorrow. If you are in, please:

• Participate in Sui’s ongoing DevNet by running a Sui fullnode, learning Move and deploying Move smart contracts, minting NFTs, or browsing the Sui Explorer
• Post your questions and feedback on Sui’s Discord channel
• Listen to our weekly AMA sessions on Sui’s Twitter spaces
• Keep your eyes peeled for the upcoming post on the next steps for Sui’s Incentivized Testnet

Yours,
The Mysten Labs Team

Announcing Sui Incentivized Testnet was originally published in Mysten Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

Note: You can find further information regarding Move Programming Language on our Sui Developer Portal.

Introduction

Jen: Thank you so much for tuning into our second installment of our AMA. This time the theme is our Move programming language. I’m really happy to introduce our lovely guests, Todd and Damir, our Move Programming Engineers at Mysten Labs!

Todd: My name’s Todd and I’ve been working on Move since 2018. I do the compiler stuff as well as Sui integration work.

Fun fact: I’ve been at Mysten since March and prior to this I was at Facebook (or Meta) for eight years. So it’s been fun in the startup space.

Damir: I’m Damir and I’ve been coaching and using Move since 2019 when the folks at Facebook were just developing the language. I’ve been through the first phase of Move IR and then started using Move. Before they had written any documentation for the language, I wrote the first book about the language.

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

Todd: As far as history, Move was created as the programming language for the Libra and the Diem project at Meta. Meta was looking at smart contract programming languages and trying to find something appropriate for the project and nothing really fit the bill. When we’re looking at other blockchain programming languages, namely Solidity, it doesn’t have assets or other blockchain items as first class items. In some ways, it looks like Javascript where you’re trying to build up programming your value from mappings, but it doesn’t really have an asset first programming model.

So, I started looking at these ideas from linear logic, linear programming, linear type systems, and integrating those as a way of introducing scarcity into a programming language. And that’s what Move really is — it’s a language for programming with scarcity.

We wanted to make sure that you have this built-in notion of: here are some values, these values represent real world assets, you shouldn’t be able to copy them, and you want to make sure that they’re used correctly.

We need this idea of scarcity, of programming that makes sure that the assets you have aren’t copyable, that you’re using them like you would use money, and they behave like physical money. You also need things like metering for a blockchain language. It’s important that you, if you come on to these platforms, you have to kind of pay for play or pay for the computation that you’re using, and have some mechanism for that. So, while you could take an existing language and try to add scarcity to it, or add an API or kind of programming with assets, it’s difficult to then also get metering.

Even more difficult on top of that is integrating determinism: a mechanism in a blockchain environment that requires all nodes to agree on the result of the computation (aka given the same input, you want the same output). You’d have to start really going through and banning a lot of libraries for non-deterministic behavior, like random number generation as an example.

So, we’re looking at all these things, and that’s really where Move got started. We thought: let’s just make a really simple language that has all of these things as the starting point of the primitives in the language. Move really started out as a very simple language for programming with resources or assets and we’ve added a bit of complexity over time. But that’s the history of it, and why we didn’t really take an off-the-shelf language like Solidity, or even Rust.

We started Move with a simplified language and made it object oriented. Then we adopted a more ML-like module system. A lot of it was designed with making sure that these blockchain applications were simple. From day one, another thing that was important, was being able to actually have strong guarantees, and being able to prove things about Move programs statically. We always had this goal in mind of building Move prover in some sort of static verification, because a lot of times when you come back, and you want to do static verification on the language, you have to deal with all this nastiness that the language added for expressivity, but isn’t really amenable to easy static verification. Originally Move wasn’t even Turing Complete; we didn’t have general loops, or recursion. We were hoping that that would make static verification easier, but it turned out that we really didn’t do that. One thing that we didn’t keep out of this language was dynamic dispatch, or kind of the more traditional thinking about object oriented languages where there’s no trace or anything. There’s no way of having indirect calls, or functions, where the behavior of the code path or what logic you’re taking is really purely dynamic in that way. This just makes certain parts of verification a lot easier. While you do have to program in a different way, we think that that trade off is worth it.

So the language has kind of evolved from that standpoint. We didn’t really have a generic set first language. There was no sort of polymorphism; that came later. There’s a lot of really fun stuff. If you ever are bored, just go and read through the VM or the IR; there’s a lot of really fun learning artifacts and they’re kind of fun archaeology. Move didn’t really have vectors or other collection types at first, we have this byte array type that was used everywhere, so you can think there are still some references, the byte array in the code base, which is always amusing.

I think that one of the things I’m proudest of is our reference safety checks, we have this borrow checker, you know, Rust’s very famous for having this borrow checker, that’s this static verification around references. And it’s famously for producing extremely confusing errors. And I’m not saying nothing confusing has ever come out of Move, but I think that in terms of the complexity of the system, we’ve produced something that has similar levels of expressiveness for the reference safety, while being, at least in terms of the formalism or implementation much simpler.

Damir: Back around 2019, we were developing a blockchain which was supposed to be a defi blockchain and we had to choose a language. At the time, you only had solidity and the other two options were up and coming development languages, one of which was Move and the other one was, if I’m not mistaken, was created by the guy who created crypto kitties.

Move first was a super bulky, hardly usable language because it was mainly, at the time, used in mobile AR, but it already had a number of properties and a number of ideas that actually drove me crazy. Then, a few months later, I completely fell in love with the language because of its expressive ability.

I come from a Solidity background and in Solidity you express stuff, like who owns something (I own NFT 1, you own NFT 2). It’s like a centralized HashMap or a database. As a database, you need to re-implement the database, but in Move, you could really own a type.

For example, whenever I say there is this coin, I own a type. It’s not written somewhere like in decentralized HashMap, but rather I literally own it. Now I think with types in my head. I know that if I pass this type coin somewhere, that means that I’m literally taking the coin from me and passing it somewhere else.

And this idea, I mean, once you get it, it’s like it opens like a lot of possibilities in like programming in general. So once you start thinking like objects and not thinking like abstractions that you build over programming primitives like a hash map, you always know what you’re doing, just like with unlimited expressivity with explicit stating of types — what was and still is.

I believe that is a selling point of Move, because you can express anything like you would in real life. When I’m at the bar explaining Move, I’d say, “So here is his bottle and here is this glass. Imagine both of them are NFTs and if we have a function, which would be like ‘pour water’ from this bottle to a glass, you literally pass this two together.” The function does it and returns you the full glass.

Question #2: Why did we select a variant of Move for Sui as opposed to using the standard Move language?

Todd: Yeah, so I guess just a bit of background here of how Move is set up. One of our goals was to build a purely language for scarcity. There’s not a lot of blockchain primitives or other things built into the language. If you go and look at solidity, It really is a language purely for Ethereum, there’s all these things baked in about various of block like the Ethereum native things that are a core part of the language and our goal was to make sure that Move felt like it can be instantiated on any sort of blockchain or any sort of application where you wanted scarcity.

But, we needed a way right to generalize storage. It’s helpful for blockchain, to be able to commit to state or actually write something down, you’re not just making the CPUs hot, you want to spend the gas, you want to make sure that you’re able to commit to a lender or make a change to the state.

So, Move have this idea of global storage that modules can declare resources or with types, and then index those into the chain and be like, Okay, I’m gonna take my coin type, and I’m going to move it and assign it or give it to this address, so we kind of had this little bigger hole map where your accounts and each account had resources and you can have one resource per type.

So, that was the goal of having a generalization around blockchain storage. But when it came to Sui, we’re trying to make a more efficient blockchain by recognizing that not every transaction is related and actually having this big centralized global state is a drawback, and it’s a drawback, but it doesn’t actually buy you much. If I’m sending a coin to Damir, the blockchain doesn’t need to wait around for me to also send some other coin to Jan or to someone else, these are independent transactions. But Move with the way that it was representing global storage these sort of concepts were very, very different or difficult to express, if not possible, because it was designed with a centralized account based model.

So to do this differently, we had to think back of like, how do we represent individual objects and Move? How do we take this sort of independence of data and insert it into the language? And I wasn’t there for the design of this, but early in the stages of the design Move, we thought about having all of the global storage instead of being this thing that you have access to these built in functions, we were thinking about it as maybe this would be a parameter that you pass into functions, you have like a, a storage type that you’re passing around in the language, and that’s basically the kind of concept that we went back to for Sui Move and instead of having centralized data as a part of primitive in the language, you will instead pass in the objects you want to consume to the entry point functions.

So that you explicitly say, Okay, I’m going to take an object of this type, and then under transaction level, you specify which object of that type you want so you have some the ID for it.

So really, that normal move is just not set up to be able to represent objects of this, and what we’ve done is remove the global storage, these big general, centralized storage from the language for Sui. I’ve gone to this individual object model so that this is really the way that or why we kind of needed to depart from standard mood, and the thing we’re doing differently.

Now, that being said, I just want to make clear, it’s not reformed to the language, or anything Move was built to allow individual adapters,that is individual instantiations of the language can add these sorts of things, by interfacing with the VM without having to actually import the language or do anything different.

So there are facilities we’re still using in the same standard library as other movements and creations. It’s the same kind of it’s the same VM, It’s the same Move Ling that we’re contributing to upstream, we’ve just taken a different approach for how we’re going to interface with storage.

Damir: You mentioned entry points, and it’s a bit enough of that. Do you know why everyone bailed on transaction as credits?

Todd: Yeah, we can talk about, going back to the history, they’re a little bit originally for one of the ideas for Move is, if you look at solidity, it’s really not like programming in a normal programming language, right? You go there and you build this synth, there’s no sharing of code. If you’re programming in a rust, and you want to go pull in some other crate or programming in Java, you can just import like from library something doesn’t really exist in solidity, at least not in the classical sense, right? You have to copy paste them code or pull in all these things, you can call out to other other contracts, but it’s not really like linking against code in a sort of normal way.

Goals for the Move module system is to behave more like a normal module system that you’d expect from other programming languages, so that if you want to reuse code on chain, you can do that without having to republish it.

Now, the question was, then how do we actually start transactions? So the idea was to basically have a separation, you have modules, which is the reusable code, and then a script is just like, I want to execute this series of instructions on the blockchain. Scripts are kind of like, they grew and grew over time to the point where they’re really looking like little mini modules, and as such, we’ve kind of transitioned a bit more into, instead of having necessarily scripts is like, here’s a set of instructions, please execute them on chain. Instead, in a module, you can specify to say, like, here’s like a transaction or here’s an entry point to execution, you can call this function in this module, you can kind of think about it as a reusable script. It’s a set of instructions published on chain that you can execute over and over again, as opposed to scripts, which were these throwaway collection of instructions.

So, that’s kind of where that’s coming up from and it’s really been helpful too in terms of programming in Sui for getting these kinds of objects, because now the model can define how you can program over the objects.

Damir: Alright, but we still have scripts, right? I mean, somewhere.

Todd: language, yeah, I kind of want to deprecate them in favor of like, a bit off topic here. But we can talk about that later.

Damir: I didn’t know if I should see LDR, so you know you could write a program and this program would be a transaction.

So usually, you call a specific method, you could write the whole program, and publish it as a transaction. so it’s like you published your whole program, and it does its job to enter like 100 addresses, and it will split your coin into like, 100 pieces, and you write it as code in Move, and it sends to this 100 addresses and it was like a really cool feature, which no one had, and now we don’t have to.

Todd: Yeah, I think it’s a bit tricky because the idea was the hope that you wouldn’t have to publish this code, but the script is still kind of has to live on chain somewhere, and that you need to be able to commit yourself to this execution and have some replay for it.

I think, maybe we’re kind of off topic at this point now. But yeah, that’s a feature of normal Move to where we are trading entry points to transactions a little bit differently as we move but we’re committing to these changes upstream and you know, I have the whole entry point story, has changed but recently for core Move not just for Sui.

Question #3: For Blockchain, how do smart contracts actually work?

Todd: Yeah, so it’s a little bit different for Sui as always saying you have these modules, and again, solidity is just like, I really hate the term talk smart contract for what it’s worth. I think it’s a stupid term and I think it’s really like marketing around the idea of programs, and that solidity it’s kind of like, I have a singleton object, or a singleton set of code that no one else can use. And here are some functions you can call into it, and the most similar it is any other kind of existing notion, at least as far as a Ethereum works, It’s kind of like an actor model. And a little way, it’s kind of like micro service model.

I just find the term smart contract a bit clever marketing. There’s nothing smart about it, there’s nothing really contracting about it. It’s just a program. That’s my own personal and I do know people like that term.

That being said, as far as modules are in Sui, I was saying that we set out to like, do something a little different Move, having these reusable modules of code, we do kind of publish them in a way that’s a bit more similar to smart contracts on Ethereum than in normal Move in Sui.

So if you want to write like a smart contract, you take a group of modules, and you publish them, in what we call a package in Sui, so you’d collect up your modules, you can link against other modules existing on chain, and then you publish those into your account. And you’ll get some ID for that.

So you have an object that contains, as I was saying, in Sui we have these objects for coins and other assets. And these objects don’t have to be just move values and move code. So you take all these things, and you package them up, and now you have an object representing a package. So that’s kind of how we’re structuring these things. But anyone can kind of call into it and link to it from their own code, you don’t have to do these delegate functions out to a different contract, that behaves a bit more similarly to how you might expect the code to work. If you’re writing like Python, or rust or Java.

There’s anything Damir, you want to say maybe you’re a bit more well versed in the Etherium space, if you want to maybe kind of go from there about how it’s similar and different.

Damir: Yeah, my theory of knowledge is outdated, very outdated in like years or something.

Todd: I mean, I don’t know if you wanna say anything else about the difference between a smart contract versus a Move package and Sui.

Damir: Yeah. But you got it right. I mean, usually we try to break code as generic as possible. So it is as reusable as possible, like if we have a coin module, which you can see, and we’re slowly shifting to the next question, which is about interfaces. If you look at our framework, you see that we have coin, but it’s like a generic point, which anyone can use to implement their coin.

So if you compare it to solidity, usually you publish like as Todd correctly mentioned that when you want to publish something like a smart contract, you usually need to implement everything from scratch. If you have like ERC 20 standard, you have this approve transfer et cetera, everything is described in an interface and you have to implement this interface and need to code everything yourself.

Uh, it is a good thing and a bad thing, is that while following this interface, you don’t necessarily have to implement them in a standard way. You can have the transfer method that just links all your money from you just Excel your money from you whenever you wanna transfer something, and that is a problem of interfaces in general. I love how Move addresses this problem, because we have generic implementations for any type T and if you look at our coin module to make another ERC 20, but I don’t like compare us to solidity, but anyway, if you wanna publish a coin or a token, you just publish like one line, which is like the name of your token, and it will be your ERC 20 coin on suing. And then you automatically get all the methods, like third main transfer, et cetera, and all the solutions we have in Move are pretty much generic and it improves called reusability. And that’s like one of the greatest features of language as well. And so even in our examples can be easily modified, if you have a sandwich example you will combine bread and butter or something. You can make a generic Combinator module, which will combine two modules somehow, I mean we can figure out the way to do it.

Question #4: Do you need interfaces and standards in Move like
RC 721 or the new one?

Damir: It is not necessary to have them and we don’t have interfaces. It is actually great things like Opensea exists. I mean, first of all, everything is an object, so if you just want everything to be transferable or spendable, et cetera, you just define your type of like a set of redefined abilities and you allow it to be transferred. And that’s it. So like my NFT, the me NFT and taught NFT, still different types, but they can share the same properties, and they implement the same interface.

So, if someone wants to build an Opensea, we don’t have to follow the same standard as RC 721, we can have like everything custom, custom metadata, custom waste to combine NFTs, custom waste to burn them. But the generic Opensea marketplace, we’ll be able to work with all of them if we just specify correct abilities on these types. So yeah, we don’t need interfaces.

Everything is generic almost by default and everything can be tuned like this slight modifications on how the type behaves, in how you define abilities for this type. They affect the way this type can be used.

Todd: So going even deeper into what Damir was saying, the interfaces are a crutch for the fact that you can’t really reuse code and there’s no way of kind of customizing existing code. So if you have like a token, you want to define it on solidity, it’s like, well, I can’t reuse the other existing token code. There’s no like token library. So you’re stuck trying to adhere to this interface. So the only solution and move the idea is that you write the coin type once and you’re done.

There’s like a coin module. And this describes the behavior of a coin. You have a coin asset, a type representing the coin, and then you have functionality over the coin. That’s gonna be the same for coins, where you have splitting and transferring and combining and withdrawing, et cetera.

So now when you want to come along and define your own token type, you can instantiate the coin type using generics and fill in the inner bits of the coin and saying, okay, I have a coin of Sui or a coin of Eth or a coin of Todd Nichols or whatever fantasy money you wanna make up on chain, you can just make a new module, make a new type, and then instant the coin type with your kind of new token type. And now it’s gonna work everywhere, once it works.

So if you have something like Opensea where you want to have transferring of these things, you can imagine having a generic type for coin or like you could have a generic wrapper for Opensea NFT. That way, the Opensea you can encapsulate your data in that type, and then it’d be good to go.

No, that’s kind of like the most straightforward connection to how things work in solidity, but we can do things a bit better here. I would say in Move, that’s kind of what Demir was talking about with these abilities for the types is that you can define your own type, your own NFT, and it actually doesn’t have to use these kind of rappers that I was just talking about. You can just do whatever you want and that if you have certain abilities, then the transferring of the Sui object is just gonna work generically across the board that we have this generalized transfer object, you can invoke a transaction, this transfer the object, and you’re done, but you don’t even need that, you don’t have to have this like public transfer, you can say, I want all code and all transfer to blow through my module. I want tight control of this behavior. And it’d still be easy enough for Opensea or someone of some other marketplace to expose this functionality. It might not be super pretty, but what you can do is you can look at the module and say, Hey, I have an object of this type. Let’s look for all the entry point function in this module that use that type. And you can say, okay, here are all the functions exposed in this module for this, for this type. And you can even say, oh, I actually want to call this other entry point and some other function. And I could imagine something like Opensea or some other Explorer, marketplace having a way of like saying, okay, I want go look at this module. And I want to use the object. I have stored in an exchange or something and I want to use it with this custom logic. So you don’t need to have just cause we don’t have interfaces. Doesn’t mean there’s like not a way of doing custom code too. I think is my point.

Damir: I can add to that. We actually have interfaces and we discovered them like a month ago. Yes, that is true, we still discover new patterns, we still discover new ways of expressing stuff. And if you go to our main branch on GitHub, you go to examples, there is this regulated coin example and it showcases that we kind of can have interfaces.

So, if you want to have this type, you need to implement a module that implements all of the methods of this type, I mean, it is technically an interface. It does allow you to implement your custom type custom interface. I mean, implement the interface, be usable, kind of as the type you are implementing. But on the other hand, you lose this property of like, uh, would I call it like generic ability? So, you can’t reuse this type, we have a regular coin example as a different coin because there are different types and so always better to go with generic, ready to go solutions. But if you wanna see how interfaces are implemented, then check out a regular coin example. I doubt anyone will ever use it, but maybe there will be someone.

Question #5: What do you think are the disadvantages of the Move programming language?

Todd: Yeah. I think we’re kind of hitting into some of them in an interesting way, I mean there’s disadvantages of things I’m unhappy about and like oh my God, why did we never get around to adding, you know, X, Y, Z feature? There’s still some basic stuff missing from the language or at least what I view is just, so I consider that at this advantage, most languages that you program with have some form of indirect calls, you have like some form of indirection. And if you’re programming in rust, you have a trait you’re programming in Java, you have like various interfaces or, other things you can do. And we just don’t have that. There’s no dynamic, dispatch is no indirect. Cause what you see is what you get in your module. And this is a feature in that, you get really strong guarantees about your code and you’re able to prove things about your code that you wouldn’t otherwise be able to prove formally. The downside is you have to think differently about how you’re laying out your code. You know, the coin module is great, but it’s just not, if you were working in another language, you just like probably wouldn’t set up the code that way.

So the, the amount of expressivity is similar, it’s just a bit different and the weight and the programming patterns that you have to use. So I would say that a disadvantage here is that in order to get kind of this power and these strong guarantees, you have to program a little bit differently. but I think about it, as kind of like driving on the other side of the road, Like in the UK, you drive on the left side of the road versus in the us for driving on the right, and they both work. It’s just that your muscle memory in terms driving is probably gonna be a little different and you’re gonna have moments where you’re gonna like freak out, like, oh my God, I’m driving on the wrong side of the road. but, you just kind of have to sit back and reassure yourself that you’re still gonna be able to get to where you want to go. You just have to be a little bit more careful. I don’t think a little bit differently than how you might have before.

Question #6: How would you implement a DNS in Move?

Damir: Our answer to that is that we will never implement it because we don’t need to. The actual problem that people usually ask is in places like solidity, because solidity is a reference smart contract language. It will change, but for now in solidity you can have like a hash map by central hash map that says this IP address is this domain name and vice versa and you can go to a single place and check a lot of data in the hash map. This was addressed as one of the main problems of Move.

You can’t have a centralized storage because it’s going to be super expensive. Move would lose all of its properties and become extremely slow. Any change that you do would affect the whole hash map. If you had a million records and you changed one or added one, you would have to rewrite 1,000,001 records again.

The DNS problem is something that we haven’t solved, but you can always find a way to implement it. Like Todd said, you need to change your mindset. You need to change your paradigm. You can always store a bunch of objects. It won’t be as programmable as you’re usually use to, like when you’re using a hashmap to create the result of an address or name of a website DNS.

It will be something different and might require more off chain tooling, but in the end you will have more efficient, more scalable result, but we try to not have huge centralized storages of data on the chain, because it is not effective.

Move makes most of the profits of its decentralization where all assets are spread on different addresses rather than putting it all together.

Todd: Most commonly the kind of questions we get are like, “I did this in solidity, how do I do this on Move?”. The answer is you don’t because you don’t need to. You should be laying out your code differently. You’re not centralizing all of the entries for your NFTs in a single map.

Instead you have individual NFT objects and the downstream effects of those decisions mean you just have to think a little bit differently about how you’re programming. For example, you should be programming on a kind of per asset style and not thinking about how would I do this with being able to view the entire world at once.

Question #7: What are the capabilities of privacy on Move? Are there limitations of privacy that you can enact on Move?

Damir: You wouldn’t from the language you would expect from the back end of like, because M produces by bytecode. This bytecode is something that can be produced in plain. It can be encoded somewhere else and you can use move by Mo VM inside some platform which would transform their code into a Zuki circuit, which no one will ever read if they don’t have the proven key and verifying key.

It’s not a problem of the language and shouldn’t be treated this way because we can always encode some data off chain and pass it into Move and then return the same encoded data. It will be private because no one knows the initial data.

On the other hand,if we just like take the move VM and like how private is bytecodes, it is less private than Solidity move bytecode is cleaner, it’s more decodable, it’s more usable and overall better if you’re a developer working on this bytecode. With solidity if you get a contract API, you usually cannot trade it because it’s encoded in a weird way.

You have lots of different directions of the compiler you don’t know what it was. Of course, there are probably some solidity compilers, but usually, you treat solidity by code as something like AFU, which you will never get. While with Move, you can also see it in our explorer, each program gets sort of depi I mean partially, you can always see the signatures, you can always see the types, so everything that happens with Move is transparent, you can check everything that’s going on, even the bite code.

Todd: Yeah. So let me hop in there, I think there’s just everything you talked about Damir.

You know, one of the goals for Move was set The VI code language, we have a strong guarantees at the VI code level, like there’s a type system for the VI code, but all of your asset and scarcity rules that ensure your objects or your types are being handled like they would for money, these guarantees are checked at the VI code level.

So, anyone could write a programming language or the bike code and get the same guarantees, or they’d be tied to having the same guarantees. And when we’re talking about being able to view everything and all the like signature functions that are stored on chain at the biker level, we refer to this as sort of a secure compilation pipeline so that when we’re thinking about Move programs as the source language and a different source language can make a different choice, but the language doesn’t add any abstractions that aren’t really present at the bike code layer.

Now, that’s not saying there aren’t like features that aren’t testing and there’s some annotations and the prover specifications, these only exist at the source language level, but when we’re talking about the signatures of functions, they’re exactly the same at the bike code level. And this is really important because it means that any of the guarantees you have at the source language are present at by care level. So if you’re trying to do something illegal or incorrect with the type, you wanna make sure that behavior is still present at the biker level, so you don’t gain expressivity by trying to interact with the bike code directly.

So that’s really what we’re talking about; secure compilation. That we’re having the same level of guarantees down the pipeline. I think that this is important to bring up when we’re talking about viewing code on-chain.

Question #8: So Move offers a unique feature for NFTs, but is there anything that it does in a unique way for DeFi that other languages don’t ?

Todd : I would say almost in a way that the type system doesn’t do anything unique for NFTs, it does something unique for assets. It just turns out that NFTs aren’t so interesting from a technical standpoint. They are really an instantiation of having rules the way things behave with real world items.

Damir : [Move] is super fast. It just provides security guarantees for everything you hold. It provides an inability for someone to seek your assets, to modify your state, to take something from you. So you are always safe if you own something. You have security guarantees, and the only problem you might face there is that the highest integer that we support is u128. We’re thinking of adding support for u120, u56, but that’s a huge question whether we actually need those or not. Apart from that, you get everything you need. You can work with math. You can work safely with assets, and lastly with Sui you can do this in a decentralized manner and with higher transaction volumes.

Thank you for tuning into our Move Programming Language AMA! If you have any feedback about how the AMAs were conducted, please don’t hesitate to reach out to social@mystenlabs.com with your input. We’re always looking to improve.

Learn more about Sui

• Sui Website — https://sui.io/
• Sui Developer Portal — https://docs.sui.io/
• Move Programming Language
• Sui Whitepaper
• Community forums

Build with us!!

We’re excited about what the future unfolds and invite creators and builders to join us.

Recap Sui AMA: Move Programming Language with Todd Nowacki & Damir Shamanaev was originally published in Mysten Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

Mysten Labs welcomes you to run your own Sui fullnode on DevNet. This is another step forward in providing robust services to developers and businesses to #buildonsui.

Sui fullnodes:

• Track and verify the state of the blockchain, independently and locally.
• Serve read requests from clients.
• Conduct local app testing against verified data.

Fullnodes enable validators (or miners in other networks) to focus on servicing the write path and processing transactions as quickly as possible. If you would like to become a validator on Sui, running a fullnode is a prerequisite. Documentation of how to set up your Sui fullnode can be found here on GitHub.

Important: For potential validators, running a Sui fullnode is an absolute prerequisite. We encourage auditors, bridges, state mirrors and other interested parties to join us. At this time, we offer no guarantees on performance or stability of our fullnode software. We expect things to evolve and stabilize over time, and we’re seeking feedback in the form of Sui Code Bug issues filed in GitHub for any problems encountered.

Learn more about Sui

• Sui Website — https://sui.io/
• Sui Developer Portal — https://docs.sui.io/
• Move Programming Language
• Sui Whitepaper
• Community forums

Build with us!!

We’re excited about what the future unfolds and invite creators and builders to join us.

*DevNet usage is subject to our Terms of Service.

Announcing Sui Fullnode was originally published in Mysten Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

Note: You can find the paper “Be Aware of Your Leaders” published on Financial Cryptography and Data Security (FC), 2022 that Kostas mentions on our Sui Developer Portal.

Introduction

Jen: We are going to kick off with our first Sui AMA. Thank you so much for joining everybody. We’re diving into the world of cryptography and I’m going to give the mic over to Kostas to discuss it shortly.

Kostas: Hello everyone, I’m Kostas, Co-Founder of Mysten Labs and leading cryptography. I was at Facebook (Meta) for three years, leading cryptography for the Libra project. You’ll know it eventually collapsed for various reasons, mostly because of regulation and auditors. Eventually we retired the project.

I had the opportunity to work with one of the first developers of Satoshi Nakamoto, Mike Hearn, on the like transition from the Bitcoin space to something that is like a permissioned blockchain for a number of banks back then. They were afraid of the Bitcoin revolution. Mike left the Bitcoin community and asked me to help him on the cryptography side. I worked very hard on zero knowledge proofs, accumulators, multi-party computation (MPC) back then — confidential transactions, and you will see how this applies to Sui today.

I also lead the proof of reserves and the proof of solvency effort on the crypto community. And it’s interesting. By the time we published papers on Financial Cryptography and Data Security 2022, one of the biggest conferences where blockchain startups and research can publish their work, two days after was the Luna collapse. And I explained to them why nobody is doing it right, and I was super surprised that some of our work had an impact.

I think that we (Mysten Labs) have one of the strongest teams. The five co-founders, all of us are ex-Facebook leads on different sectors. For example, I was the lead in cryptography, but I was also doing stuff on WhatsApp as well. So you might run some of my code on your mobile phones already. But the thing is, we tried to also build a team from scratch. Most of us are seniors, and we hired a lot of like leaders in this space in consensus, cryptography, engineering, and may other topics. We even created our own language, Move programming language. Our CTO (Sam Blackshear) is actually the creator of the Move language.

So we do a lot of research. As we move forward, you will see some interesting stuff, including some questions that I see here on zero knowledge proofs. I hope I can explain exactly what we’re working on.

Question #1: Sui’s advantage over other blockchains?

Jen: What are Sui’s advantages over other blockchains? And what are the reasons that will make users switch over to Sui?

Kostas: That’s a very good question. And actually, it’s one of the reasons that Mysten Labs exists. We’re providing a completely new paradigm on how the smart contracts are actually implemented. I will explain what’s the difference between Sui and Ethereum, for example. We have a combination of award-winning consensus algorithms. First, we have one of the fastest consensus algorithms and mempool; it’s Narwhal & Tusk. And second, there are some applications that can completely avoid full consensus and bypass it. For example, you can check out what we call Single Writer Friendly (SWF) applications. We have this different model of like ownership and certain objects, and the way you can combine it. Some of the assets can move from one place to the other, from one consensus to another method. And this is what makes a huge difference on our blockchain Sui.

Regarding Ethereum, as you know, is using the account-based model. At the same time, we have Bitcoin which is like the UTXO model. I would classify Sui as somewhere in the middle. We did this interesting trick where everything in Sui is like an object that can be transferred from even one contract to the other. On Ethereum, there are two points of congestion.

1. Imagine that on the user account level, if the user is sending transactions from the same account or there are some other users who are affecting this user’s account, for example, to pick up on the balance. This account is a point of congestion because all the transactions have to be ordered in a block. Otherwise, we don’t know which came first, if the account was drained before it had the opportunity to actually spend some money.
2. Second point of congestion on Ethereum is at the contract level. Imagine now some of the most popular contracts like ERC-721, ERC-20, etc. There is usually inside the contract a huge hashmap, huge vector, or something placed where we can actually hold the mapping between who owns what and what is the current balance or the current NFT. If there are multiple transactions in the same contract, this means that the transaction should be ordered between them in order to actually have a sequence of events. And again, not having a particular state where we’re losing information, because of unsuccessful ordering, this means that Ethereum has to create blocks. And because it orders everything, this is a slow process.

What we did is we removed this bottleneck. The removal is actually by decoupling the assets from the accounts and contract. So we have the address in Sui and this address owns objects. Imagine as NFTs, or even assets with a fungible balance, similar to UTXO. So these assets are accompanied by a version, by a nonce if you’re familiar with Ethereum. We remove the nonce from the Ethereum account and we put the nonce (this version) into the assets that you own. Now all of the assets live independently; you can touch one asset and you can touch another asset. Because these assets are not actually conflicting between them, you don’t need total ordering. And this is where our speed actually comes from.

We tried this as a little experiment on a simple Mac laptop and we achieved 120,000 transactions per second. This is huge. We’re not requiring a machine that requires huge memory and huge storage. This is where we actually sign. We believe we’re going to be the fastest one. Second, we’re using Move to protect the assets. On Ethereum, everything is uint256, right? It’s a value. How do you transfer one value from the other without having problems to understand what this means? The software developers or contract developers need to know exactly what they’re doing. And this is prone to potential attacks that we’ve seen in the past.

Shortest answer on why Sui is better: speed, programming language, object oriented, and ultimately, easier and safer because of this object-oriented mentality. Users can make less mistakes on their code.

Question #2: When is testnet? Is it incentivized?

Jen: Now, the next question we have is: when will testnet start? Is it incentivized and can active testnet participants become validators on mainnet?

Kostas: I will reply quickly on the incentivized thing. Yes, it will be incentivized. We’re still working on the details and we’re building the ecosystem and the community at the moment. We will incentivize contributors, as well as from external developers. Imagine tooling apps for testing, documentation, bug fixes, etc.

But the full details on how this will happen? It will probably be a topic that someone else in the next AMA will actually answer.

I can explain a bit on how are going to technically give incentives to people to work on. For example, we need to transfer all of the Ethereum popular smart contracts into Sui, because this will make sense for the transition and create a template. And this will incentivize people to participate, usually, because it’s very easy to write code on Sui. I personally wrote a Twitter example with 50 lines of code. If you go to my Twitter account, you will see my post; I call it Suitter. And you will realize how easy it is to contribute. We actually recommend you do that. Start at our GitHub repository and start posting things that might be like a clone of the Ethereum blockchain.

We actually need Sui to have all of the functionality of all of the other blockchains. We know it can happen. We know it’s even easier to do, especially if you’re coming from an object oriented language like Move. Move is inspired from Rust, but it doesn’t need to be a Rust developer who joins Move. Or even a Java developer or someone else because we’re dealing with objects. This can help you a lot to move quickly from your conventional software to smart contracts. Do it now because testnet will definitely be incentivized.

Question #3: What is the goal of Sui?

Jen: On top of all that, what is actually the ultimate goal of Sui? How is it unique? Who is it ultimately looking to cater to? And are there any partnerships that we can expect coming out soon?

Kostas: Imagine all of the founders are coming from FAANGs, like Facebook, and some of us have prior experience with blockchains. We’re exposed to many applications and startups that are requiring blockchain functionality. The goal for us is to actually have a stable, safer, and the fastest blockchain out there.

I explained things in the first question. And from what I can see, we’re getting towards that. We achieved a lot of milestones already. The ultimate milestone is, obviously, to be the leading blockchain to write smart contracts. Our system is delegated proof of stake. Because we have one of the fastest algorithm for consensus, and as I explained, you can even bypass consensus for some applications, this will make us the leader in industries. Imagine gaming, there is a trend, like having all of the gamers to be actually incentivized to participate in blockchains. Being able to sell their assets is easier than being in an isolated environment. It’s also DeFi because we have the fastest consensus; we believe that DeFi is also going to be like a killer application on Sui. You can even do, as I said, a Twitter on the blockchain. So any chat messaging is super fast with us. Low and even subsequent finality, because you can bypass consensus, and in the worst case, it might be a couple of seconds finality because the consensus is fast. So we believe we’re going to lead the space of DeFi, gaming, and anything with commerce. In general, it’s like a modern Ethereum. And because of this, we hope we’ll be one of the leaders.

Question #4: What happens if owner is malicious? Wouldn’t consensus actually be needed?

Jen: In terms of owned objects, it can only be modified by the owner. So you say consensus isn’t really needed for them. But what happens if the owner is malicious and tries to double spend? Wouldn’t consensus actually be needed for instances like that?

Kostas: So when I say we bypass consensus, a lot of people who are not familiar with the algorithm will obviously think of this particular use case, right? What’s happening if they use it as malicious. If the user is malicious in practice, they’re creating problems for themselves. Imagine you own something. If you try to actually play a game and send to 50% of the validators your transaction, one transaction with an object and another transaction with the same object, obviously, this object will not be able to be finalized.

You always need a quorum of signatures, which in our case, is 2f+1. So 67%, let’s assume that we had 30 validators, you need 22. You need this number of signatures to receive. Our validators obviously track what they’re signing and it’s impossible to double spend. The the worst case that can happen is there is an equivocation state where your object is actually getting frozen. And you cannot update it because it received 50 and 50. You cannot go more than 50 in this particular case, and you’re creating the problem to yourself. However, we have a mechanism. When it’s epoch chain, there will be some gossip communication between the validators and the frozen assets will be unlocked, and will be able to be used in the next epoch. We haven’t identified yet, and this is actually tested in the community, any particular case where malicious users who own assets have incentives to lock their particular object. The only thing that can happen is actually creating a problem to themselves by doing this equivocation scenario.

Question #5: How do you bypass consensus?

Jen: We actually have another question that that ties into that. Can you explain how you bypass consensus?

Kostas: Okay, cool. Let me now actually send you a link on Single Writer Friendly apps. So if you go there, we can actually go one by one and see why these applications have this benefit of bypassing the consensus. Whoever clicks on it, you can see a list of 22 applications that I have here, all of them have something in common. This can work on the single writer model, which means that actually a user owns something, is responsible for submitting these or transferring this asset to someone else, or mutating this object. As I explained before, the worst you can happen in this particular case, if you’re not careful or you’re malicious, is you’re actually freezing your asset. But in the happy path, you’re not going to do it.

And assuming most of the people will be honest, imagine the regular p2p transactions:

• You go to Starbucks, and Starbucks actually wants some eventual finality for you to actually sell you the coffee.
• And what you do is you’re sending your object to the Starbucks account, the address to the Starbucks address, and then you will receive 2f+1 signatures from the validators independently. They’re not going to the consensus.
• Actually, the user is connecting to all of this 2f+1. There will be a gateway, there will be some driver who who will do this work on the wallet side, and then you will receive 2f+1 signatures. The validators internally keep the version so they know what they signed about this particular object.
• And now, you can provide these to Starbucks. This is eventual finality, and your Starbucks is 100% sure that this transaction will reach a block in the future.

It’s impossible to get 2f+1 signatures and not go to the blockchain, which is like a secure light client mode. Because you got 2f+1 signatures on parallel interdependently, we guarantee this protocol only accumulate signatures. This is called fast pay, by the way, and you can search about the original work about how you don’t need full consensus, and our white paper about how we managed to connect all of these dots on Sui. So it is possible with this model to only accumulate signatures. And this is an undeniable proof that this will eventually go to a block. And because of this model 2f+1 on parallel communication, no n² in between nodes communication, which means low latency subsecond, it’s actually speed of light here.

And all of these applications here, it’s like regular p2p transactions, confidential transactions, because there’s no difference between transferring real balances against confidential balances. For example, MimbleWimble and Monero are doing this public bulletin board. So if a user wants to publish something on chain, they own it, and they want to do mutations over this object or they want to transfer something to someone else, you don’t need full consensus, right? Because you don’t really care if other transactions on chain are happening in a different order. This is your object, you’re transferring it to someone else. If you try to equivocate, the only thing that you might have to do is freezing the object. So you don’t actually need the default consensus. And then, we have someone now has an idea on a startup about creating the Signal protocol, WhatsApp protocol, Twitter protocol, a new Yelp, and new TripAdvisor with shopping lists, even a personal GitHub, or personal password manager. Knowing their active games, imagine if you evolve your Sim City, your FarmVille state, right? You can actually bypass consensus here. You don’t need full consensus, to have this evidence that the transaction who only received signatures will go to a block 100%.

Decentralised lotteries — imagine what is every ticket that we buy? It’s an NFT. By NFT-izing, everything in our particular case, everything is an object, you’re just creating an NFT intervention at the very end, only to identify a winner. You probably need full consensus, but the tickets can be purchased without full consensus.

Imagine even posting price quotes. You don’t necessarily need to bypass consensus on every step for every application. It is highly possible even on DEXs to have a few of the steps be a single writer that they don’t need full consensus. In this particular case, we have oracles who are posting price quotes, the posting of quotes can actually be a single writer; it doesn’t need consensus, I’m just posting it. And then the one who does the aggregation or the trade, then they need full consensus. So we manage to actually even combine this in the same application model.

You can imagine having job listing applications like you can create a workable or LinkedIn. In this particular case, you can literally avoid full consensus. Nobody’s asking you if you posted something before someone else on LinkedIn, and the ordering is slightly different. Eventually, they will go to a block anyway, so they will be ordered. But at the very beginning when you need undeniable proof, you don’t care about ordering.

I think I covered most of them. I’m super happy if you can propose other applications in this chat thread so I can add them. And this can even be considered some type of interaction from your site, as we say from the incentivized testnet, you can even help us to identify applications who are friendly with our Fast Lane; I mean, applications that can even bypass consensus. But even if they don’t, we’re still the fastest protocol out there.

Question #6: Plans to support ZK proof verification?

Jen: Are there any plans to support ZK proof verification in Smart Contracts? For example: Zokrates, Nova, Spartan, etc.

Kostas: The answer is: yes. And why and how we’re going to do this right? What is a blockchain in practice? The blockchain is a smart contract language Turing complete, where everyone can build whatever they want on top of it. Personally, some of you might know me because I was a product leader of the Winterfell STARK zero knowledge proof system. It was one of the publications from AsiaCCS. (By the way, the “Base64 Malleability in Practice” won the best poster award.)

So I’m super familiar with zero knowledge proofs. I also use bulletproofs in the proof of solvency as standardization process that I’m leading. So we have all of the capacity to do it. And what we’re planning to do is the Move language. Now we have Ethereum, and if you go to the yellow paper of Ethereum, you will see all of the transactions, all of the commands that you can actually have on your contract. We will augment Sui to also have extra primitives so that people can more easily build zero knowledge proofs on top of our system. And what are these primitives? One of them is, let’s support Pedersen commitments. If we support Pedersen commitments, then one can build all of the systems that can provide extra privacy to the smart contract.

Also, because I’m familiar with bulletproof and we are backed by a16z, people are part of a portfolio of helpers or researchers who help the portfolio companies, we will work very closely together to have an API and bulletproofs. So we can have range proofs eventually on Sui; it might not be directly on mainnet, but we are going to have support for adding it as fast as possible. And then because of these applications, and because of the fact that we might even allow bilinear pairings, someone can even build other schemes like inclusion proofs in Move like accumulators and polynomial commitments. You can even build vertical trees with polynomial commitment. Eventually, we want to incentivize people to build ZKP verifiers in Move like Groth16, PlonK, etc. I’m familiar with Starks and Winterfell. And this is part of the long term plan. But originally, bulletproofs and Pedersen commitments are pretty much a priority, plus some fraud proofs. We have some very cool applications on utilizing fraud proofs when we believe that ZKP is expensive.

And this is like an announcement here: We even have a protocol on how to do semi-private NFT. What I’m saying is, we are going to provide and allow primitives on top of the Move API. And these primitives will allow us to do all of these cool gadgets and things on top of Sui. So most of the zero knowledge proof verifiers will be, even if not implemented by ourselves, we will have some of the primitives that can be used from you like bilinear pairings or Pedersen commitments. And I personally want feedback on this. What would you like to see that can be reusable as a primitive in Sui? If you send us a list of things that you believe are useful for you to innovate and have your own startup and actually build some very cool, I don’t know, bridges or other stuff? Let me know. And I can make sure that whatever is possible from our side will be there.

Question #7: Is Sui blockchain quantum resistant?

Jen: Is Sui blockchain quantum resistant? If yes, how will it be implemented?

Kostas: This was one of my expertise, skills that I used to actually perform at Facebook as well. There are many ways I call it post-quantum readiness. And in this particular case, there are many ways to enforce post-quantum when you need it. At the very beginning, we’re going to support EdDSA as a signature algorithm. Very soon ECDSA as well, because there is a request from people who are familiar with Ethereum who can’t wait to use the same key type on Sui. Yes, after many discussions with stakeholders and partners, I decided we’re going to add this. Because there is these crypto agility, so you can define and flag of what private key type you’re using or public key type, then in the future, we might even consider to have a post-quantum scheme there.

I’m the main author of the blockchain post-quantum signature, it’s called BPQS, it’s a variant of XMSS. So there is an efficient implementation using only hash functions. I’m not sure if we’re going to use exactly this in the future. So at the very beginning, we start with non post-quantum. But we will build out our chain in a way where, with the flip of a button, people can actually move to post quantum keys.

There is a catch here. What’s happening with those who have assets on a quantum like non resistant algorithm like ECDSA; there will be a period where we will allow assets to be transferred from their non post quantum to the post quantum alternative. Or there is a nice trick here. If you’re using deterministic algorithms, like EdDSA, there is a way with Stark proofs; imagine, the zero knowledge proofs with Starks can provide post quantum security. So if you can prove knowledge of the pyramids of your private key on an EdDSA key generation, because it uses a hash function internally, then in theory, even users who are using conventional crypto, they can actually move very quickly to post quantum settings. I’m preparing a paper around this, and listing all of the methods that conventional blockchains can actually use to jump in a post quantum world.

Question #8: Sui integration on hardware wallets?

Jen: Do you plan to integrate Sui on popular hardware wallets?

Kostas: Yes. So we have Todd, Head of Engineering, who is already on this thing. There will be a spectrum of key types that we support from ECDSA, which are compatible with Ethereum, to EdDSA, which like the most modern variant of elliptic curve cryptography, the probability of actually building something on hardware wallet is like favoring cash because anyone can pick whatever key type they want and then they implement it on the hardware wallet. We need partners in many cases around this. But we are going to also work by ourselves on having a plugin on some of the most popular hardware wallets. This is not a goal for the mainnet, but it’s a stretch goal. And probably we’re going to have it if we find the suitable partner here.

Question #9: What are expected specs for nodes?

Jen: What are the expected specs for the nodes? And what is the maximum size of the ledger? How do we avoid dust attacks to overload node disk space?

Kostas: As previously discussed, we can parallelize stuff. We can scale horizontally in many particular cases, which means we just spin up new nodes to do signature verification. How does denial of service attack happen? There are many ways to do this, but one of them is you’re actually signing transactions that will fail eventually. And they will probably fail at the signature level, which means that you cannot even charge gas for this denial of service. The other thing is where people are actually submitting so many transactions, as this happened in Solana in the past, there is a dominant smart contract, which actually receives all of the traffic and it doesn’t really allow other or even the same contract transactions to be executed. Because we can finalise stuff and we can actually split the consensus, the logical execution ordering between different smart contracts, imagine all of them can run in different consensus, there will not be a dominant contract that will actually ruin the success rate of the network itself. So we’re more secure in that sense, because sharding capability is embedded into our system. So this is where we sign actually because of parallelization, even at the consensus level, and because of the fact that many applications can even bypass the consensus level, the whole network to be done is by far less probable compared to other blockchains with an older architecture. But we know exactly why we’re better than the rest. And because we’re like the second player in this game, we’re also learning from the others. And we believe we have a better system against denial of service.

(I mean, I like many of them, right? I was also a crypto safety person. I named my son Kryptos. My son’s name is literally something about the work I’m doing, and cryptography and cryptocurrency in general. How I convinced my wife is a completely different story. It’s not a joke. If you ask me about my name, you will see on my LinkedIn, it’s Kostas Kryptos. Kryptos is my son’s name with a K, because we’re Greek background. It’s a word in Greek by the way; Kryptos means hidden secret.)

Question #10: Do you plan to shard the network?

Jen: Do you plan to shard the network

Kostas: As explained before, it’s embedded in the network. It’s not like AVAX where there is some domain separation. This is also a cool technology; I personally like them. But I think we have a better system on how to organically scale and have these internal service mechanism, which is more natural. You also get all of the consensus guarantees in the whole L1 network compared to splitting to subcommittees and all of this stuff. I think our model here is slightly better.

Question #11: How is gas set?

Jen: Can we set gas like ETH or MATIC, or gas is set like Solana?

Kostas: Okay, so there is an interesting application we’re working here. You can even have meta transactions in our case. You define in our particular application how much you want to spend for a transaction, but there will be a possibility that you can even delegate your transaction. Imagine you’re sending a transaction, you can delegate to someone else because you don’t have enough gas. And if the program will see these two signatures, it will get the gas from the person who helped you and will actually execute the transaction that you want to do. This is very important, right?

Imagine people are going to receive NFTs. They might not even have a single SUI coin in their account, but they’re going to transfer their NFT and maybe because of this meta transaction support, we can allow other wallets to help them. Maybe these wallets will use it as the advertisement campaign: I will help you, but create an account on my website or watch this advertisement or something else. Or you can even have some custodial services that will do it for you, and you pay them in a different off-chain manner. So it will be. There will be a case to help onboarding people who receive stuff. Eventually, they’re going to have support for spending, transferring, mutating their own assets, if they find someone else to actually pay the gas for them. And because we’re expected to have one of the lowest gases in the space, because we’re faster, we can scale faster and organically, so we can drop the prices and be more secure against denial of service attacks compared to the rest.

We believe that this will give incentives for onboarding into the space of blockchains, especially the gaming community. You might own NFTs, but you don’t have coins. But if the game studio is helping you to spend stuff, then why not use SUI because it’s almost free?

Question #12: How do private NFTs work?

Jen: How do private NFTs work?

Kostas: I can’t share my screen, right? I can actually make a short presentation of the private NFTs. I’m planning to publish and this is one of the reasons I’m not having everything exposed at the moment. But I can give you a very quick example. Imagine you have a Bored Ape NFT. Usually you can see everything in the Bored Ape, but what if some of the pixels are blurred or there is an overlay like a watermark on top of them. And you want to prove, because what you’re buying right on the blockchain, you are buying hashes. You buy the digest of the picture. And this is like something that says you buy a commitment to the picture, you buy a commitment to the NFT.

We’re using some cryptography at the moment with fraud proofs, where you commit to the encrypted NFT, partially encrypted, you can see most of the image, but some of some of the pixels are blurred. So nobody has the exact same copy of what the Creator is selling. And then if the Creator doesn’t give you the the original NFT by decrypting key to your public key, then because the commitment will not match, you can actually create a fraud proof that says: “Okay, I bought a different hash and you sent me a completely different image, which is not what you were supposing to sell.” It’s the same thing as Amazon books. Now Amazon Preview, what do you do when you go there? You can only see a few sections, some of them are actually retracted; you cannot see them. You trust Amazon though, right? You trust Amazon that when you buy something, they will give you all of the pages of the book that you bought? How can we transfer this web2 technology to web3?

Now, we did pretty much the same thing. But we added cryptography. So if the current seller, let’s assume the Amazon on Sui, is not giving you what you would expect to get, as other people go out and added some like reputation, let’s say stars. You can go against Amazon by providing fraud proofs: “No, no, I didn’t buy this thing; I want to get refunded.” And this is how it works.

Question #13: Implementing zk-SNARKs in Sui?

Jen: And are you looking forward to implementing zk-SNARKs in Sui?

Kostas: What is the support for zero knowledge proofs? zk-SNARKs is a zero knowledge proof scheme, right? As previously discussed, yes to bulletproofs for now, like for confidential transactions and Pedersen commitments. And because we’re planning to allow primitives on chain, like bilinear pairing cooperations, even if we don’t implement the proof, the verifier on chain, because you need the verifier, we will give an opportunity for users to do with less gas compared to other systems where you have to implement everything. And it’s not part of the main network, that’s third-party operated.

Question #14: Are you going to spin up many nodes to sign transactions to scale horizontally?

Jen: When you say we are going to spin up many nodes to sign transactions to scale horizontally…

Kostas: Validators? Yeah, the validators can actually be one machine as it’s now in Solana. But in our case, there is no reason to be one machine; you can actually have multiple copies.

Question #15: What is the difference between Sui and other projects on Move?

Jen: What is the difference between Sui and other projects that are building on Move?

Kostas: Regarding the programming language, this is the only part that we’re using between other platforms and Sui. However, our Move, our variant, is splitting everything into objects. We offer this capability of getting to the fast lane and bypassing the full consensus here, because we’re object centric. The other projects are account centric. And you will see there are some very basic differences.

If you see my Twitter example (aka Suitter), and see my post about how I did this in 50 lines of code. Because everything now is NFT in our case, you are using Move slightly differently compared to the rest. Sometimes it offers some flexibility on making different sections even cheaper. The only thing that we’re using between the other projects at the moment is the language itself. We’re using the same language, but the way the construction of the object is internally slightly different.

Thank you for tuning into our first ever AMA! We’re aiming to make this a weekly event on Thursdays and can’t wait for everyone to tune in for our next topic: Move programming language.

If you have any feedback about how the AMAs were conducted, please don’t hesitate to reach out to social@mystenlabs.com with your input. We’re always looking to improve.

Learn more about Sui

• Sui Website — https://sui.io/
• Sui Developer Portal — https://docs.sui.io/
• Move Programming Language
• Sui Whitepaper
• Community forums

Build with us!!

We’re excited about what the future unfolds and invite creators and builders to join us.

Recap Sui AMA: Cryptography was originally published in Mysten Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

Highlights

• DevNet data will be wiped along with this release. If you have requested test SUI tokens via faucet, please do so again.
• Added rustdoc output for sui, narwhal, and mysten-infra projects available from both Install Sui and Contribute to Sui.
• Added persistent storage across releases. This will greatly reduce the frequency to wipe data during upgrades.
• Internal network interfaces are now described using the MultiAddr format.
• Internal gRPC network interfaces now use a bincode codec instead of protobuf.

Narwhal updates relevant to Sui:

• Updated the Narwhal release to a188b87.
• Narwhal interfaces now use gRPC.
• Narwhal configuration uses the MultiAddr format to refer to endpoints.
• Bugfix: shared-objects: correct an off-by-one error in numbering in the output of consensus.
• Bugfix: avoid sending empty sync requests to upstream peers.
• Feature: output the full transaction data out of consensus, rather than Digests.

For a complete view of all changes, see:
https://github.com/MystenLabs/sui/commits/devnet

Sui Release Notes v0.2.0 was originally published in Mysten Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.