Request for Proposals: Upgrade Mechanisms

[cooper-aztecLabs]

The next version of Aztec will be launched as a fully decentralized network. Community discussion and feedback plays a vital role in decentralization, and one of our goals is to build Aztec as transparently as possible. For key network decisions, similar to the Sequencer Selection RFP, we will be following a call for proposal method allowing anyone to submit proposals.

Up next on our roadmap: Upgrade mechanisms

Below you will find more information and learn how to get involved.

Overview

Sometimes it’s necessary to release new versions of software. The ability for a community to carefully decide on and implement changes is key to a rollup’s longevity and stability.

Aztec will have a fully permissionless set of sequencers, responsible for publishing rollups to the Ethereum mainnet. The network may also have a governance or staking token. All of these could be used to upgrade to a newer version of the protocol.

This request for proposals is asking the community to help us determine the best way to coordinate upgrades and how consensus on an upgrade occurs.

Specifically, it aims to address the following questions:

1. How do we agree that we want to upgrade to {X-release-of-software}
2. How do we actually perform the upgrade to {X-release-of-software}

Further context

For background on upgrades vs migrations and a framing of the problem at hand please visit the Appendix.

User stories

Proposals should try to cover all of the user flows below. Ultimately, some of these may be conflicting, as there are often tradeoffs in any circumstance which should be considered.

Users:

• What actions do users have to take in order to support, or reject, a network upgrade?

  • When hard forks occur, individual users ideally should not have to change their wallets, keys, or necessarily do anything to support the latest version of the network.
  • When hard forks occur, individual users should ideally have the option to opt-out of the changes, as well, via a forced exit, or another mechanism.

Developers:

• What actions do application developers have to take in order to support, or reject, different types of decisions?

  • Ideally, developers have the option to use the “old” chain similar to using outdated versions of uniswap, or Ethereum classic.
  • If wishing to support the latest version of the chain, application developers may need to update their UI &/or infrastructure to the latest version.

Infrastructure providers:

• What actions do infrastructure providers have to take in order to support, or reject, upgrades?

  • Ideally, infrastructure providers have the option to continue running the “old” chain in order to support any applications still running on previous versions. It should only require a single, or a small number of sequencers running previous versions for them to still be practical.
  • If wishing to support the latest version of the chain, infrastructure providers may need to update to the latest version.

Requirements

Proposals must meet the following requirements and design considerations. If your proposal doesn’t meet all requirements, please call out the missing requirements:

Censorship Resistance:

• The proposed solution should be resistant to censorship and ensure that all nodes have equal access to information regarding the upgrades.
• Users must have the ability to exit and recover their assets back into L1 if they do not agree with the changes.

Grieving attacks or Malicious Upgrades

• The upgrade mechanism should not be susceptible to malicious upgrades.
• Similarly, the proposed mechanism should not allow a small minority to prevent an upgrade.

Well-Known Mechanism:

• The upgrade mechanism should be easily understood and “well known” in advance by the entire network, to foster trust and transparency, allowing users to make educated decisions.

Public decision making:

• The mechanism should use some form of social consensus or community decision making to ensure that the community is in support of the upgrades, and that no single entity has control over the decision-making process, nor victim to potential bribery attacks.

  • This does not mean it cannot use some other mechanisms beyond social consensus, or combination of mechanisms, such as token weighted voting, or otherwise. It is defined as a requirement to ensure that whatever mechanism is used accurately reflects the community’s sentiment, rather than other types of ecosystem actors.

Assumptions

1. There exists a mechanism to force exit (withdraw assets from a L1 portal)
2. There exists a mechanism to force inclusion (push tx’s into the L2)
3. There exists a forum for discussing protocol/network changes (e.g. AZIPs)
4. A network token can optionally exist.
5. One of the submitted sequencer selection proposals will be chosen for how the sequencer participates in the network, and therefore, participates in upgrades
6. Due to the flexibile programmability in Aztec, there is no canonical bridge and each application on Aztec may have it’s own “portal” contract for interacting with L1. Portal contracts hold assets independently. The Aztec rollup contract consists of a state transitioner and “message box” contracts. Neiter of these hold assets. Read the docs for more information about Portal Contracts.

