DevTools Summit | Vyper + DeFi = 💘 - crv.mktcap.eth

[Applause] [Music] so without further ado like to welcome garrett it's going to talk about how do we actually use viper and build more interesting things and use deepai's example base for getting the best out of the viper lane so carrot uh feel free to turn on uh your camera and uh get started excited to have you hi croctic thanks very much for having me very excited to be here and addressing uh everyone worldwide i think you nailed it we're here to talk about a lot of uh topics around uh some specifically some of the tooling that i think makes viper really really great and in particular the use case that i'm going to be focusing on is how you can apply viper to d5 but uh open to kind of talking about anything what have been some of the kind of highlights you've seen so far you are the third talk and we're just sort of ramping up as we kind of go into uh more and more in depth of different devtools and sdks out there so i feel like people are slowly building towards um learning about the internals of libraries that they use like ethers and vlogme and we're gonna kind of start from languages to to sdks so that's the plan for today excellent excellent um so i'm yeah i'm very excited to be uh giving this uh talk here let me get my screen share going real quick um because this is a bit of a modified version of a less technical talk that i was giving in etham um back there is focusing on introducing viper to a broader audience but it was not a technical talk specifically so in this case i'm going to be talking uh more specifically about some of the tooling uh specifically brownie and ape works as well as the newer titanoboa uh so all of these are really great tools they can be in uh for the first two used with solidity as well um but uh titanoboa is native to viper so first i'm going to give a bit of background because i expect most people are very familiar with solidity and i want to talk a bit about some of the things that uh some of the some of the origin story behind viper and how it is that it came to be what it is and where it might be advantageous in some ways uh or it might have some drawbacks so many people don't know this but viper was actually started by vitalik himself this was his concept uh way way back it was a language called serpent and it has quickly outgrown uh vitalik's initial vision for this so viper is uh no longer directly developed by vitalik but it has sort of like evolved and the community took it over and really decided to take this into kind of the next level and while you might think that this means that vitalik is in some way casting aspersion on solidity or something like i just want to start this by saying that i teach solidity for night class so i like solidity i like viper i think both are great languages and this is not intended to cast aspersions on any particular language but i just want to give some pros and cons of both and also to point out that all of us are really united in our shared goal of having multiple different languages like the evm uh the ethereum foundation is actually working on additional languages beyond just viper and solidity because we want at the end of the day all of us united in wanting more great smart contracts to get deployed so if some people want to deploy using solidity some with viper and we have 15 other languages that make more developers comfortable and feel good writing code like this is what unites all of us so for example one of the other emerging options is fe uh there's a lot of hopefully we end up with a lot of different ways because at the end of the day these are just human level abstractions and what we're really trying to avoid is writing this extremely raw level byte code because anyone who's had to manipulate byte code knows that it's not as bad as it first looks but it's much better when you have these higher level interpreters that allow you to do that allows you to do like much more significant like uh significantly readable and understandable options and this gets to why you might pick viper over some of the other languages because more than a lot of other languages i really see how viper as a language has been shaped by its core values so from the start when vipre was launched it decided to rebuild this sort of smart concept of a smart contract programming language around three core values uh the first is security and anyone who's been cryptocurrency knows that this is absolutely critical because there's such an amazing number of hacks it's mind-boggling and viper wanted to address this with this actual syntax and say that at the development level it should be possible and actually just fully natural to be able to write secure smart contracts that is if you're a new person writing the code it should have security embedded by default so that you don't have to have an advanced level of understanding to be able to write smart contracts that aren't going to get hacked the second value is simplicity it always strives to make the code easier to understand for the reader even if this comes at the expense of the writer and going a bit further it prioritizes simplicity for readers who even don't know how to code and this is one of the reasons that viper is architected off python because python is code is fairly reasy to fairly legible even to people who don't understand what's going on with its human readable syntax and this ties into the final point of auditability because we know that auditors do their best but they can't always catch everything can be very very difficult for auditors to catch all the bugs in code so viper wants to make it difficult to write misleading code and this has fueled a number of different design decisions so if you're familiar with solidity when you're getting started with vipre you might be confused by some of the things you're very used to in solidity not having an equivalent viper it was chosen to simply not included at the core like architecture level because it sacrifices one of these principles for example solidity it's common to include like an only owner modifier viper doesn't have modifiers because they thought that it would be too much work for auditors to have to jump back and forth between modifiers and the function calls to understand what's going on similarly there's no function overloading because that could be a security risk you could have an overloaded function where you're expecting you're calling one version that's fine and you actually call a different version that does something different um vipre is not turing complete because the evm is itself not turing complete solidity is technically turing complete but it's running on a non-touring complete evm blockchain so viper within the language caps all of its loops solidity doesn't you could theoretically write an infinite loop in solidity it won't execute because the evm will run out of memory before it can execute it so viper puts this restriction into the coding and this can be an issue for some people because you have to have all your arrays capped it used to be the case you couldn't have dynamic arrays now you can but they still have to have a maximum size and because of this viper is not having to use this dynamic array pointer when it's deploying code which means it can deploy very very efficiently but it also has this trade-off in that you aren't able to um you aren't able to have like an unlimited array so for example if you have to define the max up front that can be off-putting some people another one we'll talk about is no raw byte code and uh no inheritance although this is going to change so no raw byte code means that there's not a way of just injecting raw a couple of lines of byte code here there because it sacrifices this capability of being easy to audit with solidity you can inject raw byte code and as a result solidity actually has the advantage on this if you need to if you need to uh for example like um we had we'll talk a couple of a couple examples where being able to inject raw bite code gives solidities incredible efficiency but it comes at this expense of readability whereas viper forces the readability and relies on the compiler to get the efficiency out of it and no inheritance for now is another drawback which we're going to talk about in just a second but this brings us to where these different principles and this difference in architecture has really caused sort of in my mind a difference in the ideal use cases so viper has a lot of advantages in terms of it's really efficient in terms of compilation costs uh and generally speaking it's slightly more gas efficient out of the box but some of these things give it a bit of drawback so i'll be the first to say that viper has never really been good at nfts and as a result i think that viper has kind of seeded this ground because solidity's advantages make it a sort of natural fit for nfts so we mentioned that some of these advantages of viper are things like it's very good at gas optimization but nft people don't particularly care that much about gas optimization every nft that gets minted has a theoretical optimum price and it doesn't really matter to the user whether they're paying that to the contract or they're paying that in the form of gas wars and as a result we've all seen the experience of wanting to make a transaction and having to wait because the gas prices have just spiked because there's some new nft drop it costs point zero one eath to mint and people are spending five hundred thousand dollars to mint it in fact this year um the other side meta um had a uh set some records in terms of the amount of uh gas that people were paying to mint this so even though viper made an advantage on gas it doesn't really matter in this space um similarly like viper might be more auditable but generally speaking like nft contracts are fairly easy to kind of cut and paste so they really benefit from the solidity capability of importing modules you can for example use open zeppelin templates if you're at all not concerned about gas they cost a little bit more but they're very readable so it's easy to kind of be able to plug and play and no one is really particularly caring when they're auditing this because they're not expecting to get money out they're throwing money at it hoping get nft out and they don't particularly expect that their deposit they don't work if it gets hacked they just care about reselling their nft at a later time so as long as the core nft contract works like you can just use the open zeppelin documents and you'll be fine and by and large like a lot of nft people are not going to be reading through the code so the corollary to this is that viper kind of punches above its weight in defy in my opinion because people do care about things like security auditability and these core values that have been built into viper so it's sort of slight because by far like 99 of contracts are still solidity but i say that viper punch is a bit above its weight in terms of the total volume that's been entrusted in dollars terms to viper contracts um even though it's about like 99 of all contracts or solidity viper has uh about 10 to 20 percent of the tbl uh largely through like curve finance urine uh lido finance uh similarly the gas optimization within solidity within versus viper benefits viper and that a few way worth of gas savings can be a huge difference when you're talking about smart contracts in d5 it can be the difference between using one exchange versus another so for example it's very common to see uh one exchange will be cheaper in terms of its like underlying gas usage uh sorry it's cheaper in terms of like gas usage but might be more expensive for slippage and if whether it's a big or a small transaction you'll you'll default to one or the other and finally the a lot of the kind of um underlying um properties of how vipre has been architected at the compiler level includes a lot of higher level math functions and i think that for a lot of d5 contracts we've seen we're really scratching the surface of kind of more complex functionality built into it and a lot of the math is there and screamingly efficient within vipre contracts moreover there's no such thing as a stack too deep error within vipre so if you want to write this contract with extreme levels of complexity it's just a bit easier to do it using viper so my contention is that they're both good choices for in some cases they might be better suited in a use case both are actually solidity and viper are great for both of these so of course like there's some really fantastic protocols built in both solidity and viper but recently there's been this phenomenon emerging which has been popularly called hot viper summer which is where this past summer more people have been looking at viper and giving it kind of a second look and trying it out part of this is because vitalik former founder of viper went ahead and started to promote it but the real difference was when viper 3.2 to 3.3 got released and before this there's actually structural differences like you couldn't have some abi types in viper that were supported in solidity and this is one of the reasons that viper really was bad at nfts which was that you couldn't have a bytes4 type and viper before uh version 3.3 and the openc api required this for checking interfaces so it was not possible to get a viper nft on openc to my knowledge maybe someone figured out a hack but i believe i'm the first person to have done it so i feel uh pretty excited about that so people started taking a second look at viper and found that when they first started a year ago it wasn't quite there but now it not only has all these efficiencies but the in compiler and the interpreter is really great to work with so this became at this point more like a preferential choice like there wasn't any structural reason why you might need one or the other and people started saying well let's take a look and see and now there are different arguments against um against viper that started to emerge like some people said the ecosystem wasn't as big as solidity which is very much true the solidity ecosystem is huge uh the viper ecosystem is small but very very friendly and i would definitely invite people to join the discord to find out more about it and this brings us to tooling which is the second thing that was listed as a drawback um because there is a lot of advanced tooling that's been created for solidity but in the past few months vipre has really caught up on the tooling level as well particularly when we get to titanoboa to talk about it so as we dive more into this uh question of vipre tooling i wanted to bring up one of the first things that people always bring up which is foundry support because viper here's one particular person who tried uh who tried using viper during hot viper summer and found it worked pretty good but was still looking for a bit more deep foundry integration and when you're dealing with complex contracts felt familiar with foundry so for people who do want to use foundry we're not going to touch too much on it but i do want to point you to this uh repo that ox kitsune has been making called foundry viper and it's very actively maintained and it's um foundry template that allows you to compile and test viper contracts so if you want to work within foundry you can do this similarly if you like hard hat there's a hard hat plug-in but a lot of people within the viper community opt for brownie and i wanted to walk through a couple of use cases of some like erc erc20 applications using brownie so if you're not familiar with brownie it's a python based development testing framework and it supports solidity as well and uh it works very well solidity i've used brownie to build entirely solidity-only repositories and applications but because uh brownie is itself python based it sort of is a natural fit for vipre which is itself also viper based and it uses pi test for its testing suite and if you've had the privilege of using pi test you'll find it's a very robust framework it can do many things that you need to do for building out tests for your contracts including property-based and stateful based testing using hypothesis um and then there's a bunch of great debugging tools built into it so it's an incredibly robust framework uh for testing a lot of these d5 applications that are built using viper so curve has built out a very extensive extensive repositories uh in which they have robust testing for incredibly uh incredibly weird edge cases using brownie and because it's been very efficient at utilizing this pi test framework it's been you know to date there's been not a single backend hack of curve although i'm always afraid to say that because i might look over and see that while i'm speaking it got hacked but i'm going to walk through just a couple of quick use cases for how you can actually use brownie to quickly get up and running using a simple erc20 token so within brownie there is a bunch of pre-built brownie mixes and these are some templates that people have created and published to github that allow you to just quickly import a project into brownie and i'm going to use the example of a viper token which is going to just clone the repository and create a viper token just like that for us to work with and we'll pop into here and i'll take a look and walk through what this uh default token looks like and it's still on version 2.0 but this should still work fine if you bump it up to version 3 or higher which is where brownie is now or sorry vipers now and walking through the uh walking through the syntax here you can see that the entirety of this is actually legitimate python so this would uh be pythonic itself in terms of all the syntax with these first 20 through 40 some lines there is all this up through line 31 is all the contract level state variables so we're able to include everything we need from the erc20 token in terms of a single hash map of balances and allowances and that gives us everything we need to be erc20 compliant line 11 here is the check for that line 14 through 22 we're defining the events that we're using to log and emit our constructor function uses the underscore underscore init function and everything else most of it is actually the doc strings because viper one of the nice things is the compiler is also very strict about making sure that the docs strings are properly formatted and as a result most of the code here is actually just the level of documentation provided but we see it all the balance of allowance approved all the classic erc20 functions are included here within viper you have to have your internal functions preceding when they're called so in this case uh the transfer function is utilizing this which simply does a assert to check if the balances are viable and then it makes a transfer transfer from works about the same first it checks the allowances then it updates the allowances but the using subtract equal value and then we return true so included within this repository is also a variety of tests so you can see within the pi test framework you always have a conf test which is going to be the fixtures in this case there's only the one to create a token and deploy it and then loading through the tests we'll take a look at for example test approvals all the tests are written out here i'm going to run the tests on this side so we can see what it looks like and we have 38 tests in total the tests all they've compiled you can see them running they're going to be fine here because we don't have any particular issues with this i'll walk through what it looks like in some of the debugging tools inherent in brownie so we can see what it looks like when the tests fail but as expected the sort of simple viper contract we have is everything that we need if you want to also you could fire up a console either by running brownie console or you can uh run some scripts and pop into the console that way so coming with this is a script that just deploys a token to the console so if i run this script and then i run this in interactive mode it's going to drop me on the console when i'm done with it so i'll run the token script it's going to deploy a token for me this is the most recent token deployed here and now i can use this console to do any amount of interaction with this that i'd like so it comes built in with in addition to all the functions it has a few different uh kind of properties built into brownie to access these contracts so for example i could transfer let's send account one half my balance and this is going to default to accounts 0 unless i pass a specific object but now i have a full full transaction which i could use to query a bit more information so that's been added to the history object here so i could look at history minus one and check the gas used on it for example or i could get more information about the transaction which is going to give me the hash the from uh two addresses and all the events contained within it and there's also the capability of running a trace on it which is quite nice so this was a very simple uh transfer you can see it called transfer and then it called the internal transfer function and it gives some of the gas usage so so the gas the transfer function just use 315 gas and then the internal function uses the bulk of it plus uh 20 21 644 for gas so where this is useful is when of course not when the tests go well but when the tests fail so let's change one of these tests to fail and see what happens so let me look at tests let's do a test transfer and let's go down to let me do transfer from actually and i'm gonna change actually instead the test let me change the contract itself and we're going to change this say we made a bug in this and instead of transferring money we transferred a thousand times the money we're going to run our tests again and but this time we're going to run them in what's called interactive mode and when you run in interactive mode it's going to give you if the test fails it's going to drop you onto the console that we just saw but it's going to drop you in the console at the place where the test failed so in this case this was a revert because of an insufficient balance and when you're here you have access to anything within this test so if we look at the tests specifically we're on test transfer uh the first test here and it failed so we have a for example token and accounts and amount are all available to us we can see what the amount was we can see what the token is we can try to transfer ourselves if we want or you can look at the most recent transaction that was attempted in the history log the final element and you could run a full traceback uh which gives you a pythonic style error message telling you exactly where in the contract it was so you can say okay this was it line 105 on token transfer sure enough the line that i was uh i was fussing with right here it's saying that this is throwing an insufficient balance so of course this is a pretty easy uh easy test to figure out what went wrong here uh but it when you're dealing with many much more complicated testing the capability of being able to bounce into the specific line that you failed on uh sort of like a break point and work with it is fantastic so uh this is like some background on brownie which is a fantastic tool but for people who are new to this i would actually recommend um well one last thing to point out is there are some more advanced features built into brownies such as the capability of seeing a full coverage audit so this is actually just going through the code uh showing the op codes on the side but also showing the graphical view of how well my code has been tested so i can guarantee i get 100 test coverage there's also like a gas profiler built in so you can pass the gas flag and see what the gas usage of all these functions were so brownie's great and it's an incredibly robust tool but that being said if you're new i would actually recommend that you instead of starting with brownie you go with the next evolution up which is ape framework and here we see the uh the gas profile come out here and this is just giving the average low and high amounts of gas used for all the function calls which is useful for seeing which functions are using gas uh anyway ape frameworks is you can think of as the successor to brownie so brownie is great but the it's not really building out in the way that ape frameworks is a ape works is a clone of brownie so you can think of it as a foundry is to dap tools as ape works is to brownie so ape works is rewriting brownie all the functionality they just showed off also exists in ape works but they have a much bigger plans for going forward and they also have a bunch of great educational tutorials you can walk through so their ape works academy has the capability of cloning a uh erc20 token and deploying it near c721 nft uh they have more that's coming and a great community so highly recommend you check out ape works i'm not going to go into too much depth on ape works because it's largely very similar to what we just showed off the brownie but i will show off the kind of equivalent of how you would create an erc20 token and the very friendly way in which they do it so word uses this templating system within ape frameworks and this is going to create a erc20 token it's going to ask for it's going to ask for a few different uh initializations so i could say eath token and call it eth token 18 decimals we'll add a pre-mint pre-mint amount it's ownable i love a mint to roll it's mintable burnable permitable and just like that it's created this uh token repository for me right here with everything already filled out for me so even friendlier than brownie as you can see in terms of the user interface and actually building this out and it's um much more recent viper version which is nice e 3.

