🇪🇸 Los stake pools Cardano afectan la experiencia de usuario dApp | SG 29 Ago 2021

:es: Transcripción al español de “Cardano stake pools affect dApp user experience”

Publicado en el canal de Youtube de Sebastien Guillemot el 29 de Agosto de 2021

Enlace a la versión doblada al español


Hola a todos, mi nombre es Sebastien, soy CTO y cofundador de DC Spark, una compañía de construcción de ecosistema cripto que también está involucrada en el proyecto Cardano. Hoy más temprano estaba hablando en un show y un espacio de twitter llamado Epochs End, estaba hablando de finalidad de transacción y garantía de transacción en la blockchain Cardano, estaba tratando de explicar exactamente qué significa esto, cómo afecta las dApps en Cardano, y cómo los operadores de stake pools juegan un rol en la finalidad de la blockchain Cardano. No tuve tiempo de hablar al respecto pero de hecho este es un problema conocido, afecta a Cardano, afecta a Bitcoin, Ethereum, afecta a todo proyecto que utiliza el consenso nakamoto. Así que quería hablar de soluciones a este problema, que es un problema muy bien conocido, la gente tiene soluciones, en DC Spark propusimos una manera para abordar este problema, como parte del fondo 6. IOHK tiene una manera diferente de abordar este problema, lo llaman Hydra, así que si escuchaste de Hydra, esta es una manera de abordar este problema.

En este video como que voy a describir qué es la garantía de transacción, qué es la finalidad, voy a hablar de cómo los stake pools afectan esto, y las posibles soluciones que incluso aunque no estés muy familiarizado con este tema, con suerte puedas entender un poquito más para el final de este video. Para comenzar voy a darte un ejemplo muy simple de qué puede ocurrir, ese es como un caso extremo, pero creo que te ayudará mucho a entender mentalmente cómo funciona esto. Imaginá que tenés la blockchain Cardano, la blockchain actual, todo el mundo que está ejecutando un stake pool ahora mismo, tiene una versión de la blockchain Cardano en su computadora, en su historial de transacciones, llamemos a esto prefijo común, es una pieza común de blockchain que todo el mundo tiene. Imaginá que sos un stake pool que decide que ya no va a aceptar bloques de nadie más, básicamente cambian el código en su máquina y dice “si un bloque es hecho por alguien más, simplemente ignóralo, no lo añadas a la blockchain, simplemente ignoralo, sólo añade bloques hechos por mí”. Básicamente tendrán una versión de Cardano que tiene este prefijo común, la mismo historia que todo el mundo tiene, luego se bifurcarán de eso y sólo tendrán bloques hechos por ellos, como parte de su historial de transacción. Obviamente todo el resto no seguirá esta regla, así que habrá una diferente versión de la blockchain Cardano, donde todo el resto está participando. Estará la blockchain Cardano con sólo una persona haciendo bloques ocasionalmente, y luego todo el resto en una cadena diferente.

Ahora, la pregunta es, ¿si le damos estas dos blockchains a alguien, cómo saben cuál es la blockchain real?, ambas tienen bloques dentro de ellas, ¿cómo sabés cuál es la versión verdadera de la blockchain? Ahora, debido a que es un protocolo descentralizado, te dí una especie de ejemplo simple, pero esto puede ocurrir de maneras mucho más complejas, podrías tener dos personas creando una bifurcación, múltiples bifurcaciones ocurriendo al mismo tiempo, así que cuando sea que estés sincronizando un nodo Cardano, imaginá que estás descargando Daedalus por primera vez, estás sincronizando un nodo completo Cardano, ¿cómo sabe tu computadora qué versión que está viendo de la blockchain Cardano es la real?, vos querés ir a la cadena en que todo el mundo está participando, no querés ir a la pequeña bifurcación. La manera en que hacen esto de hecho es con Ouroboros Génesis, si leiste el documento Ouroboros Génesis que fue publicado hace unos pocos años atrás por IOHK, describe exactamente cómo solucionó este problema, en las redes de prueba de participación Cardano. Es por eso que si alguna vez escuchaste el término de que Ouroboros arranca desde génesis, como característica principal, significa que podés comenzar de cero, con una instalación Daedalus limpia, y tu computadora tiene un algoritmo para saber cuál es la verdadera versión de la blockchain y descartar todas las demás.

