¿Qué es un juego de validación o “cómo lanzar una cadena de bloques de prueba de participación”?

Entonces, su equipo ha terminado la versión alfa de su blockchain y es hora de lanzar testnet y luego mainnet. Tienes una cadena de bloques real, con participantes independientes, un buen modelo económico, seguridad, has diseñado la gobernanza y ahora es el momento de probar todo esto en acción. En un mundo criptoanárquico ideal, pones el bloque génesis en la red, el código final del nodo y los propios validadores lanzan todo, levantan todos los servicios auxiliares y todo sucede por sí solo. Pero esto es en un mundo ficticio, pero en el mundo real, el equipo debe preparar una gran cantidad de software auxiliar y diversas manipulaciones para ayudar a los validadores a iniciar una red estable. De esto se trata este artículo.

El lanzamiento de redes basadas en consensos del tipo "prueba de participación", donde los validadores están determinados por los votos de los poseedores de tokens del sistema, es un evento bastante específico, porque incluso lanzar sistemas tradicionales administrados centralmente con decenas y cientos de servidores no es una tarea fácil. tarea en sí misma, y ​​​​la cadena de bloques debe iniciarse con el esfuerzo de participantes leales pero independientes. Y, si en una corporación, al inicio, los administradores tienen acceso completo a todas las máquinas, registros y monitoreo general, entonces los validadores no permitirán que nadie acceda a sus servidores y, muy probablemente, preferirán construir su infraestructura de forma independiente, porque controla el acceso. a los principales activos del validador: los votantes en juego. Es este comportamiento el que permite construir redes distribuidas seguras: la independencia de los proveedores de la nube utilizados, servidores virtuales y "baremetal", diferentes sistemas operativos, todo esto permite que los ataques a dicha red sean extremadamente ineficaces, demasiado diferentes. Se utiliza software. Por ejemplo, Ethereum utiliza dos implementaciones de nodos principales, en Go y en Rust, y un ataque que es efectivo para una implementación no funciona para la otra.

Por lo tanto, todos los procesos de lanzamiento y operación de blockchains deben organizarse de tal manera que cualquier validador, o incluso un pequeño grupo de validadores, pueda en cualquier momento tirar sus computadoras por la ventana e irse, mientras que nada debería romperse y los validadores restantes deberían Continuar apoyando eficazmente la red operativa y conectando nuevos validadores. Al iniciar una red, cuando un validador está en Europa, el segundo en América del Sur y el tercero en Asia, es bastante difícil lograr el trabajo coordinado de varias docenas de grupos independientes y, como resultado, interesarlos.

Validadores

Imaginemos el lanzamiento de una hipotética cadena de bloques moderna (la mayor parte de lo que se describe es adecuado para cadenas de bloques basadas en cualquier familia moderna de cadenas de bloques: Ethereum, EOS, Polkadot, Cosmos y otras, que brindan consenso de prueba de participación. Los personajes principales de Estas cadenas de bloques son equipos de validadores que se dedican a instalar sus propios servidores independientes que validan y producen nuevos bloques, y reciben recompensas proporcionadas por la red para quienes participan en el consenso. Para lanzar nuevas redes, se necesitan varias docenas de validadores (muchos ahora pueden hacerlo). llegar a un consenso de manera más o menos efectiva en segundos), por lo que el proyecto anuncia el registro, en el que los validadores comparten información pública sobre ellos mismos con los usuarios, convenciéndolos de que van a brindar un servicio de alta calidad a la red lanzada.

La validación es un negocio que le permite evaluar con extrema precisión los ingresos potenciales del validador, transferir rápidamente poder entre proyectos y, si la red que ha elegido tiene éxito, el validador puede, como participante de pleno derecho de la DAO y persona responsable, desarrollar el proyecto, o simplemente brindar un excelente servicio técnico por dinero completamente transparente y honestamente ganado. Al calcular la recompensa para los validadores, los proyectos intentan tener en cuenta los costos de los validadores y hacer que la recompensa por los bloques sea tal que este negocio sea rentable, pero al mismo tiempo no permite que los validadores derriben la economía inundándola con dinero y privando de ello a otros usuarios de la red.

