Releases: hashgraph/hedera-services
Hedera Services v0.19.4
In Hedera Services 0.19, we are thrilled to announce migration of the Hedera smart contract service to the Hyperledger Besu EVM, as laid out in HIP-26. This enables support for the latest v0.8.9 Solidity contracts, and harmonizes our gas schedule with that of the "London" hard fork. The Besu migration also sets the stage for a step change in smart contract performance on Hedera.
Two other HIPs targeting the Hedera Token Service go live in this release. First, the HIP-23 feature set is now enabled, so that any account that has been configured with a non-zero maxAutoAssociations
can receive air-drops (i.e., units or NFTs of a token type without explicit association). Second, we have also implemented HIP-24, which provides a safety measure for token types created with a pauseKey
. If a TokenPause
is submitted with this key's signature, then all operations on the token will be suspended until a subsequent TokenUnpause
.
Contributors
We'd like to thank all the contributors who worked on this release!
Hedera Services v0.19.1
In Hedera Services 0.19, we are thrilled to announce migration of the Hedera smart contract service to the Hyperledger Besu EVM, as laid out in HIP-26. This enables support for the latest v0.8.9 Solidity contracts, and harmonizes our gas schedule with that of the "London" hard fork. The Besu migration also sets the stage for a step change in smart contract performance on Hedera.
Two other HIPs targeting the Hedera Token Service go live in this release. First, the HIP-23 feature set is now enabled, so that any account that has been configured with a non-zero maxAutoAssociations
can receive air-drops (i.e., units or NFTs of a token type without explicit association). Second, we have also implemented HIP-24, which provides a safety measure for token types created with a pauseKey
. If a TokenPause
is submitted with this key's signature, then all operations on the token will be suspended until a subsequent TokenUnpause
.
Contributors
We'd like to thank all the contributors who worked on this release!
Hedera Services v0.18.1
In Hedera Services 0.18.1, we have a new scalability profile for NFTs in the Hedera Token Service (HTS). Up to fifty million (50M) NFTs, each with 100 bytes of metadata, may now be minted. Of course our CryptoTransfer
and ConsensusSubmitMessage
operations are still supported at 10k TPS even with this scale.
In this release we have also enabled automatic reconnect. This feature comes into play when a network partition causes a node to "fall behind" in the consensus protocol. With reconnect enabled, the node can use a special form of gossip to "catch up" and resume participation in the network with no human intervention. This works even when the node has missed many millions of transactions, and the world state is very different from when it was last active.
We are happy to also announce that accounts can be customized to take advantage of the upcoming HIP-23 (Opt-in Token Associations) feature set. That is, an account owner can now "pre-pay" for token associations via a CryptoCreate
or CryptoUpdate
transaction, without knowing in advance which specific token types they will use.
Once HIP-23 is fully enabled in release 0.19, when their account receives units or NFT's of a new token type via a CryptoTransfer
, the network will automatically create 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.1 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!
Hedera Services 0.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.
When their account receives units or NFT's of a new token type via a CryptoTransfer
, the network will automatically create 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!
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.
When their account receives units or NFT's of a new token type via a CryptoTransfer
, the network will automatically create 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!
Hedera Services v0.17.4
In Hedera Services 0.17.4, we are excited to announce support for HIP-17 (Non-fungible Tokens), with a complementary extension to HIP-18 (Custom Hedera Token Service Fees) that lets an NFT creator set a royalty fee to be charged when fungible value is exchanged for one of their creations.
Unique token types and minted NFTs are more natural for many use cases than fungible token types. The Hedera Token Service now supports both natively, so that a single CryptoTransfer
can perform atomic swaps with any arbitrary combination of fungible, non-fungible, and ℏ transfers. (Please do note that the "paged" getAccountNftInfos
and getTokenNftInfos
queries will remain disabled until release 0.18.0, as several large performance improvements are pending.)
In this release we have made it possible to denominate a fixed fee in the units of the token to which it is attached (assuming the type of this token is FUNGIBLE_COMMON
). Custom fractional fees may now also be set as "net-of-transfer". In this case the recipient(s) in the transfer list receive the stated amounts, and the assessed fee is charged to the sender.
There are a few final points of more specialized interest. First, users of the scheduled transaction facility may now also schedule TokenBurn
and TokenMint
transactions. Second, network administrators issuing a CryptoUpdate
to change the treasury account's key must now sign with the new treasury key. Third, the supported TLS cipher suites have been updated to the following list:
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
(TLS v1.2)TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
(TLS v1.2)TLS_AES_256_GCM_SHA384
(TLS v1.3)
tokenFeeScheduleUpdate
transaction is not currently available. Second, only one royalty fee will be charged for a non-fungible token type. Both limitations will be removed in release 0.18.0.
Contributors
We'd like to thank all the contributors who worked on this release!
Hedera Services v0.17.3
In Hedera Services 0.17.3, we are excited to announce support for HIP-17 (Non-fungible Tokens), with a complementary extension to HIP-18 (Custom Hedera Token Service Fees) that lets an NFT creator set a royalty fee to be charged when fungible value is exchanged for one of their creations.
Unique token types and minted NFTs are more natural for many use cases than fungible token types. The Hedera Token Service now supports both natively, so that a single CryptoTransfer
can perform atomic swaps with any arbitrary combination of fungible, non-fungible, and ℏ transfers. (Please do note that the "paged" getAccountNftInfos
and getTokenNftInfos
queries will remain disabled until release 0.18.0, as several large performance improvements are pending.)
In this release we have made it possible to denominate a fixed fee in the units of the token to which it is attached (assuming the type of this token is FUNGIBLE_COMMON
). Custom fractional fees may now also be set as "net-of-transfer". In this case the recipient(s) in the transfer list receive the stated amounts, and the assessed fee is charged to the sender.
There are a few final points of more specialized interest. First, users of the scheduled transaction facility may now also schedule TokenBurn
and TokenMint
transactions. Second, network administrators issuing a CryptoUpdate
to change the treasury account's key must now sign with the new treasury key. Third, the supported TLS cipher suites have been updated to the following list:
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
(TLS v1.2)TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
(TLS v1.2)TLS_AES_256_GCM_SHA384
(TLS v1.3)
Contributors
We'd like to thank all the contributors who worked on this release!
Hedera Services v0.17.2
In Hedera Services 0.17.2, we are excited to announce support for HIP-17 (Non-fungible Tokens), with a complementary extension to HIP-18 (Custom Hedera Token Service Fees) that lets an NFT creator set a royalty fee to be charged when fungible value is exchanged for one of their creations.
Unique token types and minted NFTs are more natural for many use cases than fungible token types. The Hedera Token Service now supports both natively, so that a single CryptoTransfer
can perform atomic swaps with any arbitrary combination of fungible, non-fungible, and ℏ transfers. (Please do note that the "paged" getAccountNftInfos
and getTokenNftInfos
queries will remain disabled until release 0.18.0, as several large performance improvements are pending.)
In this release we have made it possible to denominate a fixed fee in the units of the token to which it is attached (assuming the type of this token is FUNGIBLE_COMMON
). Custom fractional fees may now also be set as "net-of-transfer". In this case the recipient(s) in the transfer list receive the stated amounts, and the assessed fee is charged to the sender.
There are a few final points of more specialized interest. First, users of the scheduled transaction facility may now also schedule TokenBurn
and TokenMint
transactions. Second, network administrators issuing a CryptoUpdate
to change the treasury account's key must now sign with the new treasury key. Third, the supported TLS cipher suites have been updated to TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
and TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
.
Contributors
We'd like to thank all the contributors who worked on this release!
Hedera Services v0.17.1
In Hedera Services 0.17.1, we are excited to announce support for HIP-17 (Non-fungible Tokens), with a complementary extension to HIP-18 (Custom Hedera Token Service Fees) that lets an NFT creator set a royalty fee to be charged when fungible value is exchanged for one of their creations.
Unique token types and minted NFTs are more natural for many use cases than fungible token types. The Hedera Token Service now supports both natively, so that a single CryptoTransfer
can perform atomic swaps with any arbitrary combination of fungible, non-fungible, and ℏ transfers. (Please do note that the "paged" getAccountNftInfos
and getTokenNftInfos
queries will remain disabled until release 0.18.0, as several large performance improvements are pending.)
In this release we have made it possible to denominate a fixed fee in the units of the token to which it is attached (assuming the type of this token is FUNGIBLE_COMMON
). Custom fractional fees may now also be set as "net-of-transfer". In this case the recipient(s) in the transfer list receive the stated amounts, and the assessed fee is charged to the sender.
There are two final points of more specialized interest. First, users of the scheduled transaction facility may now also schedule TokenBurn
and TokenMint
transaction. Second, network administrators issuing a CryptoUpdate
to change the treasury account's key must now sign with the new treasury key.
Contributors
We'd like to thank all the contributors who worked on this release!
Hedera Services v0.16.1
In Hedera Services 0.16.1, we are excited to announce support for HIP-18 (Custom Hedera Token Service Fees).
Hedera tokens can now be created with a schedule of up to 10 custom fees, which are either fixed in units of ℏ or another token; or fractional and computed in the units of the owning token. The ledger automatically charges custom fees to accounts as they send units of a fungible token (or ownership of a NFT, see below) via a CryptoTransfer
.
When a custom fee cannot be charged, the CryptoTransfer
fails atomically, changing no balances other than for the Hedera network fees.
The five case studies in this document show the basics of how custom fees are charged, and how they appear in records. Note that at most two "levels" of custom HTS fees are allowed, and custom fee charging cannot require changing more than 20 account balances.
FractionalFee
as described in this issue. In Release 0.17.0 the more natural FixedFee
configuration will be available.
In this release we have also enabled previewnet support for HIP-17 (Non-fungible Tokens). Unique token types and minted NFTs are more natural for many use cases than fungible token types. The Hedera Token Service will soon support both natively, so that a single CryptoTransfer
can perform atomic swaps with any arbitrary combination of fungible, non-fungible, and ℏ transfers.
We are very grateful to the Hedera user community for these interesting and powerful new feature sets.
Contributors
We'd like to thank all the contributors who worked on this release!