FPPS vs PPLNS : quel mode de paiement choisir ?

Un schéma de payout traduit vos shares en satoshis. FPPS et PPLNS sont les deux familles les plus répandues sur Bitcoin. À frais égaux et sur un horizon long, ils donnent la même espérance pour une même fraction du hashrate du pool. Ce qu'ils changent tient en trois points : qui porte la variance, comment les frais de transaction du réseau sont partagés, et ce que vous touchez le jour où le pool ne trouve pas de bloc.

FPPS : le pool paie chaque share

En FPPS, le pool vous verse un montant par share valide, qu'il ait trouvé un bloc ou non. Le taux par share reflète la valeur théorique d'une unité de travail : la subvention de bloc, plus une composante de frais de transaction estimés, généralement calculée sur une moyenne glissante des blocs récents du réseau. Le pool porte donc le risque des périodes sans bloc, et en général le risque d'orphelin sur les blocs déjà crédités à votre solde.

Trois conséquences pratiques :

• La variance est faible pour vous. Le flux ressemble à un revenu régulier, sous réserve des shares acceptées et du seuil de paiement.
• Le pool facture cette assurance. Le barème varie d'un pool à l'autre, entre pourcentage affiché, frais annexes et règles d'arrondi. Seule la page tarifaire du pool que vous utilisez fait foi.
• Les frais de transaction reçus sont une estimation lissée, pas les frais exacts du bloc que votre share a contribué à trouver. Un pic de mempool apparaît donc avec un décalage, à la hausse comme à la baisse.

Attention aux acronymes voisins : le PPS simple ne paie souvent que la subvention, sans composante de frais, et le PPS+ ajoute une part de frais selon une comptabilité qui lui est propre. Le contrat écrit prime sur le sigle.

PPLNS : le pool paie au bloc trouvé

En PPLNS, vous n'êtes payé que lorsqu'un bloc est réellement trouvé. Le pool regarde alors une fenêtre des N dernières shares, N étant un paramètre qu'il fixe, et répartit la récompense de ce bloc précis, subvention et frais de transaction réels compris, au prorata des shares présentes dans la fenêtre.

Quatre conséquences pratiques :

• La variance à court terme est plus élevée. Une série de blocs rapprochés augmente le payout, une période sèche le réduit, parfois à zéro jusqu'au bloc suivant.
• C'est la chance du pool qui compte, pas la vôtre. Un petit pool trouve moins souvent des blocs, donc les à-coups sont plus visibles. Un grand pool les amortit sans changer la logique.
• L'uptime et la continuité comptent directement. Si vos machines sont arrêtées au moment où le bloc tombe, ou si vous venez d'arriver et que vos shares ne sont pas encore dans la fenêtre, vous manquez tout ou partie du paiement. C'est ce qui rend le pool-hopping contre-productif sous ce schéma.
• Les frais affichés sont souvent plus bas qu'en FPPS, précisément parce que le pool n'assure pas votre variance.

Choisir selon trois questions

Votre trésorerie. Devez-vous payer l'électricité et l'hébergement sur un flux prévisible chaque mois ? Le FPPS réduit le risque de trou de caisse. Si vous pouvez absorber des semaines irrégulières sans tension, le PPLNS reste ouvert.

Votre uptime. Un site instable, avec des coupures, des redémarrages de firmware ou un réseau capricieux, est nettement plus pénalisé en PPLNS. Si votre disponibilité n'est pas encore maîtrisée, le FPPS protège de cette double peine.

Votre capacité d'audit. En PPLNS, vous pouvez rapprocher chaque payout des blocs trouvés par le pool, en les retrouvant sur un explorateur via les tags de coinbase. En FPPS, vous rapprochez surtout les shares acceptées du taux publié. Les deux exigent de lire les règles d'arrondi, de shares périmées et de shares invalides.

Aucun des deux ne bat l'autre en espérance. Les écarts durables viennent des frais, de la qualité de connexion, c'est-à-dire du taux de shares périmées et rejetées, et de votre horizon. Un opérateur qui change de pool chaque jour pour chasser la chance détruit systématiquement l'avantage théorique du PPLNS, puisqu'il repart à chaque fois avec une fenêtre vide.

Les autres schémas

PROP, ou proportionnel, paie le bloc trouvé sur le round en cours, avec une fenêtre égale au round plutôt qu'à N shares.

Le solo via un pool vous fait utiliser l'infrastructure du pool tout en ne gardant le bloc que si votre propre travail le trouve. C'est la variance maximale, réservée à ceux qui l'assument.

TIDES et les schémas proches, utilisés par certains pools orientés décentralisation, ont leurs propres règles, souvent liées à un template que vous contrôlez davantage. Leur spécification se lit intégralement, sans les assimiler à du PPLNS.

Avant de choisir, ouvrez la page de payout du pool visé et vérifiez trois lignes : le taux ou la fenêtre appliqués, le traitement des shares périmées, et le seuil minimal de paiement. Ces trois lignes déterminent ce que vous toucherez réellement, bien plus que le nom du schéma.