El estado de las soluciones de interoperabilidad de Rollup

Como entusiasta del ecosistema centrado en la acumulación, siempre me han interesado las soluciones que mejoran la interoperabilidad de las acumulaciones. Además, el único motivo por el que creé este informe de investigación fue difundir un mensaje sobre la importancia de la interoperabilidad en esta área. Luego, me di cuenta de que escribir artículos es una excelente manera de consolidar mi comprensión de un tema determinado y ayudar a las personas a comprenderlo, y ahora estoy aquí.

Como cada día se aprenden cosas nuevas en el mundo de las criptomonedas, debería parecer obvio que hoy en día considero que la visión de que “la interoperabilidad de los rollups es crucial para el futuro de Ethereum” está bastante desactualizada. Desde el punto de vista de la filosofía, sigo manteniendo la misma visión**: la interoperabilidad de los rollups es absolutamente crucial para el futuro de Ethereum**, y todo el ecosistema debería trabajar en soluciones que la mejoren. Sin embargo, desde el punto de vista de la tecnología, aprendí muchas ideas nuevas sobre este tema y cambié de opinión sobre algunas cosas.

Para comprender el material que se presenta a continuación, es útil tener un conocimiento básico de los rollups y el problema de su interoperabilidad. Si no lo tiene, mi artículo “Dr. Dankshard o cómo aprendí a dejar de preocuparme y a amar los rollups” es una excelente introducción.

¡Mejor amiga!

Es la tarde del 13 de noviembre, el primer día de Devconnect Istanbul . Como gran fan de ZkSync , decidí asistir a zkSync Connect como mi primer evento en esta cumbre, el primero de mi vida. Allí conocí a un chico y juntos nos dirigimos a “Mosyo Coffee”, como se indica en la página de Luma de zkCafe. Había dos de ellos en esa zona y encontramos el lugar correcto recién al anochecer.

Estaba mucho más oscuro que en la foto de arriba y llovía a cántaros. Mientras me quedaba en el borde del techo donde se encontraba el patio de comidas y bebíamos un café que habíamos comprado con fichas gratis en Clave , le conté a mi nuevo amigo sobre mi idea para un proyecto de hackathon.

Existen las “minicuentas”: cuentas ERC-4337 , cuya lógica de validación no es la comprobación de firma sino la existencia del hash de la operación en el puente de entrada único en su L2. El hash debe enviarse desde su dirección principal en una cadena de origen específica. La dirección principal es su billetera inteligente principal en cualquier L2 o Ethereum L1. Para interactuar con otra L2, debe:

• Implementa la minicuenta y establece tu billetera principal como dirección principal. Cualquiera puede realizar la implementación; por lo tanto, puede recibir fondos del protocolo o del proveedor de tu billetera.

• Envíe el hash de la operación del usuario que desea enviar al puente de bandeja de entrada en su L2 y configure el ID de la cadena de destino.

• Este hash se agrupa con otros hashes y se envía a la capa 1. El contrato inteligente en la capa 1 reenvía este paquete a la capa 2 de destino y el puente de la bandeja de entrada desagrupa los hashes para que las minicuentas puedan leerlos.

• El remitente agrega una pequeña tarifa a su hash para incentivar a los iniciadores de las transacciones en los contratos inteligentes del protocolo.

• Cuando el hash llega a la capa 2 de destino, envías tu operación de usuario al mempool AA en esta capa 2. Al utilizar el estándar ERC-4337, no tenemos que volver a implementar nuestro propio mempool de minicuentas y el protocolo se puede integrar fácilmente en billeteras con una base de código ya existente.

  
  

En pocas palabras, iba a crear un puente basado en L1 que envía transacciones desde la billetera inteligente en tu L2 a cualquier L2 con la que quieras interactuar. Terminé casi implementándolo en el hackathon, pero no pude terminarlo debido a que tenía poca experiencia y trabajaba solo. Después de explicárselo a mi amigo, me preguntó:

¿Por qué uno no cambia simplemente la red en su billetera y usa puentes de tokens para mover los fondos necesarios a la red necesaria?

Respondí : Esta es una opción absoluta si se utiliza una billetera EOA. Las billeteras EOA actúan de la misma manera en todas las redes EVM y comparten la misma dirección, por lo que se pueden enviar transacciones en todas ellas con solo cambiar la red en la configuración de la billetera.

Sin embargo, el área está migrando a cuentas inteligentes basadas en abstracción de cuentas. Estas cuentas nos permiten agregar cualquier funcionalidad que queramos a nuestras billeteras de manera programática:

• Las firmas P256 hacen posible utilizar chips seguros en nuestros teléfonos para firmar transacciones.

• A través de la recuperación social, podemos sumar a nuestros familiares como tutores autorizados para recuperar nuestras billeteras, eliminando frases semilla inseguras.

• La tecnología Paymaster nos permite pagar la tarifa del gas con cualquier token o incluso hacer que alguien pague la tarifa por nosotros .

• Cuando las computadoras cuánticas comiencen a romper los esquemas de firma clásicos, podremos simplemente cambiar el esquema en nuestras billeteras AA a uno cuánticamente seguro sin crear una nueva billetera.

  
  

Esta lista podría continuar indefinidamente, ya que la abstracción de cuentas esencialmente nos permite usar programas ejecutables como billeteras completas. Pero todo esto tiene un costo: uno no puede migrar fácilmente sus billeteras a otra cadena porque, además de mover los fondos a través del puente, requiere volver a implementar la cuenta completa con todas las claves, guardianes y configuraciones. En algunos casos, esto puede ser demasiado complicado o incluso imposible; por ejemplo, en rollups que no admiten la precompilación P256 (este esquema de firma puede ser demasiado costoso de usar).

Por eso creé ese protocolo. Básicamente, tienes cuentas AA en muchas L2. Para enviar una transacción desde ellas, debes verificar tu intención enviando un hash de la misma desde tu cuenta principal en una L2 específica a esas "minicuentas" a través de la mensajería del puente L1. De hecho, de esta manera, no te deshaces de múltiples billeteras; simplemente mueves toda la lógica de verificación a una sola cuenta "principal".

