Transcripción al español de “IOHK | Cardano whiteboard; Ouroboros, with Prof. Aggelos Kiayias, Chief Scientist”
Publicado en el canal de Youtube de IOHK el 17 de Diciembre de 2017
Enlace a la versión doblada al español
Muy bien, bienvenidos, soy Aggelos Kiayias. jefe científico en IOHK y jefe de ciber seguridad y privacidad aquí en la Universidad de Edimburgo. Así que hoy el tema de nuestra discusión va a ser protocolos de prueba de participación y más ampliamente protocolos blockchain ¿cómo los diseñas, cómo puedes probar que son seguros? Para empezar, me gustaría hablar un poco de diseño criptográfico en general, cómo piensa la criptografía cuando van a diseñar un protocolo de seguridad, como un protocolo blockchain, así que vamos a eso. Primero tenemos un objetivo y ese objetivo sería algo que nos gustaría hacer, podría ser, por ejemplo, diseñar un libro contable, cómo un protocolo blockchain lo trata de resolver, o podría ser algo más como un componente como firma digital. Dado ese objetivo y vamos a describirlo un poco más tarde cómo es posible especificar ese objetivo particularmente, hay otras dos cosas que tenemos que determinar. Lo siguiente son los recursos que están disponibles para las partes que van estar ejecutando el protocolo o para las partes que van a usar un algoritmo para cumplir con el objetivo. Y junto con los recursos tenemos que diseñar y describir un modelo de amenaza. Ahora, estos dos vienen de la mano, así que los recursos serían cosas que cuando escribimos nuestro algoritmo, las partes que están utilizando el algoritmo van a tenerlos disponibles. Y el modelo de amenaza describirá lo que al adversario se le permite y lo que no se le permite hacer. Para presentar un buen modelo de amenaza tendríamos que pensar exactamente qué va a pasar cuando nuestro algoritmo sea desplegado en el mundo real, y nos gustaría que el modelo de amenaza capture completamente lo que va a suceder.
Ahora, dado estos dos, viene un algoritmo o el protocolo, el algoritmo o el protocolo será código o una especificación para el código que utiliza los recursos disponibles y cumple con el objetivo dado el modelo de amenaza. Ahora, esto es lo que esperamos que funcione, lo que nos gustaría es de hecho probar formalmente que este es el caso. Típicamente esto también implicaría algunos otros supuestos y estos supuestos podrían ser cosas que creemos que son verdaderas acerca del mundo, por ejemplo, un supuesto común que se utiliza en criptografía es que ciertos problemas de computación como el conocido problema de logaritmo discreto, es un problema difícil de resolver. Así que estas serían las suposiciones, digamos matemáticas, frecuentes en la naturaleza, que vamos a asumir cuando discutamos que nuestro protocolo o algoritmo cumple con el objetivo. Y finalmente dado todo eso, tendríamos una prueba, y esa prueba de seguridad va a establecer que el algoritmo cumple con el objetivo, dados los recursos del modelo de amenaza que hemos especificado, bajo los supuestos que hemos descrito. Así que esta es la lógica general que usamos en la criptografía moderna para argumentar que los protocolos son seguros, los diseñamos siguiendo esta lógica. Y el diseño de los protocolos es en realidad seguir una retroalimentación entre aquellos, a veces tenemos que volver a revisar los recursos que están disponibles, a veces tenemos que revisar el modelo de amenaza, entonces tenemos que afinar el algoritmo, mirar la prueba y luego otra vez, porque frecuentemente las cosas no estarán exactamente en la forma en que son apropiadas para que una prueba de seguridad emerja. El último objetivo es que esto sea sólido, y entonces una vez que tenemos esto, el algoritmo en el protocolo se especificará y será implementado, yendo un paso más allá, tenemos el protocolo del algoritmo, tenemos una especificación que surge y luego dada esa especificación, tenemos la implementación. Así que esto da una imagen más grande.
Vamos a ver cómo se puede poner esto en práctica, podemos ver cómo podemos aplicar esta lógica al diseño de un libro contable distribuido, ¿cuál es el objetivo en el caso de un libro contable?, es algo que, llamémoslo libro contable distribuido, necesitamos algo más de espacio para describir lo que es un libro contable. No deberíamos pensar en un libro contable como algo necesariamente ajustado al protocolo blockchain en sí mismo, esto es un punto importante para tener en cuenta, el protocolo blockchain vendrá como una solución al problema del libro contable. Para tener un libro contable, necesitamos dos cosas, persistencia y vivacidad, estas son las dos propiedades básicas. Estas dos propiedades se refieren a un registro de transacciones. La persistencia es un tipo de propiedad de seguridad, básicamente dice que la vista del registro de transacciones es estable, si le preguntas a cualquier nodo que esté implementando el libro contable, te dará la misma versión del registro. Y eso también debería ser cierto durante un período de tiempo, así que si preguntas hoy ¿cuál es el registro?, el registro que encontrarás mañana será una extensión del registro que escuchaste ayer. Así que esto es capturado por la persistencia y es posible definir esto de una manera matemáticamente precisa. La persistencia no es suficiente, lo que también necesitamos es que el libro contable, el registro de transacciones, se pueble con transacciones que son admitidas por aquellos que usan el registro. Así que la vivacidad básicamente dice que las nuevas transacciones se añaden en frecuencia regular, y como mínimo hay un límite superior después del cual una transacción que se envía a los nodos que están implementando el libro contable será incluida en el registro. Así que estas son las dos propiedades fundamentales de lo que es el objetivo de un libro contable distribuido.
Así que ahora veamos cómo podemos implementar eso. Hemos hablado de los recursos y hemos hablado del modelo de amenaza. Hablemos de los recursos primero, los recursos disponibles serían, primero, que las partes tienen memoria privada y tienen la habilidad de muestrear cadenas aleatorias. Estos son recursos importantes para el diseño del protocolo, y estos son típicos, debería decir, en diseño criptográfico, así que es típico en el diseño criptográfico, pensamos que un sistema informático que podría llamarse “una parte” para la simplicidad en el contexto de un protocolo, que tiene su propia memoria, que sólo en sí misma puede acceder a ella, y tiene la habilidad de tomar muestras al azar, y que esa aleatoriedad es suya propia, no es compartida con otras partes. Ahora, este muestreo o aleatoriedad también debería ser privado en el sentido de que un atacante desde el exterior no debería ser capaz de subvertir la aleatoriedad de una parte, así que este es el primer recurso importante. Otro recurso debería ser el acceso a una red, que es relativamente sincronizada, llamémoslo así. Así que básicamente esto dice que cuando una parte quiere enviar un mensaje, se facilita acceso a la red y de manera relativamente sincrónica ese mensaje va a llegar a las otras partes.
Bien, y esto siguiente describiría el modelo de amenaza, en un modelo de amenaza nos gustaría especificar lo que el adversario es capaz de hacer, el adversario debería controlar un número de partes. Tenemos que poner un límite sobre cuántas partes debería controlar el adversario, y dependiendo de la configuración, ajustaremos este límite para que encaje con el tipo de diseño que nos gustaría realizar. Por ejemplo, en la configuración de prueba de trabajo, digamos como en Bitcoin, el límite en el número de partes que el adversario controla, es que debe restringir al adversario para ser la minoría del poder total de hash que está disponible a la red. En el caso de un protocolo de prueba de participación, en contraste, nos gustaría el límite de restringir al adversario a la minoría de la participación que está registrada en el libro contable, así que esto también proporciona el modelo de amenaza. Con eso, veamos cuál sería la solución, hagamos un contraste entre los dos, prueba de trabajo, prueba de participación. En una configuración de prueba de trabajo lo que tenemos es que las partes se van a estar comunicando entre sí, resolviendo pruebas de trabajo e intercambiando bloques que grabarán lo que sea que quieran incluir en el libro contable. Lo que está sucediendo es que en una solución basada en prueba de trabajo para un libro contable, como la de Bitcoin, tienes un bloque Genesis, que luego es extendido por las partes a medida que encuentran prueba de trabajo, cada uno de estos bloques es una prueba de trabajo, y aquí dentro tienes un número de transacciones. En el caso de prueba de participación algo similar está sucediendo, tienes un juego, una secuencia de bloques, cada uno de ellos tiene transacciones, pero lo que tienes dentro de la producción de bloques requiere una prueba de participación. Veamos la diferencia entre los dos, producir una prueba de trabajo requiere que las partes resuelvan una ecuación criptográfica moderadamente difícil, inequidad, específicamente en el caso de Bitcoin, así que puedes pensar en todo el protocolo operando como una elección, en cualquier momento, una de las partes es elegida para producir el siguiente bloque, y el siguiente bloque se va a producir básicamente al azar, es un muestreo al azar por parte de los que están intentando producir el bloque. En la prueba de participación lo que sucede es un tipo de operación similar, en una configuración de prueba de participación el próximo bloque es producido por uno de los interesados, al azar, basado sobre la participación que está registrada en la blockchain. Así que lo que tenemos en ambos casos es una elección, que apunta a la siguiente parte elegible para emitir un bloque. La naturaleza de esa elección es diferente, en el caso de prueba de trabajo, y hagámoslo ahora más específico, Bitcoin, lo que tenemos es que la elección se basa en resolver este problema moderadamente difícil especificado por el cliente Bitcoin, hagámoslo más específico para la prueba de participación, en el caso de Ouroboros lo que tenemos es que la elección se basa en un protocolo criptográfico que crea aleatoriedad y la almacena en la blockchain. Sin embargo, en ambos casos, la lógica de alto nivel es similar, está este proceso de elección que permitirá a una de las partes emitir un próximo bloque.
Así que esta es la idea central que tipifica cómo estos bloques y protocolos funcionan. Algo que es interesante señalar, es que hay un supuesto diferente que ocurre con respecto al bloque Génesis. Ambos protocolos tienen, como requisito para proporcionar a las partes un bloque Génesis que pueden usar como punto de referencia de lo que es la blockchain, cuál es la blockchain correcta. Y ese punto de referencia, en el caso de Bitcoin, especifica sólo el bloque inicial, y eso es un bloque inicial, más una configuración de nivel de dificultad, por lo que el nivel de dificultad se almacena en el bloque génesis de Bitcoin, y aquí tenemos una distribución inicial de los interesados. Así que en ambos casos habrá un supuesto sobre el bloque Génesis, el bloque Génesis debería saber algo sobre el estado del mundo cuando la blockchain se inicia. En el caso de Bitcoin, deberías llegar al nivel correcto de dificultad que refleja cuántas partes estarán produciendo bloques cuando la blockchain comienza. Y de manera similar, hay una distribución de titulares, debería ser una distribución que ha sido preestablecida y codificada en el bloque Génesis del protocolo de prueba de participación. En ambos casos la suposición sería que debe haber una mayoría honesta, mayoría honesta de titulares aquí, mayoría honesta de poder de hash aquí, así es cómo se comparan los protocolos.
Veamos cómo probamos que estos protocolos son seguros, y bajo qué supuestos y qué argumentos los dos protocolos podrían ser diseñados para ser seguros. Vamos ahora a la prueba de seguridad, ¿cómo argumentamos que los protocolos blockchain son seguros? Y otra vez, voy a hacer un contraste entre un protocolo de prueba de trabajo como Bitcoin y un protocolo de prueba de participación como Ouroboros. Así que en el caso de Bitcoin, la lógica básicamente es la siguiente, lo que tienes en el funcionamiento del protocolo es que múltiples blockchains coexisten, la razón de ello, en primer lugar, es que las partes naturalmente se bifurcan, no están sincronizadas, no están coordinadas, no hacen ejecutar al protocolo de manera coordinada, así que puedes tener muchas bifurcaciones emergiendo naturalmente. La misma situación estaría ocurriendo en una configuración de prueba de participación, debería decir, así que los dos protocolos como que tienen la misma lógica, en términos de la resolución de estas bifurcaciones, las partes siguen la cadena más larga. Ahora, la definición de la más larga es ligeramente diferente entre los dos, pero digamos que en términos simples, la blockchain basada en prueba de trabajo seguirá la cadena que tiene la mayor cantidad de dificultad o si quieres la mayor cantidad de bloques, si la dificultad se fija para cierta parte de la ejecución, y aquí habrías seguido la blockchain con la mayor cantidad de participación, de nuevo, la mayor cantidad de bloques, por lo que es una regla similar en ambos casos, pero veamos cómo esto va a reflejarse en los argumentos de seguridad. Lo que sucede en prueba de trabajo es que, porque resolver un bloque es un problema moderadamente difícil, van a estar estos momentos, aquí está tal momento, en que se produce un bloque únicamente por una sola parte honesta, así que en el análisis del protocolo de la blockchain Bitcoin, esto ha sido llamado ronda única de éxito, así que básicamente es un período de tiempo en el que sólo una única parte honesta fue exitosa. Ahora algo muy interesante sucede con esas rondas que tienen un éxito único, si miras la ejecución del protocolo, lo que está sucediendo es que si tal ronda ocurre, el bloque que se produce por la parte honesta será adoptado por todas las demás partes honestas, a menos y sólo a menos, que el adversario actúe y emita otro bloque que confunde a las partes honestas y los divide. La piedra angular del análisis de la prueba de trabajo basada en el protocolo Bitcoin, marco Bitcoin de este lado de nuevo, es que la tasa de rondas de éxito únicas deben ser mayores que la tasa de bloques producidos por el adversario. Si eso es asegurado, entonces puedes asegurar que el adversario no será capaz de mantener lo que se conoce como una bifurcación. Así que esto es algo que nos permitirá probar la persistencia, de modo que la persistencia, estará implicada por esta incapacidad del adversario de mantener una larga bifurcación. Una bifurcación larga aquí es relevante y es porque es importante pensar en una bifurcación durante un período de tiempo, se producirán pequeñas bifurcaciones, pero eventualmente, durante un período de tiempo suficientemente largo, un número de tales rondas únicamente exitosas ocurrirán que superará el número de bloques que son producidos por el adversario, y porque el adversario tiene que igualar todo ello, cada uno de ellos, entonces no podrá, por lo que la bifurcación se derrumbará. Así que este es el argumento de seguridad central que utilizamos en el documento de la columna vertebral para establecer que el protocolo de la blockchain Bitcoin es seguro.
Esta lógica de prueba es tentadora para que alguien la utilice en la configuración de prueba de participación. Desafortunadamente, lo que te mostraré ahora es que esto no es factible. El principal problema en la configuración de prueba de participación, que tiene una situación similar como esa, puede ser ilustrada con el siguiente ejemplo. Así que imagina que tienes una bifurcación, que de alguna manera empieza desde aquí, y hay, digamos, partes honestas que están actuando, aquí, y aquí tienes un adversario que es elegido para producir el siguiente bloque. En el caso de Ouroboros, pero también de forma similar en otros protocolos, lo que va a pasar es que el adversario, al ser elegido para emitir el siguiente bloque, es capaz de añadir este bloque en más de una blockchain potencial, así que está consiguiendo de alguna manera la habilidad de usar el hecho de que él es el elegido más de una vez, y esto estropea el argumento del recuento que hace que pase esa prueba de seguridad. Esto también es consistente con nuestro entendimiento de que los protocolos de prueba de participación son más difíciles para argumentar su seguridad y está correlacionado con problemas que las comunidades blockchain han identificado como “nada en participación”, significa básicamente que realmente no cuesta nada para que el adversario produzca bloques en múltiples posibles historias del protocolo, y ese es exactamente el punto que estropea el argumento de seguridad aquí. Otra cuestión es “¿es este el final?, ¿es fundamentalmente imposible argumentar que un protocolo simple como Ouroboros sea capaz de ser probado seguro?”. Y la respuesta es no, podemos de hecho producir una prueba de seguridad, sólo tenemos que trabajar un poco más duro. Así que veamos un poco lo que va a hacer factible la prueba de seguridad en el caso de un protocolo de prueba de participación como Ouroboros.
Bien, así que hagamos una especie de inmersión más profunda y veamos cómo se ve una ejecución Ouroboros. Tomemos un segmento de ejecución, segmento de ejecución en el protocolo Ouroboros. Así que lo que está pasando es que múltiples, podemos empezar desde este bloque, y hay un potencial de que múltiples bloques puedan coexistir, y múltiples cadenas. Algunos de estos bloques son producidos por el adversario, aquí está el adversario que ha producido estos bloques. La razón por la que el adversario está en control de estos bloques es que fue elegido en ese momento y como ves, usó la libertad que tiene para emitir múltiples bloques para la misma posición. Así es como se ve la ejecución del protocolo, en ese momento en particular, puedes imaginar que eres la próxima parte que actuará en el protocolo, así que aquí tenemos a un buen chico, viene a hacer su parte y ejecuta el siguiente paso en el protocolo. El último bloque honesto que se produjo fue aquí, y aquí tenemos al adversario que está junto con esa cadena que fue producida por otra parte honesta, también tiene a su disposición otras blockchains que pueden servir a esa parte. En el análisis de seguridad de Ouroboros asumimos que el adversario está en pleno control de la red y puede ordenar mensajes de la manera que prefiera, entonces, si es capaz de añadir más bloques a esa blockhain aquí, será factible para el adversario servir esa blockchain a esa parte. Imagina, por ejemplo, que es posible para el adversario añadir tres bloques más aquí, esa cadena se convierte en más preferible para esa parte, porque el adversario puede arreglar para que esa blockchain sea servida primero y esa parte está utilizando la simple regla de la cadena más larga para producir el siguiente bloque. Así que en ese caso particular, el adversario tiene la capacidad de servir a esa blockchain a esa parte y el siguiente bloque que será producido va a estar aquí. Por otro lado, el adversario podría haber seleccionado para servir primero a esa blockchain, de nuevo, está en control de la red, por lo que esta situación no es una situación muy deseable para Ouroboros. El hecho es que el adversario tiene el control total de lo que la blockchain sirve a la parte, lo que estamos experimentando aquí es una bifurcación. Nos gustaría argumentar que esta situación indeseable sucede con muy pequeñas probabilidades, así que el adversario realmente no puede contar con ello. Así que la forma en que vamos a argumentar esto es tratar de entender cuáles son las características fundamentales de esa estructura a medida que emergen en la ejecución de un protocolo. Cada uno de estos hilos que ves aquí los llamamos tiempos, así que aquí hay un tiempo “uno” y aquí está el tiempo “dos”. Bien, así que aquí tenemos la situación con dos tiempos, que el adversario puede explotar para confundir a las partes honestas que se activan y ejecutan el protocolo. Así que esta es la configuración que nos gustaría evitar y aquí está la que esperamos que suceda la mayoría del tiempo. Así que la mayoría de las veces lo que esperamos en el protocolo, que está ocurriendo, es que la ejecución del protocolo, a partir de aquí, tiene un solo largo tiempo y además, cualquier otros tiempos de desarticulación que existen son demasiado cortos para el adversario para poder llegar al líder. Así que básicamente esto es un segmento de ejecución que proporciona la oportunidad para las partes honestas para adoptar, utilizando la regla de la cadena más larga, ese bloque, y en consecuencia esa cadena. Así que esta es una buena situación y nos gustaría mostrar que esto sucede casi todo el tiempo. Para poder argumentar eso, lo que va a pasar es que tenemos que entender la dinámica de este segmento de ejecución, y cómo son traducidos en este conjunto de tiempos. Así que lo que observamos es que es posible definir una cierta cantidad, que vamos a llamar alcance, que va a especificar, para cualquier segmento de ejecución, cuán por delante, para cada tiempo, el adversario puede ir con respecto al último bloque que fue emitido por una parte honesta. En este caso, ese es el último bloque que fue emitido por una parte honesta, y tal vez el adversario puede tener un bloque más aquí, así que el alcance de ese tiempo va ser uno, mientras que aquí, el alcance de estos otros tiempos es negativo, así que alcance negativo, negativo y positivo. Así que lo que observamos cuando miramos un segmento de ejecución es que el máximo alcance siempre será mayor o igual a cero, que hay un bloque que es el líder, que es de una parte honesta, y tal vez el adversario puede poner algunos bloques encima de ello porque tiene algunas franjas aquí, tiene algunas oportunidades de producir bloques por delante de eso, y otras veces estará detrás, esperemos. Lo que nos gustaría es que la imagen sea siempre así, con todas las demás veces teniendo un alcance que sea negativo. El segundo mayor alcance, lo llamaremos el margen, así que ese es el segundo mayor alcance, así que si el margen es negativo, sabemos que estamos a salvo, porque todos estos otros tiempos están demasiado atrás y no pueden alcanzar al líder. Mientras que si el margen es mayor o igual a cero, entonces es posible que uno de los tiempos alcance a ese bloque y luego tener un problema de ejecución como el que que hemos visto antes, el adversario puede bifurcar a la próxima parte honesta y entregar a la parte cualquier cadena que desee. Ahora nos gustaría mostrar que el margen, que es el segundo mayor alcance, siempre va a ser negativo con probabilidad abrumadora.
Así que ¿cómo vamos a hacer eso?, en nuestro arsenal de análisis pondremos un argumento probabilístico que se relaciona con caminatas aleatorias, las caminatas aleatorias son un área de probabilidad que tiene muchas aplicaciones en protocolos blockchain. La caminata aleatoria más simple es la que se llama caminata aleatoria unidimensional, y los que están familiarizados con el análisis de protocolos blockchain, o incluso el documento blanco de Nakamoto, pueden apreciar cómo eso se relaciona con el análisis básico de la blockchain Bitcoin. Así que una caminata aleatoria, en una dimensión, comienza desde un cierto punto, digamos que cero, y luego volteando una moneda se mueve hacia adelante o hacia atrás. Digamos que la moneda tiene una probabilidad de ir cabeza arriba que es un número P, que es menos o igual a la mitad, y aquí está la moneda yendo hacia adelante. Ahora, con la probabilidad 1 menos P vamos hacia atrás. Así que esa es una imagen de un mundo de caminata aleatoria unidimensional. Las preguntas que son relevantes para la caminata aleatoria son las siguientes. Supongamos que empiezas en la posición cero y podemos pedir para una cierta elección de P ¿cuál es la probabilidad de que te encuentres en otra posición?, lo que es posible mostrar, para una caminata aleatoria unidimensional, es lo siguiente. Es posible dividir la región en tres segmentos, llamemos la del medio volátil, ésta caliente y ésta fría. Y luego, vas a tomar un número de pasos, y después de que tomes un número de pasos examinaremos en qué región estás, luego vas a tomar unos cuantos pasos más y vamos a examinar de nuevo la región en la que estamos. Ahora, es posible hacer un argumento y decir que si la probabilidad es estrictamente menor a la mitad, entonces lo que sucede mientras observas, es que la caminata aleatoria tendrá una tendencia a ir a la izquierda, en el territorio frío, y ese es de hecho el caso, podemos probar que después de una secuencia de pasos, te vas a encontar en un territorio frío y una vez que te encuentres en el territorio frío, sería muy poco probable que puedas volver a volátil o caliente. Lo que realmente va a pasar, es que después de un número de secuencias de pasos, te vas a encontrar en este territorio y eventualmente escapar a la izquierda, eso es porque la caminata aleatoria tiene un sesgo a la izquierda. Lo lindo de esto es que describe una serie de fenómenos en el análisis de los bloques del protocolo Bitcoin, por ejemplo, el hecho de que una cadena maliciosa se quedará atrás de la cadena honesta principal y su comportamiento probabilístico puede ser modelado por este trabajo aleatorio que está sesgado a la izquierda. La configuración fría es básicamente el escenario donde el sistema es estable, porque el adversario se encontró a sí mismo detrás.
Esta es una dimensión de la caminata aleatoria, desafortunadamente, tal caminata aleatoria que puede ser útil cuando piensas en Bitcoin, no puede ser útil en el análisis de Ouroboros, es demasiado simple para capturar exactamente el fenómeno que muestra el comportamiento probabilístico del protocolo. En cambio, lo que es interesante, es que el protocolo se describe bien con una caminata aleatoria de dos dimensiones, les daré un pequeño vistazo. Las dos cantidades que son relevantes en esta caminata aleatoria de dos dimensiones es margen y alcance, o para ser precisos, el alcance máximo que tiene un determinado segmento de ejecución. Recuerden, el alcance máximo va a ser el alcance del tiempo que está más adelante, y el margen va a ser el segundo tiempo que nos gustaría que sea de alcance negativo. Así que lo que nos gustaría en esta caminata aleatoria bidimensional, es mostrar que el margen va a escapar hacia menos infinito. Como en el caso de Bitcoin, queríamos tener la oportunidad del adversario para traer de vuelta su cadena comparable a las partes honestas, queríamos escapar hacia el menos infinito, en la dimensión única. Aquí, nos gustaría que el margen vaya a este menos infinito, en esa dirección, porque recuerda, el margen es lo que el adversario necesita para llegar a las partes honestas que están produciendo bloques en la cabeza de la cadena. Por desgracia, la relación entre estos dos parámetros es más compleja que una simple composición de dos caminatas unidimensionales, y lo que sucede en realidad es que la caminata es un poco como eso. Cuando estás en ese dominio, lanzas de nuevo una moneda, siguiendo este comportamiento, que como ves, es un tipo de comportamiento unidimensional. Y dado que el alcance es siempre positivo, lo que pasa cuando estás en esa posición es que sólo vas abajo, así que como esto. Pero ahora, lo que está sucediendo una vez que subes, debería darme a mí mismo un poco más de espacio para mostrarte exactamente el fenómeno de esta caminata aleatoria. Así que una vez que subes, tendrás de nuevo la caminata aleatoria subiendo, así, y como ves hasta ahora, esto es más o menos un simple comportamiento unidimensional, pero una vez que llegas a ese punto, lo que está sucediendo es que la caminata aleatoria se siente atraída por cero. Así que no sigue el mismo camino ascendente como antes, y puedes ver por qué esto complica el análisis. Lo que nos gustaría es que el margen vaya hacia los valores negativos, menos infinito, pero lo que sucede en realidad en el protocolo es que es posible que un atacante corriendo contra el protocolo utilice esta dimensión X, que es el alcance, para compensar por el margen y mantenerlo en cero. La pregunta es ¿es este efecto suficiente para evitar que esta caminata aleatoria escape a menos infinito? Y la respuesta es que no, todavía es posible hacer un análisis, similar al análisis que te mostré para la caminata aleatoria simple unidimensional, y ese análisis básicamente también implica definir regiones sobre el espacio de dos dimensiones, que a grandes rasgos se parecen a eso. Y repitiendo el mismo argumento, así que lo que está pasando es que, aquí va a hacer caliente, aquí es volátil, y aquí es frío. Y resulta que estableciendo las áreas de estas regiones adecuadamente, lo que podemos mostrar es que va a suceder el mismo comportamiento de escape al infinito, que es favorable para las partes honestas, de la misma manera que en el caso de una dimensión. Y esto muestra cómo es posible obtener un tipo similar de análisis de persistencia, donde básicamente establece el hecho de que las partes honestas convergen a una sola cadena, aunque con un argumento más complejo.
Por lo que esta presentación tenía como objetivo darte un vistazo de cómo se realiza el análisis de seguridad de bloques y protocolos. Te mostré un contraste entre Bitcoin y Ouroboros, inspirado en el argumento de seguridad que conocemos para ambos protocolos, y contrasté ambos protocolos para que puedas ver tanto la similitud como la diferencia entre los dos protocolos en términos de argumentos de seguridad que usamos para establecer que son seguros. La situación que sale de toda esta discusión es el hecho de que sí, podemos probar que ambos protocolos son seguros y sus diferentes supuestos. Esto no afecta a otros aspectos de los protocolos que son de importancia crítica, como el rendimiento del protocolo o la huella energética que este protocolo tiene. Lo que sabemos es que ambos protocolos son seguros, aunque como sabes, un protocolo de prueba de participación es un protocolo mucho más eficiente en términos de consumo de energía en comparación con un protocolo de prueba de trabajo. Eso, en sí mismo, sería el tema de otra discusión, muchas gracias por asistir a esta presentación.