El negocio de los validadores requiere garantizar una alta tolerancia a fallos de los servicios, lo que significa un alto nivel de formación para los devops y desarrolladores y costosos recursos informáticos. Incluso sin la necesidad de extraer hashes en redes de prueba de trabajo, un nodo blockchain es un gran servicio que ocupa mucha memoria, consume muchos cálculos, valida, escribe en el disco y envía grandes cantidades de datos a la red. . Para almacenar registros de transacciones y cadenas de bloques para una cadena de bloques con varios miles de pequeñas transacciones en un bloque, ahora se requiere un almacenamiento de 50 Gb o más, y para los bloques debe ser un SSD. La base de datos estatal de blockchains con soporte para contratos inteligentes ya puede superar los 64 Gb de RAM. Los servidores con las características requeridas son bastante caros; un nodo Ethereum o EOS puede costar entre 100 y 200 dólares al mes. A esto se suma el aumento de los salarios por el trabajo ininterrumpido de los desarrolladores y devops, que durante el período de lanzamiento resuelven problemas incluso de noche, ya que algunos validadores pueden ubicarse fácilmente en otro hemisferio. Sin embargo, en los momentos adecuados, poseer un nodo de validación puede generar importantes ingresos (en el caso de EOS, hasta 10 dólares al día).

La validación es sólo una de las nuevas funciones potenciales de TI para empresarios y empresas; a medida que los programadores idean algoritmos cada vez más sofisticados que premian la honestidad y castigan el fraude y el robo, aparecen servicios que realizan las funciones de publicar datos importantes (oráculos), realizar supervisión (reducción de depósitos y castigo a los tramposos mediante la publicación de pruebas de engaño), servicios de resolución de disputas, seguros y opciones, incluso la recolección de basura es un mercado potencialmente grande en sistemas de contratos inteligentes donde es necesario pagar por el almacenamiento de datos.

Problemas de lanzar una blockchain

La apertura de la cadena de bloques, que hizo posible que computadoras de cualquier país participaran libremente en la red y la facilidad de conectar cualquier script kiddie a la red según las instrucciones de GitHub, no siempre es una ventaja. La búsqueda de un nuevo token a menudo obliga a los validadores a "extraer una nueva moneda al principio", con la esperanza de que la tasa aumente y la oportunidad de deshacerse rápidamente de sus ganancias. Además, esto significa que su validador puede ser cualquiera, incluso una persona anónima; puede votar por él de la misma manera que por otros validadores (sin embargo, será difícil para una persona anónima recolectar los votos de las partes interesadas, por lo que Dejaremos las historias de miedo sobre las criptomonedas anónimas a los políticos). Sin embargo

El equipo del proyecto tiene una tarea: de alguna manera introducir en su red a aquellos que en el futuro sean capaces de garantizar el funcionamiento estable de los nodos, comprender la seguridad, saber resolver problemas rápidamente, cooperar con otros validadores y actuar juntos: la calidad de eso Todo depende totalmente de estas cualidades, un token en el que los participantes de la red van a invertir su tiempo y recursos. Los fundadores adecuados, al evaluar los riesgos, comprenden bien que al lanzar software de este tamaño, definitivamente tendrán que encontrar errores en el código y la configuración de los nodos, y que la estabilidad de la red depende de qué tan bien los desarrolladores y validadores resolverán conjuntamente. tales problemas.

El equipo está listo para votar en la red principal por cualquier validador, solo para saber cuáles son buenos. ¿La cartera más grande? Casi nadie lo tiene ahora. ¿Basado en los perfiles de Linkedin del equipo? Los devops experimentados o los especialistas en seguridad no le proporcionarán ningún perfil de Linkedin. ¿Según declaraciones en chat, publicaciones y ayudar a otros durante la fase de preparación? Bueno, pero subjetivo e inexacto.

