In-depth conversation with Sui, Chief Scientist of Mysten Labs How does Sui solve the problem of network scalability from theory to practice?

In-depth conversation with Sui, Chief Scientist of Mysten Labs on solving network scalability from theory to practice.

Recently, we interviewed George Danezis to discuss the complexity and scalability of the Sui infrastructure, as well as how Sui’s transaction processing system facilitates high-performance networks. George Danezis is the co-founder and chief scientist of Mysten Labs (the original contributor to Sui) and a professor in the field of security and privacy engineering at University College London.

The following is the content of the interview:

Q1: You come from an academic background. Can you introduce your research focus?

I am a professor at University College London (UCL), with a research focus broadly called security and privacy. In the early 20th century, I conducted a considerable amount of research on peer-to-peer systems and anonymous systems, many of which were large-scale distributed systems focused on storage. As the entire blockchain became more focused on execution, especially represented by Ethereum, I became interested in distributed ledgers, blockchains, and how to execute smart contracts. I was already very familiar with the permissionless features from my work in early peer-to-peer systems. So, in my research group at UCL, we began to study how to build higher-performance systems. We founded ChainsLianGuaice, a company that commercialized some of our ideas, and later the team was acquired by Facebook. Then, we helped Facebook propose solutions for scaling the Libra/Diem blockchain. However, when the solution did not make progress, I left and continued to seek other opportunities to realize the idea of a high-performance blockchain.

Q2: You are still a professor. What do you think is the difference between application and research?

In fact, there is not much difference. When we conduct research, we consider all possible ways to achieve specific goals, such as building a high-performance blockchain or specific functions. Of course, when building a blockchain or choosing specific functions to use in practical systems, we must choose one possibility. We have to constantly make judgments, among all these good ideas, which ones are actually most useful to people? Which ones are people seeking? What are the bottlenecks to the adoption of blockchain? What is preventing people from achieving what they want to do? When building a system, you still consider all possibilities and try to understand possible situations from academic literature, and then choose the most relevant content. This is not just a matter of knowledge interest, but creating value for users.

• Friend.Tech frenzy subsides daily trading volume drops by 90%, Base network returns to rationality
• Explaining Zeth, the Ethereum Block Validator The First Type 0 zkEVM
• No matter how much emphasis is placed on it (1) 10 steps to ensure the security of encrypted assets

Q3: How do you determine which problems to solve when transitioning from theory to practical applications?

The main problem I address in my research is how to scale different functions of the blockchain. I focus on the system aspects of blockchain, such as how to increase transaction throughput and reduce latency. These problems are obvious whenever we see a contract on Ethereum becoming very popular, and the Ethereum platform cannot handle such a large transaction volume, resulting in transaction congestion and skyrocketing fees. Whenever a blockchain succeeds, we see that the transaction volume it can handle exceeds its existing capacity. So, it is clear that the problem lies in not having enough capacity to meet people’s needs on these blockchains. This is not just our idea; we see this situation over and over again. For a period of time, this was considered a valuable challenge, not only in my team but also in the entire academic community, where everyone was researching blockchains and trying to solve this problem in different ways. Now, quite a lot of technologies have been developed to scale the capacity of blockchains to address these challenges. But at that time, it was well known that many people were solving it in different ways.

Q4: L2 networks are one way people propose to solve the scalability problem. What are the differences and advantages compared to building new L1 networks like Sui?

L2 is a scaling solution within the Ethereum ecosystem. However, using L2 networks can be a bit tricky for application developers. When an L2 network tries to interact with Ethereum, bridging activities must be carried out, although this is true for any L2/L1 relationship. The state representing coins, assets, or other content in L1 must be mirrored in L2, and vice versa. In addition, L2 must have mechanisms in place for L1 to verify everything that happens in it. But this is just the first part, where any assets existing on L1 need to be moved to L2, some activities must occur in L2, and then the assets must be transferred back to L1 in some way. This is cumbersome.

