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

Nii, teie meeskond on lõpetanud oma blokiahela alpha-versiooni, ja nüüd on aeg käivitada testnet, seejärel mainnet. Teil on tõeline blokiahel, iseseisvate osalistega, hea majandusmudel, küberturvalisus, olete kavandanud juhtimise ja nüüd on aeg seda kõike proovida. Ideaalsetes krüptoanarhilistes tingimustes postitate geneesi ploki, lõpliku sõlme koodi ja valideerijad käivitavad kõik ise, tõstavad üles kõik abiteenused ja kõik juhtub iseenesest. Kuid see on väljamõeldud maailmas, reaalses elus peab meeskond ette valmistama rohkesti abiseadet ja erinevaid manipuleerimisi, et aidata valideerijatel üles ehitada stabiilne võrk. Sellest räägib see artikkel.

Konsensusmehhanismide, nagu „tõendus osalusest” (proof-of-stake), põhjal töötavate võrkude käivitamine, kus valideerijad määratakse süsteemi tokeni hoidjate häältega, on üsna spetsiifiline ettevõtmine, kuna isegi traditsiooniliste, tsentraliseeritult hallatavate süsteemide käivitamine, millel on kümneid ja sadu, serverid iseseisvate osaliste pingutustest vajalike ülesannete täitmine, ei ole lihtne ülesanne, ja blokiahel tuleb käivitada ustavate, kuid iseseisvate osaliste panuse abil. Ja kui ettevõttes saavad administraatorid käivitamisel täieliku ligipääsu kõikidele masinatele, logidele ja üldistele jälgimistulemustele, siis valideerijad ei lase kedagi oma serveritesse ning tõenäoliselt eelistavad nad ehitada oma infrastruktuuri iseseisvalt, kuna see kontrollib ligipääsu valideerija peamistele varadele – hääletustokenitele. Just selline käitumine võimaldab luua jaotatud turvalisi võrke – sõltumatuse kasutatavatest pilveteenuse pakkujatest, virtuaalsetest ja „bare-metal” serveritest, erinevatest operatsioonisüsteemidest, kõik need tegurid muudavad rünnakud sellises võrgus äärmiselt ebaefektiivseks – liiga palju erinevaid tarkvarasid kasutatakse. Näiteks Ethereumis kasutatakse kahte peamist sõlme rakendust, ühel Go-l ja teisel Rust-il, ja rünnak, mis on tõhus ühe rakenduse jaoks, ei tööta teise puhul.

Seetõttu peavad kõik plokiahelate käivitamise ja töötamise protsessid olema korraldatud nii, et igal valideerijal või isegi väiksel valideerijate rühmal oleks võimalik igal hetkel oma arvutid aknast välja visata, ilma et midagi läheks katki, ja ülejäänud valideerijad peaksid suutma jätkata võrgu tõhusat toimimist ning uusi valideerijaid ühendama. Verko käivitamisel, kui üks valideerija asub Euroopas, teine Lõuna-Ameerikas ja kolmas Aasias, on üsna keeruline saavutada mitme sõltumatu rühma ühtset tööd ja motiveerida neid tulemusi saavutama.

Valideerijad

