E133: SUI Network CoFounder: The Real Problem With Crypto Security

27:39So when you joined Facebook, you started to do all these very more practical things. How much of the things that you did in the PhD was really useful? So a very high percentage of them, which is why I enjoyed it so much, because we built the same kind of tools. It's just that it was hard to find the users for them. And we had to do a lot more of the infrastructure stuff of trying to build the code that we're finding bugs in even. or like find the right examples to look for. And here it's like, here's your example is the millions of lines of code that Facebook has. You know, we already have build systems.

28:13We already have CI. Like you get to focus on just the part that's the hard engineering and science that's specifically related to program analysis and this automated bug finding thing. So you like that so much that you said, okay, I'm going to go back, finish my internship, my PhD, and then move back to Facebook. Yeah, exactly. It's like, you know, being a professor would be cool, but it feels like this is, the industry is changing. It's sort of adopting this research technology. They're trying to commercialize it. I want to be a part of that. And I love working with them. The team that I worked with at Facebook was a team of academics who had a startup that was acquired by Facebook.

28:47So I think we all thought a lot the same way. We had similar academic backgrounds and similar ambitions for what this technology could do. So it was really awesome to work with like-minded people, but then also with crazy Facebook programmers and industrialists, It's like just a very productive mixing of different points of view and expertise. How did you get so fascinated by the world of cryptocurrency? Yeah, that was a very interesting path into that one. So, you know, I did this static analysis developer and for bug finding stuff at Facebook for a number of years, like 2015 to 2018. And I love the work and I had no intention of doing anything else.

29:23And then I got pulled into a room by Ben Maurer, who is the senior tech lead at Facebook, you know, very legendary figure there. And he told me about this Libra thing that Facebook is working on. So it was about this blockchain-powered global payments network. You know, we're going to use it to do payments across borders. We're going to have a stablecoin. It was this very, very big vision. And also this sort of secret and very ambitious project where Facebook usually does more internally public and incremental projects, I would say. And so, you know, it was this whole big thing and they're like, well, there's this smart contract component of it.

30:01And they're like, there's enough research, programmable leaders research stuff about smart contracts that I had been aware of. Solidity and, you know, the EVM and these hacks and vulnerabilities, you know, done my share of eye rolling. Like the design of this stuff is horrible. It's not going to work very well. But I never really thought about like, that's a problem that I should work on because Facebook didn't have any code in that area. When were you looking at that? See, I rolled my eye on that. Yeah. It's like you're looking at that stuff on the side for fun. Yeah, for fun. Well, yeah, I guess as a researcher, you know, there are a couple of big conferences in your field.

30:32And so you'll read through like the paper titles and the abstracts and then maybe even the papers themselves of what's going on. And so like a couple of years earlier, I guess not so many years earlier because Ethereum came out when like 2016, there started to be these papers about like smart contracts and like, you know, vulnerabilities and like solidity and things like that. So, you know, just like I would follow any happenings in the field, I read about those. And so I had awareness of it at that level, like from the perspective of a programming language researcher, like here's this new class of languages that are emerging, what's going on with them.

31:00So I was aware like that, but, you know, just like I'm aware about languages for programming with quantum computers or, you know, other things that the field is interested in. It's very broad in that way. And so when I heard about this, like, oh, Facebook's actually interested in doing something with that, you know, we don't have any experts in this. I see that there's some motivation for doing better here. I have my own opinions about software safety and languages and bugs from my own work at Facebook, my own academic background. This sounds like an amazing opportunity. You might get to design a programming language as someone who spent their career studying programming languages.

31:33This is amazingly exciting. Very clear to me that this is something that you should say yes to. I basically dived in and learned about cryptocurrency that way. I started in my domain as learning about smart contracts, and that's where the idea for Move came from. And then I got deeper into cryptocurrency by working with integrating Move into the Libra project, learning about the other technical parts of crypto, distributed systems, cryptography, and meeting people who are experts in those and were willing to share their expertise. this Libra project was an amazingly interdisciplinary and just like clever and friendly group of people that we're all trying to figure this thing out together.

32:15Let's try to get like really more practical here. So first, what was exactly Libra? And then if you can explain us what problems you're trying to solve and which is why you had to create a new programming language. Yeah, so Libra was a few different parts. So Libra was this blockchain, and the purpose of this blockchain was a settlement layer for payments. And then there was going to be a stablecoin, also called Libra, issued on top of the platform. This sort of global currency that can be used for international payments that's pegged to the dollar, pegged to a value of currency so that it doesn't fluctuate like cryptocurrencies of the time and cryptocurrencies of today do.

