Orchestrator designated signers

[yondonfu]

Orchestrators should be able to designate different signer addresses for a few reasons:

• Multi node setups
• Improved key security since the master key controlling stake can be held in cold storage
• Different keys for different responsibilities i.e. one for signing transcoded results, one for calling reward, etc.

For previous discussion on this topic:

• Orchestrator specific: https://github.com/livepeer/LIPs/issues/7
• Focused on broadcasters, but the point about why we can't allow users to bring their own contracts for signature verification holds here as well https://github.com/livepeer/LIPs/issues/13#issuecomment-436807948 This was not as relevant in the V1 protocol because O/T signatures did not need to be verified, however, in Streamflow O's signatures will likely need to be verified as a part of on-chain verification (B would submit O's signatures with challenged segments).

Broadcaster designated signers is already being implemented as a part of PM (#262 #265). We can follow the same approach for enabling orchestrator designated signers.

There are a few options here to avoid logic duplication:

• Extract the signer approval/revocation logic into a SignerRegistry contract that can be inherited from any contract that needs to support this type of logic. Both TicketBroker and the staking contract could inherit from this contract
• Extract the signer approval/revocation logic into a SignerRegistry contract that serves as a global registry that TicketBroker and the staking contract would use to check signatures

I'm currently inclined to use the first approach to avoid additional external contract calls and the requirement for TicketBroker and the staking contract to know about an additional contract address.

[eladmallel]

@yondonfu can you please share a bit more thoughts on how designated signers should fit into staking?

[yondonfu]

O can have a master address that has the following privileges:

• Transferring LPT for staking
• Withdrawing LPT rewards and ETH fees
• Approving/revoking signer addresses

This master address can be secured in cold storage and only brought online when needed.

O's signer addresses can sign transcoded results that are sent to B. With the currently proposed verification flow that involves B submitting data on-chain for verification when challenging a segment, B will need to provide O's signature over the relevant segment data.

O's signer addresses could also be allowed to submit transactions that need to happen on a regular interval i.e. calling reward to mint new LPT. Alternatively, the master address could be a contract that serves as an account proxy that implements its own address authentication mechanism (see: https://forum.aragon.org/t/key-hierarchy-for-staking-accounts/78) - in this case, the signer registry in the staking contract could just used to verify signatures and the proxy contract can manage which addresses can call functions in the staking contract (a EOA would route the transaction through the proxy contract so that from the staking contract's POV it just sees a transaction from the proxy contract).

[eladmallel]

IIUC using the proxy approach would incur additional work on the client side to support interactions with such a proxy contract? And as mentioned in the link you shared, it also requires each user to deploy their own proxy contract?

In comparison I think it's fair to say the proxy approach can be more secure than designated signers, since in a proxy solution you could implement custom multisig and revocation policies that further mitigate the chances of account takeover and the damage of such an event.

My quick gut check says we should go with designated signers because it provides "good enough" security and simpler UX.

wdyt?

[yondonfu]

I think that is a good assessment of the pros/cons of the proxy contract approach. Another pro is the ability to wrap multiple function calls into a single atomic transaction i.e. wrap ERC20 approve + transferFrom.

We need the designated signers construction for the staking contract either way if we want to support signature verification from different signer addresses - we cannot securely outsource this responsibility to a proxy contract that the user defines due to the issues around signature invalidation. However, a user can use an account proxy contract if it wants to for the benefits described.

The question would be whether or not to implement logic in the staking contract to check if transaction sender is authorized to perform an action on behalf of some address (in addition to verifying signatures on behalf of some address which it already would need to do). My current preference is to let the user decide on that authorization logic i.e. if they want more complex authorization logic they should use an account proxy contract rather than an EOA. since this avoids additional complexity in the staking contract which just needs to verify signatures now.

[eladmallel]

(in addition to verifying signatures on behalf of some address which it already would need to do)

I'm not sure I'm following where would we verify signatures of designated signers?

I think I understand the point about BondingManager allowing msg.sender to be a signer that could perform certain financial operations (e.g. withdrawFee) on behalf of the cold wallet O account. But IIUC that's distinct from what you're saying above, so I'd love to connect to a specific example of signature verification that you have in mind?

thanks!

[yondonfu]

I think I understand the point about BondingManager allowing msg.sender to be a signer that could perform certain financial operations (e.g. withdrawFee) on behalf of the cold wallet O account. But IIUC that's distinct from what you're saying above, so I'd love to connect to a specific example of signature verification that you have in mind?

I'll refer to this as sender based authentication (used to determine if a sender can call a function). We also have to handle signature based authentication.

Signature authentication for O could look like:

• O approves a signer address in BondingManager
• The signer address is used to sign transcoded results sent to B
• B wants to challenge a segment so it provides the signature when triggering on-chain verification and indicates the ETH address that identifies O
• The on-chain verifier will check with the BondingManager if the signature provided is valid for O's ETH address i.e. if O approved it

If we have a signer registry to handle signature authentication for O, we could use that same registry for sender based authentication as well. But I am suggesting that perhaps for lowering complexity within BondingManager and maintaining separation of concerns it would be better to not do that and instead have a user deployed account proxy contract deal with sender based authentication.