Revisando los Rollups de la obra maestra de V God, explicando en detalle por qué Ethereum necesita una solución de expansión de segunda capa

Autor original: Vitalik

Traducción y revisión: TinTin Land

Enlace original: https://vitalik.ca/general/2021/01/05/rollup.html

Los rollups están de moda en la comunidad de Ethereum y se espera que se conviertan en una solución de escalabilidad clave para Ethereum en el futuro. Pero ¿qué es exactamente esta tecnología y qué podemos esperar de ella? ¿Y cómo se utilizará? Este artículo intenta responder algunas preguntas clave relacionadas con los Rollups basándose en el análisis de varios planes de expansión importantes de Ethereum.

 Antecedentes: ¿Qué son L1 y L2?

Hay dos formas de expandir el ecosistema blockchain. El primero permite que la propia cadena de bloques tenga mayores capacidades de transacción. El principal desafío de esta tecnología es que las cadenas de bloques con "bloques más grandes" son inherentemente más difíciles de verificar y pueden volverse más centralizadas. Para evitar este riesgo, los desarrolladores pueden hacer que el software del cliente sea más eficiente o utilizar continuamente tecnologías como la fragmentación para permitir que el trabajo de construcción y validación de la cadena se divida en varios nodos. Esa es la actualización de Ethereum que se está construyendo actualmente.

En segundo lugar, puedes cambiar la forma en que utilizas blockchain. En lugar de tener todas sus actividades directamente en la cadena de bloques, los usuarios realizan la mayoría de sus actividades fuera de la cadena en un protocolo de "capa 2". Existe un contrato inteligente en cadena que tiene solo dos tareas: manejar depósitos y retiros, y verificar pruebas de que todo lo que sucede fuera de la cadena sigue las reglas. Hay varias formas de realizar estas pruebas, pero todas comparten la propiedad común de que verificar la prueba en la cadena es mucho más barato que realizar el cálculo original fuera de la cadena.

 Canales estatales frente a plasma frente a paquetes acumulativos 

Hay tres tipos principales de soluciones de capa L2: canales estatales, plasma y rollups. Pertenecen a diferentes paradigmas y tienen diferentes ventajas y desventajas. Los métodos de operación de estos tres esquemas diferentes se describirán a continuación.

Cómo funcionan los canales estatales

Supongamos un caso específico en el que Alice le proporciona a Bob una conexión de red y Bob paga $0,001 por megabyte. En lugar de exigir el pago cada vez, sus transacciones utilizan el siguiente esquema L2.

Primero, Bob pone 1 USD (ETH o equivalente a una moneda estable) en el contrato inteligente. Para realizar su primer pago a Alice, Bob firma un "boleto" (un mensaje fuera de la cadena) que dice "$0,001" y se lo envía a Alice. Para realizar el segundo pago, Bob firma otro billete que dice "$0,002" y se lo envía a Alice. Y así sucesivamente, realizando tantos pagos como sean necesarios. Cuando Alice y Bob completan la transacción, Alice puede publicar el billete de mayor valor en la cadena y envolverlo con otra firma propia. 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 intenciones maliciosas o fallas técnicas), Bob puede iniciar un período de salida (por ejemplo, 7 días); si Alice no proporciona un ticket dentro de este tiempo, Bob recupera todo su dinero.

Lo poderoso de esta tecnología es que puede ajustar las relaciones de contratos inteligentes que manejan pagos bidireccionales. Por ejemplo, Alice y Bob firman un contrato dentro de un canal, y si Alice y Bob tienen un canal abierto, al igual que Bob y Charlie, Alice puede interactuar con Charlie sin confianza.

Sin embargo, existen límites a lo que los canales pueden hacer. Por ejemplo, no puedes utilizar canales para enviar fondos fuera de la cadena a personas que aún no han participado. Los canales no se pueden utilizar para representar objetos que no tienen un propietario lógico claro (como Uniswap). Si tiene necesidades más complejas que simples pagos recurrentes, necesitará mucho dinero para asegurarlas.

Ver también: https://www.jeffcoleman.ca/state-channels y statechannels.org

