LIP-73: Confluence - Arbitrum One Migration

Governance
1

This is the discussion thread for LIP-73: Confluence - Arbitrum One Migration. The LIP is currently a draft and is accepting community feedback as the content continues to be iterated on.

Note: The LIP currently does not specify a particular L2, but by the time it enters Last Call the expectation is that the LIP will be updated to reference a particular L2. The current implementation track that is helping to inform this LIP is using Arbitrum.

Update 12/23/21:

  • The title of this LIP has been updated from “L2 Stake Migration” to “Confluence - Arbitrum One Migration” to reflect updated scope in the latest design
  • This LIP does specify Arbitrum One as the L2 to use

Update 12/27/21:

  • LIP-73 has been moved into the 10 day Last Call phase
4 Likes
2

Does the L2 migration also migrate over the voting process for LIPs?

2 Likes
3

Question on the L2 migration - I understand that Arbitrum is being used during the evaluation.

Are Optimism and zksync also being evaluated as potential options?

And can anyone shed any light on how a decision will be made as to which network will be proposed in the last call for the LIPs?

Exciting times! Keep up the great work!

4 Likes
4

I think it could make sense to migrate the poll voting system to L2 such that poll contracts are created on L2 (lower transaction cost for poll creation as well as voting) and stake on L2 is used to determine the weight of votes (which could make sense if we expect a large portion of stake to migrate to L2). Planning on sharing a governance specific post soon.

2 Likes
5

And can anyone shed any light on how a decision will be made as to which network will be proposed in the last call for the LIPs?

Planning on sharing a post describing the framework that the team has been using to evaluate/consider existing L2s and that could be used to evaluate/consider future L2s soon!

1 Like
6

A few updates I’m planning on making to the current proposal:

  • Support specifying an amount of stake to migrate in the L1 Migrator instead of migrating all stake. This feature can be useful for users that have a large amount of stake and that wish to take precautions while migrating stake to L2 by starting with a smaller amount. An app that is integrated with the L1 Migrator can still set the default amount to an account’s entire stake while also giving the user the option to change the amount.
  • Support authorizing migrations using EIP-712 signatures as a replacement for the opt-out mechanism that is described in the current proposal. This feature makes it easier for orchestrators to use a web UI (i.e. the explorer) for migration without exporting/importing their local keystore files (which store their encrypted private key) since they can sign a message within the CLI and provide the signature in the web UI. A user could either submit a migrate tx directly using their delegator account or they could sign a message with a deadline (the last time at which the signature can be submitted on-chain) and any address could then submit the signature on-chain.

Find below a sketch of the code to support these features which is pretty similar to the OpenZeppelin EIP-2612 Permit minus a few tweaks:

struct MigrateMsg {
    // Address of delegator to migrate stake
    address srcDelegator;
    // Address of delegator to receive migrated stake
    address dstDelegator;
    // Address of orchestrator to delegate migrated stake to
    address dstOrchestrator;

    // Hints for updating the position of dstOrchestrator in the pool
    address dstOrchestratorNewPosPrev;
    address dstOrchestratorNewPosNext;

    // Amount of stake to migrate
    uint256 amount;
    // Deadline for signature to be used for migration
    // Optional: Only required if sig is set
    uint256 deadline; 
    // Signature to authorize migration
    // Optional: Only required if msg.sender != srcDelegator
    bytes sig;
}

mapping (address => uint256) public nonces;

function migrate(MigrateMsg memory _msg) external {
    if (_msg.sig != bytes(0)) {
        // Use nonce to generate MigrateMsg EIP-712 hash
        
        nonces[_srcDelegator] += 1;
        
        // Recover signer from signature
        
        require(
            block.timestamp <= _msg.deadline,
            "expired deadline"
        );
        require(
            signer != _msg.srcDelegator,
            "invalid signer"
        );
    } else {
        require(
            msg.sender != _msg.srcDelegator,
            "invalid msg.sender"
        );
    }
    
    bondingManager.migrateStake(_srcDelegator, _msg.amount);
    
    token.approve(l1Gateway, _msg.amount);
    
    // Call gateway
}

