Reenviado el Título Original: Diseñador Blockspace: El Futuro de los Entornos de Ejecución

En los nueve años desde que Ethereum lanzó la primera cadena de bloques descentralizada y programable, las criptomonedas han enfrentado múltiples obstáculos en la búsqueda de escalar aplicaciones descentralizadas para miles de millones de usuarios. Y para desarrollar soluciones de escalabilidad que aborden esto, la industria de las criptomonedas ha financiado y desarrollado continuamente nuevos tipos de cadenas de bloques para resolver el "problema de rendimiento".

Sin embargo, el “problema de rendimiento” ha sido pobremente definido y cuantificado. Los memes sintéticos como “transacciones por segundo” han empaquetado hábilmente lo que realmente son comparaciones entre peras y manzanas entre transacciones que no requieren un trabajo computacional equivalente. La falta de matices en estas métricas también oscurece nuestra capacidad para evaluar los impactos independientes de los componentes de una cadena de bloques en el rendimiento, distrayéndonos de un enfoque fundamentado para identificar los conjuntos de optimizaciones que podemos hacer para resolver problemas altamente interdependientes.

A pesar de esta niebla, hemos visto mejoras creíbles y sostenidas en la escalabilidad de la cadena de bloques durante los últimos años. A medida que Ethereum avanza en su hoja de ruta centrada en rollups, una nueva ola de rollups, coprocesadores,disponibilidad de datos(DA) capas, y están surgiendo L1s competidores, cada uno con elecciones de diseño únicas para proporcionar a los desarrolladores entornos más eficientes para construir dapps escalables y fáciles de usar.

Hoy, la introducción de EIP4844 y las capas alternativas de DA han aliviado el cuello de botella crítico de DA. A pesar de este hito crítico, las pruebas sugieren que se deben resolver otros cuellos de botella importantes. El mes pasado, Baserecogido$1.57M en tarifas de transacción en un solo díamientras pagaba solo $5K en costos de disponibilidad de datos a Ethereum. Esto sugiere que el trabajo computacional requerido para validar y procesar actualizaciones de estado sigue siendo un cuello de botella crítico y una oportunidad de mejora.

Este artículo evaluará las decisiones de diseño tomadas tanto por los entornos de ejecución integrados como modulares en su camino para resolver un mayor rendimiento y ampliar el alcance de las aplicaciones que pueden vivir onchain.

Desafíos de hoy

El rendimiento de una capa de ejecución puede ser evaluado según el trabajo computacional que los nodos ejecutores logran en relación con el tiempo de bloque de sus cadenas, o "gas computado por segundo".

Con esto en mente, podemos reducir los cuellos de botella de la capa de ejecución a dos factores interconectados: acceso ineficiente al estado y computación ineficiente.

El acceso ineficiente al estado se refiere a los gastos generales de recuperación y actualización del estado de la cadena de bloques, lo cual puede ralentizar el procesamiento de transacciones. Por otro lado, la computación ineficiente es una función de los gastos generales incurridos por los algoritmos que ejecutan operaciones y transiciones de estado, lo cual puede incluir desde simples transferencias hasta contratos inteligentes complejos y verificaciones de firmas.

Estos cuellos de botella se refuerzan mutuamente: los retrasos en el acceso al estado pueden prolongar el tiempo de cálculo, mientras que las prácticas computacionales ineficientes pueden tensar la gestión del estado. Además, las mejoras propuestas para abordar estos problemas a menudo requieren mejoras sistémicas como el particionamiento o la adopción de arquitecturas sin estado, que mejoran el acceso al estado y la eficiencia de cálculo para mejorar el rendimiento de ejecución.

Cuello de botella #1: Acceso ineficiente al estado

El costo y la velocidad necesarios para acceder al estado de una cadena de bloques son cuellos de botella críticos para entornos de ejecución eficientes y se pueden reducir al problema de la hinchazón del estado.

En blockchains, el estado del mundo se gestiona y actualiza a través de estructuras de datos específicas llamadas árboles. Los árboles son fundamentales para las blockchains, proporcionando una forma segura y eficiente de brindar a las partes externas al nodo ejecutor garantías sobre el estado correcto de la blockchain. Cada actualización dentro de un trie genera un nuevo hash de raíz, al cual los clientes ligeros pueden hacer referencia para verificar transacciones y saldos de cuentas sin necesidad de mantener toda la cadena.

Ethereum específicamente depende de una estructura de datos conocida como el árbol de Patricia de Merkle (MPT), que comprende @chiqing/merkle-patricia-trie-explained-ae3ac6a7e123">four sub-tries.

A medida que Ethereum añade más contratos inteligentes y tokens a su estado, su árbol de estado se vuelve más grande y complejo. A medida que el estado crece, requiere más espacio de almacenamiento, más recursos computacionales para procesar y más ancho de banda para transmitir. Al mismo tiempo, las limitaciones de hardware del nodo permanecen aproximadamente iguales.

Este crecimiento del estado impacta directamente en el rendimiento de Ethereum porque el estado se almacena en disco, y las operaciones de disco incurren en una alta sobrecarga. Mientras que acceder a datos desde un registro de CPU puede tomar 0.1 nanosegundos, puede llevar entre 10 y 100 microsegundos(100x–1000x más lento)para acceder a datos desde un disco, aproximadamente se traduce en 200,000 instrucciones de CPU que podrían haberse ejecutado en ese tiempo. ¡Eso equivale a una estimación conservadora de 36 transferencias ERC-20 que podrían haberse realizado!

Exacerbando este problema, las blockchains tienen muchos patrones de acceso ineficientes para leer y escribir en el estado. Por ejemplo, la estructura no secuencial del árbol de Merkle Patricia conduce inherentemente a estas operaciones de entrada/salida (E/S) de disco que leen y escriben en varias ubicaciones impredecibles en el disco. La naturaleza aleatoria de las entradas de transacción y los cambios de estado subsiguientes que provocan conducen a un patrón de acceso a datos dispersos que ralentiza significativamente el proceso de verificación y actualización del estado y solo utiliza una parte de uncapacidad del dispositivo de hardware.

En resumen, los primitivos de gestión estatal para blockchains están lejos de alcanzar su potencial absoluto, y se pueden hacer numerosos avances para mejorar la eficiencia computacional.

Cuello de botella #2: Computación ineficiente

Las capas de ejecución también enfrentan el cuello de botella de la computación ineficiente, que se manifiesta de varias formas.

Por un lado, muchos procesan transacciones de forma secuencial, subutilizando los modernos procesadores multinúcleo capaces de manejar múltiples operaciones simultáneamente. Esta ejecución secuencial conduce a tiempos de inactividad de la CPU inevitables entre transacciones, desperdiciando valiosos recursos computacionales.

Además, el uso de máquinas virtuales implica traducir operaciones de contrato inteligente de alto nivel a bytecode, un código de nivel inferior e independiente de la plataforma, que luego se ejecuta instrucción por instrucción. Este proceso de traducción y ejecución introduce una sobrecarga significativa, especialmente para aplicaciones con tareas específicas de la aplicación complejas y frecuentemente repetidas.

Estas ineficiencias conducen a una utilización subóptima de los recursos computacionales y obstaculizan el rendimiento de las capas de ejecución.

Soluciones: Acceso ineficiente al estado

