Authoring a New Language for the EVM w/ Charles Cooper (Vyper)

Transcript

[Music] hello and welcome back for another episode of The Strange waterer podcast thank you so much for joining us this week let's get really basic let's say that you want to build on ethereum or more specifically let's say that you want to create and deploy a program to the world computer your first step you need to actually write out the program you need to explicitly write The Specific Instructions that you want ethereum to execute every time that it runs that program and by default that probably means you're writing your code

using a language called solidity but here's a little under the hood secret ethereum doesn't actually understand and solidity it's much too abstract and verbose for a computer what actually happens is that your solidity code is sent to a compiler which translates your human understandable code into machine understandable bite code this Paradigm is the magic behind the vast majority of programming we write our code in a language that's easy for humans to work with but we transform it to machine code when it's actually time to run it so here's the question to kick off today's episode if we can translate

solidity to evm B code can we translate a new language into the same bite code maybe one that has analyzed the pain points of solidity and has fixed them Charles Cooper is a core developer of Viper an alternative programming language for the ethereum blockchain and other similar blockchains while non-b might not be familiar with Viper you're definitely familiar with Viper programs for example curve Finance throughout this conversation you'll not only learn how programming languages actually work but also how properly designing a language can completely change how developers are

able to build here's the core Insight that I want you to listen for the most important part of being a builder is the ability to clearly communicate what you want to happen and as much as that is a statement about the skills of a builder it is also a warning that the tools you choose affect your ability to communicate your ideas and so picking and in Charles's case building the right tools is just as important as putting them to use one more thing before we begin please do not take Financial advice from this or any

podcast ethereum will change the world one day but you can easily lose all of your money between now and then all right let's talk Viper Charles thank you so much for joining us on the strange waterer podcast thanks for having me Rex of course so before we get to uh Viper and like the the meat and bones of like ethereum um I'm a huge believer that the most important part of every conversation are the people that are part of it so with that as a frame will you uh kind of give us a little bit of your background and tell us how did you find ethereum and what uh about it was like so compelling or fascinating or

whatever to you that you're willing to dedicate your kind of life and career and reputation towards it uh that's a really interesting question I guess I started out my career in like Financial Tech so I I've been doing various hft and automated trading for a long time and then um I think in 2017 or so I um started to become like aware of Bitcoin and ethereum and I like looked into what I was doing and I was like wow this is really cool like you can do anything like you can like replace companies like anything that you want to do that normally requires kind of

these like legal contracts and intermediaries you can you can do with smart contracts so um I started kind of looking into it and I was like okay what what can I do here uh what am I suited for and always had kind of like an interest in programming languages and I've always like believed that the a programmer's most important tool is like being able to be able to work effectively is there and the way you work effectively I actually studied Linguistics in college and and I think the way you work effective which is actually science it's not like a fake thing but uh it is a little it's not like physics but it is a science and um I I

do think that uh being able to express yourself well easily concisely and effectively is like very important is the most leverage you can have as a programmer sorry before you like dig into um like what uh kind of like spiritually got you excited about the work you're doing now like H how did you get exposed to um ethereum and crypto was it just kind of through the Mania of like 2017 um you just like happen to be exposed to it through like the internet or Reddit or was it something that was going on uh with the highfrequency trading firm you're working at like what how did you see ethereum and think like oh my God this is cool and not just part of the Deluge of information on the

Modern Life yeah um I think what happened was um I read an article in the Wall Street Journal about Bitcoin being used in Venezuela and I was like oh like this is this is like the real thing this is like actually useful this was early 2017 end of 2016 and I I like logged into coinbase to like buy some Bitcoin and I saw ethereum and I think somebody had mentioned it to me before or i' like seen it somewhere someone on the internet and I was like that's interesting like what is that so I started looking into it more nice yeah and I a big thing that I always like to say to Americans or like westerners is the idea that crypto like applications

are coming use cases are coming just reflects like the very privilege and very like soft life that we live and for people like Venezuelans for people in war in war torn countries and people like that are politically or persecuted by gangs or whatever like crypto has a use case today and it's really about like ownership of your wealth and the ability to walk away and so um super cool that you recognize that early on took me a while to get there yeah um so I cut you off earlier you were saying that like through your U you know your education and just your personal passion you like really came to the table with this belief that the ability to express yourself is the most um important or

