Tributary Release Protocol Upgrade


#1

Tributary Release Protocol Upgrade - 8/22/18

During round 1075 (starting at block 6192000 and corresponding to Wednesday August 22nd 2018), the Livepeer protocol will be upgraded as a part of the Tributary release milestone. For information about how this protocol upgrade affects the Livepeer node software see this post.

Changes

The following Livepeer Improvement Proposals (LIPs) will be included in the upgrade.

  • LIP-3: Ability To Update Registered Solver In LivepeerVerifier
  • LIP-8: Enable Partial Unbonding
  • LIP-9: Service Registry
  • LIP-11: Bond Event Details

The contract code that will be used can be found in the Livepeer protocol repository at Git commit hash 37da421d38a13313809c63b945953314eaaca455.

Over the last few months, the Livepeer core development team has discussed and solicited community feedback for these LIPs. Based on the response from community members, we believe these LIPs can offer immediate value for Livepeer users. LIP-3 will increase the security of the system as we continue R&D for a decentralized verification system. LIP-8 will enable users to withdraw a portion of their token rewards over time without disrupting their staking participation such that the liquid tokens can be used for valuable purposes such as community development. LIP-9 will enable a networking architecture that increases stability of the off-chain transcoding workflow. LIP-11 will provide third application developers with more information about staking activity allowing them to create better application experiences for users. These changes have already been deployed on the Rinkeby network where we have been testing these changes for the past few weeks.

For more information about LIPs check out the LIP repository and LIP-1 which describes the current process for including an LIP in a protocol upgrade.

Backwards Compatability

LIP-3

LIP-3 will not affect users as it is only relevant to how solver nodes are registered within the current verification system.

LIP-8

LIP-8 is a breaking change as it changes the BondingManager contract interface in addition to introducing the concept of partial unbonding. Users will need to update their node software in order to use the updated contract interface and use the new partial unbonding feature. Additionally, the following events are deprecated:

  • Unbond(address indexed delegate, address indexed delegator)
  • WithdrawStake(address indexed delegator)

And the following events are introduced:

  • event Unbond(address indexed delegate, address indexed delegator, uint256 unbondingLockId, uint256 amount, uint256 withdrawRound)
  • event Rebond(address indexed delegate, address indexed delegator, uint256 unbondingLockId, uint256 amount)
  • event WithdrawStake(address indexed delegator, uint256 unbondingLockId, uint256 amount, uint256 withdrawRound)

Applications that wish to filter for logs associated with the deprecated events will still be able to do so by constructing log filters using the deprecated event signatures.

Note: the partial unbonding feature will only be immediately available in the node - the explorer will be updated to support the feature soon after the protocol upgrade is complete.

LIP-9

LIP-9 is a breaking change as it introduces a registry contract that nodes rely on in order to execute the off-chain transcoding workflow. Users will need to update their node software in order to broadcast and transcode video with the new architecture.

LIP-11

LIP-11 is a breaking change as the following events are deprecated:

  • event Bond(address indexed delegate, address indexed delegator)

And the following events are introduced:

  • event Bond(address indexed newDelegate, address indexed oldDelegate, address indexed delegator, uint256 additionalAmount, uint256 bondedAmount)

Applications that wish to filter for logs associated with the deprecated events will still be able to do so by constructing log filters using the deprecated event signatures.

Upgrade Execution

The upgrade process will be executed in 4 steps:

  1. Deploy new contracts.
  2. Pause the Controller contract.
  3. Register the new contracts with the Controller contract.
  4. Unpause the Controller contract.

Step 1 can be executed at anytime before round 1075 as deploying the new contracts will not affect any of the existing contracts.

Step 2 will be executed at a block around 12 hours after round 1075 is initialized. Transactions submitted after this point will fail because pausing the Controller also pauses the rest of the contracts in the system! This 12 hour time buffer should allow the active transcoders for round 1075 to call reward() for that round before the Livepeer contracts are paused such that they do not need to worry about calling reward() after the contracts are unpaused. However, if any active transcoder happens to miss the reward() call before the contracts are paused, they will still be able to make the call after the contracts are unpaused.

Steps 3 and 4 will be executed shortly after the completion of step 2.

Anyone can follow the protocol upgrade process using this Github issue which will track the remaining deployment tasks necessary for completing the upgrade.

This post will be updated once the upgrade process is complete.

EDIT: This protocol upgrade was successfully executed during round 1075 and the mentioned changes are now live on mainnet!


Tributary Release: New Features and How It Affects You
Introduction to Partial Unbonding
Contribute to the Livepeer Desktop App under Community Node Grant
#2

For Transcoders to verify upgrade worked properly, from @dob in the Transcoder Discord channel -

To double check that things worked correctly…

A) Is your node running and did it automatically call reward today?

B) Check that your node’s address is registered in the serviceRegistry contract. (Little complicated because of the proxy/target contract).

Using mycrypto for example: https://mycrypto.com/contracts/interact

Contract address is: 0x406a112f3218b988c66778fd72fc8467f2601366

Contract ABI is the ABI from the target contract here:

https://etherscan.io/address/0x72d9dfa25f75a5f2c27b7336e643a559ae6aeb8e#code

Method is getServiceURI() And then you paste in your node’s address. It will show you the registered host/port.