Episode 227 - Move & Sui with Sam Blackshear from Mysten Labs

Transcript

[Music] welcome to xero knowledge i'm your host anna rose in this podcast we will be exploring the latest in zero knowledge research and the decentralized web as well as new paradigms that promise to change the way we interact and transact online this week i chat with sam blackshear co-founder and cto of mistin sam has a background in programming language research and is the author of the move language a programming language that can be used to implement custom transactions and smart contracts we chat about their concept of

programmable objects and what this makes possible we also cover sui a generalized l1 with a new asset centric data model for parallel transaction commits being developed by mistin before we kick off i want to highlight the zk jobs board for you if you're looking to jump into zk professionally i want to remind you to head over there you will find job posts from some of the top teams working in zk teams like elio anoma and mina find the next project or team you want to join now since we always have so many things to mention in this little intro block you should also check out the link tree we've put together there you can see all of the channels that we have so if you want to jump into zk this is probably a good place to start now i want to invite tanya the podcast producer to tell us a

little bit about this week's sponsor today's episode is sponsored by polygon maiden polygon midan is a layer two scaling solution for ethereum maiden relies on zk starks to roll up thousands of layer 2 transactions into a single ethereum transaction which increases throughput and reduces fees at the heart of polygon maiden is made in vm a touring complete stark-based virtual machine which provides a level of safety and the support of advanced features not currently available on ethereum visit polygon.technology to learn more about polygon miden and other polygon solutions so thank you again polygon midan now here is anna's interview with mistin labs [Music] today i'm chatting with sam blackshear

the co-founder and cto at mistin welcome to the show sam anna thanks so much for having me i'm really excited to be here a big fan of the show and excited to be on it for the first time and to be the first guest from miston yeah um miston maybe we should start a little bit with that this is the first time that yeah i'm exploring this project it was some somewhat stealthy for a while i feel and i want to hear yeah tell me what miston is yeah absolutely so mist and labs is a startup in the crypto space we officially started in november of last year our mission is creating a foundational infrastructure for crypto and you know what what does that mean i think it's actually easier to start by talking about the origin story we've missed and

then you'll understand like what we're doing and uh you know why we are where we are today so myself and all my co-founders uh we're all part of the novi research team which was a subdivision of facebook or meta that worked on libra and worked on move and so for many years we were there from the beginning of the project and we had built a lot of the court like done the research and development and a lot of the implementation for much of the core tech behind libra so we created and developed a move uh we did a lot of work on the consensus protocol on the parallel execution bits and this was an amazing experience being at facebook and working on this stuff uh you know we really got to take a very blue sky look at blockchain tech and figure out like what's generally new

here and where's what are cases where the fundamental computer science things that you can bring in uh and their insights from elsewhere that makes sense and you know where cases were this is like some generally new thing where there's new problems to solve and so we we worked on all this stuff for a number of years and you know i think built some really cool things but you know as i'm sure the audience of this show knows like a libra at dm or uh there are many renamings never ended up launching for reasons that weren't related to the core tech so there were both things that we worked on there that and libra is sort of old tech like it was designed in 2019 and you know there's a lot of things that have changed in the crypto space since then we really understand some things a lot better and you know

would do things differently so it was both wanting to take some things that we'd built a facebook that never saw the light of day like move and to take those out into the crypto space where they're really needed and take some next-gen ideas for like what can we do beyond libra like you know we there's some things about the labor design that are good but really with like if you want to design a scalable blockchain from scratch like there are a lot of things we'd want to do differently and that was never going to happen inside of facebook so this was the genesis of mystin is to take some of those ideas out there and the problem that we're focused on solving or problems is really just looking at the crypto space as a whole and just seeing that there are amazing amazing things that have been done but

there are also giant gaps uh in terms of problems that need to be solved for for enterprise and consumer grade adoption and so like we don't think of this as a problem that's all by one blockchain or one network but by something that needs to be solved by a lot of improvements throughout the entire stack that are between users and crypto so of course like you need a fast layer one blockchain with low fees and with high throughput you need a better smart contract programming language like better that's more accessible to mainstream developers you need key management to be less high stakes and more of like you don't worry so much about losing your password and losing uh your life savings you know it needs to be more of that kind of experience all of these sorts of things i think and more uh are problems that

need to be solved to get to consumer enterprise great adoption of crypto and so like misston is focused on it's sort of a meta company where the first thing we're doing is we launching this network but in the longer term we plan to launch many networks many sas companies many spin-offs to address all of these different big problems that we think need to be solved to get some broader adoption of crypto what were you doing before facebook what's your pre-blockchain story yes so i trained as a programming language theorist uh i was doing a phd at the university of colorado boulder working on scalable static analysis tools so my phd thesis was on a goal-directed static analysis where you have a particular problem that you you have a

particular kind of bug that you're looking for and you want to you want an analysis that can automatically identify that in other programs and i went straight from my phd to facebook and worked on static analysis for many years and so i looked things like finding null dereferences finding um array index out of bounds errors uh some stuff on c plus plus memory safety and enjoy enjoy this work a lot it's really really fun it's like a you get to design these little languages that are tailored toward finding these particular kinds of bugs or properties that folks care about and at facebook we got to do this we had to make it run really fast so it would go in ci uh so it could you know happen in 15 minutes even though you're analyzing tens of millions of lines of code

and i worked on this for about three years and loved it but also like you develop a lot of opinions about language design when you spend all day uh trying to patch basically design flaws in existing languages or existing frameworks like what you're doing there is basically trying to accommodate the the usage of something that already has a large amount of code written in it uh but then of course like you have opinions about like if i were doing things from scratch either from a language design perspective or from a framework perspective like how would it do that differently and then sort of at the same time like these deep questions about what what makes it hard or easy to reason about a program and especially like with different programs that compose because that's where a lot of bugs come from uh and if you're starting

