Actualización del diseño de Ouroboros Genesis
Una inmersión profunda en el diseño e implementación de Ouroboros Genesis, la última encarnación del protocolo de consenso responsable de la fiabilidad y seguridad de Cardano.
Autor: Nicholas Frisby - Ingeniero de software - Tweag
Ouroboros Genesis es una serie de mejoras al ya robusto protocolo Ouroboros, con contramedidas para proteger a un nodo de la red cuando es nuevo o regresa tras una ausencia.
Ouroboros es el protocolo de consenso en el corazón de la cadena de bloques Cardano. Dado el continuo desarrollo y la creciente aceptación de Cardano, Ouroboros ha progresado a lo largo de su plan de actualización. Ouroboros Classic fue el primer protocolo proof-of-stake de seguridad demostrable. Ouroboros BFT fue una solución provisional que permitió la actualización de Byron. Ouroboros Praos continuó el desarrollo de Ouroboros Classic. La evolución de Ouroboros dará un paso más con Ouroboros Genesis, cuya entrega está prevista para el tercer trimestre de 2024.
En este artículo se describen las recientes actualizaciones del desarrollo y la implantación del protocolo Ouroboros Genesis.
La historia de Ouroboros hasta ahora
Una cadena de bloques es un libro de contabilidad distribuido que se replica en máquinas llamadas nodos. Dado que no existe una autoridad central única, debe existir un mecanismo que garantice la coherencia y la inmutabilidad de todas las copias del libro de contabilidad. Ese mecanismo es el protocolo de consenso. El protocolo también establece incentivos para que los nodos validen nuevos bloques y los añadan a la cadena.
Ouroboros divide el tiempo de Cardano en épocas, que a su vez se subdividen en ranuras. Las ranuras representan periodos de tiempo cortos en los que se pueden crear bloques.
Ouroboros Classic es seguro cuando la mayoría de los nodos están en línea y tienen copias coherentes del libro mayor. Los adversarios no podían predecir qué nodo sería el siguiente líder de ranura (el nodo que consigue añadir un bloque a la cadena), lo que hacía que los ataques fueran muy costosos.
Ouroboros Praos aumentó la aleatoriedad en la selección del siguiente líder de ranura y añadió contramedidas para otros posibles ataques.
Ouroboros Génesis abordará la situación en la que un nodo se une por primera vez a la red (a partir del bloque génesis), o se reincorpora tras una ausencia prolongada. Estos nodos se encuentran en una situación vulnerable hasta que se ponen al día. Por ejemplo, se produce un ataque de largo alcance cuando un adversario intenta reescribir la historia de la cadena. El adversario acumula una gran participación, que le permite crear en secreto bloques más rápidamente que la cadena principal. Entonces, cuando la cadena histórica alternativa está lista, el adversario intenta cambiar la cadena principal por la cadena del adversario. La implementación de Génesis mitigará los ataques de largo alcance, a menos que el nodo de sincronización se eclipse. Un ataque de eclipse se produce cuando el adversario intenta rodear el nodo víctima con pares maliciosos, oscureciendo la red real.
Últimas novedades
Génesis introduce los siguientes conceptos nuevos:
- pares del libro mayor
- puntos de control ligeros (como alternativa temporal)
- límite de entusiasmo (LoE)
- desconexiones de densidad génesis (GDD)
- límite de paciencia (LoP)
- la máquina de estado de Génesis.
Pares del libro mayor
La desviación más profunda del documento Genesis fue una decisión arquitectónica temprana para preservar la limitación del nodo Praos en la reversión. Bajo Praos, un nodo Cardano no retrocederá más de 2.160 bloques sin intervención manual. Como se describe en el documento de Génesis, un nodo bajo ataque de eclipse sólo podría seleccionar extensiones de una cadena adversaria durante años y luego, cuando finalmente se conecta a un nodo que sirve a la cadena honesta, revertir abruptamente cualquier número de bloques.
Como en la práctica no es necesario que un nodo tenga una capacidad de reversión ilimitada, los arquitectos dieron prioridad al límite de reversión, que es clave para muchos límites en el uso de recursos. Abandonarlo para Génesis eliminaría una invariante básica invocada por una parte significativa del trabajo de ingeniería precedente. Además, mientras el nodo Cardano Genesis que se sincroniza tenga acceso a un peer honesto y sano, no debería, como el nodo Praos, requerir un rollback de más de 2.160 bloques.
Los eclipses son potencialmente una amenaza más importante para el nodo Génesis de lo expresado en el documento, que no los aborda directamente. Estos ataques ponen en peligro la propiedad de seguridad de Génesis, ya que un eclipse que dure más de unos segundos es suficiente para que un nodo Génesis de sincronización seleccione potencialmente 2.161 bloques de una cadena adversaria, a pesar de implementar fielmente las comparaciones de densidad de Génesis. Sin conocimiento de la cadena honesta, la regla de Génesis simplemente seleccionará la cadena más densa actualmente accesible. En una situación de eclipse, puede que no sea necesariamente la cadena honesta. Esto contrasta con el artículo de Génesis, en el que un nodo eclipsado y sus usuarios son simplemente retrasados, confundidos, mal informados, etc. Eso conlleva riesgos relacionados, pero no compromete las propiedades de seguridad o liveness, ya que el nodo podría eventualmente conectar a un peer honesto y por lo tanto recuperarse.
Considerando sólo una red Praos, en la que teóricamente los nodos nunca se quedan atrás, los eclipses pueden seguir siendo perjudiciales. La diferencia clave con Génesis es que un nodo Praos (inherentemente atrapado) puede soportar un eclipse mucho más largo antes de que haya una probabilidad significativa de que pueda comprometerse con una cadena adversaria. Sin embargo, incluso sin tener en cuenta la vulnerabilidad adicional durante la sincronización, un nodo Praos necesita alguna defensa contra los eclipses.
Una defensa consiste en introducir el concepto de pares del libro mayor dentro de la lógica de selección de pares para limitar suficientemente la probabilidad y duración de los eclipses. Durante la sincronización, un nodo Génesis ajusta su configuración de pares del libro mayor para reducir drásticamente la probabilidad de eclipsarse. Y sin eclipses, el nodo Génesis nunca seleccionará 2.161 bloques de una cadena adversaria.
El cambio en la selección de pares funciona así. Examinando una distribución reciente de participaciones, un nodo Génesis selecciona pares de muestra que han participado en el mantenimiento de la red, lo que reduce enormemente la probabilidad de seleccionar nodos maliciosos.
Una solución alternativa: el control ligero
El documento Genesis establece que la mejor cadena dentro de una red Praos sana tendrá más bloques que cualquier otra cadena en una ventana fija de ranuras inmediatamente después de la intersección de las dos cadenas. La única excepción es que la red Praos no esté en buen estado.
Una interrupción grave de la red justificaría la ejecución de un plan de recuperación de desastres, uno que requiera la cooperación fuera de la cadena entre las partes interesadas para reescribir la cadena dentro del intervalo de interrupción para reparar la cadena honesta. Una vez hecho esto, la regla de Génesis volvería a favorecer a la cadena honesta.
Sin embargo, un plan de recuperación en caso de catástrofe es intrínsecamente difícil y caro de ejecutar. Al menos mientras tanto, un sencillo mecanismo de puntos de control permitiría a un subconjunto suficientemente grande de operadores de grupos de estaca vigilantes mantener rápida y fácilmente el control de la red durante o inmediatamente después de la interrupción de la producción de bloques.
La lógica es simple y coherente con el resto del protocolo: un archivo de configuración que especifica una lista de pares de números de bloque y hash, cada uno de los cuales hace que cualquier otro bloque con el mismo número de bloque sea tratado como no válido. Los datos de configuración de ese punto de control deben utilizarse con cuidado y adquirirse sólo de fuentes fiables. Idealmente, la eventual ejecución del plan de recuperación permitirá (e incluso requerirá) que las adiciones reactivas a la lista de puntos de control sean temporales. Los únicos puntos de control permanentes serán el conjunto que asegura que las claves de génesis de la era Byron ya no son relevantes para la cadena Cardano.
Límite de entusiasmo
Dado que los pares del ledger evitan efectivamente los eclipses, un nodo de sincronización puede asumir que tiene al menos un par sano que sirve a toda una cadena honesta. Por tanto, la propiedad de seguridad se garantiza directamente simplemente prohibiendo al nodo Génesis sincronizador que seleccione nunca más de 2.160 bloques de una cadena más allá de la intersección de las cadenas de sus pares del ledger. Sólo seleccionará bloques con los que estén de acuerdo todos los pares del ledger, entre los que casi con toda seguridad se encuentra un par honesto. Esta restricción se denomina límite de entusiasmo (LoE), porque el nodo de sincronización no debe comprometerse con entusiasmo con el mejor bloque que ha visto hasta el momento. Un peer adversario puede ser capaz de servir sus bloques alternativos mucho más rápido de lo que cualquier peer honesto puede servir los bloques históricos.
Desconexiones de densidad génesis (GDD)
Es trivial para un adversario abusar del LoE para provocar que la víctima deje de sincronizar bloques, violando la propiedad de vitalidad del nodo sincronizador. Hay tres formas de hacerlo
- el atacante afirma que no tiene más bloques
- el par atacante sirve una cadena alternativa
- el par atacante afirma que tiene bloques alternativos pero tampoco los sirve.
La regla fundamental del artículo de Genesis mitiga directamente las dos primeras. Si dos pares sirven cadenas diferentes y al menos una de las cadenas tiene no menos de 2.161 bloques después de la intersección, Génesis favorece a la cadena que tiene más bloques en la ventana fija de ranuras después de la intersección de las dos cadenas. (Una cadena honesta siempre ganará esta comparación. Recordemos que un prefijo compartido refleja una intersección de cadenas, incluso si una de las cadenas es simplemente la extensión de otra). El nodo Génesis favorecerá a la cadena honesta desconectándose del otro peer. Esta acción se conoce como desconexión de densidad Génesis (GDD). Después de suficientes GDD, la intersección de los pares restantes estará más lejos a lo largo de la cadena honesta histórica.
Limite de paciencia (LoP)
El tercer vector de ataque es el más difícil de analizar. La GDD está desactivada porque el peer está reclamando tener más bloques. Es decir, está afirmando que su recuento de bloques en esa ventana fija aumentará si se le permite más tiempo para servir más bloques. Un par honesto siempre hace esa afirmación, hasta que el nodo de sincronización tiene todos los bloques honestos. Pero un usuario atacante podría hacer esa afirmación de mala fe. El límite de paciencia (LoP) garantiza que un par que afirma tener más bloques debe enviarlos realmente, y hacerlo con prontitud. La principal complicación es que ni siquiera los pares honestos pueden mantener una capacidad de respuesta perfecta durante horas, sino que ocasionalmente tendrán ráfagas de latencia, etc. Por esta razón, el LoP se implementa como un cubo con fugas para cada peer, donde la fuga es la tasa de procesamiento de bloques mientras el peer ha reclamado bloques y los está sirviendo más despacio que alguna generosa tasa mínima, pero la capacidad del cubo de cada peer honesto será lo suficientemente alta como para absorber las ráfagas de latencia típicamente esperadas de los peers sanos del ledger.
La máquina de estado de Génesis
El nodo Génesis desactivará LoE, GDD y LoP una vez que concluya que está atrapado, por dos razones importantes. En primer lugar, un nodo atrapado en una red Praos fundamentalmente debe acuñar el mejor bloque que pueda en una ranura en la que ha sido elegido. Por ejemplo, si un nodo de este tipo siguiera utilizando las reglas de Génesis, un adversario fuerte podría potencialmente abusar de la LoE para prohibir temporalmente a la víctima seleccionar el bloque que acaba de acuñar, impidiendo así que se propague a la red. Es difícil limitar las consecuencias de tal vector en todo el sistema, por lo que el nodo Génesis debería comportarse exactamente igual que un nodo Praos siempre que no esté sincronizando.
En segundo lugar, un nodo atrapado no necesita tantos pares como un nodo sincronizador, ya que no es tan vulnerable a los eclipses. Por lo tanto, la importante carga adicional que supone para la red que todos los nodos mantengan inflados los recuentos de pares del libro mayor es innecesaria e indeseable. La máquina de estado Génesis gestiona las transiciones del nodo entre considerarse alcanzado o no:
-
Una vez alcanzado, el nodo desactiva LoE, GDD y LoP. - Un nodo concluye que está atrapado si se cumplen estas condiciones
- Tiene suficientes pares en el ledger.
- Todos los pares afirman no tener bloques adicionales (lo que un LoP bien ajustado garantiza que ocurrirá pronto).
- El nodo ya ha seleccionado la mejor de las cadenas de pares.Esto es más robusto que confiar en la antigüedad de la selección local, etc., ya que un peer atacante podría ser capaz de activar dichos umbrales, haciendo que la víctima baje prematuramente sus defensas.
-
Un nodo vuelve a sincronizarse si la punta de su cadena es demasiado antigua (por ejemplo, 20 minutos más o menos). En particular, esto ocurrirá durante el tiempo de vida del proceso del sistema operativo del nodo si la máquina duerme durante el tiempo suficiente (por ejemplo, un usuario cierra la tapa de su portátil durante un tiempo).
Próximos pasos
El diseño anterior se ha estabilizado a lo largo del último año. Aunque sigue evolucionando ligeramente, no ha habido cambios importantes. IOG ha estado colaborando con Tweag durante los últimos meses para implementarlo y probarlo.
El lanzamiento de la primera implementación compatible con Genesis está previsto para el tercer trimestre de 2024. En este momento, la mayor incógnita que queda por despejar es el grado de optimización necesario para compensar el mayor número de pares necesario para evitar los eclipses.
Hasta entonces, el inminente diseño de los pares de arranque sirve como incremento hacia Génesis. La máquina de estado bootstrap es una variante más simple de la máquina de estado Genesis. Durante la sincronización, un nodo sólo se comunica con pares de arranque, cada uno de los cuales es de confianza, y por lo tanto el LoE, GDD y LoP son innecesarios. En cambio, Génesis permitirá que un nodo de sincronización incluya de forma segura a pares no fiables, siempre que no sea eclipsado (es decir, siempre que un par sea honesto), lo que permitirá retirar a los pares de arranque, descentralizando así la infraestructura para los nodos de sincronización y cumpliendo la promesa de Génesis Ouroboros.
Neil Burgess ha contribuido a este artículo.
Traducción al Español 
por Martín Ungar @LatinStakePools
Texto original: https://iohk.io/en/blog/posts/2024/05/08/ouroboros-genesis-design-update/