powerful like tool in a programmer's toolkit so when you entered blockchain what did you see so I was like this is interesting like I'd like to like start contributing but and and I want to do it in the way I best know how possible so you know I had some background some compilers and interpreter things and I was like let I want to like work on Smart contract programming languages and so I started like looking at what was out there I tried solidity um I tried you know Viper there were a lot of like interesting projects at the time remember there was like row L that was a long time ago and I I I thought that Viper was kind of like this Ideal Balance between practicality and um I I

don't really like using this term lightly but Elegance you know um programming is is sometimes like math you know it should be it should be beautiful in a way but not at the cost of not being able to solve engineering problems so before we like go deep into programming languages and like what is Viper and why it's important like let's start at the highest level which is like what is a programming language and how does it relate to like a program and so like I guess just so Charles you know where my head's at like can you walk us through a little bit about like the process from idea in someone's head to code to like an actual program yeah that's a funny question because people

ask me all the time when I tell them I'm a compiler engineer they say what's a compiler and I'm like okay let's put it this way you know like Java or C or Python and most people even late people have heard of those and it's like well your computer is made out of sand it doesn't know what Java is right and like a lot of people if they think about it they're like oh right that makes sense so what a a a a programming language is is actually it's for humans a programming language is like some set of quasi linguistic constructs which lets you express a program and then there's this thing called the compiler

which takes this program which is written in this high level programming language python or C or Viper or Java and it converts it Loosely speaking into a machine code and machine code is a bunch of instructions that a CPU actually knows how to execute like add multiply divide um move something from run register inter another so so what you're saying is that when we look at like lines of code and we think like oh my God this isn't English this isn't a language like this is for computers like us computer scientists know that actually anything that's written with like really letters is something that is meant for humans and is meant to be like

accessible even if it looks like crazy and weird and whatever and what what you're doing and what the job of a compiler is is to be a translator that says like we're going to take the way that humans think about code and we're going to take the way that computers think about code and we're going to act as the I mean like not the translator right because it's really one way but we are going to interpret everything that the humans wrote and then rewrite it for the machines is that correct yes exactly and then I think like the important thing to recognize especially here in blockchain world just because you have one highle language like solidity and then you have one um like computer or VM right which is

the evm like the the important thing here is that the evm just needs the instructions and if you can translate solidity into those instructions there's no reason that you can't like create or pick or whatever a different language than solidity as long as you have a compiler that knows what the machine's expecting and knows how to do the translation there's no reason that like let me just be very Frank solid like ethereum doesn't understand solidity it understands machine code and like there's no reason to limit ourselves to just this one translation of solidity to machine code is that right yeah and you can actually write bite code by hand I mean you can write

write evm code I mean I do that all the time for fun right oh and besides uh Viper insud there's a lot of like lowl languages which Target the evm uh I think Huff is like a fairly popular thing these days it's basically like an assembler with macros so you are not exactly writing bite code but you're writing you know things that are fairly close to bite code and it gives you some glue to to to glue them together in different ways and that's fairly popular recently uh especially as like a learning tool to understand how the evm works and so like when you um are like you know again because you have this background Linguistics you have some experience in interpreters and compilers did you you enter the space thinking

like solidity isn't good enough we need something better or did you enter the space thinking like programming languages um if it's a you know if it's a real technology there should be more than one and I just want to contribute to that diversity like what Drew you to the programming language level of the stack um I tried programming some things in SL and I was like this doesn't seem very fun this was a long time ago this is like Sly 04 something I think I think anyways I'm like not here to say bad things about programming languages other programming languages but I started writing some contracts and I was like wow so so has is like let's let's put it this way it's very powerful lets you do

a lot of things but there's like a lot of ways you can shoot yourself in the foot there's a lot of foot guns in the language and so I started like writing some smart contracts and I was like ooh like this seems like a little bit weird or dangerous and I was like yeah I remember opening up the you know the Viper docs the website and looking at the the language goals and I was like this is really cool cuz you know the top three design goals of Viper are like Simplicity readability and safety and it's like really important for programs to be readable um it's really really important for them to be reasonable and

I use reasonable in technical sense which is that like you are able to reason about the program and you can always like add more features you can always make things faster you can always make them more efficient but it's really really hard to make things more reasonable and so looking at you know Viper goals I was like this is really good this is really important and I thought that you know the the best way for me to work on making programming language program smart contracts more reasonable was to to work on on viper basically yeah that makes a lot of sense and I think it's always applicable to think like that um and for for those of us that don't have a computer science

