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?)
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.
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.
Really good questions @rafsolari !
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.
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.
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.
Some points pretty crucial regarding the topic:
As a note, one of those grants is actually for integrating AAVE, and we will have some announcements for that soon. ;-)
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!)
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.
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?
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.
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.
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 !
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?
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?
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.
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.
Definitely on the range of 2 months.
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.
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?
No, there is no design flaw @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
@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.
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.
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).
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 
!