Hay algunas formas distintas en las que los equipos están mejorando la velocidad a la que se puede recuperar y actualizar el estado del hardware de un nodo en ejecución, incluyendo la simplificación de estructuras de datos complejas y la búsqueda de formas de reducir las costosas operaciones de E/S en disco que provocan la inflación del estado.

Estado de no pertenencia & Computación en memoria

Algunas capas de ejecución abordan la sobrecarga de estado simplemente aceptándola a corto plazo. Desplazan el almacenamiento de datos de estado de sistemas basados en disco más lentos a la memoria de acceso aleatorio (RAM) más rápida. Acceder a la información de estado en RAM reduce significativamente la sobrecarga asociada con las operaciones de disco, que son más lentas y requieren más recursos.

Sin embargo, este enfoque desafía el principio central de descentralización. Almacenar cantidades cada vez mayores de datos de estado en RAM requiere hardware más avanzado y costoso, lo que podría limitar la capacidad de los individuos para participar como operadores de nodos. En consecuencia, a medida que los requisitos de hardware aumentan, menos entidades pueden permitirse ejecutar estos nodos.

Para equilibrar la atracción de la informática en memoria con la minimización de la confianza, tanto L1s (como Ethereum) como L2s están siguiendo una hoja de ruta de escalabilidad que se basa en desglosar el papel de un validador en nodos ejecutores separados y centralizados con muchos nodos verificadores. En este modelo, los productores de bloques altamente eficientes con los requisitos de hardware para computar en memoria son responsables de generar bloques, y las pruebas criptográficas (pruebas de fraude y de validez) son aprovechadas por los nodos verificadores para mantener a los productores de bloques responsables.

Como resultado, estos sistemas deberían permitir a los productores de bloques maximizar su velocidad porque se espera que calculen en memoria, eliminando por completo las E/S de disco durante la ejecución. Dado que la latencia de la RAM suele ser inferior a 100 nanosegundos, la latencia del acceso al estado se reduce hasta en 1000 veces en comparación con las implementaciones basadas en disco.

En paralelo, las pruebas de fraude y validez se utilizan en lugar de un consenso descentralizado para escalar las propiedades de minimización de confianza del sistema junto con su rendimiento. Como resultado, los nodos potentes y centralizados productores de bloques se contrarrestan con nodos verificadores que pueden funcionar en hardware mucho menos costoso. Estos nodos realizan la función crítica de verificar de forma independiente las pruebas de transiciones de estado (o transiciones de estado inválidas) para mantener una vista precisa del estado sin la carga de almacenar todo el estado de la cadena de bloques.

Para facilitar este proceso de forma minimalista en confianza, las capas de ejecución deben implementar un grado de apatridia, siendo el más popular el concepto de “debilidad de estado”. La debilidad del estado se logra al exigir que los productores de bloques proporcionen una certificación criptográfica conocida como una testigoa un nodo verificador. Este testigo encapsula todos los cambios de estado propuestos por el nuevo bloque, lo que permite a los validadores verificar estos cambios sin datos históricos adicionales.

Aunque este concepto se puede aplicar utilizando varias estructuras de árboles, los árboles Verkle suelen ser preferidos a los árboles Merkle por su eficiencia. Los árboles Merkle requieren la inclusión de todos los hashes de nodos hermanos a lo largo del camino desde un punto de datos (hoja) hasta la raíz del árbol para demostrar la integridad de los datos. Este requisito significa que el tamaño del testigo (la prueba de integridad) crece con la altura del árbol, ya que cada nivel requiere hashes adicionales. En consecuencia, verificar la integridad de los datos en los árboles Merkle se vuelve intensivo en computación y costoso, especialmente para conjuntos de datos grandes. En contraste, los árboles Verkle simplifican este proceso, reduciendo la sobrecarga asociada con la computación y el almacenamiento en la generación y verificación de nuevos bloques.

Verkle tree escalando desde el “Verkle Tree” inevitable de Ethereum

Los árboles Verkle mejoran la estructura de los árboles Merkle tradicionales al simplificar las conexiones entre las hojas y la raíz y eliminar la necesidad de incluir nodos hermanos en el proceso de verificación. En un árbol Verkle, verificar una prueba implica solo el valor en el nodo hoja, un compromiso con el nodo raíz y un compromiso vectorial único basado en compromisos polinómicos, que reemplaza los múltiples compromisos basados en hash que se encuentran en los árboles Merkle. Este cambio permite a los árboles Verkle mantener un testigo de tamaño fijo, que no aumenta con la altura del árbol o el número de hojas verificadas, mejorando significativamente la eficiencia de almacenamiento y computación durante la verificación de datos.

En los próximos años, veremos implementaciones de la falta de estado o statelessness suceder en los niveles L1 y L2 con configuraciones variables. Según la última hoja de ruta de Ethereum, los validadores pueden confiar en los constructores de bloques para proporcionar pruebas Verkle con respecto al estado de ciertos bloques y verificar estas pruebas ligeras en lugar de mantener el estado de Ethereum directamente.

A nivel L2, equipos como MegaETHestán aplicando activamente el concepto de sin estado al diseño de rollups optimistas. En su diseño, el nodo secuenciador genera un testigo para cada bloque que contiene los valores de estado necesarios y los hashes intermedios mientras emite un delta de estado que representa los cambios en el estado. Los nodos verificadores pueden luego reejecutar cualquier bloque recuperando el testigo de la capa DA o una red peer-to-peer sin almacenar todo el estado. Al mismo tiempo, los nodos completos actualizan su estado aplicando los deltas de estado diseminados a través de la red, lo que les permite mantenerse sincronizados sin reejecutar transacciones o almacenar todo el historial de estado.

Sin embargo, también vale la pena señalar que los beneficios de la falta de estado y la capacidad resultante de calcular en la memoria no son una solución milagrosa para el rendimiento de la capa de ejecución.

TPS en tiempo real de "Understanding Ethereum Execution Layer Performance" de MegaETH

Como cofundador de MegaETH, Yilong Li, identifica en lo siguientepresentación de investigaciónen la ejecución de Ethereum, hay otras ineficiencias en las estructuras de datos y patrones de acceso onchain que siguen optimizados.

Mejorando las bases de datos

Los equipos que trabajan en capas de ejecución están buscando formas de mejorar la estructura de estas bases de datos mismas para eliminar algunos de los cuellos de botella experimentados por Ethereum y otras blockchains compatibles con EVM al tratar con acceso estatal ineficiente, lo cual tiene un efecto dominó en la eficiencia computacional.

De hecho, las limitaciones de los diseños de bases de datos existentes encontrados en el EVM informaronMonad’s* decisión de ir más allá de la mera optimización de la eficiencia computacional para lograr la paralelización. Monad descubrió que incluso después de implementar la ejecución en paralelo, solo vieron una pequeña mejora en el rendimiento porque las solicitudes de lectura y escritura en subprocesos múltiples al bloqueaban entre sí. Como resultado, Monad implementó una base de datos compatible con E/S asíncrona (AIO), o acceso paralelo, como parte crítica de la solución.

E/S asíncrona

Las operaciones de E/S, como la lectura o escritura en dispositivos de almacenamiento, a menudo crean cuellos de botella, especialmente con los discos duros mecánicos (HDD). Estas unidades requieren el movimiento físico de un cabezal de lectura/escritura para acceder a los datos, lo que puede ralentizar significativamente el procesamiento de datos.

