Aragon DAO Backed Transcoders

[yondonfu]

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

• Transcoders can withdraw their earnings (LPT/ETH) into a DAO and DAO stakeholders can use a voting application to determine how to spend the funds.
• A DAO can designate an EOA to "act" on behalf of the DAO in the Livepeer network (since transcoders need to execute automated actions such as call reward() to mint inflationary rewards and the claim-verify workflow in order to earn transcode jobs fees) and DAO stakeholders can use a voting application to change the designated EOA if one is performing poorly.
• Following the previous point - experiment with mechanisms to select service providers. One example that has been proposed is a Vickrey auction.
• Encourage the building of a local ecosystem/community around a single DAO backed transcoder.

Required DAO Applications

• Generic Actor: From the BondingManager's point of view, this contract would represent the transcoder. An approved EOA would submit a transaction to this contract which then forwards (after first checking with the ACL if the EOA has the proper permissions) the function call to the BondingManager (with the actor as the transaction sender).
• Vault: Holds the DAO's valuable assets i.e. LPT/ETH
• Voting: Allows DAO stakeholders to create and execute votes for certain proposals i.e. transferring tokens from the Vault to some destination address.
• ACL: Maintains permissions for EOAs that can submit transactions through the Actor.

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:

• LivepeerToken.approve(BondingManager.address, N)
• BondingManager.bond(N, Actor.address)
• BondingManager.transcoder(rewardCut, feeShare, pricePerSegment)

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:

• Create a generic Actor app along the lines of what is described here
• Import contract bindings for the Actor app into go-livepeer so that the node knows how to submit transactions to the Actor
• Add a flag in go-livepeer --daoActorAddr which specifies the Actor address for a DAO. If this flag is used, the node should construct calldata that is submitted to the Actor instead of submitting transactions to the Livepeer contracts directly. By default, this would be disabled.

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]

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 DAO<https://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 * Transcoders can withdraw their earnings (LPT/ETH) into a DAO and DAO stakeholders can use a voting application to determine how to spend the funds. * A DAO can designate an EOA to "act" on behalf of the DAO in the Livepeer network (since transcoders need to execute automated actions such as call reward() to mint inflationary rewards and the claim-verify workflow in order to earn transcode jobs fees) and DAO stakeholders can use a voting application to change the designated EOA if one is performing poorly. * Following the previous point - experiment with mechanisms to select service providers. One example that has been proposed is a Vickrey auction<https://research.aragon.org/t/staking-pool-daos/136>. * Encourage the building of a local ecosystem/community around a single DAO backed transcoder. Required DAO Applications * Generic Actor<https://research.aragon.org/t/dynamic-permissions-for-organization-actions-with-signer-integration/116/12>: From the BondingManager's point of view, this contract would represent the transcoder. An approved EOA would submit a transaction to this contract which then forwards (after first checking with the ACL if the EOA has the proper permissions) the function call to the BondingManager (with the actor as the transaction sender). * Vault: Holds the DAO's valuable assets i.e. LPT/ETH * Voting: Allows DAO stakeholders to create and execute votes for certain proposals i.e. transferring tokens from the Vault to some destination address. * ACL: Maintains permissions for EOAs that can submit transactions through the Actor. 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: * LivepeerToken.approve(BondingManager.address, N) * BondingManager.bond(N, Actor.address) * BondingManager.transcoder(rewardCut, feeShare, pricePerSegment) 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: * Create a generic Actor app along the lines of what is described here<https://research.aragon.org/t/dynamic-permissions-for-organization-actions-with-signer-integration/116/12> * Import contract bindings for the Actor app into go-livepeer so that the node knows how to submit transactions to the Actor * Add a flag in go-livepeer --daoActorAddr which specifies the Actor address for a DAO. If this flag is used, the node should construct calldata that is submitted to the Actor instead of submitting transactions to the Livepeer contracts directly. By default, this would be disabled. 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 GitHub<#13>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAAoldKN9Ela1ezCS-GaBs3Sfd4LEmkaks5uassFgaJpZM4WoOQ1>.

[yondonfu]

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]

Super exciting!