The Return Of The Jedi

[LasseAztec]

Joint proposal with @cooper-aztecLabs. Require knowledge of non-governance and The Republic

Summary

This proposal is a combination of non-governance and The Republic. It takes the idea from non-governance that there should not be an upgradable Rollup, but acknowledges that not all parts of the Rollup need to be ungovernable.

Namely, the state transition function will be immutable, but the senate is able to change the gas-pricing – e.g.,the gas used per operation (nullifier insertion, etc.) – and sequencer selection contract through the same mechanism as The Republic.

Comparisons

This proposal takes inspiration from The Republic but limits the Senate’s powers by taking inspiration from Uniswap’s fee switch - e.g., governance should only have well-defined, scope-limited power.

This proposal is closer to the non-governance side of the spectrum than other alternatives (this proposal has the smallest power scope of any other proposal, besides non-governance). This proposal includes a majority of the republic’s dynamics, including the Senate, technical committee, and ability for portal developers to opt-out of governance’s ability to update fees and sequencer selection protocols.

Details

Looking back at prior Ethereum hard forks, we see that many are related to gas re-pricing of opcodes or changes to how the next block is chosen. In most cases, many of the inner workings of the Ethereum protocol are unchanged, with relatively few points of interest being the most frequent changes.

With that in mind, this proposal keeps the state transitioner constant but changes ‘peripheral’ values, and as such, the Senate is given a much narrower and more clearly-defined scope of power. Due to the narrower scope of possible changes, it is also possible to reduce the timeframes in which “upgrades” are pending, potentially down to 7 days instead of the 30 days proposed in The Republic.

The Senate still controls the registry, but the registry is simplified – it no longer points to multiple snapshots, but only to the gas pricing, sequencer selection and the Senate implementation itself.

This proposal supports upgrades that impact only the liveness properties of the network, such as repricing gas usage by different operations (nullifier insertions, etc) and the sequencer selection, while ensuring that the safety property is ensured.

In the diagram below (heavily inspired by the Repuplic), you see that the Senate can only “touch” the state transitioner through the fee and sequencer selection.

Thoughts on malicious governance

To ensure that the rollup cannot be frozen forever by the Senate massively inflating gas costs or changing the sequencer selection to an always-reverting case, the state transitioner must have an alternative route. In the case where block production has been halted for X time, the state transitioner must be able to use “default” pricing and accept blocks from any party with a valid proof (and it is up for discussion if this default should be used until a “normal” block is produced, or whether the timer would reset at every block).

While this could mitigate some of the issues from halting the rollup, it is still possible to upgrade the sequencer selection to a version with only one sequencer that is heavily censoring. In that case, token holders could elect a new Senate and go back to using a censorship-resistant sequencer selection mechanism.

Addressing non-gas or sequencer upgrades

For upgrades such as EIP1559, which altered the gas-model beyond just altering the gas costs of op-codes, migration to a new rollup where the state transitioner supports this would be required, OR the state transitioner should be made such that the gas-model is a module that can be altered and swapped (e.g., by having a separate circuit that handles this, where the verification key is fed into a block at verification time similarly to how the gas costs could be).

Addressing bugs in state transitioner

Ultimately, there’s nothing that can be done here, other than a race to exit (if possible).

[Ariiellus]

@LasseAztec

In that case, token holders could elect a new Senate and go back to using a censorship-resistant sequencer selection mechanism.

I’m thinking in a mix between Quadratic Vote (i.e Colorado HoR 2019) and Conviction vote (i.e. Polkadot) combined with a sybil resistance mechanism like MACI / MACI 101.

Disclaimer: I’m not an expert in this field, I’m learning about game theory, token engineering and incentive mechanisms. If in the future is possible to contribute in this area I’ll be more than happy

[LasseAztec]

Quadratic voting only really seem interesting as long as you can keep sybils at bay.

Don’t Maci rely on a registry of keys for those that are allowed to vote? That seems to mostly push the issue of sybil to the next guy in line? E.g., you now have to solve the sybil for how to add people to that registry and we don’t want any one entity to do that because that is the same as them just controlling it.

[heuer.eth]

Hey, this is Michael from Aragon. A very interesting proposal that we think can be realized with Aragon OSx and the permission management system at its center.

Before drafting how the “The Republic” and “The Return of the Jedi” designs can be realized with Aragon OSx, I would like to make sure that the following distinctions I am making are correct:

The technical/jedi council in particular seems to coordinate off-chain in the sense that Jedi Masters are individual actors not necessarily forming an on-chain body such as a Multisig, which sounds very reasonable to me given their duties (deploying contracts that the Senate will set in the Registry, giving advice).
Moreover, the difference between “The Republic” and “The Return of the Jedi” seems to lie on the protocol side. Components like StateTransitioner, Registry, SequencerSelection, and GasPricing are contracts with minimal implementations (and minimal attack surface). The only connection to the governance part is the Senate having permission to set the addresses in the registry, which I think is a good design.

