Consenso de unidad – Prueba de concepto – Aion

En este artículo, lo guiaré a través de la implementación de Aion Unity Proof-of-Concept (PoC). Si no ha oído hablar de Aion Unity, lea esta publicación de blog "cero a héroe".

El PoC consta de cuatro componentes:

Un contrato de registro de estaca que gestiona el registro de staker y maneja las solicitudes de estaca / no participación, una nueva estructura de bloques, junto con un conjunto de reglas de validación, para dar cuenta de dos tipos de bloques: bloques PoW y bloques PoS, un cliente de replanteo, análogo al software de minería , que genera ansiosamente bloques PoS cuando es elegible para hacerlo. Una implementación del algoritmo de ajuste de dificultad y la regla de elección de la horquilla.

El objetivo del PoC es validar las métricas clave presentadas en el documento de Aion Unity y simular diferentes escenarios de ataque. Las métricas estudiadas incluyen el tiempo de bloqueo, la distribución de recompensas de bloque y la tasa de bloqueo de huérfanos.

El Contrato de registro de estaca es el contrato inteligente que gestiona el registro de estacadores y procesa las solicitudes de voto / no voto (también conocido como estaca / no participación respectivamente). Cualquier poseedor de monedas con un saldo mínimo puede registrarse como apostador para participar en el consenso de Unity. Otros pueden votar o no votar por un apostador registrado. Las monedas líquidas se convierten en estacas bloqueadas después de una operación de votación, y vuelven a ser líquidas después de una operación no votada, sujetas a un período de bloqueo.

El código fuente del contrato de registro de participación está disponible aquí. Aunque el contrato inteligente está escrito en Solidity, luego se reescribirá en Java para ejecutarse en el AVM. Además, la aplicación de la participación mínima en el registro y el período de bloqueo no votado no se implementan en el PoC.

En Aion Unity, la estructura es una lista individualmente vinculada de bloques PoW y bloques PoS, sin necesidad de intervención. Para distinguir un bloque PoS de un bloque PoW, ampliamos la estructura original del bloque Aion con campos adicionales. Específicamente,

UNA sealType se agrega el campo para identificar el tipo de bloque; para un bloque PoW, el sello el campo consiste en un mientras tanto y un EquiHash solución; Para un bloque PoS, el sello el campo consiste en un semilla y un firma del encabezado del bloque del staker.

Tenemos un nuevo conjunto de reglas de validación para bloques PoS, como sigue:

Valide el encabezado del bloque utilizando los validadores PoW existentes, pero omita el sello validación de campo. Valide que el semilla es una firma válida ED25519 de la semilla del bloque PoS anterior y recupera la dirección del firmante (llamémosla firmante1) Valide que el firma es una firma válida ED25519 del encabezado del bloque y recupera la dirección del firmante (vamos a llamarlo firmante2) Validar que firmante1 y firmante2 son iguales. Busque la participación del firmante en la base de datos del estado y calcule el retraso de generación del bloque PoS. Valide que el retraso sea menor o igual a la duración entre este bloque PoS y el bloque PoS anterior.

Para generar un bloque PoS, un usuario necesita buscar activamente su participación y calcular el retraso de generación del bloque. Cuando es elegible para generar un bloque, crea una plantilla de bloque y lo firma.

Llamamos al software que realiza esta búsqueda, esperando y bloqueando la producción un cliente de replanteo. Necesita ser capaz de:

Administre la clave privada del staker, verifique el retraso de generación del bloque PoS comunicándose con un nodo sincronizado completo, firme las plantillas de bloque creadas por el nodo.

La implementación completa de PoC de un cliente de replanteo está disponible aquí.

Aion Unity utiliza una regla de elección diferente para manejar las bifurcaciones en la red. Siempre selecciona la cadena con el producto más alto de dificultad de minería total y dificultad de replanteo total. La dificultad minera total es simplemente la suma de las dificultades de todos los bloques PoW en la cadena; La dificultad de replanteo total es la de los bloques PoS.

La forma en que se implementa la regla de elección de la bifurcación en el PoC es hacer un seguimiento de las dificultades totales de extracción y replanteo de cada bloque. Cuando se importa un nuevo bloque, se actualiza la dificultad total de minería o la dificultad de replanteo, según corresponda.

Para mantener un tiempo de bloqueo específico, la dificultad debe ajustarse dinámicamente a medida que los mineros y los apostadores se unen y se van. La dificultad de minería / replanteo aumenta si el tiempo de bloqueo es demasiado pequeño y disminuye si el tiempo de bloqueo es demasiado grande. Consulte aquí para la implementación de PoC.

Para probar cómo funciona la implementación de PoC, configuramos el siguiente clúster:

8 nodos conectados a través de una intranet; 4 de ellos son mineros (1 GPU Nvidia cada uno); Los otros 4 nodos están en juego (1000, 2000, 3000, 4000 nAmp respectivamente).

Dejamos que la red funcione durante 2500 bloques y luego calculamos las siguientes estadísticas:

Estadísticas de tiempo de bloque entre el bloque # 500 y el bloque # 2500 Bloques huérfanos entre el bloque # 500 y el bloque # 2500 La dificultad de minería en el tiempo La dificultad de replanteo en el tiempo Distribución de recompensas en bloque

Al analizar los datos recopilados, encontramos que las métricas clave para la implementación de PoC coinciden con lo que se presentó en el documento de Unity:

El tiempo de bloqueo promedio está muy cerca de los 10 segundos objetivo; la dificultad se ajusta de 1 al nivel correcto dentro de 200 bloques, con la configuración de red dada; el número de bloques PoS y bloques PoW es aproximadamente el mismo; las recompensas de bloque de un Los mineros son proporcionales al hashrate minero, mientras que las recompensas en bloque de un staker son proporcionales a la cantidad de participación.

En este experimento, evaluamos la capacidad de la red para recuperarse de un período de conectividad interrumpida. Para probarlo, dividimos un clúster en dos grupos por un período de tiempo, y luego nos reunimos con ellos.

Al observar los crecimientos de peso de las cadenas de las dos particiones, encontramos que ambas particiones podrían progresar independientemente (se mantiene la vida). Cuando se resolvió el problema de conectividad, la red eligió la cadena con un mayor peso. El experimento nos ayudó a identificar algunos problemas de sincronización en la implementación del kernel, que se solucionaron.

Entonces, ¿qué sigue después de la implementación de Aion Unity PoC?

El diseño económico de Aion Unity se publicará pronto. El equipo de ingeniería está ocupado produciendo Aion Unity. ¡Manténganse al tanto!