over and doing these things from scratch like how how would you do it differently and so that was my background like both leading up to facebook and leading up to crypto uh i was like having these thoughts and then libra started up and they needed someone to look after the smart contracts part of it uh and uh i was like this seems like a great way to put some of these ideas about blue sky language design uh to work and then also in a space where correctness which is what the static analysis stuff is all about is super super important and folks are willing to invest in it because the stakes of getting things wrong are very high hmm in facebook this group the libra group was it connected to the general cryptography group basically the question is did you meet bobbin from winterfell through your work on libra or

is that in a totally different department i did meet bobin from libra uh okay we i did meet bobbin through the work on libra there actually isn't or wasn't a general cryptography group at facebook which is interesting there are several cryptographers at facebook but they tend to be integrated into particular teams rather than having like the general cryptography consulting team i think that may be changing uh but yes i did meet bobbin through that and get to work with him he's fantastic cool i mean that's the only other person i've had on the show and that knows anything from the inside leaving facebook and moving off on your own were you i mean it sounds like you had been at facebook for quite a while at that point like and that was your first gig so yeah was it hard to leave it had been yeah i guess it had been a

while for me it had been a five or almost six years you know it really wasn't because i was just so excited to get the chance to work with my co-founders who are basically my favorite folks of the many very very strong and impressive folks that i worked with at libra and dm and just because like the work of that we had started with move uh felt unfinished and i was this felt like the way to give it a second life and to really like get it out there and then i was also incredibly excited about some of the new ideas that uh we've since been working on in sui uh and just to get those out there and see what folks saw them to see how they would work so it was the big decisions are always easy for me uh the smaller ones

deciding what to eat for what to eat for lunch so this one uh yeah it wasn't uh it wasn't too difficult of a choice i thought oh funny and your crew is not the only team to have left or to have spun out from there i just recently heard about like two other projects and maybe they're related to what you're doing like aptos and zeph yeah so there's uh we can call ourselves the libra mafia i think there there's a number of folks coming out of there that have gone on to do different things so yes you mentioned zeff and aptos and then of course like you have folks at 860 riyaz and nas were like very talented folks working in custody at facebook who are now at a16z uh there's a guy frederick who may not know who's also doing a crypto startup uh

there's dalia malki who we also worked with at facebook who's now uh the chief scientist at chain link and you know kristen catellini uh who's also who is the chief economist there who also worked with them so i think the although this project unwind i think a lot of the ideas and folks are now like making their way into the broader crypto space and uh i think hopefully you'll be hearing from a lot of them going forward is the project done internally or like what do you know what's happened to it yeah facebook announced that uh they were no longer working on the project i think the libra association also announced that it was dissolving wow so it is done it's done man i remember like a few years ago on the show at like one of our new year's episodes or something we're definitely

like it was like the boogeyman a little bit when people were scared but it's kind of uh it ends with a little not with a bang i don't know a bit of a shame it's a bit of a shame i mean the folks always announce the good parts very loudly and the the other things less loudly but you know i've i feel that the project like really well there's the the technical things that it produced which i'm very excited about but i think it also made a lot of folks take cbdc's more seriously in advance discussions that might otherwise have happened over a series of many years or decades and you know even though that wasn't what succeeded it hopefully laid their groundwork from some important things that will that will come later so i i feel good about that part of it uh anyway

well let's dive into some of the pieces that you are bringing with you i kind of want to start with the move language because that's obviously something very dear to your heart tell us what is move yes move is very dear to me so move is a language for programming with scarcity that's the way i would explain it at the very highest level where in a conventional programming language right like everything under the hood is just bytes that have no inherent scarcity when you say something like let x equals y like what you're really saying is copy the value stored in y and put it into x but when you're programming with money or assets or anything that needs some inherent scarcity like that that model isn't going to be appropriate you don't want to be able to copy coins or or

money or anything along these lines like you need the language to have some way for talking about scarcity and objects that exhibited and so the genesis of move was this is way back in 2019 but looking at solidity and the evm the other smart contracts out there today and just thinking like this is a bit strange like when i look at these when i look at the kinds of programs folks are trying to write they're all about assets uh it's about encoding the structure of assets it's about logic for transferring them but there's no vocabulary in the language for talking about assets uh the data model is very strange it's um you have a big hash table where the keys are addresses and the address values are basically the entries in that hash table you know if it's a for coins that's an integer and

for an nft maybe it's um you know some things about the structure of the nft but there's no there's no type or value that represents an asset and so you can't do something like return an asset from a function or store an asset in a data structure or pass an asset as an input to a to a function you can't even have an asset leave the contract where it's created and so to me this just seemed like it's not going to be the right language for expressing this sort of stuff and this isn't just an ergonomic thing it leads to safety issues as well because it's really hard to talk about something like an atomic transfer when that requires touching one entry on a table and then touching another entry in the table and then making sure that something doesn't happen in between like this is how the dow hack happened for

example and so the purpose of move was really if you had a language that's centered around the idea of being able to program with scarcity providing a structured representation of assets and having that be safe what would that look like and that's there's a lot of other things that move is doing but i think that's really the core and what makes it different from other smart contract languages and general purpose languages did you look at other smart contract languages though past solidity like are there any that maybe even like influenced a little bit move yeah so at the time and this was 2019 the solidity in the evm was definitely the largest one and so we looked at other general purpose languages and other smart contract languages there were some research smart contract languages that