Submission Format

To ensure consistency and facilitate the review process, kindly adhere to the following submission format:

• Title: A concise, descriptive title for your proposal
• Summary: A brief, easy to understand summary of your proposal (about 300 words)
• Comparisons: Explain what makes this solution unique and different from alternative solutions
• Details: Explain the upgrade mechanism, its components, and its functionality
• Questions: Any outstanding questions

Submissions should be created as a new post on this forum, tagged upgrades and rfp. Once the new post is created, please refer back to this RFP and post the link to your proposal as a comment.

Grants

Complete proposals may be eligible for a retro-active cash grant and swag.

FAQ

We anticipate that you may have questions regarding the call for proposals. The following frequently asked questions and their corresponding answers should provide some clarification. Otherwise, feel free to post a question in the forum, contact cooper@aztecprotocol.com, or follow us on Twitter for updates.

Q1. How will a proposal be chosen?

A1. Proposals will be evaluated based on their adherence to the requirements and design considerations, as well as the quality, feasibility, and innovation of the proposed solution. The selection committee, consisting of Aztec Labs employees and possibly external stakeholders, will determine the winning proposal and share the chosen solution publicly.

Q2. Who can submit proposals?

A2. Anyone!

Q3. Can I submit more than one proposal?

A3. Yes, you can submit multiple proposals if you have different ideas for upgrade mechanisms.

Q4. What if my proposal does not fully meet the requirements?

A4. We still encourage you to submit your proposal and participate in the discussion, as your ideas could contribute valuable insights and help shape the final solution.

---

Appendix

This is a tough problem & you probably need some additional context!

Here’s a nice overview from @LasseAztec

Difference on migrations and upgrading

Generally, we make a distinction between a “technical upgrade” and “technical migration”. A migration is a separate deployment, where users must take action to migrate their positions from A to B. An upgrade instead requires no interaction for the individual user.

Example of migration: Uniswap: With the launch of V3, people would migrate funds from V2 to V3 to supply liquidity.

Example of upgrade: Aave: The pool contract is using a proxy and the implementation have been updated on occasion.

While the end goal for those are similar, “provide users access to a new version of the software”, it have some major differences it how this is acheived, and what kind of actions is required by the users of the software. This distinction is likely to be relevant to all of the proposals.

Ethereum

In the domain of Ethereum, deciding that we want to upgrade, and what to upgrade to is often a mix of discussion by the community proposing EIP’s and client developers that work on implementing the proposed EIP’s. When a decision is made to include XYZ into a network upgrade, a time of upgrade is decided. Throughout this process any community member can raise issues with the proposed changes and you might see fractions in the community that disagree whether to support or reject the change.

When the time of the upgrade arrives any node in the network can decide if they want to run the new node software (including the change) or continue running the existing software. If there is a significant divide between the nodes this can spawn long-lived forks of the network with different rules. The value of the fork (and its claim to be the real Ethereum) comes down to social consensus. A famous example of such a split spawned Ethereum Classic after the Dao Hack. Social consensus decided that classic was not the real Ethereum, but both versions live on and users are able to decide for themselves what they think is the real Ethereum.

Rollups with bridged assets

As Jon Charbonneau nicely conveyed in his essays Rollups Are L1s (& L2s) a.k.a. How Rollups *Actually Actually Actually* Work and The Rollup Multiverse a rollup can use the same structure as Ethereum to figure out when to fork and what to fork to but there is one very large difference from a fully separate blockchain - the bridged assets (foreign state).

If there is a proposed upgrade and community want to “fork off” they can deploy the rollup state transition contract, and start it from the current state. The assets can be used inside the fork as if they always were there, but the collateral for any bridged assets will still be in the same contract (not forked by this).

The bridge must decide which of the forks is the “real” one, and only allow it to withdraw funds from the bridge. Only one of the forks can be seen as the “real” one as it might be possible to double-spend otherwise. As an example, assume that you have 10 eth and the fork happens. On both of the forks you now have 10 eth, so you can from the L2 point of view exit those to L1. If L1 accepts messages from both forks you would be able to exit with 2*10 eth and practically have stolen someone else funds (double-spending you deposit).

