Anna Rose (00:05):
Welcome to Zero 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.

Anna Rose (00:27):
This week, I chat with Sam Blackshear co-founder and CTO of Mysten. 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 Mysten. Before we kick off, I wanna highlight the ZK jobs board for you. If you're looking to jump into ZK professionally, I remind you to head over there. You will find job posts from some of the top teams working in ZK teams like Aleo, Anoma and Mina. Find the next project or team you wanna 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 wanna jump into ZK, this is probably a good place to start. Now I wanna invite Tanya, the podcast producer to tell us a little bit about this week's sponsor.

Tanya (01:28):
Today's episode is sponsored by Polygon Miden. Polygon Miden is a layer 2 scaling solution for Ethereum. Miden 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 Miden is Miden VM, a Turing complete STARK based virtual machine, which provides a level of safety and the supportive 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 Miden. Now here is Anna's interview with Mysten labs.

Anna Rose (02:09):
Today. I'm chatting with Sam Blackshear the co-founder and CTO at Mysten. Welcome to the show, Sam.

Sam Blackshear (02:15):
Anna, thanks so much for having me. I'm really excited to be here a big fan of the show and excited to be honored for the first time and to be the first guest from Mysten.

Anna Rose (02:22):
Yeah. Mysten 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 wanna hear, yeah. Tell me what Mysten is.

Sam Blackshear (02:36):
Yeah, absolutely. So Mysten 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 of Mysten and then you'll understand like what we're doing and you know, why we are where we are today. So myself and all of my co-founders we were 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 core, like done the research and development and a lot of the implementation for much of the core tech behind Libra.

Sam Blackshear (03:18):
So we created and developed a Move. We did a lot of work on the consensus protocol on the parallel execution bits, and this was an amazing experience of being at Facebook and working on this stuff. You know, we really got to take a very blue sky, look at blockchain tech and figure out like what's genuinely new here. And where's what are cases where, you know, fundamental computer science things that you can bring in and the, or insights from elsewhere that makes sense. And you kno w, 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 Libra a Diem or the, there were many, renamings never ended up launching for reasons that weren't related to the core tech.

Sam Blackshear (03:59):
Mm. 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. And we really understand some things a lot better and, you know, would do things differently. So it was both wanting to take some things we'd built a Facebook that never saw the light of day, like Move and to take those out into the crypto space. So there really need and take some next gen ideas for like, what can we do beyond Libra? Like, you know, we, there's some things about the Libra design that are good, but really we like, if you wanna design a scalable blockchain from scratch, like there are a lot of things we'd wanna do differently and that was never gonna happen inside of Facebook.

Sam Blackshear (04:32):
So this was the Genesis of Mysten is to take some of those ideas out there. And the problem that we're focused on solving or problems is really just look 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 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 solved 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 1 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.

Sam Blackshear (05:12):
You need key management to be less high stakes and more of like, you know, worry so much about losing your password and losing your life savings. You know, it needs to be more of that kind of experience. All of these of things I think, and more are problems that need to be solved to get to consumer enterprise great adoption of crypto. And so like Mysten 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 SaaS companies, many spinoffs to address all of these different, big problems that we think need to be solved to get to broader option of crypto.

Anna Rose (05:43):
What were you doing before Facebook? What's your pre blockchain story?

Sam Blackshear (05:49):
Y es. So I trained as a programming languages theorist. 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 at things null to references finding um array index out of bounds errors some stuff on C++ memory safety and enjoy, enjoy this work a lot. That'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.

Sam Blackshear (06:37):
And at Facebook, we got to do this. We had to make it run really fast, so it would go in CI. So it could, you know, happen in 15 minutes, even though you're analyzing tens of millions of lines of code. And I, 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 trying to patch basically design flaws in existing languages or existing frameworks, like what you're doing there is basically trying to accommodate the usage of something that already has a large amount of code written in it. 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 I 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.

Sam Blackshear (07:25):
And if you are starting over and doing these things from scratch, like how, how would you do it differently? And so that, that was my background, like both leading up to Facebook and leading up to crypto I was like having these thoughts and then Libra started up and they needed someone to look after the, the smart contracts part of it. And that was like, this seems like a, a great way to put some of these ideas about blue sky language design 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.

Anna Rose (07:57):
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?

