Cohort 3, Week 8

Transcript

Welcome everyone. This is week eight of women in Ethereum protocol cohort 3. This is our study group and today on our office hours we have special guest uh Justin Florentine from Bessa team. Welcome Justin. Thank you for coming. Hi. Yeah, today it's an interesting topic. I think you will present it yourself. But before we start, could you please tell us a little bit about your role in Besso? When did you join the protocol? What was your way to the protocol? Sure. So, yes, my name's Justin Florentine. You may see me online as Robocop's gone mad. That's the handle that I use in most places. I'm not really anonymous, though. I go by my

legal name. Uh, I joined Consensus Software in 2021, uh, right around right before the London hard fork. So, that was the first one that I worked on. worked on most hard forks since then. I ran point on Cancun and the merge and yeah, right now um so typically my career is kind of weird. I go back and forth between management and engineering. My pendulum kind of swings back and forth throughout my career. So right now I'm heading back towards sort of a management type role. And so right now for the basu team I am acting as uh an engineering manager and kind of a

product owner and then I still try to do some code contributions on the side but nothing on the critical path. So mostly maintenance work things like that. Hey we need this bug fixed this needs to be refactored. It doesn't really matter when somebody gets to it because you know when you're doing management stuff you your time is really worked in one hour blocks if you're lucky not you know a day at a time where you can really focus. So yeah a little bit about me. I am from the United States. I live in the city of Philadelphia. I have a family. I work from home. I have lots of hobbies. Um I'm always encouraging people to find things to do outside of Ethereum. If you run into me at an event or something

like that, I won't ask you about Ethereum. I'll ask you like, "What did you make? What did you build? What are you doing?" Like, "What what are you into? What do you like?" Just to kind of keep our brains diverse. I'm very big on context switching. And my mind is not one that does necessarily deep analysis, but kind of builds connections. And so, I find that when I look at things from different perspectives, I I more quickly can can find intuitive connections that way. So, Your mileage may vary. Not everybody thinks like that. That's how I think and I encourage other people to do that as well. Yeah. So happy to be here.

Yeah. I definitely love it. So I feel the same. And that switching between the dev role and management role. Yeah. That's you never get bored, right? So that's interesting. You are always on top. Yeah. I won't tell you which one I like more, but I think more people should do that because engineers suffer from having managers that don't understand engineering, right? And managers suffer from not being able to understand their engineers better and how it works. And so if you've ever had a boss that you complained about, become that boss. What what I see in the protocol, so managers are often that they switch from from developers. Yes.

So I think they know a lot of stuff about the protocol. Yeah, you can go back. Don't have to be too scared of it. Do it for a couple years. If it's not for you, you you can go back. It's not common, but I think it's becoming more common. Great. Great. Tell me about your study group. It sounds like this is a regular meeting that you have. How do these usually go? This is my first one. Yeah, this is our cohort three three. We started last year and what we are trying to do, we encourage female devs to contribute into the protocol. So we try to solve good first issues and we try to learn some basics about the protocol.

Yeah, we have guests, we have lectures and talks and uh yeah, we try to solve good first issues. Okay, great. Well, this stage is yours. I think we can start. Okay, that's so since it's a study group that's good for me because my lecture materials are not cooperating at the moment. So this will be very free form and we can talk about the Ethereum protocol, how it works, etc. I understand you were interested in talking to me because of a particular interest in the execution layer. So if that's the case, I can give you an outline of what an execution client is and what it does. And in fact, actually, I might have I might have some other

materials that I can recycle for this. But then I'd love for you to tell me, let's hear more about this. Let's hear more about that. I you know let's let's make this this interactive. Yeah, sure. I think some of our participants have for example experience with smart contracts. So that would be great to know some main parts of uh execution client. Let's start from something a little closer to the beginning. This is a presentation that I gave in ETH Denver and the first half of it could be interesting. So we'll talk a little bit about so this is a software architecture diagram boxes and lines not super detailed or useful but it gives you a general sense of what is the outline of

an execution client what is the table of contents as it were what do they do okay and in this presentation I'm pointing out that they all kind of do similar things in in slightly different ways right so this for instance is the basu diagram and you can see all the different aspects of Ethereum that a client is responsible. So an execution client, the first thing it's going to do is it's going to connect to a network, right? This is a P2P network. It is permissionless. Anybody can join it. You can have a computer that's on the internet and boom, you join it. So all clients are going to have some aspect of peer-to-peer, right? We think about that as discovery, right? How do I find the other members of my peer? And then a serialization mechanism, right? So, how

do I send bytes back and forth in a way that's going to be useful to the protocol? And then potentially some subprotocols. So, if you dig into the networking stack of an Ethereum client, you'll see things like ETH protocol. We're currently at ETH68 is the version right now. There are pending EIPs for ETH69 and ETH70. They will be adding features to it. And this is how peers tell each other what capabilities they have. What do they know? What things can you do for me? and allows them to decide which peers they want to keep. And then there's the RLP protocol which is kind of layered on top of that. And that has your serialization mechanism. How do you send bytes back and forth? What does a transaction look like? What does a block look like? Maybe there's some receipts