If the contract with the collateral is controlled by some governance that decided what it seen at the real fork it can impact what is seen as the “real” fork by anyone. For the case where a rollup has a canonical bridge which holds custody of a large part of the rollup value it can practically decide what is seen as the real fork (or at least which of the forks that will have backed assets).

Above is a diagram showing how such a setup could look. We are showing message boxes as the means of communicating between L1 and L2. This set up itself is a consideration that may be relevant to your proposal! A simple (perhaps naive) proposal could define a multisig across each of these L1 contracts which can upgrade as they see fit. As you can imagine, there is a large design space.

Governance Spectrum

Generally, all proposals will live on a spectrum from “strong, well defined governance” to “weak” or almost non-existent governance (e.g. everything is a non-upgradable contract).

Ungovernable

If the contracts on L1 seen in the above diagram are all immutable without admin control or keys, the act of upgrading from one version to another requires that users are exiting funds from the rollup to enter in another system. This is sometimes referred to as a migration as users need to migrate the state from one system to another to employ the benefits of the new.

It is a “upgrade” mechanism that have been used in multiple projects in DeFi mostly prominent is probably Uniswap V3, which required liquidity providers to exit V2 and put their funds into V3.

Governed

Alternatively, contracts can be controlled by some governance organ which are able to decide what is seen as the “real” fork.

The exact mechanism for how this decision is enforced varies between different platforms, but can be done by having a proxy in fron of every contract such that the implementations can be changed by govenrance if the decision is made. Graphically this would look like what we saw earlier, just with an extra party the “governance” that can update the implementations.

Upgrade delay and rage-quitting
To ensure that it is possible to rage-quit the system in case an undesired upgrade, it must be possible for the user to perform a forced-exit before the upgrade is executed. Otherwise malicious governance can trivially steal all bridged funds as we have recently seen in other projects. This is likely a common feature that will be seen across many proposals and authors can assume this mechanism exists.

Tradeoffs

To outline some of the tradeoffs in a digestable manner, the below table shows what is required by the user to ACCEPT or REJECT upgrades and outlining what the user trust beyond correct implementation.

To summarise:

• Upgrade mechanisms that use governance do their job for delegating decision making which makes it convenient for the end-user as long as they agree with the governance direction.
• Upgrade mechanisms that are fundamentally immutable (ungoverned) prove to be a double-edged sword that can protect us from others but may harm us if we are not ready for it.
• The goal of this RFP process is to identify solutions that fit on this spectrum, and what the right tradeoffs are for Aztec! While it sadly isn’t this binary in reality, we expect all proposals to fit somewhere in between, or leveraging combinations of this identified design space.

DISCLAIMER

The information set out herein is only conceptual and describes Aztec’s future development goals. In particular, the network roadmap is being shared in order to outline some of the plans for Aztec and is provided solely for informational purposes only and does not constitute any binding commitment. Please do not rely on this information for any purpose - the development, release, and timing of any products, features or functionality remains subject to change.

[cooper-aztecLabs]

The Republic: A Flexible, Optional Governance Proposal with Self-Governed Portals

Assumes the existance of an Aztec Token (AZT). Summary The Republic is a two-part idea I have been working on that presents a new spin on governance. It’s all about giving the user more control of her risk-profile, whether she desires to delegate the responsibility to some governance or accept it herself. The first part of ‘The Republic’ is about self-governed portals. We’re dividing them into three main types: rollup-governed, portal-governed, and ungovernable. Each one with different leve…

[cooper-aztecLabs]

[Upgrade proposal] - Non-govnernance via social consensus

tldr; use social consensus & end up migrating everything! Summary This proposal suggests a simple approach to Aztec’s governance and upgrade mechanism - focusing on making everything non-upgradable, and therefore dubbed “non-governance” or “anarchy” (perhaps we can come up with a better name, or just call it social consensus?). Instead of having a system of governance that could potentially be co-opted by a few key stakeholders, such as the largest token holders or infrastructure providers, we…

