Part 2. Enter Microsoft’s Azure Blockchain Workbench
In May 2018 at Build Microsoft announced the initial pre-production release of the Azure Blockchain Workbench. “CoCo” or “Project Bletchley”, as originally named, had come of age. The project had been heralded as one that would simplify the building of Blockchains, opening up the technology to a wider audience. After the trials and tribulations described in Part 1 we were keen to find out.
Overview
Azure Blockchain Workbench is described as an infrastructure and set of tools, allowing companies to implement Blockchain applications that share and processes data with other organizations. By using Active Directory as a platform to run this enterprise-based application and preconfiguring bespoke templates it allows developers to focus on the core business needs of their company, creating the business logic and smart contracts which run on the Blockchain.
Currently (August 2018) Blockchain Workbench supports Ethereum. Other consortium types like Corda and HyperLedger are said to be in the pipeline. With the recent release of version 1.3.0 Workbench you can now “bring your own” Blockchain consortium instance and merge it with the Workbench. As yet we have not investigated this but suspect it may be something best left to those with experience.
A Blockchain Consortium built from a template.
For those familiar with Azure you can configure a Blockchain Workbench instance simply by selecting a preconfigured Resource template. You are then taken through a series of steps at the end of which you will have configured and defined a Blockchain Ethereum network – no small feat.
The steps require a fair amount of knowledge of the basic concepts of Active Directory e.g. tenancy, network permissions, user rights and so on, but perhaps no more than would be expected from a competent system engineer; and after all this is an Enterprise application (further details of this process can be found here). When all information has been entered, you accept the terms and conditions, hit the create button and sit back and wait while the preconfigured template creates, deploys and provisions all the components required to create the Blockchain Ethereum Consortium instance. This may take up to 30 mins depending on your selected configuration.
What do you get when your template completes?
When deployment has completed you will have a functioning private Blockchain network containing up to 24 distinct components or assets including load balancers, network security groups, a SQL database, web-based REST API servers and gateways, monitoring services, service bus APIs and Azure Key vaults, indeed all the services and components required to monitor and maintain your Blockchain instance.
Given our previous experience (Part 1) this template-based approach is compelling, since to build one’s own comparable network would take weeks if not months of highly skilled, and expensive, engineering time. With the workbench you can spin up a fully functioning Blockchain, complete with the potential to integrate to a range of Azure Services in minutes, then tear it down and start again in even less time. This is the attraction of the Blockchain Workbench: making the building of a Blockchain infrastructure easy. In our view, it’s a success.
Figure 1 – System overviewSome of the components of the Blockchain workbench that are spun up are as follows:
Message broker
This can be used to implement a messaging input flow from, for example, an Azure IoT source, or other Azure system. For example, a supply chain monitoring system that checks the integrity of perishable goods, providing temperature or humidity data or some other critical aspect affecting the status of goods monitored by the smart contract, routing this information into the system via Azure’s IoT service. Likewise, downstream events can be generated by the Gateway API and the Ledger that could be used to message/update external systems or parties notifying critical events.
Currently two event types are generated, one to populate the off-chain store, the other to capture metadata for API events related to the upload and storage of documents. Message consumers receive these messages from Azure Service Bus. Currently implemented messaging includes the following:
- Distributed ledger consumer: Contains the metadata for transactions to be written to the Blockchain. This consumer retrieves the messages and pushes the data to a transaction builder, signer, and router.
- Database consumer: This takes messages from Service Bus and pushes the data to the SQL database.
- Storage consumer: The storage consumer takes messages from Service Bus and pushes data to an attached storage entry, e.g. storing hashed documents, media files and other memory hungry in simple Azure Blob Storage.
- Transaction builder and signer: Inbound message that must be written to the Blockchain are processed by the DLT (distributed ledger technology), a service which retrieves the message metadata for a desired transaction to execute sends that to the transaction builder and signer. The transaction builder and signer then creates a Blockchain transaction based on the data and target destination, when created, the transaction is signed. The Blockchain Workbench get the correct private key from Azure Key Vault signs the transaction and sends it to transaction routers and ledgers.
Transaction routers and ledgers
These take signed transactions and route them to the correct Blockchain.
DLT watcher
Monitors events occurring on blockchains attached to Blockchain Workbench, such as those related to the creation of a new contract, the execution of transactions, or other instance specific changes of state programmed within the smart contract. The events are forwarded to the outbound message broker, so they can be consumed by downstream consumers.
Azure SQL database
Stores contract definitions, configuration metadata, and a replica of the data stored in the Blockchain. This provides fast off-chain access to build reports and support other data related activities, for example, integration with Power BI. By moving data from to off chain storage the Blockchain Workbench provides “standard” platform that is independent of the current Blockchain network implementation e.g. Ethereum or Corda.
Monitoring
Application Insights and Azure Monitor provide monitoring facilities. App Insights logs all information from Blockchain Workbench whilst Azure Monitor provides information on the health of the blockchain network.
Managing users
As Blockchain Workbench applications are enterprise applications run under an Active Directory (AD) tenancy, workbench administrators have rights/actions that manage access and assign users specific roles within the Blockchain application, e.g. a buyer or a seller in a market place app, or a producer and importer in a supply chain app. Once assigned, the AD user is automatically mapped to an on-chain membership (address). This means that, unlike standard Ethereum based membership, workbench members do not need to remember 21-character addresses; these are hidden, users simply sign in with their AD username and password. Interaction with the Blockchain maps the AD username to their “real” Ethereum address, simplifying the whole interaction.
Using the same AD account, users can log in to any one of a number of Blockchain instances (if invited) running under an AD tenancy; this also applies to external users who are invited as “guest users” on the AD tenancy in order to participate on the Blockchain activity.
External users federate their identities to an AD by being sent an email invitation initiated by the Blockchain administrator. When logging in, they are authenticated by user name, password, and configured policies. Azure AD manages all users and devices that have access to the Blockchain Workbench.
Supported systems
The Workbench provides a REST API for managing Blockchain applications and users which can be accessed by external applications registered on the AD tenancy to which the Blockchain application belongs. The registration should also provide the right to access a specific blockchain instance via the latter’s Application ID.
Developers wishing to build application UIs can either utilize the REST API directly or employ one of the current SDKs which wrap it; these are available for Java, C# or Python. From experience, and at the time of writing, the C# SDK may not yet be complete, and requires Visual Studio 2017. Should you use the C# SDK you will need to register your application as a Native app under the AD tenancy, and provide both its application ID and that of the Blockchain application you wish to communicate with when logging in via your app. Full details of the available SDK’s can be found on the blockchain.net client github page. It can sometimes be difficult to get this part to work, so you will need to check that your application IDs are correct, and your Native App configured in your AD has the right to access the Blockchain app defined under your AD tenancy. See the following example of how to get an access token:
// this is the request url to our AD
var ad = "https://login.windows.net/ourdomainname.onmicrosoft.com/oauth2/authorize";
AuthenticationContext ct = new AuthenticationContext(ad, true);
Uri redirectUri = new Uri("http://ChainMon"); // is our native apps name registered in the AD
// this always prompt for users login
AuthenticationResult ar = await ct.AcquireTokenAsync("Use App ID of your the block chain application", "App ID of the Native application (this application)", redirectUri, new PlatformParameters(PromptBehavior.Always));
// set the access token objected from the above
GatewayApi.Instance.SetAuthToken(ar.AccessToken);
// specify the App Service Web API for the BlockChain application you want to query
GatewayApi.SiteUrl = "https://bbres-4s4pap-api.azurewebsites.net";With the above you should then be able to use the C# GatewayApi wrapper provided in the Blockchain C# samples (see below) and call API functions.
var users = await GatewayApi.Instance.GetAllUsersAsync();
foreach (Workbench.Client.Models.User u in users) {
var k = await GatewayApi.Instance.GetUserByIdAsync( u.UserId.ToString() );
WriteLine("GetUserByIdAsync + k.DisplayName + " " + k.EmailAddress + " " +k.LastName);
}The Workbench also provides a web-based test site which you will find under the App Services section of your Azure Platform interface. Here you will find two similarly named services, the one whose name ends in the suffix ”-api” will contain the URL to the fully documented and functional REST API interface (as shown in Figures 2 to 4). The other is the main API interface, used by both the resident smart contract installation and test app and any external components that use either the REST API or one of the supplied SDKs.
Figure 2 – The core API groups available via the Workbench REST API. Selecting one of these opens a page (Figure 3) detailing all of the API calls available to that group
Figure 3. API interfaces available under the Applications grouping, from here you can select the required API, fill in the required details (Figure 4) then invoked the API call
Figure 4. API parameter entry dialog. Here you enter the required parameters for the API call, invoke it and receive the results.The SQL database provides off-chain storage and recording for every on-Block event and transaction, ensuring that these immutable encrypted events are synchronized, replicated to the database and tagged with appropriate information. This means that not only is Blockchain-specific knowledge not required to analyze data, but that Blockchain applications themselves can offload data storage – e.g. a ledger-based document storage application – onto the SQL database, reducing transaction times. The SQL database acts as a replica of on-chain data that can be analyzed with respect to the smart contract running on the block, and queried to determine its state and interaction with participants.
So far we have briefly described how to set up a BlockChain Workbench, explained, albeit briefly, what it offers and how it “fits” in the Azure platform. In Part 3, we will build the smart contract and the configuration meta data file that is unique to the MS workbench. From there we will talk about linking smart contract instances to IoT and to external systems via services provided by Azure or indeed other platforms.
