1
00:00:00,000 --> 00:00:04,300
This is epicenter episode 102 
with guest Matthew Kerner. 

2
00:00:36,500 --> 00:00:39,300
This episode of epicenter is 
brought to you by shape-shift 

3
00:00:39,300 --> 00:00:41,700
IO, the easiest fastest and most
secure. 

4
00:00:41,800 --> 00:00:43,800
Cure way to swap your digital 
assets. 

5
00:00:44,000 --> 00:00:46,600
Don't run a risk of leaving your
funds, on a centralized 

6
00:00:46,600 --> 00:00:49,900
exchange, visit shapeshifter, 
Ohio to get started. 

7
00:00:53,300 --> 00:00:55,500
Hi, welcome to epicenter the 
show which talks about the 

8
00:00:55,500 --> 00:00:57,500
Technologies, projects and 
startups, driving 

9
00:00:57,500 --> 00:00:59,800
decentralization, and the global
blockchain Revolution. 

10
00:01:00,000 --> 00:01:10,300
My name is Sebastian, would you 
change and financial services 

11
00:01:10,900 --> 00:01:14,100
will talk about? 
Recent announcement from 

12
00:01:14,100 --> 00:01:16,900
Microsoft regarding the cocoa 
framework, which use this 

13
00:01:16,900 --> 00:01:19,800
trusted, execution environments 
in a special way to make 

14
00:01:20,200 --> 00:01:24,800
Consortium Block Chain networks.
So, Matthew welcome to the show.

15
00:01:24,800 --> 00:01:27,200
Thanks for coming on. 
Thank you so much for having me.

16
00:01:28,700 --> 00:01:33,200
So before we begin like we like 
to know how how you got 

17
00:01:33,200 --> 00:01:37,400
interested in blockchains while 
working at Microsoft, it found 

18
00:01:37,400 --> 00:01:41,900
me what happened was that across
the company. 

19
00:01:43,400 --> 00:01:46,100
We were broadly people. 
Within the company we're 

20
00:01:46,100 --> 00:01:50,000
starting to look at blockchain 
and it found its way to my team 

21
00:01:50,000 --> 00:01:54,300
because broadly we owned set of 
verticals including financial 

22
00:01:54,300 --> 00:01:56,800
services. 
And so it made sense for us to 

23
00:01:56,800 --> 00:01:58,400
look at it within the Azure 
team. 

24
00:01:58,500 --> 00:02:00,400
Mmmmm. 
And so we borrowed one person 

25
00:02:00,400 --> 00:02:03,100
for my team and we thought 
perhaps it would be a flash in 

26
00:02:03,107 --> 00:02:05,600
the pan and we would get some 
things in the marketplace and be

27
00:02:05,600 --> 00:02:08,900
done. 
And as we got involved, we saw 

28
00:02:08,900 --> 00:02:11,700
that it was a much bigger deal 
and I started spending more and 

29
00:02:11,700 --> 00:02:14,700
more of my time and got to a 
point where I just sort of 

30
00:02:14,700 --> 00:02:17,100
couldn't stop reading about it 
was I was ravenous for 

31
00:02:17,100 --> 00:02:23,500
information and quickly decided 
that there was a real strategy 

32
00:02:23,500 --> 00:02:24,800
that we needed across the 
company here. 

33
00:02:24,800 --> 00:02:27,800
And so we built a team and we're
incubating that as a workload 

34
00:02:27,800 --> 00:02:31,300
now, Working with a variety of 
customers and partners to see 

35
00:02:31,300 --> 00:02:34,600
where it takes us. 
So can you tell us like what 

36
00:02:34,600 --> 00:02:36,900
your team does? 
Exactly sure. 

37
00:02:37,600 --> 00:02:40,900
My team is responsible for two. 
Things were responsible for 

38
00:02:40,900 --> 00:02:43,200
financial services as a vertical
on Azure. 

39
00:02:43,600 --> 00:02:45,100
And there, we look at more than 
blockchain. 

40
00:02:45,100 --> 00:02:48,500
That's everything that's 
required to enable bank's, 

41
00:02:48,800 --> 00:02:51,600
Capital markets, insurers 
payment, providers, and other 

42
00:02:51,600 --> 00:02:55,000
Financial organizations to run 
on Azure. 

43
00:02:55,000 --> 00:02:57,800
Whether it's a compliance 
certifications, or a certain 

44
00:02:57,800 --> 00:02:59,600
features, that the platform 
needs to have. 

45
00:02:59,700 --> 00:03:03,000
Or an ecosystem to support that 
market is V. 

46
00:03:03,100 --> 00:03:05,500
S&S eyes. 
So that's one half of what the 

47
00:03:05,500 --> 00:03:08,300
team does and then the other 
half of what the team does is to

48
00:03:08,300 --> 00:03:10,900
work on blockchain as a 
workload, and that crosses 

49
00:03:10,900 --> 00:03:14,200
multiple different Industries 
and their, you know, we're 

50
00:03:14,200 --> 00:03:17,300
building the blockchain 
technology in the Azure team 

51
00:03:17,300 --> 00:03:20,600
that we make available on our 
cloud and we're also responsible

52
00:03:20,600 --> 00:03:22,200
for. 
So the overall blockchain 

53
00:03:22,200 --> 00:03:24,600
product strategy for the company
working with a variety of 

54
00:03:24,600 --> 00:03:28,100
different teams, who work with 
customers and partners to plan 

55
00:03:28,100 --> 00:03:32,300
out what we'll do. 
I got to say, I've been really 

56
00:03:32,300 --> 00:03:35,700
just very impressed with all of 
the all the interesting stuff 

57
00:03:35,700 --> 00:03:38,000
that's been coming out of 
Microsoft, you know, especially 

58
00:03:38,000 --> 00:03:42,600
in these recent years and and 
just the level of commitment to 

59
00:03:43,400 --> 00:03:45,000
blockchain Technologies that's 
been coming. 

60
00:03:45,200 --> 00:03:49,100
Apparently at the CEO level even
setting aside in Adela, you 

61
00:03:49,108 --> 00:03:52,300
know, coming to events and 
visiting, you know, startups, 

62
00:03:53,100 --> 00:03:56,800
you know, in these Microsoft 
developer events in like, last 

63
00:03:56,800 --> 00:04:02,100
year here in Paris and and I 
I've got the feeling that you 

64
00:04:02,100 --> 00:04:04,400
know a lot of people see 
Microsoft is like this old 

65
00:04:04,400 --> 00:04:07,500
incumbent, you know, windows and
like the Steve Ballmer years and

66
00:04:07,500 --> 00:04:11,800
even before that but I think a 
lot of people primarily myself 

67
00:04:11,800 --> 00:04:14,300
you know but I think a lot of 
people like myself think that 

68
00:04:15,600 --> 00:04:18,200
neglect to realize that Marcus 
has changed a lot the last few 

69
00:04:18,200 --> 00:04:21,800
years. 
You know, open-sourcing dotnet 

70
00:04:22,200 --> 00:04:25,400
and really dedicating to open 
source and sort of opening the 

71
00:04:25,407 --> 00:04:27,100
company to all these different 
Technologies. 

72
00:04:27,100 --> 00:04:29,800
So you know, can you talk to us 
talk? 

73
00:04:30,000 --> 00:04:32,400
A bit about that change and I 
think you've been at Microsoft 

74
00:04:32,400 --> 00:04:36,000
for quite a while, like, how, 
how does that change perceived 

75
00:04:36,000 --> 00:04:39,400
internally? 
It's a breath of fresh air and 

76
00:04:39,400 --> 00:04:43,800
it has changed dramatically. 
I joined Microsoft in 2001 and 

77
00:04:43,800 --> 00:04:46,700
to put it in perspective three 
weeks after I joined the 

78
00:04:46,707 --> 00:04:51,400
company, we had the Windows XP 
ship party and it was a very 

79
00:04:51,400 --> 00:04:53,600
different time. 
I spent a number of years 

80
00:04:53,600 --> 00:04:58,300
working in Windows and it really
is a different place. 

81
00:04:58,300 --> 00:05:00,800
Now we're spending a lot more. 
More time listening to 

82
00:05:00,808 --> 00:05:04,600
customers, deeply understanding,
where they're at, we're seeking 

83
00:05:04,600 --> 00:05:09,600
to learn meet customers where 
they live and it takes us down 

84
00:05:09,600 --> 00:05:12,100
some paths that the company 
traditionally might never have 

85
00:05:12,100 --> 00:05:14,900
gone down, including open 
sources, you say, as one Trend. 

86
00:05:15,400 --> 00:05:18,000
But also I think they're 
disruption of the on-premises 

87
00:05:18,000 --> 00:05:21,100
package software business 
shifting to a cloud model is a 

88
00:05:21,108 --> 00:05:23,700
huge deal. 
That's changed the way we think 

89
00:05:23,700 --> 00:05:27,500
about Enterprise Computing and 
blockchain is one of these 

90
00:05:27,500 --> 00:05:32,800
emerging things that yet again. 
The models of the Way businesses

91
00:05:32,800 --> 00:05:35,700
approach their markets and 
businesses approach, the 

92
00:05:35,700 --> 00:05:38,800
technology that enables them to 
run in those markets and scale. 

93
00:05:39,100 --> 00:05:42,300
And one of the big sort of 
efforts that Microsoft is 

94
00:05:42,300 --> 00:05:44,800
working on is helping customers 
digitally transform their 

95
00:05:44,800 --> 00:05:46,800
businesses. 
And we think the blockchain is 

96
00:05:46,800 --> 00:05:49,200
part of that story, although 
we're really just at the 

97
00:05:49,207 --> 00:05:53,500
beginning of it and certainly 
it's true that across the 

98
00:05:53,500 --> 00:05:55,900
company. 
Many leaders, see major 

99
00:05:55,900 --> 00:05:59,700
potential here for this to be a 
disruptive new technology. 

100
00:05:59,900 --> 00:06:02,000
Trend and we don't want to miss 
it. 

101
00:06:02,500 --> 00:06:04,900
And so, we are absolutely 
investing in a big way. 

102
00:06:04,900 --> 00:06:09,700
And we're committed to seeing 
this through and having a take 

103
00:06:09,700 --> 00:06:12,300
us to places where honestly, 
we're not entirely sure what 

104
00:06:12,300 --> 00:06:15,100
those places are yet. 
We'll just have to see. 

105
00:06:15,800 --> 00:06:19,000
No, no definitely. 
Well on that note, you know, it 

106
00:06:19,000 --> 00:06:21,800
seems that right now everywhere 
you look especially, you know, 

107
00:06:22,000 --> 00:06:26,500
in the last year or so like in 
terms of Enterprise awareness of

108
00:06:26,500 --> 00:06:29,500
blockchains there's just been 
like this peak hype cycle. 

109
00:06:30,500 --> 00:06:34,200
And there's a lot of noise, 
there's a lot of there's a lot 

110
00:06:34,200 --> 00:06:36,600
of undesired noise. 
So you know, from your 

111
00:06:36,600 --> 00:06:39,200
perspective, how should should 
businesses be thinking about 

112
00:06:39,200 --> 00:06:41,000
blockchains? 
How could should businesses be 

113
00:06:41,000 --> 00:06:43,100
thinking about the potential for
blockchain Technologies in 

114
00:06:43,100 --> 00:06:47,300
Enterprise? 
We think that we are just at the

115
00:06:47,300 --> 00:06:50,300
beginning of a sea change here 
and it really is just the 

116
00:06:50,300 --> 00:06:51,800
beginning. 
There are so many things still 

117
00:06:51,800 --> 00:06:54,100
to be sorted out. 
We don't yet in the industry, 

118
00:06:54,100 --> 00:06:57,500
have established patterns of 
successful production. 

119
00:06:57,500 --> 00:07:01,400
Deployments running at scale in 
an Enterprise context that 

120
00:07:01,400 --> 00:07:03,000
people can reference and learn 
from. 

121
00:07:03,200 --> 00:07:07,400
And so I think I think it's I 
think there are a variety of 

122
00:07:07,400 --> 00:07:10,100
different postures that a 
business can take and and these 

123
00:07:10,100 --> 00:07:12,800
postures could apply to any 
technology Trend if I think for 

124
00:07:12,800 --> 00:07:16,700
example about cloud. 
And if organizations are not 

125
00:07:16,700 --> 00:07:19,200
aggressively adopting cloud and 
using it to transform the way 

126
00:07:19,200 --> 00:07:21,800
their businesses work, they're 
in trouble because their 

127
00:07:21,800 --> 00:07:24,000
competitors are likely doing 
this in their competitors. 

128
00:07:24,000 --> 00:07:27,100
Now have an asset that that is 
differentiated and sets them 

129
00:07:27,100 --> 00:07:28,900
apart when it comes to 
blockchain. 

130
00:07:28,900 --> 00:07:32,200
I think lots of organizations 
are in a wait-and-see mode and 

131
00:07:32,200 --> 00:07:34,700
it's not unreasonable for 
organizations to be there. 

132
00:07:34,700 --> 00:07:37,000
Ice again, as, as I said, I 
think we're just at the 

133
00:07:37,000 --> 00:07:40,800
beginning and it takes a certain
kind of organization to devote 

134
00:07:40,800 --> 00:07:44,000
the talent and resources and 
thought to build a business. 

135
00:07:44,100 --> 00:07:48,100
Strategy, set of business 
processes, a technology plan and

136
00:07:48,100 --> 00:07:51,000
a go-to-market strategy to make 
blockchain work for them. 

137
00:07:51,600 --> 00:07:53,900
And those are the organizations 
that we most want to be working 

138
00:07:53,900 --> 00:07:57,700
with closely right now. 
And we're aggressively sort of 

139
00:07:57,700 --> 00:08:00,600
building those relationships 
with the companies that we see 

140
00:08:00,800 --> 00:08:02,800
who deeply, understand the 
Enterprise deeply understand 

141
00:08:02,800 --> 00:08:07,400
their industry and are investing
to take a leadership step with 

142
00:08:07,400 --> 00:08:09,900
blockchain. 
And I think the payoff that 

143
00:08:09,900 --> 00:08:13,400
those companies can get, if they
take that kind of jump is that 

144
00:08:13,400 --> 00:08:17,000
they establish? 
Polish an early Market lead, and

145
00:08:17,000 --> 00:08:20,200
in many cases that early Market 
lead can become an unassailable 

146
00:08:20,200 --> 00:08:24,000
sustainable advantage over time.
So there is a payoff but I think

147
00:08:24,000 --> 00:08:26,400
it takes a lot of effort and 
cost and none of the 

148
00:08:26,400 --> 00:08:28,700
organizations that we talked to 
Enterprise organizations, 

149
00:08:28,900 --> 00:08:32,700
looking at doing blockchain 
projects, find it to be simple 

150
00:08:32,700 --> 00:08:37,200
easy process today. 
And so that I think speaks to 

151
00:08:37,400 --> 00:08:40,500
the opportunity that we have to 
bring a variety of assets that 

152
00:08:40,500 --> 00:08:43,900
Microsoft has to Bear to make 
blockchain easier for the 

153
00:08:44,100 --> 00:08:47,200
Enterprise to consume meeting 
the assumptions that enterprises

154
00:08:47,200 --> 00:08:49,600
have about non-functional 
requirements, plugging into 

155
00:08:49,600 --> 00:08:54,500
their existing processes, Talent
pools technology platforms, and 

156
00:08:54,500 --> 00:09:00,300
so, that is sort of a major 
investment area on my team. in 

157
00:09:00,300 --> 00:09:05,900
your experience, Matthew of When
you talk to Enterprise clients, 

