Compilado por: 0xMlze, Salve Boccaccio y 0xMunehisa
Compilado por: Shenchao TechFlow
Soluciones de nivel 2
La red principal de Ethereum maneja actualmente un promedio de 12 transacciones por segundo y, durante los períodos de máxima actividad de la red, los costos de transacción han alcanzado niveles que son inaceptables para la mayoría de los usuarios. Este problema de escalabilidad surge de la necesidad de que cada nodo de la red almacene y verifique todas las transacciones que ocurren en la red.
Para resolver este problema y escalar Ethereum, se inventaron soluciones de Capa 2 (L2). La segunda capa es una cadena de bloques independiente que extiende Ethereum y hereda las garantías de seguridad de Ethereum. La segunda capa es esencialmente una cadena de bloques independiente donde los usuarios realizan transacciones fuera de la cadena principal (Ethereum). Cada solución de Capa 2 tiene sus propias garantías y compensaciones de seguridad. En Ethereum, la forma más popular de escalado de segunda capa son los Rollups (Arbitrum, Optimism, zkSync).
Acumulados
Los rollups son soluciones L2 que procesan transacciones en L1 antes de regresar a L1. Una transacción estándar en Ethereum suele tener 156 bytes, siendo la firma la parte con mayor densidad de datos. Por lo tanto, Rollups procesa múltiples transacciones en el entorno de ejecución L2 y luego las agrupa en una sola transacción que se envía a L1 para una verificación periódica del estado. Agrupar varias transacciones en una reduce la tarifa del gas pagada por transacción porque la tarifa del gas se distribuye entre varias transacciones, no solo una. Sin embargo, no todos los Rollups son iguales, existen muchos tipos diferentes de Rollups:
Paquetes acumulativos de contratos inteligentes: paquetes acumulativos optimistas (Arbitrum, Optimism), paquetes acumulativos de conocimiento cero (zkEVM, zkSync, Scroll de Matic);
Celestios;
Resúmenes consagrados;
Acumulaciones soberanas.
Resúmenes de contratos inteligentes
Los Rollups de Contratos Inteligentes son donde los usuarios envían fondos a un contrato inteligente Rollup en L1, que luego administra las transacciones y los cambios de estado.
Los rollups y un componente clave de blockchain son los árboles Merkle. Los árboles Merkle son estructuras de datos que almacenan el estado de financiación de cada persona y las transacciones que se produjeron, lo que permite a L1 verificar el estado en L2 sin descargar el estado completo. En pocas palabras, los usuarios interactúan y realizan transacciones en L2 (y por lo tanto cambian de estado), y L2 envía periódicamente la raíz Merkle del estado a L1 para que L1 pueda verificar el estado de la cadena.
Además de publicar la raíz de Merkle en L1, L2 debe publicar suficientes datos de cambios del árbol de Merkle para que el usuario pueda reconstruir completamente el árbol de Merkle. Si por alguna razón L2 deja de funcionar, el usuario quedará atrapado en L2 sin proporcionar estos datos. Por lo tanto, el contrato inteligente L1 tiene una "función de emergencia" donde los usuarios pueden retirar sus fondos del contrato inteligente cuando L2 deja de ejecutarse.
L1 requiere algún tipo de prueba para garantizar que la raíz de Merkle enviada por L2 sea válida, y esta es la diferencia entre los dos principales paquetes acumulativos de contratos inteligentes. Los dos tipos principales de pruebas utilizadas son las pruebas de fraude y las pruebas de conocimiento cero.
Resumen optimista
OptimisticRollups como Arbitrum y Optimism utilizan pruebas de fraude para la confirmación final del estado. La prueba de fraude funciona así:
Los nodos L2 publican la raíz de Merkle en el contrato inteligente L1 junto con un pequeño depósito.
Los contratos inteligentes L1 confían en los nodos L2 de forma predeterminada, que es lo que significa la palabra "optimista": L1 es optimista acerca de las actualizaciones de L2.
Sin embargo, este cambio de estado no se finalizará hasta dentro de 7 días.
Durante estos 7 días, cualquiera puede presentar una prueba de que la raíz de Merkle enviada es fraudulenta, lo que revocará la actualización y penalizará al nodo L2 entregándole el depósito a la persona que informó la actualización fraudulenta.
El reportero puede demostrar que una actualización es fraudulenta verificando todas las transacciones que ocurrieron en el cambio de raíz del estado y confirmando que cada firma en esas transacciones era válida. Esto se debe a que el nodo L2 publica la raíz de Merkle y suficientes datos de cambios de Merkle para recrear el árbol de Merkle.
Si la transición de estado no se impugna dentro del período de disputa de 7 días, la actualización se finalizará y se considerará inmutable.
Acumulación de ZK
ZK Rollup utiliza pruebas de conocimiento cero. Así es como funcionan:
El nodo de Capa 2 publica la raíz de Merkle en el contrato inteligente L1 junto con prueba de que L2 procesó correctamente la transacción y generó una nueva raíz de Merkle.
Si los nodos de Capa 2 intentan publicar una actualización fraudulenta, no podrán generar una prueba de conocimiento cero válida y, por lo tanto, el contrato inteligente L1 no aceptará la nueva raíz de Merkle.
Una vez que se verifica la prueba de conocimiento cero, las actualizaciones de estado se completan de inmediato.
Clasificador
El secuenciador es el mecanismo mediante el cual L2 recopila y publica transacciones en la cadena base de Ethereum. En su estado centralizado actual, funcionan de la siguiente manera:
Los usuarios envían transacciones en L2: DeFi, NFT, envío/recepción y más.
Estas transacciones son recopiladas por un secuenciador centralizado.
El secuenciador (construcción de bloques) luego clasifica estas transacciones (datos de llamada/diferencias de estado) en un solo bloque o lote de transacciones.
Actualmente, el secuenciador L2 clasifica estas transacciones utilizando un método de clasificación primero en entrar, primero en salir (FIFO).
Luego, el secuenciador envía este lote de transacciones a la red principal de Ethereum para su inclusión en un bloque.
En su estado actual, el secuenciador de Rollup está centralizado y controlado por una sola entidad (Offchain Labs de Arbitrum y Optimism PBC de Optimism). Esta centralización crea un único punto de falla para Rollup y puede provocar problemas de vida (y falta de resistencia a la censura): si el secuenciador falla, el L2 no funcionará correctamente.
Por ejemplo, a principios de junio, el secuenciador de Arbitrum encontró un error que provocó que los lotes se revirtieran en la cadena, lo que resultó en una pérdida de costo de gas para el lote. Durante un corto período de tiempo, el remitente del lote se quedó sin combustible y no pudo enviar transacciones a Ethereum correctamente.
Tarifa de gas L2
Ahora echemos un vistazo a cómo los dos principales contratos inteligentes calculan las tarifas de gas que pagarán los usuarios y el impacto en los pedidos centralizados.
En Arbitrum y Optimism, los usuarios pagan dos tarifas al realizar transacciones:
L2Gas/Comisión de Ejecución;
Llamadas L1 cargos por datos/seguridad.
L2Gas/tarifa de ejecución
Las tarifas del gas L2 son similares a las tarifas del gas de Ethereum. Cada transacción en L2 está sujeta a una tarifa de ejecución/gas igual a la cantidad de gas utilizada por la transacción multiplicada por el precio actual del gas adjunto a la transacción.
Datos de llamada L1/Cargos de seguridad
Las tarifas de datos de llamadas L1 se pagan para cubrir el costo de publicar las transacciones en Ethereum. Esta tarifa existe porque el secuenciador o remitente del lote debe pagar una tarifa de gas L1 para publicar transacciones en Ethereum.
Modelo de ingresos del clasificador
En su forma actual, Optimistic Rollup (ORU) genera ingresos mediante la operación de un único secuenciador centralizado. En el futuro, se espera que ORU eventualmente se descentralice, lo que abrirá la puerta a otras fuentes de ingresos a través de MEV (Maximización del valor de Ethereum) o exigirá que los operadores de pedidos apuesten tokens nativos/compartan los ingresos.
Pero por ahora, en la representación más simple, podemos pensar en el clasificador que cobra tarifas de transacción L2 a los usuarios de ORU (ingresos del clasificador) y necesita pagar tarifas de gas L1 para enviar por lotes los datos de transacciones L2 de los usuarios a la red Ethereum (Costo 1). y para cubrir los costos operativos de operación del secuenciador (Costo 2).
Llevando esto un paso más allá, podemos desglosar los ingresos y los costos en sus componentes específicos. Si bien las diferentes ORU (por ejemplo, Arbitrum, Optimism) no tienen exactamente la misma fórmula de precios, siguen un marco común:
Ingresos (tarifas de gas L2)
Tarifas = L1_gas_price_estimate * (L1_calldata_size + L1_buffer) + L2_gas_price * L2_gas_used
costo
Costos = L1_precio_actual_gas * L1_calldata_size + Secuenciador_operacional_costos
Precio de la tarifa L2
En todas las ORU, el precio de cargo L2 es una función de la escala de cómputo L1, el costo de cómputo L1, la escala de cómputo L2 y el costo de cómputo L2.
Dado que todos los secuenciadores L2 incurren en costos al publicar lotes/pruebas en la red principal L1, es lógico pasar el costo dinámico de la liquidación de la red principal a los usuarios cuando se ejecutan las transacciones L2.
Arbitrum y Optimism valoran sus tarifas L2 de manera diferente. Una diferencia muy importante entre los dos es la forma en que Optimism y Arbitrum calculan los costos computacionales L1. Arbitrum utiliza un oráculo que fija el precio de los cálculos L1, lo que significa que sin votos de gobernanza, el oráculo fija el precio de los cálculos L1 de la misma manera que antes de 4844. Sin embargo, el cálculo L1 de Optimism incluye una variable dinámica (escalar) que el equipo de Optimism puede ajustar para ajustar el costo de cálculo L1.
Decisión
El precio de la tarifa L2 de Arbitrum implementa el concepto de "tarifas de gas bidimensionales", donde el límite de gas es una función de las unidades de gas utilizadas por L2, las unidades de gas utilizadas por L1 y el precio estimado de L1Gas.
De esto podemos sacar las siguientes conclusiones:
El límite de Gas L2 disminuye a medida que aumenta el precio del Gas L2.
El límite de gas L2 aumenta con el cálculo de L2, el precio del gas L1 y el cálculo de L1.
Optimismo
Al igual que Arbitrum, las tarifas de transacción de Optimism tienen en cuenta el costo de los cálculos L1 y L2. El optimismo llama a esto tarifa de ejecución L2 y tarifa de seguridad/datos L1.
Aviso:
La variable dinámica_overhead es una variable establecida por el equipo de Optimism para garantizar que sus ordenantes reciban una compensación adecuada para cubrir el costo del gas incurrido al enviar lotes de transacciones a la red L1.
Actualmente está fijado en 0,684, lo que significa que el secuenciador está subsidiando el coste del gas.
Históricamente, este valor se ha establecido principalmente por encima de 1, lo que indica que el secuenciador está cobrando más para mantener el buffer de gas de asentamiento L1.
Tarifas de gestión dinámica a lo largo del tiempo / tarifas escalares L1
EIP-4844
Actualmente, el Rollup de Optimistic es menos costoso en términos de ejecución y almacenamiento de Capa 2, pero publicar datos en Capa 1 sigue siendo costoso para los usuarios a fin de cumplir con la disponibilidad de datos.
Los datos se publican en la Capa 1 de Ethereum utilizando el código de operación calldata, por lo que tanto Arbitrum como Optimism implementan algoritmos de compresión de calldata, como los algoritmos de compresión Zlib y brotli. Esta publicación de datos es costosa y representa entre el 80% y el 90% de las tarifas de transacción que pagan los usuarios de L2.
Sin embargo, entre octubre de 2023 y febrero de 2024, está previsto que se lance la propuesta de mejora de Ethereum de alto perfil (EIP-4844, Proto-danksharding). EIP-4844 propone agregar un nuevo tipo de transacción a Ethereum que permita la aceptación de "bloques de datos". Estos "fragmentos" se eliminan o eliminan después de aproximadamente dos semanas y no se almacenan permanentemente como los datos de llamadas existentes. El tamaño de estos bloques de datos está diseñado para ser lo suficientemente pequeño como para reducir la sobrecarga de almacenamiento en la cadena de la red principal.
Las altas tarifas de transacción en Ethereum Layer 1 (L1) son el costo principal de L2 Rollup al emitir lotes y pruebas. El impacto de EIP-4844 en esto es reducir significativamente los costos generales de L1 y al mismo tiempo permitir que los datos por lotes estén disponibles el tiempo suficiente para que se emitan pruebas de fraude. Las estimaciones actuales sitúan este factor de ahorro en un rango de entre 10 y 100 veces el coste del lanzamiento del lote L1 actual.
Descripción general de alto nivel del impacto en los ingresos de los secuenciadores
Antes de profundizar en los cambios que esperamos ver en Arbitrum y Optimism, es importante que consideremos las diferencias en los precios de cómputo L1 entre Arbitrum y Optimism (como se explica en la sección anterior sobre precios de tarifas L2). Dado el oráculo de precios L1 de Arbitrum, ahora sabemos que probablemente traspasará el 100% de las tarifas a los usuarios (a menos que veamos una votación de gobernanza). Este no es el caso del Optimismo, ya que todavía controla la variable sobrecarga dinámica.
La siguiente tabla nos proporciona posibles resultados después de EIP-4844.
Decisión
Dado el estado actual de la salud financiera de Arbitrum en la sección anterior, exploramos posibles cambios en la valoración de Arbitrum bajo ciertos supuestos. Dado que se espera que los costos sean significativamente más bajos después de EIP-4844, se espera que las ganancias y los márgenes aumenten mientras que los ingresos se mantienen sin cambios.
En base a esto, creamos una tabla que muestra varios resultados posibles, incluidas diferentes combinaciones de ahorros de EIP-4844 transferidos a los usuarios (eje Y) y factores de reducción de costos de EIP-4844 (eje X, números mayores = ahorros de EIP4844 cuanto mayor sea el costo).
Hemos sombreado las combinaciones que creemos que es más probable que ocurran después de EIP-4844.
Si el 100% de los ahorros se transfiriera a los usuarios, podemos suponer que este ahorro de costos podría aumentar potencialmente la cantidad de transacciones en Arbitrum (nuevos tipos de dApp, más usuarios).
Haga algunas suposiciones:
Mantener la actual relación precio-beneficio (P/E);
Supongamos una reducción de costos de 10 veces;
El volumen de transacciones crece debido al ahorro de tarifas.
Podemos calcular el impacto de estos cambios en los precios de ARB y OP. Por ejemplo, si el volumen de Tx creciera un 40% y solo el 90% de los ahorros en tarifas se transfirieran a los usuarios, el precio de ARB sería de $2,10.
Optimismo
Haciendo el mismo cálculo para Optimismo obtenemos los siguientes resultados.
Economía y valoración del token L2
Actualmente, la única acumulación de valor de Arbitrum y Optimism es la gobernanza; esta es la única función de ARB y OP. Sin embargo, la acumulación de valor en ARB y OP puede provenir de otras dos fuentes: tarifas de transacción y MEV.
En su estado actual, estas dos soluciones L2 dependen en gran medida de sus encargados centralizados, y todas estas ganancias de propuestas y construcción de bloques centralizados se transfieren a la Fundación Arbitrum y la Fundación Optimismo. Sin embargo, ambas soluciones han prometido avanzar hacia un mecanismo secuenciador descentralizado donde la fundación no es la única entidad que construye y propone bloques L2. El primer paso hacia la acumulación de valor para los tokens L2 es descentralizar el ordenante, lo cual no es fácil, pero puede permitir que los poseedores de tokens L2 participen en el valor generado a través del proceso de construcción y propuesta.
Es probable que la descentralización del secuenciador se logre a través de un mecanismo PoS, donde los usuarios apostarán tokens L2 nativos. Si el apostador no cumple con sus deberes o actúa de mala fe, se reducirá la apuesta. Las partes interesadas pueden recibir una parte de las tarifas de transacción, MEV (en un mundo posterior a FIFO) o recompensas de apuesta en forma de tokens nativos.
La importancia de un ordenador descentralizado es que un ordenador centralizado puede hacer que las transacciones de los usuarios sean censuradas, extraer rentas excesivas o generar MEV dañino, afectando negativamente a los usuarios.