Sam Blackshear (08:12):
I did meet Bobbin from Libra. I did meet Bobbin through the work on Libra. There actually isn't, or wasn't a general cryptography group at, 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. But yes, I did meet Bobbin and through that and get to work with him. He's fantastic. 

Anna Rose (08:33):
Cool. I mean, that's the only other person I've had on the show 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?

Sam Blackshear (08:49):
It had been, yeah, I guess it had been a while for me, it had been a, a five or almost six years, you know, it, 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 Diem. And just because like, the work of the, we had started with Move felt unfinished. And I was, this felt like the way to give it a second in life and to really like, get it out there. And then I was also incredibly excited about some of the new ideas that we've since been working on in Sui 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. The smaller ones. Oh, hard to like deciding what to eat for what to eat for lunch. So the, this one yeah, it wasn't it wasn't too difficult of a choice I thought,

Anna Rose (09:36):
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, but like Aptos and ZEF?

Sam Blackshear (09:49):
Yeah. So there's a, we call ourselves the Libra mafia. I think there, there's a number of folks coming out of there that have gone up to do different things. So yes, you mentioned ZEF and Aptos. And then of course, like you have folks at a16z Riaz and Naz who are like very talented folks working in custody at Facebook who are now at a16Z. There's a guy Fred who you may know Who's also doing a crypto startup there's Dahlia Malkhi, who we also worked with at Facebook. Who's now the chief scientist at Chainlink and, you know, Kristen Catalina, who's also who is the chief economist there who also work 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 I think hopefully you'll be hearing from a lot of them going forward.

Anna Rose (10:30):
Is the project done internally? Or like, what do you know what's happened to it?

Sam Blackshear (10:35):
Yeah. Facebook announced that they were no longer working on the project. And I think the Libra association also announced that it was dissolving.

Anna Rose (10:43):
Wow.

Sam Blackshear (10:43):
So it is done.

Anna Rose (10:44):
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 were definitely like, it was like the boogieman a little bit. People were scared, but it's kind of it ends with a little, not with a bang. I don't know, bit of a shame,

Sam Blackshear (11:03):
It's a bit of a shame. I mean, the folks always announced 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 CBDs more seriously in advanced discussions. Yeah. 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 the groundwork for some important things that will, that will come later. So I, I feel good about that part of it. Anyway,

Anna Rose (11:33):
Well, let's dive into some of the pieces that you are bringing with you. I kind of wanna start with the Move language because that's obviously something very dear to your heart. Tell us what is Move.

Sam Blackshear (11:47):
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 rate, like everything under the hood is just bites 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 wanna 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 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 bit strange.

Sam Blackshear (12:33):
Like when I look at these, when I look at the kinds of programs, folks are trying to write, they're all about assets. 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. The data model is very strange. It's you have a big hash table where the keys are addresses and the, the address values are basically the entries in that hash table. You know, if it's a for coins, that's an integer in for an NFT, maybe it's 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 to a function.

Sam Blackshear (13:12):
You can't even have an asset leave the, where it's created. And so to me, this just seemed like it's not gonna be the right language for expressing this sort of stuff. And this isn't just an ergonomic thing at least to safety issues as well, because it's really hard to talk about something like anatomic transfer when that requires touching one entry in a table and then touching another entry in the table, and then making sure that something doesn't happen in bit between, like, this is how the DAO 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, 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.

Anna Rose (13:56):
Did you look at other smart contract languages though past, Solidity? Like, are there any that maybe even like influenced a little bit Move?

Sam Blackshear (14:05):
Yeah. So at the time, and this was 2019, the Solidity in the EVM were 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 lot. So 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 and the blockchain space, it has this notion of Move semantics or sub structural 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 us in terms of the way it represents assets. And then that idea in turn, comes from C++, or like there are other languages too mainstream languages that have this idea of sub structural types usually to represent memory which is also something in us to have scarcity properties, but then using it to represent assets was something that was new on Move.

Anna Rose (15:09):
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, cuz 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?

Sam Blackshear (15:29):
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 base is 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'll be interesting. And that there, 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't, 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 falt tolerant replication system. If you have non-deterministic semantics even a validators agree in everything else, they at different answers.

