Hedera Mirror Node

Search…
Hedera Mirror Node
Hedera mirror node release notes
For the latest versions supported on each network please visit the Hedera status page.
Latest Releases
​v0.56​
MAINNET UPDATE COMPLETED: MAY 18, 2022
TESTNET UPDATE COMPLETED: MAY 17, 2022
This is a big release with support for six different Hedera Improvement Proposals. Most of these changes are on the ingest side of things and future releases will work on adding them to our APIs.
​HIP-16 will enable contract expiry and brings a new auto renew account field that contains the account responsible for any renewal fees associated with the contract. The contract REST APIs now show this auto_renew_account field along with a new permanent_removal flag that is set to true when the system expires a contract.
We missed a requirement in our implementation of HIP-329 CREATE2 opcode to allow a HAPI client to do a native transfer of assets to a contract known only by its CREATE2 address. We fixed this logic gap and now support EVM addresses in a CryptoTransferTransaction.
​HIP-336 saw further polish to our allowance support. Support for an optional spender ID parameter on our /api/v1/accounts/{id}/nfts?spender.id={id} REST API is now included.
​HIP-410 brings with it the ability to wrap an Ethereum native transaction and submit it to Hedera. The mirror node can now parse this new EthereumTransaction along with the results from its execution. Any contracts created or results and logs generated by its execution will automatically show up on the relevant contract REST APIs. Support for specifying the contract initcode directly on a contract create was also added. To support Externally Owned Accounts (EOA) being able to submit Ethereum transactions, we now calculate and store the EVM address of the account's ECDSA secp256k1 alias. Finally, we added support for repeated topics in contract logs REST API to bring it more inline with the eth_getLogs JSON-RPC method. If you supply multiple different topic parameters (e.g. topic0 and topic1) it is considered an AND operation as before, but if pass repeated parameters like topic0=0x01&topic0=0x02&topic1=0x03 it means “(topic 0 is 0x01 or 0x02) and (topic 1 is 0x03)”.
​HIP-415 is defining a block as the number of records files since stream start (AKA genesis). Since only mirror nodes have a full history, they will be used to provide consensus nodes the current block number to update their state. Since partial mirror nodes with an effective start date after stream start won't have all record files, they may contain an inconsistent value for their block number in contrast to other mirror nodes with all data. This release attempts to correct that with a migration to bring them inline with full mirror nodes so everyone has a consistent block number value.
​HIP-423 Long term scheduled transactions enhances the existing scheduled transactions to allow time-based scheduling of transactions. This release adds ingest support for the new schedule-related fields. Next release will expose these fields via our existing schedule REST APIs.
Upgrading
As part of this release, we have finished upgrading our PostgreSQL databases to version 14 and have updated all tests to use that version as well. We recommend mirror node operators plan their migration to PostgreSQL 14 at their earliest convenience. More details on the upgrade process can be found in our database guide.
The migrations in this release are estimated to take up to 2 hours against a mainnet database. However, the migration that takes up the bulk of this time will only run if it needs to correct block numbers. This is only necessary if your mirror node is a partial mirror node and has an effective start date that occurs after the stream start.
​v0.55​
MAINNET UPDATE COMPLETED: MAY 4, 2022
This release is mainly focused on finishing out our support for HIP-336 Approval and Allowance API for Tokens. We added support for the new CryptoDeleteAllowance transaction and removed support for the CryptoAdjustAllowance transaction that didn't make it into the final design. NFT allowances are tracked at the NFT transfer granularity allowing for up to date allowance information on the mirror node. Current spender information will show up in both /api/v1/accounts/{id}/nfts and /api/v1/tokens/{id}/nfts REST APIs. We also added the is_approval flag to APIs that show transfers.
With more developers using computers using Apple's M-series CPUs, it become clear the mirror node needed to support ARM-based architectures to accommodate them. In this release we added multi-architecture Docker images using docker buildx. We now push linux/amd64 and linux/arm64 variants to our Google Container Registry. If there's a need for additional operating systems or architectures in the future it can easily be expanded upon.
We also updated our GCP Marketplace application to the latest version.
​v0.54​
MAINNET UPDATE COMPLETED: APRIL 25, 2022
TESTNET UPDATE COMPLETED: APRIL 19, 2022
This release adds support for three new REST APIs and four HIPs.
​HIP-21 describes the need for a free network info query to enable SDKs and other clients to be able to retrieve the current list of nodes. In v0.49.1, we added a new NetworkService.getNodes() gRPC API. In this release, we're adding an equivalent address book API to our REST API. In addition to the standard order and limit parameters, it supports a file.id query parameter to filter by the two address books 0.0.101 or 0.0.102 and a node.id query parameter to filter nodes and provide pagination.
GET /api/v1/network/nodes
1
{
2
  "nodes": [
3
    {
4
      "description": "",
5
      "file_id": "0.0.102",
6
      "memo": "0.0.3",
7
      "node_account_id": "0.0.3",
8
      "node_cert_hash": "0x3334...",
9
      "node_id": 0,
10
      "public_key": "0x308201...",
11
      "service_endpoints": [
12
        {
13
          "ip_address_v4": "13.124.142.126",
14
          "port": 50211
15
        }
16
      ],
17
      "timestamp": {
18
        "from": "1636052707.740848001",
19
        "to": null
20
      }
21
    }
22
  ],
23
  "links": {
24
    "next": null
25
  }
26
}
Copied!
​HIP-336 describes new Hedera APIs to approve and exercise allowances to a delegate account. An allowance grants a spender the right to transfer a predetermined amount of the payer's hbars or tokens to another account of the spender's choice. In v0.50.0 we added database support to store the new allowance transactions. In this release, two new REST APIs were created to expose the hbar and fungible token allowances. Full allowance support won't be available until a future release when consensus nodes enable it on mainnet.
GET /api/v1/accounts/{accountId}/allowances/crypto
1
{
2
  "allowances": [
3
    {
4
      "amount_granted": 10,
5
      "owner": "0.0.1000",
6
      "spender": "0.0.8488",
7
      "timestamp": {
8
        "from": "1633466229.96874612",
9
        "to": "1633466568.31556926"
10
      }
11
    },
12
    {
13
      "amount_granted": 5,
14
      "owner": "0.0.1000",
15
      "spender": "0.0.9857",
16
      "timestamp": {
17
        "from": "1633466229.96874612",
18
        "to": null
19
      }
20
    }
21
  ],
22
  "links": {}
23
}
Copied!
GET /api/v1/accounts/{accountId}/allowances/tokens
1
{
2
  "allowances": [
3
    {
4
      "amount_granted": 10,
5
      "owner": "0.0.1000",
6
      "spender": "0.0.8488",
7
      "token_id": "0.0.1032",
8
      "timestamp": {
9
        "from": "1633466229.96874612",
10
        "to": "1633466568.31556926"
11
      }
12
    },
13
    {
14
      "amount_granted": 5,
15
      "owner": "0.0.1000",
16
      "spender": "0.0.9857",
17
      "token_id": "0.0.1032",
18
      "timestamp": {
19
        "from": "1633466229.96874612",
20
        "to": null
21
      }
22
    }
23
  ],
24
  "links": {}
25
}
Copied!
Also on the REST API, we added support for HIP-329 CREATE2 addresses. Now any API that accepts a contract ID will also accept the 20-byte EVM address as a hex-encoded string. We improved the performance of the REST API by adding cache control headers to enable distributed caching via a CDN. The performance of the list transactions by type REST API saw a fix to improve its performance.
As part of HIP-260, contract precompile call data now populates new fields amount, gas, and function_parameter inside ContractFunctionResult within the TransactionRecord. Mirror node now stores these fields and exposes them via its existing contract results REST APIs.
There were a number of security improvements made to containerized mirror nodes. All Docker images now run as non-root regardless of running in Kubernetes or Docker Compose. The helm charts saw changes to conform to the Kubernetes restricted pod security standard. This ensures the mirror node runs with security best practices and reduces its overall attack surface. The Kubernetes Pod Security Standard replaces the deprecated PodSecurityPolicy and as such we've removed all configuration related to the latter.
Upgrading
This release has a long migration that is expected to take around 75 minutes to complete, depending upon your database hardware and configuration. As always, we recommend a red/black deployment to eliminate downtime during migrations. If you're using the hedera-mirror-common chart, please check the kube-prometheus-stack upgrade notes to ensure Prometheus Operator can update successfully.
​v0.53​
MAINNET UPDATE COMPLETED: APRIL 7, 2022
TESTNET UPDATE COMPLETED: MARCH 29, 2022
This release is mainly focused around the area of data integrity and ensuring the data in the mirror node is consistent with consensus nodes. To this end, we added an errata database migration that only runs for mainnet and corrects three known issues that impacted the stream files. The state of the consensus nodes was never impacted, only the externalization of these changes to the stream files that the mirror node consumes.
To find the inconsistent data and ensure it stays consistent going forward, we added a new balance reconciliation job. This job runs nightly and compares the balance file information against the record file information to ensure they are in sync. It does three checks for each balance file: verifies the balance files add up to 50 billion hbars, verifies the aggregated hbar transfers match the balance file, and verifies the aggregated token transfers match the balance file. It can be disabled if not needed via hedera.mirror.importer.reconciliation.enabled=false.
We also fixed a bug that caused transfers with a zero amount to show up for crypto create transactions with a zero initial balance. This was due entirely to our code inserting the extra transfers, not because of any problem in the stream files. We also fixed an REST API bug that caused the contract byte code to show up as double encoded to hex.
For the Rosetta API, we added account alias support to various endpoints. And we now support parsing contract results for precompiled contract functions like HTS functions. This capability is disabled by a feature flag and will be enabled in a future release.
Upgrading
This release contains a couple medium sized database migrations to correct the erroneous data in the database. It is expected to take about 45 minutes against a full mainnet database.
​v0.52​
MAINNET UPDATE COMPLETED: MARCH 18, 2022
TESTNET UPDATE COMPLETED: MARCH 15, 2022
​HIP-331 is a community contributed improvement proposal requesting the addition of a new REST API to retrieve an account's list of owned non-fungible tokens (NFTs). The mirror node has an existing /api/v1/tokens/{tokenId}/nfts API to retrieve all NFTs for a given token, but it didn't satisfy the requirement to show NFTs across token classes. This release adds the new /api/v1/accounts/{accountId}/nfts API to satisfy this need. It is our first API with multiple query parameters required for paging and as such has a few restrictions around their use. Please see the OpenAPI description for this API for further details.
GET /api/v1/accounts/0.0.1001/nfts?token.id=gte:1500&serialnumber=gte:2&order=asc&limit=2
1
  {
2
    "nfts": [
3
      {
4
        "account_id": "0.0.1001",
5
        "created_timestamp": "1234567890.000000006",
6
        "deleted": false,
7
        "metadata": "bTI=",
8
        "modified_timestamp": "1234567890.000000006",
9
        "serial_number": 2,
10
        "token_id": "0.0.1500"
11
      },
12
      {
13
        "account_id": "0.0.1001",
14
        "created_timestamp": "1234567890.000000008",
15
        "deleted": false,
16
        "metadata": "bTM=",
17
        "modified_timestamp": "1234567890.000000008",
18
        "serial_number": 3,
19
        "token_id": "0.0.1500"
20
      }
21
    ],
22
    "links": {
23
      "next": "/api/v1/accounts/0.0.1001/nfts?order=asc&limit=2&token.id=gte:0.0.1500&serialnumber=gt:3"
24
    }
25
  }
