Request for Proposals: Upgrade Mechanisms

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.

104 Likes
75 Likes
70 Likes
63 Likes
76 Likes

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.

18 Likes

Hey @smallsizechad thank you for the feedback! Itā€™s truly appreciated :heart:

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 :disappointed: 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. :thinking: 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?

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.

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

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?

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ā€ :thinking:

Thank you for your time & input :pray:

13 Likes

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

9 Likes

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 :smile: Thank you kindly!

6 Likes

Thank you for this RFP

4 Likes

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

7 Likes

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

2 Likes
2 Likes

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.

4 Likes

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?

4 Likes

Howdy folks :rotating_light: 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 :saluting_face:

3 Likes
1 Like
2 Likes