BGD. Aave Governance V3

[bgdlabs]

TL;DR

We present to the community Aave Governance v3, the next iteration of the Aave decentralized governance to control the whole ecosystem: multi-chain native and minimizing voting cost.

Currently: Aave Governance v2

The whole Aave ecosystem is controlled in a decentralized way by version 2 of the Aave governance smart contracts.

It works the following way:

• Addresses with AAVE proposition power can create proposals on an AaveGovernanceV2 Ethereum smart contract.
• AAVE holders or recipients of voting delegation participate by voting on the same AaveGovernanceV2 Ethereum smart contract.
• If a proposal fulfills the success thresholds (more than X Yes votes, and more than Y difference between Yes/No), it gets queued into a time-lock.
• After the delay on the timelock ends, the Ethereum governance contracts or 1) execute a payload (executable code) on Ethereum itself, OR 2) using the existing Aave cross-chain governance system, “forwards” the decision to a target network (e.g. Polygon) to a payload to be executed there.

Current architecture and flow on Aave Governance v2

Non-optimal aspects of V2

While being a production-grade system, and covering the needs of one of the most active on-chain governances in the broad DeFi field (and blockchain in general), same as with all other Aave components, the strategy is to always identify points of improvement, and iterate over them.

Some aspects to improve around Governance v2 were:

• Cost of voting. Simply too high. Aave/stkAAVE voting power is quite distributed with more than 150’000 holders of Aave and 20’000 of stkAAVE, with a lot of them holding small amounts.
  Even when Ethereum gas price levels are relatively low (~20gwei), and depending on the ETH price, the cost of voting on a governance proposal is around $5. If the network is slightly congested, this can easily be multiplied by 3x, 5x, or 10x.
  It is just not scalable for holders of small amounts of AAVE to pay even $5 for voting on 1 proposal.
• Important coupling between governance and tokens. For the governance to be able to “query” the voting power of an AAVE/stkAAVE holder, the tokens themselves need to record a history of balances, which makes transfers of AAVE/stkAAVE pretty expensive. This is accentuated by having proposition and voting power, which hints at too much need to weigh the features of the system versus the cost of introducing them.

Next: Aave Governance V3

So the question is, keeping the same or more level of decentralization, can the Aave Governance be improved? The answer is yes.

High-level differences V2 vs V3

• Proposal creation. Fundamentally, nothing major. Proposal creation happens on a governance smart contract on Ethereum and can only be done if the address has enough proposition power (balance and/or delegation).

  The only difference is that now the governance will be payload-contract oriented: before creation, the proposer or somebody else will need to deploy and register in an Aave contract the payload/s smart contract with the logic to be executed if/when the proposal passes, in the network/s where the changes will be executed if the proposal passes. This will be common for both Ethereum and non-Ethereum networks, and the proposer will only need to pass on the creation stage the id of said payload/s, and on which network they are deployed.

• Pre-voting delay. Almost the same as on v2: there will be a 1-day delay between proposal creation and the start of voting, with the “snapshot” of voting power to be taken just when that delay passes. For some technical reasons, on v3 this delay will not really always have the exact same duration, but it will mainly increase in the order of 1h difference.

• Voting. We will expand on this later on, but this is the main difference between v2 and v3, in what affects governance participants: to vote, AAVE holders/delegators will not be doing it on Ethereum in the big majority of the cases, voting will happen in other networks like Polygon, Avalanche, Arbitrum or Optimism, of which initially we will recommend Polygon and Avalanche to start with. An important aspect is that for each proposal, voting will happen in only 1 network, not in multiple in parallel, but the proposer can choose where exactly to do it, depending on his preferences or other community decisions.
  So proposal 201 could be voted on Avalanche, while proposal 202 could be on Polygon.

• Execution. Technical differences apart, that will be explained later, the time-lock and execution phases of proposals will be exactly the same as before, and initially, any network on which the Aave ecosystem is present will be covered, including the ones not so possible right now, like Avalanche.

What’s new on V3?

