Status: Draft
Abstract
This proposal provides a possible solution to the problem of upgrade features to BTTC delivery.
Motivation
BTTC delivery uses PBFT consensus algorithm to produce blocks, which means any network upgrade must be completed at the same time for at least 2/3 of validator nodes, and such characteristic arises enormous challenges for subsequent on-chain feature upgrades.
One typical solution is applying new features at a certain block height, and it is standard practice for blockchain upgrade like Ethereum and other blockchains. However, such solution has some considerable drawbacks:
- First, this solution requires a long time to deploy, because at least 2/3 of validator nodes need to upgrade to new version. This will result in the network being in an unstable state for an extended period during the upgrade.
- Second, block height activation needs a clear deadline. If the scheduled activation height is reached, but the upgrade is still incomplete, the upgrade plan must be aborted to avoid fork.
- Third, upgrades need a quick response, but block height activation method may be too slow to react.
In order to alleviate the aforementioned issues, we propose to implement a mechanism based on a combination of PBFT consensus and feature proposal to resolve the problems presented by network upgrade processes in BTTC.
Rational
The key is to design a mechanism for controlling the activation and deactivation of features introduced through network upgrade. When the current network meets the requirements for a network upgrade to activate new features, it should on one hand make sure that at least 2/3 of validator nodes have reached consensus to support the new features, and on the other hand apply dynamic procedures to decide whether to enable these features.
There are currently two fundamental mechanisms in BTTC delivery can help to support solving the above problems accordingly:
sidechannel transactions
The sidechannel transactions aim to help nodes reach consensus. While normal transactions will be executed along within the process of one block, the sidechannel transactions’ execution is separated into three steps:
- Every validator can decide whether to upgrade individually based on its own judgement, upgrading means the validator node will support for the sidechannel transaction.
- Current block producer will collect all votes for this transaction from all validators and record such vote infos in the block header.
- When any node receives and executes a block, it will execute a sidechannel transaction if this transaction has collected more than 2/3 support votes from validators, otherwise, the transaction will be ignored.
Through the sidechannel machanism, the chain can dynamically execute this transaction based on current upgrade status. It can solve the problem of instability during network-wide node upgrade.
proposal mechanism
Proposal mechanism offers a dynamic approach to modify parameters on-chain. The workflow of the machanism can be segmented into the following three stages:
- Proposal Initiation Stage: A validator represents the community to initiate a proposal for an on-chain parameter change, and the proposal will enter voting period.
- Proposal Vote Stage: All validators can vote for any proposals in voting period by making a transaction, and the vote info will be recorded in chain.
- Proposal Tally Stage: When voting period for a proposal ends, based on the results of the proposal, the proposal will either be executed or abandoned accordingly.
The proposal mechanism is used to decide whether to apply modifications to the on-chain parameters. We can utilize this proposal mechanism to confirm changes to the activation status of relevant features on the blockchain.
Specifications
The above are the two key principles of the solution. The following is implementation scheme for the control mechanism for new network upgrade features proposed based on the above two principles:
- Design a storage to record all features’ activation status. A network upgrade feature should work based on the status of corresponding activation status.
- Desigin a type of transaction based on sidechannel machanism. This transaction aims to initiate a feature change proposal to the chain. If upgrade status of the whole network supports the feature, it will initiate a proposal for community voting successfully; otherwise, the transaction will be ignored.
- Modify the current proposal machanism to accept new proposal types to maintain the activation status of different features.
And the control machanism will work as the following steps:
- Developers add new features to the chain and the feature’s execution should depend on the status of their corresponding activation.
- Validators upgrade their nodes. Upgraded nodes will support new features and they will cast supporting votes for new features through sidechannel machanism.
- Validators initiate feature change proposals to trigger new feature activation. If the proposal collects enough supporting votes from validator nodes, it will be submitted to the chain successfully and open to community for voting.
- Validtors vote for new feature to activate new features. When a feature change proposal collect enough supporting votes in community, the parameters related with the feature will be changed.
- The status of activation for the network upgrade feature transfer from false to true when proposal is passed and related features will run without any issues impacting on-chain stability.
If you have any questions about this proposal, please feel free to comment and discuss.
Thank you.