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]