• Extremely cheap to vote, DAO potentially makes voting completely free for participants. Even if highly dependent on the voting network of the proposal and its congestion, it we take a current example of gas prices on Polygon, the voting cost would be in the range of $0.05-$0.10. For reference, this is approximately 100 times cheaper than voting in the current Aave Governance v2.

  Considering this low cost, and in order to take the voting UX experience and participation to the next level, we will propose for the DAO to cover the voting cost of all participants, by using the meta-transactions capabilities included in Governance v3. This seems potentially reasonable, as with a cost of 7.5 cents per vote, and 10’000 participants, the cost would be a total of $750, to pay for 10’000 on-chain votes!**

  We are in contact with Gelato Network as an option for voting relaying.

• Future proof. The modularity of the system and how components are agnostic from each other allows us to really improve it, whenever new opportunities or models pop up.

  For example, it will be pretty straightforward to add new assets with voting power, like a different flavor of AAVE.

  Another future option is to even expand to non-EVM networks if they fulfill the infrastructural requirements (bridging infrastructure, efficient and compatible storage-proofs over Ethereum state).

• New voting assets from day 0. Apart from AAVE and stkAAVE, stkABPT and aAAVE (v3 Ethereum) will be supported at launch.

  Other flavors of AAVE like those bridged to non-Ethereum networks will not be possible at the start, as the complexity is higher.

• No more history snapshots of balance on AAVE/stkAAVE. The new voting system doesn’t require any historic balances of the voting assets like AAVE. In practice, this means that after the upgrade of the token’s smart contract to be included on the release of Aave Governance V3, transfers of AAVE & stkAAVE will become approximately 75% cheaper.

• Permissionless automation under the hood. Aave Governance V3 will have some additional state transitions compared with V2, in addition to the well-known queue() and execute(). But both these and the new ones will be completely automated (and still fully permission-less) by using Chainlink Automation, on our new tool: Aave Robot.

---

Architecture

Ethereum as the Core of Aave Governance on v3

During the last year, and probably only accelerating, the trend is for Ethereum to become the top blockchain security and settlement layer, with more and more “roll-up”-style technologies connecting to it.

Aave Governance V3 follows this approach too. Even if described as multi-chain, the most precise definition would be as Ethereum-anchored: all types of validations and access control live on smart contracts in Ethereum, aligned with the utility of the AAVE token being majorly on Ethereum at the moment.

So the responsibilities of the Ethereum smart contracts of V3 are:

• Validate that those proposal creators have enough AAVE proposition power.
• Whitelist Voting Portals, which represent other networks where voting happens and their voting strategies (which tokens are counted).
• Decide from which Ethereum block a “snapshot” will be taken to consider balances for voting.
• Enforce certain time duration and expiry requirements.
• Enforce “success” metrics: count of YES votes, vote differential.
• Manage queueing of proposals once voting was successful.
• Decide where to “forward” proposals once ready for execution: to other Ethereum smart contracts or different networks.
• Cancel capabilities via Guardian for malicious proposals.

In more technical terms, the Ethereum contracts of Aave Governance V3 could be defined as a controller (deciding how, where, and when proposals “move” to other components) and access control contract (deciding who can do certain actions like creation of proposals, or whitelisting all other components, like voting networks or voting strategies).

Aave Voting Networks/Voting Machines

As everybody in the community knows, Aave is a really inclusive ecosystem, always one of the first protocols to support new networks and technologies expanding there. We have seen this for example with the v2 liquidity protocol, being the first DeFi player to expand to Polygon and Avalanche, Aave v3 expanding on launch to optimistic roll-ups like Arbitrum and Optimism, or even the first version of the Aave cross-chain governance, currently controlled the previously mentioned systems.

With regards to Aave Governance V3, this ethos is followed by what we denominate as Aave Voting Networks.

An Aave Voting Network is any blockchain network where the Aave Governance allows eligible governance voters (holders of voting assets or delegatees) to participate in voting, for a certain proposal.

An Aave Voting Machine is the smart contract deployed on each Voting Network that contains all the logic for validation and accounting of votes in proposals.

Voting Networks/Machines work the following way:

• Voters don’t have a balance of voting assets of delegation on the Voting Network. The balance/delegations of for example AAVE stays on Ethereum.