Cómo funciona Plasma

Para depositar un activo, un usuario lo envía al contrato inteligente que gobierna la cadena Plasma. La cadena Plasma asigna al activo una nueva identificación única (por ejemplo, 537). Cada cadena de Plasma tiene un operador (podría ser un actor centralizado, un multifirma o algo más complejo como PoS o DPoS). En cada intervalo (que podría ser de 15 segundos, una hora o cualquier intervalo intermedio), el operador genera un "lote" que contiene todas las transacciones de Plasma que recibieron fuera de la cadena. Generan un árbol Merkle donde en cada índice del árbol hay una transacción que transfiere el ID del activo si dicha transacción existe; de ​​lo contrario, la hoja es cero.

También envían una rama Merkle de cada índice al propietario actual del activo. Para retirar activos, los usuarios publican la rama Merkle de la transacción más reciente y reciben los activos. El contrato comienza un período de impugnación, durante el cual cualquiera puede intentar utilizar otras sucursales de Merkle para demostrar que la salida no es válida si (i) el remitente no es propietario del activo cuando lo envía, (ii) lo hace en algún momento posterior. Haga clic para enviar activos a otras personas. Si nadie demuestra que el retiro fue fraudulento dentro de los 7 días, el usuario puede retirar los activos.

Plasma ofrece propiedades más sólidas que los canales estatales: los activos pueden enviarse a participantes que nunca han participado en el sistema y los requisitos de capital son muy bajos. El precio es: durante el "funcionamiento normal", el canal no requiere que se cargue ningún dato en la cadena, pero Plasma requiere que cada cadena publique un valor hash con regularidad. Además, la transferencia del cuerpo de Plasma no es instantánea y debe esperar hasta que finalice el intervalo y el bloque aparezca públicamente en la cadena.

Además, Plasma y Channels comparten una debilidad común: su seguridad se basa en la teoría de que cada objeto controlado por ambos sistemas tiene algún "dueño" lógico. Si ese propietario no se preocupa por su activo, podría conducir a un resultado "no válido" relacionado con ese activo. Esto está bien para muchas aplicaciones, pero es un factor decisivo para muchas otras. Incluso los sistemas que cambian el estado de un objeto sin el consentimiento del propietario (como un sistema basado en cuentas donde puedes aumentar el saldo de alguien sin su consentimiento) no funcionan bien con Plasma. Esto significa que en una implementación de Plasma o canal, se requiere mucho "razonamiento específico de la aplicación", y es imposible crear un sistema de Plasma o canal que simplemente emule todo el entorno Ethereum (o "EVM"). Para resolver este problema, comencemos con la tercera opción: Rollups.

Ver también: http://plasma.io/plasma-deprecated.pdf

Cómo funcionan los resúmenes

Acerca de los resúmenes

El plasma y los canales son soluciones L2 "completas" 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 relacionados con la disponibilidad de datos significan que es imposible hacerlo de forma segura para todas las aplicaciones. Plasma y canales resuelven este problema basándose en el concepto de propietario, pero esto afecta su ámbito de aplicación . Sin embargo, los Rollups son un esquema L2 "híbrido". Los rollups mueven la computación (y el almacenamiento de estado) fuera de la cadena, pero mantienen parte de los datos de cada tarea dentro de la cadena. Para mejorar la eficiencia, utilizan muchas técnicas de compresión complejas para reemplazar datos con cálculos siempre que sea posible. El resultado es que la escalabilidad del sistema todavía está limitada por el ancho de banda de datos de la cadena de bloques subyacente, pero en menor medida: las transferencias de tokens ERC20 en la capa base de Ethereum cuestan alrededor de 45.000 gas, mientras que las transferencias de tokens ERC20 en Rollups ocupan 16 bytes de espacio en cadena, cuesta menos de 300 gasolina.

