Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Marley Gray: Project Bletchley – Microsoft’s Blockchain 3.0 Architecture

Episode Date: December 13, 2016

In their relatively short lifespan, blockchain technologies have already undergone significant milestones. Bitcoin’s blockchain, often referred to as Blockchain 1.0, features a simple database ledger that records transactions in a chronological order and represents the state of the network to participants. Ethereum, or Blockchain 2.0, introduced the notion of smart contracts. Microsoft’s Bletchley Project introduces a new modular architecture which might mark a new milestone for blockchain technologies. Marley Gray, Principal Program Manager Blockchain at Microsoft, joins us to talk about Microsoft’s approach to blockchain architecture. With enterprise in mind, Bletchley introduces the concept of “Cryptlets”, the core building blocks for introducing a secure middleware tier into blockchain application infrastructure. These computational units, running off-chain, on secure trusted container enclave hardware, could provide trusted data to on-chain smart contract logic. Topics covered in this episode: Marley’s background and experience at Microsoft Why Microsoft is aggressively pursuing blockchain technologies (compared to other large tech companies like Amazon, Google, Facebook, etc) Microsoft’s Azure Blockchain-as-a-Service offering Project Bletchley, its goals and the problems it is trying to address The primary use cases in which Bletchley may provide value How Bletchley addresses the issue of deploying consortium style blockchains What are Cryptlets and how do they relate to Bletchley How Cryptlets are different from Oracles How Cryptlets could provide data to Ethereum-style smart contracts Episode links: Bletchley Whitepaper Blockchain as a Service (BaaS) | Microsoft Azure This episode is hosted by Brian Fabian Crain and Sébastien Couture. Show notes and listening options: epicenter.tv/161

This is Epicenter, Episode 161 with guest Marley Gray. This episode of Epicenter is brought you by Jax. Jax is the user-friendly wallet that works across all your devices and handles both Bitcoin and Ether. Go to J-A-A-WX.I.O and embrace the future of cryptocurrency wallets. Hi, welcome to Epicenter, the show that talks about the technologies, projects, and startups, driving decentralization, and the global blockchain revolution. My name is Sebastian Kujo.

And my name is Brian Fabian Kring. We're here today with Molly Gray. Marley is the principal program manager for blockchain at Microsoft. Microsoft, as I'm sure many of you are aware, has been very active in the blockchain space. They sponsored the Ethereum DefCon last year, and maybe this year again. Did you guys sponsor this year again? Yes. Right, twice.

And they were one of the first, or one of the first big tech companies to really get into the blockchain space. And I think Marley was a key driver in that. So thanks so much for joining us today. Your problem. Thanks for having me. So can you give us a little bit of background? I think you've been at Microsoft for a long time. What was, what have you been doing there and how did your career kind of evolve to end up where it is today? So yeah, I'm working on my 17th year at Microsoft. And I started in Charlotte, North Carolina, so which is a, banking hub in the United States and came on in the financial services vertical and I was a trading floor application developer at the time and I quickly moved to to our developer and platform

evangelism team which is essentially when dot net first came out we were going around talking to software architects and developers and explaining the intricacies of how Dotnet worked and why you wanted to use it, why it was better. Spending a lot of time doing that and then came back into financial services and ended up getting relocated and taking a job in New York City to a little over two years ago to run the innovation labs there. And that's where I picked up blockchain again, which is the first time I did it. really wasn't aware when I was doing Bitcoin.

Nobody really paid too much attention what was going on to the covers too much other than just getting your cryptocurrency working. And unfortunately, I lost my private keys from very early on. So I have some orphaned Bitcoin out there. But picked it back up in 2015 and an incubated blockchain at Microsoft in New York and got pulled in to actually build out our strategy and now we have an engineering team here in the product group within Azure, and I'm leading up the design and architecture here for that.

So what was it about blockchain that fancied or triggered your interest? Well, being in financial services, there was so much you have to do around settlement times and the pain around settlement. And the pain enterprise organizations go through when an audit is triggered. And just identifying some of the things that blockchain could solve. And really, it was the smart contracts, was the hook, to be able to define the data that you're going to share with other people, but also behavior and intent.

So smart contracts in a large degree really kicked the interest in blockchain into overdrive because people started thinking of it in other ways than just a cryptocurrency. So we started to see that more as a platform for delivering innovation to businesses and the way we do business and really break apart and simplify a lot of business processes that evolved over decades. So that's what you know really interested. First was in financial services, specifically in the derivative's market. But now it's spawned into just about every industry there is. Brian mentioned earlier that Microsoft was one of the first companies to, well, one of the first large companies, you know, the historical figure in tech to really dive in headfirst in

to blockchain technology and infrastructure. Can you describe sort of at a high level what the strategy is for Microsoft with regards to blockchain and blockchain as a service? Yeah, so we see blockchain as being very obviously creatively destructive to a lot of our, we have a huge enterprise business. And our customers are always coming to us

asking for innovation ideas or ways they can improve their outreach to their customers or their products or their processes. And, you know, we saw this as an opportunity. A lot of our customers were having a lot of desire to at least try blockchain, which initially was very difficult to do. And how do they even approach it? So, you know, our initial goal is to say, hey, let's make it easy for people to learn what blockchain is and to just get started.