• Ethereum block hashes as the source of information for votes; storage proofs as the core mechanism for validation. For a certain proposal, and even on Governance v2, in practice, the system takes a “snapshot” of voting token balances/delegations at exactly 1 point in time: the Ethereum block just before the delay post-creations ends.
  On Governance v3 this is exactly the same, but the (big) change is that the system 1) takes the block hash of Ethereum when proposal voting should start 2) forwards it to an Aave Voting Network 3) sets it as the main source of balances/delegation to validate against whenever an address submits a vote there.

  Simplifying the technicalities, Ethereum block hashes contain the so-called state tree of the network, which in turn contains all the data of all the smart contracts existing on the Ethereum network at that exact block. Amongst those contracts, AAVE, stkAAVE, and other voting assets are present, and within them, the balances and delegations of all Ethereum addresses. So the system “has” all the data needed to verify if somebody has voting power to participate in a proposal.

  On the other hand, Storage Proofs are a mechanism allowing to cryptographically proving that a piece of data is contained in a tree. In this case, they allow proving that a specific address has voting balance/delegation on the state tree of an Ethereum block. So what happens in practice when somebody votes is that the voter itself inputs how much balance of the voting asset/s he had at that Ethereum block (instead of the system reading it), together with a storage proof over the Ethereum block hash for that proposal. The voting Machine only takes care of cryptographically verifying the storage proof against the Ethereum block data, together with all extra validations (e.g. no double-voting) and accounting.

  In summary, the Ethereum storage layout and underlying cryptography provide the perfect mechanism for voting power aggregation and proving.

• The Voting Machine doesn’t deal with the proposal “success” validations. The Machine only cares about voting duration: simplifying, whenever the block hash of Ethereum is received, the voting starts and will remain open for a defined duration. Once that time period ends, voting is closed and YES/NO count is forwarded back to the Ethereum side of the Governance.

• Full circle with Ethereum as an Aave Voting Network in case of emergency. Even if not expected and not optimal cost-wise, if a catastrophic scenario would not allow any other Voting Network to operate, Ethereum itself will have its own Voting Machine, allowing the whole system to mirror Aave Governance V2.

Execution stage: Payloads Controller

Execution of payloads is one of the components on which the changes only slightly improve the current Governance V2. The main differences with the execution stage of v2 are:

• More cohesion of permissions, same granularity. Currently, the Aave governance has 2 types of proposals: Level 1 and 2, each one with its own success & vote requirements, as they hold permissions of the ecosystem with different criticality.
  On Aave Governance v3, the system still keeps the same granularity of Levels, but in addition, it allows to have in the same proposal, payloads with different Levels, by understanding which is the maximum level within the set and enforcing it. This was not possible on V2, which caused cases like proposals 165/166 of the rescue mission to be voted separately, even if being conceptually part of the same project.
• Pre-register payloads before creation. To make the rest of the system work better, now the payloads, apart from being deployed before proposal creation, need to be registered in the Payloads Controller.
  This allows getting an identifier of each payload that the proposer needs to submit on the creation transaction in Ethereum.

New proposal lifecycle

But how exactly the whole flow of a governance proposal works on Aave Governance V3?

Step-by-step flow on Governance v3

1. An address (can be the proposer or anybody else) creates the proposal payload/s, containing the logic that will be executed if the proposal passes, and registers it into the Payloads Controller of the target network.
   For example, if the proposal will list an asset on Aave v3 Avalanche, the payload will need to be deployed on Avalanche, and registered on the Payload Controller of Aave present there.
   Important to highlight that this is a permissionless action, as by registering the payload, there is no obligation of creating any final governance proposal using it.

   It is possible to deploy & register multiple payloads in multiple networks to be used on the same proposal.

2. When registering the payload on the Payload Controller of the target network, this will return a sequential identifier: 1 for the first payload registered, 2 next, and so on. This will be used on Ethereum to reference the payload to be executed on a proposal.

3. On Ethereum, the proposer with the required AAVE proposition power, creates the proposal by transacting with the core governance smart contract. The proposer will input in that transaction the payloads (and their networks) to execute, together with the Voting Network for the proposal.

4. After the delay period is over, the Aave Robot (more on this later) or any other Ethereum address will be able to activate the proposal. In practice, this means that the Ethereum block just before this action is taken as a “snapshot” of the Ethereum blockchain state, is to be sent to the Voting Network and used as a source of the voting power.

5. By using the Aave Cross-chain Infrastructure (more on this later), the information about the vote (Ethereum block hash mainly) gets forwarded to the Voting Network.

