# Aztec Upgrade Training Wheels **URL:** \ **Category:** Aztec\ **Tags:** upgrades\ **Created:** [July 4, 2023, 4:10pm UTC](https://forum.aztec.network/t/aztec-upgrade-training-wheels/641 "2023-07-04T16:10:24Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![cooper-aztecLabs](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.aztec.network/cooper-azteclabs/32/130_2.png) [@cooper-aztecLabs](https://forum.aztec.network/u/cooper-aztecLabs)\ **Post date:** [July 4, 2023, 4:10pm UTC](https://forum.aztec.network/t/aztec-upgrade-training-wheels/641/1 "2023-07-04T16:10:24Z")
Vitalik outlined 3 stages of [training wheels](https://ethereum-magicians.org/t/proposed-milestones-for-rollups-taking-off-training-wheels/11571) for decentralizing Layer 2 rollups. > There are currently a large number of (optimistic and ZK) rollup projects, at various stages of development. One pattern that is common to almost all of them is the use of temporary training wheels: while a project’s tech is still immature, the project launches early anyway to allow the ecosystem to start forming, but instead of relying fully on its fraud proofs or ZK proofs, there is some kind of multisig that has the ability to force a particular outcome in case there are bugs in the code. Notably this framework has received some buy in from major projects, such as Coinbase. > From the Coinbase perspective, this would be a valuable resources for presenting our users with a standardized risk assessment as they interact and move assets across different rollups. We would be excited to collaborate on fleshing this out and making this a resource that can be standardized across the broader ecosystem. - Jesse Pollak In all of Aztec’s existing [governance proposals](http://forum.aztec.network/t/request-for-proposals-upgrade-mechanisms/605) there are effectively no training wheels, bypassing “Stages 1 & 2” all together, and maybe even “Stage 3”. Let’s discuss this in more depth, and consider what kind of training wheels could be used, taking inspiration from “Stage 3”, the most decentralized stage outlined within the framework. > This is not a requirement, only hoping facilitate the discussion while the upgrade RFP is live ## Primary concern In the event of a security vulnerability, or buggy code, it may be difficult to patch. This post does not concern itself with malicious governance attacks, as those are discussed in more depth throughout existing work. ### Definitions - Halt - the inability to produce a new rollup and state transition - Exploit/bug - an issue in the code otherwise resulting in non-expected functionality, but the state continues to progress > It’s hard to define generic categories here given the amount of uknown unknowns but :shrug: ## Current Comparisons Currently there are 3 governance proposals. - [Non-governance](http://forum.aztec.network/t/upgrade-proposal-non-govnernance-via-social-consensus/611) - [The Republic](http://forum.aztec.network/t/the-republic-a-flexible-optional-governance-proposal-with-self-governed-portals/609) - [The Empire Stakes Back](http://forum.aztec.network/t/upgrade-proposal-the-empire-stakes-back/626) Let’s discuss each of these and how they handle halts & bugs. #### Non-governance | Concern | Halt | Bug | | --- | --- | --- | | What can be done? | Nothing | Race to exit, or nothing | > Non-govnernace stands out because there is no mechanism by which the system can be updated and therefore in the event that the rollup has halted, nothing can be done… Everyone’s assets will likely be stuck, forever. #### The Republic | Concern | Halt | Bug | | --- | --- | --- | | What can be done? | Wait 30 days to release fix | Race to exit, or wait 30 days | > Note that the Republic outlines a spectrum of optional governance for portals. You could be fucked if you are on a non-governable portal because it could be impossible to create the planned “exit”, depending on the issue. The same is true within the empire stakes back. #### The Empire Strikes Back | Concern | Halt | Bug | | --- | --- | --- | | What can be done? | Wait 30 days to release fix | Race to exit, or wait 30 days | ## Breakdown Now that we have a general understanding of the concerns and the proposal’s solutions to these, let’s discuss why this is the case in more depth, and potentially some improvements or solutions to the challenge. In Lasse’s proposal, The Republic, he defines a 30 day upgrade window to guarantee that if a user has issues with the decisions the Senate is making via governance proposals, they have sufficient time to force exit their assets to L1. This is good and generally addresses the issue of being rugged via malicious governance proposals, for example [like we recently saw with Tornado Cash](https://cointelegraph.com/news/attacker-hijacks-tornado-cash-governance-via-malicious-proposal). In Joe’s proposal, The Empire Stakes back, he leverages the framework Lasse defined and (I believe) has the same 30 day exit for the same reason - malicious governance. However, neither of these proposal differentiate between a malicious govenrance proposal and the ability to remedy a halted network. In the event that no rollups are prouduced and we must wait 30 days to fix, that would cause a significant amount of harm to the network and it’s reputation, not to mention an inability to access funds for a whole month. > It is important that this is a well understood design decision. **Generally, I think that this can be improved, and is worth consideration** ## Improvement suggestions In the event of a halt, I think that within \>= 7 days, there should be a mechanism that allows upgrades, by passing the traditional 30 day window. This was proposed for “Stage 3” rollups in Vitalik’s training wheel framework: > If no valid proof is submitted for \>= 7 days (ie. “the prover is stuck”), control temporarily turns over to the security council In the case of the republic or the empire stakes back, there is not necessarily a security council, but rather a Senate that can update the registry contract which points to the canoncial and current version of the network. Simply put, I suggest we enable them to update the software version registry after the 7 day window in the event of a halt, rather than 30. #### Pushing other changes in a hotfix It is critically important that the scope of these changes are limited to fixing the bugs, and that client/contract/etc developers **do not** include any other changes in these releases. I’m unsure how this would be enforced, unfortunately, but assuming that we choose the republic or the empire stakes back, there is a general trust assumption on the senate, anyways. ## Other considerations Vitalik outlines two other criteria that Stage 3 rollups can use. 1. The rollup uses two or more independent implementations of its state transition function (e.g. two distinct fraud provers, two distinct validity provers, or one of each), and the security council can adjudicate only if they disagree - which would only happen if there is a bug 2. If someone submits a transaction or series of transactions that contains two valid proofs for two distinct state roots after processing the same data (ie. “the prover disagrees with itself”), control temporarily turns over to the security council Both worth considering, but likely a bit more work than a simple halting training wheel. ---
**Author:** ![Anon](https://avatars.discourse-cdn.com/v4/letter/a/47e85d/32.png) [@Anon](https://forum.aztec.network/u/Anon)\ **Post date:** [July 4, 2023, 7:21pm UTC](https://forum.aztec.network/t/aztec-upgrade-training-wheels/641/2 "2023-07-04T19:21:13Z")
> [@cooper-aztecLabs](#): > > This is good and generally addresses the issue of being rugged via malicious governance proposals, for example [like we recently saw with Tornado Cash](https://cointelegraph.com/news/attacker-hijacks-tornado-cash-governance-via-malicious-proposal). My understanding is that governance worked correctly, with the malicious code going unnoticed. Therefore a 30-day delay would only help if some other mechanism found the exploit before release. ---
**Author:** ![cooper-aztecLabs](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.aztec.network/cooper-azteclabs/32/130_2.png) [@cooper-aztecLabs](https://forum.aztec.network/u/cooper-aztecLabs)\ **Post date:** [July 5, 2023, 9:17am UTC](https://forum.aztec.network/t/aztec-upgrade-training-wheels/641/4 "2023-07-05T09:17:49Z")
> [@Anon](#): > > My understanding is that governance worked correctly, with the malicious code going unnoticed. Therefore a 30-day delay would only help if some other mechanism found the exploit before release. Correct. It helps but does not solve malicious gov upgrades. In general, I’d reiterate that this is not an attempt to address that specific concern. > [@cooper-aztecLabs](#): > > This post does not concern itself with malicious governance attacks, as those are discussed in more depth throughout existing work. ---
**Author:** ![sam.ng](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.aztec.network/sam.ng/32/1032_2.png) [@sam.ng](https://forum.aztec.network/u/sam.ng)\ **Post date:** [July 7, 2023, 8:27am UTC](https://forum.aztec.network/t/aztec-upgrade-training-wheels/641/5 "2023-07-07T08:27:53Z")
Hey, what an intriguing subject to delve into! I find myself in agreement with Cooper’s perspective that there should be a clear distinction between harmful upgrades and a simple “halt.” This arises from the delicate equilibrium that needs to be maintained between the timing of upgrades for safety and trustlessness. When a bug arises, the ideal response wouldn’t be to post it on a governance forum and wait for a month. Instead, prompt action is required to rectify it. The concept of an immutable or non-governance mechanism doesn’t resonate with me. This is primarily because accepting it is equivalent to acknowledging the eventual obsolescence of the rollup, which would then need to be replaced entirely from the ground up. Furthermore, if you want to add some new cool features, there is no way to do it. That’s why just upgrading the bridge eliminates the need for user migration and, at the same time, allow to improve the efficiency of the protocol. Despite increasing trust assumptions beyond L1 transactions, I am also a proponent of “decentralized governance.” The reason for this is that the control over upgrade keys now lies with rollup governance. As mentioned, Aztec could incorporate waiting periods (which exceed the rollup’s withdrawal time) before implementing upgrades. If an upgrade isn’t to your liking, you can choose to opt out safely. This approach is more in tune with trust minimization because it operates under the assumption of synchrony for rollup governance. You don’t have to trust the majority to be honest. You just need to ensure that you are aware of any upcoming upgrades and can opt out beforehand. In fact, these conversations makes us get partial answers to these following questions but not all of them I guess : How do we reach a consensus on these upgrades? ❓ What if the stakeholders, who make up the majority, have malicious intentions? ✅ How can the control over upgrades be effectively managed? ❓ Is token voting a solution? ❓ To put it differently, what measures can be taken to safeguard the interests of the minority from potential exploitation by the majority?✅ ❓ Hope that makes sense and glad to see great discussions about this (complicated) topic! ---
**Author:** ![jaosef](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.aztec.network/jaosef/32/2731_2.png) [@jaosef](https://forum.aztec.network/u/jaosef)\ **Post date:** [August 2, 2023, 10:40am UTC](https://forum.aztec.network/t/aztec-upgrade-training-wheels/641/6 "2023-08-02T10:40:55Z")
Please see a training wheels implementation proposal that could apply to either Fernet or B52 sequencer designs, and would work with the republic or the empire stakes back governance, thoughts appreciated! > [@BLS Validating Training Wheels](http://forum.aztec.network/t/bls-validating-training-wheels/710): > > Training Wheels Software is known to have bugs. A decentralised network must have mechanisms to mitigate, respond and fix bugs – or it will struggle to gain adoption. For L2’s with bridged funds, this presents an especially difficult challenge – the source of truth for assets is L1. If a bug is exploited and the funds leave the L1 portal contract, the rollup has no claim on them. This problem is compounded when upgrades occur via public social consensus – the bug must be disclosed publicly, be… ---
**Author:** ![rahul-kothari](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.aztec.network/rahul-kothari/32/34_2.png) [@rahul-kothari](https://forum.aztec.network/u/rahul-kothari)\ **Post date:** [October 25, 2023, 2:42pm UTC](https://forum.aztec.network/t/aztec-upgrade-training-wheels/641/7 "2023-10-25T14:42:09Z")
Created a feasibility report on one of the training wheels idea > [@L1 Recovery Upgrade Training Wheel Feasibility Report](http://forum.aztec.network/t/l1-recovery-upgrade-training-wheel-feasibility-report/2458): > > Context Can we leverage Portals and account abstraction to create some type of “L1 social recovery” system where in the event of issues, whether they’re bugs, hacks, exploits, etc., users can have a mechanism that enables their funds to be “exited” to L1 portals, where it can stay until the upgraded L2 is alive? Requirements to satisfy are: Users can grant permissions to a third party that can move their funds to the L1 portal users deposited into The third party cannot do anything else with… Would love feedback!