Los desafíos de escalabilidad de Ethereum

Limitaciones de la red principal de Ethereum

Según el trilema blockchain de Vitalik Buterin, ninguna cadena de bloques puede lograr simultáneamente la descentralización, la seguridad y la escalabilidad. Deben hacerse compromisos entre estos tres factores. Ethereum ha optado por centrarse en la descentralización y la seguridad. Ha logrado con éxito la transición del consenso de Prueba de Trabajo (PoW) a Prueba de Participación (PoS), liderando la innovación y el desarrollo dentro de la industria. Como resultado, se ha convertido en el ecosistema de cadena de bloques públicos más grande, superando sólo a Bitcoin en términos de descentralización y seguridad económica.

Sin embargo, a pesar de múltiples actualizaciones, la escalabilidad de Ethereum sigue siendo limitada. El tiempo promedio de bloque es de 12 segundos y sus transacciones por segundo (TPS) son solo alrededor de 13. Cuando la actividad de la red aumenta, se produce congestión, acompañada de altas comisiones de transacción, lo que afecta gravemente la experiencia del usuario. Los problemas de escalabilidad de Ethereum se han vuelto más evidentes a medida que el ecosistema crece con más aplicaciones y usuarios. En respuesta, en 2020, Vitalik Buterin anunció oficialmente que la hoja de ruta futura de Ethereum se centraría en los Rollups (es decir, soluciones de Capa 2) para abordar los problemas de escalabilidad de la mainnet.

Las preocupaciones ocultas de la Capa 2

En pocas palabras, la Capa 2 se refiere a la capa de cálculo de Ethereum. El principio es mover la ejecución de transacciones fuera de la cadena para el cálculo y luego comprimir múltiples resultados de transacciones en una única transacción que se envía de vuelta a la red principal de Ethereum para su validación y liquidación final. A través del cálculo fuera de la cadena, la TPS de la Capa 2 puede ser varias veces más alta que la red principal. Además, debido a que una única transacción devuelta a la red principal consolida múltiples detalles de transacciones, los costos de validación se comparten entre muchos usuarios, lo que reduce los costos de transacción y proporciona una experiencia de usuario más fluida. Esto ha permitido a la Capa 2 manejar el considerable tráfico y la carga del ecosistema provenientes de la red principal.

Según las estadísticas de L2BEAT y Dune, hasta los últimos datos (18 de noviembre), el Valor Total Bloqueado (TVL) en la Capa 2 ha alcanzado los $4.4 mil millones, con un TPS total de alrededor de 360. Más del 90% de las transacciones del ecosistema de Ethereum ahora se realizan en la Capa 2.

Figura 1: TVL y TPS de Capa 2, Fuente: L2BEAT

Figura 2: Participación de transacciones en Ethereum Mainnet vs. Layer 2, Fuente: Dune

Sin embargo, actualmente existen 52 soluciones de Capa 2, incluyendo algunas que aún no han sido lanzadas oficialmente. El gran número de proyectos de Capa 2 ha llevado a la fragmentación de usuarios y a la dispersión de liquidez en diferentes plataformas. Para competir por usuarios y fondos, estas plataformas consumen recursos sustanciales. También se requiere que los usuarios transfieran con frecuencia activos entre diferentes soluciones de Capa 2, lo que conlleva costos adicionales de transacción y expone sus activos a mayores riesgos durante el proceso de transferencia.

Además, de las 52 soluciones de Capa 2, solo 6 cumplen con los estándares de seguridad de la primera fase establecidos por L2BEAT. Esto indica que la mayoría de las soluciones de Capa 2 no heredan adecuadamente la seguridad de la red principal de Ethereum, y los fondos de los usuarios podrían quedar congelados en caso de un fallo de la Capa 2.