6. In parallel with step 5), on the Voting Network, a permissionless “settlement” of global data to be used for vote validation will need to be done, by the Aave Robot, or any other address: the Ethereum block hash, its state tree, and the state roots of the voting assets.

7. Voting starts on the Voting Network.

8. Everybody with voting power on Ethereum is able to vote on the Voting Network, via the Voting Machine smart contract.

9. After the voting period passes, the Aave Robot or any address can call a function on the Voting Machine to close the vote, not allowing anybody else to participate.

10. Voting results in the form of a count of Yes and No are sent to Ethereum, via the Aave Cross-chain Infrastructure.

11. Voting results arrive at the core governance contract on Ethereum, which after validating its success requirements, will queue them for execution.

12. Aave Robot or any other address will initiate the execution of the payloads.

13. This will send the payload to the corresponding Executor contract on Ethereum or any other compatible network (in this case, via Cross-chain Infrastructure), and start a time lock.

14. If the proposal is on a non-Ethereum network, the payload will be queued on the corresponding Payloads Controller.

15. Execution by Aave Robot or any other address, once the time-lock is finished.

Aave Cross-chain Infrastructure

Aave Governance V3 relies heavily on good cross-chain infrastructure, and during the development, we noticed that the existing cross-chain governance system v1, even if fully functional, could be heavily improved and generalized, so we created a new cross-chain communication layer for Aave: Aave Cross-chain Infrastructure.

As the new system is a project by itself, we will publish a separate document presenting all its details to the community during the following days, but in anticipation of that:

• Bi-directional communication. The Aave Governance V3 is by itself bi-directional, with for example initiation of proposal’s votes being Ethereum → Voting Network, while notification of voting results being Voting Network → Ethereum. The new Aave Cross-chain Infrastructure enables this, being direction-agnostic.
• Multi-bridge. The bridging ecosystem has and is evolving really fast during the last year, but still, it is quite new technology and Aave should have complete control at least in the selection of underlying bridges and replacement if required.
  The new system will add big flexibility and customization on which underlying (1 or more) bridges are authorized by Aave, with the possibility of defining consensus rules.
• Emergency escape. Without sacrificing decentralization, Cross-chain Infrastructure will include a newly designed mechanism to mitigate any potential lock-up caused by malicious underlying bridges.

Aave Robot

Behind the scenes, we have been working on the automation of permissionless actions around the Aave ecosystem, specifically on those related to governance, for which it is completely natural to have decentralized infrastructure whose cost is covered directly by the Aave DAO.

Given that it is already proven technology (e.g. used on Aave Proof of Reserve) and coming from a long-term partner, we have chosen Chainlink Automation as the backbone of this project, which we call Aave Robot.

We will release more extensive specifications soon, but in the case of Aave Governance V3, Aave Robot will take care of all the actions of permissionless nature around the system, being:

• Activation of the vote on the Ethereum core governance. After the delay post-proposal creation (1 day), an address needs to trigger the “activation” of the vote, which implies sending the corresponding block hash from Ethereum to the chosen Voting Network.
• Settlement of data on Voting Network from block hash. To make available to the Voting Machine on the Voting Network the state roots of tokens and other smart contracts used for voting power validation.
• Close voting on Voting Network. Once the voting period finishes on the Voting Machine, an address needs to trigger the “closing” of the vote, which implies sending the results back to Ethereum.
• Execution of payloads. Same as with Governance v2.
• Cancel of proposal not fulfilling proposition power requirements. Aave Robot will monitor continuously if a proposer has enough proposition power during the proposal lifetime, and if not, cancel it.

Miscellaneous aspects

• Voting from smart contracts (Gnosis Safe or other multi-sigs, protocols integrating the Aave governance). Voting from smart contracts on Ethereum will be entirely possible, but differently to the normal procedure of EOA addresses, voting will need to be done by calling an Ethereum smart contract, and the Aave Cross-chain Infrastructure will bridge the vote to the Voting Machine in the corresponding Voting Network.
• AAVE/stkAAVE optimization. Currently, the smart contracts of the AAVE and stkAAVE tokens include the logic required for the proper functioning of Aave Governance v2, mainly the recording of historic snapshots of balance and delegations.
  This will not be required anymore on Aave Governance V3, so part of the project is to upgrade these tokens, making all operations (e.g. transfer) way cheaper gas-wise.
