🇪🇸 Prevención frente a Recuperación en Sistemas Distribuidos [Pizarra] | CH 23 Ene 2023

:es: Transcripción al español de “Prevention versus Recovery in Distributed Systems [Whiteboard]

Publicado en el canal de Youtube de Charles Hoskinson el 23 de Enero de 2023

Enlace a la versión doblada al español


Hola a todos, este es Charles Hoskinson, transmitiendo en vivo desde la cálida y soleada Colorado. Hoy es 23 de Enero, quiero hacer un video de pizarra en blanco, hablar un poco acerca de operaciones de red, un poco acerca de prevención versus recuperación en sistemas distribuidos, así que agarrate de tu trasero, va a ser un video divertido, voy a compartir mí pantalla.

Como muchos de ustedes saben, mencionamos que el sistema el Domingo tuvo una pequeña irregularidad, no fue una gran irregularidad. De hecho hubo un encantador tuit que vi de los operadores de stake pool diciendo “esta es una caída, esta no”, una buena visual que te muestra la diferencia entre los dos. Una de las cosas que deberían ser traídas, cuando pensás acerca de operaciones de un sistema distribuido. Tenés como que balancear tu prevención de asuntos con tu recuperación de asuntos, con sistemas distribuidos. Esta es una de estas cosas donde la gente dice “¿qué querés decir Charles?, deberíamos construir cosas que funcionan el 100% del tiempo, que nunca tienen asuntos. Y ese es el objetivo, el problema es que tenés estos demonios que introducís en tu sistema. Uno es el deseo de velocidad, velocidad barra rendimiento. Dos es acceso abierto barra básicamente accesibilidad. Tres es operación sin permiso. Y actores Bizantinos. Hay otros demonios pero cuando introducís estos perdés un montón de tus mecanismos de prevención. O, lo que ocurre, es que cuando cazás uno, por ejemplo tenés acceso abierto, accesibilidad con prevención de usuarios, esto desafortunadamente viene con el costo de velocidad y rendimiento, osea la performance de tu sistema. Podés reducir el conjunto de gente que tiene operaciones y podés hacerlo con permiso, en cuyo caso podés optimizar el rendimiento, potencialmente podés optimizar la accesibilidad al público general, eliminar actores bizantinos, prevenir asuntos. Pero desafortunadamente has centralizado un poco la red. Es porqué en cualquier buen sistema distribuido tenés que tener un balance de prevención y recuperación. La recuperación es si algo aparece y somos capaces de recuperarnos de ese asunto, restaurar desde ese asunto. Y podría ser algo como “ok, tenemos puntos de chequeo”, tenemos cosas como retrocesos, tenemos cosas como reinicios, este tipo de cosas. Podés utilizar todas las herramientas y técnicas estándares, pero básicamente esas son áreas donde el sistema, cuando algo ocurre, es golpeado, tiene la habilidad de recuperarse de ese asunto particular.

