Kickstart your Ethereum journey on Microsoft Azure — Part 2

Refresher

Yo guys! Great to see you here again. Last episode I showed you some of the nice features of Ethereum and its Smart Contracts. For your convenience, I put the complete code package on GitHub for you to download and explore. We’re going to need it this episode for some real hands-on work! Let’s go on to the next phase in our blockchain journey. Here’s a quick overview of what we’re going to do today:

• Setup an Ethereum PoA private blockchain on Microsoft Azure
• Compile the Solidity source code of the contracts shown in last episode to deployable Ethereum bytecode
• Deploy the contracts on the freshly created consortium blockchain

Let's start!

Launching our own Ethereum blockchain on Microsoft Azure

OK nice, so we have our Smart Contract code, yeeha! Now, what do we do with it? Here comes the power of the Ethereum blockchain: we just have to compile them, deploy them, and we’re good to go! For this, we’re going to use the most popular Ethereum API written in Javascript, Web3.js. Web3 illustrates the interpretation of “web 3.0” as perceived by the Ethereum founders, referring to the well known “web 2.0” definition. It originates from Ethereum's most foundational raison d'être: enabling The Decentralized Web. Where traditional blockchain is used to decentralize registrations and asset transactions, Ethereum goes a step further by decentralizing Turing-complete applications that are no longer dependent on centralized servers. Therefore, it coincidentally makes the life of the developer a lot more straight-forward too: we don’t need to maintain any servers for our application. This is all done by the Ethereum network participants and their running nodes. Applications are guaranteed to run as long as some nodes are online, so we are basically ensured of 24/7 availability. On top of that, these decentralized applications — or DApps in short — promise to make the web more democratic than it is today. How great is that?!

Web3 illustrates the interpretation of “web 3.0” as perceived by the Ethereum founders, referring to the well known “web 2.0” definition. It originates from Ethereum's most foundational raison d’être: enabling The Decentralized Web.

So far, we’ve only discussed about public blockchain networks. These networks are very promising, but also face some significant issues in terms of scalability and performance. To be really honest, they don’t quite comply with enterprise standards. That’s why a range of companies are investing heavily in several other DApp-platforms which are more tailored to these business needs. You might ask yourself why this is still a deal. We want to decentralize everything, right? Make the web more democratic, no? What else are we doing it for?

<InspirationalIntermezzo>

Let me put this in a broader context. Blockchains are meant to create trust where there is none, or where people at least have to be careful what this perceived “trust” really covers and entails.

Over the last half-century, the possibilities brought forward by the invention of the Internet have been astonishing. New forms of collaboration have seen the light and opened up markets and opportunities that had never been conceivable before for people in all kinds of domains. But with new technology also comes new responsibility; databases were constructed in a private way to be protected against attacks and restrain confidential enterprise data from public sight. This resulted in the formation of a landscape full of data silos.

More and more, businesses are aware that they need to interact to be stronger together. Take the example of a small web shop that has to fight against a giant like Amazon — David and Goliath in the digital age. With the advent of new and much higher customer expectations, the small shop has a hard time providing the same user experience and low prices in comparison with the big giant. The giant controls the complete supply chain from production to delivery and by processing mass volumes, it can optimize costs significantly and dominate the market.

But what if the individual Davids work together? What if they would set up an alliance of 20 separate businesses to outperform the giant? As they still operate as separate businesses and want things to stay like that in order to keep their identity and product individuality, they would need to find a way to be aligned while finding trust between each other. They have to function as a well-oiled machine. But who is going to manage the processes? Who is going to guard the data? In a pre-blockchain age, this would be depending on a centralized architecture in which one party would be responsible for data integrity and processing. If that party uniquely acts in its own interest, the battle is lost before it even started.

That’s why private permissioned blockchains are interesting, too. They would make it possible for known parties to work together while keeping their own identity and processes in place. They would need to integrate with a new data source or reference, a “Single Source of Truth”, to use in matters that go beyond their own business scope. This could comprise the supply chain management of product deliveries, stock data for optimizing and aligning manufacturing needs and so on. Basically, every process in which multiple independent actors need to interact and share data with each other in a reliable and trusted way. For that to work, the system and protocol itself need to be trustless. Behold the Ethereum consortium network, leveraging the power of Microsoft Azure!

</InspirationalIntermezzo>

With that information in the back of our heads, let’s get to business and launch our own private Ethereum network. We’ll make thankful use of the provided portal and wizards in Microsoft Azure to do this in a very straight-forward and accessible way. By-the-way: I will assume Azure portal access and an existing Azure subscription for the people following this tutorial.

With the portal opened, go to the blockchain offerings in the Azure Marketplace. You can find them easily as shown below.

Microsoft Azure offers an impressive array of templates for bootstrapping blockchain networks

As indicated in the picture, we’ll select the “Ethereum Proof-of-Authority Consortium” template. Next up is configuring some parameters for bootstrapping the network using the interactive wizard provided by Azure. I’ve included some print-screens for every step in the process to make this as easy as possible!

Step 1 — Basics

In this screen, we provide some basic information such as the subscription to use (read: how we’re going to pay for the running services) and a public SSH key or password to access the created VMs.

Step 2 — Deployment regions

For high-availability reasons, we can opt to deploy our infrastructure in multiple geographical regions. We’ve chosen 1 for the sake of this tutorial.

