Incentivisation of F3 #1106
Replies: 3 comments 12 replies
-
|
I cannot really easily wrap my head around α (\alpha). Is this a constant? What is the suggested value? |
Beta Was this translation helpful? Give feedback.
-
|
Given 5 days have already transpired, I wanted to acknowledge that the question. It will be responded to this week. |
Beta Was this translation helpful? Give feedback.
-
|
It is a constant parameter. I don't have a good suggested value, but a jumping-off-point might be something in the order of 10%. |
Beta Was this translation helpful? Give feedback.
-
Why is F3 important again in context of that the network should be spending resources to incentivize it? EIP-4844 was considered important too, but they let user, ie the market, decide if it is really that important by allowing user to pay for usage. Also, what "significant potential" are you referring to?
Where are the 10% of the rewards coming from? |
Beta Was this translation helpful? Give feedback.
-
There is no "management" here, the network is a collective of parties all working towards a common goal. The goal of any FIP is to convince said network that some change is in the best interest of the network (i.e., everyone benefits). With respect to the original (unincentivised) F3 FIP: everyone, including SPs, should be excited because the value of the token (hence the value of rewards) is proportional to the current and perceived future value/usefulness of the network. Adding a useful feature benefits everyone. This FIP exists to balance rewards and ensure that SPs are being rewarded proportional to the value they provide (and, importantly, ensure that there's no incentive to "free ride").
The goal isn't to get some immediate "pop"; we're building for long-term value. The goal is to build something that's eventually useful and we're building the components required to get there:
It's a fixed process that happens per-epoch (same as block mining), irrespective of demand, user submitted messages, etc. However, it's also important to note that the users are paying for this feature along with literally everything else in Filecoin:
|
Beta Was this translation helpful? Give feedback.
-
"for the greater good", comrade! 🫡
Do we have a clear cut process for "convince said network" especially with regard to acceptance? Who are the stakeholders when you say "network"?
imho, the network would be better off operating within principle of reality not "should", "could" or "maybes".
imho, the main reason why no one uses Snapdeal is not that "lotus miner is garbage" but the fact that there is literally no market demand for it. Technical inconveniences is of no significance when one truly hit the soft spot of the market, imo.
yes, they could pay extra if they want faster finality was my point and that extra could be in turn become the incentive. |
Beta Was this translation helpful? Give feedback.
-
During the passive testing rounds of F3 on mainnet, approximately 77% to 79% of the network's power participated in F3 when the tests were conducted at full scale without restrictions. The F3 team has also been extremely committed to taking a gentle approach in introducing F3, and ensuring that its adds as little overhead as possible, and are now introducing message compression and chain hashing to further reduce F3's bandwidth usage.
Historically, SnapDeals may have been buggy, and there wasn't much market demand, primarily because its economics didn't make sense compared to other pipelines. However, demand is now emerging with Curio, as the economics become favorable when bundled with the full SupraSeal pipeline. You can reconfigure your hardware for higher throughput. Or as an example, build a single $30k SupraSeal machine which is capable of producing 24TiB of sectors per day, and then snap those sectors - and the total costs will be a lot cheaper compared to the other sealing pipelines. This topic is also outside of this discussion, so if you have other ideas around SnapDeals you are welcome to share those in FIP discussions like repeated snap deals: #538 or open a new discussion. |
Beta Was this translation helpful? Give feedback.
-
AFAIU, thats by setting the default to ON? which isn't really an active process?
imho, both are related to the root cause of slow & ineffective protocol development, which is lacking a methodological approach. Even entry level models like build-measure-learn from The Lean Startup could be adopted to alleviate the problem, ie right now there is no measure & learn but only build and the tendency to chase vanity metrics is high. |
Beta Was this translation helpful? Give feedback.
-
Active participation is measured by the network's continued engagement and feedback during testing, not just the initial default setting. The high participation rate reflects the network's willingness to test and improve F3, which is a collaborative effort. And even after passive testing stopped at the end of December, larger entities has reached out to ask how they can ensure that F3 is enabled, because they see value in F3.
This comment mixes unrelated points and doesn’t add anything useful to the discussion at hand here. F3 development has been methodical, with extensive testing, feedback, and iterative improvements. If you believe there’s a better approach, we’d welcome specific, constructive proposals rather than vague references to frameworks. Critiques without meaningful contributions to the discussion or development process add little value. |
Beta Was this translation helpful? Give feedback.
-
|
Can we have some concrete details about what inclusion in the chain looks like? Would we just be adding 17th element to the |
Beta Was this translation helpful? Give feedback.
-
|
I think we're just going to have to submit it as a message, possibly a special kind of "free" message? Although the "free" part may not be necessary assuming the rewards are sufficient. We can also do all the processing in cron to reduce the problem. I'm not a fan of putting the certificate in a block header as we generally assume those are really tiny (so we can sync them for free). Messages get synced after the fact and in parallel. |
Beta Was this translation helpful? Give feedback.
-
Motivation
F3 is an important infrastructure piece unlocking significant potential for the Filecoin network. To guarantee its correct functioning, high participation is very important. This calls for an adaptation of the reward mechanism design. We detail a proposal to incentivize F3. The design should directly reward participation in the protocol, and reduce the risk of incentive misalignments. (See go-f3#803.)
tl;dr We propose adjusting the way mining rewards are earned, where up to 10% of the rewards would be tied to participation in F3, verified through evidence in the finality certificate. The total rewards available to SPs remain unchanged, ensuring that participants can earn the same overall amount. Some adaptations are suggested in order to enhance inclusivity and mitigate free-riding risks.
The proposal below includes both technical and economical details, which complement each other. Please read thoroughly, and ask/comment freely!
Basic mechanism
To directly incentivize participation, we’ll leverage the finality certificate posted on-chain as the agreed upon source of truth. Rewards are allocated to both the validator (aka SP) posting the certificate in its block, as well as the signers (i.e. other participating validators) included in the certificate.
How is the certificate constructed? (See existing FIP-0086.)
The certificate construction uses aggregated BLS signatures. A certificate from F3 contains an aggregation of decide messages:
A validator receiving sufficient (i.e., >2/3) F3 DECIDE messages can create this aggregation into a certificate and include the certificate into a block it produces.
How are F3 participation rewards allocated?$\textrm{MaxAmt}$ . Any valid certificate allocates at least ⅔ of the $\textrm{MaxAmt}$ .$i$ with a share of the total power in the power table $\textrm{share}_i$ receives $(1-\alpha) \textrm{MaxAmt}\cdot \textrm{share}_i$ . (The $\alpha$ will be used for the inclusion incentive below.) This means that F3 rewards do not constitute a zero-sum game and validators do not benefit from censoring others (in that specific context).
In the certificate there is a list of validators which is verifiable with the aggregated signature. Similarly to block rewards, there is a fixed amount of $FIL that is allocated to a certificate. However, unlike block rewards, it may be that a certificate requires less than the fixed (maximal) amount. The reward allocated due to the certificate is according to the share of total power that the contained signatures represent.A certificate containing signatures from the total share of power allocates the
The reward per signature is constant (normalized by the power of the signer). For example, a signer
Incentivizing inclusion of signatures in the certificate, and the certificate in a block.$\alpha \cdot\textrm{MaxAmt} \cdot \sum_{i \in cert}{\textrm{share}_i}$ . Later certificates (as in later epochs) for the same F3 instance, receive no reward. This implies that the includer-validator benefits from including as many signatures as possible from one hand (the opposite of censoring), while not wanting to delay posting the certificate since it might lose its chance.
Certificates are created and included in blocks by validators (possibly via a system message). To incentivize inclusion in a block, the validator who includes a certificate receives the added portion of the associated rewards. Specifically,
The above creates an economic mechanism to incentivize inclusion. What is a practical strategy for validators to implement? In practice, validators that get to create a block wait to collect as many signatures as they can before they publish the block. The simplest implementation is a cutoff time. A slightly more nuanced strategy could be as follows. Define the maximal time to wait before posting a certificate by$\tau$ . The waiting time to post/create the certificate can be $\tau-c\cdot(\sum_{i \in cert}\textrm{share}_i-\frac{2}{3})$ , where $c$ is some constant.
Example of rewards for a validator: Given$\textrm{MaxAmt}$ that corresponds to 10% of the rewards. Let’s say validator $i$ has 0.4% of the total power (a large miner), is producing blocks and is participating in F3. It does so in a timely manner and, therefore, its blocks are included and it appears in all F3 certificates. The composition of its rewards will become:
Duplication handling: How does it work with a Filecoin tipset containing multiple blocks?$s_i$ appears both in the certificate of block $j$ and in the certificate of block $k$ , and block $j$ has the priority (better winning ticket), then $j$ ’s proposer gets the reward for signer $s_i$ .
The multiple proposers is actually a benefit! The tipset can contain multiple finality certificates (1 per block), they are combined into one “super-certificate” with a set of DECIDE senders which is the joint of the respected sets in the individual certificates. The rewards for Includers (the share) is distributed according to the existing block-priority mechanism. That is, if signer
Hypothetical Questions (and real answers)
Q: What prevents a validator from “free-riding”? (This answer involves some analysis, bear with us 🙏)
In our context, a free rider is a validator that does not actively participate in F3 but does appear in the signature set in the finality certificate.
Recall that a valid certificate is created by aggregating valid DECIDE messages. A valid DECIDE message is composed of a value and evidence:
The evidence (in a DECIDE message) is an aggregation of COMMIT messages:
This construction implies that a correct validator building the certificate (and block) adds the signing validator to the aggregation only if the signer sent a valid DECIDE message, which includes evidence. It is possible to copy a received DECIDE message and send it as your own. (This is a feature that we wish to preserve since it is important in order to allow validators to efficiently jump into a DECIDE phase of the Consensus, in a case where they may be lagging behind due to network connectivity issues.)
We established that the “free-rider” needs only to listen to DECIDE messages on the network, so what’s preventing a validator from “free-riding”? The catch is in listening to the DECIDE messages.
In free riding the benefit is not additional income, but rather a reduction of costs. Therefore, we need to compare the costs in relation to (correct) active participation:
To conclude, there is little operational savings in “free riding”, so the benefit of becoming a “free rider” is insignificant.
Q: Why are siblings not an issue?
A validator can participate with multiple accounts, but there is no incentive for doing so. It may as well just run as one - no advantage: i.e. rewards are proportional to the power, and running multiple miners for F3 means higher operational cost.
Q: But a certificate only includes ⅔ of the power, so wouldn’t many be left out?
No. A certificate includes everyone that participated in a timely manner (not just the first 2/3). Specifically, the incentives are designed such (see Incentivizing inclusion section) that it is better to include more signers, but also not to wait too long since “the ship may sail for good”.
Q: Would a validator producing a certificate prefer to include only itself and its friends?
A validator is definitely encouraged to include itself and friends, but it’s rewarded in proportion to the included power in the certificate. Therefore, the validator is incentivized to include others as well, and as many of them as possible.
Q: Does this affect catching up with the chain based on certificates?
It does not. A chain of valid certificates is still a valid mechanism to catch up with the chain.
Q: Can a validator use the (certificate) catch up to get a certificate without listening to F3?
This is unlikely because the said validator would severely risk losing its turn to post a certificate.
Q: Is this F3 incentivization discussion impacting any engineering work to activate F3 on mainnet?
No, this is a separate effort that can be implemented via a network upgrade after F3 is activated in mainnet.
Technicalities of distribution
Distributing rewards to ~3000 validators every epoch is expensive in terms of gas. This can be mitigated with several mechanisms:
We propose using a combination of the 2nd and 3rd options. That is, a validator can independently collect whenever it wants, as well as an automatic distribution at block production.
Beta Was this translation helpful? Give feedback.
All reactions