David Knott: Vyper Safety First Smart Contract | ETHDenver

our next talk is someone who is part of the Colorado blockchain community and a complete rock star in etherion it is my honor and privilege to welcome David not to the stage David is working amongst other things including plasma on VIPRE which is designed to be a new language that builds informal verification and addresses a lot of these security problems that we've had with smart contracts at the root this is going to be super awesome and let's have David do it thank you so much Ken that was sweet I feel warm and fuzzy inside after that awesome so first I'm just gonna start by addressing the question on everyone's mind is it VIP ER or V Y P er it used to be VIP ER but that turns out shocker another language had that name so we took the high road and have started to shift gears towards Viper with the Y and so that's what I'm gonna be talking about today Viper is a safety first smart contract programming language for aetherium I'm having a blast working on it and hopefully some of you will choose to code in it for your smart contracts for this hackathon and yeah this is gonna be fun so we'll start with a little history for those who attended the past talks you probably you might remember this but if you don't here goes so how kind of smart contract creation works right now is you have high-level smart contract programming languages such as serpent solidity and Viper don't use serpent and use Viper soon in production but not yet these languages compile down to e vm bytecode and then they're run in the EVM which is basically a single threaded computer that's run around the world which is super cool but nothing is for free and so to prevent denial of service attacks so basically angry people who want to hurt in this case aetherium we basically have to limit their power to kind of take up the bandwidth of aetherium and to do that we use gas so basically whenever someone sends a transaction on aetherium they have to basically pay with ether which is cryptocurrency and they pay in denominations of gas and so they're basically paying for the bandwidth they're taking up on the etherium network each opcode of the etherium virtual machine has a specific gas cost sum those together you get the total gas cost of a transaction supercool stuff but there's another snake in this story and that snake is serpent serpent is a smart contract programming language that's also pythonic and it looks something like this any of any Python devs out there may recognize some of the syntax hopefully and so some facts about serpent was written in C++ it has pythonic syntax unfortunately it was never widely adopted and this is one of the reasons why down the road it was deemed unsafe by a security audit because there was never really a big enough community of developers behind the project to keep it up to date with aetherium security standards yeah and after it was deemed unsafe it was a little too late because logger already had quite a bit of money in production using serpent smart contracts and so after this audit came out the choice was made as opposed to fixing up serpent and making it safe that it be easier less costly to simply switch their smart contracts to solidity and they did that and yeah even vitalik the creator of serpent said don't use it he tweeted I now consider serpent outdated tech so if you learn one if you learn two things from my talk the second thing should be don't don't use serpent it's dangerous you'll lose money just not fun so now I'm gonna get into what you all came here for I'm gonna talk about Viper the programming smart contract programming language that is awesome I'm about to tell you why so when designing Viper there were a few things that were prioritized a security be language and compiler simplicity and C auditability and I'm just gonna go through this and explain why so security the main principle that VIPRE uses is that it actually limits and cuts down developer choices significantly because a lot of times you don't actually need the freedom that a Turing complete language provides when you're writing smart contracts so the goal is basically to make it super easy for developers very simple safe contract contracts and using some of the more kind of mesh features is it's like it's a very it's a double-edged sword you can do cool stuff but you can also lose a bunch of money or like in it's a lot easier to write unsafe good so VIPRE this allows a lot of those things an example of one thing like we've done with syntax this is just an easy example is transferring value solidity has two ways to transfer value VIPRE only has one and we've kind of taken that to the next level in the sense that we're really trying to like standardize the way VIPRE works so another example would be with type conversions there's one way to convert between types and so yeah standardization is cool one way that works really way to do things makes it simpler and safer language and compiler simplicity so the solidity repo has 120 3495 lines of code the viper codebase has 19,000 424 lines of code there are a few reasons for this one is VIPRE is still under development so it's still MIT it's a lot younger than solidity it's still growing much quicker but another reason is that the VIPRE compiler is actually written in Python as opposed to solidity which is written in C++ and this design decision was made for a few reasons one of the big ones was to facilitate contributions there is a beautiful Python ecosystem out there that we kind of tap into when we have the compiler written in Python so yeah we've basically Fatah who created serpent and Viper learned from serpent C++ code base it's harder to maintain when you're relying on a lot of open source contributors and so boom now it's in Python it's smaller it's quicker to iterate easier to audit auditability so VIPRE prioritizes readability override ability and this is because if it takes a smart contract developer a little longer to I could that's not great it's some extra billable hours but if your security auditor who's one of your last lines of defense can't has a harder time reading your code or has to hold more things in their head they're more likely to make a mistake and that leads can lead to large consequences in most cases large monetary losses in some form or another so facts written in Python Python extend tax production soon it's currently feature complete of there's still a little syntax finessing going on if any of you choose to use VIPRE for your smart contracts this weekend I would love to hear your feedback on that what do you like what do you not like make an issue if you're feeling bold make a PR maybe you'll be too busy this weekend but maybe sometimes it's a cool project created by vitalik as I mentioned before and for some of the reasons that I'm going to get down and deep into it's best used for smaller applications so solidity is currently by far the primary language used in production when it comes to aetherium smart contract development and so I'm gonna compare them and don't worry if I'm gonna kind of glaze over this but then I'm gonna have individual slides to cover most of these points so don't worry solidity supports dynamic loops vipir fixed loops solidity inline assembly VIPRE only VIPRE code is allowed solidity default number is a UN 256 fibers is an int 128 solidity supports inheritance and modifiers VIPRE does not support those and solidity is very writable I would say VIPRE just went in a bit of a different direction and the main goal is readability as I mentioned before but let's get into the nitty-gritty so fixed iteration versus dynamic iteration and kind of on that note while we're talking about control flows recursion so basically fixed iteration means in fiber when you have a loop which is basically iterating over a certain piece of code over and over again you have to specify that amount of times it will run at deployment with solidity you can do dynamically so someone could put run ten times someone else could put in run something a hundred times and yeah it's super it's more flexible but it opens up a lot of potential attacks it makes it harder to estimate gasps and kind of on that same note viper disallows recursion so you yeah I'm not I don't really want to get into what recursion is right now but for those of you you know what it is it's basically like another form of looping and yeah solidity allows it awesome and flexible but it can be dangerous recursion can be tricky sometimes and it can open doors for some potential attacks inline assembly so we're gonna start using Bob now so normal language we have give Bob $100 that's pretty simple clear everyone should be able to hear we have the phonetic form of that give Bob $100 exact same meaning but it's a lot harder for read anyone reading this is a lot more likely to make mistakes and that's kind of how I think of inline assembly granted it does allow developers a lot of freedom and flexibility VIPRE basically says if you need that go elsewhere but if you want to stay safe and you don't need that kind of super granular flexibility use us because down the road it'll make your code safer especially in audits it's a lot easier to look over like solidity or Viper than it is inline assembly once when you're dealing with like memory management stuff is this overriding this easy example would be the delegate call opcode which is in inline assembly and it's once again super cool to use but if you don't use it correctly very quickly you can take the sad path and yeah not fun so default number inches VIPRE supports two to the 127th minus one otherwise known as in 128 solidity supports 2 to the 256 minus 1 otherwise known as you went 256 just to give you a rough idea of what those numbers kind of signify there are currently it's estimated only 2 to the 78 stars out there and in terms of atoms it's 10 to the 78 so solidity could count the atoms in the universe VIPRE only is able to count the stars the reason this choice was made for VIPRE is because the EVM works with 32-bit chunked or 32 byte chunks basically once we cut down the number range it makes it really easy for us to start playing around with decimals yeah [Music] and modifiers stick it that I'll stick with that one so inheritance and modifiers basically decrease repetition heavily by allowing developers to import code from other files and to reuse code over and over again and so it's super good for IDE ability it can get pretty tricky very quickly when it comes down to eat up readability just because all of a sudden when you're reading through a smart contract all of a sudden you're you see one function it has like five modifiers you're jumping at the top of the contract Oh way this function also then calls another function from another contract and you can just be kind of it makes it much easier to get lost in kind of the control flow of the program and makes it harder to follow so VIPRE doesn't allow inheritance of modifiers so if you're doing stuff that you would use inheritance for it your code will be more repetitive but that is basically a design choice and hopefully your code will be easier to read so yeah more basically I would say VIPRE more repetition in terms of that stuff but I would say you shouldn't be using VIPRE for huge applications so that probably shouldn't be a huge issue and you can do an incredible amount of cool stuff with smart contracts in a relatively small amount of code yeah one of the things that like you notice most I would say when using VIPRE is kind of when I write solidity I use modifiers for permissions so like only owner only the owner of this is allowed to access this function and with VIPRE you just have to check for that inside the function itself so now you have options and here's kind of how you how I'd like you to think about them solidity use it now if you're pushing anything to production you solidity I want you guys to be safe minima it's great for minimizing repetition inline assembly offers a lot of flexibility you basically gain access to the entire training complete language when you're using solidity so yeah it's a super flexible super girl cool super great for low level optimizations if that's what your smart contract requires and it's JavaScript like so if you're like yes JavaScript I go might want to go more towards solidity VIPR smaller applications mutability and it's pythonic so what's happening now with VIPRE why isn't the production ready and the answer is right now we're still thinking a lot about the best way to be compatible with solidity contracts because solidity is the golden standard right now for how etherium smart contracts are made and because there are so many applications using a you in 256 basically we have to make it's super smooth for fiber contracts in 128 to basically interact with the different number a number inch because we want people who deploy VIPRE contracts we want them to be able to talk back and forth super easily we're in the process of so AV eyes are basically interfaces that are used to call smart contracts and so we're in the process of converting changing from the decimal type to a fixed type which is basically means converting from a relatively high level decimal representation to a more low down low level bytes decimal representation we're doing the final preparation for a code freeze so unlike with serpent where I was audited once it was in production Viper will be audited before that we're very happy about that we're still working on edge case testing as more people start to play around with Viper there are always fun bugs that we get to solve popping up all over the place and documentation yeah anyone who tries to use Viper this weekend the documentation has come a long way but it's not it's not there yet and so that's it's a work in progress boom this guy so Jax could not be here with us because he lives in South Africa and so yeah he has his own thing going on but he's working full-time on fibroids he's killing it on the bit on the day on a daily basis like if you guys submit an issue he might be one of the guys who responds super super cool guy and the future of Viper the future is up to all of you hopefully some of you have been convinced to take kind of the fun path and explained with Viper a bit during this hackathon any questions and I can do questions now or I could do some live coding and then do questions it's you ah so at least for me and most of the people I've talked to you as soon as you start getting into bigger application the ability to my tomahto her eyes things become super important and Viper basically supports contracts in one file and as you as soon as you start dealing with say a thousand line smart contract or more than that in one file that becomes very very hard to read and so yeah the lack of imports inheritance and modifiers oh yeah 100% why is Viper only good for small applications and do you remember the answer I can also okay awesome what's up you yeah a hundred percent so yeah the decision was made because oh sorry so why in 128 when the world is using you in 256 why did we decide to be different and it's basically because it's a lot easier to support decimals because we're dealing with 32 bytes so basically reducing the number range we're storing allows us to jump over into the decimal decimal range is significantly easier does that oh yeah I hope that answered what's up you you a hundred percent so actually there is currently ke Viper semantics right now so K is a language per formal verification and so a formally verified version of Viper is currently being worked on and yeah it's a work in progress they're helping us catch a lot of bugs that might have been overlooked at first initially and so yeah we're kind of working with them and yeah it's awesome you I think both languages I guess I wouldn't choose one I think VIPRE fulfills a great niche and solidity and I think formal verification full form formal verification is coming for both yeah why if how does PI aetherium interact with the etherium ecosystem yeah so right now a viper is currently using pi aetherium which is a Python implementation of the etherium virtual machine for testing so we're plugging just directly into the EVM which is super fun because if you for testing if you want to look at what state is it's literally just like a few dots and function calls away so that's kind of how we plug into that we've also integrated with populous so yeah populous is an amazing amazing framework created by Piper who's kind of like the king of the etherium Python ecosystem and we are basically if you want to develop in Viper if you don't want to hand roll a lot of the deployment stuff which could be another adventure I would use populist which is like basically the Python equivalent of truffle cool yeah you in terms of so vipre doesn't really protect against denial of service attack because that's done kind of at the UVM design level a through gas where you're paying for a computation so yeah dynamic arrays creating them is relatively expensive in gas they cost gas and so you couldn't say have a while loop pushing to an array because you'd run out of gas and then your transaction would fail that answer your question awesome so what uh no dynamic I would say like so right now VIPRE does supports trucks in terms of like dynamic arrays No a static array of strings right now I write your VIPRE does we don't have the strings type so where you use bytes but you can support strings in that in a static array yeah cool I can I can show you guys some tools I'm pretty pumped about that or I can keep answering questions it's really it's a kind of a choose-your-own-adventure type of thing but here I can see the clicker so a community contributor has been so kind you guys can't read that at all I can barely read that but okay that's a little better so a community contributor has been super awesome and created a VIPRE online compiler once again you should not use this for production this is not the same as me mix because it's basically we haven't worked out how we're going to basically take the Python compiler and run it client-side so this works you guys could use it at the hackathon as a easy way to kind of dip your toes into Viper but in production it's insecure because you're relying on kind of a trusted party and a server so yeah this is an amazing tool I use it sometimes it's quite fun here are the is the Viper documentation if you want to get like deeper down into the code base I would check out the Viper read the docs and finally if you actually want to use Viper there the easiest way is probably through populous and yeah I'll show you guys so it's as simple as creating a virtual environment in Python which I highly recommend you do for all Python projects because otherwise your stuff will get destroyed and then right now is that because vipers always changing the easiest way to do it is to just install it from the github repo itself which is awesome I already have it installed in another tab surprise so we don't have to wait and then yeah basically you can get there's a command-line interface so if you want to compile VIPRE contracts you can basically type VIPRE and then the path your contract so in this case we have the contract a greeter contract and yeah and over here you see the bike code if you want to get the ABI it's as easy as typing in a flag and then you get the ABI of the given function so it's pretty simple to use and then once you start using it with populist a lot of the deployment stuff in testing is kind of abstracted for you making it a lot simpler and then yeah I'm I'll just go into some actual viper code and alright some explaining what's going on and yeah hopefully you guys will enjoy so something to keep in mind is that we're able to utilize the Python syntax highlighting because we are using the Python ast parse module and so that's why as of right now we're using dot V dot pi just we're kind of picking off the pythons index dividing and so to start writing a viper contract I would say at the very top you want to declare your state variables so anything that you want in state so for this we'll have an owner with an address and then let's say we want anyone to be able to access that owner through the chain we'll create a getter for it using public ah and then we'll basically create a function for it let's say we won only the owner to be able to call this function so we'll call this function boo and then we'll assert a self dot owner so we're sticking with Python and we're gonna call the owner here and assert basically checks it kind of checks something has to be true if it's not true it will flow of burped which basically ends the transaction refunds the gas you have remaining for the computation and and basically leaves the state as it was when you first started the transaction so assert self dot owner equals a given address well create will create an init function where we basically declare the owner so we're able to check for it later and so you're just able to set state variables pretty simple we'll use message sender message dot sender is the same in solidity and it basically allows you to access the environment of the transaction so message sender gives you access to who called where the transaction is coming from just a quick note message dot value would give you access to any ether sent in the transaction so you can kind of play around with those things so here we'll set self dot owner equals message go sender now we'll check for it here and still we'll check that message sender so only the owner can call this and then we'll return you're the owner and to return in Viper you use the arrow syntax and then you put the datatype so in this case we specified the amount of bytes that will be taken up so to be you can specify any amount of bytes but it's really as simple as but just for simplicity we'll keep it at like 40 bytes just because it's a lot shorter than that and so that's that's one Viper function Viper has a lot of cool built-in functionality that I will show you with a more complex contract that I won't code in front of you so this is a market maker contract it's a super cool contract it basically allows someone to create a contract deposit ether and a given token in it and then anyone can call the contract to basically get like sell ether get a token or sell a token and get ether and yeah so it's super cool great way to liquid kind of like decentralized create liquidity on chain and yeah so as you see here as you can see here we're basically declaring the state variables on top so we're keeping track of total eve quantity total token quantity and then we're creating getters for those then we're creating a the invariant which is basically it's basically a value that is set on initiation of the contract when you basically multiply message value times total quantity to basically get the rate at which they'll be exchanged between each other and yeah super cool and then so when we're starting it off as you see here you put in the token address you put in the token quantity and then you put you do a typical transfer from which this is solidity compatible and so you're basically able to reach into an ER c20 contact contract and retrieve tokens from it and then now this smart contract will have ownership of both the ether and the tokens that the owner is depositing this does not use the pipe current viper and nate functionality it basically does it by using straight asserts so it can't be called twice because we're setting the invariant within this block here at the top we check if it's zero and then we check that it's greater than zero so it can it basically in functionality is the same as in as an initializer then here we have decorators so this is basically how Viper how we state function invisibility every function has to be either public or private this is to prevent mistakes where someone could leave leave a function without one of those and it could if it defaulted to private that would be bad because then someone who's not supposed to get to it could potentially call it and once again potential money loss and so yeah this app public does what you could probably guess it makes it public and then app payable allows a given function to accept either and so without that app payable it will just throw if you try sending ether to a given function in a contract and so as you see what's going on in EFT tokens is basically we're the owner of this contract gets a small fee before providing liquidity then then you basically you calculate the new totals between Eve and the token so basically now the contract has more eat less tokens so the exchange rate changes due to arbitrage which is super cool and then you basically send the person who sent Eve tokens in return at the given exchange rate and it's the same with tokens to Eve so the way this basically adjusts with market prices which is which are always changing is through arbitrage so people basically constantly ping this contract arbitrage in it and that's how it stays balanced with current market prices which is super cool and then finally when the owner is tired of providing liquidity maybe they want to buy a new a new car with the fees they received from providing this liquidity they just call owner withdraw once again we're checking that message sender is the self dot owner and yeah just sending the tokens to the owner and then destroying the contract and I don't know to me this is a pretty great example of Viper because it's a fairly small contract but it really highlights a lot of functionality and we kind of how readable Viper can be and the big things you can do and only a little bit of code yeah cool cool oh yeah cool yeah that's basically a general overview of Viper I'm happy to go more into detail in more code I can answer more questions or yeah it's up to you guys yes what that is has been right now know if you could write your own decorators that could be the basically point against it is that it would open up the possibility where people could basically write misleading code and I call it decorator one thing but it could actually do another thing so in an effort to be safe no but that feature has been discussed because kind of as I mentioned before especially when you're dealing with permissions it's super nice to be able to use the same permissions and checking various things and so yeah one middle ground that's been discussed is basically by increasing the number of like supported decorators to include support for permissions yeah super cool awesome well I had a blast presenting with you guys I really hope someone use this VIPRE if you do I will help you out if you have any issues and yeah this is gonna be an awesome hackathon so it's been fun [Music]