La Guía Incompleta de los Rollups
2021 Jan 05
See all posts
La Guía Incompleta de los Rollups
Gracias a j4c0b0bl4nd0n por la
traducción
Los Rollups están de moda en la comunidad de Ethereum y están destinados
a ser la solución de escalabilidad clave para Ethereum en el futuro
previsible. Pero, ¿qué es exactamente esta tecnología, qué podemos
esperar de ella y cómo podremos usarla? Este post intentará responder
algunas de esas preguntas clave.
Antecedentes:
¿Qué es el escalado de capa-1 y capa-2?
Hay dos formas de escalar un ecosistema blockchain. Primero,
puede hacer que la propia cadena de bloques tenga una mayor capacidad de
transacción. El principal desafío con esta técnica es que las
cadenas de bloques con "bloques más grandes" son inherentemente más
difíciles de verificar y es probable que se vuelvan más centralizadas.
Para evitar tales riesgos, los desarrolladores pueden aumentar la
eficiencia del software del cliente o, de manera más sostenible,
utilizar técnicas como
la fragmentación para permitir que el trabajo de construcción y
verificación de la cadena se divida en muchos nodos; el esfuerzo conocido como "eth2"
actualmente está construyendo esta actualización en Ethereum.
En segundo lugar, puede cambiar la forma en que usa la cadena
de bloques. En lugar de poner toda la actividad en la cadena de
bloques directamente, los usuarios realizan la mayor parte de su
actividad fuera de la cadena en un protocolo de "capa-2". Hay un
contrato inteligente en la cadena, que solo tiene dos tareas: procesar
depósitos y retiros, y verificar las pruebas de que todo lo que sucede
fuera de la cadena sigue las reglas. Hay varias formas de hacer estas
pruebas, pero todas comparten la propiedad que verificar las pruebas en
la cadena es mucho más económico que hacer el cálculo original fuera de
la cadena.
State channels vs plasma vs
rollups
Los tres tipos principales de escalado de capa-2 son state channels, Plasma y Rollups. Estos son tres paradigmas
diferentes, con diferentes fortalezas y debilidades, y en este punto
estamos bastante seguros de que toda la escala de capa-2 cae
aproximadamente en estas tres categorías (aunque existen controversias
de nombres en los bordes, por ejemplo, ver "validium").
Cómo funcionan State
channels?
Ver también: https://www.jeffcoleman.ca/state-channels
y statechannels.org
Imaginemos que Alice le ofrece una conexión a Internet a Bob, a
cambio de que Bob le pague $0,001 por megabyte. En lugar de realizar una
transacción para cada pago, Alice y Bob utilizan el siguiente esquema de
capa-2.
Primero, Bob pone $ 1 (o algún ETH o equivalente de moneda estable)
en un contrato inteligente. Para realizar su primer pago a Alice, Bob
firma un "boleto" (un mensaje fuera de la cadena), que simplemente dice
"$0.001", y se lo envía a Alice. Para hacer su segundo pago, Bob
firmaría otro boleto que dice "$0.002" y se lo enviaría a Alice. Y así
sucesivamente para tantos pagos como sea necesario. Cuando Alice y Bob
terminen de realizar transacciones, Alice puede publicar el boleto de
mayor valor para encadenarlo, envuelto en otra firma suya. El contrato
inteligente verifica las firmas de Alice y Bob, le paga a Alice el monto
del boleto de Bob y le devuelve el resto a Bob. Si Alice no está
dispuesta a cerrar el canal (debido a malicia o falla técnica), Bob
puede iniciar un período de retiro (por ejemplo, 7 días); si Alice no
proporciona un boleto dentro de ese tiempo, entonces Bob recupera todo
su dinero.
Esta técnica es poderosa: se puede ajustar para manejar pagos
bidireccionales, relaciones de contratos inteligentes (por ejemplo,
Alice y Bob hacen un contrato financiero dentro del canal) y composición
(si Alice y Bob tienen un canal abierto y también Bob y Charlie, Alice
puede interactuar sin confianza con Charlie). Pero hay límites a lo que
pueden hacer los canales. Los canales no se pueden usar para enviar
fondos fuera de la cadena a personas que aún no son participantes. Los
canales no se pueden utilizar para representar objetos que no tengan un
propietario lógico claro (p. ej., Uniswap). Y los canales, especialmente
si se utilizan para hacer cosas más complejas que simples pagos
recurrentes, requieren una gran cantidad de capital para bloquearse.
Cómo funciona Plasma?
Ver también: el paper original de Plasma, y Plasma
Cash.
Para depositar un activo, un usuario lo envía al contrato inteligente
que administra la cadena Plasma. La cadena Plasma asigna a ese activo
una nueva identificación única (por ejemplo, 537). Cada cadena de Plasma
tiene un operador (podría ser un actor centralizado, multisig o
algo más complejo como PoS o DPoS). Cada intervalo (esto podría ser de
15 segundos, una hora o cualquier intervalo), el operador genera un
"batch" que consta de todas las transacciones de Plasma que han recibido
fuera de la cadena. Generan un árbol de Merkle, en el que en cada índice
"X" del árbol hay una transacción que transfiere el ID de activo "X" si
existe tal transacción y, de lo contrario, esa hoja es cero. Publican el
Merkle root de este árbol a la cadena. También envían la rama Merkle de
cada índice X al propietario actual de ese activo. Para
retirar un activo, un usuario publica la sucursal de Merkle de la
transacción más reciente que le envía el activo. El contrato inicia un
período de impugnación, durante el cual cualquiera puede intentar usar
otras sucursales de Merkle para invalidar la salida al demostrar que (I)
el remitente no era propietario del activo en el momento en que lo
envió, o (II) envió el activo a otra persona en algún momento posterior.
Si nadie prueba que la salida es fraudulenta durante (por ejemplo) 7
días, el usuario puede retirar el activo.
Plasma proporciona propiedades más sólidas que los State channels:
puede enviar activos a participantes que nunca formaron parte del
sistema y los requisitos de capital son mucho más bajos. Pero tiene un
costo: los canales no requieren datos en absoluto para conectarse en
cadena durante el "funcionamiento normal", pero Plasma requiere que cada
cadena publique un hash a intervalos regulares. Además, las
transferencias de Plasma no son instantáneas: hay que esperar a que
finalice el intervalo y se publique el bloque.
Además, Plasma y State channels comparten una debilidad clave en
común: la teoría del juego detrás de por qué son seguros se basa en la
idea de que cada objeto controlado por ambos sistemas tiene algún
"propietario" lógico. Si a ese propietario no le importa su activo,
puede resultar en un resultado "no válido" que involucre a ese activo.
Esto está bien para muchas aplicaciones, pero es un factor decisivo para
muchas otras (por ejemplo: Uniswap). Incluso los sistemas en los que se
puede cambiar el estado de un objeto sin el consentimiento del
propietario (por ejemplo: los sistemas basados en cuentas, en los que
puede aumentar el saldo de alguien sin su consentimiento) no
funcionan bien con Plasma. Todo esto significa que se requiere una gran
cantidad de "razonamiento específico de la aplicación" en cualquier
despliegue realista de Plasma o State channels, y no es posible hacer un
sistema Plasma o State channels que solo simule el entorno completo de
ethereum (o "el EVM") . Para solucionar este problema, llegamos a...
Rollups.
Rollups
Ver También: EthHub
en optimistic rollups y ZK
rollups.
Plasma y State channels son esquemas de capa-2 "completos", en el
sentido de que intentan mover tanto los datos como la computación fuera
de la cadena. Sin embargo, los problemas
fundamentales de la teoría de juegos en torno a la disponibilidad de
datos significan que es imposible hacer esto de manera segura para
todas las aplicaciones. Plasma y State channels evitan esto al basarse
en una noción explícita de propietarios, pero esto les impide ser
completamente generales. Los Rollups, por otro lado, son un esquema de
capa-2 "híbrido". Los Rollups mueven el cómputo (y el
almacenamiento de estado) fuera de la cadena, pero mantienen algunos
datos por transacción adentro de la cadena. Para mejorar la
eficiencia, utilizan una gran cantidad de trucos de compresión
sofisticados para reemplazar los datos con computación siempre
que sea posible. El resultado es un sistema en el que la escalabilidad
sigue estando limitada por el ancho de banda de datos de la cadena de
bloques subyacente, pero en una proporción muy favorable: mientras que
una transferencia de token ERC20 de capa base de Ethereum cuesta ~45000
gas, una transferencia de token ERC20 en un Rollup ocupa 16 bytes de
espacio en cadena y costos por debajo de 300 de gas.
El hecho de que los datos estén en la cadena es clave (nota: poner
los datos "en IPFS" no funciona, porque IPFS no brinda
consenso sobre si un dato determinado está disponible o no; los
datos deben ir en una cadena de bloques). Poner datos en la
cadena y tener consenso sobre ese hecho permite que cualquier persona
procese localmente todas las operaciones en el Rollup si así lo desea,
lo que les permite detectar fraudes, iniciar retiros o comenzar
personalmente a producir batch de transacciones. La falta de problemas
de disponibilidad de datos significa que un operador malintencionado o
fuera de línea puede causar incluso menos daño (por ejemplo: no puede
causar un retraso de 1 semana), lo que abre un espacio de diseño mucho
más grande para quién tiene derecho a publicar batch y hace que los
Rollups sean mucho más sencillos. Y lo que es más importante, la falta
de problemas de disponibilidad de datos significa que ya no es necesario
asignar activos a los propietarios, lo que lleva a la razón clave por la
cual la comunidad de Ethereum está mucho más entusiasmada con los
Rollups que con las formas anteriores de escalado de capa-2: Los
Rollups son totalmente de multi-propósito, e incluso se puede ejecutar
un EVM dentro de un Rollup, lo que permite que las aplicaciones Ethereum
existentes migren a Rollups casi sin necesidad de escribir ningún código
nuevo.
OK, entonces,
¿cómo funciona exactamente un Rollup?
Hay un contrato inteligente dentro de la cadena que mantiene una
estado root: el Merkle root del estado del Rollup (es
decir, los saldos de cuenta, el código del contrato, etc., lo que está
"dentro" del Rollup).
Cualquiera puede publicar un batch, una colección de
transacciones en un formato altamente comprimido junto con el root del
estado anterior y el root del nuevo estado (el Merkle root
después de procesar las transacciones). El contrato verifica
que el root de estado anterior en el batch coincida con su root de
estado actual; si lo hace, cambia el root del estado a el nuevo root del
estado.
Para admitir depósitos y retiros, agregamos la capacidad de tener
transacciones cuya entrada o salida está "fuera" del estado del Rollup.
Si un batch tiene entradas desde el exterior, la transacción que envía
el batch también debe transferir estos activos al contrato de Rollup. Si
un batch tiene salidas al exterior, luego de procesar el batch, el
contrato inteligente inicia esos retiros.
¡Y eso es! Excepto por un detalle importante: ¿cómo saber si
los roots posteriores al estado en el batch son correctas? Si
alguien puede enviar un batch con cualquier root posterior al estado sin
consecuencias, podría simplemente transferir todas las monedas que
contiene el Rollup a sí mismos. Esta pregunta es clave porque hay dos
familias de soluciones muy diferentes para el problema, y estas dos
familias de soluciones conducen a los dos tipos de Rollups.
Optimistic Rollups vs ZK
Rollups
Los dos tipos de Rollups son:
- Optimistic Rollups, que utilizan pruebas de
fraude: el contrato del Rollup realiza un seguimiento de todo
su historial de state roots y el hash de cada batch. Si alguien descubre
que un batch tenía un root posterior al estado incorrecta, puede
publicar una prueba en cadena, demostrando que el batch se calculó
incorrectamente. El contrato verifica la prueba y revierte ese batch y
todos los batches posteriores.
- ZK Rollups, que usan pruebas de
validez: cada batch incluye una prueba criptográfica llamada
ZK-SNARK (por ejemplo: usando el protocolo PLONK), lo que demuestra que
el root posterior al estado es el resultado correcto para ejecutar el
batch. No importa cuán grande sea el cálculo, la prueba se puede
verificar muy rápidamente en la cadena.
Hay compensaciones complejas entre los dos tipos de Rollups:
| Costo fijo de gas por batch |
~40,000 (una transacción liviana que principalmente
solo cambia el valor del root del estado) |
~500,000 (la verificación de un ZK-SNARK es bastante intensiva
computacionalmente) |
| Tiempo de retiro |
~1 semana (los retiros deben retrasarse para dar tiempo a que
alguien publique una prueba de fraude y cancele el retiro si es
fraudulento) |
Muy rápida (solo espera el siguiente batch) |
| Complejidad de la tecnología |
Baja |
Alta (ZK-SNARK es una tecnología muy nueva y matemáticamente
compleja) |
| Generalizabilidad |
Más fácil (Los Rollups de EVM de propósito general
ya están cerca de la red principal) |
Más difícil (para ZK-SNARK probar la ejecución de EVM de propósito
general es mucho más difícil que probar cálculos simples, aunque hay
esfuerzos (por ejemplo: Cairo)
trabajando para mejorar esto) |
| Costos de gas en cadena por transacción |
Altos |
Bajos (si los datos en una transacción solo se usan
para verificar, y no para causar cambios de estado, entonces estos datos
pueden omitirse, mientras que en un Optimist Rollup tendrían que
publicarse en caso de que deban verificarse en una prueba de
fraude) |
| Costos de computación fuera de la cadena |
Bajos (aunque hay más necesidad de muchos nodos
completos para rehacer el cálculo) |
Altos (La prueba de ZK-SNARK, especialmente para el cómputo de
propósito general, puede ser costosa, potencialmente miles de veces más
costosa que ejecutar el cómputo directamente.) |
En general, mi opinión es que, a corto plazo, es probable que los
Optimist Rollups ganen para el cómputo de EVM de propósito general y que
los ZK Rollups probablemente ganen para pagos simples, intercambios y
otros casos de uso específicos de la aplicación, pero en Los Rollups de
ZK a mediano y largo plazo ganarán en todos los casos de uso a medida
que mejore la tecnología ZK-SNARK.
Anatomía de prueba de fraude
La seguridad de un Rollup de Optimistic depende de la idea de que si
alguien publica un batch inválido en el Rollup, cualquier otra
persona que se mantuvo al día con la cadena y detectó el fraude
puede publicar una prueba de fraude, demostrando al contrato que ese
batch no es válido y debe revertirse.
Una prueba de fraude que afirme que un batch no es válido contendría
los datos en verde: el batch en sí (que podría verificarse con un hash
almacenado en cadena) y las partes del árbol Merkle necesarias para
probar solo las cuentas específicas que se leyeron y/o modificado por el
batch. Los nodos del árbol en amarillo se pueden reconstruir a partir de
los nodos en verde, por lo que no es necesario proporcionarlos. Estos
datos son suficientes para ejecutar el batch y calcular el root
posterior al estado (tenga en cuenta que esto es exactamente igual a
cómo los clientes
sin estado verifican bloques individuales). Si el root posterior al
estado calculado y el root posterior al estado proporcionado en el batch
no son iguales, entonces el batch es fraudulento.
Se garantiza que si un batch se construyó incorrectamente, y
todos los batches anteriores se construyeron correctamente,
entonces es posible crear una prueba de fraude que muestre que el batch
se construyó incorrectamente. Tenga en cuenta la afirmación sobre los
batches anteriores: si hubo más de un batch no válido publicado en el
Rollup, entonces es mejor intentar probar que el primero no es válido.
Por supuesto, también se garantiza que si un batch se construyó
correctamente, nunca será posible crear una prueba de fraude que
demuestre que el batch no es válido.
¿Cómo funciona la compresión?
Una transacción simple de Ethereum (para enviar ETH) requiere ~110
bytes. Sin embargo, una transferencia ETH en un Rollup solo requiere ~12
bytes:
| Nonce |
~3 |
0 |
| Gasprice |
~8 |
0-0.5 |
| Gas |
3 |
0-0.5 |
| To |
21 |
4 |
| Value |
~9 |
~3 |
| Signature |
~68 (2 + 33 + 33) |
~0.5 |
| From |
0 (recovered from sig) |
4 |
| Total |
~112 |
~12 |
Parte de esto es simplemente una codificación superior: el RLP de
Ethereum desperdicia 1 byte por valor en la longitud de cada valor. Pero
también hay algunos trucos de compresión muy inteligentes que están
sucediendo:
- Nonce: el propósito de este parámetro es evitar
repeticiones. Si el nonce actual de una cuenta es 5, la próxima
transacción de esa cuenta debe tener un nonce 5, pero una vez que se
procese la transacción, el nonce en la cuenta se incrementará a 6 para
que la transacción no se pueda procesar nuevamente. En el Rollup,
podemos omitir el nonce por completo, porque solo recuperamos el nonce
del estado anterior; si alguien intenta reproducir una transacción con
un nonce anterior, la firma no se verificará, ya que la firma se
verificará con los datos que contienen el nuevo nonce superior.
- Gasprice: podemos permitir que los usuarios paguen
con un rango fijo de precios de gas, por ejemplo: una elección de 16
potencias consecutivas de dos. Alternativamente, podríamos simplemente
tener un nivel de tarifa fijo en cada batch, o incluso mover el pago de
gas fuera del protocolo de acumulación por completo y hacer que los
transactores paguen a los creadores de batch para su inclusión a través
de un canal.
- Gas: de manera similar, podríamos restringir el gas
total a una elección de potencias consecutivas de dos. Alternativamente,
podríamos tener un límite de gas solo a nivel de batch.
- To: podemos reemplazar la dirección de 20 bytes con
un index (por ejemplo, si una dirección es la dirección 4527
agregada al árbol, solo usamos el index 4527 para referirnos a ella.
Agregaríamos un subárbol al estado para almacenar el mapeo de índices a
direcciones).
- Value: podemos almacenar valor en notación
científica. En la mayoría de los casos, las transferencias solo
necesitan de 1 a 3 dígitos significativos.
- Signature: podemos usar BLS
firmas agregadas, que nos permite agregar muchas firmas en una sola
firma de ~32-96 bytes (según el protocolo). Luego, esta firma se puede
verificar con el conjunto completo de mensajes y remitentes en un batch,
todo a la vez. El ~0.5 en la tabla representa el hecho de que existe un
límite en la cantidad de firmas que se pueden combinar en un agregado
que se puede verificar en un solo bloque, por lo que los batches grandes
necesitarían una firma por cada ~100 transacciones.
Un truco de compresión importante que es específico de los Rollups de
ZK es que si una parte de una transacción solo se usa para la
verificación y no es relevante para calcular la actualización del
estado, entonces esa parte se puede dejar fuera de la cadena. Esto no se
puede hacer en un Rollup de Optimistic porque esos datos aún deberían
incluirse en la cadena en caso de que deban verificarse más tarde en una
prueba de fraude, mientras que en un Rollup de ZK, el SNARK que prueba
la corrección del batch ya prueba que cualquier dato necesario para la
verificación. Un ejemplo importante de esto son los Rollup que preservan
la privacidad: en un Rollup de Optimistic, el ZK-SNARK de ~500 bytes
utilizado para la privacidad en cada transacción debe ir en cadena,
mientras que en un Rollup de ZK, el ZK-SNARK que cubre todo el batch ya
no deja duda que los ZK-SNARK "internos" sean válidos.
Estos trucos de compresión son clave para la escalabilidad de los
Rollups; sin ellos, los Rollups serían quizás solo una mejora de ~10x en
la escalabilidad de la cadena base (aunque hay algunas aplicaciones
específicas de computación pesada donde incluso los resúmenes simples
son poderosos), mientras que con los trucos de compresión, el factor de
escala puede superar 100x por casi todas las aplicaciones.
¿Quién puede enviar un batch?
Hay varias escuelas de pensamiento sobre quién puede enviar un batch
en un Rollup Optimistic o ZK. En general, todos están de acuerdo en que
para poder enviar un batch, un usuario debe hacer un depósito grande; si
ese usuario alguna vez envía un batch fraudulento (por ejemplo, con un
root de estado no válido), ese depósito se quemará en parte y se
entregará en parte como recompensa al probador de fraude. Pero más allá
de eso, hay muchas posibilidades:
- Anarquía total: cualquiera puede enviar un batch en
cualquier momento. Este es el enfoque más simple, pero tiene algunos
inconvenientes importantes. En particular, existe el riesgo de que
varios participantes generen e intenten enviar batches en paralelo, y
solo uno de esos batches se puede incluir con éxito. Esto conduce a una
gran cantidad de esfuerzo desperdiciado en la generación de pruebas y/o
gas desperdiciado en la publicación de batch en cadena.
- Secuenciador centralizado: hay un solo actor, el
secuenciador, que puede enviar batches (con la
excepción de los retiros: la técnica habitual es que un usuario primero
puede enviar una solicitud de retiro y luego, si el secuenciador no
procesa ese retiro en el siguiente batch, entonces el usuario puede
enviar un batch de una sola operación por sí mismo). Este es el más
"eficiente", pero depende de un actor central para la vitalidad.
- Subasta de secuenciador: se lleva a cabo una
subasta (por ejemplo: todos los días) para determinar quién tiene
derecho a ser el secuenciador para el día siguiente. Esta técnica tiene
la ventaja de que recauda fondos que podrían ser distribuidos por
ejemplo: un DAO controlado por el Rollup (ver: Subastas
MEV)
- Selección aleatoria desde el conjunto PoS:
cualquiera puede depositar ETH (o quizás el token de protocolo propio
del Rollup) en el contrato del Rollup, y el secuenciador de cada batch
se selecciona aleatoriamente de uno de los depositantes, con la
probabilidad de ser seleccionado proporcional a la cantidad depositada.
El principal inconveniente de esta técnica es que conduce al bloqueo de
grandes cantidades de capital innecesarias.
- Votación DPoS: solo hay un secuenciador
seleccionado con una subasta, pero si su rendimiento es bajo, los
poseedores de tokens pueden votar para expulsarlos y realizar una nueva
subasta para reemplazarlos.
Procesamiento
por batches dividido y aprovisionamiento de state root
Algunos de los Rollups que se están desarrollando actualmente usan un
paradigma de "batch dividido", donde la acción de enviar un batch de
transacciones de capa-2 y la acción de enviar una state root se realizan
por separado. Esto tiene algunas ventajas clave:
- Puede permitir que muchos secuenciadores publiquen batches en
paralelo para mejorar la resistencia a la censura, sin preocuparse de
que algunos batches no sean válidos porque se incluyó otro primero.
- Si un state root es fraudulento, no necesita revertir todo el batch;
puede revertir solo el root del estado y esperar a que alguien
proporcione un nuevo root del estado para el mismo batch. Esto brinda a
los remitentes de transacciones una mejor garantía de que sus
transacciones no se revertirán.
Entonces, en general, hay un zoológico bastante complejo de técnicas
que intentan equilibrar complicadas compensaciones que involucran
eficiencia, simplicidad, resistencia a la censura y otros objetivos.
Todavía es demasiado pronto para decir qué combinación de estas ideas
funciona mejor; el tiempo dirá.
¿Cuánta escalabilidad
te dan los Rollups?
En la cadena Ethereum existente, el límite de gas es de 12,5
millones, y cada byte de datos en una transacción cuesta 16 de gas. Esto
significa que si un bloque no contiene nada más que un solo batch
(diremos que se usa un Rollup de ZK, gastando 500k de gas en la
verificación de prueba), ese batch puede tener (12 millones/16) =
750,000 bytes de datos. Como se muestra arriba, un Rollup para
transferencias ETH requiere solo 12 bytes por operación de usuario, lo
que significa que el batch puede contener hasta 62 500 transacciones.
Con un tiempo de bloque promedio de 13 segundos, esto se traduce en
~4807 TPS (en comparación con 12,5 millones/21000/13 ~= 45 TPS para
transferencias ETH directamente en Ethereum).
Aquí hay una tabla para algunos otros casos de uso de ejemplo: |
Applicación | Bytes en Rollup | costo Gas en capa-1 | Max aumento
escalabilidad | | - | - | - | - | | ETH transferencia |
12 | 21,000 | 105x | | ERC20 transferencia |
16 (4 bytes más para especificar qué token) | ~50,000 |
187x | | Uniswap trade | ~14 (remitente de 4 bytes +
Destinatario de 4 bytes + valor de 3 bytes + Precio máximo de 1 byte +
Miscelánea de 1 byte) | ~100,000 | 428x | | Retiro preservando la
privacidad (Rollup de Optimistic) | 296 (4 bytes index
root + 32 bytes anulador + 4 bytes destinatario + 256 bytes prueba
ZK-SNARK | ~380,000
| 77x
La ganancia máxima de escalabilidad se calcula como (L1
costo gas) / (bytes enRrollup * 16) * 12 million / 12.5
millones.
Ahora, vale la pena tener en cuenta que estas cifras son demasiado
optimistas por varias razones. Lo que es más importante, un bloque casi
nunca contendría solo un batch, al menos porque hay y habrá múltiples
Rollups. Segundo, los depósitos y retiros seguirán existiendo. En tercer
lugar, en el corto plazo el uso será bajo, por lo que dominarán
los costos fijos. Pero incluso teniendo en cuenta estos factores, se
espera que las ganancias de escalabilidad de más de 100x sean la
norma.
Ahora, ¿qué sucede si queremos superar ~1000-4000 TPS (según el caso
de uso específico)? Aquí es donde entra en juego la fragmentación
de datos eth2. La propuesta de fragmentación abre un espacio de 16
MB cada 12 segundos que se puede llenar con cualquier dato, y el sistema
garantiza el consenso sobre la disponibilidad de esos datos. Este
espacio de datos puede ser utilizado por los Rollups. Estos ~1398k bytes
por segundo son una mejora de 23 veces sobre los ~60 kB/seg de la cadena
Ethereum existente y, a largo plazo, se espera que la capacidad de datos
crezca aún más. Por lo tanto, los Rollups que utilizan datos
fragmentados de eth2 pueden procesar colectivamente hasta ~100 000 TPS,
e incluso más en el futuro.
¿Cuáles
son algunos de los desafíos que aún no se han resuelto por completo en
los Rollups?
Si bien el concepto básico de un Rollup ahora se comprende bien,
estamos bastante seguros de que son fundamentalmente factibles y
seguros, y ya se han implementado varios Rollups en la red principal,
todavía hay muchas áreas del diseño del Rollup que no se han explorado
bien, y bastantes desafíos para llevar por completo grandes partes del
ecosistema Ethereum a Rollups para aprovechar su escalabilidad. Algunos
desafíos clave incluyen:
- Incorporación de usuarios y ecosistemas - no muchas
aplicaciones usan Rollups, los Rollups no son familiares para los
usuarios y pocas billeteras han comenzado a integrar Rollups. Los
comerciantes y las organizaciones benéficas aún no los aceptan para
pagos.
- Transacciones cruzadas - mover activos y datos de
manera eficiente (por ejemplo: salidas de oracúlo) de un Rollup a otro
sin incurrir en el gasto de pasar por la capa base.
- Incentivos de auditoría - ¿Cómo maximizar la
posibilidad de que al menos un nodo honesto realmente verifique
completamente un Rollup de Optimistic para que puedan publicar una
prueba de fraude si algo sale mal? Para Rollups a pequeña escala (hasta
unos pocos cientos de TPS), este no es un problema importante y uno
simplemente puede confiar en el altruismo, pero para Rollups a mayor
escala se necesita un razonamiento más explícito sobre esto.
- Explorando el espacio de diseño entre Plasma y
Rollups - ¿Existen técnicas que pongan algunos datos
relevantes para la actualización del estado en la cadena, pero no
todos, y hay algo útil que pueda resultar de eso?
- Maximizar la seguridad de las confirmaciones
previas - muchos Rollups brindan una noción de "confirmación
previa" para una UX más rápida, donde el secuenciador promete de
inmediato que una transacción se incluirá en el siguiente Batch, y el
depósito del secuenciador se destruye si no cumplen su palabra. Pero la
seguridad económica de este esquema es limitada, debido a la posibilidad
de hacer muchas promesas a muchos actores al mismo tiempo. ¿Se puede
mejorar este mecanismo?
- Mejora de la velocidad de respuesta a los secuenciadores
ausentes - Si el secuenciador de un Rollup se desconecta
repentinamente, sería valioso recuperarse de esa situación de la manera
más rápida y económica, ya sea saliendo en masa de manera rápida y
económica a un Rollup diferente o reemplazando el secuenciador.
- Eficiente ZK-VM - generando una prueba ZK-SNARK de
que el código EVM de propósito general (o alguna VM diferente en la que
se puedan compilar los contratos inteligentes existentes) se ha
ejecutado correctamente y tiene un resultado determinado.
Conclusiones
Los rollups son un nuevo y poderoso paradigma de escalamiento de
capa-2, y se espera que sean la piedra angular del escalamiento de
Ethereum en el futuro a corto y mediano plazo (y posiblemente también a
largo plazo). Han visto una gran cantidad de entusiasmo por parte de la
comunidad Ethereum porque, a diferencia de los intentos anteriores de
escalado de capa-2, pueden admitir código EVM de uso general, lo que
permite que las aplicaciones existentes se migren fácilmente. Lo hacen
al hacer un compromiso clave: no intentar salir completamente de la
cadena, sino dejar una pequeña cantidad de datos por transacción en la
cadena.
Hay muchos tipos de resúmenes y muchas opciones en el espacio de
diseño: uno puede tener un Rollup de Optimistic usando pruebas de fraude
o un Rollup de ZK usando pruebas de validez (también conocido como
ZK-SNARK). El secuenciador (el usuario que puede publicar batch de
transacciones para encadenar) puede ser un actor centralizado, un
free-for-all o muchas otras opciones intermedias. Los Rollups aún son
una tecnología en etapa inicial y el desarrollo continúa rápidamente,
pero funcionan y algunos (en particular, Loopring, ZKSync y DeversiFi) ya se han estado
ejecutando durante meses. Esperamos un trabajo mucho más emocionante que
surja del espacio acumulativo en los años venideros.
La Guía Incompleta de los Rollups
2021 Jan 05 See all postsGracias a j4c0b0bl4nd0n por la traducción
Los Rollups están de moda en la comunidad de Ethereum y están destinados a ser la solución de escalabilidad clave para Ethereum en el futuro previsible. Pero, ¿qué es exactamente esta tecnología, qué podemos esperar de ella y cómo podremos usarla? Este post intentará responder algunas de esas preguntas clave.
Antecedentes: ¿Qué es el escalado de capa-1 y capa-2?
Hay dos formas de escalar un ecosistema blockchain. Primero, puede hacer que la propia cadena de bloques tenga una mayor capacidad de transacción. El principal desafío con esta técnica es que las cadenas de bloques con "bloques más grandes" son inherentemente más difíciles de verificar y es probable que se vuelvan más centralizadas. Para evitar tales riesgos, los desarrolladores pueden aumentar la eficiencia del software del cliente o, de manera más sostenible, utilizar técnicas como la fragmentación para permitir que el trabajo de construcción y verificación de la cadena se divida en muchos nodos; el esfuerzo conocido como "eth2" actualmente está construyendo esta actualización en Ethereum.
En segundo lugar, puede cambiar la forma en que usa la cadena de bloques. En lugar de poner toda la actividad en la cadena de bloques directamente, los usuarios realizan la mayor parte de su actividad fuera de la cadena en un protocolo de "capa-2". Hay un contrato inteligente en la cadena, que solo tiene dos tareas: procesar depósitos y retiros, y verificar las pruebas de que todo lo que sucede fuera de la cadena sigue las reglas. Hay varias formas de hacer estas pruebas, pero todas comparten la propiedad que verificar las pruebas en la cadena es mucho más económico que hacer el cálculo original fuera de la cadena.
State channels vs plasma vs rollups
Los tres tipos principales de escalado de capa-2 son state channels, Plasma y Rollups. Estos son tres paradigmas diferentes, con diferentes fortalezas y debilidades, y en este punto estamos bastante seguros de que toda la escala de capa-2 cae aproximadamente en estas tres categorías (aunque existen controversias de nombres en los bordes, por ejemplo, ver "validium").
Cómo funcionan State channels?
Ver también: https://www.jeffcoleman.ca/state-channels y statechannels.org
Imaginemos que Alice le ofrece una conexión a Internet a Bob, a cambio de que Bob le pague $0,001 por megabyte. En lugar de realizar una transacción para cada pago, Alice y Bob utilizan el siguiente esquema de capa-2.
Primero, Bob pone $ 1 (o algún ETH o equivalente de moneda estable) en un contrato inteligente. Para realizar su primer pago a Alice, Bob firma un "boleto" (un mensaje fuera de la cadena), que simplemente dice "$0.001", y se lo envía a Alice. Para hacer su segundo pago, Bob firmaría otro boleto que dice "$0.002" y se lo enviaría a Alice. Y así sucesivamente para tantos pagos como sea necesario. Cuando Alice y Bob terminen de realizar transacciones, Alice puede publicar el boleto de mayor valor para encadenarlo, envuelto en otra firma suya. El contrato inteligente verifica las firmas de Alice y Bob, le paga a Alice el monto del boleto de Bob y le devuelve el resto a Bob. Si Alice no está dispuesta a cerrar el canal (debido a malicia o falla técnica), Bob puede iniciar un período de retiro (por ejemplo, 7 días); si Alice no proporciona un boleto dentro de ese tiempo, entonces Bob recupera todo su dinero.
Esta técnica es poderosa: se puede ajustar para manejar pagos bidireccionales, relaciones de contratos inteligentes (por ejemplo, Alice y Bob hacen un contrato financiero dentro del canal) y composición (si Alice y Bob tienen un canal abierto y también Bob y Charlie, Alice puede interactuar sin confianza con Charlie). Pero hay límites a lo que pueden hacer los canales. Los canales no se pueden usar para enviar fondos fuera de la cadena a personas que aún no son participantes. Los canales no se pueden utilizar para representar objetos que no tengan un propietario lógico claro (p. ej., Uniswap). Y los canales, especialmente si se utilizan para hacer cosas más complejas que simples pagos recurrentes, requieren una gran cantidad de capital para bloquearse.
Cómo funciona Plasma?
Ver también: el paper original de Plasma, y Plasma Cash.
Para depositar un activo, un usuario lo envía al contrato inteligente que administra la cadena Plasma. La cadena Plasma asigna a ese activo una nueva identificación única (por ejemplo, 537). Cada cadena de Plasma tiene un operador (podría ser un actor centralizado, multisig o algo más complejo como PoS o DPoS). Cada intervalo (esto podría ser de 15 segundos, una hora o cualquier intervalo), el operador genera un "batch" que consta de todas las transacciones de Plasma que han recibido fuera de la cadena. Generan un árbol de Merkle, en el que en cada índice "X" del árbol hay una transacción que transfiere el ID de activo "X" si existe tal transacción y, de lo contrario, esa hoja es cero. Publican el Merkle root de este árbol a la cadena. También envían la rama Merkle de cada índice
Xal propietario actual de ese activo. Para retirar un activo, un usuario publica la sucursal de Merkle de la transacción más reciente que le envía el activo. El contrato inicia un período de impugnación, durante el cual cualquiera puede intentar usar otras sucursales de Merkle para invalidar la salida al demostrar que (I) el remitente no era propietario del activo en el momento en que lo envió, o (II) envió el activo a otra persona en algún momento posterior. Si nadie prueba que la salida es fraudulenta durante (por ejemplo) 7 días, el usuario puede retirar el activo.Plasma proporciona propiedades más sólidas que los State channels: puede enviar activos a participantes que nunca formaron parte del sistema y los requisitos de capital son mucho más bajos. Pero tiene un costo: los canales no requieren datos en absoluto para conectarse en cadena durante el "funcionamiento normal", pero Plasma requiere que cada cadena publique un hash a intervalos regulares. Además, las transferencias de Plasma no son instantáneas: hay que esperar a que finalice el intervalo y se publique el bloque.
Además, Plasma y State channels comparten una debilidad clave en común: la teoría del juego detrás de por qué son seguros se basa en la idea de que cada objeto controlado por ambos sistemas tiene algún "propietario" lógico. Si a ese propietario no le importa su activo, puede resultar en un resultado "no válido" que involucre a ese activo. Esto está bien para muchas aplicaciones, pero es un factor decisivo para muchas otras (por ejemplo: Uniswap). Incluso los sistemas en los que se puede cambiar el estado de un objeto sin el consentimiento del propietario (por ejemplo: los sistemas basados en cuentas, en los que puede aumentar el saldo de alguien sin su consentimiento) no funcionan bien con Plasma. Todo esto significa que se requiere una gran cantidad de "razonamiento específico de la aplicación" en cualquier despliegue realista de Plasma o State channels, y no es posible hacer un sistema Plasma o State channels que solo simule el entorno completo de ethereum (o "el EVM") . Para solucionar este problema, llegamos a... Rollups.
Rollups
Ver También: EthHub en optimistic rollups y ZK rollups.
Plasma y State channels son esquemas de capa-2 "completos", en el sentido de que intentan mover tanto los datos como la computación fuera de la cadena. Sin embargo, los problemas fundamentales de la teoría de juegos en torno a la disponibilidad de datos significan que es imposible hacer esto de manera segura para todas las aplicaciones. Plasma y State channels evitan esto al basarse en una noción explícita de propietarios, pero esto les impide ser completamente generales. Los Rollups, por otro lado, son un esquema de capa-2 "híbrido". Los Rollups mueven el cómputo (y el almacenamiento de estado) fuera de la cadena, pero mantienen algunos datos por transacción adentro de la cadena. Para mejorar la eficiencia, utilizan una gran cantidad de trucos de compresión sofisticados para reemplazar los datos con computación siempre que sea posible. El resultado es un sistema en el que la escalabilidad sigue estando limitada por el ancho de banda de datos de la cadena de bloques subyacente, pero en una proporción muy favorable: mientras que una transferencia de token ERC20 de capa base de Ethereum cuesta ~45000 gas, una transferencia de token ERC20 en un Rollup ocupa 16 bytes de espacio en cadena y costos por debajo de 300 de gas.
El hecho de que los datos estén en la cadena es clave (nota: poner los datos "en IPFS" no funciona, porque IPFS no brinda consenso sobre si un dato determinado está disponible o no; los datos deben ir en una cadena de bloques). Poner datos en la cadena y tener consenso sobre ese hecho permite que cualquier persona procese localmente todas las operaciones en el Rollup si así lo desea, lo que les permite detectar fraudes, iniciar retiros o comenzar personalmente a producir batch de transacciones. La falta de problemas de disponibilidad de datos significa que un operador malintencionado o fuera de línea puede causar incluso menos daño (por ejemplo: no puede causar un retraso de 1 semana), lo que abre un espacio de diseño mucho más grande para quién tiene derecho a publicar batch y hace que los Rollups sean mucho más sencillos. Y lo que es más importante, la falta de problemas de disponibilidad de datos significa que ya no es necesario asignar activos a los propietarios, lo que lleva a la razón clave por la cual la comunidad de Ethereum está mucho más entusiasmada con los Rollups que con las formas anteriores de escalado de capa-2: Los Rollups son totalmente de multi-propósito, e incluso se puede ejecutar un EVM dentro de un Rollup, lo que permite que las aplicaciones Ethereum existentes migren a Rollups casi sin necesidad de escribir ningún código nuevo.
OK, entonces, ¿cómo funciona exactamente un Rollup?
Hay un contrato inteligente dentro de la cadena que mantiene una estado root: el Merkle root del estado del Rollup (es decir, los saldos de cuenta, el código del contrato, etc., lo que está "dentro" del Rollup).
Cualquiera puede publicar un batch, una colección de transacciones en un formato altamente comprimido junto con el root del estado anterior y el root del nuevo estado (el Merkle root después de procesar las transacciones). El contrato verifica que el root de estado anterior en el batch coincida con su root de estado actual; si lo hace, cambia el root del estado a el nuevo root del estado.
Para admitir depósitos y retiros, agregamos la capacidad de tener transacciones cuya entrada o salida está "fuera" del estado del Rollup. Si un batch tiene entradas desde el exterior, la transacción que envía el batch también debe transferir estos activos al contrato de Rollup. Si un batch tiene salidas al exterior, luego de procesar el batch, el contrato inteligente inicia esos retiros.
¡Y eso es! Excepto por un detalle importante: ¿cómo saber si los roots posteriores al estado en el batch son correctas? Si alguien puede enviar un batch con cualquier root posterior al estado sin consecuencias, podría simplemente transferir todas las monedas que contiene el Rollup a sí mismos. Esta pregunta es clave porque hay dos familias de soluciones muy diferentes para el problema, y estas dos familias de soluciones conducen a los dos tipos de Rollups.
Optimistic Rollups vs ZK Rollups
Los dos tipos de Rollups son:
Hay compensaciones complejas entre los dos tipos de Rollups:
En general, mi opinión es que, a corto plazo, es probable que los Optimist Rollups ganen para el cómputo de EVM de propósito general y que los ZK Rollups probablemente ganen para pagos simples, intercambios y otros casos de uso específicos de la aplicación, pero en Los Rollups de ZK a mediano y largo plazo ganarán en todos los casos de uso a medida que mejore la tecnología ZK-SNARK.
Anatomía de prueba de fraude
La seguridad de un Rollup de Optimistic depende de la idea de que si alguien publica un batch inválido en el Rollup, cualquier otra persona que se mantuvo al día con la cadena y detectó el fraude puede publicar una prueba de fraude, demostrando al contrato que ese batch no es válido y debe revertirse.
Una prueba de fraude que afirme que un batch no es válido contendría los datos en verde: el batch en sí (que podría verificarse con un hash almacenado en cadena) y las partes del árbol Merkle necesarias para probar solo las cuentas específicas que se leyeron y/o modificado por el batch. Los nodos del árbol en amarillo se pueden reconstruir a partir de los nodos en verde, por lo que no es necesario proporcionarlos. Estos datos son suficientes para ejecutar el batch y calcular el root posterior al estado (tenga en cuenta que esto es exactamente igual a cómo los clientes sin estado verifican bloques individuales). Si el root posterior al estado calculado y el root posterior al estado proporcionado en el batch no son iguales, entonces el batch es fraudulento.
Se garantiza que si un batch se construyó incorrectamente, y todos los batches anteriores se construyeron correctamente, entonces es posible crear una prueba de fraude que muestre que el batch se construyó incorrectamente. Tenga en cuenta la afirmación sobre los batches anteriores: si hubo más de un batch no válido publicado en el Rollup, entonces es mejor intentar probar que el primero no es válido. Por supuesto, también se garantiza que si un batch se construyó correctamente, nunca será posible crear una prueba de fraude que demuestre que el batch no es válido.
¿Cómo funciona la compresión?
Una transacción simple de Ethereum (para enviar ETH) requiere ~110 bytes. Sin embargo, una transferencia ETH en un Rollup solo requiere ~12 bytes:
Parte de esto es simplemente una codificación superior: el RLP de Ethereum desperdicia 1 byte por valor en la longitud de cada valor. Pero también hay algunos trucos de compresión muy inteligentes que están sucediendo:
Un truco de compresión importante que es específico de los Rollups de ZK es que si una parte de una transacción solo se usa para la verificación y no es relevante para calcular la actualización del estado, entonces esa parte se puede dejar fuera de la cadena. Esto no se puede hacer en un Rollup de Optimistic porque esos datos aún deberían incluirse en la cadena en caso de que deban verificarse más tarde en una prueba de fraude, mientras que en un Rollup de ZK, el SNARK que prueba la corrección del batch ya prueba que cualquier dato necesario para la verificación. Un ejemplo importante de esto son los Rollup que preservan la privacidad: en un Rollup de Optimistic, el ZK-SNARK de ~500 bytes utilizado para la privacidad en cada transacción debe ir en cadena, mientras que en un Rollup de ZK, el ZK-SNARK que cubre todo el batch ya no deja duda que los ZK-SNARK "internos" sean válidos.
Estos trucos de compresión son clave para la escalabilidad de los Rollups; sin ellos, los Rollups serían quizás solo una mejora de ~10x en la escalabilidad de la cadena base (aunque hay algunas aplicaciones específicas de computación pesada donde incluso los resúmenes simples son poderosos), mientras que con los trucos de compresión, el factor de escala puede superar 100x por casi todas las aplicaciones.
¿Quién puede enviar un batch?
Hay varias escuelas de pensamiento sobre quién puede enviar un batch en un Rollup Optimistic o ZK. En general, todos están de acuerdo en que para poder enviar un batch, un usuario debe hacer un depósito grande; si ese usuario alguna vez envía un batch fraudulento (por ejemplo, con un root de estado no válido), ese depósito se quemará en parte y se entregará en parte como recompensa al probador de fraude. Pero más allá de eso, hay muchas posibilidades:
Procesamiento por batches dividido y aprovisionamiento de state root
Algunos de los Rollups que se están desarrollando actualmente usan un paradigma de "batch dividido", donde la acción de enviar un batch de transacciones de capa-2 y la acción de enviar una state root se realizan por separado. Esto tiene algunas ventajas clave:
Entonces, en general, hay un zoológico bastante complejo de técnicas que intentan equilibrar complicadas compensaciones que involucran eficiencia, simplicidad, resistencia a la censura y otros objetivos. Todavía es demasiado pronto para decir qué combinación de estas ideas funciona mejor; el tiempo dirá.
¿Cuánta escalabilidad te dan los Rollups?
En la cadena Ethereum existente, el límite de gas es de 12,5 millones, y cada byte de datos en una transacción cuesta 16 de gas. Esto significa que si un bloque no contiene nada más que un solo batch (diremos que se usa un Rollup de ZK, gastando 500k de gas en la verificación de prueba), ese batch puede tener (12 millones/16) = 750,000 bytes de datos. Como se muestra arriba, un Rollup para transferencias ETH requiere solo 12 bytes por operación de usuario, lo que significa que el batch puede contener hasta 62 500 transacciones. Con un tiempo de bloque promedio de 13 segundos, esto se traduce en ~4807 TPS (en comparación con 12,5 millones/21000/13 ~= 45 TPS para transferencias ETH directamente en Ethereum).
Aquí hay una tabla para algunos otros casos de uso de ejemplo: | Applicación | Bytes en Rollup | costo Gas en capa-1 | Max aumento escalabilidad | | - | - | - | - | | ETH transferencia | 12 | 21,000 | 105x | | ERC20 transferencia | 16 (4 bytes más para especificar qué token) | ~50,000 | 187x | | Uniswap trade | ~14 (remitente de 4 bytes + Destinatario de 4 bytes + valor de 3 bytes + Precio máximo de 1 byte + Miscelánea de 1 byte) | ~100,000 | 428x | | Retiro preservando la privacidad (Rollup de Optimistic) | 296 (4 bytes index root + 32 bytes anulador + 4 bytes destinatario + 256 bytes prueba ZK-SNARK | ~380,000 | 77x
La ganancia máxima de escalabilidad se calcula como (L1 costo gas) / (bytes enRrollup * 16) * 12 million / 12.5 millones.
Ahora, vale la pena tener en cuenta que estas cifras son demasiado optimistas por varias razones. Lo que es más importante, un bloque casi nunca contendría solo un batch, al menos porque hay y habrá múltiples Rollups. Segundo, los depósitos y retiros seguirán existiendo. En tercer lugar, en el corto plazo el uso será bajo, por lo que dominarán los costos fijos. Pero incluso teniendo en cuenta estos factores, se espera que las ganancias de escalabilidad de más de 100x sean la norma.
Ahora, ¿qué sucede si queremos superar ~1000-4000 TPS (según el caso de uso específico)? Aquí es donde entra en juego la fragmentación de datos eth2. La propuesta de fragmentación abre un espacio de 16 MB cada 12 segundos que se puede llenar con cualquier dato, y el sistema garantiza el consenso sobre la disponibilidad de esos datos. Este espacio de datos puede ser utilizado por los Rollups. Estos ~1398k bytes por segundo son una mejora de 23 veces sobre los ~60 kB/seg de la cadena Ethereum existente y, a largo plazo, se espera que la capacidad de datos crezca aún más. Por lo tanto, los Rollups que utilizan datos fragmentados de eth2 pueden procesar colectivamente hasta ~100 000 TPS, e incluso más en el futuro.
¿Cuáles son algunos de los desafíos que aún no se han resuelto por completo en los Rollups?
Si bien el concepto básico de un Rollup ahora se comprende bien, estamos bastante seguros de que son fundamentalmente factibles y seguros, y ya se han implementado varios Rollups en la red principal, todavía hay muchas áreas del diseño del Rollup que no se han explorado bien, y bastantes desafíos para llevar por completo grandes partes del ecosistema Ethereum a Rollups para aprovechar su escalabilidad. Algunos desafíos clave incluyen:
Conclusiones
Los rollups son un nuevo y poderoso paradigma de escalamiento de capa-2, y se espera que sean la piedra angular del escalamiento de Ethereum en el futuro a corto y mediano plazo (y posiblemente también a largo plazo). Han visto una gran cantidad de entusiasmo por parte de la comunidad Ethereum porque, a diferencia de los intentos anteriores de escalado de capa-2, pueden admitir código EVM de uso general, lo que permite que las aplicaciones existentes se migren fácilmente. Lo hacen al hacer un compromiso clave: no intentar salir completamente de la cadena, sino dejar una pequeña cantidad de datos por transacción en la cadena.
Hay muchos tipos de resúmenes y muchas opciones en el espacio de diseño: uno puede tener un Rollup de Optimistic usando pruebas de fraude o un Rollup de ZK usando pruebas de validez (también conocido como ZK-SNARK). El secuenciador (el usuario que puede publicar batch de transacciones para encadenar) puede ser un actor centralizado, un free-for-all o muchas otras opciones intermedias. Los Rollups aún son una tecnología en etapa inicial y el desarrollo continúa rápidamente, pero funcionan y algunos (en particular, Loopring, ZKSync y DeversiFi) ya se han estado ejecutando durante meses. Esperamos un trabajo mucho más emocionante que surja del espacio acumulativo en los años venideros.