background it it's like cannot be overstressed that having something that is understandable and readable and just like accessible to the human brain is so much more valuable than you might think um because like we're just at an age in technology where things are so complex it's really easy to create something that works that you have no idea how it works and that's great until it doesn't work and then you're pretty screwed so I definitely um understand like how much Focus can be put on uh just like accessibility to humans but that that's in normal programming right on top of that in our realm we live in the evm right which is if something goes wrong

you can't fix it you cannot undo the the glitch you cannot like just hot swap the code like it whatever happens is out there forever and so um do you have just any like thoughts or follow-ups on like why it why Viper specifically and like those attributes of Viper called you um as opposed to as you said any of the other languages that were uh possible at the time uh you know there's a saying in programming that if it's twice as difficult to debug a program than to write it then you better write it being half as clever as you know how otherwise you're never going to be able to debug it and one piece of feedback I get about

Viper a lot is that it it's like very it's so simple it's very readable like non-programmers can kind of write Viper contracts and there's a lot of um kind of technical things which also go into that so for one thing Viper is at least the syntax the way it looks is based on Python and python is kind of well known for being syntactically simple approachable oh I mean python is like known to look like quote unquote pseudo code which is like what what what code looks like when you're drafting it so Viper also kind of looks like pseudo code which is like if

you were like to strip the code down to the its barebones to like the essence of what it means take out all of the curly braces and the semicolons and like make it instead of look like code make it look like instructions right yeah um syntactic noise and that's kind of like a a ux thing it's just like it's it's an appearance thing it's the it's how the dress up the clothes but it's it's important and then there's always been a focus on viper being statically analyzable uh so that means to give you a bit of the backgound programs exist kind of in two realms one is static and

one is dynamic so static is the source code itself it's the meaning of the program without running it and then Dynamic is what happens or maybe you call it runtime behavior is what happens when you actually run the program and that's what it actually does at runtime and Viper is kind of designed to be uh very statically analyzable so you can kind of write a tool to figure out a lot of things about how this program behaves at runtime well actually can you break that down a little bit further like what why are some types of languages uh able to be statically analyzable and some like really struggle with that or maybe it's not even capable like what is different about the language so there's a lot of things that can make programs

hard to analyze and they usually have to do with how much dynamism is available in the language um this has to you uh do a lot with how storage and memory are allocated I'm trying to think of an example so for ex for instance in C there's kind of two basic ways of allocating things you know one is on the stack and and one is on the Heap with with Malik and um when things are allocated on the stack that's usually better because you know where they are statically whereas when they're allocated on the Heap there's some kind of indirection you have to do at runtime in order to find out where something is so if like X is allocated on on the stack you kind of know where it is you don't have to run the program but if

it's allocated on the Heap sometimes you need to like actually run the program in order to find out where it is and this is kind of a general property of programs that's known as Turing completeness so sorry just to unpack uh what you said there so stack in the Heap technical terms we don't really need to know what that means all that we need to know is that the stack is super local it's like created in this instant and we know exactly where it is it's close to us the Heap is like the Library of Congress everything that we need is accessible there but it takes a lot of like overhead and searching to go figure out where that data is and bring it back right and the point that you're making is if your language isn't careful about where it's storing data or relying much

too heavily on the Heap then it's really hard to understand what all the data is and going to do and how it's going to change without actually running the program yes exactly so the big difference is as far as we're concerned there's a lot of differences on obviously but as far as we're concerned the big difference is that the stack you know where things are just by reading the program or not exactly by reading you analyze it you might have to like write some things down in a notebook but you can figure out where they are without running the program and and things on the Heap you might not so uh one thing uh in smart contract land that I can make an analogy is uh is in Viper uh every time you access storage uh you

can actually kind of of know which variable is being accessed because you'll have something in the syntax it'll be like self. my variable where solit has this concept of storage pointers so you can actually like calculate some number while the program is running and then access that storage so again just to unpack in Viper world you say variable x equals whatever and because of the way Viper works we always know where X is and we can always check that value but with solidity um it like where the data is is this like Dynamic thing that is changing all the time and so the the only way to know what is at the end of this like pointers

to this data location is actually to run the program and at the point that you're interested in go check what all the specific variables are and then go actually look at it and and it might be different depending on what inputs you run the program with whereas Viper you can tell what variables are being accessed just by reading the program you don't even need a compiler you can just read the program or you can write a tool which reads it for you and is like a analyzer or something an analyzer an analyzer is kind of like a very a very stripped down compiler got it so the the idea just to wrap this all up is that some languages based on their fundamental construction create programs

