New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Loading player…

New Ethereum Dev Tools from 0x - Leonid Logvinov (Hacked ETHstonia Identity) - GoerliCon 0|15

ETHBerlinWed, Oct 9, 2019, 12:00 AM

https://ethberlin.com https://decentralala.com/ https://goerli.net

Transcript

heyo there was a little bit of a rush start but my name is Leo and I'm working on the developer tools team as directs and we're the developer - developer experience team we care about developer experience and we've developed some tools that will make the developer experience better and today I want to present those tools it all started to eat Denver where me and Remco were working on the solidity profiler and here were presented on the cryptic key smart contract and on the left you see the gas costs for different lines was a little bit of an experiment a little bit of a hack over there but people liked it and we liked it and we started working on that more so first let's go to the agenda I gonna talk about the list of tools that were presenting today and the functionality of those tools and why are they improving the developer experience previous work in the area of similar tools how they work how they function from inside and integrating those tools with your favorite frameworks because their framework agnostic so without further ado let's jump right in salt race salt race is the tool that gives you human readable stack traces for solidity I think everyone who have ever rode slowly encountered an error in fluidity and when you have an error that's not much you can do to debug that error because you get a transaction hash and then revert if you're lucky you get the revert reason which is a string but then that doesn't always work for you because sometimes you have a contract aid that calls a contract B and then the contract B has the reverse stream for example overflow and you don't know what did overflow and why did it overflow that's an example of a terrible developer experience and it shouldn't be like that in other languages it is not like that and you just get a normal stack trace and you can use it to debug your code there is even a page where you can go which is called vm exception while process and transaction on revert which is hilarious and has some good examples of how to debug that stuff and how it's impossible to debug that stuff and i was motivated by that page will work in that tool but now at the top of that page they just have going to salt race which like solves your stuff yeah so here is the example of the truffle aroma that says you check that your code satisfies all the conditions by require statements which can be really hard when you're working a huge system of smart contracts that has a lot of this require statements and it's your ex we've hit that complexity limit so we started thinking how can we do better and it appears that we can do better we can just get Salida River traces and now you can do two so here is the example of the river trees that you can get with this tool and we have two smart contracts here and contract meta coin used safe math quite a common pattern and the safe matt has some overflow checks and even if we have the revert reason here in the overflow check and safe math it will say something like overflow or subtraction failed but you don't know what is that subtraction why did it fail and here you know you know that meta coin on the line thirteen called that safe math with the message center balance and the amount so this is already much more helpful for you to debug why did it revert and how you can fix that so you should look into the balances of message sender the second tool is the tool for code coverage I don't think there is anything to explain here because it's just code coverage and we all need that to test our code and to check how well did we test our code the problem was that in the saluted world before that was not very feasible but now you can just use that tool and the good part about it is that it generates the report in the Istanbul format and Istanbul is this popular code coverage tool in the JavaScript world which can generate reports and text format JSON format HTML format so whatever you name it so we didn't need to rebuild all that stuff from scratch we just generate the file you're on the Istanbul reporters to get recovered report from that file and you can easily integrate it in your CI pipeline and other tools that work with coverage that's just seamless second the third tool sorry it's the profiler for the solidity in the solidity world code consumes gas and gasses money and what's even worse gas is your clients money and you shouldn't be spending a lot of your clients money because then they're not going to like you too much but if you want to optimize your code you'd better know what are the problems with their code what are the places where you should optimize it so solidity profiler shows you how much gas did each line consume so here for example we see the example of the deposit contract I think that's yeah that's the ether robber contract and the line with the balance of consumes a little bit over 20,000 gas because that's a storage right and storage rights are expensive on a theorem because every node stores the data so it's a little bit over because it also has some additions and some reads from the cold data or something but the next line is the event and the next line is much cheaper because events are much cheaper than storage writes so here you can see that overall this function consumes 21,000 gas and those particular lines consumed that much gas which may help you debug in your contracts and optimize them down for gas cost the other use case of that tool is for the solidity team itself we contacted them and they were interested in that for tuning the solidity optimizer because now you have this run's parameter on the solidity optimizer which helps the optimizer to make the trade-off between the code size and the gas cost of the code because the optimizer can do different optimizations but the optimizer needs to know like what is good what is bad or how to decide about it if you have the tool like that you can show the optimizer that this function is executed very frequently so you'd better optimize it but this function is not executed very frequently so you shouldn't care about it so we can run that for example on the main net and get the statistics for the contract and deploy a new more optimized version of that contract while providing this data to the solidity compiler itself so talking about the solidity compiler so the compiler is nice but it should be a little bit more higher level it's not the responsibility of their team so we built a higher level so later compiled a wrapper called Sol compiler it's like salt but with batteries so what's battery's about it it's project centric it compiles all the files for you it has the watch mode and that's the only slow to compiler inode has the watch mode like all the modern compilers who just watches the file changes and recompile them for you as you change them in the ID making the developer experience much more seamless it's fast because it works with the docker eyestalk as well as the soldiers you choose which one to use but on the big projects docker as salk is literally like 10 times faster has incremental builds so it doesn't rebuild the stuff that didn't changed and only rebuild to stop the change and its dependencies and it also supports multiple versions see if you have a project where you have one contract with the version 0.4 22 is 0.4 25 it will figure it out solve those constraints and compile them with different versions as far as I'm concerned a lot of other frameworks don't allow you to do that and it also works with mono repos as you go to more and more complex software and systems or smart contracts a lot of teens start migrating to mono repo and we're using the mono repo ourselves and small compiler supports the mono repo other good thing is customizable artifacts thank everyone who used truffle scene those huge artifact files which have the ast legacy st assembly bytecode stuff like that sometimes you just want ABI because you're deploying those artifacts and you care about the bundle size sometimes you actually want all that stuff if you're debugging here using the solidity input JSON and output format you can just specify what do you want in your artifacts and get just that without any trash on the side so those are the four tools here are some previous work there were some compiler wrappers with different versions of success but in terms of coverage tracing and profiling I haven't found anything except for a solidity coverage which is the tool written by the truffle team Chris get back a if I'm not mistaken and this tool also has an interesting approach but we've had some problems with it and that's why we reinvented the wheel so the approach of this tool is it takes your source files and it instruments or source files before each line it adds the event it adds this line covered event like you see here you have a equals a plus 1 and after that you have omit line covered one one is for the line number and then a equals one correspond then it free compiles all of your artifact all of your contracts then it runs the test through the fourth VM with the Ford ganache wife worked because you need enormous gas limit for that because events consume a lot of gas and also in order to track coverage for calls because you can't get debug traces for calls they just ride those directly from the VM to the test to the text file on your machine and then read the text file it's a nice hack I like it but it wasn't very reliable for us it was also slow and I didn't like running those fourth versions and configure and all of that was a little bit hard for me so that's why we went with the approach they will describe later yeah so our approach is mostly using debug traces and debug traces is the stuff that you get from the node or from the virtual machine after executing the transaction it has some interesting data so for each operation and by operation I mean the OP code execution it has the program counter DC which kind of translates to the line of assembly you're executing so here you see those incrementing program counters it has the operation which is the OP code you are executing and it has the gas cost and the called depth of that opcode so with this information from the VM directly you can do a lot of useful stuff and that's available on each III room node so you can just get it for every transaction but then program counters are not very useful if you can translate them back to the source code luckily celui gets you gives you the source Maps they look like that I'm not going to explain how they work because this isn't their documentation and it's not very interesting but basically this magic string allows you to translate the program counters to the lines of code and then with that information you can already write the coverage to learn the profiling tool you can just get the gas costs map them back to lines of solidity here you go get their operations have done backs two lines of solidity and you know which line was executed in which line was not executed but then if you want to do more interesting stuff like to revert traces then you need start tracing sub calls and emulating sub calls luckily we can also do that with the debug traces you just need to see where the opcode is called call code static called delegate call and kinda like emulate that call so you record where you jump and then when you return or revert you pop that back from the stack that's how you reconstruct a stack and when the revert happens you know like where you jumped and you can map that back using the source lines and get the nice river traces that we had here yeah so if you like any of those tools and want to start using them the good news is they're not written for any particular framework they're just providers that you can connect to your provider engine their framework agnostic and you can add your own artifact adapter for those tools because they need to know something about your smart contracts they need to know the byte codes the source maps and the source codes they use the source maps to map the byte code back to the source code they work out of the box with the sole compiler and truffle because we just showed this artifact adapters but you can use it as an example to write your own artifact adapter so for example the waffle team currently works on the artifact adapter for the waffle framework and if you use any other tooling you can also use those tools no vendor locking here resources so if you're interested I want to read more about this tools I recommend to start with the blog post we've recently published about this new dev tools there are also for landing pages that are general high-level explanation what are these tools and how to use it and why do you want to use it soul traits all coverage soul profiler and soul compiler not so hard to remember URLs and there are some documentation pages that go in depth of how to use those tools how to write your own artifact adapters how to use them with the different frameworks so more nitty-gritty technical details yeah that's kind of its that I wanted to talk about so I guess from now the developer experience and the theorem can be just a little bit better [Applause] [Music] [Applause]

Automatic transcript — names and jargon may be misspelled.