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.
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.
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
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
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)
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.
The requirement for state in the L1 contracts to be frozen in this design has the following implications:
Given these implications, the following questions are important to answer:
The below sections aim to answer these questions.
Let LIP_73_ROUND
be the round at which the changes in LIP-73 go into effect.
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 ticketsLIP_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 yetLIP_73_ROUND
begins. As of this round, Os will not be able to call reward and redeem tickets on L1Steps 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:
[1] A full list of contract level changes to be enumerated separately.
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:
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:
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?
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.
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:
Infura-like provider - which introduces a third-party dependency
Self-hosted gateway - which I have no idea how it works.
Does anyone have any wisdom on self-hosting gateways on L2s like Arbitrum?
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.
LIP-73 has been moved into the 10 day Last Call phase during which additional remaining comments/feedback will be accepted!
So this equates to a reduction in the financial barrier to entry from 18 ETH to 5 ETH, which is a sizeable reduction in the barrier to entry for new Broadcasters!
This >72% reduction effectively makes it ~4 times easier to become a Broadcaster on Livepeer.
This would be great news for the public network, as it seeks to increase the diversity of Broadcasters on Livepeer!
Also, am I right in thinking that if my Dad is delegated to my O, and I migrate my stake to L2, then their LPT will move to L2 as well, with no LPT left on L1?
His stake would be migrated when your O migrates to L2 since an O will migrate with its entire delegated stake. Then, his stake would begin accruing rewards and fees if your O calls reward and redeems ticket on L2. Technically, his stake would be managed by a delegator pool contract on L2. Later on, he would be able to submit a transaction on L2 to claim his stake from the delegator pool as well as any owed rewards and fees.
Are there any plans for migrating undelegated tokens to L2?
What do we see as being the main pain points / confusion for people - e.g. users who are accustomed to things working in a certain way, and then being confused when this changes? Asking so that we can be prepared with some FAQs to send people to when they come to ask what’s going on
- Are there any plans for migrating undelegated tokens to L2?
A tokenholder will be able to move unstaked LPT to L2 using https://bridge.arbitrum.io/ which will use the LPT gateway contracts on L1 and L2 under the hood to facilitate the transfer.
A tokenholder will be able to move unstaked LPT to L2 using https://bridge.arbitrum.io/ which will use the LPT gateway contracts on L1 and L2 under the hood to facilitate the transfer.
From a cursory look, it seems like using the bridge to migrate will require two transactions: an approve
and a deposit
.
So then, I guess there would be a marginal advantage for an undelegated tokenholder to:
a) approve
and bond
on L1, and then be migrated to L2 when their O migrates (two L1 txns),
vs.
b) approve
and deposit
on L1, then approve
and bond
on L2 (two L1 txns + two L2 txns).
I wonder whether there’s some value in communicating this to undelegated tokenholders, to “get on board” before Livepeer moves to L2?
I’m curious whether this is actually an advantage given relative gas usage.
Scenario A would still require one L2 transaction (claim).
If deposit
in Scenario B is notable cheaper than bond
in Scenario A, then Scenario A might be more expensive. But I’m not sure whether that’s the case or not. Any insights @yondon?
The amount of txs don’t really matter. It’s the total amount of gas that those tx use that matters.
Approve txs on L1 use roughly the same amount of gas, so can be neglected. The txs on L2 in b) can also be neglected since they’re on L2 where fees are cheap
Bonding costs anywhere from 275k up to 400k gas. Depositing into the Arbitrum bridge costs ~200k gas (Arbitrum: L1 Custom Gateway | 0xcee284f754e854890e311e3280b767f80797180d).
So bridging the tokens instead of bonding and getting bridged is at least 25% cheaper
OK, thanks for the responses.
In general, I wonder how it might be possible to make life less difficult for the owners of the 2.6m addresses which received ~2.4 LPT in the MerkleMine. I guess the gas on L1 might get cheaper if more projects migrate transactions to L2s (??), but I think it’s worth considering whether this migration might effectively cut loose around 6m tokens, or ~25% of current supply, and if so, whether this is appropriate.