Sam Blackshear (16:12):
And then 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. Yeah. 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. And so right, you need to have this, of course in the blockchain context, because you don't want someone to send a, a transaction with an infinite loop, install the entire system, or, you know, even less, extremely just something that occupies 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 objects, like, you know, you can copy objects and you know, you don't have to have something like Move semantics.

Sam Blackshear (16:58):
You know, it's, 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 rust code and the source compiler is telling you when you're doing something wrong, but actually at the, at the executable level, at the byte code level in Move's case where even if somebody wants to skip the source compiler and write code directly in the byte code 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, which, and mainstream languages don't have any of them.

Sam Blackshear (17:36):
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, I'll like restrict it to get rid of the non-determinism and maybe like, I'll 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 gonna 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 for Python and then for JavaScript as well.

Sam Blackshear (18:13):
It was 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. Then it it's gonna 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.

Anna Rose (18:37):
Interesting. It's sort of a bit of a throwback for me. Like a few months ago, a month ago I had Dean from Agoric come on, they did something like they, they also have this language of hardenedJS, right? So it's JavaScript, but like made more compatible to blockchain. Are you familiar with it?

Sam Blackshear (18:54):
Yeah. I'm familiar with Agoric and spoken to those guys a bit. And I, I think what they're doing is very interesting as well.

Anna Rose (19:00):
Cool. But you decided to go a different route after evaluation.

Sam Blackshear (19:03):
We decided to go a different route. I mean, I think with hardenedJS the thing is you'll run into this issue that I was just describing where are 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 Agoric specific libraries. You know, this is these things just aren't directly applicable. And I think like really that's an approach worth pursuing as, but I think taking something that's already complicated and trying to build a dialect of it, that's specific to blockchain is just gonna lead to a result that is more complex than starting from something simple.

Anna Rose (19:40):
Hmm. 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.

Sam Blackshear (19:51):
Oh yes. Nothing free's us from the needs 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. 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 bytecode gets loaded from discs, there's some are on the blockchain. In this case, there's some set of checks that run that enforce basic things like type safety and 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 was doing that also happens for bytecode that for some reason, didn't go through the source compiler.

Sam Blackshear (20:28):
Then of course you have testing. And so Move, we have built in unit testing that you can write directly in move. And then the most interesting and important thing is that we have this thing called the move prover. 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 at Mysten 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 prover can show that for all possible sequences of calls for all possible transactions. This property will continue to hold. And so you can write all the things that matter for your particular use case as specifications.

Sam Blackshear (21:12):
And then the prover 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 for 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 it's at run time and you can do things like using a, a subset that tries to restrict these things. But then you're gonna have to build tools that specifically understand the subset instead of a general JavaScript.

Anna Rose (21:57):
Hmm. How many people built Move? How many people work on that?

Sam Blackshear (22:01):
Yeah, so it's quite a few. 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 maybe like five or six working on Move at Mysten And then of course Move is a, a cross platform language. It's not a specific to one blockchain. So Aptos is using Move. So they have folks that are looking at it. There's this ... Open libra project. That's a, a fork of Libra, a similar to Aptos. That's also using Move. They have some folks working on it. There's a, a project called Starcoin in China. That's also proof of work blockchain using Move that have a bunch of folks work in 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 the developers building on top. Of course there are, 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, there are team size numbers. I shouldn't talk about it, but there are, there are still folks that are working on both Move and the prover.

Anna Rose (22:59):
I just realized that I just kept calling Facebook, Facebook. I should have been calling it Meta. Whoops.

Sam Blackshear (23:03):
I couldn't adjust too change it either. To be honest, I, I left just before it happened. And it was Facebook for some that it's still Facebook to me,

Anna Rose (23:11):
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?

Sam Blackshear (23:20):
There can be external contributors in our 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 are allowed to press the accept buttons, small and then make sure that you get things carefully reviewed just to make sure that no one is introducing vulnerabilities or back doors or any of these other things you have to worry about in a blockchain project or a, a high security project

Anna Rose (23:43):
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,

Sam Blackshear (23:56):
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 training as a program language theorist, you write down exactly what the semantics of each instruction are. You write down what the key properties you want to ensure. So like, for us, like that's the, these, there 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 destructor and not just sort of accidentally left on the floor.

Sam Blackshear (24:42):
So you can write these things down on pencil and paper prove that the language semantics satisfies them. And so that part you can feel very, very confident. And as confident 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 right. Of course you test the language very extensively and you do things you do, you know, 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.