158
00:09:06,100 --> 00:09:09,500
what are the key requirements? 
For blockchain platforms, that 

159
00:09:09,800 --> 00:09:13,900
that come across to Microsoft? 
And how are they different from 

160
00:09:13,900 --> 00:09:16,000
the open source public 
varieties? 

161
00:09:16,000 --> 00:09:19,500
That sure that we find it's a 
great question. 

162
00:09:19,500 --> 00:09:22,800
That I think these requirements 
are often the same that 

163
00:09:22,800 --> 00:09:25,500
enterprises as the as the 
requirements that enterprises 

164
00:09:25,500 --> 00:09:27,800
have had for a long time. 
When it comes to more 

165
00:09:27,800 --> 00:09:30,400
traditional technology that they
might deploy like a database, 

166
00:09:31,300 --> 00:09:33,800
they're interested in scale, 
they're interested in low 

167
00:09:33,800 --> 00:09:37,300
latency, they're interested in 
confidentiality they want to be 

168
00:09:37,300 --> 00:09:40,200
able to manage that workload and
have policies that govern how 

169
00:09:40,208 --> 00:09:44,300
that workload is going to run. 
And so all of those are 

170
00:09:44,300 --> 00:09:47,300
non-functional requirements and 
they're just Enterprise 

171
00:09:47,300 --> 00:09:49,300
assumptions and nowhere in an 
Enterprise. 

172
00:09:49,400 --> 00:09:53,500
Are they deploying production 
workloads without meeting those 

173
00:09:53,500 --> 00:09:56,500
expectations? 
Then on top of that specifically

174
00:09:56,500 --> 00:10:02,600
when it comes to blockchain we 
kind of divide our customer base

175
00:10:02,600 --> 00:10:05,200
into two sets. 
There are a small number of 

176
00:10:05,208 --> 00:10:10,000
organizations who are extremely 
deep on cryptography and 

177
00:10:10,000 --> 00:10:12,800
distributed systems and they 
want to have a very Tell 

178
00:10:12,800 --> 00:10:15,100
technical conversation and so 
they've got some specific 

179
00:10:15,100 --> 00:10:17,300
requirements around how 
blockchain will work for them. 

180
00:10:18,300 --> 00:10:21,300
But most customers that we 
talked to say, look this 

181
00:10:21,300 --> 00:10:24,100
blockchain thing is new 
technology, we don't have the 

182
00:10:24,100 --> 00:10:27,100
expertise in our organization to
be able to consume it. 

183
00:10:28,200 --> 00:10:31,100
But we would like to use it 
because we see the promise of 

184
00:10:31,100 --> 00:10:34,600
transacting across trust 
boundaries in a new way where we

185
00:10:34,600 --> 00:10:38,600
see a new arrangement for the 
market that we participate in 

186
00:10:39,800 --> 00:10:42,300
that we would like to bring to 
fruition. 

187
00:10:42,600 --> 00:10:46,000
And so they're interested in 
technology that will make it 

188
00:10:46,100 --> 00:10:51,300
easy for organizations to plug 
blockchain into their business, 

189
00:10:51,300 --> 00:10:53,700
as opposed to just doing a 
technology-oriented proof of 

190
00:10:53,708 --> 00:10:56,400
concept. 
And that's one of the places 

191
00:10:56,400 --> 00:10:59,000
where we end up having a very 
relevant conversation. 

192
00:10:59,000 --> 00:11:03,000
Because we're not only talking 
about blockchain technology, but

193
00:11:03,000 --> 00:11:05,400
we're also talking about a cloud
platform than many of these 

194
00:11:05,400 --> 00:11:07,800
customers are already using. 
We're already talking about our 

195
00:11:07,808 --> 00:11:11,100
identity offering with Azure 
active directory, that you know,

196
00:11:11,100 --> 00:11:12,400
over eighty percent of the 
fortune. 

197
00:11:12,500 --> 00:11:15,600
Hundred are already on and 
thousands of SAS applications 

198
00:11:15,600 --> 00:11:18,400
integrate with and we're talking
about the productivity platform 

199
00:11:18,400 --> 00:11:22,200
that thousands of organizations 
are running on Office 365 

200
00:11:22,400 --> 00:11:26,100
Dynamics and then partner 
offerings like the Creative 

201
00:11:26,100 --> 00:11:31,700
Cloud that comes from Adobe. 
And so there are a variety of 

202
00:11:31,700 --> 00:11:34,700
touch points that we have with 
Enterprises and they've got 

203
00:11:34,700 --> 00:11:37,500
requirements down at the bottom.
Let's say when it comes to the 

204
00:11:37,500 --> 00:11:39,800
blockchain, second Cloud 
platform that are non-functional

205
00:11:39,800 --> 00:11:42,300
in nature and they've got 
business requirements. 

206
00:11:42,400 --> 00:11:45,800
He's up at the top to make 
blockchain consumable by lines 

207
00:11:45,800 --> 00:11:48,800
of business, as opposed to 
technical Wizards with a 

208
00:11:48,808 --> 00:11:52,800
specialized skill set. 
And so that's those, are the 

209
00:11:52,800 --> 00:11:55,300
conversations that we have with 
most of the Enterprises that we 

210
00:11:55,308 --> 00:11:58,800
deal with. 
Okay, so like one of these 

211
00:11:58,800 --> 00:12:02,200
special things about the cocoa 
framework, is that it uses these

212
00:12:02,200 --> 00:12:05,400
things which are called bees or 
trusted execution. 

213
00:12:05,400 --> 00:12:09,700
Environments, can you explain 
what is a trusted execution 

214
00:12:09,700 --> 00:12:11,400
environment? 
Sure. 

215
00:12:12,400 --> 00:12:14,200
Really briefly trusted 
execution. 

216
00:12:14,200 --> 00:12:20,800
Environment is a way of running 
code that operates on data, on a

217
00:12:20,800 --> 00:12:28,100
computer that protects this 
process from disclosure, to the 

218
00:12:28,108 --> 00:12:30,300
outside and from tampering from 
the outside. 

219
00:12:30,300 --> 00:12:34,300
And if you take the case of a 
hardware based TV like Intel 

220
00:12:34,300 --> 00:12:38,600
sgx, just as one example, the 
chip enables you to create 

221
00:12:38,600 --> 00:12:41,300
what's known as an enclave, 
which has a security boundary 

222
00:12:41,300 --> 00:12:43,600
around it. 
And The code and data inside of 

223
00:12:43,608 --> 00:12:48,000
The Enclave is encrypted except 
when it is inside of the Chip 

224
00:12:48,000 --> 00:12:51,000
And executing. 
So the operating system, the 

225
00:12:51,000 --> 00:12:55,800
local admin, the hypervisor 
cannot see the plaintext data, 

226
00:12:55,800 --> 00:12:59,200
that's inside of The Enclave, 
nor can they tamper with the 

227
00:12:59,200 --> 00:13:02,500
contents of The Enclave? 
Without The Enclave, the chip 

228
00:13:02,500 --> 00:13:04,800
detecting it and then the chip 
will shut the Enclave down and 

229
00:13:04,800 --> 00:13:06,800
stop it from proceeding if it's 
been tampered with. 

230
00:13:07,500 --> 00:13:10,700
And so you have this interesting
pattern with trusted execution 

231
00:13:10,700 --> 00:13:14,600
environments where To create a 
trusted execution, environment, 

232
00:13:14,600 --> 00:13:19,100
the code inside of that tea does
inside of The Enclave, doesn't 

233
00:13:19,100 --> 00:13:21,300
trust the OS. 
And so I can't rely on the 

234
00:13:21,300 --> 00:13:23,900
operating system for system 
services that it might normally 

235
00:13:23,900 --> 00:13:26,300
expect to consume like threading
memory management 

236
00:13:26,300 --> 00:13:29,800
synchronization and so on nor 
does that code necessarily trust

237
00:13:29,800 --> 00:13:31,900
the local admin. 
And so it's a sort of a 

238
00:13:31,908 --> 00:13:35,600
different threat model that you 
can operate with on a computer. 

239
00:13:35,600 --> 00:13:38,000
Then you used to be able to do 
the other thing. 

240
00:13:38,000 --> 00:13:41,400
The two e's can do useful 
capability as they can produce. 

241
00:13:41,400 --> 00:13:45,100
What's known as a Nazi. 
Station, which is a blob of data

242
00:13:45,300 --> 00:13:50,200
that can be remotely verified 
that proves that the te is, in 

243
00:13:50,200 --> 00:13:54,500
fact, a valid T and that the 
data or the code inside of the 

244
00:13:54,508 --> 00:13:57,000
te was initialized in a certain 
way. 

245
00:13:57,000 --> 00:13:59,600
So you know, essentially what 
program is running inside of 

246
00:13:59,600 --> 00:14:03,300
there and since it's remotely 
verifiable, you can do things 

247
00:14:03,300 --> 00:14:06,300
like create a secure connection 
to its ee on another machine 

248
00:14:07,400 --> 00:14:10,000
establish trust and determine 
that that to you. 

249
00:14:10,000 --> 00:14:11,700
He is. 
In fact, the thing that you 

250
00:14:11,708 --> 00:14:14,900
think it is is and what you end 
up with is basically this 

251
00:14:14,900 --> 00:14:18,000
remotely verifiable strong 
identity for code. 

252
00:14:18,100 --> 00:14:21,000
That doesn't assume and it's 
threat model that you trust the 

253
00:14:21,000 --> 00:14:22,700
local admin or the operating 
system. 

254
00:14:22,900 --> 00:14:26,300
And so that capability we think 
is a key foundation for how 

255
00:14:26,300 --> 00:14:27,800
blockchain can run in the 
Enterprise. 

256
00:14:29,300 --> 00:14:32,100
This is really good 
visualization, the strong 

257
00:14:32,100 --> 00:14:35,800
identity for code. 
So it's essentially a te is an 

258
00:14:35,800 --> 00:14:40,700
execution environment that is 
protected by Hardware where it 

259
00:14:40,700 --> 00:14:43,800
receives inputs. 
Those inputs can be encrypted 

260
00:14:44,100 --> 00:14:48,300
and they are decrypted within 
the hardware a computation is 

261
00:14:48,300 --> 00:14:53,600
executed and then the te will 
produce an output and that 

262
00:14:53,600 --> 00:14:58,000
output would be accompanied by 
an ant. 

263
00:14:58,200 --> 00:15:00,500
Station, which I presume would 
have some sort of a signature 

264
00:15:00,800 --> 00:15:04,700
that signature could be like the
certificate of the Tes 

265
00:15:04,800 --> 00:15:07,300
manufacturer like Intel. 
And if you trust that 

266
00:15:07,300 --> 00:15:11,600
certificate and if you trust 
that the te was in fact produced

267
00:15:11,600 --> 00:15:16,600
by Intel then you can trust that
the computation was in fact what

268
00:15:16,600 --> 00:15:19,600
the attestation had provided. 
So you can sort of audit the 

269
00:15:19,600 --> 00:15:27,400
code and have a fairly good. 
Well reasonable assumption that 

270
00:15:27,800 --> 00:15:30,900
well, This this execution 
environment did in fact produce 

271
00:15:30,900 --> 00:15:33,900
the code that or the output that
was it was programmed to 

272
00:15:33,900 --> 00:15:37,500
produce. 
Yeah that's absolutely right and

273
00:15:37,500 --> 00:15:41,300
I would add T he's need not be 
solely based in Hardware. 

274
00:15:41,700 --> 00:15:44,400
We have one which is built into 
Windows Server. 

275
00:15:44,400 --> 00:15:48,100
It's called Windows Server 
virtual secure mode or VSM and 

276
00:15:48,100 --> 00:15:51,200
so you can have software-based 
E's as well and the benefit of 

277
00:15:51,208 --> 00:15:55,100
that model in our cases, it's 
implemented by the hypervisor. 

278
00:15:55,200 --> 00:15:58,200
So you don't for example, have 
to trust the host OS on a node 

279
00:15:58,200 --> 00:16:00,400
that's running virtual machines 
that host OS. 

280
00:16:00,400 --> 00:16:04,500
Can't see the memory contents of
enclaves that VSM creates for 

281
00:16:04,500 --> 00:16:07,000
the EMS only, the hypervisor can
see it. 

282
00:16:07,000 --> 00:16:09,800
And so, at that point, if you, 
if you are willing to trust 

283
00:16:09,800 --> 00:16:13,200
Microsoft as the hypervisor 
provider, you can have a degree 

284
00:16:13,200 --> 00:16:16,800
of trust that, that would go 
beyond that that you might place

285
00:16:16,800 --> 00:16:21,400
for example, in a Hoster Is that
similar to something like a zkp 

286
00:16:21,400 --> 00:16:23,700
circuit? 
Yeah. 

287
00:16:23,700 --> 00:16:26,000
And this is a really interesting
comparison. 

288
00:16:26,700 --> 00:16:32,300
The comparison of Tes and other 
cryptographic models that use 

289
00:16:32,300 --> 00:16:35,700
just math to provide some of the
capabilities. 

290
00:16:36,400 --> 00:16:40,100
Well, let's say an intersecting 
set of capabilities, of what you

291
00:16:40,100 --> 00:16:43,100
get with two e's. 
The beauty of something like a 

292
00:16:44,700 --> 00:16:47,900
zero, knowledge, proof or 
homomorphic encryption. 

293
00:16:48,700 --> 00:16:51,900
Is that you have a mathematical 
basis? 

294
00:16:53,900 --> 00:16:58,400
For the confidentiality of the 
data or the correctness of the 

295
00:16:58,400 --> 00:17:00,300
results that you're getting from
a computation. 

296
00:17:01,100 --> 00:17:07,000
And so even if an adversary 
could completely compromised all

297
00:17:07,000 --> 00:17:10,400
the parts of a machine that's 
verifying one of those proofs. 

298
00:17:11,099 --> 00:17:14,099
They couldn't get access to the 
data if the assumptions of the 

299
00:17:14,099 --> 00:17:17,400
math the cryptographic 
Assumption of the math or sound 

300
00:17:17,900 --> 00:17:21,200
and the trade-off that people 
except when they use these sorts

301
00:17:21,200 --> 00:17:23,400
of schemes is typically a time 
and space. 

302
00:17:23,500 --> 00:17:26,099
Trade off. 
Well, there are actually three 

303
00:17:26,099 --> 00:17:28,700
terios there's a Time trade-off.
You know, we can take longer to 

304
00:17:28,700 --> 00:17:31,500
produce these sorts of 
cryptographic results and it 

305
00:17:31,500 --> 00:17:34,500
would take to use a te to 
produce the results. 

306
00:17:35,200 --> 00:17:38,200
There can be a space trade-off 
where the size of the of the 

307
00:17:38,500 --> 00:17:42,000
cipher text or the size of the 
proof is large enough. 

308
00:17:42,000 --> 00:17:46,200
That it can become an impediment
to scale, throughput or latency.

309
00:17:47,600 --> 00:17:49,500
And then the third trade-off 
that people make is that 

310
00:17:49,500 --> 00:17:53,200
sometimes these schemes will 
require that you bootstrap. 

311
00:17:53,900 --> 00:17:56,900
Some Randomness and so you have 
to go through the overhead of a 

312
00:17:56,900 --> 00:17:59,800
key ceremony to establish 
Randomness if you if you truly 

313
00:17:59,800 --> 00:18:02,800
want to have a trustworthy 
system. 

314
00:18:03,100 --> 00:18:05,900
So there are trade-offs. 
I'd also say that there are 

315
00:18:05,900 --> 00:18:08,500
there are some while it may be 
mathematically possible to 

