Diseña un sitio como este con WordPress.com
Comenzar

Plan de recuperación de desastres en Cardano

La versión del protocolo Ouroboros utilizada en la implementación actual de Cardano funciona como se espera (es decir, proporciona consistencia y capacidad de respuesta en toda la red) siempre que no se produzcan dos eventos de «desastre».

Estos eventos eventos son extremadamente improbables en el despliegue real del protocolo, pero pero pueden ocurrir en despliegues de prueba independientes o en circunstancias extremadamente improbables circunstancias del mundo real (a continuación se ofrecen algunos ejemplos). Este documento describe estos eventos en detalle y las correspondientes acciones de mitigación que deben llevarse a cabo en caso de que se produzcan.

  • Particiones de larga duración en toda la red
  • Interrupción global de larga duración

Particiones de larga duración en toda la red

Escenario

Tenemos una partición de la red, donde un grupo de nodos no están conectados
a la red principal. La partición persiste lo suficiente como para que el clúster
produce más de k bloques, y los nodos del clúster los añaden a su cadena. Una vez finalizada la partición, esos nodos no volverán automáticamente a la cadena principal, ya que eso requeriría que cambiaran a una bifurcación que sea más profunda que k bloques y la implementación actual del protocolo Ouroboros no permite esa reorganización. Observamos que para la parametrización de Cardano, tenemos k = 2160, slots de 1 segundo y f = 1/20, por lo que la producción de k bloques por parte de un clúster minoritario llevaría al menos un día. Queremos reconciliar los nodos del clúster con la red.

Mitigación manual

Añadiremos una funcionalidad al nodo que permita cambiar manualmente a un
bifurcación profunda. En concreto, implementaremos un nuevo modo, en el que un operador puede especificar un par de hash/slot de la cabecera del bloque, lastGood, al iniciar el nodo. El nodo mantendrá entonces su propia cadena sólo hasta alcanzar el bloque con hash de cabecera lastGood, y posteriormente intentará sincronizarse con la red.

Los operadores de los nodos del clúster pueden entonces, independientemente de los demás, iniciar sus nodos en este modo, seleccionando compañeros de la red principal, para recuperarse. Los operadores de los nodos deben asegurarse de seleccionar a los compañeros de la red principal para evitar la resincronización con la red minoritaria. El parámetro lastGood puede determinarse observando las cadenas de la red principal y el clúster (por ejemplo, a través de un explorador).

Medidas adicionales: Recuperación de las transacciones de la partición de la minoría

Descartar una bifurcación larga hará que se pierdan muchas transacciones. Algunas de ellas podrían no ser compatibles con la cadena principal, pero si la partición, también la partición de los usuarios de la red, es probable que muchas de las transacciones de la bifurcación descartada también puedan insertarse en la cadena principal. Para preservar las transacciones de la partición minoritaria que también son válidas en la cadena principal, produciremos una herramienta para leer las transacciones de los bloques descartados, y reenviarlas a la red después de
la partición se haya resuelto.

Limitaciones

La solución requiere, naturalmente, que los operadores de los nodos del clúster
quieran volver a unirse a la cadena principal. En el caso de una red dividida en dos partes aproximadamente iguales, puede ser difícil ponerse de acuerdo sobre qué parte se considera la cadena principal. La forma de llegar a ese consenso social está fuera del alcance de este plan técnico de recuperación de desastres.

Solución

En caso de que la solución anterior no esté (todavía) implementada, también es una alternativa viable para los operadores de los nodos del clúster borrar el estado de sus nodos, y reiniciarlos, conectándolos a la red principal. En ese caso, los nodos
tendrían que resincronizar toda la cadena. Una vez más, los operadores deberían explícitamente elegir compañeros de la red principal, dado que durante un periodo de transición puede haber todavía muchos nodos en la red que estén siguiendo la otra bifurcación.

Mitigación automatizada

Actualmente se está desarrollando una nueva versión de Ouroboros que se recupera automáticamente de las particiones en red de longitud indefinida.

Interrupción global de larga duración

Escenario

