 I'd like to welcome everyone who showed up today. Um, guess the coffee chat is still going on. It's hard to get things started once everyone starts chatting again. But this is being broadcast and it's going to be recorded, so it's going to be here when people are ready for it. Um, today I'm talking about integrating, um, Beisu, the Beisu EVM and Ethereum transactions into the Hedera public network. Um, but first, my name is Dan O'Farran. I'm a Principal Software Engineer at Swirld's Labs. Um, and that's a company that works for- for the Hedera network. It's- I'll- a couple more slides, I'll talk about it. Um, I'm one of the main tainers for the Hyperledger Beisu Project, and I've been with Hyperledger Beisu since it was onboarded into, um, into the, uh, into the Hyperledger ecosystem. It started out as a project at consensus called Pantheon, and then we brought it into Hyperledger, and I've been there ever since on the Hyperledger- on the Hyperledger side. Um, I'm also a member of the Technical Steering Committee. I've served two terms. Um, this term, I've also been serving as the vice chair, um, underneath Tracy Currick. She's been doing a great job, so I just have to fill in for the occasional meeting. It's- it's, uh, she's doing a great job in being the leader of the Technical Steering Committee. But first, we should talk a little bit about what is Hedera. Um, Hedera is a permissioned public ledger. It's a proof-of-stake public ledger, um, where the participants that are producing the- producing the ledger, um, you know, they have their stake in it. But it's not a blockchain. I almost want to say, you know, it is blockchain but it's not a blockchain. But one of the unique things is it uses the- the hashgraph consensus algorithm. And what makes it different from most, uh, traditional blockchains is in this consensus algorithm, there is no block-proposer. All of the different nodes that are in consensus, they contribute their transactions continually through, uh, complex acyclic-directed graph process where you take your history and someone else's history, and then you can read through all that data. And with enough, um, spreading of the- of the various nodes, you can come to a very complete conclusion about when transactions came and which order. So they go through this at high speed, they perfectly order everything, then we just evaluate the EVM transactions through hashgraph. And there's no leader, there's no memory pool, there's no- no weird stuff like that going on with sandwich trading. On top of that are built, um, the number of services on top of this hashgraph algorithm to provide the ledger type services that people are looking for in- in a- in a distributed ledger. The first one is a native token service. And this, we can trade fungible and non-fungible tokens through the API represented natively in the- in the ledger. Um, you don't have to go through a smart contract system. These are actual tokens built into Hedera. Um, the next, uh, service is the consensus service. And that's kind of a message queue that takes advantage of the hashgraph, uh, perfect ordering of- of, uh, uh, the fair ordering of the transactions as they come in. And basically you can post your messages and you can see which order they are presented in. And, um, as I mentioned in a previous session, um, we have a plugin called Plugable HCS in Hyperledger Labs, where you can use that, uh, that consensus service to serve as an order for, uh, the, uh, fabric network. And finally there is the smart contract service, which is mostly what I'm going to talk about today. It's an EVM compatible smart contract service that we brought up to modern Ethereum mainnet compatibility standards. Now who runs Hedera? These- these stakers I mentioned, it's 26 members- it's a 26 member governing council. I was wrong before and I said it's 23. It's up to 26. It could conceivably hold up to 29. But there's some pretty, uh, big names in there you might recognize, Google, IBM, um, some- some specialized names, um, as- as well. We got, uh, Deutsche Telecom. S- and the way that they manage this network, the technical aspects of it, you know, they meet in their meetings, they vote on fees and a lot of other stuff. But as far as the technical improvements, these come through Hedera improvement proposals, hips.Hedera.com has all those Hedera improvement proposals. I've written a number of these to- to cover some of the stuff that I'm talking about today in this talk, as far as the, uh, HTS integration. And Swirl's Lab is the company I work for. They are contracted by Hedera. It's a separate company from Swirl's Lab to do the technical implementation of these Hips in the Hedera Network and other technical aspects of creating a software to run the Hedera network. And the network itself was run by Hedera in these 26 governing councils. So- so we write the software and they run it. So as far as, um, integrating the EVM into- into Hedera, there's three main aspects I'm gonna talk about today. The first is the BASU EVM itself. We took the EVM from BASU, the one that's mainnet compatible, and one of the- the one of the growing major alternative clients to get in Ethereum mainnet. We took that EVM and we used the exact same code in Hedera. It's kind of a process to get there. The next thing we did is we took the native Hedera token service and through a series of system contracts, which you might be more familiar with, calling them pre-compiled contracts, we exposed the tokens through it so you can treat them just like regular old, um, Ethereum tokens. And finally, there's another project we wrote called Hashio, which is a JSON RPC bridge. Hedera uses GRPC for its communications. However, most of the Ethereum world uses JSON RPC to talk to its nodes, and a lot of the dApps depend on some- some mantics in that. And that is an important last mile that we needed to fill in to- to make things work so you could use things like MetaMask and Hardhat when building your Ethereum applications on Hedera. So first, let's talk about the base of EVM. Now, Hedera, when it launched a smart contract service, it has- it had an EVM compatible implementation. And at the time they used the EthereumJ implementation, they were about, you know, consensus is, uh, Pantheon hadn't quite been released yet, so there wasn't much public code. So the EthereumJ, it was good enough. It was compatible up until about the Constantinople hard fork, but there were another- other issues that needed to be improved to get it working. So the decision was made to bring in the base of EVM, and that's when I came on board to Hedera. So to bring in the base of EVM, first we needed to do some groundwork inside base of itself. And I call this separating the monolith. There's about four major tasks that we needed to do, or three major tasks. But the reason that these hadn't been split out is because base of was a Swiss Army knife binary and did everything at once. And there was only one real use case for it, and that was to run either private networks or public networks. Using the different components outside the context of this, Swiss Army knife had not been contemplated before. So we had to turn it into a stack of Legos. And when you're building a modular system, you need to have a real use case to ensure that the module boundaries make sense and are usable. So this is kind of the first time when we had something that had an external use case from the Swiss Army knife of Hyperledger Basu. And for context, I'm a maintainer at Basu, and I've been with Hyperledger Basu since it was brought into Hedera, brought into Hyperledger. I was part of one of the original maintainers brought in with the project. So that's why I know a lot about why we built these things the way they did. So we took some of this tight coupling out. There's also some dependency on other code where when you have the assumption that you're all together and you have a type, you can just put it everywhere and put all the things that you need into that type that are needed in the three different components. So we had to take the gas type, the way which is the ether type, and some native hash types, move them into a separate package and remove some of these special features that only the consensus bits needed. And we split those out and stuff like the block headers. And tracing depended upon some other components that were deep nested in. So for the standard tracing, we went ahead and re-implemented that. For the standard tracing, that was easy. For the full parity tracing from the parity Ethereum style, that's gonna take a bit more work. So that's still sitting in there. We didn't move everything over. Some of the testing codes still depends on some of the setup from the monolith to set up things because we got to test things like do the trigger, calculate it correctly with the Ethereum reference tests. Those were a lot harder to split out. So those went ahead and stayed in the monolith. So the EVM module is still built in the monolith, but the library pieces are taken out separate. The next thing we needed to do was we needed to address some performance concerns. Ethereum only operated at 1.1 megagas per second. Yeah, there's 15 or 30 million gas in each block, but each block only comes every 13 and a half seconds. Hedera wanted to do something more on the order of 15 million per second. And if you figure it out, if that's what that's about 400 over 400 ERC20 transactions per second that they wanted to do to get it like 400 TPS just on the smart contracts alone. Now, for comparison, if you're using the Hedera token service natively, they can do 10,000 TPS, but they're not doing it through an EVM. You're just doing your token transfers directly in Hedera. And if that's all you need, it's gonna be cheaper to use the happy APIs. Happy is the word I use for the Hedera API, HAPI. So it's quicker and cheaper to do it that way. But if you wanna do fancy things, such as support DEXs, you would need to use the EVM to do that. So there was a lot of, there's four bullet points of things that I had to do mostly worrying around bit-swiddling and moving bits around that we were doing multiple times and calculating things into different levels. So as a result of this, the quote-unquote floor performance of the worst performing operation right now is about 60 megagas per second. So if all you do is you do shot three hashes all day long, you'll get about 60 megagas per second if you run it in our tests. Nobody does that really. A lot of the other operations perform much better. So that gives us the security guarantees we need to put 15 million gas per second as the performance ceiling inside of the Hedera nodes. So we got a lot of safety margin coming in there. Whereas before we didn't have that safety margin. We also had to update some support to bring it up to date with current EVM standards. There was three more op codes we needed to implement. We gave a chain ID to Hedera. 0x127 is the hexadecimal code for lowercase h with a bar through it. The currency is called hbar. It's some joke about Planck's constant reduced that I don't understand because I was never a physics major but that's why they picked the hbar. And so we go 0x128 and 0x129 for our test net and preview net. And if you build a local version of and test it locally, you'll have 12a as your chain ID. We also had to implement self-balance. We needed to do some fee schedule changes to S store that were changed since Constance and Opel and we needed to support an opt code that was designed for EIP 1554. So we don't support is the next bullet point. We don't support the EIP 1559, but it's 1559. But we don't support the EIP 1559 fee market. We have our own fee system setup that is indexed to the fiat value that we move the hbar with. So I needed to put in some support in there to return zero for the base fee and do some other exposing of the exchange rate to make things work properly in the fees. Now looking forward, we're gonna be supporting all changes that are coming in in Shanghai. There's actually one small minor change that's coming in in Paris that we'll support a bit later. They're changing the difficulty operation to a RANDAO operation. And we're gonna support that with something slightly different but still in the same spirit of taking a running hash from the production of the Hadera network, whereas the RANDAO is taking something from the production of the consensus layer. We're replacing that with a similar operation because a lot of people when they use that difficulty operation, what they're looking for is basically some sort of an arbitrary random number in the lower bits. So we'll deliver that as a seed that they can run their numbers against. The next thing we need to do is we need to worry about accounts. And this is kind of the big thing. We're still going through some of the details in Hadera. Hadera's accounts don't work like Ethereum accounts. We start at 001000 when we started issuing our accounts on mainnet. We've got over a million accounts right now so you'd have 00, 1 million and some digits behind it. But these are assigned increasing in order from linearly. So you create a new account or a new contract, you take the next lot. This is completely opposite from the way Ethereum does it. When you deploy a contract, it takes a bits of information like this is the notes of the account, this is the account number, put a little magic salt in there, hash it together, and out comes this 20 bytes, you take the 20 bytes of the SHA-3 hash of all that. So you get something big and convoluted like the 0x address. One advantage there is that you're never gonna have a collision from these. Your contract number doesn't depend on previous deployments but the downside is it's hard to manage it in an enterprise friendly fashion. So the initial approach that we did for it was just to map your Hadera account address to what I call the long zero notation. We would take that number, we would smash it down into the hex equivalents. We would need 24 bytes to do all three of the bytes in Java long. So one of these two zero dot zeros, we're gonna have to throw some bytes out. I would think it's gonna be the middle one because that's the future plans for it. It's gonna have a smaller range. But from that, you get a long address that looks almost like a pre-compiled contract but it's not really a pre-compiled contract. It does resolve to, when you run it backwards, that's gonna be 987654 in decimal when you run it. Now we decided to go on to a different approach where we would allow accounts to take on aliases and there's a couple of reasons why we would wanna do that. One of them is for accounts, this reason why aliases were invented or for exchanges that wanted to fund accounts where they don't know the number. So you set an alias to be the public key. So we used this public key and we went ahead and calculated the Ethereum address that would go with it for accounts. So if you have an ECDSA key associated with your Hedera account and you set it as the alias, we can give that big long name that you would see typically in MetaMask for your account and still access it through MetaMask. Now only one of these addresses is used in EVM, either the long zero or the EVM address. So if you set an EVM address, you can't access your account via the long zero notation. It's kind of a security flaw to allow an account to be accessed by different names. It presents a number of challenges and problems if you allow someone to talk about things in two different ways. So that's the current state of how we're managing accounts. The next thing that we needed to do is we needed to change the way some of the operations to work within the constraints that Hedera required of it. Eight different accounts when you access a non-existing account will throw it, will raise an exception within the EVM. If you try to get the balance or the code hash or call an encounter contract that does not exist that's above the current number that doesn't have an alias mapping, you'll get an invalid Solidity address exception raised within the EVM just as if you try to access other things. We're looking at changing that but there's not a guarantee on that right now. So we're looking at rolling that back so we treat it like Ethereum does where non-existent accounts have a zero balance. They have an empty string for their code, an empty byte string, and if you call one of these objects you'll just get your data back. If you try and send data, if you try and send value to it I expect we'll still revert because we have some requirements that for creating new accounts that can't be handled effectively via just sending H bar to it like you'd hand an Ethereum. We also need a special integrations for the create and the create too. Like I said, accounts are created sequentially from one zero to zero thousand. So when you create an account we need to give that, when you create a contract we need to return the new contract number. We needed to do something different entirely with create too because the point of create too is you get a deterministic contract back based on some input data. This is used heavily by DEXs like Uniswap and SushiSwap where they would take the two addresses of the coins that you're swapping into their salt and they'd smash it together so you'd always get the same address. So for create too we extended the alias concept to smart contracts. When you create too a smart contract we're gonna put an alias on there of the new address and that will be used. And the final piece of integration we needed to work on was fees and gas. Hedera has a very rich and complex fee schedule and they make sure to charge you exactly for what you're using and nothing more. So if you're using long-term storage, stuff you persisted disk, short-term storage, stuff you would keep in memory for the next three minutes for other nodes to access. If you're putting stuff in the block record we charge, we charge for compute, we charge for a number of other things. And we index that very lowly, I mean we also charge for the number of signatures you ask to be verified. So if you do a five of seven signature on a transaction we're gonna charge you to verify all five of those signatures. And those provide for some really low fees, that's one of the ways they get to low fees is they only charge for what you use. But that had some interesting interactions with Ethereum. But where we were able to figure out is for the most part the Ethereum gas that is charged for these operations already covers the fee if we do a conversion for the gas price to H bar. It almost always comes up greater than the fee that's gonna be charged. And the cases where Hedera would charge more, under the covers we charge more. And there's only a few cases like if you have an account with an expiry that's set to the 23rd century. That's gonna be really expensive. And so that's where the price would come through. But if you're using the default setup where your accounts need to be auto-renewed every three months, it'll look just like the exact same gas schedule that you're gonna see in Ethereum. Now one thing that is changing with this issue I said about charging storage for the 23rd century, we're separating the charge for long-term rent from the writing of the value on the first time. That's because we're introducing the notion of state rent into the Hedera network but we're gonna charge separately out of the EVM for it. And this is something probably gonna ship in 2023. Some of the bits are leaking into the code now but the decision hasn't yet been made to flip the switch on it. But that's something that's coming in the future and that it's gonna have a positive effect on the EVM integrations because the gas calculations are gonna be a lot more stable and reflect a lot more of what's really going on within it. So the next point of integration is we wanted to integrate the EVM with Hedera token services. We wanted people who are using an EVM type smart contract to have the same first-class interactions with the Hedera token service token, HTS token, as you might have if you were to deploy your own ERC20 or ERC721 contract within the EVM. One of the advantages why I wanna encourage people to use the HTS system is it's much more cost efficient and memory efficient and faster if you give someone a token and they wanna trade it they can do it for much cheaper than within the EVM. So the Hedera token services, like I said, it's a ledger native token that has no interaction with EVM. It exists as a Hedera concept. You can do 10,000 transactions per second on these if you're using the happy and there's low fees. It's like 1,100th of a cent to transfer tokens from one person to the next. And we support NFTs, fungible tokens and again we access this via the GRPC service. We'll get to this in the next segment of why this is a problem. But if you wanna use the native tokens you can get the high speed and cheap fees. You have to use the GRPC, there's SDKs that'll help you out with that, it's really easy to code but you can't do it with hard hat. So that's the downside is it would require developers to move to a new SDK which can be a problem. So as far as the EVM side of encouraging to use that we decided to expose the HTS services to via what I'm calling a system contract. Or nearly you'd call stuff like this a pre-compile contract but I wanna separate the notion of a pre-compile contract from a system contract. A pre-compile contract is something that you could express entirely within Solidity. For example, a lot of crypto primitives you can actually do in Solidity. The reason you wouldn't do it in Solidity is because it's really expensive. It would cost like 2 million gas to verify a signature. That's just way too much gas. So they tell the clients to implement it natively and charge something closer to 20,000 gas to verify a native signature. So that's stuff that does that I would properly call a pre-compile contract. But what's going on with these system contracts is it's actually breaking a layer. It's leaving the EVM and interacting with the container that's hosting it and doing services like you would break out of a container in Docker. You would go in and you would access the system and bring it back in. So that's where the system contract concept comes from. So these services that you can do, you can transfer, you can mint and burn your tokens, you can create new tokens, you can change the keys on your tokens. And you can do this via a Solidity interface. All of these services, you can do all of these calls via a GRPC happy service, but now we'll let you do it through a EVM system contract. There's some really useful use cases for these. There's a company called Calyxie that is letting people create tokenized themselves and their followers. So if you have a really popular YouTube channel, you could create a token of high fives. You could give people, hey, 100 high fives for liking my stream. So you could create that token and in the smart contract, you can automate the creation of it and handle it and set it up in an automated fashion. And you could mint more high fives if you need it. You could burn the high fives if you have too many. You could create NFTs. You could transfer NFTs within these smart contracts. So Calyxie is one example of where you might want to do some of those things in an automated fashion. Now the smart contract address is 0x167. That is T with a bar through it. I like the Unicode jokes when I pick out my random numbers. We also in the SDK have easy access to call these smart contracts as though you're calling another contract. There's a quirk and solidity where when you call any contract versus they're gonna make sure code's there before it issues the call. So one of the classes we have in there deals with that quirk. You can write it in solidity to do the call. It's really ugly looking. It's not as easy as the function. So we write a function for you that will do that ugly, unwrapped call for you and it will look just like a solidity call and it's an internal function. So it'll inline and it'll be just the same as if you did it yourself. So those are in the SDK and the smart contracts repository to use these tokens as though they were just another smart contract. Another thing we did for the tokens themselves. So like I said, there's an account and your smart contract has an account. All of these accounts come from the same number space. So if you post a token it's gonna come from that same sequence of numbers which again maps to a Hedera address that I call the Long Zero address. So what we integrated was a series of redirect contracts into the HTS system contract that allows you to treat these tokens in their EVM addresses as though they were ERC 20 or ERC 721 tokens. And this allows you to when you hook your MetaMask up via Hashio you can see your token balance as though it's an ERC 20 token. You can trade your ERC 721s just like it's a regular old NFT. And we'll go through the notes here make sure I get everything covered. And it was published by HIP 218. I talked about the HIP process. This is how he specified how it would be interacting with it. And the contract redirects to 167. So you're contracted OOFFFFF if that's your Ethereum address for your token it would then redirect it put the token address in there and call a different method in the system contract. Now one interesting thing about this to prove that it works not only I've seen my NFTs in MetaMask and my tokens in NFTs but one of our partners in the demo the other day showed us how they got the zero X order book working with our NFTs. You could put your NFT in an order book and it could be filled by a different different decks that's on the system and it just works like magic because we implemented all these standard APIs that are standard in Ethereum and they just work with, you know they didn't think it was a big deal that they got zero X working but I'd known the internals and I know the struggles that we had with it for them to get that working without having to come back and asking for texts apart was just like wow it's like working like we expect it this is awesome. So a little bit of developer anxiety that I'm sharing there every developer feels like that when they ship a new feature. So quickly there's a couple of other system contracts that we exposed to expose system information in there. The first one is the exchange rate. Like I mentioned before I don't think I mentioned it here actually Hedera's fees are fixed to fiat. So we every so often we go out and figure out what the consensus exchange rate is of H bar to dollars. We feed that into an exchange rate calculator. So we calculate your fees that we're gonna charge and we convert that to H bars. So it's still gonna cost you 100th of a cent in H bars to your transfer. So if you want to inside of your smart contract figure out what that exchange rate is rather than doing math with the gas cost and making assumptions about the schedule you can just ask it you know what is the current exchange rate in H bars and what's the current exchange rate of H bars to tiny senses what we call it. And we'll return that information. And there's another smart contract the PRNGC this is the one I'm gonna be integrating to give the same sort of functionality as RANDOW. Some of the technical details we keep running hash of our transactions. And the decision was to go to a transaction three transactions ago and take that running hash from that transaction and use that as the pseudo random seed. So you can get that information put it in your smart contract you can with more safety generate random numbers. I mean generating random numbers in a smart contract is always a danger filled proposition but this provides you a source of randomness that's a little less predictable and less controllable and more repeatable. And just randomness in smart contracts deserve its own 20 minute session to describe exactly how to do it right and how to do it wrong. Both of these contracts like the other smart contracts we've exposed to the system contracts use a Solidity ABI. So you call these as though you're calling another Solidity contract and we have contract calls to support this. So any questions before I go on to the next section? This is like a big brain dump and you're just trying to absorb it. Cool. So the last thing I wanna talk about is the Hedera JSON RPC bridge and Hashio project. The Hashio is the branded version that we're hosting but it's actually a JSON RPC bridge. And what we need this for is to solve the last mile problem what I call the last mile problem of getting people to use Hedera from Ethereum. The developer tools that people use depend on the Ethereum way of accessing the network. They depend on a JSON RPC interface. The response to certain JSON RPC calls and some very deep assumptions about the Ethereum network are built into that. For example, the way that the transactions it's just one transaction type. It's RLP encoded. You gotta sign up with an ECDS-AK and your ECDS-AK has to match to the account that you're working through. These are some pretty deep assumptions that run counter to some of the things that you've done inside of Hedera. For example, we have a GRPC account. All of our accounts are not tied to a particular key. You can rotate your keys. You can say that your account is a three of seven multi-sig. You can say that your account is a multi-sig that requires signatures from three groups. You need someone from admin. You need someone from finance. You need someone from the executive. And you can do these really complex, awesome trees that ESG people love to see go on with it that Ethereum can't do and do it natively. But when it comes to calling something via MetaMask, MetaMask doesn't know or care that you have a rich and through-out key hierarchy. All they know is that they got a private key that's gonna sign this transaction to do this call and they're gonna send it to you and hopefully are ready to receive it. So those are some of the things that we needed to solve. And we need to solve these problems because a lot of these DApps out there, a lot of these white label apps that we're trying to bring in, they have to work in the Ethereum way because that is becoming the IBM PC compatible of the smart contract world. It's not the only game out there, but it's the biggest game and it's the game that gets you the most traction amongst all the chains. So building the JsonRPC support allows us to be one of the players in there and give them access to Hedera via the tools that they have. So the first thing that we did to support this, one of the deepest problems is sending transactions. So we created a new Hedera transaction type called Ethereum Transaction. It's a really simple transaction that has the signed bytes of an Ethereum transaction and then it's a relayer that wraps the transaction and they're paying for bringing this transaction to consensus in the hash graph and they're paying for nothing else. Everything else is paid for by whoever signed that Ethereum transaction. And the key that signed the Ethereum transaction is brought in the key set. So if you have that ECDSA key in your account key that it maps to and you've signed that transaction then you don't need any other signatures in the relayer. So this is designed for simple cases where if you have an account that you just want to interact with Ethereum and EVM type stuff, you would create one account that has one key, that one key is ECDSA and you set that as the alias and that's how you would interact with it. And so the gas cost, there's some things in the transaction we can pay attention to and some things we can't. If you set a gas cost on there that is lower than the fixed gas cost of Hedera we're going to reject it. If you're using $15.59 and your max fee allows for it to be covered, we'll charge you the actual fee. But if you're using a type one transaction, you set a ridiculously high gas price. The agreement you're making with the type one transaction is we're going to charge you as much as you ask for. So if you, if you, if we halfway support $15.59 in that you'll set a maximum fee and we'll only charge you the literal fees we have to charge you per the standard fee schedule. And one other feature that we have in here is that the signer has the opportunity also to pay for the fees for you if they choose. They can list a maximum amount of H-bar that they're willing to pay. I don't think I put that on this slide. Oh yeah, it's the second bullet on the top. So the relayer can offer to pay for a certain amount of the transactions they can pay for part of the transaction or all of the transaction. So this actually opens up the opportunities for meta transactions. For example, for game use cases that want to use ADAPT that need a zero gas network you just need to set up a relayer that's going to pay for all the fees that come in for all of your game transactions you just want to work on Hedera. And so we support this that the public test net of course won't do it. You'll need the public cashier instance. You'll need to set up your own instance with your own relayer. And if you do things right you could relay it to a node that you have an agreement with that you'll get the fees back from. So if Google wanted to host a game they could just point it at their game and that the gas fees would to some extent become circular. The JSON-RPC bridge we also needed to implement all of the other queries that are in JSON-RPC. And it's a mix of, well let's see we do the happy, the raw transactions. I don't think I discussed that too much in this. So I'm gonna go off slide and just talk about this a little bit. But we had to implement all of the different JSON-RPC transactions and sometimes we need to go to the Hedera node and do a paid transaction. And sometimes we go to our mirror node. I didn't get a slide in here to show the typical network architecture but getting items from the Hed consensus nodes we always charge because you're getting in the way of consensus. We need to limit it and incentivize people to use other sources. We have another system called the mirror node that takes the transaction stream and makes it available for free that you can read from and stand up your own instance to get the data from. So some of these calls we can go to the mirror node and where we can go to a mirror node we do to get them for free. Some of them we go to the consensus nodes and the mirror node is in the middle of upgrading to support more and more of these rich calls because we still have some, we can't do debug, get storage at quite yet because we don't have that available on the mirror node but they're improving these and we'll be able to support all of these eventually. And the reason we need some of these strange calls like get storage at and get contract data is because some of the development tools like MetaMask, Truffle and Hardhat like to get this information when they're doing debugging work. So we'll expose this. We're exposing some of these through the developer tools. The developer tools won't perfectly work yet. It's still a beta. The only thing we targeted for this stage is to get web wallets like MetaMask and Tali working correctly. And so those are the ones that we focused on right now but our roadmap item is to get this working with the developer tools seamlessly and transparently. So all you have to do is just point your developer tool at a different RPC endpoint and then suddenly you're on Hedera. Now when I say that, that we just wanna make it transparent and go to Hedera you need to ask, well, why would you go to Hedera? So there's some key differentiators that we like to remind developers when they're developing transactions and they're putting them on the various EVM compatible chains. One of the biggest things that we like to point out about Hedera is that there is no transaction pool. There's no mem pool. Once you post a transaction on Hedera it's fixed in that position. Nobody can censor it. It's gonna go through consensus. So there's no sandwich trading. There's no minor extractable value. There's no games with ordering things out of the pool or trying to keep your tornado cash transactions out of it. We're going to take them all as they come in. The next thing, and this is really the secret to how we get a performance speed is that ordering and execution of these transactions are separate steps. We order the transactions and then we execute them. We don't play a game. We say, well, is this transaction gonna succeed? If it's not, well, then we can't put it in. Every transaction that comes to consensus gets executed after the order is set. So there's no consideration for the side effects. And things go fast enough that we really don't have time to do that. And finally, there's continuous transaction execution. We don't wait 10 seconds and give you a port of 5,000 transactions that went through. Every second, every time we can come to consensus and figure out that a transaction has reached final order we will execute it continually on each of the nodes. We don't have to wait for an agreement to pick out who's the next leader and wait for them to propose or not propose a block. This is a synchronous BFT. Everything just comes out all the same. So as a quick summary, the three major things that we needed to do to bring the BASU EVM and Ethereum transactions to Hedera was first we needed to upgrade to the BASU EVM to get main net compatibility and to get the performance we needed. The next thing we did is we exposed our Hedera token services via system contracts so that EVM users can with full fidelity use the same Hedera token services that our non-EVM users can get access to. It's faster and cheaper to do it outside the EVM but it's possible in the EVM. And for a lot of use cases like DEXs they're more than willing to pay the premium and take the speed hip to get what they need. And finally we solved the last mile problem by Project Hashio where we provide a JSON RPC bridge that talks to Hedera in the RPC mechanisms Hedera talks about while at the same time making it open for developer tools to work and interact. They were designed to work with the Ethereum ecosystem and get those working with Hedera and get your web wallets and everything working with that. So here's some links. Like almost every company here, Hedera's hiring thrillslabs.com slash careers if you wanna see the open list. But if you wanna get ahold of me I am at Shemnon on Twitter and GitHub on Discord. I guess I'm Shemnon number 2321. You need those numbers because Discord's Discord. Or if you like email, if you're part of my generation and still use email you can use dano.ferrin at swirlslabs.com. There's also links to Hedera, Swirls Labs and the various projects that I listed here. Any questions? There's gotta be one question. Did I explain everything perfectly? There's always a chance. Brett, did I miss anything? Do I know anyone starting to use these capabilities? Do I know anyone I can talk about? I think I can mention Open Zeppelin is their part of the Australia ANZ Bank stablecoin currency. One of the features that they needed to support because of their governance, they needed this project that Open Zeppelin had called Defender and it only really worked well via Json RPC and we talked to them. It's like, hey, could you convert it happy? And they said, how much money and are you gonna give us the engineers? Which is a typical problem in a smart contract space right now because we're engineering constrained on almost everything. But when we bring them a Json RPC bridge, they could access Hedera and get the information they need through Json RPC. Their tool just magically works because they speak it in the language it's expecting and it gives them all the feedback and telemetry that they needed. So that's someone that I know that is using it today. Even though we're not done building it, it's providing all the features that they need. Cool. Well, if anyone has any questions, you can grab me in the hall. I'll be here today and tomorrow. I'm flying back on Wednesday and I'm probably gonna be in the air when this Ethereum merge event happens unless it keeps getting pushed into Thursday. So, all right. Thanks.