Vale la pena señalar que "poner datos en IPFS" no funciona porque IPFS no tiene un consenso sobre si determinados datos están disponibles, y los datos deben estar en la cadena de bloques. Con el consenso de poner datos en cadena, Rollups permite que cualquiera maneje cualquier operación localmente si lo desea, permitiéndole detectar fraude, iniciar retiros o comenzar a generar lotes de transacciones por sí mismo. La falta de problemas de disponibilidad de datos significa que los operadores maliciosos o fuera de línea pueden causar menos daño (por ejemplo, no pueden causar un retraso de 1 semana). Es más fácil razonar sobre los rollups, lo que abre un espacio más grande para que lo utilicen aquellos con permiso para liberar lotes. Además de eso, la falta de problemas de disponibilidad de datos significa que ya no es necesario asignar activos a los propietarios, lo que ha hecho que la comunidad Ethereum esté muy interesada en las extensiones Rollups. Los rollups son completamente universales e incluso es posible ejecutar EVM en Rollups, lo que permite Algunas aplicaciones de Ethereum existentes migran a Rollups casi sin necesidad de escribir ningún código nuevo.

Ver también: https://docs.ethhub.io/ethereum-roadmap/layer-2-scaling/optimistic_rollups/

Cómo funcionan los resúmenes

Hay un contrato inteligente en la cadena, que mantiene una raíz de estado: la raíz Merkle del estado de Rollups (es decir, saldo de cuenta, código de contrato, etc., "dentro" de Rollups).

Cualquiera puede publicar un lote, que es un conjunto de transacciones altamente comprimido, junto con la raíz del estado anterior y la raíz del nuevo estado (la raíz de Merkle después de procesar las transacciones). El contrato verifica si la raíz del estado anterior en el lote coincide con su raíz del estado actual; si coincide, cambia la raíz del estado a la nueva raíz del estado.

Para admitir depósitos y retiros, se agregó la capacidad de importar o exportar transacciones "fuera del" estado de resumen. Si el lote tiene entradas externas, la transacción que compromete el lote también deberá transferir esos activos al contrato Rollups. Si un lote tiene salidas al exterior, entonces el contrato inteligente iniciará estos retiros mientras procesa el lote.

¿Cómo se sabe que el origen post-estatal del lote es correcto? Si alguien puede enviar un lote con cualquier raíz posterior al estado sin ninguna consecuencia, entonces puede transferirse todas las monedas de los Rollups a sí mismo. Este problema es crítico y ha dado lugar a dos familias distintas de soluciones, dando como resultado dos tipos diferentes de Rollups.

Paquetes acumulativos optimistas 与 Paquetes acumulativos ZK 

Los dos tipos de Rollups son:

1. Optimistic Rollups (Optimistic Rollups) , utilizando prueba de fraude: El contrato Rollups rastrea todo el historial de su estado raíz y el hash de cada lote. Si alguien descubre que un lote tiene una raíz posterior al estado incorrecta, puede publicar una prueba para vincularla que demuestre que el cálculo del lote es incorrecto. El contrato verificará la prueba y restaurará este lote y todos los lotes posteriores.

1. ZKRollups (rollups de conocimiento cero) , que utilizan prueba de validez: cada lote contiene una prueba criptográfica llamada ZK-SNARK (por ejemplo, utilizando el protocolo PLONK), que demuestra que la raíz posterior al estado es el resultado correcto de la ejecución del lote. No importa cuán computacionalmente intensa sea la prueba, se puede verificar muy rápidamente en la cadena.

Existen compensaciones complejas entre los dos tipos de Rollups:

propiedad	Acumulaciones optimistas	Acumulaciones de ZK
Costo fijo del gas por transacción	~40,000 (una transacción liviana que en su mayoría solo cambia el valor de la raíz del estado)	~500.000 (la verificación de ZK-SNARK requiere bastante cálculo)
Periodo de salida	~1 semana (los retiros deben retrasarse para que alguien tenga tiempo de publicar prueba de fraude y cancelar el retiro si es fraudulento)	Muy rápido (solo espera el siguiente lote)
complejidad técnica	Bajo	Alto (ZK-SNARK es una tecnología muy avanzada y compleja)
Versatilidad	Más fácil (los paquetes acumulativos de EVM universales están cerca de la red principal)	Más difícil (ZK-SNARK demuestra que la ejecución general de EVM es mucho más difícil que probar cálculos simples, aunque hay esfuerzos (por ejemplo, El Cairo) para mejorar esto)
Costo del gas en la cadena para cada transacción.	más alto	Inferior (si los datos de la transacción son solo para verificación y no para provocar un cambio de estado, estos datos se pueden omitir, mientras que en OptimisticRollups es necesario publicarlos en caso de que sea necesario verificarlos en una prueba de fraude)
Costos de cálculo fuera de la cadena	Inferior (aunque se necesitan muchos nodos completos para rehacer los cálculos)	Mayor (las pruebas ZK-SNARK, especialmente para cálculos de propósito general, pueden ser costosas, quizás miles de veces más costosas que ejecutar el cálculo directamente)

