Dialogue with Mysten Labs Co-founder and Move Language Creator: Detailed Explanation of Sui Technical Solutions and Roadmap

Source: Mynft Twitter Space

Compiled by: Chain Catcher

On August 18, the Mynft team conducted an in-depth interview with Sam Blackshear, co-founder of Mysten Labs and creator of the Move language, in a Twitter Space, discussing the features of the Move language and the development plans for the Sui blockchain developed by Mysten Labs. Below is a summary of the conversation organized by Chain Catcher:

Mynft Team: Hello everyone, I am Millet from Mynft, and I will be the host of today's conversation. Thank you very much for accepting the invitation to join our AMA.

Sam Blackshear: Nice to meet you, and thank you for the invitation.

Mynft Team: First of all, congratulations on the success you and Mysten Labs have achieved. We have sent you a list of questions beforehand; is there anything you would like to adjust?

Sam Blackshear: No, I think it's a great list of questions, and I'm happy to answer all of them.

Mynft Team: Recently, there has been a lot of discussion about the Move project. For example, what are the differences between Move and other languages like Solidity, and what are the advantages of Move? How can other programmers learn Move? It is said that Move programmers have high salaries, and of course, they have a lot of work. People are also curious about how Sui has gained the attention and support of top venture capitalists during a bear market, especially since the competition in Layer 1 is very fierce. To find out the answers to these questions, we need Sam to help us unveil them, as he is one of the founders of Mysten Labs and also the CTO.

Today we mainly have two parts: first, Sam will answer the previous list of questions, which come from our community and media partners, and then we will have a Q&A session. So let's start the AMA. Sam, could you introduce yourself and the project?

Sam Blackshear: I am Sam, the founder and CTO of Mysten Labs, and the creator of Move. I mainly work on static analysis and have also worked on the Diem and Libra projects. In the early stages of my career, I focused on programming language research and earned a PhD, developing some automated bug-finding auditing tools.

Let me explain how I transitioned from language research to the crypto industry. I was doing my PhD at the University of Colorado, focusing on programming language research and static analysis, creating some automated bug-finding tools. This was very interesting and mathematical. What you do is find where the problems are and answer questions about project execution. In this process, you always discover more problems and alternative solutions (semantic solutions), and sometimes you encounter "false positive" behaviors that actually do not occur.

So you can constantly improve, but there is never a definitive answer. By designing clever models, you can predict program behavior, find bugs, and understand how the code works. I spent many years doing this academic research, creating bug-finding tools, running them, and feeling a sense of accomplishment when I found vulnerabilities.

As I was nearing the end of my PhD, I had an opportunity to intern at Facebook, probably in early 2013 or 2014, when Facebook was transitioning from a web-first to a mobile-first approach. At that time, there were some issues with the mobile release. A bug appeared on mobile that persisted for two weeks. The same issue could have been fixed on the web in a day or an hour, so they invested a lot to resolve mobile bugs.

During my internship, I was doing similar work, finding and fixing issues. I had the opportunity to communicate with many programmers, who provided me with real-time feedback on how to do things better and differently. At that time, I developed the idea of wanting to work at the intersection of research and development. So after graduation, I joined Facebook, where I worked for many years on static program analysis, developing automated bug-finding tools, examining null references, finding buffers for overloads, looking into data usage, and exploring new applications of static program analysis beyond bug-finding, such as how to better manage code, how to port code to new frameworks, and how to help security engineers be more productive, etc.

This work was interesting, but you eventually realize that you become very knowledgeable about how to design languages, design frameworks, and ensure security, and you start to feel a bit frustrated with the problems brought by others. You begin to consider whether you can do more, such as how to design a language from the ground up to make it safer, to prevent bugs, and to support tasks like verification. You think about how to help programmers write safer, easier-to-assemble code with other software.