that are easy to analyze and when you can analyze them you can debug them you can um you can audit them you can like as a human figure out if I put in this then I'm going to get this result and like they're very uh just like auditable if you will whereas Dynamic programs do have a lot of those capabilities but like the way to get them is to just run the program and um like Watch What Happens as it's happening and that's fine in a lot of cases but that's very dangerous in evm world where you can't undo things that go wrong yeah and I want to talk a bit about tur

completeness um basically all modern programming languages are what's called Turing complete and what Turing complete means is that it can emulate a turning machine and what a turning machine is it is like the quintessential computer and the reason tering completeness is important is because Turing machines satisfy What's called the halting problem so you can't actually tell if a program will terminate just by analyzing it you have to actually run it and by running it you might run forever and this is like really really important Concept in programming language Theory um which is that you don't actually know what the program I mean that's why

programming languages are so powerful um but you don't actually know what it's going to do at runtime so all turning complete languages have some kind of aspects or you are able to write programs which are undecidable but all programming languages being like kind of ways to express a program also have restrictions and where these restrictions are kind of makes or breaks a programming language right so all of all programming languages are going to have these areas where they're undecidable but part of the art of programming or the difficulty in programming language design is like figuring out which kinds of programs should be undecidable and which kinds of programs which kind of programing level constructs should be obvious just by

reading the program do that making sense yeah that totally does but before we continue let me summarize it and see tell me where I'm wrong but what you're saying is um we start with this concept of a turing machine and what that essentially means is that if you can prove something is like a turing machine then you know that that thing is capable of doing all things that a turing machine can do and why that's important is because a turing machine is basically as you say like a generic computer and so if we know that it can do if our language can do something that a turing machine can do then our language can do everything that a computer can do the the Paradox or the problem is that in order if we know that something is

turning complete that also by definition of turn complete means we can't tell if a program is going to like ever stop once it starts and I want to add that this this halting problem it can mean it the the the basic definition is that we can't decide we can't tell if a program is going to Hal but it can also mean I'm not stretching the definition but there's like some way of understanding this it it basically also means that you can't predict what a program is going to do so the program is undecidable and so okay so the we want a turing machine because that means that it can do anything a computer can do but we're nervous about Turing machines because if

we're given code that is like Turing expressable turn complete whatever term you want to use then we cannot know what's going to happen from running that code without actually running the code is that correct yeah exactly actually running the code with specific inputs so it might do something completely different it might blow up if you give it different inputs great like it could be like let's say it takes inputs as all the real numbers and everything works fine it completes in a millisecond but if you give it a fraction then it will continue Forever Until the End of Time and like in regular Computing like that's totally fine you run your program in like a little sandbox you make sure that that doesn't happen and if it does

then you can kill it or even in production you can kill it right in ethereum that's not an option like you do not control the computer and and like the whole point of it is that if you give it instructions it will continue forward and so like the the real problem that we're trying to get to here is that if when you're designing a a programming language you want to make sure that even though by the definition of turn completeness we can't like know what the end result of this computation or this program is going to be we want to make design choices that make analyzing the program and like maybe holistically

understanding what it's going to do a lot a lot easier is that right yeah and maybe that way of looking at it is like a little bit theoretical maybe another way of looking at it is saying that in programming sometimes there's things that you do that are kind of straightforward you know you take two numbers and you add them together and then there's other kinds of things which are like modifying storage or the file system or or interacting with the outside world which are like kind of more risky and a good programming language should make those things really clear and really easy to analyze and so I guess my I'm not sure how to ask this question that doesn't get us too technical but what what are the actual

types of design decisions that you're making in order to achieve like analyzability like do you maybe have an example off the top of your head that solidity does that makes it really hard to analyze that Viper understands and has made a design a designed decision to make easier yeah I think the concept of storage pointers is really good so Viper doesn't have storage pointers you can't access some variable without actually naming it so if you have two variables in a contract X and Y you can't touch Why without actually saying self-thought why got it and and in like solidity or like you know for the more classic languages like in C or C++ world like

