🥇Wat is de validator game of "hoe een proof-of-stake blockchain op te starten"

Dus, uw team heeft de alpha-versie van uw blockchain afgerond, en het is tijd om de testnet te lanceren, en vervolgens de mainnet. U heeft een echte blockchain, met onafhankelijke deelnemers, een goed economisch model, beveiliging, u heeft governance ontworpen en nu is het tijd om dit alles in de praktijk te brengen. In de ideale crypto-anarchistische wereld publiceert u het genesis block op het netwerk, de definitieve code van de node, en de validators starten alles zelf op, brengen alle ondersteunende diensten online en alles gebeurt vanzelf. Maar dat is in de fantasiewereld; in de echte wereld moet het team een heleboel ondersteunende software en verschillende handelingen voorbereiden om de validators te helpen een stabiel netwerk op te starten. Dit is waar dit artikel over gaat.

Het opzetten van netwerken op basis van consensusmechanismen zoals 'proof-of-stake', waarbij validators worden bepaald door stemmen van de tokenhouders van het systeem, is een vrij specifieke onderneming, aangezien zelfs het opzetten van traditionele, centraal beheerde systemen met tientallen en honderden servers zelf al een moeilijke taak is, en de blockchain moet worden opgestart door de inspanningen van loyale, maar onafhankelijke deelnemers. En als in een bedrijf, bij de lancering, de beheerders volledige toegang hebben tot alle machines, logs, en algemene monitoring, dan zullen de validators niemand toestaan tot hun servers en zullen ze waarschijnlijk de voorkeur geven aan het zelf opbouwen van hun infrastructuur, aangezien dit de toegang tot de belangrijkste activa van de validator — de stakes van de stemmers — controleert. Dit soort gedrag maakt het mogelijk om gedistribueerde veilige netwerken te bouwen — onafhankelijkheid van de gebruikte cloudproviders, virtuele en 'bare-metal' servers, verschillende besturingssystemen, dit alles maakt aanvallen op zo'n netwerk extreem ondoeltreffend — er wordt teveel verschillende software gebruikt. Bijvoorbeeld, in Ethereum worden twee hoofdimplementaties van de node gebruikt, in Go en in Rust, en een aanval die effectief is voor de ene implementatie werkt niet voor de andere.

Daarom moeten alle processen voor het starten en exploiteren van blockchains zo worden georganiseerd dat elke validator, of zelfs een kleine groep validators, op elk moment hun computers uit het raam kunnen gooien en weg kunnen gaan, zonder dat er iets kapot gaat en de overgebleven validators de werking van het netwerk effectief moeten blijven ondersteunen en nieuwe validators moeten aansluiten. Bij het starten van het netwerk, wanneer er één validator in Europa is, de tweede in Zuid-Amerika en de derde in Azië, is het vrij moeilijk om een gecoördineerde werking van verschillende tientallen onafhankelijke groepen te bereiken en hen te interesseren in het resultaat.

Validators

Laten we ons de lancering van een hypothetische moderne blockchain voorstellen (de meeste van wat hier wordt beschreven, geldt voor blockchains die zijn gebaseerd op elk modern blockchain-familiesysteem: Ethereum, EOS, Polkadot, Cosmos en anderen, die een proof-of-stake consensus gebruiken). De belangrijkste actoren in dergelijke blockchains zijn validatorenteams die hun eigen onafhankelijke servers installeren, die nieuwe blokken valideren en produceren, en de beloningen ontvangen die het netwerk biedt aan degenen die deelnemen aan de consensus. Voor het starten van nieuwe netwerken zijn er enkele tientallen validators nodig (zodat ze meer of minder effectief consensus kunnen bereiken binnen enkele seconden), daarom kondigt het project registratie aan, waarbij validators openbare informatie over zichzelf delen met gebruikers, en hen ervan overtuigen dat ze de opstartende netwerk van hoogwaardige service willen voorzien.

Validatorenwerk is een bedrijf dat het mogelijk maakt om het potentiële inkomen van een validator zeer nauwkeurig te beoordelen, snel middelen tussen projecten te verplaatsen, en in het geval van succes van het geselecteerde netwerk kan de validator als volledig deelnemende DAO-lid en verantwoordelijke partij het project ontwikkelen, of gewoon uitstekende technische service bieden voor volledig transparante eerlijk verdiende geld. Bij het berekenen van de beloning aan validators proberen projecten de kosten van de validators in overweging te nemen en de beloning voor blokken zo te maken dat deze business winstgevend is, maar zonder validators in staat te stellen de economie in te storten door hen te overladen met geld en de andere gebruikers van het netwerk te benadelen.

