►
From YouTube: Hyperledger Besu Financial Services Workshop: Roadmap, Contribution & Getting Involved
Description
This was recorded on Day 2 of the Hyperledger Besu Financial Services Workshop
Thanks to Matt Nelson from Consensys for sharing his knowledge with the community. The wiki page (including deck slides) for this event can be found here:
https://wiki.hyperledger.org/pages/viewpage.action?pageId=80779270
Find Out More About Besu
Hyperledger Besu Wiki: https://wiki.hyperledger.org/display/besu
Hyperledger Besu GitHub: https://github.com/hyperledger/besu
Hyerledger Besu Discord: https://discord.gg/hyperledger
Hyperledger Besu “Find Your First Ticket”: https://github.com/hyperledger/besu/contribute/
Hyperledger Besu YouTube Playlist: https://www.youtube.com/playlist?list=PL0MZ85B_96CE3sGM0pdZbwaOb17CKEP
Besu Getting Started
Public Ethereum: Connect to a testnet
Private networks: Developer Quickstart
----
Hyperledger – Open Source Blockchain Technologies
Hyperledger is an open source community focused on developing a suite of stable frameworks, tools and libraries for enterprise-grade blockchain deployments. It serves as a neutral home for various distributed ledger frameworks including Hyperledger Besu, Fabric, Sawtooth, Indy, as well as tools like Hyperledger Avalon, Cactus and libraries like Hyperledger Aries, Ursa.
Learn more about Hyperledger projects:
https://www.hyperledger.org/use
Discord: https://discord.gg/rVCn4j7UFd
Case Studies: https://www.hyperledger.org/learn/case-studies
Training & Certification: https://www.hyperledger.org/learn/training
Tutorials: https://www.hyperledger.org/use/tutorials
Webinars: https://www.hyperledger.org/learn/webinars
Events: https://www.hyperledger.org/events
Vendor Directory: https://www.hyperledger.org/use/vendor-directory
Subscribe to the Hyperledger Newsletter: https://www.hyperledger.org/newsletter
Follow-us on Twitter @Hyperledger
Learn about Hyperledger Membership: https://www.hyperledger.org/about/join
#Hyperledger #Blockchain
License
Creative Commons Attribution license (reuse allowed)
A
A
You
know
the
emerging
strategy,
our
focus
at
least
for
consensus,
so
anything
that
I
say
today
doesn't
necessarily
represent
the
entire
basic
project,
but
it
does
represent
what
consensus
is
focused
on
as
far
as
maintaining
the
project
and
I'd
also,
you
know
like
to
invite
everyone
to
realize
that
anything
that
you
see
in
this
product
update
it
can
become
a
collaborative
process.
Please
work
with
me
to
talk
about
requirements.
What
you
want
to
see
out
of
the
project,
there's
open
governance.
So
it's
not
just
me
and
CSI
dictating
everything.
A
We
want
to
make
sure
that
this
is
an
opportunity
to
learn
more
and
at
the
end
of
the
presentation.
I
will
talk
specifically
about
how
you
can
get
involved
in
contributions.
What
the
process
looks
like
both
on
the
coding
and
governance
side
and
I
also
have
some
suggestions
about
how
we
can
kind
of
open
up
the
product
kind
of
strategy
for
more
groups.
So
I'll
give
a
quick
agenda.
A
Why
are
we
changing?
You
know
the
mission,
and
why
are
we
focusing
on
these
private
networks?
And
why
are
we
kind
of
refining
what
Basu
is
intending
to
do
as
a
client?
So,
with
the
merge,
we
opened
up
kind
of
the
consensus
layer
in
the
execution
layer
of
ethereum
and
separated
concerns
for
these
clients.
So
with
layer,
one
basically
was
focused
on
execution
and
that's
really
around
pulling
in
data
from
the
blockchain
executing
it
within
the
evm
and
returning
results.
A
The
consensus
of
that
data
and
the
visibility
of
that
data
is
handled
kind
of
externally
to
the
client,
at
least
in
a
mainnet
context.
In
a
private
Network
context,
space
suit
handles
all
of
the
components
consensus
as
well,
but
in
these
public
settings
it
is
a
separation
of
concerns
that
I
think
is
going
to
color
the
architecture
of
Basu
going
forward
and
of
ethereum,
and
some
of
these
blockchain
related
networks.
A
But
why
are
we
doing
this
right?
It's
about
in
making
sure
that
we
can
ensure
Network
participation
for
nodes
that
are
running
on
basis?
So
this
means
a
number
of
different
things
right.
It
means
today
that
you
can
operate
Basu
in
a
private
Network
context.
You
can
operate
basically
in
a
side
chain
context.
A
We
have
Java
familiar
programming,
language
and
you
know
a
client
you're
all
familiar
with
right
and
now
it's
about
kind
of
translating
a
lot
of
this
to
becoming
the
best
and
most
flexible
infrastructure
for
institutions
looking
to
participate
and
build
blockchain
networks.
That's
kind
of
refining
our
mission
here
into
this
road
map
that
many
of
you
probably
haven't
seen,
although
it
has
been
on
the
wiki
for
quite
some
time
with
the
nature
of
ethereum
clients,
I
tend
not
to
commit
to
more
than
two
quarters
at
a
time
given
our
shifting
priorities.
A
A
So
I've
been
touching
on
this
for
the
last
couple
of
days,
but
we
have
a
ton
of
performance
related
improvements
that
we
put
into
the
23
1
series,
alongside
a
host
of
stability
and
correctness,
improvements,
refactoring
portions
of
the
code,
retooling
RPC
to
be
in
line
with
more
with
other
clients
like
Geth,
so
we
have
very
consistent
results
across
clients
and
just
working
on
performance
performance
performance.
So
really
this
one
was
kind
of
spurned
by
that
post
merge.
A
You
know
adoption
of
Basu
we
went
from
around
one
percent
of
network
nodes
to
around
10
and
settled
around
eight
or
nine
percent.
So
we've
had
a
lot
of
new
users
and
an
influx
of
folks
work
is
working
on
mainnet
expose
the
number
of
Performance
challenges,
so
we've
taken
that
feedback.
We
focused
this
quarter
on
improving
that
performance
as
well
as
building
the
features
that
we
need
to
be
compatible
with
Shanghai
and
making
sure
that
Basu
can
continually
go
through
the
transition
without
issue.
A
A
I
mentioned
earlier,
where
the
execution
clients
are
focused
on
things
kind
of
around
evm
execution
and
other
components,
and
basically
Outsourcing
that
consensus
layer
functionality
and
it's
the
same
with
the
rollout,
essentially
we're
Outsourcing
consensus
to
this
other
layer,
we're
keeping
some
of
the
components
of
execution
and
we
are
retooling
baser
to
be
really
suited
for
that
format.
So,
in
Q3
we're
looking
to
deliver
things
around
optimistic
Basu
packages,
zero
knowledge,
basically
roll-up
packages.
A
What
this
really
means
is
client
diversity
on
the
roll-up
player.
So,
if
you're,
using
optimistic
Basu,
if
you're
using
optimism,
for
example,
having
the
code
base
be
compatible
with
that
so
they're
not
just
using
a
fork
of
death,
they're
using
multiple
clients,
creating
more
robustness
and
more
opportunity
on
Layer
Two,
but
also
creating
kind
of
a
familiarity
and
a
migration
path
for
networks
that
are
exploring
l2s
and
roll-ups,
also
looking
to
Target
more
kind
of
neatly
packaged
main
Nets
clients.
A
We
haven't
really
had
time
to
kind
of
go
back
and
evaluate
this
format.
That
used
to
be
a
lot
simpler
because
there
was
only
a
handful
of
schedules.
There
are
now
a
lot
of
weird
quirks,
especially
post,
merge
that
we're
looking
to
kind
of
clean
up-
and
my
hope
is
that
this
will
also
bring
the
kind
of
ability
for
us
to
become
compatible
with
more
chains
on
more
formats
in
layer
one.
So
if
you've
heard
of
change
like
gnosis
chain
and
others,
you
know
polygons
some
of
these
other
things.
B
B
A
We're
also
looking
to
provide
more
tools
and
specific
features
for
infrastructure
providers,
really
that's
around
packaging
improvements,
potentially
upgrading
some
of
the
existing
stuff
that
we
already
have
potentially
migration
scripts
for
certain
kinds
of
chains
to
move
their
data
around,
and
you
know,
one
of
our
final
focuses
is
making
Basu
an
ethereum
reference
client,
and
what
that
means
is
that
you
know
we
have
things
like
the
ethereum
yellow
paper.
We
have
all
these
eips,
making
sure
that
bases.
A
A
You
kind
of
wait
till
those
things
boil
down
in
the
ethereum
research
space,
but
there's
a
ton
of
open
topics
that
we're
looking
to
get
at
so
I'm
going
to
pause
here,
because
I'm
sure
we
have
questions
in
chat
and
in
the
room
and
as
I
mentioned,
I'll
explain
kind
of
the.
Why
of
this
roadmap?
And
then
we
can
return
to
this
slide
in
the
next
handful
of
slides,
but
I'll
go
there
first.
A
A
Tension
at
all,
we
know
you're
building
these
networks,
and
you
need
to
continue
to
be
able
to
operate
these
networks.
Consensus
will
just
not
be
building
essentially
new
features
in
this
capacity,
however,
we
are
looking
to
onboard
contributors.
We
have
web3
Labs
Connor
spoke
yesterday
about
how
they'll
be
getting
involved
in
handling
a
lot
of
these
specific
feature,
requests
and
bug
requests,
so
we
still
maintain
critical
bugs
that
are
found
on
the
private
Network
side
depending
on
the
severity.
A
A
Up
to
speed
on
what
it
means
to
propose
new
private
features
to
maintain
those
features,
whether
it's
using
the
plugin
API
or
the
actual
code
base.
So
the
short
answer
is
no
we're
not
deprecating
any
like
we
don't
plan
to
deprecate
any
of
those
new
features.
It's
also
an
open
source
project.
If
you
wish
to
maintain
them,
you
may
just
as
well,
but
consensus
is
focused
on
these
items
and
public
networks.
At
this
time,
the.
A
So
I
think
in
the
Enterprise
context.
The
the
word
that
we
like
to
use
is
a
single
sequencer
roll
up
where
there's
essentially
one
operator
that
sees
the
majority
and
or
all
of
the
details
and
the
proving
is
happening
kind
of
on
the
ladder
after
that.
So
you
don't
necessarily
need
to
apply
that
kind
of
privacy
protection.
The.
A
What
I'm
describing
in
this
roadmap
here
is
for
public
facing
ZK
Roll-Ups,
so
where
they
will
need
to
split
and
basically
privatize
the
account
State
and
prove
it
within
the
infrastructure,
but
not
necessarily
at
the
individual
user
level.
I
have
a
specific
slide
that
goes
through
what
that
privacy
means
later
on,
but
to
your
answer,
both
flavors
are
kind
of
possible,
so
there's
the
single
single
sequence
of
Roll-Ups
might
become
more.
A
A
C
A
Yeah,
so
the
question
was
around
account:
abstraction
standards,
specifically
EIP,
slash,
erc4337
and
how
it
pertains
to
Basu.
So
as
far
as
basically
was
concerned,
since
it
is
an
ERC
which
is
a
set
of
smart
contract
standards,
there
are
actually
no
protocol
level
changes.
What
we
will
have
to
implement,
however,
is
rpcs
that
enable
us
to
interface
better
with
these
bundlers
and
with
the
smart
contract
wallet
ecosystem
that
will
be
created.
We
do
plan
on
supporting
that
as
soon
as
possible.
A
However,
the
RPC
standards
are
being
developed
literally
as
we
speak
and
they're
not
ready
yet,
but
we
will
be
building
them
into
Basu
and
they
will
be
aligned
with
the
L2
ecosystem,
so
we're
in
contact
with
optimism
arbitrum.
You
know,
ZK,
sync,
all
these
other
folks,
the
networks
that
have
implemented
a
kind
of
extraction
we've
all
kind
of
gotten
together
and
discussed.
What
this
looks
like
and
the
output
will
be
a
set
of
rpcs
that
we
will
be
implementing
in
ASU.
A
Yeah,
so
we
are
still
taking
some
inbound
requests
for
things
like
fixes
for
to
Sarah.
Our
plan
is
again
to
kind
of
offboard
that
to
other
organizations,
including
what
three
Labs
consensus
again
are
are
stated
approaches
that
we
will
not
be
deprecating
these
features,
but
we
are
actively
looking
to
have
other
contributors,
maintain
them
and
build
them
out
with
additional
components.
A
A
Yeah,
that
really
depends.
The
question
was:
what
is
the
target
TPS
and
finality
of
Roll-Ups?
So
it
depends
on
whether
using
an
optimistic,
roll-up
or
a
ZK,
roll-up
or
a
proof
of
authority
roll
up
the
TPS
number.
It
honestly
depends
on
how
many
sequencers
and
nodes
you
have.
You
can
kind
of
just
keep
layering
them
on
top
of
each
other
in
theory
for
infinite
scale.
A
Finality
is
totally
driven
by
what
type
of
roll-up
you're
using
an
optimistic
roll-up
typically
has
a
finality
time
of
a
handful
of
minutes,
but
there's
also
a
week
two
week
long
challenge
period
where
you
can
essentially
be
try
to
prove
fraud
in
the
network
or
prove
that
there
is
specific
kinds
of
activity
going
on
and
they
use
game
theoretical
incentives
to
incentivize
those
I,
don't
think
optimistic.
Rollups
will
see
much
use
in
an
Enterprise
context
in
terms
of
internal
use
cases,
but
I
do
when
I
get
to
kind
of
the
layer.
A
Three
app
chains,
discussion
portion
of
this
I
think
that
we
will
potentially
see
things
built
on
top
of
those
roll
ups.
If
you
think
of
coinbase
bass,
the
role-up
that
they
just
announced,
that's
built
on
the
op
stack,
which
will
take
advantage
of
optimism's
fraud,
proofs
and
optimisms
basically
token
incentives
to
secure
their
Network,
which
is
secured
on
top
of
ethereum.
But
in
the
Enterprise
context
the
scale
I
think
you
know
it
again.
It
depends
on
the
deployment.
A
A
A
There's
a
lot
of
interest
around
public
networks
in
the
news,
not
necessarily
ethereum
mainnet,
but
with
chains
like
polygon,
some
ethereum,
mainnet
stuff,
as
well
as
hyper
chains
using
Basu
for
cbdc
building
on
the
standards
and
using
things
like
fridges
to
deploy
back
to
mainnet
but
I.
As
was
touched
on
yesterday.
There's
a
ton
of
stuff
in
the
news.
I!
Don't
need
to
bore
you
with
the
links,
but
Basu
is
a
complete,
mainnet,
client.
A
I
know
some
of
you
are
using
Basu
for
mainnet
today,
but
as
I
mentioned,
we
have
around
seven
and
a
half
flux
rate
between
seven
and
a
half
to
ten
percent
of
network
share
at
any
given
time.
There
are
four
main
clients
in
the
landscape
for
ethereum
execution,
layer,
clients
and
basically,
these
execution
layer.
Clients
have
really
strong
voices
around
what
happens
within
the
ethereum
protocol,
whether
that's
changes
to
the
evm,
whether
that's
changes
to
the
format
of
certain
transaction
types
and
things
all
of
this
stuff.
A
That
trickles
down
to
private
networks
starts
with
these
four
teams
for
the
most
part,
plus
ethereum
researchers
and
others.
However,
it
is
an
open
and
collaborative
process.
These
are
kind
of
the
primary
funnel
for
these
changes,
but
they're,
not
the
only
conduit
and
I'll
talk
a
lot
about
core
development
later,
but
we
are
one
of
those
four
clients
and
that
gives
this
group
of
people
a
voice
to
influence
ethereum
mainnet
in
a
number
of
ways
we
participate
in
steer.
A
Network
upgrades
on
ethereum
and
mainnet
we've
been
historically
used
for
private
networks
from
basically,
but
we
went
from
around
one
percent
Network
share
to
again
around
like
eight
to
ten
percent
and
because
that's
all
because
of
the
Bonsai
storage
format,
it's
our
big
differentiator.
It
makes
a
mainnet
node,
two-thirds,
the
size
of
any
other
client
in
many
instances,
which
is
very
valuable
for
people
who
are
running
on
Hardware
that
costs
a
lot
of
money
or
are
running
a
Hardware
validator
in
their
garage
and
need
load
requirements.
A
Not
many
other
clients
were
built
with
this
kind
of
Enterprise
focus
in
mind
or
any
of
the
private
Network
features.
The
only
other
client
that
implements
click
are
Geth
sort
of
and
they're
dropping
support
and
never
mind.
So
if
you
want
to
use
private
Network
consensus,
you're,
basically
using
Basu,
but
again
that
means
that
we
were
built
from
the
ground
up
with
these
features
in
mind
and
a
lot
of
the
stuff
around
infrastructure.
Support
that
we
have
built
in
is
kind
of
born
out
of
that
process.
A
Some
more
information
here
on
the
right
hand,
side.
You
know
this
is
a
breakdown
of
all
the
nodes
in
the
the
world
in
the
public,
so
around
half
of
the
ethereum
nodes
on
mainnet
are
run
out
of
the
United
States.
Typically,
those
are
run
in
data
centers.
If
you
look
at
this
down
here,
66.5
of
nodes
are
hosted.
A
That's
not
necessarily
great,
it's
not
the
end
of
the
world,
but
the
good
number
is
that
33
of
the
nodes
around
a
third
of
the
network
is
run
by
this
residential
internet
providers,
which
means
people's
taking
from
home.
This
is
great
for
the
decentralization
of
the
network,
because
you
don't
want,
in
theory,
Amazon
or
Google
to
be
able
to
shut
off
access
to
those
things.
But
again
the
United,
States
and
Europe
predominantly
are
the
major
folks
hosting
nodes
in
the
ethereum
network,
with
some
Asian
representation
as
well.
A
That's
a
good
question.
I
know
Peter,
put
in
a
pull
request
on
the
guest
repo
to
delete
all
the
click
code.
I,
don't
know
if
that
PR
has
been
merged,
but
so
just
for
the
for
some
elucidation,
gef
invented
Click
consensus
as
a
mechanism
to
tests
local
networks
and
to
deploy
kind
of
sort
of
enterprise-local
networks.
But
Geth
is
on
a
complete
Killing
Spree
with
dropping
features
things
like
fastsync
and
some
of
their
older
storage
formats
and
potentially
even
the
archive
node.
A
So
again,
people
build
on
Bay
suit
because
we
support
ethereum
standards
as
well
as
private
networks,
and
that
was
not
done
in
a
vacuum.
That
was
a
very
deliberate
decision
to
support
both
hybrid
use
cases
and
kind
of
the
evolution
of
private
use
cases
to
public
over
time.
So
a
lot
of
you
have
heard
about
the
Palm
Network.
A
They
take
advantage
of
ibft2
poi
consensus
to
have
gas,
basically
free
network.
Initially
the
draw
was
to
have
carbon
reduction
versus
main
net
before
the
merge.
Their
kind
of
selling
point
was
that
they
can
have
very
fast
transaction
speed,
low
cost,
fermenting
nfts
and
no
carbon
footprint
versus
the
very
wasteful
proof
of
work.
A
If
you
look
at
this
kind
of
right
hand,
side
here,
the
Palm
Network
part
on
the
bottom.
That's
the
really
interesting
thing:
that's
just
a
typical
ibft2
Network
that
has
only
a
handful
of
components
that
make
it
work
with
mainnet.
They
have
a
very
you
know.
They
have
a
bridge
of
a
layer
and
then
integration
points
of
off-chain
storage.
A
But
in
reality
that
the
the
magic
happens
at
that
bridge
layer-
and
it
you
know-
works
with
the
kind
of
scalable
basic
Network
in
a
way
that
allows
users
to
purchase
and
sell
nfts
on
both
mainnet
and
the
Palm
Network.
The
reason
being
is
that
they
don't
Implement
a
custom
nft
standard.
They
support,
of
course,
erc721
and
deploy
kind
of
these
like
side
chain
nfts.
That
can
then
be
spot
sold
and
moved
if
need
be
to
wherever
they'd
like
to
go.
A
So
you
know
I
I,
like
the
Palm
example,
because
they're
plan
longer
term
potentially
is
to
migrate
to
this
kind
of
public
infrastructure,
but
it
shows
that
Evolution
right
we
have
an
ibft2
Network
that
becomes
a
side
chain
via
a
bridge
which
could
in
theory
be
migrated
to
public
infrastructure
on
L2
or
L3
with
a
similar
process.
But
none
of
the
kind
of
architecture
underlying
it
has
to
change
too
much.
The
infrastructure
can
stay
the
same.
A
The
Basu
nodes
can
stay
the
same,
and
ideally,
if
we
get
to
that
kind
of
vision
that
I'm
laying
at
around
layer,
twos
and
Roll-Ups,
they
wouldn't
have
to
change
that
that
infrastructure
Point
as
well
right.
They
would
be
running
approvers
within
those
networks
or
potentially
just
getting
rid
of
infrastructure
altogether
and
deploying
their
smart
contracts
on
Layer
Two
and
taking
advantage
of
publicly
available
Bridges.
A
Honestly,
I
don't
really
like
this
slide,
but
what
does
ethereum
participation
mean
for
Enterprise
on
public
networks?
You
can
get
paid.
You
can
stake
Keith
and
start
playing
around
with
public
network
endpoints
and
running
nodes
and
get
returns
of
varying
perspectives.
We
think
that
the
rewards
are
the
rewards
hover
from
anywhere
between
six
to
ten
percent,
depending
on
Mev
and
other
things
not
really
important
to
work
about.
But
at
this
point
I
think
the
proof
of
sake
ethereum.
You
know
it's
shown
that
it's
sustainable
with
all
these
changes.
A
We're
making
it's
very
scalable
in
the
future
I
would
say:
give
that
one
six
to
12
months
before
I
kind
of
put
a
stamp
on
it
and
say:
okay,
ethereum
has
scaled
and
again
you're
already
building
these
applications
that
are
running
on
private
networks.
Once
we
can
get
over
the
regulatory
hurdles,
the
network
will
be
ready.
A
Okay,
the
bulk
of
what
I'm
going
to
talk
about
is
this
kind
of
layer,
2
ecosystem,
but
honestly,
once
I
get
to
the
end,
we
can
talk
about
pretty
much.
Anything
you'd
like
to
I
only
prepared
slides
for
half
of
the
time,
so
institutions
in
D5
need
more
than
layer.
One
throughput
and
privacy
are
the
big
ones
for
layer,
twos,
throughput,
meaning
scale.
A
However,
we
need
more
than
that,
often
enough
for
institutions,
auditability
and
privacy.
You
know
that
there's
some
uniqueness
of
layer,
one
that
allows
you
to
try
to
handle
both
with
things
like
tisera
and
things
like
these
private
Network
transactions.
A
lot
of
the
layer
twos
get
that
stuff
for
free
based
on
the
technology
that
they're
using
whether
it's
zero
knowledge,
proofs
or
semi-private
kind
of
transfers
it.
It
really
depends.
A
Compatibility
with
layer,
1,
smart
contracts,
composable
platforms,
all
the
good
stuff
token
transfers
are
expensive,
they're,
not
private
and
there's
often
not
compatibility
with
the
ecosystem.
If
you
take
advantage
of
privacy
features
on
layer
one.
So
if
you're
using
to
Sarah
in
a
private
Network,
you
may
not
be
able
to
support
those
assets
in
a
way
that
makes
sense
to
where
they
need
to
go
if
you're
interfacing
back
with
public
networks.
A
So
how
do
we
kind
of
get
all
these
different
components
into
one
network
and
the
answer
is
kind
of
layer,
two
solutions
right:
we
have
a
variety
of
different
solutions
here.
We
are
not
just
looking
at
kind
of
Roll-Ups
to
scale
ethereum,
there's
also
evm
side
chains
and
data
availability,
sampling
improvements,
all
formerly
known
as
sharding
that
we
you
know
are-
are
looking
at
as
the
official
scaling
roadmap
of
ethereum
layer
one.
A
So
what
is
a
roll
up
here?
I
know
this
is
potentially
self-explanatory
for
some
folks
in
the
room,
but
at
the
same
time,
roll
up
or
if
you've
heard
Layer
Two
is
a
another
Network
that
takes
advantage
of
the
security
of
the
underlying
layer.
One
in
this
case,
ethereum
mainnet
in
many
cases,
ethereum
mainnet
to
batch
execution
off
chain
and
then
post
the
results
of
that
execution
onto
a
secure
layer,
one
where
it
can
be
true,
retrieved
later
for
proving
fraud
purposes
and
for
verification
purposes.
A
So
in
reality,
if
you
think
that
I
have
you
know
a
throughput,
that's
limited
on
layer,
one
in
terms
of
security
in
terms
of
what
I
need
to
store
on
the
blockchain
in
terms
of
the
budget
to
secure
that
Network,
which
I
think
at
this
point,
there's
600
000,
validators
ish
times
32
eth
is
a
lot
of
money.
Securing
that
layer,
one
it's
a
lot
harder
to
kind
of
build
that
security
budget
in
elsewhere.
A
But
in
this
case,
let's
presume
that
we're
talking
about
ethereum
base
layer,
one
which
is
frankly,
you
know
a
100
uptime
network
with
an
insanely
high
amount
of
money
required
to
attack
it
at
any
given
second,
so
you
have
the
base
settlement
layer,
the
most
decentralized
and
resilient
Network,
and
then,
as
you
go
up
in
the
layers,
you
start
to
centralize
a
little
bit
more
and
make
trade-offs
in
terms
of
centralization
that
you
gain
back
in
terms
of
scale.
So
speed
of
execution.
A
If
I
make
assumptions
about
the
centralization
of
what
I'm
executing
batching
together
in
my
transactions,
I
can
take
the
security
concerns
out
of
that
centralization
and
take
advantage
of
layer
one
to
bring
it
back
into
play.
Does
that
make
sense?
I
just
want
to
make
sure
that
I'm
not
confusing
folks,
so
yeah
yep.
A
A
So
they
yeah
you
defer
to
the
Roll-Ups
consensus,
which
is
basically
just
I,
choose
how
to
sequence
transactions
and
I.
Do
it
in
many
cases
we're
moving
towards
a
world
of
kind
of
multi-prover
multi?
You
know
decentralized,
Roll-Ups,
that
talk
to
each
other,
but
in
reality
those
consensus
mechanisms
still
are
based
on
kind
of
the
ethereum
layer.
One
chain
securing
upwards
to
avoid
that
centralization
problem,
where
the
users
are
challenging
the
fraud
proofs
or,
where
they're
using
zero
knowledge
proofs
to
ensure
that
the
ordering
of
transactions
and
the
inputs
and
outputs
are
correct.
C
A
It
can
yeah
so
it
online
so
that
the
way
that
this
kind
of
actual
movement
between
layer,
one
and
Layer
Two
happens,
is
via
Smart
contracts
on
layer,
one
so
to
Alton's
point.
There
are
contracts
on
layer,
one
that
manage
the
funds
that
are
existing
in
its
entirety
on
Layer
Two,
but
they're,
making
sure
that
they're
secured
via
that
layer,
one
settlement
layer
as
I
mentioned,
so
when
users
deposit
funds
into
the
layer,
one
smart
contract,
they
appear
on
the
layer
two
as
this
user's
fonts.
A
So
these
contracts
are
often
enormous
in
complexity
and
size
and
they
manage
funds
across
those
two
layers
and
they
allow
you
to
basically
debit
and
credit
specific
addresses,
specific
accounts.
But
the
execution
of
what's
happening
in
those
smart
contracts
on
Layer
Two
is
not
captured
in
the
layer.
One
smart
contract,
only
the
kind
of
state,
as
it
says
like
as
it
comes
out,
does
that
make
sense.
A
So
as
the
merge
created
that
separation
of
concerns,
like
I,
said
with
the
execution,
client
and
the
consensus
client,
what
we
use
to
take
advantage
of
the
Roll-Ups
consensus
is
this
engine
API,
which
sits
in
the
middle,
so
Basu
is
now
set
up
to
have
consensus
driven
entirely
externally.
As
far
as
the
mainnet
or
public
network
context,
which
means
Basu,
is
handed
down
from
on
high
what
Fork
it
should
follow,
what
blocks
should
be
produced?
A
Right
next
to
it,
but
you
would
have
a
separate
process
from
layer.
One
I
don't
know
how
it's
going
to
shake
out.
We
don't
intend
to
have
them
on
the
same
machine
purely
because
the
requirements
of
Roll-Ups
from
an
execution
perspective
are
often
encompassing
of
the
resources
of
the
machine,
but
I'd
love
to
get
to
a
point
where
you
can
basically
kind
of
toggle.
A
These
behaviors
or
in
theory,
have
managed
state
in
multiple
components,
which
means
Basu
can
talk
to
them
at
the
same
time,
I'm
not
necessarily
convinced
that
Java
will
be
performant
enough
to
do
some
of
those
things
without
being
costly,
but
we
like
we're
thinking
these
through
actively
right
now.
These
questions.
C
D
A
So
that's
an
even
waiter
example
where
Bay
suit
becomes
essentially
even
less
of
this
execution
client
box
than
it
is
in
this
picture,
but
there's
so
many
different
formats
for
this
that
what
I'm
trying
to
get
to
is,
where
you
know
we're
using
kind
of
a
module
architecture
to
be
able
to
pick
and
choose
which
building
blocks.
We
want
to
serve
that
use
case
in
a
way
that's
efficient
and
doesn't
it
has
maximum
reuse
of
components?
A
C
A
So
now
yeah
so
we're
building
that
as
part
of
our
roadmap
from
Q2
in
Q2
and
Q3.
So
our
hope
is
that
eventually
you
can
pick
and
choose
nodes
on
multiple
layer.
Twos,
like
you
did
today
on
layer,
one
so
you
say,
oh
I
could
run
get
nethermind
or
basic
or
whatever
on
Layer
Two.
We
want
that
to
be
on.
You
know,
I'm
running
on
optimism.
I
want
to
be
able
to
run
Geth
or
bassu,
but
as
it
stands
right
now
we're
doing
that
work
today.
A
So
we
got
to
build
components
around
things
like
the
sequencer.
You
know,
like
I
mentioned
the
RPC
tracing
some
of
the
proving
components
we're
building
that
all
into
the
client
and
making
it
kind
of
accessible.
But
it's
going
to
take
time
to
make
sure
that
we
can
do
that
in
a
generalizable
way,
because
right
now
it's
very
much
tailored
built
to
certain
use
cases,
and
we
want
input
on
kind
of
what
this
looks
like,
but
the
reason
I'm
going
to
skip
this
Slide
the
reason
we're
doing
all
this
is
yeah.
A
So
we're
building
some
of
the
components
of
Basu
into
the
ZK
AVM.
The
plan
is
to
roll
back
that
work
into
the
main
code
base,
but
for
now
it's
more
of
a
we're
kind
of
building
it
as
a
MVP
internally
for
it
to
support
this
network,
but
again
over
the
next
couple
of
quarters.
My
goal
is
to
roll
back
as
much
of
that
functionality
as
we
can
into
the
mainline
client
in
a
way
that
is
generalizable
to
roll-ups,
multiple
types:
multiple
environments.
What
have
you?
A
A
No
one
else
can
see
what
I'm
doing
I
don't
care
all
I'm
going
to
do
is
post
outputs
of
what
I'm
doing
on
chain
to
ensure
that
the
data
and
the
state
are
consistent
and
that
as
I
go
forward
and
transact
and
do
things
that
data
trickles
down
and
I
don't
have
to
worry
about
securing
it
with
my
base,
2l1
because
it's
being
secured
by
mainenet
and
the
data
is
completely
opaque
to
anyone.
That's
looking
at
gross
oversimplification
there,
but
the
you
know
the
roll-up
of
Roll-Ups
kind
of
chain
world
is
absolutely
coming.
A
You
know
here
we
have
three
examples:
scroll
consensus,
roll
up
and
polygon.
We
are
already
in
talks
with
those
networks
to
basically
create
this
multi-prover
environment,
where
these
Roll-Ups
can
talk
to
each
other
move
funds
very
simply,
and
they
all
inherit
the
kind
of
security
architecture
of
ethereum
layer
one.
So
this
kind
of
big
second
circle
is
that
layer,
two
environment-
and
these
are
all
the
individual
kind
of
like
L3
if
you've
heard
the
term
app
chain
or
L3
they're
kind
of
synonymous.
A
These
are
essentially
you
know
what
you're
building
today
already
with
these
Basu
private
networks
strip
out
some
of
the
components
like
to
Sarah
add
in
some
functionality
around
privacy-
and
you
know,
data
availability
and
you
have
that
kind
of
L3
world,
so
I
know
that's
going
to
spur
in
some
questions.
Let's
Dive
In.
A
Thank
you.
So
the
question
was:
if
we
add
more
layers,
do
we
lose
composability?
The
answer
is
no,
because
all
of
these
are
being
built
around
the
evm,
so
the
standards
don't
change
as
you
go
up
and
down
the
layers.
In
fact,
it
becomes
relatively
more
and
more
composable,
because
when
you
go
to
something
like
an
L3
I,
don't
have
to
worry
about
the
infrastructure.
That's
built
on
the
L2
I
can
customize
what
I'm
building
essentially
to
fit
my
model
of
the
worlds
and
all
I
care
about.
A
A
Only
if
you're
going
from
L3
to
L3-
so
that's
not
typically
the
example.
You
would
need
something
like
a
bridge.
However,
you
could
go
down
to
L2
and
go
up
to
another
L3
in
this
kind
of
multi-prover
environment.
The
goal
is
to
avoid
Bridges
as
much
as
possible.
These
bridges
are
bad
they're,
very
prone
to
hacks
they're,
big
honey
pots,
but
in
this
scenario
with
a
roll-up,
you
can
kind
of
move
the
state
in
a
sort
of
different
way
and
go
down
and
back
up
as
needed.
A
In
reality,
all
the
state
ends
up
here
in
a
much
much
compressed
format
and
then,
as
you
go
up
the
layers,
the
state
separates
into
its
individual
components,
but
it
can
be
private
and
it
can
you
know
you
can
do
these
kind
of
like
big
transfers
of
tokens,
and
you
can
have
the
data
availability
that
you
need.
You
could
even
include
off-chain
things
in
your
app
chain,
the
other
parts
of
the
network,
don't
necessarily
care.
If
you
BS
yourself
on
your
app
chain,
they
only
care
that
the
security
is
inherited
up
and
down.
A
Does
that
make
sense,
so
I
can
have
garbage
in
garbage
out
problems
on
layer
three
and
still
put
garbage
there,
but
no
one
really
cares,
because
it
doesn't
just
that
my
garbage
is
being
secured
by
these
other
layers.
Economic
incentives
I,
don't
like
to
use
that
term
garbage.
But
it's
basically
true
right.
A
A
A
Economic
incentives
to
secure
what
you're
doing,
and
you
have
to
trust
that
ethereum
has
strong
enough
economic
incentives
to
prove
what
the
L2
is
doing.
So
these
ones
are
pretty
much
born
out
where,
like
I
mentioned,
it
costs
like
billions
millions
of
dollars
per
minute
to
attack
ethereum.
You
have
600
000
nodes
that
you
need
to
collude
with
a
good
portion
of
them.
A
There's
strong
robustness
here
this
one
is
a
little
bit
more
dubious
at
the
point.
The
point
in
time
of
right
now
there
are
a
lot
of.
If
you
go
on
to
I,
think
it's
l2b.
They
describe
the
different
fraud
proofs
and
risk
profiles
of
each
of
the
l2s
right
now.
Arbitrum
is
the
closest
to
the
most
robust,
but
there's
a
ton
of
details
there
explaining
what
are
the
trade-offs
that
are
being
made
right
now?
What
are
those
organizations
doing
about
the
trade-offs
meaning?
A
How
are
we
getting
to
full
fraud
proofs
to
full,
like
composability,
all
that
good
stuff,
like
it
they're
they're,
being
developed,
I'm,
not
implying
that
you
should
go
out
and
throw
away
everything
you've
done
on
an
L1
or
on
a
base?
2
Network
and
just
go
here
but
I'm
saying
this
is
the
direction
of
travel
for
both
the
client
that
we're
building
and
using
and
for
the
network
as
a
whole.
The
network
of
networks
as
a
whole.
A
Side
yeah,
so
the
question
was:
can
I
explain,
kind
of
the
personas
and
the
Enterprise
use
case
around
why
we
would
separate
out
these
layers
and
why
users
would
use
this
type
of
scenario.
So
it's
a
great
question.
I
think
that
what
we
see
is
the
proliferation
of
kind
of
communities
or
like
business
environments,
where,
if
I'm
a
person,
that's
playing
a
certain
video
game
and
they
have
like
an
in-game
economy,
I'm
on
a
layer,
three
I'm
on
an
app
chain
because
I'm
working
specifically
within
that
game.
A
It
could
be
that
I
have
kind
of
an
intranet
which
does
you
know,
transactions
and
settlements
within
my
own
kind
of
bank
and
I
have
another
bank
that's
running
on
the
same
kind
of
L2,
multi-prover
environment.
They
have
their
app
chain
L3.
That
does
their
internal
processes.
What
have
you
if
we
need
to
transact?
We
don't
necessarily
have
to
stay
in
our
L3
world,
because
we're
being
you
know
secured
on
this.
A
So
we
can
transact
here
without
again
having
to
Bridge
and
having
to
worry
about
the
security
guarantees,
because
my
assets
are
already
secured
by
this
bucket.
So
it
allows
for
these
kinds
of
like
big
kind
of
movements
of
assets,
the
big
kind
of
connection
tissue
without
having
that
bridge
conundrum
and
problems,
and
it
allows
us
to
also
say
okay
today,
I
want
a
new,
L3
and
I.
Don't
have
to
worry
about.
You
know
the
kind
of
standing
up
of
all
that
security
infrastructure,
I'm,
spinning
up
an
app
purpose
chain.
A
That's
why
they're
called
app
chains
I'm
trying
to
do
a
new
Financial
instrument,
I'm
trying
to
provide
you
know
instead
of
Trades,
not
I,
want
to
do
tokenization
of
stocks.
I
spin
up
a
chain
specifically
for
that
it
can
communicate
with
other
portions
of
the
L3
chain
as
I
see
fit,
and
it
can
also
interact
with
other
app
chains
via
that
kind
of
intermediary
layer
of
L2.
A
So
this
is
the
part
where
I
kind
of
took
my
own
hand,
is
that
I
don't
want
you
using
Basu
in
this
environment.
The
whole
point
of
public
infrastructure
is
that
you
just
kind
of
use
the
infrastructure
and
you
don't
worry
about
the
client,
that's
running
it
as
the
person
who
wants
people
to
use
my
product.
That's
you
know
not
necessarily
what's
good
for
me,
but
in
the
longer
term
I,
you
know,
as
a
basic
product
manager,
I
see
myself
servicing
more
networks
than
particular
companies.
A
A
Yep
it's
the
same
process
as
a
roll-up
would
take
on
L2
to
L1.
So
the
question
was:
how
do
transactions
basically
be
sequenced
and
batched
on
Alpha
3,
and
it's
the
same
as
L2
to
L1,
where
we
batch
and
process
transactions
via
that
single
prover
sequencer?
And
then
they,
you
know,
are
posted
to
L2
as
kind
of
these
data
blobs
and
like
guarantees
that
we
make
when
we
post
from
L2
to
L1.
A
A
Yeah
so
I
mean
it
depends
on
the
type
of
rollup
you're
using,
but
in
zero
knowledge
proofs,
it's
validating
the
state
transition
that
occurs
on
L3
and
then
it's
posting
that
result
to
L2
as
a
transaction.
So
if
you
think
of
the
same
exact
roll-up
that
occurs
from
L2
to
L1,
it's
done
in
the
same
way
it's
validating
State,
Transitions
and
you're,
inheriting
a
security
scale,
guarantees
of
Layer
Two,
which
is
a
big
hand
wavy
way
of
saying
we
do
things
faster,
because
an
L2
has
a
more
centralized
sequencer.
A
However,
L2
is
still
faster
than
L1,
because
L1
has
an
entirely
decentralized
sequencer,
so
you
can
see
how
they
connect
together,
but
you're
again,
you're
offloading
multiple.
Like
so
imagine,
the
L2
has
every
state
transition
that
ever
occurs
on
this
big
L2
network
has
to
be
batched
and
rolled
up
and
put
on
L1
As.
You
move
to
these
app
chain
models,
I'm
only
concerned
with
that
l3s
batch
and
roll-up
of
transactions,
which
makes
things
easier
for
them
to
prove
and
verify,
and
then
they
post
those
results
on
the
L2
which
are
rolled
up
again.
A
But
you,
what
is
important
is
that
the
output
is
stored
on
a
chain
where
you
trust
the
security
guarantees
for
a
number
of
reasons
and
again,
the
reason
you
would
trust
L2
is
because
it's
secured
by
ethereum
layer,
one
which
is
secured
by
the
economic
incentives
of
the
network.
So
those
are
big
security.
A
Things
there's
off-chain
data,
there's
identity
data,
there's
all
this
other
stuff,
but
when
you
come
up
to
layer
three,
since
you're
operating
kind
of
within
your
own
environment,
you
have
much
more
control
over
what
that
granularity
and
privacy
looks
like
because
all
you're
putting
on
L2
is
a
hash
essentially
of
that
state
transition.
That
shows
that
it's
valid
in
perpetuity,
so
L2
doesn't
get
to
see
what
I'm
doing
up
here.
They
just
say:
oh
a
and
a
happened,
and
then
now
B
is
the
state.
A
They
don't
know
what
that
state
transition
was,
but
they
know
what
the
state
was
Prior
and
the
state
was
after
and
an
obfuscated
format,
and
it's
the
same
when
you
go
from
L2
to
L1
L1.
Does
it
it's
not
necessarily
aware
of
the
roll-up
state?
In
the
same
way
it
has
the
roll-up
smart
contract,
which
keeps
kind
of
those
checks
and
balances,
but
it's
not
worried
about
the
execution
of
those
smart
contracts
on
there
too.
It's
not
necessarily
worried
about
specific
identity
on
Layer
Two.
A
C
A
The
balance
would
have
to
remain
the
same
like
you
can't
create
and
Destroy
value
on
layer.
One
like
you
have
to
yeah
yeah.
Sorry,
there's
a
lot
of
questions,
so
we're
gonna
go
kind
of
in
order.
The
previous
question
was
about
mostly
clarifying
what
I
was
discussing
and
how
these
inputs
and
outputs
are
recorded
at
each
basically,
they
Cascade
up
and
down.
That's
why
they're
called
roll
ups
yeah
I,
don't
know
how
to
simplify
that
more
Hart
had
a
question
in
the
back
or
a
comment.
A
As
well
too,
all
of
these
transitions
can
be
captured
in
between
two
blocks
on
L1,
so
I
have
a
slot
12
seconds.
Long
on
ethereum
magnet
I
do
a
whole
bunch
of
stuff
on
the
roll
up,
because
I'm
running
a
super
fast
sequencer
and
it
can
work
faster
than
the
nodes
in
the
ethereum
network.
Cam.
So
I
got
four
blocks
which
are
filled
with
you,
know,
tons
and
tons
of
little
transactions,
I,
basically
hash
merkelize.
A
All
this
stuff
and
I
put
it
back
on
layer
one
and
then,
when
I
get
to
the
next
block,
the
roll
up
will
reference.
The
change
in
state
that
has
occurred
here
as
it's
kind
of
canonical
state
and
a
canonical
state
will
drive
all
the
kind
of
continuation
of
that
roll
up
and,
if
you
think
of
this
one,
it's
the
same
with
layer.
A
Three,
it
comes
up
even
more
I
do
even
more
processing
between
the
space
of
those
two
blocks,
or
even
in
one
transaction,
on
Layer,
Two
and
Cascades
back
down
between
that
kind
of
12
second
block
time.
So
a
roll
up
is
called
as
such,
because
I
roll
up
a
whole
batch
of
transactions
push
them
back
down
to
the
canonical
chain.
A
In
this
case,
ethereum
L1
that
canonical
chain
can
be
something
else
there
doesn't
have
to
be
ethereum
L1,
but
in
all
the
examples
I've
discussed
today,
mechanical
chain
is
this
and
again
you're
you're
putting
money
here
which
goes
like
to
your
point.
You
have
to
get
assets
somewhere,
so
I
20
usdc
on
layer.
One
I
now
have
20
usdc
in
the
smart
contract
for
that
roll
up
on
layer,
one
which
is
instantaneously
available
on
L2.
It's
not
based
on
kind
of
a
bridge.
It's
a
smart
contract
guarantee,
so
the
L2
parses
that
smart
contract.
A
It
says
all
these
things
have
happened
and
then
at
the
output
of
this
block,
the
fourth
block
I
make
the
state
transition
to
a
Smart
contract
on
L1,
but
I
only
I
don't
care
about
the
intermediary
transactions
per
se.
That's
why
they're
all
they're
all
rolled
up
together
so
I
take
the
first
input
and
the
output
and
I
update
what's
happening
on
the
canonical
Chain
by
virtue
of
that
process.
A
A
It
and
then,
when
it's
resolved
those
twenty
dollars
a
bit
good
back
to
everyone
yeah.
So
as
far
as
like
the
native
currency,
so
eth,
that
is
the
case.
You
can
mint
like,
for
example,
you
think
of
like
certain
tokens
like
tokens
like
optimism
like
the
op
token,
so
they
they
have
to
represent
it
in
state.
But
you
can
kind
of
mint
burn
in
interesting
ways.
But
if
you're
talking
about
like
native
denominated
currency,
you
have
to
come
from
L1,
and
so
that's
why
the
erc20
tokens
have
to
like
move
around.
A
But,
for
example,
if
I'm
on
Layer
Two
and
I
buy
20
usdc.
Someone
has
a
process
behind
the
scenes
to
perform
that
swap
on
my
behalf.
Essentially
because
you
you
have
to
purchase
from
either
an
exchange
or,
from
you
know,
a
decentralized
Exchange,
in
which
case
those
liquidity
pools
exist
on
both
layers.
A
A
A
A
A
A
A
We
use
this
McDonald's
coin,
but
it
pays
for
its
security
budget
and
maybe
polygon
token
and
Matic
or
like
something
else
depending
on
the
layer
two,
so
we're
not
quite
there.
Yet
it's
all.
Typically,
this
picture
today
is
all
denominated
at
me
all
the
way
down
once
account
abstraction
gets
into
play
that
100
changes
because
you'll
handle
those
kind
of
payments
at
the
wallet
level,
and
then
the
pay
masters
will
feel
any
so
like
I'm
paying.
A
On
behalf
of
a
user
who
uses
gives
me
McDonald's
coin
and
then
I
pay,
the
network
clashes
a
little
bit
with
what
I
said
about
multi-dimensional
gas,
which
opens
it
at
both
levels
of
abstraction,
the
wallet
and
the
protocol
level.
It's
an
insane
amount
of
complexity
that,
frankly,
is
still
being
worked
out
in
real
time
and
I.
Welcome
your
contributions
on
those
discussions.
A
A
So
you
have
to
pay
to
secure
this
all
the
way
down
in
terms
of
fees,
but
in
reality
you
could
choose
to
run
the
infrastructure
yourself.
But
in
order
to
inherit
this,
you
still
need
to
pay,
and
this
is
cheap
right.
This
is
getting
really
cheap,
like
transacting
on
l2s,
fractions
and
fractions
of
ascent.
So
if
you
roll
up
a
ton
of
transactions
over
here
and
post
only
one
on
L2
you're,
paying
like
a
cent
per
transaction-
so
yes.
A
A
D
A
A
D
A
A
A
A
That
one
you'd
have
you'd
have
to
you
can't
raise
to
another
Network
without
exposing
what
you're,
bridging
well
so
ckp
comes
into
play
there,
because
you
can
make
assertations
about
the
data
and
move
it.
That's
a
great
question,
though,
I'll
have
to
think
on
that
one.
The
like
with
my
kind
of
Cobble
together
answer,
would
be
that
yeah
you
wouldn't
be
able
to
go
to
another
single
purpose
chain,
necessarily
without
exposing
what
you're
doing,
but
you
can.
A
I
mean
so
zero
knowledge
proves
to
your
point:
they
have
identity,
privacy
and
data
privacy,
it's
not
one
or
the
other.
Necessarily
you
make
expectations
about
the
data
and
they
like
the
account
storage
and
what's
sitting
in
it
as
well
as
smart
contract
inputs
and
outputs,
and
you
don't
have
to
expose
any
of
the
underlying
reasoning.
This
is
a
good
time
to
go
to
this
slide.
C
A
A
Yeah,
as
I
mentioned
earlier
in
the
present,
the
question
was
about
supported
private
features
and
support
of
those
features
going
forward,
as
I
mentioned
earlier.
In
the
call
we
currently
have
no
plans
like
consensus
will
not
be
just
ripping
things
out
of
the
code
base.
We
only
have
plans
to
deprecate
what
I
mentioned
earlier,
which
was
go:
Quorum
compatible
privacy
modes
and
ivft1.
A
We
are
working
with
Partners,
like
web3
labs,
to
continue
to
provide
product
level
support
for
private
networks.
Eventually,
our
hope
is
to
hand
off
all
of
these
features
and
they
can
be
maintained.
However,
they
are
maintained.
It
is
an
open
source
project.
Consensus
will
not
be
maintaining
them
into
the
future,
but
we
will
not
be
actively
breaking
or
deprecating
anything
that
I
haven't
mentioned.
As
for
a
specific
list,
I
can
get
back
to
you
on
that.
I
probably
should
work
on
that,
but
yeah
as
it
stands.
A
A
You
all
should
be
building
it
in
reli,
like
in
alignment
with
whatever
works
for
your
organization,
and
you
know
a
lot
of
that
will
trickle
back
into
the
main
code
base,
but
before
I
jump
at
risk
of
jumping
ahead
again,
zero
knowledge,
proof,
kind
of
101,
I
have
approver
and
I
have
a
verifier
and
I
have
a
ZK
scheme.
These
are
extremely
complex
cryptographic
circuits
that
essentially,
you
know.
If
you
the
classic
example
I
like
to
give.
Is
you
have
somebody
that
knows?
A
A
So
you
have
somebody
walk
into
the
cave,
you're
you're
kind
of
like
videotaping
the
the
output,
but
you
don't
necessarily
know
where
which
side
they're
going
down
or
how
they're
getting
there
you're
just
seeing
them
come
out,
so
you're
able
to
kind
of
ascertain
it
as
they
get
to
the
other.
I've
honestly
forgotten
that
metaphor,
so
I'm
not
going
to
use
it
anymore,
but
it's
on
Wikipedia,
it's
very
popular.
A
The
approvert
basic
I
have
somebody
who's,
making
an
assertion
and
someone
who
knows
the
assertion
of
the
what
I'm,
proving
because
I
have
the
data
in
front
of
me.
I'm
looking
at
my
data
I
know
that
it's
correct
and
I
have
a
basically
a
ZK
circuit,
where
I
can
understand
by
agreement
on
a
trusted
setup.
A
I,
just
it's
so
complex,
it's
so
convoluted
that
I
always
forget
the
yeah.
So
we
have
agreement
among
parties
on
a
scheme
that
we're
going
to
use
specifically
what
kind
of
circuits
and
again
we
get
together
in
this
kind.
So
you've
heard
of
snarks
and
Starks
snarks
is
some
kind
of
like
non-interactive
proof,
which
means
I
don't
need
to
actually
check
all
this
information.
A
A
We
agree
on
a
scheme
and
then
everything
out
after
that
we
can
trust
the
circuit
that
comes
in
and
out
so
I
have
my
knowledge
that
Hart
said
I
have
a
witness,
which
is
this
and
I
the
proof
of
knowledge
that
can
be
checked
without
revealing
the
content
of
this,
or
even
talking
to
this
person.
I
don't
need
to
talk
to
this
person.
I
can
go
to
the
shared
scheme.
I
can
take
the
verification.
A
A
The
circuits
are
those
public
inputs,
private
inputs
and
the
statements
of
what
we're
asserting
the
reason
I'm
not
going
to
go
into
too
much
details
because,
frankly,
a
lot
of
the
math
is
over
my
head
and
it's
very
complicated,
but
a
lot
of
smarter
people
than
I
have
proven
that
it
works,
and
it
is
a
very
widely
accepted
practice
in
computer
science
and
cryptography,
so
it.
How
does
this
relate
to
what
we
just
discussed?
A
Data
and
I
have
people
that
maybe
just
need
to
check
it.
They
don't
need
to
know
the
actual
data.
We
agree
on
the
scheme,
the
basically
the
fundamental
building
blocks
of
the
network
that
we're
transacting
upon,
and
we
can
do
this
proof
of
knowledge
very
easily
and
very
not
cheaply,
because
these
machines
are
very
powerful
that
do
this
kind
of
math,
but
we
can
do
it
and
going
back
to
this
kind
of
photo.
A
So
we
have
statements
of
zero
knowledge,
provers
and
verify
kind
of
either
amongst
themselves.
So
I
can
verify
amongst
all
of
the
participants
in
My,
Little,
Worlds
and
I
can
make
assertions
that
I
prove
to
the
whole
world
and
that
we
can
check
at
both
layers.
So
this
has
a
specific
CK
circuit.
That's
set
up
at
the
time
the
L2
is
created
again.
We
only
typically
need
one
honest
participant
and
oftentimes.
They
have
somebody
participate
and
throw
away
all
data
just
not
keep
it
so
that
no
one
actually
knows
so.
A
There's
not
really
a
back
door
into
this
circuit.
Unless
you
know
fully
well
that
everybody
that
you
worked
with
in
The,
Trusted
setup
colluded
and
that's
a
big
assumption,
because
if
you're
honest,
you
can
just
not
collude,
and
that
will
be
great,
like
I
mentioned
the
one
that
we're
using
on
ethereum
mainnet
at
85,
000
participants
and
I
personally
typed
in
random
numbers
on
my
keyboard.
A
So
I
actually
don't
know
what
my
input
was
for
this
Randomness,
so
collect
entropy,
create
circuits,
make
proofs,
that's
where
the
Privacy
value
comes
from,
because
again,
I
don't
have
to
reveal
my
data
to
the
proverb
or
sorry,
it's
the
verifier
to
prove
the
veracity
of
that
data,
which
means
in
L3
land
I
can
transact
all
I
want
all
live
long
day,
hit
the
circuit
on
L2
and
have
a
proof
back
that
we
can
both
verify
without
revealing
my
data
up
here.
This
also,
which
goes
into
account
state
I.
A
Take
my
the
entirety
of
my
account.
State
I
can
split
into
all
these
little
pieces,
but
I
can
still
get
a
unified
picture
of
that
because
of
the
fact
that
I'm
using
this
kind
of
format
we
have
the.
This
is
a
comparison
and
contrast
for
like
what
we
have
with
private
transactions
today
versus
kind
of
what
is
going
on
with
Stars
privacy.
A
So
you
all
know,
and
potentially
love
or
hate
private
transactions,
privacy
group,
a
privacy,
Group,
B,
Prime
C
group-
a
can
see
all
of
the
data,
but
not
necessarily
what's
going
on
in
these
notes.
For
now
ignore
the
this.
This
is
one
baser
network
and
then
obviously,
privacy,
Group
B,
looks
at
this
privacy.
However,
let's
not
pictured
is
it
to
Sarah
notes
that
need
to
be
running
and
the
contracts
and
extra
code
that
need
to
be
managing
all
this
information.
A
What's
also
not
pictured,
is
the
fact
that
you
have
a
separate
state,
that's
being
managed
in
the
Privacy
groups
to
be
able
to
coordinate
all
of
that
stuff.
The
difference
on
the
snark
side
is
that
we
have
a
unified
picture
of
the
state,
my
verifier
data.
So
if
you
go
back
to
the
previous
picture,
I
only
control
the
data
that
I
on
my
node.
That
represents
my
picture
of
the
worlds.
I
I
put
it
into
that
zkp
scheme
and
we
have
a
unified
state.
But
again
only
my
inputs
are
revealed
to
me.
A
A
lot
more
effective
at
managing
unified
State
without
having
to
set
up
the
actual
management
of
the
Privacy
groups
and
another
of
the
pro
is
that
you
get
higher
throughput
because
it's
just
well,
you
know
part
of
it.
Is
that
you're
not
doing
all
these
round
trips
you're
not
running
on
an
L1
but
you've
had
a
unified
state
with
token
transfers
at
scale.
It's
fully
private
or
as
private
as
you
would
like.
Zika
abms
sort
of
invalidate
this
a
little
bit
because
they're
slow
right
now,
but
they're
getting
a
lot
faster.
A
A
I
have
evm
execution
that
I
do
I,
basically
use
I
run
a
big
old
Trace
if
you're
familiar
with
the
trace
logs
and
Basu.
It
just
does
a
huge
dump
of
the
execution
and
by
huge
I
mean
huge
they're,
like
30
gig
Json,
sometimes
into
the
evm
I
put
that
into
the
prover.
In
the
zkp
and
I
have
a
verified
execution
of
the
evm,
that
is
it
an
extreme
oversimplification
of
the
process.
It
takes
a
lot
of
work
and
uses
very
heavy
hash
algorithms
and
super
super
beefy
computers.
A
But
at
the
end
of
the
day,
ASU
does
a
big
old
trace
of
what
happened
within
the
evm.
We
dump
that
Trace
into
a
zero
knowledge
circuit.
The
circuit
proves
that
the
trace
that
the
EPM
execution
happened
in
the
order
that
it
said
it
did
on
the
state
that
it
said
it
did
and
then
it
posts
that
output,
but
none
of
that
is
revealed.
A
So
that
means
you
have
private
smart
contract
execution
for
the
specific
approvers,
but
you
have
the
state
transitions
managed
across
that
account.
Unified
account
state,
like
I,
mentioned
here
again
a
simplification,
but
imagine
you
turn
the
whole
evm
into
one
big
old
circuit
and
the
inputs
and
outputs
are
those
provers
and
verifiers
question
the
back.
A
A
A
A
That's
what
you're
saying,
let
me
reiterate
the
question
to
make
sure
that
I
have
it
correct.
So
the
question
is
around
when
you're,
using
kind
of
this
multi-layer
model
and
you're
using
zero
knowledge
proofs,
how
do
you
kind
of
share
the
proving
schemes
across
the
layers
in
a
way
that
means
I
can
transact
up
and
down
without
my
data
becoming
garbage
and
move
it
across
layers
in
a
way,
that's
cohesive
is
that
right.
A
A
Ual,
like
I
mentioned
with
before,
when
you
do
that
kind
of
roll-up
process
to
move
up
and
down,
you
lose
the
granularity
of
data
for
a
number
of
reasons,
because
one
you
want
to
preserve
privacy,
often
but
two
I'm
only
posting
like
the
results
of
all
of
this
to
L2.
So
that
doesn't
mean
that
someone
can
come
say.
Oh,
you
know
so,
and
so
has
an
account
over
here
that
I
want
to
be
able
to
pull
that
data.
A
You
would
need
to
basically
request
that
data
from
the
provider
themselves,
so
we
do
run
the
risk
of
creating
innumerable
silos
again.
The
counterpoints
of
that
is
that
it
doesn't
necessarily
have
to
be
designed
in
that
way.
You
can
design
it
in
a
way
where
I
can
Traverse
those
links
and
get
the
data,
because
it's
you
can
unroll
all
of
that
state.
If
you
have
the
appropriate
access
right.
A
It's
all
the
ethereum
standards,
so
the
question
was:
how
do
we
standardize?
Is
there
work
being
done
around
standardization
of
the
movement
of
data
across
these
layers?
So
once
you
get
from
from
L1
and
L2,
it's
identical
ethereum-based
standards.
All
of
it
is
the
same
on
L2
the
data
is
typically
available
and
an
optimistic
roll-up
sense
it.
That
has
to
be
the
case,
because
otherwise
you
can't
prove
fraud
in
a
ZK
roll
up.
A
A
Right
it
could
be
a
public
L3
or
it
could
be
an
L3
that
is
completely
opaque
and
they
only
inherit
the
security
architecture
of
L2.
They
don't
inherit,
like
the
transparency
and
all
that
good
stuff,
that
we
like
blockchain
for
in
many
respects,
because
it's
a
choice
so
they
could
have
the
most
opaque
state
in
the
world
and
just
take
advantage
of
the
security
budget
of
L2
and
share
nothing.
A
So
when
we
talk
about
Regulatory,
Compliance
and
data
privacy
and
all
this
stuff,
it's
mostly
a
matter
of
getting
people
comfortable
with
the
fact
that
you
can't
really
unwind
this
data.
If
you
choose
to
make
it.
So
it's
just
about
the
security
assumptions,
which
is
a
hard
pill
to
swallow.
If
you're
a
regulator-
or
you
know
someone
else-
everybody.
A
A
Another
one
is
like
I,
said
kind
of
like
just
I'm
running
a
world
that
has
custom
rules,
but
maybe
it's
open,
there's
permissioned
and
public
l3s,
like
you
can
kind
of
design
it.
However,
you'd,
like
public
permission,
is
the
word
that
a
lot
of
people
will
be
using
around
this
you've
heard
of
private
permission,
public
permissionless,
public
permission
and
public
permission
lists
are
both
applicable
in
this
instance.
The
reason
it's
public
is
because
of
the
security
budget
and
all
the
other
stuff
that
I
mentioned
on
L2
and
L1.
C
C
A
D
A
It
doesn't
even
have
to
be
that
complicated
node
one
node,
two
trading-
that's
one
trading,
S2
trading.
This
one
keeps
a
record
of
these
accounts,
like
literally
ethereum
accounts.
Apparentness,
too,
is
it
has
access
to
these
accounts?
You
know
other
trade,
that's
sure,
and
they
in
the
zero
knowledge
format.
This
state
is
technically
unified
across
all
three
but
I'm
doing
the
proofs
prior
to
Commitment
up
to
state
in
many
cases,
so
I
can
transact
and
do
all
that
good
stuff.
A
On
my
local,
you
know
situation
presuming
that
I
have
access
to
all
that
data,
prove
it
prior
to
even
sending
it
to
the
sequencer.
I
can
have
one
sequencer
that
can
handle
all
of
this,
and
the
state
is
Unified
via
the
like
the
smart
scheme,
as
opposed
to
me
saying
you
know,
oh,
like
let
me
have
a
separate
roll-up
that
we
can
both
inherit
now
too.
A
A
We
expect
this
cost
to
go
way
down
because
they'll
be
basically
specific
Hardware
to
do
these
kinds
of
proofs
as
they
gain
more
proliferation,
yeah
similar
to
like
Asics,
but
just
for
these
kind
of
cpps
but
yeah.
So
so,
to
reiterate
what
I
just
mentioned,
you
can
have
a
unified,
slash,
private
State
and
verify
the
correctness
of
the
entire
state
by
using
the
same
commitment
scheme
and
having
the
same
notes,
kind
of
Gossip
around
already
proven
State
Transitions
and
account
storages,
basically
so
I
say:
oh
I
transact.
A
You
know
300
from
here
to
here:
I
prove
that
whole
thing
I
pushed
it
up
to
the
main
picture
and
then
the
the
correct
State
transition
is
proliferated
to
other
nodes
as
gossip,
and
they
just
say
oh
I'm,
applying
this
big
transition,
I
check
the
proof
really
quick,
because
checking
the
proof
is
really
easy
generating.
It
is
not
so
that's
the
cheap
part
that
Hart
was
mentioning
I
I'm
base
to
node
B
I'd,
see
the
proof
come
in
I
check
it
I
say
that's
cool.
That
makes
sense.
A
I
update
my
state
without
knowing
any
of
the
data
underneath
it,
so
these
trading
desks
can
stay
in
sync
without
knowing
what
any
of
them
are
actually
doing.
As
long
as
they're
on
the
same
commitment
scheme,
which
is
a
relatively
simple
thing
to
get
commitment
from,
especially
in
a
business
context
where,
if
you're
business,
a
and
business
B
in
your
different
banks,
you're
gonna
sure
as
hell
not
share
your
Randomness
with
the
other
bank
who's
committing
to
the
same
kind
of
setup
right.
A
So
the
collusion
is
a
lot
harder,
especially
when
there's
competing
business
needs
on
the
same
kind
of
marketplace.
Almost
it's
really
cool
like
this
stuff
is
there's
a
reason
I'm
talking
about
it,
it's
very
interesting
stuff
and
it
has
a
lot
of
potential,
as
the
only
caveat
that
I
mentioned
is
it's
kind
of
slow
for
now.
I
think
it'll
get
a
lot
faster.
A
A
This
could
be
a
multi-prover
scenario
where
I
want
to
work
with
other
banks
that
I'm
not
necessarily
trusting
to
sing
singularly
sequence
transactions.
So
if
I
don't
trust
another
party
but
I
have
a
singular
sequencer,
they
can
kind
of
conclude
to
move
the
order
of
transactions
in
a
way
that
might
benefit
them,
because
sequencer
is
the
centralization
point.
That's
why
we
have.
In
this
scenario,
we
want
L2
to
be
kind
of
a
multi-prover
multi-sequencer
environment,
where
they
can't
collude
across
the
sequence
of
those
transactions,
because
you
know
I,
don't
necessarily.
C
A
First
of
all,
what's
coming
in
in
order
to
collude
because
I'm
just
getting
hashes
and
I'm
kind
of
just
blindly
executing
data
here,
but
there's
also
like,
for
example.
If
this
was
all
run
by
one
operator,
then
they
can
say.
Oh
you
know
I,
don't
like
the
way
that
these
look
for
maybe
Mev
purposes
or
something
else
so
I'm
going
to
display
transactions.
A
Improver
environment:
this
is
where
it
gets
a
little
complex,
it's
basically
decentralized
sequencers
decentralized
provers,
which
means
my
transaction
is
routed
and
split
up
into
different
pieces
and
it's
kind
of
impossible
to
to
know
what's
happening
to
collude
like
that
again,
this
is
an
aspirational
photo.
We
are
trying
to
build
a
multi-prover
world,
there's
active
discussion
among
layer
twos
in
building
this
world
right
now.
A
At
the
same
time,
there
are
200,
you
know,
sets
of
transactions
that
I
kind
of
group
all
together
in
those
tinier
State
transitioning
commitments,
because
the
ZK
D
commitments
are
also
really
small
same
with
optimistic
role
of
commitments.
Since
you're.
Just
basically
saying
this
state
transition
happened
as
opposed
to
talking
about
the
entire
State
transition.
It
makes
it
a
lot
cheaper
and
smaller
and
we
dump
it
here
on
L1
and.
A
C
A
On
on
altitude,
yeah
on
on
the
layer
below
you,
you
only
care
about
the
output
and
the
input
you
would
need
to
commit
all
these
changes
on
the
originating
layer,
because
otherwise
you
could
double
spend
so
like
if
I
a
pays,
B,
APC
or
HB
whatever
yeah
these
are.
They
need
to
keep
track
of
everything,
but
this
guy
only
cares
about
the
final
results
and
kind
of
the
inputs.
A
That's
the
this:
is
the
industry
perspective
yeah?
So
the
question
was
what
is
where?
Is
this
Vision
coming
from
and
like
I
mentioned?
These
are
different
companies
like
we're
working
with
other
L2
companies
to
build
this
kind
of
vision,
because
we
know
that
a
single
sequencer,
single-prover
approach
is
will
not
be
trusted
because
you
can
collude
on
a
single
like
like
I
mentioned,
a
single
per
person
can
come
in
and
kind
of
be
like.
Well,
we
don't.
You
know
a
single
sequencer.
A
A
A
If,
in
a
perfect
world,
ASU
execution
lives
here,
they
sue
execution
lives
here
and
it
lives
in
every
one
of
these
tests.
So
Basu
is
executing
evm
code,
that's
batching
up
transactions,
it's
producing
blocks
and
their
sequenced
and
proven
by
the
L2
infrastructure
not
by
basement,
was
not
intending
to
create
like
zero
knowledge
proofs
to
do
this
stuff,
it's
not
intending
to
sequence,
the
trans.
Well,
you
might
be
modifying
they
soon
to
become
sequencer
appropriate,
but
so
it
it's
not
meant
to
like.
A
Do
the
heavy
lifting
of
the
like
proofs
and
ensuring
certain
things
it
will
record
state
it
will
produce
blocks
post
blocks.
It
will
execute
things
in
certain
certain
instances.
A
ZK
AVM
that
I'm
describing
in
a
consensus
example,
does
not
use
basis
evm,
it's
basically
a
custom
EPM
that
is
built
around
ZK
circuits,
but
Basu,
as
was
mentioned
earlier,
has
a
evm
library
that
can
be
ripped
and
replaced.
So
we
basically
do
that
and
we've
we're
modifying
other
components
in
bayesu
to
make
the
rest
of
it.
A
A
Architecture,
I
think
I'm.
You
know
where
we'd
like
the
project
to
go
as
far
as
public
networks
are
concerned,
merge
recap
consensus.
This
is
the
pre-merge
picture
on
the
left
and
the
post
merge
picture
on
the
right
pre-merge
picture.
You
have
pow
consensus,
wrapping
the
execution
layer
in
complex,
wasteful
math.
A
So
you
have.
This
is
the
ebm.
Basically,
the
block
a
lot
of
transactions
come
in
a
lot
of
execution
happens,
and
then
you
wrap
the
security
of
this
in
the
complex
math.
That
is,
private
networks,
do
the
same
thing,
but
instead
of
pow
write,
qbft
ibft.
What
have
you
this
basically
is
unchanged
with
some
caveats
content
this
wraps
evm
execution
secures
it
on
chain.
A
The
same
thing
happens,
kind
of
on
the
right
hand,
side,
except
instead
of
wrapping
evm
execution
in
pow,
we
wrap
it
in
a
whole
new
process
that
is
built
purely
for
proof
of
stake
in
the
ethereum
context.
So
again,
this
is
just
the
ethereum
context.
We
have
its
own
layer
known
as
The
Beacon
chain.
Beacon
chain
is
separated
into
slots
instead
of
blocks
blocks
can
exist
at
every
slot
and
they
basically
do,
but
not
every
slot
is
required
to
have
a
block,
so
slots
also
have
attestation.
So
these
are
the
witness
signatures.
A
A
Super
simplification.
We
still
have
this
consensus
layer
that
secures
EDM
execution,
because
if
we
didn't
have
a
degree
among
parties
on
what
actually
in
those
transactions
it's
the
same
problem,
I
talked
about
in
the
roll-up
example.
So
we
have
to
prove
what
happens
in
here
is
valid
and
the
consensus
layer
provides
a
bunch
of
witnesses,
signatures
and
all
that
good
stuff
which
is
aggregated
and
then
put
into
one
block.
That
is
this
whole
big
thing,
which
has
attestations.
It
has
potential.
A
A
A
The
Brio
magic
is
this
engine
API.
This
was
created
to
allow
those
two
layers
to
seamlessly
communicate
with
each
other.
This
is
a
closed
Port.
It
can
be
extended,
but
it's
like
basically
a
post
Port
that
only
exists
to
have
these
two
nodes
talk
to
each
other.
The
consensus
layer
receives
the
information
about
what
is
going
to
be
happening
with
the
next
block.
Is
there
a
reord?
Is
there
a
it's
called
a
fork?
Choice
update?
Is
there
a
new
payload
of
transactions
that
I
need
to
secure?
A
A
A
This
is
going
to
become
a
lot
more
robust,
this
being
in
the
consensus
layer,
the
folks
on
the
call
they're
starting
to
build
more
and
more
functionality
into
the
consensus
layer.
Now
that
we
have
a
separation
of
concerns
and
more
narrowly
on
ebm
execution
and
World
State
Management
we
really
need
to
eat
is
what
is
currently
the
state
of
ethereum.
They
don't
give
a
crap
about
the
other
blocks,
really
they
do
insofar
as
the
world
state,
but
they
don't
necessarily
care
about
old,
stuff
and
consensus-based
mechanisms,
so
they
defer.
All
of
that
up
here.
A
That's
why
it
makes
Roll-Ups
a
lot
more
interesting
when
you
think
about
execution
clients,
because
all
the
consensus
stuff
is
outsourced
to
the
rollout
sequencer
to
some
of
that
other
stuff.
For
these
different
components,
we
don't
care
about
how
consensus
is
reached.
We
just
start
spitting
out
data
as
fast
as
possible
about
the
world
State
and
sometimes
in
the
evm.
A
No,
so
we
we
might
build
a
light
client
into
basic
that
allows
you
to
connect
and
sync
the
chain,
but
you
will
never
be
able
to
validate
blocks
or
run
a
validator
with
just
space
suit.
You
will
need
an
extra
consensus,
client
like
techu,
Lighthouse,
prism,
Nimbus,
slope,
star
or
whatever
yeah.
There
are
light
apis
that
allow
you
to
connect
in
sync.
You
will
probably
be
building
those
soon,
so
you
can
follow
the
chain
and
run
data
queries
without
having
to
run
another
layer
but
not
built.
Quite
yet.
You
need
currently
to
sync
midnet.
D
A
D
A
A
Analytics
this
gets
like
this
state
of
consensus
on
the
Chain,
which
is
these
are
the
people
that
need
to
vote
soon.
These
are
the
votes.
These
are
the
peers
that
are
doing
this
this,
and
this
there's
like
subnets
and
committees,
and
all
this
crap
that's
housed
up
here.
This
is
where
the
bulk
of
the
data,
because
that's
what
evm
is
that's
what
the
contracts
are
is.
This
is
where
the
account
balances
are.
A
A
However,
it's
it's
true
right:
you're
directing
the
evm
from
the
consensus
layer
and
everything
else
exists
to
support
this
literally
everything
else,
except
maybe
Terry
literally
everything
exists
to
support
these
two
things
which
Drive
public
network
consensus,
and
that
could
be
improve
a
mistake.
It
could
be
roll-up
consensus.
A
A
A
This
is
what
you
know:
I
potentially
love.
You
have
the
Privacy
components
here
with
the
Sarah.
We
add
in
a
sub
protocol,
specifically
for
bft
related
consensus.
It
allows
us
to
network
in
the
appropriate
way
that
Antoine
touched
on
earlier,
and
then
we
have
the
actual
consensus
things
I
mean
we
still
have
approval
work
right.
You
still
have
the
attached,
you
can
use
it
I,
don't
know
why
you
would
multiple
consensus.
It's
still
is
pluggable
right.
You
can
choose
what
you
want
if
everything
else
we
want
to
decouple
these
abstractions
over
time.
A
A
We've
in
order
to
support
both
of
these,
namely
this,
these
two,
the
qbft
consensus
and
these
plugable
consensus
things.
We've
done
a
lot
of
tight
coupling
with
these
sub
protocols,
the
protocol
schedule
and
it's
turning
into
a
spaghetti
mask
and
we're
looking
to
split
this
out
when
I
talk
about
split
this
out.
This
don't
worry
about
this.
This
is
not
a
functional
change.
This
is
resolution
of
tech,
deck
we're
looking
at
decouple
these
over
time
and
make
them
more
usable
and
hopefully
more
extensible
because
in
reality,
looks
like
this.
A
A
Look
at
how
similar
these
two
things
are:
roll
up,
State,
Storage
roll
up,
State
I,
might
need
a
state
to
keep
track
of
potentially
what's
happening
on
layer
one
and
in
the
roll-up,
so
I
might
need
to
add
a
new
module.
That's
why
I
have
like
a
double
box.
Sequencer
still
externally,
driven
consensus,
however,
a
little
bit
of
green
for
the
basic
box,
because
we
might
still
build
these
components
in
Bay
soup
anyway
same
things,
evm
is
optional.
You
can
rip
it
out.
A
Fiber
Network,
exactly
the
same
Bridge
contracts
over
layer
so
like
these
were
kind
of
throwaway
slides.
But
what
I'm
trying
to
say
is
all
these
components
are
the
same,
but
the
basic
picture
looks
like
this:
it
doesn't
look
like
these
discrete
boxes.
We're
trying
to
get
there,
so
that
is
I.
Think
the
perfect
segue
for
me
to
go
back
to
the
roadmap
right.
A
Role
of
compatible
statement
Android,
that's
that
State
Management
piece.
I
was
just
talking
about
new
RPC
formats,
talking
about
the
engine
API
talking
about
RPC,
for
the
account
abstraction.
This
is
the
first
step.
This
is
not
a
complete
effect
down
here,
trying
to
build
flexible
roll
of
packages.
That
means
separating
all
those
little
boxes
so
that
we
can
stack
them.
However,
we
want
I
mean
instead
of
a
basic
driven
consensus.
Engine
I
defer
to
something
like
the
optimism,
sequencer
and
bass
too
simple.
A
On
the
EVN,
but
not
really
so
again,
just
trying
to
separate
all
those
building
blocks
into
different
components,
ultimately
to
go
here
where
we
take
those
building
blocks
and
we
get
all
the
chains
for
free
if
we
want
them.
Frankly,
this
is
probably
the
biggest
lie
on
the
whole
slide
deck
we'll
see,
but
we're
going
to
get
aggressive
with
this
going
forward.
A
We
we
need
to
split
the
code
base
open
because
I
want
it
to
be
easy
to
maintain
private
Network
features
without
breaking
stuff,
because
we
want
more
people
to
maintain
the
private
Network
features.
So
we're
really
looking
forward
to
continuing
this
modular
work
to
get
those
blocks
to
be
discreet
so
that
we
can
get
to
where
we
need
to
go
now.
Brings
me
to
my
last
point
and
then
we'll
do
a
quick
q,
a.
A
A
A
A
We
have
a
public
demo
board,
you
can
go
see
exactly
what
our
backlog
is,
what
we're
building
what
bugs
we
have
prioritized.
If
you
don't
see
your
bug,
sorry
I'll
get
there
and
you
can
check
everything
out.
This
is
mainly
maintained
by
me.
So
you'll
probably
mostly
see
consensus
moving
fingers
around
again.
I
would
also
like
that
to
change
code
contributions.
It's
very
straightforward,
again,
contributor
calls.
We
have
a
lot
of
labels,
these
different
samples,
bugs
census,
related
issues,
dependency,
updates,
developer
experience.
A
If
you're
looking
to
start
contributing
code
go
here,
it's
very
simple
stuff.
You
know
an
Etc
label
if
it's
for
ethereum
classic
an
EIP
label.
If
it's
for
mainnet
improvement
proposal,
yada
yada,
we
try
to
make
it
easy.
Really
you
need
10
or
so
pull
requests
to
become
an
active
maintainer.
An
active
maintainer
can
approve
pull
requests
into
the
main
repository,
that
is
to
say,
you
can
still
contribute
without
being
an
active
maintainer.
Your
contributions
will
always
be
reviewed
by
one
of
the
maintainers.
A
A
We
are
working
on
additional
technical
documentation,
I'd
like
to
do
things
like
breakdown,
the
evm
library
break
down
the
protocol
schedule
and
more
I'm
thinking
that
we
will
do
some
kind
of
content
Series,
where
the
baseball
engineers
run
through
what
a
lot
of
these
abstractions
are
and
what
they
mean
like
similar
to
what
you
did,
but
like
actually
kind
of
break
down.
The
protocol
schedule
break
down
how
all
these
different
network
types
work.
A
A
A
We
hopefully
will
have
also
more
money
if
eth
goes
up
a
lot
to
pay
for
bugs
and
Grant
bounties
to
do
stuff.
One
thing
to
note
that
I
actually
don't
know
if
I
included
in
the
slides
is
that
Bassy
participates
in
a
client
incentive
program.
Part
mentioned
it
the
other
day.
If
you
contribute
on
Basu
up
to
a
certain
point
on
mainnet
related
issues,
you
can
literally
get
paid
by
the
ethereum
foundation
that
that
is
good
optics
for
organizations.
A
It's
good
optics
for
individuals,
whatever
capacity
you
choose,
there's
also
the
protocol
all
guilds.
These
are
a
whole
bunch
of
other
topics,
but
to
say,
building
on
mainnet
is
rewarding
building
on
basically
rewarding
I'd
like
to
use
the
remaining
CIP
funds
to
incentivize
all
kinds
of
stuff,
not
just
mainnet,
but
you
can
get
paid
too.
D
A
Yeah,
you
only
need
maintainer
status
to
approve
PRS
of
the
main
repo
doesn't
mean
you
can't
code
today
and
get
the
hours
approved.
We
hang
out
in
the
Discord.
You
can
reach
all
the
engineers
and
contributors
here.
Don't
post
technical
questions
here,
post
process
related
project
related
questions.
Here
we
have
other
channels
for
tasseling
some
new
proposals.
I
would
ideally
like
to
do
what
I'm
doing
now
on
a
quarterly
basis
or
a
half
one
half
basis
a
product
update
of
some
kind
stirco.
A
What
have
you
because
I'm
getting
a
lot
of,
looks
slash
questions
that
have
proven
that
these
things
are
useful
and
people
are
learning
stuff,
so
it
doesn't
necessarily
even
have
to
be
in
person
I'm
very
comfortable
to
sit
in
my
house
and
to
lecture
for
an
hour
so
I,
you
know
again.
This
is
a
new
proposal,
bi-annual
core
development
review
to
align
ethereum,
Improvement
proposals
and
standards.
A
What
does
this
mean?
Basically,
what
core
depth
changes
are
coming
that
will
impact
what
you
do
if
you
choose
to
use
the
latest
versions
of
ASU.
That
will
be
again.
These
are
just
proposals,
I,
don't
know!
If
anyone
wants
this,
but
I
will
I
already
do
these
calls
for
consensus
and
for
other
organizations
they're
openly
existing
calls
and
just
record
and
share
or
I
can
do
the
same
thing
that
have
q
a
and
interactive
session,
where
I
break
down
everything.
That's
happened
in
ethereum
for
this
group.
A
A
There
are
a
million
comparisons
online,
but
I
specifically
don't
have
one
Gap
is
the
gold
standard,
fastest
execution
speed,
but
a
lot
of
storage
Basu
has
some
of
the
slower
execution
speed,
but
it
doesn't
really
matter
once
you
reach
a
certain
point.
However,
we
have
the
lowest
storage
requirements
of
any
of
the
main
clients.
Netherland
sits
somewhere
in
the
middle
and
their
focus
is
just
providing
a
good
validator
experience.
A
No,
they
cannot
so
it
depends
well,
it
depends
on
so
the
question
was:
can
layer,
2
participants,
access,
other
information
on
chain
for
the
other
transactions
and
it's
up
to
the
design
of
the
roll-up,
but
from
all
the
ones
that
I've
seen?
Privacy
is
a
key
selling
point
and
they
do
not
reveal
transaction
details
to
each
other.
A
Any
other
questions
in
the
call
or
in
the
chat,
all
right,
I'm
going
to
Breeze
through
this
in
some
overtime.
Why
does
Court
of
element
matter?
This
is
changing
gears
now
important
element.
I
mean
ethereum
core
development.
It's
just
a
loose
group
of
people
that
anyone
could
be
involved
in
that
develop.
A
This
is
what
we
really
need:
an
understanding
of
business
and
regulatory
requirements
to
the
core
development
Community,
the
ethereum
developers
are
all
they
care
about
is
the
technology
side.
We
need
four
voices
talking
about
regulatory
requirements
and
how
we
can
service
them
in
core
development
that
could
be
standards
that
we
can
iterate
on
with
both
technologists
researchers
and
kind
of
regulatory.
A
Folks-
and
you
know,
Financial
folks
mean
a
bunch
of
things,
but
around
sorely
needed,
because
we
just
build
the
technology,
essentially
in
a
vacuum
where
we
need
to
start
caring
about
financial
like
we
need
to
start
getting
involved
in
regulation
in
order
to
bring
more
Commerce
on
shame,
but
through
the
web.
Free
migration
requires
collaboration
and
core
development.
Protocol
updates
are
constantly
in
the
news.
If
you
care
about.
A
D
A
Ethereum
protocol
development
as
it
stands
right
now
it
is
fortnightly
which
is
my
British
College
way
of
saying
every
two
weeks
on
Thursday
at
roughly
11
Eastern
for
10
Eastern,
better,
it's
live
streamed
on
YouTube
Zoom.
You
can
join
the
zoom,
it's
not
a
closed
group.
Like
I
said
anybody
can
join
the
zoom.
They
share
the
link
in
Discord
and
it's
mainly
client
developers
and
r
d
researchers,
but
we've
started
to
see
more
and
more
interested
parties
like
coinbase,
deep
by
applications.
Potentially
some
actual.
A
A
I'm
not
going
to
go
through
this
there's
five
types
of
VIPs:
this
is
the
one
you
need
to
be
worried
about
core
aips
change,
the
way
that
basically
Works.
Fundamentally,
it
means
that
we
need
to
change
something
via
a
hard
fork
and
if
mainnet
requires
a
hard
work,
your
network
will
require
changes,
I'm
just
going
to
say
that,
right
now,
if
you
again,
this
is
presuming
that
you
update
your
base.
You
notes
at
some
regular
data
erc's.
This
is
where
I
see
most
of
this
group
actually
getting
involved.
A
Things
like
you,
know:
social
recovery
like
Insurance,
all
that
good
stuff.
This
lets
us
this
will.
Let
us
protect
users.
These
are
simple:
they
don't
really
matter
too
much.
These
are
typically
both
in
relation
to
the
core
eip's.
So
if
you
need
new
networking
gossip
stuff
because
of
this
you've
built
that
meta
eips
are
about
information,
changing
the
way
that
ethereum
does
stuff
not
super
useful
for
this
group,
informational
eips
are
about
design
and
they're
just
kind
of
little
bulletins.
A
Okay,
sorry
for
the
15
minutes
over,
but
do
we
have
any
additional
questions?
I
know
I
reached
through
the
court
of
elements
stuff,
but
I've
been
struggling
to
think
of
a
way
to
get
this
group
involved
in
like
a
kind
of
dip.
Your
toes
way,
it
is
a
very
much
encompassing
process.
It
takes
up
a
lot
of
my
time,
but
it
try
it's
think
of
it
as
developing
the
internet
right.
We
wanted
the
internet
to
work
in
a
certain
way,
because
it's
where
we
do
business,
you
see
our
businesses
moving
in
this
direction.