involved. Different data structures. And that's kind of your how do you find the rest of Ethereum, right? The network. Yeah. And the good news you you don't need any ETH to run Ethereum client but it's kind of useless if you don't run consensus clients as well. Right. Right. A lot of people did that for a long time and some people still do. If you have a wallet right and everybody should have a wallet I hope and you don't want to use Infura or somebody somebody else for the wallet provider. You can run an execution client without having staking without having a validator and you can point your own wallet at it. and now nobody can lock you out of the network, right? Oh, that's a good tip, right?

Yeah. So, if Infura decides, hey, we're we're not going to serve this nation or whatever. Well, you can run this client on your own. Connect to it directly. You're good to go. So, that's networking. We can talk about that. Not as interesting. The I think the things that people are going to care about is the storage and the execution engines, right? So, these things right here. Storage is interesting in Ethereum. There's a lot that could be said about that and I don't want to go too deep on it. If you find that that is an area that particularly interests you though, please reach out. We always need more storage specialists. Basu is going to pat myself on the back here. Our team is kind of leading the way in some really innovative storage mechanisms. So you may have seen over the last year or so a

lot of clients are adopting what they call path-based databases and BESU is really an innovator in that space. We developed a data model called Bonsai which allows you to kind of flatten out your storage tree. This because of the way that Basu uses Bonsai, it's actually unlocking subsequent features later on like transaction parallelization. And if you want to hear more about that, my colleague Gary Schulty did a presentation at ETH Denver on that subject and it was awesome. I highly suggest looking that up. Again, I can provide a link later on. So, how familiar are people with how storage works in Ethereum? Like how do you how

do you synchronize the the current state of Ethereum? Is this is this a subject that folks feel fairly wellversed with? Yeah, you should just um yeah, give us some basics because we have uh some people who are new to that. So from a high level, right, one of the challenges that Ethereum has is everybody needs to have the same state and it needs to be synchronized by every block. So if I'm executing block two, I need to have all of the state modifications that happened on block one, right? And the way that we can do that efficiently is we use a data structure called a Patricia Merkel tree.

And it's basically like a big tree, right? And you can hash every subnode of the tree and roll it up to its parents, right? And so if all of the nodes on the tree roll up to the root and you get the same value, you know that the entire tree is your entire state tree is the same as my state tree. And that's great because that means if you execute a block on top of that and get a result, I should be able to execute that same block on top of the same pre previous one and get the same result. Right?

That's the very core that's the the the distillation of what we mean by consensus when we talk about a consensus network and that the these are consensus technologies. We are agreeing that for these inputs we get this output because we're all playing by the same agreed upon rules. And it's the storage mechanism that makes that efficient and it makes it is really what what everything revolves around. The other aspect that you'll see here in this diagram is the execution engine itself the EVM, right? So like well what can you do? If we're all going to agree on the inputs and the outputs, I hope that we can do something

sophisticated to get from one set of inputs to another set of outputs. Right? If Ethereum only supported addition, it would be kind of boring, right? You wouldn't necessarily be able to do anything interesting with with your world computer. So the EVM is where we add some diversity to that. We add a bunch of different things that you can do and that's implemented as a virtual machine, right? So every client has their own implementation of this. It's written in their own languages. Basu is written in Java. The EVM is written in Java. Our our EVM is extremely modular. Okay, so like if you wanted to, you could actually pull it out and run just the EVM um and do you know whatever you like. Some folks have

done this. I know that there's a side chain called Hideera that does this. Uh they are reusing Basu's EDM. Um a lot of uh a lot of our testing tools. So if you get involved and please get involved with our testing the execution engine tests we have very very robust suite of tests that uh we run every time we do an upgrade every time we do a hard fork every time we introduce a new feature and they say hey when you start with this state and you run these transactions through it you should get this type of output right and having a an EVM that can be popped out and put into a testing framework is a huge advantage so this is kind of computer inside of blockchain chain, right? Yeah.

Yeah. And we can we can spend some time on that. It sounds like that's kind of what we're here to talk about today. So, we'll dive into the EVM itself, right? And then on top of that, we have our RPC layer, right? So, you need to be able to interact with these things. So, let me rephrase that. Humans need to be be able to interact with these things. Okay? So, you actually have two different types of network here. You have your networking stuff here on the left side of the diagram where the nodes are all talking to each other. And then on the right side you have your RPC APIs where people can start talking to the network. Your apps, your wallets eventually the consensus layer that we built for the merge goes through that as well. So that's probably the coarsest way that

