The Core Operations Underlying Blockchain App Development – InApps 2022

WSO2 sponsored this post.

Blockchain is a linked list (i.e., a chain) of blocks that provides immutable, append-only and shared-data storage. Among other things, blockchain enables decentralization and a distributed consensus protocol for the historical log of shared states for transactional data sharing. Blockchain also supports applications that require tamper-evidence and transparency.

In this article, we introduce a set of principle operations (i.e., core operations) that underline the implementation of the blockchain architecture patterns. Our overview and analysis are based on over 30 different use cases. We have also categorized decentralized applications into four key architecture patterns called identity and access management (IAM), audit-able history or workspace, registry or marketplace; and managed things.

We first describe the core operations that enable design and development of blockchain architecture patterns. Then we take a list of blockchain architecture patterns and show how these core operations compose those blockchain architecture patterns in detail.

Key​ ​Takeaways from this Article:

• Decentralized applications are gaining increasing attention with the proliferation of Blockchain technology;
• Many decentralized applications for blockchains can be created using four architecture patterns;
• Each of the architecture patterns can be composed using four core operations: adding a record, login, sharing a key, and smart contracts;
• The core operations need not be implemented within the blockchain itself, rather can be implemented as a hybrid between the application logic and the blockchain;
• Non-functional application requirements of blockchain applications such as system performance, security, etc. are determined by how these core operations have been implemented.

Core Operations on Blockchains

First, we will describe the four core operations which are fundamental for developing blockchain applications. We list the operations in the increasing order of complexity.

1. Adding a Record to Blockchain

The simplest core operation, “Adding a record to blockchain” adds a new entry to blockchain. In a blockchain, each block contains data, a hash of the data and the hash of the previous block. Once a block is created, a hash is generated. Adding a record to the blockchain simply means adding a new record to the distributed ledger. This involves doing two things. First, we need to collect and validate the information (e.g., transactions), which gets stored into the block. This can be done easily by checking whether sufficient funds are available for adding the record to the blockchain. Second, we need to solve a crypto-puzzle called proof of work that links the newly created (i.e., mined) block to the tail of the existing blockchain.

2. Login (Challenge-Response protocol)

The login is the second core operation for a decentralized application. Login requires the person who tries to gain access to the system to prove that they are the person who they claim to be. This is achieved via a technique called zero-knowledge proof (also known as challenge-response protocol). When implementing Zero-knowledge proof in a blockchain, the person’s Decentralized Identifier (DID) is kept within the blockchain. The person claims he or she is the person listed with the DID by providing information, such as an email address, from the DID to the blockchain. In a secure chat application in blockchain, for example, the user is identified with their email address and a private key they must select to complete the process. However, note the application never sends the private key outside the browser during the execution of the challenge-response protocol.

Figure 1: Blockchain based chat application (a) Login interface (b) Chat interface.

Once the user clicks on the submit button, the process shown in the following diagram takes place. If the private key the user selected in the browser was able to decrypt the random key delivered through a Ballerina API, then the user will get access to the group chat interface shown in Figure 1 (b). If not, the user is directed to an error page.

Figure 2: Process of Zero-knowledge privacy

3. Share a Key

Sharing a key is a somewhat more advanced operation compared to the login use case. This can also be built by extending the login use case. For example, in the login scenario described above, the random value generated can be used as a secret key that can also be used as the shared key for communication between the browser and the Ballerina API. This means the chat messages exchanged between the browser and the Ballerina service is encrypted with the secret key.

4. Smart Contracts

A smart contract consists of computer code built into the blockchain network where nodes execute. Once the code is executed, the nodes of the blockchain network update the ledger.

Escrow is a legal concept where something of value is held by a third party on behalf of two other parties who are doing a transaction. An Escrow is needed when the two parties involved in the transaction are uncertain about whether one party or another will be able to meet their obligations. An escrow account eliminates the need for an intermediary in order for a transaction to be completed. An escrow contract is also a special type of smart contact. An example of escrow is shown below.

Listing 1: An escrow contract written with the Solidity programming language:

The Application of Core Operations for Blockchains

We now describe how the blockchain architecture patterns have been implemented using the above-mentioned core operations.

Currently, multiple decentralized applications in use in the industry exist. For example, Barclays and Wave have setup a platform to execute global transactions using blockchain technology. Online platforms such as Augur create global decentralized prediction markets. IBM and Walmart work together to digitize the food supply chain process using blockchain. Among the advantages, blockchain allows organizations to have multiple copies of data as well as smart contracts when brokering an agreement with third parties.

Blockchain applications follow a few noteworthy architecture patterns:

1. Identity and access management (IAM);
2. Auditable history or workspace;
3. Registry or marketplace;
4. Managed things.

We will now describe how these architecture patterns are implemented with core operations.

