You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Until some storageminer process calls F3Participate, we should passively follow F3 via the finality certificate exchange instead of via pubsub to avoid wasting bandwidth. This way:
Pure clients can save a lot of bandwidth.
SPs can save bandwidth by delegating all F3 operations to a single client.
Abstract over this in lotus and don't start the inner F3 module until we need it. That'll lead to a cleaner solution in this repo, but we'll also have some duplicate setup code (need a certstore, certserve, certsub, etc.).
Change F3.MessagesToSign to something like F3.Participate(), lazily starting the runner on-demand. Honestly, we don't really need a way to stop participating.
Personally, I'm leaning towards option 2. It's a bit of work in this repo, but not much.
Per internal 2025-03-28 slack conversation, it wasn't deemed critical to make it an immediate followup/cleanup after F3 activation. As a result, I have reassigned its milestone.
Activity
masih commentedon Oct 8, 2024
This would probably touch some of #588? Would be nice to knock that one out too.
Stebalien commentedon Oct 8, 2024
It should be mostly orthogonal, but I agree.
Stebalien commentedon Oct 8, 2024
Two options:
F3.MessagesToSign
to something likeF3.Participate()
, lazily starting the runner on-demand. Honestly, we don't really need a way to stop participating.Personally, I'm leaning towards option 2. It's a bit of work in this repo, but not much.
masih commentedon Oct 8, 2024
Option 2 sgtm too.
BigLep commentedon Apr 1, 2025
Per internal 2025-03-28 slack conversation, it wasn't deemed critical to make it an immediate followup/cleanup after F3 activation. As a result, I have reassigned its milestone.