►
From YouTube: NEAR EVM Working Group Update [2021-01-15]
Description
Follow the latest from NEAR Protocol on,
Website: https://nearprotocol.com/
Discord: https://near.ai/discord
Medium: https://near.ai/medium
Twitter: https://near.ai/twitter
GitHub: https://near.ai/github
#WhiteboardSeries #Blockchain #FutureIsNEAR
A
So
so
it
or
it
appears
that,
because
of
some
strange
reason,
zoom
is
not
working
correctly
on
my
computer.
So
if
you
are
able
to
to
leave
this
meeting
and
share
the
stuff,
then
it
would
be
good.
Okay,.
B
Hold
on,
let
me
show
the
screen:
oh
host,
disabled
screenshot
yeah.
I'm.
B
Okay,
so
today
welcome
everybody.
We
have
a
little
bit
more
people
than
usual
welcome.
Welcome
to
the
evm
working
groups,
weekly
public
sync
today,
we're
gonna
do
a
little
bit
something
different
than
than
usual.
Normally
we
give
team
team,
member
updates
and
like
and
this
time
those
will
be
after
after
a
meeting
on
github.
B
So
we
have
a
weekly
update
discussion
which
you
can
find
in
the
near
near
core
repository
and
over
there
the
youtube
link
will
be
posted.
Somebody
can
put
it
in
there
as
soon
as
they
notice
it
on
youtube
and
the
agenda
today.
Is
this
so
our
current
goal
that
we
are
working
towards
and
let
me
edit
and
talk
at
the
same
time
so
right
now,
we
we
are
planning
our
q1
of
objectives
and
key
results,
and
we
are
staffing,
the
team
and
allocating
the
work.
B
So
that's
the
near
term,
near
term
objective
and
the
midterm
objective
is
our
deployment
to
testnet,
which
we'll
talk
about
in
a
moment
alex,
and
I
prepared
a
short
presentation
in
order
to
help
with
the
okr
review
and
running.
B
B
So
in
the
last
quarter
we
had
three
okrs
defined
usability,
evm
and
updated
uvm
and
destiny
deployment.
We
didn't
quite
make
all
of
these
okrs.
B
The
one
we
did
based
on
was
usability,
and
thanks
mike
especially
over
here
this.
This
is
in
pretty
good
shape.
We
have
defined
three
key
results
in
briefly,
internal
tooling
should
should
be
updated
to
support
the
evm,
and
that
involves
a
number
of
repositories,
including
the
cli
at
the
javascript
api,
the
web3
provider
and
that's
all
pretty
much
in
nice
shape.
We
can
always
do
more,
but
when
we
created
this
earlier
this
week
we
patted
ourselves
on
the
back
on
that
one.
B
There
are
also
substantial
documentation
updates.
We
have,
I
believe,
something
like.
Let's
look
actually
here.
B
We
have
something
like
10
different
pages
added
to
the
documentation.
I
not
everything
is
being
published.
Yet
okay
of
you
are
still
pending,
but
there
will
be
a
lot
of
moral
stuff
here
in
the
ethereum
compatibility
section
on
the
develop
in
the
mailbox,
and
this
is
all
currently
targeting
beta
nets,
because
the
bm
is
deployed
on
betterment.
B
What
we
did
less
well
is
the
last
key
result,
which
was
perhaps
a
little
bit
ill-defined
as
in
it's
about
truffle
support
for
existing
evm
projects,
and
in
this
case
we
didn't
really
define
what
what
we
should
use
as
the
metric
here
and
run
out
of
time
in
measuring
something
useful
on
this,
so
I've
assigned
as
a
25
grade
over
here,
because
I
believe
they're
in
in
okay
shape.
So
this
conservative
estimate,
but
we
haven't,
we
have
any
good
measurements
any
on
the
metric.
B
We
have
a
good
metric
and
we
have
good
measurements
on
it.
So
I
score
as
low
on
that
now
on
the
next
objective.
There
was
the
updated
evm
that
thing
first
of
all
involved
updating
us
from
the
old
old
parity
ethereum
beta
release
that
we
were
using
at
the
beginning
of
the
quarter
to
do
something
more
recent,
which
means
this
is
open.
Ethereum.
B
We
had
planned
to
upgrade
to
open
ethereum
three,
but
we
backtracked
on
that
given,
given
that
it's
a
new
new
code
base
and
it
didn't
have
a
lot
of
deployment
yet
so
we
we
did
a
number
of
upgrades
all
the
way
until
272,
which
is
where
we
are
currently.
So
that's
the
last
part
of
the
ethereum
release
just
before
the
open
ethereum
team
took
over
now.
Since
then,
we've
opened
discussions
with
the
open,
ethereum
team.
B
We
have
more
insight
into
the
roadmaps
and
and
the
procedures
and
quality
assurance
and
whatnot,
and
we
are
planning
to
to
upgrade
soon
to
open,
ethereum,
three
three
two
actually,
which
was
portable
in
hard
fork.
B
So
in
any
case
we
for
the
adjusted
objective,
we
did
dual
network.
The
second
key
key
result
was
meta
transaction
support,
and
on
this
I
believe
that
we
can
create
ourselves
a
hundred
percent,
a
lot
of
work
by
bo
mike
and
elia
by
the
way.
If
anybody
disagrees,
I
feel
free
to
speak
up
and
the
last
key
result
involved
benchmarking.
B
This
was
a
little
bit
ill
defined
and
we
haven't
really
properly
begun
this
work,
and
so
we're
gonna
have
to
put
it
on
there.
Then
we
had
the
aspirational
objective,
which
we
did
not
achieve
this.
This
last
quarter
in,
in
other
words,
a
deployment
destination,
and
this
this
we
have
to
get
done
this
quarter.
B
It
will
not
be
aspirational
for
this
quarter,
but
we
did
do
many
prerequisite
things
not
not
all
of
them
captured
here
in
in
the
key
results.
Some
things
we
did
complete
voted
great
work
on
the
gas
fees.
B
B
However,
we
would
expect
to
reach
this
target
just
need
to
measure
that
and
yeah
we
didn't
deploy
to
this
match
in
the
last
quarter,
so
that
was
the
last
quarter
and
we
learned
many
things
from
this.
This
okr
review,
which
has
been
ongoing
all
week,
namely
that
we
had
somewhat
ill-defined
okrs
and
we
had
not
the
not
the
best
metrics
on
all
of
them.
B
B
I
believe
we
are
getting
some
some
substantial
alignment
now
and
one
of
the
last
very
contentious
issues.
It's
not
a
simple,
simple
answer:
there
are
many
traders
to
consider
and
people
have
somewhat
maybe
entrenched
in
some
cases
and
in
other
cases
heated
views
has
been
the
choice
of
the
base.
Token
for
for
the
evm,
so
there's
a
whole
discussion
about
this
on
the
forum,
but
those
interested
can
check
that
out.
B
Let's
load
it
up
here
long
thread
with
20
20
posts.
So
if
somebody
has
an
interest
in
that
question,
that's
where
you
should
look
and
perhaps
participate
now
as
it
currently
stands,
so
maybe
to
introduce
this
issue
a
little
bit
for
those
who
haven't
read
the
forum
post
as
it
currently
stands,
the
the
near
evm
is
using
nero
as
in
the
near
token,
as
the
base
base
currency
base
token
of
of
the
evm
as
well.
B
This
has
a
lot
of
benefits,
in
terms
of,
for
example,
being
able
to
call
out
from
the
evm
into
into
the
near
virtual
machine
based
runtime.
B
It
has
a
lot
of
elegance
and
simplicity
to
it,
and
it
has
been
a
popular
choice
in
other
evm
compatible
exchange.
They
practically
well.
Actually,
every
single
one
I've
looked
at,
they
they've
done
the
same.
They
they've
adopted
or
created
a
utility
token
and
in
some
cases,
also
use
the
utility
token
for
fundraising,
as
in
an
ico
of
that
utility
token,
for
example,
moon
base
with
glimmer.
B
However,
there
is
a
there
is
a
contrary
case
to
be
made,
and
that
case
is
that
from
a
business
perspective,
it
would
be
highly
preferable
that
we
would
be
really
genuinely
100
compatible
with
ethereum
I've
a
little
bit
unpacked
this
here
and
on
the
forum
in
terms
of
what
happens
if
we
wanted
to
port
something
like
uniswap
say
so,
just
looking
at
the
uniform
codebase
digging
into
it,
you
can
find
stop
talking
about
the
the
ui
the
dac
itself,
not
necessarily
the
contracts
digging
into
it.
B
You
can
find
tons
of
places
where
f
is
hard
coded
as
an
assumption,
as
in
an
actual
text
string
as
but
also
fundamentally
assuming
that
we're
operating
on
a
chain
that
has
f
so,
for
example,
any
any
any
dap
which
is
meant
just
for
ethereum,
as
in
it
hasn't
been
ported
to
a
wide
range
of
evm
chains,
and
that
would
be
most
of
the
apps
right
now.
B
B
B
Adapts
have
currently
been
coded
with
that
in
mind.
All
of
them
have
assumed
a
simple
view
of
the
world
as
in
they
are
running
on
ethereum.
Why
should
they
do
anything?
B
And-
and
so
that's
that's
one-
one
part
of
the
problem
that
porting
something
like
unisrap
right
now
would
mean
making
it
run
on
the
near
evm
would
mean
forking
a
whole
bunch
of
repos
at
least
two
for
the
user
interface
and
potentially
potentially
more.
We
haven't
followed
the
whole
dependency
hierarchy
yet
and
maintaining
a
long-standing
or
indeed
indefinite
fork.
B
That
would
do
a
search
and
replace
of
of
all
strings
where
we
or
they
hard
code.
If
it
would
change
all
the
price
oracles,
it
would
deal
with
all
the
code
and
there's
a
lot
of
it.
That
assumes
that
there's
an
easy
conversion
to
be
done
between
s
and
w
s
and
probably
more
things
that
we
haven't
considered,
but
those
for
starters-
and
this
would
need
to
be
done
for
every
single
dap,
pretty
much
that
you
would
want
to
port
to
the
near
uvm.
That's
not
a
good
proposition.
B
B
So,
let's
move
a
little
forward
in
order
for
us
to
be
able
to
use
f
as
the
base
token,
we
need
to
be
able
to
bring
it
over,
as
in
one
one
f
on
on
the
near
evm
should
represent
in
some
form
an
f
on
the
f1
chain
and
some
some
chains,
for
example,
define
a
smart
chain.
They
call
this
updated
token,
which
might
make
sense
as
nomenclature
we've
been
calling
it
bridge
bridge
assets,
as
do
some
other
other
chains.
B
A
This
is
not
final.
We
are
just
like
thinking
of
how
this
can
be
implemented.
We
were
discussing
it
with
eugene
yesterday,
so
this
is
what
you
can
see
here.
So
on
the
slide,
you
can
see
the
left
hand
side
with
which,
which
represents
the
ethereum
blockchain
right
hand,
side
which
has,
which
is
the
near
blockchain.
A
The
blue
rectangle
is
the
bridge
infrastructure
that
is
currently
there
currently
deployed,
and
it
has
like
the
it
is.
It
is
common
for
all
of
the
connectors
that
are
using
this.
The
infrastructure
consists
of
several
parts,
so
there
are
some
smart
contracts
on
both
blockchains
that
are
light
clients
and
their
approvers.
A
The
facts
that
something
has
happened
on
on
the
other
blockchain
and
there
are
in
between
blockry
layers
and
these
these
are
just
the
services
that
are
sending
transactions
to
to
light
clients
with
the
information
about
the
other
chain.
A
Now
this
bridge
infrastructure
is
used
by
by
multiple
connectors
and
people
are,
and
developers
are
able
to
develop
their
own
connectors
and
to
bridge
their
own
information.
A
So
on
the
slide,
there
is
a
principle
scheme
for
uploading
of
f
for
bridging
f
to
near
f
or
nf.
So
so
it
works
the
following
way.
A
A
Then,
without
any
user,
oh
without
any
interaction
with
the
users
block
relayers
are
submitting
a
block
into
the
ethereum
light
client
on
near
side.
It
gets
verified.
There
is
some
kind
of
finality
period
that
we
need
to
wait
for
this
block
to
be
to
be
able
to
be
used.
So
we
can
use
this
block
to
prove
the
events
that
happened
there.
Currently,
this
it
is
about
25
blocks.
A
So
so
it's
about
seven
minutes,
then
the
real
layer
or
actually,
which
can
be
in
any
account
in
the
near
native
blockchain,
so
near
native
account
is
scheduling.
A
finalizing
transaction
that
goes
to
one
of
the
functions
or
one
of
the
methods
of
the
evm
recompile
within
this
transaction.
A
Relayer
is
submitting
the
information
about
the
transaction
that
happened
on
the
ethereum
blockchain.
It
actually
submits
the
proof
or
this
this
the
proof
of
the
event
that
was
emitted
on
the
ethereum
blockchain
evm
per
compile
checks
the
proofs
by
calling
approver
contracts
which
actually
literally
call
the
ethereum
like
client
to
check
the
the
eth
hash
and
stuff
like
that
and
in
the
end,
obviously
everything
gets
back
to
the
evm
precompile.
If
everything
is
correct,
even
pre-compile
means
near
f
and
deposits
it
to
the
user
account.
A
There
are
multiple
important
thing
in
this
scheme,
so,
first
of
all,
there
is
only
a
single
user
transaction
required
and
this
is
a
necessity
of
this
scheme,
because
if
a
user,
an
ethereum
user,
is
not
having
a
near
account,
he
is
not
able
to
schedule
any
call
on
the
near
side.
Actually,
so
that's
why
there
should
be
somebody
who
who
is
scheduling
this
call
for
him
and
that's
why
this
setup
should
be,
should
look
like
this,
so
only
single
user
transaction
happening
on
the
ethereum
site.
A
Potentially,
we
can
split
evm,
pre-compile
and
and
create
an
f
minter
smart
contract
there,
which
is
going
to
just
mint
and
burn
nf,
and
we
can
do
this
for
for
the
separation
of
concerns.
A
So
so
we
are
not
going
to
compose
everything
into
single
ev
and
precompile,
but
we
need
to
assess
whether
we
need
to
do
it,
especially
it
depends
on
the
on
the
on
the
other
direction
of
the
transfer.
You
will
see
it
on
the
next
slide.
A
Second,
another
thing
is
that
the
re
layer,
the
actual,
so
you
can
see
here
two
different
types
of
three
layers.
The
first
one
are
inside
of
the
bridge
infrastructure
and
we
are
not
talking
right
now
about
them.
They
are
just
working
and
we
assume
that
everything
is
good
on
that
side.
A
Now
we
need
to
have
a
real
layer
that
is
going
to
finalize
the
user
transfer,
and
this
relayer
needs
to
have
an
account
in
evm
and
near
evm
and
and
just
because
this
relayer
is
going
to
provide
in
this
step,
number
four,
his
account
or
his
address
in
order
to
be
renumerated,
because
in
the
first
transaction
that
user
schedules
on
the
ethereum
blockchain,
he
specifies
that
there
is
a
certain
amount
of
nf
that
is
going
to
be
transferred
to
the
party
that
is
going
to
relay
the
finalization
transaction.
A
Yeah
and
the
last
thing
that
we
need
to
figure
out
how
to
do
as
you.
As
you
see
here.
Evm
is
a
pre-compiled
smart
contract,
so
it
is
going
to
be
there
at
the
very
start
of
the
network.
While
the
bridge
is
designed
the
way
that
prover
and
ethereum
like
clients
are
just
ordinary
smart
contracts.
A
They
are
not
there
during
the
start,
but
when
executing
the
finalization
transaction,
avm
compile
need
to
call
prover,
which
means
that
near
a
and
then
evm
need
to
know
where,
where
this
contract
is
located
and
that's
why
we
need
to
have
an
ability
to
to
to
say
to
evm
where
this,
where
the
this
bridge
is
located.
So
this
is
something
that
we
still
need
to
figure
out
how
to
do,
but
in
general
yeah.
A
Probably
it
can
be
done
so,
oh
good,
at
least
with
the
full
access
key
and
then
like
deleting
this
full
access
key
once
the
bridge
is
deployed.
A
So
this
is
the
principle
scheme
from
from
my
points
of
view.
Personally,
it
is
really
good
just
because
a
user
can
for
for
the
user.
From
the
user
point
of
view,
the
bridging
transaction
is
atomic,
so
you
schedule
one
transaction
and
then
it
just
happens
and
also
it
is
secure,
because
you
can
see
that
there
is
no
way.
A
f
is
not
landing
on
any
account
on
near,
except
for
the
user,
except
for
the
user
account.
A
Okay,
and
if
we
go,
if
we,
if
we
take
a
look
at
transfer
back,
it
is
a
little
bit
more
complicated
because,
like
we
have,
we
have
now
two
parts.
Now
the
user
has
an
account
on
near
side
and
the
transfer
obviously
needs
to
be
started
there.
So
user
need
to
send
a
new
transaction,
but
unfortunately
he
is
not
able
to
send
a
near
a
loan
transaction.
A
So
he
needs
to
call
a
method
of
the
evm
recompile
to
withdraw
some
funds,
but
unfortunately,
he's
not
able
to
do
this,
because
what
what
we
expect
from
user
is
to
sign
normal
ethereum
transactions,
which
are
not
the
new
transactions,
so
somebody
so
so
what
what?
What
he
can
do
is
to
sign
something,
and
then
every
layer
needs
to
be
there
to
pay
near
fees
for
for
the
user
and
and
and
and
on
the
seconds.
A
Yes,
so
so
relayer
then
relays
the
withdrawal
transaction
to
evm
precompile,
a
pre-compiled
contract
is
able
to
analyze
it
and
and
produce
the
and
and
burn
some
some
nf
from
the
user
account
and
produce
what
is
called
execution
outcome.
This
is
something
this
is
something
that
it
can
be
treated
similarly
to
the
events
in
ethereum.
A
This
execution
outcome
is,
is
related
to
near
light
client
on
the
ethereum
side,
and
then
the
user
need
to
call
on
the
ethereum
side,
the
finalization
transaction
number
four,
which
is
like
literally
withdrawal,
and
it
works
absolutely
the
same
way.
How
how
on
the
near
side,
so
f,
locker
checks,
the
proof
from
the
prover,
a
smart
contract
deployed
inside
of
the
bridge
infrastructure
and
if
everything's,
okay,
atlocker
releases
some
f
and
sends
it
to
the
user
account.
A
A
This
scheme
can
be
upgraded
with
the
relayer
approach,
absolutely
the
same
way
how
we
have
had
on
the
previous
slide.
So
there
there
is
every
layer
on
the
ethereum
side
that
is
incentivized
with
some
f
to
be
able
to
to
to
create
a
withdrawal
transaction.
So
this
is
possible.
We
can
do
it,
but
it
is
not
necessary,
like
in
the
in
the
previous
case,
the
near
side.
A
Relaying
is
incentivized
by
by
the
fact
that,
within
this
evm
pre-compiled
transaction
execution,
actually
the
part
of
the
fonts
is
transferred
again
to
the
relayer
account
inside
of
near
evm,
so
principle
scheme
is
there
for
sure
we
need
to
implement
this.
A
There
is
a
hard
connection
that
is
going
to
be
introduced
in
between
near
evm,
precompile
and
the
bridge,
but
this
is
something
that,
unfortunately,
should
be
done
in
this
case.
B
All
right,
thanks
alex,
I
think
we
need
to
perhaps
a
little
bit
simplify
this.
This
whole
section
of
the
presentation
next
time
present
it
and
take
the
technical
details
after,
but
in
any
case,
thank
you,
everybody
for
holding
all
your
questions.
Let's
deal
with
those
after
we
finish
the
okr
planning,
so
we
have
considered
what
we
ought
to
do
this
quarter
and
what
we
can
do
and
alex,
and
I
think
it
looks
something
like
this.
B
B
We
have
done
a
lot
of
work
in
the
last
quarter,
which
actually
wasn't
captured
in
the
original
key
results,
because
we
adjusted
the
course
along
the
way
on
we've
done
our
work
on
having
an
rpc
endpoint
a
website
compatible
rpc
endpoint,
which
means
that
for
an
ethereum
developer
to
be
able
to
deploy
his
projects
is
ultimately
just
a
matter
of
changing
his
endpoint
url
and
that's
beautiful.
B
That's
how
simple
it
needs
to
be
so
we
haven't
defined
yet
the
metric
here.
But
we
would
like
something
something
like
when
we
work
with
partners
they'll
be
able
to
deploy
their
projects.
Community
members
will
be
able
to
deploy
their
projects
easily,
starting
with
a
link
to
the
onboarding
documentation
for
how
to
do
all
this,
which
should
have
been
video,
tutorials
and
the
like
as
well,
and
go
from
zero
to
hey.
It
works
in
about
30
minutes
in
the.
B
Of
cases
you
know
for
at
the
majority
of
cases
for
the
user
experience
somebody
who's,
not
a
developer,
but
the
one
one
million
plus
people
who
use
metamask
should
be
able
to
send
a
transaction
to
the
evm
in
a
fairly
short
order,
something
like
10
minutes,
given
that
it
takes,
as
alex
said,
seven
minutes
to
transfer
the
assets
over
the
bridge.
B
B
B
We
do
want
to
start
piping,
the
load
from
s1,
both
both
the
various
destinations
and,
ultimately,
the
magnet
into
the
evm
to
make
sure
that
we
can
handle
that
load
so
making
sure
we
can
will
be
something
something
very
important.
This
quarter
before
we
can
consider
moving
forward
with
deployments
and
ultimately,
we
need
to
put
up
a
grand
prize
for
come
and
hack
us
do
your
best.
B
B
It
doesn't
mean
that
we
don't
run
these
things
for
longer,
but
if
we
can,
if
we
can
have
24
hours
of
piping
the
load
from
something
something
which
can
be
called
ethereum,
whether
it's
a
destiny
domain
net,
then
that's
probably
a
pretty
good
indication
that
we're
in
good
shape,
even
if
we
break
on
the
second
day
and
for
security,
of
course.
B
Ultimately,
this
bounty
should
be
extended
for
as
long
as
seems
useful,
but
if
you
have
a
couple
couple
of
weeks
of
of
people
enough
people,
so
that's
question
for
the
metrics
enough
people
attempting
to
break
us
and-
and
we
haven't
suffered
a
major
setback,
then
things
things,
look
pretty
okay,.
B
That
was
the
first
object
now.
The
second
objective
is,
let's
say,
a
cross
cross
theme
objective,
as
in
we'll
want
to
collaborate
with
business
development,
on
partner
support
and
very
quickly,
some
and
other
teams,
and
with
the
bridge
team
on
making
sure
we
can
actually
transfer
f
and
erc20
tokens.
B
So
this
is
pretty
straightforward.
Most
of
our
partners
should
succeed,
importing
or
maybe
it's
better
to
call
it
deploying,
given
that
we
don't
really
want
it
to
be
a
porting
effort.
We
want
it
to
be
just
another
deployment,
so
they
should
be
able
to
deploy
their
apps
to
testnets
once
that's
all
all
up
and
going,
and
they
should
certainly
be
able
to
bring
the
liquidity
over
once
once
you
get
that
now,
the
of
course
the
third
objective
has
to
be
that
we
go
to
maintenance
now
this.
B
So
we
will
we
will
work
hard
and
I
don't
like
crazy
onboard
everybody,
but
it's
not
very
likely
this
quarter.
I
do
think
it
can
be
soon
after
this
quarter,
but
unlikely
this
order.
So
here
we
don't
have
as
long
of
a
list
of
key
results
as
on
the
test
net,
because
most
of
those
things
when
they're
done
for
testnet
they're
done
for
mainnet
as
well,
for
example,
evm
compatibility.
B
You
know
when
we
when
we
have
achieved
the
berlin
hard
fork
compatibility,
it
doesn't
need
to
be
repeated
here
so,
in
other
words,
to
go
to
mainnet
right
now.
The
the
list
would
look
like
something
something
like
a
bug:
bash,
hackathon,
a
stress
test
and
then,
ultimately,
the
consensus
problem.
Getting
all
the
validators
to
accreta
is
a
good
idea,
which
is
probably
a
project
onto
itself.
B
This
is
what
the
team
looks
like
currently,
so
we
have
four
people
permanently
assigned
one
of
them
beginning
next
monday,
and
we
have
for
for
other
people
in
supporting
roles,
and
we
we
appreciate
you
very
much.
We
need
all
the
support
we
can
get
thanks
mike
thanks,
elia
and
thanks
thank
you
eugene.
B
So
we
are
hiring
for
both
the
bridge
and
evm
teams
and
we
also
pay
a
decent
finder's
fee.
So
talk
to
me
and
alex,
if,
if
you
know
somebody
who
would
be
helpful
to
this
endeavors
okay,
so
let's
take
some
questions.
D
Just
a
just
a
quick
question,
so
in
ethereum
I
think
the
gas
ceiling
is
10
million
right
now
in
in
our
edm.
I'm
not
exactly
sure
how
high
we're
going
to
allow
it
to
go
because
of
like
the
speed
of
the
speed
of
the
execution
of
the
computation
and
then
like
affecting
like
block
production,
because
we
have.
We
have
these
one-second
blocks
and
then
we
have
other
overhead
like
networking
and
stuff.
So
I'm
not
sure
if
anyone
can
further
elaborate
on
the
performance.
C
C
I
know
you,
you
faced
an
issue
that
you
run
out
of
evm
gas
just
because
of
this
limit,
so
I'm
not
sure
how
to
address
it.
So
if
it's
an
issue,
we
may
consider
increasing
this
limit
for
edm.
B
Evm
all
right-
and
you
wanted
to
ask
something
as
well.
C
C
C
That
will
allow
us
to
essentially
use
both
balances
and
later
issue
transactions
from
evm
using
your
gas.
So
you
don't
need
to
convert
knees
to
too
near
on
the
chain
or
pre-compile
level
or
relight
only
layers.
So
you
will
be
able
to
communicate
directly
with
rpc
nodes
and
issue
your
transactions
for
this.
You
will
need
to
have
near
balance,
so
it
has
benefits
in
the
longer
term,
because
then
boarding
can
be
done
same
way
as
you
do
right
now.
C
You
you
just
like
transfer
your
ease
from
ethereum
and
start
using
its
relayer
network,
but
then
once
you,
for
example,
want
to
use
local
transactions.
You
convert
your
is
to
native
near
straight
on
evm.
Let's
say
there
is
like
modified
unison
that
converts
to
wrap
here
on
the
vm,
and
then
you
can
convert
this
or
up
near
to
native
near
on
the
vm
as
well.
So
you
don't
need
to
leave
evm
chart
in
order
to
convert
east
near
and
same
way
you
can
onboard
from
near
to
evm
you
you
have
your
native
mirror.
C
You
dab
like
to
dump
the
turn
evm
account,
and
then
you
can
issue
conversion
to
to
acquire
ease,
so
so
native
building
will
be
able
to
do
without
without
real
air
network
and
yeah
go
ahead.
Yeah.
I'm.
B
D
Yeah,
I'm
I
mean
one
is
like
I'm
pretty
against
actually
adding
ethereum
transactions
into
the
kind
of
chain
for
like
multiple
reasons,
but
like
all
of
our
like,
underneath.
D
D
This
is
like
that
premise
itself
is
seems
a
little
bit
weird
to
me
and
and
like
before,
making
adjustments
to
to
handle
that
we
should
like
decide
if,
if
we
ever
will
actually
want
this,
but
specifically
like
on
on
the
kind
of
implementation
side
of
this,
I
don't
think
we
actually
need
to
have
dual
balances.
Instead,
we
should
just
literally
have
a
wrap
near
erc20
that
is
at
the
specific
address,
and
that,
like
this
is
how
generally
it
works,
and
so
you
know
all
the
stuff
can
be
done
pretty
much
using
that.
C
D
You
need
you
need
any
like
hard
coding
inside
evm
pretty
much
for
that.
C
No,
I
I
think
it's
pretty
critical
that
you,
you
can
issue
your
own
transaction,
because
relying
always
on
relayer
network
will
not
work
in
a
longer
term,
so
you
and
like
having
separate
account,
is
also
a
problematic
like
people
will
never
want
to
like
leave
and
if
you
have
the
ability
to
issue
transactions
from
metamask
without
real
air
network
that
goes
straight
to
our
pc.
Eventually,
then,.
C
So
the
you
you
can
use
your
own
validator,
I'm
saying
without
real
air
network,
and
you
don't
need
to
have
native
near
account,
so
evm
account
should
be
enough.
Regarding
the
implementation
details
of
this,
it
actually
noticed
complicated,
because
you'll
still
need
to
eventually
do
the
sign
transaction
upgrade,
which
means
we'll
support
a
versioned
version
of
sign
transaction
and
just
adding
another
enum
there
that
is
evm
function,
call
is
fairly
simple
so
and
as
for
validation
of
this,
you
just
do
the
same
validation.
We
do
these
receipts
before
the
block
starts.
D
No,
no!
No!
No!
No!
No!
I
don't.
I
don't
understand
what
you're
saying,
because
to
to
to
for
metamask
to
sign
a
transaction
needs
to
be
an
ethereum
transaction,
so
our
nodes
need
to
be
able
to
accept
only
ethereum
transaction
signed
bytes,
not
not
a
signed
transaction,
not
a
near
signed
transaction
but
yeah.
C
That's
what
I'm
saying
we
can
accept
such
transaction
and
just
drop
it
into
signed
ethereum
transaction.
C
C
Modify
the
rpc
because
we're
doing
the
we'll
need
to.
D
B
Let's
talk
about
that
after
afterwards,
it
needs
a
considerable
depth.
There's
another
question:
we
should
also
find
time
to
talk
about
with
with
the
both
of
you
guys,
certainly
soon,
which
is
the
question
about
how
we're
going
to
account
for
evm
storage,
which
already
came
up
in
the
last
week.
I
said
we
had.
We
had
a
situation
where
the
better
net
evm
couldn't
deploy
more
contracts,
given
that
it
didn't
have
enough
funds
to
handle
the
storage.
B
I
think
it
had
like
half
a
megabyte
store
at
that
point
and
then
we
well,
we
sent
it
more
funds
to
unblock
it,
but
we
need
another
solution.
Any
thoughts
are
eugene
anally
on
that,
and
we
can.
C
Yeah,
I
think
we
just
dropped
this
completely.
We
we
need
to
be
just
careful
on
how
we
how
we
measure
like
as
a
store
operations.
So
we
need
to
estimate
how
much
we
can
abuse.
C
C
Yeah
out
of
the
limit
that
is
expected,
so
let's
say
we
exceed
the
the
reasonable
amount
of
year
that
we
pre-allocated
before
like
to
be
considered.
Then
we
we
can
never
rebalance
it.
Obviously,
so
it's
not
so
it
probably
will
have
to
be
handled
separately
eventually
and,
like
sync
needs
to
be
redone
to
handle
like
evm
shard.
If
it
becomes
very
like.
B
Popular
okay
sounds
like
we.
We
need
to
have
another
soon
conduct
as
well,
then,
afterwards,
all
right.
D
I
mean
we
can
like,
I
think,
both
of
those
things.
Let's,
let's
create
a
thread
first,
because
we
keep.
We
keep
having
those
conversations
in
meetings,
but
then,
like
there's,
some
people
who
are
not
in
the
meeting,
so
I
think
like
actually
having
collect
the
facts
first
and
then
and
then
kind
of
make
decisions.
B
Okay,
all
right!
Well
then,
I
would
solve
this
with
any
other
questions
and
if,
if
we
have
none,
it
would
actually
end
early
and
on
time.
I
aim
to
run
these
meetings
so
that
we
begin
an
end
like
clockwork,
so
that
everybody
can
count
on
that.
A
So
I
would
like
to
really
fast
reading
the
questions
and
answers
from
from
our
youtube
stream.
So.
A
Was
was
asking
the
question
about
when
some
kind
of
release
dates
and
world
maps,
so
our
next
question
our
next.
So
the
short
answer
is
that
the
ocrs
are
given
some
sense
of
it,
but
we
obviously
are
going
to
update
the
roadmap
and
going
to
share
it
publicly.
It
is
going
to
be
there.
You
will
be
able
to
access
it.
A
It
will
always
be
in
the
updated
state
on
the
same
link.
Another
question
was:
what's
the
role
of
the
near
token
in
evm,
and
the
question
to
this
is
that
literally
fees
user
pays
f
fees
to
the
relayer,
who
is
actually
relaying
his
ethereum
transaction
to
near
evm
and
relayer
obviously
need
to
send
a
new
transaction.
So
you
need
to
attach
them
here.
A
You
know
to
pay
for
the
fees,
so
near
token
is
something
that
is
used
for
paying
for
the
fees
on
the
runtime
level
and
obviously
the
gas
is
burnt.
So
well
all
of
the
tokens
that
I
paid
for
the
gas
they
are
burned,
so
yeah
user
pays
is
to
relay
for
their
pays
near
to
protocol
and
yeah.
Everybody
is
happy.
B
B
All
right
so
for
team
team
members,
please
post
your
updates,
I'm
creating
here
an
update
section.
You
can
post
them
just
a
text
form
over
there,
and
with
that
I
would
say
thank
you
to
everybody
who
participated
and
watched
and
see
you
again
next
week.