ethdebug format overview (2025) - gnidan

Transcript

Oh, great. Uh, how's the audio? Can everyone hear me? Cool. Yeah, thanks for coming everybody. Uh, I feel like I talk about Ethbug every year, but hopefully this year is a little more exciting than past if you've been to my previous talks. I'm Nick. Uh, I'm a member of Argo Collective and I've been working on debug for a number of years. Uh, so I want to get into it because I have some cool stuff to show, but I should probably give some of an introduction. And so basically debugging is hard because compilers have to be smart in order to be useful, right? A compiler that produces poor performant bite code is not going to be a useful compiler.

And this is especially true with smart contract platforms of course because uh every instruction costs money. And so as a result compilers have optimizers and optimizers obfiscate the actual highle intent. It makes it harder to debug when you have highly optimized code. uh and this is a problem in this ecosystem, right? Uh basically debuggers are stuck guessing from a world of multiple possibilities. This is the approach that f debug is taking. We are looking to make debugging less expensive. Unfortunately, debugging is still going to be hard, right? It's uh but the idea with F debug is that we want to present a view of the ETVM from the perspective of ambiguous

instructions, right? like we bake the ambiguity into the format so that compilers can be honest and accurate, right? We maintain accuracy but allow for situations where there is not room for full precision and then debuggers can use the ambiguous information alongside the like runtime state like they can actually observe the running EVM and get this like oh well here's some ambiguity but I know based on the state of the machine that I can resolve that ambiguity in many cases hopefully perfectly. So that's the what we're dealing with and we've been seeing some success lately this year especially. We have solidity implementation has begun. It is in progress. Um since 0829 we have uh an

experimental feature flag that provides some minimal source mapping output. And then on the debugger side things are even more optimistic. Uh Tenderly is working on support. uh symbolic runtime verifications debugger has been working on support and walnut debugger which is a newer entrant to the ecosystem. They've been really supporting our efforts with f debug by introducing frameworks for evaluating compiler output. Uh they're they're looking at a solution for perhaps uh providing backwards compatibility so you can get debugging data for older versions of solidity which is really exciting if that can pan out. Um so what is f debug format? Well, the idea is that that I have in working on this format and that we have in working on

this format is that we want to make it as easy as possible to build a debugger or to integrate F debug into a compiler. Right? So, you know, I was starting to say earlier debugging is hard. Debugging is hard even with debugging data, right? Even with good compiler support, building a debugger requires this kind of guesswork with with the optimized code. It it it just gets really quite tricky. So uh to kind of make it easier for people to to support this format and understand this format, we're building reference implementations as we design the format. And this is uh for all of you hopefully it helps to make it easier to implement. And then uh it also for me and for uh the members of you know the project and Argo uh reference

implementations actually validate that this format works. So uh looks like I have just enough time for demos. I have some pre-recorded videos that I hope will work. So the first one uh just to give you a sense of kind of how I'm imagining this this project and this idea of like building reference implementations. I want to ensure that the documentation and the resources for f debug are like very clear to the user. So here's the website right now. This is a static example of a a program in a fictional language and it's fictional output bite code. And you can see that by using Fde debug, we can uh translate back from the actual output instructions and see okay well that call

value instruction corresponds to that source range. And it so happens that when you encounter that instruction, you will have that stored value in scope because it's a storage variable. Uh and then down below you can see that there's the the full fbug that's fbug data. That's what the format looks like for a particular instruction. Uh and so each instruction can define a context. It can define some a code context. it can define variables context. Uh there's a couple other different kinds of context, but hopefully you get the idea. And then yeah so faster than my video, but the idea is what happens when you have instructions that correspond to multiple source ranges, right? So that jump test, well, this function clearly has two returns.

So the jump test picks from one of two originating source ranges. So that's that's the the basic mechanism of how Ethbug can present ambiguity. So that's the idea there. But you know not being satisfied with just a static handcrafting handcrafted bite code output uh we have put together a bug C toy compiler for the fictional bug language. Uh and uh just to show you kind of end to end it is producing some Ethbug output now but just to kind of give you sense you can see that it's structured like a modern compiler. We have uh an a of course we have an intermediary representation and this is a a single static assignment intermediary representation uh in part

because that's how solidity is moving forward but also because that's how modern compilers are are built these days is uh for optimization purposes and you can see that um the f debug output is being strung through so like right that there that ox1 represents the the right hand side of the assignment with the f debug data and then scrolling down to the sore that's the the left hand side of the assignment and the corresponding F debug data. So that's a start, right? Pretty simple program. Let's look at some look at something else. Uh yeah, so let's look at more interesting examples, right? Like so common sub expressions happen when you have to write the same thing more than once and the compiler, you know, good compilers will identify that it is a common subp

expression and eliminate it. So here's with the optimizer off. Uh switching the invisible drop down to the CSC demo. Keeping optimizer off you'll see that values of message.cender is uh written three times right. So a naive approach compiling that looking at the IR you can see that we have a t0 equals message sender. This is like the IR primitives that this language has. Uh and then there's a slot mapping or mapping slot calculation built into the IR. But problem is this happens three times.