316
00:18:08,500 --> 00:18:10,800
express anything with a zero 
knowledge proof. 

317
00:18:11,000 --> 00:18:14,900
Practically speaking, there are 
boundaries and it can be much 

318
00:18:14,900 --> 00:18:17,900
easier to accomplish some tasks 
using a trusted execution 

319
00:18:17,900 --> 00:18:19,500
environment. 
Because the programming model 

320
00:18:19,700 --> 00:18:22,800
looks very similar to what 
people are used to today in 

321
00:18:22,800 --> 00:18:25,100
comparison to Some of these 
cryptographic models where it 

322
00:18:25,100 --> 00:18:28,000
takes, you know, a postdoc with 
a cryptographic background to 

323
00:18:28,000 --> 00:18:30,100
figure out how to achieve a 
certain task. 

324
00:18:30,100 --> 00:18:32,000
And so, I think that's a big 
distinguishing Factor. 

325
00:18:33,700 --> 00:18:37,200
With this background in T is 
maybe we could jump into 

326
00:18:37,600 --> 00:18:40,500
eventually like what is the Coco
framework and what it is trying 

327
00:18:40,500 --> 00:18:43,300
to do. 
But even before we go to the 

328
00:18:43,300 --> 00:18:47,400
cocoa framework, I think one of 
the, one of the one of the 

329
00:18:47,400 --> 00:18:53,200
interesting questions is like 
blockchain technology was was 

330
00:18:54,000 --> 00:18:59,100
was developed in sort of this 
decentralized mode where The 

331
00:18:59,100 --> 00:19:02,500
expectation was that they would 
be like multiple nodes that will

332
00:19:02,500 --> 00:19:06,000
be controlled by different 
people working together to 

333
00:19:06,000 --> 00:19:08,700
create something like, which is 
trying to be trustless. 

334
00:19:09,700 --> 00:19:14,500
Now Like with with Microsoft 
like when Microsoft is trying to

335
00:19:14,500 --> 00:19:19,600
offer say blockchain as a 
service platforms, then the 

336
00:19:19,600 --> 00:19:22,400
Assumption becomes that like all
of the cloud nodes are like 

337
00:19:22,400 --> 00:19:26,900
hosted by Microsoft. 
They might be running T Tes, and

338
00:19:27,800 --> 00:19:30,700
this is some form of execution 
or guarantee might be given. 

339
00:19:31,200 --> 00:19:37,300
But if all of the nodes are on 
the cloud controlled by one, 

340
00:19:37,400 --> 00:19:40,400
like one or two different 
corporations, there is like 

341
00:19:40,400 --> 00:19:43,100
blockchains Reserve is trust 
model in any way. 

342
00:19:45,000 --> 00:19:48,600
I think this topic is really 
interesting, and I think that 

343
00:19:49,600 --> 00:19:51,700
we're also at the beginning of 
this debate, and we're going to 

344
00:19:51,700 --> 00:19:54,800
see where it takes us. 
I will say, we do not operate 

345
00:19:54,800 --> 00:19:59,300
with the assumption that Block 
Chain networks, that run in 

346
00:19:59,300 --> 00:20:02,900
Azure run entirely in Azure. 
I think that that would just be 

347
00:20:02,900 --> 00:20:05,600
silly, we would not be meeting 
customers where they live the 

348
00:20:05,600 --> 00:20:08,300
nature of blockchain is at least
in the enterprise. 

349
00:20:08,600 --> 00:20:11,400
We think it's at its best when 
it's used to cross 

350
00:20:11,400 --> 00:20:14,500
organizational boundaries where 
there isn't Universal Trust. 

351
00:20:15,000 --> 00:20:18,100
And that means that consortiums 
are going to form and those 

352
00:20:18,100 --> 00:20:21,900
consortiums will undoubtedly 
include participants who choose 

353
00:20:21,900 --> 00:20:25,000
to use a variety of different 
Cloud providers or run things on

354
00:20:25,000 --> 00:20:27,200
premises. 
And so, our sort of beginning 

355
00:20:27,200 --> 00:20:30,000
assumption on anything that we 
do in blockchain is we need to 

356
00:20:30,000 --> 00:20:32,700
make consortiums work really 
well with Azure, which means 

357
00:20:33,100 --> 00:20:35,900
accommodating infrastructure 
that runs elsewhere. 

358
00:20:36,900 --> 00:20:39,200
So right off the bat, I would 
assume it's not a world where 

359
00:20:39,200 --> 00:20:43,200
everything is centralized on 
Azure at the very least, you 

360
00:20:43,200 --> 00:20:45,200
know, one option. 
Of course that we make Available

361
00:20:45,200 --> 00:20:48,600
is if people like the facilities
that we provide to make it easy 

362
00:20:48,600 --> 00:20:52,200
to run blockchain on Azure, they
can run that same set of things 

363
00:20:52,200 --> 00:20:55,700
on Azure stack, which is our 
on-premises. 

364
00:20:55,800 --> 00:20:59,100
Appliance that combines Hardware
plus software to give the same 

365
00:20:59,100 --> 00:21:02,200
sort of azure deployment model 
that we have in the cloud, but 

366
00:21:02,200 --> 00:21:03,700
lets you do it in your own data 
center. 

367
00:21:03,700 --> 00:21:06,100
Under your own control with your
own network connection, or what 

368
00:21:06,100 --> 00:21:07,700
have you. 
And so, we have customers who 

369
00:21:07,700 --> 00:21:11,500
were putting these things on 
cruise ships in mines, on the 

370
00:21:11,500 --> 00:21:14,800
factory floor in regions of the 
world where we don't don't 

371
00:21:14,800 --> 00:21:19,100
currently have a hyperscale 
cloud presence and so they're 

372
00:21:19,100 --> 00:21:21,400
solving lots of different 
problems with Azure stack. 

373
00:21:21,500 --> 00:21:24,200
And and certainly blockchain is 
one workload that we think is 

374
00:21:24,200 --> 00:21:26,400
important to support in that 
configuration as well. 

375
00:21:27,200 --> 00:21:33,300
Then I think the next question 
is What are the assumptions of 

376
00:21:33,300 --> 00:21:36,700
the of the workload that's 
running on top of blockchain? 

377
00:21:37,800 --> 00:21:40,500
There are public networks and 
those public networks are 

378
00:21:40,500 --> 00:21:44,000
expressly designed to be fully 
decentralized and I cannot take 

379
00:21:44,000 --> 00:21:47,300
any dependency on any sort of 
centralized Authority and, you 

380
00:21:47,308 --> 00:21:49,800
know, public clouds might be 
useful for devtest. 

381
00:21:49,800 --> 00:21:51,800
They might be useful for running
certain utilities that the 

382
00:21:51,800 --> 00:21:55,900
public networks consumed and we 
may be able to do lots of work 

383
00:21:55,900 --> 00:21:58,500
to make the development 
experience easier for public 

384
00:21:58,500 --> 00:22:01,000
networks, but I think that those
will continue to be 

385
00:22:01,100 --> 00:22:02,600
decentralized in the way that 
they are today. 

386
00:22:02,600 --> 00:22:06,200
Enterprises however, operate in 
a different world. 

387
00:22:06,200 --> 00:22:09,900
They're not typically operating 
in a market where they're 

388
00:22:09,900 --> 00:22:14,100
performing, Anonymous, 
transactions between arbitrary 

389
00:22:14,100 --> 00:22:15,800
counterparties. 
Usually they're operating in 

390
00:22:15,800 --> 00:22:18,400
markets where they have a name, 
they have an address, they have 

391
00:22:18,408 --> 00:22:21,600
a business license, the subject 
to law enforcement, they're 

392
00:22:21,600 --> 00:22:26,600
subject to the jurisdiction of 
1/4, another and today, you 

393
00:22:26,600 --> 00:22:30,300
know, that all of these non 
technical controls govern the 

394
00:22:30,300 --> 00:22:33,800
way that that Prices behave and 
I believe that that will be true

395
00:22:33,800 --> 00:22:36,300
for the foreseeable future. 
So the assumptions for 

396
00:22:36,300 --> 00:22:39,200
Enterprises going in a little 
bit different they may not be 

397
00:22:39,200 --> 00:22:44,100
looking for the same set of 
decentralization guarantees that

398
00:22:44,100 --> 00:22:45,500
people seek on the public 
networks. 

399
00:22:47,200 --> 00:22:49,800
Now, by the way, it doesn't mean
that enterprises don't worry 

400
00:22:49,800 --> 00:22:52,900
about their Cloud providers. 
They certainly do and one of the

401
00:22:52,900 --> 00:22:56,000
reasons that we have invested, 
so heavily in Azure is 

402
00:22:56,000 --> 00:23:00,300
compliance posture getting 
dozens and dozens of 

403
00:23:00,300 --> 00:23:03,000
certification. 
Ins is because we want any 

404
00:23:03,000 --> 00:23:06,600
customer in any industry, in any
geography, to be able to use our

405
00:23:06,600 --> 00:23:10,100
cloud and certainly compliance 
as a part of that, but it's more

406
00:23:10,100 --> 00:23:11,700
than compliance. 
It's also the terms of service 

407
00:23:11,700 --> 00:23:15,300
and the way that we conduct 
ourselves and so certainly 

408
00:23:15,300 --> 00:23:17,600
people have been following the 
Microsoft Ireland case where we 

409
00:23:17,600 --> 00:23:21,200
successfully fought to avoid 
serving a warrant for data that 

410
00:23:21,200 --> 00:23:25,600
was held internationally based 
on a court order in the u.s. we 

411
00:23:25,600 --> 00:23:27,200
said that we wanted that to be 
served by. 

412
00:23:27,200 --> 00:23:29,700
We wanted to be served with a 
warrant in the jurisdiction 

413
00:23:29,700 --> 00:23:31,100
where the data was held and we 
went all the way. 

414
00:23:31,200 --> 00:23:33,700
The Supreme Court with that. 
And so, we are very serious 

415
00:23:33,800 --> 00:23:37,900
about running our cloud in a way
that enables our customers to 

416
00:23:37,900 --> 00:23:40,200
trust us, both individuals and 
Enterprises. 

417
00:23:42,000 --> 00:23:46,400
I guess the, the last thing that
I would say is we think that 

418
00:23:46,400 --> 00:23:50,300
trusted execution environments 
are an exciting development in 

419
00:23:50,300 --> 00:23:54,400
the history of cloud and we 
think that the the the point at 

420
00:23:54,400 --> 00:23:59,700
which Tes become widespread, it 
will be a watershed moment. 

421
00:23:59,700 --> 00:24:02,000
If we look back in history, 
Cloud computing. 

422
00:24:02,100 --> 00:24:07,300
Because For the First Time 
customers will be able to Put 

423
00:24:07,300 --> 00:24:10,300
their data in the cloud, put 
their compute in the cloud but 

424
00:24:10,300 --> 00:24:14,200
not have to assume that the 
cloud provider is going to 

425
00:24:16,100 --> 00:24:18,400
behave in a certain way. 
They'll be able to leverage 

426
00:24:18,400 --> 00:24:21,000
their trust in The Trusted 
execution environment to get the

427
00:24:21,008 --> 00:24:24,600
results that they want. 
You know if you think about this

428
00:24:24,600 --> 00:24:28,600
just imagine that you had some 
health data of yours and let's 

429
00:24:28,600 --> 00:24:31,800
suppose that there was a 
cloud-based service that you 

430
00:24:31,800 --> 00:24:34,800
wanted to run that would enable 
you and others to provide your 

431
00:24:34,800 --> 00:24:38,700
personal Health Data run. 
Algorithm on that data and then 

432
00:24:38,700 --> 00:24:40,100
give you back a result that 
would tell you. 

433
00:24:40,100 --> 00:24:47,400
If you are at risk of acquiring 
a certain disease, well, you 

434
00:24:47,400 --> 00:24:52,500
could encrypt your data to a key
that is available inside of a 

435
00:24:52,508 --> 00:24:55,000
trusted execution, environment. 
In the cloud, you could upload 

436
00:24:55,000 --> 00:24:57,600
your ciphertext. 
The cloud could take that and 

437
00:24:57,600 --> 00:25:00,100
process it inside of the trusted
execution environment, where I 

438
00:25:00,108 --> 00:25:02,400
thought say the hardware 
boundary prevents the cloud 

439
00:25:02,400 --> 00:25:05,600
operator from seeing that data 
in the clear and then the te 

440
00:25:05,600 --> 00:25:06,800
could take the result and write 
it. 

441
00:25:06,900 --> 00:25:10,200
Back out in ciphertext and you 
could take that and then you 

442
00:25:10,200 --> 00:25:12,700
could decrypt it, you know, on 
your own device and see what the

443
00:25:12,700 --> 00:25:15,400
result is. 
And at no point in time was the 

444
00:25:15,408 --> 00:25:18,900
data ever in the clear for the 
cloud provider to see. 

445
00:25:19,200 --> 00:25:22,000
And so we think from a 
confidentiality and integrity 

446
00:25:22,000 --> 00:25:25,600
standpoint trust execution, 
environments, enable us to sort 

447
00:25:25,600 --> 00:25:28,600
of cross a boundary that we've 
never been able to cross before.

448
00:25:28,800 --> 00:25:31,700
Of course, you still do rely on 
the cloud for availability, for 

449
00:25:31,700 --> 00:25:34,500
performance for durability of 
the data in that scenario. 

450
00:25:34,800 --> 00:25:36,800
But maybe those are 
characteristics. 

451
00:25:36,900 --> 00:25:41,900
Six that enterprises are willing
to trust Microsoft to provide in

452
00:25:41,900 --> 00:25:46,600
return for the elasticity, the 
agility, the set of services 

453
00:25:46,600 --> 00:25:50,400
that are made available you know
and dozens of regions around the

454
00:25:50,400 --> 00:25:53,300
world at hyperscale. 
And so we think that that 

455
00:25:53,300 --> 00:25:57,300
trade-off is fundamentally 
attractive to people in 

456
00:25:57,300 --> 00:26:00,700
Enterprises decision-makers in 
Enterprises and so that's why we

457
00:26:00,700 --> 00:26:03,500
think the blockchain has a role 
in azure. 

458
00:26:05,500 --> 00:26:09,200
Well, let's let's get right into
it, then the cocoa framework. 

459
00:26:10,400 --> 00:26:13,700
So what is the cocoa framework? 
And can you perhaps describe 

460
00:26:14,400 --> 00:26:19,300
that that stack of Technologies 
or, or the architecture of cocoa

461
00:26:19,300 --> 00:26:23,800
framework? 
Sure Enterprises. 

462
00:26:23,800 --> 00:26:29,700
Everywhere are curious to see 
how blockchain can be used to 

463
00:26:29,708 --> 00:26:32,200
transform their markets and 
their business. 

464
00:26:32,700 --> 00:26:37,100
And as we talked with them, One 
of the very first concerns that 

465
00:26:37,100 --> 00:26:39,900
they raised is that they're used
to a set of non functional 

466
00:26:39,900 --> 00:26:42,300
requirements that are standard 
across their entire. 

467
00:26:42,300 --> 00:26:45,700
It portfolio, they expect 
certain levels of scalability, 

468
00:26:46,100 --> 00:26:49,300
low-latency, they expect 
confidentiality of the data that

469
00:26:49,300 --> 00:26:52,000
they put into those systems and 
they expect to be able to govern

470
00:26:52,000 --> 00:26:55,200
and manage those systems. 
And those four basic assumptions

471
00:26:55,200 --> 00:26:57,400
are Enterprise non-functional 
requirements that are really 

472
00:26:57,400 --> 00:27:00,700
non-negotiable. 
And if we look at any Enterprise