influenced the ideas also there's one called flint that was sort of trying to take java and add a little bit of this notion of asset like types on top of it as well so like that was certainly something that was an influence on move and then in mainstream languages there's of course rust which a lot of folks use in the blockchain space it has this notion of move semantics or substructural types in pl lingo where you have restrictions on when i move this value you know i know from in the caller context i no longer into the callee then i no longer have it and i can't touch it again and like this is very related to some things that move does in terms of the way it represents assets and then um that idea in turn comes from c plus plus or like there are

other languages too uh mainstream languages that have this idea of substructural types usually to represent memory which is also something that has to have scarcity properties but then using it to represent assets was uh something that was new and move like if the goal here is to bring more developers in though like wouldn't you want to use an existing something like javascript which is very very popular because it sounds like you didn't take that route it's not you're not doing javascript plus you're doing something else why yeah why did you decide not to sort of piggyback on existing popular things yeah so this is a great question like you always want to i think if you can piggyback on existing popular things you always want to like language communities language tooling having existing

developer bases are much more important than language design yeah all of these things so i think this is a question we asked ourselves early on and this answer's gonna be a bit long but i hope it will be interesting and that there are these properties that i like to call the table stakes properties of a smart contract language that if your language doesn't have these things then it can it can't even satisfy the basic requirements of doing this so one thing is that the language has to be deterministic right like all of these smart contracts are running the context of you're running some byzantine fault or replication system uh if you have non-deterministic semantics uh even if validators are great and everything else they may get different answers and then uh you aren't going to accomplish the goal this whole thing which is you know

advancing the state of the system in a predictable way another thing is this metering concept right like in smart contracts we talk about gas or metering or all this stuff conventional languages including javascript don't have this uh and so right you need to have this of course in the blockchain context because you don't want someone to send a transaction with infinite loop install the entire system or you know even less extremely just something that occupies a an extreme amount of time or more resources than it can pay for and then the final thing which i kind of already touched on is this notion of assets or scarcity where in a normal language like right you're in javascript you have objects like you know you can copy objects and you know you don't have to have something like move semantics uh you know it's just not

intended for this setting where you're programming with assets but you really need that here and the way to enforce that is that you have type safety protections that are enforced not at the source language level like if you're writing your java or your rest code and the source compiler is telling you when you're doing something wrong but actually at the at the executable level at the by code level in moves case where even if somebody wants to skip the source compiler and write code directly in the bytecode language you have to make sure that the properties you care about from a type safety and from an asset safety perspective hold there as well and so these are these three table stakes properties that you need to have to play as a smart contract language and mainstream languages don't have any of them now of course like

you can try to address this by i'll take javascript and i'll add metering on top of it and you know all like restrict it to get rid of the non-determinism and maybe like all add some libraries for asset types but anytime you do this you're basically taking something that's already very complicated and then you're adding restrictions that's going to stop you from using some of the existing libraries that exist in that language or stop you from using the the tooling that's available and then you're adding something else like say metering that the this existing stuff may not be compatible with so we looked into doing this like we looked at doing this extend and restrict game for wasm for the jvm even for skylark this sort of build language that you use uh for python and then for javascript as well and we just concluded that

especially in the setting where you care so much about correctness and you care so much about safety simplicity is really the essence so it makes way more sense to start from scratch with something that has exactly the properties you want than trying to take something and you know play these games to shape it into what you want and then it's going to be a challenge to build a developer ecosystem around that but if you've really built the right tool for the job then this is something that you'll be able to do in the long term interesting it's sort of a bit of a throwback for me out like a few months ago a month ago i had dean from agora come on they did something like they they also have this language of heart and js right so it's javascript but like made more compatible to

blockchain are you familiar with it yeah i'm familiar with the gorick and uh i've spoken to those guys a bit and i i think what they're doing is very interesting as well cool but you decided to go a different route after evaluation we decided to go a different route i mean i think with heart and js the thing is you'll run into this issue that i was just describing where not there are many many tens of millions of lines of javascript code out there and many and there are you know many javascript programs and tooling developers but a lot of these things are not hard in js and these things are not js that has these agorax specific libraries uh you know this is these things just aren't directly applicable and i think like really that's an approach worth pursuing as well but i think

taking something that's already complicated and trying to build a dialect of it that's specific to blockchain is just going to lead to a result that is more complex than starting from something simple you sort of mentioned the testing or like the verification is happening at a different point like would you still need to do testing like tools to test oh yes nothing frees us from the need to test so yeah let me talk about that and move a little bit so there's a few different levels of things going on one are the protections you get from the type system uh so that of course happens at the source level but then there's a component called the bytecode verifier this is similar to technology that's in the jvm or clr where when the bicode gets loaded from disks there's some or on the blockchain in this case there's some set of checks

that run that enforce basic things like type safety uh in our case that also enforce asset safety and so these are very cheap and lightweight checks that more or less make sure that whatever the source compiler is doing that also happens for bytecode that uh for some reason didn't go through the source compiler then of course you have testing and so in move we have built-in unit testing that you can write uh directly in move and then the most interesting and important thing is that we have this thing called the move prover um this is a formal verification tool that we've co-developed alongside the language there's still folks at meta that are working on this move prover tool although we have some that missed it as well so what you do with this thing is that you can write formal specifications you can say something like

there will only ever be 100 of 100 objects of this type in the world and then the approver can show that for all possible sequences of calls for all possible transactions uh this property will continue to hold and so you can write all the things that matter for your particular use case as specifications and then the approver does a bunch of very fancy math very much like the stuff i used to do before joining libra to show that this happens and so this is something that's quite different from move than for other languages like there's a little bit of work on solidity verification but the things like reentrancy in the language and dynamic dispatch make this hard whereas move was specifically designed with the ability to enable simple and scalable formal verification in mind and then we've also

