This is epicenter episode 102 with guest Matthew Kerner.
This episode of epicenter is brought to you by shape-shift
IO, the easiest fastest and most secure.
Cure way to swap your digital assets.
Don't run a risk of leaving your funds, on a centralized
exchange, visit shapeshifter, Ohio to get started.
Hi, welcome to epicenter the show which talks about the
Technologies, projects and startups, driving
decentralization, and the global blockchain Revolution.
My name is Sebastian, would you change and financial services
will talk about? Recent announcement from
Microsoft regarding the cocoa framework, which use this
trusted, execution environments in a special way to make
Consortium Block Chain networks. So, Matthew welcome to the show.
Thanks for coming on. Thank you so much for having me.
So before we begin like we like to know how how you got
interested in blockchains while working at Microsoft, it found
me what happened was that across the company.
We were broadly people. Within the company we're
starting to look at blockchain and it found its way to my team
because broadly we owned set of verticals including financial
services. And so it made sense for us to
look at it within the Azure team.
Mmmmm. And so we borrowed one person
for my team and we thought perhaps it would be a flash in
the pan and we would get some things in the marketplace and be
done. And as we got involved, we saw
that it was a much bigger deal and I started spending more and
more of my time and got to a point where I just sort of
couldn't stop reading about it was I was ravenous for
information and quickly decided that there was a real strategy
that we needed across the company here.
And so we built a team and we're incubating that as a workload
now, Working with a variety of customers and partners to see
where it takes us. So can you tell us like what
your team does? Exactly sure.
My team is responsible for two. Things were responsible for
financial services as a vertical on Azure.
And there, we look at more than blockchain.
That's everything that's required to enable bank's,
Capital markets, insurers payment, providers, and other
Financial organizations to run on Azure.
Whether it's a compliance certifications, or a certain
features, that the platform needs to have.
Or an ecosystem to support that market is V.
S&S eyes. So that's one half of what the
team does and then the other half of what the team does is to
work on blockchain as a workload, and that crosses
multiple different Industries and their, you know, we're
building the blockchain technology in the Azure team
that we make available on our cloud and we're also responsible
for. So the overall blockchain
product strategy for the company working with a variety of
different teams, who work with customers and partners to plan
out what we'll do. I got to say, I've been really
just very impressed with all of the all the interesting stuff
that's been coming out of Microsoft, you know, especially
in these recent years and and just the level of commitment to
blockchain Technologies that's been coming.
Apparently at the CEO level even setting aside in Adela, you
know, coming to events and visiting, you know, startups,
you know, in these Microsoft developer events in like, last
year here in Paris and and I I've got the feeling that you
know a lot of people see Microsoft is like this old
incumbent, you know, windows and like the Steve Ballmer years and
even before that but I think a lot of people primarily myself
you know but I think a lot of people like myself think that
neglect to realize that Marcus has changed a lot the last few
years. You know, open-sourcing dotnet
and really dedicating to open source and sort of opening the
company to all these different Technologies.
So you know, can you talk to us talk?
A bit about that change and I think you've been at Microsoft
for quite a while, like, how, how does that change perceived
internally? It's a breath of fresh air and
it has changed dramatically. I joined Microsoft in 2001 and
to put it in perspective three weeks after I joined the
company, we had the Windows XP ship party and it was a very
different time. I spent a number of years
working in Windows and it really is a different place.
Now we're spending a lot more. More time listening to
customers, deeply understanding, where they're at, we're seeking
to learn meet customers where they live and it takes us down
some paths that the company traditionally might never have
gone down, including open sources, you say, as one Trend.
But also I think they're disruption of the on-premises
package software business shifting to a cloud model is a
huge deal. That's changed the way we think
about Enterprise Computing and blockchain is one of these
emerging things that yet again. The models of the Way businesses
approach their markets and businesses approach, the
technology that enables them to run in those markets and scale.
And one of the big sort of efforts that Microsoft is
working on is helping customers digitally transform their
businesses. And we think the blockchain is
part of that story, although we're really just at the
beginning of it and certainly it's true that across the
company. Many leaders, see major
potential here for this to be a disruptive new technology.
Trend and we don't want to miss it.
And so, we are absolutely investing in a big way.
And we're committed to seeing this through and having a take
us to places where honestly, we're not entirely sure what
those places are yet. We'll just have to see.
No, no definitely. Well on that note, you know, it
seems that right now everywhere you look especially, you know,
in the last year or so like in terms of Enterprise awareness of
blockchains there's just been like this peak hype cycle.
And there's a lot of noise, there's a lot of there's a lot
of undesired noise. So you know, from your
perspective, how should should businesses be thinking about
blockchains? How could should businesses be
thinking about the potential for blockchain Technologies in
Enterprise? We think that we are just at the
beginning of a sea change here and it really is just the
beginning. There are so many things still
to be sorted out. We don't yet in the industry,
have established patterns of successful production.
Deployments running at scale in an Enterprise context that
people can reference and learn from.
And so I think I think it's I think there are a variety of
different postures that a business can take and and these
postures could apply to any technology Trend if I think for
example about cloud. And if organizations are not
aggressively adopting cloud and using it to transform the way
their businesses work, they're in trouble because their
competitors are likely doing this in their competitors.
Now have an asset that that is differentiated and sets them
apart when it comes to blockchain.
I think lots of organizations are in a wait-and-see mode and
it's not unreasonable for organizations to be there.
Ice again, as, as I said, I think we're just at the
beginning and it takes a certain kind of organization to devote
the talent and resources and thought to build a business.
Strategy, set of business processes, a technology plan and
a go-to-market strategy to make blockchain work for them.
And those are the organizations that we most want to be working
with closely right now. And we're aggressively sort of
building those relationships with the companies that we see
who deeply, understand the Enterprise deeply understand
their industry and are investing to take a leadership step with
blockchain. And I think the payoff that
those companies can get, if they take that kind of jump is that
they establish? Polish an early Market lead, and
in many cases that early Market lead can become an unassailable
sustainable advantage over time. So there is a payoff but I think
it takes a lot of effort and cost and none of the
organizations that we talked to Enterprise organizations,
looking at doing blockchain projects, find it to be simple
easy process today. And so that I think speaks to
the opportunity that we have to bring a variety of assets that
Microsoft has to Bear to make blockchain easier for the
Enterprise to consume meeting the assumptions that enterprises
have about non-functional requirements, plugging into
their existing processes, Talent pools technology platforms, and
so, that is sort of a major investment area on my team. in
your experience, Matthew of When you talk to Enterprise clients,
what are the key requirements? For blockchain platforms, that
that come across to Microsoft? And how are they different from
the open source public varieties?
That sure that we find it's a great question.
That I think these requirements are often the same that
enterprises as the as the requirements that enterprises
have had for a long time. When it comes to more
traditional technology that they might deploy like a database,
they're interested in scale, they're interested in low
latency, they're interested in confidentiality they want to be
able to manage that workload and have policies that govern how
that workload is going to run. And so all of those are
non-functional requirements and they're just Enterprise
assumptions and nowhere in an Enterprise.
Are they deploying production workloads without meeting those
expectations? Then on top of that specifically
when it comes to blockchain we kind of divide our customer base
into two sets. There are a small number of
organizations who are extremely deep on cryptography and
distributed systems and they want to have a very Tell
technical conversation and so they've got some specific
requirements around how blockchain will work for them.
But most customers that we talked to say, look this
blockchain thing is new technology, we don't have the
expertise in our organization to be able to consume it.
But we would like to use it because we see the promise of
transacting across trust boundaries in a new way where we
see a new arrangement for the market that we participate in
that we would like to bring to fruition.
And so they're interested in technology that will make it
easy for organizations to plug blockchain into their business,
as opposed to just doing a technology-oriented proof of
concept. And that's one of the places
where we end up having a very relevant conversation.
Because we're not only talking about blockchain technology, but
we're also talking about a cloud platform than many of these
customers are already using. We're already talking about our
identity offering with Azure active directory, that you know,
over eighty percent of the fortune.
Hundred are already on and thousands of SAS applications
integrate with and we're talking about the productivity platform
that thousands of organizations are running on Office 365
Dynamics and then partner offerings like the Creative
Cloud that comes from Adobe. And so there are a variety of
touch points that we have with Enterprises and they've got
requirements down at the bottom. Let's say when it comes to the
blockchain, second Cloud platform that are non-functional
in nature and they've got business requirements.
He's up at the top to make blockchain consumable by lines
of business, as opposed to technical Wizards with a
specialized skill set. And so that's those, are the
conversations that we have with most of the Enterprises that we
deal with. Okay, so like one of these
special things about the cocoa framework, is that it uses these
things which are called bees or trusted execution.
Environments, can you explain what is a trusted execution
environment? Sure.
Really briefly trusted execution.
Environment is a way of running code that operates on data, on a
computer that protects this process from disclosure, to the
outside and from tampering from the outside.
And if you take the case of a hardware based TV like Intel
sgx, just as one example, the chip enables you to create
what's known as an enclave, which has a security boundary
around it. And The code and data inside of
The Enclave is encrypted except when it is inside of the Chip
And executing. So the operating system, the
local admin, the hypervisor cannot see the plaintext data,
that's inside of The Enclave, nor can they tamper with the
contents of The Enclave? Without The Enclave, the chip
detecting it and then the chip will shut the Enclave down and
stop it from proceeding if it's been tampered with.
And so you have this interesting pattern with trusted execution
environments where To create a trusted execution, environment,
the code inside of that tea does inside of The Enclave, doesn't
trust the OS. And so I can't rely on the
operating system for system services that it might normally
expect to consume like threading memory management
synchronization and so on nor does that code necessarily trust
the local admin. And so it's a sort of a
different threat model that you can operate with on a computer.
Then you used to be able to do the other thing.
The two e's can do useful capability as they can produce.
What's known as a Nazi. Station, which is a blob of data
that can be remotely verified that proves that the te is, in
fact, a valid T and that the data or the code inside of the
te was initialized in a certain way.
So you know, essentially what program is running inside of
there and since it's remotely verifiable, you can do things
like create a secure connection to its ee on another machine
establish trust and determine that that to you.
He is. In fact, the thing that you
think it is is and what you end up with is basically this
remotely verifiable strong identity for code.
That doesn't assume and it's threat model that you trust the
local admin or the operating system.
And so that capability we think is a key foundation for how
blockchain can run in the Enterprise.
This is really good visualization, the strong
identity for code. So it's essentially a te is an
execution environment that is protected by Hardware where it
receives inputs. Those inputs can be encrypted
and they are decrypted within the hardware a computation is
executed and then the te will produce an output and that
output would be accompanied by an ant.
Station, which I presume would have some sort of a signature
that signature could be like the certificate of the Tes
manufacturer like Intel. And if you trust that
certificate and if you trust that the te was in fact produced
by Intel then you can trust that the computation was in fact what
the attestation had provided. So you can sort of audit the
code and have a fairly good. Well reasonable assumption that
well, This this execution environment did in fact produce
the code that or the output that was it was programmed to
produce. Yeah that's absolutely right and
I would add T he's need not be solely based in Hardware.
We have one which is built into Windows Server.
It's called Windows Server virtual secure mode or VSM and
so you can have software-based E's as well and the benefit of
that model in our cases, it's implemented by the hypervisor.
So you don't for example, have to trust the host OS on a node
that's running virtual machines that host OS.
Can't see the memory contents of enclaves that VSM creates for
the EMS only, the hypervisor can see it.
And so, at that point, if you, if you are willing to trust
Microsoft as the hypervisor provider, you can have a degree
of trust that, that would go beyond that that you might place
for example, in a Hoster Is that similar to something like a zkp
circuit? Yeah.
And this is a really interesting comparison.
The comparison of Tes and other cryptographic models that use
just math to provide some of the capabilities.
Well, let's say an intersecting set of capabilities, of what you
get with two e's. The beauty of something like a
zero, knowledge, proof or homomorphic encryption.
Is that you have a mathematical basis?
For the confidentiality of the data or the correctness of the
results that you're getting from a computation.
And so even if an adversary could completely compromised all
the parts of a machine that's verifying one of those proofs.
They couldn't get access to the data if the assumptions of the
math the cryptographic Assumption of the math or sound
and the trade-off that people except when they use these sorts
of schemes is typically a time and space.
Trade off. Well, there are actually three
terios there's a Time trade-off. You know, we can take longer to
produce these sorts of cryptographic results and it
would take to use a te to produce the results.
There can be a space trade-off where the size of the of the
cipher text or the size of the proof is large enough.
That it can become an impediment to scale, throughput or latency.
And then the third trade-off that people make is that
sometimes these schemes will require that you bootstrap.
Some Randomness and so you have to go through the overhead of a
key ceremony to establish Randomness if you if you truly
want to have a trustworthy system.
So there are trade-offs. I'd also say that there are
there are some while it may be mathematically possible to
express anything with a zero knowledge proof.
Practically speaking, there are boundaries and it can be much
easier to accomplish some tasks using a trusted execution
environment. Because the programming model
looks very similar to what people are used to today in
comparison to Some of these cryptographic models where it
takes, you know, a postdoc with a cryptographic background to
figure out how to achieve a certain task.
And so, I think that's a big distinguishing Factor.
With this background in T is maybe we could jump into
eventually like what is the Coco framework and what it is trying
to do. But even before we go to the
cocoa framework, I think one of the, one of the one of the
interesting questions is like blockchain technology was was
was developed in sort of this decentralized mode where The
expectation was that they would be like multiple nodes that will
be controlled by different people working together to
create something like, which is trying to be trustless.
Now Like with with Microsoft like when Microsoft is trying to
offer say blockchain as a service platforms, then the
Assumption becomes that like all of the cloud nodes are like
hosted by Microsoft. They might be running T Tes, and
this is some form of execution or guarantee might be given.
But if all of the nodes are on the cloud controlled by one,
like one or two different corporations, there is like
blockchains Reserve is trust model in any way.
I think this topic is really interesting, and I think that
we're also at the beginning of this debate, and we're going to
see where it takes us. I will say, we do not operate
with the assumption that Block Chain networks, that run in
Azure run entirely in Azure. I think that that would just be
silly, we would not be meeting customers where they live the
nature of blockchain is at least in the enterprise.
We think it's at its best when it's used to cross
organizational boundaries where there isn't Universal Trust.
And that means that consortiums are going to form and those
consortiums will undoubtedly include participants who choose
to use a variety of different Cloud providers or run things on
premises. And so, our sort of beginning
assumption on anything that we do in blockchain is we need to
make consortiums work really well with Azure, which means
accommodating infrastructure that runs elsewhere.
So right off the bat, I would assume it's not a world where
everything is centralized on Azure at the very least, you
know, one option. Of course that we make Available
is if people like the facilities that we provide to make it easy
to run blockchain on Azure, they can run that same set of things
on Azure stack, which is our on-premises.
Appliance that combines Hardware plus software to give the same
sort of azure deployment model that we have in the cloud, but
lets you do it in your own data center.
Under your own control with your own network connection, or what
have you. And so, we have customers who
were putting these things on cruise ships in mines, on the
factory floor in regions of the world where we don't don't
currently have a hyperscale cloud presence and so they're
solving lots of different problems with Azure stack.
And and certainly blockchain is one workload that we think is
important to support in that configuration as well.
Then I think the next question is What are the assumptions of
the of the workload that's running on top of blockchain?
There are public networks and those public networks are
expressly designed to be fully decentralized and I cannot take
any dependency on any sort of centralized Authority and, you
know, public clouds might be useful for devtest.
They might be useful for running certain utilities that the
public networks consumed and we may be able to do lots of work
to make the development experience easier for public
networks, but I think that those will continue to be
decentralized in the way that they are today.
Enterprises however, operate in a different world.
They're not typically operating in a market where they're
performing, Anonymous, transactions between arbitrary
counterparties. Usually they're operating in
markets where they have a name, they have an address, they have
a business license, the subject to law enforcement, they're
subject to the jurisdiction of 1/4, another and today, you
know, that all of these non technical controls govern the
way that that Prices behave and I believe that that will be true
for the foreseeable future. So the assumptions for
Enterprises going in a little bit different they may not be
looking for the same set of decentralization guarantees that
people seek on the public networks.
Now, by the way, it doesn't mean that enterprises don't worry
about their Cloud providers. They certainly do and one of the
reasons that we have invested, so heavily in Azure is
compliance posture getting dozens and dozens of
certification. Ins is because we want any
customer in any industry, in any geography, to be able to use our
cloud and certainly compliance as a part of that, but it's more
than compliance. It's also the terms of service
and the way that we conduct ourselves and so certainly
people have been following the Microsoft Ireland case where we
successfully fought to avoid serving a warrant for data that
was held internationally based on a court order in the u.s. we
said that we wanted that to be served by.
We wanted to be served with a warrant in the jurisdiction
where the data was held and we went all the way.
The Supreme Court with that. And so, we are very serious
about running our cloud in a way that enables our customers to
trust us, both individuals and Enterprises.
I guess the, the last thing that I would say is we think that
trusted execution environments are an exciting development in
the history of cloud and we think that the the the point at
which Tes become widespread, it will be a watershed moment.
If we look back in history, Cloud computing.
Because For the First Time customers will be able to Put
their data in the cloud, put their compute in the cloud but
not have to assume that the cloud provider is going to
behave in a certain way. They'll be able to leverage
their trust in The Trusted execution environment to get the
results that they want. You know if you think about this
just imagine that you had some health data of yours and let's
suppose that there was a cloud-based service that you
wanted to run that would enable you and others to provide your
personal Health Data run. Algorithm on that data and then
give you back a result that would tell you.
If you are at risk of acquiring a certain disease, well, you
could encrypt your data to a key that is available inside of a
trusted execution, environment. In the cloud, you could upload
your ciphertext. The cloud could take that and
process it inside of the trusted execution environment, where I
thought say the hardware boundary prevents the cloud
operator from seeing that data in the clear and then the te
could take the result and write it.
Back out in ciphertext and you could take that and then you
could decrypt it, you know, on your own device and see what the
result is. And at no point in time was the
data ever in the clear for the cloud provider to see.
And so we think from a confidentiality and integrity
standpoint trust execution, environments, enable us to sort
of cross a boundary that we've never been able to cross before.
Of course, you still do rely on the cloud for availability, for
performance for durability of the data in that scenario.
But maybe those are characteristics.
Six that enterprises are willing to trust Microsoft to provide in
return for the elasticity, the agility, the set of services
that are made available you know and dozens of regions around the
world at hyperscale. And so we think that that
trade-off is fundamentally attractive to people in
Enterprises decision-makers in Enterprises and so that's why we
think the blockchain has a role in azure.
Well, let's let's get right into it, then the cocoa framework.
So what is the cocoa framework? And can you perhaps describe
that that stack of Technologies or, or the architecture of cocoa
framework? Sure Enterprises.
Everywhere are curious to see how blockchain can be used to
transform their markets and their business.
And as we talked with them, One of the very first concerns that
they raised is that they're used to a set of non functional
requirements that are standard across their entire.
It portfolio, they expect certain levels of scalability,
low-latency, they expect confidentiality of the data that
they put into those systems and they expect to be able to govern
and manage those systems. And those four basic assumptions
are Enterprise non-functional requirements that are really
non-negotiable. And if we look at any Enterprise
product that we produce, those are key shift criteria for us.
And operational criteria over time.
The challenge with blockchain is that it was developed as
technology to run in a public network across heterogeneous
machines. And with with a threat model,
that assumed that any individual party in the network could be
malicious and that threat model is a Byzantine threat model.
In other words, it assumes that any of the counterparties can
replace the code running on their node with arbitrary
malicious code of their choosing.
Saying they could try to cause the system to fail in any sort
of way, including through security failures.
And so the protocols that blockchain needed to use in
order to operate in this hostile threat environment, we're
resource-intensive protocols that also at least to date have
required the vast majority of the data in the blockchain to be
stored in the clear for all participants to see The
governance model is also very basic it is it basically comes
down to the decision of what code is Ron on each of the
mining nodes in these public networks.
And when we talked with Enterprises they feel that the
scalability latency confidentiality and governance
trade-offs that they make with blockchain, are often times too
great for them to consider it for any kind of real production
use and we heard that feedback enough from customers and also
internally from experts within Microsoft have been working on
Enterprise Computing for, you know, 20 Thirty years.
In some cases that we felt there was something that ought to be
done about that and that and we felt that none of the solutions
that were out there in the market.
Really hit the Enterprise design point and squarely and in a
head-on way and so we started working on the Coca framework
and it was an idea that came jointly sort of out of some
thinking for Mark russinovich, who's the Azure CTO and
Microsoft research, where we have a number of people looking
at blockchain broadly and and the basic idea of the Coca
framework is first of all, it's not.
Roger, if you want to run a ledger, you need to use a
ledger. Coco is a framework that enables
many or any ledger to integrate on top of it.
And Coco takes on the job of forming a secure high
performance High. Throughput Network that
implements late basic layer of governance, and then enables The
Ledger to bring its Ledger model to bear, with whatever
abstractions, The Ledger might like to use.
And it brings the set of Enterprise capabilities to that
ledger. Scalability that can handle
thousands of transactions, per second latency where we can
process transactions in Ms. Whether the rather than waiting
seconds, or minutes arbitrary confidentiality models for
fine-grained role-based access to data and governance that
enables a Consortium of Enterprises to decide what rules
they're going to follow and who's going to get to
participate in a structured way. And so Coco seeks to be this
ubiquitous Network fabric for multiple different flavors of
Enterprise blockchains built by a variety of different Ledger's,
across industry verticals and and our hope and intent is that
cocoa will enable Enterprises to consume blockchain without
having to compromise on any of their basic non-functional
requirements. Okay, so if I'll try this time,
just stayed the same thing in my own words.
So like with any block chains, With any blocks and again as
with any public blockchain there's only like three or four
leg four main components to it, right?
So the first is like this networking layer.
So there is this generally, this gossip Network, share notes,
like communicating all of these messages, then there is the
consensus layer or consensus piece, which is like, once you
have these notes and they are communicating with each other,
how they arrive at consensus on? On like, changes to whatever
data set their tracking. And then the third thing is like
a transaction layer, which is like, what do the transactions
enable the users to do? So there's some kind of
transaction logic to it and the fourth might be like a
governance layer. So how do you handle change
upgrades to the to the network to the network consensus or
transaction logic? So, the way like I see Coco is a
cocoa is trying to build just the the networking governance
and consensus systems. And on top of it, anyone can
plug in their own transaction types or on Ledger types.
Yeah. It's a good question.
Coco, certainly seeking to solve that networking layer problem.
It also will come out of the box with a variety of consensus
options and so we can handle consensus for a ledger if the
Ledger wants to to delegate that it does not Concern itself with
the content of transactions per se, that's the ledgers job but
it also does have something to say about governance.
Although I don't expect, the cocoa will ultimately be the
sole answer to governance and Consortium that works.
I think Coco will be responsible to be responsible for some
low-level governance about the basic substrate of that
Consortium and then higher application Level governance
also needs to apply. Just as a very simple example,
suppose we're talking about a blockchain that Implement smart
contracts. Coco doesn't say anything about
which smart contracts. The Consortium members are going
to use for their business processes but it does say
something about what Ledger code versions, those Enterprises are
going to run and who's going to get to participate.
This episode is brought to you by shape-shift the world's
leading trustless digital assets change quickly.
Swap between dozens of leading cryptic currencies including
Bitcoin. Ether is z cash kenosis, Monaro
Golem, auger and so many more when you go to shape-shift dot
IO you simply select your currency pair, give me your
receiving, address sent the coins and boom shift is not your
traditional crypto currency exchange.
You don't need to create an account, you don't need to give
them your personal. Information.
And they don't hold your coins. See you are never at risk from a
hacker, other malicious actor. Shape-shift has competitive
rates and is even integrated in some of your favorite wallet
apps like Jax. So you can swap your digital
assets directly within your wallet just as easily as putting
on your slippers. Whenever you see that
good-looking Fox you know that's where shape-shift is.
So to get started visit shape-shift IO and start trading
and we'd like to thank shape-shift for their support of
epicenter today. Let's look, how do you expect
like Enterprises to use the cocoa framework?
So let's assume like Let's assume like a group of
Enterprises morning to build like a Consortium blockchain for
a supply chain application. So is it the case that they can
just take the cocoa framework like choose a particular flavor
of off Ledger, right? Like like pick pick and you see
them like Ledger system or quarter like Ledger system or
whatever and then mix and merge the two and then deploy your
application. I think supply chain is a great
example, I would let's just start with some of the things
that a supply chain Consortium. I'd like to do, you might like
to have buyers who are going to submit orders for goods and you
might have suppliers who are fulfilling those orders.
And then there are a variety of people who were responsible for
transportation customs and so on.
And then there's maybe another layer of services that are
provided in a supply chain Consortium that that has to do
with trade Finance, where for any one of these, Orders the
buyers really only going to want to pay for it once the goods are
received but the suppliers going to need cash in order to
manufacture the goods and ship them.
And so there's this Gap and so supply chain financiers will
extend credit to suppliers in order to do this and then they
you know they have to determine the terms of that loan.
What interest rate are they going to charge what?
Contingencies are there in the loan and usually they try to get
data on the history of those suppliers and also the history.
The buyers to determine their credit worthiness.
And today a lot of this happens on paper fax machines, wet
signatures phone calls. It's extremely tedious and
there's a tremendous amount of friction and much of this data
is today at least in supply chain.
Shared point-to-point through protocols like EDI and it's
extremely inefficient and Troublesome for people to make
sure that they're in sync. So I think that there's a
compelling value proposition for a supply chain Consortium to
adopt a distributed Ledger. Ledger.
But I think one of the first problems that you would see and
and by the way, this use case is interesting because this is one
of these things that moves at the speed of physical Goods
here. We're not talking about some
digital bear instrument with high frequency trading that's
not the use case. Although there is such a use
case. In this case we're talking about
things that get shipped you know, a phone call is probably
actually faster than the supply chain so it moves above the
speed below the speed of So we're not so worried about the
performance scalability and latency aspects here, but I
think any supply chain, Consortium would immediately be
disturbed by the prospect of having the data from buyers
visible to all buyers and all suppliers.
What goods are they purchasing from whom at what?
Price at? What time?
If if we knew that about our competitors when it came to, for
example, the cloud supply chain, that would be a tremendously
valuable data point for us. And so we keep that that's very
proprietary information for us and we expect our suppliers to
treat it as proprietary information as well.
And I think as any supply chain Consortium would have the same
concern but think, keep in mind you then have these trade
Finance providers, who are trying to extend loans and so
both buyers and suppliers, have an interest in making data
available about how much business they've done.
Let's say in the past 12 months what percentage of the time they
did they deliver on time the right set of It's and and by
sharing that they can get better terms for trade finance, loans,
and by getting better terms for trade Finance Loans, the the
cost that the buyer has to pay ultimately for the goods goes
down, and the margin for the supplier goes up.
So everybody has an incentive in sharing that data.
They also have an incentive in being in sync on exactly where
the goods are. Did they already leave the
factory? Are they on a truck?
Where is the truck as the truck gone through customs of the
things? Ben Tampered with the number
arrived that were expected was at the same set of items that
were in the lot. That was shipped all of these
things getting in sync on, that can be tremendously tedious and
we know from our own business as a corporate, Microsoft's own
business. At this can be an extremely
tedious process and then typically know, traditionally
people would be on the phone working with spread, their
individual copies of spreadsheets to try to verify
all of this stuff. So there's absolutely a business
case to remove friction from the system and tree introduced.
A new model for trade Finance with better financing terms,
Based on verifiable data that's in sync, across all the
counterparties. But I think confidentiality is a
major issue for any supply chain Consortium.
I'm not sure that governance is quite as important.
In other words, unlike let's say, a banking Consortium a
supply chain, Consortium might not have to worry as much about
who's permitted to transact with each other.
They may not have the same kyc requirements, but of course, if
I'm a company in the US and I'm doing Business with a supplier.
I'd be mortified to learn that my supplier was actually a
sanctioned organization. So I might very well want to do
some basic KY caml checks on the set of people who are
participating in the Consortium. So I do think governance is
relevant although perhaps not as relevant.
So let's just to stay on this topic of scalability and
confidentiality because I think that for Enterprise these are
probably the two most important characteristics that they're
going to be looking for. A blockchain.
And so, can you explain then how a cocoa framework enabled,
blockchain Network, so to speak achieves, this high level of
scalability? I mean, I saw this Mark
russinovich demo which will will link to in the show notes where
we're running an evm and you know there's just like thousands
of transactions per second it's just go they the transaction
odometer just goes off the rails.
Rails. And, and so, yeah, let's address
that and also address how we can achieve transaction
confidentiality. When, you know, everybody knows
that on the public etherium network.
It's nearly, it's theoretically, impossible to achieve a
transaction in the current implementation with 3m.
It's impossible to, to, for the transaction, a confidentiality.
Sure. So, so in this, in this
Consortium example, the way that we can do this is first of all,
the Consortium Excel edger. And we've announced several that
intend to integrate with cocoa and are working with several
others that were not yet ready to announce anything.
So they pick their Ledger and that ledger would incorporate
the cocoa framework into its distribution.
And what cocoa does is it makes changes one very basic
assumption among the blockchains, we do not assume
that the participants in the Consortium, trust each other,
they can be adversarial, that's fine, but we do assume that we
can create a trusted. Network of nodes that represent
those members of the Consortium and the way that we do that is
by leveraging, The Trusted execution environment.
So we create on each node, that's a member of the network,
an enclave that Enclave is running The Ledger code, and
some cocoa management code, those enclaves connect to each
other, they exchange at the stations.
And now each of those enclaves knows what the other one is
running, and they can verify that the party on the other end
has not replaced. The code with the malicious code
of their choice. There in fact, running the, the
expected code that the Consortium has decided that
they're going to run. And once you make that
assumption, again, we're not assuming that the members trust
each other. We are assuming that those
members can't tamper with the contents of the enclaves that
they own and we're assuming that the enclaves themselves are
producing valid attestations. Once those enclaves form that
Network we can use much more traditional distributed systems
protocols to achieve things like consensus and data.
Replication Ian and those traditional distributed systems.
Protocols in addition to just being proven over the course of
dozens of years of operation at scale.
They also provide much better characteristics in terms of
latency and in terms of throughput and so we can achieve
scale like you'd expect from a database in the case of
blockchain by using trusted execution environments to set up
this particular kind of trust relationship.
Among the nodes confidentiality is the other thing that we can
achieve. Again the data in the case of
these trusts Situation environments is only ever in the
clear inside of the trusted execution environment.
Meaning that the local admin can't see the contents of all
the transactions flowing through the system.
They have to make a request through an API to read data.
And when they do that, that API can choose what data to show to
each of the individual counterparties who are
participating in the Consortium. And now, instead of having to
use very fancy cryptography that might have a time or space
trade-off or might require you Unique cryptographic knowledge
on the part of the people implementing the system.
You can have a standard Enterprise developer.
Write some logic that says in my Consortium or for this order,
I'm going to make the order visible in its entirety to the
buyer who placed the order and to the seller who's been
selected to fulfill the order. And I'm going to surface
metadata about the order like the total value of the order,
whether it was delivered on time, I'm going to surface that
to any Other who has a role that's a trade Finance role.
Now you've got this very fine-grained are back.
Its standard are back. Role-based access control that
any Enterprise developer would use today.
They set it, you know, an access control list or they write rules
about who can see what data. And then, the code just
implements those rules. And since the code is running
inside of the trusted execution, environment, it can't be
tampered. With since the data is only
unclear inside of the truss execution environment, it can't
be read from the outside. And now all of a sudden you've
got a Consortium that can run. Run at the scale of a database
with the latency of a database and have this arbitrary
fine-grained confidentiality. It's really not clear to me how
that scheme could be implemented using ZK snarks or homomorphic
encryption. It would be a real challenge to
come up with this. Especially this fine grain
confidentiality for that supply chain, Consortium scenario.
This is, this is amazing because back in 2015, so prior to 2015,
there was no notion of Enterprise blockchains at all.
Like, I think the Enterprise block seems like Consortium
chains, mr. In 2015.
And the biggest problem, they faced was the problem of like
privacy the blockchain model. Requiring all of the
transactions broadcast in order to be visible to all of the
Consortium parties and traditionally Dissolution the
proposed solution to it, has always been some form of zero
knowledge proof, but zero-knowledge proves our are
very limited in what they can do.
So this this almost seems like a Holy Grail, right?
Like, you're taking components like trusted execution
environments, which are, which are available and then able to
build a blockchain like Consortium chain platform in
which privacy of data, can be guaranteed by only rules roll.
Role-based access. This seems something which is
like very powerful. We think so, we think that
addresses, the key things that our Enterprise customers are
telling us they want out of blockchain.
And by the way, using cocoa doesn't mean that you have to
give up on all of those other techniques.
One of the ledgers that's publicly Express their intent
integrate. Cocoa is Quorum which was built
by JPMorgan, Chase & is this open source?
Ledger, that sort of a modification of a theorem for
the Enterprise and Quorum already uses point to point
encryption with its constellation system.
To enable private transactions among a subset of members of a
Consortium and Quorum already has on its roadmap, the desire
to incorporate other kinds of cryptography.
Like the the zsl from that derives, from these knowledge
knowledge proofs that derive from the public networks and
they're going to keep those systems and those will be
available to use selectively for use cases, as a Consortium sees,
fit and cocoa. Will be yet another layer that
enables consortiums to achieve what they would like.
And so this is not meant to be sort of a, the one single answer
that's suitable for everything. People will use cryptography,
cryptography, where it makes sense.
They'll use the prosecutor, execution, environments,
wherever it makes sense. And so, we think that people are
going to start being able to mix and match to address their
business requirements. So just to recap just to just to
test my understanding. So what Google can allow
Enterprises to do is like let's assume all three of us are
Enterprises in our supply chain example.
So I don't know. I'm I'm like a Shipping Company
Sebastian official Observer, any and like Matthew you buy some,
some some things in bulk and Sebastian is a lack of, is a
financing company, and all of us are On one like blockchain
Ledger which is running on the cocoa framework.
So me as me as one of the participants I have to assume.
So what do we need to assume? We need to assume that all of us
are willing to Run our nodes on these trusted execution
environments. And once we assume that it gives
me the power to input some data into into the, into the
Consortium chain. Have all of these nodes running
tested, injection execution environments, come to consensus
on that data. And also allows me to
selectively only selectively reveal, my data to the other
Consortium participants. So I can have a mechanism by
which I choose to reveal my data to Sebastian but not to Matthew.
That's exactly right. And by the way, it can be even
finer grains than revealing my data to Sebastian or not to
Matthew. It could be, I'm going to
reveal, you know, the date of the order to Matthew and the
quantity of the order and the date of the order.
Bastion and you could come up with, as fine-grained, a model
as you like. And one of the components of the
demo in the video that we show is, is this application visits
application that's built by a company called Mo Jack's.
That that is a supply chain blockchain based Supply, Chain
management application, and in order to build that application
on top of. So what we did in the demo is we
took the C++ the theory IAM code base and we re platformed it to
run on top of cocoa. But it still has the very same
set of interfaces externally that it had originally and it
has the same execution model inside of the UVM for
transactions. And so all that Magics had to
do. First of all, they removed all
public data from their smart contract definition.
So you can't read the data directly and then they
implemented Access Control logic in each of their smart contracts
where you could read data that just checked the This whoever
submitted the transaction against an access control list
to see who's allowed to see the data and that enabled them to
achieve this fine grained confidentiality.
It's all done in the idiom of The Ledger cocoa.
Underneath provides kind of the core capability to make it work.
But it ends up being very flexible and they really, we
also, we had to disable a couple of apis.
Those apis that enable raw read access to the transactional,
history, or raw read access to Enterprise, or to Smart contract
state Eight, those had to be disabled in order to prevent
people from circumventing, the logic inside of the smart
contracts, but it was a very simple change.
It's not as though we had to break things in a major way, so
they basically just had to pipe their reads through the smart
contract methods and then all of that access control logic
applies. Just just, just a question on
what happens when something goes wrong.
And for example, you have Smart contract and it turns out that
let's assume that smart contract is also handling Financial
value. And now there's a bug in the
contract and because of that bug, that smart contract is
leaking value to some people who shouldn't have access to it.
Now, somebody needs to fix that contract.
So do they get like, So whoever is trying to fix it.
Do they get like access to all of the data handled by the smart
contract? Yeah, this is a great question
and and let me sort of work my way into it.
First of all before before anyone uses Coco, they need to
do a threat model, they need to look at the particular business.
They want to run in their Consortium and decide what,
trusted execution environments might be suitable for handling
that data, because different teas have different
characteristics. And so that's sort of Up one and
I imagine there will be some workloads that are not suitable
for cocoa and that's fine. The next thing is we assume
breach and Azure. We assume breach at Microsoft,
we assume breach, we just assume breach and we've got to make
sure that things work the way. The customers should expect,
even when breach occurs. And so, that means we have to
assume that a te can be compromised at a even and and
that's a much worse failure than a smart contract.
Having it Fact because te compromise would expose
everything and let if we approach it in a naive way and
so are our design seeks to do several things.
First of all, minimize the possibility that a breach
occurs, second of all, make it easy to detect.
If a breach occurs and third of all minimize the blast radius,
when a breach occurs and so that and make it possible for people
to recover. So, the first thing is, we're
sort. Art of working with Microsoft
research on a variety of techniques to avoid bad code
failures inside of trusted, execution, environments.
And so Microsoft research has published some papers on this
that there are compiler techniques static and dynamic
analysis that can prevent data from leaking outside of a t,
even if there's a compromise inside of the T.
So there are some classes of bugs that we can just eliminate
up front. The next thing is, I worry about
the size of the trust. Computing base inside of the tea
inside of the enclave. And so in our design we will we
will end up with a model where we have actually multiple
different enclaves running. At the same time on each node,
there's an enclave that runs the cocoa management software which
is a relatively small code base. It's carefully audited, and it's
consistent across all Integrations with cocoa.
And then there's another Enclave that runs The Ledger codebase,
and that could gaze could be potentially larger that will
vary by. Ledger.
It might be a varying quality depending on which Ledger you're
talking about. And so we've now reduced attack
surface because all of the key material, for example can be
stored inside of the smaller more trusted Computing base.
And only data is encode related to The Ledger stored in the
other one. The next thing we did is we
designed a threshold encryption scheme and the idea here is if
somebody were to be able to compromise an individual node,
we wouldn't want them to be able to decrypt, the entire Ledger,
and then run off with it. And so there, this threshold
encryption lets you generate a group of public key and that
group public key, lets any of the nodes encrypt data
efficiently. And then, in order to decrypt,
you need a quorum of nodes. So to each perform a partial
description and those decryption shares can be combined to reveal
the plain text. And what that means is if you've
got one counterparty who saw Um, how compromises it to you and
they want to decrypt, the entire Ledger, they need the
cooperation of a quorum of other counterparties in order to
actually get to the data and so that enables those
counterparties to have policies, like, rate limiting, the number
of descriptions that anyone can do, and if that rate limit is
succeeded, they can alert and it was very important to us.
By the way that we did enable sort of offline decryption by a
quorum because there's a disaster recovery scenario where
you No longer have the t's that were storing, the keys that were
being used and you need all of those members to be able to
conclude this time for legitimate purposes to
rehydrate, The Ledger in new infrastructure so that it can
continue to run. And so there's a variety of
different measures that we took to model the possibility that a
te could be compromised. And to be able to detect it, you
can for example have teased reattached periodically, you can
roll over the keys that individual members are using.
And so ultimately, we envision that all of these
countermeasures will Be controllable by policy.
There's there's also a question when it comes to the consensus
model that's used in this network in blockchain today.
Of course, with let's say, proof of work every single node and
even proof of stake. Every single note is going to re
execute all of the transactions in a block in order to verify
that they're valid before accepting that block on the
chain. That requires them to be able to
re execute those transactions. So the data has to be in the
clear and you have this It's overhead and and this sort of
energy consumption overhead. And so we think that there will
ultimately be a variety of different consensus models,
available in Cocoa, including proof of work.
By the way, there's no reason you couldn't do that if you
wanted it inside of a cocoa deployment.
But we think that there are some interesting consensus models
that could come out where for example, you could elect a
leader. And then that leader is the only
one who ever has to execute a transaction.
Once the leader executes, the transaction, it takes the
resulting State changes and broadcasts.
Its all of the other participants.
Isa pants in, in the network and those participants just blindly
accept the state changes from the leader in commit them.
And this is a pretty high throughput model.
It's sort of consistent with what you may get in a system
like, paxos, where you'd have a replica set and you'd want a
quorum of replicas to commit the data before you consider a
transaction valid. So, that it's durable.
But this is a, in this, in the, in this model, you're only
worrying about crashes, you're not worrying about Adversaries
with who are running malicious code.
Now, even in this model, you can assume that maybe some of the
members in the network could somehow compromise, its he and
become malicious. And and so there, you might want
to have a model where asynchronously, let's say you
have a set of nodes who are responsible for fully
validating, every single transaction that they see.
So we'll leader is still the one responsible for broadcasting.
The state changes, the majority of nodes synchronously, except
those State changes and move on. And then asynchronously, you
have some other nodes checking to make sure that the leader has
not gone off the reservation and done the wrong thing.
And if of course, if any of the nodes does detect a violation,
they can alert. And you can Rewind The Ledger.
Back to the, to the last agreed upon State.
You perhaps, you kick out the bad actor and then you can, and
then you continue. So, we do assume that there are
these problems down at The Ledger layer, and we have a
variety of defense-in-depth, measures to reduce the
likelihood of a catastrophic failure there, we actually.
Really don't do anything to address.
The failure scenario that you described which is a bug in a
smart contract. That is entirely an application
Level concern and the cocoa framework in and of itself
doesn't really know or care about that.
And so that would be a problem that the participants would have
to sort out amongst themselves. And by the way that I don't
think that's a soft problem either and it's a very
interesting one. Well, perhaps that's a good
segue into into governance. And so the framework and I
thought this was one of the most interesting parts of the
framework talks about the governance model and the way
that you deploy a network, so it Coco framework has within it.
This is a description of how Consortium members can deploy a
network with. Just with, just one note, with
just one Consortium member sort of initializing the network and
then other members, Coming on board.
Can you walk us through? You know, let's let's keep on
this on this supply chain example, let's say I'm, I don't
know Walmart and I want to initialize this network and then
start bringing on trade Finance actors, suppliers transport
companies, you know, and all of the different participants and
supply chain. How would I as Walmart for
instance, deploy a network, using the cocoa framework.
It's there's a great. Chin and it starts with some
basic agreement on the parameters that all of the
members are going to use. They if they have to pick a
ledger it's not as though cocoa is like a lingua Franca - Franca
between Ledger's we're not attempting to solve that problem
so you have to pick your Ledger and you've all got to agree on
the code version of The Ledger that you want to use.
And you've all got to agree on who is going to participate at
least at the beginning, you can have changes their overtime but
there's got to be some initial set of members that you're going
to choose to do business with. Then you're going to have to
agree on a variety of settings that relate to Coco.
Like what trusted execution environments, you're going to be
willing to accept. You only want Hardware ones, you
want software ones, which ones. And for example, you need to
agree on a threshold for voting among the members, do you
require unanimity in order to approve new members?
Do you need a simple majority? Do you need just some other
threshold M of n could be arbitrary and so each of the
members is then going to set up an environment for themselves
And in each environment they're going to initialize their own
cocoa node. In order to do that, they
initialize the the code and then they connect to The Enclave over
a secure Channel and they would probably the very first thing
they'd like to do is they like to inspect the attestation at
The Enclave gives back to make sure that the Enclave that they
ended up with is actually the one that they wanted.
And and there wasn't a malicious actor, somehow residents on the
Note, who injected some other malicious code inside of The
Enclave. So you say, okay, hey, Hey look,
let's just say, for example, it's running on an Intel sgx
capable chip and so you have an enclave and and there's an SS
station that that looks to be valid.
And you see that the code running inside is in fact
represented by the hash of the Coca framework that you
expected. And so then that member is going
to feed the initial configuration into that node
saying, here are the other counterparties that I'm doing
business with and here are the public keys that are that, that
represent each one of them. And then that It is going to
connect to the other nodes in the network using for example
just DNS to find them and it will initialize connections and
those will be TLS connections and then these nodes exchange a
variety of data they exchanged access stations so they
determine that. Each of them is running two
years and they determine the code that's running inside and
they're in the co configuration are the set of allowed code
versions and allowed to use that are expected.
And so once the nodes have Have performed this validation,
they're ready to go ahead and so they then initialize processing
on The Ledger, all of this metadata that describes how the
network should be formed. And what settings are expected,
we call the network Constitution.
And that Network Constitution is meant to represent all of the
infrastructure level decisions about who can participate and
how they could participate and members are only A accepted into
the network and those connections are only considered
to be trusted if the rules of the Constitution are satisfied
and that is sort of how the initial state looks in a coconut
work. So if a particular Coco network
is deployed with the certain Constitution, do you expect
there to be a lot of changes to this, the truth, to this
Constitution. And I how do you think the
governance process for these changes would look like?
I think that This notion of a Consortium model is tremendously
powerful and that it will, it will disrupt multiple
Industries. But I also think it's poorly
studied and poorly understood today at least by those of us
working on blockchain. I think there are other
consortiums in existence that have been around for a long time
that are very well understood, think about a payment Network.
Like, I don't know, like a Visa or MasterCard.
That's essentially a Consortium of Banks and financial
institutions and and you know, it's not managed in this way in
particular. There's one, trusted party that
runs it. I think that there's, this is a
very rich area for new insight and Innovation and also services
that will make it possible to run, consortiums efficiently.
But I think, you know, to begin with.
And by the way many of those Consortium management problems
are at the application Level as in the example that you gave
before about a Faulty smart contract.
But when it comes to the infrastructure, the Consortium
has a life cycle members may come and members may go and the
software used and even the Tes used by the members will iterate
over time and so those are the basic rhythms by which, I
believe that the constitution is likely to change.
There may be other policy changes.
Like, you might choose a different M of n Threshold at
some point in time, but that feels less likely to me.
I think the common thing that will happen is a Consortium will
get started with a certain set of members, they'll get it.
It off the ground and they'll run it for a period of time.
And once it's The Kinks are ironed out and they're ready to
scale, it they'll bring other people in and at that point
they'll have votes to bring in new members.
They'll have you know, the manufacturers of the ledgers
will have new versions of the ledgers that fix bugs or add new
capabilities. And in some cases, they will
carry a Coco. Payload that changes the the
functionality that the Coca framework provides for that
ledger. And so, these are all updates
that need to be applied and can only be applied if the network
comes Solution is updated to accept them and so we imagine
there will be lots of interesting scenarios around
this governance where we're consortiums will decide hey, I
just want to accept any new distribution that let's say it's
signed by R3 from the from the court of team.
And so, any any signed, our three payload ought to be able
to run all that ultimately needs to be able to be expressed as a
cocoa policy. Not something that we would have
in our V1. But something that we work
towards over Time. And so we'll try to remove the
friction from these basic changes, that would happen in
the network. This is really fascinating.
I mean, I can see how any any Enterprise Consortium looking to
launch a blockchain network. Could find a lot of the
properties and a lot of functionalities that they would
need for production networks within within Coco saw.
I'm definitely going to keep looking into this and I'm
looking forward to seeing how this develops.
We're nearly at the end of our nearly at the end of the show.
But so I've got a couple of other questions.
So one is so we had Marley gray on a few months ago to talk
about project Bletchley. So can you just briefly,
perhaps, tell us if is this connected to project Bletchley
in any way? Is there any overlap there with
other initiatives, at Microsoft? I mean I I presume that all the
Azure blockchain is a service staff will have cocoa and sort
of built-in and you can use that to launch or network.
But what about these other Blockchain projects.
Yeah, you know a large fraction of the investment that we're
making has to do with as and sort of horizontal SAS built on
top of blockchain and Bletchley is that vision for this
connected set of services, many of them existing that can be
used in a in a thoughtfully. Constructed way to enable
Enterprises to take advantage of blockchain as a shared data
layer in many different kinds of business applications.
And so that's a big area of focus for the team.
It's sort of a whole Topic. But one of the things that that
seemed important to us was that the base Foundation be sound for
Enterprise use and you know it became clear that enterprises
would have trouble adopting the paths and Sass that we're
working on in The Bletchley Vision.
If the blockchain was not able to address their needs in terms
of confidentiality scalability performance governance.
And so we think that cocoa and Bletchley are our sort of self
to self-reinforcing Investments. But there are two very different
Investments. Bletchley is really a cloud
platform. Play Coco is not Coco seeks to
be the foundation of blockchain for the Enterprise wherever
blockchain in the Enterprise is running so it can be running on
premises in our cloud. In another Cloud it will be made
available in as open source for free for Enterprises to use and
in and for a ledger manufacturers to integrate and
it will work on both windows and Linux.
So it's going to have very Broad applicability.
And as an open source project, we're not looking for example,
to directly monetize cocoa, but we do think that it's a
necessary investment to get Enterprise adoption.
That then in turn can take advantage of the innovation in
Bletchley definitely, like I could see a lot of value in
that. So, at the moment, you've
written a white paper to which will link in the show notes.
Is there an implementation of cocoa that people can download
and use at this at this time? So where we are today, is that
we've built what we demonstrated?
We Took vanilla aetherium. We modified it to run on top of
the cocoa framework in its current form.
And we adapted we worked with magic smudge, X adapted, an
application to run on top of that.
And that's what we demonstrated in the demo that we did.
We're working right now towards a V1 release of cocoa in 2018.
That would be an open source release over the course of the
Fall. We'll be working on that.
And will probably be working on that with some of the partners
that we've already. Eddie announced Intel with some
hyper Ledger Sawtooth are three with korda JPMorgan Chase with
Quorum. We'll be working on
incorporating cocoa into those Ledger's and then ultimately
again get to an open source release.
In 2018 that I think we'll open it up to 22 broader consumption.
Cool. Well, I'll definitely be looking
forward to that. And so thank you very much for
coming on the show. That it was a fascinating
episode and look forward to having you back on in the
future. Perhaps when you when Microsoft
released see open source framework and we start seeing
applications being built on Coco enabled networks.
Hey I really appreciate the time and the wonderful conversation
questions. Thank you so much and thank you
to our listeners for once again. Tuning in epicenter is part of
the let's talk Bitcoin Network you can.
Find this show and lots of other great shows at let's talk
Bitcoin.com. Of course, if you want to
support the show, there's multiple ways you can do that.
You can leave us a review on iTunes or wherever you get your
podcast. It always helps people find the
show and we appreciate it greatly and you can also leave
us a tip and a tipping address will be as always in the
description. So thanks so much and we look
forward to be back next week.