32:57And then there's a vision of having companies like Facebook, like some humanitarian organizations like Mercy Corps, having wallets that built on top of Libra and then facilitate these payments. These are basically organizations who need cross-border payments for what they do as part of their core business. This was the so-called Libra Association. so those were the different parts and then my domain was both in you know with Libra we wanted to be programmable with smart contracts and so it was my job to figure out what should we what virtual machine programming language should we use and how does it fit in with the rest of the system and then that ended up also dictating a lot of the other parts of the design of Libra so that's the big picture of what Libra was and how these things fit together what were the main problems to solve if you look at what you did is you studied Bitcoin and Ethereum ecosystems and the problems that happened there and then essentially you said hey like we cannot have this happening and therefore we probably can't use the same stack yeah that's a great question so the programming language it's so interesting with any programming language you might ask like yeah what is the problem this programming language is solving and someone would tell you something but then you would move on to another programming language and say well what about this one?

34:15What problems is it trying to solve? And they probably tell you some of the similar things and you go like, what's going on, man? Why do we need so many different programming languages? Why don't we just have one programming language that does everything super well and we'll work on that and we'll have it. Everyone will work on that and have it do it the best. And so I think the thing with programming languages is that they're, from my point of view, domain-specific problem-solving tools. And so they should have, I don't think they always do, but I think they really should have a very specific set of problems that they're trying to solve and they should be laser-focused on solving those problems and focus specifically on not trying to do anything else.

34:47Because otherwise you get this mess of you start off with a goal, you're on the goal, but then oh, someone asked for a feature, you add that feature. Oh, someone wants to do this, you add that. And all of a sudden you have this mess that you lose focus and you lose simplicity and you can't do the core thing. So with the move I actually did want to really start off with having a clear set of problems to solve. And so those problems were you want a representation of money or of things that are inherently scarce. You want to have something that one person has it and it exists in only that place. And then obviously you don't want it to be copied or copyable.

35:23And so this is hard because in a conventional program language, if I say like, let x equals 7, and I say let y equals x, you're actually copying the contents of x. Well, if x is money, that's not going to do. It has to... It can't be copyable. It has to have this inherent scarcity. And then also you want transferability. Like I have X, I move X to Kevin. Now Kevin has X, you know, no longer exists here. I shouldn't be able to continue writing to it or using it or, or anything like that. So scarcity, like a first class representation of scarcity and assets was one goal. And then the other goal is about access control.

35:55You know, the, there's the nouns in the sentence, the assets, then there's the, the prep prepositional phrases owned by Kevin, you know, owned by so-and-so, um, not usable until this time, until that time, these rules on who's allowed to access assets and what they can do with them. And to me, from studying smart contracts, this is basically all that they do. It's recipes for creating new assets, what they are, what data is inside them, rules for transferring them, rules for authenticating the people that own them. And so this is a very narrow set of problems to solve, whereas with a conventional programming language, you want to talk to the disk, you want to talk to the network, you're spinning multiple threads and doing stuff in parallel, you're doing very sophisticated math with floating point numbers.

36:34And so the thing that Move is trying to do is do only those things and do those things really really well and don't try to do anything else um you're the creator of the move language how would you explain the move language to your mom yeah one sentence it's a language for programming with money i think that's the the one sentence sir you studied bitcoin and ethereum you talked about we talked the other about the DAO hack, especially those failures and or bad moments in both ecosystems. What specific failures or hard moments in the Bitcoin and Ethereum ecosystems were highly influential in the creation of the move language?

37:19Yeah, so I think the DAO hack would probably be number one. There's also the parity hack, which happened around the same time. And so there are these big picture vulnerabilities, which I think, you know, it's good to look at those, but you don't want to over-index on just one thing. And to me, it's really about looking at the code people write day to day, even when that code is correct. Just where is it not perfect instead of having in terms of having a really minimal gap between what the program was trying to do and what they had to write down to do it. And so it's about like having the right abstractions, the right building blocks to do what they're trying to do.

37:54And the thing that really struck me about Bitcoin and Ethereum is you read this code and like what it's trying to do is all about this notion of assets and exchange. Yeah, these languages have no primitives for assets and no primitives for exchange. Like all of these things, the programmer has to rebuild from scratch every time. Everyone does it in a slightly different way. Sometimes they get it wrong. And so with Move, what I really wanted to do is provide those right, figure out what those right building blocks were and then have the language provide them in a way that's just built in, that's as safe as possible, that's really easy to work with and stack together to build more complex things.

38:26And so I think like there have been many, many more of these security incidents in Ethereum since then that are motivated. But I think like any of these, when you look at them, I think it usually goes back to someone did something wrong because they were trying to do something complicated that should have been simple if you were starting from the right building blocks. Most programmers use program languages to build applications. They're using languages that exist already. Yeah. How the hell do you create a new language? Yeah, I mean... Where do you even start? That was a very daunting thing for me Because I think the way most people start is they take an existing language that they kind of like, and then like maybe there's one or two things that they don't like about it.

39:08And then they sort of like change those things and they say, look, it's a new language. But, you know, you really, it's such a hard problem, right? Because with languages, even if you figure out what to do and it's 10x better than everything else that's there, like adoption and community are such a huge deal. Like having the existing documentation, the answers on Stack Overflow, the army of programmers already know your language and can go and work for companies. the tooling, IDE integrations, you know, compilers today, like LLMs that understand all this kind of stuff. It takes so much time to build out that you should probably just abandon the project and not design a new language in the first place.