I was fortunate that in 2018, I had the opportunity at Facebook to do this, which was the Libra project, a highly confidential project that involved many experts researching distributed systems, cryptography, databases, etc. I was tasked with looking at the language, which is why Move came about. At that time, I started to become interested in distributed systems and cryptography, and I met my future co-founders, and we established a very harmonious working relationship.

We generated many interesting ideas about how to build the next generation of blockchains, which were perhaps more ambitious than what could be achieved with Libra. Later, we founded Mysten Labs, and although we followed Libra for a long time, we eventually realized it couldn't be launched, so we decided to venture into the vast world of Web3.

So last November, we essentially jumped out and started from scratch to research the design of Sui, thinking about how to make it compatible with Move, what advantages it has, and what new things can be built on top of it. All of this is exciting. So basically, this is my career journey, how I transitioned from research to the crypto field and became the CTO of a startup.

Mynft Team: Your experience is fascinating because you transitioned from Web2 to Web3, with a combined background in academia and industry research, and you have deep expertise in bug-finding, static analysis, and so on. You mentioned composability, which is very important for the next generation of blockchains, and we will discuss that in detail later.

You also talked about building the next generation of blockchains and the Sui you currently advocate. We would like to understand why you and your partners created Mysten Labs. Or perhaps you could start by discussing how you chose the name?

Sam Blackshear: Regarding Mysten Labs, the name doesn't have much meaning. We had other ideas, but considering that we would eventually need to sign legal documents with this name, I thought it was quite suitable, so we chose it.

As for Sui, we actually thought a lot about it and consulted some professionals. In the end, we chose Sui, which means water in Japanese and other languages. I hope that the block space, transactions, throughput, and so on on our platform are all freely flowing and abundant, just like water. At the same time, water is ubiquitous and beneficial to us, so I thought this brand name was nice. From a technical perspective, our founders had spent several years researching on the Libra project, putting in a lot of effort, learning a lot, and gaining many good insights.

At the same time, Libra was ambitious; in 2018, everyone hoped it would become an "Ethereum killer," drawing some designs from Ethereum but doing it better. The initial design of Libra was actually a general-purpose smart contract platform, but considering regulatory requirements and the desire to quickly push it to market, we ultimately felt it should be a payment settlement system. We didn't need to consider handling a large number of orders because, for privacy reasons, most orders would be processed between off-chain virtual asset service providers. We also didn't need to worry about scalability issues because payments and accounts generally wouldn't take up much space. We didn't plan to do flashy things like NFTs, which would take up more space.

Regarding the program, we were more concerned with how to ensure it operates in compliance with policies and how to prevent assets from disappearing or being sent to the wrong places. So we did a lot of work early on, and one of the things we considered was how to reduce the flaws of the Libra project and build the next generation of blockchains. For example, my colleague George is a senior systems expert who participated in rapid payment projects during his time at Libra.

So we basically have two major projects: one is Narwhal and Tusk (consensus protocols), and the other is rapid payments. We also began engaging with clients, especially in the gaming sector, to understand their needs, and they generally have a demand for TPS.

Taking something out of one system and adapting it to handle various throughput and transactions is challenging, though not impossible. But it means starting from scratch, so there will be many difficulties and differences. So basically, this is what we do; we initially focused on rapid payments and then considered what else could be done beyond payments, whether we could do other fast payment transactions. For example, if they don't need to place an order, they can pay quickly directly; if they need to place an order, they follow a normal process.

So basically, we drew some resources from Facebook and established a system with Move, and we are confident it can scale and adapt to any throughput or storage requirements. You can operate it in a Web2 manner, and validators can be a machine or a group of machines. (If you have more demands, you can distribute them across machines.) You know users and companies will have greater demands, so to meet this demand, we created Mysten Labs to build a new layer of blockchain. We hope this system can scale and meet any needs without facing bottlenecks in costs, storage, or throughput.

Mynft Team: Yes, actually, Sui means water in Chinese. You also talked about the flaws of Libra and how you increased TPS to build on the rapid payment system of Libra, as well as your desire to address some limitations of payments or blockchains. What you mentioned, such as payments, are still managed by some centralized organizations. This brings us to another question, which has troubled the blockchain field for many years: the impossible triangle. How do you balance scalability, security, and decentralization? How do you understand this issue? Is there a solution?

