#201 Matt Kerner: Microsoft's Coco Framework – The Holy Grail for Enterprise

Thank you so much for having me.

It found me. What happened was that across the company, we were 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. 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.

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. 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, we're building the blockchain technology in the Azure team that we make available on our cloud, and we're also responsible for 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.

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 source as you say as 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 where honestly we're not entirely sure what those places are yet. We'll just have to see.

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-see 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 talents 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 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 that 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, meaning 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.

Sure, we find it's a great question. I think these requirements are often the same 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 a 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 using. We're already talking about our identity offering with Active Directory that 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 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 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.

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 TEE, 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 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 once you create a trusted execution environment, the code inside of that TEE, 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 this 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 TEE on another machine, establish trust, and determine that that TEE 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.

Yeah, that's absolutely right. And I would add, TEEs 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 TEEs as well. And the benefit of that model in our case is 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 host OS.

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 with what you get with TEEs. 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 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 math, 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 trade-offs. There's a time trade-off, it can take longer to produce these sorts of cryptographic results than it would take to use a TEE 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 truly want to have a trustworthy system. So there are trade-offs. I'd also say that 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 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.

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 are entirely on Azure. I think that would be silly. We would not be meeting customers where they live. The nature of blockchain, 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, 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 public clouds might be useful for dev/test, 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, all of these non-technical controls govern the way that enterprises behave, and I believe that will be true for the foreseeable future. So the assumptions for enterprise blockchain 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 is compliance posture, getting dozens and dozens of certifications, is because we want any customer in any industry in 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 US. We said that we wanted that to be served, but we wanted it 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. If you think about this, just imagine that you had some health data, 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 on the cloud. You could upload your ciphertext, 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 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, trusted 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 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 I think that trade-off is fundamentally attractive to decision-makers in enterprises. And so that's why we think that blockchain has a role in Azure.

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 a set of non-functional requirements 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 products 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 assumes 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. 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 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 basic, as 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 trade-offs 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 Coco framework, and it was an idea that came jointly sort of out of some thinking from Mark Russinovich, 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 Coco 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 these 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 Coco will enable enterprises to consume blockchain without having to compromise on any of their basic non-functional requirements.

Yeah, that'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 in a consortium. 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.

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 and customs and so on. And then there's maybe another layer of services that are provided in a supply chain consortium that has to do with trade finance, where for any one of these orders, the buyer's 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 finance services 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 creditworthiness.

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. 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 bearer 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 below the speed of humans. 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 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 any supply chain consortium would have the same concern. But I think, keep in mind, you then have these trade finance providers who are trying to extend the 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 Microsoft's own business, that this can be an extremely tedious process. And then typically, traditionally, people would be on the 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 to 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 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 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.

Sure. So 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 that we're not yet ready to announce anything. So they pick their ledger, and that ledger would incorporate the Coco framework into its distribution. And what Coco does is it makes changes to 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 represents 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 Coco 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 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 enclave that they own, and we are 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 RBAC—it's standard RBAC, 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 in the clear inside of the trusted 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-SNARKs 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.

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 has expressed their intent to integrate Coco is Quorum, which was built by JPMorgan 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 already has on its roadmap the desire to incorporate other kinds of cryptography, like the crypto 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 the one single answer that's suitable for everything. People will use cryptography where it makes sense, they'll use 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.

That's exactly right. And by the way, it can be even finer-grained than revealing my data to Sebastian or not to Matthew. It could be, 'I'm going to reveal the date of the order to Matthew and the quantity of the order and the date of the order to Sebastian.' 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 this application, Physix, that's built by a company called Modum, 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 EVM for transactions. And so all that Modum 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 we also had to disable a couple of APIs—those APIs that enable raw read access to the transactional history or raw read access to smart contracts' 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.

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 environments would be suitable for handling that data, because different TEEs have different characteristics. And 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. 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; and third of all, minimize the blast radius when a breach occurs 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 researchers published some papers on this; there are compiler techniques, static and dynamic analysis, that can prevent data from leaking outside of a TEE even if there's a compromise inside of the TEE. So there are some classes of bugs that we can just eliminate upfront. The next thing is, I worry about the size of the trusted computing base inside the enclave. And so in our design, 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 Coco 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 base could be potentially larger; that will vary by ledger, it might be of 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 and code 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 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 plaintext. 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 a quorum, because there's a disaster recovery scenario where you no longer have the TEEs that were storing the keys that were being used, and you need all of those members to be able to, 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 TEE could be compromised and to be able to detect it. You can, for example, have TEEs 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.

It'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's 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, 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 in the Coco configuration are the set of allowed code versions that are expected. And so once the nodes 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 can participate. And members are only 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 Coco network.

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 Visa or MasterCard; that's essentially a consortium of banks and financial institutions, and it's not managed in this way. In particular, there's one trusted party that runs it. I think that 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, 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 lifecycle. 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 is a consortium 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 Coco update that changes the functionality that the Coco 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 consortiums will decide, 'Hey, I just want to accept any new distribution that, let's say, is signed by R3 from the Corda team.' And so any signed R3 build, it ought to be able to run. All that ultimately needs to be able to be expressed as a Coco policy—not something that we would have in our V1, but something we will work towards over time. And so we'll try to remove the friction from these basic changes that would happen in the network.

Yeah, you know, a large fraction of the investment that we're making has to do with PaaS 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 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 different topic, but one of the things 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 PaaS and SaaS 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 sort of self-reinforcing investments, but they 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 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 of Bletchley.

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 worked with Modum to adapt 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 Coco 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 Corda, JPMorgan 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.

Hey, I really appreciate the time and the wonderful conversation and questions. Thank you so much.