Así que su equipo ha terminado la versión alpha de su blockchain, y ha llegado el momento de lanzar el testnet, y luego el mainnet. Tienen un blockchain auténtico, con participantes independientes, un buen modelo económico, seguridad, han diseñado la gobernanza y ahora es hora de probar todo esto en acción. En un mundo criptoanarquista ideal, se publican en la red el bloque génesis, el código final del nodo y los validadores hacen todo el lanzamiento, levantan todos los servicios auxiliares y todo sucede por sí solo. Pero este es un mundo ficticio, y en la realidad, el equipo debe preparar bastante software auxiliar y realizar varias manipulaciones para ayudar a los validadores a lanzar una red sostenible. De esto trata este artículo.
Lanzar redes basadas en consensos como "prueba de participación", donde los validadores son determinados por los votos de los poseedores de tokens del sistema es un evento bastante específico, ya que incluso el lanzamiento de sistemas tradicionales, gestionados de manera centralizada, con decenas y cientos servidores es en sí misma una tarea compleja, y el blockchain debe iniciarse gracias a los esfuerzos de participantes leales pero independientes. Y, si en una corporación, al iniciar, los administradores tienen acceso total a todas las máquinas, registros, monitoreo en general, los validadores no permitirán a nadie acceder a sus servidores y, lo más probable, preferirán construir su infraestructura de manera independiente, ya que controla el acceso a los activos principales del validador: sus participaciones en la votación. Este comportamiento es lo que permite construir redes seguras y distribuidas: la independencia de los proveedores de nube utilizados, servidores virtuales y “bare metal”, diferentes sistemas operativos, todo esto hace que los ataques a dicha red sean extremadamente ineficaces: se utiliza demasiado software diferente. Por ejemplo, en Ethereum se utilizan dos implementaciones principales del nodo, una en Go y otra en Rust, y un ataque eficaz para una implementación no funciona para la otra.
Por lo tanto, todos los procesos de inicio y operación de blockchain 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 y marcharse, sin que nada se rompa y los validadores restantes continúen apoyando eficazmente el funcionamiento de la red y conectando nuevos validadores. Al iniciar la red, cuando hay un validador en Europa, otro en América del Sur y un tercero en Asia, lograr que varios grupos independientes trabajen de manera coordinada y motivarlos con los resultados es bastante complicado.
Validadores
Imaginemos el lanzamiento de una hipotética blockchain moderna (la mayor parte de lo descrito se aplica a blockchains basadas en cualquier familia moderna de blockchains: Ethereum, EOS, Polkadot, Cosmos y otras, que emplean un consenso de proof-of-stake. Los principales actores de estas blockchains son los equipos de validadores que instalan sus propios servidores independientes, validan y generan nuevos bloques, y reciben las recompensas que la red prevé para aquellos que participan en el consenso. Para iniciar nuevas redes, se requieren varios tens de validadores (la cantidad que actualmente puede alcanzar un consenso de manera más o menos eficaz en segundos), por lo que el proyecto anuncia registros, en los cuales los validadores comparten información pública sobre sí mismos con los usuarios, convenciendo a estos de que tienen la intención de brindar un servicio de calidad para la red que están lanzando.
La validación es un negocio que permite evaluar con gran precisión el ingreso potencial de un validador, transferir rápidamente recursos entre proyectos y, en caso de éxito en la red elegida, el validador puede, como un participante pleno de DAO y responsable, desarrollar el proyecto, o simplemente proporcionar un excelente servicio técnico por un dinero completamente transparente y honestamente ganado. Al calcular la recompensa para los validadores, los proyectos tratan de tener en cuenta los costos de los validadores y hacer que la recompensa por bloque sea rentable para este negocio, pero al mismo tiempo no permitir que los validadores colapsen la economía inundándola de dinero y privando a los demás usuarios de la red.
El negocio de los validadores requiere garantizar una alta disponibilidad de servicios, lo que significa un alto nivel de preparación de los DevOps y desarrolladores, así como recursos computacionales costosos. Incluso sin la necesidad de minar hashes en redes proof-of-work, un nodo de blockchain es un gran servicio que ocupa mucha memoria, consume muchos cálculos, valida, registra en disco y transmite grandes volúmenes de datos a la red. Para almacenar el registro de transacciones y cadenas de bloques para una blockchain con varios miles de transacciones pequeñas por bloque, se requiere actualmente un almacenamiento de al menos 50 Gb o más, y para los bloques, debe ser un SSD. La base de datos de estado de blockchains con soporte para contratos inteligentes ya puede superar los 64 Gb de memoria RAM. Los servidores con estas características son bastante costosos; un nodo de Ethereum o EOS puede costar entre 100 y 200 $ por mes. Añade a esto el aumento de los salarios para el trabajo 24/7 de los desarrolladores y DevOps, quienes durante el lanzamiento resuelven problemas incluso de noche, ya que parte de los validadores puede estar en el hemisferio opuesto. Sin embargo, en momentos afortunados, poseer un nodo validador puede generar ingresos significativos (en el caso de EOS, hasta 10,000 $ por día).
El validacionismo es solo uno de los nuevos roles potenciales en TI para emprendedores y empresas. A medida que los programadores diseñan algoritmos cada vez más sofisticados que permiten recompensar la honestidad y castigar el fraude y el robo, aparecen servicios que cumplen funciones como la publicación de datos importantes (oráculos), supervisión (slashing de depósitos y castigo a los engañadores mediante la publicación de pruebas de fraude), 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 lanzamiento de blockchain
La apertura del blockchain, que permite la participación libre en la red de computadoras de cualquier país y la facilidad de conexión para cualquier script kiddie siguiendo instrucciones de GitHub, no siempre es una ventaja. La búsqueda de un nuevo token a menudo lleva a los validadores a "minar una nueva moneda desde el inicio", con la esperanza de que su valor aumente y poder vender rápidamente lo obtenido. Esto también significa que cualquiera, incluso un anónimo, puede ser tu validador; se puede votar por él de la misma manera que por otros validadores (aunque a un anónimo le será difícil conseguir votos de los stakeholders, dejemos las historias aterradoras sobre criptomonedas anónimas para los políticos). Sin embargo,
El equipo del proyecto tiene la tarea de conseguir en su red a aquellos que en el futuro puedan garantizar un funcionamiento estable de los nodos, que comprendan de seguridad, resuelvan problemas rápidamente, se cooperen con otros validadores y actúen en conjunto; la calidad del token en el que los participantes de la red planean invertir su tiempo y recursos depende completamente de estas cualidades. Los fundadores responsables, evaluando los riesgos, comprenden bien que al lanzar un software de tal magnitud se enfrentarán inevitablemente a errores en el código, en la configuración de los nodos, y que la estabilidad de la red depende de cuán bien los desarrolladores y validadores trabajen juntos para resolver dichos problemas.
El equipo está listo para votar en el mainnet por cualquier validador, solo que necesitaríamos saber por quiénes, ¿cuáles son los buenos? ¿Los que tienen el portafolio más grande? Casi nadie lo tiene ahora. ¿Por los perfiles del equipo en Linkedin? Los DevOps o especialistas en seguridad experimentados no te proporcionarán perfiles en Linkedin. ¿Por sus declaraciones en el chat, publicaciones y ayuda a otros en la fase de preparación? Está bien, pero es subjetivo e impreciso.
En estas condiciones, solo queda una opción: un juego que resuelva los problemas de todos, en el que se puedan seleccionar los mejores validadores, pero lo principal es poner a prueba la robustez del blockchain y realizar una prueba de batalla a gran escala del blockchain en condiciones de uso activo, cambios en el consenso, aparición y corrección de errores. Esta propuesta fue presentada por primera vez como un juego por el equipo del proyecto Cosmos, y esta idea es sin duda una excelente manera de preparar la red para el lanzamiento de un mainnet confiable y resistente a fallos.
Juego de Validadores
Voy a describir el juego de validadores tal como lo diseñamos para la blockchain DAO.Casino (DAOBet) basada en un fork de EOS, que se llama Haya y tiene un mecanismo de gobernanza similar: los validadores son elegidos a través de votaciones desde cualquier cuenta, donde parte del saldo utilizado para votar por un validador se congela. Cualquier cuenta que tenga como saldo el token principal BET puede votar por el validador elegido con cualquier parte de su saldo. Los votos se suman y se construye una lista de los principales validadores. En diferentes blockchains, este proceso está organizado de diversas maneras, y generalmente es en esta parte donde la nueva blockchain se diferencia de la originaria. Debo decir que en nuestro caso, EOS justifica totalmente el “OS” en su nombre; realmente utilizamos EOS como sistema operativo base para desplegar una versión modificada de la blockchain para las necesidades de DAOBet.
Describiré problemas específicos y cómo se pueden resolver dentro del juego. Imaginemos una red en la que tu servidor puede ser atacado abiertamente, donde para mantener la posición de validador necesitas interactuar continuamente con la red, promoviendo tu validador y asegurándote de que produzca bloques y que estos se entreguen a tiempo a los demás validadores; de lo contrario, el validador será expulsado 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: los principales ganadores, deben formarse estrictamente con base en datos que cualquier participante pueda verificar. En un sistema centralizado, podríamos medir el “uptime” de cada validador y recompensar a aquellos que estuvieran más en línea o que hubieran manejado la mayor cantidad de tráfico de red. Se pueden recopilar datos sobre la carga del CPU, la memoria y recompensar a quienes trabajaron diligentemente. Sin embargo, cualquier recolección de métricas implica la existencia de un centro de recopilación, y las nodos son independientes y pueden comportarse como deseen y enviar cualquier dato.
Por lo tanto, la solución natural es que los ganadores deben ser determinados por los datos de la blockchain, ya que a través de ellos se puede ver quién de los validadores produjo qué bloque y qué transacciones fueron incluidas en él. Llamamos a este número Puntos de Validador (VP), y acumularlos es el objetivo principal de los validadores en el juego. En nuestro caso, la métrica de 'utilidad' del validador más simple, fácilmente verificable públicamente y efectiva es VP = número_de_bloques_producidos_por_el_validador en un período de tiempo determinado.
Esta elección tan simple se debe a que la gobernanza en EOS ya contempla muchos problemas que surgen, ya que EOS es el heredero de tres generaciones de blockchains que funcionan realmente, con una gran experiencia en la gestión compleja de la red, y prácticamente cualquier problema del validador con la red, el procesador o el disco conduce a un solo problema: firma menos bloques, recibe una menor remuneración por su trabajo, lo que nos lleva nuevamente simplemente al número de bloques firmados; para EOS, esta es una excelente y sencilla opción.
En otras blockchains, la forma de contar los Puntos de Validador puede diferir; por ejemplo, para consensos basados en pBFT (Tendermint/Cosmos, consenso Aura de Parity Substrate), donde cada bloque debe ser firmado por múltiples validadores, tiene sentido contar las firmas individuales de los validadores y no los bloques. También podría tener sentido considerar rondas de consenso no completadas que consumen recursos de otros validadores; en general, esto depende mucho del tipo de consenso.
Cómo modelar condiciones reales de operación
La tarea de los fundadores es verificar a los validadores en condiciones que se asemejen a la realidad, sin tener ningún control centralizado. Este problema se puede resolver mediante un contrato-faucet que reparte cantidades iguales del token principal a los validadores y a todos los interesados. Para recibir tokens en el saldo, es necesario formar una transacción y lograr que la red la incluya en un bloque. De este modo, el validador debe constantemente aumentar su saldo con nuevos tokens y votar por sí mismo para ascender en la clasificación. Esta actividad crea una carga constante en la red, y se pueden ajustar los parámetros de tal manera que el flujo de solicitudes sea lo suficientemente serio para una prueba completa de la red. Por lo tanto, planifique el contrato-faucet con anticipación, como una herramienta importante para el lanzamiento de la red y comience a ajustar sus parámetros desde antes.
La solicitud de tokens del faucet y la votación de los validadores, de todas formas, no emula completamente de manera justa el funcionamiento de la cadena de bloques, especialmente en modos de carga extrema. Por lo tanto, el equipo de la cadena de bloques tendrá que redactar benchmarks adicionales que permitan cargar la red. Los contratos inteligentes creados específicamente con anticipación juegan un papel crucial en esto, permitiendo probar subsistemas individuales. Para probar el almacenamiento, el contrato guarda datos aleatorios en la cadena de bloques, y para verificar los recursos de la red, el contrato de prueba requiere un gran volumen de datos de entrada, aumentando así el número de transacciones; al lanzar este flujo de transacciones en momentos aleatorios, el equipo prueba simultáneamente la estabilidad del código y la resistencia de los validadores.
Una cuestión aparte es la actualización del código de los nodos y la realización de hard forks. Es necesario que, en caso de aparecer un error, vulnerabilidad o colusión de validadores malintencionados, los validadores tengan un plan de acción ya ensayado en la práctica de la validación. Aquí se pueden idear esquemas para otorgar VP por la rápida implementación de un hard fork, por ejemplo, penalizando a todos los validadores que aún no hayan actualizado a la nueva versión del código del nodo, aunque esto es difícil de implementar y complica el cálculo. Simular una situación de aplicación de emergencia de un hard fork se puede hacer artificialmente “rompiendo” la blockchain en un bloque específico. La producción de bloques se detiene, y al final saldrán beneficiados aquellos que se integren antes y comiencen a firmar bloques, así que el VP basado en el número de bloques firmados se adapta 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, recibir información actualizada sobre el estado de la red de manera oportuna beneficia a todos para tomar decisiones más rápidamente, por lo que el equipo del proyecto establece un servicio para recopilar y visualizar múltiples métricas desde los servidores de los validadores, lo que permite ver la situación de toda la red al mismo tiempo, facilitando así la identificación de lo que está sucediendo. Además, tanto a los validadores como al proyecto les conviene que el equipo del proyecto solucione rápidamente los errores detectados, por lo que, junto con la recopilación de métricas, tiene sentido iniciar de inmediato la recolección de registros y datos de errores desde las máquinas de los validadores hacia una máquina accesible para los desarrolladores de la blockchain. Aquí a nadie le interesa distorsionar la información, por lo que estos servicios son gestionados por el equipo del proyecto y son de confianza. Tiene sentido recopilar métricas del sistema de los validadores y, sin falta, las métricas más importantes de la blockchain en sí: para DAOBet, esto incluye el tiempo de finalización y el retraso del último bloque finalizado. Gracias a esto, el equipo puede ver el aumento en el consumo de memoria en los nodos al ejecutar el benchmark, así como los problemas de validadores individuales.
Puntos importantes sobre la realización de la práctica de validadores
Como resultó, si desea permitir oficialmente a los validadores atacar entre sí (de manera no oficial, ya pueden hacerlo) — es necesario formularlo de forma legal como una prueba de seguridad, ya que según la legislación de algunos países, las sanciones pueden aplicarse por DDoS o ataques en red. Otra cuestión importante es cómo recompensar a los validadores. Una de las formas más naturales de premio son los tokens del proyecto, que se transferirán a mainnet, pero la distribución masiva de tokens a cualquiera que logre lanzar un nodo no es la mejor opción. Es probable que tenga que equilibrar entre dos extremos.
Distribuir todo el fondo de premios de acuerdo con los VP ganados.
esto es muy democrático y permite ganar a todos los que han invertido tiempo y recursos en el juego de los validadores.
pero atrae al juego a personas al azar sin la infraestructura adecuada.
Distribuir el fondo de premios a los validadores top-N según los resultados del juego.
es probable que los ganadores sean los validadores que se mantuvieron más estables durante el juego, muy motivados para ganar.
parte de los validadores no querrá participar, subestimando sus posibilidades de ganar, especialmente si hay validadores de renombre entre los participantes.
A cuál opción preferir, es su decisión.
Hay otro punto — no es seguro que decenas de validadores se lancen a participar en el juego a su llamado, y de aquellos que decidan intentarlo, no todos incluso instalarán y lanzarán un nodo — por lo general, en esta etapa, los proyectos tienen una documentación bastante escasa, surgen errores, y los desarrolladores que trabajan a contrarreloj no responden a las preguntas de manera muy rápida. Por lo tanto, antes de comenzar el juego, también debe prever acciones en caso de que no se logre reunir el número necesario de validadores. En este caso, al inicio del juego, los validadores que falten son lanzados por el equipo del proyecto, participan en el consenso, pero no pueden ser ganadores.
Conclusión
En conclusión, he tratado de reunir de lo anterior una lista de lo que se necesita inventar, hacer y lanzar para llevar a cabo eficazmente el juego de validadores.
Lo que se necesita hacer para lanzar un verdadero juego de validadores:
desarrollar su propia blockchain 🙂
- crear y levantar una interfaz web y proporcionar una CLI para votar por los validadores.
- Hacer que las métricas de un nodo validador en funcionamiento puedan enviarse a un servicio centralizado (por ejemplo, Prometheus)
- Levantar un servidor de recolección de métricas (Prometheus + Grafana) para el juego de validadores
- Inventar cómo se calcularán los Punto de Validador (VP)
- Desarrollar un script público que calcule los VP de los validadores basado en datos de blockchain
- Desarrollar una interfaz web para mostrar el ranking de validadores y el estado del juego de validadores (cuánto tiempo queda, cuántos VP tiene cada uno, etc.)
- Desarrollar y automatizar el lanzamiento de un número arbitrario de nodos propios, diseñar el proceso de conexión de validadores al juego (cuándo y cómo desconectar sus nodos, emitir y retirar votos por ellos)
- Calcular cuántos tokens deben emitirse y desarrollar un contrato-faucet
- Crear un script de benchmarking (transferencias de tokens, uso masivo de almacenamiento, uso masivo de red)
- Reunir a todos los participantes en un chat para facilitar la comunicación rápida
- Lanzar la blockchain un poco antes de empezar el juego
- Esperar el bloque inicial, comenzar el juego
- Probar la red con varios tipos de transacciones
- Ejecutar el hard fork
- Modificar la lista de validadores
- Repetir los puntos 13, 14, 15 en diferente orden, manteniendo la estabilidad de la red
- Esperar el bloque final, terminar el juego, contar los VP
Es importante mencionar que el juego de validadores es algo nuevo y se ha llevado a cabo solo un par de veces, por lo que no se debe considerar este texto como una guía definitiva. No existen análogos en el negocio de TI moderno; imagina que los bancos compiten antes de lanzar un sistema de pagos, tratando de ver quién puede procesar mejor las transacciones de los clientes. Los enfoques tradicionales probablemente no te ayudarán a crear grandes redes descentralizadas, así que adopta nuevos modelos comerciales, organiza tus juegos, identifica a los dignos, recompénsalos y permite que tus sistemas distribuidos funcionen rápido y de manera estable.
Fuente: habr.com
