Entón, o teu equipo rematou a versión alfa da túa cadea de bloques e é hora de lanzar testnet e despois mainnet. Tes unha verdadeira cadea de bloques, con participantes independentes, un bo modelo económico, seguridade, deseñaches a gobernanza e agora toca probar todo isto en acción. Nun mundo cripto-anárquico ideal, pon o bloque de xénese na rede, o código final do nodo e os propios validadores lanzan todo, elevan todos os servizos auxiliares e todo sucede por si só. Pero isto é nun mundo ficticio, pero no mundo real, o equipo debe preparar bastante software auxiliar e varias manipulacións para axudar aos validadores a lanzar unha rede estable. Isto é do que trata este artigo.
O lanzamento de redes baseados en consensos de tipo "proba de participación", onde os validadores están determinados polos votos dos posuidores de tokens do sistema, é un evento bastante específico, porque incluso lanzar sistemas tradicionais de xestión centralizada con decenas e centos de servidores non é sinxelo. tarefa en si mesma, e a cadea de bloques debe comezar con participantes leais pero independentes. E, se nunha corporación, ao iniciarse, os administradores teñen acceso total a todas as máquinas, rexistros, vixilancia xeral, entón os validadores non permitirán que ninguén acceda aos seus servidores e, moi probablemente, preferirán construír a súa infraestrutura de forma independente, porque controla o acceso. aos principais activos do validador - electores de apostas. É este comportamento o que fai posible construír redes seguras distribuídas: a independencia dos provedores de nube utilizados, servidores virtuais e "baremetal", diferentes sistemas operativos, todo iso permítelle facer ataques a unha rede así moi ineficaz, demasiado diferente. se utiliza software. Por exemplo, Ethereum usa dúas implementacións de nodos principais, en Go e en Rust, e un ataque que é efectivo para unha implementación non funciona para a outra.
Polo tanto, todos os procesos de lanzamento e funcionamento das cadeas de bloques deben estar organizados de forma que calquera validador, ou mesmo un pequeno grupo de validadores, poida en calquera momento tirar os seus ordenadores pola fiestra e saír, mentres que nada debería romper e os validadores restantes deberían saír. continuar dando soporte eficaz á rede operativa e conectar novos validadores. Ao lanzar unha rede, cando un validador está en Europa, o segundo en Sudamérica e o terceiro en Asia, é bastante difícil conseguir o traballo coordinado de varias decenas de grupos independentes e interesalos como resultado.
Validadores
Imaxinemos o lanzamento dunha hipotética cadea de bloques moderna (a maior parte do descrito é adecuado para cadeas de bloques baseadas en calquera familia moderna de cadeas de bloques: Ethereum, EOS, Polkadot, Cosmos e outros, que proporcionan consenso de proba de xogo. Os personaxes principais de tales blockchains son equipos de validadores , que se dedican a instalar os seus propios servidores independentes que validan e producen novos bloques, e reciben recompensas proporcionadas pola rede para aqueles que participan no consenso. Para lanzar novas redes, son necesarios varias ducias de validadores (tantos agora poden de forma máis ou menos efectiva chegan ao consenso en segundos), polo que o proxecto anuncia o rexistro, no que os validadores comparten información pública sobre si mesmos cos usuarios, convencéndoos de que van prestar un servizo de alta calidade á rede posta en marcha.
A validación é unha empresa que permite avaliar con gran precisión os ingresos potenciais do validador, transferir rapidamente o poder entre os proxectos e, se a rede que elixiu ten éxito, o validador pode, como participante de pleno dereito do DAO e persoa responsable, desenvolver o proxecto, ou simplemente proporcionar un excelente servizo técnico para o diñeiro completamente transparente e honestamente gañado. Ao calcular a recompensa dos validadores, os proxectos tratan de ter en conta os custos dos validadores e facer que a recompensa dos bloques sexa rendible, pero ao mesmo tempo non permite que os validadores derruben a economía inungándoos de cartos e privando dela a outros usuarios da rede.
O negocio dos validadores require garantir unha alta tolerancia a fallos dos servizos, o que significa un alto nivel de formación para devops e desenvolvedores e recursos informáticos caros. Mesmo sen necesidade de minar hash en redes de proba de traballo, un nodo de cadea de bloques é un servizo grande que ocupa moita memoria, consome moitos cálculos, valida, escribe no disco e envía grandes cantidades de datos á rede. . Para almacenar rexistros de transaccións e cadeas de bloques para unha cadea de bloques con varios miles de pequenas transaccións nun bloque, agora é necesario almacenar 50 Gb ou máis, e para os bloques debe ser un SSD. A base de datos estatal de blockchains con soporte para contratos intelixentes xa pode superar os 64 Gb de RAM. Os servidores coas características requiridas son bastante caros; un nodo Ethereum ou EOS pode custar entre 100 e 200 $/mes. Engádese a isto o aumento dos salarios polo traballo durante todo o día dos desenvolvedores e devops, que durante o período de lanzamento resolven problemas mesmo pola noite, xa que algúns validadores poden localizarse facilmente noutro hemisferio. Non obstante, nos momentos axeitados, posuír un nodo validador pode xerar ingresos serios (no caso de EOS, ata 10 dólares por día).
A validación é só un dos novos roles potenciais de TI para emprendedores e empresas; a medida que os programadores crean algoritmos cada vez máis sofisticados que premian a honestidade e castigan a fraude e o roubo, aparecen servizos que realizan as funcións de publicar datos importantes (oráculos), realizar a supervisión. (recortar depósitos e castigar aos tramposos publicando probas de engano), servizos de resolución de disputas, seguros e opcións, incluso a recollida de lixo é un mercado potencialmente grande nos sistemas de contrato intelixente onde é necesario pagar o almacenamento de datos.
Problemas para lanzar unha cadea de bloques
A apertura da cadea de bloques, que fixo posible que os ordenadores de calquera país participaran libremente na rede e a facilidade de conectar calquera script kiddie á rede segundo as instrucións de GitHub, non sempre é unha vantaxe. A procura dun novo token adoita obrigar aos validadores a "extraer unha nova moeda ao principio", coa esperanza de que a taxa aumente e a oportunidade de perder rapidamente as súas ganancias. Ademais, isto significa que o teu validador pode ser calquera persoa, incluso unha persoa anónima, podes votar por el do mesmo xeito que para outros validadores (non obstante, será difícil para unha persoa anónima recoller os votos das partes interesadas por si mesma, polo que " Deixarei os contos de medo sobre as criptomoedas anónimas para os políticos). Con todo
O equipo do proxecto ten unha tarefa: entrar dalgún xeito na súa rede a aqueles que no futuro sexan capaces de garantir o funcionamento estable dos nodos, comprender a seguridade, saber resolver problemas rapidamente, cooperar con outros validadores e actuar xuntos: a calidade diso. Moi cousa depende totalmente destas calidades, unha mostra na que os participantes da rede van investir o seu tempo e recursos. Os fundadores adecuados, ao avaliar os riscos, entenden ben que ao lanzar software deste tamaño, definitivamente terás que atopar erros no código e na configuración dos nodos, e que a estabilidade da rede depende do ben que os desenvolvedores e os validadores resolvan conxuntamente. tales problemas.
O equipo está preparado para votar na rede principal calquera validador, só para saber cales, cales son boas? A carteira máis grande? Agora case ninguén o ten. Segundo os perfís de Linkedin do equipo? Devops experimentados ou especialistas en seguridade non che darán ningún perfil de Linkedin. Segundo declaracións no chat, publicacións e axudando a outros durante a fase de preparación? Bo, pero subxectivo e impreciso.
En tales condicións, queda unha cousa - algo que resolve ben os problemas de todos - un xogo no que será posible seleccionar os mellores validadores, pero o principal é probar a forza da cadea de bloques e realizar unha proba de combate a gran escala do blockchain en condicións de uso activo, cambios de consenso, aparición e corrección de erros. Este procedemento foi presentado por primeira vez como un xogo polos mozos do proxecto Cosmos, e esta idea é sen dúbida unha excelente forma de preparar a rede para o lanzamento dunha rede principal fiable e tolerante a fallos.
Xogo de validadores
Describirei o xogo de validadores tal e como o deseñamos para a cadea de bloques DAO.Casino (DAOBet) baseado no fork EOS, que se chama Haya e ten un mecanismo de goberno similar: os validadores escóllense votando desde calquera conta, na que parte de o saldo utilizado para votar ao validador está conxelado. Calquera conta que teña o token BET principal no seu saldo pode votar polo validador seleccionado con calquera parte do seu saldo. Os votos resúmense e os principais validadores constrúense en función dos resultados. En diferentes blockchains este proceso organízase de forma diferente, e normalmente é nesta parte onde a nova blockchain difire da principal, e debo dicir que no noso caso, EOS xustifica plenamente o "SO" no seu nome, realmente usamos EOS. como o sistema operativo base para a implantación dunha versión modificada da cadea de bloques para tarefas DAOBet.
Describirei os problemas individuais e como se poden resolver dentro do xogo. Imaxinemos unha rede na que o teu servidor pode ser atacado abertamente, onde para manter a posición dun validador cómpre interactuar continuamente coa rede, promocionando o teu validador e asegurándote de que produce bloques e que sexan entregados a outros validadores en tempo, se non, o validador será eliminado da lista.
Como elixir os mellores gañadores?
O principal requisito técnico para o xogo é que os seus resultados sexan verificables publicamente. Isto significa que os resultados do xogo: TOP winners, deben estar formados estrictamente en base a datos que poden ser verificados por calquera participante. Nun sistema centralizado, poderiamos medir o "tempo de actividade" de cada validador e premiar aos que máis estaban en liña ou pasaron polo máximo tráfico de rede. Podes recoller datos sobre a carga do procesador e da memoria e premiar aos que traballaron ben. Pero calquera colección deste tipo de métricas significa a existencia dun centro de recollida, e os nodos son todos independentes e poden comportarse como queiran e enviar calquera dato.
Polo tanto, a solución natural é que os gañadores se determinen en función dos datos da cadea de bloques, xa que se pode usar para ver que validador produciu que bloque e que transaccións se incluíron nel. Chamámoslle a este número Puntos de validación (VP) e gañalos é o principal obxectivo dos validadores do xogo. No noso caso, a métrica máis sinxela, facilmente verificable publicamente e efectiva da "utilidade" dun validador é VP = número de bloques producidos polo validador nun período de tempo determinado.
Esta simple elección débese ao feito de que a gobernanza en EOS xa prevé moitos problemas emerxentes, xa que EOS é o herdeiro de tres xeracións de cadeas de bloques que realmente funcionan con ampla experiencia na xestión de redes complexas e case calquera problema de validación coa rede, o procesador, disco leva a só un problema - asina menos bloques, recibe menos pago polo traballo, o que de novo nos leva simplemente ao número de bloques asinados - para EOS esta é unha opción excelente e sinxela.
Para outras cadeas de bloques, a forma en que se calculan os puntos de validación pode diferir, por exemplo, para os consensos baseados en pBFT (Tendermint/Cosmos, consenso Aura de Parity Substrate), onde cada bloque debe estar asinado por varios validadores, ten sentido contar o validador individual. sinaturas en lugar de bloques.Pode ter sentido ter en conta as roldas de consenso incompletas, que malgastan os recursos doutros validadores, en xeral isto depende moito do tipo de consenso.
Como simular condicións reais de funcionamento
A tarefa dos fundadores é probar os validadores en condicións próximas á realidade, sen ter ningún control centralizado. Este problema pódese resolver mediante un contrato de billa, que distribúe cantidades iguais do token principal aos validadores e a todos os demais. Para recibir tokens no teu saldo, debes crear unha transacción e asegurarte de que a rede a inclúa no bloque. Así, para gañar, un validador debe repoñer constantemente o seu saldo con novas fichas e votar por si mesmo, ascendendo á cima. Esta actividade crea unha carga constante na rede e pódense seleccionar os parámetros para que o fluxo de solicitudes sexa o suficientemente severo para unha proba de rede completa. Polo tanto, planifica o contrato da billa con antelación como unha ferramenta importante para lanzar a rede e comeza a seleccionar os seus parámetros con antelación.
Solicitar fichas dunha billa e validar votos aínda non emula completamente o funcionamento dunha oxiva, especialmente en modos extremadamente cargados. Polo tanto, o equipo de blockchain aínda terá que escribir benchmarks adicionais dun xeito ou doutro para cargar a rede. Os contratos intelixentes especialmente creados que permiten probar un subsistema separado teñen un papel especial. Para probar o almacenamento, o contrato almacena datos aleatorios na cadea de bloques e, para probar os recursos da rede, o contrato de proba require unha gran cantidade de datos de entrada, polo que aumenta o volume de transaccións, ao lanzar un fluxo de tales transaccións en momentos arbitrarios. o equipo proba simultaneamente a estabilidade do código e a forza dos validadores.
Un problema aparte é a actualización do código de nodos e a realización de hard forks. Requírese que, en caso de erro, vulnerabilidade ou connivencia de validadores maliciosos, os validadores teñan un plan de acción xa elaborado no xogo dos validadores. Aquí podes atopar esquemas para acumular VP para aplicar rapidamente unha bifurcación dura, por exemplo, multando a todos os validadores que aínda non lanzaron unha nova versión do código do nodo, pero isto é difícil de implementar e complica o cálculo. Podes simular a situación dun uso de emerxencia dun garfo duro "rompendo" artificialmente a cadea de bloques nun bloque determinado. A produción de bloques detense e, ao final, os gañadores serán os que salten primeiro e comecen a asinar bloques, polo que a VP baseada no número de bloques asinados é unha boa opción aquí.
Como informar aos participantes sobre o estado da rede e corrixir erros
A pesar da desconfianza entre os validadores, a recepción oportuna de información actualizada sobre o estado da rede é beneficiosa para todos para poder tomar decisións máis rápido, polo que o equipo do proxecto está a crear un servizo para recoller e visualizar moitas métricas dos servidores de validadores. que permite ver a situación de forma simultánea para toda a rede, o que lle permite determinar rapidamente o que está a suceder. Ademais, é beneficioso tanto para os validadores como para o proxecto que o equipo do proxecto corrixa rapidamente os erros atopados, polo que ademais de recoller métricas, ten sentido comezar inmediatamente a recompilar rexistros e datos de erros das máquinas dos validadores nunha máquina accesible para blockchain. desenvolvedores. Aquí, non é beneficioso que ninguén distorsione a información, polo que estes servizos son desenvolvidos polo equipo do proxecto e pódense confiar. Ten sentido recoller métricas do sistema dos validadores e, por suposto, as métricas máis importantes da propia cadea de bloques - para DAOBet - son o tempo de finalización e o atraso do último bloque finalizado. Grazas a isto, o equipo observa un aumento no consumo de memoria nos nodos ao executar o benchmark, problemas cos validadores individuais
Puntos importantes para a realización dun xogo de validación
Polo que resulta, se queres permitir oficialmente que os validadores ataquen as máquinas dos outros (non oficialmente poden facelo de todos os xeitos), cómpre formular isto por separado legalmente como proba de seguridade, xa que segundo as leis dalgúns países pódense realizar ataques DDoS ou de rede. castigado. Outra cuestión importante é como recompensar aos validadores. Os premios naturais son fichas de proxecto, que se transferirán á rede principal, pero unha distribución masiva de fichas a calquera que puidese lanzar un nodo tampouco é a mellor opción. O máis probable é que teñas que equilibrar entre dúas opcións extremas:
Reparte todo o premio total segundo o VP obtido
é moi democrático e permite que todos os que investiron tempo e recursos no xogo do validador poidan gañar cartos
pero atrae persoas aleatorias ao xogo sen unha infraestrutura preparada
Distribuír os premios dos primeiros N aos validadores en función dos resultados do xogo
Os gañadores probablemente serán os validadores que durasen máis constantemente durante o xogo e están moi decididos a gañar
algúns validadores non quererán participar, avaliando as súas posibilidades de gañar, especialmente se os participantes inclúen validadores venerables
Que opción elixir depende de ti
Hai un punto máis: non é para nada un feito que decenas de validadores se apresuren a participar no xogo na túa chamada, e dos que deciden tentalo, nin todos instalarán e lanzarán o nodo, normalmente, nesta fase, os proxectos teñen unha documentación bastante escasa, atópanse erros e os desenvolvedores que traballan baixo a presión do tempo non responden ás preguntas moi rapidamente. Polo tanto, antes de lanzar o xogo, tamén é necesario prever accións se non se alcanza o número necesario de validadores. Neste caso, ao comezo do xogo, os validadores que faltan son postos en marcha polo equipo do proxecto, participan en consenso, pero non poden ser gañadores.
Conclusión
En conclusión, tentei compilar a partir do anterior unha lista do que hai que pensar, facer e lanzar para levar a cabo un xogo de validación de forma eficaz.
O que cómpre facer para executar un xogo de validación real:
desenvolve a túa propia cadea de bloques :)
- crear e crear unha interface web e proporcionar unha CLI para votar aos validadores
- asegúrese de que as métricas dun nodo validador en execución se poidan enviar a un servizo centralizado (por exemplo, Prometheus)
- crear un servidor de recollida de métricas (Prometheus + Grafana) para o xogo de validación
- descubrir como se calcularán os puntos de validación (VP).
- desenvolver un script público que calcule o validador VP en función dos datos da cadea de bloques
- desenvolver unha interface web para mostrar os principais validadores e o estado do xogo dos validadores (canto tempo queda para o final, quen ten canto VP, etc.)
- desenvolver e automatizar o lanzamento dun número arbitrario dos teus propios nodos, deseñar o proceso de conexión de validadores ao xogo (cando e como desconectar os teus nodos, enviar e eliminar votos para eles)
- calcular cantos tokens hai que emitir e desenvolver un contrato de billa
- facer un script de referencia (transferencias de tokens, uso masivo de almacenamento, uso masivo da rede)
- reúna a todos os participantes nun chat para unha comunicación rápida
- lanzar a cadea de bloques un pouco antes do comezo do xogo
- agarda o bloque de saída, comeza o xogo
- probar a rede con varios tipos de transaccións
- tirar un garfo duro
- cambiar a lista de validadores
- repita os pasos 13,14,15, XNUMX, XNUMX en diferentes ordes, mantendo a estabilidade da rede
- esperar o bloque final, rematar o xogo, contar VP
Hai que dicir que o xogo dos validadores é unha historia nova, e que se levou a cabo só un par de veces, polo que non debes tomar este texto como unha guía preparada. Non hai análogos no negocio de TI moderno: imaxina que os bancos, antes de lanzar un sistema de pago, compiten entre eles para ver quen será o mellor para realizar transaccións con clientes. É improbable que os enfoques tradicionais che axuden a crear grandes redes descentralizadas, polo que domina novos modelos de negocio, executa os teus xogos, identifica os valiosos, premiaos e mantén os teus sistemas distribuídos funcionando de forma rápida e estable.
Fonte: www.habr.com