AIO aborda este desafío al permitir que los programas realicen operaciones de E/S de forma concurrente con otros procesos. Esencialmente, un programa puede iniciar una operación de E/S y seguir adelante sin esperar a que se complete. Esto se logra registrando una función de devolución de llamada o una promesa que el sistema operativo o una biblioteca de E/S cumplirá una vez que la operación de E/S finalice. Este enfoque asíncrono permite que el programa principal continúe ejecutando otras tareas, mejorando la eficiencia general al no detenerse por tareas de E/S para completarse.

La E/S asincrónica se puede implementar tanto con HDD tradicionales como con unidades de estado sólido (SSD), aunque los beneficios son más pronunciados con los SSD. Los HDD pueden realizar AIO, pero su naturaleza mecánica significa que son inherentemente más lentos que los SSD, que almacenan datos en memoria flash y no tienen piezas móviles, lo que resulta en tiempos de acceso más rápidos.

Por ejemplo, Monad utiliza un backend de estado personalizado optimizado para el almacenamiento SSD, que admite altos niveles de procesamiento de datos en paralelo y reduce la latencia de E/S. Esta configuración es más eficiente que los sistemas que dependen únicamente de almacenamiento en disco tradicional o los que utilizan bases de datos en memoria, que aún pueden experimentar retrasos debido a escrituras frecuentes de datos en medios de almacenamiento más lentos y lecturas de los mismos.

Del mismo modo, Reth emplea un método que separa las operaciones de la base de datos del motor de ejecución principal de EVM. Esta configuración permite que el código bytecode de EVM se ejecute de forma secuencial en un solo hilo para mantener la consistencia mientras las tareas de E/S de la base de datos se desvían a procesos paralelos. Reth utiliza el modelo de actores, un patrón de arquitectura de software, para gestionar eficazmente estos procesos paralelos, asegurando que las operaciones de E/S no interrumpan al intérprete de EVM.

Frecuencia de Merklización del Estado

Otro vector para la optimización es la frecuencia de merklización del estado. El modelo actual de Ethereum de merklizar el estado después de cada bloque introduce una sobrecarga significativa, requiriendo escrituras frecuentes y lecturas del disco, y recorridos continuos del trie. Los árboles de Merkle suelen funcionar agrupando hashes intermedios en conjuntos de 16 (llamados nodo) y almacenándolos en una base de datos de almacén de clave-valor donde la clave es el hash del nodo y el valor es el nodo mismo.

Recorrer este árbol para encontrar y actualizar datos requiere un acceso aleatorio de disco para cada capa del árbol que se recorra, y recorrer un árbol de Merkle ingenuo requerirá aproximadamente ocho consultas secuenciales a la base de datos por entrada.

El enfoque de Solana de actualizar el compromiso de estado solo al final de cada época permite la amortización de los costos de escritura durante muchas transacciones dentro de ese período. Si una entrada de estado se modifica varias veces dentro de la misma época, cada escritura no requiere una actualización inmediata de la raíz de Merkle. Esto reduce la sobrecarga computacional general asociada con las actualizaciones de estado durante la época. En consecuencia, el costo asociado con la lectura del estado permanece constante, o O(1), porque el estado se puede leer directamente sin necesidad de recorrer un camino de Merkle cada vez.

Reducir la frecuencia de merklización en Ethereum podría disminuir la sobrecarga de las lecturas y escrituras de estado, mejorando el rendimiento. Sin embargo, los clientes ligeros necesitarían reproducir los cambios de bloque para rastrear el estado entre épocas o enviar transacciones en cadena para la verificación de estado, y dicho cambio actualmente no es compatible con Ethereum.

Estructuras de datos eficientes y especializadas

Además, las estructuras de árboles en capas dentro de los clientes de Ethereum existentes generalmente causan patrones de acceso al estado ineficientes, lo que contribuye aún más a la inflación del estado. Si bien el estado de Ethereum está estructurado como un MPT, también se almacena en bases de datos de clientes de Ethereum como LevelDB,PebbleDB(utilizado por go-ethereum), o MDBX (utilizado por Erigon) que almacenan datos en árboles de Merkle como un B-TreeoLSM-Tree.

En esta configuración, una estructura de datos está enraizada en otra estructura de datos de un tipo separado, creando una 'amplificación de lectura' al navegar en estructuras de árbol internas sobre clientes que operan bajo otro sistema basado en árbol de Merkle. La amplificación de lectura puede entenderse como el resultado de los múltiples pasos para acceder o actualizar la información contenida dentro de un estado, lo que requiere navegar el árbol externo para encontrar el punto de entrada en el MPT antes de ejecutar la operación requerida. Como resultado, el número de accesos al disco para una lectura aleatoria se multiplica por un factor log(n).

Para resolver esto, Monad aprovecha nativamente una estructura de datos de árbol Patricia en disco y en memoria. Desde una perspectiva técnica, los árboles Patricia suelen ser superiores a otras estructuras de árbol de Merkle debido a su combinación única de eficiencia espacial, coincidencia eficiente de prefijos y traversión mínima de nodos. El diseño del árbol colapsa nodos con hijos únicos y optimiza búsquedas, inserciones y eliminaciones, reduciendo el número de operaciones de E/S de disco o red requeridas. Además, la habilidad de un árbol Patricia para manejar la coincidencia de prefijos mejora el rendimiento en aplicaciones que necesitan búsquedas rápidas de claves parciales.

Otro cuello de botella específico de las estructuras basadas en árboles es que acceder o actualizar datos requiere atravesar múltiples capas, lo que conlleva numerosos accesos secuenciales al disco. Laboratorios Soberanos addresses this inefficiency by advocating for a binary Merkle tree configuration. This pivotal shift to a binary structure drastically reduces the number of potential paths during tree traversal, directly reducing the hash computations needed for updates, insertions, and cryptographic proofs.

Configuración del árbol Merkle binario de la “Merklización de estado casi óptima” de Sovereign Labs

Un ejemplo adicional en esta categoría es el equipo Reth configurando Reth parapre-fetch nodos del trie intermedios desde el disco durante la ejecuciónal notificar al servicio raíz del estado sobre los espacios de almacenamiento y las cuentas afectadas.

Expiración de estado

La expiración del estado es un mecanismo para gestionar y reducir el tamaño del estado de la cadena de bloques eliminando datos que no se han accedido durante un período de tiempo establecido. Si bien la expiración a menudo se clasifica en la categoría de "falta de estado", es fundamental distinguir estos conceptos en el contexto de la ejecución.

La apatridia mejora la ejecución al aumentar la capacidad de cálculo de un nodo ejecutor en memoria, pero las mejoras en la ejecución provienen de los requisitos de hardware más robustos a través de menos nodos que ejecutan transacciones. En contraste, la caducidad del estado se puede aplicar a blockchains con pocos y muchos nodos ejecutores.

Hay un par de métodos comúnmente discutidos para implementar la expiración del estado:

• Vencimiento por alquiler: Este método implica cobrar una tarifa de mantenimiento, o "alquiler", para mantener activas las cuentas dentro de la base de datos del estado. Si el alquiler no se paga, las cuentas se archivan hasta que se pague una tarifa para restaurarlas.
• Caducidad por tiempo: Aquí, las cuentas se consideran inactivas si no han sido accedidas, lo que significa que no ha habido transacciones o interacciones, durante una duración especificada.

Ambos métodos tienen como objetivo mantener solo los datos utilizados activamente en el estado inmediato y accesible, mientras que empujan los datos más antiguos y menos accesados con menor frecuencia a un estado archivado que no carga el sistema principal.

