We are currently about 4 months out from our spork control expiring. This is effectively a master key for us to disable Lelantus should we notice any suspicious activity. The original proposal was to have it for 1 year. I recommend reading that thread as well.
I have no issues to have it expire. However there’s one niggling piece that’s bugging me and that’s relating to a security proof in Lelantus’ balance security.
Security proofs in cryptography are basically mathematical proofs that prove the security of a particular component. The lack of a proof doesn’t mean that the system is insecure and it may be practically secure; however there is no guarantee that it is.
Due to the way Lelantus v1 combines certain elements together for efficiency, proving one part of its security (namely balance security) is challenging. We had an existing security proof and another way to write the proof which addressed some concerns, but it didn’t prove it sufficiently and it’s unclear what’s the best way to proceed with this. Again this doesn’t mean that a flaw exists, just we can’t prove its security either.
This was also a reason why we also embarked on research with Lelantus Spark that separates these elements, making it much easier to prove security and doesn’t inherit the same problems with Lelantus v1.
Given the potential issues, we need to decide how we should handle this risk as to whether we should let it expire and set a good precedent as to not extending control or to get community approval to extend it as we move to Spark.
Transitioning from Lelantus to Lelantus Spark
This also has implications as to the transition from Lelantus to Lelantus Spark. There are two main ways we can transition from Lelantus to Lelantus Spark.
Lelantus > Transparent > Lelantus Spark
This was how Zcash did it and it has benefits in having a possible checkpoint on supply since amounts need to be revealed. They call this a turnstile. This hardly needs any special code to handle. However, it has deanonymization risks since amounts are revealed. It is much more likely to detect whether a flaw was found in Lelantus though not guaranteed if the attacker doesn’t drain the entire pool.
However all the anonymity sets we built up in Lelantus would need to be rebuilt again.
Lelantus > Lelantus Spark
This allows migration directly from Lelantus Mints into Lelantus Spark system. This preserves existing anonymity sets and there are much less deanonymization risks. A special transaction to do this would need to be created but it’s relatively simple still to do so.
However if there are any flaws in original Lelantus, this inflation can be carried over into Spark and would be hard to detect.
So the decisions are as follows
- Should we extend emergency switch functionality and if so how long? Should it be until Spark is activated?
- Should we have an emergency switch for Spark again with limited duration?
- How should we do the transition? A turnstile migration or direct from Lelantus to Lelantus Spark?