Build Beyond: Cryptographic Innovation on the Blockchain

This week we sat down with Kostas Chalkias, Co-founder and Chief Cryptographer of Mysten Labs, to discuss how cryptographic innovation is central to Sui’s design and what upcoming features he is most excited about.

Can you briefly explain the role of a cryptographer in building a blockchain?

I've been in the field since the very early days of Bitcoin. I actually used to work with one of the first developers of Satoshi (Mike Hearn), yes the real Satoshi. I have a PhD in cryptography, and before the blockchain era, my focus was mostly on academia. Because of this involvement, I can tell you exactly how cryptography works for a blockchain infrastructure company, or for any other company, which is usually broken down into three key roles.

One of the roles is obviously research. You have to innovate in cryptography because it's typically very advanced mathematics. One part is finding cool new algorithms, and at the same time, you're also doing research on breaking algorithms. One of my previous roles for a blockchain company involved reviewing implementations of cryptography and finding attacks for them as a white hat hacker. The idea was “You're a mathematician, you are the cryptographer. Go see the implementation of this particular digital signature algorithm or randomness beacon or whatever. Check if everything is fine.” This is in the realm of research.

Another role for cryptographers is implementation, the concept of applied cryptography. An applied cryptographer literally gets the requirements from the product team—hey, we want a new faster signature scheme, or we want to actually create a new privacy feature for our clients or customers or the community. And then it's not only designing the stuff, the research, it's also implementing it. Sometimes you have to be a very strong software developer, especially if you don't have advanced security programmers on your team, where you have to go through novel optimizations on the coding side.

The third part is creating new products. So you aren’t given any requirements. Instead, because you know a few primitives that might be useful for something not done before, you have the capacity to propose new ideas.

So to sum up…It's the research side. It's the implementation side. And I would say like an octopus, we also have our arms into the product side, sometimes even proposing stuff. This is the role of a typical blockchain cryptographer.

Is it usually the same person who's able to do these three things? Or is it usually a team that's divided into these groups?

For Sui, because we introduced many innovations, we need multiple people working on the many work-streams. I'm the chief cryptographer for Mysten Labs, one of the originators of Sui, so I'm involved in most of the work, if not all. However, you can’t do everything alone. And I can tell you for sure that I'm still learning from my team.

Imagine, we're not just working in one programming language. You might do an original implementation, like a proof of concept in, for example, the Rust language. But then we realize most people on the web, they're using JavaScript or TypeScript, right? You cannot write everything by yourself. But sometimes you can’t delegate to a generalist like a software engineer because there are some optimizations that require advanced knowledge of mathematics and crypto primitives. Or you may need to interact with some libraries you aren’t familiar with, thus you need other people to take over the work.  

On our crypto research team, we’re about 10 people total. All of us work on both innovation and implementation in our everyday work. I'm super happy to be part of this stellar team. We have these “brilliant” minds. Sometimes I am the person proposing the ideas but with so many experts on the crypto team, I'm also following the direction of others. We collaborate. I can help with implementation, or offer resources or give hints on how to extend and apply a cool idea.

Two eyes are not enough. Because cryptography is an extremely critical part of blockchain infrastructure. If something is wrong there, it's possibly GAME OVER. So yeah, you need more pairs of eyes. Plus, you need innovators, many of them.

What are the key advancements that came from outside research that have been applied and impact of the design of Sui? What key innovations have come from internal conversations?

On the cryptography side, an external signal that had an impact on us was the evolution of technologies like zero knowledge proofs, and generally privacy preserving technologies, that have been proposed in the literature. We're in a collaborative environment, right? It's not only the blockchains that are doing cryptography. There are also research institutes around the world, university departments, doing theoretical work. And the thing that I personally see is that Mysten Labs is really good at finding new theories in the space that nobody has ever implemented, where some of the assumptions may not be accurate. But we're marrying it with the existing technology we have, and eventually, this drives us in creating a novel product.

