ep 19 – Programming Languages & Crypto

Transcript

welcome to web 3 with A6 and z a show about building the Next Generation the internet from the team at Asics and see crypto that includes me your host sonal choxie this show is for anyone seeking to understand and go deeper on all things crypto and web 3. whether developer Creator Builder business leader or policy maker and we're now back with an all new season of episodes today's episode is actually all about programming languages on crypto and it's for both existing smart contract programmers as well as other developers seeking to enter the space and for anyone who's just curious about how programming languages evolve and come into existence as well our special guest today include Sam Blackshear co-founder

and CTO of mistin labs which is building foundations for the decentralized future of web 3. Sam has a long history in programming languages from his PhD to working at Facebook to creating and being one of the authors of move and open source programming language for building smart contracts and we'll talk more about that and throughout this episode we also have NOAA Citron smart contract and research engineer here at Asics and Z crypto who also recently authored a light client for ethereum called Helios and he won a challenging gas optimization challenge with another partner here which we briefly allude to and finally we have Eddie lazarin head of engineering for Asics and Z crypto before that he was in software

engineering at Netflix as well as data engineering and data science at Facebook as a reminder none of the following is investment business legal or tax advice please see asicsnz.com disclosures for more important information including a link to a list of our investments stick with us for the fun and fascinating ride in this episode because we cover everything from differences and similarities in conventional programming languages versus smart contract programming we discuss and debate the unique constraints and opportunities of blockchain games and also touch on topics such as formal verification governance and Community tooling cross-platform adaptation and much much more but we begin with the history of

traditional programming and the first voice you'll hear is Noah's followed by Sam's and then Eddie's we want to hear a little bit about how the history of programming affects the history of smart contract programming like because there's I feel like three things going there's like traditional programming smart contract programming and then there's move and all three of those things have its own history right yeah I love that framing I mean people with languages like oh languages are about like designing syntax or about making people really happy and it is about those things but it's not just about those things so I love this big picture framing yeah well just building on that in traditional programming there have been all these Trends over the last 20 30 years over the years traditional programming languages have changed there have been different topics that have been trendy and come and go there was a

long time where dynamic programming languages and being very loose about type checking and types in general was kind of the way to go it was thought like it's more ergonomic just to jump in forget the types forget all the craft just like write the code but more recently it's been the way to go to think really deeply about type systems and static typing and compile time checks and things like that to learn the most you can about a program right before it even runs there have been these Ebbs and flows however for smart contract programming just because it's so new we haven't had this type of history in smart contract programming which I think is very different and I think move is some of the first evidence

we've seen about how different it is and how differently you can design a language to accommodate that I'd love to get into what are the types of things that we expect to change like what are the potential static versus Dynamic typing type of Topics in smart contract programming that maybe haven't yet emerged just because there's really only been one language there's really only been solidity yeah absolutely so my take on programming language design is that programming languages are problem solving tools so a lot of the trends we've seen in language design is about like what new problem arose and what sort of language came in to fill that Niche and then like what was important for that particular kinds of problems so you look at say JavaScript for example

like the silver is to fill the nation these web things and we need some programmability Beyond just static CSS and we need a way to talk about moving around Dom elements and communicating with the back end and all these sorts of things and in that environment the thing that was the most important was dynamism web page is constantly evolving for many reasons like you don't just want to be refetching or redoing everything after the fact so both in the language and the Frameworks built on top of it like things like react it's all about the dynamism it's all about reactivity it's all about just making things as flexible as possible and so that's one example of a language Trend and why it went that way and then you mentioned you also see a move in the other direction like static type systems safety more predictability and I think a lot of

where that Trend came from is also with program in the web less client-side but more on the back end we started off with a Ruby on Rails or python or all these like very Dynamic back-end languages even JavaScript itself to some extent and then folks started off by building these very Nimble startups that worked well because they could Leverage The dynamism of these languages to build products quickly and to iterate quickly PHP and then how Facebook is another example and then over time as these matured from these small startups into into much larger companies that discovered hey like it's really difficult to maintain these code bases to refactor these code bases to keep things safe it's great for iteration speed But as time goes on you actually really want the static types to be able to have a large number of programmers working on these code bases and to keep

them functioning reasonably and so you started seeing a lot more interest in static type systems both in languages to be used for back-end programming and also retrofitting type systems onto existing languages like they did with hack at Facebook like stripe has done with the sorbet type system for Ruby even for python like there's an IPI and so there's a line of research for my field Randy Johnson said types one like there's this long debate of dynamic types for static types and types one even for the languages that are statically type by default like everyone has some sort of way to retrofit Types on top and I think we really understand that you can have the flexibility of dynamism but then bring the types in once you actually know what your code is supposed to do and you want to be able to maintain it so how does that connect

back to the shift to Smart contract programming again Sam yeah so working that into the smart contract space a bit there's a different set of Trends where with the evm there's the first entrant in the space of smart contract languages so folks didn't really know like what do people want to do with smart contracts how do we program them or any of these sorts of things so I think flexibility was much more important to try to know what kind of experts have you needed to discover the use cases and I feel like now we we kind of know or at least we have some idea of what the building blocks or sort of the trends are like with smart contracts they're extremely domain specific you sort of Define templates for assets you define policies for transferring assets you check access control and permissions and that's

basically it you don't do other things you're not going to use a Smart contract language to write a compiler or to write an operating system or any of these sorts of things so they're very very niche in what they do compared to a general purpose programming language no I think that people undervalue how even the erc20 standard occurred a long time after it was possible to program the evm even something that we take for granted is such a basic building block of writing a program in ethereum and I just don't see any evidence that it was obvious before that what the most basic things were so you're right that now that you can kind of take for granted I mean I think of types and those things as circumventing writing types in a

programming language is like being able to take a degree of technical debt right if it's a small you just want to move really quickly and the code is something that you can toss away that debt is totally acceptable but what's funny is you framed it in terms of the size of the startup or the size of the company a small company you're moving quick everyone kind of has the whole code base in their mind that type of debt is tolerable but when it's really really big there's tons of people changing the code they don't know what consequences the new types of objects and systems they're building have putting that into the type system makes it so that you know what walls you're running up against as you're writing code in an explicit straightforward way as opposed to accidentally creating a

pane of glass that someone's going to crash into later but what's interesting is that the set of constraints is different but becoming more obvious in blockchain programming for example like you were talking about being able to prevent copying being able to set a maximum supply of an asset like these are constraints that are really important to maintain independent of the size of the project there are constraints that are important to maintain for the sanity and safety of the project and understanding what those boundaries are means you can now create programming languages that allow you to enforce them that's kind of how I think about move is as we've learned about the types of constraints we need to do

things properly we now have the ability to include them in the language themselves so I do see it parallel with the way types have won as you were saying you mentioned that types are a lot of times for like the sanity of the program and safety of the program you guys said that Dynamic might be good for small things but as I grow you should be static I kind of disagree I think medically synthetic types are I think this might be a hot take it's for the sanity of the programmer you know that's right the scariest thing I've ever seen is when I you know I've got one of my keybinds is control K and it tells me what the function signature is and when I write python it terrifies me I look at a function signature I just get names of the parameters I'm like what do you want

from me here like that I can't believe people accepted that that was a great way to write code that was never well what they were accepting was just the tacit they were taking for granted that they can maintain the requirements of the system in their mind and that is probably not an acceptable thing to take for granted in a Sprint contract context well I mean I don't even think I could take that one for granted in a 100 line program yeah I can't keep that many things in my head at once I think you're totally right about that I think like that mindset has kind of evolved where like for it's like oh type systems are to protect programmers from their colleagues once you're once your startup gets too big but now it's more like oh it's actually to protect me from myself and in the smart contract setting it's

to totally protect me from attackers and I think that's really the thing that's actually super different here because a normal program like you don't deploy it in a setting where the attacker is subject to the type system like the attacker is deploying some machine code or they could write in a different language and you just protect yourself via a firewall but here it's like I write this nicely typed object and it's going to flow into an attacker's code and maintain its integrity and the type system has to have my back on that and as you were saying Eddie it's a great point that gives you a different set of things you need to enforce like preventing copying that's not something you think about with a normal type system or preventing dropping or making sure that you use a value in a certain way or destroy in a certain way these