And blockchain as a service, when I launched it, well, it's been over a year now, was its main goal is just to make it easy for people to stand up a private blockchain network and to start tinkering with it and learning it. We started out with Ethereum, but quickly customers wanted to try out, Ares, which has been renamed. but you know a multi-chain now we have a chain and a whole bunch of different blockchains out there so everybody wanted to try out the different the different blockchains and start to test them and that's that was the initial goal now we've greatly expanded that I'm sure we'll talk about that a little bit later now but that was that was our primary goal to

it's just to meet customer demand to allow them to do it and we felt like the cloud was a great place to do things. We called it the fail fast, fail cheap, because we knew nobody was going to build anything right out of the gate that would make it to production, that they would tinker and play and try something and fail miserably. But with that at low cost, so you just delete it and start all over again. And that was our initial design goal. I agree that sort of that fail fast model is really valuable.

Like today I signed up for Azure. I think I'd done it a while back, but I never really gotten through with it. But I signed up for Azure, like I had some credits. I spun up an Ethereum network. It took about five minutes. You just basically set it up. And it was really easy to do, right? So I can see that, you know, having set up a Geth node before on my Mac, this was much more pleasurable.

This was a much more pleasurable experience as a whole rather than having to install like NPM and Node and like all this other stuff. and that often is really complex and buggy and it takes a long time just to get you off the ground. So I think that for a lot of people getting started, I don't know if they're going in that route, but it definitely looks like something really attractive for someone who wants to play around with like multi-chain and, you know, wants to start really quick.

Yeah, so actually we were quite surprised when we were researching this to learn that Azure, the number of data centers that you have all around the world, world and how, yeah, it seems like a massive cloud infrastructure, which I really was not aware of. Can you talk about sort of, but perhaps just describe for those who aren't familiar, what is Azure and how, you know, how blockchains fit into the Azure offering? Right. So Azure is our cloud platform.

And it is really targeted initially, and it's always been targeted. at the enterprise market. And so we started to, and also our own internal systems, so our own being in Xbox Live and things like that. So we initially started to put data centers out there for initial redundancy, speed of light issues, you know, you want to have things close, geographically dispersed, and started to work with our enterprise customers, and a lot of the major concerns were not technical in nature, but more government-related. So we needed things in certain jurisdictions for data residency laws. So what we quickly found is we would build these footprints and we could put these massive data centers all over the world. But we started to find

out, oh, we need to put data centers in specific countries or specific regions. And they also have to have a fault domain within that same region. So it ended up, we, we, we, we, have over 100 data centers around the world. We're in, I think, 39 different regions, which is actually larger than our two closest competitors combined. And it's really targeted at, where we have a jurisdictional issue with enough customer, we're going to put and service our customers there.

And the interesting point is all those data centers are linked with our own dark fiber. So we actually, I think I have the second. largest dark fiber network outside of government where we live. So it's a massive dark network that you can go between data centers without touching a public network. And then we have this other piece. So this is that massive we call it hyperscale cloud to deliver computing on demand. And when we first launched Azure, we actually overshot the market.

We launched Azure with a platform as a service message where you didn't concern yourself with spinning up virtual machines. You just said, hey, I need a database. Give me a database. I want to stand up this web app. Here's a web app. And you just put your requirements in. And behind the scenes, it would make sure that you have the right resources from a hardware and storage and networking perspective. And then AWS came out with where the market actually was was.

They weren't ready for next generation applications. And so they came out with infrastructure as a service. So then we quickly followed with that. But now the markets are moving back into Platform as a Service. You're starting to see a lot of talk about serverless environments where you have this execution environment in the cloud where you can reach out and access capabilities or functions that you need. Without saying I need it to run,

on this type of hardware, on this operating system, you don't concern yourself with that. You basically say, this is what I need to do, or this is what I need. I don't care how you get it to me. Just do it within these SLA, and I'm good to go. So the Azure is that sort of worldwide network where we're delivering data based on, and meeting those restraints around data residency, compliance, security, our security and compliance portfolio is the best in the business. So when you start to look at putting things in the cloud,

you have to have all those. There's a long list of checkboxes you have to go through to get enterprise customers ready to start putting data in their biggest processing workloads out there. And we're starting to see customers moving en masse certain workloads and we'll see more and more go through. So net new applications, we're starting to see being built with cloud in mind.

And lastly, Azure is also hybrid, so you can run something called Azure Stack, which is an on-premises private cloud, which looks and feels and behaves just like an Azure process. It's like sending up your own data center or Azure Cloud in your own data center, and it looks like a region, and it can burst out to the cloud for more computer,

resources or storage and things like that. So it's that hybrid on-prem and public cloud, if you will. Cool. Very interesting. And you mentioned before that part of the reason why you guys got into blockchain was that a lot of Microsoft's clients, you know, they wanted to try out blockchain and they were sort of looking to you guys to make that easier. But is there a larger thesis that Microsoft has about, you know, where technology, enterprise software is going over the next maybe decade, two decades, that informs how you guys are approaching blockchain. And maybe not just right now when it comes to this experimental phase, but also beyond when we're going to go into production and actually, you know, big applications run on blockchain

