Introducción

A finales de 2020, Ethereum adoptó una enfoque centrado en rolluppara ofrecer transacciones rápidas y económicas. Sin embargo, esto conlleva el costo de una mayor fragmentación, ya que los usuarios y la liquidez se dispersan en múltiples rollups. Esta fragmentación es un desafío a nivel de ecosistema que impide una experiencia unificada de Ethereum.

En este artículo, examinaremos las raíces de esta fragmentación, analizaremos uno de los desafíos principales de la interoperabilidad de rollup, la equivocación, y categorizaremos las soluciones que existen para abordar este problema. Al describir las diferentes soluciones propuestas respecto a la interoperabilidad de rollup y destacar los compromisos involucrados, esperamos brindar una visión del futuro de la interoperabilidad de rollup y cómo construir un futuro de rollup mejor conectado.

El problema de la fragmentación

La fragmentación del estado en diferentes rollups conduce a una mala experiencia del usuario, una eficiencia de capital reducida y una falta de composabilidad nativa:

Experiencia del usuario: La fragmentación obliga a los usuarios a cambiar de red con frecuencia, gestionar múltiples copias del mismo token y equilibrar varias billeteras. Esto añade fricción y complejidad, lo que hace más difícil que los usuarios disfruten de una experiencia de Ethereum fluida y que simplemente funcione. Por ejemplo, supongamos que Alicia tiene sus fondos en rollup A pero desea comprar un token disponible solo en Rollup B. En lugar de simplemente hacer clic en “Comprar”, primero debe cambiar de red, transferir sus fondos de A a B, esperar las confirmaciones de L1 y luego ejecutar la operación de compra.

Liquidez: Con la liquidez dispersa en múltiples rollups, los pares de negociación carecen de profundidad y eficiencia. Esto conduce a precios peores, rendimientos reducidos para los protocolos de préstamo y ejecución comercial subóptima.

Composabilidad: En una sola cadena, un protocolo de préstamo puede liquidar instantáneamente una posición llamando a un contrato DEX en la misma transacción, todo sucede en un solo atomic, sincrónicoEn un mundo fragmentado y multi-rollup, ese proceso se vuelve asíncrono. El protocolo podría desencadenar una liquidación en un rollup, luego esperar un mensaje para finalizar en el DEX de otro rollup. Si algo sale mal, revertir el proceso no es sencillo. Además, Ethereum no proporciona herramientas nativas para realizar llamadas de contrato entre rollups o garantizar una ejecución rápida de estas llamadas. Esta pérdida de interacciones inmediatas y atómicas socava la composabilidad que hace tan poderoso al ecosistema de Ethereum.

Interoperabilidad

En su esencia, interoperabilidad significa permitir una transacción que comienza en un rollup y actualiza el estado en otro, como enviar tokens de Rollup A a Rollup B. Idealmente, esta acción es tan simple como hacer que su saldo en A disminuya y su saldo en B aumente, todo al mismo tiempo. En la práctica, lograr un comportamiento tan fluido de 'todo o nada' es un desafío entre diferentes rollups.

Idealmente, las interacciones entre rollups funcionarían igual que en Ethereum L1, de forma síncrona. En un entorno síncrono, múltiples llamadas a diferentes contratos en diferentes rollups pueden agruparse en una sola transacción que ya sea tenga éxito en su totalidad o falle por completo, brindando resultados inmediatos y atómicos.

Por el contrario, la componibilidad asíncrona implica varios pasos repartidos a lo largo del tiempo en diferentes paquetes acumulativos. En lugar de una sola transacción atómica, una acción puede desencadenar un evento en un paquete acumulativo y, a continuación, esperar la confirmación antes de completar la interacción en otro. La componibilidad asíncrona debe lidiar con las anulaciones: solo uno de los paquetes acumulativos puede realizar la acción a tiempo y, luego, es posible que deba revertir esta transición de estado parcial (ya que el paquete acumulativo de paquetes acumulativo opuesto no hizo su parte). La componibilidad sincrónica y asincrónica comparten muchos desafíos comunes que analizamos aquí.

Este artículo se centra en soluciones de interoperabilidad nativas de rollup que requieren integración a nivel de protocolo. Excluimos soluciones de puente externas que dependen de proveedores de liquidez y solo admiten transferencias de tokens fungibles.

Los desafíos de interoperabilidad

