Actualización de desarrollo semanal # 25 – THORChain

Actualización semanal de desarrollo de THORChain para la semana 06-13 de enero de 2020

No hay cambios significativos para informar.

Trabajo binario

Se trabajó para limpiar la forma en que los mensajes se pasan a la consola para ayudar mejor con la depuración. El estado del grupo también se movió de una configuración de configuración de administrador al archivo constante, ya que es poco probable que se cambie. También se agregó un comando CLI para que los operadores consulten las últimas constantes.

Corrección de errores

El error principal manejado durante la semana fue cómo la red maneja los números de secuencia (nonces) en BinanceChain. Si los números de secuencia alguna vez se desincronizan, las transacciones salientes pueden fallar y bloquear efectivamente los fondos. Se construyó más lógica en los números de secuencia de almacenamiento en caché para evitar que esto suceda.

ChaosNet

Dado que ChoasNet tiene algunas diferencias con Main-net, para evitar que se produzcan divergencias en los indicadores de construcción binarios, ahora se utilizan para establecer los parámetros de ChaosNet necesarios.

TSS

Se ha comenzado a desarrollar el código necesario para detectar la culpa en las rutinas de generación y firma de claves. Con la culpa en su lugar, si alguna vez se aborta una ceremonia, se puede identificar e informar a la parte culpable. Si se llega a un consenso sobre a quién culpar, pueden ser penalizados y eliminados. La culpa eliminará un vector de ataque donde los nodos en colisión pueden detener el abandono.

BEPSwap Interface

Se está abordando más trabajo que surge del proceso de control de calidad para garantizar que BEPSwap esté libre de errores y sea muy elegante para trabajar. Aunque BEPSwap es una interfaz simple, se ocupa de múltiples fuentes de información en una configuración asincrónica y hay mucha lógica para que esto sea lo más fluido posible.

Se han realizado muchas pruebas y validaciones para probar la lógica de abandono de THORChain. Surgieron dificultades del plan original para tener un clúster de génesis de 4 nodos implementado por Docker debido a la forma en que Docker protege las direcciones IP de la red p2p. La solución ha sido usar docker para desplegar una red de un solo nodo, luego comenzar a agitar en los nodos de génesis 2–4 para llevarlo al estado BFT. En este punto, los nodos externos pueden conectarse y hacerse cargo de la red.

Revisión de código: comenzó

Revisión económica: en descubrimiento

Auditoría de TSS: discusión temprana

El testnet actualizado se encuentra en las etapas finales de prueba.