July 2018
Volume 33 Number 7
[Blockchain]
Decentralized Applications with Azure Blockchain as a Service
Blockchain has captured the attention of the business and technology world as a way to streamline business processes, verify transactions, and reduce the potential for fraud. This article introduces Blockchain as a Service (BaaS) in Microsoft Azure, showing how it can be used to build a secured data structure and create a distributed transactional digital ledger.
There’s plenty of literature on the Internet about blockchain and how it started as a digital ledger for Bitcoin. A good introductory article to what blockchain is can be found at bit.ly/2IsoWeJ, and for a more technical overview on how blockchain works, please refer to Jonathan Waldman’s “Blockchain Fundamentals” article in the March 2018 issue of MSDN Magazine (msdn.com/magazine/mt845650).
Blockchain is a secure, shared, distributed ledger that can be public, private or consortium (that is, restricted to named members only). It’s secure because it uses cryptography to create transactions that are difficult (if not impossible with current computing technology) with which to tamper. Shared among all nodes or peers in the chain is a data store and, as you’ll see shortly, business logic in the form of contracts. A blockchain value is indeed directly linked to the number of entities that participate in them. Critically, blockchain data and contracts are distributed, which means that there are many replicas of the database. And the more replicas there are, the more authentic it becomes. And finally, blockchain is a digital ledger, a transactional database that appends only immutable records of every transaction that occurs.
I’d like to reinforce this point about blockchain being a distributed ledger. Traditional ledgers are centralized and use third-party systems, or middlemen, to approve and record transactions. Think of credit cards, banks, identity management systems and the like. This approach creates a challenge of trust and scale. Do you trust your middleman agent to act as a broker for all your transactions? Can the agent become a single point of failure? Can it be compromised?
In a blockchain, ledgers are distributed across the entire network, and there’s no need for any third-party system to be in the middle of a transaction. The technology maintains multiple replicas of data, as in a peer-to-peer file-sharing system, as each peer obtains a copy of the entire dataset. No one owns the entire thing, but everyone possesses a copy of it. Figure 1 depicts this arrangement.
.png "A Decentralized Distributed Ledger")
Figure 1 A Decentralized Distributed Ledger
The first blockchain, Bitcoin, emerged in 2009, with distinct limits. As a digital ledger, it simply records transactions and doesn’t keep track of digital asset account balances. Ownership of bitcoins is verified by links to previous transactions, following the immutable history of blocks in the chain of recorded transactions. Also, Bitcoin doesn’t define any specific logic on how to handle a transaction and the conditions, for example, that the two involved parties must agree upon in a cryptocurrency exchange.
Blockchain technology evolved with the addition of smart contracts, which are small pieces of code that add logic to transactions. Think of smart contracts as a computer code representation of legal terms in a contract for goods or services. New blockchain ledgers emerged in the market, the most popular being Ethereum (ethereum.org) and Hyperledger Fabric (hyperledger.org), to add smart contract capability to the network. In these (let’s call them Blockchain 2.0) digital ledgers, smart contracts are now stored in a block and are distributed to all nodes along with related data.
Blockchain 3.0
Bitcoin’s blockchain is often referred to as Blockchain 1.0. It’s a simple ledger that records transactions in sequence and represents the state of the network at any given moment. Think of it simply as a distributed database.
But just as databases have evolved over time by adding logic execution capability—in the form of stored procedures, for example—blockchain has introduced smart contracts to handle the logic tier. However, smart contracts can operate on data only contained in the block where they’re stored. They can’t access external data or systems, as calling a service outside of the blockchain breaks the “circle of trust” that blockchain provides for cryptographic security and immutability of transactions. CRM, ERP and payroll systems all represent external entities that aren’t part of a blockchain, but may be involved in the exchange of data within a transaction. Blockchains need a way to securely receive external data, as well as access to secure execution of off-chain code.
To address this requirement, Microsoft introduced cryptlets as part of “Blockchain 3.0,” the blockchain of data, logic and cloud services. Figure 2 shows the progression of features.
.png "Evolution of Blockchain")
Figure 2 Evolution of Blockchain
Cryptlets are off-chain code modules written in any language that can execute within a secure, isolated, trusted container and can communicate over secure channels. Cryptlets extend smart contracts to the outside world by providing services like encryption, time and date events, external data access, and identity authentication. Microsoft introduced cryptlets as part of its open source project code-named “Bletchley” (bit.ly/2Iv9VZz), which has evolved into the Azure Blockchain Workbench product revealed at the Microsoft Build developer conference in May.
As described on the Web site, Bletchley is an architectural approach to building an enterprise consortium blockchain ecosystem. To be clear, this is not a blockchain stack. It’s Microsoft’s approach to bringing distributed ledger (blockchain) platforms into the enterprise and building real solutions addressing real business problems, while keeping the platform open.
Azure Blockchain Workbench (aka.ms/abcworkbench) leverages different blockchain ledgers and existing cloud services to enable a robust blockchain ecosystem for the enterprise. It’s an easy-to-use tool with a simplified interface that enables users to create end-to-end blockchain applications that leverage the best of Azure services, including Azure Active Directory (Azure AD), Azure Key Vault, Azure SQL Database, Application Insights, Azure Functions and Service Bus. And it does so around popular blockchains and into a reference architecture that can be used to build blockchain-based applications.
You can learn more about Azure Blockchain Workbench in the “Introducing Azure Blockchain Workbench” article I wrote for the June issue of MSDN Magazine (msdn.com/magazine/mt846726)
Getting back to cryptlets, these provide an approachable way for developers to use cross-cutting capabilities like integration into third-party systems and data access. But before I shift focus to development of decentralized applications on a blockchain, I need a platform for delivering a secure and integrated solution on public or private distributed ledgers. Microsoft Azure offers a worldwide footprint that allows building a hyper-scale, secure data and execution platform to deliver the next-generation applications on any blockchain platform.
Blockchain as a Service
Blockchain on Azure (bit.ly/2rQUO5q) provides a rapid, low-cost, low-risk platform for building and deploying blockchain applications. Azure, basically, offers Blockchain as a Service (BaaS) by providing several easy-to-deploy, enterprise-ready templates for the most popular ledgers, including Ethereum, Quorum, Hyperledger Fabric, Corda and more.
Enough with the sales pitch, let’s investigate some key capabilities of Azure BaaS, before diving into the configuration of a specific ledger in the Azure portal. Azure Blockchain consists of:
- Single-node ledgers to simulate production for multiple divisions within a single organization.
- Multi-node ledgers to simulate production for multiple divisions within multiple organizations.
- Tools for development of decentralized applications distributed on a blockchain.
Decentralized applications (dApps) are applications that run on a peer-to-peer network of computers rather than a single computer. In blockchain context, think of a dApp as a client application that communicates to a smart contract for interacting with the blockchain network. A good introduction to dApps can be found on BlockchainHub at bit.ly/2rRkijj.
The key characteristics of building a blockchain infrastructure in Azure are:
- Establish a secure environment that exposes protected endpoints. This can be done via Azure Virtual Networks, Azure App Services VNet Integration or Network Security Groups.
- Develop smart contracts, using any of the available development tools, such as Blockstack Core, Ethereum Studio or Truffle.
- Automate deployment of participant components, both virtual machines and Platform-as-a-Service components. This can be enabled by Azure Resource Manager and PowerShell scripts.
- Protect access to data and logic, with user-level authentication and authorization, by implementing Azure AD to secure apps and APIs.
- In general, build an architecture for enterprise solution integration with a blockchain ledger, leveraging Azure enterprise capabilities and worldwide distribution.
Azure BaaS, in a nutshell, represents not just a public cloud hosting provider for distributed ledgers, but an organic and integrated platform for building and delivering decentralized applications that run on a blockchain technology. Figure 3 illustrates the platform architecture.
.png "Azure Blockchain-as-a-Service Stack")
Figure 3 Azure Blockchain-as-a-Service Stack
Now let’s explore the digital ledger provisioning capabilities of Azure BaaS. First, I need to access Azure portal (portal.azure.com) and create a new service from the Azure Marketplace | Blockchain section. I can select from several digital ledger technologies—in this case I’ll create an Ethereum Consortium multi-node ledger—and quickly provision my blockchain network in Azure.
Ethereum Consortium
The Ethereum Consortium template deploys an Ethereum multi-member network, consisting of a set of mining nodes and transaction nodes. Provisioning can take up to 20 minutes, depending on the size of the network, at which point I can configure additional Ethereum accounts and get started with smart contract and dApp development through the administrator Web page.
The provisioning process guides you through five steps to enter the necessary configuration settings for provisioning the Ethereum ledger in Azure:
Step 1: Configure basic settings, which include a Resource prefix for naming all the generated Azure resources provisioned in the assigned Resource group, authentication credentials as admin of all the deployed virtual machines and the Azure region of deployment.
Step 2: Address network size and performance. You may want to specify the number of members in the consortium (up to 12), the number of mining nodes per member (mining nodes record transactions within a blockchain network), storage replication (locally redundant or geo-redundant) and performance. You can also set the number of load-balanced transaction nodes, which represents the point of interaction of users or applications with the deployed blockchain.
Step 3: This step is specific to Ethereum nodes. I can specify the Ethereum Network ID, a unique value that identifies the network and will be used by nodes to peer with each other. Also, I can specify how the first block, called Genesis, will be generated, either automatically by the platform or manually by providing my own JSON file.
Step 4: Before I deploy the resources in the Ethereum Consortium ledger, I’m presented with a summary of the configuration settings I entered. From here, I can download a JSON template file to automate deployment of a similar resource set with Azure Resource Manager. Figure 4 anticipates the Azure resources to be deployed in the provisioning of the Ethereum ledger, along with a snippet of the template file.
.png "Resource Template File for Ethereum Consortium Multi-Node Ledger")
Figure 4 Resource Template File for Ethereum Consortium Multi-Node Ledger
This template file can be used to automate deployment of similar resources in the future, using a combination of .NET or PowerShell scripts.
The C# code in Figure 5 describes the DeploymentHelper class generated by the template for automating the deployment of the identified Azure resources. You need to reference the following packages to run the code:
- Microsoft.Azure.Management.Authorization
- Microsoft.Azure.Management.ResourceManager
- Microsoft.Rest.ClientRuntime.Azure.Authentication
Figure 5 The DeploymentHelper Class
class DeploymentHelper
{
string subscriptionId = "your-subscription-id";
string clientId = "your-service-principal-clientId";
string clientSecret = "your-service-principal-client-secret";
string resourceGroupName = "resource-group-name";
string deploymentName = "deployment-name";
string resourceGroupLocation = "resource-group-location";
// Must be specified for creating a new resource group
string pathToTemplateFile = "path-to-template.json-on-disk";
string pathToParameterFile = "path-to-parameters.json-on-disk";
string tenantId = "tenant-id";
public async void Run()
{
// Try to obtain the service credentials
var serviceCreds = await ApplicationTokenProvider.LoginSilentAsync(
tenantId, clientId, clientSecret);
// Read the template and parameter file contents
JObject templateFileContents =
GetJsonFileContents(pathToTemplateFile);
JObject parameterFileContents =
GetJsonFileContents(pathToParameterFile);
// Create the resource manager client
var resourceManagementClient =
new ResourceManagementClient(serviceCreds);
resourceManagementClient.SubscriptionId = subscriptionId;
// Create or check that resource group exists
EnsureResourceGroupExists(resourceManagementClient, resourceGroupName,
resourceGroupLocation);
// Start a deployment
DeployTemplate(resourceManagementClient, resourceGroupName, deploymentName,
templateFileContents, parameterFileContents);
}
Similarly, the PowerShell script signs into an Azure subscription, registers the necessary resource providers and then starts the deployment of the resources identified in the template file, as shown in Figure 6.
Figure 6: Starting the Deployment
# sign in
Write-Host "Logging in...";
Login-AzureRmAccount;
# select subscription
Write-Host "Selecting subscription '$subscriptionId'";
Select-AzureRmSubscription -SubscriptionID $subscriptionId;
# Register RPs
$resourceProviders = @("microsoft.compute","microsoft.resources","microsoft.network");
if($resourceProviders.length) {
Write-Host "Registering resource providers"
foreach($resourceProvider in $resourceProviders) {
RegisterRP($resourceProvider);
}
}
#Create or check for existing resource group
$resourceGroup = Get-AzureRmResourceGroup -Name $resourceGroupName -ErrorAction SilentlyContinue
if(!$resourceGroup)
{
Write-Host "Resource group '$resourceGroupName' does not exist.
To create a new resource
group, please enter a location.";
if(!$resourceGroupLocation) {
$resourceGroupLocation = Read-Host "resourceGroupLocation";
}
Write-Host "Creating resource group '$resourceGroupName' in location
'$resourceGroupLocation'";
New-AzureRmResourceGroup -Name $resourceGroupName
-Location $resourceGroupLocation
}
else{
Write-Host "Using existing resource group '$resourceGroupName'";
}
# Start the deployment
Write-Host "Starting deployment...";
if(Test-Path $parametersFilePath) {
New-AzureRmResourceGroupDeployment -ResourceGroupName $resourceGroupName
-TemplateFile $templateFilePath -TemplateParameterFile $parametersFilePath;
} else {
New-AzureRmResourceGroupDeployment -ResourceGroupName $resourceGroupName
-TemplateFile $templateFilePath;
}
The entire solution, consisting of template and script files, is available for download from my GitHub repository at bit.ly/2INgNEP.
Once that’s done, review the terms of use and licensing conditions, and click Create to deploy the resources. In less than 20 minutes, you have a fully functional blockchain ledger up and running. Just don’t forget to save important information needed for developing dApps, including:
- RPC-Endpoint: You need this address to establish communication between a dApp development environment, such as Ethereum Remix and the consortium blockchain.
- SSH Info: You need credentials to sign into the blockchain environments and configure parameters, like most typically for unlocking the Coinbase account and start mining new blocks.
Coinbase is my digital wallet, which contains my signature keys used to hash a block, and my Ether, the cryptocurrency of Ethereum, earned as part of the mining process. When deploying a new Ethereum Consortium ledger in Azure, this account is initially locked, so I need to unlock it before I can publish smart contracts. With the help of SSH, I connect to a transaction node of the Ethereum Consortium network and unlock the Coinbase account, like so:
geth attach -- opens the Geth console
personal.unlockAccount(eth.coinbase)
When prompted for a passphrase, I enter the gethadmin password that I specified in Step 1 of the configuration wizard (not the Ethereum private key passphrase). By default, this action unlocks the Coinbase account for 5 minutes. You can change the duration using a different signature of the unlockAccount method, as shown here:
eth.coinbase -- address of the coinbase account
personal.unlockAccount('address', 'passphrase', 'duration') --
unlocking the account for a longer time period
If you’re wondering what the “geth” command stands for, it’s a multipurpose command-line tool that runs a full Ethereum node implemented in Go.
Once the Coinbase account is unlocked, this represents time zero, when the network starts. After this point, nodes can accept transactions. Transactions could be in the form of creation of accounts, movement of ether, creation of smart contracts, or any change to the state of the blockchain. Then, at a periodic time configured for the network, the network mines the next block. This block is a hash calculated by combining hashes of the transactions executed between the last block and now, plus the hash from the previous block and a nonce—a sequence of bits in a block that can be adjusted in order to try to satisfy the proof-of-work condition.
This is the essence of mining. This value makes satisfying “proof of work” a difficult computational task that depends on luck or brute force. The block is then accepted by the network by consensus, and so you have the first two blocks in your chain, and so on.
Developing Smart Contracts
It would take a whole book to go through the details of developing smart contracts in Ethereum. In this article, I want to offer pointers to start with and understand the landscape of technologies and frameworks in use.
To write and deploy smart contracts in Ethereum, you can use any of the development environments available in Azure, or access a completely external browser-based IDE like Ether Camp (ether.camp) or Ethereum Remix (remix.ethereum.org).
In terms of programming languages, Solidity (solidity.readthedocs.io) is a popular contract-oriented language for blockchain programming, with a JavaScript-like syntax.
On the client side, programming languages that support interacting with an Ethereum node include C#, C++, JavaScript and more. It’s possible to write C# code using a library like NEthereum (nethereum.com), a fully managed .NET integration library for Ethereum that allows interaction with Ethereum clients like geth, eth or parity using RPC. The library has very similar functionality to the JavaScript Ethereum Web3 RPC Client Library, which is the de-facto standard for blockchain client interoperability.
For example, to make a Smart Contract call via NEthereum, I need to do the following:
- Obtain the smart contract address and Application Binary Interface (ABI). An ABI is the interface to call functions in a smart contract and get data back from an Ethereum node.
- Obtain the function signature on the smart contract to be invoked.
- Unlock the Ethereum account making the call with the account’s passphrase.
- Make the call to the smart contract.
The code snippet in Figure 7 shows a few very basic steps, using the NEthereum library.
Figure 7 Calling a Smart Contract
// Obtain the contract ABI
abi = db.GetContract(ballot.ContractID);
// Get the function address to call on the smart contract
var func = web3.Eth.GetContract(
abi,
ballot.ContractID).GetFunction("vote");
// Unlock the account so you can call the smart contract
string passphrase = db.GetAccountPassphrase(agreement.OriginatorAccount);
bool success = await web3.Personal.UnlockAccount.SendRequestAsync(
ballot.OriginatorAccount,
passphrase,
120);
// Make the smart contract call
if (success)
{
object[] args = new object[] {
id,
ballot.OriginatorAccount,
ballot.CounterSigAccount,
123 /* sample proposal number to vote for */ };
// Call the "vote" function on the smart contract
await func.SendTransactionAsync(ballot.OriginatorAccount, args);
}
The invoked smart contract, written in Solidity, would look like a ballot contract that exposes a vote method, which accepts a proposal number in input. When a vote is cast, the voted flag on the voter (the message sender) is set to true to prevent double voting, and the proposal counter is increased, considering a weight for the vote itself. Figure 8 shows the code for this.
Figure 8 A Ballot Contract in Solidity Code
pragma solidity ^0.4.0;
contract Ballot {
struct Voter {
uint weight;
bool voted;
uint8 vote;
}
struct Proposal {
uint voteCount;
}
address chairperson;
mapping(address => Voter) voters;
Proposal[] proposals;
/// Create a new ballot with different proposals
function Ballot(uint8 _numProposals) public {
chairperson = msg.sender;
voters[chairperson].weight = 1;
proposals.length = _numProposals;
}
/// Give a single vote to the given proposal
function vote(uint8 toProposal) public {
Voter storage sender = voters[msg.sender];
if (sender.voted || toProposal >= proposals.length) return;
sender.voted = true;
sender.vote = toProposal;
proposals[toProposal].voteCount += sender.weight;
}
}
Please note that this is Solidity code, a strongly typed language with JavaScript-like syntax, with a few variants, like the contract, struct and address keywords, or the triple slash (“///”) for a comment. I use Ethereum Remix for development of smart contracts in Solidity, which provides a Web-based IDE for development, testing and deployment.
Azure Blockchain vNext
Let’s look at what the future looks like in the Microsoft vision for blockchain technology. Coming soon, the Microsoft Confidential Consortium (Coco) Framework is an open source system that enables high-scale, confidential blockchain networks that meet all key enterprise requirements for confidentiality, governance and performance, and at the same time provide a means to accelerate production enterprise adoption of blockchain technology.
Coco (bit.ly/2Ior8YA) brings together the power of existing blockchain protocols, trusted execution environments, distributed systems and cryptography to enable enterprise-ready blockchain networks that deliver:
- Throughput and latency approaching database speeds
- Richer, more flexible, business-specific confidentiality models
- Network policy management through distributed governance
- Support for non-deterministic transactions
- Reduced energy consumption
It’s important to note that Coco isn’t a standalone blockchain protocol. Rather, it provides a trusted foundation with which existing blockchain protocols such as Ethereum, Quorum, Corda and others can be integrated to deliver complete, enterprise-ready ledger solutions. Coco is designed to be open and compatible with any blockchain protocol. It achieves this through the use of trusted execution environments (TEE), such as Intel Software Guard Extensions (SGX) and Windows Virtual Secure Mode (VSM), to enable the creation of a trusted network of physical nodes on which to run a distributed ledger. Figure 9 shows the Coco Framework architecture.
.png "High-Level Overview of the Coco Framework")
Figure 9 High-Level Overview of the Coco Framework
Microsoft plans to open source the Coco Framework code later in 2018.
Finally, a word on Azure Blockchain Workbench, which is the primary mechanism for enterprise customers getting started with blockchain. Azure Blockchain is a collection of Azure services and capabilities designed to help enterprises create and deploy a new class of applications for sharing business processes and data with multiple, semi-trusted organizations. Currently, customers can deploy these services into their subscriptions and integrate them with blockchains available on the Azure Marketplace. With Azure Blockchain Workbench the heavy lifting is done for them, so they can focus less on scaffolding and more on logic and smart contracts.
Azure Blockchain Workbench is available now in the Azure Marketplace (aka.ms/tryworkbench).
Stefano Tempesta is a Microsoft Regional Director and MVP, as well as chapter leader for CRMUG in Switzerland, the largest community of Dynamics 365/CRM experts in the world. Tempesta is an instructor of courses about Dynamics 365, blockchain and machine learning, and a regular speaker at international IT conferences, including Microsoft Ignite and Tech Summit. He founded Blogchain Space (blogchain.space), a blog about blockchain technologies, writes for MSDN Magazine and MS Dynamics World*, and publishes machine learning experiments on the Azure AI Gallery (gallery.azure.ai).*
Thanks to the following Microsoft technical experts for reviewing this article: James McCaffrey
Dr. James McCaffrey works for Microsoft Research in Redmond, Wash. He has worked on several Microsoft products, including Internet Explorer and Bing. Dr. McCaffrey can be reached at jamccaff@microsoft.com.