Anna Rose (25:20):
Hmm. How long do you think it takes a language to, to be battle tested or how much volume? Maybe it's not time. It's more like, yeah. Edge case is tested somehow in, in the wild,

Sam Blackshear (25:33):
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, or you can be fully confident about that, especially as something is evolving.

Anna Rose (25:52):
Cool. So what is Sui?

Sam Blackshear (25:54):
So Sui is a smart contracts platform and it's a smart contracts 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 in throughput over time

Anna Rose (26:09):
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.

Sam Blackshear (26:18):
Yes, that's 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 thing things you might care about, or at least not doing so specifically. So sharding like sharding is a technique that can, you can talk about sharding computation. You can talk about sharding state and then you can also, and this is a blockchain thing. Talk about charting as part of the protocol where everyone, you know, you go and look at the protocol spec and it talks about sharding and how it works. Or you can talk about sharding what we like to call intravalidator, sharding as an augmentation strategy that you don't need to be aware of at the validator level. So in Sui, and in contrast to say, what ETH 2 or Serenity I think is the name of this project now is doing, or what near is doing.

Sam Blackshear (27:03):
We do not have sharding at the protocol level. But we do have sharding 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 the where, some of the computation happens in each one or the store just spread out among each one, but different validators need not be aware of how other validators are sharded. And there doesn't need to be a protocol level or community decision to decide how sharding 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 sharding inside your data centers, but as a customer of the system, you don't need to be aware that they're sharding happening or how it works. And you have the flexibility to change this very dynamically as well.

Anna Rose (27:47):
So it's the smart contract platform. Is it a VM?

Sam Blackshear (27:51):
It has the Move VM inside, but it is not itself a VM.

Anna Rose (27:54):
I see. So it's the Move VM in Sui.

Sam Blackshear (27:58):
Exactly.

Anna Rose (27:59):
Okay. And what does Sui stand for? It's kind,

Sam Blackshear (28:02):
So it, it's not an acronym. It's the origin of the name is that 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 blockchains space today. So if we are lucky to happen upon this one,

Anna Rose (28:28):
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. Why is this a naming choice or is it built differently?

Sam Blackshear (28:37):
Yeah. So good question Move is both the name of the source language and the virtual machine. Whereas you have the Ethereum virtual machine and the solidity source language you could in principle have other source languages for Move, but we call it the, the Move virtual machine. And we very intentionally call it that instead of the Libra virtual machine or the, the one, because this is a cross platform thing. It works for everywhere that you have Move. Like if you go and look at Starcoin or zero L they're also using the Move virtual machine, not some specific version.

Anna Rose (29:03):
Is that something that like the language provides out of the box, or is this a separate library?

Sam Blackshear (29:08):
This is something that the language provides outta 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, so thing, 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 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. I'm gonna, here's my notion of accounts. If I have that, here's a crypto photography I'm gonna use, here's a consensus. And then Move, lets you do whatever you want to 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.

Anna Rose (30:10):
I kind of wanna understand how this lives as a blockchain. Like, is it like the account model? Is it a UX O or is it something else? Yeah. Like let's, let's talk about Sui specifically here.

Sam Blackshear (30:21):
Yeah. Let's talk about Sui 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 are Move values might be something like an NFT. It might be something like a fungible token, something like a DEX. That's an object as well. And 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 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 gonna make a trade in DEX , you would say this transaction takes the ID at the DEX it's gonna make with, and the idea 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 Sui. There are objects,uyou pass objects in the 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 gonna do with the, the data objects you've passed in.

Anna Rose (31:20):
But what is actually written to chain, then we're still talking about blockchains. So like what's being put in like, sorry. It's I know I'm, 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, what is it in this case

Sam Blackshear (31:39):
Here? It's the object or objects, the transaction, it declares the objects it's gonna 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 would come in here. There's a notion of address, like right. A transaction does have a sender or 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. Okay.

Anna Rose (32:18):
Can you do stuff to these objects? Can you affect them?

Sam Blackshear (32:22):
Yes. Whatever code you can right. And Move, you can do that thing to that object. So this includes the basics, like mutating, the objects fields destroying it, creating new objects 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 any of these sorts of things that you can do.

Anna Rose (32:43):
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?

