Kickstart your Ethereum journey on Microsoft Azure — Part 1
Hi guys! In this threefold series, I'm going to give you an introduction on Solidity Smart Contract development, teach you how to interact with the blockchain and explain how to setup integrations on Microsoft Azure that go beyond the blockchain horizon. The first part in this series will give a short introduction on Ethereum and its magnificent Smart Contracts. Still with me? Let's go!
Ethereum and the EVM
Before diving into the technical side of things, let’s start with a quick Ethereum refresher. Well, of course y’all know the basics of blockchain already, otherwise you wouldn’t be here in the first place. So let’s skip that one, and go straight to the most interesting part: Smart Contracts. These little autonomous pieces of code live on the blockchain as so-called accounts. Just like a physical user can have an account and interact with the blockchain using his private key, Smart Contracts can perform all actions normal users can do, in a fully automated way. They can be used as trust-less business rules, making it fully transparent to all stakeholders what actions will be performed based on incoming transactions and external events. This is a really cool feature, but also implies an important limitation on the autonomy of Ethereum Smart Contracts: they cannot act out of nothing. They will always do what they’re told to do (read: what was written by the developer), but they will only do it based on external triggers. This is an important restriction to remember.
Following best practices in computer programming, one Smart Contract should not contain code that goes beyond its border of responsibility.
Keep it Simple, Stupid!
Of course, the genius Ethereum dev team took this into account and provided means for other developers to implement inheritance and interfacing capabilities. You can easily compare a contract with a class in traditional object-oriented programming. Similarly, deployed instances of this contract can be seen as objects. And by the way, when I’m talking about Smart Contracts I mean Solidity Smart Contracts. These can be compiled by the Solidity compiler to generate bytecode that can be read by the Ethereum Virtual Machine or EVM. Just like Java, indeed! We'll show how it works later on.
Solidity Smart Contracts
With this in mind, let’s envision an exemplary Smart Contract interaction flow. Don’t worry about the code yet, it will be covered later on. Imagine we have a contract that takes input from a normal user by disclosing a function called burnTokens. The rules in the contract require that the transaction to trigger this function has to come from a certain wallet address, so only the person holding the right private key is allowed to call it. There are several ways you can design a Smart Contract architecture, but for the sake of this tutorial we're not going to make things overcomplicated. Our simplified Smart Contract demo architecture is shown below.
I understand this might seem a bit abstract at first sight, but it’s actually super simple, really. Every box is a separate Smart Contract, which is also visible by the .sol file extension. Now focus on the two contracts in the lower half of the diagram. These are the ones of interest in this blog. I added the three upper contracts as well to give you the full picture and to demonstrate the importing and interfacing capabilities of Smart Contracts. Just like in object-oriented programming, contracts can be implemented, inherited or imported as a dependency by other contracts. We can see that both the TokenController and Token contracts require SafeMath as a dependency, which is a small library defining safe mathematical operations. On top of that, the TokenController contract also implements ERC223ReceivingContract, while Token implements ERC223Interface. ERC223 is an Ethereum token standard that allows for safe token-to-contract transactions. It is an extension to the popular ERC20 token standard, which lacks this additional safety check. TL;DR? Once we implement ERC223Interface in the Token contract, we end up with a fully ERC223-compliant cryptocurrency! More information, developer docs and resources on Solidity programming can be found here. We're not going to dive too deep in Solidity syntax and all the different types in this series.
Back to our burnTokens function. We find this function in the TokenController contract, as shown by the snippet below:
This function calls another function in the Token contract, which will be responsible for effectively burning the tokens. In the same way, TokenController provides an endpoint to mint tokens via the mintTokens function, which calls the function mint in the Token contract itself. The Token contract code is shown below.
Have a look at this code. As you can see, the contract code is indeed very similar to how a Java class looks like, for example. In the next parts of this series, we’re going to focus on one particular field type in Solidity: the event. This type will allow us to catch events happening in a contract and do something with it. Can you spot the 4 different events in the previous two contracts?
Wrap-up
To finish up this first part of the story, here's a short overview of what we're going to do in the next two episodes:
- Deploy the contracts to an Ethereum PoA private blockchain on Azure
- Mint tokens via the TokenController contract and transfer them around
- Catch events on successful transfers
- Forward the details of these events to Azure Service Bus
- Spread the word within our application landscape
Of course, we're going to tackle this roadmap step by step. First milestones ahead are launching our own Ethereum blockchain leveraging the power of Azure and deploying the Smart Contracts from this episode to it. I guess you are super excited to see this coming to life, so stay tuned for the next part in this series on kickstarting your Ethereum journey on Microsoft Azure!
Happy Solidity coding!
