►
From YouTube: Ethereum Core Devs Meeting #30 [12/15/17]
Description
A
That's
good
I
think
we
are
now
streaming.
Let
me
just
ask
the
group:
are
we
streaming?
Okay,
great
I,
think
we
can
begin
everybody.
The
welcome
we're
trying
to
miss
time,
because
we
have
a
limit
for
Google,
Hangouts
I
hope
that
that's
gonna
work.
This
will
be
a
test
run.
We
have
a
lot
to
go
over
today,
so
I'll
just
jump
into
it.
We
also
have
some
new
people
joining.
So
the
first
thing
is
gonna.
Be
testing
updates.
I
am
not
sure
if
Casey
Ryoichi
or
anyone
else
has
any
testing
updates.
A
Okay
sounds
good,
so
next
we
have
digital
cats,
cause
network
congestion.
So
let's
talk
about
kind
of
why
this
happened
and
some
of
the
proposals
around
making.
It
not
happen
again.
So
the
first
thing
is:
why
did
this
happen
and
what
solutions
are
available?
So
why
did
this
happen?
I?
Think
it's
just
because
there
were
a
lot
of
people
sending
out
transactions
for
crypto
kitties.
What
is
there
anybody
who
wants
to
kind
of
elaborate
as
like
a
overview
of
that
I.
C
Mean
from
a
technical
standpoint,
it's
pretty
simple.
The
yes
limit
was
six
point,
seven
million
and
it
is
turned
out
to
be
an
application
that
had
you
know
what
102
million
yeah
I
guess
for
a
block
worth
of
demand
and
that's
what
you
said
job
usage
is
11
turns.
Actually
it
started
going
up,
then
miners
some
of
the
councilmen
a
bit
and
it
turns
out
they
used
to
just
grown
even
more
and
there
were
any
feelings
on
that
implies
for
basically
fall.
D
A
Okay,
great
the
first
thing,
so
sub-point
B
as
the
first
idea
for
something
that
could
help
with
congestion
as
stateless
clients.
If
you
click
on
B
it'll,
take
you
to
a
comment
someone
made.
Let
me
see
who
made
that
comment
there
who
know
that's
right,
Vitalik,
I
think
you
talked
back
and
forth
with
him
about
that.
Do
you
want
to
kind
of
go
over
that
and
I
guess
if
it
would
work?
You
also
wrote
a
blog
post
on
that
I
believe.
C
C
C
C
Let's
see
here
if
I
can
just
find
this
right
now,
but
like
basically,
it's
like
there's
two
there's
two
things
that
make
well
they're
sleeping
to
make
it
hard.
The
first
thing
is
that
our
patricia
reott
actually,
instead
of
like
from
so
one
of
the
idea,
one
of
the
things
that
I
had
suggested
resize
suggested
in
further.
We
are,
we
research
is
the
possibility
to
access
such
accessed.
Reno
has
been
parallel.
C
C
Only
state
gb
document
rights
to
disk
cold
once
per
block
yeah
right,
so
the
one,
the
one
idea
that
means
like
oh
yeah,
there's
basically
a
few
ideas
in
there.
Some
of
them
involve
hard
work,
some
of
them
don't.
The
idea
that
involve
hard
works
basically
has
to
do
with
sort
of
bumping
of
the
cost
of
storage,
read
and
particularly
bumping
up
the
cost
of
storage
reads
in
those
cases
where
the
they
go
to
cut,
they
go
to
contracts
that
have
really
big
hunks
of
code
v
him
I
so
the
idea
said
don't
require
hard.
C
Forks
probably
have
to
do
well.
The
first
thing
that
we
do
need
to
know
is
like
basically
how
much
what?
What
kind
of
game
can
we
make
from
a
paralyzing
just
breeze?
Because
if
those
games
are
large,
then
there's
a
lot
of
things
we
can
do.
You
know,
including
yeah
g
648,
including
different
kinds
of
witnesses
and
so
forth.
So
that
seems
like
something
that's
really
worth
looking
into.
E
F
Sorry
to
find
the
unmute,
so
would
this
involve
us
issuing?
You
know
if
we
settled
on
one
of
these
options,
that
was
a
hard
fork.
Are
we
talking
about
doing
something
specifically
for
Network
scaling
in
the
shorter
term
in
terms
of
forking,
not
that
we
have
a
plan
to
do
that
right
now,
but
were
we
to
settle
on
that?
Is
that
something
that
we're
talking
about.
C
G
C
H
I
C
A
That's
actually
so
the
next
few
items
are
kind
of
over
that
with
the.
If
there's
you
know,
sequential
disk
bandwidth
problems
and
things
like
that,
so
Before
we
jump
into
that
yeah,
let's
see
if
but
since
the
last
meaning
or
the
last
few
meetings,
if
there's
been
significant
changes
to
like
metallics
and
garbage
collection,
I
know
that
parity
is
switching
from
rocks
DB
to
something
else.
So
if
someone
can
elaborate
on
that
a
few
other
things
so
we'll
start
with
the
we'll
start
with
the
parity
team.
J
I'm
sorry,
my
donut
yeah
parity
is
switching
to
own
custom
database
layer.
It's
called
parity,
DB
and
I
can
not
give
out
any
technical
details
right
now.
It's
on
github.
You
can
look
into
it,
but
I
don't
know
exactly
what's
the
idea
behind,
but
we
are
at
the
limits
of
what
our
rocks
DB
can
do
and
we
try
to
find
you
in
it
over
the
last
six
months,
but
there's
not
much
room
for
improvements,
so
we
have
to
totally
switch
out
the
database
layer.
J
J
J
H
It
does
produce
really
nice
results,
or
at
least
did
produce
a
preliminary
test.
I
think
we
kind
of
need
a
proper
implementation
or
I
can
give
you
other
details,
but
maybe
perhaps
make
hats
more
infos
on
it
other
than
that.
We've
also
looked
at
various
other
databases
out
there.
Now
we
also
way
back,
we
tried
Rocksteady
and
that
one
didn't
produce
any
noticeable
difference
for
us.
We
tried
we
looked
at
norms,
we
looked
at
some
badger,
DB
or
whatever
it's
called
we
did
up
until
now,
we
haven't
found
any,
for
example,
any
database
replacement.
H
That
would
just
automatically
solve
our
problems.
We
do
you
think
about
rolling
our
own
database
a
few
times,
but
we
didn't
find
or
have
the
capacity
to
do
that,
and
we
figure
that
there
are
better
optimizations
to
work
so
I'm,
hoping
that,
because
we
can
get
mix
next
of
bashed-up
eventually
for
the
next
release,
and
let's
see
now
that
folks.
A
So
Peter
Aleksey
on
on
the
agenda
posted
very
recently
that
would
it
be
possible
to
have
some
optimization
improvements.
If
the
background
miner
is
disabled
and
he
said
something
else
about
readwrite
State
and
from
this
key
value
pairs
directly
as
well
as
says,
try
structure
which
will
require
order
of
magnitude.
Fewer
reads:
I'm,
not
sure
what
he
means
by
that,
but
as
far
as
disabling
the
miner,
in
the
background,
would
that
help.
H
C
Think
really
that
meaningful,
like
these
days,
compared
to
what
compared
to
the
head
state
of
a
shame,
especially
centroid,
which
someone
else
and
send
the
transaction
and
totally
possible.
They
like
goal
out
completed
on
the
on
gas
price
or
at
all,
or
that
transaction
or
I
can
eat
you
on
yeah
sprays
like.
H
Personally,
I
don't
think
the
pending
state
is
meaningful
because
it
is
limited
by
a
blocked
number
anyway,
so
it
means
I'm
one
hundred
thousand
transactions
waiting
them.
Basically,
you
get
the
next
100,
which
is
just
a
random
slice
of
the
family
presence
and,
and
the
rest
won't
make
it
entertaining
stick
like
that,
not
that
you
get
any
single
transaction.
Take
you
down
execute.
C
A
G
G
E
L
It's
interesting
track
that
parity
has
moved
from
frogs
DB
to
their
own
database
engine
cuz.
We
are
moving
from
level
db2
rugs
to
B,
so
we
are
on
the
right
way
to
create
our
own
database.
Yes,
okay!
So
we're
almost
done
with
that.
I
need
to
finalize
change,
because
the
main
scenarios
with
the
database
works,
and
we
also
had
to
create
new
pruning
mechanism,
because
old
one
was
based
on
reference
counting
and
we
got
rid
of
reference
counting.
A
L
A
Okay,
great,
let's
see
PI
via.
F
Yeah,
nothing
interesting
for
report
we're
just
churning
away
on
getting
closer
to
a
early
alpha
release,
but
same
standard
work
being
done
just
turned
away
at
it.
Cool.
A
M
A
M
I'm
currently
working
on
changing
and
that
source
format
intern
llamo,
so
we
now
could
support
tests
in
the
llamo
format,
and
in
that
format
we
could
use
a
multi-line
and
to
describe
some
contracts
code,
and
that
would
make
it
easier.
We
could
write
Julia,
for
example,
and
this
this
should
be
awesome.
You
should
look
at
them
if
you're
on
a
test
repository,
so
we
could
discuss
a
new
test
format.
Maybe
you
have
some
thoughts:
how
to
do
it
properly?.
A
M
A
So
looking
here
so
I
think
this
might
have
been
I
guess
tan
generally
discussed
by
everyone.
Updating
their
data
bases,
but
a
sub-item
D
is,
is
actually
sorry.
We
skipped
C
would
having
minimum
system
requirements
to
help
set
up
an
optimal
client
or
full
mode
help.
Who
did
that
one?
Oh
my
cat
just
jumped
on
my
monitor.
It
went
off.
Okay,
it's
back
on
anyways.
A
Where
is
that
yeah?
So
just
it
was
RSA
management
mentioned.
If
there's
like
minimum
system
requirements
to
set
up
an
optimal
client,
node
hard
drive
is
one
of
the
most
important
bottlenecks.
Okay,
that's
actually
gonna
go
into
our
next
item.
So
our
next
item
is:
is
there
a
bottleneck
not
just
on
disk
bandwidth
but
on
sequential
disk
bandwidth
and
I?
Believe
the
taliking
you
commented
on
that?
Was
there
anything
you
wanted
to
add.
C
Yeah,
so
basically,
you
I
was
just
wondering
like
whether
so
we
know,
for
example,
that
an
SSD
re
was
that
an
SSD
can
do
one
SSD
reagent.
You
know
in
about
100
microseconds,
but
in
order
for
an
SSD
to
do
20,
SSD
read
where
we
know
what
all
20
of
the
keys
are
advanced
was
I'd,
say
2,000,
microseconds
or
as
I
think
much
more.
It
does
microseconds,
because
the
answer
that
question
can
vary
significantly
impact
like
what
we'd
end
up
doing
from
a
scalability
standpoint
both
and
there
was
a
coin
implementations
and
for.
A
C
No
I'm
just
asking
RSA
or
random
SS
eries
parallelizable.
So
if
you
have
20
years
that
you
want
for
like
20
locations
that
you
want
to
reaffirm
in
SSD,
then
first
of
all,
can
you
do
that?
Can
you
do
that
in
less
than
20
times
the
time
that
it
would
take
in
order
to
just
the
do
a
thing
over
you
and
then,
if
the
answer
is
no
well,
that
is
that
would
makes
me
sad
and
if
the
answer
is
yes
and
the
folo
obvious
well,
does
that
transcend
these
kind
of
going
up.
C
Siddal
of
the
the
level
of
like
a
level
DB
or
some
other
DB
I'll
call
for
an
answer,
yeah
and
then
and
I
kind
of,
and
then
on
top
of
that
I
know.
I
can't
translate
into
like
either
you
and
multiple
tree
reads
in
parallel,
or
ideally
some
way
to
do
the
different
parts
which
we
read
in
parallel
or
public
somewhere.
H
H
Now
the
question
is,
of
course:
so
if
you
are
reading
and
writing
these
massive
database,
so
is
level
DB
database
and
others.
Usually
they
write
out
entire
blocks
and
I
think
they
can
pretty
much
saturate
bandwidth
pretty
nicely
on
SSDs.
So
in
theory
they
are
fast
in
practice.
It
probably
depends
on
the
load,
but
it's
definitely
worth
investigation.
N
A
Okay,
so
Alexi
just
commented
on
the
agenda.
If
anyone
wants
to
refresh
their
page-
and
he
said
that
he
can
do
experiments
with
parallel
SSD
reads:
if
we,
if
we
want
so
I
said
that'd,
be
great
thanks.
So
thanks
Alexi,
if
you
can
do
those
and
then
comment
on
the
next
agenda,
that
I'll
put
up
today
or
tomorrow,
that
that'd
be
really
cool.
C
H
I
think
we
both
are
the
bottlenecks
and
leveldb
has
this.
So
the
the
design
of
level
DB
is
to
create
a
stable,
stable
stream
of
data,
which
means
that
it
doesn't
give
you
data
back
as
fast
as
it
can,
or
it
doesn't
write
out
data
as
fast
as
it
can.
Rather
it
tries
to
be
stable.
H
So
if
there's
a
static
form,
a
right
cue,
then,
instead
of
writing
the
first
three
items
immediately
in
the
last
three
items,
one
minute
later,
it
tries
to
spread
out
the
writes
and
spread
out
the
weeds
and
throttle
them
so
whatever,
whatever
you
are
benchmarking
these
stuff-
and
you
see
that
there's
a
big
lag
on
reads
or
writes
many
times.
It
may
be
simply
level
to
be
throttling,
because
it's
busy
doing
something
else
or
just
throttling.
A
Okay,
great
the
last
sub
point
for
two
is
vitalik
having
some
ideas
on
gas
cost
changes
and
scalability
relevant
client
optimizations
we've
gone
over
scalability
relevant
client
optimizations
a
bit
Vitalik.
If
you
want
to
go
over
anything
else
from
that
comment,
he
left
the
gas
changes
and
whatnot
I.
C
Mean
I,
don't
think
there
is
anything
beyond
what
said.
What?
Basically,
the
point
is
that
I
still
think
that
state
reads
the
render
price?
That's
what
everything
boils
down
to
any
like
if,
like
service
like,
if
there
were
two
things
that
I
could
do
to
improve
etherium
said
well.
If
there
are
three
things,
I
could
do
to
improve
etherium
scalability
that
are
fairly
quick.
One
of
them
would
be
to
increase
like
further
increase
the
price
of
reads,
because
those
are
probably
still
be
dominant
on
sector.
C
C
648
a
sterilization
and
then
like
if
there
was
a
fourth
thing,
that
would
obviously
be
like
basically
making
reads
even
even
more
expensive
and
improving
the
more
country
and
then
making
sailors
clients
liable.
But
that
would
be
it
and
that's
obviously,
I've
been
a
bit
harder
to
do
backwards,
compatible.
I
No
well
regarding
making
reads
more
expensive.
It
will
be
interesting
to
see
how
that
would
actually
what
the
effect,
what
the
impact
that
would
have
on
the
on
the
last
life
period,
where
it's
been
so
full
transaction
and
if
all
those
transactions
would
have
taken
more
gas
or
if
we
could
have
yeah,
we
would
just
have
spread
out
the
spread
of
the
transaction
onto
more
blocks
and
made
the
situation
worse
over.
The
situation
has
become
better
I.
C
Like
in
general
right,
the
only
the
purpose
of
repricing
operations
is
I
think
more
to
improve
the
worst
case,
and
it
is
to
improve
the
average
case
like
I,
think
there
definitely
are
ways
where
we
can
encourage
developers
to
meet
right,
they're,
smart
from
their
contracts
and
ways
that
are
better
and
we
can
kind
of
improve,
improve
incentivization
better.
But
the
more
important
thing
is
also
like
I
think
like.
We
do
have
to
also
be
proactive
about,
like
thinking
about
the
case
where
there,
where
there.
C
Attack
on
the
network,
well,
I
think
so.
I
think
the
risk
of
an
attack
is
ironically
enough
less
than
it
was
a
year
ago,
mainly
because,
like
at
this
point
in
attacks
that
even
feels
like
a
sort
of
for
gas
usage
was
just
enough.
Driving
transaction
fee
is
up
to
up
to
two
dollars
and
would
burn
through
you
know
millions
a
million
dollars
in
a
few
days,
but
even
still,
it's
worth
being
concerned
about.
A
Okay,
so
last
thought
for
me:
I
think
off
chain
solutions
for
crypto
kitties.
It
was
part
of
the
thing
that
could
help
solve,
at
least
for
them,
specifically
some
of
the
scaling
issues
and
some
of
the
network
congestion
issues.
So
things
like
state
channels,
I've
heard
that
kind
of
being
thrown
around
as
a
solution,
so
I
thought
that
was
interesting.
A
C
Yeah
yeah
I
mean
like
I,
guess,
I've
kind
of
informally
considered
like
each
channel
solutions
out
of
scope
for
the
court
house.
Call
because
they
don't
work,
don't
require
anything
any
a
consensus
solely
or
layer,
Network
layer
changes,
they're
kind
of
separate
networks
that
are
links
to
etherium,
but
like
there.
A
C
That,
actually
is
something
that
I
didn't
want
to
bring
up,
because,
like
there
was
that
each
research
thread,
we
only
have
about
four
or
five
different
proposals
that
I
actually
think
do
a
better
like
substantially
better
job,
the
name
anything
we've
had
before
us
and
a
balancing
between
me
having
as
a
little
complexity
on
out
of
consensus
and
having
as
a
little
income
points
that
he
in
front
of
two
thousand
sort
of
thing.
At
the
same
time,
I
don't
know
how
to
did
you
see
that
research
bread
yet
and
if.
A
A
But
and
yeah
I
think
that
that
would
be
good.
C
C
Listen
of
like
actually
like
ask
people
to
try
hard
to
provide
feedback
on
that
over
I
mean
like
we
sent
the
the
next
few
days
or
so
well
like
it
could
affect
both
the
sharding
roadmap
and
like
it
seems
like
what
like.
If
something
sensible,
get
stopped
at
a
crib
and
it
would.
It
would
make
sense
that
the
mainline
in
the
medium-term,
as
well.
A
Okay,
great,
can
someone
post
this
in
the
zoom
chat,
my
my
get
her
client
crashed,
but
if
someone
could
post
that
link
and
zoom
for
those
who
aren't
in
the
coordinate
chat,
that'd
be
great,
perfect,
Thank,
You,
Martin,
okay,
so
yeah
people
could
go
and
comment
on
that.
That
would
help
a
lot.
The
next
item
is
introducing
the
KA
VM
team
and
Kay
Viper
team.
So
we
have
Everett
Hildebrandt
and
we
have.
A
O
Well,
the
KBM
was
a
well
is
a
formalization
of
the
ethereal
virtual
machine
in
language
that
are
reports
on
which
is
K.
K
is
kind
of
a
operational
semantics
framework
that
ends
up
giving
you
a
bunch
of
software
development
tools
once
you've
specified
your
your
languages,
languages,
definition
and
K.
So
what
we
did
is
just
formalize
the
EDM
following
the
yellow
paper
almost
directly,
and
when
we
were
confused,
we
looked
at
source
code
in
the
various
clients
but
yeah,
and
then
now
we
have.
O
We
have
even
branches
I
think
for
the
Byzantium
update,
although
there's
a
bunch
of
unmerged
branches
in
the
K
repo
right
now,
because
we've
all
been
kind
of
busy
with
school
stuff,
just
end
of
semester,
things
and
and
wrapping
all
that
up,
but
more
recently,
we've
been
looking
into
supporting
some
higher-level
languages.
So
back
over
the
summer,
there
was
kind
of
some
experimental.
O
Prototypes
in
that
direction,
just
extending
the
EDM
with
some
high-level
languages
and
more
recently
de
Jun,
has
been
leading
efforts
on
making
semantics
for
Viper.
Well,
maybe
maybe
not
leading
the
direct
semantics
efforts,
but
he's
certainly
working
a
lot
on
the
semantics
of
Viper,
which
we
originally
gave
semantics
in
terms
of
a
translation
to
EVM.
P
P
Specifically,
we
formalized
actually
the
the
piper
compilation
itself.
So,
roughly
speaking,
if
you
think
about
this,
has
a
translating
its
own
implementation
of
the
viper
compiler
into
some
mathematical
definition
and
inkay,
so,
which
means
that
we
kind
of,
let
me
get
another
compiler,
a
Byford
compiler,
so
that
you
can
cross
check
each
other
to
test
them
as
a
good
side
effect.
Actually,
we
found
some
bugs
in
the
production.
Compiler
also
helped
to
improve
some
design
of
the
language
by
proposing
some
new
features
so
based
on
this.
P
Based
on
these
therefore
more
semantics,
we
are
right
working
on
two
tools.
The
formal
tools,
one
is
the
verifier
for
the
piper
programs
and
another
is
verifier
for
the
viper
compiler
itself.
So
let
me
introduce
a
little
bit
details
about
these
tools,
so
the
first
by
for
I,
mean
program
verifier
or
the
by
programs
is
that
we
actually
have
some
the
core
engine
for
the
verification,
but
we'd
like
to
make
it
more
usable
and
is
used
by
the
contract
developers.
P
So
we
are
thinking
to
provide
some
annotation
language
features
into
the
piper
programs
so
that
the
contract
developers
can
describe
their
intention
of
their
contract
into
their
source
code
and
then
actually
we
can
take
the
source
code
annotation
and
verified
it.
The
properties
are
satisfied
by
the
program
contract
programs.
So
right
now
we
are
using
the
ERC
20
token
implementations
by
Philips
as
a
testbed
for
our
verifier,
but
once
we
have
done
this,
we
are
thinking
to
move
move
on
to
verify.
P
The
Casper
contract,
as
Petaling
proposed
database
program,
verify
your
idea
for
the
verifier
for
the
compiler.
So
we
also
have
inque
a
kind
of
program
deck
inference
checker,
which
means
that
which
takes
two
programs
and
checks
that
they
are
equivalent
or
not.
So
using
this
program,
Givens
checker
actually
can
verify
that
the
piper
programs
and
the
EVM
programs
are
compiled
down
to
from
the
piper.
You
can
verify
two
programs
equal
or
not,
which
means
that
you
can
actually
verify
the
compiler
is
correct
for
each
instance
of
compilation.
P
Another
application
of
me
using
the
program
difference
checker.
Is
that
suppose
you
want
to
migrate
solidity
contract
into
piper.
Then
you
want
to
make
sure
that
actually
by
four
programs
actually
equivalent
with
the
solidity
one.
So
what
we
can
do
is
that
we
take
two
if
program
to
IBM
byte
codes,
we
want
each
generate
from
the
each
language
and
then
it
can
actually
verify
their
EVM
programs
equivalent,
which
means
that
you
correctly
my
created
the
original
solidity
programs.
So
that's
the
compiler
verification
idea
so
yeah.
P
We
are
working
on
these
two
and
then
hoping
to
finish
in
a
short
time,
and
actually
we
released
a
yeah
yeah.
Actually,
a
fillip
posted
the
link
to
that.
So
fill
it
right
down
right
off
the
blog
post
about
this.
While
you've
done-
and
we
are
really
thinking
plenty
so
yeah-
please
check
it
out-
I'll,
try
it
alright.
A
Q
It's
also
worth
noting,
and
let
me
put
a
link
to
this
in
the
in
the
chat,
so
maybe
someone
can
afford
it
the
Skype
channels.
We
also
have
essentially
from
ke
VM
this
compilation,
a
web-based
and
and
human
readable,
hopefully
eventually
documentation
of
the
KVM
semantics.
So
we're
kind
of
calling
this
like
the
jello
paper.
It's
meant
to
be
sort
of
like
the
yellow
paper,
except
that
it
can
be
fully
compiled
into
an
implementation
for
evm
right
now,
it's
like
sort
of
early
stages.
It
was
compiled
directly
from
the
existing
return
to
KVM
semantics.
Q
Your
internet,
everything
anyway,
so
so
yeah.
So
the
idea
is
essentially
to
be
able
to
compile
this
jello
paper
into
a
full
implementation
of
the
EVM
that
could
even
potentially
be
used
in
a
client
one
day.
Unfortunately,
right
now
is
sort
of
compiled
from
the
semantics
that
we've
mainly
been
for
the
trooper
and
for
our
own
tools.
A
Q
Sure
so
I
guess
I'll
get
some
background
on
the
KVM
project,
while
I
do
that.
The
KVM
project
is
split
across
two
entities.
Right
now,
which
is
the
University
of
Illinois,
where
Professor
Gregorio
Shu
is
a
professor
and
has
a
research
lab
that
works
on
formal
semantics
and
also
the
spin-out
startup
run
time.
Verification
Inc,
which
is
intended
to
commercialize
the
technologies
developed
like
before
his
lab,
so
I'm
kind
of
we
having
smart
contract
strategy
@rv,
which
is
like
the
commercial
side
of
the
collaboration
and
I'm.
Also
a
PhD
student
at
Cornell.
A
Okay,
great,
so
the
next
item
is
a
follow-up
to
what
we
talked
about
last
time.
There's
a
link
to
doesn't
remain
the
case
that
the
yellow
paper
is
intended
to
be
a
theorems,
formal
specification
that
was
initially
brought
up
by
Ben
Edgington.
So
we
have
been
Edgington
and
here
today,
as
well
as
Daniel
Ellison
there
from
Pegasus,
which
is
a
consensus,
core
client
team,
so
actually
I'll.
Let
Daniel
and
Ben
introduce
themselves
Daniel
if
you
want
to
go
first
and
then
Ben.
S
Great
thanks,
Ben
hi
everybody.
My
name
is
Ben
Edgington
I'm
I'm
in
the
Pegasus
team
within
concerns,
so
pegasus
means
protocol
engineering
and
systems
we're
relatively
new
team,
but
they're,
focusing
on
core
blockchain
protocols,
research
and
development.
Of
course,
at
the
moment,
it's
fully
focused
on
the
theorem
slight
emphasis
on
private,
if
they're
in
networks,
but
definitely
intention
is
to
span
the
whole
space
and
be
very
active
in
the
public
etherion
space
as
well
so
I'm
in
the
research
and
development
part
of
Texas.
A
Awesome
thanks
Ben,
so
now
back
to
the
topic
about
the
yellow
people
paper
being
the
formal
specification.
Anyone
who's
talked
to
I-
don't
see
Gavin
in
here
today,
but
is
anyone
here
who
was
sent
by
Gavin
to
speak
about
the
yellow
paper
or
who
has
gotten
a
response
together
with
respect
to
the
yellow
paper
comments
from
last
time
or
the
licensing
of
the
yellow
paper.
J
And
he
said,
he's
happy
to
put
the
yellow
paper
repository
under
a
Creative
Commons
license
so
far.
He
didn't
do
it
yet
because
he's
busy
so
he's
currently
considering
which
CC
license
so,
but
if
anyone
wants
to
help
to
figure
out
just
reach
out
to
him,
he
said
he
will
be
able
to
do
it
around
in
around
three
weeks.
So
this
one
out
awesome.
A
That's
a
good
update,
so
basically
Ben
brought
this
up
last
time
and
we
went
through
this.
But
basically
the
questions
are
doesn't
need
to
Rene
in
the
formal
specification
and
if
not,
what
replaces
it
I
kind
of
want
to
throw
in
a
third
option?
Does
there
only
have
to
be
one
as
long
as
they're
compatible
with
each
other
I'm
not
versed,
and
how
these
type
of
formal
specifications
for
this
for
this
stuff
needs
to
go
down,
but
can
anyone
answer
the
question
you
know?
Is
there
a
possibility
of
interoperability
so.
O
Maybe
I
can
say
a
couple
words
about
that.
The
AVM
is
testable
in
executable.
So
if
you
had
another
executable
or
testable
specification,
you
could
check
interoperability
of
those
two
or
you
could
check
agreement
of
those
two
specifications,
but
I
don't
see
a
way
to
mechanically
check.
Conformance
of
the
yellow
paper
with
other
executable
specifications.
O
Certainly,
though,
could
try
to
kind
of
get
a
merge
of
the
two,
because
the
yellow
paper
has
a
lot
of
useful
English,
prose
and
and
other
high-level
overviews
of
the
EVM
that
help
implementers
and
certainly
helped
our
team
to
implement
the
KVM.
So
I
think
what
Philip
was
saying
earlier
makes
a
bit
of
sense
essentially
have
an
executable
specification.
That
also
is
human,
readable.
Q
Yeah
I,
agree
and
I
also
I,
don't
think
it's
necessarily
a
bad
thing
to
have
multiple
specifications,
especially
if
client
developers
are
aware
of
that.
But
you
also
don't
want
to
fragment
efforts
too
much
like
it
is
nice
to
have
a
very
small
number,
so
they
can
all
still
be
audited
and
check
very
thoroughly.
Every
time
they're
updated,
I.
A
Know
at
one
time,
Gavin
had
a
yellow
paper
committee
that
dealt
with
the
responsibility
of
keeping
the
yellow
paper,
updated,
I'm,
not
sure
what
the
status
is
on
that.
Maybe
we
can
talk
to
Gavin
if
he
can
attend
the
next
core,
dev
call
or
just
offline
or
off
call
talk
to
him
about
it,
but
I
think
something
like
that
in
a
collaboration
between
KVM
and
the
yellow
paper
would
be
good
now
for
general
discussion
about
this.
Anybody
have
any
thoughts
on
if
it
should
remain
the
formal,
spec
or
anything
else
about
what
we've
been
discussing.
B
Me
running
public,
so
an
open
license
is
kind
of
vidi-vidi
important.
It's
a
bit
surprising.
The
yellow
paper
hasn't
been
licensed,
so
I
believe
that's
the
first
step
for
first
step
for
the
yellow
paper
side
KVM,
so
I
was
reading
the
master
branch
of
KVM
for
a
while,
and
the
Byzantium
changes
hasn't
hit
the
master
branch.
Yet
so
and
yes,
in
some
cases
the
English
state
paragraphs
very
short,
they
look
like
comments
to
the
code,
so
there
are
death.
Some
work
to
do,
but
JVM
has
already
got
the
license.
A
Q
B
B
Q
E
Yeah,
the
the
other
cool
thing
about
the
ke
BM
is
that
it
actually,
they
said
it
was
an
executable
spec.
Maybe
maybe
it
was
already
mentioned
that
it
actually
runs
in
passes
all
the
state
tests.
Well,
maybe
not
all
of
them,
but
certainly
close
to
being
able
to
pass
them
all
so,
in
the
same
way
that
every
other
client
runs
in
and
passes
those
those
test
cases
the
the
ke
BM
SPECT
can
can
do
that
as
well.
Q
F
A
A
So,
in
summary,
the
yellow
paper
there
needs
to
be
some
changes
over
the
next
month.
Gavin
needs
to
communicate
what
the
license
changes
are,
gonna,
be
and
the
steps
starting
for
that
and
then,
hopefully,
from
there
there
can
be
some
communication
between
KVM
and
the
yellow
paper,
the
maintainer
z'
of
the
yellow
paper,
so
that
there
can
be
some
coordination
going
forward.
It
sounds
like
the
KVM
is
gonna,
be
going
full
steam
ahead,
and
that
sounds
really
cool
as
well,
really
exciting
project
guys,
thanks
for
thanks
for
coming
on
so
I.
Think
thanks.
O
M
J
A
A
A
A
H
A
I
agree:
let's
bring
this
to
the
Skype
and
get
her
channels,
and
then
I
will
announce
it
in
the
agenda
that
I
post
on
there,
but
we'll
definitely
delay
by
at
least
a
week,
if
not
two
weeks,
because
a
week
after
that
is
the
fifth
and
people
will
still
be
kind
of
getting
back
into
the
swing
of
things.
So
we
might
do
two
delays.
Is
anyone
opposed
to
doing
it
to
a
two-week
delay
rather
than
a
one-week
delay?.
D
Well,
I
think
unless
there's
something
very
urgent
or
something
big
happening,
I
don't
expect
that
most
of
the
court,
the
teams
who
be
doing
a
lot
of
hard
a
lot
of
work
in
this
and
the
period
I
think
it's
very
common
for
most
a
lot
of
teams
to
taking
time
some
time
off
and
not
to
some
major
releases.
So
I
don't
think
it
would
be
a
big
problem.
I.
A
A
Let's
just
have
the
next
meeting
on
the
12th
everybody
cool
with
that
I
understand
when
I
ask
a
question
like
that.
If
everyone
speaks
up
at
once,
it's
gonna
be
chaos,
but
I
just
felt
like
a
general,
all
right,
cool
everybody
all
right.
Thanks,
we're
gonna
see
everybody
back
on
the
12th
and
everybody
have
a
good
holiday
depending
on
where
you
are
in
the
world
and
if
you're
celebrating
bye,
everybody.