►
Description
The second Whiteboard Series session that we conducted during the NY Blockchain Week was with Monica Quaintance (https://twitter.com/QuaintM) from Kadena (https://twitter.com/kadena_io), who was interviewed by Alex Skidanov (https://twitter.com/AlexSkidanov)
Learn more about Kadena here: https://kadena.io/
Location: Kadena HQ, Brooklyn, NY | Consensus Week 2019
Download the video here: https://near.ai/35543
------- About Whiteboard Series ---------
The Whiteboard Series with NEAR is a set of video interviews with Founders who are building scalable solutions for Blockchain. We deep dive into their story, what they're developing and how it is helping the ecosystem.
Follow the latest from NEAR Protocol on,
Discord: https://near.ai/discord
Medium: https://near.ai/medium
Twitter: https://near.ai/twitter
GitHub: https://near.ai/github
#WhiteboardSeries #FutureIsNEAR #Consensus2019
A
B
At
Kadena
now
my
title
is
head
of
research,
but
really
I
just
do
whatever
needs
to
get
done,
which
sometimes
involves
chain.
Web
I
was
on
the
original
chain.
Web
paper
with
will
he's
the
one
who
dreamed
up
the
crazy
idea,
but
now
I
spend
most
of
my
time
working
on
research
and
implementation
details
of
chain
web.
Most
recently,
I
have
published
a
paper
in
Euro
SP
about
security
properties,
entertainment,
which
we
can
also
talk
about,
that
could
be
kind
of
cool.
So,
let's
service.
A
B
B
B
Simple
payment
verification
right.
So,
if
an
let
me
go
in
the
middle
alright,
so
in
Bitcoin
you
have
a
block,
and
that
block
has
a
pointer
to
some
previous
block
right
and
when
you
make
a
new
block,
it
contains
a
hash
of
all
of
previous
history,
and
this
is
how
you
get
your
verifications,
that
people
can't
go
around
and
screw
around
with
watch
it,
because
you
can't
go
back
and
modify
previous
transactions
because
they're
included
in
every
future
block
right.
B
So
the
idea
behind
chain
web
came
from
first,
if
you,
instead
of
having
just
one
chain
what
if,
in
order
to
be
able
to
have
more
transaction
throughput,
you
had
two
chains
and
they
were
both
using
the
same
native
token,
both
using
same
protocol
and
each
chain
has
its
own
ledger.
We
can
call
them
like
a
and
B
or
something
so
chain
a
has.
This
whole
like
it
makes
a
block,
and
then
the
next
block
contains
the
previous
block
in
it.
But
in
this
case
we
want
them
to
be
related
to
each
other
and.
B
Chain
a
has
its
own
idea
of
history.
Has
its
own
accounts
on
it,
so
this
block
in
chain
a
will
also
contain
a
pointer
to
a
moment
in
time
on
chain.
B
and
you'll
know
that
this
Fork
of
chain
B
or
this
version
of
chain
B,
is
truth
on
chain
a
and
this
block
on
chain
B
contains
the
same
one
and
then
because
it's
two
chains-
and
we
only
have
two
of
them-
we're
also
going
to
have
it
cross
back
the
other
way.
B
Obviously,
the
having
the
same
number
of
messages
as
the
number
of
chains
is
not
very
efficient
because,
as
you
start,
making
the
number
of
chains
bigger
and
bigger
you're
suddenly,
if
you
have
10
chains
and
they're
all
talking
to
ten
all
their
peers
all
at
the
same
time,
you
start
to
have
the
handshake
problem
and
that's
too
many
messages
so,
instead
of
just
having
them
all
talk
to
each
other,
we
were
like.
Well,
you
can
do
this
idea
of
chains
talking
to
each
other
with
any
arbitrary
base
graph.
B
Why
not
come
up
with
a
base
graph,
that's
much
more
efficient
in
terms
of
message
propagation.
So
there's
this
idea
in
graph
theory
called
the
degree
diameter
problem,
which
is
where
you
want
to
maximize
your
order
so
maximize
the
number
of
nodes
in
a
graph
or
a
number
of
chains
in
chain
web.
For
example,
the.
B
B
B
B
B
A
B
B
Here,
we've
like
tied
a
and
B's
legs
together,
and
they
can't
go
too
far
forward
without
each
other,
but
I
actually
consider
that
to
be
a
benefit,
because
if
something
goes
wrong
with
the
network,
instead
of
like
people
just
willy-nilly
making
transactions
all
over
the
place
and
letting
it
spiral
out
of
control
like
eventually,
it
will
halt.
Okay,
because.
B
So
you
say:
nobody's
mining
this
one,
the
Mort
when
the
mining
reward
is
going
to
be
good,
I'm,
going
to
switch
and
reallocate
my
hash
power
to
be,
and
then
eventually,
if
the
whole
network
is
halting,
everybody
will
be
mining
me,
and
so
it
manages
to
unstick
itself.
At
least
that's
what
the
simulation
shows
so
far
and.
B
There's
a
perspective,
but
I
don't
want
to
complete
that
with
calling
a
B
or
C
people,
because
there's
sometimes-
and
we
get
this
conflation
with
people
that
have
been
looking
at
proof
of
state
projects
too
much
and
they
see
this
and
they
see
a
validator
graph.
They
see
it
see
this
and
they
see
a
minor
graph,
but
this
is
not
a
minor
graph.
This
is
a
protocol
graph.
B
In
fact,
we
totally
try
to
disambiguate
between
the
protocol
graph
and
the
relationships
that
miners
have
with
each
other,
so
we
still
have
a
validator
graph
and
in
fact,
only
when
we're
doing
simulations
and
when
we're
mining
in
our
test
net,
we
have
a
minor
graph
about
how
they
connect
with
each
other
and
who
sends
messages
to
whom
totally
different
from
how
chains
send
messages
to
other
chains.
And
it's
once
people
start
completing
these
with
people
they're
like,
but
this
person
is
going
to
end
up
attacking
this
person
and
you're
like
these.
A
A
So,
let's
go
with
like
x1
y1,
z1
x2
a
way
to
like
see,
for
example,
sure
so,
let's
say
that
the
character
is
the
person,
then
I,
guess
it's
X
a
would
be
better.
But
so
what's
the
m
x1
I'm,
observing
the
chain
right
and
I
also
have
some
view
on
the
on
the
other
chains.
My
others
cross-links
in
any
way
affecting
my
fortress
role
on
my
on
my
chain.
B
C
B
And
this
next
block
here,
like
obviously
this
guy's,
given
to
that
when
aid
needs
to
make
its
next
block,
it
needs
to
make
a
choice
because
it's
going
to
be
receiving
messages
from
both
people,
mining,
B
and
also
people,
mining,
B,
prime,
that
both
of
these
are
valid.
So
then
a
almost
immediately
needs
to
make
a
choice
between
this
link
and
this
link,
and
so
a
is
making
calls
on
whether
B
or
B
prime
is
valid.
It's
not
just
the
miners
on
D
and
B
prime.
B
A
C
C
B
A
But
those
endorsements
are
going
to
be
accounted
for
by
everybody,
but
let's
say
that
C
also
has
a
conflicting
note
right,
like
C,
isn't
the
same
situation
and
this
one
is
actually
endorsing
B
right
so
which
of
these
two
like
one
of
them
is
effectively
like
from
perspective
of
a
particular
minor
right.
So
let's
say
this
is
a
minor
x
from
perspective
of
actually
one
of
these
two
is
valid
right,
so
let's
say
ax
things
that
this
one
is
valid
at
this
point,
X
has
no
extra
information
right.
A
B
If
you're,
only
mining
a
subset,
then
you're
going
to
have
to
start
trusting
the
message
headers
that
you
get
from
other
trusted
parties,
which
is
you
know
if
you
belong
to
a
pool
and
your
friend
is
mining
a
and
then
your
friend
gives
you
the
block
like
you
as
X
will
trust
whatever
you
get
from
your
friend.
But
yes,
you
start
getting
these
like
confusing.
B
We
call
them
our
burrito,
because
you
have
lots
of
trees
and
so
many
trees
making
Arboretum
I.
Don't
know
it
was
true,
pne's
joke
when
we
made
the
paper,
but
like
you
can't
just
talk
about
single
trees
coming
off,
because
you
don't
have
one
chain,
we
get
multiple
chains,
and
so
yes,
it
does
start
to
get
that
there's
a
lot
of
information
and
that
you
might
not
have
all
of
it
as
a
minor,
which
is
why
we
say
like
people
should
really
mind
more
of
the
braid
rather
than
less.
But.
A
A
B
A
B
B
A
B
A
A
B
A
B
If
you're,
just
a
user,
you
can
only
synchronize
the
one
that
your
chain
is
on
and
that's
totally
fine.
You
can
just
listen
to
the
headers
coming
in
from
large
mining
pools
for
the
rest
of
the
information.
If
you
want
to
there's
no
need
for
you
to
replicate
any
more
than
that.
If
you
decide
that
you
want
to
scale
out
what
you're
doing
and
have
it
belong
to
more
chains
so
that
you
can
effectively
load-balanced
your
application.
You
can
do
that
by
cloning.
Your
application
onto
more
than
one
chain.
A
B
Right
now,
test
net
is
on
20.
We
just
torqued
to
a
larger
net.
We're
launching
I
think
we're
gonna
launch
with
20.
It
might
be
50
I,
don't
know
it
depends
on
how
ambitious
the
dev
team
yes,
but
the
plan
is
to
as
we
get
more
adoption
and
the
network
starts
to
become
congested
and
we
start
to
see
transaction
pooling,
then
you
will
fork
out
to
larger
configurations.
I
mean
in
theory,
chain
web
could
be
arbitrarily
large,
but
obviously
founded
by
normal
real-world
bandwidth
constraints.
B
A
B
A
A
B
A
Sorry,
yes,
and
so
on
this
chain,
because
we're
saying
this
100
chance
give
or
take,
then
this
chain
on
itself
has
approximately
10%,
also
a
1%
right,
approximately
1%
over
hash
power,
so
I'm
not
gonna,
throw
entire.
My
entire
part,
where
I'm
just
gonna,
throw
one
point:
one
percent
like
something
that
right
on
that
particular
chain:
what
I'm
gonna
do
and
I'm
going
to
create
a
completely
invalid
block
also,
so
this
is
the
chain
that
is
being
built,
so
that
was
valid
block
valid
block.
Then
they
created
something
which
makes
absolutely
no
sense
right.
A
Then
they
continue
building
right.
So
at
this
point,
naturally
the
honest
1%
will
say:
well,
that's
that's
nonsense,
like
their
client
will
just
discard
it.
Try
it
right
away,
so
they
will
continue
building
and
this
rule
makes
no
sense
for
them
right.
So
this
is
the
onus
chain.
This
is
the
dishonest
chain,
but
the
his
owner's
chain
is
growing
a
little
faster,
but
naturally
nobody
in
the
remaining
chance
respects
it
right.
So
they
make
humane
chains
and
doors
this
one,
but
in
this
chain
I'm
also
going
to
play
11.1%.
B
A
A
B
A
B
B
C
B
A
B
A
Yeah
so
I
copied
this
for
it,
and
this
one
is
well
right:
oh
if
it
was
100
node
graph,
I
would
have
two
more
right,
yeah,
so
I
don't
care
about
all
the
neighbors.
So
let's
say
that
in
all
the
in
all
the
charts,
which
are
not
one
of
those
for
a
little
less
than
50%
validating
at
least
one
of
those
four
and
a
little
more
than
50%
or
not.
Is
that
reasonable
assumption
yeah.
B
A
B
So
because
you
have
all
of
the
tiny
little
blocks
you
get
to
move
them
through
much
faster,
you
don't
have
to
have
the
same
hardware
requirements
per
individual
replicas
and
because
of
the
way
that
the
chains
are
interconnected.
You
get
these
really
cool
security
properties
of
chain
web.
It's
sort
of
like
the
interlinking
of
ghost,
be
giving
you
lower
block
times
and
if
you're
in
we
can
achieve
much
lower
block
times
because
of
the
nature
of
the
interconnectedness
of
the
braid.
B
B
B
C
C
B
This
is
the
the
whole
censorship
thing
that
we
were
just
talking
about.
So
in
the
security
paper
that
Troon
and
I
just
released
on
archives,
that's
getting
published
in
june
is
does
an
economic
analysis
of
how
expensive
it
is
to
try
to
do
this
attack
and,
if
you're,
less
than
51%
of
the
hash
power
of
the
entire
braid
you
it's
much
more
economical
for
you
to
just
mine,
because
you
have
to
spend
so
much
on
hash
power
and
the
potential
rewards
that
you
get
from.
It
are
highly
variable.
A
A
B
B
So
now
on
chain
B.
In
this
block,
you
can
resurrect
the
chains
that
were
burned
on
chain
a
that
changed
the
coins
that
were
burned
on
chaining,
and
so
you
can
imagine
if
you
were
on
c
and
c
communicates
with
B
and
not
a
that.
If
you
were
paying
somebody
on
C
from
a
then
once
you
made
it
out
to
blocks,
then
here
is
where
you
could
resurrect
your
coins.
A
A
B
Is
why
the
whole
trying
to
make
sure
that
transactions
are
synchronous,
thing
I,
don't
really
understand,
I'm
totally
fine
with
asynchronous
transactions,
because
as
long
as
I
can
prove
that
you
paid
me,
I
can
go
and
redeem
it
whenever
I
want
and-
and
we
don't
have
to
have
like
some
sort
of
uniform
number
of
tokens
in
the
system
at
all
times,
we
can
have
float
in
between
burn
and
receipt.
It
doesn't
really
matter
to
me
so.
C
B
C
A
B
A
B
C
B
B
B
All
of
the
juicy
stuff
now
and
test
net
we're
working
on
putting
through
a
transaction
simulator
that
is
pumping
a
lot
of
transactions
through
and
seeing
what
happens?
It's
pretty
fun,
oh
yeah,
packed
so
I
mean
you
might
want
to
tag
Stuart
in
except
he's.
Not
here.
You
can
talk
to
him
some
other
time
since
he
actually
wrote
the
lion's
share
of
pact.
We.
C
B
You
know
neither
here
nor
there
how
you
feel
about
the
EBM,
but
our
hypothesis
is
that
the
your
smart
contract
language
should
basically
handle
a
lot
of
stuff
for
the
developer,
that
you
don't
want
your
developer,
having
to
go
through
and
worry
about
something
like
a
namespace
abstraction
that
you
should
be
thinking
about
your
smart
contract.
Not
all
of
the
elements
that
you
wish
a
virtual
machine
had
actually
done
for
you
instead
so
packed
is
it
has
a
super
small
space.
B
It
has
a
super
small
number
of
functions
and
it
handles
like
he
said
for
you.
It
handles
it
has
a
very
granular
permission
set,
and
so
you
can
allow
people
to
do
different
things
depending
on
how
they've
authenticated
their
way
into
the
smart
contract.
There's
actually
not
a
you,
don't
put
in
your
key.
You
there's
a
function
where
you
put
in
your
governance
function
for
the
smart
contract
and
that
function
can
be
satisfied,
and
you
know
you
name
it
number
of
ways.
B
B
B
Pact
is
interpreted
on
the
whole
mess,
and
so
you
can
actually
put
pact
in
pretty
much
anything
you
can
put
pact
on
like
it
doesn't
have
to
be
a
smart
contract
language,
we're
actually
talking
to
some
people
about
putting
it
on
non
blockchain
type
of
applications.
It's
because
of
the
way
that
the
language
is
super
flexible.
You
can
do
a
whole
lot
of
things
with
it.
I
actually
had
a
call
with
Akamai.
They
were
like.
B
We
want
to
put
pact
on
top
of
something
that
we
made
internally,
that's
cool
great
yeah
pact
is,
it's
looks
a
lot
like
English.
It
doesn't
look
like
a
programming
language
in
the
way
that
you
would
sort
of
expect
expect
a
programming
language.
It
does
have
a
lot
of
front.
The
C
is
because
of
the
Lisp
thanks.
B
So
because
pact
has
so,
for
example,
pact
is
non
turing-complete
and
on
purpose
we
don't
think
that
we're
cursing
is
something
that
you
should
do
on
a
blockchain.
It
seems
like
a
silly
idea
to
try
to
calculate
Dijkstra's
algorithm,
shortest
path
from
New
York
to
LA,
on
the
blockchain,
and
so
because
the
the
syntax
tree
of
pact
is
very
limited.
B
We
can
unroll
the
whole
thing
and
pipe
it
straight
through
into
the
XIII
solver
with
SMT
Lib,
and
so
this
is
trivializing
a
whole
lot
of
work
that
went
into
it,
but
we
don't
have
to
worry
about
like
when
people
are
talking
about.
Oh
we're,
gonna
formally
verify
some
subset
of
solidity.
They've
had
to
carve
away
a
lot
of
things
that
we
have
carved
away
originally
when
we
wrote
pact
in
the
first
place,
and
so
it's
not
just
formally
verified
like
a
compiler
as
formally
verified.
B
It's
actually,
you
can
write
user
code
and
then,
when
you
save,
if
you're
tied
into
the
formal
verification
system,
it
will
verify
any
annotations
that
you've
put
in
our
own
annotation
language
into
your
smart
contract.
So
it
can
be
like
prove
that
this
value
can
never
go
negative
or
prove
that
this
account
can
only
receive
and
can
never
send.
But.
A
A
B
Think
the
future
is
totally
interacting
with
other
watchings.
I
would
love
to
see
that
happen?
There's
because
we
have
this
idea
of
being
a
fast
transaction
execution.
Layer
I
would
love
to
see
a
representation
of
other
people's
stuff
that
executes
on
cadena
and
the
neck
and
then
exits
afterwards,
so
like
flash
some
sort
of
representation
of
some
their
non
fungible
asset
onto
cadena
and
do
a
bunch
of
operations
and
then
move
it
back
cross
again.
That
seems
like
a
totally
reasonable
way
of
interacting
with
our
stuff.
B
Also
because
of
the
whole,
we
have
a
permission
blockchain
as
well.
In
our
stack,
our
permission,
blockchain
scale
will
be
ft,
is
also
designed
to
connect
to
chain
web.
So
we
have
people
that
are
writing
applications,
written
impact
that
have
some
part
of
it.
That's
on
a
private
blockchain
instance
that
they've
just
spin
up
and
some
part
of
it
that's
going
to
be
on
chain
web
and
that
those
pieces
talk
to
each
other
and
they
talk
to
each
other
in
the
same
way
that
you
do
any
sort
of
off
chain.
B
C
A
B
A
B
A
I
guess
it's
a
little
more
fundamental,
because
the
theorem
in
principle,
can
invalidate
the
whole
chain
or
of
Kadena
right,
so
even
lag
time
will
not
help
much
yeah.
It's
just
interesting
topic
in
general.
How
would
you
like
connection
with
the
with
slower
chance,
which
is
I?
Guess
it's
very
much
open.
B
A
C
A
Broadcasted
actually,
which
I
never
broadcasted
all
right,
so
imagine
that
you
were
honest
and
I
was
I
was
also
okay.
So
let's
say
that
the
connection
is
the
following:
I
show
these
two
charts
connected
this
to
connecting
these
two
connected
and
these
two
connected,
but
like
not
these
two,
for
example,
sure.
C
A
So
I
corrupted
these
three
by
by
sending
more
than
50
percent
of
the
hash
powers,
if
it
was
hundred
charts,
I
would
corrupt
six
again
right.
So
these
are
corrupted
what
I
do
is
I
create
a
block
here
which
I
wish
I'd
done
so
to
anyone
and
I
create
two
blocks
here
which
which
which
have
the
header
of
the
block
but
not,
but
the
block
was
never
sent
out.
So
how
is
it
handled
like
imagine?