systems. blockchain itself is forcing sort of a business process for reengineering effort across industries so because we're dealing with the enterprises these enterprises are are moving away from business processes operating within their own four walls which is hard enough as it is getting interoperability in a large organization across applications but now saying I want to be able to have that same interoperability between my most fierce competitor and throughout an entire supply chain. How do I do that? And before you really didn't have that option because you didn't have a shared truth like the blockchain,

to be able to share that data and have one place to go for reconciliation to see where the business process is that crosses organizational boundaries, which is essentially everything in this global economy. And it touches every industry. So with that, we said, okay, well, kind of backed into the cloud being. And blockchain initial, at a first glance, people said, well, why would you do blockchain in the cloud? And at first it does seem counterintuitive. But if you think of what the cloud is, the cloud is essentially a massive distributed.

system. So we're in these massive data centers all over the place. But you're, you have different levels of distribution, right? You just, you distribute things for different reasons. You distribute things for disasters, right? I don't want to have all my data centers in lower Manhattan. And that happened in 9-11 and that was a problem, right? So you need to have redundancy outside of the geographic area. You need to have data residing in different areas. areas. So there's a lot of that flexibility. But once we started looking at that, we said, okay, customers are going to start wanting to move to what we call the collaborative economy, where you work with each other and it's a part of the business process. So cross-organization,

distributed workflows is if we look at supply chain, it's a very complex business process. Lots of infrastructure required. It is a ton of overhead. It is a ton of overhead. and friction in any supply chain, whether you're manufacturing a product and getting parts from a thousand different suppliers, which are actually cascaded down to smaller suppliers, or you're producing a movie. Very similar, you have a supply chain. And how do you manage that? And then how do you audit that? And we saw that as a fundamental shift to provide not only that, false organizational workflow and shared data and shared execution and trust, sort of distributed trust.

But then it sort of changes everything on the back end too because now you have visibility into your business processes and where they're inefficiencies. You can catch fraud a lot easier. You can optimize a lot better. So, you know, our customers initially. stance is, hey, we're rethinking the way we're actually doing this business process that we haven't revisited in 20 years with this technology. So we think it's a fundamental shift, and we're really ramping our platforms to work in this distributed. It's not just data distribution. People think too much

about distributed compute, distributed data, but really it's distributed trust and moving, looking at your your business processes and distributing them, but having visibility of where they are at any given time very seamlessly. I think that's a great way of explaining, right? Essentially the underlying thesis that is in a big part of the blockchain space, you know, that was sort of the thesis or the Issa thesis at Eris Monax, but all kinds of companies in this space, right? Like the whole Ethereum for business, or even, even.

the public theory is also about exactly that process automation stuff. But if we agree that this is the big trend that is going to happen, I would be really curious about your perspective. Why are the other big tech companies like Google, Apple, Amazon, maybe Facebook, are they doing something, but they just don't talk about it? Or do they have a different thesis? that means they don't see it the same way and they don't feel like they have to take action and move in this direction? What do you think?

Well, I think it has more to do with the DNA of the organizations. If you look at the two big tech companies that are doing a lot in blockchain, it's Microsoft and IBM. And we're firmly rooted in the enterprise. Even though blockchain evolved out of a cryptocurrency, so you have this sort of why quickly jump over to enterprise, It's because it solved a problem in a very unique way and stood the test of time, even though people shot holes in it. And then the enterprises quickly said, wow, this is going to change.

This could change how we do business completely. Some of them, when they fully understood it, depending on the business, they either have a near-death experience, meaning that they're a middleman and they don't provide much value, other than friction into an existing business process that could be completely disanimated. or they saw opportunity. And usually companies see both, opportunity to reinvent themselves. So a lot of companies we've talked to in the enterprise,

they see this as a catalyst. It's not pure technology. It doesn't solve every problem, but it provides that catalyst opportunity to revisit because Microsoft and IBM are so focused on delivering value in the enterprise and working with businesses on different ways, right? So IBM really has a massive human services business where we're really focused on the software.

We're not trying to sell consulting services. We rely on our partners to do that. But that's why you saw us doing that. I think the reason you're not seeing AWS and Google is they don't have that enterprise focus. Amazon will probably, I mean, I can't really speak for where they are and what they're doing. but I think that's why you see sort of this while we got out front. Will they catch up? I'm sure they will once you get into that.

But the actual customer demand, we're getting it from these enterprise customers, and that's why we went first. I'd like to say we're so visionary, but it's really a little bit more simple than that. And do you think that's going to remain like that in the near medium, term future that the most activity and interest is on the enterprise side as opposed to the consumer facing side? I think it will. I think the evolution of the two will come. I think what we're going to go through is that enterprises will spin up, distribute the ledgers, and there'll probably be a bunch of them. The public ledgers will provide an interesting backbone, and that will start to see interoperability

happening using the public network as a bridging mechanism for assets, you know, traversing between blockchains, for example, or even smart contracts to bind themselves together, even though they have no awareness of the other network. So the public networks become very interesting, sort of utility, common infrastructure, and then these consortium enterprise blockchains, you know, tapping into those I think is a very interesting way to see this evolve and eventually get to the point where we flatten these things out and we have this ledger that even though it's not one ledger we don't have this one massive worldwide database that has an identity for everything and tracks every business process but we have a way to navigate a hierarchy or a mesh of these these blockchains or