Sam Blackshear: This is a very interesting question, and it requires considering various trade-offs, etc. I think there is actually a "fourth pillar" to consider, which is its utility. Because no matter which one you choose, it must be effective for the protocol and for developers. If your solution ultimately has "no utility," then perhaps you have solved the technical problem, but you haven't solved the business problem.

I think, first of all, if you need utility, it must consider its scalability, and of course, it must also consider security. Decentralization must also be considered, but different people have different definitions of decentralization. In contrast, if you ask others what security or scalability looks like, I think those questions will be more absolute, or the correct answers will be fewer, which implies that there is actually a larger design space.

So, regarding Sui, when it comes to decentralization, there are different aspects to consider. You can consider the number of validators, the internal state distribution of validators, the number of full nodes, and the cost threshold for running validators or the hardware requirements. All of these factors are important.

Sometimes we will select precise definitions for these things. So for me, if I want to have some different approaches to the impossible triangle, if we want more throughput and storage, we will need more hardware resources. This is not something that can be done casually; if you need to do more work, you will need more hardware.

Many people are currently exploring sharding at the protocol level to split the state, which I do not agree with. We believe that the usefulness of a blockchain or the vision of blockchain is that you have all the assets in the world, such as all smart contracts, together, able to interact. You can send a transaction that involves all transactions. All financial-related components are together, and you only need one invocation function to complete everything.

You can increase friction between different assets, different smart contracts, and different use cases. Then you essentially hand the problem over to programmers and users, letting them solve the problem and figure out how to bridge that gap. I believe blockchain should eliminate friction.

What Sui does is that if validators need to handle more throughput, I require them to use more hardware and more storage. But we will not compromise; we will not make the work of validators excessively expensive. Otherwise, I believe that ultimately there will be an oligopoly, where the validators are two giants in the network, and no one can afford to check the work they are doing.

Therefore, one thing we are doing that helps address this issue is that our data model allows for an alternative, which is non-voting validator nodes, called Sparse nodes. Their work is the same as that of validators, except they do not vote.

Sparse nodes start with a set of base data, such as some objects you care about and some addresses you care about. They can recheck the work of validators, focusing only on those specific routes. For example, if you are a wallet, you can become a Sparse node and only track specific coins, such as NFTs or game items that belong to you. You can replay all transactions and check whether the validators are honest.

If you are running a game, you can run a game server to understand the work validators are doing on your game state and your players' game states, but only care about your own, not others'. So this is better and cheaper than running a full node.

Considering storage and transactions, running a full node can be quite expensive. But if you only consider a part of the network, only your part, it can actually be very cheap. This is all thanks to Sui's data model, which can clarify the relationship between transactions and the objects you care about. I think this is how we can address the impossible triangle. Of course, you need stronger validators, but that doesn't mean you should compromise on third-party checks of validators. So while there will be higher requirements for validators, the existence of Sparse nodes still ensures their integrity.

Mynft Team: That was indeed packed with insights, and my brain is working at high speed. So instead of doing sharding or partitioning in the blockchain field, you are using Sui to allocate tasks on demand, such as running validator nodes, and this is proportional to the rewards you receive, which helps us interpret it from an abstract perspective.

You also mentioned that you believe the way to address the impossible triangle is through trade-offs, and you think that addressing decentralization fundamentally requires trade-offs. Is this an approach you agree with? Because in your tweets, you mentioned blockchain as a service for large companies. I can understand this as your vision for Sui entering Web2, which is to serve large companies without sacrificing decentralization.

Sam Blackshear: Yes, that's right. I believe that if you want to tap into audiences beyond the current cryptocurrency space, you really need to have scalability that goes beyond current blockchains. So this is what we are trying to provide. Moreover, Sui is carrying the torch on the important journey of decentralization and security.

