Pay Per Last N Shares (PPLNS) est une méthode de répartition des récompenses d’un pool de minage. Un Mining Pool coordonne des mineurs qui cherchent des blocs, c’est-à-dire des groupes de transactions ajoutés à l’historique public de Bitcoin. Lorsqu’il trouve un bloc, le pool partage la récompense prévue selon le travail récemment accepté de ses participants. Une share, preuve de travail, n’a donc pas de rémunération fixe promise à l’avance comme avec Pay Per Share (PPS).
Jan relie sa machine à un Mining Pool, un service qui coordonne le travail de plusieurs mineurs. Avec PPLNS, le pool ne promet pas un prix fixe pour chaque résultat accepté. Lorsqu’il trouve un bloc, il répartit plutôt la récompense à partir d’un relevé du travail récent. Imaginez une liste qui avance : de nouveaux résultats entrent, les plus anciens en sortent progressivement. Trouver un bloc n’efface pas la liste. Le même travail peut ainsi participer à plusieurs récompenses, ou sortir avant qu’un seul bloc rémunéré soit trouvé. [1]
Les résultats envoyés par une machine pour attester son travail s’appellent des shares. Le hash est ici un nombre calculé à partir des données du bloc proposé. Le réseau exige qu’il ne dépasse pas une valeur cible. Le mineur modifie donc les données et recommence le calcul. Ils remplissent la condition moins exigeante du pool, sans généralement suffire à produire un nouveau bloc Bitcoin. N désigne la taille de la fenêtre de travail considérée. Dans le modèle le plus simple, ce sont les dernières N shares de même difficulté de tout le pool, et non les N dernières personnes. Si la difficulté varie, il faut pondérer le travail en conséquence. La fenêtre ne représente pas non plus un nombre fixe d’heures : sa durée dépend du rythme d’arrivée du travail suivant. [1]
Imaginons une fenêtre complète contenant 1000 shares de même poids, dont 100 appartiennent à Jan. Le pool vient de trouver un bloc et dispose de 3 BTC à répartir après sa retenue. Dans cet exemple, Jan reçoit une part de 100 / 1000 × 3 = 0.3 BTC. Jan a fourni un dixième du travail pris en compte : il obtient donc un dixième de la récompense répartie. Ces nombres sont illustratifs : 3 BTC ne désigne pas ici le montant de la subvention de bloc, c’est-à-dire les nouveaux bitcoins créés pour un bloc, et 0.3 BTC n’est pas un revenu quotidien promis. Au prochain bloc, la fenêtre pourra contenir d’autres résultats et le montant disponible pourra lui aussi changer. [1]
Jan débranche sa machine pour l’entretenir. Dans un PPLNS correctement mis en œuvre, cela n’efface pas le travail déjà accepté. Il reste dans la fenêtre et peut participer à des récompenses ultérieures jusqu’à ce que du travail plus récent le repousse dehors. Il vieillirait de la même façon si Jan continuait à miner ; celui-ci ajouterait simplement de nouveaux résultats. À la reconnexion, sa présence dans la fenêtre se reconstitue progressivement. Une activité intermittente peut accentuer les variations, mais ce n’est pas en soi une pénalité automatique pour son départ. [1]
PPLNS répartit le produit des blocs effectivement trouvés : une bonne journée du pool diffère donc d’une journée sans découverte. Le traitement des frais de transaction payés par les utilisateurs de Bitcoin compte aussi. F2Pool décrit explicitement cette variabilité. Full Pay Per Share (FPPS) évalue au contraire le travail accepté à partir d’une estimation comprenant subvention et frais ; Pay Per Share Plus (PPS+) peut n’utiliser PPLNS que pour la part des frais. Le pourcentage prélevé par le service ne dit donc pas, à lui seul, quel résultat sera meilleur pour Jan. Il faut aussi connaître le montant auquel il s’applique. [2] [3]
Une part calculée, un solde de compte et un paiement reçu dans son propre portefeuille sont des étapes distinctes. Jan vérifie que le bloc a été accepté, comment sa part a été calculée et quand le solde peut être retiré selon le seuil et le calendrier. Un changement de méthode peut également ne pas prendre effet immédiatement. F2Pool publie par exemple son propre moment d’application. Une comparaison honnête doit inclure le travail antérieur au changement et les éventuelles récompenses ultérieures liées à sa fenêtre encore active. PPLNS ne supprime ni le risque d’impayé du pool, ni l’électricité, ni le coût du matériel. [3] [4]
Une fenêtre plus longue maintient le travail admissible plus longtemps et étale sa rémunération possible sur davantage de découvertes futures. Cela atténue une partie des variations dues à une fenêtre trop courte. Cela ne rend pas régulières les découvertes d’un petit pool. En contrepartie, le résultat complet du travail passé met plus longtemps à se préciser. Si le tableau de bord affiche sa récompense attendue, elle reste une estimation de découvertes futures, pas un montant fixe promis et immédiatement retirable. [1]
PPLNS vise notamment à limiter le pool-hopping : changer de pool uniquement pour profiter d’une phase plus favorable du partage. Une fenêtre qui traverse les découvertes de blocs enlève l’avantage simple d’une arrivée au début d’un nouveau tour. L’équité mathématique dépend toutefois de la variante. Meni Rosenfeld distingue le modèle simple à N fixe de unit-PPLNS, plus élaboré ; des règles naïves peuvent être exploitées lors de changements de difficulté du réseau ou de valeur du bloc. Unit-PPLNS enregistre pour chaque share des données fondées sur la difficulté du réseau et la récompense de bloc au moment de son envoi. Les versements ultérieurs peuvent ainsi tenir compte des conditions dans lesquelles le travail a été effectué. En modifiant ses paramètres, l’opérateur doit préserver la valeur attendue du travail déjà accepté. Le nom du service ne prouve pas que son calcul le fait. [1]
Pour une vision complète, lisez aussi Mining Pool, Mining Share, Full Pay Per Share, Pay Per Share, Pool Fee, Payout Threshold. Cette entrée est également citée par Mining Pool, Solo Mining, Pay Per Share, Pool Fee.