Network | Current Version | Upcoming |
Mainnet | 0.12.0 | 0.13.0 |
Testnet | 0.12.0 | 0.13.0 |
Previewnet | 0.13.0-alpha.2 | 0.14.0 |
MAINNET UPDATE SCHEDULED: MAY 6, 2021
TESTNET UPDATE SCHEDULED: APRIL 22, 2021
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.
MAINNET UPDATE COMPLETED: MARCH 12, 2021
TESTNET UPDATE COMPLETED: FEBRUARY 26, 2021
In Hedera Services v0.12.0, we completed the MVP implementation of the Hedera Scheduled Transaction Service (HSTS) as detailed in this design document. This service decouples what should execute on the ledger from when it should execute, giving new flexibility and programmability to users. Note that HSTS operations are enabled on Previewnet, but remain disabled on Testnet and Mainnet at this time.
We have given users of the Hedera Token Service (HTS) more control over the lifecycle of their token associations. In v0.11.0, deleted tokens were immediately dissociated from all accounts. This automatic dissociation no longer occurs. If account X
is associated with token Y
, then even if token Y
is marked for deletion, a getAccountInfo
query for X
will continue to show the association with Y
untilit is explicitly removed via a tokenDissociateFromAccount
transaction. Note that for convenience, queries that return token balances now also return the decimals
value for the relevant token. This allows a user to interpret e.g. balance=10050
as 100.50
tokens given decimals=2
.
In a final Hedera API (HAPI) change, we have extended the memo
field present on contract and topic entities to the account, file, token, and scheduled transaction entities. (Note this memo
is distinct from the short-lived memo
that may be given to any TransactionBody
for inclusion in the TransactionRecord
.) All of these changes to HAPI are now more easily browsed via GitHub pages here; the new hashgraph/hedera-protobufs
repository is now the authortative source of the protobuf files defining HAPI.
Apart from these enhancements to HAPI, the "streams" consumable by mirror node operators now include an alpha version of a protobuf file that contains the same information as the _Balances.csv
files. The type of this file is AllAccountBalances
.
MAINNET UPDATE COMPLETED: FEBRUARY 4, 2021
TESTNET UPDATE COMPLETED: JANUARY 26, 2021
In Hedera Services v0.11.0, we upgraded the record stream format from v2 to v5 and the event stream format from v3 to v5. These changes are described in detail in the "Record and Event Stream File Formats" article.
We also updated startup code to make the number of system accounts in development and pre-production networks match the number of system accounts on mainnet, creating account numbers 900-1000
on startup if they do not exist.
MAINNET UPDATE COMPLETED: JANUARY 7, 2021
TESTNET UPDATE COMPLETED: DECEMBER 17, 2020
In Hedera Services v0.10.0, we improved the usability of the Hedera Token Service (HTS) with a newTotalSupply
field in the receipts of TokenMint
and 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.
MAINNET UPDATE COMPLETED: DECEMBER 3, 2020
TESTNET UPDATE COMPLETED: NOVEMBER 19, 2020
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 bodyBytes
and 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 CryptoGetRecords
and 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.
MAINNET UPDATE COMPLETED: OCTOBER 22, 2020
TESTNET UPDATE COMPLETED: OCTOBER 7, 2020
The mainnet release includes the 0.8.0 version updates.
TESTNET UPDATE COMPLETED: SEPTEMBER 17, 2020
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.
MAINNET UPDATE COMPLETED: SEPTEMBER 8, 2020
TESTNET UPDATE COMPLETED: AUGUST 20, 2020
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.
Enhancements
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
Documentation changes
Bug fixes
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
MAINNET UPGRADE COMPLETED: AUGUST 6, 2020
TESTNET UPGRADE COMPLETED: JULY 16, 2020
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.
Enhancements
Add support for HCS Topic Fragmentation
Documentation changes
Protobuf v0.6.0 with HAPI doc update to support HCS Topic Fragmentation
MAINNET UPGRADE COMPLETED: JUNE 18, 2020 v0.5.8 includes all of the updates found in v0.5.0
TESTNET UPGRADE COMPLETED: JUNE 8, 2020
Version 0.5.8 includes a patch which addresses the resilience of peer-to-peer networking in the hashgraph consensus platform.
TESTNET UPGRADE COMPLETED: MAY 5, 2020
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.
Enhancements
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
Bug fixes
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
Documentation changes
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
JavaScript/Typescript SDK has reached version 1.0.0, supporting all four mainnet services
JavaScript/Typescript SDK supports both running in the browser (with Envoy Proxy) and in Node.
Go SDK now supports all four mainnet services.
Fees
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.