Så dit team har afsluttet alfaversionen af din blockchain, og det er tid til at starte testnet og derefter mainnet. Du har en rigtig blockchain, med uafhængige deltagere, en god økonomisk model, sikkerhed, du har designet governance, og nu er det tid til at prøve alt dette i aktion. I en ideel kryptoanarkisk verden sætter du genesis-blokken på netværket, den endelige kode for noden og validatorerne starter selv alt, hæver alle hjælpetjenester, og alt sker af sig selv. Men dette er i en fiktiv verden, men i den virkelige verden skal holdet forberede en hel del hjælpesoftware og forskellige manipulationer for at hjælpe validatorer med at starte et stabilt netværk. Det er, hvad denne artikel handler om.
Lancering af netværk baseret på "proof-of-stake" type konsensus, hvor validatorer bestemmes af stemmerne fra systemtoken-indehavere, er en ret specifik begivenhed, fordi det ikke er let at lancere traditionelle, centralt administrerede systemer med snesevis og hundredvis af servere. opgave i sig selv, og blockchain skal startes med indsats loyale, men uafhængige deltagere. Og hvis administratorer i en virksomhed ved opstart har fuld adgang til alle maskiner, logfiler, generel overvågning, så vil validatorer ikke tillade nogen at få adgang til deres servere og vil højst sandsynligt foretrække at bygge deres infrastruktur uafhængigt, fordi det styrer adgangen til validatorens hovedaktiver - satser vælgere. Det er denne adfærd, der gør det muligt at bygge distribuerede sikre netværk - uafhængigheden af de anvendte cloud-udbydere, virtuelle og "baremetal" servere, forskellige operativsystemer, alt dette giver dig mulighed for at gøre angreb på et sådant netværk ekstremt ineffektive - for meget anderledes software bruges. For eksempel bruger Ethereum to hovedknudeimplementeringer, i Go og i Rust, og et angreb, der er effektivt for den ene implementering, virker ikke for den anden.
Derfor skal alle processer til lancering og drift af blockchains organiseres på en sådan måde, at enhver validator, eller endda en lille gruppe af validatorer, til enhver tid kan smide deres computere ud af vinduet og gå, mens intet bør gå i stykker, og de resterende validatorer bør fortsætte med effektivt at understøtte driftsnetværket og forbinde nye validatorer. Når man lancerer et netværk, når en validator er i Europa, den anden i Sydamerika og den tredje i Asien, er det ret svært at opnå det koordinerede arbejde fra flere dusin uafhængige grupper og interessere dem som et resultat.
Validatorer
Lad os forestille os lanceringen af en hypotetisk moderne blockchain (det meste af det, der er beskrevet, er velegnet til blockchains baseret på enhver moderne familie af blockchains: Ethereum, EOS, Polkadot, Cosmos og andre, som giver proof-of-stake konsensus. Hovedpersonerne i sådanne blockchains er valideringsteams, der er engageret i at installere deres egne uafhængige servere, der validerer og producerer nye blokke, og modtager belønninger fra netværket til dem, der deltager i konsensus. For at lancere nye netværk kræves der flere dusin validatorer (så mange kan nu mere eller mindre effektivt nå til konsensus på få sekunder), så projektet annoncerer registrering, hvor validatorer deler offentlig information om sig selv med brugerne og overbeviser dem om, at de vil levere service af høj kvalitet til det lancerede netværk.
Validering er en virksomhed, der giver dig mulighed for ekstremt præcist at vurdere validatorens potentielle indkomst, hurtigt overføre magt mellem projekter, og hvis det netværk, han har valgt, lykkes, kan validatoren som fuldgyldig deltager i DAO og ansvarlig person, udvikle projektet, eller blot levere fremragende teknisk service for fuldstændig gennemsigtige, ærligt tjente penge. Når de beregner belønningen for validatorer, forsøger projekter at tage højde for omkostningerne ved validatorer og gøre belønningen for blokke sådan, at denne forretning er rentabel, men tillader samtidig ikke validatorer at bringe økonomien ned ved at oversvømme dem med penge og fratage andre netværksbrugere det.
Validatorers forretning kræver at sikre høj fejltolerance af tjenester, hvilket betyder et højt uddannelsesniveau for devops og udviklere og dyre computerressourcer. Selv uden behov for at mine hashes i proof-of-work netværk, er en blockchain node en stor tjeneste, der fylder meget hukommelse, bruger mange beregninger, validerer, skriver til disk og sender store mængder data til netværket . For at gemme transaktionslogs og blokkæder til en blockchain med flere tusinde små transaktioner i en blok kræves der nu lagring på 50 Gb eller mere, og for blokke skal det være en SSD. Statsdatabase over blockchains med understøttelse af smarte kontrakter kan allerede overstige 64 Gb RAM. Servere med de nødvendige egenskaber er ret dyre; en Ethereum- eller EOS-node kan koste fra 100 til 200 $/måned. Hertil kommer de øgede lønninger for udviklere og devops, som i løbet af lanceringsperioden løser problemer selv om natten, da nogle validatorer nemt kan placeres på en anden halvkugle. På de rigtige tidspunkter kan det dog give alvorlige indtægter at eje en valideringsnode (i tilfælde af EOS, op til $10 pr. dag).
Validering er blot en af de nye potentielle it-roller for iværksættere og virksomheder; efterhånden som programmører kommer med flere og mere sofistikerede algoritmer, der belønner ærlighed og straffer svindel og tyveri, dukker der tjenester op, der udfører funktionerne med at udgive vigtige data (orakler), udføre supervision (indskudsskæring og straf af snydere ved at offentliggøre bevis for bedrag), tvistløsningstjenester, forsikringer og muligheder, selv affaldsindsamling er et potentielt stort marked inden for smarte kontraktsystemer, hvor det er nødvendigt at betale for datalagring.
Problemer med at lancere en blockchain
Åbenheden i blockchainen, som gjorde det muligt for computere fra ethvert land at frit deltage i netværket og letheden ved at forbinde enhver script-kiddie til netværket i henhold til instruktionerne på GitHub, er ikke altid en fordel. Jagten på et nyt token tvinger ofte validatorer til at "mine en ny mønt i starten", i håbet om, at kursen vil stige og muligheden for hurtigt at smide deres indtjening. Det betyder også, at din validator kan være enhver, selv en anonym person, du kan stemme på ham på samme måde som på andre validatorer (det vil dog være svært for en anonym person at indsamle interessenters stemmer til sig selv, så vi' Jeg vil overlade de skræmmende historier om anonyme kryptovalutaer til politikere). alligevel
Projektteamet har en opgave - på en eller anden måde at få ind i sit netværk dem, der i fremtiden er i stand til at sikre stabil drift af noder, forstår sikkerhed, ved, hvordan man hurtigt løser problemer, samarbejder med andre validatorer og handler sammen - kvaliteten af det meget afhænger helt af disse kvaliteter, et symbol, som netværksdeltagere vil investere deres tid og ressourcer i. Tilstrækkelige grundlæggere, når de vurderer risiciene, forstår godt, at når du lancerer software af denne størrelse, vil du helt sikkert skulle støde på fejl i koden og konfigurationen af noder, og at stabiliteten af netværket afhænger af, hvor godt udviklere og validatorer vil løse i fællesskab. sådanne problemer.
Holdet er klar til at stemme på mainnet for alle validatorer, bare for at vide hvilke, hvilke er gode? Den største portefølje? Næsten ingen har det nu. Baseret på holdets Linkedin-profiler? Erfarne devops eller sikkerhedsspecialister vil ikke give dig nogen Linkedin-profiler. Ifølge udsagn i chat, indlæg og at hjælpe andre i forberedelsesfasen? Godt, men subjektivt og unøjagtigt.
Under sådanne forhold er der én ting tilbage - noget, der løser alles problemer godt - et spil, hvor det vil være muligt at vælge de bedste validatorer, men det vigtigste er at teste blockchain for styrke og udføre en fuldskala kamptest af blockchain i forhold til aktiv brug, ændringer i konsensus, udseende og korrektion af fejl . Denne procedure blev først præsenteret som et spil af fyrene fra Cosmos-projektet, og denne idé er uden tvivl en fremragende måde at forberede netværket på lanceringen af et pålideligt og fejltolerant mainnet
Game of Validators
Jeg vil beskrive spillet med validatorer, som vi designede det til DAO.Casino (DAOBet) blockchain baseret på EOS-gaflen, som hedder Haya og har en lignende styringsmekanisme - validatorer vælges ved at stemme fra enhver konto, hvor en del af saldoen, der blev brugt til at stemme på validatoren, er frosset. Enhver konto, der har det primære BET-token på sin saldo, kan stemme på den valgte validator med en hvilken som helst del af saldoen. Stemmerne opsummeres, og topvalidatorerne bygges ud fra resultaterne. I forskellige blockchains er denne proces organiseret forskelligt, og normalt er det i denne del, at den nye blockchain adskiller sig fra moderkæden, og jeg må sige, at i vores tilfælde retfærdiggør EOS fuldt ud "OS" i dets navn, vi bruger virkelig EOS som basisoperativsystem til implementering af en modificeret version af blockchain til DAOBet-opgaver.
Jeg vil beskrive individuelle problemer, og hvordan de kan løses inden for spillet. Lad os forestille os et netværk, hvor din server åbenlyst kan angribes, hvor du for at bevare validatorens position skal konstant interagere med netværket, promovere din validator og sørge for, at han producerer blokke, og de bliver leveret til andre validatorer til tiden, ellers vil validatoren blive smidt ud af listen.
Hvordan vælger man topvindere?
Det vigtigste tekniske krav til spillet er, at dets resultater kan verificeres offentligt. Dette betyder, at resultaterne af spillet: TOP-vindere, skal dannes udelukkende på basis af data, der kan verificeres af enhver deltager. I et centraliseret system kunne vi måle "oppetiden" for hver validator og belønne dem, der var mest online eller passerede gennem den maksimale netværkstrafik. Du kan indsamle data om processor- og hukommelsesbelastning og belønne dem, der har arbejdet godt. Men enhver sådan indsamling af metrikker betyder eksistensen af et indsamlingscenter, og noderne er alle uafhængige og kan opføre sig, som de vil, og sende alle data.
Derfor er den naturlige løsning, at vinderne skal afgøres ud fra data fra blockchainen, da den kan bruges til at se, hvilken validator der har produceret hvilken blok, og hvilke transaktioner der er inkluderet i den. Vi kaldte dette nummer for Validator Points (VP), og at optjene dem er hovedmålet for validatorer i spillet. I vores tilfælde er den enkleste, let offentligt verificerbare og effektive metrik for en validators "nytte" VP = antallet af blokke produceret af validatoren i en given tidsperiode.
Dette enkle valg skyldes det faktum, at styring i EOS allerede sørger for mange nye problemer, eftersom EOS er arving til tre generationer af faktisk fungerende blockchains med stor erfaring i kompleks netværksstyring og næsten alle valideringsproblemer med netværket, processoren, disk fører kun til ét problem - han underskriver færre blokke, modtager mindre betaling for arbejdet, hvilket igen fører os blot til antallet af signerede blokke - for EOS er dette en fremragende og enkel mulighed.
For andre blockchains kan den måde, hvorpå Validator Points beregnes, variere, for eksempel for pBFT-baserede konsensus (Tendermint/Cosmos, Aura consensus fra Parity Substrate), hvor hver blok skal være underskrevet af flere validatorer, giver det mening at tælle individuelle validatorer signaturer frem for blokeringer Det kan være fornuftigt at tage hensyn til ufuldstændige konsensusrunder, som spilder ressourcerne hos andre validatorer, generelt afhænger dette meget af typen af konsensus.
Hvordan man simulerer virkelige driftsforhold
Grundlæggernes opgave er at teste validatorer under forhold tæt på virkeligheden, uden at have nogen centraliseret kontrol. Dette problem kan løses ved hjælp af en vandhanekontrakt, som distribuerer lige store mængder af hovedtokenet til validatorer og alle andre. For at modtage tokens på din saldo skal du oprette en transaktion og sikre, at netværket inkluderer den i blokken. For at vinde skal en validator derfor konstant genopfylde sin balance med nye tokens og stemme på sig selv, og promovere sig selv til toppen. Denne aktivitet skaber en konstant belastning på netværket, og parametrene kan vælges, så strømmen af anmodninger er alvorlig nok til en fuld netværkstest. Planlæg derfor vandhanekontrakten på forhånd som et vigtigt værktøj til at starte netværket og begynd at vælge dets parametre på forhånd.
At anmode om tokens fra en vandhane og validere stemmer efterligner stadig ikke fuldt ud driften af et sprænghoved, især i ekstremt belastede tilstande. Derfor skal blockchain-teamet stadig skrive yderligere benchmarks på den ene eller anden måde for at indlæse netværket. En særlig rolle i dette spilles af specielt oprettede smarte kontrakter, der tillader test af et separat undersystem. For at teste lagring gemmer kontrakten tilfældige data i blockchainen, og for at teste netværksressourcer kræver testkontrakten en stor mængde inputdata, hvorved mængden af transaktioner pumpes op - ved at starte en strøm af sådanne transaktioner på vilkårlige tidspunkter, holdet tester samtidig kodens stabilitet og styrken af validatorerne.
Et separat problem er at opdatere nodernes kode og udføre hårde gafler. Det er påkrævet, at validatorer i tilfælde af en fejl, sårbarhed eller samarbejde mellem ondsindede validatorer skal have en handlingsplan, der allerede er udarbejdet i validatorernes spil. Her kan du finde på skemaer til at optjene VP for hurtigt at anvende en hard fork, for eksempel ved at bøde alle validatorer, der endnu ikke har udrullet en ny version af nodekoden, men det er svært at implementere og komplicerer beregningen. Du kan simulere situationen med en nødsituation brug af en hård gaffel ved kunstigt at "bryde" blockchain på en given blok. Blokproduktionen stopper, og i sidste ende bliver vinderne dem, der springer først ind og begynder at signere blokke, så VP baseret på antallet af signerede blokke passer godt her.
Sådan informerer du deltagere om netværksstatus og retter fejl
På trods af mistilliden mellem validatorer er rettidig modtagelse af ajourførte oplysninger om netværkets tilstand gavnlig for alle for at træffe beslutninger hurtigere, så projektteamet rejser en tjeneste til at indsamle og visualisere mange metrics fra validatorservere, som giver dig mulighed for at se situationen samtidigt for hele netværket, så du hurtigt kan bestemme, hvad der sker. Det er også en fordel for både validatorerne og projektet, at projektteamet hurtigt retter de fundne fejl, så ud over at indsamle metrics giver det mening straks at begynde at indsamle logs og fejldata fra validatorernes maskiner på en maskine, der er tilgængelig for blockchain. udviklere. Her er det ikke fordelagtigt for nogen at fordreje information, så disse tjenester er udviklet af projektteamet og kan stole på. Det giver mening at indsamle systemmetrikker fra validatorer, og selvfølgelig er de vigtigste metrics for selve blockchain - for DAOBet - færdiggørelsestiden og forsinkelsen af den sidst afsluttede blok. Takket være dette ser teamet en stigning i hukommelsesforbrug på noder, når de kører benchmark, problemer med individuelle validatorer
Vigtige pointer for at gennemføre et valideringsspil
Som det viser sig, hvis du officielt vil tillade validatorer at angribe hinandens maskiner (uofficielt kan de gøre dette alligevel), skal du separat formulere dette juridisk som sikkerhedstest, da DDoS eller netværksangreb i henhold til nogle landes love kan være straffet. Et andet vigtigt spørgsmål er, hvordan man belønner validatorer. Naturlige præmier er projekt-tokens, som vil blive overført til mainnet, men en massiv distribution af tokens til alle, der var i stand til at starte en node, er heller ikke den bedste mulighed. Mest sandsynligt bliver du nødt til at balancere mellem to ekstreme muligheder:
Fordel hele præmiepuljen i henhold til den optjente VP
det er meget demokratisk og giver alle, der har investeret tid og ressourcer i valideringsspillet, mulighed for at tjene penge
men tiltrækker tilfældige mennesker til spillet uden forberedt infrastruktur
Fordel top-N præmiepuljen til validatorer baseret på resultaterne af spillet
Vinderne vil højst sandsynligt være de validatorer, der varede mest konsekvent under spillet og er meget strengt fast besluttet på at vinde
nogle validatorer ønsker ikke at deltage, lavt vurderer deres chancer for at vinde, især hvis deltagerne inkluderer ærværdige validatorer
Hvilken mulighed du skal vælge er op til dig
Der er endnu en pointe - det er slet ikke en kendsgerning, at snesevis af validatorer vil skynde sig at deltage i spillet på dit opkald, og af dem, der beslutter sig for at prøve, vil ikke alle af dem endda installere og starte noden - normalt, på nuværende tidspunkt har projekter ret sparsom dokumentation, der opstår fejl, og udviklere, der arbejder under tidspres, svarer ikke særlig hurtigt på spørgsmål. Derfor, før du starter spillet, er det også nødvendigt at sørge for handlinger, hvis det nødvendige antal validatorer ikke er nået. I dette tilfælde, i starten af spillet, lanceres de manglende validatorer af projektteamet, deltager i konsensus, men kan ikke være vindere.
Konklusion
Afslutningsvis forsøgte jeg at kompilere ud fra ovenstående en liste over, hvad der skal tænkes op, laves og lanceres for effektivt at udføre et valideringsspil
Hvad du skal gøre for at køre et rigtigt valideringsspil:
udvikle din egen blockchain :)
- lave og hæve en webgrænseflade og levere en CLI til at stemme på validatorer
- sørg for, at metrics fra en kørende valideringsnode kan sendes til en centraliseret tjeneste (for eksempel Prometheus)
- oprette en metrikindsamlingsserver (Prometheus + Grafana) til valideringsspillet
- finde ud af, hvordan Validator Points (VP) vil blive beregnet
- udvikle et offentligt script, der beregner validator VP baseret på data fra blockchain
- udvikle en webgrænseflade til at vise de bedste validatorer og validatorernes spilstatus (hvor lang tid er der tilbage til slutningen, hvem har hvor meget VP osv.)
- udvikle og automatisere lanceringen af et vilkårligt antal af dine egne noder, design processen med at forbinde validatorer til spillet (hvornår og hvordan du afbryder dine noder, indsender og fjerner stemmer for dem)
- beregne, hvor mange poletter der skal udstedes, og udvikle en vandhanekontrakt
- lav et benchmark-script (tokenoverførsler, massivt lagerforbrug, massivt netværksbrug)
- samle alle deltagere i én chat for hurtig kommunikation
- start blockchain lidt tidligere end spillets start
- vent på startblokken, start spillet
- teste netværket med flere typer transaktioner
- rul en hård gaffel ud
- ændre listen over validatorer
- gentag trin 13,14,15, XNUMX, XNUMX i forskellige rækkefølger for at bevare netværkets stabilitet
- vent på den sidste blok, afslut spillet, tæl VP
Det skal siges, at spillet med validatorer er en ny historie, og det blev kun gennemført et par gange, så du skal ikke tage denne tekst som en færdig guide. Der er ingen analoger i den moderne it-forretning - forestil dig, at banker, før de lancerer et betalingssystem, konkurrerer med hinanden om, hvem der vil være bedst til at udføre kundetransaktioner. Det er usandsynligt, at traditionelle tilgange hjælper dig med at skabe store decentrale netværk, så behersk nye forretningsmodeller, kør dine spil, identificer de værdige, belønne dem og hold dine distribuerede systemer kørende hurtigt og stabilt.
Kilde: www.habr.com