• Meta-transactions focused. In order to be relayer-friendly, the smart contracts of Aave Governance V3 have been designed with actions-by-signature in mind (meta-transactions).

---

Activation steps & Timeline

Aave Governance V3 is a system touching an important part of the smart contracts of the Aave ecosystem, so its activation if/when approved by the community consists of multiple steps, which will most probably be grouped together.
A summary of what needs to be done before having it fully functional in production is the following:

1. Discussion of the community on the forum and Snapshot vote to signal for the upgrade.

2. Audit of the codebase by the security providers of the community, Certora, and SigmaPrime. This will include the following items:

   1. Aave Governance V3 smart contracts.
   2. Aave Cross-chain Infrastructure
   3. Upgrade of AAVE/stkAAVE/stkABPT/aAAVE

   Additionally, given its criticality for the whole ecosystem, we would like to request the community to engage in some extra security firms/researchers that BGD will evaluate and negotiate the budget with, even if the Aave DAO will cover the cost.

3. Once all security procedures are finished, BGD will deploy the necessary smart contracts.

4. Governance v2 proposal to activate the system, consisting of transferring all the permissions of the Aave ecosystem to V3.

We will keep publishing extra information and the codebase of the system in the following weeks. In the meantime, we appreciated all the feedback from the community!

[fig]

First, congrats on the hard work of the @bgdlabs team.

This is a long time coming and marks the transition of Aave into its next stage of maturity and community-led governance. I am particularly excited about the following sections:

@bgdlabs

Extremely cheap to vote

This feature will empower more teams like ourselves and other governance outfits (especially blockchain clubs) to continue to engage in Governance without fear of ballooning expenses.

While Aave’s governance is exciting and fast - it is challenging to sustain participation while spending ETH at rising rates, as AIPs increase in frequency as well

You may see @MarcZeller’s recent ACI six-month proposal which approaches the topic of compensation to offset his mounting Governance costs and efforts.

Next up, is the addition of more assets with voting power.

@bgdlabs

stkABPT and aAAVE (v3 Ethereum) will be supported at launch.

Will these assets hold proposition power too? And are they able to be delegated?

The addition of these two Aave-native (stkABPT and aAAVE) assets seem to introduce more diversity in Governance participants and potential delegators.

Lastly, the “Aave Robot” via

@bgdlabs

Permissionless automation under the hood.

We have experienced the complexities of managing an on-chain AIP from start to finish and believe it is a worthwhile investment to make it easier for proposing teams - encouraging more individuals to get involved.

@bgdlabs do you have initial candidates for the “Multi-Bridge” solution?

[bgdlabs]

@fig

Will these assets hold proposition power too? And are they able to be delegated?

All assets will be exactly the same from voting/proposition point of view, so the answer is yes.

@fig

@bgdlabs do you have initial candidates for the “Multi-Bridge” solution?

Aave Cross-chain Infrastructure is a system by itself, that’s the reason why we preferred to not include all the details in this post.
But yes, we have been evaluating and testing already multiple “bridging” solutions, and we will propose an initial list to start with in the follow-up post about Cross-Chain.

[dennisonbertram]

Congrats folks, this looks awesome. At Tally.xyz we built a POC of a similar system on L2s so we are excited to see storage proofs moving forward for reducing costs of voting.

Some considerations:

Removal of the L1 checkpointing mechanism

Upgrading the token to remove the checkpointing mechanism, also means that voting on L1 will be impossible. I personally think that might be dangerous for the v1 implementation of the system. While the advantage is appreciable (cost savings in Gas for AAVE tokens) it does mean that AAVE’s security will be entirely defined by the network chosen by the proposer, and the infrastructure required around the vote.

Considering that an attacker will have the luxury of deciding the place and time of an attack, in some ways we might be removing decentralization for gas costs savings (considering the council will be required to intervene).

If gas savings on token transfers are really important, would it not be worthwhile exploring incentivizing high-volume token movement to happen instead on L2 chains? If folks are primarily voting on L1, it’s reasonable to assume the tokens that folks hold to vote are not very liquid in the first place.

Network Selection

Why is it important to allow the proposer to choose the network where the voting will happen? Each network has different security guarantees, there is no financial value to the network selected, so why not have AAVE pick one? For tools like Tally.xyz which just finished a grant to support AAVE, the complexity of supporting multiple voting networks, is significant. For example, Polygon and Avalanche have very different block reorg characteristics.