are because we're studying smart contracts and trying to provide the type system that makes sense for those use cases these are the type of things that we end up putting into move and probably into future smart contract languages fascinating actually you guys let's talk more about other differences between traditional programming and smart contract programming but before we go further could you guys give me a quick lay of the land of what languages are at a smart contract programmers disposal I actually think we need to orient the big picture here a bit because you know I like to kind of have the map and the terrain like what's out there solidity Viper Etc Noah can you take this one really quick yeah so I guess the basic lay of land is that at the moment if you want to write a smart contract you're gonna write it in suddenly almost always

unless you happen to be in one of the couple of other like smaller ecosystems if you're in the Solana ecosystem you're going to write it and so long it's like like a rust thing right if you're in the cosmos ecosystem you're using existing programming language if you're in the starkman ecosystem you use Skyrim but for the most part if you're just like default and if I'm giving the advice like hey I want to learn how to write smart contracts say okay go learn some salinity learn to evm you might also want to use Viper the only like downside is Viper is newer it's potentially more exposed to bugs I remember one a few years back they found a bunch of bugs in the Viper compiler when they were verifying the EFT deposit contract which uh the person who found that was actually now works at a16z it's day June

that's so cool yeah because Adrian's like a formal verification Maxi like he studied that and I guess that's the reality is that you need to learn something what's even a little bit worse about nuclear solidity is that if you want to be really good you really need to learn devm all of the best smart contract Engineers I know no vvm to ridiculous level to a point where you could say how much gas each individual op could cost and they can tell you the exact cap Mission with the gas costs and that that's sort of the world we live in at the moment there is maybe a point worth making is that you can always as a software engineer learn about the machine that you're running code in there's a lot to learn about the environment you're programming in but in smart contract programming in particular

the environment is very rich and the environment is very complicated and there's a lot of context you need to understand that have almost nothing to do with the language in itself has to do with just what is around you what objects are around you how are different pieces of code invoked that's a really strange thing it's much more strange than in other programming languages I would say the closest thing I can think of is thinking about the Dom when writing JavaScript for the browser as opposed to JavaScript in itself but yeah it's even more involved than that and then is it true that like the closest analog to learn solidity is people who know JavaScript everyone says it's JavaScript because function like you use

the keyword function right and like they're like oh JavaScript uses that as well but unfortunately there's not really that much like like a syntactically solidity does inherit a lot from JavaScript and if you squint or are having a really rough day it may look similar but it is not it is not similar it's just the virtual machines environment is just so radically different that there's very little to preserve yeah so there any analog that's close yeah I think there's no direct analog I think if you're familiar not with say JavaScript but with wasm and sort of like trying to write wasm in a setting where you care a lot about isolation like in serverless for example like they use was may try to write like containers that do independent things that communicate with each other a little bit but not too much that's maybe

the closest but it's still not very close at all it's a very different mindset false similarity can be dangerous yeah maybe related to just big mistakes in programming language history I don't know if there's things that you think were just like really bad paths in the idmas that we went down in programming language history related to blockchains or not just like are there just like awful paths we went down that's such a good question that's a NOAA question by the way just I want to give Noah credit for that question go ahead so yeah that's a great question so 1977 was the year that c came out and was also the year that standard ml came out now standard ml is amazingly influential now like there's this ocamo language rust is super strongly influenced by Centerville move is super

strongly influenced but like those ideas have been out there for a long long time I think a lot about the alternative future where instead of C becoming very popular and very dominant like maybe folks pick up the ideas of standard ml like the strong typing the built-in safety and like where does the Computing landscape go from that so I'm not saying that that's a mistake but I think like that's ml seems so modern even today and just like to think about that alternative Universe I think is an interesting thing that blew my mind when I first found out just out of curiosity why do you think that see and similar languages that are just so straightforward so imperative they think about the computer on a relatively low level right they're not doing a lot as programming languages that's how I think about C why did we go down that path so

I think Hardware limitations at the time these came out basically forced you to UC if you were going to write really efficient programs or to push the boundaries of what you can do with Computing period I think maybe if you like fast forward the hardware you go on a different path but I think also functional programming is hard and it's sort of like counterintuitive in many ways I mean not that c isn't hard but I feel like it's easier to get into and then you realize like oh I've actually done this very very complex thing or this thing that's hard reason about but it's sort of too late now with functional languages there's a steeper learning curve but like once you get there you're like oh I can really reason about the pieces that I have independently and things work out nicely well I think if you think a lot about

how a computer works on a hardware level a language like C is more straightforward but if you don't know a lot about programming languages as such then sees more preferable but if you think a lot about programming languages then I think ML and functional programming and those types they have a lot more flesh like they have a lot more to them totally that's a fascinating observation that's the big picture answer I mean this is going to different more small scale like quote-unquote Computing or language mistake wait so like I'm sort of torn on this because the thing is I've always heard how great functional programming is done a little bit of it found it to be you know quite difficult to sort of rock my head around but the question I always have is if it's so great it never was able to

overcome the network effect of current programming languages like that it surprises me that it really hasn't but I will add that I think the great contribution that functional programming gave to us was that all the imperative languages we use borrowed all of its best thing like you just said rust is super influenced by standard ml but rust is a basically an imperative language right but it's got all the wonderful pixie dust that came from Sarah ml but totally I think that's really the thing is the imperative languages were too influential from 99 and then there was pure FP which as you say like isn't the greatest like it has its great ideas like in isolation each of them have their own issues and we're only really seeing true hybrids like Russ that marry them beautifully now and it's really changing the landscape so the one other

thing I was going to mention which is you know Tony horror calls the milder reference the billion dollar mistake and at the time he said that I think he intended to be hyperbolic but like I think it's very clear that's cost way more money than that no no it may be a lower bound yeah I was actually curious one question which you didn't really talk about about Innovation at like the virtual machine layer versus the programming language layer and how that like plays out generally over smart contracts as a whole yeah it's a great question I mean so I think people don't think about these distinctions enough like the difference between the virtual machine and the programming language I think there's been a lot of innovation beyond the evm and new virtual machine layers and then also like a lot in the source languages like Viper puff you know these things

are different and better than solid and interesting ways I think if move does what we want like basically becomes the wasm of web theory is the way we like to think about it then innovation of the virtual machine layer will happen but it will be slow and gradual in the sense that like the core is fixed and we add new things but you're not going to like blow it up and start all over whereas I think Innovation at the source language level is going to be quite significant today we only have one source language but it's very tied to the bytecode format but I can especially imagine that given the many different customers who are going to be coming to Smart contracts and where they're coming from given the emphasis on safety that there's just gonna be a lot of different things to try out the source language

level you know program since this is this interesting research area maybe you start by writing your move proof respects and then the synthesizer fills in the program for you or suggestion from limitations maybe your writing move in a very specific gaming context for something that looks like the scene hierarchy maybe it's in like python or uses python libraries but compiles to move by code maybe you're like Solana or one of these other platforms that's looking incorporating move but not incorporating the VM but doing it by having a compiler from move by code to the Solana backend format and then using the move Source language at the developer level so I think there's a lot of different ways I sort of think of it as like the jvm like the jvm is this beautiful like all-purpose virtual machine where it started off with just Java but it sort of the test of time and

now you have Scala you have groovy of all these other interesting ways of using those parameters to design different programming experiences that are very tailored to what folks are trying to do so basically I have a biased view on the vampire because I think that gives you a lot of room to experiment at the source language level how do you feel about all the alternative evm byte code languages like there's Fe like iron there's Viper these other interesting efforts to build more smart contracts sophisticated languages for the evm are you optimistic about those so this is different Source languages to compile to the evm to evm by code yeah so I'm not in that the reason when we started off at Facebook decided to