or distributed ledgers as they evolve. So I think we will see for the next couple of years, just from a effort and where people will be making a lot of vets and being employed and looking at solving hard problems. I think it's going to be an enterprise first. I think, you know, everybody's still sort of waiting on that consumer-facing, you know, Uber or Airbnb scenario. But, you know, if you look at those things, I think it might be, those things will pop up once you get industry-specific blockchains. And then those will be ones that cross those industry blockchains to solve a unique problem that involves financial services, healthcare, and IOT, for example.

That would be a killer app. It's really the composite of this. So we're just building basic plumbing now within single industries. And once we start going across the industry, that's where you see, we'll start to see these really killer apps that come out, I think. Now, before we go into Bletchley in a little bit more detail what Microsoft's, you know, blockchain efforts going to look like, I wanted to bring up a concern that I think a lot of people have. and I saw that mentioned somewhere, maybe there was a comment in front of one of your talks as well.

So one of the central premise of blockchain is this idea of decentralization, decentralized control, decentralized processing. How does that play with something like Azure, which is a centralized infrastructure provider that really also lives on economies of scale? Do you think, you know, what's the role here in terms of while the technology is being developed?

And how do you think that's going to change when some of this technology and these blockchains are going to go into production? So when we talk about blockchains in Azure, we say you don't, most customers aren't going to run their entire blockchain in Azure unless you're just doing devintest, right? When you're going into production, very few enterprises, even though they love us and they want to use Azure, from a risk standpoint, they want to spread. their risk. So they'll say, well, we need to have multiple providers of this network. So you

would put a certain number of nodes in Azure. You could put certain number in AWS. You have certain in your data centers. So when we look at the blockchain layer itself, because the consensus algorithms and the database gets propagated and validated between nodes, regardless of where they live, that's the model that we would love people to have all their nodes in blockchain but that's not the reality and so we don't have any dependency you can actually use bletchley without having a single node in Azure and just call up to those services from wherever you are because it's just something out there in the cloud So when we say, we look at Azure as being the distributed sort of fabric for that sort of distributed execution model and not necessarily the place where the ledger exists, even though Azure is a distributed system. I mean, it's all around the world, but like I said, there's different levels of distribution.

In that case, you might have a, you know, enterprises need to make sure that they spread their nodes across multiple providers. And it's really against multiple counterparties because you might have certain counterparties and a financial services blockchain that aren't Azure customers, for example, and IBM. Those nodes will still work on the same network. Let's take a short break to talk about Jacks. Jacks is a multi-coin wallet created by the people at the Central. Now, in the past, if he had a whole bunch of cryptocurrencies, it was a pain to handle them. You either had to leave them on an exchange, which was insecure, or you had to have all these different wallets, which was a hassle. Fortunately, now with Jacks, those medieval days of darkness, misery, and suffering are over.

Jack supports multiple cryptocurrencies and new ones. are being added. But it's not just storing cryptocurrency you can do with Jax, but you can also exchange them directly from within side the wallet thanks to their shape-shift integration. And since there's only one seed, Jax makes it super easy to back up and sync to the other devices. Jax works with Windows, MacOS, Linux, Android, iOS, and has browser extensions for Firefox and Chrome. So go to Jax.io, that's J-A-D-W-X-I-I-O to download the wallet and get some. started today. We'd like to thank Jacks for the supportive epicenter. So moving on to Bletchley, there's a white paper that you authored, which is available on

GitHub. We'll put the links in the show notes, which is called the Bletchley white paper. And in this white paper, you discuss sort of the evolution from blockchain 1.0 to blockchain 2.0, the blockchain 1.0 being the sort of Utexo Bitcoin-style blockchain, and then moving on from that, we saw the technology evolve into smart contract languages with Ethereum and now into a new era, which is what you're calling blockchain 3.0. Could you talk about the evolution between these different versions of blockchain technologies? Sure, yeah. So UTXO was built for a specific use case.

So it was built specifically for a cryptocurrency, which is essentially provenancing a cryptocurrency, transferring ownership, and being able to make change. So, and it was built, and it does that very well. And it's, we like to think of UTXO if it's, if your, if your applications are only dealing with bare instruments. So you're proving ownership, proving lineage and transferring of assets, then that model works very, very well. But it's somewhat restricted because an individual Bitcoin doesn't have an ID. It's just a sum of UTXOs.

And when you spend a Bitcoin, it's no longer the same. It's just spread out as other UTXOs. Well, when Ethereum came out and they introduced smart contracts, it introduced some key innovations. The first of which was it had an identity. So a smart contract is essentially an account that persists. So I can have an address and assign an identity to something. So I know it's going to be there.

And I can also define schema, whereas UTXA system, you're essentially, I mean, you can have properties in your transaction and asset, but it doesn't have a strongly typed schema, which we found very interesting to be able to do. define, define schema, and then it can have behavior. And the behavior piece was, the smart contracts piece, but I'd argue that it's actually those three things together, the identity, the ability to have schema, and then having code or logic there.

And that was super interesting in that you could start to write these programs and do interesting things. As an enterprise developer that grew up in that, well, I went from writing client server applications to having to write three-tiered applications and learned some painful lessons about how we managed state and scale and separation of concerns to make sure that you can version things independently. And we learned a lot of painful lessons in the 90s in the early 2000s about how to build web applications that could, that could, that could, that could, scale and and and and and serve the internet so we looked at smart contracts today this is a great way of of really doing other things on a blockchain however i don't think it's going to scale