3 i'm running a bit shorter on time so if i want to go through the kind of more newest tool which is titanium boa uh titanoboa is this natural execution layer for viper language code and titanoboa is in my opinion it's sort of mind-blowing it allows you to execute raw viper code um directly within python so this is incredibly useful for things like being able to create jupiter notebooks and within it actually like interact directly with live smart contracts and pull the stats natively into all the advanced mathematical libraries that you can utilize using python such as you know you could use sklearn on this you could use pandas data frames so some of the things that you can do using titanoboa you can do storage enumeration and what we can see by this uh the example which i'd walk through if we had more time is you're actually able to read through all the storage variables of a contract including mappings so if you want to see like uh mappings are not generally readable as key very value pairs so if you have a mapping you can't easily enumerate it within the smart contract but you can using uh titanic boa just rip through all the storage enumerations so you can trace and enumerate the storage with this syntax here in this case we're loading a contract minting three times and then checking the three balances and looping through them very recently they added the capability of doing mainnet forking so just beware as you're doing this this is caching the rpc results using leveldb so subsequent state fetches the state are very very fast and this is very useful for running simulations against the actual mainnet state so this is where you can take live code and run it through your jupyter notebook and come up with very nice beautiful graphs so here we see a test function being ran through ipython deploying it and this on this um connected to a local mainnet fork is able to pull live data from the blockchain gas profiling is another really useful one i showed how you could get the function level uh gas usage using brownie or ape but if you want to get line-by-line gas usage you can enable gas profiling and walk through on every single line uh the gas usage of every single statement so this has been uh i i feel really bad about this because i basically had to write something very similar uh mostly by like trial and error when i was trying to build out a recent contract and then after i did that and launched and shipped my contract this got released and this would have saved me so many hours of being able to kind of figure out the specific lines where there's issues also i can do up code patching so this is the capability of patching arbitrary opcode implementations directly into the virtual machine in case you need to run some finely grained tests so this here is an example of using store which is tracing all the touch storage slots by address anyone who is familiar with foundry will be familiar with user-defined cheats and this is now available using titanoboa as user-definable pre-compiles in this case um you can see it registering it and executing this raw call as it is touching this right here so this is a simple example printing the sender to standard out but anything that you can do in python you can now do here so you could uh you tracing you can do http requests this kind of opens up the full power of python to this here you can execute arbitrary code so you don't even need to spin up a contract like in the previous examples we were writing a contract deploying it and testing it but there's also a boa eval function where you can evaluate raw lines of viper code and get the result directly to standard out and for debugging uh revert reasons so in this case this is uh there's two types of revert reasons you can get the revert reasons here this is a general mechanism to filter on the physical revert strings so this could be brownie nat spec oxygen style revert strings or even compiler generated checks and here's an example of the compiler revert reasons so if the compiler is throwing an error you can actually load this in and see what the error that's being called is so titanoboa is uh becoming a very very robust and powerful tool for all of your smart contract uh needs the team behind vypro is big ambitions big tech sucks on twitter is one of the founding team members of viper he is very ambitious plans to get viper to the best user experience and developer experience for smart contract languages uh safest and most performant language vm programming and highest use smart contract language for new projects within the next six months to one year so if you're interested please do join us uh feel free to reach out to me i write a daily blog on defy stuff except weekends on curve.substack.com you used to be able to find me on twitter but because i've been supporting the free alex movement i'm no longer findable on twitter so find me on lens instead or if you're old school you can find me on linkedin and finally if you'd like to join the viper community the best place is the discord where the team hangs out all the time and returns in almost real time uh feature requests so it's a fantastic place to be and they're incredibly proactive and get some help so if you follow this qr code we'll see you in the discord thank you very much garrett that was absolutely amazing thank you so much for going into so many deep dives and uh telling us about all these tools uh even i didn't know about the last one so that was that was great and learning for me too um we had two questions one of them was actually answered by another member but i'll just ask it because we're also recording it which is uh when you were doing the testing um was there a way to verify the contract once deployed with the same way in brownie or is that only for testing in that part looks like the answer is you can verify it but uh when i maybe add any other colors to that uh please do no i think that they nailed it right on the head it's uh 100 you can do that using brownie uh it's also like brownie works i should have mentioned that it works just as well for um if you want to work in a developer local chain if you want to work on a mainnet fork or if you want to go directly on mainnet so i actually do most of my smart contract interaction directly on brownie on the mainnet just because it's like easier for me to query and see what's going on under the hood there awesome and the other one was uh people wanted to know what is your terminal setup and what a terminal app do you use [Laughter] so as you see i'm pretty old school um like i um do everything i don't ever use like any ide or anything i just do everything directly within vim uh and then i i am basically using brownie and python for everything so yeah i don't i'm i'm boring okay well thank you so much and i really appreciate taking the time today my pleasure thank you