►
From YouTube: CasperLabs Community Call
Description
Engineering update, Delgator UX, How Casper is different from Ethereum, why CasperLabs is launching a separate blockchain
A
Good
morning,
good
afternoon,
good
evening,
everyone,
wherever
you're
coming
to
us
from
my
name,
is
metta
parlikar,
I'm
the
cto
of
casper
labs
and
I'm
here
to
provide
an
engineering
status
update
today
the
agenda
is
we're
going
to
talk
about,
obviously,
where
engineering
is
at
with
the
work,
some
upcoming
milestones
and
then
we're
going
to
talk
and
how
we're
tracking
towards
those
milestones.
A
We've
also
got
a
question
in
from
the
community
about
the
performance,
the
projected
performance
of
the
network,
the
infernal
tps
number.
I
almost
attempted
to
ask
about
tps
reports
from
the
engineering
team
and
then
we're
going
to
talk
a
little
bit
about
social
consensus.
A
Today,
I'd
like
to
talk
a
little
bit
about
social
consensus,
what
it
is
as
a
concept,
it's
something
that
the
engineering
team
is
working
on
is
very
relevant
and
a
little
I'll
talk
a
little
bit
also
about
monitoring
how
validators
monitor
the
system
and
know
whether
or
not
you
know
social
consensus
needs
to
happen
or
not
right,
so
so
I'll,
just
dive
right
in
with
engineering
status
update.
A
So,
let's
see
so,
the
team
has
entered
the
last
weekly
sprint
of
the
20.9
release
cycle
we
intend
on
so
in
terms
of
an
upcoming
milestone.
At
the
end
of
next
week,
I
intend
on
unveiling
the
rust
node.
This
is
a
brand
new
node
that
we
are
building
for
mainnet.
It
is
a
pure
rust
implementation
for
those
that
haven't
seen
the
repo
it.
I
assure
you
it
is
real.
A
It's
right
here,
it's
private,
it's
called
casper
labs,
no
we'll
probably
be
changing
it
to
casper
node
here,
but
you
can
see.
We've
already
got
about
1300
commits
in
this
repo
and
quite
a
few
pull
requests
that
have
been
closed.
We've
been
working,
184,
close,
pull,
requests
we've
been
working
on
this
since
april
of
this
year.
This
is
a
brand
new
brand
new
repo
brand
new
node
that
is
based
fully
on
rust
and
and
it
uses
the
this
big
spike
you're.
A
Seeing
here
is
when
we
merged
in
the
contract
runtime
the
execution
engine,
which
is
also
in
rust,
so
that
that
is
the
rust
node.
It's
our
intention
to
open
source
that
repo
later
next
week
and
we
will
be
cutting
a
release.
Our
first
package,
first
debian
package
of
the
rust
node
and
I'm
going
to
be
turning
it
over
to
a
handful
of
validators
that
are
currently
part
of
the
alpha
test
net
and
the
beta
test
net
we've
hand
selected
these
validators
because
they
have
the
time
and
bandwidth
to
actually
bang
on
this
thing.
A
So
they're
gonna,
they're
gonna,
help
us
out
by
banging
on
this
node
and
working
really
closely
with
us.
So
we're
also
gonna
be
working
with
some
of
our
our
technical
advisors
and
partners
as
well
to
start
battle
testing
this
node
in
preparation
for
mainnet
launch.
A
So
that's
the
rust
node
that'll
be
coming
up
over
the
next
week
or
ten
days
or
so.
If
you're
interested
in
participating
in
this
round
of
testing
drop
me
a
note
in
discord.
A
Drop
me
a
note
in
telegram,
and
let
us
know
that
you're
interested
and
we'll
reach
out
to
you
and
you
can
have
the
opportunity
to
participate
in
the
incentivized
test.
Net
nursing
rewards.
A
We
are
planning
on
bouncing
the
the
public
beta
network,
we're
doing
this
because
we've
we
had
an
issue
with
key
generation
in
clarity
and
because
of
that
we
unfortunately
had
about
11
validators
that
were
not
able
to
bond
into
the
network,
and
the
reason
for
that
is
that
the
key
they
provided
was
actually
the
account
hash
and
the
chain
specification
requires
the
proper
public
key
right.
That
is
a
you
know,
base
16
or
base
64
key
and
unfortunately,
the
validators
that
went
into
clarity.
A
And
you
know
when
you
go
into
clarity,
you
see
this
public
key.
It
says
public
key
hash
right
and
so
that
persnickety
little
word
there
hash
means
it's
not
actually
the
public
key,
it's
the
hash
of
the
public
key,
which
is
the
internal
representation
of
accounts
in
the
casper's
protocol,
because
we
support
multiple
key
types.
But
it's
a
my
perspective
is
that
this
is
an
implementation.
Details
should
never
be
exposed
to
end
users,
and
so
we
exposed
it
to
end
users.
A
We
made
a
mistake
in
our
instructions,
and
so
we
had
about
a
dozen
or
so
validators
that
we're
not
able
to
bond
in.
We
want
to
include
those
validators
in
so
we've
been
working
with
them
to
fix
their
keys,
so
we
have
their
proper
keys
that
we
can
include
in
the
genesis
block
so
we'll
be
cutting
a
new
genesis
block
around
the
same
time
frame
on
around
you
know,
after
labor
day
we
plan
on
bouncing
the
network.
So
that's
that's
the
reason
why
we're
bouncing
the
network.
A
It
was
a
miss
on
our
part,
but
we've
we've
got
some
of
those
things
fixed,
but
otherwise
the
network
is
stable.
I'll
also
show
you
guys
how
we
monitor
the
network
and
what
the
implications
are
for
social
consensus
in
terms
of
how
the
validators
detect
a
problem
within
highway.
So
we'll
talk
about
the
different
pieces
of
the
node
architecture
and
statuses
in
highway
highway
core,
which
is
the
implementation
of
the
math
paper
in
code.
A
We
are
working
on
implementing
slashing
and
the
security
features,
and
this
is,
of
course,
the
vertical
spam
attacks
and
the
horizontal
spam
attacks.
Basically,
these
are
known
as
equivocation
catastrophes.
A
A
We
can
go
over
those
the
security
features
later
on.
This
is
on
the
rust
side.
This
is
the
node
container,
we're
extending
the
the
node.
I
like
to
call
this:
the
cli,
the
command
line,
interface
client,
which
is
actually
not
the
rust
node
client
itself,
but
actually
what
dap
developers
will
use
what
end
users
will
use
right?
It's
it's
basically
the
json
interface
to
the
node
api.
A
So
it's
going
to
include
more
features
that
are
exposed
in
the
node
api.
The
goal
is
to
get
this
to
feature
parity
with
the
with
the
python
client.
So
all
the
things
you
can
do
in
the
python
client
now
you'll
be
able
to
do
the
new
rust
client
for
the
new
rust
node
we're
implementing
node
join
rejoin.
So
what
currently
happens
in
the
node
in
the
rust
node
is
all
the
nodes
need
to
be
there
at
genesis
and
they
need
to
stay
present.
A
So
if
a
node
has
a
liveness
fault,
there
isn't
any
way
for
it
to
rejoin
from
that
point
right
it
it.
You
have
to
start
a
genesis
and
stay
alive,
so
obviously
we
need
no
join
rejoin.
I
think
that's
a
really
important
feature
that
we
need.
It
enables
validators
to
you,
know,
stop
their
node
and
rejoin
the
network
right
without
having
to
start
at
genesis
costing
for
host
site
functions.
So
if
you
remember
there
are
some
things,
some
specific
transaction
types
that
we
brought
onto
the
host
side.
We
did
this
for
performance.
A
This
basically
means
the
cost
of
a
token
transfer
right.
So
the
other
host
side
functions
are
the
mint
contract,
the
token
contract
and
the
proof
of
stake
contract.
We
brought
those
host
side
for
performance
reasons.
Obviously,
people
are
going
to
explicitly
call
the
proof
of
state
contract
or
specifically
call
any
of
those
other
contracts.
A
You
know
the
mint
and
token
contract
so
making
those
you
know,
we
don't
need
to
cost
those,
but
we
do
need
to
cost
token
transfers
right,
and
so
that's
what
that
refers
to
and
then,
of
course,
the
cost
for
storage
right.
So
we
don't
want
people
uploading.
A
You
know
videos
to
the
blockchain,
that's
not
the
best
use.
I
mean
they.
Could
it's
just
going
to
be
very,
very
expensive
because
we'll
be
charging
by
the
byte
for
storage
costs
it'll
for
the
purposes
of
mainnet
lodge,
it
will
not
include
rent
right,
so
it
will
be
much
more
like
the
ethereum
model.
It'll
be
perpetual
storage,
but
know
that
we
will
be
implementing
rent
in
short
order.
After
that
it
will
be
in
the
form
of
either
you
have
to
persist
a
certain
amount
of
token
in
the
contract.
A
You
have
to
lock
some
token
in
the
contract
or
you
will
have
to
pay
rent,
we're
not
sure
exactly
which
way,
but
it
could
be
a
minimum
balance.
A
minimum
token
balance
right
will
enable
your
contract
to
persist,
that's
easier
to
implement
because
we
could
implement
the
same
thing
for
accounts,
we're
implementing
transaction
fee
distribution.
So
if
you've
deployed
a
contract,
you
know
that
we
do
take
token
for
transactions
some
basic
token,
but
we
don't
do
anything.
With
that
token,
it
doesn't
go
to
the
validators
we
will
now.
A
What
the
status
endpoint
looks
like
in
the
current
test
net,
so
you
guys
can
get
an
understanding
of
what
we're
implementing
and
why
sre
we're
preparing
for
beta
test
net
restart
and
we're
preparing
that
rust
network
like
I
spoke
with,
spoke
to
you
guys
about
about
five
to
ten
validators
and
we
are
still
we've
got
a
20
node,
lrt
long
running
test
with
rust
nodes
and
we're
banging
on
this
rust
node.
A
On
the
ecosystem
front,
we
are
doing
documentation,
work
on
key
management,
so
integration
with
you
know
hot
and
cold,
hot,
cold,
cold
and
hot
hardware
wallets.
Of
course,
we
need
a
custody
solution
for
mainnet
launch,
so
we
are
also
in
talks
with
several
custody
providers,
and
they
will
actually
also
need
this
information.
There's
also
coin
list,
not
coin
list.
I'm
sorry.
A
This
thing,
coinbase
also
has
the
rosetta
information
that
they've
provided
we're,
also
consuming
those
requirements
and
we'll
create
a
separate
api
for
the
coinbase
for
coinbase
integration,
we're
also
implementing
metrics
in
clarity.
We've
got
a
very
large
pr
in
the
clarity
repo
right
now,
that
is,
for
the
implementation
of
metrics.
A
A
It
seems
that
we
merged
that
pull
request.
Oh
yeah
implement
metrics
there.
There
we
go
so
you'll
see
the
input,
metrics
implementation.
This
is
the
pull
request
for
it.
It's
rather
large
pr
about
you
know
thousand
lines,
and
so
these
are
some
of
the
metrics
that
it
adds,
and
this
is
really
to
help.
You
know
anybody.
That's
running
a
block
explorer
using
this
code
base
will
understand
a
few
things
about
how
the
system
is
being
used
right
and
we
need
this
for
ourselves.
A
On
the
economic
side,
we're
designing
social
consensus,
revising
the
token
vintage
model.
So
when
we
did
our
validator
sales,
we
had
a
lot
of
validators.
Ask
hey
if
I
stay
bonded
for
longer.
Does
that?
Is
that
worth
something
right?
Do
I
get?
Do
I
get
some
additional
benefit
for
being
a
long
time
validator
in
the
network?
And
the
answer
is
you
know
why?
Yes,
that
makes
a
lot
of
sense
right,
and
so
this
is
the
token
vintage
model
right.
A
What
are
the
benefits
to
stay
being
a
long
time
validator
in
the
network,
and
we
calling
that
token
vintages
scala
node
is
in
code.
Freeze,
we're
not
doing
any
additional
work
on
it,
only
critical
bugs
that
are
reported
on
testnet
and
and,
of
course,
any
bugs
on
the
execution
engine
will
fix,
but
we're
going
to
fix
them
in
the
new
rust
code
base.
A
Contract
runtime
is
mostly
feature
complete.
We
have
some
new
must-have
features
that
we
want
to
get
done,
namely
payments
2.0.
You
can
see
that
in
our
new
cep,
I'm
very
excited
about
cep.
We
can
talk
about
this.
We
talk
about
governance
a
little
bit.
It's
our
casper
enhancement
proposals.
A
These
are
requests
for
comments.
I'm
happy
to
report.
We
already
had
one
external
one
here,
which
is
the
it
was
approved.
Maybe
it
was
merged
yeah
it
was
closed
and
merged
and
oh
maybe
it's
not
here,
wait.
A
Blake
hash,
so
ledger
leap
is
one
of
our
advisors
and
one
of
our
validators
and
they
filed
the
cep,
if
feel
free,
to
fork
this
repo
and
put
in
a
cep.
If
you
have
some
good
ideas,
please
be
aware
that
you
should
follow
the
format
very
carefully
make
sure
your
cep
is
complete.
We
ask
that
it
be
you
know,
filed
properly
and
completely
and
then
yeah
and
by
in
all
means
feel
free
to
review
these
right.
This
is
the
client
api
cep
from
frasier.
A
This
is
the
you
know,
information
about
how
a
clarity
integration
would
look
like
and
what
are
what
are
the
needs
for
nodes?
So
here
we
go.
This
is
the
client
api
of
a
casper
node.
So
the
goal
is
for
us
to
try
to
do
this
as
transparently
as
possible.
We
want
to
start,
you
know
kind
of
dog
fooding
our
governance
process
now
so
this
this
is
it
here
we
go
and
for
the
time
being,
the
core
development
team
are
the
cep.
Editors
and
approvers
later
on.
A
Malika
has,
you
know,
introduced
a
process
for
how
editors
will
be
selected.
That
will
definitely
be
an
improvement
on
this
process.
We
definitely
don't
want
to
just
be
the
only
ones
right,
an
active
participant
in
how
features
are
approved
for
implementation
that
will
eventually
become
decentralized
as
well.
A
Team
and
company
update
I'm
happy
to
report
henry
taylor's
back
on
the
team
so
excited
to
have
him
joining
the
organization.
We
also
have
another
joinee,
that's
going
to
be
joining
the
team
on
september
14th.
He
is
a
rust
developer
based
in
canada.
We
also
have
a
new
developer
advocate.
We've
cut
an
offer
to
I'm
hoping
to
get
that
signed
contract
here
shortly.
A
I'm
very
excited
about
that
person
joining
the
team
I'll
be
very
happy
to
announce
that
once
he
starts
and
we're
still
hiring
actively
hiring
rust
engineers
sres
as
well
as
app
developers.
So
if
you're
interested
in
working
with
us
go
ahead
and
submit
your
resume
and
we'll
put
you
in
the
pipeline,
so
let's
talk
a
little
bit
about
social
consensus.
A
What
social
consensus
is
why
it's
important
and
what
we're
doing
about
it?
So
social
consensus
is
basically
what
happens
in
the
event
of
a
critical
failure
of
consensus
right.
So
when
you
have
a
critical
consensus
failure,
then
the
validators
need
to
determine
get
together
and
basically
out
of
protocol,
decide
how
they're
going
to
help
the
network
recover.
A
A
A
Failure
basically
looks
like
the
network
has
split,
and
what
that
means
is
the
the
network
no
longer
agrees
on
the
last
finalized
block,
and
so
what
you're
seeing
here
is
here
you
see
that
we've
got
34
validators
in
sync,
34
of
the
validators
agree
on
the
last
finalized
block.
Right
34
is
actually
a
much
lower
number.
A
I
think
we've
got
some
that
have
dropped
off
or
we're
in
a
transition
here
where
we've
got
validators
that
are
so
you'll
see
here,
we're
in
an
era
transition
right,
and
so
we've
got
a
few
more
validators
that
synced
up
in
our
36
validators
in
sync
here,
and
so
what
does
that
mean?
That
means
the
fourth
choice
tip.
Is
this
particular
block
if
we
go
into
the
explorer
and
we
look
at
the
last
finalized
block
now
this
is
not
the
last
finalized
block.
This
block
is,
has
gray
lines
to
it.
A
B
Maybe
100
on
top,
you
can
make
it
say
just
say:
500.
A
B
I
I
I
looked
at
it.
It
looked
as
if
it's
gonna
it's
taking
some
time,
but
maybe
we
can
revisit
this
yeah.
A
A
A
Yeah,
it's
just
slowing
down
a
little
bit
and
so
in
the
event
of
a
consensus,
failure.
What
you
will
see
here
is,
you
will
actually
see
two
blocks.
You
won't
see
a
single
block
right,
so
what
that
means
is
then
now
the
network
has
forked
right
and
so
there's
an
alternate
version
of
the
blockchain,
and
so
in
this
event
the
validators
will
detect
this
because
they'll
see
something
very
similar
to
this
testnet
status.
Page
right,
that's
the
status
endpoint
we're
building
in
the
node,
and
it
basically
provides
this
information
it.
It
provides.
A
A
A
We
don't
know
which
ip
address
necessarily
sent
this
block
very
easily,
but
they
could
still
be
voting.
We
just
can't
tell
here
right.
So
if,
if
the
report
isn't
open,
it's
not
possible
for
us
to
get
information
from
them.
A
So
so,
in
the
event
of
a
consensus,
failure
you
see
this
split,
and
so
what
the
validators
need
to
do
is
they
need
to
figure
out.
Okay,
which
of
the
chains
is
legitimate,
which
of
the
chains
is
not
legitimate,
who
equivocated?
A
What
were
the
transactions
that
were
illegitimate
and
what
is
the
last
good
finalist
finalized
block
and
what
are
the
transactions
that
are
good,
that
need
to
be
replayed.
So
this
is
the
concept
of
social
consensus
right.
The
validators
would
then
figure
out
what
the
last
good
checkpoint
is,
the
last
good
block.
A
A
What
is
the
last
good
finalized
block
to
roll
back
their
global
state
to
that
last,
good
checkpoint
or
last
good
finalized
block,
identify
the
legitimate
transactions,
identify
the
validators
that
equivocated
and
then
basically
run
the
good
transactions,
slash
the
validators
that
equivocated
and
restart
the
network
right
this?
This
is
something
that
we
will
provide
as
a
set
of
apis,
and
the
validators
will
basically
need
to
agree
out
of
protocol
very
similar
to
the
genesis
process.
They
agree
out
of
protocol
from
people
that
they
trust
how
to
restart
the
blockchain.
A
Now
we're
building
in
all
the
struts
into
the
code
to
prevent
equivocations
like
we're.
You
know,
andreas
has
a
ticket
to
basically
make
it
impossible
for
equivocations
to
happen
is
quite
literally
like
prevent
equivocations
from
happening,
I
think,
is
what
it's
called:
make
it
impossible
to
equivocate
in
the
highway
core
so
right
here,
here's
his
ticket
make
it
impossible
to
equivocate
in
highway
core
it's
in
progress
and
so
make
sure
an
active
validator
never
creates
an
equivocation.
A
So
we
are
building
what
we
need
to
build
in
the
code.
Such
that
equivocation
will
never
happen.
We
understand
this
is
a
slashing
condition.
Obviously,
validators
don't
want
to
equivocate.
They
want
to
make
sure
that
they
won't
equivocate.
They
want
to
monitor
for
all
this,
but
they
sometimes
you
just
never
know
right.
You
write
a
lot
of
code
that
you
hope
never
executes,
but
we
still
need
to
make
sure
that
in
the
event,
god
forbid
something
terrible
happens
and
social
consensus
is
required
that
we
need
to
provide
the
tooling
to
enable
that
for
our
validators.
A
A
Our
network
is
going
to
be
decentralized
and
permissionless
from
day
one.
So
we're
not
going
to
do
this
like
we're
not
going
to
slowly
decentralize
slowly,
make
the
network
permission.
That's
right,
it'll
be
permissionless
on
day
one.
We
do
plan
on
increasing
the
number
of
bonding
slots
available
over
time,
probably
in
protocol.
A
Okay,
great
there's
a
folks
in
here
that
might
be
able
to
talk.
So
if
there's
any
questions
go
ahead
and
put
them
in
the
qa,
so
the
other
thing
that
the
community
wanted
to
talk
about
was
tps
transactions
per
second,
the
infernal
tps
number.
So
let's
talk
about
it
right,
so
the
scala
node,
we
attempted
to
run
a
a
performance
test
on
the
scala
node.
We
discovered
that
we
could
cram
in
about
a
thousand
transactions
in
a
block
right.
So
there's
there's
two
layers
of
performance
right
so
or
three.
A
There's
three
aspects
to
performance.
One
aspect
to
performance
is
the
virtual
machine
itself
like
how
fast
is
the
virtual
machine?
How
fast
can
it
make
state?
You
know,
updates
in
the
state?
Try.
How
fast
can
we
run
transactions
in
wazami
right,
which
is
the
parity
wasm
interpreter
for
the
code?
How
fast
can
all
of
this
take
place
right
and
so
there's
two
types
of
transactions
in
the
casper
labs
protocol.
A
One
type
of
transactions
are
those
those
contracts
that
are
part
of
the
global
state
and
they
formally
exist
at
the
blockchain
layer.
What
does
that
mean?
That
means
I
send,
I
send
a
block
of
wasm
code
to
the
blockchain
and
that
wasn't
code
gets
installed
in
the
blockchain,
and
then
I
execute
that
wasn't
code
by
invoking
it
that's
one
type
of
transaction
right.
That
is
what
the
what
most
of
the
d5
contracts
you
see
out
in
the
space
they
run.
They
run
their
code
in
this
manner.
A
It's
on
the
blockchain
it's
code
on
the
blockchain,
the
other
type
of
transaction
is
called
what
we
call
the
host
side
function
and
the
host
side
functions
are
those
that
are
actually
part
of
the
contract
runtime
they
are.
They
are
part
of
the
global
state,
but
they're
part
of
the
virtual
machine
core
execution.
A
The
effects
of
this
host
side
execution
happen
on
the
blockchain
right.
So,
for
example,
if
I
and
and
one
such
example
of
this
is
a
token
transfer,
so
if
I'm
transferring
token
from
account
a
to
account
b,
the
effects
of
this
token
transfer
happen
on
the
blockchain,
it's
possible
to
see
it
in
the
blockchain.
However,
the
token
transfer
function
the
code,
the
wasm
code,
to
run
a
token
transfer,
isn't
on
the
blockchain
itself.
A
It
will
go
through
code
review,
it
is,
it
is
part
of
it
is
open
source,
it
will
be
audited
for
safety,
and
you
know
attack
vectors,
but
it
isn't
something
that
we
deployed
to
the
blockchain
it's
host
side
and
because
it's
host
side,
it's
a
lot
faster
right,
and
we
did
this
because
we
wanted
obviously
token
transfers
are
really
important.
Token
transfers
have
are
going
to
happen
very
very
frequently.
It
made
a
lot
of
sense
for
us
to
say
we're
just
going
to
bring
token
transfers
host
side
right.
A
We
wanted
to
be
opportunistic
in
the
performance
of
host
side,
the
benefits
of
host
side,
token
transfers,
and
so
we
brought
it
homeside.
So
we
can
get
better
transactions
and
better
throughput
for
the
blockchain.
So
I'm
able
to
benchmark
effectively
what
the
vm
does.
A
I
have
really
solid
benchmarks
for
the
vm,
so
I
can
tell
you
the
vm
will
run
about
if
you
talk
about
global
state
based
contracts
and
it
all
depends
on
the
size
of
the
contract
right
we
can
do
about,
and
I
think
henry
and
ed
will
need
to
keep
me
honest
here.
Ashok.
You
need
to
keep
me
honest
here.
I
believe
those
benchmarks
came
in
about
175
events
per
second
per
core.
Is
that
right,
or
is
that
also
host
side?
A
A
I
believe
that
is
approximately
150
events
per
second
per
core
right
per
core,
and
so
what
that
means
is,
if
you're,
on
an
eight
core
machine,
it's
about
8x
that
that
does
not
include
any
consensus
overhead
on
the
token
transfers
and
warned
me,
don't
get
too
excited
about
this
meta,
but
on
his
machine
he
was
able
to
benchmark
about
10k
10k
token
transfers
per
second
on
his
machine
which
is
about.
I
think
his
machine
is
about
8x.
I
think
he's
got
eight
cores
on
it,
which
is
about
2500
token
transfers
hostside
in
the
virtual
machine.
A
It's
important
right!
This
is
an
important
number,
because
this
is
the
ceiling
like
this
is
the
highest.
We
can
ever
go
for
token
transfers,
which
is
pretty
dang
high.
It's
pretty
cool
this
now
we
still
have
opportunities
to
do
a
lot
of
things.
In
years,
three
to
five,
you
know
tall.
We
could
look
at
guazamur
instead
of
wasabi
right,
there's
wasa
wasabi
is
where
about.
Eighty
percent
of
our
bottleneck
is
on
the
system,
so
moving
to
wazimer
could
make
it
a
lot
faster.
This
is
not
main
network.
A
A
Now,
on
top
of
that,
you
have
to
overlay
consensus
overhead
right,
and
this
is
the
benchmark
I
don't
have
yet
we
could
have
done
benchmarks
on
the
scala
node
for
for
consensus
overhead,
but
we
ran
into
a
problem
with
the
deploy
buffer
architecture.
A
In
scala,
we
found
that
the
deploy
buffers
were
basically
doing
buffer
overflows
and
we
couldn't
cram
in
more
than
a
thousand
transactions
into
a
block,
and
there
isn't
any
reason
for
us
to
be
limited
to
a
thousand
transactions
per
block,
because
what
goes
in
the
block
are
arguably
like
in
the
new
rust
architecture.
It's
only
deploy
hashes
that
go
into
the
block.
A
It's
not
it's
not
actually
wasm
code
right
and
in
the
other,
in
the
scala
architect,
in
the
scala
node,
the
the
basically
when
you're
invoking
a
contract.
What
goes
into
the
block
is:
is
a
minuscule
it's
a
very,
very
small
piece
of
information
that
goes
into
the
block.
It's
basically
the
address
of
the
contract.
You
want
to
invoke,
and
so
theoretically,
you
should
be
able
to
cram
in
a
lot
of
transactions
into
a
block.
We
set
the
gas
limit
very
high,
depending
on
on
what
the
nodes
can
do,
or
we
make
this
adjustable.
A
We
should
be
able
to
get
pretty
significant
throughput
right.
Just
don't
know
what
those
numbers
are.
We
need
to
fine-tune
it
and
figure
out
what
the
consensus
overhead
looks
like
and
what
the
deploy,
how
the
deploy
buffer
architecture,
lands
and
right
in
terms
of
how
quickly
deploys
are
gossiped
right
now
in
the
rust
node.
The
way
the
architecture
works
in
rust,
node
is
very
different
than
most
other
blockchains
we're
going
to
be
doing
execution
after
consensus.
A
So
what
does
that
mean
inside
the
blocks?
The
consensus
model
is
going
to
be
optimistic,
which
is
kind
of
cool
inside
the
blocks.
We're
going
to
include
hashes
of
deploys
and
the
network
is
going
to
be
very
gossipy,
so
the
deploys
will
be
gossiped
to
all
the
nodes,
and
what
will
happen
is
the
node
will
have
to
verify.
A
It
has
all
the
deploys
that
were
included
in
the
block
before
it
can
run
the
block,
but
the
votes
on
the
block
are
tallied
before
right.
So
the
nodes
vote
on
the
block,
basically
by
providing
attestations
and
then
after
the
block
is
finalized,
then
the
nodes
will
do
a
bulk
insert
or
you
know,
a
single
insert
into
the
global
state
after
it's
run,
all
the
deploy,
so
the
node
has
to
validate.
It,
has
all
the
deploys
it
finalizes
block,
while
the
block
finance
finalization
is
happening.
A
At
the
same
time,
the
node
is
gathering
up
all
the
deploys
and
once
it
has
all
the
deploys,
it
can
go
ahead
and
run
the
block,
so
the
vm,
the
rate
at
which
the
vm
can
run
all
the
deploys
is
hugely
important.
So
it
feels
to
me
like
we
were
I'm
hoping
for
a
thousand
transactions
a
second,
but
it's
anybody's
guess
at
this
point
right.
That's
my
goal
is
to
get
to
a
thousand
transactions
per
second
on
this
network.
A
A
I've
already
said
that
I
think
that
the
tps
thing
is
a
silly
thing
that
we
do
to
ourselves
in
blockchain.
I
think
we're
focusing
on
the
wrong
thing.
You
know
visa
offers
40
000
transactions
per
second
sure,
but
they
have
many
many
many
servers
that
are
not
doing
state
replication
right.
It's
just
apples
and
oranges.
We
really
shouldn't
be
talking
about
transactions
per
second
in
the
manner
we
are
because
it's
not
the
value
of
blockchain
right,
like
the
value
of
blockchain,
really
is
about
the
trust
layer.
A
A
That's
exact,
that's
exactly
that's
100,
correct
right,
like
when
I
worked
at
avalara.
An
avalaire
is
a
very
large
mini.
You
know:
billion
dollar
market
capitalization
company
now
great
company.
You
know
I
remember
we
would
process
about
1400
sales,
tax
trends,
calculations,
a
second
in
the
core
architecture-
I'm
sure
they've
done
a
lot
of
work
since
then,
but
they
have
to
deal
with
database
sharding
as
well
right
and
so
having,
like
you
know,
20
000
transactions
per
second
in
blockchain
is
just
not
realistic.
A
It's
not
it's
not
correct
and
we
do
ourselves
a
great
disservice,
because
if
we
sacrifice
security
for
that,
we've
basically
just
shot
ourselves
in
the
foot
right
and
it's
not
something
we're
going
to
do
here.
Security
is
paramount.
Having
a
trustless
blockchain
is
paramount
and
having
good,
sustainable
infrastructure
right,
like
our
node
architecture,
is
going
to
be
sustainable.
A
You
can
use.
You
can
always
query
the
linear
blockchain
for
historical
transactions,
but
the
global
state
is
going
to
be
a
representation
of
what's
needed
today,
right,
it's
not
going
to
be
representation
of
everything
that
has
ever
happened
from
the
beginning
of
time.
Nobody
does
that.
You
can't
even
do
that
with
your
bank
right.
Your
bank
will
will
not
give
you
online
transaction
data
data.
You
got
to
go
to
your
old
pdfs
after
a
certain
point
and
that's
exactly
the
model
we
will
follow
as
well.
A
C
C
Where
does
governance
plug
into
your
decentralization?
Given
that
you're
decentralizing
fully
right.
A
Yes,
it's
a
really
great
question,
so,
if
you
think
about
so,
the
casper
protocol
has
got
some
interesting,
interesting
features
in
it
that
I
think
are
going
to
make
the
on-chain
it's
gonna.
It's
going
to
be
a
mash-up
of
on-chain
and
off-chain
governance
right.
It's
like
the
social
consensus
piece
is
absolutely
has
to
be
off-chain
right,
like
there
isn't
a
way.
A
If
you,
if
you
experience
this
a
catastrophic
consensus
failure,
then
the
honest
validators
have
to
get
together
to
recover
the
network,
so
they're
going
to
have
to
have
some
way
that
they're
going
to
coordinate,
they
have
to
coordinate
and
agree,
and
that's
definitely
a
consensus
mechanism.
I
mean
I'm
sorry,
governance
mechanism
that
we
haven't
clearly
specified
yet
right.
To
be
honest,
we
we
have
some
ideas
about
a
board
and
ratification
of
of
certain
of
certain
governance
processes
right.
A
So
we
believe
that
ratification
is
important,
but
the
interesting
thing
about
let's
talk
about
the
technology
right,
so
the
casper
protocol
offers
several
features
right.
One
of
the
one
of
the
legacy
features
that
the
casper
protocol
has
that
almost
all
blockchains
have
is
that
miners
or
validators
vote
for
a
protocol
version
by
accepting
a
version
of
the
software
right.
So
you
can
see
here
there's
a
software
version.
This
validator
has
accepted
this
version
of
the
software
by
installing
it
so
in
the
event
of
a
protocol
upgrade.
A
This
implicit
vote
comes
in
for
the
validators
by
ins
choosing
to
install
the
protocol
version.
So
that's
the
first,
that's
the
first
manner
in
which
they
vote.
The
second
manner,
which
is
not
expressed
here
on
my
screen,
is
that
validators
right
the
notion
of
a
node
operator
right.
So
this
is
a
node
operator.
This
is
a
person
running
a
software
version
of
a
node.
A
They
are,
they
implicitly
vote
on
a
version
of
the
protocol
by
accepting
it
installing
it
on
their
software
on
their
hardware,
sorry
and
and
continuing
to
participate.
The
protocol,
the
other
person,
the
stakeholder
is
the
token
holder
in
our
network.
If
you
have
a
custody
of
your
private
keys-
and
this
is
a
big
if
right
so
I
don't
know
how
to
solve
the
exchange
custody
problem,
people
have
to
have
self-sovereign
custody
of
their
keys.
If
you
have
custody
of
your
keys,
you
can
delegate
your
tokens
to
a
validator
right.
A
So
if
you
think
in
the
in
the
so
you
can
so
that's
the
first
thing
you
delegate
your
tokens
to
validator.
The
second
piece
is
that
anybody
can
delegate
tokens
to
any
validator,
so
you
can
discover
which
validator
may
be
providing
you
a
certain
return
for
staking
rewards
a
validators.
A
A
All
token
holders,
if
they
have
custody
of
their
keys,
are
allowed
to
are
allowed
to
delegate
their
tokens
to
a
given
node
operator
in
this
manner.
They
are
basically
placing
their
face
and
trust
in
this
node
operator
on
the
rate
of
uptime
and
consistency
and
responsiveness,
and
you
know
their
reputation
and
the
returns
and
the
rewards
that
they're
giving
them
right.
So
that's
how
the
token
holder
actually
votes
on
a
validator.
A
The
third
thing
to
think
about
is
dap
developers
in
our
protocol.
Adapt
developers
are
able
to
specify
a
supported
protocol
version
for
their
dap,
so
that
means
in
the
event
of
a
contentious
fork.
Dapps
are
going
to
be
able
to
say
well.
These
are
the
protocol
versions
that
I
support
right.
If
the
adap
is
bringing
a
lot
of
transactions
and
they
have
a
lot
of
users
which
protocol
version
they
support
is
going
to
kind
of
matter,
it's
going
to
matter
a
lot.
A
It's
going
to
matter
to
the
validators
which,
in
turn,
if
it
matters
to
validators,
it's
going
to
matter
to
the
token
holders,
because
the
token
holders
will
want
to
go
to
the
validators
that
are
going
to
make
transaction
fees
and
be
able
to
support
the
network
and
bear
in
mind.
We
offer
bonding
auctions
or
bonding
q
right.
So
the
top
n
number
of
validators,
with
the
most
stake,
are
the
ones
that
get
in
and
are
bonded
in
the
network.
A
A
Dapp
developers
have
a
voice
at
the
table
with
which
version
of
the
protocol
fork
they
go
with
and
because
they're
bringing
the
users
in
the
transaction
fees,
both
node
operators
and
validators
alike,
are
going
to
care
which
version
of
a
protocol
fork.
Adapt
developer
goes
with,
and
obviously
everybody's
going
to
care
that
at
a
fork
which
version
of
the
software,
a
particular
node
operator
is
installed
because
that's
going
to
dictate
whether
or
not
they
have
stakers
sticking
with
them.
A
So
in
a
manner
of
speaking,
we
kind
of
have
addressed
the
collective
action
problem
right,
where
there's
always
been
a
lack
of
alignment
between
the
three
different
stakeholder
groups,
node
operators,
stakers
and
dapp
developers-
and,
of
course,
the
end
users
right.
The
end
users
are
even
represented
here,
because
the
app
developers
bring
the
end
users
so
I'll
pause
there.
I
don't
actually
I'd
like
to
run
some
game
theoretic
analysis.
A
I
would
be
interested
to
know
how
many
dap
developers
are
actually
also
node
operators
right
if
this
is
something
malika
has
been
trying
to
run
the
game
theoretic
analysis
of
this,
but
we
don't
actually
know
how
many
or
what
percentage
of
nodes
that
are
run
in
this
kind
of
a
network
are
actually
also
going
to
be
running
their
own
dap,
because
they
actually
have
two
two
votes.
A
C
Just
one
more,
I
probably
missed
it.
I
was
a
little
late.
Getting
in
there
was
a
dev
dao
con
fab,
the
any
update
on
the
launch
date
for
mainnet
target.
A
So
the
intention
is
to
kick
off
the
delta
test
net
on
our
birthday
october,
31st
after
we
are
starting.
A
Yes,
and
so
then,
after
that
we
go
into
the
hardening
phase,
and
so
it
all
depends
on
how
we're
starting
hardening
before
we
suspect
we
need
a
minimum
of
12
weeks
of
hardening,
but
the
idea
is
to
try
to
cut
that
down
to
eight
weeks,
and
you
know
four,
you
know
six
to
eight
weeks,
but
it's
a
very
aggressive
timeline.
We
are
still
pushing
hard
for
q4,
don't
know
how
I
don't
know,
what's
going
to
happen
in
in
delta
test
now.
A
A
It
is
it's
all
just
time
right
and
you
know
what
we're
trying
to
do
here
is.
We
are
working
with
our
validators
and
we're
working
with
infrastructure
and
devops
partners.
You
know
technology
partners
and
you
know,
starting
next
week
we're
going
to
get
them
the
software
right.
So
you
know
you
know
david
thai
of.
C
A
Marco,
you
know
I'm
I'm
gonna
talk
to
zach
this
week
to
get
david's
time
and
just
get
them
to
start
banging
on
this
thing
right
and
we're
talking
to
folks
on
pen
testing.
We
signed
our
statement
of
work
with
trail
of
bits
to
rail
of
bits
has
got
to
do
their
security
review.
They
are
on
tap
for
november
to
do
the
security
review
so
we're
getting
the
highway
paper
updated
for
all
the
attacks.
A
So
it's
ready
for
peer
review
and
the
security
review
and
getting
ready
to
give
them
the
code
for
the
consensus
component.
So
we
want
to
get
the
security
review
done.
We
don't
know
what
that's
going
to
yield
right,
we're
also
working
on
custody
solutions,
great
great
discussions
around
custody
solutions
and
mainnet
public
sale
super
excited
about
that.
So
there's
a
lot
of
things
that
are
lining
up
for
the
main
net
launch
and
the
public
sale.
But
it's
just
a
lot
of
work
to
to
bang
out
right.
Yeah,
yeah,
yeah.
A
C
I
think
the
grant's,
not
the
big
problem
now
now
it's
everything
else
right.
The
grant
will
solve
itself
in
the
next
week
or
two,
my
expectation,
the
lawyers
are
finally
getting
down
to
changing
commas.
C
Thank
you,
so
we're
okay
there,
but
then
there's
everything
else
right
and
a
lot
of
that
depends
on
timing.
A
A
All
right
cheers
everyone
thanks
a
lot.
Thank
you
very
much
for
the
comments
and
feedback,
and
I
think
og
is
going
to
write
up
his
summary.
So
look
forward.
Look
for
that
drop
in
in
the
channel
later
this
week.
Cheers
thanks
bye.