Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Matt Kerner: Microsoft’s Coco Framework – The Holy Grail for Enterprise

Episode Date: September 19, 2017

Enterprise consortium blockchains have gained a lot of interest in recent months. And although we can see many applications for this particular type of network deployment, many questions remain to be answered before these systems can move to production. Issues related to scaling, network deployment, access controls and key management remain open at this point. With its deep roots in the enterprise, Microsoft hopes to have answers to these questions. Matt Kerner, Partner GM for Blockchains at Azure, joins us to discuss Coco Framework. Coco is an open-source system which promises to enable high scalability and offer confidentiality for enterprise blockchain consortiums. This novel framework leverages Trusted Execution Environments (TEE) to deliver blockchain networks with throughput comparable to database speeds. Topics covered in this episode: Matt’s background and role at Azure Azure’s high-level thesis regarding blockchains Coco Framework and how it fits in Microsoft’s vision The different components of Coco and its architecture The role of TEE’s in Coco How Coco achieves confidential transactions Identify management and network governance in Coco How Coco fits into other blockchain initiatives at Microsoft The framework’s roadmap Episode links: Announcing the Coco Framework for enterprise blockchain networks Introducing the Coco Framework - YouTube Coco Framework Whitepaper This episode is hosted by Meher Roy and Sébastien Couture. Show notes and listening options: epicenter.tv/201

This is Epicenter. Episode 102 with guest Matthew Kerner. This episode of Epicenter is brought you by Shapeshift.io, the easiest, fastest, and most secure way to swap your digital assets. Don't run a risk of leaving your funds on a centralized exchange. Visit Shapeshift.io 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 Quiju. And I'm a hero. Today we are talking to Matthew Kerner, who is partner GM at Microsoft, working in blockchains and financial services.

We'll talk about recent announcement from Microsoft regarding the Koko Framework, which uses trusted execution environments in a special way to make consortium blockchain networks. So, Matthew, welcome to the show. Thanks for coming on. Thank you so much for having me. So before we begin, like we'd like to know how you will. got interested in blockchains while working at Microsoft? It found me. What happened was that across the company, broadly, people within the company were starting to

look at blockchain. And it found its way to my team because broadly we owned a set of verticals, including financial services. And so it made sense for us to look at it within the Azure team. And so we borrowed one person from 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 sort of couldn't

stop reading about it. 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. We're 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 banks, capital markets, insurers, payment providers, and other financial organizations to run on Azure, whether it's compliance certifications or certain features that the platform needs to have or an ecosystem to support that market of ISVs and SIs. 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 there, 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 sort of 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've got to say, I've been really just very impressed with all the, all the interesting stuff that's been coming out of Microsoft, you know, especially in these recent years. And just the level of commitment to blockchain technologies that's been coming apparently at the CEO level, even Satya Nadella, you know, coming to events and visiting, you know, startups, you know, in these Microsoft developer events like last year here in Paris. and I've got the feeling that, you know, a lot of people see Microsoft as 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 are neglected to realize that Microsoft's changed a lot in 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 little bit about that change? And I think you've been at Microsoft for quite a while. Like, how is 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 so 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 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, is one trend. But also, I think the disruption of the on-premises packaged 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 challenges 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 that 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 it take us to places. We're 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, where you look, especially 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 businesses be thinking about blockchains? How could, should businesses be thinking about the potential for blockchain technologies and 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 there are a variety of different postures that a business could take. And these postures could apply to any technology trend. If I think, for example, about cloud, 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, and their competitors now

have an asset that is differentiated and sets them apart. When it comes to blockchain, I think lots of organizations are in a wait-and-sea mode, and it's not unreasonable for organizations to be there. Again, 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,

a 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 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 costs. And none of the organizations that we talk to, enterprise organizations looking at doing blockchain projects, find it to be a 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 assumption. 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. So in your experience, Matthew, when you talk to enterprise clients, what are the key requirements for blockchain platforms that come across to Microsoft? And how are the different from the open source public varieties that we find.

It's a great question. I think these requirements are often the same that enterprises 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 detailed technical conversation. And so they've got some specific requirements around how blockchain will work for them. But most customers that we talk 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 that many of these customers are already using. We're already talking about our identity offering with Azure Active Directory that, you know, over 80% of the Fortune 500 are already on, and thousands of SaaS 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 touchpoints that we have with enterprises, and they've got requirements down at the bottom, let's say when it comes to the blockchain tech and cloud platform that are non-functional in nature,

