►
From YouTube: Blockchains are No Longer Monolithic Programs, but Composable Applicati... James Barry & Bill Katsak
Description
Blockchains are No Longer Monolithic Programs, but Composable Applications that Meet a Specific Need - James Barry & Bill Katsak, Taekion
Over the past year the meaning of a “Blockchain” has changed as many blockchains have become focused on solving a business problem and the original crypto currencies do not have the platform that meets an enterprise need. Hyperledger offers the best selection of parts that can then be selected to build an enterprise application. Why a “Blockchain” application does have to all be from a single entity like Ethereum or Bitcoin. James and Bill will show how Taekion is using multiple components including Hyperledger Sawtooth, Ursa, Transact, and new components they will be proposing to the Hyperledger community to build a new composable distributed application that showcases why a compassable app is the future in 2020 and beyond. This presentation will showcase why Hyperledger is the perfect community to find, build & use these components to build the new vision of a distributed blockchain.
----
Hyperledger – Open Source Blockchain Technologies
Hyperledger is an open source community focused on developing a suite of stable frameworks, tools and libraries for enterprise-grade blockchain deployments.
It serves as a neutral home for various distributed ledger frameworks including Hyperledger Besu, Fabric, Sawtooth, Indy, as well as tools like Hyperledger Avalon, Cactus and libraries like Hyperledger Aries, Ursa. Learn more about Hyperledger projects: https://www.hyperledger.org/use
Case Studies: https://www.hyperledger.org/learn/case-studies
Training & Certification: https://www.hyperledger.org/learn/training
Tutorials: https://www.hyperledger.org/use/tutorials
Webinars: https://www.hyperledger.org/learn/webinars
Events: https://www.hyperledger.org/events
Vendor Directory: https://www.hyperledger.org/use/vendor-directory
Subscribe to the Hyperledger Newsletter: https://www.hyperledger.org/newsletter
Follow-us on Twitter @Hyperledger
Learn about Hyperledger Membership: https://www.hyperledger.org/about/join
#Hyperledger #HyperledgerGlobalForum2020 #Blockchain
A
While
everybody's
coming
in
I
always
start
with
Dilbert's,
just
because
for
some
reason
he
seems
to
describe
my
programming
better
than
no
meetings
I'm
in
and
for
this
I
thought
that
the
far
left
bottom
corner
was
right
when
he
said
what
are
the
terms
of
blockchain,
only
the
goofy
ones,
oak
and
smart
contract
certainty
as
a
service
you
DxO,
etc.
Well.
A
What
we're
here
to
talk
about
today
is
how
black
hands
are
no
longer
monolithic
programs
and
they're
changing
very
rapidly
and
they're,
going
to
become
more
of
a
composite
application
over
time,
so
I'm
James,
berry,
I'm,
the
CTO
and
co-founder
of
tachyon
and
and
bill
Cossack
who's,
our
chief
architect,
just
a
bit
about
tachyon
we're
a
four
person
company
surviving
on
u.s.
government
grants.
We've
got
a
grant
from
the
Department
of
Energy
Air
Force
and
one
that's
probably
more
relevant
to
this
particular
session.
A
We
have
one
from
the
National
Science
Foundation
to
create
a
fault,
tolerant
consensus
mechanism.
So
as
we're
going
through
this
we're
gonna
talk,
I'm,
gonna
kind
of
give
the
set
up
about
where
I
see
black
chains
and
the
fact
that
they're
not
really
composable
apps.
Today,
Bill's
gonna
get
into
what
we've
been
doing
with
them
and
where
we
see
hyper
ledger
as
having
some
places
that
can
improve
and
ways
that
you
can
use
hyper
ledger
to
build
a
more
composable
to
app
yourself
and
I'll.
A
Leave
it
with
talking
about
some
possible
new
areas
that
projects
in
within
hyper
ledger
to
really
build
up
a
blockchain.
That's
not
necessarily
a
monolithic
block
team.
So
yes,
oh
there
goes.
A
lot
of
discussion
has
come
out
in
the
last
year,
whether
black
chain,
as
a
application,
that's
meaningless,
or
is
it
a
design
pattern?
We've
taken
the
approach
that
it's
more
of
a
design
pattern.
It
has
a
monolithic
application.
A
A
Should
they
be
a
monolithic
one
or
new
way
of
programming?
You
know
what
does
hyper
ledger
functionality
stack,
look
like
today.
How
are
we
tachyon
using
different
components
to
build
out
our
app?
What
share
components
are
missing
from
hyper
ledger
and
lastly,
you
know
why
not
use
new
apps
from
the
existing
and
why
hyper
ledger
can
be
the
Apache
or
get
the
bike
chain
community.
A
A
You
know
if
you're
on
a
public
network
and
you're
seeking
worldwide
audience,
you
really
need
an
irrevocable
transaction
cryptocurrency.
But
if
you're
a
public
network
serving
a
small
group
like
real
estate
Idol,
you
still
need
that
irrevocable
consensus,
but
it's
low
volume
from
a
DPS
standpoint.
Yes
being
transactions
per
second,
if
you
look
at
private
networks
between
companies
like
supply
chain,
it's
usually
a
low
TPS
for
engine
need
for
consensus.
Private
between
subsidiaries
is
accounting,
settlements
and
stuff
is
low.
A
Tps
still
a
stringent
need
network
within
a
company,
low,
TPS,
less
stringent
and
least
of
all
is
private
networks
for
mass
product.
There's
a
bunch
of
gaming
companies
that
are
throwing
the
results
in
for
24
hours
into
a
blockchain,
and
then
they
that
way.
You
hear
that
you're,
not
cheating.
Those
are
some
different
ways.
You
can
look
at
workload
from
a
workload
perspective.
A
You
know
standard
monolithic,
software
is
user,
interface,
business
logic,
data
interface
liking
or
a
database
at
the
end
of
it.
When
you
get
to
what
we
have
been
doing,
is
you
take
that
standard
components
and
you
break
it
out
to
micro
services?
So
you
have
micro-services
style,
components
and
I'll.
Take
you
into
or
bill
will
take
you
into
how
we're
using
the
hyper.
A
Let
your
pieces
and
I'll
take
you
into
some
areas
that
either
us
or
other
people
are
working
on
to
expand
that
within
hyper
ledger
and
one
thing
I
want
you
to
think
about
is
I've
been
around
for
a
while.
I
was
early
on
in
HTTP
XMPP
I
took
through
the
IETF,
which
is
messaging
and
I.
Think
that
we're
kind
of
in
that
third
major
step
of
my
lifetime,
Amazon
Facebook
Google
Twitter-
they
all
built
themselves
off
Apache.
What
wasn't
there
they
put
into
Apache?
A
If
you
really
look
at
their
stack
and
you
read
their
blogs
from
10
15
years
ago,
they
used
the
Apache
stack
to
launch
very
quickly.
They
were
more
blessed
a
technology
company,
anything
we're
trying
to
assemble
the
pieces
and
make
something
happen
and
that's
where
I
see
needing
to
happen
within
the
blockchain
community.
But
today,
you're
limited,
you
have
a
theorem,
you
have
fabric,
you
have
a
big
monoliths.
The
application
has
everything
you
need
in
it,
but
doesn't
allow
you
to
expand
out.
A
So
when
these
companies
came
out,
they
started
putting
out
things
like
Kafka
and
other
different
applications
and
Apache.
You
know
kind
of
show
you
the
evolution
over
time
when
I
first
started
out,
Netscape
AOL,
prodigy,
MSN,
CompuServe
a
world
names,
you
don't
hear
of
anymore.
There
wasn't
an
internet,
they
were
private
internets
you
got
on
there.
You
couldn't
send
your
mail
from
CompuServe
to
AOL.
You
couldn't
send
your
mail
across
all
that
interconnection
has
got
to
change.
If
you
think
today,
it's
hard
to
send
your
information
from
aetherium
to
a
Bitcoin
or
u.s.
B
A
A
You
have
an
D
as
kind
of
an
immutable
identity,
and
you
started
a
C
on
the
left
as
you
go
down,
transact
it's
starting
to
be
a
smart
contract
interface,
the
ability
to
move
smart
contracts
out
of
the
blockchain
into
its
own
separate
interface
and
I'm
already
starting
to
see
other
applications
start
to
look
at
transact
and
trying
to
adapt
it
so
that
they
can
use
transact
as
their
smart
contract
interface
same
thing
when
public
all
pluggable
encryption.
You
know
right
now:
versa
has
the
security
keys
of
primitives,
etc.
A
B
Right
so
I
just
want
to
talk
a
little
bit
about
how
we've
leveraged
sawtooth
and
some
of
the
other
components
of
the
of
the
hyper
ledger
stack
to
work
on
our
internal
business
cases.
Unfortunately,
we
can't
talk
about
what
we've
actually
built
with
the
platform.
These
were
still
at
that
point
in
our
evolution.
We
can't
give
away
the
farm,
but
essentially,
we've
started
out
using
sawtooth
and
sawtooth
forms
the
base
of
what
we're
calling
our
tachyon
core
platform.
We
have
several
core
apps.
B
And
then
we
have
another
transaction
family
that
has
the
the
sort
of
things
IDs
and
things
like
that.
That
might
actually
need
to
be
shared
between
them
and
some
nice
features
of
sawtooth
like
transaction
batches,
which
are
atomic,
allow
us
to
manipulate
state
even
when
they
go
across
transaction
families
and
still
think
of
them
as
atomic
transactions
that
get
committed
at
exactly
the
same
time
or
don't
commit
get
committed
at
all.
B
Sattva
gives
us
really
nice
signing
and
permission
facility,
it's
very
powerful.
It's
simple,
but
it
works
very
well
and
gives
us
sort
of
a
per
entity
access
control
as
far
as
what
they
can
update
a
mutate
on
the
chain.
And,
last
but
not
least,
the
pluggable
consensus
is
is
extremely
powerful.
So
we
actually
have
a
some
funding.
We
just
received
from
the
National
Science
Foundation
to
look
at
a
bunch
of
different
consensus
schemes
for
different
type
of
situations,
some
of
them
being
war,
fighting
some
of
them
being
more
civilian,
but
we
actually
have.
B
In
addition
to
the
sawtooth
base,
we've
actually
adopted
transact
now
transact
is
in
rust
with,
but
it
does
have
some
C
api's
and
we've
been
working
on,
go
ports
where
we
need
it.
We've
started
to
use
all
of
the
transact
code
for
submission
and
in
transaction
management,
where
possible
across
our
core
apps,
where
it
hasn't
been
possible.
We've
gone
back
to
the
to
the
base
from
sawtooth,
but
we've
done
it
wherever
it's
possible,
and
by
doing
this
we
ensure
clean,
standardised
code.
B
That
sort
of
is
going
to
work
now
and
it's
gonna
work
into
the
future,
as
our
system
continues
to
evolve.
One
additional
thing
we've
done
here
that
might
be
of
interest
to
the
community
is
we've
been
experimenting:
how
to
add
a
well
defined
SDK
to
build
application,
clients
for
and
put
it
into
transact.
So,
for
example,
you
have
a
transaction
family
that
represents
an
application
that
you've
built
on
the
blockchain.
B
You
have
all
sorts
of
internal
data
state
things
like
that
that
need
to
be
manipulated
and
by
default,
if
you,
if
you
roll
out
a
something
like
this
in
sawtooth,
your
client
code
has
to
be
written
sort
of
ad
hoc.
You
need
to
build
sort
of
stubs
in
your
programming
language
and
sign
your
transactions
and
submit
them
and
follow
up
on
them
to
make
sure
they're
committed,
and
you
have
to
do
all
the
stuff.
It's
actually
a
huge
amount
of
boilerplate
code.
That
needs
to
be
done
for
that.
B
So
one
of
the
things
we've
actually
done
and
we've
already
put
it
out.
There
is
open
source
to
the
community.
If
anybody's
interested
in
golang
is
we've
actually
developed
a
an
application,
client
sdk
that
follows
sort
of
what
we
call
an
api
builder
paradigm,
you
sort
of
define
methods
in
it.
You
define
functionality
to
find
state
that
goes
in
and
out,
and
you
just
get
a
library
that
you
can
instantiate
and
go
give
it
the
address
of
a
sawtooth
system
and
then
just
start
using
it
like
any
other
software
library.
B
B
B
You
get
a
well-defined
interface
and
it
behaves
as
you
would
expect
it
to
the
reason
we
adopted
our
since
that
I've,
just
instead
of
using
goal
line,
crypto
code
or
open
SSL,
is
that
some
of
our
clients
have
very
specific
cryptography
requirements,
in
particular
the
DoD
they
require
that
you
put
their
stuff
in,
and
that's
it
it's
not
up
for
negotiation.
It's
not
up
for
discussion.
You
have
to
put
their
stuff
in,
but
most
other
clients
don't
really
need
that
level
of
stuff
or
they
don't
have
that
sort
of
a
specificity
in
their
requirements.
B
So
we
needed
to
be
very
careful,
as
we
were
designing
our
system
to
two
completely
abstract
anything
that
was
crypto
into
sort
of
very
discreet
packages
that
could
be
brought
in
and
brought
out
as
needed,
and
we
found
that
Ursa
was
a
really
great
layer
in
which
to
do
this
abstraction.
We
write
for
Ursa.
If
we
need
to
expand
something,
add
something
we
can
add
it
in
using
the
actual
Ursa
API,
and
we
don't
have
to
worry
too
much
about
how
how
its
interface
to
so.
B
That
being
said,
that
we're
talking
I've
talked
about
what
we
really
like
in
hyper
Ledger,
what
we've
been
able
to
leverage
and
get
benefit
out
of
so
the
second
part
here
is
what
we
think
needs
to
be
done
in
hyper
ledger
and
what
we
actually
are
trying
to
contribute
to
in
in
the
future,
and
hopefully,
the
relatively
near
future.
The
first
thing,
especially
tying
into
our
NSF
grant,
is
a
really
really
pluggable
consensus,
so
a
bunch
of
different
components
claim
that
they
have
pluggable
consensus
right
now.
B
B
The
main
reason
for
this
is
that
implementing
a
correct,
robust
version
of
one
of
these
algorithms
is
hard.
It's
not
a
trivial
exercise,
it
never
has
and
I
don't
think
it
ever
will
be.
You
don't
want
to
do
this
more
than
once.
What
you
really
want
to
do
is
implement
pbft
debug
it
test.
It
stress,
test
it
and
put
it
into
production
and
be
able
to
trust
that
you
can
use
it
in
whichever
platform
you're
going
to
use,
whichever
sort
of
blockchain
system
you're
going
to
end
up
using
and
that's
what
we'd
like
to
do.
B
It's
a
it's
a
nice
extension
of
the
very
basic
socket
API,
but
it's
still
too
low-level
we're
working
on
a
system
that
gives
a
sort
of
a
modularized
version
of
the
standard,
common
communication
schemes,
peering
and
discovery,
gossiping,
reliable
connection
management
and
sort
of
a
few
other
things
that
we've
that
we've
needed
and
we're
planning
to
push
it
out
as
a
as
a
an
independent
library
in
particular,
we've
been
working
on
a
bug
in
soft.
It's
connection
management
that
sort
of
catalyzed
this.
B
The
next
thing
is
abstracted
block.
Storage.
All
current
block
chains
assume
a
replica
of
every
block
on
every
node,
and
this
is
sort
of
an
assumption.
That's
been
with
us
for
a
while.
It's
been
with
us
pretty
much
since
the
beginning,
but
what
we're
finding
and
talking
to
people
in
in
the
business
world
is
that
not
all
use
cases
need
this.
B
If
you
have
a
ten
node
system
across
three
different
locations
for
consensus
and
sort
of
validation
reasons,
you
don't
need
ten
copies
of
every
piece
of
data
and
a
lot
of
people
don't
want
to
do
this
because
they
don't
want
to
pay
for
the
storage
I.
Don't
know
if
anybody
else
is
hearing
this,
but
we've
heard
this
a
lot.
We
believe
the
block
storage
even
inside
a
blockchain
system
should
be
an
abstraction.
It
should
be
decoupled
from
the
validation.
It
should
be
decoupled
from
the
consensus
and
it
should
allow
for
custom
storage
and
replication
strategies.
B
So,
for
example,
if
I
have
a
30
node
chain,
I
may
set
every
block
to
a
replication
factor
of
3
a
la
Cassandra
or
something
like
that,
and
we,
the
system,
will
guarantee
that
we
have
three
copies,
but
we
don't
need
to
do
a
full
replication
across
all
of
those
nodes
and
it
once
this
is
in
place,
and
once
this
is
nicely
abstracted
out,
you
could
start
doing
fancy
stuff.
You
could
use
existing
object
stores.
You
could
do
fancy
schemes
like
erase
your
coding
and
things
like
that.
B
I
think
this
could
be
a
really
interesting
place
to
go
with
this
another
one
is
key.
Storage.
Key
storage
is
a
relatively
solved
problem.
People
know
how
to
write
key
stores,
but
so
far,
there's
no
official
hyper
ledger
standard.
We
had
to
do
something
with
this
very
early
for
the
DoD
clients
to
satisfy
them
that
we
were
storing
the
keys
properly
and
I
could
see
this
being
either
stand
alone
or
with
Ursa.
B
B
So
this
point
may
be
obviated
already,
and
it
may
already
be
a
done
thing,
but
that's
actually,
okay,
because
it
just
it
just
means
that
we
really
did
have
a
problem
that
we
identified
and
people
are
fixing,
and
the
last
thing
that
I
would
like
to
see
standardized
is
a
sort
of
a
fixed
or
standardized
API
for
data.
Exporting
sawtooth
has
a
system
called
State
Delta
exports,
where
you
can
subscribe
to
the
the
blockchain
and
get
a
for
the
get
subscribe
to
a
validator
and
get
a
notification
every
time.
B
But
this
is
a
sawtooth
specific
thing
if
they
just
sort
of
implemented
a
protocol
in
over
zmq
using
protobufs
and
it's
their
internal
thing,
it
works
very
well,
but
it
needs
to
be
standardized
so
that
if
you
have
an
application
that
is,
has
been
developed
to
take
this
kind
of
sort
of
state
delta.
You
shouldn't
have
to
re-implement
that
ty.
B
A
All
of
that
put
together,
this
is
kind
of
a
slide
showing
what's
there
today
and
what
we
think
needs
to
be
coming
out
in
the
future.
And,
frankly,
if
you
look
at
the
state
of
internet
applications
and
you
go
to
a
place
like
Apache,
you
can
find
everything
you
need
in
order
to
build
an
application
from
start
to
finish.
You
don't
have
to
get
a
generic,
you
don't
have
to
get
a
generic
blockchain
and
then
try
to
work
the
edges
around
it.
A
A
You
should
be
able
to
link
them
all
together
and
there
are
a
lot
of
advantages
to
doing
that,
and
this
is
taking
a
pattern
that
has
happened
time
and
time
again
for
the
last
50
years
in
software,
which
is
this
starts
off
to
the
monolithic
system
and
it
breaks
apart.
I
know:
I
started
off
in
Java
Enterprise
Edition.
A
We
started
making
that
more
and
more
discrete
components
until
basically,
you
don't
want
to
use
j2ee
because
it
got
too
complex
and
then
everybody
started,
making
very
standalone
components
that
you
could
now
build
real
applications
with.
So,
if
you
take
this,
we
talked
about
block
storage,
being
probably
the
primary
thing
that
nobody
in
black
chains
is
thinking
about
today,
block
archiving
there's
a
labs
product
out
there,
but
nobody
seems
to
be
committing
to
it.
A
There's
key
storage,
pluggable
consensus
and
I
actually
have
something
on
another
slide,
but
while
it's
up
there
with
all
of
these
on
enterprise,
aetherium
fabric
and
sawtooth,
if
you
just
took
those
three
they're,
all
open
source
programs,
they've
all
implemented
a
way
to
do
pluggable,
consensus
and
they've
all
not
abstracted
it
out,
so
it
can
be
used
between
programs.
So
if
you
are
a
consensus,
writer
going
pbft
and
I
just
use
that
one,
because
that's
practical
Byzantine
fault
tolerance
for
those
who
haven't
heard
of
it.
A
A
lot
of
universities
for
some
reason
seem
to
put
their
masters
and
PhD
people
on
it
right
and
yet
another
pbft
consensus.
You
should
be
able
to
plug
it
in
make
it
work
and
show
people
how
it
works
very
quickly,
and
wouldn't
it
be
great
if
it
was
a
shared
library,
the
network
and
connection
management
layer.
Really
this
is
communications.
Gossip.
A
All
that
kind
of
stuff
really
can
be
brought
down
to
a
layer
that
it's
an
in-and-out
area,
there's
no
facade
for
business
logic,
if
you
think
about
it
as
you're
writing
business
logic,
you
really
want
something
that
glues
on
to
your
blockchain
and
you
can
use
it.
I've
had
three
or
four
people
at
this
show
tell
me
that
they're,
probably
their
team
is
actually
writing
a
basically
a
standard,
centralized
app
and
then
they
just
reference
blockchain
off
of
it
wouldn't
be
better.
A
If
it
was
an
exposed
set
of
endpoints,
you
could
access
and
and
make
it
into
a
real
distributed
application
as
opposed
to
a
centralized
application.
I
mean
even
in
the
blockchain
top
50
coins.
If
you
look
at
those,
eleven
of
them
are
fully
standard
or
I
would
say
not
distributed
whatsoever,
even
though
they
call
themselves
a
blockchain
and
I
can
take
you
through
that
privately.
A
If
you
want
one
that
everybody
knows
about
is
iota
which
collapsed
because
of
their
central
coordinator
and
was
down
for
two
weeks,
so
there
are
a
lot
of
centralized
applications
masquerading
around
this
would
have
enough
Assad
for
business
logic,
allows
you
to
build
it
and
actually
have
a
real
distributed
application.
We
talked
about
data
exporting
data
importing
having
a
way
to
do
what
they
call
Oracle
support.
I
love
the
way
all
the
names
are
different
now,
but
the
functions
are
the
same.
They
were
10
15
20
years
ago.
A
There
is
no
access
control
to
a
corporate
ID
when
I
say
that
you
know,
LDAP
does
have
a
very
sorcerer
IDs
right,
except
it's
called
Active
Directory
for
99%
of
the
big
companies.
Why
don't
we
have
a
standardized
way
of
dragging
that
and
putting
that
access
in
membership
services
governance?
So
those
are
some
ideas,
but
if
you
take
all
these
together,
do
you
need
a
fabric
or
Sawtooth
and
I
row
or
borough
I,
don't
think
so.
A
I
think
you'd
be
able
to
assemble
your
own
and
be
able
to
do
the
distributive
properties
yourself,
and
so
just
I
threw
one
slide
in
here:
real
quick.
What
about
layer,
2,
layer,
3,
sidechain,
seat
channels?
All
of
that
stuff?
The
thing
about
those
is
almost
in
entirety.
They
are
a
separate
app
sitting
in
the
cloud
that
you
access
so
you're,
giving
your
data
up
over
the
cloud.
A
They
have
a
separate
API,
separate
network
connections,
transform
data.
So
no
longer
are
you
in
a
blockchain
to
share
between
companies?
It's
not
only
a
company
you're
sharing
it
with
the
companies
supporting
it.
So
if
your
blockchain
doesn't
support
some
function
and
now
you're
doing
a
layer,
2
app
or
a
layer,
3
app
now
you're
reaching
outside
of
your
own
circle
of
black
chains.
If
you
got
five
companies
now,
you've
got
to
have
things
in
there
like
compliance,
Sox
and
PCI.
A
A
Cyber
currencies
involved
in
transacting,
for
example,
there's
one
major
black
chain
that
has
consensus
as
a
service,
except
you
have
to
pay
them
in
their
chain
and
I've
talked
to
several
companies
talking
about
well,
you
know:
I
have
to
go
to
my
accounting
department
have
to
allocate
out.
You
know,
$100,000
sit
in
an
account
by
this
particular
cyber
currency.
Have
it
sit
there
until
it's
drawn
down
as
we
use
it
and
then
get
another
hundred
thousand
in
the
accounting,
for
that
is
a
nightmare,
and
that
alone
killed
the
project.
A
He
was
trying
to
figure
out
how
to
get
all
of
this
to
happen.
So
if
the
components
come
out
and
this
works
I
think
personally,
that
would
really
make
the
blockchain
community
go
faster
and
I
already
talked
about.
You
know:
fabric
sawtooth
and
enterprises
of
cerium
all
having
a
consensus
library,
so
today,
hyper
ledger
greenhouse
has
all
of
these
applications.
A
Then
you've
seen
that
little
house
around
I
think
hyper
ledger
needs
to
be
the
Apache
project
list
on
the
right
when
I
started
with
Apache,
it
had
been
around
for
a
little
while
and
it
had
one
project
met
Brian.
We
had
HTTP
I
brought
some
Java
in.
We
suddenly
had
two
projects.
I
was
with
a
company
called
IBM
at
the
time,
so
we
ended
up
having
to
write
the
Apache
200
license
or
the
Apache
guys,
because,
as
the
blockchain
guys
are
today,
they
were
the
young
kids
then,
and
we
were
the
old
old
guys.
A
A
We
don't
do
coins,
so
we
don't
do
quilt
we're
looking
at
Ares.
All
these
are
ways
that
you
can
start
building
a
blockchain
from
the
ground
up,
I,
don't
think
you're
gonna
end
up
needing
to
have
a
fabric,
a
sawtooth
or
any
of
the
other
ones
as
themselves.
I
think
you're
gonna
end
up
having
components
that
you'll
build
like
you
do
standard
applications,
and
this
is
for
private
chains.
This
is
not
talking
about
a
public
chain
and
that
type
of
stuff.
So
do
we
have
any
questions?
A
B
Like
to
just
make
a
comment
before
we
take
questions
is
that
we've
got
up
here
and
sort
of
been
we've
been
preaching
about
all
these
things
that
should
be,
and
I
want
to
make
it
clear
that
almost
everything
we've
we've
proposed
here,
we've
already
started
working
on
in
some
form
internally.
This
is
actually
not
something
that
we're
just
guessing
about
we're
saying:
oh,
it
should
be
there.
It's
something
that
we've
all
heard
of
them
are
things
that
we've
concretely
started
working
on.
B
The
only
thing
that
we've
been
able
to
push
out
so
far
is
the
is
The
Client
SDK,
which
was,
which
was
a
pretty
big
effort
to
get
the
time
together
to
push
it
out.
So
I
I
just
wanted
to
make
it
clear
that
we're
not
trying
to
be
up
here
and
be
preachy
and
trying
to
say
this
is
what
you
guys
need
to
do,
we're
doing
it.
We're
doing
it
to
the
best
of
our
ability,
with
the
resources
that
we
have
and
we'd
like
to
do
more
and.
A
As
you'll
find
out
with
an
open
source
project,
it
need
to
be
a
lot
of
hands
in
it.
The
reason
and
we're
big
open
source
advocates,
so
we
will
open
any
of
our
code
up
that
people
have
we
just
don't
want
to
open
it
up
and
have
lots
of
questions
to
deter
us
from
building
our
regular
application.
So
if
anybody
is
interested
in
any
of
those
up,
there
will
we'd
love
to
talk
to
you
any.