For tokens, which are fungible assets, this bridging activity is relatively smooth because people have two accounts and a bridging middleware. But for more general assets, the effect is not good. In order to develop applications on Ethereum that use L2 networks for more complex purposes than tokens, you need smart contracts on both sides, one for minting and another for burning. They must move between two different ecosystems, which is custom activity for each contract. You can’t simply say, I will create an L2 network and take all the assets away, operate them as I wish, and then bring them back. There is no such concept. It is a manual process and prone to errors. Therefore, this is not a good experience. Imagine that you have assets on multiple L2 networks, and there are custom smart contracts on different L2 networks. Every time you want to operate on a state located on another L2 network, you have to bridge all the way back to L1 and then back to L2. You can’t easily say, I just did something on this blockchain and now I want to do something else on another blockchain without considering whether it is on L1 or L2. Everything is here, in my hands, ready to transact on any state I want to access. That’s why the experience of having states scattered across L2 networks is not good. Moving assets between different chains is very tricky and obvious to users. That’s why L2 networks have never really interested me.

Another example is Cosmos, which has a very interesting ecosystem and takes a different approach by scaling through different blockchains for different apps. We can have different transaction speeds on different chains, and when operations need to be done between different apps, assets can be bridged between chains. However, it also faces the same problem. Every time you want to use a different app, you have to go through the bridging process first, which is subtle and obvious to users, and then you can use the app and bridge back. You’ll find yourself spending more time moving assets from one chain to another instead of doing what you really want to do.

On Sui, our solution is to build a large database that essentially contains the state replicated by all validated nodes. Once you complete a transaction, the state in the same database can be used for the next transaction, and users do not need to constantly move asset states between L1 and L2.

Q5: What is the key innovation of Sui Lutris, the basis of the Sui protocol, that enables Sui to have high throughput and low latency?

Sui Lutris consists of two key concepts: (1) Many operations on the blockchain do not actually require consensus; (2) When consensus is indeed needed, there is a very high throughput method that combines these two approaches. Sui Lutris is the core of the Sui distributed system, ensuring that two different validating nodes following the protocol will never be in an inconsistent state when conducting transactions on the distributed network. This prevents a situation where one validating node thinks you spent a coin and sent it to Alice, while another validating node thinks the same coin was actually sent to Bob.

🌟 Sui Lutris:

https://tech.mystenlabs.com/sui-lutris-the-distributed-system-protocol-at-the-heart-of-sui

There are two different paths: one does not require consensus (fast path) and the other requires consensus (consensus path). When the object you want to operate on belongs exclusively to yourself, such as your own NFT character and the hat you want to combine with it so that your character can wear the hat, theoretically no one else should operate on them. In these cases, Sui uses the fast path, which means you can operate on your own objects and achieve transaction finality without waiting for consensus, ensuring that the transaction occurs and the hat is worn on your NFT head.

However, in some cases, transactions involve objects that are shared by many people. For example, if there is an auction selling small hats, this type of auction is represented as a shared object in Sui. People can bid and the highest bidder wins the hat. This auction is an object that does not belong to a single entity, and everyone must be able to bid, share, and update the state regarding the latest bid, which requires additional consensus. Sui Lutris allows you to own shared objects and perform transactions on them, so that you can own other objects, change the state of shared objects, or create new shared objects. It allows both paths to coexist and interact between exclusive objects owned by specific individuals and shared objects shared by multiple people.

These two different paths have different advantages. The fast path for exclusive objects has extremely low latency, taking less than a second, very fast, and can be widely scaled. The consensus path has higher latency, usually exceeding one second, and the capacity is quite high, but compared to the first path, it is more difficult to scale. On Sui, those apps that truly drive on-chain apps with millions of transactions daily usually use the first path and largely structure their apps to perform the most transactions on exclusive objects rather than shared transactions. On the other hand, protocols that perform complex tasks (such as DeFi) typically implement the second type of transaction because they need to combine bids or liquidity from many different people to execute operations.

