Repurposing BlockHeader.ForkSignaling for Network Coordination #1221
Replies: 2 comments 1 reply
-
|
Thanks for starting this @rvagg . The proposal makes sense to me. A few things that I think could be added when converting this to an FRC. ExampleLets assume the following (coming from https://github.com/filecoin-project/core-devs/blob/master/upgrades.json)
Could we maybe outline what we'd expect
I want to make sure it's clear how we show what version of actors is active right now vs. the version we're capable of supporting. Upgrade path (i.e., make clear what happens if we need to make changes)I assume if Bits 0-1 is MotivationsI think you can also add how it's useful to determine which SPs have upgraded to the new network version as failure to upgrade can lead to F3 participation levels dropping below the minimum as we saw in filecoin-project/lotus#13359. Other sources to potentially referenceFDS-7 notes: https://docs.google.com/document/d/1kxA2b5V0Hm0lSF8ZQxmqauBoh6wJWXINscDpEm3sTH4/edit?tab=t.y3uj8nmj7dfk#bookmark=id.21ljfg6h5xoz |
Beta Was this translation helpful? Give feedback.
-
|
Noting also that @Kubuxu thinks we don't have enough bits for the version string in this proposal. We only get one more version bump, Regarding the digest - there are cases where we've had two different bundle hashes for the same version string so having part of the digest is quite helpful. I believe that 20 bits gives us 1 in 1,048,576 chance of random collision, 21 would be 2,097,152. BUT we also have control over this digest; if we ever accidentally had a bundle generation mishap where we needed to make a new one and be absolutely sure that we didn't conflict with a previous build, we could just jigger some bit in the build and have an entirely new bundle hash if we needed to, so the collisions wouldn't be entirely random, we could probably get away with many fewer bits if we were very intentional about our builds and watched for collisions with previous recent builds. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
The
BlockHeader.ForkSignalingfield is a 64-bit integer that's been sitting (mostly) unused in the Filecoin chain block headers (type is described here).During an in-person discussion at FDS-7 about the difficulty of determining network upgrade readiness there was a proposal to use
ForkSignalingto actually do some signalling (from memory, @lanzafame, @BigLep and @rjan90 were present and contributed to this discussion). Currently the field is left as the default0value by Lotus Miner and Curio, and is set to1by Venus / sophon-miner.This is an initial proposal of how we could use it to encode miner software identification, network upgrade readiness signals, and actors bundle verification into a structured bit layout that enables better network visibility and coordination.
Motivation
Right now, we have limited visibility into the Filecoin mining ecosystem. Which software are miners running? Are miners ready for upcoming network versions or do we need to chase them up? Are they really ready, with the latest actors bundle or do they have something else?
The
ForkSignalingfield gives us 64 bits to work with. Currently, only values 0 and 1 have been used (Venus/Sophon uses 1 for internal signaling). Let's define a proper schema.Proposed Bit Layout
When mining a new block, a miner will encode the 64 bit field as follows:
2lets us clearly differentiate from the current0and1in use in the wild.The validity of this field would not be checked, so having it correctly formatted is not consensus-critical..
Miner Software IDs
A FIP (edit: this is probably an FRC, not a FIP) would also introduce a registry of miner software that can be updated by maintainers as new ones are introduced. We would start with:
What This Enables
Upgrade readiness dashboards: Anyone can scan the chain and see what percentage of recent blocks signal readiness for nv29, nv30, etc.
Implementation diversity metrics: Track the health of the multi-client ecosystem over time.
Actors bundle verification: Quickly detect if miners are running mismatched or outdated bundles.
Backward Compatibility
Existing chain history remains valid. Miners running older software simply won't populate the new fields, which is fine. This field has never been checked or validated and this will continue to be the case. Participation is opt-in.
Beta Was this translation helpful? Give feedback.
All reactions