Slush Pool: pomysł z Pragi przeciwko losowaniu wśród górników

Bitcoin wówczas nagradzał zwycięzcę bloku pięćdziesiątoma monetami. Dla sieci był to prosty mechanizm, ale dla jednostki — twarda loteria. Prawdopodobieństwo znalezienia bloku odpowiadało udziałowi jego wydajności obliczeniowej w całej sieci. Im wyższy był całkowity wydajność, tym dłużej mógł czekać mały górnik, mimo że jego maszyna pracowała bez przerwy.

Długoterminowy średni poziom mógł wyglądać korzystnie, ale rachunki za prąd przychodziły co miesiąc. Jednostka musiała ponieść duży rozrzut: albo otrzymała całą nagrodę, albo przez długi okres nic nie otrzymała. To wypierało ludzi o mniejszej wydajności, chociaż ich praca była z punktu widzenia sieci równie użyteczna jak praca dużej operacji.

Palatinus znał ten problem z własnego doświadczenia. Na forum opisał, że wspólny serwer może połączyć tysiące małych prób i wyniki rozdzielić. Uczestnik nie będzie już czekał na własny rzadki sukces; otrzyma mniejszy udział każdego razu, gdy ktoś w grupie odniesie sukces.

Mining pool nie zmienia prawdopodobieństwa całej grupy ani nie tworzy więcej bitcoinów. Zmienia podział ryzyka w czasie. Jest to różnica między jednym losiem z dużą wygraną a regularnym udziałem w dużym pakiecie losów. Za stabilniejszy dochód górnik płaci opłatą i zależnością od prawidłowego rozliczania przez operatora.

Slush nie przedstawił swojego pomysłu jako czystego zwycięstwa technicznego. Już w pierwszym wątku wymienił zalety, wady i niezbędną ufność. Serwer musiał prawidłowo mierzyć oddaną pracę, nie kradł nagród i pozostawał dostępny. Pool usuwał jedną niepewność, ale dodawał pośrednika, którego sam konsensus bitcoinowy nie kontrolował.

Dla małego górnika największym problemem nie była średnia stopa zwrotu, lecz czas. Statystycznie mógł mieć prawo do ułamka nagrody każdego dnia, ale rzeczywisty protokół nie wypłacał ułamków za sam wysiłek. Albo jego maszyna znalazła ważny blok i otrzymała pełne pięćdziesiąt bitcoinów, albo nie otrzymała niczego. Długa seria niepowodzeń nie oznaczała przy tym, że urządzenie nie pracowało; oznaczała jedynie, że loteria nie wypadała jeszcze na jego korzyść. Wspólny serwer przekładał to nieregularne zdarzenie na mniejsze udziały według udokumentowanej pracy. Pool nie zwiększył oczekiwanej liczby znalezionych bloków, ale zmienił rytm przychodów, i to właśnie ta różnica mogła przesądzić, czy ktoś mógł sobie pozwolić na dalsze kopanie.

Ogłoszenie z 27 listopada 2010 roku nie przedstawiało jeszcze gotowego produktu firmy. Palatinus szukał ludzi chętnych do przetestowania protokołu, połączenia i sposobu naliczania nagród. System musiał przyjmować częściowe dowody pracy — wyniki niewystarczające do utworzenia poprawnego bloku, ale potwierdzające, że górnik rzeczywiście wykonuje obliczenia.

Te częściowe wyniki, nazywane shares, pozwalały poolowi oszacować wkład każdej maszyny. Gdy któryś z uczestników znalazł hash spełniający wymagania trudności całej sieci, pool otrzymywał nagrodę za blok i dzielił ją według przyjętej zasady rozliczeń. Dla zwykłego górnika oznaczało to przejście od nieregularnej nagrody w wysokości pięćdziesięciu bitcoinów do strumienia mniejszych wypłat.

Pierwsza wersja usługi działała pod nazwą Bitcoin.cz Mining Pool. Strona, serwer i wsparcie były w dużej mierze pracą jednego człowieka. To daje czeskiemu pierwszeństwu bardziej precyzyjny wymiar: nie było to projektem narodowym ani programem państwowym, ale programistą, który z Pragi rozwiązywał konkretny problem ekonomiczny globalnej sieci.

Pool jednocześnie musiał zmontować kandydujący blok i rozsyłać górnikom zadania. Poszczególne maszyny dostarczały wydajność, ale operator określał, nad jakim nagłówkiem pracują i jakie transakcje szablon zawiera. Rozdział sprzętu między wielu ludzi nie gwarantował więc rozdziału decyzji.

Późniejszy rozwój protokołów wydobywczych, w tym Stratum V1, próbował usprawnić komunikację między poolami a urządzeniami. Podstawowa wymiana pozostała jednak taka sama: pool sprzedaje bardziej przewidywalną wypłatę, a górnik powierza mu część koordynacji. Pierwszy serwer stworzył wzorzec, który inni szybko naśladowali.