473
00:27:00,700 --> 00:27:04,800
product that we produce, those 
are key shift criteria for us. 

474
00:27:06,100 --> 00:27:08,100
And operational criteria over 
time. 

475
00:27:09,900 --> 00:27:13,800
The challenge with blockchain is
that it was developed as 

476
00:27:13,800 --> 00:27:16,800
technology to run in a public 
network across heterogeneous 

477
00:27:16,800 --> 00:27:21,000
machines. 
And with with a threat model, 

478
00:27:21,000 --> 00:27:24,400
that assumed that any individual
party in the network could be 

479
00:27:24,400 --> 00:27:28,600
malicious and that threat model 
is a Byzantine threat model. 

480
00:27:28,600 --> 00:27:31,300
In other words, it assumes that 
any of the counterparties can 

481
00:27:31,300 --> 00:27:33,700
replace the code running on 
their node with arbitrary 

482
00:27:33,700 --> 00:27:34,800
malicious code of their 
choosing. 

483
00:27:35,000 --> 00:27:40,100
Saying they could try to cause 
the system to fail in any sort 

484
00:27:40,100 --> 00:27:42,000
of way, including through 
security failures. 

485
00:27:42,700 --> 00:27:47,300
And so the protocols that 
blockchain needed to use in 

486
00:27:47,300 --> 00:27:51,800
order to operate in this hostile
threat environment, we're 

487
00:27:52,400 --> 00:27:57,200
resource-intensive protocols 
that also at least to date have 

488
00:27:57,200 --> 00:28:00,800
required the vast majority of 
the data in the blockchain to be

489
00:28:00,800 --> 00:28:05,900
stored in the clear for all 
participants to see The 

490
00:28:05,900 --> 00:28:09,100
governance model is also very 
basic it is it basically comes 

491
00:28:09,100 --> 00:28:12,900
down to the decision of what 
code is Ron on each of the 

492
00:28:12,900 --> 00:28:14,700
mining nodes in these public 
networks. 

493
00:28:14,900 --> 00:28:17,000
And when we talked with 
Enterprises they feel that the 

494
00:28:17,000 --> 00:28:20,300
scalability latency 
confidentiality and governance 

495
00:28:20,300 --> 00:28:23,000
trade-offs that they make with 
blockchain, are often times too 

496
00:28:23,000 --> 00:28:25,400
great for them to consider it 
for any kind of real production 

497
00:28:25,400 --> 00:28:30,200
use and we heard that feedback 
enough from customers and also 

498
00:28:30,200 --> 00:28:32,700
internally from experts within 
Microsoft have been working on 

499
00:28:32,700 --> 00:28:36,000
Enterprise Computing for, you 
know, 20 Thirty years. 

500
00:28:36,000 --> 00:28:38,900
In some cases that we felt there
was something that ought to be 

501
00:28:38,900 --> 00:28:41,900
done about that and that and we 
felt that none of the solutions 

502
00:28:41,900 --> 00:28:42,900
that were out there in the 
market. 

503
00:28:42,900 --> 00:28:47,400
Really hit the Enterprise design
point and squarely and in a 

504
00:28:47,408 --> 00:28:50,600
head-on way and so we started 
working on the Coca framework 

505
00:28:50,600 --> 00:28:53,100
and it was an idea that came 
jointly sort of out of some 

506
00:28:53,500 --> 00:28:56,600
thinking for Mark russinovich, 
who's the Azure CTO and 

507
00:28:56,600 --> 00:28:59,000
Microsoft research, where we 
have a number of people looking 

508
00:28:59,000 --> 00:29:03,400
at blockchain broadly and and 
the basic idea of the Coca 

509
00:29:03,400 --> 00:29:05,300
framework is first of all, it's 
not. 

510
00:29:05,500 --> 00:29:07,800
Roger, if you want to run a 
ledger, you need to use a 

511
00:29:07,800 --> 00:29:10,500
ledger. 
Coco is a framework that enables

512
00:29:10,500 --> 00:29:13,400
many or any ledger to integrate 
on top of it. 

513
00:29:13,700 --> 00:29:17,200
And Coco takes on the job of 
forming a secure high 

514
00:29:17,200 --> 00:29:19,900
performance High. 
Throughput Network that 

515
00:29:19,900 --> 00:29:23,900
implements late basic layer of 
governance, and then enables The

516
00:29:23,900 --> 00:29:27,600
Ledger to bring its Ledger model
to bear, with whatever 

517
00:29:27,600 --> 00:29:29,600
abstractions, The Ledger might 
like to use. 

518
00:29:30,800 --> 00:29:34,200
And it brings the set of 
Enterprise capabilities to that 

519
00:29:34,200 --> 00:29:37,500
ledger. 
Scalability that can handle 

520
00:29:37,500 --> 00:29:41,100
thousands of transactions, per 
second latency where we can 

521
00:29:41,100 --> 00:29:44,000
process transactions in Ms. 
Whether the rather than waiting 

522
00:29:44,000 --> 00:29:48,400
seconds, or minutes arbitrary 
confidentiality models for 

523
00:29:48,400 --> 00:29:52,800
fine-grained role-based access 
to data and governance that 

524
00:29:52,800 --> 00:29:56,400
enables a Consortium of 
Enterprises to decide what rules

525
00:29:56,400 --> 00:29:57,900
they're going to follow and 
who's going to get to 

526
00:29:57,900 --> 00:30:02,700
participate in a structured way.
And so Coco seeks to be this 

527
00:30:04,300 --> 00:30:08,800
ubiquitous Network fabric for 
multiple different flavors of 

528
00:30:08,800 --> 00:30:12,000
Enterprise blockchains built by 
a variety of different Ledger's,

529
00:30:12,000 --> 00:30:17,000
across industry verticals and 
and our hope and intent is that 

530
00:30:17,000 --> 00:30:20,300
cocoa will enable Enterprises to
consume blockchain without 

531
00:30:20,300 --> 00:30:22,700
having to compromise on any of 
their basic non-functional 

532
00:30:22,700 --> 00:30:26,500
requirements. 
Okay, so if I'll try this time, 

533
00:30:26,500 --> 00:30:30,900
just stayed the same thing in my
own words. 

534
00:30:31,300 --> 00:30:35,900
So like with any block chains, 
With any blocks and again as 

535
00:30:36,000 --> 00:30:39,400
with any public blockchain 
there's only like three or four 

536
00:30:39,400 --> 00:30:41,200
leg four main components to it, 
right? 

537
00:30:41,200 --> 00:30:44,100
So the first is like this 
networking layer. 

538
00:30:44,400 --> 00:30:48,400
So there is this generally, this
gossip Network, share notes, 

539
00:30:48,400 --> 00:30:52,200
like communicating all of these 
messages, then there is the 

540
00:30:52,200 --> 00:30:57,000
consensus layer or consensus 
piece, which is like, once you 

541
00:30:57,000 --> 00:30:59,200
have these notes and they are 
communicating with each other, 

542
00:30:59,200 --> 00:31:05,400
how they arrive at consensus on?
On like, changes to whatever 

543
00:31:05,400 --> 00:31:08,700
data set their tracking. 
And then the third thing is like

544
00:31:08,700 --> 00:31:13,000
a transaction layer, which is 
like, what do the transactions 

545
00:31:13,000 --> 00:31:15,200
enable the users to do? 
So there's some kind of 

546
00:31:15,200 --> 00:31:18,600
transaction logic to it and the 
fourth might be like a 

547
00:31:18,600 --> 00:31:20,800
governance layer. 
So how do you handle change 

548
00:31:21,000 --> 00:31:26,000
upgrades to the to the network 
to the network consensus or 

549
00:31:26,000 --> 00:31:30,800
transaction logic? 
So, the way like I see Coco is a

550
00:31:30,800 --> 00:31:35,600
cocoa is trying to build just 
the the networking governance 

551
00:31:35,900 --> 00:31:39,300
and consensus systems. 
And on top of it, anyone can 

552
00:31:39,300 --> 00:31:44,000
plug in their own transaction 
types or on Ledger types. 

553
00:31:45,100 --> 00:31:46,200
Yeah. 
It's a good question. 

554
00:31:46,200 --> 00:31:49,500
Coco, certainly seeking to solve
that networking layer problem. 

555
00:31:50,300 --> 00:31:54,600
It also will come out of the box
with a variety of consensus 

556
00:31:54,600 --> 00:31:57,800
options and so we can handle 
consensus for a ledger if the 

557
00:31:57,808 --> 00:32:05,000
Ledger wants to to delegate that
it does not Concern itself with 

558
00:32:05,000 --> 00:32:08,900
the content of transactions per 
se, that's the ledgers job but 

559
00:32:08,900 --> 00:32:11,300
it also does have something to 
say about governance. 

560
00:32:11,300 --> 00:32:14,400
Although I don't expect, the 
cocoa will ultimately be the 

561
00:32:14,400 --> 00:32:16,900
sole answer to governance and 
Consortium that works. 

562
00:32:17,200 --> 00:32:19,900
I think Coco will be responsible
to be responsible for some 

563
00:32:19,900 --> 00:32:23,900
low-level governance about the 
basic substrate of that 

564
00:32:23,900 --> 00:32:26,900
Consortium and then higher 
application Level governance 

565
00:32:26,900 --> 00:32:30,000
also needs to apply. 
Just as a very simple example, 

566
00:32:30,000 --> 00:32:32,000
suppose we're talking about a 
blockchain that Implement smart 

567
00:32:32,000 --> 00:32:34,500
contracts. 
Coco doesn't say anything about 

568
00:32:34,500 --> 00:32:36,900
which smart contracts. 
The Consortium members are going

569
00:32:36,900 --> 00:32:39,500
to use for their business 
processes but it does say 

570
00:32:39,500 --> 00:32:43,800
something about what Ledger code
versions, those Enterprises are 

571
00:32:43,800 --> 00:32:46,800
going to run and who's going to 
get to participate. 

572
00:32:48,900 --> 00:32:51,900
This episode is brought to you 
by shape-shift the world's 

573
00:32:51,900 --> 00:32:54,800
leading trustless digital assets
change quickly. 

574
00:32:54,800 --> 00:32:58,100
Swap between dozens of leading 
cryptic currencies including 

575
00:32:58,100 --> 00:33:01,900
Bitcoin. 
Ether is z cash kenosis, Monaro 

576
00:33:01,900 --> 00:33:06,100
Golem, auger and so many more 
when you go to shape-shift dot 

577
00:33:06,100 --> 00:33:09,100
IO you simply select your 
currency pair, give me your 

578
00:33:09,100 --> 00:33:13,300
receiving, address sent the 
coins and boom shift is not your

579
00:33:13,300 --> 00:33:15,200
traditional crypto currency 
exchange. 

580
00:33:15,200 --> 00:33:17,900
You don't need to create an 
account, you don't need to give 

581
00:33:17,900 --> 00:33:19,400
them your personal. 
Information. 

582
00:33:19,500 --> 00:33:23,200
And they don't hold your coins. 
See you are never at risk from a

583
00:33:23,300 --> 00:33:27,600
hacker, other malicious actor. 
Shape-shift has competitive 

584
00:33:27,600 --> 00:33:30,200
rates and is even integrated in 
some of your favorite wallet 

585
00:33:30,200 --> 00:33:32,800
apps like Jax. 
So you can swap your digital 

586
00:33:32,800 --> 00:33:36,700
assets directly within your 
wallet just as easily as putting

587
00:33:36,700 --> 00:33:38,500
on your slippers. 
Whenever you see that 

588
00:33:38,500 --> 00:33:41,000
good-looking Fox you know that's
where shape-shift is. 

589
00:33:41,400 --> 00:33:44,800
So to get started visit 
shape-shift IO and start trading

590
00:33:45,000 --> 00:33:46,900
and we'd like to thank 
shape-shift for their support of

591
00:33:46,900 --> 00:33:50,200
epicenter today. 
Let's look, how do you expect 

592
00:33:50,200 --> 00:33:53,100
like Enterprises to use the 
cocoa framework? 

593
00:33:53,100 --> 00:33:58,200
So let's assume like Let's 
assume like a group of 

594
00:33:58,200 --> 00:34:02,400
Enterprises morning to build 
like a Consortium blockchain for

595
00:34:02,400 --> 00:34:06,600
a supply chain application. 
So is it the case that they can 

596
00:34:06,600 --> 00:34:10,800
just take the cocoa framework 
like choose a particular flavor 

597
00:34:10,800 --> 00:34:17,100
of off Ledger, right? 
Like like pick pick and you see 

598
00:34:17,100 --> 00:34:20,199
them like Ledger system or 
quarter like Ledger system or 

599
00:34:20,199 --> 00:34:23,800
whatever and then mix and merge 
the two and then deploy your 

600
00:34:23,800 --> 00:34:28,000
application. 
I think supply chain is a great 

601
00:34:28,000 --> 00:34:31,100
example, I would let's just 
start with some of the things 

602
00:34:31,100 --> 00:34:34,800
that a supply chain Consortium. 
I'd like to do, you might like 

603
00:34:34,800 --> 00:34:38,300
to have buyers who are going to 
submit orders for goods and you 

604
00:34:38,308 --> 00:34:40,800
might have suppliers who are 
fulfilling those orders. 

605
00:34:40,800 --> 00:34:42,699
And then there are a variety of 
people who were responsible for 

606
00:34:42,699 --> 00:34:46,300
transportation customs and so 
on. 

607
00:34:46,699 --> 00:34:49,000
And then there's maybe another 
layer of services that are 

608
00:34:49,007 --> 00:34:52,100
provided in a supply chain 
Consortium that that has to do 

609
00:34:52,100 --> 00:34:55,500
with trade Finance, where for 
any one of these, Orders the 

610
00:34:55,500 --> 00:34:58,800
buyers really only going to want
to pay for it once the goods are

611
00:34:58,800 --> 00:35:03,500
received but the suppliers going
to need cash in order to 

612
00:35:03,500 --> 00:35:05,600
manufacture the goods and ship 
them. 

613
00:35:05,900 --> 00:35:09,600
And so there's this Gap and so 
supply chain financiers will 

614
00:35:09,600 --> 00:35:13,200
extend credit to suppliers in 
order to do this and then they 

615
00:35:13,700 --> 00:35:15,900
you know they have to determine 
the terms of that loan. 

616
00:35:15,900 --> 00:35:18,000
What interest rate are they 
going to charge what? 

617
00:35:18,000 --> 00:35:21,500
Contingencies are there in the 
loan and usually they try to get

618
00:35:21,500 --> 00:35:24,800
data on the history of those 
suppliers and also the history. 

619
00:35:25,000 --> 00:35:27,600
The buyers to determine their 
credit worthiness. 

620
00:35:28,100 --> 00:35:32,000
And today a lot of this happens 
on paper fax machines, wet 

621
00:35:32,000 --> 00:35:35,800
signatures phone calls. 
It's extremely tedious and 

622
00:35:35,800 --> 00:35:38,900
there's a tremendous amount of 
friction and much of this data 

623
00:35:38,900 --> 00:35:40,700
is today at least in supply 
chain. 

624
00:35:40,900 --> 00:35:44,400
Shared point-to-point through 
protocols like EDI and it's 

625
00:35:44,400 --> 00:35:47,000
extremely inefficient and 
Troublesome for people to make 

626
00:35:47,000 --> 00:35:50,000
sure that they're in sync. 
So I think that there's a 

627
00:35:50,000 --> 00:35:53,600
compelling value proposition for
a supply chain Consortium to 

628
00:35:53,600 --> 00:35:55,300
adopt a distributed Ledger. 
Ledger. 

