►
Description
Roman is a Rust programmer at Bitfury, he leads the Exonum Russia team. They develop blockchain applications built on the Exonum. He has experience in building and integration of enterprise and government blockchain solutions.
Exonum is a blockchain framework developed in Rust that allows building secure permissioned blockchain applications. Blockchain, as a technology that expands the capabilities of distributed databases, implies the possibility of auditing or validating stored information.
Exonum provides a “proofs mechanism”, based on cryptographic commitments via Merkle / Merkle Patricia trees. This mechanism allows verifying that a response from the full node has been really authorized by a supermajority of validators.
The talk will present how we develop the merkelized collections in Exonum and the tools to provide data auditability functionality for the web applications integration. The talk will be based on the auction blockchain application example.
A
My
name
is
Herman
I'm
working
in
this
fury,
especially
I'm,
working
in
on
excellent
project
economies,
framework
for
building
private
blockchains
and
especially
I
suppose
developing
book
chain.
Application
based
on
the
exonym
I
have
a
question
for
our
audience.
How
many
did
you
have
experience
with
blockchain
or
any
related
technologies?
Please
raise
your
hands.
A
Okay,
nice,
it's
cool,
so
I'm
gonna
address
the
problem
with
my
presentation.
Today.
Okay,
we
have
IT
system,
we
have
block
J,
but
how
we
gonna
provide
the
final
user,
the
proof
that
the
data
is
actually
stored
in
this
block
chain,
that
the
data
is
have
the
same
state
as
it
was
before
when
the
transaction
was
recorded
and
I'm
going
to
explain
how
we
did
and
solve
this
problem
with
our
solution
in
this
acronym
a
couple
words
about
the
company
so
book
bitfury,
it's
a
global
blockchain
company.
A
A
A
What
is
the
proof
is
a
little
bit
theory
part
and
how
we
implement
it
in
our
in
in
code
in
our
solution
and
the
third
part
will
be
demo
so
the
exam
it's
open
source
before
framework
for
prefer
private
chains,
what
Spri
book.
So
it's
usually
the
book
change
that
can
be
used
between
some
organizations.
Usually
some
organizations
have
like
the
shirt
business
process
and
they
want
to
share
the
data
also
and
this
our
greens,
each
organization-
usually
don't
trust
each
other,
but
they
need
to
exchange
it
by
beta.
A
So
in
this
case
is
pride
watching
can
be
useful
X
on
them.
So
it's
already
on
point
source
for
about
1/2
year
about
30
developers,
working
on
this
project
and
most
and
mostly
it's
a
rat
developers,
and
so
it's
it's
a
purely
Liberty
and
business,
but
business
logic.
It's
up
on
the
developers
who
who
trying
to
build
something
on
top
agonal
as
the
consensus
we
using
TIF
district
consensus.
A
This
allows
will
rebuild
it
ourselves.
Its
allows
to
to
show
the
speed
of
transaction
processing
cup
5000
and
the
lintons
it's
about
zero
point,
zero
point,
five
seconds,
it's
mostly
for
for
the
network
delays,
plus
it's
for
block
issuing
and
with
using
standard
algorithms
that
everyone
using
in
industry.
A
We
also
develop
the
technology
anchoring
when
it's
useful.
For,
for
example,
we
have
four
nodes
and
we
have
be
50
consensus
with
three
nodes
and
it's
it
can
be
happen.
The
three
nodes
can
agree
to
like
to
check
the
first,
the
first
nodes
and
so
what
what
the
first
node
can
be
doing
in
this
case.
So
for
this
case
we
introduced
anchoring
technology.
What
is
what's
it
actually
do
so
we
get
the
hash
of
the
block
and,
for
example,
each
one
thousands
of
the
blocks.
A
A
A
Like
we
have
their
own
their
own
model
of
our
nodes,
we
have
actually
three
types
of
the
nodes.
The
first
node
is
validator,
it's
the
node
who
store
the
whole
copy
of
the
data
and
also
its.
Then
these
nodes
is
involved
in
the
consensus.
Also,
we
have
our
dieter
node,
so
it's
not
quite
the
same
as
validator,
but
it's
not
involved
in
the
consensus
and
decline,
a
light
client.
So
usually
it's
sitting.
Duration,
integration,
part.
A
A
Ok,
let's
move
on
to
cryptographic
proofs.
Firstly,
I
will
start
lives
with
theory
and
then
just
it
will
be
more
closer
to
the
Colton
to
the
our
solution,
the
first
our
exam
storage
based
on
the
rocks
GB.
So
second
beta
key
value
storage.
We
as
a
collection,
we
have
the
usual
position
collections.
It's
list
is
a
map
it's
set
and
also
on
top
of
it.
We
have
some
mechanised
collections.
It's
we
called
proof
appendix
and
proof
list
index
the
about
this
collection.
I
will
talk
a
little
bit
later
and
also
in
the
storage.
A
A
As
I
said
earlier,
we
had
visualized
collections,
it's
proof,
map
index
and
proof
list
index,
and
this
actually
collections
based
on
on
mere
cro3
data
data
collections.
So
what
what
we
are
using
using
this
for
the
first
deal
for
the
audition
to
calculate
the
pass
all
of
the
data
from
the
database
and
the
second
for
for
consensus
for
synchronization
of
the
data.
A
Here
we
can
see,
this
will
be
our
tables
that
presented
as
Merkle
trees,
for
example.
This
one
will
be
at
the
table
with
name
time,
stamping.
This
will
be
some
another
tables,
let's
code
users
and
then,
as
we
as
we
have
the
mirco,
the
describe
all
the
information
of
the
table.
We
can
collect
the
whole
the
one
common
table
or
common
three
that.
A
A
B
A
So
for
the
key
we
have
been
encode
the
key,
so
we
need
to
encode
our
tree
with
some
indexes.
So
how
do
we
encode
itself?
The
key
consists
with
hate
in
index
the
head:
it's
the
head
of
the
of
the
tree
and
the
index
is
the
position
like
if
we
called
horizontal
key
in
the
tree.
This
is
some
kind
of
example
how
how
some
values
will
be
stored
in
the
day
in
the
table
and
let's
move
to
the
proofs.
A
A
We
will
encode
it
as
a
JSON
file
and
this
JSON
file
we
can
send
to
the
to
the
client
and
the
client
on
on
on
his
side
can
calculate,
but
he
found
the
state
and
compared
with
the
state
that
writen
in
block
chain
for
the
proof,
appendix
we'll
use
a
little
bit
different
data
structure.
It's
murkrow
Patricia
tree,
it's
based
on
the
radix
tree
and
so
how?
How?
Let's
just
remember
how
radix
3
walks
we
have
some
index
and
based
on
similarity
index.
A
Let's
do
it.
It's
return
to
the
like
for
our
pictures.
We
have
our
database
and
the
user
now
I
want
to
request.
So
we
have
like
working
system
and
the
user
won't
want
to
like
through
the
web
client
want
to
request
the
proof.
His
has
some
record
and
he
want
to
get
the
whole
proof
how
his
data
record
stored
in
database.
A
This
is
how
it
will
be
looked
for,
look
wow
so,
for
example,
I'm
asking
for
for
the
data
with
ID
Bob
and
the
proof
the
full
proof
pass
will
be
like
here.
So
we
will
follow
the
pass
in
time.
Stamps
tables
then
we'll
fold.
The
past
means
in
our
common
state
hash
table
and
also
we
want
to
receive
some
information
from
the
blockchain
related
to
the
blockchain.
A
Now
it's
part
for
the
demo,
but
firstly,
I
won't
quickly
go
through
the
code
of
our
application.
The
demo
will
be
based
on
the
simple
application.
Is
time
step
we
called
time,
stamping
so
basically
housework.
We
have
file
alkalis
the
hash
of
the
file
and
we
put
in.
We
have
write
it
in
the
blockchain.
Why
we
need,
for.
We
need
to
make
a
proof
that
this
the
this
file
has
has
like
the
same,
the
particular
state
in
the
particular
time.
A
A
A
Here
we
are
describing
our
transaction,
and
this
is
our
business
logic.
What
we
will
do
without
injection
first,
we
will
verify
our
transaction
and
the
second.
We
will
do
some
execution
code
here.
We
will
call
our
database
checking
that
this
is
a
new
record
and
then
we
are
writing
this
worker
to
the
database
and
this
how
we
will
describe
our
database
here.
We
can
see
our
proof
appendix
and
we
call
our
table
this
time.
Stimac
timestamps-
and
this
is
auxiliary
function-
to
add-
to
write
our
data
to
database.
A
So
I
have
started
the
note
it's
started
to
work.
Then
I
will
start
my
web
application.
Then
I
will
go
to
my
application.
The
interface
is
quite
simple,
so
what
I
can
do
from
this
web
application?
I
can
upload
my
file
I'll
write
some
metadata
and
send
this
information
to
block
chain.
So
we
can
follow
the
transactions
and
check.
A
A
I'm
going
to
search
for
this
file
in
my
interface
and
then
when
I
call
this
search
actually
I'm
called
the
API
demo
input
and
the
it
VPA
input
provide
this
type
of
information.
So
what
we
have
here,
we
have
our
information
about
who
was
called
for
this
for
this
transaction.
We
would
then
we
will
have
the
information
about
our
state
hash
table
and
we
can
see
here
the
proof
pass,
how
we
can
find
this
information.
This
is
an
affirmation.
A
Is
it's
information
about
our
table,
so
we
are
storing
our
table
and
in
our
lake
state,
hash
table
state
hash
tree,
and
this
is
a
proof
how
we
will
search
how
we
search
this
table
and
then
we
have.
Then
we
have
our
time
step
proof.
This
is
for
the
value
that
we
uphold
it,
and
this
is
a
proof
pass
how
it
was
stored
in
the
tree.
A
A
Clearly,
then,
we
are
looking
for
our
table
in
our
state
hash
table
and
we
are
want
to
be
sure
that
it's
we
are
tracking
this
table
and
and
then
we
are
looking
for
our
record
record
actually
in
timestamp
table
and
checking
our
three
pass
on
the
client-side.
If
everything,
okay,
we
will
return
our
data.
A
How
do
you
look
like
on
them
on
the
exonym?
On
the
back
hand,
side
we
are
getting.
This
is
our
database,
so
we
are
firstly
requesting
the
information
from
the
database
about
our
last
block.
Then
we
are
equating
information
about
our
blocks
and
pre
chemists,
and
then
we
equate
requesting
our
proofs
for
this
table,
and
then
we
are
returning
on
this
information
for
for
our
Clyde.
A
B
A
A
So
yeah
we
have,
we
have
the
plans,
but
by
now,
like
all
like,
our
business
requirements
was
was,
was
fully
like
closed
by
or
but
the
Bitcoin,
and
it
was
by
this
moment.
It
was
quite
enough-
and
this
way,
and
also
we
were
quite
big-
support
the
Bitcoin
network,
this
wired,
but
also
like
this-
this
also
like
open
sourced
and
is
quite
easier
to
switch
to
another
upon
block
chains.
Okay,
thank
you
for
attention.