BGD. Aave Governance V3

[tuta]

Hey @bgdlabs team, very interesting post ! Looking forward to read the Cross-chain one as well.

I’m not following Aave Governance enough to know this, but I’m wondering if there really is a pain or need to decrease voting cost to the point of doing this whole revamp of the Governance process. Interesting design either way !

On the security side, you could try to go through a Code4Arena contest, it looks much better than traditional auditing.

Multiple Voting Networks

Though I understand your will to propose a global opt-in approach, my 2 cents is that having votes taking place on potentially different networks could quickly become hard to follow for the community, and adds unnecessary complexity on the dev side.

However, having the possibility to switch to another network if needed is great as it adds resiliency !

Future proof and new voting assets

The modular aspect of the design is great. Are there any specific requirements for an ERC20 token to be used as voting asset ?

On another note, do you have a rough ballpark on the timeline? Is it looking more like 2 to 3 months or 8 to 10?

[jengajojo]

Glad to see this proposal and thank you @bgdlabs for the same. This proposal definitely improves the governance experience by making it easier and cheaper to propose and vote. Will cross-chain voting via multi-sigs be possible?

[kohei]

I would like to express my sincere appreciation to @bgdlabs for their diligent efforts in developing Aave Governance v3. In my view, the issue of multi-chain and L2 governance will be of great significance and assume a key role this year. The decision to pursue this direction represents a significant milestone not only for Aave governance but for the broader ecosystem as well. I am keenly interested in exploring how Aave community can ensure accountability of governance across multiple chains in the future.

[bgdlabs]

@tuta

The modular aspect of the design is great. Are there any specific requirements for an ERC20 token to be used as voting asset ?

There are no ERC20 requirements to be considered as a voting asset if you are thinking from a generic standpoint. Precisely this is one of the main advantages compared with the current V2 version, that requires tokens to have especific logic to enable voting.

@tuta

On another note, do you have a rough ballpark on the timeline? Is it looking more like 2 to 3 months or 8 to 10?

Definitely on the range of 2 months.

[bgdlabs]

@jengajojo

Will cross-chain voting via multi-sigs be possible?

Yes, enabling any type of smart contracts voting was of course a requirement during the design phase. As we commented on the description of the system HERE, the procedure is technically a bit different than when EOA addresses (non-smart contracts) vote, but in nature, it is the same: completely permissionless and based on storage proofs.

[dennisonbertram]

Hello folks! @bgdlabs in reading the proposal again and following up on my earlier comment, I think there might be a critical flaw in the design that effectively kills delegation.

In this design, ERC20 snapshotting is removed to save costs on L1 tokens transactions. This also removes delegation, as delegation uses the snapshotting to track the total voting power of a Delegatee by tracking how much voting power is being delegated each time a token is transferred.

This becomes a problem when using storage proofs to verify voting power on a different chain, because now we need to proofs for:

A) Voters token balance

But also two additional storage proofs for each address delegating to that voter:

B) Delegators token balance
c) Proof Delegator is delegating to Voter

This problem becomes unbounded because you now need two storage proofs for every delegator, and the number of delegators is unlimited.

While most voters in the AAVE ecosystem don’t have as many delegators as in other ecosystems, even at current delegation amounts it can easily make voting on l2 more expensive than on l1 because the amount of calldata necessary for each proof multiplied by each delegator.

Additionally this is vector for a severe griefing attack, whereby and attacker can could prevent a voter from ever being able to vote by simply delegating to them so many times that it becomes impractical for the user to submit the required storage proofs.

You could get around this problem by not requiring a user to submit all their delegated voting power, but since a voter can only vote once, you get into a weird state by which someone for economic reasons might only be voting with portions of their voting power which could lead to other problems.

Socially, delegation is important for the scalability and long term success of hyperscale public infrastructure like AAVE. Removing it all together would, IMHO be a net negative for the protocol.

Am I wrong in my assessment that this design is not compatible with Delegations?

[bgdlabs]

No, there is no design flaw @dennisonbertram :

• Delegation is kept as on governance v2 in terms of UX.
• There is no additional gas cost added to keep delegation, even more, we optimize this aspect further than removing snapshots.
• Obviously the number of storage proofs required for voting is bounded, more precisely by the number of voting assets (AAVE, stkAAVE, aAAVE, etc), but nothing else. To simplify, if you are voting with AAVE, and you have both balance and let’s say 10 delegators, you need to prove exactly 1 slot.

[dennisonbertram]

Would you mind sharing the code for how this is done? It could be really useful for other projects as well in terms of optimization.

If we have both a balance, and 10 delegators, how are we updating the balance of each 10 delegators every time they transfer a token, without doing some version of a snapshot and then storing that value in a slot, on each transfer? If we’re proving it in exactly 1 slot, doesn’t that by default mean we are using a snapshotting mechanism?

When I look at the existing code we see this:

Showing we need to move delegate information on each transfer. Are you getting rid of this?

I think maybe the OpenZeppelin governor version might be more gas efficient, but I’m confused as how we can get around it all together, and how we can bridge that state without potentially many proofs.

Edit: quick ballpark I think OZ governor might be 20-30% more efficient

[bgdlabs]

@dennisonbertram
We will explain how every technical aspect works once all procedures (e.g. security) around the project are finished. Again, delegation dynamics keep working completely fine without sacrificing scalability anyhow.

@dennisonbertram

I think maybe the OpenZeppelin governor version might be more gas efficient, but I’m confused as how we can get around it all together, and how we can bridge that state without potentially many proofs.

As we already said in a previous answer, we are not going to use OZ Governor, as 1) Aave has its own requirements and 2) simply doesn’t fit in our design decisions.

@dennisonbertram

Edit: quick ballpark I think OZ governor might be 20-30% more efficient

Regarding efficiency, we have no doubt that OZ Governor is an efficient system, but it is pretty misleading to anybody to assert that without really understanding how Aave Governance V3 works, or even how we managed to solve some of the challenges (e.g. delegation).

[bgdlabs]

Following the timeline, we have published a Snapshot vote for the pre-approval of the community on Aave Governance v3 and the other system surrounding it (a.DI and Aave Robot v3, a similar version as the v2 approved).

The vote starts tomorrow, and follows the default configuration of the Aave snapshot space.
Participate !

https://snapshot.org/#/aave.eth/proposal/0x7e61744629fce7787281905b4d5984b39f9cbe83fbe2dd05d8b77697205ce0ce