to you know massive even private blockchains that have millions and millions and millions of smart contracts running on the network at once so immediately just went and said, okay, let's decompose what a smart contract actually is. And if we look at that, it's, you know, you define your schema, which includes the properties that you're tracking. And those could be, the example we always give us with a loan. So if you take out a loan, maybe it's a mortgage. You'll have a amount you're borrowing. So that's how much you're borrowing. You have an interest rate. You have a term. And you'll have a, and that interest rate could be variable. So you could get a fixed length one, and then that's the case, then it doesn't change.

But you can have a variable interest rate. And then you have some rules about what's your payment, when's it due, what's the penalty if you pay it late, and then what's the big penalty if you really go late about foreclosure? And those are basically legal clauses. And at the end of it, if you've ever taken out of the mortgage, you get an amortization. schedule, which is essentially predicting your future states. If you make every payment, this is how much principle is going to be over a 30-year period if it's a 30-year loan.

Now, if it's a fixed floating interest rate, that amortization schedule can vary based on how your interest rate can go up or down and things like that. But that's essentially a contract. And we said, okay, what portions of that need to be, if I was going to take this, this smart contract is said, I don't want all this stuff to be bundled into this one piece of code data all intermingled on a node. And when I have a thousand node network, that smart contract runs a thousand times to do the same thing. I don't necessarily need that kind of behavior. I want to be able to take out portions of it. So we said, okay, what if you could say

keep the schema, keep some logic that just validate your data. So like store procedures like type of behaviors for relational databases, where you're not putting business logic, but you're just validating inputs before you commit to the database. So we could validate signatures and things like that. And then record the basic static properties, like the amount you're borrowing, the signatures of the lender and the borrower,

those are important to capture. But then the clauses themselves, the payment, the rate that might need to be recalculated, and then the conditions of is it late or not, and then how does that payment apply? That logic can be pulled out and executed somewhere else, as long as we can execute it, and then attest that it actually does what it's supposed to do. And we can guarantee that. it will run. So that's, we said, okay, let's, let's talk, think a different differently about defining what a smart contract is. In a sense, it's taking what UTXO base systems always did, right?

They didn't have a smart contract to define schema. They always built these, uh, applications on top that had all the business logic. Uh, but they were schemas on the bottom and it's hard to share that stuff across without using op codes and things like that. Whereas this is a little cleaner and it, it, And it feels like it is built sort of for enterprises for me to have strongly type schema, some logic that can execute in the smart contract to validate my transactions. But then raise up any logic that doesn't necessarily have to be on the blockchain and can be running a shared environment by all the counterparties and get better performance and scale and all that good stuff. Okay, so I think you've sort of started to explain with your answer what we'll get to in a bit, which is Bletchley. But if I could just rephrase that in the way that I conceptualize it, is that with this idea of blockchain 3.0 that Bletchley introduces, what you're essentially doing is rather than having all of your smart contract logic,

state, storage, and the distributed network within one system, which is essentially what Ethereum does, you decompose those components. So you decompose the business logic, you decompose, you take out storage and you take out state and you take out all those components. You split them up. And then once you have that base architecture, right, where, all of those components can be sort of modularized. I mean, sort of like application development today, where you have your database over here, you may have cloud storage over here,

you may have some other component over here, and they all interact together, but you're building this sort of modularized system. But then the other component that this introduces is this idea that rather than trusting all of this to a distributed network where it's completely trustless, you can sort of pick and choose with every component, where's the cursor, right? So if you want your storage to be fully distributed, you can rely on a fully distributed

blockchain type, you know, public network to do that. But perhaps some of those functions feeding into those smart contracts don't need to be fully distributed. You can trust some sort of trusted source to execute that logic and provide results. And that's okay. And the people, you know, the participants in that network agree on that and like some interest rate, for instance. Is that sort of a good representation of what Bletchley is trying to do? Yes. Today's magic word is Bletchley, B-L-E-T-C-H-L-E-Y. Head over to Let's TalkBetcoin.com to sign in, enter the magic word, and claim your part of the listener reward. So then let's talk about the architecture. Describe the Bletchley architecture for us, if you may.

Sure. So at the bottom, when you provision one or more blockchains, and so you can use Ethereum, you could use chain, you could use Quora, you could use whatever. You can actually use multiple ones. So above that is this thing called the Cripplet fabric, which is actually, Actually, right now we're running in what we call Azure Service Fabric, which is essentially a cloud runtime that abstracts behind it. It could be X number of Linux VMs and X number of Windows VMs, depending on what you're using. And they're sort of abstracted from you.

It spins up more and more resources as you go along. And it manages the instantiation, life cycle, and fault tolerance of companies. components that are running in it. So this is that serverless environment that provides the runtime, which we call the cripplet fabric. The cripplet fabric itself, it is that runtime of you register blockchains with it. You build cripplets to run on top of it, and cripplets are these discrete levels of functionality. There's different types. We have utility cripplets, which are usually thought of as Oracle-type cripplets or Oracle cripplets. We have contract cripplets, which are taking that logic for a specific smart contract and executing that. And within contract cripplets, there's different types of contract