Kujutage ette hüpoteetilise moodsa plokiahela käivitamist (enamik kirjeldatut sobib igasuguste kaasaegsete plokiahelate perede, nagu Ethereum, EOS, Polkadot, Cosmos ja teiste puhul, kus kasutatakse tõendusmehhanismi proof-of-stake. Selliste plokiahelate peamised tegijad on valideerijate meeskonnad, kes paigaldavad oma sõltumatud serverid, valideerivad ja loovad uusi plokke ning saavad võrgu poolt ette nähtud preemiaid nende konsensusvalikute eest. Uute võrkude käivitamiseks on vajalik mitu tosinat valideerijat (nii palju suudavad praegu enam-vähem tõhusalt saavutada konsensust sekundite jooksul), seega kuulutab projekt välja registreerimise, kus valideerijad jagavad kasutajatele enda avalikku teavet, veendes neid, et nad kavatsevad kvaliteetselt hallata käivitatavat võrku.

Valideerimine on äri, mis võimaldab väga täpselt hinnata valideerija potentsiaalset tulu, kiiresti üle kanda ressursse projektide vahel ning juhul, kui valitud võrk osutub edukaks, saab valideerija täieõiguslikuks DAO liikmeks ja vastutavaks isikuks projekti arendamise osas või pakkuda lihtsalt suurepärast tehnilist teenust täiesti läbipaistvate ja õiglaste teenitud rahade eest. Valideerijatele tehtava preemia arvutamisel püüavad projektid arvestada valideerijate kulusid ja teha plokkide preemia selliseks, et see äri oleks kasumlik, kuid samas ei lasta valideerijatel majandust kokku kukutada, tarnides neile raha ja jättes võrgu teiste kasutajatega ilma.

Validatorite äri nõuab teenuste kõrget taluvust, mis tähendab ka kõrget taset devops'ide ja arendajate ettevalmistuses ning mitte odavaid arvutusressursse. Isegi ilma vajaduseta kaevandada hash'e proof-of-work võrkudes, on plokiahela node suur teenus, mis kasutab palju mälu, tarbib palju arvutusi, valideerib, salvestab kettale ja edastab võrgus suuri andmemahtusid. Tehingu logi ja ploki ahelate salvestamiseks plokiahelas, kus on mitu tuhat väikest tehingut ploki kohta, on nüüd vajalik salvestusruum alates 50 Gb või rohkem, ja plokkide jaoks peaks see olema SSD. Nutilepingutega plokiahede staatiline andmebaas võib juba ületada 64Gb RAM-i. Nõutava omadustega serverid on üsna kallid, Ethereum'i või EOS'i node võib maksma minna 100 kuni 200 $/kuu. Lisage sellele suurenenud tööjõud, et arendajad ja devops töötaksid ööpäevaringselt, lahendades käivitamise ajal probleeme isegi öösel, kuna osa valideerijatest võib olla kergesti teises hemisfääris. Sellegipoolest, soodsatel hetkedel võib validatsiooni node'i omamine tuua tõsist tulu (EOS'i puhul kuni 10 000$ päevas).

Valideerimine on vaid üks uutest potentsiaalsetest IT-rollidest ettevõtjate ja ettevõtete jaoks. Mida enam programmeerijad leiutavad keerukamaid algoritme, mis võimaldavad auhindade andmist aususele ja karistamist petmise ja varguse eest, sünnivad teenused, mis täidavad oluliste andmete avaldamise funktsioone (oraaklid), teenused, mis teostavad järelevalvet (deposiitide slashing ja petjate karistamine, avaldades petmise tõendeid), vaidluste lahendamise teenused, kindlustus ja optsioonid. Ieven garbage collection on potentsiaalselt suur turuvaldkond nutilepingute süsteemides, kus on vajalik andmete säilitamise eest tasumine.

Plokiahela käivitamise probleemid

Plokia avatud olemus, mis võimaldab igasuguste riikide arvutite võrku vaba juurdepääsu ja lihtne ühendamine igasuguste script kiddie'dega GitHub'i juhiste järgi, ei ole alati eelis. Uue tokeni taga ajamine sunnib valideerijaid "kaevandama uut münti alguses", lootes kursuse tõusule ja võimalusele kiiresti teenitud müntidest vabaneda. See tähendab ka, et teie valideerija võib olla keegi, isegi anonüümne, kelle poolt saab hääletada nagu teiste valideerijate puhul (tõsi, anonüümsel on keeruline koguda hääli osalejatelt, nii et jäänud õuduslood anonüümsest krüptorahast jätame poliitikutele). Mitte siiski

Projekti meeskonnal on eesmärk — kuidagi kaasata oma võrku neid, kes tulevikus suudavad tagada nodede stabiilse töö, mõistavad turvalisust, oskavad kiiresti lahendada probleeme, koostööd teha teiste valideerijatega ja tegutseda ühiselt — nende omaduste järgi sõltub täielikult kvaliteet sellest tokenist, millele osalejad plaanivad oma aega ja ressursse investeerida. Adekaatsed asutajad mõistavad riske ja teavad hästi, et nii suure mahuga tarkvara käivitamisel tuleb paratamatult silmitsi seista koodivigade, nodede konfiguratsiooniprobleemidega, ja et võrgu stabiilsus sõltub sellest, kui hästi suudavad arendajad ja valideerijad üheskoos selliseid probleeme lahendada.

Meeskond on valmis mainnet'is hääletama mis tahes valideerijate poolt, aga kelle poolt? Millised on head? Suurim portfell? Praegu pole seda peaaegu kellelgi. Linkedin'i profiilide järgi? Kogenud devops'id või turvatöötajad ei anna teile mingeid profiile Linkedin'is. Vestlustes tehtud avalduste, postituste ja teiste abistamise põhjal ettevalmistamise etapis? Huvitav, kuid subjektiivne ja ebatäpne.