Otro detalle interesante de un protocolo de este tipo es que permite la interoperabilidad no solo con las L2, sino con todas las L1 (cadenas laterales) que tienen puentes consagrados con Ethereum (se me ocurren Polygon PoS, Ronin, Gnosis y Avalanche). Sin embargo, fue diseñado como un protocolo de interoperabilidad centrado en la acumulación , por lo que este es solo un dato tecnológico divertido.

Si bien la idea del proyecto era bastante inteligente, la implementación práctica tenía un inconveniente importante: la velocidad . Todo el diseño se basa en puentes rollup canónicos conectados a Ethereum L1. Los puentes rollup son peculiares porque prueban su estado a sus contratos inteligentes en Ethereum para heredar su seguridad. Como ya sabrás, la verificación optimista y ZK son las dos formas más populares de hacer esto.

La verificación optimista funciona abriendo una “ventana de desafío”, generalmente de unos siete días, en la que los retadores pueden enviar una prueba de fraude que señale cualquier parte no válida del lote de transacciones. Si esta prueba es válida, el rollup reorganiza su blockchain para eliminar este lote. Después de siete días sin pruebas de fraude, el lote se considera automáticamente válido y todos los mensajes y retiros se finalizan en Ethereum.

Probablemente ya lo hayas deducido. Debido a un retraso de siete días en la mensajería a L1, enviar transacciones entre cadenas desde un rollup optimista es una idea terrible . ¿Por qué? Bueno, ¿esperarás una semana para tu intercambio de DEX? ¿Qué va a pasar con el precio en ese momento?

Es mucho mejor enviar transacciones entre cadenas al Optimist Rollup. Aunque el secuenciador de OP Stack espera unos pocos bloques antes de procesar el mensaje para minimizar la posibilidad de reorganizaciones, esperar unos minutos para recibir la transacción ya es algo aceptable para algunas tareas.

Además, la comunidad Ethereum está trabajando actualmente en la finalización de una sola ranura , que hará que cada bloque se finalice por separado, lo que los hará irreversibles para el siguiente bloque. Una vez que se implemente, la mensajería de L1 a L2 tardará unos 12 segundos.

Sería mejor alojar dichas cuentas en paquetes ZK, pero aún no es muy útil. Como podemos ver en las estadísticas a continuación, ZKsync Era finaliza en 21 horas, Linea en 5 horas, Starknet en 9 horas, etc.

Pero ¿por qué es así? ¿No es rápida la generación de pruebas ZK en clústeres potentes? En resumen, hay dos problemas:

• Algunas acumulaciones de ZK, como ZKsync Era, establecen retrasos en la ejecución para que el consejo de seguridad tenga tiempo de revertir algunos lotes en caso de un error en su sistema de prueba. Los zkEVM son piezas de tecnología realmente complicadas y, debido a esta complejidad, prevenir errores de manera probabilística mediante el uso de múltiples sistemas de prueba a la vez aún no es factible.
• Aunque la verificación de prueba de ZK es muy liviana en comparación con los cálculos que prueba, verificarla en la cadena sigue siendo bastante costoso. Dependiendo del sistema de prueba, puede requerir hasta un millón de gas por verificación. Si tomamos el precio promedio del gas de 9 gwei y los precios actuales de ETH, una sola prueba cuesta alrededor de $30 solo para la verificación en L1.
  • Los rollups ZK modernos minimizan estos gastos al generar una prueba para muchos lotes una vez cada cierto tiempo, pero esto reduce la velocidad de finalización del puente. Generar un lote y probarlo en cada bloque genera $30 por bloque o $216,000 por día . A 100 TPS, esto es aproximadamente $0.025 por transacción solo por costos de verificación. ¡Y también tenemos que generar la prueba y publicar el lote en la cadena!

Esperar una o dos horas para realizar una transacción sigue siendo demasiado tiempo. ¿Qué podemos hacer al respecto?

En primer lugar, olvidemos mi proyecto de hackathon de ocho meses de antigüedad e intentemos eliminar el modelo mental de que cada transacción debe iniciarse desde nuestra billetera inteligente principal. ¿Por qué necesitamos compartir la lógica de nuestra billetera inteligente en cada acumulación? ¿Por qué no generamos simplemente EOA temporales, conectamos los fondos desde nuestra billetera inteligente principal allí, hacemos algún trabajo que queremos hacer y conectamos lo que queda?

Mi Clave (o cualquier billetera inteligente que estés usando) tiene firma Secure Enclave y recuperación social, por lo que siempre puedo estar seguro de mis fondos allí, incluso si pierdo mi teléfono. ¿Y a quién le importa lo que pase con esas cuentas temporales? Ya hice lo que tenía que hacer con ellas; todos los fondos están ahora en mi Clave.

Sin embargo, este enfoque tiene un problema fundamental: la suposición de que no se puede usar la misma billetera en otras cadenas de manera regular restringe en gran medida la cantidad de tareas que se pueden realizar en ellas. Por ejemplo, no se puede:

• Crea un depósito en una plataforma de préstamos local porque no puedes migrarlo a tu red principal (ZKsync Era en este caso)
• Obtenga tokens que no tengan un equivalente fungible en su red principal (por ejemplo, si se acuñan de forma nativa en esa red)
• Participa en una DAO local porque tus votos deben permanecer en esa cuenta temporal.

Básicamente, todo lo que puede hacer como usuario es dispersar fondos a múltiples destinatarios sin tener que hacer un puente cada vez y obtener una mejor liquidez para un intercambio a un token que pueda conectarse de nuevo a su cadena principal.

Por lo tanto, para que estas billeteras sean útiles, tenemos que acceder a ellas utilizando las mismas reglas que utilizamos en nuestras billeteras inteligentes principales: enclaves seguros, recuperación social, etc. Así que volvemos a la idea anterior y a su inviabilidad. Sin embargo, existe un paliativo factible que puede otorgar a estas minicuentas solo las propiedades de recuperación de nuestra billetera principal:

Creamos las mismas minicuentas descritas anteriormente, pero permitimos que una clave envíe transacciones directamente desde ellas. Nuestra billetera principal ahora puede cambiar esta clave a través del puente basado en L1 o hacer que la minicuenta la lea desde el estado L2 de la billetera principal. De esta manera, si se pierde la clave temporal, la billetera principal puede iniciar un cambio de clave a través del puente basado en L1, lento pero atómico.

