What Alternative Blockchains Compatibility with Ethereum Tooling Can Teach Us

foreign [Music] I thought you know other chains have gone before ethereum and they've done different things in ethereum and we've adapted things and so is 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 changes 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 what I got instead was 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 um how to read 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 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 base 2 and they wanted to improve their ethereum compatibility game so now idea was well hedera's Java based base is Java based let's just complementize out their evm and bring it into hedera and bring that software over and suddenly boom 100 evium compatible it's not that simple there's a lot more to it than just reading byte code and executing programs so I'm going to talk about three separate areas the first area is going to be accounts and 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 and transacting with ethereum which is 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 on crypto on the accounts is the cryptography accounts are 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 um ethereum uses ecdsa on secp 256k1 hedera uses Edwards as does near polka dot uses a combination of schnor 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 of shot three called contract that ethereum uses then there's actual shot 3 which hedera uses but they use more bits near uses shot 256 as as the consensus layer and polka dot uses Blake 2. um so one of the things looking at this is you might think we can just pick one and go with it the problem is need 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 going to have to change some of these algorithms and at some points we're going to have to do significant changes so we should continue to build with this in mind that we're going to want to change it I mean as it is right now we may want to change it to use the wrong button this is the laser we may want to use BLS 12 381 for some of our accounts it's not just useful on ethereum mainnet 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 I think that's covered by the next slide so the 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 um hedera is interesting an alias system and some of its accounts to support some of the needs of 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 um 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 um but another problem with compatibility is if we're going to use a different Key address do we do address translations to ethereum do we have definitions for these we'll probably need some sort of a definition for how you would take a BLS 12 signature into an ethereum address if we're going to adapt that for for various uses um and their biggest problem is that 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 it 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 what the RPC tells them is the new address when it comes back to them another problem is authorization EC recover is used by a lot of contracts to authorize messages like 0x to authorize the trades some other uh some other Dows use it to validate votes and everything like that but this again ties the account to the key and also approved includes key rotation um hedera we use this clinch accounts which doesn't work well to easily recover we have to map in it addressed 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 and we probably need some sort of a an account authorized pre-compiled to be brought into ethereum when we do account abstractions so you can ask a question of here's a address here's the signature and here's the here's what they signed um is it authorized and then just return yes or no so I think you know that would help us continue to keep PC recovery as a primitive and move the questions about am I authorized into a pre-compile that has deep integration with the system and finally account abstraction [Music] um one thing I we should learn from hedera on this is hedera counts 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 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 aliasp account and we would create the account under the covers for you late the moment we need it um 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 going to have account abstractions we need to have a mechanism that you could that you can't 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 um 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 so I'm a draft some drafts have this feature some drafts don't have that feature of account abstractions 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 bring in the same Library there's always rough edges and Corners that you need to deal with one is the issue of ergonomics and pre-compiled 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 a queue up a layer 2 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 lots of smart contracts lots of uh different blockchains have different addresses for a lot of their pre-compiles an interesting one down here is stello this is actually the pre-compile that was the BLS signatures that was in Berlin before it was removed before we shipped it to test Nets they just the difference is there they put it at a different address which I think underscores what the what my main ask here is that we probably need to organize a registry of pre-compiled contracts that all chains and layer 2 is used 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 as for these contracts there's going to be a difference between a pre-compiled contract which is a contract that you could do everything within the evm most crypto Primitives would cover into this you just can't do it efficiently you can't do it the speed wise it costs too much so you pre-compile 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 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 the BLS signatures I would really call a pre-compiled contract on this list um a little bit here we had to do something different instead of randow we used a different hash um and hedera has a very complex P system it works um you just librarize it gets lots of tests um 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 um but you know 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 the multi-dimensional 1559 would be a good value and I don't think we're going to 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 going to store its store uh take up a lot of memory space that you're not doing a lot of compute from there's no reason to keep the the whole blockchain shut down just do one large operation that takes no compute um not too big of an issue um 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'll tell a little parable about this um and a lot of things that you're interacting with in smart contracts and in in uh blockchain sometimes you don't know if it's really going on anywhere so if it's going on under the system inside inside of it so here's here's a little scene from Westworld season one where Billy is going in and says like are you real and the Very pivot comment that comes out that kind of shapes the rest of the series is well if you can't tell does it matter 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 this in hedera hedera has a very rich token system that has zero connection to the smart contract system um 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 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 crc721 contract and it worked great we plugged in some some unicorn some uniswap derivatives we plugged in zerox protocol in some of our metamask testing it just magically worked and none of this was running evm code um 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 um this has very and this is honestly what zkevm uh proving is is using in the system and you know it's it's uh 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 on 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 um we had to adapt the ethereum transactions into hedera transactions I'll go through this in some of the slides um but first I want to 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 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 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 the majority of the other nodes and you can take an average of when it came and that's your time stamp 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 so when people say hedera is 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 out 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 because we're running the evm full-time you know the base of evm is not the fastest that will be evm1 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 Mega gas 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 um the problem is this really doesn't apply to ethereum blockchains never changed their consensus algorithm well almost never and consent and uh and um ethereum 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 talkative and surrounding proposer 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 you know not much to be considered about this this is kind of neat 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 announces hedera doesn't use transaction nonsense they use timestamps and you can do neat little tricks with your valid start time and valid duration down to the nanoseconds to ensure uniqueness for your transactions um but this is a problem that ethereum very strictly uses their notes and they really use their notes as sequence numbers I really wish that when they started this spec instead of calling it a known so we call it a sequence number but unfortunately that ship has sailed in nearly every blockchain out there when you see notes in a transaction you know it seeks its 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 um but it doesn't um it doesn't do the transaction sequence numbers and the gnosis it actually treats them as a true note great for performance and throughput horrible for memory so not everyone does this but we had to adapt announces the next issue was meta transactions we took a process where we wrapped the transactions of the ethereum rlp inside of a hedera transaction and we started the hedera transaction with one account and the inner account was responsible for it this is you know plastic protocol level meta transactions there's not too much fancy stuff going on with it and it just transparently works um 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 was responsible for the rest of it once we map that transaction to a user and if the relayer sends garbage into the into pedera 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 balances great then spins like a top um so so if we need to get um meta transactions into into ethereum mainnet the way to do it would be through uh in shredding in the protocol would be the best way um what we have right now with the Cooperative impersonation going on is is a good enough way for people that want to participate but account abstraction also has the potential to solve this problem of allowing people to to pay in one account and act in another now I promised I'd come back to this off and off call um 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 often off call is their solution I think is is stronger evidence and I think on balance is going to come by even if you take these evidences out that it's not worth the risk um maybe we should examine pay your 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 going to go through and talk to systems that aren't necessarily live but have verifiable information it's going to work great it works great for us um so this is something this is um 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 ax ask this is this is my uh last point can we get an RPC system that doesn't put everything in the post body can we please get arrest like Json RPC that is 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 um and so that's one of the issues because hedera uses grpc and it's got amazing load balancing implications um but we can't quite do the same tricks that we do with uh with Json RPC so in the 25 minutes that I had to talk or the 20 minutes I was allocated um those are my conclusions of of what we could really learn from from ethereum um from from other networks and what ethereum could apply I think account abstraction has great future potential to solve a lot of these problems um the evm um 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 to change to deal with potential changes in cryptography that comes ahead and um not every chain is going to be a theory mean that there's going to be other changes that do cool things that aren't compatible with ethereum mainnet that's fine let them do their cool things let us hear be ethereum and if you have any questions or comments my DMs are open um just don't offer me a pump and dump I will delete you [Applause]