Lograr una verdadera interoperabilidad entre rollups no se trata solo de enviar mensajes de un lado a otro; se trata de garantizar que las transacciones se finalicen de forma segura y rápida. Depender únicamente de Ethereum L1 puede significar largos retrasos y altos costos. Alice tiene sus fondos en rollup A pero quiere comprar un token disponible solo en Rollup B. Dos opciones son posibles:

• Rollup B solo acepta los fondos de Alice si se transfieren a través de Ethereum. En este caso, Alice necesita retirar sus fondos a L1, luego depositarlos en el rollup B y finalmente comprar el token en el rollup B, lo que conlleva un alto retraso y costo.
• Rollup B proporciona un camino más rápido y económico al procesar la transferencia directamente en lugar de liquidar primero en Ethereum Layer 1. Sin embargo, como explicamos a continuación, esto expone a Rollup B a posibles riesgos de reorganización si Rollup A equivoca, no liquida o presenta una transición de estado inválida.

Cuando dos L2 interactúan a una latencia más rápida que Ethereum (es decir, antes de que siquiera confirmen o liquiden sus transiciones de estado a L1), hay tres problemas fundamentales con los que los rollups necesitan lidiar: la equivocación, la invalidez y la no liquidación.

• Equivocación: Un rollup transmite estados conflictivos a diferentes cadenas, prometiendo efectivamente los mismos activos varias veces.
• Invalidez: Es posible que una transición de estado nunca sea demostrablemente correcta en L1.
• No liquidación: La generación de pruebas o el proceso de liquidación podrían estancarse indefinidamente.

Reiteremos aquí que todos estos problemas pueden resolverse trivialmente esperando la finalidad de L1, cuando las transiciones de estado estén completamente resueltas en Ethereum. Sin embargo, estamos interesados en habilitar interacciones seguras entre rollups cruzados a una velocidad más rápida que la latencia de Ethereum. Exploramos soluciones que mantengan la seguridad mientras operan en esta ventana de sub-finalidad.

Ilustremos estos desafíos con un ejemplo: supongamos que Alice posee 10 ETH en la red principal de Scroll y quiere transferirlas a Bob en Arbitrum. Idealmente, Alice podría mover la liquidez entre estas dos cadenas de forma nativa a velocidades más rápidas que Ethereum. Supongamos que existiera una solución de este tipo, en la que Arbitrum acreditara a Alice con 10 ETH en Arbitrum antes de que Scroll enviara algo a L1, ¿qué podría salir mal para Arbitrum?

• Equívoco: Scroll se equivoca al cometer en L1 una transición de estado diferente en la que la transacción de Alice no está incluida, robando efectivamente 10 ETH de Arbitrum (que necesita reorganizarse para poder liquidar).
• Invalidity: Scroll no equivale, pero la transición de estado que contenía la transacción es inválida, por lo que Scroll nunca puede liquidarla (es decir, demostrarla) en L1 y dar los fondos a Arbitrum. Nuevamente, Arbitrum necesita reorganizarse para poder liquidarla.
• No liquidación: Scroll no equivoca y la transición de estado es válida, pero los probadores designados de Scroll se desconectan y, por lo tanto, la liquidación nunca ocurre. Arbitrum necesita reorganizarse nuevamente.

Al integrar Arbitrum los 10 ETH enviados por Alice en Scroll antes de que Scroll se comprometa en L1 (en caso de equivocación) y antes de que Scroll se resuelva (en caso de invalidez y no resolución), Arbitrum asume un riesgo en su cadena dependiente de las consideraciones de seguridad de Scroll.

Un aspecto crítico de la interoperabilidad de rollup es cómo los sistemas manejan la equivocación. Diferentes arquitecturas toman enfoques diferentes. En algunos sistemas como el OP Superchain, los rollups están diseñados para reorganizarse juntos: si un rollup equivoca, todos los rollups conectados deben reorganizar su estado para mantener la consistencia en todo el sistema, una propiedad llamada bloques contingentes entre cadenas. Otras arquitecturas se centran en prevenir la equivocación por completo a través de varios mecanismos que exploraremos a continuación.

