Offset CSM Performance Oracle report weekday

Proposals
1

Problem

Currently, CSM Performance Oracle (CSM Oracle) reports are due on Fridays after the Accounting Oracle (AO) report. Combined with the fast-lane delay of 6 hours, we frequently end up waiting for the report until OOO hours for EU contributors. This makes it hard to resolve any report issues, both for Lido contributors and Oracle runners.

Solution

Offset the CSM Oracle report due day from Friday to Monday and set the fast lane delay to 1 hour to make the cadence more manageable for support.

Implementation

General plan

Changing Oracle report cadence is a bit tricky due to the design of the HashConsensus.sol contract. Since HashConsensus.sol does not allow a simple change of the report date, it is proposed to do the change in 2 steps:

  • Temporarily change CSM Oracle frame from 28 days (6300 CL epochs) to 31 days (6975 CL epochs) and set fast-lane slots to 0 (temporarily disabled).
  • Wait for the finalization of one report with the extended frame.
  • Change CSM Oracle frame from 31 days (6975 CL epochs) back to 28 days (6300 CL epochs) and keep fast-lane slots equal to 300 (1 hour).

Once the process is finalized, CSM Oracle report due day will be adjusted from Friday to Monday, and the fast lane will be shortened. The only unavoidable consequence is an extended frame in one CSM Oracle report, from 28 days to 31 days. This consequence should not have a significant impact on CSM Operators’ rewards or user experience.

Execution

By default, changes to the CSM Oracle frame config require an on-chain vote. Since the process is two-phased, corresponding on-chain votes have to be precisely timed. To overcome this inconvenience, we propose using a temporary contract with one-time-use operations to facilitate execution.

  • We deploy a contract with pre-set params to execute both phases of the transition.
  • We grant MANAGE_FRAME_CONFIG_ROLE on CSM’s HashConsensus: 0x71093efF8D8599b5fA340D665Ad60fA7C80688e4 to the deployed contract within an on-chain vote.
  • Once the vote is executed, we monitor the blockchain and invoke the Phase 1 method once the following CSM Oracle report is finalized to set the frame size to 31 days and set the fast lane to 0.
  • Once the CSM Oracle report with the extended frame is finalized, we invoke the Phase 2 method to reset the frame size to 28 days and revoke a role from the temporary contract.

Contract description

It is proposed to have a temporary contract to facilitate the operations. The contract code can be found here. The general idea of the contract is as follows:

  • Contract params and safety limits are set upon contract deployment.
  • Once the role is granted to the contract, Phase 1 can be invoked:
    • Check that Phase 1 was not invoked before.
    • Check that the report for the expected refSlot is finalized.
    • Check that the expected refSlot has not passed (otherwise, we will end up with the delayed report).
    • Change frame config to the one set for Phase 1.
    • Mark Phase 1 as executed.
  • Once the first report with the new frame config is finalized, we invoke Phase 2:
    • Check that Phase 1 was invoked before.
    • Check that Phase 2 was not invoked before.
    • Check that the report for the expected refSlot is finalized.
    • Change frame config to the one set for Phase 2.
    • Renounce the role from the contract.
    • Mark Phase 2 as executed.
      Invocation of both phases is permissionless. Internal limits ensure that the methods can not be called twice or called at an inappropriate moment in time.

Contingency plans

Phase 1 can not be executed due to a delay in the on-chain vote execution

We renounce the role from the contract using the fallback method, abandon the contract, and deploy a new one. In the next on-chain vote, we grant the role to the new contract and restart the process.

Phase 1 can not be executed due to a missed report for the expected refSlot

We renounce the role from the contract using the fallback method, abandon the contract, and deploy a new one. In the next on-chain vote, we grant the role to the new contract and restart the process.

Phase 2 can not be executed due to a missed report for the expected refSlot

We abandon the contract and apply the new frame config in the next on-chain vote or restart the process with the new contract to ensure that the desired cadence for the CSM Oracle report can be reached upon successful execution of both phases of the new contract.

Audits

The contract code is currently undergoing a security audit by MixBytes as a part of the GRAPPA initiative. The audit report, along with the deployment verification, will be published before the corresponding on-chain vote.

7 Likes
2

The contract described has been deployed on mainnet - Address: 0xb2B4DB14...239f110C1 | Etherscan. More information about deployment can be found in this PR - chore: CSM Two-phased Frame Config Update artifacts on mainnet by dgusakov · Pull Request #656 · lidofinance/community-staking-module · GitHub

Security audit report with the deployment verification will follow soon.

2 Likes
3

The audit by MixBytes is finalized and published:

5 Likes
4

The Vote #198 has started! :sparkles:

The vote will remain open for your “For” or “Against” input until the end of the main phase on January 23 at 11:09 UTC.

For instructions on how to verify the vote items, please follow this guide.

4 Likes