This article aims to provide a broad overview of the impact blockchain is having on various aspects of the software industry. We begin by explaining the basic idea behind blockchain, looking at the building blocks it consists of. Then we'll move on to examples of blockchain's application in practice. If you are already familiar with the theory, you can skip straight to the second part with cases.
Blockchain: What kind of blocks, what kind of chain
Imagine a group of mathematicians working together, doing complex mathematical calculations. They combine their results so that by the end of the day they have a common total. For the calculations they have a computer with a rudimentary calculator that produces a "4" for the "2+2" operation and records each calculation so that all the mathematicians can trace the history.
The problem is that mathematicians don't trust each other - just as organisations in real life don't tend to take other organisations at their word. Although all mathematicians should benefit from correct calculations, there is a villain among them who has altered his calculator so that "2+2" turns out to be "5". Just like in "1984".
In this situation, everyone has to recalculate the others' results to make sure they are correct. Obviously, this is a waste of effort. A typical solution to the problem would be a centralised system, something like a shared cloud calculator. However, as already mentioned, the participants trust no one, so the third party in charge of the calculator is just another member of the group who may also have malicious intent. So what to do?
Blockchain comes to the rescue.
The word "blockchain" itself implies a chain of blocks. A block is simply an abstract container for any payload. When a hash function is applied to the entire block and its payload, and the resulting value of the previous block is included in the next block, you have a blockchain. That is, each block is cryptographically linked to the previous block.
Essentially, this makes it impossible to change the contents of any block in between without changing its hash, which in turn changes the hash of the next block, and so on. Thus, in order to change a block, the entire chain following it must be rearranged. This mechanism is the basis of blockchain immutability.
Blockchain as persistent storage is managed by a special programme called a blockchain node. Typically, each node has its own local copy of the blockchain, the "Ledger", and a database storing the most recent state, as in conventional applications, the "World State". Embedded databases (database as library), such as RocksDB or LevelDB, and external databases, such as CouchDB, can be used for a particular blockchain implementation in various combinations.
When multiple nodes are connected via a peer-to-peer protocol, they constitute a blockchain network. Nodes provide an API to send transactions to external applications. A node receives a transaction, then adds it to a pool of pending transactions and propagates it throughout the network.
Depending on the implementation, some nodes have the ability to produce a block: add a transaction from its pool of pending transactions to a new block and then broadcast it to other nodes. To add a new block received from the network to the local copy of the blockchain, each node checks all transactions and applies state changes to the local copy of the Ledger and the State of the World.
But wait, what happens when two nodes are trying to create and broadcast the block with the same number but a different list of transactions?
Transactions and smart contracts
The mechanism that solves this type of problem and many others related to it is called consensus. The consensus mechanism is the part of the blockchain node program that is executed and applied to each new incoming block or incoming transaction. It determines how transactions are captured, i.e., added to a new block. It also establishes rules for block production for all participants in the network and enforces them through penalty mechanisms. For example, if one node behaves maliciously by producing incorrect blocks or forged transactions, the consensus supported by the rest of the network simply does not accept these blocks, or even penalises that node.
There are many types of consensus: Proof of Work, Proof of Stake, Proof of Authority and others. I recommend reading the official Ethereum documentation for more details on blockchain consensus.
A blockchain's payload is usually defined by a list of transactions. Essentially, a transaction is a state transition initiated by an external client. The simplest example of a transaction would be to transfer money from one account to another or, as in our maths example, to call a calculator.
Executing a transaction is an asynchronous process from the client's point of view. It sends a transaction to the network via a blockchain node and then it takes some time for that transaction to propagate across the network and be included in a new blockchain. Thus, the client needs a way to be notified of changes in the state of the target that occur when the transaction of interest is committed. This mechanism is called events.
When a transaction is executed, one or many relevant events occur and are added to the block along with the transaction input parameters and output state changes. For example, when a money transfer transaction is executed, an event occurs (let it be a transfer) with parameters such as "from", "to" and "amount".
Every transaction is cryptographically signed using a private key or another type of key. Transaction authentication is implemented by verifying the signature against the principal that is supposed to be the owner of the private key. In the simplest scenario, the cryptographic public-private key pair is generated, and the public key is used as a user id or account id in the blockchain, whereas the private key is used for transaction signature.
For example, holding the private key is effectively equal to owning the account in a bank where transactions are signed to transfer money from it. It is a common practice to store private keys out of the blockchain either by users themselves or by external vaults.
To build arbitrary business logic in the blockchain, we use smart contracts. A smart contract is a computer program stored on the blockchain and executed by the network via transactions. The smart contract typically consists of one or many functions and state variables that are changed by those functions. The simplest example might be cryptocurrency smart contract with account balances as state variables and a “transfer” function that just decreases the sender’s balance and increases the recipient’s one.
Attack of 51%
Let’s come back to our group of mathematicians and assume that we set up the blockchain for them, so that everybody has their own node and own copy of the blockchain. Then, we deploy a single version of the calculator as a smart contract. The pseudocode of which might look like this:
contract Calculator {
function sum(int a, int b) {
var result = a + b;
log(request.invocator, a, b, result); // save invocation in the history
emit SumEvent(a, b, result); // emit successful execution event
}
}
Now it’s time to consider the benefits that we can achieve with this setup.
Immutability is the first and most obvious benefit, which is an inherent characteristic of the technology. Because the blocks are cryptographically linked, it is impossible to change any of them. The history of all calls to the calculators cannot be changed without making changes to every copy of the blockchain stored on every node, even if one of the participants decides to change his or her own. Consequently, everyone can easily verify that a particular calculation actually took place.
As long as we have a list of all transactions recorded in the blockchain, we can achieve a high level of transparency. All inputs and outputs are stored in each transaction, so they are available to anyone who looks into the blockchain. In our case, any member of the group can view the inputs and outputs of any other calculations and check if they are correct.
The calculator itself is a program running on the blockchain, meaning participants must have a copy of it deployed on their own nodes. Each participant has access to the source code of this program. This means that everyone has the same version of the calculator logic. The blockchain network will only accept calculations made by this version. This in fact provides security — the business logic and rules are enforced by the network majority.
This is where the notorious "51% attack" problem arises. If attackers control 51% of the network nodes, their version of the calculator becomes the correct version (archivistically, rejecting the correct transactions of the malicious nodes). In this way, they control the entire network.
Usually, this problem is solved by the consensus itself, making those who control 51% of the network financially unprofitable, as it requires either massive amounts of energy-intensive computation or huge amounts of storage and warehousing - more than the profits from the attack itself. Moreover, cryptographically signed transactions allow the blockchain to provide authentication, preventing fraud and unauthorised activity, which is one of the security benefits.
In our case, every member of the group can verify that the settlement was indeed made by a specific person. Moreover, given the immutability and transparency, this generally gives a very high level of trust to all who look into the blockchain.
Another important advantage is decentralisation and fault tolerance. Due to the fact that each node stores its own copy of the data, when a few nodes fail, this does not interfere with the rest of the network and the data is still available.
So far, we have considered a rather private type of blockchain, where nodes belong only to a specific group of people or organisations. In contrast, there is the concept of public blockchain, where anyone is allowed to set up their own node and connect to the network, producing and verifying blocks according to consensus. Typical examples are Bitcoin and Ethereum.
Blockchain in DataArt's projects: DApp
DApp or decentralized application is an autonomous service that provides its functionality mainly through a smart contract deployed on a public blockchain like Ethereum.
Let’s consider the example of a decentralized escrow agent as an online service, the function of which is to serve as a third party in a deal between two sides locking and releasing funds while ensuring the terms of a contract. For example, it might be a product or real estate purchase, or a service being provided.
The escrow smart contract exposes functionality to create a deal, accept it from both sides, and deposit funds (e.g., in a value of cryptocurrency). Then funds are released to the seller if the terms of the contract are satisfied and accepted, or to the buyer if something went wrong.
Although a smart contract works without human intervention and is not owned by any one entity, it requires outside involvement when there is a dispute between the parties.
Consider a scenario in which Alice is the client and Bob is the freelancer. Alice, as the client, hires Bob. Both parties sign a contract. However, for some reason Alice is not satisfied with the quality of Bob's services. Bob, on the other hand, thinks that he has done a good job and Alice's claims are unfounded. How do they solve this problem?
Another dApp could be used as decentralised arbitration. The first is a voting system, which is designed to resolve various disputes over transactions in the blockchain community. The system provides appointed arbitrators (51 in total) who have full access to the details dictated by the smart contract entered into by the two parties. The arbitrators are randomly selected by a built-in algorithm to ensure fairness.
Both parties can make accusations and defend themselves by providing supporting evidence for their claims. Finally, based on the resolution of the dispute recorded in the blockchain, the escrow smart contract disburses funds to the winning party.
The integration between the escrow and court smart contracts is also done on the blockchain, so the former trusts the latter and releases funds according to verdicts returned. Thus, a great level of automation is achieved.
A centralized solution where the escrow is represented by an organization or a human might be corrupted or biased in many ways. Also, it might be a case of a service availability issue or outage when funds are locked at a critical point in time. This is not the case in the public blockchain though. These two integrated DApps provide fully decentralized, autonomous, and publicly available services that are key benefits to the end users compared with a centralized solution.
Application Audit Log
There is a common practice of using an audit log for a system to store documentary evidence of the sequence of activities that have affected at any time a specific operation, procedure, event, or device. The target system is audited by a third party. Audit log entries are commonly stored in a centralized database or external service which the auditor has access to. Audit log immutability and access security are crucial for preventing fraud and illegal write/read access.
Let’s consider how blockchain can be used as a storage for log entries. A private blockchain network is set up for the target system and the auditor. The audit log contract is deployed on the network with a permission policy ensuring that only the system of interest can insert logs, and that the audit organization has read-only access. Two parties manage their own nodes. Hyperledger Fabric is a good example of a blockchain implementation that fits our use case well.
Every audit log entry is stored on the blockchain via transaction submission along with a cryptographic proof. Just like in the artificial example of mathematicians and the calculator, the parties might not trust each other, but they do trust blockchain and their own copy of data. Thus, audit log functionality is provided with immutability and a much higher level of security, trust and transparency compared with a common centralized storage.
Payment System
With the advent of blockchain, cryptocurrencies have emerged as a means of payment and electronic exchange. Beforementioned Bitcoin and Ethereum public blockchains are primarily payment systems. Blockchain payment solutions allow customers to make transactions quickly. A user account in such type of a system is represented by a cryptographic keypair. The private key belongs to a user and is never exposed to an external system or a third party.
Because every transaction requires cryptographic proof of ownership made only by that private key, there is no way to make an unauthorized transaction except by stealing the private key. Thus, this mechanism ensures that nobody, even being in authority like in a centralized system, can move users’ funds without their approval.
However, total decentralization and the lack of control in public blockchains make it inappropriate for payment-related business use cases being under high regulations. But still a transparent and immutable ledger has been found pivotal in such scenarios. That is, instead of using traditional payment systems like VISA and banking, a business can leverage its own private blockchain and issue its own cryptocurrency or tokens.
A token represents a particular value to its holder depending on the use case. For example, it might be a stablecoin backed by real estate properties or even carbon mitigation assets. In that case, the blockchain token used as a means of payment or investment is a good alternative to the classic banking system.
These forms of payment are also quicker than traditional solutions since they do not require a financial institution and transactions can be completed across country borders with ease. Moreover, companies choose to use blockchain payments because it enables the creation of smart contracts used to verify and enforce transactions.