Al mantener un estado más pequeño y manejable, la caducidad del estado reduce la "sobrecarga del estado" que puede obstaculizar gravemente el rendimiento de la cadena de bloques. Un tamaño de estado más pequeño permite que los nodos naveguen y actualicen rápidamente el estado, lo que se traduce en una ejecución más rápida porque los nodos pasan menos tiempo escaneando y más tiempo procesando.

Fragmentación de ejecución

Sharding optimizes resource utilization and performance by distributing tasks and data across a limited number of specialized nodes (not every node executes a global state).

En una arquitectura de blockchain fragmentada, el estado global se divide en particiones distintas llamadas fragmentos. Cada fragmento mantiene su parte del estado y es responsable de procesar un subconjunto de las transacciones de la red. Las transacciones se asignan a fragmentos específicos en función de una función de fragmentación determinista, que considera diversos factores como la dirección del remitente, la dirección del destinatario y el hash de los datos de la transacción. Esto minimiza la necesidad de comunicación entre fragmentos y permite una ejecución de transacciones más eficiente.

Diagrama de fragmentación de "Los límites de la escalabilidad de blockchain" de Vitalik

Esto se hace evidente al explorar NEAR Protocol’sdiseño de fragmentación, Belladona, que logra la falta de estado para escalar el shard sin comprometer la minimización de la confianza.

En Nightshade, la cadena de bloques está estructurada como una única cadena lógica, con cada bloque compuesto por múltiples "fragmentos" y asignándose un fragmento por fragmento. Estos fragmentos contienen las transacciones y transiciones de estado específicas de cada fragmento. Incluir fragmentos de todos los fragmentos dentro de un solo bloque permite una vista unificada del estado completo de la cadena de bloques y simplifica el proceso de comunicación entre fragmentos.

De manera similar a la separación adecuada del constructor (PBS) en Ethereum, Nightshade delimita explícitamente los roles de los nodos con estado y sin estado. En NEAR, a los validadores con estado se les asignan fragmentos específicos y son responsables de recopilar transacciones, ejecutarlas y producir fragmentos específicos del fragmento. Mantienen el estado completo de su fragmento asignado y generan testigos de estado para que los validadores los utilicen durante el proceso de validación.

Mientras tanto, a los validadores sin estado se les asignan aleatoriamente para validar fragmentos específicos en una base por bloque. No necesitan mantener el estado completo fragmentado y dependen de testigos de estado proporcionados por los productores de bloques de otros fragmentos para validar las transiciones de estado y transacciones dentro de un fragmento. La asignación aleatoria de validadores a fragmentos ayuda a garantizar la seguridad e integridad de la red, ya que dificulta que actores malintencionados coludan y controlen un fragmento específico.

Dado que cada nodo en la red solo necesita manejar los datos de su respectiva fragmento en lugar de los datos de toda la red, la carga de almacenamiento y computacional en los nodos individuales se reduce.

Soluciones: Cálculo Ineficiente

Paralelización de la ejecución

Hora de abordar el elefante en la habitación: paralelización. La ejecución paralela de transacciones permite procesar múltiples transacciones utilizando múltiples recursos informáticos de forma concurrente. Esto permite aumentar el rendimiento a medida que los recursos de hardware se escalan durante períodos de alta demanda.

Sin embargo, es importante tener en cuenta que varios componentes de ejecución pueden ser paralelizados, muchos de los cuales son implementados por coprocesadores como Lagrange* y clientes alternativos de blockchain como Firedancerpara mejorar significativamente el rendimiento de las blockchains. Específicamente, la paralelización puede implicar:

• Acceso paralelo al estado
• Operaciones Específicas de Paralelización
• Paralelizando Consenso y Ejecución

Acceso paralelo al estado

Acceso paralelo al estadobrings two critical benefits:

• Los EVM paralelos distribuyen el procesamiento de transacciones en varios núcleos de CPU. Esta configuración permite que múltiples transacciones se manejen de manera concurrente en lugar de obligarlas a hacer cola para un único recurso.
• Cuando una transacción espera datos de almacenamiento, lo que puede introducir una latencia significativa, el sistema no permanece inactivo. En su lugar, puede cambiar a otra transacción que esté lista para ejecutarse. Esto es posible porque múltiples núcleos pueden manejar diferentes tareas de forma independiente y simultánea.

El principal desafío en paralelizar la ejecución de transacciones proviene de gestionar el acceso concurrente al estado global compartido sin violar el ACIDreglas para actualizar sistemas distribuidos. Si una cadena de bloques tiene un montón de transacciones ejecutándose en paralelo, algunas de ellas entrarán en conflicto. Como resultado, las dos metodologías principales para paralelizar el acceso al estado difieren en cuándo dedican recursos para resolver conflictos: el modelo de ejecución pesimista (o bloqueo de memoria) y el modelo de ejecución optimista.

Ejecución pesimista

El modelo de ejecución pesimista es un enfoque de procesamiento de transacciones que requiere que las transacciones declaren las variables de estado a las que accederán (lectura o escritura) durante la ejecución. Esta información se incluye en los metadatos de la transacción, lo que permite que el tiempo de ejecución analice los patrones de acceso antes de la ejecución.

Al examinar los patrones de acceso de lectura-escritura, el tiempo de ejecución puede identificar transacciones con conjuntos de acceso no superpuestos, lo que permite la ejecución paralela de transacciones no superpuestas y de solo lectura, mejorando el rendimiento. El tiempo de ejecución crea colas de transacciones paralelas para cada hilo de CPU en un nodo validador, garantizando que las transacciones con patrones de acceso no conflictivos se procesen de forma concurrente.

Como resultado de esta elección de diseño, el modelo de ejecución pesimista se beneficia del control detallado sobre la asignación de recursos, lo que permite segmentar o particionar el espacio de estado de una cadena de bloques.

La paralelización crea efectivamente múltiples fragmentos de ejecución independientes, componibles sincrónicamente y respaldados por un modelo de seguridad unificado. Ayuda a abordar la congestión de red y optimizar los costos de gas mediante una gestión precisa de recursos y mercados dinámicos de tarifas. Al identificar "puntos críticos" de acceso al estado (áreas de alta demanda transaccional), el sistema puede implementar optimizaciones específicas como la diferenciación de precios de tarifas, la limitación de la velocidad o la asignación de recursos adicionales a estados de alta contención. Es importante tener en cuenta que la implementación actual de la paralelización en Solana no...realizar plenamente el potencial de los mercados de tarifas localizados.

Para garantizar la consistencia de los datos en el acceso concurrente, el modelo de ejecución pesimista utiliza un mecanismo de bloqueo. Antes de que una transacción pueda acceder a una variable de estado específica, debe adquirir un bloqueo en esa variable. El bloqueo proporciona a la transacción acceso exclusivo a la variable, evitando que otras transacciones la modifiquen simultáneamente. El bloqueo se libera una vez que se ejecuta la transacción, permitiendo que otras transacciones accedan a la variable.

En Solana's Nivel del martiempo de ejecución, que implementa este modelo de ejecución pesimista, las transacciones especifican las cuentas que leerán o escribirán durante la ejecución. Sealevel analiza los patrones de acceso y construye colas de transacciones paralelas para cada hilo de CPU en un nodo validador. Si una cuenta se accede varias veces, se lista secuencialmente en una sola cola para evitar conflictos. Las transacciones que no se procesan dentro del tiempo de bloque del nodo líder se agrupan y se envían al siguiente líder programado para su procesamiento.

