Maybe you build software products, maybe you’re a consultant or perhaps you work on internal corporate IT estates. I’ve worked in all three environments and for many years I didn’t fully appreciate what Blockchain tech could bring to the table. My opinion at the time was that I had the tools to solve the problems. What I didn’t have enough of, was time and money to build a bigger team and get things over the line faster.

Let me lay out how the Web3 world works through the eyes of a Web2 developer and why I changed my mind. Then you can decide how this tool fits into your solutions and when to use — and when not to.

Let’s Execute Some Code

Let’s jump right in and execute some code, we’ll go back and explain what is going on later.

1. Clone the example repo: https://github.com/thallo-io/blockchain-example
2. Open it in VSCode and ensure you open it in the DevContainer (use the green icon in the bottom left of VSCode -> Open In Container)
3. npm i
4. Run the code via the tests:hh test

You should see a similar output to this:

What Just Happened?

Hardhat 👷‍♀️ is an outstanding modern development environment to compile, deploy, test, and debug your Ethereum software. We have it installed as part of the example repo.

You can find the test code we executed at test/greeter.spec.ts and the Smart Contract code at contracts/Greeter.sol

Here’s an overview of what just happened in our test:

Take a Step Back

Let’s take a step back and talk about the blockchain landscape.

Our code executed inside Hardhat’s EVM compatible implementation. EVM stands for Ethereum Virtual Machine. It’s the runtime in which our Solidity code can execute. Actually solidity compiles down into Ethereum bytecode but we can ignore this technicality for now.

Other blockchains utilise their own runtime, for example Cardano has its own VM and smart contracts are written in Haskell instead of Solidity. Arbitrum uses its own AVM however it is EVM-compatible which means we can continue to write Solidity and have it execute correctly on the AVM. There are many other implementations which I may cover in future articles.

On top of these different runtime implementations we also have running instances of each blockchain. Ethereum has several testnets including Ropsten, Rinkeby and Kovan. Most other blockchains follow a similar convention. The Production environment is called “mainnet” and only ETH (that is, Ether — the base cryptocurrency on Ethereum) on mainnet is worth any actual $$. We just ran our blockchain instance locally using Hardhat’s EVM compatible implementation.

Miners and Validators

I’m not going to go into the nitty gritty here. As developers, our code gets magically executed. That’s all we really care about. Of course if you’re going to actually start using a blockchain for real projects you will need to do your due diligence.

I will however briefly touch on consensus mechanisms. Ethereum currently uses Proof-of-Work (PoW). Super high level explanation: for each block (which contains multiple txs) a miner tries to guess the magic password, it tries many millions of passwords for each block and whoever finds it first gets some ETH that is minted out of thin air.

This is not very environmentally friendly 😔 It uses a lot of electricity just on mindless guessing. Fortunately a new consensus method has been developed called Proof-of-Stake (PoS) which basically involves people locking up a large amount of ETH, then they just run simple validation against the txs and say to the network “this all looks good”. If they fiddle with the data but emit the “all good” to the network, and they get caught (which they almost certainly will do by other validators) they will lose a large chunk of their locked up ETH — this process is called “slashing”. So it is in their interest to be honest.

PoS is awesome because it reduces the energy required by a blockchain network to something like 0.05% of its needs when using PoW. 🌎 thallo is working hard to help allow blockchains and other protocols reduce their carbon footprint to zero, or even be climate positive — read more here!

Ethereum will be moving to PoS in the near future — known as “The Merge”.

Wallets & Accounts

MetaMask

MetaMask is an example of an Ethereum wallet. It’s a Chrome extension that looks after your accounts (explained below).

It also allows JavaScript on webpages you visit in Chrome talk to the blockchain. At a high level this works like this:

JS -> MetaMask -> an Ethereum node

This means you don’t have to run a full Ethereum node which is a heavy task and not in scope for this article. Again, for now, it magically reads from the blockchain and fires txs into it. 🙌

Accounts

In order to execute a tx you need an Ethereum account. This is a public/private key pair. You can generate a new one using MetaMask. Note that this doesn’t communicate with the blockchain, it’s generated locally. The number of available addresses is 2¹⁶⁰ or 1461501637330902918203684832716283019655932542976. So a lot! So the chances of a collision with an existing account is reduced to virtually zero.

What is a Smart Contract

Firstly it isn’t a contract in the legal sense. It’s not an agreement between 2 or more parties or anything like that.

It’s a lump of code (similar to a “class”) which does two things:

1. Stores data on the blockchain through declaring module level variables.
2. Contains logic. Typically the logic will focus on the management of the data — who can update it and who can’t. How can the data evolve etc. Contracts can call other contracts — the calling contract will need to know the address of the contract it is trying to talk to.

As a developer you can write Solidity code and exercise it through writing tests in TypeScript (or JS) and using Hardhat to execute those tests.

Deployment

