Should we enable spork functionality temporarily until Lelantus matures?

[reuben]

• Yes to spork control temporarily with a 1 year validity
• No, we should not sacrifice decentralization

TLDR:
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.

Longer explanation

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.

[jleony]

It makes total sense to have this enable during initial Lelantus period. It is more likes a threat mitigation feature for possible safety issue. Having the master key to auto expire after one year is great. Happy with this proposal, and again it proves that Zcoin team is always think ahead and plan properly.

[Muggles]

I’m all for enabling spork functionality (that expires after a year.) Realistically, being on the cutting edge means that mistakes happen, and when dealing with peoples money you can’t be too safe.

[nolonger]

it will be good if we enable the spork function first before the Lelantus matures, and it let zcoin team to react if something serious happen. Coding and blockchain are so invulnerable, and i always believe in zcoin team on how they handle the problems honesty and transparency.

[Bigpiggy01]

There really is no point in not doing so. Risk mitigation is the name of the game.
Pushing out real innovation and having the balls to stand by it is not a suicide pact, mitigating the potential risks of at least a transition period makes perfect sense.

[Kenshin]

Absolutely 100% for spork control while Lelantus is being proven. This will protect Zcoin holders and the project long term until the core technology matures by giving the core team the capability to block the exits during an exploit. Hence minimizing any inflation damage.

As mentioned, combined with upcoming Chainlocks, something like this is even more necessary.

And it can be reversed when there’s sufficient confidence in the system at a later date. Great idea, makes a lot of sense.

[devwarrior]

Even as a long time believer in the sanctity of decentralization I here agree that - on balance - this is the right thing to do. There will be attacks for sure and Zcoin’s reputation will absolutely suffer if many get burned.
Yes, do it!!!

[Kenshin]

I had a couple more thoughts…

…I’d recommend removing the visible 1 year timeline for it, or have the option to extend since: If I’m a hacker exploiting Zcoin code, I could potentially sit on that exploit to 0-day it once the spork master key deactivates. Using that time to automate the whole exploit process for maximum impact. I say this because we are talking about a potentially small number of people who will be able to find the right vulnerability (and I’m sure it will happen at some point)… I have in mind something like this could be kind of like the exploits on console hardware that are sat on for years the right moment before they’re taken advantage of. Perhaps, extend/renew the key until it meets some secret criteria the team sets where it’s no longer needed imo.

Another way I could see this working is if sporks are activated normally every major patch (after 1 year) for a specific amount of time. That way as upgrades and features for new development are introduced, it gives a period of time for a kind of “hotfix” control capability.

Depending on Dash core code complexity and customization the zcoin team does, it will need historical audit of any attack vectors & testing to ensure it can’t be exploited itself as well… but I’m sure ya’ll are ontop of that.

[reuben]

Yes I was thinking of this as well but don’t know about the whole ‘secret criteria’. But note that the moment we remove it (secret or not), the attacker can always do it anyway so I’m not sure whether having a fixed date or no fixed date really helps in the long run.

Ideally if price permits, we can have more comprehensive audits in the meantime.

[JCTheMiner]

I like this idea. Deploying new features come with risks so having a backup plan to protect the network in the event of the unforeseen is a good idea.

Perhaps as a compromise towards decentralization you could add the option to turn off this feature to leave the possibility for consensus to deactivate it.

How to deal with the scenario where the key somehow falls into the wrong hands before it expires? Is it possible that deactivating a feature could cause an even bigger problem, especially if there is an unforeseen bug and how could that be dealt with?

[reuben]

Well considering that the dev reward address is also a key, I think we should be okay.

The only thing I can that won’t be good is using it to deactivate the chainlocks to mount at 51% attack but that wouldn’t be different than the current situation imo.

One of the thing is if we leave it to pools, that won’t be enough as Znodes would need to do it too esp if chainlocks is activated.

[TylerX]

Seems like a topic of great importance, I wish I could provide anything more than. Keep up the great work…I trust your expertise.

[matthew.niemerg]

If there is a way to allow for governance beyond just the core team handling the activation / deactivation of various features, that may be nice to have as well, especially if this is needed long term!

[KFC]

this! i fully agree and think it is necessary for the future of Zcoin

[Savil]

Just as a plane have multiple engines to work with, having sporks as a safety measure makes sense. The real test and battle field post audits is the real world. Being able to act quickly within the first year of Lelantus would be key. I support spork. The team constantly shows how capable they are.

[SUPdood]

Why not just run a parallel testnet?

[reuben]

Testnets are always run but hackers don’t hack testnets.

[reuben]

Sure, I think that’s a great idea. I actually posted something here but reception hasn’t been great so far https://forum.zcoin.io/t/burning-zcoins-for-governance/809/18

[anwar]

While I strongly dislike the idea of a kill switch and centralisation, past events has shown the necessity of it.

I am for the spork functionality.