Blockchain consensus-as-a-service

Blockchain consensus-as-a-service: what is this service, who would want to use it, and how does it benefit the receiver?

As we all know, a certain kind of consensus mechanism is necessary to validate transactions on a blockchain network. Different blockchain protocols adopt different consensus mechanisms, such as proof of work, proof of stake, proof of concept, and proof of history. This act of validating transactions through decentralized consensus offered by the network nodes builds trust in the data stored in a blockchain. The more distributed a network is, and the more validator nodes it has, the more reliable the data becomes.

However, when we talk about blockchain as an enterprise-grade solution, it is evident that businesses prefer building their applications using industry-standard permissioned blockchains or distributed ledger frameworks. This preference is to achieve increased privacy because of the sensitive nature of the data they deal with. But  data from private permissioned blockchain networks or dApps lack the fundamental element of public trust because they rely on nodes operated by one or a few parties, so the level of distribution is low.

So, is there a solution for enterprise applications to retain the privacy of sensitive data while also achieving decentralized consensus? This is where consensus-as-a-service can help. The blockchain consensus service is mainly used by applications that handle private or proprietary data but want to benefit from the decentralized trust, fast ordering, and immutable recording of a public ledger. In the next section, we will learn more about consensus-as-a-service, its benefits, and its mechanism.

• What is consensus as a service?
• Why is consensus as a service needed?
• What are the advantages of consensus as a service?
• How does a consensus as service model work?
• The architecture of the Hedera Consensus Service

What is consensus as a service?

As the name suggests, it is a third-party blockchain consensus service offered to private or permissioned blockchain networks or applications for validating their order of events or transactions. A public distributed ledger technology (DLT) network can offer this kind of service. For the sake of understanding, consider that a public distributed ledger like Hedera can provide consensus service to private and permissioned blockchain networks like Hyperledger Fabric and R3 Corda.

The service-providing network validates the order of events in a permissioned network by timestamping them, and thus creates transparent and auditable logs. Private chains can take advantage of consensus-as-a-service without sharing the persistent history of transactions in their network.

In a nutshell, consensus-as-a-service is an offering that combines trust and privacy. The service allows permissioned networks or applications to retain the privacy of their sensitive data while also providing them the advantages of trusted timestamps, high transaction throughput, fast finality, and security from a public ledger.

Consensus-as-a-service delivers decentralized trust that helps business and consumer applications eliminate the need to rely on expensive intermediaries to facilitate trust between parties.

Why is consensus as a service needed?

Blockchain as a technology holds so much value because it can timestamp the order of events for financial services, IoT, or supply chains in an immutable way and create verifiable logs dictating everything from financial transactions to meaningful asset provenance.

But because private applications rely on the consensus provided by smaller networks of known and permissioned nodes, they lack public trust, which is central to web 3.0. Consensus service can add that much-needed layer of trust. Any application or permissioned network that requires executing logic based on the specific time and order of events (e.g., for data auditing or reconciliation) can benefit from consensus service.

In the absence of such a service, these applications rely on moderation, matching, and ordering performed by single entities. This has three major downsides:

• The applications become prone to unintentional network outages or intentional manipulation of a service.
• They face the risk of collusion by a small number of parties.
• They become subject to the cost model of centralized infrastructure providers.

To achieve decentralized consensus, permissioned networks or applications also have the option of using public ledgers like Bitcoin and Ethereum, where they can select a block producer through proof of work. But these public ledgers are slow, expensive, and often take minutes or even hours to confirm the finality of a transaction. The speed of delivering consensus matters, so a public DLT network offering consensus service should be capable of delivering decentralized as well as fast consensus.

What are the advantages of consensus as a service?

In light of the aforementioned problems, it is clear that permissioned blockchain networks or applications compromise on decentralized consensus for achieving data privacy. In that process, they lose the very essence of the blockchain edge.

Consensus-as-a-service provides two key features to solve this problem:

