Mis on valideerijate mäng või "kuidas käivitada proof-of-stake plokiahel"

Nii, teie meeskond on lõpetanud oma plokiahela alpha-variandi ja on aeg käivitada testnet ja seejärel mainnet. Teil on tõeline plokiahel, sõltumatud osalised, tugev majandusmudel, turvalisus, olete kavandanud valitsemise ja nüüd on aeg kõik see praktikas proovida. Ideaalmaal, kus valitseb krütoanarkhia, panete te võrku genesis block'i, lõpliku sõlme koodi ja valideerijad käivitavad kõik iseseisvalt, tõstavad kõik toetavad teenused ja kõik juhtub iseenesest. Kuid see on väljamõeldud maailm, reaalses elus peab meeskond ette valmistama üsna palju abiprogramme ja erinevaid toiminguid, et aidata valideerijatel käivitada stabiilne võrk. Sellest räägib käesolev artikkel.

Konsensusel põhinevate võrkude, nagu "proof-of-stake", käivitamine, kus valideerijad määratakse süsteemi tokenite omanike häältega, on üsna spetsiifiline ettevõtmine, sest isegi traditsiooniliste, tsentraliseeritud süsteemide käivitamine, kus on kümneid ja sadu ... serverite see endab ysamat, kuid blokkhaip vajab usaldusväärsete, kuid sõltumatute osalejate jõupingutusi. Ja kui ettevõttes, käivitamisel, administreerijatel on täielik juurdepääs kõigile masinatele, logidele ja üldisele jälgimisele, siis valideerijad ei lase kedagi oma serveritesse ja tõenäoliselt eelistavad nad rajada oma infrastruktuuri iseseisvalt, kuna see kontrollib juurdepääsu valideerija peamisele varale — hääletamise stake’idele. Just see käitumine võimaldab luua jaotatud ohutuid võrke — kasutatavate pilveteenuste sõltumatuse, virtuaalsete ja “baremetal” serverite, erinevate operatsioonisüsteemide, kõik see muudab sellise võrgu rünnakud äärmiselt ebaefektiivseks — liiga palju erinevat tarkvara kasutatakse. Näiteks Ethereumis kasutatakse kahte peamist node'i rakendust, ühe Go ja teise Rust keeles, ja rünnak, mis on tõhus ühe rakenduse jaoks, ei toimi teise jaoks.

Seetõttu peavad kõik plokiahela käivitamise ja haldamise protsessid olema organiseeritud nii, et iga valideerija või isegi väike valideerijate grupp saaks igal hetkel oma arvutid aknast välja visata ja lahkuda, samas ei tohi midagi katki minna ning allesjäänud valideerijad peaksid jätkama võrgustiku tõhusat toimimist ja uute valideerijate liitmist. Võrgu käivitamisel, kui üks valideerija on Euroopas, teine Lõuna-Ameerikas ja kolmas Aasias, on mitme sõltumatu grupi koordineerimine ja nende motiveerimine tulemuse nimel üsna keeruline.

Valideerijad