Q6: Can app developers on Sui design their apps to take advantage of the fast path?

Yes, absolutely. I think this is a core aspect of expanding app design on Sui. Smart contract developers can fully control whether the objects they operate on in the contract are exclusive or shared objects at any given time. A trick to expanding apps on Sui is to ensure that most operations are performed on exclusive objects, as Sui can manage many operations with very low latency, which provides a great user experience. Actions required for games should fall into this category, as their latency is very low compared to operations that require mediation through shared states and shared objects. Once clicked, transactions can be completed immediately on the network.

Smart contract designers have complete control over this and can specify what transactions are in each category. Of course, the first version of the contract can treat everything as shared states and all operations will be processed through a higher latency consensus path, but as the need for expansion arises, developers need to consider to what extent these parts can be eliminated.

Q7: How does the programmable transaction block play a role in this?

The programmable transaction block can play a role on both the fast path and the consensus path. If a programmable transaction block only involves your exclusive objects, it means you can perform multiple operations in one chain operation. For example, suppose you are a CEX app where many people buy and sell different coins. You can perform one transaction on the chain, which conceptually corresponds to the content people are buying and selling. But because you are the exchange, they all belong to you, so you can settle a thousand transactions simultaneously, which is the fast path. On the other hand, if some objects within the programmable transaction block are shared, then it enters the consensus path, and the latency will be slightly higher, not less than a second but several seconds.

Q8: After being online for more than 100 days, has Sui’s performance confirmed your research assumptions? Is there anything that surprised you?

Several things have confirmed Sui’s design, but there are also some thought-provoking aspects. One is that when there is a particularly high transaction volume, even at a specific moment, the daily transaction volume exceeds 60 million, with the majority of transactions on the fast path. Sui Lutris is highly scalable and has very low latency. It was not clear before whether this path would be used, but it was used when there was a need for high transaction volume and low latency, and it was very effective! It is easy to see that this approach. During those days, Sui’s transaction volume exceeded the sum of all other blockchains. This is an interesting validation that proves the rationality of Sui’s design.

At the same time, the Sui community found this fast path to be a bit subtle. Because the owners of the objects have to some extent manage the order of operations on their own objects, sometimes mistakes can occur. Sometimes they may even use libraries that do not help them and the libraries themselves have bugs, so sometimes objects get locked. Usually, they will be unlocked at the end of the day, i.e., at the end of an epoch, but this is not a good experience. Those who design smart contracts may be afraid of this and worry that such situations may lead to errors, which prevents them from fully utilizing the facilities of low latency and scalability. A set of technologies is being developed to allow those who have mistakenly locked objects to unlock them quickly within a few seconds. Therefore, if you try to use the fast path, an error occurs and your object is locked, you can immediately unlock it using the consensus path without waiting for the end of an epoch.

And, strangely enough, this is not just to avoid mistakes, it also allows developers to express more things through the fast path, and there are some potential techniques where some objects are not owned by just one party. Perhaps there is an object that is owned by both you and me because it is shared, and usually transactions on that object must go through a consensus path. However, if Sui has a way to quickly unlock objects, developers can actually try to transact through the fast path. In the case where you and I happen to transact on the same object at the same time, the system will be locked and unable to determine which transaction occurs next, and then Sui can unlock it and make it go through the consensus path, making it shared and resolved. But this situation is unlikely to happen unless people intentionally try to compete. Once Sui has the ability to unlock objects, it should be able to allow objects owned by multiple people to go through the fast path. This is a game that tries to pass as much transaction volume as possible through the fast path, and it is a type of thing being developed to help build the builder community.

Q9: Can you share more details about the current causes of object locking?

