Note: this blog post was updated on March 16, 2023.
We appreciate feedback from the Hedera developer community and strive to do what’s best for those using Hedera software and tools. We recently received feedback about early access to Hedera test network functionality and how we communicate testnet and mainnet network status and upgrades. We’re excited to share how we've planned to address this feedback moving forward.
In addition, we want to share more detailed information with you about the state of Hedera’s mainnet nodes and node software release v0.5.0 — specifically, the addition of IP proxies and TLS 1.2 & 1.3 support for additional network security and client privacy.
The developer community has expressed interest in early access to new network features and functionality, prior to their availability on the Hedera testnet and mainnet. In response, Hedera has made the decision to operate two publicly accessible test networks:
Both the “stable” and “preview” testnets will be composed of four nodes operated by Hedera in Google Cloud, publicly accessible, and using the same throttles as the mainnet. A mirror node will be available by Hedera for both networks. Accounts can be created for the preview testnet in the developer portal at portal.hedera.com. We expect the previewnet to go live in May.
We’ve also implemented new internal rules and communication processes for planned testnet and mainnet downtime. Hedera's mainnet software roadmap includes rolling upgrades by late 2020 but, until then, any codebase-related network upgrades require downtime and a subsequent restart. The developer community has expressed the need for earlier and more consistent communication across all channels when this happens.
To ensure our developer community has an adequate amount of time to adapt application code (if necessary), Hedera has decided that all upgrades/planned downtime for the testnet and mainnet will require a 5 business days' notice and communications. The communications will include a link to the release notes in the Hedera docs before it’s deployed, for detailed information about the upcoming release. The source of truth for network status and planned network upgrades for Hedera’s mainnet, testnet, and soon, preview testnet, will always be available at https://status.hedera.com — you can email subscribe or use the RSS feed link for live status updates. Hedera will also provide updates in the #network-status channel in the Hedera developer Discord.
Whenever upgrades occur on the testnet or previewnet, developers who created their account through the Hedera Portal will receive an email notice of the network upgrade. In some cases (more likely on the previewnet), this means old account IDs are purged and you’ll receive a new account ID and associated keys — the email notice will contain your new account ID, public key, and private key to get back up and running more smoothly. Those keys will also be available in the Hedera Portal, after logging in.
Hedera's mission is to become the most decentralized and utilized public network at scale in the market. We measure decentralization in the following ways:
The Hedera mainnet today consists of 13 nodes — 4 of which are operating in Google Cloud and managed by Hedera but controlled by individual council members. The 9 other nodes are running in unique hosting providers (Centrilogic, HiVelocity, MassiveGrid, Digital Ocean, Linode, Microsoft Azure, Equinix, IBM Cloud and Tata Communications’ corporate data center). During the next mainnet upgrade (v0.5.0 set for May 12th), one of the Hedera GCP nodes will be replaced by an independent node in GCP managed by Google.
You may already know that the underlying hashgraph algorithm is natively DDoS resistant through its “leaderless” system — and the Hedera network assists further with DoS and DDoS resistance via fees paid in HBAR per every transaction, making it expensive for an attack to persist.
But with the Hedera network still in its infancy, having additional protections in place for node operation will ensure a safe path towards permissioned expansion and, eventually, our goal of a fully permissionless network. For this reason, the Hedera Council’s Technical Steering & Product Committee* has approved the decision to place proxies in front of testnet and mainnet nodes. The purpose of implementing proxies are to protect individual nodes from Denial of Service attack, while having zero impact on consensus within the network or between the nodes.
These proxies will be deployed to the stable testnet v0.5.0 release on May 5th and mainnet v0.5.0 release on May 12th. These proxies will be distributed across three cloud environments (Google Cloud, AWS, and Microsoft Azure), per each node (39 proxies total). They’ll be fully controlled by Hedera today — but full control and ownership will be passed to every council member node operator individually no earlier than v0.7.0 of the Hedera node software, to continue forging our path towards decentralization. Hedera Governing Council members joining the network today will be required to stand up proxies, which they will singularly control after the transition period of co-control**, within their existing environment and geography, as to ensure consistent network performance.
The addresses for these proxies are listed in the Hedera documentation (docs.hedera.com), as well as in the address book file (0.0.101) stored on the network. With the upcoming v0.5.0 update, you’ll need to ensure your applications are pointing to this updated address book.
TLS (transport layer security) is a foundational security and privacy standard ubiquitous on the modern web. We’re excited to announce that v0.5.0 of the Hedera network software will include native support for TLS 1.2 and 1.3. Although Hedera is a public network and ultimately messages/transactions (encrypted or not) end up on the Hedera public ledger, TLS allows users to prevent eavesdropping on their connection to the mainnet, and prevents attackers from modifying messages they receive. We encourage all users to take advantage of this new security functionality.
The address book file starting in v0.5.0 includes a certificate hash to enable clients to optionally use TLS. They can verify the certificate for the connection against the certificate hash stored in the network address book. Any Hedera node running network software v0.5.0 will support TLS through port 50212. The Hedera documentation will explain how to set this up, upon release of v.0.5.0 to the testnet Tuesday, May 5th, 2020.
* Updated to clarify that TechCom, not the Hedera Governing Council overall, voted to approve the introduction of proxies.
** Updated to clarify that Hedera staff and contractors also have access to the proxies of new Council members.