SÄ, ditt team har slutfört alpha-versionen av din blockchain, och det Àr dags att starta testnet och sedan mainnet. Du har en riktig blockchain med oberoende deltagare, en bra ekonomisk modell, sÀkerhet, du har designat governance och nu Àr det dags att testa allt detta i praktiken. I en idealisk kryptoanarkistisk vÀrld lÀgger du ut genesis block, den slutgiltiga koden för noden och validatorerna startar allt sjÀlva, sÀtter upp alla hjÀlptjÀnster och allt sker av sig sjÀlv. Men det Àr i en pÄhittad vÀrld, i verkligheten mÄste teamet förbereda ganska mycket hjÀlpsystem och olika manipuleringar för att hjÀlpa validatorerna att starta ett hÄllbart nÀtverk. Denna artikel handlar om det.
Att starta nĂ€tverk baserat pĂ„ konsensusmetoder som "proof-of-stake", dĂ€r validatorerna bestĂ€ms av röster frĂ„n tokeninnehavare i systemet, Ă€r en ganska specifik verksamhet, eftersom Ă€ven start av traditionella, centraliserade system med tiotals och hundratals servrar Ă€r en utmaning i sig, och det krĂ€vs att blockkedjan startas av lojala men oberoende deltagare. Om i en corporation har administratörerna full tillgĂ„ng till alla maskiner, loggar och allmĂ€n övervakning, sĂ„ kommer validatorerna inte att slĂ€ppa in nĂ„gon till sina servrar och kommer sannolikt att föredra att bygga sin infrastruktur sjĂ€lva, eftersom den kontrollerar tillgĂ„ngen till validatorernas huvudsakliga tillgĂ„ngar â stakarna som röstar. Just detta beteende gör det möjligt att bygga distribuerade sĂ€kra nĂ€tverk â oberoende av anvĂ€nda molnleverantörer, virtuella och "baremetal" servrar, olika operativsystem, allt detta gör att attacker pĂ„ ett sĂ„dant nĂ€tverk blir extremt ineffektiva â för mycket olika mjukvara anvĂ€nds. Till exempel anvĂ€nds tvĂ„ huvudimplementationer av noden i Ethereum, en pĂ„ Go och en pĂ„ Rust, och en attack som Ă€r effektiv mot en implementation fungerar inte för den andra.
DÀrför mÄste alla processer för att starta och driva blockkedjor organiseras sÄ att vilken validator som helst, eller till och med en liten grupp av validatorer, nÀr som helst kan kasta sina datorer ut genom fönstret och gÄ dÀrifrÄn, utan att nÄgot ska gÄ sönder och de kvarvarande validatorerna mÄste fortsÀtta att effektivt stödja nÀtets drift och koppla nya validatorer. Vid starten av ett nÀtverk, nÀr en validator Àr i Europa, en annan i Sydamerika och den tredje i Asien, Àr det ganska svÄrt att uppnÄ samordnad verksamhet mellan flera dussin oberoende grupper och fÄ dem intresserade av resultatet.
Validatorer
LÄt oss förestÀlla oss starten av en hypotetisk modern blockkedja (större delen av det som beskrivs passar för blockkedjor baserade pÄ vilket modernt blockkedjesystem som helst: Ethereum, EOS, Polkadot, Cosmos och andra som tillÄter proof-of-stake-konsensus. Huvudaktörerna i sÄdana blockkedjor Àr validatorteam som installerar egna oberoende servrar som validerar och producerar nya block, och fÄr de belöningar som nÀtverket tillhandahÄller för dem som deltar i konsensus. För att starta nya nÀtverk behövs flera dussin validatorer (sÄ mÄnga kan i nulÀget mer eller mindre effektivt uppnÄ konsensus pÄ sekunder), dÀrför utlyser projektet registrering dÀr validatorer delar offentlig information om sig sjÀlva med anvÀndarna, och övertygar dem om att de avser att kvalitativt stödja det lanserade nÀtverket.
Validatorverksamhet Àr en affÀr som gör det möjligt att mycket exakt uppskatta potentiell inkomst för validatorn, snabbt flytta resurser mellan projekt, och vid framgÄng för det valda nÀtverket kan validatorn som fullvÀrdig deltagare i DAO och ansvarig person utveckla projektet, eller bara erbjuda utmÀrkt teknisk service för helt transparenta och rÀttvist tjÀnade pengar. NÀr belöningen för validatorer berÀknas försöker projekten ta hÀnsyn till validatorernas kostnader och göra belöningen per block sÄ att denna verksamhet blir lönsam, men ÀndÄ inte lÄter validatorer krossa ekonomin genom att överösa dem med pengar och beröva övriga anvÀndare av nÀtverket.
Validatorverksamhet krĂ€ver hög tillgĂ€nglighet för tjĂ€nster, vilket innebĂ€r en hög nivĂ„ av utbildning för DevOps och utvecklare samt kostsamma datorkapaciteter. Ăven utan behovet av att bryta hash i proof-of-work-nĂ€tverk Ă€r en blockchain-nod en stor tjĂ€nst som anvĂ€nder mycket minne, förbrukar mycket berĂ€kningskraft, validerar, skriver till disk och överför stora datamĂ€ngder till nĂ€tverket. För lagring av transaktionsloggar och blockkedjor för blockchain med flera tusen smĂ„ transaktioner per block krĂ€vs nu lagring frĂ„n 50 Gb och mer, och för blocken bör det vara SSD. State-databaser för blockkedjor som stöder smarta kontrakt kan redan överstiga 64 Gb RAM. Servrar med dessa specifikationer Ă€r ganska dyra, och en Ethereum- eller EOS-nod kan kosta mellan 100 och 200 $/mĂ„nad. LĂ€gg dĂ€rtill ökade kostnader för arbetstid för dygnet-runt-arbete av utvecklare och DevOps, som under lanseringsfasen löser problem Ă€ven pĂ„ nĂ€tterna, eftersom en del av validatorerna kan befinna sig pĂ„ andra sidan av jordklotet. Trots detta kan Ă€gande av en validatornod vid gynnsamma tillfĂ€llen ge betydande intĂ€kter (i fallet EOS, upp till 10 000 $ per dag).
Validatorarbete Àr endast en av de nya potentiella IT-rollerna för entreprenörer och företag. I takt med att programmerare uppfinner mer sofistikerade algoritmer för att belöna Àrlighet och straffa fusk och stöld uppstÄr tjÀnster som utför funktioner sÄsom publicering av viktiga data (orakler), övervakning (slashing av insÀttningar och straff av fuskare genom att publicera bevis pÄ bedrÀgeri), tjÀnster för tvistlösning, försÀkringar och optioner. Till och med garbage collection kan utgöra en betydande marknad inom smarta kontraktsystem, dÀr det krÀvs betalning för datalagring.
Uppstart av blockkedja problem
Ăppenheten av blockchain, som möjliggjorde fritt deltagande i nĂ€tverksarbetet frĂ„n vilket land som helst och enkel anslutning för alla script kiddies via instruktioner pĂ„ GitHub, Ă€r inte alltid en fördel. Jakten pĂ„ en ny token fĂ„r ofta validatörer att "bryta en ny mynt vid starten" i hopp om prisökning och möjlighet att snabbt sĂ€lja det som tjĂ€nats. Detta innebĂ€r ocksĂ„ att vilken anonym person som helst kan vara er validatör, och de kan rösta lika mycket som andra validatörer (men för anonyma kan det bli svĂ„rt att samla röster frĂ„n intressenter, sĂ„ skrĂ€mmande berĂ€ttelser om anonyma kryptovalutor lĂ€mnar vi Ă„t politikerna). Trots allt.
Projektteamet har en uppgift â att pĂ„ nĂ„got sĂ€tt fĂ„ in de som i framtiden kan sĂ€kerstĂ€lla stabil drift av noder, har kunskap om sĂ€kerhet, kan snabbt lösa problem, samarbeta med andra validatörer och agera tillsammans â av dessa egenskaper beror kvaliteten pĂ„ den token som nĂ€tverksdeltagare planerar att investera sina tid och resurser i. Rimliga grundare, som bedömer risker, förstĂ„r vĂ€l att vid lansering av programvaror av denna storlek mĂ„ste de nödvĂ€ndigtvis möta fel i koden, nodkonfigurationen och att stabiliteten för nĂ€tverket beror pĂ„ hur vĂ€l utvecklarna och validatörerna gemensamt hanterar sĂ„dana problem.
Teamet Àr redo att rösta i mainnet för alla validatörer, men skulle bara vilja veta vilka, vilka Àr bra? Med det största portföljet? Det har nÀstan ingen nu. Genom teamprofiler pÄ Linkedin? Erfarna devops eller sÀkerhetsspecialister kommer inte ge nÄgra profiler pÄ Linkedin. Genom uttalanden i chatten, inlÀgg och hjÀlp till andra i förberedelserna? Bra, men subjektivt och oprecist.
Under sĂ„dana förhĂ„llanden kvarstĂ„r endast en sak â nĂ„got som effektivt löser problemen för alla â ett spel dĂ€r man kan vĂ€lja de bĂ€sta validatörerna, men viktigast av allt â att testa blockchainens styrka och genomföra en omfattande fĂ€lttest av blockchain i aktiva bruksförhĂ„llanden, med förĂ€ndringar i konsensus, uppkomst och korrigering av buggar. För första gĂ„ngen presenterades denna procedur som ett spel av killarna frĂ„n projektet Cosmos, och denna idĂ© Ă€r tveklöst ett utmĂ€rkt sĂ€tt att förbereda nĂ€tverket för lanseringen av ett pĂ„litligt och felkantrt mainnet.
Game of Validators
Jag kommer att beskriva validatorer spelet sĂ„ som vi designade det för blockchain DAO.Casino (DAOBet) baserat pĂ„ en fork av EOS, som kallas Haya och har en liknande governance-mekanism. Validatorer vĂ€ljs genom omröstningar frĂ„n vilket konto som helst, dĂ€r en del av saldot som röstar pĂ„ validatorn fryses. Varje konto som har den primĂ€ra token BET pĂ„ sin balans kan rösta pĂ„ vald validator med vilken del som helst av sitt saldo. Rösterna summeras och efter det skapas en topp lista av validatorer. I olika blockkedjor Ă€r denna process organiserad pĂ„ olika sĂ€tt, och vanligtvis Ă€r det i denna del som den nya blockkedjan skiljer sig frĂ„n förĂ€ldern, och jag mĂ„ste sĂ€ga att i vĂ„rt fall rĂ€ttfĂ€rdigar EOS helt namnet âOSâ. Vi anvĂ€nder faktiskt EOS som ett grundlĂ€ggande operativsystem för att lansera en modifierad version av blockkedjan för DAOBets behov.
Jag kommer att beskriva specifika problem och hur de kan lösas inom spelet. TÀnk dig ett nÀtverk dÀr din server kan attackeras öppet, dÀr du för att behÄlla din position som validator mÄste interagera kontinuerligt med nÀtverket, frÀmja din validator och se till att den producerar block och att dessa levereras i tid till andra validatorer, annars kan validatorn bli utesluten frÄn listan.
Hur vÀljer man topp vinnare?
Det viktigaste tekniska kravet pĂ„ spelet Ă€r att dess resultat mĂ„ste vara offentligt verifierbara. Det innebĂ€r att spelets resultat: TOP vinnare, mĂ„ste baseras strikt pĂ„ data som varje deltagare kan verifiera. I ett centraliserat system skulle vi kunna mĂ€ta âuptimeâ för varje validator och belöna de som varit online mest eller som passerat mest nĂ€tverkstrafik. Vi kan samla in data om CPU-anvĂ€ndning och minne och belöna de som arbetsamt har presterat. Men varje sĂ„dan insamling av mĂ€tvĂ€rden innebĂ€r att det finns ett insamlingscentrum, och noderna Ă€r helt oberoende och kan bete sig som de vill och skicka vilka data som helst.
DĂ€rför Ă€r den naturliga lösningen att vinnarna bör bestĂ€mmas baserat pĂ„ data frĂ„n blockchain, eftersom det visar vem av validatorerna som har producerat vilken block och vilka transaktioner som ingick i det. Vi kallar detta antal Validator Points (VP), och att tjĂ€na dessa Ă€r det huvudsakliga mĂ„let för validatorerna i spelet. I vĂ„rt fall Ă€r den enklaste, lĂ€tt offentligt kontrollerbara och effektiva metrik ânyttaâ för en validator VP = antal_producerade_block_av_validator_under_en_bestĂ€md_tidsperiod.
Detta enkla val beror pĂ„ att governance i EOS redan tar hĂ€nsyn till mĂ„nga uppkomna problem, eftersom EOS Ă€r ett arv frĂ„n redan tre generationer av fungerande blockchains med stor erfarenhet av komplex nĂ€tverksförvaltning, och praktiskt taget alla problem som validatorer har med nĂ€tverket, processorn, disken leder bara till ett problem â de undertecknar fĂ€rre block och fĂ„r mindre betalt för sitt arbete, vilket leder oss tillbaka till antalet undertecknade block â för EOS Ă€r detta ett utmĂ€rkt och enkelt alternativ.
I andra blockchains kan sÀttet att rÀkna Validator Points skilja sig, till exempel för pBFT-baserade konsensus (Tendermint/Cosmos, konsensus Aura frÄn Parity Substrate), dÀr varje block mÄste undertecknas av flera validatorer, Àr det meningsfullt att rÀkna individuella validatorunderskrifter istÀllet för block; det kan ocksÄ vara meningsfullt att ta hÀnsyn till ofullstÀndiga konsensusomgÄngar som förbrukar resurser frÄn andra validatorer, sÄ det beror mycket pÄ typen av konsensus.
Hur man modellerar verkliga driftsförhÄllanden
GrundlÀggande uppgift för grundarna Àr att testa validatorerna under förhÄllanden som liknar verkligheten, utan nÄgot centraliserat kontrollsystem. Detta problem kan lösas med hjÀlp av en faucet-kontrakt som delar ut lika mÀngder av den primÀra token till validatorer och intresserade. För att erhÄlla tokens pÄ sitt saldo mÄste man skapa en transaktion och se till att nÀtverket inkluderar den i ett block. DÀrför mÄste validatorn stÀndigt fylla pÄ sitt saldo med nya tokens och rösta pÄ sig sjÀlv för att avancera i toppen. Denna aktivitet skapar en konstant belastning pÄ nÀtverket, och parametrarna kan justeras sÄ att flödet av förfrÄgningar Àr tillrÀckligt stort för att testet av nÀtverket ska vara fullstÀndigt. DÀrför bör ni planera faucet-kontraktet i förvÀg som ett viktigt verktyg för lanseringen av nÀtverket och börja anpassa dess parametrar i god tid.
BegĂ€ran av tokens frĂ„n faucet och validatorernas röstande emulerar fortfarande inte helt rĂ€ttvist arbetet hos BCh, sĂ€rskilt under extremt belastade lĂ€gen. DĂ€rför kommer blockchain-teamet oavsett att behöva skriva tillĂ€ggsbenchmarker som möjliggör att belasta nĂ€tverket. SĂ€rskilt viktiga i detta avseende Ă€r specialskapade smarta kontrakt som gör det möjligt att testa enskilda delsystem. För testning av lagring sparar kontraktet slumpmĂ€ssiga data till blockchain, och för att kontrollera nĂ€tverksresurser krĂ€ver testkontraktet en stor mĂ€ngd indata, vilket ökar transaktionsvolymen â genom att starta en ström av sĂ„dana transaktioner vid godtyckliga tidpunkter testar teamet samtidigt stabiliteten i koden och validatorernas motstĂ„ndskraft.
En separat frĂ„ga Ă€r uppdateringen av nodernas kod och genomförandet av hĂ„rdgafflar. Det krĂ€vs att validatorer har en handlingsplan, redan trĂ€nad i validatorernas spel, i hĂ€ndelse av ett fel, en sĂ„rbarhet eller en konspiration av illvilliga validatorer. HĂ€r kan man skapa system för att bevilja VP för snabb tillĂ€mpning av en hĂ„rdgaffel, till exempel genom att straffa alla validatorer som Ă€nnu inte har installerat den nya versionen av nodens kod, men detta Ă€r svĂ„rt att genomföra och komplicerar berĂ€kningen. Att simulera en situation för hastig tillĂ€mpning av en hĂ„rdgaffel kan göras genom att âbrytaâ blockchainen pĂ„ ett specifikt block. Blocktillverkningen stoppas, och i slutĂ€ndan kommer de som börjar signera blocken tidigt att vinna, sĂ„ VP baserat pĂ„ antalet signerade block passar bra hĂ€r.
Hur man informerar deltagarna om nÀtverksstatus och ÄtgÀrdar fel
Trots misstroendet mellan validatorerna, Ă€r det fördelaktigt för alla att snabbt fĂ„ aktuell information om nĂ€tverksstatus för att ta snabba beslut, dĂ€rför upprĂ€ttar projektteamet en tjĂ€nst för att samla in och visualisera olika mĂ€tvĂ€rden frĂ„n validatorernas servrar. Detta gör det möjligt att se situationen för hela nĂ€tverket samtidigt, vilket snabbt avgör vad som hĂ€nder. Dessutom Ă€r det fördelaktigt för bĂ„de validatorerna och projektet att projektteamet snabbt Ă„tgĂ€rdar upptĂ€ckta fel, sĂ„ förutom insamlingen av mĂ€tvĂ€rden Ă€r det meningsfullt att genast starta insamlingen av loggar och feldata frĂ„n validatorernas maskiner till en maskin tillgĂ€nglig för blockchain-utvecklarna. HĂ€r Ă€r det ingen som har nĂ„got att vinna pĂ„ att förvrĂ€nga information, dĂ€rför upprĂ€ttas dessa tjĂ€nster av projektteamet och kan litas pĂ„. Det Ă€r meningsfullt att samla in systemmetrik frĂ„n validatorerna och, absolut, de viktigaste metriska av sjĂ€lva blockchainen â för DAOBet Ă€r detta finaliseringstid och efterslĂ€pning av det senaste finaliserade blocket. Tack vare detta ser teamet en ökning av minnesanvĂ€ndningen pĂ„ noderna vid körning av benchmark och problem med enskilda validatorer.
Viktiga punkter för genomförandet av validatorernas spel
Det visade sig att om du vill ge officiellt tillstÄnd för validerare att attackera varandra (de kan faktiskt göra det inofficiellt) mÄste du juridiskt formulera detta som en sÀkerhetstestning, eftersom lagstiftningen i vissa lÀnder kan straffa DDoS eller nÀtverksattacker. En annan viktig frÄga Àr hur validerare ska belönas. Naturliga priser Àr projektets tokens som kommer att överföras till mainnet, men massutdelning av tokens till alla som lyckas starta en nod Àr inte heller det bÀsta alternativet. Du kommer troligen att behöva balansera mellan de tvÄ ytterligheterna:
Dela ut hela prispotten enligt förtjÀnade VP
det Àr mycket demokratiskt och gör att alla som investerat tid och resurser i validerarens spel kan tjÀna
men det lockar till sig slumpmÀssiga personer utan förberedd infrastruktur
Dela ut prispotten till top-N validerare baserat pÄ spelets resultat
vinnarna kommer troligtvis att vara de validerare som har varit mest stabila under spelets gÄng och som Àr mycket fokuserade pÄ att vinna
en del validerare kanske inte vill delta eftersom de bedömer sina vinstchanser som lÄga, sÀrskilt om det finns etablerade validerare bland deltagarna
Vilket alternativ du föredrar Àr upp till dig
Det finns ocksĂ„ en annan punkt â det Ă€r lĂ„ngt ifrĂ„n sĂ€kert att dussintals validerare kommer att rusa för att delta i spelet pĂ„ din inbjudan, och av de som bestĂ€mmer sig för att prova kommer inte alla ens att installera och starta en nod â vanligtvis har projekt under denna fas ganska begrĂ€nsad dokumentation, det uppstĂ„r fel och utvecklare som arbetar under tidspress svarar inte sĂ€rskilt snabbt pĂ„ frĂ„gor. DĂ€rför bör du Ă€ven övervĂ€ga Ă„tgĂ€rder om du inte fĂ„r det antal validerare som behövs. I det hĂ€r fallet startas de saknade validerarna av projektteamet, deltar i konsensus, men kan inte bli vinnare.
Slutsats
Sammanfattningsvis har jag försökt sammanstÀlla en lista över vad som behöver tÀnkas ut, göras och startas för en effektiv genomföring av validerarspelet
Vad som behövs för att starta ett verkligt validerarspel:
utveckla din egen blockchain đ
- skapa och lansera en web-grÀnssnitt och tillhandahÄlla CLI för att rösta pÄ validerare
- se möjliggöra att metrik frÄn den aktiverade validatornoden kan skickas till en centraliserad tjÀnst (till exempel Prometheus)
- starta en server för insamling av metrik (Prometheus + Grafana) för validatorernas spel
- komma pÄ hur Validator Points (VP) ska rÀknas
- utveckla ett offentligt skript som berÀknar VP för validatorer baserat pÄ data frÄn blockkedjan
- utveckla ett webgrÀnssnitt för att visa topplistan av validatorer och statusen för validatorernas spel (hur mycket tid som Àr kvar, hur mÄnga VP var och en har, etc.)
- utveckla och automatisera starten av valfritt antal egna noder, designa processen för att koppla validatorer till spelet (nÀr och hur man stÀnger av sina noder, lÀmnar och tar tillbaka röster för dem)
- berÀkna hur mÄnga tokens som behöver delas ut och utveckla en kontrakt-faucet
- skapa ett benchmark-skript (tokenöverföringar, massiv anvÀndning av lagring, massiv anvÀndning av nÀtverket)
- samla alla deltagare i en chatt för snabb kommunikation
- starta blockkedjan lite innan spelet börjar
- vÀnta pÄ startblocket, börja spelet
- testa nÀtverket med flera typer av transaktioner
- genomföra en hÄrd gaffel
- Àndra listan över validatorer
- upprepa punkt 13, 14, 15 i olika ordningar, för att upprÀtthÄlla nÀtverkets stabilitet
- vÀnta pÄ det slutgiltiga blocket, avsluta spelet, rÀkna VP
Det bör noteras att validatorers spel Ă€r en ny historia och har genomförts endast ett par gĂ„nger, sĂ„ detta text bör inte ses som en fĂ€rdig handbok. Det finns inga motsvarigheter i dagens IT-bransch â tĂ€nk dig att banker tĂ€vlar med varandra innan en betalningssystem lanseras, om vem som ska genomföra kundtransaktionerna bĂ€st. Traditionella metoder kommer troligen inte att hjĂ€lpa dig att skapa stora decentraliserade nĂ€tverk, sĂ„ utforska nya affĂ€rsmodeller, genomför dina spel, identifiera de vĂ€rdiga, belöna dem och lĂ„t dina distribuerade system fungera snabbt och stabilt.
KĂ€lla: habr.com
