Análisis de la actualización técnica de Ethereum: The Surge
Desde octubre de este año, el cofundador de Ethereum ha publicado una serie de artículos sobre las posibilidades futuras del protocolo de Ethereum, abarcando seis partes del mapa de desarrollo de Ethereum. Este artículo interpretará la segunda parte de la serie, The Surge, enfocándose en la escalabilidad de Ethereum y su desarrollo a largo plazo. A partir del mapa de ruta técnica de esta etapa, podemos profundizar en cómo Ethereum se transformará en un protocolo capaz de manejar una gran demanda (TPS alcanzando 100,000+) y al mismo tiempo mantener la descentralización y la seguridad.
Visión central de Ethereum
En esencia, Ethereum está diseñado para ser la capa base de un internet descentralizado. Ether soporta aplicaciones descentralizadas complejas a través de contratos inteligentes automáticos, lo que le brinda la flexibilidad para ser la blockchain preferida por los desarrolladores para construir aplicaciones descentralizadas, incluyendo DeFi, NFT y más.
Sin embargo, Ethereum tiene limitaciones en términos de escalabilidad. Ethereum L1 solo puede procesar aproximadamente de 15 a 30 transacciones por segundo, lo que representa una gran diferencia con respecto a las redes de pago tradicionales. Esto da lugar a tarifas de gas elevadas durante períodos de congestión de la red y limita la capacidad de Ethereum para convertirse en una infraestructura de escala global. Este es precisamente el problema que The Surge se propone abordar.
Los principales objetivos de The Surge son los siguientes:
Ethereum L1+L2 alcanza 100,000+ TPS;
Mantener la descentralización y la solidez de L1;
Al menos algunos L2 heredan completamente las propiedades fundamentales de Ethereum (sin necesidad de confianza, abierto, resistente a la censura);
Maximizar la interoperabilidad entre L2: Ethereum debería ser como un ecosistema, en lugar de decenas de cadenas de bloques diferentes.
El futuro centrado en rollup
The Surge se refiere al plan de Ethereum para aumentar significativamente la escalabilidad, principalmente a través de soluciones L2. Y el rollup es una parte clave de esta estrategia. La hoja de ruta centrada en rollup propone una simple división de trabajo: Ethereum L1 se enfoca en convertirse en una capa base poderosa y descentralizada, mientras que L2 asume la tarea de ayudar a expandir el ecosistema.
Rollup empaqueta las transacciones fuera de la cadena y luego las envía de regreso a la red principal de Ethereum, aumentando significativamente el rendimiento mientras mantiene la seguridad y la descentralización. Rollup puede aumentar la escalabilidad de Ethereum a más de 100,000 TPS. Esto será una expansión transformadora, ya que permite a Ethereum manejar aplicaciones de escala global sin comprometer el espíritu de descentralización.
La hoja de ruta centrada en rollup se considera una solución de escalado a largo plazo. Ethereum 2.0 ha reducido el consumo de energía al pasar de PoW a PoS a través de The Merge, mientras que rollup se considera el próximo hito importante como solución de escalado a largo plazo.
Este año, la hoja de ruta centrada en rollup ha logrado importantes resultados: con el lanzamiento de los blobs EIP-4844, el ancho de banda de datos de Ethereum L1 ha aumentado significativamente, y múltiples rollups de la Máquina Virtual de Ethereum (EVM) han entrado en la primera fase. Cada L2 existe como un fragmento con sus propias reglas y lógica internas, y la diversidad y variabilidad de las implementaciones de fragmentos se han convertido en una realidad.
Muestreo de disponibilidad de datos (DAS)desarrollo adicional
Otro aspecto clave de The Surge es el muestreo de disponibilidad de datos (DAS), una técnica diseñada para abordar los problemas de disponibilidad de datos. En redes descentralizadas como Ethereum, es crucial que todos los nodos puedan verificar los datos sin necesidad de almacenar o descargar todo el contenido.
DAS permite a los nodos verificar datos sin acceder al conjunto de datos completo, lo que mejora la escalabilidad y la eficiencia.
Existen dos formas de DAS: PeerDAS y 2D DAS. PeerDAS promete mejorar la hipótesis de confianza en el rollup, haciéndolo más seguro. 2D DAS no solo realiza muestreo aleatorio dentro del blob, sino también entre los blobs. Aprovechando las propiedades lineales de los compromisos KZG, se expande el conjunto de blobs en un bloque a través de un nuevo conjunto de blobs virtuales que codifican la misma información redundante.
Con DAS, Ethereum puede manejar una mayor cantidad de datos, lo que permite rollups más rápidos y baratos, sin comprometer la descentralización.
En etapas futuras más avanzadas, se necesitará hacer más trabajo para determinar la versión ideal de 2D DAS y demostrar sus propiedades de seguridad.
El camino de realidad a largo plazo es:
Implementar un DAS 2D ideal;
Seguir utilizando 1D DAS, sacrificando la eficiencia del ancho de banda de muestreo, aceptando un límite de datos más bajo por simplicidad y robustez;
Abandonar DA y aceptar completamente Plasma como la principal arquitectura Layer2.
Es importante señalar que, incluso si se decide expandir la ejecución directamente en la capa L1, esta opción existe. Esto se debe a que si la capa L1 tiene que manejar una gran cantidad de TPS, los bloques L1 se volverán muy grandes, y los clientes querrán tener un método eficiente para verificar su corrección, por lo que tendrán que utilizar en la capa L1 las mismas tecnologías que los rollups (como ZK-EVM y DAS).
Plasma y otras soluciones
Además de Rollup, Plasma, una de las soluciones de escalado fuera de la cadena propuestas en sus inicios, también es otra solución L2.
Plasma crea subcadenas, las cuales procesan transacciones de manera independiente a la cadena principal de Ethereum y envían resúmenes a la red principal de forma regular. Para cada bloque, el operador envía a cada usuario una rama Merkle para probar el estado de cambio de los activos de ese usuario. Los usuarios pueden retirar sus activos proporcionando la rama Merkle. Es importante señalar que esta rama no tiene que tener el estado más reciente como raíz.
Por lo tanto, incluso si hay problemas de disponibilidad de datos, los usuarios aún pueden recuperar sus activos extrayendo el estado más reciente disponible. Si un usuario presenta una rama inválida (por ejemplo, intentando extraer activos que ya se han enviado a otros, o si el operador crea un activo de la nada), se puede determinar la legítima pertenencia de los activos a través del mecanismo de desafío en la cadena.
Aunque el desarrollo de Plasma ha quedado rezagado en cierta medida respecto a rollup, todavía se considera parte del conjunto de herramientas de escalabilidad más amplio de Ethereum.
Además, hay discusiones sobre la mejora de las técnicas de compresión de datos y las pruebas criptográficas para aumentar aún más la eficiencia de los rollups y otras soluciones L2. La idea es comprimir la mayor cantidad posible de datos, asegurando al mismo tiempo que toda la información necesaria siga estando disponible para la validación por parte de los nodos de Ethereum. Estas mejoras tecnológicas probablemente desempeñarán un papel clave en el proceso de alcanzar un mayor rendimiento en Ethereum.
Las versiones tempranas de Plasma solo podían manejar casos de pago y no podían expandirse de manera efectiva. Sin embargo, si se exige que cada raíz sea verificada mediante SNARK, Plasma se volvería mucho más robusto. Su proceso puede simplificarse enormemente, ya que se excluyen la mayoría de las posibles rutas de trampa de los operadores. Al mismo tiempo, se abren nuevas rutas, en las que los usuarios pueden retirar fondos de inmediato sin tener que esperar una semana para el período de desafío, siempre que los operadores no hagan trampa.
Una forma de crear una cadena plasma EVM (no es el único método) es: construir un árbol UTXO paralelo utilizando ZK-SNARK que refleje los cambios de saldo realizados por EVM, definiendo un mapeo único de "la misma moneda" en diferentes períodos históricos. Luego se puede construir una estructura Plasma sobre esta base.
El rendimiento de Plasma es bastante bueno, esta es también la razón clave por la que todos deben diseñar estructuras de técnicas para superar sus deficiencias de seguridad.
Mejora de la interoperabilidad entre L2
Uno de los principales desafíos que enfrenta el ecosistema L2 actual es la débil interoperabilidad entre L2. Es urgente mejorar cómo hacer que la experiencia de usar el ecosistema L2 se sienta como si estuvieras utilizando un ecosistema Ethereum unificado.
Las mejoras en la interoperabilidad entre L2 tienen muchas categorías. En teoría, Ethereum centrado en Rollup es similar a L1 con fragmentación de ejecución. El actual ecosistema L2 de Ethereum enfrenta los siguientes problemas en la práctica que lo alejan de un estado ideal:
Dirección de cadena específica: la dirección debe contener información sobre la cadena (L1, Optimism, Arbitrum, ......). Una vez que se logre esto, se puede realizar el proceso de envío entre L2 simplemente colocando la dirección en el campo de envío, momento en el cual la billetera puede manejar en segundo plano cómo enviar (incluyendo el uso de protocolos de cadena cruzada).
Solicitudes de pago en cadenas específicas: debería ser capaz de crear fácilmente y de manera estandarizada un mensaje en forma de "En la cadena Z, envíame X tokens de tipo Y". Esto tiene principalmente dos escenarios de aplicación: pagos entre personas o pagos entre personas y servicios de comerciantes; solicitudes de financiación de dApps.
Intercambio entre cadenas y pago de Gas: debe haber un protocolo abierto estandarizado para expresar operaciones entre cadenas. ERC-7683 y RIP-7755 son intentos en este campo, aunque el alcance de ambos es más amplio que estos casos de uso específicos.
Cliente ligero: los usuarios deben poder verificar realmente la cadena con la que están interactuando, y no solo confiar en el proveedor de RPC. ERC-3668 (CCIP-read) es una estrategia para lograr este objetivo.
Concepto de puente de tokens compartidos: Supongamos que en un mundo donde todos los L2 son rollups de prueba de validez y cada slot se presenta a Ethereum, para transferir un activo de un L2 a otro en estado nativo, aún se requiere un retiro y un depósito, lo que implica pagar una gran cantidad de tarifas de Gas L1.
Una forma de resolver este problema es: crear un Rollup compartido y minimalista, cuya única función sea mantener qué L2 posee cada tipo de token y cuántos saldos tiene, y permitir que estos saldos se actualicen en lotes a través de una serie de operaciones de envío entre L2 iniciadas por cualquier L2. Esto haría que las transferencias entre L2 no requieran pagar la tarifa de gas de L1 en cada transferencia, ni utilizar tecnologías basadas en proveedores de liquidez como ERC-7683.
Sincronización combinatoria: permite que se realicen llamadas sincronizadas entre L2 específicas y L1 o entre múltiples L2. Esto ayuda a mejorar la eficiencia financiera de los protocolos DeFi. El primero se puede lograr sin ninguna coordinación entre L2; el segundo requiere un orden compartido. La tecnología basada en rollup se aplica automáticamente a todas estas tecnologías.
Muchos de los ejemplos anteriores enfrentan el dilema de cuándo estandarizar y qué capas estandarizar. Si la estandarización se realiza demasiado pronto, puede arraigar una solución deficiente. Si se realiza demasiado tarde, puede provocar una fragmentación innecesaria.
Un consenso actual es que, en ciertas circunstancias, existe una solución a corto plazo que tiene propiedades más débiles pero es más fácil de implementar, así como una solución a largo plazo que es "finalmente correcta" pero que requiere años para ser realizada. Estas tareas no son solo problemas técnicos, también son (e incluso pueden ser principalmente) problemas sociales, que requieren la colaboración de L2, billeteras y L1.
Continuar expandiendo Ethereum L1
Ampliar Ethereum L1 en sí mismo y asegurarse de que pueda seguir acomodando cada vez más casos de uso es muy valioso.
Existen tres estrategias para la expansión L1, que se pueden llevar a cabo de forma individual o en paralelo:
Mejorar la tecnología (como el código del cliente, el cliente sin estado, la expiración histórica) para hacer que L1 sea más fácil de verificar y luego aumentar el límite de Gas;
Reducir el costo de operaciones específicas, aumentando la capacidad media sin aumentar el riesgo en el peor de los casos;
Rollups nativos (es decir, crear N copias paralelas de EVM).
Estas diferentes tecnologías tienen distintas compensaciones. Por ejemplo, los rollups nativos tienen la misma debilidad en términos de combinabilidad que los rollups normales: no se puede enviar una única transacción para ejecutar operaciones de manera sincronizada a través de múltiples rollups. Aumentar el límite de Gas puede debilitar otros beneficios que se pueden lograr al simplificar la verificación de L1, como aumentar la proporción de usuarios que ejecutan nodos de verificación, así como aumentar el número de stakers solitarios. Dependiendo de la forma en que se implementen, hacer que ciertas operaciones en EVM sean más baratas puede aumentar la complejidad general de EVM.
Descentralización y seguridad
El equilibrio entre escalabilidad y descentralización es uno de los temas mencionados repetidamente. Muchos proyectos de blockchain optan por sacrificar la descentralización a cambio de un mayor rendimiento. Por ejemplo, cierta blockchain cada
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
12 me gusta
Recompensa
12
7
Compartir
Comentar
0/400
DiamondHands
· 07-25 01:37
Otra vez hablando de tps, suspirando.
Ver originalesResponder0
0xSoulless
· 07-23 21:11
tps vuelve a subir, también son tontos que están de un lado a otro.
Ver originalesResponder0
WenAirdrop
· 07-22 23:20
tps tan alto, he vivido para verlo.
Ver originalesResponder0
FloorSweeper
· 07-22 08:45
manos de papel todavía creen en eth lmao
Ver originalesResponder0
CryptoFortuneTeller
· 07-22 08:45
Viene un trabajo, eth puede alcanzar 100k tps
Ver originalesResponder0
MrRightClick
· 07-22 08:31
¿Solo 10w tps? Realmente no es suficiente.
Ver originalesResponder0
AirdropHunterWang
· 07-22 08:30
Ya está todo. Espero que las tarifas de gas bajen un poco.
Actualización de Ethereum The Surge: El camino de escalabilidad con el objetivo de más de 100,000 TPS
Análisis de la actualización técnica de Ethereum: The Surge
Desde octubre de este año, el cofundador de Ethereum ha publicado una serie de artículos sobre las posibilidades futuras del protocolo de Ethereum, abarcando seis partes del mapa de desarrollo de Ethereum. Este artículo interpretará la segunda parte de la serie, The Surge, enfocándose en la escalabilidad de Ethereum y su desarrollo a largo plazo. A partir del mapa de ruta técnica de esta etapa, podemos profundizar en cómo Ethereum se transformará en un protocolo capaz de manejar una gran demanda (TPS alcanzando 100,000+) y al mismo tiempo mantener la descentralización y la seguridad.
Visión central de Ethereum
En esencia, Ethereum está diseñado para ser la capa base de un internet descentralizado. Ether soporta aplicaciones descentralizadas complejas a través de contratos inteligentes automáticos, lo que le brinda la flexibilidad para ser la blockchain preferida por los desarrolladores para construir aplicaciones descentralizadas, incluyendo DeFi, NFT y más.
Sin embargo, Ethereum tiene limitaciones en términos de escalabilidad. Ethereum L1 solo puede procesar aproximadamente de 15 a 30 transacciones por segundo, lo que representa una gran diferencia con respecto a las redes de pago tradicionales. Esto da lugar a tarifas de gas elevadas durante períodos de congestión de la red y limita la capacidad de Ethereum para convertirse en una infraestructura de escala global. Este es precisamente el problema que The Surge se propone abordar.
Los principales objetivos de The Surge son los siguientes:
El futuro centrado en rollup
The Surge se refiere al plan de Ethereum para aumentar significativamente la escalabilidad, principalmente a través de soluciones L2. Y el rollup es una parte clave de esta estrategia. La hoja de ruta centrada en rollup propone una simple división de trabajo: Ethereum L1 se enfoca en convertirse en una capa base poderosa y descentralizada, mientras que L2 asume la tarea de ayudar a expandir el ecosistema.
Rollup empaqueta las transacciones fuera de la cadena y luego las envía de regreso a la red principal de Ethereum, aumentando significativamente el rendimiento mientras mantiene la seguridad y la descentralización. Rollup puede aumentar la escalabilidad de Ethereum a más de 100,000 TPS. Esto será una expansión transformadora, ya que permite a Ethereum manejar aplicaciones de escala global sin comprometer el espíritu de descentralización.
La hoja de ruta centrada en rollup se considera una solución de escalado a largo plazo. Ethereum 2.0 ha reducido el consumo de energía al pasar de PoW a PoS a través de The Merge, mientras que rollup se considera el próximo hito importante como solución de escalado a largo plazo.
Este año, la hoja de ruta centrada en rollup ha logrado importantes resultados: con el lanzamiento de los blobs EIP-4844, el ancho de banda de datos de Ethereum L1 ha aumentado significativamente, y múltiples rollups de la Máquina Virtual de Ethereum (EVM) han entrado en la primera fase. Cada L2 existe como un fragmento con sus propias reglas y lógica internas, y la diversidad y variabilidad de las implementaciones de fragmentos se han convertido en una realidad.
Muestreo de disponibilidad de datos (DAS)desarrollo adicional
Otro aspecto clave de The Surge es el muestreo de disponibilidad de datos (DAS), una técnica diseñada para abordar los problemas de disponibilidad de datos. En redes descentralizadas como Ethereum, es crucial que todos los nodos puedan verificar los datos sin necesidad de almacenar o descargar todo el contenido.
DAS permite a los nodos verificar datos sin acceder al conjunto de datos completo, lo que mejora la escalabilidad y la eficiencia.
Existen dos formas de DAS: PeerDAS y 2D DAS. PeerDAS promete mejorar la hipótesis de confianza en el rollup, haciéndolo más seguro. 2D DAS no solo realiza muestreo aleatorio dentro del blob, sino también entre los blobs. Aprovechando las propiedades lineales de los compromisos KZG, se expande el conjunto de blobs en un bloque a través de un nuevo conjunto de blobs virtuales que codifican la misma información redundante.
Con DAS, Ethereum puede manejar una mayor cantidad de datos, lo que permite rollups más rápidos y baratos, sin comprometer la descentralización.
En etapas futuras más avanzadas, se necesitará hacer más trabajo para determinar la versión ideal de 2D DAS y demostrar sus propiedades de seguridad.
El camino de realidad a largo plazo es:
Es importante señalar que, incluso si se decide expandir la ejecución directamente en la capa L1, esta opción existe. Esto se debe a que si la capa L1 tiene que manejar una gran cantidad de TPS, los bloques L1 se volverán muy grandes, y los clientes querrán tener un método eficiente para verificar su corrección, por lo que tendrán que utilizar en la capa L1 las mismas tecnologías que los rollups (como ZK-EVM y DAS).
Plasma y otras soluciones
Además de Rollup, Plasma, una de las soluciones de escalado fuera de la cadena propuestas en sus inicios, también es otra solución L2.
Plasma crea subcadenas, las cuales procesan transacciones de manera independiente a la cadena principal de Ethereum y envían resúmenes a la red principal de forma regular. Para cada bloque, el operador envía a cada usuario una rama Merkle para probar el estado de cambio de los activos de ese usuario. Los usuarios pueden retirar sus activos proporcionando la rama Merkle. Es importante señalar que esta rama no tiene que tener el estado más reciente como raíz.
Por lo tanto, incluso si hay problemas de disponibilidad de datos, los usuarios aún pueden recuperar sus activos extrayendo el estado más reciente disponible. Si un usuario presenta una rama inválida (por ejemplo, intentando extraer activos que ya se han enviado a otros, o si el operador crea un activo de la nada), se puede determinar la legítima pertenencia de los activos a través del mecanismo de desafío en la cadena.
Aunque el desarrollo de Plasma ha quedado rezagado en cierta medida respecto a rollup, todavía se considera parte del conjunto de herramientas de escalabilidad más amplio de Ethereum.
Además, hay discusiones sobre la mejora de las técnicas de compresión de datos y las pruebas criptográficas para aumentar aún más la eficiencia de los rollups y otras soluciones L2. La idea es comprimir la mayor cantidad posible de datos, asegurando al mismo tiempo que toda la información necesaria siga estando disponible para la validación por parte de los nodos de Ethereum. Estas mejoras tecnológicas probablemente desempeñarán un papel clave en el proceso de alcanzar un mayor rendimiento en Ethereum.
Las versiones tempranas de Plasma solo podían manejar casos de pago y no podían expandirse de manera efectiva. Sin embargo, si se exige que cada raíz sea verificada mediante SNARK, Plasma se volvería mucho más robusto. Su proceso puede simplificarse enormemente, ya que se excluyen la mayoría de las posibles rutas de trampa de los operadores. Al mismo tiempo, se abren nuevas rutas, en las que los usuarios pueden retirar fondos de inmediato sin tener que esperar una semana para el período de desafío, siempre que los operadores no hagan trampa.
Una forma de crear una cadena plasma EVM (no es el único método) es: construir un árbol UTXO paralelo utilizando ZK-SNARK que refleje los cambios de saldo realizados por EVM, definiendo un mapeo único de "la misma moneda" en diferentes períodos históricos. Luego se puede construir una estructura Plasma sobre esta base.
El rendimiento de Plasma es bastante bueno, esta es también la razón clave por la que todos deben diseñar estructuras de técnicas para superar sus deficiencias de seguridad.
Mejora de la interoperabilidad entre L2
Uno de los principales desafíos que enfrenta el ecosistema L2 actual es la débil interoperabilidad entre L2. Es urgente mejorar cómo hacer que la experiencia de usar el ecosistema L2 se sienta como si estuvieras utilizando un ecosistema Ethereum unificado.
Las mejoras en la interoperabilidad entre L2 tienen muchas categorías. En teoría, Ethereum centrado en Rollup es similar a L1 con fragmentación de ejecución. El actual ecosistema L2 de Ethereum enfrenta los siguientes problemas en la práctica que lo alejan de un estado ideal:
Dirección de cadena específica: la dirección debe contener información sobre la cadena (L1, Optimism, Arbitrum, ......). Una vez que se logre esto, se puede realizar el proceso de envío entre L2 simplemente colocando la dirección en el campo de envío, momento en el cual la billetera puede manejar en segundo plano cómo enviar (incluyendo el uso de protocolos de cadena cruzada).
Solicitudes de pago en cadenas específicas: debería ser capaz de crear fácilmente y de manera estandarizada un mensaje en forma de "En la cadena Z, envíame X tokens de tipo Y". Esto tiene principalmente dos escenarios de aplicación: pagos entre personas o pagos entre personas y servicios de comerciantes; solicitudes de financiación de dApps.
Intercambio entre cadenas y pago de Gas: debe haber un protocolo abierto estandarizado para expresar operaciones entre cadenas. ERC-7683 y RIP-7755 son intentos en este campo, aunque el alcance de ambos es más amplio que estos casos de uso específicos.
Cliente ligero: los usuarios deben poder verificar realmente la cadena con la que están interactuando, y no solo confiar en el proveedor de RPC. ERC-3668 (CCIP-read) es una estrategia para lograr este objetivo.
Concepto de puente de tokens compartidos: Supongamos que en un mundo donde todos los L2 son rollups de prueba de validez y cada slot se presenta a Ethereum, para transferir un activo de un L2 a otro en estado nativo, aún se requiere un retiro y un depósito, lo que implica pagar una gran cantidad de tarifas de Gas L1.
Una forma de resolver este problema es: crear un Rollup compartido y minimalista, cuya única función sea mantener qué L2 posee cada tipo de token y cuántos saldos tiene, y permitir que estos saldos se actualicen en lotes a través de una serie de operaciones de envío entre L2 iniciadas por cualquier L2. Esto haría que las transferencias entre L2 no requieran pagar la tarifa de gas de L1 en cada transferencia, ni utilizar tecnologías basadas en proveedores de liquidez como ERC-7683.
Muchos de los ejemplos anteriores enfrentan el dilema de cuándo estandarizar y qué capas estandarizar. Si la estandarización se realiza demasiado pronto, puede arraigar una solución deficiente. Si se realiza demasiado tarde, puede provocar una fragmentación innecesaria.
Un consenso actual es que, en ciertas circunstancias, existe una solución a corto plazo que tiene propiedades más débiles pero es más fácil de implementar, así como una solución a largo plazo que es "finalmente correcta" pero que requiere años para ser realizada. Estas tareas no son solo problemas técnicos, también son (e incluso pueden ser principalmente) problemas sociales, que requieren la colaboración de L2, billeteras y L1.
Continuar expandiendo Ethereum L1
Ampliar Ethereum L1 en sí mismo y asegurarse de que pueda seguir acomodando cada vez más casos de uso es muy valioso.
Existen tres estrategias para la expansión L1, que se pueden llevar a cabo de forma individual o en paralelo:
Estas diferentes tecnologías tienen distintas compensaciones. Por ejemplo, los rollups nativos tienen la misma debilidad en términos de combinabilidad que los rollups normales: no se puede enviar una única transacción para ejecutar operaciones de manera sincronizada a través de múltiples rollups. Aumentar el límite de Gas puede debilitar otros beneficios que se pueden lograr al simplificar la verificación de L1, como aumentar la proporción de usuarios que ejecutan nodos de verificación, así como aumentar el número de stakers solitarios. Dependiendo de la forma en que se implementen, hacer que ciertas operaciones en EVM sean más baratas puede aumentar la complejidad general de EVM.
Descentralización y seguridad
El equilibrio entre escalabilidad y descentralización es uno de los temas mencionados repetidamente. Muchos proyectos de blockchain optan por sacrificar la descentralización a cambio de un mayor rendimiento. Por ejemplo, cierta blockchain cada