As the number of transactions conducted on the Hedera network increases, so does the FUD around what these transactions actually represent. This FUD is exacerbated by other networks that function differently from Hedera, and may stretch the truth of what a transaction actually is. So, once and for all, let us note that Hedera Consensus Service (HCS) transactions are not required for the Hedera network to reach consensus and Hedera's publicly reported transaction count does not count the intra-node gossip communication needed to arrive at consensus.
We believe that no honest count of transactions should include 'how we internally came to consensus on the order of whatever volume of transactions were submitted by external parties’, however that might be done on different ledgers. So that’s not included in our transaction counts. What is included in Hedera’s transaction/TPS counts? When a user or system does the following things, these are transactions on Hedera: https://docs.hedera.com/hedera/sdks-and-apis/sdks/transactions
Some examples include:
Sending hbars from one address to another
Deploying a new smart contract to the Hedera network
Interacting with an existing smart contract by calling its functions and methods
Creating a new fungible or non-fungible token using the Hedera Token Service
Participating in decentralized finance (DeFi) applications such as lending, borrowing, or trading cryptocurrencies
Receiving and recording carbon emissions data for billions of specific products, using the Hedera Consensus Service
Creating an immutable log of legal documents and their delivery to end users, using the Hedera Consensus Service, ensuring that it hasn't been modified.
Using the Hedera Consensus Service (HCS) to enable notification to applications, wallets, exchanges, explorers, etc., that may be interested in building supporting infrastructure for a set of tokens, and signaling to those stakeholders which tokens have been certified as conforming to the rules of a specific token creator.
When nodes in the Hedera network use gossip protocol to communicate with each other to arrive at a consensus, those are NOT transactions that are counted, or can even be tracked in the transaction count, on Hedera.
The Hedera Consensus Service and the hashgraph consensus algorithm are often confused due to their similar names, but they are two distinct concepts. The hashgraph consensus algorithm is responsible for achieving fair, fast, and asynchronous Byzantine fault-tolerant (aBFT) consensus among all nodes in the Hedera network. It accomplishes this through concepts such as gossip about gossip and virtual voting, which make the process secure and immune to attacks that are common in leader-based consensus algorithms. This consensus algorithm forms the platform layer of the Hedera proof-of-stake network.
The operations that happen behind the scenes to achieve consensus on Hedera (to fairly timestamp and order transactions submitted to the ledger) do not themselves involve additional transactions or transactional overhead included in our publicly reported transaction count.
Even when Hedera provides this timestamping and fair-ordering capability to other external client applications through the Hedera Consensus Service, the underlying operations are not included in our publicly reported transaction count.
The Hedera Consensus Service (HCS), like the Hedera Token Service (HTS) and the Smart Contract Service, are services that sit on top of the Hedera public network. Just as making a request of the ledger itself (for example, sending cryptocurrency from one account to another) constitutes a transaction for which fees are paid to the ledger (because it's using the compute/network resources of the ledger), the same is true for any other request that comes through HCS, HTS, or the Smart Contract Service.
Each of these requests is ultimately serviced by the ledger, recorded on the ledger as a transaction, and the requestor pays a customary fee to the ledger that covers the associated compute/network resource costs. Each of these requests unequivocally represents a transaction where a user of Hedera paid the network for its utility; the very definition of a transaction and in volume, an honest representation of the degree to which Hedera is getting adopted by organizations large and small. These third party requests account for over 99.999% of Hedera's publicly reported transactions. These transactions and the users of Hedera who initiate them speak to our vision that the inherent capabilities of DLT have enormous applications outside of the ledger itself.
The Hedera Consensus Service is being used today by a number of applications and users, delivering real-world value and offering Web3 solutions to age-old problems. We believe that massive, high-throughput, high-scale adoption is the future of distributed ledger technology, and Hedera happens to have the most of these transactions of any ledger today. Some examples include:
Atma.io (from Avery Dennison) is using HCS to provide support for sending product lifecycle events such as creation, shipping, and sale, for billions of products, to Hedera. Recording these events with Hedera Consensus Service establishes an immutable and verifiable history for every product.
HCS is utilized in the new AI8112 Digital Coupon Standard by The Coupon Bureau. Each coupon creation and redemption is tracked. At each stage of the coupon lifecycle a transaction is sent to Hedera using the Hedera Consensus Service. The fast, low-cost API provides the Coupon Bureau and its partners a single, trusted view. Each transaction sent to Hedera returns a consensus timestamp with strong ordering guarantees to affirm the active state of the coupon. Since Hedera is a public network, each authorized party is able to see the latest updates and, optionally, store the data in their database of choice.
ALT/AVE uses HCS for document sharing. 'docStribute uses Hedera Consensus Service to record and track immutable document sharing. By sending a hash of the document to the ledger, both ends of the communication know the information being shared has not been tampered with. Companies are thus able to do more digital exchanges in an effort to increase efficiency, reduce paper waste, and lower their carbon footprint.'
Hala Systems’ Sentry application enables civilians to capture images and record video to act as an early warning system during conflicts and humanitarian crises. Hala uses HCS to log their content’s metadata from the Sentry application. Each creation event records over 30 pieces of information to the Hedera network, receiving a verifiable and tamper-proof audit log to provide to potential 3rd parties.
AVC Global’s supply chain platform is anchored by HCS, integrated with Hyperledger, to exceed their requirements for high-throughput, encrypted content, trusted timestamps and ordering, and fast finality at a global scale.
Theom is a fully managed Cloud Data Protection Platform that uses HCS and Hedera’s “proof-of-action” implementation to create a high-throughput, immutable, and verifiable log of events on the public Hedera network — akin to a decentralized messaging bus.
If you want to learn how to work with HCS, you can visit the learning guide here: https://docs.hedera.com/hedera/tutorials/consensus/submit-your-first-message
The Hedera consensus algorithm uses gossip about gossip and virtual voting to reach a consensus. You can learn more here: https://docs.hedera.com/hedera/core-concepts/hashgraph-consensus-algorithms