Hemos introducido un montón de nuevos conceptos en 2022, con Vasil. Un ejemplo es tubería de difusión. La tubería de difusión fue súper popular, ¿por qué?, porque hace a Cardano mejor, más rápido y barato. Ahora, el problema con tubería de difusión es que cuando lo introducís, de repente, un montón de las cosas que hacés para validar y chequear la propagación de transacciones, digamos por ejemplo que tenés una mala transacción, bueno alguien tiene que presentar eso, de manera maliciosa o no, así que creemos un usuario, llamado Bob, así que transmite, llamaremos a esto tx b, por malo, así que tenés que presentar tx b a la red. Bueno, eso será golpeado digamos por relay. Antes de la tubería de difusión, si esa mala transacción era capaz de hacer caer el relay, el relay la obtendría, y el relay moriría del lado de validación antes de transmitir eso a alguien más, porque validó completamente la carga. Pero cuando introducís conceptos como tubería de difusión, lo que hacés es remover algunos de los chequeos de seguridad, así que se puede propagar más rápidamente a través de la red. Y decís “¿pero eso hace a la red menos segura?”, no, no realmente. Porque quizás ahora mataste al conjunto de relays alrededor de ese relay, pero hablando de manera general no tiene un problema más allá de ello. Así que vas de una falla a N fallas, donde N es la cantidad de conexiones que tiene ese relay particular. Ahora, en la práctica las transacciones se cayeron, los relays se reiniciaron, así que ganaste un montón más de velocidad, performance, rendimiento en el sistema, pero ahora reducís tu prevención de actores bizantinos. En lugar de que la prevención sea sólo una, va a N nodos. Y esas simplemente son las compensaciones que existen en sistemas distribuidos. De hecho estuvimos escribiendo algunos artículos para intentar entender estas compensaciones. Primero, para deshacerte de la necesidad de puntos de chequeo escribimos Ouroboros Génesis y el objetivo aquí es cómo uno se recupera de básicamente desde el bloque Génesis a hoy sin un punto de chequeo y esto está para entregarse este año combinado con par a par, debería crear un muy bonito mecanismo de recuperación para Cardano. Más teóricamente hemos escrito un genial artículo de protocolo llamado Scuttlebutt, protocolos Gossip resistentes a Bizantino, que habla de este tipo de escenarios. Sólo para leer los abstractos dice “Una de las más exitosas aplicaciones de redes de comunicación par a par está en el contexto de protocolos blockchain, que en las propias palabras de Satoshi Nakamoto, dependen en la naturaleza de la información siendo fácil de ser esparcida y difícil de sofocar. Se invirtieron esfuerzos significativos en la última década para analizar la seguridad de estos protocolos, invariablemente los argumentos de seguridad conocidos por el estilo de consenso Nakamoto de la cadena más larga utiliza una idealización de este inquilino, aquí el asunto. Desafortunadamente las implementaciones en el mundo real de redes par a par estilo gossip utilizadas por protocolos blockchain dependen en un número de estrategias de mitigación de ataques ad hoc que dejan una brecha evidente entre la capa de comunicación idealizada asumida en argumentos de seguridad formal para blockchain y el mundo real donde un amplio espectro de ataques han sido demostrados. En este trabajo puenteamos la brecha presentando una capa de red de resistencia bizantina para protocolos blockchain, por primera vez cuantificamos el problema de ataques de capas de red en el contexto de modelos de seguridad blockchain, hemos desarrollado un diseño que soporta estas cosas para restringir adversarios.

Así que un montón de esos conceptos ya hicieron su camino dentro de la pila de red Cardano, que es porque es bastante resiliente. Así que tenemos una prevención bastante buena ya construída dentro para el relay. Así que por ejemplo cuando Bob intenta enviar una malformada, mala transacción, ya hay un montón de buenas ideas de recuperación que tenemos para ello, ideas de prevención que tenemos para ello. Pero luego también tenemos un muy buen y elegante retroceso de recuperación. En general, cuando tenés fallas en cascada como esta no tienden a propagarse a toda la red. Aunque, de vez en cuando, podría aparecer un bug, donde una cadena de malas transacciones, básicamente se juntan, y esa cadena crea un estado emergente que crearía un escenario de choque. En cuyo caso tendrás este efecto ondulante donde va de Bob, el que presentó, luego va al relay, y luego eso va a N y luego eso va a, estos son, N, N, N, N, así que obtenés ese N al cuadrado, así que se propaga a través de toda la red, la golpea a medida que avanza.