Sui has a new feature, zero knowledge login (ZK Login), that came about like this. Some technology was proposed externally but it was not enough to provide a seamless authentication mechanism for an L1 blockchain. We actually invented new features on top of it, this is the internal vertical of applied research. And then eventually, we came up with a full solution.

We're not a university. We're not just theories. We implement production-ready stuff, right? So we get feedback from both internal and external discussions. Many times, perhaps even more than 50% of the time, we read a scientific paper, we attend events, we are reviewers and presenters, we receive feedback. And obviously, we convert all this into an implementation on Sui.

I realize that some of our code is then being used by other folks, other companies, even outside our industry. You know, we're building some of the fastest cryptographic primitives for use on Sui. But eventually, you see big companies getting this code and injecting it to their own infrastructure, which is not necessarily blockchain infrastructure.

Internal innovation is usually triggered by the product team. They will come to us and say “So guys, you know, this is currently not possible. We haven’t seen research on this. Can you solve this problem?”

For example, the interesting problem of enabling discoverable blockchain addresses, but with privacy. How can I send something to your email or your phone number, even before you create an account? Imagine a Venmo style feature, where I'm sending you assets, and then you go and grab them when you realize they are there. Figuring this out requires internal brainstorming on how to do it properly with a privacy mindset. You get the theory externally. And we marry all of this into a set of tools. Most of the time we’re actually very successful at this. We managed to come up with a solution to the aforementioned problem. It's very rare that we encounter a product question and we don't have a solution.

How does Move allow you to create these innovations in cryptography and a more secure experience in general for developers using Sui?

I used to be a Solidity developer, writing Ethereum contracts. And my passion was also breaking smart contracts on Ethereum. One of my first jobs, I worked on auditing lottery contracts on Ethereum, and I managed to completely destroy some algorithms. At the time, you could pretty much say the randomness algorithm wasn’t fair, wasn’t transparent. This is actually what made me understand that smart contract developers are typically engineers writing small scripts. Smart contracts are not big programs. It's not complex databases with tons of authentication steps for admins. Typically, someone with just a few days of training can write a smart contract and deploy it. But it requires very careful audits (not everyone is properly addressing that), you will be surprised by what we see every week. And then web2 - web3 interactions can have hidden traps.

We realized that on Ethereum there were issues with some safety features on Solidity because of two particular elements. First, engineers are optimizing on compression to reduce gas fees. This could create issues eventually, where you might miss something just because you didn't cover an edge case. And there is also the problem of reentrancy attacks. Like, imagine a smart contract paying to another smart contract without updating its state. This attack vector has caused a lot of money to be lost in the past, including the Ethereum DAO many years ago, which resulted in forking Ethereum.

Move doesn't have these problems because, especially for the reentrancy issue, we protect the source code from scratch. We don't allow people to make mistakes. And also we diverted a lot from the original Facebook Move by creating a more object-centric Move language, which helps a lot on code reusability. You don't need to copy paste smart contract code and then maybe make some adjustments there, as you typically do on Ethereum. You literally invoke the original code and have better consistency guarantees.

At the same time, in Move, we have objects for everything. In Solidity, when you are moving stuff from one contract to another, typically you don't know what it is if you don't have the context. Is this an address? Is this a number? Is this some image URL? What is it, right? Well, when you have everything as an object, similar to Java and C++ and all of the object oriented languages, you can, first, convert existing client projects into a smart contract based world without focusing on a triple optimized compression mechanism. And at the same time, it's easier to read, right? Because you can literally see, oh, this is a tiger object, and I'm transferring you a tiger object.

What about cryptography? When you have these objects, when I'm sending something from one wallet to another address, you will see a pop up saying “You're transferring a tiger NFT. This tiger NFT has X features”. Because of the object focused design, you can see exactly what you're doing, whatever object you are touching. This helps you to identify any issues with your transaction. Many users have been lured by malware or applications trying to convince you to sign something you didn’t intend in other blockchain wallets. But with Move, it's a bit more difficult. If you have a good UI, because of the object-oriented model, users can clearly see what is happening and this enhances end-user security.