you could look at an execution client. Once you have all of these things interacting, you have one. You could say I don't actually need the RPC part of it. I think that would probably still be considered a a consensus client. It wouldn't be very useful to humans. So I included it. Looks simple but it's not. That's the idea of the diagram. And in fact if you look this is the GU one right this is the basic one. Okay this is Aragon right? Aragon represents things in kind of like their own microservices right? So each one is executable on its own and then they talk to each other with RPCs. This is ref and it's all libraries right? So this is really a good domain model for what they think are the different components of

it. and you'll see that this aligns with it. And so this was a funny bit. I asked the Nethermind team, "Hey, do you have one of these diagrams?" And Lucas was like, "Just put Nethermind on it and it it'll be fine. It'll it'll be the same thing." And it was, you know, it was funny. We were kind of joking about it or whatever, but it was actually a really really good point. And it's like, yeah, because these are consensus technologies. They have to do the same thing. So even if you do design them in different languages in different approaches, they're going to be different, but they're because of like basic software encapsulation practices, you're probably going to end up with very similar subcomponents and ways that they interact with each other. Yeah. And

it's based on on the specs. So anyway, you you have some similar parts. Yeah. There's not as many specs in there as we would like, but so what I've done here, and if this ever works, I will send out this link. But what I did when I first started working on Ethereum was I went through the Ethereum white paper and I annotated different parts of it and where they're implemented in Basu. Unfortunately, this is broken and we're not going to be able to really drive our conversation with it. But if we skim through some of this stuff, we might find good places to start. So, I think I want to start with block processing. I

think I want to gloss over some of the networking code. What if we start from what happens on the wallet? So, you send something from the wallet, some comments, and what happens next? Okay. So, so this is an RPC method. This is an example of E send raw transaction. All right. So, the first thing that would happen is your wallet would be configured with an endpoint. So, it starts off by default. If you look into it, it's probably pointing to metamask.infura something if you use MetaMask, but you can change that. You can point it to the this API on your local host that's running connected to the network. You send it a transaction, right? And in this case we handle it. We do some some checking here just to you

know validate that the API itself is being run. Uh we decode it because the body of the JSON message that is sent into the API is just RLP which is awesome because that's what we're going to feed into the EVM later on. Okay. And in this case uh we do some validation here. Nothing too fancy. And what's going to happen is we throw it in the transaction pool. All right. So, the most boring explanation is that you send a transaction to an Ethereum client, it goes into a transaction pool. Now, how many people have heard of the memool or the dark

forest? Yeah. When we talk about MEV, we talk about the dark forest. And that's that's what this this transaction pool class. That's basically what this is, right? So these nodes are sending out these transactions. Once you fire it into here, it's also going to get gossiped out on the network and sent to everybody else because we don't know who's going to build the next block and who's going to potentially include your transaction in that block. So technically, mele is just transactions uh flowing everywhere like through the gossip. Exactly. Yep. And in our case, our transaction pool is called a layered transaction pool. I don't know if we want to get get into that too much.

Everybody has different implementations of of the transaction pool uh for good reasons because it is a really good denial of service vector because just gossiping transactions is something that you can do permissionlessly and it doesn't really cost you anything, right? Um you don't get charged until your until your uh transaction gets included in the block. Uh so we have to be very very careful and very strict about how we build our transaction pools and um how we prevent griefing attacks things like that. So uh it's in the it's in the it's in the transaction pool. Why don't we try to build a block on top of it?

Let's say that this client while your transaction is out there in the memory pool, new blocks on the blockchain are still coming in, right? So that's one thing that you got to keep in mind. None of this stuff is synchronized. Everything is all happening in one big big mess. All right. So, what if somebody else got your transaction and is including it in the next block before this one here? All right. So, I'm I'm imagining a situation where Justin is is coming up as a proposer soon. Okay. Maybe he's next.

He's got Kotch's transaction in the me pool. Okay. But a new block comes in. All right. And this is our loop. Our loop that we run actually runs on blocks, not necessarily on transactions. The blocks are going to contain transactions. Okay. So, a new block comes in, we need to process it. This might help. I'll keep this open here so you can kind of see the structure of the classes. I hope you all are familiar with object-oriented languages. Java is very object-oriented except when it's not. So, uh, process block here. All right. So, what are we going to do?

Well, that depends on where we are in the blockchain. All right. So, one of the first things that we do every time we go to process a block, we check to see if we upgraded, right? So, we organize our we used to organize them by block number. Now, we do it by time stamp because the consensus layer has a nice time stamp field in it. And so we every client has a protocol schedule. Basically, we say that all right, first we're going to do London, then we're going to do Paris, then we're going to do Shanghai, then we do Cancun, and these are all the different upgrades that we go through. So everybody knows that we used to use those rules, now we use these rules. So we get a protocol spec, and a protocol spec basically

defines all the different things that this particular hard fork requires. Okay. So, quick remark. We get the block from the consensus layer, right? Yes, that is true. The block came in from the consensus layer through the engine API. Yeah. All right. So, yes, that's a good point. We don't do block gossip anymore. We still do transaction gossip, but we don't do block gossip anymore. The consensus and the beacon chain uh handle that for us. So, let's see what else do we do here. We figure out what the parent of the proposed of the of the new block is going to be. It might not necessarily be the last one that you saw. You could be in the middle of a reorg and you might need to take that block and say, "All right, we're