And they've got business requirements up at the top to make blockchain consumable by lines of business as opposed to technical wizards with a specialized skill set. And so those are the conversations that we have with most of the enterprises that we deal with. Okay. So one of these special things about the COCO framework is that it uses these things which are called TEEs or trusted execution environments. Can you explain what is a trusted execution environment? Sure. Just really briefly, a 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 TE, like Intel SGX, just as one example, the chip enables you to create what's known as an enclave, which is a software-based TEE, like Intel SGX, just as one example, the chip enables you to create what's known as an enclave, which is a 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 Acres. execution environments where once you create a trusted execution environment, the code inside of that

TEE does, or inside of the enclave, doesn't trust the OS. And so it 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 than you used to be able to do. The other thing that TEEs can do, useful capability, is they can produce what's known as an attestation, which is a blob of data that can be remotely verified, that proves that the TEE is in fact a valid TEE, and that the data or the code inside of the TEE 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 a TE on another machine, establish trust, and determine that that TE is in fact the thing that you think it is. And what you end up with is basically this remotely verifiable, strong identity for code that doesn't assume in its 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. So this is a really good visualization, this strong identity for code. So essentially a TEE 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 TEE will produce an output. And that output would be accompanied by an attestation, which I presume would have some sort of a signature. that signature could be like the certificate of the TEE's 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, a reasonable assumption that, well, this execution environment did in fact produce the output that was it was programmed to produce.

Yeah, that's absolutely right. And I would add, TEs 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 TEs 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 VMs. Only the hypervisor can see it. And so at that point, if you are willing to trust Microsoft as the hypervisor provider, you can have a degree of trust 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 TEEs 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 TEEs. The beauty of something like zero knowledge proof or homomorphic encryption is that you have a mathematical basis for the confidentiality. of the data or the correctness of the result that you're getting from a computation. And so even if an adversary could completely compromise 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 cryptographic assumption of the math are sound. And the trade-off that people accept when they use these sorts of schemes is typically a time and space trade-off. well, there are actually three tariffs. There's a time trade-off. You know, it can take longer to produce these sorts of cryptographic results than it would take to use a TEEE to produce the results. There can be a space trade-off where the size of the ciphertext

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 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 comparison to some of these cryptographic models where it takes 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 TEs, 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 COCO framework, I think one of the

interesting questions is like blockchain technology was was was developed in sort of this decentralized mode where the expectation was that there would be like multiple nodes that would be controlled by different people working together to create something like which is trying to be trustless now like 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 by Microsoft, they might be running TEEs and some form of executional guarantee might be given.

But if all of the nodes are on the cloud controlled by one or two different corporations, does like blockchains preserve this 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 blockchain 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 consortions 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 are putting these things on cruise ships, in mines, on the factory floor, in regions of the world where we don't currently have a hyperscale cloud presence. And so they're solving lots of different problems with Azure Stack. 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 workload that's running on top of blockchain? There are public networks, and those public networks are expressly designed to be fully decentralized,

not take any dependency on any sort of centralized authority. And, you know, public clouds might be useful for deaf tests. They might be useful for running certain utilities that the public networks consume. 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.

They're subject to law enforcement. They're subject to the jurisdiction of one court or another. And today, you know, all of these non-technical controls govern the way that enterprises behave, and I believe that that will be true for the foreseeable future. So the assumptions for enterprises going in are 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's compliance posture, getting dozens and dozens of certifications, is because we want any customer in any industry and any geography to be able to use our cloud. And certainly compliance is 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 to 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 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 point at which TEEs become widespread, it will be a watershed moment if we look back in history of 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 an 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 ciphertexts. The cloud could take that and process it inside of the trusted execution environment where,

let's say, the hardware boundary prevents the cloud operator from seeing that data in the clear. And then the TEE 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 that enterprises are willing to trust Microsoft to provide, to provide in return for the elasticity, the agility, the set of services that are made available in dozens of regions around the world at hyperscale. And so we think that that tradeoff is fundamentally attractive to people in enterprises, decision makers and enterprises. And so that's why we think that blockchain has a role in Azure. Well, let's get right into it.

Then the COCO framework. So what is the COCO framework? And can you perhaps describe that stack of technologies or the architecture of the COCO framework? Sure. Enterprises everywhere are curious to see how blockchain can be used to transform their markets and their business. And as we talk with them, one of the very first concerns that they raise is that they're used to 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 ship 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 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 that 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 were 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 big, basic. It basically comes down to the decision of what code is run on each of the mining nodes in these public networks.