built the tooling to match with this and so this is something like for javascript javascript is one of the hardest languages to reason about from a static analysis and verification perspective it's so so dynamic like you add new properties at runtime you add new methods at runtime and you can do things like using a subset that tries to restrict these things but then you're going to have to build tools that specifically understand this subset instead of a general javascript how many people built move how many people work on that yeah so it's quite a few um i think at one point there are probably at least 15 folks at meta working on it and there are more now some of those folks are still at meta we have lots of folks uh maybe like five or six working on move at mistim and then of course

move is a cross-platform language it's not a specific to one blockchain so aptos is using moves that they have folks that are looking at it uh there's this zero elephant labor project that's a fork of libra similar to aptos that's also using move they have some folks working on it there's a project called star coin in china that's also proof of work blockchain using move that have a bunch of folks work on the core language so worldwide there's maybe like i would say like 20 or 30 people working on it and this is working on like the core um the developers building on top of course there are probably a bit more i would say that's about the number and then at facebook i'm not sure if i know their team size thing i should their team size numbers i shouldn't talk about it but

there's there's still folks that are working on both movie and the approver i just realized that i just kept calling facebook facebook i should have been calling it meta whoops i couldn't adjust either to be honest i i left just before it happened and it was facebook for so many years but it's still facebook to me it's an open source project right like could there be external contributors or were you kind of careful with like who could add to it there can be external contributors in r it's very much like any other open source project especially one that's security critical where you accept pull requests from anyone you accept issues from anyone but you want to keep the set of folks who are allowed to press the accept button small and then make sure that you get things carefully reviewed just to make sure that no one is introducing

vulnerabilities or backdoors or any of these other things you have to worry about in a blockchain project or a high security project are languages also these like are they something where with a lot of use you kind of find all the edge cases i guess the question here is a little bit like since it's kind of new is it as battle tested as something like solidity there are two things to worry about with the language i think one is about the design and validating the design of it and this is something that you can do without so-called battle testing like you write the formal semantics down with pencil and paper and you know this is the part that i really love doing uh training as a programming language theorist you write down exactly what the semantics of each instruction are you write down what the key properties you

want to ensure it's like for us like that's the these are things like type safety but then also things like what we call resource safety like if i have this type then i know it can never be copied except by this privileged copy instruction or i know that when i move this type between procedures that it exists in exactly one place or i know that if this thing doesn't have the drop attribute it can only be destroyed by a privileged instructor and not just sort of accidentally left on the floor so you can write these things down on pencil and paper and prove that the language semantics satisfies them and so that part you can feel very very confident and as confident as you can feel about anything in the world then there's actually making sure that the implementation respects those properties so that that's something where the

battle testing becomes quite relevant where you both um right of course you test the language very extensively and you do things but you do unit testing you do fuzzing you have lots of example programs and so that's something that of course we've done as we're building up move but then you have to be very very careful about the edge cases to make sure you conform to the specification everywhere and that's something that can only happen with time how long do you think it takes a language to to be battle tested how much volume maybe it's not time it's more like yeah edge case is tested somehow in in the wild i think as long as the language is still evolving the job is never done and you know languages must evolve like you're always adding new features or deciding that something

you've done in the past needs to be shifted i don't think there's any specific period of time where you start to feel confident about that or where you can be fully confident about that especially as something is evolving cool so what is sui so sui is a smart contracts platform and it's a smart contract platform that's specifically designed to be extremely high throughput and extremely low latency and then also to be horizontally scalable to handle the increase in demand and throughput over time when you say horizontal do you mean sharding because i heard that you are not doing sharding so tell me what what horizontal means in this context yes this is a great question so by horizontal we just mean that you add

more machines and you get more throughput without degrading other key metrics like latency or other things you might care about or at least not doing so specifically so starting right like um sharding is a technique that can you can talk about starting computation you can talk about starting state and then you can also and this is a blockchain thing talk about sharding as part of the protocol uh where everyone you know you go and look at the protocol spec and it talks about charity and how it works or you can talk about starting what we like to call inter-validator sharing as an implementation strategy that you don't need to be aware of at the validator level so in sui and in contrast to say what eth2 or serenity i think is the name of this project now is doing or what near is doing we do not have sharding at the

protocol level but we do have starting of course like the only way to scale beyond like what a single machine can do is to have some form of sharding and so what we do instead is intra validator sharding where a validator could consist of a single machine or it could consist of multiple machines that where some of the computation happens and each one or the storage is spread out among each one but different validators need not be aware of how other validators are started and there doesn't need to be a protocol level or community decision to decide how sharing could work it's just more much more of a conventional computer science problem where okay if you're facebook or google or anyone like you have the starting inside your data centers but as a customer of the system you don't need to be aware that they're starting happening

or how it works uh and you have the flexibility to change this very dynamically as well so it's the smart contract platform is it a vm it has the movement side but it is not itself a vm i see so it's the move vm in sui exactly okay and what does swede stand for so it it's not an acronym uh it's the origin of the name is that uh it's the japanese for water and so you know it's like there's a connection to liquidity or things that are free-flowing or an essential resource that you must have and then also like it's it's very nice and short and and easy to say it's very hard to find names that are not already taken up by other currencies and networks in the

blockchain space today so we're lucky to happen upon this one i'm gonna ask a bit of a dumb question here though you just said it's the move vm but like we don't call it the solidity vm what is this a naming choice or is it built differently yes a good question move is both the name of the source language and the virtual machine whereas uh you have the ethereum virtual machine machine and the solidity source language uh you could in principle have other source languages removed but we call it the the move virtual machine and we very intentionally call it that instead of the libra virtual machine or the ethereum one because this is a cross-platform thing it works for everywhere that you have move like if you go and look at star coin or zero l they're also using the move virtual machine uh not some specific version is