39:43And so the first thing we try to do is not set out to build a new language. Like, let's see if we can take the EVM and make it better. Let's see if we can repurpose WASM or the EVM, you know, or sorry, let's see if we can repurpose a general purpose programming language like the evm or the clr or wasm and these sorts of things i think like that's always the approach you should take like see if you can solve your problem with something that's there but add modifications on top or add some restrictions or like change it to be what you want it to be and the reason we didn't end up going that route was when we looked at the general purpose languages they just tried to do so many things like we were talking earlier like you know oh multi-threaded programming you know disk io you know networks fancy math and all this like to get it to be a smart contract language you ended up having to restrict all this stuff that you don't need and then add you know asset support and you know account support and transfers and all this stuff on top and it ends up looking like this chimera of like delete a lot of the stuff and then add all this new stuff and it's just it's not small and simple and very problem directed um and so i think like you know if you see rust and the way like you know solana uses rust it sort of looks like this too where like they have to take out some features and they have to add their own like sort of solana specific abstractions and libraries so like let's try to do exactly what we want so the way i approach to actually answer the question the way i approach design language is figure out the problems to be solved the jobs to be done having these nice abstractions for assets and access control and then build out a language that what's what i would want as a programmer if those were the things i i was working with and what's sort of the absolute minimal set for that and then just sort of start writing a bunch of example programs of things we had seen in Ethereum and, you know, make sure we can implement all of them, that they look really nice and they look really simple and sort of seem like the essence of what you'd be trying to say.

41:28That's why I approached it, but I definitely had a lot of a blank sheet of paper shock during this time. And, you know, I was like, I don't really know how to get started or like whether you're going down the right path or any of these sorts of things. I had Gavin Wood on the podcast, the inventor of the EZM and the Solidity Language, language, which is most likely one of the reasons why we're both here today. And as you came up with the move language, which is a sort of next evolution of the solidity language, I have to ask you the same question as I asked him. How do you come up with a great idea?

42:05So to me, great ideas are great because they solve important problems. And so I think like it's always about being the really, really problem directed and like, you know, following the so-called Feynman methodology, where it's like, write the problem down, like think very hard and then solve the problem. So I think like, if you really understand the problem that you're trying to tackle, and like you're not just, you understand why it's painful, you understand the different parts of it, you understand different, different approaches that have been taken. I think once you've really done all that work, usually this, usually the solution or idea is like almost the easy part.

42:40It's like, it comes from that, that deep understanding. happening so to me like i think almost all of my good ideas have come from just like really trying to get it like why why is this so hard though and just like maybe being more persistent and more curious than than other people are in that part whereas i think a lot of times it's just like people want to start with the blank slate thing or the thing that i'm doing uniquely and it's really easy to lose track of why you're doing it and how it ties back to what you're trying to do so definitely uh some people work with me on the techno side get probably find me annoying because I do what my PhD advisor used to do, which is like, you know, needs more examples, like, you know, need to understand the pain of this better, you know, show me why this matters or like that this addresses everything and like insisting on that before going into the solution phase.

43:24That's actually a very good framework or way to approach business building, right? Because one of the biggest problem in tech and crypto is people who are building solutions to problems that don't exist. I'm building a solution, but there's no problem out there. Yeah, yeah, yeah. It's 100 % true, Ray. The original sin of the crypto space is that you have one slam dunk use case, which is speculation, and it clouds product market fit. So, you know, people think they're act like they're trying to solve one problem or think they're trying to solve one problem, but then it's clouded by this other thing going on.

43:56And so I think in the crypto space, it's especially hard and especially important to really be problem focused and to do things because you're making progress on the problem, not because of some side signal that you weren't going after or that um other people are pushing you to do with these sorts of things so yeah it's a it's an especially big challenge here i would say so focus on the problem even more and understand the problem and understand why the problem is so hard yeah yeah exactly and why other things and why other things haven't worked because if you if you don't understand what however the people were pushed it you'll probably end up doing the same thing or doing like an incremental version of what someone else has done and so i think yeah yeah for me creativity comes from understanding it deeply enough to be like yeah but no one's poked at this facet yet or like they tried this but you know maybe they thought of that yeah the really uh touching on the sides of the elephant or whatever the right metaphor is how do you avoid analysis uh paralysis by analysis for example in the in the example of um facebook they probably told you okay we need to i mean you you define if we need a new programming language or not for that.

45:02But we need to ship. Yeah. Hey, we have a deadline. We want to get this out there. It ended up not working out, but you have time constraints, probably budget constraints. So you can just analyze everything forever. Yeah, yeah, totally. And I think you could easily spend seven years designing a new program in LanguageDee if you didn't have these sorts of constraints. So I think having deadlines helps. I think having deadlines is basically the only way to do it. And then I think there, it's like, you know, figuring out because I have this deadline, with Libra, we had just enough time to take the bold move of designing a new language.