Once at the top and then once in the then and once in the else. So that's not going to be performant. And so we would naturally want our compilers to get rid of that uh duplicate code. So now people probably want to see it with the optimizer on. So this is the same the same code but just switching the invisible drop down to optimization three and compiling it. And you can see that the message sender and the slot calculation only happen the once and that they get assigned to a single static assignment of T1 which gets used in multiple places because the the optimizer here has been smart enough to

identify that and handles it. So looking at the bite code, do we get debug data? Well, if we look at the single use of collar, it shows up three times with a pick combinator and the catchack for doing the slot calculation also highlighted three times for only one instruction. So, this is uh perhaps the first end to end validation of the format and looking forward to other compilers supporting this stuff and adding support for variables and and you know the rest of the components you would want in a debugging format. Uh so ultimately I'm pleased to say that this year at the debug format is not just theoretical like every year it's been

maybe four or five years I keep saying oh ebug is going to be great. Well eth bug kind of exists now. So uh hope this represents the start of some constructive feedback loops between the debuggers and compilers in the ecosystem and we can make real progress. Um should probably save time for questions but I'll just note that I left out some stuff. I wanted to show the compiler side stuff today. Uh if you're curious, I did present on the debugger side reference implementations a bit last year. So you can find the the uh Bangkok talk. Uh if you want to learn more there, you can just click on some of these resources. But yeah, happy to take questions now.

>> Amazing. We already have quite a few questions coming in already. >> Excellent. Love it. >> Um the first one is, is it easier to debug smart contracts with verified source code on Sourceify? >> Absolutely. Uh, Con, thank you for the question. I'm just kidding. Uh, no. Well, so right, imagine that a lot of that compiler output I showed is going to be quite enormous and so you might not be likely to distribute the full compiler like debug output with your program. you uh but theoretically if you have the exact version of the Solidity compiler you need or whatever language compiler you need you can just rerun the compilation based on the sourceify data right you can go and pull the the

verified contract and metadata from sourceify recompile with debug turned on and then produce the debug data you need to feed into your debugger so uh I don't know how you would do that without the source code and sourceify is the the best repository for getting smart contract source code so Um the next question is can you talk about how this will help determine the relation between inputs and storage location of mappings because this is key for fuzzing >> the Can you repeat it? Sorry. >> Can you talk about how this will help determine the relation between inputs and storage location of mappings?

>> Yeah. So that's not specifically something that is being targeted by Ethbug right now, but this is a problem that I'm familiar with. Uh you can kind of uh since I have my computer here, you can kind of just look at it. Um nope, this one, right? So you can figure theoretically you could trace through the individual like data locations. I don't know. There there are no real good primitives for this right now. This is a problem that I' I've kind of not been looking at solving with urgency as we get the format kind of more you know I want the instruction view of the world to be ready first and then we can look at kind of these like data dependency

tracing things. Um yeah it's an interesting question. >> Okay. Um the next question is how is e debug different from the source map style debugging in foundry? Um, yeah, those come from solidity output directly, I believe. I'm not sure, unless they do something smart on their own. Um, but in addition to the, you know, of course, Fde Debbug will include source mappings, right? That's the first thing you need in a debugger is to see where you are in the code. But, uh, the source mappings today don't provide a mechanism for ambiguity. So if you're running solidity for instance with op with the optimizer turned on the output you will get if you have like in my example where I showed you those uh

dduplicated bite code instructions um this the strategy that solidity has taken has just been to output the first such source range right so there's only one you know there might be three source ranges but you only get one so that's the the first difference that debug uh accounts for and then the other thing is debug also wants to provide a mechanism for the compiler to specify where to find the variables I didn't talk about that in this talk too much but in my static slide right the video um this one you can see that well you might be able to see yeah so oops well well oh screen's off never mind then okay so

yeah if you remember the the video uh there was the stored value was highlighted and that's a mechanism that f debug provides is to say this variable is available right now and if you want to look for it. You can find it in storage slot zero. Or maybe you have an array and so debug provides a mechanism. Oh, you have an array. Well, if you want to find the length of the array, you can find it in storage slot 10 and then you can hash that to get a particular index. Uh so those kinds of mechanisms are built into the format and that is just not something that the the solidity source mapping uh provides. >> Hope that answers.

>> Um the next question is what's the timeline to see debug packaged with popular compilers like hard hat and foundry? Well, I imagine it would follow quickly after uh the solidity support, but note that there is a non-trivial amount of work to actually implement at debug support on a debugger side, right? Because like in the example I just gave where you have a memory array or maybe you have a memory array inside a strruct inside a mapping, uh even with compiler information, it might be a bit challenging for a debugger to implement the logic to go and actually take that information from the compiler and then cross reference it with the runtime state. Uh but I I hope it would make it a lot easier and we would see that uh quickly to follow uh from real solidity support.

>> Maybe we can squeeze one more in um because this is interesting. Which existing non-blockchain uh debugging frameworks inspired e debug? Do you have any? >> Well, I mean the dwarf format, you know, I've read that 300 paper page standard, you know, years ago and you know, I've looked at that. I've looked at the Microsoft debugging data formats and really they're all kind of an inspiration. Um, but most of the inspiration is just my own madness, I guess. >> Awesome. That's all for you, Nick. Thank you so much for answering.

>> Thanks, everybody.