Los sistemas basados en salidas de transacción no gastadas (UTXO) mejoran la eficiencia computacional de manera similar. Las UTXO involucran unidades específicas de moneda, UTXO, asociadas con la cartera de un individuo. Para cada una de las transacciones de dicha cartera, las UTXO se gastan y se reemplazan por nuevas; se crean una o más UTXO para el receptor, que representan el pago, y otra se crea típicamente para el iniciador, que representa cualquier cambio debido.

Al definir qué contratos se tocarán, las transacciones que tocan conjuntos disjuntos de contratos pueden ejecutarse en paralelo mediante la ejecución de nodos (lo cual se puede lograr en el modelo de datos de "cuentas" con listas de acceso estrictas). Sin embargo, para ganar compatibilidad con contratos inteligentes al estilo Ethereum, esquemas UTXO como los de Fuel restringen a los nodos productores de bloques a ejecutar transacciones con listas de acceso superpuestas de forma secuencial.

Sin embargo, el modelo de ejecución pesimista tiene limitaciones. Las transacciones deben declarar con precisión sus patrones de acceso de antemano, lo cual puede ser un desafío para transacciones complejas o dinámicas donde los patrones de acceso pueden depender de los datos de entrada o la lógica condicional. Las declaraciones de patrones de acceso inexactas o incompletas pueden causar un rendimiento subóptimo y posibles errores en tiempo de ejecución. Además, el mecanismo de bloqueo puede introducir latencia y reducir la concurrencia cuando muchas transacciones compiten por las mismas variables de estado. Esta contención puede formar cuellos de botella de rendimiento, ya que las transacciones pueden pasar una parte significativa de su tiempo de ejecución esperando adquirir bloqueos en variables de estado de alta demanda.

Más importante aún, este modelo coloca una carga considerable sobre los desarrolladores, quienes deben tener un profundo entendimiento de las dependencias de datos de sus contratos para especificar de manera precisa los accesos al estado necesario de antemano. Esta complejidad puede presentar desafíos, especialmente en el diseño de aplicaciones con interacciones de estado dinámicas y complejas, como intercambios descentralizados o creadores de mercado automatizados.

Ejecución Optimista

Por el contrario, el modelo de ejecución optimista adopta un enfoque 'especulativo' para la ejecución de transacciones, lo que permite que las transacciones se ejecuten en paralelo sin necesidad de declaraciones de acceso al estado por adelantado.

En lugar de prevenir conflictos antes de que ocurran, las transacciones se ejecutan de forma optimista en paralelo, asumiendo que son independientes. El tiempo de ejecución emplea técnicas como control de concurrencia de múltiples versiones(MVCC) and memoria transaccional de software (STM) para rastrear conjuntos de lectura y escritura durante la ejecución. Después de la ejecución, el tiempo de ejecución detecta cualquier conflicto o dependencia. Toma medidas correctivas, como abortar y volver a ejecutar transacciones en conflicto, pero puede hacerlo leyendo desde la memoria en lugar del disco para identificar transacciones en conflicto.

El modelo de ejecución optimista simplifica el proceso de desarrollo, permitiendo a los programadores centrarse en escribir la lógica del contrato sin preocuparse por declarar patrones de acceso al estado. Debido a que las transacciones no necesitan declarar sus interacciones de estado de antemano, los desarrolladores tienen más libertad para diseñar sus contratos inteligentes, lo que permite interacciones más complejas y dinámicas con el estado de la cadena de bloques. El modelo de ejecución optimista es especialmente adecuado para plataformas que admiten un alto volumen de transacciones y dapps complejas, ya que puede ofrecer una mayor capacidad de procesamiento y escalabilidad que el modelo pesimista.

Una implementación notable de este modelo se encuentra en Aptos y el MoveVM de Movement Labs*, que emplea una técnica conocida como Bloque-STMEn Block-STM, las transacciones se ejecutan primero en paralelo; luego, se identifican las transacciones conflictivas y se programan para su reejecución basándose en las dependencias detectadas. Este enfoque garantiza que los recursos de procesamiento se utilicen de forma continua, mejorando el rendimiento y manteniendo la integridad del flujo de transacciones.

El Bloque-STM de Aptos de "Escalando la Ejecución de Blockchain Convirtiendo la Maldición del Pedido en una Bendición de Rendimiento"

A pesar de sus ventajas, el modelo de ejecución optimista también conlleva desafíos. La necesidad de detección de conflictos en tiempo de ejecución y la posibilidad de abortos y reintentos de transacciones introducen sobrecarga computacional y complejidad. Además, mantener múltiples versiones del estado y gestionar la sobrecarga asociada con la resolución de conflictos requiere un diseño de sistema sofisticado y mecanismos de control de concurrencia robustos para garantizar la integridad y el rendimiento de la cadena de bloques.

Block-STM aprovecha MVCC para gestionar eficazmente las escrituras concurrentes y mantener múltiples versiones de datos, evitando así conflictos entre operaciones de escritura simultáneas. Incorpora un programador colaborativo para coordinar las tareas de ejecución y validación en múltiples hilos, asegurando que las transacciones se confirmen en el orden en que se iniciaron. Esta configuración minimiza las anulaciones de transacciones mediante la estimación dinámica de dependencias, lo que permite que las transacciones con dependencias esperen y resuelvan eficientemente estas dependencias antes de seguir adelante.

Además, el modelo de cuenta utilizado por MoveVM difiere del de EVM de Ethereum, lo que lleva a menos colisiones. En Ethereum, un token es gestionado típicamente por un único contrato inteligente, lo que potencialmente causa que múltiples transacciones de tokens interactúen a través de la misma dirección de contrato, aumentando la probabilidad de conflictos. En contraste, MoveVM asigna tokens a cuentas de usuario individuales, reduciendo la posibilidad de tales conflictos ya que cada transacción generalmente interactúa con direcciones de cuenta diferentes.

En Monad, el conjunto inicial de transacciones ejecutadas en paralelo puede ser enmarcado como una fase de E/S, que puede producir resultados inmediatamente comprometidos, y la siguiente fase de "reintentar", que requiere una pequeña cantidad de trabajo para eliminar las transacciones restantes en conflicto. Estas transiciones en conflicto se detectan y se almacenan en caché, lo que permite reducir la sobrecarga de ejecución porque residen en memoria. Mientras que la mayoría del estado vive en disco, las transacciones en conflicto se acceden rápidamente en el momento de la ejecución.

Los modelos de ejecución pesimista y optimista ofrecen enfoques distintos para manejar la ejecución de transacciones y la gestión de estados en blockchains. La elección entre estos modelos implica compensaciones entre la complejidad inicial en la especificación de acceso al estado y la sobrecarga computacional asociada con la resolución dinámica de conflictos.

Paralelismo de datos y tareas

La paralelización de datos y tareas se centra en optimizar el rendimiento distribuyendo cargas computacionales en varios procesadores: la paralelización de datos segmenta un conjunto de datos para su procesamiento simultáneo, mientras que la paralelización de tareas asigna diferentes tareas a varios procesadores para que operen de manera concurrente.

