►
From YouTube: Aurora Update [2021-05-07]
Description
Follow the latest from NEAR Protocol on:
Website: https://near.org/
Discord: https://near.chat/
Blog: https://near.org/blog/
Twitter: https://twitter.com/NEARProtocol
GitHub: https://github.com/near https://github.com/nearprotocol
#Blockchain #FutureIsNEAR #NEAR #nearprotocol
A
Okay,
so
hello,
everybody,
it
seems
like
we
are
online
right
now,
just
checking
it
on
the
youtube,
yeah
cool,
so
hello,
everybody.
This
is
a
friday
update
from
the
aurora
team.
As
you
know,
for
a
couple
of
weeks,
we're
already
running
a
joint
update
of
the
bridge
and
evm
teams
and
yeah.
So
so,
let's
go
directly
into
into
the
updates.
Let's
discuss
some
stuff,
we
have
lots
of
things
to
to
share.
I
believe
today,
let
me
start
sharing
of
my
screen.
A
Great
so
so,
as
we
said
yes
last
week,
we
are
on
the
full
speed
going
to
going
for
the
aurora
release
and
structure
and
the
spin-off
of
aurora.
A
So
as
a
as
we
were
mentioning
during
the
last
call,
aurora
is
going
to
become
a
separate
company,
so
we
are
working
in
this
direction
and
we
are
trying
to
secure
the
funding
for
it
actually.
So
the
the
current
the
current
status
in
the
current
gold,
we
are
on
the
finish
line
for
the
aurora
release,
or
this
is
going
to
happen
pretty
soon
and
we
are
wrapping
up
right
now.
Everything
that
comes
into
our
mind
for
this
release
already.
The
team
is
working
really
really
hard
on
this.
A
A
B
Yeah
mainly
working
on
the
onboarding
stuff
and
having
some
like
a
couple
of
meetings
with
marcelo
regarding
the
like
intro
for
the
rainbow
bridge
and
also
reading
the
importing
temporary
stuff,
the
technical
stuff
yeah.
So
yep.
A
Okay,
cool
cool,
so
happy
onboarding
to
you.
Hopefully
you
will
be
pretty
soon
after
speed
and
and
will
will
help
all
of
us
with
all
of
the
different
stuff
that
we
need
to
do
yeah,
and
this
is
going
to
be
actually
the
the
normal
position
of
ahmed,
because
h
goes
prior
to
l
so,
but
you
are
going
to
be
the
first
one
who
is
going
to
share
his
updates
from
now
on.
A
So
congratulations
now
mine
update,
so
I'm
working
mainly
on
the
on
the
aurora
release,
trying
to
to
help
everybody
to
deliver
their
things
and
check,
and
then
everything
is
is
okay.
This.
This
is
mainly
unseen
inside
of
the
inside
of
the
overall
team,
but
we
are.
A
We
have
a
lot
of
connections
with
marketing
departments
with
and
julian,
as
always
thanks
for
joining
the
call
we're
working
with
julian
on
the
legal
structure
and
so
lots
of
activities
here.
Small
tasks
unfortunate
well
can
cannot
cannot
say
any
any
major
thing
that
is
happening
there,
but
small
tasks
checking
the
the
communications
and
stuff
like
that.
A
A
So
it
comes
to
an
end.
Actually,
so
it's
going
to
be
finalized
pretty
soon
and
we
already
started
to
have
conversations
with
investors
at
this
moment
in
time.
I
can
say
that,
even
before
the
pitch
deck
is
finished,
we
have
secured
around
15
percent
of
the
founding
round
in
soft
commits,
so
investors
are
pretty
active,
so
this
is
cool.
A
A
Obviously
pretty
soon
you
will,
you
will
understand
who
are
these
partners,
but
for
now
this
is
obviously
under
embargo,
and
we
cannot
share
this
info
with
you
during
the
week.
I
was
testing
in
here
so
pierre,
I
yeah
are
you
here,
yeah
you're
here
so
here
I
tested
it.
The
deployment
of
the
connectors
on
the
test
net
and
the
the
front
end
itself.
A
It
works
good.
It
is
a
it
it.
It
looks
also
pretty
straightforward.
There
must.
Probably
there
are
some
things
that
we
need
to
tweak
there
like
naming
of
the
tokens
and
stuff
like
that,
but
we
can.
We
can
discuss
this
or
we
can
discuss
this
later
on
after
aurora
release.
A
The
major
point
to
to
know
about
is
that
in-ear
is
going
to
be
released,
not
together
with
aurora.
This
is
going
to
be
a
separate
release,
so
this
is
going
to
happen
after
aurora
launch
and
there
was
a
small
piece
of
activity.
It
was
a
an
ama
session
in
binance
with
russian
community,
so
yeah
also
I've
taken
part
in
it
together.
Actually
so
that's
it
from
my
site
arto.
C
More
than
I
can
remember,
but
I
put
in
some
some
things
that
I
can
remember
so
importantly,
joshua
and
I
collaborated
throughout
the
week
on
on
the
engine
collaborated
with
others
too,
but
with
to
show
we
had
a
very
tight
feedback,
loop
form
for
fixing
the
basic
basic
logic,
validating
and
fixing
the.
C
In
the
in
the
engine,
so
we
found
some
edge
cases
that
we
took
care
of,
for
example,
in
the
transaction
decoding
we
didn't
take
care
of.
We
hadn't
taken
care
of
the
case
where
the
transaction
actually
has
all
all
zeros
to
address,
which
needs
to
be
treated
the
same
way
as
the
lack
of
to
address.
C
Joshua
can
talk
more
about
the
engine
work.
My
my
own
main
focus
was
the
relay,
so
the
the
relay
is
is
almost,
I
would
say,
ready
for
prime
time
as
in
it's
certainly
already
out
there
and
and
some
people
are
hitting
it,
but
there
was
still
a
ton
of
ton
of
work
to
tie
up
the
classic
saying
that
the
you.
C
The
80,
but
you
still
have
the
other
80
to
do
that-
certainly
applied,
and
so
a
lot
of
small
things
to
do,
and
I've
done
most
of
them
most
recently
as
as
an
ask
from
from
marcelinepierre
I'm
adding
some
some
more
new
metadata
for
the
blocks
and
transactions,
which
will
aid
the
development
of
the
esc,
2020
bridge
connector.
C
Also
beyond
the
actual
implementation
of
the
relayer,
we
actually
have
to
offer
well
services
related
services
and,
to
that
end,
there's
been
a
lot
of
infrastructure
work
in
cooperation
with
the
srp
team,
but
also
just
currently,
all
by
my
lonesome
asmb.
We
are
hiring
for
this
position
and
qualified
candidates
should
should
contact
me
alex
so
that
that
involves
probably
familiar
technologies
like
ansible,
caddy,
postgres,
prometheus,
terraform
and
grafana,
and
so
on.
C
C
I
wasn't
sure
that
the
master
on
the
engine
is
actually
stable.
So
I
would
like
to
to
maybe
talk
about
that
as
an
agenda
item.
They
should
keep
the
master
stable
at
all
times
and
then
it's
possible
to
to
deploy
we'll
come
back
to
that
in
the
discussion
segment.
So
those
are
some
of
the
highlights
from
me.
Let's
go
to
japanese.
D
So
I
was,
I
did
a
little
review
of
pull
requests
and
also
of
aurora
engines,
so
aurora
engine
is
big,
so
I
only
reviewed
some
small
part
of
code,
but
I
already
found
some
discrepancies
between
the
behavior
of
our
evm
and
ethereum.
So,
for
example,
one
area
where
I
found
the
discrepancy
is
the
transaction
transactional
gas
processing
as
hd.
D
Currently,
as
I
think
that
the
gas
limit
field
interes
in
transaction
is
completely
ignored
and
in
general
I
think
the
logic
like
when
processing
and
when
ethereum
processes
transaction,
it
subtracts
the
gas
fees
like
gas
price
times
gas
limit
and
then
at
the
end
it
refunds
unused
gas
and
gas
that
was
added
to
the
fund
counter
and
I
think
in
our
aurora
engine.
This
part
is
not
implemented
at
all
so
transaction
level,
gas
processing
and
associated.
D
And
another
thing
that
I
found
we
currently
when
we
are
deleting
a
an
account
in
vm.
We
are
not
deleting
its
storage
and
this
actually
has
an
observable
effect
on
the
behavior.
So
it's
not
just
some
stale
storage
entries
residing
in
the
near
contract
storage
because
in
evm
it's
possible
to
delete
the
contract
and
then
and
then
recreate
it
at
the
same
address.
D
D
D
D
Yeah
also,
another
thing
that
I
found
is
that
current
the
current
code
handles
the
transfers
without
call
date,
special
in
a
special
way,
just
as
a
transfer
without
a
call-
and
this
is
not
what
ethereum
does
so
in
ethereum.
Any
transaction
which
is
not
creating
a
new
contract
is
doing
a
call,
even
if
its
call
data
is
empty,
but
I
think
there
is
already
a
pull
request
to
change
it.
C
Yeah
this
most
of
these
were
known
known
issues,
including
the
the
gas
and
the
contract
collision.
Let's
see
what.
C
Yeah,
of
course,
everybody's
a
bit
overloaded,
so
such
items
are
not
yet
documented.
What
was
the
item
you
had?
The
third
third
item
was
something
novel.
Let's
see
you
didn't
take
another
I'll
look
from
the
recording
later.
A
D
C
B
It
was
fixed
review
issues
related
to
s
connector
of
fungible
tokens,
and
I
found
also
a
critical
issue
related
to
promises
flow,
and
I
fixed
that
also.
I
fixed
integration
tests.
B
We
have
a
lot
of
discussions
so
with
kirill
marcelo
joshua
about
algorithms,
and
we
go
through
code
to
understand
and
explain
how
currently
it's
all
works.
Also
we
decide
to
with
marcelo
separate
our
pr's
to
to
for
two-part
erc20
and
as
connector
false
and
currently
immersed
marcelo's
power
and,
as
I
know
currently,
integration
tests
not
work,
but
I
think
today
I
will
fix
also
I
completed
some
small
part
related
to
a
formal
specification
and
draw
a
diagram
for
that.
B
I
believe
it
will
help
to
understand
how
currently
all
things
work
and
so
that
that's
all,
for
my
part.
B
I
would
I
put
the
diagram
to
to
pr
and
also
link
to
a
link
to
promote
specification
also
put
to
vr.
Well.
A
G
I
helped
julian
a
little
bit
with
legal
structure
and
other
than
that
was
mostly
focusing
on
the
marker
testing.
So
I
implemented
the
transaction
batching
for
the
bully.
So
then
it
turned
out
it's
not
so
useful
in
practice,
because
there's
the
max
total
preferred
gas
limitation
and
near
core.
G
So
if
you,
if
you
combine
multiple
transactions,
then
the
overall
gas
limit
we
hit
it
pretty
quickly.
So
I
kept
testing
with
one
transaction
at
a
time.
G
Then
we
had
this
error
last
week,
which
was
exceeding
the
maximum
amount
of
gas
allowed
to
burn
per
contract,
and
that
also
turned
out
to
be
a
limitation
that
is
set
in
neocore.
G
So
I
try
to
increase
max
total
prepared
gas
and
max
gas
burn
to
800
tera
gas
for
the
testing,
which
then
allows
us
to
test
more
on
gurley
up
to
you
know,
40
641,
and
then
I'm
hitting
a
timeout
on
near
core.
G
So
when
you
do
an
rpc
call
on
on
near
core
after
10
seconds
it
times
out,
so
somehow
the
transaction
doesn't
go
through
within
these
10
seconds.
B
G
G
Setup
yeah,
so
I've
been
now
testing
all
on
local.
Then
I
also
had
some
non-deterministic
idempotence
problem,
so
you
know
if
you,
if
you
do
this,
call
to
near
core
in
near
core
once
the
transaction
goes
through.
If
you
do
the
same
call
again,
it
just
returns
to
the
previous
result,
but
it
seemed
here
that
there
was
some
problem
in
the
evm
that
it's
the
the
timeout
hit
and
then
some
state
was
changed.
C
I
think
I
think
we've
I
think,
we've
fixed
that
one
with
a
lot
of
non.
G
Issues
yeah,
so
I
can
retest
that
and
then
I
I
just
ran
it
on
on
robston
and
drinkaby
as
well,
where
I
get
these
two
errors
stack
on
the
floor
and
out
of
front,
but
I
haven't
investigated
them
further,
so
I
just
figured.
If
I
get
stuck,
let's
say
I'm
girly,
then
I
can
also
look
at
the
others
and
see.
C
G
C
That
was
with
having
transferred
genesis
stage.
C
Yes,
okay,
yeah.
Well,
then,
that
one
is
that
one
is
interesting,
I
might
admit
some
investigation
yeah,
although
this
is
now
highly
dependent
on
how
old
is
the
contract
that
you're
testing
it?
When
did
you
take
the
engine
copy.
C
There's
a
new
one:
okay,
yeah,
let's
see
in
conduct
today
later,
okay.
G
And
yeah
see
I
like
some
of
the
points
to
discussion,
so
that
is
the
status.
F
B
F
I'm
not
going
to
read
that
out,
yeah,
so
yeah
me
and
r2
tag
team
quite
a
bit
this
week
actually
to
solve
some
issues
and
to
go
through
some
parts,
but
yeah
just
highlights
for
basically
better
error.
Implementation,
as
I,
as
I
ran
into
an
issue
where
our
current
air
system
wouldn't
work
with
options
or
results.
F
It
can
be
improved
a
little
bit
more,
but
for
now
it's
fine,
then
I
removed
the
transfer
method
and
fix
fix
up
some
nonsense
with
the
help
of
r2.
So
frank
mentioned
that
already
there
was
the
small
bug
with
the
transaction
decoding
which
me
and
r2
went
through
and
then
yeah.
I
guess
after
that
was.
F
Sorry,
I'm
just
like
skipping
over
the
ones
we
already
spoke
about
in
the
call
sure,
okay,
yeah,
karel
and
evgeny,
and-
and
I
had
a
had
a
pretty
lengthy
call
this
week-
going
through
the
f
connector
practically
line
by
line
just
to
make
sure
that
everything
made
sense.
Then
I
then
I've
been
going
through
it
at
a
high
level
and
trying
to
think
if
I
can
think
of
a
better
way
to
do
it.
F
Of
course,
we're
running
out
of
time
right
now,
but
yes,
so
far,
it
seems
pretty
solid.
I
think
we're
gonna
do
one
more
call
still
and
then
we
should
be
good
on
that.
Then
there
was
a.
I
did
a
large
and
lengthy
review
of
all
of
the
or
engine,
and
some
of
the
fixes
that
you
can
see
there
are
just
things
that
I
came
across
and
then
countless
reviews.
A
Yeah
lots
of
work
from
you
this
week,
thanks
for
for
your
passion
with
all
of
this.
F
Big
quick,
that's
for
sure
I
I
just
want
to
make
sure
that
that
everything
is
is
ready,
ready
to
rock
and
roll
so
yeah.
I'm.
A
E
So
on
this
week
I
spent
most
of
the
time
reviewing
and
committing
to
multiple
pr's.
So
there
was
a
bunch
of
cars
that
was
reviewed
and
I
also
configured
and
set
up
the
server
for
the
espana
ventral
layer.
That
is
useful
for
the
front
end
for
laying
the
aurora
events
and
added
some
additional
power
scene
and
improvements
and
metrics
in
that
one.
I
also
this
week
had
a
lot
of
calls
things
with
pierre
on
the
front
end
with
joshua
and
evgeny
khan
to
deep
dive
and
analyze.
E
This
connector,
which
which
parts
are
most
crucial
to
take
a
look
in
and
to
give
joshua
like
a
bit
more
of
context
for
the
for
the
future
review,
and
we
also
think
with
marcel
and
evgeny,
about
the
pre-compiles
as
connector,
and
also
we
had
some
pr
conflicts
and
we
worked
on
the
solution.
How
to
solve
this
and
merge
everything.
E
And
that's
exactly
the
reason
why
evgeny
kapoor
mentioned
there's
a
relay
master
branch,
but
not
used
anywhere
at
the
moment,
because
this
is
a
common
part
that
is
needed
for
both
of
our
prs.
So
the
usage
of
this
euralia
vm
address
will
be
as
soon
as
as
this
power
submerged.
A
Okay,
marcelo
is
not
feeling
well,
unfortunately,
almost
all
of
this
week,
so
he
was
half
half
working
half
have
been
ill
so
wishing
him
great
health
in
in
our
not
very
simple
condition
of
the
world,
I
would
say
so.
Hopefully
this
is
not
coveted,
yeah
and
update
from
him.
He
obviously
put
it
here,
I'm
just
going
to
read
all
of
this
here.
A
So
marcelo
was
working
on
the
connect
on
the
connector
between
ethereum
and
the
evm,
which
is
the
erc20
connector
right
here
it
was
separating
the
logic
in
between
f
connector
and
your
c20
connector,
using
customer
c20
to
be
deployed
in
the
evm.
Well,
this
is
a
nice
thing,
so
an
additional.
Probably
this
is
an
additional
function
to
deploy
a
customer
c20
and
add
in
pre-compile
to
the
aurora
engine.
All
of
these
are
in
dprs.
Probably
some
of
them
are
ready
for
you.
The
others
are
in
the
draft
mode.
A
A
Nice
matt:
what
about
yourself.
H
Most
of
the
activities
were
around
the
aurora
website,
so
we
closed
out
a
lot
of
internal
to-do's
that
we
we
were
managing.
We
set
up
some
commercial
services
around
it.
There
were
some
aesthetic
tweaks
coming
from
the
broader
near
team,
some
content
additions
and
adjustments.
H
Oh
the
first
point:
we
had
to
update
the
the
bridge
to
handle
two-step
process
for
transfers
going
back
from
aurora
to
ethereum
and
then
the
other
miscellaneous
activities
around
the
launch
were
reviewing
some
some
requested
things
from
from
others,
a
number
of
meetings
and
coordination
with
marketing
in
the
data
teams
and
then
began
some
aurora
organization.
C
Michael
worked,
most
importantly
on
the
on
the
sanity
checks
that
we
need,
as
in
the
basic
test
coverage
of
the
engine,
was
lacking
and
and
that's
why
we
kept
discovering
some
some
edge
cases
and,
and
so
he's
had
a
a
good
start
of
what
will
be
soon
very
soon
comprehensive
sanity
checks
of
all
the
all
the
basic
engine
operations
and
I
plan
to
also
myself
expand
those
next
week
now
he
he
also
worked
on
the
f
connector
review,
which
is
what
I've
asked
a
number
of
people
to
do
as
a
high
priority.
C
Let
me
see
what
did
I
lose
on
my
notes,
okay,
yeah,
so
he
he
worked
on
a
bunch
of
pr
reviews
and
comprehensive
reviews,
and
then
he
also
finished
up
the
initial
block
cash
proposal
that
we
had.
So
that's
that's
in
in
near
core
and
undergoing
undergoing
review
with
a
lot
of
comments.
We'll
come
back
to
that
once
we
can
that's
pretty
much
his
week.
I
believe.
A
Cole,
pierre.
I
Yeah
hi
yeah,
so
this
week
I
started
with
the
aurora
web
app.
So,
like
mike
said,
matt
said
we
did
some
work
planning
for
the
new
process
for
unlocking
on
ethereum
instead
of
the
relayer
doing
the
unlocking
and
also
did
some
work
on
the
two
client
libraries
for
aurora,
which
are
currently
called
aurora,
erc20
and
aurora
ether.
I
I
The
deletable
transfer
functionality,
so
there
was
quite
a
bit
of
debate
whether
to
add
this
or
not,
and
so
in
the
end,
what
we're
doing
is
a
transfer
is
deletable
from
ethereum
on
a
transfer
from
ethereum
to
near
is
deletable
if
the
lock
hasn't
happened
yet
so
anything
in
the
approved
process
and
before
the
lock
is
broadcasted
can
be
that
transfer
can
be
deleted
and,
finally,
adding
the
archival
endpoint
to
unlock
some
users
who
are
having
trouble
finalizing
and
restoring
transfers
to
ethereum.
I
On
the.
In
your
side,
we
published
the
prerelease
on
testnet,
so
everything
is
mostly
ready
on
that
side.
Unless
we
have
some
tweaks
in
the
contract
or
function,
names
changing
and
finally
did
some
catching
up
on
the
connector
work
with
marcelo
and
curiel
and
spent
some
time
in
the
telegram
channel.
As
usual.
A
C
Quest
question
to
appear:
you
mentioned
the
the
new
library,
the
aurora
ether.
Where
can
I
find
that
library.
I
There
is
so
you
can
click
this
clickable
link,
it's
in
the
in
the
repository
with
all
the
connector
libraries.
B
C
So
you
just
raised
it
rested
for
discussion
or
do
you
do
you
need
somebody
to
review
it.
I
Well,
usually,
chad
was
doing
some
reviews,
but
he's
currently
out
of
office,
okay,
so
afterwards
yeah.
If
somebody
wants
to
review
it,
definitely.
I
So
there
there
is
some
the
the
current
work
in
this
pr
contains
the
functionality
for
sending
to
aurora
and
I'm
still
adding.
This
is
still
working
progress,
so
I'm
adding
the
functionality.
Okay,.
C
Given
that
our
next
next
topic
here
is
release
management,
let's
go
back
to
the
pr
alex
quickly
and
sure
this.
If,
if
this
is
not
ready
to
go,
then
it
should
be
in
draft
mode.
So
just
a
general,
not
everybody
do
do,
use
the
draft
functionality
in
github.
It's
it's
called
that
way.
Also,
you
don't
need
to
mark
it
as
work
in
progress.
It's
clearly
booking
progress
when
it's
draft.
A
C
A
A
A
We
are
receiving
very,
very
good
feedback
from
our
users
that
that
we
are
doing
a
great
job
with
support.
So
I
think
that
this
can
be
a
standard
for
us
actually,
so
the
more
the
the
better
support
we
are
able
to
give
to
to
the
users
the
better
they
will
feel
about
the
products.
So
this
is
a
very,
very
important
thing
and
at
the
moment,
when
aurora
is
going
to
be
released,
obviously
we
will
require
support
from
all
of
you
for
for
the
people
who
are
going
to
use
aurora.
A
Actually,
so
so,
please,
those
of
you
who
have
not
yet
joined
aurora
support,
telegram,
channel
and
or
development
channel
and
the
general
orange
channel
just
join
it
and
and
you
will
be
able
to
see,
what's
happening
there.
Obviously,
nothing
is
happening
there
right
now.
Only
just
some
people
that
are
wanted
to
to
get
an
access
to,
or
that's
it,
okay.
Let's
go
then
straight
into
the
discussions.
C
So
for
the
for
the
engine,
there
were
several
prs
merged
in
the
last
day
to
master
which,
although
they
are
very
useful
for
development,
are
not
something
that
we
would
want
to
be
deploying
to
testnet
as
yet,
and-
and
so
I
would
ask-
please
do
not
do
that-
I
am
the
release
manager
for
the
engine
and
the
master
branch
is
basically
mine,
so
don't
merge
to
master
unless
I'm
out
of
office,
so
I've
created
a
next
branch,
and
the
next
branch
will
be
a
good
place
to
merge
our
collaborative
development
efforts
so
that
everybody
can
take
the
latest
development
version,
but
the
master
should
be,
as
the
name
implies.
C
It's
the
golden
master
from
which
we
can
you
know,
press
cd,
cd
disks
in
the
original
meaning
and
in
this
case
master,
should
be
something
that
I
should
feel
comfortable
deploying
at
any
time
to
test
it.
C
A
Cool
now,
let's
discuss
gas
accounting
yeah.
E
C
Yes,
please
so,
let's,
let's
let's
be
clear
about
this-
that
master
is
something
that
is
imminently
ending
up
on
chain.
I
have
to
do
upgrades
to
beta
net
and
dismiss
fairly
often
it's
a
for
example,
in
sync,
with
the
relay
book
or
if
partners
need
something
else.
So
there's
a
fixer
needs
to
go,
so
master
needs
to
really
be
ready
to
go
anytime
on
chain,
so
don't
touch
it
otherwise,
and
those.
C
I
C
We
will
do
checkpoints,
we
need
to
do
more
testing
of
next
to
to
validate
it
using
exactly
the
kind
of
things
that
were
added
lately.
Sanity
checks,
the
the
we
have
the
beginnings
of
our
of
integration
tests
on
on
multiple
levels.
C
All
of
this
needs
to
needs
to
be
reach,
a
point
where
we
can
feel
comfortable.
That
next
is
actually
stable
and
then
it
becomes
the
new
master,
but
we
are
not
yet
there
right.
Now,
it's
a
little
bit
more
of
a
gut
feeling
and
we
don't
want
to
screw
that
up
the.
Let
me
let
me
describe
the
the
nightmare
scenario
here.
The
nightmare
scenario
is
that,
and
this
is
why
we
haven't
done
a
lot
of
updates
of
the
destination
contracts
in
the
last
month.
C
The
the
nightmare
scenario
is
that
if
we,
if
we
change
subtle
things
as
we
have
been
in
the
in
the
last
week
or
so,
fixing
fixing
non-handling
and
other
other
basic
things
of
the
engine,
then
if
we,
if
we
deploy
upgrades
to
to
let's
say
bayonet
where
we
change
this
and
we
deploy,
let's
say
daily
updates,
what
we
can
do
is
we
can
end
up
with
invalid
state
on
chain
that
is
basically
impossible
to
to
have
organically
arisen
in
correct
contracts
and
then
we'll
have
to
clean
up
that
mess
and
that'll
be
really
nasty.
A
Okay:
let's
talk
a
little
bit
about
gas
accounting.
C
Right
so
known
issue:
we
don't
we
don't
really
do
gas
accounting
now,
any
any
code
towards
gas
accounting
is
absolute
working
progress
of
low
priority.
That's
why
it's
not
implemented.
D
So
currently
like
for
release,
we
don't
really
talk
like
we,
it's
okay
for
us
to
have
a
couple
of
such
differences
and
behavior
between
ethereum
and
tvm,
as
long
as
we
consider
them
to
not
significantly
affect
existing
contracts.
But
eventually
we
want
to
resolve
this
differences
to
make
our
vm
behave
more
like
ethereum.
A
In
short,
the
answer
is
yes,
we
have
a
solution
for
this
that
is
going
to
be
implemented
for
some
period
of
time.
We
are
going
to
announce
it
during
the
the
release,
but
even
without
this,
this
gas.
D
C
Yeah,
so
they
I
would
expand
on
that
and
say
that
the
what
we
want
to
avoid
is
is
creating
all
state
unchained
state,
as
in
evm
state.
That
would
be
impossible
in
a
in
a
fully
100.00
compatible
evm
implementation.
So
it
would
be
nice
if
we
are
creating
something
on
chain
that
can't
be
but
other
than
that,
for
example,
in
particular
with
the
gas
accounting.
We
are
punting
this
question
because
we
simply
don't
have
time
for
for
the
launch.
C
D
C
Yeah,
and-
and
this
is
this-
is
a
big
to-do
in
the
code
about
the
inability
to
iterate
over
the
contract
state
and
as
as
eugenie
has
noted,
we
we
we
do
need
a
workaround
for
this.
I
believe
again,
you
had
proposals.
D
D
C
Yeah
now,
as
I
understand
it,
this
is
actually
our
only
choice
because
team,
the
workaround
that
you
had
proposed,
I
believe,
a
month
or
two
ago,
it
does
involve
changing
the
the
storage
scheme
and-
and
if
that's
the
case,
then
that
would
not
be
something
that
we
have
time
to
do.
D
Yeah,
so
I
have
a
multiple,
so
one
of
the
schemes
that
a
current
link
is
considered
am
considering
is
that,
instead
of
having
account
id
as
like,
instead
of
having
evm
account
id
as
a
part
of
storage,
key
basically
allocate
like
storage
buckets.
D
So
basically,
each
time
you
delete
and
then
create
a
new
account
and
you
storage
bucket,
is
allocated
to
this
evm
account,
and
so
it's
initially
emptier.
Basically,
they
can
be
just
numbered
by
a
sequential
integers
and
then
the
old.
So
when
the
account
is
deleted,
its
storage
bucket
just
becomes
unused
and
then
possibly
we
can
clean
up
in
the
same
way.
So
having
an
external
service,
provide
the
list
of
storage
keys
that
the
cvm
evm
will
just
delete
after
checking
that
the
corresponding
bucket
is
no
longer
used.
C
C
A
Mentioned
any
comments
on
this
approach:
are
we
all
okay
with
taking
it.
C
Well,
a
general
meta
meta
comment
here
is
that,
of
course,
what
we
would
very
much
like
to
avoid
is
having
having
a
storage
layout
that
we
scheme
that
we
need
to
actually
migrate
in
the
future,
especially
as
this
one
is
not
versioned
in
any
way,
but
just
due
to
time
constraints,
I
don't
think
we
we
have
a
chance
to
improve
on
this.
The
other
constraint
is
that
we
already
have
a
better
net
and
destnet
state
with
the
current
scheme
of
things
and
yeah.
C
A
Okay,
joshua,
can
you
can
you
comment
on
this.
F
A
Well,
so
are
we
actually
100
well
yeah?
So
what
what
was
the
point
that
you
wanted
to
raise?
Are
we
actually
100
sure
that
we
are
feature
complete
or
what
well.
F
We
are
not
feature
complete
yeah,
I
was
gonna,
say
that
and
then
and
then
next
week
of
course
we're
we're.
Gonna
we're
gonna
work
on
some
more
sanity
tests,
just
to
make
sure
that
the
the
implementation
is
correct.
So
I'm
gonna
be
a
part
of
that
r2
said
he
was
going
to
be
a
part
of
that.
I
think
michael
said,
he's
going
to
work
on
that
as
well
and
yeah.
A
G
I
mean
so
like
I
said,
for
the
for
girlie,
I
had
to
increase
some
limits
in
order
to
run
the
early
transactions
and
I'm
not
sure
what
that
means
for
running
on
the
same
main
net,
because
we're
probably
not
going
to
be
able
to
increase
these
limits
there
and
ran
into
them
with
some
pretty
yeah
early
transactions
on
goalie.
So.
A
G
A
Upper
limit
for
the
ethereum
transaction,
the
effective
limit
for
the
ethereum
transaction
that
we
will
be
able
to
to
host.
B
A
Ethereum
right
now,
the
upper
limit
is
just
the
block
size,
so
anyone
right
now
is
able
to
send
to
ethereum
transaction
with
the
size
of
15
million
gas
and
well
potentially,
it
can
be
included,
especially
if
you
will
going
to
use
a
pretty
high
gas
fee,
so
it
will
be
included
and
will
be
just
a
block
with
a
central
transaction.
A
Well,
some
gas
is
taken
for
the
multisig
or
two-factor
authentication,
so
this
is
this
is
actually
the
limit
and
for
one
block
there
is
a
1000
tera
gas
limit
limit
per
per
block,
and
we
will
not
be
able
to
to
change
it.
The
the
metric
here
actually
is
that
one
target
equals
to
around
one
millisecond
of
execution.
G
I
think
the
then
it's
probably
what
bowen
said:
it's
200,
I
think
for
the
for
a
single
transaction
and
300
for
combined
transaction
and
yeah,
because
he
said
that
they
always
want
to
have
five
transactions
in
a
block.
So
that
would
lead
to
this.
A
Thousand
yeah,
so,
okay,
so
let
me
put
it
here
batch
transaction.
There
is
a
thing
that
in
here
that
in
your
own
time,
which
is
a
batch
transaction
when
the
transaction
schedules
multiple
calls
actually
and
then
there
is
a
300
targets
per
base
transactions
and
200
tara,
gas
per
a
single
call.
G
C
G
A
These
these
this,
these
numbers
are
going
to
dictate
us
the
limitation
of
the
sizes
of
the
of
the
ethereum
transactions
that
we
can
handle,
so
that.
C
Well,
michael
already
did
we
have
figures
of
what's
taking
so
long
and
we
have
a
plan
to
improve
it.
It's
just
we're
gonna
take
some
time
to
get
it
out
there.
That's
actually
a
discussion
item
joshua,
you
think,
with
bowen.
Regarding
the
mid
june
protocol
upgrade
right
where
we
get
the
host
functions
for
evm
pre-compiles.
F
C
But
the
important
thing
here
is
that
do
you
have
a
deadline
by
which
you
need
to
have
those
merch
to
master.
D
D
D
Yeah.
That's
fair
for
forum
posts
that
pre-compiles
are
not
widely
used.
So
pre-compiles
are
not
that
that
there
are
not
that
many
calls
pre-compiles
within
like
normal
execution
of
like
common
ethereum
transactions,
but
verification
of
signature
is
in
fact
very
common.
You
need
to
verify
signature
on
every
transaction,
so
this
is,
I
think,
what
causes
most
gas
usage
currently.
C
Yeah,
so
is
easy.
Recovery
is
the
priority
for
sure,
but
okay,
so
joshua.
The
the
important
thing
is
to
figure
out
the
actual
timelines
here,
the
the
dependency
chain
for
landing
this
mid-june
end
of
june.
So
you
you,
you
need
to
get
a
little
bit
more
precise
figures
from
bowen
when
he
needs
and
expects
things
to
land
where
and
what.
D
We
will
probably
want
to
test
all
of
those
cost
functions
on
test
sets
from
ethereum
implementations
like
I
think
yes
and
others
have
some
sets
of
test
vectors
for
ethereum
compiles,
and
we
want
our
near
host
functions
to
be
compatible.
So
we
want
the
same
test
vectors
to
pass
on
our
near
host
functions.
C
Yeah,
I
believe
you
had
lifted
some
of
such
test
cases
joshua.
Where
did
you
look
for
test
cases.
F
Community
message
to
bowen
sorry:
can
you
say
that
again.
C
Yeah,
where
did
you
currently
source
your
test
cases?
My.
F
F
Okay,
yeah
yeah,
I
I
got
those
it
depends
like
I
got
them
from
the
ethereum,
like
some
of
them
had
really
good
test
cases
like
10
to
12
of
them
from
the
ethereum
yeah
eips
directly,
and
then
some
of
them
were
from
the
implementations
of
other
code
sources
that
I
could
actually
trust
which
ethereum
and
others
were
using,
but
but
most
of
them
for
most
of
them
were
from
the
the
actual
documentation.
C
F
C
F
G
Since
I'm
running
on
local
local
node,
I
can
also
test
when
a
pr
is
ready,
so
right
now
I'm
using
the
master
of
near
core.
So
that
means
everything
in
master.
I
can
I'm
testing,
even
if
it's
not
activated
on
mainnet
yet,
but
I
could
also
run
a
branch
that
has
these
pre-compacts
in
there.
For
example,.
C
Yeah
that
will
be
super
helpful,
especially
the
total
gas
used
up
until
sunblock.
So
as
soon
as
we
are
at
that
stage,
please
please
do
and-
and
in
fact
it
sounds
like
you
are
kind
of
blocked
with
the
the
bully.
There
might
be
another
discussion
item
that
okay,
you
have
some
investigations
to
do
on
the
other
test
nets
that
you
didn't
get
that
far
on
yet
but
beyond.
C
That
sounds
like
you're
blocked
on
the
pulley
until
we
can
unblock
you
and
then,
given
that,
maybe
it
makes
sense
that
you
would
actually
start
to
use
those
pretty
compass
already.
The
first
functions.
G
A
Well,
there
is
a
sense
to
do
it,
because,
eventually,
what
what
we
would
like
to
to
get
from
from
the
bully
is
that
we
we
can
run
the
full
we
can
run.
We
can
fully
run
gurley
or
rinkeby
or
or
something
or
other
networks
and
yeah,
and
for
this
for
some
some
of
the
transactions,
some
of
the
transactions
are
pretty
pretty
big
so
and
this
limit.
A
Unfortunately,
it
may
lead
to
that
the
limit
of
the
size
of
the
transactions
that
we're
scheduling
is
lower
than
this
15
million
against
for
the
maintenance
yeah
so
well.
The
good
thing
is
that
it's
not
all-
or
it's
not
every
day
when
such
a
big
transactions
are
happening
and
and
that's
why?
But,
however,
we
would
like
to
to
test
the
the
correctness
of
the
execution
yeah
right,
so
this
is
this
is
the
this
is
the
main
goal
of
bullying.
A
So
I
I
would
advise
you
on
the
local
setup,
with
the
the
pre-release
version
of
the
near
core
well
to
build
it.
There
use,
I
don't
know,
increase
the
the
gas
limits
like
100
times
literally
the
the
block,
the
block
one
block
will
take
a
little
bit
more
than
one
second
yeah
on
the
on
the
on
the
benchmark
hardware.
A
So,
potentially
you
would
need
to
have
you
would
need
to
have
you
know
you
would
need
to
rent
some
some
server
with
with
the
high-end
hardware
to
to
do
the
testing
a
little
bit
faster,
but
in
general,
let's
do
it
and
let's
check
that
all
of
the
transactions
that
are
there
in
the
ethereum
networks,
testing
networks
are
working
correctly.
G
A
G
We
have
a
dedicated,
so
it's
not
super
beefy,
but
it's
it's
pretty
beefy
and
I
increased
it
to
800
because
I
still
wanted
to
stay
below
the
1
000
per
block.
But
when
I
do
then
I
I
get
to
that
point
where
near
core
basically
doesn't
return
anything
for
10
seconds.
Yeah.
A
Yeah,
so
so
this,
so
so,
I
think
that
you
need
to
sync
up
with
bowen
on
this
problem.
I'm
not
quite
sure
what
is
happening
there.
Okay,
especially
if
it
happens
on
the
same
block,
yeah
every
time,
yeah.
A
A
G
G
And
generally
auto,
I
should
test
on
master
right
for
the
for
the
engine.
C
Yes,
yes,
next
is
going
to
be
to
bleeding
edge,
yeah,
okay,
so
go
go
with
master
and
you'll
you'll
need
to
enable
a
feature
to
be
able
to
use
those
host
functions
in
order
to
get
the
speed
up
so
looking
to
make
the
file.
It
should
be
there
yeah
from.
C
C
A
C
Yeah
yeah,
so
all
of
these
pre-compass
are
currently
and
including
easy
recover.
Use
is
currently
implemented
directly
in
the
contracts
which
bloats
things
and
you
need
to
switch
on
a
feature
to
get
rid
of
that
then
use
the
host
functions
once
once
you
have
a
near
core
which
has
those
okay,
all
right.
A
Okay
cool,
so
actually
I
do
think
that
potentially
bowen
will
will
go
with.
This
will
will
propose
this
upgrade
to
the
validators.
Sooner
than
later.
Obviously,
we
need
to
take
a
look
at
what
is
going
to
be
the
user
show
for
aura
the
first
days
the
first
week
and
maybe
just
not
to
overload
the
near
protocol
as
a
whole.
A
So,
let's
see
how
it's
going
to
work,
but
I
believe
there
are
some
some
some
data
that
that
suggests
us
to
do
it
sooner
than
late.
B
C
A
Yeah
so
the
sooner
we
will
have
it
so,
the
better
okay
cool.
So
one
additional
question
that
I
wanted
to
raise
said
so
this
is
from
my
site.
I
have
a
like
a
cognitive
problem
in
my
mind.
I
was
already
already
discussing
this
with
with
kirill.
A
So
maybe
there
is
a
there
is
a
solution
for
this,
so
in
general,
since
we
know
that
f
connector
is
a
part
of
aurora
engine,
and
this
is
the
only
way
how
aurora
engine
is
able
to
operate
is
to
to
implement
the
nap141
interface
for
bridged,
f,
yeah.
A
The
question
is
where
to
put
the
code
for
the
for
the
ethereum
side
of
that
connector,
and
I
see
here
the
problem
that
if
we
are
going
to
put
it
in
the
in
the
aurora
engine
repo,
it's
it's
not
about
the
the
engine
itself.
It's
like,
okay,
it's
just
just
just
some
piece
of
code
somewhere
out
there,
but,
however,
we
will
be
able
to
write
integration
tests
directly
in
this
repo
and
well.
A
We
will
be
able
to
to
test
everything
there
if
we
are
going
to
split
this
into
several
repos,
then
any
updates
of
the
eth
connector
logic.
It
needs
to
be
need
to
be
done
on
the
on
on
both
repos
and
I'm
not
quite
sure
how
to
organize
the
the
testing
of
this.
So
I.
D
D
A
D
D
So
the
user
won't
have
two
balances,
because
aurora
will
have
the
only
user's
balance,
but
at
the
same
time
the
bridging
itself
can
be
in
a
different
contract.
So,
for
example,
if
the
user
withdraws
his
near
like
near
vm
is
into
ethereum,
it
will
actually
send
them
to
the
connector
contract
on
your
blockchain,
which
will
do
the
bridging.
B
D
But
aurora
itself
will
be
basically
all
for
the
e
is.
It
will
be
like
almost
like
a
plane
near
an
ep
141
token,
except
that,
of
course,
the
same
balances
would
also
be
used
within
the
evm
itself.
As
a
base,
token
balance.
A
D
At
least
as
you,
I
think
you
don't
like
you
can
do
this
without
having
multiple
balances
per
user.
So
the
idea
is
that
bridging
logic
is
all
in
a
single
connector
for
everything
but
ins,
so
so
the
rc20
connector.
Currently
it
generates
the
account
ids
for
bridge
tokens
using
some
procedure
like
traditional
address.
E
I
I
remember
that
we
discussed
this,
that
it's
yes
makes
sense,
as
again
already
mentioned,
to
have
one
connector
like
rainbow
connector,
which
has
both
erc20
in-ear
and
egh
functionality
in
one
repo.
E
But
if
we
talk
about
the
current
status,
I
would
say,
as
the
disconnector
in
the
aurora
engine
has
not
been
even
merged
into
a
rare
engine,
I
would
suggest
to
postpone
this
discussion
because
the
solution
to
merge
everything
into
a
single
connector
will
require
to
do
additional
refactoring
and
now,
obviously
I
would
say
we
don't
have
enough
time
for
this.
I
think
in
these
months.
C
E
And,
moreover,
in
this
case,
after
the
release,
if
you
want
to
separate
the
logic
from
the
aurora
and
put
the
akh
logic
into
the
factory,
this
will
also
require,
like
a
quite
thorough
release,
upgrade.
A
D
Well,
surely
we
will
need
many,
but
we'll
have
many
reasons
to
do
upgrades
of
all
the
smart
contracts.
So
we
should
expect
this
in
any
case
now
independent
on
this
on
the
decision
in
in
for
individual
components
so
for
aurora
engine.
There
are
many
reasons
we'll
need
to
upgrade
it
and
for
connectors.
I
think
there
would
be
reasons
to
upgrade
them
in
any
case,.
A
Okay,
so
right
now,
ethereum
side
effect
connector
is
located
is
located
in
the
earth
connector
repo,
while
the
near
side
of
this
connector
is
look,
it
will
be
located
after
the
merge
in
aurora
engine.
Is
this
correct.
C
Arter,
can
you
repeat
that,
unfortunately,
I
I
had
to
tune
in
something
else.
A
Yeah,
so
I'm
saying
that
the
ethereum
side
of
that
connector
is
located
in
the
nth
connector
repo,
while
the
near
side
of
that
connector
after
the
merge
will
be
in
or
in
aurora,
correct,
yeah
and
yeah.
So
this
will
will
most
probably
mean
that
the
deployment
procedures
for
for
aurora
are
going
to
be
a
little
bit
more
complicated.
A
A
E
A
So
once
again
fees
for
withdraw
from
aurora
to
to
ethereum,
yes,
okay,
so
the
user
just
pays
the
fee
for
this
transaction
to
the
relayer
to
the
rpc
proxy
and
then
on
the
other
side,
he
would
need
to
schedule
additional
transaction
for
finalization
of
this
transfer.
E
Yeah
I
understand
this,
but
in
this
case,
if
the
user
pastes
it
in
the
raw
adh,
there
will
be
needed
to
have
some,
maybe
trust
with
relay,
or
I
would
say,
because
the
most
trustless
way
is
will
be
when
the
user,
in
this
case
the
layer
who
submits
the
transactions
on
the
ethereum
site,
he
will
get
the
appropriate
amount
of
fee
on
the
ethereum
site,
which.
A
A
A
Then
the
effect
of
the
inclusion
of
the
transaction
is
breached
back
back
through
the
bridge
and
then
and
then
it
will.
There
sends
a
transaction
to
unlock
the
funds,
the
the
locked
fee
to
unlock
on
the
ethereum
on
the
to
to
aurora
yeah,
so
he,
your
relay,
should
use
this
transaction
that
he
submitted
on
the
ethereum
side
and
yeah
and
rick
and
unlock
the
fees
that
then
he
was
paying
actually.
A
So
this
is
yeah,
and
this
is
not
a
simple
thing
to
do
so
we
just
do
not
have
that.
Second,
second,
this
is
an
additional.
Obviously
we
can
implement
this
having
a
bridge
already
in
place,
but
this
is
an
additional
piece
of
logic
for
the
connector,
so
yeah
this
thing.
This
is
exactly
the
reason
why
we
cannot
do
it
the
simple
way,
and
most
probably,
we
are
not
going
to
implement
it.
A
Like
this,
we
are
going
to
to
implement
a
little
bit
more
profound
solution,
with
the
fast
withdrawals
so
really
will
be
able
to
finalize
the
transfer
even
before
the
transfer
is,
is
transferred
over
the
bridge
to
the
ethereum.
A
Okay,
so
let
me
put
it
here,
our.
A
A
Cool,
so
let's
talk
a
little
bit
about
the
the
next
week
ahmed:
what's
what
what
are
you
going
to
be
focusing
on?
What
are
your
plans.
B
Yeah
so
mainly
from
my
site,
I'm
gonna
start
work
on
the
first
first
issue
on
the
on
the
bridge,
and
maybe
I'm
also
I'm
gonna,
look
at
the
if
connector
code,
so
that's
mainly
my
plan
for
the
next
week
and
I'm
gonna
iterate
with
marcelo
next
week.
Also
regarding
that
to
make
sure
that
I
am
like
already
well
imported
on
the
on
this
yeah.
So
that's
amazing.
A
I
would
recommend
you
to
start
with
some
some
some
tests,
so
you
will
it
will.
You
will
familiarize
yourself
with
the
with
the
code
a
little
bit
more.
There
is
a
long
list
of
tests
that
that
we
would
like
to
implement
for,
for
the
bridge.
A
Sure
so
for
on
my
site,
I'm
going
to
fully
focus
on
on
on
the
release,
management,
release
or
forward.
So
I'm
going
to
focus
on
this
or
like
release
management,
yeah
lots
of
stuff.
There,
investors
finalizing.
A
Nice
arthur.
C
Yeah
on
my
side,
it's
pretty
much
like
last
week,
last
week's
list,
but
even
longer
so
pure
validation,
devex
documentation
still
need
to
finish
the
websocket
support
and
it's
been
requested
by
certain
partners.
We
need.
We
need
the
definite
faucet.
That's
actually
mostly
a
frontend
task
at
this
point.
So
if
somebody
wanted
to
help
me
out
on
that,
that
would
be
great,
hard
hat
plug-in
needs
to
be
finished.
We
need
some
quality
of
service
limits,
given
the
gas
use
and
so
on.
C
I'm
syncing
with
bowen
on
that,
and
we
need
to
really
make
sure
that
we're
going
to
hit
this
midtune
protocol
upgrade
window.
So
I
need
to
coordinate
everybody
on
that.
D
Yes
of
aurora
engine
and
possibly
other
pull,
requests
otherwise
changes
discussions
of
how
to
are
we
going
to
do
stuff.
A
Cool,
I
would
encourage
everybody
who
is
here
on
the
call,
since
evgeny
is
our
security
expert,
just
in
case
in
case
there
is
some
critical
piece
that
you
are
developing,
just
pin
him
and
and
say
that
hey
you've,
given
me
a
please
review,
so
it's
not
going
it's
not
going
the
like
the
long
routes
just
pin
directly
okay,
you've,
given
your
heart
of.
What's
what
what's
your
plan.
B
So
I
will
focus
to
testing
a
new
functionality
related
to
erc20
and
also,
I
believe
we
should
do
some
some
pictures
of
the
merging
functionality
of
marcelo.
So
and
after
that
we
should
all.
The
things
are
pretty
good
to
test.
A
Okay,
frank.
G
Yeah
well,
I
talked
to
bone
about
the
problem
on
on
gurley
with
the
timeout
look
into
the
other
two
test
net
issues
and
also
figure
out
how
to
run
the
pre-compiled,
the
new
things.
So
no
testing,
basically.
A
Oh
okay,
joshua!
I
I
see
that
you,
oh
you,
have
already
written
it
here.
F
Sure
yeah
just
more
over
engine
review
documentation
because
there's
a
lot
of
stuff
that
popped
up
this
week,
f,
connector
finalization.
I
still
got
one
more
call
with
the
corel
and
and
evgeny
evgeny,
and
then
also
rare
engine
tests,
and
that
was
more
so
more
of
satin
tests.
Michael,
did
a
fantastic
job
with
with
the
start
of
them
and
of
course
we
could
always
do
some
more
to
make
sure
everything
else
is
just
working
yeah.
That's
why
I
plan
for
next
week.
A
Okay,
cool
kirill.
Is
it
yours.
B
E
Yeah,
so
my
plan
is
similar
to
the
one
that
I
have
for
this
week,
so
I
will
just
and
maybe
adjust
some
aurora
compiles
if
it's
needed
and
try
to
test
the
aurora
c20
connector
interaction
when
it's
ready-
and
I
will
continue
on
pr
reviews-
I
mean
the
new
one
prs
that
may
appear
on
the
next
week
and
the
color
engine
review.
A
A
A
No,
it
is
me
more
engine
tests,
launch
activities
will
chat
with
art,
okay,.
H
Yeah
so
just
bridge
bridge
testing
and
that's
finalized,
the
finalizing
of
the
website
and
then
the
launch.
I
Yeah
working
on
the
integration
of
aurora
to
ethereum
client
libraries
planning
this
as
much
as
possible
and
arto.
Once
we
have
first
deployments
and
rpc
available,
that
would
be
great
on
testnet.
A
Okay,
so
at
this
moment
I'm
going
to
to
stop
the
screen
sharing
just
checking
what
is
in
our
chat
happening.
C
In
general,
in
general,
I
believe
we
have
a
growing
number
of
viewers
on
the
stream
yeah.
A
Okay,
that's
nice!
So
that's
nice!
What
is
the
biggest
goal
for
near
to
achieve?
Well,
unfortunately,
we
cannot.
A
We
cannot
talk
for
for
the
whole
company,
but
our
biggest
goal
right
now
is
to
deliver
aurora
and
and
help
ethereum
projects
to
scale
action.
So
this
is.
This
is
all
this
is
the
ultimate
goal
of
the
aurora
project,
so
so
this
is
something
that
we
are
working
hardly
on.
I
believe
lots
of
other
people
in
the
in
our
org
are
working
on
on
other
things:
okay,
100,
000,
tara,
gas,
limit,
yeah.
A
Okay,
okay
and
well,
thanks
for
the
feedback
that
the
technology
is
ahead
of
time,
we'll
see
it
depends
on
when
we
are
going
to
to
release
it.
A
H
Could
I
just
mention
one
thing
that
I
forgot
to
mention
earlier:
I'm
setting
up
a
base
camp
instance
for
aurora
and
everyone
will
be
getting
invites
to
that
and
you'll
probably
be
getting
some
invites
to
some
projects.
You
don't
necessarily
have
to
jump
in
there
and
do
anything.
Yet
it's
just
kind
of
a
pilot
thing,
but
you
will
be
getting
a
few.
H
A
few
invitation
emails
if
you
want
to
go
ahead
and
confirm
your
confirm
your
account
in
base
camp
that
that's
fine
but
I'll
need
some
time
to
get
it
all
set
up
and
and
I'll
write
an
introduction,
an
introduction
message
there
explaining
how
how
it
works,
probably
at
in
you
know
after
the
end
of
the
next
week.
A
Okay,
that's
cool
we're
going
to
use
basecamp
for
for
the
as
a
global
task
management
system
for
aurora
yeah
and
an
additional
question.
I
mean
any
comments
on
becoming
a
validator
costs.
So
this
this
is
a
good
question
to
the
chain
team.
A
But
from
what
I
know,
the
current
limitation
of
three
million
near
or
for
becoming
an
element,
a
validator.
It
is
going
to
be
decreased
and
the
number
because
the
number
of
seats
for
the
validators
is
going
to
be
increased
from
100
right
now
to
400
pretty
recently
so
in
the
in
the
following
couple
of
months.
We'll
have
this
protocol
upgrade
yeah,
and
this
is
exactly
the
answer
to
your
next
question.
So
this
is
exactly
the
solution
for
the
decentralization
of
the
of
the
validators.
A
Okay,
wait
in
a
couple
of
seconds
three
seconds
or
something
for
additional
questions.
A
Yeah
yeah
yeah.
We
are
actually
on
time.
Okay,
thanks
everyone
for
watching.
Hopefully
this
was
informative
to
you
yeah
and
see
you
next
week,
goodbye
everybody
bye.