Additionally since we’re using storage proofs, why not allow for voting based on AAVE token balance on any network? We should be able to prove L1 ethereum state as easily as L2 state, and supporting L2 state makes it more accessible to individuals who are gas price sensitive.

[dennisonbertram]

As another note:

If the goal of multi-chain governance is to reduce gas costs for participation, I think there might be a simpler solution. In 2023 when gas fees for voting in AAVE have been quite cheap, there have not been any votes with more than 200 unique addresses participating, with the majority of votes having an average of around 30 unique addresses participating per vote.

At this participation rate, would it not be simpler to simply sponsor the cost of gas for these voters? Tools like Tally, Boardroom and others can easily submit votes as signatures and the DAO can choose some sort of parameters at which to refund the gas cost or sponsor it entirely. (NounsDAO also does this). Indeed in some cases (back of the napkin math here) it might be cheaper in many votes for the DAO to simply sponsor the cost of voting versus the cost of the infra and bridging required for multichain.

[rafsolari]

Great explanation. Love the ambition! I wanted to dig in on the trust model a bit more. Maybe this will be covered in the post about AAVE Cross Chain Infrastructure, but I was wondering how the storage proof gets to the Voting Network.

Is there a trust-minimized way to check that the storage proof connects to valid block headers on all the chains that contain voting tokens? Or is the Voting Network trusting an oracle?

[bgdlabs]

Thanks, @dennisonbertram !

@dennisonbertram

Upgrading the token to remove the checkpointing mechanism, also means that voting on L1 will be impossible. I personally think that might be dangerous for the v1 implementation of the system. While the advantage is appreciable (cost savings in Gas for AAVE tokens) it does mean that AAVE’s security will be entirely defined by the network chosen by the proposer, and the infrastructure required around the vote.

It is not really the case with our system. Ethereum will be also a Voting Network, just not used in the “happy path” situation.
There must be anyway a cancellation mechanism for malicious proposals, and this will always work on Ethereum.

@dennisonbertram

Why is it important to allow the proposer to choose the network where the voting will happen? Each network has different security guarantees, there is no financial value to the network selected, so why not have AAVE pick one?

This is a behavior that can be easily changed if the governance itself decides so, but we support a more opt-in approach, as the field of networks is constantly evolving, and Aave should not simply choose one.

@dennisonbertram

For tools like Tally.xyz which just finished a grant to support AAVE, the complexity of supporting multiple voting networks, is significant. For example, Polygon and Avalanche have very different block reorg characteristics.

Interface-wise, the integration of a Voting Machine is exactly the same on all networks, especially in those with EVM-compatibility in terms of read/write smart contracts.
Additionally, we will of course open source utilities for proof generation for any integrator.
From our understanding, the reason why Tally.xyz didn’t support Aave governance v2 for the last 2 years was its differences from other types of governances like Compound’s, which actually are not really so meaningful integration-wise.

@dennisonbertram

Additionally, since we’re using storage proofs, why not allow for voting based on AAVE token balance on any network?

It is on our plans to potentially expand to this in the future, but scope-wise is pretty different due to chain-synchronization.

@dennisonbertram

In 2023 when gas fees for voting in AAVE have been quite cheap, there have not been any votes with more than 200 unique addresses participating, with the majority of votes having an average of around 30 unique addresses participating per vote.

We don’t really think that ~$5 to emit a vote is reasonable for all AAVE token holders, and definitely not something scalable.

[Kene_StableLab]

@bgdlabs has done an excellent job in designing the next iteration of Aave Governance.

Reducing governance costs is essential for frequent Aave’s governance participants, and we are glad to see this problem being addressed.

@bgdlabs

An Aave Voting Network is any blockchain network where the Aave Governance allows eligible governance voters (holders of voting assets or delegatees) to participate in voting for a certain proposal.

Cross Chain Governance would possibly redefine how we approach governance as participants, and we would be intrigued to see how this innovation plays out.

We are excited to see how these changes affect the Aave Ecosystem.

[bgdlabs]

@rafsolari

Is there a trust-minimized way to check that the storage proof connects to valid block headers on all the chains that contain voting tokens? Or is the Voting Network trusting an oracle?