En la manera en que hacen esto es con algunas estadísticas y análisis de la blockchain, ¿qué versión de la blockchain tiene más bloques, más actores?, es muy complejo, no es una conversación en la que entraremos en este video. Pero, lo importante de lo que quiero hablar es que debido a que pueden haber múltiples versiones de la blockchain Cardano, significa que tu computadora tiene que resolver cuál es la versión verdadera, no hay como una versión verdadera de Cardano hasta que tu computadora puede mirar todas las diferentes opciones ahí fuera, y puede decir “ok, esta es la verdadera”.

En nuestro ejemplo estábamos hablando de que está esa bifurcación ocurriendo con muchos bloques, tenemos muchos bloques en la versión real de Cardano y muchos bloques en la versión que está ejecutada por una persona. Este es un ejemplo fácil para decirte, descrito muy verbalmente, claramente todo el mundo está contribuyendo a esta, esta es la versión real de Cardano, pero no es siempre tan claro, especialmente al principio. Imaginá que ves dos versiones de Cardano, una que tiene este bloque hecho por esta persona, y la otra tiene dos bloques hechos por diferentes personas. No sabés si estadísticamente por casualidad esta tuvo dos bloques y esta tiene un bloque y todo el mundo de hecho está construyendo encima de esta, no sabés si el hecho de que tenga dos bloques significa que todo el mundo construye encima de esta. Desde una perspectiva de billetera y dApp todavía no sabés con un cien por ciento de certeza cuál es la versión verdadera de la blockchain Cardano, tendrás que dar algo de tiempo para ver cuál crece más grande, cuál tiene más gente contribuyendo a ella, así que no podés saber instantáneamente cuál es la versión real de Cardano.

Ahora, hay sistemas que permiten decirte desde el principio cuál es la versión verdadera de la historia de la blockchain, pero esto no es posible en sistemas descentralizados. Así que si alguna vez ves a alguien decir “nuestra blockchain tiene finalidad instantánea”, significa que no es un sistema descentralizado, tienen una manera de decir rápidamente cuál es la versión verdadera, cuál es la versión falsa de algo. La finalidad instantánea no está disponible en Cardano, no está disponible en Bitcoin, no está disponible en Ethereum, la razón por la que no pueden obtener finalidad instantánea, saber de un principio cuál es la versión verdadera es que, como describí, para saber cuál es la versión verdadera tenés que dar algo de tiempo y ver cuál elige la gente como versión verdadera de la historia. Así que si alguna vez utilizaste la billetera Daedalus, Yoroi o cualquier clase de billetera en cripto, cuando realizás una transacción, después de ser enviada usualmente ves un contador, bloques desde que ocurrió esta transacción, o algunas billeteras las muestran como nivel de garantía, digamos que hay una poca probabilidad que esta transacción sea revertida, altas probabilidades de que sea revertida, cada billetera tiene una manera de mostrar esto, algunas billeteras lo ignoran completamente, pero muchas billeteras tienen una manera de mostrar esto. Por ejemplo en Bitcoin la gente usualmente recomienda que esperes seis bloques para obtener una buena idea de que esta transacción probablemente es final y no será revertida. Debido a que no tenemos finalidad instantánea, tenemos que decirle al usuario “hey, tu transacción está en la blockchain ahora, pero podrías tener tu transacción en la cadena equivocada, podría ser revertida, volver atrás, ir a la nueva versión de esta blockchain, que quizás no tenga tu transacción”. Sé que esto es súper complicado, con suerte con mi ejemplo ustedes muchachos hayan obtenido un entendimiento intuitivo de por qué no podemos tener finalidad en blockchains descentralizadas, y espero que ahora con mi explicación hayan obtenido una idea que la garantía de transacción es una cosa estadística, tenés alguna probabilidad de que tu transacción sea aceptada en la cadena principal, pero no es más que una probabilidad. Los seis bloques que se utilizan heurísticamente para Bitcoin, la razón es por que se traduce a un cierto porcentaje de garantía, olvidé el número exacto, pero digamos que es 99 por ciento de garantía. Así que si tu transacción ha sido incluida por seis bloques, entonces obtenés una garantía del 99 por ciento de que tu transacción de hecho será incluida.