design move instead of we looked at building another source language the evm like we studied solidity we've studied Viper which is near the time we started the evm and we ended up thinking like the real I don't want to say problem here because that sounds judgmental but like the thing that makes it difficult to write safe smart contracts is how low level the evm is and how hard it is to have like typed values that can flow across trust boundaries and like Dynamic discussion these sorts of things and these are evm features if you build a better Source language you make it harder for the developer to shoot themselves in the foot maybe they can have more advanced verification But ultimately like what you get with move and what we think is important is protection at the by code verifier and VM level from other programmers and a

source language can't give you that that has to be baked into the VM and no matter how much you iterate on the perfect Source language for the evm which I think ability is great we could also do better than solidity but I think like where you get to with that approach just ends up being not as good as somewhere where you have these fundamental protections baked into the VM so I'm embarrassed not because I think Hof is very cool for example but just because like I think the end state is less compelling than insurance but can one of you make the counter case for like a Viper and anything else out there these things are important for the ecosystem yeah well it's a little bit hard to make the counter case because I've seen a lot of interesting examples where they've been able to write right

Viper that is much more performant out of the box that compiles to novel evm by code structures that just are really hard to compile to from solidity that just end up with great performance characteristics Great Space characteristics so there's a lot of space to improve on solidity but Sam's Point about being able to do type checking for more useful blockchain native types or smart contract native types in the evm that's just really difficult to solve at the evm level so I'm not sure I have a super strong case other than the fact that there's already a big Network effect for solidity there's already a big Network effect for

the evm and there is a good amount of space I think to bring some checks at compile time at Contract writing time to improve the experience for engineers who are writing to the evm you know think of it like we were talking about earlier bolting Types on to like python later with my Pi or improving the type system in BHP with HACC these are things that were added after the fact they're probably not as good as rust's type system from the beginning or Haskell or something but they're a net Improvement that allows you to have your cake and eat it too a little bit so there's a case to be made that there's fruit and new evm languages even if you can't get

to exactly the same level as building from scratch that makes sense you know Sam you've mentioned glass platform a couple of times and I think you mean that move has all these different flavors with different blockchains but it's also one of those phrases that means a lot of different things so can you say a bit more precisely about what you mean with cross-platform and also more broadly you know why that matters for the smart contract programming context yeah sure so let me start off with a Spiel so I think one thing with early smart contract languages and specifically the evm is that they overfit to the implementation details of the platform they're designed for like you know they inside the EV on their instructions to talk about the transaction structure or the talk about the account structure that use specific kinds of cryptography and so I think

this makes it really hard to use the evm on a chain that doesn't look a lot like ethereum like you end up having to inherit a lot of the design decisions that ethereum made and maybe in some cases some of the mistakes that make it hard to scale ethereum so indesigning move we were really conscious of not putting anything block Chaney into the core language like trying to make it as agnostic as possible so that you can take move and you can use it in a proof of work chain that has this crazy transaction structure in Swede that does things this way versus Aptos that does things this other way and so that way you don't have to bet on a particular chain to become a move developer you can take your skills and use them across all sorts of different chains including ones that are coming in the future we think

that's going to be really important for a smart contract language to survive like the biggest asset a language can have is its community and the bigger you can make the community by making your skills basically cross-platform instead of overfitting to one thing the more you can succeed in doing that in a large community is what makes it possible to invest a lot in tooling to invest a lot in common libraries and then all the things you really need for a language to become big time and to become successful and so this is something we try to do from the very beginning are now seeing like multiple mood chains that really are super different and how they end up incorporating the language I mean in my mind that's kind of the thesis that was underpinning node right is that there's a ton of people that know JavaScript

there's a ton that they want to do there's tons of libraries that they want to be able to share with each other and the extent to which code that exists can bootstrap server side applications of JavaScript that just makes node useful out the box and it means that there's all kinds of developers who may not do backend programming but can start to move into it and make that their domain I think it's a great analogy it's also by the way a good segue if we want to talk about governing programming languages because node obviously had some very high profile I mean every programming language Community has had many high profile divides and splits on the governance side and many different evolutions of it I covered node a ton it's one of my favorites actually but I want to make sure we just finish this

thread is there anything more to else to say no I feel like you're a resident curmudgeon on those podcasts which I love go for it yeah so I have like maybe a Counterpoint or I've got a pro and a con Pro that's very cool I keep thinking about why doesn't someone build a move optimistic roll up and like that would be really cool given like the Optimus role of people or ethereum people and like using metamask and ecdsa signatures right and they don't lose like move I don't believe is using like the same signature format as we for example yo in Sweden both eddsa and ecdsa easy to say for ethereum support oh well perfect well like my point being that like you could build some like pretty interesting things but however my Counterpoint is when I was trying to learn move I was staring at both the sweet docs and the

Aptos docs and I was very confused so this is definitely a problem right where it's like when someone comes in to move it's like do you teach them the core language and that they're familiar to blockchain they'll be like wait I'm learning the smart contract language but where's the blockchain and then if you're trying to write for both like there are differences between the platforms so I think that's a challenge that we're still working on I think the best path is like pick a platform pick a suite pick an Aptos you learn that really deeply and then you see that oh actually my skills and code they really pour it easily to the other one but yeah I think there's some inherent problems there and then there's just some documentation problems that we need to work through to make that a bit easier yeah maybe the analog is like it depends

on whether you consider SQL like a portable skill or not there's tons of SQL dialects yeah there is an ANSI sequel no one really knows what it is but they they kind of learn SQL and then if you squint a little bit you could use any database like you might be a little confused about a specific function name or a specific type that's missing but it's more or less the same shape and I think that that has made SQL very robust and really durable it's part of why it remains like a lingua Franca for data maybe that's where move ends up I think we could do a little better than that but yeah I think in terms of being cross-platform like that's a great thing to aim for and like very very application specific and it's just a little be right language for talking

about tables and talking about databases and it's just overwhately clear which is why everyone use it so I would love it if move were all right so blockchain has staple list of databases Okay so we've covered in sort of circle back and forth between traditional versus smart contract programming ways and flows you know specific constraints and differences and also even some parallels between Trad and smart contract programming is there anything major or even minor on things unique to the smart contract programming contracts that we didn't cover well another thing that is really important in a smart contract context is resource use like gas metering in solidity right although of course always software Engineers take into consideration the computational

costs of what in many many contexts that's very important computational resources are relatively abundant outside of that support contract context or outside of a blockchain context which means it's just litigated and considered less and I think having a notion of the resources you're consuming in the language could be an interesting resource for smart contract programming yeah it's something that we think about a lot we have built-in gas metering in the VM that's something as you say it's very different from a conventional programming language I actually think the trend on this going forward will be that gas media will become more and more coarse grained and

more about just preventing like egregious resource misuse rather than really trying to nickel and dime for every instruction like I actually think things like gas golfing although they're very fun and interesting are actually pretty harmful for both coding style and for security ironically agree I think that's because like the only model we know is to charge per instruction even though like if you have a fast VM the difference between running 100 000 instructions to 500 000 is in the noise if you're actually like measuring runtime so like you know why are we charging per instruction so I think that's a trend we'll see is how to make this more coarse yeah whenever I see all these unsafe blocks and so on and tons of inline assembly in solidity code it just reminds me how early we are because that's just not the type of programming

challenge that smart contract developers ought to be considering that's just not the sign of a mature developer ecosystem but we're getting there I agree Sam at the limit I think choosing the right algorithms choosing the right data structures to using the right General approach as is the case with most software engineering will always be important but the minutia kind of thinking about like the exact cost of every instruction is probably a step too far what are other constraints so we talked about gas optimization talked about the types we talked about the assets and safety what are other constraints that come to mind yeah this is like a sort of similar thread on gas but I guess the specific subset is a

state and this is a big thing for me when I sort of approach gas golfing you know I do love to do like extreme gas golfing we know you do however when we're dealing with real smart contracts that hold real money my general thesis is that you should do reasonable optimizations where they're obvious except for one case if you can bend over backwards to use slightly less State than you were using before you should do it that's the only time where I will break out large assembly blocks is that if you could do something stupid to use less State because it's like this whole other resource where we should put that just one above just execution or call data or whatever I agree wholeheartedly because I think that's what's fundamentally expensive like if you have a platform where every contract is allowed to touch any piece of state

