Transcripción al español de “Video for Jack: PoW versus PoS”
Publicado en el canal de Youtube de Charles Hoskinson el 21 de Mayo de 2021
Enlace a la versión doblada al español
Hola, este es Charles Hoskinson, transmitiendo en vivo desde la cálida y soleada Colorado, siempre cálida, siempre soleada, a veces Colorado. Ayer no tuve tiempo, pero hoy tengo un poquito de tiempo en mi agenda, antes de irme a casa, quería hablar un poquito acerca de prueba de trabajo versus prueba de participación, de hecho este video es realizado para Jack Dorsey. Ayer Jack dijo “eh, prueba de trabajo es mejor que prueba de participación porque la prueba de trabajo es menos centralizada y más segura”. Saben, esta es una cosa común que se le adoctrina a la gente en la escuela de Bitcoin, tienden a decirlo, y es una cosa bizarra. Normalmente, la mayoría de la gente, los laicos, no tienen fuertes opiniones acerca de protocolos de consenso en ciencias de la computación. Es como decir “¿cuál es tu procedimiento quirúrgico favorito o método para suturar a un paciente?”. Si sos un cirujano probablemente tendrás una respuesta para eso, una opinión, pero si eres un laico estarás como “no tengo idea”, no sé, me gustan las colecistectomías o algo así, ¿quién sabe? Lo que ocurre es que todo el mundo quiere ser un experto, todo el mundo quiere hablar de estas cosas, lo que tenemos es esta conversación desafortunada que es realmente difícil de converger en algo significativo. El propósito de este video es hablar un poco de cómo pensar acerca de estas cosas, y si de hecho estás curioso para hacer el trabajo duro de desarrollar una buena opinión, de hecho voy a darles muchachos asombrosos recursos específicamente para eso, así que déjenme continuar y compartir mi pantalla.
Ahí vamos, bien, la primera cosa para mirar es este encantador documento de Leslie Lamport, de hecho este es uno de los más famosos documentos en ciencias de la computación, horarios, relojes en el orden de los eventos y sistemas distribuidos. Leslie publicó esto creo que en 1970, tiene alrededor de doce mil citaciones, es uno de los documentos más citados en la historia de las ciencias de la computación. Este documento realmente esboza un problema difícil, discute maneras de pensar al respecto y solucionarlo. Así que ordinariamente, cuando sos una única persona, y estás observando algo, digamos que eres Alice, vamos a darle un bonito vestido, y ves un evento, vamos a llamarlo evento A, y ves el evento B. Esto ocurre en una configuración local, Alice los puede ordenar y decir “bien, el evento A ocurrió primero y luego el evento B”. Bien, pero el problema es cuando comenzas a introducir más actores, aquí está Bob, y él está siendo testigo desde la perspectiva de Bob, mirándolo, él vio primero al evento B, así que eso ocurrió primero, y luego vio el evento A, eso ocurrió en segundo lugar. Así que la pregunta es ¿quién tiene razón, es Bob o es Alice? Es una pregunta realmente interesante y Lamport de hecho discutió esto entre otros conceptos, lo llama como orden parcial, hay toda clase de cosas que vienen de aquí. De hecho creó un encantador y hermoso campo de ciencias de la computación, llamado sistemas distribuidos, para este trabajo y otros trabajos Lamport fue premiado con el premio Nobel de ciencias de la computación, el premio Turing. Es un tipo encantador, recientemente vino y habló en nuestro seminario interno, tuvimos oportunidad de hablar acerca de TLA, entre otras cosas, yo quería tratar de hacer que hable de relojes, paxos y él estaba como “no, ya no hago eso, ahora hago TLA”. Si sos muy curioso y querés aprender todos estos principios, primero como que tenés que aprender este tipo de cosas corriendo en una única computadora, luego vas al próximo nivel que es una colección de computadoras que están en diferentes lugares. Tengo dos asombrosos recursos para ustedes muchachos, primero “Series de lecturas del MIT 6.824, la clase de sistemas distribuidos”, cubre introducción, rpc, hilos, gfc, replicación, etc, todo el camino hacia abajo, eventualmente habla de Bitcoin al final. Y hay otra serie de lecturas de Martin Klepman, de la universidad de Cambridge, eso también cubre toda clase de asombrosos temas, es una serie de ocho partes, recomiendo mucho ambas, no son para los laicos, tenés que tener muy buenos antecedentes de programación y entender ciencias de la computación para sacar lo mejor de ellos.
Pero el punto es que esto es un tema en sí mismo, por eso mencioné la situación de cirugía, es algo en lo que realmente tenés que tener mucho conocimiento para comenzar a desarrollar una fuerte opinión respecto a ciertas cosas. Pero en general, cuando hablas acerca de este tipo de problemas, la primer cosa que haces es tratar de trabajar en definiciones y fundaciones. Una de las cosas que hicieron nuestros científicos, escribieron un encantador documento que tiene alrededor de mil cien citaciones, este es el documento GKL, su nombre formal es “El protocolo de la comuna vertebral de Bitcoin, análisis y aplicaciones”. Esto ha sido citado prácticamente más que cualquier otro documento, mil cien veces, un documento muy famoso, de Juan Garay, está en Texas ANM, y dos de IOHK, Aggelos, nuestro jefe científico, y Nikos Leonardos, que está en el laboratorio de la universidad de Atenas, con otros. Básicamente lo que hace este documento es intentar crear definiciones y fundaciones. Crea algunas funciones fundacionales, este concepto de predicado de validación de contenido, función de entrada de contribución, etc. Te da una manera de hablar acerca de un protocolo de criptomoneda. Luego sacas propiedades de ello, dos en particular, la propiedad del prefijo común y la propiedad de calidad de cadena. Esto es muy bonito porque es una fundación teórica, puedes probar toda clase de interesantes y bonitas propiedades acerca de esta fundación. Una vez que tenés eso podés desarrollar lo que se llama un modelo de seguridad, ¿ok? Lo que un modelo de seguridad hace es decir “tengo alguna clase de adversario”, y es malvado, así que le ponemos anteojos y un gorro, un bastón, y el adversario siempre está tratando de romper cosas. Lo que básicamente te dice el modelo de seguridad es cuándo van a ganar, y cuándo van a perder, ¿de qué ataques te estás defendiendo y de que ataques no te estás defendiendo?, eso siempre está conectado con las capacidades del adversario. Así que tus capacidades, por ejemplo “¿tienen una computadora clásica?, ¿tienen acceso a tu computadora?, pueden caer en el medio de comunicación y colectar mensajes?, o quizás tienen una computadora cuántica”. A menudo escuchas cosas como “las criptomonedas no son seguras contra computadoras cuánticas”. Lo que básicamente están diciendo es que si tu adversario tiene una capacidad de computadora cuántica, entonces el modelo de seguridad podría no mantenerse y el adversario podría ganar. Y esto es en lo que piensan los criptógrafos cuando están modelando y construyendo protocolos, hay muchos protocolos que te permiten clasificar órdenes, y decidir cuándo ocurrieron los eventos, tu transacción, mí transacción, básicamente ser el motor de un sistema distribuido. En el caso de las criptomonedas te tenés que mover desde un bloque a otro bloque y esos protocolos podrían ser lo que se denominan tolerantes a fallas Bizantinas, o no tolerantes a fallas Bizantinas, podrían no ser capaces de admitir actores Bizantinos, en otras palabras, “¿podés tener un adversario en tu sistema y la presencia de ese adversario romperá el sistema o no?”. Aquí hay un ejemplo de no tolerante a fallas Bizantinas, protocolo muy simplista. Digamos que tenés un conjunto de siete personas, y lo que haces es decir “ok, vamos a seleccionar de este conjunto de siete personas quién está a cargo para hacer un bloque para nuestra blockchain”, y lo que vamos a hacer es tener un generador de números aleatorios, hacer que todos hagan correr un generador de números aleatorios, y el que sea que tenga el mínimo, será el ganador para esa ronda, ¿ok?. Y de hecho hasta que hagan esto, creo que esto es una prueba de tiempo transcurrido o algo así, o algo llamado Sawtooth. Ahora, en computadoras normales esto es de hecho no es un algoritmo seguro porque lo que yo puedo hacer es piratear mi generador de números aleatorios, y digamos que retorna algo entre cero y uno, simplemente puedo piratear mi generador de números aleatorios y decir “bien, siempre retorna cero”, lo que significa que siempre gano, porque todo el mundo tendrá un valor igual o más grande que el mío. Bien, eso no admite un actor Bizantino, Sawtooth lo admite porque el generador de números aleatorios de hecho corre sobre SGX, así que no podés modificar el código, esto es un ejemplo. Hay un montón de matices y elegancia acerca de cómo son desarrollados estos protocolos, pero siempre, cuando estás desarrollando un protocolo, incluso prueba de trabajo, implícita o explícitamente necesitas alguna noción de definición, y necesitas crear alguna noción de fundaciones de seguridad. Fue desafortunado que Satoshi no hizo eso, fue un protocolo brillante e inspirador, basado en la prueba de trabajo hashcash, pero le tomó años a los criptógrafos para ir alrededor y retroactivamente construir un modelo fundacional para entender lo que sucedió con la prueba de trabajo Nakamoto. Y resulta que hay un montón de bonitas propiedades de seguridad de prueba de trabajo, y hablemos acerca de eso.
Así que, cuando pensás acerca de un protocolo de criptomoneda, y una blockchain, tenés tres cosas que ocurren. Primero tenés que escoger a alguien para hacer un bloque, ¿ok?, ese es el paso uno. Luego dos, necesitás hacer el bloque y distribuirlo, hacer y empujar a la red. Y tres, la red tiene que aceptar el trabajo. Bien, así que todo el consumo energético de Bitcoin ocurre aquí, en la parte de escoger, para hacer el bloque. Así que lo que ocurre es que tenés esta prueba de trabajo que hace la gente, y básicamente están comprando boletos de lotería computacionales, y si obtenés un número mágico, golpeas un valor mágico, eso es bajo un objetivo, luego tenés un bloque válido, ¿ok?, y este es un proceso igualitario meritocrático, y es un recurso externo. Así que el minado no es titular dentro de Bitcoin, es una cosa externa, tengo que tener un minero externo, tengo que tener un ASIC para básicamente hacer este proceso competitivamente. Y puedo hacerlo sólo puedo hacerlo con un pool privado, muchas ASIC juntas, o puedo hacerlo con un pool distribuido, o de hecho contribuir con alguna unidad de trabajo, etc.
Ahora, prueba de participación y prueba de trabajo son funcionalmente idénticos en estos dos lados, número dos y número tres. Así que POS hace esto, prueba de trabajo hace esto, haces y empujas bloques, lo haces de la misma manera, puedes tomar un algoritmo de prueba de participación, dejarlo caer encima del sistema Bitcoin y en su mayor parte será de esa forma, con algunas diferencias de detalles de implementación. Luego tendrás reglas de validación, reglas del libro contable, reglas de aceptación, acerca de si esos bloques se ven bien o no. Así que la manera más fácil de pensar esto conceptualmente es como un juego de poker, alguien tiene que ser el distribuidor, que baraja la mesa y distribuye las cartas. El segundo paso es la distribución de las cartas, el primer paso es escoger al distribuidor, y el paso tres es levantar la baraja, mirarla, mirar esas cartas. Lo que eso hace es, ya sabes, tenés cinco ases, tenés la carta de información, un joker, dices “bueno, espera un segundo, esta no es una mano válida”. Así que la pregunta es, “¿podés hacer una validación completa, o una validación parcial o una validación ciega, qué nivel de validación podés tener con la forma en que son hechos los bloques?”.
Así que varios algoritmos de consenso y reglas del libro contable en el espacio de criptomonedas, porque hay muchos de ellos, tienen diferentes niveles de cosas. En el caso de Bitcoin, tiende a ser un sistema completamente sin confianza, osea que cuando vos recibís ese bloque, podés comprobar la prueba de trabajo, podés comprobar el contenido del bloque, y tendrás una colección entera de la historia, sos capaz de validar, asumiendo mayoría honesta, que ese bloque es real, legítimo y no se enviará hacia atrás, así que es un muy poderoso sistema determinístico, eso es algo muy raro de tener con completa descentralización, es por eso que Bitcoin es tan genial.
Pero ese primer paso, esa colección del valor mágico, como he mencionado, es donde ocurre todo el consumo energético, el 99.9999997% de toda la energía ocurre ahí. Y básicamente lo que hace la prueba de participación es decir “bien, inventemos alguna clase de recurso sintético”. Así que las capacidades de minado, ASICs, son un recurso, esa es la manera en pensar acerca de ellas. Y para cualquier período de tiempo dado, habrá algún conjunto de ASICs, puedes unificar todo ese conjunto de ASICs, juntarlos todos, esto de aquí es el pool total de recursos. Cuando piensas acerca de un recurso sintético básicamente lo que estás haciendo es decir “ok, si tengo el 25% de las ASICs, en promedio, yo debería ser capaz de encontrar esos números mágicos el 25% de las veces”. Así que si yo tengo el 25% de este recurso sintético, en promedio, mi valor esperado debería ser que el 25% de las veces yo debería ser el distribuidor, debería ser esa persona que hace el bloque, puedo hacer el bloque, empujarlo, y por supuesto, si es aceptado se me pagará por eso.
Bien, así que la pregunta es, la distribución de este recurso sintético, ¿es justa?, y también, ¿es segura? Necesitas un modelo de seguridad contra un adversario para incluso tener una discusión significativa, que es por qué este documento es tan increíblemente importante, porque luego puedes tener una muy rigurosa conversación acerca de qué propiedades de seguridad provee la prueba de trabajo. Luego, si vas a crear un recurso sintético, y construir un diferente tipo de sistema, ¿qué propiedades de seguridad tiene ese sistema? Y escribimos ese documento, este documento Ouroboros, originalmente salió en 2017, pero fue actualizado en 2019 para reflejar toda clase de nuevas e interesantes cosas que hemos recopilado, y esto está construido con ese modelo GKL. Básicamente lo que el documento hace es hablar acerca de los desafíos de diseño de prueba de participación. Y realmente están diciendo “bien, ¿cómo hago que ese recurso sintético funcione apropiadamente, y cómo utilizo ese recurso sintético para seleccionar correctamente una colección de gente para realizar esos bloques?”. Por supuesto tenés que modelar esto, tenés que crear rigurosas pruebas de seguridad para este tipo de cosas, vas hacia abajo, miras el modelo entero, habla acerca del tiempo, sincronía, hemos visto eso antes, aquí vamos, 1978, las cosas Lamport, probablemente hayas citado el documento Lamport, no me sorprendería, sobre este documento, todo el mundo lo hace en el trabajo académico. Y habla acerca propiedades de vivacidad y todas estas cosas, crecimiento honesto de cadena, calidad de cadena existencial, el prefijo común de GKL. Y lo que hace es que con el tiempo construye un gran modelo de seguridad, como que discute que si utilizas esto, bajo los supuestos que están dentro de este documento, que básicamente tendrás seguridad equivalente a la seguridad de prueba de trabajo.
Ahora, el problema es que estamos utilizando ese término “supuesto”, es el término más peligroso en todas las ciencias de la computación, esa y funcionalidad ideal, esas son las dos. Esos supuestos básicamente dicen que este adversario maligno que tenemos aquí sólo puede ser derrotado bajo el modelo y con las suposiciones que hicimos, para derrotarlo. Sólo porque tenemos un documento revisado por pares no significa que hay seguridad garantizada en contra todo tipo de adversarios y todo tipo de condiciones. Por ejemplo, las computadoras que están hablando entre sí, hay diferentes modelos de comunicación, así que cuando enviás una señal entre las computadoras, podés hacer que todas ocurran en tiempo sincronizado, o pueden ocurrir en un tiempo parcialmente sincronizado, o pueden ser asincrónicos. Y hay una cosa genial llamada resultado de imposibilidad Fisher Lynch Patterson, que habla acerca de algunas limitaciones si tu sistema es asincrónico versus sincrónico, o parcialmente sincrónico, etc, acerca del nivel de seguridad que podés tener, y eso es sólo cómo se pasan los mensajes. Otra cosa es ¿cuántos actores bizantinos podés tener en tu sistema?, ¿es un tercio?, eso es muy común para protocolos fragmentados y sistemas asincrónicos, ¿es un cuarto?, ¿es 50%? Y resulta que de hecho Bitcoin tiene un montón de realmente asombrosas propiedades con prueba de trabajo, por ejemplo, tenés la habilidad de recuperarte de ataques. Digamos que hay un ataque en el sistema, con el tiempo, la minoría honesta, si se quedan alrededor y continúan minando, y el atacante se detiene, la cadena de minoría puede realizar la cadena de la mayoría y nos podemos recuperar. Así que hay un mecanismo de recuperación de desastre que está en prueba de trabajo, la prueba de trabajo mayormente es parcialmente sincrónico o asincrónico dependiendo a quién le preguntes en el espacio, como a Andrew Miller. Eso significa que puede operar en condiciones de red muy incómodas. No sabes con anticipación quién va a encontrar ese valor mágico, ese no es necesariamente el caso en un montón de algoritmos de consenso, en muchos algoritmos de consenso sabes quién será la persona para realizar ese bloque, es como saber quién será el próximo distribuidor, así que puedes coaccionar o atacar a ese distribuidor, y Bitcoin no es predecible. Además de eso, Bitcoin de hecho genera una muy razonable fuente de aleatoriedad, no es perfecto, es sujeto de ataques de molienda, pero obtienes un suministro razonable de eso. Así que tenés un montón de asombrosas propiedades de seguridad, además de un 50%, osea la mitad, de resistencia bizantina. Así que para replicar eso para prueba de participación no es trivial, tenés que aparecer con nuevas maneras creativas para obtener fuentes de aleatoriedad, ser capaz de hacer la selección de gente justa, tenés que ser capaz de recuperarte de ataques del 51%, tenés que ser capaz de tener un reloj apropiado para el sistema. Usualmente lo que la gente hace es heredar ese reloj de un sistema como NTP, para sincronizar las cosas, pero de hecho hay maneras para ir alrededor de eso y crear un reloj dentro del sistema, creamos un documento llamado Chronos, específicamente para eso. Así que mucha gente pregunta, ¿por qué tenemos tantos documentos Ouroboros?, y la razón es que un montón de esas propiedades no fueron solucionadas en este documento de aquí, el documento Ouroboros original. Si vas a eprint, que es un eprint IACR, que es como el archivo de criptografía para la mayoría del trabajo académico en el dominio de la criptografía. Y vas adelante y escribes Aggelos, es nuestro jefe científico, verás un montón de los documentos que escribió recientemente, es un académico extremadamente verboso, pero ingresemos la palabra clave Ouroboros, ahí vamos, y ves cuántos diferentes documentos Ouroboros hay, Ouroboros Praos, modelo de tiempo universalmente componible, tenemos Ouroboros Chronos, que es el desacoplamiento del reloj, Ouroboros Crypsinous es cómo preservar privacidad, Ouroboros BFT es un protocolo montado para ayudar con cadenas laterales y protocolos federados, Génesis te permite arrancar desde génesis, esa es otra gran propiedad de seguridad de sistemas de estilo prueba de trabajo, nunca tenés que tener un punto de chequeo, simplemente podés rehacer la prueba de trabajo y comprobarlo desde la cadena que se te da y sos capaz de tener selección apropiada de cadena. Praos pone seguridad adaptativa y se mueve a un modelo semi sincrónico. Y de hecho no es todo porque hay otros documentos, como por ejemplo Ledger Redux, ese es uno, habla de recuperarse de ataques del 51%, o consenso Redux, perdón, y también finalidad rápida y cosas como esa, ese trabajo habla de propiedades autocurativas de prueba de trabajo y prueba de participación, etc.
Hay un montón en esto, es una cosa muy muy complicada, pero sabes, creo que la manera más fácil de pensar acerca de esto, en general, es como un motor. Cuando tenés un motor, el motor tiene este concepto de rendimiento, tiene este concepto latencia, ¿cuánto demora en entregar el poder, cuánto poder podés entregar?, una especie de noción de capacidad. La prueba de trabajo es un tipo de motor, es la cosa que corre la blockchain Bitcoin y otras blockchains como Ethereum. Básicamente dice “bien, podés obtener una cierta cantidad de trabajo realizado, con cada bloque, durante una cierta cantidad de tiempo”, así que la distancia entre estos bloques pueden ser diez minutos, pueden ser diez segundos, ¿ok?, así que puede ser algún valor tiempo T, es tu consideración de latencia. Y capacidad es ¿cuánto puedo poner dentro de esos bloques?