@SCBuergel1 This is an interesting request. There’s a couple of issues with using block numbers to identify snapshots for our contract.
First of all token transfers can happen many times in a block, so you need to define what a snapshot at a block number means: is it at the beginning of the block, the end, or some arbitrary point in the middle?
Secondly, our implementation of
ERC20Snapshot does not have snapshots for every block, snapshots are instead taken on demand by a function call. This is a big difference with the minime token, but it makes for a vastly more efficient implementation. As a consequence, there may not be a snapshot for every block. An on-chain governance contract would need to know that there is a snapshot for a given block number, otherwise the proposal would fail when it tries to read the snapshot balances. If you will let the governance contract know that there is a snapshot for a given block, you may as well just share a snapshot id with it.
Also keep in mind that there can be multiple snapshots within the same block so we would have to disambiguate what snapshot is referred to by a block number.
I have an intuition that this ambiguity can be an avenue for attacks agains the contract.
Note that the
snapshot() function returns the integer snapshot id. This means that a contract can take the snapshot itself when it is required, and store the id for later use.
In summary, there are several issues due to which I don’t think block numbers are feasible or a good idea for this contract. I would love to know more about the governance use case you have in mind so we can figure out whether it can be implemented using snapshot ids, or we can figure out other improvements to the contract that would make it possible.
One thing that I realize is not possible is to get the block number that corresponds to a snapshot id. This is something that we can easily add if it helps your use case.