🇪🇸 Hydra de Cardano vs Lightning Network: Qué enfoque de escalabilidad es mejor | Lex 18 Jun 2021

:es: Transcripción al español de “Cardano’s Hydra vs Lightning Network: What scalability approach is best | Charles Hoskinson”

Publicado en el canal de Youtube Lex Clips el 18 de Junio de 2021

Enlace a la versión doblada al español


Lex: Hay un montón de diferentes aspectos técnicos que quiero preguntarte del lado Cardano, quizás primero del lado de escalabilidad, ¿qué es Hydra, cómo se compara Hydra con otras diferentes ideas para escalabilidad como Roll Up, principales compensaciones respecto a seguridad, UX, y cualquier otra cosa de la que quieras hablar?

Charles: Tengo que tener un poco más de energía Lex, vamos dale!

Lex: Sabés qué necesito, necesito esa máquina de coca que mencionaste, que convierte agua en cocaína.

Charles: Del director Bullock, dejaremos esto ahí, ¿cierto? Canales de estado isomórficos, ese es un tema genial, hay una ensalada de palabras de términos criptográficos. Ya sea Lighting, Hydra, Roll Ups, cualquiera de estas cosas. Realmente lo que estás tratando de hacer es decir, bien, si lo hago en la capa uno es lento y caro, lo que voy a hacer es agrupar algo, de alguna manera, de alguna forma, y luego hacerlo en un sistema distinto, donde es rápido y barato. Lo que estoy haciendo con ello es perder algo de las garantías de seguridad de la capa base, y admitiendo y ligero grado de centralización, pero luego obtengo asentamiento súper rápido, costo de transacciones súper bajo, y potencialmente podría ser capaz de obtener computación distribuida, significando que en vez tener los contratos inteligentes ejecutándose en un sistema replicado, pueden correr en un único nodo, como un stake pool, y sus cosas son diferentes a las cosas de los otros muchachos, así que vas de un sistema de capacidad de lo que sea que fuera, a un sistema N para la totalidad de todos los stake pools, así que básicamente Hydra es la próxima generación de eso. Cuando tenés la habilidad de entretenerte con el modelo de contabilidad, y la solución de segunda capa está co diseñada con la solución de capa uno. Así que es como lo que hubiera sido Lighting, si Lighting hubiera sido desarrollado cuando salió Bitcoin. Se hicieron provisiones especiales en Bitcoin, específicamente para acomodar lighting, y hubiera sido muy fácil para vos moverte dentro y fuera del sistema y tener propiedades de seguridad preservadas, como la disponibilidad por ejemplo, o digamos resistencia al fraude, no podés robar el dinero o este tipo de cosas.

Bueno las cosas se vuelven muy complejas, y es por eso que Hydra es novedoso sobre Lighting. Es cuando querés moverte más allá de pagos a gestión de estado, ¿ok? Así que pagos es “quiero mover entre Alice y Bob lo más rápido posible, al menor costo posible”. Por ejemplo, tengo una aplicación de micro propina, como Change Tip en Twitter o un video, estoy viendo un video de Youtube, como quizás éste video en el futuro, y a la gente realmente le gustó, hacen clic en tip y recibís cinco centavos, o algo así. Así que ese es un ejemplo de una perfecta aplicación de pago, y eso es genial. ¿Pero qué pasa cuando de hecho tenés un rico contrato inteligente, como un dEx, o querés hacer un video juego, algo así, querés ejecutar eso fuera de cadena, pero hay una reconciliación en cadena que ocurre. Así que un canal de estado básicamente te permite hacer eso, pero es mucho más complicado y hay mucho más en lo que pensar. Hydra básicamente es un diseño de una colección de ideas acerca de cómo hacer eso. El documento actual es para una única cabeza, la próxima cosa que haces es composición, así que vas a múltiples cabezas y hay un protocolo de enrutamiento entre ellos. Y eventualmente crea estos protocolos de cola para cuando la cosa se vuelve asincrónica. Así que en vez de estar siempre en línea, y siempre estar disponible, ¿qué pasa si mueren por un tiempo y luego vuelven? Y podés crear un montón de garantías de que tus fondos no se perderán, o bloqueados para siempre, o cosas como esas, hay un modo de recupero de falla para este tipo de cosas. Y básicamente es aprovechar lo que ya logró Lighting con Bitcoin, pero luego sacar ventaja del hecho de que tenemos un modelo de contabilidad más expresivo, y un modelo de programación más expresivo, así que físicamente podés hacer más, podés poner más cripto dentro de esta cosa.

