Release notes coming soon...
In Hedera Services v0.10.0, we improved the usability of the Hedera Token Service (HTS) with a
newTotalSupply field in the receipts of
TokenBurn transactions. Without this field, a client must follow the entire record stream of a token's supply changes to be certain of its supply at the consensus timestamp in the receipt. (Note that HTS operations are now enabled on Previewnet and Testnet, but remain disabled on Mainnet at this time. Please consult the SDK documentation for HTS semantics.)
Also for HTS, we added a property
fees.tokenTransferUsageMultiplier that scales the resource usage assigned to a
CryptoTransfer that changes token balances. This scaling factor is expected to be set so that the cost of a
CryptoTransfer that changes two token balances is roughly 10x the cost of a
CryptoTransfer that changes only two hbar balances.
Apart from HTS, this release drops a restriction on what payer accounts can be used for
CryptoUpdate transactions that target system accounts. (That is, accounts with number not greater than
hedera.numReservedSystemEntities.) In earlier versions, only three payers were accepted: The target account itself, the system admin account, or the treasury account. Other payers resulted in a status of
AUTHORIZATION_FAILED. This entire restriction is removed, with one exception---the treasury must pay for a
CryptoUpdate targeting the treasury.
Apart from these functional changes, we fixed an unintentional change in the naming of the crypto balances CSV file, and improved the usefulness of clients under test-clients/ for testing reconnect scenarios.
In Hedera Services v0.9.0, we finished the alpha implementation of the Hedera Token Service (HTS). Note that all HTS operations are enabled on Previewnet, but remain disabled on Testnet and Mainnet. Please consult the SDK documentation for HTS semantics.
We made several changes to the HAPI protobuf. First, we removed the deprecated
SignatureList message type. Second, we added a top-level
signedTransactionBytes field to the
Transaction message to ensure deterministic transaction hashes across different client libraries; the top-level
sigMap fields are now deprecated and the already-deprecated
body field is removed. Third, we deprecated all fields related to non-payer records, include account send and receive thresholds. This followed from the effective removal of non-payer records in v0.8.1.
For the same reason, the semantics of the
ContractGetRecords queries have also changed. The only queryable records are now those granted to the effective payer of a transaction that was handled while the network property
ledger.keepRecordsInState=true. Such records have an expiry of 180 seconds. It is important to note that because a contract account can never be the effective payer for a transaction, any
ContractGetRecords query will always return an empty record list, and we have deprecated the query.
The mainnet release includes the 0.8.0 version updates.
In Hedera Services v0.8.0, we made several minor fixes and improvements. This tag also includes pre-release implementations of several operations for an incipient Hedera Token Service (HTS).
NOTE: HTS operations will remain disabled in non-development environments for some time. These operations are under active development; please consult
master for up-to-date semantics.
Deprecated fields related to threshold records in HAPI protobuf #506
Update Receipt proto to pair each Status with NodeID - Receipt is deleted only when the latest (duplicate) transaction expires.
getTxRecord API will continue to return ALL records with the transaction ID.
In Hedera Services v0.7.0, we’ve moved to Swirlds SDK release
0.7.3 which enables zero-stake nodes to be part of a network without affecting consensus. Hedera Services v0.7.0 migrated to new interfaces and methods provided in this version of the Swirlds SDK. HCS topic running hashes are now calculated including the payer account id. The release includes other minor fixes and improvements.
Update HCS topic running hash to include the payer account id #88
Add zero-stake node functionality #274
Change gRPC CipherSuite to be CNSA compliant #215
Make recordLogPeriod dynamic with a default of 2 seconds #315
Add record with 3-min expiry to effective payer account after handling transaction #348
Fix incorrect submitted smart contract transactions count #371
Validate total ledger balance before starting up Services #258
Add a new rolling file to log all queries with controlled maximum rate #59
Other minor bugs #373
In Hedera Services v0.6.0, we’ve enhanced the Hedera Consensus Service by supporting HCS Topic Fragmentation. We added, into the
ConsensusSubmitMessageTransactionBody, an optional field for the current chunk information. For every chunk, the payer account that is part of the
initialTransactionID must match the Payer Account of this transaction. The entire
initialTransactionID should match the
transactionID of the first chunk, but this is not checked or enforced by Hedera except when the chunk number is 1.
Add support for HCS Topic Fragmentation
Protobuf v0.6.0 with HAPI doc update to support HCS Topic Fragmentation
Version 0.5.8 includes a patch which addresses the resilience of peer-to-peer networking in the hashgraph consensus platform.
In Hedera Services v0.5.0, we’ve added TLS for trusted communication with nodes on the Hedera network. For better security, only TLS v1.2 and v1.3 with TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and TLS_RSA_WITH_AES_256_GCM_SHA384 cipher suites are allowed. We’ve added new metadata in the Hedera NodeAddressBook, accessible in system file 0.0.101. The versions of the node software and gRPC Hedera API (HAPI) are now queryable via GetVersionInfo under the new NetworkService for node and network-scoped operations. For Hedera Consensus Service, we’ve updated the topic running hash calculation to use the SHA-384 hash of the submitted message, rather than the message itself. This reduces the storage requirements needed to validate the hash of a topic. The record of a ConsensusSubmitMessage transaction that uses the new hashing scheme will have a new topicRunningHashVersion field in its receipt. The value of the field will be 2. Hedera File Service also has several fixes of note. First, we enabled immutable files. Second, we relaxed the signing requirements for a FileDelete transaction to match the semantics of a revocation service. Third, we fixed a fee calculation bug that overcharged certain FileUpdate transactions. For Hedera Smart Contract Service, we’ve improved visibility into transactions that create child contracts using the new keyword by putting created ids in the record of the transaction; and we now propagate parent contract metadata to created children. Finally, if you use the throttle properties in system file 0.0.121 to estimate network performance limits, you will also be interested in a new standardized format of those properties. The lists below contain these and other minor updates, bug fixes, and documentation changes.
Add support for TLS
Expand address book metadata
Return all created contract ids
Propagate creator contract metadata
Introduce GetVersionInfo query
Standardize throttle configuration
Enforce file.encoding=utf-8 on startup
Make duration properties inclusive for readability
Use message SHA-384 hash in running hash
Enable immutable files
Relax FileDelete signing requirements
Fix sbh calculation in FileUpdate
Return metadata for deleted files
Enforce receiver signing requirements during contract execution
Reject invalid CryptoGetInfo
Reject CryptoCreate with empty key
Return NOT_SUPPORTED for state proof queries
Waive fees for 0.0.57 updating 0.0.111
Waive signing requirements for 0.0.55 updating 0.0.121/0.0.122
Waive all fees for 0.0.2
Do not throttle system accounts
Replace “claim” with “livehash” as appropriate
Standardize and clarify HAPI doc
Software update includes the ability for Hedera to dynamically set throttles on network transaction types.
The following throttles would be updated to: 1000 submit messages per second and 5 topic creates per second.
Reassigning of new Council Member nodes
Say hello to the Hedera Consensus Service! This release is the first to include HCS, allowing verifiable timestamping and ordering of application messages.
Network pricing has been updated to include HCS transactions and queries
Network throttle for HCS set to 1000 tps for submitting messages, and 100 tps for each of the other HCS operations.
Improved end to end testing.
General code clean up and refactoring.
ContractCall - TransactionReceipt response to ContractCall no longer includes the contractID called
CryptoUpdate - TransactionReceipt response to CryptoUpdate no longer includes the accountID updated
CryptoTransfer – CryptoTransfer transactions resulting in INSUFFICIENT_ACCOUNT_BALANCE error no longer list Transfers in the TransactionRecord transferList that were not applied
Java SDK has been updated to support the Hedera Consensus Service
Go SDK now supports all four mainnet services.
Transfer list within transaction records now shows only a single net amount in or out for each account, reflecting both transfers and any fees paid.
Fixed bug in fee schedule that had resulted in fees for ContractCallLocal, ContractGetBytecode, and getVersion queries being undercharged by ~33%
You may get more information regarding transaction record fees here.
The Hedera SDK Extension Components (SXC) is an open sourced set of pre-built components that aim to provide additional functionality over and above HCS to make it easier and quicker to develop applications, particularly if they require secure communications between participants.
Components use the Hedera Java SDK to communicate with the Hedera Consensus Service.
Learn more about Hedera SXC here.