🇪🇸 SPANISH DUBBING Ouroboros Peras: el siguiente paso en el viaje del protocolo de Cardano | IOG 14 Oct 2024

Enlace a la versión doblada al español


Además aquí está la transcripción completa, traducida y revisada para el Canal Cardano Castellano

Transcripción completa

:es: Doblaje al español de “Ouroboros Peras: the next step in the journey of Cardano’s protocol

Publicado en el canal de Youtube de IOHK el 14 de Octubre 2024

Hola, mi nombre es Sandro Coretti Drayton, soy investigadora en IOG y estamos aquí hoy para hablar sobre Peras y cómo proporciona un asentamiento rápido a las blockchain Nakamoto, en particular a Ouroboros, que impulsa todo el ecosistema Cardano. En el consenso Nakamoto, al igual que con cualquier blockchain, las partes intentan construir una cadena muy larga de bloques que contengan transacciones. Sin embargo, a veces en el consenso Nakamoto pueden ocurrir pequeñas bifurcaciones, por ejemplo, cuando las partes liberan nuevos bloques al mismo tiempo o cuando un adversario intenta interferir.

Como regla general, es muy importante que las partes honestas construyan sobre los bloques de los demás, y para garantizar esto, existen algunas restricciones. La restricción más importante es que no podemos tener una frecuencia de producción de bloques demasiado alta; en particular, la frecuencia debe ser aproximadamente el inverso del retraso de propagación, es decir, el tiempo que tarda un bloque en ir desde el productor hasta todos los demás en la red.

Además, si quieres estar seguro de que tu transacción se asiente, debes esperar a que se construya una cierta cantidad de bloques encima del bloque que contiene la transacción, ya que la probabilidad de que tu bloque sea revertido disminuye exponencialmente con el número de bloques que se construyen encima. ¿Qué aprendemos de esto? Aprendemos que el consenso de Nakamoto es lento, y la pregunta es, ¿qué podemos hacer al respecto?

Una forma de evitar esto es usar protocolos basados en BFT. BFT significa “Computación Tolerante a Fallas Bizantinas” y, de hecho, es una idea que ha sido conocida desde los años 80. Generalmente, cuando intentas construir una blockchain basada en esta idea, lo que haces es, en un primer paso, tener un número de partes que proponen bloques y elegir un líder entre ellas, luego ejecutar un protocolo llamado acuerdo bizantino para determinar cuál será el bloque que se adjunte al final de la blockchain.

Ahora podrías preguntarte, ¿qué es el acuerdo bizantino? El acuerdo bizantino es un primitivo donde cada parte tiene una entrada, es decir, la parte I tiene una entrada XI, y eventualmente cada parte obtiene una salida VI. Hay dos garantías principales que nos importan aquí. La primera garantía se llama consistencia. Consistencia significa que, sin importar lo que suceda o las entradas de las partes adversarias, los participantes honestos siempre obtienen el mismo resultado. Los participantes honestos son aquellos que siguen el protocolo tal como está escrito, mientras que las partes adversarias pueden hacer lo que deseen. La segunda propiedad se llama validez, que requiere que, si todos los participantes honestos introducen el mismo valor, entonces el valor que se produce como salida para todos ellos es ese mismo valor.

Volvamos a nuestro esquema anterior y veamos cómo construimos un protocolo blockchain basado en esta idea. El primer caso que examinaremos es cuando el líder es honesto. El líder se elige generalmente observando quién tiene el boleto de lotería más bajo y, en este caso, supongamos que es la parte que propuso el bloque D. Dado que esta parte es honesta, enviará este bloque D a tiempo a todos los demás, por lo que todas las partes honestas que participan en el protocolo BA introducirán el bloque D en dicho protocolo. El adversario, representado aquí por un pequeño diablo, puede introducir cualquier bloque que desee, pero la garantía de validez nos dice que, dado que todas las partes honestas introdujeron el mismo bloque D, todas las partes honestas obtendrán ese bloque como resultado, por lo que han llegado a un acuerdo sobre cuál será el próximo bloque en la blockchain.

