Hi everyone! The team has agreed and accepted design solution, development workflow and the process of Hyperchains implementation has started.
This roadmap is based on our current landscape with existing Aeternity node and describes estimated integration scenario with the all Hyperchains features atop of the chain agnostic core design.
The preliminary stage (Github projects setup + CI pipeline (4 man-day):
Hypechains project should be decoupled into the core part and so called connectors lib.
The core part of Hypechains should be placed inside aeternity monorepo to preserve CI pipeline for the sake of compatibility between releases.
hypechains_connectors repo should be located separately and has to be covered by CI pipeline. The finished pipeline should be passed only if the connectors are able to execute their requests and to fetch the data via parents chain protocols (until code is done to replace it with mock functions)
Core node surgery stage (7 man-day):
To provide so called “stub” interface inside the aeternity core part. This interface should cover the chain format functionality (we are decided to avoid the term “plugin” as we are not going to enrich the current PoW solution but to make chain agnostic interface instead).
The all mounting points of the chain interface should be covered by testing contracts and be checked on the pipeline stage. The main criteria of success is that after interface has injected the existing PoW solution has to pass the all test suites and preserves the correct system behaviour as is and without any little change
Chain stub interface implementation (7 man-day):
The chain interface should support the new changed format of Hyperchain block structure and has to solve the all serialization/deserialization format issues. The acceptance criteria for this step is successful check for the chain format test contract. Until Hyperchains is selected the default PoW chain interface should be preserved
Parent chain communication protocol (14 man-day):
Parent chain interaction consists of posting transaction payload/contract execution request and fetch chain state request and should be provided via hypechains_connectors lib. The main interaction model needs to be represented via unified behaviour which has to be documented and to provide customer with option to write his own connector and to supply it as the main interaction protocol
Voting engine (14 man-day):
Via this term we assume the component which is responsible to manage the PoS election process by safe and clear for the all participants way. It has to provide staking contract process execution, parent chain polling activity and eventually elect the next leader.
The main design consideration is the ability to switch voting strategy via so called voting templates.
Forks solving and security (14 man-day):
Here will be performed the most important part of the project. At that point we have to emphasize the points with:
a) Refactoring PoF for microforks
b) Implementing PoGF for generational forks
Hyperchain system tests (21 man-day)
At that stage the test network should be prepared. The environment has to reproduce both the “friendly” and “malicious” cases. This section will be described later on the appropriate chapter in details
