►
Description
An introduction to Hyperledger Cactus from Peter Somogyvari that introduces the project and explains about how to get involved.
Find out more about Hyperledger Cactus at:
https://wiki.hyperledger.org/display/cactus/
----
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
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
A
A
A
So
what
is
it
it
is?
Hopefully
it
will
be
a
plugable
enterprise,
great
framework,
to
transact
on
multiple
distributed
ledgers
without
inventing
yet
another
competing
blockchain.
The
last
part
is
important.
We
do
not
want
a
ledger
of
ledger
sort
of
blockchain,
so
we
do
not
intend
on
having
this
core
functionality
where
we
basically
store
blocks
of
data
and
then
have
some
sort
of
consensus
achieved
on
that
as
part
of
cactus.
A
You
just
want
this
to
work
with
every
blockchain
out
there,
because
that's
like
the
bare
minimum,
how
it
should
be,
then
you
are
looking
at
doing
thousands
and
thousands
of
different
integrations
to
different
letters,
and
so
that's
part
of
it
why
fragmentation
is
bad.
It's
not
as
bad
as
exponential
growth,
but
it
is
quadratically
growing.
A
A
So
I
just
wanted
to
clarify
that.
Make
sure
that
I
mentioned
it
and
then
we
have
a
generic
use
case.
This
is
a
ridiculously
oversimplified
for
a
reason
I
will
get
into
more
details,
but
I
just
wanted
to
show
this
that
in
the
end,
this
is
what
it
always
boils
down
to.
You
have
more
than
one
letters.
You
know
it
can
be
two
or
ten,
and
then
you
have
a
separate
cactus
deployment
and
the
users
or
the
developers.
A
A
They
almost
always
involve
a
smart
contract
being
deployed
on
the
target
ledgers
to
facilitate
some
sort
of
operation,
for
example,
the
use
case
we
have
with
the
federated
validation,
where
you
can
export
some
data
from
ledger,
a
to
ledger
b
and
then
have
actual
cryptographic
proof
obtained
from
cactus,
which
obtained
it
from
ledger
aids.
Smart
contract,
that
the
data
is
present
on
ledger
a,
and
it
is
indeed
in
the
form
that
ledger
b
has.
A
A
A
The
main
point
is
that
we
want
to
be
able
to
integrate
with
as
many
ledgers
as
possible,
and
we
don't
want
to
limit
ourselves
to
plug-ins
that
we
implemented.
We
want
everyone
else
to
also
implement
targets
secure
by
default
very
important,
it's
one
of
the
boring
ones,
because
nobody
likes
to
deal
with
securing
their
application,
but
we
make
it
a
point
to
have
the
software
come
ship
with
the
security
defaults
that
will
not
cause
any
heartbreak,
hopefully
to
anyone
so
that
it
doesn't,
you
know,
come
deployed
with
a
password.
A
That's
a
admin,
and
the
username
is
also
admin
stuff
like
that,
and
then
we
want
it
to
be
toll-free.
We
do
not
want
any
kind
of
functionality
based
in
there
that
somehow
ends
up
charging
people,
transaction
fees
or
anything
else.
We
do
not
intend
on
issuing
our
own
tokens
or
have
an
ico.
We
don't
really
want
to
do
any
of
that
low
impact
deployment.
A
An
example
of
that
would
be
sorry
an
example
of
that
would
be
if
you
are
running
a
fabric
letter
and
we
have
a
fabric
connector
plug-in
for
that
ledger,
then
you
shouldn't
need
to
deploy
additional
software
to
be
able
to
use
the
cactus
api
and
deploy
chain
code
contracts
on
it.
This
is
much
harder
said
or
much
further
done
than
said,
but
we
are
working
on
things
like
this
to
make
sure
that
that
design
principle
is
really
actually.
A
Ledger
is
just
a
database
with
you
know
a
lot
of
extra
bells
and
whistles,
but
in
our
abstraction,
we're
trying
to
just
treat
it
as
a
as
a
read,
write
data
store
that
is
able
to
have
cryptographic
proofs
of
the
data.
That's
in
there
and
also
the
smart
contract
support,
which
is
executing
code
for
use
cases
there.
A
A
A
A
A
A
Some
implementation
details
about
the
project,
much
lower
level.
We
write
the
coding
typescript,
we
bundle
it
with
webpack
there's
a
bunch
of
packages.
I
think
it's
already
above
10.,
some
of
them
are
plugins.
Some
of
them
are
the
core
api
definitions.
We
have
an
api
server.
We
have
a
common
package
which
is
designed
to
be
cross
platform,
slash
universal,
so
the
same
package
can
be
installed
in
a
node.js
or
a
browser
environment.
A
A
A
A
A
A
So
that
would
mean
that,
even
though
cactus
is
running
a
node.js,
you
could
write
your
plugin
in
your
favorite
language
and
interact
with
cactus
through
the
localhost
network
interface
and
some
good
ideas
we've
seen
elsewhere.
Implementing
these
is
the
go
plugin
project
which
uses
this
exact
same
mechanism.
A
You
know
package
it
up
as
an
npm
package
and
you're
ready
to
go.
You
can
use
the
plugin.
You
never
have
to
talk
to
any
of
the
maintainers
to
get
any
sort
of
permission
or
any
of
that
and
the
edge
case
is
which
hopefully
will
happen
very
rarely.
But
if
it's
not
even
pluggable
so
this.
If
this
is
something
embedded
in
the
core,
then
we
can
discuss
it
and
if
he
say
yeah,
this
is
a
good
idea.
A
Example,
the
way
you
could
use
a
storage
plug-in
like
that
is
to
implement
some
sort
of
functionality
where
your
application
keeps
track
of
pending
transactions
or
some
other
really
basic
necessary
feature
that
you
will
most
definitely
need
if
you
have
any
kind
of
business
application
where
you
have
to
keep
track
of.
What's.
A
Said
this
I'll
just
skip
this
one,
the
transaction
protocol-
this
is
still
under
design,
but
the
point
is
that
we
want
to
have
this
handshake
phase,
where
both
participants
of
the
transaction
first
have
to
agree
on
what
is
going
to
happen.
How
this
cross
ledger
transaction
is
going
to
be
played
out,
and
that's
the
important
part
about
that,
so
that
nothing
happens,
that
you
don't
want
or
didn't,
anticipate
to
happen
and
the
void
surprise
is
like.
A
A
For
higher
throughput
use
cases
where
explicit
peer
interaction
is
not
required,
for
example,
if
if
you
have
a
business
use
case
where
you
want
to
move
large
chunks
of
data
from
one
ledger
to
another
and
both
accounts
or
wallets
or
whatever
identity,
you
have
you
both
own
both
of
those
on
both
ledgers,
then
you
might
just
want
to
get
it
done
as
fast
as
possible.
Instead
of
having
to
go
through
the
transaction
proposal
phase
for
each
one
individually,.
A
A
The
big
challenge
there
is
that
you
cannot
really
have
any
sort
of
state
or
almost
any
I
mean
we
will
end
up
having
some,
but
we
try
to
keep
that
to
the
minimum,
because
that's
what
always
blocks
software
down
there
and
it
has
to
store
a
certain
amount
of
state.
So
we
intend
to
be
stateless
wherever
possible
and
that's
that
actually
ties
back
twice.
What
I
said
about
us
not
wanting
to
store
blocks
of
data
and
be
responsible
for
the
consensus
and
all
that.
A
A
It's
really
just
to
show
that
we
do
have
details.
I
promised
them
in
the
beginning
on
that
very
oversimplification
of
slide,
and
you
should
definitely
check
out
the
white
paper
that
we
have
on
github
within
the
github
repo,
because
there's
lots
of
this.
So
if
you
want
to
seriously
deep
dive
on
the
hands
on
details,
then
we
have
that,
and
that's
all
I'm
gonna
say
about
this
regarding
federated
validation.
A
So
the
point
there
is
that
you
can
verify
you
can
give
a
verification
to
one
letter
that
a
certain
state
is
on
the
other
ledger
for
a
specific
block
or
a
piece
of
data,
and
we
want
it
to
be
fill
stop
tolerance.
So
if
one
node
goes
down
or
if
a
member
of
your
consensus
goes
down,
then
it
shouldn't
stop
working,
it
should
just
handle
it.
A
The
network
services
that
involve
this
or
this
involves
is
really
to
to
add
public
keys
to
the
smart
contracts,
which
is
mentioned
as
manage
trusted
foreign
validators
and
verify
the
payloads
against
the
state
of
the
ledger.
They
are
connected
to
and
handle
export
requests,
meaning
your
application
wants
a
piece
of
data
moved
legibly
from
ledger
rate
letter
b,
a
little
bit
of
an
architecture
diagram
that
shows
the
layers,
and
it
shows
that
we
are
on
top
of
the
actual
dlt
platforms
and
the
ledger
software
and
the
sdks.
A
A
That's
where
requests
come
in
from
a
client
application
and
the
on-chain
logic
is,
as
it
is
right
now.
Most
of
the
time
is
a
smart
contract
that
we
deployed
on
the
ledgers
that
we
support
and
really
what
the
off
chain
logic
does
is
invoke
the
on-chain
logic
to
work
its
magic
and
deliver
the
specific
use
case
that
you
wish
it
to
do.
A
We
do
have
a
roadmap,
but
this
is
heavily
subject
to
change.
We
want
to
finalize
the
1.0
design
and
technical
architecture.
We
do
not
yet
have
a
1.0
release
or
a
stable
version
of
it.
I
wanted
to
reiterate
that
and
regarding
identity,
we
want
to
support
all
the
cool
solutions
out
there
and
standards.
A
I
am
personally
a
big
fan
of
the
sovereign
foundation
and
I
also
have
been
working
on
adding
some
sort
of
open
id
connect
support
for
identities,
but
that's
also
still
work
in
progress.
If
you,
if
you
want
the
absolute
hardcore
details,
there
is
a
pull
request
open
with
it,
and
the
project
so
feel
free
to
check
that
out
as
well.
A
Implementing
plugins
for
different
languages
mentioned
that
consortium
management.
I
talked
about
that
and
we
definitely
want
some
sort
of
first
public
test
deployment
that
would
achieve
some
sort
of
dummy
hello
world
use
case,
but
out
there
in
the
public
so
that
everyone
can
give
it
a
test
and
see
it
in
action.
A
C
A
Well,
if
you
are
looking
to
contribute
the
plugin
to
the
main
repository,
then
it
will
be
scrutinized
by
all
the
maintainers
heavily,
so
that
is
sort
of
an
approval
process,
but
you
can
also
develop
your
own
plugins
and
nobody
stops
you
from
publishing
those
in
divide,
open
internet
and
nobody
will
stop
people
from
using
it.
So
there
isn't
at
the
moment
a
sort
of
a
safeguard
around
us,
except
maybe
a
verbal
recommendation
that
if
you
operate
cactus,
then
you
should
not
install
plugins
without
reviewing
the
source
code.
A
And
if
someone
is
trying
to
obfuscate
the
source
code,
then
that's
obviously
a
red
flag,
but
yeah.
I
think
that's
a
that's
a
great
point,
that's
something
we
should
look
into,
because
this
could
be
a
problem
just
like
it
is
a
huge
problem
with
the
app
stores,
the
main
stream
app
stores.
Where
you
know
a
big
big
percentage
of
the
apps
out.
There
are
basically
just
malware.
C
A
There
is
a
an
api
proposal
out
there
right
now
in
the
examples
directory
of
ours
where
it
is
proposed
that
we
should
have
an
event-driven
way
of
listening
to
changes
in
the
ledger
state
so
that
you
as
a
an
end-user,
slash
developer.
You
can
subscribe
to,
let's
say
a
certain
block
or
a
certain
transaction
being
completed
on
one
or
both
of
the
ledgers
or
all
of
them,
and
then
you
get
notified.
A
D
I
mean
if
we
have
a
few
different
networks
of
participants
that
do
not
intersect
with
each
other,
but
they
have
different
instances
of
cactus
that
want
to
connect
to
each
other,
for
example,
if
it
would
be
something
like
an
oracle
that
tells,
I
don't
know,
exchange
rates
for
different
currencies
and
one
organization
would
want
to
interact
with
another
organization's
instance.
Is
this
something
to
consider
or
all
interactions
are
only
within
blockchains?
A
A
So
in
theory,
if
you
want
an
application
that
doesn't
just
work
with
one
cactus
deployment,
but
also
an
other,
you
could
do
that
and
the
experience
in
the
code
should
be
largely
the
same.
You
just
have
to
be
aware
of
the
differences
of
those
two
cactus
deployments.
For
example,
you
know
one
of
the
deployments
will
have
a
ledger
connector
plug-in
for
fabric,
but
the
other
one
will
be
for
basic,
so
you
have
to
take
care
of
that
in
your
code,
other
than
that
it
should
just
work.
That's
my
personal
vision
of
this.
A
We
do
plan
on
supporting
ethereum,
you
know
just
because
something
is
proof
of
work.
It
doesn't
mean
that
we
cannot
integrate
with
it.
It's
just
that.
I
will
work
extra
hard
on
telling
everybody
and
making
sure
that,
if
you're
integrating
with
the
proof
of
work
ledger,
then
certain
things
can
happen
that
are
outside
of
your
control.
C
Awesome
yeah
that
that
makes
total
sense.
So
I
think
that
well
do
you,
the
the
people,
have
more
questions.
We
have
still
some
time
if
you'd
like
to
you,
know
grill
me
or
peter
on
any
topics
we're
here
for
you
really
so
I'll.
You
know
give
you
a
minute
to
to
think.
If
you
have
any
questions
and
if
you
don't,
then
we
can
always
just
wrap.
D
A
A
Yes,
but
there's
a
there's
a
fine
print
there,
which
is
that
you
can
only
guarantee
this
if
you
are
transacting
with
ledgers,
where
both
of
those
ledgers
are
under
your
control,
in
the
sense
that
you
can
actually
do
a
rollback
right,
because
you
cannot
roll
back
a
proof-of-work
lecture,
but
the
two-phase
commit.
I
really
like
that.
A
C
Yep,
I
was
just
waiting
giving
people
a
moment,
but
I
think
we
are
done
here.
This
was
amazing.
Askcliff
says
it's
a
great
good
presentation
and
good
answers.
I
would
say
it's
great
presentation
and
great
answers.
I
am
really
appreciative
because
I've
had
so
many
people
asking
about
cactus
and
learning
more
about
it,
so
it
will
be
awesome
to
also
be
able
to
point
people
at
the
recording
of
this
presentation.