45:37If it's like you have one month, it's like, okay, you're going to use the EVM or, you know, something else that's there. If you have two or three months, maybe you could try to retrofit an existing programming language. If you have six, well, you could do something new, but you better get started soon and you better have an approach for doing it incrementally. So, you know, for me, I was like, okay, I know the first thing people are going to ask is, how do you represent coins and new coin transfers? So I make sure I built out that part of the language first and had sort of sketches for the other bits but maybe we didn't have to have them implemented yet or you know we instill a flexibility in the design from what we learned in the first part so i but yeah i avoid it by trying to avoid analysis paralysis by having an idea of the big picture of what we're trying to do but then always trying to plan out incremental steps where not only can i make progress incrementally but i have i learn a lot from the the first things that i do and have the flexibility to change things later on uh yeah you always want to down scope the problem to sort of the minimal thing where you can you know try it out and get feedback whether it's from you or from users or from from other people looking at the design or whatever else the the most risky projects are the one where someone goes alone and does something for six months without asking for feedback and then comes out it's really scary for them coming out of that room that they might have wasted time they also feel safer along the journey right you're just there in your room you're doing your thing so you don't feel like you're too too much at risk yeah Yeah, and I think that's why some people, like, why there's a tendency to operate in that model.

47:04You know, there's a thing from Google X that I think about a lot that I think makes a lot of sense and that is, like, against human nature to do, but it's, like, so important, where it's, like, you know, if you want to have a monkey stand on a pedestal and recite the works of Shakespeare, you do the monkey first. You know, you don't spend all the time building the pedestal and making up the most beautiful pedestal and making sure that, you know, the monkey can be in front of the microphone and stuff. It's, like, you do the part that's most likely to fail first, the riskiest part. and like even though like as a person you want your project to keep going it's like you really got to go after like the hardest and riskiest bits first but then also get incremental progress on them so i try to think about that principle a lot and this is not a very this is a very entrepreneurial way of seeing things right and it's necessary in in startups but it's probably not the most natural way to think for an engineer yeah i mean for an for an engineer i think i think it depends i think a lot of projects just don't have that either they don't have that much risk to them or most dangerously you think that the project doesn't have that much risk to it and so you know you just approach it wherever doing the parts that are most interesting first but i i think like even as an engineer with something that seems straightforward i mean you see it with sort of government software projects or these sorts of things where they're large it's like there's anything with software has a lot of inherent complexity and there's going to be risks and so i think like engineering should be approached this way too.

48:23Like, really try to figure out what the hard parts are going to be, see how much you can get a handle on that early. But yeah, nobody wants to fail and somehow it feels better to be a zombie for a long time than to like fail right at the beginning. But, you know, if you have limited time, you really want to do that. And we all have limited time, right? We mentioned before, started with a lot of blank piece of paper. We talked about a concept called unstructured thinking the other day that you like to use what is that yeah so for me um the you know i talked about my path as an athlete like running is the thing i grew up doing like in high school and college and still do still do a lot of today and so i'm spending a lot of time every day i think probably more time than most people without having a phone or headphones or being in front of a computer or talking to other people but you know just like running around and you know you run the same routes or similar routes every day and your sort of your mind drifts where it will uh and a lot of times i end up you run every day like six days a week or so um sometimes seven but yeah five or six um so yeah it's i it's not like i run out and be like okay today i'm gonna solve this problem on the run but you know you're running and then like there's a song playing in your head and you know you see a bird or a tree or you cross the street or see somebody and then like you know something will pop up to like a little corner of like something you were thinking about or you'll be trying to think hard about something you'll be like but wait why was i thinking about that thing like you know zoom out like what's the purpose of that like why not do it this way and so i feel like i end up solving a lot of problems from making a lot of progress on technical problems business problems like personal problems from having that time every unstructured time of thinking reflection every day i think other people get to the same or similar place via you know meditation or some other thing but for me it's like that practice of running even though like i don't do it for that reason like i definitely find that that's some of the most productive time of my day.

50:19There's a book called Psycho-Cybernetics that talks about something similar, right? It's more, you envision, you have a problem, you envision the goal, and you just let your subconscious, because it's probably 95 % of what happens in there, do the work. Psycho-Cybernetics, I like that term. I'm going to use that now to describe what happens on the runs instead of unstructured thinking. It's a lot cooler sounding. It's what happens in your subconscious mind, right? Which is always solving problems, even when you sleep, people and just doing things without realizing. Absolutely. Why does unstructured thinking work so well?

50:56I think it works well because, you know, it's just so easy to get in a rut or fall into a pattern or sort of like a loop when you're trying to do something. And so I think it works because, like, you're not forcing yourself to do it. It's sort of like the unconscious, like as you're saying, it comes up unprompted. and because you don't have distractions. I think that's maybe even the most important thing. You know, this is a problem for all of us and, you know, it's just getting worse all the time. Like there's so much stimulation distractions like in your pocket on the screen in front of you, like how many like tabs and windows and, you know, and we live busy lives with, you know, families and friends and all these sorts of things.