it makes it very very hard to paralyze things whereas the approach sui is taking and a lot of these newer blockchains are taking is make transactions explicitly sparse like say what state you're going to access or at least like give me an idea so it's easier for the top level platform to paralyze transactions both through execution and through consensus so I think that's something that'll always be expensive and something that programmers will need to think about like make this as far as possible in terms of not touching more State than it needs to so that the validators can paralyze it more effectively and then effectively have more block space as compared to it everybody is contending for the same state does that open up a world where eventually not all validators even in a non-roll-up context have to download Allstate if you can sort of like very

easily separate out State and like what validator potentially can service what kind of transaction I think it does enable that world it also enables a different approach to change and let me back up and say I think from a programmer perspective it's very valuable to be able to touch the entire world across different transactions and not on the same one without having to go through the friction of oh you know I have to go through a roll up here or there's a cross Shard transaction and so it's slower or less secure and users notices I think the abstraction of there's one Ledger where all the valuable state is and then I can just touch that all at once as a programmers where the value of blockchain comes from so I think it's like how do you continue to Broad that illusion while under the hood things actually do let you split it

up and have it be sparse and so in sweep a validator can be multiple workers and each worker handles a part of the state handles some subset of state but from the programmer's perspective and even from the perspective of other validators it seems like it's one logical entity that can do everything so that makes a lot easier to Shard storage to start execution without having to bake that stuff into the protocol level and have users and programmers have to think about it so okay just closing this thread on anything related to what's really unique about smart contract programming what are the mindset shifts involved like we already talked a little bit about one Eddie alluded to this that a huge shift is that in the world of programming at least since the early days of computing we're in a world of abundance but in this world we're in a

world of constraints so that's one example of a mindset shift what are other kind of mindset shifts especially for each of you as you guys have come to Smart contract programming like what does it surprised you or taught you or made you think differently about that you knew going in as a programmer well maybe a silly one is I still remember the first time years ago that I learned that your balance of an erc20 token was not a thing that your account had like your address does not have a balance of tokens that's not how it works instead there is a token contract that's somewhere and in that token contract there is a mapping of which addresses have what balance right it's kind of

inverted a little bit on its head so when you want to transfer some tokens to someone you're not sending them some tokens instead you have to do all this low level kind of go to this contract and then change the address and change the balance held by your address and their address and you have permissions to manipulate and mutate that contract it's a very kind of counter-intuitive way to think in the evm in solidity and that's kind of one of the first things that stuck out to me about move is that it is a little bit more like the way you would expect all of the this to work naively hearing about it described in English you know and that's an interesting mindset shift it's just to take for granted that the words we use

in English don't necessarily map onto the programming model yeah in blockchains yet there's just a lot of you're in a weird jungle space and things are all around you and they're just not really arranged how you'd expect that's great one thing I'd add is that and this just has to do with something that you realize when you're doing it is that when in the normal world we care a lot about like developer productivity because the job of an engineer is Right a lot of code and for that code to have only a couple of bugs and have those bugs not be that bad meanwhile in a smart object World your job is right a very very small amount of code and it must be perfect it must be perfect every possible way otherwise you're going to lose hundreds of millions by other people's money and

that's an entirely different mind shift it is a a weird thing to do to stare at 1000 lines of code for like two months and try and figure out how do I make this better and more importantly how do I make this literally perfect and to have Auditors then do that exact same job of saying is this perfect that's a big one one of the pieces I edited at wired was from Leslie Lamport proposing that software design should be like designing houses that was like his big stick for the longest time and I remember pushing back and being like well what about agile and all these people who disagreed that you can have like your specs and everything written up this beautiful pure blueprint-like way and he got like reamed in the comments for it but it's funny because I feel like his worldview would actually

be dominant now in this kind of thing it's a sidebar it's a great observation well I just think it's fascinating because that was his big stick and by the way if you go to his website he has a thing on his page about me as this annoying editor he had to work with on this piece which is so funny because he was really mad that I asked that question about the difference between like the mindset shift totally the barrier to changing your code is higher than it is in any other programming setting that I can think of for like in the limit or like in the most secure most decentralized smart contracts it's immutable which means you get it out there and it's perfect the first time and you never do it I think this is something where we'll figure out in both language design and platform

design how we can support safe upgradability and trusted upgradability and make it look a little bit more like a conventional ecosystem but I think like that's always going to be a fact of smart contracts that it's way harder than upgrading a mobile app or upgrading a website in a way that's trusted or without having breaking changes building on those answer I think that's also mine where it's definitely going to be a surprise for someone who's trying to iterate into relevance that's great what else would you guys add to the list so I think as a smart contract programmer you have to have an adversarial mindset which may be very unfamiliar even if you're a product person which may be very unfamiliar if you're coming from elsewhere just because of the deployment model like you're not only thinking about the intended usage of your application you also have to be thinking

about the unintended usage because in conventional programming there's ways to hide yourself from this or limit it to a small API surface or use a firewall to limit what an attacker can do or these sorts of things but it's more contracts the whole point is what you're doing can interact with code you never imagined and do so safely and so you have to think about that the happy case of that and the sad case of that and that's definitely a mindset shift compared to Conventional programming is this like a line in the sand that you're drawing that you think ought to be top of mind when we talk about how to write smart contracts and how to use Smart contract programming languages yeah absolutely and this is actually my absolute favorite thing to talk about I am very opinionated about this which is the thing that smart contract language

designers should be thinking about is safety and that's like the main focus maybe even the only focus until we can lock down this problem like I think smart contract safety is an existential threat to broader crypto adoption and the reason I say this is because you look at ethereum and solidity the evm and solidity which the most popular platforms today and you look at the early programmers who write this code these are extremely highly qualified folks they really understand the underlying blockchains they're really security minded they know what they're doing I think they take the responsibility of writing code that manages millions or billions of dollars very seriously but still if you look at the track record of smart contract security anywhere it's just really really really abysmal and not to the fault of these folks I think it's just an extremely hard problem and I think

the languages make it harder so if you look at something like my favorite website rec.news you look at the leaderboard or look at like these 10 hacks that are in the value of tens of millions 100 million dollars are super routine like a sort of weekly or monthly occurrence depending on the size and at the same time the smart contract developer Community is really small like there's about 5 000 full-time evm programmers which is really really tiny compared to Conventional developer communities so if you buy this thesis that the folks we have are sort of the most hardcore and the most security minded now but the development practices and like the security track record is unsustainable but I think you conclude that there's no way this space is going to grow without making the security problem even worse which maybe means like it's just not going to grow at all

or like folks who are sitting on the side like big financial institutions or companies who want to get into 130 but are looking at do I have to hire a smart contract developer I'm going to get a hack for tens of millions of dollars and are nervous about this that narrative is only going to get worse for them they might just stay on the sidelines so I think as someone who's trying to design a smart contract language safety has to be the first thing you're thinking about you guys actually already alluded to this in the context of not losing assets but what do you mean by safety more specifically Sam since it's such an important Point what I mean by safety is that we're both trying to prevent the programmers from shooting themselves in the foot but even more so trying to give them the right Primitives

for being able to defend themselves from attacks because smart contracts are a setting where you're deploying your code next to an attacker who can directly call into your code can directly link against it your code is open source or at least the bytecode is open source and so like this is the most adversarial programming environment we've ever seen with the highest Stakes for getting things wrong so I think if you're talking about smart contract programming design it needs to begin and end with safety and once we've locked down the safety issue we can think more about expression of the things but that's a little boring but I think a very opinionated answer what types of features make or break safety like what are examples of things that just embodied it so I think the number one thing is encapsulation broadly and then I'll talk about specific sub features

that corresponds so it's basically when you write your code you don't know what an attacker is going to try to do when they call it or link against it and so you need to be able to reason about it without being able to anticipate what a creative attacker will do so like you want a strong type system not just at the source level but I think at the bytecode level so that the guarantees you get when you're writing your source code will continue to hold when you publish your code on the blockchain and when other folks depend on it and when they want to like against it and move one thing we look at with this the feature that's popular elsewhere but we think is inherently unsuitable for smart contract programming is dynamic dispatch no in conventional programming like interfaces and dynamic dispatch like this is the key abstract mechanism this

