►
From YouTube: Aurora Update [2021-04-23]
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
it
seems
like
we
are
live,
I'm
not
100
sure,
because
let's
see
it
on
the
youtube
that
this
stream
started.
Okay,
but
hopefully
it
is
so
hello
everybody.
Last
week
we
have
decided
to
compose
two
calls
together:
the
bridge
weekly
update
poll
and
evm
weekly
update
call.
A
This
is
very
in
line
with
the
composing
of
the
of
the
development
teams
and
having
more
and
more
things
that
the
teams
are
working
together
with
each
other.
So,
for
example,
yeah
we're
going
to
talk
quite
a
lot
about
this.
During
this
call,
so,
starting
from
today
we
are
going
to
have
a
single
aurora
update,
call
it
will
last
for
an
hour
and
a
half
every
friday.
At
this
time
you
will
be
able
to
see
it
yeah.
So,
let's
start
I'm
going
to
share
my
screen.
A
So,
let's,
let's
start
with
with
the
goals
and
and
with
the
agenda
yeah,
let's
start
with
the
agenda.
So
here
is
our
typical
agenda.
Guys,
do
you
have
anything
to
discuss
specifically
to
discuss
during
today's
call.
B
I
think
we
will
discover
things
to
add
as
we
go
through
the
updates.
Okay,.
A
Sure
cool,
so
our
status
rainbow
bridge
is
he
is
working
okayish.
We
have
found
out
that
there
is
at
least
one
one.
Additional
problem
that
needs
to
be
fixed
has
some
some
of
the
transfers
from
ethereum
to
near
you
know.
We
have
updated
the
client
contract
and
now
the
block
edition
consumes
up
to
70
less
gas
on
ethereum,
which
is
super
cool
because,
instead
of
paying
something
like
60
f
per
per
a
month,
we
are
now
going
to
pay
around
18.
A
If
f
for
for
maintenance
of
the
bridge,
we
are
joining
our
forces
or
to
fast
forward
aurora
development
and
delivery.
A
So
there
is
like
a
very
big
movement
right
now
to
to
release
aurora
as
soon
as
possible.
The
target
date
for
this
is
the
beginning
of
of
may.
I
will,
I
would
not
say,
what's
the
the
actual
date
that
we
haven't
planned,
but
I
I
can
say
er,
demay
and
yeah.
There
are
lots
of
things
that
needs
to
be
done
before
this.
A
These
things
are
obviously
around
the
the
technical
side
of
it,
but
also,
but
also
things
around
marketing
pr.
Some
partners
that
are
coming
on
board
the
legal
structure
of
aurora
projects
and
and
so
on
and
so
forth,
so
so
yeah.
These
are
all
things
out
that
align
outside
the
the
technical
discussions
and
technical
capabilities
of
the
project,
but
they
are
also
very
important,
especially
at
the
very
beginning
of
the
of
the
product
operations.
A
So,
let's
go
closer
to
the
the
weekly
update,
so
there
is
there
is
also
there
are
also
here,
the
items
that
were
suggested
by
max
to
have
planned
items.
What
is
done
and
and
the
plans
for
the
next
week,
I'm
going
to
to
fill
in
this
information
by
myself,
but
I'm
going
to
once
again
review
the
the
notes
from
the
call.
So
let's
do
the
weekly
update.
A
I
will
start
with
myself.
I
was
heavily
involved
in
aurora
management.
This
week
we
were
discussing
a
lot
about
potential
aurora
token,
a
separate
aurora
token
and
the
legal
structure
around
the
company
were
you
were
thinking
how
we
can
launch
this,
so
it
will
be
convenient
to
maintain
and
convenient
to
start.
This
aurora
is
a
separate
business.
A
Both
that
are
connected
to
aurora
and
that
are
line
outside
aurora
and
and
also
a
number
of
marketing
activities,
including
maker,
call
the
call
with
maker
community
and
violence
ama
with
kazakhstan
community
yeah
and
was
just
helping
the
people
here
and
there
a
little
bit
with
the
deployment
of
the
new
version
of
the
bridge
a
little
bit
with
discussions
on
the
as
connect
and
stuff
like
that.
B
Yes,
it's
been
a
busy
week,
I'm
putting
links
as
well,
so
you
can.
You
can
always
show
what
we
are
talking
about
on
screen
as
we
go
through
them.
So,
most
importantly,
I've
been
working
on
the
relayer
for
the
past
week
intensively
and
that
has
well
it's
basically
a
rewrite
of
the
relayer
for
production
readiness.
B
So
I've
composed
the
comprehensive
list
of
you
can
maybe
show
the
read
meter
in
the
relay
repo
yeah
compose
a
comprehensive
list
of
rpco
operations.
We
need
to
support
reviewed
each
one
that
we
do
correct,
parameter,
handling
and
implemented
a
lot
of
them
that
were
missing,
there's
still
a
handful
that
I'm
missing
and
they
will.
They
will
need
a
little
bit
more
work
next
week.
B
In
addition,
I
I
made
the
relay
you're
ready
for
production
by
adding
comprehensive
logging
of
requests
and
responses.
So
we
can
troubleshoot
issues.
The
logging
is
keyed
by
a
request
id
a
unique
identifier
for
each
request,
which
means
that
we
can
track
down
problems
when
people
report
them.
We
also
have
rate
limiting
to
prevent
abuse
and
for
persistent
abusers.
We
have
ib
blacklists
and
you
know
in
order
to
make
this
easy
to
manage,
we
have
a
configuration
files
and
I've
improved
the
local
key
management.
B
This
is
where
we
will
be
moving
the
the
documentation
for
our
specifically,
as
in
the
bridge
and
uvm
both
and
the
that's
using
the
the
mk
docs
content
management
system,
which
I'm
sure
some
are
familiar
with,
and
you
can
anybody
working
on
a
bridge
as
well.
You
can
just
add
documentation
in
in
the
github
repo,
and
I
also
began
working
on
a
hard
hat
plugin
for
aurora,
which
I
I
think
will
be
finished
next
week.
So
yeah
busy
week.
B
There's
multiple
reasons,
one
one
is
that
filters:
user
defined
filters
need
to
be
persisted
between
requests,
and
but
the
more
important
reason
is
that,
in
order
for
us
to
retrieve
transaction
data
for
for
past
f
transactions
that
is
necessary
to
index,
we
can't
find
it
ad
hoc
when
we
need
it.
We
have
to
actually
keep
track
of
that.
So
it
means
that,
in
addition
to
the
relay
itself,
there
will
be
an
index
or
process
for
which
I'm
I'm
tapping
the
existing
near
index
of
framework.
A
And
how
is
this,
I
don't
know
intersec
intersected
with
with
the
ordinary
indexers
that
are
there
for
ethereum
ecosystem.
B
A
B
It
has
nothing
to
do
with
either
existing
ethereum
indexes
nor
existing
near
near
indexes.
So
this
is
quite
specific
for
our.
C
B
A
Yeah
sure,
if
kenny
kapoor,
how
are
you
I.
D
Was
working
mostly
on
reviewing
proquests,
but
also
finally,
we
integrated
this
optimization.
That
was,
we
already
said.
I,
and
I
was
also
reviewing
why
our
near
to
e3
layer
is
not
working
as
well
as
you
want.
So
there
are
some
problems
some
of
the
times
it
it
stops
working
properly
and
currently,
if
this
happens,
we
need
to
manually
restart
it.
So
I
reviewed
logs
and
probably
at
some
point
we
are
going
to
change
it
so
that
it
doesn't
need
to
be
restarted
as
often.
A
Okay,
okay,
you
can
you
fan
of.
E
This
week
I
started
implementation
new
logic
related
to
earth
connector,
and
we
discussed
a
lot
of
things
with
alex
chavchanka,
and
for
that
time
it
was
implemented
about
95
percent.
So
next
week
I
think
we
should
start
somewhat
fixing.
If
we
we
will
find-
and
we
will
start
testing.
A
E
Oh
I'm
sorry,
I
added
continuous
integration
to
the
evm
bully
on
github
fixed
all
the
lintel
errors,
so
the
code
base
is
pretty
clean.
Now
I
debugged
some
error
with
the
aurora
script,
so
I
can
properly
initialize
the
contract
state
on
testnet
because
we
have
these
ownership
checks
in
the
the
engine
for
the
fully
specific
methods.
E
Then
I
encoded
the
genesis
state
on
the
bully
side
and
decoded
it
on
the
engine
side
and
then
we
I
implemented
it
in
the
begin
block.
So
we
can
set
the
initial
balances
because,
right
before
we,
the
first
transaction
failed
with
the
token
transfer,
because
we
didn't
have
the
money
we
want
to
transfer.
Now
that
works
I
mean
now.
Can
we
play
basically
girly
up
to
block
12
842
and
there
I
it
fails
with
an
exceeded.
C
A
C
E
A
Okay,
cool
joshua:
what's
on
your
side,.
E
C
I
fixed
a
serialization
bug
with
library,
which
I
noticed
quite
a
bit
of
libraries
kind
of
omitted.
C
Then
I
added
lots
of
new
public
api
to
the
bn128
library
and
then
I
completed
it
then
finished
all
the
pre-compiles
for
the
aurora
engine
wrote
all
spec
tests
and
I
guess
I
rewrote
that
twice
yeah
then
I
wrote
all
spec
tests
for
the
for
the
pre-compiles
and
then
after
that
I
just
added
a
transfer
method
method
to
the
engine,
which
was
to
unblock
frank
with
the
evm
bully.
C
But
then
I
wrote
the
code
for
the
faucet
wait
because
I
saw
it
sitting
there
in
the
in
the
to-do
list
and
I
thought
it
was
easy
enough
to
tackle.
I
called
it
the
make
it
rain
method.
We
could
change
that
if
you
guys
want,
but
that's
funny
and
then.
Lastly,
I
started
work
on
the
engine
implementation
and
today
I
worked
on
the
evm
math
api
because
that
hasn't
been
touched
in
the
last
couple
of
weeks
and
it'd
be
nice
to
get
that
moving
a
lot
again
and
then.
C
A
Yeah
cool,
as
far
as
understand,
for
example,
the
pre-compiles
are
now
in
the
pull
request
is:
is
this
correct.
A
Yeah,
it
will
be
cool
guys
if
you
would
be
able
to
to
put
the
links
to
the
to
the
pull
requests
like
arta
did
so
people
if
they
would
like
to
get
some
additional
info,
they
will
be
able
to
to
take
a
look
at
some
particular
things.
Sure,
okay,
kirill.
What's
on
your
side,.
C
Week
several
times
since
guinea
and
alex
on
the
new
connectors
design,
also,
we
spent
some
time
with
marcel
on
design
discussions,
so
vrc20
connector.
C
B
East
to
near
eventual
air
which
relays.
C
A
F
Yeah
well,
I
was
reviewing
several
pr's.
In
particular,
I
was
reviewing
an
implementation
of
in-ear
connector,
transferring
near
to
ethereum
and
leaving
some
feedback
there.
Also
main
task
of
this
week
was
building
the
rc20
connector.
I
was
working
on
this
in
collaboration
with
kirill
who
was
building
the
relayer.
F
F
Well
right
now,
yesterday
we
found
like
last
week
we
found
an
issue
building
some
proofs
on
robsten,
and
yesterday
we
found
the
same
issue
on
mainnet
and
I'm
working
on
this.
It's
like
the
issue
is
only
about
building
the
proof,
not
about
checking
them,
so
only
change
will
be
on
our
under
layers
itself
and
well
as
a
side
task.
I
was
reorganizing
our
repositories
moving
them
to
aurora's
near
organization,
removing
install
branches
and
setting
up
few
more
configurations
to
remove
branches
automatically
yeah.
A
F
And
so
almost
all
the
work
this
week
was
related
to
the
aurora
launch.
Most
of
the
time
was
designing
and
developing
the
aurora
bridge,
creating
draft
content
for
the
site.
C
Yes,
so
most
of
the
week
doing
some
evm
contract
benchmarking
work.
It's
it's,
maybe
a
misnomer
to
say
that
it's
about
evm
benchmarking.
It's
really
more
about
benchmarking.
The
underlying
near
run
time
that
the
contract
runs
in,
but
there's
there's
a
pull
request
there
and
then
I
did
do
some
review
of
the
east
character
logic,
but
it
was
before
the
the
new
changes
were
put
in.
So
I
haven't.
I
haven't
looked
at
the
new
stuff,
yet.
F
Yeah,
let
me
get
with
us
so
this
week
I
did
some
in-ear
client
development
so
now
we're
I'm
waiting
to
have
a
a
test
net
deployment
to
start
the
integration
with
the
front
end,
so
I
mostly
went
through
it,
so
it
should
go
pretty
fast,
but
yeah
if
we,
if
we
can
have
this
this
first
draft
on
testnet,
that
would
be
great
to
get
things
moving.
F
A
Yeah
thanks
for
doing
this,
big
thanks
for
marcelo
and
upr
for
making
for
being
active
and
supporting
the
current
rainbow
bridge
users
and
that's
cool
okay.
Does
everyone
get
a
chance
to
to
talk.
A
B
I
added
an
initial
discussion
item.
I
had
the
same
same
question,
probably
as
you
alex
about.
Maybe
we
could
get
some
initial
performance
figures
from
the
first
runs
of
the
bully.
I
I'm
sure
we
can
improve
things
but
would
be
interesting
to
know
yeah
and
how
it.
B
B
If
one
were
somehow
able
to
compare,
compare
the
final
block
state
at
just
before
the
block
we
failed
at
with
the
state
of
gurley.
At
that
point
to
see
whether
we
have
any
discrepancies,
I
mean
one
would
hope
we
don't
have
any
discrepancies,
but
I
imagine
that
could
be
a
bit
of
a
side
project
by
itself.
What
do
you
think
frank.
E
Yeah,
I
think
I
think
it's
not
worth
putting
in
the
effort
there
right
now,
because
if
the
transactions
succeed,
we
can
you
know
kind
of
indirectly
see
that
the
state
at
least
is
correct.
Absolute
point.
B
Yeah
yeah,
that's
that's
what
I
meant
that
it's
probably
just
good
for
you
to
keep
unblocking
the
blocks
that
that
fail
and
keep
moving
forward
yeah
and
maybe
maybe
at
some
point
we
can
pull
somebody
to
do
the
state
comparison.
E
B
Well,
even
without
batching,
it's
it's
an
interesting
thing
to
know
how
much
it
might
clock
in
that.
But,
of
course
it's
it's
not
particularly
useful
measure.
It's
just
getting
some
baseline
understanding.
E
Well
right
now
I
mean
you
have
this
one
about
one
second
per
transaction,
because
you
know
it
always
waits
for
the
confirmation,
so
yeah.
B
A
We
actually
need
to
to
get
not
only
the
performance
which
which
will
save
us.
What
is
the
amount
of
of
time
or
what's
the
amount
of
transactions
that
we
are
able
to
fit
in,
but
also
some
numbers
from
the
like
some
constants?
So,
for
example,
what
we
can
what
we
can
calculate-
and
this
will
be
pretty
important
things
like,
for
example,
how
much
oh,
my
gosh
yeah,
so
how
how
much
ethereum
gas
we
can
fit
into
300
terra
gas
near
terra
gas.
A
This
is
one
thing.
Another
thing
what
we
can
calculate
is
how
much
gas
or
like
near
gas
does
it
take
for
simple
ethereum
transactions
like
yeah
base,
talk
and
transfer
or
erc
to
only
transfer
yeah.
C
C
The
final
results
are
still
a
work
in
progress.
There's
a
couple
of
things.
I
want
to
double
check,
but
I
I
can
100
get
it
next
week
and
for
internal
purposes.
I'll
probably
have
it
on
monday.
B
I
think
we
need
it
for
at
least
a
few
different
things.
Elia
elia
wants
it
badly,
of
course,
and
we
need
it
for
for
planning
alex,
and
I
and
matt
will
need
it
for
marketing
purposes,
as
in
for
the
content
for
for
the
website,.
A
Absolutely-
and
this
is
also-
this
is
also
important
for
our
for
our
partners,
so,
for
example,
if
if
they
have
a
very
you
know,
computation
intense.
A
B
We
have
a
standard
pre-compiled
test
case
in
solidity,
which
exercises
all
of
the
istanbul
pre-compiles,
and
it
would
be
worthwhile
to
to
collect
the
amount
of
gas,
a
short
amount
of
gas
used
by
that
and
and
then
see
how
it
changes
as
we
deploy
the
protocol
upgrades.
B
So
right
now,
as
a
reminder
of
everybody,
the
all
of
the
pre
compiles
are
implemented
directly
on
the
user
level,
as
in
in
the
in
the
contract
itself,
and
that
will
be
slow
given.
Given
that
they
are
well,
it
will
be
expensive
in
terms
of
gas
given,
given
that
we're
talking
about
the
elliptic,
math
and
so
on,
but
the
the
pr
is
open
in
near
core
for
pushing
pushing
down
this
to
the
host
functions
and
that's
what
joshua
mentioned
that
he
needs
to
push
that
to
finalization.
D
C
Yeah
yeah
yeah
it
was,
it
was
mostly
just
a
blank
to
I
I
added
a
few
more
arguments
to
it,
as
was
suggested
by
kaplan
and
yeah.
I
I
started
working
on
on
that
today
and
I
want
to
get
that
done
over
the
weekend,
but
I
think
that
was
only
the
real
suggestion
that
that
all
that
needed
to
be
done
to
wrap
all
that
up
and,
of
course,
like
the
the
gas
I
gotta
run
the
gas
costs
again.
B
Yeah
well,
I
would
suggest
joshua
that
post
post
an
update
to
the
ticket
on
on
what
you
still
plan
to
do
and
and
then
float
that
with
everybody
who
needs
to
sign
off
on
it,
including
you're.
Getting.
D
B
Yeah
for
sure,
and
also,
of
course,
the
standard
pre-compost
test
case,
it's
a
good
start
to
to
put
that
into
in
the
near
nearby
unit
unit
testing,
in
terms
of
rust,
to
exercise
the
host
functions.
B
Well,
the
the
pre-compiled
cost
is
important
for
the
for
the
transfers.
We
would
also
want
to
measure
the
in
nfd
operations
potentially,
but
I'm
not
sure
that's
of
interest
to
that
many
partners
lower
lower
priority.
A
A
What
is
the
amount
of
what
is
our
this
is
literally
transforms
into
into
how
much
transactions
we
can.
We
can
handle
literally,
and
it
also
transforms
into
into
yeah
into.
B
How
much
does
a
typical
transaction
cost?
Concretely,
that's
what
everybody
cares
about.
E
Yeah
sounds
good
yeah.
I
think
it's
worth
mentioning.
I
also
discussed
this
with
michael
that,
basically,
what
he's
doing
and
what
we're
trying
to
do
with
bully
are
like
different
levels.
So
bully
is
more
in
a
micro
level,
where
we
try
to
check
correctness
and
maybe
over
performance
transaction
throughput
with
what
we
have
in
the
test
net.
But
then
things
like
what
michael
is
working
on
is:
it
makes
more
sense
to
have
it
as
isolated
test
cases
more
on
the
micro
level.
B
Yeah,
that
said,
that
said,
frank
we
we
do
want
ultimately
to
know
the
let's
say
that
you
do
a
girly
run.
We
we
want
to
see
what
is
the
total
gas
consumed
for
that
run
and
then
bring
that
optimize
that
over
time,
but
but
of
course,
it's
far
more
important
that
you
are
able
to
finish
around
and
then
to
count
the
cost
of
it.
B
We
have
some
people
on
the
call
who
might
know,
there's
a
the
there's,
a
couple
of
rpc
methods
that
are
difficult
to
implement
in
the
into
relay,
because
we
we
don't
have
as
far
as
I
can
tell
in
the
near
api,
but
whether
we're
talking
about
the
json
rpc
api
or
we're
talking
about
the
library
that
wraps
it.
We
don't
have
the
ability
to
look
up
a
transaction
just
by
its
hash.
We,
we
also
have
to
know
the
account
id
that
sent
the
transaction
and
yeah
I'm.
A
I
think
I
think
I
know
that
the
so
the
problem,
the
problem
of
of
the
fact
that
we
need
to
provide
the
account
id
here
is,
that
is
that
contracts
potentially
can
be
located
in
different
charts
right.
So
so
that's
why
that's
why
you
need
to
provide
what
is
the
account
id
in
order
to
like
to
execute
this,
and,
but
actually
you
can
just
use
for
the
account
id
aurora
itself
and
that's
it.
C
No
but
yeah
go
ahead,
so
this
is
kind
of
like
a
similar
thing,
with
the
getting
a
mock
block
hash
in
a
sense
right.
A
A
But
at
the
moment,
when
we're
on
multiple
charts
this
this
matters,
because
you
because,
during
the
call
the
rpc
what
tries
what
it
tries
to
do
is
it
tries
to
direct
you
to
the
to
the
to
the
chart
where
your
account
id
yeah
well,
where
your
account
is
located
and
then
from
that
chart,
you're
asking
this
well
you're
you're
doing
the
call.
I
I
I'm
not
sure.
A
What's
the
reason
for
for
having
the
separation
in
between
the
the
user
and
well
the
the
the
need
to
put
so
any
okay,
let
me
get
a
step
back,
so
any
any
transaction
to
near.
You
are
able
to
schedule
as
a
transaction
or
as
a
view
call
and
the
difference
between
them.
A
Is
that,
like
I
are
you
either
scheduling
a
transaction
and
this
transaction
is
put
into
into
the
blockchain
and
executed
on
all
of
the
shard
nodes,
or
it
just
one
single
note
that
returns
you
the
result
of
the
execution
of
this
transaction,
and
this
is
this-
is
what
you
expect
to
get
after
the
execution
of
the
transaction.
A
So
you
literally
can
schedule
a
view
call
for
ft
transfer
for
nap141
no
problem.
A
You
will
see
what
is
the
outcome
of
this
and
within
the
execution
runtime
there
is
an
ability
to
get
the
predecessor
id
so
the
caller
of
this
transaction,
and
when
you
are
doing
a
view
call
there
is
no
yeah
and
when
you're
doing
an
ordinary
call
of
the
transaction
you're
getting
the
predecessor
id
from
the
signature
and
when
you're
doing
a
view
call
it
doesn't
unders
the
code
doesn't
understand
where
to
get
the
the
account
from
which
it
was
called.
So
that's
why
you
need
to
specify
the
account
id
there.
A
This
is
the
logic
behind
yeah
and
and
the
execution
that
it
happens.
It
is
absolutely
the
same
it
just
it's
just
not
so
the
view
calls
just
not
going
through
the
consensus
mechanism
and
that's
it
so
yeah.
This
is
how
it
works,
and
this
is
the
reasoning
for
for
having
this
a
user
account
or
account
id.
D
A
D
There's
a
difference
between
view
calls
and
near
ethereum,
so
in
ethereum
view
calls
actually
can
do
pretty
much
anything,
but
in
near
many
operations
are
restricted
for
view
calls.
So
your
calls
contract
like
right
to
storage
and
make
cross-contract
calls
in
near,
but
they
can
do
all
of
that
in
ethereum,
although
of
course,
state
changes,
don't
persist
in
the
blockchain.
B
Yeah,
so
this
that's
probably
a
good
way
to
work
around
this,
which
is
again,
as
I
said,
we
need
the
indexing
in
any
case,
and
the
the
indexing
will
then
discover
these
transactions
and
we'll
be
able
to
look
them
up
by
without
without
any
need
to
reference,
the
account
id
and,
and
that
will
that
will
work
around
this
but
yeah.
So
I
have
a
few
few
more
things
to
implement
like
that.
B
A
Okay,
I
wanted
to
say
a
couple
of
words
about
the
bridge
speed
up,
because
this
is
something
that
influences
the
the
chain
team.
So
I
created
a
separate
discussion
from
from
my
in
my
talk
with
evgeny,
so
eugenie
proposed
the
way
how
we
potentially
can
speed
up
the
bridge
token
transfers,
so
not
not
arbitrary
transfers
but
token
transfers,
and
the
thing
that
is
important
is
the
from
near
to
ethereum
direction.
So
this
this
specific
direction
that
now
takes
up
to
16
hours
to
do
so.
A
C
A
A
It
implements
an
additional
method
for
fast
transfer,
and
this
third
party
submits
a
transaction
within
the
execution
of
this
transaction
locker
transfers
from
this
third
party,
the
amount
that
needs
to
be
paid
out
and
transfers
to
the
recipient
of
the
transfer
and
then
token
locker
is
just
and
then
token
locker
records
the
information
that
this
fast
finalization
of
withdrawal
was
done
by
third
party,
and
at
the
moment
when,
when
the
networks
are
synced,
then
then
the
party
who
is
going
to
receive
the
transfer-
he
would
be
not
the
the
actual
receiver.
A
D
Think
they
can
formulate
it
a
bit
better.
So
the
idea
is
that
summary
layer
deposit
their
own
tones
and
when
they
see
the
transfer
near
side,
they
can
pay
immediately
those
tokens
to
the
receiver
on
ethereum
site
without
waiting
for
this
transfer
to
actually
go
through,
so
they
are
paying
their
own
tokens.
But
the
fact
that
this
happened
is
recorded
in
the
token
locker.
So
when
the
transfer
actually
go
through,
it's
not
the
receiver
who
received
this
token,
but
that
three
layers,
so
they
received
those
tokens
back
once
the
the.
A
Yeah,
so
now
why?
Why
I'm,
why
I'm
asking
this
one
on
the
on
the
public
call
yeah?
The
reason
is
that
this
influences
the
importance
of
implementation,
of
a
realistic
bridge
and
in
implementing
the
realistic
bridge.
We
are
very
connected
with
the
chain
team
because
they
need
to
do
lots
of
lots
of
the
stuff
on
on
their
side
here.
So
here
is
here
is
the
question
to
you.
What
do
you
think
does
this
approach
for
speeding?
A
The
bridge
up
is
okay
for
now
and
we
can
decrease
the
priority
for
chain
team
to
implement
separate
keys
support
in
near
runtime,
or
we
still
need
to
keep
the
the
priority
for
sap,
keys
implementation
or
addition
and.
D
This
change
can
theoretically
make
bridge
maker
length
tokens
cheaper
because
well
currently,
it's
expensive
to
verify
actual
withdrawals,
but
it
can
be
optimized
independent
on
whether
the
breach
is
realistic
or
not.
And
this
way
we
don't
have,
we
can
have
fast
withdrawals
without
having
to
relay
blocks
frequently
and
we
even
with
realistic
reach
and
especially
with
realistic
breach.
Relaying
blocks
will
cost
something
because
it
will
need
to
verify
all
the
signatures
each
time
a
block
is
relayed.
A
Okay,
so
yeah,
I
do
understand
that
these
are
the
different
things
and
though,
what
what's
your
takeaway.
D
C
B
A
Okay,
okay,
so
let's
do
the
following:
please
please
consider
taking
a
look
in
this
discussion
and
and
expressing
your
opinion
there
from
my
point
of
view.
Also,
we
we
should
probably
decrease
the
priority
and
and
leave
a
chain
team
focusing
on
more
urgent
things
that
needs
to
be
fixed.
A
So
let
me
put
it
probably
yes,
okay,
arta
thanks
for
for
reminding
about
the
ocrs.
Are
you
guys
do
you
guys
want
me
to
go
over
this.
B
A
Okay,
cool
so
yeah.
This
is
one
additional
thing
that
that
we
need
to
that.
We
need
to
inform
all
of
you
about
so
in
here
in
general.
As
you
know,
we
are
following
the
ocr
process
and
this
process
is
intended
to
unite
the
team
and
give
simple
answers
to
the
questions.
A
What
what
are
our
goals?
What
are
we
doing?
What
are
we
focusing
on?
What
is
our
light
house
in
front
of
us
to
which
we
are
going
so
for
the
second
quarter
of
2021
aurora
team?
Remember
so
bridge
and
evm
teams
has
joined
okrs,
and
now
we
call
it
aurora
or
cars,
and
here
are
the
objectives
we
have.
Four
major
objectives,
which
are
the
following:
aurora
has
the
best
user
experience
in
the
industry,
aurora
is
discovered
by
ethereum
community
aurora
on
mainnet
is
launched
and
maintainable
aurora
unblocks
partners
blocked
on
ethereum
compatibility.
A
As
you
can
see,
all
of
the
all
of
the
objectives
are
very
ambitious,
I
would
say,
and
they
are
all
about
the
launch
of
aurora
and
you
know,
delivery
quite
quite
a
high
quality
product.
A
So,
let's
go
one
by
one
with
objectives
and
we
will
be
able
to
see
what
are
the
key
results
that
supporting
these
objectives.
The
key
results
here,
giving
us
some
kind
of
additional,
in-depth
understanding
of
of
what
we
think
should
should
support
us.
Coming
closer
to
this
objective,
for
the
aurora
has
the
best
ux
in
the
industry.
We
have
three
key
results:
we
have
an
exhaustive
list
of
cases
when
users
can
lose
the
transfer
and
we
have
mitigation
for
all
of
them.
A
This
is
a
key
result
that
is
committed,
as
you
can
see,
so
this
is
about
the
transfers
over
the
bridge.
Obviously,
we
measure
our
responsiveness
to
users
and
80
of
the
user
requests
are
acknowledged
within
one
hour.
A
We
are
literally
saying
that
we
would
like
to
reduce
by
25
percent
the
transfer
time
from
near
to
ethereum.
This
can
be
done
by
many
means.
Let's
see,
and
this
is
the
last
two
key
results
are
inspirational
here.
A
A
Advantages
of
bridge
design
are
understood
by
ninety
percent
of
the
users
that
that
we
come
in
contact
with
this
is
about
us,
communicating
and
educating
our
users.
The
excellence
of
the
aurora
user
experience
is
amply
demonstrated.
A
We
would
like
we
would
like
aurora
bridge
to
be
the
best
bridge
in
the
industry
and
aurora
aurora
itself
or
our
engine
to
be
also
very,
very
similar
to
the
ethereum
1.0.
So
we
are.
We
would
like
to
have
this
result.
A
Okay,
again
committed
okr,
so
we
would
like
to
to
provide
enough
information
for
the
ethereum
developers
to
for
them
to
be
able
to
try
aurora
bridge
we're
always
transparent
to
the
community
with
respect
to
design
usage
in
decision
making.
This
is
also
pretty
important.
However.
This
is
an
inspirational
goal
for
us,
for
this
quarter,
aurora
on
mainnet
is
launched
and
maintainable
again.
Five
key
results
supporting
this
very
important
goal.
Very
important,
objective
development
and
release
process
of
aurora
are
defined
and
implemented,
so
we
wanted
to,
you,
know,
stabilize
the
stuff.
A
A
Aurora
cannot
be
broken
by
any
single
entity
within
governance
of
credibility
model,
which
is
which
means
that
we
do
not.
We
would
like
to,
though
it
is
inspirational
for
now,
but
this
is
our
intention,
in
the
end,
to
to
share
the
ability
to
to
work
with
aurora
to
to
to
not
to
work
but
to
govern
the
aurora
and
not
with
the
single
keys
or
single
entity
control
in
it,
potentially
with
with
multisig
world.
But.
C
A
The
wallet
that
is
managed
by
a
single
entity
but
rather
share
the
governance
mechanisms
with
with
other
people
and
all
the
ad
hoc
knowledge,
is
written
down
and
structured.
This
is
also
pretty
important
that
we
are
able
to
find
all
of
the
artifacts
from
the
past,
because
the
bridge
is
already
in
the
development
for
more
than
a
year.
A
Aurora
or
previously.
Evm
is
also
in
the
development
for
half
of
a
year,
even
more
than
that
yeah,
actually
even
almost
a
year
or
two.
So
so
we
need
to
structure
everything.
We
need
not
to
lose
anything
that
we
have
encountered
in
in
the
past,
and
the
last
thing,
but
also
pretty
important,
is
that
we
are
unblocking
our
partners
on
ethereum
compatibility.
There
are
lots
of
companies
that
are
seeking
a
place
where
they
can
launch
their
ethereum
contracts,
and
we
have
many
partners
that
are
deliberately
asking
us
for
delivering
this
functionality.
A
So
what
we
would
like
to
do
is
to
unblock
them
and
make
them
able
to
launch
their
businesses
their
dapps
on
near.
A
Ethereum
end
users
are
using
dabs
by
key
partners,
so
this
is
the
actual
the
goal
of
the
whole
unblocking
thing
yeah,
because
this
is
this
is
the
thing
that
demonstrates
the
fact
that
that
our
partners
are
unblocked
and
the
last
one
which
is
expiration.
These
two
are
committed.
The
last
one
is
inspirational,
the
final
list
of
dependencies
required
by
80
of
key
partners
and
ensure
that
they
get
deployed
to
mainnet.
We
have
been
talking
about
this
for
for
some
some
time
and,
however,
we
are
moving
this
a
little
bit.
A
So
the
priority
of
this
task
is
obviously
not
that
high
most
probably,
we
will
try
to
find
an
external
partner
to
help
us
with
this
okr.
A
So
these
are
our
ocrs.
We
have
been
discussing
them
for
a
pretty
long
period
of
time,
I'm
going
to
create
a
separate
link
that
will
be
available
for
everyone
to
take
a
look
at
this
okrs
yeah
and
hopefully
we'll
be
able
to
deliver
quite
good
results
with
this
old
cars,
any
any
any
questions
objections
or
about
the
ocrs.
A
B
A
A
B
A
A
A
Then
I'm
going
to
to
start
with
myself.
So
let's
do
the
the
same
order
that
we
have
had
previously,
so
my
plan
for
the
next
week
is
to
to
work
a
lot
on
hiring,
so
I
agreed
with
with
ilya
on
additional
positions
that
aurora
is
going
to
open
and
here's
a
bit
of
info
to
everybody.
Sorry
for
not
sharing
this
completely.
A
It
was
out
of
my
hand,
so
these
positions
include
qa
engineer
a
tech
writer
devops
specific
devops
for
us,
so
we
are
going
to
grow
the
the
amount
of
engineers
that
are
working
for
us
and,
most
probably,
we
are
going
to
to
hire
some
additional
people
that
will
take
care
of
our
social,
medias
and
and
business
development
will
help
us
with
this
so
yeah.
A
So
I
need
to
obviously
for
all
of
this
hiring
need
to
need
to
work
with
our
updated
hiring
departments
or
like
hr
departments,
and
I'm
going
to
focus
on
legal
structure
and
supportive
docs.
E
Yeah
sorry
just
had
to
step
out
for
one
second
sure,
no
problem
I'll
focus
on
the
the
two
things
I
already
mentioned
above,
namely
the
the
error
I
encountered.
So
basically,
you
know
fixing
the
errors
making
sure
we
can
replay
more
more
blocks
and
as
soon
as
it
becomes
a
problem,
then
start
working
on
the
batching
of
transactions
to
improve
the
performance.
A
B
B
B
We
need
some
metrics
and
monitoring
in
place
and
probably
a
little
bit
more
work
on
the
security
aspects
such
as
adding
a
reverse
proxy
in
in
front
of
it
and
and
then
then,
of
course,
the
the
indexer
that
I
mentioned
to
be
able
to
actually
implement
every
single
rpc
method.
We
need
this
indexing,
and
I
plan
to
finish
that
next
week
after
that
or
parallel
to
that,
documentation
is
my
my
main
priority
and
there's
other
other
wish
list
items
like
the
hard
hat
plugin.
F
A
A
It
is
annoying
a
little
bit,
but
it's
not
that
critical,
although
aurora
code
is
much
more
critical,
so
I
I
I
propose
you
to
take
a
look
at
anything
that
that
artist.
D
B
Right,
there's
two
there's
two
branches
you're
getting
this:
the
master
branch
is
currently
without
the
f
connector
and
the
s
connector
is
on
its
own
separate
branch
and,
of
course
the
f
connector
is
is
well
it's
a
big
big
piece
of
work
and
that
that
especially
needs
needs.
Some
review.
A
Yeah,
this
is
yeah
again
thanks.
I
I've
seen
that
you
have
submitted
your
review
to
the
in-ear
yeah.
This
is
going
to
be
something
similar.
A
Okay,
then
we
have,
we
have
evgeny
so.
E
Next
week,
we
should
finalize
logic
for
a
new
s,
connector
improvement,
and
I
think
we
should
integration
tests
with
kirill
and
also
I
I
will
connect
with.
A
Yeah,
actually
maybe
this
we
need
to-
we
need
to
discuss
this,
so
I
bet
if
marcelo
and
evgeny
need
to
have
some
inputs
on
the
pre-compiles,
how
to
implement.
C
A
So
maybe
this
can
be
a
separate,
separate
call,
but
obviously
marcelo
and
new
guinea,
for
you,
people
to
go
are
arto
and
joshua
because
they
they
were
implemented.
The
pre-compiles.
A
Okay
cool,
so
whom
do
we
have
next
and
okay
josh
reel
joshua.
C
Yeah,
so
it's
just
the
same
stuff
that
I
was
basically
saying
before,
which
was
the
engine
implementation
of
which
is
the
engine
of
sputnik
and
then
also
completing
the
evm
math
api.
I
want
to
get
that
done
as
soon
as
possible,
and
then
I
want
to
support
frank
next
week
with
every
every
little
issue
that
he
has
that
I
can
quickly
address
it
for
him.
C
Yeah,
so
on
the
next
new
week
I
plan
to
work.
In
the
beginning,
you
kind
of
played
some
tests
with
the
aurora
disconnect
and
I
also
will
assist
marcel
in
the
erc20
connector
implementation
efforts
and
also
we
will
discuss.
I
believe,
on
monday,
whether
we
need,
as
we
previously
mentioned,
some
additional
indexing
for
the
event
layer.
And
if
we
need
those,
then
I
will
implement
that
as.
F
So
so
next
week
we're
going
to
move
the
prototype
repository
to
aurora
hand
over
the
prototype
of
the
aurora
bridge
to
pierre
for
integration,
with
a
protocol
designing
the
content
sections
of
the
website.
And
then
the
target
is
to
have
the
entire
website
ready
for
internal
review
on
friday,
so
that
we
can
make
launch
week
as
low
stress
as
possible.
F
Yeah
I'll
be
working
mainly
on
the
rc20
connector
to
the
evm.
That's
the
main
priority,
and
if
we
finish
that
early,
then
probably
we
can
discuss
about
the
fast
withdrawal
fast
finalization
from
near
to
it,
and
you
can
start
on
that.
Of
course,
I'm
working
today
on
the
on
the
issue
with
building
proofs
and
that's
higher
priority.
If
we
cannot,
if
I
can,
if
we
can't
finish
today
and
we'll
continue
next
week,.
A
I
think
like
it
will
be
too
ambitious
to
to
start
discussions
about
fast
withdrawal.
I
think
we
need
to
wait
until
aurora
is
launched.
C
A
So
what
we
can,
what
we
can
do
is
is
try
to
to
do
some
docks
for
the
bridge.
Actually,
I'm
going
to
I'm
going
to
add
here
bridge
talks
for
myself,
so
I
also
would
like
to
to
work
on
this
to
to
provide
some
good
content
to
people
and
encourage
also
marcelo
you
and
cadil
everybody
from
the
from
the
bridge
team.
B
C
B
If
you're
familiar
with
that
process,
then
by
all
means
just
you
can
you
can
push
there
and
rebuild
from
there.
A
C
F
A
Okay,
cool
pretty
solid
plan
seems
like
everything
is
covered
here,
obviously
we're
not
covering
in
here
anywhere
here
it
will.
It
will
also
probably
require
some
some
work
from
us,
but
hopefully
not
a
lot.
A
What
do
you
have
to
add
to
everything
that
we
have
discussed
today?
It's
like
pretty
long
update,
so
it's
super
long.
A
C
A
Okay,
it's
just
hello,
ranger,
okay,
hello,
ranger,
thanks
for
watching
us,
hopefully
you're
still
with
us,
and
I'm
not
sure,
since
three
people
watching
now,
it
may
be
me
and
somebody
else
from
this.