kyriediculous
commented
4 years ago Can you link your transactions. I bond roughly once every month (35 rounds give or take) and I never pay more than 50 cents for my bonding transaction which includes claiming earnings.
My answer from discord:
fees and rewards are memory variables. From an EVM level it doesn't matter if they are declared outside or inside the loop. In fact I believe the gist to be even more expensive by a marginal amount due to re-zeroing the memory slots.
I think there's other non-protocol optimizations we can do such as doing a better job of splitting up the transactions more.
A tx with a high gas cost (many rounds) and a low gas price has a very low chance of being included by miners, transactions with low gas cost and low gas price might have a better chance.
eg. Instead of 1tx with 2 mil gas at 5 Gwei , we could test whether 5tx at 400k gas and 1gwei would confirm faster than the first one. We can then reduce absolute cost of execution on the client side by leveraging miner economics rather than protocol changes
glints
Are there any plans on making the claim earnings function more gas efficient? Just called 150 rounds for 6$ (lowest possible fees). Got another address that needs to claim 3 rounds, which will set me back somewhere between 15$ and 20$ (again lowest possible fees on Metamask). This is not proportionate vs earnings. On first sight I'd think that updateDelegatorWithEarnings is the culprit, consuming so much gas.
Here are my suggestions; mind you, I have only looked at this particular function and I don't know enough of the complete inner workings of Livepeer, but maybe it helps. I think that the fees and rewards variable were being set every iteration of the for loop - though I'm not 100% sure about variable scope in solidity for loops - and I moved them out of the loop. This is completely untested, I don't have a Livepeer development setup. My transactions are still pending, so there might be a spike in gas costs as well.
gist link with suggestions for improvement