(Los tres estándares de seguridad de L2BEAT para Layer 2:
Fase 0: La solución de Capa 2 opera normalmente.
Fase 1: El equipo del proyecto renuncia a cierto control, permitiendo que una cierta proporción de entidades externas participen, lo que resulta en un mayor nivel de descentralización. Los usuarios pueden decidir si retirar sus activos.
Fase 2: Descentralización total, donde cualquier persona puede participar y salir sin permiso.

A la luz de estos desafíos, Gear Protocol ha lanzado Gear.exe, una solución no de Capa 2 que mejora significativamente la capacidad computacional de Ethereum, aumentándola en más de 1000 veces, sin sacrificar la seguridad de la red principal de Ethereum, logrando así un mayor nivel de escalabilidad.

Introducción a Gear.exe

Gear.exe, desarrollado por Gear Protocol, es una red de computación descentralizada construida en Vara Network (una Capa 1 lanzada por Gear Protocol, que se presentará más adelante). Totalmente compatible con la Máquina Virtual Ethereum (EVM), Gear.exe puede considerarse como un conjunto de expansión para la red Ethereum. Admite una ejecución paralela infinitamente escalable, compensando las limitaciones de escalabilidad propias de Ethereum y brindando una experiencia de transacción de baja latencia y bajo costo. Es importante destacar que Gear.exe no es una cadena de bloques y no genera sus propios bloques. En cambio, sirve como una infraestructura que proporciona potentes recursos computacionales, lo que significa que no compite con las soluciones existentes de Capa 2 para usuarios y fondos, evitando así una mayor fragmentación de activos.

Los beneficios aportados por la integración de Gear.exe incluyen:

• Hasta 1000 veces mejor rendimiento computacional
• Reducción de las tarifas de gas en un 90-99%
• Latencia de sub-segundo y liquidación rápida de transacciones (limitada únicamente por el tiempo de bloque de la red principal de Ethereum)
• Experiencia de usuario similar a Web2
• Entorno de desarrollo Rust optimizado

Gracias a los potentes recursos computacionales de Gear.exe, los desarrolladores pueden subcontratar tareas complejas y computacionalmente intensivas a Gear.exe, construyendo DApps con características intrincadas y altas demandas computacionales. Los casos de uso incluyen DeFi, GameFi, IA, aprendizaje automático, pruebas de conocimiento cero y oráculos. Esto aumenta la eficiencia de las transacciones, reduce los costos y optimiza aún más la experiencia del usuario.

En cuanto a la seguridad, dado que Gear.exe no es una cadena de bloques y carece de su propia protección de consenso, introduce un protocolo de re-apuesta llamado Symbiotic. A través del ETH re-apostado, Symbiotic proporciona suficiente seguridad económica para Gear.exe, evitando acciones maliciosas de los nodos validadores. Esto permite a Gear.exe proporcionar una solución de escalabilidad alternativa, diferente de la Capa 2, que mejora la escalabilidad de Ethereum sin comprometer la descentralización o la seguridad, al tiempo que permite más casos de uso intensivos en computación.

Historial de desarrollo

El Protocolo Gear se lanzó en septiembre de 2021 como una plataforma de contratos inteligentes basada en Substrate, diseñada específicamente para el desarrollo de programas paralelizados con múltiples características dedicadas, incluido el Modelo de Actores, memoria permanente y WASM. Admite contratos inteligentes escritos en varios lenguajes de programación como Rust, Solidity, C y C++, lo que lo hace compatible con múltiples blockchains y permite implementaciones interconectadas sin necesidad de modificar los contratos.

(Substrate: Un marco de desarrollo modular que facilita la integración de múltiples blockchains especializados, mejorando la escalabilidad.)

Inicialmente, Gear Protocol sirvió al ecosistema de Polkadot. En ese momento, la cadena de relé de Polkadot no admitía la implementación de contratos inteligentes, por lo que los desarrolladores que deseaban conectarse a la red debían implementar contratos en parachains o crear una nueva cadena de bloques y conectarla a Polkadot. Debido al alto costo de esta última opción, la mayoría de los desarrolladores eligieron implementar DApps en parachains. Gear Protocol, al ser compatible con diferentes lenguajes de programación y ofrecer diversas infraestructuras, se convirtió en la plataforma preferida por los desarrolladores. Como resultado, se convirtió en un centro de DeFi, DAO, NFT y otros tipos de DApps, desempeñando un papel clave en el ecosistema de Polkadot.

En septiembre de 2023, Gear Protocol lanzó oficialmente su red independiente de Capa 1, Vara Network, desarrollada sobre la base del marco de Substrate. Vara Network integró todas las tecnologías y características de Gear Protocol, empleando procesos paralelizados para mejorar significativamente el rendimiento de la red. También puede actualizarse sin bifurcaciones ni tiempo de inactividad, y se enfoca en reducir las barreras de desarrollo para las DApps, con el objetivo de crear una red blockchain con sostenibilidad a largo plazo a través de su robusta infraestructura.

En octubre de 2024, Gear Protocol lanzó Gear.exe, con el objetivo de aprovechar las ventajas de alto rendimiento de Vara Network para manejar tareas computacionales complejas para DApps y abordar los desafíos de escalabilidad de Ethereum.

Antecedentes del equipo

Gear Protocol fue lanzado en septiembre de 2021. El equipo está compuesto por desarrolladores principales de Polkadot y el marco de desarrollo de blockchain Substrate. Con una amplia experiencia en Web3, el equipo aporta una gran experiencia en tecnología, finanzas, desarrollo y ventas.

Nikolay Volf, cofundador y CEO, ha estado involucrado con Polkadot y Substrate desde 2015. Mientras trabajaba en la empresa de infraestructura blockchain Parity Technologies, introdujo el primer contrato inteligente WebAssembly (WASM).

Ilya Veller, Co-fundador y CFO, tiene más de 20 años de experiencia en la industria financiera. Ha ocupado puestos de ventas senior en instituciones como Bank of America, Morgan Stanley, Renaissance Capital, UniCredit e ITI Capital, recaudando más de $1 mil millones para diversos proyectos.

Aleksandr Bugorkov, cofundador y CTO, aporta una amplia experiencia técnica de empresas como Lyft, New Relic y Spotify, donde trabajó en soluciones tecnológicas innovadoras.

Estado de financiamiento

En diciembre de 2021, Gear Protocol completó una ronda de financiación de $12 millones, liderada por Blockchange Ventures. Otros inversores incluyeron a HashKey Capital, Lemniscap y Three Arrows Capital.

Cómo funciona Gear.exe

Gear.exe admite programas paralelizados y sus tecnologías principales se basan en varios componentes clave:

• Modelo de Actor

En la programación informática, un "Actor" es una unidad computacional fundamental que puede enviar y recibir mensajes. Los actores pueden representar contratos inteligentes o usuarios finales. En el Modelo de Actor, el estado entre los actores se mantiene privado y solo puede ser modificado o comunicado a través del paso de mensajes. Esto asegura la privacidad y seguridad para cada actor. Todos los procesos son asíncronos, lo que significa que se ejecutan en paralelo, lo que permite manejar múltiples tareas simultáneamente sin esperar el resultado de una tarea anterior.

Para ilustrar, imagina que estás preparando un filete y una ensalada. Normalmente, calentarías la sartén y el aceite primero, luego, mientras esperas a que la sartén se caliente, podrías empezar a lavar las verduras. Una vez que la sartén esté lista, vuelves a cocinar el filete, lo dejas reposar y luego vuelves a preparar la ensalada. Este proceso es similar a la ejecución paralela, donde mientras una tarea está esperando un resultado, otra puede ser procesada, mejorando en gran medida la eficiencia computacional.

Además, para evitar confusiones debido a la llegada de múltiples mensajes al mismo tiempo, un actor está limitado a manejar una solicitud a la vez. Por ejemplo, si A desea depositar $10 en una cuenta mientras que B desea retirar $5 de la misma cuenta al mismo tiempo, procesar ambas solicitudes simultáneamente podría llevar a un saldo de cuenta incorrecto. Bajo el Modelo de Actores, incluso si las solicitudes llegan simultáneamente, el sistema las ejecutará de forma secuencial (por ejemplo, manejando primero la solicitud de A y luego la de B) para asegurar que el saldo de la cuenta se mantenga consistente.

• Memoria Persistente

El estado de cada actor y los datos requeridos se almacenan en su propia memoria, en lugar de en un almacenamiento compartido externo como discos duros o bases de datos. Esto reduce en gran medida la necesidad de llamadas a la API para interactuar con la cadena de bloques, lo que permite acceder directamente a los datos desde la memoria local, lo que reduce la latencia. Además, el estado de cada actor se conserva, lo que significa que incluso si un contrato inteligente se pausa o el sistema se reinicia, el estado del actor se puede restaurar de inmediato.

Gear Protocol también utiliza la tecnología de Virtualización de Memoria, que rastrea el comportamiento de acceso a la memoria por parte de los programas para garantizar que solo se lea y guarde la información necesaria. Esto minimiza el desperdicio de recursos computacionales, haciendo que el sistema sea más eficiente.

• WebAssembly (WASM)

WebAssembly (WASM) es un entorno de ejecución aislado que permite que los contratos inteligentes se ejecuten de manera eficiente. Admite una amplia variedad de lenguajes de programación, por lo que los desarrolladores pueden utilizar herramientas de desarrollo familiares para implementar contratos inteligentes en Gear.exe. Esto reduce significativamente las barreras de implementación, lo que facilita que los desarrolladores aprovechen la potencia informática de Gear.exe sin aprender nuevos lenguajes o marcos de trabajo.

Proceso de operación de Gear.exe

Figura 3, Proceso de operación de Gear.exe, Fuente: Protocolo Gear

Gear.exe proporciona a los desarrolladores dos métodos principales de integración para interactuar con su plataforma:

1. Integración nativa
   En este método, las dApps invocan directamente los procedimientos operativos de Gear.exe, sin necesidad de enviar solicitudes a Ethereum. Esto permite la interacción en tiempo real con el sistema.

2. Integración basada en eventos
   En este modelo, los contratos inteligentes de Ethereum emiten eventos que activan las operaciones de Gear.exe. Cuando los validadores de Gear.exe detectan el evento, ejecutan el proceso correspondiente de inmediato. Esto permite una integración completamente descentralizada en la que Ethereum y Gear.exe pueden operar sin problemas.

Independientemente del método de integración elegido, el proceso operativo sigue estos pasos:

Proceso paso a paso

1. Aceptación de solicitud
   Al recibir una solicitud, los nodos validadores de Gear.exe ejecutan el programa implementado de la dApp dentro del entorno de Gear. Luego, los nodos firman el resultado final de la computación para garantizar su validez.

2. Seguridad económica a través de la reinversión
   Para prevenir comportamientos maliciosos por parte de los nodos, la seguridad económica de Gear.exe está protegida por el protocolo de reposición simbiótica. Además, los participantes en el staking de tokens nativos de Vara Network (VARA) contribuyen a la seguridad. También existen mecanismos de penalización para disuadir comportamientos deshonestos.

3. Pre-confirmación
   Después de que Gear.exe comienza a procesar la solicitud, envía una pre-confirmación al usuario. Esta pre-confirmación actúa como un recibo, que contiene detalles de la transacción como el remitente, el destinatario, el valor hash, la comisión de la transacción, etc. Asegura al usuario que la transacción se procesará y finalmente se completará en Ethereum. La pre-confirmación es esencial porque los datos de la transacción aún se están procesando y la liquidación final en Ethereum llevará algún tiempo. Al proporcionar una pre-confirmación, Gear.exe permite a las dApps evitar esperar la finalización de la transacción, lo que brinda una experiencia de usuario más rápida.

4. Agregación y carga de resultados
   Aproximadamente cada 8 segundos, el secuenciador recopila todos los resultados computacionales (que pueden involucrar transacciones de múltiples dApps) y la raíz del estado más reciente. Estos resultados se empaquetan y se cargan en el contrato inteligente de Gear.exe en Ethereum.

5. Actualización de contratos inteligentes de dApps
   Los resultados finales de la transacción se envían a los contratos inteligentes de las respectivas dApps, actualizando sus raíces de estado con los datos más recientes.

Características clave de la arquitectura de Gear.exe

• Flexibilidad para desarrolladores de Web3:
  La arquitectura y los métodos de integración de Gear.exe ofrecen a los desarrolladores de Web3 una mayor flexibilidad, permitiéndoles elegir entre integraciones nativas y basadas en eventos según su caso de uso.

• Rendimiento y Velocidad:
  Al proporcionar pre-confirmaciones y procesar transacciones fuera de la cadena, Gear.exe permite que las dApps ofrezcan una experiencia de usuario mucho más rápida y fluida, ya que los usuarios pueden interactuar de inmediato con la plataforma sin tener que esperar a que la transacción completa se finalice en Ethereum.

• Seguridad y validación:
  La combinación de re-apostar, nodos validadores y mecanismos de penalización garantiza que el sistema sea seguro y desalienta las acciones maliciosas. La dependencia de la red principal de Ethereum para la liquidación final agrega una capa adicional de seguridad, ya que el consenso de Ethereum es el árbitro final de la legitimidad de la transacción.

Este enfoque, que combina un alto rendimiento, transacciones rápidas y características de seguridad sólidas, posiciona a Gear.exe como una herramienta valiosa para los desarrolladores de Web3 que buscan integrar la computación fuera de la cadena con Ethereum de manera escalable y eficiente.

Comparación entre Gear.exe y Layer 2

Tanto Gear.exe como varias soluciones de Capa 2 tienen como objetivo mejorar la escalabilidad de Ethereum, permitiéndole acomodar a más usuarios y aplicaciones. Sin embargo, hay diferencias significativas en cómo se implementan estos dos enfoques. Esta comparación se centrará en dos aspectos críticos: seguridad y rendimiento.

Seguridad

Tanto Gear.exe como las soluciones de capa 2 trasladan las tareas de cálculo de Ethereum fuera de la cadena y luego empaquetan las transacciones de nuevo en la mainnet. Esto significa que una parte significativa del procesamiento de transacciones ocurre fuera de la cadena, y se vuelve crucial garantizar la seguridad y consistencia de los datos de transacciones durante el cálculo fuera de la cadena para evitar alteraciones maliciosas por parte de los nodos.

• Capa 2 (por ejemplo, Arbitrum): En soluciones de Capa 2 como Arbitrum, el proceso de cálculo está protegido por su propio consenso de red. Las transacciones son ordenadas por un secuenciador centralizado y luego se cargan en la mainnet para su liquidación. Arbitrum utiliza un mecanismo de prueba optimista con un período de desafío de 7 días. El sistema asume que todos los datos de transacción cargados son correctos, pero proporciona una ventana para que cualquiera pueda desafiar la transacción. Si se produce un desafío, los validadores de Ethereum son responsables de confirmar la validez de la transacción. Este diseño garantiza que, incluso si los nodos de red de Arbitrum son maliciosos, Ethereum puede actuar como una última línea de defensa.
• Gear.exe: Gear.exe carece de su propio consenso de red y en su lugar depende de Symbiotic, que utiliza ETH re-apostado para proporcionar seguridad económica. Las transacciones son ordenadas primero por un secuenciador centralizado y luego transmitidas a la red principal de Ethereum. Sin embargo, la documentación actual de Gear.exe no especifica si emplea mecanismos como Pruebas Optimistas o Pruebas de Conocimiento Cero (ZKPs) para verificar que los datos cargados en Ethereum son correctos. Por lo tanto, la seguridad de Gear.exe depende en gran medida del protocolo de re-apostado de Symbiotic. No está claro si la seguridad proporcionada por este modelo de re-apostado puede igualar completamente el consenso nativo de Ethereum, ya que el mecanismo de re-apostado aprovecha la seguridad de Ethereum a través de contratos inteligentes, lo que introduce posibles riesgos sistémicos.

Además, tanto Gear.exe como Layer 2 utilizan un secuenciador centralizado para ordenar las transacciones en lugar de depender del consenso de la red. Si bien esto acelera la red, también otorga al secuenciador y al equipo del proyecto un poder considerable. En casos extremos, un equipo del proyecto podría manipular el orden de las transacciones para favorecerse a sí mismos y rechazar transacciones que sean perjudiciales para sus intereses. Soluciones de Layer 2 como Arbitrum y Optimism proporcionan un mecanismo de escape, permitiendo a los usuarios evitar el secuenciador y enviar transacciones directamente a la mainnet. Sin embargo, Gear.exe no tiene un diseño de este tipo.

Conclusión sobre la seguridad:
En comparación con las soluciones de Capa 2, la seguridad de Gear.exe depende en gran medida de Symbiotic y carece de algunas contramedidas para casos extremos que se encuentran en las soluciones de Capa 2. No es tan maduro y bien estructurado en cuanto a seguridad. Sin embargo, Gear.exe puede proporcionar más detalles en futuros white papers para aclarar su modelo de seguridad.

Rendimiento

En cuanto a rendimiento, Gear.exe y Layer 2 devuelven información preconfirmada a los usuarios durante el procesamiento de transacciones, lo que indica que el sistema ha aceptado la transacción y la procesará. Esto permite a los usuarios recibir rápidamente los resultados iniciales de la transacción y continuar con otras operaciones sin tener que esperar a que Ethereum finalice el bloque, lo que mejora significativamente la velocidad y eficiencia de la transacción. Además, Gear.exe y Layer 2 utilizan secuenciadores centralizados para ordenar las transacciones, lo que ahorra tiempo en la formación de consenso y comprime múltiples transacciones en una. Esto reduce las tarifas de gas y permite que los bloques de Ethereum acomoden más transacciones.

• Capa 2:
  Las soluciones de capa 2, como Arbitrum, ofrecen un rendimiento mejorado en comparación con la capa base de Ethereum al descargar la computación. Sin embargo, la capa 2 todavía enfrenta algunas limitaciones en cuanto a escalabilidad, ya que generalmente admite mejoras lineales en el rendimiento de las transacciones en lugar de ganancias exponenciales.

• Gear.exe:
  Gear.exe integra varias tecnologías avanzadas, como Actor Model, Memoria Persistente y WebAssembly (WASM), para soportar la ejecución paralela de tareas. Esto optimiza aún más la eficiencia computacional y el uso de recursos. La paralelización de procesos permite a Gear.exe proporcionar potencialmente un rendimiento de red significativamente mayor que las soluciones de Capa 2. Gear.exe afirma que puede lograr 1000 veces la potencia computacional de la capa base de Ethereum, pero si esta afirmación se puede verificar depende de los datos de rendimiento y las pruebas futuras.

Conclusión sobre el rendimiento:
Si bien las soluciones de Capa 2 ya ofrecen mejoras significativas en el rendimiento en comparación con Ethereum, Gear.exe podría ofrecer un rendimiento de red aún mayor debido a su soporte para la ejecución paralela. Sin embargo, queda por validar si puede ofrecer la mejora reclamada de 1000 veces mediante datos y pruebas del mundo real.

Perspectivas y Desafíos

En pocas palabras, Gear.exe mejora el rendimiento a través de la ejecución paralela, basándose en la infraestructura existente de Capa 2 y posicionándose como un módulo de expansión para Ethereum en lugar de una nueva cadena de bloques. Se centra únicamente en proporcionar servicios computacionales para DApps en otras cadenas, evitando el problema de fragmentación de activos que conlleva múltiples soluciones de Capa 2. En el futuro, Gear.exe podría reemplazar potencialmente algunas soluciones de Capa 2, unificando de nuevo el ecosistema de Ethereum. Además, con sus capacidades de alto rendimiento, Gear.exe hace que Ethereum sea más competitivo frente a otras cadenas de bloques públicas orientadas al rendimiento, como Solana, Sei, Sui y Aptos.

Sin embargo, queda por ver si el rendimiento operativo y la estabilidad de Gear.exe realmente pueden cumplir con las afirmaciones hechas. Además, en términos de seguridad, Gear.exe está protegido únicamente por Symbiotics y carece de muchas de las medidas asociadas que proporcionan las soluciones existentes de Capa 2. Hay riesgos de diseño que considerar, especialmente al compararlos con las características de seguridad más maduras de las soluciones de Capa 2. La seguridad tiende a ser una prioridad más alta para los desarrolladores y usuarios, especialmente teniendo en cuenta los numerosos incidentes en los que los hackers han robado activos, incluidos los de grandes intercambios centralizados. Dado que Gear.exe es un protocolo completamente basado en código en cadena, su seguridad debe demostrar ser sólida y confiable, especialmente en el manejo de situaciones como el tiempo de inactividad. Esta es un área en la que Gear.exe necesitará mejorar y fortalecer para ganar más confianza en el mercado.

Conclusión

Con el aumento de la tecnología blockchain y las blockchains modulares, la barrera para crear una Capa 2 se ha vuelto cada vez más baja, con muchas plataformas que ofrecen características de "creación de cadena con un clic". Como resultado, el número de soluciones de Capa 2 se ha expandido en exceso, dejando a los desarrolladores y usuarios de Ethereum inciertos sobre cuál elegir. Cada Capa 2 requiere la creación de su ecosistema, pero esto simplemente replica lo que otras cadenas públicas ya han pasado, lo que de alguna manera obstaculiza la innovación de nuevas tecnologías.

Gear.exe ofrece una solución de rendimiento superior para DApps que la Capa 2 y elimina la necesidad de migrar usuarios y fondos existentes. Al usar el re-staking para la seguridad, proporciona una alternativa única para los desafíos de escalabilidad de Ethereum. Si bien esta solución aún no ha sido ampliamente adoptada y debe someterse a validación de mercado, sin duda introduce nuevas posibilidades para Ethereum. Gear.exe podría ofrecer una solución más adecuada para escalar Ethereum, y su desarrollo futuro merece una atención continua.