En el otro caso, cuando el líder es deshonesto, la situación es diferente. Un líder deshonesto puede enviar su bloque a algunas partes pero no a otras, por lo que las partes no necesariamente tienen la misma visión sobre quién tiene el boleto de lotería más bajo, y por lo tanto, los participantes honestos pueden introducir diferentes valores. Pero aquí nos apoyamos en la condición de consistencia del acuerdo bizantino, que garantiza que, incluso en tal caso, todos los participantes honestos obtendrán el mismo resultado. Podría ser un valor nulo, pero esto está bien porque solo significaría que acordamos un bloque vacío como el siguiente bloque en la blockchain. Repitiendo este proceso, eventualmente construimos una cadena muy larga de bloques.

En este punto, podrías preguntarte si los protocolos basados en BFT nos brindan una gran finalización, ¿por qué molestarse con los protocolos de Nakamoto? La razón de esto es que los protocolos BFT funcionan en lo que se llama un entorno de permisos, que es un entorno en el que todas las partes se conocen entre sí.y saben sobre sus claves y es un sistema cerrado donde las partes no pueden unirse y salir a voluntad. Durante mucho tiempo no estaba claro cómo construir un sistema completamente sin permisos en el que cualquiera con una computadora pudiera unirse, hasta 2008, cuando Satoshi Nakamoto propuso Bitcoin, que se basaba en las llamadas loterías de prueba de trabajo. En las loterías de prueba de trabajo, resolverías acertijos criptográficos para obtener el derecho a construir nuevos bloques, y de esta manera, siempre que la mayoría del poder computacional esté en manos honestas, se puede usar este enfoque de cadena más larga para llegar a un consenso en un libro contable en constante crecimiento. El problema con esto, por supuesto, es que utiliza mucha energía; de hecho, Bitcoin consume tanta energía que se podría abastecer a un país entero con la energía que gasta.

Entonces, en 2011, en una publicación en un foro, se propuso reemplazar esta lotería basada en prueba de trabajo con una lotería basada en criptografía de clave pública. Luego tomó un tiempo para que la comunidad de investigación retomara esta idea, pero eventualmente llevó a los llamados protocolos de prueba de participación. Pero aún eran protocolos Nakamoto, por lo que eran algo lentos en la liquidación. La gente redescubrió los protocolos BFT de los 80 y, utilizando las ideas de la prueba de participación, lograron hacerlos también sin permisos.

Para entender por qué no estamos abandonando el paradigma de Nakamoto, debemos considerar los requisitos que quisiéramos de nuestra blockchan. El primer requisito que queremos es que la blockchan sea segura contra un adversario que controle menos del 50% de la participación. En otras palabras, mientras la mayoría de la participación en el sistema esté en manos honestas, queremos que todo funcione sin problemas. La segunda cosa es que queremos apoyar la seguridad incluso cuando este adversario sea adaptativo, es decir, un adversario muy fuerte que podría intentar corromper a los participantes incluso durante el protocolo, sobre la marcha, basado en lo que ha sucedido antes.

Hay dos propiedades más que son muy importantes para nosotros. La primera es la participación dinámica, que establece que incluso cuando la fracción del stake que participa activamente en el protocolo disminuye, el protocolo debería continuar construyendo bloques; debería haber vivacidad incluso si la participación es baja. Sin embargo, durante esos momentos podría ser que el adversario tenga una mayoría relativa, porque una razón para la caída de la participación es que algunas personas honestas podrían estar temporalmente desconectadas, y entonces las partes adversarias tendrían una mayoría de la participación por un momento. Ahí es donde entra la última propiedad que nos interesa, llamada auto-sanación. Queremos que una vez que las personas honestas regresen y haya nuevamente una mayoría honesta de participación, el protocolo se recupere después de un tiempo.