Sellistes tingimustes jääb üks — see, mis lahendab kõigi probleeme — mäng, kus saate valida parimad valideerijad, kuid peamine — testida plokiahelat tema tugevuse osas ning läbi viia ulatuslik lahingu test plokiahela puhul aktiivse kasutamise, konsensuse muutuste ja vigade ilmnemise ja parandamise tingimustes. Esmakordselt esitas selle protseduuri mänguna projekti Cosmos meeskond, ja see idee on kahtlemata suurepärane viis võrgu ettevalmistamiseks usaldusväärse ja häirekindla mainnet'i käivitamiseks.

Valideerijate mäng

Ma kirjeldan valideerijate mängu nii, nagu me selle blockchain DAO.Casino (DAOBet) jaoks projekteerisime, tuginedes EOS-i forkile, mida nimetatakse Haya ja millel on sarnane juhtimismehhanism — valideerijad valitakse häältega igalt kontolt, kusjuures osa häältega valitud valideerija saldo külmutatakse. Iga konto, millel on põhisümbol BET, võib hääletada valitud valideerija poolt mis tahes osa oma saldos. Hääled summeeritakse ning tulemused moodustavad valideerijate tipud. Erinevates blockchain'ides on see protsess korraldatud erinevalt ja tavaliselt just selles osas erineb uus blockchain oma eelkäijast, ning tuleb öelda, et meie puhul õigustab EOS täielikult „OS”-i oma nimetus, me tõepoolest kasutame EOS-i modifitseeritud blockchaini versiooni käivitamiseks DAOBet'i ülesannete täitmiseks.

Käsitlen eraldi probleeme ja seda, kuidas neid mängu raames lahendada. Kujutame ette võrku, kus sinu serverit võivad avatud rünnakute objektiks, kus valideerija positsiooni säilitamiseks on vaja pidevalt suhelda võrguga, edendades oma valideerijat ja jälgides, et ta genereeriks plokke ning need viivitamatult ülejäänud valideerijateni jõuaks, vastasel juhul paisatakse valideerija loendist välja.

Kuidas valida tipupreemia saajaid?

Peamine tehniline nõue mängule on see, et selle tulemusi tuleks avalikult kontrollida. See tähendab, et mängu tulemused: TOP preemia saajad, peavad olema moodustatud rangelt andmete põhjal, mida iga osaleja saab kontrollida. Centraliseeritud süsteemis saaksime mõõta iga valideerija „ülesoleku aega” ja premeerida neid, kes on rohkem online või kes töötlesid läbi maksimumvõrgu liiklust. Saame koguda andmeid protsessori ja mälu koormuse kohta ning premeerida neid, kes väärikalt töötasid. Kuid igasugune selline metrikate kogumine tähendab kogumispunkti olemasolu, ja nodid on kõik iseseisvad ning võivad käituda nagu soovivad ning edastada mis tahes andmeid.

Seetõttu on loomulik lahendus — võitjad peaksid olema määratud plokiahela andmete põhjal, kuna selle abil on võimalik näha, kes validatoritest millise bloki tootis ja millised tehingud sellesse lisati. Oleme nimetanud seda arvu Validator Points (VP), ja nende teenimine ongi validatorite põhieesmärk mängus. Meie puhul on kõige lihtsam, avalikult kontrollitav ja tõhus ‘kasutatavuse’ mõõdik validatorite jaoks VP = validatorite loodud blokkide arv antud ajaperioodi jooksul.

Selline lihtne valik on tingitud sellest, et EOSis on juhised juba ette näinud palju tekkivaid probleeme, kuna EOS on kolme põlvkonna tõeliselt töötava plokiahela järglane, millel on suur kogemus keerulise võrgu juhtimisega, ja praktiliselt kõik validatorite probleemid võrgu, protsessori, ketas on seotud vaid ühe probleemiga — nad allkirjastavad vähem blokke, saavad vähem tasu oma töö eest, mis viib meid jälle lihtsalt allkirjastatud blokkide arvuni — EOS jaoks on see suurepärane ja lihtne valik.

Teistel plokiaheladel võib Validator Points'i arvestamise meetod erineda, näiteks pBFT-põhiste konsensuste (Tendermint/Cosmos, Aura konsensus Parity Substratest), kus iga blokk peab olema allkirjastatud paljude validatorite poolt, on mõistlik lugeda eraldi validatorite allkirju, mitte blokke, võib-olla on mõistlik arvesse võtta ka lõpetamata konsensuse ringe, mis raiskavad teiste validatorite ressursse, tegelikult sõltub see kõik konsensuse tüübist.