The other thing that actually helps designing more interesting and cool algorithms is parallelization that is enabled by objects. Imagine I have some bank notes, a $10 note and a $100 note. If I am giving the notes to two people next to me, I can do this in parallel, because these are not touching the same balance.

On Ethereum, the basic concept is a central account balance and you move stuff from there. So if I am sending or receiving funds, I have to order these transactions. I will first send the $100, then submit the $10 transaction, in the meantime if someone sends me funds, all these 3 transactions have to be ordered. This process is expensive. You need parallelization.

So this is how we get all of the cool stuff from the Move language. We as cryptographers can use parallelization and object oriented programming that Move offers to create better security, cool innovative algorithms. That's the whole idea here. For example, we created a lottery scheme. Although it seems easy at first glance, honestly doing it correctly is typically very, very difficult, especially when building a multiplayer lottery with complex edge cases. This is where good cryptographers shine. We need some randomness, and then you need to buy tickets, but these tickets should be bought in parallel, because you only have one minute or two to cover everyone. How do you do that on the blockchain? Move and its available cryptographic primitives really offer a better and more secure cryptography ecosystem.

Just so I'm clear, something like this lottery system could be used in a product where say, there's 300 tickets available, but 1000s of people want them and you want them to be randomly assigned? And this system is fundamental to Sui so any company could add it to their product?

Exactly. The nice thing here is, again due to the object oriented nature of Sui, you can literally invoke the same contract from many different other smart contracts. We have this concept of composability, which actually helps you to even use the same ticket in two different lotteries. This is super useful for creating new experiences that didn't exist before.

In the gaming sector, you need randomness, and Sui is actually one of the best blockchains for it. It fits the requirements really well. For board games, even in chess which seems like a deterministic game, you need to know who is playing first. Who is white and who is black (and as we know in chess, white has an advantage). It requires some transparency to properly match different players in the same game. There are also governmental applications. Imagine the tax office is doing some statistical sampling and choosing who to audit. Can they actually provide proof that the statistical sampling happened in a fair and transparent manner? You never know, right?

If there is an algorithm with undeniable transparency, that provides good randomness that the organizer couldn't have altered, then there is a new level of fairness to every lottery or random sampling.

You recently wrote a tweet thread about the importance of NFTs being stored on chain in order for them to be dynamic and change over time. Can you share more about this view, particularly how Sui’s data structure enhances the utility of NFTs?

It was a highly debated thread, if you've seen all of the answers from people working on other blockchains. I tried to explain the different NFT properties enabled by different infrastructures. When it’s just a static image, and you don’t do anything with high traffic with that image, other conventional constructions are indeed really good. But there are situations, like with games, where you want more from your NFT.

Sui has a few algorithms that allow for dynamic NFTs, where their fields are updated every time you have an event. When you are playing a game, and you have a hero, and you're winning and jumping levels, you might get some new weapon or power, it can all be recorded on the blockchain, in the state, and create a completely new kind of experience. If storage is cheap, as it is in Sui, NFTs can be stored on chain. This allows you to have easier read and write from different smart contracts and allow for straight-forward composability.

On other chains, you face a problem because the changes are not in the state. For another smart contract to read your contract, they need to know your structure. You need to have an off chain parser which creates some UX complexity. There is also conditional logic in some cool applications, situations where at the time of submitting a transaction you don’t know which NFT you are going to touch, so what can I provide from the offchain world, this doesn’t easily scale.