[Anon]

[Upgrade Proposal] - Prediction-marketed non-governance

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…

[cooper-aztecLabs]

[Upgrade Proposal] - The Empire Stakes Back

Summary This proposal is highly-opinionated – onchain token voting does not work. Low turnout, group-think, and bribery are unsolved issues with token voting, and the incentives are misaligned—even with a ‘senate and delegates’-style representative democracy. This quote sets the scene on chain voting fallacies. What if I told you that the republic is now under the control of the dark lord of the Sith? https://www.youtube.com/watch?v=OZtYhpzrcoM Instead of on chain token voting, this propos…

[smallsizechad]

Hey guys. Unfortunately I reckon you can’t expect many community members to be involved in this kind of discussions because to be honest the topic and the language you’re using are a bit complicated for an average user. I personally decided to give it a try though. Hope to be wrong on this one.
As far as I understood, ‘‘The Empire’’ proposal is basically what has been known as a popular ‘‘veToken’’ model, used by many blue chip DeFi projects (Curve, Stargate to name a few). In my opinion it is not innovative, but a very good model. Please let me know if it is actually more sophisticated than it seems, but anyway, from my not very professional PoV, this one is the most suitable one.

So, hypothetically, what if the governance includes some kinda of social reputation as well. For example one’s voting power could be determined by the amount of veAZT (staked AZT) + some kind of offchain/web2 reputation like Github/Twitter account or a role in the discord server (specifically created for valuable community members and builders/helpers) which could be, say, up to 1.2x multiplier of veAZT voting power?

As of forcing people to actually participate in governance and not just hold/stake tokens: what if active votins is a requirement to claim staking rewards but with some kind of mechanism, determining conscious voting (to exclude bots and scripts) ?

P.S. Social/Builder/Community score for governance can be proved with ZK-Badges (SBT like by Sismo.io, for example). Of course they should work only as an addition to holding staked veAZT.

[cooper-aztecLabs]

Hey @smallsizechad thank you for the feedback! It’s truly appreciated

@smallsizechad

the language you’re using are a bit complicated for an average user.

I think that in general, this is fair and something we are aware of.

From my perspective, it’s a request for network design proposals and therefore is targeting researchers, infrastructure builders, economists, etc… those who have experience designing networks - not necessarily average users, unfortunately. I think that there is a time and place for non-engineers, etc. to contribute to network design, but this is arguably too technical of a concept to try and successfully bring everyone along on the journey With that being said, perhaps this is too in the middle, whereas it’s not technical enough for researchers, and not fully digestible enough for the broader audience. What do you think? Is it worth trying to bring everyone along for the journey, however futile it may be? Or should we prioritize catering to those we believe will be able to produce sufficiently robust and thoughtful designs?

@smallsizechad

As far as I understood, ‘‘The Empire’’ proposal is basically what has been known as a popular ‘‘veToken’’ model, used by many blue chip DeFi projects (Curve, Stargate to name a few). In my opinion it is not innovative, but a very good model. Please let me know if it is actually more sophisticated than it seems, but anyway, from my not very professional PoV, this one is the most suitable one.

At a high level, I believe some of the differences are in that you are not minting a $veAZTC governance token (or whatever it could hypothetically be named in the future) and there is no reward/incentive for longer stake durations. That’s something we’ve discussed but none of the proposals define yet. They’re almost all as simple as possible, intentionally.

Fundamentally I’d say that the Senate is an attempt to define the challenges specific to L2’s, as well as separate concerns and ensure that any multisig holders that may be required to deploy new versions (or more accurately point a registry to the latest version) do not have the ability to rug, take, or reallocate any users funds, whether maliciously or by accident - via the use of self governed portals (bridges). This seems unique compared to the other projects you mention.

@smallsizechad

what if the governance includes some kinda of social reputation as well

This is a cool idea I’d love to see explored more throughout these proposals & industry more broadly.

@smallsizechad

