So, jou span het die alfa-weergawe van jou blokketting voltooi, en dit is tyd om testnet en dan mainnet te begin. Jy het 'n regte blokketting, met onafhanklike deelnemers, 'n goeie ekonomiese model, sekuriteit, jy het bestuur ontwerp en nou is dit tyd om dit alles in aksie te probeer. In 'n ideale kripto-anargiese wêreld plaas jy 'n ontstaansblok op die netwerk, die finale kode van die nodus en valideerders begin alles self, verhoog al die hulpdienste, en alles gebeur vanself. Maar dit is in 'n fiktiewe wêreld, maar in die regte wêreld moet die span heelwat hulpprogrammatuur en verskeie manipulasies voorberei om valideerders te help om 'n stabiele netwerk te begin. Dit is waaroor hierdie artikel gaan.
Die bekendstelling van netwerke gebaseer op "bewys-van-spel" tipe konsensusse, waar valideerders bepaal word deur die stemme van stelseltokenhouers, is 'n taamlik spesifieke gebeurtenis, want selfs die bekendstelling van tradisionele, sentraal bestuurde stelsels met tien en honderde bedieners is nie 'n maklike taak op sigself, en die blokketting moet begin word met moeite lojale maar onafhanklike deelnemers. En as administrateurs in 'n korporasie by opstart volle toegang tot alle masjiene, logboeke, algemene monitering het, sal valideerders niemand toelaat om toegang tot hul bedieners te kry nie en sal waarskynlik verkies om hul infrastruktuur onafhanklik te bou, want dit beheer toegang tot die belangrikste bates van die valideerder - stakes kiesers. Dit is hierdie gedrag wat dit moontlik maak om verspreide veilige netwerke te bou - die onafhanklikheid van die wolkverskaffers wat gebruik word, virtuele en "baremetal" bedieners, verskillende bedryfstelsels, dit alles laat jou toe om aanvalle op so 'n netwerk uiters ondoeltreffend te maak - te veel anders sagteware gebruik word. Byvoorbeeld, Ethereum gebruik twee hoofnodusimplementerings, in Go en in Rust, en 'n aanval wat effektief is vir een implementering, werk nie vir die ander nie.
Daarom moet alle prosesse vir die bekendstelling en bedryf van blokkettings so georganiseer word dat enige valideerder, of selfs 'n klein groepie valideerders, te eniger tyd hul rekenaars by die venster kan uitgooi en vertrek, terwyl niks moet breek nie en die oorblywende valideerders moet gaan voort om die bedryfsnetwerk effektief te ondersteun en nuwe valideerders aan te sluit. Wanneer 'n netwerk bekendgestel word, wanneer een valideerder in Europa is, die tweede in Suid-Amerika en die derde in Asië, is dit nogal moeilik om die gekoördineerde werk van 'n paar dosyn onafhanklike groepe te bereik en hulle as gevolg daarvan te interesseer.
Valideerders
Kom ons stel ons die bekendstelling van 'n hipotetiese moderne blokketting voor (die meeste van wat beskryf word, is geskik vir blokkettings gebaseer op enige moderne familie blokkettings: Ethereum, EOS, Polkadot, Cosmos en ander, wat bewys-van-spel konsensus bied. Die hoofkarakters van sulke blokkettings is valideerderspanne wat besig is met die installering van hul eie onafhanklike bedieners wat nuwe blokke valideer en produseer, en ontvang belonings wat deur die netwerk verskaf word vir diegene wat aan die konsensus deelneem. Om nuwe netwerke te begin, word 'n paar dosyn valideerders vereis (so baie kan nou min of meer effektief konsensus in sekondes bereik), daarom kondig die projek registrasie aan, waarin valideerders publieke inligting oor hulself met gebruikers deel, wat hulle oortuig dat hulle diens van hoë gehalte aan die geloodsde netwerk gaan lewer.
Validasie is 'n besigheid wat jou toelaat om die valideerder se potensiële inkomste uiters akkuraat te evalueer, vinnig krag tussen projekte oor te dra, en as die netwerk wat hy gekies het suksesvol is, kan die valideerder as 'n volwaardige deelnemer aan die DAO en 'n verantwoordelike persoon, ontwikkel die projek, of verskaf bloot uitstekende tegniese diens vir heeltemal deursigtige, eerlik verdiende geld. Wanneer die beloning vir valideerders bereken word, probeer projekte om die koste van valideerders in ag te neem en die beloning vir blokke sodanig te maak dat hierdie besigheid winsgewend is, maar laat terselfdertyd nie toe dat valideerders die ekonomie tot 'n val bring deur hulle met geld te oorstroom en ander netwerkgebruikers daarvan te ontneem.
Die besigheid van valideerders vereis om hoë fouttoleransie van dienste te verseker, wat 'n hoë vlak van opleiding vir devops en ontwikkelaars en duur rekenaarhulpbronne beteken. Selfs sonder dat dit nodig is om hashes in bewys-van-werk-netwerke te myn, is 'n blokkettingnodus 'n groot diens wat baie geheue opneem, baie berekeninge verbruik, bekragtig, na skyf skryf en groot hoeveelhede data na die netwerk stuur . Om transaksielogboeke en blokkettings vir 'n blokketting met 'n paar duisend klein transaksies in 'n blok te stoor, word berging van 50 Gb of meer nou vereis, en vir blokke moet dit 'n SSD wees. Staatsdatabasis van blokkettings met ondersteuning vir slim kontrakte kan reeds 64 Gb RAM oorskry. Bedieners met die vereiste eienskappe is redelik duur; 'n Ethereum- of EOS-knooppunt kan van 100 tot 200 $/maand kos. Voeg hierby die verhoogde lone vir die 10-uur-werk van ontwikkelaars en devops, wat gedurende die bekendstellingsperiode probleme selfs snags oplos, aangesien sommige valideerders maklik in 'n ander halfrond geleë kan wees. Op die regte oomblikke kan die besit van 'n valideerderknoop egter ernstige inkomste meebring (in die geval van EOS, tot $000 XNUMX per dag).
Validasie is net een van die nuwe potensiële IT-rolle vir entrepreneurs en maatskappye; namate programmeerders met meer en meer gesofistikeerde algoritmes vorendag kom wat eerlikheid beloon en bedrog en diefstal straf, verskyn dienste wat die funksies verrig om belangrike data (orakels) te publiseer, toesig te verrig. (deposito sny en straf cheaters deur bewys van misleiding te publiseer), dispuutoplossingsdienste, versekering en opsies, selfs vullisverwydering is 'n potensieel groot mark in slim kontrakstelsels waar dit nodig is om vir databerging te betaal.
Probleme om 'n blokketting te begin
Die openheid van die blokketting, wat dit vir rekenaars van enige land moontlik gemaak het om vrylik aan die netwerk deel te neem en die gemak om enige script kiddie aan die netwerk te koppel volgens instruksies op GitHub, is nie altyd 'n voordeel nie. Die strewe na 'n nuwe teken dwing dikwels valideerders om "aan die begin 'n nuwe munt te ontgin", in die hoop dat die koers sal styg en die geleentheid om vinnig hul verdienste af te gooi. Dit beteken ook dat jou valideerder enigiemand kan wees, selfs 'n anonieme persoon, jy kan vir hom stem op dieselfde manier as vir ander valideerders (dit sal egter moeilik wees vir 'n anonieme persoon om belanghebbende stemme vir homself in te samel, so ons' sal die skrikwekkende verhale oor anonieme kripto-geldeenhede aan politici oorlaat). Nietemin
Die projekspan het 'n taak - om op een of ander manier in sy netwerk te kom diegene wat in die toekoms die stabiele werking van nodusse kan verseker, sekuriteit verstaan, weet hoe om probleme vinnig op te los, met ander valideerders saam te werk en saam op te tree - die kwaliteit daarvan Die ding hang heeltemal af van hierdie eienskappe, 'n teken waarin netwerkdeelnemers hul tyd en hulpbronne gaan belê. Genoegsame stigters, wanneer die risiko's beoordeel word, verstaan goed dat wanneer u sagteware van hierdie grootte bekendstel, u beslis foute in die kode en konfigurasie van nodusse sal moet ondervind, en dat die stabiliteit van die netwerk afhang van hoe goed ontwikkelaars en valideerders gesamentlik sal oplos sulke probleme.
Die span is gereed om op die hoofnet te stem vir enige valideerders, net om te weet watter, watter is goed? Die grootste portefeulje? Byna niemand het dit nou nie. Gebaseer op die span se Linkedin-profiele? Ervare devops of sekuriteitspesialiste sal jou geen Linkedin-profiele gee nie. Volgens stellings in klets, plasings en om ander te help tydens die voorbereidingsfase? Goed, maar subjektief en onakkuraat.
In sulke toestande bly een ding oor - iets wat almal se probleme goed oplos - 'n speletjie waarin dit moontlik sal wees om die beste valideerders te kies, maar die belangrikste ding is om die blokketting vir krag te toets en 'n volskaalse gevegstoets van die blokketting in toestande van aktiewe gebruik, veranderinge in konsensus, voorkoms en regstelling van foute. Hierdie prosedure is die eerste keer as 'n speletjie aangebied deur die ouens van die Cosmos-projek, en hierdie idee is ongetwyfeld 'n uitstekende manier om die netwerk voor te berei vir die bekendstelling van 'n betroubare en foutverdraagsame hoofnet
Game of Validators
Ek sal die spel van valideerders beskryf soos ons dit ontwerp het vir die DAO.Casino (DAOBet) blokketting gebaseer op die EOS vurk, wat Haya genoem word en 'n soortgelyke bestuursmeganisme het - valideerders word gekies deur uit enige rekening te stem, in watter deel van die balans wat gebruik word om vir die valideerder te stem, word gevries. Enige rekening wat die hoof BET-token op sy saldo het, kan vir die geselekteerde valideerder stem met enige deel van sy saldo. Die stemme word opgesom en die top valideerders word gebou op grond van die resultate. In verskillende blokkettings is hierdie proses anders georganiseer, en gewoonlik is dit in hierdie deel dat die nuwe blokketting van die ouer een verskil, en ek moet sê dat in ons geval, EOS die "OS" in sy naam ten volle regverdig, ons gebruik regtig EOS as die basisbedryfstelsel vir die implementering van 'n gewysigde weergawe van die blokketting vir DAOBet-take.
Ek sal individuele probleme beskryf en hoe dit binne die spel opgelos kan word. Kom ons stel ons 'n netwerk voor waarin u bediener openlik aangeval kan word, waar u, om die posisie van 'n valideerder te behou, voortdurend met die netwerk moet kommunikeer, u valideerder moet bevorder en seker maak dat dit blokke produseer en dit aan ander valideerders afgelewer word op tyd, anders sal die valideerder uit die lys gegooi word.
Hoe om topwenners te kies?
Die belangrikste tegniese vereiste vir die speletjie is dat die resultate daarvan in die openbaar verifieerbaar moet wees. Dit beteken dat die resultate van die spel: TOP-wenners, streng gevorm moet word op grond van data wat deur enige deelnemer geverifieer kan word. In 'n gesentraliseerde stelsel kan ons die "uptyd" van elke valideerder meet en diegene beloon wat die meeste aanlyn was of deur die maksimum netwerkverkeer gegaan het. Jy kan data oor verwerker en geheuelading insamel en diegene beloon wat goed gewerk het. Maar enige so 'n versameling van metrieke beteken die bestaan van 'n versameling sentrum, en die nodusse is almal onafhanklik en kan optree soos hulle wil en enige data stuur.
Daarom is die natuurlike oplossing dat die wenners op grond van data van die blokketting bepaal moet word, aangesien dit gebruik kan word om te sien watter valideerder watter blok vervaardig het en watter transaksies daarby ingesluit is. Ons het hierdie nommer Validator Points (VP) genoem, en om dit te verdien is die hoofdoel van valideerders in die spel. In ons geval is die eenvoudigste, maklik publiek verifieerbare en effektiewe maatstaf van 'n valideerder se "nut" VP = aantal blokke wat deur die valideerder in 'n gegewe tydperk geproduseer word.
Hierdie eenvoudige keuse is te danke aan die feit dat bestuur in EOS reeds voorsiening maak vir baie opkomende probleme, aangesien EOS die erfgenaam is van drie generasies van werklik werkende blokkettings met uitgebreide ervaring in komplekse netwerkbestuur, en byna enige valideerderprobleme met die netwerk, verwerker, skyf lei tot net een probleem - hy teken minder blokke, ontvang minder betaling vir die werk, wat ons weer eenvoudig na die aantal ondertekende blokke lei - vir EOS is dit 'n uitstekende en eenvoudige opsie.
Vir ander blokkettings kan die manier waarop Validator Points bereken word verskil, byvoorbeeld vir pBFT-gebaseerde konsensusse (Tendermint/Cosmos, Aura consensus from Parity Substrate), waar elke blok deur verskeie valideerders onderteken moet word, maak dit sin om individuele valideerder te tel handtekeninge eerder as blokke Dit kan sin maak om onvolledige konsensusrondtes in ag te neem, wat die hulpbronne van ander valideerders mors, in die algemeen hang dit baie af van die tipe konsensus.
Hoe om werklike bedryfstoestande te simuleer
Die stigters se taak is om valideerders te toets onder toestande naby aan die werklikheid, sonder om enige gesentraliseerde beheer te hê. Hierdie probleem kan opgelos word deur 'n kraankontrak te gebruik, wat gelyke hoeveelhede van die hooftoken aan valideerders en almal anders versprei. Om tokens op jou saldo te ontvang, moet jy 'n transaksie skep en verseker dat die netwerk dit in die blok insluit. Dus, om te wen, moet 'n valideerder voortdurend sy balans aanvul met nuwe tekens en vir homself stem, om homself na bo te bevorder. Hierdie aktiwiteit skep 'n konstante las op die netwerk, en die parameters kan so gekies word dat die vloei van versoeke ernstig genoeg is vir 'n volledige netwerktoets. Beplan dus die kraankontrak vooraf as 'n belangrike hulpmiddel om die netwerk te begin en begin vooraf sy parameters kies.
Om tekens van 'n kraan te versoek en stemme te bekragtig, boots steeds nie die werking van 'n plofkop ten volle na nie, veral in uiters gelaaide modusse. Daarom sal die blokkettingspan steeds op een of ander manier bykomende maatstawwe moet skryf om die netwerk te laai. 'n Spesiale rol hierin word gespeel deur spesiaal geskep slim kontrakte wat die toetsing van 'n aparte substelsel moontlik maak. Om berging te toets, stoor die kontrak ewekansige data in die blokketting, en om netwerkhulpbronne te toets, vereis die toetskontrak 'n groot hoeveelheid insetdata, waardeur die volume transaksies opgeblaas word - deur 'n vloei van sulke transaksies op arbitrêre tydstip te begin, die span toets terselfdertyd die stabiliteit van die kode en die sterkte van die valideerders.
'n Afsonderlike probleem is die opdatering van die kode van nodusse en die uitvoer van harde vurke. Dit word vereis dat in die geval van 'n fout, kwesbaarheid of samespanning van kwaadwillige valideerders, valideerders 'n aksieplan moet hê wat reeds in die valideerders se spel uitgewerk is. Hier kan jy vorendag kom met skemas vir die aanwas van VP vir vinnige toepassing van 'n harde vurk, byvoorbeeld, deur alle valideerders te beboet wat nog nie 'n nuwe weergawe van die noduskode uitgerol het nie, maar dit is moeilik om te implementeer en bemoeilik die berekening. U kan die situasie van 'n noodgebruik van 'n harde vurk simuleer deur die blokketting op 'n gegewe blok kunsmatig te "breek". Blokproduksie stop, en op die ou end sal die wenners diegene wees wat eerste inspring en blokke begin teken, so VP gebaseer op die aantal ondertekende blokke pas goed hier.
Hoe om deelnemers in te lig oor die netwerkstatus en foute reg te stel
Ten spyte van die wantroue tussen valideerders, is tydige ontvangs van bygewerkte inligting oor die toestand van die netwerk voordelig vir almal om vinniger besluite te neem, so die projekspan is besig om 'n diens in te samel vir die insameling en visualisering van baie statistieke vanaf validator-bedieners, wat jou toelaat om die situasie gelyktydig vir die hele netwerk te sien, sodat jy vinnig kan bepaal wat gebeur. Dit is ook voordelig vir beide die valideerders en die projek dat die projekspan die foute wat gevind word vinnig regstel, so benewens die insameling van statistieke, maak dit sin om dadelik logs en foutdata van valideerders se masjiene te begin versamel op 'n masjien wat toeganklik is vir blockchain ontwikkelaars. Hier is dit vir niemand voordelig om inligting te verdraai nie, so hierdie dienste word deur die projekspan ontwikkel en kan vertrou word. Dit maak sin om stelselstatistieke van valideerders in te samel, en natuurlik is die belangrikste maatstawwe van die blokketting self - vir DAOBet - die finaliseringstyd en die vertraging van die laaste gefinaliseerde blok. Danksy dit sien die span 'n toename in geheueverbruik op nodusse wanneer die maatstaf uitgevoer word, probleme met individuele valideerders
Belangrike punte vir die uitvoer van 'n validator-speletjie
Soos dit blyk, as jy amptelik wil toelaat dat valideerders mekaar se masjiene aanval (nie-amptelik kan hulle dit in elk geval doen), moet jy dit wettiglik apart formuleer as sekuriteitstoetsing, aangesien DDoS of netwerkaanvalle onder die wette van sommige lande kan wees. gestraf. Nog 'n belangrike kwessie is hoe om valideerders te beloon. Natuurlike pryse is projektokens, wat na die hoofnet oorgedra sal word, maar 'n massiewe verspreiding van tokens aan enigiemand wat 'n nodus kon begin is ook nie die beste opsie nie. Heel waarskynlik sal jy tussen twee uiterste opsies moet balanseer:
Verdeel die hele pryspoel volgens die VP wat verdien is
dit is baie demokraties en laat almal toe wat tyd en hulpbronne in die validator-speletjie belê het om geld te verdien
maar lok willekeurige mense na die spel sonder voorbereide infrastruktuur
Versprei die top-N-pryspoel aan valideerders gebaseer op die resultate van die speletjie
Die wenners sal heel waarskynlik die valideerders wees wat die meeste konsekwent gedurende die wedstryd geduur het en baie streng vasbeslote is om te wen
sommige valideerders sal nie wil deelneem nie, en hulle beoordeel hul kanse om te wen min, veral as die deelnemers eerbiedwaardige valideerders insluit
Watter opsie om te kies is aan jou
Daar is nog 'n punt - dit is glad nie 'n feit dat dosyne valideerders sal jaag om aan die speletjie deel te neem op jou oproep nie, en van diegene wat besluit om te probeer, sal nie almal eens die nodus installeer en begin nie - gewoonlik, op hierdie stadium het projekte taamlik yl dokumentasie, word foute teëgekom en ontwikkelaars wat onder tydsdruk werk, beantwoord nie vrae baie vinnig nie. Daarom, voordat die speletjie begin word, is dit ook nodig om voorsiening te maak vir aksies as die vereiste aantal valideerders nie bereik word nie. In hierdie geval, aan die begin van die speletjie, word die ontbrekende valideerders deur die projekspan geloods, neem deel aan konsensus, maar kan nie wenners wees nie.
Gevolgtrekking
Ten slotte het ek probeer om uit die bogenoemde 'n lys saam te stel van wat bedink, gemaak en bekendgestel moet word om 'n validator-speletjie effektief uit te voer
Wat jy moet doen om 'n regte validator-speletjie uit te voer:
ontwikkel jou eie blockchain :)
- maak en verhoog 'n webkoppelvlak en verskaf 'n CLI om vir valideerders te stem
- maak seker dat metrieke vanaf 'n lopende valideerdernodus na 'n gesentraliseerde diens gestuur kan word (byvoorbeeld Prometheus)
- verhoog 'n bediener vir die versameling van statistieke (Prometheus + Grafana) vir die valideerderspeletjie
- uit te vind hoe Validator Points (VP) bereken sal word
- ontwikkel 'n publieke skrif wat validator VP bereken op grond van data van die blockchain
- ontwikkel 'n webkoppelvlak om die top-valideerders te vertoon, en die spelstatus van die valideerders (hoeveel tyd is daar oor tot die einde, wie het hoeveel VP, ens.)
- ontwikkel en outomatiseer die bekendstelling van 'n arbitrêre aantal van jou eie nodusse, ontwerp die proses om valideerders aan die speletjie te koppel (wanneer en hoe om jou nodusse te ontkoppel, dien in en verwyder stemme daarvoor)
- bereken hoeveel tokens uitgereik moet word en ontwikkel 'n kraankontrak
- maak 'n maatstafskrif (tekenoordragte, massiewe berginggebruik, massiewe netwerkgebruik)
- versamel alle deelnemers in een klets vir vinnige kommunikasie
- begin die blokketting 'n bietjie vroeër as die begin van die speletjie
- wag vir die beginblok, begin die speletjie
- toets die netwerk met verskeie tipes transaksies
- rol 'n harde vurk uit
- verander die lys van valideerders
- herhaal stappe 13,14,15, XNUMX, XNUMX in verskillende volgordes, en behou netwerkstabiliteit
- wag vir die laaste blok, eindig die wedstryd, tel VP
Daar moet gesê word dat die spel van valideerders 'n nuwe storie is, en dit is slegs 'n paar keer uitgevoer, so jy moet nie hierdie teks as 'n klaargemaakte gids neem nie. Daar is geen analoë in die moderne IT-besigheid nie - stel jou voor dat banke, voordat hulle 'n betaalstelsel bekendstel, met mekaar meeding om te sien wie die beste sal wees om kliëntetransaksies uit te voer. Dit is onwaarskynlik dat tradisionele benaderings jou sal help om groot gedesentraliseerde netwerke te skep, so bemeester nuwe sakemodelle, bestuur jou speletjies, identifiseer die waardiges, beloon hulle en hou jou verspreide stelsels vinnig en stabiel aan die gang.
Bron: will.com