Kujutame ette hüpoteetilise kaasaegse plokiahela käivitamist (enamik siin kirjeldatust kehtib igasuguste kaasaegsete plokiahela perede, nagu Ethereum, EOS, Polkadot, Cosmos ja teiste, jaoks, kus on rakendatud proof-of-stake konsensus. Selliste plokiahelate peamisteks tegijateks on valideerijate meeskonnad, kes paigaldavad oma iseseisvaid servereid, valideerivad ja loovad uusi ploke ning saavad võrgu ettenähtud preemiaid, mis on suunatud neile, kes osalevad konsensusprotsessis. Uute võrkude käivitamiseks on vaja mitmeid tosin validaatorit (nii palju saab nüüd enam-vähem tõhusalt sekundite jooksul konsensust saavutada), seega kuulutab projekt välja registreerimise, mille käigus validaatorid jagavad kasutajatega avalikku teavet enda kohta, veendes neid, et nad on valmis kvaliteetselt teenindama käivitatavat võrku.

Validatsioon on äri, mis võimaldab väga täpselt hinnata valideerija potentsiaalset tulu, kiiresti üle kanda ressursse erinevate проектide vahel. Kui valitud võrk saavutab edu, võib valideerija kas osaleda DAO täieõiguslik liikmena ja vastutajana projekti edendamises või lihtsalt pakkuda suurepärast tehnilist teenust täiesti läbipaistvalt ja ausalt teenitud raha eest. Valideerijatele antava tasu arvutamisel püüavad projektid arvesse võtta valideerijate kulusid ja määrata plokkide tasu selliseks, et äri oleks kasumlik, aga samas ei võimaldaks valideerijatel majandust kokku varisemisest päästa, üleujutades seda rahaga ning jättes teiste võrgu kasutajad ilma.

Ärivalideerijate äri nõuab teenuste kõrge töökindluse tagamist, mis omakorda tähendab suurepäraste devopside ja arendajate ettevalmistamist ning kallite arvutusressursside kasutamist. Isegi ilma vajaduseta tööproovi võrgustikes hash'e kaevandada on blokeerimise sõlm suur teenus, mis tarbib palju mälu, vajab palju arvutust, valideerib, salvestab andmeid kettale ning edastab võrgus suurtes kogustes andmeid. Mitme tuhande väikese tehinguga ploki jaoks vajab plokiahela tehingute logi ning plokkide ahel salvestamiseks nüüd vähemalt 50 Gb salvestusruumi, kusjuures SSD peaks olema plokkide jaoks. Nutikliendile toetavate plokiahelate olekute andmebaasid võivad juba ületada 64 Gb RAM-i. Nõutavate omadustega serverid on üsna kallid, näiteks võib Ethereum'i või EOS-i sõlm maksma minna 100 kuni 200 $/kuus. Lisage sellele kõrgem tööjõukulu ööpäevaringselt töötavate arendajate ja devopside võrdluses, kes periodi käivitamisel lahendavad probleeme ka öösel, kuna osa valideerijatest võib asuda teises maailmas. Siiski, õnnelikel hetkedel võib valideerijana sõlm omamine tuua tõsist tulu (EOS-i puhul kuni 10 000 $ päevas).

Valideerimine on vaid üks uutest potentsiaalsetest IT-rolletest ettevõtjatele ja ettevõtetele. Kõik sügavamad algoritmid, mille programmid loovad, et tunnustada ausust ja karistada petmist ja vargusi, toovad endaga kaasa teenuseid, mis avaldavad olulisi andmeid (oraklid), teostavad järelevalvet (deposiitide lõhkumist ja petjate karistamist, avaldades petmisproove), vaidluste lahendamise teenuseid, kindlustusi ja optsioone. Isegi prügikogumine on potentsiaalselt suur turg nutilepingutes, kus andmete salvestamise eest tuleb maksta.

Plokiahela käivitamise probleemid

Blokeerimise avatus, mis võimaldab vabalt osaleda võrgu arvutite töös igast riigist ning lihtne ühendamine mis tahes script kiddie'ga GitHubi juhiste abil ei ole alati eeliseks. Uue tokeni jahtimine sunnib valideerijaid "kaevandama uut münti alguses", lootes kursuse tõusule ja võimalusele kiiresti teenitud raha maha müüa. Samuti tähendab see, et teie valideerijaks võib olla keegi, isegi anonüümne, kelle kasuks on võimalik niisama hääletada nagu teiste valideerijate puhul (kuigi anonüümsel on tõenäoliselt keeruline koguda hääli osalejatelt, seega jätkame hirmutavaid lugusid anonüümsetest krüptovaluutadest poliitikutele). Siiski

Projekti meeskonnal on ülesanne — kuidagi kaasata oma võrku inimesi, kes suudavad tulevikus tagada sõlmede stabiilse töö, tunnevad turvalisust, oskavad kiiresti lahendada probleeme, teha koostööd teiste valideerijatega ja tegutseda ühiselt — nendest omadustest sõltub täielikult selle tokeni kvaliteet, kuhu neti osalised plaanivad oma aega ja ressursse investeerida. Adekaatsed asutajad, hinnates riske, mõistavad hästi, et sellise mahuka tarkvara käivitamisel tuleb kindlasti silmitsi seista koodivea ja sõlmede konfiguratsiooniga, ning et võrgu stabiilsus sõltub sellest, kui hästi arendajad ja valideerijad suudavad selliseid probleeme ühiselt lahendada.

Meeskond on valmis mainnetis hääletama mistahes valideerijate poolt, aga keda hääletada, kes on head? Suurema portfelliga? Praegu ei ole seda praktiliselt kellelgi. LinkedInis tiimi profiilide järgi? Kogenud DevOpsid või turbeeksperdid ei anna teile LinkedInis mingeid profiile. Vestluses esitatud avalduste, postituste ja teiste abistamise etapis? See on hea, aga subjektiivne ja ebatäpne.

Sellistes tingimustes jääb üle vaid see, mis tõhusalt lahendab kõiki probleeme — mäng, kus saab valida parimaid valideerijaid, kuid kõige tähtsam on testida plokiahela vastupidavust ja viia läbi ulatuslik lahingutest plokiahelas aktiivse kasutuse, konsensuse muutuste ning vigade tekkimise ja kõrvaldamise tingimustes. Esmakordselt esitasid selle protseduuri mänguna projekt Cosmos, ja see idee on kahtlemata suurepärane viis võrgu ettevalmistamiseks usaldusväärse ja tõrgeteta mainneti käivitamiseks.

Valideerijate Mäng

Kirjeldan valideerijate mängu nii, nagu me selle projekteerisime DAO.Casino (DAOBet) plokiahelale, mis põhineb EOS fork'il, mida nimetatakse Haya ja millel on sarnane haldussüsteem — valideerijad valitakse häältega igalt kontolt, mille korral osa häältega valitud valideerija häälest külmutatakse. Igal kontol, millel on baas-token BET, on võimalik hääletada valitud valideerija poolt mistahes oma saldo osaga. Hääled summeeritakse ja selle põhjal koostatakse valideerijate edetabel. Erinevates plokiahelates on see protsess korraldatud erinevalt ja tavaliselt just selles osas erineb uus plokiahel oma vanemast. Pean ütlema, et meie juhul õigustab EOS täielikult oma nime „OS”, kuna kasutame tõeliselt EOS'i põhjaliku operatsioonisüsteemina kohandatud plokiahela käitamiseks DAOBet'i ülesannete jaoks.

Ma kirjeldan eraldi probleeme ja kuidas neid mängu raames lahendada. Kujutame ette võrku, kus sinu serverit võivad avatud rünnakud ohustada, kus validatorina püsimiseks on pidev suhtlemine võrguga hädavajalik, edendades oma validaatorit ning jälgides, et see tootaks plokke, mis jõuavad õigel ajal teiste validaatoriteni; vastasel juhul visatakse validaator nimekirjast välja.

Kuidas valida parimaid võitjaid?

Mängu peamine tehniline nõue on, et selle tulemused peavad olema avalikult kontrollitavad. See tähendab, et mängu top võitjate nimekiri peab olema koostatud rangelt andmete põhjal, mida võib kontrollida iga osaleja. Tsentraliseeritud süsteemis võiksime mõõta iga validaatori 'uptime'i ja auhinda neid, kes on rohkem online või kes on läbi lasknud kõige rohkem võrgu liiklust. Saame koguda andmeid protsessori ja mälu koormuse kohta ning auhinda neid, kes on oma töö hästi ära teinud. Kuid igasugune selline mõõtmiste kogumine eeldab keskset kogumispunkti, ja nodid on kõik sõltumatud, võttes endale tegevuse, nagu nad soovivad, ja edastades mis tahes andmeid.

Seetõttu on loogiline lahendus, et võitjad peaksid olema määratud plokiahela andmete põhjal, kuna sealt on näha, millised valideerijad on millise ploki tootnud ja millised tehingud sinna lisatud. Me nimetasime selle numbri Validator Points (VP) ja selle teenimine on valideerijate peamine eesmärk mängus. Meie puhul on kõige lihtsam, avalikult kontrollitav ja tõhus “kasutuse” mõõdik valideerijale VP = valideerija toodetud plokkide arv kindlal ajaperioodil.

Selline lihtne valik tuleneb sellest, et EOSi haldamine hõlmab juba mitmeid tekkivaid probleeme, kuna EOS on kolme reaalselt töötava plokiahelageneratsiooni järglane, millel on suur kogemus keerulise võrguhalduse vallas. Praktikas põhjustab iga valideerija probleem võrgu, protsessori või kettaga lihtsalt ühe probleemi — ta allkirjastab vähem plokke, saab vähem tasu oma töö eest, mis viib meid taas plokkide allkirjastamise arvu juurde — EOSi jaoks on see suurepärane ja lihtne valik.

Teistel plokiahelatel võivad Validator Points'i arvestamise viisid erineda, näiteks pBFT-põhiste konsensusmehhanismide (Tendermint/Cosmos, Parity Substrate'i Aura konsensus) puhul, kus iga plokk peab olema allkirjastatud mitme valideerija poolt. On mõistlik arvestada eraldi valideerijate allkirju, mitte plokke. Võib-olla on mõistlik arvesse võtta ka lõpetamata konsensusvoorud, mis kulutavad teiste valideerijate ressursse. Kokkuvõttes sõltub see tugevalt konsensuse tüübist.