For example one’s voting power could be determined by the amount of veAZT (staked AZT) + some kind of offchain/web2 reputation like Github/Twitter account or a role in the discord server (specifically created for valuable community members and builders/helpers) which could be, say, up to 1.2x multiplier of veAZT voting power?

While I like the idea, it seems somewhat tough to implement this while fundamentally preserving users privacy, at least, without building a significant amount of offchain infrastructure. Not that this is a dealbreaker, but it’d be one of the fundamental challenges to something in this direction – particularly adding a web2 compatible, privacy preserving reputation system, as a mainnet launch requirement, could delay things… Are there any orgs doing this as service that could be more easily leveraged?

@smallsizechad

what if active votins is a requirement to claim staking rewards but with some kind of mechanism, determining conscious voting (to exclude bots and scripts) ?

@smallsizechad

P.S. Social/Builder/Community score for governance can be proved with ZK-Badges (SBT like by Sismo.io, for example). Of course they should work only as an addition to holding staked veAZT.

Cool ideas, as well. Begs the question of how frequently are there actually going to be votes… (I’m currently hoping not that often to ensure a robust, stable network that devs can rely on for feature targeting…) But surely worth considering! Assuming we go with a model that includes voting, perhaps it’d be valuable to do another proposal that separates “how voting happens” from “how votes are counted”

Thank you for your time & input

[smallsizechad]

@cooper-aztecLabs

it seems somewhat tough to implement this while fundamentally preserving users privacy, at least, without building a significant amount of offchain infrastructure. Not that this is a dealbreaker, but it’d be one of the fundamental challenges to something in this direction – particularly adding a web2 compatible, privacy preserving reputation system, as a mainnet launch requirement, could delay things… Are there any orgs doing this as service that could be more easily leveraged?

Yes, I have already mentioned sismo.io, a ZK-badge service. Those guys are fantastic, have been live on mainnet for about a year already and I believe some Aztec-based project (if I remember correctly it was called ZKpay) has issued ZK-badges on there for some purposes.
Their ZK-badges are non-tranferable SBTokens, fully private and can be minted to another (fully anon) address to prove any web2 or web3 data on-chain.
There are competitors, but those guys are real ZK-maximalists and I haven’t seen other projects of that kind to care this much about privacy.

Here is more info on what they do: https://docs.sismo.io/sismo-docs/welcome-to-sismo/readme

[cooper-aztecLabs]

@smallsizechad

Those guys are fantastic, have been live on mainnet for about a year already and I believe some Aztec-based project (if I remember correctly it was called ZKpay) has issued ZK-badges on there for some purposes.

Makes sense! I’ve only been working at Aztec Labs for ~3 months, so was before my time. It does appear the team is connected and that is a great call out Thank you kindly!

[KevinLomax]

Thank you for this RFP

[LasseAztec]

@cooper-aztecLabs and I have listened to the midichlorians and propose The Return of the Jedi

[jaosef]

A simplified and improved version of The Empire Stakes Back, compatible with Fernet.

The Empire Stakes Back Again

This is a simplified and general version of the original Empire Stakes Back proposal, that is compatible with Fernet. Assumptions There is at least an honest majority of stakers participating in block production. The honest majority assumption is the same assumption used for ETH stakers. The sequencer selection algorithim is not game-able and the distribution of blocks over a “upgrade” period will be random and fairly reflect the honest majority assumption. There are at least two independent s…

[Anon]

[Proposal] Standard Address Upgrades

(an adaptation of Zcash Unified Addresses (ZIP316)) This is an extension of social consensus, compatible with PBS. PBS introduces a stakeholder set, whose signatures are required to progress each rollup. Because PBS allows stakers to run on low-end hardware, it is acceptable to assign a single stakeholder set to multiple concurrent rollups. The PBS stakeholder set is then assigned, via social consensus, additional rollups as needed. If a rollup’s based block rate is consistently and consider…

[bberry259]

Gm Fren. I’ve been able to give this some thought and have an implementation idea.

One thought that kept being of centre at mind was how to make the protocol unstoppable. Other than contracts revoked most protocols and chains suffer from developer control. This results in potential attack vectors from state and other actors. Aztec needs to be the most resistant to this, otherwise you will be forced to pause it on the whim of someone somewhere (see Thorchain).