Pool rozpoczął normalną pracę 16 grudnia 2010 roku i tego samego dnia wydobył blok 97 834. Dzisiejszy zapis w łańcuchu pokazuje wynik, ale nie oddaje napięcia, które go poprzedzało: czy serwer poprawnie przyjmie wykonaną pracę, rozpozna prawidłowy blok i zaliczy udziały osobom, które udostępniły moc obliczeniową?

Pierwszy blok potwierdził, że koordynacja działa nie tylko w teście. Nagroda mogła być rozdzielona między uczestników, z których większość samodzielnie w tym momencie nic by nie uzyskała. Dla małych górników był to namacalny dowód, że ich słabsze maszyny nie muszą być natychmiast wyparte z gospodarki sieci.

Data jest ważna do odróżnienia od listopadowego ogłoszenia. Pomysł, publiczne testowanie i ostry wynik były trzema różnymi krokami. Historia nie zaczyna się od nagłego znalezienia bloku, ale tygodniami przed nim, gdy Slush otwarcie opisał pomysł i poprosił społeczność o pomoc w znalezieniu błędów.

Sukces przyniósł więcej wydajności i odpowiedzialności. Im większy udział sieci pool łączył, tym bardziej wrażliwy był każdy awaria lub zły wybór. Usługa musiała chronić konta, liczyć nagrody i reagować na ataki. To już nie był tylko skrypt na wyrównanie szczęścia; była to infrastruktura, na której rozliczenia polegali obcy ludzie.

Blok 97 834 jest więc znaczący nie swoją kwotą. Tych samych pięćdziesięciu bitcoinów uzyskiwali inni górnikowie. Wyjątkowy był sposób, w jaki do niego došli i jak go rozdzielili. Jeden wiersz w blockchainie reprezentował wspólną pracę wielu maszyn i pierwszy praktyczny dowód, że pooling może działać w publicznej sieci.

Projekt później przeszedł nazwy Slush Pool i Braiins Pool. Zespół Braiins usługę zunifikował, podczas gdy Marek Palatinus poświęcił więcej energii SatoshiLabs i sprzętowej kasie Trezor. Z oryginalnego serwera pozostała jednak nieprzerwana linia historyczna do jednego z najstarszych nazw wydobywczych bitcoinów.

Pooling rozszerzył możliwość wydobywania, ale stopniowo również skoncentrował tworzenie szablonów bloków w mniejszej liczbie usług. Samodzielny górnik decyduje sam, jaki blok buduje. Uczestnik zwykłego poolu często tylko liczy zadanie, które otrzymał. Fizyczna wydajność może być rozproszona, podczas gdy decyzje koordynacyjne pozostają scentralizowane.

Ta koncentracja nie oznacza, że pool posiada wszystkie podłączone maszyny. Górnikowie mogą wydajność przekierować gdzie indziej, jeśli nie zgadzają się z opłatami, cenzurą lub zachowaniem operatora. Przesunięcie wymaga jednak informacji i gotowości do reakcji. Decentralizacja mierzy się więc nie tylko liczbą urządzeń, ale także tym, kto składa bloki i jak łatwo można zmienić koordynatora.

Pierwszy tekst Slushe nie ukrywał tego kompromisu. Zaproponował rozwiązanie problemu ekonomicznego i jednocześnie nazwał zaufanie, jakiego rozwiązanie wymaga. To właśnie ta otwartość pomaga czytać historię bez późniejszego triumfalizmu: pool nie był ostateczną odpowiedzią, ale nowym narzędziem z jasnymi kosztami.

Prażski projekt zmienił wydobywanie, oddzielając pracę od szczęścia. Jednostka nie musiała już sama wygrać cały blok, aby jej wydajność otrzymała bieżącą cenę. Jednocześnie pokazał, że nawet system zaprojektowany bez banku centralnego będzie tworzył usługi, którym ludzie powierzają koordynację. Pytanie nie brzmi, czy powstaną, ale czy uczestnicy będą w stanie je kontrolować, opuszczać i zastępować.

Koncentracji poolów nie można więc mierzyć wyłącznie liczbą podłączonych maszyn. Ważne jest, kto składa szablon bloku, wybiera transakcje, ustala zasady wypłat i potrafi przekonać uczestników, by w razie problemu zmienili oprogramowanie. Górnik może opuścić pool tylko wtedy, gdy ma inną użyteczną alternatywę i rzeczywiście śledzi, co robi usługa. Oryginalny opis zaufania Slusha pozostaje w tym względzie wciąż aktualny. Pooling rozwiązał rzeczywisty problem ekonomiczny i jednocześnie stworzył nowy obszar, w którym konieczna jest konkurencja, przejrzystość i możliwość odejścia. Decentralizację nie utrzymuje się przez zakaz koordynacji, lecz przez to, że nie pozwala się jej stwardnieć w niekontrolowaną władzę.