Identity and Access Management (IAM)

Decentralized Identifiers (DIDs) serve as a novel way to verify digital identity. They are also fully autonomous since they are fully under the control of the subject of the DID without depending on any centralized registry, certificate authority or identity provider.

An Identity and Access Management (IAM) blockchain architectural pattern supports most identity and access management use cases. It is based on W3C DID specification and World Wide Web Consortium’s verifiable claims specification. If someone (e.g., Alice) requires an identity, blockchain can create a randomly generated identifier and use that as the DID.

Implementation of Identity and Access Management (IAM)

How blockchain core operations help for implementing the IAM pattern can be explained as follows: Let’s take the scenario where Alice needs an identity (i..e, DID). Alice first creates an entry in the blockchain, which includes a randomly generated identifier, a link to the repository, including user’s profile data and a hash of the profile data. The user profile contains a public key and a set of verifiable claims. Based on the verifiable claims, the generated random identifier becomes Alice’s DID.

Figure 3: Identity and Access Management architecture pattern.

The core operation login (i.e., Zero-Knowledge Proof) is used by Alice to demonstrate her ownership of the account. For example, as mentioned above, an organization that wants to identify Alice may generate a random seed, encrypt it with Alice’s public key listed under Alice’s profile data and then ask Alice to demonstrate that she has the private key by decrypting the encrypted seed.

Auditable History or Workspace

This category of applications provides an auditable history or an auditable shared workspace. Here the blockchain has been used as the system that records activities and creates entries in the blockchain for those records. Since blockchains cannot be tampered, the records can’t be disputed later.

Implementation of History or Workspace

In this particular architecture pattern, the system provides an auditable history or an auditable shared workspace. The system records activities and creates entries for blockchain for those records. Since each entry contains a hash of the activity records, they can’t be disputed at a later time. For example, let’s take news feed aggregator service scenario developed with blockchain.

Figure 4: News feed aggregator service scenario based on history pattern.

In this case, the news reporter (Alice) can prove her identity in the blockchain using verifiable claims using Zero-Knowledge Proof when she is entering hashed keys of her news reports into the blockchain. The verifiable claims can be issued by both governmental and non-governmental entities. Due to the immutable nature of the blockchain, the news consumer can make sure the information he or she receives is originally from Alice and has not been altered by third parties.

Registry or Marketplace

A registry is a collection of data that users can look up. The registry may also perform as a marketplace that supports buying the item in some form. A registry, for example, may contain available APIs. If the data to be stored becomes large, the blockchain record may contain a link to the data and give it a hash value. The blockchain may also work as a “service marketplace” where the same service is sold multiple times. Due to performance limitations, blockchain-based marketplaces are not suitable for items that can be sold only once.

Implementation of Registry or Marketplace

When a user invokes add/update registry operation, the blockchain is updated with the information. The update operation is implemented with the core operations use to add a blockchain record. The identity of the user who carries out the add/update registry operation is also verifiable via Challenge Response Protocol.

Figure 5: Registry architecture pattern.

As shown in Figure 5, the registry client can maintain a database to store data and index it. In this scenario, registry client needs to periodically check the blockchain and should update the registry.

Managed Things

The concept of “blockchain managed things” merges the behaviors that are governed by the blockchain into managed things. For example, below is an example of how we can implement a blockchain for the purchase of a car.

The Implementation of ‘Managed Things’

The blockchain managed things enables the behaviors of the artifacts to be governed by blockchain. Let’s consider the managed “thing” to be a car (See Figure 6). In this scenario, a manufacturer records the DID and the public key and compares them against the owner against the car. When the ownership of the car changes from the current owner to new owner, the current owner adds a new record in the blockchain specifying the new owner.

When the car owner’s identity is verified, for example, all relevant records in blockchain are verified to check that each record was added by the current owner. This can be done by checking the public key of the user who wrote the record against the public key included in the previous ownership record. The last record in this valid chain is the current owner of the car. Once the car determines the public key of the current owner (Alice), the car’s verification system does a Challenge Response Protocol based on login with Alice’s phone, which has Alice’s private key information.

Figure 6: The “managed things” pattern.

Conclusion

We have listed and described four core operations that can be used to develop most decentralized applications with blockchain. We categorized blockchain architecture patterns into four areas as identity and access management, auditable history or workspace, registry or marketplace and managed things. We also described how these core operations can be applied to the blockchain architecture patterns.

Additionally, we have created a group chat application that provides more information about blockchain and describes how some of these core operations help to build these such blockchain applications.

The characteristics of non-functional characteristics of a blockchain application such as system performance and information security are largely determined by how these core operations have been implemented. Hence, we emphasize the importance of investigating more details of such non-functional characteristics associated with these core operations in future.

Feature image via Pixabay.