Twoje zespoły zakończyły wersję alpha swojego blockchaina, a teraz nadszedł czas na uruchomienie testnetu, a następnie mainnetu. Masz prawdziwy blockchain, z niezależnymi uczestnikami, dobrym modelem ekonomicznym, bezpieczeństwem, zaprojektowałeś governance i teraz nadeszła pora, by to wszystko przetestować w praktyce. W idealnym świecie kryptoanarchicznym publikujesz w sieci genesis block, ostateczny kod węzła, a walidatory uruchamiają wszystko samodzielnie, podnoszą wszystkie usługi wspomagające, a wszystko dzieje się samo. Ale to tylko w wymyślonym świecie, a w rzeczywistym, zespół musi przygotować wiele dodatkowego oprogramowania i wykonywać różne manipulacje, aby pomóc walidatorom uruchomić stabilną sieć. O tym jest ten artykuł.
Uruchomienie sieci opartych na konsensusach typu 'proof-of-stake', gdzie walidatory są wybierane głosami posiadaczy tokenów systemu, jest dość specyficznym przedsięwzięciem, ponieważ nawet uruchomienie tradycyjnych, centralnie zarządzanych systemów z dziesiątkami i setkami serwerów to samo w sobie nie jest łatwym zadaniem, a blockchain musi być uruchamiany przez zjednoczone, ale niezależne podmioty. Jeśli w korporacji, podczas uruchamiania, administratorzy mają pełny dostęp do wszystkich maszyn, logów, ogólnego monitoringu, to walidatory nie wpuszczą nikogo do swoich serwerów i najprawdopodobniej będą wolały budować swoją infrastrukturę samodzielnie, ponieważ kontroluje ona dostęp do podstawowych aktywów walidatora – staków głosujących. Tego rodzaju zachowanie pozwala budować rozproszone, bezpieczne sieci – niezależność używanych dostawców chmury, serwerów wirtualnych i “baremetal”, różne systemy operacyjne, wszystko to sprawia, że ataki na taką sieć są niezwykle mało skuteczne – zbyt wiele różnorodnego oprogramowania jest używane. Na przykład w Ethereum wykorzystuje się dwie podstawowe implementacje węzła, w Go i Rust, a atak, który działa dla jednej implementacji, nie działa dla drugiej.
Dlatego wszystkie procesy związane z uruchamianiem i eksploatacją blockchainów muszą być zorganizowane w taki sposób, aby każdy walidator, a nawet niewielka grupa walidatorów, mogła w każdej chwili wyrzucić swoje komputery przez okno, a mimo to nic nie powinno się zepsuć, a pozostali walidatorzy powinni skutecznie utrzymywać pracę sieci i przyłączać nowych walidatorów. Przy uruchamianiu sieci, kiedy jeden walidator jest w Europie, drugi w Ameryce Południowej, a trzeci w Azji, osiągnięcie zgodnej pracy kilku dziesiątek niezależnych grup i zainteresowanie ich wynikiem jest dość trudne.
Walidatorzy
Wyobraźmy sobie uruchomienie hipotetycznego nowoczesnego blockchaina (większość opisanego odnosi się do blockchainów opartych na dowolnej nowoczesnej rodzinie blockchainów: Ethereum, EOS, Polkadot, Cosmos i innych, które przewidują konsensus proof-of-stake). Głównymi aktorami takich blockchainów są zespoły walidatorów zajmujących się instalowaniem własnych niezależnych serwerów, walidujących i produkujących nowe bloki oraz otrzymujących nagrody przewidziane przez sieć dla tych, którzy uczestniczą w konsensusie. Do uruchomienia nowych sieci potrzebnych jest kilka dziesiątek walidatorów (tyle, ile obecnie może mniej więcej efektywnie osiągnąć konsensus w ciągu sekund), dlatego projekt ogłasza rejestrację, w której walidatorzy dzielą się publicznymi informacjami o sobie z użytkownikami, przekonując ich, że zamierzają jakościowo obsługiwać uruchamianą sieć.
Walidatorstwo to biznes, który pozwala bardzo dokładnie oceniać potencjalny dochód walidatora, szybko przenosić moce między projektami, a w przypadku sukcesu wybranej sieci, walidator może jako pełnoprawny uczestnik DAO i osoba odpowiedzialna rozwijać projekt lub po prostu zapewniać doskonałe usługi techniczne za całkowicie przejrzyste, uczciwie zarobione pieniądze. Przy obliczaniu nagrody dla walidatorów, projekty starają się uwzględniać koszty walidatorów i ustalać nagrodę za bloki w taki sposób, aby biznes ten był opłacalny, ale jednocześnie nie pozwalał walidatorom na załamanie gospodarki, zalewając ich pieniędzmi i pozbawiając innych użytkowników sieci.
Biznes validatorów wymaga zapewnienia wysokiej dostępności usług, co oznacza wysoką jakość przygotowania devopsów i programistów oraz kosztownych zasobów obliczeniowych. Nawet bez potrzeby wydobywania hashy w sieciach proof-of-work, węzeł blockchain to duża usługa zajmująca dużo pamięci, konsumująca wiele obliczeń, walidująca, zapisująca na dysku i przesyłająca do sieci duże ilości danych. Do przechowywania logu transakcji i łańcuchów bloków dla blockchaina z kilkoma tysiącami małych transakcji w bloku potrzeba teraz storage o pojemności od 50 GB i więcej, a dla bloków to musi być SSD. Rządowe bazy danych blockchainów z obsługą inteligentnych kontraktów mogą już przekraczać 64 GB pamięci operacyjnej. Serwery o wymaganych parametrach są dość drogie, węzeł Ethereum lub EOS może kosztować od 100 do 200 $/miesiąc. Dodaj do tego zwiększone wynagrodzenie za pracę programistów i devopsów, którzy w okresie uruchamiania rozwiązują problemy nawet w nocy, ponieważ część validatorów może znajdować się na innym półkuli. Niemniej jednak, w sprzyjających momentach posiadanie węzła-walidatora może przynosić poważne dochody (w przypadku EOS – do 10 000 $ dziennie).
Walidacja to tylko jedna z nowych potencjalnych ról IT dla przedsiębiorców i firm. W miarę gdy programiści wymyślają coraz bardziej wyszukane algorytmy, które nagradzają uczciwość i karają oszustów oraz złodziei, pojawiają się usługi, które pełnią funkcje publikacji ważnych danych (orakle), nadzoru (penalizacja depozytów i karanie oszustów poprzez publikację dowodu oszustwa), usługi rozwiązywania sporów, ubezpieczeń i opcji, a nawet zarządzanie odpadami stanowi potencjalnie duży rynek w systemach inteligentnych kontraktów, gdzie za przechowywanie danych należy płacić.
Problemy związane z uruchomieniem blockchaina
Otwartość blockchaina, która umożliwiła swobodne uczestnictwo w pracy sieci komputerów z dowolnych krajów oraz łatwość podłączenia do sieci każdego script kiddie zgodnie z instrukcją na GitHubie, nie zawsze jest zaletą. Gonitwa za nowym tokenem często zmusza walidatorów do "wydobywania nowej monety na starcie", w nadziei na wzrost kursu i możliwość szybkiego zbycia zarobionych środków. Oznacza to także, że Twoim walidatorem może być ktokolwiek, nawet anonim, za którego można głosować tak samo jak za innych walidatorów (prawda, że anonimowi będzie trudno zdobyć głosy stakerów, więc straszne bajki o anonimowych kryptowalutach pozostawmy politykom). Niemniej jednak
Zespół projektu ma zadanie — w jakiś sposób zdobyć do swojej sieci tych, którzy w przyszłości będą w stanie zapewnić stabilną pracę węzłów, znają się na bezpieczeństwie, potrafią szybko rozwiązywać problemy, współpracować z innymi walidatorami i działać wspólnie — od tych cech w pełni zależy jakość tego tokena, w który uczestnicy sieci zamierzają zainwestować swój czas i zasoby. Rozsądni założyciele, oceniając ryzyko, dobrze rozumieją, że przy uruchomieniu oprogramowania takiej wielkości z pewnością będą musieli zmierzyć się z błędami w kodzie, konfiguracji węzłów, oraz że stabilność sieci zależy od tego, jak dobrze programiści i walidatorzy wspólnie będą rozwiązywać tego rodzaju problemy.
Zespół jest gotów głosować w mainnecie za jakimikolwiek walidatorami, tylko nie wiadomo za którymi, którzy są dobrzy? Z największym portfolio? Obecnie prawie nikt takiego nie ma. Po profilach zespołu na Linkedin? Doświadczeni DevOps lub specjaliści ds. bezpieczeństwa nie będą wam udostępniać żadnych profili na Linkedin. Po deklaracjach na czacie, postach i pomocy innym na etapie przygotowań? Dobrze, ale subiektywnie i niedokładnie.
W takich warunkach pozostaje tylko jedno — to, co dobrze rozwiązuje problemy wszystkich — gra, w której będzie można wybrać najlepszych walidatorów, ale najważniejsze — przetestować blockchain na wytrzymałość i przeprowadzić kompleksowy test bojowy blockchaina w warunkach aktywnego użytkowania, zmian w konsensusie, pojawiania się i usuwania błędów. Po raz pierwszy tę procedurę przedstawili jako grę chłopaki z projektu Cosmos, a ten pomysł z pewnością jest doskonałym sposobem przygotowania sieci do uruchomienia niezawodnego i odpornemu na awarie mainnetu.
Gra Walidatorów
Opiszę grę walidatorów tak, jak ją zaprojektowaliśmy dla blockchaina DAO.Casino (DAOBet) oparty na fork EOS, który nazywa się Haya i ma zbliżony mechanizm zarządzania – walidatorzy są wybierani w drodze głosowania z dowolnego konta, przy czym część salda, za które głosuje się na walidatora, jest zamrażana. Każde konto, które ma na saldzie główny token BET, może zagłosować na wybranego walidatora dowolną częścią swojego salda. Głosy są sumowane, a na ich podstawie powstaje top walidatorów. W różnych blockchainach ten proces jest zorganizowany w różny sposób, a zazwyczaj to ta część różni nowy blockchain od rodzicielskiego. Trzeba powiedzieć, że w naszym przypadku EOS w pełni uzasadnia „OS” w swojej nazwie; rzeczywiście używamy EOS jako podstawowego systemu operacyjnego do wdrażania zmodyfikowanej wersji blockchaina pod potrzeby DAOBet.
Będę opisywał poszczególne problemy oraz to, jak można je rozwiązać w ramach gry. Załóżmy sieć, w której twój serwer może być otwarcie atakowany, gdzie aby utrzymać pozycję walidatora, trzeba nieprzerwanie współpracować z siecią, promując swojego walidatora i dbając o to, aby produkował bloki, które na czas dostarczane są do innych walidatorów; w przeciwnym razie, walidator zostanie usunięty z listy.
Jak wybrać top zwycięzców?
Główne techniczne wymaganie do gry – aby wyniki były publicznie weryfikowalne. Oznacza to, że wyniki gry: TOP zwycięzców, muszą być tworzone wyłącznie na podstawie danych, które każdy uczestnik może zweryfikować. W systemie scentralizowanym moglibyśmy mierzyć „uptime” każdego walidatora i nagradzać tych, którzy byli dłużej online lub przepuścili przez siebie maximum ruchu sieciowego. Można gromadzić dane o obciążeniu procesora, pamięci i nagradzać tych, którzy pracowali sumiennie. Jednak jakiekolwiek gromadzenie metryk oznacza istnienie centralnego punktu zbiorczego, a węzły są wszystkie niezależne i mogą zachowywać się, jak chcą, oraz wysyłać dowolne dane.
Naturalnym rozwiązaniem jest określanie zwycięzców na podstawie danych z blockchaina, ponieważ można zobaczyć, który z walidatorów stworzył jaki blok i jakie transakcje zostały w niego włączone. Nazwaliśmy tę wartość Punkty Walidatora (VP), a ich zdobycie jest głównym celem walidatorów w grze. W naszym przypadku najprostszą, łatwo kontrolowalną publicznie i efektywną metryką „użyteczności” walidatora jest VP = liczba_stworzonych_bloków_walidatora w danym okresie czasu.
Ten prosty wybór wynika z faktu, że zarządzanie w EOS już przewiduje wiele występujących problemów, ponieważ EOS jest potomkiem już trzech pokoleń realnie działających blockchainów z dużym doświadczeniem w skomplikowanym zarządzaniu siecią. Prawie każde problemy walidatora z siecią, procesorem czy dyskiem prowadzą do jednego problemu — podpisuje mniej bloków, otrzymuje mniejszą zapłatę za pracę, co ponownie sprowadza nas do liczby podpisywanych bloków — dla EOS to świetna i prosta opcja.
W innych blockchainach sposób liczenia Punktów Walidatora może się różnić. Na przykład dla konsensusu opartego na pBFT (Tendermint/Cosmos, konsensus Aura z Parity Substrate), gdzie każdy blok musi być podpisany przez wielu walidatorów, ma sens liczenie oddzielnych podpisów walidatorów, a nie bloków. Może również warto rozważyć niezakończone rundy konsensusu, które obciążają zasoby innych walidatorów. Ogólnie rzecz biorąc, to się mocno różni w zależności od typu konsensusu.
Jak modelować rzeczywiste warunki eksploatacji
Celem założycieli jest przetestowanie walidatorów w warunkach zbliżonych do rzeczywistości, bez żadnej centralnej kontroli. Problem ten można rozwiązać za pomocą kontraktu-faucet, który rozdaje równe ilości podstawowego tokena walidatorom oraz wszystkim chętnym. Aby otrzymać tokeny na saldo, należy stworzyć transakcję i doprowadzić do tego, aby sieć uwzględniła ją w bloku. W ten sposób walidator musi ciągle uzupełniać swoje saldo nowymi tokenami i głosować na siebie, promując się tym samym na szczycie. Działalność ta tworzy stałe obciążenie sieci, a parametry można dostosować tak, aby strumień żądań był wystarczająco poważny do pełnego testu sieci. Dlatego planujcie kontrakt-faucet z wyprzedzeniem jako ważne narzędzie do uruchomienia sieci i zaczynajcie dostosowywać jego parametry wcześniej.
Wniosek o tokeny z faucet i głosowanie walidatorów wciąż nie do końca wiarygodnie emuluje działanie BČ, szczególnie w ekstremalnie obciążonych trybach. Dlatego zespół blockchainu i tak czy inaczej będzie musiał napisać dodatkowe benchmarki, które pozwolą obciążyć sieć. Szczególną rolę odgrywają specjalnie stworzone wcześniej kontrakty smart, które umożliwiają przetestowanie poszczególnych podsystemów. Do testowania storage, kontrakt zapisuje w blockchainie losowe dane, a do sprawdzenia zasobów sieciowych, testowy kontrakt wymaga dużej ilości danych wejściowych, tym samym zwiększając objętość transakcji — uruchamiając strumień takich transakcji w dowolnych momentach czasowych, zespół jednocześnie testuje stabilność kodu i odporność walidatorów.
Osobnym pytaniem jest aktualizacja kodu węzłów i przeprowadzenie hard forków. W przypadku pojawienia się błędu, luki w zabezpieczeniach lub zmowy złośliwych weryfikatorów, weryfikatorzy powinni mieć plan działania, który został już opracowany w grze weryfikatorów. Można wymyślić zasady przyznawania VP za szybkie wdrożenie hard forka, na przykład karząc wszystkich weryfikatorów, którzy jeszcze nie zaktualizowali nowej wersji kodu węzła, ale jest to trudne do zrealizowania, co komplikuję obliczenia. Sfałszować sytuację nagłego zastosowania hard forka można sztucznie, "łamując" blockchain na zadanym bloku. Produkcja bloków jest wstrzymywana, a w efekcie korzyść odniosą ci, którzy wcześniej się włączą i zaczną podpisywać bloki, więc VP oparty na liczbie podpisanych bloków tutaj dobrze się nadaje.
Jak informować uczestników o stanie sieci i naprawiać błędy
Pomimo nieufności między weryfikatorami, terminowe uzyskiwanie aktualnych informacji o stanie sieci jest korzystne dla wszystkich, aby szybciej podejmować decyzje, dlatego zespół projektu uruchamia usługę do zbierania i wizualizacji wielu metryk z serwerów weryfikatorów, która pozwala zobaczyć sytuację jednocześnie dla całej sieci, pozwalając szybko określić, co się dzieje. Dodatkowo, zarówno weryfikatorom, jak i projektowi zależy na tym, aby zespół szybko naprawiał znalezione błędy, dlatego oprócz zbierania metryk ma sens natychmiastowe uruchomienie zbierania logów i danych o błędach z maszyn weryfikatorów na maszynę dostępną dla programistów blockchaina. Nikt nie ma interesu w zniekształcaniu informacji, dlatego te usługi są uruchamiane przez zespół projektu i można im ufać. Ma sens zbierać metryki systemowe z weryfikatorów oraz, co najważniejsze, najważniejsze metryki samego blockchaina — dla DAOBet to czas finalizacji i opóźnienie ostatniego finalizowanego bloku. Dzięki temu zespół widzi wzrost zużycia pamięci na węzłach podczas uruchamiania benchmarku oraz problemy poszczególnych weryfikatorów.
Ważne kwestie dotyczące przeprowadzenia gry weryfikatorów
Okazuje się, że jeśli chcesz oficjalnie zezwolić walidatorom na atakowanie nawzajem swoich maszyn (nieoficjalnie mogą to robić tak czy inaczej) — musisz to osobno sformułować prawnie jako testowanie bezpieczeństwa, ponieważ w przepisach niektórych krajów DDoS lub ataki sieciowe mogą być karane. Innym ważnym pytaniem jest to, jak nagradzać walidatorów. Naturalnymi nagrodami są tokeny projektu, które będą przeniesione do mainnet, ale masowa dystrybucja tokenów każdemu, kto uda się uruchomić węzeł — też nie jest najlepszym pomysłem. Najprawdopodobniej będziesz musiał balansować między dwoma skrajnymi opcjami:
Rozdać cały fundusz nagród zgodnie z uzyskanymi VP
jest to bardzo demokratyczne i pozwala zarobić wszystkim, którzy poświęcili czas i zasoby na grę walidatorów
ale przyciąga do gry przypadkowych ludzi bez przygotowanej infrastruktury
Rozdać fundusz nagród czołowym walidatorom według wyników gry
zwycięzcami będą najprawdopodobniej walidatorzy, którzy najstabilniej przetrwali w trakcie gry, bardzo nastawieni na zwycięstwo
część walidatorów może nie chcieć brać udziału, nisko oceniając swoje szanse na zwycięstwo, zwłaszcza jeśli wśród uczestników znajdują się doświadczeni walidatorzy
Którą opcję wybrać — to sprawa dla Ciebie
Jest jeszcze jeden aspekt — wcale nie jest pewne, że dziesiątki walidatorów rzucą się do udziału w grze na Twoje wezwanie, a z tych, którzy zdecydują się spróbować, nie wszyscy nawet zainstalują i uruchomią węzeł — zazwyczaj na tym etapie projekty mają dość ubogą dokumentację, występują błędy, a programiści pracujący w stresie nie odpowiadają na pytania zbyt szybko. Dlatego przed rozpoczęciem gry należy przewidzieć działania, jeśli potrzebnej liczby walidatorów nie uda się zebrać. W takim przypadku na początku gry brakujący walidatorzy są uruchamiani przez zespół projektu, uczestniczą w konsensusie, ale nie mogą być zwycięzcami.
Podsumowanie
Na zakończenie starałem się zebrać z powyższego listę rzeczy, które należy wymyślić, zrobić i uruchomić, aby efektywnie przeprowadzić grę walidatorów
Co należy zrobić, aby uruchomić prawdziwą grę walidatorów:
opracować własną blockchain 🙂
- stworzyć i uruchomić interfejs webowy oraz zapewnić CLI do głosowania na walidatorów
- sprawić, by metryki z uruchomionego węzła walidatora mogły być wysyłane do zcentralizowanej usługi (np. Prometheus)
- uruchomić serwer zbierania metryk (Prometheus + Grafana) dla gry walidatorów
- wymyślić, jak będą liczone Punkty Walidatora (VP)
- opracować publiczny skrypt, który liczy VP walidatora na podstawie danych z blockchaina
- opracować interfejs webowy do wyświetlania top walidatorów oraz stanu gry walidatorów (ile czasu pozostało do końca, kto ma ile VP itd.)
- opracować i zautomatyzować uruchamianie dowolnej liczby własnych węzłów, zaprojektować proces podłączania walidatorów do gry (kiedy i jak odłączać własne węzły, zgłaszać i wycofywać głosy za nie)
- obliczyć, ile tokenów należy wydać i opracować kontrakt-faucet
- zrobić skrypt-benchmark (transfery tokenów, masowe wykorzystanie storage, masowe wykorzystanie sieci)
- zebrać wszystkich uczestników w jednym czacie dla szybkiej komunikacji
- uruchomić blockchain nieco wcześniej przed rozpoczęciem gry
- czekać na blok startowy, rozpocząć grę
- przetestować sieć różnymi typami transakcji
- wdrożyć hard fork
- zmienić listę walidatorów
- powtórzyć punkty 13, 14, 15 w różnej kolejności, zachowując stabilność sieci
- czekać na ostatni blok, zakończyć grę, obliczyć VP
Należy powiedzieć, że gra walidatorów to nowa historia, która miała miejsce tylko kilka razy, dlatego nie należy tego tekstu traktować jako gotowej instrukcji. Nie ma odpowiedników w nowoczesnym biznesie IT — wyobraźcie sobie, że banki przed uruchomieniem systemu płatności konkurują ze sobą, kto lepiej będzie realizować transakcje klientów. Tradycyjne podejścia raczej nie pomogą Wam w tworzeniu dużych zdecentralizowanych sieci, więc przyswajajcie nowe modele biznesowe, organizujcie swoje gry, wyłaniajcie zasłużonych, nagradzajcie ich i niech Wasze rozproszone systemy działają szybko i stabilnie.
Źródło: habr.com