actually going to build on the one prior to that." Uh, that's what the consensus layer is telling us. We don't care anymore. All right, we have to do some blob gas prices stuff. I'm going to gloss over blobs because I don't know that that's super useful for people that want to try and understand the EDM. This is some pre-processing. Here's the interesting bit, though. Okay, got a block. It's full of transactions. We loop over the transactions. Okay, the first thing that we're going to do here, I shouldn't say the first thing. The third thing that we're going to do here is get the world state. Okay, because the block might be building on not necessarily the most

recent one, we might have to get an older world state. So remember when I was talking about storage and I was talking about path driven databases and some of the things that we do with with bonsai. All clients need to have at least a few copies of state. Um they can't just only have the most recent one because you might have a reorg and you might need to roll back to a previous one. How they implement that could change. So in Basu we keep what we call log trees. All right, tree logs rather. Sorry. Because it's a Merkel Patricia tree, right? And then we have these logs that are just the deltas between them.

And so we can roll forward and roll backwards. All right. So in the case that this was a reorg, we might roll backwards a little bit and have an earlier version of the state for us to operate on. Okay. And then we process transactions. Well, that's not very helpful. All right. transaction processor. All right, process the transactions. Now, this is the mainet transaction processor. Now, we're getting to the good stuff here. Okay, everybody knows that a block is just a list. It's not just, but the important part of a block is the list of transactions that they run on. And each one of them is telling an EVM to do something. And it could be as simple as send somebody money. It could be a

simple transfer of value from one account to another. All right. But the interesting bits are actual executions where you're saying, "Hey, this transaction should go to this contract. It should have this data that goes with it and it should run that contract on this data." What could be uh how many transactions are in the block maximum or average? Great question. The answer is it doesn't matter. And here's the actual answer. It's not how many, it's how much gas they take. Okay. So I think so if you did all transfers, right, transfer is 21,000 gas. Just send money from one person to another. If you filled the

block with that, you could get 30 million divided by 21,000. That many transactions in it. And so that's that's like the maximum size of a block right now. I'm sorry, it's actually 36 million now. I forgot. We increased it a couple months ago. And realistically, I I don't know off the top of my head. I want to say like 200 someish is probably like an average number that we that we see varying sizes varying complexity uh but the the important bit now is less number and it's more it's more how much gas they cost how much work are we going to do okay so we do validation and I know that we do different levels of validation you'll see this as an optimization in most clients where

they'll do some basic validation like is the signature valid on a transaction well if it's not don't even put it in the Right now, we're doing slightly more nuanced validations that were inside the transaction processing loop. We say like, okay, well, do does the account have enough gas? And that could be like, yeah, we think so. We're not sure. You don't actually know how much gas a transaction is going to use until you run it, right? Because there could be conditions in the code that get hit. Like you and I could send a transaction to the same contract with the same data, but based on some state that has changed between them, they could go on a different path and cost more gas. So the validation may happen a

couple of times with different levels of precision. Okay. Um that's why you see like up here you have uh validate then validate for sender. Is the knots current? Did their knots change? Okay. This might this might be a timed out transaction now because another one was was processed with the same knots. Tracers. Now this is an interesting one. Strictly speaking, you don't really need a tracer in um your EVM. However, I think they all have one of some sort. This is a debugging tool. Um if you really want to get into the internals of an EVM, turn tracing on for a transaction. Most of

them have an API call in the debug suite somewhere where you can give it a transaction hash and it'll rerun that transaction and give you a trace of the EVM. This is super cool because it'll actually show you here's what I put on the stack, here's what I put in memory, here's the op code that I ran and the order that it runs in it. And this is what we use when we find consensus issues. When we have execution clients that come up with two different state routes after running the same transactions on the same uh prior state, we have what we call a consensus issue.

They both ran the EVM and they came up with different answers. And the way that we debug it is with these traces. Uh it is a painstaking process, but um we've all kind of gotten gotten used to it. It doesn't happen as often. And folks want to build tools to make it easier, that would be very much appreciated as well. But it's it's a it's a very common skill that an EVM developer is going to need to have. Getting through a trace, figuring out where the delta is, and then going back to figure out, well, what did the op code do and why why did it behave differently? There is a good resource where you can put your smart contract and do all this debugging. See memory, you see op codes stack. Yeah, I used it. Yeah. Yeah. Cool. Um, so

transaction pricing. Yeah. The fee market. So, this is a thing that changes from time to time. The fees that are charged for transactions. Prior to London, this was pretty much just like, well, how much gas does it cost? Now, it's a little bit more complicated. Right now we take the gas and we charge a certain price and that price changes over time based on network usage. So everybody needs to figure that out. Needs to kind of figure out based on again this is all driven by our protocol schedule driven based on the upgrade that I'm on right now. How do I how am I charging people for for gas?