Atomicidad: propiedad de una acción que no permite que falle durante su ejecución. O bien no se inició, o bien se realizó. Los puentes basados en L1 son atómicos porque el mensaje no se puede perder si se envía. El orden, la disponibilidad y la autenticidad están garantizados por la L1 de Ethereum.

¡Esto es mucho mejor! Ahora, las transacciones ordinarias solo toman tiempo para el puente de tokens. Una vez que los tokens están en el destino, el envío de transacciones es tan rápido como si fuera tu cadena principal. Si pierdes la clave, tendrás que esperar desde varias horas hasta siete días, dependiendo de la cadena de tu billetera principal, pero no la usarás muy a menudo, por lo que la compensación es aceptable para la mayoría de los casos de uso. Además, es factible implementarlo en billeteras incluso hoy. Incluso hice mi propia implementación , pero no es de ninguna manera segura ni lista para producción y está destinada solo a fines de visualización.

En las plataformas de negociación de futuros Web3 se utiliza una técnica similar: se aprueba el token en par (normalmente USDC) al contrato inteligente y se asigna una clave temporal para el gasto, que se almacena en el frontend de la plataforma. Esto permite a los usuarios realizar acciones rápidas sin tener que firmar cada acción con su billetera principal. Si cambia de dispositivo o borra los datos de su navegador, puede simplemente reasignar la clave utilizando su billetera principal.

Pero, como ocurre con todo lo relacionado con las criptomonedas, este enfoque tampoco es perfecto. Tiene dos desventajas:

• Si bien las minicuentas pueden cumplir con la norma ERC-4337 y, por lo tanto, admitir todas sus funciones, como procesamiento por lotes, pagadores, límites de gastos, etc., estas funciones ya no se heredan de la cuenta principal. De hecho, la cuenta principal solo actúa como un único guardián de recuperación social para la minicuenta, pero el guardián es el propio usuario.
• El puenteo de tokens debe realizarse mediante puentes externos. Con la iniciación de transacciones entre cadenas, podemos llevar nuestros tokens con el mensaje, recibiéndolos prácticamente 1:1 de forma atómica. Sin embargo, con esta solución, esto ya no es una opción, por lo que el puenteo externo es la única opción rápida que queda.

Aunque los puentes modernos pueden transferir fondos en unos pocos segundos , a) cobran una tarifa que puede llegar a ser muy alta en transferencias grandes , b) no son atómicos y no heredan las propiedades de seguridad de Ethereum. Es particularmente importante tomar nota sobre las propiedades de seguridad de los puentes de blockchain .

El uso de puentes externos para transferir tokens es algo aceptable, a diferencia de su uso para pasar mensajes para operar minicuentas. La razón es que en sus peores casos, probablemente debido a un ataque contra ellos:

• En el puente de tokens, lo peor que puede pasar es que no recibas los tokens que enviaste. En ese caso, perderás X tokens que querías puentear y cambiarás a otro puente.
• En la mensajería entre cuentas, lo peor que puede pasar es que te roben todas tus minicuentas al pasar mensajes de suplantación de identidad a través del puente. En ese caso, pierdes tus billeteras en todas las cadenas con todo su valor, excepto la principal.

Por lo tanto, depender de puentes externos para la conexión de tokens es prácticamente una opción siempre que no se cuente con una forma eficiente de conectarlos de manera atómica utilizando L1. De hecho, esta es la opción que utilizan muchos usuarios que interactúan con cadenas de acumulación en la actualidad.

Supongamos que queremos validar todas las transacciones en un único lugar, por ejemplo, para transferir tokens de forma nativa entre cuentas o verificar firmas con una precompilación única. En ese caso, nos enfrentamos a la lenta finalidad de los rollups de ZK actuales. Volvamos un momento a pensar en qué se puede mejorar con la técnica anterior.

¿Por qué los rollups tienen una finalidad de puente lenta? Tomaremos los rollups ZK como objetivo porque, con los optimistas, la razón ya es evidente:

• Los sistemas de prueba ZK para entornos de VM completos son complicados, especialmente si el entorno no es compatible con ZK (EVM). Por lo tanto, existe una gran posibilidad de que contengan errores. Los sistemas de prueba múltiples pueden evitar esto, pero son muy complicados de implementar y generar múltiples pruebas para un solo lote puede ser demasiado lento y costoso. Como solución alternativa, los equipos de rollup habilitan demoras en la ejecución, lo que les permite revertir la cadena en caso de emergencia. Esto es lo que ralentiza la finalización del puente en algunos rollups (por ejemplo, ZKsync Era).
• Proponer el nuevo estado y probárselo a L1 son tareas bastante costosas, por lo que, para minimizar los costos, los secuenciadores rollup lo hacen cada pocas horas en lugar de cada bloque.

Sin embargo, hay una excepción: Scroll propone el estado aproximadamente cada minuto , pero a) la verificación de pruebas todavía se realiza cada pocas horas, por lo que permanece sin verificar, y b) Scroll es uno de los rollups más costosos de usar en la actualidad.

Si lo reformulamos de forma más sencilla, los problemas son demostrar los costos y verificarlos. Veamos cada problema y las formas de resolverlo.

Básicamente, nuestra tarea es hacer que nuestra billetera inteligente en un rollup interactúe rápidamente con otras rollups sin suposiciones de confianza adicionales que aportan los puentes externos. Las billeteras inteligentes suelen constar de algunas características AA habituales (pagadores, recuperación social, enclaves seguros, límites de gasto, etc.) y la operación principal que nos permite enviar transacciones en cadena desde ella.

¿Por qué necesitamos la operación principal si queremos usar los otros rollups de nuestra billetera? Porque probablemente esté alojada en un rollup multipropósito (Arbitrum, Base, ZKsync Era) y también queremos interactuar con los usuarios y los contratos inteligentes en este rollup.

En este caso particular, tendría sentido simplemente utilizar puentes de token externos. Basta con reemplazar la tarea con, por ejemplo, la interacción con una dApp en el mismo rollup y otra.