Si estás inclinado matemáticamente, podrías preguntarte, ¿cómo obtienen una garantía del 99%?, esta es una red descentralizada, ¿cómo saben que hay una garantía del 99% de que la transacción será incluída? Esto es debido a una variable de la que no hablé. Si querés computar la garantía, el porcentaje de probabilidad de que una transacción se mantendrá y será parte de la versión real de la blockchain, no sólo tenés que utilizar el número de bloques como argumento, pero también tenés que incluir el porcentaje de bloques hechos por actores adversarios, actores adversarios significan personas que no están siguiendo el estado real de la red, están tratando de atacar a la red. El problema es que no podés saber qué porcentaje de la blockchain es adversaria. En el caso de Bitcoin podría ser que al diez por ciento de los mineros le encantaría atacar la red si se les presenta la oportunidad. También podría ser que sólo el 5 por ciento o el cero por ciento de la gente querría atacar. No sabés cuánta gente quiere atacar la red, esto es problemático porque a veces el número de gente que quiere atacar la red es más del 50 por ciento, eso es llamado ataque del 51%, significa que más del 50% de la gente de hecho se están comportando de manera adversaria, están intentando atacar a la red. Si tenés más del 50% de la red intentando atacar la blockchain no tenés garantía de transacción, porque sin importar cuán larga se vuelva la cadena, el adversario puede hacer más bloques que vos y anular la historia, y esta se convertiría en la versión real del historial de transacciones. Es por esto que los ataques del 51% son peligrosos, porque si alguien posee el 51% de la red, básicamente puede deshacer la historia, crear una nueva versión de la historia con diferentes transacciones. Y la gente utiliza esto para atacar exchanges, básicamente, por ejemplo, envían Bitcoin a un exchange, venden el Bitcoin al exchange, luego retiran el dinero. Una vez que obtienen su dinero nuevamente, borran la historia de la blockchain Bitcoin y crean una nueva versión de la blockchain Bitcoin con más bloques en ella, así que esta se convierte en la versión real, y todo el mundo tiene que moverse a esta versión real. Esta versión real no incluye la transacción al exchange, así que básicamente no sólo obtienen el dinero por vender Bitcoin al exchange, deshicieron la historia, crearon una nueva versión de la historia donde nunca enviaron el Bitcoin al exchange, así que el exchange pierde todo ese BTC. Es por eso que ves los ataques del 51% siempre atacando a los exchanges, porque este es el mejor objetivo para sacar ventaja de este tipo de ataques. Los ataques del 51% son muy comunes en blockchains de prueba de trabajo, por ejemplo ETC ha recibido ataques del 51% muchas veces durante el curso de su historia, muchas de las otras blockchains de prueba de trabajo también recibieron ataques del 51% durante el curso de historia, este es un problema muy real.

