►
From YouTube: Design Patterns to Practically Scale Blockchain Networks- Deepika Karanji & Arun S M, Walmart Global
Description
Design Patterns to Practically Scale Blockchain Networks - Deepika Karanji & Arun S M, Walmart Global Tech India
Blockchain technology has gained mass attention but mass adoption is still a distant future because it is yet to address scalability and user experience issues. The 3 pillars of blockchain - Security, Decentralization and Scalability seem to constantly strive to co-exist but struggle to live in harmony. Scalability and Decentralization are often held back by security, security tends to be compromised by any shifts on a network that offer scalability. Some platforms claim a higher transaction throughput, but compromise on decentralization. Finding a balance between the three is difficult and presents a problem referred to as the Blockchain Trilemma. Few projects propose developing their own blockchains, neglecting the massive developer community and ecosystem that already exists. If there is going to be any sort of mass adoption, scalability is critical. Lately, there have been solutions in Layer 2 space that use innovative and practical design patterns to tackle the trilemma. Popular design patterns like state channels, side chains, optimistic rollups and zero-knowledge rollups have been proven to improve transaction speeds without compromising on security and decentralization.
Sessions Details & Slides (if available): https://sched.co/14H6k
Access All Sessions: https://events.linuxfoundation.org/hyperledger-global-forum/program/schedule/
----
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
Okay
good
afternoon,
everyone
welcome
to
Apple
Ledger
global
forum
and
I
know
it's
soon
after
lunch
and
we
are
getting
into
mode
of
learning
a
lot.
So,
in
this
session
I'm
sure
you
will
enjoy
the
session
learning
more
about
the
scalability
aspects
of
blockchain
technology.
So
when
people
talk
about
scalability,
they
often
go
into.
How
do
we
measure
performance?
How
do
I
understand
how
to
measure
like
how
to
do
things,
but
one
of
the
things
that
people
often
ignore
is
understanding
what
really
affects
the
scalability?
How
do
we
achieve?
A
A
What
really
is
causing
that
the
issue
that
is
not
allowing
us
to
go
further,
so
I'm
sure
you
all
will
enjoy
this
session
today
and
today,
I'm
Arun,
talking
with
my
colleague
Deepika
and
we
are
from
Walmart
Global,
Tech
India
and
briefly
the
agenda
will
cover
three
aspects.
We
will,
of
course,
Define
the
scalability
in
the
stock.
We
are
definitely
not
going
to
just
showcase
the
numbers
that
that
hey
this
is
this
part,
this
particular
blockchain.
This
is
the
throughput
that
we
are
achieving.
We
are
not
going
to
do
that
in
this
session.
B
B
Eventually
they
get
written
into
a
block
and
that
block
gets
committed
onto
a
blockchain
after
it
passes
the
test
of
consensus,
which
usually
happens,
maybe
through
leader
election
or
where
a
bunch
of
nodes
are
selected
to
validate
the
block,
or
it
could
be
that
all
the
participating
nodes
in
the
network
need
to
validate
the
block.
So
whatever
it
is.
This
is
this
is
basically
how
blockchain
works
and
we
are
all
aware
of
that.
B
So
when
we
kind
of
say
blockchain,
you
know
there's
still
this
big
question
that
is
being
asked
today,
given
all
the
noise
that
is
created
by
a
lot
of
token
based
projects
that
are
coming
into
our
ecosystem
and
I
kind
of
found,
a
meme
to
sort
of
capture
that
sentiment
ta-da.
So
basically,
it's
like
blockchain,
not
sure
if
it's
a
great
idea
or
a
shiny
object
syndrome,
I
mean
in
lately
in
I
think
2021.
There
was
this
whole
hype
cycle.
B
Everyone
were
like:
oh
blockchain,
blockchain,
let's
mine,
let's
earn
a
lot
of
money,
and
that
was
the
kind
of
hype
there,
but
slowly
I
think
we're
gravitating
towards
a
mindset
where
we're
trying
to
look
Beyond
crypto
we're
trying
to
see
how
we
can
utilize
certain
aspects
of
blockchain
to
solve
real
world
use
cases
if
we
don't
want
to
try
and
force
fit
that
into
our
Solutions.
But
there
has
a
blockchain
has
been
gaining
a
lot
of
mass
attention
because
of
two
main
aspects
of
it,
which
is
decentralization
and
democracy.
B
But
but
that
being
said,
there
are
some
real
concerns
regarding
the
mass
adoption
aspect
of
it
right,
I
I
believe
I
attended
the
keynote
of
Bob,
Rob
and
Christopher
and,
like
he
said,
we
still
have
a
long
way
to
go
before
we
reach
a
stage
where
we
say:
if
not
this
without
blockchain.
How
do
you
achieve
this
without
blockchain?
There's
no
other
way
to
file
your
taxes
without
blockchain?
Why
are
we
not
using
blockchain
here?
So
you
know
to
achieve
a
state
where
blockchain
becomes
the
norm.
B
There
is
still
quite
some
way
to
go,
and
that
is
mainly
because
of
two
main
or
one
main
bottleneck
which
is
scalability
concerns,
which
kind
of
relates
to
the
transaction.
Speed
concerns.
Scalability
is
directly
linked
to
how
many
transactions
we're
able
to
process
in
a
given
time
frame
right.
So
that
would
be
the
main
bottleneck,
and
then
this
presentation
we're
going
to
try
and
see
what
kind
of
design
patterns
and
we're
going
to
review
some
architectures
of,
like
our
own,
said,
existing
hyperledger
projects
to
see
where
those
issues
kind
of
come
in.
B
Here,
if
you
see
I
mean
we
all
hate
traffic,
we
come
from
different
parts
of
the
world,
but
we
all
have
the
common
problem.
We
don't
want
to
sit
in
traffic
traffic
exists
on
a
road,
because
a
road
is
built.
It's
a
fixed
bandwidth
right.
You,
it's
meant
to
allow
only
few
number
of
vehicles
on
the
road
per
second.
B
So
if
you
know
there's
some
event
like
I,
believe
there's
a
concert
recently
in
the
Dublin
City
Center,
which
caused
a
lot
of
problems
for
us,
the
amount
of
traffic
increases,
and
so
the
flow
of
the
vehicles
on
the
road
also
becomes
a
problem.
So
that
is
essentially
what
is
happening
in
blockchain
today
there
are
a
lot
of
people
who
are
trying
to
execute
their
transactions
on
the
blockchain,
which
is
resulting
in
lesser
speeds
of
execution
right,
so
how
to
achieve
a
bunch
of
things.
B
So
the
three
main
pillars
that
we
kind
of
want
to
talk
about
when
we
say
blockchain
is
scalability,
then
decentralization
and
security.
So
if
we
try
to
achieve
scalable
decentralization,
how
we
want
to
do
that
is
maybe
creating
Island
networks
which
execute
these
transactions
right.
These
do
meet
scaling
requirements,
because
these
networks
individually
execute
these
transactions
and
maybe
later
they
are
come
sort
of
compiled
together
and
then
the
result
is
given
on
to
the
main
blockchain.
B
But
this
does
result
in
some
kind
of
compromised
security,
because
these
Island
networks,
which
are
individually
executed,
executing
different
parts
of
the
transaction,
may
all
be
interlinked.
There
is
a
dependency
Factor,
so
if
any
one
of
these
networks
undergo
some
kind
of
a
bad
block
Edition
or
something
like
that,
then
there
is
a
ripple
effect
which
affects
the
overall
result
of
that
transaction.
Now,
if
we
try
to
achieve
a
secure
scalability,
then
we
can
talk
about
a
trusted
execution
environment
where
we
sort
of
delegate
whatever
transaction.
B
B
If
we
try
to
achieve
decentralized
security.
This
is
something
that
we
are
all
very
familiar
with
a
lot
of
traditional
blockchains,
that
projects
that
we
are
aware
of
right
achieve
this.
This
obviously
leads
to
longer
consensus
times,
because
it
is
highly
decentralized,
which
means
that
is
a
communication
overhead,
where
each
of
the
nodes
need
to
communicate
with
each
other.
B
To
achieve
that
consensus
that
leads
to
increased
security
like
I
just
mentioned,
but
again
we
know
that
this
solution
is
not
scalable,
so
this
kind
of
leads
into
a
problem
that
is
popularly
known
as
the
blockchain
trilemma
This
was
term
that
was
coined
by
vitalik.
So
what
this
dilemma
States
is
that
at
any
given
point
of
time
you
can
achieve
only
two
of
the
three
points
in
the
rectangle
in
the
triangle,
which
is
decentralization
security
scalability.
So
if
you're
trying
to
look
at
say
we
we
spoke
about
traditional
blockchain
right.
B
You
cannot
achieve
scalability
with
that.
If
we
are
trying
to
look
at
some
kind
of
project
which
achieves
scalability
and
security,
there
are
a
lot
of
projects
which
claim
High
TPS
throughputs,
but
they
are
not
necessarily
decentralized.
They
do
that
through
a
lot
of
other
mechanisms
which
promote
only
centralization
where
a
few
selected
nodes
which
maybe
have
specific
Hardware
requirements
or
specific
resources,
Computing
capabilities,
only
those
kind
of
nodes
are
able
to
execute
it.
So
that
leads
to
increased
centralization
compromising
security.
B
A
Thanks
Deepika,
so
now
that
we
understand
problem
statement,
scalability
is
really
a
concern
that
we
need
to
deal
with.
So
just
in
terms
of
blockchain
Technology.
How
can
we
Define
like
what
factors
would
influence
right?
So
in
this
probably
we
are
going
to
cover,
let's,
let's
visualize
it,
to
build
Hardware
based
factors
that
would
influence
in
software-based
factors
so
quickly
talking
through
what
could
be
like
common
Hardware
based
factors
that
could
influence.
We
all
know,
let's
visualize
blockchain
technology,
into
a
system
that
follows
a
protocol
that
does
multiple
things.
A
One
of
the
things
that
it
does
is
running
smart
contract
for
it
to
run
smart
contract.
It
needs
access
to
State
database
right.
So
there
is
State
database.
Read
There
is
a
processing
requirement
that
to
run
a
smart
contract
and,
at
the
same
time
there
needs
to
be
verification
that
needs
to
happen
in
terms
of
cryptographic,
proofs
both
for
Block
verification,
the
signature,
verification
of
submitters
again-
and
apart
from
these,
the
other
factors
that
would
influence
is
just
in
terms
of
network
bandwidth.
A
We
often
talk
about
blockchain
being
a
replication
mechanism
and
like
we
are
not
really
concerned
in
terms
of
our
deployment
infrastructure.
How
are
they
syncing
that
information
with
each
other?
So,
of
course,
when
we
dissect
blockchain
into
these
segments
different
responsibilities
that
are
to
be
done,
we
can
come
across.
How
can
I
increase
my
in
memory
storage
so
that
I
can
store
more
data
and
be
accessible
it
at
runtime,
I,
don't
end
up
being
I
mean
making
a
read,
request
or
write
request
that
needs
longer
time
longer
cycle
to
commit
on
the
state
database.
A
At
the
same
time,
how
can
I
increase
my
network
bandwidth
so
that
I
can
parallely
do
a
gossip
or
send
and
receive
transactions
with
other
nodes?
So
these
are
the
some
of
these
are
some
of
the
things:
let's
not
go
deep
into
I
mean
into
each
of
them,
but
it's
good
to
be
aware
of
these
terms,
so
that
when
we
go
for
our
Network
deployment,
these
factors
are
something
that
you
should.
A
This
is
how
you
should
probably
consider
of
building
your
solution
and
quickly
talking
through
some
of
the
software
based
factors
that
would
influence
the
scale
scalability.
Of
course,
one
of
the
thing
that
people
talk
about
in
blockchain
is
consensus.
Algorithms,
there
is
little
Choice
as
of
today
in
which
protocol
we
choose
and
what
consensus
algorithm
that
particular
protocol
supports.
A
For
instance,
if
you
choose,
let's
say
fabric,
for
instance,
there
is
of
course
endorsements
that
do
happen
between
the
nodes,
but
then,
at
the
end,
when
ordering
service
Runs
Out
of
the
Box,
you
all
are
familiar
that
it
does
have
an
option
to
run
ordering
service
in
a
raft
consensus
protocol
right,
so
there
are
Integrations,
which
others
have
done.
That
would
run
a
different
approach,
but,
as
you
see
like
many
of
the
blockchain,
mostly
they
have
limitations
in
how
you
can
configure
it
so
again
quickly
talking
about
it.
A
There
can
be
two
approaches,
for
instance,
let's
say
consensus
that
would
speed
up
the
execution.
One
of
the
challenge
that
it
will
bring
in
is
how
do
I
create
my
blog?
How
do
I
deterministically
say
like
I,
can
create
this
block
in
next
five
seconds
if
I
need
that
kind
of
determinism
I
need
a
consensus,
that's
that
can
support.
A
For
instance,
if
I
choose
pbft
as
an
approach
pbft
is
it
gives
me
that
support
by
the
network
bandwidth
consumption
increases,
every
node
has
to
talk
to
every
other
node
in
three
different
phases:
pre-validate
validate
and
then
the
commit
phase
right.
If
you
go
into
dice,
if
you
dissect
how
exact
a
pbft
Works.
A
Similarly,
if
you
choose
raft
the
similar
thing
happens,
every
node
has
to
talk
to
every
other
node
for
leader
election
mechanism
now
and
also
replication
mechanism,
and
there
are
four
king
algorithms
that
provide
increased
decentralization,
which
means,
if
you
are
familiar
with
the
initial
version
of
Sawtooth,
which
supported
poet
as
a
consensus.
It
was
kind
of
a
four
king
algorithm
which
which
will
span
so,
for
instance,
every
node
will
optimistically
create
a
block.
They
think
that
they
are
the
in
the
network.
A
They
keep
creating
the
blocks,
but
the
moment
they
realize
that
I
was
not
supposed
to
create
this
particular
block.
They
try
to
discard
it.
They
try
to
respect
the
other
node
that
has
created
the
block,
so
we
are
creating
folks
and
we
are
finalizing
on
that
fork.
The
you
can
imagine
like
there
are
multiple
blockchains
getting
created,
and
only
one
of
that
will
be
finalized.
Now,
when
you
are
doing
that,
there
is
high
possibility
that
you're
discarding
rest
of
them,
so
there
is
of
course,
increased
decentralization.
You
can
run
any
number
of
nodes.
A
Eventual
consistency
is
what
we'll
gain
out
of
this
right.
So
there
is
probably
another
way
of
looking
into
it,
so
consensus
algorithms.
They
generally
go
hand
in
hand
in
with
how
we
achieve
a
fault
tolerance
in
our
blockchain
networks.
So
when
we
talk
about
fault
tolerance,
let's
imagine
this
to
be
like.
A
Do
I
need
my
blockchain
to
be
just
safeguarding
whatever
is
committed
on
to
block
or
whatever
is
committed
on
into
a
block,
or
do
I
need
my
blockchain
to
be
safeguarding
even
the
transactions
that
are
getting
executed
to
be
validated
before
it
gets
written.
So
that's
the
kind
of
question
or
thing
thought
process
that
will
go
into
it.
A
So
if
your
application
requires
a
design
which
which
you
have
all
the
trusted
parties
and
all
that
you
need,
is
probably
a
record
keeping
of
what
has
happened
in
the
past
and
you
have
established
trust
through
other
means
in
your
Enterprise,
it
probably
makes
sense
for
you
to
even
go
with
fault.
All
I
mean
the
the
one
that
does
not
provide
Byzantine
fault
tolerance
right,
so
you
it's
fine.
So
for
me
the
what
matters
most
is
once
I
create
the
blog
somebody.
A
It
should
not
be
possible
for
somebody
to
break
that
from
that
point,
when
we
go
to
Byzantine,
it's
really
important
for
me
to
know
if
somebody
is
being
malicious
in
the
network,
can
I
stop
them
from
being
malicious?
Can
I
identify
that
scenario
and
if
I
identify
how
do
I
Rectify
my
Pro
I
mean
rectal?
Actually,
how
do
I
stop
that
from
occurring
further?
These
are
the
kind
of
decisions
that
go
into
when
designing,
present
and
fault
tolerance
systems.
A
So
this,
of
course,
do
matter
like,
depending
on
whether
you
want
to
achieve
decentralization
or
scale
you
can
choose
between
these
and
probably
when
I
was
thinking
through
this.
Like
these
things,
one
thing
that
called
out
or
that
stood
out
to
me
in
terms
of
software
factors
that
would
definitely
affect
the
performance
is
in
terms
of
the
flow
in
which
a
block
is
created.
You
might
all
be
wondering
how
exactly
does
blockchain
create
a
block
right?
A
So,
let's,
let's
dissect
it
in
very
simple
terms,
the
things
that
happen
in
a
typical
blockchain
is
you
send
a
transaction
and
somebody
needs
to
execute
it,
and
that
somebody
in
our
case
would
be
a
validator
node
or
a
blockchain
node
that's
receiving
transactions,
and
once
they
execute
it,
they
are
reading
some
State.
They
are
generating
output
state.
So
once
they
generate
the
output
state,
they
are
committing
that
output
State
into
a
structure
like
a
com
like
in
computer
science
terms
or
in
programming
terms.
An
object
is
created
and
that
object
is
a
blocked
object.
A
They
are
putting
the
result
of
execution
into
the
block
structure.
They
are
linking
the
result
to
the
previously
created
block.
That
way.
If
somebody
has
to
be
malicious
and
break
the
blockchain,
they
don't
have
to
just
break
the
current
block,
but
also
block
when
break
the
previous
ones.
So,
just
by
going
into
the
same
process,
I
mean
the
same
process,
it's
possible
for
us
to
follow
these
two
different
orders
right.
These
two
different
flows
so
fabric.
If
you
are
all
familiar
with
fabric,
it
supports
first
for
us
to
execute.
A
In
the
sense
we
send
transactions
to
PR
nodes,
they
execute
the
transaction,
they
generate
the
output
and
then
we
send
it
to
ordering
service
for
ordering.
So
when
it
goes
to
ordering
trans,
you
already
know
the
result,
transaction
results
and
for
after
ordering
every
other
node
they
just
probably
validate.
If
the
whatever
is
ordered
in
your
block
structure
ordering
is
nothing
but
creating
that
block
structure
with
all
the
transactions
they
just
validate
if
those
transactions
were
really
executed
as
they
claim
in
the
result.
A
So
that's
the
validation
that
goes
in,
but
in
probably
other
blockchains
such
as
Basu
or
Sawtooth.
It's
like
before
you
create
that
block
structure.
You
have
to
pre-validate
the
transactions.
You
are
executing
the
results,
then
you're
creating
the
structure
after
execution.
You
are
invalidating
all
the
invalid
transactions,
you
are
just
removing
them
ignoring
them,
and
you
put
the
valid
ones
onto
block
structure.
Then
you
send
that
block
to
everyone
else
in
the
network
when
they
receive
it.
A
It's
their
responsibility
of
receiver
to
verify
if
they
are
receiving
all
the
valid
I
mean
valid
transactions
first,
and
then
they
have
to
re-execute
all
the
transactions
and
figure
out
if
whatever
is
being
sent
to
them,
is
as
per
the
result
given
when
a
block
was
created.
So
there
is
extra
step
like
every
node
is
executing
the
transaction.
Every
node
is
trying
to
replicate
what
one
particular
node
did.
So
this
is
again
another
factor
that
would
influence
your
scalability.
A
Like
going
really
into
the
system
details
level,
you
will
find
the
difference
and
a
quickly
couple
of
more
factors.
Let's
also
talk
about
the
smart
contract
itself,
when
we
all
talk
about
smart
contracts
in
very
simple
terms,
if
I
have
to
say
what
smart
contract
does
it's
a
program,
it's
a
piece
of
code
that
would
probably
instruct
a
blockchain
node,
such
as
validator
or
peer
in
case
of
fabric,
to
do
some
activities
and
that
needs
to
be
triggered
from
a
client
right,
so
client
sends
a
transaction
based
on
that.
A
The
validator
of
the
peer
node
will
request.
Somebody
to
here
is
the
request
coming
into
this
particular
smart
contract.
Can
you
tell
me
what
to
do
now?
The
smart
contract
will
say
yes,
as
per
the
agreement
or
the
hospital.
The
code
that
we
have
come
up
with
I
want
to
read
some
data
that
is
stored
in
this
address
or
I
want
to
read
a
key
from
database,
which
is
referenced
with
key
one
or
key
two
kind
of
a
thing
and
validator
will
read
it
back.
A
The
cons
I
mean
the
smart
contract
will
then
say
hey
as
per
the
rule
I
processed.
Your
input
data
here
is
the
output
for
you
and,
like
validator,
of
the
peer
then
takes
it
to
the
next
steps
of
creating
the
block
structure.
So
just
in
this
process,
if
we
see
there
is
possibility
for
us
to
parallelize
and
make
effective
use
of
the
blockchain
protocol,
how
can
we
do
that?
A
If,
let's
say
if
you
can
design
your
smart
contract
in
a
way
the
read
and
write
operations
that
you're
performing
can
be
done
on
two
different
nodes
or
two
different
keys?
If
you
can
logically
separate
them
through
your
solution
engineering
aspect,
it's
definitely
possible
for
us
to
utilize
the
parallel
transaction
capability
that
some
of
the
underlying
blockchain
protocols
May
provide
we'll
talk
about
quickly
in
coming
slides,
one
of
the
protocol
that
is
available
within
hyperledger,
but
this
is
one
of
the
way
that
is
possible.
A
Now.
I
also
wanted
to
cover
this,
because,
typically,
when
we
go
out
of
hyperledger,
there
are
some
other
blockchains
or
protocols
also
available
and
within
hyperledger.
Also
there
are
protocols
that
do
support
both
kind
of
approaches
you
might
have
all
heard
about.
I
mean
it
ties
in
back
to
what
I
was
again
discussing
in
the
previous
slide,
with
respect
to
the
Keys
and
how
we
parallely
execute
transactions.
This
is
another
way
of
visualizing
it
right.
So
initially
somebody
creates
a
block
or
at
the
end
of
the
day
we
are
all
dealing
with
some
state.
A
So
let's
say
in
utxo
model.
What
typically
happens
is
I
have
an
initial
state
which
needs
to
be
created
as
a
special
transaction,
and
this
initial
state
is
with
me
forever
how
I
spend
it
or
how
I
move
to
next
state
is
up
to
me.
I.
Don't
need
everybody's
consensus
to
make
that
decision.
Of
course,
I
need
to
run
smart
contract,
but
that
smart
contract
can
be
between
exact
parties
that
I
deal
with
I.
Don't
need
entire
network
to
agree
with
me
if
I'm
dealing
with
Deepika,
for
instance,
I
just
need
to
ask
her
hey.
A
Do
you
agree
for
this
move?
If
else
we
both
make
that
state
transition,
because
it
only
concerns
with
both
of
us,
so
that's
kind
of
that
kind
of
allows
us
to
parallely
utilize.
Our
like
perform
multiple
transactions
parallely
through
initializing
them
into
separate
logical
entities
through
our
smart
contract
design,
and
the
other
approach
would
be,
of
course,
the
shared
State
model
which
which
allows
us
to
simplify.
B
Right
so,
first
we'll
just
be
looking
at
fabric
for
those
of
you
who
are
new
to
fabric
The,
Client
First
initiates,
the
transaction
request
sends
it
to
a
peer
which
belongs
to
a
participating
organization.
So
within
the
pure
certain
processes
happen.
Let's
kind
of
look
at
the
zoomed.
In
view
of
that,
so
we
have
a
pure
node.
The
transaction
request
that
is
sent
to
the
pure
initiates
may
be
a
a
query
to
the
DB.
B
Once
we
have
the
information
required
from
the
state
DB,
the
information
is
sent
to
the
chain
code
server
here.
Potentially
the
chain
code
service
itself
could
have
some
inherently
built
latencies
in
terms
of
processing
the
code
that
is
on
it
with
the
supplied
information.
Then,
when
this
information
is
sent
back
to
all
of
the
peers
participate
of
the
participating
nodes,
the
fabric
client
then
sends
it
to
the
hold
on
yeah.
It
then
sends
it
to
the
orderer
node.
B
So
let's
take
a
look
at
what
happens
in
the
orderer,
so
the
orderer
is
not
just
a
single
node
right.
The
ordering
service
consists
of
multiple
order
nodes,
so
these
nodes
again
need
to
communicate
with
each
other,
which
causes
which
results
in
a
communication
overhead,
and
once
that
is
done,
the
orderer
sends
this
information
to
all
of
the
organizations
then
sends
the
block
to
all
of
the
organizations,
and
then
this
is
again
the
validation
happens.
B
So
what
we
saw
just
now
is
where
the
fabric
client
is
the
one
who
is
responsible
for
initiating
the
transactions
between
the
peers
and
then
to
the
orderer.
But
if
we
look
at
an
architecture
like
besu
right,
the
validators
of
on
the
chain
or
the
nodes
are
the
ones
which
are
responsible
for
doing
all
the
validations
among
themselves
and
intercommunicating.
So
what
happens
is
initially?
B
One
requirement
is
that
the
transactions
need
to
be
available
to
each
of
the
validators
in
that
Network.
The
second
thing
is,
let's
say,
two
is
communicating
with
one
and
three,
but
there's
some
kind
of
network
delay
or
lag
which
causes
validator
one
to
be
out
of
sync
with
what
state
the
block
is
in
in
two
and
three.
In
that
case,
a
block
sync
needs
to
happen,
which
again
takes
time.
B
Block
validation
relates
to
how
every
single
validator
in
the
network
needs
to
validate
every
single
block
which
comes
in
and
when
we
say
consensus.
This
again
is
the
communication
overhead,
where
each
of
the
validators
need
to
communicate
with
each
other.
So
so
far,
I
think
we
have
understood
the
various
factors
that
influence
scalability,
and
we
have
also
looked
at
the
architecture
which
currently
exists
in
hyperledger
projects
with
fabric
and
besso,
where
possible
latencies
can
be
introduced.
B
So
we'll
now
kind
of
jump
into
the
main
topic,
which
is
design
patterns
for
scaling
blockchain.
So
the
first
pattern
that
we'll
be
talking
about
is
single
chain.
Sharding
sharding
is
a
concept
that
is
kind
of
dear
to
all
Engineers.
It
started
with
database
sharding,
where,
instead
of
storing
all
of
the
data
on
a
single
database,
we
decided
to
partition
it
horizontally,
maybe
into
shards
into
logical
partitions
call
shards,
which
are
then
stored
on
two
different
physical
charts
there
in
database
sharding.
B
What
we
did
is
split
the
data
itself
Health
here
in
single
chain
sharding.
What
we're
doing
is,
let's
say
we
have
maybe
10
000
validators
in
the
network
and
100
blocks
that
require
validation.
Now
we
Shard
or
partition
the
nodes
itself,
so
we
have
10
000
nodes.
We
partition
them
into
groups
of
100
nodes
each
and
each
of
these
groups
is
called
as
a
committee.
Now,
what
we
do
is
we
assign
the
first
block
among
the
hundred
blocks
to
be
validated
by
the
first
committee,
so
the
first
block
is
validated
by
100
nodes.
B
B
What
happens
here
is
now
after,
let's
say
committee,
one
validates
block
one
and
what
they
do
then
is
publish
the
signature,
their
signatures,
that
they
have
in
fact
validated
onto
the
network.
Now
what
all
the
other
nodes
need
to
do
is
instead
of
validating
100
full
blocks
which
contain
all
of
the
transaction
history
of
that
entire
blockchain.
They
just
need
to
verify
the
10
000
signatures
that
are
have
come
in
from
each
of
the
validators,
and
this
is
a
significantly
easier
or
a
lightweight
job
to
do
than
validating
the
entire
block
itself
right.
B
Let's
say
the
computational
resource
power,
whatever
increases
by
2x,
then
what
happens
is
they
are
able
to
validate
even
block
sizes
which
are
two
times
the
size
and
they
are
also
going
to
be
able
to
validate
instead
of
having
just
say,
100
Committees,
of
each
having
100
100
nodes.
We
can
now
have
200
right
because
the
computation
power
has
increased
by
two.
So
if
you
look
at
both
of
it
now,
the
sharded
chains
capacity
has
increased
in
from
two
to
four
right.
B
So
that
is
essentially
what
I'm
trying
to
say
there
computational
capacity
of
a
single
node.
If
we
call
it
we
go
of
C,
then
the
sharded
node
capacity
it
becomes
quadratic,
which
is
C
square,
but
there
are
again
limitations
to
it.
Quadratic
sharding
isn't
exponential.
There
is
a
threshold
to
it,
but
we
won't
get
into
that
in
the
interest
of
time.
B
The
problem
here
is
the
security
you
know,
because
the
entire
the
you
know,
this
entire
data
is
split
into
shards
and
sent
into
multiple
blocks
blockchains,
but
now
that
the
blockchains
are
smaller,
if
any
attacker
kind
of
messes
up
the
first
blockchain,
then
the
result
will
affect
all
of
the
shards
right,
so
the
amount
of
so
basically
the
attacker
only
needs
the
first
chain
to
go
bad
for
the
entire
data
to
go
bad.
So
that's
where
the
problem
of
security
comes
in,
which
is
why
we
spoke
about
single
chain
sharding.
B
This
was
on
chain
now,
if
we
look
at
some
or
of
chain
transaction
processing,
I
already
mentioned
trusted
execution,
environment
and
there's
also
the
concept
of
State
channels,
which
Arun
will
cover
with
the
example
of
an
existing
hyperledger
Labs
project.
There's
this
concept
of
side
chain,
where
we
Peg
one
of
the
chains
to
the
main
chain-
and
this
is
like
a
two-way
pegging.
So
what
happens
here?
Is
we
move
assets
from
the
main
chain
to
the
side
chain?
B
Let's
say:
there's
some
I
said
some
transaction
that
needs
to
execute
on
the
main
chain,
but
there
is
some
latency
or
some
delays
over
there.
So
what
we
do
is
we
lock
the
assets
on
the
main
chain
and
then
the
bridge
is
what
is
used
to
actually
transfer
the
assets
to
the
site,
to
do
the
Locking
essentially
and
then
on
the
side
chain.
We
generate
equivalent
amount
of
assets
on
what
using
whatever
asset
generation
or
is
done
on
the
side
chain,
and
then
once
that
is
done,
we
spend
that
asset
and
unlock.
B
We
spend
that
asset
on
the
side
chain
and
unlock
this
exact
amount
on
the
main
chain.
So
that
way,
the
work
that
the
assets
that
needed
to
be
minted
have
been
done
on
the
side
chain
and
nothing.
The
the
entire
transaction
has
been
validated
on
the
side
chain
and
the
main
Chain's,
latency
or
delays
have
not
affected
the
overall
process
over
to
iron
for
optimistic
rollups.
A
So
so
far
we
have
been
seeing
different
techniques
of
scaling
in
terms
of
utilizing
some
capabilities
in
addition
to
blockchain
so
I'm
going
to
continue
the
same,
but
in
this
technique
instead
of
utilizing
additional
capability.
Let's
imagine
that
what
if
clients
can
be
more
intelligent,
what
if
person,
who
is
going
to
send
transaction
to
blockchain
can
do
something
more
than
what
they
currently
do.
So
that's
where
the
rollups
technique
come
into
picture.
So
what
do
Roll-Ups
do
they
process
some
transactions
outside
the
blockchain?
So
let's
say
in
this
case
optimistic
roll
up.
A
It's
like
we
have
an.
Let's
say
there
are
transactions
that
are
coming
in,
so
we
want
to
batch
them
together
and
then
put
them
onto
blockchain.
That's
the
straightforward
sentence
of
definition
of
what
this
roll
up
optimistic,
Roll
Up
is.
So
what
exactly
happens
is
we
have
an
operator
who
would
be
monitoring
for
incoming
transactions?
A
So
that
is
where
the
challenge
approach
also
needs
to
be
there.
So
challenge
approach
is
like,
if
you
don't
abide
by
or
if
you
don't
agree
to
this
result,
you
do
have
a
period
where
you
can
go
and
say:
hey,
I,
don't
agree
to
your
results.
Let
me
challenge
you:
let's
reprocess
this,
let's
see
who
is
correct
and
whoever
is
correct,
they've
been
and
either
block
gets
accepted
or
rejected.
A
Similarly,
this
is
one
of
the
interesting
concept
that
almost
everybody
speaks
nowadays
in
very
simple
terms,
let
me
try
to
break
it.
It's
another
roll
up
technique
where
you
do
something
outside
the
client
becomes
more
powerful.
They
do
then
commit
the
information
onto
the
actual
blockchain,
but
this
time
instead
of
directly
batching
and
adding
they
do
some
more
intelligence,
they
add
some
more
intelligence.
What
exactly
are
they
adding
this
time
the
operator
or
whoever
is
adding
the
transaction?
They
would
be
holding
additional
responsibility.
They
cannot
be
blind
like
they
cannot.
It
is.
A
A
They'll,
probably
stop
me
come
from
coming
in.
So
how
can
we
achieve
this
using
zero
knowledge?
That's
that's
the
challenge
right.
So
let's
say
Indian
government
would
have
issued
me
a
passport.
So
that's
my
proof.
I'll!
Take
that
proof.
I'll
add
it
on
to
blockchain
for
extra
security
and
that
proof
cannot
derive
any
other
information
other
than
saying
that
I
hold
a
passport,
so
that's
kind
of
zero.
That
is
the
kind
of
zero
knowledge.
A
So
there
is
proof
of
ownership,
and
there
is
proof
that
it
is
issued
by
the
proper
correct
entity,
and
then
there
is
no
leakage
of
information
other
than
what
actually
I'm
trying
to
say.
So
the
same
technique
is
applied
in
rollup
when
I
apply
this
technique
onto
blockchain,
I,
add
the
proof
onto
blockchain
and
that
proof-
and
you
probably
might
know
like
ZK
snark-
have
heard
about
JK
snarks.
A
So
we'll
probably
also
quickly
talk
about
current
projects
that
I
mean
current
state
within
hyperledger.
What
what
is
available?
We
spoke
about
a
lot.
Many
Concepts
are
these
available,
or
are
this
just
Concepts
that
we
are
talking
about?
So,
let's,
let's
break
them
by
using
two
examples.
I
want
to
quickly
talk
about
in
the
previous
one
of
the
slides
I
spoke
about
the
way
somebody
can
design
the
smart
contract
so
quickly.
Taking
an
example
from
the
way
we
write
any
transaction
processors
in
Sawtooth.
It
is
State
address
based
Sawtooth
project
like
when.
A
If
you
remember
how
to
write
the
transaction
I
mean
your
smart
contract,
you
basically
have
to
arrive
at
the
addresses
where
you
need
to
store
your
data,
and
based
on
that,
you
will
submit
your
transaction,
and
transaction
processor
will
execute
it.
Validator
will
try
to
parallelize
if
there
is
no
conflict
in
your
addresses.
So
what
it
allows
is,
let's
say:
if
you
you
can
represent
your
data
in
35
byte
string,
then
imagine
that
first
few
bytes
can
be
representing
a
namespace.
So
that
way
you
are
right
away
delegating
if
anything
comes
from
another
namespace.
A
These
two
can
be
executed
parallely
because
my
state
input
state,
so
smart
contract
is
making
State
transition
from
one
main
input
state
to
another
state,
so
my
state
would
still
remain
the
same.
Even
if
I
execute
two
transactions
parallely,
they
don't
have
any
conflicts
and
my
block
has
high
possibility
of
getting
accepted.
There
is
no
conflicts
that
may
come
in.
There
is
parallelization
that
comes
into
picture,
so
similarly
I
mean
that
is
achieved
in
sought
to
choosing
these
two
parameters.
Basically,
in
the
client
transaction
that
you
sign,
you
are
adding
input
and
output
transactions.
A
B
B
A
signed
message
which
says
I
owe
you
one
dollar
now
today
and
then
tomorrow,
I'll
say
the
same
thing:
I
owe
you
a
dollar
tomorrow
and
so
on.
So
at
the
end
of
the
week,
I
have
I
have
seven
Dollars
around
you
know
I
owe
around
seven
dollars
and
he
wants
to
kind
of
cash
out.
So
what
he
does
is
sends
another
transaction,
a
dozen
other
transaction
of
closing
the
channel
on
onto
the
blockchain.
B
So
when
he
does
that
the
the
final
result
of
seven
dollars
will
the
smart
contract
which
exists
on
the
blockchain
will
transfer
the
seven
dollars
to
him
now,
there's
also
this
concept
of
hashed
time
block
transaction,
which
is
at
the
end
of
the
week.
If
Arun
doesn't
initiate
the
closed
transaction
request,
then
all
of
the
transaction
messages
the
signed
messages
that
have
been
sent
on
the
state
channel
will
be
invalidated.
So
that
is
essentially
the
concept
of
State
channels.
A
So
this
session
we
wanted
to
cover
the
aspects
that
would
influence
the
scalability.
So
this
does
not
cover
the
result
of
execution
of
any
blockchain
as
such,
but
it
does
improve
the
performance,
for
instance,
the
state
channels
concept
that
was
just
spoken
about.
It
helps
us
in
let's
say:
if
only
two
parties
are
interacting,
they
can
interact
as
many
transactions
as
they
want.
Just
like
any
other
streaming
process,
they
can
exchange
the
data
and
perform
transactions
just
make
sure
that
every
transactions
that
is
sent
is
signed.
A
So
this
will,
of
course
improve
because
we
are
removing
the
validate
phase
from
each
transaction
and
validation
phase
in
order
execute
validate
that
I
initially
spoke
about.
That
validation
is
happening
just
once
for
for
a
period
for
a
state
Channel,
and
this
concept
will
definitely
help
and
another
thing
like
one
more
cool
Factor
about
this.
Is
it
helps
us
in
abstracting
the
blockchain
itself
right
so
because
I'm,
not
tying
myself
to
a
particular
blockchain
I,
can
use
any
protocol
of
my
choice.
So
State
channel
is
in
independent
of
what
blockchain
I'm
running
it
on.
A
Yep,
so
there
is
lot
that
happens
within
hyperledger,
Community
I
know
it's
end
of
our
schedule,
but
please
do
join
the
calls.
There
is
a
scalability
I
mean
working
group
as
well.
Where
many
topics
like
this
and
there
is
there
used
to
be
architecture
working
group,
all
of
them
they
do
run
weekly
meetings
or
monthly
meetings.
You
can
learn
more
about
and
meet
the
people
who
are
building
such
Solutions.
A
Side,
Channel
out
of
the
box.
There
is
no
such
implementation.
There
is
one
fabric,
smart,
client,
it's
not
exactly
a
side,
Channel
concept,
but
it
allows
you
to
do
intelligent
transactions
that
would
deal
with
Channel
concept
within
Fabric
in
a
different
way
where
in
which
you
can
Define
the
workflow
that
has
dependency
across
channels.
It's
not
like
straightforward
implementation
of
side,
the
concept
that
we
spoke,
but
it's
kind
of
implicitly
giving
you
that
feature
that
capability
yeah
this
each
channel
is
kind
of
like
dependent
on
each
other.
A
Yes,
please,
oh
okay,
so
so
when
we
design
the
smart
contract,
it's
really
important
from
for
us
generally,
people
start
thinking
in
terms
of
business
workflow.
They
say,
as
per
my
transaction
I
have
to
follow
this
flow.
Basically
person
a
needs
to
do
ABC
task
person.
B
needs
to
do
XYZ
task,
and
only
when
both
persons
have
done.
A
So
that's
the
Elegance
that
I
was
talking
about
as
part
in
the
conclusion,
so
by
not
just
on
the
solution
Side
by
also
spending
some
time
in
terms
of
the
scaling
factors
that
we
just
discussed.
If
we
can
bring
those
factors
in
into
our
designing,
it
makes
that
process
much
smoother.
It
helps
us
in
extracting
all
possible
capability
that
a
particular
blockchain
protocol
has
to
offer.