Collect a fee (decreasing to 0 over time) which is used to subsidize a prediction-market over the networks cryptographic security.
Every zk project released to date (familiar to me) has had a critical security vulnerability (Tornado Cash, Zcash, Aztec, to name a few).
Security is hard, therefore I expect most empires to fall.
Market settlement is done centrally (pick your poison), but can be challenged (with sufficient capital) into an open L1 validator vote.
This (anti-)upgrade mechanism is designed to make security trade-offs of migrations legible to users.
Hello @Anon unfortunately I don’t really understand what’s being suggested here and it doesn’t match the submission format. Would you be able to further elaborate so that we can accurately compare the proposal to others?
This proposal extends social-consensus with a prediction market.
Migrations are not only manual for users, but come with an increased fee (small). This fee is used to inform the network of smart-contract-risk in an objective manner.
Upgrades of cryptographic primitives come with extreme risks. I bet that most long-term upgrade proposals eventually fall prey to a critical security vulnerability.
Therefore upgrades should be avoided in favor of ossification.
Thanks for the updates! Helpful to know that it extends the non-governance/social consensus proposal. Could I ask you what makes you say this, and what you would do in the event of a bug in some of the “cryptographic primitives” as you put it?
Surely one of the reasons you want a well defined governance mechanism is to be able to easily step in and release new software is to fix vulnerabilities, ideally as fast as possible. For example, Vitalik’s proposed milestones for rollups taking off their training wheels thinks carefully about this and proposes a digestible framework for evaluation. In a non-governance world, and seemingly this proposal, there are no training wheels (we would speed run to a “stage 3” rollup, beyond the milestones Vitalik outlined) and therefore if an issue arises everyone’s funds could theoretically be stuck permanently. That may not be exactly what you have in mind, but candidly due to the lack of details in your proposal it’s unclear what happens.
Let me rephrase. ZK-SNARK and smart-contract technology are similar in stringent-mathy ways to other work in cryptography. I have observed in the world a general failure to produce secure stringent-mathy-things at a high rate.
Therefore, my base-rate for mistakes is high, and the risk of surreptitious backdoors (e.g. Dual_EC_DRBG, Tornado Cash) is also high, given the complexity of the underlying software and large economic incentives.
Surely one of the reasons you want a well defined governance mechanism is to be able to easily step in and release new software is to fix vulnerabilities, ideally as fast as possible
I expect near-instant loss of all assets. Additionally, the ability to quickly update software is itself a risk.
I consider training wheels opposed by “The next version of Aztec will be launched as a fully decentralized network” [1].
I do not oppose a decentralize-over-time approach (<1yr).
A public testnet, and transparency about mainnet risks, seem like a reasonable alternative.
Your point about chain-halting-risk is good. I propose Exxit.