Update some protocol parameters due to post merge reduced block times

Governance & GIPs Graph Improvement Proposals (GIP)
1

It’s been brought to our attention that some protocol parameters might require updating due to the recent Ethereum move to PoS last September.

With the merge the block time has changed from an average of 13.4 seconds to a fixed 12 seconds. This means that any protocol parameters that depend on or were set considering the pre-merge average block time are now slightly off their intended targets since essentially the clock is running faster. While this is not necessarily detrimental to the protocol it signifies a “silent” update and participants interacting with the protocol might experience unexpected behavior.

We need to evaluate if we want to update the parameters to match their original targets in days/hours. We have already done this process for the protocol’s issuance rate (see forum discussion and GGP) however there are at least two more parameters we should review: EpochManager.epochLength and Staking.thawingPeriod.

epochLength

This parameter sets the length of an epoch in blocks and it’s currently set to 6646 blocks on mainnet. Pre-merge this translated to epoch duration of ~24 hours; post-merge it means epochs are ~22.15 hours long.

This is most noticeable for example when considering the allocation epoch cap (maxAllocationEpochs), which is set in epochs so it changed from ~28 days to ~25,8 days. Anyone can close allocations after this period which means unaware indexers might lose out on rewards due to griefers closing allocations they thought were still safe.

thawingPeriod

Thawing period is the amount of time tokens are locked after unstaking and it’s also set in blocks; on mainnet it’s set to 186092 which means ~28 days pre-merge and ~25,8 days post-merge.

Suggested changes

Here are the proposed changes we would need to apply to bring these parameters back in line with their original target:

Parameter Current value Proposed value
EpochManager.epochLength 6646 (~24 hours pre-merge; ~22.15 hours post-merge) 7200 (24 hours post-merge)
Staking.thawingPeriod 186092 (~28 days pre-merge; ~25.8 days post-merge) 201600 (28 days post-merge)
7 Likes
2

We also ran into this issue in graphscan. Many things, such as calculating the API or displaying the duration of the allocation, depend on the number of blocks per epoch/day. We have already fixed this in the graphscan and support updating the parameters in The Graph protocol.

3

Update: the Council is voting about this topic in Snapshot Snapshot

3 Likes
4

Vote passed in snapshot. I’ll post the transactions here once the council executes them.

1 Like
5

Actually, from what I see onchain, last million blocks average block time is 12.07 seconds.
Which makes it ~7152 blocks per day and 200256 blocks per 28 days. Just saying.

6

Yep, looking at Ethereum Average Block Time. the block time is not precisely 12 seconds but close to it (varies from 12.0 to 12.1 almost).

7

Council updated the parameters, here are the txs:

2 Likes
8

Update transaction for the protocol on Arbitrum One (both parameters on the same tx): Arbitrum Transaction Hash (Txhash) Details | Arbiscan

3 Likes