De zakelijke validatie vereist hoge beschikbaarheid van diensten, wat betekent dat er een hoog niveau van voorbereiding van devops en ontwikkelaars nodig is, evenals dure computermiddelen. Zelfs zonder de noodzaak om hashes te minen in proof-of-work netwerken, is een blockchain-node een grote dienst die veel geheugen gebruikt, veel rekenkracht verbruikt, gegevens valideert, op de schijf vastlegt en grote gegevenshoeveelheden naar het netwerk verzendt. Voor het opslaan van de transactiegeschiedenis en blokketens voor blockchains met duizenden kleine transacties in een blok, is nu een opslagcapaciteit van meer dan 50 Gb vereist, en voor blokken moet dit een SSD zijn. De statusdatabase van blockchains met smart contract-ondersteuning kan al meer dan 64 Gb RAM vereisen. Servers met de vereiste specificaties zijn behoorlijk duur; een node van Ethereum of EOS kan kosten tussen de 100 en 200 $/maand. Voeg hierbij de verhoogde loonkosten voor de 24/7 beschikbaarheid van ontwikkelaars en devops die tijdens de lancering zelfs 's nachts problemen oplossen, aangezien een deel van de validators zich gemakkelijk op een andere hemisphere kan bevinden. Desondanks kan bezit van een validator-node op gunstige momenten aanzienlijke inkomsten opleveren (tot 10.000 $ per dag in het geval van EOS).

Validatie is slechts één van de nieuwe potentiële IT-rollen voor ondernemers en bedrijven. Naarmate programmeurs steeds geavanceerdere algoritmen bedenken die eerlijkheid belonen en bedrog en diefstal bestraffen, ontstaan er diensten die belangrijke gegevens (orakels) publiceerden, toezicht houden (slashing van depots en bestraffing van bedrog door het publiceren van bewijs van bedrog), geschillenbeslechtingsdiensten, verzekeringen en opties, zelfs garbage collection is een potentieel grote markt in systemen met smart contracts waar men moet betalen voor dataopslag.

Startproblemen van blockchain

De openheid van de blockchain, die het mogelijk maakt dat iedereen uit verschillende landen vrij kan deelnemen aan het netwerk van computers en de eenvoud van het aansluiten op het netwerk volgens instructies op GitHub, is niet altijd een voordeel. De jacht op een nieuwe token dwingt validators vaak om 'bij de start een nieuwe munt te minen', in de hoop dat de waarde stijgt en ze hun verdiende munten snel kunnen verkopen. Dit betekent ook dat uw validator iedereen kan zijn, zelfs anoniem, en dat er op hen gestemd kan worden zoals op andere validators (hoewel het voor een anonieme persoon moeilijk zal zijn om stemmen van stakeholders te verzamelen, laten we de angstaanjagende verhalen over anonieme cryptocurrencies aan politici). Niettemin

Het projectteam heeft de taak om op een of andere manier degenen in hun netwerk te krijgen die in de toekomst in staat zijn om een stabiele werking van de nodes te garanderen, verstand van beveiliging hebben, snel problemen kunnen oplossen, samenwerken met andere validators en gezamenlijk handelen — deze kwaliteiten zijn van cruciaal belang voor de kwaliteit van de token waarin de deelnemers van het netwerk hun tijd en middelen willen investeren. Adequate oprichters begrijpen, terwijl ze de risico's evalueren, goed dat ze bij de lancering van software van deze omvang onvermijdelijk met fouten in de code en de configuratie van de nodes te maken zullen krijgen, en dat de stabiliteit van het netwerk afhankelijk is van hoe goed ontwikkelaars en validators gezamenlijk dergelijke problemen zullen oplossen.

Het team is bereid om in de mainnet op elke validator te stemmen, maar het zou goed zijn om te weten op welke, welke zijn goed? Met het grootste portfolio? Dat heeft momenteel bijna niemand. Op basis van de teamprofielen op Linkedin? Ervaren DevOps-ers of beveiligingsspecialisten zullen geen profielen op Linkedin met u delen. Op basis van uitspraken in de chat, berichten en hulp aan anderen tijdens de voorbereidingen? Goed, maar subjectief en onnauwkeurig.