En tales condiciones, queda una cosa, algo que resuelva bien los problemas de todos: un juego en el que será posible seleccionar los mejores validadores, pero lo principal es probar la resistencia de la cadena de bloques y realizar una prueba de combate a gran escala del blockchain en condiciones de uso activo, cambios de consenso, aparición y corrección de errores. Este procedimiento fue presentado por primera vez como un juego por los chicos del proyecto Cosmos, y esta idea es sin duda una excelente manera de preparar la red para el lanzamiento de una red principal confiable y tolerante a fallas.

Juego de validadores

Describiré el juego de validadores tal como lo diseñamos para la cadena de bloques DAO.Casino (DAOBet) basada en la bifurcación EOS, que se llama Haya y tiene un mecanismo de gobernanza similar: los validadores se eligen votando desde cualquier cuenta, en la que parte de el saldo utilizado para votar por el validador está congelado. Cualquier cuenta que tenga el token BET principal en su saldo puede votar por el validador seleccionado con cualquier parte de su saldo. Los votos se resumen y los principales validadores se crean en función de los resultados. En diferentes cadenas de bloques, este proceso se organiza de manera diferente y, por lo general, es en esta parte donde la nueva cadena de bloques se diferencia de la principal, y debo decir que en nuestro caso, EOS justifica plenamente el "OS" en su nombre, realmente usamos EOS. como sistema operativo base para la implementación de una versión modificada de blockchain para tareas DAOBet.

Describiré problemas individuales y cómo se pueden resolver dentro del juego. Imaginemos una red en la que su servidor puede ser atacado abiertamente, donde para mantener la posición de un validador necesita interactuar continuamente con la red, promocionando su validador y asegurándose de que produzca bloques y se entreguen a otros validadores en tiempo, de lo contrario el validador será eliminado de la lista.

¿Cómo elegir a los principales ganadores?

El principal requisito técnico del juego es que sus resultados sean públicamente verificables. Esto significa que los resultados del juego: TOP ganadores, deben formarse estrictamente sobre la base de datos que puedan ser verificados por cualquier participante. En un sistema centralizado, podríamos medir el "tiempo de actividad" de cada validador y recompensar a aquellos que estuvieron más en línea o pasaron por el máximo tráfico de red. Puede recopilar datos sobre la carga del procesador y la memoria y recompensar a quienes han trabajado bien. Pero cualquier recopilación de métricas de este tipo significa la existencia de un centro de recopilación, y todos los nodos son independientes y pueden comportarse como quieran y enviar cualquier dato.

Por lo tanto, la solución natural es que los ganadores se determinen basándose en los datos de la cadena de bloques, ya que con ellos se puede ver qué validador produjo qué bloque y qué transacciones se incluyeron en él. A este número lo llamamos Puntos de Validador (VP) y ganarlos es el objetivo principal de los validadores en el juego. En nuestro caso, la métrica más simple, fácilmente verificable públicamente y efectiva de la "utilidad" de un validador es VP = número de bloques producidos por el validador en un período de tiempo determinado.

Esta simple elección se debe al hecho de que la gobernanza en EOS ya prevé muchos problemas emergentes, ya que EOS es el heredero de tres generaciones de cadenas de bloques realmente funcionales con amplia experiencia en la gestión de redes complejas y casi cualquier problema de validación con la red, el procesador, disco conduce a un solo problema: firma menos bloques, recibe menos pago por el trabajo, lo que nuevamente nos lleva simplemente al número de bloques firmados; para EOS esta es una opción excelente y simple.

Para otras cadenas de bloques, la forma en que se calculan los puntos de validación puede diferir; por ejemplo, para los consensos basados ​​en pBFT (Tendermint/Cosmos, consenso Aura de Parity Substrate), donde cada bloque debe estar firmado por múltiples validadores, tiene sentido contar validadores individuales. firmas en lugar de bloques. Puede tener sentido tener en cuenta rondas de consenso incompletas, que desperdician los recursos de otros validadores, en general esto depende en gran medida del tipo de consenso.

Cómo simular condiciones de funcionamiento reales