Ahora, podrías intentar prevenir este estado particular, mientras eliminamos bugs del asunto particular que causó esa cascada que temporariamente detuvo algunos pocos nodos, ese es el lado de prevención. Pero la recuperación es igual de importante, colocar algo de código sentinela, código de reseteo, este tipo de cosas. ¿Por qué estoy trayendo esto?, bueno, cuando miramos al futuro tenemos cosas como endosantes de entrada. El artículo Ouroboros Leos vendrá en la primera mitad de este año, osea 2023, esa es nuestra fecha actual, podría retrasarse un poquito, pero no mucho. ¿Qué significa eso?, significa que este diseño particular será un demonio de velocidad, tenés tres tipos diferentes de bloques, tenés un montón ocurriendo. Y mientras tenés este concepto de protocolo de cadena más larga, osea que la gente está presentando transacciones y eventualmente las juntaremos en esta cadena, tenés todas estas cosas ocurriendo al mismo tiempo, de manera asincrónica, y esas se agrupan en sus propios bloques, y eventualmente son serializadas, y hacen su camino dentro del sistema.

En el momento que introducís esta nueva estructura ganás enorme mejoras al rendimiento, tu velocidad y performance aumenta, obtenés mucha más operación del sistema porque toneladas de nuevas personas pueden participar en el consenso. Teniendo mayor rendimiento tu accesibilidad aumenta. Sin embargo introdujiste toda una nueva capa de potenciales ataques bizantinos que pueden ocurrir. Es totalmente posible que partes de la red, digamos este clic de aquí, o este clic de aquí, colapse, cuando entre un mal actor o un mal estado de transacción. Eso está bien porque tus operaciones generales de red todavía están ocurriendo. Este reloj está bien, esta parte de la red, la cadena principal, está bien. Bueno, las cosas son un poco raras en los bordes, pero ese es un ejemplo de una compensación, donde perdés la magia de esta perfecta máquina tic tac que es completamente inmune a todo, osea que maximiza la prevención, y lo has compensado para decir “bueno, ocasionalmente voy a tener un estado de falla y tiene que recuperarse porque yo quiero rendimiento súper rápido, transacciones a costo súper bajo”. El primer ejemplo de compensación fue en 2022 con tubería de difusión donde algo que probablemente sólo mataría algunos relays ahora mata un montón de relays, esa conexión de transacciones con mal estado emergente.

Ahora, la prevención sigue ahí, aquí es donde los métodos formales son realmente poderosos, aquí es donde el modelaje es realmente poderoso, aquí es donde cosas como funciones puras son realmente poderosas. Básicamente podés obtener una enorme cantidad de esto para entender el comportamiento de tus problemas, tanto de manera local o emergente. Pero en el momento en que vas a un sistema distribuido, las cosas se vuelven un poco locas, tenés estos demonios emergentes, se vuelven muy malos cuanta más gente juegue, cuanta más accesibilidad tengas, que hagas más cosas. La expresividad es otro demonio, por cierto, escribiré eso. Es porque Bitcoin no tiene contratos inteligentes. Las cosas que podés hacer en la cadena, cuanto más grande la expresividad más potencial de que alguien será capaz de encontrar un tipo de transacción bizarra o cadena de transacciones, o llevar al sistema a un estado emergente que podría crear un modo de falla que requiere un reseteo. Es por eso que diseñamos el UTxO extendido, Plutus, porque queremos crear un montón de garantías formales para que la gente no pueda escribir transacciones de una manera particular para romper cosas. En su mayor parte de hecho funcionó exactamente como pensábamos.

Así que fuimos muy serios acerca de la prevención, el asunto es que la prevención en muchos casos de hecho reduce la expresividad en el sistema. Ves a un montón de desarrolladores de contratos inteligentes flotando alrededor diciendo “bueno, no tengo esta cosa que tengo en Ethereum, estoy enojado al respecto”, nosotros decimos “bueno, no lo pusimos dentro porque no queríamos que ese sea un peligro abierto para el sistema, aquí está la otra manera de realizarlo que podría ser un poquito más difícil pero no lastima las operaciones del sistema”, especialmente cuando vas a un sistema emergente más complejo.

