Estoy emocionado de finalmente compartir y lanzar la primera versión pública de la cadena de bloques de Herdius. Esta primera versión se llama Foundation y, como su nombre lo indica, los servidores como nuestra infraestructura base sobre la cual se construirá nuestra visión. Muchos meses de desarrollo y trabajo de nuestro equipo han entrado en el proyecto, y después de haber ejecutado nuestra red de prueba interna durante el último mes, nos sentimos confiados en la liberación de nuestra arquitectura para que todos la puedan usar.
Puede acceder al repositorio de Herdius aquí: https://github.com/herdius/herdius-core
De un vistazo
La primera versión pública de la cadena de bloques de Herdius incluye una cadena de bloques completa que es completamente funcional y está lista para ser implementada. Está diseñado para adaptarse a nuestras propias necesidades específicas y una hoja de ruta para facilitar un medio para transferir activos de todo tipo. Estos activos son principalmente diferentes monedas criptográficas, acciones, moneda fiduciaria, etc. Nuestro objetivo era crear una base estable sobre la que podamos construir y completar fácilmente la arquitectura Herdius general mediante la actualización y la adición de componentes y funcionalidades que aún faltan.
Nuestra configuración actual es semi-descentralizada debido a que nuestro nodo Supervisor (que se explica a continuación) en este momento es actualmente un nodo único en lugar de estar descentralizado y distribuido. Si alguien desea utilizar la versión actual en el entorno de producción, le recomendamos que lo haga en una red / configuración privada. Todo está listo para la implementación con instrucciones que se encuentran dentro de nuestro repositorio sobre cómo implementar Herdius Core por su cuenta, como parte de un servidor dedicado o una red de instancias de EC2 en AWS.
Vista general de la arquitectura
Nuestra arquitectura sigue todos los principales ides iniciales que se describieron en nuestro documento técnico y en diferentes artículos en nuestro Medio. Específicamente, la parte interesante de nuestro diseño es algo que llamamos Blocks-on-Blocks, BoB en breve. Queríamos crear una arquitectura que se adapte al volumen de transacciones y al número de validadores, pero sin poner un cuello de botella en el rendimiento, de ahí surgió la idea de BoB. Al hacer que las transacciones se agrupen en un conjunto más pequeño de bloques, y luego que cada uno de estos bloques individuales sea validado por diferentes grupos de validadores, los nodos pueden validar bloques en paralelo. En el centro de nuestra arquitectura hay algo que llamamos el nodo supervisor que, por ahora, controla el flujo general de transacciones y actúa como una protección en el sistema. En el entorno actual, actúa como un búfer entre los nodos y los usuarios.
Para ilustrar cómo funciona nuestra red a continuación hay un ejemplo de viaje de transacción:
Paso 1: el nodo Supervisor hace una copia del último Estado de la cadena de bloques (S) aprobado y crea S '
Paso 2: Dentro de cada bloque hay una lista de candidatos de nodos que se comprometen a realizar la validación
Paso 3: el nodo Supervisor asigna validadores a grupos (actualmente al azar), crea un árbol Merkle de su dirección para cada grupo
Paso 4: El usuario crea un paquete de transacción y lo transmite al nodo supervisor
Paso 5: el nodo Supervisor valida la transacción contra el Estado S '
Paso 6: el nodo Supervisor coloca la transacción en lotes de 500 Tx cada uno
Paso 7: el nodo Supervisor construye la estructura de BoB, hace un hash de todas las raíces de los bloques y los conecta; asigna cada bloque a un grupo validador diferente
Paso 8: Los validadores realizan la validación de bloque, votan el resultado dentro de su grupo para alcanzar un consenso que luego se envía de vuelta al nodo Supervisor
Paso 9: el nodo Supervisor recibe el resultado de consenso, finaliza todos los bloques y agrega un bloque a la cadena de bloques
Una versión muy simplificada de BoB.
Hay varias ventajas de usar BoB, las más obvias e importantes son:
reduce el tamaño de los validadores de toda la red, a un subconjunto más pequeño de nodos. Esto significa que no todos los nodos de la red tienen que acordar que una transacción sea válida, sino solo aquellos dentro de su propio grupo de validación. Elimina el problema de la comunicación de bloques cruzados (fragmentos cruzados traducidos a nuestra redacción) como lo hacen los grupos de validación. No tienen que comunicarse entre sí. Esto ahorra una cantidad considerable de bandwithTx La validación puede ejecutarse en paralelo sin comprometernos a los ataques de doble gasto. Lo que ocurra en el subbloque # 1 no influye en el bloque # 9. p.ej. Si Alice / Bob crea 100 Txs y los transmite al supervisor con algún retraso entre ellos, lo más probable es que estas transacciones se realicen en lotes diferentes, asignados a diferentes validadores. Debido al hecho de que el nodo Supervisor ya tiene un estado S 'que se modifica continuamente, se evita el riesgo de doble gasto.
En el camino, muchas personas han estado diciendo que BoB es similar a la fragmentación, lo es. Primero imaginamos a BoB durante el verano final, 2017, que casualmente también es el momento en que salió la primera especificación de fragmentación.
Puntos de referencia y rendimiento
Hemos tenido la cadena de bloques Herdius completamente implementada ejecutándose en nuestra red de pruebas. Para simular una red distribuida, utilizamos instancias pequeñas de AWS EC2 (2 núcleos de CPU, 2 GB de RAM, 8 GB de almacenamiento) distribuidas en diferentes continentes y centros de datos para simular nodos de validación. Nuestro nodo supervisor central fue alojado en Frankfurt, Alemania. También creamos 3.000 transacciones de muestra que alimentamos continuamente a la red. Desde el momento en que un usuario envió 3000 transacciones continuas, tomó toda la red 5.31s para finalizar y acordar todos los bloques dentro.
Futuros desarrollos
Uno de los aspectos más obvios del sistema podría ser que el componente supervisor no está descentralizado. Esto se hizo a propósito para esta versión, ya que aún se alinea con nuestra hoja de ruta en el trimestre actual. Tener el nodo supervisor de nuestro sistema para ser totalmente distribuido (y aquí me refiero a que no hay masternodes, 21 nodos, 100 u otros schenenigans similares) nos quitaría la mayor parte de nuestro poder de desarrollo para estar completamente enfocado en él durante aproximadamente un mes. Algo que no se alinea con nuestros planes actuales de terminar y lanzar nuestra billetera en marzo. También es bastante difícil de hacer. No hay una manera correcta, o rutas que hayan sido probadas, y cuando se hace un sistema que eventualmente será público. Es mejor que sepas lo que estás haciendo y que sea seguro.
El replanteo también es un componente que falta y tenemos un plan completo para realizar nuestra versión modificada de PoS. Una vez más, preferiríamos tener un producto perfectamente utilizable ahora que diferentes compañías ya pueden usar que algo en lo que trabajamos durante años sin que funcione durante ese tiempo. El token HER jugará un papel en el sistema y cada validador debe tenerlo. Desde este lado, buscamos una arquitectura que sea fácil de usar y ver, y esto significa que no hay contratos inteligentes complicados. Dos soluciones posibles aquí: 1) cuando ejecuta un nodo validador, simplemente tiene una dirección asociada con usted HER. Usted decide cuánto arriesgar / comprometer y las tarifas se distribuyen automáticamente a su cliente. 2) Usted tiene SU dentro de nuestra billetera y eso es todo, las tarifas llegan a su billetera dependiendo de la cantidad que tenga.
Por el lado de la gobernanza mi opinión todavía no ha cambiado. Planeamos hacer lo que describimos en nuestro documento inicial para incluir a nuestros titulares de fichas en las decisiones tanto como sea posible. Nada más sobre esto por ahora, ya que mi opinión de que la gobernabilidad es un desastre desde hace un año todavía no ha cambiado.
Colaboración
Damos la bienvenida a otras compañías de blockchain, corporaciones o cualquier persona interesada en contribuir, participar y ayudar. Estamos encantados de proporcionar nuestras ideas y planes sobre cómo resolver el replanteo, la descentralización del nodo supervisor, la votación, etc. No dude en ponerse en contacto.
Pensamientos de cierre
Estoy feliz de haber llegado hasta aquí y emocionados por nuestros lanzamientos y lo que tenemos en la tienda. Para ser más precisos, esto incluye nuestra billetera de monedas criptográficas multi-moneda antes mencionada para Mac y Windows e IOS (poco más tarde que las dos anteriores). Claro que no suena emocionante en sí mismo, pero herdius-core no fue el único proyecto en el que trabajamos. Nuestro protocolo de generación de claves distribuidas se terminará muy, muy pronto. Cuando lo combinas con la billetera, las cosas son más emocionantes 🙂