cripplets as well. But those are the two basic types. And you have the option of running these cripplets and an enclave. So they can run in a secure, isolated tamper-proof environment that attests to their results so that they run and did what they say they did without you having to put the code on the blockchain, but rather just the attestation of the signature for guarantees that your logic ran as intended. So and then above that, so the cripplet fabric exposes a sort of an event-driven API to blockchains underneath it. So you can subscribe. If you have a smart contract, you can subscribe to an event. So like a market price every X minutes, you can set. So time-based, you could set it as a threshold.

So let me know if oil goes above $40 a barrel or below. And when it does, give me this price and this index. And then I'm going to do something on my smart contract. Or you could do it based on. So that's threshold. You could do it the other way around. You could also have them subscribe to events just like your CRM system. So maybe your CRM system feeds into a KYC.

service that you're using. In an event that might happen in the CRM, you want to flow in to your KYC system to update your know-your-customer system that you have there. So there's a whole bunch of, that exposes a surface level API as well. Above Criplets, where you can expose a Criplets functionality to a front end or another system, can invoke a Cripplet from the top and have that transaction flow to the bottom. The other key piece, that the cripplet fabric does is it abstracts the underlying distributed ledger

from the cripplet. So the cripple has no notion or no real idea. It has no dependency on a specific blockchain. It's just running trusted executed code and sending out signed JSON payloads which then get additionally

signed by an alaclave if necessary. The cripplet fabric then as it routes, it has bindings. that will format messages for Ethereum, chain, Corder, and the like. So it provides that abstraction for developers to not have to, especially if you're writing reusable components, which is interesting, you can write these things as a cripplet

and have it work across all blockchains and not have to write one for each blockchain, which makes it simpler. Maybe an example for this. I remember once I talked to, we talked with a bank and they mentioned the issue of an interest rate swap, right? And the thing there is that there are some calculations that you want to be done, but, you know, calculations putting on a blockchain doesn't work very well

because they're just, the performance isn't nearly good enough. So that would be a good case, for a cripple, right? So you would define that function, you get executed on a cripplet, and you can verify, you know, as participants on a blockchain, you can see what was run in that cripple, You can see what data was used as input, what was the output. So, you know, I could potentially run it myself, check it. So you have, you know, you have lots of performance benefits.

And potentially, as you mentioned, right, you could have that cripple as its own sort of standalone, almost like application providing kind of an API. So if we use different types of blockchain, you could always plug into that same thing. Is that, that's kind of the, what can this make possible, right? Yeah, and you could also keep that algorithm secret. So you run it faster and you might have an IP in that algorithm that you don't want to share. So yeah, it allows that as well. So if you kept the algorithm secret though, then, you know, I would be able to see the input, the output, but I wouldn't be able to replicate, you know, if I was some other participant on the chain, I wouldn't be able to.

to replicate that, right? Right, unless you subscribe to that same service. So from a, and as far as the writing of the blockchain, you're just writing a value down. And you can, depending on the level of trust that you have, so some counterparties entering to those things, that's perfectly fine with them. They trust that algorithm.

Maybe it's coming from a third party, so it comes from a Reuters, for example. And they say, yeah, we're just going to use that. And we trust it. It's going to sign with the signature. That signature is actually based off the hash of the code that we all reviewed. So we can attest that, yeah, it ran the code that we all reviewed. And that's the output.

So we trust it. But maybe it runs in a co-located space for optimal performance and things like that. So the Ripple guys once did this project, which was shut down called Code Use, it sounds very similar to Criplets. Is it some of the same ideas? Or how did they differentiate? Yeah, Coteus heavily influenced the first approach.

Well, actually, the second approach. The first approach was for contract cripples. So how do we pull logic out of the smart contract while keeping all the goodness of smart contracts in the blockchain? Codeus was how do you do secure attested oracles? And so when we looked at Cody, I talked to the guys at Ripple, and it was abandoned because it didn't have the ability to scale this, right? They weren't a massive worldwide cloud provider to stand up this infrastructure. And, you know, said, hey, we are.

I think we could probably deliver something like this. It's not, we don't have the hardware yet, but it's coming. And let's go ahead and build the infrastructure such that there's a lot of people that, you know, have value to inject in these systems and give them a platform for exposing Oracle-type behaviors in a Criplet that then enterprises are comfortable consuming because you could have the best Oracle in the world, but if the enterprise that doesn't trust you, they're not going to use it. So how do we empower the smaller innovators and the software partners that we have and marry them up to these large enterprises that want their capabilities, but don't know how we can't

have that marketplace to bring him together. So this idea of a cripplet, I mean, it is some sort of an oracle, right? To a smart contract, anyway, the smart contracts use it as a source of data that the participants need to trust. And before the show, we were talking about how that works. Can you explain for those who are saying, I mean, I can hear the Reddit comments and Twitter comments already where people are like, you know, this is just, you know, non-trust. the data being fed into a smart contract, this is ridiculous. Can you explain how a cripplet

can provide a trusted source of executed data? So if you take a cripplet that would execute some function, like calculate some sort of a, maybe we can get into some use cases, but a cripple that calculates some sort of a rate, which would go into a loan contract. How can the participants trust that cripplet? What is the software and hardware configuration that enables them to trust it? If I'm a smart contract developer, and I'm going to use an Oracle Criplet or a utility cripplet, meaning it's going to provide me some result. It could be just a raw market price, or it could be a computed value that I just need to have for my smart contract.