And when we talk with enterprises, they feel that the scalability, latency, confidentiality, and governance, tradeoffs that they make with blockchain are oftentimes 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 who have been working on enterprise computing for 20 or 30 years in some cases, that we felt there was something that ought to be done about that, and we felt that none of the solutions that were out there in the market really hit the enterprise design point squarely and in a head-on way. And so we started working on the Koka framework, and it was an idea that came jointly sort of out of some thinking from Mark

Kinovich, who's the Azure CTO and Microsoft Research, where we have a number of people looking at blockchain broadly. And the basic idea of the Koka framework is, first of all, it's not a ledger. 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 a 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 milliseconds 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

ledgers across industry verticals 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 uh i'll try to state the same thing uh in my own words so like with any blockchains with any like with any public blockchain there are generally like three or four main components to it right so so the first is like this networking layer so there's this generally this gossip network the channels like communicating all of these messages then there's the consensus layer or consensus piece which is like once you have these nodes and they're communicating with each other how they arrive at consensus on on like changes to whatever

data set they're 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 upgrades to the to the network to the network consensus or transaction logic so the way like I see Coco is the Coco is trying to build just the networking governance and consensus systems, and on top of it, anyone can plug in their own transaction types or ledger types. Yeah, it's a good question.

Coco is certainly seeking to solve that networking layer problem. It also will come out of the box with a variety of consensus options. And so it can handle consensus for a ledger if the ledger wants to delegate that. It does not concern itself with the content of transactions per se. That's the ledger's job. But it also does have something to say about governance. Although I don't expect that Coco will ultimately be the sole answer to governance and consortium that works. I think Coco will be able to be responsible for some low-level governance about the basic sort of 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 implements 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 ShapeShift. The world's leading trustless digital asset exchange quickly swapped between dozens of leading cryptocurrencies, including Bitcoin, Ether, Z. Zcash, Gnosis, Monero, Golem, Auger, and so many more. When you go to Shapeshift.io, you simply select your currency pair, give them your receiving

address, sent the coins, and boom. Shapeshift is not your traditional cryptocurrency 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, so you are never at risk from a hacker or other malicious actor. shape shift has competitive rates and has even integrated in some of your favorite wallet apps like jacks 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 shapeshift. i.o and start trading and we'd like to thank shapeshift for their supportive app center so tell us like how do you expect like enterprises to use the cocoa framework so let's assume like Let's assume like a group of enterprises is wanting to build like a consortium blockchain for a supply chain application. So is it the case that they can just take the Koko framework, like choose a particular flavor of ledger, right?

Like pick an Ethereum like ledger system or Korda like ledger system or whatever, and then mix and merge the two and then deploy that application. I think supply chain is a great example. Let's just start with some of the things that a supply chain consortium might 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 are responsible for transportation, customs, and so on. And then there's maybe another layer of services that are provided in a supply chain consortion that has to do with trade finance, where for any one of these orders, the buyer,

is really only going to want to pay for it once the goods are received. But the supplier is 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 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 of 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. But I think one of the first problems that you would see. 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. A phone call is probably actually faster than the supply chain. So it moves above the speed, below the speed of humans. So we're not so worried about the performance, you know, 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 we knew that about our competitors when it came to, for example, the cloud supply chain, 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 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 did they deliver on time the right set of goods? And by sharing that, they can get better terms for trade finance loans.

And by getting better terms for trade finance loans, 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? Has the truck gone through customs?

Have the things been tampered with? Did the number arrive that were expected? Was it 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, that this can be an extremely tedious process. And then, you know, traditionally, people would be on the first. phone, working with 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 introduce

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 U.S. 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 KYC AML 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 in a blockchain. And so can you explain then how a COCO framework-enabled blockchain network, so to speak, achieves this high level of scalability. I saw this Mark Resinovich demo, which we'll link to in the show notes

where we're running an EVM and there's just like thousands of transactions per second. It just goes, the transaction odometer just goes off the rails. And so, yeah, let's address that and also address how we can achieve transaction confidentiality when everybody knows that on the public Ethereum network, it's nearly, you know, it's theoretically impossible to achieve a transaction, in the current implementation of Ethereum, it's impossible to achieve a transaction confidentiality.

