Releases: hiero-ledger/hiero-consensus-node
Hedera Services v0.15.1
In Hedera Services 0.15.1, we improved performance and integrated with the latest Platform SDK to enable network reconnect.
The performance gains let us augment the Hedera world state with records of all transactions handled in the three minutes of consensus time, even when handling 10k transactions per second. The GetAccountRecords query will now return, from state, the records of all transactions handled in the last 3 minute for which the queried account was the payer.
In this release we 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 the official repository, with documentation here.
The CSV format for exported account balances is no longer supported. All mainnet stream file consumers should be fully migrated to the protobuf format of the account balances file.
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.15.0
In Hedera Services 0.15.0, we improved performance and integrated with the latest Platform SDK to enable network reconnect.
The performance gains let us augment the Hedera world state with records of all transactions handled in the three minutes of consensus time, even when handling 10k transactions per second. The GetAccountRecords query will now return, from state, the records of all transactions handled in the last 3 minute for which the queried account was the payer.
In this release we 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 the official repository, with documentation here.
The CSV format for exported account balances is no longer supported. All mainnet stream file consumers should be fully migrated to the protobuf format of the account balances file.
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.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.14.0-alpha.1
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. Users will be able to schedule CryptoTransfer and ConsensusSubmitMessage transactions in this release. Other transaction types will be introduced in future releases.
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 schedule 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. Users will be able to schedule CryptoTransfer and ConsensusSubmitMessage transactions in this release. Other transaction types will be introduced in future releases. Note: The schedule transactions feature will not be enabled in this release; it's expected to be enabled on testnet in a subsequent v0.13.1 update on April 29th. This feature is enabled on previewnet.
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
Contributors
We'd like to thank all the contributors who worked on this release!
Hedera Services v0.13.0
In Hedera Services v0.13.0, we have redesigned schedule 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. Users will be able to schedule CryptoTransfer and ConsensusSubmitMessage transactions in this release. Other transaction types will be introduced in future releases. Note: The schedule transactions feature will not be enabled in this release; it's expected to be enabled on testnet in a subsequent v0.13.1 update on April 29th. This feature is enabled on previewnet.
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.2
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!