►
From YouTube: Aurora Update [2021-04-30]
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
looks
like
we
are
live
right
now,
hello,
everybody
welcome
to
the
aurora
update,
weekly
update
that
is
happening
here
on
fridays.
As
usual.
Today
we
are
going
to
discuss
the
news
of
the
aurora
project,
update
all
of
you
with
what
we
are
working
on,
what
we
have
achieved
during
the
last
week
and
what
are
our
plans
for
the
future?
A
A
So
our
status
is
is
really
really
simple.
We
are
working
hard.
The
whole
team
is
working
hard
on
preparing
everything
to
order
release
that
is
going
to
happen
pretty
soon
so
yeah.
I
believe
it
will
be
safe
to
say
that
it's
going
to
happen
in
the
next
month
or
even
the
next
couple
of
weeks
and
yeah.
There
are
lots
of
things
that
needs
to
be
done,
but
if
everybody
are
going
to
update
on
their
on
their
stuff
right
away-
and
we
have
had
some
some
some
planned
things.
A
So
when
you
are
doing
the
update,
please
you
know
maybe
maybe
refer
to
some
of
the
things
that
that
that
have
been
planned
during
the
last
call.
I
will
start
with
myself.
I
was
planning
to
do
hiring
legal
structure
and
supportive
docs
bridge
talks
and
yeah.
I
was
working
quite
a
lot
on
the
legal
setup
of
aurora.
A
I
believe
we
have
an
approach
how
to
do
this
still,
some
some
things
are
not
yet
fixed,
but
we
are
going
to
to
fix
it
pretty
soon
lots
of
support
in
dogs,
especially
preparation
and
presented
during
the
town
hall.
So
this
this
wednesday
was
the
town
hall
was
preparing
a
deck
for
it
and
also
I
started
to
work
on
the
investor
pitch
tank,
so
it's
still
work
in
progress
and
I
already
started
to
have
first
calls
with
potential
investors
and
partners.
A
So
unfortunately
I
can
say
that
during
during
these
updates
onwards,
for
the
next
several
weeks,
I
believe
my
my
updates
will
be
pretty
weak
in
terms
of
working
with
the
potential
investors
and
partners,
but
obviously
well.
You
know
that
all
of
this
is
pretty
sensitive
stuff,
so
I
cannot
share
it
publicly.
Until
the
moment
we
have
secured
all
of
the
investors
and
partners
some
some
various
management
tasks,
not
a
lot
of
this
arto.
What's
on
your
side,.
B
B
A
B
B
B
We
already
have
some
people
hitting
those
endpoints,
even
without
any
announcement
of
the
of
the
urls
and
and
of
course,
we've
communicated
those
urls
to
do
some
some
key
partners
directly.
So
after
today
I
will
be
quite
comfortable
letting
people
at
the
layers.
More
broadly,
we
have,
we
have
good
quality
of
service
limits,
their
rate
limiting
and
like,
and
it's
a
pretty
robust
implementation
by
now.
So
we
can
just
open
that
up
also
continued
work
on
the
documentation
website,
so
joshua
and
I
took
that
forward
in
the
past
week.
B
There's
a
lot
a
lot
more
to
do
on
that
there'll
be
a
more
of
a
focus
next
week,
so
in
general,
the
focus
now
shifting
towards
just
validation
and
documentation.
Those
are
tied
together
because
a
lot
of
the
previous
documentation
we
had
is
out
of
date.
Incomplete
potentially
has
errors,
so
it
means
that
we
have
to
actually
test
every
everything
that
we
have
documented
and
therefore
the
photos
are
tied
together
now
in
terms
of
the
important
design
discussions.
This
week
we
had
a
couple
of
things
that
are
worth
mentioning.
B
One
is
that
we
had
to
figure
out
how
we're
going
to
emit
the
event
logs.
So
these
are
the
log
op
codes
in
the
uvm,
how
we're
going
to
emit
those
from
the
from
the
avm.
We
had
been
doing
it
using
the
near
logging
facility
as
in
the
block,
utf
host
functions,
and
that's
not
a
good
good
solution
for
several
reasons.
B
One
one
is
that
those
functions
are
defined
as
only
taking
utf-8,
because
we
need
to
log
arbitrary
binary
data
and
secondarily
they
have
a
16
kilobyte
limit
and
we
don't
have
any
such
limit
on
the
evm.
People
can
can
log
more
if
they
are
willing
to
pay
for
it.
So
just
when
I
figured
it
out
and
that's
currently
under
under
review
and
will
be
merged
and
after
that,
the
access
to
the
event
logs
will
will
go
through
during
later.
B
So
that's
all
happening
still
today
and
then
we
had
a
big
evm
block
hash
discussion,
which
is
maybe
better
better
suited
for
the
discussion
segment,
but
that
took
a
lot
of
people
involved
to
figure
out
the
path
forward
there
and,
of
course,
a
bunch
of
reviews
of
of
pull
requests.
We
have
a
lot
of
a
lot
of
pull
requests
flow
now
so
to
speak.
C
Fixed
an
issue
that
cause
drops
then
breach
to
not
accept
ethereum
blocks.
The
claim
that
the
client
that's
running
on
the
near
blockchain
do
not
accept
ethereum
blocks.
The
problems
was
is
because
this
was
caused
by
a
deep
reorg.
We
implement
that
hotfix.
We
think
that
on
main
end,
there
won't
be
such
deeply
orchid
rewards.
C
It
was
over
100
blocks
deep,
and
there
was
another
issue
with
the
near
proofs
of
withdrawals,
not
verifying
an
ethereum
chain,
and
now
we
think
that
this
is
because
our
front
end
is
storing
old
proof
and
after
we
redeployed
the
smart
contract
on
ethereum
chain,
it
can't
verify
old
proofs,
but
it
should
be
able
to
verify.
It
should
be
possible
to
regenerate
the
proofs
of
all
withdrawals
so
that
they
would
be
verified.
So
it's
not
that
old
withdrawals
can't
be
verified
at
all.
They
can,
but
the
proofs
themselves
need
to
be
regenerated.
C
C
There
is
no
need
for
this
check
in
the
current
connector,
but
in
the
future,
if
we
redeploy
it,
we
want
to
make
use
of
this
check
to
avoid
verifying
to
avoid
accepting
old
proofs
so
that
we
will
not
have
to
copy
the
list
of
already
used
events.
Instead,
we
just
set
a
minimum
height,
so
all
the
events
are
automatically
invalid,
but
actually
this
check
is
not
currently
implemented
correctly.
C
It
is
checking
the
height
of
reference
block
for
the
proof
and
not
the
height
of
the
proof
where
the
actual
event
took
place
and
because
of
this,
it
is
possible
to
generate
proofs
using
new
blocks
at
the
reference
and
essential
that
this
check
can
be
bypassed.
But
now
we
know
about
this
issue
so
by
the
time
we
actually
need
this
check.
We
will
fix
it
to
make
it
actually
work.
D
But
I
should
have
mentioned
that
not
tested
part
related
to
pre-compiles
and
parts
related
to
a
call
erc
20
contract.
So
I
think
when
it
will
be
completed,
we
should
decide
how
to
test
it.
I'm
not
sure
that
it
should
be
integration
tests
but
really
related
to
integration
tests.
Currently
it's
all
completed,
and
I
want
to
say
that
kirilla
brahmo
found,
as
I
understand,
critical
issues
related
to
proof
or
field
skip
breach.
A
A
A
A
E
E
Sure,
yeah,
okay
and
then
I
wanted
to
continue
with
the
error
I
had
last
week
and
updated
my
near
core
and
my
test.
Scripts
weren't
working
anymore
and
near
cli
gave
me
like
this
page
of
error
stack
and
I
about
delete
account
with
large
state
and
first
I
thought,
there's
a
bucket
near
cli,
and
so
I
just
implemented
that
command
and
the
bully
directly.
E
Then
it's
fine,
but
when
you
run
the
bully
for
a
while,
then
you
know
the
account
state
becomes
so
big
that
you
cannot
delete
it
anymore,
and
so
I
changed
my
local
test
script
that
we
basically
always
create
random
accounts
and,
and
one
point
for
the
discussion
would
be.
Is
there
a
problem
actually
for
us
in
production,
or
what
do
we
do
is
deal
with
that.
A
F
There
was
a
lot
of
dummy
data,
so
I
just
wanted
to
make
sure
that
all
the
all
the
stuff
that
we
were
we
were
returning
made
sense.
So
the
only
the
only
thing
that
really
resulted
in
that
was
the
big
block
cash
discussion
and
gas
limit.
What
what
should
we
turn
for
that
then?
After
that
I
started
on
the
docks
a
bit
a
bit
lately
I
was
filling
in
some
gaps
and
adding
in
a
bit
more
details.
G
Yeah,
so
on
the
beginning
of
this
week,
I
worked
on
the
avm
pre-compiles
with
marcella
and
also
had
a
couple
of
calls
with
joshua
and
arthur
helping
us
to
figure
out
the
pre-compiled
design
in
the
aurora.
Thanks
for
that,
I
also
worked
with
again
jokanov
on
verification
fixing
and
testing
the
aurora
ath
connector
and
its
new
design.
G
A
G
A
G
I
I
just
said
I
also
updating
the
eastern
europe
entry
layer
to
release
installer
as
well,
and
during
my
quad
walkthrough
through
the
aurora
engine
I
found
and
fixed,
I
would
say
quite
serious
security
issue
in
our
8h
connector,
so
it
allowed
us
allowed
anyone
to
pass
this
bridge
call
flag
in
the
roof.
So
that
means
that
the
proof
that
any
valid
proof
from
the
etherium
would
have
accepted.
G
H
Yeah
well,
the
main
topic
of
this
week
was
building
the
rc20
connector.
I
would
say
right
now:
it's
like
70,
80
percent
done,
like
all
the
components
are
built,
but
I
need
to
connect
them
to
each
other,
and
so
it's
not
not
done
yet.
On
the
other
side
I
was
doing,
I
got
some
help
from
kirill,
mostly
on
the
track
and
paul
side,
which
I
appreciate.
H
I
was
working
with
closely
with
eugenie
on
some
of
the
issues
he
already
described
about
roxanne
with
rowles.
Also,
you
know
some
time
and
giving
support
for
bridge
related
channels.
We
still
need
to
improve
our
ux
in
several
places.
Well,
for
now,
some
manual
intervention
still
helps,
and
I
had
one
important
discussion
with
mario
from
our
sre
team
that
will
help
us
set
up
a
proper
release
process
for
the
for
the
bridge
and
will
improve
in
general
the
development
experience
I
expect
yeah.
So
that's
it.
A
H
A
H
A
H
I
H
I
And
then
there
was
some
management
activities
related
to
the
aurora
launch
and
then
some
minor
things.
So
we
just
set
up
a
base
camp
project
for
alex
b
and
myself,
because
the
the
number
of
little
tasks
related
to
the
website
kind
of
exploded,
as
as
things
came
together,
and
so
we
set
up
a
little
base
camp
project
to
manage
those
tasks
and
started
a
final
punch
list
for
the
launch
on
the
trello
board.
I
I
So
this
week
I
was
working
mostly
on
the
benchmarks.
I
think
those
are
in
good
shape,
there's
a
comment
from
alexei
kladov
that
I'll
address
today,
but
that
should
get
merged.
The
sort
of
summary
of
that
is
doing
pre-compiles
and
watson
directly
is
too
expensive,
so
the
math
api
pr
is,
is
pretty
important.
I
Thanks
so
this
week's
the
first
part
of
the
week
I
was
working
on
in-ear,
so
that's
almost
done.
The
front
end
is
ready.
The
only
thing
that's
missing
is
testing
the
unlocking
and
burning
on
tokens
which
I
couldn't
test
because
the
we
had
the
issue
with
the
rainbow
bridge,
and
so
then
I
started
working
on
aurora,
so
I'll
have
to
get
back
to
it
sometime
next
week
and
so
yeah.
After
that
I
was
working
on
aurora.
A
I
A
A
Yeah
I
just
yeah
well,
potentially,
maybe
just
just
to
spend
ten
ten
more
seconds
to
give
everyone
a
little
bit
of
stats
on
how
the
bridge
is
working
right
now,
a
little
bit
of
stats
here.
So
the
total
amount
of
assets
breached
over
the
bridge
is
now
more
than
800
thousand.
Yes,
us
dollars,
recalculated,
obviously
from
all
of
the
from
all
of
the
assets
and
the
rc20
locker
is
now
holding
almost
well
686
thousand,
so
pretty
good
stats.
A
A
B
I
I
A
H
I
A
I
I
A
A
G
Definitely
transaction
is
already
there,
but
what
pr
has
mentioned
is
that
I
believe
he
wants
to
have
some
way
to
get
the
status
of
the
specific
transaction.
Was
this
already
transferred
or
not?
And
for
that,
for
example,
for
sure
we
can
add
some
api
for
the
layer
or
we
can
add
some
some
subscriptions
feature
to
notify
for
some
specific
events
as
they
are
relate,
but,
okay
for
sure,
we
will
discuss
this
with
spear.
What
is
the
best
way
for
him?.
I
G
A
H
G
D
H
H
I
A
I
H
I
G
A
No,
we
discussed
this.
This
is
not
the
way
to
go
the
reason
for
this,
so
we
need
to
have
a
separate
recompile
for
this.
The
reason
for
this
is
that
your
c20
implementations
and
actually
today,
was
speaking
to
the
partner
they
have
their
own
token
and
they
would
like
to
deploy
this
token
to
aurora
and
they
do
not
want
to
modify
the
erc20
logic
because
they
have
the
erc20
logic
and
some
additional
pieces.
A
So
this
this
is
what
this
this
pre-compile
is
taken,
and
then
this
pre-compile
is
checking
that
the
bridge
talking
address
is
actually
a
some
kind
of
is
actually
an
address
of
the
bridge
token,
and
then
it
goes
directly
into
the
state
of
this
token
and
removes
a
specific
amount
from
the
message.
Sender
and
and
issues
the
and
then
aurora
and
then
does
the
transfer
to
factory
or
if
it
is
yeah
that
doesn't
transfer
to
it.
C
A
C
Yes,
so
it
should
sound
similar
to
like
you're
sending
a
token
to
locker.
Basically,
the
reason
we
want
to
have
in
some
future
unified
interface.
So
all
tokens
should
be
bridged
in
the
same
way,
no
matter
whether
they're
native
on
vm
in
ethereum,
in
near
vmware
ethereum
or
in
near
native
runtimes.
So
the
idea
is
that
when
you
want
to
bridge
your
token,
you
always
have
to
send
actual
actually
send
this
tokens
to
the
appropriate
contract,
not
just.
A
A
B
H
C
C
Similarly,
to
how
this
is
done
in
ethereum,
well,
not
this,
but
generally.
If
you
want
to
send
token
and
then
to
perform
some
operation,
then
you
first
approve
this
token
to
the
contractor
in
this.
In
this
case,
it
would
be
this
precaum
file,
then
you
make
a
call,
and
this
call
calls
transfer
from
normally
as
if
so,
it
doesn't
need
to
be
able
like
to
directly
modify
the
state
of
the
token
it
shouldn't
need
this
ability.
It
should
behave
like
any
regular
ethereum
contract
that
accepts
token,
for
something.
I
A
I
I
too,
so
this
is
a
specific
thing
and
like
having
only
one
transaction,
and
you
do
not
need
to
do
a
proof
and
then
and
then
call
in
the
pre-compile
which
does
transfer
from
yeah.
Anyway.
We
need
to
delete
these
tokens
from
the
pre-compile
in
order
for,
for
the
erc20
to
correctly
show
the
the
total
total
amount
of.
A
C
So
the
problem
with
this
approach
is
that
when
maybe
in
the
future,
we
implement
the
ability
to
breach
native
tokens
from
vm
back
to
illinois
like
tokens
which
are
native
to
evm,
which
will
probably
exist
at
some
point,
because
some
of
the
contracts
that
are
going
to
here
want
to
be
deployed
to
them
have
their
own
tokens.
And
we
want
to
reach
those
tokens
to
ethereum.
C
A
Yeah,
I
understand
what
you're
saying
so,
let's,
let's
probably
think
of
this
a
little
bit
later,
when
there
are
aurora
native
tokens
that
we
want
to
bridge
to
ethereum
absolutely
the
same
thing
as
as
we
are
so
so.
Let's
delay
this
problem
the
solution
of
this
problem,
because
it's
it's
it's
the
same
as
with
bridging
np
141s,
so
we're
not
supporting
it
right.
Now,
though,
the
value
of
of
the
current
approach
is
is
already
there
yeah,
so
we
have
near
blockchain
getting
some
tokens
but
yeah
I
hear
you.
A
A
I
A
A
This
actually
pre-compile
will
help
us
to
use
to
make
use
of
the
composibility
of
transactions
literally,
so
there
will
be
an
interesting
way
how
to
how
to
do
it.
So
some
kind
of
some
some
contract
executes
and
and
is
actually
calling
the
pre-compile
yeah
without
without
an
approve
without
an
additional
transaction.
B
B
We
should
endeavor
to
take
into
account
the
rare
situation
of
a
short
term
near
fork,
which
is
why
mac
suggested
we
wouldn't
want
to
use
the
block
height.
We
ought
to
use
the
block
hash
and
the
launch.
The
aurora
launch
should
highly
preferably
use
a
finalized
block
hash
scheme,
so
we
don't
have
to
change
that
later,
which
would
be
quite
painful
and
a
mess,
and
an
additional
weak
requirement
would
be
that
the
the
way
we
form
the
scheme
scheme
for
the
block
hash
should
be
not
that
easily
predictable.
B
This
is
not
a
hugely
important
requirement,
because
nobody
should
be
using
block
hash
for
pseudo
pseudorandom
number
generation.
Although
people
do,
of
course,
so
so,
given
given
those
requirements,
we
we
wanted
to
implement
it
as
a
a
hash,
a
catcher
cache
of
of
the
chain
id
the
block
hash,
that's
in
the
near
block
hash
and
the
evm
contract
accounts.
B
Looks
like
somebody's
phone
here
is
ringing,
so
the
host
function
needs
to
be
added,
so
that's
that's
been
tested
out.
Michael
michael
is
working
on
that
we
initially
thought
that
this
would
be
a
high
priority
for
launch,
but
we
lowered
the
priority
after
frank
gave
us
some
some
data
on
how
frequently
or
infrequently
this
instruction
is
used.
B
That
will
have
the
correct
scheme
from
the
beginning,
with
the
assumption
that
the
contract
will
catch
up
once
it
has.
That
protocol
upgrade
eventually,
so
that
pretty
much
summarizes
the
plan
here
launched
with
with
this
one
instruction
broken
basically
and
based
on
the
data
we
have,
it
shouldn't
be
a
broker
for
anybody.
We
hope
and
then
fix
that
up
over
the
summer.
B
B
C
C
So
if
you
want
to
manipulate
low
cash,
you
may
need
to
discard
some
valid
nonsense,
and
this
is
like
costs
a
lot
in
year.
It
costs
much
less
basically
for
block
producer.
It's
free
to
able
to
change
the
current
blocks
hash
by
generating
a
different
signature,
so
the
using
near
block
hash
won't
get
you
even
the
same
level
of
security
in
terms
of
randomness
as
the
ethereum
block
hash.
C
C
Then,
as
some
people's
note
people
noted,
it
is
possible
to
get
block
hatch
from
ethereum
and
then
use
it
in
the
free
api
to
look
up
the
block
by
hash.
This
can
be
implemented
with
any
scheme.
We
just
need
to
have
our
web3
api.
Our
rpc
servers
to
actually
use
the
same
block
hashes
as
the
keys
to
and
to
return
the
appropriate
kind
of
blocks
for
those
block.
Hashes
doesn't
matter
which,
which
values
are
used
as
block
hashes
as
long
as
they're
unique.
So
you
can
use
this
value
to
identify
the
block
to
return.
C
B
C
B
C
C
C
B
The
chart
yeah
and-
and
it's
also
it's
also
not
the
case-
that
that's
actually
unique.
We
use
the
same
chain
id,
for
example,
on
local
deployments
as
on
abolite
beta
net.
We
reuse
that
id.
So
that's
one
reason.
The
other
reason
is
max's
objection,
so
this
this
had
to
do
with
short
term
forks
of
the
chain,
and
he
felt
that
the
the
hash
would
be
a
far
better
solution
than
the
heights.
C
B
A
A
Correct
okay!
So,
let's,
let's
not,
let's
not
not
stop
here
for
for
a
long
period
of
time,
let's
go
into
the
next
item.
This
is
something
that
that
I
added
here
customer
receipt
money
contract.
So,
as
I
said
to
you,
as
I
briefly
mentioned
this,
I
have
had
a
chat
with
a
partner
that
would
like
to
in
order
for
his
solution
to
work
he
needs.
A
A
H
A
But
potentially
this
is
also
something
that
can
be
done.
Just
wanted
to
mention
this
because
we
obviously
probably
this
is
not
something
that
we
are
going
to
do
right
here
right
now,
but
this
is
something
that
we
are
going
to
encounter
very
quickly
like
maybe
in
couple
of
weeks,
so
if,
if
we
are
able
to,
if
marcelo
marcel,
what's
your
take
on
this,
if
you
since
you're
working
right
now
on
the
on
the
nap
141
bridge
into
two
aurora,
what's
your
what's
your
first
reaction
on
this.
A
A
Yeah,
the
problem
is
that
we
have
a
function
to
deploy
your
c20
yeah
deploy
bridge
token.
This
is
the
same
function
that
we
have,
in
fact
in
the
factory
right
now
for
nap141s,
and
this
function
deploys
a
vanilla
implementation
of
np141
yeah
and
for
aurora
it's
going
to
implement
a
vanilla
implementation
of
the
erc20,
probably
from
open
zeppelin
yeah.
H
Like
from
the
top
of
my
head,
what
I
can
think
is
that
he
can
actually
deploy
the
new
york
c20
with
an
extra
function
that
allows
him
to
to
exchange
like
to
send
tokens
from
the
vanilla
implementation
to
the
new
implementation
and
well,
you
interact
with
the
other
implementation.
It's
a
little
bit
more
cumbersome.
H
A
H
Some
tools
that
are
separate
discussion-
and
I
have
my
opinions
on
that,
but
in
the
in
this
regard,
I
don't
think
it
would
be
easy
to
to
deploy
other
than
the
vanilla
implementation,
because
otherwise
we
need
to
like
inspect
them.
While
these
ourselves,
some
custom
implementations
and
it
may
be
easy
to
to
misread
or
miss
something
there.
So
in
general,
I
think
it's
on
the
on
the
developer
and
the
user
of
that
contract
to
to
actually
handle
this
like
interact
with
our
interface
right
now.
A
H
H
A
A
H
I
C
It's.
Not.
It
can't
be
just
automated,
and
I
think,
if
we
need
to
have
some
of
those
bridge
tokens
have
some
special
behavior.
Maybe
we
want
to
have
either
different
connectors
for
them
for
them,
or
at
least
talking
themselves,
shouldn't
be
deployed
by
the
connector.
Normally,
it's
some
special
process.
A
A
A
It
is
not
enough
because,
in
that
transactions
there
are
always
in
they
need
methods.
There
is
some
kind
of
initial
supply
of
the
tokens
and
the
initial
distribution.
Most
probably
people
do
not
want
to.
You
know,
create
new
tokens
during
their
deployment
of
the
contract
on
aurora,
so
there
may
be
many
many
many
additional
small
things
that
are
not
going
to
work
as
absolutely
the
same
as
as
as
with
the
first
deployment
on
ethereum.
A
Okay,
let's
discuss
this.
I
believe
this
is
going
to
be
hot
topic,
so
cool.
It's
super
cool
that
we
have
different
opinions
on
this.
Let's
discuss,
maybe
we
can
generate
a
good
idea
how
how
to
handle
these
cases
cool,
let's
go
further.
How
do
we
deal
with
the
near
core
limitation
of
the
addition
of
the
contracts?
Is
that
problem?
Is
that
a
problem
for
us?
E
B
And,
of
course,
the
bone
suggestion
of
deleting
state
from
inside
the
contract
itself
as
in
managing
managing
our
own
storage,
it's
a
little
bit
complicated
because
we
can't
iterate
over
the
contents
of
the
storage
from
inside
the
contract.
So
it
somewhat
needs
to
be
externally
facilitated
in
that
regard,.
B
B
B
B
H
E
But
it
means
if,
if
you
run
it
on
testnet,
the
way
I
test
on
test
net
visibility
is
that
I
have
to
deploy
my
own
contract
because
it
has
the
special
functions
in
there
and
that
kind
of
will
create
this.
You
know
toxic
waste
in
a
sense
that
I
will
never
be
able
to
delete
those
contracts
again
and
with
the
test
tokens
that
are
bound
by
the
by
the
contract
size
and
could
potentially
become.
I
mean
we're
still
in
the
early
early
phase,
where
we
don't.
B
E
B
H
B
I
think
for
for
cleaning
up
something
like
that.
As
long
as
you
have
a
full
access
key
to
the
account,
it's
always
possible
to
clean
it
up,
you
just
need
a
contract
which
does
nothing
except
delete,
storage
keys.
You
know
especially
keys
one
by
one.
Somebody
should
write
a
script
to
do
that.
That
would
be
cool.
B
B
B
B
There's
also
a
question
how
to
collaborate
on
such
a
review,
because
it
will
be
useful
for
reviewers
to
be
able
to
collaborate,
and
that
might
might
make
sense
to
then
raise
a
new
pr
specifically
between
the
the
master
branch
and
the
s
connector
branch.
It's
it's
big,
but
it's
not
so
much
necessary
for
the
review,
which
I
think
is
more
likely
to
be
successful.
B
B
B
A
Cool
yeah,
so
very,
very
short:
let's
close
this
with
our
plans
for
the
next
for
the
next
week.
So
I'll
start
with
myself,
I'm
going
to
the
general
management
with
regard
to
aurora
release,
so
we
need
to
prepare.
We
need
to
make
sure
that
everything
is
there
that
everything
is
is
cool.
I'm
going
to
work
with
the
pitch
deck
for
investors
and
and
we'll
start
to
reach
was
that
to
reach
these
people.
A
C
D
So
next
week
I
asked
are
to
mention
that
I
should
complete
for
small,
specs
and
diagrams
I'm
not
familiar
with
cdla
plus
but
main
goal
related
to
easily
understand
or
for
people
who
who
don't
know
how
all
these
things
work
short.
So
we
should
have.
We
should
help
our
people
to
understand
to
how
it
work
and
validate
pull
requests
and
as
connector.
So
after
that
I
should
testing
as
connector
with
kirill.
I
believe
and
probably
will
be
some
additional
tasks.
B
E
F
Yeah
documentation
with
that
that
includes
like
the
online
documentation
and
also
the
roar
engine
inline
documentation.
I
want
to
get
into
the
math
math
api,
but
that
might
not
be
until
the
end
of
the
week.
Then,
after
that
the
connector
logic
review.
That's
gonna
take
some
time
because
it's
a
lot
of
lines
of
code,
then
the
general
like
the
aurora
engine
as
a
whole.
F
B
G
A
A
Don't
hesitate
in
one
additional
day
from
this
from
this
weekend,
so
not
not
saying
to
you
that
you
need
to
do
it,
but
just
take
a
look
at
at
the
speed
how
how
the
things
are
done.
So
myself,
and
as
far
as
I
understand,
are,
though
we
are
going
to
work
on
sunday.
So
if
you
want,
you
obviously
can
reach
to
us
on
that
day.
A
C
B
C
B
Yeah
we're
already
operating
past
the
gas
gas
limit
so
to
speak
on
on
the
avm
contracts.
It
would
be
good
to
not
add
things
that
cause
the
gas
to
it.
We
have
a
protocol
upgrade
in
the
books.
It
will
be
delivered
in
middle
of
june.
Everybody
is
happy
with
it.
Bone
is
happy
with
it.
Max
is
happy
with
it.
Don't
don't
don't
see,
really
a
problem
with
it?
B
We
can
access
the
last
256,
hashes
and
and
we're
good,
so
I
would
suggest
take
it
up
in
the
in
the
channel
if
you,
if
you
want
to
push
this,
but
really
this
has
already
been.
We
all
spent
a
lot
of
time
on
this
this
week
and
I
don't
think
there's
too
much
more
benefit
to
be
gained
here.
This
is
already
a
dead
horse.
As
far
as
I'm
concerned.
A
Yes,
okay,
so
again,
thanks
for
for
the
input,
please
continue
async,
but
before
you
will
continue
check
check.
What
is
the
solution
that
is,
that
is
used
right
now,
okay,
so
we
have
had
a
couple
of
people
who
were
joining
us
and
commenting
during
the
stream
shout
out
to
them.
Thanks
for
joining
thanks
for
your
activity,
I
was
I
was
answering
the
questions,
async
cool,
that
you
are
watching
us
and
and
supporting
us
and
see
you
all
next
week.