Call reward for another eth addr

[stronk-dev]

Adds the function to call reward for a given orch eth address. This is useful, since a throwaway wallet could then be used to call reward, keeping the main wallet more secure

Todo:

• Added a separate function cause the JS test library would vomit on function overloading, but can be fixed by modifying all tests...
• Add new tests

[papabear99]

Damn @stronk-dev that was fast! :)

[mikezupper]

I would also add the delegators would not be at the mercy of an Orchestrator to call reward. They can ensure they get all their daily LPT rewards by making the reward call on behalf of the O.

[dob]

I think the spirit behind the suggestion has merit and is certainly worth discussion. A couple comments:

• Any protocol functionality change like this which is not an urgent security fix to protect user funds would have to go through the LIP process. The LIP could be quick to write, but there'd have to be a discussion period and a vote.
• The breaking change to the interface of the public rewardWithHint function is not desirable, and probably a non-starter. Any existing tool, app, smart contract composition built against it would break. Instead you'd probably want to maintain the same interface, and refactor out the functionality to a helper that was called by both reward functions.
• To actually eventually merge a change like this, the tests would have to be updated and be passing.

Separately, I'll share some comments on the merit of O's not calling reward for themselves.

[dob]

As for O's not calling reward using their own keys...

1. I think it would definitely be a positive if O's could delegate signing power to another specified key within the protocol. That way the O key could be kept in cold storage offline, and it could be used only to grant and revoke power for a throwaway hot key.
2. But as for any key being able to call reward on behalf of an O, I do see a potential spiritual and future-proofing drawback:
   1. The daily reward call is part of the spiritual "cost" of running an O instead of just being a D. It's the daily connection to the protocol itself, and incurs a real cost not born by delegators. It's part of the reason why being a phantom O is an economically worse decision than just resigning and being a D - because to realize the rewards you need to maintain a process that calls reward every day and incur the gas cost. I'll acknowledge this cost isn't that high given scalable L2s like arbitrum right now, but it's not trivial.
   2. While not in place now, the daily reward call could also be extended to include some sort of other responsibility that the O is expected to take - for example signaling on governance actions, voting in slashing processes, etc. Like the previous point, if this daily check in is when the O connects to the protocol to do their duty as an O, then allowing anyone to do it on their behalf really limits the power of having a dedicated set of O operator experts helping to run and govern the network.

Just a couple thoughts for the longer debate.

[stronk-dev]

Yeah, I agree there might be a better solution. The issue is that the original Orchestrator keystore is vulnerable for calling reward or withdrawing/unbonding/etc. Lots of orchestrators have it connected through MetaMask and permanently stored on one or multiple servers. Once the key is compromised, it's basically game over unless you're lucky enough to have Delegators switch with you to a new wallet. Luckily hacks do not happen that often, but it would be good to find a way to keep the Orchestrator keystore as cold as possible

Maybe we can take it a step further than just assigning signing power, but also having rewards accrue at a set 'primary address'. This way the original keystore would only have to be used during initial activation and setting this primary address

[dob]

Yes, completely agree that addressing the security of the O key is a top priority here, rather than aiming to allow others to call reward on behalf of an O. It also seems highly achievable via some of the suggested means.

[0xVires]

1. I think it would definitely be a positive if O's could delegate signing power to another specified key within the protocol. That way the O key could be kept in cold storage offline, and it could be used only to grant and revoke power for a throwaway hot key.

This seems to be the way to go. Basically allowing an O to set a "worker" that has the same capabilities as the O itself (reward call, withdraw, adjust fees etc.) - apart from setting the worker address. This wouldn't weaken the O-Protocol bond and solve the most pressing issue: Having your O identity and delegators locked to a hot wallet.

Any estimates on how difficult that would be to implement? I feel like it shouldn't be too complex but I could be totally wrong...