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
Doblaje al español* de “Connecting Blockchain Networks in Practice”
Publicado en el canal de Youtube Cardano Foundation el 12 de Abril de 2026
CF: Sí, iba a preguntar cuáles son los casos de uso más adoptados para mensajería, pero parece que aún no han despegado.
T: Sí, creo que nos acercamos a una parte un poco más deprimente de la conversación, pero tienes razón: los protocolos de mensajería son más flexibles en teoría, pero la gente no ha encontrado aplicaciones amplias más allá de puentes de tokens y swaps cross cadena. Ese sería el principal valor añadido. Los swaps cross cadena se han vuelto un poco más comunes desde la llegada de la mensajería, pero quizá esto refleja una cuestión más profunda: ¿para qué sirve blockchain más allá de los activos?
Teníamos muchos sueños al principio, pero si miras lo que la gente realmente hace hoy en cadena, todo está centrado en activos. Así que no sorprende que en la capa de interoperabilidad también nos cueste pensar más allá de eso.
CF:¿Y los protocolos de mensajería para swaps de tokens usan mensajería o mecanismos tradicionales como bloquear, mintear, quemar, desbloquear?
T: Para los swaps cross cadena
CF: Si, Layer Zero, CCIP, lo que sea, Wanchain, aquellos que han desarrollado mensajería para el caso más básico, como mover ADA a Ethereum, ¿qué utilizan?
T: Definitivamente estás usando mensajería para los swaps cross cadena porque hay cierto tipo de datos “arbitrarios” u otros datos que no son puramente el activo y que necesitas conocer cuando haces un swap cross cadena. Con activos es simple: bloqueas y minteas la misma cantidad, así que no necesitas pasar mucha lógica adicional de la primera a la segunda cadena, es bastante directo.
Pero en un swap cross cadena hay más matices, por ejemplo, necesitas saber algo tan básico, están todos estos Dexes, como que el usuario no tiene una tolerancia infinita al slippage, así que habrá un límite sobre qué tipo de tasa está dispuesto a aceptar en ese intercambio. Necesitas saber el activo al que el usuario quiere cambiar; el usuario sólo está enviando, digamos, si quiere pasar de USDT a BTC —aunque no es el mejor ejemplo—, digamos de USDT a ETH.
El usuario envía su USDT al contrato inteligente, pero esos contratos necesitan saber en la cadena de destino que lo que el usuario quiere hacer es tomar ese USDT y cambiarlo a ETH, que es un activo diferente, además de conocer varias cosas como la dirección de destino, la tolerancia al slippage y otros aspectos operativos.
CF: ¿USDT en qué cadena? ¿No en Ethereum?
T: Podrías hacer algo como USDT en Avalanche a ETH en Ethereum, por ejemplo.
CF: ETH en Solana, más interesante,.
T: O USDT en Ethereum a ADA. Tienes toda esta información adicional que necesitas pasar a través de toda la lógica del puente, porque supongamos que el swap ocurre en Cardano, entonces necesita saber que el usuario ha bloqueado o ha cedido la custodia de su USDT en Ethereum y luego necesitas enviar una variedad de instrucciones en un swap cross cadena. No simplemente vas a acuñar la misma cantidad de USDT y listo, el flujo continúa.
Necesitas saber cuál es la dirección receptora —y en este caso es importante porque el formato de dirección es diferente—, no puedes simplemente copiar la dirección de Ethereum. Necesitas conocer la tolerancia al slippage, necesitas saber que el usuario comenzó con USDT y que quiere terminar con ADA, y probablemente también especificar en qué DEX de Cardano el protocolo está dispuesto a ejecutar el swap.
Así que tienes toda esta información adicional, y todo esto se envía mediante un protocolo de mensajería. Luego, en ciertos casos —en realidad en casi todos— también necesitas usar un puente de activos. Por ejemplo, si estás usando un Wan USDT envuelto en Cardano, el usuario, como parte de este flujo, bloquea su USDT en el contrato de swap cross cadena, y luego ese contrato necesita utilizar el puente de Wanchain para mintear la cantidad equivalente de USDT envuelto en Cardano. Después, el contrato en Cardano necesita recibir tanto el USDT envuelto como las instrucciones e información suplementaria provenientes del protocolo de mensajería para poder ejecutar un swap en algo como Minswap, convertir de USDT a ADA respetando las restricciones que el usuario especificó en términos de slippage y demás, y luego enviar el resultado a su dirección receptora en Cardano.
Si estás tratando con un caso —aunque no es el mejor ejemplo para Cardano— en el que existe USDT nativo en Cardano y el puente Wanchain o el swap cross cadena no tiene la capacidad de mintear una versión envuelta, entonces la idea es la misma: sigues necesitando un puente y un protocolo de mensajería, pero en lugar de mintear, bloqueas el USDT en la cadena de origen y lo desbloqueas en Cardano. Así que tienes las mismas diferencias en la parte del puente, pero en la mayoría de los casos con swaps cross cadena necesitas ambos tipos de puentes: puentes de activos porque estás manejando activos, y puentes de mensajería porque necesitas transferir instrucciones adicionales.
CF: Excelente explicación. Antes de entrar en cómo funciona todo esto a nivel operativo y en los supuestos de seguridad, ¿hay algún otro concepto en la evolución de la interoperabilidad?
T: En la práctica, ahí es donde estamos hoy: hay algunos desarrollos teóricos —quizás no soy el más indicado para hablar de ellos a nivel experto— pero definitivamente cosas como la tecnología ZK van a jugar un papel importante y muchos puentes están enfocados en esa dirección.
Básicamente, si volvemos al modelo simplificado inicial, todos los puentes tienen infraestructura en la cadena de origen, infraestructura en la cadena de destino y algún componente fuera de cadena, y lo que queremos es reducir la superficie de ese componente fuera de cadena. Ahí es donde entran conceptos como diseños de sin confianza o mínima confianza, se trata de hacer que esa parte fuera de cadena sea cada vez menos relevante. Tecnologías como ZK están en desarrollo, pero aún no están listas para producción; no estás usando puentes ZK reales hoy en día.
CF: En cuanto a los intents, los ves como una capa encima de UX o también pensás que son un bloque de construcción de interoperabilidad.
T: Un poco controversial, no creo que las soluciones basadas en intents sean una gran innovación para la interoperabilidad. Creo que son útiles a nivel de aplicación para mejorar la experiencia de usuario, pero no son una buena dirección para la infraestructura base de interoperabilidad. En esencia, para la gente que escucha, a muy alto nivel, el usuario no se preocupa por cómo se hacen las cosas detrás de escena, simplemente quiere declarar el resultado, y luego cómo se logra ese resultado no le importa.
Así que puedes tener todo tipo de diseños distintos para resolverlo; normalmente es como una red de actores independientes que compiten entre sí ofreciendo el servicio de la forma más barata o más rápida posible por diseño. En la práctica, termina siendo una sola persona la que lo hace porque es una carrera hacia el fondo y nadie gana dinero. Pero creo que son útiles para suavizar la experiencia, aunque como industria estaríamos en muy mala forma si eso se convierte en parte del núcleo de la pila de interoperabilidad, en mi opinión.
CF: Sí, estoy de acuerdo contigo, y quizá es un poco como un agregador de DEX; este concepto de intents sería más bien un agregador de interoperabilidad, como un router para tus operaciones o para el puenteo de activos.
T: Incluso eso creo que es un poco optimista respecto a cómo ha evolucionado, porque sería una cosa si solo agregara otras soluciones sólidas, pero en realidad casi siempre termina reduciéndose a literalmente una sola persona ejecutando un agente que resuelve todo. Seguimos atascados en tokens, ¿no? Así que si alguien intenta hacer un puente o un swap cross cadena rápidamente, sorprendentemente a menudo es literalmente una sola persona corriendo un agente en AWS que detecta la operación, hace el swap en un exchange centralizado en algún lugar y luego envía los activos al usuario.
CF: ¿Es tan malo? No sabía que fuera tan así.
T: A menudo —aunque hay casos que no usan exchanges centralizados, eso fue un poco exagerado— se trata de gente usando su propia liquidez. Siempre termina reduciéndose a eso. Así que básicamente quien sea el “solver”, como los llamamos, necesita acceso a liquidez. Para ponerlo en términos más tangibles para los oyentes: supongamos que quiero hacer puente de USDT desde Ethereum a Tron, que es una ruta popular. Si usas un puente tradicional de terceros, puede tardar bastante, digamos 15 minutos. Con una solución basada en intents, en este caso literalmente tienes un agente, algún actor que tiene USDT disponible en Tron sin usar, y cuando el usuario quiere hacer el puente, ese agente simplemente toma el USDT del usuario en Ethereum y le entrega USDT en Tron.
Obviamente eso es mucho más rápido que pasar por múltiples capas de lógica de contratos inteligentes y esperar la finalidad en distintas cadenas. Entonces el “intent solver” cobra una pequeña comisión porque asume riesgo y presta un servicio, pero para mí esto es más una innovación a nivel de aplicación, no algo del núcleo.
CF: ¿Cuáles son los principales protocolos de intents, son plataformas? La última vez que miré Near, tenían como este nicho.
T: No sé si hay alguno que haya hecho un trabajo sobresaliente. Cosas como puentes han funcionado bien desde la perspectiva de tokens en el sentido de que la experiencia de usuario es muy buena: es rápida y fluida, y son puentes que aprovechan redes basadas en intents. Creo que Across Protocol también hace cosas con puenteo basado en intents, pero en general esto se trata más de mejorar la experiencia de usuario. No necesariamente querría construir sistemas críticos del mundo apoyándome en soluciones basadas en intents; es más bien una capa de aplicación en lugar de infraestructura central.
CF: Hablemos de los supuestos de seguridad: ¿cómo funciona eso? ¿Qué deberíamos mirar cuando usamos un puente cross cadena o hacemos un swap? ¿Cuáles son las características de un puente o protocolo a las que deberíamos prestar atención? ¿Es solo el número de validadores, el tipo de multifirma, cómo funciona?
T: En realidad, todo vuelve a esas tres partes que mencioné: la infraestructura de la cadena de origen, que casi siempre son contratos inteligentes, a menos que estés en una cadena sin contratos inteligentes, pero para simplificar la conversación, El contrato inteligente en la cadena origen, el relayer fuera de cadena, que es el componente que observa la cadena de origen para confirmar que algo ocurrió en la cadena origen, queres resolver esa pregunta y la infraestructura de la cadena de destino, que también suele ser un conjunto de contratos inteligentes.
En 2026, a menos que estemos tratando con —no voy a ir tan lejos— pero digamos que en 2026, la infraestructura de la cadena de origen y la infraestructura de la cadena de destino están bastante bien establecidas, bien probadas, la mayoría de los puentes ejecutan estas funciones en un contrato inteligente. Realmente no es ahí donde vas a esperar un riesgo enorme. Siempre puedes tener casos de fraude o algunas puertas traseras secretas o algo así.
CF: Si confío en los contratos inteligentes de Ethereum y Cardano, lo que queda es la parte fuera de cadena.
T: Exactamente. Sí. Entonces, por lejos la pieza más importante es lo que está pasando fuera de cadena; incluso en cadena normalmente puedes, si eres un usuario relativamente o muy avanzado y puedes acceder a muchos de estos contratos inteligentes como código y puedes revisarlos y todo ese tipo de cosas o confiar en alguien que tenga esa capacidad. Bien. Todo eso se puede dejar de lado porque en realidad ese no es tu riesgo. Como bien dijiste, es lo que está pasando fuera de cadena y hay muchas versiones diferentes y lo que complica aún más las cosas es que esto no tiene los mismos requisitos estrictos de código abierto o la misma cultura que tienen las partes en cadena; hay mucha tecnología propietaria ocurriendo en la parte fuera de cadena y parte de eso puede ser, en un extremo del espectro, porque hay un esfuerzo fuerte y deliberado para hacer que la parte fuera de cadena sea lo más segura posible, por lo que no necesariamente buscan abrirla al público; en el otro extremo del espectro, tal vez es simplemente una construcción de muy baja calidad y no quieres revelárselo a los usuarios.
Y por eso es bastante difícil. Pero normalmente hay un número manejable de diferentes formas en que hoy en día la gente, los puentes hoy en día, están haciendo esta parte fuera de cadena. La más simple es totalmente centralizada, simplemente alguien ejecutando un bot, básicamente uno de uno y procesando transacciones. Ese es como un extremo, pero no hace falta hablar mucho de ese tipo.
De una manera más descentralizada, también hay solo un puñado de cosas que la gente hace. Tenemos multi firma. Muchos de los oyentes estarán familiarizados con lo que es eso. Entonces, podrías hacer esa parte fuera de cadena con multi firma. Básicamente, tienes múltiples actores diferentes, se conozcan entre ellos o no, lo cual impactará el perfil de riesgo del puente, cuántos hay, todos esos tipos de consideraciones, pero básicamente tienes un grupo de personas que estarán observando los eventos de la cadena de origen y luego los ven y firman una transacción y dicen sí, estamos de acuerdo, que superas cierto umbral y entonces ese contrato inteligente activará el evento en la cadena de destino, ya sea un minteado o desbloqueo. Entonces tienes multifirma, tienes MPCs. Eso es lo que de hecho Wanchain usa para nuestro relayer fuera de cadena, que no es tan diferente de un multi firma, pero ya sabes, en lo técnico es muy diferente, pero sigue siendo la misma idea. Tienes múltiples partes diferentes que en lugar de que cada una tenga su propia clave privada y firme, están generando una clave como de manera conjunta y luego superas cierto umbral.
Básicamente puedes pensarlo conceptualmente igual que un MPC o un multi firma donde suficientes personas ven lo que sucede en la cadena de origen y luego firman una transacción juntas para activarlo en la cadena de destino. Con estos dos necesitas pensar en cuántos participantes hay, cómo son seleccionados los participantes. Esas son realmente las dos cosas más importantes. Por supuesto, para MPC y cosas así necesitas tener confianza en que, ya sabes, las matemáticas detrás de eso y cómo se generan las claves están hechas correctamente.
Estas cosas siempre son complicadas de hablar porque nosotros como industria sabemos cómo hacer esto. Así que no es un desafío técnico imposible de resolver. Es solo que desde la perspectiva del usuario es casi imposible confirmar de forma independiente si esto ha sido implementado correctamente o si cometieron errores humanos, pero eso es otra cosa.
Algunos puentes pueden usar cosas como clientes livianos, que básicamente significa que no tienes todos los datos completos de la cadena desde el génesis, desde el historial, sino que estás trabajando con puntos de control o estados aprobados y tomando decisiones basadas en eso, y luego con muchos de las L2 estás usando como observadores optimistas donde básicamente asumes que todo está bien y luego tienes un conjunto de actores que, en lugar de mirar la cadena y confirmar que los eventos están ocurriendo y son correctos, hacen lo opuesto: asumen que todo está bien y luego si ven algún problema dicen, hey, tenemos que revisar este.
Probablemente haya otros que estoy olvidando, pero obviamente ZK también lo mencionamos, pero esos no están en producción de una manera significativa todavía. Pero esas son las diferentes formas en que puedes diseñar tu relayer fuera de cadena. No es muy útil en realidad para los usuarios minoristas que están usando puentes, solo para mover sus propios fondos personales de una cadena a otra, porque mucho de esto está ofuscado. Incluso si tuvieras el conocimiento para entender todo esto, no tienes acceso a los datos en la mayoría de los casos, así que es muy, muy difícil y normalmente lo que le digo a la gente es, ok, no vas a tener un entendimiento del 100%, no vas a poder tener 100% de confianza, pero puedes hacer pruebas de estrés simples para tener una idea básica.
Una cosa que siempre sugiero es, ok, si estás pensando en usar un puente: ok, cadena de origen, cadena de destino, contrato inteligentes, sí, ese relayer fuera de cadena, ¿es sin permiso o es con permiso? ¿Cuál es la forma más fácil de averiguarlo? Googlea o revisa su documentación e intenta ver cómo despliegas un nodo. En la mayoría de los casos, podrías sorprenderte al descubrir que no puedes. Y si vos mismo no puedes desplegar un nodo, es un sistema con permisos.
Entonces, si estás lidiando con un MPC o multifirma, ya sabes que estos son participantes preseleccionados y eso también informa tu perfil de riesgo para el puente. Puedes ver cuántos participantes hay. Esto normalmente lo publican los proyectos, suelen decir algo como ok, nuestro umbral es 17 de 19 o no normalmente tan ajustado pero como 17 de 25 o 11 de 19 o lo que sea, tres de cinco, ya sabes, normalmente publican ese tipo de información. Así que también puedes usar eso para construir tus propios modelos mentales de cuán riesgoso es esto.
Si es un multifirma de tres de cinco y es con permiso, no puedes unirte a ese multifirma, ya tienes una idea clara de qué es ese puente. Son cinco personas que definitivamente se conocen entre sí o al menos están conectadas por alguna entidad que las selecciona y les da esos derechos. Solo hace falta que tres de ellas se pongan de acuerdo para robar todos los fondos en el puente porque si ese relayer falla, pueden hacer lo que quieran porque son quienes están determinando desde la perspectiva del puente que algo ocurrió en la cadena de origen y están activando eventos basados en esa información en la cadena de destino.
CF: Solo para el oyente, MPC es computación multipartita.. No entremos en eso. Entonces, tal vez, ¿podemos poner nombres? Wanchain es MPC, ¿puede cualquiera participar en la computación? ¿Es sin permiso?
T: Wanchain es sin permiso, así que puedes ir y desplegar un nodo y unirte al conjunto; ahora mismo es como un mecanismo basado en staking, así que haces stake de activos y luego hay un ciclo de elección básicamente mensual, cada época es un mes, así es como se maneja ese. Entonces este es un conjunto MPC sin permiso.
CF: ¿Conoces otros, digamos los tres principales, los cinco principales protocolos, cómo son en términos de seguridad, MPC, multifirma o es solo un tipo con una sola clave por ejemplo? Empecemos con LayerZero, ¿sabes cómo lo hacen?
T: Entonces LayerZero es bastante interesante si hablamos de V2. Entonces LayerZero, una de sus diferencias es que básicamente te permite configurar la parte fuera de cadena según tu propio despliegue. Creo que los llaman DVNs, estoy tratando de recordar qué significa eso, pero básicamente es tu red de verificación. Puedes configurarla. Entonces, si quieres que sea una sola persona, puedes desplegar tu… ya sabes, bromeábamos sobre cómo la gente está usando protocolos de paso de mensajes como LayerZero para desplegar puentes de tokens. Entonces, si estás construyendo un puente con un protocolo de paso de mensajes y quieres que sea uno de uno, puedes usar LayerZero para hacer eso.
Teóricamente eso también significa que puedes hacerlo tan descentralizado y sin permiso como quieras, eso podría significar que tienes que construir un relayer fuera de cadena descentralizado y sin permiso desde cero y conectarlo a LayerZero. Así que es un umbral de ingeniería muy, muy alto para eso. LayerZero creo que la tecnología es muy interesante. No es una preocupación porque tampoco quiero pintarlo de mala manera porque también bromeamos sobre el uno de uno, pero uno de uno no significa no seguro; uno de uno podría ser máximamente seguro si confías en esa persona y en muchos casos, especialmente a nivel empresarial, tal vez uno de uno es un poco extremo, pero cuando maximizas seguridad, una forma de hacerlo es sacrificar descentralización, así que no necesariamente tienes que ser descentralizado y sin permiso para ser seguro.
Definitivamente no quiero que ese sea el mensaje. Así que puedes usar LayerZero para hacerlo tan centralizado o descentralizado como quieras. En la práctica creo que algo como el 99% de las transacciones que pasan por LayerZero o bien dependen de su relayer interno por defecto o son ejecutadas por el propio cliente y todos estos son básicamente centralizados, no descentralizados.
Así que en la práctica la mayoría de las transacciones de LayerZero estarán más cerca de un conjunto centralizado con permisos, ya sea usando las capas DeFi de LayerZero o como Tether usa LayerZero para cosas como USDT0, otra situación donde uno de uno —ligera exageración— pero un pequeño conjunto de entidades centralizadas se utiliza para maximizar la seguridad porque Tether no confía en nadie más que en sí mismo, lo mismo con Circle, así que se colocan en esa posición y están muy cómodos. Entonces eso es LayerZero, pero la tecnología es muy muy interesante. De hecho soy bastante fan.
CF:¿Qué hay de CCIP de Chainlink?
T: CCIP es uno curioso también.
CF: Todos son curiosos.
T: Sí, todos son curiosos. Ellos obviamente tienen una red de oráculos bastante amplia, así que aprovechan esa red para hacer esta parte fuera de cadena porque los oráculos son muy similares a los puentes. Si quieres ser muy flexible con la definición de qué es un puente, podrías decir que un oráculo es un puente. Pero no hace falta entrar en eso ahora. Entonces aprovechan la red existente de oráculos, pero tienen un conjunto de nodos con permisos que actúan como un mecanismo de seguridad.
Así que si reduces esto a su perfil de seguridad puro, es mejor tratarlo como un pequeño conjunto de nodos con permisos porque tienen esa prueba ante fallos que puede congelar despliegues y cosas así. Yendo a mí propia experiencia, creo que en los documentos originales la visión final de CCIP es acercarse un poco más a LayerZero donde muchos de estos componentes se vuelven configurables para el cliente específico, pero según entiendo hoy en día todavía básicamente usas por defecto este conjunto de nodos con permisos debajo de la red más grande de oráculos.
CF: ¿Quién más está ahí afuera? Wormhole.
T: Wormhole usa MPC también. El suyo es un MPC con permisos, así que no puedes ir y desplegar tu propio nodo. Creo que también tienen un conjunto considerable, creo que como 19, a menos que haya cambiado recientemente, pero creo que tienen 19 actores con permisos que hacen la validación para Wormhole. No sé si ibas a preguntar este después, pero CCTP creo que también vale la pena mencionarlo. Ese es de Circle.
CF: Sí, acabamos de lanzar USDCx en Cardano, ¿verdad? Sí, creo que por volumen es de hecho el protocolo de mensajería más grande si miras DeFi Llama. Sí, lo estaba mirando antes de grabar. Sí, son número uno por volumen de 24 horas por un margen grande.
T: Sí, y son muy interesantes en el sentido —y de nuevo vuelve a lo que dije antes— centralizado no es necesariamente malo si hablamos de seguridad. Este es un caso perfecto. CCTP es el protocolo de mensajería interno de Circle y sirve exclusivamente, al menos hoy, a sus activos nativos que ellos mismos emiten, USDC.
De esta manera, Circle controla cada parte de esa infraestructura de puente simplificada que mencioné. Controlan la cadena de origen, el puente, la capa de mensajería y la cadena de destino. Y por eso están muy cómodos. Y CCTP es interesante porque permiten que otros puentes o cualquiera use CCTP, y básicamente les haces ping —simplificando— de que algo ocurrió en la cadena de origen y que estás intentando hacer este puente con USDC y luego su relayer fuera de cadena confirmará que eso ocurrió, emitirán una “attestation” diciendo que sí, esto fue confirmado y luego usas esa attestation para activar el contrato inteligente en la cadena de destino, lo que permite a puentes como Wanchain que han integrado CCTP para USDC que desde la perspectiva del usuario puedas ir al puente de Wanchain y quemar y mintear USDC nativo a través de esa interfaz.
Volviendo a esas cuatro piezas que mencionamos antes, con puentes de terceros siempre hablas de bloqueo y minteado, quemado y desbloqueo o bloqueo y desbloqueo, pero como esto es todo Circle de arriba a abajo, puedes hacer cosas más interesantes como quemado y minteo, es decir, eliminar completamente de circulación en la cadena A, USDC en circulación en cadena A y mintear nuevo USDC nativo en la cadena de destino indistinguible del original porque es el mismo USDC nativo. Muy interesante.
CF: Muy bien, hemos hablado de la mecánica, de los supuestos de seguridad. ¿Qué salió mal en el pasado? Hay muchas historias de hacks y fallas, ¿tienes en mente algún hack o algún incidente que podamos usar para ver qué salió mal y qué hemos aprendido desde entonces?
T: Bueno, no sé sobre esa segunda pregunta, pero creo que cualquiera que haya estado en cripto el tiempo suficiente puede pensar en varios hackeos de puentes que han ocurrido. Ya sabes, algunos grandes relevantes para Cardano. Estuvo el hack de Nomad hace varios años. Ha habido el hack de Wormhole, también uno enorme. Estuvo Multichain, que algunas personas quizás hayan olvidado que existió, pero en un momento eran por lejos el puente más grande y más popular que había. Y de la noche a la mañana dejaron de existir y simplemente desaparecieron en el aire. Así que tal vez podemos hablar de ese.
Pero ese es bastante simple en el sentido de que básicamente tenían una puerta trasera en sus contratos inteligentes y simplemente tomaron todo.
CF: No lo llamaría un hackeo, ¿verdad? Esto es más bien como un hack barato.
T: Un hack de bajo presupuesto. Sí. Pero hay montones de casos así. Sabes, creo que normalmente todo se reduce a —no sé cómo decir esto sin ofender a toda la audiencia— cuando tienes hacks de puentes, básicamente la causa raíz casi nunca ha sido algo fundamental de la tecnología cross cadena en sí misma; no es la criptografía central la que ha fallado, no es un MPC implementado correctamente o las matemáticas subyacentes, ya sabes, la generación de claves correctamente implementada la que ha fallado. No son las L1 subyacentes, en la mayoría de los casos, al menos las principales, no es como si el consenso de Cardano hubiera fallado.
Siempre es simplemente o algo con cómo esa parte fuera de cadena está verificando lo que está ocurriendo en la cadena de origen que no fue configurado correctamente o hay problemas de gestión de claves, como que una clave privada se filtra y entonces alguien puede tomar control del multifirma, o ingeniería social y ese tipo de cosas también, o como mencionamos con multifirma, hay una puerta trasera.
Así que eso no hace que nadie se sienta mejor porque si pierdes dinero, pierdes dinero. Y en mi cabeza, creo que por eso también meto a Multi cadena en ese mismo grupo porque aunque es bastante diferente de una filtración de claves vía ingeniería social o un bug de verificación como creo que ocurrió con Wormhole y Nomad, desde el punto de vista del usuario no les importa, ya sabes, al final del día perdieron su dinero. Así que puedo ponerlos a todos en la misma canasta.
CF: Investigando para este episodio, busqué el mayor hack y fue el Ronin puente en marzo de 2022, 624 millones, y el exploit fue ingeniería social y obtuvieron cinco claves privadas de nueve, lo cual es una locura.
T: Sí, yo siempre bromeo también, ya sabes, que con estos tipos específicos de filtraciones, ya sabes, o cómo debería decirlo, diría que por eso cuando estás evaluando distintos puentes, normalmente serán bastante abiertos porque gente con conocimiento podrá ver en cadena si estás usando un multi firma o un MPC o algo así. Así que normalmente son bastante transparentes con respecto a cuáles son sus umbrales en términos de cuántos participantes hay en el multi firma, por ejemplo. Así que, como en el hack del Ronin puente, no era un secreto que había, bueno, creo que dijiste nueve, ¿verdad?, y que solo necesitabas cinco de nueve para explotar el puente.
Así que esto era información pública y cuando estás evaluando puentes, estos son los tipos de cosas que los usuarios normales pueden tomar en cuenta y desarrollar un perfil de riesgo razonablemente preciso. Como, ok, si tu multi firma tiene 100 participantes y es sin permiso, sí, podrías —y el umbral, inventemos algo— es 60 de 100, sí, podrías decir, bueno, tal vez 60 personas podrían ser víctimas de ingeniería social y filtrar sus claves privadas, pero obviamente eso es muy poco probable.
Pero si es tres de cinco, cinco de nueve, de repente estás muy dentro del terreno de lo posible. Especialmente si es un sistema con permisos y el proyecto no es muy transparente sobre quiénes son los firmantes, entonces de repente podrían ser nueve firmantes que trabajan para la misma empresa, que están todos en el mismo servidor o algo así. Entonces de repente se vuelve mucho más creíble que la ingeniería social pueda romper ese tipo de sistema incluso si hay, ya sabes, 600 millones de dólares en él. Podrías sentirte tentado a asumir que hay medidas de seguridad adecuadas en su lugar, pero más a menudo que no, especialmente en blockchain, no es así.
CF: Bien. Mirando ahora, tal vez no es necesariamente una pregunta sobre interoperabilidad y puentes, pero creo que tiene sentido tocarlo contigo. Me gustaría saber qué piensas. Me parece que el espacio de bloques ahora se ha vuelto fácilmente disponible, ya sabes, con tantas blockchains, Solana, Ethereum, Cardano, Definity Near, todas las L2 de Ethereum, así que parece que hay más espacio de bloques disponible que demanda, y ahora hemos visto por ejemplo en el mundo de Ethereum el regreso al maximalismo de una sola cadena donde están intentando consolidar todo de nuevo en una sola cadena en lugar de tener este sharding y fragmentación. ¿Ves que esta tendencia continúe y esto tiene impacto en cómo ves a tu empresa hacia adelante? Porque si vemos esta consolidación hacia solo unas pocas layer 1, tal vez Bitcoin, Ethereum, Solana, Cardano, por supuesto, habrá menos necesidad de interoperabilidad o cómo lo ves.
Creo que definitivamente observo las mismas cosas que tú estás observando. Por supuesto, probablemente hoy en día la expansión específicamente de L2 de Ethereum y cadenas laterales fue demasiado agresiva. Así que sí estoy de acuerdo en que probablemente veremos cierta consolidación. No creo que la visión original de por qué la interoperabilidad necesita existir esté bajo ninguna amenaza. No creo que vayamos hacia una sola cadena, pero sí creo que podemos podar en los bordes en términos de cuántas cadenas se necesitan actualmente, particularmente en el espacio de L2 de Ethereum. Algo que entra un poco en conflicto con ese punto de vista es que las empresas han empezado a llegar. Siempre han estado ahí en segundo plano, pero han dado un paso al frente en los últimos años, para bien o para mal.
CF: Una de las cosas que surgió en la conversación con empresas es que muchas de ellas construyen sus productos con Corda, Hyperledger, Ethereum, Besu, Canton, la primera iteración de la red que era más bien privada, y se dieron cuenta de que hacer algo con cadenas privadas con permisos derrota el propósito de una blockchain, ¿verdad? Podrías simplemente usar una base de datos centralizada. Así que ahora están viniendo a las layer 1 y hay mucha demanda: o empiezan desde cero y construyen sobre Cardano, Ethereum, Solana o están construyendo puentes de interoperabilidad desde esas blockchains empresariales como Hyperledger, que quizás es la más famosa, luego Corda, y están ocurriendo cosas en esa dirección.
T: Sí, absolutamente. Y sé que tú conoces muy bien esta historia, pero creo que en los primeros días del mundo empresarial había una sensación clara de que las empresas querían ejecutar su propia blockchain. Y decían, “oh, podemos hacer que todos nuestros clientes vengan a nuestra cadena”. Y luego en la práctica se dieron cuenta de que eso no ocurrió porque, de la misma manera que ellos no estaban dispuestos a ir a la blockchain de otra persona y poner todos sus datos propietarios allí, sus socios tampoco estaban dispuestos a hacer lo mismo. Y entonces eso, como mencionaste, los llevó de vuelta a mirar hacia el espacio público.
Donde yo creo, y quizás me preocupa, no lo sé, pero hacia donde creo que están yendo las cosas es que estás empezando a ver emerger una nueva clase de blockchains. Entonces, mientras espero ver que el sistema completamente público de L2 de Ethereum comience a consolidarse, también vamos a empezar a ver la aparición de nuevas cadenas que son operadas y gestionadas de una forma como semi-pública. Se presentan como públicas, pero su cliente principal está pensado para ser empresas, lo que significa que tendrás muchas de las características de una cadena pública, pero también muchos de los mecanismos de seguridad que esperarías ver en un sistema cerrado. Puedes ver esto con cadenas que tal vez son propiedad de entidades como Coinbase o potencialmente incluso Layer Zero a medida que eso se vuelve más claro.
Así que estoy observando qué pasa ahí. Entonces, en lugar de tener simplemente algunas cadenas empresariales totalmente permissionadas y algunas cadenas públicas totalmente orientadas a retail, y preguntarnos cómo interoperar entre ambas, podrías tener esta tercera clase híbrida donde…
CF: ¿Es Canton un ejemplo?
T: Canton es muy interesante. Bueno, creo que probablemente será difícil replicar Canton. Así que están casi en una categoría propia, pero creo que su diseño único probablemente viene del mismo lugar, donde son un tercero que está construyendo una blockchain específicamente para ser compatible con casos de uso permissionados, que creo que es donde viven muchas de las empresas.
Así que tenemos que ver cómo evoluciona eso. Pero mientras tengas diferentes tipos de cadenas apareciendo, tendrás más de una cadena, y tendrás una necesidad de interoperabilidad. Así que la interoperabilidad, como dijimos al principio, ha cambiado mucho a lo largo de los años, y no espero que eso cambie. No creo que hayamos llegado todavía al llamado “fin de juego” de la interoperabilidad.
T: ¿Qué opinas? Tal vez última pregunta, ¿cuál crees que es el fin de juego? ¿Cuál es el mayor problema sin resolver o cómo crees que será el futuro de la interoperabilidad en cinco años?
T: No vamos a llegar ahí en cinco años, pero a muy largo plazo creo que para el bienestar de la industria necesitamos llegar a un punto donde la interoperabilidad… donde los proveedores de interoperabilidad sean ellos mismos interoperables, y una de mis preocupaciones ahora mismo es que estamos yendo en la dirección opuesta. Las soluciones de interoperabilidad están siendo cada vez más posicionadas como implementaciones a nivel de producto. Entonces, si construyes algo con un protocolo de paso de mensajes, o un puente, o un protocolo de mensajería, los resultados de esas cosas no son compatibles con otros proveedores.
Así que estás en riesgo de quedar atrapado con un proveedor, algo que será muy, muy costoso de revertir. Y eso es porque las piezas entre blockchains, la pila de interoperabilidad, nunca ha sido completamente adoptado por la industria como parte de la tecnología central de blockchain. Siempre ha sido, ya sabes, algo aparte. Y mi visión a largo plazo es que tenemos que llegar a un punto donde haya suficientes estándares a nivel de toda la industria para que los proveedores de interoperabilidad sean interoperables entre sí.
No soy muy optimista, porque no estamos yendo en esa dirección. Estás viendo actores específicos que se están volviendo muy, muy grandes con soluciones propietarias y, aún más preocupante, sé que muchos de los grandes no quieren estándares a nivel industria. No ven la necesidad porque están en una posición muy poderosa.
Así que, dicho todo eso, en cinco años no soy muy optimista, pero dentro de esos cinco años creo que todavía van a pasar cosas muy interesantes y emocionantes. Ahora mismo, a nivel retail, creo que la abstracción de cadenas tiene mucho potencial. Como industria, no hemos sido muy buenos a lo largo de los años, por muchas razones, creando experiencias de usuario fluidas. La idea de una billetera y tener que firmar transacciones y todo eso quizás hasta ahora ha sido incompatible con una experiencia de usuario sin fricción, pero cosas como la abstracción de cadenas creo que ayudarán a suavizar mucho eso, y ese es el tipo de cosas que espero ver en el corto plazo, donde los usuarios no necesitan preocuparse, y la mayoría de ellos no se preocupa por en qué cadena están sus activos o qué cadena están usando. Sí, tienes tribalismo y cosas así, pero estoy hablando de gente que quiere usar aplicaciones.
CF: Estoy totalmente de acuerdo contigo, pero me pasa que creo que Cardano es una de las layer 1 más descentralizadas, ¿no? Y entonces me duele un poco pensar que si a la gente no le importa en qué cadena está, podríamos terminar con cadenas más centralizadas. El propósito de una blockchain es la autosoberanía, y podríamos entrar en un escenario de “no me importa qué cadena uso” y terminar usando una cadena muy centralizada donde no tienes autosoberanía, ese es el lado oscuro.
T: Me preocupa que vayamos a terminar con una nota bastante sombría porque estoy de acuerdo con mucho de lo que dijiste. Al principio creo que mencioné que yo me sentí atraído por blockchain por esta promesa romántica de que todo el mundo funcionaría sobre tecnología descentralizada y todas las ventajas que eso trae. Creo que a medida que la industria ha avanzado, y como puedes ver, no creo que dirías que en general, desde el lanzamiento de Cardano y las blockchains que vinieron después, se hayan vuelto más descentralizadas; como dijiste, Cardano incluso hoy sigue estando entre las más descentralizadas, pero en general estamos viendo lo contrario, estamos viendo una disposición a sacrificar descentralización por mayores velocidades y mayor rendimiento, y creo y me preocupa que esa tendencia solo vaya a continuar, especialmente ahora que las empresas están entrando en juego.
Y han demostrado, con razón o sin ella, que para ellos la seguridad es más importante que la descentralización, y no buscan descentralización por la descentralización en sí misma. Están más que felices de tener mecanismos de emergencia y poder presionar un botón de stop y todo ese tipo de cosas que probablemente tengas que sacrificar entre 2026 y 2027 para lograr un rendimiento muy alto con alta seguridad.
Así que sí, no quiero terminar demasiado sombrío. Por eso también espero que estos mismos problemas se reflejen en la interoperabilidad; los líderes del mercado no están prometiendo máxima descentralización. Ese no es el discurso. El discurso es que tú, como emisor, tienes el control, y eso es algo incompatible con la descentralización.
CF: Bien, eso fue increíble. Muchas gracias. Fue súper revelador y deberíamos hacer esto de nuevo en 5 años para ver qué tan acertados fuimos con nuestras predicciones. Muchísimas gracias.
T: Absolutamente. Y déjame decir que espero que no hayamos sido precisos, que la industria dé un giro brusco, que la descentralización vuelva a ser el objetivo y podamos avanzar en esa dirección.
CF: Gracias
Gracias por acompañarnos en Let’s Talk Cardano. Para más ideas y análisis profundos sobre el mundo de blockchain, no olvides suscribirte y visitarnos en cardanofoundation.org donde encontrarás recursos adicionales y contenido sobre todo lo relacionado con blockchain. Deja una reseña donde sea que escuches podcasts. Síguenos en redes sociales y mantente atento a más contenido próximamente.