• Decentralized consensus on the validity and order of events
• Transparency of the history of events

A consensus-as-a-service model uses a wider network of distributed nodes to come to an agreement on the time and order of an event. It has the ability to independently verify whether and when an event occurred, and thus can provide timestamps for the events.

The blockchain consensus service model mustn’t rely on storing all events across all members in the network because that will significantly limit the service performance. Thus, the need is for optimized performance in decentralized consensus, which can be achieved through a service model that doesn’t require persisting history of transactions over time and can offload the storage requirements to some other supporting resource or network. This way, the consensus service can provide fast, fair, and secured consensus.

How does a consensus as service model work?

The architecture of a consensus model depends on the abilities of the underlying blockchain protocol. So, there can be different consensus service models that vary in terms of transaction throughput, cost of service, finality, and even mechanism.

To understand the blockchain consensus service model’s mechanism, let’s refer to the popular Hedera Consensus Service. This service by Hedera provides verifiable event ordering and timestamping service for any application or permissioned blockchain network. The Hedera Consensus Service uses the Hedera public network and hashgraph consensus algorithm to validate the events for distinct applications while offloading the storage requirements to computers using the Mirror Network.

The architecture of the Hedera Consensus Service

This consensus service is offered via several SDKs in common programming languages and the Hedera API (HAPI) using protobufs.

The key components of the hedera consensus service are as follows:

• Client application
• SDK interface
• Hedera mainnet nodes
• Mirror net nodes

The following steps illustrate how a permissioned network can avail itself of the consensus service from the Hedera public network:

• The client application submits a message and gives it a topic (an ID number). The topic is important because messages with the same topic are classified together.
• The message from the client application includes the relevant transaction details; the transaction can be a bid on a financial asset or the hash of data stored elsewhere.
• The client application creates a transaction using the Hedera SDK, which allows the application to include the message and the topic.
• Then, the application can send the transaction to single or multiple Hedera mainnet nodes. The client application pays a transaction fee for using the consensus service.
• The Hedera mainnet node checks that the transaction has the necessary information, including signatures, payment, and inputs, and then returns an acknowledgement to the client application confirming that the transaction has met precheck. A sample transaction is shown below:
• Next, the mainnet node gossips or shares the transaction details with the rest of the network.
• The network nodes use the hashgraph consensus algorithm to determine a consensus timestamp for the asked event or transaction.
• Once the Hedera public ledger network achieves consensus on the transparency and order of events, it returns a record to the client application stating that consensus has been reached.
• Next, it generates a record, including the consensus timestamp of the topic, the order or the event sequence number for the given topic.
• The sequence number helps interpret the order of the message relative to the other messages with the same topic.
• The record generated by Hedera also includes a running hash of all the messages so far for that topic. A running hash acts as a fingerprint of all the messages so far for that topic.
• All the information (consensus order, consensus timestamps and running hash) generated by the Hedera mainnet is submitted to the mirror node.
• The mirror nodes, on receiving information from the mainnet nodes, calculate the consensus timestamp and generate a state proof themselves.
• Next, the mirror node runs software that implements the application’s business logic to take the results of a transaction from the mainnet, structure and store them using a running hash to create a tamper-proof chain of ordered transactions, and then return results to the client application.

The final thought

As more organizations and businesses continue to use blockchain-powered applications or permissioned networks in their processes, the demand for consensus-as-a-service will grow. Financial services, logistics and supply chain businesses that want to preserve the privacy of their data while benefitting from decentralized consensus can use the consensus service to audit records, match bids, transfer security tokens, or update the status of a good in-transit.

A consensus service provides secure, fast, fair, and decentralized consensus to any application, private ledger-based or not. Also, it helps reduce the cost of operating private networks and improves the trust over both private ledgers and centralized servers.

If you want to use consensus-as-a-service for your applications or develop a consensus service model using your DLT network, we are excited to work on your projects. Please connect with our developers to discuss your project.