Așadar, echipa ta a finalizat versiunea alpha a blockchain-ului tău și este timpul să lansezi testnet-ul, iar apoi mainnet-ul. Ai un adevărat blockchain, cu participanți independenți, un model economic solid, securitate, ai proiectat guvernanța și acum ești pregătit să testezi toate acestea în practică. Într-o lume ideală de criptoanarchism, ai publica blocul genesis în rețea, codul final al nodului și validatorii ar lansa totul singuri, ridicând toate serviciile auxiliare, iar totul s-ar desfășura de la sine. Dar aceasta este o lume fictivă; în realitate, echipa trebuie să pregătească o cantitate semnificativă de software auxiliar și diferite operațiuni pentru a ajuta validatorii să lanseze o rețea stabilă. Despre aceasta este vorba în acest articol.
Lansarea rețelelor bazate pe consens de tip „proof-of-stake”, unde validatorii sunt determinați de voturile deținătorilor de tokeni ai sistemului, este un eveniment destul de specific, deoarece chiar și lansarea sistemelor tradiționale, gestionate centralizat, cu zeci și sute servere de participanți, este o sarcină complexă în sine, iar blockchain-ul trebuie să fie lansat cu eforturile participanților loiali, dar independenți. Și, dacă într-o corporație, la lansare, administratorii au acces total la toate mașinile, logurile, monitorizarea generală, validatorii nu permit nimănui să se apropie de serverele lor și, cel mai probabil, preferă să își construiască propria infrastructură, deoarece aceasta controlează accesul la activele principale ale validatorilor — stake-urile votanților. Tocmai acest comportament permite construirea de rețele distribuite sigure — independența furnizorilor de cloud utilizați, serverelor virtuale și „baremetal”, diferitele sisteme de operare, toate acestea fac ca atacurile asupra acestei rețele să fie extrem de ineficiente — se folosește o cantitate prea mare de software diferit. De exemplu, în Ethereum sunt utilizate două implementări principale ale nodului, una pe Go și cealaltă pe Rust, iar un atac eficient pentru o implementare nu funcționează pentru cealaltă.
Prin urmare, toate procesele de lansare și operare a blockchain-urilor trebuie organizate astfel încât orice validator, sau chiar un grup mic de validatori, să poată renunța oricând la calculatoarele lor fără ca nimic să se defecteze, iar validatori rămași să continue să susțină eficient rețeaua și să conecteze noi validatori. La lansarea rețelei, când un validator se află în Europa, al doilea în America de Sud, iar al treilea în Asia, este destul de dificil să se obțină o funcționare sincronizată a mai multor zeci de grupuri independente și să se motiveze acestea pentru rezultate comune.
Validatori
Să ne imaginăm lansarea unui blockchain modern ipotetic (cea mai mare parte a ceea ce se descrie se aplică blockchain-urilor din orice familie modernă de blockchain-uri: Ethereum, EOS, Polkadot, Cosmos și altele, care prevăd consensul proof-of-stake). Actorii principali ai acestor blockchain-uri sunt echipele de validatori, care instalează servere independente, validează și generează blocuri noi, obținând recompense prevăzute de rețea pentru cei care participă la consens. Pentru lansarea de noi rețele sunt necesari câțiva zeci de validatori (atât de mulți pot acum să ajungă mai mult sau mai puțin eficient la consens în câteva secunde), așa că proiectul anunță înregistrarea, în care validatori împărtășesc informații publice despre ei înșiși cu utilizatorii, convingându-i că intenționează să ofere servicii de calitate la rețeaua lansată.
Validarea este o afacere care permite evaluarea extrem de precisă a veniturilor potențiale ale validatorilor, transferând rapid puterea între proiecte, iar în cazul succesului rețelei alese, validatorul poate deveni un participant cu drepturi depline în DAO și un responsabil al dezvoltării proiectului, sau pur și simplu poate oferi un serviciu tehnic excelent pentru bani câștigați în mod transparent și corect. La calcularea recompensei, proiectele se străduiesc să ia în considerare cheltuielile validatorilor și să facă recompensa pentru blocuri astfel încât această afacere să fie profitabilă, dar în același timp să nu permită validatorilor să dărâme economia prin inundarea acesteia cu bani și privarea altor utilizatori ai rețelei.
Business validators require ensuring high service reliability, which means a high level of training for DevOps and developers, along with costly computational resources. Even without the need to mine hashes in proof-of-work networks, a blockchain node is a large service that occupies a lot of memory, consumes significant computing power, validates, records to disk, and delivers large volumes of data to the network. To store transaction logs and blockchains with several thousand small transactions, storage of at least 50 Gb or more is currently required, and for blocks, this must be an SSD. The state database of blockchains supporting smart contracts can already exceed 64 Gb of RAM. Servers with the required specifications are quite expensive, with an Ethereum or EOS node costing between $100 and $200 per month. Add to this the increased labor costs for round-the-clock work by developers and DevOps, who resolve issues even at night during the launch period, as some validators may easily be in another hemisphere. Nevertheless, in fortunate moments, owning a validator node can yield serious income (in the case of EOS, up to $10,000 per day).
Validation is just one of the new potential IT roles for entrepreneurs and companies. As programmers devise increasingly sophisticated algorithms to reward honesty and punish fraud and theft, services are emerging that perform functions such as publishing important data (oracles), overseeing (slashing deposits and punishing fraudsters by publishing proof of fraud), dispute resolution, insurance, and options. Even garbage collection presents a potentially large market in smart contract systems, where payment for data storage is necessary.
Challenges of launching a blockchain
Transparența blockchain-ului, care a făcut posibilă participarea liberă la rețeaua de calculatoare din orice țară și ușurința de a se conecta la rețea chiar și de către orice script kiddie conform instrucțiunilor de pe GitHub, nu este întotdeauna un avantaj. Cursa pentru un nou token îi determină adesea pe validatori să „mineze o nouă monedă la început”, sperând la o creștere a valorii și la posibilitatea de a vinde rapid ceea ce au câștigat. De asemenea, aceasta înseamnă că validatorul dumneavoastră poate fi oricine, chiar și anonim; se poate vota pentru el la fel ca și pentru alți validatori (cu toate că unui anonim îi va fi greu să adune voturi de la stakeholderi, așa că poveștile înfricoșătoare despre criptomonedele anonime le lăsăm politicienilor). Cu toate acestea,
Echipa proiectului are o sarcină - să capteze în rețeaua lor pe cei care, în viitor, pot asigura funcționarea stabilă a nodurilor, înțeleg securitatea, pot rezolva rapid problemele, pot coopera cu alți validatori și să acționeze împreună - de aceste calități depinde în totalitate calitatea acelui token în care participanții la rețea intenționează să investească timpul și resursele. Fondatorii raționali, evaluând riscurile, înțeleg bine că, la lansarea unui software de o asemenea amploare, vor trebui să se confrunte cu erori în cod, în configurația nodului, iar stabilitatea rețelei depinde de cât de bine vor colabora dezvoltatorii și validatorii pentru a rezolva astfel de probleme.
Echipa este gata să voteze în mainnet pentru orice validatori, dar ar fi bine să știm pentru care, care dintre ei sunt buni? Cel cu cel mai mare portofoliu? Acesta nu este aproape deloc prezent acum. Pe profilurile echipei de pe Linkedin? DevOps-ii sau specialiștii în securitate experimentați nu vă vor oferi profiluri pe Linkedin. Pe baza declarațiilor din chat, postărilor și ajutoarelor oferite altora în etapa de pregătire? Bine, dar subiectiv și imprecis.
În astfel de condiții, rămâne doar un lucru - ceea ce rezolvă problemele tuturor - un joc în care se pot alege cei mai buni validatori, dar mai ales - testarea durabilității blockchain-ului și desfășurarea unui test de luptă la scară largă a blockchain-ului în condiții de utilizare activă, modificări ale consensului, apariția și corectarea erorilor. Pentru prima dată, această procedură a fost propusă ca un joc de către băieții de la proiectul Cosmos, iar această idee este cu siguranță o modalitate excelentă de pregătire a rețelei pentru lansarea unui mainnet fiabil și rezistent la erori.
Jocul Validatorilor
Voi descrie jocul validatorilor așa cum l-am proiectat pentru blockchain-ul DAO.Casino (DAOBet) bazat pe fork-ul EOS, numit Haya, care are un mecanism de guvernare similar — validatorii sunt aleși prin voturi din orice cont, iar o parte din soldul utilizat pentru votul în favoarea validatorului este înghețat. Orice cont care deține token-ul principal BET poate vota pentru validatorul ales cu orice parte din soldul său. Voturile sunt aggregate, iar în urma acestora se construiește un top al validatorilor. În diferite blockchain-uri, acest proces este organizat diferit, iar de obicei, tocmai în această parte noul blockchain se deosebește de cel părinte. Trebuie să spun că în cazul nostru, EOS își justifică pe deplin „OS” în denumire, noi folosim cu adevărat EOS ca sistem de operare de bază pentru desfășurarea unei versiuni modificate a blockchain-ului pentru cerințele DAOBet.
Voi descrie problemele individuale și modul în care acestea pot fi rezolvate în cadrul jocului. Să ne imaginăm o rețea în care serverul tău poate fi atacat deschis, unde pentru a menține poziția de validator trebuie să interacționezi continuu cu rețeaua, promovând validatorul tău și asigurându-te că acesta produce blocuri și că acestea sunt livrate la timp celorlalți validatorii, altfel, validatorul va fi eliminat din listă.
Cum să alegi top câștigători?
Cerința tehnică principală a jocului este ca rezultatele acestuia să fie verificabile public. Aceasta înseamnă că rezultatele jocului: TOP câștigători, trebuie să fie formate strict pe baza datelor pe care orice participant le poate verifica. Într-un sistem centralizat, am putea măsura „uptime”-ul fiecărui validator și să recompensăm pe cei care au fost online mai mult sau care au procesat cel mai mult trafic de rețea. Putem colecta date despre utilizarea procesorului, memoriei și să recompensăm pe cei care au muncit din greu. Dar orice fel de colectare a metricilor implică existența unui centru de colectare, iar nodurile sunt toate independente și pot acționa cum doresc, trimițând orice date.
Prin urmare, soluția naturală este ca câștigătorii să fie determinați pe baza datelor din blockchain, deoarece acestea arată cine dintre validatori a produs un anumit bloc și ce tranzacții au fost incluse în acesta. Am numit această valoare Puncte Validator (VP), iar câștigarea lor este obiectivul principal al validatorilor în joc. În cazul nostru, cea mai simplă, ușor verificabilă public și eficientă metrică a "utilității" validatorului este VP = numărul_bloacărilor_produse_de_validator într-o perioadă de timp dată.
Această alegere simplă este determinată de faptul că governance-ul în EOS prevede deja o mulțime de probleme care apar, deoarece EOS este urmașul a trei generații de blockchain-uri operaționale, cu o experiență vastă în gestionarea complexă a rețelei. Practic, orice problemă pe care un validator o are cu rețeaua, procesorul sau discul duce doar la o singură problemă: semnează mai puține blocuri, primește o plată mai mică pentru muncă, ceea ce ne duce din nou la numărul de blocuri semnate — pentru EOS, acesta este o opțiune excelentă și simplă.
La alte blockchain-uri, metoda de calcul a Punctelor Validator poate diferi; de exemplu, pentru consensurile bazate pe pBFT (Tendermint/Cosmos, consensul Aura din Parity Substrate), unde fiecare bloc trebuie să fie semnat de mai mulți validatori, are sens să se contabilizeze semnăturile separate ale validatorilor, nu blocurile. Este posibil să aibă sens să se țină cont de runde de consens nefinalizate, care consumă resursele altor validatori; în general, acest lucru depinde mult de tipul de consens.
Cum să modelăm condițiile reale de exploatare
Sarcina fondatorilor este să verifice validatoarele în condiții apropiate de realitate, fără a avea un control centralizat. Această problemă poate fi rezolvată cu ajutorul unui contract faucet care îi distribuie la egalitate token-uri de bază validatoarelor și tuturor celor interesați. Pentru a obține token-uri pe balans, este necesar să se formeze o tranzacție și să se obțină includerea acesteia în bloc de către rețea. Astfel, pentru a câștiga, validatorul trebuie să-și reînnoiască constant balansul cu token-uri noi și să voteze pentru sine, promovându-se în top. Această activitate creează o sarcină constantă pe rețea, iar parametrii pot fi ajustați astfel încât fluxul de cereri să fie suficient de serios pentru un test complet al rețelei. De aceea, planificați contractul faucet din timp, ca un instrument important pentru lansarea rețelei și începeți să-i ajustați parametrii din timp.
Cererea de token-uri de la faucet și votul validatorilor nu imită complet corect funcționarea blockchain-ului, în special în moduri extrem de încărcate. Prin urmare, echipa blockchain-ului tot va trebui să scrie benchmark-uri suplimentare pentru a putea încărca rețeaua. Un rol special în acest proces îl au contractele inteligente create în prealabil, care permit testarea unei subsisteme separate. Pentru testarea stocării, contractul salvează date aleatorii în blockchain, iar pentru verificarea resurselor de rețea, contractul de testare necesită un volum mare de date de intrare, crescând astfel volumul tranzacțiilor — prin inițierea unui flux de astfel de tranzacții în momente aleatorii, echipa testează simultan stabilitatea codului și reziliența validatorilor.
O actualizare a codului nodurilor și desfășurarea hardfork-urilor reprezintă o întrebare distinctă. Este necesar ca, în cazul apariției unui bug, a unei vulnerabilități sau a unui complot al validatorilor rău intenționați, validatorii să aibă un plan de acțiune deja dezvoltat în cadrul jocului validatorilor. Aici se pot concepe scheme de acordare a VP-urilor pentru aplicarea rapidă a hardfork-ului, de exemplu, penalizând toți validatorii care nu au actualizat încă noua versiune a codului nodului, însă acest lucru este complicat de realizat și îngreunează calculul. Simularea unei situații de urgență la aplicarea hardfork-ului poate fi realizată prin „ruinarea” artificială a blockchain-ului la un anumit bloc. Producția de blocuri se oprește, iar în final vor avea de câștigat cei care se vor conecta mai repede și vor începe să semneze blocuri, așa că VP-urile pe baza numărului de blocuri semnate se potrivesc bine aici.
Cum să informăm participanții despre starea rețelei și să corectăm erorile
În ciuda neîncrederii dintre validatori, obținerea la timp a informațiilor actualizate despre starea rețelei este benefică pentru toată lumea, pentru a lua decizii mai rapide. De aceea, echipa proiectului dezvoltă un serviciu pentru colectarea și vizualizarea unei multitudini de metrici de la serverele validatorilor, care permite vizualizarea situației simultan pentru întreaga rețea, facilitând rapid determinarea a ceea ce se întâmplă. De asemenea, atât pentru validatori, cât și pentru proiect, este benefic ca echipa proiectului să corecteze rapid erorile identificate, așa că, pe lângă colectarea metricilor, are sens să se pornească imediat colectarea log-urilor și a datelor despre erori de la mașinile validatorilor către o mașină accesibilă dezvoltatorilor blockchain-ului. Aici, nimănui nu îi este convenabil să deformeze informațiile, așa că aceste servicii sunt dezvoltate de echipa proiectului și se pot încredința lor. Este util să se colecteze metrici sistemice de la validatori și, cu siguranță, cele mai importante metrici ale blockchain-ului — pentru DAOBet, acestea sunt timpul de finalizare și întârzâierea ultimului bloc finalizat. Astfel, echipa observă creșterea consumului de memorie pe noduri atunci când se rulează benchmark-uri, precum și problemele unor validatori individuali.
Aspecte importante referitoare la desfășurarea jocului validatorilor
Se pare că, dacă doriți să permiteți oficial validatorilor să atace mașinile unul altuia (neoficial, ei pot oricum să facă acest lucru) — este necesar să formulați separat acest lucru ca testare de securitate din punct de vedere juridic, deoarece legislația unor țări impune sancțiuni pentru DDoS sau atacuri de rețea. O altă întrebare importantă este cum să recompensați validatorii. Premiile naturale sunt tokenii proiectului, care vor fi transferați în mainnet, dar o distribuție masivă de tokeni către oricine a reușit să lanseze un nod — nu este, de asemenea, cea mai bună opțiune. Cel mai probabil va trebui să echilibrați între cele două extreme:
Distribuiți întregul fond de premii conform VP-urilor câștigate
aceasta este foarte democratic și permite tuturor celor care au investit timp și resurse în jocul validatorilor să câștige
dar atrage în joc oameni aleatori fără infrastructură pregătită
Distribuiți fondul de premii top-N validatorilor pe baza rezultatelor jocului
câștigătorii vor fi cel mai probabil validatorii care au rezistat cel mai constant pe parcursul jocului, foarte concentrați pe victorie
partea validatorilor nu va dori să participe, evaluând slab șansele de a câștiga, mai ales dacă în rândul participanților sunt validatorii experimentați
Ce variantă să preferați — este alegerea dumneavoastră
Mai este un aspect — nu este deloc sigur că zeci de validatorii se vor grăbi să participe la jocul vostru la apelul vostru, iar dintre cei care decid să încerce, nu toți vor instala și lansa un nod — de obicei, în această etapă, proiectele au documentație destul de slabă, apar erori, iar dezvoltatorii care lucrează sub presiune răspund la întrebări nu foarte prompt. Prin urmare, înainte de lansarea jocului, trebuie să prevedem acțiuni, în cazul în care nu se va strânge numărul necesar de validatorii. În acest caz, la începutul jocului, validatorii lipsă sunt lansați de echipa proiectului, participă la consens, dar nu pot fi câștigători.
Concluzie
În concluzie, am încercat să adun din cele descrise mai sus o listă cu ceea ce trebuie să fie gândit, realizat și lansat pentru desfășurarea eficientă a jocului validatorilor
Ce trebuie făcut pentru lansarea unui adevărat joc al validatorilor:
să dezvoltați propriul blockchain 🙂
- să creați și să ridicați o interfață web și să oferiți CLI pentru votarea validatorilor
- asigurați-vă că metricile de la nodul validator activ pot fi trimise către un serviciu centralizat (de exemplu, Prometheus)
- configurați un server de colectare a metricilor (Prometheus + Grafana) pentru jocul validatorilor
- gândiți-vă la cum vor fi calculate Punctele Validator (VP)
- dezvoltați un script public care să calculeze VP-ul validatorilor pe baza datelor din blockchain
- creați o interfață web pentru a afișa cei mai buni validatori și starea jocului validatorilor (cât timp a mai rămas până la final, câte VP are fiecare etc.)
- dezvoltați și automatizați lansarea unui număr arbitrar de noduri proprii, proiectați procesul de conectare a validatorilor la joc (când și cum să deconectați nodurile proprii, să trimiți și să retrageți voturile pentru acestea)
- calculati câte tokenuri trebuie distribuite și dezvoltați un contract-faucet
- faceți un script de benchmark (transferuri de tokenuri, utilizare masivă a stocării, utilizare masivă a rețelei)
- adunați toți participanții într-un singur chat pentru o comunicare rapidă
- lansați blockchain-ul puțin înainte de începerea jocului
- așteptați blocul inițial, începeți jocul
- testați rețeaua cu mai multe tipuri de tranzacții
- implementați hardfork-ul
- modificați lista validatorilor
- repetați punctele 13, 14, 15 în ordini diferite, menținând stabilitatea rețelei
- așteptați blocul final, terminați jocul, calculați VP
Trebuie să menționez că jocul validatorilor este o poveste nouă și a fost realizat doar de câteva ori, așa că nu ar trebui să considerați acest text ca un ghid complet. Nu există analogi în afacerea IT modernă - imaginați-vă că băncile, înainte de a lansa sistemul de plăți, concurează între ele despre cine va efectua cel mai bine tranzacțiile clienților. Abordările tradiționale vor avea puțin succes în crearea unor rețele descentralizate mari, așadar învățați noi modele de afaceri, desfășurați-vă jocurile, identificați cei merituoși, recompensați-i și lăsați ca sistemele dumneavoastră distribuite să funcționeze rapid și stabil.
Sursa: habr.com
