►
From YouTube: Understanding the Hyperledger Indy Distributed Ledger - Alexander Shcherbakov, Evernym
Description
Understanding the Hyperledger Indy Distributed Ledger - Alexander Shcherbakov, Evernym
Hyperledger Indy has its own implementation of Distributed Ledger (indy-node) not dependent on any other blockchain platform. It also has its own implementation of a PBFT-like consensus protocol (indy-plenum).
Indy-node is a Ledger purpose-build for Identity. However, it can be used as a general-purpose blockchain for use cases besides Identity.
One of indy-node deployments (Sovrin Ledger) is successfully functioning in production for more than 2 years.
The presentation focuses on the Architecture and specific of Indy Ledger. In includes Plenum consensus protocol (RBFT), corresponding crypto (in particular, BLS multi-signature), organization of transactions and storages (ledgers and states), usage of merkle trees and Patricia merkle tries, auditability, workflow of read and write requests, catch-up procedure.
Support of custom plugins and custom transactions on top of indy-plenum or indy-node will also be described.
----
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 #HyperledgerGlobalForum2020 #Blockchain
A
A
So
what
do
you
know
about
India
for
most
people?
India
is
all
about
identity.
That's
true,
and
not
everyone
actually
realized
that
India
has
its
own
distributed
ledger
and
it
has
its
own
implementation
of
distributed
ledger
and
this
implementation
not
dependent
on
any
other
blockchain
platforms,
any
other
blockchain
systems.
This
is
really
one
of
the
distributed
letters
which
is
part
of
hyper
ledger,
and
what
is
important,
this
is
beef.
A
Tp
beef,
tea,
like
implementation
of
a
consensus
protocol
more
our
this
implementation
is
in
production
as
part
of
Solon
Network
for
more
than
two
years,
and
also
in
G
is
one
of
active
hyper
letter
projects.
I
mentioned
certain
foundation
and
sorry
networks,
but
there
are
also
another
deployments
of
Internet
work
of
India
ledger
such
as
fin
G,
Kiva
and
so
on.
A
So
it's
working
for
more
than
two
years
in
production
and
has
real
customers
and
real
applications
working
on
top
of
these
okay.
So
what
we
are
going
to
discuss
today?
First
of
all,
we
are
going
to
understand
why
we
need
a
public
blog
chain
in
sell
stolen
identity,
so
why
we
need
the
blockchain
and
these
kind
of
identity
solutions.
A
Then
we
are
going
to
consider
what
projects
hyper
ledger
in
the
larger
consists
off
and
we
are
going
to
discuss
the
architecture
of
in
the
larger,
how
the
actual
database
ists
look
like
and,
of
course,
deal
with
the
consensus
protocol,
what
consensus
protocol
India
implements
and
what
is
specific?
Oh,
this
protocol,
okay,
so
self
certain
identity.
You
know
there
were
other
grad
topics
describing
what
is
areas?
What
is
in
G?
What
is
verifiable
credentials?
A
This
is
also
just
a
very
quick
overview
that,
in
order
to
have
a
verifiable
credentials,
the
issue
usually
creates
the
issues
claim
which
is
signed
by
him,
and
it's
issued
in
the
form
of
a
digital,
verifiable
credential
which
is
stored
on
the
poorest
wallet
and
then
can
be
presented
to
a
verifier.
As
you
know,
SS
zero
knowledge
proof
form.
A
So
the
question
is:
why
do
we
need
a
blockchain
here
actually,
but
you
can
see
some
errors
and
we
need
to
the
blockchain
because
of
multiple
reasons.
The
first
reason
that
we
need
a
schema
for
these
credentials.
We
need
to
know
how
it
looks
like
we
need
to
know
what
is
a
public
key
of
the
issuer
to
be
used
for
signing
this
credential.
We
need
to
know
well
whether
these
credential
is
revoked
or
not.
A
Why
not
just
a
database
and
the
answer
that
we
need
a
decentralized
source
of
trust
and
also
we
would
like
the
latter
to
be
public
so
that
it
means
that
anyone
in
the
ecosystem,
anyone
in
the
world
should
be
able
to
read
this
data
for
identity
use
cases,
and
it's
pretty
important
to
understand
what
data
in
engine
verifiable
credentials
workflow
is
on
the
blockchain
and
what
data
is
considered
to
be
private
and
never
goes
to
the
blockchain
and
began
here.
You
all
know
about
GDP
are
about
the
laws
in
California
and
so
on.
A
So
the
rule
of
thumb
here
that
no
private
data
is
ever
written
to
the
blockchain
to
the
in
the
latter.
But
what
is
written
then
some
public
D
ID
spotted
the
central
identifiers
and
the
corresponding
data
documents.
It
can
be
written
to
the
blockchain
issues,
public
keys,
which
will
be
used
for
verification
of
credentials.
It
goes
to
the
blockchain
credentials,
schema
and
information
about,
revocation,
that's,
usually
what
we
can
see
on
the
blockchain
and
what
is
never
written
to
the
blockchain
is
pairwise
the
IDS.
A
A
Okay.
So
in
the
ledger
in
the
distributed
ledger,
it
consists
of
two
projects
in
hyper
ledger.
This
is
in
the
plenum
and
in
general.
What
is
the
difference
in
the
plenum
is
a
kind
of
general-purpose
project
related
to
implementation
of
the
consensus
protocol
as
a
ledger,
database,
state
and
so
on
and
in
the
node
it's
built
on
top
of
these
on
top
of
in
the
plenum
and
it
introduces
and
implements
identity
related
stuff
and
they
related
transactions.
For
example.
A
If
you
would
like
to
know
how
the
schema
transaction
or
credential
definition
transactions
from
the
in
the
world
look
like,
you
should
go
to
engine
hood,
but
if
you
will
interest
it
in
consensus
protocols
in
this
stuff,
then
you
should
go
to
in
the
plenum
in
general.
India
is
a
ledger
purpose-built
for
identity,
but
from
my
previous
explanation
it
follows
that
in
principle
it
can
be
used
as
a
general
purpose
ledger.
A
So
plenum
is
a
core
stuff
and
you
can
extend
plenum
implementing
custom
transactions
because
we
have
so-called
concept
of
pluggable
request
handlers
and
you
can
even
implement
your
own
plugins
that
actually,
what
engineer
does
so?
It
extends
pluggable,
request,
handlers
interfaces
and
implements
identity
related
stuff.
On
top
of
the
common
logic
within
in
the
plenum,
but
sitting
pretty
important
to
understand
that
in
general,
independent
can
be
used
as
a
general
purpose
letter,
so
brief
overview
of
in
the
plenum
and
nerd
its
certain
Python.
A
It
depends
on
gmq
in
decrypter
and
currently
are
immigrating
to
Ursa
and
lip
sodium.
It
follows
a
modular
architecture
message
driven
behavior
and
yeah.
We've
been
working
on
improving
this
and
also
we
do
care
about
pests
in
Indies.
So
it
has
extensive
test
coverage.
It
tries
to
follow
TDD.
It
has
a
lot
of
unit
tests,
integration
tests
and
also
simulation
test
property
base.
A
The
testing
is
pretty
important
for
distributed
ledger
and
fifty,
like
consensus
protocol,
also
have
a
number
of
system
tests
and
load
tests,
and
it's
important
to
mention
that
we
do
test
on
a
real
deployments
of
twenty
five
notes,
pools
which
are
distributed
in
different
parts
of
the
world
in
AWS,
for
example,
so
plenum
and
the
node
ledger
is
really
tested
at
scale
and
in
the
real
environment.
Oh.
A
So
in
the
ledger
can
be
considered
as
a
public
permissioned
one.
So
you
know
bitcoin
is
about
decentralized
money.
The
room
is
mostly
about
decentralized
applications
and
India
is
about
decentralized
identity,
and
so
what
it's
public?
It's
public,
because
anyone
can
read
from
the
ledger
and
why
it's
permissioned,
because
it's
not
like
bitcoin
or
a
theorem
that,
where
anyone
can
know,
join
the
network
and
participate
in
processing
transactions
in
India,
only
the
specific
stewards
can
join
the
network
and
can
own
and
has
a
node
which
validates
transactions
and
also
write
request.
A
A
They
needs
to
be
owned
by
different
so-called
stewards,
who
has
a
private
key
for
this
node
to
their
maintenance
of
this
node,
make
sure
that
it's
connected
to
all
other
nodes
in
the
pool
and
so
on,
and
this
validated
pool
it's
responsible
for
actual
processing
of
requests
and
ordering
them
as
part
of
consensus
protocol.
In
addition
to
the
data
pool,
we
may
have
so-called
observable,
and
this
is
the
nodes
which
can
process
requests.
A
A
So
the
validators,
as
I
said
they,
they
have
a
consensus
logic
implemented
there.
That's
what
what
they
do
when
you
get
a
transaction
when
they
get
write
requests
they
come
to
consensus.
What
is
the
sequence
number
of
this
request
in
what
order
it
should
be
written
to
the
ledger
by
letter
here,
I
mean
like
a
ledger
database.
So
each
node
replicates
replicates
these
databases,
so
it
has
the
same
information,
the
same
data
on
every
node
and
yes,
any
other
pbft
like
protocol.
A
We
have
n
nodes
which
is
equal
to
3,
F
plus
1,
where
F
is
a
maximum
number
of
crashed
or
unavailable
or
malicious
nodes,
and
we
use
0
mq
as
a
secure
transport.
It's
TCP
based
protocol.
It
uses
authenticated
encryption
instead
of
digital
signatures
and
BLS
signatures.
It's
also
part
of
consensus
protocol
to
be
able
to
verify
the
data
written
to
the
ledger,
I'm
going
to
tell
you
about
BLS
signatures
with
more
in
the
next
slides.
A
A
Qwest
is
sent
to
all
notes
the
system,
all
nodes
from
the
validator
pool,
and
we
expect
to
get
F
plus
1
equal
replies
to
be
to
be
sure
that
it's
actually
written
S
was
a
really
quests
have
only
one
error
here:
it's
sufficient
to
send
a
read
request
to
one
node.
Only
the
single
node
only
and
the
user
can
trust
the
result.
The
reply,
because
of
the
BLS
aggregated
signatures
because
of
the
state
proofs.
So
we
are
going
to
talk
about
this
in
more
details
and
no
signatures
are
required
there.
A
So
the
legend
is
public
from
the
read
equals
point
of
view.
Let's
talk
about
authentication
and
authorization,
so
authentication
as
well
as
authorization
is
based
on
the
information
present
on
the
ledger.
So,
as
I
said,
every
write
request
must
be
signed
and
the
signature
is
verified
against
the
public
key,
which
is
also
present
on
the
ledger.
A
This
public
key
is
put
there
as
a
part
of
the
added
dock
or
kind
of
information
associated
with
the
D
ID
of
the
user
of
the
sender
of
the
transaction,
so
that
all
the
nodes
can
get
a
request
and
can
get
the
Associated
public
key
from
the
ledger
and
verify
the
signature
and
for
requests.
We
don't
require
any
authentication
anyone
can
read
as
for
authorization
about
whether
a
person
is
allowed
to
do
this
particular
action.
A
Okay.
Now,
let's
talk
about
the
ledger
itself
as
a
database
which
is
replicated
in
every
node.
So
as
the
ledger
consists
of
transaction
log-
and
this
is
just
an
ordered
list
of
all
the
transactions
which
are
written
to
the
pool
and
we
have
a
miracle
tree
for
the
whole
ledger
attached
the
miracle
tree
or
you
know
it's
a
kind
of
a
common
structure
in
all
the
block
chains,
and
we
have
actually
three
databases
associated
with
every
ledger:
transaction
log
itself
and
two
databases
for
vertical
Leafs
and
vertical
nerves.
A
These
rocks
DB
as
a
key
value
storage
to
store
array,
all
these
data
structures,
and
also
it's
worth
mentioning
that
we
have
as
a
called
ketchup
process
so
that
if
a
node
is
lagging
behind
or
has
just
started,
I
need
to
get
the
information
missing
information
to
have
the
equal
representation
equal
ledger-
and
this
is
what
ketchup
procedure
does
all
other
information.
All
other
state
of
the
node
can
be
restored
from
the
ledger.
A
So
SMI
should
we
use
miracle
trees
and
we
use
a
consistency
check
just
by
verifying
that
to
miracle
trees.
Root
hashes
are
equal,
and
this
is
very
fast
and
convenient
way
to
see
that
two
letters
are
equal
during
part
of
our
consensus
protocol.
Also,
we
use
state
proofs
or
inclusion
proofs
to
verify
the
results
get
transaction,
so
you
ask
for
transaction.
You
can
verify
that
this
data
is
really
actually
part
of
this
miracle
tree
and
it's
also
used
during
the
ketchup
procedure.
When
you
get
the
missing
information
from
other
nodes.
A
Okay
Indy
has
multiple
Ledger's.
It's
not
just
one.
Sorry
have
so
called
audit
letter,
and
this
is
a
ledger
which
actually
introduces
the
order
odor
in
across
all
the
letters
all
other
letters,
so
it
can
be
considered
as
a
source
of
blocks
also
have
a
pool
ledger,
and
this
is
a
ledger.
Consistent
information
about
the
current
state
of
the
pool,
but
notes,
are
in
the
pool
what
are
the
public
keys
and
so
on.
A
We
have
config
ledger,
and
this
is
a
ledger
containing
some
information
about,
for
example,
validation
of
transactions,
authorization
policies,
some
config,
which
all
the
nodes
need
to
counter
consensus,
and
the
main
legerdemain
ledger
is
the
main
ledger
containing
application-specific
or
identity
specific
data.
So
if
we
consider
indy
and
identity
use
cases,
then
all
the
transactions
such
as
schema,
cred
death
vacation.
It's
all
part
of
the
domain
ledger
and
it's
worth
mentioning
that
plugins
can
add.
New
ledgers
can
register
and
add
new
lodgers
for
their
purposes,
so
poor
ledger
the
in
general.
A
The
current
configuration
of
the
pool
consists
of
a
block
of
Genesis
transactions
and
a
number
of
so-called
node
transaction
associated
with
every
node
in
the
pool-
and
you
can
add
you
can
use
this
no
transaction,
for
example,
to
add
a
new
node
or
to
remove
a
node
from
the
pool
or
to
edit
information
about
this
node,
for
example,
rotate
its
keys
and
on
this
example,
you
can
see
that
from
these
four
Genesis
transactions
and
these
five
new
transactions,
you
can
get
the
current
state
of
the
pool.
So
it
contains
actually
four
nodes
in
this
case.
A
I
would
ledger
so.
The
main
purpose
of
audit
ledger
is
to
introduce
synchronization
and
owner
in
between
all
other
Ledger's,
and
also
it
can
be
used
for
external
audit
of
data
written
in
multiple
letters
how
the
transaction
area
of
the
transactions
can
be
considered
as
a
block
associated
with
a
sequence
number,
and
also
having
references
to
vertical
tree
root.
A
So,
in
addition
to
ledger,
ledger
database
and
every
node
have
a
concept
of
state.
This
is
kind
of
a
snapshot
of
the
current
ledger.
So
each
letter,
except
audit
has
a
state
and
in
principle
this
is
a
partition
Merkle
tree
very
similar
to
how
it's
used
in
a
theorem.
It's
a
combination
of
radix
tree
like
a
key
where
a
storage
and
a
miracle
tree,
in
other
words,
state
mapped.
The
ordered
list
of
transactions
is
stored
in
the
ladder
to
a
current
state.
A
As
a
dictionary
like
current
snapshot,
we
used
rocks
DB
as
a
key
value
storage
here
as
well,
so
why
it's
needed
so,
for
example,
we
have
a
D
ID
and
we
have
a
key
associated
with
the
D
ID
and
we
need
to.
We
can
rotate
this
key.
We
can
change
the
value,
so
the
state
will
be
just
the
current
value
of
this
key
for
a
particular
GED
that
you
can
allow
you
to
get.
A
Now,
let's
move
to
consensus
protocol,
as
I
mentioned
before
India
has
its
own
implementation
of
a
consensus
protocol
and
this
is
busy
food
tolerant
protocol.
So
in
general
we
have
two
types
of
consensus
protocols.
This
is
CF:
seek
rational,
tolerant
and
beef,
tea
business,
evil,
tolerant
in
a
safety
world
the
nodes
can
be
unavailable
can
crash,
and
the
protocol
will
still
come
to
consensus
if
no
more
than
particular
number
of
such
nodes
are
unavailable,
but
in
beef
tea
world
it's
even
more.
The
nodes
can
be
available
by
may
just
behave
maliciously.
A
Okay,
so
plenum
in
the
plenum.
It
has
implementation
of
a
protocol
which
is
called
RB
FG,
and
this
is
a
beam
if
you
like
consensus
protocol.
So
no
pbft
was
maybe
the
first
practical
business,
a
fault
tolerant
protocol
created
in
1999
by
Mikkel,
Custer
and
Barbara
Liskov,
and
you
can
consider
RB
FC
as
a
multiple
instances
of
pv
FC
running
at
the
same
time,
and
it
helps
to
to
notice
some
malicious
behavior
in
the
network
better.
A
So
any
PVC
protocol
consists
of
three
main
phases,
which
is
called
three
phase
commit
and
the
first
phase
there
is
when
a
primary-
and
this
is
a
leader
base-
that
primary
based
protocol,
where
a
primary
proposes
the
next
set
of
transactions
to
be
ordered
and
the
primary
sends
a
so-called
pair
preparer
message,
all
other
nerds.
They
come
to
agreement
using,
prepare
and
commit
messages,
and
after
they
got
a
quorum
of
commit
messages,
the
transactions
is
considered
to
be
audit.
A
It's
written
to
the
ledger
and
reply
sent
to
a
client
while
I
have
actually
two
phases
prepared
commit,
not
just
one.
This
is
because
the
primary
can
be
malicious.
The
protocol
is
leader
leader
based
and
the
primary
can
be
malicious
in
different
ways.
It
can
be
just
disconnected,
are
stopped
or
it
can
intentionally
degrade
performance,
or
it
may
send
some
inconsistent
data
in
all
these
cases,
with
other
nodes
notice
that
the
primary
is
malicious,
they
need
to
change
the
primary,
and
this
is
a
process
which
is
called
a
view
change
so
of
in
every
view.
A
A
We
use
a
variant
without
digital
signatures,
and
that's
actually
why
they
have
multiple
instances
of
the
pivot
of
like
protocol
in
our
BFG.
That
every
instance
has
its
own
primary
and
they
all
execute
at
the
same
time
calculate
throughput,
latency
and
compare
performance
and
if
other
instances,
backup
instances
sees
that
the
master
protocol
instance,
which
is
actually
the
one
which
executes
surreal
transactions,
degree
its
performance,
they
do
a
view
change
they
change
the
primary.
A
This
is
the
reason
why
our
beauty
is
better
in
catching
this
kind
of
behavior
in
general,
that
will
change
protocol
and
pbft
well.
The
main
thing
here
is
to
be
make
sure
that
all
transactions
that
could
be
potentially
ordered
on
at
least
one
correct
nodes
node
should
eventually
be
ordered
on
all
the
nodes,
and
this
is
done
by
letting
the
next
primary
in
a
new
view,
kind
of
reorder,
all
these
kind
of
transactions
which
could
be
potentially
audit,
okay.
A
So
the
Panem
has
a
number
of
features
which
worth
mentioning
are
the
first
one
that
every
request
every
transaction
is
ordered,
not
one
by
one,
because
you
can
see
that
this
is
quite
heavy
process
of
through
phase
commit,
and
this
is
n
square
asymptotics
there.
So
we
can
order
a
batch
of
transactions
at
once
in
one
pre-prepared
message
which
of
course
improves
performance
a
lot.
This
is
a
trade-off
between
throughput
and
latency,
depending
on
how
many
transactions
include
in
one
pre-prepare,
also
as
part
of
our
consensus
protocol.
A
We
check
for
data
consistency,
so
we
apply
all
the
transactions
optimistically
in
uncommitted
State
and
we
make
ensure
that
the
data
on
other
node
is
equal
to
the
data
on
the
primary.
If,
yes,
we
continue
to
order
this
transaction.
If
not,
we
do
that.
We
change
and
change
the
primary
and
well,
in
addition
to
just
applying
the
data.
We
do
this
dynamic
validation,
for
example,
we
validate
the
data
is
immutable,
or
this
is
really.
The
user
has
a
permission
to
do
this
action.
Something
like
this,
and
this
verification
is
done
against
the
current
uncommitted
State.
A
A
So
if
you
don't
have
pre
prepare
number
12,
then
we
need
to
wait
or
request
it
from
other
nodes
before
we
can
go
further
and
maybe
the
last
important
thing
last
feature
in
plenum.
It's
BLS,
aggregated
signature.
So,
as
I
mentioned
before,
it's
sufficient
to
send
the
requests
to
a
single
node
only
and
why
the
client
can
trust
this
data.
It
can
trust
because
of
two
things.
The
first
thing
that
in
every
reply
to
read
request,
we
return
proof
that
this
request
belongs
to
a
miracle
tree
to
the
petition
miracle
tree
on
the
node.
A
That's
fine!
We,
the
client,
can
verify
that
this
data
is
on
this
miracle
tree.
But
the
next
question
is:
how
would
you
know
that
this
miracle
tree
is
really
the
same
as
on
other
nodes,
because
it
can
be
that
this
node
just
create
that
fake
miracle
tree
and
returned
this
data
to
the
user?
And
the
answer
to
this
question
is
that
every
note
during
consensus
protocol
they
sign
they
cryptographically
sign
the
root
hashes
of
the
state,
so
that
we
also,
in
addition
to
the
state
proof,
will
return
this
signature.
A
So
the
client
can
verify
the
signature,
can
verify
the
root
or
for
the
miracle
tree
and
trust
the
data
so
yeah
during
the
commit
phase.
Every
note
signs
the
ledger:
miracle:
the
state
Merkel
the
current
time
stamp
so
that
we
have
this
called
so-called
aggregated
Els
multi
signature
to
be
verified
by
the
client.
Okay.
A
Well,
so,
as
a
summary
ledger
in
the
ledger
is
a
larger
purpose-built
identity,
but
on
the
other
hand
it
can
be
used
as
a
general
purpose.
Ledger
India
has
its
own
implementation
of
consensus
protocol,
a
business,
a
fault
tolerant,
like
consensus,
protocol
I
need
you
have
multiple
Ledger's.
Every
letter
has
a
state,
a
partition
miracle
to
state
as
a
snapshot
and
has
a
miracle
tree,
authentication
authorization.
It's
all
based
on
the
information
present
on
the
letter
and
one
of
the
features
of
important
features
of
India
is
efficient
reads.
A
You
can
read
just
from
one
note:
you
don't
need
to
download
the
whole
block
chain
the
whole
ledger.
You
can
just
send
a
request
and
verify
it
with
a
small
amount
of
time
and
data
required
and
yeah.
This
is
very
pretty
important
for
public
permissioned,
Ledger's
use
cases
so
as
some
links
to
our
code
to
the
RBA
cheap
paper
to
PVC
paper,
and
thank
you.
A
This
is
features
considered
to
be
partially
implemented.
We
already
have
like
the
key
things
for
this
feature,
and
actually
one
of
the
key
things
for
this
feature.
Is
this
one
be
less
aggregated
signatures
and
to
be
able
to
transfer
data
from
one
node?
Only
and
also
we
have
observer
interfaces,
but
we
don't
have
any
real
observer
nodes
in
production
and
I
believe
there's
also
some
a
couple
of
things
that
needs
to
be
finished
before
it
can
go
there.
A
A
A
Not
necessary,
we
can
see
we're
considering
some
strategies.
We're
observing
notes
could
replace
with
letters,
for
example,
if
validators
behaved
maliciously
or
the
other
way
around,
but
in
general
observer.
No,
don't
need
to
be
able
to
data
note
in
terms
of
the
code.
It
can
run
the
same
code,
the
same
in
denude
or
solving
code,
but
it
just
depends
on
the
role
that
we
assign
for
this
particular
node.
A
A
Yeah,
so
we
use
rocks
DB
as
a
persistent
storage
for
this
data
for
any
every
ledger.
Every
state
of
use
rocks
DB.
So
it's
not
in
RAM,
it's
not
in
memory.
It's
actually
persisted
rocks.
Db
has,
of
course,
some.
You
know
optimizations
that
for
frequently
used
data
it
uses
some
in
memory
accesses,
but
in
general
it
can
be
persisted
and
in
general
we
can.
We
can
scale
it
on
these
levels,
so
we
can
create
multiple,
you
know,
databases
and
so
on
cuz.
It's
usually
a
trade-off
between.
A
Yeah,
you
know
that
we
have
a
new
transaction
which
is
can
be
used
to
store
the
idea
that
passes
it
public
keys,
but
we
don't
have
a
request
to
just
return
a
di-did
dog.
This
is
kind
of
one
of
the
features
which
is
in
our
backlog,
so
you
can
just
you
know,
process
the
data
on
that
client
side
and
form
the
GID
dog
in
a
way
it
is
defined
by
w3c
and
in
order
to
how
to
store
other
information
required
for
the
ID
dog,
such
as
service
endpoints.
You
know
this
controllers.
A
We
have
a
special
transaction,
which
is
called
a
trip
attribute
where
you
can
put
any
data
associated
with
the
D
ID.
So
you
can
use
these
transactions
to
store
at
the
idea
dog,
but
in
general
we
have
plans
for
a
real
the
idea
dog
support
more
convenient
for
end-users,
so
you
can
just
request
it
and
get
back
in
a
you
know
into
interoperable
form.