servidores<\/a> es en s\u00ed misma una tarea compleja, y el blockchain debe iniciarse gracias a los esfuerzos de participantes leales pero independientes. Y, si en una corporaci\u00f3n, al iniciar, los administradores tienen acceso total a todas las m\u00e1quinas, registros, monitoreo en general, los validadores no permitir\u00e1n a nadie acceder a sus servidores y, lo m\u00e1s probable, preferir\u00e1n construir su infraestructura de manera independiente, ya que controla el acceso a los activos principales del validador: sus participaciones en la votaci\u00f3n. Este comportamiento es lo que permite construir redes seguras y distribuidas: la independencia de los proveedores de nube utilizados, servidores virtuales y \u201cbare metal\u201d, 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\u00f3n no funciona para la otra.<\/p>\n<\/p>\n
Por lo tanto, todos los procesos de inicio y operaci\u00f3n de blockchain deben organizarse de tal manera que cualquier validador, o incluso un peque\u00f1o 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\u00faen apoyando eficazmente el funcionamiento de la red y conectando nuevos validadores. Al iniciar la red, cuando hay un validador en Europa, otro en Am\u00e9rica del Sur y un tercero en Asia, lograr que varios grupos independientes trabajen de manera coordinada y motivarlos con los resultados es bastante complicado. <\/p>\n
<\/p>\n
Validadores<\/h2>\n <\/p>\n
Imaginemos el lanzamiento de una hipot\u00e9tica 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\u00e9 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\u00e1s o menos eficaz en segundos), por lo que el proyecto anuncia registros, en los cuales los validadores comparten informaci\u00f3n p\u00fablica sobre s\u00ed mismos con los usuarios, convenciendo a estos de que tienen la intenci\u00f3n de brindar un servicio de calidad para la red que est\u00e1n lanzando.<\/p>\n
<\/p>\n
La validaci\u00f3n es un negocio que permite evaluar con gran precisi\u00f3n el ingreso potencial de un validador, transferir r\u00e1pidamente recursos entre proyectos y, en caso de \u00e9xito 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\u00e9cnico 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\u00eda inund\u00e1ndola de dinero y privando a los dem\u00e1s usuarios de la red.<\/p>\n
<\/p>\n
El negocio de los validadores requiere garantizar una alta disponibilidad de servicios, lo que significa un alto nivel de preparaci\u00f3n de los DevOps y desarrolladores, as\u00ed 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\u00e1lculos, valida, registra en disco y transmite grandes vol\u00famenes de datos a la red. Para almacenar el registro de transacciones y cadenas de bloques para una blockchain con varios miles de transacciones peque\u00f1as por bloque, se requiere actualmente un almacenamiento de al menos 50 Gb o m\u00e1s, 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\u00edsticas son bastante costosos; un nodo de Ethereum o EOS puede costar entre 100 y 200 $ por mes. A\u00f1ade 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\u00eda).<\/p>\n
<\/p>\n
El validacionismo es solo uno de los nuevos roles potenciales en TI para emprendedores y empresas. A medida que los programadores dise\u00f1an algoritmos cada vez m\u00e1s sofisticados que permiten recompensar la honestidad y castigar el fraude y el robo, aparecen servicios que cumplen funciones como la publicaci\u00f3n de datos importantes (or\u00e1culos), supervisi\u00f3n (slashing de dep\u00f3sitos y castigo a los enga\u00f1adores mediante la publicaci\u00f3n de pruebas de fraude), servicios de resoluci\u00f3n de disputas, seguros y opciones; incluso la recolecci\u00f3n de basura es un mercado potencialmente grande en sistemas de contratos inteligentes, donde es necesario pagar por el almacenamiento de datos. <\/p>\n
<\/p>\n
Problemas de lanzamiento de blockchain<\/h2>\n <\/p>\n
La apertura del blockchain, que permite la participaci\u00f3n libre en la red de computadoras de cualquier pa\u00eds y la facilidad de conexi\u00f3n para cualquier script kiddie siguiendo instrucciones de GitHub, no siempre es una ventaja. La b\u00fasqueda 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\u00e1pidamente lo obtenido. Esto tambi\u00e9n significa que cualquiera, incluso un an\u00f3nimo, puede ser tu validador; se puede votar por \u00e9l de la misma manera que por otros validadores (aunque a un an\u00f3nimo le ser\u00e1 dif\u00edcil conseguir votos de los stakeholders, dejemos las historias aterradoras sobre criptomonedas an\u00f3nimas para los pol\u00edticos). Sin embargo,<\/p>\n
<\/p>\n
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\u00e1pidamente, se cooperen con otros validadores y act\u00faen 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\u00e1n inevitablemente a errores en el c\u00f3digo, en la configuraci\u00f3n de los nodos, y que la estabilidad de la red depende de cu\u00e1n bien los desarrolladores y validadores trabajen juntos para resolver dichos problemas.<\/p>\n
<\/p>\n
El equipo est\u00e1 listo para votar en el mainnet por cualquier validador, solo que necesitar\u00edamos saber por qui\u00e9nes, \u00bfcu\u00e1les son los buenos? \u00bfLos que tienen el portafolio m\u00e1s grande? Casi nadie lo tiene ahora. \u00bfPor los perfiles del equipo en Linkedin? Los DevOps o especialistas en seguridad experimentados no te proporcionar\u00e1n perfiles en Linkedin. \u00bfPor sus declaraciones en el chat, publicaciones y ayuda a otros en la fase de preparaci\u00f3n? Est\u00e1 bien, pero es subjetivo e impreciso.<\/p>\n
<\/p>\n
En estas condiciones, solo queda una opci\u00f3n: 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\u00f3n y correcci\u00f3n 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.<\/p>\n
<\/p>\n
Juego de Validadores<\/h2>\n <\/p>\n
Voy a describir el juego de validadores tal como lo dise\u00f1amos 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\u00e9s 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\u00e1 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 \u201cOS\u201d en su nombre; realmente utilizamos EOS como sistema operativo base para desplegar una versi\u00f3n modificada de la blockchain para las necesidades de DAOBet.<\/p>\n
<\/p>\n
Describir\u00e9 problemas espec\u00edficos y c\u00f3mo se pueden resolver dentro del juego. Imaginemos una red en la que tu servidor puede ser atacado abiertamente, donde para mantener la posici\u00f3n de validador necesitas interactuar continuamente con la red, promoviendo tu validador y asegur\u00e1ndote de que produzca bloques y que estos se entreguen a tiempo a los dem\u00e1s validadores; de lo contrario, el validador ser\u00e1 expulsado de la lista.<\/p>\n
<\/p>\n
\u00bfC\u00f3mo elegir a los principales ganadores?<\/h3>\n <\/p>\n
El principal requisito t\u00e9cnico del juego es que sus resultados sean p\u00fablicamente 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\u00edamos medir el \u201cuptime\u201d de cada validador y recompensar a aquellos que estuvieran m\u00e1s en l\u00ednea o que hubieran manejado la mayor cantidad de tr\u00e1fico de red. Se pueden recopilar datos sobre la carga del CPU, la memoria y recompensar a quienes trabajaron diligentemente. Sin embargo, cualquier recolecci\u00f3n de m\u00e9tricas implica la existencia de un centro de recopilaci\u00f3n, y las nodos son independientes y pueden comportarse como deseen y enviar cualquier dato.<\/p>\n
<\/p>\n
Por lo tanto, la soluci\u00f3n natural es que los ganadores deben ser determinados por los datos de la blockchain, ya que a trav\u00e9s de ellos se puede ver qui\u00e9n de los validadores produjo qu\u00e9 bloque y qu\u00e9 transacciones fueron incluidas en \u00e9l. Llamamos a este n\u00famero Puntos de Validador (VP), y acumularlos es el objetivo principal de los validadores en el juego. En nuestro caso, la m\u00e9trica de 'utilidad' del validador m\u00e1s simple, f\u00e1cilmente verificable p\u00fablicamente y efectiva es VP = n\u00famero_de_bloques_producidos_por_el_validador en un per\u00edodo de tiempo determinado.<\/p>\n
<\/p>\n
Esta elecci\u00f3n 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\u00f3n compleja de la red, y pr\u00e1cticamente cualquier problema del validador con la red, el procesador o el disco conduce a un solo problema: firma menos bloques, recibe una menor remuneraci\u00f3n por su trabajo, lo que nos lleva nuevamente simplemente al n\u00famero de bloques firmados; para EOS, esta es una excelente y sencilla opci\u00f3n.<\/p>\n
<\/p>\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\u00faltiples validadores, tiene sentido contar las firmas individuales de los validadores y no los bloques. Tambi\u00e9n podr\u00eda tener sentido considerar rondas de consenso no completadas que consumen recursos de otros validadores; en general, esto depende mucho del tipo de consenso. <\/p>\n
<\/p>\n
C\u00f3mo modelar condiciones reales de operaci\u00f3n<\/h3>\n <\/p>\n
La tarea de los fundadores es verificar a los validadores en condiciones que se asemejen a la realidad, sin tener ning\u00fan 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\u00f3n 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\u00ed mismo para ascender en la clasificaci\u00f3n. Esta actividad crea una carga constante en la red, y se pueden ajustar los par\u00e1metros 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\u00f3n, como una herramienta importante para el lanzamiento de la red y comience a ajustar sus par\u00e1metros desde antes.<\/p>\n
<\/p>\n
La solicitud de tokens del faucet y la votaci\u00f3n 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\u00e1 que redactar benchmarks adicionales que permitan cargar la red. Los contratos inteligentes creados espec\u00edficamente con anticipaci\u00f3n 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\u00ed el n\u00famero de transacciones; al lanzar este flujo de transacciones en momentos aleatorios, el equipo prueba simult\u00e1neamente la estabilidad del c\u00f3digo y la resistencia de los validadores.<\/p>\n
<\/p>\n
Una cuesti\u00f3n aparte es la actualizaci\u00f3n del c\u00f3digo de los nodos y la realizaci\u00f3n de hard forks. Es necesario que, en caso de aparecer un error, vulnerabilidad o colusi\u00f3n de validadores malintencionados, los validadores tengan un plan de acci\u00f3n ya ensayado en la pr\u00e1ctica de la validaci\u00f3n. Aqu\u00ed se pueden idear esquemas para otorgar VP por la r\u00e1pida implementaci\u00f3n de un hard fork, por ejemplo, penalizando a todos los validadores que a\u00fan no hayan actualizado a la nueva versi\u00f3n del c\u00f3digo del nodo, aunque esto es dif\u00edcil de implementar y complica el c\u00e1lculo. Simular una situaci\u00f3n de aplicaci\u00f3n de emergencia de un hard fork se puede hacer artificialmente \u201crompiendo\u201d la blockchain en un bloque espec\u00edfico. La producci\u00f3n de bloques se detiene, y al final saldr\u00e1n beneficiados aquellos que se integren antes y comiencen a firmar bloques, as\u00ed que el VP basado en el n\u00famero de bloques firmados se adapta bien aqu\u00ed.<\/p>\n
<\/p>\n
<\/p>\n
A pesar de la desconfianza entre los validadores, recibir informaci\u00f3n actualizada sobre el estado de la red de manera oportuna beneficia a todos para tomar decisiones m\u00e1s r\u00e1pidamente, por lo que el equipo del proyecto establece un servicio para recopilar y visualizar m\u00faltiples m\u00e9tricas desde los servidores de los validadores, lo que permite ver la situaci\u00f3n de toda la red al mismo tiempo, facilitando as\u00ed la identificaci\u00f3n de lo que est\u00e1 sucediendo. Adem\u00e1s, tanto a los validadores como al proyecto les conviene que el equipo del proyecto solucione r\u00e1pidamente los errores detectados, por lo que, junto con la recopilaci\u00f3n de m\u00e9tricas, tiene sentido iniciar de inmediato la recolecci\u00f3n de registros y datos de errores desde las m\u00e1quinas de los validadores hacia una m\u00e1quina accesible para los desarrolladores de la blockchain. Aqu\u00ed a nadie le interesa distorsionar la informaci\u00f3n, por lo que estos servicios son gestionados por el equipo del proyecto y son de confianza. Tiene sentido recopilar m\u00e9tricas del sistema de los validadores y, sin falta, las m\u00e9tricas m\u00e1s importantes de la blockchain en s\u00ed: para DAOBet, esto incluye el tiempo de finalizaci\u00f3n y el retraso del \u00faltimo bloque finalizado. Gracias a esto, el equipo puede ver el aumento en el consumo de memoria en los nodos al ejecutar el benchmark, as\u00ed como los problemas de validadores individuales. <\/p>\n
<\/p>\n
Puntos importantes sobre la realizaci\u00f3n de la pr\u00e1ctica de validadores<\/h2>\n <\/p>\n
Como result\u00f3, si desea permitir oficialmente a los validadores atacar entre s\u00ed (de manera no oficial, ya pueden hacerlo) \u2014 es necesario formularlo de forma legal como una prueba de seguridad, ya que seg\u00fan la legislaci\u00f3n de algunos pa\u00edses, las sanciones pueden aplicarse por DDoS o ataques en red. Otra cuesti\u00f3n importante es c\u00f3mo recompensar a los validadores. Una de las formas m\u00e1s naturales de premio son los tokens del proyecto, que se transferir\u00e1n a mainnet, pero la distribuci\u00f3n masiva de tokens a cualquiera que logre lanzar un nodo no es la mejor opci\u00f3n. Es probable que tenga que equilibrar entre dos extremos.<\/p>\n
<\/p>\n
Distribuir todo el fondo de premios de acuerdo con los VP ganados.
<\/p>\n
Distribuir el fondo de premios a los validadores top-N seg\u00fan los resultados del juego.
<\/p>\n
A cu\u00e1l opci\u00f3n preferir, es su decisi\u00f3n. <\/p>\n
<\/p>\n
Hay otro punto \u2014 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\u00e1n y lanzar\u00e1n un nodo \u2014 por lo general, en esta etapa, los proyectos tienen una documentaci\u00f3n bastante escasa, surgen errores, y los desarrolladores que trabajan a contrarreloj no responden a las preguntas de manera muy r\u00e1pida. Por lo tanto, antes de comenzar el juego, tambi\u00e9n debe prever acciones en caso de que no se logre reunir el n\u00famero 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.<\/p>\n
<\/p>\n
Conclusi\u00f3n<\/h2>\n <\/p>\n
En conclusi\u00f3n, 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.<\/p>\n
<\/p>\n
Lo que se necesita hacer para lanzar un verdadero juego de validadores:
<\/p>\n
\ncrear y levantar una interfaz web y proporcionar una CLI para votar por los validadores.<\/li>\n Hacer que las m\u00e9tricas de un nodo validador en funcionamiento puedan enviarse a un servicio centralizado (por ejemplo, Prometheus)<\/li>\n Levantar un servidor de recolecci\u00f3n de m\u00e9tricas (Prometheus + Grafana) para el juego de validadores<\/li>\n Inventar c\u00f3mo se calcular\u00e1n los Punto de Validador (VP)<\/li>\n Desarrollar un script p\u00fablico que calcule los VP de los validadores basado en datos de blockchain<\/li>\n Desarrollar una interfaz web para mostrar el ranking de validadores y el estado del juego de validadores (cu\u00e1nto tiempo queda, cu\u00e1ntos VP tiene cada uno, etc.)<\/li>\n Desarrollar y automatizar el lanzamiento de un n\u00famero arbitrario de nodos propios, dise\u00f1ar el proceso de conexi\u00f3n de validadores al juego (cu\u00e1ndo y c\u00f3mo desconectar sus nodos, emitir y retirar votos por ellos)<\/li>\n Calcular cu\u00e1ntos tokens deben emitirse y desarrollar un contrato-faucet<\/li>\n Crear un script de benchmarking (transferencias de tokens, uso masivo de almacenamiento, uso masivo de red) <\/li>\n Reunir a todos los participantes en un chat para facilitar la comunicaci\u00f3n r\u00e1pida<\/li>\n Lanzar la blockchain un poco antes de empezar el juego<\/li>\n Esperar el bloque inicial, comenzar el juego<\/li>\n Probar la red con varios tipos de transacciones<\/li>\n Ejecutar el hard fork<\/li>\n Modificar la lista de validadores<\/li>\n Repetir los puntos 13, 14, 15 en diferente orden, manteniendo la estabilidad de la red<\/li>\n Esperar el bloque final, terminar el juego, contar los VP<\/li>\n<\/ul>\n<\/p>\n
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\u00eda definitiva. No existen an\u00e1logos en el negocio de TI moderno; imagina que los bancos compiten antes de lanzar un sistema de pagos, tratando de ver qui\u00e9n puede procesar mejor las transacciones de los clientes. Los enfoques tradicionales probablemente no te ayudar\u00e1n a crear grandes redes descentralizadas, as\u00ed que adopta nuevos modelos comerciales, organiza tus juegos, identifica a los dignos, recomp\u00e9nsalos y permite que tus sistemas distribuidos funcionen r\u00e1pido y de manera estable.<\/p>\n
Fuente: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0418\u0442\u0430\u043a, \u0432\u0430\u0448\u0430 \u043a\u043e\u043c\u0430\u043d\u0434\u0430 \u0437\u0430\u043a\u043e\u043d\u0447\u0438\u043b\u0430 alpha-\u0432\u0435\u0440\u0441\u0438\u044e \u0432\u0430\u0448\u0435\u0433\u043e \u0431\u043b\u043e\u043a\u0447\u0435\u0439\u043d\u0430, \u0438 \u043f\u0440\u0438\u0448\u043b\u043e \u0432\u0440\u0435\u043c\u044f \u0437\u0430\u043f\u0443\u0441\u043a\u0430\u0442\u044c testnet, \u0430 \u0437\u0430\u0442\u0435\u043c \u0438 mainnet. \u0423 \u0432\u0430\u0441 \u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0438\u0439 \u0431\u043b\u043e\u043a\u0447\u0435\u0439\u043d, \u0441 \u043d\u0435\u0437\u0430\u0432\u0438\u0441\u0438\u043c\u044b\u043c\u0438 \u0443\u0447\u0430\u0441\u0442\u043d\u0438\u043a\u0430\u043c\u0438, \u0445\u043e\u0440\u043e\u0448\u0435\u0439 \u044d\u043a\u043e\u043d\u043e\u043c\u0438\u0447\u0435\u0441\u043a\u043e\u0439 \u043c\u043e\u0434\u0435\u043b\u044c\u044e, \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u044c\u044e, \u0432\u044b \u0441\u043f\u0440\u043e\u0435\u043a\u0442\u0438\u0440\u043e\u0432\u0430\u043b\u0438 governance \u0438 \u0442\u0435\u043f\u0435\u0440\u044c \u043f\u043e\u0440\u0430 \u0431\u044b \u043f\u043e\u043f\u0440\u043e\u0431\u043e\u0432\u0430\u0442\u044c \u0432\u0441\u0435 \u044d\u0442\u043e \u0432 \u0434\u0435\u043b\u0435. \u0412 \u0438\u0434\u0435\u0430\u043b\u044c\u043d\u043e\u043c \u043a\u0440\u0438\u043f\u0442\u043e\u0430\u043d\u0430\u0440\u0445\u0438\u0447\u0435\u0441\u043a\u043e\u043c \u043c\u0438\u0440\u0435, \u0432\u044b \u0432\u044b\u043a\u043b\u0430\u0434\u044b\u0432\u0430\u0435\u0442\u0435 \u0432 \u0441\u0435\u0442\u044c genesis block, \u043e\u043a\u043e\u043d\u0447\u0430\u0442\u0435\u043b\u044c\u043d\u044b\u0439 \u043a\u043e\u0434 \u043d\u043e\u0434\u044b \u0438 \u0432\u0430\u043b\u0438\u0434\u0430\u0442\u043e\u0440\u044b \u0441\u0430\u043c\u0438 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-39478","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t