Another realization I had while considering the implications of supporting specifying an amount of stake to migrate is that if the delegator address on L2 already has a delegate then a migration should not modify that delegate. Otherwise, an address on L1 could modify the delegate of another address on L2 during a migration. In practice, we can just ignore the dstOrchestrator argument of a migration message in the L2 Migrator if the dstDelegator already has a delegate in the L2 BondingManager.

Updated the LIP in this PR.

2 Likes
7

Here is a proposal for an updated L2 stake migration design to address the drawbacks with the current design described in LIP-73 as described in this post.

Overview

The design consists of two phases:

  • Phase 1: Enable orchestrator migration to L2
  • Phase 2: Enable delegator stake claiming on L2

When the first phase begins, orchestrators will be able to submit a L1 transaction to migrate their entire delegated stake to L2. As soon as an orchestrator migrates to L2, its entire delegated stake will immediately be able to accrue LPT rewards and ETH fees on L2 if the orchestrator calls reward or redeems tickets on L2. Delegators will need to wait until the start of the next phase to actually claim their stake on L2. However, if a delegator’s orchestrator migrates to L2 before the start of the next phase then the delegator will be able to access LPT rewards and ETH fees accrued to its stake when it claims in the next phase. If a delegator wants to opt-out of having its stake migrated by its orchestrator it has the option of unstaking and withdrawing prior to the upgrade.

When the second phase begins, delegators will be able to submit a L2 transaction with a proof of their L1 state in order to claim their stake and fees on L2. Since delegators only have to submit a L2 transaction they can avoid paying L1 transaction costs. The delegator’s claimed stake will be added to its stake in the L2 BondingManager. If the delegator’s orchestrator migrated prior to the delegator’s claim then the delegator will be able to collect any accrued LPT rewards and ETH fees since the orchestrator’s migration.

The reason for having two phases is because in order to allow delegators to claim their stake on L2 without paying L1 transaction costs there is a snapshot of L1 delegator state created at the start of first phase that needs to be reviewed by the community (similar to the snapshot process used for LIP-52) before the snapshot can be used as a part of the delegator claiming process in the second phase. Since the snapshot needs to be reviewed before it can be used for the second phase there would be at least a week long delay between the start of the first and second phases.

Phase 1: Enable orchestrator migration to L2

First, let’s assume that there is a Confluence LIP that bundles together LIP-73 (L2 Stake Migration) as well as any other LIPs pertaining to Confluence (i.e. updates to how protocol inflation works) which is voted on by the community.

If the Confluence LIP is approved by the community and deployed then immediately after deployment the following happens:

  • The L1 Minter will transfer all of its LPT (i.e. all staked LPT on L1) across the bridge to the L2 Migrator so that it can stake in the L2 BondingManager on behalf of orchestrators and delegators that claim in the second phase
  • The L1 Minter will transfer all of its ETH across the bridge to the L2 Migrator so that it can credit fees to orchestrators that migrate and delegators that claim in the second phase
  • L1 protocol inflation is disabled to prevent the stake of orchestrators and delegators on L1 from increasing and L2 protocol inflation is enabled
  • The L1 BondingManager will be upgraded to disable all state modifying actions in order to prevent the state of orchestrators and delegators from changing [1]
  • A Merkle tree based state snapshot of L1 delegator state is created such that a proof of a delegator’s L1 state can be created based on the root of the tree
  • A LIP that references the above snapshot will be proposed and be the subject of a governance poll giving the community the opportunity to review the correctness of the snapshot off-chain

At the smart contract level, in order to allow an orchestrator to migrate its entire delegated stake to L2, a delegator pool contract can be deployed on L2 for each migrating orchestrator. The orchestrator’s delegated stake would be owned by the delegator pool contract and would begin to accrue LPT rewards and ETH fees while that stake is delegated to the orchestrator.

[1] Will need to ensure that any unbonding locks can be withdrawn, but not used to rebond to an orchestrator which would change the stake of the delegator.

Phase 2: Enable delegator stake claiming on L2

