Introduction
Following the approval of KGP-4, which proposes changing the Kaia network to be permissionless, the Kaia team wants to share the stepwise phases for implementation.
Many components of the Kaia network are currently implemented with the assumption of a permissioned environment. To transition toward a permissionless model, we plan to redesign these structures gradually. In this post, we aim to provide a stepwise overview of smart contracts for permissionless and outline the key changes that will follow. Please note that those changes are not finalized and can be updated.
Permissionless
To maintain Kaia’s high performance while transitioning to a permissionless model, we are conducting extensive research and development. Since many components of the network have historically been built under a permissioned assumption, replacing them all at once would require disruptive changes to both the system and the ecosystem. Therefore, we are pursuing a phased approach to achieving full permissionlessness.
In the first phase, the focus will be on opening registration and on managing validator information. At present, all validator information on the Kaia network is managed within the AddressBook (AB) and the SimpleBlsRegistry (SBR) contract. The Kaia team currently administers both contracts on behalf of the validator, and this process will be opened up during this phase. Please note that Phase 1 will not provide a fully permissionless network, but is a stepwise phase towards becoming permissionless. The overall onboarding/offboarding process will be maintained, while opening more authority to validators.
Subsequent phases will bring true permissionless and automated operations to the network. Under defined rules, validators will be automatically promoted or demoted. New validators will be required to pass a performance assessment system before onboarding, and continuous performance monitoring will ensure that Kaia achieves both permissionlessness and high network performance.
Let’s now take a closer look at the key changes that will take place in each phase.
Permissionless: Phase 1
As mentioned earlier, Phase 1 focuses on self-registration of validator information. The authority to manage validator-related data will be granted to the validators themselves. To achieve this without directly modifying the existing AddressBook (AB) and SimpleBlsRegistry (SBR), the Kaia team plans to introduce a new contract called the Validator Management Contract (VMC), which implements the KIP-277: Self Validator Registration. The VMC can be deprecated at later phases, as there’ll be direct changes to AB and SBR.
Validator Management Contract: VMC
Under this design, the VMC will hold the ownership for AB and SBR. Validators will be able to register and update their own information directly via VMC, while operational functions will continue to be handled by the Kaia team. To manage the authority for validator information, each validator will need a new account, referred to as the validator node manager.
| Task | Current | Phase 1 | Future phases |
|---|---|---|---|
| Validator information submission | Validator, Kaia | Validator | Validator |
| Validator information verification | Validator, Kaia | Validator | Validator |
| Validator information smart contract (un)registration | Kaia | Validator, Kaia | Validator |
| Consensus node network (un)registration | Kaia | Kaia | Autonomous system |
The validator information includes data used to participate in the Kaia network, including node ID, BLS key, and staking and governance-related information.
Validator Management Tools
Along with the introduction of the VMC, we will also provide a new tool to interact with it. Although the detailed implementation of this tool has not yet been determined, it will be designed with clear guidance to provide a smooth transition for validators into Phase 1. In addition, starting with this, we plan to ensure compatibility with the features that validators will use in the permissionless, making the phased transition to permissionless more seamless and practical. More detailed information will be shared once the specifications are finalized.
Permissionless: Future phases
The VMC contract cannot achieve a permissionless network on its own. The Kaia team will introduce more updates to transition the network to a fully permissionless one. New candidates wishing to join the Kaia network must pass an automated node performance test, and validators will undergo continuous performance monitoring. Based on these evaluations, validators may be automatically removed from the active validator set if their node performance does not meet the required standards. To implement future phases, we need additional modifications to the existing system, including AddressBook, SimpleBlsRegistry, and staking contracts. Let’s take a look at the expected changes.
AddressBookV2
The existing AddressBook contract has been in use since the Klaytn genesis and assumes a permissioned entity; therefore, we can’t continue using it. In addition, as the network has improved, multiple components such as StakingTracker, Voter address, and SimpleBlsRegistry have been introduced and managed separately. To reduce operational complexity, these will be consolidated under the new AddressBookV2.
It is worth noting that the AddressBook is not only used for validator management but is also widely relied upon by various ecosystem applications and users. Therefore, following the transition, the existing AddressBook will continue to be managed with the same reliability, and sufficient time will be provided to ensure that existing users can adapt smoothly.
Unified validator management
The AddressBookV2 is expected to provide the unified interface for validator management as follows.
| Data storage | Current | Future phases |
|---|---|---|
| Validator Manager Address | N.A. (Does not exist) | AddressBookV2 |
| Validator information | AddressBook, SimpleBlsRegistry, CnStakingContract | AddressBookV2 |
| Consensus Liquidity | CLRegistry | CLRegistryV2 |
| (TBD) KNI | DevOps | AddressBookV2 |
| (TBD) Metadata | Kaia Square, DevOps | AddressBookV2 |
The changes to the AddressBook and data management are expected to affect several other contracts that interact with it. Currently, we have identified the following contracts that need to be updated:
- CnStakingContract (→ CnStakingContractV4)
- StakingTrackerV2 (→ StakingTrackerV3)
- CLRegistry (→ CLRegistryV2)
The scope of the affected contracts may be adjusted during the development process.
Upgradeability
During the permissionless transition, the Kaia team can introduce additional features, which are likely to necessitate modifications to AddressBookV2. However, introducing yet another transition to an AddressBookV3 would place an excessive burden on the system.
Based on this, the Kaia team plans to implement AddressBookV2 as an upgradeable contract. The Kaia team is aware of potential concerns about upgradeability and will provide an appropriate solution once a decision is made.
CnStakingV4
For a complete permissionless system, it’s essential to establish appropriate penalty rules for validators. For example, without a proper penalty, a malicious node can degrade our node’s performance or attack our network, unrestricted by permissionless entry mechanisms. The most straightforward way to penalize a validator for malicious behavior is through staking-related restrictions, such as additional lockup or slashing. If it’s decided to implement staking-related penalties, it’ll be mandatory to deprecate existing CnStakingContractV2 and V3 and migrate to a new CnStakingContractV4. With the same rationale as AddressBookV2, the CnStakingV4 can also be an upgradeable contract.
Validator performance measurement system
As a high-performance blockchain, it’s essential to assess the node’s performance before it joins the network. To achieve this, we’re designing a validator performance measurement system that determines the promotion/demotion of validators without centralized control. The more detailed design and technical specifications will be shared in due course through the relevant KIPs.
Conclusion
Although permissionless Phase 1 does not involve significant technical changes, it focuses on areas well-suited for gradual permissionless introduction, especially since both the Kaia team and validators are still adapting to this new system. This phase will serve as an essential step in reinforcing the team’s direction toward permissionlessness and helping validators smoothly adjust to the upcoming changes. In the subsequent phases, more technical changes are expected. Both validator operations and network management will be carried out automatically in accordance with clear standards, minimizing the need for intervention by any centralized entity.
As this is the first introduction to our permissionless technical roadmap, we would greatly value your feedback and input. We sincerely welcome any questions or comments you may have on this matter.