Contrastado con Roll Ups, eso es decir que vas a tomar algo, un grupo de transacciones juntas y vas a generar una prueba, y lo que podés hacer es que cuando sea que veas alguna parte de esa historia, podés comprobarlo a través de esa prueba que es Roll Up.

El concepto cercano son los snarks recursivos, verás un montón, hay cosas como el protocolo Mina, u otras cosas. Y básicamente la idea es que cuando sea que veas algo siempre podes generar dos pruebas, una prueba existencial, osea que las monedas existen y la no existencia de un doble gasto, así que siempre podés comprobar estas dos propiedades, e idealmente la prueba es verificable en tiempo logarítmico. Así que podés tener gigantescas cantidades de datos, pero es muy pequeño, la prueba real es muy concisa, ¿ok?, así que son distintos botes para distintos flotadores. La ventaja de una red de segunda capa, donde están los canales reales, y hay interacción en sus proveedores de servicios, es que los canales eventualmente pueden escalar a una colección de cosas que pueden hacer. Y eventualmente pueden convertirse en redes de interoperabilidad entre criptomonedas. Así que en algún punto podemos modificar las especificaciones y hacerlo de alguna forma interoperable con Hydra. Luego lo que podría ocurrir es que lo utilices como puente para hacer tráfico cros cadena, y enviar transacciones entre los sistemas. No pensás mucho acerca de ello cuando haces Roll Ups, eso es más acerca de optimizar lo que tenés dentro del sistema.

Lex: ¿Podés elaborar cómo es posible hacer tráfico cros cadena?

Charles: Bueno, ya tenés los intermediarios, tenes los operadores de canal, ya tenés el protocolo Lighting, construyeron un dEx que corre dentro de ese sistema, pueden intercambiar activos, o podés envolver activos.

Lex: ¿Cómo bajo costo, supongo que intercambias?

Charles: Sí, la misa cosa, si agrupas cosas en una te permitirá agrupar otras. Si Lighting funciona en Bitcoin y Hydra funciona en Cardano, eventualmente podés puentear estas dos juntas y crear una manera de mover hacia atrás y adelante. Y la misma cosa que hace transacciones baratas dentro y fuera de esa red creará activos envueltos baratos, al menos del lado de Bitcoin a Cardano, no podés crear activos en Bitcoin, otra falencia de Bitcoin que nunca solucionaron.

Lex: ¿Cuáles son tus pensamientos sobre tecnologías de segunda capa en general, hay cosas sobre las cuales estás emocionado, hablamos bastante de Lightning Network, Hydra, estas ideas, crees que habrá alguien que ganará o será algo así como una cosa dinámica que simplemente mantiene construyendo diferentes ideas y no interactuan entre sí?

Charles: Vuelvo a la biología, el concepto de diferenciación celular, tenés que construir tejido especializado para hacer cosas. El punto de la segunda capa es extender la red, es agregar una pierna, un brazo, es agregar un cerebro, un corazón, ojos, dándote sentidos adicionales, tenés ojos ahora. Así que cuando agregas estos protocolos de segunda capa, Atala Prism es un ejemplo perfecto de eso. No tenemos identidad en la capa base en Cardano, realmente es un mal negocio hacer eso, porque vendrá China, USA y te dirán cómo hacer eso. Lo que haces es construir un protocolo de segunda capa que es blockchain agnóstico, y el usuario puede decidir cuándo y dónde necesitan identidad, y traer esa identidad al sistema. Y si lo diseñaste correctamente, cuando lo traés es muy fácil, fluido, y de repente mejora, todo simplemente se vuelve mejor, “Oh, wow, ahora puedo utilizar todas estas cosas reguladas, van de gris a verde en la tienda de aplicaciones, eso es tan genial”. O “ahora puedo enviar direcciones leíbles por humanos, porque si vos tenés una identidad, yo tengo una identidad, podemos poner un álias con espacio de nombre, y ahora le mando a Lex, en vez de a una horrible estructura de dirección Bech32. Eso es realmente lo que tenés que hacer con la segunda capa, es decir que cada protocolo de segunda capa está destinado a hacer algo. Ya sea darme pagos, o contratos inteligentes de menor costo, interoperabilidad, o identidad, y luego es un mercado, deberías tener agnosticismo con tus soluciones de segunda capa. Así que podés mezclar, emparejar, elegir cualquiera sea la colección de servicios que necesitás. De hecho así es como funciona estos días con microservicios y estas otras cosas, software en la nube, cada firma es una agregación de docenas de proveedores y básicamente la composición de ellos es tu pila de software.