Releases: hashgraph/hedera-protobufs
Hedera Services Protobufs v0.20.0
For release notes, please see here.
Hedera Services v0.18.0
In Hedera Services 0.18.0, we are happy to announce support for HIP-23 (Opt-in Token Associations). This feature lets an Hedera account owner "pre-pay" for token associations via a CryptoCreate or CryptoUpdate transaction, without knowing in advance which specific token types they will use.
Then, when their account receives units or NFT's of a new token type via a CryptoTransfer, the network automatically creates the needed association---no explicit TokenAssociate transaction needed. This supports several interesting use cases; please see the linked HIP-23 for more details.
There are three other points of interest in this release.
First, we have removed the HIP-18 limitations noted in the previous release. The tokenFeeScheduleUpdate transaction has been re-enabled, and multiple royalty fees can now be charged for a non-fungible token type.
Second, the address books in system files 0.0.101 and 0.0.102 will now populate their ServiceEndpoint fields. (However, the deprecated ipAddress, portno, and memo fields will no longer be populated after the next release.)
Third, please note that the TokenService getTokenNftInfos and getAccountNftInfos queries are now deprecated and will be removed in a future release. The best answers to such queries demand historical context that only Mirror Nodes have; so these and related queries will move to mirror REST APIs.
Developers will likely appreciate two other release 0.18.0 items. First, we have migrated to Dagger2 for dependency injection. Second, there is a new getExecutionTime query in the NetworkService that supports granular performance testing in development environments.
Contributors
We'd like to thank all the contributors who worked on this release!
Contributors
Assets 2
Hedera Services v0.18.0
In Hedera Services 0.18.0, we are happy to announce support for HIP-23 (Opt-in Token Associations). This feature lets an Hedera account owner "pre-pay" for token associations via a CryptoCreate or CryptoUpdate transaction, without knowing in advance which specific token types they will use.
Then, when their account receives units or NFT's of a new token type via a CryptoTransfer, the network automatically creates the needed association---no explicit TokenAssociate transaction needed. This supports several interesting use cases; please see the linked HIP-23 for more details.
There are three other points of interest in this release.
First, we have removed the HIP-18 limitations noted in the previous release. The tokenFeeScheduleUpdate transaction has been re-enabled, and multiple royalty fees can now be charged for a non-fungible token type.
Second, the address books in system files 0.0.101 and 0.0.102 will now populate their ServiceEndpoint fields. (However, the deprecated ipAddress, portno, and memo fields will no longer be populated after the next release.)
Third, please note that the TokenService getTokenNftInfos and getAccountNftInfos queries are now deprecated and will be removed in a future release. The best answers to such queries demand historical context that only Mirror Nodes have; so these and related queries will move to mirror REST APIs.
Developers will likely appreciate two other release 0.18.0 items. First, we have migrated to Dagger2 for dependency injection. Second, there is a new getExecutionTime query in the NetworkService that supports granular performance testing in development environments.
Contributors
We'd like to thank all the contributors who worked on this release!
Contributors
Assets 2
Hedera Services v0.16.0
For release notes please see the matching tag in Hedera Services here.
Hedera Services v0.16.0 protobufs
For release notes please see the matching tag in Hedera Services here.
Hedera Services v0.15.0
In Hedera Services 0.15.0, we improved performance and integrated with the latest Platform SDK to enable full support of network reconnect.
These performance improvements let us augment the Hedera world state with records of all transactions handled in the three minutes of consensus time, even when handling 10,000 transactions per second. The HAPI GetAccountRecords query now returns, from state, all such records for which the queried account was the payer account.
We have also finalized the design for the non-fungible token (NFT) support to be added to the Hedera Token Service (HTS) in release 0.16.0. The protobufs for new HAPI operations are available in the 0.15.0 tag of this repository.
To simplify fee calculations, there is now a maximum entity lifetime of a century for any entity whose lifetime is not already constrained by the maximum auto-renew period. A HAPI transaction that tries to set an expiration further than a century from the current consensus time will resolve to INVALID_EXPIRATION_TIME.
Enhancements
- Improve performance, e.g. #1505, #1501, #1500, #1499, #1498, #1461, #1425, #1424, #1423, #1422, #1421
- Finalize protobufs for NFT support in HTS
Contributors
We'd like to thank all the contributors who worked on this release!
Hedera Services v0.14.0
In Hedera Services 0.14.0, we have implemented account auto-renewal according to the specifications of HIP-16. This feature will not be enabled until a later date, after ensuring universal awareness of its impact in the user community.
This release also includes notable infrastructure work to enable use of the Platform reconnect feature. Reconnect allows a node that has fallen behind in consensus gossip to catch back up dynamically.
A minor improvement to the Hedera API is that the GetVersionInfo query now includes the optional pre-release version and build metadata fields from the Semantic Versioning spec (if applicable). In another change to HAPI, to simplify life for system admins who are updating a system account's key, we now waive the signing requirement for the account's new key.
Enhancements
- Implement HIP-16 :: #1125, #1350, #1371
- Waive new key's signature when a privileged payer updates a system account :: #1164
- Refine
GetVersionInfoto return the Git tag used to build the deployed JAR :: #1188
Contributors
We'd like to thank all the contributors who worked on this release!
Hedera Services v0.13.2
In Hedera Services v0.13.2, we have redesigned scheduled transactions. The new design gives collaborating nodes a well-defined workflow if they happen to schedule identical transactions, even if they are using different gRPC client libraries (for example, Go and JavaScript). The new design also reduces the number of signatures required to submit a valid ScheduleSign transaction in many common use cases.
This release deprecates three fields in the protobuf for system files 0.0.101 and 0.0.102. The three deprecated fields are ipAddress, portno, and memo. When we rely on these fields, we cannot concisely represent node with multiple IP addresses. For example, take mainnet node 0 (account 0.0.3), which as of this writing has proxy IPs 13.82.40.153, 34.239.82.6, and 35.237.200.180. The mainnet 0.0.101 file must include a NodeAddress entry for each proxy, which means duplicating fields like nodeCertHash.
The new protobuf avoid this duplication, letting us represent node 0 in a protobuf equivalent of,
{
"nodeId" : 0,
"certHash" : "337390d8fea144afc12e81254a28dac6ea82893836ac072effd85e0a7748580ef28096648c5a7f8dbb4ce81476815137",
"nodeAccount" : "0.0.3",
"serviceEndpoints" : [ {
"ipAddressV4" : "13.82.40.153",
"port" : 50211
}, {
"ipAddressV4" : "34.239.82.6",
"port" : 50211
}, {
"ipAddressV4" : "35.237.200.180",
"port" : 50211
} ]
}However, Services will continue to populate the deprecated fields in duplicate entries for six months, to give all consumers of files 0.0.101 and 0.0.102 time to prepare for exclusive use of the new format. After six months, we will eliminate the duplication and the ipAddress, portno, and memo fields will be left empty. (The fields will never be removed to ensure it remains possible to parse early versions of these system files.)
In a minor point, Services now rejects any protobuf string field whose UTF-8 encoding includes the zero-byte character; that is, Unicode code point 0, NUL. Databases (for example, PostgreSQL) commonly reserve this character as a delimiter in their internal formats, so allowing it to occur in entity fields can make life harder for Mirror Node operators.
To simplify tasks for network admins, we have also streamlined the signing requirements for updates to system accounts, and introduced a Docker-based utility called "yahcli" for admin actions such as updating system files.
Enhancements
- Redesign scheduled transactions #1177
- When updating a system account's key, if the account's signature is waived, also waive signing with new key #1148
- Basic implementation of yahcli, e.g. #1176
Protobuf deprecations
- Three
NodeAddressfields, to be replaced by a richerServiceEndpointmessage #750
Bug fixes
- Re-institute policy of exporting account balances every 15 minutes since the epoch #1142
- Abort signing of resolved schedules #1303
- Update default throttles packaged as throttles.json in JAR to desired values #1312
Contributors
We'd like to thank all the contributors who worked on this release!
Hedera Services v0.13.1
In Hedera Services v0.13.0, we have redesigned scheduled transactions. The new design gives collaborating nodes a well-defined workflow if they happen to schedule identical transactions, even if they are using different gRPC client libraries (for example, Go and JavaScript). The new design also reduces the number of signatures required to submit a valid ScheduleSign transaction in many common use cases.
This release deprecates three fields in the protobuf for system files 0.0.101 and 0.0.102. The three deprecated fields are ipAddress, portno, and memo. When we rely on these fields, we cannot concisely represent node with multiple IP addresses. For example, take mainnet node 0 (account 0.0.3), which as of this writing has proxy IPs 13.82.40.153, 34.239.82.6, and 35.237.200.180. The mainnet 0.0.101 file must include a NodeAddress entry for each proxy, which means duplicating fields like nodeCertHash.
The new protobuf avoid this duplication, letting us represent node 0 in a protobuf equivalent of,
{
"nodeId" : 0,
"certHash" : "337390d8fea144afc12e81254a28dac6ea82893836ac072effd85e0a7748580ef28096648c5a7f8dbb4ce81476815137",
"nodeAccount" : "0.0.3",
"serviceEndpoints" : [ {
"ipAddressV4" : "13.82.40.153",
"port" : 50211
}, {
"ipAddressV4" : "34.239.82.6",
"port" : 50211
}, {
"ipAddressV4" : "35.237.200.180",
"port" : 50211
} ]
}However, Services will continue to populate the deprecated fields in duplicate entries for six months, to give all consumers of files 0.0.101 and 0.0.102 time to prepare for exclusive use of the new format. After six months, we will eliminate the duplication and the ipAddress, portno, and memo fields will be left empty. (The fields will never be removed to ensure it remains possible to parse early versions of these system files.)
In a minor point, Services now rejects any protobuf string field whose UTF-8 encoding includes the zero-byte character; that is, Unicode code point 0, NUL. Databases (for example, PostgreSQL) commonly reserve this character as a delimiter in their internal formats, so allowing it to occur in entity fields can make life harder for Mirror Node operators.
To simplify tasks for network admins, we have also streamlined the signing requirements for updates to system accounts, and introduced a Docker-based utility called "yahcli" for admin actions such as updating system files.
Enhancements
- Redesign scheduled transactions #1177
- When updating a system account's key, if the account's signature is waived, also waive signing with new key #1148
- Basic implementation of yahcli, e.g. #1176
Protobuf deprecations
- Three
NodeAddressfields, to be replaced by a richerServiceEndpointmessage #750
Bug fixes
- Re-institute policy of exporting account balances every 15 minutes since the epoch #1142
Contributors
We'd like to thank all the contributors who worked on this release!
Hedera Services v0.13.0-rc.1
In Hedera Services v0.13.0, we have redesigned scheduled transactions. The new design gives collaborating nodes a well-defined workflow if they happen to schedule identical transactions, even if they are using different gRPC client libraries (for example, Go and JavaScript). The new design also reduces the number of signatures required to submit a valid ScheduleSign transaction in many common use cases.
This release deprecates three fields in the protobuf for system files 0.0.101 and 0.0.102. The three deprecated fields are ipAddress, portno, and memo. When we rely on these fields, we cannot concisely represent node with multiple IP addresses. For example, take mainnet node 0 (account 0.0.3), which as of this writing has proxy IPs 13.82.40.153, 34.239.82.6, and 35.237.200.180. The mainnet 0.0.101 file must include a NodeAddress entry for each proxy, which means duplicating fields like nodeCertHash.
The new protobuf avoid this duplication, letting us represent node 0 in a protobuf equivalent of,
{
"nodeId" : 0,
"certHash" : "337390d8fea144afc12e81254a28dac6ea82893836ac072effd85e0a7748580ef28096648c5a7f8dbb4ce81476815137",
"nodeAccount" : "0.0.3",
"serviceEndpoints" : [ {
"ipAddressV4" : "13.82.40.153",
"port" : 50211
}, {
"ipAddressV4" : "34.239.82.6",
"port" : 50211
}, {
"ipAddressV4" : "35.237.200.180",
"port" : 50211
} ]
}However, Services will continue to populate the deprecated fields in duplicate entries for six months, to give all consumers of files 0.0.101 and 0.0.102 time to prepare for exclusive use of the new format. After six months, we will eliminate the duplication and the ipAddress, portno, and memo fields will be left empty. (The fields will never be removed to ensure it remains possible to parse early versions of these system files.)
In a minor point, Services now rejects any protobuf string field whose UTF-8 encoding includes the zero-byte character; that is, Unicode code point 0, NUL. Databases (for example, PostgreSQL) commonly reserve this character as a delimiter in their internal formats, so allowing it to occur in entity fields can make life harder for Mirror Node operators.
To simplify tasks for network admins, we have also streamlined the signing requirements for updates to system accounts, and introduced a Docker-based utility called "yahcli" for admin actions such as updating system files.
Enhancements
- Redesign scheduled transactions #1177
- When updating a system account's key, if the account's signature is waived, also waive signing with new key #1148
- Basic implementation of yahcli, e.g. #1176
Protobuf deprecations
- Three
NodeAddressfields, to be replaced by a richerNodeEndpointmessage #750
Bug fixes
- Re-institute policy of exporting account balances every 15 minutes since the epoch #1142
Contributors
We'd like to thank all the contributors who worked on this release!