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!