that something that like the language provides out of the box or is this a separate library this is something that the language provides out of the box the design of the language and how it's able to be cross-platform is that things like the account structure and the transaction structure and the cryptography and the consensus that the network uses those aren't hard-coded into language like they are say in the evm like in the evm you say something like you know you can look at the hash of the current block which you know implies that there is a notion of blocks and they have a hash and here's how it's computed or like an account structure in a move none of those things live in the vm or in the core language what you do is you take the vm which is only knows about things like it knows

about structs uh it knows about integers it does know about addresses and then it's the job of a particular platform like sui or like zero l to add this thing that we called an adapter where they say hey i'm a platform uh i'm gonna here's my notion of accounts if i have that here's a cryptography i'm gonna use here's a consensus and then your move lets you do whatever you want uh underneath that but you can make those decisions and you can have platforms that look very different at the top level they're using the same move under the hood i kind of want to understand how this lives as a blockchain like is it like the account model is it a utxo or is it something else yeah like let's let's talk about sweet specifically here yeah let's talk about sweet specifically yeah so move doesn't

enforce anything but i'll talk about how it works for sui where sui is a little bit of a hybrid between a utxo and account model the global state of sui is a pool of objects so objects or move values might be something like an nft it might be something like a fungible token something like a dex uh that's an object as well and the there's this pool of objects all of them have a global unique id and when you have a transaction it needs to declare the objects that it's going to operate on if i'm going to transfer an nft the transaction says i'm going to touch this object with this id and then that's what the transaction looks like if you're going to make a trade and a dex you would say this transaction takes the id of the decks it's going to make a trade with and the

id of the object that corresponds to the coin and then that's what it would do so that's that's the data model of swiss there are objects uh you pass objects into transactions the transaction also is a pointer to a code object which is a move smart contract and then it tells you what it's going to do with the the data objects you've passed in but what is actually written to chain then we're still talking about blockchains so like what's being put in like sorry i know i must sound kind of silly but it's like there's always something to do with like the account the transaction something that like inevitably is being you know written to the ledger so yeah what is it in this case here it's the object or objects the transaction it declares the objects it's going to

mutate it might also create some new objects or it might also transfer an object and maybe that's a helpful thing to explain to see how it works here because that's where something like account will come in here there's a notion of address like right a transaction does have a sender address and of course there's a signature check that makes sure that some signature corresponds to that address but then part of the object metadata is who owns the object and so there's a rule that says if i own this object i'm the only one who can send a transaction that's touching it and then the way a transfer works is that you just mutate that owner metadata to be someone else's address can you do stuff to these objects can you affect them yes whatever code you can write and move you can do that thing

to that object so this includes the basics like mutating the object's fields uh destroying it creating new objects um doing some action that you can only do if you have some particular combination of objects putting objects inside of each other like if you want to have composable nfts uh any of these sorts of things that you can do so usually when you talk about like destroying something i always think of like sending it to a burn wallet right a burn address it's just like you send it to nothing no one can ever use it again but in your case if you were to destroy something is it really destroyed it is really destroyed so the the state of sweet right it says pool of objects this pool begins empty or not exactly empty it begins with some pool of genesis objects and then over time objects will be added

to that pool they'll be removed from that pool or they'll persist in there the way i think i think really the helpful way to think about it is that you have this pool of objects you have a transaction it temporarily removes a lot of objects from this pool and then at that point the transaction owns the objects and so it might mutate them and then it might destroy them and then what destroying it means is that it doesn't actually go back in the pool you know it just disappears forever and then if it does a mutation it's conceptually it's taken ownership of it it's mutated a little bit and now it goes back into the pool at the end it's proof of stake right that's right in this model do the validators do anything different or are they just kind of acting like validators as we've known

them so they don't need to do anything different but there's something that having this object-centric data model enables us to do and let me describe what that is so backing up for a second if you think about the way other blockchains work there's always this step of you have a bunch of transactions you order them and then you execute them and some folks are clever about trying to discover parallelism in these transactions and execute them parallel but there's always this constraint of first you order transactions and then you do other things and so in swede the thing we're doing that's interesting is that we observe there are some classes of computations that do not require ordering uh so for example if i'm gonna send you a token and someone else is gonna send someone else a token those transactions don't have to be ordered with respect to each

other uh they can be executed in parallel but they can also even be committed in parallel without going through full consensus and so in swede this is this is what we do when you have transactions that touch distinct objects we don't order them with respect to each other and then we can both execute them in parallel and commit them in parallel which really reduces the latency compared to going through full ordering uh and then for use cases that do require full ordering like say if you have a dex uh this is this inherently requires ordering right like you and i are hitting the decks at the same time we have to determine who gets what price we have a scheme there where there's a notion of instead of objects having a single owner address they can be shared and so if you have a transaction that's

touching a shared object it goes through full consensus it gets sequenced and then executed just like normal but if you have these transactions that don't need to be that don't require ordering then we can use byzantine consistent broadcast to commit them in parallel instead of going through full consensus does it mean it gets committed later like you assume that it's okay and then it will be committed at some point or does it never really hit the blockchain at all so it gets committed earlier uh it's just that if so right this is a proof of stake system where you know you have to have some you have to have i'll say for simplicity two of plus one validator sign off on a given transaction so if you're not one of the validators who signed off on this particular the byzantine system broadcast transaction then the other