Sui cares deeply about user use cases and is very concerned with what already exists on the blockchain, such as DeFi being a liquidity engine driving much of the value on the blockchain, and NFTs being important for brands and games. For example, there are now many native use cases for cryptocurrencies. So what we really care about is the mix of old and new; we believe we will be able to do old things better with better programs, such as safer programs and lower costs.

I believe we will be able to have developer experience, scalability, and necessary infrastructure to effectively enter Web2 and attract mainstream and enterprise use cases. So we really care about these two things. We need the old parts, which are also interesting, and we also need new things to benefit from this. I believe this is not a true either-or situation; I think you really need a combination of both to make it successful.

Mynft Team: An interesting point is that Sui claims to be the next generation Layer 1. So compared to other L1 public chains like Ethereum and Avalanche, what do you think are your unique aspects or advantages?

Sam Blackshear: I think these are all different projects. One of our differences is that we have a data model that reflects the relationship between transactions and their final outcomes. This makes the relationship between a transaction and what it does very clear; you can even see it without running the transaction. This makes it easy for us to distinguish relationships between transactions and also makes it easy to identify, for example, when you look at an object, who the last transaction that touched it was. Or if you look at a trader, you want to see related transactions, what objects it operates on, and what it is trying to do. This is the foundation of all the progress we have made in scalability, and it also reflects in usability.

If you look at traditional blockchain architectures, they have many sequential models, which makes scaling very difficult. First, a bunch of transactions come in, and your computer starts working on these transactions, of course, based on global consensus. We have to sort them all and execute the transactions, and many systems need to proceed sequentially, even if they may not be related. You need to process transactions in order because that is the simplest and most obvious correct approach.

There is also a bottleneck. These transactions ultimately have a result that needs to be written back to the database. This database exists in a tree structure, showing your accounts, balances, user accounts, and other information at the root, and you have to keep updating these changes to the top, forming a new tree. As the state grows larger, this tree becomes larger. When this thing becomes too big to fit in memory, it becomes difficult to run it faster and more efficiently.

So basically, you have these different, large, sequential bottlenecks, which makes it difficult to scale the throughput and storage of blockchains. We are trying to eliminate or alleviate these sequential bottlenecks as much as possible.

Therefore, in terms of consensus, because we can look at transactions and know whether consensus is needed, sometimes we can skip consensus altogether and use faster payment methods for transactions, such as token transfers or NFT minting.

If an order needs to be placed, we use Narwhal, which separates the sequential part, such as actual computation and sorting in transaction propagation, ensuring that validators reach consensus on transactions. This gives you a significant speed boost because you can parallelize some parts of the consensus.

In terms of execution, when you know these relationships, when you know which transactions will be triggered, it becomes easy to come up with the most efficient schedule for executing transactions, allowing for maximum parallelism on workloads. Finally, because we know the situation of each transaction, we do not need a large global state concept; we can give credit upgrades for transaction authentication without needing to compute on the data structure.

Therefore, we are working on sequential bottlenecks, which is a reason that makes commercial blockchains difficult to scale. Then, we either try to use fast payments to bypass these issues or completely eliminate them or find ways to find parallel operation solutions. I think this is our unique aspect right now.

This is not to say that there are no other systems doing similar things; many blockchains are currently exploring parallel execution using similar technologies and structures like Merkle trees.

But I believe we have truly achieved a combination. We provide a complete data model that allows us to have more post-optimization. Another thing I want to say is that I have been exposed to these things earlier than others.

Many scaling strategies now involve sacrificing the composability of smart contracts and assets by putting things into multiple shards. Essentially, this sacrifices user experience and developer experience to achieve scalability, so I believe this is where we differ.

We are committed to maintaining developer and user experience by keeping all assets and smart contracts in one place. Eliminating friction is the value of blockchain. Then we have a scalable architecture without needing to make trade-offs and compromises.

Mynft Team: Being able to see transactions even before execution is indeed very important, and you also mentioned the idea of parallelism, which is very interesting and significant.