Kuidas mudelda reaalseid töötingimusi

Asutajate ülesanne on testida valideerijaid tingimustes, mis on piisavalt lähedased reaalsusele, omamata samal ajal mingit tsentraliseeritud kontrolli. Selle probleemi saab lahendada faucet-lepinguga, mis jagab valideerijatele ja kõigile soovijatele võrdses koguses põhitokenit. Tokenite saamiseks tuleb teostada transaktsioon ja saavutada, et võrk lisab selle plokki. Nii on valideerijal, et võita, vaja pidevalt täiendavaid tokenite summasid ja hääletada enda poolt, edendades ennast tippu. See tegevus tekitab pidevat koormust võrku, ja parameetreid saab kohandada nii, et päringute voog oleks piisavalt ulatuslik, et teha põhjalik võrgu test. Seetõttu planeerige faucet-leping eelnevalt, kui oluline tööriist võrgu käivitamiseks, ja alustage selle parameetrite kohandamist varakult.

Faucet'i tokenite nõudmine ja valideerijate hääletamine ei imiteeri siiski täielikult plokiahela tööd, eriti äärmiselt koormatud režiimides. Seetõttu peab plokiahela meeskond nagunii kirjutama täiendavaid bänkmärke, mis võimaldavad võrku koormata. Sellel mängivad erilist rolli spetsiaalsete smart-kontraktide eelnevalt loodud süsteemid, mis võimaldavad testida erilisi alamsüsteeme. Storage'i testimiseks salvestab leping plokiahelasse juhuslikke andmeid, ja võrguressursside kontrollimiseks nõuab testileping suurt hulka sisendandmeid, suurendades seeläbi tehingute mahtu — käivitades selliste tehingute voolu juhuslikel hetkedel, testib meeskond samal ajal koodi stabiilsust ja valideerijate vastupidavust.

