►
From YouTube: IOHK | PMO Project Shelley June 2018 Update
Description
In this update, IOHK project manager Liz Bancroft-Turner talks about the forthcoming capabilities for Cardano. She explains the Shelley Project and its overarching goal, how it's broken down into manageable workstreams and outlines the key deliverables and timeline expected for release.
https://iohk.io/team/liz-bancroft
--
Input Output
See more at: https://iohk.io
Get our latest news updates: https://iohk.io/blog/
Meet the team: https://iohk.io/team/
Learn about our projects: https://iohk.io/projects/cardano/
Read our papers: http://iohk.link/paper-ouroboros
Visit our library: https://iohk.io/research/library/
In the press: https://iohk.io/press/
Work with us: https://iohk.io/careers/
A
Hi
everyone,
its
Liz
Bancroft
Turner
from
irh
Kay
here
today,
to
give
you
June's,
update
from
Project
Shelly
in
today's
agenda,
we'll
go
over
what
the
overall
goal
is
for
the
Shelly
Project.
This
is
just
to
give
everyone
a
recap
of
why
we're
doing
this
project
provides
an
update
of
the
work
we
have
carried
out
for
the
month
of
June,
then
review
where
we
are
on
the
plan
in
terms
of
what
has
been
delivered
and
what
is
due
to
be
delivered.
A
And,
lastly,
just
talk
about
the
progress
we've
made
and
testing
it
so
far,
so
the
primary
goal
of
the
Shelly
release
is
to
upgrade
the
network
to
operate
in
a
decentralized
fashion.
The
project
consists
of
the
following
Rock
streams,
incentives,
delegation
and
networking
the
incentives.
This
is
about
providing
stakeholders
with
monetary
incentives
to
follow
the
protocol
and
make
sure
the
system
one
smoothly
for
the
delegation.
This
is
about
allowing
stakeholders
to
delegate
their
right
and
obligation
to
sign
blocks
to
at
their
party,
and
that
reckoning
is
all
about
providing
the
network
infrastructure
to
support
decentralization.
A
So
what
have
we
done
for
the
month
of
June?
So,
starting
with
delegation
and
the
research
paper,
we've
established
how
delegation
will
be
performed
in
a
way
that
satisfies
our
requirements.
So
some
of
those
requirements
that
we've
detailed
out
in
the
paper
are
things
like
state
pools
recovery
if
keys
are
compromised,
making
sure
that
the
security
of
your
funds
does
not
get
compromised.
If
you
delegate
now
a
number
of
security
convenience
and
reward
considerations
that
we've
discussed
inland
and
detailed
in
the
paper.
A
Moving
on
to
the
delegation
design
document
we've
been
working
on
specifying
and
detailing
how
the
schema
proposed
and
the
research
paper
can
be
implemented
in
Cardno.
We'll
make
sure
that
the
design
of
the
delegation
is
compatible
with
the
envisioned
incentives
mechanisms
and
a
few
of
those
desire
loans
we've
covered
in
the
design
document
stuff
like
howling
of
stale
snake.
That
is
what
does
the
system
do
if
it
detects
that
a
staking
pool
or
other
stateful
stakeholder
stops
producing
blocks?
A
We've
discussed
how
to
share
rewards
with
people
delegating
to
a
pool
without
flooding
the
system
with
transactions
and
creating
lots
of
dust
in
the
UTX
ohm.
We've
mentioned
that
specifying
how
leader
election
works
with
within
delegation
we've
updated
the
chapter
on
wallet
recovery.
This
is
to
effect
the
new
address
scheme,
so
moving
on
then
to
the
incentives
research
paper
here.
We've
proved
that
using
formulas
for
utility
each
Nash
equilibrium
has
a
desired
form
of
Caples
of
equal
size.
So
a
Nash
equilibrium
is
a
essential
concept
in
game
theory.
A
So
here
you
have
a
game
in
which
players
can
choose
a
strategy
and,
depending
one
that's
trusting
each
player,
then
chooses
rewards
are
paid
to
the
players.
So
in
our
case
the
strategies
are
things
like
I
quote:
a
pool
would
cost
so
and
so
high
and
set
my
margin
to
so-and-so
high
or
I
delegate.
This
ratio
of
my
state
to
that
pool
and
that
the
rest
of
that
other
pool
so
Shashi's
are
either
creating
a
pool
with
certain
parameters
or
delegating
to
existing
pools.
What,
then,
is
Nash
equilibrium?
A
So
it's
about
selecting
strategies
for
each
player
so
that
such
player
or
no
player
can
improve
the
his
or
her
award
by
unilaterally
changing
his
strategy
or
her
strategy.
So
in
other
words,
we
have
a
Nash
equilibrium
if
we
have
no
rational
reason
to
change
what
I,
what
he's
doing,
if
nobody
else
changes
what
they're
doing
so.
The
basic
idea
of
applying
game
theory
to
practical
problems
is
the
belief
that
in
reality,
things
will
settle
down
in
a
Nash
equilibrium.
A
So
the
fact
that
we
proved
that
there
are
no
bad
equilibria
means
that
hopefully,
in
practice
will
indeed
end
up
with
K
pools
of
equal
size,
so
that
was
the
main
achievement
on
the
leisure
research
side.
Moving
on
to
the
design
document,
after
having
settled
on
the
general
shape
of
the
incentives
mechanism,
the
research
team
spent
the
last
month
fine-tuning
verifying
and
refining
it.
So,
first
of
all,
we
made
a
small
simplification
to
one
of
our
formulas
for
pool
desirability
and
verified
that
change.
A
Experimentally,
so
after
some
back-and-forth
between
theory
and
experiments,
results
eventually
aligned
perfectly,
it
gave
us
even
more
confidence
than
that.
Our
mathematical
analysis
was
correct,
so
the
research
team
was
able
to
formally
prove
the
correctness
of
this
improved
game
theoretical
model,
and
then
the
experiments
confirmed
the
mathematical
theorems.
A
On
the
networking
side,
we
had
a
new
addition
to
the
team
who
is
now
looking
at
this
and
he's
soon
to
be
properly
on,
boarded,
he's
still
ramping
up
and
getting
familiarized
with
what
was
left
from
the
former
colleague
on
the
networking
delta-q
measurements
enzyme.
We've
identified
a
number
of
real-world
use
cases
that
were
going
to
investigate
to
act
as
examples
during
the
implementation
and
testing.
So
here
we
have
control
to
make
the
network
usage
more
or
less
aggressive.
A
In
its
real-time
use
of
network
resources,
we've
identified
the
key
use
cases
like
catching
up
with
the
tip
of
the
chain
and
block
broadcasts.
The
delta
key
measurement
approach
is
being
used
to
help
minimize
natan
seas
for
those
activities
while
not
creating
our
burst
network
performance
or
for
other
applications.
The
end
user
might
be
using
at
the
same
time
so
making
the
card
a
card
on
Oh
assessment
layer,
node,
a
responsible
network
citizen
while
still
ensuring
it
performs
effectively.
So
we
are
currently
investigating
those
use
cases
on
the
communication
protocol
10.
A
This
is
an
essential
part
of
the
communication
protocol
design.
We've
been
looking
at
the
way
in
which
a
node
downloads
blockchain
segments
from
its
peers
and
the
way
in
which
it
deals
with
Forks.
So
this
is
done
not
so.
This
is
not
not
so
efficiently
in
the
current
release
and
cuaderno
assessment
layer,
so
it's
essential
that
we
improve
on
that.
A
A
So
then
we
have
a
few
graphs
that
we
would
like
to
present
and
the
first
one
is
is
basically
where
the
x-axis
is
a
time.
The
chart
shows
you
the
evolution
of
pools,
so
each
colored
band
is
a
pool
and
the
height
of
that
band
is
the
size
of
the
pool,
so
the
simulations
use
K
equals
10.
So,
for
example,
we
aim
for
temples,
but
not
you
know,
hundred
as
we
will
in
real
life.
A
So
the
second
chart
shows
you
similar
parameters
as
the
first
graph,
so
where
the
first,
where
the
first
graph
shows
you
where
pool
costs,
are
low
with
respect
to
rewards
and
the
stake
of
the
pool
leader
has
no
influence
on
rewards
and
this
second
graph
costs
are
high
and
there
is
a
second
significant
influence
of
leader
stakes
on
rewards.
So,
under
both
sets
of
parameters,
we
get
the
desired
results.
A
So,
moving
on
to
the
plan
for
the
research
phase,
we
are
over
Lamba
status.
So
whilst
we
have
completed
the
delegation
research
paper
in
green,
we
are
still
making
final
adjustments
to
the
incentive
research
paper.
So,
as
you
can
understand,
speculative
research
by
its
nature
is
not
an
exact
science
and
while
we
have
not
met
our
calendar
date
milestones
for
the
research
phase,
we
are
confident
about
achieving
our
overall
business
objectives.
The
design
phase
is
can't
be
tracking
green.
A
We
are
due
to
complete
their
delegation
and
incentives,
design
docking
the
next
week
and
then
the
incentive
design
would
then
be
merged
in
with
their
delegation
design
to
make
it
one
final
document.
So
once
we
have
sign-off
on
the
design
document
which
we
are
aiming
for
next
week,
we'll
then
detail
out
the
technical
implementation
plan
whereby
we
broke
the
design
down
into
the
user
stories
and
tasks
for
the
developers
to
implement,
so
just
to
give
you
some
update
on
the
test
nets
and
where
we
are
we're
currently
in
the
initiation
phase
of
defining.
A
You
know
the
objectors,
deliverables
and
work
plan
for
the
shadow
test
net
launch
so
I
kind
of
like
to
describe
this
as
the
OTW
method,
which
is
the
objectives
deliverables
on
a
work
plan.
So
the
odw
method
will
contribute
to
the
test
net
development
by
translating
the
objectives
into
deliverables,
which
will
then
turn
shape
will
turn
the
shape
of
it
into
the
work
plan.
Ie
your
work
stream
phases
and
activities.
So
so
far,
we've
been
working
on
defining
the
high
level
test,
net
objectives
and
outcomes.
A
We've
scoped
out
the
high
level
work
activities
and
timeline,
we've
defined
for
lemony
scheduling
risks,
we've
secured
secured
planning
resources,
we've
conducted
initial
stakeholder
analysis
engagement.
So
by
having
this
framework
in
place,
this
will
ensure
that
there
is
a
alignment
and
integrity
of
the
test
plan
against
the
users
needs.
So
this
is
obviously
to
avoid
the
risk
of
producing
a
meaningless
plan
of
unfocus
activities
so
like
here
in
ihk,
we
spend
a
lot
of
time
and
the
initiation
phase.
This
is
to
ensure
users
needs,
are
addressed
to
create
the
best
outcomes
and
experiences.
A
So
what
makes
us
different
is
our
focus
on
the
education.
We
provide
a
lot
of
education
material
to
help
people
understand
how
to
use
our
technology.
So
that
concludes
the
end
of
the
update
for
June
I
hope.
You
found
this
useful
and
thank
you
for
watching
and
look
forward
to
seeing
you
in
the
next
month's
update
bye
for
now.