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