# \[Upgrade Proposal (Concept Only)\] Beskar Council: A Temporary Emergency Pause-Only Multi-Sig **URL:** \ **Category:** Aztec\ **Tags:** rfp, upgrades\ **Created:** [August 6, 2023, 6:58pm UTC](https://forum.aztec.network/t/upgrade-proposal-concept-only-beskar-council-a-temporary-emergency-pause-only-multi-sig/720 "2023-08-06T18:58:56Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![KevinLomax](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.aztec.network/kevinlomax/32/367_2.png) [@KevinLomax](https://forum.aztec.network/u/KevinLomax)\ **Post date:** [August 6, 2023, 6:58pm UTC](https://forum.aztec.network/t/upgrade-proposal-concept-only-beskar-council-a-temporary-emergency-pause-only-multi-sig/720/1 "2023-08-06T18:58:56Z")
**CONCEPT PROPOSAL, FOR DISCUSSION PURPOSES ONLY - DOES NOT CONTAIN ALL TECHNICAL DETAILS** - **Summary** - **Comparisons** Here is a high level overview of the judicial order risk [^1] associated with certain upgrade mechanism models: | **Certain Upgrade Mechanisms** | **Description** | **Other Similar Projects** | **Judicial Order Risk / Consequence** [^2] | | --- | --- | --- | --- | | Social Consensus | See [Non-governance](http://forum.aztec.network/t/upgrade-proposal-non-govnernance-via-social-consensus/611) | Bitcoin / Ethereum 1.0 | 🟢 Low 🟢 | | Staker Based Consensus | See [Empire Strikes Back](http://forum.aztec.network/t/upgrade-proposal-the-empire-stakes-back/626) | Ethereum 2.0 | 🟢 Low 🟢 (assuming Staking is not concentrated among a limited set of easily identifiable Stakers and Staker set continues to grow) | | Staker Based Consensus + Pause Only Multi-Sig (Transparent) | See [Empire Strikes Back](http://forum.aztec.network/t/upgrade-proposal-the-empire-stakes-back/626) + this concept proposal | N/A [^3] | 🟢 Low/Medium 🟠 - a court order may force members of the Security Council to pause the network. However, the Stakers could remove the Security Council and ensure the network remains functional, live and censorship resistant, making any judicial requirement to pause the network inconsequential. A potentially greater risk here is that members of the Security Council / Foundation could be forced to reveal identities of the genesis Stakers (see below - genesis Stakers would participate in the selection / nomination of the Security Council members), which may lead to court action against the genesis Stakers, although this could be mitigated by ensuring a geographically / jurisdictionally diverse and growing set of Stakers (over and above the genesis Stakers) is joining the network on a permissionless basis. | | Multi-Sig (Anonymous) | Upgrades conducted via an anonymous mult-sig | Optimism | 🟠 Medium / High 🔴 - a court order may force the Security Council members to take an action, provided they are identified, impacting the whole network. | | Multi-Sig (Transparent) | Emergency upgrades conducted via a transparent multi-sig | Arbitrum | 🔴 High 🔴 - a court may force council members to take all necessary steps to take an action, impacting the whole network. | | Senate (Transparent) | See [The Republic](http://forum.aztec.network/t/the-republic-a-flexible-optional-governance-proposal-with-self-governed-portals/609) | N/A but similar to Uniswap | 🔴 High 🔴 - a court order may force Senators to take an action, impacting the whole network. However, a mitigating factor for the users is that the Senate cannot force an upgrade instantly, users can exit the network. Notwithstanding the consequence for the network itself remains high. | - **Details** - **Pros** - **Cons** - **Questions and Other Concerns** 1. Who should be a member of the Security Council and how can we ensure a quick reaction to vulnerabilities (covering all time zones), who is trustworthy and who will act in the best interest of the network and not just the Stakers? 2. Does a pause-only Security Council provide sufficient comfort to prevent bugs / vulnerabilities from being exploited? 3. What exact pause functions should the Security Council have? 4. How do we limit the potential for Security Council members to identify Stakers? 5. Would anonymising the Security Council (which would further limit judicial order risk) outweigh the benefits of a transparent Security Council (which provides comfort that Security Council members are accountable)? 6. Is 12 months a sufficiently long enough time for the Security Council to exist or is it too short? Are there any other ways to look at this? 7. Are there any additional (conceptual) modifications that could be made to this proposal which would alleviate the key risk of having Stakers collude in a pause situation which could lead to a total loss of funds for users, without any ability to exit? Do we have to rely on the benevolence of Stakers at this point? 8. Is the increase of the activation threshold (once Rollup Contract is paused by the Security Council) from 51% to 75% too high and would cause the Rollup to be stuck in a paused state? 9. Are there any technical challenges that would not be capable of being overcome to implement this? **[^1]:** Note this concept proposal and table focuses only on judicial order risk (a particularly pertinent risk given recent developments (see footnote below)) and does not cover other risks, including other legal risks, such as sanctions and securities law risks. **[^2]:** See [Oasis Judicial Order](https://blog.oasis.app/statement-regarding-the-transactions-from-the-oasis-multisig-on-21st-feb-2023/) and [Nomad Bridge Class Action](https://www.classaction.org/news/nomad-crypto-bridge-class-action-says-simple-programmer-mistake-allowed-186m-hack-in-2022); multi-sigs carry significant “legal” / judicial order risk. For example, Oasis received an order from the High Court of England and Wales to take all necessary steps that would result in the retrieval of certain assets involved with a specific wallet address. The specific legal risk here is the ability of a court to force security council members to take a specific action as directed by the court; halt the network or return certain funds to person X. **[^3]:** However, see [Compound Pause Guardian](https://docs.compound.finance/v2/governance/#pause-guardian) multi-sig. ---
**Author:** ![LasseAztec](https://avatars.discourse-cdn.com/v4/letter/l/90db22/32.png) [@LasseAztec](https://forum.aztec.network/u/LasseAztec)\ **Post date:** [August 8, 2023, 7:50am UTC](https://forum.aztec.network/t/upgrade-proposal-concept-only-beskar-council-a-temporary-emergency-pause-only-multi-sig/720/2 "2023-08-08T07:50:57Z")
Hi @KevinLomax, thanks for putting a proposal forward. Adding some questions and comments below. > _“If the Security Council pauses the network as a result of discovering a critical bug/vulnerabilty, this would enable the Stakers to upgrade the network to resolve the vulnerability, without any delay limitations”_ When it is possible to upgrade quicker than staker governance in case of `unforeseen engineering / cryptographic bugs`, how to you distinguish between a bug and malicious use of the pause function? Because upgrades can be made without delay if coordinated between stakers and the beskar council, how do you see staking services such as Lido impact the risks of the system? Possibly two parties that can be pressured to force an inescapable upgrade. **For the table:** - I disagree that Ethereum PoS is “Staker Based Token Voting”. Stakers are unable to take your state just because they want to. The “real” Ethereum is decided socially - _not_ by stakers. - How are the consequences less for optimism than arbitrum? If action is taken the impact are similar. - For the Senate, I don’t see how the consequences are same as arbitrum and optimism. It might be as easy to find the senators as arbitrum signers, but they hold less power. They cannot force an upgrade instantly so the consequences can be much less since there will be time to exit. So the consequences are only the same if all users ignore the world throughout the delay. > _“the normal 750/1000 blocks for a new rollup is ignored”_ - How is voting done then? Voting period, how to cast votes etc? - If you no longer have to vote over a significant period and there are no execution of rollups (so you can’t be slashed) seems more likely that someone will start borrowing stake to vote in their own best interest. - If voting happens until enough have voted to upgrade, that might never happen - An example of this is that the council can effectively freeze the rollup forever for 25% of the stake. Seems like easy way to blackmail, “accept my change where I take some of your funds, or lose all of your funds”. > _“If 75% of the stake has manually moved from implementation A (old Rollup Contract) to B (new Rollup Contract), implementation B will become canonical.”_ If the unpause is done through an upgrade from A to B, A will be paused forever. Any ungovernable portal will practically be bricked, I don’t see that any from the group that would use ungovernable portals actually use them if a multi-sig can brick it on command. > _“The Security Council members could be changed (for example because they were not sufficiently reactive to a fire drill), or the Security Council could be removed in its entirety, by AZIP proposals / Stakers at any time.”_ This seems like something that would require on-chain voting, do you have thoughts on quorum and such for that kind of proposals? > _“The Security Council would be able to quickly respond to network vulnerabilities and pause the Rollup Contract quickly, to mitigate any critical vulnerabilities / risks.”_ What does this statement build on? Do we have examples of large multisigs that have reacted in a timely manner to vulnerabilities (they must exists, but I don’t have one at the top of my head)? * * * Overall, I think that the introduction of a pause that is active until an upgrade gives the upgrading party (stakers, multisig or benevolent dictator alike) the power to perform instant upgrades which frightens me. Training wheels that can be used to steal funds without a “counter” don’t float well with me. ---
**Author:** ![KevinLomax](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.aztec.network/kevinlomax/32/367_2.png) [@KevinLomax](https://forum.aztec.network/u/KevinLomax)\ **Post date:** [August 14, 2023, 11:47am UTC](https://forum.aztec.network/t/upgrade-proposal-concept-only-beskar-council-a-temporary-emergency-pause-only-multi-sig/720/4 "2023-08-14T11:47:21Z")
Thank you @LasseAztec for taking the time to reply, may the raven flanked god Odin shine upon you with his thunder and Freyja ride you in her chariot. The Aztec project you are working on would benefit from your Thor hammer, which you should apply to all other proposals as well. You must make sure no upgrade mechanism ships to war without being hammer tested. No mercy please - the world’s freedom is at stake. > 1. When it is possible to upgrade quicker than staker governance in case of `unforeseen engineering / cryptographic bugs` , how to you distinguish between a bug and malicious use of the pause function? Because upgrades can be made without delay if coordinated between stakers and the beskar council, how do you see staking services such as Lido impact the risks of the system? Possibly two parties that can be pressured to force an inescapable upgrade. Agreed that this is a risk, which is attempted to be limited (but not eliminated) by: (i) Security Council being transparent (cf Optimism) and individuals would be held accountable for initiating the pause functionality, (ii) upgrades conducted by infrastructure providers (Stakers) and not by Security Council; and (iii) increased 75% (from 51%) Rollup Contract activation threshold during pause period for upgrades (which would have to be processed by Stakers) would limit (but not eliminate) risk of malicious behaviour by Stakers. > 1. I disagree that Ethereum PoS is “Staker Based Token Voting”. Stakers are unable to take your state just because they want to. The “real” Ethereum is decided socially - _not_ by stakers. Agreed that Ethereum PoS does not track the Empire Stakes Back governance 1 to 1 on this (and the Empire Stakes Back proposal also acknowledges this) and also the nomenclature used can be updated - I have updated the proposal to reflect this. > 1. How are the consequences less for optimism than arbitrum? If action is taken the impact are similar. Fully agreed that consequences will be the same as for Optimism; given the multi-sig is anonymous for Optimism the likelihood of any action taken against the multi-sig is slightly less likely to occur in comparison to Arbitrum’s transparent multi-sig. I have clarified this in the above table, thanks for flagging. > 1. For the Senate, I don’t see how the consequences are same as arbitrum and optimism. It might be as easy to find the senators as arbitrum signers, but they hold less power. They cannot force an upgrade instantly so the consequences can be much less since there will be time to exit. So the consequences are only the same if all users ignore the world throughout the delay. Thanks for flagging this - I think the ultimate consequences for Aztec, the L2, will be the same as Arbitrum / Optimism (could be shut down) but for the users, you’re right, given the time for exit, this will better. This nuance has been updated in the table. > 1. \*How is voting done then? Voting period, how to cast votes etc? If you no longer have to vote over a significant period and there are no execution of rollups (so you can’t be slashed) seems more likely that someone will start borrowing stake to vote in their own best interest. If voting happens until enough have voted to upgrade, that might never happen. An example of this is that the council can effectively freeze the rollup forever for 25% of the stake. Seems like easy way to blackmail, “accept my change where I take some of your funds, or lose all of your funds”. This concept proposal relies on the staking and social consensus proposed in Empire Stakes Back to correctly align incentives and help facilitate network upgrades. Nomenclature has been updated to avoid misunderstandings. Fully agreed that there is a risk that a 25% stake can effectively freeze the rollup forever once the Security Council initiates the pause; this is a trade-off as a result of increasing the activation threshold from 51% to 75% (see response to q 1 above) to limit risk of malicious upgrades during this sensitive period and also flagged this concern at #8 in the questions and concerns section. > 1. Re Security Council removal of members. This seems like something that would require on-chain voting, do you have thoughts on quorum and such for that kind of proposals? This would rely on the staking and social consensus proposed in Empire Stakes Back - no on-chain token voting.