►
From YouTube: Hyperledger Labs: Private Data Objects (PDO)
Description
A virtual meetup hosted by Hyperledger Kansas City on October 13, 2021 featuring Mic Bowman, a principal engineer at Intel Labs, Hyperledger Technical Steering Committee member, and computer science Ph.D. holder, speak on the Private Data Objects lab. Specifically, he will cover how to integrate code from a lab into Fabric.
Private Data Objects (PDO) enables sharing of data and coordinating action amongst mutually distrusting parties. Interaction is mediated through a “smart contract” that defines data access and updates policies that are carried with the object regardless of where it resides or how often it changes hands. The smart contracts policies are enforced through execution in a Trusted Execution Environment (TEE).
PDO provides benefits for both application developers seeking to define and implement privacy-preserving distributed ledgers, and for service providers seeking to provide blockchain services.
More about Private Data Objects is at: https://github.com/hyperledger-labs/private-data-objects
More about this event is at: https://www.meetup.com/Hyperledger-Kansas-City/events/280944843/
----
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 #HyperledgerMeetup #Blockchain
A
A
Thanks
matt
yeah
hi
everyone.
This
is
dave,
pitt,
keel
software.
We
were,
we
kind
of.
We
started
up
the
the
meetups,
I
think
during
the
pandemic
we
kind
of
dialed
that
back
a
little
bit,
but
we're
gonna
start
initiating
those
again
and
we
we
we
play
around
with
hyper
ledger
and
do
some
stuff
with
it.
I
personally
have
some
some
some
experience
with
it,
but
we're
excited
to
hear
about
private
data
objects
and
with
intel.
A
B
B
As
dave
mentioned,
I
built
the
original
te-based
consensus,
algorithm
called
proof
of
elapsed,
time,
which
is
a
very
efficient
decentralized
consensus.
Algorithm
based
on
trusted
execution,
environments.
Okay,
so
all
that's
background.
So
what
I
want
to
talk
about
today
is
a
thing
called.
Private
data
objects,
like
I
said
it's
a
hyperledger
lab
project,
and
it's
really
at
its
core
is
about
how
we
can
do
community-based
or
decentralized
computing
on
data
that
has
confidentiality
and
privacy
requirements.
B
So
kind
of
you
know
step
back
for
a
second
we're,
just
just
the
motivation
parts
of
this.
What
is
it
that
prevents
data
sharing
right
now?
Obviously,
there's
some
issues
with
access
that
data
is
not
always
available
to
us.
We
can't
get
at
it.
There
is
risk,
that's
associated
with
it
and
that
risk
is,
is
inappropriate,
use
or
misuse
or
monetization
of
the
data
that
that's
inappropriate
for
it
or
inconsistent
with
the
creators
of
the
owner's
responsibility
and
then
there's
this.
B
This
ongoing
sense
of
loss
of
control
that
you
know
our
data
sharing
interfaces
and
apis
tend
to
be
fairly
low
level.
If
I
give
you
something
you
can
do
whatever
you
want
with
it,
even
if
it's
not
what
I
intended
for
you're,
generating
huge
amounts
of
data
that
data
about
how
you
drive-
and
it
creates
this.
This
kind
of
high
excuse
me,
high
dimensionality,
high
detailed
profile
of
you,
as
a
driver.
B
So
the
the
problem
in
general,
with
insurance
for
sort
of
long-lived
or
with
short-lived
interactions
like
when
we
have
you
know
a
number
of
rental
cars
and
other
things
is
that
we
can't
really
use
that
profile
in
order
to
get
our
insurance
codes.
So
what
we'd
like
to
be
able
to
do
is
use
a
profile
that
we've
that
we
generate
be
able
to
get
a
quote.
B
That's
representative
of
the
what
we
are
as
a
driver,
but
at
the
same
time
we
really
don't
want
the
information
about
us
that
the
very
personal
information
about
places
we've
been
and
things
we
have
done.
That
could
be
inferred
from
that
profile
to
be
leaked
out
to
the
insurance
company.
They
have
no
business.
Knowing
you
know
that
they
they
have
a
reason
to
know
how
good
a
driver
we
are,
but
not
where
we've
been,
and
so
how
can
we
do
those
kinds
of
computations
for
it
and
it
brings
up
a
bunch
of
questions.
B
You
know
they're
kind
of
about
our
data
sharing
issues.
Where
do
you
store
the
profile
who
gets
access
to
the
profile
and
then
there's
a
bunch
of
these
sort
of
integrity
things
like
well.
If
I
can
give
the
insurance
company
my
profile,
why
would
they
even
believe
that
it's
an
accurate
representation
of
me?
B
You
know
I
may
be
lying
just
so
that
I
can
get
a
better
rate
for
it
and
and
sort
of
the
converse
is
that
if
I
give
my
instructor
my
profile
to
the
insurance
company,
why
do
I
believe
that
they'll
delete
it
when
they're
done
or
if
I
choose
a
different
insurance
company
and
then
a
bunch
of
sort
of
other
things
are
related
to
this,
like
okay?
So
the
profile
that
I
create?
B
So
what
we
would
really
like
to
be
able
to
do
is
to
have
the
sort
of
trusted
party
that
that
we
could
give
our
data
to
the
insurance
company
could
give
their
analytics
algorithms
to,
and
everything
takes
place
and,
and
the
trusted
party,
we
believe,
will
not
leak
any
information.
It
verifies
the
integrity
of
everything
and
it
generates
this.
This
insurance
quote
so
that's
the
ideal
is,
is
that
we
have
this.
B
This
trusted
party
that
we
can
create
that
has
those
those
properties
with
it
and
it
it
turns
out
that
this
sort
of
notion
of
a
trust
that
their
party
ends
up
in
a
lot
of
different
situations.
So
we
did
some
work
with
ibm
on
alternative
ways
of
doing
blockchain
based
seal
bid,
auctions
for
wireless
spectrum,
and
it
turns
out
it
has
some
of
the
same
characteristics
that
the
government
kind
of
wants
to
get
out
of
the
business
of
managing
all
the
sealed
bids.
B
So
how
can
they
create
this
trust?
Third
party?
They
could
actually
manage
the
entire
auction
and
ensure
that
the
auction
is
fair,
ensure
that
the
correct
bidder
wins
but
never
expose
the
information
to
any
of
the
parties
who
are
participating
and
we've.
You
know
we're
going
through
the
hyperledger
election
right
now.
This
is
this
has
actually
come
up
several
times
about
some
of
the
problems
related
to
organizational
elections
and
you'll
notice.
B
But
but
these
kind
of
organizational
elections
like
electing
the
hyperledger
technical
steering
committee
that
we're
going
through
right
now
that
again,
what
we
would
really
like
to
be
able
to
do
is
to
remove
the
election
staff
from
that
trusted
computing
base
and
have
some
kind
of
third
party
which
can
enforce
the
rules,
seize
all
the
data
and
which
everyone
trusts
to
generate
the
right
results
that
are
coming
out
of
it,
and
so
we
go
back
and
kind
of
look
at
this
trusted
party.
The
properties
that
we
would
really
like
are
things
like.
B
Well,
we
want
high
integrity
data.
We
want
to
know
that
the
data
is
trustworthy
and
a
lot
of
times
that
has
to
do
with
things
like
provenance.
We
want
to
be
able
to
prove
or
verify
that
the
data
that's
coming
in
has
the
appropriate
history
for
it,
and
we
we
talk
a
lot
about
things
like
privacy
and
confidentiality.
B
You
know
the
lab
I
work
in
is
the
the
security
and
privacy
research
lab,
but
a
lot
of
times.
We
really
don't
understand
what
that
means,
and
in
fact,
privacy
and
contextual
or
confidentiality
are
really
sort
of
in
context,
and
so
really
what
we
want
is
not
necessarily
privacy
and
confidentiality
is
sort
of
this
broad
spectrum
of
definitions
for
it.
What
we
really
want
is
for
the
data
to
be
used
in
the
way
that
we
intend
for
it
to
be
used.
We
want
to
be
able
to
say
it's.
B
That
there
is
no
one
that
you
would
trust,
because
anyone
who
has
the
information
has
the
ability
to
manipulate
the
auction.
That
way-
and
there
are
a
bunch
of
these
other
properties
as
well-
which
we're
not
going
to
talk
about
today,
like
commensuration,
which
is
you
know,
how
can
we,
how
can
we
make
data
monetizable
that
way
and
then
and
then
things
like
scarcity,
for
it
have
to
be
a
part
of
that
as
well?
B
We
can
come
back
and
talk
about
nfts,
another
time
on
that
by
the
way,
if
there
are
questions
on
the
chat,
I
because
of
the
way
the
setup
is
right
now
I
do
not
have
access
to
the
chat,
so
please
just
break
in
and
ask
all
right
so
anyway,
those
are
the
kind
of
problems
that
we're
trying
to
solve
is.
Can
we
create
that
trusted
third
party
using
technology?
B
In
particular,
you
know
combinations
of
smart
contracts
and
blockchain
and
other
things
in
order
to
create
that
trusted
third
party
that
allows
us
to
do
these
multi-party
kind
of
confidential
applications
with
it.
So,
as
david
mentioned
at
the
at
the
very
beginning,
you
know
there's
this
special
kind
of
hardware:
that's
really
been
kind
of
the
core
of
our
work.
B
This
first
showed
up
in
the
sawtooth
consensus,
algorithms,
the
proof
of
elapsed,
time,
consensus,
our
room
and
satu
started
with
that
way.
It
has
shown
up,
in
a
number
of
of
other
blockchain
related
projects,
from
some
of
the
work
done
at
cornell
to
on
off
chain
layer,
two
contracts
to
some
work
on
secure,
oracles
and
high
integrity,
oracles
that
are
moving
data
out
of
the
real
world
into
the
blockchain.
B
So
this
trust.execution
environment
has
been
used
in
a
lot
of
different
places
and
basically,
what
a
trusted
execution
environment
is
is
a
way
for
us
to
execute
code
on
data
in
a
way
so
that
even
the
owner
of
the
server
can't
look
at
the
computation
and
can't
look
at
the
results
of
the
computation
that
way.
So
it
gives
us.
You
know
we.
We
talk
about
encryption
being
used
to
protect
data
in
transit
and
encryption
being
used
to
protect
data
in
at
rest.
B
We
can
add
data
in
there
that
can
be
processed
inside
this
enclave
and
the
owner
of
the
machine
doesn't
have
the
ability
to
to
actually
look
at
it.
The
second
really
useful
property
of
these
trusted
execution
environments
is,
you
know
the
first
is
sort
of
then
the
big
one
everyone
talks
about
is
a
confidentiality
parts
of
it,
but
the
second
part
is
integrity,
and
what
that
means
in
this
case
is
that
I
can
perform
this
computation
and
assuming
the
computation's
sufficiently
deterministic.
B
I
can
prove
to
you
as
a
third
party,
that
I
did
the
computation
and
that
I
did
it
in
the
way
that
you
expected
us
expecting
me
to
do
it,
and
I
can
prove
that
to
you
without
giving
you
all
of
the
details
of
the
computation
itself
and
and
that's
kind
of
a
useful
thing.
When
you're
working
with
these
decentralized
blockchain
systems
that
that
I
can
perform
a
computation,
I
can
do
a
transaction
on
state.
B
B
So
there
are
a
bunch
of
advantages
with
performance
and
efficiency
that
that
we
only
have
to
do
this
competition
once
rather
than
you
know,
like
ethereum,
where
we
have
to
do
every
smart
contract
transaction
on
every
single
client.
That's
participating
in
the
validation
parts
of
it,
but
it
also
means
that
that
we
don't
have
to
do
this
sort
of
on
chain
that
the
smart
contract
execution
doesn't
have
to
be
on
chain.
B
You
can
trust
the
results,
because
the
trusted
execution
environment
basically
signs
off
on
on
the
transactions,
and
you
get
all
the
confidentiality
that
you
need.
So
I
can
put
confidential
data
into
it.
I
can
perform
some
computation
on
it.
I
can
get
some
results
back
out
of
it
and
at
all
times
that
data
is
protected
from
from
access.
So
really
what
it
comes
down
to
is.
Private
data
objects
is
smart
contracts
for
data
access
for
confidential
data
access.
B
As
I
said
before,
we
encrypt
the
data.
It's
not
just
sufficient
to
have
the
data
you
have
to
have
the
key.
The
key
is
placed
inside
the
enclave
in
a
way
so
that
nobody
gets
access
to
the
key.
That
way,
we
wrap
the
data
with
a
smart
contract.
This
allows
us
to
formalize
the
kind
of
access
and
update
policies,
so
that
contract
represents
the
agreement
between
us
about
what
is
an
acceptable
use
for
that
data.
Remember
we're
talking
about
you
know.
B
We
can
perform
very
complex
computations
inside
these
smart
contracts
and
we
have
some
examples
that
are
doing
inferencing
on
images
in
order
to
be
able
to
do
object,
detection
on
the
images
so
we're
able
to
do
some
fairly
complex
things
in
these
contracts
as
well,
and
then
we
use
the
blockchain
as
the
root
of
trust.
So
the
blockchain
serves
a
couple
purposes
for
us
one.
B
It
becomes
a
registry
of
all
of
the
objects
and
all
the
components
and
the
infrastructure
pieces
of
it
so
that
we
can
verify
the
identity
and
the
integrity
of
the
components
that
are
being
used
for
it.
The
second
is
that
it
becomes
kind
of
a
transactional
log
of
state
changes,
and
so
what
we
do
with
the
state
changes
in
in
the
blockchain
for
us
is.
B
We
basically
take
a
hash
of
the
data
that
was
going
into
the
operation,
some
information
about
the
operation
that
was
performed
and
the
hash
of
the
data
that
came
out,
and
so
that's
what
a
transaction
was
on
the
blockchain.
So
there's
no
real
data
about
the
pdo
that
goes
on
to
the
chain,
just
the
hashes
in
the
transaction
and
then
there's
a
signature
by
the
te
that
performed
that
computation.
B
B
A
B
So
they're
they're
attempts
to
solve
similar
kinds
of
problems,
but
there
are
several
different
assumptions,
so
the
private
data
objects
basically
assumes
that
the
information
that's
collected
here
unless
you
are
specifically
given
permission
to
it.
No
one
has
the
right
to
see
it
with
private
data
collections,
there's
essentially
an
access
control
list
for
everyone
who
gets
access
to
and
shares
that
and
any
chain
code
that
needs
to
be
able
to
compute
on
that
private
data
collection
has
to
have
access
to
that
to
the
to
the
pdc.
B
So
really
what
a
pdc
is
is
a
collection
of
data
that
is
off
chain
allows
computation
on
chain
without
exposing
the
specific
details
of
that
computation
to
anyone
other
than
the
parties
that
are
explicitly
allowed
to
access
it.
So
the
private
data
collections
is
not
so
much
prevent
anyone
from
doing
it.
It
basically
says
here's
the
list
of
people
that
are
allowed
to
do
it
and
we'll
allow
them
to
to
perform
the
computation
on
it.
B
All
right,
then,
we'll
keep
going
and
again,
like
I
said
you
know,
feel
free
to
interrupt
if
there's
anything
that
that
you'd
like
to
talk
about
all
right.
So
we
can
go
back
to
this
example
that
we
started
with
with
the
driver
profile
and
again
I
apologize
my
camera's
on
one
side
and
my
screen's
on
the
other
side,
it
bugs
me
to
no
end
when
I
have
to
look
one
direction
to
the
other
on
these
on
these
zoom
meetings.
So
I
will
just
apologize
for
that.
B
So
the
idea
behind
the
transit
driver
probe,
I
remember,
is
we
wanted
to
create
that
trusted
third
party
that
enforced
the
rules
of
computing.
The
the
contract
that
way,
and
so
what
we'd
like
to
be
able
to
do,
is
to
move
all
of
that
information
into
a
private
data
object
that
can
actually
do
the
computation.
So
we
create
a
pdo
for
the
driver
profile
that
gives
us
a
way
of
verifying
the
integrity
of
the
profile.
B
We
create
a
pdo
for
the
driver
contract
or
for
the
the
evaluation,
insurance
quote
analysis,
and
then
we
provide
a
means
to
bind
those
two
together
so
that
the
insurance
contract
can
perform
operations
on
the
driver
profile
data
without
ever
exposing
that
information
back
to
the
insurance
company.
So
since
the
computation
happens,
the
evaluation
of
my
profile
happens
inside
the
pdo.
B
At
no
point
is
my
profile
exposed.
I
can
examine
in
theory.
I
can
examine
that
insurance
contract
and
look
to
see
that
it
never
leaks
any
information
so
that
I
can
establish
my
own
trust
in
it
that
I'm
willing
to
give
my
profile
to
it
and
the
insurance
company
that
the
evaluation
contract
can
go
back
and
look
at
the
driver
profile
and
verify
that
the
driver
profile
does
not
provide
hooks
so
that
the
driver
can
cheat
by
rewriting
their
history.
B
That
is
the
driver,
can't
go
in
and
remove
an
accident
from
their
history
just
so
that
their
profile
would
look
good.
So
we
get
this
sort
of
bi-directional
integrity
check
and
then
all
of
the
computation
happens
inside
these
objects.
So
we
can
get
a
high
quality
quote,
knowing
full.
Well,
that
the
that
the
information
that
we're
providing
is
not
misused,
it's
used
only
in
the
way
that
that
we
have
authorized
its
use
in
this
case.
B
So
in
that
way,
the
pdos
create
that
trusted
third
party
that
we
were
looking
for
all
right.
So
architecturally,
there
are
a
bunch
of
different
moving
parts.
Here
we
have
some
issues
with
being
able
to
to
basically
create
and
provision
the
contract
objects
onto
a
set
of
these
trusted
execution
environments.
B
There's
a
decentralized
storage
service
that
allows
us
to
actually
share
the
the
current
state
in
a
way
that
others
can
pick
it
up.
So
we
don't
have
any
persistent
storage,
but
what
we've
been
able
to
do
is
to
show
that
we
can
guarantee
availability
of
state
updates,
so
this
for
a
certain
period
of
time
and
that
allows
anyone
who's
participating
in
the
contract
to
guarantee
that
they
can
get
at
the
most
recent
authoritative
copy
of
the
state
that
way.
B
So
this
is
how
we
manage
storage
in
an
off
chain
system.
That
way,
the
enclave
hosting
service
is
really
where
we
perform
the
execution
of
the
operations
on
the
private
data
objects,
and
so
this
is
a
collection
of
servers
that
are
running
trust,
execution
environments
where
we
actually
move
the
private
data
objects
into.
B
There
is
an
interpreter
for
the
contract
language
right
now.
The
original
version
of
pdf
supported
scheme,
which
was
really
the
simplest
language,
had
the
smallest
tcp
that
we
could
that
we
could
implement
on
it.
But
surprisingly,
no
one
wanted
to
write.
You
know
list
like
programs
for
contracts,
and
so
we've
recently
replaced
that
with
the
webassembly
micro
runtime,
it's
a
wasm
interpreter,
and
that
means
you
can
use
anything
that
can
compile
into
wasm
as
your
development
language.
B
A
A
B
So,
since
the
data
for
the
objects
is
stored,
off-chain
there's
really
an
availability
agreement
between
everyone,
who's
participating
in
a
particular
contract
that
they're
going
to
keep
a
copy
of
the
state.
So
when
I
want
to
perform
an
operation,
I
grab
the
state,
the
current
encrypted
state
of
the
pdo,
and
I
take
that
statement
and
I
hand
it
to
a
contract
enclave
service,
and
I
say
this
is
the
operation
that
I
want
that
I
want
to
perform
on
it.
B
That
execution
completes
there's
a
new
version
of
the
state
as
the
as
the
one
who
invoked
the
operation,
I
retrieve
all
the
pieces
of
the
state.
I
commit
the
transaction
to
the
ledger,
but
as
part
of
committing
the
transaction
to
the
ledger,
I
have
to
provide
proof
to
the
ledger
that
I
made
the
state
available
in
one
of
the
public
locations
so
that
others
can
download
it.
So
anyone
who's
participating
in
that
object
can
go
to
one
of
these
storage
services.
Now
we
implement
our
own
storage
service
with
with
the
pdos.
B
B
We
we
do
use
the
attestation
service.
The
current
version
of
pdo
is
implemented
with
the
intel
attestation
service
for
sgx
there's.
No,
I
mean
we
have
tried
in
the
code
to
at
least
move
sort
of
the
tee
specific
details
into
it
into
modules,
so
that
you
could,
you
could
implement
with
a
different
tee.
B
So
it's
the
contract,
enclave
host
or
the
contract
enclave
services
themselves
are
the
ones
that
we
provide.
The
attestation
for
and
those
attestations
are
registered
in
the
blockchain
so
that
they
can
be
verified.
So
they
are
verified
on
entry
into
the
blockchain.
But
anyone
who
wants
to
see
them
is
able
to
take
a
look
at
the
attestations
for
the
contract
enclave
hosting
services.
B
B
B
B
B
There's
a
standard
process
for
adding
new
contract
enclave
services
to
it
to
the
mix
there's
a
process
for
adding
new
provisioning
services
that
goes
through
this
sort
of
registration,
but
what
constitutes
unacceptable
registration
is
actually
entirely
up
to
the
organization.
That's
running
the
ledger,
so
there
is
a
policy
object
inside
and
again,
like
I
said,
our
our
ledger.
B
So
whatever
the
community
decides
as
the
acceptable
policy
for
allowing
new
enclaves
in
that
becomes
our
our
kind
of
onboarding
story,
so
mechanistically,
it's
not
very
difficult
to
do
deciding
on
what
the
appropriate
policy
is.
Well
that
depends
on
what
you
want
to
accomplish
right
now.
Our
policy
is
very
simple,
which
is,
if
you
present
a
valid
ias.
Certified
sgx
report,
then
we'll
accept
you.
That
is,
it
has
to
be
running
valid
in
this
case
has
to
be
running.
The
appropriate
version
of
the
contract
conclude
service.
B
What
constitutes
an
acceptable
enclave
service
that
way
or
what
constitutes
an
acceptable
provisioning
service?
So
the
ledger
and
the
registry
and
transaction
log
is
our-
is
our
root
of
trust.
It
is
not
the
root
of
activity,
it's
not
the
source
of
activity
from
any
of
these,
and-
and
this
is
kind
of
what
I
mean-
that
we
separate
out
the
notion
of
execution
of
the
contract
from
authority
or
commit
of
that
contract
authority
and
commit
is
the
job
of
the
ledger.
B
That
cannot
be
committed,
for
example,
because
somebody
else
has
committed
the
current
state
or
because
the
transaction
returns,
because
the
execution
returns
an
invalid
transaction
that
way,
but
by
separating
execution
out
into
the
contract,
enclosed
services,
it
allows
us
to
have
scalability
in
the
execution
separate
from
the
problems
we
have
with
scalability
of
consensus
in
the
ledger.
So
we
can
do
big
computations
of
the
contract.
We
can
do.
Inferencing
we've
been
talking
about
how
to
incorporate
some
of
this
work
into
some
trusted.
B
Federated
learning,
architectures,
where
we
might
do
some
training
there
as
well.
So
these
are.
These
are
big
complex
contracts
for
the
potential
to
be
big,
complex
contracts,
but
the
complexity
of
the
contract,
because
the
execution
happens.
Off-Chain
does
not
affect
the
scalability
of
the
ledger
transactions
as
well.
B
B
So
the
second
part
of
this
is
then,
if
a
tee
could
be
attacked,
how
do
we
prevent
those
commits
from
from
being
a
part
of
the
the
authoritative
law
that
gets
in
the
ledger,
and
the
approach
we've
taken
on
it
is
is
basically
an
optimistic
execution,
so
any
of
these
attacks
are
really
hard.
Any
attacks
on
tvs
are
really
hard,
so
what
we
want
to
do
is
rather
than
pay
the
price
before
we
put
something
in,
we
allow
anyone
who
has
access
to
the
contract
to
verify
the
integrity
of
any
transaction.
B
That's
been,
that's
been
committed
in
the
past,
and
so
the
idea
is
we
can
commit
on.
We
can
commit
a
new
transaction
to
the
ledger,
with
a
single
trusted
execution
environment,
saying
that
it's
good,
but
we
can
revoke
that
transaction
if
enough,
others
enough
other
tees
attempt
to
perform
that
transaction
get
a
different
result
for
it.
So
it's
the
idea
that
we're
very
optimistic
which
allows
us
to
go
fast,
but
we
still
have
the
ability
to
do
the
kind
of
revocation
on
something
if
we
can
prove
that
something's
been
broken.
B
We
can
store
data
inside
the
object
and
that
data
is
never
exposed
to
any
human
being
or
any
host
in
that
environment,
and
that
makes
some
really
interesting
possible
applications
that
we
can
build
on
it.
That
way
in
general.
Our
notion
is
that
the
most
motivated
party
is
the
one
who
is
in
charge.
So
many
of
the
trusted
execution
environments
don't
explicitly
support
trusted
io.
B
That
way,
so
we
have
to
create
authoritative
channels
from
the
execution
environments
to
the
different
services
in
order
to
coordinate
the
protocols,
and
we
basically
trust
the
individual.
Who
is
most
motivated
for
it
to
work
correctly.
To
make
that
work
and,
as
I
said,
you
know,
we
kind
of
design
the
system
overall
with
this
notion
of
trustlessness
and
when
we
start
from
a
zero
trust
assumption.
B
Everything
is
really
expensive
because
you
have
to
establish
from
ground
zero
the
acceptable
use
of
of
the
policies
that
way.
But
what
we've
done
at
the
same
time
is
to
basically
say
there
are
hooks
in
here
for
metadata
that
can
be
added
to
these
services
that
allow
us
to
create
a
much
more
efficient
environment.
So,
for
example,
in
order
to
make
sure
that
we
get
the
appropriate
resiliency
for
updates
to
a
contract.
B
B
But
if
we
all
kind
of
agree
that
this
is
that
this
is
worth
our
time,
then
we
can
get
much
much
better
performance
by
sort
of
re-centralizing
the
execution
of
those
contract
objects.
So
it
allows
us
to
have
both
sort
of
a
core
of
zero
trust,
but
allow
for
relaxing
that
assumption
for
a
particular
applications.
B
All
right
and
then
the
only
other
thing
I'm
going
to
say
about
this-
is
that
one
of
the
things
we
finally
realized
is:
you
know
we
were
kind
of
being
silly
originally
by
keeping
the
contract
and
the
data
as
separate
things.
The
contract
turns
out
actually
is
just
part
of
the
data,
and
so
we
ended
up
moving
the
smart
contract
into
the
encrypted
data,
and
so
now
we
have
a
complete
package
that
we
can
execute
that
way
and
then
the
contract
enclave
is
really
just
a
loader.
For
this.
B
This
chunk
of
data,
it's
able
to
extract
out
the
contract,
extract
out
the
data
and
then
perform
the
execution
inside
the
interpreter.
That
way-
and
I
think
we've
talked
a
little
bit
about
this
already-
that
the
the
whoever
wants
to
execute
the
method
pushes
the
state
to
the
contract
enclave
service
performs
an
operation
get
something
back
from
it
and
then
pushes
that
change
set
onto
the
ledger.
B
B
So
in
some
sense
it's
our
my
answer
to
that
is
that
it
depends
a
little
bit
on
what
the
the
properties
are.
The
ledger.
We
have
tried
hard
to
make
the
pdo
as
ledger
independent
as
we
can,
but
there
are
some
places
where
the
properties
tend
to
bleed
through
and
and
the
governance
section
is
really
where
that
happens.
B
Okay,
well
then,
let's
talk
a
little
bit
about
something
kind
of
different,
and
this
is
this
is
the
kind
of
application
that
we're
trying
to
build
with
these
pdos
right,
and
so
I
said
before
that
we
can
do
inferencing
right.
So
we've
we've
looked
at
how
to
do
tf,
lite,
tensorflow
lite
inside
one
of
the
contract
objects
and
they
can
compile
under
wasm,
and
so
we're
able
to
to
take
advantage
of
that.
B
And
let's
say
that
I
build
this
model
called
a
cat
counter
right
and
so
the
idea
behind
the
cat
counter
is
you
invoke
an
operation
on
the
cat
counter
pdo
and
it
uses
its
object,
detection
algorithm
and
counts
the
number
of
cats
that
are
that
are
in
that
image
in
that
particular
image.
That
way.
So
what
we
end
up
with
is
in
in
some
sense
this
pdo
becomes
almost
kind
of
a
library
or
reusable
library
routine,
and
it
has
some
really
nice
properties
as
a
reusable
library
routine.
B
B
Is
I
get
something
that's
effectively
a
server-independent
encapsulation
of
code
that
preserves
the
confidentiality
of
the
intellectual
property
of
the
counter
model?
That's
inside
it.
So
some
really
nice
properties
of
this
thing.
It's
reusable
it's
serverless
and
yet,
at
the
same
time
it
has
some
interesting.
You
know
it's
not
just
giving
you
bytes,
it
has
behavior
with
it,
which
means
that
you
know,
for
example,
I
could
charge
you
every
time.
B
I
want
you
to
give
me
a
picture
and
I
want
that
picture
to
have
as
many
cats
as
possible
inside
okay.
This
is
a
silly
example
I
know,
but
but
it
captures
the
idea
here,
and
so
we
get
in
this
situation.
So
you
know
again,
like
I
said,
the
cat
counter
is
not
free
right.
I
want
to
make
money
off
the
work
that
I
put
into
creating
the
object
detection
model
inside
the
cat
counter.
B
B
That's
been
coming
out
of
the
cat
counter
and
you
can
give
it
to
the
auction,
and
so
we
can
get
the
image
we
get
the
attestation
that
the
cat
counter
object
says
that
there
are
25
paths
in
this
one,
and
the
auction
can
then
decide
what
it
wants
to
do
for
it,
and
the
cool
thing
is
is
that
all
of
these
services
are
fundamentally
other
than
the
trust
relationship
between
them.
They're,
fundamentally,
independent
things
right.
The
billing
service
doesn't
have
to
know
anything
whatsoever
about
how
the
the
payments
are
being
used.
B
Sometimes
it
can
be
used
for
a
cat
counter.
Sometimes
it
can
be
used
for
something
else.
The
billing
contract
is
completely
independent
of
the
counter
contract
and
the
auction
contract
does
not
care
how
paths
are
counted
in
the
image.
As
long
as
one
of
the
things
it
trusts
can
provide
an
attestation
for
the
number
of
cats
during
the
image,
so
what
we
end
up
with
with
pdo
is
in
some
sense
a
new
decentralized
programming
model,
it's
compositional
and
confidential
computing.
We
end
up
with
this
library
of
kind
of
pre-configured.
B
B
Anyone
can
execute
these
anywhere
that
these
objects
have
been
provisioned
for
execution
for,
and,
and
so
they
have.
This
kind
of
notion
of
you
know
for
back
in
the
programming
languages
view
it's
it's
a
closure
on
a
set
of
data
that
is
completely
confidential
and
completely
server
independent
subject
to
appropriate
provisioning
of
the
keys
for
those
servers.
B
Looking
steel
bid,
auctions
and
institutional
elections,
we're
looking
at
new
means
of
creating
nfts
and
monetizing,
creating
monetizable
data
units
as
well.
For
that
all
right
so
closing
up,
then,
as
I
said,
private
data
objects
is
really
a
system
for
doing
smart
contracts
for
data.
It's
a
decentralized
tee
based
smart
contract
execution
environment
that
preserves
privacy
and
confidentiality
of
the
data
prototype
code
is
available
through
hyperledger
labs.
I
will
say
it
is
labs.
B
As
far
as
ongoing
work,
as
I
said,
we
have
some
notion
of
supporting
additional
contract
interpreters,
although
we
really
kind
of
like
wasm
for
a
lot
of
the
things
that
it
gives
us
in
the
kind
of
bi-directional
sandboxing
part
of
it.
I
say
we're
supporting
more
ledgers,
but,
frankly
again
we
sort
of
we.
We
really
like
the
properties
we
get
from
ccf
as
far
as
performance
and
confidentiality
goes
on
the
transactions
that
way
all
right
and
on
that,
thank
you.
Any.
A
A
B
B
All
of
the
iceland
servers
that
are
out
now
have
sgx
support
for
it.
The
e3
xeons
for
the
last
several
years
have
supported
it
and
and
their
support
and
appliance.
If
you
want
confidential
services,
you
can
get
them
from
like,
for
example,
microsoft
azure
has
their
confidential
compute
service
ibm
is
offering
some
of
their
cloud
servers
that
are
bare
metal
sgx
as
well.
A
A
B
Yeah,
so
the
answer
is
yes
and
no.
The
older
e3s,
the
amount
of
memory
that
was
available
for
the
enclave
was
restricted,
and
so
you
had
to
be
kind
of
careful
with
it.
But
the
iceland
servers
have
increased
that
substantially
and
it's
enough
we've
been
able
to
show
again
sort
of
in
in
in-house
experimentation
that
you
can
do
some
pretty
substantial
computation
in
those
that
is
there's
enough
memory
to
do
interesting.
Things.
A
B
I
can
put
the
data
inside
the
pdo.
The
pdo
manages
all
of
the
encryption
and
the
confidentiality
around
it
using
the
trusted
execution
environment,
and
so
in
some
sense
I
have
an
explicit
set
of
policies
for
use
for
what
constitutes
appropriate
use,
and
I
can
encode
them
inside
the
pdo
and
the
pdo.
Does
the
enforcement
of
that
there
are
other
more
challenging
problems
with
sort
of
implicit
information.
That's
exported
that
way.
B
You
know
the
the
transaction
rates
on
a
particular
private
data
object,
for
example,
may
lead
you
to
some
understanding
of
the
importance
of
that
object
or
the
or
the
properties
of
that
object,
or
because
the
protocols
between
objects,
as
we
move
data
back
and
forth
between
these
objects,
because
those
protocols
may
give
you
some
information
about
the
kinds
of
objects
that
are
in
there.
There's
a
there's,
an
implicit
expectation
of
confidentiality
that
could
be
explicit.
That
could
be
exposed
as
a
result
of
those
transactions.
B
One
of
the
reasons
why
we
like
ccf
so
so.
First
off
we
do
anonymization
of
the
transactions
as
best
we
can,
and
so
you
don't
get
the
same
identity
for
the
same
transactions
when
they're
being
committed
to
the
ledger.
The
ledger
does
not
know
anything
about
who's
actually
doing
committing.
They
just
know
that
it
was
the
same
individual
that
performed
the
operation
that
way,
but
what
ccf
does
is
because
ccf
itself
is
implemented
using
a
trusted
execution
environment.
B
Is
it
the
communication
between
all
of
the
components
between
the
client
and
the
ledger
and
between
all
of
the
components
of
the
ledger
is
happening
through
encrypted
channels
as
well?
So
even
that
allows
us
to
hide
some
of
the
details
about
you.
You
can
see
activity.
We
can't
hide
the
network
that
way,
but
you
can't
even
see
differentiation
between
what
contract
objects
are
being
are
being
evoked
that
way.
So,
if
I'm
understanding
your
question
correctly,
that's
really
the
kind
of
two
things
that
we're
trying
to
prevent.
In
this
case.
B
Yes,
we
basically
are
looking
for
when
we
did
the
implementation
of
the
solitude
we
were.
We
were
really
looking
for
a
number
of
blocks
and
block
commits
on
the
ledger.
So
you
know
you
had
to
provide
evidence
of
revocation
within
say
a
10
block
period
of
the
original
commit,
which
is
a
little
I
mean
it's.
It
is
a
policy
decision
and
one
of
the
things
we
were
looking
at
was
should
every
contract
object,
have
its
own
policy
for
revocation
on
it.
B
So
yes,
there's
a
time
limit
on
the
revocation
one
of
the
things
I
will
point
out
here,
though
it
which
is
a
little
different
than
when
there
is
a
disagreement
between
tees.
We
can
infer
much
more
information
about
the
problem
because
they
should
never
disagree
with
one
another
unless
a
compromise
has
occurred,
or
unless
there
is
some
randomness
in
the
contract
that
has
not
been
removed,
and
so
we
can
infer
a
little
bit
more
information
and
and
the
policies
for
handling
invalid
and
and
how
we
do.