629
00:35:55,500 --> 00:35:59,000
But I think one of the first 
problems that you would see and 

630
00:35:59,000 --> 00:36:04,400
and by the way, this use case is
interesting because this is one 

631
00:36:04,400 --> 00:36:07,700
of these things that moves at 
the speed of physical Goods 

632
00:36:08,100 --> 00:36:09,400
here. 
We're not talking about some 

633
00:36:09,400 --> 00:36:12,400
digital bear instrument with 
high frequency trading that's 

634
00:36:12,400 --> 00:36:14,100
not the use case. 
Although there is such a use 

635
00:36:14,100 --> 00:36:15,600
case. 
In this case we're talking about

636
00:36:15,600 --> 00:36:19,100
things that get shipped you 
know, a phone call is probably 

637
00:36:19,100 --> 00:36:23,100
actually faster than the supply 
chain so it moves above the 

638
00:36:23,100 --> 00:36:26,700
speed below the speed of So 
we're not so worried about the 

639
00:36:26,700 --> 00:36:30,500
performance scalability and 
latency aspects here, but I 

640
00:36:30,500 --> 00:36:32,900
think any supply chain, 
Consortium would immediately be 

641
00:36:32,900 --> 00:36:38,900
disturbed by the prospect of 
having the data from buyers 

642
00:36:39,300 --> 00:36:41,400
visible to all buyers and all 
suppliers. 

643
00:36:41,400 --> 00:36:43,300
What goods are they purchasing 
from whom at what? 

644
00:36:43,300 --> 00:36:44,700
Price at? 
What time? 

645
00:36:45,100 --> 00:36:50,100
If if we knew that about our 
competitors when it came to, for

646
00:36:50,100 --> 00:36:52,800
example, the cloud supply chain,
that would be a tremendously 

647
00:36:52,800 --> 00:36:56,900
valuable data point for us. 
And so we keep that that's very 

648
00:36:56,900 --> 00:36:59,900
proprietary information for us 
and we expect our suppliers to 

649
00:36:59,900 --> 00:37:01,500
treat it as proprietary 
information as well. 

650
00:37:01,500 --> 00:37:03,800
And I think as any supply chain 
Consortium would have the same 

651
00:37:03,800 --> 00:37:09,100
concern but think, keep in mind 
you then have these trade 

652
00:37:09,100 --> 00:37:12,200
Finance providers, who are 
trying to extend loans and so 

653
00:37:12,200 --> 00:37:16,100
both buyers and suppliers, have 
an interest in making data 

654
00:37:16,100 --> 00:37:19,000
available about how much 
business they've done. 

655
00:37:19,000 --> 00:37:21,900
Let's say in the past 12 months 
what percentage of the time they

656
00:37:21,900 --> 00:37:27,000
did they deliver on time the 
right set of It's and and by 

657
00:37:27,000 --> 00:37:31,900
sharing that they can get better
terms for trade finance, loans, 

658
00:37:32,200 --> 00:37:35,300
and by getting better terms for 
trade Finance Loans, the the 

659
00:37:35,300 --> 00:37:38,000
cost that the buyer has to pay 
ultimately for the goods goes 

660
00:37:38,000 --> 00:37:40,600
down, and the margin for the 
supplier goes up. 

661
00:37:40,600 --> 00:37:43,400
So everybody has an incentive in
sharing that data. 

662
00:37:44,400 --> 00:37:48,000
They also have an incentive in 
being in sync on exactly where 

663
00:37:48,000 --> 00:37:50,300
the goods are. 
Did they already leave the 

664
00:37:50,300 --> 00:37:51,600
factory? 
Are they on a truck? 

665
00:37:51,600 --> 00:37:54,200
Where is the truck as the truck 
gone through customs of the 

666
00:37:54,200 --> 00:37:57,000
things? 
Ben Tampered with the number 

667
00:37:57,000 --> 00:37:59,700
arrived that were expected was 
at the same set of items that 

668
00:37:59,700 --> 00:38:01,400
were in the lot. 
That was shipped all of these 

669
00:38:01,400 --> 00:38:04,600
things getting in sync on, that 
can be tremendously tedious and 

670
00:38:04,600 --> 00:38:07,500
we know from our own business as
a corporate, Microsoft's own 

671
00:38:07,500 --> 00:38:09,400
business. 
At this can be an extremely 

672
00:38:09,400 --> 00:38:12,100
tedious process and then 
typically know, traditionally 

673
00:38:12,100 --> 00:38:15,900
people would be on the phone 
working with spread, their 

674
00:38:15,900 --> 00:38:18,400
individual copies of 
spreadsheets to try to verify 

675
00:38:18,400 --> 00:38:21,400
all of this stuff. 
So there's absolutely a business

676
00:38:21,400 --> 00:38:24,300
case to remove friction from the
system and tree introduced. 

677
00:38:24,800 --> 00:38:28,200
A new model for trade Finance 
with better financing terms, 

678
00:38:28,200 --> 00:38:31,100
Based on verifiable data that's 
in sync, across all the 

679
00:38:31,100 --> 00:38:34,400
counterparties. 
But I think confidentiality is a

680
00:38:34,400 --> 00:38:36,700
major issue for any supply chain
Consortium. 

681
00:38:36,700 --> 00:38:39,000
I'm not sure that governance is 
quite as important. 

682
00:38:39,000 --> 00:38:42,600
In other words, unlike let's 
say, a banking Consortium a 

683
00:38:42,600 --> 00:38:46,000
supply chain, Consortium might 
not have to worry as much about 

684
00:38:46,000 --> 00:38:48,600
who's permitted to transact with
each other. 

685
00:38:48,600 --> 00:38:52,400
They may not have the same kyc 
requirements, but of course, if 

686
00:38:52,400 --> 00:38:55,800
I'm a company in the US and I'm 
doing Business with a supplier. 

687
00:38:55,800 --> 00:38:59,700
I'd be mortified to learn that 
my supplier was actually a 

688
00:38:59,700 --> 00:39:02,700
sanctioned organization. 
So I might very well want to do 

689
00:39:02,700 --> 00:39:06,900
some basic KY caml checks on the
set of people who are 

690
00:39:06,900 --> 00:39:09,400
participating in the Consortium.
So I do think governance is 

691
00:39:09,400 --> 00:39:11,000
relevant although perhaps not as
relevant. 

692
00:39:11,000 --> 00:39:16,300
So let's just to stay on this 
topic of scalability and 

693
00:39:16,300 --> 00:39:19,500
confidentiality because I think 
that for Enterprise these are 

694
00:39:19,500 --> 00:39:23,100
probably the two most important 
characteristics that they're 

695
00:39:23,100 --> 00:39:26,000
going to be looking for. 
A blockchain. 

696
00:39:27,400 --> 00:39:35,200
And so, can you explain then how
a cocoa framework enabled, 

697
00:39:35,200 --> 00:39:39,800
blockchain Network, so to speak 
achieves, this high level of 

698
00:39:39,800 --> 00:39:41,600
scalability? 
I mean, I saw this Mark 

699
00:39:41,600 --> 00:39:46,000
russinovich demo which will will
link to in the show notes where 

700
00:39:46,000 --> 00:39:49,900
we're running an evm and you 
know there's just like thousands

701
00:39:49,900 --> 00:39:53,500
of transactions per second it's 
just go they the transaction 

702
00:39:53,500 --> 00:39:54,700
odometer just goes off the 
rails. 

703
00:39:54,800 --> 00:39:58,100
Rails. 
And, and so, yeah, let's address

704
00:39:58,100 --> 00:40:01,100
that and also address how we can
achieve transaction 

705
00:40:01,100 --> 00:40:03,600
confidentiality. 
When, you know, everybody knows 

706
00:40:03,600 --> 00:40:06,100
that on the public etherium 
network. 

707
00:40:06,600 --> 00:40:10,400
It's nearly, it's theoretically,
impossible to achieve a 

708
00:40:10,408 --> 00:40:14,100
transaction in the current 
implementation with 3m. 

709
00:40:14,100 --> 00:40:16,700
It's impossible to, to, for the 
transaction, a confidentiality. 

710
00:40:17,900 --> 00:40:20,400
Sure. 
So, so in this, in this 

711
00:40:20,400 --> 00:40:24,200
Consortium example, the way that
we can do this is first of all, 

712
00:40:24,207 --> 00:40:27,700
the Consortium Excel edger. 
And we've announced several that

713
00:40:27,700 --> 00:40:30,700
intend to integrate with cocoa 
and are working with several 

714
00:40:30,700 --> 00:40:33,500
others that were not yet ready 
to announce anything. 

715
00:40:33,900 --> 00:40:37,600
So they pick their Ledger and 
that ledger would incorporate 

716
00:40:37,600 --> 00:40:39,800
the cocoa framework into its 
distribution. 

717
00:40:40,100 --> 00:40:44,800
And what cocoa does is it makes 
changes one very basic 

718
00:40:44,800 --> 00:40:47,400
assumption among the 
blockchains, we do not assume 

719
00:40:47,400 --> 00:40:49,800
that the participants in the 
Consortium, trust each other, 

720
00:40:49,900 --> 00:40:53,400
they can be adversarial, that's 
fine, but we do assume that we 

721
00:40:53,400 --> 00:40:57,500
can create a trusted. 
Network of nodes that represent 

722
00:40:57,500 --> 00:41:00,200
those members of the Consortium 
and the way that we do that is 

723
00:41:00,200 --> 00:41:02,500
by leveraging, The Trusted 
execution environment. 

724
00:41:02,500 --> 00:41:05,600
So we create on each node, 
that's a member of the network, 

725
00:41:05,600 --> 00:41:10,500
an enclave that Enclave is 
running The Ledger code, and 

726
00:41:10,500 --> 00:41:14,700
some cocoa management code, 
those enclaves connect to each 

727
00:41:14,700 --> 00:41:17,300
other, they exchange at the 
stations. 

728
00:41:17,500 --> 00:41:20,100
And now each of those enclaves 
knows what the other one is 

729
00:41:20,100 --> 00:41:23,900
running, and they can verify 
that the party on the other end 

730
00:41:23,900 --> 00:41:26,200
has not replaced. 
The code with the malicious code

731
00:41:26,200 --> 00:41:28,800
of their choice. 
There in fact, running the, the 

732
00:41:28,800 --> 00:41:31,300
expected code that the 
Consortium has decided that 

733
00:41:31,300 --> 00:41:33,400
they're going to run. 
And once you make that 

734
00:41:33,400 --> 00:41:36,700
assumption, again, we're not 
assuming that the members trust 

735
00:41:36,700 --> 00:41:38,800
each other. 
We are assuming that those 

736
00:41:38,800 --> 00:41:41,400
members can't tamper with the 
contents of the enclaves that 

737
00:41:41,400 --> 00:41:44,700
they own and we're assuming that
the enclaves themselves are 

738
00:41:44,700 --> 00:41:47,300
producing valid attestations. 
Once those enclaves form that 

739
00:41:47,300 --> 00:41:51,100
Network we can use much more 
traditional distributed systems 

740
00:41:51,100 --> 00:41:54,000
protocols to achieve things like
consensus and data. 

741
00:41:54,000 --> 00:41:58,000
Replication Ian and those 
traditional distributed systems.

742
00:41:58,000 --> 00:42:00,700
Protocols in addition to just 
being proven over the course of 

743
00:42:00,700 --> 00:42:02,700
dozens of years of operation at 
scale. 

744
00:42:03,200 --> 00:42:06,200
They also provide much better 
characteristics in terms of 

745
00:42:06,200 --> 00:42:09,900
latency and in terms of 
throughput and so we can achieve

746
00:42:09,900 --> 00:42:13,400
scale like you'd expect from a 
database in the case of 

747
00:42:13,400 --> 00:42:16,600
blockchain by using trusted 
execution environments to set up

748
00:42:16,600 --> 00:42:18,300
this particular kind of trust 
relationship. 

749
00:42:18,300 --> 00:42:21,800
Among the nodes confidentiality 
is the other thing that we can 

750
00:42:21,800 --> 00:42:24,200
achieve. 
Again the data in the case of 

751
00:42:24,200 --> 00:42:26,700
these trusts Situation 
environments is only ever in the

752
00:42:26,700 --> 00:42:29,500
clear inside of the trusted 
execution environment. 

753
00:42:29,500 --> 00:42:32,500
Meaning that the local admin 
can't see the contents of all 

754
00:42:32,500 --> 00:42:34,400
the transactions flowing through
the system. 

755
00:42:34,500 --> 00:42:38,000
They have to make a request 
through an API to read data. 

756
00:42:38,400 --> 00:42:44,400
And when they do that, that API 
can choose what data to show to 

757
00:42:44,400 --> 00:42:46,100
each of the individual 
counterparties who are 

758
00:42:46,100 --> 00:42:49,900
participating in the Consortium.
And now, instead of having to 

759
00:42:49,900 --> 00:42:52,800
use very fancy cryptography that
might have a time or space 

760
00:42:52,800 --> 00:42:56,600
trade-off or might require you 
Unique cryptographic knowledge 

761
00:42:56,600 --> 00:42:58,700
on the part of the people 
implementing the system. 

762
00:42:58,800 --> 00:43:01,100
You can have a standard 
Enterprise developer. 

763
00:43:01,300 --> 00:43:06,500
Write some logic that says in my
Consortium or for this order, 

764
00:43:06,500 --> 00:43:09,900
I'm going to make the order 
visible in its entirety to the 

765
00:43:09,900 --> 00:43:12,200
buyer who placed the order and 
to the seller who's been 

766
00:43:12,200 --> 00:43:15,800
selected to fulfill the order. 
And I'm going to surface 

767
00:43:15,800 --> 00:43:19,700
metadata about the order like 
the total value of the order, 

768
00:43:21,200 --> 00:43:24,200
whether it was delivered on 
time, I'm going to surface that 

769
00:43:24,200 --> 00:43:27,500
to any Other who has a role 
that's a trade Finance role. 

770
00:43:27,800 --> 00:43:30,100
Now you've got this very 
fine-grained are back. 

771
00:43:30,200 --> 00:43:34,300
Its standard are back. 
Role-based access control that 

772
00:43:34,300 --> 00:43:36,300
any Enterprise developer would 
use today. 

773
00:43:36,300 --> 00:43:38,800
They set it, you know, an access
control list or they write rules

774
00:43:38,800 --> 00:43:41,300
about who can see what data. 
And then, the code just 

775
00:43:41,300 --> 00:43:43,300
implements those rules. 
And since the code is running 

776
00:43:43,300 --> 00:43:45,300
inside of the trusted execution,
environment, it can't be 

777
00:43:45,300 --> 00:43:47,000
tampered. 
With since the data is only 

778
00:43:47,000 --> 00:43:49,100
unclear inside of the truss 
execution environment, it can't 

779
00:43:49,100 --> 00:43:51,600
be read from the outside. 
And now all of a sudden you've 

780
00:43:51,600 --> 00:43:56,400
got a Consortium that can run. 
Run at the scale of a database 

781
00:43:56,400 --> 00:43:58,700
with the latency of a database 
and have this arbitrary 

782
00:43:58,700 --> 00:44:02,100
fine-grained confidentiality. 
It's really not clear to me how 

783
00:44:02,100 --> 00:44:06,800
that scheme could be implemented
using ZK snarks or homomorphic 

784
00:44:06,800 --> 00:44:09,200
encryption. 
It would be a real challenge to 

785
00:44:09,200 --> 00:44:11,300
come up with this. 
Especially this fine grain 

786
00:44:11,300 --> 00:44:14,000
confidentiality for that supply 
chain, Consortium scenario. 

