Harmony is a blockchain designed to provide fast, secure, and scalable infrastructure. This article will cover the current picture and the plan for Harmony’s architecture. We’ll also address possible solutions for existing and potential hurdles of the network.
Bootnodes are responsible for bootstrapping nodes in the network. When a new node is introduced to the network, bootnode provides a set of nodes for the new nodes to sync with. This will allow the new node to have the necessary data to participate in the network.
Harmony is currently hosting 5 internal bootnodes for Mainnet. They are relatively cheaper than other services as they are lightweight instances. Despite their simplicity, bootnodes cannot be terminated at our current state as they are a critical service. Without them, new nodes will not be able to join the Harmony network. Harmony plans on fully externalizing all services and we once a detailed plan is set in stone, we will proceed with retiring the bootnodes.
Full nodes are the entry point to the Harmony network. They serve RPC requests such as querying information in the blockchain or processing transactions. Last year, Harmony transitioned from original RPC nodes to elastic RPC clusters to scale RPC requests. The transition for scalability was reasonable as Harmony was receiving a lot more requests in the previous years. However, now that the traffic amount has decreased, we have transitioned back to the legacy RPC nodes.
The motive for this transition is to prevent resources from being wasted and extra costs from occurring. We have fully terminated our ERPC clusters and have set up the required nodes to properly handle RPC requests. Harmony currently has 3 full nodes serving requests. They are fully utilized as the average max CPUs during the past week are all above 80%.
Harmony will constantly monitor the health and traffic of the full nodes. If more or less traffic occurs, the team will scale the nodes for the robustness of the network. We hope to
Leader node is responsible for constructing new blocks and broadcasting them to validators. Validator nodes verify the validity of blocks to ensure that the ones from malicious leaders do not get appended to the chain. Currently, leaders are chosen from the 20 internal validators hosted by Harmony (5 validators per shard). Each validator contains 5 BLS keys each, which totals 25 BLS keys per shard. These keys are the actual identity that gets selected as the leader.
Harmony’s plan is to fully externalize the voting slots as our end goal is a fully decentralized network. The plan is as follows:
| Voting Power (Internal Slots) | Internal | External |
|---|---|---|
| Current | 49% (100) | 51% (900) |
| 1st governance | 26% (48) | 74% (952) |
| 2nd governance | 0% (0) | 100% (1000) |
The governance for the first shutdown of internal nodes is happening currently: HIP-29. If the governance is approved, 2 nodes will be terminated per shard, making it 3 nodes per shard. Each node will have one less slot making it 4 slots per node and 12 slots per shard. Once the change is implemented, Harmony will have increased external voting power.
One concern we need to address is increased centralization. Increasing the external voting power may also increase the centralization of the network. A smaller number of participants with larger stakes may have more influence over the network’s decision. Along with this, there are other concerns Harmony has to confront and solve.
Full decentralization means an increased dependency on the external validators community. Harmony needs to find a swift mechanism to work with the community to prevent network failure. Without prompt action from external validators, the network may sustain more prolonged network outages.
The multiple governances will allow Harmony to cooperate with the community on finding a robust solution for a decentralized, secure network.