►
From YouTube: NEAR EVM Working Group Update [2021-02-05]
Description
https://gov.near.org/t/2021-02-05-evm-update/576
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
A
Okay,
all
right:
well,
we
will
begin
in
any
case.
So
today,
agenda
is
this.
Does
anybody
have
something
to
add
to
the
discussion
agenda
alex.
A
All
right,
so
our
current
call
goal
remains
the
same
as
I
discussed
last
week
as
in
we
are
working
towards
this
net
release
by
the
end
of
q1
for
the
evm,
and
we
pretty
much
test
things
out
right
now.
We
also
have
bug
bounty
prep
ongoing,
since
that
will
start
in
about
three
weeks
and
for
this
week,
let's
begin
with
the
updates
in
alphabetical
order
alex,
you
can
go
ahead.
C
Yeah
so
from
my
side
was
working
a
little
bit
on
the
evm
architecture
this
week,
together
with
uarto.
C
So
there
were
lots
of
discussions,
but
if
we
are
going
to
go
in
deep
into
it
in
the
discussion
phase,
I
was
I
was
given
lots
of
time
to
the
bridge
project
this
week,
so
yeah,
probably
not
that
much
on
my
end
for
for
the
evm
at
the
moment
was
was
on
board
in
matt
a
bit
on
the
specifics
of
the
evm,
so
matt
is
probably
going
to
join.
Us
was
having
some
calls
with
him,
but
yeah
also.
C
Yeah
and
in
the
beginning
of
the
week
it
was
the
all
hands
meeting
and
together
with
you
arthur,
we
were
preparing
a
presentation
there.
A
Yes,
I
think
our
updates
are
beginning
to
look
pretty
much
the
same
week
to
week,
so
I
can.
I
can
copy
that
to
myself
as
well
and
and
yeah.
So
we
we
worked
on
defining
the
evm
architecture
as
a
result
of
elias
architectural
explorations,
which
is
more
changed.
A
What
we
are
doing,
I
will
talk
about
that
in
a
bit,
did
a
little
presentation
to
keep
everybody
up
to
date,
booked
on
on
evaluating
the
sputnik
vm,
which
will
implementation,
which
we'll
also
talk
about
soon
and
data,
did
a
bunch
of
project
management
on
on
ticket
triage
and
and
tasking.
A
Yes
sure
right
so
just
trying
to
figure
out
how
to
how
much
to
say
here
versus
the
discussion
segments
yeah.
So
we
we
have
evaluated
a
new
sputnik,
a
new
evm,
runtime
and
virtual
machine,
and
we
will
be
attempting
to
switch
over
from
the
current
parity
ethereum
implementation.
We
use
the
sputnik
vm
and
I
think,
let's
defer
the
details
on
on
that
to
the
discussion
segment.
B
So
I
reviewed
spookingqvm
and
send
some
some
descriptions
about
that.
After
that
I
I
investigate
fungible
and
non-fungible
tokens
and
neb
protocol,
and
I
tested
some
examples
about
the
that
I
am
currently
investigate
near
evm
repo.
So
all.
A
D
Oh
yeah,
I
spent
my
half
working
week.
Finally,
getting
getting
this
full
request
for
the
crypto
zombies
merged
had
a
lot
of
meetings,
one
with
a
candidate
and
also
the
all
hands
where
I
reviewed
all
the
materials
to
like
get
a
better
overview
of
the
strategy
near
has,
and
mostly
I
was
focusing
on
the
replayer
architecture.
D
A
Let's
put
it
on
the
agenda
here,
I
don't
think
we
have
too
full
of
an
agenda,
so
we
can.
We
can
deal
with
it
today.
Okay,
okay,
so
investigations
into
the
ripley.
A
Okay,
we
don't
have
ilya
today
and
we
don't
have
mike,
but
on
max
mike's
behalf,
I
believe
he's.
No.
I
don't
see
him.
A
Ilya,
if
you,
if
you
wanted
to
briefly,
describe
the
work
you
did
on
your
evm,
that
would
be
also
useful.
E
Yeah,
hey
yeah,
hey
guys,
yeah,
so
pretty
much
been
manchester
united
in
different
options
for
evm,
and
so
I've
been
benchmarking.
Bosses
could
be
pm
and
trying
to
like
cut
the
cost
there.
I
think
the
like
action
item.
There
is
really
to
create
a
reproducible
example
for
contact
runtime
to
be
able
to
kind
of
ideally
optimize
performance,
so
we
can
actually
like
upload
some
of
the
work
there.
E
A
Talk
about
that
in
a
sec,
some
more
and
yeah
so
on
mike
mike's
behalf.
I
saw
that
he
and
let's
do
vehement-
I
mean
I'm
gonna
sing,
maybe
the
full
participant
list
so.
B
A
Okay,
so
he
he's
recorded
several
several
new
videos
on
using
the
evm
and
they
are
on
the
youtube.
A
Or
pvm
I
haven't
had
a
chance
to
to
look
at
those
yet
so
I
don't
know
exactly
what
they
are.
Okay,
all
right.
Well,
I
think
before
we
tackle
next
week,
let's
better
actually
have
have
the
discussion
here.
So
we
have
two
big
topics
to
talk
about:
on
the
one
hand,
the
evm
architecture
and
the
other
hand
some
input
for
frank
on
the
replay
and
result
of
his
investigations.
A
D
So
yeah,
I
didn't
really
find
anything
we
could
reuse.
I
mean
there
are
some.
There
are
some
tools
from
hyperledger,
but
that
that's
not
really
something
we
we
could
use
a
few
things
that
that
came
to
my
attention
was.
First
of
all,
I
already
told
you
we
have
to
be
able
to
set
the
chain
id
for
testing
purposes
in
in
the
evm,
because
otherwise
we
cannot
replay
the
transactions
from
an
ethereum
test
net
and
yeah.
The
most
important
thing
is
probably
that.
D
So
I
talked
to
an
ethereum
developer
and
he
said
what
they
are
doing
usually
is
they're
just
syncing
and
they're
not
like
pulling
out
the
transactions
via
the
rpc,
because
that's
like
too
slow,
of
course
we
we
cannot
use
it
for
replaying
because
we're
not
like
really
thinking,
but
we.
What
we
could
do
is
like
single
test
test
net
chain
and
then
just
query
the
database
directly
and
then
put
it
into
our
system
with
the
rpc
endpoint.
D
A
A
No,
it
doesn't
matter
how
you
take
them.
That's
not
the
important
part,
so
yeah
sure
how
how
do
you
figure
is
the
best
thing
to
to
pull
the
data.
A
You
would
you
would
want
a
local
node
synced
with
a
testnet
and
then
pull
the
data
from
that.
D
I
think
that
seems
to
be
the
best
approach:
yeah,
okay
and
then
put
the
transaction
in
through
our
endpoint
yeah.
Okay,
let
me
know
if
you
have
a
better
idea,
but
that
seems
to
me
the
best
approach.
C
A
C
The
chain
id
thing,
so
I
understand
that
in
the
signature
there
is
a
chain
that
is
specified
how
how
do
we
deal
with
it
in
the
in
the
better
net?
Can
we
actually
disregard
the
chain
id
transaction
for
our
batternet?
Can
we
can
we
like
introduce
there
something?
If,
if
we
are
in
the
better
net,
then.
B
D
A
A
A
Sure
it
does
doesn't
matter
too
much.
It's
a
standalone
tool
so
give
us
a
give
us
a
single
binary.
We
can,
we
can
use
and-
and
that's
fine,
let's,
let's
do
it
as
soon
as
possible.
The
deadline
is
less
than
a
month
from
now.
A
Okay,
that
makes
the
most
sense,
you'll,
probably
want
a
sizable
enough
one
to
be
able
to
handle
one
of
the
dismas.
A
So
let's
take
let's
begin
with
the
smallest
destination,
f1
testnet,
and
assume
that
and
have
enough
space
to
to
do
what
you
need
to
do
and
yeah.
Let's,
let's
try
that
approach.
D
A
Okay,
so
then
the
the
evm
architecture
discussion.
So
let
me
frame
this
and
then
then,
let's
discuss
with,
let
literally
speak
about
it.
So
we
we
have
been
doing,
let's
say,
architectural
experimentation
to
find
out
what
is
what
is
the
most
useful
path
forward
in
in
terms
of
how
to
structure
and
architect
the
evm?
A
A
A
A
It's
a
primitive
implementation,
not
not
a
user
level
implementation,
and
this
this
is
what
we've
been
working
on
so
far
since
the
last
last
few
months,
but
now
that
we
found
oh,
let's
say,
noticed,
let's
see
if
I
can
find
here.
First
blockchain
yeah,
we
noticed
a
project
called
sputnik
vm.
A
We
have
been
rethinking
this
approach,
because
this
is
a
very,
very
small
standalone,
virtual
machine
and
runtime
for
for
the
evm
and
ilia
has
been
exploring
if
we
could
just
directly
directly
replace
our
previous
use
of
open
ethereum
with
sputnik
vm,
and
this
would
lead
to
a
much
smaller
evm
contract
implemented
as
a
indeed
a
real
native
smart
contract,
and
this
in
turn
leads
to
a
rather
large
performance
speed
up
where
the
difference
between
the
contract
approach,
pure
contact,
contract
approach
and
the
so-called
pre-compile
approach
is,
is
getting
to
be
something
maybe
not
tolerable,
but
getting
to
be
something
interesting.
B
A
A
Yeah,
I
don't
see
the
full
participant
list
for
some
reason:
okay,
all
right!
Well,
let
me
let
me
speak
more
and
he
can
jump
in
if
he's
able
so
right
now.
The
way
our
investigations
look
is
that
the
original
approach
of
basically
a
smart
contract
pulling
in
the
whole
open,
ethereum,
runtime
and
virtual
machine
results
in
a
contract
of
about
one
one
megabyte
in
size
and
about
100
times
slower
than
the
pre-compile
approach.
A
A
A
So
that's
getting
already
into
territory.
That's
definitely
can
be
called
interesting.
It's
we.
We
can't
accept
this.
This
slowdown,
so
we
can't
do
exactly
this
approach,
but
there
is.
There
are
many
advantages
to
the
pure
contract
approach.
The
most
significant
advantage
right
now
in
terms
of
our
development
is
the
development
cycle
can
be
a
lot
faster.
As
in
we
don't
need
to
modify
near
core,
we
just
modify
a
contract
and
deploy
a
new
version
of
the
contract.
A
It
really
speeds
up
our
cadence
quite
a
lot
in
in
terms
of
the
how
many
times
per
day
we
can
iterate
when
we
develop.
So
this
is.
This
is
certainly
one
one
very
attractive
approach.
The
other
attractive
aspect
of
it
is
that
we
can.
We
can
basically
deploy
a
version
of
this
contract
to
any
of
the
pure
contract
evm
to
any
chain.
We
like,
including
mainnet,
when
we
like
now,
of
course,
in
terms
of
a
production,
ready
version,
it's
necessary
to
manage
expectations
here.
A
It
wouldn't
be
something
that
would
recommend
people
to
use,
but
it
it
would
be
available
in
any
case,
in
short
order,
for
let's
say,
highly
dedicated,
alpha
testers,
who
who
understand
that,
when,
when
it
breaks,
they
can
keep
both
pieces.
So
that's
another
attractive
approach.
A
What
we've
settled
on
this
week
in
our
deliberations
is
something
that
could
be
called
a
hybrid
approach,
as
in
we
are
going
to
to
attempt
to
strike
a
balance
somewhere
in
the
middle.
It
makes
sense
that
we
put
as
much
as
we
can
into
the
contract
user
level
contract
code
itself.
A
A
One
contentious
discussion
recently
was
regarding
to
what
extent
json
password
differences
might
break
consensus
if
we
have
to
put
it
down
on
the
protocol
level.
If
you
have
to
address
that
on
the
protocol
level
on
the
contract
level,
it
doesn't
matter
so
we
are
going
to
lift
some
aspects
of
the
evm
interface
to
from
from
the
protocol
level,
to
the
let's
say:
user
land
to
the
contract
level
and
we're
going
to
leave
performance,
critical
parts
on
the
protocol
level
in
in
near
core
itself,
so
the
exact
boundary
is
still
being
drawn.
A
But
some
of
the
some
of
the
things
we
already
figured
out
is
that
performance
performance,
critical,
let's
say
functions,
I
mean
they
are
ultimately
functions.
Performance,
critical
functions
that
must
remain,
or
rather
must,
must
be
supported
by
near
core
include
things
like
the
ketchup
function.
A
There's
some
some
about
the
easy,
easy
recovery
function
through
which
we
can
determine
who
signed
a
message.
The
there
are
hash
functions
like
more
hash
functions
like
256,
ripe,
md
160,
and
this
there's
a
bunch
of
elliptic
curve,
math
that
we
need.
So
this.
These
things
need
to
be
available
in
the
base
runtime
for
rust,
smart
contracts
to
use,
and
then
the
evm
implementation
can
can
make
use
of
them.
So
so
as
to
do
not
bake
this.
A
Let's
say
the
implementation
of
a
hash
function
into
the
contract
itself,
wasting
a
lot
of
space
and
and
performance
and
gas.
A
The
other
aspect
is
that
so
elia
would
would
be
able
to
speak
about
the
numbers
here.
Easy
with
us.
A
A
We
can
reduce
the
size
from
about
200
kilobytes
to
about
50
kilobytes
by
pushing
the
opcode
execution
down
into
the
into
near
corosa
as
a
pre-compile.
A
So
this
is
potentially
a
worthwhile
trade-off,
including
the
trade-off
is
not
fundamental
in
the
sense
that
let's
say
that
we
so
we
don't
have
the
actual
numbers
yet,
but
the
the
expectation
is
that
we
will
have
a
two
or
three
times
multiplier.
A
slowdown
from
the
hybrid
approach
currently
outlined
this.
This
multiplier
will
be
possible
to
reduce
quite
a
lot
going
forward,
including
not
only
through
the
efforts
of
the
evm
team,
but
significantly
parallel
tasking
of
the
contract
runtime
team,
so
that
that
will
be
a
nice
nice
benefit
here.
B
A
Yeah,
that's
that's
right,
so
this
is
this.
Is
this?
Is
a
standalone,
evm,
interpreter
and
runtime
that
anybody
could
deploy
to
the
chain?
It
doesn't
take
any
special
privileges
from
our
part.
It
is
absolutely
a
user
level
contract.
Anybody
could
do
it
and
well
elia
elia
did
it
and
I
believe
that
the
the
end
result
was,
from
his
point
of
view,
almost
acceptable
and
and
given,
given
that
we
can
push
some
of
it
some
of
the
implementation
down
into
near
core.
B
B
Well,
the
have
we
considered
special
whitelisting,
the
evm
contract,
specifically
so
that
we
can
use
the
llvm
compiler.
That
would
should
be
significantly
faster
than
the
the
single
pass
we're
using
today,
because
single
pass
is
pretty
much
not
very
optimized.
E
B
Yeah,
but
I
don't
yeah,
I
don't
think
it's
okay
yeah.
It
should
not
be
too
hard,
given
that
it
is
one
of
those
things
more
support.
E
So
yeah,
I
think
the
next
step
here
is
really
to
create
a
benchmark
for
this.
So
we
can
actually
like
get
the
contract
runtime
to
try
different
versions
and
see
how
get?
How
can
we
get
better
performance.
B
Yeah,
actually,
I
think,
like
kevin
what
you
said
also
about
it's
only
like
right
now
it's
10x
performance
reduction.
It
is
actually
quite
promising
because
the
the
rvm
supposedly
would
be
much
faster.
I
mean
I
would,
I
would
imagine
several
times
faster
than
the
single
pass
compiler,
because
single
pass
is
yeah,
pretty
much,
there's
not
much
optimization.
You
do
there,
but
lvm
yeah
is
like
highly
optimized,
so
yeah.
A
Yeah,
first
of
all,
bowen
thanks
thanks
for
joining
us,
it's
very
good
to
have
you
for
this
discussion.
Yeah
alex
go
ahead.
C
Yeah,
I
just
wanted
to
mention
that
the
current
limit
on-
let's,
let's
also
not
forget
the
the
gas
limitations
that
we
have
at
the
moment,
so
the
current
limit
of
the
near
blockchain
for
the
gas.
They
actually
say
that
we
can
be
faster,
nine
times
like
nine
times
faster
than
the
eva
than
the
ethereum
at
the
moment,
if
we're
talking
about
evm,
computations
and
stuff
like
that,
so
like
reducing
the-
and
this
is
for
the
pre-compiled
version
yeah.
C
So
if
we
are
taking
the
version
that
is
going
to
have
10
times
less
performance,
this
will
this
will
eventually
mean
that
we
are
going
to
deliver
on
the
product
that
works
slower
than
ethereum
at
the
moment
yeah.
So
so
this
is.
This
is
something
also
to
keep
to
keep
in
mind
where
we
are
positioned
with
different
options
in
conversion
to
ethereum,
so
yeah,
we
for
sure
need
to
to
be
faster
than
the
current
version,
so
hopefully
the
level
vm
will
will
give
this
to
us
sure.
A
Ilya,
since
you're
back,
could
you
could
you
pass
speak
about
all
of
this?
You?
You
know
this.
The
best.
A
A
Well,
I
mean
I
mean
actually
in
terms
of
everything
everything
just
discussed
since
you
you
did
you
did
these
measurements,
you
have
these
numbers
you're
in
the
best
position
to
speak
on
this
subject.
Maybe
you
could
speak
a
few.
E
Minutes
about
the
whole
thing
yeah
I
mean
like
high
level
right
the
current
implementation
of
splitting
vm.
I
mean
it's
definitely
like
faster
than
what
they've
had
with
open
vm
before,
but
it's
still
like
slower.
I
mean
yeah
like
a
few
like
few
to
10x
slower
than
what
we
have
right
now
with
the
freedom
precompile.
E
E
E
The
the
second
step
would
be
to
like
look
into
yeah,
llvm
and
other
stuff,
where,
like
we,
can
slash
down
the
performance
of
the
like,
improve
the
performance
of
contracts.
Potentially,
if
I
remember
between
single
pass-
and
it
will
be
on
the
almost
like
a
5x
improvement,
and
so
we
potentially
get
like
recover
almost
all
of
the
kind
of
costs
that
we're
losing
right
now
and
then
there's
also
like
isolated
interface
for
the
the
actual
vm
like
so
so.
E
I
call
it
the
u256
stack
machine,
it's
like
how
to
do
math
with
u356,
and
so
that
is
actually
taking
most
of
the
space,
and
I
think
it
takes
most
of
the
computation
just
because
256
computation
is
expensive
so
like
moving,
that
into
pre-compile
is
like
a
buzzing
modern
functions
right
that
would
allow
us
to
to
improve
performance
dramatically.
So
so
that
is
isolated
as
well,
and
so
we
can
actually
try
to
see
how
much
performance
improves
from
that.
E
E
For
the
tangible
token
and
everything
like
this
kind
of
a
parallel
work
item
anyway,
that
can
be
like
with
smart
contract.
You
can
do
it
like
way
faster
and
like
iterate,
a
lot
faster
again
like
I
suggest
you
just
launch
an
alpha
version,
first,
which
kind
of
implements
all
this
and
like
maybe
it's
less
performant,
but
gives
us
the
functionality
and
then
improved
performance
over
time
was
like
pre-compiling
whatever's
needed
yeah.
A
Yeah
yeah,
that
makes
sense
yeah
from
from
my
point
of
view,
it's
of
course
a
bit
of
a
upset
to
to
our
roadmap
at
this
stage,
but
it
is.
It
is
the
right
thing
to
be
doing,
especially
given
that,
although
we
will
pay
now
a
let's
say,
a
fixed
startup
cost
in
in
terms
of
the
adjusting
to
this
approach,
we
will
in
fact
be
able
to
iterate
a
lot
faster
already
a
week
or
two
from
now
so
yeah.
A
B
Yeah,
I
think
it's
definitely
helpful
if
you,
if
you
join
that
meeting,
because
I
think
there
are
more
optimizations,
you
can
do
like
things
like
preloading
the
the
contract,
like
always
maintained
in
memory
and
things
like
preloading,
the
the
vm
and
stuff
like
this
is
I,
I
think,
they're
like
small
improvements
that
that
can
be
done
on
top
of
this,
but
but
I'm
not
the
best
person
to
speak
to
that
sure.
A
Yeah,
okay,
so
so
that's
pretty
much
an
update
on
that
and
and
we'll
we'll
update
more
next
week
as
we
proceed
through
it.
So,
let's
talk
about
next
next
week,
frank,
we,
we
discussed
pretty
much
what
you
should
be
doing
and
since
you're
only
available
half
time,
I
can't
really
load
you
more
than
that
you're.
Getting.
Are
you
still
on
the
call?
A
Yes,
okay
right,
so
the
number
one
thing
that
we
would
need
for
you
to
jump
on
is
the
implementation
of
the
fungible
token
standard
in
the
evm
contract.
A
C
C
C
So
so,
and
the
reason
for
this
separation
is
that
accounts
potentially
can
be
used
for
some
other
actions
and
the
specifics
of
accounts
so,
like
a
user
need
to
register
to
hold
the
token
and
this
registration,
it
incurs
some
payment
to
the
to
the
fundable
token
contract,
because
this
contract
need
to
store
the
amount
of
of
tokens
that
associated
with
this
user.
So
this
is
an
additional
entry
in
the
map,
and
that
means
this
is
an
additional
place
and
storage
for
this
contract.
C
Account
standard
it
is
not
yet
in
place,
so
there
are
discussions
happening
there.
So
what
I
think
we
can
we
can,
we
can
use
at
the
moment
yeah.
It
is
like
to
to
focus
on
np
21.
It
is,
it
is
already
there.
We
still
can
do
this
and
then
updating
updating.
Once
once
everything
is
a
is
done
with
nap141
and
the
new
accounts
standard.
C
Then
we
can
migrate
to
it
literally,
even
if
we
would
launch
f
as
nap21,
it
will
not
be
such
a
big
problem,
for
example,
as
for
the
other
bridge
tokens
bridge
to
your
city
tokens
over
the
bridge,
because
this
is
a
single
contract,
yeah
and
all
of
the
concerns
with
regard
to
the
storage
and
the
necessity
of
users
paying
for
the
storage
and
stuff
like
that,
they
will
be,
they
will
actually
be
eliminated,
so
so
all
of
the
like,
so
all
of
the
additional
stuff
that
we
have,
I
think
for
a
single
contract
we
can
handle.
C
It
will
still
not
be
simple,
so
yeah
from
from
my
side,
I'm
like
trying
to
to
push
this
discussion
forwards,
and,
but
still
it
is
not
yet
there.
So,
just
just
an
opinion
that
we
can.
We
can
work
right
now
with
the
things
that
we
have
right
now
and
maybe
on
the
latest
stage.
Obviously,
before
the
main
net
release
we
can
update,
do
we.
C
So
141
is,
is
almost
finalized
or
like
it
is
like
treated
as
finalized
by
all
of
the
community.
But
again
this
is
not
enough.
So
the
account
the
account
standard
discussion
just
just
have
started,
and
it's
it's
still
to
be
there.
C
So
he's
the
main,
the
main
character
in
all
the
discussions
and-
and
mike
also
is
driving
this
a
lot
so
so
yeah,
you
probably
need
to
well.
I
do
not
want
to
distract
them
too
much,
because
I'm
I'm
already
pushing
them
almost
every
day
with
the
standards
yeah
and
they,
and
they
obviously
know
that
that
we
are
dependent
on
this
and,
moreover,
it
is
even
before
the
evm
launched
the
bridge
launch
as
we
have
since
we
have
it.
C
According
to
our
ocrs,
it
is
more
important
for
the
bridge
actually
to
have
it
finalized.
A
By
the
way,
one
question
I
saw
in
slides
from
chad
that
are
we
calling
are
we
calling
this
tokens
now
like.
C
Yeah
so
yeah,
so
so
it
is
an.
It
is
an
open
discussion
in
terms
of
the
the
naming,
okay,
I
believe
for
now.
Let's
keep.
C
Yeah,
there
is
no
stated
decision
on
this
and
I
think
that
it
should
be
connected.
The
the
literals
and
also
the
the
imaging
of
this
because,
like
there
are
already
icons
for
for
the
tokens
on
the
ethereum
side,
so
we
must
probably
need
to
some
kind
of
depict
it
also
on
the
near
side
yeah.
So
so
it
is
not
not
yet.
C
We
have
not
yet
figured
out
how
to
how
to
make
it
a
clear
and
user-friendly
way.
Okay,.
A
A
A
Take
that
doesn't
know
no
okay,
all
right
so
alex.
I
I
believe
you
you've
been
working
on
on
debug
bounty
anything
to
report
for
next
week.
What
you
plan
to
do.
C
Yeah,
actually
I
have
to
I-
we
have
a
major
point
in
the
end
in
the
beginning
of
the
next
week,
if
we
will
take
a
look
at
our
roadmap,
so
I
was
just
checking
in
the
background
the
roadmap
on
february
16.
C
We
have
the
the
points
which
is
called
the
evm
protocol,
upgrade
proposal
posted
in
forum,
so
so
this
is
something
that
I
I
need
to.
I
need
to
prepare
and
I
I
would
most
probably
be
working
not
on
the
backbone
by
rather
on
this
thing
right
here.
B
C
A
All
right
and
on
on
my
part,
I
will
continue
with
the
change
of
the
near
core
implementation,
the
pre-compile
implementation
to
use
sputnik
so
that
we
align
and
use
the
same
virtual
machine
on
on
everything,
no
matter
which
are
approaches
at
the
same
time.
I've
ticketed
and
we
can
work
on
adding
specifically
easy,
recover
and
ripe
md
to
your
core.
Already,
let's
say
the
math
api
and
yeah.
I
mean
this.
This
that's
pretty
much
gonna
occupy
me
next
week
in
terms
of
implementation.
A
Let's
see
so
kirill
you
will
discuss
on
the
bridge,
call
mike
we
don't
have
today
elia.
Do
you
want
to
mention
anything
about
your
plans
for
for
next
week
in
terms
of
your
availability
and
what
you
plan
to
move
forward.
A
Okay
and
yeah,
as
as
you
saw
today,
I
did
go
ahead
and
merge
much
your
open
pull
request
on
on
a
new
vm
up
to
to
master,
so
the
master
is
now,
let's
see
over.
A
Here
yeah,
so
this
is
this
is
how
much
the
master
and
I
began,
updating
the
master
branch
with
read
me
corrections,
because
the
readme
read
me
as
it
was
written
is
not
operable
and
one
question
I
had
for
you.
Ilia
is
that
so
obviously,
this
approach
of
creating
the
contract
only
ever
worked
in
the
the
version
that
isn't
using
the
nightly
protocol
features
and
has
evm
hard
coded,
but
furthermore,
well,
let's,
let's
put
the
question
this
way.
E
A
B
A
Okay,
okay,
so
I
I'm
aiming
to
make
this
with
evgeny's
help
also
who's
also
going
through
it.
We're
gonna
make
this
fully
workable,
this
readme,
so
that
everybody
can
get
set
up
with
this
dev
environment,
and
then
I'm
gonna
update
the
onboarding
guide
to
document
how
to
do
that,
so
that
everybody's
on
board?
Okay-
well,
that's
pretty
much
it
for
this
week.
Unless
somebody
has
questions,
I,
like
short
meetings,.
A
Right
so
we
we
are
calling
the
combined
solution
of
the
evm
and
the
bridge
we're
calling
it
codename
project
aurora
for
now,
as
in
the
marketing
department,
is
thinking
about
how
to
brand
all
of
this,
and
for
obvious
reasons,
if
you
look
at
my
background,
we
came
up.
Alex
came
up
with
with
a
nice
code,
name
for
it,
so
that's
that's
just
what
we
we
are
calling
it
for
now,
we'll
we'll
see
what
marketing
decides
to
call
it.
A
Does
that
make
sense?
Yes,
okay,
good,
so
that
was
a
pretty
short
meet.
Oh
yeah
nice.
We
can
be
still
a
fast
meet
and
can
somebody
check
do
we
have
questions
on
youtube.
C
So
yeah
I
was
checking
it
so
there
was
a
one
one
nice
comment
that
we
can
call
it
neither
at
the
token
and
and.
E
A
B
C
Yeah,
that's
a
clever
suggestion,
yeah
yeah
and
it
was
a
mention
about
the
hiring
and
I
would
probably
trade
ninja.
I
would
probably
advise
you
to
go
to
our
discord
for
near
and
and
go
to
the
evm
channel
there
and
and
then
you
can,
you
can
copy
this
and
and
you
can
you
can
tag
someone
from
our
either
art
or
me.
Then
we
can,
we
can
discuss
it.
There.
A
Yeah
for
sure
we
are
interested
to
talk
to
you
if
you're
interested
to
join
this
team.
We
also,
I
should
announce
we
have
a
new
team
member
joining
us
on
on
monday
as
well,
but
we
are
certainly
certainly
hiring
more.
So
that's
everything
for
today
then,
and
thank
you.
Thank
you,
everyone
for
your
time.