The Incognito network must eventually operate autonomously. One of the most important milestones is the release of fixed shard nodes, and a lot of work is being done in this department to ensure we can do so as soon as possible, as safely as possible.
Since we are all eager for this milestone to be completed, here is some contextual information on what is being done behind the scenes. We’d also like to invite you to share your opinions and expectations so we can work together towards this event.
Challenges
Here are the 2 main challenges we need to address prior to the release:
1. Security
a. Malicious proposer: validators might not be able to verify that proposed blocks (and their txs) are malicious, due to a lack of validation code.
b. Validator collusion: validators and a proposer collude to agree on a malicious block containing double spending or illegal minting txs.
2. Network stability
a. Blocks would not be created if the majority of nodes in the network are not functional because of connection issues, power outage, etc.
Solutions
1. Security:
The core dev team’s foremost priority is safety of user funds. Both internal and external code audits are submitted regularly to mitigate problem 1.a.
Problem 1.b is a bit trickier. If the validation code in 1.a is invalid because validators accept proposed blocks without any validation, another party is needed to re-verify these blocks and take action as soon as possible to prevent attackers from removing assets from Incognito.
Specifically, beacon nodes will re-verify all blocks sent by a shard, and if there are any invalid transactions detected in a block, the network will either be paused for a post mortem (the most practical thing we can do currently), or the malicious block will be rejected, and the shard’s committee swapped out.
2. Network stability:
Work currently being done on Dynamic Committee Size (DCS) is directed towards ensuring network stability in multiple eventualities. An essential feature of DCS is Slashing, which will force dysfunctional nodes that are not contributing to consensus to unstake. Slashing will be released on mainnet around Feb 2021, and the core dev team will endeavor to provide advance support in the form of notifications, dedicated validator support groups and so on to ensure the transition is as smooth as possible for honest validators. We hope that after slashing has run for a couple of months, the network will consist of only “healthy” nodes.
The clue is in the name – another integral part of DCS is making the committee size dynamic based on the number of substitutes in the shard pool. For more details regarding terminologies and mechanisms, please have a look at this document and feel free to leave your comments. This is aimed at making the network more fault tolerant. The tentative release date is June 2021.
The plan
This is the current plan of action:
-
The network will be released in stages to ensure continued stability. For example, keeping 6 proposers to propose blocks in a round-robin fashion and releasing 16 validators to the community. This will only happen if the DCS runs stably for a period of time, say 1-2 months (August 2021). By being cautious in this way, we minimize the likelihood of security issues, and will have more time to ensure the system is airtight.
-
Once we feel confident in the security of the network, we will release all shard proposers to the community. The core team will keep just the beacon nodes in the meantime, for security reasons stated in the sections above. We also hope to release these at a future date.
We hope this gives you a little clarity on the work being done towards decentralization and full autonomy. Releasing the network in a stable and secure way is a shared goal – many of you contribute to the network in some way by taking on the roles of validator, provider, user, or community member.
So please share your thoughts. Do you have any questions, or ideas on how to ease this transition? We’re excited to work towards this huge milestone with you.