Design a mechanism to reduce the need for two network upgrades for F3 activation to one

[masih]

Background

To activate F3 two network upgrades are required:

1. to allow a period of passive testing to determine the final manifest configuration values, e.g. delta, rebroadcast backoff, lookback etc.
2. making a release with those empirically determined values to then upgrade the network with.

As a two step concept there is no getting away from this from engineering perspective; it is required to measure things and perform experimentation in order to determine network wide constants.

But logistically, the process can be simplified such that those values can be updated without requiring 2 network upgrade: by delegation of control to a party/committee to set those variables at runtime.

Done Criteria

There is a "design document" that outlines how a tightly scoped, easily abortable, and fully transparent mechanism can be built into go-f3 / Lotus to allow for a one-time setting of F3 activation parameters that bypasses the time / coordination cost of a network upgrade.

This document should include:

1. Pseudo code of the smart contract
2. Who would have access to the smart contract
3. List of changes required in Lotus such that F3 parameter values are not required at build time
4. Sequence of events for "releasing" and then using this mechanism (e.g., smart contract published, contract addressed integrated in Lotus RC, mechanism tested in Calibration, etc.)
5. Estimate for the amount of engineering effort to pull this off

Why Important

This is even being considered because of the way it could save the network the time and coordination effort that goes into a network upgrade. Once the design is completed and communicated to the community, the community can still reject it and we fallback to doing a network upgrade.

We need to do this design phase so:

1. Community can accurately assess the idea
2. We can make realistic estimates and then timelines, given this will need to be done in concert with a larger nv25 upgrade train that has other FIPs. (As an extreme, if adding this mechanism took an extra calendar month from an engineering perspective, it would we become clear that it's likely not in scope for a mid-February 2025 nv25).

Notes

1. This issue isn't tracking all the related comms for such an effort.
2. The basic idea is to set up a smart contract that would allow a specific (mutisig) key to set manifest values for the network by some deadline and only once. After they are set, that smart contract would lock itself into an immutable config.

Tasks

• Publish a FIP Discussion: Delegation of Authority for F3 Parameter Setting FIPs#1102
• Investigate if/how can get smart contract parameter setting when a node isn't listening for EVM events #821
• Publish a FRC
• Enumerate initialization steps

[BigLep]

Thanks for creating this issue @masih. I update the issue description a bit by giving it done criteria that is focused on creating the design. There will be other/followup tasks for communications, implementation, etc.

[BigLep]

2025-01-10 standup update: will have initial design for review 2025-01-13.

[BigLep]

FIP discussion posted: filecoin-project/FIPs#1102

Post to #fil-implementers: https://filecoinproject.slack.com/archives/C05P37R9KQD/p1736971640483289

[BigLep]

@Kubuxu : I added one more task to this to make sure we have identified all the initialization steps. I'm thinking about things like:

Deploy f3parameters contract to Calibration
Collect public keys for maintainer groups
Create maintainer multisig in Calibration
Transfer f3 parameters ownership to maintainer multisig

Similar for mainnet

Are there other things we'll need to do?

I also want to include steps like:

• Ensure it's auditble who the signers are on the multisig (I guess they just look tthe create safe multisig contract message params)
• Where we are posting contract verification

Maybe we can talk during 2025-01-30 standup and I can get this documented.

[BigLep]

2025-01-30 standup conversation
We can deploy multisig first then deploy
or reverse
That is fine because there is transfer functionality

After we deploy
The we have the address, it can be embedded in Lotus
Address can be the same
Just to make sure the expiry is the same

Need to collect the public keys
Need to create the safe constract
Creating the safe contract through code is possible but will be a time sink
The transparency is the message on chain with the contract parameters
You can also view it on safe.filecoin.io

There is a task that prints the outputs that need to use with the safe contract
We'll save the manifest in the repo
Ask implementersto run tools to generate the bytes

We can propose the message
Other implementations can cross verify we proposed the right message

They will then go to the safe UI to approve the message

FilOz will create an account that is just for the f3 parameter activation. Store in 1password.

(I'll write this up better after)