deploy: Delta production deployment scripts

[victorges]

What does this pull request do? Explain your changes. (required)
This is to update and create deployment scripts in order to update Delta (LIP-91 and LIP-92)
to production.

Specific updates (required)

• Fix dotenv and contract verification, as well as create a task to verify all deployed contracts
• Update ContractDeployer to support deploy-only (no register) mode
• Write deploy_audit.ts script to update the contracts in question and print required governance commands

How did you test each of these updates (required)

• Run the deploy over a local and testnets
• Run the deploy over a fork

Does this pull request close any open issues?
Implements PRO-32

Checklist:

• README and other documentation updated
• All tests using yarn test pass

[victorges]

FTR I've created a fork on Tenderly and ran the deployment script over there to ensure the expected behavior:

• Replaced the arbitrumMainnet RPC URL on the hardhat config with the the Tenderly fork URL
• Ran npx hardhat deploy --tags DELTA_UPGRADE --network arbitrumMainnet
• All transactions ran can be seen here: https://dashboard.tenderly.co/shared/fork/1fe3a622-01c6-4f3c-8bd7-c26903949c0f/transactions
• I only verified the Treasury contract for now since it's the only one where functions have been called

Will follow-up later with simulating the governance script to register contracts on controller.

[victorges]

@yondonfu FYI added 2 more utilities here:

• A task to renounce the admin role from the treasury post deploy/validations
• A document explaining all the deployment steps
  • (included a deployment validation that I made for the fork, tho haven't included the raw task script here)
  • This other fork test I made is documented in this branch tho I wasn't planning on opening a PR for it: vg/chore/delta-deployment...vg/fork-test-2

LMK if you'd suggest anything, like including that "verify delta deployment" task in here as well or if its fine like this. Tomorrow I plan on merging this and running the contract deploys. Will ping you about how we should merge this into confluence branch for the deploy.

[victorges]

FTR this is the second fork I made, where I ran both the contract deploys and the governance actions: https://dashboard.tenderly.co/shared/fork/2f6f7f38-4c86-4b24-a165-2b535747ba26/transactions

Unfortunately, controlling the block number of the fork is harder than I thought, so I couldn't advance the round to test treasury contribution. What I might do next is make a fork right at the beginning of a round, so I can initialize it myself after making the deploy.

The code changes for that deploy is on this branch: vg/chore/delta-deployment...vg/fork-test-2
Where I also wrote a task to verify the delta deployment and it is currently passing.

[yondonfu]

Unfortunately, controlling the block number of the fork is harder than I thought, so I couldn't advance the round to test treasury contribution.

You should be able to control the block number using the evm_increaseBlocks Tenderly RPC call when connected to the fork JSON RPC URL.

[victorges]

@yondonfu

You should be able to control the block number using the evm_increaseBlocks Tenderly RPC call when connected to the fork JSON RPC URL.

Yeah, I did do that and expected it to work, but it just stayed on the same block. I used this task and it has no effect no matter how many blocks I increase:

import {task} from "hardhat/config"
import {ethers} from "ethers"

const BLOCK_PERIOD = 12 // seconds

task(
    "evm-increase-blocks",
    "Helper task to increase the block number in the current EVM"
)
    .addOptionalPositionalParam(
        "blocks",
        "How many blocks to increase by (defaults to 1)"
    )
    .setAction(async (taskArgs, hre) => {
        const {network} = hre

        const provider = network.provider
        const blocks = parseInt(taskArgs.blocks ?? "1")

        await provider.send("evm_increaseBlocks", [
            ethers.utils.hexValue(blocks) // hex encoded number of blocks to increase
        ])
        // helpfully increase the time by 12s per block as well
        await provider.send("evm_increaseTime", [
            ethers.utils.hexValue(BLOCK_PERIOD * blocks) // hex encoded number of seconds
        ])
    })

Maybe it is increasing the L2 block number instead of the observed L1 block number. Couldn't find any docs on increase L1 block number on an arbitrum fork instead.

[victorges]

OK I managed to deploy an AdjustableRoundsManager as the RoundsManagerTarget on the fork, and am able to manipulate the observed L1 block number now as well :)

Was then able to adjust the block to the next round after deploy, initialize that round and run some reward calls observing the 10% of the rewards going to the treasury [1] :)

All transactions inspectable on the fork here [2] and the corresponding code/deployment registry on that same branch [3]

Pending now only updating the deploy docs here and merging the PR into delta branch. Then we can start doing the real thing :)

[1] https://dashboard.tenderly.co/livepeer/livepeer/fork/2f6f7f38-4c86-4b24-a165-2b535747ba26/simulation/6b163c5d-9c29-46a4-9cbd-31a8ce446d87
[2] https://dashboard.tenderly.co/shared/fork/2f6f7f38-4c86-4b24-a165-2b535747ba26/transactions
[3] vg/chore/delta-deployment...vg/fork-test-2

[victorges]

Unintended close 😅

[yondonfu]

Maybe it is increasing the L2 block number instead of the observed L1 block number

Ah I think you're right that's probably what is happening.