Estas dos propiedades, juntas, no son compatibles actualmente con ningún protocolo de estilo BFT, y por eso seguimos con el paradigma de Nakamoto. Sin embargo, nos preguntamos, ¿cómo podemos hacerlo más rápido? Aquí es donde entra Peras. La idea principal detrás de Peras es que en la práctica, en el ecosistema de Cardano, casi nunca hay una bifurcación larga; de hecho, la bifurcación más larga observada hasta la fecha ha sido de longitud tres. Entonces, una idea que podríamos tener es que, si las partes siempre tienen algún tipo de prefijo común, ¿por qué no ignorar algunos de los bloques más nuevos, quizás de los slots L más recientes, donde L es un parámetro que podemos elegir, tal vez 60 segundos o 150 segundos? Luego, vamos a ser optimistas y asumir que todos ven el mismo bloque, el bloque rojo aquí, como el final de su cadena. ¿Hay alguna manera de darle a ese bloque un impulso para que se establezca más rápido?

La respuesta es que podemos dividir el tiempo en rondas de votación, y en cada ronda de votación, las partes simplemente van a votar por este final de la cadena cuando se eliminan los slots más nuevos. Si el número de votos para un bloque en particular supera un cierto umbral, entonces es cuando vamos a darle el impulso al bloque. Para poder representar tal impulso de una manera más eficiente, sin tener que proporcionar todos los votos, hay una forma de convertir todos esos votos, si están por encima de un umbral, en un certificado corto que atestigua que este bloque ha recibido el impulso.

El cambio de paradigma aquí es que ya no preferimos la cadena más larga, sino que ahora vamos por la cadena más pesada, porque la idea es que los bloques normales tienen un peso de uno, y los bloques con el certificado obtienen un impulso adicional de B, donde B nuevamente es un parámetro. Veremos cómo la elección de B afecta el resto del protocolo más adelante en esta charla.

Una cosa que debemos asegurarnos absolutamente es que en cada ronda de votación no se certifiquen múltiples bloques, porque queremos que solo un bloque reciba el impulso. Esto se logra con un argumento clásico llamado intersección de quórum. Con este argumento, imaginamos que efectivamente sucedió que dos bloques obtuvieron un certificado o impulso, y organizamos a los votantes en estos dos círculos: los votantes que solo votaron por el Bloque 1 van en el círculo rojo, y los votantes que votaron por el Bloque 2 van en el círculo azul. Luego, hay algunos votantes que podrían haber votado por ambos bloques; ellos aparecerán en esta intersección. Sin embargo, sabemos que, si hay T partes corruptas, entonces habrá como máximo T votantes en esta intersección.

Por otro lado, sabemos que todo el círculo rojo debe ser al menos de Tao porque es el umbral que uno necesita cruzar para obtener un certificado, y lo mismo es cierto para todo el círculo azul. También tiene que ser al menos de Tao. Ahora, si haces los cálculos y asumes que hay un total de n partes, obtienes que n está limitado inferiormente por 2 Tao menos T, y si lo volteas, puedes ver que si hay una situación en la que dos bloques reciben un impulso, entonces esto tiene que cumplirse, es decir, T menor o igual que N más T dividido por 2. Por lo tanto, si quieres evitar una situación en la que dos bloques reciban un impulso, todo lo que tienes que hacer ahora es elegir Tao mayor que esto, y eso significaría que ya no es posible. Entonces, en nuestro caso, donde como que queremos que T sea la mitad, porque buscamos seguridad contra un adversario que controle hasta el 50% o estrictamente menos del 50% de la participación, si elegimos Tao para que sea alrededor del 75% de de todos los votantes, podemos garantizar que en cada ronda de votación habrá como máximo un ganador. La idea principal ahora es que si tienes un bloque aquí, representado por este círculo, el cual te importa, la esperanza es que rápidamente se construyan muchos certificados encima de él, lo que aumenta el peso de la cadena que contiene este bloque y, por lo tanto, este bloque se confirmará mucho más rápido que en el sistema tradicional de Nakamoto, donde lo único que puedes hacer es esperar que se construyan bloques encima. Aquí, en cambio, obtenemos estos certificados construidos encima, y estos certificados llevan peso adicional, lo que debería hacer que este bloque se confirme más rápido.