The Ethereum block hash is passed from an Ethereum contract to the Voting Network via the Cross-chain Infrastructure, yes. So the trust resides in the Cross-chain system itself passing a correct message.

In parallel, the process of proving from a block hash its contents on the Voting Network is actually permissionless, because what is really important is which one gets used on the proposal for voting, and that is communicated via Cross-chain.

So let’s imagine block hash A is in process of being forwarded to the Voting Network. In parallel, let’s say that somebody submits block hashes B & C (correct ones) and proves their data.
Whenever the message arrives on the Voting Network, it will try to “query” the data of block hash A, no matter at all that B, C, or anything else is present on the contract storing the hashes.
Usually, this will not be a realistic scenario, because before block hash A arrives from Ethereum, actually, somebody would have proven A and its contents.

[dennisonbertram]

Thanks @bgdlabs for answering!

While I know your focus is on the AAVE governance specifically, it would be really exciting to see if the system could be generalized and made available to the wider ecosystem with low onboarding costs. Its really a big leap forward.

From our understanding, the reason why Tally.xyz didn’t support Aave governance v2 for the last 2 years was its differences from other types of governances like Compound’s, which actually are not really so meaningful integration-wise.

Correct. With a big upgrade like this, what are your thoughts about taking this opportunity to switch over to use the Governor system (now standardized universally as OpenZeppelin Governor) so that integration with tools like Tally.xyz is out of the box? It would allow for not just Tally but the other Governor compatible tools to work easily with AAVE.

The Governor framework is simple and modular, and thanks to the new voteWithParams() in the latest version of Governor, this system could easily be plugged in.

Obviously it’s a huge change in scope, but wanted to throw it out there!

[rafsolari]

Thanks! That’s helpful.

Can you share more about how the Cross-Chain Infrastructure passes the block hash?

Safety: how can I be sure that the system cannot somehow pass an incorrect block header? (I imagine a malicious header could contain fake voting power and hijack the DAO)

Liveness: how can I be sure that the system will always be able to pass a block header? (i.e. Are there services like the proof generator that can go down and make it impossible to pass a proposal?)

[bgdlabs]

@dennisonbertram

While I know your focus is on the AAVE governance specifically, it would be really exciting to see if the system could be generalized and made available to the wider ecosystem with low onboarding costs.

In terms of making it fully available for all other projects of the ecosystem, it is more of a decision of the Aave DAO itself, but we are fairly confident that will be the direction, following the current scenario where other projects already use Aave Governance V2.

@dennisonbertram

With a big upgrade like this, what are your thoughts about taking this opportunity to switch over to use the Governor system (now standardized universally as OpenZeppelin Governor) so that integration with tools like Tally.xyz is out of the box? It would allow for not just Tally but the other Governor compatible tools to work easily with AAVE.

The Aave ecosystem is quite big, and it is important that the governance layer is designed specifically for its needs. It is also a simple and modular system, even if using mechanisms that can sound more “esoteric” like storage proofs, but that are well know techniques on Ethereum, just under-utilized from our point of view.

Additionally, both we and other contributors help as much as possible with the integration of Aave governance facilities, together with Aave Grants DAO supporting financial teams like Tally (from what we are aware, receiving at least 2 grants since 2021, but not yet integrating Aave).
Obviously, some effort is expected in exchange, so when the integration takes years, it is not really because of the effort required, especially because Aave is the most active on-chain governance on DeFi, so it should be a must for any platform dealing with voting/delegation aggregation

So no, not really an option to swap to Governor.

[bgdlabs]

Really good questions @rafsolari !

@rafsolari

Safety: how can I be sure that the system cannot somehow pass an incorrect block header? (I imagine a malicious header could contain fake voting power and hijack the DAO)

Once the delay post-proposal creation is over, anybody can call an activateVoting() function on the core governance contract on Ethereum, which internally (on the contract itself) takes blockhash(block.number - 1), and passes it to the Cross-Chain Infrastructure. So taking the correct block hash is enforced fully on-chain by the smart contract itself.

@rafsolari

Liveness: how can I be sure that the system will always be able to pass a block header? (i.e. Are there services like the proof generator that can go down and make it impossible to pass a proposal?)