Is it AIP1559 or Yes, that's the big one for London. Yes, 1559 was the one that introduced burn and smoothed out the pricing uh for the network. I don't know if folks uh remember, but prior to 1559, so like 2020, 2019, 2020, gas prices on Ethereum were very spiky. um you could submit something and if you were part of like a big uh NFT or something like that, there's a lot of stuff going on time, gas prices would change abruptly and it could be a little bit of a shock to the system. Here you can see some carveouts for things that we have to do for

7702. I don't think we want to get into that right now. That is some complicated stuff, but what you're seeing here is how we support that uh access list entries. So when you send a transaction, you can include a list of addresses that you plan on accessing. This is an optimization here. Uh when we say warm address, what that means is we're preloading it into memory and you get a gas discount on that, right? So every time you access something, you have to load it from memory. Maybe you have to load it from disk into memory. And those two different things are, you know, loading it from disk is slower than loading it from memory. Uh, so this is

your opportunity to say in advance, hey, I'm going to access the following addresses. If you warm them up for me, it'll actually cost less later on. Code delegation gas, that's more account abstraction stuff. Intrinsic gas kind of hinted at this. This is like the bare minimum of gas that your transaction is going to cost. So for instance, you're sending data to a smart contract. They're think of these as your function parameters, right? How much data that you have is a fixed cost. We know that's not going to change. You sent that much data that's going to go into the thing.

So we figure out that much gas and we know that the bare minimum you are going to use this much gas. We can charge that now and maybe reject the transaction if you didn't pay enough for it. Okay. So gas takes a big part in the execution layer. Oh yes. Oh yeah. That's that's another very common area for bugs where we maybe mischarge for gas, right? And because you debit the account that pollutes the state route, right? So you may char you may um you may modify state correctly when you're you're looking at a problem that you have, right? You may be looking through the trace and two clients agree on all the modifications

to state. Those are all fine and those are all good, but at the end they got the wrong state route and it was because maybe they charged different price for an OP code. They had the price calculation wrong and then they went and debited the account and now the balances are different and then that breaks your state route. So yeah, that's another very common area. That's probably more common actually than an actual logic error in the op codes. Yeah, gas costs. All right, we haven't even gotten to the good bit yet. This is the good bit. Okay, a message frame. A message frame is the transaction boundary for an EVM. When you first interact with the EVM for your

transaction, we start what's called a message frame. And the reason we do that is it's a little execution context for the start of that transaction. Okay, some transactions can spawn off other transactions, right? using call and delegate call methods within the EVM. Yeah, when those happen, we nest another message frame. Okay, so they kind of chain together and they allow us to maintain an accumulated context that is still unique to each transaction, right? So think of it kind of like think of it as the envelope, right, that your that your transaction is going to start off in. And if the

transaction tells you to execute other transactions, there'll be other envelopes that go, but they're all going to be stacked up in order and then wrapped in a bigger envelope. Okay, so this is building our message frame. All right, get version hashes. Again, this is a blobs thing. I'm going to gloss over that, but if that's your area of interest, we definitely have specialists we can put you in contact with. Yeah, contract creation. There's always going to be carveouts for contract creations and self-destructions and things like that and it changes. Yeah. Over the time these rules. Yeah. Creating a contract is different than just executing one. Um we can circle back to that. Oh wow, we're already 45 minutes in. Let's get

into the EVM then. All right. Initial frame. So we have our message frame here. Where's our execute? Okay. Okay, we build a stack of so again this is the stack of frames that I was talking about. This could potentially get appended to process. Okay, abstract message processor. All right, so this is kind of some bookkeeping internal to the EVM so we know what the state of the different message frames are. Have I started this one? Am I in the middle of executing it? Did I stop? Am I returning back? Etc., etc. So you see all of this stuff u but the important one is right here. code execute. Okay, EDM run to halt. And we've got our frame. Remember,

our frame has our transaction in it. And here is really the guts of the EVM state machine. Okay. What we do is we pull the code off of the message frame. This is our EVM encoded. In fact, it's a big old string of these, right? This is probably a website everybody has seen already. These are every bite the EVM says, "What does that do?" All right, what does that do?

What's the current operation? All right, so while we're still executing, we leap loop over it. We get a current operation. We have the frames PC which is program counter. So we've loaded code into the EVM and we have a pointer that points to where we are in that code and that's one of the things that we update and that's how that and that belongs to the frame that we're executing. All right, we get the op codes, right? And yes.

Oh, this big switch. This is how it works. Yep. Wow. Cool. It's a big old interesting to look through the code. Yeah. Big old switch statement. That's right. Because these are bytes, right? And um this was the most efficient way to do it, right? So, this is very highly tuned. Our EVM is very, very highly tuned. Basu, and I'm trying not to pat myself on the back too much because I didn't do this. My awesome colleagues did this. But if you look at the performance of Basu since the merge, it has just gotten leaps and bounds better.