you could pretty easily access or change the data in y by using the um by basically like manipulating the data in X to change the pointer to be pointing to the space where Y is but in a way where the program like doesn't really understand that I guess that's that's very hard to unpack if you're not a programmer but um the point is is that like Viper is setting explicit rules that like even on a technical standpoint it's possible to access this memory we're creating the language rules that says if you want to access the memory you need to do it in this very like clean and safe and readable way is that

correct yeah I I would say it's explicit got it and is that really kind of the quintessential thing that we're getting at here is that in order to make a language more statically analysable you need to find all of the places of ambiguity and enforce uh um enforce like specificity yeah and you want to think about how people are going to use the program you need to really get into the mind of a programmer so like a a language designer is like a programmer's programmer right and literally so you need to get into the mind of a program and be like okay I I mean we can talk about Theory all day right but at the end of the day you really need to get

into the pro the user's mind and be like okay what what are they going to do and then is that that decidable is that analyzable can we can we look at this program and like know what it does or is there going to be some kind of issue where you the programmer takes some language feature and then they make it do something that isn't analyzable where if you are an auditor and you're reading this code you have to think about the behavior of the code at runtime you know yeah and I guess like let's this is like so basic you're going to laugh at it but like let's imagine a world where like we have our you know in sorry we have our variable X and when we instantiate or

create the variable it there's a number in there right like an integer let's say like what it doesn't even matter there's an integer in there and in um like some languages like that the compiler will enforce it will not the it will not create the program if at any point it sees that in this variable X instead of trying to put a number in there you're trying to put like a word or a um some other type of object like the compiler will literally see this and say oh this is expecting a number we got a word error like abort everything we can't compile and then in some of these L looser like again C is the perfect

example that has no typing at all you say let variable x equal your integer and then maybe 10 steps down the line you call a sub routine that takes that whatever the values that X is and replaces it with the string and then 20 steps later you when you go look at X and you're expecting a variable and you get a string the compiler didn't notice that but your program will blow up at runtime because what I was expecting wasn't there um C is uh statically typed so normally if you try to assign something of a different type to X then the compiler will complain but in see it's also very easy to do a cast so you

can easily convince C that like X is now now a string or rather like a pointer to a character got it so but at a high level the so and it I guess to to bring it to its core like really you as a programming language designer are you want to make as many choices as possible that remove ambiguity and remove kind of flexibility without actually removing the ability for the programmer to express the program that they want to make is that like kind of the battle you're always fighting yeah I'd say that's a good way of characterizing it yeah so you're almost like a sculptor who starts with

like the full amount of material and tries to Chisel away like all the excess until you have the functional work of art in the middle yeah or you're like design you're like creating a tool set for sculptors so that it's like easy for them to do what they want to do but also not easy to screw up makes a lot of sense all right so we've talked a lot about um like the fact that you can have multiple languages then we talked about uh how Viper has made these design choices around um reasonability and security and simplicity um can we can we start to talk a little bit about like what are the types of uh applications that really benefit from the Viper approach and I

know the most famous the big one is curve so if you want to kind of talk a little bit about curve or any other type of project like who do you think the best candidates to be thinking in Viper as opposed to solidity R um I think actually um people who are learning about how to write smart contracts Viper is actually a very good entrylevel smart contract language and that's not to say you know you can't um do more powerful things with it I mean otherwise you wouldn't be able to build curve exactly protocols but Viper kind of you know as much as possible tries to strip away the noise yeah and it I mean it's sounds very similar to python right where it's like it's so much about readability and

just like understandability that like by learning to program in it you can immediately focus on what you're trying to do as opposed to like the weird quirks of like the language itself and so I think that's what you're saying is why like python is so sorry why Viper is so powerful is because it allows developers to jump to thinking about their apps as quickly as possible as opposed to like worrying about learning a new language yes exactly so um that that's Viper is it is today can you talk a little bit about like what does the development road map look like for a language like what are the types of things that you guys are working on and thinking about and um what do you want

to turn Viper into in the long term I think of Viper uh as kind of like Swift for iOS I want it to be the most natural language for programming smart contracts as to what goes into uh a language's maintenance over time is um you're always wanting to add more language features um and a lot of the way that happens is you actually look at how the language is being used in real life and reading code on GitHub or whatever and you're like that looks unsafe or that looks not very ergonomic like what can we add to the language or can we design a feature which makes that easier