Ethereum está intentando hacer esto, están intentando tener un espacio fragmentado, el problema es que ellos sufren de protocolos que no están bien modelados formalmente, no tienen un buen entendimiento de cómo vas de uno a N, la expresividad es demasiado elevada en algunas áreas, lo que están haciendo es comprometiendo aquí, están intentando colocar permiso, básicamente lo están haciendo con un sistema de barrido adherido. Nosotros de hecho somos significativamente más abiertos, donde no tenemos un sistema sistema de barrido adherido, que significa que tenemos que trabajar realmente duro en diseño de protocolo para ser capaces de resolver cómo el sistema puede prevenir un montón de asuntos y recuperarse de un montón de asuntos sin ello, y eso es lo que nos desacelera un poquito, pero lo tuvimos hecho. Con Ethereum básicamente dijeron que lo colocarían y si este tipo de cosas ocurrieran en Ethereum hay un potencial de que la gente podría de hecho perder todo su dinero. No podés hacer que eso ocurra en Cardano, de hecho no es posible con el diseño actual.

Todo el mundo tiene un diferente conjunto de compensaciones de diseño, ya sea compensaciones de los tipos de actores bizantinos que pueden acomodar, prevención IE, recuperarse de eso, cómo abren el sistema, quién tiene acceso y quién no tiene acceso, qué tipo de cosas pueden realizar los usuarios generales, el nivel de expresividad que tiene el sistema, y finalmente qué tipo de velocidad y rendimiento. Las cosas que realizás para optimizar velocidad y rendimiento, como tubería de difusión, cosas como endosantes de entrada, ese estilo de fragmentación, ciertamente pueden tener un gran impacto en tu habilidad para prevenir ataques. En algunos casos tenés que tener un modelo de recuperación formal.

Resumiendo, lo que en este momento estamos experimentando es dolor de crecimiento muy natural en diseño de sistemas distribuidos, y el hecho de que fuimos capaces de recuperarnos en menos de dos minutos es una buena indicación de que hay un bonito balance de estas funciones dentro del sistema, entre prevención y recuperación, dados los demonios que enfrentamos, los demonios de rendimiento, permiso, acceso, accesibilidad, los actores bizantinos, expresividad. A medida que vamos hacia el futuro, estas definitivamente son cosas que tendremos que discutir más. Eventualmente a medida que Cardano vaya a un sistema que tiene billones de usuarios, trillones de transacciones, en cualquier momento dado alguna parte de la red probablemente estará en estado de falla, no para siempre, sólo en ese momento. Habrá dócenas o cientos de estas cosas, decís “bueno, eso es malo”. Bueno, en cualquier momento dado, como humano, lo escribo aquí, ser humano escuchando esto, en cualquier momento dado, vas a tener células malas en tu cuerpo, podrías tener algo de cáncer, podrías tener algunas células senescentes, y esas células mueren, o son matadas. En cualquier momento dado podrías tener un virus y tu sistema inmune tiene que matarlas. En cualquier momento dado un montón de cosas ocurren, ¿por qué?, porque sos un sistema complicado, tenés trillones de células, y la probabilidad de que al menos una de esas células tenga un estado defectuoso es bastante elevada. Ciertamente tu cuerpo tiene un montón de prevención, oncogén, todas estas otras cosas para prevenir que ocurran malas células, pero tu cuerpo también tiene un sistema inmune para mantener la homeóstasis, de eso se trata la recuperación. Y esto es la vida real, es realmente complicado, todavía estamos intentando entender el manual de operaciones para ello, hemos estado trabajando en él como especie por bastante tiempo, ¿por qué un sistema distribuido que es más simple que tu cuerpo sería diferente? Cuanta más complejidad introduzcas, mayor probabilidad de que el sistema en cualquier momento dado tendrá algunas células malas, el sistema tiene que purgar esas malas células, especialmente mientras escalás y tenés variados niveles de habilidad, experiencia y capacidades dentro del sistema, esa es simplemente la naturaleza de las cosas.