Esta multipropósito es lo que introduce complejidad al sistema de prueba de los rollups. Verificar el estado de toda la máquina virtual con muchos contratos inteligentes y transacciones que ocurren cada segundo es una tarea bastante difícil. Queremos ejecutar dos tipos de tareas que requieren un conjunto completamente diferente de características en el rollup: para una transacción en cadena, es una inclusión rápida de L2, tarifas bajas de L2 y una amplia funcionalidad de VM, y para una transacción de múltiples rollups, es una finalización rápida del puente.

Pero ¿qué sucede si simplemente nos deshacemos de la máquina virtual y creamos un paquete acumulativo que solo pueda manejar cuentas inteligentes y mensajes a las otras L2? Vitalik Buterin propuso una técnica similar casi al mismo tiempo que Devconnect Istanbul llamada “paquetes acumulativos de almacenes de claves”. Analizaremos esto a continuación.

Resumen de almacenes de claves

La idea es crear un conjunto de claves ZK que solo pueda almacenar las claves de cuenta y cambiarlas utilizando otra clave. Este conjunto de claves envía la raíz del árbol Merkle que contiene todas estas claves a L1. Luego, cuando desee enviar una transacción desde una de sus cuentas inteligentes en L2, generará la prueba Merkle de su clave actual y su cuenta la verificará con la raíz del almacén de claves disponible en L1. Ahora, conoce su clave y puede usarla para verificar sus firmas.

Este tipo de acumulación es muy simple y se pueden implementar fácilmente múltiples sistemas de prueba, por lo que las claves almacenadas en él son en realidad tan seguras como la L1.

Además del diseño original de Vitalik, existen tres diseños principales para acumulaciones de almacenes de claves:

• El enfoque de Scroll es almacenar datos del almacén de claves en L1 pero permitir su actualización desde su paquete acumulativo zkEVM. Para ello, están introduciendo una precompilación L1SLOAD que permite lecturas económicas del almacenamiento L1. Luego, las cuentas AA en otras L2 pueden leer estos datos para sincronizar su configuración (claves, guardianes, etc.).
• El equipo base está explorando una técnica en la que solo se almacena la raíz del estado en L1, pero las transacciones se secuencian utilizando calldata, de modo que el árbol siempre se puede reconstruir. Se espera que las cuentas en L2 obtengan claves actuales utilizando pruebas de Merkle.
• El diseño de Stackr es muy similar al de Base o Vitalik, pero utiliza su propio marco de “micro-rollups” con máquinas virtuales mínimas especializadas.

En términos generales, difieren en la cantidad de tareas delegadas al procesamiento fuera de la cadena (en otras palabras, cuántas cosas hay en L2) y sus detalles de implementación.

Podemos ampliar esta idea aún más manejando no solo las claves sino también toda la lógica de la cuenta inteligente . Esto tampoco sería mucho más difícil computacionalmente; básicamente, solo necesitamos manejar estas tareas:

• Envío de datos a L1: las cuentas en el conjunto de claves deben poder notificar a L1 sobre su intención de transacción. No es necesario almacenar toda la transacción en L1; algo como una raíz de un árbol Merkle con todos los hashes de las operaciones del usuario sería suficiente. Luego, todo lo que se necesita para enviar una transacción desde una minicuenta es leer la raíz desde la L2 de destino y demostrar que una determinada operación AA realmente se solicitó desde la cuenta principal.

• Comprobaciones de firma: el usuario firma el hash de la operación de usuario que desea ejecutar en un determinado rollup. El rollup del almacén de claves verifica la firma para demostrar la intención y agrega el hash al árbol para luego enviarlo a la capa 1. Algunos esquemas de firma, como ECDSA , P256 y los de seguridad cuántica , son suficientes.

• Recuperación social: Hacer que las otras cuentas elegidas a propósito, llamadas “guardianes”, voten por el cambio de clave en la cuenta del usuario. El usuario puede establecer los guardianes y el umbral y solicitarles la recuperación en caso de pérdida de clave. También podemos implementar la recuperación basada en veto o esquemas de guardianes alternativos como ZK-Email , ZK-OTP o Web Proofs para expandir la recuperación social más allá de los usuarios del rollup.

• Reglas de gasto: en caso de robo de la billetera, las reglas de gasto controladas por los tutores pueden reducir en gran medida las posibles pérdidas antes de que el usuario recupere la billetera. Esta función también es útil para ahorrar fondos o, por ejemplo, para crear billeteras para niños: los padres pueden enviar una asignación y restringir cuánto se puede gastar para que el niño aprenda a ahorrar.

• Saldos de tokens: esto puede parecer innecesario, pero poder almacenar criptomonedas dentro del almacén de claves aumenta drásticamente la seguridad de los activos de los usuarios al no separarlos en múltiples minicuentas. Además, permite muchas funciones que mejoran la experiencia del usuario:

• Pagadores: el rollup puede ofrecer transacciones gratuitas para atraer nuevos usuarios o permitirles pagar la tarifa con cualquier token en lugar de solo ETH. También se puede implementar una lógica de pagador más complicada; por ejemplo, el secuenciador puede cobrar una tarifa del intercambio en otra cadena cuando se conecta de nuevo al rollup del almacén de claves.

• Transferencias internas de tokens: además de enviar fondos de manera instantánea entre usuarios de la acumulación, las transferencias directas también son útiles para implementar puentes basados en intenciones con otras acumulaciones que tienen una finalidad demasiado lenta para usar L1 para hacer un puente desde la minicuenta a la cuenta principal en la acumulación de almacén de claves. De esta manera, la acumulación de almacén de claves puede actuar esencialmente como un centro para transferir tokens entre minicuentas en docenas de L2 diferentes de manera económica.

  
  

Un sistema de este tipo es mucho más simple técnicamente que una máquina virtual completa dentro de un paquete acumulativo, por lo que es posible generar pruebas para múltiples sistemas de pruebas simultáneamente, y la complejidad de la generación de pruebas seguirá siendo mucho menor.

Sin embargo, la verificación de pruebas sigue siendo un problema. Como hemos calculado antes, el coste del gas puede ser de hasta 1 millón de gas o de 25 a 50 dólares, dependiendo del precio del gas. Este coste es fijo y no depende de la cantidad de transacciones del lote. Esto significa que, si hay muy pocas transacciones, la tarifa por cada transacción puede ser muy alta. Hay dos formas principales de reducir este coste:

Capa alineada

Aligned es un AVS de EigenLayer que utiliza operadores de resttaking para verificar las pruebas ZK de forma económica. Si no está familiarizado con EigenLayer, este es un resumen simplificado de cómo se verifican las pruebas en Aligned:

• Un usuario envía la solicitud de verificación de prueba a la red y paga la tarifa por ella;

• Los operadores alineados, cada uno de los cuales es un validador de Ethereum con sus depósitos vinculados, verifican la prueba en sus nodos y firman su validez;

• Cuando 2/3 operadores firman la prueba, la firma agregada se envía y verifica en Ethereum L1.

• Si una prueba no válida ha llegado a su fin, los validadores que la firmaron pueden ser eliminados al verificarla en cadena. De esta manera, la prueba obtiene una seguridad económica equivalente a 2/3 de la participación total de los operadores alineados.

  
  

Este enfoque tiene un inconveniente obvio: Ethereum ya no garantiza la validez de la prueba. Si el TVL del puente del rollup es superior a 2/3 del total de la participación de Aligned, atacarlo se vuelve rentable. Y como estamos hablando de la latencia de finalidad de 1-2 bloques, no podemos prevenir el ataque de manera optimista.

Sin embargo, esta podría ser una opción relativamente segura siempre que la acumulación no sea demasiado grande. Cuando lo sea, la demanda de transacciones podría hacer que valga la pena la verificación de prueba L1. Según los documentos, verificar la prueba ZK usando Aligned cuesta alrededor de 3000 gas, lo que es casi gratis incluso para Ethereum L1.

Capas de agregación de pruebas

Si no se siente cómodo introduciendo suposiciones de confianza adicionales en el sistema, o su protocolo ya se ha vuelto demasiado grande, pero su demanda de transacciones no, existe una alternativa.

Los equipos de ZK y de rollup han comenzado recientemente a trabajar activamente en protocolos de agregación de pruebas. Si no estás muy familiarizado con ZK, la agregación de pruebas es cuando una prueba de ZK prueba la validez de otra prueba de ZK (que, a su vez, puede probar otra prueba, y así sucesivamente), "agregándolas" así en una única prueba y, esencialmente, trasladando todos sus costos de verificación a costos de prueba. Lo que queda es verificar una única prueba de ZK en cadena y estar seguro de la validez de todas las demás pruebas de ZK que prueba. ¡Uf!

Verificación en cadena de prueba ZK.

La agregación de pruebas tiene sentido cuando los costos de verificación son más altos que los de probar la agregación de pruebas. Es decir, la agregación se vuelve rentable si el costo de generar una prueba para diez pruebas y verificarla es menor que verificar estas diez pruebas de forma independiente. Esto es aún más útil en Ethereum L1, que está muy restringido por la capacidad computacional. Dependiendo del sistema de prueba, el bloque completo solo puede contener alrededor de 100 verificaciones de prueba , excluyendo todas las demás actividades en cadena.

Generalmente, existen dos tipos de protocolos de agregación de pruebas:

• Agregación de propósito general (universal): estos proyectos suelen admitir varios de los protocolos ZK más populares (Groth16, Halo2, Plonky), sobre los cuales se construyen la mayoría de los circuitos ZK y cobran una tarifa por su procesamiento. Las aplicaciones descentralizadas que necesitan las pruebas luego revelan los datos del protocolo y los procesan por su cuenta. El sistema de agregación de pruebas universal de Nebra , actualmente en desarrollo, hace exactamente esto. Aligned también está trabajando en la llamada verificación de "modo lento" , que, de hecho, también es un sistema de agregación de pruebas.
• Agregación de puentes de acumulación compartidos: de manera similar a la secuenciación compartida en acumulaciones optimistas, las acumulaciones ZK con sus pilas funcionan en puentes compartidos con pruebas de estado agregadas para cada acumulación ZK en el puente. Esto no solo permite la componibilidad sincrónica dentro de la pila al estilo de la secuenciación compartida, sino que también minimiza los costos de verificación de pruebas. Es posible que haya oído hablar de AggLayer de Polygon o Hyperbridge de ZKsync, que son puentes de acumulación compartidos que funcionan en la agregación de pruebas dentro del puente.

Las ventajas de los sistemas de agregación universales son que son independientes del proyecto y solo se especializan en el proceso de agregación en sí, lo que permite una verificación de pruebas bastante rápida y costos bajos. Además, es probable que no tengan rueditas de entrenamiento debido a la falta del componente puente.

Los puentes de agregación de claves, a su vez, son útiles para que la acumulación de claves tenga capacidad de composición sincrónica con una pila de acumulación ya existente. Por ejemplo, según L2BEAT , actualmente se crean 13 proyectos utilizando Polygon CDK y 11 utilizan ZK Stack. Cuando todos se conectan a un puente de agregación de pruebas compartidas, conectar la acumulación de claves a uno de ellos abrirá una interacción sin problemas con muchas L2 sin siquiera tocar la L1. Para que esto funcione, el puente debe admitir una lógica de transición de estado diferente para sus L2 porque la lógica de la acumulación de claves difiere de las otras L2 que contiene.

Sin embargo, estos puentes suelen ser actualizables y controlados por su DAO o consejo de seguridad. Es posible que los proyectos de acumulación de almacenes de claves no se sientan cómodos con ceder su soberanía a los operadores del puente al que están conectados. Además, los puentes pueden introducir retrasos en la ejecución como precaución de entrenamiento, de forma similar a cómo funciona ZKsync Era ahora, lo que básicamente acaba con toda la eficiencia de este diseño de acumulación de almacenes de claves.

De esta manera, los paquetes acumulativos de almacén de claves, como cualquier otro paquete acumulativo de ZK, pueden minimizar los costos de verificación de pruebas e incluso combinar esto con capacidad de composición sincrónica con una pila de paquetes acumulativos ya existente.

Puentes eficientes basados en intenciones con acumulaciones de “Keystore+”