When you’re ready you can deploy your smart contracts to a testnet such as Ropsten. You’ll need some ETH on the Ropsten network which can be obtained through a “faucet” or by asking the internet kindly via reddit/twitter etc.. You’ll need to setup Ropsten in your Hardhat config and have a key for an API that will allow you to talk to the blockchain easily — Alchemy and Infura are the two most popular ones. Both have free tiers which are good enough for most personal projects.

When you deploy a Smart Contract it will be given an address, which looks something like this: 0x006eCb9efFA194df5ce192AF1e15eFBaa8a3c87b

Anyone can then submit txs and attempt to execute the various methods available on the Smart Contract.

Once ready you can now deploy to mainnet. You will get a new contract address as you’re deploying to a completely different blockchain instance — they aren’t linked in any way.

Updating Code

By default Smart Contracts are immutable — that is, once they are deployed you cannot change their contents. This is very different to what we’re used to in the Web2 world. DevOps processes, coupled with test automation have transformed the way in which we can deliver change into systems. Instead of having monthly, quarterly or even longer delivery cycles, we’re able to deploy to production multiple times a day with a high level of confidence that we haven’t broken stuff, and with zero downtime.

There are patterns you can follow to allow your Smart Contracts to be upgradeable. The details of this are out of scope for this article but you can take a look at the OpenZepplin upgradeable contracts. OpenZepplin produce tonnes of awesome Smart Contracts to inherit from so if you want to create your own fungible token for example, you can simply inherit from the OZ ERC20 contract which will handle most of the logic for you.

Security Considerations

Given that any Smart Contracts you deploy are effectively an API available for the world to execute against you need to be careful that your code doesn’t have any logic issues which would allow a user to do something nefarious, like steal tokens or otherwise corrupt the data.

You will have to be extra cautious if you don’t make your contracts upgradeable!

There are several pit falls new blockchain devs fall into. I won’t go through all of them here — I highly recommend working your way through these CTF style challenges: https://ethernaut.openzeppelin.com/

Remember that all data on public blockchains (e.g. Ethereum) is visible to the world. Even privatevariable’s data is visible — private simply means that one contract cannot access the data directly from another contract.

Typically companies use 3rd parties to audit their Smart Contracts before they get deployed. Consensys Diligence and Quantstamp are well known providers for this service. Because it is a highly skilled and unique task for each customer, its very expensive — do not underestimate this cost when budgeting.

Example Smart Contracts

We already have one example in the GitHub repo, here is another example which is a little tech challenge as part of our hiring process at thallo. Take a look at our open positions! 🧐

Serverless and Gas Fees

Because our code is executed by someone else and the data is stored by the people running a “node” on the network, we don’t have any server costs or maintenance overheads! Pretty awesome!

However, everyone that executes a tx has to pay to have their tx executed and their data stored on the blockchain. In Ethereum this is paid in Ether.

The details of how much a tx costs is a large topic in its own right but at a high level, the more code is executed and the more data is stored the higher the gas fees. So code performance has a direct $ cost to all those who are going to interact with it — you can’t just chuck hardware at it, which is sometimes a viable solution in the Web2 world.

Applications

DeFi

DeFi which is short for Decentralised Finance — is the opposite of TradFi which is short for Traditional Finance. There are a huge number of protocols which range from lending to staking to futures and options contracts and a million other things.

This is the obvious and most utilised function of blockchain tech but there are other problems it can solve too.

Prove Your Data Hasn’t Changed

As a business you may have private data that you wish to prove to your customers hasn’t changed. Imagine you’re an electricity supplier and as you take people’s readings, check their agreed rate and calculate their bill, you store all of this information in a regular database.

It would be feasible for a nefarious actor internally, or a bug in the code to alter old readings and land the customer with a large bill. There would then be a costly dispute process and you’ll probably incur some reputational damage. However if you take a snapshot of all the data each time you take a reading and put it on the blockchain, where it would then be immutable, the dispute is easily resolved.

The issue here is that we’ve just published private customer data on to a public blockchain! What we can do instead is take a hash of this data and store that on the blockchain. This will allow the customer (through an easy to use tool) to compare the hashes and know if the data has changed since it was originally created.

Cross-Organisation Data

Because of the immutability and trust-less ownership of data, blockchain opens opportunities for businesses to share information between each other without duplicating the data in their own infrastructure and setting up costly reconciliation processes.

There are complications here as the Smart Contract code would have to be developed in tandem to ensure that the logic serves both parties. Privacy may also be a concern as transactions between businesses are generally not something the parties want publicly visible.

Conclusion

Blockchain doesn’t solve everything — it’s a tool to be used to complement existing technologies.

I’ve massively glossed over many details and considerations here but I wanted to give you enough to at least write some code and execute it, and have an idea of where this tech sits in the grand scheme of things.

It’s a powerful addition to your arsenal as an architect. Use it wisely!