En general, a corto plazo, es probable que los Rollups de Optimistic ganen en la informática EVM de uso general, mientras que los Rollups de ZK probablemente ganen en pagos simples, intercambios y otros casos de uso específicos de aplicaciones.

Anatomía de una prueba de fraude

La seguridad de Optimistic Rollups se basa en la suposición de que si alguien publica un lote no válido en un Rollup, cualquier otra persona que detecte el fraude puede publicar una prueba de fraude, demostrando al contrato que el lote no es válido y debe restaurarse.

Como puede ver en la figura anterior, una prueba de fraude que afirme que un lote no es válido contendrá datos verdes: el lote en sí (que se puede comparar con el hash almacenado en la cadena) y las partes del árbol Merkle que solo necesitan se debe demostrar que ha sido leído y/o modificado por la cuenta específica del lote. Los nodos del árbol amarillo se pueden reconstruir a partir de los nodos verdes y, por lo tanto, no es necesario proporcionarlos. Estos datos son suficientes para ejecutar el lote y calcular la raíz posterior al estado (tenga en cuenta que esta es exactamente la misma forma en que un cliente sin estado valida un solo bloque). Si la raíz post-estado calculada no es la misma que la raíz post-estado proporcionada en el lote, entonces el lote es fraudulento.

Lo que es seguro es que si un lote se construye incorrectamente y todos los lotes anteriores se construyeron correctamente, es posible crear una prueba de fraude que indique que el lote se construyó incorrectamente. Tenga en cuenta la afirmación sobre lotes anteriores: si se publican varios lotes no válidos en un resumen, es mejor intentar demostrar que el lote más antiguo no es válido. Por supuesto, si el lote se construye correctamente, nunca es posible crear una prueba de fraude de que el lote no es válido.

Principio de compresión de datos

Una transacción simple de Ethereum (envío de ETH) requiere aproximadamente 110 bytes. Sin embargo, las transferencias ETH en Rollups solo ocupan unos 12 bytes :

parámetro	Etereum	Acumulados
Mientras tanto	~3	0
Precio del gas	~8	0-0,5
Gas	3	0-0,5
A	21	4
Valor	~9	~3
Firma	~ 68 (2 + 33 + 33)	~0.5
De	0 (recuperarse de la firma)	4
Total	~112	~12

Parte de esto es simplemente codificación de alto nivel: el RLP de Ethereum desperdicia 1 byte en la longitud de cada valor. Pero también incluye ciertas técnicas de compresión:

• Nonce : el propósito de este parámetro es evitar ataques de repetición. Si el Nonce actual de una cuenta es 5, entonces la siguiente transacción para esa cuenta debe tener un Nonce de 5; una vez que se procesa la transacción, el Nonce en la cuenta aumentará a 6, por lo que la transacción no se puede procesar nuevamente. En Rollups podemos omitir el nonce por completo, ya que solo estamos restaurando el nonce del estado anterior; si alguien intenta reproducir la transacción usando un nonce anterior, la firma no se verificará ya que la firma se comparará con datos que contengan un Nonce Check más alto.

• Gasprice : Permitimos a los usuarios pagar con un rango fijo de Gasprice, como 2 elevado a 16. O podría tener una tarifa fija en cada lote, o incluso mover el pago del gas completamente fuera del protocolo Rollups y hacer que los participantes de la transacción paguen al creador del lote a través de un canal estatal.