51:34And this stuff is wonderful, but there's not a lot of time you have to focus on just one thing or, and it might sound a little weird to say like, I'm focusing on just one thing while you're like running around. But that's the thing about running a route that you do all the time where it's like there's sort of an autopilot. I don't think about where I'm going and it's like very comfortable because it's like, you know, a pace that I'm used to and a distance. And then so it really is just like freeing your mind to do that one thing. I think that's why it works, but it's hard to know. What types of problems are best solved with unstructured thinking?

52:03Hard ones, but, you know, more specifically, I think something where you either need a reframing, like you're like, I'm really, I'm really in the weeds of trying to do this specific thing but really you're like misguided and trying to do this specific thing and if you like step back and ask why you realize you should trying to be you should be trying to do this other thing instead or I think things where you need to connect ideas or solutions from disparate areas like for me and this is with the research problems like I was mentioning before like in these conferences like when you're a researcher you have the big conferences and you read the titles and abstracts of all the papers that come out and there's like many papers that you've read in your lives across these very different topics and ideas so sometimes you'll be thinking about something and you'll be like i feel like i've i've heard something similar to this before but like i don't really know what it is then you'll see like oh it's weird like this person working on this quantum programming language had this unique feature that i didn't really think about as relevant to this problem because i'm here working on a smart contract programming language but i see like the thing i'm running into is actually something that they did so maybe i should go back and look at that paper or i'll just jog my memory of what that was and then you know you go and you make that happen so i think those are some of the modes that are the most effective.

53:14So this unstructured thinking helped you build the move language, which is used by three, but not only. Yeah, move is growing. There is a new, move is growing, there's a new generation of layer ones like Aptos movement that use your creation, the move language. How do you feel about brand new protocols that are worth billions of dollars and built using the language that you created? I feel great about it. I mean, this was always the vision for Move where, you know, we think that Move is a better way of writing smart contracts. We think it's a safer way. I think that smart contract safety is one of the key things that's holding back broader adoption of crypto and that's stopping crypto platform growth.

53:58So, you know, I want to see as many platforms as possible using it. I mean, with SWE, like we have the team that worked on the Move language here. I think we're the ones that are driving it forward and sort of setting what happens. but like I always love every new platform that uses Move. And I think if everyone used Move and there was no more slitting the EVM, that would be not good for the space. I'm obviously very biased in this, but I feel proud when there's new platforms using it for sure. Why is the Move language the best programming language out there to build any blockchain application?

54:29Because safety is the most important thing about smart contracts and Move is the safest language. I think it's really as simple as that. And then, so I think that's like the big picture sort of like business for a CTO pitch. But then I think for a programmer, they like it because they try it and they're like, oh, this understands what I'm trying to do. I can be more productive with this. I can focus more on the business logic and less on low-level details and not worry as much about security. I think they really feel like it was made for them and it understands them and it's sort of a good thought partner.

54:56That's what developers tell me anyway and also what we shoot for. The co-founder and CTO of Miston Labs, company behind the SWE network. What is the SWE network? if you had to explain it to your mom? Yeah, so I'd say the SWE Network is an experimental developer platform. Think of the iOS app store in the early days when people didn't know what to do with mobile apps, so they built an app that you press a button and it farts or something. That's the stage we're at for smart contracts today. But then it's like, oh, there's really a lot of potential here in terms of what people can do with this, the problems they can solve.

55:35And there's a lot of interesting experimentation going on with people putting stuff out there and seeing what works and what doesn't work. And for us as the platform developers figuring out what else people need, I think that's how I'd explain it. Why is SWE the best layer one blockchain out there? Out of the sea of layer ones that will have emerged in the crypto industry over the past few years. Yeah, I think it's the best because it's the best for developers. So I think first of all, it's the fastest. Like people, end users care about that. Developers care about that. I mean the fastest in terms of the time It takes end-to-end to send a request and get back a response.

56:09I think it's the fastest to get started as a developer and sort of the fastest to get started, the fastest to iterate and to do things the safest. And I think it provides the most features and components of the stack end-to-end. Like, you know, with Waris, which is one of our big focuses right now, like in any conventional application building, right? Like you have your disk, you have RAM, and you have CPU. And with other blockchains, I think you only have RAM and CPU and there's no disk. And if you think about what applications you can build if you don't have a disk, like a lot of things are going to be off the table, right?

56:40Like, you know, you can build a calculator, but you can't build a machine learning model. You can't build, you know, almost anything on your phone. Like everything needs persistent storage. So that's really one of the things we're trying to differentiate on is like in addition to, yes, the speed, yes, the developer experience, yes, the scalability. It's just like fundamentally different capabilities that you need as an application builder trying to build a rich app that is trying to, you know, do real things and provide real value. you mentioned decentralized data storage my question is what's possible on the street that is just not possible on other blockchain ecosystems yeah so I think with Walrus anything where you want to create you want to pay for pay for the creation or consumption of data from a smart contract which I think is an extremely fundamental thing for and you need a concrete example for normal people to understand hey why do we need this yeah so say i'm a blogger i'm creating a sub stack like blog platform i'm creating a blog post and i want people to be able to subscribe and then to pay me and they should only be able to access the content if they pay me um so i think in order in order to do that you need a support in a what they're like platform you need a surprising number of things you need the identity and the payment rails that's the layer one you need to be able to store the posts that's the that's waris you need to be able to encrypt the posts.

