Before, we were just using l1 token balances for voting power using the EVMSlotValueVotingStrategy. This did not allow delegation.
This PR changes the voting strategy to now query the checkpoints array within the token state. The last checkpoint in this array for a particular voter contains their delegated voting power at the current block number.
To obtain this voting power we can verify a storage proof of the storage slot where this checkpoint resides.
However we must ensure that the slot submitted does indeed correspond to the final checkpoint in the voter's checkpoints array. Since array values are stored contiguously in the contract storage, we can do this by additionally verifying that the immediately following slot is empty.
Refering to the solidity documentation we can derive the slot key of the final checkpoint as:
Before, we were just using l1 token balances for voting power using the
EVMSlotValueVotingStrategy. This did not allow delegation.This PR changes the voting strategy to now query the checkpoints array within the token state. The last checkpoint in this array for a particular voter contains their delegated voting power at the current block number.
To obtain this voting power we can verify a storage proof of the storage slot where this checkpoint resides.
However we must ensure that the slot submitted does indeed correspond to the final checkpoint in the voter's checkpoints array. Since array values are stored contiguously in the contract storage, we can do this by additionally verifying that the immediately following slot is empty.
Refering to the solidity documentation we can derive the slot key of the final checkpoint as:
We now submit 2 storage proofs with each vote which are verified in succession.
Here is an example vote on starknet goerli: 0x06efdb5b164cc77f03c8e692f457b1e27805ee7c59cdbfe7ce52eafd1775aa18