[Upgrade proposal] - Non-govnernance via social consensus

[cooper-aztecLabs]

@LasseAztec

Do you expect new rollup deployments to come with clean state, or start from current L2 state?

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.”

@LasseAztec

• If clean state, how do you migrate an L2 only asset? And what about non-asset state?

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.

@LasseAztec

• Portals will be deployed like many protocols today, some multisig or small dao → internally governed.

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).

@LasseAztec

• How large a fraction of portals do you expected to have some form of governance (be it multi-sig or token)

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.

@LasseAztec

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 )

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 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.

@LasseAztec

And what stops me from deploying a new one valueless rollup and then mint my useless token 1:1 for your valuable one?

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 Without an elegant solution it could be a dealbreaker.