And Dan Faren, uh, one of my colleagues who's our EVM specialist, spent a lot of time right after the merge, actually just doing really, really deep performance analysises of this stuff. and he finds he's he's a big proponent of primitive types and trying to really squeeze as much out of the the VM as he can. Here's an example of of that type of op optimization. Okay, so yeah, these are all static definitions of what the op code is and how it works. So let's do let's do something that's stack based.

Let's do like a bite pop. Now, inside your message frame, you have your current stack. All right, everybody should know what a stack is from CS lessons. It's basically a data structure where you push stuff on and it goes on the top. And so it's a it's a you know, the first one in is the last one out, right? Think of it as a queue, right? But it maintains the order. That's the important bit. So here, for instance, is is an example of a pop. Okay. Okay. It literally it just pops the bites off the frame. Okay, if you want to see more about the frame, the frame, I'm sorry.

Uh let's see. This is a stack that I believe uh this is Oh, this is a flex stack. So, normally you have a 32 I believe it's a 32 byt stack size 256 bit words on there but you know uh it it returns it and then it um gives you your operation result back. Okay. What op codes are people interested in? I'm not quite sure which ones to show off. Let's say um get something from the storage. I don't

remember exactly this s. Okay. Yeah. So these are the static operations. That could be why. Meaning that they don't have to access memory at all. They just work on the stack. Okay. So add takes two values, right? You push them both on the stack. You pull them off. You add them together. You push the result back onto the stack right there. That looks simple. Yes, it is wonderful. It is. Yep. The hard part was getting here, right? Like once you get down to the the the op code operations, things are pretty easy. The hard bit was all the stuff

that we went through and all the handwaving that I had to do. Don't look at that. That's a distraction. Don't look at that. That's a distraction. Because there's a lot of them. So these operations do they return any any values sometimes or or they just Yeah. So some do. So for instance um that was that was add, right? Okay. So add it pushes things onto the stack, right? So you have a stack input and a stack output. Whereas s load Oh, I guess you have a stack input and an output there too as well. Okay. Uh but there could be some things that like only manipulate memory mtore right so M store that there's no stack output because

you're not asking it to manipulate the stack you're asking it to stick it in memory which is a free form location right so if you need to store data that doesn't fit on the stack stack's only 256 bits you can just stick it in memory know how much data you put where the offset was and then other parts of your code can reference it that or maybe other transactions. Um, actually I don't think the memory goes across the frame. I don't think that would work, but other parts of your your smart contract can can access it. And after the eBay went through all these up codes and transaction is executed, right? And we go back to that loop. Yeah. Yeah. Let's

go back to the transaction processor here. All right. So that was this uh yeah so this is the process transaction method and then let's say everything was great and we added our two numbers correctly and then we did an STO and we stuck it in memory our world updator needs to commit it this is our storage change here and when we do that we will change the storage route that we get the route is expensive to calculate however so if we don't need it so for instance ever since Bzanti The Bzantium upgrade introduced we don't need to do intermittent state routes anymore. There used to be transactions had to know transactions. They had to be

run serily sequentially because each one depended on a certain state to be provided. Right? We don't do that anymore. So you don't have to calculate the overall state route for your transaction. Big optimization there. And in fact, if you do an analysis of a client, Basu does this for sure running through like a full sync, everything takes a lot longer before it hits the Bantium upgrade and then everything starts going much faster for exactly that reason. So yeah, committed to the state figure out whether or not you get a refund on your gas. Maybe you didn't use up as much as you thought you would. Yeah, this is more just Okay, so the Coinbase uh this figures out if you're proposing, how

much money do you get for proposing it? So that's the where we credit you for actually having done the the execution. It's not as much as it used to be. And uh yeah, wrapping up some transaction tracing. Like I said, that tracer was running this entire time. So when we did our ad operations and our slos and all that fun stuff, you would see that recorded in the traces. Those are becoming more and more important as people start working on ZK roll-ups. ZK roll-ups can take these traces out and turn them into ZK proofs to prove that they were run in a way that you can't actually you don't know exactly what it did, but you can prove that it did it.

That is way beyond me. I do not understand the moon math involved in ZK proofs, but if you do, please pursue it. Yeah. And then so the rest of this I think is kind of error handling and error reporting. You know if if the transaction doesn't execute successfully, you've got a bad block and you should not have received it. U so we stick it in a cache and we hold on to it and we don't build on it anymore. We don't add it to the blockchain. Um, and if folks try to build on it, we I think we I don't think we disconnect them, but we we do keep a a cache around that has our bad blocks in it that you can inspect. Um, and again, that's a

debugging skill. Yeah. After you went through all the transaction, what do you return to consensus layer? I think Oh, we just say, "Okay, cool. Okay. Oh, yeah. It's pretty much that works. Yeah, that works. That block is done." Exactly. Yeah. Or or we say, "No, that was a bad block." And even then they I don't know we have seen cases where they insist they're like no this is actually correct because the whole other network told me it was correct. I think you're wrong. Um again another source of bugs. Another another way that you can find consensus issues. All right. Great.