However, we have talked so much about technical issues; perhaps we can change the perspective and discuss the ecosystem and application issues. Because we know that when it comes to ecosystem development, the intelligent language of smart contracts and various applications are very important, such as the recent DeFi summer and the recent NFT craze. So can you tell us what types of applications you think are the most promising overall, especially those that are likely to be built on Sui? How do you plan to invest in these dapps in the future?

Sam Blackshear: I think some of the use cases you mentioned are very interesting. We have talked to people working in gaming and learned that they have many creative ideas about how to use blockchain, how to make games more engaging, and how to shift parts of the game economy onto the chain.

There is also collaboration with brands to establish interesting relationships between games, so that people's gaming experiences are not limited to just one game. This is also something we value highly.

We are also very concerned about creator monetization, which can be done through NFTs, micro-payments, or anything related to finance.

We are also very interested in traditional finance and how to develop connections with DeFi. Basically, we believe we are building a foundational layer. We will talk to cryptocurrency and blockchain users who are interested in this and have great ideas, who encounter bottlenecks when using other systems, and we will help them figure out whether Sui can help them solve these problems.

We invest in different ways. We collaborate with partners, provide funding, help people develop, brainstorm with them, and discuss how to best use blockchain or platforms like Sui. We hope to ultimately find answers and create something universal and practical that helps everyone do non-speculative and universally interesting things.

Mynft Team: You mentioned gaming and GameFi. Games require composability because they want assets in games to be transferable across different games, and users want to own assets that they can control and transfer across different platforms. This is also something Sui values, and it is part of the architectural design.

We also talked about wanting to position yourselves as a foundational layer, so a related question is how you consider bridging with other chains? Considering the desire to leverage some existing Web3-native crypto assets, how do you plan to bring users of these applications into your ecosystem through some "bridges"?

Sam Blackshear: Yes, we believe this is crucial. There is currently a lot of liquidity and some interesting tokens and NFTs in other blockchains, so we hope people can bring these over. To do this, we need to build a better application ecosystem to attract people.

For example, you can add new features or leverage Sui's capabilities, even at lower costs, and more securely, etc. We will be launching two different bridges soon. We will spend more time thinking about how to connect with existing blockchains and ecosystems.

Mynft Team: Speaking of ecosystems, the ecosystem is a very important aspect of blockchain. So can you tell us what kind of ecosystem you want to build? How will you establish it? How will you support builders in the ecosystem? What specific support and funding will there be? What kind of support will you provide to developers, especially those from Asia? If they see the prospects in this direction and want to join, what should they do?

Sam Blackshear: Yes, we want to build an ecosystem that pushes the boundaries of cryptocurrency use cases and what you can do. We want to keep the original things and make them better; we want to be creative and come up with new ways of doing things and create surprising things. This is our vision.

Because we are not specialized developers; we are not professionals. So I think, from a philosophical perspective, this is what we want to do.

In terms of support, I think the most important support is to encourage them (developers) and help them see more possibilities. Of course, as you mentioned, grants are a very important form of support.

We hope to form a community where people can discuss, set standards, and share code and ideas. This is also something we want to do specifically to support Asian developers. Regarding support for Asian developers, we believe funding projects is also a good form of support. We have deep connections in the blockchain field with Korea and China.

As for the last part of the question, what is the best way for everyone to participate? They should engage in various discussions, ask questions, and understand what is happening. Learn the documentation, start learning how to program, move, and build applications. On this basis, they can also learn the details of how Sui works and what makes it unique. Then they can also check GitHub to see what is happening and see if they can make some contributions. I think it all depends on your points of interest, how you want to contribute, and how we can help you. But I think these are some of the best ways to participate as a developer.

Mynft Team: Is it difficult for developers to learn Move? You also mentioned that Move draws from Rust; can you talk about the differences between the two? Will past development experience help in building on Sui?