ones outside of that set may not know about it immediately but as soon as a client sees signatures from two of plus one validators on that transaction it has been committed and then those validators know about it they know about it and for anyone else who doesn't know about it you can show them we call this the certificate the transaction that carries those two plus one signatures and then they can then use that object in a subsequent transaction or provide as proof of payment or any other things that you would like to do in a normal setting i know i think you just explained this but now i'm like because i thought what you were saying was more like there were some less important transactions that you just sort of like let float around and eventually got in but what you're saying is different can you actually

walk me through this again and sorry to the listeners if you got it the first time but i didn't so these transactions i wouldn't describe as less important but there you need less computational power to deal with them or less agreement power let's call it what would be an example would this be like connecting an nft to another nft like making them composable or is that very i think a basic token transfer is the simplest one where and i think for folks familiar with utxos like this is somewhat this is like fairly easy to think about like if you have a single balance and i'm trying to send in a non-utxo model if i have a single balance and i'm trying to send out going transactions to lots of folks at once there's a potential conflict because my my balance may go below zero but if i instead

take that balance and i split it into a bunch of independent utxos then i can do a bunch of those things in parallel so basically what we have is everything is split not into utxos but into objects and in these transactions that touch distinct objects you can commit them in parallel without full consensus because there's no reason there's no need to do that ordering uh whereas in something like a dex or an auction uh you do need that ordering you need the ordering but like where does the data go like you're saying it's happening in parallel but are they then like hashed into one thing that then gets put into the blockchain or not like this is the part where i'm kind of confused what happens to it after you've parallelized it it's happening at the same time they don't all know each other

they don't know what each other is doing so at what point does that become like the global state because of these transactions that don't go through full ordering at any given point in time the validators may not agree on the set of transactions that have been committed they will eventually agree and the set of validators have signed off on a particular transaction agree on that transaction but it's a much more asynchronous kind of setup than you'd see in a blockchain where you have a total order and you have blocks that are coming out now of course in suite we do also have blocks and you know we have them for the transactions that require ordering in addition to that we do state checkpoints that are asynchronous and so they're like every now and then either at apoc boundaries or perhaps more frequently you have a list of all the transactions

that happened and then you'll after the fact build some canonical ordering among them but you didn't have to build that ordering to commit the transactions because the ordering isn't going to change their effect that's sort of the key thing here you're doing almost like in every epoch you're doing some sort of lock in like now this is where it lives would you call this a dag what is it decentralized a cyclical graph oh god the d is wrong right what was the directed acyclic graph directed yeah yeah yeah that's exactly what it is so right these transactions that don't go through full consensus they're not unordered they're causally ordered they're only ordered with respect to transactions that have happened beforehand or transactions that are conceptually related and so you can think of the state of the world instead

of being the set of sequential blocks there's a dag where you start with objects in genesis and then you have the edges or transactions that take those objects is input and do something else and then you know you build that out and then occasionally these things join together when two objects are previously unrelated go into the same transaction and then become separate that's how you should think of this the history of sweet but then i think the confusion i was causing is that i was talking about the state at a point in time which is this global object pool and then what you're pointing out is that the validators do not necessarily agree on the object pool at any given point in time which is true okay how are validators being chosen in this consensus actually is this like is it like the 66 percent must

be doing something like yeah i'm just curious like how how is this working what we do here is very conventional where it's a proof of stake system uh you know you have you have stake and then you have validators that can vote their votes are weighted by the amount of stake that they have and then in order for a transaction to be committed whether it's in this uh fast track mode where you commit things extinctively without going through consensus or going through full consensus you have to get two f plus one of the weighted stake vote to get your transaction committed like there was another project that i believe came out of a similar group which was like hot stuff does it have any relation to that so hot stuff is a consensus algorithm and one that was used in dm or at least like a variant of

it was used in dm in what we're doing with sui i haven't even talked about the i'm saying we have consensus for these shared objects but haven't mentioned which consensus there you can use anything you could use hot stuff you could use tendermint you could use narwhal tusca which is uh i wish my co-founder george was here to talk about this so we'll probably what we're going to use in suia this next-gen consensus that can do that separates the the notion of the mempool from the notion of actually ordering things and then it gets a lot of speed ups related to that but so there's no direct relationship with hot stuff to answer your concrete question got it now let's bring it back to move because now that we have some sense of sweet like how do these things work together why kind of going back to that initial

thing that i'd sort of hinted at like does sweet allow move to act differently or does actually move allow sui to actually i think it's the first right this i think it's the latter movement definitely so this data model is describing where you have these structured objects and they go into transactions there needs to be you need to have a data model that can encode that it's like thinking about ethereum like the data model is contract centric where there's no notion of an object uh or an asset right like you have a hash map and then the object is some entry in there so if you wanted to say in in ether for example i have a transaction that's going to be touching these three different nfts the way to express that is that you

provide the address of those three contracts and then you maybe provide indexes into the hashmap like there's no vocabulary for saying that sort of thing or for saying take this nft and bring it out of the contract in it and into somewhere else like all you can do is switch the owner or things like that and so in move we have a notion of structured objects that can flow across contract boundaries like i can take my object type and make it a field of another object type and then it's not just that i write it that way in the source code it actually looks that way in the data model it's moved and enables this object-centric data model if we want to do this with the with the evm or with any other kind of language that doesn't allow you to pass structured bytes across trust boundaries

then you wouldn't be able to to express the things that we're doing in swede does the language actually offer this ability to parallelize somewhere in it as well because you mentioned it in the context of sui having the sort of like multiple non-confirmed things happening at the same time different validators seeing it but yeah does the language take advantage of that so this happens in the layer above the language the language provides the data model that lets the layer above do that but the movie m is the movie m is single threaded and you know usually does short running computations as smart contracts are maybe eventually it'll uh it'll run things in parallel once we have smart contracts doing machine learning or other fancy stuff but for now i think we get a lot more leverage by having the vm be single

