Project Bletchley Cryptlets: Microsoft Targets Blockchain Smart Contracts
I wrote about Microsoft’s Project Bletchley a few months ago, noting that it indicates the company’s intent to be a major — if not the major — player in blockchain. In the piece, I discussed Microsoft’s insight that, if blockchain is truly to become the major presence in FinTech and commerce that everyone predicts, it will require a far more sophisticated ecosystem than is currently envisioned by most blockchain proponents.
Project Bletchley is made up of three elements:
- The Azure Marketplace. This will offer smart contracts to users, allowing them to gain the benefit of a blockchain-based transaction system without the headache of creating it from scratch
- Blockchain Middleware. This is a set of helper services that will aid enterprises in embedding blockchain contracts in a supporting computing environment. Examples of such services are cryptography, machine learning, and identity and key management.
- Cryptlets. I quoted Microsoft in describing cryptlets: “Cryptlets are off-chain code components that are written in any language, execute within a secure, trusted container and communicated with using secure channels. Cryptlets can be used in SmartContracts and UTXO systems when additional functionality or information is needed and provided via a “CryptoDelegate” or adapter.”
Of the three, I identified cryptlets as the most intriguing aspect of Project Bletchley because, as the Project DAO debacle illustrates, writing and running smart contracts is really, really hard. However, the discussion of cryptlets in the original Bletchley white paper is relatively abbreviated — more of a placeholder than a real description of them.
Want to understand smart contracts better? Download this free white paper.
Microsoft has now addressed that shortcoming with a new white paper focused on cryptlets, and this paper is a signal of just how serious the company is regarding its blockchain ambitions. The paper goes into much more depth about how cryptlets operate and show how Microsoft has carefully thought about how to address many of the challenges associated with smart contracts.
Utility Cryptlets
Microsoft defines two types of cryptlets: utility and contracts. The difference between the two is mostly usage; utility cryptlets are general services that offer events that may be consumed by any smart contract. For example, a utility cryptlet might publish the NY Stock Exchange closing price of a given stock by placing the event in a message queue. Any smart contract that needs this information could subscribe to the queue and use this information (see the section on Security and Isolation below that describes how a utility cryptlet can guarantee the accuracy of this information). Here is a figure depicting how a utility cryptlet operates:
Contract Cryptlets
By contrast, a contract cryptlet is dedicated to a specific purpose. It might represent a futures agreement, which represents the opportunity to buy something at some future date. It might represent an agreement for a property lease between a landlord and a tenant. A smart contract is an agreement between a selected set of participants (which can be two or more parties) and therefore is dedicated to them. Consequently, it is customized to represent their identities, interests, and commitments (e.g., to keep a leased building properly maintained).
In this figure depicting what Microsoft refers to as an event smart contract, the smart contract receives notification of a given event; for example, as the price of a commodity upon which a futures contract depended, the contract has a callback function that is triggered when an event occurs.
There is a second type of cryptlet smart contract called a control contract, which I will discuss a bit further down after describing the benefits of the cryptlets approach.
Cryptlets: Accelerating Smart Contracts
OK. So Microsoft has created this cryptlet concept and has now published more detail about how they work. Why is this noteworthy? Well, here are three things that cryptlets offer that are important in the world of blockchain smart contracts.
Convenience
If one stops to think about smart contracts for a moment, one thing becomes obvious: they’re complicated. Today, smart contract developers are expected to capture legal agreements in a computing language, which is challenging enough, but they are also responsible for ensuring the contracts can communicate to any other entities that are involved, not to mention for the overall operational security of the contract and any external parties involved. That is a steep challenge.
Microsoft addresses this by providing a cryptlet SDK that implements an operational framework offering secure communication, event handling, general contract setup, keypair handling, and cryptlet registration. In other words, the SDK handles most of the plumbing, allowing the contract developer to focus on the value-creating part of the smart contract: the operational logic.
The power of frameworks is enormous. Simplifying the job of developers can lead to strong network effect — as developers adopt a framework, it becomes a de facto standard, enticing new developers addressing a given domain to use the same framework, which eventually results in enterprises standardizing on the framework, which leads to…heaven, for the framework creator. One has only to look at the history of Java Enterprise Edition (or, indeed, Microsoft’s own .NET) to realize the benefits of owning a domain’s standard framework.
Efficiency
The enthusiasm for smart contracts and their potential often overlooks practical issues associated with their operation. If one envisions a future of hundreds of thousands of businesses running increasingly complicated business agreements via the mechanism of smart contracts, it’s obvious that enormous processing power will be required.
Moreover, the common smart contract topology assumes that smart contracts are distributed to each blockchain execution node and every contract action is performed on each node. Clearly, this is extremely wasteful, not to mention complicated due to processing latency — some nodes will update contract state quickly, while others with less processing power or memory might not process the contract event until much later. As a practical matter, this approach to smart contracts is unlikely to scale should the rosy future envisioned by many blockchain enthusiasts come to pass.
Microsoft proposes rearchitecting the smart contract topology. Instead of the smart contract logic residing on every blockchain node, cryptlets move smart contract processing onto centralized nodes that execute contract events. What resides on blockchain nodes is contract state so the contract processing load on these nodes is far lower. Contracts themselves have to be restructured so that the contract state machine residing on blockchain nodes can receive contract data updates.
Microsoft has implemented this distributed topology approach in open source so that anyone can serve as a cryptlet execution provider. Part of the configuration of the SDK framework is to identify where the node-based contract portion should communicate for state change updates, so that the cryptlet execution can be placed wherever the contract creator desires: Azure, another cloud provider, or even on-premise.
Here is a figure outlining the distributed contract topology, which is associated with a control contract:
As one can see, the node state machine has a “CryptoDelegate” that know how and where to connect and communicate to send and receive data to the execution part of the contract cryptlet.
Clearly, cleaving smart contracts between state and processing goes against current assumptions of how smart contracts are designed and operated, but it provides a smarter method to ensure sufficient contract processing resources are available and simplifies smart contract operations as well.
Isolation and Security
The third aspect of cryptlets that Microsoft addresses is execution isolation and security (and this aspect applies to all types of cryptlets, not just contract cryptlets). One of the difficulties smart contracts confront in the real world is how to ensure that any events they depend upon are trustworthy. This is sometimes referred to as the oracle problem: if there is an oracle that is the source of “truth” (e.g., the closing price of a stock on the stock exchange), how can one know that the oracle itself hasn’t been tampered with and is therefore emitting an incorrect closing price.
The cryptlet architecture addresses this in part via the SDK already described — it will ensure that all communication between a smart contract and an external data source is cryptographically secure. But the architecture goes much further than that. It envisions what it refers to as “enclaves,” which are cryptographically secured containers operated by a trustworthy party. Enclaves can be operated on hardware-based cryptographically secure environments, allowing smart contract users to be confident that an oracle has an impervious execution foundation. Once a hardware-isolated environment is present, a secure container-based environment is created, in which the cryptlet itself executes. Here is a figure that details an enclave environment:
With enclaves, Microsoft offers a solution to the trusted oracle challenge. Of course, one has to trust Microsoft (or any other provider that can deliver such a secure environment), but for most people this would provide a much more palatable option than hoping a contract writer has figured out how to implement a trustworthy oracle.
Clearly, enclaves are Microsoft’s bid to become the smart contract execution environment. While the open source nature of the execution environment allows anyone to implement the architecture, doing so is a complex task, likely to be beyond the abilities of most smart contract users. By defining what it hopes will become the core requirements of smart contract usage, and offering them in an easy-to-use service, Microsoft is staking out its claim to be the standard smart contract deployment and operation environment. One might think of this as “Windows for smart contracts.”
Conclusion
It’s hard to wrap one’s head around the Bletchley cryptlet vision. I had to read the white paper several times to (I hope) fully grasp cryptlet architecture and operation. But the more I kept at it, the more I appreciated what Microsoft has created with Bletchley in general and with cryptlets specifically.
Need to understand the benefits and challenges of smart contracts? Read this free white paper.
To my mind, the technical vision behind Bletchley demonstrates that Microsoft has thought more deeply about the future of blockchains than anyone else I’ve encountered. The general level of discussion about smart contracts in the blockchain community is almost laughably naive — pronouncements that one industry or another will be upended by smart contract restructuring, but unsupported by technical detail beyond discussing what language to use or that one should be careful about security. But if one accepts that blockchain technology offers benefits that are sufficiently attractive to motivate potential participants, a whole set of technology requirements and implications become imminent, and it is to those requirements and implications that Bletchley is aimed.
Microsoft’s challenge, I think, will be to educate and convince blockchain adopters that cryptlets are really necessary. As I said, many current advocates of smart contracts seem blithely confident that things are pretty much fine as they stand. It will be up to Microsoft to convince adopters that the status quo (if one can speak of “the status quo” in such a nascent environment) is insufficient to deliver desired benefits without additional scaffolding and security. However, by taking such a bold — and visionary — approach with Bletchley, I believe Microsoft has positioned itself as an important enabler — and a huge beneficiary — of the blockchain revolution.
Enjoyed the content? Don’t forget to hit ❤
.