Sure. So, so in this, in this consortium example, the way that we can do this is, first of all, the consortium picks a ledger, and we've announced several that intend to integrate with Coco, and are working with several others where we're not yet ready to announce anything. So they'd pick their ledger, and that ledger would, would incorporate the COCO framework into its distribution. And what COCO does is it makes, it 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 attestations. 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. They're in fact running 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 so 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. 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 trusted execution 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 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 caller who has a role that's a trade finance role. Now you've got this very fine-grained R-back. It's standard R-back role-based access control that any enterprise developer would use today. They set 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 trust execution environment, it can't be read from the outside. And now all of a sudden you've got a consortium that can 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 SNARCs or homomorphic encryption. It would be a real challenge to come up with this, especially this fine-grained confidentiality for that supply chain consortium scenario. This is amazing because back in 2015, so prior to 2015, there was no notion of enterprise blockchains at all. I think enterprise blockchains like consortium. change really started 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 the solution the proposed solution to it has always been some form of zero knowledge proofs but zero knowledge proofs are are very limited in what they can do So this almost seems like a holy grail, right? Like you're taking components like trusted execution environments which are available and then able to build a blockchain, like consortium chain platform in which privacy of data can be guaranteed by only role-based access. This seems something which is like very powerful.

We think so. We think that it addresses the key things that our enterprise customers are telling us. they want out of blockchain. And by the way, using Coco doesn't mean that you have to give up on all of those other techniques. One of the ledgers that publicly express their intent

to integrate Coco is Quorum, which was built by J.P. Morgan Chase and is this open source ledger that's sort of a modification of Ethereum 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 all already has on its roadmap the desire to incorporate other kinds of cryptography like the the ZSL that derives from these zero 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 COCO will be yet another layer that enables consortiums to achieve what they would like. And so this is not meant to be sort of the one single answer that's suitable for everything. People will use cryptography where it makes sense.

They'll use the 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 test my understanding. So what Koko 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 like a shipping company, Sebastian. A fish lobster. Yeah, fish lobster. And like, Matthew, you buy some things in bulk. And Sebastian is a, like,

is a financing company. And all of us are on one like blockchain ledger, which is running on the Koko 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 trusted and execution environments come to consensus on that data and also allows me to selectively only selectively reveal my data to the other consortium participant. 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 to Sebastian. And, you know, 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 this application, physics application that's built by a company called Mojix 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++ Ethereum code base and we replatformed it to run on top of Coco, 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 Mojiks had to do, first of all, they removed all public data from their smart contract definitions, 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 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, Coco 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. 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 a question on what happens when something goes wrong. Like for example, you have

a smart contract, right? 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 let me sort of work my way into it. First of all, 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 and environments might be suitable for handling that data because different TEEs have different

characteristics. So that's sort of step one. And I imagine there will be some workloads that are not suitable for Coco, and that's fine. The next thing is we assume breach. In 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 TEE can be compromised. And that's a much worse failure than a smart contract having a defect. Because TEE compromise would expose everything if we approached it in a naive way. And so 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. 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 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 trusted computing base inside of the T, 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 Coco. And then there's another enclave that runs the ledger code base.

And that code case 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 a tax 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 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 to each perform a partial decryption, and those decryption shares can be combined to reveal the plain text. And what that means is if you've got one counterparty who somehow compromises a TEE 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 decryptions that anyone can do. And if that rate limit is exceeded, they can alert. And it was very important to us, by the way, that we did enable sort of offline decryption by Aquarium because there's a disaster recovery scenario where you no longer have the T's that we're storing the keys that were being used.

And you need all of those members to be able to collude, this time, for legitimate purposes, to rehydrate the ledger in new infrastructure. 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 TEs reattest 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 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 node 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 performance overhead and this sort of energy consumption overhead. And so we think that there will ultimately be a variety of different consensus models available in Coco.

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 it to all of the other participants in the network. And those participants just blindly accept the state changes from the leader and commit them. And this is a pretty high-throughput model. It's sort of consistent with what you might 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 in this model, you're only worrying about crashes.

