Breaking the Code: Ethdebug for Smart Contract Debugging - Nebojša Urošević | Tenderly

hey everyone thank you all for coming um so today I'm going to be talking about debuggers and hopefully how eth debug format is going to help uh hopefully help you not break your code in the future so before we begin let's dig deeper into do we need do we actually need a debugger in the ethereum ecosystem so if you take a step back and track travel in time to 200 to 2016 or 2017 before the first debuggers um what we would actually uh uh be capable of doing without it uh if we if in case we wanted to debug our smart contracts we would basically add uh print functions into the source code wait for the compiler to compile it and then run the transaction and hopefully get some insight into the execution so basically something like this um now the funny thing about it is that uh if you opt in for this way of debugging your smart contracts you're going to end up uh consuming so much more time in fact um we we started going to ethereum heatons somewhere around that period and we were extremely frustrated by the time and the energy it took us to uh find bugs in our contracts um so what it actually uh uh resulted in is usually us um basically scraping the 90% of the project and going with some M MVP MVP version of it um and the even worst case that could occur to you is this one where your production is down and the only thing you can do is try to replicate exactly what's going on in the production by and then in that in that instance add uh numerous number of prints just to be able to catch where the bug is um but besides this let's see what are some of the other reasons why we need a comprehensive debugger in the ethereum ecosystem so essentially it's for all the same reasons we need debuggers in the standard programming languages in web 2 it's just that it's even more Amplified in the ethereum ecosystem why well because smart contracts tend to uh hold a lot of value in them where you have a program that is basically instructed to do certain things and if you have a bug in it if an attacker finds a vulnerability uh then all of those funds could be lost so the most important thing there would be of course the security then with the rise of the defi application and the games in the uh in the ethereum ecosystem there there's also rise in complexity um which can be really hard to comprehend uh if you're a developer who wants to integrate certain protocols um being able to step through those protocols Analyze That code can really help you uh uh into managing that complexity and the last part is reliability uh why reliability well of course when we uh finish with the development and building of our application we want to ship it to the production uh in this case we want to feel confident then once we uh deploy our application that it's not going to break automatically now let's see what are some of the frustrations that developer encounter while debugging uh their smart contracts in the ethereum ecosystem um so there's the the the first one and something that we usually get from uh our users is that de is not pointing to the right line of the code um how do we actually uh map the execution environment to the high level source code is by leveraging something solidity compilers outputs that is called uh Source Maps basically this uh uh array of instructions tell us uh to which exactly Point uh in the code a corresponding execution uh uh points um now the problem here of course is that um solidity as a compiler uh has some bugs uh and U this is something that we try to prevent by deploying some heris sixs but of course uh we cannot always be certain that we're doing the right thing um next up is the misidentified function calls um so as a standard debugger we want to have a full function stack so that uh developers who are uh uh debugging their smart contracts can really know in what point in time uh they're in in their execution um how we actually come up with the function stack and how we know where we are actually in the code is by leveraging some of the internals of the compiler uh into understanding where we exactly are uh now they're all again similar to The Source Maps there are certain problems there especially when solidity compiler utilizes some of the optim izations as they can basically remove some of the functions from our code um in the cases when we are able to um exactly know in which function we are um we can get to a certain problems while decoding parameters uh this is simply due to the fact of how uh solidity and where solidity store parameters sometimes they are going to be in the ethereum virtual machine in Stacks uh sometimes it's going to be in the memory the other time it's going to be in the C data and whatsoever so we're not exactly sure where to look for the certain parameters um and on top of that when we are in a certain function scope uh the coding of the local variables can be can be really cuc cumbersome uh again due to the optimizer due to the some unpredicted behavior of the evm stack Etc and there are so many other nuances uh uh when you try to build a debugger um simply put uh this is not the just the problem uh for our debugger this is the problem for any evm debugger out there the number and the quality of the data that we get from the compiler is simply not sufficient enough to make a reliable debugger um this is why uh some year and a half ago we sat down with the solid team uh we also sat down with uh a couple of other tooling company a couple of other security analysis firms to try and U get together and standardize the way that solidity compiler is going to um output the data that we need in order to make uh Our Lives easier so that we can make uh lives of developers uh in the ethereum ecosystem easier um and what we came uh uh with is uh the debugging format that is going to be sufficient enough uh with that that is going to allow us with 100% accuracy to be able to decode and to analyze basically anything in your smart contracts from the low level all the way up to the high level programming language um so what it means in practice is uh we all know that bite code uh on the evm uh uh run runs uh uh sequentially uh this is not the C so we need some way to map all of those instruction to the high level programming languages like solidity or Viper uh we need some way to map uh basically any instructions uh and to know if it's pointing to a function or if it's pointing to a local variable or uh some log that is going to be emitted Etc and we to be be certain that we are in that scope of the of the of the programming l language um and the the the the the thing that uh U has also uh uh been uh evolving over the past years is the data complexity of the smart contracts developers uh uh require from the solidity team to continue pushing on with the new features uh something that uh some other programming languages in the web twoo space already have and with this Rising complexity the the need for the debugging format is even greater and the last thing um since there are some custom things to the evm as it's not very similar to the traditional virtual machines we have concepts of gas we have concepts of uh 256bit registry uh the need for the format is even greater um let's see now what are some of the key challenges that uh the format is trying to address uh so the the idea of course the high level idea is to help tooling uh uh uh tooling companies build better and more uh reliable features so uh what's the first thing that and one of the biggest problems that we have right now is the full type definition uh right now we are mostly relying on some information from the abstract syntax tree that compiler is providing us with uh this is not the most elegant or the best way uh to consume this information and uh the type definition should help us into really dissecting down uh exactly which type we are dealing with what what what's the name of that type Etc um pointer are also very important they they work together with the type definition they should help us understand uh how to decode uh uh some specific information from the uh uh lowlevel evm so uh ideally tell us uh where to look for some information is it on stack is it on memory is it in uh transient storage is it in return return data is it in code um so I briefly mentioned the source Maps which we currently leverage to map low-level uh execution instruction to the high level programming language uh Source location should be the evolution of that uh they should help us uh uh correspond with uh 100 % accuracy uh the lowlevel code all the way to the high level programming language um and there are even like some of the some of the problems that we encounter right now is uh um during the phase of the optimization of the bite code uh some of those information simply going to get lost uh we're not going to be sure if for example we have uh two similar or very uh or or identical functions uh what the optim is going to do is simply going to erase uh one of those functions on the bite code and we wouldn't be sure from which location we are coming um and the last point and but this is the certainly one of the like biggest challenges that the uh developers uh are asking and uh uh something that they would really like for a debugger to have is being able to uh tell you what are all the variables in the scope uh and besides that to be able to uh understand everything that's on stack uh Plus in a case where some of the variables are optimized out or we have a constant folded functions to be able with certainty to say uh that we cannot uh uh find the value of it or in certain cases be able to reconstruct it uh with certain functions um now this format is uh only in draft version right now uh um but fortunately uh solidity team has already implemented some of the proof of concepts of it so we were able to get a sneak peek into the information that they're providing us with and uh since we have a internal tool for the debugging that we uh uh constantly uh uh where we constantly test out new features new functionality Etc uh we just couldn't uh wait for the production version of the of the format we had to implement this ourselves um so this is going to be like a quick uh explanation of uh um how uh and what uh the new debugger is going to be capable of having um so um this is basically the layout of it this is a simple CLI tool that we've written in Python where we test things out uh so on the lower part you can see the the source code you can see the break point on the line 46 uh basically the the new debug format should allow us for the easier implementation of the break points and line by line debuggers um on the top left side you can see the information on the stack uh you'll basically be able to see uh exactly which variables are on the stack uh if some variables is not we would be able to highlight that this information is not present on the stack at this point and on the top right side you can see the history of the instructions with all the relevant information there is um now I mentioned briefly that uh uh one of the uh big one of the bigger challenges that we have is maintaining the function stack simply because uh um some some functions might get optimized out uh some heris stic might not work for us uh with the new format we would be able to with 100% guarantee the function stack and not just that be also able to decode all the par that are uh uh accessible at that that is the input of this function um now um probably not a lot of you know but uh um since version uh 0.8 uh solidity has released U debugging for to the general availability uh and right now you can use the Ule to compile your smart contracts um what this is going to do is basically uh inject some of the jewel functions uh so for example if you're performing an addition of two variables in solidity what's going to happen in the background is uh this function uh check ad is going to be called um and in the versions uh above 0.8 of the solidity uh if you don't specify unchecked in your function uh Clause uh solidity is going to P Panic uh in case uh uh uh the addition of these two parameters overflows uh and with the debug format uh we're going to be able to basically go down into the specific U functions and showcase you uh what's going on down there now um another thing that uh is also relevant to the Ule uh debugger debugging is uh in the next phases of the solidity uh the the the they plan on making the Ule uh uh default way of compiling smart contracts uh what's that going to allow developers is of course much more flexibility they don't need to worry about having too many variables on stack Etc but that's also going to mean that most of these variables are not going to be allocated in the stack uh which is again a a a good thing for the developers not a great thing for us because we need some way of uh uh uh finding those variables and usually in most cases uh these VAR variables are going to be on the memory um so with the new debug format we'll be able to fully decompose the whole memory and to have understanding of like each value that's uh uh in it um and one of my favorite features of the debugging uh is being able to watch expressions and variable that is in the scope um we we would be able to do this for like any line number anywhere in your codebase uh and not just it but uh uh we wouldn't uh uh we don't need to rely on the compiler to have this information right now we have an implementation for the evaluate of the Expressions unfortunately it leverages a compiler uh which can sometimes produce errors or incorrect answers um now um we we to summarize everything up uh and we believe this is going to be a great initiative that's going to uh enable so much stuff but uh to summarize up everything that is going to to be enabled from the debugging standpoint uh we're going to achieve 100% accuracy in code locations meaning that uh we'll be more certain when we showcase uh where we are on in your source code uh we'll be able to display all the variables that these are that are either on stack on memory or anywhere else uh and Ensure that uh constant folder variables are uh uh uh if there is a way we would be able to decompose them um on top of that we'll be able to uh decode uh uh all of the memory of your smart contract as well as showcase uh uh all the storage slots that have been uh uh uh that have been transferred during the during the transaction um and last but not least these two things uh uh which are my favorite is being able to evaluate expression without the need uh for the compiler and be able to do it on any line number uh there is um so these are all the great things but we believe that the impact of uh implementation of the debug format is going to be is going to go even beyond that uh we believe that this is going to be a tremendous new step for the for the whole ecosystem U why we think that uh uh uh well it's it's pretty obvious the first thing is this is going to accelerate development Cycles a lot uh which is going to uh uh result in more applications uh uh um going to the production and in the end more users on boarding to the to the blockchain ecosystem uh we're going to have higher quality and the better security of the smart contracts we all saw from the beginning and we all know how many hacks occurred on the ethereum blockchain uh it's a numerous amount of millions of dollars who who are get going to the to the attackers every year uh we think that with better debuggers with better tooling uh we can prevent this um a thing that uh uh might not be clear from the from the uh uh beginning but uh with this we believe that there's going to be a better interoperability between tooling and between platforms of the ethereum ecosystem so essentially what we see is going to happen this that uh we're going to uh be it's going to be possible to integrate with so many other tools in the ecosystem similar to how it is now in the web to and of course one of the uh uh biggest uh uh things that's going to come come out from this is uh we all know how important it is for the newcomers to be able to on board to the technology have an easy time learning things Etc uh we believe that with this format we're going to be able to push the tooling to the same level that that that is right now in the Web 2.0 space um and all of this combined we believe is going to uh uh bring a broader adoption to the etherum ecosystem which uh we all here very much want um and to uh wrap things up um as mentioned this format is still in the draft phase uh if you have some ideas or uh you want to contribute uh feel free to go to the E debug. github.

