►
From YouTube: Basic Technical Walkthrough - Baseline Protocol
Description
Baseline architecture and code walkthrough conducted by Kartheek Solipuram at the November 8, 2021 Baseline Core Devs Session.
Join our Core Dev or other community teams here:
https://www.signupgenius.com/org/baseline#/
A
All
right,
as
as
as
soon
as
pointing
out
I'll
go
over
some
of
the
basics
of
the
baseline
protocol,
particularly
around
some
of
the
core
components
that
we've
introduced
with
help
from
the
the
main
members
of
the
community,
predominantly
from
provide
and
consensus,
and
some
of
our
work
as
we
came
along
to
open
source
or
make
this
make
this
a
baseline
project.
You
know
go
into
public
domain.
A
Essentially
I'm
not
going
to
go
over
some
of
the
motivations
which
I'm
sure
that
most
of
you
are
aware
of,
but
just
as
a
quick
round
up,
we
some
of
the
cons.
The
main
considerations
for
baseline
is
how
do
enterprises
communicate
with
each
other,
any
form
of
any
form
of
inter
business
communication
or
any
form
of
logical
interpolation
or
any
form
of
synchronization
for
that
matter,
on
data
on
process
or
any
form
of
business
logic
that
enterprises
deal
with
on
a
day-to-day
basis
with
their
other
counterparties.
A
So
with
that
being
said,
some
of
the
key
considerations
are
around
security
to
make
sure
that
the
data
that
any
of
the
enterprise
systems
use
to
interact
with
the
mainnet,
that
data
itself
doesn't
leave
the
legacy
systems
and
any
form
of
data,
interchange
or
transformations,
etc
remain
hidden.
While
doing
so
it
is
square
it
is.
A
So
in
that
sense,
we
need
to
one
of
the
main
considerations
with
data.
Consider
sorry,
consistency
is
the
compatibility
with
multiple
data
systems.
Different
organizations
may
have
different
types
of
data
systems
or
database
technologies
or
or
even
data,
governance
considerations
or
data
architecture
paradigms,
but
being
aware
of
all
of
those
aspects
or
all
of
those
variations
or
variabilities.
A
How
to
the
main
consideration
is
making
sure
that
the
data
across
the
various
types
of
models
is
consistent
across
all
the
enterprises,
and
in
doing
so,
we
want
to
use
mainnet
as
the
primary
source
of
truth
or
a
common
reference
frame
by
which
all
different
parties
can
more
or
less
subscribe
to
the
various
changes
that
are
happening
in
the
data
or
the
various
state
changes
that
might
impact
the
primary
blockchain
itself.
So
we
do
so
by
introducing
a
set
of
smart
contracts
to
verify
data
consistency
while
keep
the
data
while
keeping
the
data
hidden.
A
One
of
the
other
consideration
is
that,
with
the
changing
nature
of
the
mainnet,
with
with
various
folks
coming
up
or
with
the
folks
that
have
come
up
in
the
last
two
years,
even
with
byzantine
and
london,
hard
folk
and
also
with
the
new
types
of
pre-compiles,
getting
added
to
enable
different
form
of
signature
mechanisms
or
even
zero
knowledge,
proof,
based
proofing
or
verification
mechanisms,
are
continuously
changing
or
continuously
being
upgraded
with
introduction
of
new
eips
and
so
on.
So
it's
pri.
A
It's
it's
important
that
as
we
are,
as
we
are
lining
up
things
to
use
mainnet
as
a
common
reference
frame
of
data.
It
also
needs
to
be
extensible
to
various
changing
privacy
techniques
and
finally,
scalability
is
also
of
main
importance,
as
we
know
that
there
have
been
numerous
issues,
or
rather
numerous
quote,
unquote-
concerns
with
the
rising
gas
fees
on
of
conducting
any
business
or
any
transactions
on
the
main
net.
A
It
is
important
that
for
scale
not
only
is
not
only
is
it
important
to
be
able
to
commit
any
of
the
private
elements
or
private
data
or
private
logic
to
the
mainnet,
but
it's
also
important
that
it
needs
to
be
extended
to
many
other
private
states
and
the
ability
to
compose
multiple
groups.
Given
the
given
the
nature
of
the
zero
knowledge
proof
that
is
embedded
with
any
verification
of
a
business
logic
or
a
business
data
or
data
synchronization.
For
that
matter,
it's
important
to
compose
these
proofs
and
conduct
efficient
verification.
A
A
It
starts
off
with
api,
which
is
around
creating
this
successful
interface,
enabling
solution
providers
or
like
solution,
adopters
of
the
baseline
protocol
or
any
organizations
of
the
baseline
protocol
as
they're
adopting
the
standard.
It's
important
that
api
acts
as
a
mechanism
for
enabling
either
rest
base
and
points
or
any
form
of
micro
service
enabled
endpoints
for
businesses
or
parties
to
conduct
business
with
each
other
so
quickly
switch
to
the
repo
itself.
A
So
we
have
in
the
baseline
stack
the
all
the
all
the
various
services
or
the
components
are
structured
under
the
baseline
core
and
particularly
under
api.
We
have
a
typescript
form
of
an
interface
definition
where
you
could
see
that
we
have
various
and
various
interfaces
to
essentially
maintain
or
connect
to
an
rpc,
maintain
an
rpc
connection
to
the
mainnet,
and
there
are
a
bunch
of
other
a
bunch
of
other
interfaces
as
well.
So,
for
example,
here
one
of
the
main
interface
is
the
baseline
rpc.
A
We
have
a
few
methods
to
be
able
to
get
to
be
able
to
get
the
commit
of
any
of
any
object
or
data
that
is
getting
attested
or
verified
and
then
put
into
a
merkle
tree
I'll
I'll
talk
about
the
overall
business
process
as
to
where
mr
tree
comes
in.
But
the
idea
is
that
this
rpc
interface
or
this
baseline
rpc
interface
essentially
contains
a
list
of
methods
to
track
and
follow
the
state
changes
that
are
happening
on
a
merkle
tree.
A
The
state
changes
itself
directly,
but
we
use
a
localization
concept
or
an
accumulator
concept
where
we
push
the
hashes
of
any
of
the
data
elements
that
we
would
like
to
communicate
from
between
one
organization
to
another
directly
into
a
merkle
tree,
where
each
each
root
or
each
sorry.
Each
leaf
of
the
merkle
tree
corresponds
to
a
hash
of
the
data
that
is
communicated
between
the
parties
and
the
hash
itself
is
embedded
with
other
properties
around
zero
knowledge
groups
as
well,
which
I'll
go
into
in
a
few
moments.
A
So
essentially,
this
entire
set
of
baseline
rpc
methods
provides
an
ability
to
store
things
in
historic
hashes
in
the
merkle
tree,
both
on
chain,
but
also
maintain
a
parallel
collection
in
your
local
mongodb
of,
or
rather
when,
I
say,
local
mongodb,
a
part
of
the
persistence
in
the
baseline
protocol,
which
I'll
go
to,
which
is
one
of
the
next
elements.
So
the
idea
is
that
each
hash
that
is
getting
stored
on
the
blockchain
also
needs
to
have
a
representative
structure
or
storage
on
your
local
databases
as
well.
A
When
it
comes
to
participants,
we
also
have
some
of
the
standard
ones
for
connecting
to
a
blockchain
service
here,
like
broadcasting,
a
transaction
fetching
transaction
receipts
or
even
signing
any
payload.
Before
before
sending
any
message,
then
we
have
the
registry
interface.
This
is
where
this
is
the
interaction
with
the
organization
registry,
smart
contract.
A
So
the
idea
is
that,
when
we
are
interacting
with
various
parties
on
the
mainnet,
it
is
important
that
we
need
to
be
able
to
have
some
form
of
an
identification
and
also
an
enablement
or
a
provision
for
say,
for
example,
different
kyc
providers
or
email
email
providers
to
be
able
to
detect
or
identify
who
the
counterparty
is
to
identify
who
the
various
organizations
are.
So
to
that
extent,
we
have
various
methods
which
are
essentially
behind
the
behind
the
scenes.
A
You
could
think
of
each
of
the
implementations
of
these
methods
to
interact
with
the
smart
contract
using
rpc
methods.
So
to
that
extent
we
have
create
work,
group
or
sorry
work
group
functionalities
to
create
work
groups
to
fetch
the
various
work
groups,
the
details,
the
organizations
and
the
re
under
the
work
groups
and
so
on.
A
The
traditional
keys
that
most
of
us
know
are
of
say
any
form
of
secrets
that
are
used
to
sign
any
transactions
in
general
on
ethereum,
which
is
your
standard,
ethereum
public
key
private
key
pair.
So
the
vault
acts
as
a
enabler
for
storing
such
private
keys.
But
as
we
go
forward,
we'll
notice
that
there
is
some
elements
of
privacy
as
well,
especially
when
it
comes
to
zkp.
A
We
use
a
special
form
of
signatures
to
ensure
that
parties
signing
a
certain
message.
Their
identity
is
hidden
under
serial
knowledge
proofs
and
to
be
able
to
do
so,
you
need
you
need
some
special
special
curves,
like
a
form
of
edd
sa
curves
and
also
bls
type
signatures
to
be
used
as
part
of
signing
a
given
message.
So,
apart
from
traditional
private
keys
that
we
that
we
nominally
use
for
signing
any
transactions
to
interact
with
the
mainnet,
the
wallet
is
also
designed,
or
rather
facilitated,
to
store
other
types
of
private,
private.
A
Sorry,
private
keys
as
well
like
the
private
keys
that
are
needed
for
bls
signatures
or
the
private
keys
or
or
even
the
curves,
that
itself
that
are
used
to
create
construct.
The
bls
signatures,
and
so
on,
so
these
so
in
that
sense,
api
acts
as
a
way
to
a
way
to
interact
with
the
blockchain
way
to
interact
with
security,
storage
and
finally
interact
with
the
smart
contracts
that
are
deployed
on
the
main
net.
A
The
next
one
we'll
go
into
is
the
contracts
so
as
part
of
contracts,
some
of
the
primary
contracts
that
we
have
are
around
setting
up
work
groups.
Obviously
these
set
of
smart
contracts
are
just
the
base
ones
and
any
extensions
are
welcome
and
any
extensions
are
possible
here,
but
we,
when
we
came
up
with
this
architecture
originally
the
idea
was
that
we
want
an
ability
for
different
organizations
to
be
able
to
identify
each
other
who
they
are
working
with,
and
also
the
ability
to
ensure
that
these
are
organizations
are
valid
and
identifiable
organizations.
A
So
to
that
extent
again,
this
work
group
that
a
transportation
agency
may
have
may
be
very
local,
so
to
speak
in
terms
of
business
integratives
for
the
transportation
agency
and
in
a
similar
manner.
This,
a
buyer
may
or
a
different
part,
or
a
different
participant
on
the
ecosystem
may
or
in
this
work
in
this
group,
may
have
their
own
downstream
providers
that
they
deal
with
their
own
tier
2
suppliers
or
tier
2
manufacturers
and
so
on.
A
So
regardless
of
all
this,
what
we
are,
what
we
came
up
with
was
that
if
there
was
an
ability
for
different
organizations
to
identify
themselves
and
form
working
groups
so
that
they
can
uniquely
identify
which
working
group
they
are
part
of
and
and
at
the
same
point
at
the
sorry.
To
the
same
token,
we
have
organizations
being
added
to
the
working
group
or
removed
from
the
working
group
or
moved
from
one
working
group
to
another.
A
So
the
idea
is
that
we
would
want
a
standard
or
we
would
want
a
good
eip
that
we
could
use
for
representing
organizations
and
their
work
groups,
and
not
just
that.
We
also
want
to
make
sure
that
the
work
group
or
the
set
of
contracts
or
set
off
say
shield,
sorry
set
of
say
the
merkle
tree
contracts
or
the
shielding
contracts
that
are
needed
for
zero
knowledge
proofing.
A
They
are
also
custom
to
each
working
group,
so
a
working
group
for
say,
for
example,
a
working
group
that
consists
of
say,
hypothetically
just
a
supplier
and
buyer
may
be,
could
be
rather
attuned
to
just
verifying
say
proofs
of
any
documents
that
are
being
shared
around
say.
The
agreements
that
are
agreed
upon,
like
in
terms
of
the
goods
that
need
to
be
procured
or
or
say,
the
purchase,
orders
or
invoices
etc.
A
So
to
be
able
to
verify
the
shipping
contract
details
or
to
ensure
the
data,
integrity
of
the
shipping
contract
between,
say,
a
transportation
agency
and
a
local
warehousing
agency,
or
a
logistics
company,
the
very
it
may
have
they
may
have
their
own
verifications
of
verifying
the
shipping
notice
or
verifying
a
shipping
contract
or
verifying
the
logistics
contract
and
so
on.
So
to
that
extent,
it's
key
that
organization
registry
as
such
not
only
has
a
facility
to
create
different
working
groups,
but
you're
also
able
to
register
different
types
of
interfaces.
A
So
a
shield
interface
is
an
example
in
this
case,
where
a
shield
contract
or
verify
shield
and
verifier
as
a
combination
are,
can
have
different
interfaces
or
different
definitions
based
on
how
they
are
interacting
with
how
they're,
interacting
with
the
merkle
tree
itself.
So
to
that
extent,
organization
registry
also
has
functionality
to
register
the
various
interfaces
so
just
quickly
switch
to
the
baseline
contracts.
A
So
this
whisper
key
is
more
of
a
more
of
an
indicator
of
the
messaging
endpoint
or
sorry,
the
the
key
that
is
needed
to
identify
your
counterparty.
When
it
comes
to
sending
private
messages,
then
you
also
have
a
zkp
public
key
to
to
indicate
an
organization's
signature
main
signature
key.
So
in
the
case
of
baseline
and
then
particularly
in
the
case
of
sending
sending
secure
messages
across.
One
of
the
key
aspect
is
the
type
of
signature
mechanism
that
is
being
used.
Is
that
particular
signature
mechanisms?
A
Public
key,
is
what
we
would
want
to
capture
over
here
as
part
of
the
registry
of
the
organization,
so
this
functionality
walks
through
or
provides
an
ability
to
register
organizations
not
much
different,
very
similar
to
any
of
the
other
naming
registry
or
naming
or
organization
registry
or
name
registry
contracts.
That
folks
must
have
seen,
but
we
also
have
another
method
where
we
are
essentially
registering
interfaces,
so
different,
different
types
of
interfaces
or
different
types
of
implementations
of
a
given
interface
can
be
used
by
the
working
group
organizations.
A
A
So
the
idea
is
that
when
we
are
using
erc
1820,
it
acts
as
a
factory
of
factories
or
an
interface
of
interfaces,
so
it
john's
one
of
john's
famous
words.
It's
like
it's.
It's
like
a
corporate
phone
book
of
sorts.
Where
you
can
have.
You
can
use
erc
1820
as
a
registry
of
registries,
so
that
you
can
have
various
types
of
organization,
registries
into
their
work
groups
or
shield
or
shields
or
verifiers,
etc.
But
all
of
them
can
be
dependent
or
all
of
them
can
be
registered
with
one
parent
erc
1820.
A
These
encrypted
messages
are
essentially
needed
to
be
able
to
communicate
any
seek
any
private
information,
or
rather
particularly
the
information
that
is
needed
to
verify
a
zero
knowledge
proof,
which
is
what
we'll
go
into
next,
but
at
the
core
level
the
messaging
is
is
like
a
interface
or
an
enabler
for.
Oh
sorry,
it's
a
it's
a
library
or
containing
a
set
of
interfaces
to
typescript-based
interfaces
to
interact
or
with
any
form
of
messaging
providers.
A
A
So
this
ma
so
in.
In
short,
this
this
particular
package
deals
with
enabling
interfaces
or
creating
standard
methods
or
standard
functionalities
to
be
able
to
connect
to
nats
and
similarly
to
be
able
to
connect
to
whisper
as
well.
Although
we
don't
use
whisper
much
these
days
in
law
of
mats
for
that
matter,
this
idea
is
that
this
could
be
extended
to
other
types
of
messaging
providers
as
well.
A
In
the
past,
we
did
come
across
several
questions
around
the
ability
to
add
somewhat
more
beefy
messaging
providers
like
kafka
or
rabbit
mq,
but
but
to
that
extent
we
used
a
more
lightweight
protocol
like
nats,
but
that
being
said,
it
is
obviously
open
for
developers
to
extend
this
messaging
interface
to
not
just
include
nats
and
nats
and
whisper.
But
you
can
go
ahead
and
create
other
forms
of
interfaces
as
well.
A
So
the
main
idea
is
that
each
of
these
packages
acts
as
a
standalone
npm
library
which
could
be
used
to
set
up
a
container
or
rather
used
to
be
set
up.
Your
look
any
organizations
or
your
custom
legacy
systems,
microservices
or
say
cloud
services,
or
even
say
on-prem
services.
For
that
matter,
persistence
is
intended
to
indicate
any
form
of
data
storage.
A
So
finally,
we
have
privacy
which
is
pretty
much
the
main
piece
of
oil
main
engine
behind
hiding,
critical
or
business,
critical
information
or
business
critical
logic
and
which
is
where
we
use
zero
knowledge
groups.
So
to
start
off
I'll,
just
show
you
quickly
the
interface
and
then
I'll
go
into
some
more
detail
of
how
we
use
zero
knowledge
groups
for
for
securing
messages
or
hiding
hiding
private
information.
A
So
in
api
we
had
seen
like
one
type
of
provision
or
like
one
type
of
provider,
the
or
the
interface
that
we
had
seen
in
api,
had
like
various
methods
for
rpc
connections
or
for
interacting
with
the
smart
contracts
and
so
on.
But
when
it
comes
to
the
implementation,
there
can
be
many
other
many
ways
in
which
that
could
be
implemented
or
virtualized.
A
A
So
that
being
said,
so
privacy,
in
that
extent
has
has
enablers
or
abilities
to
be
able
to
interact
with
some
existing
zika
snark
providers
when
we
are
talking
about
zika
smart
providers.
In
this
case
we
are
referring
to
the
various
libraries
we
started
off
with
using
socrates
and
and
in
the
weeks
and
months
or
the
year
that
followed.
We
have.
A
A
So
so
the
this
aspect-
or
this
is
done
using
what
you
call
as
circuits,
which
are
essentially
r1cs,
or
they
are
constrained
based
system-based
circuits
so
similar
to
boolean
circuits
or
like
bobolian
gates.
You
have
arithmetic
circuits
and
that's
where
that's
what
these
circuits
are
referred
to,
and
we
don't
need
to
write
these
arithmetic
static
circuits
directly
in
that
language.
But
you
have
other
dsls
like
in
the
case
of
socrates.
There
is
their
own
custom
dsl,
by
which
you
can
write
your
own
circuits.
A
Similarly,
we
have
a
proof
of
knowledge
of
signature,
which
is
where
we
ensure
that
whether
or
not
the
buyer
and
supplier,
or,
for
example,
alice
and
bob
their
signatures
are,
are
verified
and
in
doing
so
the
verification
is
within.
Behind
the
scenes
is
using
a
library
circuit
that
which
essentially
proves
whether
or
not
points
are
on
an
edd
sa
curve.
So
you
because
edd
say-based
signature
mechanism
is
used.
A
And,
finally,
we
have
the
proof
of
membership
of
a
hash
in
a
merkle
tree,
where
what
we
make
sure
is
that
when
we
are
inserting
any
leaf
into
a
merkle
tree,
say,
for
example,
a
hash
is
determined
and
that
hash
needs
to
be
set
into
the
merkle
tree.
The
important
point
over
here
is
to
make
sure
that
this,
the
the
root
that
gets
changed
upon
every
time
a
hash
is
inserted
into
a
merkle
tree.
A
So
this
in
the
case
of
privacy
management,
when
alice
intends
to
integrate
sorry
interact
with
bob,
they
would
take
a
circuit
such
as
the
one
we
just
saw,
compile
it
set
it
up
and
publish
those
artifacts
and
using
those
artifacts.
You
can
deploy
the
verifier
smart
contract.
So
then
the
smart
contracts,
the
verified
smart
contract,
contains
a
functionality
to
verify.
A
Any
proof
that
is
being
submitted
can
be
verified
under
zero
knowledge
and
whenever
it
means
under
zero
knowledge
is
that
verifier
uses
a
library
appearing
curve,
library
called
bn256,
and
that
is
what
is
used
to
verify.
Whether
or
not
a
proof
is
is
a
legitimate
or
rather
a
proof
is
poi
is
a
point
on
that
on
the
patellar
electric
curve.
A
A
It
starts
off
with
party
a
generating
a
commitment
which
is
essentially
generating
a
hash
signing
that
particular
hash,
and
this
signing
is
done
using
a
special
signature
mechanism
like
like
the
eddsa
and
and
one
form
of
edd
essay
we
have
been
using
in
this,
or
at
least
that
was
that
has
been
originally
published
to
the
baseline
stack,
was
the
baby
curve.
But
to
that
extent
any
other
form
of
signatures
also
can
be
used.
A
A
proof
which
essentially
contains
is
a
all
those
three
methods
that
we
spoke
about
to
ensure
that
the
hash
is
correct
and
to
ensure
that
the
both
parties
have
signed
off
that
document
and
verifying
that
particular
signature
under
this
proof
and
finally,
inserting
that
particular
hash
as
a
as
a
as
a
leaf
in
a
bunker
tree
both
that
are
stored
locally.
So
the
proof
itself
contains
the
membership
of
a
particular
leaf
in
a
merkle
tree,
and
then
that
particular
proof
is
verified
by
calling
the
shield
contract
and
this
may
be
optional.
A
If
a
party
may
not
does
not
need
to
verify
the
proof,
they
can
still
verify
the
proof
locally
without
making
an
interaction
with
the
shield
contract.
But
this
is
just
for
posturity.
It
is
shown
that
both
anyone
can
verify
this
proof
and
after
verification
of
such
a
proof
is
when
the
proof
is
being
sent
and
it
and
once
the
proof
is
sent
and
as
a
part
of
party
b
as
well,
either
party
a
or
party
b
can
call
the
shield
contract
to
ensure
that
the
proof
is
valid.