Copied!
The mirror node now has performance tests written using k6 for all of our APIs. These tests can be used to verify the performance doesn't regress from release to release. In the future, we plan to integrate these into a nightly regression test suite to improve our current approach of testing each release.
A number of deployment issues were addressed in this release. We now disable leader election by default until we can fix the issues with its implementation. Likewise we changed the importer Kubernetes deployment strategy from a rolling update to recreate to avoid ever having multiple importer pods running concurrently. A migration readiness probe was added to the importer. This will mark importer pods as unready until it completes all database migrations. Doing this will ensure Helm doesn't finish its release and run its tests before the migrations are completed.
We continue to fine tune our Rosetta implementation with a number of performance improvements and bug fixes. The performance of the Rosetta get genesis balance script was improved to reduce initial startup time. The embedded PostgreSQL container was upgraded to PostgreSQL 14. The Rosetta unified Docker image was updated to comply with the Rosetta persistence requirements.
​v0.51​
MAINNET UPDATE COMPLETED: FEBRUARY 28, 2022
TESTNET UPDATE COMPLETED: FEBRUARY 25, 2022
This is a smaller release focusing on observability improvements and Rosetta API fixes.
On the observability front, we've reduced the volume of log information the REST API produces in half. We also change the REST API to generate a consistent trace log for all responses that includes accurate client IPs, the elapsed time, and a status code. We reduced the number of time series by about 50% that the mirror node produces to reduce monitoring costs.
For the Rosetta API, we added a workaround for the missing disappearing token transfer issue that allows the check data reconciliation to pass. Overall reconciliation time was improved by tweaking configuration parameters and improving NFT balance tracking performance. We worked around slow genesis account balance file loading by Rosetta CLI by switching to a dynamic account balance loading approach. A number of other Rosetta issues were also addressed.
​v0.50​
MAINNET UPDATE COMPLETED: FEBRUARY 23, 2022
TESTNET UPDATE COMPLETED: FEBRUARY 15, 2022
This release adds support for three new improvement proposals: HIP-260 Smart Contract Traceability, HIP-329 CREATE2 Opcode, and HIP-336 Allowance APIs. It also updates the REST API to reflect the latest phases of HIP-226 and HIP-227 and updates the Rosetta API for HIP-31.
​HIP-260 describes a need for improving the traceability of smart contracts by providing a verifiable trail of contract state changes in the transaction record. The mirror node can now store these state changes and expose them via the contract results REST API to show the values read and written for each slot. This information was added to both /api/v1/contracts/results/{transactionId} and /api/v1/contracts/{id}/results/{timestamp}. Below is an example, with other fields omitted for brevity:
1
{
2
  "state_changes": [{
3
      "address": "0x0000000000000000000000000000000000001f41",
4
      "contract_id": "0.0.8001",
5
      "slot": "0x0000000000000000000000000000000000000000000000000000000000000002",
6
      "value_read": "0xaf846d22986843e3d25981b94ce181adc556b334ccfdd8225762d7f709841df0",
7
      "value_written": "0x000000000000000000000000000000000000000000c2a8c408d0e29d623347c5"
8
    }, {
9
      "address": "0x0000000000000000000000000000000000001f42",
10
      "contract_id": "0.0.8002",
11
      "slot": "0xe1b094dec1b7d360498fa8130bf1944104b7b5d8a48f9ca88c3fc0f96c2d7225",
12
      "value_read": "0x000000000000000000000000000000000000000000000001eafa3aaed1d27246",
13
      "value_written": null
14
   }]
15
}
Copied!
​HIP-329 adds support for EIP-1014 generated contract addresses via the CREATE2 opcode. As part of this, a new evm_address is added to the transaction record that will be present for contract create transactions. Additionally, this evm_address can be populated in any ContractID that appears in the transaction body. The mirror node was updated to be able to map this evm_address to its corresponding contract number and to expose this property on the contracts REST API. We also store full contract information for child contracts since they now appear as separate internal transactions in the record stream, filling a long-standing gap in missing smart contract data.
​HIP-336 allowance functionality allows an account owner to delegate another account to spend hbars or tokens on his or her behalf. This feature provides an implementation of ERC20, IERC20, and ERC721 on the Hedera network. The mirror node was updated to support these new transaction types and store the absolute or relative crypto, fungible or non-fungible allowances. In a later release we will expose this information via a REST API as detailed in the design document.
Multiple new fields were added to the contract REST APIs as outlined in HIP-226 and HIP-227. The fields bloom, result, and status were added to the contract results API response. result and status show similar information with the former being the HAPI response enum while the latter returning 0x1 or 0x0 to show if the transaction was successful or not, as is common in web3 APIs. We also added bloom to the contract logs API response. Finally, we now return a partial response for contract calls without a result.
The importer component added a new hedera.mirror.importer.parser.record.entity.persist.topics property to control the persistence of topic messages. This can be set to false for mirror node operators if topic message data is not being used. On mainnet alone, this data currently takes up to 2TB worth of storage.
The Monitor component gained support for parallel node validation to improve startup performance. Now all validation is done in a background thread, adding and removing nodes as necessary while the publisher thread continues publishing transactions without any interruptions. This re-work also fixed issues with subscription halting during node validation and taking too long to validate a down node.
Rosetta saw a few important improvements including adding support for HIP-31 expected token decimals. The Rosetta unified Docker image saw functionality added to automatically restore the database using a database snapshot on initial startup.
Breaking Changes
As part of HIP-329 CREATE2, we renamed the existing solidity_address in the contract REST API to evm_address. This new name accurately reflects the naming in the HIP and protobuf and avoids tying the address to Solidity when Hedera supports more than just Solidity contracts.
​v0.49​
MAINNET UPDATE COMPLETED: FEBRUARY 15, 2022
TESTNET UPDATE COMPLETED: FEBRUARY 4, 2022
This release implements three Hedera Improvement Proposals (HIPs) and upgrades the mirror node database to the latest version.
​HIP-21 describes the need for a free network info query to enable SDKs and other clients to be able to retrieve the current list of nodes. To satisfy this need we added a new NetworkService.getNodes() streaming gRPC API to get the list of current nodes from the address book network file. By making it a streaming API we avoid the client having to handle paging themselves, while still allowing us to split the large address book into smaller chunks. Since there are two address book files, we provide an option to choose which FileID to return.
1
message AddressBookQuery {
2
    .proto.FileID file_id = 1; // The ID of the address book file on the network. Can be either 0.0.101 or 0.0.102.
3
    int32 limit = 2;           // The maximum number of node addresses to receive before stopping. If not set or set to zero it will return all node addresses in the database.
4
}
5
​
6
service NetworkService {
7
    rpc getNodes (AddressBookQuery) returns (stream .proto.NodeAddress);
8
}
Copied!
​HIP-171 describes the need for returning the payer account in the topic message REST API response. This release does just that while also adding in the topic message chunk information that was present in the gRPC API but missing from the REST API.
1
 {
2
+  "chunk_info": {
3
+    "initial_transaction_id": {
4
+      "account_id": "0.0.1000",
5
+      "nonce": 0,
6
+      "scheduled": false,
7
+      "transaction_valid_start": "1234567890-000000006"
8
+    },
9
+    "number": 2,
10
+    "total": 5
11
+  },
12
   "consensus_timestamp": "1234567890.000000001",
13
   "topic_id": "0.0.7",
14
   "message": "bWVzc2FnZQ==",
15
+  "payer_account_id": "0.0.1000",
16
   "running_hash": "cnVubmluZ19oYXNo",
17
   "running_hash_version": 2,
18
   "sequence_number": 1
19
 }
