Per tant, el vostre equip ha acabat la versió alfa de la vostra cadena de blocs i és hora de llançar testnet i, a continuació, mainnet. Tens una blockchain real, amb participants independents, un bon model econòmic, seguretat, has dissenyat la governança i ara toca provar tot això en acció. En un món cripto-anàrquic ideal, poses el bloc de gènesi a la xarxa, el codi final del node i els mateixos validadors ho llancen tot, aixequen tots els serveis auxiliars i tot passa per si sol. Però això és en un món fictici, però en el món real, l'equip ha de preparar un munt de programari auxiliar i diverses manipulacions per ajudar els validadors a llançar una xarxa estable. D'això tracta aquest article.
Llançar xarxes basades en consensos de tipus "prova de participació", on els validadors es determinen pels vots dels titulars de fitxes del sistema, és un esdeveniment força específic, perquè fins i tot llançar sistemes tradicionals de gestió centralitzada amb desenes i centenars de servidors no és fàcil. tasca en si mateixa, i la cadena de blocs s'ha de començar amb un esforç de participants lleials però independents. I, si en una corporació, en iniciar-se, els administradors tenen accés total a totes les màquines, registres, monitorització general, aleshores els validadors no permetran que ningú accedeixi als seus servidors i, molt probablement, preferiran construir la seva infraestructura de manera independent, perquè controla l'accés. als principals actius del validador - votants de participació. És aquest comportament el que permet construir xarxes segures distribuïdes: la independència dels proveïdors de núvol utilitzats, servidors virtuals i "baremetal", diferents sistemes operatius, tot això us permet fer que els atacs a aquesta xarxa siguin extremadament ineficaços, massa diferents. s'utilitza programari. Per exemple, Ethereum utilitza dues implementacions de nodes principals, a Go i a Rust, i un atac que és efectiu per a una implementació no funciona per a l'altra.
Per tant, tots els processos de llançament i funcionament de blockchains s'han d'organitzar de manera que qualsevol validador, o fins i tot un petit grup de validadors, pugui en qualsevol moment llençar els seus ordinadors per la finestra i marxar, mentre que res no s'hauria de trencar i els validadors restants haurien de sortir. continuar donant suport eficaç a la xarxa d'operacions i connectar nous validadors. Quan es posa en marxa una xarxa, quan un validador és a Europa, el segon a Amèrica del Sud i el tercer a Àsia, és bastant difícil aconseguir el treball coordinat de diverses desenes de grups independents i, per tant, interessar-los.
Validadors
Imaginem-nos el llançament d'una hipotètica blockchain moderna (la major part del que es descriu és adequat per a blockchains basats en qualsevol família moderna de blockchains: Ethereum, EOS, Polkadot, Cosmos i altres, que proporcionen un consens de prova d'aposta. Els protagonistes de aquestes cadenes de blocs són equips de validadors , que es dediquen a instal·lar els seus propis servidors independents que validen i produeixen nous blocs, i reben recompenses proporcionades per la xarxa per a aquells que participen en el consens. Per llançar noves xarxes, es necessiten diverses desenes de validadors (tants ara poden més o menys eficaçment arriben a consens en segons), de manera que el projecte anuncia el registre, en el qual els validadors comparteixen informació pública sobre ells mateixos amb els usuaris, convencent-los que oferiran un servei d'alta qualitat a la xarxa llançada.
La validació és un negoci que us permet avaluar amb molta precisió els ingressos potencials del validador, transferir ràpidament el poder entre projectes i, si la xarxa que ha escollit té èxit, el validador pot, com a participant de ple dret al DAO i persona responsable, desenvolupar el projecte, o simplement oferir un servei tècnic excel·lent per a diners totalment transparents i honestament guanyats. A l'hora de calcular la recompensa dels validadors, els projectes intenten tenir en compte els costos dels validadors i fer que la recompensa dels blocs sigui rendible, però al mateix temps no permet que els validadors facin caure l'economia inundant-los de diners i privant-ne altres usuaris de la xarxa.
El negoci dels validadors requereix garantir una alta tolerància a errors dels serveis, la qual cosa significa un alt nivell de formació per a desenvolupadors i desenvolupadors i recursos informàtics cars. Fins i tot sense la necessitat de minar hash en xarxes de prova de treball, un node de cadena de blocs és un gran servei que ocupa molta memòria, consumeix molts càlculs, valida, escriu al disc i envia grans quantitats de dades a la xarxa. . Per emmagatzemar registres de transaccions i cadenes de blocs per a una cadena de blocs amb diversos milers de petites transaccions en un bloc, ara es requereix un emmagatzematge de 50 Gb o més, i per als blocs ha de ser un SSD. La base de dades estatal de blockchains amb suport per a contractes intel·ligents ja pot superar els 64 Gb de RAM. Els servidors amb les característiques requerides són bastant cars; un node Ethereum o EOS pot costar entre 100 i 200 $/mes. A això s'afegeix l'augment dels salaris per al treball durant les 10 hores dels desenvolupadors i devops, que durant el període de llançament resolen problemes fins i tot de nit, ja que alguns validadors es poden localitzar fàcilment en un altre hemisferi. Tanmateix, en els moments adequats, tenir un node validador pot generar ingressos importants (en el cas d'EOS, fins a 000 dòlars al dia).
La validació és només un dels nous rols potencials de TI per als emprenedors i les empreses; a mesura que els programadors presenten algorismes cada cop més sofisticats que premien l'honestedat i castiguen el frau i el robatori, apareixen serveis que compleixen les funcions de publicar dades importants (oracles), fer la supervisió. (reducció de dipòsits i càstig als tramposos mitjançant la publicació de proves d'engany), serveis de resolució de disputes, assegurances i opcions, fins i tot la recollida d'escombraries és un mercat potencialment gran en sistemes de contracte intel·ligent on cal pagar l'emmagatzematge de dades.
Problemes per llançar una cadena de blocs
L'obertura de la cadena de blocs, que va fer possible que els ordinadors de qualsevol país poguessin participar lliurement a la xarxa i la facilitat per connectar qualsevol script kiddie a la xarxa segons les instruccions de GitHub, no sempre és un avantatge. La recerca d'un nou testimoni sovint obliga els validadors a "extraure una moneda nova al principi", amb l'esperança que la taxa pugi i l'oportunitat de treure ràpidament els seus guanys. A més, això vol dir que el vostre validador pot ser qualsevol persona, fins i tot una persona anònima, podeu votar per ell de la mateixa manera que per a altres validadors (no obstant això, serà difícil que una persona anònima recapti els vots de les parts interessades per si mateix, així que" Deixaré les històries de por sobre les criptomonedes anònimes als polítics). no obstant
L'equip del projecte té una tasca: entrar d'alguna manera a la seva xarxa aquells que en el futur siguin capaços d'assegurar el funcionament estable dels nodes, entendre la seguretat, saber resoldre problemes ràpidament, cooperar amb altres validadors i actuar junts: la qualitat d'això molt depèn d'aquestes qualitats, un testimoni en què els participants de la xarxa invertiran el seu temps i recursos. Els fundadors adequats, a l'hora d'avaluar els riscos, entenen bé que en llançar programari d'aquesta mida, definitivament haureu de trobar errors en el codi i la configuració dels nodes, i que l'estabilitat de la xarxa depèn de com resolguin conjuntament desenvolupadors i validadors. aquests problemes.
L'equip està preparat per votar a la xarxa principal qualsevol validador, només per saber quins, quins són bons? La cartera més gran? Gairebé ningú en té ara. Segons els perfils de Linkedin de l'equip? Els devots amb experiència o els especialistes en seguretat no us donaran cap perfil de Linkedin. Segons declaracions al xat, publicacions i ajuda als altres durant la fase de preparació? Bé, però subjectiu i inexacte.
En aquestes condicions, queda una cosa, una cosa que resol bé els problemes de tothom, un joc en el qual serà possible seleccionar els millors validadors, però el més important és provar la força de la cadena de blocs i dur a terme una prova de combat a gran escala del blockchain en condicions d'ús actiu, canvis de consens, aparició i correcció d'errors. Aquest procediment va ser presentat per primera vegada com un joc pels nois del projecte Cosmos, i aquesta idea és sens dubte una excel·lent manera de preparar la xarxa per al llançament d'una xarxa principal fiable i tolerant a errors.
Joc de validadors
Descriuré el joc dels validadors tal com el vam dissenyar per a la cadena de blocs DAO.Casino (DAOBet) basat en la bifurcació EOS, que s'anomena Haya i té un mecanisme de govern similar: els validadors s'escullen votant des de qualsevol compte, en què part de el saldo utilitzat per votar el validador està congelat. Qualsevol compte que tingui el token BET principal al seu saldo pot votar pel validador seleccionat amb qualsevol part del seu saldo. Es resumeixen els vots i es construeixen els principals validadors a partir dels resultats. En diferents blockchain aquest procés s'organitza de manera diferent, i normalment és en aquesta part on la nova blockchain difereix de la matriu, i he de dir que en el nostre cas, EOS justifica plenament el "SO" en el seu nom, realment fem servir EOS. com a sistema operatiu base per al desplegament d'una versió modificada de la cadena de blocs per a tasques DAOBet.
Descriuré problemes individuals i com es poden resoldre dins del joc. Imaginem una xarxa en la qual el vostre servidor pugui ser atacat obertament, on per mantenir la posició d'un validador necessiteu interactuar contínuament amb la xarxa, promocionant el vostre validador i assegurant-vos que produeixi blocs i que es lliurin a altres validadors el temps, en cas contrari, el validador serà eliminat de la llista.
Com triar els millors guanyadors?
El principal requisit tècnic del joc és que els seus resultats siguin verificables públicament. Això vol dir que els resultats del joc: TOP winners, s'han de formar estrictament sobre la base de dades que qualsevol participant pugui verificar. En un sistema centralitzat, podríem mesurar el "temps de funcionament" de cada validador i premiar els que més estaven en línia o passaven pel màxim trànsit de xarxa. Podeu recollir dades sobre la càrrega del processador i la memòria i recompensar els que han treballat bé. Però qualsevol recopilació d'aquestes mètriques significa l'existència d'un centre de recollida, i els nodes són tots independents i poden comportar-se com vulguin i enviar qualsevol dada.
Per tant, la solució natural és que els guanyadors s'han de determinar a partir de les dades de la cadena de blocs, ja que es pot utilitzar per veure quin validador va produir quin bloc i quines transaccions s'hi van incloure. Aquest nombre l'hem anomenat Punts de validació (VP) i guanyar-los és l'objectiu principal dels validadors del joc. En el nostre cas, la mètrica més senzilla, fàcilment verificable públicament i eficaç de la "utilitat" d'un validador és VP = nombre de blocs produïts pel validador en un període de temps determinat.
Aquesta senzilla elecció es deu al fet que la governança a EOS ja preveu molts problemes emergents, ja que EOS és l'hereu de tres generacions de blockchains que funcionen realment amb una àmplia experiència en la gestió de xarxes complexes i gairebé qualsevol problema de validació amb la xarxa, el processador, El disc només condueix a un problema: signa menys blocs, rep menys pagament per l'obra, cosa que ens porta de nou al nombre de blocs signats; per a EOS aquesta és una opció excel·lent i senzilla.
Per a altres cadenes de blocs, la forma en què es calculen els punts de validació pot ser diferent, per exemple, per a consensos basats en pBFT (Tendermint/Cosmos, consens Aura de Parity Substrate), on cada bloc ha d'estar signat per diversos validadors, té sentit comptar el validador individual. signatures més que blocs. Pot tenir sentit tenir en compte les rondes de consens incompletes, que malgasten els recursos d'altres validadors, en general això depèn molt del tipus de consens.
Com simular condicions reals de funcionament
La tasca dels fundadors és provar validadors en condicions properes a la realitat, sense tenir cap control centralitzat. Aquest problema es pot resoldre mitjançant un contracte d'aixeta, que distribueix quantitats iguals del testimoni principal als validadors i a tots els altres. Per rebre fitxes al vostre saldo, heu de crear una transacció i assegurar-vos que la xarxa l'inclogui al bloc. Així, per guanyar, un validador ha d'omplir constantment el seu saldo amb noves fitxes i votar per si mateix, promocionant-se al cim. Aquesta activitat crea una càrrega constant a la xarxa i es poden seleccionar els paràmetres perquè el flux de sol·licituds sigui prou intens com per a una prova completa de la xarxa. Per tant, planifiqueu el contracte de l'aixeta amb antelació com una eina important per posar en marxa la xarxa i comenceu a seleccionar-ne els paràmetres amb antelació.
Sol·licitar fitxes d'una aixeta i validar els vots encara no emula completament el funcionament d'una ogiva, especialment en modes extremadament carregats. Per tant, l'equip de blockchain encara haurà d'escriure punts de referència addicionals d'una manera o altra per carregar la xarxa. Un paper especial en això juguen els contractes intel·ligents creats especialment que permeten provar un subsistema separat. Per provar l'emmagatzematge, el contracte emmagatzema dades aleatòries a la cadena de blocs i, per provar els recursos de la xarxa, el contracte de prova requereix una gran quantitat de dades d'entrada, augmentant així el volum de transaccions, llançant un flux d'aquestes transaccions en moments arbitraris. l'equip prova simultàniament l'estabilitat del codi i la força dels validadors.
Un problema a part és actualitzar el codi de nodes i dur a terme bifurcacions dures. Cal que en cas d'error, vulnerabilitat o col·lusió de validadors maliciosos, els validadors han de tenir un pla d'acció que ja s'hagi elaborat en el joc dels validadors. Aquí podeu trobar esquemes per acumular VP per aplicar ràpidament una bifurcació dura, per exemple, multant tots els validadors que encara no han llançat una nova versió del codi del node, però això és difícil d'implementar i complica el càlcul. Podeu simular la situació d'un ús d'emergència d'una forquilla dura "trencant" artificialment la cadena de blocs d'un bloc determinat. La producció de blocs s'atura i, al final, els guanyadors seran els que saltin primer i comencen a signar blocs, de manera que VP basat en el nombre de blocs signats és una bona solució aquí.
Com informar els participants sobre l'estat de la xarxa i corregir errors
Malgrat la desconfiança entre els validadors, la recepció puntual d'informació actualitzada sobre l'estat de la xarxa és beneficiós per a tothom per tal de prendre decisions més ràpidament, de manera que l'equip del projecte està plantejant un servei per recollir i visualitzar moltes mètriques dels servidors validadors, que us permet veure la situació simultàniament per a tota la xarxa, la qual cosa us permet determinar ràpidament què està passant. A més, és beneficiós tant per als validadors com per al projecte que l'equip del projecte corregeixi ràpidament els errors trobats, de manera que, a més de recollir mètriques, té sentit començar immediatament a recopilar registres i dades d'error de les màquines dels validadors en una màquina accessible per blockchain. desenvolupadors. Aquí, no és beneficiós per a ningú distorsionar la informació, de manera que aquests serveis els desenvolupa l'equip del projecte i es pot confiar. Té sentit recollir mètriques del sistema dels validadors i, per descomptat, les mètriques més importants de la pròpia cadena de blocs -per a DAOBet- són el temps de finalització i el retard de l'últim bloc finalitzat. Gràcies a això, l'equip veu un augment del consum de memòria als nodes en executar el benchmark, problemes amb validadors individuals.
Punts importants per a la realització d'un joc de validació
Com a resultat, si voleu permetre oficialment que els validadors ataquen les màquines dels altres (extraoficialment poden fer-ho de totes maneres), heu de formular-ho per separat legalment com a prova de seguretat, ja que segons les lleis d'alguns països es poden produir atacs DDoS o a la xarxa. castigat. Un altre tema important és com recompensar els validadors. Els premis naturals són fitxes de projecte, que es transferiran a la xarxa principal, però una distribució massiva de fitxes a qualsevol persona que hagi pogut llançar un node tampoc és la millor opció. El més probable és que haureu d'equilibrar entre dues opcions extremes:
Distribueix tot el premi acumulat segons el VP obtingut
és molt democràtic i permet que tothom que hagi invertit temps i recursos en el joc del validador guanyi diners
però atrau persones aleatòries al joc sense una infraestructura preparada
Distribuïu el premi N més gran als validadors en funció dels resultats del joc
Probablement, els guanyadors seran els validadors que hagin durat més constantment durant el joc i estiguin molt decidits a guanyar
alguns validadors no voldran participar, avaluant baixes les seves possibilitats de guanyar, especialment si els participants inclouen validadors venerables
Quina opció triar depèn de tu
Hi ha un punt més: no és gens un fet que desenes de validadors s'afanyin a participar en el joc a la vostra trucada, i dels que decideixen provar-ho, ni tan sols instal·laran i llançaran el node, normalment, En aquesta etapa, els projectes tenen una documentació força escassa, es troben errors i els desenvolupadors que treballen amb pressió de temps no responen a les preguntes molt ràpidament. Per tant, abans de llançar el joc, també cal preveure accions si no s'arriba al nombre de validadors necessaris. En aquest cas, a l'inici del joc, els validadors que falten són llançats per l'equip del projecte, participen en consens, però no poden ser guanyadors.
Conclusió
En conclusió, vaig intentar compilar a partir de l'anterior una llista del que cal pensar, fer i llançar per dur a terme de manera eficaç un joc de validació.
Què heu de fer per executar un joc de validació real:
desenvolupa la teva pròpia cadena de blocs :)
- crear i crear una interfície web i proporcionar una CLI per votar als validadors
- Assegureu-vos que les mètriques d'un node validador en execució es puguin enviar a un servei centralitzat (per exemple, Prometheus)
- crear un servidor de recollida de mètriques (Prometheus + Grafana) per al joc del validador
- esbrineu com es calcularan els punts de validació (VP).
- desenvolupar un script públic que calculi la VP del validador a partir de les dades de la cadena de blocs
- desenvolupar una interfície web per mostrar els validadors principals i l'estat del joc dels validadors (quant de temps queda per al final, qui té quant VP, etc.)
- desenvolupar i automatitzar el llançament d'un nombre arbitrari dels vostres propis nodes, dissenyar el procés de connexió de validadors al joc (quan i com desconnectar els vostres nodes, enviar-los i eliminar-los)
- calcular quantes fitxes s'han d'emetre i desenvolupar un contracte d'aixeta
- fer un script de referència (transferències de testimonis, ús massiu d'emmagatzematge, ús massiu de xarxa)
- reuniu tots els participants en un sol xat per a una comunicació ràpida
- llançar la cadena de blocs una mica abans de l'inici del joc
- espera el bloc de sortida, comença el joc
- prova la xarxa amb diversos tipus de transaccions
- estirar una forquilla dura
- canviar la llista de validadors
- repetiu els passos 13,14,15, XNUMX, XNUMX en diferents ordres, mantenint l'estabilitat de la xarxa
- esperar el bloc final, acabar el joc, comptar VP
Cal dir que el joc dels validadors és una història nova, i només es va dur a terme un parell de vegades, per la qual cosa no hauríeu de prendre aquest text com una guia ja feta. No hi ha anàlegs en el negoci informàtic modern: imagineu-vos que els bancs, abans de llançar un sistema de pagament, competeixen entre ells per veure qui serà el millor per fer transaccions amb els clients. És poc probable que els enfocaments tradicionals us ajudin a crear grans xarxes descentralitzades, de manera que domina nous models de negoci, executeu els vostres jocs, identifiqueu els dignes, recompenseu-los i mantingueu els vostres sistemes distribuïts en funcionament de manera ràpida i estable.
Font: www.habr.com