Sam Blackshear (32:57):
It is really destroyed. So the, the state of Sui, 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 put 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, 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,

Anna Rose (33:37):
It's proof of stake, right?

Sam Blackshear (33:38):
That's right

Anna Rose (33:39):
In this model. Do do the validators do anything different or are they just kind of acting like validators as we've known them?

Sam Blackshear (33:46):
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 the 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 Sui the thing we're doing. That's interesting is that we observe, there are some classes of computations that do not require ordering. 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.

Sam Blackshear (34:29):
They can be executed in a parallel, but they can also even be committed in a parallel without going through full consensus. And so in Sui, this is, this is what we do. When you have transactions that touch distinct objects, 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. And then for use cases that do require full ordering. Like say, if you have a DEX this, this inherently requires ordering, right? Like you and I are hitting the DEX 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.

Anna Rose (35:22):
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?

Sam Blackshear (35:32):
So it gets committed earlier. It's just that, oh, if so, right. This is a proof of stake system where, you know, you have to have some, you have to have all say for simplicity two oh, 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 oh, plus one validators on that action, 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 of plus one signatures, and then they can then use that object in a subsequent transaction or provider's proof of payment or, and the other things that you would like to do in a normal setting.

Anna Rose (36:16):
I know, I think you'd just explained this, but now I'm like, cuz 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, but I didn't. So

Sam Blackshear (36:34):
These transactions, I wouldn't describe them as less important, but they're you need less computational power to deal with them or less agreement, power, let's call it that

Anna Rose (36:42):
What would be an example? Would this be like connecting an NFT to another NFT, like making them composable or is that very,

Sam Blackshear (36:49):
I think a basic token transfer is the simplest one where, and I think for folks familiar with the 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 outgoing 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. Then 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 a 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 whereas in, in something like a DEX or an auction you do need that ordering.

Anna Rose (37:35):
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 by what you say, what happens to it after you've paralyzed, 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

Sam Blackshear (37:57):
Because of these transactions, like don't go through full or 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 ordering, 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 there, like every now and then either EPOC 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. Okay. But you didn't have to build that ordering to, to commit the transactions because the ordering isn't gonna change their effect. That's sort of the key thing here.

Anna Rose (38:42):
You're doing almost like an every EPOC 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 acyclical graph? Oh god, the D is wrong. Right? What, what was th first word?

Sam Blackshear (38:57):
Directed Acyclic graph directed. Yeah, yeah, yeah. That's exactly what it is. So wait, these transactions that don't go through full consensus. They're not unordered they're, causily 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 the objects in Genesis and then you have the, the edges or transactions that take those objects, then put 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 the, the history of suite. 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.

Anna Rose (39:46):
Okay. How, how are validators being chosen in this consensus actually? Is this like, is it like the 66% must be something like, yeah, I'm just curious. Like how, how is this working?

Sam Blackshear (39:59):
What we do here is very conventional where it's a proof of stake system. 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 fast track mode where you commit things extensively, 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. Mm-Hmm

Anna Rose (40:22):
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?

Sam Blackshear (40:30):
Hot stuff is a consensus algorithm. And one that was used in DM or at least like a, a variant of it was used in DM. And 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 HotStuff, you could use Tendermint, you could use Narwhale Tuska, which is,uI wish my co-founder George was here to talk about this,uwhat probably what we're going to use in Sui this next in consensus they can do that separates the, the notion of the mempool from the notion of actually ordering things. And then it gets a lot of speedups related to that. Ubut so there there's no direct relationship with Hotstuff to answer your concrete question.

Anna Rose (41:06):
Got it. Now let's bring it back to Move because now that we have some sense of Sui, like how do these things work together? Why kind of going back to that initial thing that I, I had sort of hinted at, like, does Sui allow Move to act differently or does actually Move, allow Sui to act? I think it's the first right.

Sam Blackshear (41:27):
I think it's the latter Move allows Sui act differently. 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. So like thinking about Ethereum, like the data model is, is contract centric where there's no notion of an object or an asset, right? Like you have a HashMap and then the object is some entry in there. So if you wanted to say in, in ETH 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 and it into somewhere else, like, all you can do is switch the owner or things like that.

Sam Blackshear (42:13):
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 Move that 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, the things that we're doing in Sui.