is there some is there a new kind of tool a wrench that we can add to the language that's going to allow people to do this task in a safer way or in a more ergonomic way so like for example you might read on GitHub and see like the exact same function or function Paradigm in like 40 40% of projects and you might realize like oh if everyone is doing this maybe it could be served by like having a built-in feature of the language yes exactly and let me give you an example of that um whenever you call an erc20 token like transfer whatever uh according to the spec it's supposed to return some Boolean true or false and what exactly that true or false means uh

is subject to interpretation but that's not the important part the important part is that there's a lot of erc20 tokens which are known to be non-compliant uh so they don't return anything and so when you call them normally uh when the when you call a some function in another contract the compiler will insert code to check that the contract you called actually return back enough data in this case when you have a Boolean in like that's being returned from a contract it you should get at least 32 bytes and so there's all these non-compliant contracts which are not returning any bites and so in older Viper code bases you see a lot of this stuff which is like raw call so there's a way to bypass the the compiler's you

know checks or whatever and the compiler's way of constructing the call to this external contract and reading data and that's called raw call and what you'll see in a lot of these codebases is there's like this raw call and then people are like constructing the call data manually they're like Computing the method ID for this transfer thing and then they're like turning all these numbers into bytes like you you see this like ABI encode or concat and then you are going to check if it actually returned any data and if it did return any data then you make sure that it's true and if it didn't then you just kind of assume that the Target contract would have reverted if the transfer

didn't succeed or whatever and so these These are blocks of code that are like you know 10 lines long and they're like really weird and they're all over the place anytime you want to interact with an erc20 token and I don't remember exactly how it came up but I was like reading some contracts and I was like this looks like really tedious what if we added something to the way contract calls are constructed uh which would remove all this boiler plate and so you know I thought about it and discussed it with a few people and and eventually uh decided on adding this keyword AR this extra argument to all all calls and it's called default return value and default

return value will just put in a value when the contract you call doesn't return with data instead of reverting so now instead of doing this raw call constructing the call data um checking the length of the data that the contract returned to you whatever now you just do like token. transfer and then you add default return value equals true because that's what people are doing anymore got it so just to be like let let me make sure I understood what you said you said before like you could it's possible to you know request this data from erc20 and because the erc20 contract is non-compliant they would give you nothing or give you garbage or whatever and in previous versions of Viper like

that would cause the whole program to fail yeah and people would have to write all this boilerplate code in order to deal with that yeah and yeah exactly you and the team realized that like every single person was writing variations of the exact same boiler plate and not only you realize not only can we save everyone a bunch of time but because everyone's writing their own like boiler plate as a safety check like some people are making mistakes and getting it wrong and causing like Havoc so you just thought you know what a new feature of this language should be that like should solve this problem for us and that's how you upgraded Viper yeah and the neat thing about this feature is that it's

actually clear what you are doing which in my opinion is actually the most important part so like before you would see like raw call with a bunch of like data and then you have to like figure out what the programmer uh was trying to do with the return data and then like you have to read the code and try to understand what's going on uh and if you don't know if you're not familiar with the pattern it takes some time to get used to it um but if you see default return value equals true like you just look up the docks what that means and you're like oh sometimes contracts don't return enough data don't return enough bites and default return value just gives you a way to deal with that got it and so would you say that like most of the upgrades if not all of the upgrades

that you make to Viper Lang are um either like straight up security patches or this idea of looking for what developers are spending their time on as non-productive work and then figuring out okay is that something that can be incorporated into the language I'd say that's about 30% of it another 30% is finding ways to compile to evm code that's like more optimized it's either smaller or uses less gas that takes a lot of time and then I'd say giving people more data structures is important um which is kind of like this language feature but it's also like um data

structures are are their own thing and then and a big thing that I've been working on for or actually planning for a long time and a lot of people are I think excited to see it and also like Charles why is in this thing yet um is uh Viper module system which is really important um because the alternative is to copy paste code and developers should have ways to reuse code which isn't just copy paste and maybe this is too much hesitation on my part but I've been going about it very slowly for a long time because I recognize that like once you

introduce this module system and a good module system should feel like part of the language not like it was baked on as an afterthought uh it's kind of hard to change it and so I want to kind of get it right from the get-go and there's a few features which I think are really important uh in Viper's upcoming module system one is there's no inheritance so Viper is firmly in what I would call this contract oriented language Pro Paradigm uh as opposed to like an objectoriented language so contract oriented means that the programming