• Gas : También podemos limitar el Gas total a múltiples potencias de 2. O establezca límites de gas a nivel de lote.

• Para : Podemos reemplazar la dirección de 20 bytes con índice. Si una dirección es la dirección número 4527 agregada al árbol y solo usamos el índice 4527 para hacer referencia a ella, se agregará un subárbol al estado para almacenar el índice de la dirección.

• Valor : Podemos almacenar valores en notación científica. En la mayoría de los casos, las transferencias solo requieren de 1 a 3 dígitos significativos.

• Firma : podemos agregar firmas usando BLS, que permite agregar una gran cantidad de firmas en una sola firma de aproximadamente 32 a 96 bytes (según el protocolo). Luego, esta firma se puede comparar con todo el conjunto de mensajes y remitentes de un lote. El "aproximadamente 0,5" en la tabla indica que existe un límite en la cantidad de firmas que se pueden combinar en un agregado y verificar en un solo bloque, por lo que los lotes grandes requieren aproximadamente una firma por cada 100 transacciones.

Un truco de compresión importante con ZK Rollups es que si una parte de la transacción se usa solo para verificación y no tiene relevancia para calcular las actualizaciones de estado, esa parte puede permanecer fuera de la cadena . Esto no se puede hacer con Optimistic Rollups, porque si los datos deben verificarse más adelante en una prueba de fraude, los datos aún deben incluirse en la cadena, mientras que en ZKRollups, se ha demostrado que el SNARK que demuestra la exactitud del lote proporciona cualquier dato requerido para la verificación. Los rollups con función de protección de la privacidad son un ejemplo importante: en los Optimistic Rollups, se utilizan alrededor de 500 bytes para la privacidad en cada transacción, ZK-SNARK debe estar en la cadena; mientras que en ZKRollups, ZK-SNARK que cubre todo el lote ya se muestra más allá de un Dudo que el ZK-SNARK "interno" funcione.

Estas técnicas de compresión son clave para la escalabilidad de los Rollups. Sin ellos, los Rollups son probablemente sólo 10 veces más escalables que la cadena base (aunque hay algunas aplicaciones específicas de uso intensivo de cómputo donde incluso los Rollups simples son poderosos), mientras que con la compresión de datos, casi todas las aplicaciones son escalables. Ambas pueden lograr más que Mejora 100 veces .

¿Quién puede enviar lotes?

Hay muchas opiniones sobre quién puede enviar lotes en Optimistic o ZKRollups. En términos generales, todos están de acuerdo en que para poder enviar un lote, un usuario debe pagar un depósito grande; si el usuario alguna vez envía un lote fraudulento (por ejemplo, con un estado raíz no válido), el depósito será parcialmente destruido y parcialmente entregado. como recompensa Probador de fraude. Pero más allá de eso, hay muchas posibilidades:

• Anarquía total : cualquiera puede enviar un lote en cualquier momento. Este es el método más sencillo, pero tiene algunos inconvenientes importantes. Una vez que hay varios participantes, se generan lotes y se intenta enviarlos en paralelo, pero al final solo se puede empaquetar con éxito un lote. Esto da como resultado una gran cantidad de esfuerzo desperdiciado en la generación de pruebas y un desperdicio de gas en la publicación de lotes en la cadena.

• Procesamiento centralizado : Hay un secuenciador para enviar lotes (excepto para retiros: la técnica habitual es que el usuario puede enviar una solicitud de retiro primero, y luego, si el secuenciador no procesa el retiro en el siguiente lote, el usuario puede enviarlo él mismo). lote de operación única). Este es el más "eficiente", pero depende de un actor central para operar.

• Subasta de clasificador : se lleva a cabo una subasta (por ejemplo, diaria) para determinar quién tiene derecho a ser el clasificador para el día siguiente. La ventaja de esta tecnología es que puede recaudar fondos para su posterior distribución a través de un DAO controlado por Rollups. (Ver: Subasta MEV)

