Pay Per Last N Shares

Jan podłącza urządzenie wydobywcze do Mining Pool, usługi koordynującej pracę górników. W PPLNS pula nie obiecuje stałej ceny za każdy zaakceptowany wynik. Zamiast tego, gdy znajdzie blok, dzieli nagrodę na podstawie zapisu niedawnej pracy. Można go sobie wyobrazić jako przesuwającą się listę: nowe wyniki dochodzą, najstarsze stopniowo wypadają. Znalezienie bloku nie kasuje listy. Ta sama praca może więc uczestniczyć w kilku nagrodach albo wypaść, zanim pojawi się jakikolwiek wynagradzany blok. [1]

Wyniki przesyłane przez urządzenie jako bieżące dowody pracy nazywają się shares. Hash jest tu liczbą obliczoną z danych o proponowanym bloku. Sieć wymaga, by nie przekraczała ustalonej wartości docelowej, więc górnik zmienia dane i ponawia obliczenia. Spełniają łatwiejszy warunek puli, ale zwykle nie wystarczają na nowy blok Bitcoina. N określa rozmiar rozpatrywanego okna pracy. W najprostszym modelu chodzi o ostatnie N shares o tej samej trudności całej puli, a nie ostatnie N osób. Jeśli trudność się różni, trzeba odpowiednio ważyć pracę. Okno nie oznacza też stałej liczby godzin: zależy od tego, jak szybko napływa dalsza praca. [1]

Wyobraźmy sobie pełne okno z 1000 shares o tej samej wadze. Do Jana należy 100. Pula właśnie znalazła blok i po własnym potrąceniu ma do podziału 3 BTC. Udział Jana w tym przykładzie wynosi 100 / 1000 × 3 = 0.3 BTC. Jan wykonał jedną dziesiątą uwzględnionej pracy, więc przypada mu jedna dziesiąta dzielonej nagrody. Liczby służą tylko ilustracji: 3 BTC nie określa tu subsydium blokowego, czyli nowych bitcoinów tworzonych za blok, a 0.3 BTC nie jest obiecanym dziennym przychodem. Przy następnym bloku w oknie mogą znajdować się inne wyniki, a kwota do podziału może być inna. [1]

Jan odłącza urządzenie na czas konserwacji. W prawidłowo wdrożonym PPLNS nie usuwa to wcześniej uznanej pracy. Pozostaje ona w oknie i może uczestniczyć w kolejnych nagrodach, dopóki nie wyprze jej nowsza praca. Starzałaby się tak samo, gdyby Jan nadal kopał; dokładałby tylko nowe wyniki. Po ponownym podłączeniu jego obecność w oknie stopniowo się odbudowuje. Praca z przerwami może przynosić większe wahania, ale sama w sobie nie jest automatyczną karą za odejście. [1]

PPLNS dzieli wynik rzeczywistych odkryć bloków, więc dobry dzień puli różni się od dnia bez sukcesu. Znaczenie ma również sposób uwzględniania opłat transakcyjnych użytkowników Bitcoina. F2Pool wprost opisuje tę zmienność. Full Pay Per Share (FPPS) wycenia natomiast uznaną pracę na podstawie szacunku obejmującego subsydium i opłaty, a Pay Per Share Plus (PPS+) może stosować PPLNS wyłącznie do części opłat. Sam procent potrącenia nie mówi zatem Janowi, który wynik będzie lepszy. Musi też wiedzieć, od jakiej kwoty jest liczony. [2] [3]

Wyliczony udział, saldo konta i płatność otrzymana we własnym portfelu to odrębne kroki. Jan sprawdza, czy blok został uznany, jak wyliczono jego część i kiedy można wypłacić saldo zgodnie z minimum i harmonogramem. Zmiana metody wynagradzania też nie musi działać od razu. F2Pool publikuje na przykład własny moment wejścia zmiany w życie. Rzetelne porównanie obejmuje pracę sprzed zmiany i ewentualne późniejsze nagrody z jej nadal aktywnego okna. PPLNS nie usuwa ryzyka braku wypłaty ani rachunków za prąd i kosztu sprzętu. [3] [4]

Większe okno sprawia, że wykonana praca jest dłużej uwzględniana przy podziale nagród i rozkłada jej możliwe wynagrodzenie na więcej przyszłych odkryć bloków. Wygładza to część wahań powodowanych przez bardzo krótkie okno. Nie sprawia jednak, że mała pula zaczyna regularnie znajdować bloki. Ceną jest dłuższe oczekiwanie na pełny wynik już wykonanej pracy. Jeśli panel pokazuje oczekiwaną nagrodę, nadal jest to szacunek przyszłych odkryć, a nie stała obiecana kwota do natychmiastowej wypłaty. [1]

Jednym z celów PPLNS jest ograniczenie pool-hopping, czyli przechodzenia między pulami tylko po to, by wykorzystać korzystniejszą fazę podziału nagród. Okno obejmujące granice między blokami usuwa prostą korzyść z wejścia na początku nowej rundy. Matematyczna uczciwość zależy jednak od wariantu. Meni Rosenfeld odróżnia proste stałe N od bardziej dopracowanego unit-PPLNS; naiwne reguły można wykorzystać przy zmianie trudności sieci lub wartości bloku. Unit-PPLNS zapisuje dla każdej share dane oparte na trudności sieci i nagrodzie za blok w chwili jej przesłania. Dzięki temu późniejsze wypłaty mogą uwzględniać warunki, w których wykonano pracę. Zmieniając parametry, operator powinien zachować oczekiwaną wartość wcześniej uznanej pracy. Nazwa usługi nie dowodzi, że jej obliczenia rzeczywiście to robią. [1]