In terms of passing the block hash to the Voting Network, the liveness depends on Cross-chain properly working, which we consider as an assumption. And as described before, on that there is no proof/proof-generation involved.
Then, once the block hash “arrives” (or usually even before) at the Voting Network, it is true that an entity needs to settle the data of said hash, but that is 1) permissionless 2) Aave Robot will automatically do it, which liveness will boil down to Chainlink Automation being live.
To be more specific about proof generation, there will be no backend service involved, it will be just a frontend library connecting to Ethereum nodes.

[rafsolari]

@bgdlabs

which internally (on the contract itself) takes blockhash(block.number - 1), and passes it to the Cross-Chain Infrastructure. So taking the correct block hash is enforced fully on-chain by the smart contract itself.

@bgdlabs

the liveness depends on Cross-chain properly working, which we consider as an assumption

Ok, got it. Sounds like I should wait to read more about how the cross-chain infra works. As far as I know, getting an Ethereum block hash on another L1 like Avalanche or Polygon requires a bridge. I am trying to understand the bridge assumptions here, to see if Aave Governance is now vulnerable to a bridge hack.

[bgdlabs]

@rafsolari

I am trying to understand the bridge assumptions here, to see if Aave Governance is now vulnerable to a bridge hack.

Some points pretty crucial regarding the topic:

• Cancellation and expiry logic are always controlled on Ethereum. So imagine that a proposal is created on Ethereum, and when block hash gets bridged to a Voting Network X, even the Cross-Chain Infrastructure gets compromised (all bridges get compromised simultaneously).
  In this case, the Guardian will cancel the proposal immediately in Ethereum, and whatever happens on Voting Network X doesn’t matter anymore.
• The only major assumption is that Ethereum itself works. Even if (in practice impossible) all the Voting Networks would be somehow compromised, the entire voting process could happen on Ethereum, with a Voting Machine living there.

[dennisonbertram]

@bgdlabs

Additionally, both we and other contributors help as much as possible with the integration of Aave governance facilities, together with Aave Grants DAO supporting financial teams like Tally (from what we are aware, receiving at least 2 grants since 2021, but not yet integrating Aave).

As a note, one of those grants is actually for integrating AAVE, and we will have some announcements for that soon. ;-)

[dennisonbertram]

The only major assumption is that Ethereum itself works. Even if (in practice impossible) all the Voting Networks would be somehow compromised, the entire voting process could happen on Ethereum, with a Voting Machine living there.

Would this require the vote to be done on L1 Ethereum using Storage Proofs of L1 Ethereum? And what would the costs of that be? (Very intriguing idea!)

[bgdlabs]

@dennisonbertram

Would this require the vote to be done on L1 Ethereum using Storage Proofs of L1 Ethereum? And what would the costs of that be? (Very intriguing idea!)

Yes, correct, the Voting Machine is based on storage proofs no matter which Voting Network, including Ethereum.

In terms of costs, highly depends on the composition of voting assets of the voter, and if it is an EOA or smart contract. But for reference, for an EOA voting with 1 voting asset (average case), the cost would be ~2-2.5x in gas of a vote in Aave Governance v2, at let’s say 20gwei and current ETH price, in the order of $5-10

So it is something quite acceptable, considering that there should not really be almost ever that need, because it would mean that all Voting Network are malfunctioning at the same time simultaneously.

[dennisonbertram]

If at current gas costs $5-$10 for doing storage proofs on L1, thats a great result and I think totally acceptable.

In thinking globally, it would be exciting to understand how the Voting Machine works because I think we could help bring this tool to many other DAOs in the space.

Does Delegation work with storage Proof voting? We ran into some theoretical problems where we realized you had to prove the delegated amount of each delegator which could become very expensive. So if someone had a million delegations, you would have to prove the million delegations individually. How would that work?

[AaveLabs]

We are excited to see this come to the forum!

This upgrade, if approved by the DAO, would likely have a positive impact on voter participation by reducing voting gas costs, supporting further decentralization in the DAO and its activities.

Moreover, by enabling voting with aAAVE and stkABPT, voting becomes open to a wider range of participants. This, again, will have a positive impact on the decentralisation of the Aave DAO, and we are looking forward to seeing how this impacts Aave Governance moving forward!

Overall, this is a great step in the right direction for the Aave DAO as it continues to lead the way on decentralisation in the space. Kudos to BGD for their hard work.