La tarea de los fundadores es probar los validadores en condiciones cercanas a la realidad, sin tener ningún control centralizado. Este problema se puede resolver mediante un contrato faucet, que distribuye cantidades iguales del token principal a los validadores y a todos los demás. Para recibir tokens en su saldo, debe crear una transacción y asegurarse de que la red la incluya en el bloque. Por lo tanto, para ganar, un validador debe reponer constantemente su saldo con nuevos tokens y votar por sí mismo, promoviéndose a sí mismo hasta la cima. Esta actividad crea una carga constante en la red y los parámetros se pueden seleccionar para que el flujo de solicitudes sea lo suficientemente severo para una prueba completa de la red. Por lo tanto, planifique el contrato faucet con anticipación como una herramienta importante para lanzar la red y comience a seleccionar sus parámetros con anticipación.

Solicitar tokens de un faucet y validar votos aún no emula completamente el funcionamiento de una ojiva, especialmente en modos extremadamente cargados. Por lo tanto, el equipo de blockchain aún tendrá que escribir puntos de referencia adicionales de una forma u otra para cargar la red. Un papel especial en esto lo desempeñan los contratos inteligentes especialmente creados que permiten probar un subsistema separado. Para probar el almacenamiento, el contrato almacena datos aleatorios en la cadena de bloques, y para probar los recursos de la red, el contrato de prueba requiere una gran cantidad de datos de entrada, inflando así el volumen de transacciones, al iniciar un flujo de dichas transacciones en momentos arbitrarios en el tiempo. el equipo prueba simultáneamente la estabilidad del código y la solidez de los validadores.

Un tema aparte es la actualización del código de los nodos y la realización de bifurcaciones duras. Se requiere que en caso de un error, vulnerabilidad o colusión de validadores maliciosos, los validadores tengan un plan de acción que ya haya sido elaborado en el juego de validadores. Aquí puede idear esquemas para acumular VP por aplicar rápidamente un hard fork, por ejemplo, multando a todos los validadores que aún no han implementado una nueva versión del código del nodo, pero esto es difícil de implementar y complica el cálculo. Puede simular la situación de un uso de emergencia de un hard fork "rompiendo" artificialmente la cadena de bloques en un bloque determinado. La producción de bloques se detiene y, al final, los ganadores serán aquellos que salten primero y comiencen a firmar bloques, por lo que el vicepresidente basado en la cantidad de bloques firmados encaja bien aquí.

Cómo informar a los participantes sobre el estado de la red y corregir errores

A pesar de la desconfianza entre los validadores, la recepción oportuna de información actualizada sobre el estado de la red es beneficiosa para todos para poder tomar decisiones más rápidamente, por lo que el equipo del proyecto está planteando un servicio para recopilar y visualizar muchas métricas de los servidores de validación. lo que le permite ver la situación simultáneamente para toda la red, permitiéndole determinar rápidamente lo que está sucediendo. Además, es beneficioso tanto para los validadores como para el proyecto que el equipo del proyecto corrija rápidamente los errores encontrados, por lo que además de recopilar métricas, tiene sentido comenzar inmediatamente a recopilar registros y datos de errores de las máquinas de los validadores en una máquina accesible a blockchain. desarrolladores. En este caso, no es beneficioso para nadie distorsionar la información, por lo que estos servicios son desarrollados por el equipo del proyecto y se puede confiar en ellos. Tiene sentido recopilar métricas del sistema de los validadores y, por supuesto, las métricas más importantes de la cadena de bloques en sí (para DAOBet) son el tiempo de finalización y el retraso del último bloque finalizado. Gracias a esto, el equipo ve un aumento en el consumo de memoria en los nodos al ejecutar el benchmark, problemas con los validadores individuales

Puntos importantes para realizar un juego de validación

Resulta que si desea permitir oficialmente que los validadores ataquen las máquinas de otros (extraoficialmente pueden hacerlo de todos modos), debe formular esto por separado legalmente como prueba de seguridad, ya que según las leyes de algunos países, los ataques DDoS o de red pueden ser castigado. Otra cuestión importante es cómo recompensar a los validadores. Los premios naturales son tokens de proyecto, que se transferirán a la red principal, pero una distribución masiva de tokens a cualquiera que haya podido lanzar un nodo tampoco es la mejor opción. Lo más probable es que tengas que hacer un equilibrio entre dos opciones extremas:

Distribuya todo el premio acumulado según los VP obtenidos.
Es muy democrático y permite que todos los que hayan invertido tiempo y recursos en el juego del validador ganen dinero.
pero atrae a personas aleatorias al juego sin una infraestructura preparada

Distribuya el premio acumulado de los N primeros a los validadores según los resultados del juego.
Lo más probable es que los ganadores sean los validadores que duren más consistentemente durante el juego y que estén estrictamente decididos a ganar.
Algunos validadores no querrán participar, evaluando poco sus posibilidades de ganar, especialmente si entre los participantes hay validadores venerables.

La opción que elijas depende de ti.

Hay un punto más: no es en absoluto un hecho que docenas de validadores se apresurarán a participar en el juego cuando usted los llame, y de aquellos que decidan intentarlo, ni siquiera todos instalarán y ejecutarán el nodo; En esta etapa, los proyectos tienen documentación bastante escasa, se encuentran errores y los desarrolladores que trabajan bajo presión de tiempo no responden las preguntas muy rápidamente. Por lo tanto, antes de iniciar el juego, también es necesario prever acciones si no se alcanza el número requerido de validadores. En este caso, al comienzo del juego, los validadores que faltan son lanzados por el equipo del proyecto, participan en el consenso, pero no pueden ser ganadores.

Conclusión

En conclusión, traté de compilar a partir de lo anterior una lista de lo que se debe pensar, fabricar y lanzar para llevar a cabo de manera efectiva un juego de validación.

Lo que debes hacer para ejecutar un juego de validación real:
desarrolla tu propia cadena de bloques :)

  • Crear y crear una interfaz web y proporcionar una CLI para votar por validadores.
  • asegúrese de que las métricas de un nodo validador en ejecución se puedan enviar a un servicio centralizado (por ejemplo, Prometheus)
  • crear un servidor de recopilación de métricas (Prometheus + Grafana) para el juego del validador
  • descubrir cómo se calcularán los puntos de validación (VP)
  • desarrollar un script público que calcule el VP del validador basándose en datos de blockchain
  • Desarrollar una interfaz web para mostrar los mejores validadores y el estado del juego de los validadores (cuánto tiempo queda hasta el final, quién tiene cuántos VP, etc.)
  • desarrollar y automatizar el lanzamiento de un número arbitrario de sus propios nodos, diseñar el proceso de conexión de validadores al juego (cuándo y cómo desconectar sus nodos, enviar y eliminar votos para ellos)
  • calcular cuántos tokens deben emitirse y desarrollar un contrato faucet
  • crear un script de referencia (transferencias de tokens, uso masivo de almacenamiento, uso masivo de la red)
  • reúna a todos los participantes en un chat para una comunicación rápida
  • Inicie la cadena de bloques un poco antes del inicio del juego.
  • espera el bloque inicial, comienza el juego
  • probar la red con varios tipos de transacciones
  • desplegar un tenedor duro
  • cambiar la lista de validadores
  • repita los pasos 13,14,15, XNUMX, XNUMX en diferentes órdenes, manteniendo la estabilidad de la red
  • espera el bloque final, finaliza el juego, cuenta VP

Hay que decir que el juego de los validadores es una historia nueva y se realizó solo un par de veces, por lo que no debes tomar este texto como una guía ya preparada. No hay análogos en el negocio de TI moderno: imagine que los bancos, antes de lanzar un sistema de pago, compiten entre sí para ver quién será el mejor en realizar las transacciones de los clientes. Es poco probable que los enfoques tradicionales le ayuden a crear grandes redes descentralizadas, así que domine nuevos modelos de negocio, ejecute sus juegos, identifique los que valen la pena, recompénselos y mantenga sus sistemas distribuidos funcionando de forma rápida y estable.

Fuente: habr.com

Añadir un comentario