 I thought, you know, other chains have gone on before Ethereum and they've done different things in Ethereum, and we've adapted things. And so as Ethereum is moving forward, we should look and see what's worked with them and what hasn't worked with them. So the thought I had is some of these chains are trailblazers and some of them are shipwrecks as warnings to don't go there. So I thought I'd ask Dolly to the AI generation program to create an image of me of a covered wagon on a seaside looking out over a shipwreck. And when I got instead with something more awesome, I got this. Over here you see a broken down wagon that's broken. This is the real wreck. And this isn't a ship. This is a wagon that's converted its cover into a sail. So this isn't the east coast if you're heading west. This is the west coast. They made it to their destination. But this wagon is learning from other systems. It is adapting. It is getting ready to set sail and head even further west. So how do we do this presentation? Most of these slides are going to be in two columns. On the left is going to be what other chains do in some of the details that are relevant. And on the right is what Ethereum could learn from it. Sometimes we learn good things. Sometimes we learn things not to do. And sometimes that's just a neat thing to know, but it really won't work for Ethereum. And I kind of live in both worlds on this. The reason I came up with the idea for this talk was I work at Hedera Hashgraph. I was one of the maintainers of Hyperledger Basu. And they wanted to improve their Ethereum compatibility game. So the idea was, well, Hedera is Java-based. Basu is Java-based. Let's just componentize out their EVM and bring it into Hedera and bring that software over and suddenly boom, 100% EVM compatible. It's not that simple. There's a lot more to it than just reading bytecode and executing programs. So I'm going to talk about three separate areas. The first area is going to be accounts of cryptography. Then I'm going to spend a little bit of time on the EVM itself. And then I'm going to talk about transactions and transacting with Ethereum, which is kind of an important thing. If you can't put your transaction on a chain, the chain may as well not exist. So the first thing to talk about on the accounts is the cryptography. Accounts in Ethereum are intrinsically tied to your public key. And a lot of other operations are intrinsically tied to hashing operations. Nearly every different chain out there has a different setup for the encryption that it uses. Ethereum uses ECDSA on the SCP-256K1. Hedera uses Edwards, as does Nir. Polkadot uses a combination of Schnorr and Curve 25519, which is pretty unique and insensible. And the consensus layer uses BLS-12381. And there's a lot of variation in there. And then you look at the hashing algorithms. There's an older draft of SHA-3 called Kachak that Ethereum uses. Then there's actual SHA-3, which Hedera uses. But they use warm bits. Nir uses SHA-256, as does the consensus layer. And Polkadot uses BLAKE-2. So one of the things looking at this is you might think we can just pick one and go with it. The problem is cryptography needs change over time. Attacks against cryptography don't get worse, they only get better. New ideas get found. One of the big things on the horizon is quantum resistance. If we want Ethereum to last 10, 20, 50 years, at some point, we're gonna have to change some of these algorithms. And at some point, we're gonna have to do significant changes. So we should continue to build with this in mind that we're gonna want to change it. I mean, as it is right now, we may want to change it to use, wrong button, this is the laser. We may want to use BLS-12381 for some of our accounts. It's not just useful on Ethereum on the consensus layer for aggregating signatures, but it's useful on layer twos for aggregating all of their transactions into one signed transaction. Now that comes along with some problems. BLS and Edwards require you to bring the public key along with you. And I think that's covered by the next slide. So the BLS and Edwards require you to bring your public key. ECDSA doesn't. So we need to put more space in some of these transactions and normalize the practice of sending your public key or your Ethereum. And you can't send your Ethereum address, you actually need the public key for the cryptography. So for some of these signatures, we would need to socialize that. So the next interesting issue comes along with the account addresses. Hedera uses a sequential system, counting up from a thousand. Hedera is interested in an alias system in some of its accounts to support some of the needs of Ethereum mainnet. Create two, you have to use the Ethereum equivalent address. Or things like Uniswap just won't work. We're also considering multiple accounts per model. But some of the interesting things here is that by disconnecting the public key from the address, you can do things such as key rotation, which is critical to some enterprise applications. But right now, your key is tied to your address. So account abstraction is a way to solve this, I think will be a great way. But another problem with compatibility is if we're going to use a different key address, do we do address translations with Ethereum? Do we have definitions for these? We'll probably need some sort of a definition for how you would take a BLS12 signature into an Ethereum address. If we're going to adapt that for various uses. And the biggest problem is in ethers.js and some of the other tooling. When you create a contract from an account, they don't check the return value. They assume that you're following proper yellow paper definitions, which for an Ethereum tool makes sense. But with the possibility on the horizon that some of these signature algorithms might be changing, that's not an assumption that is safe anymore for these tools to make. They should believe what the RPC tells them, is the new address when it comes back to them. Another problem is authorization. ECRecover is used by a lot of contracts to authorize messages, like 0x to authorize the trades. Some other dows use it to validate votes and everything like that. But this again ties the account to the key. It also includes key rotation. Hedera uses credentialed accounts, which doesn't work well to ECRecover. We have to map in an address to that. Near uses usernames that you have to register ahead of time. Quite different. And so we need to have a different approach to this. We probably need some sort of an account authorized precompile to be brought into Ethereum when we do account abstraction. So you can ask a question of here's an address, here's the signature, and here's what they signed. Is it authorized? And then just returning username. So I think that would help us continue to keep ECRecover as a primitive and move the questions about, am I authorized into a precompile that has deep integration with the system? And finally, account abstraction. One thing we should learn from Hedera on this is Hedera accounts that used to have to create them before you could send crypto to them, which presented lots of problems for exchanges creating new accounts for customers, or for somebody saying, hey, send it to this public key. You'd have to have the account created before anybody could send you your NFTs, or your crypto, or anything. So Hedera introduced a system where you could have an ALSP account and we would create the account that covers for you late the moment we need it. And the lesson here is from the account abstraction. This was a bad experience, which is why we had to add the aliases. If we're gonna have account abstractions, we need to have a mechanism that you can convert an existing end user account to an account abstraction account so people can still send you stuff ahead of time before you create your contract. Hedera's got a unique process called hollow accounts that we're implementing here shortly where you can just set it with partial information and then fill it out later. And that's kind of what would need to happen in account abstraction. Some drafts have this feature, some drafts don't have that feature of account abstraction. So whatever approach we take, I would really want to be able to convert an end user account into an existing externally owned account into an account abstraction account rather than requiring them always to start from a contract deploy. So that covers it mostly for accounts. The next area is the Ethereum virtual machine. Even though you're bringing the same library, there's always rough edges and corners that you need to deal with. One is issue of ergonomics. And precompile contracts is the way that most change saw this issue. What if you need to do stuff that you can't do inside the EVM? What if you need to queue up a layer two withdrawal? What if you need to interact with your native token system? What if you need to change your account information from a smart contract? Lots of smart contracts, lots of different blockchains have different addresses for a lot of their precompiles. An interesting one down here is Cello. This is actually the precompile that was the BLS signatures that was in Berlin before it was removed before we shifted to test nets. They just, the difference is there, they put it at a different address. Which I think underscores what my main ask here is that we probably need to organize a registry of precompiled contracts that all chains and layer twos use. For one, to make sure there's no collisions. And for two, to give proper documentation and utility for smart contract writers. So they know how to call these contracts within it in kind of a centralized place. But I also want to pitch a language change for these contracts. There should be a difference between a precompiled contract which is a contract that you could do everything within the EVM. Most crypto primitives would cover onto this. You just can't do it efficiently. You can't do it speed-wise. It costs too much. So you precompile it into a library and you do it cheaper and faster. The other type of contract would be a system contract where you're breaking the layers of the Ethereum virtual machine and going and doing things into different parts of the system that you can't do in the EVM. So most of these contracts up here I would call system contracts. And only the BLS signatures I would really call a precompiled contract on this list. A little bit here. We had to do something different instead of RANDA. We used a different hash. And Hedera has a very complex fee system. It works. You just libraryize it. It gets lots of tests. And the takeaway from that is that multi-dimensional 1559, much simpler than what Hedera has. And what Hedera does isn't too scary if you know what's going into it. But some end users, it's not quite as simple as here's one price and here's one meter. Numbers go up as you do more. So I think the multi-dimensional 1559 would be a good value. And I don't think we're gonna be charging too much for a lot of our gas features, but if we do, we should consider letting some operations be charged with Ether rather than charging gas because if you're just gonna take up a whole lot of memory space that you're not doing a lot of compute from, there's no reason to keep the whole blockchain shut down, just do one large operation that takes no compute. Not too big of an issue. Off and off call. I don't know that anybody that does this. So this isn't a fair take, but it would be evidence we shouldn't do it. I'll come back to this later, don't worry. The next thing though, I'd like to use this as a little example. I'm gonna tell a little parable about this. And a lot of things that you're interacting with in smart contracts and in blockchain, sometimes you don't know if it's really going on in a way, if it's going on under the system inside of it. So here's a little scene from West World Season One where Billy is going in and says, like, are you real? And the very pithy comment that comes out that kind of shapes the rest of the series as well if you can't tell, does it matter? The substance that you're interacting with doesn't matter nearly as much as the surface you're interacting on. So this is something that we did in Hedera. Hedera has a very rich token system that has zero connection to the smart contract system. This is how they get their 10,000 TPS number on token trades is they just completely bypass the EVM. But there's a lot of use cases where you may want to interact with your smart contracts to interact with your native Hedera tokens. So what we did at Hedera is we took the addresses of the tokens and we made a little jumper contract. You call into it and it'll immediately jump you into the HTS system contract and do whatever you would need to do. And from this, we could make our HTS tokens look like you had deployed an open Zeppelin ERC20 or ERC721 contract. And it worked great. We plugged in some Uniswap derivatives. We plugged in 0x protocol. In some of our metamask testing, it just magically worked and none of this was running EVM code. So the takeaway from this is it's only the effects of what happens in a lot of these systems that matters. Clients can do things if they really wanted to. They could pre-compile the open Zeppelin contracts if speed is the issue. And this has very, and this is honestly what ZK EVM proving is using in the system. And it's the side effects that matter and I don't understand the math, but the math checks out. And so you can take that same approach to the EVM. I don't understand the EVM, but the side effects check out. So you can pull this in later in all sorts of other systems. Finally, transactions and transacting. This is probably the last hurdle that we had to overcome to really up our game at Hedera for Ethereum compatibility. We had to adapt the Ethereum transactions into Hedera transactions. I'll go through this in some of the slides. But first I wanna talk about, before I get too deep into the transactions, a little bit about Hedera's consensus mechanism that really drives a lot of its features. Hedera uses a consensus mechanism that fully separates ordering from execution. And the way they do this is because of the nature of the asynchronous BFT hashgraph algorithm. The algorithm works by all the nodes gossiping together about what transactions they've seen and they include a link to another transaction, to another node's previous hash in gossip. Eventually, you can get to the point where you know what all the other nodes have seen and what they've signed and attested to and you can come to a conclusion about when transactions reached the majority of the other nodes. And you can take an average of when it came and that's your timestamp and that's your absolute total ordering. So we can order these transactions without even seeing what's on the inside of them. Now one of the great things about this is there is no leader that comes out of this process. So when people say Hedera's not a blockchain, it's probably better to say that there's no block producers in Hedera. We don't go into a memory pool and pick and choose our favorite transactions and put them in there. You get the order that you get. And this allows us to, and this is kind of the trick behind how we get our amazingly high TPS numbers is we're running the EVM full time. The base of EVM is not the fastest, that would be EVM one, but what we're running is if we run it all the time, we can overcome a lot of those barriers and we can get that transaction and that's even 15 megagas per second is even us holding back and having some safety features in there in case we get overloaded in other parts of the system. Now the problem is this really doesn't apply to Ethereum. Blockchains never change their consensus algorithm. Well, almost never. And theory of mainnet just changed there is over to proof of stake. And a lot of things about the culture are falling out from this. MEV is accepted and endorsed. There's talk of enshrining, proposal builder separation into the protocol. So some of these base level decisions come up and they affect the nature of the ecosystem. So there's not much to be considered about this as it kind of needs to look at, but it's not something that Ethereum is going to be able to change. The next thing I ran into was an issue with transaction nonces. Hedera doesn't use transaction nonces. They use timestamps and you can do neat little tricks with your valid start time and valid duration down to the nanoseconds to ensure your uniqueness for your transactions. But this is a problem that Ethereum very strictly uses their nonces and they really use their nonces as sequence numbers. I really wish that when they started this back instead of calling it a nonce, we call it a sequence number. But unfortunately that ship has sailed. And nearly every blockchain out there, when you see nodes in a transaction, you know it's sequence number. Except for one, I really had to dig deep in my memory for this one. This is a blockchain out of China that's very Ethereum like, but it doesn't do the transaction sequence numbers in the nonces. It actually treats them as a true nonce. Great for performance and throughput, horrible for memory. So not everyone does this, but we had to adapt the nonces. The next issue was metatransactions. We took a process where we wrapped the transactions of the Ethereum RLP inside of a Hedera transaction and we signed the Hedera transaction with one account and the inner account was responsible for it. This is, you know, plastic protocol level metatransactions. There's not too much fancy stuff going on with it. And it just transparently works. The relay can agree to pay for none of the gas, some of the gas or all of the gas. And the transaction on the inside is responsible for the rest of it once we map that transaction to a user. And if the relayer sends garbage into the Hedera, we throw it away and we just charge the relayer for the garbage that they brought into the system. And it works really well. And it bounces great, then spins like a top. So if we need to get metatransactions into Ethereum mainnet, the way to do it would be through in trending in the protocol would be the best way. What we have right now with the cooperative impersonation going on is a good enough way for people that wanna participate. But account abstraction also has the potential to solve this problem of allowing people to pay in one account and act in another. And I promised I'd come back to this, off and off call. So it's not just that other people don't do it, it's that other people solve the problems directly in the protocol. So I think that the people don't use off and off call. Is there solution? I think is stronger evidence. And I think unbalance is gonna come by even if you take these evidences out that it's not worth the risk. Maybe we should examine payer executor splits to solve some of these off and off call problems. And finally there's JSON RPC. This is truly the last mile of Ethereum compatibility. If you don't speak JSON RPC, all the masses of retail tools and developer tools will not talk to your blockchain. So we had to write up a relay server that would stand up in the middle, take those RPC calls, send it out to consensus layer, send it to our mirror node. And this looks a lot like the portal network. So the portal network's idea of having a proxy that's gonna go through and talk to systems that aren't necessarily live, but have very viable information, it's gonna work great. It works great for us. So this is something that I have a lot of hope for. I've been following Piper's work for quite a while. I think it's great. I think that covers most, oh yeah, one last ask. This is my last point. Can we get an RPC system that doesn't put everything in the post body? Can we please get a rest like JSON RPC? This has huge impacts on load balancers, huge impacts on caching, and all sorts of other items. We have to put this into the application. We can't put good front ends on it and split the balance easier. It's just as simple as putting the method name in the URL would have huge impact. And so that's one of the issues because Hedera uses GRPC and it's got amazing load balancing implications. But we can't quite do the same tricks that we do with JSON RPC. So in the 25 minutes that I had to talk, or the 20 minutes that I was allocated, those are my conclusions of what we could really learn from Ethereum, from other networks and what Ethereum could apply. I think account abstraction has great future potential to solve a lot of these problems. The EVM, if a chain wants to really run the EVM, they will do the changes they need to. There's not too much changes the EVM needs to do. It's the user tooling that might need a change to deal with potential changes in cryptography that comes ahead. Not every chain's gonna be Ethereum mainnet. There's gonna be other chains that do cool things that are compatible with Ethereum mainnet. That's fine, let them do their cool things. Let Ethereum be Ethereum. And if you have any questions or comments, my DMs are open. Just don't offer me a pump and dump, I'll delete you.