is ubiquitous right like you define an interface and then other folks override the interface with logic that does something different and then you know you program against the interface and everything works out great but we have this cheeky saying where it's like in a world where code is law interfaces are a crime let's pause there for a minute and a world where code is law interfaces are a crime can you explain that a little bit more before you keep going I don't want to just skip over that dude fast yeah yeah absolutely so the idea here is like an interface it doesn't Define behavior it defines intended Behavior like when you read the specification for an interface or the parameter names or even the types it tells you what you want to be done but there's no guarantee that that's actually going to be the case and

so if you're writing some code that's supposed to be protecting something but you're basically leaving a blank check for an attacker or someone else to fill in and you know this is contract law that seems like a crime it's an ill-specified contract so you know big fan of this feature and conventional program languages of course but we think in smart contracts this has led to lots and lots of different issues like re-entrancy requires Dynamic dispatch for example you take away Dynamic dispatch you just don't have a re-entracy at all lots of things like say poison tokens in ethereum like this happens because you override the transfer function which everyone knows like intuitively this is just supposed to move money around and maybe not do anything else but now you make it do something super unexpected and steal money and so that's one example of a

feature where if you take it out like reasoning about your code and having proper encapsulation just becomes much much easier because every time you see a call site you know exactly what it's going to do and you don't have to worry about someone else coming in doing something that surprises you later on exactly I think the analogy there is like if you define an interface around a chair four legs and a seat you're describing it at a specific level you're describing it not at a behavioral level you're not describing other things that it may be implicit or assumed about a chair like it has a certain structural Integrity right it has certain materials like it's oriented a specific way all of those things can be subverted and mean that the interface is really just an arbitrary set of descriptions that just doesn't capture the safety constraints

that you want to enforce in that object it's exactly right defining things at the wrong level I'm curious though how do you then sort of do modularity really well without interface because I think if interface is requirement might be a criminal here because my favorite sort of way to build complicated smart contract systems is I love to have different contracts that have sort of different purposes and like particularly when you have very complicated systems you have like a module basis where the module adheres to some sort of interface and then sort of the main contracts that can sort of nose to call those different modules and those modules generally get permission to buy governance in some way like how do you get that like super expressive plug and play modularity without sort of like standardized interface yeah how do you inheritance

how do you like all these things that are kind of related to interfaces this is exactly the right question to ask they're like okay you can rail against us all day but then how do you still provide something that lets you write useful code it's like there's no crime if you're not allowed to come out of your house or something anyway but the way we do that the interfaces and inheritance are not the only way I tend to think in terms of composition and so we provide several composition Primitives that don't require Dynamic dispatcher interfaces so one is generics we have runtime generics that look a lot like what you have in the CLR so let me give a very clear example because otherwise this gets abstract pretty quickly something like your C20 this is obviously a fundamentally important crypto standard if you can't do something like that your

platform or your language is not going to be very useful so the way that works in a language like move is you define a type called point of T where T is a generic type parameter and then you implement functions for coin like you know there's a function for joining two points together this works the same for all coin types it's not something that someone wants to override you define you know splitting and then when you want to let somebody customize behavior of coin use these so-called capability patterns like for a coin one thing you might want to customize is like What's the total Supply or like more fundamentally what's the policy fermenting and burning it so the way you express that is okay you have the struct point of T and then there's this different stations of T like us SD or GDP or EUR or whatever

else and then for stuff that you want to customize you provided at the capability level the function for creating a coin you say here's a type parameter for my coin and then it gives you back what's called a treasury capability and then there's other logic that makes sure that only someone who holds the treasure capability of T can mint and burn coins of type T and then you can go take that treasure capability you lock in a different contract that enforces the total Supply constraint you put it somewhere that says anyone can rent it on Tuesday but not on Thursdays you go and lock it you basically invert the control flow instead of putting it inside an interface and then that allows you to do this arbitrary sort of composition and so that's one example of the trick but this works basically everywhere where if you want Behavior to

work one way you've hard hard-coded sounds bad but you implement specific methods then you define these capabilities for stuff that you want to allow so if you think of capabilities as constraints that you can add to what might look like an interface to a conventional programmer exactly right like I think most of these interface patterns you can vary straightforwardly not quite compile them that's a little too hard but say here's the equivalent capability pattern for this thing you want to do with interfaces yeah by the way Noah do you find that satisfying let me feel free to disagree it's good [Laughter] so I do find it relatively satisfying because I think if you can have modules or I guess structs that have capability inside them and those trucks can be fed into modules that have like very predefined behaviors you can end up

getting the sort of same exact Behavior like a module can do x a module takes up struct a struct that was sort of defined in that module and then that struct has it capability inside of it it actually works quite nicely because then you get like really great Authority style Registries that sort of naturally arise from that like a very maker down like what's called DS off registry almost works just like that right exactly like that and then these capabilities are an explicit representation of things that you're allowed to do so that has a lot of other benefits like you want to know what can my account do you look at what capabilities it has and then maybe you can do program analysis where it says if I have a treasury capability like you know show me all the functions that I could call and then all of these sorts

of things so maybe I'm cutting ahead to the proverb but are these capabilities visible to the type system and are they visible at the time of static analysis for the program like if I you know write some code for my specific instantiation of one of these types that has capabilities then is it visible very early that I've violated a capability or is that something that I can only learn about later if I'm running it like in the VM yeah so let me give a short answer to the question and then provide some background where yes they're visible to the prover and they're part of the type system this is something they're leveraged very heavily but let me talk a little bit about structs and the movability system and then how that rolls up into things like capabilities in the perimeter if that's not too much

of a distraction so in move you have struct types and destruct is like another language it can have fields can be fields of primitive types these can be other structs and then the thing that's interesting and maybe more different about move is these trucks have abilities if you're familiar with rust abilities are a little bit like marker traits they declare built-in operations that you're allowed to do on the struct and just as importantly if you don't have the ability you can't do those things and so to start with an easy one one ability that's very important for financial programming is the ability to copy like if you have something that's a coin type or an nft or something in the computer it's just bytes but you don't want to allow someone to copy that thing willy-nilly and so in move if you don't say has copy

for your struct then you're not allowed to use our equivalent of mem copy like basically the copy operation so things like integers and strings they have copy but if you don't want your type to have copy then you just don't give it that and then there are other abilities like discarding like so that's this is called the drop ability so this is where you get into interesting things like linear types these two elsewhere like if you want to be able to just drop something on the floor like you know Let it go out of scope overwrite it then you give it a drop but if you don't give a drop then the only way to eliminate it is whatever policy the module that defined that type wanted so to give a concrete example there something like you want to keep a total supply for your coin like you just

don't give your coin drop and then the only way to get rid of your coin is some burn function in the the module that declared it which then updates the total Supply so these are the sort of tricks you can type that you can play and then there are several other abilities related to where you can put something in global storage whether it can go there or not I won't get into those as much because I think they're less relevant to the question but basically like building into the prover and abilities like the prover is aware of the type system it knows how to leverage the type system to figure things out like oh I know if something doesn't have copy I don't have to worry about it being copied and so if I write a specification that says there's only one of this thing the

prover can leverage that to prove this property and so it really works hand in hand on top of the guarantees that the type system is giving you as soon as you said drop I wanted to talk about my favorite can you just like talk about what the Hot Potato pattern is if there's other similar really cool things it's one of my favorite weird things that arises from move it's definitely a weird thing so yeah this is very closely related to abilities so normally in a programming language you don't have a lot of control over when someone can eliminate your value like maybe you have a Destructor that says this is what happens when your your value goes away but you know sometimes there's weak guarantees around a Destructor being called or you can't just say something like you're not allowed to delete my type now like that sounds like a weird

