►
From YouTube: The Perun Framework: Towards Blockchain Scalability & Interoperability - Matthias Geihs, PolyCrypt
Description
The Perun Framework: Towards Blockchain Scalability & Interoperability - Matthias Geihs, PolyCrypt GmbH
The Perun Framework is a toolkit for enabling blockchain scalability and interoperability through state channel technology, which is based on a series of renowned research papers. In this talk we want to give an overview of the Framework and how it can be used. We also want to highlight recent developments of the project and give an outlook on what's to come. Recent developments include the integration of Ethereum, Cosmos, and Polkadot blockchains. The integration of Dfinity and Fabric blockchains is in development. This means that Perun state channels can be used on all of these networks while the modular design of the Framework allows writing applications that are easy to port from one network to the other. We recently demonstrated cross-chain capabilities of Perun channels for the first time and are working on enabling this feature for all supported blockchains. Furthermore, we are looking to apply Perun channels in the context of Hyperledger Aries for enabling secure and trustless payments for verifiable credentials.
Sessions Details & Slides (if available): https://sched.co/14H5L
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
Then
thanks
for
coming
so
this
talk
will
be
about
the
parent
framework,
which
is
you
can
see
as
a
toolkit
for
blockchain
scalability,
for
increasing
the
transaction
throughput
and
for
enabling
also
transactions
across
blockchains,
for
example,
regarding
blockchain
cross
chain
swaps.
Peroon
is
a
hyper
lateral,
Labs
project.
A
A
So
we
see,
for
example,
in
the
case
of
ethereum
Bitcoin,
we
can
do
globally
between
10
and
20
transactions
per
second,
and
this
is
something
that
we
wanted
to
address
with.
The
research
initially
turns
out
that
the
same
technology
is
also
capable
of
solving
a
different
problem
that
arised
more
recently,
so
we
see
more
and
more
different
blockchain
networks
coming
up
the
assets
are
fragmented,
the
user
are
fragmented
across
the
networks
and
yeah.
There's,
as
you
know,
need
for
interoperability
Solutions,
so
that
assets,
for
example,
from
different
network
can
be
exchanged
against
each
other.
A
So
how
does
the
protocol
work
so
this?
As
I
said?
It
stems
from
a
research
project,
and
this
slide
should
give
you
a
very
rough
idea
how
it
works
on
a
protocol
level.
The
basic
idea
is
that
we
try
to
push
as
many
of
the
transactions
off
the
chain
so
that
there
is
no
on-chain
transaction
costs
and
no
on-chain
limitations
and
only
in
the
case
of
an
off-chain
dispute.
A
So
if
we
run
into
a
dispute
with
other
parties
that
we
are
interacting
with,
then
we
use
a
Smart
contract
to
resolve
the
disputes
and
The.
Crucial
point
is
that
we
don't
really
want
to
sacrifice
any
security
guarantees
that
we
typically
have.
So
we
still
want
to
do
that
in
a
trustless
way
where
we
don't
need
to
rely
on
a
trusted
intermediary.
A
So
here
you
can
see
the
typical
transactions
key
scheme
when
working
with
a
blockchain
and
for
us
it
looks
a
little
bit
like
this.
So
we
have
this
off
chain
protocol
for
entering
the
off-chain
system.
We
do
maybe
a
few
online
transactions
for
exiting
the
system
or
for
disputing,
but
as
long
as
we're
in
an
exit,
an
optimistic
execution,
we
can
do
transactions
across
the
parties
in
this
in
the
opt-in
system
without
any
on-train
interaction.
A
A
A
So
yeah,
as
I
mentioned,
we
started
I
think
the
research
started
actually
back
in
2016
or
something
like
that,
and
then
it
always
takes
time
to
formulate
the
ideas
to
write
it
down.
And
finally,
the
papers
got
published
in
the
middle
of
2018,
beginning
of
2019
I,
think
at
well-renowned,
computer
security
conferences,
eurocrypt,
acmccs,
I,
triple
e
s
p,
and
that
was
focusing
on
building
State
Channel
networks.
A
So
we
cannot
just
have
one
state
channel
that
has
a
fixed
set
of
parties,
but
we
can
actually
build
State
channels
on
top
of
stage
channels
in
order
to
build,
for
example,
a
payment
Network
where
the
creation
of
new
state
channels
doesn't
require
on-chain
interactions,
and
that's
also
what
these
papers
focus
on,
and
on
top
of
that
you
can
actually
run
smart
contracts.
Inside
such
a
such
a
stage,
Channel
and
yeah
other
Protocols
are
in
these
papers.
A
Then
we
wanted
to
build
out
the
protocols
into
a
library
and
in
the
middle
of
2018
we
got
some
funding
from
the
ethereum
foundation,
which
basically
kick-started
this
endeavor
of
making
some
software
product.
All
of
it
also
early
on,
we
got
interest
from
company
Bosch.
Unfortunately,
a
colleague
from
Bosch
couldn't
be
here
today
to
to
Visa
reasons
but
yeah.
They
engage
with
us
already,
I
think
also
in
the
middle
of
2018
and
then
beginning
of
2019.
A
We
also,
then,
in
the
end
of
2019,
released
the
first
version
of
the
library
yeah
and
since
then,
it's
publicly
available
on
GitHub
I
will
point
to
the
repositories.
At
the
end,
we
continue
to
develop
new
features.
Basically,
we
just
started
with
simple
payment
channels.
In
the
beginning,
and
by
by
today
we
can
do
payment
Channel
networks.
We
can
also
do
arbitrary
execution
logic
in
the
payment
channel
in
an
in
a
state
Channel.
A
We
have
cross
chain
functionality
by
now,
so
we
continue
to
add
new
features,
but
on
an
organization
level.
At
some
point,
it
was
suggested
by
Bosch
that
we
joined
the
hyperledger
foundation
as
a
Labs
project,
because
it
gives
us
a
common
neutral
ground
to
work
together
without
having
the
problem
of
who
owns
what
it's
just
open
source
and
there's.
No,
we
don't
have
to
decide
if
the
repository
lies
at
the
Bosch
org
or
the
fully
Crypt
orb,
which
is
the
company
name
and
so
on.
A
Yeah
and,
as
I
already
hinted
the
company.
Until
that
point
it
was
still
located
at
the
University
and
then
at
the
end
of
2020.
We
founded
the
company
called
pulley
group,
which
is
still
tightly
located
related
to
the
university
group
of
Professor
Sebastian
Faust.
We
still
have
offices
in
the
University,
so
that's
also
quite
nice
yeah.
A
This
year
a
focus
was
really
on
the
application
side,
so
we
are
kind
of
a
technology
provider.
But
of
course,
in
the
end,
technology
is
only
useful
if
you
have
good
applications
for
it
and
one
instance
of
that
came
through
a
connection
with
the
polka
dot
space.
So
a
unit
is
a
startup
company
which
also
received
some
funding
from
polkadot
and
they're,
focusing
on
focusing
on
providing
gaming
based,
blockchain
applications
and
making
it
easy
easy
for
game
developers
to
use
blockchain,
but
they
hit
a
limitation
in
terms
of
how
far
they
could
scale
the
application.
A
Yeah
and
recently
we
also
published
an
integration
for
hyperledger
fabric
and
are
also
now
developing
an
integration
for
cardano,
which
is
a
different
type
of
blockchain.
It's
utxo
base,
so
quite
a
different
model,
but
it
looks
like
our
abstractions
and
our
protocols
also
work
for
yeah
for
utxo
based
blockchains,
with
some
smart
contract
functionality.
A
So
the
prerequisite
for
using
peroon
is
yeah
independent
of
how
we
implement
it.
When
you
want
to
use
it,
you
have
to
deploy
a
smart
contract
on
a
chosen
blockchain,
so
we
are
compatible
with
different
types
of
blockchains
but
independent,
which
blockchain
it
is.
You
have
to
deploy.
Peru
smart,
smart
contract
with
a
certain
functionality
for
dispute
resolution
by
the
way
is
to
sound
alright
or
should
I
yeah.
All
right,
I
have
a
small
Echo,
but
it's
fine
so
and
then
the
next
thing
is
okay.
We
we
need
an
option.
A
We
have
an
option
agreement
protocol
for
two
parties
to
agree
that
they
want
to
engage
in
an
off-chain
interaction
so
once
they
have
that
opt-in
agreement.
Basically
by
signing
the
channel
parameters,
they
can
then
open
the
channel
by
funding
into
this
globally
unique
Channel
ID,
making
a
fun
transaction
into
the
smart
contract.
And
now
these
funds,
these
assets,
will
be
reserved
for
that
particular
Channel,
where
only
these
two
parties
have
access
to.
A
A
Basically,
Alice
can
say:
I
want
to
make
a
transfer
payment
transfer
to
Bob
of
five
tokens.
So
Bob
has
balance
10
afterwards
and
Alice
has
balance
zero.
They
both
sign
the
new
state
and
since
they
both
signed
it,
the
smart
contract
and
later
realized.
Okay.
Now
this
is
the
state
with
the
highest
version
number,
which
has
signatures
from
all
parties
in
the
channel.
So
I
will
accept
it
later.
A
A
A
So
in
that
case
we
run
into
a
dispute,
and
now
we
have
to
decide
which
is
the
most
recent
state
that
was
agreed
upon,
and
basically
this
is
a
challenge
response
protocol
with
some
timeout
logic
and
the
smart
contract.
Yeah
supports
this,
and
as
long
as
the
parties
are
online,
that's
that's
a
necessary
requirement.
They
will
basically
be
able
to
register
the
most
recent
state
that
everybody
has
agreed
on
and
the
channel
will
then
be
settled.
A
So,
as
I
said,
we
also
have
different
features
that
we
can
now
enable
in
such
repairing
Channel.
We
can
do
swaps
inside
the
channel.
We
can
do
other
transaction
Logics
so
that
one
transaction
depends
on
the
next
transaction
and
in
case
one
party
may
be
signs
one,
the
first
transaction,
but
not
the
second
one.
We
have
mechanism
that
if
these
are
dependent
on
each
other,
we
can
enforce
the
transaction
on
the
smart
contract.
A
A
Another
thing
that
we
can
do.
We
can
also
have
Alice
on
the
left
put
assets
from
from
a
different
blockchain
into
the
channel,
then
Bob.
So
maybe
Alice
wants
to
trade
ether
against
metric
on
from
Bob
on
polygon,
and
this
method
also
works.
If
you
have
two
blockchain
two
blockchains
with
two
smart
contracts
and
the
basic
idea
is
that
as
long
as
you
keep
these
two
things
synchronized
with
each
other
similar
a
little
bit
to
how
a
hash
time
log
works,
you
can
basically
fund
the
Channel
with
assets
from
different
from
different
blockchains.
A
All
of
that
on
most
of
that
I
should
say,
is
written
in
the
papers.
We
have
some
new
protocols,
especially
the
papers,
we're
focusing
on
more
on
a
single
blockchain.
We
now
have
some
new
protocols
with
the
multi-chain
functionality,
but
yeah
most
of
the
protocols
are
formally
analyzed
peer-reviewed
and,
as
I
mentioned,
we
now
also
have
a
cross
chain
support.
A
Yeah,
so
from
an
implementation
perspective,
how
does
the
framework
look
like
so
at
the
core?
We
have
the
goproon
library
and
you
can
see
that
as
an
SDK
for
using
that
technology.
So
it
has
an
implementation
of
the
protocols
at
its
core
and
then
the
implementation
is
reading
written
against
a
set
of
abstract
interfaces.
So
we
have
a
block,
blockchain
abstraction
and
you
can
basically
plug
in
your
favorite
blockchain
module.
If
you
implement
it
and
then
the
protocol
will
run
against
this
blockchain.
A
Currently
we
have
with
different
features,
enabled
we
have
plugins
for
ethereum,
Cosmos,
polka,
dot
and
fabric.
We
are
working
on
one
for
cardano
and
on
one
for
the
dfinity
internet
computer
and
a
similar
approach.
We
took
also
for
the
peer-to-peer
communication
for
the
persistence.
So
in
order
to
store
the
state
and
restore
clients,
we
can
also
have
a
modularized
approach
so
that
you
can
plug
in
your
favorite
database,
your
favorite
network
message
broker
and
so
on.
A
A
A
Otherwise,
if
you
have
a
light
client
or
an
embedded
device
client,
which
is
something
that
Bosch's
specialty
is
interested
in,
you
can
use
a
pair
of
node,
which
is
kind
of
yeah,
provides
some
additional
services
and
a
simplified
user
interface
for
light.
Clients
yeah,
and
you
can
all
find
all
these
repositories.
When
you
go
to
hyperledger
Labs
search
for
Peru,
but
as
I
said,
I
will
also
link
to
them
later.
A
All
right
so
a
little
bit
more
detail.
I
think
I
should
have
time
to
show
this.
So
this
is
the
architecture
of
the
library
of
the
core
library,
and
here
you
can
see
exactly
what
I
just
explained.
So
we
have
the
core
client
protocols
and
they
work
against
a
certain
set
of
interfaces.
This
is
the
blockchain
abstraction
which
has
an
abstraction
for
wallets
accounts.
A
This
is
the
channel
package
is
the
abstraction
for
interacting,
basically
a
blockchain
middle
middleware
layer
where
we
can.
Basically,
if
the
client
wants
to
make
an
online
transaction,
it
will
tell
that
to
the
channel
package
and
the
channel
package
will
translate
that
by
corresponding
chain
specific
implementation
into
an
on-chain
call-
and
this
also
includes
event
subscriptions
and
similar
for
the
ym
package.
We
have
some
abstraction
for
inter-client
messaging,
for
persistence,
as
I
just
mentioned,
and
you
can
basically
then
plug
in
your
favorite
implementation
of
that.
A
And
to
give
you
a
little
bit
of
a
better
idea,
how
that
actually
looks
like
in
terms
of
so
the
library
is
written
in
goal,
and
this
is
a
simplified
version
of
the
go
interfaces.
But
this
is
roughly
how
it
looks
like
so
the
wallet
is
a
type
that
can
given
an
address
can
unlock
an
account.
An
account
is
something
that
can
generate
a
signature
for
a
certain
byte
array.
A
Then
we
need
some
functionality
for
marshalling
and
unmarshalling
for
sending
it
over
the
network
and
of
course,
we
also
need
the
capability
of
verifying
signatures.
So
that's
the
account
abstraction
and
the
latter.
Abstraction
is
on
the
right
hand,
side.
So,
for
opening
the
channel
we
use
the
funder
abstraction,
which
basically
must
make
sure.
So
an
implementation
must
ensure
that
when
you
call
fund,
you
specify
the
channel
parameters
that
has
been
agreed
upon
in
the
opening
protocol,
the
initial
State
and
then
the
funding
transaction
should
make
sure
that
the
funding
is
done
into
the
on-chain
contract.
A
So
we
have
a
method
for
registering
a
dispute,
so
we
provide
the
parameters
which
is
fixed.
We
provide
the
most
recent
State
and
we
provide
signatures
from
all
participants
on
the
most
recent
State
and
then
the
implementation
should
make
sure
that
this
dispute
is
registered
and
we
have
a
specification
basically
how
the
smart
contract
implementation
should
look
like
and
then
for
withdrawal.
A
Once
we
have
registered
a
channel,
we
can
also
re-register
in
case
somebody
registered
in
all
states.
So
this
is
a
function
that
could
potentially
be
called
multiple
times,
but
the
client
will
know
from
the
protocol,
at
which
point
we
are
able
to
conclude
the
dispute
and
then
we
can
finally
withdraw
funds
from
yeah
from
the
channel
back
into
the
account
and,
of
course,
for
all
of
that
it
is
often
useful
and
necessary
for
the
client
logic
to
understand
to
consuming
events
from
the
blockchain,
and
for
that
we
have
the
event
subscription
logic.
A
It's
very
crucial
that,
from
the
parameters
we
can
derive
a
unique
ID
for
a
channel.
It
must
be
globally
unique
because
and
that
this
is
basically
a
hash
of
the
participants
and
determines
who
can
in
a
way
who
can
access
the
channel.
And
if
you
have
a
duplicate
ID,
you
would
actually
by
mistake
fund
yeah
in
a
potentially
distributive
funds
to
the
whole
to
the
wrong
persons.
A
So
it's
very
crucial
that
this
is
implemented
in
a
way
that
you
get
a
globally
unique
ID
for
each
Channel
and
in
practice
this
works
by
hashing
or
the
fixed
parameter
parameters
into
the
channel
like
yeah,
the
participant,
especially
the
addresses,
but
also
by
choosing
a
shared
random
nonce,
so
that
yeah,
you
are
guaranteed
to
get
a
unique
value.
Out
of
that.
That
could
not
be
predicted
by
others
yeah
and
then,
of
course,
we
need
some
functionality
for
signing
a
state
and
for
verifying
a
state,
and
that
includes
serialization
of
the
state.
A
So
we
need
some
functionality,
that
of
serialization
so
that
the
blockchain
can
basically
deserialize
the
state.
Read
it
and
also
the
blockchain
must
be
able,
with
this
block
stream,
specific
cryptographic.
Signature
scheme
to
verify
the
states
on
chain,
so
these
things
are
also
chain
specific,
because
different
chains
have
different
serialization
mechanisms
and
different
cryptographic.
Algorithms,
and
these
are
some
of
the
basic
components
that
we
need
on
chain
to
make.
This
work.
A
A
The
messaging
bars
are
the
type
of
funder,
the
type
of
adjudicator
which
wallet
is
being
used
and
The
Watcher,
which
is
basically
the
service
for
consuming
on
genuines.
It
can
also
be
an
external
service.
That
is
why
we
moved
it
out
of
the
adjudicator
at
some
point
yeah.
Then
we
need
to
start
some
some
handlers
so
that
we
can
receive
requests
from
other
clients
and
consume
blockchain
events
and
yeah.
A
Then,
for
creating
setting
up
a
new
channel,
we
propose
we
created
a
ledger
Channel
proposal,
which
is
a
channel
that
sits
directly
on
layer
one.
We
can
also
create
virtual
channels
which
sit
on
top
of
other
channels,
but
the
most
simple
type
is
the
letter
Channel.
We
specify
the
parameters
like
the
initial
balances,
which
asset
types
and
so
on,
and
then
we
run
the
channel
proposal
protocol,
including
the
funding
and
so
on
by
calling
proposed
Channel.
And
if
that
doesn't
error,
we
have
a
new
channel
that
we
can
work
with.
A
Yeah
and
once
we
have
a
channel
object,
we
can
now
Define
and
update
logic,
so
that
works
as
follows.
We
have
a
function
that
gets
its
input
appointed
to
a
general
State,
and
then
we
can
call
on
the
channel
object.
We
call
update
by
with
a
parameter
of
that
function
and
once
the
function
returns
update
by
returns,
we
are
ensured
that
this
off
chain
update,
has
been
enforced,
has
been
agreed
by
all
parties.
A
If
we
get
an
error,
so,
for
example,
if
one
party
doesn't
reply,
then
we
have
a
dispute
case
and
settle.
Is
the
final
operation
from
a
user
perspective
from
a
developer's
perspective
that
will
use
our
library
and
settle
will
make
sure
that
either
in
the
dispute
case
we
run
the
dispute
protocol
or
in
the
optimistic
case
we
will
just
conclude
the
channel
and
withdraw
the
funds.
A
A
Okay
and
yeah,
which
applications
could
you
think
of
so
what
would
be
potential
use
cases?
One
potential
use
case
that
Bosch
is
particularly
looking
at
is
building
this
technology
in
embedded
devices,
for
example,
to
enable
machine
to
machine
payments.
So
here
the
example
is
shown
for
making
payments
to
an
electric
charging
station.
A
Maybe
the
user
would
have
a
cell
phone
that
provides
so
so
maybe
the
car
itself,
the
embedded
device,
doesn't
have
a
blockchain
connection,
but
the
user
would
have
a
cell
phone
which
communicates
with
the
embedded
device
and
thereby
enables
blockchain
connectivity
while
still
enabling
the
car
to
do
micropayments,
maybe
for
each
kilowatt
hour
or
something
like
that.
You
can
do
an
individual
payment
without
any
delays.
A
And
then
once
the
charging
process
is
finished,
you
settle
at
some
point
later
against
the
blockchain
when
there's
connectivity
or
yeah,
basically
when
the
yeah,
when,
when
the
blockchain
so
yeah
as
long
as
you
have
the
off
chain
guarantee,
you
could
do
the
settlement
anytime,
you
like.
Basically,
so
we
maybe
you
could
even
already
leave
the
charging
station
and
the
charging
station
would
take
care
of
the
settlement
or
something
like
that.
A
Yeah
then
I
mentioned
the
collaboration
with
ayuna,
who
is
a
gaming
platform
provider.
It's
also
a
startup,
so
they
are
also
in
the
early
phases,
but
their
vision
is
that
they
have
a
gaming
developer
platform
which
is
integrated
with
unity
or
Unreal
Engine
I
think.
Currently
they
focus
on
Unity
and
they
want
to
make
it
easy
for
game
developers
to
yeah
to
write
an
application
that
uses
blockchain
without
the
complexity
and
they
were
running
into
the
problem.
A
So
they
basically
already
had
a
scaling
solution
based
on
a
trusted
execution
environment,
but
they
couldn't
go
below
latency
of
500
milliseconds
or
something
like
that,
and
since
Peru
State
channels
appear
to
peer,
you
have
almost
no
noticeable
latency.
It's
like
running
a
normal
game
and
I.
Don't
know
if
I
have
time,
probably
not,
but
we
also
have
a
demo.
We
will
publish
it
soon,
where
there's
a
simple
tic-tac-toe
game
played
in
the
state
Channel.
You
can
really
see.
There's
there's,
basically,
no,
no
latent,
no
noticeable
latency.
A
Yeah
then
we
have
the
cross
chain
use
cases.
So
since
we
have
integrated
different
blockchains,
we
can
also
enable
and
the
protocols
are
capable
of
that
we
can
enable
cross-chain
swaps.
So,
for
example,
if
you
think
I
hinted
at
this
use
case
earlier,
if
you
think
one
client
has
ether
and
he
wants
to
swap
it
against
the
pocket
tokens,
he
can
connect
with
the
liquidity
provider
and
do
a
trustless
token
swap
them.
So
there's
no
trust
involved.
A
There's
no
trusted
intermediary
necessary.
You
can
swap
tokens
against
each
other
and
either
the
swap
happens
or
not,
and
you
can
even
do
it
thousands
of
times.
So
maybe,
if
you
think
of
two
big
banks
that
want
to
do
a
lot
of
swaps
between
each
other
before
they
settle,
that
could
be
a
viable
application
here.
A
At
the
moment,
I
should
note
we
only
support
swaps
between
two
networks
that
are
of
the
same
type,
so
it
could
be
two
ethereum
based
Networks.
This
specific
use
case
ethereum
to
polka
dot,
is
something
that
requires
the
same
cryptographic
mechanisms
to
be
available
on
both
but
chains
the
same,
the
same
serialization
to
be
available,
and
that
just
requires
more
work
on
the
implementation
side.
A
So
that's
something.
Currently,
we
focus
on
evm
to
evm
or
fabric
to
fabric
or
yeah
same
types
of
networks
on
both
sides
yeah
another
nice
use
case-
that
is
in
the
realm
of
decentralized
identities.
So
here
we
look
at
an
example
where
there's
an
authority,
maybe
a
notary
who
provides
a
certificate
service
and
once
expects
some
payment,
and
now
maybe
there's
not
enough
trust
that
the
authority
provides
the
wants
to
provide
the
certificate
for
the
payment.
A
So
there's
no
risk
involved
in
that,
because
it's
now
an
atomic
transaction
that
we
can
program
into
the
channel,
but
it's
still
very
efficient.
So
we
can
do
thousands
of
transactions
of
that
type
between
entered
two
entities
and
the
middle
term
goal
is
that
we
actually
want.
We
have
a
proof
of
concept
for
that
ready
and
we're
looking
at
integrating
that
with
the
hyperledger
areas.
Protocols.
A
You
can
find
more
about
the
perum
project
at
GitHub.
When
you
go
to
hyperledger
Labs,
you
find
yeah
the
repository
stair
when
you
search
for
Peru.
We
also
have
a
bit
of
developer
documentation
where
you
can
go
through
tutorials
play
with
it
and
yeah.
If
you
are
interested
reach
out
to
us,
we're
happy
to
to
get
yeah
interest
contributions,
maintainers
whatever
happy
to
talk
to
you,
we
have
a
Discord
Channel
at
the
hyperledger
Discord,
but
you
can
also
find
us
via
these
links
and
with
that
thanks
for
your
attention
and
happy
to
take
any
questions.
A
It's
a
good
question,
so
we
have
exploring
a
concept
where
it's
customizable,
but
the
library
as
it
published.
So
as
it's
on
the
main
publishment
branch,
it
you
always
have
to
pre-fund,
because
only
that
way
you
don't
need
to
trust
the
other
parties.
But
it's
not
that
hard
to
customize
it.
So
I
did
a
proof
of
concept
where
we
only
partially
fund
the
channel.
A
So,
for
example,
if
you
have
some
trust
involved,
you
could
say
maybe
you
reference
a
funding
pool
and
if
there's
not
enough
funding
for
the
the
final
settlement,
then
the
funding
from
one
party
will
be
taken
from
an
authorized
funding
pool
which
has
the
risk
that
the
pool
may
run
dry
at
some
point,
but
you
can
actually
start
transacting
without
any
on-train
interaction.
If
you,
if
you
trust
in
that,
so
that
enables
off-chain
payments,
for
example,
risk
can
still
drag
whose
balances
are
what
so.
A
A
Yeah,
so
any
party
can
trigger
it.
So
in
the
optimistic
case
one
party
proposes
to
close
the
channel
and
then
the
settlement
will
be
just
one
online
transaction
and
usually
we
split
the
settlement
from
the
withdrawal.
So
at
some
point
the
on-chain
state
will
be
concluded
and
there's
no
change
possible,
but
individual
parties
can
withdraw
it
through
their
accounts
whenever
they
like.
A
If
you
have
a
dispute,
so
you
couldn't
settle
the
channel
off
chain,
you
couldn't
finalize
the
state
of
Jane,
then
the
dispute
period
until
you
have
to
wait
that
the
settlement
can
be
done
is
configurable
and
that's
I,
guess,
depending
on
the
blockchain
that
you
use
depending
on
the
application,
it
can
be
minutes
or
seconds
minutes
or
days.
Maybe
even
so,
that's
a
parameter
that
you
specify
when
you
open
the
channel
yeah.
It
also
goes
into
the
unique
Channel
ID
yeah,
so
you
can
specify
it.
A
A
A
Yeah
I'm
good
that
you
point
me
too
fast
fabric
because
I'm
not
aware
of
that,
but
I'm,
aware
of
like
in
general,
the
space
of
Roll-Ups
and
so
on.
That's
something
that
we
that
we're
aware
of
in
terms
of
throughput
what
we
benchmarked
on
our
normal
computers
is
about
two
to
three
thousand
transactions
per
second,
but
I.
Think
if
you
tune
it
a
little
bit,
maybe
you
can
even
go
faster
really
what
just
what
you
just
need
to
do
is
in
case
of
a
two-party
channel
two
signatures
and
the
network
communication.
A
A
Yeah,
so
basically
we
have
an
injection
point
in
our.
So
let's
say
we
are
on
ethereum
and
then
we
have
our
ethereum
smart
contract
and
we
have
an
injection
point
where
you
can
in
the
dispute
protocol
inject
arbitrary
transaction
logic.
So
when
you
open
a
channel
you
specify
this
is
a
Channel
with
custom
transaction
logic
and
then,
when
the
dispute
protocol
runs
there's
an
additional
phase
that
checks
does
the
channel
have
customized
transaction
logic
and
then
it
will
call
a
separate
contract.
A
So,
like
you
deploy
your
tic-tac-toe
contract
separately
and
it
has
a
valid
transition
function.
So
basically
how
the
tic-tac-toe
contract
must
look
like
you
specify.
What
is
the
value
transition
from
one
game
state
to
the
next
one,
and
so
what
our
Peru
smart
contract
will
then
do,
and
it
will
check
it
would
call
the
the
tic-tac-toe
contract
with
the
current
state
and
the
proposed
next
state
and
the
signature
from
one
party.
There
must
be
at
least
one
party
that
yeah
yeah.
A
A
At
the
end
of
the
life
cycle
of
the
channels
you
somebody
will
have
to
check
to
them.
Nobody
cheated
right.
That's
also
an
interesting
point.
Yeah
we
don't
guarantee
like.
If
both
parties
are
cheating,
you
don't
have
a
reliable
outcome,
like
the
you
couldn't
rely
as
a
third
party
that
they
played
everything
correct.
That
would
involve
maybe
in
an
unrelated
third
party
in
the
channel.
So
that's
also
but
like
if
you,
if
you
think
about
swaps
or
some
like
chess
game
or
something
like
that,
then
you
want
to
make
sure
that
you're
not
betrayed.
A
A
A
But
between
the
two
parties
in
the
channel,
you
have
the
guarantee
that,
whatever
you
agree
on,
you
can
settle
at
any
point
in
time.
So
it's
up
to
you
basically
I
mean
you
can
do
it
for
like
I.
Think
the
typical
point
in
time
would
be.
You
want
to
use
the
funds
that
are
locked
into
the
channel
in
a
different
use
case,
so
you
want
to
transfer
the
funds.
A
Yeah
do
a
payment
outside
of
the
Peru
Channel.
Then
you
want
to
close
the
channel
and
settle
it,
but
there's
no
need
to
settle
the
channel,
because
maybe
your
fear
of
losing
your
funds
as
long
as
the
channel
is
open-
and
you
still
remember
what
the
most
recent
state
was.
This
is
also
persistence
is
important
yeah,
but
for
example,
maybe
you
want
to
do
checkpoints
for
persistence,
reasons
that
that
could
be
a
good,
a
good
point,
yeah,
so
yeah.
A
Yeah,
it
seems
at
first
that
there's
this
kind
of
contrary,
and
sometimes
we
were
also
pitching
the
technology
as
a
private
Channel,
because,
as
you
say,
you
only
receive
the
result.
The
settled
result
on
the
blockchain,
but
you
don't
necessarily
see
the
individual
transaction,
but
what
you
could
do,
for
example,
you
could
maybe
so
there
is
an
arbitrary
data
field
that
you
can
fill
in
this
channel
state.
So
maybe
you
could
populate
that
with
the
transaction
history
or
something
like
that
and
make
it.
A
So
you
could
maybe
even
do
some
additional
proof,
logic,
a
program
it
into
the
channel
logic,
yeah
and
basically
enforce
the
correct
transaction
history.
I,
don't
have
a
like
thought
through
answer
for
this,
but
you
like
the
basic
thing
that
you
just
track
an
addition
of
the
balances
you
track,
the
individual
transaction.
That's
something
that
you
can
surely
do.
A
Yeah,
as
I
said
so
this
these
are
the
blockchains,
so
this
is
life.
This
is
life.
This
is
life.
This
is
life
with
different
feature,
sets
so
virtual
channels,
for
example,
so
channels
on
top
of
channels.
We
currently
only
have
here
Channels
with
customizable
transactionality
we
have
in
polkadot
now,
cardano
and
dfinity
are
in
development.