Pero en su mayor parte creo que la magia de Cardano es el hecho de que encontramos este hermoso balance y ese balance no requiere medidas económicas punitivas para compensar pobre diseño de protocolo, como otros sistemas.

Estaría asustado hasta el demonio si yo fuera Ethereum y ocurre un sistema de parado como este y nos despertamos y el 20% del Ether fue barrido sin que haya falta de la gente ejecutando el sistema pero debido a una mala transacción o lo que sea que lo haya golpeado y llevado a ese estado particular. El hecho de que eso no pueda ocurrir es un maldito buen diseño de protocolo para nosotros, estoy bastante feliz al respecto. Yo estaría asustando como el demonio si no tuviéramos un modelo formal acerca de cómo balancear la necesidad de prevención de asuntos, la habilidad de recuperarse de las cosas con los planes de escalabilidad y fragmentación de Cardano. Esto conlleva pesada utilización del UTxO extendido y Mithril. Lo que es bonito al respecto es que estas son tecnologías de las que entendemos un montón, realmente demostramos a escala que entendemos cómo cambiar este tipo de cosas juntas. Ahora, se tienen que realizar un montón de cosas, tenés que volver aquí arriba, métodos formales, modelación, funciones puras, toda clase de cosas, ok, genial, para asegurarte que no vas a un mal estado, pero siempre tenés algún asunto con un sistema como este, y estas cosas ocurrirán. En la práctica podés tener mejor monitoreo de red, podés obtener dumps TCP, este tipo de cosas, podés ser un poquito más proactivo asegurándote que las cosas no colapsan. Pero ya sabés, en 2017 las cosas colapsaban mucho más seguido, sólo que a nadie le importaba. En 2023, hemos estado corriendo por cinco años sin asuntos y francamente este no fue un asunto mayor. Es sólo un buen ejemplo de cuando la gente se junta y busca por ello.

Así que continuaremos eliminando bugs, buscaremos eso, pero quería mostrar el bosque detrás de los árboles acerca de cómo pensamos acerca de este tipo de problemas y el enorme diseño de protocolo que va dentro de todas estas cosas, todas las cosas geniales con las que aparecimos durante los años para básicamente crear un sistema tolerante a fallas, con auto curación, resiliente, descentralizado, que es ejecutado y liderado por la comunidad. La realidad es que Cardano está ejecutado por vos, ustedes son los muchachos que de hecho tienen esto. No hubo trabajo de parte de IOHK para resetear o hacer algo, no hubo llamadas telefónicas de 11 horas en Discord para rogar a la gente que reinicien o reseteen cosas, ustedes muchachos básicamente realizaron la operación ustedes mismos. La vasta mayoría del equipo IO estaba durmiendo durante ese período de tiempo, o estaban en descanso, era Domingo, no tuvo ningún impacto en absoluto sobre nosotros. Así que ese es un buen testimonio de que el sistema es completamente descentralizado, opera de manera descentralizado. Pero se tiene que pensar un montón, de manera muy cuidadosa, acerca de nuestro modelo de falla, de nuestro modelo de recuperación mientras descargamos medidas preventivas, especialmente si queremos escalar el rendimiento, reducir costos de operación, incrementar el conjunto de validadores, incrementar la expresividad que permite más tipos de ataques bizantinos, lo atravesaremos juntos a través de un proceso estructurado. Y si lo hacemos, entonces podés crear organismos vivos bastante felices, bastante bonitos que prosperan y sobreviven en los próximos años. Así que gracias a todos por escuchar, espero que este haya sido un ligeramente útil video de pizarra com para explicar la filosofía de diseño, cómo pensamos acerca de las cosas, dónde nos sentamos. Todavía estoy asombrado por cuán notable es Cardano como ecosistema, cuán verdaderamente descentralizados nos volvimos, cuán capaces somos de recuperarnos de accidentes que vienen de cuando en cuando, saludos.