If I got this right, I will map out the setup with Aragon OSx. If you meanwhile want to have a read on how our DAO and plugin system works, you can take a look at our developer docs.

It is also worth noting that despite Aragon OSx’s modularity and upgradeability allowing a DAO to evolve over time to adapt to changing requirements, you can also do the opposite and ossify the system by disabling upgradeability and freezing permissions permanently.

[LasseAztec]

Hi @heuer.eth, very neat diagram. Yes I think that matches quite nicely.

Moreover, the difference between “The Republic” and “The Return of the Jedi” seems to lie on the protocol side.

Exactly, governance is similar with just with different limitations on what they can change.

you can also do the opposite and ossify

Correct, if governance has the desire, they can move it into non-governance as proposed separately.

Looking forward to see what you outline. Great to see proposals expanding on each other.

[heuer.eth]

Governance Implementation for The Return of the Jedi & The Republic by Aragon

Based on the governance design provided and clarified in previous posts

we propose the following governance implementation using Aragon OSx, our new, modular governance framework:

For simplicity, only relevant state variables, functions, and parameters are shown.

Next, we present details on our proposed implementation.

On-chain Governance

The on-chain governance consists of three contracts

• CitizenAssembly
• Senate
• DAO

and two sets of actors

• Citizens
• Senators

The DAO contract is created through the standard Aragon OSx DAOFactory, which allows you to select (multiple) plugins adding functionality to your DAO.

For Aztec, Aragon would provide an AztecGovernance plugin comprised by a CitizenAssembly and Senate contract. An associated AztecGovernanceSetup contract would deploy the CitizenAssembly and Senate contract and establish the permission relations between them and the DAO contract. This allows the Aragon OSx PluginSetupProcessor to set up the plugin. To build the plugin, we can re-use existing functionality from our TokenVoting, AddresslistVoting, and Multisig plugin.

Because the difference between The Republic and The Return of the Jedi lies on the protocol part, the on-chain governance implementation we propose can be used in both designs.

CitizenAssembly

In contrast to the original design, we propose the CitzenAssembly contract as a second governance body, allowing the citizens to exert their powers on the Senate. We did this to clearly separate the governance logic involving the citizens from that of the Senate on the contract level. Although we prefer this separation from an architectural standpoint, the CitizenAssembly logic can be incorporated into the Senate contract as well without any change in behavior.

State

• address dao: The address of the associated DAO (required access the DAO permission manager).
• Proposal[] citizenAssemblyProposals: a list of proposals that token holders create and vote on in the CitizenAssembly

Functionality

• createReelectionProposal(address[]): Creates a proposal to reelect the senators. Upon approval and execution, the setSenators(address[]) function in the Senate contract is called.
• createSenateProposal(Action[]): Creates a proposal (AZIP) containing defined actions to be voted on in the Senate contract. Upon approval and execution, the createProposal(Action[]) function in the Senate contract is called.
• createEmergencyStateProposal(bool): Creates a proposal to turn the emergency state mode on and off. Upon approval and execution, the setEmergencyState(bool) function in the Senate contract is called.

Calling the three functions in the CitizenAssembly requires you to be citizen (i.e, a token holder) and custom conditions can be added on top (e.g., minimum number of tokens held).

Senate

The Senate contract allows the senators to exert their powers of approving and executing AZIPs coming from the CitizenAssembly through the DAO executor.

State

• address dao: The address of the associated DAO (required access the DAO permission manager).
• address[] members A list of senator addresses.
• Proposal[] senateProposals: a list of proposals proposed by the CitizenAssembly for the senators to vote on.

Functionality

• setSenators(address[]): Sets the senator addresses. This function is guarded by the SET_SENATORS permission being granted only to the CitizenAssembly contract.
• createProposal(Action[]): Creates a proposal for the Senate. This function is guarded by the CREATE_PROPOSAL permission being granted only to the CitizenAssembly contract.
• setEmergencyState(bool): Moves the Senate into/out of the emergency state. This function is guarded by the CREATE_PROPOSAL permission being granted only to the CitizenAssembly contract.
• vote(proposalId): Allows senate members (senators), to vote on a proposal. The details of the voting process (vote duration, delays, etc.) settings are customizable to the needs of the Aztec’s community. Features can potentiallybe added through follow-up updates.
• executeProposal(proposalId): Allows senate members (or optionally everyone) to execute a proposal.

DAO

The DAO contracts is the identity and account of your on-chain governance system. Besides other, essential functionalities, it allows you to execute arbitrary actions, manage permissions, and validate signatures.

Functionality

• execute(Action[]): A non-reentrant executor allowing to execute generic Action calls (see the section on Action execution in our dev portal). This function is guarded by the EXECUTE permission being granted only to the Senate contract.
• grant(Permission)/revoke(Permission): Grants/revokes permissions (see the section on Permissions in our dev portal). This function is guarded by the ROOT permission being granted only to the DAO contract itself (and temporarily to the PluginSetupProcessor during the setup of the plugin). Through execute(Action), the DAO can call the function itself.