threaded and be optimized for these short computations and putting all of the parallelism and high performance stuff in the layer above that just uses the vm as a subroutine when you say going above the language do you mean like the smart contracts being deployed on the vm yes so when i say above the language i mean the system that is invoking the vm like the validator software that is going to ingest some transactions and then decide like how am i going to schedule these which of these am i going to well in our case we run all of them in parallel but which of these am i going to run in parallel and then how do i organize the the structure of the computation inside the valley that's what i mean by the layer above not by the smart contracts the smart contract program model is this

very much the same in terms of you write your code you just have this nice abstraction where the entire world is yours and you can you can touch whatever you want you can call whatever you want and then it's the job of the validator software the runtime whatever you'd like to call it to take that in and figure out can i commit this in parallel does this need to go through consensus uh what object ids do i need to specify dependencies and all these sorts of things cool a colleague of mine at the xero knowledge validator philip encouraged me to ask a little bit about a new transaction payment protocol tell me about is this fast pay is that this part so right i think he's probably asking about the byzantine system broadcasting which does come from

let me explain fast pay and uh okay okay so uh at facebook jor uh my co-founder george as well as a alberto who works at mistin and a number of other folks were tasked with this problem of okay we want to have a really high throughput payment system and we only care about doing payments like how would you design a blockchain from the ground up basically with these constraints in mind and the design they came up with was this fast pay thing where you don't they observe that for payments you don't need ordering and i think other folks have observed this in the past too if you don't have a single balance but you think of payments as like you know you think of coins as like distinct chunks then you can send them in parallel and commit them in parallel and not have to need

this full consensus and then what we did in sui was basically taking that fast pay idea and say we actually start off by thinking okay fast pay idea is very applicable to nfts so maybe we can just take fast pay and layer some you know nice apis for like specifying nft metadata and things like that but then we started talking to potential customers and of course like they want much more than this to say okay we don't want static entities we want things that are mutable i want restricted transfers you know i want to be able to say i can create nft to number three only if i get number one and two as input and just basically they wanted full programmability so what we did is tried to squeeze as much programmability as you can into the fastpay model via move and just see what could be expressed there

and then we add full consensus on top to be able to express the rest of things like dexes or stuff that fundamentally requires sharing and ordering cool i want to understand a little bit more about kind of the go to market or like the ecosystem side of things because you're an l1 and back in 2017 everyone was raising money for l1s that have since come to fruition but a lot of them now are seeing that they must interconnect they must actually like you know link up to each other to other parts of the ecosystem so you're now in l1 but are you also considering like are you right off the bat thinking about how to link to the other networks yes we are uh so let me talk first about

the go to mark a little bit and then i'll talk about how linking to other chains plays into that so the use cases we're most excited about are where we think we can offer a lot over existing platforms and these are cases where use cases where you really need high throughput and the low fees that come along with it and also really low latency i think the most logical thing here is gaming where there are many many different folks in the gaming space and we've been talking to a lot of them who they want to do nft based assets in their game they want to move some aspects of gameplay online and they're just finding that it's really really difficult and expensive to do that on existing platforms and you know a lot of what gets talked about here is throughput but for games latency is the

the beginning and ending too right like you don't hear as much about latency as a performance issue in the blockchain space but full consensus uh has these multiple round trips to achieve an ordering like there's a lot of latency that comes in as an ad so we're focusing very heavily on games and our early partnerships and in our go to market because we think that's where we can especially add a lot of the value over existing platforms and of course like part of making games work well is you need to bring in the liquidity that's already in the blockchain ecosystem and this is where you know connecting to other chains happens so of course like you know you want to be able to sell nfts uh on an ethereum where a lot of the liquidity is or bring liquidity from ethereum to sui uh probably similar for solana and polygon

and some of these other ecosystems where a lot of things are happening in the the coin and nft space so we're thinking very much about games from the use case perspective and then of course like part of uh what makes that compelling is connecting to other chains what are the networks that you are actually looking to integrate with like would you integrate potentially just with one of these bridging solutions or interoperability now like zones networks which are already kind of connected to all the other ones things like nomad or xlr or would you do direct bridges to these networks so we're still finalizing our plans to that and of course like i think the best thing for us to do is build the gener make the smart contract platform as usable as possible so folks will build bridges to all the places where they need

in terms of us like we may or may not end up implementing and operating bridges ourselves but i think of course the ones i would expect to see emerge whether we do them or someone else does is of course you want to bridge to eth for the token liquidity from there and for all of the the nfts that are there i think solana's also gaining a lot of momentum in this area possibly to polygon as well none of these are things that we've worked out and we hope and expect like that there will be multiple bridges between sweden other platforms uh you know as there are for all these other blockchains that exist and for us it's really just about building the ones that our early partners will need or at least making it possible for someone else to build those if it's not us

i read somewhere that there was plans to work on something with sommelier sommelier is the project of a kind of repeat guest on the show zucky so yeah i'm just curious like how are you working with them exactly because they're not they're not an l1 they're like well they're kind of an l but they're like a meta l1 or something yes our collaboration with somalia isn't about sweet it's about this narwhal and tusk next generation consensus component that i mentioned so miston uh has relationships both with somalia and with cello to integrate narwhal and tusk into their setup and basically like give a massive throughput boost by pulling in this new consensus under the hood so we're working closely with the

the sommelier team to experiment swapping out tendermint with narwhal and tusk to really get the throughput boost and help them achieve the increase the effectiveness of the liquidity cannon they're building uh over at somalia cool the way i read it was it was like to bring smart contracts to cosmos was that a different thing maybe it was just a headline i think maybe that was a different thing but i mean who knows where that could go in the future i know some of the folks there are big fans of move but there aren't concrete uh plans to go forward with that at some point but we'll definitely be open to that in the future so you know i we kept forgetting to call facebook meta but do you have like you're talking about gaming do you still have your eye towards the metaverse is that on your

