Pra ne, ekipi juaj përfundoi versionin alpha të blockchain-it tuaj, dhe tani është koha për të nisur testnet-in dhe pastaj mainnet-in. Keni një blockchain të vërtetë, me pjesëmarrës të pavarur, një model të mirë ekonomik, siguri, keni dizajnuar qeverisjen dhe tani është koha ta provoni të gjithë këtë në veprim. Në një botë ideale kriptoanarkiste, ju publikoni në rrjet bllokun e parë, kodin përfundimtar të nodës dhe validuesit e fillojnë gjithçka vetë, ngrisin të gjitha shërbimet ndihmëse dhe gjithçka ndodh natyrshëm. Por kjo është në një botë imaginare, ndersa në të vërtetën, ekipi duhet të përgatisë një sërë softuerësh ndihmës dhe manipulimesh të ndryshme për t’i ndihmuar validuesit të nisin një rrjet të qëndrueshëm. Kjo është tema e këtij artikulli.
Nisja e rrjeteve të bazuara në konsensusin e tipit "proof-of-stake", ku validuesit përcaktohen nga votat e mbajtësve të tokeneve në sistem, është një ngjarje mjaft specifike, pasi madje edhe nisja e sistemeve tradicionale të menaxhuara qendrorisht me dhjetëra dhe qindra serverëve ndërsa vetë është një detyrë e komplikuar, blockchain duhet të niset nga përpjekjet e pjesëmarrësve që janë të besueshëm, por të pavarur. Dhe, nëse në një kompani, gjatë fillimit adminstratorët kanë qasje të plotë në të gjitha makinat, log-et, dhe monitorimin e përgjithshëm, validuesit nuk do të lejojnë askënd të hyjë në serverat e tyre dhe, shumë mundësi, do të preferonin të ndërtonin infrastrukturën e tyre vetë, sepse ajo kontrollon aksesin në asetet kryesore të validuesit — stake-t e votuesve. Kjo sjellje lejon ndërtimin e rrjeteve të sigurta të shpërndara — pavarësia e ofruesve të ndryshëm të cloud, serverëve virtualë dhe 'bare metal', sistemet operative të ndryshme, e gjithë kjo e bën sulmin ndaj një rrjeti të tillë jashtëzakonisht të pasuksesshëm — ka shumë lloje të ndryshme software-i që përdoren. Për shembull, në Ethereum, ka dy implementime kryesore të nodit, një në Go dhe një në Rust, dhe një sulm, i efektshëm për një implementim, nuk funksionon për tjetrin.
Prandaj, të gjitha proceset e nisjes dhe funksionimit të blokçainëve duhet të organizohen në mënyrë që çdo validues, ose madje një grup i vogël validuesish, të mund ta heqin kompjuterin e tyre në çdo moment, dhe të largohen, pa prishur asgjë dhe validuesit e mbetur duhet të vazhdojnë të mbështesin efektivisht funksionimin e rrjetit dhe të lidhin validues të rinj. Gjatë nisjes së rrjetit, kur një validues është në Evropë, tjetri në Amerikën e Jugut, dhe i treti në Azi, arritja e një funksionimi të koordinuar të disa dhjetëra grupeve të pavarura dhe të angazhuar për rezultatin është mjaft e vështirë.
Validuesit
Le të imagjinojmë nisjen e një blockchain-i modern hipotekar (shumica e përshkruar më sipër i përshtatet blockchain-eve të çdo familjeje moderne si Ethereum, EOS, Polkadot, Cosmos dhe të tjera, të cilat përfshijnë konsensusin proof-of-stake. Aktorët kryesorë të këtyre blockchain-eve janë ekipet e validuesve, të cilët po instalojnë serverë të pavarur dhe që validojnë e prodhojnë blloqe të reja, duke marrë shpërblimet e parashikuara nga rrjeti për ata që marrin pjesë në konsensus. Për të nisur rrjete të reja nevojiten disa dhjetëra validues, (aq sa aktualisht mund të arrijnë më ose më pak efektivisht konsensusin brenda disa sekondash), ndaj projekti shpall regjistrimin, ku validuesit ndajnë informacion të hapur për veten me përdoruesit, duke i bindur ata se kanë për intention të ofrojnë shërbim cilësor për rrjetin që po niset.
Validimi është një biznes që lejon vlerësimin jashtëzakonisht të saktë të të ardhurave potenciale të një validatori, si dhe transferimin e shpejtë të burimeve midis projekteve. Në rast se rrjeti i zgjedhur ka sukses, validatori mund të kontribuojë si një pjesëmarrës i plotë në DAO dhe të zhvillojë projektin si një person përgjegjës, ose thjesht të ofrojë një shërbim teknik të shkëlqyer për para të fituara plotësisht transparencë. Kur llogaritet shpërblimi për validatorët, projektet përpiqen të marrin parasysh shpenzimet e validatorëve dhe të bëjnë shpërblimin për blloqet në mënyrë që ky biznes të jetë fitimprurës, por pa lejuar që validatoret të dëmtojnë ekonominë duke i mbushur ata me para dhe duke privuar përdoruesit e tjerë të rrjetit.
Biznesi i validatorëve kërkon sigurimin e një qëndrueshmërie të lartë të shërbimeve, çka nënkupton një nivel të lartë përgatitjeje për profesionistët e DevOps dhe zhvilluesit, si dhe burime kompjuterike jo të lira. Edhe pa nevojën për të minuar hash-e në rrjete me proof-of-work, një nod blockchain është një shërbim i madh që zë shumë memorie, konsumon shumë llogaritje, validon, regjistron në disk dhe transmeton në rrjet sasi të mëdha të të dhënave. Për të ruajtur log-un e transaksioneve dhe zinxhirët e bllokave për një blockchain me disa mijëra transaksione të vogla në bllok, tani kërkohet ruajtje prej mbi 50 Gb, dhe për blloqe duhet të jetë SSD. Databaza shtetërore e blockchain-eve me mbështetje për kontrata inteligjente mund të kalojë tashmë 64Gb RAM. Serverët me karakteristikat e kërkuara janë mjaft të shtrenjtë; një nod Ethereum ose EOS mund të kushtojë nga 100 deri në 200 $/muaj. Shtoni kësaj pagat e rritura për punën e zhvilluesve dhe DevOps-it në gatishmëri 24 orë, të cilët gjatë lançimit zgjidhin probleme edhe natën, pasi një pjesë e validatorëve mund të jetë lehtësisht në hemisferën tjetër. Megjithatë, në momente të favorshme, posedimi i një nodi-validatori mund të sjellë fitime të konsiderueshme (në rastin e EOS, deri në 10 000$ në ditë).
Vlerësimi është vetëm një nga rolet e reja të mundshme IT për sipërmarrësit dhe kompanitë. Me kalimin e kohës, programuesit po krijojnë algoritmo më komplekse që shpërblejnë ndershmërinë dhe ndëshkojnë mashtrimin dhe vjedhjen. Kështu, po shfaqen shërbime që kryejnë funksione si publikimi i të dhënave të rëndësishme (orakuj), që mbikëqyrin (shkurtimi i depozitave dhe ndëshkimi i mashtruesve përmes publikimit të provave të mashtrimit), shërbime të zgjidhjes së mosmarrëveshjeve, sigurimeve dhe opsioneve. Edhe mbledhja e mbetjeve paraqet një treg të madh potencial në sistemet e kontratave të mençura, ku është e nevojshme të paguhet për ruajtjen e të dhënave.
Problemet e lançimit të blockchain
Transparenca e blockchain-it, e cila ka mundësuar pjesëmarrjen e lirë në funksionimin e rrjetit të kompjuterëve nga çdo vend dhe thjeshtësia e lidhjes në rrjet për çdo script kiddie sipas udhëzimeve në GitHub nuk është gjithmonë një avantazh. Nxitja për të fituar një token të ri shpesh i detyron validuesit "të minojnë një monedhë të re në fillim", duke shpresuar në rritjen e çmimit dhe mundësinë për të shitur shpejt atë që kanë fituar. Gjithashtu, kjo do të thotë se validuesi juaj mund të jetë kushdo, madje dhe anonim, dhe për të mund të votohet ashtu si për validuesit e tjerë (sigurisht, anonomi do të ketë vështirësi të mbledhë votat e aksionarëve, kështu që legjendat frikësuese për kriptovalutat anonime do t'i lëmë politikëve). Megjithatë
Ekipa e projektit ka një detyrë - të gjejë në ndonjë mënyrë ata që, në të ardhmen, janë në gjendje të sigurojnë funksionimin e stabilizuar të nodeve, të kenë njohuri mbi sigurinë, të zgjidhin shpejt problemet, të bashkëpunojnë me validues të tjerë dhe të veprojnë së bashku - sepse këto cilësi ndjeshëm ndikojnë në cilësinë e atij tokeni në të cilin planifikojnë të investojnë kohën dhe burimet e tyre pjesëmarrësit e rrjetit. Fondatorët e arsyeshëm, duke e vlerësuar rrezikun, e kuptojnë mirë se, kur lançojnë një softuer të tillë, do të duhet patjetër të përballen me gabime në kod, në konfigurimin e nodëve, dhe se stabiliteti i rrjetit varet nga sa mirë zhvilluesit dhe validuesit do të zgjidhin këto probleme së bashku.
Ekipa është e gatshme të votojë në mainnet për cilindo validues, por do të dëshironim të dinim se për kë, kush është i mirë? Me portofolin më të madh? Momentalisht pothuajse askush nuk e ka atë. Në profilin e ekipet në Linkedin? DevOps të përvojshëm ose ekspertë të sigurisë nuk do t’ju ofrojnë asnjë profil në Linkedin. Nga deklaratat në chat, postimet dhe ndihmën për të tjerët në fazën e përgatitjes? E mira, por është subjektive dhe e pasaktë.
Në një situatë të tillë, mbetet vetëm një gjë — ajo që zgjidh problemet e të gjithëve — një lojë, në të cilën do të mund të zgjidhni validatorët më të mirë, por mbi të gjitha — të testoni qëndrueshmërinë e blockchain-it dhe të kryeni një provë të plotë të luftës në kushte aktive të përdorimit, ndryshimeve në konsensus, shfaqjes dhe korrigjimit të gabimeve. Këtë procedurë e paraqitën për herë të parë si një lojë djemtë e projektit Cosmos, dhe kjo ide padyshim që është një mënyrë e shkëlqyer për të përgatitur rrjetin për fillimin e një mainnet të besueshëm dhe të qëndrueshëm.
Lojë e Validatorëve
Do të përshkruaj lojën e validatorëve ashtu siç e kemi projektuar për blockchain-in DAO.Casino (DAOBet) mbi një fork të EOS-it, i quajtur Haya, i cili ka një mekanizëm të ngjashëm qeverisës — validatorët zgjidhen me vota nga çdo llogari, ku një pjesë e bilancit që votohet për validatorin mbetet e ngrirë. Çdo llogari që ka në bilancin e saj tokenin kryesor BET mund të votojë për validatorin e zgjedhur me çdo pjesë të bilancit të saj. Votat shënohen dhe në bazë të rezultateve ndikohet renditja e validatorëve. Në blockchain të ndryshme, ky proces është organizuar ndryshe, dhe zakonisht në këtë pjesë blockchain-i i ri ndryshon nga prindi, dhe duhet thënë se në rastin tonë, EOS e justifikon plotësisht “OS” në emrin e tij, ne vërtet përdorim EOS si një sistem operativ themelor për të zhvilluar një version të modifikuar të blockchain-it për nevojat e DAOBet.
Do të përshkruaj problemet e veçanta dhe si mund t'i zgjidhim ato brenda lojës. Le të imagjinojmë një rrjet, ku serveri yt mund të sulmohet hapur, ku për të ruajtur pozitat e validuesit duhet të ndërveprosh vazhdimisht me rrjetin, promovoni validuesin tuaj dhe monitoroni që ai të prodhojë blloqe dhe ato të dërgohen në kohë tek validuesit e tjerë; përndryshe, validuesi do të përjashtohet nga lista.
Si të zgjidhni fituesit më të mirë?
Kërkesa kryesore teknike për lojën është që rezultatet e saj të jenë publikisht të verifikueshme. Kjo do të thotë se rezultatet e lojës: fituesit TOP, duhet të formohen strikt mbi bazën e të dhënave që mund t'i verifikojë çdo pjesëmarrës. Në një sistem të centralizuar ne do të mund të masnim 'uptime' e çdo validuesi dhe të shpërblenim ata që ishin më shumë online ose kaluan përmes maksimalit të trafikut të rrjetit. Mund të mblidhen të dhëna për ngarkesën e procesorit, kujtesë dhe të shpërblejmë ata që punuan mirë. Por çdo mbledhje e tillë metrikash do të thotë ekzistencën e një qendre mbledhjeje, për më tepër, nodet janë të pavarura dhe mund të sillen si të duan dhe të dërgojnë çdo lloj të dhëne.
Prandaj, zgjidhja natyrale është që fituesit duhet të përcaktohen nga të dhënat e blockchain-it, pasi nga ai mund të shihet se cili nga validuesit ka prodhuar cilin bllok dhe cilat transaksione janë përfshirë në të. Ne e emërtuam këtë numër Pikët e Validuesve (VP), dhe përvetësimi i tyre është objekti kryesor i validuesve në lojë. Në rastin tonë, metrika më e thjeshtë, e cila mund të verifikohet publikisht lehtë dhe që është efektive për “përdorshmërinë” e validuesit është VP = numri i blloqeve të prodhuara nga validuesi në një periudhë të caktuar kohore.
Ky zgjedhje e thjeshtë është e bazuar në faktin se qeverisja në EOS tashmë parashikon shumë nga problemet që lindin, pasi EOS është trashëgimtar i tre brezave të tashëm të blockchain-eve që funksionojnë me një përvojë të madhe në menaxhimin e komplikuar të rrjetit, dhe, pothuajse çdo problem që ka validuesi me rrjetin, procesorin, apo diskun çon në një problem të vetëm — ai nënshkruan më pak blloqe, merr më pakPagesë për punë, çka na rikthen sërish në numrin e blloqeve të nënshkruara — për EOS ky është një variant i shkëlqyer dhe i thjeshtë.
Në blockchain të tjerë, mënyra e llogaritjes së Pikave të Validuesve mund të ndryshojë, për shembull, për konsensuset e bazuara në pBFT (Tendermint/Cosmos, konsensusi Aura nga Parity Substrate), ku çdo bllok duhet të nënshkruhet nga shumë validues, ka kuptim të llogariten nënshkrime të veçanta të validuesve, dhe jo blloqet. Ndoshta ka kuptim të merret parasysh edhe raundet e papërfunduar të konsensusit, të cilat shpenzojnë burime të validuesve të tjerë; në përgjithësi, kjo varet shumë nga lloji i konsensusit.
Si të modeloni kushte reale eksploatimi
Detyra e themeluesve është të kontrollojnë validatoret në kushte që i përshtaten realitetit, ndërsa nuk kanë asnjë kontroll të centralizuar. Ky problem mund të zgjidhet me anë të një kontrate-faucet, e cila shpërndan sasi të barabarta të tokenit kryesor për validatoret dhe të gjithë ata që janë të interesuar. Për të marrë tokenat në bilanc, duhet të formohet një transaksion dhe të arrihet që rrjeti ta përfshijë atë në një bllok. Në këtë mënyrë, validatori duhet të rikthejë vazhdimisht bilancin e tij me tokena të rinj dhe të votojë për veten, duke u promovuar në majë. Kjo aktivitet krijon një ngarkesë të vazhdueshme në rrjet, dhe parametrat mund të përshtaten në mënyrë që fluksi i kërkesave të jetë mjaft serioz për një test të plotë të rrjetit. Prandaj, planifikoni kontratën-faucet paraprakisht, si një mjet të rëndësishëm për nisjen e rrjetit dhe filloni të përshtatni parametrat e saj paraprakisht.
Kërkesa për tokene nga faucet dhe votimi i validatoreve nuk simulon plotësisht funksionimin e BÇ, veçanërisht në modet e ngarkesës së lartë. Prandaj, ekipi i blockchain-it do të duhet, në një mënyrë ose në një tjetër, të shkruajë benchmark të shtuar që lejojnë ngarkimin e rrjetit. Një rol të veçantë në këtë e luajnë smart-kontratet e krijuara më parë, që lejojnë testimin e një nën-sistemi të veçantë. Për testimin e storage, kontrata ruan të dhëna të rastit në blockchain, ndërsa për verifikimin e burimeve të rrjetit, kontrata testuese kërkon një sasi të madhe të dhënash hyrëse, duke e rritur kështu volumin e transaksioneve — duke nisur një fluks të tillë transaksionesh në momente të rastësishme, ekipi teston njëkohësisht stabilitetin e kodit dhe qëndrueshmërinë e validatoreve.
Një çështje e veçantë është përditësimi i kodit të node-ve dhe zhvillimi i hard fork-ëve. Nevojitet që, në rast shfaqjeje të një gabimi, vulnerabiliteti, ose një aleance të keqe validatorësh, validatorët të kenë një plan veprimi, të cilin e kanë provuar tashmë në lojë. Këtu mund të shpiken skema për dhënien e VP për aplikimin e shpejtë të hard fork-ut, për shembull, duke dënua të gjithë validatorët që ende nuk e kanë ndjekur versionin e ri të kodit të node-ve, por kjo është e vështirë për t'u zbatuar dhe e komplikon llogaritjen. Simulimi i situatës së zbatuar urgjent të hard fork-ut mund të bëhet artificialisht duke 'thyer' bllokunçajn në një bllok të caktuar. Prodhimi i blloqeve ndalet, dhe përfundimisht në fitim do të jenë ata që aktivizohen më herët dhe fillojnë të nënshkruajnë blloqet, kështu që VP mbi bazën e numrit të blloqeve të nënshkruara është e përshtatshme këtu.
Si t'i informojmë pjesëmarrësit mbi gjendjen e rrjetit dhe të rregullojmë gabimet
Megjithëse ka mosbesim midis validuesve, marrja e informacionit aktual në kohë për gjendjen e rrjetit është e dobishme për të gjithë, për të marrë vendime më shpejt. Prandaj, ekipi i projektit ngrit një shërbim për mbledhjen dhe vizualizimin e një sërë metrikash nga serverat e validuesve, i cili lejon shikimin e situatës për të gjithë rrjetin, duke mundësuar përcaktimin e shpejtë të asaj që po ndodh. Gjithashtu, si për validuesit ashtu edhe për projektin është e rëndësishme që ekipi i projektit të korrigjojë shpejt gabimet e gjetura, prandaj, përveç mbledhjes së metrikave, ka kuptim të nisni menjëherë mbledhjen e logjeve dhe të dhënave për gabimet nga makinat e validuesve në një makinë, e cila do të jetë e qasshme për zhvilluesit e blokçain. Askush nuk ka dobi nga keqformimi i informacionit, prandaj këto shërbime krijohen nga ekipi i projektit dhe ato mund të besohen. Ka kuptim të mbledhim metrika sistemike nga validuesit, dhe, patjetër, metrikat më të rëndësishme të vetë blokçain — për DAOBet — këto janë koha e finalizimit dhe vonesa e bllokut më të fundit të finalizuar. Falë kësaj, ekipi sheh rritjen e konsumit të memories në nodet gjatë ekzekutimit të benchmark-ut dhe problemet e validuesve të veçantë.
Pikat e rëndësishme për zhvillimin e lojës së validuesve
Siç duket, nëse dëshironi të lejoni zyrtarisht validuesit të sulmojnë makinat e njëri-tjetrit (ndryshe ata mund ta bëjnë këtë pa zyrtarizim) — është e nevojshme ta formuloni këtë veçmas si testim të sigurisë, pasi sipas legjislacionit të disa vendeve, sulmet DDoS ose të tjera mund të dënohen. Një pyetje tjetër e rëndësishme është se si të shpërblehen validuesit. Çmimet natyrale janë tokenat e projektit që do të transferohen në mainnet, por shpërndarja masive e tokenave për çdo person që mund të aktivizojë një nodë — gjithashtu nuk është ide e mirë. Me siguri do t'ju duhet të balanconi midis dy skenarëve ekstreme:
Shpërndani të gjithë fondin e çmimeve në përputhje me VP-të e fituara
kjo është shumë demokratike dhe lejon të fitojnë të gjithë ata që kanë investuar kohë dhe burime në lojën e validuesve
por tërheq në lojë njerëz të rastësishëm pa infrastrukturë të përgatitur
Shpërndani fondin e çmimeve top-N validuesve sipas rezultateve të lojës
fituesit do të jenë me siguri validuesit që kanë qëndruar më stabil gjatë lojës, të përkushtuar shumë seriozisht për fitoren
disa e validuesve nuk do të dojë të marrë pjesë, duke e vlerësuar ulur mundësinë e fitimit, sidomos nëse në radhët e pjesëmarrësve ka validues të njohur.
Cilin variant të preferoni — është çështje e juaja.
Ka edhe një aspekt tjetër — nuk është aspak i sigurt që dhjetëra validues do të hidhen në lojë në thirrjen tuaj, dhe nga ata që vendosin të provojnë, të gjithë nuk do të instalojnë dhe nisin nodën — zakonisht, në këtë fazë projektet kanë dokumentacion mjaft të skuqur, ndodhin gabime, dhe zhvilluesit që punojnë nën presion nuk përgjigjen shumë shpejt. Prandaj, para fillimit të lojës duhet gjithashtu të parashikoni veprimet nëse numri i nevojshëm i validuesve nuk arrihet. Në këtë rast, në fillim të lojës, validuesit që mungojnë do të nisen nga ekipi i projektit, do të marrin pjesë në konsensus, por nuk mund të jenë fitues.
Përfundimi
Në përfundim, përpiqesha të mbledh nga përshkrimi i mësipërm një listë të asaj që duhet të shpikim, bëjmë dhe nisnim për zhvillimin efektiv të lojës së validuesve.
Çfarë duhet të bëhet për të filluar një lojë reale validuesish:
të zhvillohet blockchain-i juaj🙂
- të krijosh dhe ngresh një ndërfaqe web dhe të ofrosh CLI për votimin për validuesit
- të bësh në mënyrë që metrikat nga nodi validues i instaluar të mund të dërgohen në një shërbim të centralizuar (p.sh. Prometheus)
- të ngresh një server për mbledhjen e metrikave (Prometheus + Grafana) për lojën e validuesve
- të mendosh se si do të llogariten Pikët e Validuesit (VP)
- të zhvillosh një skript publik që llogarit VP të validuesve në bazë të të dhënave nga blockchain
- të zhvillosh një ndërfaqe web për të treguar top-in e validuesve dhe gjendjen e lojës së validuesve (sa kohë ka mbetur deri në fund, sa VP ka kush etj.)
- të zhvillosh dhe automatizosh fillimin e një numri të caktuar nodash, të dizajnosh procesin e lidhjes së validuesve me lojën (kur dhe si të çaktivizosh nodat e tua, si të ndash dhe heqësh vota për to)
- të llogaritësh se sa duhet të jepen tokene dhe të zhvillosh kontratën-faucet
- të krijosh një skript benchmark (transferet e tokenëve, përdorimi i madh i storage, përdorimi masiv i rrjetit)
- të mbledhësh të gjithë pjesëmarrësit në një bisedë për komunikim të shpejtë
- të nisësh blockchain-in pak më parë se fillimi i lojës
- të presësh bllokun fillestar, të fillosh lojën
- testoni rrjetin me disa lloje transaksionesh
- implementoni hard fork
- ndryshoni listën e validuesve
- përsëritni pikat 13, 14, 15 në rend të ndryshëm, duke ruajtur stabilitetin e rrjetit
- pritni bllokun përfundimtar, përfundoni lojën, numëroni VP
Duhet thënë se loja e validuesve është një histori e re dhe është zhvilluar vetëm disa herë, prandaj nuk duhet ta merrni këtë tekst si një udhëzues të gatshëm. Nuk ka asnjë analog në biznesin modern të IT - imagjinoni se bankat para se të lançojnë sistemin e pagesave konkurrojnë me njëra-tjetrën për të parë se kush do të realizojë më mirë transaksionet e klientëve. Qasjet tradicionale me siguri nuk do t'ju ndihmojnë të krijoni rrjete të mëdha të decentralizuara, prandaj mësoni modele të reja biznesi, organizoni lojërat tuaja, identifikoni të denjët, shpërbleni ata dhe lejoni që sistemet tuaja të shpërndara të punojnë shpejt dhe stabilisht.
Burimi: habr.com