Estas optimizaciones son distintas pero interdependientes con el paralelismo de acceso al estado, que gestiona y sincroniza el acceso a recursos compartidos como la memoria o las bases de datos para prevenir conflictos y garantizar la integridad de los datos cuando múltiples procesos o hilos operan simultáneamente.

Paralelismo de datos

El paralelismo de datos implica la paralelización de operaciones específicas en múltiples elementos de datos simultáneamente. Este enfoque es particularmente beneficioso cuando se necesita aplicar la misma operación a un gran conjunto de datos o al realizar operaciones computacionalmente intensivas en múltiples valores de entrada. La clave está en distribuir los datos en múltiples unidades de procesamiento y ejecutar la misma operación de forma concurrente en diferentes elementos de datos.

Una técnica común para el paralelismo de datos es instrucción única, datos múltiples(SIMD), que permite que una sola instrucción se ejecute simultáneamente en varios elementos de datos. Las CPU modernas a menudo tienen capacidades SIMD incorporadas, lo que les permite realizar operaciones paralelas en múltiples puntos de datos. Al aprovechar las instrucciones SIMD, los desarrolladores pueden lograr mejoras significativas en la velocidad para ciertos tipos de operaciones, como cálculos matemáticos, transformaciones de datos o procesamiento de señales.

Por ejemplo, considere un escenario en el que deba aplicar una función matemática compleja a una gran matriz de números. En lugar de procesar cada número de forma secuencial, SIMD puede operar en múltiples números simultáneamente. Este procesamiento simultáneo se logra cargando un subconjunto de los números en los registros SIMD de la CPU, ejecutando la función matemática en todos los números cargados en paralelo, y luego almacenando los resultados nuevamente en la memoria. Al procesar múltiples números a la vez, SIMD puede reducir considerablemente el tiempo de ejecución general.

Trabajo de Firedancer en ED25519La verificación de firma demuestra el poder de SIMD para optimizar cálculos complejos. El proceso de verificación de firma implica operaciones aritméticas dentro de los Campos de Galois, que pueden ser intensivas computacionalmente. Al aprovechar las instrucciones SIMD, Firedancer puede realizar estas operaciones en múltiples elementos de datos de forma concurrente, lo que resulta en mejoras significativas de rendimiento. Estas optimizaciones serán críticas para mejorar el rendimiento de Solana, que ya ha implementado la paralelización del acceso al estado.

Paralelismo de tareas

La paralelización de tareas implica la paralelización de diferentes tareas u operaciones dentro de un programa en múltiples unidades de procesamiento. Este enfoque es útil cuando un programa consta de múltiples tareas independientes que pueden realizarse simultáneamente. Al asignar cada tarea a una unidad de procesamiento separada, como un núcleo de CPU o una GPU, el tiempo de ejecución general puede reducirse.

El paralelismo de tareas se utiliza comúnmente en escenarios donde un programa debe realizar múltiples operaciones complejas simultáneamente. Por ejemplo, consideremos una aplicación de procesamiento de video que necesita aplicar diferentes filtros y efectos a un flujo de video en tiempo real. En lugar de utilizar cada unidad de cálculo para aplicar colectivamente cada filtro secuencialmente, el paralelismo de tareas puede distribuir la carga de trabajo entre las múltiples unidades de procesamiento. Una unidad de procesamiento puede ser responsable de aplicar un filtro de desenfoque mientras que otra unidad aplica un filtro de corrección de color, y así sucesivamente. Al ejecutar estas tareas en paralelo, la aplicación puede lograr un procesamiento más rápido y mantener una experiencia de usuario fluida.

Lagrange’s@lagrangelabs/a-big-data-primer-introducing-zk-mapreduce-12cf404eab75">ZK MapReduce (ZKMR) aprovecha el paralelismo de datos y tareas para paralelizar y generar pruebas de cálculos distribuidos de manera eficiente en grandes conjuntos de datos. En la fase de asignación, el conjunto de datos de entrada se divide en fragmentos más pequeños y cada fragmento es procesado de forma independiente por un trabajador asignador independiente o una máquina en paralelo (paralelismo de tareas). La operación de "mapeo" se puede paralelizar dentro de cada tarea de mapeo a través de múltiples núcleos o procesadores (paralelismo de datos). Del mismo modo, en la fase de reducción, la operación de "reducción" en los valores asociados a cada clave se puede paralelizar dentro de cada tarea de reducción (paralelismo de datos). Por el contrario, las tareas reductoras se ejecutan en paralelo entre varios trabajadores (paralelismo de tareas).

Al combinar el paralelismo de datos y el paralelismo de tareas, ZKMR puede lograr una escalabilidad y rendimiento eficientes para cálculos complejos en conjuntos de datos masivos, manteniendo garantías de conocimiento cero a través de la composición de pruebas recursivas.

Verificación de un procedimiento arbitrario de MapReduce en ZK a partir de la "Introducción a ZK MapReduce" de Lagrange

La capacidad de Lagrange para generar pruebas de almacenamiento para cálculos de SQL sobre @lagrangelabs/anunciando-testnet-euclid-la-primerabase-de-datos-verificable-de-ethereum-y-coprocessador-zk-cc4a5595365c">888,888 ranuras de almacenamiento en 1 minuto y 20 segundos demuestran el poder de ZKMR, así como la tarea y paralelismo de datos que lo sustentan. Además, lo reciente de Lagrange's Árboles ReckleEl papel subraya la necesidad de paralelismo en que asegura que las pruebas por lotes de datos en cadena también sean computables en 𝑂(log𝑛), independientemente del tamaño del lote.

Paralelizando Consenso & Ejecución

Si bien esta pieza no aborda el consenso, las blockchains también pueden paralelizar el proceso de consenso y ejecución. Las blockchains tradicionales a menudo procesan transacciones de manera secuencial, llegando a un consenso sobre las transacciones de un bloque (bloque N) antes de ejecutarlas. El procesamiento paralelo de las fases de consenso y ejecución aumenta significativamente la eficiencia de ejecución y es una técnica ejemplificada por sistemas como Monad. A medida que la red llega a un consenso para el bloque N, ejecuta simultáneamente transacciones para el bloque anterior (N-1).

Esta estrategia garantiza el uso continuo y eficiente de los recursos computacionales, reduciendo efectivamente los tiempos de inactividad y mejorando la capacidad de la red para procesar transacciones rápidamente. Estas mejoras aumentan el rendimiento del sistema y el costo de capital necesario para enviar spam a la red.

Intérpretes & Reducing Overhead

Cuando los contratos inteligentes se escriben en lenguajes como Solidity, primero se compilan en el bytecode de nivel inferior. Luego, la EVM utiliza un intérprete para ejecutar este bytecode. El intérprete lee y ejecuta cada instrucción secuencialmente, similar a traducir un idioma extranjero en tiempo real mientras se habla. Paradigma's última pieza sobre Rethseñala que esto conlleva sobrecarga ya que cada instrucción debe procesarse individualmente y convertirse de bytecode a instrucciones de máquina durante la ejecución.

Reth está abordando las ineficiencias de EVM mediante la incorporación de un compilador justo a tiempo (JIT). Este compilador traduce el código de bytes en código de máquina nativo poco antes de la ejecución, evitando el proceso de interpretación que consume muchos recursos y que normalmente se requiere durante el tiempo de ejecución.

