Så ditt team har avslutat alfaversionen av din blockchain, och det är dags att starta testnet och sedan mainnet. Du har en riktig blockkedja, med oberoende deltagare, en bra ekonomisk modell, säkerhet, du har utformat styrning och nu är det dags att prova allt detta i handling. I en idealisk kryptoanarkisk värld lägger du uppkomstblocket på nätverket, nodens slutliga kod och validerarna själva startar allt, höjer alla hjälptjänster och allt händer av sig själv. Men det här är i en fiktiv värld, men i den verkliga världen måste teamet förbereda en hel del extra programvara och olika manipulationer för att hjälpa validerare att starta ett stabilt nätverk. Det här är vad den här artikeln handlar om.
Att lansera nätverk baserade på konsensus av typen "proof-of-stake", där validerare bestäms av rösterna från systemtokeninnehavare, är en ganska specifik händelse, eftersom det inte är lätt att lansera traditionella, centralt hanterade system med tiotals och hundratals servrar. uppgift i sig, och blockkedjan måste startas med ansträngning lojala men oberoende deltagare. Och om administratörer i ett företag vid uppstart har full tillgång till alla maskiner, loggar, allmän övervakning, så kommer validatorer inte att tillåta någon att komma åt deras servrar och kommer troligen att föredra att bygga sin infrastruktur självständigt, eftersom det styr åtkomsten till validatorns huvudsakliga tillgångar - insatser väljarna. Det är detta beteende som gör det möjligt att bygga distribuerade säkra nätverk - oberoende av molnleverantörerna som används, virtuella och "baremetal" servrar, olika operativsystem, allt detta gör att du kan göra attacker på ett sådant nätverk extremt ineffektiva - för mycket annorlunda programvara används. Till exempel använder Ethereum två huvudnodimplementeringar, i Go och i Rust, och en attack som är effektiv för en implementering fungerar inte för den andra.
Därför måste alla processer för att starta och driva blockkedjor organiseras på ett sådant sätt att vilken validator som helst, eller till och med en liten grupp validerare, när som helst kan kasta ut sina datorer genom fönstret och gå därifrån, samtidigt som ingenting ska gå sönder och de återstående validerarna bör fortsätta att effektivt stödja driftnätverket och ansluta nya validerare. När man lanserar ett nätverk, när en validator är i Europa, den andra i Sydamerika och den tredje i Asien, är det ganska svårt att uppnå det samordnade arbetet från flera dussin oberoende grupper och intressera dem som ett resultat.
Validatorer
Låt oss föreställa oss lanseringen av en hypotetisk modern blockkedja (det mesta av det som beskrivs är lämpligt för blockkedjor baserade på vilken modern familj av blockkedjor som helst: Ethereum, EOS, Polkadot, Cosmos och andra, som ger proof-of-stake konsensus. Huvudpersonerna i sådana blockkedjor är valideringsteam, engagerade i att installera sina egna oberoende servrar som validerar och producerar nya block, och tar emot belöningar från nätverket för de som deltar i konsensus. För att lansera nya nätverk krävs flera dussin validatorer (så många kan nu mer eller mindre effektivt nå konsensus på några sekunder), så projektet tillkännager registrering, där validatorer delar offentlig information om sig själva med användarna och övertygar dem om att de kommer att tillhandahålla högkvalitativa tjänster till det lanserade nätverket.
Validering är en verksamhet som låter dig extremt noggrant bedöma validerarens potentiella inkomst, snabbt överföra makt mellan projekt, och om nätverket han valt är framgångsrikt kan valideraren, som en fullvärdig deltagare i DAO och en ansvarig person, utveckla projektet, eller helt enkelt tillhandahålla utmärkt teknisk service för helt transparenta, ärligt intjänade pengar. När man beräknar belöningen för validerare försöker projekt ta hänsyn till kostnaderna för validerare och göra belöningen för block så att denna verksamhet är lönsam, men samtidigt tillåter inte validerare att få ner ekonomin genom att översvämma dem med pengar och beröva andra nätverksanvändare det.
Validatorernas verksamhet kräver att säkerställa hög feltolerans för tjänster, vilket innebär en hög utbildningsnivå för devops och utvecklare och dyra datorresurser. Även utan att behöva bryta hash i proof-of-work-nätverk är en blockchain-nod en stor tjänst som tar upp mycket minne, förbrukar många beräkningar, validerar, skriver till disk och skickar stora mängder data till nätverket . För att lagra transaktionsloggar och blockkedjor för en blockkedja med flera tusen små transaktioner i ett block krävs nu lagring på 50 Gb eller mer och för block måste det vara en SSD. Statlig databas över blockkedjor med stöd för smarta kontrakt kan redan överstiga 64 Gb RAM. Servrar med de nödvändiga egenskaperna är ganska dyra; en Ethereum- eller EOS-nod kan kosta från 100 till 200 $/månad. Lägg till detta de ökade lönerna för dygnet-runt-arbete av utvecklare och devops, som under lanseringsperioden löser problem även på natten, eftersom vissa validatorer lätt kan placeras på en annan hemisfär. Men vid rätt tillfälle kan ägandet av en valideringsnod ge allvarliga inkomster (i fallet med EOS, upp till $10 000 per dag).
Validering är bara en av de nya potentiella IT-rollerna för entreprenörer och företag; i takt med att programmerare kommer på mer och mer sofistikerade algoritmer som belönar ärlighet och straffar bedrägerier och stöld, dyker det upp tjänster som utför funktionerna att publicera viktig data (orakel), utföra övervakning (insättning slashing och straff fuskare genom att publicera bevis på bedrägeri), tvistlösningstjänster, försäkringar och alternativ, även sophämtning är en potentiellt stor marknad inom smarta avtalssystem där det är nödvändigt att betala för datalagring.
Problem med att lansera en blockchain
Öppenheten i blockkedjan, som gjorde det möjligt för datorer från vilket land som helst att fritt delta i nätverket och enkelheten att ansluta valfri skriptbarn till nätverket enligt instruktionerna på GitHub, är inte alltid en fördel. Jakten på en ny token tvingar ofta validerare att "bryta ett nytt mynt i början", i hopp om att kursen kommer att stiga och möjligheten att snabbt kasta av sig sina intäkter. Detta betyder också att din validator kan vara vem som helst, även en anonym person, du kan rösta på honom på samma sätt som för andra validatorer (dock kommer det att vara svårt för en anonym person att samla in intressenters röster för sig själv, så vi" kommer att lämna de läskiga berättelserna om anonyma kryptovalutor till politiker). Ändå
Projektgruppen har en uppgift - att på något sätt komma in i sitt nätverk de som i framtiden kan säkerställa en stabil drift av noder, förstå säkerhet, veta hur man snabbt löser problem, samarbeta med andra validatorer och agera tillsammans - kvaliteten på det mycket beror helt på dessa egenskaper, en symbol som nätverksdeltagare kommer att investera sin tid och sina resurser i. Adekvata grundare, när de bedömer riskerna, förstår väl att när du lanserar programvara av denna storlek, kommer du definitivt att behöva stöta på fel i koden och konfigurationen av noder, och att stabiliteten i nätverket beror på hur väl utvecklare och validerare kommer att lösa gemensamt sådana problem.
Teamet är redo att rösta på mainnet för alla validerare, bara för att veta vilka, vilka är bra? Den största portföljen? Det är nästan ingen som har det nu. Baserat på lagets Linkedin-profiler? Erfarna devops eller säkerhetsspecialister kommer inte att ge dig några Linkedin-profiler. Enligt uttalanden i chatt, inlägg och att hjälpa andra under förberedelsefasen? Bra, men subjektivt och felaktigt.
Under sådana förhållanden återstår en sak - något som löser allas problem väl - ett spel där det kommer att vara möjligt att välja de bästa validatorerna, men det viktigaste är att testa blockkedjan för styrka och genomföra ett fullskaligt stridstest av blockchain under förhållanden för aktiv användning, förändringar i konsensus, utseende och korrigering av fel . Denna procedur presenterades först som ett spel av killarna från Cosmos-projektet, och denna idé är utan tvekan ett utmärkt sätt att förbereda nätverket för lanseringen av ett pålitligt och feltolerant huvudnät
Game of Validators
Jag kommer att beskriva spelet med validerare som vi designade det för DAO.Casino (DAOBet) blockkedjan baserat på EOS-gaffeln, som kallas Haya och har en liknande styrningsmekanism - validatorer väljs genom att rösta från vilket konto som helst, där en del av saldot som användes för att rösta på validatorn är fryst. Alla konton som har den huvudsakliga BET-token på sitt saldo kan rösta på den valda valideraren med vilken del av sitt saldo som helst. Rösterna summeras och de bästa validerarna byggs utifrån resultaten. I olika blockkedjor är denna process organiserad på olika sätt, och vanligtvis är det i den här delen som den nya blockkedjan skiljer sig från den överordnade, och jag måste säga att i vårt fall motiverar EOS helt "OS" i dess namn, vi använder verkligen EOS som basoperativsystem för distribution av en modifierad version av blockkedjan för DAOBet-uppgifter.
Jag kommer att beskriva individuella problem och hur de kan lösas inom spelet. Låt oss föreställa oss ett nätverk där din server öppet kan attackeras, där du för att behålla positionen som en validator behöver kontinuerligt interagera med nätverket, marknadsföra din validator och se till att den producerar block och att de levereras till andra validatorer på tid, annars kommer valideraren att kastas ut från listan.
Hur väljer man toppvinnare?
Det huvudsakliga tekniska kravet för spelet är att dess resultat ska vara offentligt verifierbara. Detta innebär att resultatet av spelet: TOP vinnare, måste utformas strikt på basis av data som kan verifieras av alla deltagare. I ett centraliserat system kunde vi mäta "upptiden" för varje validator och belöna de som var online mest eller passerade den maximala nätverkstrafiken. Du kan samla in data om processor- och minnesbelastning och belöna de som har jobbat bra. Men varje sådan insamling av mått innebär att det finns ett insamlingscenter, och noderna är alla oberoende och kan bete sig som de vill och skicka vilken data som helst.
Därför är den naturliga lösningen att vinnarna ska fastställas utifrån data från blockkedjan, eftersom den kan användas för att se vilken validator som producerade vilket block och vilka transaktioner som ingick i det. Vi kallade detta nummer för Validator Points (VP), och att tjäna dem är huvudmålet för validatorer i spelet. I vårt fall är det enklaste, lätt offentligt verifierbara och effektiva måttet på en validators "användbarhet" VP = antalet block som produceras av valideraren under en given tidsperiod.
Detta enkla val beror på det faktum att styrning i EOS redan tillhandahåller många nya problem, eftersom EOS är arvtagaren till tre generationer av faktiskt fungerande blockkedjor med lång erfarenhet av komplex nätverkshantering, och nästan alla valideringsproblem med nätverket, processorn, disk leder till bara ett problem - han signerar färre block, får mindre betalt för arbetet, vilket återigen leder oss helt enkelt till antalet signerade block - för EOS är detta ett utmärkt och enkelt alternativ.
För andra blockkedjor kan sättet som Validator Points beräknas skilja sig åt, till exempel för pBFT-baserade konsensus (Tendermint/Cosmos, Aura consensus från Parity Substrate), där varje block måste signeras av flera validatorer, är det vettigt att räkna individuella validatorer signaturer snarare än block Det kan vara meningsfullt att ta hänsyn till ofullständiga konsensusrundor, vilket slösar med andra validatorers resurser, i allmänhet beror detta mycket på typen av konsensus.
Hur man simulerar verkliga driftsförhållanden
Grundarnas uppgift är att testa validatorer under förhållanden nära verkligheten, utan att ha någon centraliserad kontroll. Detta problem kan lösas med hjälp av ett krankontrakt, som distribuerar lika stora mängder av huvudtoken till validerare och alla andra. För att ta emot tokens på ditt saldo måste du skapa en transaktion och se till att nätverket inkluderar den i blocket. För att vinna måste en validerare ständigt fylla på sin balans med nya tokens och rösta på sig själv och promota sig själv till toppen. Denna aktivitet skapar en konstant belastning på nätverket, och parametrarna kan väljas så att flödet av förfrågningar är tillräckligt allvarligt för ett fullständigt nätverkstest. Planera därför krankontraktet i förväg som ett viktigt verktyg för att starta nätverket och börja välja dess parametrar i förväg.
Att begära tokens från en kran och validera röster efterliknar fortfarande inte driften av en stridsspets, särskilt i extremt belastade lägen. Därför kommer blockchain-teamet fortfarande att behöva skriva ytterligare benchmarks på ett eller annat sätt för att ladda nätverket. En speciell roll i detta spelas av speciellt skapade smarta kontrakt som tillåter testning av ett separat delsystem. För att testa lagring lagrar kontraktet slumpmässiga data i blockkedjan, och för att testa nätverksresurser kräver testkontraktet en stor mängd indata, vilket ökar mängden transaktioner - genom att starta ett flöde av sådana transaktioner vid godtyckliga tidpunkter, teamet testar samtidigt kodens stabilitet och styrkan hos validatorerna.
Ett separat problem är att uppdatera nodkoden och genomföra hårda gafflar. Det krävs att i händelse av en bugg, sårbarhet eller maskopi av skadliga validerare, ska validerare ha en handlingsplan som redan har utarbetats i validerarnas spel. Här kan du komma med scheman för att samla VP för att snabbt applicera en hård gaffel, till exempel genom att bötfälla alla validerare som ännu inte har rullat ut en ny version av nodkoden, men detta är svårt att implementera och komplicerar beräkningen. Du kan simulera en nödsituation med en hård gaffel genom att artificiellt "bryta" blockkedjan på ett givet block. Blockproduktionen stannar, och i slutändan blir vinnarna de som hoppar in först och börjar signera block, så VP baserat på antalet signerade block passar bra här.
Hur man informerar deltagare om nätverksstatus och åtgärdar fel
Trots misstroendet mellan validatorer, är snabb mottagning av aktuell information om nätverkets tillstånd fördelaktigt för alla för att fatta beslut snabbare, så projektteamet tar fram en tjänst för att samla in och visualisera många mätvärden från valideringsservrar, som gör att du kan se situationen samtidigt för hela nätverket, vilket gör att du snabbt kan avgöra vad som händer. Det är också fördelaktigt för både validerarna och projektet att projektgruppen snabbt korrigerar de fel som hittats, så förutom att samla in mätvärden är det vettigt att omedelbart börja samla in loggar och feldata från validatorernas maskiner på en maskin som är tillgänglig för blockchain utvecklare. Här är det inte fördelaktigt för någon att förvränga information, så dessa tjänster är utvecklade av projektgruppen och kan lita på. Det är vettigt att samla in systemmått från validerare, och naturligtvis är de viktigaste mätvärdena för själva blockkedjan - för DAOBet - slutförandetiden och fördröjningen för det senast slutförda blocket. Tack vare detta ser teamet en ökning av minnesförbrukningen på noder när man kör benchmark, problem med individuella validerare
Viktiga poäng för att genomföra ett valideringsspel
Som det visar sig, om du officiellt vill tillåta validatorer att attackera varandras maskiner (inofficiellt kan de göra detta ändå), måste du separat formulera detta juridiskt som säkerhetstestning, eftersom DDoS eller nätverksattacker enligt lagarna i vissa länder kan vara straffad. En annan viktig fråga är hur man belönar validerare. Naturliga priser är projekttokens, som kommer att överföras till huvudnätet, men en massiv distribution av tokens till alla som kunde starta en nod är inte heller det bästa alternativet. Troligtvis måste du balansera mellan två extrema alternativ:
Fördela hela prispotten enligt intjänad VP
det är väldigt demokratiskt och låter alla som har investerat tid och resurser i valideringsspelet att tjäna pengar
men lockar slumpmässiga människor till spelet utan förberedd infrastruktur
Dela ut den högsta N-prispotten till validerare baserat på resultatet av spelet
Vinnarna kommer med största sannolikhet att vara de validerare som varade mest konsekvent under spelet och som är mycket strikt fast beslutna att vinna
vissa validerare kommer inte att vilja delta, de bedömer inte deras chanser att vinna, speciellt om deltagarna inkluderar ärevördiga validerare
Vilket alternativ du ska välja är upp till dig
Det finns en sak till - det är inte alls ett faktum att dussintals validerare kommer att skynda sig att delta i spelet vid ditt samtal, och av de som bestämmer sig för att försöka, kommer inte alla ens att installera och starta noden - vanligtvis, i detta skede har projekten ganska sparsam dokumentation, fel uppstår och utvecklare som arbetar under tidspress svarar inte på frågor särskilt snabbt. Därför, innan du startar spelet, är det också nödvändigt att tillhandahålla åtgärder om det erforderliga antalet validerare inte uppnås. I det här fallet, i början av spelet, lanseras de saknade validerarna av projektgruppen, deltar i konsensus, men kan inte vara vinnare.
Slutsats
Sammanfattningsvis försökte jag från ovanstående sammanställa en lista över vad som behöver tänkas ut, göras och lanseras för att effektivt genomföra ett valideringsspel
Vad du behöver göra för att köra ett riktigt valideringsspel:
utveckla din egen blockchain :)
- skapa och skapa ett webbgränssnitt och tillhandahålla en CLI för att rösta på validerare
- se till att mätvärden från en körande valideringsnod kan skickas till en centraliserad tjänst (till exempel Prometheus)
- skapa en mätvärdesinsamlingsserver (Prometheus + Grafana) för valideringsspelet
- ta reda på hur Validator Points (VP) kommer att beräknas
- utveckla ett offentligt skript som beräknar validator VP baserat på data från blockkedjan
- utveckla ett webbgränssnitt för att visa de bästa validerarna och spelstatusen för validatorerna (hur mycket tid är kvar till slutet, vem har hur mycket VP, etc.)
- utveckla och automatisera lanseringen av ett godtyckligt antal av dina egna noder, designa processen för att koppla validatorer till spelet (när och hur du kopplar bort dina noder, skickar in och tar bort röster för dem)
- beräkna hur många polletter som behöver utfärdas och utveckla ett krankontrakt
- göra ett benchmark-skript (tokenöverföringar, massiv lagringsanvändning, massiv nätverksanvändning)
- samla alla deltagare i en chatt för snabb kommunikation
- starta blockkedjan lite tidigare än spelets början
- vänta på startblocket, starta spelet
- testa nätverket med flera typer av transaktioner
- kavla ut en hård gaffel
- ändra listan över validerare
- upprepa steg 13,14,15, XNUMX, XNUMX i olika ordningsföljder, bibehåll nätverksstabilitet
- vänta på sista blocket, avsluta spelet, räkna VP
Det måste sägas att spelet med validerare är en ny historia, och det genomfördes bara ett par gånger, så du bör inte ta den här texten som en färdig guide. Det finns inga analoger i den moderna IT-verksamheten – föreställ dig att banker, innan de lanserar ett betalningssystem, tävlar med varandra för att se vem som kommer att vara bäst på att genomföra kundtransaktioner. Traditionella tillvägagångssätt kommer sannolikt inte att hjälpa dig att skapa stora decentraliserade nätverk, så behärska nya affärsmodeller, kör dina spel, identifiera de värdiga, belöna dem och håll dina distribuerade system igång snabbt och stabilt.
Källa: will.com