auto_renew_account
field along with a new permanent_removal
flag that is set to true when the system expires a contract.CryptoTransferTransaction
./api/v1/accounts/{id}/nfts?spender.id={id}
REST API is now included.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)β.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.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.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
GET /api/v1/accounts/{accountId}/allowances/crypto
GET /api/v1/accounts/{accountId}/allowances/tokens
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.hedera-mirror-common
chart, please check the kube-prometheus-stack upgrade notes to ensure Prometheus Operator can update successfully.hedera.mirror.importer.reconciliation.enabled=false
./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
/api/v1/contracts/results/{transactionId}
and /api/v1/contracts/{id}/results/{timestamp}
. Below is an example, with other fields omitted for brevity: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.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.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.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.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./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.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.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.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.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.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:eth_blockNumber
method has been implemented in this release as we focused on putting the groundwork in place first.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
./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.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./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}
hedera-mirror-common
module to share code with a future API module./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./construction/submit
. An issue with token balance reconciliation was also addressed.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.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.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./api/v1/contracts/{id}
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./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.GET /api/v1/network/supply
max_automatic_token_associations
in the accounts REST API.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.GET /api/v1/tokens/0.0.1500/nfts
GET /api/v1/tokens/0.0.1500/nfts/1
GET /api/v1/tokens/0.0.1500/nfts/1/transactions
PodDisruptionBudgets
, adjust alert rules and other improvements to make it easier to automate the deployment.type
field to the token related APIs to indicate fungibility and anft_transfers
to /api/v1/transactions/{id}
:leaders
is used to atomically elect the leader.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
: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:hedera.mirror.importer.downloader.balance.keepSignatures
to hedera.mirror.importer.downloader.balance.writeSignatures
hedera.mirror.importer.parser.balance.keepFiles
to hedera.mirror.importer.downloader.balance.writeFiles
hedera.mirror.importer.parser.balance.persistBytes
to hedera.mirror.importer.downloader.balance.persistBytes
hedera.mirror.importer.downloader.event.keepSignatures
to hedera.mirror.importer.downloader.event.writeSignatures
hedera.mirror.importer.parser.event.keepFiles
to hedera.mirror.importer.downloader.event.writeFiles
hedera.mirror.importer.parser.event.persistBytes
to hedera.mirror.importer.downloader.event.persistBytes
hedera.mirror.importer.downloader.record.keepSignatures
to hedera.mirror.importer.downloader.record.writeSignatures
hedera.mirror.importer.parser.record.keepFiles
to hedera.mirror.importer.downloader.record.writeFiles
hedera.mirror.importer.parser.record.persistBytes
to hedera.mirror.importer.downloader.record.persistBytes
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.hedera-mirror-test
image from 1.5G to 0.5G.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.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.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
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.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.hedera.mirror.importer.importHistoricalAccountInfo
) and works in combination with the hedera.mirror.importer.startDate
setting.account.id
and credit/debit
filtering options supported HBAR transfers only, this release expands both filters to include tokens also.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.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
gosec
as-well as the implementation of suggestions from a 3rd party code audit./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
null
, empty string or a non-empty string to keep, clear or replace the existing memo, respectively.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.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.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./api/v1/openapi.yml
and 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
.~/.aws/credentials
, etc). See our documentation for more information./api/v1/transactions?transactionType=tokentransfers
and /api/v1/transactions?transactiontype=tokentransfers
are now both acceptable./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!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
.PrometheusRule
alerts for each component that trigger notifications based upon Prometheus metrics. A custom Grafana dashboard was created that shows currently firing alerts.