Onder zulke omstandigheden blijft er maar één optie over — iets dat de problemen van iedereen goed oplost — een spel waarin de beste validators gekozen kunnen worden, maar het belangrijkste is om de blockchain op de proef te stellen en een grootschalige field test van de blockchain uit te voeren onder actieve omstandigheden, veranderingen in consensus, en het opduiken en oplossen van fouten. Voor het eerst werd deze procedure gepresenteerd als een spel door de jongens van het project Cosmos, en dit idee is ongetwijfeld een uitstekende manier om het netwerk voor te bereiden op de lancering van een betrouwbare en foutbestendige mainnet.

Game of Validators

Ik zal het validatorspel beschrijven zoals we het hebben ontworpen voor de DAO.Casino (DAOBet) blockchain op basis van de EOS-fork, die Haya wordt genoemd en een vergelijkbaar governance-mechanisme heeft — validators worden gekozen via stemmen vanuit elk account, waarbij een deel van het saldo dat wordt gestemd voor een validator wordt bevroren. Elk account dat de primaire token BET op zijn saldo heeft, kan stemmen op de gekozen validator met elk deel van zijn saldo. De stemmen worden opgeteld en aan het einde wordt er een top van validators samengesteld. In verschillende blockchains is dit proces op verschillende manieren georganiseerd, en meestal is het juist op dit punt dat de nieuwe blockchain verschilt van de ouderlijke, en ik moet zeggen dat in ons geval EOS de “OS” in zijn naam volledig rechtvaardigt; we gebruiken EOS inderdaad als het basisbesturingssysteem voor het implementeren van een gemodificeerde versie van de blockchain voor de behoeften van DAOBet.

Ik zal afzonderlijke problemen beschrijven en hoe die binnen het spel kunnen worden opgelost. Laten we een netwerk voorstellen waarin jouw server openlijk kan worden aangevallen, waar je om je positie als validator te behouden voortdurend interactie met het netwerk moet hebben, je validator moet promoten en ervoor moet zorgen dat hij blokken produceert die tijdig aan de andere validators worden geleverd, anders wordt de validator uit de lijst verwijderd.

Hoe kies je de topwinnaars?

De belangrijkste technische vereiste voor het spel is dat de resultaten publiekelijk controleerbaar zijn. Dit betekent dat de spelresultaten: TOP winnaars, strikt moeten worden gevormd op basis van gegevens die door elke deelnemer kunnen worden geverifieerd. In een gecentraliseerd systeem zouden we de 'uptime' van elke validator kunnen meten en degenen belonen die het meest online waren of de meeste netwerkverkeer door hun server lieten gaan. We kunnen gegevens verzamelen over CPU-belasting, geheugen en degenen belonen die hard hebben gewerkt. Maar elke dergelijke metingenverzameling betekent het bestaan van een verzamelcentrum, en de nodes zijn allemaal onafhankelijk en kunnen zich gedragen zoals ze willen en willekeurige gegevens verzenden.

Daarom is de natuurlijke oplossing dat winnaars moeten worden bepaald op basis van gegevens uit de blockchain, aangezien je daarmee kunt zien welke validator welke blok heeft geproduceerd en welke transacties erin zijn opgenomen. We hebben dit aantal Validator Points (VP) genoemd, en het verdienen ervan is het belangrijkste doel van de validators in het spel. In ons geval is de eenvoudigste, gemakkelijk publiek verifieerbare en effectieve metriek voor de 'nuttigheid' van een validator VP = aantal_gegenereerde_blokken_van_de_validator in een bepaalde tijdsperiode.

Deze eenvoudige keuze is te wijten aan het feit dat governance in EOS al vele opkomende problemen voorziet, omdat EOS de opvolger is van al drie generaties werkelijk werkende blockchains met veel ervaring in complexe netwerkbeheer, en vrijwel elk probleem van een validator met het netwerk, de processor of de schijf leidt gewoonlijk tot één probleem: hij ondertekent minder blokken, ontvangt minder betaling voor zijn werk, wat ons weer terugbrengt naar het aantal ondertekende blokken - voor EOS is dit een uitstekende en eenvoudige optie.

Bij andere blockchains kan de manier van het berekenen van Validator Points verschillen; bijvoorbeeld voor pBFT-gebaseerde consensus (Tendermint/Cosmos, consensus Aura uit Parity Substrate), waar elk blok door meerdere validators moet worden ondertekend, is het zinvol om afzonderlijke handtekeningen van validators te tellen in plaats van blokken, en het kan zinvol zijn om niet-voltooide consensusrondes mee te tellen die middelen van andere validators verbruiken; dit hangt sterk af van het type consensus.

