Marley Gray, director of blockchain business development and strategy at Microsoft, posted an update to GitHub in June 2016 providing an overview of Bletchley. This white paper was published six days after Microsoft's announcement of Project Bletchley on June 15, 2016, and goes on to say that Project Bletchley is a set of tools for supporting SmartContracts on the blockchain, enabling secure access to off-chain information. The project supports open standards for protocol-level implementations of peer-to-peer networking, consensus, database and virtual machines are vital to establish trust within a blockchain ecosystem.
Bletchley is a middleware tool set for developers and provides an ecosystem to enable implementing identity, security, cryptography, scale, tooling, management, monitoring and reporting for both on and off the blockchain.
Client-driven performance flexibility
What Bletchley offers is performance flexibility for core, kernel and universal protocols. For example, a banking application will have different requirements for transactional, processing and nonfunctional requirements for scale when compared to a nonprofit using a basic digital ledger to record donations.
The two-tier client-server architectures are multitier computing architectures in which an entire application is distributed as two distinct layers or tiers. In this case, the presentation layer and data layer run on the server. In contrast, three-tier or n-tier architecture is usually separated into three major sections: The presentation/front-end tier, the business/application tier and the data/back-end tier.
The process of blockchain architectures experienced a similar evolution as tier-level client architectures. Blockchain 1.0, simple state machine, used logic (stored procedures) to record transactions in sequence, where referential integrity was implemented through the use of primary keys (PK) and foreign keys (FK). Blockchain 2.0, state machine and code, added SmartContracts. The 2.0 version also leverages PK and FK, however Blockchain 2.0 also contains logic (code like a stored procedure) that can be executed. Blockchain 3.0, state machine and code and cryptlets, allows for improved interoperability and scale on and off the blockchain.
As a general clarification there are some additional differences regarding tokenization and instantiation of transactions that are beyond the scope of this article.
MIcrosoft also introduces the idea of the enterprise consortium node. In these scenarios, the client system makes a request and the request is given to a future node (block database, state, history) that is connected to the block database (state and history, signing, VM and consensus). In short, the modular framework can choose the best components to fulfill the client request. We're starting to reach the ability to handle dynamic scalable, requests.
Getting off-chain data
Cryptlets establish the foundation for Microsoft's security blockchain middleware and run as a cloud-based service, provider-agnostic. Previously, when making data requests outside a SmartContract, the authenticity was broken for dependent transactions. For example, if you're running an app on your phone but, in order to process an order, you need your payment information stored in another SmartContract. Another example would be while running a phone app, you make a request to view your medical information, but when you click on your lab results details, a call (to the lab's SmartContract) is required to access that information (outside of the existing SmartContract). Today the effect is that the pure integrity of the transaction is broken.
Cryptlets live off the blockchain and execute within a secure trusted container and communicate using secure channels. Cryptlets also can be written in any programming language and are called or instantiated by a CryptoDelegate (with the SmartContract). Cryptlets come in two flavors: Utility (providing core infrastructure and middleware services, e.g. encryption, time and date events, external data access and authentication services) and Contract (providing all the execution logic and securely storing the data in the SmartContract). Contract Cryptlets also don't run on the blockchain and therefore can execute in parallel on vertically scaled systems.
The idea of "winner take all" doesn't apply to blockchains. The number of players on the field is exploding and consortiums are required to play to win. Microsoft gets that multiple players are required for effective blockchain outcomes and to fuel deeper rapid application development. As a result, Microsoft has touted blockchain middleware as the "Enterprise Consortium Distributed Ledger Fabric" evolving into APIs and platform-as-a-service. Is this the real fix for interoperability for payments, health, property and provenance? It might not fix everything, but it's a strong start to a huge problem.
The Microsoft blockchain middleware layer provides these core services as explained in the white paper:
- Identity and Certificate Services: authentication, authorization, key issuance, storage, Cryptlet registration, access and life-cycle management.
- Encryption Services: partial payload encryption.
- Cryptlet Services: attested hosting for cryptlets to be securely invoked by CryptoDelegates in SmartContracts.
- Blockchain Gateway Services: Interledger-like services to allow for SmartContracts and tokenized objects to be passed between different ledger systems.
- Data Services: key data services like distributed file systems (IPFS, Storj etc.) of off-chain data referenced by public keys. Read: get your data from any source, from anywhere in the world. This enables auditing, advanced analytics, machine learning and dashboarding services for SmartContracts, blockchains, consortia and regulators.
- Management and Operations: tools for deployment, management and operations of enterprise systems.
The base of this three-tier stack is the Distributed Ledger Stack (consensus, networking, database and any other third-party distributed ledger stacks. This means the foundation can be built on Ethereum, Eris or Unspent Transaction Output (UTXO) implementations such as Hyperledger.
The true middleware layer involves distributed ledger gateway services, identity and key services, crypto services, and machine learning and business intelligence services. The nodes supporting this layer can be places on any location (Azure, AzureStack, private datacenter, AWS, or others). Soon full libraries of Cryptlets as well as full SmartContract libraries will be available for purchase.
For example, if a medical company determined how to access and populate an anonymized private store of medical information for researchers, it could create a PatientNameless SmartContract and place it on the marketplace (similar to apps on iTunes). Then a research group could select a PatientAccessRequest SmartContract to populate data for its next research study. The team that is hired to create the application (inclusive of populated data, machine learning, wrapped with business intelligence) could choose a PatientForResearch Cryptlet that meets or exceeds requirements for the research application.
The top layer is the application layer, where most of the current industry solutions reside.
Many of blockchain's challenges are solved and most are not integrated into consortium solutions but exist siloed – almost where we started. Some challenges remain outstanding such as self-sovereignty (self-ownership of identity), scalability (off-chain), interoperability (seamless interaction between systems).
Solving these challenges may be that last stone to uncover a truly collaborative economy – a global economy that shares data.
This article is published as part of the IDG Contributor Network. Want to Join?