livepeer / research

Organization of the current open research tracks within the Livepeer Project
MIT License
7 stars 2 forks source link

Aragon DAO Backed Transcoders #13

Open yondonfu opened 6 years ago

yondonfu commented 6 years ago

At the moment, a transcoder is commonly represented by an EOA that delegates LPT towards itself and is a registered in the transcoder pool maintained by the BondingManager contract. However, a transcoder can also be represented by a contract that implements an ACL that controls which EOAs can trigger actions within the BondingManager on behalf of the contract. In fact, this contract can be an application that is a part of an Aragon DAO.

This issue will serve as the basis for initial designs to enable an Aragon DAO backed transcoder.

Use Cases

Required DAO Applications

Workflow

Suppose the ACL is set up such that Alice's EOA is allowed to execute all function calls on the BondingManager through the Actor.

The DAO moves the required LPT for staking from the Vault to the Actor (which could inherit from the Vault such that it is able to manage tokens). Alice constructs the calldata for the following function calls:

The entire data payload is then submitted to the Actor app which executes each of the function calls represented by the individual calldata payloads. Each function call is executed with the Actor as the sender. Before executing the function call, the Actor checks with the ACL that the provider of the calldata (Alice) is allowed to forward the function call through the Actor. If so, the function call is executed. If not, the entire transaction will revert. The entire transcoder registration workflow can be completed within a single atomic transaction.

After registration, whenever Alice's transcoder node needs to perform an automated operation such as as call reward() or execute the claim-verify workflow, instead of submitting the transactions directly to the BondingManager, the node will construct the calldata for the transaction and submit it to the Actor which will forward the function call to the BondingManager.

When Alice's either calls BondingManager.unbond() + BondingManager.withdrawStake() or BondingManager.withdrawFees(), the LPT/ETH will be sent to the Actor. The LPT/ETH in the Actor can then be used for continued operations on the Livepeer network or DAO stakeholders can use the Voting app to initiate a vote to withdraw the LPT/ETH from the Actor to the Vault. The ACL could also have special permissions for BondingManager.unbond(), BondingManager.withdrawStake() and BondingManager.withdrawFees() such that DAO stakeholders can use the Voting app to initiate a vote to trigger one of these functions instead of relying on Alice to do so.

MVP

The simplest way to build an MVP of this design would entail:

A first step would be to try out this MVP with a fork of go-livepeer that is usable on Rinkeby.

One thing to note is that an open problem is how to deal with designated signers (see https://research.aragon.org/t/dynamic-permissions-for-organization-actions-with-signer-integration/116/20). This is not a problem for transcoders in the Livepeer protocol today because transcoder signatures do not need to be validated on-chain, but it is something to consider in future updates to the protocol if support for DAO backed transcoders is to be continued.

dob commented 6 years ago

This looks great. One thing I wonder about is how to make the eventual node implementation more generic so that it can just set a proxy to pass calls through, which would allow for different types of actor wrappers for different sorts of DAO experiments. Perhaps this abstracts to the same thing, but if not, then simply importing a single AragonDAO actor into the node itself may feel like a one off. Then again, it’s probably ok if it’s just set up in a plugins directory or something, enables me via a flag.


From: Yondon Fu notifications@github.com Sent: Thursday, September 13, 2018 9:15:49 PM To: livepeer/research Cc: Subscribed Subject: [livepeer/research] Aragon DAO Backed Transcoders (#13)

At the moment, a transcoder is commonly represented by an EOA that delegates LPT towards itself and is a registered in the transcoder pool maintained by the BondingManager contract. However, a transcoder can also be represented by a contract that implements an ACL that controls which EOAs can trigger actions within the BondingManager on behalf of the contract. In fact, this contract can be an application that is a part of an Aragon DAOhttps://hack.aragon.org/docs/aragonos-ref.html#2-kernel.

This issue will serve as the basis for initial designs to enable an Aragon DAO backed transcoder.

Use Cases

Required DAO Applications

Workflow

Suppose the ACL is set up such that Alice's EOA is allowed to execute all function calls on the BondingManager through the Actor.

The DAO moves the required LPT for staking from the Vault to the Actor (which could inherit from the Vault such that it is able to manage tokens). Alice constructs the calldata for the following function calls:

The entire data payload is then submitted to the Actor app which executes each of the function calls represented by the individual calldata payloads. Each function call is executed with the Actor as the sender. Before executing the function call, the Actor checks with the ACL that the provider of the calldata (Alice) is allowed to forward the function call through the Actor. If so, the function call is executed. If not, the entire transaction will revert. The entire transcoder registration workflow can be completed within a single atomic transaction.

After registration, whenever Alice's transcoder node needs to perform an automated operation such as as call reward() or execute the claim-verify workflow, instead of submitting the transactions directly to the BondingManager, the node will construct the calldata for the transaction and submit it to the Actor which will forward the function call to the BondingManager.

When Alice's either calls BondingManager.unbond() + BondingManager.withdrawStake() or BondingManager.withdrawFees(), the LPT/ETH will be sent to the Actor. The LPT/ETH in the Actor can then be used for continued operations on the Livepeer network or DAO stakeholders can use the Voting app to initiate a vote to withdraw the LPT/ETH from the Actor to the Vault. The ACL could also have special permissions for BondingManager.unbond(), BondingManager.withdrawStake() and BondingManager.withdrawFees() such that DAO stakeholders can use the Voting app to initiate a vote to trigger one of these functions instead of relying on Alice to do so.

MVP

The simplest way to build an MVP of this design would entail:

A first step would be to try out this MVP with a fork of go-livepeer that is usable on Rinkeby.

One thing to note is that an open problem is how to deal with designated signers (see https://research.aragon.org/t/dynamic-permissions-for-organization-actions-with-signer-integration/116/20). This is not a problem for transcoders in the Livepeer protocol today because transcoder signatures do not need to be validated on-chain, but it is something to consider in future updates to the protocol if support for DAO backed transcoders is to be continued.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/livepeer/research/issues/13, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAAoldKN9Ela1ezCS-GaBs3Sfd4LEmkaks5uassFgaJpZM4WoOQ1.

yondonfu commented 6 years ago

Yeah that's a good point - another set up that a transcoder might want to use is to proxy function calls through a staking wallet that implements authorization logic for cold/hot keys that can act on behalf of the staking wallet contract as mentioned here.

Perhaps the Aragon DAO Actor can share the same interface as the staking wallet such that the ABI encoding for transactions to be submitted for either type of contract can be the same...

jbrukh commented 6 years ago

Super exciting!