►
From YouTube: The Baseline Show: Office Hours, March 29
Description
This week we covered what's coming up for Baseline Reference Implementation 3 (BRI-3) Milestone 4!
Milestone 4: BRI-3 supports agreeing on shared state for a single happy case (Buyer, Seller, Order), setting up simple workflows and worksteps with all the necessary admin actions and triggering state changes with BPI messages to Transactions. All proofs are generated and stored accordingly and can be verified by the participants.
Baseline Protocol is an emerging standard for state synchronization across different systems of record. This standard can be applied to traditional corporate systems of record and utilize any kind of database or state machine, including different blockchains or distributed ledger technologies (DLTs).
Join us every Wednesday at noon EST on our live show, 'The Baseline Show'. Each week, we host industry leaders who share their insights and expert opinions on data governance, security, digital supply chain, multi-party workflows and collaboration.
#BaselineProtocol #DataManagement #Blockchain #DataSharing #MultiPartyWorkflows #DataGovernance #InformationSecurity #BusinessAutomation #BusinessSynchronization #DataIntegrity #IndustryTrends #LiveShow #LiveStream #LiveDiscussion #ExpertOpinion #YouTube #LinkedInLive #B2BBlockchain #DigitalSupplyChain #Innovation #SupplyChain
A
C
C
We
have
an
open
Office
hours,
we
do
not
have
a
guest,
but
we're
just
gonna
chat
about
stuff,
that's
going
on
in
the
Baseline
community
and
in
the
tech
World,
we'll
see
who
else
hops
on
our
live
studio,
and
we
do
have
guests
lined
up
for
the
next
two
to
three
weeks
actually
and
hopefully
for
the
foreseeable
future.
So
these
open
Office
hours
will
hopefully
become
the
rare
meetings,
but
we're
always
happy
to
to
do
them
still.
C
I
guess
what
is
up
Keith?
How
is
work
going
in
the
Bri
3
world,
the
post,
Milestone,
three
completion
and
moving
on
to
the
ZK
work?
Now
you
gave
us
a
walk
through
last
time.
You
ended
on
a
good
Cliffhanger.
That's
why
I'm
pointing
to
you
of
in
the
future.
I
can
show
some
more
code
but
I'll
I'll.
Let
you
tell
us
how
things
are
going
and
how
the
next
Milestones
starting
to
play
out
yeah.
A
Can
always
show
more
code
right,
you
know
we
can
always
go
I,
guess
in
depth
the
the
design
decisions
that
we
made
and,
and
you
know,
trade-offs
and
and
like
down
into
the
details-
I'm,
not
sure.
If
that's
you
know
what
everybody
wants
when
watching
the
show
I
mean
who
will
it
appeal
to
like
those
you
know
with
the
strong
technical
Dev
backgrounds,
we
can
always
use
some
more
of
those,
but
you
know
before
I
get
the
chance
possibly
to
go
into
that.
A
C
A
Okay
should
be
sharing
my
screen
now,
if
you
guys
can
see
right
so
I
go
to
the
screen
a
lot
whenever
we're
talking
about
bri3
SRI,
whatever
Milestones
we're
working
on
this
is
we
keep
all
the
issues
pertaining
to
bi3.
You
know,
inside
of
just
the
EA
Oasis
Baseline
issues
tab.
Here,
it's
going
to
be
mixed
in
with
you
know,
other
issues
of
people
working
in
the
open
source
Community.
Usually
this
should
be
a
SRI
tag
before
it.
A
We
try
to
stay
a
bit
mechanical
in
the
way
we
do
things.
It's
not
always
the
case.
Some
issues
are
written
off
the
cuff
from
things
that
we
missed
in
previous
meetings
or
things
that
need
to
be
corrected.
So
some
of
them
you'll
see
like
this
proposal
document.
This
was
actually
written
by
me
and
I
didn't
put
SRI.
B
B
A
A
You
know
add
it
to
the
various
storage
places,
one
of
them
being
on
chain
right.
So
there
is
no
reason
for
an
entity,
a
BPI
account
or
subject
to
say:
hey
here's
anchor
hash
created
on
chain
right.
So
this
is
a
simple
like
you
know.
Somebody
was
going
through
the
motions
and
creating
all
the
stuff
you
need
for
this
and
crash
controller
and
it's
internal
logic
and
they
opened
up
an
endpoint.
That's
like
a
small
piece
of
code
and
then
we're
like
okay
well,
this
is
not
really
necessary.
A
Let's
not
include
anything
that
is
never
going
to
be
used
right
or
shouldn't
be
used
right.
It's
not
open
ourselves
up
to
the
possibility
of
you
know
something
crazy
or
incorrect
happening.
Then
we
go
on
through
and
we
have
things
like
so
the
proposal
document
on
state
object
crud.
If
you
remember,
or
have
kind
of
listened
to
some
of
the
my
previous
rantings
on
how
we
do
the
open
source
work.
We
always
our
our
group
has
agreed
that
you
know
every
time
somebody
takes
up
a
task.
A
They
are
to
originally
create
a
proposal
document,
and
this
is
just
a
Google
doc
and
the
issue
there
should
be
an
issue
corresponding
to
that
document.
Right
so
I
need
an
issue.
Four
I'm
going
to
create
the
proposal
document
for
the
the
state
object,
the
crud.
You
know
the
create
update,
delete
all
that
other
stuff
for
for
the
state
object
inside
the
BPI.
So
we
create
an
issue
to
do
that.
We
create
the
documents.
A
I
I'd
say
maybe
in
the
last
week
I've
heard
from
five
people
who
want
to
get
involved
in
the
open
source,
deving
and
I
think
that
really
only
three
of
them
are
like
hardcore
coders
and
the
other
two
are
just
like
in
the
economics
slash
blockchain
area.
So
maybe
we
can
also
talk
about
how
they
can
get
involved
right.
B
A
Research
group
or
I'm
I'm
not
sure
exactly
what
they
were.
Imagining
I
think
they're,
imagining
something
more
Bri
three
for
helping
progress;
bri3,
so
maybe
maybe
a
new
research
topic,
or
is
that
you
know
taking
old
research
and
trying
to
apply
it
in
a
br3
implementation,
with
what
Mark's
doing
and
and
writing
out.
You
know
the
user
stories
and
the
test
case
and
getting
us
to
the
point
right
where
Dev
can
start
or
or
Outreach
or
something
else
right.
Yeah.
C
That's
a
good
idea,
like
even
documentation,
of
course,
or
even
with
the
upcoming
interoperability
use
case.
That's
been
identified,
we're
going
to
need
some
functional
Minds
in
between
the
use
case
and
the
technical
requirements,
but
there's
definitely
places
for
them
to
get
involved
or
room
for
them
to
even
give
us
ideas
on
what
they
envisioned
they
could
do
and
starting
it
up
for
them.
A
The
meeting
with
like
hey
here
are
the
actionable
items
that
we
all
need
to
do
right
and
Andreas
as
well.
Here's
the
actual
items.
So
it
would
be
nice
if
some
of
those
items
can,
if
we
have
this
uptick
and
people
want
to
participate
on
a
public
issues,
board
I'm,
not
sure
where,
maybe
maybe
in
the
the
standards
of
the
blip
Trooper,
whichever
one
and
then
we
can
point
people
there
and
be
like
hey.
A
It's
very
kind
of
relaxed,
there's
a
general
flow.
This
one
is
still
not
totally
complete
yet,
but
there's
a
general
flow
of
there'll
be
an
introduction.
Maybe
some
examples,
there'll
be
a
collection
of
all
the
requirements
that
relate
to
this
issue
from
the
the
standard,
the
Baseline
standard
and
then
below
will
be
kind
of
a
a
first
look
at
what
the
the
classes
or
the
kind
of
the
interfaces
for
the
objects
that
we'll
be
working
on
right.
A
D
A
System
a
curve,
hash
function,
witness
state
tree
so
on
and
so
forth
and
the
same
thing.
Well,
okay,
one
of
these
things
in
here
like
a
merkel-proof
witness.
This
is
like
the
type
of
the
witness.
Well,
it's
composed
it's
an
object
that
is
also
composed
of
many
things
right.
It
also
has
an
ID
root
hash.
So
that's
kind
of
the
first
task
is:
let's:
let's
look
at
all
the
requirements,
all
the
things
we
can
in
the
standard
and
let's
determine
what
do
these
objects
that
are
being
passed
around?
What
are
they
made
of?
A
A
So
it
is
not
everything
that's
done
in
in
the
dev
tasks,
but
it
is
like
the
the
very
beginning
to
start.
If
we
can
agree
as
a
group
that
all
these
things
a
state
object,
a
miracle
proof
witness
belief
are
composed
of
these
things.
Generally,
then,
it's
much
easier
to
start
out.
We
all
have
kind
of
like
a
consensus
that
this
is
what
it
should
look
like.
Of
course,
if
you
have
seen
me
share
code
before
there's
a
lot
of
you
know
in
between
right.
A
Not
only
do
we
have
these,
these
objects
themselves
right
with
these
things
like
ID
and
Merkle,
Trio
and
so
on
and
so
forth.
But
then
we
have
these
agents
that
are
deciding
you
know
how.
How
do
you
handle
trying
to
do
something
with
that
object
right,
like
I,
have
let's
say
a
BPI
Miracle
tree?
Well,
how
do
I
actually
create
that
Merkle
tree?
So
the
document
doesn't
just
outline,
you
know
every
single
thing,
it's
kind
of
the
general
shape
of
the
objects
you'll
be
dealing
with,
and
then
it's
up
to
you
to
go
in
code.
A
And
the
storage
agent
and
the
commands
get
executed
kind
of
you
know
between
right.
Then
this
between
is
when
the
information
enters
kind
of
from
the
outside,
like
I
as
a
subject,
want
to
create
a
Merkle
tree
or
a
state
object,
and
then
how
does
that
kind
of
propagate
through
the
system
right?
How
does
that
get
transformed
into
something
that
is
going
to
be
put
on
chain
going
to
be
put
in
store?
A
It's
going
to
be
put
in
a
Merkle
tree
right
because
as
it
flows
through
the
system,
you
know
it's
it's
going
through
its
kind
of
execution
process
and
it
exists
firmly
right
ephemerally.
So
once
once
it's
in
those
storage
places,
it's
really
no
longer
in
the
this
ephemeral
memory
of
the
system
itself
and
that,
if
you
need
it
again,
you
have
to
reach
back
out
to
those
places
stored
and
pull
it
it
back
in
as
kind
of
like
a
a
virtual
object.
A
So
all
that
handling
really
it's
handling
the
flow
of
those
things
is
what
you're
left
to
do
right
and
then,
of
course,
there'll
be
an
implementation
issue.
Corresponding
usually
comes
after
people
have
said.
Everybody
kind
of
signs
off
on
the
document.
They
said
the
one
that
I
just
showed
it's.
Okay,
all
right.
Well,
let's
have
an
implementation
issue,
that
kind
of
says
the
task.
What
do
I
need
to
implement
I
need
to
have
a
State
Credit
model.
I
need
to
actually
implement
the
the
create
the
read
the
update,
the
delete.
A
A
A
We
have
things
like
mocking
Prisma
way
in
a
way
that
allows
us
to
ditch
writing
mock
storage
agents
in
unit
tests.
So
right
now,
a
lot
of
our
unit
tests
are
using
like
a
mock
storage
agent,
because
when
you're
running
the
test
it
doesn't
have,
the
system
is
not
spun
up
right.
The
the
the
docker
storage
is
not
spun
up,
so
the
test
is
kind
of
running
outside
of
the
normal
execution,
so
it
doesn't
have
access
to
those
to
the
place
where
all
the
information
is
stored.
B
A
These
things
with
it.
Well,
if
I
tell
it,
oh
go
reach
out
to
the
database.
Well,
the
database
is
not
there
because
you're
running
a
test,
that's
outside
of
the
normal
execution
right.
The
execution
is
not
even
running
when
I,
when
I
run
the
test
right,
but
the
execution
of
the
BPI
so
instead
I
have
to
say,
okay.
Well,
let
me
just
whenever
you
go
to
run
this
test.
First,
let's
spin
up
like
this
ephemeral,
a
mock
database
which
is
really
just
a
a
couple
structures
in
typescript
right
and
say:
okay,
here's
a
state
object!
A
You
can
work
with
here.
Let
me
just
give
it
these
default
values
use
this
when
you're
running
the
test,
instead
of
trying
to
like
reach
out
to
a
database
right.
So
this
is
something
we're
trying
to
replace
with
like
an
auto
mocking
function
from
Prisma
Prisma
being
the
orm.
The
object
relational
mapper
that
allows
us
to
communicate
easily
with
the
actual
database
right.
One
of
the
functionalities
of
these
orms,
usually
they'll
make
available
is
a
way
to
mock
the
database
as
well
right
so
that
you
can
do
cool
things.
Tests
like
this.
A
This
is
the
corresponding
implementation
into
issue
for
the
state
optic
crud.
Here's
one
for
parse
messages
coming
in
the
announce
and
create
BBI
messages
that
are
persisted
in
the
database.
That's
Ogden's
issue
move
hard-coded
test
values,
so
we
see
a
lot
of
stuff
here.
Not
all
of
them
are
exactly
related
to
zkp
and
anger
stuff,
but
we'll
see
like
right
under
here
we
have
a
large
flow
of
the
Merkle
tree.
Crud
zkp
component
implement
the
circuit,
which
is
sri's
working
on
now.
Implement
State
object
as
input
anchor
hash.
A
So
here's
a
lot
of
the
zkp
stuff-
that's
actually
milestone
for
I
mean
some
of
these
other
things
are
just
clean
up
and
kind
of
technical
debt
that
we've
accrued
over
time
right
and
the
idea
behind
that
is
well.
Maybe
we
set
things
up
in
a
way:
that's
easy
to
run
it
and
given
its
current
status
and
Circumstance
like
of
the
BPI
right,
it
makes
it
convenient
for
us,
as
developers
to
spin
this
up
in
a
certain
amount
of
time,
with,
like
a
certain
amount
of
commands
and
and
run
this
thing.
A
But
then,
as
we
progress
and
the
BPI
actually
starts
to
take
True
Form.
Well,
then,
that
that
kind
of
like,
for
example,
the
mock
thing
that
we
were
doing
before
that
aids
us
it's
no
longer
useful
and
it
has
to
be
reconstructed
in
another
form.
That
is
useful
for
the
for
the
stage
that
we're
at
right,
because
we're
doing
all
these
development
stages
before
we
actually
get
to
the
true
real,
complete
thing
right,
and
so
some
tasks
are
related
to
that.
A
B
Keith
I
have
a
question
for
you.
The
state
object
is
a
pretty
fundamental
part
of
the
Baseline
standard.
It's
one
of
the
first
things
that
it
talks
about.
Would
you
mind
going
back
into
that
proposal
and
just
giving
us
a
little
bit
more
detail
about
how
you
and
the
team
are
thinking
about
representing
the
state,
object,
Within
a
BPI
and
give
us
some
context
on
how
you're
creating
the
interfaces
for
this
and
how
it
interacts
with
some
of
the
other
parts
of
the
code
and
Miracle
proof
witness?
Why
would
you
want
that?
A
Yeah
sure
I
can
do
that
so
I
started
compiling
all
this
stuff
and
then
I
reached
out
to
Andreas
and
I.
Just
said:
hey,
you
know,
you
wrote
the
standard
I've
been
reading
through
all
the
stuff
and
I'm
like,
and
this
is
I
was
like
this
is
kind
of
what
I
have
so
far.
But
you
know,
if
you
happen
to
just
know
already,
also
tell
me
what
you
think
it
should
all
the
qualities
it
should
possess
right
and
I,
just
straight
up
copy
and
pasted.
You
know
what
he
wrote
to
me.
A
And
so,
of
course,
we
have
the
state
tree
which
in
this
case
we
are
our
initial
implementation.
We
that
we
agreed
on
in
the
group
would
be
using
Merkel
proofs
right
in
reality,
it'll,
probably
end
up
being
a
a
merkel-proof
inside
of
a
ZK
circuit
and
that
ZK
proof
will
be
on
chain,
because
it'll
just
be
much
more
succinct
right
and
a
lot
of
this
information
is
is
has
to
be
attributed
to
the
work
that
this
washery
is
doing.
A
There's
another
large
document
that
I'll
go
find
in
a
second
the
kind
of
details,
kind
of
the
overarching
steps
along
this
flow
right.
So
this
is
only
one
part
in
the
flow.
Is
let's
decide
what
the
state
object
is
right,
so
we
have
the
state
tree
right
with
the
root
and
the
hashes
and
and
hashes
of
leaves
it
needs
a
pointer
to
the
storage
object
to
the
leaf.
A
A
When
all
those
things
come
together,
you
can
imagine
that,
as
being
turned
into
like
a
single
alphanumeric
hash,
that's
being
put
in
the
tree
to
say,
hey
we've
taken
everything
into
consideration.
This
is
the
new
overall
State.
Let's
go
ahead
and
kind
of
like
time
stamp
it
somewhere
or
let's
go
ahead,
and
let's
just
like
store
it
somewhere.
As
we
know,
this
is
the
most
recent
state
right.
You.
A
Yeah,
you
could
say
it:
I
mean
yeah,
it's
just
adding
a
new
Leaf
in,
and
so
that's
what
this
one
thing
is
here.
The
the
straight
state
tree,
the
Merkle
tree,
which
is
reliant
on
you,
can
see.
I
put
here,
oh
it's
relying
on
the
this
Merkle
tree,
crud
right.
This
is
another
outstanding
issue
that
we
had,
which
is
the
system
has
to
be
able
to
do.
The
create
read,
update
stuff
to
a
Merkle
tree
has
to
have
that
ability
doesn't
have
that
ability.
Yet
so
that's
the
one
that
I'm
like.
A
Working
on
and
which
I'm
pretty
much
done
with
and
should
be
able
to
peer
up
today,
I
believe
so
once
it
has
all
these
abilities.
Well
then,
it's
easy
enough
to
say:
okay!
Well,
let's
just
create
a
Merkle
tree,
let's
put
it
as
part
of
this
object
and
then
whatever
we
need
to
do
to
it,
you
know,
update,
it.
Add
leaves
that
should
all
be
handled
inside
this
crud
right
here.
So
this
is
like
a
essentially
a
state
tracker
right.
A
So
it's
in
a
lot
of
ZK
talks
and
you're
going
to
hear
like
what
prover
system
are
you
using
what
what
system
used
to
to
prove
that
things
are
what
you
say
they
are
that
the
state
is
what
you
say.
It
is
so
on
and
so
forth.
For
us
again,
the
first
approach
is
just
Merkel
proofs
right.
Let's
just
prove
that
this
thing
is
part
of
the
tree.
A
Let's
add
this
to
the
tree:
let's
prove
it's
part
of
the
tree
and
we
can
take
that
proof
and
we
can
pass
it
on
really
anywhere
because
we
want
to
do
it
on
chain.
It's
more
likely
that
it's
just
going
to
be
the
miracle
proof
inside
of
a
ZK
circuit.
In
this
case,
I
believe
SRI
is
doing
that
in
gunarch,
so
a
goaling
like
DSL,
ZK
and
and
she's,
and
so
that's
going
to
wrap
the
actual
Merkel
proof
because
of
the
way
that
the
proof
will
grow
over
time.
B
A
So
I
mean
this
is
something
that
I
don't
know.
All
the
CK
libraries
I
know
that
can
Arc
comes
with
this
functionality
out
of
the
box
right,
okay
and
it
actually
already
exists
in
our
our
open
source
circuit
that
we
have
within
the
consensus
mesh
repo
right.
It's
part
of
a
project
that
we've
done
before
this
is
comes
out
of
the
box
with
them
they're
always
actively
Deming.
So
there
can
be
some
amount
of
of
I.
A
Don't
know,
finagling
that
you
need
to
do
to
make
this
work,
but
for
the
most
part
you
should
be
able
to
access
their
API
inside
the
circuit
and
just
say:
hey,
you
know:
I
want
to
do
a
Merkel
proof
right
like
it's.
You
know
the
code
is
going
to
be
like
API
dot.
Let
me
you
know
Merkel
proof
whatever,
and
then
it's
going
to
accept
a
certain
amount
of
parameters
that
are
being
put
in
there
and
it
will
do
the
Merkle
proof
for
you
inside
the
circuit.
A
But
if
you
needed
to
all
the
tools
you
know
would
be
there,
and
you
would
essentially
just
have
to
do
some
kind
of
take
what
you've
been
given,
which
essentially
will
be
like
the
root
hash
you're
going
to
be
given
belief,
you're
trying
to
prove
that's
kind
of
included
in
the
Merkle
tree
and
then
you're
going
to
be
given
a
path,
a
path
of
ones
and
zeros.
That
represents
kind
of
like
left
and
right
as
you're
going
up
the
tree
because
in
reality,
right
you're.
A
Looking
at
the
trick
from
like
the
bottom
up
right,
the
bottom
leaves
and
then
all
the
way
up
to
the
I
mean
you
can
imagine
it
like
this
as
well
right,
but
a
lot
of
the
time
you'll
see
it
with
the
bottom
leaves
bottom
leaves
are
the
most
recent
and
you're
saying.
Okay.
This
is
your
Leaf
here
all
right
and
you
want
to
do
a
proof
that
it
actually
is
included
in
the
tree
we've
given
you've.
A
Given
this,
we
have
the
root
hash,
which
is
what
we
should
end
up
at
the
end,
and
then
we
have
the
path,
that's
kind
of
how
you
travel
up.
The
tree,
and
so
essentially
you're
taking
two
kind
of
passion
together
and
then
getting
the
next
part
of
the
tree
and
so
on
and
so
forth.
Until
you
get
to
the
last
one-
and
you
say:
okay
well,
the
root
house
that
I
made
based
on
the
leaf
and
the
pap
should
match
the
root
hash
that
was
given.
If
it
doesn't,
then
something
is
wrong.
A
A
Proof
of
you
know
that
your
Leaf
is
included
in
the
given
tree,
so
we
don't
need
to
provide
anything
else,
but
the
actual
ZK
proof
at
that
point,
and
then
some
way
for
people
to
verify
it
right,
which
can
be
done.
It
could
be
done
on
chain
right
with
solidity
contracts.
Right
narc
also
has
most
a
lot
of
other
ones.
Also
have
the
ability
to
export
the
verifier
and
prove
a
release
to
solidity
but
verifier.soul,
and
then
you
can
put
it
up.
Yeah.
A
Yeah
cool
and
then
there's
a
couple
other
things
right,
proofer
system,
well
how
we
create
an
improve
in
this
case.
It's
a
miracle
proof.
What
curve
we're
using
well
we're
not
using
a
curve
because
Merkel
proof
right
if
we're
doing
something
else,
graph
or
Punk,
then
you'd
have
to
choose
some
electrical
curve,
a
hash
function,
and
this
one
we're
just
going
with
you
know
a
real
standard
like
shot
through
256.
Most
of
our
implementations.
A
The
idea
is
well,
let's
just
go
with
whatever
something
very
standard
is,
and
let's
make
that
our
first
one
and
then
as
soon
as
we
get
all
that
working,
then
we
can
make
things
more
Dynamic
right
to
where
you
can
choose
a
certain
hash
and
so
on
and
so
on
and
so
forth.
Right,
which
is
it's
not
a
terribly
difficult
task
right
when
you
think
about
it
like
one
at
a
time?
A
So,
instead
of
worrying
about
all
that,
the
first
idea
is:
let's
just
make
it
work
with
a
very
standard
default
case
and
then
kind
of
expand
the
system
from
there
and
then
you'd
have
the
witness
so
the
root
hash,
the
Merkel
proof.
You
know
the
the
leaf.
In
this
case
the
leaf
would
be
the
signed
document
by
the
buyer
and
seller.
Two
six
one
over
there,
each
other
encrypted
data
used
to
validate
the
transition
so
on
and
so
forth,
right
and
I
think
that's
pretty
much
it.
A
We
can
see
here
proof
system,
curve,
hash
function,
the
witness
state
tree
and
the
witness
itself
is
going
to
be
made
up
of
all
the
things.
I
talked
about
that,
you
need
to
construct
the
Merkel
proof
right,
whether
it's
inside
or
outside
of
the
circuit
right
you're
going
to
need
the
root
hash
to
compare
at
the
end
and
say
all
right.
Well,
the
root
hash
we
calculated
is
the
root
half
that
they're
saying
is
kind
of
the
source
of
Truth.
A
A
And
then
for
us
I
mean
it
can
be
many
things
for
many
different
bpis
for
us,
it's
just
simply
well.
This
is
the
the
document
hash,
the
the
half
of
the
document.
That's
representing
you
know
the
state
change,
and
then
you
know
the
the
two
entities
interacting
saying:
okay,
yeah
we
signed
off
on
this
thing
right
the
state's
been
passed
back
and
forth.
They
both
sign
off.
This
is
okay,
let's
add
it
to
the
states,
and
so
that's
the
the
actual
Leaf
that's
being
added
into
a
tree.
Yeah.
B
A
B
A
These
things
need
to
happen
before
this
thing
becomes
kind
of
like
a
commitment
to
the
tree.
Saying
like
this
is
the
new
state
right.
We
need
both
sides
to
sign
off
and
say,
like
Bob
and
Alice,
to
say-
and
maybe
this
is
a
good
time
to
show
the
overarching
document
yeah.
Let's
do
it,
we
need
both
sides
to
say:
hey
we
have
signed
off.
This
is
the
correct
State.
Now
now
it
can
be
added
to
you
can
see.
The
Merkle
tree
almost
has
like
just
a
storage
of
things
that
have
happened
and
we've
agreed.
A
They've
happened
kind
of
correctly
right,
and
this
is
a
pretty
long
document
that
biswashery
has
put
together
detailing
everything
you
know
here
is
a
proposed
flow.
Alice
proposes
a
document
to
Bob.
The
initial
state
of
the
document
is
captured
in
the
state
object
right.
So,
in
the
same
object
in
the
leaf,
there
was
the
actual
document
itself.
The
same
object
acts
as
a
common
print
reference
for
the
participants.
A
Group
and
after
updates
or
changes
proposed
by
the
worker
participants,
finalized
State
object
containing
the
document
is
anchored
to
the
ccsm
right
so
once
and
that
is
kind
of
like
skimmed
over
our
once
all
the
work
group
participants
have
finalized.
You
know
the
stocking,
meaning
they
signed
off
on
it
and
one
of
those
that
signing
really
look
like
we'll
encode.
A
We
just
decide
a
cryptographic
mechanism
for
somebody
to
sign
off
on
this
object,
and
then
it
usually
includes
them,
providing
like,
for
example,
using
their
private
key
to
create
a
signature,
I'm
sure
we've
all
seen
like
where,
where,
if
I
want
to
send
a
a
you
know,
a
message
and
encrypted
message
to
Mark
or
I
want
to
sign
to
make
sure
it's
from
me.
I
can
sign
with
my
private
key.
Anybody
can
have
my
public
key
and
they
can
say
okay.
A
A
So
so
you
know,
depending
on
how
we
want
to
implement,
use
some
cryptographic
mechanism
to
allow
them
to
sign
using
some
private
piece,
private
key
that
corresponds
to
a
public
key,
the
account
that
they
have
inside
of
our
database
and
and
then
once
it's
finalized.
It's
gonna
be
added
into
the
Merkle
tree
and
yeah.
So
I
encourage
you
to
take
a
look
through
this
document.
You
not
only
get
a
feel
for
the
overall
flow
of
Milestone,
four,
all
the
components,
State
history.
A
You
can
also
see
you
know
on
the
side
the
conversations
we've
been
having
a
lot
of
our
work
is
done,
asynchronously
right,
a
majority
of
the
work
we
meet
once
a
week,
maybe
30
minutes
at
most,
and
so
the
majority
of
work
is
done.
Asynchronously
right
and
this
not
only
will
this
document
give
you
a
good
idea
for
what
you
know:
Bri
3's.
First
implementation
of
Milestone
4
is
going
to
be
with
content
adjustable
hashes.
A
You
know
on-chain
off
chain,
his
State
history,
the
blockchain
service,
the
zkp
proof
service
inside
of
van3,
but
will
also
give
you
a
good
idea
of
you
know
how
to
take
this.
In
a
modular
fashion
and
really
implement
it
in
any
other
project
that
you
have
as
well
right,
is
it
it's
specific
to
a
lot
of
the
requirements
for
based
on
critical
implementation?
B
A
C
C
A
Oh
I
mean
of
course,
of
course,
it's
reusable
yeah,
not
only
I
mean,
could
it
become
a
just
implementer
guide
for
the
specific
way
we've
done
it,
but
even
with
a
little
bit
of
kind
of
generalization
throughout
some
of
these
documents,
or
even
just
you
know,
through
the
minds
of
any
person
who
is
a
developer
and
wants
to
look
at
this
or
is
not
and
say,
okay,
I've
seen
what
they've
done.
Let
me
do
my
own
twist
on
this.
Let
me
do
this
instead
of
Miracle
proofs.
A
Let
me
do
it
that
way
so
on
and
so
forth
that
it's
it's,
you
know
sometimes
as
a
developer,
I,
don't
even
I,
don't
care
if
I
have
a
guide.
That's
like
this
is
the
best
way
to
do
it,
or
this
is
the
only
way
to
do
it.
It's
just
like
show
me
a
way
to
do
it
and
then
I'll
be
able
to
say
like
okay
I
want
this
to
be
different.
That's
you.
A
A
And
yeah
here
it
is
you're
right.
It
was
in
blips,
Baseline
blips.
If
you
just
go
to,
if
you
scroll
on
down
right
there,
the
third
one
from
the
top
number
32,
SRI
VR3
overview
and
I,
it
should
be
pretty
much
up
to
date.
There
might
be
a
couple
missing
of
like
the
very
newest
ones:
documents
we've
created,
but
generally
you
all
keeps
us
pretty
pretty
tight
and
adding
everything
in.
Actually,
you
might
have
everything
I
don't
know
cool.
C
D
D
You
know
bettering
use
right
now,
particularly
multi-party.
When
the
you
know,
when
a
certain
number
of
the
parties
exist
outside
of
corporate
borders.
How
can
you
share
data
with
them
without
revealing
anything
that
might
get
you
in
trouble
or
might
at
least
give
them
a
competitive
advantage
over
you?
Because
they
now
know
you
say
your
pricing
lists,
or
they
know
your
customer
list,
and
you
know
inventories
anything
like
that.
D
You
want
that
to
remain
quiet,
so
we
look
at
you
know:
shared
architectures,
EDI,
public
and
private
blockchains,
really
giving
an
idea
in
a
non-technical
fashion
as
far
as
how
these
are
used
and
what
they
may
be
good
for,
and
what
what
some
of
the
trade-offs
and
some
of
the
challenges
that
come
with
adopting
these
so
watch
this
space.
We
want
to
publish
it
tomorrow,
as
always
said,
subtle.
C
D
So
watch
the
space
on
that
and
right
now,
of
course,
you
know,
you've
got
a
lot
of
stuff
in
the
larger.
You
know
space
right
now
to
where
you've
got
chat,
GPT.
That
is
really
getting
a
lot
of
attention
right
now
and
they
can
write
all
of
our
term
papers
and
you
know,
maybe
make
marketing
materials
a
lot
quicker
to
spin
up
and
stuff.
But
you
know
the
one
thing
that
I
look
at
when
it
comes
to
chat
GPT
is
it
does
not
have
the
ability
to
discern
what
is
confidential
data
or
not.
D
You
know,
and
it's
certain
people
have
kind
of
looked
at
that
and
said.
Well,
you
know
if
you
want
to
ask
chat,
GPT
how
to
build
a
bomb
or
how
to
you
know,
make
meth
or
something
like
that.
That's
going
to
be
something
to
where
they're
saying
no
I'm
not
going
to
teach
you
how
to
do
that.
But
what
happens?
If
you
have
perfectly
legal
but
sensitive
data
that
is
not
meant
to
be
shared
by
others,
chat,
GPT
right
now,
I,
don't
I
haven't
seen
that
it
can
tell
the
difference
between
the
two.
D
So
if
you're
using
it,
you
know
for
an
AI
engine,
you're
going
to
need
to
really
train
your
models
to
be
able
to
know
the
difference,
and
so
that
you
don't
you
know
inadvertently,
reveal
something
that
you
haven't.
So
that's
just
the
one
thing
that
I've
looked
at
I,
don't
know
if
anybody
else
came
up
with
that
say
impression.
D
D
So
you
want
to
make
sure
that
if
you're
making
substantive
decisions,
you
want
to
make
sure
that
that
data
is
uniform,
correct
relevant
to
what
you
are
trying
to
get
an
outcome
outcome
to
make
a
decision
around,
especially
if
that
decision
is
going
to
affect
someone's
health
or
their
finances
or
anything
else.
So.
B
Yeah
one
one
idea:
I
had
a
while
ago,
probably
not
the
first
time
someone
had
that
idea
was
verifiably
trained
AI
models
under
zero
knowledge,
I
think
I
floated
that
idea
to
Andreas,
but
I
think
I,
don't
know
Andres
I.
Remember
you
having
some
thoughts
on
that.
I
can't
remember
really
what
you
said
about
that,
but
I'm
sure
there
are
a
lot
of
people
thinking
about
using
using
ZK
for
for
AI,
but
yeah.
It's
an
interesting
concept.
Do
you
remember,
do.
E
Yeah,
well,
you
know
it's
like
it's
like.
You
need
a
super
computer
to
to
to
to
to
to
patrol
a
supercomputer
right,
because,
because
it's
just
yeah,
of
course
you
can
do
it,
but
it
becomes
enormously
computationally
expensive.
Just
because
of
all
the
you
need
to
it's
just
it's
just
it's.
Just
such
an
enormous
amount
of
of
operations
that
are
happening
it
just
becomes
becomes
not
not
feasible.
Now,
on
the.
E
What
is
interesting
is
is
is
saying,
you
know,
does
this
you
know
do
I
am
I,
am
I
am
I
generating
the
same,
am
I,
generating
the
same
answers
that
I
generated
before
for
the
same
question.
So
it's
like
it's
like
as
a
as
a
as
a
as
a
check.
Those
are
those
are
type
of
things
where
you
can
you
can
you
can
you
can
think
about
maybe
or
whether
you
know
a
a
you
know.
They're
using
you
know,
they're
using
the
same
models.