58:00That's this forthcoming thing that we're working on on top of Warris. And then you need to be able to say, when I exchange the money, then that person should get access to the post, but they shouldn't get access to it beforehand. And then also, it's not like that person should be able to get access to everything I've ever done. They're paying for this post specifically. So that's a lot of different moving parts. I think a lot of people can do the identity and the payment part, but they don't have the attached storage there. They don't have the encryption. And they definitely don't have this exchange of like, oh, add, configure the access control policy for the storage on the layer one.

58:40This is... So this is like what we call a role-evaled security? Like the security of the different, what people can access. Sorry, what security? to people who are allowed to access certain things yes yeah access control policies we would call that or that's one term yeah we talked about energy management yesterday yes obviously you're on this sweet journey I mean not only you're missing lab journey this is a multi-year if not multi-decade journey yep you're the CTO of a company that raised hundreds of millions of dollars desert of pressure. You don't look like you are stressed out. You look pretty chill.

59:32Desert of pressure nonstop and it's a long journey. How do you keep your energy and enthusiasm during a very intense journey in the last years, if not decades? Yeah, so I think you're right. I think I'm not stressed. You got to have fun, right? And, you know, and I think this is a really fun place to work and a really fun industry to be working in. And I think it's all about like, you know, making sure that you're doing things that you find enjoyable, that are fun, but that are also really important for the industry and for the ecosystem. I think for me, I mentioned like the way I am as a person is that I'm very curious.

1:00:03I like doing a lot of different things. I'm very experimental. So I'm like pretty happy doing a wide range of tasks. But like for anybody, including myself, like there are many aspects of running a business or doing things where, you know, it's going to drain your energy and it won't be the thing that you like the most. and like as you scale and grow there's going to be enough of those things you could easily fill your day doing all of those things and if you do that you will not be a very happy person and some days that might be the most important thing for the business and you just eat you just eat it and go for it but in the long term like you're going to burn out if you do that you're not going to be happy so i think it's all about just figuring out that right portfolio of things to do and i mean maybe even more generally you know the way i came up my career is like you know you're an ic you know you're working on some coding project or software project, you have some list of things you want to get done for the day.

1:00:49I write at the beginning of the day, I burn through that list, I'm done in the afternoon, then I go do more. And I feel very happy with myself because I've met my expectations and exceeded them. When you're running a company, it's not like that. Maybe it starts off like that, and I still start off my day writing off what I want to do. But then the way it works is you have the intention for what you want to do, then something comes in and it's very important, or then there are always these sort of distractions, or the things you want to do are very long-term, so you can't finish them in one day.

1:01:12So you have to learn how to be satisfied with... How do you do that? How do you do that? It's so tricky. Like the ultimate for an employee, the ultimate example is maybe working in business development or sales. Yeah. Because the sales cycle are very long, right? Yeah, yeah, yeah. So the kind of joke is always, once I close this deal, I'm not even happy anymore because it took so long, right? Right. But when you build a business, it's this, but on another level. and so it's very easy to basically never really be happy because there's no small things to celebrate yeah how do you do that yeah well you have to figure out how to incrementalize your goals and then take satisfaction and incrementalizing them and you know for me it's like because there are just so many things that happen you never get to all the things you really should get to today you have to learn to take satisfaction in dropping the right balls instead of not dropping any balls uh and i think that's a that was a personal transformation i think took a while as Misson got from being small to like being a little bit bigger but I think now I'm very peaceful especially recognizing that other people don't and can't expect you to to deal with everything that they try to put on their plate they as employees and the ecosystem like they want you to be focusing on what's most important so they're not going to be upset if you don't get to their thing or you pick something else like they trust you as a as a leader to do the right thing so I just try to trust myself and be worthy of other people's trust to to do that while also keeping my uh keeping my energy how did you learn that just learning by doing a trial by fire yeah but you know i think also you know like i've had a lot of like really excellent mentors um like at through my career at facebook you know i mentioned my parents too like i think my dad has always been very much of like picking picking work that you find enjoyable so it doesn't actually feel like you're working uh and you know he follows that example himself he retired and then he recently like unretired to go back to work one day a week you know he's a cardiologist because he loves that so much or one of my mentors at facebook this guy peter ahern is a researcher he always encouraged me you know as a software developer like who's with a research background like yeah you could do this development stuff all day but you have to pick those portfolio projects that are gonna have impact for the company advance your career versus stuff you're interested in uh and a lot of times those end up intersecting in ways you don't expect so i think it's yeah both of those things or things that I think about and helped.

