As you might know, one round within the Livepeer protocol is currently set to 5760 mainnet blocks. Most people perceive that one round = 1 day, and that’s also how the 5760 blocks/round originally came to be: The average block time back then was ~15s.
Current situation: Since quite some time we’ve had around 13.2s between blocks (variable, see here for the most recent data: https://etherscan.io/chart/blocktime), which means that one round roughly equals ~21.1h.
That’s already ~12% more blocks per year than originally anticipated. But with the merge fast approaching, I think it’s finally time to revisit this parameter and maybe adjust it.
Why does the round time even matter? Well every round, new LPT get created and distributed among the stakers (of the O’s that do the reward calls). So if we have faster round times, we’ll see a higher LPT inflation*.
(*Assuming the inflation rate keeps changing between increasing/decreasing. If from now on, it will only decrease and then stay at 0, the total amount of LPT to get there won’t change with faster round times)
After the merge: The Ethereum block time will be a constant 12s. So if we keep the 5760 blocks/round we’ll see a new round every 19.2h after the merge. Compared to the current situation that would mean ~9% more rounds per year (compared to the planned 24h/round it’s 20% more).
Discussion: I’d propose to increase the rounds per block after the merge in order to keep the LPT inflation comparable to the current situation and to keep the perceived 1 round ~= 1 day somewhat intact.
Since we have a constant block time, we could set the blocks/round to 7200 to make it exactly 24h.
But I do actually like the slight variance of when a new round starts (i.e. caters for different time zones).
so instead, I propose changing it to either:
6600 blocks = 22h
6565 blocks = 1313min or 21.88h
I kind of like the increased variance of not having a new round start at the same minute every day, so I favor the 6565 blocks.
Thanks @vires-in-numeris for kicking off this discussion and highlighting how the constant 12s blocks post-Merge will impact the frequency of rounds and thus the frequency of LPT reward distribution!
As a reminder for anyone that is wondering why we should care about Ethereum (L1) block time even though the protocol contracts are now running on Arbitrum One (L2) - the contracts still rely on L1 block numbers because L1 blocks are produced at a near constant rate (and after the Merge, they will be produced at an exact constant rate) while L2 blocks are produced at a highly variable rate. The constant rate of production for L1 blocks is important because it allows the progression of L1 blocks to serve as a fairly reliable global measurement of time which is why rounds are measured in terms of a specific # of L1 blocks.
I agree with the proposal to increase the round length as an adjustment for shorter block times after the Merge. My reasoning is that outside of a few cases for a long period of the protocol’s history the average block time has hovered around 13.2s which maps to a specific LPT reward distribution schedule. A 9% increase in the # of rounds after the Merge and thus frequency of LPT reward distribution feels like a pretty significant departure from that status quo. I generally believe that a critical economic property of the protocol like the LPT reward distribution schedule should only be changed based on proper, informed analysis with a clear objective in mind. The sudden 9% shift that would be caused by the Merge does not meet that criteria so I would support an action to prevent that shift from occurring.
In terms of the value to increase the round length to, I like the idea of targeting the current status quo duration since that is what the community has been accustomed to. In practice, this would mean setting the round length to 6330 which would be 6330 blocks * 12 seconds = 21.1 hours. This would only be a minor difference relative to the suggestions in the OP, but setting the new round length value based on targeting the current status quo duration might be a a nice, easy, simple justification. Welcome other thoughts though.
I agree that a 9% shift would be a significant change without a clear understanding of what the consequences are and I think keeping the inflation around the same as it is now is a good idea
Any technical considerations to be aware of when changing this parameter? Is the previous value of the parameter unexpectedly baked into any assumptions elsewhere in the protocol code or client code?
It’s not critical to do a full pass audit of this in response to this post, but it certainly is something to keep in mind when making the param change proposal and review before the vote.
This is a great idea, thanks @vires-in-numeris, and the reasoning why not to have 24hr rounds is spot-on!
I have two contributions:
Let’s be cognizant that if we change the duration of RoundLength, this will also change the duration of UnbondingPeriod. While it might seem minor, it is a change to the economics.
Perhaps consider doing what is required to maintain the status quo, in terms of time duration of each round. e.g. today, if each block is approximately 13.2s and a round is 5760 blocks, then a round is approximately 76,032 seconds, which would be 6336 blocks post-merge.
I propose 6331 blocks… What is the reason you may ask?
Well 6331 is present in the Arbitrum Livepeer Token address
-------------------------------------------------- ---------------------------------------------------
0x289ba1701C2F088cf0faf8B3705246331cB8A839
Any technical considerations to be aware of when changing this parameter?
In addition to affecting the duration of a round and the LPT reward distribution schedule, the round length also affects:
The duration of the unbonding period (as mentioned by @chrishobcroft) because the unbonding period is denominated in rounds
The duration of a payment ticket’s validity period because the ticket validity period is denominated in rounds
The RoundsManager contract will also calculate round numbers after a round length parameter value update such that round numbers continue to increase correctly i.e. if the round length is updated at round N, the next round will still be N + 1.
Is the previous value of the parameter unexpectedly baked into any assumptions elsewhere in the protocol code or client code?
I don’t think there are any assumptions made in protocol or client code about the value of the round length parameter that would break if parameter value changes. A full, comprehensive review along with testing should/would be completed though.
Perhaps consider doing what is required to maintain the status quo, in terms of time duration of each round. e.g. today, if each block is approximately 13.2s and a round is 5760 blocks, then a round is approximately 76,032 seconds, which would be 6336 blocks post-merge.
Ah right my previous calculation assumed that a round is currently approximately 21.1 hours:
But, your calculation is simpler as it doesn’t make an assumption of the # of hours in a round and instead only makes an assumption of the approximate current average block time:
13.2s block times * 5760 blocks = 76032 seconds
76032 seconds / 12s block times = 6336 blocks
The last economic change to the protocol was updating the inflation change parameter. This update was implemented on Aug. 18th 2020, so pretty much 2 years ago. The exact average blocktime since then was 13.285642 seconds:
I therefore propose to set the new round length to 6377 blocks - which is the current status quo according to the data. If there are no objections, I’ll go with this number in the LIP.
Thanks for looking into the more exact calculation!
I verified that the average block time from August 18th 2020 - August 19th 2022 was 13.285642 seconds in this spreadsheet by importing the CSV file from the Etherscan average block time page and then calculating the average of all block time data points between August 18th 2020 and August 19th 2022 (inclusive).
The Merge is currently estimated to occur on 9/15. Given that technically speaking the date of the Merge could change, it would be safer to complete the LIP-83 poll before 9/15. If a 2 day buffer is added, the new date of interest is 9/13
Given a ~8.8 day voting period, in order to complete voting before 9/13, we would need to start the LIP-83 poll on or before 9/4
Given a 10 day Last Call period, in order to complete Last Call before 9/4, we would need to start the Last Call period on or before 8/25
The Livepeer Inc. eng team is going to start working on technical due diligence and testing this week to ensure that updating the roundLength parameter does not have any unexpected side effects. The team will aim to share initial insights in the next few days. If there are no immediate issues of concern that arise from initial due diliegence, given the simplicity of this LIP I think it would be reasonable to move this LIP to Last Call (though testing can and likely will continue into the Last Call period) this week to try to align with the timeline mentioned above.
LIP-83 is now in Last Call. The Last Call period will last for 10 days and will end on 9/17.
Note: Since LIP-83 is just now going into Last Call, even if it is approved it will not be executed until after the expected 9/15 date for the Merge. So, there will be a period of time after the Merge during which rounds will be slightly shorter.
I therefore propose to set the new round length to 6377 blocks - which is the current status quo according to the data. If there are no objections, I’ll go with this number in the LIP.
I get the math’s, but for me using the timing of the last update is somewhat arbitrary, and for me, 6377 is somehow ugly (unless you like a preponderance of 7s for luck!).
Can we consider making this somehow a “round” number (no pun intended), something easy to remember?
For example, rounding to the nearest 10 would be nicer, and give us 6380 (1 round = 21 hours 16 minutes).
Or something very nice like 6400 (1 round = 21 hours 20 minutes), which is a multiple of 2^6 (nice easy-to-remember binary-based thing).
We can also consider the opportunity to make this a precise number of hours, e.g. 21 hours = 6300.
Thanks for you input! Why do you think taking the date range between the last inflation change and now is arbitrary? IMO, the rate and its adjustment is working well so trying to keep it that way makes sense.
Personally, I prefer a data-based round number over something that looks pretty
On the explorer the focus is on the remaining blocks, but you can also see blocks/round - so you don’t even have to remember it.
6380: For me that would not be any nicer/easier to remember than 6377
6400: Yeah that would be easier to remember, but we lose some randomness due to it (every third round is at the same minute). On the plus side, the round start block would always be something round - a multiple of 6400.
6300: I think it’s a bit too far off the status quo
But I’m not convinced that it’s important to have something “nice” (who defines what’s nice anyways). But if the majority thinks otherwise, I’m happy to adjust the proposal.
The next step is for the Governor contract update that executes the roundLength update to be staged with a 51840 L1 block delay as described in LIP-25. A post will be shared here once the update is staged.
The Governor update for LIP-83 has been staged in this transaction.
The update will be executable at L1 block 15691216 on October 6th. The hash of this update is 0x7e55930248bf1754dac50ae70fd4b5b8e552aaca69d8ca7d0abb10f8abc04dbc which can be used to look up the execute block number in Etherscan in the “Read Contract” tab using the updates function.
---------------------------------------------------