Hoe echte exploitatiewaarden te modelleren

De taak van de oprichters is om de validators te controleren onder omstandigheden die dicht bij de realiteit liggen, zonder enige gecentraliseerde controle. Dit probleem kan worden opgelost met behulp van een faucet-contract dat gelijke hoeveelheden van de hoofdtoken aan validators en geïnteresseerden uitdeelt. Om tokens aan de balans toe te voegen, moet een transactie worden gevormd, en ervoor worden gezorgd dat het netwerk deze in een blok opneemt. Hierdoor moet de validator zijn balans voortdurend aanvullen met nieuwe tokens en op zichzelf stemmen om in de top te komen. Deze activiteit creëert een constante belasting voor het netwerk, en de parameters kunnen zo worden afgestemd dat de stroom van verzoeken groot genoeg is voor een volledige netwerktest. Daarom is het belangrijk om het faucet-contract van tevoren te plannen als een essentieel hulpmiddel voor het lanceren van het netwerk en de parameters tijdig te selecteren.

Het aanvragen van tokens bij de faucet en het stemmen van validators emuleert nog steeds niet volledig eerlijk het functioneren van de blockchain, vooral niet in extreem drukke modus. Daarom zal het blockchain-team hoe dan ook aanvullende benchmarks moeten schrijven om het netwerk te belasten. Hierbij spelen speciaal van tevoren gemaakte smart contracts een belangrijke rol, waarmee afzonderlijke subsysteemtests mogelijk zijn. Voor het testen van opslag slaat het contract willekeurige gegevens op in de blockchain, en om de netwerkbronnen te controleren, vereist het testcontract een grote hoeveelheid invoergegevens, waardoor het volume van de transacties toeneemt — door dergelijke transacties op willekeurige tijdstippen te starten, test het team tegelijkertijd de stabiliteit van de code en de veerkracht van de validators.

Een apart onderwerp is de update van noden en het uitvoeren van hard forks. Het is vereist dat, in het geval van een bug, kwetsbaarheid of samenzwering van kwaadaardige validators, de validators een actieplan hebben, dat al in de validatoren-gemeenschap is geoefend. Hier kunnen we schema's bedenken voor het toekennen van VP voor het snel implementeren van een hard fork, bijvoorbeeld door alle validators te straffen die de nieuwe versie van de noden-code nog niet hebben geïnstalleerd, maar dit is moeilijk te realiseren, omdat het de berekeningen bemoeilijkt. We kunnen de situatie van een nood-hard fork kunstmatig simuleren door de blockchain op een bepaald blok te

Hoe deelnemers te informeren over de staat van het netwerk en fouten te verhelpen

Ondanks het wantrouwen tussen validators, is het voordelig voor iedereen om tijdig actuele informatie over de staat van het netwerk te ontvangen, zodat we sneller beslissingen kunnen nemen. Daarom richt het projectteam een service op voor het verzamelen en visualiseren van verschillende metrics van de validators' servers, die tegelijkertijd de situatie voor het hele netwerk zichtbaar maakt, zodat we snel kunnen bepalen wat er aan de hand is. Ook is het voor zowel de validators als het project voordelig dat het projectteam snel gevonden fouten verhelpt. Daarom is het naast het verzamelen van metrics ook zinvol om direct een verzameling van logbestanden en foutgegevens van de validators-machines naar een machine te starten die toegankelijk is voor blockchain-ontwikkelaars. Niemand heeft er baat bij om informatie te vervuilen, daarom worden deze diensten opgezet door het projectteam en zijn ze betrouwbaar. Het is zinvol om systeem-metrics van validators te verzamelen, en zeker de belangrijkste metrics van de blockchain zelf — voor DAOBet zijn dat de finalisatietijd en de achterstand van het laatst gefinaliseerde blok. Hierdoor ziet het team de toename van het geheugenverbruik op de nodes bij het starten van de benchmark, evenals de problemen van afzonderlijke validators.

Belangrijke punten voor het uitvoeren van de validators-gemeenschap