Tanto la no liquidación como la invalidez se resolverán de manera trivial una vez que la generación en tiempo real de la prueba zk sea práctica (también conocida como prueba en tiempo real). Sin embargo, el problema de la equivocación es fundamentalmente diferente. Una prueba zk puede demostrar que Alice envió 10 ETH a Bob en Arbitrum, pero no garantiza que Scroll cometa esta transición en L1. Las pruebas de Zk por sí solas no resuelven y nunca resolverán el equívoco. Por otra parte, esperar la liquidación de L1 resuelve el equívoco, pero a costa de la ventaja de velocidad del rollup. Por lo tanto, nos centramos en el equívoco previo a la liquidación, es decir, en las garantías de prevención de equívocos antes de la liquidación en Ethereum. Como veremos, cada enfoque implica diferentes compensaciones, especialmente en términos de supuestos de confianza que discutimos a continuación.

Arquitectura de interoperabilidad

Presentamos dos enfoques diferentes que se han explorado para la interoperabilidad a una latencia más rápida que Ethereum, a los que llamamos la malla y el concentrador.

En resumen, el modelo de malla es donde los rollups están directamente interconectados entre sí en un grupo donde todos confían en no equivocarse para lograr la finalidad preestablecida.

El modelo de hub introduce una capa compartida, en la que se basan los rollups para gestionar los equívocos: la prevención de las interacciones entre cadenas con una latencia más rápida que la de Ethereum. Exploremos lo que significa esta diferencia en la práctica.

Malla

El modelo de malla funciona tal como cabría esperar, con rollups comunicándose entre sí directamente mientras siguen siendo responsables de liquidar en Ethereum L1 ellos mismos:

A medida que más y más rollups se interconectan en esta gran malla, la transitividad de la confianza y las dependencias se convierte en un problema para la escalabilidad. Si Arbitrum confía en Scroll pero no en zkSync, entonces Scroll no puede confiar en zkSync mientras mantiene la confianza de Arbitrum. Solo los "grupos de confianza" disjuntos, es decir, las camarillas de rollups, pueden interactuar entre sí en una malla. Este problema de dependencia se amplifica a medida que más y más rollups están involucrados en casos de interoperabilidad complejos, donde la seguridad del conjunto se limita a la seguridad del rollup más débil.

Si bien los sistemas de malla dependen de la confianza para la seguridad de la liquidación previa, pueden detectar la equivocación en la liquidación, lo que desencadena reorganizaciones en todos los rollups conectados.

Por lo tanto, aunque este modelo de interoperabilidad tiene algunas deficiencias, es completamente adecuado para casos en los que las operaciones deseadas entre cadenas se limitan a rollups principales que han demostrado ser seguros y/o confiables, y que están dispuestos a crear esta dependencia de confianza en sus sistemas. Sin embargo, rápidamente queda claro que este modelo no escala bien si queremos agregar más y más rollups, otros L2 e incluso L3 de appchain en la malla.

Hub

En el modelo de concentrador, las deficiencias del modelo de malla se abordan mediante la introducción de una capa compartida. Cada rollup necesita confiar en esta capa, que actúa como la fuente de verdad para las interacciones, por lo que vincular un rollup más a la capa es mucho más fácil. Naturalmente, necesitamos que esta capa sea lo más segura posible para ofrecer las mejores garantías de no-equivocación con una latencia más rápida que Ethereum.

La ventaja de esta solución es que agregar rollups adicionales en la mezcla no crea más problemas de dependencia, ya que la capa de interoperabilidad actúa como un 'escudo' entre cada rollup. Esto puede incluir cualquier cadena L2 arbitraria, así como L3s y rollups de aplicaciones; todo lo que tienen que hacer es integrarse en el centro y disfrutar de los beneficios.

El principal compromiso de este enfoque es que todos los rollups tienen una dependencia compartida común en el centro, que obtiene un poder significativo.

Específicamente, para la prevención de la equivocación previa al asentamiento, debemos asegurarnos de que el concentrador no coludirá con un rollup equivocante. Los sistemas de concentradores reemplazan así la confianza mutua entre los rollups en el diseño de malla, con confianza en una sola capa compartida que no debe coludir con otros rollups para equivocar.

No es sorprendente, por lo tanto, que el centro debe ser construido teniendo en cuenta la seguridad y la descentralización. Hay algunas opciones diferentes para construir un centro como este:

• Usar un rollup existente: Esta opción tiene la ventaja de ser la más simple, ya que el rollup ya existe y presumiblemente ha sido probado en batalla, y sería cuestión de implementar contratos inteligentes en él.
• Creación de un componente dedicado: En lugar de pedir a los rollups que confíen en todas las propiedades de seguridad de un rollup existente, en su lugar creamos un nuevo componente dedicado para actuar como el centro. La ventaja aquí es que este nuevo componente tendría un vector de superficie de errores/exploits minimizado al estar específicamente diseñado para las necesidades entre cadenas (¡e incluso podría ser verificado formalmente!).
• Usando Ethereum L1 en sí mismo: Esta opción implica usar basado en preconfirmacionesdirectamente en la Capa 1 para tener lo mejor de ambos mundos: utilizar la capa máximamente descentralizada para obtener la máxima vitalidad y seguridad, mientras se tienen confirmaciones casi instantáneas, tiempos de retiro minimizados, etc.

Suponiendo que se estén utilizando pruebas zk, las tres opciones pueden aprovechar el concepto de agregación de pruebas para reducir aún más los costos involucrados, al hacer que el L1 verifique una sola prueba que agrupe muchas pruebas individuales de todos los rollups que son compatibles con el hub.

Sistemas existentes

Varios proyectos han propuesto diversas soluciones de interoperabilidad, que pueden ser categorizadas de la siguiente manera.

Sistemas de malla. OPSuperchain y de Arbitrum Cadenas de clústeresson sistemas de malla, donde las cadenas deben liquidarse cruzadamente juntas: si una cadena equivoca, todas las cadenas conectadas deben reorganizarse. Las cadenas deben confiar entre sí para confirmaciones de preliquidación.

Estas soluciones podrían transitar hacia el uso de algún tipo de hub, ya que los grupos de confianza no pueden escalar más allá de unos pocos rollups grandes para lograr la finalidad de preliquidación preestablecida.

Sistemas de concentradores. Espresso y el de zkSync Cadena Elásticason sistemas de concentradores. En Scroll, hemos estado explorando un diseño de concentrador que podría permitir soluciones de interoperabilidad más escalables y fiables. Nuestro presentaciónen el Taller de Criptoeconomía de Columbia 2024 se proporciona una visión general del diseño, con más detalles que se seguirán en una próxima publicación.

Otros sistemas. Las rollups basadas tienen el potencial de permitir la composabilidad sincrónica no solo entre sí, sino incluso con Ethereum L1, y a su vez pueden usar Ethereum L1 para la prevención de la equivocación.

AggLayer de Polygon es otro tipo de sistema de concentrador que proporciona una capa compartida con la que se comunican todos los rollups. Sin embargo, difiere en que evita suposiciones de confianza adicionales en esa capa compartida. En su lugar, esperan la liquidación y el uso pruebas pesimistaspara proporcionar seguridad. La equivocación se evita solo en el momento de liquidación. Las preconfirmaciones podrían usarse opcionalmente para ofrecer garantías de finalidad más rápidas. La capa de agregación anunció recientemente un asociación con Espresso Systems, que proporciona un mecanismo de secuenciación compartido.

Conclusión

Desarrollar un mecanismo de prevención de la equivocación para una interop más rápida que Ethereum conlleva todo tipo de compensaciones que deben ser cuidadosamente consideradas por el bien de la seguridad, la descentralización y la neutralidad creíble. Si bien esta publicación se centró en la prevención de la equivocación, hay varios otros desafíos críticos de interop que no hemos discutido profundamente aquí, como la disponibilidad de datos, el diseño de la capa de liquidación (por ejemplo, la implementación de contratos de puente compartidos y rollup entre diferentes rollups), protocolos de paso de mensajes y los incentivos económicos necesarios para que el sistema funcione. Pero como dijo Vitalik en un tweet reciente, estamos más cerca de resolver estos problemas de interoperabilidad de lo que la mayoría de la gente piensa. En este final de interoperabilidad, creemos que los usuarios realmente sentirán que están “usando un Ethereum”, en lugar de rollups individuales como hoy en día.

Descargo de responsabilidad:

1. Este artículo fue reimprimido de [Investigación de pergaminos]. Todos los derechos de autor pertenecen al autor original [Alejandro Ranchal-Pedrosa]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo y lo resolverán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen consejo de inversión.
3. El equipo de Gate Learn realiza traducciones del artículo a otros idiomas. Está prohibido copiar, distribuir o plagiar los artículos traducidos a menos que se mencione.