Kuidas simuleerida reaalset kasutustingimust

Esialgsed ülesanded on kontrollida valideerijaid tingimustes, mis on võimalikult sarnased reaalsusele, ilma igasuguse tsentraliseeritud kontrollita. Selle probleemi saab lahendada faucet-lepingu abil, mis jagab valdajatele ja soovijatele võrdses koguses põhiväärtpaberit. Tokenite saamiseks tuleb moodustada tehing ja saavutada, et võrk lisab selle plokki. Seetõttu peab valideerija edu saavutamiseks pidevalt oma saldo täiendama uute tokenitega ja endale hääletama, edendades end tipptasemele. See tegevus loob pideva koormuse võrgule, ja parameetreid saab seadistada nii, et päringute voog oleks piisavalt intensiivne, et korralik võrk testida. Seetõttu planeeri faucet-leping eelnevalt, kui oluline tööriist võrgu käivitamiseks ja alusta tema parameetrite valimist varakult.

Tokenite taotlemine faucet'ist ja valideerijate hääletamine ei suuda siiski täielikult ausalt emuleerida plokiahela toimimist, eriti ülikoormatud režiimides. Seetõttu peab plokiahela meeskond igal juhul kirjutama täiendavad benchmark'id, mis võimaldavad võrgule koormust rakendada. Eriti olulist rolli mängivad spetsiaalselt eelnevalt loodud nutilepingud, mis võimaldavad testida konkreetset alamsüsteemi. Andmete salvestamiseks säilitab leping plokiahelas juhuslikke andmeid, ning võrguressursside kontrollimiseks nõuab testileping suurte sisendandmete mahtu, sellega laiendades tehingute mahtu - käivitades selliste tehingute vooge juhuslikel hetkedel testib meeskond samaaegselt koodi stabiilsust ja valideerijate usaldusväärsust.

Eraldi küsimus on sõlmpunktide koodi värskendamine ja kõva haru läbi viimine. On vajalik, et juhul kui ilmneb viga, haavatavus või pahatahtlike valideerijate kokkulepe, oleksid valideerijatel tegevuskava, mis on juba valideerijate mängus välja töötatud. Siinkohal võib välja pakkuda skeeme VP-de määramiseks kiire haru rakendamise eest, näiteks karistades kõiki valideerijaid, kes pole veel rakendanud uut sõlmpunkti koodiversiooni, kuid see on keeruline ellu viia ja raskendab arvestust. Rootorite kiirusest tingitud olenematu haru kiire rakendamise simuleerimiseks saab kunstlikult "purustada" plokiahel kindlas plokis. Plokkide tootmine peatub ja lõpuks saavad kasu need, kes esimesena aktiivseks saavad ja plokkide allkirjastamisega alustada, nii et VP, mis põhineb allkirjastatud plokkide arvul, sobib hästi.

Kuidas teavitada osalejaid võrgu seisundist ja parandada vigu

Malaside vahelise usalduse puudumisest hoolimata on õigeaegne juurdepääs võrgu seisundi kohta käivale asjakohasele teabele kasulik kõigile otsuste kiiremaks vastuvõtmiseks. Seetõttu loob projektimeeskond teenuse valideerijate serveritest saadud dünaamiliste mõõdikute kogumiseks ja visualiseerimiseks, mis võimaldab näha olukorda samaaegselt kogu võrgus, võimaldades kiiresti kindlaks teha, mis toimub. Samuti on nii valideerijatele kui projektile kasulik, et projektimeeskond kiiresti tuvastatud vigu kõrvaldada, seega on lisaks mõõdikute kogumisele mõistlik kohe käivitada valideerija masinatelt logide ja veateabe kogumine masinale, mis on arendajatele plokiahela jaoks kergesti ligipääsetav. Keegi ei soovi informatsiooni väärata, seega tõstab need teenused projektimeeskond, kellele saab usaldada. On mõistlik koguda süsteemimõõdikuid valideerijatelt ja kindlasti ka kõige olulisemaid plokiahela mõõdikuid – DAOBet jaoks on need lõpuleviimise aeg ja viimasena lõpetatud ploki viivitus. Tänu sellele näeb meeskond, kuidas mälutarbimine sõlmpunktides suurenev katsetamisel, ning individuaalsete valideerijate probleeme.

Olulised punktid valideerijate mängu läbiviimisel

