►
Description
Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.
https://archive.devcon.org/archive/watch/6/what-alternative-blockchains-compatibility-with-ethereum-tooling-can-teach-us-about-ethereums-future/
In this talk the various techniques that some L1s and L2s use to provide EVM and RPC compatibility with end user and developer tooling will be examined. Special attention will be paid to features (address aliasing and expansion, RPC handing of system contracts, account abstraction) of other blockchains that Ethereum developers have discussed with an eye towards the compatibility issues they introduce.
Speaker(s): Danno Ferrin
Skill level: Advanced
Track: Layer 1 Protocol
Keywords: EVM,JSON-RPC,COMPATIBILITY
Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/
Devcon is the Ethereum conference for developers, researchers, thinkers, and makers.
Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/
A
A
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.
A
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.
A
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
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.
A
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.
A
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.
A
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.
A
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..
A
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.
A
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.
A
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.
A
Hedera
uses
a
sequential
system,
counting
up
from
a
thousand
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
by
disconnecting
the
public
key
from
the
address,
you
can
do
things
such
as
key
rotation,
which
is
critical
to
some
Enterprise
applications.
A
A
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.
A
Another
problem
is
authorization.
Ec
recover
is
used
by
a
lot
of
contracts
to
authorize
messages
like
0x
to
authorize
the
trades,
some
other
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
hedera.
We
use
this
clinch
accounts
which
doesn't
work
well
to
easily
recover.
A
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.
A
Here's,
the
signature
and
here's
the
here's
what
they
signed
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
one
thing:
I
we
should
learn
from
hedera
on.
A
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.
A
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
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.
A
A
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.
A
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
different
blockchains
have
different
addresses
for
a
lot
of
their
pre-compiles.
An
interesting
one
down
here
is
stello.
A
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.
A
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
a
little
bit
here.
We
had
to
do
something
different.
Instead
of
randow,
we
used
a
different
hash
and
hedera
has
a
very
complex
P
system.
A
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,
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,
not
too
big
of
an
issue
off
and
off.
Call
I,
don't
know
that
anybody
that
does
this.
A
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
and
a
lot
of
things
that
you're
interacting
with
in
smart
contracts
and
in
in
blockchain.
A
A
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.
A
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.
A
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,
this
has
very-
and
this
is
honestly
what
zkevm
proving
is
is
using
in
the
system-
and
you
know
it's
it's
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.
A
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,
we
had
to
adapt
the
ethereum
transactions
into
hedera
transactions.
I'll
go
through
this
in
some
of
the
slides,
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.
A
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.
A
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.
A
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.
A
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.
A
In
case
we
get
overloaded
in
other
parts
of
the
system.
Now
the
problem
is
this
really
doesn't
apply
to
ethereum
blockchains,
never
changed
their
consensus,
algorithm
well,
almost
never
and
consent,
and
and
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.
A
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.
A
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,
but
it
doesn't.
A
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.
A
A
So
so,
if
we
need
to
get
meta
transactions
into
into
ethereum
mainnet,
the
way
to
do
it
would
be
through
in
shredding
in
the
protocol
would
be
the
best
way.
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.
A
Now
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
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.
A
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.
A
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,
so
this
is
something.
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
ax
ask
this.
Is
this
is
my
last
point?
A
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.
A
So
in
the
25
minutes
that
I
had
to
talk
or
the
20
minutes,
I
was
allocated.
Those
are
my
conclusions
of
of
what
we
could
really
learn
from
from
ethereum
from
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.
A
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
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.