CertiK Chain realizes the full potential of a secure blockchain infrastructure and defines blockchain security more formally and concretely. The Chain accelerates development of blockchain-related security technologies on all layers of software abstractions, including languages, compilers, virtual machines, chain logics, and OS platforms, as well as demonstrates their integrations into blockchain.
This article will serve as an overview of CertiK Chain’s unique security-focused dual-pass governance model. First, let’s begin by describing key players of the Chain.
The Chain has three types of participants when it comes to governance:
Overall, Stake Delegators represent the stake aspect of the chain, while Security Certifiers represent the security aspect of the chain. Validator Operators, by delegation and representation, represent the operational and financial aspects of the chain. The collection of all Security Certifiers forms the security council. In order to maintain checks and balances, Delegators are allowed to unseat Certifiers with a vast majority in worst-case scenarios.
The security council cannot make changes to the operational or financial aspects of the chain — proposals regarding those types of executions must be voted on by the Validator Operators, who represent Delegators. However, the security council is allowed to block any security-related proposals before they enter the stake voting stage.
Compared to other blockchains, Security Certifiers and security councils are unique new chain designs to address the tension between decentralization and chain security. To add (elect) or remove (unseat) Security Certifiers, it must be agreed upon by the security council, as well as the vast majority of Delegators and Validator Operators.
Both Stake Delegators and Security Certifiers can submit governance proposals. There are several types of proposals.
Plain Text Proposals do not require chain code modifications. They can be used to discuss and seek majority consensus on any topic related to chain operations and governance, e.g., initiating a bounty campaign, increasing the incentive reward ratio, etc. Submission of a plain text proposal is the prerequisite for a software upgrade proposal, which ensures the technical changes are desired and agreed upon with a majority of Delegators and Validator Operators.
Software Upgrade Proposals require chain code modifications, such as changing the range/scope of the chain parameters or adding new chain features. Once a related plain text proposal is approved, proposers are then qualified to submit a software upgrade proposal for security approval. If the software upgrade proposal is accepted by the security council, the chain software will then be upgraded to the new version as voted.
Bounty Proposals may include any chain contribution request, such as creation of chain artifacts, performing security verifications, construction of security proof, conducting security auditing, etc. The deposits for a bounty proposal are stored in a pool that can be claimed by contributors who complete the request. Once the proposal has been accepted by governance, contributors can submit a software upgrade proposal and claim the bounty.
A proposal can be submitted by all three types of participants: Stake Delegators, Validator Operators, and Security Certifiers.
For Stake Delegators, submitting a proposal requires a deposit. The proposal will be confirmed and enter the Voting Period once the minimum deposit is reached. For software upgrade proposals, proposers are required to submit a plain text proposal first to receive a majority consensus. This process will include two deposit transactions. The Proposal will enter into the Voting Period once the deposit conditions have been met; otherwise, the deposit will be refunded.
The deposit process allows Stake Delegators to gain more attention in order to get their proposals into the Voting Period. Security Certifiers and Validator Operators can skip the deposit period when submitting proposals, since they have already been entrusted by delegators during their delegation and election process.
There are two passes (hence the naming of the dual-pass governance model) of voting during the voting period, for functional and security considerations.
For functional considerations, only staked tokens can participate in the voting pass. The number of tokens staked determines the influence on the decision, i.e., voting power. Stake Delegators adopt the vote of the Validators they have chosen to delegate to, unless they decide to cast their own vote, which would overwrite the Validators’ voting choice. Security Certifiers do not vote during this process, since there are no code modifications included, hence no new chain security concerns.
For security considerations, Security Certifiers are responsible for evaluating whether the code matches its intention in security, correctness, and performance. In most cases, unanimous approval is needed for a proposal to pass the security council. In the very limited cases where the vote needs to be done by majority, each Certifier has the same voting power — in the case of a 50/50 split, the Certifier elected earliest is the tie-breaker. If the proposal passes security considerations, Stake Delegators and Validator Operators then vote based on code functionality considerations as mentioned previously.
There are four stake voting options:
There are two security voting options:
If the passed proposal is a software upgrade proposal, then nodes need to upgrade their software to the new version that was voted. This process is divided in two steps, through a signal and switch.
In the signal step, Validator Operators are expected to download and install the new version of the software while continuing to run the previous version. Once a validator node has been installed with the upgrade, it will start signaling to the network that it is ready to switch over.
There is only one signal at any time. If several software upgrade proposals are accepted in a short time frame, a pipeline will form and they will be implemented one after the another in the order they were accepted.
In the switch step, once a majority of validator nodes are signaling for a common software upgrade proposal, all the nodes (including validator nodes, non-validator nodes, and light nodes) are expected to switch to the new version of the software simultaneously.
Governance for dPoS chains is challenging due to the limited decentralization of super nodes. By adding security stakeholders into the governance model and separating functional and security considerations, the result is practical, balanced, and extensible governance.
Together with other unique security designs and technologies, CertiK Chain creates the security groundwork for a safer blockchain ecosystem. With security as the key design focus, every chain layer or component prioritizes trust and security, such that true decentralization and scalability can be meaningfully achieved while allowing developers to rely on better chain security.
To stay updated with future releases, sign up for the CertiK Foundation Newsletter.
.png)