• Seleccionado aleatoriamente del conjunto PoS : cualquiera puede depositar ETH (o posiblemente el propio token de protocolo de Rollups) en el contrato de Rollups, y el ordenante de cada lote se selecciona aleatoriamente entre uno de los depositantes, quien es seleccionado La probabilidad es proporcional a la cantidad depositado. La principal desventaja de esta técnica es que resulta en el bloqueo de una gran cantidad de capital innecesario.

• Votación DPoS : los secuenciadores se seleccionan en la subasta, pero si tienen un rendimiento deficiente, los poseedores de tokens pueden eliminarlos y realizar una nueva subasta.

Aprovisionamiento de raíz estatal y por lotes divididos

Los paquetes acumulativos actualmente en desarrollo utilizan el método de "procesamiento por lotes divididos", es decir, enviar un lote de operaciones L2 y enviar las operaciones raíz estatales se completan por separado. Esto tiene algunas ventajas clave:

1. A muchos ordenantes se les puede permitir publicar lotes en paralelo para aumentar la resistencia a la censura sin tener que preocuparse de que algunos lotes sean invalidados porque algún otro se incluyó primero.

1. Si la raíz estatal es fraudulenta, no es necesario restaurar todo el lote; simplemente puede restaurar la raíz estatal y esperar a que alguien proporcione una nueva raíz estatal para el mismo lote. Esto proporciona a los remitentes de transacciones una mayor seguridad de que sus transacciones no serán revertidas.

En definitiva, se trata de una tecnología bastante compleja que intenta equilibrar complejos equilibrios entre eficiencia, simplicidad, resistencia a la censura y otros objetivos. Es demasiado pronto para decir qué combinación de estas ideas funcionará mejor. El tiempo lo demostrará todo.

 ¿Cuánta expansión puede aportar Rol lups? 

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 gas. Esto significa que si un bloque solo contiene un único lote (asumimos que se utilizan ZKRollups y cuestan 500 000 gas para la verificación de la prueba), entonces el lote puede tener (12 millones/16) = 750 000 bytes de datos. Como se muestra arriba, los paquetes acumulativos de transferencias ETH requieren solo 12 bytes por operación de usuario, lo que significa que el lote puede contener hasta 62,500 transacciones. En un tiempo de bloqueo promedio de 13 segundos, esto equivale a aproximadamente 4807 TPS (en comparación con los 12,5 millones/21000/13 ~= 45 TPS del propio Ethereum para transferencias directas de ETH).

A continuación se muestran diagramas para algunos otros casos de uso de ejemplo:

solicitud	Número de bytes en paquetes acumulativos	Costo de gasolina L1	Máxima ganancia de escalabilidad
transferencia ETH	12	21.000	105 veces
transferencia ERC20	16 (se utilizan otros 4 bytes para especificar qué token)	~50.000	187 veces
Comercio Uniswap	~14 (4 bytes de remitente + 4 bytes de receptor + 3 bytes de valor + 1 byte de precio máximo + 1 byte varios)	~100.000	428 veces
Acumulaciones optimistas	296 (índice raíz de 4 bytes + cavitador de 32 bytes + receptor de 4 bytes + prueba ZK-SNARK de 256 bytes)	~380.000	77 veces
Acumulaciones de ZK	40 (índice raíz de 4 bytes + cavitador de 32 bytes + receptor de 4 bytes)	~380.000	570x

La ganancia máxima de escalabilidad se calcula como (costo de gas L1) / (número de bytes en acumulaciones * 16) * 12 millones / 12,5 millones.

Vale la pena señalar que estas cifras son demasiado optimistas. Un fragmento casi nunca contendrá solo un lote, al menos porque hay y habrá múltiples paquetes acumulativos. En segundo lugar, seguirán existiendo depósitos y retiros. En tercer lugar, la utilización será baja en el corto plazo, por lo que predominarán los costos fijos. Pero incluso teniendo en cuenta estos factores, se espera que las ganancias de escalabilidad de más de 100 veces se conviertan en la norma.