Sam Blackshear: I think learning to write smart contracts is difficult. But I believe Move simplifies this process. I think smart contracts are fundamentally very different from traditional programming; they are essentially a very narrow set of tasks, such as you have some assets, you want to transfer them, you want to update them, you want to do some tracking, etc. You wouldn't use a smart contract language to write a compiler, an operating system, a network, or a mobile application.

So this is a very narrow requirement, and programming with scarcity is not something traditional languages do, so this will be a bit challenging, especially for those from traditional language backgrounds. So we use Move to simplify things, making it easier for people to get started.

Solidity is actually a good background. Because it was designed to explicitly address many performance and security issues. So we find that those who use this language feel they can quickly get the hang of Move because it is designed for them to accomplish what they have always done with Solidity, but in a more intuitive, safer, and more efficient way. Some feedback we've heard from partners is that if given some guidance, they can get up to speed in just four or five days. So I think this is an ideal background.

Secondly, I think knowing Rust is also a good background. The biggest similarity between Rust and Move is the so-called borrow checker, which analyzes safety. If you already know Rust, I think transitioning will be easier for you. Because you have to choose some things as your language syntax, and our syntax is also similar to Rust, so if you are used to reading Rust, it will be very familiar to you.

However, compared to Rust, Move is a smaller and simpler language. For example, some things in Rust are difficult to use, such as reference lifetimes, but in Move, you don't have to worry about that.

So we believe that those with these backgrounds will have an easier time getting started. But we also want those without a web background, who don't know Solidity or Rust, to be able to use it. I think the key is to find a compiler to guide you to do the right things and write effective, safe code. Then combine that with a lot of examples and documentation, continuously reading and interpreting the error messages that pop up.

If someone wants to learn Move but doesn't know how to start, they should try writing code, continuously reading and compiling; this is an effective way to teach the language to the masses.

Q&A Session

Q: Move is a relatively difficult language, and our developers have encountered some issues during development, such as its return and search functions being a bit simple, and currently, the corresponding content information, such as line numbers and functions, is also quite basic, with some features not being supported. Will there be relevant updates for Move in the future?

A: Yes, there will definitely be some updates in the future. For example, if you perform a certain test, you will receive a complete trace result to understand where the failure occurred, including source information, etc. You mentioned that some basic functions are relatively simple; of course, we will make improvements. But overall, we spent the first three years focusing on the design of the foundational language because this is a part we cannot change in the future. Once smart contracts are released, this part cannot be altered, and errors will remain forever. Therefore, we are really working hard to get it right.

This requires focused time and feedback, so I think you can expect more improvements because we will see what the biggest pain points are from the feedback and figure out what we should prioritize and how to improve the tools and language.

Q: We know that different ecosystems have different token standards and functionalities, so I would like to understand how your token standard works?

A: We know there are standards like ERC20 and ERC721 that regulate fungible and non-fungible tokens. For example, they specify minting standards, supply, how to transfer, how to split, etc.

For NFTs, there is already an existing standard. From one perspective, NFTs are like metadata; each NFT can be transferred, and if you want a restrictive transfer policy, that is also possible. These functionalities are native to Sui, and there is no explicit standard.

So I think the question is, besides the standards we already have, what else needs to be standardized?

I think the answers are numerous. For example, how to display NFTs or how to display things like explorers? Our approach is to standardize certain name and type fields. For example, a named URL or image; when I show you my URL, I not only show you the text but can also render the image.

We have made some attempts at standardization like this. We hope to build blocks for NFTs and other similar things so that people can mix and match in any way. Rather than having only one unique standard defining these things, or creators having to cater to the demands of leasing companies and operators, etc.

So we are working to figure out which standardization blocks are meaningful and how to combine them. This is a high-level perspective. Of course, people also say we might create a standard similar to NFTs. Specific examples might include Ethereum-style rappers or Netflix-style rappers on Sui, etc.

All these ideas will be realized in the future. I believe we will have various ways to do this, and we have made a lot of progress. I think much of the future progress will be determined by what people want and what they want to create.