If the snapshot LIP is approved by the community and deployed then immediately after deployment, delegators will be able to claim their stake on L2 by providing a proof of their L1 state based on the snapshot.

If the delegator’s orchestrator migrated, then the L2 transaction submitted by the delegator would also take ownership of the stake and fees owed to the delegator by the L2 delegator pool contract for the delegator’s orchestrator. A pro rata share calculation can be performed to determine how much stake and fees from the delegator pool the delegator should be entitled to. For example, if the delegator owns 20% of the delegator pool’s initial stake then it is entitled to 20% of the delegator pool’s current stake (which includes accrued LPT rewards) and fees.

Rationale

While the snapshot mechanism to support delegator claiming on L2 is not trustless, the motivations for including it in this design are:

  • L1 gas prices make it especially tough for smaller delegators to migrate on their own to access value that they are entitled to within the protocol. Based on some rough back of the napkin math, we estimate that there could be as many as 2000+ delegators for which the L1 transaction cost for migration would exceed the value of their stake and as many as 4000+ delegators for which the L1 transaction cost for withdrawing fees would exceed the value of their earned fees. We estimate that avoiding L1 transaction costs altogether for these delegators could “unlock” a cumulative total as much as 1000+ LPT and 2+ ETH that could otherwise be inaccessible to delegators from an economic POV
  • There is precedent for using a snapshot process to unlock value in the protocol with LIP-52 given the ability for the community to properly evaluate the correctness of the snapshot off-chain before it is used on-chain

Questions for the community’s consideration

  1. Does the tradeoff with the snapshot based claiming process for delegators on L2 seem reasonable?
  2. Does the delay before delegators can claim on L2 seem reasonable given that if a delegator’s orchestrator migrates the delegator’s stake will already be accruing rewards and fees on L2?
6 Likes
8
  1. Does the tradeoff with the snapshot based claiming process for delegators on L2 seem reasonable?

In my opinion, Yes. Keeping fees low for delegators will be a big win for Livepeer, and this decision is based on today’s prices. What if gas + ETH is 2x, 3x, or god forbid 10x for when L2 goes live. My only concern would be a miscalculation or risk to having LPT unclaimed for a long period of time. Say 5,10, 20 years from now. If that risk is minimal or non-existent then I am all for a snapshot.

  1. Does the delay before delegators can claim on L2 seem reasonable given that if a delegator’s orchestrator migrates the delegator’s stake will already be accruing rewards and fees on L2?

The delay will be fine.

4 Likes
9

Thank you for taking the time to rework the design - I like it a lot!

You mean the tradeoff of it not being trustless? Since the snapshot will be public and can be reviewed, I don’t see an issue.

If the delay is only a week or two, that’s fine. But we need to make sure that we’re not talking months, since O’s can’t receive new stakes (and no new withdrawals can be started?) during the delay.

Will it be a problem in the long run that we’ll probably have some LPT in those contracts for a long time (due to inactive stakers)? Thinking about increased tx costs since additional stake calculations are necessary?

4 Likes
10

Thanks Yondon,

We agree with @Titan-Node and @vires-in-numeris concerning the tradeoff with the snapshot and the delay before delegators can claim.

Thats seems definitively to be the better solution.

5 Likes
11

hi Vires, I am Amit from Australia and new to LPT. I delegated 255 token on your link but my metamask wallet account got hacked and now all my LPT has been unstacked, which is due to be unbounded in 7 days. The thief has my meta mask key and has stolen $20k worth of token and my only hope is to get some help from you to resolve this. As the thief now has the secret phase therefore can transfer token from LPT to his account as soon as they are available to withdraw. is there anything we can do to stop it. I can prove the token were stolen as I pad around $12k in cash on Coinspot

in Australia. Is there anything you can do to help. My public key is as below.

0x903293187d3a43Aad7CA9e19E5dCE55A917f2bb9

1 Like
12

sorry everyone on this post. I don’t know how to contact Vires in private. Apologies, but i am looking for some support here. I have lost 3 years worth of hard earned money within seconds due to a hack. Is there any community support available. I will truly grateful if someone can please support. The Metamask team is not responding and I guess will not respond as it was hack on their wallet