Ahora bien, ¿qué pasa si queremos ir más allá de unos 1000-4000 TPS? Aquí es donde entra en juego la fragmentación de datos Eth2. La propuesta de fragmento proporciona 16 MB de espacio cada 12 segundos, lo que puede acomodar cualquier dato y garantizar la disponibilidad de esos datos. Si este espacio de datos es utilizado por Rollups, el espacio de aproximadamente 1398kb por segundo es 23 veces mayor que el de la cadena Ethereum existente y se espera que la capacidad de datos crezca aún más a largo plazo. Por lo tanto, los Rollups que utilizan datos fragmentados de Eth2 pueden procesar colectivamente hasta unas 100.000 transacciones, e incluso más en el futuro.

¿ Qué desafíos existen que  Rol·lup aún no ha abordado por completo?

Si bien los conceptos básicos de los Rollups ahora se comprenden bien, son factibles y seguros, y ya hay múltiples Rollups implementados en la red principal, todavía hay muchas áreas del diseño de Rollups que no se han explorado completamente, lo que deja gran parte del ecosistema Ethereum allí. Hay muchos desafíos a la hora de introducir contenido completo en los Rollups. Algunas preguntas clave incluyen:

• Usuarios y participación del ecosistema  : no hay muchos proyectos que utilicen Rollups, los usuarios no están familiarizados con ellos y pocas billeteras los integran. Los comerciantes y organizaciones benéficas aún no admiten este método de pago.

• Transacciones entre paquetes acumulativos  : mueva activos y datos de manera eficiente de un paquete acumulativo a otro sin incurrir en tarifas a través de L1.

• Incentivos de auditoría  : ¿Cómo maximizar la posibilidad de que al menos un nodo honesto verifique completamente un resumen optimista, de modo que cuando surjan problemas transmitan una prueba de fraude? Para acumulaciones a pequeña escala (hasta cientos de transacciones por segundo), esto no es un gran problema, porque es pan comido para los mineros, pero para acumulaciones a gran escala, se necesitan más razones suficientes para convencer a los mineros de que lo hagan. verificación.

• Explorando el espacio de diseño entre Plasma y Rollups  : ¿Existe alguna técnica para poner en cadena algunos, pero no todos, los datos relacionados con las actualizaciones de estado que producirían algo útil?

• Maximice la seguridad de la confirmación previa  : muchos paquetes acumulativos ofrecen el concepto de "confirmación previa" para una experiencia de usuario más rápida, donde el solicitante proporciona inmediatamente una promesa de que la transacción se incluirá en el siguiente lote y, si el solicitante incumple su promesa, el solicitante El depósito será destruido. Pero la seguridad económica de este programa es limitada porque es posible contraer muchos compromisos con muchos actores simultáneamente. ¿Se puede mejorar este mecanismo?

• Respuesta mejorada a clasificadores faltantes  : si el clasificador de un Rollup se desconecta repentinamente, recuperarse de esta situación en poco tiempo es un cambio rápido y de bajo costo a otro Rollup o a un clasificador diferente. Hay un costo.

• ZK-VM eficiente  : la generación de un ZK-SNARK demuestra que el código EVM genérico (o alguna VM diferente en la que se pueda compilar un contrato inteligente existente) se ha ejecutado correctamente con un resultado determinado.

 en conclusión 

Los rollups son una poderosa y novedosa solución de escalamiento L2 que se espera que sea la piedra angular del escalamiento a corto y mediano plazo (y posiblemente a largo plazo) de Ethereum. A diferencia de las extensiones L2 anteriores, pueden admitir código EVM común, lo que permite migrar fácilmente las aplicaciones existentes. Los rollups, por otro lado, han ganado gran atención en la comunidad Ethereum al comprometer que el procesamiento de transacciones no se realiza completamente fuera de la cadena, sino que cada transacción deja una pequeña porción de datos en la cadena.

Desde una perspectiva de diseño técnico, existen muchos tipos de Rollups, como Optimistic Rollups que utilizan prueba de fraude y ZKRollups (ZK-SNARK) que utilizan prueba de validez. Los rollups son todavía una tecnología temprana y en rápida evolución, y esperamos que surjan proyectos más interesantes en el espacio de los rollups en los próximos años.