kaiax: Add module framework and dummy noop module

[blukat29]

Proposed changes

• Define "kaiax modules" similar to "x/modules" of Cosmos SDK. See kaiax/interface.go for the design.
• Add NoopModule as a template.
• A JsonRpcModule can be injected into the CN to expose its APIs
• A ConsensusModule can be injected into a ConsensusModuleHost; currently the only host is the Istanbul backend.
• An ExecutionModule can be injected into an ExecutionModuleHost; where the only host is BlockChain.
• A RewindableModule can be injected into an RewindableModuleHost; where the only host is BlockChain.
• TxProcessModule and TxPoolModule are left as future work.

Types of changes

Please put an x in the boxes related to your change.

• [ ] Bugfix
• [ ] New feature or enhancement
• [ ] Others

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

• [ ] I have read the CONTRIBUTING GUIDELINES doc
• [ ] I have read the CLA and signed by comment I have read the CLA Document and I hereby sign the CLA in first time contribute
• [ ] Lint and unit tests pass locally with my changes ($ make test)
• [ ] I have added tests that prove my fix is effective or that my feature works
• [ ] I have added necessary documentation (if appropriate)
• [ ] Any dependent changes have been merged and published in downstream modules

Related issues

• Please leave the issue numbers or links related to this PR here.

Further comments

If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc...

[hyunsooda]

Seems like a good starting point. Here is a suggestion for the prototype structure. Maybe you already thought about this.

VerifyHeader() in the ConsensusModule is complex and strongly coupled with the governance handler, particularly regarding snapshots. Introducing a separate GovernanceModule could provide an opportunity to refactor and reduce this complexity by decoupling these responsibilities.

[blukat29]

@hyunsooda Exactly. That's what I am going to do next.

I imagine these modules can exist. The modules can refer each other via Init()

• Staking: Keeps track of validator staking status.
  • JsonRpcModule: kaia_getStakingInfo
  • Getters: GetStakingInfoFor(num)
• Gov: Keeps track of governance parameters. Send governance messages via special block header fields.
  • JsonRpcModule: kaia_getParams, et al.
  • ConsensusModule: Verify gov-related header fields. Attach gov-related fields such as voteData.
  • ExecutionModule: After inserting a block, calculate ParamSet for the next block and persist.
  • Getters: GetParamsFor(num), GetValidatorUpdates(num)
• Validator: Keeps track of validator set changes.
  • JsonRpcModule: kaia_council, et al.
  • ExecutionModule: After inserting a block, calculate ValSet for the next block and optionally persist.
  • Getters: GetValSetFor(num)
• Reward: Calculate deferred- and non-deferred- rewards and reflect them to world states.
  • JsonRpcModule: kaia_getRewards, et al.
  • ConsensusModule: Apply deferred per-block reward.
  • TxProcessModule: Apply non-deferred per-tx reward.
  • Getters: GetDeferredRewardsFor(block), GetRewardsFor(block)

[blukat29]

@hyunsooda Exactly! the module functions are indeed event handlers at various stages in block processing. A Kaia core functionality can be formulated as 'a set of customizations to the Ethereum block processing pipeline'. I just did not name them like OnBlockInsert. Tell me if you have any naming suggestions.