Entrevista a John Adler de Celestia Labs en Sovereign Radio
Resumen de la Entrevista a John adler por Laura Shin en el pasado Modular Summit 3.0
📺Accede a la entrevista completa aquí:
Laura Shin comienza presentado a John Adler, director de ingeniería de protocolos y cofunder de Celestia Labs.
Laura: Celestia ha despegado desde su lanzamiento el año pasado. ¿Cuáles son algunos de los logros de los que estás especialmente orgulloso? ¿Y cuáles han sido algunas de las sorpresas desde el lanzamiento?
John: Sí, diría que hay dos logros de los que estoy particularmente orgulloso. Uno de ellos ya ha sucedido y el otro está a punto de suceder. El primero es que un gran número de personas han estado ejecutando light nodes en diversos dispositivos alrededor del mundo, incluso en radios con limitaciones de internet. Creo que este es un gran hito en el desarrollo de blockchains en general, en cuanto a cómo se utilizan. Porque, aparte de Bitcoin, ninguna otra blockchain excepto Celestia tiene clientes ligeros que la gente pueda ejecutar con hardware tan barato y con tan pocas restricciones de ancho de banda.
Laura: Entonces, un cliente ligero no contiene la cadena de bloques completa….
John: Correcto. Un cliente ligero no descarga la blockchain completa, solo descarga los encabezados de los bloques. Pero lo más importante es que no se trata solo de que los clientes ligeros de Celestia descarguen los encabezados de los bloques, sino que también realizan un muestreo de disponibilidad de datos. Esto es una especie de “ingrediente secreto” que permite que los clientes ligeros sean tan seguros como los full nodes. No solo son clientes ligeros, sino que también realizan muestreo de disponibilidad de datos.
Algunos clientes ligeros, como mencioné, son muy populares en Bitcoin. Satoshi, en su diseño de Bitcoin, dedicó una sección entera a los clientes ligeros, llamados clientes SPV (Simplified Payment Verification) en ese entonces. Básicamente, ninguna otra blockchain excepto Celestia ha priorizado este tipo de cliente como una parte fundamental.
El segundo logro, que está en progreso pero cerca de completarse, es lo que llamamos el Hard Fork Lemongrass. Es el primer hard fork de Celestia que introduce una serie de nuevas características y mejoras, y establece las bases para futuras rutas de actualización. Esta es la primera actualización de la red que se espera en el próximo mes aproximadamente. Creo que es un gran logro para todo el equipo poder implementar un cambio tan importante en el protocolo, y hacerlo de una manera que recuerda al estilo de los Hard Forks de Ethereum, permitiendo la opcionalidad y la autoridad, y permitiendo a los usuarios elegir si quieren seguir esta nueva actualización de la red o no.
Laura: Retrocedamos un poco y pensemos antes del lanzamiento. ¿Cuáles eran los principales problemas que intentaban resolver con Celestia?
John: La idea de Celestia, que en ese entonces se llamaba Lazy Ledger, fue creada por mi cofundador Mustafa Al-Bassam y por mí. Era una manera de escalar blockchains. El problema de la escalabilidad es bastante genérico, pero en ese momento, muchas personas estaban pensando en cómo escalar las blockchains separando ciertas funciones. Por ejemplo, los rollups estaban comenzando a ganar popularidad. La idea era proponer todos los datos a Ethereum, y verificar la ejecución externamente. Esta separación entre la capa base, que se encarga de la disponibilidad de datos, y la capa de ejecución es crucial.
Pero incluso con estas soluciones, había restricciones muy significativas sobre la cantidad de datos que la capa base podía manejar en ese momento. Ethereum tenía muchas limitaciones, lo que hacía que seguir utilizando la capa base fuera extremadamente costoso, aunque más barato que otras alternativas. La separación de la disponibilidad de datos de la ejecución permite que la capa base maneje solo la disponibilidad de datos, lo que es mucho más escalable y puede reducir los costes para los rollups.
Laura: ¿Cuál era tu experiencia antes de comenzar con Celestia?
John: Antes de Celestia, trabajé como ingeniero de investigación en ConsenSys, donde me enfoqué en Plasma y rollups. Allí desarrollé la idea de los rollups optimistas. Después de esto, desarrollé Lazy Ledger porque vi que esta era realmente la forma en que las blockchains deberían escalar, a través de este enfoque modular. Mustafa se acercó a mí un día para preguntarme si quería comenzar esta nueva blockchain, y pensé: “Sí, esto es exactamente como creo que las blockchains deberían escalar”.
Laura: Bueno, ahora Celestia está trabajando en nuevas cosas. Hay una nueva primitiva llamada Lazy Bridging, que utiliza la abstracción de cuentas. ¿Puedes explicar qué es?
John: Sí. Lazy Bridging es una aplicación de cuentas ZK. Primero, debo explicar cómo funciona en el contexto de Celestia. Celestia es una blockchain que solo realiza disponibilidad de datos y no ejecución. A diferencia de Ethereum, no tiene un entorno de ejecución de smart contracts. Esto significa que no se pueden verificar directamente que un rollup se haya ejecutado correctamente, ni hacer depósitos y retiros de fondos del rollup en la capa base.
Esto es similar a Bitcoin, que utiliza predicados sobre UTXOs para definir condiciones de gasto, Celestia puede realizar verificaciones en lugar de ejecuciones. Esto ofrece beneficios de rendimiento y seguridad. La idea es que, al no necesitar una máquina virtual genérica, solo se realiza la verificación de pruebas específicas. Esta lógica de verificación se enmarca en las cuentas ZK, permitiendo una gran flexibilidad sin necesidad de ejecución en la capa base.
Las cuentas ZK en Celestia funcionan como un tipo especial de cuenta donde los cambios requieren una prueba ZK válida para ser publicada y verificada en Celestia. La prueba es completamente genérica y lo que se verifica es independiente de lo que ocurre fuera de la cadena. Esto significa que se puede tener una lógica compleja, incluso sin una Máquina Virtual de Ethereum, operando completamente fuera de la cadena. La capa base de Celestia solo necesita verificar las pruebas, lo que permite que la cuenta actualice su estado basándose en la transacción verificada.
Laura: ¿Puedes dar un ejemplo de cómo esto se aplica?
John: Por ejemplo, si alguien quiere mover un token de Solana a Celestia, podrían usar Lazy Bridging para emitir una prueba ZK que verifique la transacción. La capa base de Celestia solo necesita verificar esta prueba, sin necesidad de conocer la lógica específica de la transacción. Esto hace que el proceso sea más seguro y eficiente. Además, al combinar cuentas ZK con abstracción de cuentas, se pueden realizar transacciones atómicas entre varios rollups, como retirar de uno y devolver a otro, sin necesidad de ejecutar smart contracts en la capa base.
Esto ofrece una gran flexibilidad sin necesidad de agregar ejecución genérica a la capa base. Puedes tener toda la funcionalidad de un sistema blockchain genérico como la máquina virtual de Solana o Ethereum sin complicar la capa base.
Laura: Eso me recuerda, no sé si lo recuerdas, pero cuando tenías Google Authenticator, tenías que actualizar cada código individualmente cada vez que obtenías un nuevo teléfono. Ahora, se actualizan automáticamente cuando cambias de teléfono.
John: No uso Google Authenticator, pero puedo imaginarlo. Es un gran ejemplo de cómo algo que solía ser un gran problema ahora es mucho más fácil. En un sistema blockchain, no solo es una molestia, también es muy costoso porque tienes que firmar múltiples transacciones. Con este tipo de almacenamiento de claves, puedes hacer una rotación de claves con una sola transacción.
Laura: Y me imagino que usando cuentas ZK de esa manera te permite mantener la capa base liviana y evitar muchos Hard Forks para actualizar la funcionalidad, solo necesitas actualizar estas cuentas externas.
John: Exactamente. Hay mucha flexibilidad porque las cuentas ZK en el rollup pueden tener una lógica arbitrariamente compleja. Podrías tener la EVM completamente operando fuera de la cadena y solo necesitar verificar las pruebas en la capa base.
Laura: ¿Esto también aborda los problemas de fragmentación que mencionaste antes?
John: Sí, exactamente. Al permitir que las transacciones y transferencias de activos se realicen de manera segura y sin necesidad de confiar en terceros, se reduce significativamente la fragmentación. Esto permite una mayor interoperabilidad entre diferentes cadenas y rollups dentro del ecosistema de Celestia, creando un entorno más cohesionado y seguro para los usuarios.
Laura: Pero esto solo se aplica a las transiciones de estado y no necesariamente a activos externos, ¿correcto?
John: Exacto, esto solo se aplica a las transiciones de estado y no automáticamente a los activos externos. Por ejemplo, si tienes un NFT en Solana y quieres moverlo al ecosistema de Celestia, necesitas un protocolo como Wormhole. Esto puede causar fragmentación, ya que los usuarios deben confiar en el poder custodial de los operadores del bridge Wormhole y otros operadores de bridge para mover fondos entre cadenas.
Lazy Bridging permite crear puentes que no requieren confianza en un comité o validadores externos. Todo se basa en pruebas ZK verificadas matemáticamente. Esto elimina la necesidad de confiar en terceros para la custodia de fondos, reduciendo significativamente los riesgos de hackeos y problemas de seguridad que hemos visto con otros bridges. Así, se minimiza la fragmentación al permitir que las cadenas y rollups dentro del ecosistema de Celestia interactúen de manera segura y sin confianza.
Laura: ¿Cómo funciona esto en la práctica?
John: Puedes tener un sistema de bridge en dos partes: una parte en la capa base de Celesita que verifica la prueba ZK y otra parte en el rollup que implementa la lógica de la transacción. Por ejemplo, si una prueba ZK válida indica una retirada, la capa base puede procesar esa retirada sin conocer la lógica específica. Esto permite una gran flexibilidad y seguridad, eliminando la necesidad de un comité o validadores externos.
Esto resolvería los problemas de hackeos en bridges que hemos visto, siempre y cuando la lógica ZK esté implementada correctamente. No necesitas confiar en un tercero para asegurar las claves o custodiar fondos. Los fondos están esencialmente custodiados por la propia máquina de estado, siguiendo las reglas definidas por las pruebas ZK. Esto permite un bridge que no requiere confianza, solo necesitas confiar en que tu full node de Celestia está operando correctamente y en que la máquina de estado se está ejecutando correctamente.
Laura: Obviamente, como acabas de mencionar, la fragmentación es un problema que se resuelve. Pero también hemos visto muchos hackeos con bridges. ¿Esto lo resuelve de alguna manera, o al menos, minimiza los problemas de centralización que llevaron a esos hackeos?
John: Correcto. Sí, siempre y cuando la lógica ZK del circuito esté implementada correctamente. No tienes que confiar en un tercero para asegurar tus claves o custodiar fondos. Los fondos están esencialmente custodiados por la propia máquina de estado y las reglas de la máquina de estado.
Así que no confías en nadie más para custodiar los fondos. Obviamente, si la máquina de estado es hackeada, similar a lo que sucedería si hubiera un error importante en la máquina virtual, se esperaría que la comunidad adopte una solución. Por supuesto, no se puede obligar a la comunidad a adoptar una solución, pero generalmente lo hacen. En los casos raros donde hay errores en la máquina virtual subyacente, la comunidad suele unirse para solucionarlo.
Las máquinas de estado suelen ser bastante simples, lo que reduce la posibilidad de errores en comparación con los smart contracts, que pueden ser muy complejos y difíciles de depurar. Aunque no elimina completamente los problemas, este sistema reduciría significativamente los problemas de seguridad que hemos visto con los bridges en el pasado.
Laura: Para hacerlo un poco más concreto para los oyentes, ¿podrías contrastar la experiencia actual con los bridges en comparación con cómo sería con Lazy Bridging?
John: Sí, claro. La experiencia actual implica elegir un proveedor de bridges específico para mover fondos entre cadenas. Esto puede causar problemas de fragmentación, ya que diferentes proveedores tienen diferentes reglas y niveles de seguridad. Además, puede haber problemas de liquidez y custodia, así como riesgos de hackeos.
En el futuro, con Lazy Bridging, habría un puente canónico que proporciona mejor seguridad. Similar a cómo funciona el puente canónico entre Ethereum y Arbitrum, no habría necesidad de envolver activos a través de un proveedor específico. Los activos simplemente se moverían de una cadena a otra sin prefijos ni sufijos complicados.
Laura: Definitivamente suena mucho más fácil. Celestia también está ayudando a habilitar rollups soberanos. ¿Puedes hablar sobre qué son y cómo se diferencian de los rollups de smart contracts?
John: Sí. Los rollups soberanos son un concepto que nos entusiasma mucho. A diferencia de los rollups tradicionales, que dependen de smart contracts en la capa base para verificar la corrección, los rollups soberanos permiten que los usuarios del rollup determinen su corrección. En los rollups soberanos, la corrección es determinada por los operadores de nodos y la comunidad del propio rollup. Esto es diferente de los rollups tradicionales como Optimism en Ethereum, donde la corrección depende de los validadores de Ethereum y de la comunidad para solucionar errores.
En los rollups soberanos, no necesitas un comité multisig para actualizaciones. Pueden ser actualizados de manera independiente por la comunidad del rollup, sin depender de la máquina de estado o de la comunidad de la capa base.
Laura: ¿Qué más hay en ese roadmap de Celestia?
John: Está dividido en tres áreas. Una de ellas es la abundancia, donde hablamos de una gran cantidad de espacio en bloques. La otra es la verificabilidad, lo que significa que las personas pueden ejecutar nodos ligeros. Y por último la adopción por parte de un gran número de usuarios.
Big blocks: En nuestro roadmap, queremos llegar a bloques de 1 Gigabyte cada 12 segundos, lo cual es un aumento de magnitudes en comparación con los actuales bloques de 2 Megabytes cada 12 segundos. Esto representa un aumento significativo en el rendimiento en comparación con otras blockchains.
Verificabilidad: Queremos que los usuarios puedan ejecutar light nodes de manera muy económica, para que todos tengan acceso a la alta seguridad de la disponibilidad de datos. Estamos desarrollando light nodes que se pueden ejecutar en el navegador, utilizando WebAssembly (Wasm). Esto permite que los usuarios verifiquen no solo la cadena de encabezados, sino también la disponibilidad de datos directamente en su navegador sin necesidad de descargar ningún software adicional.
Esto significa que eventualmente, las wallets podrán conectarse a estos light nodes en el navegador, en lugar de depender de proveedores centralizados como Infura para Ethereum.
También estamos trabajando en varias mejoras como header pruning, lock running, header drilling …, lo que reducirá el coste de ejecutar un light node. Esto hará que sea más accesible para un gran número de usuarios. Además, a medida que aumente el número de light nodes que realizan muestreo de disponibilidad de datos, podremos aumentar el tamaño de los bloques mientras mantenemos la misma seguridad.
Laura: Eso definitivamente suena a un vistazo al futuro. Ha sido muy emocionante charlar contigo. Muchas gracias por compartir tu trabajo actual con Celestia y tu visión para el futuro.
John: Gracias a ti, Laura.
Twitter | Medium | LinkedIn | Discord | Telegram | cumulo.pro