1 Like
13

Hey Amit, sorry that happened to you. Unfortunately, it’s not in my (or the Livepeer team’s) power to do something here. Your tokens are in the staking contract and can only be controlled by your own address.

That said, there might be some solutions for your problem…

For your staked LPT: I see that you rebonded your LPT with this tx: Ethereum Transaction Hash (Txhash) Details | Etherscan
And at the moment, there is not enough ETH left on the account to send another unbond tx. So the attacker would need to send some ETH to the wallet first before he/she/they can initiate the unbond again - which they probably won’t do.
Now the issue is that they might run a bot that automatically scrapes all the ETH that you send to this address, so your LPT is essentially stuck. A possible solution might the the upcoming L2 update. It would automatically move your stake to an L2 (probably Arbitrum) where you’d have to claim it. It’s likely that the attackers don’t know that. So once the update happens, you could recover your LPT on the L2 where the attackers won’t check. Until then you’d have to regularly check that the attackers don’t send another unbond tx.

If they do that (and I see that you also have some GRT that is unbonding…), the second solution could be flashbots:

They have a whitehat service that tries to retrieve tokens from situations like yours: whitehat hotline | Flashbots Docs It basically works by bribing the block producers to execute your tx first. It’s best to fill in the form in the link provided and then join their discord to discuss further.

And for the future please ALWAYS use a hardware wallet as soon as it would hurt you if you lost the $ amount of crypto that you’re handling. If you have any other questions you can find me in the livepeer discord: vires-in-numeris#5324 (check the number as well and watch out for scammers, I won’t DM you first)

3 Likes
14

If the delay is only a week or two, that’s fine. But we need to make sure that we’re not talking months

The current idea is for the delay to be around 7 days (exact timing TBD, but around this duration).

since O’s can’t receive new stakes (and no new withdrawals can be started?) during the delay.

Just for the sake of clarification - technically, a O that migrates to L2 before the snapshot delay period is over can receive stake delegation if a delegator transfers liquid LPT to L2 and stakes directly in the L2 BondingManager.

Additionally, also worth noting that even with the snapshot based claim on L2 for delegators we’ll need to have support for delegators to submit a L1 tx to migrate their stake to L2 without using the snapshot to handle the scenario where a delegator is a contract (i.e. a multisig). Since L1 contracts do not necessarily exist at the same address on L2, a delegator contract would not be able to claim stake on L2 since the contract does not exist on L2. The solution to this problem is for the delegator contract to submit a L1 tx to migrate stake to L2 with the stake owned by a specified existing address on L2. I mention this because given support for this feature, another way for an O to receive stake delegation before the snapshot delay period is over is if a delegator chooses to migrate its stake to L2 on its own. However, unless a delegator is a contract, it could make sense for most delegators to just wait through the snapshot delay period in order to claim stake directly on L2 which should be cheaper since it doesn’t incur L1 tx costs.

Will it be a problem in the long run that we’ll probably have some LPT in those contracts for a long time (due to inactive stakers)? Thinking about increased tx costs since additional stake calculations are necessary?

I think the main impact in the current design of having LPT held by contracts on L2 on behalf of inactive/passive delegators whose Os do not migrate from L1 is that the LPT would be unstaked and thus not count toward the L2 participation rate (which influences the per round inflation rate adjustment). If an inactive/passive delegator’s orchestrator does migrate from L1 then the delegator’s stake would count toward the L2 participation rate since the orchestrator migrated its entire delegated stake (includes the delegator’s stake) to L2.

The additional calculations will only be necessary for a delegator once when it claims its stake on L2 and will not impact the tx costs of other users.

2 Likes
15

The requirement for state in the L1 contracts to be frozen in this design has the following implications:

  • Protocol inflation on L1 is completely disabled
    • Reason: Otherwise, the stake of accounts on L1 could increase after the snapshot is created. Additionally, this creates a stronger incentive to migrate to L2
  • Protocol inflation on L2 is supported
    • Reason: Otherwise, there is less of an incentive to migrate to L2
  • No fees can be earned on L1 and fees can only be earned on L2
    • Reason: Otherwise, the fees earned by accounts on L1 could increase after the snapshot is created. Additionally, this creates a stronger incentive to migrate to L2