Well, when I do that, I essentially make a reference to that smart contract that I can find, I mean, to that cripplet that I find in the, each fabric has a cripplet explorer where you can discover cripplets, what they do, and you could subscribe to them. The subscription process is essentially creating a binding between your smart contract and the cripplet. The requirements that you have when you're binding in that way is you have to have a callback function. is this an event. So it's a Pub Sub model. So the smart contract is subscribing to that. And it wires up the trust that says it's only going to accept messages from this cripplet address. So the cripplet signs, it has an identity and it signs its messages with that signature. So you can trust it. That's just one level of trust. The cripplet can also be run in an enclave. Like I said, it could be if you want that level.

Not every cripplet needs that for most utility cripplets, unless it's doing in cryptos, it's probably not worth doing it because you really have any secrets there you're just sort of unless your algorithm secret then you want to run it in an eye club you can but essentially that you subscribe to it you say these are my this is what I want you to let me know let me know if the markets were open that day and it's 4 o'clock eastern standard time I want to note 9 a.m. Eastern standard time and 4 o'clock Eastern standard time I want to know it 9 a.m. Eastern standard time I want you to give me the LIBOR rate and the price of this commodity or this list of commodities. And so the cripple will say, okay, I'll let you know. And the cripplet goes out and runs. It runs

in the fabric. The fabric makes sure that that cripplet is running, that there's always an instance of it that will fire your event. If something goes wrong, it'll fire up another instance so that you're guaranteed to get that event. It will evaluate the conditions of the event you subscribe to, And if it's true, it will get those values. It will sign its payload. If it's running in it, it will send that message back through the, back through the cripplet fabric, which will send it into the blockchain. In that case, it's sending it, you only have to send it successfully, item potently, if you will,

through a single node that will go to that smart contract. and then that will get executed and sent around the rest of the network. That's the simplest mode. That's the Oracle contract. Previously people would do oracles and they would inject oracles to a separate smart contract, and then your smart contract would watch that other smart contract, and you would look at local events on the blockchain. This is more saying, okay, I'm delegating that PubSub model,

where the events can happen out in the real world and be injected directly to me so that I don't have this other smart contract out there and this intermediary that's there. You can still do that. There's nothing stopping someone from doing a queuing mechanism like that for a smart contract and a cripplet as well. But you can do that straight binding between a smart contract address, a callback function, and the cripplet. for an Oracle Cripplet. So that's that's the, sort of the, that easy, the easy case. The, the contract cripplet is, or a control cripple is the pattern we call, is where you're taking that logic out. You're not just getting, in the previous example, you're just getting a market data price or some calculation performed, and then you're actually executing other logic on your smart contract

and, you know, persisting that. If we don't need that to happen, if we can, if we could actually do all of that logic and just write the results back. We can then upshift and move all that smart contract code up into a Cripplet. And the Criplet can then have a subscription to the market data Cripplet that's maybe firing that event. So Criplets can talk to each other. So I can subscribe to other Cripplets events that might be providing Oracle capabilities. So it would give me it signed payload. And then I would execute my logic for my specific. smart contract in that cripplet, and then write the results out. Now, contract cripplets are mostly, usually going to be running an enclave. So the enclave will attest that

it ran in the enclave, unmodified, and the results are guaranteed, and write that back down to the blockchain. So at the blockchain, you'll have the results of the computation of the smart contract, and then you'll have the signatures of the cripplet and the enclave. So you'll be able to have that full trust audit capability between the counterparties, which is how a contract cryptlet will work. Okay. So it really all comes down to the level of trust that you have in this cripple. I mean, I think that for a lot of enterprises, this will make sense because we're operating

in a system that. or there are rules and regulation. And enterprise tend to trust each other when they are operating within the blanket of regulation. And it seems to me like you can then, based on your needs, on the specific use case that you're building, you can set that cursor for trust, right? So if you need specific application logic to be distributed, because we need to be operating in sort of a trustless way amongst each other, and these specific functions need to operate on a blockchain because that's the only way that we can achieve this trustlessness,

then that will suffice our needs. However, for other functions or other pieces of data, rather than relying on, say, like, a prediction, market to retrieve the data, we're going to rely on a cripplet operating on an enclave, where we have the audit trail for provisioning of the keys, provisioning of the business logic and functions themselves. We can trace that. We know it's happening on an enclave. So there's a high, you know, there's a high likelihood, there's a low likelihood that that will get hacked or, you know, there's exploited. And then, so therefore, we have a high level of.

trust in those results because we're operating in this formalized, regulated ecosystem or framework. And where do you think this will go then? Because it's quite a ways away from, intellectually, from Ethereum. Yeah. Or blockchain technologies, sort of a distribute, everything distributed, you know, the application stack with Ethereum, IPFS, Big ChainDB, you know, we're, we're completely trustless. That's quite a ways away from that.

But it seems like it's enabled by technologies that perhaps aren't available yet, like that are not really commoditized, such as enclaves. Where do you see that going? Like where do you see this going in the next 10 years with regards to how, sort of blockings? chains and these centralized technologies, but highly trusted technologies, how will they interact together? Yeah, I think it's a really good point. I mean, that's a design choice. And what we're trying to do is inject that design choice in there.

