Incentivisation of F3

[Kubuxu]

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?
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 $\textrm{MaxAmt}$. Any valid certificate allocates at least ⅔ of the $\textrm{MaxAmt}$.
The reward per signature is constant (normalized by the power of the signer). For example, a signer $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).

Incentivizing inclusion of signatures in the certificate, and the certificate in a block.
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, $\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.

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:

• $90\%$ tied to block production. That is, it gets a hefty reward when it produces a block. On average, every 50 epochs (1h40m), with a relatively large variance in arrival times.
• $(1-\alpha)\cdot 10\%$ tied to its signatures on F3 certificates. That is, a small but constant reliable stream with very little variance.
• $\alpha \cdot 10\%$ tied to blocks it produces via certificates it creates and includes in its blocks. Arrival times here are also with high variance.

Duplication handling: How does it work with a Filecoin tipset containing multiple blocks?
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 $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$.

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:

• The computation and memory resources required to actively participate in F3 are smaller than those required to produce a block (a burst of effort and winning PoSt). Hence, the computation and memory are practically free, given that they are typically available at no extra cost.
• Regarding bandwidth, the situation is slightly different. The F3 bandwidth requirement is higher than standard Filecoin node usage, however, this cost also translates to free-riders. Due to the specifics of pubsub, filtering messages such that only F3 DECIDE is processed happens after retrieving and deciphering the messages. Hence, a “free-rider” still has to listen to the entire F3 traffic. That is, the main added cost of participation is still incurred by the “free rider”.

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:

1. Distribution of funds from reward/coin actor periodically (e.g., every 120 epochs or during Cron).
   • Distributing during Cron is free, but adds a dependency to Cron.
2. Distribute to a validator when it produces a block.
   • For small validators, this will be very rare.
3. Collect whenever you want.
4. Distribute to a validator during WindowPoST.

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.

[vukolic]

I cannot really easily wrap my head around α (\alpha). Is this a constant? What is the suggested value?

[Fatman13]

F3 is an important infrastructure piece unlocking significant potential for the Filecoin network.

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?

We propose adjusting the way mining rewards are earned, where up to 10% of the rewards would be tied to participation in F3,

Where are the 10% of the rewards coming from?

[Stebalien]

F3 is an important infrastructure piece unlocking significant potential for the Filecoin network.

Why is F3 important again? What significant potential are you referring to?

See https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0086.md#change-motivation. Highlights are:

1. Better experience for users with respect to exchanges.
2. Much better bridging. E.g., allowing users on other networks/L2s to buy storage on Filecoin without having to put said markets on the Filecoin mainnet (impacting gas prices).
3. Much easier to build apps on Filecoin because they won't have to handle reverts.

I've also heard (from @magik6k) that it'll help sealing pipelines because they won't have to wait some arbitrary number of epochs before they can consider a message to have "landed": faster pipelines that don't have to reason about potential reverts.

Where are the 10% of the rewards coming from?

From the block reward. That is, 10% of the block reward is shifted to an F3 reward but still distributed proportional to power (same as with block rewards). SPs that both mint new blocks and participate in F3 should receive the same reward (approximately, but it should be very close) over time, 90% from the block reward and 10% from F3 participation.

This mechanism also has an interesting side-effect with respect to orphaned blocks, which is especially relevant for small SPs: if an SP's block isn't included in the chain but said SP is actively participating in F3, they'll still earn the 10% from F3. Given that they get a chance to participate in F3 every epoch (approximately) instead of "whenever they win a block", this will reduce the impact of producing an orphaned block proportionally.

[Fatman13]

Thank you for the reply! And sorry that i didn't structure my question better earlier...

Given...

1. Better experience for users with respect to exchanges.
2. Much better bridging. E.g., allowing users on other networks/L2s to buy storage on Filecoin without having to put said markets on the Filecoin mainnet (impacting gas prices).
3. Much easier to build apps on Filecoin because they won't have to handle reverts.

AFAIU, it seems that benefits listed above are not really proven merits besides better UX for exchanges? Are these speculative improvements enough to warrant a network subsidy? imho, users should be paying for the usage of f3 similar to how EIP-4844 structure its incentives if they really consider f3 is important and useful to them.

Also 10% seems to be a bit magic? Why do the team think 10% is the favorable amount?

[Stebalien]

AFAIU, it seems that benefits listed above are not really proven merits besides better UX for exchanges? Are these speculative improvements enough to warrant a network subsidy?

Yes, these benefits are absolutely worth it because Filecoin needs a healthy network of users and applications and building such applications/networks without fast and provable finality is really difficult. That's why nearly all modern blockchains have some form of fast provable finality (e.g., Ethereum).

imho, users should be paying for the usage of f3 similar to how EIP-4844 structure its incentives if they really consider f3 is important and useful to them.

1. This is equivalent to the Ethereum beacon chain, not proto-danksharding.
2. At the end of the day, the users are paying for everything because they're the ones who'll be buying a service from the network (making Filecoin actually worth something). The block reward is the network paying the SPs for operating the network and is precisely the place where this reward should come from.

Also 10% seems to be a bit magic? Why do the team think 10% is the favorable amount?

It needs to be enough that SPs are incentivised to not just "turn F3 off" to save a bit of bandwidth. I assume 10% was just chosen as "good enough" and suggestions for a better number derived from bandwidth costs and incentive considerations would be appreciated. Once we start the second round of F3 live testing, we'll be able to get a better bandwidth estimate and we'll likely be able to refine this number.

However, IMO, the exact number isn't all that important as long as it isn't too low because (a) it needs to be high enough such that SPs won't turn off F3 and (b) if SPs participate in F3 they'll earn the same amount of block rewards as they earn today.

[Fatman13]

(b) if SPs participate in F3 they'll earn the same amount of block rewards as they earn today.

i think there is a distinct difference between taking part of the rewards away & call it incentive and having validators earning extra layer of fees from actual user demand. Imagine you are working in a company or a freelance job, the management suddenly tells the employees / contractors that they are taking away 10% of their paycheck, but guess what if the employees do some extra XYZ they will get the 10% back! 😂

Yes, these benefits are absolutely worth it because Filecoin needs a healthy network of users and applications and building such applications/networks without fast and provable finality is really difficult.

i think the idea is that the market may or may not react to what one think is important, snapdeal etc in the past for example.

This is equivalent to the Ethereum beacon chain, not proto-danksharding.

Pardon my limited technical knowledge. Is there any reason why there can't be an extra pay-as-you-go f3 fee?