Så teamet ditt har fullført alfaversjonen av blokkjeden din, og det er på tide å starte testnet og deretter mainnet. Du har en ekte blokkjede, med uavhengige deltakere, en god økonomisk modell, sikkerhet, du har designet styring og nå er det på tide å prøve alt dette i aksjon. I en ideell kryptoanarkisk verden legger du genesis-blokken på nettverket, den endelige koden til noden og validatorene selv starter alt, hever alle hjelpetjenester, og alt skjer av seg selv. Men dette er i en fiktiv verden, men i den virkelige verden må teamet forberede ganske mye ekstra programvare og ulike manipulasjoner for å hjelpe validatorer med å lansere et stabilt nettverk. Dette er hva denne artikkelen handler om.
Å lansere nettverk basert på "proof-of-stake"-konsensus, der validatorer bestemmes av stemmene til systemtokenholdere, er en ganske spesifikk hendelse, fordi det ikke er lett å lansere tradisjonelle, sentralstyrte systemer med titalls og hundrevis av servere. oppgave i seg selv, og blokkjeden må startes med innsats lojale, men uavhengige deltakere. Og hvis i et selskap, ved oppstart, har administratorer full tilgang til alle maskiner, logger, generell overvåking, vil validatorer ikke tillate noen å få tilgang til serverne deres og vil mest sannsynlig foretrekke å bygge infrastrukturen deres uavhengig, fordi den kontrollerer tilgangen til de viktigste eiendelene til validatoren - satser velgere. Det er denne oppførselen som gjør det mulig å bygge distribuerte sikre nettverk - uavhengigheten til skyleverandørene som brukes, virtuelle og "baremetal" servere, forskjellige operativsystemer, alt dette lar deg gjøre angrep på et slikt nettverk ekstremt ineffektive - for mye forskjellig programvare brukes. For eksempel bruker Ethereum to hovednodeimplementeringer, i Go og i Rust, og et angrep som er effektivt for en implementering fungerer ikke for den andre.
Derfor må alle prosesser for lansering og drift av blokkjeder organiseres på en slik måte at enhver validator, eller til og med en liten gruppe validatorer, når som helst kan kaste datamaskinene sine ut av vinduet og forlate, mens ingenting skal gå i stykker og de gjenværende validatorene bør fortsett å effektivt støtte driftsnettverket og koble til nye validatorer. Når du lanserer et nettverk, når en validator er i Europa, den andre i Sør-Amerika og den tredje i Asia, er det ganske vanskelig å oppnå det koordinerte arbeidet til flere dusin uavhengige grupper og interessere dem som et resultat.
Validatorer
La oss forestille oss lanseringen av en hypotetisk moderne blokkjede (det meste av det som er beskrevet er egnet for blokkjeder basert på en hvilken som helst moderne familie av blokkkjeder: Ethereum, EOS, Polkadot, Cosmos og andre, som gir bevis-på-innsats-konsensus. Hovedpersonene i slike blokkjeder er valideringsteam , engasjert i å installere sine egne uavhengige servere som validerer og produserer nye blokker, og mottar belønninger gitt av nettverket for de som deltar i konsensus. For å lansere nye nettverk kreves det flere dusin validatorer (så mange kan nå mer eller mindre effektivt oppnå konsensus i løpet av sekunder), så prosjektet kunngjør registrering, der validatorer deler offentlig informasjon om seg selv med brukere, og overbeviser dem om at de kommer til å tilby høykvalitetstjenester til det lanserte nettverket.
Validering er en virksomhet som lar deg ekstremt nøyaktig vurdere validatorens potensielle inntekt, raskt overføre makt mellom prosjekter, og hvis nettverket han har valgt er vellykket, kan validatoren, som en fullverdig deltaker i DAO og en ansvarlig person, utvikle prosjektet, eller bare gi utmerket teknisk service for helt gjennomsiktige, ærlig tjente penger. Når de beregner belønningen for validatorer, prøver prosjekter å ta hensyn til kostnadene til validatorer og gjøre belønningen for blokker slik at denne virksomheten er lønnsom, men samtidig tillater ikke validatorer å få ned økonomien ved å oversvømme dem med penger og frata andre nettverksbrukere det.
Virksomheten til validatorer krever å sikre høy feiltoleranse for tjenester, noe som betyr et høyt opplæringsnivå for devops og utviklere og dyre dataressurser. Selv uten behov for å mine hashes i proof-of-work-nettverk, er en blockchain-node en stor tjeneste som tar opp mye minne, bruker mange beregninger, validerer, skriver til disk og sender store mengder data til nettverket . For å lagre transaksjonslogger og blokkjeder for en blokkjede med flere tusen små transaksjoner i en blokk kreves det nå lagring på 50 Gb eller mer, og for blokker må det være en SSD. Statlig database over blokkjeder med støtte for smarte kontrakter kan allerede overstige 64 Gb RAM. Servere med de nødvendige egenskapene er ganske dyre; en Ethereum- eller EOS-node kan koste fra 100 til 200 $/måned. Legg til dette de økte lønningene for det døgnåpne arbeidet til utviklere og devops, som i løpet av lanseringsperioden løser problemer selv om natten, siden noen validatorer lett kan lokaliseres på en annen halvkule. Men i de riktige øyeblikkene kan det å eie en valideringsnode gi alvorlige inntekter (i tilfelle EOS, opptil $10 000 per dag).
Validering er bare en av de nye potensielle IT-rollene for gründere og bedrifter; etter hvert som programmerere kommer opp med flere og mer sofistikerte algoritmer som belønner ærlighet og straffer svindel og tyveri, dukker det opp tjenester som utfører funksjonene med å publisere viktige data (orakler), utføre tilsyn (deposit slashing and punishing cheaters by publish proof of deception), tvisteløsningstjenester, forsikring og alternativer, til og med søppelinnsamling er et potensielt stort marked innen smarte kontraktsystemer hvor det er nødvendig å betale for datalagring.
Problemer med å lansere en blokkjede
Åpenheten til blokkjeden, som gjorde det mulig for datamaskiner fra ethvert land å fritt delta i nettverket og det enkle å koble en hvilken som helst skriptbarn til nettverket i henhold til instruksjonene på GitHub, er ikke alltid en fordel. Jakten på et nytt token tvinger ofte validatorer til å "mine en ny mynt i starten", i håp om at kursen vil stige og muligheten til å raskt kaste av seg inntektene. Dette betyr også at validatoren din kan være hvem som helst, til og med en anonym person, du kan stemme på ham på samme måte som for andre validatorer (det vil imidlertid være vanskelig for en anonym person å samle interessentstemmer for seg selv, så vi vil overlate de skumle historiene om anonyme kryptovalutaer til politikere). Likevel
Prosjektteamet har en oppgave - å på en eller annen måte komme inn i nettverket sitt de som i fremtiden er i stand til å sikre stabil drift av noder, forstår sikkerhet, vet hvordan de raskt løser problemer, samarbeider med andre validatorer og handler sammen - kvaliteten på det mye avhenger helt av disse egenskapene, et symbol som nettverksdeltakere kommer til å investere sin tid og ressurser i. Adekvate grunnleggere, når de vurderer risikoene, forstår godt at når du lanserer programvare av denne størrelsen, vil du definitivt måtte støte på feil i koden og konfigurasjonen av noder, og at stabiliteten til nettverket avhenger av hvor godt utviklere og validatorer vil løse i fellesskap slike problemer.
Teamet er klare til å stemme på hovednettet for alle validatorer, bare for å vite hvilke, hvilke er gode? Den største porteføljen? Det er nesten ingen som har det nå. Basert på lagets Linkedin-profiler? Erfarne devops eller sikkerhetsspesialister vil ikke gi deg noen Linkedin-profiler. Ifølge uttalelser i chat, innlegg og hjelpe andre i forberedelsesfasen? Bra, men subjektivt og unøyaktig.
Under slike forhold gjenstår en ting - noe som løser alles problemer godt - et spill der det vil være mulig å velge de beste validatorene, men det viktigste er å teste blokkjeden for styrke og gjennomføre en fullskala kamptest av blokkjede i forhold til aktiv bruk, endringer i konsensus, utseende og retting av feil . Denne prosedyren ble først presentert som et spill av gutta fra Cosmos-prosjektet, og denne ideen er utvilsomt en utmerket måte å forberede nettverket på lanseringen av et pålitelig og feiltolerant hovednett.
Game of Validators
Jeg vil beskrive spillet med validatorer slik vi designet det for DAO.Casino (DAOBet) blokkkjeden basert på EOS-gaffelen, som kalles Haya og har en lignende styringsmekanisme - validatorer velges ved å stemme fra hvilken som helst konto, hvor en del av saldoen som ble brukt til å stemme på validatoren, fryses. Enhver konto som har hovedinnsatsen på saldoen kan stemme på den valgte validatoren med hvilken som helst del av saldoen. Stemmene summeres og de beste validatorene bygges basert på resultatene. I forskjellige blokkjeder er denne prosessen organisert forskjellig, og vanligvis er det i denne delen at den nye blokkjeden skiller seg fra den overordnede, og jeg må si at i vårt tilfelle rettferdiggjør EOS fullt ut "OS" i navnet, vi bruker virkelig EOS som basisoperativsystem for distribusjon av en modifisert versjon av blokkjeden for DAOBet-oppgaver.
Jeg vil beskrive individuelle problemer og hvordan de kan løses i spillet. La oss forestille oss et nettverk der serveren din kan bli åpenlyst angrepet, hvor du for å opprettholde posisjonen til en validator må kontinuerlig samhandle med nettverket, promotere validatoren din og sørge for at den produserer blokker og at de blir levert til andre validatorer på tid, ellers vil validatoren bli kastet ut av listen.
Hvordan velge toppvinnere?
Det viktigste tekniske kravet til spillet er at resultatene kan verifiseres offentlig. Dette betyr at resultatene av spillet: TOP-vinnere, må dannes strengt på grunnlag av data som kan verifiseres av enhver deltaker. I et sentralisert system kunne vi måle "oppetiden" til hver validator og belønne de som var mest online eller passerte gjennom maksimal nettverkstrafikk. Du kan samle inn data om prosessor- og minnebelastning og belønne de som har jobbet godt. Men enhver slik samling av beregninger betyr at det eksisterer et innsamlingssenter, og nodene er alle uavhengige og kan oppføre seg som de vil og sende alle data.
Derfor er den naturlige løsningen at vinnerne skal avgjøres basert på data fra blokkjeden, siden den kan brukes til å se hvilken validator som produserte hvilken blokk og hvilke transaksjoner som var inkludert i den. Vi kalte dette tallet Validator Points (VP), og å tjene dem er hovedmålet for validatorer i spillet. I vårt tilfelle er den enkleste, lett offentlig verifiserbare og effektive beregningen av en validators "nytte" VP = antall blokker produsert av validatoren i en gitt tidsperiode.
Dette enkle valget skyldes det faktum at styring i EOS allerede sørger for mange nye problemer, siden EOS er arvingen til tre generasjoner av faktisk fungerende blokkjeder med lang erfaring i kompleks nettverksadministrasjon, og nesten alle validatorproblemer med nettverket, prosessoren, disk fører til bare ett problem - han signerer færre blokker, mottar mindre betaling for arbeidet, noe som igjen fører oss bare til antall signerte blokker - for EOS er dette et utmerket og enkelt alternativ.
For andre blokkkjeder kan måten Validator Points beregnes på variere, for eksempel for pBFT-baserte konsensus (Tendermint/Cosmos, Aura consensus fra Parity Substrate), der hver blokk må signeres av flere validatorer, er det fornuftig å telle individuelle validatorer signaturer i stedet for blokker. Det kan være fornuftig å ta hensyn til ufullstendige konsensusrunder, som sløser med ressursene til andre validatorer, generelt avhenger dette veldig av typen konsensus.
Hvordan simulere reelle driftsforhold
Gründernes oppgave er å teste validatorer under forhold nær virkeligheten, uten å ha noen sentralisert kontroll. Dette problemet kan løses ved å bruke en krankontrakt, som distribuerer like mengder av hovedtokenet til validatorer og alle andre. For å motta tokens på saldoen din, må du opprette en transaksjon og sørge for at nettverket inkluderer den i blokken. Derfor, for å vinne, må en validator hele tiden fylle på balansen med nye tokens og stemme på seg selv, og promotere seg selv til toppen. Denne aktiviteten skaper en konstant belastning på nettverket, og parametrene kan velges slik at flyten av forespørsler er alvorlig nok for en fullstendig nettverkstest. Planlegg derfor krankontrakten på forhånd som et viktig verktøy for å starte nettverket og begynn å velge parametrene på forhånd.
Å be om tokens fra en kran og validere stemmer etterligner fortsatt ikke driften til et stridshode fullt ut, spesielt i ekstremt belastede moduser. Derfor vil blockchain-teamet fortsatt måtte skrive flere benchmarks på en eller annen måte for å laste nettverket. En spesiell rolle i dette spilles av spesiallagde smarte kontrakter som tillater testing av et eget undersystem. For å teste lagring lagrer kontrakten tilfeldige data i blokkjeden, og for å teste nettverksressurser krever testkontrakten en stor mengde inndata, og øker dermed volumet av transaksjoner - ved å starte en flyt av slike transaksjoner på vilkårlige tidspunkter, teamet tester samtidig stabiliteten til koden og styrken til validatorene.
Et eget problem er å oppdatere koden for noder og utføre harde gafler. Det kreves at i tilfelle en feil, sårbarhet eller samarbeid mellom ondsinnede validatorer, skal validatorer ha en handlingsplan som allerede er utarbeidet i validatorspillet. Her kan du komme opp med ordninger for å akkumulere VP for raskt å bruke en hard fork, for eksempel ved å bøtelegge alle validatorer som ennå ikke har rullet ut en ny versjon av nodekoden, men dette er vanskelig å implementere og kompliserer utregningen. Du kan simulere situasjonen med en nødbruk av en hard gaffel ved å kunstig "bryte" blokkjeden på en gitt blokk. Blokkproduksjonen stopper opp, og vinnerne blir til slutt de som hopper inn først og begynner å signere blokker, så VP basert på antall signerte blokker passer bra her.
Hvordan informere deltakere om nettverksstatus og fikse feil
Til tross for mistilliten mellom validatorer, er rettidig mottak av oppdatert informasjon om nettverkets tilstand fordelaktig for alle for å ta beslutninger raskere, så prosjektteamet løfter en tjeneste for innsamling og visualisering av mange beregninger fra validatorservere, som lar deg se situasjonen samtidig for hele nettverket, slik at du raskt kan finne ut hva som skjer. Det er også fordelaktig for både validatorene og prosjektet at prosjektteamet raskt retter opp feilene som er funnet, så i tillegg til å samle inn beregninger, er det fornuftig å umiddelbart begynne å samle inn logger og feildata fra validatorenes maskiner på en maskin som er tilgjengelig for blockchain. utviklere. Her er det ikke gunstig for noen å forvrenge informasjon, så disse tjenestene er utviklet av prosjektteamet og kan stole på. Det er fornuftig å samle inn systemberegninger fra validatorer, og selvfølgelig er de viktigste beregningene for selve blokkjeden - for DAOBet - sluttføringstiden og etterslepet til den siste ferdigstilte blokken. Takket være dette ser teamet en økning i minneforbruk på noder når de kjører benchmark, problemer med individuelle validatorer
Viktige punkter for å gjennomføre et valideringsspill
Som det viser seg, hvis du offisielt vil tillate validatorer å angripe hverandres maskiner (uoffisielt kan de gjøre dette uansett), må du formulere dette separat juridisk som sikkerhetstesting, siden under lovene i noen land kan DDoS eller nettverksangrep være straffet. En annen viktig sak er hvordan man belønner validatorer. Naturlige premier er prosjekt-tokens, som vil bli overført til hovednettet, men en massiv distribusjon av tokens til alle som var i stand til å starte en node er heller ikke det beste alternativet. Mest sannsynlig må du balansere mellom to ekstreme alternativer:
Fordel hele premiepotten i henhold til opptjent VP
det er veldig demokratisk og lar alle som har investert tid og ressurser i valideringsspillet tjene penger
men tiltrekker seg tilfeldige mennesker til spillet uten forberedt infrastruktur
Fordel topp-N-premiepotten til validatorer basert på resultatene av spillet
Vinnerne vil mest sannsynlig være validatorene som varte mest konsekvent i løpet av spillet og som er svært strengt bestemt på å vinne
noen validatorer vil ikke ønske å delta, lavt vurderer sjansene for å vinne, spesielt hvis deltakerne inkluderer ærverdige validatorer
Hvilket alternativ du skal velge er opp til deg
Det er ett poeng til - det er slett ikke et faktum at dusinvis av validatorer vil skynde seg å delta i spillet når du ringer, og av de som bestemmer seg for å prøve, vil ikke alle engang installere og starte noden - vanligvis, på dette stadiet har prosjekter ganske sparsom dokumentasjon, det oppstår feil, og utviklere som jobber under tidspress svarer ikke veldig raskt på spørsmål. Derfor, før du starter spillet, er det også nødvendig å sørge for handlinger hvis det nødvendige antallet validatorer ikke er nådd. I dette tilfellet, ved starten av spillet, lanseres de manglende validatorene av prosjektteamet, deltar i konsensus, men kan ikke være vinnere.
Konklusjon
Avslutningsvis prøvde jeg å kompilere fra ovenstående en liste over hva som må tenkes opp, lages og lanseres for å effektivt gjennomføre et valideringsspill
Hva du trenger å gjøre for å kjøre et ekte valideringsspill:
utvikle din egen blockchain :)
- lage og heve et nettgrensesnitt og gi en CLI for å stemme på validatorer
- sørg for at beregninger fra en kjørende validatornode kan sendes til en sentralisert tjeneste (for eksempel Prometheus)
- heve en metrikkinnsamlingsserver (Prometheus + Grafana) for valideringsspillet
- finne ut hvordan Validator Points (VP) vil bli beregnet
- utvikle et offentlig skript som beregner validator VP basert på data fra blokkjeden
- utvikle et nettgrensesnitt for å vise de beste validatorene, og spillstatusen til validatorene (hvor mye tid er igjen til slutten, hvem har hvor mye VP, etc.)
- utvikle og automatisere lanseringen av et vilkårlig antall av dine egne noder, designe prosessen med å koble validatorer til spillet (når og hvordan koble fra nodene dine, sende inn og fjerne stemmer for dem)
- beregne hvor mange tokens som må utstedes og utvikle en krankontrakt
- lage et benchmark-skript (tokenoverføringer, massiv lagringsbruk, massiv nettverksbruk)
- samle alle deltakerne i en chat for rask kommunikasjon
- lanser blokkjeden litt tidligere enn starten av spillet
- vent på startblokken, start spillet
- teste nettverket med flere typer transaksjoner
- rull ut en hard gaffel
- endre listen over validatorer
- gjenta trinn 13,14,15, XNUMX, XNUMX i forskjellige rekkefølger, og opprettholde nettverksstabiliteten
- vent på siste blokk, avslutt spillet, tell VP
Det må sies at spillet med validatorer er en ny historie, og det ble utført bare et par ganger, så du bør ikke ta denne teksten som en ferdig guide. Det finnes ingen analoger i den moderne IT-virksomheten – tenk at bankene, før de lanserer et betalingssystem, konkurrerer med hverandre for å se hvem som vil være best til å gjennomføre kundetransaksjoner. Tradisjonelle tilnærminger vil neppe hjelpe deg med å skape store desentraliserte nettverk, så mestr nye forretningsmodeller, kjør spillene dine, identifiser de verdige, belønn dem og hold de distribuerte systemene i gang raskt og stabilt.
Kilde: www.habr.com