The Hedera API (HAPI) is always evolving based on user feedback, usability testing, and necessary changes in functionality directed and approved by the Hedera Governing Council. Sometimes these changes require the deprecation or addition of functionalities.
If you’re utilizing the Hedera API (HAPI) to build applications on the testnet or mainnet, you’ll need to review the deprecations and additions coming in v0.8.0 and v0.9.0 of the Hedera Services Codebase. If you’re building on Hedera using any of the official Hedera SDKs, no action is needed at this time.
Testnet v0.9.0 estimated release: November 19, 2020Mainnet v0.9.0 estimated release: December 3, 2020
For technical community and Hedera development support, please join the Hedera Discord at https://hedera.com/discord
Mainnet v0.8.0 estimated release: October 1, 2020
When creating an account, you can optionally generate records for receiving or sending hbars that meet a certain threshold value. The option to generate these threshold records will be marked as deprecated in this release. The following protobufs will be affected:
You can view the updated protobufs here and related issue here. These fields will be marked deprecated for at least 6 months before they’re completely removed.
Testnet v0.9.0 estimated release: November 19, 2020 Mainnet v0.9.0 estimated release: December 3, 2020
For the upcoming v0.9.0 release, the Transaction proto will have the following deprecated fields removed. They have been marked as deprecated:
TransactionBody body = 1SignatureList sigs = 2
The signedTransactionBytes field will be added. If the appropriate updates are not made, transactions will fail with INVALID_TRANSACTION_BODY or INVALID_SIGNATURE response from the network. You can view the updated transaction proto here and issue here.
Release v0.9.0 will be introducing a new field to transaction proto. The addition of the signedTransactionBytes field to the Transaction protobuf message is designed to ensure that the hash of the entire transaction (including signatures) as calculated by the client and the network is guaranteed to be identical. The new field stores the entire signed transaction including signatures as an array of bytes.
signedTransactionBytes = 5
This change is a backwards compatible change, so clients that currently use the bodyBytes & sigMap to submit transactions can continue to do so, with the node parsing and hashing the transaction as it currently does.
A transaction can only contain signedTransactionBytes or contain bodyBytes & sigMap. A transaction that contains any other combination of fields will be rejected with an INVALID_TRANSACTION response from the network.
You can view the updated transaction proto here.
message Transaction { bytes signedTransactionBytes = 5; // SignedTransaction serialized into bytes bytes bodyBytes = 4 [deprecated = true]; // TransactionBody serialized into bytes, which needs to be signed SignatureMap sigMap = 3 [deprecated = true]; // The signatures on the body with the new format, to authorize the transaction }
message Transaction {
bytes signedTransactionBytes = 5; // SignedTransaction serialized into bytes
bytes bodyBytes = 4 [deprecated = true]; // TransactionBody serialized into bytes, which needs to be signed
SignatureMap sigMap = 3 [deprecated = true]; // The signatures on the body with the new format, to authorize the transaction
}