Disclaimer: This post is a rough draft, doesn’t and shouldn’t be considered to reflect the opinions or knowledge of my employer, Hedera Hashgraph.

---

Introduction

I will attempt to outline confirmation mechanisms in traditional blockchains such as Bitcoin or Ethereum, and the confirmation mechanisms available in the Hedera Hashgraph public network; which goes beyond blockchain to provide quick, guaranteed, low-latency finality within seconds.

If you’re already familiar with confirmation mechanisms in other networks you can skip directly to the section titled Why Hedera Hashgraph isn’t a blockchain.

Because this is a deeply technical topic in a rapidly evolving field, I’ve attempted to provide a good balance of nuance and conciseness; which is hopefully reflected below.

What’s a confirmation mechanism?

A confirmation mechanism is simply a way to confirm the results of an event.

More formally in this context I’ll define it as an attestation to the success of a given transaction on a network’s state, whether cryptocurrency, a smart contract, a file, or an arbitrary message.

Traditional blockchain confirmation mechanisms

Most traditional blockchains fundamentally, and by design, rely on the premise of “longest chain wins”(1, 2, 3), which means that there’s no single point in time one can guarantee a transaction was successful.

What this means is that you must simply wait until the chain is long enough, i.e. enough subsequent blocks have been added on top of yours to the chain, that it would be sufficiently expensive to build a longer chain.

The more blocks that are “confirmed” to be added to the chain, the more resassurances you have to your transactions success. Most recommend waiting 1-6 blocks, but others such as ATMs rely on 0 block confirmations that have resulted in double spends, the exact issue that traditional Nakamoto blockchains were invented to solve.

Because there is no point in time which a transasction is 100% certain to be successful or not, traditional blockchains can be said to be non byzantine fault tolerant, without the assumptions of an arbitrarily large enough number of blocks provides arbitrarily enough assurance. Given enough money or hashpower in any of these types of networks, one could rewrite history, and revert a transaction (1, 2, 3).

Why Hedera Hashgraph isn’t a blockchain

Hedera Hashgraph is and will be the only public network in the world that is built on Dr. Leemon Baird’s novel hashgraph distributed consensus algorithm.

In my opinion and that of others, it’s a fundamental improvment over the previously popularized algorithms within the same category such as Paxos or Raft (1, 2, 3), which are used in systems such as Google’s Cloud Spanner or Apache Kafka.

Hashgraph itself is asynchronous byzantine fault tolerant, or ABFT, which unlike pbFT (a specific algorithm that can be slightly modified or optimized given an architects particular desires (i.e. the blockchain trilemma)), ABFT is a category of algorithms that has long been considered the “gold standard” of security within the field of distributed consensus (1).

Importantly algorithms that achieve ABFT don’t make any assumptions regarding the amount of time it may take for a transaction to propogate or spread throughout the network, and aren’t reliant on a leader which could prevent consensus from being achieved.

Hedera Hashgraph uses the hashgraph distributed consensus algorithm to yield a replicated state machine, which can be more easily thought of as a distributed datastore, or distributed ledger. Because this concept is unique and far different than that of a traditional blockchain, there are different confirmation mechanisms utilized to check the state of the ledger, which are outlined below.

Hedera’s confirmation mechanisms

When discussing confirmation mechanisms with respect to the Hedera Hashgraph public network it is a way to consider the results of a given transactions effect on the state of the ledger.

Currently Hedera Hashgraph has 4 explicit network services - cryptocurrency, smart contracts, file services, and a consensus service - which have a variety transactions themselves, and there are a variety of implicit services within those, each with their own transactions - such as claims and revocations.

When a tramsaction is submitted to the Hedera Hashgraph network it is submitted to any given single node, and anyone can achieve confirmation of it’s success or failure in the following ways from any given single node. Additionally (and hopefully obviously) users could further request the same or different from multiple sources, including from a mirror node upon the eventual release of Hedera’s mirror network.

The confirmation mechanisms available on Hedera Hashgraph are as follows:

Option 1 - Response

When a transaction is submitted to the network, the node it was submitted to will perform a “precheck” of the transaction and provide the client which submitted it a response. Essentially this confirmation mechanism allows you to know whether or not a given transaction was properly structured and that there were enough fees included to perform the transaction.

If this node determines that the transaction was properly structured and there’s a sufficient amount of “gas” (or fees) supplied, this node will then submit the transaction to the rest of the Hedera Hashgraph network.

Actual Cost	Reassurance	Estimated speed
Free	Low	< 1 second

Option 2 - Generic Query

One option for confirming that a transaction was successful is capturing a “before and after” snapshot of the state through subsequent queries.

For example, if one wants to know whether or not a cryptocurrency transfer was successful, simply query the balance of the recieving account before and after the transaction to confirm whether or not it was recieved.

Relative cost	Reassurance	Estimated speed
Low	Low - medium	< 1 second

Option 3 - Receipt

Once a transaction is successful, and it’s results are either applied or not applied to the state of the ledger (with finality), all nodes will generate what’s called a receipt of this transaction.

After this receipt is generated by the network, a client or user can then query (from option 2) any node(s), or mirror node(s) for that receipt.

Relative cost	Reassurance	Estimated speed
Low	Medium - High	3-5 seconds

Option 4 - Record

While receipts are generated for free with the transactions that generate them, they do not provide sometimes important details such as the conseusus timestamp, or the results of an individual smart contract function call, from the majority of the network.

If a user or client wishes to have this additional information generated by the network, they will need to request a record and additionally pay for it’s computional burden alongside the fees with the initial transaction.

After this record is generated by the network, a client or user can then query (from option 2) any node(s), or mirror node(s) for that record.

Relative cost	Reassurance	Estimated speed
Medium	Medium - High	3-5 seconds

Option 5 - State proof

State proofs are by far the most secure confirmation mechanism within the Hedera network. State proofs are a collectively signed assertion that a given record is valid from a supermajority of the network at a given time.

If a user or client wishes to have this additional information generated by the network, they will need to request a state proof and additionally pay for it’s computional burden alongside the fees with the initial transaction.

After this state proof is generated by the network, a client or user can then query (from option 2) any node(s), or mirror node(s) for that state proof.

Relative cost	Reassurance	Estimated speed
High	100% guaranteed	3-10 seconds

Note: coming soon (2019-2020)

I highly recommend learning more about state proofs and the underlying merkle trees that provide this functionality in this video by Dr. Leemon Baird starting at 23 minutes.

---

You can learn more about Hedera’s transactions through their documentation, which can be found at docs.hedera.com. Transaction fee prices will be set by the Hedera Governing Council and published prior to Hedera’s Open Access, which is expected sometime during summer 2019.

---

Acknowledgments: This blog post by my colleague Paul Madsen was helpful.

This post doesn’t discuss the notion of rent, which is the fact that someone must continiously pay for the burden of storage of data on the network. Paul has another good post that outlines rent on Hedera Hashgraph which I’d recommend to learn more on this topic.

See an issue? File one on GitHub