Boy, I talked for a whole hour. That was a lot. That was a big old information dump. I know we're supposed to have time for questions. I can stay a little bit longer if folks have questions. Uh but I do want to be respectful of time. I hope they have questions. Uh dear ladies, please raise your hands, ask your questions. That's a good chance anything about execution layer. Feel free to ask. That was really interesting to look through the code through the heart of the execution layer. I've never went so deep before.

Yeah, that's basically all the way down, you know, like once you get to the to the op codes and you're manipulating state, that's about as deep as it goes, but I handwaved over a tremendous amount of code. Yeah. So, question from Lada. Uh, can you show how stake withdrawals are done? So, stake withdrawals are on the consensus part, right? or so you are asking the right question because it doesn't happen in the EVM. That is a really good question because it's actually happens outside of I think it's in the block processor. This is going to be the case for a lot of the requests

that we have. Where are the Ethereum protocol contracts? Are they on the execution layer or consensus layer? So we have this is like the system the system contracts the things. Yes, those are on the execution layer. That's right. Yeah, there's no real contracts on the beacon tree. Um so how many basic contracts do they have? I think right now we have three. Let's see what we got here. I think this is what the someone is asking about here. We have these system calls. These are what take the request out of the block right now and run them through a contract and and at that point they

actually are running through the EDM. So I think the withdrawals might be the one that's still done out of band or maybe it's the deposits. I'm not sure. Yeah. So I think this is what you're looking for here. All right. So this request processor coordinator is running. It's configured with different processors that are bound to an address and they're mapped to a type that comes in on the block. All right, Lada, is it the answer for a question? Yeah, thank you. So, Koko, would you like to read your question aloud? Yeah, feel free to unmute yourself. Yeah. Yeah. Thank you, Kasa. So Justin there I had a couple

questions but first is know it seems like you've been involved in most of the hard works. So I'm most curious like what are you looking forward to in terms of the Ethereum road map? And then earlier you mentioned that something that would be really helpful for the Basil team is people getting involved in testing. So how do you go about that? Uh last question first. So getting involved in testing, there's a ton of work being done by Mario uh Mario Havo and Mario uh I always get Mario Hav and Mario Vega working on the Hive test and the Hive tests are coming a long way. Hive is a suite of tests that all run through the RPC layer and we have added all kinds of good stuff for the upcoming hard fork.

The dashboards are getting better. We're able to compare historically how clients used to perform on tests and running and are performing on tests. and we're introducing new processes where you have to be passing higher tests in order for new EIPs to be scheduled for inclusion. Okay, so if you want to make Ethereum go faster, help those teams write those tests. The tests are fairly easy to run, but the trick is is you have a little bit of a chicken and the egg problem, right? So if you know, for instance, EIP, I'm just going to say 400. Okay, we want to include that in the next hard fork. We know that nevermind has an implementation of it, right? You can sit

down and you can think up a test plan for it that runs through the APIs, runs through the APIs and collects the JSON responses and you can say here's what a successful test looks like. Here's what a failing test looks like and then you can submit that, right? And so you will be increasing the code coverage not just for that one client that has it implemented but for all the other teams and then they will be able to make sure that their implementation of it when the time comes is successful. So it's a really really I call it a high lever task that you can do for Ethereum because a it helps refine our specs better. we can actually see an implementation, see whether or not

there's any design problems, and B, it does work that execution client teams are going to have to do anyway in a way that's reusable across all the teams. So, it's it's a really valuable task. And u I'm sure Kashi can put you in touch with like the right people if that's something that you want to pursue. And I talked so much that I forgot your first question. Koko, Ethereum roadmap, what are you looking forward to? Me mitigation. Anytime that I can can champion that, I'm going to. Um, it's a really really hard problem. But there's plans. I've seen at least four different plans for different types of either encrypted mem pools or sealed transactions or auction type mechanics

that will either mitigate or eliminate MEV. And people are very skeptical. Um, they should be. uh the history of economics has never really built systems that are uh impossible to extract rent from. And so if we can do it, it would be an amazing thing and I think that we should pursue it. I'm hoping that Glamsterdam will have a lot of that in it. Um I'm also really psyched for EOF. Um just showed off bunch of EVM stuff, so obviously that's an area of interest to me. uh Dan Faren uh our our expert has worked on EOF tirelessly and Basu is in

a great position because of it. So I would say for Fusaka EF and for Glamsterdam hopefully more hopefully sealed transactions. I hope that's the one that gets in there. We'll see. But it's it's very early. The design's not quite there yet. So it'll be it'll take some time. Everything great starts with skep being people being skeptical. So yeah. Yeah. Good attitude. Next goes Glory. Uh, Glory, I have a bunch of questions. Try to be short. We have a limit of time. All right. All right. So, my first question is, how do BSA communicate with Inte clients? I know we've talked about

