►
From YouTube: NEAR EVM Working Group Update [2021-01-22]
Description
https://gov.near.org/t/2021-01-22-evm-update/445
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
B
See
my
screen
yeah.
So,
let's
take
the
notes
from
hack
md
from
now
on,
I've
lost
too
many
notes
to
github
okay.
So
today
we
don't
have
a
specific
agenda
other
than
the
usual
one.
Last
week
we
dealt
with
some
some
roadmap
updates
for
the
coming
quarter
and
that's
an
interesting
particularly
interesting
recording
for
those
who
missed
it.
B
B
A
We
actually
well
yeah,
so
just
just
to
mention
to
everybody
that
we
have
two
people
joined
near
evm
and
bridge
teams,
so
these
people
are
eugene,
johanna
and
and
kirilla
brahmov.
They
are
going
to
mainly
focus
on
the
bridging
of
base
currency
from
ethereum
to
to
to
near
evm,
which
is
at
so
guys
say
hello
to
everybody.
B
A
Yeah,
I
was
working
mainly
on
hiring.
I
was
trying
to
reach,
so
I
actually
reached
all
of
all
of
the
well
the
majority
at
least
people
in
my
network,
trying
to
to
convince
some
of
them
to
join
us
and
help
us
do
some
stuff.
Some
progress
is:
is
there
I'm
going
to
submit
some
some
referrals
actually
and
it's
a
bit
later
sorry?
A
B
And
my
updates
are
very
similar,
so
recruiting
on
the
one
hand,
as
in
in
order
to
make
our
quarterly
objectives
defined
last
week.
We
do
need
one
to
two
decks
more,
so
that's
an
active,
active
topic
right
now
and
that
we
need
people
sooner
instead
of
later
and
onboarding,
our
new
recruits
and
internal
working
through
what
is
needed
to
onboard
people
to
evm,
primarily,
but
also
with
alex's
collaboration
to
the
bridge
team,
and
so
that
we
can
systematize
this
process.
B
It
was
rather
disorganized
when
I
joined
myself
as
in,
we
didn't
really
have
any
anything.
I
could
work
through
as
a
checklist,
and
now
we
now
we
have
something
and
very
happy
to
get
feedback
on
that
if
you're
missing
anything
anything
from
the
documentation,
especially
as
you
can
cure
as
we
go
through
it,
please
note
either
as
comments
or
or
indeed
directly
changing
documentation.
B
A
A
C
C
D
Yeah
I
was
working
through
some
problems
with
cargo,
also
like
reading
the
cargo
book
to
understand
cargo
better
and
then
mostly
the
crypto
zombie
code.
We
have
in
near
core,
so
we
now
also
have
the
erc
721
functionality
there
and
extended
the
tests
visit,
transferring
esc21
tokens
and
then
next
up
is
doing
a
benchmark.
There.
D
B
D
B
D
B
E
Comment:
hey
yeah.
I
haven't
done
much
on
this
side,
but
I'm
gonna
take
a
look
at
the
adding
value
to
my
transaction
call
and
also
expanding
to
use
two
bytes
for
the
length
of
the
method.
Definition
should
have
like
a
quick
vr
to
near
core
over
the
weekend
and
then
we
will
need
to
modify
the
let's
see
our
website
provider
and
rpc
proxy
to
follow.
F
Sorry
not
feeling
super
good,
so
there's
a
beta
net
chain
id
issue
in
your
workflow
provider,
where
we
have
now
a
new
chain
id
for
that
network
in
particular,
and
just
had
to
make
a
simple
fix
to
update
that
in
the
webview
provider,
so
that
is
that
is
fixed
how
to
do
a
quick
fix
to
the
the
evm,
simple
repository,
which
is
basically
way
the
simplest
version
of
interacting
with
the
evm
and
based
on
ilia.
Suggestion
move
the
keys
around
a
little
bit.
F
So
it's
as
simple
as
possible
push
one
of
the
changes
yesterday
for
that,
oh
yeah,
and
then
yesterday
also
thank
you
evgeny
for
pointing
out
the
web.
3
was
not
available
in
browsers
that
don't
have
like
metamask.
It's
been
a
while,
since
I
have
used
a
browser
like
that.
So
thank
you
for
finding
that
out.
Some
just
made
a
super
simple
change
explicitly
importing
web3
so
that
it
all
works
there.
That
was
my
mistake
before
so
that
that
is
pushed
to
near
pet
shop.
F
I
did
note
that
I
haven't
made
an
issue
for
this
yet
but
near
api.
Js
has
changed.
Serialization
and
they've
done
a
good
job
of
keeping
notes
in
the
change
log
about
this,
but
I
I
missed
it
so
we're
going
to
have
to
change
a
little
bit
of
near
web
3
provider
as
they
actually
change
the
method,
names
and
whatnot,
and
so,
if
we
want
to
keep
your
api.js
updated
with
that,
then
we'll
need
to
make
that
change
so
I'll
create
a
tiny
issue.
For
that
it
shouldn't
be
bad.
F
I
will
note
that
I'm
getting
pulled
into
lots
of
manager
tasks
so
I'll
probably
be
super
limited
on
on
evm,
but
I've
got
stuff
going
and
the
last
thing
is
I'm
just
for
fun.
I
am
making
a
really
simple
web
interface
for
evm,
simple
that'll
be
a
good
place
to
start
off,
and
I
really
want
to
carve
some
time
to
make
a
video
on
that.
So
you
can
look
forward
to
evm
simple,
having
a
like
node.js
and
also
a
super
simple
front
end
showing
people
how
to
how
to
use
it.
C
C
It
was
very
interesting
and
I'm
very
happy
to
join
the
team.
It's
a
very
good
and
inspiring
projects,
and
mostly
the
current
week.
I
would
say
that
I'm
at
the
same
stage
at
the
european,
so
I'm
setting
up
my
development
environment,
getting
ready
for
future
tasks
and
issues
and
at
the
moment
I'm
discovering
the
near
documentation
and
trying
to
follow
the
onboarding
guides.
Reading
the
messages,
what
happened
last,
two
or
three
months
or
so,
and
at
the
moment
mostly
focused
on
the
bridge,
documentation.
B
C
I,
I
would
say
everything
is
going.
Okay
at
the
moment
we
just
had
another
one-on-one
talk
with
alex
rafchenko
and
we
have
discovered
together
and
alex,
told
me
a
lot
about
the
bridge
functionalities
and
challenges
that
we
will
need
to
solve
in
in
this.
Our
interaction
between
the
evm
and
bridge
teams.
B
As
alex
noted,
we
have
the
plan
to
assign
yevgeny
and
kirill
to
work
on
this
problem
from
sort
of
opposite
sides,
as
in
evgeny
from
the
evm
team
side
and
kirill
from
the
bridge
team
side,
so
that
that
would
be
one
topic
we
don't
have
eugene.
So
I
wouldn't
tackle
the
question
about
storage
accounting
that
we
wanted
to
eventually
talk
about
anything
else.
Somebody
else
wants
to
bring
up.
A
C
C
A
Go
to
the
tv
yeah,
so
so
india,
you
can
see
here
that
we
have
the
evm
on
mainnet
in
in
this
objective.
We
have
a
protocol
upgrade
okr
and,
and
there
we
have
the
metric.
If
you
can
can
go
into
the
nodes,
then
we
are
saying
that
validators
agree
to
schedule
and
perform
the
near
evm
deployment
as
a
maintenance
protocol
operate.
So
so
this
is.
This
is
what
we'd
like
to
to
to
achieve.
A
But
obviously
we
are
going
to
start
the
preparation
here,
and
this
is
actually
is
going
in
hand
in
hand
with
the
other
topics
that
we
would
like
to
reach
out
to
to
the
validators,
which
is,
for
example,
the
upgradeability
of
the
breach
and
how
it
is
going
to
be
how
it's
going
to
be
managed
over
over
some
period
of
time.
So
so
now
we
are
going
to
to
start
with
the
simple
versions
of
their
upgrade
ability
and
and
can
and
continue
there
and
and
some
other
things
too,
so
so
yeah.
A
This
is
something
that
is
on
the
radar
thanks
for
bringing
this.
I
do
not
think
that
this
is
something
that
we
are
going
to
like
agree
on
this
call,
because
it
should
be
like
something
like
a
wide
discussion,
for
example,
that
was
done
by
the
validators
when
we
need
to
when
they
need
to
turn
on
the
well
vote.
What
are
the
criteria
is
to
transition
to
the
phase
two
of
the
maintenance.
E
E
A
A
E
B
E
A
A
B
A
Yeah
yeah,
let
me
start
this,
I'm
go
I'm
going
to
be
yes,
I
need
to
need
to
finalize,
for
example,
roadmaps.
I
think
that
this
is
something
that
that
is
going
to
be
done
on
the
on
the
next
week
and
and
then
and
then
like.
There
are
lots
of
things
that
I
need
to
take
care
of,
and
then
I'm
going
to
do
it.
C
B
B
Okay,
so
I'll
just
quickly
mention
for
the
audience
that
we
have,
we
have
a
stress,
testing
and
then
we'll
replay,
some
f
transaction
logs
and
we've
defined
that
as
a
day
and
active
adversarial
attacks
for
two
weeks
on
baronets
before
before
testnets
and,
of
course,
we
have
need
to
get
the
go-ahead
from
the
sra
team.
Overall,
we
we
need
a
little
bit
stricter
or,
let's
say
more,
well-defined
criteria
for
what
are
the
actual
products
that
or
projects
that
we
would
measure
the
success
here
with.
A
C
A
B
In
in
any
case,
from
last
week's
meeting
notes
you
can
you
can
find
the
same
information
on
in
the
presentation
all
right.
So
let's
talk
about
some
of
the
some
of
the
trickier
issues.
Let
me
see
if
we
have
anybody
join
no
okay,
so
I
think
the
the
most
important
thing
is.
The
most
important
thing
is
the
f
base
token.
So
we
have
to
move
that
forward
fairly
fast,
so
the
current
plan
is
that
I'll
have
to
start
working
through
those
changes
on
newport,
hopefully
in
collaboration
with
ilya.
B
B
A
So
this
is
a
pretty
natural
and
we
discussed
that
that's
a
pretty
natural
thing
for
us
to
focus,
focus,
curio
and
evgeny
on
this
task
and
that's
why
I
think
that
this
this
base,
talking
bridging
is,
is
something
that
we
we
well
potentially
can
can
do,
can
do
this
this
quarter
and
we
are
like
resourcing
this
activity.
So
so
that's
pretty
good
from
my
point
of
view
and
let's
and
let's
do
it,
let's,
let's
keep
it
it.
A
B
B
Can
we
do
it
this
order
or
not,
and
I
suggest
we
figure
that
out
as
soon
as
otherwise
we
need
to
re-evaluate
our
objectives
here.
So
let's
talk
about
the
base
token,
I
think
elian.
Would
you
be
able
to
provide
some
some
guidance
here?
You
you
know
the
code
base.
You
wrote
most
of
the
code,
you
relevant
code.
You
know
it
the
best.
What
do
you
think
are
the
next
things
we
need
to
do
to
move
this
forward.
E
E
A
Yeah
the
the
quick
comment
here,
141,
so
so
the
fungible
token
standard.
It
was
split
into
multiple
into
into
three
actually
parts,
and
this
one
is
is
on.
Only
one
of
these
parts
two
are
necessary
and
one
is
is,
is
optional,
so
this
is
only
half
of
a
standard,
well,
the
bigger
half,
but
still
only
half-
and
this
is
about
the
transverse
itself
now
and
an
additional
nap
should
be
created
for
the
accounts
itself,
and
this
is
that
is
still
what
still
should
be
done.
A
Also,
a
person
from
the
community
said
that
he
is
he
would
like
to.
He
would
like
to
do
the
reference
implementation
of
np141,
which
is
good
and
the
overall.
The
overall
I
don't
know
like
yeah,
at
least
if
guinea
or
eugene
is,
is
saying
that
it
is
in
the
good
shape,
and
maybe
mike
you
can
comment
because
you
you
were
on
the
call.
The
last
call
on
the
on
the.
A
A
B
E
E
I
I
can,
I
can
give
a
stab.
I
think
I
think
the
piece
that
we
really
need
to
do
is
like
figure
out.
The
second
item
here
like
the
first
and
third,
is
like
they're,
pretty
straightforward,
yeah,
it's
just
kind
of
like
as
soon
as
this.
The
interface
for
for
flauntable
token
is
finalized.
It
should
be
straightforward
to
do
the
yeah,
they're
figuring
out
how
to
pipe
mirror
instead,
like
it's
it's
I
don't
think
it's
gonna
be
blocking
right
away,
but
it's
gonna
be
pretty
hard
to
do
stuff
without
that
yeah.
So,
okay,.
E
B
A
C
A
C
E
We
still
need
near,
like
you
know,
like
the
nearest
kind
of
the
the
base
talking
of
the
of
the
kind
of
outside
so
yeah,
so
there's
still
things
which
are
like
if
people
attach,
for
example,
if
people
attach
balance
well,
we
can
fail.
That's
easy
but
like
there
should
be
a
way
how
you
bring
near
into
you.
A
E
E
E
A
Yes,
so
I
already
started
to
work
on
this,
so
I
I
think,
that's
like
generally,
we
have
discussed
in
the
bridge
team
that
a
good
good
way
how
to
do
this
is
well.
First
of
all,
do
not
don't
have
a
hard
connection
with
the
existing
bridge,
so
bridging
the
internal
bridge
in
between
near
native
vm
and
near
evm.
It
should
be
like
a
separate
contract.
A
It
shouldn't
be
aware
of
of
the
bridge
itself,
and
this
is
pretty
unusual,
because
any
fungible
tokens
that
we
create
on
the
near
side
should
be
also
be
able
to
be
bridged
in
inside
of
in
your
evm.
So
this
is
one
thing
now
now
imagine
that
we
have
this
thing
now
if
we
have
breached
a
token
from
the
erc20
to
nep
141.
A
If
we
did
that
bridge
now
we
need
to,
but
but
if
we
have
this
bridge
and
then
nap
141
to
n
erc20
and
then
the
question
is
that
a
user,
an
ethereum
user?
He
needs
to
be
able
to
do
this
breach
in
like
in
a
single
transaction,
because
he
he's
not
able
to
schedule
near
transactions
so
and
because
he
he
doesn't
have
a
near
account.
A
The
only
thing
that
we
can
do
is
to
land
it
into
the
escrow
smart
contracts,
which
can
be
then,
so
we
are
putting
this
nap141
tokens
after
the
first
bridge
in
the
smart
contract
and
then
somebody
on
behalf
of
the
user,
any
relayer,
any
any
type
of
of
of
service
is
able
to
call
this
smart
contract
with
the
near
transaction,
and
this
new
transaction
is
going
to
ask
the
the
the
internal
bridge
to
move
these
tokens
inside
of
the
evm.
So
I
think
that
this
is.
A
This
is
the
way
how
this
should
be
done
and
and
if
so
then,
for
the
ethereum
users,
the
the
workflow
will
be
pretty
straightforward.
They
are
going
to
schedule
a
couple
of
transactions
on
the
ethereum
site.
Only
in
the
beginning
of
the
transfer,
then
some
relayer
is
going
to
finalize
this
first
transfer
on
your
site
issuing
first
near
transaction.
A
E
E
Then
we
are
but
we
need.
We
need
to
change
them
anyway,
because
we
need
to
be.
We
need
to
follow
this.
We
need
to
follow
the
standard
right
now.
The
new
standard,
the
new
standard,
includes
transfers
with
callback
okay.
So
so,
if
you
have
transfers
callback,
you
pretty
much,
we
just
need
kind
of
a
mint
with
callback
which
is.
E
C
A
A
So
if
we
potentially
can
can
remove
this
and
like
do
it
with
a
single
transaction
and
just
this
fungible
token
factory
is
going
to
call
it's
and
and
then
the
transfer
is
happening,
but
but
here
we
need
to
inject
some
additional
logic
in
case
this
proof
wants
with
using
this
proof,
we
would
like
to
transfer
the
funds
in
the
near
evm.
Then
we
need
to
do
the
callback,
if
not
then
just
transfer
it.
There.
E
C
A
E
A
E
A
A
A
I
I
I'm
I'm
just
I'm
just
checking,
so
I
I'm
just
saying
that
near
smart
contracts
need
to
be
able
to
schedule
ethereum
transactions
to
the
evm
and
at
the
moment,
yes.
So
the
thing
that
I'm
missing
in
the
link
here
is
is
how
it
is
treated
in
terms
of
so
it
should
be
treated
very
differently
from
the
from
the
relate
ethereum
native
transactions,
because
we
relay
ethereum
encoded
transactions
and
what
we
are
scheduling
from
our
smart
contracts
is
already
decoded
transactions
and
we
need
to
attach
to
the
first
ones.
A
We
need
to
account
for
the
first
ones,
with
the
evm
gas,
which
is
obviously
then
recalculated
in
the
near
gas
and
for
the
second
ones,
the
transactions
from
the
from
the
from
the
internal
well
from
the
near
native
smart
contracts
we
need
to
intentionally
when
they
are
not
able
to
attach
if
they
can
attach
only
near
yeah.
So
I'm
just
checking.
That
is
something
that
is
possible
right
now.
E
E
E
C
F
A
E
C
E
A
A
A
B
Okay,
all
right,
so,
let's,
let's
table
that
for
now,
we
don't
have
a
lot
of
time
left.
One
one
thing
I
would
raise
is
that
so
yes,
we
we
do
need
to
upgrade
bayonet,
preferably
sooner
right,
given
that
we
actually
are
inviting
people
to
hack
on
it,
and
mike
is
also
a
question
for
you.
What
happened
with
that
blog
post
you
plan
to
publish
is
that
on
the
agenda
still.
F
My
read
on
this
is
it's
not
in
the
near
future.
Honestly,
it
sounds
like
I
think.
Marketing
is
working
on
sort
of
a
like
a
broad
post
about
like
everything
we're
doing
in
ethereum,
including
the
bridge,
including
this,
including,
I
think
one
other
thing
so,
but
we,
but
we
do
want
to
invite
the
community
and
to
help
hack
at
this
thing.
So
I
I'm
not
exactly
sure.
C
Can
I
get
a
pushback
from
towards
marketing
and,
like
say
like,
can
you
give
me
estimate
like
one
or
two
weeks?
If
not,
then
we'll
publish
it
without
this
strategy
because
we
need
testing
like
it
seems
like
you
shouldn't
block
content,
that's
already
there
and
wait
for
like
one
push
I
mean
it
can
be
reiterated
on
a
future
event
if
needed.
Like
reference,
I
don't
think
you
should
like
wait
for.
E
C
E
I
I
agree
with
eugene
yeah.
If,
if
you
have
content-
and
like
I
mean
yes,
it's
great
to
have
like
an
overarching
thing
and
we
should
have
it
but
like
actually,
I
don't
think
we're
actually
ready
for
overarching
thing,
because
it's
not
really
like
on
main
net,
neither
bridge
nor
evm.
So
like
fully
functioning.
E
B
B
Right,
that's
actually,
we
have
now
a
dedicated
evm,
evm
sub
forum
here,
so
we
have
under
development,
evm
and
bridge
bridge
is
pretty
empty.
Perhaps
somebody
can
move
any
relevant
post
into
there
for
the
evm
category.
I
already
moved
a
couple
of
relevant
posts.
The
token
discussion
was
actually
posted
in
economics,
so
I
figured.
Maybe
it
belongs
there,
but
the
other
other
things
I
moved
here.
Just
so
you
know
I'll
show
you
so
mike.
This
might
actually
be
a
pretty
okay
option
for
getting
the
word
out.
B
B
Okay,
all
right,
let's
see
we'll
be
on
so
outcome,
is
probably
published
on
publish
on
forum
soon.
I
I
think
we,
we
finished
the
review
on
that
right.
It's
it's
fully.
Everything
is
ready
and
waiting
for
already
some
time
two
weeks,
okay,
but
so
once
once
we
have
the
blog
post
out.
Hopefully
we
start
to
get
people
hacking
on
it,
and
that
does
come
with
the
caveat
that
we
wouldn't
still
plan
to
change
the
world
from
underneath
them
in
terms
of
the
base
token.
B
E
B
A
A
A
B
E
Actually
yeah,
so
there's
like
couple
things
here:
one
is
the
the
so
the
way
the
way
so
this
is
like
the
other
piece
is
like
the
the
ease
as
a
token
right,
they'll
be
way
too
minted,
so
we
can
just
on
on
better.
That
leaves
a
thing
that,
like
some
you
know,
faucet
contract
can
just
call
that
and
and
yeah.
B
E
C
E
B
E
B
A
Yeah,
and
also
also,
I
just
want
to
mention
that
this
is-
I
know
that
we
run
out
of
time,
but
this
is
also
connected
with
the
initial
supply
of
f
on
the
main
net
once
we
are
going
to
to
deploy
this
so
evm
contract.
Potentially,
this
is
something
that
we
still
need
to
discuss.
Maybe
it
would
be
worth
of
somebody
buying
beforehand,
before
even
the
bridge
is
launched,
because
the
bridge
should
be
launched
like
after
the
instance
of
the
evm
deployed.
E
A
A
B
Well,
I
think
we
are
running
out
of
time.
Does
anybody
have
some
quick
comments?
Questions?
Oh!
Is
it
enough
for
today
I'll
write
up
by
the
way
all
of
this
on
the
forum,
so
we've
agreed
now
that
all
teams
are
posting
forum
updates
weekly.
This
update
will
go
not
only
to
github
discussions,
it
will
go
to
the
forum
under
the
evm
subcategory
and
we
can
discuss
it
further.
There.