Uno de los beneficios del ecosistema de prueba de participación es que los ataques del 51% son mucho más difíciles, porque signifique que tenés que tener el 51% de las monedas de la red. En Cardano, por ejemplo, en la prueba de participación, el número de bloques que haces están atados a la cantidad de Ada que posees, así que a menos que poseas el 51% del Ada participado en la blockchain, no podés realmente llevar a cabo este tipo de ataque. Sin embargo, como mencioné, no necesitás el 51% de la red, incluso con el 5, 10 % de la red ya estás comenzando a afectar la garantía de transacciones. Si podemos asumir que el cero por ciento de la gente está de acuerdo en atacar a la blockchain, nadie quiere realizar este tipo de ataque, la garantía de transacción en Cardano es bastante rápida. Pero cuanto más gente quiera sacar ventaja de este hecho matemático, en un sentido, buscás oportunidades para atacar el protocolo, cuánto más tardes en obtener garantía de que una transacción será incluída y siempre incluida dentro de la blockchain. No te daré números exactos ahora, pero el punto es que si mirás a los pools ahora mismo en Cardano, por ejemplo Binance posee como el 10 por ciento de todo el Ada en participación en pools que son ejecutados por su exchange. Si estás escribiendo una dApp en Cardano, al menos tendrás que asumir que el 10% de la participación podría ser adversaria, el 10% de los bloques podrían ser adversarios, porque Binance, en algún punto podría decidir atacar la blockchain Cardano. Estoy seguro que Binance es una compañía registrada legalmente, no tienen interés en hacer esto, pero es algo que tenés que tener en consideración. Afortunadamente el 10% no afecta mucho la finalidad, no es una situación desastrosa, no es que hará a las dApps inutilizables en Cardano, pero cuando más bajo el número mejor. No podemos saber quién ejecuta qué pools, no podemos saber cuán descentralizada es la blockchain Cardano, por la misma razón que no podemos saber cuánto de la blockchain es adversaria, podés hacer suposiciones, podés ver cuánta gente ejecuta cuántos pools, alguien que ejecuta 10 pools tiene una mejor oportunidad de intentar atacar a la red, quizás vos pensas que son adversarios, pero quizás son honestos, es una discusión compleja y matizada. Pero creo que todo el mundo está en la misma página que para mejorar este problema, para hacerlo tan bueno como sea posible, lo mejor que podés hacer es esparcir Ada entre más gente sea posible. Así que cuanto más gente es incluída en la creación de bloques, más difícil es corromper un cierto conjunto de individuos para atacar la red.

Con eso, si mirás a algunos de los otros pooles, como el pool uno por ciento, que posee relativamente grandes cantidades de Ada, mientras estás escribiendo tu dApp, tenés que pensar y decir “imagina que el pool uno por ciento decide atacar mí dApp, ¿cómo protejo a mis usuarios y la interfaz de usuario de mi sitio web, decir a los usuarios que las transacciones sólo son finalizadas luego de una cierta cantidad de tiempo haya transcurrido, quizás cinco minutos. La razón por la que tenés que hacer esto es por que el uno por ciento posee tantos stake pools, y esos stake pools se esparcen a más poseedores de participación, operadores, tenés más confianza que podés salir con una baja garantía de transacción y decir a los usuarios que sus transacciones han sido aprobadas más tarde que temprano. Con suerte esto les haya dado un buen entendimiento de finalidad de transacción, garantía de transacción, y cómo los stake pools afectan la garantía de transacción en la blockchain Cardano.

