- Yes to spork control temporarily with a 1 year validity
- No, we should not sacrifice decentralization
Should we give core team temporary ability to turn off and on features like Lelantus, chainlocks and instant send? Proposed one year period from activation of feature.
Sporks allow for the developers to turn off and on certain features of the chain. They are a point of centralization but they also act as ‘emergency brakes’ where things like Lelantus or chainlocks can be turned off. How this works is meaning the core team can issue a special command on the chain that will signal the rest to turn off certain features such as Lelantus.
When we first enabled Znodes, we were quite adamant about not having these controls held by the team as we didn’t want it to be centralized. However, after experiencing numerous challenges while deploying new tech, we think it may be prudent to introduce a temporary safety switch until the protocol matures.
Chainlocks protect the chain against 51% attacks and also prevents re-organizations past one block. This in normal circumstances is very beneficial but it also makes it extremely hard to stop an attack quickly.
This is because while attacks with PoW can be mitigated by just coordinating with the majority of the pools, chainlocks means if we were to deploy any emergency fixes, they need to be done by both pools and Znodes which is impractical
Similarly while Lelantus is still new, while we have undergone audits, it might be beneficial to have a safety lock for a period of time so that we can address issues immediately.
Having a temporary disable of instant send (when implemented) would also be beneficial in the face of attacks.
We can set for this ‘master key’ to automatically expire after a period of one year from the time of activation.
This feature will add about 2 weeks on development time and testing but given the cutting edge nature of the tech, it may be prudent to have some temporary emergency measures especially given the recent scare.