Protocol

The protocol part is immutable, independent of the on-chain governance part, and will be developed by Aztec. This is also the part where architectural differences between The Republic and The Return of the Jedi can be found.
However, the connection between the on-chain governance and the protocol part is equivalent, as the interaction occurs between the DAO and the Registry in both cases.

Registry

Although there are differences between The Republic and The Return of the Jedi, the connection between the on-chain governance and the protocol part is identical: Through the DAO contracts execute(Action[]) function, the Senate has the ability to call the setGasPricing(address) and setSequencerSelection(address) in the Registry contract to set the implementations that the StateTransitioner contract will then interact with. No other address than the DAO is allowed to call the Registry setter functions, which is achieved through onlyOwner modifiers.

We propose that the Registry should have a setOwner(address) function allowing it to change the owner to another address. Furthermore and in case the Senate is corrupted, we suggest putting a mechanism in place allowing the CitizenAssembly to call the setOwner(address) function through the DAO, thus bypassing the Senate and in case the emergency state was triggered.

Social Coordination

Technical/Jedi Council

As clarified in a previous post, the technical/Jedi council has an informal role. Councillors/Jedi are nominated by the citizens, inform the senate and deploy new contract implementations of the GasPricing and SequencerSelection contracts that the senate can set through the DAO.

---

Considerations on Upgradeability

Aragon OSx DAOs are upgradeable by default. The DAO upgradeability can be disabled permanently or time-locked.

Aragon OSx plugins can be upgraded or replaced by other plugin implementations, and we designed a complete lifecycle around it (i.e., installation, updates, uninstallation). Plugin developers can provide newer versions (containing security patches or feature additions) that DAOs can upgrade to. Again, you can opt out of this system by permanently disabling or time-locking this functionality.

---

I am happy to receive feedback and discuss improvements.

[LasseAztec]

Hi @heuer.eth, sorry for the slowness from my side here.

Like the way you mapped multiple of the proposals on the same skeleton, think we have had troubles showing it nicely before.

Seems interesting that most can be plugged together with mostly prebuilt components

Do you have examples of protocols/teams using the Aragon OSx contracts? And any of them using it in the immutable version or having the governance perform the upgrades of itself if upgradable?

[heuer.eth]

Hi @LasseAztec,

Like the way you mapped multiple of the proposals on the same skeleton, think we have had troubles showing it nicely before.

Thanks, we are glad to show the capabilities of Aragon OSx .

Seems interesting that most can be plugged together with mostly prebuilt components.

Yes, this lowers the effort to create custom plugins significantly because we can re-use parts that are already in production in our DAOs today.

Do you have examples of protocols/teams using the Aragon OSx contracts?

Our framework launched earlier this year. Accordingly, every DAO deployed since then, uses Aragon OSx (check out our Aragon App frontend). We currently support Ethereum, Polygon, and Base and will extend to more networks over time. To date, 2148 DAOs have been created with Aragon OSx according to our dune dashboard.
Naturally, we use an Aragon OSx DAO ourselves for the OSx protocol infrastructure governance (i.e., registries, factories, ENS registrars, and other components) as well as funds management.

We are in talks with other protocols (predominantly staking protocols) and expect a couple of deployments before the end of the year. It should also be noted that there are generally few community-governed protocol DAOs to date. Looking at bigger protocols, this applies to, for example, Lido, AAVE, Uniswap, Nouns, and Gitcoin, whereas the majority does not have binding on-chain vote execution. In light of these few examples, the thoughtful approaches to protocol governance presented in this and other proposals in the forum will put Aztec at the forefront of protocol decentralization.

Any of them […] having the governance perform the upgrades of itself if upgradable?

In our Aragon App frontend, the modularity features (installation and uninstallation of plugins) are not available yet, as the frontend is not en par with our contract functionality.
In Q4, we will enable updates to roll out new features and patches to existing DAOs and Aragon plugins. Our updates will be audited, optional, and presented to the DAO via a proposal that must to be approved and executed by the DAOs governance process (e.g. a token vote or approval by a list of members). Our process is very similar to what Gnosis Safe has recently announced too.

Any of them using it in the immutable version […]?

Currently, none of the OSX DAOs is immutable as we deploy upgradeable contracts by default. The reasoning behind this decision is that this allows us to provide security as well as feature updates over the lifetime of a DAO.
Even well-audited contracts can be subject to unexpected compiler vulnerabilities and bugs, (see, for example, the recent compiler bug for solc versions <0.8.21 that didn’t affect our contracts).

Because immutability/ossification was a requested feature by a staking protocols we are in discussion with too, we consider making this a generally available feature via a future update.
In this context, we explore is a time-based locking mechanism. However, this would not prevent us from doing a custom deployment for Aztec earlier, where upgradability is disabled.