En condiciones normales, tenemos aproximadamente un bloque por cada slot 1/f (un bloque cada 20 segundos). La implementación actual de Ouroboros requiere tener al menos un bloque en al menos un bloque en 3k/f slots, que es una ventana de 36 horas bajo la parametrización actual de la mainnet de Cardano. Una violación de este requisito es extremadamente extremadamente improbable: la producción de bloques tendría que detenerse durante 36 horas en toda la red. Los eventos bajo los cuales la producción de bloques podría detenerse por un tiempo tan largo son extremadamente improbables e incluyen:

  1. Hay un fallo de software en la implementación del nodo que afecta a todos los
    nodos simultáneamente y les impide producir bloques. La monitorización lo revelaría inmediatamente, y los desarrolladores trabajarían en la corrección de este fallo, pero si la producción de la corrección, y su despliegue en un subconjunto de nodos productores de bloques, tarda más de 36 horas, la red se vería afectada, la red no reanudaría automáticamente la producción de bloques.
  2. Las erupciones solares a escala de Carrington podrían hacer caer la red mundial mucho más de 36 horas.

Mitigación manual

Añadiremos una funcionalidad que permita iniciar un nodo con un reloj virtual
que comienza en un momento dado tFail, y es más rápido por un factor de tiempoAceleración que el wall clock real. Además de esos parámetros, un operador también proporcionará un tiempo tRecover, la hora de inicio del wall clock del proceso de recuperación.

Cuando se inicia en este modo, el nodo

  1. esperará hasta que el wall clock del sistema esté en tRecover
  2. establecerá un reloj interno en tFail
  3. descartará cualquier bloque que se haya producido después de tFail
  4. establecerá la velocidad del reloj interno a timeAcceleration veces la velocidad del tiempo real
  5. producir, enviar y aceptar bloques vacíos de acuerdo con la programación del líder de slot pero utilizando el reloj interno en lugar del reloj del sistema
  6. una vez que el reloj interno deje de estar por detrás del reloj del sistema, reanudar
    funcionamiento normal, según el reloj del sistema (quizás mediante un apagado y reinicio en el modo normal).

Con esa funcionalidad implementada, la reparación de la cadena requeriría
una coordinación manual entre un grupo de operadores de pools. El grupo de operadores de pools se pondría de acuerdo en tFail (a partir de los datos históricos anteriores a del evento), y tRecover y timeAcceleration (tRecover debería ser un
tiempo en un futuro próximo, para que todos los nodos puedan empezar al mismo tiempo, y timeAcceleration debe ser lo suficientemente grande como para que el proceso de recuperación no tarde demasiado, pero lo suficientemente bajo como para que el sistema pueda seguir enviando bloques lo suficientemente rápido. Si esto último resulta problemático, los operadores de stake pool pueden decidir utilizar una red más localizada que en el funcionamiento normal, como por ejemplo, hacer funcionar todos los nodos en el mismo continente. Tenga en cuenta que el uso de bloques vacíos también ayuda en este caso: son más pequeños, lo que ayuda a propagarlos la red rápidamente). A continuación, todos los nodos arrancarían con esos parámetros. Los nodos producirían bloques durante el tiempo de la interrupción a una mayor cadencia, hasta que se «pongan al día» con el tiempo real, y se reanuden normalmente a partir de ahí.

Al iniciar su nodo en modo de recuperación, los operadores de pool no podrán utilizar su certificado operativo actual y su clave KES, ya que esa clave
habrá evolucionado hasta el presente, por lo que no se considerará válida cuando el reloj vuelva a ponerse en tFail. En su lugar, descartarán su certificado operativo y la clave KES, actuales, y emitirán un certificado operativo y una clave KES nuevos, que serán válidos en tFail.

Mitigación automatizada

Actualmente se está desarrollando una nueva versión de Ouroboros que se recupera automáticamente de las interrupciones globales de duración indefinida.

Fuente: Cardano Disaster Recovery Plan

Anuncio publicitario

Publicado por LiberLion

La descentralización es Proof of Liberty. Twitter @liberlion17

Deja una respuesta

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Salir /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Salir /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Salir /  Cambiar )

Conectando a %s

A %d blogueros les gusta esto: