bonding: Implement active stake checkpointing

[victorges]

What does this pull request do? Explain your changes. (required) This is to introduce a checkpointing logic in bonding manager so that we can lookup historical information about any point in time. We need this in order to support an on-chain governance system with support for OpenZeppelin Governor abstractions. That is why it also implements the IERC5808 interface to plug into OZ Governor framework.

It is implemented as "external" to BondingManager as possible in a separate BondingVotes contract, but there were a couple places where BondingManager needed changes to start checkpointing its state.

Specific updates (required)

• Implement historical active stake snapshotting logic in the BondingVotes contract
• Make BondingManager call it to checkpoint the state where it needs to
• Tests for the checkpointing logic (unit / integration / fork)

How did you test each of these updates (required)

• Unit and integration tests with yarn test
• Fork test with forge
• Devnet on Goerli

Does this pull request close any open issues? Implements PRO-28

Checklist:

• [ ] README and other documentation updated
• [x] All tests using yarn test pass

[victorges]

@yondonfu @0xcadams Ok I think NOW this one is ready to go! :)

[victorges]

Ran the gas report on confluence branch (current) compared to this (checkpoints). Here are the reports, it seems to have increased around 200k gas on the bond/unbond functions due to the checkpoints that have been made. The checkpoint initialization itself also costs around 170k gas, which should still be relatively cheap on Arbitrum, but I haven't found a way to reliably calculate how it would cost considering the calldata cost on L1.

gas-report-checkpoints.txt gas-report-current.txt

[victorges]

OK @yondonfu @0xcadams I've addressed the feedback on your comments and this is ready for another review round. I have included some other changes as well that seemed necessary after the rounds of testing with the testnet and some discussions.

I recommend reviewing commit by commit, I avoided making a force push here not to lose history, and also isolated the less trivial changes in their own commits. As an overview of each:

• https://github.com/livepeer/protocol/pull/614/commits/0c41f78401a97ba4d92def55ba21f2c1820ab6b2: This addresses the comments about multiple checkpoints being made for the same account in the same transaction. It makes sure we only call it once in the end of all mutations instead on all code paths.
• https://github.com/livepeer/protocol/pull/614/commits/d518cd6058e87c7bc10c8ecfc05696e8c30655e8: This merges the BondingCheckpointsVotes contract from https://github.com/livepeer/protocol/pull/615 into the BondingCheckpoints contract here (renamed to just BondingVotes). This is mainly to allow it to send the ERC5805 events on changes.
• https://github.com/livepeer/protocol/pull/614/commits/ccc3ddf071a4c7b63fe22ca9531118b858a8b390: This is a change on the way that we assign voting power to accounts, to use their active stake at the end of the round instead of start. I didn't change any of the core checkpointing logic, just changed the voting power functions to read state from the next round instead, also using the nextRoundTotalActiveStake when querying for the next round to the current one.
  • After further testing with the OZ governor, I came to understand that their definition of "voting power at a timepoint" actually refers to the voting power at the end of that timepoint. This makes sense if you think about using block numbers as the clock, and is also reflected in the way that the OZ Governor works for some things like vote snapshotting: voting starts only after the "snapshot round", not on it.
  • A practical effect of this is that, in the previous implementation, if we had a votingDelay of 1 round the voting would be delayed in 1-2 rounds, but users would only really have 0-1 rounds to make any staking changes. Any staking changes made on the round before the voting actually starts would not be effective, since we would take the active stake from the start of that round for the voting power. Now we take it from the end (start of next round), and things work a bit more as expected.
• https://github.com/livepeer/protocol/pull/614/commits/d5062fe2db7d5037988c2f1a5989886d7ce087d3: This changes the behavior of most of the "read" logic in the BondingVotes contract to avoid reverting queries that could simply return a 0 value. There is only 1 specific case now where we will revert instead of returning zero, which is when there is no earnings pool on a transcoder's last reward round, which is an illegal state from the way that BondingManager works. This also fixed a lot of the redundant reverts with the SortedArrays implementation.
• https://github.com/livepeer/protocol/pull/614/commits/292f9542610d6f270966570135915a12ce6fd531: This one addresses the other review comments which were simpler so I just combined them in this commit.