thing to be able to say like why wouldn't you be allowed to delete something but it actually ends up being very powerful particularly in this setting where there's no Dynamic dispatch so I'll start with an example of hot potato and then we can work more into the guts like a flash loan if you're doing a flashlight on eth this is a standard that you override where basically you expose a callback where it's like hey flash loan contract like you give me money call my call back and then take the money back or something and move the way you do that instead is someone goes to the flashlight contract and they say hey like give me 50 Suite but then they also give you the so-called Hot Potato object and the Hot Potato object is a struct that has no abilities it doesn't have copy so you

can't copy it it doesn't have any of the global storage ones so you can't just like stash it away in a contract somewhere and it doesn't have drops so you can't get rid of it so the only way to get rid of it is to pass it back to the flashlight contract and the code in the flash on contract that lets you pass it back forces you to pay back the flash loan and if you don't it's not that your program will fail at runtime it won't even type check so it's leveraging this interesting ability to control the destruction of your values and then as a programmer to put arbitrary and variants on when are you allowed to like what needs to be satisfied in order to destroy this and then just sort of making these little like API call patterns are very explicit like another

very obvious one is like if you want to force someone to call lock after they call unlock but want to let them do whatever they want in between you can also do that exactly yeah when I first heard about the Hub data pattern it reminded me of like mutexes like interesting uses of locks where purely for the purposes of ergonomics you take advantage of the type system in order to force almost business logic level requirements in the way that specific objects are used which I think is really clever that feels like such a modern such a high quality use of ergonomics in programming languages that really I don't think is super common in traditional programming languages even yet but is so obviously valuable in a

smart contract environment where there's even more logical requirements on what is possible what is not possible when you have so much value and so much security at stake so before we go into like any particular examples can you give a quick high-level overview of the sort of object system that we have what are objects who own them how objects own other objects palette pairs of like modules or sort of the bird's eye of how it all works yeah totally so this is about the dialect of move specifically move and the basis of this thing is a different structure of global storage than the original dialect of move that we use so the original move Global Storage scheme was very much like in the compass model like ethereum is using and in Suite we instead want to make things object-centric with a high level of

motivation of being able to express fine-grained access as precisely as possible like this helps you do a lot of things that won't get into on this podcast but like paralyzed transactions more efficiently tell wallet users what a transaction is going to do before they sign it and things of this nature so in sweep the structure of the global storage is it's a map from object ID to object and then objects or just move structs that have this ability called key key says hey I'm allowed to be a key I'm allowed to basically appear in the global object pool and then every object has to have one of these Global unique IDs and then you can write entry point functions for your modules and then they can directly take objects as input and the sweet runtime is able to if you're writing a transaction it has object IDs

and the suite runtime is able to use the IDS to resolve the ID an object and then plug it into the function for you and it just has this very nice like object-centric asset Centric programming experience that's a lot more direct than what we had in the original version of move and you mentioned also the parent objects and child objects and object hierarchies this is very useful but of course you still want to be able to do something like represent a large collection I'm building a DNS style registry and I want it to have millions of entries we have an object size limit an object can be a couple megabytes but not bigger but if you have DNS like that thing should be arbitrarily large and so the way we represent that is with parent-child object relationships we basically have a way to view an object

as a heterogeneous map and then you can sort of add keys with dynamically chosen Fields it's very javascripty in this way worm you can say this object has a map inside of it and then I can put stuff inside this map or you can say hey when I Define this object it had 10 Fields but I actually like to add a new field I'm going to upgrade my contract I'd like to add a new field after the fact and the way we represent that is with these parent object child relationships where each file is associated with a key value that can just be an arbitrary variable value like a string or a u64 or whatever else you want it to be yeah and related to that sort of parent object idea I think the thing that made that like really quick for me actually a

couple of months back I spent time doing a deep dive into sweet move and basically started writing a program that's just a single object all the way to re-implementing most of you know swap V2 style decks and the one little mini project I did that really made the objects owning objects being so valuable hit me is I built a really simple system that was I think the three objects were there was a lock something called gold like lock can hold gold and then like a empty object called a key and a very basic module which you could probably think about that can create a gold owned by the key object and then the only way to get the gold out is there's a function that takes the lock and key and obviously destroys the lock gives you the gold back and destroys your key right and I think that's sort of

interesting like is this the benefit you get by having like the optic relationship describing permissions in a really granular way yeah that's exactly how we think of it I love how you describe the nesting of the three different objects because this thing is even more powerful when it goes deep sure so yeah it makes it much easier like as a programmer to structure that to make sure like oh I get to the second tier and then I can touch the third tier but I can't go directly from the first to the other and it also makes a lot more approachable I think for programmers coming from outside the smart contract space like these books are very familiar to program the Trees of objects the Dom's a tree of objects if you're a game programmer you know everything is the scene hierarchy where you know it's a character and they have

an inventory and then the inventory might have little sub bits in there so you can encode this stuff very directly and move and then the type system allows you to set up this Access Control in a very direct and safe way so yeah I think this is a very tactile program experience it really mirrors the intuitions you have about the real world or how you describe something but then transcribes very directly into the relevant code by the way before I came to wired and Basics and ASP at Xerox Park and that reminds me a little bit of the history of object oriented programming what you just said which is super fascinating because they invented Small Talk which is the early precursor of a lot of the object-oriented Frameworks today anyway okay cool anything else you guys wanted to cover I I just had like one general question

like actually are there like hacks and stuff that have happened in the evm world that you think using move just immediately would have made never happen in the first place just because of the type system yeah I have a whole Twitter thrown on this that I'll have to plug in the show notes I'll link to it so in the evm world we already mentioned Dynamic dispatch re-entrancy yeah move eliminates for entrancy by construction anything that has to do with re-entrancy that just goes away which I think people are pretty good now I think at avoiding re-entrancy but well could you spell out why like what is it about move that makes that exactly impossible so with re-entracy right like what happens you're writing some code you call out to some function and then the problem is somebody supplies an implementation of that function that you as the initial

programmer did not anticipate and so in order for that to happen that function call has to be dynamic it has to call code that's basically a function pointer supplied by the caller who might be an attacker and so if you don't have any sort of dynamic function calls if you always know the target of a function call at runtime then this just can't happen at all like anything you call like well you might not know what the code did but like you knew what it was you could have tested it you could have verified it it's all right there for you so it never happens that someone can supply code that makes your module behave in a way that you didn't expect the it's just a static function Paul cool so that eliminates re-entrancy attacks which has been a perennial issue in solidity development yeah I think a big

issue with smart contract programming the move basically eliminates is missing permission checks where a lot of times you're writing some code and then you pass in all these accounts explicitly and you have to say like oh am I allowed to do this on that account and you write the straightforward code and there's just like oh I forgot to check that the sender is this person or that this person can access that and I think these sorts of things happen quite frequently so and move and then we move specifically the object ownership information lives in object metadata it's not something the programmer even has control of like when you look at these objects they'll say I'm owned by this address or I'm owned by this other object or I'm a shared object or I'm immutable so the programmer can't forget to check who owns it because the runtime does it

before you even start executing code that passes in a sweet object the runtime will have said okay I see the transaction sender I see all the objects they want to use I'm checking that they actually own them or that they own an object that transitively owns that so they have permission to use them so a lot of permission checks that we ask the programmer to write end up happening in the suite runtime instead so that you can't possibly forget them and I think this is huge because the hardest things to guard against are like the specifications that the programmer hasn't told you are important it's easy to forget those and it's hard to catch those with static analysis or something else because you always need some human intent done yeah on what's important I think it'll be really interesting by the way just projecting way long term or

near Long Term which is what happens at Enterprise scale when people collaborate in more ways this way like it's obviously distributed and not only in one company that sometimes people collaborate but what I mean is when you think of the olden days of like the way that things work out right now you have like devops and you have like all these best practices and all these like methods and then you have like these very different mindsets for doing things and we haven't quite like institutionalized all that in this world yet by any means it's still too early but I am very curious for what that kind of thing will look like yeah like what's left for tooling evm tooling is so great move tooling I think still has like a little bit to be desired like what needs to be built still are we going to see