1:03:31But it was a lot of trial by fire from just doing it and having to deal with a company that's growing and being successful. How much of what you do today is on the bucket of I love it and how much is on the bucket of I have to do it? I think it's like 90-10 on a typical day. I mean, I'd say it's very high variance. I think there's a lot of days where I'm like, everything I did today I loved and it was awesome and I don't even want to go to bed because this was so great. And then there are some days where it's like, wow, this was one of those days where I was going to burn down a lot of not so pleasant tasks and you know that it's not great but I think you know even things that I I don't get I think like crises or stressful situations you can always find humor in them or you can focus more on like trying to help other people be calm and de-stress and like you know I think that's something I do well so that park it's more just like when you have tasks that are the grind like I've agreed to produce this artifact and like I'm excited about doing it but I just don't want to have to do it on this deadline that can still be hard sometimes.

1:04:30But no, I think my average day is like super high satisfaction tasks for the most part. Maybe it's because also of your hobby that you developed in the last five years, surfing. That makes you even better. So you said 90 % of what I do is amazing, 10 % not that good. You add the surfing on the side, like you're at 120 % of pure happiness. Yes, exactly. and surfing is kind of like the opposite in terms of the distribution where like the activity is like 99 % paddling around and getting tossed underwater and you know waiting and then like 1 % of like the best possible feelings so maybe having that reversed ratio and like high variance also contributes but yeah it's something I've really gotten into and my wife also does it and you know so it's a great thing for us to do together and it's just yeah it's just incredibly incredibly fun incredibly relaxing just like a great way to like explore nature and like you know guide your travel and yeah it's like people haven't tried it should really try it I feel people say like oh like the water's cold or there are sharks or things like that but man it's so worth it you said surfing makes me think a lot yeah why yeah I mean it's a different you know talked about the unstructured thinking with running I feel like surfing is a little bit different where you can't let your mind completely untethered and like you know sort of autopilot like i talked about because you're going to end up uh on the bottom but it is like you're very focused but not in like a like you know okay look look for the wave make sure i'm in a good situation like get set up but not in a like scared or like high stress way kind of so i think um and then there's this emotional variance of the you know riding a wave and feeling super happy about it versus you know trying not to trying not to get held underwater.

1:06:21And so it's like, yeah, thoughts more like pop up in the spots between the intensity that's characteristic of the activity, I guess. That's how I would explain it. Servers are famous for not being articulate and going dude and bro and tube and stuff. And I feel like I'm doing that now, except with the thought pattern. So I apologize for that. As long as you don't do that in the office. When you get out, Hey dude, hey bro.

1:06:50What's something that you believe in that most people would not agree with? Yeah, let's see. What do I believe in? That won't get me in trouble. Or, you know, I guess it's fun to get in trouble a little bit.

1:07:07I guess these are maybe boring or nerdy opinions, but whatever, it's something I believe strongly. So, you know, there's also a software thing, but not about smart contracts, where there's this notion of memory safety in programming languages. You know, so languages like C and C++ don't have memory safety. And then, like, more modern languages like your Rust or your Java or something would. And there's this interesting... Sorry, this is really nerdy, but we're going to do it. What is memory safety? Yeah, yeah. So memory safety is a property of where things have a clearly defined boundary. and the data sits inside the boundary and programs aren't allowed to go outside of it.

1:07:47So a classic example might be there's a list, you have, say, a contact list and you're allowed to look at yourself in the contact list, but you're not allowed to read outside to see who other people's contacts are, that sort of thing. And so if you have memory-safe languages, it's very easy to ensure these properties. And if you have memory-safe languages, you can, but you have to do it very carefully. And if you get it wrong, the consequences are very bad. So most software vulnerabilities outside of the smart contract space have led from using these memory unsafe languages and, you know, people thinking they can get it right and getting it wrong and then like costing.

1:08:23Definitely, I think, tens of billions or trillions of dollars to this point. And so I think like from a regulatory perspective, we should do more about programming language safety because it's one of these things where it's you're using this tool that we think people can be careful and get it right, but they don't. And when they get it wrong, everybody's like, it's not just the programmer or the company that suffers. It can be like the Equifax hack. You know, this happens because like, you know, this happens because like someone uses a memory unsafe language. Hackers get onto the machine and then they can do more with that access than they're able to, than they should be able to.

1:08:54So I guess my unpopular opinion or something that most people don't think is, I actually think there should be more regulations about language safety and not using these things that have been that we know after many years are just not quite safe. two questions what was the ECOFAX hack and what was the result of that yeah so and just the other question is are the people who should make these decisions qualified enough to make these decisions yes it's a big problem I mean now it's better with Trump electing David Sachs and all these guys basically it's like Silicon Valley takeover of the government but otherwise it's a big problem we had I mean you worked for Facebook we had so many examples of like Mark Zuckerberg just talking to people sure who don't understand what the fuck is going on right yeah yeah yeah so what's the GoFacts action and are the people in the government or the people who are supposed to create these rules qualified even qualified to make these decisions yeah yeah it's a great question so this was one of the AgroFacts is one of these credit agencies in the US like you know they maintain credit scores for they maintained credit scores for people so they ended up having a lot of private information they had a breach where someone was able to get in and like basically steal lots of people's security social security information credit information like all of this kind of stuff and you know had to was due to a variety of factors but at the end of the day it's all these sort of hacks always have the same recipe it's like someone gets access to a machine then they can do something and they're able to get access because they exploit a memory safety vulnerability or because once they get on there, they find one that they can exploit and do something.