Blijkbaar, als u officieel wilt toestaan dat validators elkaar aanvallen (onofficieel kunnen ze dat al doen), moet dit apart juridisch worden geformuleerd als beveiligingstests, omdat in sommige landen de wetgeving DDoS- of netwerkaanvallen kan bestraffen. Een andere belangrijke kwestie is hoe validators beloond moeten worden. Natuurlijke prijzen zijn de tokens van het project die naar het mainnet worden overgebracht, maar een massale distributie van tokens aan iedereen die een node heeft opgezet, is ook geen ideale optie. Waarschijnlijk moet u balanceren tussen twee uitersten:

De volledige prijzenpot verdelen op basis van verdiende VP
dit is zeer democratisch en stelt iedereen in staat om te profiteren die tijd en middelen in het validatorspel heeft gestoken
maar trekt willekeurige mensen aan zonder de juiste infrastructuur

De prijzenpot verdelen onder de top-N validators op basis van de resultaten van het spel
de winnaars zullen waarschijnlijk de validators zijn die het meest stabiel zijn gebleven tijdens het spel, zeer gericht op de overwinning
een deel van de validators zal mogelijk niet willen deelnemen, omdat ze hun kansen om te winnen laag inschatten, vooral als er ervaren validators bij de deelnemers zijn

Welke optie u ook kiest, is aan u

Er is nog een punt — het is helemaal niet zeker dat tientallen validators zich zullen aanmelden voor het spel op uw uitnodiging, en van degenen die het toch proberen, zullen niet allemaal een node installeren en starten — meestal hebben projecten in deze fase vrij beperkte documentatie, er ontstaan fouten, en ontwikkelaars die onder tijdsdruk werken geven niet altijd snel antwoord op vragen. Daarom moet u ook rekening houden met acties, mocht niet het gewenste aantal validators zich aanmelden. In dat geval worden de ontbrekende validators bij de start van het spel door het projectteam opgestart, nemen ze deel aan de consensus, maar kunnen ze geen winnaars zijn.

Conclusie

Tot slot heb ik geprobeerd om uit het bovenstaande een lijst samen te stellen van wat er bedacht, gedaan en gestart moet worden voor een effectieve uitvoering van het validatorspel

Wat moet er gebeuren om een echt validatorspel te starten:
ontwikkel uw eigen blockchain 🙂

maak en lanceer een webinterface en bied CLI aan voor het stemmen op validators
zorgen dat de statistieken van de actieve validator node verzonden kunnen worden naar een gecentraliseerde service (bijvoorbeeld Prometheus)
een server opzetten voor het verzamelen van statistieken (Prometheus + Grafana) voor de validator game
uitvinden hoe de Validator Points (VP) worden geteld
een openbaar script ontwikkelen dat de VP van de validator berekent op basis van gegevens uit de blockchain
een webinterface ontwikkelen voor het weergeven van de top validators en de status van de validator game (hoeveel tijd er nog over is, hoeveel VP iedereen heeft, enz.)
het ontwikkelen en automatiseren van het opstarten van een willekeurig aantal eigen nodes, en het proces ontwerpen voor het verbinden van validators met het spel (wanneer en hoe je je nodes kunt uitschakelen, stemmen indienen en verwijderen)
berekenen hoeveel tokens er uitgegeven moeten worden en een contract-faucet ontwikkelen
een benchmark-script maken (tokentransfers, massaal gebruik van opslag, massaal gebruik van het netwerk)
alle deelnemers in één chat samenbrengen voor snelle communicatie
de blockchain iets eerder starten dan de start van het spel
wachten op de startblock, het spel beginnen
het netwerk testen met verschillende soorten transacties
een hardfork uitvoeren
de lijst met validators wijzigen
punten 13, 14, 15 in een andere volgorde herhalen, terwijl de stabiliteit van het netwerk wordt handhaafd
wachten op de finale block, het spel beëindigen, VP berekenen

Het moet gezegd worden dat de validator game een nieuw verhaal is en slechts een paar keer is gehouden, dus men moet deze tekst niet beschouwen als een definitieve gids. Er zijn geen analogen in de moderne IT-business - stel je voor dat banken voor de lancering van een betalingssysteem met elkaar strijden om te zien wie de beste transacties voor klanten kan uitvoeren. Traditionele benaderingen zullen je waarschijnlijk niet helpen bij het creëren van grote gedecentraliseerde netwerken, dus ontwikkel nieuwe businessmodellen, organiseer je spellen, bepaal wie waardig is, beloon ze en laat je gedistribueerde systemen snel en stabiel werken.

Bron: habr.com