major changes happening oh yeah I think we're very early in pooling so I'll talk about a few things I'm excited about coming up where one is a package system and package manager think of like at crates.io or npm or whatever your favorite the move model system is very amenable to this sort of thing and so we're working on something like this and it's cross ecosystem it's not just for sweet packages or star coin packages or something but it's like create.io where like there's one tab where you see the source code for this thing and you know you can use it in your manifest files to build projects locally and make it really convenient but then there's other tablets like hear all the blockchains where this thing's deployed and then if their vulnerability disclosures or upgrades then it can be integrated with that so I think like that's something

where there's a real opportunity in the blockchain space and that we're really excited about that just makes it so much easier to share code which is hard to do and say solidity because like you share code by copy pasting basically instead of like using modules or packages that are already published on chain and so that's one piece of tooling we're very excited about correctness tools is what we've invested in the most early on and we have a lot of those but I think there's a lot to be done to make them more usable so we have a unit testing framework you can write you know test directly and move which folks use very heavily and we've specialized a little bit to fit the suite transaction model there's of course the move prover which we've developed alongside from the beginning can you briefly talk about formal verification and why the prover

matters Noah had already mentioned earlier about dejan but we never actually shared context for listeners about formal verification right so formal verification is very challenging you usually have to be an expert or have a PhD to use it and so we're really trying to push the limit as far as we can to to make this just something an everyday programmer can use and just not really think about instead of having to be an expert and I think the jury's still out on how possible that's going to be like the move standard library is all verified and someone didn't know just like submitted a PR to a file that had a bunch of specs and then they added a new function and they just wrote specs because it was just easy to imitate what was their parents clearly culturally that's what you're supposed to do so I

think like these sorts of things are very promising but there's so much much more both in terms of making the proof a more usable and making it more powerful I think things like fuzzers we haven't invested in as much because a fuzzer is Never As Good as formal verification but on the other hand like buzzers are free they work very well for blockchains like important correctness tool especially if you're writing very intricate code that's doing some parsing or Loop kind of stuff so we have some collaborators in Academia that are working on these sorts of things and then I think beyond that it's just a lot about like how do you make writing programs easier well of course we have the source code we have the compiler we have the basic IDE Integrations but there's lots lots more that can be done there both on sort of

just supporting more Ides but also like more powerful tools maybe program synthesis maybe AI integration just love to see what's going to come out there cool how do you use the move prover today like what if I wanted to mess around with it yeah so you take your program which you've already tested uh verification is not a substitute for testing and then you write some things that are either hard to test or just hard to check that you've gotten it right for all inputs so it might be something as simple as function pre-post conditions you excited if this is true about the inputs to my function this should be true about the outputs you might also write data and variance like you have a counter and you want to show that it's always increasing you can write a specification that's attached to that counter struct that checks that

this is true and then it'll look at all the functions and make sure of that and then there are more advanced usages about global storage and variants like you might want to say there's exactly one of this object always or like if there's two of this object then there's three of this object and like here's the relationship between the fields of that object and the fields of that one it ends up being very application specific where the language takes a lot of basic mistakes off your plate but then for you as the programmer like there's always going to be correctness conditions that are specific to your application and the specification language makes it easy to write those out either after you've written your code or in some cases even before and to make sure that they hold for all possible program executions and all possible function calls and so today

like the spec language is integrated with the compiler so you can pull it out and try it out in any of these modes and then it's also integrated with the build systems you just do you know move build dash dash prove and it'll check these cool is the prover yet like does it understand sort of the sweet object model and the sweet transaction system yet like can I prove things about like cross transaction things that like potentially modify the global state it doesn't yet on the other hand it doesn't need to understand like say the counter that's always increasing like that's a sweet object but it doesn't need to understand anything about the suite to be able to prove that even in the prover for core move it really reasons at the level of objects in global storage and less about like transactions because transactions aren't

a core move concept so that's a direction we may take the approver eventually like sort of symbolic transactions or any living transactions but today it really looks at the level of functions and structs which works well but I imagine we'll end up doing some sweet Miss stuff in the future especially as regards the parent-child relationships and these heterogeneous object Maps okay so should we talk about governing programming languages then a little so like there's actually long and storied history of how programming languages have evolved but the governance topic is obviously even more top of Mind in the context of blockchains and crypto because there's all these other aspects to it a decentralization b you know open source distributed communities C tokens and economics and assets sometimes being involved as part of the incentive scheme

programming languages especially because they're open source they're useful in so many different contexts they are treated a little bit like public goods but they're not the same they're something that needs design and needs attention to detail how should programming languages develop there's so many ways that programming languages seem to be governed today like the top two that come to mind to me are like the C plus committee the wg21 committee or has some crazy name and then like python with Guido being the bdfl the benevolent dictator for life like what do you think is the modern way to govern a programming language especially in crypto it's kind of unique because these programming languages have layer ones

attached to them maybe which is a different type of thing that depends on that programming language it's kind of a public good but it has stakeholders it has a lot of capital attached there's a lot of value being transmitted like maybe there's governance models for programming languages that work better for blockchains so I'm interested in thinking about how they should be governed or maybe better how does move evolve given all the huge variety of stakeholders and the importance of the design of the language and preserving its safety properties and so on yeah I wouldn't presume for my insights to apply to other program Landers but for move I have a very specific take on this where this desire to be cross-platform I mean in addition to the benefits for programmers and for platform designers

governance is another reason for that where almost all of the controversial decisions in a blockchain language things like hey should we increase this limit or should we support this signature scheme or should we have this library or not we try to set it up so those are in what we call the adapter layer the platform that's building on top of the core move language and then the core language is extremely minimal minimality is one of our key design principles for the language and just very blockchain agnostic so if we're going to have a debate with stakeholders in the community it won't be like hey should we increase the gas limit it'll be like should we have enums which is a lot more of a pure design question and something that can be influenced by problems or use cases that are coming from one or more moved platforms but

isn't likely to be be driven in a direction that is really good for one stakeholder and not for others so that model has been working out pretty well so far I mean we'll see what the feeder holds but basically the way move is governed today is that originally move was developed at Facebook and there there wasn't really any governance it was just us using it although building these principles in mind and now the team is spread out a little bit where we have many folks that missed in there are some folks that act us there are some third-party contributors in Academia in the security community and also at starcoin and ol these other move chains and so we just have a meeting every Thursday and we talk about move design topics and we're really conservative about extending language minimality is the main thing but then we're aggressive

about extending it one and it's like oh adding this thing would make it easier to experiment in these layers that build on top of move and then once we see the results of those experimentation or everyone seems to be doing the same thing that's when we move it into the core language and so really our answer to governance is to mostly avoid it both by having the controversial things be in stuff that happens on top of move and then also by having a core principle be we're really conservative about extending this thing minimality is one of the most important features so that we only add new stuff when it's just all only clear that this is something that every programmer would want do you guys as programmers like on the other side of things Noah like do you actually care like when you look at and

you pick what to use how to engage like do you care how the community or like the language as governor do you just care that you're getting the tools that you need I think it matters to a certain extent like you want to use a language that like a is used by a lot of other people so you can have contributors to your project right you want a language that's not going to be abandoned right like I guess those are the main things right yeah but I don't really care if it's python governance by dictatorship or governance by committee as as long as sort of the things get done although I think a lot of people do not there are a lot of arguments for for why governments by committee has sort of broken a lot of programming languages I guess yeah totally I'm always find it fascinating

yeah I do think it's important for I mean like I've had a certain technical vision for these things like the cross-platform for a program with assets and basically like a broad idea of what these things should be but of course like this is a community project there are many many contributors who have added to many aspects of design like I'm by no means they've been a dictator for move or anything of the sort but I do think my role as being a curator in terms of making sure that everyone is on the same page and just making sure that when ideas come in we're evaluating them against those principles and those ideas could come from anyone yeah but the most important thing is just that we have that shared Vision every language is a little different I think they inherently reflect what they're used for and the