io format uh we meet uh uh uh we assemble every other week uh and we'll definitely go over all the all the ideas that were presented or if you have some other idea feel free to come talk to anyone from tenderly and we'll definitely uh share these ideas with the rest of the folks uh uh uh who are working on this format um and I think that's it thank [Applause] you are there any questions maybe sureh MH let me just repeat the question so um you last uh uh you said that in the Java for example we are you're able to stop at any break point and then modify the code um yes we'll definitely be able to do that uh most likely we'll need to Leverage The compiler for that so we won't be able to like do it out of the box simply because uh uh there's additional steps uh in changing the the the source code and then uh running those instructions but we'll be able to do it nonetheless using the compiler and great question thank you uh hello uh I might have some uh I might I might have forgot on something but uh is uh your debugger is online only yes it's online and you can use it but uh it's not the default path of the compiling of your smart contracts so right now it's going through the assembly and then directly to the evm bite code in the future solidity team plans on making it the default way of compiling right now you have to like wait somewhere around the anywhere between 10 seconds and 10 minutes for your uh smart contract to compile which is not the case with the Legacy Way of compiling but once the uh uh the the once the Ule compiling reaches certain level of maturity and performance solidity plans on making it the default way uh my question was actually more about you know code privacy because it's hard to De if we for example don't want to share the code with anyone uh we can't use your debugger right sorry can you repeat the question I uh if uh uh if we are a bit trustless and don't want to share the code with uh tenderly M uh we can't use their uh your debugger because it's it's online only that's a great question uh yes currently uh uh the tender debugger only works on our dashboard um in the future once uh we see the level of uh uh quality of the debugger reaching certain degrees we definitely do plan on making it open source thank you okay thank you so much