So if you are on a completely trusted environment, having your logic in the smart contract is the most appropriate way for you to do that. But in these semi-trusted environments, which these consortium blockchains are, This gives you that design, as a software developer and an architect, you go and say, well, where's the right place for me to do this based on the requirements? And sort of move it based on that trust pendulum, but also on the privacy pendulum. So, again, if you have algorithms that need to be private, if I have very complex counterparty, multi-counterparty contracts where each counterparty has to maintain secrets

while validating the state and participating in transactions, the cripplets provides a great framework for doing that. So I think what we'll see is as we start to roll out the cripplet fabric and you'll be able to spin up enclaves on demand. So as a developer, you really don't have to think about, I don't know how to write an enclave for this chip architecture. It's simply a property that you checks. Is it enclave or not? And your cripple, it's actually getting all of its services from a wrapper anyway. So you get that and it's sort of commoditized and easy to do.

Now as we start to roll that out, we wouldn't want you to put everything in an enclave if it's not required because it is a more expensive. It will be a more expensive because it's an option. So you want to do it kind of selectively. But it's a good tool for doing that. I think as it rolls out, it becomes more and more commodities. We'll start to see enclaving being used not only in the cloud, but on desktops and on mobile devices as well. So we already have enclaving on phones, a good bit.

We have it on most Intel desktop PCs that are Generation 6 have, enclaveing capabilities, whether or not the bias supports it or not. So we'll start to move this type of secure execution will come more and more prevalent. The differences in the cloud is it's on demand at hyperscale, and you only pay for what you use. You don't have to go out and buy all these hardware and stuff. So I think it's going to help the evolution of applications, and we'll start to see more capabilities come together, but you still sort of need that.

We get the best of both worlds. So as a developer in public Ethereum, you can then start developing enterprise applications but still use a lot of the same tools. You approach things with a very similar mindset. The difference is, as you start to say, my logic is distributed different than my data in my state. And it's done at different trust levels, whether it's completely trustless or semi-trusted

to very discretionary trust in the execution layer. Cool. One of the main ways of monetization, as far as I understand with Azure, is simply that I'm putting my application on Azure. I'm using up some computational resources and I'm kind of paying by the computational steps. I can certainly see how that will continue to be a role, right?

You say, okay, we make Azure the best platform for blockchain applications, and that way we're going to get more usage. But are there also some novel different business models that you guys see emerging with blockchain on Azure? Yeah, I mean, so for Bletchley, we spent a lot of time talking about cripplets, but there's also some core cripplet libraries that will be shipping, and these will be,

that we're exposing in Bletchley. And these are the ones that are most commonly asked for. One is identity. So that is identity and key management. We kind of pair together because they're very similar. So we have an Azure, we have something called Azure Active Directory. We have over 800 million unique identities within Azure Active Directory. It's the standard for enterprises to use active directories.

It does federation. It has a lot of things out of the box for you, multifactor authentication and things like that. So we're going to be providing that as a library, as a service for distributed ledger. So it'll be a part of the cripplet fabric. And key management as well. So issuing keys, managing the life cycle of keys,

like key expiration, key renewal. These types of things are pretty hard to do. We've got a lot of experience in doing that. And you tie that with action. the directory and you start to have the ability to provision keys based on someone's identity and start to provision things remotely. So you can have nodes join a consortium blockchain. As long as you have the right credentials, you can have a node join a particular blockchain.

And the certificates for that node to participate in that will be delivered through that same infrastructure. So we're actually standing on the shoulders of giants here, that stuff that's evolved over 25 years. So Azure Actory Directory is a piece of that. The other piece is the key management, something called Key Vault, which is our globally distributed to HSMs. The other one is around cryptographic services. So we'll have libraries out there available to you.

If you want to use homomorphic encryption, zero knowledge proofs, all sorts of things will be libraries that are available there, as well as a more distributed application patterns. So we call those gateway services. So things like the BTC relay for Ethereum to Bitcoin, that can be put in that gateway. You can write your own multi-block chain integration pieces, but it has a distributed transaction coordinator. And it has a distributed ledger resource transaction compensation. So if you've ever seen how resource transaction happens, and compensation on a relational database,

it can roll transactions back. We can't do that on a blockchain. So we have to post corrective transactions. So it's a modified version of that. But those enterprise development patterns for complex transactions are being exposed there. And those, again, are things that evolved through products like BizTalk. And to allow your blockchain systems to work with the rest of the enterprise, whether you have an enterprise service bus or any type of product to plug it in.

make it a first-class citizen on these networks okay cool well marley we're at the end of episodes so but thanks so much for coming on and sharing a bit about microsoft's vision when it comes to blockchain and the work you guys have been doing with bletchley thanks yeah i think it will be very interesting to see you know not just uh how this plays out once enterprise has really utilize some of these tools that you guys are building that others are building and And then we're really going to see how that transforms the nature organizations and how they work into fabric of business processes down the line. I think that would be very interesting to see.

So we have with that way at the end of our episode. We are episode as part of the Let's So Bitcoin Network. You can find this show and other shows on let's talk bitcoin.com. And of course, if you want to help the show, then please leave us in iTunes to you helps new people find the show. So thanks so much for those who do that. And yeah, with that, we're at the end, and we look forward to being back next week.