Desafortunadamente, las cosas no son tan fáciles. En particular, hay algo que el adversario puede hacer, lo cual es un ataque de balanceo. Como mencioné antes, estamos siendo algo optimistas al esperar que las partes siempre tengan este prefijo común, pero a veces este no es el caso, y nos encontramos en una situación donde algunas partes ven esta cadena y otras partes ven otra cadena. Cuando empezamos a votar, podría suceder que los votos honestos se dividan, por ejemplo, un 50% de los votos honestos podrían votar aquí y el resto de los honestos votará aquí. Esto significa que las partes honestas por sí solas no pueden superar el 75% que necesitamos para un impulso.

En esta situación, donde los votos honestos están divididos 50/50, es posible que el adversario tenga algunos votos adicionales que le permitan completar uno de los dos bloques hasta convertirlo en un bloque impulsado. Supongamos, por el bien del argumento, que este será el bloque en la parte inferior. El adversario tiene suficientes votos para certificar este bloque, pero decide no liberar esos votos inmediatamente. En cambio, espera a que las partes honestas continúen construyendo bloques. Si el adversario es realmente fuerte, digamos con un 30%, 35% o incluso 40%, entonces puede detener la generación de certificados por completo, lo hacen durante algún tiempo hasta que la cadena superior alcance una longitud aproximadamente equivalente al impulso que la cadena inferior obtendría con el certificado. En ese momento, el adversario libera los votos faltantes y este bloque recibe un impulso. Ahora nos encontramos en una situación donde, en términos de peso, ambas cadenas son iguales: la cadena superior tiene muchos bloques que cuentan solo como uno cada uno, pero es bastante larga, y la inferior es corta, pero recibe el impulso. Ahora estamos en una situación en la que el adversario ha creado una división, y lo peor es que puede continuar haciéndolo indefinidamente. Si repite esto suficientes veces, este fork se hará más y más largo, lo que es una violación de la seguridad del protocolo.

Para entender cómo podemos evitar este problema, volvamos a la situación inicial donde tenemos esta pequeña división porque no hay un prefijo común, y estamos en una situación donde el adversario en algún momento puede liberar votos que le dan al bloque inferior un impulso. Lo que nos interesa medir es la ventaja que tiene el adversario en ese momento, y eso es aproximadamente equivalente a la cantidad de impulso que se obtiene, es decir, este parámetro ( B ) que mencioné antes. Ahora veremos cómo esta ventaja del adversario se desarrolla con el tiempo, asumiendo que si no vemos un certificado en una ronda particular, dejamos de votar por completo. Lo que sucede con el tiempo es que las partes simplemente construirán bloques normales de Nakamoto, y esta ventaja disminuirá porque las partes construyen la cadena superior, y la ventaja del adversario se vuelve cada vez menor hasta que, en algún punto, alcanza cero. Antes de eso, era aproximadamente cuando el adversario podría intentar realizar el mismo ataque nuevamente, así que lo que tenemos que hacer es dejar que esto continúe hasta que la ventaja del adversario realmente se vuelva negativa y solo una vez que sea suficientemente negativa vamos a reiniciar el procedimiento de votación para evitar este ataque de división que vimos antes.

La pregunta es, ¿cuál va a ser exactamente la regla para el reinicio? Ahora, lo que podríamos decir es que la regla de reinicio es mirar la última ronda en la que se vio un certificado; en nuestro caso, llamémosla ronda R, y luego simplemente se va a esperar K rondas y se reiniciará. Sin embargo, el adversario puede volver a molestarnos si hacemos esto, ya que tiene votos guardados, que puede liberar justo antes de la ronda R más K a algunas partes honestas, pero no a otras. Esto resulta en que algunas partes honestas voten en la ronda R más K y otras solo voten en la ronda R más K+1, lo que desincroniza a las partes honestas, lo que estamos tratando de evitar.