Anna Rose (42:42):
Does the language actually offer this ability to parallelize somewhere in it as well. Cuz you mentioned it in the context of Sui having the sort of like multiple non things happening at the same time, different validators seen it, but yeah. Does the language take advantage of that?

Sam Blackshear (42:59):
So this happens in the layer above the language, the language provides the data model that lets the layer above do that. But the Move VM is the Move. VM is single threaded and you know, usually does short running computations as smart contracts are maybe eventually it'll it'll run things in parallel. Once we have smart contracts to machine learning or other fancy stuff. Oh 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, as a sub team.

Anna Rose (43:28):
When you say going above the language, do you mean like the smart contracts being deployed on the VM?

Sam Blackshear (43:36):
Yeah. 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 a parallel? And then how do I organize the, the structure of the computation side, the validator? That's what I mean by the layer of above, not by the smart contracts, the, the smart contract program model is this very much the same in terms of you write your code, you just have this nice abstraction word. 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, the validator software, the runtime, whatever you'd like to call it to, to take that in and figure out, can I commit this parallel? Does this need to go through consensus? What object IDs do I need to specify dependencies and all of these sorts of things.

Anna Rose (44:23):
Cool. A colleague of mine at the zero 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?

Sam Blackshear (44:36):
So right. I think he's probably asking about the Byzantine consistent broadcast thing, which does come from, let me explain FastPay and how that relates. So at Facebook my co-founder George, as well as Alberto who works at Mysten and a number of other folks were task with this problem of, okay, we wanna 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 FastPay thing where you don't, they observed that for payments, you don't need ordering. And I think other folks have have observed this in the past two, if you don't have, 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.

Sam Blackshear (45:22):
And then what we did inwe was basically taking that FastPay idea and say, we actually start off by thinking, okay, FastPay idea is very applicable to NFTs. So maybe we can just take fast pay and layer some, you know, nice PIs 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 NFTs. 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 is input and just basically they wanted full programability. So what we did is tried to squeeze as much programability 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 Dexus or stuff that fundamentally requires sharing and ordering.

Anna Rose (46:07):
Cool. I wanna 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 seen that they must interconnect. They must actually like, you know, link up to each other to other parts of the ecosystem. So you, you are now an L1, but are you also considering, like, are you right off the bat thinking about how to link to the other networks?

Sam Blackshear (46:41):
Yes, we are. So let me talk first about the go to market 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 a existing platforms. And these are cases where use cases where you really need high throughput and the low fees to 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 wanna move some aspects of game play online. And they're just 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?

Sam Blackshear (47:25):
Like you don't hear as much about latency as a performance issue in the blockchain space, but full consensus has these multiple round trips to achieve and ordering, like there's a lot of latency that comes in as an ad. So we're focusing very heavily on games in 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 the liquidity that's already in the blockchain ecosystem. And this is where, you know, connecting to other chains happen. So of course, like, you know, you want to be able to sell NFTs on an Ethereum where a lot of the liquidity is or bring liquidity from Ethereum to Sui probably similar for Solana and Polygon and some of these other ecosystems where a lot of things are happening and 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 what makes that compelling is connecting to other chains.

Anna Rose (48:15):
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, net, like zones networks, which are already kind of connected to all the other ones, things like Nomad or Axelar, or would you, you do direct bridges to these networks?

Sam Blackshear (48:32):
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 generic, 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 a bridge to ETH for the token liquidity from there. And for all of the, the NFTs that are there. I think Salon is 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 Sui and other platforms 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,

Anna Rose (49:17):
I read somewhere that there was plans to work on something with Sommmelier? Sommelier is the project of a kind of repeat guest on the show Zaki. So, yeah, I'm just curious, like, how are you working with them? Cause 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.

Sam Blackshear (49:39):
Yes. Our collaboration with Sommelier, isn't about Sui. It's about this Narwhal and Tusk next generation consensus component that I mentioned. Oh, so Mysten has relationships both with Sommelier and with Celo to integrate Narwhal and Tusk into their setup. And basically like give a massive throughput boost by pulling in this new consensus onto the hood. So working closely with the, the Sommelier team to experiment, swapping out temperament with Narwhal and Tusk to really get the throughput boost and help them achieve the increase the effectiveness of the liquidity can. And they're building over at Sommelier.