Eraldi teema on sõlmpunktide koodi uuendamine ja kõvakettaste läbiviimine. Oluline on, et kui ilmneb viga, haavatavus või pahatahtlike valideerijate koostöö, oleks valideerijatel tegevusplaan, mis on juba valideerijate mängus läbi proovitud. Siin saab mõelda skeemidele, kus VP-d (valideerimispunkte) antakse kiire kõvaketta manustamise eest, näiteks karistades kõiki valideerijaid, kes ei ole veel uut sõlmpunkti koodi versiooni rakendanud, kuid see on keeruline teostada ning raskendab arvestust. Hädaolukorra simulatsiooni kõvakettaste kiireks rakendamiseks saab tekitada kunstlikult, „murdes“ plokiahela kindlas plokis. Plokkide tootmine peatub, ja lõpuks on võitjad need, kes varem sisse lülituvad ja plokke hakkavad allkirjastama, nii et VP, mis põhineb allkirjastatud plokkide arvul, sobib siin hästi.

Kuidas teavitada osalejaid võrgu seisundist ja parandada vigu

Kuigi valideerijate vahel on usaldamatust, on kõigile kasulik saada õigeaegselt teavet võrgu seisundi kohta, et kiiremini otsuseid vastu võtta. Seetõttu arendab projektimeeskond teenust, mis kogub ja visualiseerib mitmesuguseid mõõdikuid valideerijate serveritest. See võimaldab korraga näha olukorda kogu võrgu ulatuses ja kiiresti tuvastada, mis toimub. Samuti on nii valideerijate kui projekti huvides, et projektimeeskond saaks kiiresti tuvastatud vigu parandada. Seetõttu on lisaks mõõdikute kogumisele mõttekas koheselt alustada ka logide ja vigade andmete kogumist valideerijate masinatelt arendajatele kergesti ligipääsetavale masinale. Siin ei ole kellelgi kasulik teavet moonutada, seega tõstetakse neid teenuseid projektimeeskonna poolt ja neile saab usaldada. On mõttekas koguda süsteemseid mõõdikuid valideerijatelt ning kindlasti ka kõige olulisemaid enda plokiahela mõõdikuid — DAOBeti jaoks on need lõpuleviimise aeg ja viimase lõpetatud ploki maha jäämine. Tänu sellele näeb meeskond, kuidas mälukasutus node'des suureneb, kui käivitada benchmark, samuti on võimalik tuvastada üksikute valideerijate probleemid.

Olulised punktid valideerijate mängu läbiviimiseks