When an object belongs to you, the reason it doesn’t need to tell Sui the sequence of actions that occur through consensus is because no one else can operate on your object. Sui relies on you to tell the system that action A will occur first, action B will occur next, and action C will occur last. The system still has to check if ABC is seen by everyone in the same order. This system is implemented through a distributed protocol that only checks if we have all seen ABC in order. The problem is, if you make a mistake, or if your software makes a mistake. For example, if your phone controls your assets and your computer controls your assets, and your phone indicates that A is the first to occur while your computer indicates that B is the first to occur. You have mistakenly sorted two different things. This is a contradiction. In this case, Sui would say, “Well, the entity that I entrusted to tell me the order seems to have given me two contradictory things, so I don’t know what to do. I don’t know how to resolve this issue.” Because Sui usually resolves this issue through the consensus path. But here, you are trying to use the fast path. So Sui raises its hand and says, “Well, here is an error.”

The initial assumption was that this situation would not occur frequently, but it turns out that it happens frequently because people use different devices or try to transact on the same object at the same time. Currently, when these objects are locked, Sui waits until the end of an epoch to unlock them, which is very concerning. Imagine if your assets cannot be used in a day, it could actually be a serious problem.

Therefore, Sui now needs to develop the ability to take the correct action when something is locked. If the entity entrusted to provide the correct order gives an ambiguous order, Sui will resolve the entire situation through consensus. This will happen within seconds rather than at the end of an epoch.

Q10: Many of your studies revolve around privacy. What are your thoughts on how public blockchains can best balance transparency, traceability, and privacy?

Balancing transparency, traceability, and privacy in public blockchains is a highly relevant question that depends largely on the specific application. In terms of privacy, my perspective is that the level of privacy required largely depends on the nature of the application. For example, on Sui, it makes sense for application developers to develop contracts to protect the privacy of their users. Some developers may only be interested in developing games and may not prioritize privacy concerns. On the other hand, those who want to process financial transactions on the blockchain may have greater privacy concerns, but this may also involve other types of regulatory issues. So, Sui’s approach is to provide a good platform for users to build privacy on top of it.

To help people build privacy, Sui provides native support for certain encryption methods that can be useful when designing smart contracts. One of the most important capabilities is the ability to verify zero-knowledge proofs on Sui. There is a built-in function that can verify one of the most widely used and understood schemes, the Groth16 scheme developed by my colleague Jens Groth. This means that app designers can actually verify certain events off-chain without revealing what those events are. This is a fundamental building block for building a whole class of privacy-friendly applications that keep some state off-chain but allow you to verify on-chain that anything that happened off-chain is correct.

Application developers decide what kind of privacy protection their applications need and use these native supports to combine on-chain, off-chain, and on-chain encryption strategies to address any privacy issues they may encounter.

Q11: Are there more native privacy supports on Sui?

The community is considering the support needed for developers to write smart contracts in a more privacy-friendly manner, and zero-knowledge proofs are one of them. Some may argue that Sui needs more general mathematical or cryptographic functions on-chain. We would love to see feedback from smart contract designers on what is missing and there are other classes of technology that can be used to protect privacy, such as multi-party computation or trusted hardware. Different blockchains are already moving in these directions, and they require complex additional systems. There needs to be enough evidence in the community that people want these technologies because they represent some fundamental changes to the Sui architecture. But if the community wants to move in this direction, there will be a process to propose adding privacy protection mechanisms.

Q12: How do you think Sui will develop in the next 6 to 12 months?

It depends on what kind of applications are developed on Sui. In the short term, many improvements will be focused on the actual applications being built. From a very long-term perspective, 6 to 12 months can be seen as a very long time in the blockchain space. We will be improving the Sui Lutris protocol to achieve lower latency and simpler protocols to enable better scalability. Additionally, we will make the economy more efficient, allowing validator nodes to run on more limited hardware and utilizing existing hardware for actual transaction execution rather than cryptographic or other blockchain overheads. These are the things we expect to see.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!