Selgus, et kui soovite ametlikult lubada valideerijatel üksteise masinate kallale tungida (mitte ametlikult saavad nad seda juba teha) - tuleb see eraldi õiguslikult sõnastada kui turvatestimine, kuna mõnede riikide seadused võivad DDoS või võrgu rünnakute eest karistada. Samuti on oluline küsimus, kuidas tunnustada valideerijaid. Loomulikud auhinnad on projekti tokenid, mis kantakse mainnetisse, kuid tohutu tokenite jagamine igaühele, kes suudab sõlme käivitada, ei ole ka parim võimalus. Tõenäoliselt peate tasakaalustama kahe äärmuse vahel:

Jagada kogu auhinnafond vastavalt teenitud VP-dele
see on väga demokraatlik ja võimaldab teenida kõigil, kes on panustanud aega ja ressursse valideerijate mängu
kuid meelitab mängu juhuslikke inimesi, kellel pole ettevalmistatud infrastruktuuri

Jagada auhinnafond parimatele N valideerijatele mängu tulemuste põhjal
võitjate seas on tõenäoliselt valideerijad, kes on kõige stabiilsemalt püsima jäänud mängu jooksul, kes on väga põhjalikud võidu nimel
osa valideerijatest ei soovi osaleda, hinnates madalalt oma võimalusi võita, eriti kui osalejate seas on tuntud valideerijaid

Millisele variandile eelistada — see on teie otsustada

On veel üks punkt — ei ole sugugi kindel, et kümned valideerijad tormavad osalema mängus teie kutsel, ja neist, kes otsustavad proovida, ei pruugi kõik isegi nodi installida ja käivitada — tavaliselt on sellel etapil projektidel üsna puudulik dokumentatsioon, esinevad vead ja tihedas graafikus töötavad arendajad ei vasta küsimustele eriti kiiresti. Seetõttu tuleb enne mängu käivitamist ette näha tegevused, kui vajalikke valideerijaid ei koguneda. Sel juhul mängu alguses käivitavad vajalikke valideerijaid projekti meeskond, osalevad konsensuses, kuid ei saa olla võitjad.

Kokkuvõte

Kokkuvõtteks püüdsin kokku koondada loendi sellest, mida on vaja välja mõelda, teha ja käivitada, et validaatorite mängu tõhusalt läbi viia

Mida on vaja teha, et käivitada õiget valideerijate mängu:
arendada oma plokiahelat 🙂

• luua ja käivitada veebiliides ning pakkuda CLI-d valideerijate hääletamiseks
• teha, et metrikad käivitatud valideerija sõlmedelt saaksid saata andmeid tsentraliseeritud teenusele (nt Prometheus)
• seada üles metrikate kogumise server (Prometheus + Grafana) valideerijate mängu jaoks
• mõelda välja, kuidas arvestatakse valideerija punkte (VP)
• arendada välja avalik skript, mis arvutab valideerija VP-d plokiahela andmete põhjal
• arendada välja veebivahend, et kuvada tippe valideerijate ja nende mängu olekut (kui palju aega on jäänud, kellel on mitu VP jne)
• arendada ja automatiseerida oma sõlmede käivitamine suvalises arvus, kavandada protsessi valideerijate ühendamiseks mänguga (millal ja kuidas lõpetada oma sõlmed, anda ja eemaldada nende hääli)
• arvutada, kui palju token'e tuleb välja anda ja arendada fauceti lepingut
• teha skript, mis töötab benchmark'ina (token'i ülekanded, massiivne salvestuse kasutamine, massiivne võrgu kasutamine)
• tuua kõik osalised ühte vestlusesse kiireks suhtlemiseks
• käivitada plokiahel veidi enne mängu algust
• oodata algusplokki, alustada mängu
• katsetada võrku mitmete tehingute tüüpidega
• rakendada hard fork
• muuta valideerijate loendit
• korrata p.13, 14, 15 erinevas järjestuses, säilitades võrgu stabiilsuse
• oodata lõppplokki, lõpetada mäng, arvutada VP-d

Tuleb öelda, et valideerijate mäng on uus lugu ja seda on korraldatud vaid paar korda, seega ei tasu seda teksti võtta kui valmismaterjali. Kaasaegses IT-äri maailmas ei ole sellele analooge - kujutage ette, et pangad konkurentide seas enne maksesüsteemi käivitamist võistlevad, kes suudab paremini kliendi tehinguid teostada. Traditsioonilised lähenemised ei aita teil luua suuri detsentraliseeritud võrke, seega õppige uusi ärimudeleid, korraldage oma mänge, määrake väärilised, premeerige neid ja laske oma jaotatud süsteemidel töötada kiiresti ja stabiilselt.

Allikas: habr.com