Original Author: Sui World DAO
Last year, a16z and other institutions strongly promoted the Move public chain represented by Sui, which made the Move language come back from the ruins of Meta Diem. At the same time, from the moment Sui Move appeared, the unfavorable voice has always existed:
If only because the Move language may be better than Solidity or other development languages, do we necessarily need a new smart contract language, and will we be happy to build a new Layer 1 from scratch?
Recently, the a16z Crypto team and Sam Blackshear, the co-founder and CTO of MystenLabs and the father of the Move language, conducted a podcast conversation on the theme of Programming Languages Crypto, discussing why Move is an important direction for future smart contracts.
In this podcast, a16z Crypto and Sam Blackshear discuss the design thinking, object-oriented and Asset programming, security, and shared formal verification, governance and community tools, cross-platform adaptability and other topics.
The main sharing contents include:
1. Programming language and smart contract history
From traditional programming, to smart contract programming, to Move programming. Move was the earliest look at how to design a language to accommodate issues like type systems, static typing, and compile-time checking.
2. Innovation of Move smart contract
The EVM overfits the implementation details of the platform, which were designed for Ethereum. Developers ended up having to inherit many of the design decisions made by Ethereum, including some bugs that made Ethereum difficult to scale. Move was designed without adding anything blockchain-specific to the core language. Innovation at the source code language level will be quite important, and what Move will eventually be able to provide is a code validator and VM-level protection from attacks by other programmers.
3. The design idea of Sui Move
Move is an executable bytecode language used to execute user transactions and smart contracts. In Sui Move, verifiers can be parallelized more efficiently, which makes storage and execution easier without having to encode these things to the protocol level and let users and programmers consider them.
4. Security
In the world of smart contracts, we are in a state of constraints. We write a very small amount of code, and it has to be flawless, and security has to be a top priority. Move security is about preventing programmers from stepping on their own feet, but also giving them the correct primitives where possible so they can defend against attacks.
5. Object Orientation and Assets
Move was designed as an object- and asset-oriented smart contract programming language because most Web2 object-oriented programming languages are like that. In Sui Move, by placing the central point of things on objects, there is a high incentive to be able to represent fine-grained access as precisely as possible. The structure of Sui Moves global storage is a mapping from object ID to object ID.
6. Security comparison
Move eliminates reentrancy and missing permission checks in smart contract programming by construction. In Move, object ownership information is actually stored in object metadata, which is not something the programmer can control. Move Prover is designed to prevent language errors in writing smart contracts, which can prevent developers from making many basic mistakes.
7. Governance of smart contract language
Initially, Move was developed at Facebook with no real governance. We extend the language very carefully. Simplicity is the main thing, but we will aggressively extend it. Sam Blackshear has a very specific wish, such as Move being designed as a cross-platform language in which some of the basic functions of the chain EDM should still be applicable, and it covers both smart contract development experts and Web2 newcomers, with great flexibility.
8. Learning suggestions for developers
Reading a lot of code is the best way to learn about the language. Be willing to share and dig deeper, and find people who really enjoy sharing your code with others and building an open source community together. Any tool that can make your job easier, you should learn how it works.
first level title
Host Sonal Chokshi Introduction
Welcome to Web 3.0, a show from the team at a16z Crypto about building the next generation of the Internet. Im your host, Sonal Chokshi.
This show is designed to help anyone, whether a developer, creator, architect, business leader, or policy maker, seeking to understand and dig deeper into matters related to encryption and Web 3.0. We are now starting a brand new season of the show. Todays episode focuses on programming languages and cryptocurrencies, both for existing smart contract programmers and for other developers looking to break into the space. Its also a good option for those curious about the evolution and emergence of programming languages.
Our special guest today isSam Blackshear, co-founder and CTO of MystenLabs, the company is laying the groundwork for the decentralized future of Web 3.0. Sam has a senior history in programming languages, from his Ph.D. to working at Facebook, to creating and being the author of Move and the open source programming language for building smart contracts. We will talk more about this topic.
Throughout the program, we also inviteNoah, Smart Contract Research Engineer at a16z Crypto, he and another partner recently developed a lightweight client for Ethereum called Helios and won the challenging gas optimization.
We also inviteEddy Lazzarin, lead engineer at a16z Cryptofirst level title
The History of Programming and Smart Contracts
Host Sonal Chokshi:
Well start with the history of traditional programming with Noah speaking first, followed by Sam Blackshear and Eddy.
a16z Crypto Noah：
We want to understand how programming history affects the history of smart contract programming, because I think there are three things, traditional programming, smart contract programming, and Move language. All three things have their own history, right?
Sui CTO Sam Blackshear：
Yes, I like this framework. Its true that people use language to design syntax or make people happy, but its more than that. So I like this big picture framework very much.
a16z Crypto Eddy Lazzarin：
On this basis, traditional programming has various trends in the past two or three decades. Traditional programming languages have changed, with some hot topics coming and going. There was a long time when dynamic programming languages with very loose type checking were very popular. Its generally believed that jumping in, forgetting types, forgetting all the technical details, and just writing code is the more ergonomic way to go.
Sui CTO Sam Blackshear：
But recently, people have started thinking more deeply about things like type systems, static typing, and compile-time checking to know as much detail as possible about a program before it runs. These trends are constantly changing. However, for smart contract programming, since its so new, we havent seen this type of history in smart contract programming, which is very different.
I think the Move language is the earliest evidence weve seen of how languages can be designed to accommodate this (issues like type systems, static typing, and compile-time checking). Im curious to see what changes we expect to see in smart contract programming like static and dynamic typing? These topics may not come up yet because there is currently only one language, Solidity.
Host Sonal Chokshi:
So, how does this relate to the move to smart contract programming? Sam again please answer?
Sui CTO Sam Blackshear：
In this smart contract space, there are different trends with EVM as the first entrants of smart contract languages. People dont know what they want to do with smart contracts? How we write them or any of these types of things So I think flexibility is more important to try to understand the types of experts that need to discover the usage. I feel like now we know, or at least we know something about the building blocks.
The trend of smart contracts is extremely domain specific, you define templates for assets, define policies for transferring assets, check access control and permissions.
Thats the basics, you dont write a compiler or an operating system or any of those types of things in a smart contract language. So theyre very, very good, their advantage over general-purpose programming languages.
I think people underestimate that the EVM is even considered one of the basic building blocks for writing Ethereum programs even though the ERC-20 standard happened long after the EVM was programmable. I just dont see any obvious evidence that the most basic things are clear before then.
So youre right, now you can take types for granted. I think types and the bypassing of these things can bear a certain amount of technical debt. If the scale is small, you just want to move fast, and the code can be thrown away, then this kind of technical debt is perfectly acceptable. But its interesting that you describe it in terms of the size of a company or a startup, a small company growing fast, where everyone understands the entire code base, and this kind of technical debt is tolerable.
But when its very, very large, there are tons of people changing the code who dont know the ramifications of the new objects and systems theyre building. Putting this into the type system allows you to write code in an unambiguous, straightforward manner and hit the roadblocks instead of accidentally creating glass fences that someone will bump into later.
For example, as you guys talked about, being able to prevent duplication, being able to set a maximum supply of an asset. These constraints are very important and need to be maintained regardless of the size of the project. They are very important constraints to maintain the health and security of your project.Knowing these boundaries means you can now create programming languages that allow you to enforce them. Thats how I see the Move language.
As we learn the types of constraints needed to do the right thing, we now have the ability to include them in the language itself. So I do think its somewhat similar to types, like you said.
You mentioned that types are very important to program sanity and safety.You guys say that dynamic typing might be fine for small projects, but as projects grow, static typing should be used. I kind of disagree, I think fully static typing might be a better fit. This might be a novel take. Its for programmer sanity. The scariest thing Ive ever seen is when I press my shortcut control k it tells me what the function signature is. This scares me when I write Python. I look at the function signature and only see the names of the parameters. I was like, what the hell do you want me to do?
a16z Noah：
I cant believe people accept the idea of writing code and never looking at it again.
a16z Eddy Lazzarin：
They accept the default assumption that they can keep the systems requirements in mind.
a16z Noah：
But even with a 100-line program, I dont think its possible to default to this.
Sam Blackshear ：
It works, but its not perfect.
a16z Eddy Lazzarin：
I think you are right. And I think that mentality has evolved. Previously, type systems were used to protect programmers from colleagues.It comes in handy when your startup gets too big. But now its more like protecting myself.
In the context of smart contracts, its protecting me from attackers. This is the real difference, because in normal programs, you dont deploy programs when an attacker is bound by the type system. An attacker can write machine code in other languages. You just need to protect your own firewall. But here I write this nicely typed object that will flow into the attackers code and keep it intact. The type system has to keep me safe.
Like you said, its a great tool that brings different requirements to you, and you need to enforce them, like preventing copying. Thats not something you need to think about in a normal type system, or prevent deletion or make sure you use or destroy a value in a certain way. This is all because were working on smart contracts and trying to come up with a meaningful type system for these use cases, so well end up adding these things to move, and possibly future smart contract languages as well.
Host Sonal Chokshi:
Actually, guys, lets talk a little more about other differences between traditional programming and smart contract programming. But before we go any further, can you guys give a quick overview of the languages available to smart contract programmers? I think we need to take a look at the big picture because I want to look at the status quo, like Solidity, Viper, etc. Knowing what content can get us started faster.
Sui CTO Sam Blackshear ：
Yeah, I guess the basics are that if you want to write smart contracts, youll almost always be using solidity. Unless you happen to be in one of several other smaller ecosystems.
If you are in the Polkadot ecosystem, you will use ink! (Sui World Note: ink! is a smart contract language developed by Parity for writing smart contracts in Rust and compiling to Wasm code), which is an existing Programming language. If you are in the StarkNet ecosystem, you use Cairo (Sui World Note: Cairo is one of the programming languages for the STARK proof system).
But for the most part, if I were to give advice on how to write smart contracts, I would suggest you learn some Solidity and then learn the EVM. You might also want to use Viper, the only downside is that Viper is newer and may be more prone to bugs. I remember a few years ago, when verifying the deposit contract, they found a bunch of bugs in the Viper compiler. The guy who found these bugs is now working at 16z, hes Day June, hes a formal verification expert.
Since Day June is an expert in formal verification, he is now working at a16z. And the reality is, you need to learn some content, you need to learn some language.
You even need to understand the EVM in depth, and if you want to be a really good smart contract engineer, you need to understand the EVM to a ridiculous degree, so that you can tell the gas cost of each operation, they can tell you the exact code related to the gas cost. This is the world we currently live in.
a16z Eddy Lazzarin：
Perhaps its worth mentioning that, as a software engineer, you can always learn about the machine youre running your code on. There is a lot to know about programming environments. But in smart contract programming, the environment is very rich and complex. Theres a lot of context to understand, almost independent of the language itself. Thats whats going on around you, what objects are around, how different codes are called. This is a very strange thing.
Host Sonal Chokshi:
So is it true that the closest people to learning Solidity are people who know JavaScript?
Sui CTO Sam Blackshear ：
People say its JavaScript because it uses the keyword function, just like JavaScript does. But unfortunately, they are not very similar.
a16z Eddy Lazzarin：
From a grammatical point of view, Solidity does inherit many JavaScript features. If youre squinting or in a bad mood, it might feel similar, but its actually quite different. Virtual machine environments vary widely, so there is very little in common.
Host Sonal Chokshi:
Are there any similar programming languages?
a16z Noah：
Yes, I dont think there is a directly similar programming language. If you are familiar with Was (Sui World Note: WebAssembly Studio, an online tool for compiling C/C++ and Rust code into WASM format. ), and trying to write code in an environment that requires a high degree of isolation (such as Surplus), This is probably the closest thing that these codes are to execute independently, but require some level of communication. But its still not very similar, the way of thinking is completely different, and superficial similarities can be dangerous.
a16z Eddy Lazzarin：
Perhaps relevant are some great mistakes in the history of programming languages.I dont know if there is some nasty history of going down the wrong path when it comes to blockchain. Have we gone down some terrible paths?
Host Sonal Chokshi:
Thats a good question.
Sui CTO Sam Blackshear ：
Thats a good question. In 1977, the C language was released, which was also the year Standard ML was released. Standard ML is extremely influential. Now, the OCaml language and the Rust language are greatly influenced by it, and the Move language is also affected by it. But these ideas have been around for a long time. I think a lot of people are thinking about an alternative future where instead of C being mainstream, the ideas of Standard ML are widely accepted, like strong typing, built-in safety.
Host Sonal Chokshi:
So, what is this trend in computer technology? Im not saying its a mistake, but I think a language like Standard ML looks very modern even today. Imagining that alternative universe is an interesting thing, and I was blown away when I first discovered it.
a16z Eddy Lazzarin：
Out of curiosity, why do you think languages like C and similar are so straightforward and imperative? They think about computers at a relatively low level, and as programming languages they dont really do a whole lot, thats how I feel about C, why did we go down this road?
Sui CTO Sam Blackshear ：
I think the hardware constraints at the time forced you to use C, and if you wanted to write efficient programs, or push the boundaries of computing, I think if you pushed the hardware forward, you would choose another path. But in my opinion, functional programming is hard, its counter-intuitive in many ways. Im not saying that C language is not difficult, but I think it is easier to get started. Then you realize, Ive done something very complicated, or rather hard to reason about, but its too late. Thats a good idea, functional languages do have a steeper learning curve, but once you get the hang of it, you realize that I can think about my code pretty well on my own, and things work out pretty well.
a16z Eddy Lazzarin：
I think a language like C is more straightforward if you think a lot about how computers work on a hardware level. But if you dont know much about programming languages, then C language is easier to get started. But if you know programming languages very well, then I think ML and functional programming types of languages have more to explore.
Sui CTO Sam Blackshear ：
This is a big picture answer. But what I want to say is about the small-scale computer language error problem.
a16z Noah：
So, Im a bit hesitant about this because I keep hearing how awesome functional programming is, but Im finding it a little hard to understand. But the question Ive always wondered is, if functional programming is so good, why has it never been able to overcome the network effects of current programming languages? Its the way it is that surprises me.
But I would like to add that I think the great contribution that functional programming brings us is that all the imperative languages we use are borrowed. But the best part is, like you just said, Rust is heavily influenced by standard email, but Rust is basically an imperative language, right? But it has all the wonderful fairy dust that comes from gazing at them.
Sui CTO Sam Blackshear ：
In general, I think the real problem is that imperative languages have had too much influence since 1977. Then theres PRFP, as you said, its not the greatest, it has its own great ideas, and in isolation, everyone has their own problems. We only see real biracials like Rust marrying them beautifully now. It really changes the landscape.
So one of the things I want to mention is what Tony Hoare calls the billion-dollar error of node references. While he may have been exaggerating at the time, the mistake was clearly more expensive than not making it.
a16z Eddy Lazzarin：
first level title
Innovative development of smart contracts
a16z Noah：
Im actually curious that you havent talked much about innovations at the virtual machine layer and programming language layer, and how they affect the development of smart contracts.
Sui CTO Sam Blackshear ：
Thats a great question. I dont think people have given enough thought to the distinctions, like the difference between the virtual machine layer and the programming language layer. In fact, besides the EVM and the new virtual machine layer, there are many innovations, such as source code languages such as Viper. These things are better than Solidity in many ways, and fun.
I think that if Move is to become the legal standard for the Web 3.0 we expect, innovation at the virtual machine layer will be slow and incremental. Because the core is fixed, well only add new stuff, not a complete redesign.
However, I think innovation at the source code language level will be quite important. Right now, we only have one source code language, but its closely tied to the bytecode format. However, as more and more clients use smart contracts, with an emphasis on security, I can imagine that there will be a lot of different source code languages to try, and this is an interesting area of research. Perhaps you could start by writing down your previous facts and then synthesize their information for you in the program, or a suggestion for limitations.
Maybe you could start by writing the facts before your Move, and then have the compositing program populate the program for you, or suggest constraints.
For example, you might write Moves in the context of a very specific game that looks like a scene hierarchy. Maybe its written in a Python library, but compiled to Moves bytecode. Maybe you, like Solana or other platforms, are thinking of integrating Move, but dont want to integrate a virtual machine, but by compiling Moves bytecode to Salinas bytecode format and then using the Move source code language at the developer level.
I think there are many different approaches, just like JVM (Java Virtual Machine). The JVM is a wonderful general-purpose virtual machine that originally only supported Java. But its stood the test of time, and now you have Scala, Groovy, and some other interesting ways to use these primitives to design different programming experiences, very much in line with what people want to do.
So, I have a biased view that Viper gives you a lot of room to experiment at the source language level.
a16z Eddy Lazzarin：
What are your thoughts on all alternative EVM bytecode languages? Are you optimistic that there are interesting efforts like FE, Iron, Viper etc. to build smarter, more complex languages for the EVM?
Sui CTO Sam Blackshear ：
So these are different source code languages compiled to EVM bytecode.
a16z Eddy Lazzarin：
Yes, compiled to EVM bytecode.
Sui CTO Sam Blackshear ：
When we started designing Move at Facebook, we looked at Solidity and Viper when we saw other source code languages building the EVM, which is when we started building the EVM. What we ultimately came to the conclusion is that the most difficult problem for people to write secure smart contracts is the underlying nature of the EVM, and how to make typed values flow on trusted boundaries, and dynamic decision-making and so on. Features of the EVM.
If you build a better source code language, you can make it harder for developers to screw up. Maybe they could do more advanced validation,But ultimately, what Move is able to provide, and what we think is important, is code validators and VM-level protection from other programmers.
A source code language cant give you this, it has to be built into the VM, no matter how many times you iterate on the EVM for a perfect source code language, I think Solidity is great and we can do better, but I think if you dont With these basic safeguards built into the VM, you end up with results that are not as good as some other paths. Im not embarrassed because I think Half is cool, but because I dont think the end state is as appealing as the other paths.
I think early smart contract languages, especially the EVM, overfit the implementation details of the platform, which were designed for Ethereum, internally including instructions on transaction structure, account structure, using certain types of cryptography etc.
I think this makes it very difficult to use the EVM on a chain that isnt like Ethereum, and you end up having to inherit a lot of the design decisions that Ethereum made, and maybe in some cases, some of the things that made Ethereum difficult. Extended error.
When designing Move, we were very conscious of not adding any blockchain-specific things into the core language, and making it as independent as possible from the specific blockchain.
So you can take Move and use it on a proof-of-work chain with a crazy transaction structure that might be doing this in Sweden and another chain thats doing it in Australia. This way, you dont have to bet on a particular chain to be a Move developer. You can use your skills across a variety of different chains, including future chains. We think this is critical to the survival of a smart contract language, because a languages greatest asset is its community. And by making your skills cross-platform, rather than overfitting to one language, you can scale up your community and be better positioned to succeed. And then a big community is what makes it possible to invest a lot of money in tools, a lot of money in public libraries and all the things you really need for a language to be a big name and be successful.
Thats what weve tried to do from the beginning, and now weve seen multiple really different Move chains that are very different in how they integrate the language.
a16z Eddy Lazzarin：
It seems to me that this is the underlying theme of node.js, right?
Host Sonal Chokshi:
Yes.
a16z Eddy Lazzarin：
There are a lot of people who know JavaScript and they want to do a lot of things. They want to share various libraries. Existing code can start a server-side JavaScript instance, which makes node useful. This means that there are all kinds of developers who may not do backend programming, but can start to jump in and make it their field.
Sui CTO Sam Blackshear ：
I think its a good comparison. Also, we wanted to talk a little bit about programming language governance, because Node obviously has some very high profile governance splits and splits, and every programming language community has many high profile governance splits and directions. Ive covered Node and its one of my favorites. But I want to make sure we finish this topic. Is there anything else to say? I think youre the resident oldie on our radio show, which I love.
a16z Noah：
So I have a counterpoint, or rather I have a cool idea.Ive been wondering why no one built an OP Rollup for Move, that would be really cool,Considering that the OPs Rollup folks are implemented on Ethereum, they use MetaMask and ECDSA signatures, but dont seem to use the same signature format as us, like Move doesnt seem to use ECDSA.
Sui CTO Sam Blackshear ：
Yes, we support Ethereums EdDSA and ECDSA signature formats.
a16z Noah：
Perfect, but my point is, you can build some really interesting stuff. However, when I was trying to learn Move, I kept staring at Dessert and Actor Dog. Im confused.
Sui CTO Sam Blackshear ：
Indeed a problem, right? When someone starts learning Move, they might be confused: Im learning a smart contract language, but where is the blockchain? The differences between them can also create problems if you try to write code for both platforms. So I think the challenge that were still trying to figure out is, pick a platform, pick a dessert, pick an Optus, learn it in depth, and then you find that your skills and code can be easily transferred to another platform. I think there are some inherent issues here, and some documentation issues that need to be ironed out to make this easier.
a16z Eddy Lazzarin：
Perhaps an analogy depends on whether you consider SQL to be a portable skill. There are many dialects of SQL. There is an anti-SQL, no one really knows what it is, but they can learn SQL, if you squint your eyes a bit, you can use any database, maybe a bit confused about specific function names or specific types, but roughly the same shape. I think this makes SQL very powerful and durable. Thats why its still part of the lingua franca of data. Maybe this is the future of Move. I think we can do better.
Sui CTO Sam Blackshear ：
first level title
Unique things about smart contract programming
Host Sonal Chokshi:
Weve gone back and forth around traditional vs. smart contract programming, specific constraints and differences, and even some similarities between tread and smart contract programming. Is there something unique about smart contract programming that we didnt cover?
a16z Eddy Lazzarin：
Another very important thing in the context of smart contracts is resource usage, like Gas Metering in Solidity. Although computing resources are relatively plentiful in many cases, computational cost is also very important. But outside of a smart contract context or outside of a blockchain context, that means its just less touched and considered. I think the notion in the language of resources you consume could be an interesting resource for smart contract programming.
Sui CTO Sam Blackshear ：
Thats something were very focused on, weve built Gas Metering into the EVM, which, as you said, is very different from traditional programming languages.
I think the future trend is that Gas Meeting will become more and more coarse-grained, more to prevent serious problems such as resource abuse, rather than really fine-grained for each command.
I actually think that things like Gas Golfing (Sui World Note: Gas Golfing refers to the challenge for developers to write the most gas-efficient code in a series of smart contract jump interactions) are very interesting, but they are actually very important for coding. Both style and safety do a lot of harm.
Ironically, the reason we only know about the charge-per-instruction model is probably because if you have a huge virtual machine, the difference between running 100k instructions versus running 500k instructions is insignificant when it comes to actually measuring runtime.
So, why do we charge per order? So I think well see a trend of how to make this more coarse-grained.
Whenever I see all these unsafe blocks and tons of inline assembly in Solidity code, it reminds me of how early we are now, because this is not a programming challenge that a smart contract developer should consider, this is not a A sign of a mature development ecosystem. But we are moving in that direction. I agree that we need to consider edge cases. Choosing the right algorithm, choosing the right data structure, choosing the right general approach, which is the case with most software engineering, is all important. But the trivial question of exactly calculating the cost of each instruction is probably too much work.
Host Sonal Chokshi:
We talked about optimizing gas, types, assets, and security. What other limitations need to be considered?
Sui CTO Sam Blackshear ：
This is a thread similar to gas, but the specific subset I have in mind is state. This is a big problem for me. When I think about gas operations, I like to do extreme gas optimization.
However, when were dealing with actual smart contracts that hold real funds, my general advice is that unless you can go out of your way to use slightly less state than youve used before, you should be reasonably organized. Thats the only time I would use a large block of assembly if you can do something stupid to use less state because this is like a forever resource and we should place it just above the execute or call The location of the data.
a16z Eddy Lazzarin：
I totally agree with this point, because I think its fundamentally expensive. If a platform allows every contract to touch any piece of state, it will be hard to parallelize. And the approach taken by Squeeze and some other new blockchain platforms is to explicitly limit the state that transactions can access, at least let me know some. In this way, at a high level, the platform can more easily parallelize transactions, including execution and consensus. So this is something some programmers have to think about: be as fast as possible when accessing state, and not touch unnecessary state, so that validators can parallelize more efficiently and achieve more block space.
a16z Noah：
Does this open the world to the fact that not all validators need to download the full state even in non-role-playing situations? Would it be possible if you could easily separate the state so that the validator only serves the transactions it can handle?
Sui CTO Sam Blackshear ：
I think its really possible to realize such a world. This also opens up a path for different approaches.
Let me recap, from a programmers point of view, being able to touch the whole world across different transactions is very valuable. However, we cannot emphasize this advantage so much that it has to be implemented via Rollup or across multiple transactions, as this would reduce security for users to notice.
I think the value of the blockchain comes from this abstraction: there is a ledger, all valuable states are on this ledger, and I can touch them all at once. From a programmers point of view, this is where the value of the blockchain lies. The question is: how do you make things work more efficiently behind the scenes? How can it be made more sparse so that validators can be parallelized more efficiently? In Sui, a validator can have multiple workers, each responsible for a portion of the state. But from the programmers point of view, and even from the point of view of other validators, it looks like a logical entity that does everything.
first level title
Changes in the way of thinking about smart contract programming
Host Sonal Chokshi:
We just discussed some of the unique aspects associated with smart contract programming. What other changes in mindset? Weve talked a little bit about, and like Eddie mentioned, a big shift is that in the world of programming, at least since the early days of computing, were in the world of abundance, but in this world, were in the world of limitation. Thats an example of a way of thinking. What other mindset shifts? Especially for each of you, as you programmers who are exposed to smart contract programming, what has surprised you, or taught you, or made you think about certain things differently?
a16z Eddy Lazzarin：
Perhaps a slightly silly example, I still remember the first time I learned a few years ago that the balance of an ERC-20 token is not something your account owns. Your address has no token balance. Instead, there is a Token contract that records which address has how much balance. When you want to transfer tokens to someone, you are not sending them some tokens. Instead, you need to go into the contract and do all these low-level operations, changing the balances held by your addresses and their addresses. You have permission to manipulate and change that contract. Its a very counter-intuitive approach, an interesting shift in thinking about Move that Ive noticed for the first time in the EVM and Slippery. Its an interesting shift in mindset, because the English words we hear a lot dont necessarily correspond to programming models.
Sui CTO Sam Blackshear ：
Id like to add that its about when you actually do it. In the normal world, were very concerned about developer productivity, because its the engineers job to write a lot of code that has only a few bugs, and those bugs arent too severe. Whereas in the world of smart contracts, your job is to write a very small amount of code, and it has to be flawless. It must be perfect in every possible way. Otherwise, you will lose hundreds of millions of other peoples money. Its a shift in a completely different way of thinking. Spending two months staring at 1,000 lines of code and trying to figure out how to make it better, and more importantly, how to make it perfect, and then the reviewers do the same, judging whether its perfect or not.
Host Sonal Chokshi:
This is a big shift in thinking. In the world of programming, at least since the early days of computing, weve been in a world of abundance, but in this world were in a world of constraints.
a16z Eddy Lazzarin：
Another shift in thinking is that in the world of ERC 20 tokens, your address does not represent token balances. You cannot send Token, you must visit the Token contract, find the Token balance corresponding to the address in the Token contract, and then complete the Token transfer by modifying the address and balance. This is a rather counter-intuitive way of thinking, but in EVM and Move, its a very important shift in thinking.
Sui CTO Sam Blackshear ：
In smart contract programming, your job is to write a small piece of code, and it must be perfect, because this code may involve the safety of funds of hundreds of millions of people. You have to scrutinize the code to make sure its correct.
Also, upgrading a smart contract is more difficult than upgrading a mobile app or website because in a smart contract, the code is immutable. In smart contract programming, you have to think about how to support safe upgrades and trust, making it look more like a traditional ecosystem.
But in smart contract programming, you need to have an adversarial way of thinking, which may be unfamiliar to people from other fields. This is because of the deployment model in smart contracts, you need to consider not only the expected usage of your application, but also the unintended usage. Because in traditional programming, there are ways to hide yourself, limit yourself to a small API, or use a firewall to limit the attackers actions, etc.
But the whole point of smart contracts is that what you make can interact with code that you never imagined, and do so securely. Therefore, you need to consider the advantages and disadvantages of this situation. This is definitely a mindset shift from traditional programming.
Host Sonal Chokshi:
Is this a very important question and one that should be prioritized when we discuss how to write smart contracts and use smart contract programming languages?
Sui CTO Sam Blackshear ：
Yes, absolutely. Its actually my favorite thing to talk about. This scares me a lot, the issue that smart contract language designers need to consider is security. Thats the main focus, maybe even the only focus until we get that out of the way.
In my opinion, smart contract security is an existential threat to wider cryptocurrency adoption. The reason I say this is that you can look at Ethereum and solidity, and the most popular platforms, EVM and Solidity. You can look at the early programmers who wrote this code, they were very highly qualified, they really understood the underlying blockchain, they were very security conscious. They know what they are doing. I think they take their responsibility to write code that manages hundreds of millions and billions of dollars very seriously.
But if you look at the smart contract security record anywhere, its pretty bad, and its not the fault of these people. I think this is a very difficult question. And I think language makes it more difficult. So if you look at my favorite site, rakt.news, you can look at the leaderboards or look at these ten hacks worth tens or hundreds of millions of dollars that are very routine and happen every week or month Depends on scale. At the same time, the smart contract developer community is very small, only about 5,000 full-time EVM programmers, which is very, very small compared to the traditional developer community.
So if you believe that the people we have are the most hardcore and safety-conscious, but the development practices and safety records are unsustainable, then I think your conclusion is that theres no way this space can survive without making the safety If the problem continues to grow for the worse, that could mean it doesnt grow at all, or like those big financial institutions or companies that want to get into Web3, theyre looking at whether they have to hire smart contract developers? I would get hacked for tens of millions of dollars and get nervous. This situation will only get worse as time goes on. They may stay on the sidelines. So, as someone trying to design a new smart contract language, security must be your first consideration.
Host Sonal Chokshi:
You guys have actually hinted at that in the context of not losing assets, but what do you mean more specifically because its very important?
Sui CTO Sam Blackshear ：
What I mean by security is that we both prevent programmers from stepping on their own feet and provide them with the correct primitives as much as possible so that they can defend against attacks because a smart contract is a setup where your code is deployed in an attack Next to the attacker, the attacker can call your code directly, can link directly to it. Your code is open source, or at least the bytecode is open source.
This is by far the most adversarial programming environment weve seen, and the most expensive to make mistakes. So, I think if youre talking about smart contract programming design, then security must always come first. Once we get the security out of the way, we can think about other more expressive factors, but heres my somewhat tedious, but I think very important answer.
a16z Eddy Lazzarin：
Which features can affect security? What are some examples of this?
Sui CTO Sam Blackshear ：
I think the most important thing is encapsulation, specifically, the individual sub-features of encapsulation. When you write code, you cannot predict what an attacker will try, so you need to be able to reason without foreseeing what the attacker will do. So, you need a strong type system, not just at the source code level, but at the bytecode level, so that the guarantees you get when you write your source code will be there when you publish your code on the blockchain and other people rely on It stays on and interacts with it.
We observe that certain features popular in other domains are inherently inappropriate in smart contract programming, such as dynamic dispatch.
In traditional programming, things like interfaces and dynamic dispatch are key abstraction mechanisms that are ubiquitous. You can define an interface, and then someone else rewrites that interface with different logic, and you can program against that interface, and all is well and good. But we have a quip: In a world where code is law, interfaces are crime.
a16z Noah：
This is a joke, lets stop for a minute. In a world where code is the law, interfaces are the crime.
Host Sonal Chokshi:
Before you go on, can you explain this sentence a little more? I dont want to jump over it too quickly.
Sui CTO Sam Blackshear ：
Yes, exactly. The idea here is that an interface doesnt define behavior, it defines expected behavior. For example, when you read the specification of an interface, parameter names or even types, it tells you what you want to accomplish. But theres no guarantee it will happen.
So, if you write code to protect something, but youre actually leaving a blank check for the attacker, somebody else to fill in. This appears to be a crime in contract law. This is an unspecified contract. I really like this feature, its popular in traditional programming languages. But we think that in smart contracts, this leads to a lot of different problems. For example, re-entrancy requires dynamic scheduling. For example, if you cancel dynamic scheduling, there is no re-entrancy at all. Things like poison tokens in Ethereum happen because you rewrite the transfer function, and everyone knows that intuitively, its just used to transfer funds and probably doesnt do anything else. But now you make it do something beyond what was expected, like stealing money. Thats an example of a feature that, if you remove it, it becomes much easier to reason about your code and encapsulate it appropriately because every time you see a call site you know exactly what its going to do, you Dont worry about other people doing things that surprise you later.
a16z Eddy Lazzarin：
To be precise, I think the analogy is like if you define an interface about a chair, which has four legs and a seat, and you describe it at the concrete level, not the behavioral level, what you dont describe may be implicit or default The other things about the chair, like it has some kind of structural integrity, its a certain material, its placed in a certain way.
a16z Eddy Lazzarin：
Can be circumvented, meaning that an interface is just an arbitrary set of descriptions that doesnt capture the security constraints you want to enforce.
a16z Noah：
Thats exactly the definition.
a16z Eddy Lazzarin：
Defining things at the wrong level. Im curious.
Sui CTO Sam Blackshear ：
But how do you modularize well beyond interfaces? If interfaces are a crime, Im probably one, because one of my favorite ways to build complex smart contracts is to have different contracts, with different purposes. And, especially in very complex systems, you have a module-based foundation where the modules obey some kind of interface, and then the main contract can know how to call the different modules. These modules are usually licensed through governance, how do you get the plug-and-play modularity of Super Express? No standardized interface? How to get inheritance?
a16z Eddy Lazzarin：
Like all these things to do with interfaces?
Sui CTO Sam Blackshear ：
This is exactly the right question to ask. They can argue against this all day long, but how about providing something that makes you write useful code? Like if youre not allowed out of the house or something, theres no crime. But the way we do it is that interfaces and inheritance arent the only way, I tend to think in composition. We provide several compositional primitives that do not require a dynamic scheduler interface.
One of them is generics. We have runtime inheritance that looks a lot like what you have. Clr (Sui World Note: common language runtime, common language runtime) Let me give a very concrete example, otherwise this gets abstract very quickly.
Something like your ERC-20, which is obviously a fundamentally important encryption standard. If your platform, your language cant do that, then it wont be very useful. In a language like Move, you define a point of type called t, where t is a generic type parameter, and then implement functions for coin, for example a function for joining 2 points together. This applies to all coin types. Its not something someone wants to cover. You define splits.
When you want someone to customize the behavior of a token, use what is called the capability pattern, for example for a token, one of the things you might want to customize is what is the total supply, or more fundamentally what is its policy? You can express it like this: OK, so you have point structs of type t, and then have different instantiations of t, such as dollars, pounds, or some other currency type. For something you want to customize, you provide it at the capability level, creating a Token function. You say, this is the type parameter of my Token, and then it will give you something called capacity of treasury of funds. Then there are other logics to ensure that only those who hold the treasury capacity of t can mint and destroy Tokens of type t. You can take this treasury capacity, lock it in a different contract, and enforce a limit on the total supply. You can put it somewhere, say only comment on Tuesday, but not on Thursday. You invert the flow of control, which allows you to make arbitrary combinations. This is an example of a trick, but the trick works pretty much everywhere, and if you want the behavior to work a certain way, you need to hardcode it. This sounds bad, but you implement specific two methods, and then you define those capabilities for what you want to allow.
a16z Eddy Lazzarin：
Do you think capability is a constraint you can add to an interface that looks like a traditional programmer?
Sui CTO Sam Blackshear ：
Yes, I think most of these interface patterns can be morphed pretty straight forward. Its a bit harder to compile, but you could argue that its the equivalent capability model of what this interface is trying to do.
Host Sonal Chokshi:
By the way, Sam, do you find this satisfying? Feel free to disagree, a little conflict is a good thing.
Sui CTO Sam Blackshear ：
Im fine with that, because I think if you can have modules or structs with intrinsic capabilities that can be fed into modules that have very predefined behavior, you can end up with the exact same behavior, like modules can do that. A module accepts an abstract struct, that struct is defined in that module, and then there is an intrinsic capability inside that struct. This actually works really well, because you can get really nice permission style registries, and they kind of come out of here almost naturally, like whats called a DS-Off registry, right?
a16z Noah：
first level title
Object-Oriented and Asset-Oriented Programming
a16z Eddy Lazzarin：
So I might be a little bit ahead of the proverb, but are these capabilities visible to the type system? At what point in the program are these capabilities visible during static analysis of the program? If I write some instantiation-specific code in which there is a capability, will it be possible to detect early on that Im violating the capability, before I run it?
a16z Noah：
Yes, these capabilities are visible to the type system and are visible during the static analysis phase of the program. If I write code for a specific instantiated type with a capability, I can find out very early on if Im violating the capability without running it on a virtual machine.
Sui CTO Sam Blackshear ：
Let me answer the question briefly and then provide some background information, they are visible to the compiler and are part of the type system. This is a very important utilization point for us. But I want to talk a little bit about the structure in the Move mobility system, and how that gets involved in something like an audit-like level of capability. If thats not a distraction.
In Move, you have struct types and like structs in other languages, they can have fields, fields of primitive types, or other structs. Whats more interesting, and perhaps even more different, is that these structures have abilities. If youre familiar with Rust, capabilities are a bit like marking transactions. They declare the built-in operations you are allowed to perform on the struct.
Just as importantly, you cant do those things if you dont have the ability. A relatively simple ability is very important, that is, the ability to copy. If you have a Token type or something like a non-homogeneous Token, in the computer, it is just some bits, but you dont want to allow others to copy this thing at will.
In Move, if you dont declare your struct capable of copying, then you cant use our equivalent of man copy.
So things like integers and strings have copies. But if you dont want your type to have the ability to be copied, then you dont give it. And then there are other capabilities, like discarding, which is called the drop capability. Thats where the interesting linear type stuff comes in, if you want to drop something, like put it out of scope, or overwrite it, then you give it the drop ability. But if you dont give drop, the only way to get rid of it is to define whatever policies are expected by modules of that type.
Common language runtime (CLR) As a specific example, if you want to maintain a total supply for your Token, you do not give your Token the ability to drop. Then there is no way to get rid of it other than the burn function defined in the module where it is declared, which updates the total supply. These are all tricks you can use. There are also several storage-related capabilities, such as whether it can be stored in global storage, which I wont go into detail because they are not very relevant to this question. But basically, capabilities are baked into the audit program, and the audit program understands the type system and knows how to use the type system to solve problems. If I write a statement saying there is only one such thing, then the auditor can use this to prove this property. Thus, capabilities and type system guarantees go hand in hand.
a16z Noah：
When you mentioned drop, I wanted to talk about my favorite thing. Can you talk a little bit about what the hot potato mode is? If theres any other cool stuff like this, its one of my favorite weird things that came out of Move.
Sui CTO Sam Blackshear ：
This is indeed a strange thing. This is very closely related to competence. Usually in programming languages you dont have much control over when your value can be destroyed, maybe you have a destructor that says when your value will disappear. But sometimes the destructor guarantees are weak, or you cant simply say something like you cant delete my type. This might sound like an odd limitation, but its actually quite powerful, especially without dynamic dispatch.
Ill start with a hot potato example, and then we can drill down to things like flash loans. If you do flash loans on ethereum, its a standard, you can override it, basically you expose a callback function, like a flash loan contract, you give me money, my callback function and then get back the money sort of, and in Move, the way you do it is somebody goes to the flash loan contract and they say, “Hey, give me 53 bucks, but they also give you what they call a hot potato object.
A hot potato object is a struct, it has no capabilities. Its not copied, so you cant copy it. It doesnt have global storage capabilities, you cant stash it like you would put it in a contract. It also has no drop ability, so you cant drop it. Therefore, the only way to get rid of it is to pass it back to the flash loan contract. Let you pass back the code of its flash loan contract, forcing you to repay. If you dont, its programs will fail at runtime and wont even pass type checks. So this is the interesting ability to control the destruction of your values, as a programmer, can impose arbitrary invariants at any time as to when these objects can be destroyed. These look a lot like the API call pattern is very specific. Another very obvious example is if you want to force someone to call lock after calling unlock, but do whatever they want in between, you can do it this way too.
a16z Eddy Lazzarin：
When I first heard about the hot potato pattern, I thought about the interesting use of locks like mute texas, which take advantage of the type system for ergonomic purposes only, to enforce the use of specific objects The method is almost a requirement of business logic level. I think its very clever, it feels very modern, its a high-quality use of ergonomics in a programming language thats not even very common in traditional programming languages yet, but is obviously very useful in a smart contract environment Value, because there are more logical requirements here, considering the value and security that may be involved.
Sui CTO Sam Blackshear ：
Before we talk about any concrete examples, can you give a quick high-level overview of our object system? What are objects and who owns them? How do objects own other objects, and how do modules work with them?
a16z Noah：
Yes, exactly. This is about a dialect of the Move language, specifically Sui Move. The basis of this thing is a different structure of global storage than the global storage scheme of the original Move dialect that we used to use. The original Move global storage scheme is very similar to the corporate model used by Ethereum.
In Sui Move, we want to put the central point of things on objects, highly incentivized to be able to represent fine-grained access as precisely as possible. This helps you do a lot of things that we wont go into detail on this podcast, like processing transactions more efficiently, telling wallet users what transactions are going to do, etc.
So in Sui Move, the global storage structure is a mapping from object ID to object ID. Objects are then just Move structs with a capability called a key. It says, Hey, I can be a key. It can appear in the global object pool. Then each object must have a globally unique ID. You can then write entry point functions for your modules that can take objects directly as input. If you are writing a transaction, this WeRunTime will have the object ID. If youre writing a transaction, WeRunTime can use these IDs to resolve the IDs into objects and insert them into functions.
This object-oriented and asset-oriented programming experience is great. Its much more straightforward than what we did in the original Move version. You also mentioned parent and child objects and object hierarchies. This is very useful, but you still want to be able to represent things like large collections.
Say Im building a DNS-like registry and I want to have millions of entries. We have an object size limit, an object can be several megabytes, but no larger. But if you have something like DNS, it should be arbitrarily large. The way we represent it is using a parent-child object relationship, we basically have a way of viewing an object as a heterogeneous map. Then you can add keys with dynamic select fields. This is very similar to JavaScript in a way. We can say, this object has a map in it, and then I can put something in this map. Or you could say, when I define this object, it has ten fields, but I actually want to add a new field later, and Im going to upgrade my contract. I want to add a new field after the fact.
The way we represent it is with these parent and child object relationships, and each child object is associated with a key value, which can be any arbitrary Move value, like a string or u 64 , or whatever else you want.
a16z Noah：
Yes, related to the concept of parent objects, the thing that I think made it really my eureka moment was actually a few months ago when I took the time to dig into Sui Move and went from writing a program with only one object to To re-implement most of the Uniswap V2-style card combinations. A little project I did really made me realize how valuable it is to have objects of objects. This project has only three objects, the lock, the gold, and an empty barrier. There is a very basic module that you can imagine creating gold owned by a key object. Then the only way to get the gold out is to have a function that takes the lock and the key, and obviously destroys the lock, gives you the gold, and then destroys your key. This approach is very interesting, in this way, you can describe the relationship between objects, and describe permissions in a very fine-grained way.
Sui CTO Sam Blackshear ：
first level title
Security comparison of Move and Solidity
Host Sonal Chokshi:
By the way, before I came to Wired magazine, I spent 6 days in Xerox Park, which reminded me a little about the history of object-oriented programming. What you just said is super interesting, because they invented Smalltalk, an early precursor to many of todays object-oriented frameworks. Anyway, is there any other topic you want to discuss?
a16z Noah：
I just have a general question, but really, are there any hacks and such that happen in the EVM world that you think would not happen the first time if you were using Move because of the type system.
Sui CTO Sam Blackshear ：
In the EVM world, weve already mentioned dynamic allocation and reentrancy, Move eliminates reentrancy by construct, any reentrancy related problems go away, and I think people are doing a good job. Now, I think it avoids react and view.
a16z Eddy Lazzarin：
But can you explain why Move makes these problems impossible?
Sui CTO Sam Blackshear ：
re-entry, right? what happened? You write some code and call a certain function. The problem is that someone provides an implementation of a function that you didnt expect in the first place. For this to work, function calls must be dynamic. It has to call code, which is basically a function pointer provided by the caller, possibly the attacker. If you dont have any dynamic function calls, if you always know the target of a function call, then this cant happen at all, like anything you call, you may not know what the code does, but you know what it is , you can test it, you can verify it, everything is there. So basically, its impossible for others to provide code that makes your module behave differently than you expected, because its just a static function call. so cool.
a16z Eddy Lazzarin：
Thus, this eliminates reentrancy attacks, which have been an eternal problem in Solidity development.
Sui CTO Sam Blackshear ：
Yes, I think Move basically eliminates the problem of missing permission checks in smart contract programming. There are times when you write some code where you need to pass all the accounts explicitly, and you have to say, do I have permission to do this. You wrote a simple code, but forgot to check if the sender is someone, or if the person can access it. I think these problems happen quite often.
So in Move, object ownership information is actually stored in object metadata. This is not something the programmer can control.
When you look at these objects, they say, Im owned by this address, or Im owned by this other object, or Im a shared object, or Im an immutable object. The programmer cant forget to check its owner, because the runtime will check before executing the code passed in this Sui object. Runtime says, I see this exchange, I see all the objects they want to use. Im checking to see if they actually own these objects, or they have an object that intermediate owns them so they have permission to use they.
Many of the permission checks we ask our programmers to do end up happening in We Run Time, and those checks are impossible to forget. I think this is very important, because the hardest thing to protect is the specification that the programmer didnt tell you. These norms are easy to forget, and hard to catch using static analysis or other methods, because you always need someone to figure out which norms are important.
Host Sonal Chokshi:
And by the way, I think its going to be very interesting what happens at enterprise scale when people collaborate more in this way in terms of long-term or near-term planning because its obviously distributed and not just A company, sometimes people collaborate. But I mean, when you think about the old ways now, you have like developers and all these best practice