787
00:44:15,000 --> 00:44:19,500
This is, this is amazing because
back in 2015, so prior to 2015, 

788
00:44:19,500 --> 00:44:22,800
there was no notion of 
Enterprise blockchains at all. 

789
00:44:22,800 --> 00:44:26,100
Like, I think the Enterprise 
block seems like Consortium 

790
00:44:26,100 --> 00:44:27,800
chains, mr. 
In 2015. 

791
00:44:29,000 --> 00:44:32,100
And the biggest problem, they 
faced was the problem of like 

792
00:44:32,300 --> 00:44:35,500
privacy the blockchain model. 
Requiring all of the 

793
00:44:35,500 --> 00:44:39,800
transactions broadcast in order 
to be visible to all of the 

794
00:44:39,900 --> 00:44:45,500
Consortium parties and 
traditionally Dissolution the 

795
00:44:45,508 --> 00:44:48,100
proposed solution to it, has 
always been some form of zero 

796
00:44:48,100 --> 00:44:52,700
knowledge proof, but 
zero-knowledge proves our are 

797
00:44:52,900 --> 00:44:55,300
very limited in what they can 
do. 

798
00:44:56,000 --> 00:44:59,500
So this this almost seems like a
Holy Grail, right? 

799
00:44:59,500 --> 00:45:02,300
Like, you're taking components 
like trusted execution 

800
00:45:02,300 --> 00:45:06,500
environments, which are, which 
are available and then able to 

801
00:45:06,500 --> 00:45:10,000
build a blockchain like 
Consortium chain platform in 

802
00:45:10,000 --> 00:45:14,600
which privacy of data, can be 
guaranteed by only rules roll. 

803
00:45:14,800 --> 00:45:18,600
Role-based access. 
This seems something which is 

804
00:45:18,600 --> 00:45:22,600
like very powerful. 
We think so, we think that 

805
00:45:22,600 --> 00:45:25,600
addresses, the key things that 
our Enterprise customers are 

806
00:45:25,600 --> 00:45:27,500
telling us they want out of 
blockchain. 

807
00:45:27,800 --> 00:45:31,600
And by the way, using cocoa 
doesn't mean that you have to 

808
00:45:31,600 --> 00:45:33,600
give up on all of those other 
techniques. 

809
00:45:34,800 --> 00:45:38,000
One of the ledgers that's 
publicly Express their intent 

810
00:45:38,000 --> 00:45:40,800
integrate. 
Cocoa is Quorum which was built 

811
00:45:40,800 --> 00:45:42,700
by JPMorgan, Chase & is this 
open source? 

812
00:45:42,700 --> 00:45:45,200
Ledger, that sort of a 
modification of a theorem for 

813
00:45:45,200 --> 00:45:48,500
the Enterprise and Quorum 
already uses point to point 

814
00:45:48,500 --> 00:45:50,500
encryption with its 
constellation system. 

815
00:45:50,900 --> 00:45:54,100
To enable private transactions 
among a subset of members of a 

816
00:45:54,107 --> 00:45:58,300
Consortium and Quorum already 
has on its roadmap, the desire 

817
00:45:58,300 --> 00:46:01,900
to incorporate other kinds of 
cryptography. 

818
00:46:01,900 --> 00:46:08,400
Like the the zsl from that 
derives, from these knowledge 

819
00:46:08,400 --> 00:46:12,100
knowledge proofs that derive 
from the public networks and 

820
00:46:13,400 --> 00:46:15,500
they're going to keep those 
systems and those will be 

821
00:46:15,500 --> 00:46:19,900
available to use selectively for
use cases, as a Consortium sees,

822
00:46:19,900 --> 00:46:22,600
fit and cocoa. 
Will be yet another layer that 

823
00:46:22,600 --> 00:46:25,200
enables consortiums to achieve 
what they would like. 

824
00:46:25,200 --> 00:46:28,900
And so this is not meant to be 
sort of a, the one single answer

825
00:46:28,900 --> 00:46:31,300
that's suitable for everything. 
People will use cryptography, 

826
00:46:31,300 --> 00:46:32,600
cryptography, where it makes 
sense. 

827
00:46:32,600 --> 00:46:35,700
They'll use the prosecutor, 
execution, environments, 

828
00:46:35,700 --> 00:46:38,300
wherever it makes sense. 
And so, we think that people are

829
00:46:38,300 --> 00:46:40,400
going to start being able to mix
and match to address their 

830
00:46:40,400 --> 00:46:45,700
business requirements. 
So just to recap just to just to

831
00:46:45,700 --> 00:46:49,700
test my understanding. 
So what Google can allow 

832
00:46:50,000 --> 00:46:53,900
Enterprises to do is like let's 
assume all three of us are 

833
00:46:54,000 --> 00:46:56,100
Enterprises in our supply chain 
example. 

834
00:46:56,300 --> 00:46:59,800
So I don't know. 
I'm I'm like a Shipping Company 

835
00:47:00,300 --> 00:47:09,900
Sebastian official Observer, any
and like Matthew you buy some, 

836
00:47:09,900 --> 00:47:14,400
some some things in bulk and 
Sebastian is a lack of, is a 

837
00:47:14,400 --> 00:47:20,700
financing company, and all of us
are On one like blockchain 

838
00:47:20,700 --> 00:47:23,000
Ledger which is running on the 
cocoa framework. 

839
00:47:23,400 --> 00:47:28,000
So me as me as one of the 
participants I have to assume. 

840
00:47:28,500 --> 00:47:31,500
So what do we need to assume? 
We need to assume that all of us

841
00:47:31,500 --> 00:47:36,300
are willing to Run our nodes on 
these trusted execution 

842
00:47:36,300 --> 00:47:42,100
environments. 
And once we assume that it gives

843
00:47:42,100 --> 00:47:47,400
me the power to input some data 
into into the, into the 

844
00:47:47,400 --> 00:47:51,900
Consortium chain. 
Have all of these nodes running 

845
00:47:51,900 --> 00:47:55,000
tested, injection execution 
environments, come to consensus 

846
00:47:55,000 --> 00:47:59,400
on that data. 
And also allows me to 

847
00:47:59,400 --> 00:48:02,400
selectively only selectively 
reveal, my data to the other 

848
00:48:02,400 --> 00:48:05,800
Consortium participants. 
So I can have a mechanism by 

849
00:48:05,800 --> 00:48:09,800
which I choose to reveal my data
to Sebastian but not to Matthew.

850
00:48:10,900 --> 00:48:14,800
That's exactly right. 
And by the way, it can be even 

851
00:48:14,800 --> 00:48:17,700
finer grains than revealing my 
data to Sebastian or not to 

852
00:48:17,700 --> 00:48:18,900
Matthew. 
It could be, I'm going to 

853
00:48:18,900 --> 00:48:24,400
reveal, you know, the date of 
the order to Matthew and the 

854
00:48:24,400 --> 00:48:26,400
quantity of the order and the 
date of the order. 

855
00:48:26,800 --> 00:48:31,400
Bastion and you could come up 
with, as fine-grained, a model 

856
00:48:31,400 --> 00:48:34,600
as you like. 
And one of the components of the

857
00:48:34,600 --> 00:48:41,600
demo in the video that we show 
is, is this application visits 

858
00:48:41,600 --> 00:48:44,600
application that's built by a 
company called Mo Jack's. 

859
00:48:44,900 --> 00:48:47,500
That that is a supply chain 
blockchain based Supply, Chain 

860
00:48:47,600 --> 00:48:51,600
management application, and in 
order to build that application 

861
00:48:51,600 --> 00:48:54,500
on top of. 
So what we did in the demo is we

862
00:48:54,500 --> 00:49:00,600
took the C++ the theory IAM code
base and we re platformed it to 

863
00:49:00,600 --> 00:49:03,100
run on top of cocoa. 
But it still has the very same 

864
00:49:03,100 --> 00:49:06,100
set of interfaces externally 
that it had originally and it 

865
00:49:06,100 --> 00:49:08,400
has the same execution model 
inside of the UVM for 

866
00:49:08,400 --> 00:49:10,700
transactions. 
And so all that Magics had to 

867
00:49:10,700 --> 00:49:14,300
do. 
First of all, they removed all 

868
00:49:14,300 --> 00:49:17,700
public data from their smart 
contract definition. 

869
00:49:17,700 --> 00:49:21,100
So you can't read the data 
directly and then they 

870
00:49:21,100 --> 00:49:24,800
implemented Access Control logic
in each of their smart contracts

871
00:49:24,800 --> 00:49:28,500
where you could read data that 
just checked the This whoever 

872
00:49:28,500 --> 00:49:31,100
submitted the transaction 
against an access control list 

873
00:49:31,100 --> 00:49:33,800
to see who's allowed to see the 
data and that enabled them to 

874
00:49:33,800 --> 00:49:36,200
achieve this fine grained 
confidentiality. 

875
00:49:36,200 --> 00:49:39,100
It's all done in the idiom of 
The Ledger cocoa. 

876
00:49:39,100 --> 00:49:41,900
Underneath provides kind of the 
core capability to make it work.

877
00:49:42,400 --> 00:49:45,300
But it ends up being very 
flexible and they really, we 

878
00:49:45,300 --> 00:49:48,200
also, we had to disable a couple
of apis. 

879
00:49:48,200 --> 00:49:51,500
Those apis that enable raw read 
access to the transactional, 

880
00:49:51,500 --> 00:49:56,300
history, or raw read access to 
Enterprise, or to Smart contract

881
00:49:56,300 --> 00:50:00,200
state Eight, those had to be 
disabled in order to prevent 

882
00:50:00,200 --> 00:50:02,700
people from circumventing, the 
logic inside of the smart 

883
00:50:02,700 --> 00:50:04,800
contracts, but it was a very 
simple change. 

884
00:50:04,800 --> 00:50:08,300
It's not as though we had to 
break things in a major way, so 

885
00:50:08,300 --> 00:50:11,300
they basically just had to pipe 
their reads through the smart 

886
00:50:11,300 --> 00:50:14,100
contract methods and then all of
that access control logic 

887
00:50:14,100 --> 00:50:19,200
applies. 
Just just, just a question on 

888
00:50:19,300 --> 00:50:21,300
what happens when something goes
wrong. 

889
00:50:21,700 --> 00:50:26,800
And for example, you have Smart 
contract and it turns out that 

890
00:50:27,100 --> 00:50:29,700
let's assume that smart contract
is also handling Financial 

891
00:50:29,700 --> 00:50:31,900
value. 
And now there's a bug in the 

892
00:50:31,900 --> 00:50:36,000
contract and because of that 
bug, that smart contract is 

893
00:50:36,000 --> 00:50:39,500
leaking value to some people who
shouldn't have access to it. 

894
00:50:40,100 --> 00:50:43,300
Now, somebody needs to fix that 
contract. 

895
00:50:43,600 --> 00:50:48,400
So do they get like, So whoever 
is trying to fix it. 

896
00:50:48,400 --> 00:50:51,700
Do they get like access to all 
of the data handled by the smart

897
00:50:51,700 --> 00:50:54,000
contract? 
Yeah, this is a great question 

898
00:50:55,900 --> 00:50:57,900
and and let me sort of work my 
way into it. 

899
00:50:58,100 --> 00:51:02,400
First of all before before 
anyone uses Coco, they need to 

900
00:51:02,400 --> 00:51:05,100
do a threat model, they need to 
look at the particular business.

901
00:51:05,100 --> 00:51:08,700
They want to run in their 
Consortium and decide what, 

902
00:51:08,700 --> 00:51:12,900
trusted execution environments 
might be suitable for handling 

903
00:51:12,900 --> 00:51:15,000
that data, because different 
teas have different 

904
00:51:15,000 --> 00:51:17,200
characteristics. 
And so that's sort of Up one and

905
00:51:17,200 --> 00:51:19,700
I imagine there will be some 
workloads that are not suitable 

906
00:51:19,700 --> 00:51:26,500
for cocoa and that's fine. 
The next thing is we assume 

907
00:51:26,500 --> 00:51:29,800
breach and Azure. 
We assume breach at Microsoft, 

908
00:51:29,800 --> 00:51:31,900
we assume breach, we just assume
breach and we've got to make 

909
00:51:31,900 --> 00:51:34,200
sure that things work the way. 
The customers should expect, 

910
00:51:34,200 --> 00:51:39,000
even when breach occurs. 
And so, that means we have to 

911
00:51:39,000 --> 00:51:42,600
assume that a te can be 
compromised at a even and and 

912
00:51:42,600 --> 00:51:46,200
that's a much worse failure than
a smart contract. 

913
00:51:46,200 --> 00:51:50,900
Having it Fact because te 
compromise would expose 

914
00:51:51,100 --> 00:51:54,900
everything and let if we 
approach it in a naive way and 

915
00:51:54,900 --> 00:51:58,900
so are our design seeks to do 
several things. 

916
00:51:58,900 --> 00:52:01,600
First of all, minimize the 
possibility that a breach 

917
00:52:01,600 --> 00:52:04,500
occurs, second of all, make it 
easy to detect. 

918
00:52:04,500 --> 00:52:07,700
If a breach occurs and third of 
all minimize the blast radius, 

919
00:52:07,700 --> 00:52:11,500
when a breach occurs and so that
and make it possible for people 

920
00:52:11,500 --> 00:52:16,500
to recover. 
So, the first thing is, we're 

921
00:52:16,500 --> 00:52:17,700
sort. 
Art of working with Microsoft 

922
00:52:17,700 --> 00:52:25,600
research on a variety of 
techniques to avoid bad code 

923
00:52:25,600 --> 00:52:27,900
failures inside of trusted, 
execution, environments. 

924
00:52:27,900 --> 00:52:30,400
And so Microsoft research has 
published some papers on this 

925
00:52:30,400 --> 00:52:34,200
that there are compiler 
techniques static and dynamic 

926
00:52:34,200 --> 00:52:37,500
analysis that can prevent data 
from leaking outside of a t, 

927
00:52:37,800 --> 00:52:39,700
even if there's a compromise 
inside of the T. 

928
00:52:39,700 --> 00:52:42,000
So there are some classes of 
bugs that we can just eliminate 

929
00:52:42,000 --> 00:52:45,300
up front. 
The next thing is, I worry about

930
00:52:45,300 --> 00:52:48,800
the size of the trust. 
Computing base inside of the tea

931
00:52:49,100 --> 00:52:52,700
inside of the enclave. 
And so in our design we will we 

932
00:52:52,700 --> 00:52:55,400
will end up with a model where 
we have actually multiple 

933
00:52:55,400 --> 00:52:58,000
different enclaves running. 
At the same time on each node, 

934
00:52:58,100 --> 00:53:03,300
there's an enclave that runs the
cocoa management software which 

935
00:53:03,300 --> 00:53:07,400
is a relatively small code base.
It's carefully audited, and it's

936
00:53:07,400 --> 00:53:10,500
consistent across all 
Integrations with cocoa. 

937
00:53:10,700 --> 00:53:13,300
And then there's another Enclave
that runs The Ledger codebase, 

938
00:53:13,500 --> 00:53:16,100
and that could gaze could be 
potentially larger that will 

939
00:53:16,100 --> 00:53:16,900
vary by. 
Ledger. 

940
00:53:16,900 --> 00:53:19,300
It might be a varying quality 
depending on which Ledger you're

941
00:53:19,300 --> 00:53:21,500
talking about. 
And so we've now reduced attack 

942
00:53:21,500 --> 00:53:23,900
surface because all of the key 
material, for example can be 

943
00:53:23,900 --> 00:53:27,100
stored inside of the smaller 
more trusted Computing base. 

