[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 propose a system where changes are triggered solely by community activity and acceptance, ala social consensus. The idea is somewhat to avoid the traditional concept of a traditional software upgrade altogether and let the network evolve organically with the community’s direct participation and manually opting-in to all changes, while preserving the immutability and accessibility of all previous versions.

Comparisons

Unlike most networks that utilize a governance mechanism involving voting rights, staking, or delegated power, non-govnernance eliminates the traditional hierarchy and goes back to what we saw with Bitcoin and Ethereum via social consensus.

In contrast to the Republic, or other types of “balanced governance” which attempt to achieve trade-offs between user experience and immutability, there is no multi-sig, no token voting, actually nothing really beyond code and social consensus.

Credit to @LasseAztec for the diagram

This proposal has some explicit shortcomings, and does not meet the requirement of user-friendly migration whatsoever. A majority of users will need to manually migrate their assets/accounts to support an upgrade. This specific consideration is especially unique to Layer-2 networks in a sense, as social consensus on Ethereum or other Layer-1 networks do not have similar notion of (or perhaps importance placed on) “bridged assets” or assets that were initially created on other ledgers to worry about (for further reading, consider Jon’s blog “Rollups aren’t real”).

As part of the user experience tradeoff, this proposal does nicely give users, developers, and infrastructure providers, the strongest possible guarantees that the network, applications, and services they’re using today will not change tomorrow and “rug” via it’s own governance. I believe that the added decentralization, credible neutrality, and inability to co-opt make this trade-off a worth-while consideration - and perhaps more importantly, helps paint what the ungovernable end of the spectrum looks like.

Credit to @LasseAztec for the diagram

Details

Non-governance operates under a very simple idea: if an upgrade becomes necessary, a new, separate version of the protocol is created, while keeping the original intact as long as someone, perhaps the user themselves, is willing to run infrastructure for the previous versions. This means that users, developers, and infrastructure providers then must voluntarily, and most often manually, migrate to the new protocol if they wish, based on the perceived benefits or improvements. The new protocol version would state with no state or from a genesis block, and be dependent on community migrations to achieve adoption or usage. This also means that they can also choose to stay with the old protocol, as long as there are a sufficient number of service providers continuing to support those pervious versions. It is entirely up to social consensus to determine which deployments are canonical or relevant to the community.

User stories

Here’s how it would address &/or impact the user personas:

Users:
Users are free to support or reject a network upgrade. To support an upgrade, they need to migrate their assets to the new version of the network. If they choose to reject the upgrade, they can simply continue using the original version.

The user experience of active migrations is surely one of the largest downsides or tradeoffs of this approach (solutions & suggestions welcome). On one hand there are potential concerns about legacy software not being supported, requiring users to potentially do expensive migrations often enough to be annoying… however, sufficiently sophisticated and financially capable users should retain the option to run any necessary infrastructure perpetually.

Developers:
Developers have the freedom to support the older version or the new one. To adapt to the new version, they will need to adjust their application interfaces and infrastructure. Additionally there will likely need to be some easy / potentially standardized way to migrate state. To reject new versions, they do nothing. There are a variety of examples of project’s doing this well by distributing their frontends over IPFS, or otherwise, to ensure they will always be accessible.

Infrastructure Providers:
Infrastructure providers have the freedom to support the older version or the new one. To adapt to the new version, they will need to update their infrastructure. To reject new versions, they do nothing. There may be some financial motiviaton and community demand to support a variety of older versions or widely adopted forks, which could become burdensome, or perhaps profitable.

Requirements

Censorship Resistance: Since the proposal suggests social consensus, it is extremely resistant to upgrade specific censorship. If a user is being censorsed with respect to an upgrade, or an outdated version of the software, they would typically fallback to running their own node(s). At that point, concerns would primarly be within service providers (e.g. cloud environments) and code distribution platforms (e.g. github) required to run their own node(s).

Assuming that users have access to the code, knowledge of how to use it, and a sufficiently capable machine to run the software on, there are no other points of concern unique to upgrade mechanisms.

Grieving attacks or Malicious Upgrades: This approach virtually eliminates the risk of malicious upgrades, as there is no centralized decision-making process that could be exploited or taken control of. If a version is deployed without buy-in from the community, it is unlikely to be accepted as canonical, and users would be unlikely to migrate their software or assets to it.

Well-Known Mechanism: The proposal is extremely transparent, as users have direct control and can decide independently which version of the network to support. It is likely to result in a longer deliberation process, and periods in which a new version has been deployed but has not yet been accepted as canonical by social consensus - leading to some potential confusion.

While the mechanism itself is well known it may not easy to understand what the latest version is, or even reason about all the possible versions that could potentially exist - this complexity could be real and considerable if a large number of forks or previous versions become widely utilized.

Public decision making: By using social consensus to drive the direction of the network, we can ensure that decisions are not dominated by a small group, or really any group. You, and everyone else, must convince people it’s worth it to migrate.

Questions:

  1. What ways could this proposal be improved?

    • There are a number of small tweaks or expansions to this idea of social consensus ruling everything, such as introducing an informal version registry of sorts (perhaps multiple) that could be valuable in addressing the user experience shortfalls unqiue to L2’s that aren’t relevant to Bitcoin or Ethereum (being the most well understood uses of social consensus). There are also secuity considerations that are somewhat explored in question #3 but are worth more direct exporation.
  2. How do we handle a scenario where the community is split across multiple versions?

    • Probably nothing, it’s designed for these types of scenarios to exist/thrive independent to other versions or instances of the network (we all remember ethereum versus ethereum classic…right? …right??)
  3. What happens in the event of a vulnerability?

    • In general, client &/or contract implementators would work on a potential fix to the issue while users would attempt to recover and force exit their funds. There would be no way to “freeze” or stop the protocol/network from operating, in this specific proposal, and so another way of thinking about this candidly is that it would be a race to withdraw funds between users and attackers. This is potentially not be an acceptable security assumption for the network, particularly in the early days. For the sake of the proposal process and comparisons, I will leave others to explore a design space that consider’s security councils, multisig’s that could potentially pause/freeze/patch the network, or otherwise.
      • It is worth exploring the “training wheels” roadmap outlined by Vitalik, where there are multiple implementations of the state transitioner, and potentially a “fallback security council” that can step in to adjudicate issues between the two (or more) implementations, or perhaps if there is not a rollup produced within X timeframe (e.g. 7 days).
  4. How does a hypothetical network token get minted across potentially different versions of the L1 rollup contract, if the rollup contract itself is non-upgradeable and requires migrations?

    • This is a tough question which I don’t have a great answer for. Perhaps there are different tokens, each themselves versioned, and those with sufficient social consensus can be swapped 1:1 with previous versions. In general, it’d seems to result in a migration and some marketplaces/ecosystems needing to support previous versioned tokens. I’m not sure, and without an elegant solution this is considerably a large downside for this proposal. Suggestions welcome!
70 Likes

A keystore protocol would let users share their multi-party-compute-keys (social-recovery) across forks.

61 Likes

Hey! Thanks for the reply :slight_smile:

Could you elaborate more how this relates to active migrations, if at all? Or is it just an attempt/suggestion to reduce the # of keys required for accounts that are using mpc (which is also nice)? I could be misunderstanding.

58 Likes

Reducing user overhead seems minorly relevant to the cost of migration.

Yes, surely! Appreciate the clarity/validation of understanding.

Throwing a few annoying questions in your direction @cooper-aztecLabs.

First, swo scenarios:

  • Assume that all portals are ungovernable:
    • Do you expect new rollup deployments to come with clean state, or start from current L2 state?
      • If clean state, how do you migrate an L2 only asset? And what about non-asset state?
      • If not clean slate, what happens to the L2 assets such as stable-coins that are generated from bridge collateral, which on the new rollup now is unbacked and impossible to back?
        • In republic, this is also an issue, but less as not all portals are ungovernable. So it is possible to build groups of collateral that “flow together”.
  • Assume that not all portals are ungovernable:
    • Portals will be deployed like many protocols today, some multisig or small dao → internally governed.
    • How large a fraction of portals do you expected to have some form of governance (be it multi-sig or token)
    • Do you think portals would “converge” on what they think is the “real” rollup? If so, this seems similar to an implicit senate (without the neat pending message handling :sunglasses:).

Beyond this, for the token. If the tokens can be swapped 1:1 they need to either be able to burn/mint of each other, or there needs to be same amount of all of them. If they are permissionless to setup, how do you enforce this? And what stops me from deploying a new one valueless rollup and then mint my useless token 1:1 for your valuable one?
Essentially, what is the entity that update the storage for “sufficient social consensus” in the “swapper”?

4 Likes

The current proposal suggests fresh state. “The new protocol version would state with no state or from a genesis block, and be dependent on community migrations to achieve adoption or usage.”

General (unfortunate) answer is that application developers would need to build their own bridge mechanisms to migrate, either offchain, L1, or another mechanism. Non-asset state is a bit less clear but if you have any specific examples i’m happy to try and give them some consideration.

Definitely. No matter what, you will end up with some “internally governed” portals which are outside of the scope of the Aztec protocol and therefore just not something that the community needs to pay attention to (if they don’t want to, similar to the republic).

I would expect a majority of meaningfully used portals to have some form of internal governance (e.g. a circle/usdc or maker dao/dai bridge). Whether or not that is a good thing, is a separate question, and can be considered similarly to any other bridge diversity or almost client diversity challenge. Wrt to this fact, I think the implication of this proposal is that sequencers/provers/infrastructure providers/etc., should remember that the protocol says the governance power should lie within social consensus, rather than portal developers/collateral holders. Perhaps it’s differences are more in spirit than in code.

I think that they would converge, but do so via communication offchain rather than a multisig like you see in other social consensus contexts, like validators aligning on blocks to upgrade at, etc. It surely does not handle pending messages nicely, perhaps I need to look more into the implications there :person_shrugging: Initially my thought was that it doesn’t need to be a factor if you are expecting active migrations so messages to v1 protocols wouldn’t really need to be supported in v2.

Nothing, really, as is acknowledged in the outstanding question #4. I guess in general you would hope that the community doesn’t use any from non-trusted parties or those that have achieved sufficient social consensus yet. But iractice this often looks like CEX “endorsements” or core developers validating deployments, then a long time horizon before social consensus is achieved… and if we’re being realistic, users apeing into a bunch of potential rugs :disappointed: Without an elegant solution it could be a dealbreaker.

2 Likes

The current proposal suggests fresh state. “The new protocol version would state with no state or from a genesis block, and be dependent on community migrations to achieve adoption or usage.”

If the genesis is set up front and is non-empty, you will have issues as the “swap” will essentially revert any L2 state changes that happened between decision making and execution, e.g., possibly unbacked now.

Non-asset state is a bit less clear but if you have any specific examples i’m happy to try and give them some consideration.

Non-asset state could be CDP information which is not using receipt tokens, or Uniswap LP positions where the nft id is pointing to information so it is not enough to know that you got id 420, you need to know what is stored there as well. I think migrating out from a very complex state could be impractical from the point of view that liquidity is “too” tied up for there to be enough free to exit because the free was already exited so you need new assets bridged in to unwind.

I would expect a majority of meaningfully used portals to have some form of internal governance (e.g. a circle/usdc or maker dao/dai bridge).

I think that they would converge

Initially my thought was that it doesn’t need to be a factor if you are expecting active migrations so messages to v1 protocols wouldn’t really need to be supported in v2.

If the largest ones will have governance, they can easily move the collateral from A → B, seems like there would be a hard pushback against having to pay a lot of funds to migrate the state if it could be started from “current” instead. To start from current you need to have many “switch” at the same time or fragmentation or partial state can become a mess (but this is the case for all of the proposals). In the republic I used the registry as the authority for when to switch (and thereby the senate)

I guess in general you would hope that the community doesn’t use any from non-trusted parties or those that have achieved sufficient social consensus yet.

It does not matter what the community does. Unless L1 knows when it is has “sufficient social consensus” I can as a sole actor jump in and trade my shit for you token, essentially sending it to instant 0. If L1 don’t know, it is essentially the same as saying you will trade Dai for any token 1:1, and me minting 10 trillion “shitcoins” and taking your offer :wink:

In the end, a lot of the upgrade question is “how to tell L1 about it” be it through a senate, direct token voting or staking etc.

5 Likes