La solución a este problema es que, efectivamente, vamos a hacer primero una fase de recuperación en la que esperamos que la ventaja del adversario disminuya y luego vamos a tener una fase de inclusión de certificado en la que las partes honestas van a enviar a la cadena el último certificado que conocen. Durante esta fase de inclusión de certificado, el adversario puede optar por liberar los votos restantes, pero debe hacerlo antes de que la fase de inclusión de certificado termine. Luego, simplemente dejamos que este período se estabilice, continuando construyendo bloques Nakamoto encima de esto. Esto significa que ahora podemos usar la cadena como consenso para decidir cuándo hacer el reinicio, porque en el punto al que lleguemos aquí, una de dos cosas va a ocurrir: o bien el último certificado en la cadena es de la ronda R (esto ocurre si el adversario no libera los votos que tiene guardados), o es en la ronda R+1 (lo cual sucede si el adversario sí libera esos votos a tiempo). En cualquiera de los dos casos, tendremos un acuerdo sobre cuándo reiniciar.

También se puede ver que hay una compensación entre la cantidad de impulso que damos y la duración de la fase de recuperación y, por lo tanto, la duración de toda la fase de enfriamiento. Si damos mucho impulso, lo que en el caso favorable nos da un asentamiento rápido, en el caso desfavorable da una gran ventaja al adversario, así que hay una compensación entre cuán rápido se puede estabilizar en el caso optimista y cuánto tiempo se tiene que esperar si algo sale mal y se tiene que entrar en una fase de enfriamiento.

Ahora, aún tenemos un pequeño problema, porque a veces las partes tendrán este prefijo común que necesitamos para un asentamiento rápido y otras veces no lo tendrán. Sin embargo, cada vez que no lo tienen, no solo no obtenemos un impulso, sino que entramos en esta fase de enfriamiento, la cual dura bastante tiempo. Nos gustaría evitar esto si es posible, y en particular queremos evitarlo mientras el adversario no controle más del 25% del total de la participación. ¿Por qué 25%? Porque necesitamos superar el 75% para obtener un certificado. Si el adversario controla más del 25% de la participación, siempre puede evitar que se cree un certificado simplemente no votando. Esto es lo mejor que podemos esperar.

Vamos a demostrar que es posible evitar la fase de enfriamiento en tal escenario. En particular, lo que vamos a hacer es cambiar la estructura de nuestras rondas para que se vean un poco diferentes. Hasta ahora, en cada ronda simplemente votábamos, pero ahora es un poco más complicado: hay tres subfases. En la primera fase, vamos a hacer una pre-votación donde todos simplemente votan por la punta de la cadena sin los L bloques más recientes. Esto es similar a cómo votábamos antes, pero no cuenta, solo es para ver qué hay disponible. Luego, la segunda fase consiste en una fase de acuerdo bizantino, donde las partes ejecutan un acuerdo bizantino como vimos en el caso primitivo.

La regla es que, si una parte al comienzo de esta fase ve un bloque en la pre-votación que obtiene el 75% de los pre votos, entonces ingresarán uno en este acuerdo bizantino. Si no ven uno, ingresarán cero. Lo que sucederá es lo siguiente: si hay un prefijo común, todas las partes votarán por el mismo bloque y, dado que asumimos que el adversario tiene como máximo el 25%, esto significará que habrá un bloque que obtenga más del 75%. Esto, a su vez, hace que todas las partes, o al menos todas las partes honestas, ingresen uno en el acuerdo bizantino y, si recuerdan la propiedad de validez del acuerdo bizantino, en tal caso, uno también será la salida garantizada de esta fase del acuerdo bizantino.

Por otro lado, a veces no tenemos el prefijo común al comienzo de una ronda, en cuyo caso podría ser que no todas las partes honestas ingresen uno en el protocolo de acuerdo bizantino porque tal vez no hay ningún bloque que obtenga el 75% de la pre-votación. Sin embargo, la consistencia aún garantiza que todas las partes honestas lleguen a un acuerdo sobre si hay o no tal bloque. Así que la salida será uno o cero para todas las partes. Finalmente, si el acuerdo bizantino da como resultado uno, entonces todos votarán por el bloque que obtuvo el 75% de la pre-votación; de lo contrario, todos votarán por el símbolo especial de “abajo”, que simplemente representará el bloque vacío.

