CKPool пояснює шість режимів побудови пулу й Stratum-проксі

Документація розділяє default, solo, proxy, userproxy, passthrough і redirector — з різною моделлю довіри та обліку.

Це не чергова обіцянка «більшого хешрейту», а конкретна зміна у відкритому проєкті, яку можна перевірити за кодом, релізом і журналом змін. Редакція розібрала, що саме відбулося, кому це важливо і де закінчуються підтверджені факти.

Що сталося

CKPool підтримує кілька архітектурних режимів. Default об’єднує хешрейт до однієї адреси й потребує локального Bitcoin node. Solo групує роботу за username, який має бути валідною адресою. Proxy агрегує локальних клієнтів до upstream-пулу, userproxy зберігає ідентичність окремих користувачів, passthrough прозоро передає трафік, а redirector після валідної частки намагається перевести клієнта на прямий endpoint. Режими вирішують різні задачі й не є взаємозамінними.

Головне за хвилину

• Ключова зміна. CKPool підтримує кілька архітектурних режимів.
• Що було раніше. Default об’єднує хешрейт до однієї адреси й потребує локального Bitcoin node.
• Практичний крок. Вибір треба починати з моделі довіри: хто рахує shares, де зберігаються credentials, чи потрібен локальний node і що станеться при втраті upstream.

Чому ця новина важлива

Майнінгові системи працюють безперервно, тому навіть невелика помилка у протоколі, пам’яті, живленні або телеметрії з часом перетворюється на простої, неправильний облік чи зайве споживання. Тут важливий не рекламний відсоток, а передбачуваність: оператор має розуміти, що змінилося, як це перевірити і як повернутися до попередньої версії.

Коротко: Документація розділяє default, solo, proxy, userproxy, passthrough і redirector — з різною моделлю довіри та обліку. Це технічна новина про продукт і його розвиток, а не прогноз курсу чи обіцянка окупності обладнання.

Що варто зробити користувачам

Вибір треба починати з моделі довіри: хто рахує shares, де зберігаються credentials, чи потрібен локальний node і що станеться при втраті upstream. Trusted/node режими документація позначає як не підтримувані й імовірно нефункціональні — їх не слід вводити у production лише через наявність коду. Конфігураційні файли мають мати мінімальні права, Stratum-порти — мережеві ACL, а failover потрібно тестувати без зміни payout identity.

Перед зміною робочої конфігурації варто зробити резервну копію, зафіксувати поточні версії та підготувати шлях відкату. Код і бінарні файли потрібно брати з офіційного репозиторію, перевіряючи тег або commit. Короткий успішний тест ще не доводить стабільність під тривалим навантаженням.

Джерело й умови використання

Автори оригінального проєкту: Con Kolivas та CKPool contributors. Матеріал редакційно переказано й адаптовано українською без копіювання великих фрагментів. Ліцензія першоджерела: GNU GPL v3.0. Якщо вона містить ShareAlike або strongly reciprocal, похідні ліцензовані файли поширюються на тих самих умовах.