El Artículo de Rethmenciona que el 50% del tiempo de ejecución de EVM bajo un sistema basado en intérpretes está dedicado a procesos que teóricamente JIT podría optimizar, lo que sugiere la posibilidad de duplicar la velocidad de ejecución con la implementación de JIT. Sin embargo, como señala Yilong en esta presentación, mientras que JIT puede disminuir significativamente el tiempo necesario para procesar opcodes específicos, es posible que no afecte drásticamente la ejecución general. Esto se debe a que una parte sustancial del 50% del tiempo de ejecución de EVM que ocupa JIT involucra operaciones de "host" y "sistema" (Diapositiva 13), que no son susceptibles a optimizaciones JIT como "aritmética" o "control" debido a su naturaleza no computacional.

Si bien los intérpretes pueden limitar el rendimiento, crean la oportunidad para la "traducción", lo que aumenta el alcance del código que puede aprovechar las nuevas máquinas virtuales, lo que reduce la sobrecarga para que los desarrolladores usen el espacio de bloque del diseñador. Por ejemplo, Movement Labs ha desarrollado Fractal, lo que permite a los desarrolladores implementar sus contratos basados en Solidity en MoveVM. Fractal funciona compilando Solidity en un lenguaje intermedio que contiene instrucciones articuladas en códigos de operación de EVM, que luego se asignan a sus contrapartes de código de bytes de MoveVM, lo que permite que los contratos de Solidity se ejecuten en el entorno de MoveVM.

Máquinas de Estado Especializadas y Personalizadas

Personalizar la capa de ejecución implica diseñar máquinas de estado especializadas optimizadas para aplicaciones específicas. Esto no solo significa que un entorno de ejecución puede prescindir completamente de la necesidad de una máquina virtual, sino que también permite a las aplicaciones adaptar la arquitectura de conjunto de instrucciones (ISA), las estructuras de datos y el modelo de ejecución a sus necesidades específicas. La principal ventaja de rendimiento de adaptar una ISA a una aplicación específica proviene de la reducción de la sobrecarga de traducir los patrones computacionales de la aplicación en las instrucciones de propósito general de una ISA tradicional. Las CPU de uso general utilizan conjuntos de instrucciones básicas (es decir, agregar, cargar, bifurcar) para admitir la ejecución de diferentes tipos de software. Sin embargo, cuando las aplicaciones repiten con frecuencia las mismas operaciones de varios pasos, la implementación de estos patrones mediante secuencias de instrucciones simples se vuelve ineficaz.

Por ejemplo, las aplicaciones de base de datos pueden necesitar atravesar constantemente estructuras de datos de árbol, buscar entradas, actualizar valores y reequilibrar árboles. En una CPU normal, el mapeo de estas operaciones de nivel superior requiere descomponerlas en secuencias largas de microoperaciones de bajo nivel, como cargas, almacenamientos, ramas y operaciones aritméticas, que se ejecutan individualmente en el hardware general. En contraste, una ISA personalizada para bases de datos puede fusionar estos patrones recurrentes en instrucciones más amplias optimizadas que aprovechan el hardware especializado. Una instrucción "TraverseTree" podría calcular direcciones de memoria, cargar nodos relevantes y comparar claves utilizando circuitos de comparación paralelos diseñados para esa operación. "UpdateEntry" podría recopilar directamente la entrada del diseño de almacenamiento de base de datos optimizado, modificarla y confirmar el nuevo estado todo en una sola instrucción.

Esto elimina la sobrecarga redundante de traducir operaciones de alto nivel a instrucciones simples. También permite que el hardware ejecute óptimamente la aplicación utilizando menos pero más amplias instrucciones paralelas explícitamente diseñadas para satisfacer sus necesidades.

LayerN’s Norddemuestra los beneficios de rendimiento de especializar entornos de ejecución y estructuras de datos a través de su caso de uso específico de un libro de órdenes verificable. El enfoque de LayerN se centra en optimizar la colocación de operaciones en la estructura de datos del libro de órdenes, mientras que su mecanismo de canalización está diseñado para insertar eficientemente nuevas órdenes en la posición adecuada dentro del árbol de datos del libro de órdenes. Al adaptar la estructura de datos y el algoritmo de inserción a los requisitos específicos de un libro de órdenes, LayerN logra una colocación de órdenes de baja latencia y un alto rendimiento.

Alternativamente, es posible apoyarse en entornos de ejecución de propósito general que permiten módulos programables de forma arbitraria a los que las aplicaciones pueden conectarse para optimizar su rendimiento. Este enfoque prioriza la experiencia del desarrollador sobre el rendimiento bruto.

Fluido y CWDutilice una estrategia que equilibre los compromisos entre la optimización del rendimiento computacional y la mejora de la experiencia del desarrollador y la compatibilidad del ecosistema. Este enfoque se centra en el uso de WebAssembly (Wasm) como la máquina virtual para ejecutar código. Wasm se ha convertido en una elección preferida en el desarrollo web debido a su amplio soporte de lenguajes y al amplio grado en que ha sido adoptado.

La decisión de un desarrollador de usar Wasm en lugar de la ejecución nativa del cliente refleja una preferencia estratégica por la versatilidad y amplia accesibilidad de un entorno de ejecución de propósito general. Aunque la ejecución nativa, que ejecuta código directamente en hardware sin una máquina virtual, puede ofrecer un mejor rendimiento, restringe la compatibilidad entre plataformas y es menos accesible para los desarrolladores. En contraste, Wasm garantiza un entorno de ejecución uniforme y seguro en diferentes plataformas a pesar de no lograr la misma velocidad bruta que la ejecución nativa. Este compromiso se alinea con las filosofías de diseño de Fluent y CWD, priorizando la productividad del desarrollador y la integración más amplia del ecosistema sobre la eficiencia máxima de rendimiento.

Implementación de CosmWasm (CWD), en particular, ejemplifica este enfoque no solo empleando Wasm para la ejecución de contratos inteligentes, sino también incorporándolo en un marco más extenso diseñado para apoyar las complejidades de las operaciones de blockchain. Enriquecido con 'lógica periférica', este marco ofrece un avanzado manejo de cuentas, un mecanismo de gas personalizable y una ordenación de transacciones optimizada. Estas características contribuyen a un entorno de desarrollo flexible, eficiente y seguro que capacita a los desarrolladores para construir dapps escalables y complejas relativamente fácilmente.

Stackr* toma un enfoque diferente al combinar los beneficios de entornos de ejecución personalizados con la flexibilidad de las plataformas tradicionales de contratos inteligentes. Stackr permite a los desarrolladores codificar aplicaciones como rollups, lo que les permite definir sus propias reglas para la ordenación, ejecución y configuración de transacciones. En el modelo de Stackr, los desarrolladores pueden elegir la ISA, las estructuras de datos y el modelo de ejecución que mejor se adapte a los requisitos de su aplicación.

El diseño de micro-rollup de Stackr de "Introducción al Stackr SDK"

Con Stackr, los desarrolladores pueden aplicar reglas de transición de estado directamente en el tiempo de ejecución de la aplicación en lugar de estar limitados por las reglas de una máquina virtual de propósito general, lo que les da la capacidad de optimizar su conjunto de instrucciones para que sea más eficiente y redefinir el conjunto de cosas que se pueden hacer en un entorno de tiempo de ejecución.

Esto resulta en una ejecución más ligera y eficiente, ya que la lógica empresarial se implementa a nivel de cliente, eliminando la necesidad de costosas invocaciones y validaciones de contratos inteligentes. Como resultado, las posibilidades en torno a cómo se configura una aplicación se expanden en términos de los diferentes tipos de lenguajes, estructuras de datos y firmas que los desarrolladores pueden usar para una sola aplicación sin sacrificar rendimiento.