Como se mencionó anteriormente, el puente de L2 a L1 no es el único problema. La mayoría de los secuenciadores de rollup también aplican demoras al pasar mensajes de L1 a L2. Esto se debe a que cuando se crea un bloque de Ethereum, aún no es definitivo y se puede revertir dentro de los siguientes ~64 bloques (dos épocas, aproximadamente 13 minutos). Estas reorganizaciones ocurren debido a las latencias de la red, lo que hace que algunas propuestas aparezcan en la red demasiado tarde cuando algunos nodos ya las consideran perdidas.

Aunque la mayoría de las reorganizaciones no son más profundas que dos bloques (una reorganización de siete bloques incluso apareció en las noticias hace dos años) , los equipos de rollup aún no quieren correr riesgos relacionados con mensajes perdidos y aplican demoras al puenteo desde L1. Estas demoras son de solo 1 minuto en algunas rollups ( OP Stack , ZK Stack ), pero pueden ser de hasta 6 minutos, como en Arbitrum , o incluso solicitar la finalidad de L1, como en Linea .

La comunidad de Ethereum está trabajando activamente en la Finalidad de Ranura Única , que hará que cada bloque se finalice de forma independiente en lugar de una vez en una época. Pero podemos decir con certeza que no está previsto para la próxima actualización de Pectra que llegará en el primer trimestre de 2025, por lo que pasará al menos un año antes de que se implemente la Finalidad de Ranura Única.

Si un equipo que implementa este diseño de acumulación de almacén de claves extendido no se siente cómodo con esa latencia de transacciones, puede implementar un paliativo descrito anteriormente. Cada minicuenta tiene una clave autorizada para enviar transacciones o utiliza una clave estática del almacén de claves (según el diseño original de Vitalik), pero la administración de la cuenta aún está en la cuenta del almacén de claves principal. Una vez que se implementa SSF en L1, la acumulación puede eliminar las claves de gasto autorizadas y los usuarios obtendrán toda la funcionalidad de personalización de AA sin una degradación significativa de la velocidad.

Estoy de acuerdo con Alex en esto: 15 segundos de latencia son absolutamente aceptables, especialmente porque la operación es atómica después de que se finaliza la transacción de acumulación de claves en L1. Si hablamos de transferencias de tokens, las billeteras de los destinatarios pueden incluso implementar un estado "Pendiente" en el nivel de la interfaz de usuario.

Sin embargo, las transferencias de tokens entre acumulaciones aún presentan un problema. Si implementamos bóvedas de tokens dentro de la acumulación de claves, la transferencia de tokens desde allí demorará entre 1 y 15 minutos, según la acumulación de destinatarios. Si no lo hacemos, dividir los saldos de los usuarios en minicuentas en múltiples L2 puede plantear riesgos de seguridad e incluso bloquear algunos activos en L2 ilíquidos, lo que puede costar demasiado o llevar demasiado tiempo.

Como alternativa, podemos integrar un puente basado en intenciones en el paquete acumulativo e implementarlo en todos los demás paquetes acumulativos o incluso reutilizar la infraestructura existente, como los protocolos compatibles con ERC-7683 . Analizaremos brevemente los puentes basados en intenciones en la siguiente sección.

¿Qué es un puente basado en intenciones?

La mayoría de los puentes entre cadenas existentes se basan en protocolos de mensajería. Por ejemplo, Stargate utiliza LayerZero para pasar mensajes sobre depósitos a las cadenas de destino, basándose en este como fuente de confianza. Cuando envías tokens a través de estos puentes, bloquean tus tokens en un lado y envían un mensaje sobre tu depósito en el otro lado, y la bóveda allí desbloquea la cantidad respectiva de tokens para ti.

Los puentes basados en intenciones , a su vez, no envían mensajes entre dos cadenas. En cambio, los fondos que se envían se bloquean en la bóveda como una "orden entre cadenas" y, luego, cualquiera puede completar la orden enviando la cantidad solicitada de tokens en la cadena de destino. Quien complete la orden puede reclamar los tokens bloqueados de la cadena de origen cuando la bóveda que se encuentra en ella recibe información sobre el estado finalizado de la cadena de destino y puede confirmar la transferencia.

Esto puede suceder ya sea esperando la finalización del objetivo (puente) de la cadena de destino o a través de algún protocolo oráculo externo. Por ejemplo, Across utiliza el oráculo optimista de UMA para obtener el estado de las capas 2 que aún no se han finalizado.

En este escenario, se utiliza Ethereum L1 como fuente de confianza. Algunos protocolos, como Across, utilizan oráculos externos en su lugar. El diseño real puede diferir en los proyectos existentes; solo se muestra la idea general.

Podemos utilizar el mismo diseño para estos paquetes de almacenamiento de claves ampliados para implementar un puente bidireccional sin confianza, rápido y económico entre el almacenamiento de claves y todas las demás capas 2. La finalidad del puente rápido permite que los pedidos basados en intenciones de las otras capas 2 sean casi gratuitos porque demostrar el cumplimiento en la capa 2 solo lleva unos minutos.

Los pedidos desde el almacén de claves probablemente también serán baratos, ya que la liquidez en la capa 2 se puede suministrar con relativa rapidez a través del almacén de claves. De esta manera, el diseño de este tipo de acumulación de almacén de claves puede convertirse en un centro para la creación de puentes basados en intenciones, lo que permite a los usuarios enviar transacciones instantáneamente en lugar de en unos pocos minutos, pagando casi nada por la creación de puentes. El equipo de acumulación también puede proporcionar liquidez para la creación de puentes a través del almacén de claves 1:1, y esto no les costaría mucho.

Nombre ENS unificado para todas las cadenas

Imagina tener un único nombre de usuario .eth que se resuelva en todas tus minicuentas, sin importar en qué cadena se encuentre el destinatario. Este diseño lo hace posible. ¿Cómo?

Como ya conocemos la dirección de nuestra cuenta de almacén de claves principal, podemos usar fábricas multicadena y CREATE2 para que las direcciones de nuestras minicuentas sean las mismas en todas las cadenas EVM equivalentes a bytecode, incluso en Ethereum L1. Luego, configuramos la dirección unificada en el solucionador ENS y nuestro nombre funciona en todas las EVM L2.

