►
From YouTube: NEAR EVM Working Group Update [2021-03-12]
Description
A
A
A
A
It
has
the
it
has
feature
parity
with
the
old
contracts,
but
it's
it's
possible
to
upgrade
the
evm
implementation.
We
are
on
a
much
newer
version
than
than
the
old
contract,
so
we
have
certain
performance,
improvement
and,
and
some
bugs
are
fixed.
Let's
see
here
yeah
we
are.
We
are
now
releases
of
two
two
days
ago,
currently
so
pretty
much
in
sync
with
upstream,
so
this.
B
B
So
currently
it's
all
fine
and
I
started
implementation,
specific
functions
for
s
connector
and
currently
almost
implemented
deposit,
and
I
think
it's
really
good
progress,
because
I
solve
for
probably
all
problems
that
stopped
me
to
implement
a
new
implementation
for
no
std
so
next
week.
I
think
I
will
have
a
really
good
progress
and
probably
I
will
end
the
task.
A
A
Okay,
all
right,
I
also
see
that
you,
you
are
now
on
the
same
nightly
version
as
we
are
using
in
a
contract.
That's
good!
I
was
going
to
ask
whether
we
needed
to
stay
on
an
older
version,
but
if
that
works,
that's
great
yeah,
so
this
is
coming
along.
I
will.
I
will
find
some
time
in
the
next
days
to
to
review.
Is
it
ready
for
review?
A
B
Implement
some
things
related
to
sdk,
I
mean
sdk.
Now,
stevie
sdk
could
be
based
some
functionality
from
near
evm,
and
I
put
additional
functions
for
for
working
to
s.
Connector
so
currently,
full
environment
for
development
is
really,
and
I
think
in
next
week
I
probably
can
finalize
that
smart
contract.
A
C
So,
in
order
to
call
the
evm
contract,
we
have
to
sign
and
create
transact,
create
transactions
and
sign
them,
and
it's
basically
the
same
as
transmitting
money.
So
I
started
building
that
first
to
be
able
to
test
it,
and
so
it
basically
means
creating
a
transaction
and
calling
it
as
with
borsch
and
signing
it,
and
I
I
built
that
it's
finished,
but
it
doesn't
work.
C
A
A
I
believe
we
have
everything
you
need
for
that
as
long
as
we
are
tracking
the
block
hashes
in
the
contract,
yeah
yeah,
so
those
those
should
be
okay
and
you
should
be
able
to
call
those
just
remember
to
portion
code
the
input,
it's
not
json,
we
don't
use
none
of
the
evm
contracts.
Inputs
are
json
that
will
change
when
we
incorporate
the
punchable
token
standard,
perhaps,
but
for
now
they
are
push.
C
C
A
C
A
E
I'm
waiting
on
a
response
about
a
question
I
had
about
adding
fields
to
the
genesis.
Config
I
mean.
Typically,
you
don't
want
to
change
those.
Then
I
don't
think
we've
like
we've
changed
some
fields,
since
I
think
but
yeah,
I'm
not
not
sure
about
actually
adding
fields
to
that.
I
don't
think
we've
ever
done
that
and
then
I
looked
at
implementing
the
blake
to
f,
compress
compression
function,
and
I
was
like
a
quarter
of
the
way
through
it
and
I
just
thought
I'm
like
it
must
be.
E
A
E
D
Is
the
difference,
though,
because
if
compression
function
in
eip
allows
the
caller
to
specify
the
number
of
rounds
and
then
this
implementation
it
is
fixed,
so
we'll
probably
have
to
copy
it.
We
can't
use
it
from
this
library
and
we'll
have
to
copy
and
have
some
modification
to
make
some
changes
to
this
code.
E
E
E
A
A
True,
however,
in
any
case,
they
may
accept
it,
and
so
that
would
be.
That
would
be
the
preferable
way
to
proceed,
but
so
joshua
you
need
to
keep
your
eye
on
the
ball
here
as
in
this
is.
This
is
what
we
need.
Ultimately,
this
this
needs
to
be
implementable
and
whatever
it
takes
to
to
get
this
implementable,
that's
what
you
need
to
do.
So
it's
it's
not
enough.
As
joking
pointed
out,
if
something
is
in
the
source
code,
there
we
have
to
actually
be
able
to
provide
this
call
signature.
A
Yeah
but
there's
still
a
bunch
of
days
until
tuesday,
which
we
wouldn't
want
to
misdirect
joshua
in
the
meantime.
So,
let's,
let's
make
sure
that
we,
we
agree
what
we
work
on
here.
So
it
doesn't
mean
it
doesn't
mean
that
the
the
mass
api
should
have
a
host
function
which
is
exactly
equivalent
to
the
eep
as
it's
defined,
because
after
all,
we
would
like
these
host
functions
to
be
generally
useful
beyond
just
the
implementation
of
an
evm.
However,
it
must
be
flexible.
D
Yes,
so
I
have
thought
about
how
to
make
a
generally
useful
function
that
can
also
be
used
to
implement
this
eip.
So
what
I
thought
about,
basically,
the
function
that
can
perform
like
the
same
of
compression
call,
but
on
multiple
blocks
at
once.
This
is
general
generally
useful
because
you
can,
for
example,
compute
regular
blank
two
hash
in
a
single
call
of
such
function.
Even
if
the
message
to
be
hashed
is
longer
than
a
single
block
and
at
the
same
time
you
can
implement
this
pre-compile.
D
So
this
pre-compile
in
ethereum
is
not
that
good
for
ethereum
users,
because
it
only
compress
perform
this
compression
on
one
block
at
a
time.
So
if
you
need
to
hash
a
longer
message,
you
need
to
call
it
multiple
times
and
currently
in
ethereum.
There
is
a
high
cost
of
for
calling
any
contracts,
including
pre-compiles,
but
we
are
not
ethereum.
A
A
E
Yeah,
I
renamed
or
renamed
it
to
kind
of
follow
what
we
were
doing
before,
which
was
like
the
protocol
feature
underscore
crypto
extras,
and
I
implemented
that
into
evm
feature,
but
other
than
that.
That's
that's
pretty
much
good
to
go.
I
I
still
have
to
push
that
one,
but
I
was.
I
was
going
a
little
bit
over
time
when
going
through
the
f
compression
function,
then
I
got
one
last
thing
yeah
then
I
guess
I've
just
been
fixing
the
lingering
ci
issues
because
there's
a
couple
backwards.
E
A
E
A
E
E
A
I
believe
yeah
I
mentioned
that
yes
yeah,
I
I
wouldn't
get
held
up
on
questions
like
that,
just
boot,
one
up
and
expensive,
otherwise,
otherwise
you
introduce
pipeline
stalls
into
critical
paths
and
that's
not
good
right,
so,
let's
just
get
it
done.
So
I
believe
that
the
the
other
question
that
you
had
here
we
will
need
either
yogani
kuciako
for
or
perhaps
evgeny
coupon
or
bo,
and
one
who,
on
the
call,
know
something
about
this.
A
F
Know
that
that
file
is
well
so,
first
of
all
that
file
is
now
the
genesis
file.
It
is
a
file,
that's
used
to
for
testing
purposes,
and,
and
yes,
it
has
to
be
changed,
but
that's
not
for
the
reason
of
changing
the
genesis
file.
It's
mostly
just
like.
I
think
some
tests
rely
on
that
file
rely
on
the
fact
that
the
file
is
updated.
E
E
A
A
Okay,
great
okay,
so
those
are
those
are
the
theme
updates
now,
if
we
had,
if
we
had
alex
with
us,
probably
we
would
discuss
the
connector
in
more
detail.
You
have
guinea,
you
do
you
have
any
anything
to
comment
on
that.
You
are
not
blocked
on
anything.
You
just
actually
were
saying
a
new
update.
You
just
need
to
finish
the
coding
and
and
that's
all
you're,
not
waiting
on
kirill
or
alexa
or
me
or
anything
like.
A
A
B
A
A
A
Let's
see
that
looks
better
for
scrolling.
So
currently
the
goal
is
that
we
we
would
deploy.
Let's
look
at
the
calendar
and
see
what
date
that
was
march.
29
is
a
monday
just
a
few
days
before
the
end
of
the
month,
and
we
will
certainly
have
something
to
deploy
on
that
day
for
testnet
no
question
given
the
evm
contract
approach,
a
different
question
is
what
all
might
be
missing
in
terms
of
performance
and
and
testing.
F
A
A
A
So
the
let's
see
so
the
bug
bounty
program
was
deferred
for
both
bridge
and
evm
on
the
on
the
performance,
and
we
are
definitely
late
with
the
replayer,
which
is
frank.
Why
why
we
need
to
know
how
long
it
will
take
to
replay
something
like
gurley?
So
if
you
would
calculate
that
as
soon
as
you
can-
and
we
did
the
protocol
upgrade
proposal
there
wasn't
that
much
discussion
around
it
that
I
saw
but
then
again
it's
no
longer
on
the
critical
path.
A
I
do
believe
we
can
make
that
that
date
and
the
connector
of
course,
is
also
coming
along
very
nicely
in.
In
fact,
this
is
pretty
much
on
schedule
still
and
the
hard
fork
brilliant
hard
fork
got
d
scoped,
although
upstream
is
actively
working
on
it.
So
we
might,
we
might
even
have
it
in
the
next
few
weeks,
but
if,
if
so,
it's
just
a
cherry
on
top
the
berlin
hard
fork
for
the
ethereum
mainnet
is
scheduled
for
middle
of
april.