Skip to main content
The Hedera Consensus Service (HCS) enables decentralized event ordering and immutable timestamping for any application. A best practice for data integrity involves anchoring a ‘digital fingerprint’ of your records on-chain, which provides a verifiable audit trail without exposing sensitive information. Merkle roots are cryptographic summaries that enable the efficient verification of large datasets, allowing you to also prove the existence of individual records within a batch. This tutorial demonstrates how to use these tools to verify data on a public ledger like Hedera in a manner that is both highly secure and cost-effective.

What You Will Accomplish

  • Compute a Merkle root from a batch of off-chain records
  • Anchor that Merkle root on HCS using ConsensusSubmitMessage
  • Verify the batch (and a single record) using the mirror node

Prerequisites

Table of Contents

  1. Setup and Installation
  2. Understand the dataset
  3. Create a topic for batch anchoring and verification
  4. Compute the Merkle root
  5. Anchor the Merkle root on HCS
  6. Verify the batch via Mirror Node
  7. Verify a single record (Proof)
  8. Next steps

1. Setup and Installation

1a. Clone and Install

Clone the repository and install dependencies:

1b. Configure Environment

Copy the example environment file:
Open .env and fill in your Testnet credentials:
  • OPERATOR_ID: Your Account ID (e.g. 0.0.12345)
  • OPERATOR_KEY: Your HEX-encoded ECDSA Private Key (e.g. 0x8ccf...)
  • HEDERA_NETWORK: testnet
  • MIRROR_NODE_BASE_URL: Leave as https://testnet.mirrornode.hedera.com

2. Understand the Dataset You Will Anchor

When you ran npm install in Step 1, a postinstall script automatically executed scripts/generate-data-internal.js. This script populated the data/ directory with the sample datasets (batch-10.json and batch-100.json) and their corresponding Merkle proofs. Each record in the generated JSON files looks like this:

Canonicalization

To ensure the hash is deterministic (always the same for the same data), we “canonicalize” the record before hashing. This means:
  1. Sorting the object keys alphabetically.
  2. Removing all whitespace.
  3. Encoding as UTF-8.
This ensures that { "a": 1, "b": 2 } and { "b": 2, "a": 1 } result in the exact same hash.
Canonicalization is the process of converting data into a standard, unique format. It is essential because different representations of the same logical data (like different key orders or whitespace) would produce different hashes, making verification difficult.

Terminology: Batch Hash vs. Merkle Root

  • Batch Hash: Usually hash(record1 + record2 + ...). This approach is simple, but makes it hard to verify any single record.
  • Merkle Root: hash(hash(r1) + hash(r2) + ...). This approach allows efficient batch verification and single-record proofs. This example uses Merkle Roots.

3. Create a Topic for Batch Anchoring and Verification

Run the setup script to create a new HCS topic:
The 01-create-topic.js script initializes the Hedera client and calls the createTopic helper function to mint a new topic ID.
Expected Output:
🚨 Copy the new TOPIC_ID into your .env file.

4. Compute the Merkle Root (Local)

Before anchoring on-chain, calculate the Merkle root locally for the dataset you want to anchor. This example uses the dataset in data/batch-100.json. Run scripts/02-compute-root.js as shown below:
This script performs the following process:
  1. Load Dataset: Reads the JSON file from the data/ directory.
  2. Canonicalize: Standardizes each record to ensure a deterministic hash.
  3. Hash: Computes the SHA-256 hash of each canonicalized record (the leaves of the tree).
  4. Compute Root: Recursively pairs and hashes leaves using computeRoot until a single root hash remains.
Expected Output:

5. Anchor the Merkle Root on HCS

Now that you have the root hash, proceed to anchor it on Hedera. This step recomputes the root for safety and then submits a message to HCS. While you could manually use the root hash from the previous step, recomputing it immediately before submission is a best practice. This ensures the anchor reflects the current state of your local dataset and serves as a final integrity check before committing the hash to the public ledger.
Expected Output:
This approach is efficient because instead of sending 100 individual transactions, you send one transaction with the Merkle root.

6. Verify the Anchored Root Using the Mirror Node

With the Merkle root hash on the public ledger, anyone can verify the batch integrity. Running scripts/04-verify-batch.js confirms this by completing the following steps:
  1. Recompute Root: Loads the local dataset and calculates the Merkle root from your local data/batch-100.json exactly as before using computeRoot.
  2. Fetch Message: Queries the Mirror Node REST API for the latest message on the topic using getLatestTopicMessage.
  3. Compare: Decode the message and verify that the on-chain root matches the locally computed root.
Hedera operates a free/public mirror node for testing and development. Production applications should use commercial-grade mirror node services provided by third-party vendors.
Output:

7. Verify a Single Record Using a Merkle Proof

A powerful feature of Merkle trees is that they enable proving one item is in the batch without revealing the other items. For simplicity, in this tutorial we use pre-generated proofs in data/proofs-100.json. The script takes the single record’s hash and combines it with “siblings” from the pre-generated proof until it reaches the root. If the calculated root matches the trusted root, the record is proven content. Running scripts/05-verify-single-record.js demonstrates Merkle proofs with the following steps:
  1. Load Proof: Reads the pre-generated Merkle proof for the specific record.
  2. Trusted Root: In a real scenario, this comes from HCS (as in step 6). Here we simulate it with a manifest (data/manifest.json).
  3. Verify: Use the verifyProof function to hash the record with its sibling hashes up the tree. If the final hash matches the trusted root, the record is proven.
Output:

Code Check ✅

It’s time to try this example yourself! Get the code from the GitHub repository: tutorial-hcs-batching-hashing-verifying-js

Notes on Message Limits

Message Limits

  • HCS Message Size: 1024 bytes (1 KB).
  • HCS Transaction Size: 6 KB (includes signatures and keys).

Chunking

If your anchor message exceeds 1 KB (e.g., if you added a lot of metadata), you must use HCS Chunking. The SDK handles this automatically if you configure it:
For this tutorial, our anchor message is ~200 bytes, so no chunking was needed.

Next steps


Have a question?

Writer: Ed Marquez, Developer Relations

Editor: Krystal, Senior DX Engineer