personality of the Creator and the community and all these sorts of things so there's definitely not going to be a one-size-fits-all rule there no totally that makes total sense so before we wrap up with the last few questions here I just realized Sam that we never actually heard from you about how you got to move in the first place and I'm mainly interested in it not just because I want to hear your story which I'm sure is great but I'm actually much more interested in the idea maze you traveled like how you came to this problem in the first place so can you quickly share a little bit about that Journey absolutely so I start off my career as a programming language as a researcher I worked in static analysis and program verification which means that I spent a lot of time looking at real programs

looking at bugs and trying to figure out like what are the kinds of bugs that programmers consistently create and what contributes to those is it underlying issues with the language that just makes certain kinds of mistakes too easy to make is it problems with Frameworks that they're using is it just things about human psychology that makes certain kinds of mistakes easier to find another and basically in my PhD I spent a lot of time studying real programs looking at bugs and then building these tools that try to look at code without running it and try to catch these bugs beforehand and the thing in general is undecidable you're in the static program analysis you're always fighting the halting problem but you can get arbitrarily close to getting a perfect result in practice without ever reaching in theory so spent a lot of time doing this and

you know looked at all sorts of classic kinds of bugs like multiple references buffer overflow security issues and I really really enjoyed this work but it was hard to find these examples and find a lot of data sets that folks really cared about but towards the end of my PhD I did an internship at Facebook and this was back in like 2013 2014 they were making the transition from the web world to the mobile world and discovering hey when I ship a bug into a mobile app it sits there for two weeks as opposed to the web I can fix it right away and when I joined the fragmentation in Android was causing the most problems in terms of like shipping bugs that just sat there forever so one of the big things they invested in was the static analysis technology they acquired a team

of researchers from my field and I got to sit in with them and take the work I really love doing but instead of begging sort of single digit programmers to fix bugs you ship this stuff in front of tens of thousands of developers and run it in CI and get real-time feedback on it's awesome that you found this book why didn't you find this one can you also use it for that and so I spent about three years there just really like getting deep into program analysis and like programmers and I love the work but if you do this work for a long time you develop a lot of opinions about language design you know the cardinal rule of stock analysis is you're not allowed to change the underlying language you work with a program you get and you know you just do the best you can but you can't

help but look and say oh they just did this a little bit differently like my tool could be more precise or it could be faster or this bug would be prevented by construction and we wouldn't have to be doing what I was doing I could be doing something else and so I just had a lot of opinions about language design and software safety and sort of human psychology and how it interacts with these things and about program composition like how do you make it when you smash two programs that never anticipate each other together like that they still behave as expected instead of having some weird occurrence happen and so in 2018 I got a chance to put these ideas to work when I was asked to join the labor project to build a global scale payment Network that was powered by blockchain and they were just

bringing in folks who had the sort of relevant technical expertise so distributed systems cryptography databases payments and then also programming languages and so when I got there this was about April 2018 it was a very broad mandate with like hey there's the smart contracts thing here's the evm here's the Bitcoin here's this other stuff like just try to figure out what we should do with smart contracts on Libra so Libra's also was renamed to DM that's how a lot of people might know it today and then the other quick note your PhD what was the actual topic of it yeah I worked in goal directed static analysis so normally when you do static analysis the way you sort of do it is you look at an entire program and you build a database of facts about the program and then you try to find bugs by querying

that fact database and this works well but it tends not to scale well for really large programs because you have to look at the entire program and sort of do everything whereas you might have a very pointed question that's about one particular part in the program like if you're running your analyzer in CI for example you really want to report bugs that happen on that pull request and you don't care so much about what happens in the rest of the program and so in my dissertation I was looking at Gold directed stock analysis where it's like hey I want the efficiency of the static analysis to scale not what the size of the input program but with the complexity of the particular property that I care about so if there's really simple reasoning for why this thing is safe or why there's a bug I want that to

be really fast where if it's really intricate reasoning that requires looking at everything then that'll be correspondingly slow this is a useful thing to do because one of the big issues with static analysis is just really slow especially when you run on like giant multi-million line programs so I was working on new Theory and this subfield of static analysis called abstract interpretation to make abstract interpretation more goal directed and property directed for both better efficiency and better Precision ooh fascinating you mentioned in your background that you were also interested in the psychology of things when you think about designing your PhD your work until now can you quickly close the thread about the psychology of the programmer because you didn't actually scratch that itch for me so in 2018 when I landed at a Libra is basically like you know we need to have Smart contracts

on Libra and like you get to figure out what that means like you can't reason in a vacuum like this as they're saying earlier like languages are fundamentally problem-solving tools so I've looked at a lot of solidity and smart contract code I was like what are programmers trying to do with these things where is the language helping them and where is it getting in their way and the main conclusion from this is just basically like there's something that all these programs are trying to do they're trying to talk about assets they're trying to transfer them they're trying to Define them but the way this code is written is always just so indirect it's almost like a Brutus design exercise so it's like you're trying to talk about this thing but there's no vocabulary to be able to say it and that was sort of like the

psychology element like I can read the program and think about like what is this person trying to say like in their head versus the code that they actually wrote and what gets in the way during that translation there and how can the language help by providing the right abstractions and you know there's no objective answer to these sorts of things this is sort of like well I'm a programmer too like how would I want to write this code or like what would I find intuitive versus confusing yeah and so basically the decision to create move instead of building on top of the evm or using an existing language is like well this smart contract demand as we were saying before like it's just really really different from anything else like it doesn't really make sense to use an existing language because it doesn't have those abstractions that you want or

the the features that you need and if you're using something like slowly in the evm it's the first effort in the space so it didn't quite anticipate understandably what folks are going to want to try to do so I thought we have all this second mover Advantage we have information about what folks want to do what works well and what doesn't and we should use that to craft a new language and it was an interesting Journey that we've talked about some other time to convince folks they need to build a new program language When someone tells you that you should always say no And so there's a lot of like very reasonable skepticism yeah you know I'm glad Facebook had the vision to try it out I mean interestingly it feels like it's almost the only place you could have spawned it and almost even better that

you then can take it away from it and move on like it almost feels like the ideal conditions in fact for both the birth and the evolution of it absolutely very serendipitous yeah so that's great context so last quick thing any parting words of advice for people trying to understand like just a lightning round like two second answer like if you had one piece of advice for people coming into this space of smart contract programming languages or they're already in the space and you want like a word of advice for them what would you guys say read a lot of code and read code where you know what it's trying to do and understand how the underlying code actually does that and what it does well and what it doesn't and why just really quick I think this is just the best way to understand something like a language

is a big surface to understand it's very abstract but if you start with something you know and just are trying to figure out to do it I think that's a much more concrete route in and it's easy to generalize from that great Eddie you know anything your dad it's such a great question I totally agree with what Sam said I'd also add that because we're in early days people love sharing all the cool stuff about how crazy it is to program on a blockchain there are so many people that are just so happy to share so happy to get into the weeds every time I have questions in any kind of big chat group or any Forum like people love to share with me so I'd say find people that you really enjoy just sharing your crazy code with and building the open mind would be that if

there is a tool you love that you make use of it every day in your workflow whether that's a compiler a testing tool or whatever it is that makes your life easier you should learn how it works and also every time you find a bug you should go in and fix it be you know a good custodian of Open Source software oh that's a great it's something I certainly if something has made my life better I want to at least give back a little bit that's great you guys well thank you so much again for taking the time Sam Noah and Eddie thank you so much for joining this episode of web 3 with A6 and Z so thank you so much thank you Noah and Eddie this was a really fun conversation I appreciate you having me thanks so much this is really fun thank

you guys it's a great chat thank you Sono Sono thanks so much for having me it's the lunch conversation with other nerds is my favorite thing yeah I know that totally that's why I described it like that except no lunch anyway you guys have a great day have a good one thank you for listening to web3 with Asics and Z you can find show notes with links to resources books or papers discussed transcripts and more at asicsncrypto.com this episode was produced and edited by sonal choxi that's me the episode was technically edited by our audio editor Justin golden credit also to moonshot design for the art and all thanks to support from Asics and Z crypto to follow more of our work and get updates resources from us and

from others be sure to subscribe to our web 3 Weekly Newsletter you can find it on our website at asicsnzcrypto.com thank you for listening and for subscribing let's go [Music]