Welcome to HABS monorepository!
Check blog post for more information.
And all previous blog posts at https://medium.com/luguslabs/
HABS is a High Availability solution for Blockchain Services, aka HA for Blockchain Service, aka HABS.
- Polkadot Node
- Kusama Node
- Centrifuge Node
- Trustlines Node
Nowadays, many blockchain services are centralized on cloud infrastructure. For instance, around 70% of Ethereum nodes are in VPC and 63% of Ethereum Dapps use Infura Provider as this survey shows. We can imagine that in a few years some of blockchain services can be banned from public cloud providers.
The solution is to have a decentralized infrastructure at home. The problem is that it is challenging to maintain a good quality of service at home. You can have internet connection or power cuts. As a result, it is very unsafe to install a Proof-of-Stake validator at home. Your validator must be always up (24/7) and ready to execute its duty. If not, you will be slashed by the network and lose your money. To solve this problem, we are creating a solution to provide high availability for blockchain services. The first service that we target is Polkadot PoS Validator.
The idea behind HABS is federating some nodes between friends and family. We are using DAppNode as the infrastructure layer for our solution. With DAppNode, you can launch a blockchain node (Bitcoin, Ethereum ...) or any P2P software. We would like to thank DAppNode Team for their amazing work. To achieve the high availability of services at a DAppNode, we are adding HABS on top of it.
| Component | Description |
|---|---|
| Chain | Chain component is responsible for HABS state synchronization between participants |
| Orchestrator | Orchestrator is the decision-making component in HABS federation |
| CLI | CLI is a component that generates configuration and bootstraps an HABS federation |
| UI | UI is the HABS chain state visualization component |
| Deployer | HABS End-To-End tests, build scripts and deploy tools |
| DAppNodePackage | DAppNode package wrapping HABS |
Please refer to the README instructions in the sub-repositories for more information on building, using, and testing each software component.
To federate several nodes and have a shared state to elect a leader, we created a specific blockchain using the Substrate framework.
Substrate is a Parity framework that allows creating application-specific blockchains.
We created a Substrate runtime that collects all nodes heartbeats and sets federation leadership. This helps HABS orchestrator to select the best leader appropriately in the federation. We call this specific blockchain the HABS Substrate Chain or HABS Chain.
All nodes inside a federation, run HABS Chain. In the current implementation, an HABS must be composed of at least 4 nodes. That means that to operate, you have to set up at least 4 nodes. Try to set up nodes in different locations.
The idea is that in the HABS federation, all participants are trusted. They can be friends or family or other trusted social links. That allows us to have a fast chain consensus.
The HABS chain, needed for orchestration state, uses babe/grandpa consensus provided by the Substrate framework. To sum up, as soon as more than 2/3 of authorities attest to a chain containing a certain block, all blocks leading up to that one are finalized at once. When finalized, blockchains events are received by HABS nodes. That means that this high-availability solution needs (⅔ nodes + 1) HABS nodes up to operate properly. In other words, the automatic smart orchestrator supports (⅓ nodes - 1) HABS nodes down at the same time within the federation. If you setup n=9 HABS nodes authorities, you can tolerate 2 nodes down, 12 authorities you can tolerate 3 nodes down, and so forth...
Choose your High aAvailability security level through the number of nodes that suit your cost/benefit/security requirements. If your number of nodes down reaches the threshold limit ( you have to monitor, man). The chain will be stalled, cannot finalize state, and heartbeat events will no longer be received by nodes. In this specific case, orchestrators react and all service nodes ( Polkadot in our case ) will automatically switch to passive mode as a precautionary measure. You can then continue to "survive" with your validator duty: administrators must manually force the service node to operate under active|passive role instead of the default automatic orchestrator mode. At this manual stage, with HABS_SERVICE_MODE forced to ‘active’, you still benefit from the orchestrator that will monitor your Polkadot validator node to be always up and restart it if it crashes.
More information on chain/README.md
Orchestrator is the component that is responsible for decision making in an HABS Federation.
On each DAppNode instance and for their instance, orchestrators daemon pilot start, stop, restart of the Polkadot node in ‘active’ (validator) or ‘passive’ (sync only). All orchestrators need a shared state between them to operate properly. This shared state is provided by a customized Substrate chain created from Substrate node template v2.0.0-alpha.5. This is what is called: HABS chain.
- Launch external service in passive mode
- Send node heartbeats to HABS Chain
- Retrieve other nodes heartbeats from HABS Chain
- Retrieve current leader from HABS Chain and determine its availability
- If the current leader is alive, do nothing and ensure that the service was launched in passive mode
- If the current leader is not alive, try to take its place by making a transaction to HABS Chain
- If the transaction succeeded, the current node becomes the current leader of the federation
- Do supplementary checks (anyone other is alive, HABS Chain Node has any peers...)
- If supplementary checks pass launch external service in active mode
- You can operate multiple validator and leader inside the federation by filtering by groupId your nodes.
The first service targeted by HABS is Polkadot Validator.
The N Polkadot validators ( using group filter ) node can be launched with this kind of setup :
- 1 Active mode - Polkadot node in with validator option.
- 2 Passive mode - Polkadot node in the sync-only mode.
We are also planning to support other services.
More information on orchestrator/README.md
4 nodes are operators
| Node | Role |
|---|---|
| HABS-node-1-{active or passive} | operator |
| HABS-node-2-{active or passive} | operator |
| HABS-node-3-{active or passive} | operator |
| HABS-node-4-{active or passive} | operator |
You must have a minimum of the 4 HABS nodes to assure consensus substrate finality. ( tolarate 1/3 -1 )
Example of complex federation with 2 groups with 9 active/passive nodes.
HABS CLI is a component that generates configuration and bootstraps an HABS federation.
More information on cli/README.md
The HABS UI to administrate and visualize the federation state :
More information on ui/README.md
HABS End-To-End tests, build scripts and deploy tools.
More information on deployer/README.md
DAppNode package wrapping HABS stack.
It allows installing HABS from the DAppNode interface in one click.
More information on DAppNodePackage-HABS/README.md
The bootstrap development of HABS is financed by WEB3 Foundation's grant program Wave4. Thanks a lot for support.