Start Building
Changes to Hedera API (HAPI) for v0.8.0 and v0.9.0
technical
Sep 24, 2020
by Simi Hunjan

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, 2020
Mainnet 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

Deprecate threshold records (v0.8.0)

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:

  • CryptoCreate.proto - sendRecordThreshold, receiveRecordThreshold
  • CryptoGetInfo.proto - generateSendRecordThreshold, generateReceiveRecordThreshold
  • CryptoUpdate.proto - sendRecordThresholdWrapper, receiveRecordThresholdWrapper
  • ResponseCode.proto - INVALID_RECEIVE_RECORD_THRESHOLD, INVALID_SEND_RECORD_THRESHOLD

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.

[ACTION REQUIRED] Deprecated fields removed from transaction proto (v0.9.0)

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:

Code Snippet Background 
TransactionBody body = 1

SignatureList 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.

New fields in transaction proto (v0.9.0)

Testnet v0.9.0 estimated release: November 19, 2020
Mainnet v0.9.0 estimated release: December 3, 2020

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.

Code Snippet Background 
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.

Code Snippet Background 
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 


}
View All Posts