experience revolves around a contract and contract should not in my opinion should not have inheritance because one way to put it is that inheritance is a little bit like pointer aliasing except for code so we talked earlier about like figuring out which variables some storage pointer refers to and how that's kind of sometimes really hard to reason about and inheritance is kind of like that for code so when you have a lot of inheritance in a code base what can happen is that you kind of need to figure out how something is instantiated how some object is

instantiated in order to figure out what it actually does and by that I mean like what code is actually being run at run time so if you have like food. bar which bar is that and this can be like actually a really hard problem when you're reading a code base yeah so sorry let me just unpack that a little bit um for all non likee super technical people the what Charles is essentially saying is that today if you like let's say you create like a little function that all it does is take two numbers and add them together um today if you wanted to use that in two different places in your project you would literally highlight it all copy it and then paste it into the different part of your project and like if you if you know anything about

computer science like that is not what you're supposed to do and the reason very simply is you might decide at some point that you want to make a small change maybe instead of plus it's multiplication and you might go do that on your first place that you originally wrote the code you might do it on the second one but if you forget to do it on every single one then sometimes like your program is going to behave in weird ways and what inheritance and uh modules and all of this conversation that Charles has just had is about how can we let all every time it's the same code we want it to exist in in one place and then we want to use tools like importing from other files to make that code

available without having to like manually replicate it and have it live in different places and then as Charles was saying like that's a super powerful super basic feature of modern programming languages the problem is is it creates the exact same analyzability issues that we were speaking of before which is if your Cod isn't explicitly with like the rest of the code you have to go find it in other files it can be really hard to track down what you're actually trying to do um statically right before you run the program you might be stuck in just having to let it run and see what happens and so all to

say is a very hard design problem like it it's super powerful but also introduces a ton of surface area for um for failure and like totally makes sense to me that both people are just all on your case about adding it but also like there's not an easy way to do it yeah so like one very high priority design goal for Viper module system is that like when you see some function call you kind of know what it does you don't have to do any reasoning to figure out uh which function is being called I mean you might have to like open up a file but you don't have to like guess which file to open up yeah you don't have to open up a file that file depending on which

inputs that file will reference one of three other files then for you know like it's really should be super linear that if this code is called I know exactly what it's supposed to mean yeah cool well um in the last few minutes here um I I would be remiss if I didn't take the opportunity to ask you to reflect or to talk a little bit about the Viper hack um and just like I don't there's no reason to get too deep into it the reality is is that like you program stuff you put it out in the world like people are going to look for ways to break it and sometimes they do and like that's just life but I just um wonder if you have any higher level Reflections on like what happened and like what you

learned from that at the programming language level and uh yeah just how you how Viper Ling has changed after going through that Crucible so I think one important takeaway which is kind of obvious if you think about it this like really hammers at home is that the bar for correctness for smart contract compilers is is really high it's much higher actually than web 2 because in web 2 if you find a bug in some code you just kind of patch it and fix it and move on whereas with Viper or solid or any smart contract compiler it's not enough to just keep the current version up to date and bug free you you also

need to like always be checking old versions of the compiler because there could be contracts that are out there that were you know deployed with Viper 0.3.0 and they're immutable right they can't just upgrade to the latest Viper version they can't just recompile it because in in web 2 that's pretty much the mitigation most of the time you just like send people a new code everybody recompiles and then like they can move on with their life but in in web 3 in smart contracts are mutable land and that's not really possible and so we've kind of started to approach Security in a much more um so I want to choose my words very carefully here we've started

to approach Security in a much more robust way so first of all we've onboarded several very good audit firms to not just review Viper code like on a regular basis but also to approach uh Viper Security and in like a in a multifaceted way so to speak so that includes like writing tooling help find bugs and Viper that includes kind of review of older compiler versions that includes kind of you know differential testing so like if we take the same contract and compile it with you know different versions of Viper does it behave the same and if it doesn't then there's like some kind of problem and also starting these kind of regular or we've had one we've started one uh

competitive actually a Viper and we're probably going to have this do this on a regular basis going forward since it's you know seems to be a very robust way of getting a lot of eyes on the code base so I guess like final question on this did this experience make you think of um the having upgradeable contract smart contracts differently at all I mean I guess what was your your feelings on should smart contract be immutable or upgradeable and um did this experience like alter your ideas on what best practices are not at all okay so what's the best