Sin embargo, hay dos casos excepcionales:

• EVM no equivalentes a bytecode, como ZK Stack. Para ellos, podemos generar una dirección personalizada según sus reglas CREATE2 y agregarla al ENS con sus identificadores de cadena según ENSIP-11 .
• L2 que no son EVM, como nuestro almacén de claves. La lógica es la misma para ellos, pero en su lugar, agregamos sus direcciones personalizadas al ENS de acuerdo con ENSIP-9 .

Si bien es muy amigable con la experiencia del usuario, este enfoque utiliza una gran cantidad de computación y almacenamiento costosos en L1 porque los nombres y las direcciones se almacenan en los solucionadores de L1. Este problema se puede resolver usando CCIP Read , pero se me ocurrió otra lógica de resolución en cadena más eficiente:

Cada cuenta del almacén de claves se registra e indexa por el hash de nombre de su nombre ENS (registrado bajo un único nombre ENS con un solucionador personalizado). Cuando se resuelve su subdominio, el contrato del solucionador verifica si la cuenta con dicho hash de nombre existe en el resumen y utiliza el hash de nombre para generar direcciones de minicuentas basadas en CREATE2 .

Cuando se implementan, solicitarán a L1 los datos del almacén de claves que pertenecen al hash de nombre con el que se implementaron. Puede ser la intención de transacción en sí o solo la clave de firma actual, según la implementación del almacén de claves. De esta manera, obtenemos cuentas de almacén de claves, cada una con un nombre de ENS que se resuelve en sí misma y sus minicuentas en cada acumulación. Estas minicuentas, a su vez, también dependerán de este nombre de ENS al validar la transacción mediante la acumulación de almacén de claves.

**

Mecanismos de secuenciación en los rollups “Keystore+”

Como se supone que la finalidad del puente en el conjunto de claves extendidas debe ser de unos pocos bloques L1, también podemos deshacernos de los secuenciadores centralizados por completo y convertirlo en un conjunto basado. Como hemos comentado antes, una velocidad de transacción de ~12 segundos es aceptable para el usuario promedio, pero la secuenciación basada haría que el conjunto fuera mucho más resistente a la censura y a los puntos únicos de falla.

Vale la pena considerar que, con la secuenciación basada en datos, las transacciones internas demorarán tanto como las externas (sin contar el tiempo necesario para llegar a L2). Esto puede resultar inaceptable para algunos equipos, ya que la secuenciación centralizada hace que todas las operaciones internas sean instantáneas.

Soluciones alternativas de interoperabilidad de rollup o: Por qué no mencioné la secuenciación compartida

Escribí todo el artículo sobre los rollups ZK y la tecnología ZK. Esto se debe a que los rollups optimistas no pueden tener fundamentalmente una finalidad objetiva rápida, y dicha propiedad solo se puede alcanzar utilizando ZK. Los rollups optimistas de hoy comprenden su posición sellada y están investigando activamente la viabilidad de integrar diseños centrados en la validez en sus pilas, de ahí, por ejemplo, la reciente asociación de Optimism y RISC Zero .

El diseño optimista es fundamentalmente restrictivo, ya que nunca podrá manejar la interoperabilidad con otros rollups. Sin embargo, la interoperabilidad dentro del ecosistema optimista se está desarrollando rápidamente. La tecnología principal para hacer que los rollups optimistas sean interoperables entre sí es la secuenciación compartida . En pocas palabras, se trata de un mecanismo mediante el cual un secuenciador puede crear un lote para varios rollups simultáneamente. Si alguna transacción en cualquiera de los rollups secuenciados no es válida, se puede disputar y revertir todo el lote.

Esto otorga a todos los lotes de este “megalote” la propiedad atómica (o todos los lotes son válidos o ninguno). Esto, a su vez, permite la componibilidad sincrónica atómica dentro del lote. Atómica (porque nada en el lote puede ser inválido si es válido) y sincrónica (porque todos los mensajes están dentro del lote, que es procesado simultáneamente por todos los nodos de sus acumulaciones).

Esta tecnología básicamente convierte todos los rollups en una determinada pila optimista en un gran rollup fragmentado. ¿Por qué solo una pila y no todas? Porque para que esto funcione, los rollups deben estar conectados a un solo puente. Cada pila tiene su propio puente y no hay una forma confiable de crear lotes en varios puentes simultáneamente. Esto significa que la secuenciación compartida permite que OP Mainnet interopere sin problemas con Base y Zora, pero no con Arbitrum o Metis, y viceversa.

Esta consolidación crea una situación peligrosa en el ecosistema de rollups. Los nuevos rollups tienen la opción de unirse a la pila existente e integrarse con ella, pero no con nadie más, O construir sobre ZK e integrarse con cualquiera, excepto con la pila anterior. No existe tal opción ahora porque la secuenciación compartida aún no está disponible, y cada rollup de OP Stack o Arbitrum Orbit es independiente, con su propio puente. Sin embargo, cuando se consoliden, formarán dos organismos sólidos dentro del ecosistema, cada uno con aproximadamente el 40% del TVL total de L2 .

"Está bien. Si ellos tienen la gran mayoría del total de TVL, ¿por qué no nos deshacemos de ZK y construimos sobre ellos?"

En primer lugar, los secuenciadores compartidos son un gran impulsor de la centralización. Si ejecuta un secuenciador de la red principal de OP, sus lotes no incluirán transacciones de otros conjuntos de transacciones en la pila; ganará menos en comisiones y, con el tiempo, quedará eclipsado por los grandes secuenciadores comerciales que pueden manejar toda la pila en sus lotes.

Sin embargo, el problema más crítico es que, en tal caso, el ecosistema de rollup queda encerrado en imperios oligopólicos que persiguen sus propios intereses, buscan establecer un mayor control sobre el capital y se muestran reticentes al progreso tecnológico en el ecosistema. Entonces tendríamos que lidiar con el hecho de que Ethereum queda aplastado en un área disjunta donde lo que importa son las relaciones públicas y la lucha intraespecífica, no las tecnologías que realmente cambian el mundo.

“Construyamos herramientas, no imperios . Los imperios intentan capturar y atrapar al usuario dentro de un jardín amurallado; las herramientas cumplen su función, pero por lo demás interactúan con un ecosistema más abierto.”— Vitalik Buterin