Given these implications, the following questions are important to answer:

  • How will protocol inflation be disabled on L1 and enabled on L2?
  • How will work distribution transition to L2 once fees are disabled on L1?

The below sections aim to answer these questions.

Protocol Inflation

Let LIP_73_ROUND be the round at which the changes in LIP-73 go into effect.

  1. Before LIP_73_ROUND begins, the RoundsManager contract is upgraded such that starting at LIP_73_ROUND the initializeRound() function will be disabled meaning that rounds cannot be initialized. As a result, the round prior to LIP_73_ROUND will be the last round in which Os can call reward and redeem tickets
  2. Before LIP_73_ROUND begins, all protocol contracts (with required changes [1] for stake migration) will be deployed to L2 and will begin in a paused state meaning that no protocol transactions can be processed yet
  3. LIP_73_ROUND begins. As of this round, Os will not be able to call reward and redeem tickets on L1
  4. The L1 Minter will be upgraded to support transferring LPT + ETH cross-chain to the L2 Migrator to support the stake migration process
  5. The L1 Minter will transfer LPT + ETH cross-chain to the L2 Migrator
  6. The L2 Minter will set the starting inflation rate on L2 as the last inflation rate in the L1 Minter. As a result, the inflation schedule on L2 essentially picks up where the inflation schedule on L1 left off
  7. All protocol contracts on L2 are unpaused allowing protocol transactions to be processed

Steps 4-7 should happen in quick succession during a very short time period. We’re also looking into the possibility of executing these steps in a single action to minimize the length of the time period.

At this point, the stake migration process described in the previous post can begin. Note that since the protocol currently requires an O to wait until the next round after it stakes/registered to become active, after migrating an O will need to wait until the next round before it can call reward and redeem tickets.

Summary:

  • Os will be able to call reward and redeem tickets on L1 up until a designated round
  • From that round on, no protocol transactions will be processed on L1
  • The inflation schedule on L2 will pick up where the inflation schedule on L1 left off
  • Once the steps are complete, stake migration from L1 can start and anyone is also free to directly submit protocol transactions on L2
  • Once Os migrate to L2 they will need to wait until the next round in order to become active after which they will be able to call reward and redeem tickets

[1] A full list of contract level changes to be enumerated separately.

Work Distribution

Once fees are disabled on L1, Os will not be able to redeem tickets on L1. So, any work received by Os after this point and before migrating to L2 would be performed for free (since any winning tickets received would not redeemable).

At the moment, Livepeer Inc. expects to start operating Bs on L2 immediately after the LIP-73 upgrade is executed which will only distribute work to Os on L2. Additionally, there are no plans to add simultaneous support for L1/L2 in go-livepeer. So, if other B operators wish to operate a L1 B and a L2 B they can choose to do so, but the recommendation will be to just operate a L2 B.

Previously, the intent was for Bs to be able to distribute work to Os on either L1 or L2 as outlined in this post. The benefit of this hybrid work distribution approach was that it allows for a smoother network transition where Bs could fallback to Os on L1 if the active Os on L2 have insufficient capacity. However, the reasons for not using this hybrid approach at this time are:

  • In this latest design, Os on L1 cannot earn fees after the upgrade so they can only do work for free
  • Given the above, it feels unnecessarily complex to support such a hybrid approach as opposed to as a community focusing on moving to L2

With all that being said, such an approach could be considered in the future if another migration is needed in a scenario where fees are not disabled on the origin chain. In this case, the choice of disabling fees (and other protocol transactions) on L1 in order to support a snapshot based claim on L2 that lowers costs for delegators feels like a worthwhile tradeoff.

The current planned changes in go-livepeer to make this transition easier:

  • Allow Os to receive tickets if they are pending activation as opposed the current requirement where they need to be active to receive tickets. The reason for this change is to allow Os that are scheduled to be active in the next round after they migrate to L2 to immediately be able to accept work on L2 in order to minimize the period where an O cannot receive work at all. Since the O is pending activation and since tickets are valid for at least 2 rounds (the current ticket validity period), the O will be able to redeem any winning tickets as soon as the next round.