roadmap so i think to me the gaming is just the part of the metaverse that already exists or is like the preview of the metaverse that will come next like in games you're already multi-billion dollar businesses that work by uh selling digital assets and you know providing virtual worlds for folks to play around in and the the size of these has increased a lot over the like over the recent years and i think we'll continue to and to me the metaverse is just about expanding that into our work lives and social lives and in other areas where that makes sense i guess i'm a big fan of the real world and like i like the metaverse to the extent that uh it helps make our physical lives more meaningful uh and more connected and i think like gaming is one part of that but gaming

can also be it can be very social but it can be very solo and you know i'm very interested in ways of socializing outside of gaming and the ways that blockchains is a as a collaboration technology and as a social technology can enhance that let's talk a little bit about future plans or what's coming up like so far is there any zero knowledge anywhere in your stack not really eh i don't think we've heard anything like that so far so far there is not i mean so right our scaling strategy is based more on just uh improving the the base layer rather than trying to do zk roles on top of that in the long term i'm sure that's something that we could look into i think zk for privacy as a smart contract programming primitive or for light clients uh is something that we might

definitely want to look into uh costas my co-founder is our lead cryptographer and it's gonna have much more interesting ideas on how that could fit in there uh but for now yes there's no zero knowledge which i feel a little bit bad about being on the show that has so much great zero knowledge maybe by next time next time when i have someone else on for mistan there'll be like some other ideas in the works you just mentioned like client though that that sort of reminds me of like plumo and i wonder if you're at all familiar with that work yes of course uh miston has this engagement with cello and we know we know kobe well and like we know plumo and the very cool stuff that's going on there and so like i think as we think about our like line and phone ecosystem

and ways to reduce the bandwidth of that or reduce the computational cost of doing replays like pluma-like approaches are certainly something that we might want to think about we're also thinking a little bit and i should have said this apart earlier about random beacons which are useful both from a program perspective because you can do things on chain that require true randomness and also some of the consensus options we're looking at benefit from having a random coin for leader election and so we're this is a little bit further down the road but definitely like in the zero knowledge wheelhouse in terms of things that are that are interesting that uh you might see coming later is there any other kind of things we should look out for in the next little while maybe non-zk future tech ideas yeah so one thing we think is very interesting

about this object-centric asset model is that it enables a lot better things in terms of wallets and sort of client experience in general like for example for example one big issue with wallets today is that signing requests are not human interpretable you get a bunch of rlp bytes and your wallet says do you want to sign this and you're like yeah i don't know i guess it came from uniswapper alleged too so it's fine whereas we'd really like to provide something that's more like an android or ios permissions model where you say hey like this app would like to permission to touch your board ape and like this coin and to do that and because of the object centric data model like we can do that quite easily where when a transaction comes in you know what objects is going to touch you know their types you know their

shape and then often you can pre-execute the transaction and predict exactly what it's going to do so you can provide a much better user experience and turn and this is important both for security and just in terms of like predictability knowing how things are going to go where you can say like it's going to touch these assets i know it's going to touch these and no other ones is that okay with you and i think like this can help a lot with uh preventing some of both the the security and usability issues that you see elsewhere so i think this is one item and then i think another one is that having these structure types from a programmability perspective just makes a lot easier to do things that you can't do without establishing a common standard in ethereum or in other places like for the things that you get in something

like say erc721 the community has to come together and agree on the standard and it works well but then if someone wants to do something a little different you have to go through a whole another round of let's like talk about how to actually make this fungible or like how to make the url immutable or something along these lines and with structured types you write your type that has the properties you want and other people write code that just uses that type either embedded and they're in their struct or they take it as input and it just makes it a lot easier to sort of define standards without everyone having to agree on it people who want to agree on the standard use that type and other ones use some other type and then i think it just should just make it a lot easier to experiment with

things that are new use cases without having to go through the rigmarole of standards which i'm very excited about cool well i think we've reached the end of my questions sam thank you so much for coming on the show anna thank you so much for having me uh it's it's been a blast to be here i've listened to this show many times and uh it's a little bit surreal for me to be on the the other side of the mic so thank you for having me it's been a blast the other side well i do i i mean just as a side note we did actually have your your colleague george originally planned to come on the show he couldn't make it um i would love to explore this again maybe kind of when a new milestone is hit in fact maybe i could ask you that

question like what is the timeline when could people actually play with this yes this is a great question so currently putting all the pressure on you right now what we have now when is it coming what we have out now is an sdk where you and we have the sdk and the white paper you can run a node locally you can start writing moves smart contracts you can look at our examples um you can connect a wallet what we have coming uh hopefully by the end of this month is a public devnet where there'll be a network that's up and running you can do all the things you can do locally now with the devnet publish smart contracts call them they'll be a connected explorer within a few months after that we want to have a public test net where instead of the devnet which will only be run by

missed and operated validators we'll add in validators from the community and start building up a large validator set and developing the experience of operating the network and dealing with issues together and then we're hoping to go to a mainnet launch by the end of the year so we're we're hoping to move quite quickly things are things are going well from a tech perspective and it's really just a matter of both making it easier to build on top of the network and really getting to the the point of stability and uh security and heartedness that you need to to launch a new l1 cool thanks again sam thank you anna it's been fantastic and i want to say thank you to the podcast producer tanya the researcher on this episode chris who i think is the first time i'm mentioning him so thank you chris for helping put

together a lot of the notes and i want to say thank you to the podcast editor henrik and to our listeners thanks for listening you