practice I mean it's very tempting it it's very attractive right you know you compile this contract with some version of Viper or solidity or whatever and then this contract is immutable right but then sometime later it turns out that there's a compiler bug in that specific version that you know you were using and you want to upgrade it you want to just like recompile the contract it should with the new version of the compiler it should do the same thing so there's should be like no problem with that you just recompile it and redeploy it and and and then there's no more bug and that's actually more problematic than it seems on the surface so first of all I think that immutable smart contracts are a good thing in general as a design choice you know you see this

contract and you want to interact with it and not everybody maybe has the the technical capacity to do this but in principle you can like read the bite code and you kind of know what it does and it's very desirable from a safety perspective in a lot of ways to know that like if you do something with this contract today and you interact with it tomorrow like it's also it's always going to be the same contract and this idea that recompiling a contract doesn't change its behavior isn't actually true for instance the Viper team could like just like completely change the language so like xals 1 does like something completely different in two versions than it did today and that's like obviously you know bit of a silly example but that kind of thing happens

all the time which is that the behavior of the language changes subtly between versions so if the storage layout ever changes you know between versions X and Y and then you recompile your contract with Version Y it's actually going to have different storage than you originally started and that's basically a a very similar problem that upgradeable contracts have already except that it's not really hidden in the compiler but people already you know need to be very careful when they're upgrading contracts that they use the same storage as they were before and I think that there's this kind of perception that the source code of a program kind of defines what the program does but that's not actually true it would be an exaggeration to say that the compiler takes your source code does

some stuff with it and then like outputs whatever B code at once but in some ways it's actually not entirely incorrect languages have ambiguity they have like a lot of undocumented Behavior they have undefined Behavior Uh which is very well known in C I'll take a digression which is that like in C there's areas of the spec which are terms undefined behavior and these are things like division by zero um accessing uh invalid memory and what I think what the spec says or maybe this is just the general convention is that when the compiler sees code with undefined Behavior it's all do whatever it wants and in practice this usually

just means that it can optimize the code better but it can also fire the missiles or you can inate code that fires the missiles or whatever and so the source code is actually not the final say on program Behavior Uh what the program actually does is defined by its bite code and so this concept that you can just like recompile a contract and it'll do what you want it to is basically flawed the program is really defined by by the bite code and yeah I mean if that were the case then you could like take a an independently implemented version of the Viper Viper compiler and like compile the same program and you would get the

same bite code but actually uh when all whenever you take you know two compilers and you implement the same and sorry you compile the same source code you're going to get like different machine code yeah so sorry just to um Focus that so when when it comes to like developers creating D apps like their choice is either to like issue an immutable smart contract or to issue a smart contract that points to a proxy and we can change what what which proxy it's pointing to therefore we can kind of like upgrade the smart contract and I think the point that you're trying to make is that like this immutability is like a feature not a bug of ethereum and we should like

really like understand and appreciate that and yes like it introduces some risks like what happened with uh Viper langing in the hack before but like we're gaining some very powerful things from that which is the ability to know that whatever happen whatever that smart contract did yesterday will happen tomorrow and like you don't want to be so um dismisses dismissive of that is that correct yeah yeah cool all right man I'm so sorry I feel like we could keep going on for a long time but uh coming up on an hour now so before I let you go will you just like let the audience know um where they can find you how they can learn more about

Viper and if they want to contribute like what should they do yeah so uh there's a lot of good ways to get involved if you want to learn more about the Viper source code or contribute you can go to the viperline GitHub which is github.com Viper Lang l n and Viper of course spelled VP R you can find uh you can follow Viper on Twitter which is also twitter.com viiper Lang LNG you can also follow me on Twitter which is bigor teore sux sux and you can also join our Discord and the link to that is on our GitHub page there's not a a really easy

human readable Discord link cool all right man Charles thank you so much I this is like a really really cool conversation to me because um there's not a lot of people that are thinking about like really tooling and like design principles and to make basically this space more accessible and like the a platform that can be built on and so I just have so much respect for like seeing a problem seeing a need and going out there and building something that is not only like cool and works but um is robust enough for you know the Beating Heart of uh D 2.0 or or what however you want to put it but like the proof is in the pudding with Viper Ling right and

it's it isn't for sure with like the compiler you've built and everything that's to come and all that stuff but like the the real proof for everything is like our people using it and so um it's very cool that like just like we have client diversity we now have language diversity and I think that's in the going to be such a huge like part of the journey to the world computer so Charles thank you so much really appreciate it and uh hope to talk to you soon thanks so much for having me Rex