“¿En qué sentido la agregación de puentes compartidos en ZK es mejor que la secuenciación compartida optimista?”

En los puentes compartidos de los paquetes ZK, la secuenciación se puede realizar de forma independiente de los demás paquetes del puente. Cada paquete puede tener su propio secuenciador o implementar una secuenciación compartida. Los proponentes que afirman la raíz del estado resultante después de todos los lotes secuenciados y lo prueban mediante ZK son los que realizan la agregación.

Además, la característica de una finalidad objetiva relativamente rápida en los rollups de ZK no los hace encerrados dentro de su ecosistema, sin importar cuán grande crezca o cuán centralizado sea. Cuando ZK se desarrolle hasta el nivel en que se puedan generar rápidamente grandes pruebas zkVM para múltiples sistemas de prueba, todas las pilas de rollups basadas en ZK interoperarán casi sin problemas, al igual que el rollup teórico de almacén de claves descrito anteriormente envía transacciones en todos los demás rollups en cuestión de bloques L1.

"Pero, ¿cómo es que todavía existen los rollups optimistas si son tan malvados y hay una alternativa en los rollups ZK?"

Dentro de nuestra comunidad de investigadores y personas altamente técnicas, el consenso es que ZK es la mejor solución de escalado. ¡Y te sorprenderá saber que para los usuarios y desarrolladores habituales, los rollups optimistas son mucho mejores que ZK! ¿Por qué?

Para los usuarios : hay un ecosistema bien establecido. Todas las plataformas saben qué son Arbitrum y Base, las dApps siempre tienen una alta liquidez y la experiencia de usuario es fragante. Intenta nombrar una aplicación en Base y recordarás instantáneamente Friend.tech , Farcaster , Daimo , Time.fun (ahora exclusivo de Solana), varias colecciones de NFT, ZKP2P. Incluso Mirror inicialmente solo admitía acumulaciones de OP Stack para acuñar. Intenta nombrar una aplicación en ZKsync Era. Uhhh...

Para los desarrolladores : existe una equivalencia absoluta con Ethereum, por lo que toda la infraestructura de bifurcaciones de Ethereum y EVM funciona desde el principio. Además de eso, la documentación define y explica minuciosamente todas las peculiaridades y herramientas de los rollups optimistas. Hay muchos tutoriales, cursos, maratones, relaciones con los desarrolladores, etc.

Por otro lado, hay zkEVMs de hace años, y no todos tienen equivalencia de bytecode. Todos tienen una larga lista de diferencias y dificultades a la hora de construir sobre ellos. En su mayoría, están mal documentados y dependen en gran medida de una infraestructura existente que apenas es compatible con las redes. Auditar máquinas virtuales "compatibles" es muy difícil y costoso, y ni siquiera tienes un ChatGPT al que preguntar.

Para los usuarios: los rollups de ZK no tienen ecosistema. No hay aplicaciones para usar, ni redes sociales, ni NFT o tokens populares, y toda la actividad se reduce a la agricultura de airdrop. Apenas encontrarás liquidez para pares que no estén en el top 10 del ecosistema Ethereum, y DefiLlama comienza a mostrar rollups de ZK cuando te cansas de desplazarte.

“Pero los rollups optimistas en realidad ganan por compatibilidad con la infraestructura existente. ¿Cómo pueden los rollups ZK superarlos en esto?”

No es necesario introducir la equivalencia de bytecode ni la precompilación de blake2f para atraer a los desarrolladores y la actividad a su plataforma. No se supone que los rollups de ZK sean mejores en eso. En cambio, sí lo son en su rápida finalidad e interoperabilidad, escalabilidad totalmente horizontal, mayor seguridad y descentralización. Esto es lo que se debería utilizar en los proyectos del ecosistema de rollups de ZK para que sean ventajosos en el ecosistema.

Escribí este artículo para reunir una imagen completa de todas estas tecnologías, incluidas las acumulaciones de ZK, que han aparecido y se han desarrollado en el área durante este tiempo y mostrar cómo se pueden utilizar para resolver el problema más importante de hoy en día en el campo: la interoperabilidad de las acumulaciones. Tenemos que adoptar ZK y sus beneficios ilimitados. Tenemos que usarlos a nuestro favor para crear cosas que nos acerquen a hacer de la Web3 un lugar para todos en el mundo.

Esta es quizás la tabla comparativa más grande que he hecho. No es de extrañar: en el último año, la comunidad Ethereum ha presentado muchas ideas y tecnologías nuevas que se pueden combinar y manipular de manera flexible para crear soluciones completamente nuevas que resuelvan los problemas más urgentes en el área, incluso con la tecnología existente.

Sí, sigo convencido de que la interoperabilidad de las acumulaciones es el problema más acuciante que nos impide incorporar a todo el mundo a la Web3. La escalabilidad ya no es tan urgente: 4844 nos permite gestionar hasta mil transacciones por segundo, comparable a la actividad financiera de los países más grandes del mundo; PeerDAS llegará pronto y aumentará aún más esta capacidad. Sin embargo, la fragmentación sigue planteando una grave amenaza para el ecosistema Ethereum. No importa lo grande que sea, el ecosistema no debería sentirse como una docena de imperios distintos, sino como un gran mecanismo. Tan diferente, pero tan idéntico.

No es el primer paso, y este artículo pretende demostrártelo. Debemos utilizar todas nuestras fuerzas para desarrollar sistemas que funcionen y que ayuden a que el gigantesco ecosistema L2 interopere. Esto es posible ahora mismo. Pronto, deberías poder participar en cualquier DAO y enviar cualquier activo a la ENS cuyo propietario se encuentre a varios miles de kilómetros de ti. Las fronteras geográficas no deberían ser sustituidas por fronteras digitales.

Si te gustó este trabajo, estás de acuerdo con su tesis, aprendiste algo nuevo o quieres difundir más este mensaje, compártelo en las redes sociales, deja tus comentarios y habla más sobre la importancia de la interoperabilidad de los rollups. Gracias por leer.

Nota del autor: Una versión de este artículo fue publicada previamente aquí .