There is also the issue of the threat model. We had a fruitful debate on Twitter, and I can see their point. Indeed, some particular applications might tolerate compression and off chain storage. But in practice, we're changing the threat model when we're storing something off chain. The reason is typically a centralization element. Imagine that one day, if you store it in AWS, and… Amazon goes down. Amazon is a single company, if it goes down and you lose access to this particular off chain data, you cannot use it on chain; even if you can, you need the data even to generate proofs that you indeed have it off chain, because sometimes you only need the proof, right? For proof, you need to get the content from AWS and then  hash it and send a very small amount of data into the blockchain. And this is verified somehow. But if you don't have the data, you cannot even do this. You cannot even prove what the content of my NFT is.

So there are some centralization issues although some people are saying no, because we can store it in different places. I agree, if we can manage to have a specific design where all of this threat model is encoded into the blockchain, you know, you're not trusting the validators anymore. Perhaps your application can tolerate that Google and Amazon control your data. This is fine.

But sometimes the issue is liveness. Liveness means, in practice, I need the content now with the minimum latency. If you store it elsewhere, latency is doubled, right? First, I need the external storage to be fast. And then I also need the validators to be fast. If we could, we should avoid such a double dependency.

To sum up there are a few important elements. Composability is far easier when you store everything on chain. Another thing is availability. Anything that is stored off chain, including on archival nodes, could hinder this. Archival nodes are not necessarily incentivized to have past transactions available at all times. There are definitely some wallets and other new players in the game that have to pay to store and access this data off chain. This creates dependencies, right? We would want to avoid this by storing everything on chain, or whatever is possible.

I agree that some parts can still be stored off chain, but many of the properties of the NFTs, if they're on chain, you get a completely new experience, contracts looking at other contracts. And liveness depends on the validators.

Really interesting. If what you want to use is static NFTs, then compression is appropriate. But, if you're trying to have a more expansive view of the way the NFTs can be used, then, then the way that Sui is handling them offers you a better option.

Yeah, and note that we have some cool features that are going to be launched in the next few weeks or months. And some of them are confidential NFTs, partially confidential NFTs, and many other applications that do not exist out there. And in many situations, you require some of the data to be on chain just to easily verify encrypted stuff, or even decrypt on chain encrypted stuff.

What are some of the things you’re most excited about regarding the future of Sui?

This is my favorite question. The main reason that I joined Mysten Labs was because I prefer a place where innovation drives product development. And we're offering something new to the community. I even named my son Kryptos. I'm so deep into the technology of the blockchain and cryptography, that I actually convinced my wife to have a child that is called Kryptos. Which is crazy.

If you're asking me in particular about cryptographic innovations in Sui, one thing for sure is the many ways we allow for authentication. Typically, most blockchains only support one signature algorithm. Ethereum has its own algorithm. Cardano and Solana support another algorithm. We tried to be proactive, and be able to have all of the blockchains talk to us. This means we allow all of the existing algorithms, which means we're compatible with more wallets. Existing wallets don’t need to reinvent the wheel. You like one that is Ethereum-based, we're supporting that algorithm, so go and use it. Do you use an iPhone? You don't even need a wallet. iPhones and the more advanced Android devices have this security chip inside them that only supports a particular algorithm. We support this as well.

And then we also have the concept of multi signatures natively. If you're obsessed with security, use the system where you need two out of three different signature schemes every time you are signing. So the authentication part of cryptography, I think it's like one of the flagship features of Sui that will create new authentication experiences.

The other thing that I personally like a lot is that we introduced zero knowledge proofs, privacy preserving technologies, inside Sui from day one. So someone can now create a KYC system with as much privacy as they want. They can construct new authentication schemes. They can even create confidential amount transfers, but also giving them the opportunity to comply with regulation and auditors. They can now have all of these tools without having to personally implement them and possibly make mistakes. We put everything there for the developers to use.

Beyond all these algorithms, we actually offer very good support from our developer solutions engineering team. And we work everyday with teams that are not fluent in cryptography. They don't have cryptographers but work on a crazy cool idea, we help them! And if we get some feedback that something is not available, or questions on how to implement something, we can tackle that too in blazing fast speeds.