5 Likes
16

Question: will operating on a L2 enable Broadcasters to have smaller deposits / reserves?

IIUC, a Broadcaster must have enough funds deposited to be able to pay out the face value of a winning ticket to all Orchestrators in the active set, i.e. faceValue * 100 in the current case that there are 100 Os in the active set. Given a face value of e.g. 0.18 ETH, this requires 18 ETH, or ~$72,000.

Further, the faceValue needs to be higher if the cost of redemption is higher, in order to not lose too much transcoding fees to redemption fees.

If operating on a L2 reduces the cost of redemption, will this reduce the typical faceValue of a PM ticket (and assuming the number of Orchestrators in the active set remains constant), will this enable Broadcasters to have smaller deposits / reserves, thus lowering the barrier to entry for Broadcasters?

1 Like
17

The LIP has been updated in this PR to include the latest designs described in the following comments:

The title of the LIP has also been updated to “Confluence - L2 Stake Migration” to reflect the updated scope.

3 Likes
18

Also, another practical question: how do people expect to connect their nodes to the L2?

I’m assuming that the -ethUrl will need to pass in an RPC endpoint for the L2 network, and then I guess the options are:

  1. Infura-like provider - which introduces a third-party dependency

  2. Self-hosted gateway - which I have no idea how it works.

Does anyone have any wisdom on self-hosting gateways on L2s like Arbitrum?

1 Like
19

@videoDAC

If operating on a L2 reduces the cost of redemption, will this reduce the typical faceValue of a PM ticket (and assuming the number of Orchestrators in the active set remains constant), will this enable Broadcasters to have smaller deposits / reserves, thus lowering the barrier to entry for Broadcasters?

The reduced cost of redemption on L2 can help reduce reserve requirements by a bit for Bs, but I also think medium/long term updates to the payment protocol will also be desirable to further reduce the barrier to entry for Bs.

For now, an example to illustrate how lower redemption costs can impact reserve requirements:

At a gas price of 100 gwei, I estimate that the redemption cost should be somewhere around 0.02-0.03 ETH [1]. Suppose the ticket redemption cost is 0.025 ETH. Then, given the current typical faceValue of ~0.18 ETH, the overhead for redemption would be ~13%. If the gas price drops to 2 gwei on L2, then the ticket redemption cost should be somewhere around 0.0005 ETH. Then, given the current typical faceValue of ~0.18 ETH, the overhead for redemption would be ~0.2%. As this is less than the target overhead of 1% that is currently set by Os, a B could reduce its reserve in this scenario while still being able to cover lower faceValue tickets that still have an overhead of around 1% for redemption. In fact, given a redemption cost of 0.0005 ETH, a faceValue of 0.05 ETH would achieve an overhead of 1% and this would translate to a 0.05 * 100 = 5 ETH reserve for the B.

[1] I am assuming gas usage of 250000 for ticket redemption. In practice, the gas usage might be slightly different.

I’m assuming that the -ethUrl will need to pass in an RPC endpoint for the L2 network, and then I guess the options are:

Yep that’s right. The -ethUrl flag will be able to accept an L2 RPC endpoint which could be backed by a self-hosted L2 node or a hosted service like Infura/Alchemy. There are docs for running a L2 node. Since the Arbitrum stack is not as mature as the L1 Ethereum stack, there will be some kinks to work out for those that intend to run self-hosted L2 nodes (for example, the additional storage requirements for the L2 node given that there haven’t been many optimizations implemented yet targeting storage and connections with L1 nodes). So, for those that are interested in starting to experiment with running self-hosted L2 nodes would be interested in hearing about the experience and any learnings. The core team is also currently experimenting with running L2 nodes as well and will aim to share learnings from the experience.

2 Likes
20

LIP-73 has been moved into the 10 day Last Call phase during which additional remaining comments/feedback will be accepted!

2 Likes