Så, dit team har afsluttet alpha-versionen af din blockchain, og det er tid til at lancere 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 det hele i praksis. I den ideelle kryptoanarkistiske verden uploader du genesis block, den endelige kode for noderne, og validatorerne starter det hele op, opsætter alle de relevante tjenester, og alt sker af sig selv. Men det er i en fiktiv verden; i den virkelige verden skal teamet forberede en del supportsoftware og forskellige procedurer for at hjælpe validatorerne med at lancere et bæredygtigt netværk. Dette emne er fokus for denne artikel.
At lancere netværk baseret på konsensus som 'proof-of-stake', hvor validatorerne bestemmes af stemmerne fra tokenholderne i systemet, er en ret speciel affære, da selv lanceringen af traditionelle, centralt styrede systemer med dozens og hundreder servere er i sig selv en vanskelig opgave, og blockchain skal startes med indsatsen fra loyale, men uafhængige deltagere. Og hvis, i et firma, administratorerne har fuld adgang til alle maskiner, logs, og generel overvågning, så vil validatorerne nægte adgang til deres servere og sandsynligvis foretrække at bygge deres egen infrastruktur, da den kontrollerer adgangen til validatorens primære aktiver — stemmeindsatserne. Denne adfærd muliggør opbygningen af distribuerede sikre netværk — uafhængigheden af de anvendte cloud-udbydere, virtuelle og 'baremetal' servere, forskellige operativsystemer, alt dette gør angreb på et sådant netværk ekstremt ineffektive — der anvendes for meget forskelligt software. For eksempel i Ethereum bruges der to primære implementeringer af noden, den på Go og den på Rust, og et angreb, der er effektivt for én implementering, virker ikke for en anden.
Derfor skal alle processer til start og drift af blockchains organiseres, så enhver validator, eller endda en lille gruppe af validatorer, på ethvert tidspunkt kan kaste deres computere ud af vinduet og forlade systemet, uden at noget går i stykker, og de resterende validatorer fortsat effektivt kan opretholde netværket og tilslutte nye validatorer. Ved opstart af netværket, når en validator er i Europa, en anden i Sydamerika og en tredje i Asien, er det temmelig vanskeligt at opnå enighed blandt flere dusin uafhængige grupper og motivere dem til resultatet.
Validatorer
Lad os forestille os lanceringen af en hypotetisk moderne blockchain (det meste af det beskrevne gælder for blockchains baseret på enhver moderne familie af blockchains: Ethereum, EOS, Polkadot, Cosmos og andre, der anvender proof-of-stake konsensus. De primære aktører i sådanne blockchains er validatorhold, der opretter deres egne uafhængige servere, validerer og producerer nye blokke og modtager de belønninger, der er afsat af netværket til dem, der deltager i konsensus. For at starte nye netværk kræves der flere dusin validatorer (så mange kan nu mere eller mindre effektivt nå konsensus på sekunder), derfor annoncerer projektet registreringen, hvor validatorer deler offentlige oplysninger om sig selv med brugerne, og overbeviser dem om, at de er villige til at levere kvalitetsservice til det nye netværk.
Validatorvirksomhed er en forretning, der gør det muligt at estimere validatorens potentielle indkomst meget præcist, hurtigt flytte ressourcer mellem projekter, og i tilfælde af succes med det valgte netværk, kan validatoren, som et fuldt medlem af DAO og ansvarlig part, udvikle projektet, eller blot levere en fremragende teknisk service for helt transparente, ærligt tjente penge. Ved beregning af belønningen til validatorerne prøver projekterne at tage højde for validatorernes omkostninger og gøre belønningen for blokke sådan, at denne forretning er rentabel, men samtidig ikke tillader validatorer at kollapse økonomien ved at oversvømme dem med penge og berøve de øvrige brugere af netværket.
Virksomhedens validatorer kræver en høj grad af pålidelighed i tjenesterne, hvilket betyder, at devops- og udviklerteamene skal have et højt niveau af forberedelse og kostbare beregningsressourcer. Selv uden behov for at mine hashes i proof-of-work-netværk, er en blockchain-node en stor tjeneste, der optager meget hukommelse, forbruger mange beregninger, validerer, registrerer data på disk og sender store mængder data ud i netværket. For at lagre transaktionslister og blockchains for blokke med flere tusinde små transaktioner kræves der i øjeblikket opbevaring på over 50 Gb, og for blokke skal dette være SSD. State-databaserne for blockchains med støtte for smart contracts kan allerede overstige 64Gb RAM. Servere med de nødvendige specifikationer er ret dyre, en Ethereum- eller EOS-node kan koste fra 100 til 200 $/måned. Tilsæt hertil den øgede lønudgift for udviklere og devops, der arbejder døgnet rundt for at løse problemer, selv om natten, da nogle validatorer let kan befinde sig på den anden halvkugle. Ikke desto mindre kan ejerskab af en validator-node i gunstige øjeblikke generere betydelige indtægter (i tilfælde af EOS – op til 10.000 $ per dag).
Validering er kun en af de nye potentielle IT-roller for iværksættere og virksomheder, efterhånden som programmører finder på stadig mere sofistikerede algoritmer, der belønner ærebarhed og straffer bedrag og tyveri. Der opstår tjenester, der offentliggør vigtige data (orakler), udfører overvågning (slashing af indskud og straffelse af bedragere ved at offentliggøre bevis for bedrageri), tjenester til konfliktløsning, forsikringer og optioner; selv garbage collection er et potentielt stort marked i smart contract-systemer, hvor betaling for datalagring er nødvendig.
Problemer med at starte en blockchain
Offentligheden af blockchain, som har gjort det muligt for folk fra enhver nation at deltage frit i netværket af computere, samt den nemme adgang for enhver script kiddie via en guide på GitHub, er ikke altid en fordel. Jagten på en ny token tvinger ofte validatorer til at "mine en ny mønt ved starten" i håbet om værdistigning og mulighed for hurtigt at sælge det, de har tjent. Det betyder også, at hvem som helst kan være din validator, selv anonymt, og de kan stemmes på ligesom alle andre validatorer (selv om det vil være vanskeligt for anonymen at samle stemmer fra interessenter, så lad os lade de skræmmende fortællinger om anonyme kryptovalutaer til politikerne). Alligevel
Projektteamet har en opgave - at få fat i de personer, der i fremtiden kan sikre stabil drift af noder, som har viden om sikkerhed, kan løse problemer hurtigt, samarbejde med andre validatorer og handle kollektivt - afhængig af disse kvaliteter vil kvaliteten af den token, som netværksdeltagere planlægger at investere deres tid og ressourcer i, være. Ansvarsbevidste grundlæggere, når de vurderer risici, forstår godt, at ved lanceringen af software af denne størrelse vil der uundgåeligt opstå fejl i koden og konfigurationen af noder, og at netværkets stabilitet afhænger af, hvor godt udviklerne og validatorer sammen vil løse sådanne problemer.
Teamet er klar til at stemme i mainnet for enhver validator, men det ville være rart at vide, for hvem, hvilke der er gode? Den med det største portefølje? Det har nærmest ingen i øjeblikket. Ud fra teamprofiler på Linkedin? Erfarne devops eller sikkerhedseksperter vil ikke give jer nogen profiler på Linkedin. Baseret på udtalelser i chatten, opslag og hjælp til andre under forberedelserne? Godt, men subjektivt og unøjagtigt.
Under sådanne forhold er der kun én løsning - et spil, der kan løse problemer for alle - hvor man kan vælge de bedste validatorer, men vigtigst af alt - teste blockchainens robusthed og gennemføre en fuldskala feltprøve af blockchainen under aktiv brug, ændringer i konsensus og forekomsten og rettelsen af fejl. Denne procedure blev først præsenteret som et spil af drengene fra projektet Cosmos, og denne idé er uden tvivl en fremragende måde at forberede netværket til lancering af et pålideligt og fejltolerant mainnet.
Game of Validators
Jeg vil beskrive validator-spillet, som vi designede til blockchain DAO.Casino (DAOBet) baseret på en fork af EOS, kaldet Haya, der har et lignende governance-system — validatorer vælges ved afstemninger fra enhver konto, hvor en del af balancen, der stemmes for validatoren, fryses. Enhver konto, der har den primære tokens BET på sin balance, kan stemme på den valgte validator med hvilken som helst del af sin balance. Stemmerne summeres, og der udarbejdes en topvaliderliste. I forskellige blockchains er denne proces organiseret forskelligt, og normalt er det netop i denne del, at en ny blockchain adskiller sig fra sin forælder. Man må sige, at i vores tilfælde lever EOS fuldt ud op til “OS” i sit navn; vi bruger faktisk EOS som det grundlæggende operativsystem til at implementere en modificeret version af blockchainen til opgaverne for DAOBet.
Jeg vil beskrive specifikke problemer og hvordan de kan løses indenfor spillet. Lad os forestille os et netværk, hvor din server kan blive åbent angrebet, hvor du er nødt til kontinuerligt at interagere med netværket for at opretholde din position som validator, fremme din validator og sørge for, at den producerer blokke og at de kommer til andre validatorer til tiden, ellers vil validatoren blive udelukket fra listen.
Hvordan vælger man de bedste vindere?
Det primære tekniske krav til spillet er, at dets resultater skal være offentligt verificerbare. Det betyder, at resultaterne af spillet: TOP-vinderne, skal dannes strengt på baggrund af data, som enhver deltager kan kontrollere. I et centraliseret system kunne vi måle “uptime” for hver validator og belønne dem, der har været online mest, eller der har passeret mest netværkstrafik. Vi kunne indsamle data om CPU-belastning, hukommelse og belønne dem, der har arbejdet hårdt. Men enhver sådan indsamling af metrics indebærer eksistensen af et centralt knudepunkt, og noderne er alle uafhængige og kan opføre sig, som de vil, og sende hvilke som helst data.
Der naturlige løsning er derfor, at vindere skal bestemmes ud fra data fra blockchainen, da man kan se, hvilke validatorer der har produceret hvilken blok, og hvilke transaktioner der blev inkluderet i den. Vi har kaldt dette antal Validator Points (VP), og at tjene disse er den primære målsætning for validatorerne i spillet. I vores tilfælde er den enkleste, offentligt verificerbare og effektive måling af en validators "nytte" VP = antal_producerede_valideringsblokke over en given tidsperiode.
Dette enkle valg skyldes, at governance i EOS allerede tager højde for mange opståede problemer, da EOS er en arv af tre generationer af reelt fungerende blockchains med stor erfaring i kompleks netværksstyring. Næsten enhver validatorproblematik med netværket, CPU eller disk fører kun til ét problem – man underskriver færre blokke og modtager mindre betaling for arbejdet, hvilket igen fører os tilbage til antallet af underskrevne blokke – for EOS er dette et fremragende og simpelt valg.
For andre blockchains kan metoden til beregning af Validator Points variere, for eksempel for pBFT-baserede konsensusmetoder (Tendermint/Cosmos, Aura konsensus fra Parity Substrate), hvor hver blok skal underskrives af flere validatorer. Det kan give mening at tælle individuelle underskrifter fra validatorerne, snarere end blokke, og muligvis også tage højde for ikke-afsluttede konsensusrunder, som forbruger ressourcer fra andre validatorer; dette afhænger i høj grad af typen af konsensus.
Hvordan man modellerer reelle driftsbetingelser
Grundlæggernes opgave er at kontrollere validatorer under forhold, der ligner virkeligheden, uden nogen form for centraliseret kontrol. Dette problem kan løses med en faucet-kontrakt, der uddeler lige mængder af den primære token til validatorer og alle interesserede. For at modtage tokens på saldoen skal man oprette en transaktion og sikre, at netværket inkluderer den i en blok. Dermed er det nødvendigt for validatoren konstant at opdatere sin saldo med nye tokens og stemme på sig selv for at komme til tops. Denne aktivitet skaber en konstant belastning på netværket, og parametrene kan justeres, så mængden af anmodninger er tilstrækkelig stor til en grundig netværkstests. Planlæg derfor faucet-kontrakten i forvejen som et vigtigt værktøj til netværksstart og begynd at tilpasse dens parametre tidligt.
Anmodningen om tokens fra faucet og validatorernes stemmeemulering efterligner alligevel ikke helt arbejdet i blockchain, især under ekstremt belastede tilstande. Derfor bliver blockchain-teamet nødt til på den ene eller anden måde at skrive yderligere benchmarks, der kan belaste netværket. Særligt tilpassede smart contracts spiller en vigtig rolle i dette og gør det muligt at teste individuelle undersystemer. For at teste storage gemmer kontrakten tilfældige data i blockchain, og for at kontrollere netværksressourcer kræver testkontrakten en stor mængde inddata, hvilket dermed øger mængden af transaktioner — ved at starte strømmen af sådanne transaktioner på vilkårlige tidspunkter tester teamet samtidig stabiliteten af koden og validatorernes robusthed.
Et særskilt spørgsmål er opdatering af noderne og udførelsen af hard forks. Det er nødvendigt, at der, i tilfælde af en fejl, sårbarhed eller sammensværgelse af ondsindede validatorer, foreligger en handlingsplan for validatorerne, som allerede er afprøvet i validatorernes spil. Her kan man finde på ordninger til tildeling af VP for hurtig gennemførelse af hard forks, eksempelvis ved at straffe alle validatorer, der ikke har opdateret til den nye version af nodens kode, men det er svært at implementere, da det komplicerer beregningen. Man kan simulere en situation med akut anvendelse af en hard fork ved kunstigt at "ødelægge" blockchainen på et bestemt blok. Produktion af blokke stopper, og de, der hurtigst aktiverer sig og begynder at validere blokke, vil være dem, der vinder, så VP baseret på antallet af validerede blokke passer godt ind her.
Hvordan informere deltagerne om netværkets tilstand og rette fejl
På trods af mistillid mellem validatorerne er det fordelagtigt for alle hurtigt at modtage aktuel information om netværkets tilstand for at træffe hurtigere beslutninger. Derfor opstiller projektteamet en service til indsamling og visualisering af mange metrikker fra validatorernes servere, hvilket gør det muligt at se situationen samlet for hele netværket og hurtigt bestemme, hvad der foregår. Desuden er det i både validatorernes og projektets interesse, at projektteamet hurtigt retter opdagede fejl, så det giver mening at starte med at indsamle logfiler og fejldata fra validatorernes maskiner til en maskine tilgængelig for blockchain-udviklerne. Ingen har interesse i at fordreje information, så disse tjenester opstilles af projektteamet og kan stole på. Det giver mening at indsamle systemmetrikker fra validatorerne og, nødvendigvis, de mest vigtige metrikker fra blockchainen selv — for DAOBet er det tid til finalisering og efterslæb for den senest finaliserede blok. Takket være dette ser teamet stigninger i hukommelsesforbruget på noderne ved opstart af benchmark, samt problemer hos enkelte validatorer.
Vigtige punkter for afholdelse af validatorernes spil
Det viser sig, at hvis du ønsker at give validatorerne officiel tilladelse til at angribe hinandens maskiner (uofficielt kan de allerede gøre dette) — skal det formuleres juridisk som sikkerhedstest, da lovgivningen i nogle lande kan straffe DDoS- eller netværksangreb. Et andet vigtigt spørgsmål er, hvordan man belønner validatorerne. Naturlige præmier er projektets tokens, som overføres til mainnet, men en massiv distribution af tokens til enhver, der kan starte en node, er heller ikke den bedste løsning. Det vil sandsynligvis kræve, at du balancerer mellem to yderligheder:
Uddel hele præmiefonden i overensstemmelse med de optjente VP
det er meget demokratisk og giver mulighed for, at alle, der har investeret tid og ressourcer i validatorernes spil, kan tjene
men tiltrækker tilfældige mennesker uden forberedt infrastruktur til spillet
Uddel præmiefonden til top-N validatorer baseret på spillets resultater
vinderne vil sandsynligvis være de validatorer, der har været mest stabile gennem spillet og har været meget målrettede mod sejren
nogle validatorer vil nægte at deltage, da de vurderer deres chancer for at vinde som lave, især hvis der er etablerede validatorer blandt deltagerne
Hvilket alternativ du foretrækker — er op til dig
Der er også et andet aspekt — det er slet ikke sikkert, at mange validatorer vil strømme til at deltage i spillet på din opfordring, og af dem, der beslutter sig for at prøve, vil ikke alle engang installere og starte en node — normalt har projekter på dette stadium ret sparsomme dokumentation, der optræder fejl, og udviklerne, der arbejder under tidspres, svarer ikke alt for hurtigt på spørgsmål. Derfor bør du før spillets start også overveje, hvad der skal gøres, hvis ikke det ønskede antal validatorer kan samles. I dette tilfælde startes de manglende validatorer af projektteamet ved spillets start, deltager i konsensus, men kan ikke være vindere.
Konklusion
Afslutningsvis har jeg forsøgt at samle en liste over det, der skal tænkes, gøres og startes for effektivt at gennemføre validatorernes spil med ovenstående beskrivelse
Hvad der skal gøres for at starte et rigtigt spil for validatorer:
udvikle din egen blockchain 🙂
- lave og opsætte et webinterface og give CLI til at stemme på validatorer
- Sørg for, at metrics fra den kørende validatornode kan sendes til en centraliseret service (som f.eks. Prometheus)
- Opsæt en server til indsamling af metrics (Prometheus + Grafana) til validatorernes spil
- Find ud af, hvordan Validator Points (VP) skal beregnes
- Udvikle et offentligt script, der beregner VP for validatorer baseret på data fra blockchain
- Udvikle en webgrænseflade til at vise top-validatorer og status for validatorernes spil (hvor lang tid der er tilbage, hvor mange VP hver har osv.)
- Udvikle og automatisere opstarten af et vilkårligt antal egne noder, designe processen for forbindelsen af validatorer til spillet (hvornår og hvordan man slukker for sine noder, afgiver og trækker stemmer tilbage for dem)
- Beregn, hvor mange tokens der skal uddeles, og udvikle en kontrakt-faucet
- Lave et benchmark-script (tokenoverførsler, massiv brug af lager, massiv brug af netværk)
- Samle alle deltagere i én chat for hurtig kommunikation
- Lancere blockchain lidt før spillets start
- Vent på startblokken, begynd spillet
- Teste netværket med flere typer transaktioner
- Udføre en hard fork
- Ændre listen over validatorer
- Gentage pkt. 13, 14, 15 i forskellig rækkefølge, mens stabiliteten af netværket opretholdes
- Vent på den endelige blok, afslut spillet, og beregn VP
Det skal siges, at validatorernes spil er en ny historie, der kun er blevet afholdt et par gange, så dette tekst skal ikke betragtes som en færdig vejledning. Der findes ingen analoger i den moderne IT-verden – forestil dig, at banker konkurrerer om, hvem der bedst kan gennemføre kundetransaktioner, inden de lancerer deres betalingssystem. Traditionelle metoder vil næppe hjælpe dig med at oprette store decentrale netværk, så lær nye forretningsmodeller at kende, afhold dine spil, udpeg værdige, beløn dem, og lad dine distribuerede systemer fungere hurtigt og stabilt.
Kilde: habr.com
