The EVM and EVM Object Format (EOF) w/ Danno Ferrin (Swirlds Labs)

**Speaker A:** Foreign. **Speaker B:** Hello, and welcome back to another. **Speaker C:** Episode of the Strange Water Podcast. Thank you once again for joining us. **Speaker B:** For another great conversation. **Speaker C:** Today's discussion is a deep dive into the Ethereum virtual machine. Though you're about to hear from one of the world's foremost experts in a very technical topic, don't worry too much. We try to keep everything pretty accessible. But even still, before we dive in, it's probably helpful to review what the EVM is and how it relates to Ethereum. Now, EVM stands for Ethereum Virtual Machine, and it's the computational environment where smart contracts live and transactions are processed. Have you ever run a Windows emulator on your Mac? Now that's a virtual machine. It's an independent computing environment sandboxed inside of another computing environment. Whenever you make a trade on Uniswap or donate to support the Protocol Guild, you're generating a transaction which is really just a set of instructions for the EVM to process. Now, stepping back, Ethereum is made up of thousands of individual computers, each running a piece of software that spins up the evm. Through the magic of proof of stake, each of these computers are able to communicate and coordinate to ensure that their local copy of the EVM is exactly in sync with every other node in the network. The record of what happened within the EVM exists across thousands of computers all across the globe. As I hope is clear, the EVM is the beating heart of Ethereum. Everything else exists just to create and secure this credibly neutral computing space. And it's within this space where all things that are recorded on chain actually happen. And so I think it's entirely appropriate that we spend some serious time thinking about how the EVM actually works. Fortunately, today we have the perfect guest. Dano Farren has been working directly on the EVM for five years, including his time with Consensys, working on Hyperledger, Besu, and at Swirl Labs, where he is currently working on bringing EVM equivalents to Hedera. Today's discussion is focused around the next major upgrade coming to the evm EVM Object Format, or eof. Over the next hour, you'll hear a little bit about how to think about this update to how code is packaged and and through it you'll learn a ton about how the EVM works and the evolution of the EVM going back to the days inside Gavin Wood's head, all the way to an Ethereum far in the future. One more thing before we begin. Please do not take financial advice from this or any podcast. Ethereum will change the world one day, but you can easily lose all of your money between now and then. **Speaker B:** Okay. **Speaker C:** Ladies and gentlemen, Dan o' Faron on the evm. **Speaker B:** Dano, thank you so much for joining us on the Strangewater podcast. **Speaker A:** Hello. Good to be here. **Speaker B:** Well, man, I'm super excited for this one. I mean, as you know, I first heard you on the Peep and EEP podcast podcast talking about Ethereum or EVM object format. And since then I've been trying to get you on the show. I've been so excited by both your background and like the deep, interesting and like really important technical work that you're doing. So once again, just thank you and welcome to the show. **Speaker A:** Thank. Glad to be here. I've been listening to it for a while. I love the Dune reference. I listen to Dune a lot. It's my sleepy time story that helps me fall asleep with my sleep mask. **Speaker B:** But no, man, I would love to do a whole episode on Dune. But I will say, like, they start so good and then by the end I just can't even follow it anymore. **Speaker A:** Yeah, it gets weird at the end and then his son picks it up and it gets even weirder. **Speaker B:** Great. So in lieu of Dune podcast, let's talk about you and let's talk about crypto. But so I'm a big believer that the most important part of every conversation are the people in it. So with that as a starter, can you tell us a little bit about who you are, your background, I guess, how you found technology and then because I know a little bit about your background, ultimately why you decided to make the leap from like, maybe more traditional, just accepted technology into this like, wild west of crypto. **Speaker A:** So, yeah, background about myself, I grew up as a child in the, in the 80s and 70s and 80s mostly. So that's, you know, when home computers started going on. I was always fascinated with home computers. My older brother, the first computer was a mail order kit ZX80 and like they had a solder the pieces together and that was just so interesting to watch. I had no idea what was going on. But, you know, I liked programming computers and making, making it do things, you know, independent, you know, and the complex, very methodical instructions a lot better than, you know, the sort of fuzzy thinking that goes on in, in, you know, English and textual analysis and subtext. It's just like there is no subtext with a robot tractor. You tell it where to go and it goes there. So that really appealed to me. So, you know, I did computers. I, I thought about doing engineering in college I thought about doing actuarial work. The funny thing about actuarial work, I was accepted at a college and at the university. That's what got me in. And I looked at the test you have to take as an actuary and like the last few tests, I want to know what I was really getting into. And they're talking about, you know, building these shell companies, putting them in the Bahamas, doing all sorts of, you know, it just looks like this is not something that terribly interests me, although the math was interesting. So I just stuck with computers all the time. Worked in Silicon Valley for a couple of years in a startup before the dot com boom. And then my first real job was at an insurance company. Not, I mean it was, they were, they were trying to build exchanges back in 2000, insurance exchanges. And that was like, you know, 10 years ahead of the time. So, you know, too early is indistinguishable from wrong. So they went out of business. Then I worked at a Internet startup that was doing network configuration automation, again ahead of its time, indistinguishable from wrong. Some of their tech got bought, but now, you know, software controlled, you know, unified control plane of networks is very common. We just, you know, we're just a little too early to the game. Then I spent, you know, six years at a defense contractor doing front end work and GUI work because that's really what I was doing at the startup for network configuration I was doing Java Swing and I was doing the same stuff with the contractor. And one of the last things I did as a contractor was this thing called graph analysis where you'll like take all the links of everyone, put them on a graph. And one of the things about that is that most GUI toolkits don't do that well. At the time they were all based on squares and things not overlapping in the idea of moving stuff around and reshaping things arbitrarily and not having clear cut boundaries was kind of hard. So the toolkits were mostly less about graph analysis and more about the visual layout of the graph. So that's in like the time the toolkits like Flash and JavaFX were around where they use this thing called a scene graph. And I. So when I left that job to go work at another company, I was working Oracle, working on backend tooling for Java. I still loved the idea of visual layouts of stuff, even though I was getting out of front end. And there was this company, yworks and they had this visual layout, you know, a lot of exciting Graph layouts and I was hooking that on the back end and using Java FX in the front end. And the problem is I needed some interesting data set that was legal for me to access. You know, there's all sorts of interesting data sets of government work that you really should be sharing. So I wasn't using those. But what I came across, it was about the same time that bitcoin had its first thousand dollar pop. It's like, you know, the first big bull run around happening. And I did some read up, I read up some of the technology on it and I was reading about unspent transaction outputs and where those came from and I'm like that's an acyclic directed graph if I ever saw one. So I spent some time parsing the bitcoin blockchain and getting data into the system. I did some test transactions of my own and I was able to, you know, visually lay it out and get it into this graph analysis stuff and that was pretty exciting for me. So that's, that's kind of how I got started in, in crypto. I briefly thought about doing a bitcoin forensics operation. A couple of things got in the way. I'm not excited about government contracting. You know, regardless of how you feel about what the government does, contracting with the government is, you know, an entirely different beast billing. And you, you can't really do a venture company based on we're going to sell this to the, to, to the three letter agencies and law enforcement. That's really hard. That's a really different pitch. You really got to have the connections. The tech's like, you know, third tier issue honestly in those situations. So I sold it off for chump change. But hey, it was a, it was a crypto exit back in 2014, which was 2015, which is amazing. So at that point I went to Google for a few years. I worked in their payments group for half the time and I worked in another group that was doing ads measurements, measuring eyeballs, you know, stuff like that. And about the time I was between one of those ad measurements projects, we had shipped a good one for YouTube. I worked in Boulder. And the reward for doing a good project in Boulder is they take the project and they send it to the west coast. So I was shifting to another project in the same ads measurement group and that's when a recruiter from Consensys called me up. I've been doing a lot of Java work. You know, Java still got a good big place in Google, backend work and they told me that they were building Ethereum client in Java and would I be interested. And I had been. You know, when I worked at Google I was going with the premise of that, you know, I'm just going to get Blockchain out of my system. Everyone here hates it. They can't say enough bad things. It's inefficient, there's much better ways to do it. But I just could not stop paying attention to it. I followed the Dao fork, I followed the Shanghai attacks on CoinDesk. It was a very regular read even though I was distant from it. So when the recruiter called up it was just like an obvious yes. I mean I couldn't focus on my work at Google after that at all. They couldn't pay me enough money to get there. So that's when I just jumped off and went full crypto. And Pantheon was the name of the project before it became Hyperledger Besu. So for the past five years through a couple of different companies, I've been contributing as a core developer to Hyperledger Basu. I've been on all core devs calls. So right now I'm working at Hedera, working on the EVM equivalence portion of it. I used to be working at Consensus, so yeah, that's where I'm at right now. That's how I got into the system, how I jump full feet in. It's got a lot of stuff that interests me and I love building things and there's a lot to build in Ethereum. **Speaker B:** Well before we get to what you're working on and what we're building in Ethereum today and what needs to be built, I just want to spend some time on your journey and I think something that really jumped out to me is like look man, you know this better than me. We are in an industry that is, let me just say the like median age is not allowed to drink in the United States. Like it is a very young group and I think like a huge reason for that is. So I'm 32, like my generation of people entered a world where yeah, computers were not great and like, yeah, we didn't have, you know, broadband Internet but we did have computers and we had games and we had Internet. And I think like my generation and you know, I study computer science at stanford, so literally 4/5 of my class were working with you at Google. I just think that like there's something about your story and then like being a kid right now where like you really understand the malleability and the fact that like this stuff is being created from nothing in real time right in front of us and it's an opportunity to be involved. And like, I think to me that like explains a lot of your excitement and willingness to roll up your sleeves and jump in as opposed to like a lot of the attitude I see of my peers of just like, what's that? I don't understand this, therefore it's not real, therefore I don't want anything to do with it. And I guess like I just wanted to, to hear any thoughts or reflections you had on like why people really have a problem like looking at crypto as like an actually interesting. And for me it's an interesting comput. And I'm like so bored by things like hard money and finance and all that stuff. Like why, why do you think that people have so much trouble like giving crypto a fair shot? **Speaker A:** So some of us were their biases. Like when I was at Google, a lot of people that were in their previous experience, their understanding of what their goals are at the payment system at Google, when I was there, one of the, you know, bitcoin was a non starter because you couldn't do like a billion, not a billion, but they had some absurdly large number of transactions a day to try to bring blockchain technology inside of Google would have been a non starter because they could, the, you know, the current technology could not sustain the amount of transactions they had just for people buying AdWords just for logging that sort of information. So I think that the issue with, with Google is it's such, you know, such an absurdly large scale. But at the same time, I think what gets a lot of people's biases is they're 100% okay at Google with things being centralized. I mean, you know, if they say that there's these three data centers and you know, they control their database and they keep the synchronization and you just have to trust the controllers. At 3, it's easy for Google because they literally own the hardware that's running that they can call up, you know, someone, Bob or Alice in the network center and say, hey, is this wire just connected? Is your clock off? And they can work with those people and they can make it work. And with centralization like that, you can get just crazy throughput going through and crazy high velocity because you have an essential level of trust. You have trust in the centralization, you have trust outside of it. So I think some people, why they don't give crypto a fair shake is because it doesn't fit their immediate needs. So some of them, they just don't understand what they're looking at. And on a vice versa, they have no appreciation for the needs of censorship resistance because they have the bandwidth to handle everything. It's like, well, why do we censor that? We would lose money if we censored an ad. Or they're fully on board with ads. It's just like, no, we're not gonna, you know, sell ads about, you know, zippy. No, no's a pew pew pews because, you know, that might, you know, get our other advertisers to run away. So they're all rational decisions based on what Google is, which is at its courts and advertising company. There's, you know, now they're transitioning into a cloud infrastructure company. But it permeates. And I think one of the hardest things I had with being at Google is they are by nature and by necessity a very judgmental company. I mean they have 20 milliseconds to make a judgment if this is the right search results return. So they have to be judge it really quick. And so people who understand that judgment, appreciate it, get that personality insight. Because it's like I go to a fairly conservative church and I felt more judged at Google than I did at church. I mean that's just. But that's the nature of the company and that's what makes it tick. And that's like a competitive advantage for them. So like trying to get other people interested in crypto. The other part of the coin is what they have works for them. You know, they're not, they're not operating on the fringes of society. They're not trying to push boundaries. They're not trying to, you know, put a dent in the universe. So they've never had experiences with banks saying, oh, we don't like that transaction, we're going to shut down your account. They've never, you know, I mean I live in America. I'm incredibly, you know, privileged to not have to worry about people following me home and snooping for the government and you know, various, you know, other. I mean these sound like, you know, when I say these, these sound like stuff out of George Orwell's 1984 book and you know, concerns like that. But there are places in the world and people in the world where this is a very real concern for them. So the ability for censorship, resistance to get a message out is very important to them and probably the closest experience most first world people have to this is just being careful what they say on social media, because their HR person might be following them and listening to what they're talking to. I mean, that's like the closest that some people get to what concerns about, you know, freedom of speech and censorship are. And they're, they're more than willing to make the exchanges. Just like I get paid good money, so I'm not going to act like a fool online. I mean, some people are 100% okay with that exchange. So it's so, you know. But the thing is, when I came into crypto, I mean, I understand those, those crypto, techno anarchist, I guess is one way to put it. I understand and appreciate some of the places they're coming from, but honestly, what got me interested in it is just the ability to build stuff. I love building things and there's really unique opportunities for me to build. And I think that's where it's, it's. Crypto's created kind of a unique world where you got the builders and the idealists coming together on the same thing, coming in from different directions, from orthogonal approaches, and the intersection of those are just exposing some incredibly unique and valuable things that wouldn't happen if just builders came in or just idealists came in. You know, just this looking at it at two different angles in the interplay is really opening up a lot of interesting things. **Speaker B:** I mean, I'm just going to be honest here, and I'll say that I only entered crypto in 2021, so everything I said needs to be taken with eight grains of salt. But I, I do find that there's really only two origin stories of people in crypto. And one is kind of what you described, which is like your work or some project or whatever put you in proximity with it. And just over time you realize that there is nothing like crypto just in the ability to deploy and experiment and to like mess around with stuff that hits like the, the open market instantly and like, are really driven by building. And then the other part are people that are like, in some way have been actually betrayed by the, let's call it the western financial system, right? And like, I, I will identify as one of those people. I've got like many stories I have. Well, the one that I'll draw the attention to is in 2022. So after I found crypto, I was locked out of my assets at Wells Fargo for like three or four months. Had nothing to do with crypto at all. It's like totally arcane thing. But the, the result was that I could not withdraw my money and that ended up with me going, you know, minimum payments on all my credit cards. Eventually I had to take a five figure loan from my mom until like all of that got worked out and then it did and all's well that ends well, but like it in order to turn someone into it. Let me put it this way, it is not hard for people to understand the value of crypto when you've just been like absolutely screwed by the system that crypto is here to fix. And that's like not even talking about all of the actual idealistic reasons like political self sovereignty or political persecution or being able to cross borders, all this stuff. Right. And so I think there's a lot of interesting stuff going on in the world, but there is something really weird and special about our space. And yeah, part of it's the building and part of it is that we all have a chip on our shoulder for some reason or another. But yeah, I don't know, I hope this lasts forever because it creates a very special building environment. **Speaker A:** Yep, it's pretty weird. It's a unique opportunity, unique serendipity of events. **Speaker B:** Cool. We can spend all day talking about your background, but let's get into the work that you're doing. You said for the last 5ish years you've been contributing to hyperledger based Zoo as well as just been contributing to, I guess the ethereal concept of the evm. Can you talk a little bit about, just give us a brief summary of the work that you do the five years so far and then maybe end with how did you end up finding yourself working at Hedera but still contributing to the evm? **Speaker A:** The EVM for me, I mean I've always been fascinated in virtual machines. One of the things that drew me to Java, they had a virtual machine and I before I, you know, build complex things with it. I read up about the virtual machine and the class file structure and just fascinated with the idea that it would compile this bytecode down to, you know, intel or Motorola, Mac at the time, or now to arm. And it's a really old concept, it's older than me. Pascal used to use it. This whole idea of a virtual machine bytecode and interpreting it. And so it's not, as Greg Colvin said at a conference, EVM's future is the past of computing. So it's applying a lot of things that have already been there. You got a Stack machine, which is a well understood and simple machine that could be optimized out to other formats. You have your simple math you got some operations that help you cross the barrier between simple arithmetic into the outer machine. But when I look at these machines, this is the first broad based and widely used machine that I think provides a solution to. There's a computer science problem that you're familiar with, and a lot of the listeners are probably familiar with, of that of the halting problem. You take these old machines, they express it in a very weird way. So it could be mathematically analyzed. But the question is, given a program, without executing it, can you figure out if it's going to halt or if it's going to go on forever and lots of serious mathematical analysis later. The answer is no, you can't figure it out without actually executing it. So that's kind of a problem. We're talking about distributed systems where everyone executing things in exactly the right way and not being able to attack each other is important. So the EVM introduces a notion of gas. And the big thing that GAS solves is the halting problem. So every time you do an operation, you have to decrement it the gas, you have to spend GAS to do that. So you can look at any contract and the answer to that question is, if executed, will this program come to a halt? And the answer is yes, because you're going to run out of gas and you're going to shut it down. So that's kind of of all the VMs, that's a necessary change that EVM used to do to solve the halting problem, because you can't run stuff forever. When you're trying to come to consensus across thousands of transactions a minute every second, or whatever the speed limit you're at, if you want to impose some sort of limit and make sure people can keep up and keep consensus, you have to be able to close the door on long running transactions and say, no, we're done. So being able to close it, there's bad ways and there's good ways. You could just say, well, we'll just let it run for 5 seconds or 500 milliseconds or 5 milliseconds. And that's great until you start running on a faster machine. And then you have like a program that runs just at the 5 millisecond. So someone's machine that's going to have a bunch of cache faults and swap stuff in is going to fail. But somebody who's got everything loaded up in cache because they're not doing everything else, it's going to work. So if you just use wall clock, you got two different answers. So what the GAS notion gives you is the ability to reasonably say, no, trust me, this will come to the end. Spend as much time running it as you need to. It'll eventually end. And when it ends, everyone can can agree on what the state is at the end, how it ended, where it ended in very specific ways. And that level of specificity in a smart contract is essential because there is no room for ambiguity when you're trying to, you know, consistently share millions of dollars of transactions. You have to be absolutely right on everything and there's got to be no room for argument. So by introducing gas, we can safely do these smart contracts. Not the best name. Verifiable computation might be a better name. You can verify this computation in a reasonable amount of time and come to a reasonable conclusion that everyone's going to agree with it. It leaves evidence at the end that you all came to the right solution and so everyone can go on with their lives that this has been done and you don't have to continually doubt what's going on with the computation. So as far as what drew me to evm, I think those properties are very unique amongst all computations, which is kind of different from say, a Google data center. If you give slightly different answers to the query based on whether you're dialing into an east coast data center or a West coast data center, that's actually okay. Because some people especially I was reading some stuff up on AI and some of the early GPT models, they were concerned, well, why are we getting different answers? This should be a deterministic algorithm. There's no randomness in there, but they split up the algorithm across multiple machines and these tokens are getting processed in at multiple times. So there's no randomness in the algorithm, but the implementation brings in a certain ordering changes and you can get different things. And I think that's part of the Brownian motion that makes the current generation of AI look so convincing, is because it's not always identical. It's got these little flaps of butterfly wings that just have these huge impacts on the kind of output it gets. **Speaker B:** Yeah, I'll actually, just to hammer home your point, I would not have like, that would not have even registered to me, except for just recently I upgraded my Twitter subscription to the highest one. And so I got access to Grok, right? And the craziest thing happened to me, so. Or it's not crazy, but it was so jarring that I asked it like, hey, I want to write a better copy for my next Strange Water episode. Like, how Can I improve? And, you know, my thought was like, it has access to Twitter data. It can tell me like very specific things. And so it basically not only did it chunk out this, like, extremely generic, just like how to make more compelling Twitter posts, but it had like a full paragraph of jokes. And then I was like, okay, this is useless. I need something that's actually specific to what I'm asking, to my tweet. So I rewrote the query and the exact same thing with the exact same jokes came out. And that was the first time that I'd ever experienced one of these chatbots actually acting deterministically like a machine. And it was so much unlike the human experience, the that I really felt exactly what was happening there. And so no real point to that story other than to say that it's just like really interesting that the emergent properties of the system actually like end up being so important to the user experience of it. And I guess this is like completely outside of EVM world, but just thought that was a fun anecdote. **Speaker A:** Yeah, but I mean, I mean, user experience, I mean, that's kind of an interesting tangent to go on. There's so much things to go into user experience than just like the pixels on screen. Because when I was at my defense contracting and startup where I was working in front end, user experience is something that's talked about a lot. But user experience is a lot more than just front end work. If you're working in dev tooling, they'll recall it developer experience because their users are developers. And when it comes to AI, the experience is not just the text that comes across, it's the feel. And when you get an experience where you give a radically different query and get the same answer, that just ruins the illusion that you're talking to a person versus, you know, when you are working on, you know, chat, GPT or Bard and you give a slightly different query and you get a radically different answer and then you try and refine it and they say, oh, I'm sorry, I got that wrong. Or, you know, it provides more of the illusion. It's those, those subtle things that really add up to the user experience that you don't notice. I mean, you know, like there's what, like a 90% invisible podcast that used to be around a lot of the things you just don't process consciously contribute very much. This developer experience, this user experience. And so to bring it back to crypto, I mean, people complain a lot about how crypto's got a UX problem and the thing is, what I think people are noticing is they're just subtle friction points that are so different from the way they're used to interacting with, with a computer or with a phone or with their bank account. Because, like, you have to, you get one shot to do a lot of transactions. And you get one, one particular thing. Just a second. Let me turn my robot vacuum off. **Speaker B:** No worries. **Speaker A:** I think its ears were burning. It heard me talking about artificial intelligence. And so it's like I'm going to vacuum the floor and show that I'm doing a good job, except it's actually on a timer. So that's not quite the same. But that's those subtle things that you might interpret it as saying, oh, the robot vacuum is listening to me talking about AI and you interpret it and you put this extra layer on top of it that wasn't there. And that's the essence of the illusion. But the friction you get with trying to do transactions with crypto and you get one shot, you send it to the wrong address, it's gone forever. That's not the case in banks. And the reason is having been on the backside of Google, there's entire processes where they balance stuff out. They have people change things, and there's actual processes around manually moving money around and manually fixing ledger lines to comply with laws and regulations. Because you, you know, it's pretty well understood that banks and places can't just steal money, even if it is out of, you know, out of negligence. You know, if someone sends it to the wrong address and you refuse to give them payment for that, you know, they still have ways to get it back. And that's. That was what was eye opening. Working at the back end of payments at Google is just how much of the global financial system is still run on duct tape and baling wire. And it works and it continues to work. And the reason it continues to work is because there's people committed to make it work. And so I think that's why, like, you know, your bank feels so much more human and personable, is because there probably is someone on the back end when your transaction doesn't add up or that gets sent with the wrong tax information, someone's there fixing it and making it work. When the, when the accounting reports come back and say, oh, you're off by 2 cents, you got to go figure out what went wrong, they'll spend hours combing through, figuring it out. And if a block comes back in Ethereum and it's like two way off, it'll just get thrown out and say, nope, try again. So it's kind of a different experience. **Speaker B:** Yeah, well, and just to be on the crypto side and not give traditional institutions too much credit, I think part of. Part of going back to the experience conversation, like, yes, like, they kind of feel more human and like, yeah, like, more things can happen just to, like, fix a mistake. But like, the flip side of that, I think the further we go into the 21st century, the more all of us understand that, like, okay, if we complain hard enough, loud enough, and, like, big enough, like, maybe we can get a company to, like, bend a little bit to our will. And so, like, I find, like, my experience in life these days is, like, so much time, like, whining to companies and businesses and corporations about, like, hey, you guys should have done this. I know that you don't want to do it the right way, but if I, like, make a big enough stink, like, you'll probably fix it. And I think something that's, like, really refreshing and different and, yes, scary, but different about Ethereum or about blockchain is that, like, you just know that you, like, you're gonna get what you're gonna get, and there's no one for you to argue with. Like, and it to. To where we started this conversation, like, it is deterministic. Like, if you do this, it'll happen and it's over. There's no one to talk to about it. And for me, that's much needed in this, like, more and more chaotic and, like, needing to fight for yourself world. **Speaker A:** Yeah, I mean, it's. The downside is code is law, bugs and all. But on the flip side, it's very dispassionate and not targeting anybody for a particular reason. It's just, unfortunately, you trip the wires and you get to deal with the consequences. **Speaker B:** So let's go back to talking about the evm. So we started this conversation talking about all of the. The nuts and bolts of a vm. Nothing is new there. It's all taken from things, from decades and decades of computer science research. Then we talked about what the introduction of GAS does, is allow us to solve the halting problem. And because we can solve the halting problem, we can now feasibly build a distributed computing system. But that's the EVM as it is today. It works. Like, I use it often. Like, it's great. I love it. But to the, like, you're still working on it, right? So can you talk a little bit about, like, what are the big gaps in front of us today? That like, let's say we completely ossified things got too political. Every core dev decided to go work for a bank. Like what would the EVM as it stands today, like where are the big problems that make like Ethereum not yet the world computer. **Speaker A:** So there's a couple of things in the current way the EVM is set up that we're trying to fix with a project called Ethereum object EVM object format. It's not Ethereum object format, it's EVM object format. @ a core I would say it's mostly container format and a few key changes to a few base assumptions of the way the EVM works. The first thing about a container format it's just says here's the data, here's the code, here's some stuff about the code, go run it. We're not changing anything about the messaging model. We're not changing anything drastic about the operation codes. We're not changing anything about the account model at Ethereum. We're changing one part of how we're packaging it and it solves another problem. And these are all kind of interrelated problems. It's like, you know the song There's a Hole in the Bucket. We can't have immediate arguments because we can't have static jumps because we can't have immediate arguments. We can't have immediate arguments because we can't verify the code. We can't verify the code because we don't have a container format. We can't have a container format because there's already code out there. It's like this whole thing, you can't just fix one thing incrementally, you got to fix it all in one go to fix everything at the same time. I mentioned dynamic jumps. One of the things that the EVM does that's fairly unique amongst most VMs is allows you to do branching control based off of data off the stack. Most other VMs like Java and Net and Wasm, they have very. They either don't let you do it, they make you have your jumps be static, or they have very restrictive rules about how you can introduce that value into the stack. And the problem is with an Ethereum solution to try and solve this is they introduce the jump test argument, meaning there's only certain places you're allowed to jump to. It's kind of like it's almost like there's an old joke language called intercal. They don't have go to statements, they have comes from statements. So you don't say you come from this Spot. But you say but you could land here. So it's kind of unintentionally going to some really old computer science humor. But the problem that this, the dynamic jump that you could put, so the structure is you could have something in through call data and you could put that call data value on the stack and then you could use that call data value stack to jump to anywhere in the program. So there's a lot of analysis you can't do because someone could introduce random values from outside the system to undo all of your static analysis. So it makes it so you can't statically analyze the evm, you have to take it as it is. And the other problem is then you don't know which one of your jump desks you're going to go to at any point where you jump. And you know, when you're interpreting it and running it, that's not really that big of a deal because you're just, you just point it to the PC as you need it. But looking at things that are going to be very important in the future of Ethereum, there is, you know, zero knowledge proofs. And so that's basically, you know, you can get a short answer of how you run the execution of the evm, you can get a hash at the end of it, but zero knowledge proofs to basically take a bunch of checksum data along the side and verify this checksum data and prove that you did the math correctly so that other people can take this, do a little bit of math on their end and be sure that you ran it correctly without having to run it themselves. But when you have really complex things like, you know, static jumps that could go anywhere in the program, it makes these zero knowledge proofs much more complex than they need to be. They've had to invent new techniques of how they're going to go about analyzing it. The whole arithmetizing the trace. They have invented other sorts of ways that they, you know, there's, there's some PhDs that have got some, you know, and, and some people going off a master's that have got some nice theses and dissertations off of solving some of these problems. And that's because we have dynamic jumps, but we can't replace dynamic jumps with static jumps unless we can have an immediate argument. And so that gets into the problem of why we need EOF is because, well, if we just introduce an immediate argument, what if there's old code that has that old opcode and that immediate argument then contains a jump destination, then You've changed the meaning of the code just by upgrading the software and that's bad for long term stability. So, you know, really I need to show a graphic about this and tell the story about it. But basically because of that, we need to have validated code that needs to exist in a container. From that we can get rid of dynamic jumps and only have static jumps. And with that, the Epsilon team from the Ethereum foundation has also introduced other long standing and decades old concepts of things like stack validation. You have to follow certain rules on your stack validation and code validation, and from those you can do some really interesting transformations rather easily. The biggest deal one is with a well formed, I mean you could do it with well formed evm, but with eof you can always do it. You can do a transformation where you take the stack machine and you convert it to a register machine. And that's kind of important because that makes ZK transformations really easy. Because doing stacks in some of the ZK languages is not terribly easy. It's like going back to my experience in math when I was doing differential equations. The last bit is always about Fourier transformations and it teaches you one of the greatest mathematical statements, which is just figuring out where your coordinates are and how you view it can make a completely intractable problem trivial. So you take these really complex mathematical relations, you apply the right Fourier translation on it, and you're just doing addition. But there's complex rules about how you transform it and you got to do the right thing in the right place. That's entirely what some of the class is about at the end, is when you can do it and do it right. I barely scraped out of there with a B so that I'm not a math major. But in that vein, being able to go from a stack machine to a register machine can be huge. I mean, what's, what's surprising when you look at opcode execution. Stack manipulation is like a large percentage of the time spent executing the vm. It's not doing the math, it's not doing the calls, it's not accessible. Storage takes a long time because it's expensive. But from a raw number of operations, it's mostly stack manipulation, duplicating and swapping and pushing onto the stack and off the stack. And if you can reduce those to register operations, there's like, you know, 30% of EVM execution that just disappears because it's just moving stuff around. So that's. So when I look at EVM and eof, one of the complaints that I get from people Saying, why are we doing this? You know, one of the first questions they have is how is this going to make the node's life easier? How is this going to make things better for a validating node? And there's some small things. Code will be slightly smaller, you'll get a little better gas efficiency, you'll be able to get more transactions in if everyone uses eof. But the real big benefits are outside the validating node. And so having A well defined VM that can do these transformations is great for ZKs. So they could move to compiling the smart contracts into ZK directly rather than making an interpreter, which will make ZKs more efficient and easier to create and faster to create. But also you could cross compile it into LLVM and you could make Java code or ARM code or intel code that would run these contracts. And the people that would be super excited about this are these MEV builders. Some of them have done this by hand already. They take in some of these swap contracts, figure out what the real logic is in Rust, and so they can look at these transactions and if they know that this addresses a swap contract, they can calculate it much quicker. Because a lot of people say, well, the EVM doesn't need to be quicker if the data storage is, if data storage is the real bottleneck. But again, looking even further down the road, vertical trees is going to change how the storage works. It's not going to solve all the problems, but what's really going to solve the problem is state proofs. Vertical trees make these state proofs smaller. With these state proofs, the cost of querying the data from the disk goes away because in the proof you bring all the data that you need. So you can do this, you know, you could, you could valid, you could run a validator in your web browser possibly if everyone, if you wouldn't be able to generate the state proof. But you could validate the state proof and probably keep up in time if these are done properly because you wouldn't have to have the disk access. So it's features like this that, you know, it doesn't necessarily make a good now, makes it marginally better now, but we're looking further down the road. It just unlocks so much more potential. And it's just like that user experience thing. It's the little things that you don't notice that are going to have cascading effects down the road that are going to make things so much better. And that's, that's got to be the hardest thing in advocating for EOF is getting people to look from their immediate problems, which are, which are very important and very, very severe, to look further down the road and try and, you know, work multiple steps down the road. But you know, decentralized coordination is so hard that just, you know, working on the media problem is victory in and of itself. **Speaker B:** So first to be clear, like this is going to be basic for all computer scientists. But what we're talking about here, Ethereum EVM object format, is about the way that you write your code, let's say in solidity or in Vyper. And then a compiler takes your human readable code and translates it into machine code. What EOF is looking at is that compiler today, every single compiler might have their own bespoke way of translating your code and creating the machine code. And these things might come out differently or come out in different formats. What you guys are saying is because all these formats, and we'll get into this in a minute, but because all these formats are not the same, the EVM can't like make any assumptions, has to treat each one as like an individual. Like just read each line and do each line. And because of that, like we have a ton of overhead. We can't do any, like, we can't do any analysis on the objects. Like we just kind of have to take it as it is and then hope, you know. So first of all, is that a somewhat hobbled together understanding of the problem it is today? **Speaker A:** Right? Yeah, it's like going to the grocery store and what we have now is you have to take each individual item and carry it by hand. And EOF would be like, let's have a bag for cold stuff, let's have a bag for meats, let's have a bag of cans. And so it comes down there, you put it in bags and you have bags for different places. And if you don't want your raw meat touching your produce, great. We don't. That raw meat goes in the raw meat bag, produce goes in a different bag. And we can handle these things a lot quicker and a lot more efficiently and make better assumptions about all the cold stuffs in the cold bag versus if you just take each item coming down the grocery checkout lane one at a time, you have no idea what you're getting. And it could, it could be a head of lettuce followed by a raw steak. **Speaker B:** And in this analogy it's like you get the head of lettuce, okay, Then you need to Google what to do with lettuce and then you get the steak and you have to google what to do with steak and each time you get a new thing, you have to figure out what to do. That's a great analogy. It sounds like, based on what you just said to us, that there's two major things worth picking apart on the benefits of eof. The first is about the static analysis and we'll pick that apart in a second. And the second is the implications for ZK other computing environments. So on the static analysis, so, so let me repeat back to you what I heard and you tell me if this is correct, that today because of the jumpdest, this is a machine code argument, so no programmer ever writes jumpdest. This is what the compiler puts out there. No developer with asterisk. What that command essentially says to Ethereum is okay, when you reach this jump to this instruction based on like the information I'm giving you right here. And the problem with that is this information I'm giving you right here, like that may not be known before the program is actually run. Like let's say you're getting that information from Chainlink because it's the, like it's generated on a second by second basis. Or let's say that you're getting that information from a smart contract that updates once a year. Or the point is, if that information is coming from an external source, your analysis is over until it's time to actually run it. Is that correct? **Speaker A:** Right. I mean, it's like having a street map and knowing where all the turns are, but you don't know what direction you're going to turn until you get to the turn. And with static jumps you get a list of turn, left, turn right, turn left, turn right. And you can look at the map and you can draw a conclusion of where you're going to be. But if all you have is like there's five stops and you don't know which turn you're going to be at, you can't really optimize for where you're going to be. So yeah, the dynamic things is basically you get to the stop sign and you go to the person backstate which way now and they'll tell you, the back street driver at that point will tell you versus if the backstreet driver says, you know, take a left on Main street and take a right down fifth street and then take a left down state. And you know, if they tell you that ahead of time, then you can say, well okay, you're going to say capital, I know a faster way to get there. And you Just take the other way. **Speaker B:** Makes a lot of sense. And I, I know that you weren't necessarily involved, like in Day Negative one of creating the evm, but do you have any sense of why the EVM was created with the jump desk problem? And I'm just queuing off this because you said that most of the other VMs don't really have this problem. Like they either don't allow jumpdest at all or only allow you. They only allow the compiler to introduce it with really strong safeguards. What happened in Ethereum that even allows it forces us to have this problem. **Speaker A:** So the other systems had multiple additions where they could figure out ways to break it in ways that cause security attacks. And they had lots of time to think about it and years to actually come to a solution and ship a new version that's incompatible with the previous version. And they can just say, too bad, recompile your code. Don't really have that option in Ethereum. So when evm, as it was shipped on the first launch block or the Genesis block, there were certain commands we had to keep forever. And you step back from that. And the stories that I've heard is the EVM was written basically in a weekend and it got to the point where it was good enough. And there's a lot to say about this approach to solving software. When things are good enough, the right thing to do is to move on and deal with more existential threats, like, what's our proof of work algorithm? So I wasn't there, but everything that I've heard, it seems to indicate that, that they worked on, on a weekend got them to the point, the essential point that they needed to get to. And there were much bigger problems that needed to be solved that required a lot more attention. So in that sense, you know, it's like, it's like, you know, being a middle child, you know, the younger child always has more things to do and the older child's always causing more problems. And if you just fly under the, under the radar, you're not going to get the, you know, the level of concern and attention that your other siblings are going to get. And it's just because, you know, of unfortunate circumstances, there's, you know, I don't think, you know, so, so the jump desk, I think someone had brought out a concern that you could jump to any point of the code and it would cause problems. And that was one way to make sure that things were fine. And I think the big issue, one of the big issues beyond jumpdest, more than Just jumpdest is there's a secondary problem that you can't jump into push data. So when, when you write the code you say push one, push two, push three and what you're saying is the next one, two, three or 32 bytes in the code is data and is not code. So what the jump test analysis is really doing is making sure that the jump tests are not existing inside of that code. So in that, in that push data, so you can't jump into stuff that's never intended to be executable data. So I think jumpdest and jumpnest analysis are there to solve those problems of getting the minimum viable product on code validation that they needed. And when they moved on, it got them where they needed to go. And dealing with the problems they're having with EVM Object format and ZK snarks. They're in a category of problem I call problems related to success. If Ethereum wasn't successful, this never would have been a problem. And they could have just started over, launched a new chain, done it, quote unquote the right way. I mean, what, you know, Libra and Diem and now Aptos and SUI have with it with Movie and they're really building off of that prior experience and they had the privilege of having the time and the people with, you know, who obsess over VMs and knowing the impact and seeing what it was to get it right on the first try, because it's not their first try. It's like, you know, the third or fourth revision when you look at all the other systems. So, you know, I think it's just, you know, the reason why we're in this situation is because it was the most simple thing that could possibly work and it worked great. And now that it worked great, you know, we gotta work our way out of it. **Speaker B:** Yeah, well, I thought that's a great way to segue into the second point you made, which is eof, like really changes the game and makes things like ZK more viable. And I think. So quick anecdote back in, I want to say November of 2022. So a year and a half ago, a little less, I was up in Seattle and I met with Sriram Kannan of Eigenlayer. One of the comments he made to me, which has stuck with me ever since, was he's like Rex, you know, once we are actually looking at verifying ZK snarks like those are so computationally expensive that like, if you're looking at a full gas block of 30 million gas right. So that's as much computation as you can possibly do in one unit of time. His estimate was like, we're only going to be able to verify like 12 to 15 snarks per block. And I've asked this question on the show a few times to different people I've been thinking about this whole time. Because if that's true, then as much as like the modular blockchain thesis and, and all of this ZK technology is like going to scale Ethereum. Like, it's not going to, it's going to scale up by one order of magnitude. But, but what I finally found the answer I'm looking for, and it sounds like you're working hard on it, is like, by changing the, by creating EOF and making some like, small but like really important and really compounding changes to the evm, we're able to make much more space within the EVM for more ZK and to make the EVM itself more hospitable to zk. And so if a year and a half ago it was 12 to 15 snarks, without even being more clever about the ZK or any of those kinds of solutions, what you're saying is that with EOF we'll be able to get like, much, much more, let's say, verifications per block than we are able to do today. **Speaker A:** And even beyond that, I mean, there's more than just Ethereum mainnet. And so you have Ethereum mainnet and the goal is to like, you know, one day snarkify Ethereum mainnet and try to solve the execution layer. But you have like all these layer twos and these Alt L1s. And so with EOF, you could even change some of the rules of your layer two. For example, you could say only these five contracts are allowed. You know, you got Uniswap, you got the, you got the pool contract, and maybe you got a few other contracts. So if you set up a system where only those contracts are allowed, then you can take the EVM evm, the EOF version of the evm, and if you wanted to, you could, you know, interpret it and come to the correct answer. But, you know, instead you could just, you know, make ZK snarks of each one of those fives, chain those together, and then you have two steps of the snark, you know, do all 200 transactions in parallel. They don't depend on each other, which makes the proof smaller. Chain those together and then you have another ZK snark that recursively groups those together. And you prove that each transaction was done properly and you prove that each transaction was grouped together. And so you could have a chain that could get these outlandish numbers for defi if they want it, because you're limiting it to defi and those. You know, I think that's, I think where some of the future of ZK is going is you just need to be smart about what you're snarking and to have the wide open sandbox with anything possible under the sun permitted by the evm. You know, that's, that's where some of the hardest problems in Zkite is and where some of the most expensive computations and proving that what you did is correct exists. And you put limitations on it and you can go to the Moon, that makes it exponentially easier. If you could say there's only five contracts. **Speaker B:** And actually we've seen this, the market has shown us this, which. The ones that are off the top of my head are zksync and starkware, where the first things we saw were them developing this incredible Moon math technology and then deploying it to like really, really tight, purpose driven applications like DYDX or Zigzag or whatever. And that's exactly what you're talking about. But what you're talking about is being able to inject it directly into the EVM and then make it Ethereum native. **Speaker A:** Right? And probably the quickest path to victory is to take EOF code, cross compile it into Cairo and then just let the rest of the tool chain do its thing. **Speaker B:** Very cool, man. So I think we can go all day on EVM and object format and just like the insights that you gave us already are so good. But with our last few minutes here, I really want to take a moment to talk a little bit about Hedera and what you're doing there. And we can talk about hashgraph. I think that it is so interesting, but also maybe a little too visual to do in a podcast format. So whatever is needed to talk about what Hedera is, I'd love to hear from you, but I think the big question in is like, what is really cool about your story and what you're doing is that you are ultimately always contributing back to like the beating heart of Ethereum, the evm. But you've been doing it by like working for like, for example, consensus and working directly on a client to working on Hedera, which is its own independent chain. And, and so I guess, like, I would love just to hear some insight on like what you Think the value of alternate, let's say side chains, L1s like things that are not directly tied to Ethereum and how much your kind of work can contribute back to mainnet. **Speaker A:** I think, you know, when you look at my contributions to Hedera, Hedera itself, I think what makes Itera unique is the hashgraph algorithm. The algorithm is something that they call asynchronous bft and what's cool about it, I don't, you know, I'm not, I'm not the, I didn't invent it, I don't know that much of the, I don't work much on a consensus layer. Consensus really isn't my thing. But you can take your nodes that are running this consensus and they do their hash graph, they see that a transaction is given, they share it with all their friends. And what's unique about it is they use acyclic directed graphs to come to a conclusion of when a particular transaction was entered into the system and they come to a consensus agreement about what time it happened. And that ordering is completely and totally separate from the, from the subsequent execution of the transaction. So that's one thing, they've got a full separation of execution and ordering. They do ordering first and then they do the execution. But another very unique thing about it is it's leaderless. It's not really block driven because you do it and the order stuff comes in and the stuff you do orders with, I mean they put a structure. Well, I'll come back to that when I talk about the Ethereum bit. So stuff comes in and you can independently come to the conclusion. Assuming everyone else in the network was voting on us, this would be the state of the network and you don't need a leader to tell you that. So it's a leaderless algorithm. So everyone is basically producing transactions full speed, full time. There's, you know, no waiting for block election, no waiting for attestations to come back when you, you know, as you gossip around your transaction sets that basically serves as validation of all the other transaction sets. And that's what's really unique about hashgraph is it's, there's, it's really difficult to play the MEV games that you can with a block based system, with a memory pool based system. There's not really a memory pool per se, there are some corner cases but there's such a narrow time frame for malicious nodes to do malicious things. I think it's got some state of the art stuff. But Hedera, when they first started building this they didn't. You know, when they first put their algorithm together, it wasn't as obvious that the EVM was going to be the market winner. So they made a lot of their own independent decisions based on their own independent experience about how they're going to build their token system. So they have a set of services built on top of the hashgraph that is completely separate from the consensus algorithm. And there is hts, a token service, hcs, basically a timestamping provenance service, and then the smart contract system. So what brought me into Hedera is they were looking at their smart contract system and they saw that it was based on old constant, ample code. This was back during Berlin, it was like three years old. It was based off of a project that had since been Sunset. Ethereum J was their code base and they realized that they either needed to sunset the smart contract system or come up to speed and be current with evm. So I came on board and one of the things I did is I took the BASU evm, I made a library out of it. I pulled the pieces out so that there's an independent EVM library that fell out of the BESU code and it's part of the BESU client, but you could take the independent EVM code. And there's another project that just came Into Hyperledger called Web3J is developer tooling for smart contracts in Java. And that's what they do, they take the library. So there's like three different users of it. And so Hedera is another user of it. And so they've taken the library and they've layered it on top of their current system. And one of the problems with a system like that, and I've outlined it in some of the talks that I've given, and like DevConnect and previous dev cons, is there's just an impedance mismatch. They just do things slightly different and getting those things to fit together is where a lot of the work in Ethereum equivalence is. And I think we finally, as a team gotten to the point where we can say from a tool perspective, Hedera is Ethereum equivalent. So even though things are put into this ordered sequence, we split it up into blocks. We make something for block hash that would support that so that all the external tooling like Hardhat and Foundry can go in there and it looks like an Ethereum system. It's got JSON, rpc, Hedera, when they first built it, they used grpc, which in a void, not knowing what's going to win the market is a very sensible choice, but the market sense moved. So they need to move where the ball is at. And so they have a JSON RPC relay that you can use your Metamask wallet in. Hedera also has an ecosystem of wallets that do talk native happy. You can do more exciting Hedera specific things with it, like stake your Hedera on a hat on a Hedera specific wallet. But you know, when it comes to people who just want to run Uniswap or run their smart contract, they've written in solidity and get support on another chain, you really need to have support of what are essentially industry standard interfaces of submitting assigned Ethereum transaction. JSON RPC to submit it, JSON RPC to query it. These standard things are the things that I've spent the past two and a half years along with several other people on the smart contracts team. I think it's about like five of us right now. Six, if you include our manager. I mean, you should. The manager's part of the team, he's just not the one writing the code all the time. So you got to give them credit. But we've been building this along with the rest of Hedera to actually get to the point where it looks on the surface just like any other EVM chain. It's not perfect. There's always going to be impedance mismatches. That's just the nature of it. It's most of the way there. Unless you're doing some really esoteric like, you know, if you're, if you're really depending upon. Gosh, there's like some weird, strange corner case that, that, you know, you might be able to tell the difference that I'm on Hedera and not on Ethereum. And it's like unless your code really depends on that, you'll be fine. And most code doesn't. I mean, unless you're, unless you're writing, unless you're, you know, unless you're writing some real serious layer, some serious Dex MEV stuff that you need to figure out. You know, is this block, the current block that I'm in, the one that I proposed, then you don't really need it. I mean, there's like the very edge corner cases of where it would matter of the differences that are there and you know, we get rid of those concerns. MEV is not a thing on Hedera. Everything shows up in the order you get it. That's kind of a unique thing and it's yeah, it's, it's pretty interesting. So that's when it comes to ALTEL ones, I think that the value of ALTEL ones have. Even if, if the EVM dominates and you know, you got MOVE vm, you got fuel vm, you got a bunch of other things coming in. Solana vm, Solana vm. We're starting to see the growth of a modular system, which I think is great. So you can have your own vm, you can have your own data availability, you can have your own consensus and you can mix and match these. And I think that's, that's where Hedera can provide, you know, some unique value. It's got a different consensus mechanism that is fairly unique in industry. **Speaker B:** Yeah. And listen, like, I don't want to like talk anything negative to ALT ecosystems. I think, like there's so much, there's our industry so tiny and there's so much growth to happen. Like, I encourage everyone to do whatever you need to do in order to be building. That's the only thing that matters is be building. I guess, like my question to you though, as someone who uh. Or coming from someone who, like, even though I don't like the label, I'll just say it like I'm an Ethereum maxi. My question to you is which, like, what are the lessons and insights that you're gaining by helping Hedera achieve EVM equivalence that like you think are really interesting and worth bringing back to Ethereum to make like the EVM stronger than it was before? You like really looked at it from this new perspective. **Speaker A:** So I don't know if it's something that can necessarily be brought back to the evm. I think that probably the one thing, another thing that's important about Hedera is it has strong corporate backing. All the nodes are operated by very large corporations. They have a council that operates the nodes. I think there's 30 node operators and they make a point in the council to say that this can't be your only line of work. So when you're operating a node that provides an extra layer of assurance that you're not going to do anything untoward because that would threaten your livelihood and the thing that's secondary to what your node operation is. So that's one of the unique things. So one of the things I think Alt can provide that mainnet may not ever be able to provide is a certain level of regulatory comfort. So if you want to run, if you want to tokenize something 3 or assets and some regulatory agency says, well, we need to be able to identify and take to court anyone that's running software validating your system. There's no way you could do that in Ethereum, because that's the point. You don't know who's running. **Speaker B:** No point. **Speaker A:** Yeah, but in something like Hedera, where you can identify by name who the node operators are and you can figure out who their legal counsel is, that provides a layer that, that some people are just going to need in the future. And I think, you know, maybe not with Ethereum itself, but you know, there might be layer twos where that is a core corporate value. Is that, yes, we're a registered company in some jurisdiction and if we do something untoward, your insurance company can come and sue us. You know, if we validate something wrong and don't follow the protocol correctly, you could take us to court and get the assets. Whether or not that is actually valuable to some people, the possibility that they could do that is really what they need. So I don't think we'll ever see any of these lawsuits that you upgraded the blockchain wrong. But to be able to think that you could go there and have legal standing against some entity is something that I think a lot of bean counters are going to say, that's what we need, we need the option to do it, not that we're actually ever going to do it. **Speaker B:** Yeah, yeah. And I think you're spot on. And this is the world that um, like the world that has the world computer pumping at the center, like will look like that. Right. And I can totally imagine a world where like we have let's say $5 trillion of real world assets on chain and like 4.5 trillion of those assets are in JP Morgan, Morgan, Onyx, new Wells Fargo chain, like new Citibank chain. And like we, you know, these will all start as like private L1s, just like JP Morgan, Onyx is. And then eventually all of these companies will realize like, okay, either this should be an L2 and settle onto Ethereum, or there's no reason to mess around with all this consensus stuff like we all trust each other, we all know each other, like, might as well just sue each other if something goes wrong. And so like I, I fully believe that like the end game state of Ethereum is that turns out all the assets do live in places tied to specific people where we can sue them if something goes wrong. But like, what Ethereum provides very simply is the rage quit option and the ability to take your assets back into custody, flee your country, move to a new place, invest in something your government says you're not allowed to invest in. Like, whatever you want to do in this world that is becoming more and more globalized, like, Ethereum will provide that option. But let's be real, man. Like, how often have you done any of that stuff, right? **Speaker A:** You're not going to. You just having the option is nice. It makes you feel more secure to know that you could escape. **Speaker B:** Very cool, man. Well, I could go for like, literally another two hours. Like, I. There's a whole category of questions on Hedera that I'd love to ask about, but for, for the sake of our audience's schedules and ears and just ability to pay attention, I'll cut us off here. So, Dano, before I let you go, can you just share first, like, how can people find you, follow you, learn more about what you're working on. And then second, if they are interested in EOF or EVM and like, really want to be part of the team that's pushing Ethereum towards the endgame state, like, how can they get involved? **Speaker A:** So I have a fairly unique username. It's not widely used by many other people. It's Shemnon. S H E M N O N so I have that on Twitter. I have that. Well, X Twitter X I have that on GitHub, I have that on Telegram. I. I don't have it on Discord. I have to be like, underscore Shemnon. But, you know, those are the places you can get a hold of me. My DMs are open. Don't just say hi, ask what you're asking for when you connect to me. I. I get too many high DMS on X right now for me to just even deal with it. But yeah, you can reach out to me, get a hold of me on those places. If you want to get involved in EOF right now, it's still in a very technical phase, but there's calls. There's every Wednesday at like 10 or 11 UTC or maybe noon UTC. I'll have to look up the calendar, but there's a standard. If you look at the Ethereum call calendar, there's an EF call that happens every other week on Wednesday. You can also, if you want to pitch in, there's like, on the Ethereum research Discord, there's an EVM channel. You can get a hold of people there. But I think the thing about EOF is if we do it properly, the way that you participate and use EOF once it ships is you just use an up to date version of Solidity and it'll just spit it out, it'll be that transparent. That's the goal we have is that most users will just say, oh, it's faster on the inside and they won't know the details and it'll have zero impact onto them. And if we can reach that level, we've done it. Right. But if you're technical and want to get into the details and ask about what DAC validation algorithm we're doing, we're all ears. That's going to be in the Ethereum discord. Or if you just want to follow what's going on with it, there's the Alcor dev recaps that Tim and I think Christina Kim passed around on Twitter a lot from Galaxy Research. I probably got her name wrong, but I follow it a lot. But yeah, there's a lot of places. Hit me up if you have any questions and I'll do my best to answer them. **Speaker B:** Yeah man, much appreciated. And I hear you that we're in a technical phase of a technical implementation and so it's tough, right? But at least for me, who's non technical, like every single day I just find myself like reflecting and just being grateful that we're able to watch like a generational technology that really will change how humans interact and live in this world. We have an opportunity to literally watch it happen on a call by call or a code by code basis. And even if you can't contribute and the way that you're thinking, you know, like this is also a contribution. Right. It's like getting people excited about it, like learning why any of this matters and like hopefully for someone like me is eventually like building a company and an empire using the tools that you're building for all of us. But I, I just, I encourage anyone in this, listening to this that's interested and is not a hardcore developer to still get involved and still like just understand that like this is a special moment in human history and you get to be a part of the world computer coming online and cherish that. **Speaker A:** Yep, pretty, pretty neat time. **Speaker B:** Great. So Dano, thank you so much. I really appreciate the time and be well man. **Speaker A:** Sounds good. It.