You're not worrying about Byzantine adversaries 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 a TE and become malicious. 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 a leader is still the one responsible for broadcasting the state changes. The majority of nodes synchronously accept 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 of course, if any of the nodes does detect a violation, they can alert and you can rewind the ledger back to the last agreed upon state. Perhaps you kick out the bad actor 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 and depth measures to reduce the likelihood of a catastrophic failure there. We actually 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 COCO 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, I don't think that's a self-problem either, and it's a very interesting one. Well, perhaps that's a good segue 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 Cocoa framework has within it a description of how consortium members can deploy a network with just one no, 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 keep 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 in the supply chain, how would I, as Walmart, for instance, deploy a network using the Coco framework? There's a great question. And it starts with some basic agreement on the parameters that all of the members are going to use. They have to pick a ledger. it's not as though Coco is like a lingua franca between ledgers. 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 there over time, but there's got to be some initial set of members that you're going to choose to do business with. And 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, Do you only want hardware ones? Do 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? It 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 Coco node. In order to do that, they initialize 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'd like to inspect the attestation that the enclave gives back. To make sure that the enclave that they ended up with is actually the one that they wanted. And there wasn't a malicious actor somehow resident on the node who injected some other malicious code inside of the enclave. So you say, okay, hey, look, let's just say, for example, it's running on an Intel SGX capable chip, And so you have an enclave and there's an attestation that looks to be valid. And you see that the code running inside is in fact represented by the hash of the COCO 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 represent each one of them. And then that node 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 exchange attestations so they determine that each of them is running TEEs and they determine the code that's running inside and they're in the COCO configuration are the set of allowed code versions and allowed TEEs that are expected and so once the the nodes have have performed this validation they're ready to go ahead and so they then initialize processing and 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 can participate.

And members are only accepted into the network and those connections and are only considered to be trusted if the rule. of the Constitution are satisfied. And that is sort of how the initial state looks in a Koko network. So if a particular Koko network is deployed with a certain constitution, do you expect there to be a lot of changes to this constitution? And 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 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, 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 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 TEEs 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 as a consortial will get started with a certain set of members. They'll get it off the ground and they'll run it for a period of time. And once 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 Koko payload that changes the functionality that the Koko framework provides for that ledger.

And so these are all updates that need to be applied and can only be applied if the network constitution is updated to accept them. And so we imagine there will be lots of interesting scenarios around this governance where consortsions will decide, hey, I just want to accept any new distribution that, let's say, is signed by R3 from the quarter team. And so any signed R3 payload ought to be able to run, well, that ultimately needs to be able to be. expressed as a COCO policy, not something that we would have in our V1, but something that we would 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, you know, any enterprise consortium looking to launch a blockchain network could find a lot of the

properties and a lot of functionality that they would need for production networks within Coco. So I'm definitely going to keep looking into this and then looking forward to seeing how this develops. We're nearly at the end of the show. So I've got a couple of other questions. So we had Marley Gray on a few months ago to talk about Project Bletchley. So could you just briefly just perhaps tell us, is this connected to Project Bletchley in any way? Is there any overlap there with other initiatives at Microsoft? I presume that all the Azure blockchain as a service stuff will have cocoa and sort of built in, and you can use that to launch a 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 PAS and sort of horizontal SaaS 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 thoughtfully constructed way to enable enterprises to take advantage of blockchain as a share. data layer in many different kinds of business applications. And so that's a big area focus for the team. It's sort of a whole different topic. But one of the things that that seemed important to us was that the base foundation be sound for enterprise use. And it became clear

that enterprises would have trouble adopting the Paz and SAS 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 Coco and Bletchley are two 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 and the enterprise is running. So it can be running on premises, in our cloud, in another cloud. It will be made available as open source for free for enterprises to use. and for 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 Coco. 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. Oh, definitely, I could see a lot of value in that. So at the moment, you've written a white paper to which we'll link in the show notes. Is there an implementation of Coco that people can download and use at this time? So where we are today is that we've built what we demonstrated. We took vanilla Ethereum. We modified it to run on top of the Coco framework in its current form. And we adapted, we worked with Mojix.

Mojix 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 we'll probably be working on that with some of the partners that we've already announced Intel with Hyperledger Sawtooth, R3 with Cora, J.P. Morgan Chase with Quorum.

We'll be working on incorporating Coco into those ledgers, and then ultimately, again, get to an open-source release in 2018, that I think will open it up to broader consumption. Cool. Well, definitely be looking forward to that. And so thank you very much for coming on the show. It was a fascinating episode and look forward to having you back on in the future. Perhaps when Microsoft released the open source framework and we start seeing applications being built on Coco enabled networks. Hey, I really appreciate the time and the wonderful conversation and 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 you. 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 the tipping address will be, as always, in the show description. So thanks so much and we look forward to being back next week.