Q: Do we have a toolchain? Is it possible for developers to use this toolchain to implement Move, compile it, integrate it with smart contracts, and run it on both Aptos and Sui? Is this possible now, or are there plans to achieve this?

A: Currently, there is no toolchain. It is all related to Move, so the burden of migration is quite low. For example, if you look online, there are many libraries, and many projects are built on both Aptos and Sui.

You can search for Pentagon on GitHub to see related materials; there are actually many cases. They maintain a set of directly accessible directories that look very similar. I believe that automatic translation between them is also possible in some cases, especially if you understand Move and are using the same compiler. However, in other cases, we have many differences, such as scalability, operations, etc., which may be incompatible.

Q: What narratives or areas do you think you will focus on more and give higher priority to? Because the entire ecosystem is quite rich right now, and there are various things on the market, so how will your focus change in the future? For example, what projects will you pay attention to?

A: What I just mentioned is actually quite interesting, such as the gaming industry, creator monetization, traditional Web3 finance, etc. I am looking forward to seeing these things, but more importantly, I am not focusing on technology because these things do not have to exist solely on the blockchain. How these things reflect the founders' philosophies, etc., is what I am more concerned about.

Q: Regarding the name "Sui," it sounds a bit strange and gives a somewhat negative feeling. Is there a possibility that we will change the name later, or why did we choose this name?

A: Actually, I answered this earlier. Because Sui represents water, constantly flowing, pervasive in life, and essential to your life, that is why we chose this name. We are also unlikely to change it because there is a lot of meaning behind this name, and our founders are quite passionate about it. You should know that finding a globally popular name is not easy; people will have different interpretations, and we have tried to find a name that represents water, although this name may have shortcomings in other aspects.

Q: I noticed that Move recently had a collection activity. What aspects are you particularly interested in? For example, what features or areas do you hope to add/collect?

A: I think these things will eventually enter Sui's library or other libraries and activities. For example, the Bloom filter data structure is a great structure. Or talking about functionalities, for example, if you want to check membership without processing a lot of data, that functionality is very useful. We also have a built-in map, which I think is quite useful. I believe there are many good data structures to look at, and we should see what people's basic needs are, such as putting off-chain data on-chain, writing code, decoding, etc.

Q: Sui adopts a very novel approach, prioritizing scalability. As a result, simple transactions can achieve almost instant finality. I am curious about how you would describe transaction ordering, especially considering how it can help us narrow down to financial markets. For example, how are transaction orders determined? On traditional blockchains, it is done in an auction format or first-in-first-out format. I want to know how you would describe this at a high level, how transaction ordering is determined, especially considering sharding, scalability, and parallelism issues.

A: This is actually about considering how you decide which transaction gets ordered when transactions need to be sorted. How do you determine which transactions to process first? What we are trying to do is something very interesting and novel; we provide our clients with a market based on objects.

Because normally, there is a unified price on the platform; for example, there is a hot NFT that is highly valued, and everyone rushes for it. Even if you are smart and can operate in parallel, fundamentally, this matter is sequential, so costs will ultimately rise for everyone.

What Sui wants to do is that when such things happen, the fees for that application will rise, but the fees for other unrelated applications will not rise.

This means we have a way within the protocol to quantify the difficulty of sharing such objects, looking at how many times it has been touched in the past in a block, and then we will incorporate it into a massive priority mechanism. If many people are touching this object, we will require relatively high fees, ensuring that all transactions are not affected by this hot transaction. If you are dealing with other shared objects, such as just doing token transfers, your fees will not be affected.

So we will not have a globally unified price; this fee basically depends on how much competition you create in the system and to what extent you will slow down our transactions.

In fact, we have not publicly disclosed this idea yet. We are really excited because this approach can provide a good user experience while prioritizing transactions, and you will not be affected by every issue. If you interact directly with an object, the only thing you need to worry about is a "neighbor" that touches that object. Moreover, this will be very good for validators, ensuring they can utilize resources most effectively and collect fees as much as possible.