Copied!
Continuing our support for HIP-32 auto account creation, we added alias support to our accounts REST API. Now when you query /v1/api/accounts/:id the id can be either a Hedera entity in the 0.0.x form or a hex-encoded alias. An account's alias will now also show up in all of the accounts REST API output.
A lot of testing was done to ensure that PostgreSQL 14 functions correctly with the mirror node and provides as good as or better performance to older versions. We are now in the process of migrating our Hedera managed mirror nodes to PostgreSQL 14. We recommend other mirror node operators consider upgrading to the latest database version at their earliest convenience and have provided upgrade instructions to aid in that process.
​v0.48​
MAINNET UPDATE COMPLETED: JANUARY 26, 2022
TESTNET UPDATE COMPLETED: JANUARY 18, 2022
​HIP-206 adds a parent consensus timestamp to the transaction record for internal transactions that occur like HTS precompiles invoked from a smart contract. To round out the nonce support in the last release we added parent_consensus_timestamp to /api/v1/accounts/{id} and /api/v1/transactions. This field helps define the parent/child relationships between transactions.
​HIP-226 describes the recently added contract results REST API. Each release we've been iterating and adding more functionality to the API until it matches the description in the HIP. This release adds the list of logs generated by a smart contract execution. Here's a sample of the new JSON response:
1
{
2
    "amount": 30,
3
    ...
4
    "logs": [
5
      {
6
        "address": "0x0000000000000000000000000000000000001389",
7
        "contract_id": "0.0.5001",
8
        "data": "0x0123",
9
        "index": 0,
10
        "topics": [
11
          "0x97c1fc0a6ed5551bc831571325e9bdb365d06803100dc20648640ba24ce69750",
12
          "0x8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925",
13
          "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef",
14
          "0xe8d47b56e8cdfa95f871b19d4f50a857217c44a95502b0811a350fec1500dd67"
15
        ]
16
      },
17
      {
18
        "address": "0x000000000000000000000000000000000000138a",
19
        "contract_id": "0.0.5002",
20
        "data": "0x0123",
21
        "index": 1,
22
        "topics": [
23
          "0x97c1fc0a6ed5551bc831571325e9bdb365d06803100dc20648640ba24ce69750",
24
          "0x8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925"
25
        ]
26
      }
27
    ]
28
  }
