Hedera and Swirlds appreciate our community, which has shown such interest in and support for the hashgraph technology and network. To provide openness and oversight, we have been working together on releasing code for some time. First we released as open source the code for many of the tools and projects that work with the Hedera network, such as the mirror nodes and wallet software and multiple projects that build on it. Then we released as open source the code for the services that the Hedera network provides: cryptocurrency, smart contracts, files, and the Hedera Consensus Service (HCS). Today we are releasing as Open Review the code for the platform itself, which the services are built on. In addition, we are today extending our bug bounty program to also provide bug bounties for this code, in addition to the existing program for the code we have released in the past.
The code running on the Hedera mainnet consists of two components: platform and services. The platform code includes the gossip and consensus protocol code, and the various libraries that are used by the services code. The platform code compiles to a Java .jar file, which then provides the API that the services code uses to handle the user transactions, to provide services such as HCS. So the platform and services are the two components that together make up the code running on the Hedera mainnet.
This release is Open Review, rather than Open Source. In Open Review, the code is available only for reviewing, compiling, and testing, but not for any other use. In Open Source, the code is also available for broad use (not limited to reviewing and testing). The services, mirror nodes, and various tools were all released as Open Source while the platform is released as Open Review.
This difference is part of our commitment to those building on the Hedera ledger, that this ledger will be stable, without forking or splitting. The code is being released for review so that the community can understand what the code does, to build trust, and to allow suggestions for changes to the code. But it is limited to open review so that it will not be used to create a fork or split of the network.
Our goal is to avoid such forks, because of the problems it can cause for those building on the network. For example, imagine a dapp (distributed application) that records ownership of real estate. It might record who owns your house. When you sell your house, it records how the ownership has changed. It might even tokenize the house, and allow actual sales of it on the network itself. If a fork or split were to happen, someone could set up a new network running the same code, starting from the genesis state of the existing network. Then, when the house is later sold again, that sale might be recorded on just one network, but not the other. So the two networks would then give different results.
If it were possible for the network to fork or split, there could even be some of the nodes from the old network that decide to move to the new network, while others continue with the old network. So a phone app for title searches would end up communicating at random with one network versus the other, and could give two different answers depending on which network it contacts. This would be bad. It is important to do everything possible to ensure that the state will not split, and that there will always be a single ledger, with a single, authoritative state.
Another example is a token built on the network, such as an ERC-20 token. In this case, if you own some of that token, and the ledger forks or splits, with the ledger state being copied, then there would now be two different tokens, one on each network, with you owning an equal number of each of them. There is concern that this could potentially cause tax issues. The tax authorities in some jurisdictions might consider this to be a gain of property for which taxes must be paid. But you might not even be aware that you have gained those new tokens. And you might not even want them. So again, stability can be useful for making it less likely that your holdings will be duplicated by a fork without your knowledge or consent.
For all these reasons, we are releasing the code as Open Review: to ensure transparency, while discouraging forks and splits using this code.
This release doesn't change how the network works. And it doesn't change the ownership or IP licensing of the hashgraph algorithm, except for giving users a new ability to see, recompile, and test the source code.
Today, the source code is being made available for the public to access and download from a GitHub repo. We are not planning to develop the code in that repo, so it will not reflect all the commits as the code is being developed, and the repo will not have issues and pull requests. But we are committed to periodically committing a snapshot of the latest code to the repo. So the git history will show how the code evolves over time. This first snapshot is for version 0.8.0 of the code, which is the latest. This month's update to Mainnet will have a slightly different version, which is slightly older (because it has been running on the public testnet for a while). But the intent is that in the future, updates will commit to the repo the exact code that is deployed to run on Mainnet. So the two will stay in sync.
We are currently having an external code audit company audit both the platform and services code. When this audit is done, we will publish their report. We expect that later this quarter.
We are also extending our bug bounty program. We are continuing to offer bug bounties for the code we have open sourced in the past. In addition, we will now offer bug bounties for bugs in this open review code. Please see the bug bounty program page for details on how to submit bugs for possible rewards.
All other comments, bug reports, feature requests, or suggested code changes can be submitted as described in the README file in the repo. We appreciate your interest in the code, and will look forward to hearing any feedback you have.
Verifiable timestamps and ordering of events.