Conclusión

Existen múltiples caminos para lograr un rendimiento óptimo en la capa de ejecución.

Ninguna optimización singular para el acceso al estado o la paralelización destaca como un punto de diferenciación técnica propietario entre las capas de ejecución al intentar capturar dapps. Como hemos visto, los beneficios de la paralelización basada en recursos en Solana pueden aplicarse igualmente al modelo UTXO de Fuel. Cualquiera puede usar Amazon’ssoluciones perspicaces para mejorar la escalabilidad horizontal a través del particionamiento y mejorar el rendimiento de la capa de ejecución.

Si bien el rendimiento de la capa de ejecución es un vector crítico para ganarse a los constructores de aplicaciones descentralizadas, las nuevas capas L1 y L2 centradas en mejorar la ejecución deben competir en otras variables, incluida la seguridad, la interoperabilidad y la compatibilidad con las herramientas existentes. Por esta razón, la proliferación de nuevas capas de interoperabilidad, desde Nebra hasta Statenet y AggLayer de Polygon, será fundamental para los desarrolladores que compren espacio de bloque de diseñador, ya que pueden construir o comprar espacio de bloque especializado sin sacrificar la composabilidad sincrónica y la liquidez compartida de los L1 generales tradicionales.

Mejoras en la gestión del estado y la eficiencia computacional son interdependientes.

A través de las comunidades que diseñan nuevas capas de ejecución, la paralelización del acceso al estado se ha convertido en un meme definitorio para las mejoras de rendimiento que prometen ofrecer. Si bien esto es por una buena razón, ya que podría llevar a un Mejora de 5x en la ejecución del EVM, la evidencia de la experimentación temprana de Monad con la paralelización demuestra que su papel está sobrevalorado si no se desarrollan otras mejoras, como la E/S asincrónica, al mismo tiempo.

Basándonos en esto, podemos concluir que la eficiencia computacional a menudo solo se logra cuando mejoramos cómo se accede y almacena el estado. La gestión eficiente del estado reduce el tiempo y los recursos necesarios para acceder y manipular datos, lo que acelera el procesamiento y reduce la carga computacional.

Llevando esto un paso más allá, los incumbentes pueden estar tomando decisiones dependientes del camino que obstaculizan su capacidad para competir con nuevos diseños de blockchain que reestructuran cómo se administra y actualiza el estado, dada la inercia que implica un hard fork. Como resultado, capas de ejecución especializadas y modulares y L1 alternativos pueden ser capaces de crear defensibilidad en torno a las decisiones de diseño para un almacenamiento de estado más eficiente y los protocolos para leer y escribir en él. Estas decisiones de diseño ofrecen una ventaja competitiva, ya que los incumbentes pueden encontrar inercia al actualizar sus estructuras de base de datos sin un hard fork.

Al final del día, los valores de un espacio de bloques impactan en el espacio de diseño para las capas de ejecución.

Al comprender cómo podemos mejorar las capas de ejecución, ahora podemos delinear que las clases de optimizaciones difieren según dos decisiones de diseño críticas: ¿quién está ejecutando transacciones y cuántos nodos deben estar involucrados? Las técnicas disponibles para los desarrolladores para resolver cuellos de botella de ejecución difieren significativamente dependiendo de las respuestas iniciales de un equipo a estas preguntas.

Por un lado, L1 monolíticas como Solana y Monad no aceptan separar el rol del validador en nodos poderosos y débiles heterogéneos para acelerar el rendimiento. 'Aceptar' la hinchazón del estado a corto plazo no es una solución viable, por lo que confían en mejoras en la capa de base de datos y otros componentes del motor de producción de bloques, como el consenso, para compensar la mayor cantidad de nodos en ejecución considerados como un componente crítico y un valor central de la red. Debido a que los modelos de seguridad de estas L1 dependen del consenso de un conjunto más distribuido de validadores con requisitos de hardware más débiles, sus datos deben escribirse en una base de datos que reside en un disco, lo cual es necesariamente más barato para una cadena de bloques sin permisos y maximamente descentralizada.

Por otro lado, proyectos como Ethereum y sus L2 están siguiendo una hoja de ruta que se inclina hacia la centralización en sus nodos ejecutores a través de constructores de bloques centralizados responsables ante nodos proponentes verificadores más débiles a través de pruebas de fraude o validez.

Supongamos que los “ejecutores” centralizados de transacciones y transiciones de estado se consideran aceptables en la búsqueda de un futuro descentralizado. En ese caso, la ley de la física establece que los sistemas que pueden 1) agregar bloques a una cadena sin requerir que múltiples actores vuelvan a ejecutar las transacciones, 2) aumentar los requisitos del validador para maximizar la computación en la memoria (y ignorar el problema de la hinchazón del estado), y 3) reducir la latencia y los cuellos de botella del consenso claramente superan a los sistemas que dependen de una descentralización extensa y consenso entre nodos.

Al buscar un equilibrio entre la escalabilidad y la minimización de la confianza, está quedando claro que el objetivo de las capas de ejecución no debe ser optimizar la descentralización a ciegas, ni la ejecución siempre debe ser completamente sin permisos.

A medida que desarrollamos e implementamos una gama más amplia de herramientas criptográficas, como pruebas de validez y fraude, reducimos efectivamente el número de nodos necesarios para resistir la censura y mantener la seguridad y la viabilidad. Sin embargo, este enfoque implica compromisos, lo que potencialmente afecta la resistencia a la censura, la integridad del orden y las garantías de viabilidad debido a la posible centralización de los ejecutores.

Como señaló Sreeram, la "descentralización mínima viable" no significa que "la validación deba ser sin permisos", sino que debe estar "incentivada de manera adecuada". Esto implica que un sistema bien supervisado, donde los validadores enfrenten repercusiones significativas por mala conducta, puede mantener la seguridad y la actividad sin necesidad de una descentralización excesiva.h/t Sreeram).

Tales modelos de gobernanza ya se están probando en aplicaciones prácticas. Por ejemplo, soluciones como Arbitrum están explorando sistemas de gobernanza o basados en comités para hacer cumplir reglas de ordenación de transacciones y selección de líderes, y están considerando mecanismos en los que los secuenciadores utilizan datos onchain para mantener las políticas de ordenación de transacciones.

A pesar de estos avances, no existe una "frontera óptima de Pareto" definitiva para equilibrar la descentralización con el rendimiento.

Consideraciones ideológicas y técnicas siguen favoreciendo la descentralización de nodos ejecutores para validar el estado. Si bien la centralización de nodos reduce la sobrecarga de consenso y la actualización de hardware puede mejorar significativamente el rendimiento, aún está por verse si estas optimizaciones atraerán a desarrolladores centrados en crear aplicaciones resistentes a la censura y en qué medida la resistencia a la censura sigue siendo un valor fundamental en la industria.

*denotes una empresa de cartera de Archetype

Descargo de responsabilidad：

1. Este artículo es reimpreso de [espejo )], Reenviar el Título Original 'Designer Blockspace: The Future of Execution Environments', Todos los derechos de autor pertenecen al autor original [Benjamin Funk]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo, y lo manejarán rápidamente.

2. Descargo de responsabilidad: Los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.

3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.