Copied!
In the last release, we added a new Web3 JSON-RPC API. With this release, we've added a hedera-mirror-web3 Helm chart that can be used to deploy it on Kubernetes. Additional metrics were added to the Java module and a new Grafana dashboard was created to visualize them. The Web3 API was also added to the docker-compose file.
Upgrading
If you're upgrading an existing deployment of our Helm chart, there are a few breaking changes to keep in mind. First, we deploy the new Web3 API chart by default and it requires a mirror_web3 database user exist with read permission. Please create the new database user before upgrading or you can disable the hedera-mirror-web3 sub-chart.
We've upgraded the PodDisruptionBudget resources from policy/v1beta1 to policy/v1 and as a result now require Kubernetes 1.21 or greater. For the hedera-mirror chart, if you're using the optional postgresql sub-chart you must scale the PostgreSQL replicas down to one before initiating an upgrade in order to upgrade repmgr.
If you're using the hedera-mirror-common chart, there are a number of breaking changes in the community sub-charts it uses. Before upgrading, you will need to delete the prometheus-adapter and kube-state-metrics deployments. You'll also need to reinstall a few custom resource definitions. Run the below commands to do so:
1
kubectl delete deployment -l app.kubernetes.io/name=kube-state-metrics --cascade=orphan
2
kubectl delete deployment -l app=prometheus-adapter
3
kubectl apply --server-side -f https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/v0.53.1/example/prometheus-operator-crd/monitoring.coreos.com_alertmanagerconfigs.yaml
4
kubectl apply --server-side -f https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/v0.53.1/example/prometheus-operator-crd/monitoring.coreos.com_alertmanagers.yaml
5
kubectl apply --server-side -f https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/v0.53.1/example/prometheus-operator-crd/monitoring.coreos.com_podmonitors.yaml
6
kubectl apply --server-side -f https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/v0.53.1/example/prometheus-operator-crd/monitoring.coreos.com_probes.yaml
7
kubectl apply --server-side -f https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/v0.53.1/example/prometheus-operator-crd/monitoring.coreos.com_prometheuses.yaml
8
kubectl apply --server-side -f https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/v0.53.1/example/prometheus-operator-crd/monitoring.coreos.com_prometheusrules.yaml
9
kubectl apply --server-side -f https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/v0.53.1/example/prometheus-operator-crd/monitoring.coreos.com_servicemonitors.yaml
10
kubectl apply --server-side -f https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/v0.53.1/example/prometheus-operator-crd/monitoring.coreos.com_thanosrulers.yaml
Copied!
​v0.47​
MAINNET UPDATE COMPLETED: JANUARY 3, 2022
TESTNET UPDATE COMPLETED: DECEMBER 30, 2021
This release continues the focus on Smart Contracts 2.0. The mirror node is useful for debugging a smart contract execution and our focus has been on providing APIs to make developers' lives easier. To that end, we added support for transaction ID nonce, a new contract logs REST API, and a new web3 API component.
The new Web3 API module provides an implementation of existing JSON-RPC APIs for the Hedera network. JSON-RPC API is a widely used standard for interacting with distributed ledgers. The aim in providing a Hedera implementation of these APIs is to ease the migration of existing dApps to Hedera and simplify the developer on-ramp. Currently, the Web3 module only provides a partial implementation of the Ethereum JSON-RPC API. Specifically, only the eth_blockNumber method has been implemented in this release as we focused on putting the groundwork in place first.
As part of HIP-32 and HIP-206 a nonce field was added to the TransactionID protobuf to guarantee uniqueness for platform generated transactions. This nonce field was added to any REST API that returns transaction data. A nonce query parameter was added to /api/v1/transactions/:transactionId, /api/v1/transactions/:transactionId/stateproof, and /api/v1/contracts/results/:transactionId to be able to distinguish between a user-submitted transaction and an internal transaction generated as a result of that transaction. Note that /api/v1/transactions/:transactionId without a nonce parameter will default to returning all transactions regardless of nonce while the other APIs will default nonce to 0.
The new /api/v1/contracts/{id}/results/logs REST API provides a search API to query for logs across contract executions for a particular contract. Searching by consensus timestamp and topics is supported. Note that for performance reasons it doesn't currently support pagination and requires a timestamp or timestamp range be provided to search by topic.
​v0.46​
MAINNET UPDATE COMPLETED: DECEMBER 20, 2021
TESTNET UPDATE COMPLETED: DECEMBER 17, 2021
0.46 is a feature-packed release and includes support for three new HIPs, three new REST APIs, a redesigned monitor dashboard, a new BDD test suite for the Rosetta API, and one new module. Let’s dive in!
​HIP-222 adds support for ECDSA (secp256k1) keys to the Hedera network to help improve the developer experience of migrating a dApp to Hedera. The mirror node was updated to be able to parse and store the new key type along with its corresponding new signature. Since this key type is also considered a primitive key like ED25519 (e.g. not a complex key list or threshold key), you can now search for accounts and tokens by their 66-character ECDSA public key. As an added bonus, we now also allow searching by complex public keys that are a key list or threshold key with exactly one primitive key.
​HIP-32 auto-account creation lets a new user receive ℏ via a CryptoTransfer without having already created an account on the network. The mirror node was updated to store the user's alias and map transfers that contain an alias to the newly created account ID. In an upcoming release, we'll add the ability to query for an account by its alias.
​HIP-206 integrates the Hedera Token Service (HTS) into the Hedera Smart Contract Service (HSCS), allowing contracts to transfer, mint, burn, associate, and dissociate tokens programmatically. While support for consensus nodes is still being worked on, the mirror node now has preliminary support for HTS precompiled transactions. This adds a new nonce field to the transaction ID as well as the concept of parent/child relationships between transactions. In an upcoming release, we'll add nonce support and expose parent/child relationships to the REST API.
The REST API saw three new REST APIs created to support the new Smart Contracts 2.0 feature. After executing a smart contract, developers can use the /api/v1/contracts/{id}/results API to search for a contract's execution results by timestamp range or payer account (e.g. from). Once the result is located, the new /api/v1/contracts/{id}/results/{timestamp} API can retrieve detailed information about the smart contract call. If you already know the transaction's ID, you can directly retrieve the smart contract results via the new /api/v1/contracts/results/{transactionId} API. In an upcoming release, we'll add support for logs, state changes, and more to this API. Below is an example response:
/api/v1/contracts/results/{transactionId}
1
{
2
    "amount": 30,
3
    "block_hash": "0x6ceecd8bb224da491",
4
    "block_number": 17,
5
    "call_result": "0x0606",
6
    "contract_id": "0.0.5001",
7
    "created_contract_ids": ["0.0.7001"],
8
    "error_message": "",
9
    "from": "0x0000000000000000000000000000000000001f41",
10
    "function_parameters": "0x0707",
11
    "gas_limit": 987654,
12
    "gas_used": 123,
13
    "hash": "0x3531396130303866616264653464",
14
    "timestamp": "167654.000123456",
15
    "to": "0x0000000000000000000000000000000000001389"
16
}
Copied!
Other miscellaneous changes include now validating the REST API tests against the OpenAPI specification. This should help keep the specification file better in sync with the code until we can fully integrate the specification. The Node.js based monitor dashboard saw a visual refresh in order to make it easier to use. The Rosetta API saw a new suite of crypto and token Behavior Driven Development (BDD) tests. As a result of these tests a number of bugs were found and addressed. Finally, we refactored some common classes into a hedera-mirror-common module to share code with a future API module.
Database Migration
Due to the aforementioned features, we had to make changes to the database schema that may take some time to complete. We've tested the migrations against a mainnet database with 1.9B+ transactions and it completed in around five hours. Mirror node operators may see the migration take more or less time depending upon the size of their data, database hardware, and database configuration flags.
​v0.45.0​
MAINNET UPDATE COMPLETED: DECEMBER 8, 2021
TESTNET UPDATE COMPLETED: DECEMBER 6, 2021
The mirror node now captures the full history of changes that occur to accounts and contracts over time. Prior to this, the mirror node would only maintain the current state of a Hedera entity. With this change, all create, update and delete transactions that occur for an entity will cause a snapshot to be created to represent how it appeared at each of those points in time. This information can be used to query the API for an entity at a particular consensus timestamp in the past.
Currently, this historical lookup option is only supported on the contracts REST API. For example, you can now search for /api/v1/contracts/0.0.1000?timestamp=lte:1609480800 to see the state of the contract 0.0.1000 on January 1st, 2021. Related to contracts, we added new acceptance tests for contract related APIs. The design document was updated to detail new APIs that we are proposing to implement. Those changes are also detailed in Hedera Improvement Proposals (HIPs) for contract results and contract execution logs REST APIs. Please take a look and let us know if you have any feedback.
On the CitusDB front, we continue to make progress. All of our reference tables are now removed in favor of database or application enums. This should help improve performance and streamline the database migration. We've updated our test harness to use the latest version of CitusDB that uses PostgreSQL 14. Finally, we now create distributed tables with entity IDs used as distribution columns for partitioning and co-locate them with other tables as appropriate.
The Rosetta API also saw some improvements including the ability to create accounts online in /construction/submit. An issue with token balance reconciliation was also addressed.
​v0.44.0​
Making progress on transitioning our database to CitusDB, this release adds a new v2 schema with initial support for CitusDB. Automated testing against CitusDB was added to our CI pipeline so that it runs concurrently with the v1 PostgreSQL-based schema. The transaction payer account ID was added to transfer related tables. This will be used as a distribution column for database partitioning across a dimension that is not time-based. This allows the mirror node to scale reads and writes as more transaction payers use the system.
The rest of the release is mainly focused around performance improvements. We no longer persist minimal entity information for every entity ID encountered in a transaction. This was a performance drag but also caused problems with our plans to track entity history in an upcoming release. A few of our reference tables were removed in favor of using an application enum instead to map protobuf values to descriptive strings.
On the REST API, retrieval of accounts by public key was optimized to improve its performance. If your application does not require balance information, you can see additional performance gains by setting the new balance parameter to false for account API calls. The code was optimized to replace Array.concat with Array.push and to cache entity ID construction. The biggest change is probably the potentially breaking change to the limit parameter.
Breaking Changes
The maximum number of rows the REST API can return was changed from 500 to 100. Likewise the default number of rows the REST API returns if the limit parameter is unspecified was changed from 500 to 25. If a request is sent requesting more than 100 it won't fail. Instead, it will transparently use the smaller of the two values. As a result, this should not be a breaking change unless your application makes assumptions about the exact number of results being returned. We may tweak these values in the future for performance reasons so it's good practice to update your application to handle arbitrary limits and results.
​v0.43.0​
MAINNET UPDATE COMPLETED: NOVEMBER 18, 2021
TESTNET UPDATE COMPLETED: NOVEMBER 12, 2021
Smart Contracts
With Hedera's increased focus on Smart Contracts, we took the time to revamp the mirror node's smart contract support and lay the groundwork for future enhancements. As detailed in the design document, plans include new contract-specific REST APIs and Ethereum-compatible APIs in the future.
To prepare for that, the database schema and importer were updated to normalize and store all contract-related information, fixing long-standing bugs like not storing contract bytecode and child contracts. The contract table was split from the generic entity table and work was started on making all the entity tables maintain a history of all changes. The REST API now supports searching for and retrieving specific contracts. Below is an example of retrieving a contract:
/api/v1/contracts/{id}
1
{
2
  "admin_key": {
3
    "_type": "ProtobufEncoded",
4
    "key": "7b2233222c2233222c2233227d"
5
  },
6
  "auto_renew_period": 7776000,
7
  "bytecode": "0xc896c66db6d98784cc03807640f3dfd41ac3a48c",
8
  "contract_id": "0.0.10001",
9
  "created_timestamp": "1633466229.96874612",
10
  "deleted": false,
11
  "expiration_timestamp": "1633466229.96874612",
12
  "file_id": "0.0.1000",
13
  "memo": "First contract",
14
  "obtainer_id": "0.0.101",
15
  "proxy_account_id": "0.0.100",
16
  "solidity_address": "0x00000000000000000000000000000000000003E9",
17
  "timestamp": {
18
    "from": "1633466229.96874612",
19
    "to": "1633466568.31556926"
20
  }
21
}
Copied!
Data Architecture
Over the last few months, work has been underway to analyze possible PostgreSQL replacements as the need for handling an ever-increasing amount of data puts strain on the existing mirror node database. After agreeing upon the acceptance criteria, priority was placed on a PostgreSQL-compatible distributed database that can shard our time-series data across many nodes for scale-out reads and writes. That would ensure the quickest time to market and ease transition for Hedera and others using the open source mirror node software. The four distributed databases we chose for our proof of concept included CitusDB, CockroachDB, TimescaleDB, and YugabyteDB.
After a detailed analysis of each, we chose CitusDB for our next database due to its excellent PostgreSQL compatibility (it's a PostgreSQL extension) and its mature support for sharding time-series data. Its distributed query engine routes and parallelizes DDL, DML, and other operations on distributed tables across the cluster. And its columnar storage can compress data up to 8x, speeds up table scans, and supports fast projections. This release contains some foundational work to get our schema ready for partitioning. You can track our progress as we work towards integrating CitusDB into our codebase over the next few months. We plan on maintaining support for both databases for a period of time after the work is complete.
Performance Improvements
As is usually the case, we took the time to optimize various pieces of the system to work at scale. Our transactions REST API saw some performance improvements by rewriting them using Common Table Expressions (CTE). This will pay future dividends with CitusDB as it allows queries to be ran in parallel easier. An issue with /api/v1/topics/{id}/messages timing out for some topics was addressed and the realm and topic number columns were combined to reduce the table and index size. /api/v1/tokens/{id}/balances also saw some performance improvements that decreased its average response time. Configuration options for faster historical ingestion were documented so that mirror node operators can get historical data faster.
​v0.42.0​
MAINNET UPDATE COMPLETED: OCTOBER 22, 2021
TESTNET UPDATE COMPLETED: OCTOBER 18, 2021
This release saw a lot of improvements to the mirror node's Hedera Token Service functionality. Support for HIP-24 pause feature on Hedera Token Service was completed. The importer can ingest the new token pause and unpause transaction types and update the token appropriately. Likewise, the token REST API was updated to show the new pause key and pause status.
Along those lines, the token REST API was also updated to show the token memo and a flag to show if it's deleted. Now when an account is dissociated from a token its supply will be properly updated to show the negative transfer. And if the token in that dissociate is of type NFT, all of the NFTs owned by that account will be properly marked as deleted. We also fixed issues with some special negative transfer amounts showing up in the transactions REST API.
A new network supply REST API was added to show the released supply. Having the open source mirror node calculate and show the release supply avoids any single point of failure with the current system because a user could ask multiple mirror nodes and compare their answers (or run their own mirror node).
GET /api/v1/network/supply
1
{
2
	"timestamp": "123456870.854775807",
3
	"released_supply": 1800000000000000000,
4
	"total_supply": 5000000000000000000
5
}
Copied!
Continuing our theme of improving the Rosetta API, NFT support was added to the data and construction APIs. We took the time to convert it to a standard configuration library and reorganize the package structure to be flatter and more consistent. And contexts were added to every layer to enable proper cancellation and timeout support.
​v0.41.0​
MAINNET UPDATE COMPLETED: OCTOBER 6, 2021
TESTNET UPDATE COMPLETED: SEPTEMBER 30, 2021
This release focuses our efforts on improving our Rosetta API and making it ready for production use. A new Rosetta Helm chart was added for production deployments to Kubernetes. Observability improvements include health probes, metrics, request logs, alerts, and a Grafana dashboard. Postman integration tests were added to verify post-deployment functionality. Finally, a few important bugs were fixed including missing peer IP addresses and a token balance reconciliation failure.
The importer component was optimized to ingest transactions at 15,000 TPS or higher. This change included improvements to reduce CPU and memory usage while simultaneously increasing the allocated memory available to the process.
Other enhancements include revalidating main nodes periodically in the monitor and adding TLS support for the REST API's database connection.
​v0.40.0​
MAINNET UPDATE COMPLETED: SEPTEMBER 27, 2021
TESTNET UPDATE COMPLETED: SEPTEMBER 16, 2021
This release adds support for HIP-23 Automatic Token Association. This feature allows users to opt-in to receiving fungible or non-fungible tokens automatically as part of a transfer without having to be previously associated with the token. The mirror node now stores these implicitly created associations and returns them via its REST API. Additionally, we show the max_automatic_token_associations in the accounts REST API.
Besides updating it for HIP-23, the REST API saw quite a few other fixes and improvements. The accounts API now displays its memo and the receiverSigRequired field. The REST API packages were renamed to use the @hashgraph NPM package scope. This shouldn't be a breaking change as we don't currently publish those packages to NPM. A number of APIs were fixed to ensure lists were returned in a deterministic sort order. Also, the OpenAPI specification was fixed up so that it accurately reflects the current API and can be used to generate client code. Finally, the schedules API had some performance improvements.
On the monitoring side, we enhanced our Grafana dashboards to make them compatible with Grafana Cloud by adding datasource and cluster drop-downs.
​v0.39.0​
MAINNET UPDATE COMPLETED: AUGUST 31, 2021
TESTNET UPDATE COMPLETED: AUGUST 30, 2021
This release provides compatibility with Hedera Services 0.17 including support for Non-Fungible Tokens (NFTs) and its enhancement to custom fees. For the latter, an NFT creator can set a royalty fee to be charged when fungible value is exchanged for one of their creations and the mirror node has been updated to track this new type of custom fees. Support was also added for effective payer accounts in assessed custom fees and for storing net-of-transfers in fractional fees.
The mostly unused data generator module was removed, resulting in a large increase in code coverage. Coverage has increased from 84% to 92%.
A good amount of bugs were fixed including a crash on REST API startup if the database was down, monitor taking too long to startup, OpenAPI fixes, and more.
​v0.38.1​
MAINNET UPDATE COMPLETED: AUGUST 17, 2021
TESTNET UPDATE COMPLETED: AUGUST 17, 2021
This release is a small bug fix release that contains some important fixes for our mirror node monitoring component. We added a new cluster health check to the monitor that takes into account publishing status. The load balancer uses this health check to determine which cluster to route traffic to. The old health check endpoint didn't take into account whether transaction publishing was active or successful and so would not route traffic to the public mirror node during main node upgrades.
Besides the new health check, the monitor had fixes to its rate calculation at low TPS, not sampling when idle, node validation, and the alerts it generates. The mainnet network configuration of the monitor now points to the public mirror node and we've added the new previewnet node to the previewnet network configuration.
There were also a number of other fixes to clean up code and fix tests. We've made an effort to reduce our code smells as seen in SonarCloud.
​v0.38.0​
MAINNET UPDATE COMPLETED: AUGUST 16, 2021
TESTNET UPDATE COMPLETED: AUGUST 13, 2021
This release wraps up NFT and custom fee support by adding additional test coverage and fixing any remaining bugs. Specifically, NFT support was added to our monitor tool and our acceptance tests. Custom fees was also added to the acceptance tests and had some bug fixes.
Mainnet public saw some monitoring improvements including adding HTTPS support to our external monitor dashboard and the addition of a platform not active alert that inhibits all other alerts.
There were a number of bug fixes in this release. The stream file health check that was disabled in the last release due to a bug was fixed and re-enabled. The address book update flow saw a couple of important fixes as well.
Breaking Changes
The payer account ID in transaction assessed custom fee REST API response was removed. This is a change in services 0.16 whereby custom fees are now charged from the account who send the triggering tokens, not necessarily the payer of the transaction.
​v0.37.2​
MAINNET UPDATE COMPLETED: AUGUST 4, 2021
TESTNET UPDATE COMPLETED: AUGUST 5, 2021
A small bug fix release that addresses some issues with our HIP-18 support.
​v0.37.1​
MAINNET UPDATE COMPLETED: JULY 29, 2021
TESTNET UPDATE COMPLETED: JULY 15, 2021
This release broadens our support for non-fungible tokens (NFTs) with new NFT-specific REST APIs. A new API was added to return a list of NFTs for a particular token ID. We also added a new API to return a single NFT by its token ID and serial number. Finally, we added an API to see the transaction history for a particular NFT. In an effort to have more manageable REST API code, we now adopt a more object-oriented approach by utilizing models, view-models and services. Below is an example of the three new APIs:
GET /api/v1/tokens/0.0.1500/nfts
1
{
2
  "nfts": [{
3
    "account_id": "0.0.1002",
4
    "created_timestamp": "1234567890.000000010",
5
    "deleted": false,
6
    "metadata": "ahf=",
7
    "modified_timestamp": "1234567890.000000010",
8
    "serial_number": 2,
9
    "token_id": "0.0.1500"
10
  },{
11
    "account_id": "0.0.1001",
12
    "created_timestamp": "1234567890.000000009",
13
    "deleted": false,
14
    "metadata": "bTM=",
15
    "modified_timestamp": "1234567890.000000008",
16
    "serial_number": 1,
17
    "token_id": "0.0.1500"
18
  }],
19
  "links": {
20
    "next": null
21
  }
22
}
Copied!
GET /api/v1/tokens/0.0.1500/nfts/1
1
{
2
  "account_id": "0.0.1001",
3
  "created_timestamp": "1234567890.000000008",
4
  "deleted": false,
5
  "metadata": "bTM=",
6
  "modified_timestamp": "1234567890.000000009",
7
  "serial_number": 1,
8
  "token_id": "0.0.1500"
9
}
Copied!
GET /api/v1/tokens/0.0.1500/nfts/1/transactions
1
{
2
  "transactions": [{
3
    "consensus_timestamp": "1234567890.000000009",
4
    "transaction_id": "0.0.8-1234567890-000000009",
5
    "receiver_account_id": "0.0.1001",
6
    "sender_account_id": "0.0.2001",
7
    "type": "CRYPTOTRANSFER"
8
  }, {
9
    "consensus_timestamp": "1234567890.000000008",
10
    "transaction_id": "0.0.8-1234567890-000000008",
11
    "receiver_account_id": "0.0.2001",
12
    "sender_account_id": null,
13
    "type": "TOKENMINT"
14
  }],
15
  "links": {
16
    "next": null
17
  }
18
}
Copied!
​v0.36.0​
MAINNET UPDATE COMPLETED: JULY 19, 2021
We are happy to announce the availability of a publicly accessible, free-to-use, mainnet Mirror Node operated by the Hedera team. As part of this, we put a large amount of effort into fine-tuning our Kubernetes deployment. We migrated to Flux 2, a GitOps-based deployment tool that allows us to declaratively specify the expected state of the Mirror Node in git and manage our rollouts. You can browse our deploy branch and see the exact config and versions rolled out to various clusters and environments. The Helm chart was updated to add PodDisruptionBudgets, adjust alert rules and other improvements to make it easier to automate the deployment.
This release is the first version of the Mirror Node with preliminary support for non-fungible tokens (NFTs). NFT support is being added to the Hedera nodes as outlined in HIP 17. We spent time designing how that NFT support will look like for the Mirror Node. Modifications to the schema were made to add new tables and fields and the Importer was updated to ingest NFT transactions. The existing REST APIs were updated to add NFT related fields to the response. This includes adding a type field to the token related APIs to indicate fungibility and anft_transfers to /api/v1/transactions/{id}:
1
{
2
  "transactions": [{
3
      "consensus_timestamp": "1234567890.000000001",
4
      "name": "CRYPTOTRANSFER",
5
      "nft_transfers": [
6
        {
7
          "receiver_account_id": "0.0.121",
8
          "sender_account_id": "0.0.122",
9
          "serial_number": 104,
10
          "token_id": "0.0.14873"
11
        }
12
      ]
13
  }]
14
}
Copied!
One thing to note is that we did not add NFT transfers to the list transactions endpoint in an effort to reduce the size and improve the performance of that endpoint. In the next release, we will add new NFT specific REST APIs.
Continuing upon the theme of the last release, we made additional changes to the Rosetta API to bring it up to par with the rest of the components. Rosetta now includes support for HTS via both is data and construction APIs.
The Importer saw a large focus on improving performance and resiliency. It is now highly available (HA) when run inside Kubernetes. This allows more than one instance to run at a time and to failover to the secondary instance when the primary becomes unhealthy. A special Kubernetes ConfigMap named leaders is used to atomically elect the leader.
We’re improving our ingestion time dramatically for entity creation. Previously those were database finds followed by updates. Since inserts are always faster than find and updates, we’ve optimized this to insert the updates into a temporary table and at the end upsert those to the final table. A record file with 6,000 new entities went from 21 seconds to 600 ms, making it 35x improvement. Balance file processing was optimized to greatly reduce memory by only keeping one file in memory at a time.
Breaking Changes
In honor of Juneteenth and as part of the general industry-wide movement, we renamed our master branch to main. If you have a clone or fork of the Mirror Node Git repository, you will need to take the below steps to update it to use main:
1
git branch -m master main
2
git fetch origin
3
git branch -u origin/main main
4
git remote set-head origin -a
Copied!
As part of our optimization to reduce memory usage, we now process some things earlier in the lifecycle. Due to this we had to rename some properties to reflect this change. We also changed the disk structure if you are using the keepFiles (now renamed to writeFiles) properties to write the stream files to disk after download. It is no longer archived into folders by day. Instead, the folder structure will exactly match the structure in the bucket. This opens the possibility for a mirror node to download and mirror the bucket itself using a S3 compatible API like MinIO. Below is a summary of the renamed properties:
Renamed hedera.mirror.importer.downloader.balance.keepSignatures to hedera.mirror.importer.downloader.balance.writeSignatures
Renamed hedera.mirror.importer.parser.balance.keepFiles to hedera.mirror.importer.downloader.balance.writeFiles
Renamed hedera.mirror.importer.parser.balance.persistBytes to hedera.mirror.importer.downloader.balance.persistBytes
Renamed hedera.mirror.importer.downloader.event.keepSignatures to hedera.mirror.importer.downloader.event.writeSignatures
Renamed hedera.mirror.importer.parser.event.keepFiles to hedera.mirror.importer.downloader.event.writeFiles
Renamed hedera.mirror.importer.parser.event.persistBytes to hedera.mirror.importer.downloader.event.persistBytes
Renamed hedera.mirror.importer.downloader.record.keepSignatures to hedera.mirror.importer.downloader.record.writeSignatures
Renamed hedera.mirror.importer.parser.record.keepFiles to hedera.mirror.importer.downloader.record.writeFiles
Renamed hedera.mirror.importer.parser.record.persistBytes to hedera.mirror.importer.downloader.record.persistBytes
​v0.35.0​
MAINNET UPDATE COMPLETED: JULY 8, 2021
TESTNET UPDATE COMPLETED: JUNE 21, 2021
Most of the changes in this release were operational improvements around our Kubernetes deployment. These changes were necessary as we begin to convert more environments from virtual machines to Kubernetes-based. We added our acceptance tests to the Helm chart so that it can trigger automatically during upgrades and verify the deployment was successful. On the importer, we added a new health check to the probes that verifies that stream files are successfully being parsed. And we fixed the importer so that the probes are started before long-running database migrations, allowing us to finally enable its liveness probe. There were a lot of smaller fixes to the charts, so please see the linked PRs for further details.
The monitor saw a brand new REST API that lists active subscriptions. This is used in our cluster to determine overall cluster health and route traffic via our load balancers. We added an OpenAPI spec and Swagger UI for this API as well.
Special thanks to @si618 for fixing the build on Windows and adding a GitHub workflow to make sure it stays fixed.
And also thanks to @safinbot for addressing some errors in our REST API OpenAPI specification.
Breaking changes
The REST API maximum and default limit was lowered from 1000 to 500. If you explicitly send a number of more than 500, your request will fail. Please update your client code appropriately.
​v0.34.0​
MAINNET UPDATE COMPLETED: JUNE 16, 2021
TESTNET UPDATE COMPLETED: JUNE 11, 2021
In Hedera Mirror Node v0.34.0, we started work on designing support for NFTs that will come in a future Hedera Services release.
By default, the mirror node will validate that at least one-third of all nodes in the address book have signed a stream file before importing it into its database. This ensures that the main nodes have reached two-thirds consensus on the transactions in the file. For performance or verification reasons, you may want to decrease or increase this default percentage. To support this use case, we added a hedera.mirror.importer.downloader.consensusRatio property that controls the ratio of verified nodes (nodes used to come to consensus on the signature file hash) to the total number of nodes available.
We took the time to undertake some major dependency upgrades for the Rosetta API. This included major updates to the Hedera and Rosetta SDKs that both required a large amount of refactoring. A number of bugs in Rosetta were addressed as well as improvements to Rosetta's CI workflow. These changes lay the groundwork for additional Rosetta improvements in a future release.
To avoid duplication, we wanted to unify our JMeter and Monitor performance tests. To do so, we needed the newer monitor tool to have feature parity with our JMeter tests. To accomplish this, we've split the publish to HAPI and subscribe to mirror node flows in the monitor to allow for subscribe only. In this iteration, only the gRPC API supports subscribe only. With this change, we were able to remove our JMeter code and optimize the hedera-mirror-test image from 1.5G to 0.5G.
We made some operational improvements to our helm chart including alert dependencies. Alert dependencies help avoid a flood of alerts that are all related to the same root cause. We also made some bug fixes to the chart that could occur when enabling or disabling some components in favor of external databases or message buses.
​v0.33.0​
MAINNET UPDATE COMPLETED: JUNE 10, 2021
TESTNET UPDATE COMPLETED: MAY 21, 2021
This release adds support for HAPI 0.13.2. This brings with it a new address book file format that is more compact and doesn't duplicate IP address and port information. We took the time to adjust our database to reflect the newer format while maintaining compatibility with the older format.
A big focus of this release was on improving the Helm charts for use in production deployments. We now auto-generate passwords for components that require one and ensure they remain the same on upgrades by using Helm's lookup feature. We added env, envFrom, volumes, volumeMounts properties to all charts for more flexible configuration. We added a global.image.tag chart property to make it easier to test out custom versions. And we made it easier to use dependencies that can be outside the cluster like Redis and PostgreSQL.
Some internal improvements saw us automating our release process so that version bumps and release note generation can be kicked off via GitHub. This now also includes generating a CHANGELOG and keeping it up to date with the release notes. And finally we updated our acceptance tests to automatically pull and use the latest address book along with validating all nodes to ensure only the latest, valid nodes are used for validation.
​v0.32.0​
MAINNET UPDATE COMPLETED: MAY 19, 2021
TESTNET UPDATE COMPLETED: MAY 11, 2021
In this release we took the time to do some performance optimizations of both the importer and the monitor. If you're using a containerized mirror node, the Java applications now uses more of the available memory that's already been allocated to it. We optimized the size of some internal queues to reduce the likelihood of out of memory errors. And we now use a more efficient streaming method to write entities to the database and avoid large memory allocations. All these combine to greatly reducing overall memory usage and improve overall performance for the importer. The monitor also saw performance improvements to allow it to publish transactions at a rate of 10,000 TPS.
This release updates more of our system to handle the revised scheduled transaction design that will be available soon on mainnet. Both the acceptance tests and monitor were updated to be able to publish the new transactions.
We now expose the raw transaction bytes encoded in Base64 format in the REST API. Persisting the bytes of the Transaction protobuf in the database is an option that's been available for a while but until now has not been available via the API. Persisting the data is off by default as does increase the size of the database quite a bit. The Hedera managed mirror nodes will not have that functionality turned on to reduce storage.
​v0.31.0​
MAINNET UPDATE COMPLETED: APRIL 30, 2021
TESTNET UPDATE COMPLETED: APRIL 26, 2021
After scheduled transactions were made available in previewnet, we listened to user feedback and further iterated on the design to make it easier to use. This release adds support for this revised scheduled transactions design planned to be released in HAPI v0.13. There was no impact to our REST API format, only the importer needed to be updated to parse and ingest the new proto format. Our monitor API and acceptance tests will be adjusted in the next release once the SDKs add support for the new design.
This release also adds support for the newly announced account balance file format that was released in HAPI v0.12. The new protobufbased format will eventually replace the CSV format in July 2021. Until then, both formats will exist simultaneously in the bucket so users can transition at their leisure. Besides being more efficient to parse, the new files are also compressed using Gzip for reduced storage and download costs. We also took the time to improve the balance file parsing performance regardless of format. Average parse times should decrease by about 27%.
For our REST API, we now expose an entity_id field on our transactions related APIs. This field represents the main entity associated with that transaction type. For example, if it was a HCS transaction it would be the topic ID created, updated, or deleted.
GET /api/v1/transactions/0.0.1009-1234567890-999999998
1
{
2
  "transactions": [{
3
    "consensus_timestamp": "1234567890.999999999",
4
    "entity_id": "0.0.108763",
5
    "valid_start_timestamp": "1234567890.999999998",
6
    "charged_tx_fee": 0,
7
    "memo_base64": null,
8
    "result": "SUCCESS",
9
    "scheduled": false,
10
    "transaction_hash": "aGFzaA==",
11
    "name": "CRYPTOUPDATEACCOUNT",
12
    "node": "0.0.3",
13
    "transaction_id": "0.0.1009-1234567890-999999998",
14
    "valid_duration_seconds": "11",
15
    "max_fee": "33",
16
    "transfers": []
17
  }]
18
}
Copied!
We continue to make progress towards our goal of switching to TimescaleDB. We fixed the user and database initialization issues and tested a migration from PostgreSQL. We switched out the TimescaleDB Helm chart to a more stable one and explored our hosting options for production. Finally, we switched to SCRAM-SHA-256 to improve the security of our database user authentication.
Breaking changes:
There were a number of breaking changes this release to be aware of. If you're using our Helm chart, we have switched the importer from a StatefulSet to a Deployment since it no longer has the need for a persistent volume. We also switched the Traefik dependency from a Deployment to a DaemonSet. Both of these will require manual intervention to delete the old workload before upgrading. Support for Helm 2 was dropped since it is no longer supported by the community after November 13, 2020. If you're directly reading from our database, a rename of the t_entities table and its columns may impact you as well.
​v0.30.0​
Mirror node v0.30 brings operational improvements with changes to our continuous integration and monitoring components.
With this release, we've completed the migration from CircleCI to GitHub Actions. CircleCI had some limitations with our use of Testcontainers for unit testing against 3rd party dependencies. We previously had a mixture of GitHub Actions and CircleCI with the latter using slightly different commands than local testing. Consolidating to GitHub Actions allowed us to reduce this difference and further parallelize our checks.
To improve our runtime observability and testing coverage, we've continued to invest in our monitor tool this cycle. Scheduled transaction support was recently added supporting both ScheduleCreate and ScheduleSign operations. We've added the three new mainnet nodes the monitor's default configuration. A bug with the monitor unable to reach expected TPS with multiple scenarios was fixed.
The REST API also saw some bug fixes including a fix to queries with a credit/debit parameter now able to retrieve token only transfers. The transaction API now populates the token transfers list for all transaction types instead of being limited to just crypto transfers.
​v0.29.1​
MAINNET UPDATE COMPLETED: APRIL 5, 2021
TESTNET UPDATE COMPLETED: MARCH 26, 2021
This release brings an assortment of under the hood improvements across modules and refinements of multiple REST API's.
Historical entity information prior to OA is now available. In this release we've added a repeatable Java migration that will import entity information from a mainnet network snapshot. This runs during upgrade, is configureable (hedera.mirror.importer.importHistoricalAccountInfo) and works in combination with the hedera.mirror.importer.startDatesetting.
The REST API now expands its filtering options support specifically around transfers and in relation to tokens. Previously the account.idand credit/debit filtering options supported HBAR transfers only, this release expands both filters to include tokens also.
The stateproof REST API and check-state-proof package have also been improved. The API now supports filtering for scheduled transactions via /api/v1/transactions/:transactionId/stateproof?scheduled=true as-well as a more compact response format. For record streams that utilize the newer improved HAPI v5 version the stateproof API response send back metadata hashes instead of the full raw bytes. With this, the response is more light weight.
1
 {
2
     "address_books": [
3
       "address book content"
4
     ],
5
     "record_file": {
6
       "head": "content of the head",
7
       "start_running_hash_object": "content of the start running hash object",
8
       "hashes_before": [
9
         "hash of the 1st record stream object",
10
         "hash of the 2nd record stream object",
11
         "hash of the (m-1)th record stream object"
12
       ],
13
       "record_stream_object": "content of the mth record stream object",
14
       "hashes_after": [
15
         "hash of the (m+1)th record stream object",
16
         "hash of the (m+2)th record stream object",
17
         "hash of the nth record stream object"
18
       ],
19
       "end_running_hash_object": "content of the end running hash object",
20
     },
21
     "signature_files": {
22
       "0.0.3": "signature file content of node 0.0.3",
23
       "0.0.4": "signature file content of node 0.0.4",
24
       "0.0.n": "signature file content of node 0.0.n"
25
     },
26
     "version": 5
27
 }
Copied!
The REST API now also supports repeatable account.id query parameters when filtering, with a configureable setting for the maximum number of repeated query parameters
/api/v1/(accounts|balances|transactions)?account.id=:id&account.id=:id2...
GET /api/v1/accounts?account.id=0.0.7&account.id=0.0.9
1
{
2
     "accounts": [
3
       {
4
         "balance": {
5
           "timestamp": "0.000002345",
6
           "balance": 70,
7
           "tokens": [
8
             {
9
               "token_id": "0.0.100001",
10
               "balance": 7
11
             },
12
             {
13
               "token_id": "0.0.100002",
14
               "balance": 77
15
             }
16
           ]
17
         },
18
         "account": "0.0.7",
19
         "expiry_timestamp": null,
20
         "auto_renew_period": null,
21
         "key": null,
22
         "deleted": false
23
       },
24
       {
25
         "balance": {
26
           "timestamp": "0.000002345",
27
           "balance": 90,
28
           "tokens": []
29
         },
30
         "account": "0.0.9",
31
         "expiry_timestamp": null,
32
         "auto_renew_period": null,
33
         "key": null,
34
         "deleted": false
35
       }
36
     ],
37
     "links": {
38
       "next": null
39
     }
40
   }
Copied!
Multiple modules have also seen security and standardization improvements by the addition of more robust automated analysis tools such as gosec as-well as the implementation of suggestions from a 3rd party code audit.
This release also saw a step to support the new and improved v2 offerings of the (Java SDK)[https://github.com/hashgraph/hedera-sdk-java\]. Both the monitor module and acceptance tests were updated to use the new SDK and utilize features such as in-built retry and support for scheduled transactions.
​v0.28.2​
MAINNET UPDATE COMPLETED: MARCH 17, 2021
TESTNET UPDATE COMPLETED: MARCH 10, 2021
This releases finalizes support for scheduled transactions and HAPI protobuf v0.12. Two new schedule specific REST APIs were added including /api/v1/schedules and /api/v1/schedules/:id. The former lists all schedules with various filtering options available and the latter returns a specific schedule by its schedule ID.
GET /api/v1/schedules?account.id=0.0.1024&schedule.id=gte:4000&order=desc&limit=10
1
{
2
    "schedules": [
3
      {
4
        "admin_key": {
5
          "_type": "ProtobufEncoded",
6
          "key": "7b2233222c2233222c2233227d"
7
        },
8
        "consensus_timestamp": "1234567890.000030003",
9
        "creator_account_id": "0.0.1024",
10
        "executed_timestamp": null,
11
        "memo": "Created per governing council decision dated 02/03/21",
12
        "payer_account_id": "0.0.1024",
13
        "schedule_id": "0.0.4000",
14
        "signatures": [
15
          {
16
            "consensus_timestamp": "1234567890.000030001",
17
            "public_key_prefix": "CQkJ",
18
            "signature": "CQkJ"
19
          }
20
        ],
21
        "transaction_body": "AQECAgMD"
22
      }
23
    ],
24
    "links": {
25
      "next": null
26
    }
27
}
Copied!
In HAPI v0.12, new memo fields were added to all entity types bringing parity across all services. Mirror node now supports the new fields including for update operations where the memo field can be set to null, empty string or a non-empty string to keep, clear or replace the existing memo, respectively.
Historically, the importer application has always downloaded stream files and saved to the filesystem in one thread then read those files and ingested them into the database in another thread. This has sometimes caused the database and filesystem to get out of sync and require manual intervention to fix. It also makes the importer stateful and as a result could not support running multiple instances for high availability.
With this release, we've removed the need for importer to read and write to the filesystem. Instead, the downloader and parser threads now communicate via an in-memory queue. To accomplish this, we also had to remove the t_application_status table in favor of calculating the last successful file directly from the stream file tables. In addition to fixing the aforementioned issues, the removal of the filesystem has resulted in a 5% latency improvement.
Other changes include adding an index field to record_file table to simulate a blockchain index and updating our Google Marketplace to v0.27. Also, we added support for the v5 stream files to the check-state-proof client app.
​0.27.0​
MAINNET UPDATE COMPLETED: FEBRUARY 22, 2021
TESTNET UPDATE COMPLETED: FEBRUARY 11, 2021
This release adds a new REST API component that implements the Rosetta API. The Rosetta API is an open standard for integrating with blockchain-oriented systems. Implementing the Rosetta AP provides a number of advantages. It reduces the time and effort it takes for wallets, exchanges, etc. to integrate with the Hedera network if they have integrated with Rosetta in the past. Even if the systems integrator has not used Rosetta previously, using the Rosetta API in lieu of our separate REST API might be useful to reduce the friction with using a non-blockchain DLT like Hedera.
​Scheduled transactions is an new feature being added to the main nodes in a future release. Scheduled transactions allows transactions to be submitted without all the necessary signatures and will execute once all the required parties sign. The mirror node has been updated to understand and store these new types of transactions. Additionally, we've updated our existing REST APIs to expose this information. The next release will add additional schedule specific REST APIs.
We made a concerted effort this release to improve our tests. Most of our flaky tests were fixed so that our continuous integration runs smoother. We also improved the stability of our acceptance tests. The REST API monitor also had some logging and useability fixes to aid in production observability.
​v0.26.0​
MAINNET UPDATE COMPLETED: FEBRUARY 1, 2021
TESTNET UPDATE COMPLETED: JANUARY 22, 2021
This release is mainly focused on adding support for the upcoming features in the main nodes. We added support for the newTotalSupply field to the transaction record in HAPI 0.10.0. We also documented our design for the upcoming scheduled transactions services that's coming in a future release of HAPI. Our next minor version will have preliminary support for that.
But by far the biggest change is support for the new record file V5 and signature file V5 format. These files are uploaded to cloud storage and pulled by the mirror nodes to populate its database. Since it's the core communication format between the main nodes and mirror nodes, it took a bit of refactoring and new code to support the new format while retaining compatibility with previous stream files.
Warning! If you don't upgrade your Mirror Node to v0.26.0 or later before HAPI v0.11.0 is released in a few weeks, your mirror node will be unable to process new transactions.
We continued our progress on switching to TimescaleDB. We integrated a TimescaleDB helm chart into our Kubernetes deployment and added migration scripts to convert from PostgreSQL to TimescaleDB. We're still in the testing phase so it's still recommended to stick with the v1 schema (the default) for now.
​v0.25.0​
MAINNET UPDATE COMPLETED: JANUARY 12, 2021
TESTNET UPDATE COMPLETED: JANUARY 8, 2021
This release saw a slew of enhancements to our new monitoring module. The monitor is a standalone component that can publish and subscribe to transactions from various Hedera APIs to gauge the health of the system. New in this release is the ability to automatically create entities on startup using a new expression syntax. This is useful to avoid boilerplate configuration and manual entity creation steps that vary per environment.
A sample percentage property was added to the monitor to control how often the REST API should be verified. We took the time to properly document the monitor tool detailing its configuration and operational steps. Finally, we added a number of new metrics and a Grafana dashboard to view them.
We made progress towards our goal of replacing PostgreSQL with TimescaleDB. This release contains the initial database migrations to setup the mirror node from scratch using TimescaleDB. These migrations are hidden behind a feature flag. In an upcoming release we'll add further functionality including data migration scripts and Helm support.
​v0.24.0​
MAINNET UPDATE COMPLETED: DECEMBER 28, 2020
TESTNET UPDATE COMPLETED: DECEMBER 10, 2020
This release adds OpenAPI 3.0 specification support to our REST API. The OpenAPI specification is available at /api/v1/openapi.ymland serves as a formal specification of our API. Clients can use the specification to shorten the amount of time it takes to integrate with our API by generating code or tests harnesses. It also provides us with a new auto-generated API documentation site viewable at /api/v1/docs.
We now have support for the AWS Default Credential Provider Chain. Now instead of only being able to provide static access and secret keys in the configuration, you can rely on the default provider chain to retrieve your credentials automatically from the environment (environment variables, ~/.aws/credentials, etc). See our documentation for more information.
We've enhanced our monitoring tools to provide greater observability into the mirror node's operation. In addition to publishing, our monitor tool now supports subscribing to the gRPC and REST APIs to verify end to end functionality of Hedera. It will also generate metrics off this information. We take advantage of Loki's new log alerting capability and now can alert off of any errors we see in logs that might be cause for concern.
​v0.23.0​
MAINNET UPDATE COMPLETED: DECEMBER 2, 2020
TESTNET UPDATE COMPLETED: NOVEMBER 20, 2020
This release focuses on finalizing our support for the new Hedera Token Service (HTS) provided by the Hedera API v0.9.0. There are no new HTS features, just various fixes to make it compatible with the latest protobuf. HTS is currently enabled in previewnet and should be enabled in testnet very soon, so please try it out and let us know if you have any feedback.
A new Helm chart was added to run the monitor application. The monitor is still under heavy development so stay tuned.
Most of the other changes were bug fixes. We now use SonarCloud to scan for vulnerabilities and bugs and have addressed all the major items. You can view our SonarCloud dashboard to track our progress. Entities are now only inserted for successful transactions and we fixed the wrong address book being updated. There were multiple issues with the state proof alpha API that were resolved. For the gRPC API, we improved its performance and lowered its CPU usage. Also related to gRPC, we now enable server sent keep alive messages and permit a lower client sent keep alive messages of 90 seconds, which should hopefully address timeout issues that some users have reported.
​v0.22.0​
This release continues our improvements to our Kubernetes support as well as monitoring and performance improvements across the modules.
We improved our custom PrometheusRule alerts for the Importer, GRPC and REST API modules, as well as added dashboards for our gRPC and REST API modules. Additionally, we increased our pod resources limits to optimize Importer ingestion and gRPC streaming performance in a Kubernetes cluster. Our existing js based monitor and REST performance tests were both updated to include HTS support.
We also improved our data generator module with support for the majority of HAPI transactions the mirror node importer ingests. Additionally, we also added a java based monitor module that supports generation and publishing of transactions.
This release also includes an improvements to avoid the stale account info bug that stems from balance stream files being received at a slower frequency than record stream files. Now account creations and account info changes will be reflected in REST API call even though the updated balance may not have been received.
We also extended our REST API support to include case insensitive support query parameters. /api/v1/transactions?transactionType=tokentransfers and /api/v1/transactions?transactiontype=tokentransfers are now both acceptable.
​v0.21.0​
MAINNET UPDATE COMPLETED: NOVEMBER 24, 2020
TESTNET UPDATE COMPLETED: NOVEMBER 13, 2020
This release continues our focus on the Hedera Token Service (HTS) by adding three new token REST APIs. A token discovery REST API /api/v1/tokens shows available tokens on the network. A token REST API /api/v1/tokens/${tokenId} shows details for a token on the network. A token supply distribution REST API /api/v1/tokens/${tokenId}/balances shows token distribution across accounts. These APIs have already made their way to previewnet so check them out!
Continuing our HTS theme, we enhanced our testing frameworks with token support. Our acceptance tests can send HTS transactions to HAPI and wait for those transactions to show up via the mirror node REST API. Additionally, our performance tests can simulate a HTS load to test how the system responds to HTS transactions.
We improved our existing REST APIs by adding a way to filter by transaction type. When searching for transactions or showing the transactions for a particular account you can now filter via an optional transactionType query parameter. This feature can be used with the transactions API in the format /api/v1/transactions?transactionType=tokentransfers while the format for the accounts API is /api/v1/accounts/0.0.8?transactionType=TOKENTRANSFERS.
We improved our Kubernetes support with AlertManager integration. There are now custom PrometheusRule alerts for each component that trigger notifications based upon Prometheus metrics. A custom Grafana dashboard was created that shows currently firing alerts.
​
Latest Releases

​v0.56​

Upgrading

​v0.55​

​v0.54​

Upgrading

​v0.53​

Upgrading

​v0.52​

​v0.51​

​v0.50​

Breaking Changes

​v0.49​

​v0.48​

Upgrading

​v0.47​

​v0.46​

Database Migration

​v0.45.0​

​v0.44.0​

Breaking Changes

​v0.43.0​

Smart Contracts

Data Architecture

Performance Improvements

​v0.42.0​

​v0.41.0​

​v0.40.0​

​v0.39.0​

​v0.38.1​

​v0.38.0​

Breaking Changes

​v0.37.2​

​v0.37.1​

​v0.36.0​

Breaking Changes

​v0.35.0​

Breaking changes

​v0.34.0​

​v0.33.0​

​v0.32.0​

​v0.31.0​

Breaking changes:

​v0.30.0​

​v0.29.1​

​v0.28.2​

​0.27.0​

​v0.26.0​

Warning! If you don't upgrade your Mirror Node to v0.26.0 or later before HAPI v0.11.0 is released in a few weeks, your mirror node will be unable to process new transactions.

​v0.25.0​

​v0.24.0​

​v0.23.0​

​v0.22.0​

​v0.21.0​

​

v0.56

v0.55

v0.54

v0.53

v0.52

v0.51

v0.50

v0.49

v0.48

v0.47

v0.46

v0.45.0

v0.44.0

v0.43.0

v0.42.0

v0.41.0

v0.40.0

v0.39.0

v0.38.1

v0.38.0

v0.37.2

v0.37.1

v0.36.0

v0.35.0

v0.34.0

v0.33.0

v0.32.0

v0.31.0

v0.30.0

v0.29.1

v0.28.2

0.27.0

v0.26.0

v0.25.0

v0.24.0

v0.23.0

v0.22.0

v0.21.0
