Consensus Node
Consensus Node release information
Visit the Hedera status page for the latest versions supported on each network.
Release v0.64
Release v0.63
TESTNET UPDATE: JULY 10, 2025
Release Highlights
Release v0.63 introduces three focused improvements: birth-round based ancient event handling, low overhead SDK usage metrics, and full support for non-zero realm IDs.
Release v0.62
MAINNET UPDATE: JUNE 25, 2025
TESTNET UPDATE: JUNE 3, 2025
Release Highlights
Release 0.62 delivers substantial improvements in Ethereum compatibility, continuing Hedera’s commitment to providing a seamless and cost-effective experience for developers and ecosystem participants building with Ethereum tools and infrastructure. In addition, this release updates the HIP-991 SubmitMessage fees and lays the groundwork for block streams. What's new in Release 0.62?
Jumbo Ethereum Transaction Support (HIP-1086)
Historically, the Hedera API (HAPI) transaction size has been limited to 6 KB. Many Ethereum smart contracts and certain Ethereum contract calls exceed this limit. To work around this, developers previously had to utilize Hedera’s file service to upload larger contracts or call data in multiple 6 KB chunks — a process that added complexity, cost, and latency. Release 0.62 eliminates this friction by supporting a significantly larger transaction size of almost 128 KB for smart contract transactions, thereby simplifying EVM developer workflows and improving performance.
Key benefits:
Simplified development: Eliminates the need to write and maintain custom code to handle 6 KB chunking.
Reduced cost and latency: Streamlines common operations such as ContractCreate, ContractCall, and
EthereumTransaction.Improved cost efficiency for JSON-RPC relays: Lowers operational costs for relay providers.
Enhanced Ethereum compatibility: Brings the experience of creating and calling smart contracts on Hedera closer to native Ethereum workflows.
To support this capability, the release also introduces a reworked throttling system that protects against potential denial-of-service (DoS) attacks while maintaining fairness across transaction sizes.
Zero-Cost EthereumTransaction on Success (HIP-1084)
A frequently reported pain point from JSON-RPC relay operators has been the cost of submitting wrapper EthereumTransactions. While gas costs for contract execution are typically borne by the calling entity (EOA or contract), relay operators have been required to fund the HBAR-based transaction fee — resulting in reduced adoption and ecosystem participation. Release 0.62 addresses this by eliminating the cover charge for EthereumTransactions where the inner call completes and pays for the gas consumed.
Key benefits:
Simplified relay operation: Removes the need for relay operators or embedded relays in dApps to maintain funded HBAR accounts for successful calls.
Enhanced Ethereum compatibility: Further enhances Hedera’s Ethereum compatibility by charging all costs in gas alone.
Better ecosystem support: Encourages greater participation by third-party relay operators and dApp developers.
To maintain network security, malformed, underfunded, or invalid contract calls that fail to cover gas fees through regular mechanisms will still be charged a fee in order to prevent abuse.
Other updates:
In addition to the aforementioned features that improve Ethereum compatibility, Release 0.62 introduces two other updates:
SubmitMessage API calls for an HCS topic with Custom Fees (HIP-991) have been updated to $0.05 for the Hedera network.
Foundational improvements in block stream management and handling workflows that will enable future features in block streaming capabilities and performance in upcoming releases.
Summary:
Release 0.62 represents an important milestone toward making Hedera a highly competitive platform for Ethereum-compatible applications, completes the implementation of HIP-991, and sets up the foundation for streaming the network blocks and state information.
Performance Results
Release v0.61
MAINNET UPDATE: MAY 30, 2025
TESTNET UPDATE: MAY 20, 2025
Release Highlights
This release focuses on enhancing network incentivization and improving overall system robustness and developer experience.
Hiero Improvement Proposals (HIPs)
Daily rewards for active nodes HIP-1064: Full implementation of a daily reward mechanism for active consensus nodes, including an option for node operators to decline these rewards. This enhances network health by incentivizing consistent node uptime and participation, while providing operators flexibility in managing their rewards and improving network decentralization. Please note this feature will be disabled until a July 1, 2025 launch date.
HIP-551 (Atomic Batch Transactions): HIP-551 This release includes the implementation of Atomic Batch Transactions; however, due to technical challenges identified in testing, this feature has been temporarily disabled.
As a result, users attempting to submit Atomic Batch Transactions will receive a status code of
BUSYfrom the network. We are actively working to resolve these issues and plan to enable this feature in a future update.
New Features
Node Reward Opt-Out (HIP-1064): Node operators can now decline daily node rewards using a new decline_reward boolean flag in NodeCreateTransactionBody and NodeUpdateTransactionBody. This offers greater control and flexibility for node operators based on their specific requirements. The default value for this flag will be set to true to decline rewards by default.
// Example: Opting out of node rewards during node creation NodeCreateTransactionBody createBody = NodeCreateTransactionBody.newBuilder() // ... other fields like accountID, description, etc. .setDeclineReward(true) // Set to true to decline node rewards .build();
Notable Bug Fixes
#17478: Corrected Cancun SELFDESTRUCT Semantics: Fixed incorrect
SELFDESTRUCTbehavior per EIP-6780 post-Cancun, where a contract specifying itself as the beneficiary in a non-creation transaction erroneously triggered aSELF_DESTRUCT_TO_SELFerror. The fix ensures compliance with EIP-6780, allowing the operation to proceed without deleting the contract or transferring its balance, including native tokens. Additionally, refactored CustomSelfDestructOperation.execute to streamline validation checks before state changes. Impact: Enhances EVM compatibility and reliability on Hedera for contracts usingSELFDESTRUCT, ensuring correct execution under post-Cancun rules.
Performance Results
Release v0.60
MAINNET UPDATE: APRIL 16, 2025
TESTNET UPDATE: April 9, 2025
Release Highlights
This release focuses on significant performance improvements, enhanced developer tooling, and improved error handling.
Hiero Improvement Proposals (HIPs)
HIP-1021: Improve Assignment of Auto-Renew Account ID for Topics
Full implementation of improved auto-renew account ID assignment for topics, enabling setting
autoRenewAccountIdduring topic creation without an admin key.Developers benefit from simplified topic management and reduced risk of unexpected expirations.
Performance Results
Release v0.59
MAINNET UPDATE: MARCH 26, 2025
TESTNET UPDATE: MARCH 18, 2025
Release Highlights
HIPs:
HIP-991: Topic Fees
Description: HIP-991 introduces an optional fee system for submitting messages to topics on the Hedera network, aiming to enhance economic scalability and simplify operations for topic operators.
Benefits: Empowers topic operators with greater control over their topics, offering mechanisms to monetize and manage access. Key features include:
Optional Submission Fees: Topic operators can set optional fees for message submissions, payable in HBAR or Hedera Token Service (HTS) fungible tokens.
Fee Schedule Key: A new 'Fee Schedule Key' allows operators to manage and update fee structures. This key must be set during topic creation.
Custom Fee Distribution: Collected fees can be distributed to multiple accounts, supporting both HBAR and HTS tokens.
Fee Exemptions: Operators can specify a list of keys that are exempt from fees, allowing certain users to submit messages without incurring charges.
HIP-755: Schedule Service System Contract signSchedule(address, bytes)
Description: This HIP introduces a Schedule Service System Contract to enhance the Hedera Smart Contract Service (HSCS) by enabling smart contracts to interact with scheduled transactions. This release includes signSchedule(address, bytes).
Benefits: HIP-755 introduces a Schedule Service System Contract to enhance the Hedera Smart Contract Service by enabling smart contracts to interact with scheduled transactions. signSchedule(address, bytes) method, allows smart contracts to pass along the signature from an EOA needed for a scheduled transaction.
HIP-756: Scheduled Token Create/Update Transactions via Smart Contract
Description: Enables scheduling token create and update operations through smart contracts, with implementation of the scheduleNative system contract function.
Benefits: Expands smart contract functionality by allowing developers to schedule token operations directly from smart contracts, providing more flexibility in DApp development.
Release v0.58
MAINNET UPDATE: MARCH 12, 2025
TESTNET UPDATE: FEBRUARY 11, 2025
Release Highlights
This release introduces several new features, improvements, and bug fixes, including:
HIPs
HIP-755 authorizeSchedule(address) Adds functionality to the Hedera Schedule Service System contract so that a smart contract can sign a referenced scheduled transaction using its contract key, enabling automated execution of scheduled transactions directly from smart contracts. (#16983), the remaining outstanding features to complete HIP-755 will be provisioned in release .59.
Other Notable Changes
Enabled mirror node to simulate contract calls: The standalone transaction executor now supports custom Operations. Developers can use this feature to create and execute custom operations that are not part of the standard Hedera API. (#17354)
Enhancing Dynamic Address Book v2 NodeCreate and NodeDelete transaction signature requirements changed:
The NodeCreate transaction now requires the admin key and one of the treasury account key, system admin key, or address book admin key to sign.
Ensuring state changes are now in block streams: Refactored out-of-band state modifications: All out-of-band state modifications have been refactored to be done in Schemas. (#16843)
Release v0.57
MAINNET UPDATE: JANUARY 28, 2025
TESTNET UPDATE: JANUARY 8, 2025
Release Highlights
This release introduces several new features, improvements, and bug fixes, including:
HIPs
HIP-423: Long-Term Scheduled Transactions: This release completes the implementation of HIP-423, enabling schedules to execute transactions at a future date and time. This provides developers with a powerful tool for automating on-chain actions and building time-based applications. Benefits include:
Automated Transactions: Schedule transactions to execute automatically at a specific time.
Time-Based Applications: Build applications that rely on time-based events, such as recurring payments or token distributions.
Enhanced Security: Schedule transactions can be signed by multiple parties, ensuring that they are executed only when all required approvals are obtained.
New Features
Node Operator Queries: This release introduces a dedicated gRPC port for node operators to perform free queries. This enables node operators to monitor the network and their nodes more efficiently without incurring transaction fees.
Proxy Redirect Contract for Schedule Entities: This release adds support for a proxy redirect contract for calls to schedule transactions. This allows EOAs to make function calls in schedule entity addresses, enabling more flexible and dynamic interactions with scheduled transactions.
HSS System Contract: This release introduces the Hedera Schedule Service (HSS) system contract, providing a set of functions for managing scheduled transactions, including signing and authorizing schedules.
Support for Extra Dispatch Authorizations: The
ScheduleSignHandlernow supports authorizingKey{contractID=0.0.X}andKey{delegatable_contract_id=0.0.X}keys in a schedule's signatories list, enabling more granular control over schedule execution.
Performance Results
Release v0.56
MAINNET UPDATE: DECEMBER 11, 2024
TESTNET UPDATE: DECEMBER 4, 2024
Release Highlights
HIPs
HIP-869 Dynamic Address Book—Stage 1: This release includes the implementation of HIP-869, enabling the Dynamic Address Book. Node operators can now update node details and address books via Hedera transactions. This streamlines network operations and enables node operators to manage their associated node entries directly in the Address Book.
HIP-904 System Contract Functions: Implements the System Contract Functions section within HIP-904. Introduces Hedera Token Service (HTS) support for the airdrop-related capabilities. These functions are implemented as system contract functions, making it possible for smart contracts to issue Frictionless Airdrops, Token Reject, and AutomaticToken Association configurations for efficient management.
HIP-632 - isAuthorized(): The isAuthorized() function introduced in HIP-632 extends the Hedera Account Service (HAS) System Contract, enabling smart contracts to authenticate signatures against Hedera accounts. This provides functionality akin to the validation step following Ethereum's ECRECOVER, without recovering public keys. It supports ECDSA, ED25519, and complex keys such as threshold keys, though ECDSA is recommended for compatibility and interoperability with Ethereum. This builds on the previous functionality of isAuthorizedRaw() released in 0.52.
Other Notable Changes:
Block Streams - Dev Access Preview: Block Streams is a new output stream that will replace Hedera’s existing event and record streams into a single stream of verifiable data. This consolidated approach not only simplifies data consumption but also enhances Hedera's capabilities by including state data.
Starting with version 0.56, consensus nodes will publish preview block stream files alongside the existing record stream, which remains the authoritative source of truth for Hedera. This preview allows the community to explore, test, and provide feedback on this new feature, paving the way for its future adoption.
Migration from .pfx to .pem Cryptography Files: The consensus node cryptography system was migrated from using .pfx files to more manageable .pem files.
Performance Results
Release v0.55
MAINNET UPDATE SCHEDULED: NOVEMBER 13, 2024
TESTNET UPDATE SCHEDULED: NOVEMBER 5, 2024
Release Highlights
Notable Change
Throttle for AccountBalanceQuery
A new throttle for
AccountBalanceQueryrequests to manage and optimize query load on the network.
TESTNET UPDATE SCHEDULED: OCTOBER 29, 2024
Performance Results
Release v0.54
MAINNET UPDATE SCHEDULED: OCTOBER 23, 2024
TESTNET UPDATE SCHEDULED: OCTOBER 16, 2024
Release Highlights
This release introduces exciting new features and improvements, including HIP-904 for token airdrops, and HIP-1010 for updating custom fee via smart contracts.
HIPs
HIP-904: Token Airdrops and Claims
Implementation: Partial implementation
Delivered in this release:
TokenAirdrop transaction is similar to crypto transfers, but differs in one fundamental way - when an airdrop is performed and the receiver does not have available or automatic association slots, rather than failing, the transfer will be kept in state as a pending transfer.
TokenClaimAirdrop transaction introduced for recipients to claim pending airdropped tokens.
TokenCancelAirdrop transaction introduced giving senders the ability to cancel unclaimed airdrops.
Benefits:
Streamlines token distribution, empowers token creators, developers, and projects by allowing them to distribute tokens more efficiently to a wider audience.\
HIP-1010: Update Token Custom Fee Schedules via Smart Contracts
Implementation: Full implementation
Delivered in this release:
updateFungibleTokenCustomFees system contract function for updating custom fees for fungible tokens.
updateNonFungibleTokenCustomFees system contract function for updating custom fees for non-fungible tokens.
Benefits:
Enables smart contracts to manage token custom fees, providing more dynamic and autonomous token management capabilities.
TESTNET UPDATE SCHEDULED: OCTOBER 2, 2024
Performance Results
Release v0.53
MAINNET UPDATE SCHEDULED: SEPTEMBER 11, 2024
TESTNET UPDATE SCHEDULED: SEPTEMBER 4, 2024
Release Highlights
HIP-719: Associate and Dissociate Tokens via Facade Contract
Functionality
Delivered in release 0.53
isAssociatedfor token association via proxy facade contract.Syntax
<tokenAddress>.isAssociated()
Example
IHRC719(<tokenAddress>).isAssociated()
Delivered in prior release(0.38)
Associate and Dissociate Tokens via proxy facade contract
Benefits
Token functions are callable by both EOAs and contracts.
HIP-904: tokenReject, account infinite maxAutoAssociation & Sender pays auto association
Functionality
Partial completion of HIP-904 Delivered in 0.53
Sender pays for association
Sender now pays for token association at the time of HTS transaction execution.
Max_auto_associations
Default value for
max_auto_assocationswill now be-1meaning that if an account is created automatically by performing a token transfer to an alias that does not yet exist the account is configured with unlimited automatic token association.HAPI:CryptoCreate will continue to have
max_auto_associationsdefaulting to0.Accounts created before the launch of this feature will remain unchanged.
Token reject
Introduces TokenReject Transaction.
Benefits
maxAutoAssociationusers can update their account preferences to unlimited association giving the ability to receive any airdrops without explicitly having to associate with that token.Slots are only paid for when used, and are initially paid for by the sender during automatic associations.
HIP-850: HTS Mutable metadata in treasury
Functionality
Entire scope of HIP-850 delivered in release 0.53.
Enables the Supply Key to update an NFT metadata field while the NFT is held in the treasury account via TokenUpdateNftsTransaction function for a specific NFT serial number.
Benefits
NFT owners can return an NFT to treasury custody in order to update parameters within the metadata of the NFT.
NFT cannot be updated by unauthorized parties once distributed.
HIP-993: Improve record stream legibility and extensibility
Functionality
Delivered in release .53:
Itemized auto-creation fees
Unified child consensus times
Clean hollow account completion records
Synthetic file creations at genesis
Use natural order for preceding dispatch records
Planned for delivery in release .54:
Fail fast on throttled child transactions
Benefits
This HIP refines the legibility and extensibility of the record stream.
What's Changed
ci: resolves release issue preventing the publication of the docker images by @nathanklick in #15158
fix: hedera-evm and hedera-evm-impl are overwriting each other in MC by @rbarkerSL in #15175
What's changed
fix: change order of descriptor variables by @lpetrovic05 in #15016
Performance Results
Release v0.52
Release Highlights
HIP-632 - isAuthorizedRaw
Functionality
Accepts three parameters:
addressmessageHashsignatureBlob
Validates the provided address (Hedera Account ID or virtual address)
Determines signature type based on
signatureBloblength:65 bytes: ECDSA
64 bytes: ED25519
ECDSA Signature Handling
Extracts
v,r, andscomponentsRuns ECRECOVER to recover signing address
Compares result with the account's virtual addresses
ED25519 Signature Handling
Retrieves Hedera address
Checks for single associated key on account
Verifies signature against message hash and account key
Benefits
Similar functionality to Ethereum's ECRECOVER precompile
Supports both ECDSA and ED25519 signature verification
Works with Hedera Account IDs and virtual addresses
Simplifies signature verification in smart contracts
Streamlines transaction authentication within contracts
Enhances Hedera-Ethereum authorization flow compatibility
Improves developer experience with familiar authorization mechanism
TokenRect Functionality
Allows users to reject undesired tokens
Transfers thefull balance of one or more tokens from the requesting account to the treasury
Supports rejection of both fungible and non-fungible tokens
Handles up to 10 token rejections in a single transaction
Bypasses custom fees and royalties defined for the rejected tokens
Benefits of TokenReject
Enables users to remove unwanted tokens from their accounts
Protects users from potential scams or unwanted airdrops
Allows rejection of tokens regardless of how they were acquired (manual or automatic association)
Helps users manage their token holdings more effectively
Prevents users from being forced to pay exorbitant or potentially malicious fees to remove tokens
Maintains account association with the token, allowing for future transactions if desired
Provides a simple mechanism for users to clean up their accounts
Enhances user control over their token portfolio
Improves overall user experience in token management
MAINNET UPDATE SCHEDULED: AUGUST 28, 2024
What's Changed
fix: invalid
feeSchedules.jsonby @Neeharika-Sompalli in #14881
TESTNET UPDATE SCHEDULED: AUGUST 14, 2024
What's Changed
chore(0.52): updates the buildkit and docker daemon configuration to use the registry mirror by @nathanklick in #14777
fix: immediately finalize transfer lists for scheduled crypto transfer by @tinker-michaelj in #14799
What's Changed
ci: fix gradle publish failures in release-0.52 for hedera.com.evm by @rbarkerSL in #14513
fix: 14489 cherry pick docker rate limit fix in release052 by @rbarkerSL in #14490
fix(bug): Removed daemon config changes (#14599) by @rbarkerSL in #14602
fix: cherry pick misc fixes by @tinker-michaelj in #14609
TESTNET UPDATE SCHEDULED: JULY 31, 2024
What's Changed
The
accounts.maxNumberandnfts.MaxAllowedMintsvalues both remain at 20 million for this releasefeat: extract
HederaNetworkinterface with initialSubProcessNetworkimpl by @tinker-michaelj in #13540build: make annotation library dependencies transitive by @jjohannes in #13643
chore: Address compiler warnings in LoggerApiSpecAssertions by @jjohannes in #13644
chore: disabled new backpressure via settings by @cody-littley in #13635
chore: Add
FakePlatformandFakeServicesRegistryby @Neeharika-Sompalli in #13549docs: File Service design doc by @derektriley in #13615
build: (de)activate selection of javac lint features by @jjohannes in #11838
fix(reconnect): use AtomicLong for anticipatedMessages counter by @anthony-swirldslabs in #13650
feat: Move to fully connected network by @kfa-aguda in #13010
docs: add design document for HIP-904 token cancel airdrop transaction by @MiroslavGatsanoga in #12787
➡ See the full list of changes here.
Performance Results
MAINNET UPDATE: JULY 17, 2024
TESTNET UPDATE: JULY 2, 2024
Release Highlights
Functionality
Defines a new function to the Hedera Token Service system contract that allows for the atomic transfer of HBAR, fungible tokens and non-fungible tokens.
Function cryptoTransfer(TransferList transferList,TokenTransferList[] tokenTransfer)
Exposes an existing HAPI call via smart contracts.
Transfer respects granted allowances.
Benefits
Enables native royalty support on the EVM since native $hbar can now be transferred using spending allowances
Direct interaction with HBAR and HTS tokens
Eliminates the need for token wrapping.
Enhances efficiency and reduces complexity.
Cuts costs by removing intermediary steps i.e., wrapping assets to interact with them.
Enables native royalty support on the EVM since native HBAR can now be transferred using spending allowances
Functionality
Introduces a new Hedera Account Service system contract.
Enables querying and granting approval of HBAR to a spender account from smart contracts code
hbarAllowance, hbarApprove
Developers do not have to context switch out of smart contract code
Benefits
Introduces new account proxy contract for HBAR allowances
Enables grant, retrieve, and manage HBAR allowances within smart contracts
Developers do not have to context switch out of smart contracts code
Simplifies workflows and enhances security
Expands potential use cases, especially for DeFi and token marketplaces
What's Changed
feat(reconnect): introduce ReconnectMapStats interface by @anthony-swirldslabs in #13027
chore: revert removal of CLI report tool by @lpetrovic05 in #13002
docs: add design document for HIP-904 token reject operation by @MiroslavGatsanoga in #12786
feat: gossip facade by @cody-littley in #12897
feat: add the ability to disable the running event hasher by @cody-littley in #13083
fix: ignore token expiry status in
TokenDissociateby @tinker-michaelj in #13104feat: add javadoc and diagram, delete dead code by @tinker-michaelj in #13070
fix: use civilian payer for modified variants by @tinker-michaelj in #13020
fix: 12853: Memory leak from MerkleDbDataSource.copyStatisticsFrom() by @artemananiev in #13097
➡ See the full list of changes here.
Performance Results
MAINNET UPDATE: JUNE 20, 2024
TESTNET UPDATE: JUNE 5, 2024
What's Changed
chore: Cherry pick 13648 into release 0.50 branch by @lukelee-sl in #13662
fix(ci): cherry pick milestone assignee checks rel 50 by @rbarkerSL in #13712
fix: (cherry-pick) Use restart method to all token schemas by @Neeharika-Sompalli in #13676
➡ See the full list of changes here.
What's Changed
feat(diff-testing): Script (python) to pull intervals - up to a day - from GCP by @david-bakin-sl in #11409
test: add security v2 model tests for token associate by @anastasiya-kovaliova in #11327
fix: stop checking for minimum birth round by @cody-littley in #11769
feat: make the state compatible with birth rounds by @cody-littley in #11780
fix: FilteredLoggingMonitor by @mxtartaglia-sl in #11754
feat: diagram tweaks by @cody-littley in #11801
fix: wait longer for freeze transaction to be handled by @JeffreyDallas in #11790
➡ See the full list of changes here.
Performance Results
MAINNET UPDATE: MAY 22, 2024
TESTNET UPDATE: MAY 14, 2024
What's Changed
fix: support crypto admin keys in system contract
tokenCreate()by @tinker-michaelj in #13148fix: remove balance adjustment limit from record in state, use
0for initial gas snapshot by @tinker-michaelj in #13185
What's Changed
fix: cherry-pick midnight rate management on restart (#13071) by @povolev15 in #13091
feat: auto-resubmit operations with modifications (#12811) by @Neeharika-Sompalli in #13088
fix: ignore token expiry status in
TokenDissociateby @tinker-michaelj in #13106fix: avoid NPE when migrating from genesis (non-prod) state by @tinker-michaelj in #13123
What's Changed
fix: storage link management by @tinker-michaelj in #13056
What's Changed
fix: manage
StakingInfosin restart by @tinker-michaelj in #12911
What's changed
feat: address cold read issue in ExtCodeHash operation by @lukelee-sl in #11323
fix: 11348: The fix for 11231 doesn't cover ParsedBucket by @artemananiev in #11349
chore: Create ISS detector component by @lpetrovic05 in #11075
chore: remove hashgraph demo by @lpetrovic05 in #11352
➡ See the full list of changes here.
Performance Results
MAINNET UPDATE: APRIL 25, 2024
TESTNET UPDATE: APRIL 18, 2024
What's Changed
fix: remove adjustments limit by @tinker-michaelj in #12826
TESTNET UPDATE: APRIL 11, 2024
What's Changed
Performance Results
MAINNET UPDATE: APRIL 4, 2024
TESTNET UPDATE: MARCH 28, 2024
What's Changed
chore: cherry-pick unified CryptoCreate throttle reclamation (#12339).
TESTNET UPDATE: MARCH 20, 2024
What's Changed
chore: Configure
maxAggregateRelsto 15 million (all envs) (#12053).
What's Changed
fix: Update Configuration
hashesRamToDiskThresholdto 0 inMerkleDbConfigfix: Backport the fix for virtual map flushes.
TESTNET UPDATE: FEBRUARY 29, 2024
What's Changed
chore: add an old-style queue thread for intake by @cody-littley in #11671
fix: 11746: Backport the fix for #11304 to release 0.47 by @artemananiev in #11747
What's Changed
fix: bug when node is removed by @cody-littley in #10687
fix: Fuzzy matching for CreateOperationSuite and Create2OperationSuite 09431 by @JivkoKelchev in #10185
fix: recordCache to commit added entries and implemented correctly the remove elements from the queue by @povolev15 in #10523
fix: Fix and enable all Schedule HapiTests by @povolev15 in #10551
fix: implement sidecars by @JivkoKelchev in #9815
feat: add setting for birth round ancient threshold by @cody-littley in #10660
chore: drop chatter by @cody-littley in #10670
chore: remove state info by @cody-littley in #10685
fix: state leak by @cody-littley in #10690
➡ See the full list of changes here.
Performance Results
MAINNET UPDATE: FEBRUARY 21, 2024
TESTNET UPDATE: FEBRUARY 6, 2024
What's Changed
chore: bump HAPI proto version by @tinker-michaelj in #11232
TESTNET UPDATE: JANUARY 30, 2024
What's Changed
fix: Ensure that the pending creation customizer applies to the address being created by @lukelee-sl in #11213
What's Changed
chore: bump HAPI proto version by @tinker-michaelj in #11232
TESTNET UPDATE: JANUARY 23, 2024
What's Changed
feat: wiring diagram improvements by @cody-littley in #10233
chore: Change
HashMaptoLinkedHashMapin custom fees assessment by @Neeharika-Sompalli in #10240feat: add implementation in throttling facility to handle N-Of-Unscaled type of throttling by @MiroslavGatsanoga in #10142
build: do not publish test fixtures by @jjohannes in #10147
build: patch everything we use to be a real Java Module by @jjohannes in #10056
chore!: More common tests moved to correct module by @hendrikebbers in #10133
feat: Config constants created & used by @hendrikebbers in #10117
feat: script for cleaning build files by @cody-littley in #10190
fix: Compact last PCES file at boot time by @cody-littley in #10257
feat: sync++- by @cody-littley in #10260
➡ See the full list of changes here.
Performance Results
MAINNET UPDATE: JANUARY 9, 2024
TESTNET UPDATE: DECEMBER 28, 2023
What's Changed
fix: Added a feature flag which is by default enabled to disable tokenBalances and tokenRelationships in
getAccountInfo,getAccountBalanceandgetContractInfoqueries. #10639
Disable compression. by @cody-littley in #9554
Fix tests in unique token management spec by @mhess-swl in #9537
enaled one more test and remove the other one that not really in use by @povolev15 in #9557
Enable tests from CannotDeleteSystemEntitiesSuite by @Ivo-Yankov in #9440
Fix tests in ContractBurnHTSSuite by @agadzhalov in #9572
Tune dependency scopes by @jjohannes in #8455
unneeded calls to swirlds-common removed by @hendrikebbers in #9003
Enable test from AssociatePrecompileSuite by @mustafauzunn in #9571
Performance Results
MAINNET UPDATE: DECEMBER 19, 2023
TESTNET UPDATE: DECEMBER 12, 2023
What's Changed
Enforce NFT allowance check on auto-creation by @tinker-michaelj in e69d0a9
What's Changed
Catch UncheckedIOException during PCES file copy. (#10083) by @cody-littley in #10087
Bug Fixes
Features
Re-add bootstrap.properties file to maintain downstream processes and increase accounts.maxNumber=20_000_000 #8915
8815: sort dirty leaves during flush #8981
Add setting to disable critical quorum. #8961
Add a doc for all system entity numbers #8993
08566 - Validate PCES Events When Loading State On Different Network #8568
Differential testing analytic engine: State file file dumper now dumps special files #8991
Added improved startup ASCII art. #9028
Characterize invalid id failure modes for classic HTS calls #9053
Add ordinals to status diagram, and update javadocs #9108
5552: Create a Grafana Data Dashboard to view all existing relevant data metrics #8845
Update Besu to version 23.10.0 #9168
➡ See the full list of changes here.
Performance Results
MAINNET UPDATE: NOVEMBER 27, 2023
TESTNET UPDATE: NOVEMBER 2, 2023
Services v0.43.0 adds the following features:
HIP-786 (#8620)
Enhancements
Services v0.43.0 adds the following enhancements:
Update Besu to 23.10.0 - cherry pick (#9199)
Update the Besu EVM library to version 23.7.2 (#8472)
"Productizing" contract disassembler at last (#8563)
Auto sidecar validations (#8404)
Create fat jar with services CLI so it can be run standalone (#8519)
Performance Results
MAINNET UPDATE: OCTOBER 24, 2023
TESTNET UPDATE: SEPTEMBER 26, 2023
This release updates the platform SDK version from 0.42.0 to 0.42.6, which removes reconnect.asyncStreamTimeout from the settings files. Doing so ensures that this property will default to the value specified in code (300 seconds).
Changes
Upgrade platform SDK (#9224)
Changes
0.42 account balance test (#8866)
Re-add bootstrap.properties file and increase
accounts.maxNumber=20_000_000(#8928)
Changes
Chore: normalize configuration values (release/0.42) (#8668)
8751: No data source metrics for accounts, NFTs, or token rels (#8798)
Add EIP 2930 support to EthTXData (#7696)
Provide entity and throttle dashboards (#7774)
07748 Postconsensus signature gathering (#7776)
Enable EIP-2930 transactions by default (#7786)
7570: Remove JasperDB (#7803)
Remove support for legacy sync gossip. (#8059)
Disable account balance exports (#8272)
Modify config to support state on disk by default (#8510)
Performance Results
MAINNET UPDATE: SEPTEMBER 20, 2023
TESTNET UPDATE: AUGUST 22, 2023
Ethereum transaction type support is expanded to include type 1 transactions (#7670) which follow EIP 2930 RLP encoding. This increases the number of native EVM tools and scenarios the Hedera Smart Contract Service supports.
NFT mint pricing is changed to linearly scale based on number of serials minted. Also, minting a single NFT in collection is changed to cost $0.02 from $0.05. #7769
Performance Results
MAINNET UPDATE: AUGUST 15, 2023
TESTNET UPDATE: AUGUST 8, 2023
TESTNET UPDATE: JULY 19, 2023
The 0.40 release of Consensus Node delivers HIP-729 ~ "Contract Accounts Nonce Externalization". Smart contract developers using the Hedera public mirror node can now track contract nonces as they would on e.g., Ethereum. Use cases might include troubleshooting failed contract calls or writing unit tests that validate transaction ordering based on CREATE1 addresses (once these are set by default in release 0.41+).
Open source contributors to the project will notice major refinements in the Gradle build, thanks to @jjohannes's expert touch.
Performance Results
MAINNET UPDATE: JULY 11, 2023
TESTNET UPDATE: JUNE 21, 2023
Services v0.39.0 adds the following features:
VirtualRootNode constructor creates a cache object that doesn't get reused #6321
Implement blocklisting of EVM addresses #5799
Optimize virtual node cache flush strategy #5568
HIP-721: 06026 - add software version to events #6236
Implement CryptoCreate handle method #6112
UtilPrng handle Implementation #6310
Add a PCLI sub command to sign services stream files #6309
Implement token freeze handling #6467
Implement token unfreeze handle() #6502
Combine Admin and Network modules #6511
Implement the modular Pre-Handle Workflow #6291
Move hashes out of leaves node in VirtualMap #5825
TokenFeeScheduleUpdate handle() implementation #6582
Basic File service implementation #6522
Implement Token Association to Account #6609
Implementation of handle workflow #6476
Implement the modular record cache #6754
CryptoDelete handle implementation #6694
Performance Results
MAINNET UPDATE: JUNE 8, 2023
TESTNET UPDATE: JUNE 1, 2023
TESTNET UPDATE: MAY 18, 2023
Upgrade EVM to Shanghai #5964
EVM version update and optimizations #5962
Turn on the Shanghai version of the EVM in previewnet #6212
Update hedera-protobufs-java version to 0.38.10 #6579
Add PCLI command to sign account balance files #6264
Performance Results
MAINNET UPDATE: MAY 17, 2023
TESTNET UPDATE: APRIL 24, 2023
Features
Implement topic deletion prehandle (#5033)
Generalize workflows enabled and add workflow ports (#5032)
Pre-handle improvements (#5056)
Support auto-scheduling operations by type within a suite (#5054)
Add SPI and App components supporting TransactionDispatcher for modularized HCS (#5062)
added the missing functionality to FileSignTool (#5100)
Consensus Message Submission Prehandle (#5059)
Add IngestChecker mono adapters for sigs and solvency (#5098)
[HIP-583] Finalize hollow accounts via any required signature in a txn (#4990)
Remove CryptoCreate capability to create hollow accounts (#4998)
Populate EVM Address in CryptoTranscation (#5010)
Enable All EVM E2E suites to run with Ethereum Calls (#4375)
Performance Results
MAINNET UPDATE: APRIL 20, 2023
TESTNET UPDATE: APRIL 13, 2023
TESTNET UPDATE: APRIL 4, 2023
Features
Services v0.36.0 adds the following functionality:
Add tracking of property changes for hollow account completion (#4647)
Adding support for Redirect Token Calls fro evm-module (#4880)
Update FileSignTool (#4988)
Adding block number tool (#4997)
Add client.workflow.operations and test with workflows (#5053)
update hedera-services to use FSTS CLI instead of system properties
6166: Migrate VirtualMap data from JasperDB to MerkleDb data sources
Implementation of current network functionality in new, modularized application architecture: consensus operations, query workflow, and various preHandle implementations
Security Updates: Hedera Smart Contract Service Security Model Changes
Changes from services v0.35.2 have also been ported to v0.36.0.
After the security incident on March 9th, the engineers conducted a thorough analysis of the Smart Contract Service and the Hedera Token Service system contracts.
As part of this exercise, we did not find any additional vulnerabilities that could result in an attack that that which we witnessed on March 9th.
The team also looked for any disparities between the expectations of a typical smart contract developer who is used to working with the Ethereum Virtual Machine (EVM) or ERC token APIs and the behaviors of the Hedera Token Service system contract APIs. Such differences in behavior could be used by a malicious smart contract developer in unexpected ways.
In order to eliminate the possibility of these behavioral differences being utilized as attack vectors in the future, the consensus node software will align the behaviors of the Hedera Smart Contract Service token system contracts with those of EVM and typical token APIs such as ERC 20 and ERC 721.
As a result, the following changes are made as of the mainnet 0.35.2 release on March 31st:
An EOA (externally owned account) will have to provide explicit approval/allowance to a contract if they want the contract to transfer value from their account balance.
The behavior of
transferFromsystem contract will be exactly the same as that of the ERC 20 and ERC 721 spectransferFromfunction.For HTS specific token functionality (e.g. Pause, Freeze, or Grant KYC), a contract will be authorized to perform the associated token management function only if the ContractId is listed as a key on the token (i.e. Pause Key, Freeze Key, KYC Key respectively).
The
transferTokenandtransferNFTAPIs will behave astransferin ERC20/721 if the caller owns the value being transferred, otherwise it will rely on approve spender allowances from the token owner.The above model will dictate entity (EOA and contracts) permissions during contract executions when modifying state. Contracts will no longer rely on Hedera transaction signature presence, but will instead be in accordance with EVM, ERC and ContractId key models noted.
As part of this release, the network will include logic to grandfather in previous contracts.
Any contracts created from this release onwards will utilize the stricter security model and as such will not have considerations for top-level signatures on transactions to provide permissions.
Existing contracts deployed prior to this upgrade will be automatically grandfathered in and continue to use the old model that was in place prior to this release for a limited time to allow for DApp/UX modification to work with the new security model.
The grandfather logic will be maintained for an approximate period of 3 months from this release. In a future release in July 2023, the network will remove the grandfather logic, and all contracts will follow the new security model.
Developers are encouraged to test their DApps with new contracts and UX using the new security model to avoid unintended consequences. If any DApp developers fail to modify their applications or upgrade their contracts (as applicable) to adhere to the new security model, they may experience issues in their applications.
Performance Results
MAINNET UPDATE: MARCH 31, 2023
TESTNET UPDATE: MARCH 16, 2023
After the security incident on March 9th, the engineers conducted a thorough analysis of the Smart Contract Service and the Hedera Token Service system contracts.
As part of this exercise, we did not find any additional vulnerabilities that could result in an attack that that which we witnessed on March 9th.
The team also looked for any disparities between the expectations of a typical smart contract developer who is used to working with the Ethereum Virtual Machine (EVM) or ERC token APIs and the behaviors of the Hedera Token Service system contract APIs. Such differences in behavior could be used by a malicious smart contract developer in unexpected ways.
In order to eliminate the possibility of these behavioral differences being utilized as attack vectors in the future, the consensus node software will align the behaviors of the Hedera Smart Contract Service token system contracts with those of EVM and typical token APIs such as ERC 20 and ERC 721.
As a result, the following changes are made as of the mainnet 0.35.2 release on March 31st:
An EOA (externally owned account) will have to provide explicit approval/allowance to a contract if they want the contract to transfer value from their account balance.
The behavior of
transferFromsystem contract will be exactly the same as that of the ERC 20 and ERC 721 spectransferFromfunction.For HTS specific token functionality (e.g. Pause, Freeze, or Grant KYC), a contract will be authorized to perform the associated token management function only if the ContractId is listed as a key on the token (i.e. Pause Key, Freeze Key, KYC Key respectively).
The
transferTokenandtransferNFTAPIs will behave astransferin ERC20/721 if the caller owns the value being transferred, otherwise it will rely on approve spender allowances from the token owner.The above model will dictate entity (EOA and contracts) permissions during contract executions when modifying state. Contracts will no longer rely on Hedera transaction signature presence, but will instead be in accordance with EVM, ERC and ContractId key models noted.
As part of this release, the network will include logic to grandfather in previous contracts.
Any contracts created from this release onwards will utilize the stricter security model and as such will not have considerations for top-level signatures on transactions to provide permissions.
Existing contracts deployed prior to this upgrade will be automatically grandfathered in and continue to use the old model that was in place prior to this release for a limited time to allow for DApp/UX modification to work with the new security model.
The grandfather logic will be maintained for an approximate period of 3 months from this release. In a future release in July 2023, the network will remove the grandfather logic, and all contracts will follow the new security model.
Developers are encouraged to test their DApps with new contracts and UX using the new security model to avoid unintended consequences. If any DApp developers fail to modify their applications or upgrade their contracts (as applicable) to adhere to the new security model, they may experience issues in their applications.
Features
HIP-583 to expand alias support in CryptoCreate & CryptoTransfer Transactions.
This includes,
CryptoTransfer to non-existing EVM address alias causing hollow-account creation.
Finalizing a hollow account with the payer signature in an incoming transaction
Use cases for HIP-583 that work in this release :
As a user with an ECDSA based account from another chain I can have a new Hedera account created based on my evm-address alias.
As a developer, I can create a new account using a evm-address alias via the CryptoTransfer transaction.
As a developer, I can transfer HBAR or tokens to a Hedera account using their evm-address alias.
As a Hedera user with an Ethereum-native wallet, I can receive HBAR or tokens in my account by sharing only my evm-address alias.
As a Hedera user with a Hedera-native wallet, I can transfer HBAR or tokens to another account using only the recipient's evm-address alias.
Configuration Changes
autoCreation.enabled=true
lazyCreation.enabled=true
cryptoCreateWithAliasAndEvmAddress.enabled=false
contracts.evm.version=v0.34Performance Results
MAINNET UPDATE: FEBRUARY 9, 2023
TESTNET UPDATE: JANUARY 24, 2023
Use v0.34.3 SDK.
Services v0.34.0 completes the implementation of HIP-583.
To ensure full test coverage of this intricate feature, it will first be enabled only on previewnet.
This release will not enable smart contract rent.
Performance Results
MAINNET UPDATE: JANUARY 12, 2023
TESTNET UPDATE: DECEMBER 22, 2022
Services v0.33.0 adds the following features:
Hyperledger Besu EVM updated to version 22.10.x
'accounts send' subcommand added to yahcli to support sending HTS token units
Developer documentation updates
MAINNET UPDATE: DECEMBER 9, 2022
TESTNET UPDATE: DECEMBER 1, 2022
TESTNET UPDATE: NOVEMBER 11, 2022
TESTNET UPDATE: OCTOBER 27, 2022
Services 0.31 completes the following features:
HIP-542 roadmap for making payer of the
CryptoTransfersponsor forauto-creation. It also enables auto-creation with Token transfers in addition to Hbar transfers.HIP-564 roadmap for allowing zero unit fungible token transfers
HIP-573 roadmap for enabling token creators an option to exempt all of their token’s fee collectors from a custom fee.
In addition to the above features,
Adds support of the ERC20/721
transferFrommethod for HTS precompiles from HIP-514 roadmap.Enables Smart Contract Traceability.
Adds some changes related to testability improvements.
MAINNET UPDATE: OCTOBER 21, 2022
TESTNET UPDATE: OCTOBER 19, 2022
TESTNET UPDATE: OCTOBER 6, 2022
Services 0.30 completes the HIP-514 roadmap for making Hedera native tokens manageable via smart contracts. There are five new system contracts: getTokenExpiryInfo(address), updateTokenExpiryInfo(address, Expiry), isToken(address token), getTokenType(address token), and updateTokenInfo(address, HederaToken).
The updateTokenInfo(address, HederaToken) call is especially powerful. If a token's admin key signs the transaction calling a contract, that contract can now make itself the token's treasury, assume authority to mint or burn units or NFTs, and so on.
⚠️ Contract authors should know this release initiates Hedera's expiration and rent model for contracts. There will be two visible effects immediately after the 0.30 upgrade:
All non-deleted contracts will have their expiry extended to at least 90 days after the upgrade date.
Deleted contracts will start to be purged from state; so a
getContractInfoquery that previously returnedCONTRACT_DELETEDmay now reportINVALID_CONTRACT_ID.
About 90 days after the 0.30 upgrade, some contracts will begin to expire. The network will try to automatically charge the renewal fee (approximately $0.026 for 90 days) to the expired contract's auto-renew account. If an auto-renew account has zero balance, the network will then try to charge the contract itself.
A contract unable to pay renewal fees will enter a week-long "grace period" during which it is unusable, unless its expiry is extended via ContractUpdate or it receives hbar. After this grace period, the contract will be purged from state.
We strongly encourage all contract authors to set an auto-renew account for their contract. This isolates the contract logic from the existence of rent.
This release also brings two peripheral improvements:
It will become possible to schedule a
CryptoApproveAllowancetransaction.Mirror node operators will be able to use the daily
NodeStakeUpdateexport to track the current values of several key staking properties. Please review the linked protobuf comments for more details on these properties.
MAINNET UPDATE: SEPTEMBER 27, 2022
TESTNET UPDATE: SEPTEMBER 7, 2022
TESTNET UPDATE: AUGUST 30, 2022
Contract-managed tokens 🪙
In Services 0.29 we have followed the HIP-514 roadmap to give contract authors many new ways to inspect and manage HTS tokens.
The HIP enumerates the ways; examples include a contract that revokes an account's KYC for a token, or deletes a token for which it has admin privileges, or even changes a token's supply key based on the metadata in an NFT!
Note there are four HIP-514 functions that will be part of release 0.30, as follows: getTokenExpiryInfo(address), updateTokenExpiryInfo(address, Expiry), updateTokenInfo(address, HederaToken), isToken(address token) and getTokenType(address token).
HIP-435 Record Stream v6 will be enabled on testnet and mainnet in this release.
Deprecations
Please note this important deprecation that will change how clients fetch token associations and balances after the November release in this year. At that time, mirror nodes will become the exclusive source of token association metadata. This is because HIP-367 made token associations unlimited, so in the long run it will not be efficient for consensus nodes to serve this information.
MAINNET UPDATE: AUGUST 25, 2022
TESTNET UPDATE: JULY 29, 2022
Services 0.28 gives Hedera devs a new dApp building block in HIP-351 (Pseudorandom Numbers). HAPI has a new UtilService with a prng transaction that generates a record with either a pseudorandom 48-byte seed, or an integer in a requested range.
Smart contracts can also get pseudorandom values by calling a new system contract at address 0x169, using the interface here as in this example. Applications might include NFT mint contracts, lotteries, and so on.
📝 The HIP-351 text does not yet reflect the name change from RandomGenerate to prng, or the system contract specification. It does explain in detail how prng derives its entropy from the running hash of transaction records generated by the network.
This release also includes some bug fixes and smaller improvements; notably, it:
Extends
ContractCallLocalsupport to the ERC-20 and ERC-721 functionsallowance,getApproved, andisApprovedForAll.Permits staking to contract accounts.
v0.27.7
MAINNET UPDATE: AUGUST 9, 2022
Any ledger that will grow to billions of entities must have an efficient way to remove expired entities. In the Hedera network, this means keeping a list of NFTs owned by an account, so that when an account expires, we can return its NFTs to their respective treasury accounts.
Under certain conditions in the 0.27.5 release, a bug in the logic maintaining these lists could cause NFT transfers to fail, without refunding fees.
We appreciate the Hedera community working with us on this issue. We invite any users who were affected by this bug to contact support at [email protected].
v0.27.0
MAINNET UPDATE: JULY 21, 2022
TESTNET UPDATE: JULY 1, 2022
The 0.27 release of Consensus Node initiates the first phase of HIP-406 (Staking). We deeply appreciate the community’s feedback on this critical feature!
As wallets and exchanges roll out client support, users will now have the choice to stake their hbar to a node. As nodes accumulate stake, from both individuals and organizations, they will become eligible to pay rewards to their stakers. At this point, once the 0.0.800 account balance has crossed a threshold to be set by the council coin committee, rewards will be permanently activated.
This will set the stage for the second phase of staking, in which a node’s contribution to consensus becomes a direct function of its stake, and community nodes with sufficient stake can begin to participate in consensus. Please note the decentralized nature of this process makes it hard to predict exactly when each milestone and phase will be achieved. The immediately visible consequences of the 0.27 release will be simply,
The consensus nodes handle
CryptoCreateandCryptoUpdatetransactions with staking elections---even if not all wallets and exchanges are updated to make these elections just yet.
Observant readers might recall that an earlier alpha release of Services 0.27 also enabled HIP-423 (Long Term Scheduled Transactions). This is a complex feature with some deep implications, and we have decided to defer for one more release before going to production.
MAINNET UPDATE: JUNE 9, 2022
TESTNET UPDATE: MAY 25, 2022
In this release, we are excited to deploy support for HIP-410 (Wrapping Ethereum Transaction Bytes in a Hedera Transaction). and HIP-415 (Introduction Of Blocks).
HIP-410 adds a HAPI EthereumTransaction by which an account that was auto-created with an ECDSA(secp256k1) key can submit Ethereum transactions to Hedera by signing with its ECDSA key. (Standard Ethereum restrictions on the sender's nonce apply.) Please see HIP-410 for details, including a summary of some very compelling use cases that the EthereumTransaction enables---for example, "I want to use MetaMask to create a transaction to transfer HBAR to another account".
HIP-415 also anticipates such use cases by standardizing the concept of a Hedera "block"; this is important for a full implementation of the Ethereum JSON-RPC API. The definition is simple: One block is all the transactions in a record stream file. The block hash is the 32-byte prefix of the transaction running hash at the end of the file. And the block number is the index of the record file in the full stream history, where the first file had index 0.
Consensus Node 0.26 implements HIP-376, allowing smart contract developers to use the familiar EIP-20 and EIP-721 "operator approval" with both fungible and non-fungible HTS tokens.
Approved operators can manage an owner's tokens on their behalf; this is necessary for many consignment use cases with third party brokers/wallets/auctioneers.
Any permissions granted in a contract through approve() or setApprovalForAll() have an equivalent HAPI cryptoApproveAllowance or cryptoDeleteAllowance expression---and this expression is externalized as a HAPI TransactionBody in the record stream. That is, the HIP-376 system contracts expose a subset of the native HAPI operations, only within the EVM.
MAINNET UPDATE: MAY 19, 2022
TESTNET UPDATE: APRIL 26, 2022
TESTNET UPDATE: APRIL 21, 202
The Consensus Node 0.25 release brings good news for HTS users who manage large numbers of token types, as it delivers HIP-367 (Unlimited Token Associations per Account). In particular, a single account can now serve as treasury for any number of token types. (Please do note the CryptoService HAPI queries still return information for only an account’s 1000 most recently associated tokens; mirror nodes remain the best source for full history.)
We are also very excited to announce support for HIP-358 (Allow TokenCreate through Hedera Token Service Precompiled Contract). This HIP supercharges contract integration, making it possible for a smart contract to create a new HTS token---fungible or non-fungible, with or without custom fees. (An interested Solidity developer might consult the examples in this contract.)
In a harbinger of more upcoming HTS precompile support, this release will also enable HIP-336 (Approval and Allowance API for Tokens). Token owners can now approve other accounts to manage their HTS tokens or NFTs, in direct analogy to the approve() and transferFrom() mechanisms in ERC-20 and ERC-721 style tokens.
Enhancements
Fixes
ERC
viewfunctions now usable inContractCallLocalQuery#3061
MAINNET UPDATE: APRIL 15, 2022
TESTNET UPDATE: APRIL 7, 2022
TESTNET UPDATE: MARCH 31, 2022
TESTNET UPDATE: MARCH 24, 2022
In the 0.24 release of Consensus Node, we are excited to give smart contract developers a new level of interoperability with native Hedera Token Service (HTS) tokens via HIP-218 (Smart Contract interactions with Hedera Token Accounts). The Hedera EVM now exposes every HTS fungible token as an ERC-20 token at the address of the token’s 0.0.X entity id; and analogously, every HTS non-fungible token appears as an ERC-721 token. This means a smart contract can look up its balance of a fungible HTS token; or change its behavior based on the owner of a particular HTS NFT. Please see the linked HIP for full details.
This upgrade also creates two new system accounts 0.0.800 and 0.0.801 that will hold reward funds.
One change to the Hedera API (HAPI) is that we now have enough evidence to conclude the experimental getAccountNftInfos and getTokenNftInfos queries do not have a favorable cost/benefit ratio, and these queries are now permanently disabled.
MAINNET UPDATE: MARCH 10, 2022
TESTNET UPDATE: FEBRUARY 17, 2022
Consensus Node 0.23 fleshes out our smart contract service via the implementation of HIP-329 (Support CREATE2 opcode). Smart contract developers are now free to use the CREATE2 EVM opcode. A typical use case is a distributed exchange that wants its pair contracts to have deterministic addresses based on the tokens in the pair.
Please note two issues fixed in this release. First, in release 0.22, the nodes returned the bytes ledger_id stipulated by HIP-33 as a UTF-8 encoding of a hex string. The returned bytes are now the big-endian representation of the ledger's numeric id. Second, prior to this release, the record of a dissociateToken from a deleted token did not list the discarded balance of the dissociated account if the token's treasury was missing. This is now fixed.
MAINNET UPDATE: FEBRUARY 3, 2022
TESTNET UPDATE: JANUARY 20, 2022
The 0.22 release is a paradigm shift for Consensus Node, as we deliver the next major step in our Smart Contracts 2.0 roadmap on the strength of the protean HIP-25, a technical foundation for scaling the world state of our ledger to billions of entities without sacrificing the high TPS enabled by the hashgraph consensus algorithm.
Highlights of this release include:
Network EVM capacity increased to 15M
gas-per-second. (Please see HIP-185 for details.)Gas limit per
ContractCreateorContractCallraised to 4M.Per-contract storage capacity increased to 10MB.
Solidity integration with native HTS tokens. (Please see HIP-206 for details.)
We expect more progress in these directions over the coming releases. Do note that the gas usage of the HTS integrations is still evolving; follow this issue to track the finalized gas charges leading up to mainnet release.
There are two other HIP's included in this release not related to the smart contract service. First, HIP-33 enhances queries like CryptoGetInfo with a ledger id that marks which Hedera network answered the query. Second, HIP-31 allows a client to include the expected decimals for a token in a CryptoTransfer. This means a hardware wallet can guarantee its token transactions will have the precision seen by the user in the device display.
While we are gaining momentum in our smart contracts roadmap, we are also deeply committed to improving the developer experience, and welcome issues and ideas in our GitHub repository and Discord!
MAINNET UPDATE: JANUARY 13, 2022
TESTNET UPDATE: DECEMBER 21, 2021
In Consensus Node 0.21 we are pleased to announce support for ECDSA(secp256k1) keys and auto-account creation.
The Ethereum network makes heavy use of ECDSA cryptography with the secp256k1 curve, and by supporting these keys we ease the developer experience of migrating a dApp to Hedera. Anywhere a Ed25519 key can be used in the Hedera API, it is now possible to substitute an ECDSA(secp256k1) key.
Auto-account creation lets a new user receive ℏ via a CryptoTransfer without having already created an 0.0.X id on the network. The new user only needs to provide their public key, and when a sponsor account sends ℏ "to" their key via a new AccountID.alias field, the network automatically creates an account with their key. Additional transfers to and from an auto-created account may also use its alias instead of the account id.
An alias may also be used to get the account balance and account info for the account. (Do note there is a known issue that causes the getAccountInfo query response to echo back the account alias instead of its 0.0.<num> id; this will be fixed in the next release. Please use the free getAccountBalance query to check the 0.0.<num> id that corresponds to an alias.) You will be able to use the alias in all other transactions and queries in a future release.
Meanwhile, our team continues exhaustive due diligence for Smart Contracts 2.0... 🚀
MAINNET UPDATE: DECEMBER 2,2021
TESTNET UPDATE: NOVEMBER 18, 2021
Consensus Node 0.20 is primarily a scaffolding release, as our team is working heads-down to deliver the Smart Contract Service refresh with massive new scale and performance; as well as smart contract integration with native tokens created using the Hedera Token Service. The scope of this refresh is significant, and we believe it will be well worth the wait.
The main deliverables in this release are improved automation for node operators to use in software upgrades; and a handful of minor bug fixes, including for #2432.
Please also note the following deprecations in the Hedera API protobufs:
The
ContractUpdateTransactionBody.fileIDfield, which is redundant given the existence of theContractGetBytecodequery.The
ContractCallLocalQuery.maxResultSizefield, as this limit is now simply a side-effect of the given gas limit.
MAINNET UPDATE: NOVEMBER 4,2021
TESTNET UPDATE: OCTOBER 28, 2021
TESTNET UPDATE: OCTOBER 21, 2021
In Consensus Node 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.
MAINNET UPDATE: OCTOBER 7, 2021
In Consensus Node 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.
v0.18.0
TESTNET UPDATE: SEPTEMBER 23, 2021
In Consensus Node 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.
Then, when their account receives units or NFT's of a new token type via a CryptoTransfer, the network automatically creates 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 not be 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.
Performance Measurement Results:
MAINNET UPDATE: SEPTEMBER 2, 2021
TESTNET UPDATE: AUGUST 30, 2021
In Consensus Node 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 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)
⚠️ There are two temporary limitations to HIP-18 in this release. First, the 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.
Performance Measurement Results:
TESTNET UPDATE: AUGUST 24, 2021
Please see 0.17.4 release notes.
TESTNET UPDATE: AUGUST 19, 2021
Please see 0.17.4 release notes.
MAINNET UPDATE COMPLETED: AUGUST 5, 2021
TESTNET UPDATE COMPLETED: JULY 22, 2021
In Consensus Node 0.16.0, 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.
⚠️ There is one variation on custom fees that requires a work-around in this release. Specifically, if a fixed fee should be collected in the units of the "parent" token to whose schedule it belongs, then in Release 0.16.0 this must be accomplished using a 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.
Performance Measurement Results:
MAINNET UPDATE COMPLETED: JULY 1, 2021
TESTNET UPDATE COMPLETED: JUNE 17, 2021
In Consensus Node 0.15.1, we improved performance and integrated with the latest Platform SDK to enable full support of network reconnect.
These performance improvements let us augment the Hedera world state with records of all transactions handled in the three minutes of consensus time, even when handling 10,000 transactions per second. The HAPI GetAccountRecords query now returns, from state, all such records for which the queried account was the payer account.
We have 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 hedera-protobufs GitHub repository.
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.
MAINNET UPDATE COMPLETED: JUNE 3, 2021
TESTNET UPDATE COMPLETED: MAY 20, 2021
In Consensus Node 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 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).
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.
MAINNET UPDATE COMPLETED: MAY 6, 2021
TESTNET UPDATE COMPLETED: APRIL 29, 2021 [v0.13.2]
TESTNET UPDATE COMPLETED: APRIL 22, 2021 [v0.13.0]
In Consensus Node 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.2 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.
MAINNET UPDATE COMPLETED: MARCH 12, 2021
TESTNET UPDATE COMPLETED: FEBRUARY 26, 2021
In Consensus Node 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 _until_it 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 TransactionBodyfor 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 authoritative 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 Consensus Node 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 Consensus Node 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 numbers 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 Consensus Node 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 Consensus Node 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.
Enhancements
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.
getTxRecordAPI will continue to return ALL records with the transaction ID.
MAINNET UPDATE COMPLETED: SEPTEMBER 8, 2020
TESTNET UPDATE COMPLETED: AUGUST 20, 2020
In Consensus Node 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. Consensus Node 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 Consensus Node 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.
v0.5.0
TESTNET UPGRADE COMPLETED: MAY 5, 2020
In Consensus Node 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
v0.4.1
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
v0.4.0
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
Miscellaneous
SDKs
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.
SDK Extension Components
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.
Last updated
Was this helpful?