that before, but I can understand that there is in that communication there API. So, but I'm still like yet to understand fully how this communication actually works. So, that's one. Should I wait to finish answering that to find? Yeah, let me let me answer that real quick. No, that's fine because that's a quick one. It all happens over the engine API and the new requests mechanic is how we communicate back out basically, right? So, that's kind of it. The request mechanic is a general purpose type deal and the results of that are in the block that that comes back out to the consensus layer somehow.

Um, excuse me. So, it's a typical API request, right? Right. So, the engine API is your request response. If you need a response to get back to the CL after you've processed something like that, it's usually on a block that's being provided in the case of producing a new block um or directly on the response itself in the case of processing a new block from the um rest of the network. Okay. So my second question is on light client. I can understand that we had a team doing EPF that was working on sambar the light client version for Java. So I don't really know at this point if that has been implemented yet into Bessu and if they do that how does this how is it

going to work? How is the interaction going to be like? That is a great question. I actually have on my to-do list to schedule a meeting on that very same subject. So I will be setting that up right after this. Samba is portal client and so we're planning on integrating it through our plug-in API and the design for that is still TBD. the discussions for that like I said I need to to have this meeting but also we have our own discord um the basu team does it's on the formerly Hyperledger discord now it's the LFDT uh discord you'll find me on there and that's that's where those discussions will be happening the

adoption of portal network is probably further down the line from some more short-term things that we want to do so there's There's two EIPs that are out there that allow us to drop history. Um, so right now the amount of storage that's used by a Basu client is by far uh consumed by historical blocks uh that all clients accumulate. So the first thing that we want to do is drop all of those, free up that space and then we'll start adopting um portal network as a plug-in in BYU to allow people to provide historical blocks that come from the portal network uh instead of the the

main network. So just the context portal network is a data layer or yeah it's kind of like an archive layer, right? So it's, you know, we separated out the consensus layer because we were like, well, consensus is kind of its own aspect of the blockchain. Maybe we should separate that out and let people really focus on it. Historical data might be the same thing. It accumulates so much space, and space is really one of the resources that worries home stakers, I think, the most. It's their space and their upstream bandwidth. And so it makes a lot of sense for that to be pulled out into its own network. Um they have very different characteristics. Following the head of

an active blockchain in production is very different than doing analysis on historical things and there's not it's not the same audience. It's not the same performance profile. Um and so it makes a lot of sense for those to be separated out. Yeah. So the reason for this question is I'm looking at a situation whereby let's say for instance I am writing a backend service with rust and uh you know js is for javascript so I would want to imagine that maybe the equivalent of js when working with rust it could be rest I don't know if red will work in that scenario so similar to bessu and um oh red is what yeah yeah I'm not sure it work now one approach

that you could take would be like writing a plugin, right? So you could write a Basu plugin that reacts to blocks, that reacts to transactions, um that gets access to the state, uh all those types of things, but you would be in a very basis specific world, right? So if you write an application that is using JavaScript over the execution APIs, that's going to be more portable and you're going to be able to use it with different clients and things like that. So like it's possible but I don't think I would recommend it.

Okay. Yeah. So I was just like trying to like understand the similarity between I know it's ethology is more like an OPC. So I was just like trying to understand how it relates with u with execution clients and then yeah uh that's just what I was thinking. Sh right any other questions? Okay. So um one last thing I about the ROPC standard like what's your plan on on confinging that? Yeah. So I guess step one is to hassle more people to show up to those meetings, huh? I think everybody wants it to be worked on. My plan is to just

keep hurting the cats and to try and make sure that the work that we are doing is being pulled in. So, I've reached out to some people that have committer access on those projects to try and accelerate that a little bit. And um I think we would be happy if we got to I think Okay. So, uh, plans change, but I think the goal that any of our plans should be aiming for is like the tests become so self-sufficient that they can be used by designers.

Meaning that we don't generate RPC compatibility tests based on clients. we generate them based on specs or maybe a reference implementation that isn't GU like eels. So I think that's that's the goal that we want to get to is the schemas for everything being well defined enough that all clients can trivially automate their testing that they adopt them. And they're also flexible enough that it's not a bottleneck for future development. Right? So when for instance the next version of the engine API comes out, uh we don't want them to get

tangled up in any type of RPC standards that get in their way. Um I think those would be the high level goals. You know, in the short term, we're thinking very very tactically, right? get PRs merged, get stuff landed, fix things that are uh causing people pain right now. Make sure that the hive tests don't have client specific stuff in them. Um things like that. Thank you. You're welcome. All right. Great. Any other questions? No. No questions. No time. I think this Thank you very much, Justin. It was really interesting talk. Yeah. I hope you get a

lot of it, a lot of insights about execution layer and u yeah so uh we don't have uh much time we have only a month uh to by the end of the cohort so please speed up ladies and ask your questions tag me in the discord if you have any questions on your PRs and yeah thank you Justin thank you everyone and