944
00:53:27,300 --> 00:53:31,200
And only data is encode related 
to The Ledger stored in the 

945
00:53:31,200 --> 00:53:33,800
other one. 
The next thing we did is we 

946
00:53:33,800 --> 00:53:37,700
designed a threshold encryption 
scheme and the idea here is if 

947
00:53:37,700 --> 00:53:42,300
somebody were to be able to 
compromise an individual node, 

948
00:53:42,500 --> 00:53:45,400
we wouldn't want them to be able
to decrypt, the entire Ledger, 

949
00:53:45,400 --> 00:53:49,500
and then run off with it. 
And so there, this threshold 

950
00:53:49,500 --> 00:53:55,600
encryption lets you generate a 
group of public key and that 

951
00:53:55,600 --> 00:53:58,000
group public key, lets any of 
the nodes encrypt data 

952
00:53:58,000 --> 00:54:01,700
efficiently. 
And then, in order to decrypt, 

953
00:54:02,400 --> 00:54:06,500
you need a quorum of nodes. 
So to each perform a partial 

954
00:54:06,500 --> 00:54:11,400
description and those decryption
shares can be combined to reveal

955
00:54:11,400 --> 00:54:14,200
the plain text. 
And what that means is if you've

956
00:54:14,200 --> 00:54:19,000
got one counterparty who saw Um,
how compromises it to you and 

957
00:54:19,000 --> 00:54:21,400
they want to decrypt, the entire
Ledger, they need the 

958
00:54:21,400 --> 00:54:25,500
cooperation of a quorum of other
counterparties in order to 

959
00:54:25,500 --> 00:54:28,300
actually get to the data and so 
that enables those 

960
00:54:28,300 --> 00:54:30,900
counterparties to have policies,
like, rate limiting, the number 

961
00:54:30,900 --> 00:54:33,600
of descriptions that anyone can 
do, and if that rate limit is 

962
00:54:33,600 --> 00:54:39,000
succeeded, they can alert and it
was very important to us. 

963
00:54:39,000 --> 00:54:43,500
By the way that we did enable 
sort of offline decryption by a 

964
00:54:43,500 --> 00:54:46,500
quorum because there's a 
disaster recovery scenario where

965
00:54:46,500 --> 00:54:49,300
you No longer have the t's that 
were storing, the keys that were

966
00:54:49,308 --> 00:54:51,600
being used and you need all of 
those members to be able to 

967
00:54:51,600 --> 00:54:54,600
conclude this time for 
legitimate purposes to 

968
00:54:54,600 --> 00:54:57,600
rehydrate, The Ledger in new 
infrastructure so that it can 

969
00:54:57,600 --> 00:55:01,100
continue to run. 
And so there's a variety of 

970
00:55:01,100 --> 00:55:04,200
different measures that we took 
to model the possibility that a 

971
00:55:04,207 --> 00:55:07,600
te could be compromised. 
And to be able to detect it, you

972
00:55:07,600 --> 00:55:11,000
can for example have teased 
reattached periodically, you can

973
00:55:11,000 --> 00:55:13,400
roll over the keys that 
individual members are using. 

974
00:55:13,600 --> 00:55:15,700
And so ultimately, we envision 
that all of these 

975
00:55:15,700 --> 00:55:18,300
countermeasures will Be 
controllable by policy. 

976
00:55:20,400 --> 00:55:23,600
There's there's also a question 
when it comes to the consensus 

977
00:55:23,600 --> 00:55:26,400
model that's used in this 
network in blockchain today. 

978
00:55:26,400 --> 00:55:31,100
Of course, with let's say, proof
of work every single node and 

979
00:55:31,100 --> 00:55:33,400
even proof of stake. 
Every single note is going to re

980
00:55:33,400 --> 00:55:37,000
execute all of the transactions 
in a block in order to verify 

981
00:55:37,000 --> 00:55:39,300
that they're valid before 
accepting that block on the 

982
00:55:39,300 --> 00:55:41,900
chain. 
That requires them to be able to

983
00:55:41,900 --> 00:55:44,400
re execute those transactions. 
So the data has to be in the 

984
00:55:44,400 --> 00:55:49,100
clear and you have this It's 
overhead and and this sort of 

985
00:55:49,100 --> 00:55:52,200
energy consumption overhead. 
And so we think that there will 

986
00:55:52,200 --> 00:55:54,600
ultimately be a variety of 
different consensus models, 

987
00:55:54,600 --> 00:55:56,700
available in Cocoa, including 
proof of work. 

988
00:55:56,700 --> 00:55:58,600
By the way, there's no reason 
you couldn't do that if you 

989
00:55:58,607 --> 00:56:01,700
wanted it inside of a cocoa 
deployment. 

990
00:56:01,900 --> 00:56:04,000
But we think that there are some
interesting consensus models 

991
00:56:04,000 --> 00:56:05,800
that could come out where for 
example, you could elect a 

992
00:56:05,808 --> 00:56:08,000
leader. 
And then that leader is the only

993
00:56:08,000 --> 00:56:09,700
one who ever has to execute a 
transaction. 

994
00:56:09,700 --> 00:56:12,300
Once the leader executes, the 
transaction, it takes the 

995
00:56:12,300 --> 00:56:14,600
resulting State changes and 
broadcasts. 

996
00:56:14,600 --> 00:56:16,600
Its all of the other 
participants. 

997
00:56:16,700 --> 00:56:20,900
Isa pants in, in the network and
those participants just blindly 

998
00:56:20,900 --> 00:56:24,100
accept the state changes from 
the leader in commit them. 

999
00:56:24,600 --> 00:56:27,700
And this is a pretty high 
throughput model. 

1000
00:56:27,700 --> 00:56:29,800
It's sort of consistent with 
what you may get in a system 

1001
00:56:29,800 --> 00:56:33,200
like, paxos, where you'd have a 
replica set and you'd want a 

1002
00:56:33,200 --> 00:56:36,600
quorum of replicas to commit the
data before you consider a 

1003
00:56:36,607 --> 00:56:39,100
transaction valid. 
So, that it's durable. 

1004
00:56:40,600 --> 00:56:43,500
But this is a, in this, in the, 
in this model, you're only 

1005
00:56:43,500 --> 00:56:47,400
worrying about crashes, you're 
not worrying about Adversaries 

1006
00:56:47,400 --> 00:56:50,500
with who are running malicious 
code. 

1007
00:56:50,800 --> 00:56:55,300
Now, even in this model, you can
assume that maybe some of the 

1008
00:56:55,300 --> 00:56:58,400
members in the network could 
somehow compromise, its he and 

1009
00:56:58,400 --> 00:57:01,200
become malicious. 
And and so there, you might want

1010
00:57:01,200 --> 00:57:04,200
to have a model where 
asynchronously, let's say you 

1011
00:57:04,200 --> 00:57:06,400
have a set of nodes who are 
responsible for fully 

1012
00:57:06,400 --> 00:57:09,200
validating, every single 
transaction that they see. 

1013
00:57:09,300 --> 00:57:12,200
So we'll leader is still the one
responsible for broadcasting. 

1014
00:57:12,200 --> 00:57:15,100
The state changes, the majority 
of nodes synchronously, except 

1015
00:57:15,100 --> 00:57:17,800
those State changes and move on.
And then asynchronously, you 

1016
00:57:17,800 --> 00:57:20,900
have some other nodes checking 
to make sure that the leader has

1017
00:57:20,900 --> 00:57:23,300
not gone off the reservation and
done the wrong thing. 

1018
00:57:23,500 --> 00:57:26,900
And if of course, if any of the 
nodes does detect a violation, 

1019
00:57:27,400 --> 00:57:30,000
they can alert. 
And you can Rewind The Ledger. 

1020
00:57:30,000 --> 00:57:32,900
Back to the, to the last agreed 
upon State. 

1021
00:57:32,900 --> 00:57:35,200
You perhaps, you kick out the 
bad actor and then you can, and 

1022
00:57:35,207 --> 00:57:37,900
then you continue. 
So, we do assume that there are 

1023
00:57:37,900 --> 00:57:40,500
these problems down at The 
Ledger layer, and we have a 

1024
00:57:40,500 --> 00:57:43,400
variety of defense-in-depth, 
measures to reduce the 

1025
00:57:43,400 --> 00:57:46,600
likelihood of a catastrophic 
failure there, we actually. 

1026
00:57:46,600 --> 00:57:48,900
Really don't do anything to 
address. 

1027
00:57:48,900 --> 00:57:51,700
The failure scenario that you 
described which is a bug in a 

1028
00:57:51,707 --> 00:57:54,800
smart contract. 
That is entirely an application 

1029
00:57:54,800 --> 00:57:58,400
Level concern and the cocoa 
framework in and of itself 

1030
00:57:58,700 --> 00:58:01,800
doesn't really know or care 
about that. 

1031
00:58:01,800 --> 00:58:04,200
And so that would be a problem 
that the participants would have

1032
00:58:04,200 --> 00:58:06,600
to sort out amongst themselves. 
And by the way that I don't 

1033
00:58:06,600 --> 00:58:08,200
think that's a soft problem 
either and it's a very 

1034
00:58:08,200 --> 00:58:11,700
interesting one. 
Well, perhaps that's a good 

1035
00:58:11,900 --> 00:58:16,900
segue into into governance. 
And so the framework and I 

1036
00:58:16,908 --> 00:58:19,100
thought this was one of the most
interesting parts of the 

1037
00:58:19,100 --> 00:58:23,200
framework talks about the 
governance model and the way 

1038
00:58:23,200 --> 00:58:28,400
that you deploy a network, so it
Coco framework has within it. 

1039
00:58:28,600 --> 00:58:32,400
This is a description of how 
Consortium members can deploy a 

1040
00:58:32,400 --> 00:58:35,300
network with. 
Just with, just one note, with 

1041
00:58:35,300 --> 00:58:38,600
just one Consortium member sort 
of initializing the network and 

1042
00:58:38,607 --> 00:58:40,800
then other members, Coming on 
board. 

1043
00:58:41,100 --> 00:58:44,100
Can you walk us through? 
You know, let's let's keep on 

1044
00:58:44,100 --> 00:58:48,500
this on this supply chain 
example, let's say I'm, I don't 

1045
00:58:48,500 --> 00:58:52,300
know Walmart and I want to 
initialize this network and then

1046
00:58:52,400 --> 00:58:58,000
start bringing on trade Finance 
actors, suppliers transport 

1047
00:58:58,000 --> 00:59:01,100
companies, you know, and all of 
the different participants and 

1048
00:59:01,100 --> 00:59:04,200
supply chain. 
How would I as Walmart for 

1049
00:59:04,200 --> 00:59:07,700
instance, deploy a network, 
using the cocoa framework. 

1050
00:59:08,400 --> 00:59:11,500
It's there's a great. 
Chin and it starts with some 

1051
00:59:11,500 --> 00:59:14,700
basic agreement on the 
parameters that all of the 

1052
00:59:14,700 --> 00:59:16,500
members are going to use. 
They if they have to pick a 

1053
00:59:16,508 --> 00:59:20,800
ledger it's not as though cocoa 
is like a lingua Franca - Franca

1054
00:59:20,800 --> 00:59:23,600
between Ledger's we're not 
attempting to solve that problem

1055
00:59:24,600 --> 00:59:27,700
so you have to pick your Ledger 
and you've all got to agree on 

1056
00:59:27,700 --> 00:59:29,700
the code version of The Ledger 
that you want to use. 

1057
00:59:29,700 --> 00:59:32,200
And you've all got to agree on 
who is going to participate at 

1058
00:59:32,200 --> 00:59:34,800
least at the beginning, you can 
have changes their overtime but 

1059
00:59:34,800 --> 00:59:37,000
there's got to be some initial 
set of members that you're going

1060
00:59:37,000 --> 00:59:40,300
to choose to do business with. 
Then you're going to have to 

1061
00:59:40,300 --> 00:59:43,300
agree on a variety of settings 
that relate to Coco. 

1062
00:59:43,300 --> 00:59:46,200
Like what trusted execution 
environments, you're going to be

1063
00:59:46,207 --> 00:59:48,400
willing to accept. 
You only want Hardware ones, you

1064
00:59:48,400 --> 00:59:52,800
want software ones, which ones. 
And for example, you need to 

1065
00:59:52,800 --> 00:59:57,000
agree on a threshold for voting 
among the members, do you 

1066
00:59:57,000 --> 00:59:59,600
require unanimity in order to 
approve new members? 

1067
00:59:59,600 --> 01:00:03,200
Do you need a simple majority? 
Do you need just some other 

1068
01:00:03,200 --> 01:00:06,600
threshold M of n could be 
arbitrary and so each of the 

1069
01:00:06,600 --> 01:00:09,200
members is then going to set up 
an environment for themselves 

1070
01:00:10,300 --> 01:00:13,400
And in each environment they're 
going to initialize their own 

1071
01:00:13,700 --> 01:00:16,900
cocoa node. 
In order to do that, they 

1072
01:00:17,400 --> 01:00:21,400
initialize the the code and then
they connect to The Enclave over

1073
01:00:21,400 --> 01:00:24,300
a secure Channel and they would 
probably the very first thing 

1074
01:00:24,300 --> 01:00:26,900
they'd like to do is they like 
to inspect the attestation at 

1075
01:00:26,900 --> 01:00:29,600
The Enclave gives back to make 
sure that the Enclave that they 

1076
01:00:29,600 --> 01:00:32,500
ended up with is actually the 
one that they wanted. 

1077
01:00:32,500 --> 01:00:35,800
And and there wasn't a malicious
actor, somehow residents on the 

1078
01:00:35,800 --> 01:00:38,400
Note, who injected some other 
malicious code inside of The 

1079
01:00:38,400 --> 01:00:40,200
Enclave. 
So you say, okay, hey, Hey look,

1080
01:00:40,200 --> 01:00:42,800
let's just say, for example, 
it's running on an Intel sgx 

1081
01:00:44,100 --> 01:00:47,800
capable chip and so you have an 
enclave and and there's an SS 

1082
01:00:47,800 --> 01:00:49,900
station that that looks to be 
valid. 

1083
01:00:49,900 --> 01:00:52,600
And you see that the code 
running inside is in fact 

1084
01:00:52,600 --> 01:00:54,700
represented by the hash of the 
Coca framework that you 

1085
01:00:54,700 --> 01:00:58,500
expected. 
And so then that member is going

1086
01:00:58,500 --> 01:01:02,400
to feed the initial 
configuration into that node 

1087
01:01:02,700 --> 01:01:04,600
saying, here are the other 
counterparties that I'm doing 

1088
01:01:04,600 --> 01:01:07,300
business with and here are the 
public keys that are that, that 

1089
01:01:07,300 --> 01:01:10,400
represent each one of them. 
And then that It is going to 

1090
01:01:10,400 --> 01:01:15,000
connect to the other nodes in 
the network using for example 

1091
01:01:15,000 --> 01:01:19,800
just DNS to find them and it 
will initialize connections and 

1092
01:01:19,800 --> 01:01:22,500
those will be TLS connections 
and then these nodes exchange a 

1093
01:01:22,500 --> 01:01:25,800
variety of data they exchanged 
access stations so they 

1094
01:01:25,800 --> 01:01:27,600
determine that. 
Each of them is running two 

1095
01:01:27,600 --> 01:01:30,800
years and they determine the 
code that's running inside and 

1096
01:01:30,800 --> 01:01:34,100
they're in the co configuration 
are the set of allowed code 

1097
01:01:34,100 --> 01:01:36,700
versions and allowed to use that
are expected. 

1098
01:01:36,900 --> 01:01:41,000
And so once the nodes have Have 
performed this validation, 