Step 3 — Network size and performance

This is the most important step. We’ll need to define how many validating nodes our first consortium member will consist of. We will be able to extend this number later on, but it will require some technical knowledge and won’t be covered by this series. This number will put a restriction on the number of validating nodes other parties can maximally have. The number of parties can be scaled without any limits, as long as there is consensus throughout the consortium over these extensions.

Go ahead and define as much nodes as you want, but be aware that a higher number of nodes will result in higher computational and storage costs on your active subscription. I’ve gone with 2 nodes in this tutorial.

Step 4 — Ethereum settings

To finish up the configuration of the blockchain network itself, we need to define ids for the network itself and the first consortium member within this network. This first member will be the one with initial control over the network and can choose to include other parties to delegate consensus. The ids can be chosen freely, but remember that they have to be unique when adding members later on. On top of that we need to provide the admin Ethereum public key from which the first transactions in the network can be performed. If you don’t have an Ethereum wallet yet, I advise you to download the official go-ethereum client, install it and run the following command:

> geth account new

This will create a JSON wallet file in ~/.ethereum/keystore. Go ahead and look it up! But be very careful; if you’re going to use this wallet for real, you don’t want to share its content with anyone, ever! Inside the file you can find your public Ethereum address, which can be shared without any issues. This is the 40-character string value under key “address”. Normally, you’d always include “0x” at the beginning of this sequence when providing your address digitally. This is also how you need to define it in Azure.

Disable advanced options for now.

Step 5 — Monitoring

We’ve reached the last configuration step in the wizard. I advise you to enable logging and monitoring in case you would like to see what’s going on under the hood!

Step 6 — Summary

That’s it. Let’s power it up! Be patient though; the deployment process can take up to 30 minutes. But Azure has got you covered. You’ll get an email notification when the process is finished.

You'll get this email notification when deployment is finished.

When you’ve received this mail, please go back to the Azure portal and go to the details page of the central load balancer of the validating nodes. Save the public IP address of this load balancer, you’ll need it in the next part.

Deploying your own Smart Contract to the Ethereum consortium blockchain

With the blockchain ready to be used, I assume you’re hungry for your Ethereum bytecode, am I right? Let’s go get it! First thing you’ll need to do is making sure you have Node.js and NPM installed on your machine. If not, you can download a release compiled for your OS via following link. Installing the latest LTS release should be just fine! Open up your terminal and test out the installation. If you get something like this everything should be fine.

> node -version
v10.14.2

Next thing is to install the Solidity compiler on your system. This can be done by running following command:

> sudo npm install -g solc@0.4.18

Now let’s create a folder containing our Solidity source code. To make it easier for you, I’ve made a little GitHub repo with all the required files. Just clone it and you’re (almost) all set. You can find it here.

There’s two things we need to do now. I didn’t tell you this so far, but we’ll need a bit more than just the bytecode in order to deploy the contracts to the network. This secret ingredient is the contract-specific application binary interface (ABI), which is basically a JSON-interface describing the endpoints and parameters written in the contract, so SDKs like Web3.js know how to talk to them. Let’s create all the required material by running the next commands from the root of the cloned repo:

> mkdir compiled
> cd contracts
> solcjs -o ../compiled --bin --optimize *.sol
> solcjs -o ../compiled --abi --optimize *.sol

We now have the bytecode and ABIs in a subfolder named compiled.

Let’s go on to the next step. Before we can make any transactions to the blockchain network, we need to define the required credentials and parameters to interact with it. As you might have seen, there are three more files in the repo. I’ve made these to make it a bit more straight-forward to deploy the contracts. But first, let’s install the required Node.js dependencies to the project root:

> npm install

Now we’ve come at the trickiest part of the process. To actually deploy the contract to the network, you’ll need an Ethereum wallet. Luckily for us, we already generated it in the previous part! Go into the config.js file in the root of the project folder and copy-paste your Ethereum public address in the account field. Furthermore, you’ll have to specify the node endpoint to connect to. This is the load balancer IP address you saved earlier on. The URL should look like this:

http://<LOAD_BALANCER_IP>:8540

After you’ve done this, open the file deploy-contract.js and adjust the value for keystore at line 9. Probably you’ll just need to change ethereumintro to .ethereum if you’ve followed my instructions for generating a wallet. Otherwise, just specify the exact location of your JSON wallet file.

Now we’re finally ready to deploy! 3, 2, 1… GO! Open up your terminal from the project root and enter:

> node deploy-contract.js TokenController --compiled

Wait a few seconds for the deployment to complete. When everything goes well, you’ll see the Ethereum address of your newly deployed contract instance in your terminal window.

Wrap-up

Congratulations! You successfully created your own Ethereum blockchain and deployed the very first contract to it! This is a big milestone, so you can be proud of yourself.

Be sure to save the contract address for later. We’ll use it as the main entry point to interact with it.

To finish up this second part of the story, here’s a short overview of what we’re going to do in the next and final episode:

1. Mint tokens via the TokenController contract and transfer them around
2. Catch events on successful transfers
3. Forward the details of these events to Azure Service Bus
4. Spread the word within our global application landscape

Stay tuned and keep it decentralized!

<<< Go to the previous episode or Go to the next episode >>>