De esta manera, el adversario no tiene la oportunidad de guardar nada bajo la manga para molestarnos más adelante, ya que siempre obtenemos un certificado, ya sea para un bloque o para el bloque vacío . Ahora, una cosa de la que aún debemos ocuparnos es si los adversarios controlan más del 25% de la participación. Esto funciona si el adversario controla menos del 25% de la participación y nos permite obtener un asentamiento rápido. Ahora, debemos renunciar al asentamiento rápido si el adversario controla más del 25% de la participación.

Pero también tenemos que asegurarnos de que el adversario no comprometa nuestra seguridad, y al igual que hicimos antes, si no logramos producir un certificado para cualquier cosa en particular, ya sea un bloque o el bloque vacío, debemos entrar en un período de enfriamiento. Sin embargo, a diferencia de antes, solo tenemos que hacerlo en escenarios donde el adversario controle más del 25% de la participación. Por lo tanto, la regla es que las partes solo votan si ven un certificado para un bloque en la ronda anterior o para el bloque vacío; eso está bien, pero debe haber un certificado. La segunda regla es que, como queremos que estos bloques certificados se construyan unos sobre otros para garantizar una liquidación rápida, una parte solo vota si el bloque que resulta de esta fase de pre-votación realmente extiende el bloque previamente certificado. Al hacer esto, podemos esperar que nuestro bloque de interés, representado aquí por el círculo, se entierre rápidamente bajo mucho peso.

A veces puede suceder que no haya un certificado para un bloque, por lo que no añade ningún peso, pero tampoco provoca un período de enfriamiento siempre que el adversario controle menos del 25% del stake. Por lo tanto, aunque algunos de estos bloques están abajo, también habrá suficientes certificados para bloques reales, lo que pondrá mucho peso sobre nuestro bloque de interés aquí y se liquidará rápidamente.

Es importante notar que cuanto más tiempo dejamos correr el acuerdo bizantino, más probable es que sea exitoso. La razón es que los protocolos de acuerdo bizantino que terminan rápidamente en expectativa tienen la propiedad de que, si lo ejecutas durante una ronda, obtienes consistencia y validez con probabilidad de 1/3 y, luego, en la siguiente ronda, lo obtienes nuevamente con probabilidad de 1/3, y así sucesivamente. La probabilidad de no ser exitoso después de cinco rondas es 1/3 elevado a la quinta potencia, lo cual ya es bastante pequeño. Sin embargo, si se desea que esta probabilidad sea muy baja y realmente evitar períodos de enfriamiento, es necesario que el acuerdo bizantino binario se ejecute durante más tiempo. Esto representa otro compromiso: uno entre la duración de esta fase de acuerdo bizantino y el éxito en evitar un período de enfriamiento.

Ya hemos llegado al final de la presentación, y es momento de hacer un pequeño resumen. Peras es un protocolo que funciona en un entorno sincrónico, lo que significa que asumimos que todos los mensajes se entregan dentro de un tiempo límite fijo y que las partes tienen relojes sincronizados. Esa es exactamente la misma suposición que se hace en el protocolo actual de Ouroboros. El nuevo protocolo es resistente contra un adversario que controle como máximo el 50% de la participación, al igual que el actual Ouroboros. En términos de velocidad de liquidación, podemos decir que obtenemos un tiempo de liquidación constante esperado contra cualquier adversario que controle hasta el 25% de la participación total, y obtenemos garantías de liquidación similares a las del modelo Nakamoto normal para adversarios entre el 25% y menos del 50%.

Peras también admite la participación dinámica, lo que significa que el protocolo continúa produciendo bloques incluso cuando algunas de las partes participantes se desconectan. Puede que no siempre sea posible durante estos períodos producir certificados y, por lo tanto, lograr una liquidación rápida, pero al menos se obtiene una liquidación comparada con el modelo Nakamoto normal. Finalmente, el protocolo también admite la auto-recuperación como un caso especial. Piensa en un período durante el cual el adversario ha tenido una mayoría relativa porque algunos participantes honestos han estado desconectados y asume que esta ventaja no es demasiado alta, de modo que pueda corregirse con un período de enfriamiento. En este caso especial, es fácil ver que el protocolo tiene capacidad de auto-recuperación.

Esto concluye la presentación y les agradezco mucho su atención.

1 Like