Moving to a resistant system like Bitcoin (where upgrades must be backward compatible and any hardfork needs a majority of nodes and there are a f*ck ton of nodes) is unrealistic and unfeasible. Having an upgradable system (with or without community support) has issues (see above). I am therefore proposing the following:

The initial implementation of Aztec is immutable. It cannot be changed. (PSA you can still end up in prison for this, see Tornado). Done. Cant be changed. We use it. We have privacy.

but but but but what if there is a problem and it needs to change? Or new tech comes along which would enhance security or privacy or speed or viability or or or? Clearly the initial implementation cannot be changed, that is the way it was built. At the point someone wishes an upgrade to happen then can propose it and it can be built, AS A SEPERATE CHAIN. (stick with me for a while please).

This proposal can be proposed via Snapshot (new users cannot post links) and implemented via a customised oSnap (new users cannot post links). This allows for trustless implementation with lots of eyes on it.

A new chain is annoying I hear you say. But is it really?! We’ve just spent the last two years playing on a number of fantastic chains, hopping and bridging between them as we see fit. I ask you, dear reader, do yo have funds on Arbitrum and Optimism (and base and linea and, and and)? So I do not see the problem with a new chain. People would not vote in favour if it didn’t have ecosystem support. And I don’t see these being spun up every week, or month, or year. But there will come times when there is enough to upgrade to warrant an improved chain. Its important to note that this doesn’t defunct the original chain, that keeps chugging and will keep lots (potentially the lion share) of TVL and activity.

Bridging between these chains can be as cheap and as fast as imaginable using third parties or indeed an in house solution.

So we have my proposal (if you can call my rambling above that) for Migration and Upgrade. But who gets to vote and how many votes do they get? It almost doesn’t matter, users cannot be harmed through voting. If voting is required for looking after a treasury/ developer grants etc then that can be as simple as the way UNI works (or doesnt work…).

Thank you for coming to my ted talk.

[cooper-aztecLabs]

Hey @bberry259 thanks for your reply! I wanted to help paint the spectrum of options (not make an explicit recommendation) & proposed non-upgradable, immutable smart contracts here: [Upgrade proposal] - Non-govnernance via social consensus which I believe is very similar to your suggestion. Where it differs is that it sounds like your idea is to have community members vote on new deployments, via token balance based snapshots, and that determines if a new deployment is canonical. Where my suggestion originally had no voting and acknowledges the reality anyone can deploy a new version at any time, and they must convince other’s that it is relevant. Personally at the moment I’m not 100% sure why you would need voting in a fully immutable world, when it essentially will rely on convincing users and ecosystem participants to adopt via a migration, anyways. Do you feel strongly about the pros/cons here, and if so, why?

[cooper-aztecLabs]

Howdy folks Heads up that we are doing a final call for upgrade proposals!

There will be 1 more week to submit your proposals - deadline is November 17th.

Please let us know if you have any questions

[cooper-aztecLabs]

[Upgrade Proposal (Concept Only)] Beskar Council: A Temporary Emergency Pause-Only Multi-Sig

CONCEPT PROPOSAL, FOR DISCUSSION PURPOSES ONLY - DOES NOT CONTAIN ALL TECHNICAL DETAILS Summary Description This is a high-level (non-technical) concept proposal only. It proposes a discussion around a potential modification of the Empire Stakes Back proposal and proposes a “training wheels” (pause-only) multi-sig add-on for the first 12 months (the “Security Council” or the “Beskar Council”) layered on top of the existing governance structure as set out in the Empire Strikes Back propo…

[cooper-aztecLabs]

[Upgrade Proposal] - Balance of the Force

Summary This proposal lays the foundation for upgrades by social consensus, while preserving the ability to quickly resolve issues while the network is still in development. In this proposal, infrastructure providers determine whether an upgrade goes into effect after receiving feedback from the community. By default, there is a 1000 block timelock to allow users to withdraw funds. Importantly, this proposal applies training wheels in the form of a security council. This security council provi…