Anna Rose (50:12):
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.

Sam Blackshear (50:20):
I think maybe that was a different thing. But I mean, who knows where that could go in the future? I, I know some of the folks there are big fans of Move, but there aren't concrete plans to go forward without, at some point, but would definitely be open to that in the future.

Anna Rose (50:32):
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?

Sam Blackshear (50:44):
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 selling digital assets and, you know, providing virtual worlds for folks to play around. And, 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 it helps make our physical lives more meaningful 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 as a, as a collaboration technology and as a social technology can enhance that.

Anna Rose (51:37):
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,

Sam Blackshear (51:47):
So far not. I mean, so right. Our scaling strategy is based more on just improving the, the base layer rather than trying to do ZK rolls on top of that. And 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 is something that we might definitely wanna look into Kostas, my co-founder is our lead cryptographer, and it's gonna have much more interesting ideas on how that could fit in there. But for now, yes, there there's no zero knowledge, which I feel a little bit bad about being on this show that has so much great zero knowledge content.

Anna Rose (52:18):
Mmaybe by next time or next time when I have someone else on for Mysten, 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 you're at all familiar with that work?

Sam Blackshear (52:31):
Yes, of course. Mysten has this engagement with Celo 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 lightclient ... Ecosystem in ways to reduce the bandwidth of that, or reduce the computational cost of doing replays, like Plumo like approaches are certainly something that we might wanna think about. We're also thinking a little bit, and I should have said this part 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, a random coin for leader election. And so we're, this is a little bit further down the road, but definitely like in the a zero knowledge wheelhouse in terms of things that are, that are interesting, that,uyou might see coming later.

Anna Rose (53:15):
Is there any other kind of things we should look out for in the next little while maybe non ZK, future tech ideas?

Sam Blackshear (53:21):
Yeah. So one thing that 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 like example, for example, one big issue with wallets today is that signing requests are not human interpretable. You get a bunch of RLP bites and your wallet says, do you wanna sign this? And you're like, yeah, I don't know. I guess it came from Uniswap or allegedly, 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 Bored Ape and like this coin and to do that. Yeah. 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 gonna touch, you know, their types, you know their shape, and then often you can, pre-execute the transaction and predict exactly what's gonna do so you can provide a much better user experience in terms.

Sam Blackshear (54:12):
And this is important, both for security. And just in terms of like predictability, knowing how things are gonna go, where you can say, like, it's gonna touch these assets. I know it's gonna touch these and know other ones is that okay with you? And I think like this can help a lot with a 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 programability perspective just makes it 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 I say ERC 721 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 nother round of let's like talk about how to actually make this fungible or like how to make the URL mutable or something along these lines.

Sam Blackshear (55:00):
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 in their, 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 it about.

Anna Rose (55:28):
Hmm. Cool. Well, I think we've reached the end of my questions, Sam. Thank you so much for coming on the show.

Sam Blackshear (55:35):
Anna, thank you so much for having me. It's it's been a blast to be here. I've listened to this show many times and 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.

Anna Rose (55:44):
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. I would love to explore this again. Maybe kind of when a new milestone is hit. In fact, maybe we, I could ask you that question. Like, what is the timeline? When could people actually play with this?

Sam Blackshear (56:05):
Yes, this is a great question. So currently

Anna Rose (56:07):
Putting all the pressure are on you right now.

Sam Blackshear (56:09):
What we have now, when, when is it coming? It's there? What we have out now is an SDK where you, we have an SDK in the white paper, you can run a node locally, you can start writing, move smart contracts. You can look at our examples. You can connect a wallet. What we have coming, 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, there'll be a connected Explorer within a few months after that, we wanna have a public testnet where instead of the DevNet, which will only be run by Mysten operated validators will 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, a matter of both making it easier to build on top of the network and really to the point of stability and security and heartedness that you need to, to launch a new L1.

Anna Rose (57:09):
Cool. Thanks again, Sam.

Sam Blackshear (57:11):
Thank you, Anna. It's been fantastic.

Anna Rose (57:13):
And I wanna say thank you to the podcast producer, Tanya, the researcher on this episode, Chris, who I think this is the first time I'm mentioning him. So thank you, Chris, for helping put together a lot of the notes. And I wanna say thank you to the podcast editor Henrick and to our listeners. Thanks for listening.