1099
01:01:41,000 --> 01:01:45,000
they're ready to go ahead and so
they then initialize processing 

1100
01:01:45,000 --> 01:01:51,600
on The Ledger, all of this 
metadata that describes how the 

1101
01:01:51,600 --> 01:01:54,800
network should be formed. 
And what settings are expected, 

1102
01:01:54,800 --> 01:01:56,700
we call the network 
Constitution. 

1103
01:01:56,700 --> 01:02:00,200
And that Network Constitution is
meant to represent all of the 

1104
01:02:00,200 --> 01:02:06,600
infrastructure level decisions 
about who can participate and 

1105
01:02:06,600 --> 01:02:10,500
how they could participate and 
members are only A accepted into

1106
01:02:10,500 --> 01:02:13,100
the network and those 
connections are only considered 

1107
01:02:13,100 --> 01:02:17,700
to be trusted if the rules of 
the Constitution are satisfied 

1108
01:02:18,300 --> 01:02:21,700
and that is sort of how the 
initial state looks in a coconut

1109
01:02:21,700 --> 01:02:27,200
work. 
So if a particular Coco network 

1110
01:02:27,200 --> 01:02:32,000
is deployed with the certain 
Constitution, do you expect 

1111
01:02:32,000 --> 01:02:34,800
there to be a lot of changes to 
this, the truth, to this 

1112
01:02:34,800 --> 01:02:37,000
Constitution. 
And I how do you think the 

1113
01:02:37,000 --> 01:02:39,300
governance process for these 
changes would look like? 

1114
01:02:39,900 --> 01:02:48,100
I think that This notion of a 
Consortium model is tremendously

1115
01:02:48,100 --> 01:02:53,400
powerful and that it will, it 
will disrupt multiple 

1116
01:02:53,400 --> 01:02:56,100
Industries. 
But I also think it's poorly 

1117
01:02:56,100 --> 01:03:01,300
studied and poorly understood 
today at least by those of us 

1118
01:03:01,300 --> 01:03:04,000
working on blockchain. 
I think there are other 

1119
01:03:04,000 --> 01:03:07,300
consortiums in existence that 
have been around for a long time

1120
01:03:07,600 --> 01:03:10,000
that are very well understood, 
think about a payment Network. 

1121
01:03:10,000 --> 01:03:12,000
Like, I don't know, like a Visa 
or MasterCard. 

1122
01:03:12,100 --> 01:03:14,900
That's essentially a Consortium 
of Banks and financial 

1123
01:03:14,900 --> 01:03:19,900
institutions and and you know, 
it's not managed in this way in 

1124
01:03:19,900 --> 01:03:21,600
particular. 
There's one, trusted party that 

1125
01:03:21,600 --> 01:03:24,900
runs it. 
I think that there's, this is a 

1126
01:03:24,900 --> 01:03:29,800
very rich area for new insight 
and Innovation and also services

1127
01:03:29,800 --> 01:03:32,500
that will make it possible to 
run, consortiums efficiently. 

1128
01:03:33,200 --> 01:03:35,100
But I think, you know, to begin 
with. 

1129
01:03:35,300 --> 01:03:38,100
And by the way many of those 
Consortium management problems 

1130
01:03:38,100 --> 01:03:41,100
are at the application Level as 
in the example that you gave 

1131
01:03:41,100 --> 01:03:43,600
before about a Faulty smart 
contract. 

1132
01:03:43,700 --> 01:03:46,000
But when it comes to the 
infrastructure, the Consortium 

1133
01:03:46,000 --> 01:03:49,900
has a life cycle members may 
come and members may go and the 

1134
01:03:49,900 --> 01:03:54,700
software used and even the Tes 
used by the members will iterate

1135
01:03:54,700 --> 01:03:58,500
over time and so those are the 
basic rhythms by which, I 

1136
01:03:58,500 --> 01:04:00,900
believe that the constitution is
likely to change. 

1137
01:04:00,900 --> 01:04:02,400
There may be other policy 
changes. 

1138
01:04:02,400 --> 01:04:04,800
Like, you might choose a 
different M of n Threshold at 

1139
01:04:04,800 --> 01:04:07,300
some point in time, but that 
feels less likely to me. 

1140
01:04:07,300 --> 01:04:09,500
I think the common thing that 
will happen is a Consortium will

1141
01:04:09,500 --> 01:04:12,000
get started with a certain set 
of members, they'll get it. 

1142
01:04:12,100 --> 01:04:14,200
It off the ground and they'll 
run it for a period of time. 

1143
01:04:14,200 --> 01:04:17,100
And once it's The Kinks are 
ironed out and they're ready to 

1144
01:04:17,100 --> 01:04:19,300
scale, it they'll bring other 
people in and at that point 

1145
01:04:19,300 --> 01:04:21,500
they'll have votes to bring in 
new members. 

1146
01:04:22,800 --> 01:04:26,500
They'll have you know, the 
manufacturers of the ledgers 

1147
01:04:26,500 --> 01:04:29,400
will have new versions of the 
ledgers that fix bugs or add new

1148
01:04:29,400 --> 01:04:31,800
capabilities. 
And in some cases, they will 

1149
01:04:31,800 --> 01:04:34,800
carry a Coco. 
Payload that changes the the 

1150
01:04:34,800 --> 01:04:37,100
functionality that the Coca 
framework provides for that 

1151
01:04:37,100 --> 01:04:39,300
ledger. 
And so, these are all updates 

1152
01:04:39,300 --> 01:04:41,800
that need to be applied and can 
only be applied if the network 

1153
01:04:41,800 --> 01:04:46,400
comes Solution is updated to 
accept them and so we imagine 

1154
01:04:46,400 --> 01:04:50,000
there will be lots of 
interesting scenarios around 

1155
01:04:50,000 --> 01:04:53,200
this governance where we're 
consortiums will decide hey, I 

1156
01:04:53,200 --> 01:04:59,900
just want to accept any new 
distribution that let's say it's

1157
01:04:59,900 --> 01:05:02,600
signed by R3 from the from the 
court of team. 

1158
01:05:02,600 --> 01:05:05,200
And so, any any signed, our 
three payload ought to be able 

1159
01:05:05,200 --> 01:05:08,100
to run all that ultimately needs
to be able to be expressed as a 

1160
01:05:08,107 --> 01:05:09,900
cocoa policy. 
Not something that we would have

1161
01:05:09,900 --> 01:05:11,400
in our V1. 
But something that we work 

1162
01:05:11,400 --> 01:05:13,700
towards over Time. 
And so we'll try to remove the 

1163
01:05:13,700 --> 01:05:16,200
friction from these basic 
changes, that would happen in 

1164
01:05:16,207 --> 01:05:18,900
the network. 
This is really fascinating. 

1165
01:05:18,900 --> 01:05:25,400
I mean, I can see how any any 
Enterprise Consortium looking to

1166
01:05:25,400 --> 01:05:28,000
launch a blockchain network. 
Could find a lot of the 

1167
01:05:28,000 --> 01:05:30,100
properties and a lot of 
functionalities that they would 

1168
01:05:30,100 --> 01:05:33,100
need for production networks 
within within Coco saw. 

1169
01:05:33,500 --> 01:05:36,700
I'm definitely going to keep 
looking into this and I'm 

1170
01:05:36,700 --> 01:05:38,300
looking forward to seeing how 
this develops. 

1171
01:05:39,400 --> 01:05:42,000
We're nearly at the end of our 
nearly at the end of the show. 

1172
01:05:42,700 --> 01:05:44,600
But so I've got a couple of 
other questions. 

1173
01:05:44,600 --> 01:05:49,400
So one is so we had Marley gray 
on a few months ago to talk 

1174
01:05:49,400 --> 01:05:52,300
about project Bletchley. 
So can you just briefly, 

1175
01:05:52,700 --> 01:05:57,700
perhaps, tell us if is this 
connected to project Bletchley 

1176
01:05:57,700 --> 01:06:00,100
in any way? 
Is there any overlap there with 

1177
01:06:00,200 --> 01:06:04,600
other initiatives, at Microsoft?
I mean I I presume that all the 

1178
01:06:04,700 --> 01:06:08,400
Azure blockchain is a service 
staff will have cocoa and sort 

1179
01:06:08,400 --> 01:06:10,300
of built-in and you can use that
to launch or network. 

1180
01:06:10,300 --> 01:06:13,300
But what about these other 
Blockchain projects. 

1181
01:06:13,800 --> 01:06:17,600
Yeah, you know a large fraction 
of the investment that we're 

1182
01:06:17,600 --> 01:06:22,300
making has to do with as and 
sort of horizontal SAS built on 

1183
01:06:22,300 --> 01:06:25,200
top of blockchain and Bletchley 
is that vision for this 

1184
01:06:25,200 --> 01:06:28,300
connected set of services, many 
of them existing that can be 

1185
01:06:28,300 --> 01:06:33,000
used in a in a thoughtfully. 
Constructed way to enable 

1186
01:06:33,000 --> 01:06:36,100
Enterprises to take advantage of
blockchain as a shared data 

1187
01:06:36,100 --> 01:06:39,400
layer in many different kinds of
business applications. 

1188
01:06:39,400 --> 01:06:41,200
And so that's a big area of 
focus for the team. 

1189
01:06:41,200 --> 01:06:44,200
It's sort of a whole Topic. 
But one of the things that that 

1190
01:06:44,200 --> 01:06:49,100
seemed important to us was that 
the base Foundation be sound for

1191
01:06:49,100 --> 01:06:54,000
Enterprise use and you know it 
became clear that enterprises 

1192
01:06:54,000 --> 01:06:57,200
would have trouble adopting the 
paths and Sass that we're 

1193
01:06:57,200 --> 01:06:59,000
working on in The Bletchley 
Vision. 

1194
01:06:59,300 --> 01:07:03,100
If the blockchain was not able 
to address their needs in terms 

1195
01:07:03,100 --> 01:07:05,900
of confidentiality scalability 
performance governance. 

1196
01:07:06,100 --> 01:07:10,200
And so we think that cocoa and 
Bletchley are our sort of self 

1197
01:07:10,200 --> 01:07:13,400
to self-reinforcing Investments.
But there are two very different

1198
01:07:13,400 --> 01:07:15,900
Investments. 
Bletchley is really a cloud 

1199
01:07:15,900 --> 01:07:19,700
platform. 
Play Coco is not Coco seeks to 

1200
01:07:19,700 --> 01:07:22,900
be the foundation of blockchain 
for the Enterprise wherever 

1201
01:07:22,900 --> 01:07:25,500
blockchain in the Enterprise is 
running so it can be running on 

1202
01:07:25,500 --> 01:07:29,000
premises in our cloud. 
In another Cloud it will be made

1203
01:07:29,000 --> 01:07:34,400
available in as open source for 
free for Enterprises to use and 

1204
01:07:34,400 --> 01:07:38,000
in and for a ledger 
manufacturers to integrate and 

1205
01:07:38,000 --> 01:07:39,800
it will work on both windows and
Linux. 

1206
01:07:39,800 --> 01:07:41,900
So it's going to have very Broad
applicability. 

1207
01:07:42,200 --> 01:07:44,700
And as an open source project, 
we're not looking for example, 

1208
01:07:44,700 --> 01:07:47,800
to directly monetize cocoa, but 
we do think that it's a 

1209
01:07:47,800 --> 01:07:50,300
necessary investment to get 
Enterprise adoption. 

1210
01:07:50,300 --> 01:07:53,600
That then in turn can take 
advantage of the innovation in 

1211
01:07:53,600 --> 01:07:56,700
Bletchley definitely, like I 
could see a lot of value in 

1212
01:07:56,700 --> 01:08:00,000
that. 
So, at the moment, you've 

1213
01:08:00,000 --> 01:08:03,000
written a white paper to which 
will link in the show notes. 

1214
01:08:03,400 --> 01:08:06,700
Is there an implementation of 
cocoa that people can download 

1215
01:08:06,700 --> 01:08:10,300
and use at this at this time? 
So where we are today, is that 

1216
01:08:10,300 --> 01:08:11,700
we've built what we 
demonstrated? 

1217
01:08:11,700 --> 01:08:17,100
We Took vanilla aetherium. 
We modified it to run on top of 

1218
01:08:17,600 --> 01:08:20,200
the cocoa framework in its 
current form. 

1219
01:08:20,600 --> 01:08:24,700
And we adapted we worked with 
magic smudge, X adapted, an 

1220
01:08:24,700 --> 01:08:26,500
application to run on top of 
that. 

1221
01:08:26,500 --> 01:08:30,000
And that's what we demonstrated 
in the demo that we did. 

1222
01:08:30,800 --> 01:08:35,200
We're working right now towards 
a V1 release of cocoa in 2018. 

1223
01:08:35,200 --> 01:08:38,000
That would be an open source 
release over the course of the 

1224
01:08:38,000 --> 01:08:39,399
Fall. 
We'll be working on that. 

1225
01:08:39,399 --> 01:08:41,500
And will probably be working on 
that with some of the partners 

1226
01:08:41,500 --> 01:08:44,000
that we've already. 
Eddie announced Intel with some 

1227
01:08:44,200 --> 01:08:48,399
hyper Ledger Sawtooth are three 
with korda JPMorgan Chase with 

1228
01:08:48,399 --> 01:08:50,399
Quorum. 
We'll be working on 

1229
01:08:50,399 --> 01:08:53,800
incorporating cocoa into those 
Ledger's and then ultimately 

1230
01:08:53,800 --> 01:08:55,100
again get to an open source 
release. 

1231
01:08:55,100 --> 01:08:59,300
In 2018 that I think we'll open 
it up to 22 broader consumption.

1232
01:09:00,700 --> 01:09:03,100
Cool. 
Well, I'll definitely be looking

1233
01:09:03,100 --> 01:09:05,399
forward to that. 
And so thank you very much for 

1234
01:09:05,399 --> 01:09:07,000
coming on the show. 
That it was a fascinating 

1235
01:09:07,000 --> 01:09:09,700
episode and look forward to 
having you back on in the 

1236
01:09:09,707 --> 01:09:12,200
future. 
Perhaps when you when Microsoft 

1237
01:09:12,200 --> 01:09:14,500
released see open source 
framework and we start seeing 

1238
01:09:14,500 --> 01:09:18,700
applications being built on Coco
enabled networks. 

1239
01:09:19,399 --> 01:09:22,200
Hey I really appreciate the time
and the wonderful conversation 

1240
01:09:22,200 --> 01:09:25,300
questions. 
Thank you so much and thank you 

1241
01:09:25,300 --> 01:09:28,399
to our listeners for once again.
Tuning in epicenter is part of 

1242
01:09:28,399 --> 01:09:29,700
the let's talk Bitcoin Network 
you can. 

1243
01:09:29,899 --> 01:09:32,100
Find this show and lots of other
great shows at let's talk 

1244
01:09:32,100 --> 01:09:33,700
Bitcoin.com. 
Of course, if you want to 

1245
01:09:33,700 --> 01:09:35,399
support the show, there's 
multiple ways you can do that. 

1246
01:09:35,399 --> 01:09:37,700
You can leave us a review on 
iTunes or wherever you get your 

1247
01:09:37,700 --> 01:09:39,500
podcast. 
It always helps people find the 

1248
01:09:39,508 --> 01:09:42,500
show and we appreciate it 
greatly and you can also leave 

1249
01:09:42,500 --> 01:09:45,300
us a tip and a tipping address 
will be as always in the 

1250
01:09:45,300 --> 01:09:47,300
description. 
So thanks so much and we look 

1251
01:09:47,300 --> 01:09:48,600
forward to be back next week.