Ahora hablemos de soluciones a este problema, como mencioné, este problema afecta a Bitcoin, a Ethereum, a Cardano, y ¿cómo podemos solucionar este problema más allá de tratar de obtener operadores de stake pools honestos? Hay como dos maneras de hacerlo, una de ellas es mejores herramientas para dApps, y de hecho en DC Spark estamos trabajando en un proyecto llamado multiverso. Básicamente este proyecto intenta crear un programa que las dApps pueden ejecutar, básicamente permite a la dApp mirar a cada una de las versiones de la blockchain Cardano al mismo tiempo. Como mencioné antes, pueden haber dos versiones de la blockchain Cardano como prefijo común, en una versión todo el mundo construyen encima, la otra versión sólo tiene una persona. Podría ser que tu transacción, imaginá que estás enviando Ada a una dApp, podría ser que la transacción sea incluída en la versión de la blockchain que sólo tiene una persona y la versión de la blockchain donde está todo el mundo. Si tu transacción está preestablecida en ambas versiones de la historia, no importa qué terminará siendo la versión real de la blockchain, tu transacción está incluida sin importar esto, ¿ok? El multiverso básicamente es un programa que permitirá a las dApps no sólo sincronizar una versión de la blockchain Cardano, pero permitirles sincronizar múltiples versiones de la blockchain Cardano al mismo tiempo, serán capaces de mirar transacciones que hace la gente utilizando su dApp, y ver si la transacción ocurre en cada bifurcación de la blockchain que existe actualmente. Si es así, entonces pueden decirles a los usuarios “ok, no tenés que esperar más, tu transacción estará incluída con garantía bastante elevada”. Si pensás que es una idea interesante, si pensás que las dApps se beneficiarán de esto, definitivamente chequea el fondo 6 de Catalyst, mirá la propuesta DC Spark llamada multiverso, creo que se llama Multiverse dApp Rollback Handler, creo que es el nombre de la propuesta, dejaré enlace a la propuesta dentro de la descripción de Youtube, también enviaré el enlace por Twitter. Esto definitivamente ayudará a las dApps a abordar este problema.

Otra manera en la que pueden abordar este problema es ya sea creando segundas capas o canales de estado que tienen diferentes propiedades para finalidad. Podrías haber escuchado hablar de Hydra, que es un proyecto de IOHK, para básicamente ser capaces de crear un canal de estado, hacer transacciones realmente rápido y establecer el canal de estado nuevamente en la red principal Cardano. Uno de los beneficios de Hydra, uno de los beneficios de hacer estos canales de estado, es que te da una finalidad mucho más elevada. Incluso también si mirás soluciones de segunda capa en Ethereum, una de las razones por la cuál la gente está haciendo segundas capas en Ethereum no es sólo por menores costos de gas que podrías obtener de esta especie de solución de segunda capa, pero uno de los principales atractivos para la comunidad es que con la solución de segunda capa obtienes finalidad más rápida. Hydra es de la misma manera, obtenés finalidad más rápida a través de Hydra, obviamente funciona totalmente diferente respecto a lo que está ocurriendo en Ethereum, investigación totalmente nueva, trabaja con Plutus, es una cosa totalmente diferente. Pero el objetivo final es muy similar necesitamos hacer cadenas laterales y soluciones de segunda capa que tengan costos de gas más bajos y finalidad más elevada, para mitigar este problema, si querés finalidad rápida para la aplicación que sea que estés haciendo, por ejemplo si estás ejecutando un dEx, y necesitás que los usuarios tan rápido como sea posible sepan que la transacción está finalizada, y pueden seguir adelante y hacer el próximo cambio, y el próximo y el próximo, los canales de estado a menudo proporcionan una buena manera de hacer esto y Hydra como que aborda este problema. Obviamente Hydra tiene su propio conjunto de compensaciones, no voy a ir a ello en este video porque es un protocolo muy complicado, puedo hacer un video separado en el futuro, pero creo que IOHK hablará de Hydra de manera bastante extensa durante la cumbre Cardano más a fin de mes, si querés aprender más acerca de Hydra y cómo tu dApp puede utilizar Hydra para proporcionar una experiencia de usuario más rápida, mirá la cumbre Cardano.

Así que esa es la discusión, fuimos a través del problema, una descripción del problema, cómo los pools en Cardano afectan la finalidad y la garantía de transacción. Luego fuimos a través de dos soluciones a este problema, en que DC Spark está trabajando, IOHK está trabajando. Si tenés alguna pregunta acerca de esto podés escribirme en cualquier momento en Twitter, Telegram, de hecho ahora tenemos un discord DC Spark, podés ir al Discord DC Spark, enviarme un mensaje, o a cualquiera del equipo DC Spark, siempre estoy feliz de tener estas discusiones técnicas, como para explicar blockchain y los matices de problemas técnicos que ocurren en redes descentralizadas, muchas gracias.

1 Like