From ea552efcf726192173db9ef52d72d80fc55e9ae7 Mon Sep 17 00:00:00 2001 From: Steve Loeppky Date: Thu, 30 Jan 2025 22:28:00 -0800 Subject: [PATCH 01/13] FRC for Delegation of Authority for F3 Parameter Setting This is the FRC accompanying https://github.com/filecoin-project/FIPs/discussions/1102 --- FRCs/frc-f3_delegated_authority.md | 431 +++++++++++++++++++++++++++++ README.md | 1 + 2 files changed, 432 insertions(+) create mode 100644 FRCs/frc-f3_delegated_authority.md diff --git a/FRCs/frc-f3_delegated_authority.md b/FRCs/frc-f3_delegated_authority.md new file mode 100644 index 000000000..4fc716ed0 --- /dev/null +++ b/FRCs/frc-f3_delegated_authority.md @@ -0,0 +1,431 @@ +--- +fip: "" +title: Delegation of Authority for F3 Parameter Setting +author: "@Kubuxu @BigLep" +discussions-to: https://github.com/filecoin-project/FIPs/discussions/1102 +status: Draft +type: FRC +created: 2025-01-30 +requires (*optional): FIP-0086 +# category: +# spec-sections: +# - +# - +#replaces (*optional): +--- + + + +# FIP-Number: Title + +## Simple Summary + +Avoid a full network upgrade for setting F3 activation parameters by instead delegating parameter setting to the Lotus, Forest, and Venus implementation teams, who will set these parameters on-chain for one-time use on mainnet. + +## Abstract + +This FRC proposes introducing an on-chain smart contract that can manage F3 parameters dynamically. This contract would be owned/controlled through a multi-signature mechanism requiring consensus from all three major Filecoin implementations (Lotus, Forest, and Venus). The contract would allow for a one-time parameter update based on mainnet passive test results, effectively combining what would have been two network upgrades into one while maintaining security through multiple stakeholder approval, full onchain transparency, and built-in time delays for community review. + +## Change Motivation + +The Fast Finality (F3) feature for Filecoin requires comprehensive testing under mainnet conditions to ensure its effectiveness and reliability. These live network conditions are challenging to replicate in test environments, and thus, the parameters for F3 are contingent upon the results of these mainnet tests. By default this necessitates two distinct network upgrades: one enabling Storage Providers to update their software for testing purposes, and a subsequent one for setting the finalized parameters. At least as of 202501, network upgrades are "costly" in terms of the multiple party coordination and for good reasons take a couple of calendar months to fully execute in non-emergency situations. Implementers who are taking on delivering F3, as already approved by the network in [FIP-0086](../FIPS/fip-0086.md), want to deliver the benefits of F3 network faster while minimize the "people resource" consumption on the network and their teams. (See https://github.com/filecoin-project/go-f3/issues/800 for more info.) + +### Terminology + +*Below are common terms used through the rest of this document.* + +- nv25 - The network upgrade that will deliver the next batch of F3 protocol and code changes, which we also expect is the last network upgrade for activating F3 on mainnet. +- "the implementations" - This means the main active Filecoin implementations: Lotus, Forest, and Venus. +- “the smart contract” - This is the smart contract referred to in this proposal that contains the “good parameter set” and the bootstrap epoch. The source code will live in [filecoin-project/f3-activation-contract](https://github.com/filecoin-project/f3-activation-contract) and its address and owner address will be hardcoded in Lotus/Forest/Venus nv25-compatible releases. The owner address is "the multisig contract" discussed below. +- “good parameter set” - This is the set of F3 configuration parameters that will be determined as part of [nv25 mainnet passive testing](https://github.com/filecoin-project/go-f3/issues/802). This parameter set will have sustained demonstrated success in mainnet. It will be stored in "the smart contract" as DEFLATE compressed JSON data, and it will be consumed by "the implementations". +- “the multisig contract” - This is a standard off-the-shelf multisig EVM contract that will be the owner of “the smart contract”. As a result, “the smart contract” will only accept updates from this multisg contract. This is the mechanism by which we accomplish multi-stakeholder consensus of the Lotus, Forest, and Venus implementation teams. + + +## Specification + +To streamline this process and enhance flexibility, we propose delegating the authority for setting F3 parameters to an on-chain contract so F3 activation in mainnet can be accomplished with one network upgrade rather than two. This contract will be responsible for managing a predefined set of parameters and making go/no-go decisions regarding their implementation. + +### On-Chain Contract for Parameter Management +- Move the parameter setting from the build phase to an on-chain contract, allowing for a singular dynamic update based on real-time test results. +- This contract will live in a new public repo: [filecoin-project/f3-activation-contract](https://github.com/filecoin-project/f3-activation-contract) + - Note: while we’ll restrict write access to the repo to Lotus, Forest, and Venus maintainers for general repo hygiene, repo write access isn’t the chief concern. The key decision is the groups that have the ability to update the state of the published mainnet contract (discussed more below). + +### Controlled Update Mechanism +- Parameter updates will require full consensus amongst each of the Filecoin implementations: Lotus, Forest, and Venus. This is implemented with a multisig requiring 3 of 3. +- Each of the three implementation teams will send signed messages to authorize changes, ensuring security and agreement among stakeholders. + +### Finalization and Self-Disabling +- This would have “used once finalization”. The contract does not permit further updates if the currently set bootstrap epoch is in the past. +- It is designed to automatically disable itself after a period of six months from contract creation, ensuring that any changes are deliberate and well-considered, while preventing indefinite alterations. + - This means the bootstrap epoch must be within 6 months months of the contract creation. + - If for some reason F3 still isn’t activated within this 6 month window, a network upgrade will be required to update client software to point to a new or updated contract. + +### Content of the Dynamic Manifest +- The expected content of the dynamic manifest is expected to comply with the [schema below](#dynamic-manifest-schema). +- Some of the most important attributes include: + - **Bootstrap Epoch:** Specifies the activation time, set no sooner than 72 hours from message transmission. (This is intended to give the community an additional window to react in case there late-discovered issues with the parameters/rollout. See [Proposed sequence / example timeline](#proposed-sequence--example-timeline) for more context.) + - **EC.DelayMultiplier:** Adjusts the delay multiplier for the consensus mechanism. + - **EC.BaseDecisionBackoffTable:** Defines the backoff strategy for consensus decisions. + - **EC.HeadLookback:** Determines the how far behind EC is F3 running. + - **GPBFTConfig:** Configures the parameters for the GPBFT consensus protocol. + - **CxConfig:** Configuration of Chain Exchange protocol + - **PubSubConfig:** Configuration of F3’s usage of PubSub. + - **CatchUpAlignment:** Aligns catch-up processes with network requirements. +- The smart contract itself will not do any conformance checking of the manifest data. It is up to implementations to decompress and parse the data and defensively set the allowed parameters. +- The manifest content that is stored in the contract will be DEFLATE-compressed JSON data. + +#### Dynamic Manifest Schema +
+Click to expand Dynamic Manifest Schema + +```json +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "type": "object", + "required": [ + "Pause", + "ProtocolVersion", + "InitialInstance", + "BootstrapEpoch", + "NetworkName", + "CommitteeLookback", + "CatchUpAlignment", + "Gpbft", + "EC", + "CertificateExchange", + "PubSub", + "ChainExchange" + ], + "properties": { + "Pause": { + "type": "boolean", + "description": "Flag to pause the protocol" + }, + "ProtocolVersion": { + "type": "integer", + "minimum": 0, + "description": "Version number of the protocol" + }, + "InitialInstance": { + "type": "integer", + "minimum": 0, + "description": "Initial instance number" + }, + "BootstrapEpoch": { + "type": "integer", + "minimum": 0, + "description": "Epoch number for bootstrapping" + }, + "NetworkName": { + "type": "string", + "description": "Name of the network" + }, + "ExplicitPower": { + "type": ["null", "object"], + "description": "Optional explicit power configuration" + }, + "IgnoreECPower": { + "type": "boolean", + "description": "Flag to ignore EC power" + }, + "InitialPowerTable": { + "type": ["null", "object"], + "description": "Optional initial power table configuration" + }, + "CommitteeLookback": { + "type": "integer", + "minimum": 0, + "description": "Number of blocks to look back for committee" + }, + "CatchUpAlignment": { + "type": "integer", + "minimum": 0, + "description": "Alignment value for catch-up process" + }, + "Gpbft": { + "type": "object", + "required": [ + "Delta", + "DeltaBackOffExponent", + "QualityDeltaMultiplier", + "MaxLookaheadRounds", + "ChainProposedLength", + "RebroadcastBackoffBase", + "RebroadcastBackoffExponent", + "RebroadcastBackoffSpread", + "RebroadcastBackoffMax" + ], + "properties": { + "Delta": { + "type": "integer", + "minimum": 0, + "description": "Base delta value" + }, + "DeltaBackOffExponent": { + "type": "number", + "minimum": 0, + "description": "Exponent for delta backoff calculation" + }, + "QualityDeltaMultiplier": { + "type": "integer", + "minimum": 0, + "description": "Multiplier for quality delta" + }, + "MaxLookaheadRounds": { + "type": "integer", + "minimum": 0, + "description": "Maximum number of lookahead rounds" + }, + "ChainProposedLength": { + "type": "integer", + "minimum": 0, + "description": "Proposed length of the chain" + }, + "RebroadcastBackoffBase": { + "type": "integer", + "minimum": 0, + "description": "Base value for rebroadcast backoff" + }, + "RebroadcastBackoffExponent": { + "type": "number", + "minimum": 0, + "description": "Exponent for rebroadcast backoff" + }, + "RebroadcastBackoffSpread": { + "type": "number", + "minimum": 0, + "description": "Spread value for rebroadcast backoff" + }, + "RebroadcastBackoffMax": { + "type": "integer", + "minimum": 0, + "description": "Maximum rebroadcast backoff value" + } + } + }, + "EC": { + "type": "object", + "required": [ + "Period", + "Finality", + "DelayMultiplier", + "BaseDecisionBackoffTable", + "HeadLookback", + "Finalize" + ], + "properties": { + "Period": { + "type": "integer", + "minimum": 0, + "description": "Period duration" + }, + "Finality": { + "type": "integer", + "minimum": 0, + "description": "Finality parameter" + }, + "DelayMultiplier": { + "type": "integer", + "minimum": 0, + "description": "Multiplier for delay calculations" + }, + "BaseDecisionBackoffTable": { + "type": "array", + "items": { + "type": "number", + "minimum": 0 + }, + "description": "Table of backoff values for base decisions" + }, + "HeadLookback": { + "type": "integer", + "minimum": 0, + "description": "Number of blocks to look back from head" + }, + "Finalize": { + "type": "boolean", + "description": "Flag to enable finalization" + } + } + }, + "CertificateExchange": { + "type": "object", + "required": [ + "ClientRequestTimeout", + "ServerRequestTimeout", + "MinimumPollInterval", + "MaximumPollInterval" + ], + "properties": { + "ClientRequestTimeout": { + "type": "integer", + "minimum": 0, + "description": "Timeout for client requests" + }, + "ServerRequestTimeout": { + "type": "integer", + "minimum": 0, + "description": "Timeout for server requests" + }, + "MinimumPollInterval": { + "type": "integer", + "minimum": 0, + "description": "Minimum interval between polls" + }, + "MaximumPollInterval": { + "type": "integer", + "minimum": 0, + "description": "Maximum interval between polls" + } + } + }, + "PubSub": { + "type": "object", + "required": ["CompressionEnabled"], + "properties": { + "CompressionEnabled": { + "type": "boolean", + "description": "Flag to enable compression" + } + } + }, + "ChainExchange": { + "type": "object", + "required": [ + "SubscriptionBufferSize", + "MaxChainLength", + "MaxInstanceLookahead", + "MaxDiscoveredChainsPerInstance", + "MaxWantedChainsPerInstance", + "RebroadcastInterval", + "MaxTimestampAge" + ], + "properties": { + "SubscriptionBufferSize": { + "type": "integer", + "minimum": 0, + "description": "Size of the subscription buffer" + }, + "MaxChainLength": { + "type": "integer", + "minimum": 0, + "description": "Maximum length of the chain" + }, + "MaxInstanceLookahead": { + "type": "integer", + "minimum": 0, + "description": "Maximum number of instances to look ahead" + }, + "MaxDiscoveredChainsPerInstance": { + "type": "integer", + "minimum": 0, + "description": "Maximum number of discovered chains per instance" + }, + "MaxWantedChainsPerInstance": { + "type": "integer", + "minimum": 0, + "description": "Maximum number of wanted chains per instance" + }, + "RebroadcastInterval": { + "type": "integer", + "minimum": 0, + "description": "Interval between rebroadcasts" + }, + "MaxTimestampAge": { + "type": "integer", + "minimum": 0, + "description": "Maximum age of timestamps" + } + } + } + } +} +``` +
+ +### Proposed sequence / example timeline + +*This is an expected sequence of events for using this proposed functionality with an example timeline to aid with clarity on decision points and review periods.* + +| What? | When Starts? | When Completes? | Why? | +| --- | --- | --- | --- | +| create “the multisig contract” | whenever | before deploying “the smart contract” below | Serves as the owner of “the smart contract” and accomplishes multi-stakeholder consensus of the Lotus, Forest, and Venus implementation teams. | +| deploy “the smart contract” that implements this proposal | by 1 week before nv25 Lotus code freeze | by nv25 Lotus code freeze | Give community an opportunity to review/audit “the smart contract” before baking its address and owner address into nv25 Lotus/Forest/Venus versions. It should follow the design in this proposal and comply with the constraints that have been outlined. | +| update Lotus/Forest/Venus to hardcode “the smart contract” address and owner address | by nv25 Lotus code freeze | by nv25 Lotus code freeze | Prevent any tampering with “the smart contract”’s logic/constraints that were reviewed by the community. | +| nv25 activation | | date X (ideally in Q1) | Filecoin mainnet nodes/miners now have code that has: 1) Improvements / learnings from the nv24 passive testing. 2) Additional knobs for [nv25 passive testing](https://github.com/filecoin-project/go-f3/issues/802). 3) Does a one-time setting of the F3 “good parameter set” based on querying “the smart contract” as discussed in this proposal. | +| [nv25 passive testing](https://github.com/filecoin-project/go-f3/issues/802) | X + 1 or 2 days | X + 2 weeks | Empirical testing to ensure we have a “good parameter set” that works well on mainnet. There will be daily updates on progress and findings, like with nv24, [here](https://github.com/filecoin-project/lotus/discussions/12287). | +| announce proposed f3 parameters, proposed activation date, and rationale for these | X+2.5 weeks (after [nv25 passive testing](https://github.com/filecoin-project/go-f3/issues/802)) | X + 2.5 weeks | Give community full visibility into the proposed f3 “good parameter set” that would be one-time-set via “the smart contract” so we can get input and determine whether we need to make any adjustments. This would be both in English prose in a GitHub community discussion/issue and in PR as a ["task"](https://github.com/filecoin-project/f3-activation-contract/blob/master/tasks/F3Parameters.ts) to run against “the smart contract”. | +| community review period | X+2.5 weeks (after public announcement / PR) | X + 3.5 weeks | Ensure there is buy-in (or at least not major active opposition) to the “good parameter set” and bootstrap epoch. | +| set the bootstrap epoch and “good parameter set” on “the smart contract” with an activation epoch (which is at least 3 days in the future) | X + 3.5 weeks (after community review period) | X + 3.5 weeks | Nodes that are participating in nv25 will pick up the “good parameter set” and start using them at the bootstrap epoch. Given the bootstrap epoch is sufficiently in the future, if an issue wasn’t caught in the previous review period, there is still time to abort by updating “the smart contract” with a bootstrap epoch further in the future and/or to deploy client software that ignores the “good parameter set” values in “the smart contract”. | +| (optional) publish new Lotus, Forest, and Venus versions with the f3 “good parameter set” inline and removal of delegated setting via smart contract | X + 3.5 weeks (after community review period) | X + 3.5 weeks | Operators aren’t required to update to this version, but it gives them a way to run code that no longer has an opening for delegated authority. | +| bootstrap epoch | X + 4 weeks (starts based on the bootstrap epoch that was set as part of publishing “the smart contract”.) | X + 4 weeks | This is what activates F3 on Mainnet. This is what the network has been building towards for months 🙂 | +| active mainnet monitoring | X + 4 weeks (after bootstrap epoch) | Indefinite | F3 in nainnet has now become a default aspect that is monitored and reviewed with other network metrics given its importance for the network. | + +## Design Rationale + +We considered these options: +* ❌ do an extra network upgrade - This was rejected for the reasons outlined in [Change Motivation](#change-motivation): too long on the calendar and too people-taxing on the network. +* ❌ use the same mechanism as passive testing but affect consensus - With passive testing we've already got an ability to dynamically set the F3 parameters. It is centrally owned and managed though by FilOz engineers that have been driving the F3 implementation. Centralization for expediency seemed fine when consensus wasn't at play, but the moment that consensus is impacted, we expect network values of decentralization to be followed. +* ❌ propagate manifest values with PubSub - rather than deliver "the good parameter set" via a smart contract, sign a message form pre-arranged and agreed upon libp2p peer id. While this would enable multiple stakehlders, it would miss out on the easier transparency and tooling that we get from living with chain-stored state. +* ✅ distribute via implemenation-team owned smart contract - This idea has been shared at multiple [Filecoin Implementers Working Group](https://filecoindev.notion.site/Filecoin-Implementers-Working-Group-118dc41950c180d08a24f0869aae1c1c) meetings without concern, and the [public discussion](https://github.com/filecoin-project/FIPs/discussions/1102) has not raised opposition to the proposal. We have taken this as approval (or at least acceptance) of this lighter-weight mechanism to move faster while still having a high amount of transparency and safety. + +## Backwards Compatibility + +There is no backward incompatibility introduced by this FRC. Instead, this FRC may be the beginning of a new tool in the ecosystem's toolbelt for being able to make important changes at a faster rate at acceptable safety and transparency levels. + +## Test Cases + +* smart contract reading and writing: https://github.com/filecoin-project/f3-activation-contract/blob/master/test/F3Parameters.js +* Lotus integration: TODO +* Forest integration: TODO +* Venus integration: TODO + +## Security Considerations + +The following checks and balances are in place to avoid blind-siding anyone in the network and to use the collective community to catch any potential mistakes or security issues: + +1. “the smart contract” code will be open for review for at least a week to help catch any potential vulnerabilities. + 1. Note: we are not planning for this contract to be formally audited because of its simple logic and no user assets being directly at stake. +2. The nv25-compatible Lotus/Forest/Venus releases will hardcode “the smart contract” address and owner address such that getting clients to use a tampered-version would require a network version. The PRs for hardcoding “the smart contract” address and owner address will be open for review for at least 2 days to allow for verification. (And of course since implementations are open source, the contract and owner addresses can be verified at any point.) +3. Updating the state of “the smart contract” with the bootstrap epoch and “good parameter set” will require signing from “the multiisig contract”, which has three separate but knowledgeable signing groups (Lotus, Forest, and Venus maintainers). The corresponding blockchain message id will be shared on Slack, GitHub, etc. for clear visibility. +4. The bootstrap epoch set in the message above will be at least 72 hours in the future, providing one more window to course correct. +5. “the smart contract” code will disregard any bootstrap updates that are 6 months in future of the contract creation date, ensuring this one-time setting mechanism has an upper bound. (It’s expected that its “used once finalization” will occur well before this “self-disablement”.) +6. The “good parameter set” and bootstrap epoch cannot be updated if “the smart contract” has a bootstrap epoch set that is in the past. (This conforms to “use only once and then finalize”.) + + +## Incentive Considerations + +This proposal does not affect incentives. In nv25 and the period immediately following, f3 participation will still be voluntary without any direct charge to SPs who opt out. While we believe SPs have indirect incentivization in the long term to enable F3 because of the wider capabilities it brings to the network, direct incentivization will be designed and encouraged in followup network upgrades (see [current proposal discussion](https://github.com/filecoin-project/FIPs/discussions/1106)). + +## Product Considerations + +For this proposed activation strategy, we believe the guardrails and transparency proposed should have no adverse product impact. Instead, we expect the network will get the [F3 benefits](../FIPS/fip-0086.md#product-considerations) quicker and with less net effort than an additional network upgrade. + +## Implementation + +* smart contract: + * source code: https://github.com/filecoin-project/f3-activation-contract/blob/master/contracts/F3Parameters.sol + * mainnet contract verification: TODO +* multisig owning contract + * address: TODO + * Lotus public key: TODO + * Forest public key: TODO + * Venus public key: TODO +* Lotus integration code: TODO ([tracking issue](https://github.com/filecoin-project/go-f3/issues/824)) +* Forest integration code: TODO +* Venus integration code: TODO + +## TODO + +* Implementation and integration master tracking issue: https://github.com/filecoin-project/go-f3/issues/828 + + +## FAQ + +### Why was this done as an FRC rather than as addition to the F3 FIP? + +[F3 FIP-0086](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0086.md) focuses on the protocol changes, which already has community agreement to ship. This was separated out because it's a discussion on _how_ to deliver the protocol changes that have already been approved. We didn't want the community acceptance of FIP-0086 to be clouded by the delivery vehicle. In addition, we forsee this proposed "delegated authority" appproach being a potential pattern to learn from or use again in the future as the ecosystem seeks to move faster while still having safety and community transparency. As a result, we thought this potential case study should be more easily addressed and referenced if it wasn't buried within an already very long FIP. + + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). diff --git a/README.md b/README.md index 2201a0dac..a8a9462ee 100644 --- a/README.md +++ b/README.md @@ -134,3 +134,4 @@ This improvement protocol helps achieve that objective for all members of the Fi | [0096](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0096.md) | Convert fundraising remainder address(es) to keyless account actor(s) | FIP | @Fatman13 | Draft | | [0097](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0097.md) | Add Support for EIP-1153 (Transient Storage) in the FEVM | FIP | Michael Seiler (@snissn), Steven Allen (@stebalien) | Accepted | | [0098](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0098.md) | Simplify termination fee calculation to a fixed percentage of initial pledge | FIP | Jonathan Schwartz (@Schwartz10), Alex North (@anorth), Jim Pick (@jimpick) | Last Call | +| [XXXX](https://github.com/filecoin-project/FIPs/blob/master/FRCs/frc-retrieval-checking-requirements.md) | Delegation of Authority for F3 Parameter Setting | FRC | @Kubuxu @BigLep | Draft | From bdb3d15b922a7219815f390291899f8ba6d18e83 Mon Sep 17 00:00:00 2001 From: Steve Loeppky Date: Fri, 31 Jan 2025 11:31:25 -0800 Subject: [PATCH 02/13] Apply suggestions from code review Co-authored-by: Masih H. Derkani Co-authored-by: Phi-rjan --- FRCs/frc-f3_delegated_authority.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/FRCs/frc-f3_delegated_authority.md b/FRCs/frc-f3_delegated_authority.md index 4fc716ed0..cff0d9ae0 100644 --- a/FRCs/frc-f3_delegated_authority.md +++ b/FRCs/frc-f3_delegated_authority.md @@ -35,10 +35,10 @@ The Fast Finality (F3) feature for Filecoin requires comprehensive testing under *Below are common terms used through the rest of this document.* - nv25 - The network upgrade that will deliver the next batch of F3 protocol and code changes, which we also expect is the last network upgrade for activating F3 on mainnet. -- "the implementations" - This means the main active Filecoin implementations: Lotus, Forest, and Venus. +- "the implementations" - This means the main major Filecoin implementations: Lotus, Forest, and Venus. - “the smart contract” - This is the smart contract referred to in this proposal that contains the “good parameter set” and the bootstrap epoch. The source code will live in [filecoin-project/f3-activation-contract](https://github.com/filecoin-project/f3-activation-contract) and its address and owner address will be hardcoded in Lotus/Forest/Venus nv25-compatible releases. The owner address is "the multisig contract" discussed below. - “good parameter set” - This is the set of F3 configuration parameters that will be determined as part of [nv25 mainnet passive testing](https://github.com/filecoin-project/go-f3/issues/802). This parameter set will have sustained demonstrated success in mainnet. It will be stored in "the smart contract" as DEFLATE compressed JSON data, and it will be consumed by "the implementations". -- “the multisig contract” - This is a standard off-the-shelf multisig EVM contract that will be the owner of “the smart contract”. As a result, “the smart contract” will only accept updates from this multisg contract. This is the mechanism by which we accomplish multi-stakeholder consensus of the Lotus, Forest, and Venus implementation teams. +- “the multisig contract” - This is a standard off-the-shelf multisig EVM contract that will be the owner of “the smart contract”. As a result, “the smart contract” will only accept updates from this multisig contract. This is the mechanism by which we accomplish multi-stakeholder consensus of the Lotus, Forest, and Venus implementation teams. ## Specification @@ -359,15 +359,15 @@ To streamline this process and enhance flexibility, we propose delegating the au | set the bootstrap epoch and “good parameter set” on “the smart contract” with an activation epoch (which is at least 3 days in the future) | X + 3.5 weeks (after community review period) | X + 3.5 weeks | Nodes that are participating in nv25 will pick up the “good parameter set” and start using them at the bootstrap epoch. Given the bootstrap epoch is sufficiently in the future, if an issue wasn’t caught in the previous review period, there is still time to abort by updating “the smart contract” with a bootstrap epoch further in the future and/or to deploy client software that ignores the “good parameter set” values in “the smart contract”. | | (optional) publish new Lotus, Forest, and Venus versions with the f3 “good parameter set” inline and removal of delegated setting via smart contract | X + 3.5 weeks (after community review period) | X + 3.5 weeks | Operators aren’t required to update to this version, but it gives them a way to run code that no longer has an opening for delegated authority. | | bootstrap epoch | X + 4 weeks (starts based on the bootstrap epoch that was set as part of publishing “the smart contract”.) | X + 4 weeks | This is what activates F3 on Mainnet. This is what the network has been building towards for months 🙂 | -| active mainnet monitoring | X + 4 weeks (after bootstrap epoch) | Indefinite | F3 in nainnet has now become a default aspect that is monitored and reviewed with other network metrics given its importance for the network. | +| active mainnet monitoring | X + 4 weeks (after bootstrap epoch) | Indefinite | F3 in mainnet has now become a default aspect that is monitored and reviewed with other network metrics given its importance for the network. | ## Design Rationale We considered these options: * ❌ do an extra network upgrade - This was rejected for the reasons outlined in [Change Motivation](#change-motivation): too long on the calendar and too people-taxing on the network. * ❌ use the same mechanism as passive testing but affect consensus - With passive testing we've already got an ability to dynamically set the F3 parameters. It is centrally owned and managed though by FilOz engineers that have been driving the F3 implementation. Centralization for expediency seemed fine when consensus wasn't at play, but the moment that consensus is impacted, we expect network values of decentralization to be followed. -* ❌ propagate manifest values with PubSub - rather than deliver "the good parameter set" via a smart contract, sign a message form pre-arranged and agreed upon libp2p peer id. While this would enable multiple stakehlders, it would miss out on the easier transparency and tooling that we get from living with chain-stored state. -* ✅ distribute via implemenation-team owned smart contract - This idea has been shared at multiple [Filecoin Implementers Working Group](https://filecoindev.notion.site/Filecoin-Implementers-Working-Group-118dc41950c180d08a24f0869aae1c1c) meetings without concern, and the [public discussion](https://github.com/filecoin-project/FIPs/discussions/1102) has not raised opposition to the proposal. We have taken this as approval (or at least acceptance) of this lighter-weight mechanism to move faster while still having a high amount of transparency and safety. +* ❌ propagate manifest values with PubSub - rather than deliver "the good parameter set" via a smart contract, sign a message form pre-arranged and agreed upon libp2p peer id. While this would enable multiple stakeholders, it would miss out on the easier transparency and tooling that we get from living with chain-stored state. +* ✅ distribute via implementation-team owned smart contract - This idea has been shared at multiple [Filecoin Implementers Working Group](https://filecoindev.notion.site/Filecoin-Implementers-Working-Group-118dc41950c180d08a24f0869aae1c1c) meetings without concern, and the [public discussion](https://github.com/filecoin-project/FIPs/discussions/1102) has not raised opposition to the proposal. We have taken this as approval (or at least acceptance) of this lighter-weight mechanism to move faster while still having a high amount of transparency and safety. ## Backwards Compatibility @@ -424,7 +424,7 @@ For this proposed activation strategy, we believe the guardrails and transparenc ### Why was this done as an FRC rather than as addition to the F3 FIP? -[F3 FIP-0086](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0086.md) focuses on the protocol changes, which already has community agreement to ship. This was separated out because it's a discussion on _how_ to deliver the protocol changes that have already been approved. We didn't want the community acceptance of FIP-0086 to be clouded by the delivery vehicle. In addition, we forsee this proposed "delegated authority" appproach being a potential pattern to learn from or use again in the future as the ecosystem seeks to move faster while still having safety and community transparency. As a result, we thought this potential case study should be more easily addressed and referenced if it wasn't buried within an already very long FIP. +[F3 FIP-0086](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0086.md) focuses on the protocol changes, which already has community agreement to ship. This was separated out because it's a discussion on _how_ to deliver the protocol changes that have already been approved. We didn't want the community acceptance of FIP-0086 to be clouded by the delivery vehicle. In addition, we forsee this proposed "delegated authority" approach being a potential pattern to learn from or use again in the future as the ecosystem seeks to move faster while still having safety and community transparency. As a result, we thought this potential case study should be more easily addressed and referenced if it wasn't buried within an already very long FIP. ## Copyright From 75ca52d2404e3b261180f8e1011555931a275cc7 Mon Sep 17 00:00:00 2001 From: Steve Loeppky Date: Fri, 31 Jan 2025 13:25:58 -0800 Subject: [PATCH 03/13] Incorporated feedback. Also set the multisig and lotus addresses. --- FRCs/frc-f3_delegated_authority.md | 155 ++++++++++++++++++++++++----- 1 file changed, 131 insertions(+), 24 deletions(-) diff --git a/FRCs/frc-f3_delegated_authority.md b/FRCs/frc-f3_delegated_authority.md index cff0d9ae0..cf88deef6 100644 --- a/FRCs/frc-f3_delegated_authority.md +++ b/FRCs/frc-f3_delegated_authority.md @@ -20,11 +20,11 @@ requires (*optional): FIP-0086 ## Simple Summary -Avoid a full network upgrade for setting F3 activation parameters by instead delegating parameter setting to the Lotus, Forest, and Venus implementation teams, who will set these parameters on-chain for one-time use on mainnet. +Avoid a full network upgrade for setting F3 activation parameters by instead delegating parameter setting to the Lotus, Forest, and Venus implementation teams, who will set these parameters using a multi-signer-owned smart contract for one-time use on mainnet. ## Abstract -This FRC proposes introducing an on-chain smart contract that can manage F3 parameters dynamically. This contract would be owned/controlled through a multi-signature mechanism requiring consensus from all three major Filecoin implementations (Lotus, Forest, and Venus). The contract would allow for a one-time parameter update based on mainnet passive test results, effectively combining what would have been two network upgrades into one while maintaining security through multiple stakeholder approval, full onchain transparency, and built-in time delays for community review. +This FRC proposes introducing an on-chain smart contract that can manage F3 parameters dynamically. This contract would be owned/controlled through a multi-signature mechanism requiring consensus from all three major Filecoin implementations (Lotus, Forest, and Venus). The contract would allow for a one-time parameter update based on mainnet passive test results, effectively combining what would have been two network upgrades into one while maintaining security through multiple stakeholder approval, full onchain transparency, and built-in time delays for community review. Additionally, the contract is designed to automatically disable itself after the F3 activation date or 2025-08-01, whichever comes first, ensuring that any changes are deliberate and well-considered, while preventing indefinite alterations. ## Change Motivation @@ -36,9 +36,9 @@ The Fast Finality (F3) feature for Filecoin requires comprehensive testing under - nv25 - The network upgrade that will deliver the next batch of F3 protocol and code changes, which we also expect is the last network upgrade for activating F3 on mainnet. - "the implementations" - This means the main major Filecoin implementations: Lotus, Forest, and Venus. -- “the smart contract” - This is the smart contract referred to in this proposal that contains the “good parameter set” and the bootstrap epoch. The source code will live in [filecoin-project/f3-activation-contract](https://github.com/filecoin-project/f3-activation-contract) and its address and owner address will be hardcoded in Lotus/Forest/Venus nv25-compatible releases. The owner address is "the multisig contract" discussed below. +- “the smart contract” - This is the smart contract referred to in this proposal that contains the “good parameter set” and the bootstrap epoch. The source code will live in [filecoin-project/f3-activation-contract](https://github.com/filecoin-project/f3-activation-contract) and its address will be hardcoded in Lotus/Forest/Venus nv25-compatible releases. The owner address is "the multisig contract" discussed below. - “good parameter set” - This is the set of F3 configuration parameters that will be determined as part of [nv25 mainnet passive testing](https://github.com/filecoin-project/go-f3/issues/802). This parameter set will have sustained demonstrated success in mainnet. It will be stored in "the smart contract" as DEFLATE compressed JSON data, and it will be consumed by "the implementations". -- “the multisig contract” - This is a standard off-the-shelf multisig EVM contract that will be the owner of “the smart contract”. As a result, “the smart contract” will only accept updates from this multisig contract. This is the mechanism by which we accomplish multi-stakeholder consensus of the Lotus, Forest, and Venus implementation teams. +- “the multisig contract” - This is a standard off-the-shelf multisig EVM contract ([Gnosis Safe](https://safe.global)) that will be the owner of “the smart contract”. As a result, “the smart contract” will only accept updates from this multisig contract. This is the mechanism by which we accomplish multi-stakeholder consensus of the Lotus, Forest, and Venus implementation teams. ## Specification @@ -50,20 +50,26 @@ To streamline this process and enhance flexibility, we propose delegating the au - This contract will live in a new public repo: [filecoin-project/f3-activation-contract](https://github.com/filecoin-project/f3-activation-contract) - Note: while we’ll restrict write access to the repo to Lotus, Forest, and Venus maintainers for general repo hygiene, repo write access isn’t the chief concern. The key decision is the groups that have the ability to update the state of the published mainnet contract (discussed more below). +### Key Verification +- Key ownership is communicated by each implementation team adding their keys to this FRC via PR in the [Implementation section](#implementation). +- One can then following the chain of _contract address hardcoded in implementations_ → _contract address owner_ → _inspect the multisig at https://safe.filecoin.io/home?safe=filecoin:ADDRESS_ → _ensure keys from [Implementation section](#implementation) are present_ + ### Controlled Update Mechanism - Parameter updates will require full consensus amongst each of the Filecoin implementations: Lotus, Forest, and Venus. This is implemented with a multisig requiring 3 of 3. - Each of the three implementation teams will send signed messages to authorize changes, ensuring security and agreement among stakeholders. ### Finalization and Self-Disabling - This would have “used once finalization”. The contract does not permit further updates if the currently set bootstrap epoch is in the past. -- It is designed to automatically disable itself after a period of six months from contract creation, ensuring that any changes are deliberate and well-considered, while preventing indefinite alterations. - - This means the bootstrap epoch must be within 6 months months of the contract creation. - - If for some reason F3 still isn’t activated within this 6 month window, a network upgrade will be required to update client software to point to a new or updated contract. +- Assuming bootstrap hasn't already finalized the contract, it is designed to automatically disable itself on 2025-08-01TOO:OO:OOZ, ensuring that any changes are deliberate and well-considered, while preventing indefinite alterations. + - This means the bootstrap epoch must be before 2025-08-01. + - There is no contingency plan beyond another network upgrade. If for some reason F3 still isn’t activated within this ~6 month window, a network upgrade will be required to update client software to point to a new contract. ### Content of the Dynamic Manifest -- The expected content of the dynamic manifest is expected to comply with the [schema below](#dynamic-manifest-schema). +- The content of the dynamic manifest is expected to comply with or be similar to [schema below](#dynamic-manifest-schema). (There may be some shifts in the parameters based on testing from before the nv25 upgrade.) - Some of the most important attributes include: - - **Bootstrap Epoch:** Specifies the activation time, set no sooner than 72 hours from message transmission. (This is intended to give the community an additional window to react in case there late-discovered issues with the parameters/rollout. See [Proposed sequence / example timeline](#proposed-sequence--example-timeline) for more context.) + - **Bootstrap Epoch:** + - Specifies the activation time, set no sooner than 72 hours from message transmission. This is intended to give the community an additional window to react in case there late-discovered issues with the parameters/rollout. See [Proposed sequence / example timeline](#proposed-sequence--example-timeline) for more context. + - This should match the "activation epoch" that has been set/validated on the contract itself. Implementations need to validate this or else they are susceptible to activating at a datetime that doesn't meet the restrictions in this proposal. - **EC.DelayMultiplier:** Adjusts the delay multiplier for the consensus mechanism. - **EC.BaseDecisionBackoffTable:** Defines the backoff strategy for consensus decisions. - **EC.HeadLookback:** Determines the how far behind EC is F3 running. @@ -75,8 +81,11 @@ To streamline this process and enhance flexibility, we propose delegating the au - The manifest content that is stored in the contract will be DEFLATE-compressed JSON data. #### Dynamic Manifest Schema + +> Note: The schema below is provided as an approximation to give readers an understanding of the expected structure. The actual schema may have adjustments based on testing results before the nv25 upgrade. +
-Click to expand Dynamic Manifest Schema +Click to expand the Dynamic Manifest Schema estimate. ```json { @@ -343,6 +352,100 @@ To streamline this process and enhance flexibility, we propose delegating the au ```
+### ABI Sketch + +Below isn't the full ABI, but captures the key functions. See the [implementation notes](#implementation) for links to the full ABI. + +```json +[ + // This will be invoked by the implementers to set the expiration as 2025-08-01T00:00:00Z + { + "name": "constructor", + "type": "constructor", + "inputs": [ + { + "name": "owner", + "type": "address" + }, + { + "name": "expiry", + "type": "uint64" + } + ], + "outputs": [] + }, + // This will be invoked by the implementers to set the activation epoch and "good parameter set". + { + "name": "updateActivationInformation", + "type": "function", + "inputs": [ + { + "name": "activationEpoch", + "type": "uint64" + }, + { + "name": "manifestData", + "type": "bytes" + } + ], + "outputs": [] + }, + // This is the main read method used by implementations. + // It will be polled for determining the activation epoch and "the good parameter set". + { + "name": "activationInformation", + "type": "function", + "inputs": [], + "outputs": [ + { + // activationEpoch + "type": "uint64" + }, + { + // manifestData + "type": "bytes" + } + ] + }, + // Error cases + // Activation epoch is in the past or within 3 days of now. + { + "name": "UpdateActivationEpochInvalid", + "type": "error", + "inputs": [ + { + "name": "currentEpoch", + "type": "uint64" + }, + { + "name": "activationEpoch", + "type": "uint64" + }, + { + "name": "reason", + "type": "string" + } + ], + "outputs": [] + }, + // F3 has already been active. + { + "name": "UpdateAlreadyActive", + "type": "error", + "inputs": [], + "outputs": [] + }, + // It's after 2025-08-01T00:00:00Z + { + "name": "UpdateExpired", + "type": "error", + "inputs": [], + "outputs": [] + } +] +``` + + ### Proposed sequence / example timeline *This is an expected sequence of events for using this proposed functionality with an example timeline to aid with clarity on decision points and review periods.* @@ -350,8 +453,8 @@ To streamline this process and enhance flexibility, we propose delegating the au | What? | When Starts? | When Completes? | Why? | | --- | --- | --- | --- | | create “the multisig contract” | whenever | before deploying “the smart contract” below | Serves as the owner of “the smart contract” and accomplishes multi-stakeholder consensus of the Lotus, Forest, and Venus implementation teams. | -| deploy “the smart contract” that implements this proposal | by 1 week before nv25 Lotus code freeze | by nv25 Lotus code freeze | Give community an opportunity to review/audit “the smart contract” before baking its address and owner address into nv25 Lotus/Forest/Venus versions. It should follow the design in this proposal and comply with the constraints that have been outlined. | -| update Lotus/Forest/Venus to hardcode “the smart contract” address and owner address | by nv25 Lotus code freeze | by nv25 Lotus code freeze | Prevent any tampering with “the smart contract”’s logic/constraints that were reviewed by the community. | +| deploy “the smart contract” that implements this proposal | by 1 week before nv25 Lotus code freeze | by nv25 Lotus code freeze | Give community an opportunity to review/audit “the smart contract” before baking its address into nv25 Lotus/Forest/Venus versions. It should follow the design in this proposal and comply with the constraints that have been outlined. | +| update Lotus/Forest/Venus to hardcode “the smart contract” address | by nv25 Lotus code freeze | by nv25 Lotus code freeze | Prevent any tampering with “the smart contract”’s logic/constraints that were reviewed by the community. | | nv25 activation | | date X (ideally in Q1) | Filecoin mainnet nodes/miners now have code that has: 1) Improvements / learnings from the nv24 passive testing. 2) Additional knobs for [nv25 passive testing](https://github.com/filecoin-project/go-f3/issues/802). 3) Does a one-time setting of the F3 “good parameter set” based on querying “the smart contract” as discussed in this proposal. | | [nv25 passive testing](https://github.com/filecoin-project/go-f3/issues/802) | X + 1 or 2 days | X + 2 weeks | Empirical testing to ensure we have a “good parameter set” that works well on mainnet. There will be daily updates on progress and findings, like with nv24, [here](https://github.com/filecoin-project/lotus/discussions/12287). | | announce proposed f3 parameters, proposed activation date, and rationale for these | X+2.5 weeks (after [nv25 passive testing](https://github.com/filecoin-project/go-f3/issues/802)) | X + 2.5 weeks | Give community full visibility into the proposed f3 “good parameter set” that would be one-time-set via “the smart contract” so we can get input and determine whether we need to make any adjustments. This would be both in English prose in a GitHub community discussion/issue and in PR as a ["task"](https://github.com/filecoin-project/f3-activation-contract/blob/master/tasks/F3Parameters.ts) to run against “the smart contract”. | @@ -366,28 +469,21 @@ To streamline this process and enhance flexibility, we propose delegating the au We considered these options: * ❌ do an extra network upgrade - This was rejected for the reasons outlined in [Change Motivation](#change-motivation): too long on the calendar and too people-taxing on the network. * ❌ use the same mechanism as passive testing but affect consensus - With passive testing we've already got an ability to dynamically set the F3 parameters. It is centrally owned and managed though by FilOz engineers that have been driving the F3 implementation. Centralization for expediency seemed fine when consensus wasn't at play, but the moment that consensus is impacted, we expect network values of decentralization to be followed. -* ❌ propagate manifest values with PubSub - rather than deliver "the good parameter set" via a smart contract, sign a message form pre-arranged and agreed upon libp2p peer id. While this would enable multiple stakeholders, it would miss out on the easier transparency and tooling that we get from living with chain-stored state. +* ❌ propagate manifest values with PubSub - rather than deliver "the good parameter set" via a smart contract, sign a message form pre-arranged and agreed upon libp2p peer id. While this would enable multiple stakeholders, it would miss out on the easier transparency and tooling that we get from living with chain-stored state. Specifically this approach doesn't have the stickiness/immutability that we get from state on chain. It also doesn't have an easy way to canonically reference it. * ✅ distribute via implementation-team owned smart contract - This idea has been shared at multiple [Filecoin Implementers Working Group](https://filecoindev.notion.site/Filecoin-Implementers-Working-Group-118dc41950c180d08a24f0869aae1c1c) meetings without concern, and the [public discussion](https://github.com/filecoin-project/FIPs/discussions/1102) has not raised opposition to the proposal. We have taken this as approval (or at least acceptance) of this lighter-weight mechanism to move faster while still having a high amount of transparency and safety. ## Backwards Compatibility There is no backward incompatibility introduced by this FRC. Instead, this FRC may be the beginning of a new tool in the ecosystem's toolbelt for being able to make important changes at a faster rate at acceptable safety and transparency levels. -## Test Cases - -* smart contract reading and writing: https://github.com/filecoin-project/f3-activation-contract/blob/master/test/F3Parameters.js -* Lotus integration: TODO -* Forest integration: TODO -* Venus integration: TODO - ## Security Considerations The following checks and balances are in place to avoid blind-siding anyone in the network and to use the collective community to catch any potential mistakes or security issues: 1. “the smart contract” code will be open for review for at least a week to help catch any potential vulnerabilities. 1. Note: we are not planning for this contract to be formally audited because of its simple logic and no user assets being directly at stake. -2. The nv25-compatible Lotus/Forest/Venus releases will hardcode “the smart contract” address and owner address such that getting clients to use a tampered-version would require a network version. The PRs for hardcoding “the smart contract” address and owner address will be open for review for at least 2 days to allow for verification. (And of course since implementations are open source, the contract and owner addresses can be verified at any point.) -3. Updating the state of “the smart contract” with the bootstrap epoch and “good parameter set” will require signing from “the multiisig contract”, which has three separate but knowledgeable signing groups (Lotus, Forest, and Venus maintainers). The corresponding blockchain message id will be shared on Slack, GitHub, etc. for clear visibility. +2. The nv25-compatible Lotus/Forest/Venus releases will hardcode “the smart contract” address such that getting clients to use a tampered-version would require a network version. The PRs for hardcoding “the smart contract” address will be open for review for at least 2 days to allow for verification. (And of course since implementations are open source, the contract can be verified at any point.) See [below](#why-do-implementations-only-hardcode-the-contract-address-vs-other-metadata) for why other contract metadata isn't hardcoded. +3. Updating the state of “the smart contract” with the bootstrap epoch and “good parameter set” will require signing from “the multisig contract”, which has three separate but knowledgeable signing groups (Lotus, Forest, and Venus maintainers). The corresponding blockchain message id will be shared on Slack, GitHub, etc. for clear visibility. 4. The bootstrap epoch set in the message above will be at least 72 hours in the future, providing one more window to course correct. 5. “the smart contract” code will disregard any bootstrap updates that are 6 months in future of the contract creation date, ensuring this one-time setting mechanism has an upper bound. (It’s expected that its “used once finalization” will occur well before this “self-disablement”.) 6. The “good parameter set” and bootstrap epoch cannot be updated if “the smart contract” has a bootstrap epoch set that is in the past. (This conforms to “use only once and then finalize”.) @@ -407,17 +503,25 @@ For this proposed activation strategy, we believe the guardrails and transparenc * source code: https://github.com/filecoin-project/f3-activation-contract/blob/master/contracts/F3Parameters.sol * mainnet contract verification: TODO * multisig owning contract - * address: TODO - * Lotus public key: TODO + * address: [0x53bd89Ff2Ff97541f42ACC3AFC0C0030e7410422](https://safe.filecoin.io/address-book?safe=filecoin:0x53bd89Ff2Ff97541f42ACC3AFC0C0030e7410422) + * Lotus public key: [0x6743938A48fC8799A5608EF079C53f3cF3B84398](https://filecoin.blockscout.com/address/0x6743938A48fC8799A5608EF079C53f3cF3B84398) * Forest public key: TODO * Venus public key: TODO * Lotus integration code: TODO ([tracking issue](https://github.com/filecoin-project/go-f3/issues/824)) * Forest integration code: TODO * Venus integration code: TODO +### Test Cases + +* smart contract reading and writing: https://github.com/filecoin-project/f3-activation-contract/blob/master/test/F3Parameters.js +* Lotus integration: TODO +* Forest integration: TODO +* Venus integration: TODO + ## TODO * Implementation and integration master tracking issue: https://github.com/filecoin-project/go-f3/issues/828 +* All the "TODO"s referenced above, which are largely related to implementation teams providing their keys, integration code, and test cases. ## FAQ @@ -426,6 +530,9 @@ For this proposed activation strategy, we believe the guardrails and transparenc [F3 FIP-0086](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0086.md) focuses on the protocol changes, which already has community agreement to ship. This was separated out because it's a discussion on _how_ to deliver the protocol changes that have already been approved. We didn't want the community acceptance of FIP-0086 to be clouded by the delivery vehicle. In addition, we forsee this proposed "delegated authority" approach being a potential pattern to learn from or use again in the future as the ecosystem seeks to move faster while still having safety and community transparency. As a result, we thought this potential case study should be more easily addressed and referenced if it wasn't buried within an already very long FIP. +### Why do implementations only hardcode the contract address vs. other metadata? + +From a threat model perspective, the implementation teams are supposed to own the the smart contract. In order to be malicious by changing ownership of the smart contract, the "good parameter set" stored within the contract or the contract's logic, they would need to collude. If the implementation teams are all colluding for nefarious purposes, we have much bigger problems... As a result, hard coding in the implementations the owner address or a hash of the of the smart contract code isn't actually buying any extra security. ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 26372ddc32a4d865d8ba9784db4cf6bd0a07962c Mon Sep 17 00:00:00 2001 From: Steve Loeppky Date: Fri, 31 Jan 2025 13:42:19 -0800 Subject: [PATCH 04/13] Small grammar fixes. --- FRCs/frc-f3_delegated_authority.md | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/FRCs/frc-f3_delegated_authority.md b/FRCs/frc-f3_delegated_authority.md index cf88deef6..0a3927e7f 100644 --- a/FRCs/frc-f3_delegated_authority.md +++ b/FRCs/frc-f3_delegated_authority.md @@ -20,19 +20,19 @@ requires (*optional): FIP-0086 ## Simple Summary -Avoid a full network upgrade for setting F3 activation parameters by instead delegating parameter setting to the Lotus, Forest, and Venus implementation teams, who will set these parameters using a multi-signer-owned smart contract for one-time use on mainnet. +Avoid a full network upgrade for setting F3 activation parameters by instead delegating parameter setting to the Lotus, Forest, and Venus implementation teams, who will set these parameters using a multisig-owned smart contract for one-time use on mainnet. ## Abstract -This FRC proposes introducing an on-chain smart contract that can manage F3 parameters dynamically. This contract would be owned/controlled through a multi-signature mechanism requiring consensus from all three major Filecoin implementations (Lotus, Forest, and Venus). The contract would allow for a one-time parameter update based on mainnet passive test results, effectively combining what would have been two network upgrades into one while maintaining security through multiple stakeholder approval, full onchain transparency, and built-in time delays for community review. Additionally, the contract is designed to automatically disable itself after the F3 activation date or 2025-08-01, whichever comes first, ensuring that any changes are deliberate and well-considered, while preventing indefinite alterations. +This FRC proposes introducing an on-chain smart contract that can manage F3 parameters dynamically. This contract would be owned/controlled through a multi-signature mechanism requiring consensus from all three major Filecoin implementations (Lotus, Forest, and Venus). The contract would allow for a one-time parameter update based on mainnet passive test results, effectively combining what would have been two network upgrades into one while maintaining security through multiple stakeholder approval, full on-chain transparency, and built-in time delays for community review. Additionally, the contract is designed to automatically disable itself after the F3 activation date or 2025-08-01, whichever comes first, ensuring that any changes are deliberate and well-considered, while preventing indefinite alterations. ## Change Motivation -The Fast Finality (F3) feature for Filecoin requires comprehensive testing under mainnet conditions to ensure its effectiveness and reliability. These live network conditions are challenging to replicate in test environments, and thus, the parameters for F3 are contingent upon the results of these mainnet tests. By default this necessitates two distinct network upgrades: one enabling Storage Providers to update their software for testing purposes, and a subsequent one for setting the finalized parameters. At least as of 202501, network upgrades are "costly" in terms of the multiple party coordination and for good reasons take a couple of calendar months to fully execute in non-emergency situations. Implementers who are taking on delivering F3, as already approved by the network in [FIP-0086](../FIPS/fip-0086.md), want to deliver the benefits of F3 network faster while minimize the "people resource" consumption on the network and their teams. (See https://github.com/filecoin-project/go-f3/issues/800 for more info.) +The Fast Finality (F3) feature for Filecoin requires comprehensive testing under mainnet conditions to ensure its effectiveness and reliability. These live network conditions are challenging to replicate in test environments, and thus, the parameters for F3 are contingent upon the results of these mainnet tests. By default this necessitates two distinct network upgrades: one enabling Storage Providers to update their software for testing purposes, and a subsequent one for setting the finalized parameters. As of 202501, network upgrades are "costly" in terms of the multiple party coordination and for good reasons take a couple of calendar months to fully execute in non-emergency situations. Implementers who are taking on delivering F3, as already approved by the network in [FIP-0086](../FIPS/fip-0086.md), want to deliver the benefits of F3 to the network faster while minimizing the "people resource" consumption on the network and their teams. (See https://github.com/filecoin-project/go-f3/issues/800 for more info.) ### Terminology -*Below are common terms used through the rest of this document.* +*Below are common terms used throughout the rest of this document.* - nv25 - The network upgrade that will deliver the next batch of F3 protocol and code changes, which we also expect is the last network upgrade for activating F3 on mainnet. - "the implementations" - This means the main major Filecoin implementations: Lotus, Forest, and Venus. @@ -60,7 +60,7 @@ To streamline this process and enhance flexibility, we propose delegating the au ### Finalization and Self-Disabling - This would have “used once finalization”. The contract does not permit further updates if the currently set bootstrap epoch is in the past. -- Assuming bootstrap hasn't already finalized the contract, it is designed to automatically disable itself on 2025-08-01TOO:OO:OOZ, ensuring that any changes are deliberate and well-considered, while preventing indefinite alterations. +- Assuming bootstrap hasn't already finalized the contract, it is designed to automatically disable itself on 2025-08-01T00:00:00Z, ensuring that any changes are deliberate and well-considered, while preventing indefinite alterations. - This means the bootstrap epoch must be before 2025-08-01. - There is no contingency plan beyond another network upgrade. If for some reason F3 still isn’t activated within this ~6 month window, a network upgrade will be required to update client software to point to a new contract. @@ -468,7 +468,7 @@ Below isn't the full ABI, but captures the key functions. See the [implementati We considered these options: * ❌ do an extra network upgrade - This was rejected for the reasons outlined in [Change Motivation](#change-motivation): too long on the calendar and too people-taxing on the network. -* ❌ use the same mechanism as passive testing but affect consensus - With passive testing we've already got an ability to dynamically set the F3 parameters. It is centrally owned and managed though by FilOz engineers that have been driving the F3 implementation. Centralization for expediency seemed fine when consensus wasn't at play, but the moment that consensus is impacted, we expect network values of decentralization to be followed. +* ❌ use the same mechanism as passive testing but affect consensus - With passive testing we've already got an ability to dynamically set the F3 parameters. It is centrally owned and managed though by FilOz engineers that have been driving the F3 implementation. Centralization for expediency seemed acceptable when consensus wasn't at play, but the moment that consensus is impacted, we expect network values of decentralization to be followed. * ❌ propagate manifest values with PubSub - rather than deliver "the good parameter set" via a smart contract, sign a message form pre-arranged and agreed upon libp2p peer id. While this would enable multiple stakeholders, it would miss out on the easier transparency and tooling that we get from living with chain-stored state. Specifically this approach doesn't have the stickiness/immutability that we get from state on chain. It also doesn't have an easy way to canonically reference it. * ✅ distribute via implementation-team owned smart contract - This idea has been shared at multiple [Filecoin Implementers Working Group](https://filecoindev.notion.site/Filecoin-Implementers-Working-Group-118dc41950c180d08a24f0869aae1c1c) meetings without concern, and the [public discussion](https://github.com/filecoin-project/FIPs/discussions/1102) has not raised opposition to the proposal. We have taken this as approval (or at least acceptance) of this lighter-weight mechanism to move faster while still having a high amount of transparency and safety. @@ -478,13 +478,13 @@ There is no backward incompatibility introduced by this FRC. Instead, this FRC ## Security Considerations -The following checks and balances are in place to avoid blind-siding anyone in the network and to use the collective community to catch any potential mistakes or security issues: +The following checks and balances are in place to avoid blindsiding anyone in the network and to use the collective community to catch any potential mistakes or security issues: 1. “the smart contract” code will be open for review for at least a week to help catch any potential vulnerabilities. 1. Note: we are not planning for this contract to be formally audited because of its simple logic and no user assets being directly at stake. 2. The nv25-compatible Lotus/Forest/Venus releases will hardcode “the smart contract” address such that getting clients to use a tampered-version would require a network version. The PRs for hardcoding “the smart contract” address will be open for review for at least 2 days to allow for verification. (And of course since implementations are open source, the contract can be verified at any point.) See [below](#why-do-implementations-only-hardcode-the-contract-address-vs-other-metadata) for why other contract metadata isn't hardcoded. 3. Updating the state of “the smart contract” with the bootstrap epoch and “good parameter set” will require signing from “the multisig contract”, which has three separate but knowledgeable signing groups (Lotus, Forest, and Venus maintainers). The corresponding blockchain message id will be shared on Slack, GitHub, etc. for clear visibility. -4. The bootstrap epoch set in the message above will be at least 72 hours in the future, providing one more window to course correct. +4. The bootstrap epoch set in the message above will be at least 72 hours in the future, providing one more window to course-correct. 5. “the smart contract” code will disregard any bootstrap updates that are 6 months in future of the contract creation date, ensuring this one-time setting mechanism has an upper bound. (It’s expected that its “used once finalization” will occur well before this “self-disablement”.) 6. The “good parameter set” and bootstrap epoch cannot be updated if “the smart contract” has a bootstrap epoch set that is in the past. (This conforms to “use only once and then finalize”.) @@ -501,6 +501,7 @@ For this proposed activation strategy, we believe the guardrails and transparenc * smart contract: * source code: https://github.com/filecoin-project/f3-activation-contract/blob/master/contracts/F3Parameters.sol + * ABI: TODO * mainnet contract verification: TODO * multisig owning contract * address: [0x53bd89Ff2Ff97541f42ACC3AFC0C0030e7410422](https://safe.filecoin.io/address-book?safe=filecoin:0x53bd89Ff2Ff97541f42ACC3AFC0C0030e7410422) @@ -528,11 +529,11 @@ For this proposed activation strategy, we believe the guardrails and transparenc ### Why was this done as an FRC rather than as addition to the F3 FIP? -[F3 FIP-0086](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0086.md) focuses on the protocol changes, which already has community agreement to ship. This was separated out because it's a discussion on _how_ to deliver the protocol changes that have already been approved. We didn't want the community acceptance of FIP-0086 to be clouded by the delivery vehicle. In addition, we forsee this proposed "delegated authority" approach being a potential pattern to learn from or use again in the future as the ecosystem seeks to move faster while still having safety and community transparency. As a result, we thought this potential case study should be more easily addressed and referenced if it wasn't buried within an already very long FIP. +[F3 FIP-0086](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0086.md) focuses on the protocol changes, which already has community agreement to ship. This was separated out because it's a discussion on _how_ to deliver the protocol changes that have already been approved. We didn't want the community acceptance of FIP-0086 to be clouded by the delivery vehicle. In addition, we foresee this proposed "delegated authority" approach being a potential pattern to learn from or use again in the future as the ecosystem seeks to move faster while still having safety and community transparency. As a result, we thought this potential case study should be more easily addressed and referenced if it wasn't buried within an already very long FIP. ### Why do implementations only hardcode the contract address vs. other metadata? -From a threat model perspective, the implementation teams are supposed to own the the smart contract. In order to be malicious by changing ownership of the smart contract, the "good parameter set" stored within the contract or the contract's logic, they would need to collude. If the implementation teams are all colluding for nefarious purposes, we have much bigger problems... As a result, hard coding in the implementations the owner address or a hash of the of the smart contract code isn't actually buying any extra security. +From a threat model perspective, the implementation teams are supposed to own the the smart contract. In order to be malicious by changing ownership of the smart contract, the "good parameter set" stored within the contract or the contract's logic, they would need to collude. If the implementation teams are all colluding for nefarious purposes, we have much bigger problems. As a result, hard coding in the implementations the owner address or a hash of the of the smart contract code isn't actually buying any extra security. ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 255f203286c685c49304d3518e53bf3e7b980205 Mon Sep 17 00:00:00 2001 From: Steve Loeppky Date: Wed, 5 Feb 2025 08:06:48 -0800 Subject: [PATCH 05/13] Incorporated fip editor comments. --- FRCs/frc-0099.md | 534 +++++++++++++++++++++++++++++++++++++++++++++++ README.md | 2 +- 2 files changed, 535 insertions(+), 1 deletion(-) create mode 100644 FRCs/frc-0099.md diff --git a/FRCs/frc-0099.md b/FRCs/frc-0099.md new file mode 100644 index 000000000..08ea4a328 --- /dev/null +++ b/FRCs/frc-0099.md @@ -0,0 +1,534 @@ +--- +fip: "0099" +title: Delegation of Authority for F3 Parameter Setting +author: "@Kubuxu @BigLep" +discussions-to: https://github.com/filecoin-project/FIPs/discussions/1102 +status: Draft +type: FRC +created: 2025-01-30 +requires (*optional): FIP-0086 +--- + + + +# FRC-0099: Delegation of Authority for F3 Parameter Setting + +## Simple Summary + +Avoid a full network upgrade for setting F3 activation parameters by instead delegating parameter setting to the Lotus, Forest, and Venus implementation teams, who will set these parameters using a multisig-owned smart contract for one-time use on mainnet. + +## Abstract + +This FRC proposes introducing an on-chain smart contract that can manage F3 parameters dynamically. This contract would be owned/controlled through a multi-signature mechanism requiring consensus from all three major Filecoin implementations (Lotus, Forest, and Venus). The contract would allow for a one-time parameter update based on mainnet passive test results, effectively combining what would have been two network upgrades into one while maintaining security through multiple stakeholder approval, full on-chain transparency, and built-in time delays for community review. Additionally, the contract is designed to automatically disable itself after the F3 activation date or 2025-08-01, whichever comes first, ensuring that any changes are deliberate and well-considered, while preventing indefinite alterations. + +## Change Motivation + +The Fast Finality (F3) feature for Filecoin requires comprehensive testing under mainnet conditions to ensure its effectiveness and reliability. These live network conditions are challenging to replicate in test environments, and thus, the parameters for F3 are contingent upon the results of these mainnet tests. By default this necessitates two distinct network upgrades: one enabling Storage Providers to update their software for testing purposes, and a subsequent one for setting the finalized parameters. As of 202501, network upgrades are "costly" in terms of the multiple party coordination and for good reasons take a couple of calendar months to fully execute in non-emergency situations. Implementers who are taking on delivering F3, as already approved by the network in [FIP-0086](../FIPS/fip-0086.md), want to deliver the benefits of F3 to the network faster while minimizing the "people resource" consumption on the network and their teams. (See https://github.com/filecoin-project/go-f3/issues/800 for more info.) + +### Terminology + +*Below are common terms used throughout the rest of this document.* + +- nv25 - The network upgrade that will deliver the next batch of F3 protocol and code changes, which we also expect is the last network upgrade for activating F3 on mainnet. +- "the implementations" - This means the main major Filecoin implementations: Lotus, Forest, and Venus. +- “the smart contract” - This is the smart contract referred to in this proposal that contains the “good parameter set” and the bootstrap epoch. The source code will live in [filecoin-project/f3-activation-contract](https://github.com/filecoin-project/f3-activation-contract) and its address will be hardcoded in Lotus/Forest/Venus nv25-compatible releases. The owner address is "the multisig contract" discussed below. +- “good parameter set” - This is the set of F3 configuration parameters that will be determined as part of [nv25 mainnet passive testing](https://github.com/filecoin-project/go-f3/issues/802). This parameter set will have sustained demonstrated success in mainnet. It will be stored in "the smart contract" as DEFLATE compressed JSON data, and it will be consumed by "the implementations". +- “the multisig contract” - This is a standard off-the-shelf multisig EVM contract ([Gnosis Safe](https://safe.global)) that will be the owner of “the smart contract”. As a result, “the smart contract” will only accept updates from this multisig contract. This is the mechanism by which we accomplish multi-stakeholder consensus of the Lotus, Forest, and Venus implementation teams. + + +## Specification + +To streamline this process and enhance flexibility, we propose delegating the authority for setting F3 parameters to an on-chain contract so F3 activation in mainnet can be accomplished with one network upgrade rather than two. This contract will be responsible for managing a predefined set of parameters and making go/no-go decisions regarding their implementation. + +### On-Chain Contract for Parameter Management +- Move the parameter setting from the build phase to an on-chain contract, allowing for a singular dynamic update based on real-time test results. +- This contract will live in a new public repo: [filecoin-project/f3-activation-contract](https://github.com/filecoin-project/f3-activation-contract) + - Note: while we’ll restrict write access to the repo to Lotus, Forest, and Venus maintainers for general repo hygiene, repo write access isn’t the chief concern. The key decision is the groups that have the ability to update the state of the published mainnet contract (discussed more below). + +### Key Verification +- Key ownership is communicated by each implementation team adding their keys to this FRC via PR in the [Implementation section](#implementation). +- One can then following the chain of _contract address hardcoded in implementations_ → _contract address owner_ → _inspect the multisig at https://safe.filecoin.io/home?safe=filecoin:ADDRESS_ → _ensure keys from [Implementation section](#implementation) are present_ + +### Controlled Update Mechanism +- Parameter updates will require full consensus amongst each of the Filecoin implementations: Lotus, Forest, and Venus. This is implemented with a multisig requiring 3 of 3. +- Each of the three implementation teams will send signed messages to authorize changes, ensuring security and agreement among stakeholders. + +### Finalization and Self-Disabling +- This would have “used once finalization”. The contract does not permit further updates if the currently set bootstrap epoch is in the past. +- Assuming bootstrap hasn't already finalized the contract, it is designed to automatically disable itself on 2025-08-01T00:00:00Z (mainnet epoch 5190000), ensuring that any changes are deliberate and well-considered, while preventing indefinite alterations. + - This means the bootstrap epoch must be before 2025-08-01. + - There is no contingency plan beyond another network upgrade. If for some reason F3 still isn’t activated within this ~6 month window, a network upgrade will be required to update client software to point to a new contract. + +### Content of the Dynamic Manifest +- The content of the dynamic manifest is expected to comply with or be similar to [schema below](#dynamic-manifest-schema). (There may be some shifts in the parameters based on testing from before the nv25 upgrade.) +- Some of the most important attributes include: + - **Bootstrap Epoch:** + - Specifies the activation time, set no sooner than 72 hours from message transmission. This is intended to give the community an additional window to react in case there late-discovered issues with the parameters/rollout. See [Proposed sequence / example timeline](#proposed-sequence--example-timeline) for more context. + - This should match the "activation epoch" that has been set/validated on the contract itself. Implementations need to validate this or else they are susceptible to activating at a datetime that doesn't meet the restrictions in this proposal. + - **EC.DelayMultiplier:** Adjusts the delay multiplier for the consensus mechanism. + - **EC.BaseDecisionBackoffTable:** Defines the backoff strategy for consensus decisions. + - **EC.HeadLookback:** Determines the how far behind EC is F3 running. + - **GPBFTConfig:** Configures the parameters for the GPBFT consensus protocol. + - **CxConfig:** Configuration of Chain Exchange protocol + - **PubSubConfig:** Configuration of F3’s usage of PubSub. + - **CatchUpAlignment:** Aligns catch-up processes with network requirements. +- The smart contract itself will not do any conformance checking of the manifest data. It is up to implementations to decompress and parse the data and defensively set the allowed parameters. +- The manifest content that is stored in the contract will be DEFLATE-compressed JSON data. + +#### Dynamic Manifest Schema + +> Note: The schema below is provided as an approximation to give readers an understanding of the expected structure. The actual schema may have adjustments based on testing results before the nv25 upgrade. + +
+Click to expand the Dynamic Manifest Schema estimate. + +```json +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "type": "object", + "required": [ + "Pause", + "ProtocolVersion", + "InitialInstance", + "BootstrapEpoch", + "NetworkName", + "CommitteeLookback", + "CatchUpAlignment", + "Gpbft", + "EC", + "CertificateExchange", + "PubSub", + "ChainExchange" + ], + "properties": { + "Pause": { + "type": "boolean", + "description": "Flag to pause the protocol" + }, + "ProtocolVersion": { + "type": "integer", + "minimum": 0, + "description": "Version number of the protocol" + }, + "InitialInstance": { + "type": "integer", + "minimum": 0, + "description": "Initial instance number" + }, + "BootstrapEpoch": { + "type": "integer", + "minimum": 0, + "description": "Epoch number for bootstrapping" + }, + "NetworkName": { + "type": "string", + "description": "Name of the network" + }, + "ExplicitPower": { + "type": ["null", "object"], + "description": "Optional explicit power configuration" + }, + "IgnoreECPower": { + "type": "boolean", + "description": "Flag to ignore EC power" + }, + "InitialPowerTable": { + "type": ["null", "object"], + "description": "Optional initial power table configuration" + }, + "CommitteeLookback": { + "type": "integer", + "minimum": 0, + "description": "Number of blocks to look back for committee" + }, + "CatchUpAlignment": { + "type": "integer", + "minimum": 0, + "description": "Alignment value for catch-up process" + }, + "Gpbft": { + "type": "object", + "required": [ + "Delta", + "DeltaBackOffExponent", + "QualityDeltaMultiplier", + "MaxLookaheadRounds", + "ChainProposedLength", + "RebroadcastBackoffBase", + "RebroadcastBackoffExponent", + "RebroadcastBackoffSpread", + "RebroadcastBackoffMax" + ], + "properties": { + "Delta": { + "type": "integer", + "minimum": 0, + "description": "Base delta value" + }, + "DeltaBackOffExponent": { + "type": "number", + "minimum": 0, + "description": "Exponent for delta backoff calculation" + }, + "QualityDeltaMultiplier": { + "type": "integer", + "minimum": 0, + "description": "Multiplier for quality delta" + }, + "MaxLookaheadRounds": { + "type": "integer", + "minimum": 0, + "description": "Maximum number of lookahead rounds" + }, + "ChainProposedLength": { + "type": "integer", + "minimum": 0, + "description": "Proposed length of the chain" + }, + "RebroadcastBackoffBase": { + "type": "integer", + "minimum": 0, + "description": "Base value for rebroadcast backoff" + }, + "RebroadcastBackoffExponent": { + "type": "number", + "minimum": 0, + "description": "Exponent for rebroadcast backoff" + }, + "RebroadcastBackoffSpread": { + "type": "number", + "minimum": 0, + "description": "Spread value for rebroadcast backoff" + }, + "RebroadcastBackoffMax": { + "type": "integer", + "minimum": 0, + "description": "Maximum rebroadcast backoff value" + } + } + }, + "EC": { + "type": "object", + "required": [ + "Period", + "Finality", + "DelayMultiplier", + "BaseDecisionBackoffTable", + "HeadLookback", + "Finalize" + ], + "properties": { + "Period": { + "type": "integer", + "minimum": 0, + "description": "Period duration" + }, + "Finality": { + "type": "integer", + "minimum": 0, + "description": "Finality parameter" + }, + "DelayMultiplier": { + "type": "integer", + "minimum": 0, + "description": "Multiplier for delay calculations" + }, + "BaseDecisionBackoffTable": { + "type": "array", + "items": { + "type": "number", + "minimum": 0 + }, + "description": "Table of backoff values for base decisions" + }, + "HeadLookback": { + "type": "integer", + "minimum": 0, + "description": "Number of blocks to look back from head" + }, + "Finalize": { + "type": "boolean", + "description": "Flag to enable finalization" + } + } + }, + "CertificateExchange": { + "type": "object", + "required": [ + "ClientRequestTimeout", + "ServerRequestTimeout", + "MinimumPollInterval", + "MaximumPollInterval" + ], + "properties": { + "ClientRequestTimeout": { + "type": "integer", + "minimum": 0, + "description": "Timeout for client requests" + }, + "ServerRequestTimeout": { + "type": "integer", + "minimum": 0, + "description": "Timeout for server requests" + }, + "MinimumPollInterval": { + "type": "integer", + "minimum": 0, + "description": "Minimum interval between polls" + }, + "MaximumPollInterval": { + "type": "integer", + "minimum": 0, + "description": "Maximum interval between polls" + } + } + }, + "PubSub": { + "type": "object", + "required": ["CompressionEnabled"], + "properties": { + "CompressionEnabled": { + "type": "boolean", + "description": "Flag to enable compression" + } + } + }, + "ChainExchange": { + "type": "object", + "required": [ + "SubscriptionBufferSize", + "MaxChainLength", + "MaxInstanceLookahead", + "MaxDiscoveredChainsPerInstance", + "MaxWantedChainsPerInstance", + "RebroadcastInterval", + "MaxTimestampAge" + ], + "properties": { + "SubscriptionBufferSize": { + "type": "integer", + "minimum": 0, + "description": "Size of the subscription buffer" + }, + "MaxChainLength": { + "type": "integer", + "minimum": 0, + "description": "Maximum length of the chain" + }, + "MaxInstanceLookahead": { + "type": "integer", + "minimum": 0, + "description": "Maximum number of instances to look ahead" + }, + "MaxDiscoveredChainsPerInstance": { + "type": "integer", + "minimum": 0, + "description": "Maximum number of discovered chains per instance" + }, + "MaxWantedChainsPerInstance": { + "type": "integer", + "minimum": 0, + "description": "Maximum number of wanted chains per instance" + }, + "RebroadcastInterval": { + "type": "integer", + "minimum": 0, + "description": "Interval between rebroadcasts" + }, + "MaxTimestampAge": { + "type": "integer", + "minimum": 0, + "description": "Maximum age of timestamps" + } + } + } + } +} +``` +
+ +### ABI Sketch + +Below isn't the full ABI, but captures the key functions. See the [implementation notes](#implementation) for links to the full ABI. + +```json +[ + // This will be invoked by the implementers to set the expiration as 2025-08-01T00:00:00Z + { + "name": "constructor", + "type": "constructor", + "inputs": [ + { + "name": "owner", + "type": "address" + }, + { + "name": "expiry", + "type": "uint64" + } + ], + "outputs": [] + }, + // This will be invoked by the implementers to set the activation epoch and "good parameter set". + { + "name": "updateActivationInformation", + "type": "function", + "inputs": [ + { + "name": "activationEpoch", + "type": "uint64" + }, + { + "name": "manifestData", + "type": "bytes" + } + ], + "outputs": [] + }, + // This is the main read method used by implementations. + // It will be polled for determining the activation epoch and "the good parameter set". + { + "name": "activationInformation", + "type": "function", + "inputs": [], + "outputs": [ + { + // activationEpoch + "type": "uint64" + }, + { + // manifestData + "type": "bytes" + } + ] + }, + // Error cases + // Activation epoch is in the past or within 3 days of now. + { + "name": "UpdateActivationEpochInvalid", + "type": "error", + "inputs": [ + { + "name": "currentEpoch", + "type": "uint64" + }, + { + "name": "activationEpoch", + "type": "uint64" + }, + { + "name": "reason", + "type": "string" + } + ], + "outputs": [] + }, + // F3 has already been active. + { + "name": "UpdateAlreadyActive", + "type": "error", + "inputs": [], + "outputs": [] + }, + // It's after 2025-08-01T00:00:00Z + { + "name": "UpdateExpired", + "type": "error", + "inputs": [], + "outputs": [] + } +] +``` + + +### Proposed sequence / example timeline + +*This is an expected sequence of events for using this proposed functionality with an example timeline to aid with clarity on decision points and review periods.* + +| What? | When Starts? | When Completes? | Why? | +| --- | --- | --- | --- | +| create “the multisig contract” | whenever | before deploying “the smart contract” below | Serves as the owner of “the smart contract” and accomplishes multi-stakeholder consensus of the Lotus, Forest, and Venus implementation teams. | +| deploy “the smart contract” that implements this proposal | by 1 week before nv25 Lotus code freeze | by nv25 Lotus code freeze | Give community an opportunity to review/audit “the smart contract” before baking its address into nv25 Lotus/Forest/Venus versions. It should follow the design in this proposal and comply with the constraints that have been outlined. | +| update Lotus/Forest/Venus to hardcode “the smart contract” address | by nv25 Lotus code freeze | by nv25 Lotus code freeze | Prevent any tampering with “the smart contract”’s logic/constraints that were reviewed by the community. | +| nv25 activation | | date X (ideally in Q1) | Filecoin mainnet nodes/miners now have code that has: 1) Improvements / learnings from the nv24 passive testing. 2) Additional knobs for [nv25 passive testing](https://github.com/filecoin-project/go-f3/issues/802). 3) Does a one-time setting of the F3 “good parameter set” based on querying “the smart contract” as discussed in this proposal. | +| [nv25 passive testing](https://github.com/filecoin-project/go-f3/issues/802) | X + 1 or 2 days | X + 2 weeks | Empirical testing to ensure we have a “good parameter set” that works well on mainnet. There will be daily updates on progress and findings, like with nv24, [here](https://github.com/filecoin-project/lotus/discussions/12287). | +| announce proposed f3 parameters, proposed activation date, and rationale for these | X+2.5 weeks (after [nv25 passive testing](https://github.com/filecoin-project/go-f3/issues/802)) | X + 2.5 weeks | Give community full visibility into the proposed f3 “good parameter set” that would be one-time-set via “the smart contract” so we can get input and determine whether we need to make any adjustments. This would be both in English prose in a GitHub community discussion/issue and in PR as a ["task"](https://github.com/filecoin-project/f3-activation-contract/blob/master/tasks/F3Parameters.ts) to run against “the smart contract”. | +| community review period | X+2.5 weeks (after public announcement / PR) | X + 3.5 weeks | Ensure there is buy-in (or at least not major active opposition) to the “good parameter set” and bootstrap epoch. | +| set the bootstrap epoch and “good parameter set” on “the smart contract” with an activation epoch (which is at least 3 days in the future) | X + 3.5 weeks (after community review period) | X + 3.5 weeks | Nodes that are participating in nv25 will pick up the “good parameter set” and start using them at the bootstrap epoch. Given the bootstrap epoch is sufficiently in the future, if an issue wasn’t caught in the previous review period, there is still time to abort by updating “the smart contract” with a bootstrap epoch further in the future and/or to deploy client software that ignores the “good parameter set” values in “the smart contract”. | +| (optional) publish new Lotus, Forest, and Venus versions with the f3 “good parameter set” inline and removal of delegated setting via smart contract | X + 3.5 weeks (after community review period) | X + 3.5 weeks | Operators aren’t required to update to this version, but it gives them a way to run code that no longer has an opening for delegated authority. | +| bootstrap epoch | X + 4 weeks (starts based on the bootstrap epoch that was set as part of publishing “the smart contract”.) | X + 4 weeks | This is what activates F3 on Mainnet. This is what the network has been building towards for months 🙂 | +| active mainnet monitoring | X + 4 weeks (after bootstrap epoch) | Indefinite | F3 in mainnet has now become a default aspect that is monitored and reviewed with other network metrics given its importance for the network. | + +## Design Rationale + +We considered these options: +* ❌ do an extra network upgrade - This was rejected for the reasons outlined in [Change Motivation](#change-motivation): too long on the calendar and too people-taxing on the network. +* ❌ use the same mechanism as passive testing but affect consensus - With passive testing we've already got an ability to dynamically set the F3 parameters. It is centrally owned and managed though by FilOz engineers that have been driving the F3 implementation. Centralization for expediency seemed acceptable when consensus wasn't at play, but the moment that consensus is impacted, we expect network values of decentralization to be followed. +* ❌ propagate manifest values with PubSub - rather than deliver "the good parameter set" via a smart contract, sign a message form pre-arranged and agreed upon libp2p peer id. While this would enable multiple stakeholders, it would miss out on the easier transparency and tooling that we get from living with chain-stored state. Specifically this approach doesn't have the stickiness/immutability that we get from state on chain. It also doesn't have an easy way to canonically reference it. +* ✅ distribute via implementation-team owned smart contract - This idea has been shared at multiple [Filecoin Implementers Working Group](https://filecoindev.notion.site/Filecoin-Implementers-Working-Group-118dc41950c180d08a24f0869aae1c1c) meetings without concern, and the [public discussion](https://github.com/filecoin-project/FIPs/discussions/1102) has not raised opposition to the proposal. We have taken this as approval (or at least acceptance) of this lighter-weight mechanism to move faster while still having a high amount of transparency and safety. + +## Backwards Compatibility + +There is no backward incompatibility introduced by this FRC. Instead, this FRC may be the beginning of a new tool in the ecosystem's toolbelt for being able to make important changes at a faster rate at acceptable safety and transparency levels. + +## Security Considerations + +The following checks and balances are in place to avoid blindsiding anyone in the network and to use the collective community to catch any potential mistakes or security issues: + +1. “the smart contract” code will be open for review for at least a week to help catch any potential vulnerabilities. + 1. Note: we are not planning for this contract to be formally audited because of its simple logic and no user assets being directly at stake. +2. The nv25-compatible Lotus/Forest/Venus releases will hardcode “the smart contract” address such that getting clients to use a tampered-version would require a network version. The PRs for hardcoding “the smart contract” address will be open for review for at least 2 days to allow for verification. (And of course since implementations are open source, the contract can be verified at any point.) See [below](#why-do-implementations-only-hardcode-the-contract-address-vs-other-metadata) for why other contract metadata isn't hardcoded. +3. Updating the state of “the smart contract” with the bootstrap epoch and “good parameter set” will require signing from “the multisig contract”, which has three separate but knowledgeable signing groups (Lotus, Forest, and Venus maintainers). The corresponding blockchain message id will be shared on Slack, GitHub, etc. for clear visibility. +4. The bootstrap epoch set in the message above will be at least 72 hours in the future, providing one more window to course-correct. +5. “the smart contract” code will disregard any bootstrap updates that are 6 months in future of the contract creation date, ensuring this one-time setting mechanism has an upper bound. (It’s expected that its “used once finalization” will occur well before this “self-disablement”.) +6. The “good parameter set” and bootstrap epoch cannot be updated if “the smart contract” has a bootstrap epoch set that is in the past. (This conforms to “use only once and then finalize”.) + + +## Incentive Considerations + +This proposal does not affect incentives. In nv25 and the period immediately following, f3 participation will still be voluntary without any direct charge to SPs who opt out. While we believe SPs have indirect incentivization in the long term to enable F3 because of the wider capabilities it brings to the network, direct incentivization will be designed and encouraged in followup network upgrades (see [current proposal discussion](https://github.com/filecoin-project/FIPs/discussions/1106)). + +## Product Considerations + +For this proposed activation strategy, we believe the guardrails and transparency proposed should have no adverse product impact. Instead, we expect the network will get the [F3 benefits](../FIPS/fip-0086.md#product-considerations) quicker and with less net effort than an additional network upgrade. + +## Implementation + +* smart contract: + * source code: https://github.com/filecoin-project/f3-activation-contract/blob/master/contracts/F3Parameters.sol + * ABI: TODO + * mainnet contract verification: TODO +* multisig owning contract + * address: [0x53bd89Ff2Ff97541f42ACC3AFC0C0030e7410422](https://safe.filecoin.io/address-book?safe=filecoin:0x53bd89Ff2Ff97541f42ACC3AFC0C0030e7410422) + * Lotus public key: [0x6743938A48fC8799A5608EF079C53f3cF3B84398](https://filecoin.blockscout.com/address/0x6743938A48fC8799A5608EF079C53f3cF3B84398) + * Forest public key: TODO + * Venus public key: TODO +* Lotus integration code: TODO ([tracking issue](https://github.com/filecoin-project/go-f3/issues/824)) +* Forest integration code: TODO +* Venus integration code: TODO + +### Test Cases + +* smart contract reading and writing: https://github.com/filecoin-project/f3-activation-contract/blob/master/test/F3Parameters.js +* Lotus integration: TODO +* Forest integration: TODO +* Venus integration: TODO + +## TODO + +* Implementation and integration master tracking issue: https://github.com/filecoin-project/go-f3/issues/828 +* All the "TODO"s referenced above, which are largely related to implementation teams providing their keys, integration code, and test cases. + + +## FAQ + +### Why was this done as an FRC rather than as addition to the F3 FIP? + +[F3 FIP-0086](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0086.md) focuses on the protocol changes, which already has community agreement to ship. This was separated out because it's a discussion on _how_ to deliver the protocol changes that have already been approved. We didn't want the community acceptance of FIP-0086 to be clouded by the delivery vehicle. In addition, we foresee this proposed "delegated authority" approach being a potential pattern to learn from or use again in the future as the ecosystem seeks to move faster while still having safety and community transparency. As a result, we thought this potential case study should be more easily addressed and referenced if it wasn't buried within an already very long FIP. + +### Why do implementations only hardcode the contract address vs. other metadata? + +From a threat model perspective, the implementation teams are supposed to own the the smart contract. In order to be malicious by changing ownership of the smart contract, the "good parameter set" stored within the contract or the contract's logic, they would need to collude. If the implementation teams are all colluding for nefarious purposes, we have much bigger problems. As a result, hard coding in the implementations the owner address or a hash of the of the smart contract code isn't actually buying any extra security. + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). diff --git a/README.md b/README.md index a8a9462ee..6497fd84a 100644 --- a/README.md +++ b/README.md @@ -134,4 +134,4 @@ This improvement protocol helps achieve that objective for all members of the Fi | [0096](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0096.md) | Convert fundraising remainder address(es) to keyless account actor(s) | FIP | @Fatman13 | Draft | | [0097](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0097.md) | Add Support for EIP-1153 (Transient Storage) in the FEVM | FIP | Michael Seiler (@snissn), Steven Allen (@stebalien) | Accepted | | [0098](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0098.md) | Simplify termination fee calculation to a fixed percentage of initial pledge | FIP | Jonathan Schwartz (@Schwartz10), Alex North (@anorth), Jim Pick (@jimpick) | Last Call | -| [XXXX](https://github.com/filecoin-project/FIPs/blob/master/FRCs/frc-retrieval-checking-requirements.md) | Delegation of Authority for F3 Parameter Setting | FRC | @Kubuxu @BigLep | Draft | +| [0099](https://github.com/filecoin-project/FIPs/blob/master/FRCs/frc-0099.md) | Delegation of Authority for F3 Parameter Setting | FRC | @Kubuxu @BigLep | Draft | From e9a2929ec4d1abf8466da650c65b6d704f2d3442 Mon Sep 17 00:00:00 2001 From: Hubert Date: Tue, 11 Feb 2025 15:53:11 +0100 Subject: [PATCH 06/13] add Forest Ethereum address to list (#1119) --- FRCs/frc-0099.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/FRCs/frc-0099.md b/FRCs/frc-0099.md index 08ea4a328..d92f29a63 100644 --- a/FRCs/frc-0099.md +++ b/FRCs/frc-0099.md @@ -501,7 +501,7 @@ For this proposed activation strategy, we believe the guardrails and transparenc * multisig owning contract * address: [0x53bd89Ff2Ff97541f42ACC3AFC0C0030e7410422](https://safe.filecoin.io/address-book?safe=filecoin:0x53bd89Ff2Ff97541f42ACC3AFC0C0030e7410422) * Lotus public key: [0x6743938A48fC8799A5608EF079C53f3cF3B84398](https://filecoin.blockscout.com/address/0x6743938A48fC8799A5608EF079C53f3cF3B84398) - * Forest public key: TODO + * Forest public key: [0xDc9C10232F6A0Db8Bae2e8Fbc24ac1c26141977d](https://filecoin.blockscout.com/address/0xDc9C10232F6A0Db8Bae2e8Fbc24ac1c26141977d) * Venus public key: TODO * Lotus integration code: TODO ([tracking issue](https://github.com/filecoin-project/go-f3/issues/824)) * Forest integration code: TODO From 0e0f3cd361f5fcb6f617f4c297d050a8fc32902e Mon Sep 17 00:00:00 2001 From: tom Date: Thu, 13 Feb 2025 14:31:13 +0800 Subject: [PATCH 07/13] Add Venus address to Delegation of Authority for F3 Parameter Setting (#1120) --- FRCs/frc-0099.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/FRCs/frc-0099.md b/FRCs/frc-0099.md index d92f29a63..c4a5d2b35 100644 --- a/FRCs/frc-0099.md +++ b/FRCs/frc-0099.md @@ -502,7 +502,7 @@ For this proposed activation strategy, we believe the guardrails and transparenc * address: [0x53bd89Ff2Ff97541f42ACC3AFC0C0030e7410422](https://safe.filecoin.io/address-book?safe=filecoin:0x53bd89Ff2Ff97541f42ACC3AFC0C0030e7410422) * Lotus public key: [0x6743938A48fC8799A5608EF079C53f3cF3B84398](https://filecoin.blockscout.com/address/0x6743938A48fC8799A5608EF079C53f3cF3B84398) * Forest public key: [0xDc9C10232F6A0Db8Bae2e8Fbc24ac1c26141977d](https://filecoin.blockscout.com/address/0xDc9C10232F6A0Db8Bae2e8Fbc24ac1c26141977d) - * Venus public key: TODO + * Venus public key: [0x82A16435509bAa9b8Fe71D8260CCf6C601b1b6eD](https://filecoin.blockscout.com/address/0x82A16435509bAa9b8Fe71D8260CCf6C601b1b6eD) * Lotus integration code: TODO ([tracking issue](https://github.com/filecoin-project/go-f3/issues/824)) * Forest integration code: TODO * Venus integration code: TODO From b62aef7e5f8e28cb207934351dfa914e512fbd96 Mon Sep 17 00:00:00 2001 From: Steve Loeppky Date: Tue, 25 Feb 2025 23:35:30 -0800 Subject: [PATCH 08/13] Set FIP-0098 as Accepted Marking as accepted given the FIP editor approvals and no community pushback. --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index d9c4d4c08..f9c4767ce 100644 --- a/README.md +++ b/README.md @@ -134,6 +134,6 @@ This improvement protocol helps achieve that objective for all members of the Fi | [0096](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0096.md) | Convert fundraising remainder address(es) to keyless account actor(s) | FIP | @Fatman13 | Draft | | [0097](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0097.md) | Add Support for EIP-1153 (Transient Storage) in the FEVM | FIP | Michael Seiler (@snissn), Steven Allen (@stebalien) | Accepted | | [0098](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0098.md) | Simplify termination fee calculation to a fixed percentage of initial pledge | FIP | Jonathan Schwartz (@Schwartz10), Alex North (@anorth), Jim Pick (@jimpick) | Last Call | -| [0099](https://github.com/filecoin-project/FIPs/blob/master/FRCs/frc-0099.md) | Delegation of Authority for F3 Parameter Setting | FRC | @Kubuxu @BigLep | Draft | +| [0099](https://github.com/filecoin-project/FIPs/blob/master/FRCs/frc-0099.md) | Delegation of Authority for F3 Parameter Setting | FRC | @Kubuxu @BigLep | Accepted | | [0100](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0100.md) | Removing Batch Balancer, Replacing It With a Per-sector Fee and Removing Gas-limited Constraints | FIP | irene (@irenegia), AX (@AxCortesCubero), rvagg (@rvagg), molly (@momack2), kiran (@kkarrancsu)| Last Call | | [0101](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0101.md) | Removal of the ProveCommitAggregate method from the miner actor | FIP | Rod Vagg (@rvagg) | Draft | From 2c3c2ed19d66c07b65cfd71c72f087cb0fa07b02 Mon Sep 17 00:00:00 2001 From: Steve Loeppky Date: Wed, 26 Feb 2025 00:42:42 -0700 Subject: [PATCH 09/13] Removing file from before FIP number was assigned. --- FRCs/frc-f3_delegated_authority.md | 539 ----------------------------- 1 file changed, 539 deletions(-) delete mode 100644 FRCs/frc-f3_delegated_authority.md diff --git a/FRCs/frc-f3_delegated_authority.md b/FRCs/frc-f3_delegated_authority.md deleted file mode 100644 index 0a3927e7f..000000000 --- a/FRCs/frc-f3_delegated_authority.md +++ /dev/null @@ -1,539 +0,0 @@ ---- -fip: "" -title: Delegation of Authority for F3 Parameter Setting -author: "@Kubuxu @BigLep" -discussions-to: https://github.com/filecoin-project/FIPs/discussions/1102 -status: Draft -type: FRC -created: 2025-01-30 -requires (*optional): FIP-0086 -# category: -# spec-sections: -# - -# - -#replaces (*optional): ---- - - - -# FIP-Number: Title - -## Simple Summary - -Avoid a full network upgrade for setting F3 activation parameters by instead delegating parameter setting to the Lotus, Forest, and Venus implementation teams, who will set these parameters using a multisig-owned smart contract for one-time use on mainnet. - -## Abstract - -This FRC proposes introducing an on-chain smart contract that can manage F3 parameters dynamically. This contract would be owned/controlled through a multi-signature mechanism requiring consensus from all three major Filecoin implementations (Lotus, Forest, and Venus). The contract would allow for a one-time parameter update based on mainnet passive test results, effectively combining what would have been two network upgrades into one while maintaining security through multiple stakeholder approval, full on-chain transparency, and built-in time delays for community review. Additionally, the contract is designed to automatically disable itself after the F3 activation date or 2025-08-01, whichever comes first, ensuring that any changes are deliberate and well-considered, while preventing indefinite alterations. - -## Change Motivation - -The Fast Finality (F3) feature for Filecoin requires comprehensive testing under mainnet conditions to ensure its effectiveness and reliability. These live network conditions are challenging to replicate in test environments, and thus, the parameters for F3 are contingent upon the results of these mainnet tests. By default this necessitates two distinct network upgrades: one enabling Storage Providers to update their software for testing purposes, and a subsequent one for setting the finalized parameters. As of 202501, network upgrades are "costly" in terms of the multiple party coordination and for good reasons take a couple of calendar months to fully execute in non-emergency situations. Implementers who are taking on delivering F3, as already approved by the network in [FIP-0086](../FIPS/fip-0086.md), want to deliver the benefits of F3 to the network faster while minimizing the "people resource" consumption on the network and their teams. (See https://github.com/filecoin-project/go-f3/issues/800 for more info.) - -### Terminology - -*Below are common terms used throughout the rest of this document.* - -- nv25 - The network upgrade that will deliver the next batch of F3 protocol and code changes, which we also expect is the last network upgrade for activating F3 on mainnet. -- "the implementations" - This means the main major Filecoin implementations: Lotus, Forest, and Venus. -- “the smart contract” - This is the smart contract referred to in this proposal that contains the “good parameter set” and the bootstrap epoch. The source code will live in [filecoin-project/f3-activation-contract](https://github.com/filecoin-project/f3-activation-contract) and its address will be hardcoded in Lotus/Forest/Venus nv25-compatible releases. The owner address is "the multisig contract" discussed below. -- “good parameter set” - This is the set of F3 configuration parameters that will be determined as part of [nv25 mainnet passive testing](https://github.com/filecoin-project/go-f3/issues/802). This parameter set will have sustained demonstrated success in mainnet. It will be stored in "the smart contract" as DEFLATE compressed JSON data, and it will be consumed by "the implementations". -- “the multisig contract” - This is a standard off-the-shelf multisig EVM contract ([Gnosis Safe](https://safe.global)) that will be the owner of “the smart contract”. As a result, “the smart contract” will only accept updates from this multisig contract. This is the mechanism by which we accomplish multi-stakeholder consensus of the Lotus, Forest, and Venus implementation teams. - - -## Specification - -To streamline this process and enhance flexibility, we propose delegating the authority for setting F3 parameters to an on-chain contract so F3 activation in mainnet can be accomplished with one network upgrade rather than two. This contract will be responsible for managing a predefined set of parameters and making go/no-go decisions regarding their implementation. - -### On-Chain Contract for Parameter Management -- Move the parameter setting from the build phase to an on-chain contract, allowing for a singular dynamic update based on real-time test results. -- This contract will live in a new public repo: [filecoin-project/f3-activation-contract](https://github.com/filecoin-project/f3-activation-contract) - - Note: while we’ll restrict write access to the repo to Lotus, Forest, and Venus maintainers for general repo hygiene, repo write access isn’t the chief concern. The key decision is the groups that have the ability to update the state of the published mainnet contract (discussed more below). - -### Key Verification -- Key ownership is communicated by each implementation team adding their keys to this FRC via PR in the [Implementation section](#implementation). -- One can then following the chain of _contract address hardcoded in implementations_ → _contract address owner_ → _inspect the multisig at https://safe.filecoin.io/home?safe=filecoin:ADDRESS_ → _ensure keys from [Implementation section](#implementation) are present_ - -### Controlled Update Mechanism -- Parameter updates will require full consensus amongst each of the Filecoin implementations: Lotus, Forest, and Venus. This is implemented with a multisig requiring 3 of 3. -- Each of the three implementation teams will send signed messages to authorize changes, ensuring security and agreement among stakeholders. - -### Finalization and Self-Disabling -- This would have “used once finalization”. The contract does not permit further updates if the currently set bootstrap epoch is in the past. -- Assuming bootstrap hasn't already finalized the contract, it is designed to automatically disable itself on 2025-08-01T00:00:00Z, ensuring that any changes are deliberate and well-considered, while preventing indefinite alterations. - - This means the bootstrap epoch must be before 2025-08-01. - - There is no contingency plan beyond another network upgrade. If for some reason F3 still isn’t activated within this ~6 month window, a network upgrade will be required to update client software to point to a new contract. - -### Content of the Dynamic Manifest -- The content of the dynamic manifest is expected to comply with or be similar to [schema below](#dynamic-manifest-schema). (There may be some shifts in the parameters based on testing from before the nv25 upgrade.) -- Some of the most important attributes include: - - **Bootstrap Epoch:** - - Specifies the activation time, set no sooner than 72 hours from message transmission. This is intended to give the community an additional window to react in case there late-discovered issues with the parameters/rollout. See [Proposed sequence / example timeline](#proposed-sequence--example-timeline) for more context. - - This should match the "activation epoch" that has been set/validated on the contract itself. Implementations need to validate this or else they are susceptible to activating at a datetime that doesn't meet the restrictions in this proposal. - - **EC.DelayMultiplier:** Adjusts the delay multiplier for the consensus mechanism. - - **EC.BaseDecisionBackoffTable:** Defines the backoff strategy for consensus decisions. - - **EC.HeadLookback:** Determines the how far behind EC is F3 running. - - **GPBFTConfig:** Configures the parameters for the GPBFT consensus protocol. - - **CxConfig:** Configuration of Chain Exchange protocol - - **PubSubConfig:** Configuration of F3’s usage of PubSub. - - **CatchUpAlignment:** Aligns catch-up processes with network requirements. -- The smart contract itself will not do any conformance checking of the manifest data. It is up to implementations to decompress and parse the data and defensively set the allowed parameters. -- The manifest content that is stored in the contract will be DEFLATE-compressed JSON data. - -#### Dynamic Manifest Schema - -> Note: The schema below is provided as an approximation to give readers an understanding of the expected structure. The actual schema may have adjustments based on testing results before the nv25 upgrade. - -
-Click to expand the Dynamic Manifest Schema estimate. - -```json -{ - "$schema": "http://json-schema.org/draft-07/schema#", - "type": "object", - "required": [ - "Pause", - "ProtocolVersion", - "InitialInstance", - "BootstrapEpoch", - "NetworkName", - "CommitteeLookback", - "CatchUpAlignment", - "Gpbft", - "EC", - "CertificateExchange", - "PubSub", - "ChainExchange" - ], - "properties": { - "Pause": { - "type": "boolean", - "description": "Flag to pause the protocol" - }, - "ProtocolVersion": { - "type": "integer", - "minimum": 0, - "description": "Version number of the protocol" - }, - "InitialInstance": { - "type": "integer", - "minimum": 0, - "description": "Initial instance number" - }, - "BootstrapEpoch": { - "type": "integer", - "minimum": 0, - "description": "Epoch number for bootstrapping" - }, - "NetworkName": { - "type": "string", - "description": "Name of the network" - }, - "ExplicitPower": { - "type": ["null", "object"], - "description": "Optional explicit power configuration" - }, - "IgnoreECPower": { - "type": "boolean", - "description": "Flag to ignore EC power" - }, - "InitialPowerTable": { - "type": ["null", "object"], - "description": "Optional initial power table configuration" - }, - "CommitteeLookback": { - "type": "integer", - "minimum": 0, - "description": "Number of blocks to look back for committee" - }, - "CatchUpAlignment": { - "type": "integer", - "minimum": 0, - "description": "Alignment value for catch-up process" - }, - "Gpbft": { - "type": "object", - "required": [ - "Delta", - "DeltaBackOffExponent", - "QualityDeltaMultiplier", - "MaxLookaheadRounds", - "ChainProposedLength", - "RebroadcastBackoffBase", - "RebroadcastBackoffExponent", - "RebroadcastBackoffSpread", - "RebroadcastBackoffMax" - ], - "properties": { - "Delta": { - "type": "integer", - "minimum": 0, - "description": "Base delta value" - }, - "DeltaBackOffExponent": { - "type": "number", - "minimum": 0, - "description": "Exponent for delta backoff calculation" - }, - "QualityDeltaMultiplier": { - "type": "integer", - "minimum": 0, - "description": "Multiplier for quality delta" - }, - "MaxLookaheadRounds": { - "type": "integer", - "minimum": 0, - "description": "Maximum number of lookahead rounds" - }, - "ChainProposedLength": { - "type": "integer", - "minimum": 0, - "description": "Proposed length of the chain" - }, - "RebroadcastBackoffBase": { - "type": "integer", - "minimum": 0, - "description": "Base value for rebroadcast backoff" - }, - "RebroadcastBackoffExponent": { - "type": "number", - "minimum": 0, - "description": "Exponent for rebroadcast backoff" - }, - "RebroadcastBackoffSpread": { - "type": "number", - "minimum": 0, - "description": "Spread value for rebroadcast backoff" - }, - "RebroadcastBackoffMax": { - "type": "integer", - "minimum": 0, - "description": "Maximum rebroadcast backoff value" - } - } - }, - "EC": { - "type": "object", - "required": [ - "Period", - "Finality", - "DelayMultiplier", - "BaseDecisionBackoffTable", - "HeadLookback", - "Finalize" - ], - "properties": { - "Period": { - "type": "integer", - "minimum": 0, - "description": "Period duration" - }, - "Finality": { - "type": "integer", - "minimum": 0, - "description": "Finality parameter" - }, - "DelayMultiplier": { - "type": "integer", - "minimum": 0, - "description": "Multiplier for delay calculations" - }, - "BaseDecisionBackoffTable": { - "type": "array", - "items": { - "type": "number", - "minimum": 0 - }, - "description": "Table of backoff values for base decisions" - }, - "HeadLookback": { - "type": "integer", - "minimum": 0, - "description": "Number of blocks to look back from head" - }, - "Finalize": { - "type": "boolean", - "description": "Flag to enable finalization" - } - } - }, - "CertificateExchange": { - "type": "object", - "required": [ - "ClientRequestTimeout", - "ServerRequestTimeout", - "MinimumPollInterval", - "MaximumPollInterval" - ], - "properties": { - "ClientRequestTimeout": { - "type": "integer", - "minimum": 0, - "description": "Timeout for client requests" - }, - "ServerRequestTimeout": { - "type": "integer", - "minimum": 0, - "description": "Timeout for server requests" - }, - "MinimumPollInterval": { - "type": "integer", - "minimum": 0, - "description": "Minimum interval between polls" - }, - "MaximumPollInterval": { - "type": "integer", - "minimum": 0, - "description": "Maximum interval between polls" - } - } - }, - "PubSub": { - "type": "object", - "required": ["CompressionEnabled"], - "properties": { - "CompressionEnabled": { - "type": "boolean", - "description": "Flag to enable compression" - } - } - }, - "ChainExchange": { - "type": "object", - "required": [ - "SubscriptionBufferSize", - "MaxChainLength", - "MaxInstanceLookahead", - "MaxDiscoveredChainsPerInstance", - "MaxWantedChainsPerInstance", - "RebroadcastInterval", - "MaxTimestampAge" - ], - "properties": { - "SubscriptionBufferSize": { - "type": "integer", - "minimum": 0, - "description": "Size of the subscription buffer" - }, - "MaxChainLength": { - "type": "integer", - "minimum": 0, - "description": "Maximum length of the chain" - }, - "MaxInstanceLookahead": { - "type": "integer", - "minimum": 0, - "description": "Maximum number of instances to look ahead" - }, - "MaxDiscoveredChainsPerInstance": { - "type": "integer", - "minimum": 0, - "description": "Maximum number of discovered chains per instance" - }, - "MaxWantedChainsPerInstance": { - "type": "integer", - "minimum": 0, - "description": "Maximum number of wanted chains per instance" - }, - "RebroadcastInterval": { - "type": "integer", - "minimum": 0, - "description": "Interval between rebroadcasts" - }, - "MaxTimestampAge": { - "type": "integer", - "minimum": 0, - "description": "Maximum age of timestamps" - } - } - } - } -} -``` -
- -### ABI Sketch - -Below isn't the full ABI, but captures the key functions. See the [implementation notes](#implementation) for links to the full ABI. - -```json -[ - // This will be invoked by the implementers to set the expiration as 2025-08-01T00:00:00Z - { - "name": "constructor", - "type": "constructor", - "inputs": [ - { - "name": "owner", - "type": "address" - }, - { - "name": "expiry", - "type": "uint64" - } - ], - "outputs": [] - }, - // This will be invoked by the implementers to set the activation epoch and "good parameter set". - { - "name": "updateActivationInformation", - "type": "function", - "inputs": [ - { - "name": "activationEpoch", - "type": "uint64" - }, - { - "name": "manifestData", - "type": "bytes" - } - ], - "outputs": [] - }, - // This is the main read method used by implementations. - // It will be polled for determining the activation epoch and "the good parameter set". - { - "name": "activationInformation", - "type": "function", - "inputs": [], - "outputs": [ - { - // activationEpoch - "type": "uint64" - }, - { - // manifestData - "type": "bytes" - } - ] - }, - // Error cases - // Activation epoch is in the past or within 3 days of now. - { - "name": "UpdateActivationEpochInvalid", - "type": "error", - "inputs": [ - { - "name": "currentEpoch", - "type": "uint64" - }, - { - "name": "activationEpoch", - "type": "uint64" - }, - { - "name": "reason", - "type": "string" - } - ], - "outputs": [] - }, - // F3 has already been active. - { - "name": "UpdateAlreadyActive", - "type": "error", - "inputs": [], - "outputs": [] - }, - // It's after 2025-08-01T00:00:00Z - { - "name": "UpdateExpired", - "type": "error", - "inputs": [], - "outputs": [] - } -] -``` - - -### Proposed sequence / example timeline - -*This is an expected sequence of events for using this proposed functionality with an example timeline to aid with clarity on decision points and review periods.* - -| What? | When Starts? | When Completes? | Why? | -| --- | --- | --- | --- | -| create “the multisig contract” | whenever | before deploying “the smart contract” below | Serves as the owner of “the smart contract” and accomplishes multi-stakeholder consensus of the Lotus, Forest, and Venus implementation teams. | -| deploy “the smart contract” that implements this proposal | by 1 week before nv25 Lotus code freeze | by nv25 Lotus code freeze | Give community an opportunity to review/audit “the smart contract” before baking its address into nv25 Lotus/Forest/Venus versions. It should follow the design in this proposal and comply with the constraints that have been outlined. | -| update Lotus/Forest/Venus to hardcode “the smart contract” address | by nv25 Lotus code freeze | by nv25 Lotus code freeze | Prevent any tampering with “the smart contract”’s logic/constraints that were reviewed by the community. | -| nv25 activation | | date X (ideally in Q1) | Filecoin mainnet nodes/miners now have code that has: 1) Improvements / learnings from the nv24 passive testing. 2) Additional knobs for [nv25 passive testing](https://github.com/filecoin-project/go-f3/issues/802). 3) Does a one-time setting of the F3 “good parameter set” based on querying “the smart contract” as discussed in this proposal. | -| [nv25 passive testing](https://github.com/filecoin-project/go-f3/issues/802) | X + 1 or 2 days | X + 2 weeks | Empirical testing to ensure we have a “good parameter set” that works well on mainnet. There will be daily updates on progress and findings, like with nv24, [here](https://github.com/filecoin-project/lotus/discussions/12287). | -| announce proposed f3 parameters, proposed activation date, and rationale for these | X+2.5 weeks (after [nv25 passive testing](https://github.com/filecoin-project/go-f3/issues/802)) | X + 2.5 weeks | Give community full visibility into the proposed f3 “good parameter set” that would be one-time-set via “the smart contract” so we can get input and determine whether we need to make any adjustments. This would be both in English prose in a GitHub community discussion/issue and in PR as a ["task"](https://github.com/filecoin-project/f3-activation-contract/blob/master/tasks/F3Parameters.ts) to run against “the smart contract”. | -| community review period | X+2.5 weeks (after public announcement / PR) | X + 3.5 weeks | Ensure there is buy-in (or at least not major active opposition) to the “good parameter set” and bootstrap epoch. | -| set the bootstrap epoch and “good parameter set” on “the smart contract” with an activation epoch (which is at least 3 days in the future) | X + 3.5 weeks (after community review period) | X + 3.5 weeks | Nodes that are participating in nv25 will pick up the “good parameter set” and start using them at the bootstrap epoch. Given the bootstrap epoch is sufficiently in the future, if an issue wasn’t caught in the previous review period, there is still time to abort by updating “the smart contract” with a bootstrap epoch further in the future and/or to deploy client software that ignores the “good parameter set” values in “the smart contract”. | -| (optional) publish new Lotus, Forest, and Venus versions with the f3 “good parameter set” inline and removal of delegated setting via smart contract | X + 3.5 weeks (after community review period) | X + 3.5 weeks | Operators aren’t required to update to this version, but it gives them a way to run code that no longer has an opening for delegated authority. | -| bootstrap epoch | X + 4 weeks (starts based on the bootstrap epoch that was set as part of publishing “the smart contract”.) | X + 4 weeks | This is what activates F3 on Mainnet. This is what the network has been building towards for months 🙂 | -| active mainnet monitoring | X + 4 weeks (after bootstrap epoch) | Indefinite | F3 in mainnet has now become a default aspect that is monitored and reviewed with other network metrics given its importance for the network. | - -## Design Rationale - -We considered these options: -* ❌ do an extra network upgrade - This was rejected for the reasons outlined in [Change Motivation](#change-motivation): too long on the calendar and too people-taxing on the network. -* ❌ use the same mechanism as passive testing but affect consensus - With passive testing we've already got an ability to dynamically set the F3 parameters. It is centrally owned and managed though by FilOz engineers that have been driving the F3 implementation. Centralization for expediency seemed acceptable when consensus wasn't at play, but the moment that consensus is impacted, we expect network values of decentralization to be followed. -* ❌ propagate manifest values with PubSub - rather than deliver "the good parameter set" via a smart contract, sign a message form pre-arranged and agreed upon libp2p peer id. While this would enable multiple stakeholders, it would miss out on the easier transparency and tooling that we get from living with chain-stored state. Specifically this approach doesn't have the stickiness/immutability that we get from state on chain. It also doesn't have an easy way to canonically reference it. -* ✅ distribute via implementation-team owned smart contract - This idea has been shared at multiple [Filecoin Implementers Working Group](https://filecoindev.notion.site/Filecoin-Implementers-Working-Group-118dc41950c180d08a24f0869aae1c1c) meetings without concern, and the [public discussion](https://github.com/filecoin-project/FIPs/discussions/1102) has not raised opposition to the proposal. We have taken this as approval (or at least acceptance) of this lighter-weight mechanism to move faster while still having a high amount of transparency and safety. - -## Backwards Compatibility - -There is no backward incompatibility introduced by this FRC. Instead, this FRC may be the beginning of a new tool in the ecosystem's toolbelt for being able to make important changes at a faster rate at acceptable safety and transparency levels. - -## Security Considerations - -The following checks and balances are in place to avoid blindsiding anyone in the network and to use the collective community to catch any potential mistakes or security issues: - -1. “the smart contract” code will be open for review for at least a week to help catch any potential vulnerabilities. - 1. Note: we are not planning for this contract to be formally audited because of its simple logic and no user assets being directly at stake. -2. The nv25-compatible Lotus/Forest/Venus releases will hardcode “the smart contract” address such that getting clients to use a tampered-version would require a network version. The PRs for hardcoding “the smart contract” address will be open for review for at least 2 days to allow for verification. (And of course since implementations are open source, the contract can be verified at any point.) See [below](#why-do-implementations-only-hardcode-the-contract-address-vs-other-metadata) for why other contract metadata isn't hardcoded. -3. Updating the state of “the smart contract” with the bootstrap epoch and “good parameter set” will require signing from “the multisig contract”, which has three separate but knowledgeable signing groups (Lotus, Forest, and Venus maintainers). The corresponding blockchain message id will be shared on Slack, GitHub, etc. for clear visibility. -4. The bootstrap epoch set in the message above will be at least 72 hours in the future, providing one more window to course-correct. -5. “the smart contract” code will disregard any bootstrap updates that are 6 months in future of the contract creation date, ensuring this one-time setting mechanism has an upper bound. (It’s expected that its “used once finalization” will occur well before this “self-disablement”.) -6. The “good parameter set” and bootstrap epoch cannot be updated if “the smart contract” has a bootstrap epoch set that is in the past. (This conforms to “use only once and then finalize”.) - - -## Incentive Considerations - -This proposal does not affect incentives. In nv25 and the period immediately following, f3 participation will still be voluntary without any direct charge to SPs who opt out. While we believe SPs have indirect incentivization in the long term to enable F3 because of the wider capabilities it brings to the network, direct incentivization will be designed and encouraged in followup network upgrades (see [current proposal discussion](https://github.com/filecoin-project/FIPs/discussions/1106)). - -## Product Considerations - -For this proposed activation strategy, we believe the guardrails and transparency proposed should have no adverse product impact. Instead, we expect the network will get the [F3 benefits](../FIPS/fip-0086.md#product-considerations) quicker and with less net effort than an additional network upgrade. - -## Implementation - -* smart contract: - * source code: https://github.com/filecoin-project/f3-activation-contract/blob/master/contracts/F3Parameters.sol - * ABI: TODO - * mainnet contract verification: TODO -* multisig owning contract - * address: [0x53bd89Ff2Ff97541f42ACC3AFC0C0030e7410422](https://safe.filecoin.io/address-book?safe=filecoin:0x53bd89Ff2Ff97541f42ACC3AFC0C0030e7410422) - * Lotus public key: [0x6743938A48fC8799A5608EF079C53f3cF3B84398](https://filecoin.blockscout.com/address/0x6743938A48fC8799A5608EF079C53f3cF3B84398) - * Forest public key: TODO - * Venus public key: TODO -* Lotus integration code: TODO ([tracking issue](https://github.com/filecoin-project/go-f3/issues/824)) -* Forest integration code: TODO -* Venus integration code: TODO - -### Test Cases - -* smart contract reading and writing: https://github.com/filecoin-project/f3-activation-contract/blob/master/test/F3Parameters.js -* Lotus integration: TODO -* Forest integration: TODO -* Venus integration: TODO - -## TODO - -* Implementation and integration master tracking issue: https://github.com/filecoin-project/go-f3/issues/828 -* All the "TODO"s referenced above, which are largely related to implementation teams providing their keys, integration code, and test cases. - - -## FAQ - -### Why was this done as an FRC rather than as addition to the F3 FIP? - -[F3 FIP-0086](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0086.md) focuses on the protocol changes, which already has community agreement to ship. This was separated out because it's a discussion on _how_ to deliver the protocol changes that have already been approved. We didn't want the community acceptance of FIP-0086 to be clouded by the delivery vehicle. In addition, we foresee this proposed "delegated authority" approach being a potential pattern to learn from or use again in the future as the ecosystem seeks to move faster while still having safety and community transparency. As a result, we thought this potential case study should be more easily addressed and referenced if it wasn't buried within an already very long FIP. - -### Why do implementations only hardcode the contract address vs. other metadata? - -From a threat model perspective, the implementation teams are supposed to own the the smart contract. In order to be malicious by changing ownership of the smart contract, the "good parameter set" stored within the contract or the contract's logic, they would need to collude. If the implementation teams are all colluding for nefarious purposes, we have much bigger problems. As a result, hard coding in the implementations the owner address or a hash of the of the smart contract code isn't actually buying any extra security. - -## Copyright -Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From c470287bf43331a4e2433078d63f1d9ba375a4a7 Mon Sep 17 00:00:00 2001 From: Steve Loeppky Date: Tue, 25 Feb 2025 23:46:51 -0800 Subject: [PATCH 10/13] Updated integration code links --- FRCs/frc-0099.md | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/FRCs/frc-0099.md b/FRCs/frc-0099.md index c4a5d2b35..9acad8160 100644 --- a/FRCs/frc-0099.md +++ b/FRCs/frc-0099.md @@ -503,16 +503,14 @@ For this proposed activation strategy, we believe the guardrails and transparenc * Lotus public key: [0x6743938A48fC8799A5608EF079C53f3cF3B84398](https://filecoin.blockscout.com/address/0x6743938A48fC8799A5608EF079C53f3cF3B84398) * Forest public key: [0xDc9C10232F6A0Db8Bae2e8Fbc24ac1c26141977d](https://filecoin.blockscout.com/address/0xDc9C10232F6A0Db8Bae2e8Fbc24ac1c26141977d) * Venus public key: [0x82A16435509bAa9b8Fe71D8260CCf6C601b1b6eD](https://filecoin.blockscout.com/address/0x82A16435509bAa9b8Fe71D8260CCf6C601b1b6eD) -* Lotus integration code: TODO ([tracking issue](https://github.com/filecoin-project/go-f3/issues/824)) -* Forest integration code: TODO -* Venus integration code: TODO +* Lotus integration code: https://github.com/filecoin-project/lotus/pull/12861 +* Forest integration code: https://github.com/ChainSafe/forest/pull/5321 +* Venus integration code: https://github.com/filecoin-project/venus/pull/6447 ### Test Cases * smart contract reading and writing: https://github.com/filecoin-project/f3-activation-contract/blob/master/test/F3Parameters.js -* Lotus integration: TODO -* Forest integration: TODO -* Venus integration: TODO +* See also the implementation integrations above for their unit tests ## TODO From 68e0cbfc55685a049f9419f4f835b43ba7c50e53 Mon Sep 17 00:00:00 2001 From: Jakub Sztandera Date: Fri, 21 Feb 2025 17:16:34 +0100 Subject: [PATCH 11/13] Change the link to settings page so signers and threshold are visible Signed-off-by: Jakub Sztandera --- FRCs/frc-0099.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/FRCs/frc-0099.md b/FRCs/frc-0099.md index 9acad8160..f003a48dd 100644 --- a/FRCs/frc-0099.md +++ b/FRCs/frc-0099.md @@ -499,7 +499,7 @@ For this proposed activation strategy, we believe the guardrails and transparenc * ABI: TODO * mainnet contract verification: TODO * multisig owning contract - * address: [0x53bd89Ff2Ff97541f42ACC3AFC0C0030e7410422](https://safe.filecoin.io/address-book?safe=filecoin:0x53bd89Ff2Ff97541f42ACC3AFC0C0030e7410422) + * address: [0x53bd89Ff2Ff97541f42ACC3AFC0C0030e7410422](https://safe.filecoin.io/settings/setup?safe=filecoin:0x53bd89Ff2Ff97541f42ACC3AFC0C0030e7410422) * Lotus public key: [0x6743938A48fC8799A5608EF079C53f3cF3B84398](https://filecoin.blockscout.com/address/0x6743938A48fC8799A5608EF079C53f3cF3B84398) * Forest public key: [0xDc9C10232F6A0Db8Bae2e8Fbc24ac1c26141977d](https://filecoin.blockscout.com/address/0xDc9C10232F6A0Db8Bae2e8Fbc24ac1c26141977d) * Venus public key: [0x82A16435509bAa9b8Fe71D8260CCf6C601b1b6eD](https://filecoin.blockscout.com/address/0x82A16435509bAa9b8Fe71D8260CCf6C601b1b6eD) From 5387a649aee88cf079f2c44ebd0ad51c10972d51 Mon Sep 17 00:00:00 2001 From: Jakub Sztandera Date: Wed, 26 Feb 2025 16:19:20 +0100 Subject: [PATCH 12/13] Add contract infromation Signed-off-by: Jakub Sztandera --- FRCs/frc-0099.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/FRCs/frc-0099.md b/FRCs/frc-0099.md index f003a48dd..8ffaf019b 100644 --- a/FRCs/frc-0099.md +++ b/FRCs/frc-0099.md @@ -496,8 +496,9 @@ For this proposed activation strategy, we believe the guardrails and transparenc * smart contract: * source code: https://github.com/filecoin-project/f3-activation-contract/blob/master/contracts/F3Parameters.sol - * ABI: TODO - * mainnet contract verification: TODO + * ABI: [.abi in this file](https://github.com/filecoin-project/f3-activation-contract/blob/master/ignition/deployments/mainnet/artifacts/F3ParametersModule%23F3Parameters.json) + * Mainnet contract address: 0xA19080A1Bcb82Bb61bcb9691EC94653Eb5315716 + * mainnet contract verification: [blockscout](https://filecoin.blockscout.com/address/0xA19080A1Bcb82Bb61bcb9691EC94653Eb5315716?tab=contract) * multisig owning contract * address: [0x53bd89Ff2Ff97541f42ACC3AFC0C0030e7410422](https://safe.filecoin.io/settings/setup?safe=filecoin:0x53bd89Ff2Ff97541f42ACC3AFC0C0030e7410422) * Lotus public key: [0x6743938A48fC8799A5608EF079C53f3cF3B84398](https://filecoin.blockscout.com/address/0x6743938A48fC8799A5608EF079C53f3cF3B84398) From 0c75f3b07cdd7ac0fed8ba05a766e8b3193352ff Mon Sep 17 00:00:00 2001 From: Steve Loeppky Date: Wed, 26 Feb 2025 07:24:51 -0800 Subject: [PATCH 13/13] Fix merge mistake since FIP-0098 is accepted --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index f9c4767ce..7c03ff39d 100644 --- a/README.md +++ b/README.md @@ -133,7 +133,7 @@ This improvement protocol helps achieve that objective for all members of the Fi | [0095](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0095.md) | Add FEVM precompile to fetch beacon digest from chain history | FIP | @ZenGround0, Alex North (@anorth) | Final | | [0096](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0096.md) | Convert fundraising remainder address(es) to keyless account actor(s) | FIP | @Fatman13 | Draft | | [0097](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0097.md) | Add Support for EIP-1153 (Transient Storage) in the FEVM | FIP | Michael Seiler (@snissn), Steven Allen (@stebalien) | Accepted | -| [0098](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0098.md) | Simplify termination fee calculation to a fixed percentage of initial pledge | FIP | Jonathan Schwartz (@Schwartz10), Alex North (@anorth), Jim Pick (@jimpick) | Last Call | +| [0098](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0098.md) | Simplify termination fee calculation to a fixed percentage of initial pledge | FIP | Jonathan Schwartz (@Schwartz10), Alex North (@anorth), Jim Pick (@jimpick) | Accepted | | [0099](https://github.com/filecoin-project/FIPs/blob/master/FRCs/frc-0099.md) | Delegation of Authority for F3 Parameter Setting | FRC | @Kubuxu @BigLep | Accepted | | [0100](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0100.md) | Removing Batch Balancer, Replacing It With a Per-sector Fee and Removing Gas-limited Constraints | FIP | irene (@irenegia), AX (@AxCortesCubero), rvagg (@rvagg), molly (@momack2), kiran (@kkarrancsu)| Last Call | | [0101](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0101.md) | Removal of the ProveCommitAggregate method from the miner actor | FIP | Rod Vagg (@rvagg) | Draft |