1:10:35So that's what that was. And, you know, it's like everyone in the, like a credit bureau tracks your credit info, whether you want them to or not. It's like everyone in the country is affected basically by this, even though they didn't write the bad software or sign up to be part of the service for these sorts of things. And, you know, that's not the only thing that went wrong, but it's certainly something that aided it. And so the second part of the question, do people, yeah, do the people who would make these decisions have the right expertise? that one that one is hard um because yeah programming languages like this is a highly technical thing you know i think the you have to have people asking the right questions and then like bring in the right experts to do this i think the right question asked in this case is just like why do we feel like all software is going to be like inherently hackable and unsafe like is that a truth of the universe or is that just like a state that we've gotten ourselves into by making a bad set of decisions and what can we do to undo that that axiom basically and i think if you asked that set of questions, you would end up bringing experts that might suggest this as one potential mitigation.

1:11:34Or they could, you know, have a 20-year certification program to become a software developer that kills all innovation. There's a lot of ways you can do this wrong, too, so I'm not suggesting regulation as an answer for anything. I think, and I guess I shouldn't even say regulation, I think we should be more thoughtful about things that just seem bad and unfortunate, and how we can actually do it differently with better core technology or better programming language choices in the case of my particular passion area. Talk about regulation and crypto. What's the right dose of regulation if you don't want to kill potential?

1:12:13I think the right answer is having some. And I think that's been the problem in the US up to this point is that there have not been clear regulations for folks to want to operate in this area. and it's more of a regulation by enforcement kind of thing. And I think that's what needs to change is there need to be guidelines and rules that people know how to follow and to stay within and those need to be enforced. And I think that can be a great starting point. So I think right now folks are talking a lot about stablecoins and stablecoin regulation. I think that's an excellent starting point as something where there need to be more rules.

1:12:46It's clearly something that has broader utility. It's clearly something a lot of people are operating in with different levels of with different levels of sort of carefulness and I think it would be great to codify that more. What's your biggest prediction for the next 24 months? Ooh, is we related, world related, war-related? Anything related. Anything related.

1:13:2624 months is a long time. But I think... It's interesting you say that. Because usually I say 12 months, and I was told, this is not long enough. This is not long enough. This is too short. So I'm like, okay, I'm going to do something that gives a bit more room for safety. So I think, yeah, I like that technique. So I think in 24 months, if we do our job well, I think the number of developers that there are in crypto today has been like a little bit flat, like around like, you know, 25 ,000 over like the past couple of years. I think that number will be at least 5X. I think most of those developers will be using Move and Sweden.

1:13:59That's my prediction for 24 months. What do you mean by if we do our job well? I mean, if we as Mists and Labs execute on our plan. Can you tell me a bit more about that? How do you get 5X more developers in the crypto space? and move them, pun intended, to the move language? Yeah, so I think getting non-crypto developers into the crypto space, I think the key thing is showing the value proposition that a platform like Suite can provide without having them have to go all the way in. So, you know, something that we do a lot is we try to have SDKs and APIs or these programmable transaction blocks, which we can talk about more for being able to use Suite from the front end.

1:14:47And so I think like we should make it easier for people to experiment with crypto powered utility without having to, you know, make the pivot to be a crypto app or crypto developer, that sort of thing. And then I think once they do that, like if you use a little bit of something and see that it's useful, you want to customize it, you want to build on other things, you want to see what else you can do. And that's how you get all the way in. So I think we need to have clear value propositions for what folks outside of crypto should be doing. Like, you know, I want to experiment with doing micropayments or, you know, invoice arbitrage where like instead of billing people monthly, like bill per usage, I want to experiment with ownership and in my in my game and then have nice APIs for those things, get them to try it out.

1:15:27And then, you know, don't sell it as like, you know, you strap lasers and do this. Just sell it as like, experiment, see if this provides value for your business, iterate with it, you know, see if it can work and throw it out if it doesn't. And then just like do that at scale and then show enough utility that you get lots and lots of people in the door. That's the high level idea. That's probably where the teams, the SUI teams and Mitten Labs teams background in Facebook helps a lot. Yeah, absolutely. I mean, we know how to build developer platforms. We know we've worked with apps that serve billions of users.

1:15:58We know how to scale and do growth. We know how to be ambitious. Absolutely. From the founding team and a lot of other folks, this background helps a lot. Amazing. Thank you so much, Sam, for doing that. Thank you for taking an hour, an hour and a half of your already wholesome day. Make my day wholesome. Thanks, Kevin. This was a lot of fun. I generally enjoyed the conversation. Amazing. Thank you so much.

1:16:28Upro