Pay Per Last N Shares

Ян під’єднує свій пристрій до Mining Pool — сервісу, який координує роботу майнерів. У PPLNS пул не обіцяє фіксованої ціни за кожен прийнятий результат. Натомість, знайшовши блок, він розподіляє винагороду за записом нещодавньої роботи. Уявімо рухомий список: нові результати додаються, а найстаріші поступово вибувають. Знахідка блоку не стирає цей список. Тому та сама робота може отримати частку кількох винагород або вибути ще до появи будь-якого оплачуваного блоку. [1]

Результати, якими пристрій регулярно підтверджує роботу, називають shares. Хеш тут — число, обчислене з даних про запропонований блок. Мережа вимагає, щоб воно не перевищувало встановлене цільове значення, тому майнер знову й знову змінює дані та обчислює новий результат. Вони виконують простішу умову пулу, але зазвичай недостатні для нового блоку Bitcoin. N позначає розмір вікна роботи, що враховується. У найпростішій моделі це останні N shares однакової складності всього пулу, а не останні N людей. Якщо складність різниться, роботу треба відповідно зважувати. Вікно також не означає фіксованої кількості годин: його тривалість залежить від швидкості надходження нової роботи. [1]

Уявімо повне вікно з 1000 однаково зважених shares, з яких 100 належать Яну. Пул щойно знайшов блок і після власного відрахування має для розподілу 3 BTC. Частка Яна в цьому прикладі становить 100 / 1000 × 3 = 0.3 BTC. Ян виконав десяту частину врахованої роботи, тому йому належить десята частина винагороди, яку розподіляють. Це лише наочні числа: 3 BTC тут не означає розміру субсидії блоку, тобто нових біткоїнів, що створюються за блок, а 0.3 BTC — обіцяного денного доходу. На час наступної знахідки у вікні можуть бути інші результати, а сума для розподілу теж може змінитися. [1]

Ян від’єднує пристрій для обслуговування. У правильно реалізованому PPLNS це не стирає вже прийнятої роботи. Вона залишається у вікні й може брати участь у наступних винагородах, доки новіша робота її не витіснить. Вона старіла б так само, якби Ян продовжував майнити; він лише додавав би нові результати. Після повторного підключення його частка у вікні поступово відновлюється. Робота з перервами може спричиняти більші коливання, але сама по собі не є автоматичним штрафом за вихід. [1]

PPLNS розподіляє результат реальних знахідок блоків, тому успішний день пулу відрізняється від дня без знахідки. Важливо й те, як пул враховує комісії за транзакції користувачів Bitcoin. F2Pool прямо описує цю мінливість. Натомість Full Pay Per Share (FPPS) оцінює прийняту роботу за розрахунком, що включає субсидію і комісії; Pay Per Share Plus (PPS+) може застосовувати PPLNS лише до комісійної частини. Сам відсоток відрахування сервісу не показує Яну, який результат буде кращим. Потрібно знати, до якої суми він застосовується. [2] [3]

Розрахована частка, баланс рахунку та платіж у власному гаманці — різні етапи. Ян перевіряє, чи прийнято блок, як обчислено його частку та коли можна вивести баланс за мінімумом і розкладом. Зміна методу виплат теж не обов’язково діє одразу. Наприклад, F2Pool публікує власний момент набуття зміною чинності. Чесне порівняння має включати роботу до зміни й можливі пізніші винагороди з її ще активного вікна. PPLNS не усуває ризику несплати пулом, рахунків за електрику чи вартості обладнання. [3] [4]

Більше вікно дає змогу довше враховувати виконану роботу при розподілі винагород та розподіляє її можливу оплату між більшою кількістю майбутніх знахідок. Це згладжує частину коливань через надто коротке вікно. Але не змушує малий пул регулярно знаходити блоки. Натомість довше доводиться чекати, поки стане відомий повний результат уже виконаної роботи. Якщо кабінет показує очікувану винагороду, це все ще оцінка майбутніх знахідок, а не обіцяна фіксована сума для негайного виведення. [1]

Одна з цілей PPLNS — обмежити pool-hopping: переходи між пулами лише заради вигіднішої фази розподілу винагород. Вікно, яке охоплює знахідки блоків, прибирає просту перевагу входу на початку нового раунду. Проте математична справедливість залежить від варіанта. Мені Розенфельд відрізняє просте фіксоване N від складнішого unit-PPLNS; наївні правила можна використати при зміні складності мережі або вартості блоку. Unit-PPLNS записує для кожної share дані, що спираються на складність мережі та винагороду за блок у момент її подання. Це дає змогу в подальших виплатах врахувати умови, за яких було виконано роботу. Змінюючи параметри, оператор має зберігати очікувану вартість раніше прийнятої роботи. Назва сервісу не доводить, що його розрахунок це робить. [1]