Kuna selgus, et kui soovite ametlikult lubada valideerijatel üksteise masinatesse rünnata (mitteametlikult saavad nad seda juba teha) — tuleb see eraldi seaduslikult sõnastada kui turvatehnika testimine, kuna paljude riikide seadusandlus karistab DDoS või võrgurünnakute eest. Teine oluline küsimus on, kuidas valideerijaid premeerida. Loomulikud auhinnad on projekti tokenid, mis kantakse mainnetisse, kuid tokenite massiline jagamine igale, kes suudab sõlme käivitada — pole samuti parim valik. Tõenäoliselt peate tasakaalustama kahe äärmuse vahel:

Jaotada kogu auhindade fond vastavalt teenitud VP-dele
see on väga demokraatlik ning võimaldab kõigil, kes on investeerinud aega ja ressursse valideerijate mängusse, raha teenida
aga see meelitab mängu juhuslikke inimesi, kellel puudub ettevalmistatud infrastruktuur

Jaotada auhindade fond top-N valideerijatele mängu tulemuste põhjal
võitjaks saavad tõenäoliselt need valideerijad, kes on mängu jooksul kõige stabiilsemalt vastu pidanud ning olid äärmiselt pühendunud võidule
Mõned valideerijad ei soovi osaleda, hinnates madalaks oma võiduvõimalusi, eriti kui osalejate hulgas on kogenud valideerijaid.

Mille vahel valida — on teie otsustada.

On veel üks asi — ei ole sugugi kindel, et kümned valideerijad tormavad teie kutsest osalema, ja nendest, kes otsustavad proovida, ei jõua kõik isegi node'i seadistada ja käivitada — tavaliselt on projektide dokumentatsioon sel hetkel üsna napp, esinevad vead, ja tegevuses olevad arendajad ei vasta küsimustele eriti kiiresti. Seetõttu tuleb enne mängu algust ette näha ka tegevused, kui vajalikku arvu valideerijaid ei kogune. Sel juhul mängu alguses käivitavad puuduvad valideerijad projekti meeskond, osalevad konsensuses, kuid ei saa olla võitjad.

Kokkuvõte

Lõpetuseks olen üritanud koostada eeltoodud põhjal nimekirja sellest, mida tuleb väljamõelda, teha ja käivitada, et valideerijate mäng tõhusalt toimiks.

Mida on vaja tõelise valideerijate mängu käivitamiseks:
arendada oma plokiahelat 🙂

• luua ja käivitada veebiliides ning pakkuda CLI-d valideerijate hääletamiseks
• tagada, et valideerija käivitatud node'i metrikad saaksid saata andmeid keskserverisse (näiteks Prometheus)
• seada üles metrikate kogumise server (Prometheus + Grafana) valideerijate mängu jaoks
• välja mõelda, kuidas arvestatakse valideerija punkte (VP)
• arendada välja avalik skript, mis arvutab valideerija VP-d blockchaini andmete alusel
• arendada veebiliides, et kuvada top valideerijad ja valideerijate mängu olek (kui kaua on mängu lõpuni, kellel on mitu VP jne)
• arendada ja automatiseerida oma node'ide käivitamise protsess, kavandada valideerijate ühendamise protsess mänguga (millal ja kuidas oma node'e väljalülitada, hääli esitada ja eemaldada)
• kalkuleerida, kui palju token'e on vaja jagada ja arendada välja kontrakti-faucet
• luua skript-benchmark (tokenite ülekanded, andmemassiivne kasutamine, võrgu massiline kasutamine)
• koguda kõik osalised ühte vestlusesse kiireks suhtlemiseks
• käivitada blockchain veidi enne mängu algust
• oodata algbloki saabumist, alustada mängu
• testida võrku erinevat tüüpi tehingutega
• rakendada kõva haru
• muuta valideerijate nimekirja
• korrata p.13,14,15 erinevas järjekorras, tagades võrgu stabiilsuse
• ootama viimast ploki, lõpetama mängu, arvestama VP

Peab ütlema, et valideerijate mäng on uus teema ja seda on korraldatud vaid paar korda, seega ei tohiks seda teksti võtta kui lõplikku juhendit. Kaasaegses IT-äritegevuses ei ole palju analoge — kujutlege, et pangad konkureerivad omavahel enne maksesüsteemi käivitamist, kes suudab klientide tehingud paremini täita. Traditsioonilised lähenemisviisid ei aita tõenäoliselt teil luua suuri detsentraliseeritud võrke, seega õppige uusi ärimudeleid, korraldage oma mänge, määrake väärilised, premeerige neid ning laske oma jaotatud süsteemidel töötada kiiresti ja stabiilselt.

Allikas: habr.com