Set indexer rewards destination using rewards pool

[abarmat]

Related to #450

• Indexer can set a rewards destination (Stake or RewardsPool) for indexing rewards after closing an allocation and for rebate claims
• A function called withdrawRewards() is available to claim accrued tokens from both indexing rewards and query fees.

The main differences is that it accrues any rewards on the stake or rebate pool depending on how rewards destination is set.

This version is about 4% more gas efficient on every close allocation call and is slightly more efficient when calling claim() without restake as it behaves the same way as close allocation. The reason for that is that transferring a token means doing two SSTORE, one to change the balance of the sender and another one for the receiver, additionally a CALL/SLOAD to get the graph token address. Instead it just use one SLOAD and one SSTORE to update the rewards pool.

Discussed in: https://forum.thegraph.com/t/rewards-destination-for-indexers-indexing-rewards/1279/64

[abarmat]

I'm posting new data based on new benchmarks as gas usage will depend if sending the token to an address with zero balance and also if the rewards pool is zero or not. SSTORE take 20k when empty and 5k when non-empty.

- direct destination-address-no-balance: 271898
- direct destination-address-with-balance: 256886
- rewardsPool no-balance: 265438
- rewardsPool with-balance: 250438

The difference is smaller between the two balance / no balance versions. Gas usage on one or the other implementation will depend very much on how the indexer behaves (the withdrawal flow and frequency they use)

[pi0neerpat]

Gas usage on one or the other implementation will depend very much on how the indexer behaves (the withdrawal flow and frequency they use)

I think its worth it to ask the community what they plan to do. In this implementation, the indexer will have to call an additional function withdraw. If they call this each time they close, then they will end up spending more gas.

For now at least, I think the simpler implementaiton in #450 is sufficient, and then we can add the pool later if people are concerned over saving 4% in gas.

[davekay100]

Only a few small comments

[davekay100]

With this setup - we make them withdraw all tokens in the pool at once.

I am thinking out loud - I think it is fine, tokens sitting in the rewards pool are doing nothing, they are not earning rewrds and they are in the staking contract. I don't see a reason why someone would want to withdraw partially

[davekay100]

Also to note, we let them withdraw to any address by providing a beneficiary address here. Maybe do we want to have require( _beneficiary != address(0)) ?

[abarmat]

That is a very good suggestion

[davaymne]

Would it be here "read" fucntion to see How many GRT is in the rewards pool available to withdraw? It would help Indexer to decide whether it is worthwhile to withdraw or not.

[davekay100]

contracts/contracts/staking/StakingStorage.sol

Line 90 in 17aaeda

mapping(address => uint256) public rewardsPool;

we get the read function automatically by making the storage vairable public

[davekay100]

maybe we could also check to see their rewards pool balance went up

[abarmat]

I'll add that test

[davekay100]

this was calculated on a spread sheet?

[abarmat]

Originally we calculated all rewards tests agains a spreedsheet with the formulas, based on issuance rate and blocks, we could make the spreadsheet public and link

[davekay100]

Gas usage on one or the other implementation will depend very much on how the indexer behaves (the withdrawal flow and frequency they use)

I think its worth it to ask the community what they plan to do. In this implementation, the indexer will have to call an additional function withdraw. If they call this each time they close, then they will end up spending more gas.

For now at least, I think the simpler implementaiton in #450 is sufficient, and then we can add the pool later if people are concerned over saving 4% in gas.

That's a great Idea!

[abarmat]

Archive as an alternative research solution