►
From YouTube: Let's Talk EOS EVM!
Description
The EOS EVM launch is just around the corner
Zack Gall and Brandon Lovejoy sat down with Areg Hayrapetian & Matias Romeo to chat about the technical work going on behind the scenes and the impact that the EVM will have on EOS 🛠️
00:00:00 Start
00:00:08 Welcome to the Everything EOS podcast
00:03:35 Matias Romeo joins the ENF
00:06:55 EVM launch roadmap
00:10:25 The gas economy
00:20:00 Trustless bridge
00:25:08 Why EVM is important to EOS
00:30:40 What is Silkworm
00:38:11 Crypto Primitives
00:44:22 z-k SNARKs
00:46:09 Performance and Compatibility
00:56:57 Instant Finality
01:04:30 Account creation
01:12:18 End
The EOS Network Foundation coordinates financial and non-financial support to encourage the growth and development of the EOS Network. We’re harnessing the power of decentralization to chart a coordinated future for the EOS Network as a force for positive global change.
// EOS Network Foundation //
https://www.eosnetwork.com
https://twitter.com/EosNFoundation
https://www.linkedin.com/company/eos-network-foundation
https://t.me/EOSNetworkFoundation
https://discord.gg/eos-network
info@eosnetwork.com
#EOS #Web3
A
Today
we
are
going
to
discuss
the
latest
developments
with
EOS
evm,
the
ethereum
virtual
machine
deploying
on
EOS
I'm,
your
host
Brandon
Lovejoy.
My
co-host
today
is
Zach
gall
Zach
is
co-founder
and
chief
Communications
officer
of
the
EOS
Network,
Foundation
and
originator
of
the
everything
EOS
podcast
and
to
help
us
get
into
all
the
details.
We
are
joined
by
two
other
esteemed
guests:
arig
arapatian,
director
of
engineering
at
the
EOS
Network
Foundation,
a
core
contributor
to
the
EOS
code
base
since
before
launch
of
the
EOS
mainnet.
A
Alongside
his
work
with
enf
engineering,
recently
arag
has
been
supporting
the
origin
team
with
their
work
on
Antelope
IBC,
the
forthcoming
instant
finality
and
working
alongside
Matthias
Romeo
on
EOS,
evm
and,
last
but
not
least,
the
newest
member
of
the
enf
engineering
team,
but
certainly
not
new
to
the
EOS
Community
Matthias
Romeo
Matias
is
a
long
time.
Eos
contributor,
a
founding
member
of
the
block
producer
team,
EOS
Argentina
Matthias,
helped
launch
the
EOS
main
net
among
his
many
contributions
to
the
EOS
ecosystem.
A
After
the
launch
of
EOS
Matias
developed
a
smart
contract
that
helped
restore
over
3
million
Frozen
EOS
tokens
to
their
rightful
owners,
he
cooperated
with
bitfinex
in
the
development
of
the
eosphinex
on-chain
exchange.
Marius
was
also
a
lead,
blockchain
developer
of
lock
chain,
the
Latin,
American
and
Caribbean
chain
test
net
for
the
inter-american
Development,
Bank
and
co-organized
to
the
EOS
Rio
conference
in
Brazil
and
not
least
of
all
Matthias,
was
instrumental
in
integrating
metamask
to
EOS
mainnet.
A
A
B
C
B
D
Yes,
before,
before
joining
the
the
team,
I
previously
worked
at
block
one
for
one
year,
together
with
attic
doing
contributions
to
to
the
development
of
EOS
at
the
very,
very
beginning,
yeah,
so
so
in.
In
fact,
I
also
remember
Eric
from
previous
day
from
beechers,
also
and
and
also
for
first
team.
So
yeah
we've
done
the
old
timers
and
the
news
that
consists
all.
B
Wow
so
I
think
this
intro.
This
is
the
first
formal
announcement
that
Matthias
has
joined
the
enf
as
as
part
of
our
our
engineering
team.
So
that's
the
announcement.
Welcome
to
the
enf.
It's
been
great.
We've
been
working
with
some
since
the
the
very
beginning,
almost
of
the
enf,
so
we
announced
the
evm
plus
working
group
in
January
of
2021.
So
that's
when
the
formal
working
relationship
with
with
madius
and
and
the
enf
kind
of
begin.
B
D
Well,
we
we,
as
a
team
with
with
my
my
group
with
dios
Argentina.
We
always
were
looking
for
ways
to
make
use,
learn
like
more
accessible
or
or
more.
In
fact,
it's
friendly
for
for
asset
friendly
right,
but
we
were
looking
for
for
ways
to
improve
the
the
the
the
platform
and
one
of
the
things
that
we
started
with
was
the
integration
with
metamask,
but
the
integration
with
metamath
was
just
a
way
to
use
EOS
without
installing
any
new
wallet.
D
D
So
after
that
we
were,
we
were
presented
with
the
opportunity
to
contribute
to
one
of
the
blue
papers,
and
we
say
that
we
we
were
not
sure
that
we
can
contribute
something
meaningful
to
those
documents
and
we
told
IBS
that
our
next
war
will
be
start
working
in
an
implementation
of
the
ebm
and
then
I've
said
well.
Why
don't
we
form
a
nice
DSN
and
and
see
if
there's
a
way
to
to
work
together?
B
Yeah
I
think
I
think
it
contract
was
pretty
close.
We
announced
it
in
January,
so
this
probably
all
happened
in
November
December,
so
that
was
kind
of
the
idea
at
the
very
beginning
was
getting
the
all
of
the
blue
Papers
written
the
core,
Plus
audit,
plus
API,
plus
and
wallet
plus,
and
then
evm
plus,
was
the
fifth
one.
But
instead
of
writing
a
paper,
you
were
like
I'd
rather
just
build,
and
that's
what
happened
yeah,
because
it
just
need
something
cool.
D
The
the
specifications
are,
they
are
right.
It's
not
that
much
that
we,
you
can
write
on
the
nebm
plus
paper,
so
we
we
thought
that
the
real
stuff
was
to
to
have
something
running
and
and
have
something
like
on
chain
for
developers
to
to
to
test.
The
thing
is
that,
well,
we
can
go
on
the
test
later,
but
yeah.
A
Yeah
so
yeah
we
can
get
into
it.
I'm
really
excited
to
have
this
discussion
and
I'm
really
glad.
Zach
is
here
to
help
bridge
the
gap
between
some
of
the
deeper
technical
nuance
and
and
and
myself
I'm
kind
of
a
noob
when
it
comes
to
the
evm
and
everything
so
I'll
be
here
to
ask
the
the
questions
that
need
asking
and
today
is
a
kind
of
a
significant
day,
because
today
the
enf
announced
the
the
launch
date,
and
so
we've
got
a
an
evm
launch
road
map.
Maybe
I'll
could
walk
us
through.
A
B
Handle
this
so
it's
about
to
see
it
but
I
wrote
a
question
randomly
headset,
essentially
code
completion
that
should
be
happening
very
soon.
All
of
the
the
final
touches
are
being
made
to
the
code
that
we're
not
implemented
on
the
previous
jungle.
Four
tests
that
launched,
which
we
announced
in
in
January,
so
the
final
code
will
be
out.
First
that'll,
be
the
first
step
from
there
we're
going
to
deploy
it
on
Jungle
test
net.
B
It's
going
to
be
deployed
in
parallel
to
the
previous
test
net
to
allow
daps
time
to
migrate
over
if
if
they
don't
want
to
lose
their
data
and
then
the
audit's
pretty
self-explanatory
once
the
code's
complete,
we
give
it
to
the
the
team
at
Sentinel.
There
are
contracted
auditing
firm.
They
did
a
great
job
auditing,
the
Telo
CVM
they've,
already
audited
the
EOC
VM
also,
but
we've
made
some
significant
changes
and
then
this
the
silkworm
implementation.
B
So
this
is
their
second
audit
for
the
EOC
VM
and
pending
any
major
major
bugs
or
anything
that
they
may
come
up
with.
We
have
a
Target
testnet
launch
dates,
a
late
March
and
then
mainnet
beta
launch
for
the
EOS
evm
on
April
14th.
So
this
has
been
a
very
long
time
coming.
It
was
just
announced
today
we're
recording
this
on
February
28th
we've
been
itching
to
get
an
actual
date
out
for
so
long
because
we
just
we
don't
want
to
put
a
date
out
there
and
miss
it.
B
So
it's
really
just
syncing
up
with
the
product
managers,
the
project
managers,
the
engineers
marketing
and
just
really
making
sure
that
all
of
our
ducks
were
in
a
row,
and
we
finally
have
this
date
of
April
14th.
So
I'm
super
excited
that
we
finally
have
a
a
Target
where
six
weeks
from
launch-
maybe
five
weeks
by
the
time
you're
watching
this,
but
we're
executing
it.
Within
a
year
of
the
very
first
test
net
launched
the
first
test:
net
pre-soakware
and
pre.
A
lot
of
things
happened
on
April
19th
2021.
B
So
it's
great
to
see
that
we're
able
to
execute
the
launch
prior
to
that,
but
to
get
into
one
of
the
major
changes
with
the
previous
test
net
to
the
new
test
net
is
the
the
gas
economy.
So
one
of
the
biggest
shifts
that
we
announced
in
the
January
update
to
the
what
was
previously
called
the
trust
evm
project
was
we
removed
the
introduction
of
an
external
token
and
where
EOS
is
the
native
token
EOS
is
the
gas
token.
B
C
Sure
so
so
the
evm
runtime
has
a
native
token
right.
If,
if
this
is
the
exam
running
on
ethereum,
this
would
be
Geet
other
Forks
of
it,
but
evm
need
to
come
up
with
their
own
token,
or
maybe
they
end
up
using
eth
or
something
else.
You
need
some
sort
of
token,
as
a
native
token,
to
pay
for
the
gas
to
just
make
the
whole
thing
work.
So
initially,
as
you
mentioned,
perhaps
the
switch
to
using
EOS
as
the
native
gas
token,
there
was
another
new
token
to
be
introduced
for
that
purpose.
C
Now,
we've
we've
made
a
shift
to
just
use
EOS
itself
and
what
that
really
means
is
internally.
We
still
have
a
new
token
I
mean
not
understanding.
Certainly
we
have
a
representation
of
a
token
with
this
compliant
with
what
you'd
expect
with
the
ECM
with
ethereum
right.
We
have
18
decimal
places,
but
it's
it's
one-to-one
matching
here,
so
you
bring
your
EOS
in
from
the
outside.
It
mints
the
appropriate
amount
of
that
EOS
internally
inside
the
the
evm
environment.
C
So
we've
made
that
change
to
ecos
token.
We've
introduced
this
trustless
bridge
as
a
mechanism
for
the
Ingress
and
need
rest
to
get
the
tokens
in
and
out
of
this
internal
environment,
and
the
native
token
is
also
necessarily
the
gas
token.
It's
how
you
pay
your
gas.
So
there's
this
whole
other
mechanism.
We
can
go
into
a
little
more
detail
about
how
that
gas
is
paid,
but
not
just
paid
internally
in
the
internal
evm
environment.
C
How
that
moves
essentially
across
that
bridge
to
the
outside,
where
it's
then
used
to
kind
of
split
two
streams
to
be
diverted
to
one
the
the
EOS
account
that's
paying
for
the
CPU
and
net
resources
of
that
Antelope
transaction,
EOS
transaction
that
runs
within
it.
The
evm
transaction
and
two
another
stream
of
the
es
funds
which
are
used
to
cover
well
one
ram
costs
of
the
contract.
That's
the
other!
B
I
think
that
was
one
of
the
biggest
points
of
confusion
that
we
were
able
to
eliminate
by
just
going
all
in
on
on
Native
EOS
is
regardless
of
what
you
call
the
token
on
the
inside
of
the
evm.
Underneath
it
all
Eos
resources
are
being
leveraged.
Transactions
on
evm
are
using
EOS
CPU
on
Native
weather.
You
have
a
new
token
or
not,
but
I
think
this
is
very
good
way
to
add
brand
new
utility
to
the
EOS
token,
and
also
an
opportunity
to
create
a
burn
mechanism
with
this
new
gas
model.
B
B
The
the
rest
of
the
EOS
is
essentially
going
to
to
be
burned
on
a
periodic
basis
and
and
we'll
be
announcing
those
Burns
and
probably
have
a
fun
little
indicator
on
a
front
end
somewhere.
That
shows
how
much
gas
has
been
burned
or
is
in
the
burn
account
ready
to
be
burned
at
the
next
burn,
for
example.
So
I'm
really
excited
to
have
that
model
as
part
of
EOS.
B
Since
the
the
network
launched
a
lot
of
other
chains
and
projects,
we've
seen
introducing
different
deflationary
models
to
offset
token
insulation
and
obviously
with
EOS
like
the
node
operations
and
and
the
the
enf
itself
is
funded
through
an
inflationary
mechanism.
So
the
the
better
we
can
do
it
coming
up
with
two
things.
B
One
model
is
to
burn
EOS,
where
it
makes
sense
and
other
models
where
you
could
share
Revenue
back
to
EOS
token
holders
in
Rex,
for
example,
where
when
people
trade
Ram
when
people
trade,
Ram,
there's
a
half
a
percent
transaction
fee
that
fee
gets
fed
to
rec
stakers
as
yield.
So
you
have
those
two
options:
would
it
be
better
to
burn
something
and
move
it
from
circulation
or
pay
it
back
to
token
holders?
Who
did
some
action,
such
as
staking
into
Rex?
B
So
that's
something
like
I'm
constantly
thinking
about
so
I'm
really
excited
that
in
the
fall
when
we
announced
EOS
Network
Ventures.
That
was
the
first
time
that
was
the
first
I
guess
opportunity
at
a
burn
mechanism.
So,
with
yoast
network
Ventures,
the
idea
is
it'll
it'll
make
investment
in
for-profit
projects
so
that,
basically
any
profit
realized
on
these
Investments.
After,
however
long
it
takes
to
realize
those
profits,
two
three
four
five
years,
the
the
proceeds
will
actually
be
used
to
to
buy
back
EOS
and
then
to
burn
it
so
that
that's
the
first
burn
mechanism.
B
It's
an
off
chain
mechanism.
By
the
time
it
actually
occurs
because
typically
VC
Investments
are
longer
term.
It
may
be
automated
by
that
time
reinforced
on
chain.
It
hasn't
really
been
decided,
but
this
process,
with
with
the
gas
model
on
the
evm
it'll,
be
most
likely
programmatic,
with
scheduled
Burns.
That
will
be
able
to
kind
of
announce
in
advance
and
create
kind
of
an
announcement
out
of
so
to
speak,
Soto,
maybe
quarterly.
This
is
all
kind
of
TBD.
B
But,
to
conclude
on
this
ramble
the
more
ways
we
could
burn
EOS,
the
better
and
the
more
ways
that
we
can
generate
yield
in
in
some
ways
for
Eos
token
holders
and
a
lot
of
times.
We
don't
even
need
to
even
worry
about
how
the
yield
is
generated,
because
we
have
programs
in
place
such
as
yield
plus,
which
allows
the
D5
protocols
to
figure
out
how
to
earn
the
yield
and
we'll
just
kind
of
subsidize.
It.
C
So
I
I
speaking
of
yield
plus
I,
mean
they're
I'm
really
excited
with
this
change.
So
it
isn't.
You
know
this
is
the
native
token
and
there's
like
two
two
asterisks
of
it
that
I
I
think
are
interesting
to
me
one
is
it
really
simplifies
things,
because
the
truth
is
that
the
previous
model,
where
it
is
a
separate
token,
we
still
you
still
pay
for
the
EOS
cost
I
can't
avoid
that
and
that's
that's
the
beauty
of
it.
We
have
is
this
running
on
EOS,
so,
no
matter
what
this
internal
system
decides
to
do.
C
First
token:
economics:
the
fact
that
it's
running
on
EOS
Community
has
to
pay
for
the
EOS
cost
CPU.
No,
you
can't
avoid
so
somehow
the
money
has
to
work
out.
It
was
just
a
very
convoluted
mechanism
where
you
have
to
convert
this
new
typical
into
EOS,
to
then
pay
it
for
the
Ram
or
pay
for
the
power-ups
or
whatever.
Now
it's
a
lot
simpler,
it's
easier
to
understand,
there's
less
steps
of
conversion.
C
B
B
It
took
a
little
bit
of
time,
but
I'm
glad
this
is
the
direction
we
went
I'm
glad
this
is
the
the
way
we're
going
to
be
launching
the
mainnet
beta
you
you
brought
up,
yield
plus
and
I
wanted
to
use.
This
particular
conversation
we're
having
now
to
clarify
certain
things
of
what
will
and
will
not
be
live
on.
B
April
14th,
when
the
main
beta
launches
and
one
of
the
things
that
I
want
to
be
clear
on
is
the
functionality
of
the
trustless,
EOS
and
evm
Bridge,
so
I,
all
right,
I
think
you'd,
probably
you're,
probably
the
one
who's
been
working
on
that
more.
Do
you
want
to
explain
like
what
the
functionality
is,
what
you
can
and
cannot
be
do
at
launch.
C
Sure
so
this
is
actually
related
to
the
simplification
discussion
as
well.
So
at
a
technical
level,
this
trustless
bridge
Works
only
with
the
native
token,
which
previously
was
another
token.
Now
it's
just
EOS
that
that
the
mechanism
we
use
is
is
someone
was
only
working
with
that
that
native
token,
we
have
thought
about
other
ways
to
expand
that
to
newer
other
tokens
that
requires
going
beyond
the
native
token
supporting
some
standard
like
erc20
wrapping
EOS
assets.
C
C
Some
of
the
complications
there.
Obviously
the
biggest
complication
is
handling
the
size
of
their
different
token
standards.
We
don't
you
know
on
EOS.
We
have
this
quasi
standard.
Esi
token,
with
you
know,
cdt's
asset
type
has
certain
limitations.
It
has
again
represents
the
same
256
bits
of
amounts
that
you
can
in
the
evm
side.
So
you
need
to
account
for
that.
There's
the
erc20
standard
on
ethereum
you'd
have
to
somehow
wrap
things.
C
So
there's
things
to
figure
out
in
terms
of
maintaining
compatibility
between
what's
expected,
of
an
egm
side
and,
what's
expected
from
the
other
side,
there's
other
things
to
figure
out
about
the
exact
mechanism
of
how
you
cross
the
bridge
or
across
yeah
and
cross.
That
bridge.
One
thing
to
point
out
is
this:
trustless
bridge
alone
requires
some
changes
to
the
Eternal
protocol
of
the
evm.
It's
very
my
they're,
very
minor
changes
that
we've
worked
very
hard
to
maintain
as
much
compatibility
as
possible.
C
We
could
talk
about
that
a
little
bit
more
various
different
contexts,
but
there
are
slight
deviations.
We've
done
to
achieve
what
we
want
to
do
with
EOC
VM.
One
of
these
is
to
facilitate
this
this
trustless
bridge
and
to
make
it
trust
us
to
not
to
make
it
core
to
this
contract
and
not
require
some
third
party
to
access
the
bridge.
C
D
I
got
something
in
my
mind,
but
I
just
went
away,
but
yeah
one
thing
to
mention
is
that
even
if
the
thrustless
breach
won't
be
available
when,
when
launch
on
Main
it
as
addict
was
mentioning
that
also
a
third
party
can
act
as
an
oracle
on
both
runtimes
and
take
tokens
from
one
side
and
issue
on
the
other
side.
So
also
I,
don't
know
if
any
any
member
of
the
community
or
company
can
make
that
work.
Also,
but
yes,
we
we
plan
on
working
on
on
the
thrusters
trustless
mode,
beyond
the
release.
A
D
Okay,
I
think
I
can
take
that
one
well,
whether
we
like
it
or
not,
I
think
that
the
ebm
has
it's
now
at
the
factor
standard
across
the
whole
ecosystem.
So
that's
one
one
part
of
of
the
things
of
what
I
think
another
one
is
that
we
have
a
accent
layer,
one
a
really
running
for
many
years.
We
with
great
performance
right
so
there's
already
already
a
big
ecosystem
of
developers,
tools.
D
Auditors,
that
works
on
top
of
this
runtime,
that
that's
the
ebm
right
plenty
of
documentation,
and
so
it's
pretty
friendly
for
developers
so
and
we
have
an
excellent
player
one
runtime
one
years
so
I
I
think
that
it's
it
was
a
no-brainer
to
have
support
for
that
runtime
on
top
of
yes
and
because
it
we
we
want
to
be
as
as
compatible
as
possible.
That's
what
added
what
attic
worth
mentioning
that
we
don't
want
to
deviate
from
the
standard
match.
That's
why
also?
D
We
took
some
other
decisions
that
maybe
we
will
be
talking
later,
but
yes,
I,
think
that
that
it's
a
standard,
there's
plenty
of
developers
already
trained
in
solidity.
There's
a
lot
of
companies
that
do
audits.
Smart
contracts
on
that
runtime
there's
a
pretty
vehicle
system
out
there,
so
I
think
it
was
an
operator
to
to
support
that
on
EOS
and
knowing
that
our
player,
one
performance
is
accent
right.
B
It's
a
bigger
risk
to
not
have
evm
at
this
point,
because
evm
has
become
a
standard.
It's
got
a
very
robust
tool,
set
testing,
Frameworks,
open
source
code
and
libraries
to
be
pulled
from
things
like
open,
Zeppelin
and
all
of
that's
already
taken
care
of
as
enf.
We
don't
need
to
worry
about
any
of
the
developer
tooling.
We
just
need
to
provide
the
base
functionality
of
an
evm
runtime
and
allow
solidity
developers
to
be
able
to
expand
their
applications
to
EOS
or
just
build
it
there.
B
Not
worry
about
what
tooling
EOS
native
has
or
doesn't
have
don't
have
to
worry
about
the
EOS
resource
model
being
different.
They
work
with
all
of
the
tools
all
of
the
gas
models
that
they're
already
comfortable
with
and
end
users
as
well
they're,
already
comfortable
with
paying
gas
already
comfortable
with
metamask
wallet,
basically
opening
a
door
that
was
previously
not
open
for
years.
B
So
it
allows
us
to
do
both
I
think
for
Native
EOS.
The
business
opportunities
are
better
for
introducing
like
web
2
companies
to
enter
web
3
for
the
first
time,
because
then
they
don't
have
all
of
this
technical
debt
in
solidity
or
things
that
they
need
to
rebuild
they're,
just
building
it
from
scratch
and
using
native
Vos
from
the
first
place.
But
if
we're
talking
about
like
what
exists
today
in
the
web,
3
space
from
end
users
and
developers
meet
them
meet
them
where
they're
already
at.
B
D
Okay,
I
I
think
I
I
can
answer
some
of
the
questions
there,
but
yeah
well.
The
thing
is
that
supporting
having
ebm
support
for
Eos
is
not
only
about
the
runtime
right.
We
implemented
the
runtime
in
regular
es
smart
contract
and
where
the
ebm
is
running
there,
and
but
that's
only
one
part
of
the
project.
D
In
fact,
it's
one
part
of
the
orbital
experience
because
developers
need
a
way
to
access
the
change
data
right,
the
ebm
data,
the
the
they
need
a
way
to
submit
transactions
in
a
way
to
to
query
the
blockchain
right.
You
also
need
block
explorers
to
extract
information
from
this
runtime
to
generate
the
web.
The
website
for
developers
to
explore
so
the
the
execution
part.
The
runtime
is
one
part
of
the
project,
but
the
other
one
was
to
build
an
compatible
RPC
right,
a
full
compatible
RPC
for
for
the
ebm.
D
So
we
were,
there
was
a
C
plus
plus
node
in
the
ethereum
and
ecosystem
named
alif.
That
is
discontinued
right
now,
but
some
time
ago,
I
don't
remember
exactly
when
there's
the
come
up
a
new
specification
for
the
node
that
is
named
edicon,
which
is
thinking
in
terms
of
efficiency
and
one
of
the
implementations
it's
based
on
C
plus,
which
is
silkworm
implementation.
So,
basically,
silkworm
is
a
an
ethereum
node
under
the
specification
of
Aragon
that
we
are
using
to
support
the
RPC
compatibility.
D
Basically,
we
execute
the
transaction
inside
the
ESR
contract,
and
then
we
extract
that
transaction
using
the
state
history,
plugin
and
re-execute
that
transaction
outside
outside
nodius,
and
we
using
the
the
internal
circum
libraries
to
generate
a
database.
That's
it
accessible
to
the
RPC
node
and
to
to
serve
their
request.
So
basically
we
are.
We
are
building
blockchain
database
in
in,
under
the
circle
specification
to
serve
the
rpcl
request.
So
that
is
basically
what
the
90
of
the
third
one
code
is
being
used.
C
I
mean
I,
think
I
guess
I'll,
just
add
that
you
know
like
we're
leveraging
this
existing
code.
The
theorem
space
shoe
provide
this
critical
functional
functionality
of
therapy
C,
we're
also
I
mean
where
sulfur
and
comes
in
specifically,
rather
than
what
about
alternative
implementations
of
evm
and
ethereum
ethereum
nodes
is.
We
do
share
a
lot
of
that
that
core
that
execution
processor
in
the
two
environments-
and
that's
really
handy,
especially
as
we
make
some
tweaks
towards,
took
it
economy.
We
know
we're
running
the
exact
same
code.
C
B
I
think
a
common
theme
there's
been
with
the
evm
is
to
squeeze
as
much
performance
out
of
the
EOC
VM
as
possible
and
the
transition
through
silkworm,
which
happens
sometime
in
the
fall,
and
it
was
one
of
one
of
the
reasons
for
the
timelines.
Shifting
a
little
bit
was
to
implement
silk
room
to
to
squeeze
the
extra
compatibility
and
performance
out
of
it,
but
then
there's
other
functionality.
That's
actually
included
in
the
the
hard
Fork
that
we
had
in
September
with
the
release
of
leap
3.1
we're
now
on
3.2.
B
D
C
Well,
I
did
want
to
wrap
up
one
point
of
what
you
said
before
we
move
on
to
that
one,
because
you
did
mention
performance
and
before
we
had
this
extra,
this
additional
service
written
JavaScript
to
do
translation
from
the
blockchain
stream.
Basically,
all
the
push
transactions
first
push
TX
actions
that
are
happening
for
the
easier
one
type
contract
and
watch
it
I
think
extracted
and
then,
from
there
constructing
a
virtual
blockchain
to
be
fed
into
a
modified
together.
C
Fine,
the
cell
from
change
was
thought
as
we're
still
on
the
topic
of
silkworm
like
that
is
about
speeding
things
up
without
bottleneck
right.
So
now,
instead
of
doing
that,
we're
using
ship
to
stream
the
blocks,
the
UVM
node
is
bring
the
singles
plus.
You
know
extracting
and
processing
that
very
quickly,
so
there's
performance
improvements
there
as
well.
We
still
have
this
concept
of
virtual
blockchain.
Going
back
to
the
idea
of
we
have
two
different
environments
executing
this
code
identically.
C
Their
communication
is
this
virtual
blockchain
and
prior
in
the
prior
case,
that
was
explicitly
created
by
this
translator.
Now
it's
just
implicit,
but
it
still
exists
as
a
concept.
It's
actually
pretty
important
to
think
about,
because
everything
you
need
to
reproduce
it
in
the
second
environment
needs
to
be
captured
in
that
in
the
virtual
blockchain
stream
of
transactions,
and-
and
that
means
you
need
to
actually
be
careful
in
the
first
environment,
to
not
use
special
information
that
you
only
have
in
the
contract
like
what's
happening
on
the
EO
side
of
things.
C
B
Well,
yes,
leave
feed
into
it.
First
is
essentially
functionality,
and
this
was
never
possible
before,
because
the
maintainers
of
the
code
base
weren't
really
building
for
the
public
network,
and
this
functionality
was
see
this
being
highly
valuable.
I
think
mattius
I
think
you're
the
one
pushing
for
the
pre-compose
originally
weren't.
You
yeah.
D
B
So
we
were
actually
able
to
include
so
in
in
the
Antelope
road
map.
We
included
new
functionality
to
be
added.
That
was
mainly
to
benefit
the
EOC
VM.
It
probably
has
other
functionality
that
enables
for
Native
EOS,
but
in
the
short
term,
it
was
specifically
added
to
the
hard,
the
the
3.1
roadmap
to
get
it
as
part
of
the
hard
Fork
specifically
to
help
us
launch
the
evm.
D
Right
exactly
yes,
what
that
was
one
of
the
first
things
that
we
pushed
to
to
enter
was
this
well.
The
thing
is
that
EOS
has
this
particular
way
to
extend
the
protocol
that
you
can
you
can
well.
This
is
a
protocol
feature
where
we,
you
can
extend
the
protocol
or
add
new
features,
and
this
crypto
crypto
functions
or
crypto.
Primitives
I,
don't
remember
the
name
exactly
what
it's
doing.
It's
it's!
D
So
basically,
the
ethereum
pre-compiles
is
the
same
that
we
have
on
on
EOS
that
we
we
named
them
in
three
six,
it's
code
that
runs
on
it's
implemented
inside
the
node.
It's
part
of
the
protocol,
but
it's
it's
they're
not
running
in
a
in
a
in
evm
code,
it's
native
code.
Basically,
the
the
contracts
can
call
this
this
pre-compile.
D
C
D
I
think
that
that
was
a
great
addition,
not
only
for
the
ebm,
as
you
mentioned,
that
now
developers
of
EOS
contracts
can
also
benefit
from
using
new
new
functions.
New
intrinsic
new
crypto
Primitives.
But
it
was
kind
of
crucial
for
the
evm
runtime
to
to
be
100,
compatible
and
and
able
to
run
some
kind
of
code.
C
Yeah
also
as
a
compatibility
part,
because
I
mean
in
ethereum
that
these
are
these
prickapows.
All
that
is
just
a
function.
You
can
implement
it.
You
know
you
can
Implement
any
solidity.
If
you
wanted
to
it's
just
the
extremely
expensive
in
gas,
if
any
of
you
you've
hit
limits,
but
in
theory
you
could
do
it,
but
a
practice
you
can't
unless
it's
fast
enough,
otherwise
just
not
economically
violent.
Similar
issue
exists
with
Theos
right.
There's
there
are
are
ready
host
functions.
C
It's
still
not
as
fast
as
running
it
natively.
On
the
actual
nodio
side,
the
the
binary
compiled
binary
code
running
that's
for
you,
which
is
where
host
motions
come
in
and
for
some
things
like
the
the
of
being
128
host
functions,
they're
pretty
expensive
that
if
it's
not
provided
as
a
host
function
or
intrinsic,
and
you
try
to
implement
it
yourself,
it
may
cause
the
contract
to
run
for
too
long.
They
start
hitting
deadline
timeouts
and
that's
where
compatibility
really
comes
in,
because
the
EDM
contract
did
support
these
things
without
the
holisticians.
C
It's
just
when
you
do
when
your
contract
does
use
those
pre-compiles.
It
just
takes
a
lot
longer
and
maybe
you're
now
going
to
hit
the
the
EO
assembly
limit
and
now
a
contract
you
expect
to
work.
Ethereum
may
not
work
on
yes
because
of
just
time,
and
that's
that
was
a
big
motivation
for
us
to
consider.
Adding
the
host
functions,
support
accelerating
those
those
options
at
evm,
but
also
we
take
that
we
take
that
very
seriously
anytime.
We
change
the
protocol.
I
mean
we're
stuck
with
it
forever.
C
You
know,
like
I,
think
wax
out
of
those
function.
Just
for
that
purpose,
I
think
the
core
part
of
it
here
can
be
satisfied
with
this
modular
option.
The
the
alt
BN
128
list
of
options
not
just
allow
us
to
accelerate
the
the
pre-compiles
expected
in
EDM
space,
but
they
also
for
the
same
reason.
You
know
if
the
EVMS
in
ethereum
space
they
have
ZK
snark
verifiers
built
on
these.
We
could
also,
therefore,
be
by
making
most
functions,
have
them
supported
outside
of
the
VM
in
EOS
contracts,
so
that
provides
value
beyond
the
easy
end.
C
B
Looking
for
a
sound
bite
here,
could
you
elaborate
a
little
bit
this
intrigued
me
when
the
3.1
readme
came
out
the
the
release
notes
specifically
for
the
crypto
Primitives,
and
you
just
called
it
out,
ZK
snarks.
So
what
what
is
the
pathway
like
ZK
snarks
are
always
kind
of
being
talked
about
and
innovated
on?
It's
part
of
kind
of
like
zero
knowledge
like
how
do
I
even
explain
it,
it's
kind
of
like
being
able
to
prove
something
without
actually
showing
your
cards.
C
Yeah,
so
there's
lots
of
different
implementations
of
zero
knowledge
proofs
in
different
ways
of
doing
this.
Okay,
Starks
and
the
case
starts,
the
one
I
think
is
most
common,
because
it's
available
in
theater
is
the
ones
built
on
these
pre-compiles,
which
we
now
support
so
whether
you're
doing
through
evm
or
you
do
it
directly
on.
C
Yes,
you
now
have
the
tools
to
build
that
verifying
that
verifier
directly
and
take
advantage
of
exactly
the
same
ecosystem
of
zero
knowledge
proofs
that
exist
in
the
ethereum
space,
including
things
like
I,
mean
there's
all
kinds
of
use
cases
there
I
mean
they're.
Both
Colin
wants
a
space,
I
think
are
like
Roll-Ups,
CK,
Rogers,
first
scaling
solution,
but
I
mean
is
that
the
possibilities
are
really
endless.
C
B
A
common
word
that
keeps
coming
up
and
it
is
very
important
to
how
the
EOC
VM
was
architected-
is
compatibility.
It's
I
haven't
been
counting
every
time
it
I've
heard
it,
but
it's
a
constant
theme.
Performance
and
compatibility
were
two
of
the
key
focuses
in
in
the
roadmap
and
architecture.
So
a
strategic
engineering
decision
was
made
sometime
in
the
fall
to
go
from
previously
half
second
blocks,
which
EOS
is
fully
capable
of
it's
one
of
the
fastest
blockchains
out
there
as
a
layer
one
but
the
half
second
block
speed
the
engineering
team.
B
You
guys
essentially
made
the
Strategic
decision
to
go
with
a
one
second
block
speed.
What
led
to
that
decision
and
and
how
does
that
factor
into
compatibility
and
maybe
just
walk
everyone
through
that
thought
process,
because
I'm
sure
this
is
something
I've
already
seen
come
up
and
we'll
probably
see
more
of
it.
As
we
speak
about
this
block
speed
more.
C
Sure
the
major
effort
is
compatibility.
There
is
another
factor
which
is
that
is
competition,
okay,
so
on
one
hand
we
have
performance
in
this
case
it's
not
throughput.
The
the
house.
Second,
one
second
doesn't
make
a
difference
for
throughput.
Throughput
still
take
advantage
of
the
the
raw
speed
of
transactions
it's
like
enabled
by
EOS.
So
that's
not
the
issue
performance
here.
We're
talking
about
is
latency.
So
how
long
does
it
take?
What
really
matters
is
I?
C
Send
my
UVM
transaction
evm
transaction
out
and
assigned
with
the
metamask
and
when
do
I
get
feedback
that
it's
confirmed
on
the
blockchain,
maybe
not
irreversible,
but
at
least
on
there
and
then
also
would
be
interested
in
times
of
finality
too,
but
that's
a
whole
other
discussion
involving
is
the
finality
of
improving
that
on
yes,
but
just
getting
it
in
the
block,
so
yeah
half
second
block
times
versus
one
second
block
time.
We
say
you
know
half
a
second
latency
in
theory
right
in
practice,
it's
more
complicated
than
that,
there's
other
factors
as
well.
C
So
it's
a
competition
from
your
compatibility
and
latency
performance.
There's
caveats
to
how
much
you
gain
going
from
one.
Second,
to
half
second
of
the
performance
side,
but
what
you
do
lose
very
clearly
is
a
lot
of
the
compatibility
side,
and
that
was
the
main
motivation
to
go
with
one
second,
which
is
the
the
fastest
speed
you
can
go
without
breaking
about
it.
So
what
is
the
compatibility
issue
here?
C
You
know
like
just
there's
no
resolution
like
a
timestamp
on
ethereum
blockheader
just
doesn't
have
the
resolution.
Eos
does
for
half
seconds
for
for
milliseconds,
it's
limited
to
one
second
resolution.
So
that's
just
a
it's
just
a
limitation
of
that
protocol,
and
so,
if
we
wanted
to
have
let's
say
a
one-to-one
block
mapping
where
every
Year's
block
corresponds
to
this
I
talked
about
this
virtual
blockchain,
the
UVM
blockchain,
as
it
corresponds
to
a
virtual
Block
in
that
space.
C
That's
so
from
then
processes
and
makes
available
in
the
blocky
Splitters
saying
that
the
virtual
evm
block
height
is
X
and
that
maps
to
the
EOS
block
height
of
Y
and
the
next
one
is
X,
plus
one
mapping
to
block
y
plus
one
one
to
one
right.
So
you
get
as
fast
as
possible.
What's
the
disadvantage
of
that?
C
Actually,
you
have
one
choice:
I
think
you're,
basically
forced
to
round
how
much
it's
really
fun,
yeah
a
lot
of
choices
on
grounding
I
suppose,
but
you
can
see
the
force
of
truncate
or
round
or
do
some
sort
of
reduction
on
the
timestamp.
Because
and
yes,
you
have
say,
block
a
timestamp
whenever
it's
gonna
be
up
10.0
and
then
the
next
one
is
10.5,
the
next
one's
11.
okay,
so
you
have
two
blocks
10.0
and
10.5
to
have
to
map
to
a
whole
number.
What
do
you
do
so
you
end
up
with
two
blocks.
C
C
Maybe
nothing,
but
it's
a
risk.
It's
a
it's
a
break
in
expectations
in
in
what
quadrats
expect
that
could
could
break
some
things
and-
and
the
question
is:
is
it
worth
it
I
remember
there
wasn't
there's
another
Choice
as
well,
which
was
unacceptable
because
of
compatibility,
which
is
you
just
added
resolution,
but
then
you
break
the
op
code
of
the
timestamp,
so
that
was
like
that's
not
okay,
so
we
could
pick
the
option
that
that's
the
least
damage
to
compatibility,
which
is
just
rounding
down
and
say
that's
good
enough.
C
But
what
do
we
gain
out
of
it?
We
gain
a
half
second
Improvement
in
latency
theoretically,
but
in
practice
you're.
So
you
say:
oh
that's,
a
50
reduction
in
latency,
but
in
practice
it's
a
lot
less
than
that,
because
you're
not
counting
the
time
it
takes
for
your
transaction
to
propagate
to
the
node,
the
time
it
takes
for
it
to
show
up
in
the
block
Explorer,
you
add
all
those
it's
not
a
half.
C
Second,
it's
a
little
bit
more
and
so
the
production
in
latency,
as
a
relative
percentage,
is
actually
less,
and
so
there
is
a
call
to
be
made
of
which
one's
worth
it
is.
This
you
know
marginal
decrease
in
latency
worth
a
potential
breaking
compatibility
in
contracts,
and
we
we
thought
it's
not
and
decided
to
go
with
C
the
compatible
option.
That's
so
fast
and
one
second.
A
C
D
At
work,
so
we're
doing
sorry
just
one
one
thing
to
add:
it
was
great
explanation,
but
also
what
the
the
this
gives
us
is
is
a
way
to
decouple
both
thread
times
right,
if
eosin
in
the
future
want
to
change
the
the
block
frequency
that
won't
impact
on
the
on
the
ebl
runtime
also.
So
that's
also
one
thing
that
in
fact,
I'd
suggested
was
to
the
couple
the
the
both
runtimes
in
those
terms,
even
if
they
are
highly
yeah.
C
Yeah,
thanks
for
bringing
I
mean
I,
remember
against
that,
but
it
is
interesting.
So
maybe
you
should
say
a
few
words
on
that
that
what
I
just
said
before
is
about
you
know,
one
second
resolution
and
one
way
of
doing
that
was
to
do
a
two
to
one
mapping.
So
every
you
kind
of
take
the
transactions
block
whatever
100
and
block
101,
and
you
both
have
together
into
one
ezm
virtual
block
right
so
again,
one
second
resolution
that
was
a
perfectly
viable
option
too.
C
We
went
further
once
we
decided
okay,
we're
gonna,
you
know
we're
gonna
have
once
a
one
second
time
step
resolution
we
need.
Did
it
just
want
to
do
a
two
to
one
actually
before
we
started
off
with
ten
to
one
and
then
we're
talking
about
reducing
it
down
to
one
to
one
and
that's
what
brought
up
this
whole
discussion
of
compatibility
and
then
we're
discussing
two
to
one,
but
we
actually
own
different
approach.
C
C
They
a
lot
of
them,
actually
rely,
even
though
they
care
about
time.
They
really
want
to
block
height
as
a
means
of
creating
inflating
new
tokens,
or
something
like
that
and-
and
that
has
some
reasons
to
do
with
like
they,
they
feel
they
could
trust.
You
know
the
block
increments
more
than
the
time
increments,
because
technically
it's
actually
I
don't
know
the
reason
why,
but
for
whatever
reason,
it
seems
like
subcontracts
prefer
the
block
height,
even
though
they're
built
with
expectations
of
this
consistency
between
the
of
the
time
between
each
consecutive
block.
C
If
we,
if
we
and
so
like
the
evm
series
kind
of
abstracts,
the
underlying
EOS
layer-
and
you
don't
you
shouldn't
care
about
the
underlying
yes
layer,
you
don't
care
about
the
resources
of
the
isolator,
you
don't
care
about
CP
or
net
or
Ram.
If
it's
all
just
gas,
it's
exactly
what
evm
contract
developers
expect
so
rediding
one
another
situation
where
if
we
were
to
decide
to
change
I'm,
not
saying
we're
doing
this
right,
I,
don't
think,
there's
a
there's,
no
plan
to
lose
I!
C
Don't
think
that's
gonna
happen,
but
if
you
were
to
change
the
underlying
block
frequency
for
Eos,
let's
say
you
brought
it
down
to
250
milliseconds
or
maybe
you
made
a
variable
as
a
means
of
being
efficient,
like
you
could
have
longer
block
times
or
shorter
block
times,
depending
on
Dynamic
conditions.
Those
would
then
change
the
underlying
expectations
of
contracts
of
how
quickly
blocks
are
generated.
The
virtual
loss
is
generated
by
switching
to
time.
B
We
could
Benchmark
half
second
block
speed
against
one
second
block
speed
and
it's
either
going
to
be
the
same
or
even
slightly
better
with
the
one
second.
So
if
anyone
has
more
questions
about
that
feel
free
to
ask
in
in
the
chats,
but
I
think
you
guys
did
an
excellent
job.
Thank
you
very
much
for
articulating
that,
because
it's
much
better
than
I
could
do
all
right.
You,
you
started.
You
brought
it
up,
but
then
you
pivoted,
you
brought
up
the
instant
finality
earlier
and
I.
Think
Brandon
was
trying
to
follow
up
on
that.
C
Yeah
so
I
brought
him
up
in
the
complex
of
latency.
It's
a
question
of
what
people
care
about
so
often,
especially
on
us.
You,
you
get
a
transaction
in
a
block.
Maybe
you
have
one
block
building
on
top
of
it
within
a
second,
basically
you're,
pretty
confident
it's
going
to
stay
I
mean.
Maybe
you
don't
want
to
just
wait
for
one
confirmation,
because
if
it's
at
the
end
of
a
producer
handoff
there
might
be
some
micro
Forks
there
and
they
lose
the
block.
But
you
wait
a
second
to
get
two
blocks.
C
It's
I,
don't
know
what
how
many
nines
confidence
you
should
have,
but
you're
pretty
confident
it's
going
to
stay
there,
but
if
you're
really
concerned
it's
a
high
value
transaction,
you
really
want
to
wait
until
it's
irreverse.
There's
a
there's,
algorithmic
error.
First
finality
here,
there's
wait.
You
know
when
it's
done.
It's
confirmed
and
the
network
should
never
Fork
that.
Otherwise
that's
a.
D
C
It
consensus
basically
that
shouldn't
happen,
so
those
are
the
basically
the
two
Milestones
to
get
away
for.
You
can
either
wait.
You
know
a
few
blocks,
depending
on
your
comfort
level,
very
fast,
basically
instant,
it's
not
technically
final,
but
it's
you're
pretty
confident
it's
going
to
stay
there
or,
if
you're
faring
much
about
it,
wait
until
finality
on
EOS
right
now,
the
current
algorithm.
It
depends
on
the
number
of
block
producers
well
so
NEOS
with
21
black
producers.
It's
about
three
minutes
that
you
have
to
wait.
The
time
to
find
out.
B
C
C
So
what
isn't,
and
so
every
everything
that
builds
on
top
of
that
even
has
no
exception,
inherits
the
finality
of
its
underlying
layer
right
so
that
99.9,
whatever
percentage
confidence,
you
have
within
a
couple
seconds
that
your
transaction
is
not
going
to
be
reverted.
The
EDM
transactions
inherit
that,
because
they're
on
they're
on
the
apps
now
same
is
true
for
the
other
number
as
well
right.
C
C
You
know
a
few
seconds,
I,
don't
know
what
the
actual
numbers
we'll
see.
If
my
benchmarks
I
mean
the
the
current
number
of
shell
is
going
to
be
low
single
digit
seconds.
So
then,
basically,
it
collapse
is
more
or
less
the
the
99,
whatever
number
that
people
mostly
rely
on
now
and
the
true
finale
number
are
basically
going
to
be
well
more
or
less
clapsed,
and
you
could
just
continue
with
what
you're
expecting
that
after
a
few
seconds,
it's
final,
except
now,
it's
actually
truly
final.
B
So
the
incident
finality
the
big
the
reason
the
origin
team
is
doing
it's
because
it's
directly
correlated
with
IBC
those
high
value
transactions
you're
talking
about
whenever
you're
transacting
across
chains.
You
need
to
be
100
certain
that
things
won't
get
reversed,
because
it's
essentially
bridging
tokens
in
a
lot
of
cases,
you
could
use
the
IBC
for
any
type
of
messaging,
but
tokens
are
the
ones
that
most
people
relate
to.
So
in
that
case,
like
with
the
current
IBC
they're,
using
the
three
minute
finality,
because
it's
it's
it's
it's
important.
C
Than
that
right,
it's
it's
yeah.
So
it's
being
extra
cautious,
partly
for
the
true
finality,
even
though
it's
very
likely
to
revert,
because
if
it
does,
if
it
did
River
it's
a
whole
complicated
process,
how
would
you
entangle
that
mess
across
two
different
shades?
But
it's
more
than
that,
because
you
don't
really
know
that
the
other
chain
doesn't
really
know
what's
happening
on
the
The
Source
chain
right.
It's
relying
on
this,
this
header
validation,
to
figure
out
what
the
truth
is
of
what
occurred,
and
you
want
to
have
higher
security
there.
C
You
want
to
have
more
attestations
of
of
what
happened
so,
even
though
so
it's
a
different
kind
of
trust
model
right
because
you're,
if
you're
a
node,
a
full
node
crossing
a
blockchain,
you
know
the
blockchain's
valid.
So
the
only
question
is:
is
it
going
to
become
final
and
you
have
maybe
one
or
two
producers
signing
off
testing?
Yes,
I
commit
to
making
this
final,
but
you
don't
have
the
remaining
13
or
whatever
that
you
need
in
the
case
of
a
IVC.
C
It's
more
than
that,
because
you
only
have
two,
let's
say
two:
a
producer
signing
off
that
this
blockchain
is
going
to
become
final.
They
think,
but
also
that
is
valid.
So
it's
it's
serving
a
double
role
there,
which
means
it's
really
critical
to
actually
get
the
proper
threshold
that
you
need
before
you
actually
hacked
on
it.
B
One
we
have
a
little
text
chat
going
here
and
you
brought
up
IBC
or
you
brought
up
instant
finality
as
part
of
your
answer
and
the
real
question
was
once
I
once
the
instant
finality
is
deployed.
Does
it
have
any
direct
benefits
to
the
evm?
Would
it
be
noticeable
to
developers
to
infrastructure
providers
or
to
anyone
like?
Does
it
benefit
evm,
specifically,
so.
C
B
C
Doesn't
that's
if
that's
actually
truly
instant
Atomic?
Those
are
these
in
IBC,
there
are
two
independent
chains
that
we're
trying
to
like
connect
them,
read
them
together
in
in
the
case
of
how
we
built
ezm
it's
building
on
it's
writing
on
top
of
the
videos
chain,
and
because
of
that,
it's
the
interaction
between
them
are
immediate,
and
if
that
could
happen
within
a
single
Atomic
transaction.
B
B
Yeah,
maybe
I'm
trying
to
come
up
with
a
good
analogy
of
like
a
game
emulator
so,
like
you
think
of
EOS,
it's
like
a
PS5
and-
and
you
could
obviously
like
emulate,
like
Super
Nintendo
on
it
and
running
the
evm
inside
it.
It's
just
like.
We
have
this
super
computer
cardios
and
we
could
run
other
runtimes
in
it.
And
performance
is
an
issue
because
the
layer,
one
is
just
so
damn
performant
that
I
could
handle
any
runtime
that
we
throw
at
it.
B
You
know,
let's
keep
it,
then
one
of
the
things
we
missed
earlier
and
it
kind
of
ties
in
since
I
just
brought
up
bridging
before
we
wrap
up
here
is
the
functionality
of
the
the
native
Bridge.
One
of
the
the
features
that
I
thought
was
really
important
was
one
of
the
points
of
friction.
There's
there's
been
a
couple
of
points
of
friction
within
EOS
since
the
beginning
that
we're
working
on
through
the
Coalition
through
the
NF
as
far
as
native
EOS
and
that's
account
creation.
B
B
So
one
of
the
the
most
important
things
I.
Think
of
this
bridge
functionality
is
that
we
we
built
it
in
a
way
that
allows
you
to
just
totally
skip
touching
the
native
EOS
or
a
native
EOS
wallet
at
all,
because
you're
able
to
just
withdraw
tokens
from
a
centralized
exchange
straight
to
the
evm
do
either
of
you
guys
want
to
elaborate
on
on
how
that
actually
happens.
C
Sure
sure
yeah,
so
that
was
a
very
important
goal
with
this
this
bridge,
because
that
really
want
to
make
it
seamless
for
someone,
but
it
kind
of
goes
lots
of
compatibility
of
expectations
right
like
so.
A
lot
expects
to
go
on
their
exchange,
withdraw
the
token
of
interest.
You
know,
maybe
that's
East,
if
they're
going
to
ethereum
blockchain,
but
in
this
case
EOS,
but
they
want
to
withdraw
it
directly
to
their
accounts
that
they
created
in
metamask
for
free
without
having
to
create
a
you
know,
created
EOS
accounting
pay
for
that
cost
right.
C
So
the
the
ethereum
side.
This
is
this
is
like
straightforward.
You
just
pay
the
gas
to
cover
the
cost,
because
there's
always
costs.
There's
cost
on
your
screen,
account
which
costs
on
ethereum
to
effectively
create
an
account
by
sending
tokens
to
it
and
and
the
cost
is
paid
for
in
gas.
So
we
there
are
more
advanced
mechanisms
that
can
come
later
post
on
VP
for
people
who
want
to
kind
of
pay
for
the
actual
gas
costs
and
not
anymore,
but
for
convenience.
We'll
be
built
for
m
p.
C
So
remember
here,
there's
two
computational
costs
in
the
in
the
case
of
this.
This
Ingress
this
this
transfer
of
EOS
into
the
UVM
environment,
one
is
the
EOS
computational
cost
of
CPU
and
that
which
The
Exchange
is
already
covering
right,
whether
you're
sending
that
to
your
EOS
account
or
you're,
sending
out
to
your
evm
account
it's
a
transaction,
an
answer
of
transaction,
that's
as
CPU
and
net
they
have
to
pay
in.
C
You
know
that
you
pay
through
Power,
essentially
The
Exchange
is
covering
that,
but
because
it's
a
its
destination
is
an
evm
account.
There's
an
additional
evm
gas
cost.
That's
there
that
the
exchange
knows
nothing
about,
whereas
they
don't
know
where
they're
sending
it
to
they're,
just
sending
it
to
an
account
name
with
a
memo.
It's
the
same
interface
they're
used
to.
So
we
need
to
cover
that
cost
somehow,
and
so
what
we've
done
is
revalued
this.
C
B
Yeah,
so
the
whole
friction
with
the
NEOS
account
it's
it's
being
it's
it's
being
worked
on,
but
this
is
like
a
very
short-term
solution
that
literally
April
14th
you'll
now
be
able
to
withdraw
EOS
from
any
centralized
exchange
to
an
evm
account
by
simply
putting
an
ethereum
public
key
in
your
memo
and
sending
it
to
a
privileged
account.
I
I,
don't
know
if
the
account
name
has
been
determined
yet,
but
eosio
dot,
something
owned
by
the
block
producers.
C
C
The
evm
contract
is
now
privileged,
meaning
that
in
theory
someone
else
could
have
so
anyone
could
actually
launch
this
on
their
own
account
as
a
separate
evm
runtime,
but
it's
privilege
in
the
sense
where
it's
sort
of
a
special
in
the
sense
in
the
same
says
that
say
the
esio
token
contract
is
especially
where
we
we're
going
to
create
a
name.
The
reserve
name
vocio
dot
in
this
case,
esi.evm
to
host
the
contract,
and
it's
going
to
be
ultimately
owned
by
the
black
producers.
Just
like
any
of
the
other
asio
accounts.
B
Yeah
I
mentioned
the
the
friction
that
that
we're
solving
for
with
EOC
VM
the
other
one's
resources,
so
esa's
unique
model
with
the
power
up
and
and
the
staking
for
resources
that
we
previously
had,
whereas
the
current
web
3
users
as
the
space
stands
today,
most
people
are
used
to
paying
a
gas
fee
for
transactions.
It's
really
just
another
opportunity
to
meet
people
where
they're
at
this
is
what
they're
used
to
we're,
giving
them.
B
B
Superpowers
is
the
fact
that
it
came
out
in
2017
at
a
great
time,
has
over
300
exchange
listings
and
we're
able
to
leverage
all
of
that
for
the
evm,
whereas
if
we
went
the
original
route
with
with
the
external
token
and
the
external
team,
and
all
of
that,
they
would
have
had
to
have
started
from
Ground
Zero
with
the
exchange
listings
and
from
what
I
understand
it's
very
difficult
to
get
tokens
listed
on
new
exchanges.
So
we
avoid
all
of
that
get
to
Leverage
one
of
the
EOS
superpowers.
This.
A
Has
been
extremely
informative
at
times
daunting
to
try
and
comprehend
and
follow,
but
I
was.
It
was
very,
very
good
to
to
learn
more
about
the
EOS
evm
thanks
so
much
Matthias
and
Rag
and
Zach
for
shedding
some
more
light
on
this.
This
exciting
development,
if
folks
yeah,
thanks
for
being
here
to
see
you
again
sometime.
B
I
hope
everyone
watching
or
listening
got
a
lot
of
value
out
of
this
I
think
we
packed
as
much
information
as
we
possibly
could
in
an
hour
or
so
of
your
time.
Okay,
on
enterprising
developers
are
listening.
Please
look
into
the
direct
Grant
framework
or
a
new
season
of
pomelo
has
just
begun.
Eoc
VM
projects
are
eligible
for
all
of
the
same
funding,
resources
that
are
available
to
building
on
Native
EOS.