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 un fragmento de “Essential Cardano360 - June 2025 Edition”
Del minuto 00:31:06 al 00:41:10 del video original
Publicado en el canal de Youtube de IOHK el 26 de Junio de 2025
T: A medida que Cardano continúa creciendo, también crece la necesidad de una arquitectura de nodo más flexible y accesible. El nodo Haskell sigue sirviéndonos bien, ofreciendo fuertes garantías en términos de seguridad y corrección. Pero depender de un solo lenguaje ha dificultado que nuevos desarrolladores se involucren. El Proyecto Acropolis busca ayudar a cambiar eso reconstruyendo el nodo alrededor de una arquitectura modular basada en Rust.
Esto hace que el nodo sea más fácil de escalar, integrar y extender, mientras se le agrega resiliencia y se reducen las barreras para una participación más amplia. Paul Clarke habló con Rich para contarnos más.
R: Hola de nuevo, y hoy estoy acompañado por Paul del equipo de Acropolis aquí en Input Output. Paul, ¿cómo estás?
P: Estoy bien, gracias. Es un gusto estar aquí.
R: Paul, danos una pequeña introducción sobre ti y el trabajo que estás haciendo en IO.
P: Sí, claro. Soy arquitecto técnico en IOE y lidero lo que llamamos un equipo pionero, explorando cómo podemos usar diferentes arquitecturas de software para cambiar la forma en que construimos las cosas.
Mi experiencia es en sistemas en tiempo real, en medios de transmisión, cosas audiovisuales,
especializándome en sistemas modulares. Así que supongo que podrías decir que esa es mi especialidad: crear sistemas modulares que funcionen rápido. Y ese es el tipo de tecnología, el tipo de concepto que quiero traer también a este campo.
R: Fantástico. Entonces, el proyecto Acropolis, ¿cómo surgió todo esto?
P:Fue una idea, realmente, de que queríamos explorar cómo podíamos expandir la arquitectura de software con la que construimos el nodo, hacia una manera más extensible, una que pudiera escalar más, que pudiera operar más en paralelo que la actual. Así que me propuse básicamente observar cómo construimos nuestro software actual y me di cuenta de que podríamos hacer eso con el nodo a largo plazo.
Pero a corto plazo, en realidad estaba observando cómo las aplicaciones se comunican con el nodo existente y me di cuenta de que a veces eso es bastante difícil para la gente. Es un gran sistema, pero es una especie de caja negra y tienes una interfaz bastante limitada. Así que quise ver cómo podíamos usar esta arquitectura modular para facilitarles la vida a los desarrolladores.
Y al hacer eso, bajo un enfoque ágil, como es típico, tratás de encontrar un cliente real, un cliente con un dolor real y querés resolver eso. Y resultó que ese cliente era nuestra propia división de cadenas asociadas, y ellos tenían un problema en el que básicamente los recursos que necesitaban para ejecutar tanto un nodo completo como db-sync junto a él eran bastante altos, y querían reducir eso. Y ese se convirtió en el objetivo a corto plazo: ayudarlos.
R: Genial. Entonces hablemos sobre la diversidad de nodos. ¿Por qué es tan importante? ¿Por qué es un tema tan candente en este momento?
P: Es en parte filosófico y en parte práctico. Desde el punto de vista filosófico, tenemos esta increíble red descentralizada. Creo que es la red más descentralizada en términos de cantidad de nodos que la ejecutan. Ahora tenemos esta gobernanza descentralizada, y obviamente hay mucha actividad en torno a eso ahora mismo, pero nuestra base de código todavía es muy centralizada. No le quito mérito a su brillantez, pero es mantenida por un equipo relativamente pequeño y, en general, a los desarrolladores les ha resultado bastante difícil contribuir. Así que creo que hay un movimiento general hacia la diversidad de nodos para resolver ese problema, para descentralizar la base de código desde un ángulo más filosófico, pero también desde un punto de vista pragmático.
Mirando a largo plazo, no quieres que toda tu red dependa de una sola implementación.
Es mucho mejor tener múltiples implementaciones. Es más resiliente si hay cambios en los equipos. Imaginá cómo la NASA lanza una nave espacial: construyen múltiples computadoras,
de hecho normalmente construyen tres, todas haciendo el mismo cálculo, y luego toman el mejor de los tres si no coinciden. Ethereum hace eso, y deliberadamente buscan una diversidad en su ecosistema con diferentes nodos, así saben que tienen múltiples implementaciones, múltiples personas pensando en el problema desde diferentes enfoques,
y eso hace que la red en conjunto sea más resiliente.
R: Entonces, Paul, ¿estoy en lo correcto si digo que Acropolis no reemplaza al nodo en Haskell actual, sino que básicamente es una extensión de él? ¿Es correcto eso?
P: Bueno, en este momento sí. Lo estamos usando como un nodo de datos, donde se conecta a un nodo en Haskell existente y se usa para extraer datos de él y, en el futuro, enviar datos de vuelta hacia él. Pero existe el potencial de que se convierta en un nuevo nodo por sí mismo. Y entonces pasaría a ser parte del movimiento general hacia la diversidad de nodos que estamos viendo en Cardano con otros proyectos como Amaru y Dingo.
Realmente, en el último año ha habido mucho movimiento en esa dirección. Tuvimos una excelente mini conferencia en París en abril, donde nos reunimos todos los que estamos trabajando en nodos, incluyendo el equipo de Haskell, Acropolis, Amaru, Dingo y otros, y hablamos sobre lo que significa tener múltiples nodos en la red. Y lo que me llamó la atención fue cuán colegiado y cooperativo es el ambiente. No hay una sensación de competencia aquí. Todos estamos tratando de construir lo mismo, pero todos tenemos diferentes ideas sobre cómo podríamos hacerlo. Y eso genera la diversidad que nos dará resiliencia a largo plazo.
R: Así que esto es colaborativo y complementario, en vez de competitivo. Hablando de colaboración, cuéntame sobre algunas de las figuras más amplias que están involucradas en el proyecto Acropolis.
P: Bueno, al principio era un proyecto interno. Era solo yo por un tiempo, diseñando cosas y construyendo esta especie de infraestructura subyacente. Se llama Kariatid. Pero recientemente, hemos incorporado a otros socios. Así que ahora tenemos personas de cuatro compañías diferentes trabajando en esto, una de las cuales es Sundae Labs, que tiene una gran experiencia en el desarrollo, obviamente, de sus propias aplicaciones. Así que están actuando como clientes aquí, potencialmente, pero también han estado trabajando en el proyecto Amaru. Han hecho un montón de trabajo en sistemas de pruebas, han estado trabajando en Leios.
Así que hay una gran cantidad de conocimiento que incorporamos al equipo allí. Eso de hecho nos da esa diversidad de pensamiento. Siempre hay un peligro, si tienes un equipo muy limitado, de que tiendes a meterte en un túnel sin salida. Y de hecho, encuentro que en esta etapa, cuando estamos en esa parte del proceso de pensamiento divergente, es mejor tener más personas en la sala, y así pueden aportarnos muchas perspectivas diferentes.
R: Así que cambiando ligeramente de tema, Paul, ¿qué esperas ver del ecosistema ahora que esta modularidad abre nuevas oportunidades para las personas en Cardano?
P: En este momento hemos sido un proyecto un poco bajo el radar. No hemos… porque hemos estado construyendo nuestras bases, y hemos estado… ya sabes, es un proceso ágil, ¿no? Hemos escrito algunas cosas, y luego las hemos desechado, y luego las hemos vuelto a hacer. Así que no queríamos lanzarlo a la comunidad demasiado pronto, porque de lo contrario la cantidad de cambios que estábamos haciendo sería una molestia para todos.
Pero ese momento está llegando, nos gustaría que la comunidad, el ecosistema completo, se involucrara y comenzara no solo a pedir cosas en términos de, por ejemplo, el nodo de datos, nuevas APIs, diferentes formas en las que quieren consumir datos, sino también a empezar a escribir sus propios módulos.
Y lo genial de cómo lo hemos organizado con Kariatid es que, aunque estamos trabajando en Rust, puedes escribir un módulo en cualquier cosa, cualquier cosa que pueda comunicarse con un bus de mensajes. Puedes escribirlo en TypeScript, o Go, o Haskell, o Rust, o lo que elijas. Queremos acercar el nodo a donde está la gente. Que puedan construir su propia funcionalidad allí. Puede que haya aplicaciones simples que solo necesiten usar APIs estándar, y eso está bien, y proporcionaremos tantas APIs como podamos para que eso suceda, pero siempre existe la posibilidad de que si deseas un tipo de dato particular, o si deseas filtrarlo de una manera específica, puedas escribir tu propio módulo que se conecte a este nodo de datos y se convierta en un ciudadano de primera clase dentro de ese nodo. No es algo que esté por fuera, estás dentro del nodo.
De ahí viene esta especie de mantra mío de que el nodo es el ecosistema. Es tan poroso y tan flexible, que si deseas hacer una aplicación particular que no necesita cierta funcionalidad, simplemente la dejas fuera. Y si deseas agregar tu propia funcionalidad, puedes enchufarla allí. Creo que es a donde quiero que se dirija el ecosistema. Obviamente, esto es algo con lo que necesitamos ayudar a la gente, explicar y todo eso, y aún no hemos llegado completamente, pero escribir uno de estos módulos es relativamente fácil. Estamos hablando de un par de páginas de código, usualmente, para escribir un módulo. Así que esperamos que sea algo que la comunidad de desarrolladores más amplia pueda empezar a hacer también.
R: Maravilloso. Y lo mencionaste un poco, ¿cuáles son los próximos pasos para el proyecto Acropolis?
P: Bueno, estamos ahora en una etapa en la que estamos muy cerca de producir este santo grial, que son los datos de distribución de stake pools. Y eso es lo que ha impulsado tener que hacer todas las otras cosas. Obviamente, lo primero que hay que hacer ahí es, una vez que empecemos a derivar esos datos —y estamos a literalmente semanas de hacerlo—, vamos a probar eso contra el nodo Haskell original y contra lo que está en la red.
Así que podemos reproducir toda la cadena principal y verificar que coincidimos con todos los datos que el sistema existente ha producido. Así que ese es un flujo. Luego queremos continuar ese flujo con nodos de datos, en términos de agregar nuevas APIs y, como dije, ayudar a la gente a construir sus propios módulos. Y luego hay otro flujo que comenzará pronto, donde estamos comenzando a pensar en cómo esto podría convertirse en un nodo completo. Y luego necesitamos agregar todas las cosas como validación, la red par a par, la producción de bloques, todas las funciones que tiene un nodo completo y que no tiene un nodo de datos.
Y luego el tercer flujo es que estamos pensando mucho en Leios, porque Leios es un sistema mucho más paralelizado, ¿verdad? Hay muchas cosas sucediendo en paralelo, y esta arquitectura, cuando tienes módulos que escalan horizontalmente y se comunican sobre un bus de eventos, es una forma muy buena de hacer eso. Y esa es la razón por la que lo elegimos desde el principio. Así que tan pronto como el diseño de Leios esté suficientemente finalizado como para que podamos comenzar a desarrollar, comenzaremos a hacerlo, y vamos a usar Acropolis como una especie de banco de pruebas, porque es muy fácil cortar y cambiar cosas. Puedes enchufar cosas, reemplazarlas, quitarlas, poner otras. Así que esperamos que eso también sea una contribución al esfuerzo de desarrollo de Leios.
R: Fantástico. Entonces, si la gente quiere saber más sobre el proyecto Acropolis, ¿cómo pueden hacerlo?
P: Bueno, para ser honesto, hemos estado un poco bajo el radar hasta ahora. Hemos estado muy concentrados en diseñar y desarrollar esto, y las cosas han sido muy fluidas. Así que no lo hemos promocionado demasiado. Pero todo está en un repositorio de GitHub. De hecho, hay dos repositorios. Hay uno para Acropolis y uno para Kariatid. También puedes seguirme en X: @talena, que es una palabra córnica que significa “programador”. Y pronto saldrán más materiales. Tenemos una entrada de blog en camino. Vamos a estar produciendo más materiales orientados a desarrolladores en los próximos meses.
R: Muchas gracias, Paul. Un gusto tenerte en el programa.
P: Muchas gracias.
T: Así que gracias a Paul y a Rich por eso. Y para conocer más, consulten el repositorio de GitHub bajo el GitHub de IO y nuestro blog reciente. Encontrarán los enlaces abajo.