TLDR: Este trabajo de investigación proporciona una visión general de las arquitecturas de diseño paralelo para cadenas de bloques, utilizando tres ejemplos relevantes: Solana, Sei y Monad. Destaca las diferencias entre la paralelización optimista y determinista y examina los matices del acceso al estado y la memoria en estas cadenas.

Introducción

En 1837, el científico de la computación y matemático Charles Babbage diseñó el “Máquina analítica, que sentó las bases teóricas para la computación paralela. Hoy en día, la paralelización es un tema fundamental en el mundo de la criptografía, ya que las cadenas de bloques intentan empujar los límites del procesamiento, la eficiencia y el rendimiento.

El Universo Paralelo

La computación en paralelo permite que muchas cálculos o procesos se ejecuten simultáneamente, en lugar de ejecutar cálculos en serie o uno tras otro. La computación en paralelo se refiere a descomponer problemas más grandes en partes más pequeñas e independientes que pueden ser ejecutadas por múltiples procesadores comunicándose a través de memoria compartida. Los sistemas paralelos tienen varias ventajas, como una mayor eficiencia y velocidad, escalabilidad, mejor fiabilidad y tolerancia a fallos, una mejor utilización de recursos y la capacidad de manejar conjuntos de datos muy grandes.

Sin embargo, es crucial reconocer que la efectividad de la paralelización depende de las especificaciones de la arquitectura subyacente y la implementación. Dos cuellos de botella fundamentales para las cadenas de bloques son las funciones criptográficas (funciones hash, firmas, curvas elípticas, etc.) y el acceso a la memoria/estado. Con las cadenas de bloques, uno de los componentes clave para diseñar un sistema paralelo eficiente radica en los matices del acceso al estado. El acceso al estado se refiere a la capacidad de una transacción para leer y escribir en el estado de una cadena de bloques, incluido el almacenamiento, los contratos inteligentes y los saldos de cuentas. Para que una cadena de bloques paralela sea efectiva y eficiente, el acceso al estado debe estar optimizado.

Actualmente existen dos enfoques para optimizar el acceso al estado en blockchains paralelizadas: la paralelización determinista frente a la paralelización optimista. La paralelización determinista requiere que el código declare explícitamente de antemano qué partes del estado de la cadena de bloques se accederán y modificarán. Esto permite que un sistema determine qué transacciones pueden procesarse en paralelo sin conflictos de antemano. La paralelización determinista permite la previsibilidad y eficiencia (especialmente cuando las transacciones son en su mayoría independientes). Sin embargo, crea más complejidad para los desarrolladores.

La paralelización optimista no requiere que el código declare su acceso al estado por adelantado y procesa transacciones en paralelo como si no hubiera conflictos. Si surge un conflicto, la paralelización optimista volverá a ejecutar, reprocesar o ejecutar las transacciones conflictivas en serie. Si bien la paralelización optimista permite más flexibilidad para los desarrolladores, se requiere volver a ejecutar para resolver conflictos, lo que hace que este método sea más eficiente cuando las transacciones no están en conflicto. No hay una respuesta correcta sobre cuál de estos enfoques es mejor. Simplemente son dos enfoques diferentes (y viables) para la paralelización.

En la Parte I de esta serie, primero exploraremos algunos conceptos básicos de sistemas paralelos no criptográficos, seguido por el espacio de diseño para la ejecución paralela de cadenas de bloques, centrándonos en tres áreas principales:

1. Visión general de los sistemas paralelos de criptografía
2. Enfoques para Acceso a la Memoria y Estado
3. Oportunidades de diseño paralelo

Sistemas Paralelos No-Crypto

Teniendo en cuenta lo que acabamos de leer anteriormente sobre lo que permite la computación paralela y las ventajas de los sistemas paralelos, es fácil entender por qué la adopción de la computación paralela ha despegado en los últimos años. El aumento en la adopción de la computación paralela ha permitido muchos avances en las últimas décadas solamente.

1. Imágenes médicas: El procesamiento paralelo ha transformado fundamentalmente la imagen médica, lo que ha llevado a aumentos significativos en velocidad y resolución en diversas modalidades como resonancia magnética, tomografía computarizada, rayos X y tomografía óptica. Nvidia está a la vanguardia de estos avances, proporcionando a los radiólogos capacidades mejoradas de inteligencia artificial a través de su kit de herramientas de procesamiento paralelo, que permite a los sistemas de imagen manejar de manera más efectiva cargas de datos y computacionales aumentadas.
2. Astronomía: Algunos fenómenos nuevos, como la comprensión de los agujeros negros, solo han sido posibles mediante el uso de supercomputadoras paralelas.
3. Motor de juego Unity: El motor de Unity utiliza las capacidades de las GPU, que están diseñadas para cargas de trabajo gráficas masivas, para ayudar con el rendimiento y la velocidad. El motor está equipado con funciones de procesamiento multihilo y paralelo, lo que proporciona una experiencia de juego fluida y crea entornos de juego complejos y detallados.

Examinemos tres cadenas de bloques que han implementado entornos de ejecución paralelos. Primero, desempaquetaremos Solana, seguido por dos cadenas basadas en EVM, Monad y Sei.

Resumen del Diseño Paralelo - Solana

A un alto nivel, la filosofía de diseño de Solana es que la innovación de la cadena de bloques debe evolucionar con los avances hardware. A medida que el hardware mejora con el tiempo a través de la Ley de Moore, Solana está diseñada para beneficiarse de un mayor rendimiento y escalabilidad. Co-Fundador de Solana Anatoly Yakovenkoinicialmente diseñadoLa arquitectura de paralelización de Solanahace más de cinco años, y hoy en día, el paralelismo como principio de diseño de cadena de bloques se está extendiendo rápidamente.

Solana utiliza la paralelización determinista, que proviene de la experiencia pasada de Anatoly trabajando con sistemas integrados, donde típicamente se declaran todos los estados por adelantado. Esto permite que la CPU conozca todas las dependencias, lo que le permite precargar las partes necesarias de la memoria. El resultado es una ejecución del sistema optimizada, pero nuevamente, requiere que los desarrolladores hagan un trabajo adicional por adelantado. En Solana, todas las dependencias de memoria para un programa son necesarias y se indican en la transacción construida (es decir, Listas de Acceso), lo que permite al tiempo de ejecución programar y ejecutar múltiples transacciones en paralelo de manera eficiente.

El siguiente componente principal de la arquitectura de Solana es Sealevel VM, que es el tiempo de ejecución de contrato inteligente paralelo de Solana. Sealevel admite nativamente el procesamiento de múltiples contratos y transacciones en paralelo en función del número de núcleos que tiene un validador. Un validador en una cadena de bloques es un participante de la red responsable de verificar y validar transacciones, proponer nuevos bloques y mantener la integridad y seguridad de la cadena de bloques. Dado que las transacciones declaran qué cuentas deben leerse y escribirse bloqueadas de antemano, el programador de tareas de Solana puede determinar qué transacciones pueden ejecutarse simultáneamente. Debido a esto, cuando se trata de validación, el “Productor de bloques” o Líder puede ordenar miles de transacciones pendientes y programar las transacciones no superpuestas en paralelo.

El último elemento de diseño para Solana es el “pipelining”. El pipelining ocurre cuando los datos deben procesarse en una serie de pasos, y un hardware diferente es responsable de cada uno. La idea clave aquí es tomar datos que necesitan ejecutarse en serie y paralelizarlos usando el pipelining. Estos pipelines pueden ejecutarse en paralelo, y cada etapa del pipeline puede procesar diferentes lotes de transacciones.

Estas optimizaciones permiten a Sealevel organizar y ejecutar transacciones independientes simultáneamente, utilizando la capacidad del hardware para procesar múltiples puntos de datos a la vez con un solo programa. Sealevel clasifica las instrucciones por programID y ejecuta la misma instrucción en todas las cuentas relevantes en paralelo.

Con estas innovaciones en mente, podemos ver que Solana fue diseñada intencionalmente para soportar la paralelización.

Descripción general del diseño paralelo - Sei

Sei es una cadena de bloques de propósito general de código abierto especializada en el intercambio de activos digitales. Sei V2 aprovecha la paralelización optimista y, como resultado, es más amigable para los desarrolladores que su contraparte determinista. En la paralelización optimista, los contratos inteligentes pueden ejecutarse de manera más fluida y concurrente sin requerir que los desarrolladores declaren sus recursos por adelantado. Esto significa que la cadena ejecuta de manera optimista todas las transacciones en paralelo. Sin embargo, cuando hay conflictos (es decir, múltiples transacciones que acceden al mismo estado), la cadena de bloques llevará un registro del componente de almacenamiento específico que impacta cada transacción en conflicto.

La cadena de bloques de Sei se acerca a la ejecución de transacciones utilizando el “Control de Concurrency Optimista (OCC).” El procesamiento de transacciones concurrentes ocurre cuando múltiples transacciones están vivas simultáneamente en un sistema. Hay dos fases en este enfoque de transacción: ejecución y validación.

En la fase de ejecución, las transacciones se procesan de manera optimista, con todas las lecturas/escrituras almacenadas temporalmente en una tienda específica de transacciones. Después de esto, cada transacción entrará en la fase de validación, donde la información en las operaciones de la tienda temporal se verifica con respecto a cualquier cambio de estado realizado por transacciones anteriores. Si una transacción es independiente, la transacción se ejecuta en paralelo. Si una transacción lee datos modificados por otra transacción, esto crearía un conflicto. El sistema paralelo de Sei identificará cada conflicto comparando los conjuntos de lectura de transacciones frente a los últimos cambios de estado en una tienda de múltiples versiones (estos están indexados por orden de transacción). Sei volverá a ejecutar y revalidar casos en los que surjan conflictos. Este es un proceso iterativo que implica ejecución, validación y nueva ejecución para solucionar los conflictos. El gráfico a continuación ilustra el enfoque de Sei para las transacciones cuando surge un conflicto.

Fuente: https://blog.sei.io/sei-v2-the-first-parallelized-evm/

La implementación de Sei resulta en tarifas de gas más baratas y un espacio de diseño más amplio para los desarrolladores de EVM. Históricamente, los entornos de EVM han estado limitados a <50 TPS, lo que obligó a los desarrolladores a crear aplicaciones que seguían patrones anti. Sei V2 permite a los desarrolladores abordar sectores que típicamente requieren alto rendimiento y tarifas bajas, como DeFi, DePIN y Gaming.

Visión general del diseño paralelo - Mónada

Monad está construyendo una capa EVM paralela de nivel 1 con compatibilidad total de bytecode. Lo que hace único a Monad no es solo su motor de paralelización, sino lo que han construido bajo el capó para optimizarlo. Monad adopta un enfoque único para su diseño general al incorporar varias características clave, incluyendo la segmentación, E/S asincrónica, separación de consenso y ejecución, y MonadDB.

Una innovación clave en el diseño de Monad es pipeliningcon un ligero desplazamiento. El desplazamiento permite paralelizar más procesos ejecutando múltiples instancias simultáneamente. Por lo tanto, se utiliza el encauzamiento para optimizar una serie de funciones, como el encauzamiento de acceso al estado, el encauzamiento de ejecución de transacciones, el encauzamiento dentro del consenso y la ejecución, y el encauzamiento dentro del propio mecanismo de consenso.

A continuación, haremos doble clic en la pieza de paralelización de Monad. En Monad, las transacciones están ordenadas de forma lineal dentro del bloque, pero el objetivo es alcanzar este estado final más rápido aprovechando la ejecución paralela. Monad utiliza un algoritmo de paralelización optimista para el diseño de su motor de ejecución. El motor de Monad procesa las transacciones simultáneamente y luego realiza un análisis para garantizar que el resultado sería idéntico si las transacciones se ejecutaran una tras otra. Si hay conflictos, es necesario volver a ejecutar. La ejecución paralela aquí es un algoritmo relativamente simple, pero combinarlo con las otras innovaciones clave de Monad es lo que hace que este enfoque sea novedoso. Hay que tener en cuenta que incluso si se produce una reejecución, generalmente es económica porque los insumos necesarios para una transacción inválida casi siempre permanecerán en la caché, por lo que será una simple búsqueda en caché. La reejecución está garantizada para tener éxito porque ya has ejecutado las transacciones anteriores en el bloque.

Monad también mejora el rendimiento al separar la ejecución y el consenso, al igual que Solana y Sei, además de la ejecución diferida. La idea aquí es que si relajas la condición para que la ejecución se complete al mismo tiempo que el consenso, puedes ejecutar ambos en paralelo, lo que resulta en tiempo adicional para ambos. Por supuesto, Monad utiliza un algoritmo determinista para manejar esta condición y asegurarse de que ninguno de estos se ejecute demasiado lejos sin posibilidad de alcanzarlo.

Enfoques únicos para el acceso al estado y la memoria

Como mencioné al principio de esta publicación, el acceso al estado es uno de los cuellos de botella de rendimiento típicos para las cadenas de bloques. Las decisiones de diseño en torno al acceso al estado y la memoria pueden dictar en última instancia si una implementación específica de un sistema paralelo mejorará el rendimiento en la práctica. Aquí, desglosaremos y compararemos los diferentes enfoques tomados por Solana, Sei y Monad.

Acceso al estado de Solana: AccountsDB / Cloudbreak

Solana utiliza escalado horizontal para distribuir y gestionar datos de estado en múltiples dispositivos SSD. Muchas cadenas de bloques hoy en día utilizan bases de datos genéricas (es decir, LevelDB) con limitaciones en el manejo de un gran número de lecturas y escrituras concurrentes de datos de estado. Para evitar esto, Solana construyó su propio accountsDB personalizado aprovechandoCloudbreak.

Cloudbreak está diseñado para el acceso paralelo a través de operaciones de E/S en lugar de depender únicamente de la RAM, que es inherentemente rápida. Las operaciones de E/S (Entrada/Salida) se refieren a la lectura de datos desde o la escritura de datos en una fuente externa, como un disco, red o dispositivo periférico. Inicialmente, Cloudbreak utilizaba un índice en la RAM para asignar claves públicas a cuentas que contenían saldos y datos. Sin embargo, al momento de escribir este documento y en la versión 1.9, el índice ha sido trasladado de la RAM a los SSD. Este cambio permite que Cloudbreak maneje simultáneamente 32 operaciones de E/S en su cola, mejorando el rendimiento en múltiples SSDs. En consecuencia, los datos de la cadena de bloques como cuentas y transacciones pueden ser accedidos eficientemente, como si estuvieran en la RAM utilizando archivos mapeados en memoria. El gráfico a continuación representa una jerarquía de memoria ilustrativa. Aunque la RAM es más rápida, tiene menos capacidad que los SSD y generalmente es más cara:

Diagrama ilustrativo de jerarquía de memoria

Al escalar horizontalmente y distribuir datos de estado en varios dispositivos, Cloudbreak reduce la latencia y mejora la eficiencia, la descentralización y la resistencia de la red dentro del ecosistema de Solana.

Acceso a Sei State: SeiDB

Sei ha rediseñado su almacenamiento, SeiDB, para abordar varios problemas: amplificación de escritura (cuántos metadatos se necesitan para mantener las estructuras de datos, cuanto más pequeño mejor), inflación de estado, operaciones lentas y degradación del rendimiento con el tiempo. El nuevo rediseño ahora se divide en dos componentes: almacenamiento de estado y compromiso de estado. El registro y la verificación de cualquier cambio en los datos son manejados por el compromiso de estado, mientras que la base de datos que mantiene registro de todos los datos en cualquier momento es manejada por el almacenamiento de estado (SS).

En Sei V2, el Compromiso de Estado utiliza un mapeado de memoria Arquitectura de árbol IAVL (MemIAVL). El árbol IAVL mapeado en memoria almacena menos metadatos, lo que reduce el almacenamiento del estado y los tiempos de sincronización del estado y facilita mucho la ejecución de un nodo completo. El árbol IAVL mapeado en memoria se representa como tres archivos en disco (kv, branch, leaves); por lo tanto, se necesita rastrear menos metadatos, lo que ayuda a reducir el almacenamiento del estado en más del 50%. La nueva estructura MemIAVL ayuda a reducir el factor de amplificación de escritura porque reduce los metadatos necesarios para mantener las estructuras de datos.

La SeiDB actualizada permite un soporte flexible de la base de datos para la capa de almacenamiento de estado. Sei cree que diferentes operadores de nodos tendrán requisitos y necesidades de almacenamiento diversos. Por lo tanto, el SS ha sido diseñado para adaptarse a diferentes backends, proporcionando a los operadores libertad y flexibilidad, es decir, PebbleDB, RocksDB, SQLite, etc.

Acceso al estado: MonadDB

Hay algunos matices importantes para el acceso al estado de Monad. En primer lugar, la mayoría de los clientes de Ethereum aprovechan dos tipos de bases de datos: bases de datos B-Tree (es decir, LMDB) o bases de datos de árbol de combinación estructurada por registro (LSM) (es decir, RocksDB, LevelDB). Ambas son estructuras de datos genéricas no diseñadas explícitamente para las cadenas de bloques. Además, estas bases de datos no aprovechan los avances más actualizados en la tecnología de Linux, especialmente en lo que respecta a operaciones asincrónicas y optimizaciones de E/S. Por último, Ethereum mismo gestiona el estado utilizandoPatricia Merkle Trie, que se especializa en criptografía, verificación y pruebas. El problema principal es que los clientes deben integrar este Patricia Merkle Trie específico en bases de datos más genéricas (es decir, B-Tree / LSM), con importantes inconvenientes de rendimiento como un acceso excesivo al disco duro.

Todo lo anterior ayuda a preparar el escenario de por qué Monad decidió crear su base de datos personalizada MonadDB, diseñada específicamente para manejar los datos de blockchain y el acceso al estado de manera más eficiente. Algunas de las características clave de MonadDB incluyen una base de datos de acceso paralelo, una base de datos personalizada optimizada para datos de Merkle Trie, acceso eficiente al estado sobre el uso estándar de RAM, y descentralización y escalabilidad.

MonadDB está diseñado específicamente para cadenas de bloques, lo que lo hace más eficiente que aprovechar bases de datos genéricas. El MonadDB personalizado está especializado y adaptado para gestionar eficientemente datos de tipo árbol de Merkle, lo que permite el acceso paralelo a múltiples nodos de árbol al mismo tiempo. Aunque el costo de una sola lectura en MonadDB frente a algunas de las bases de datos genéricas mencionadas anteriormente es el mismo, la propiedad clave aquí es que MonadDB puede ejecutar muchas lecturas en paralelo, lo que conduce a una aceleración masiva.

MonadDB permite el acceso simultáneo al estado de la base de datos de acceso paralelo. Debido a que Monad está construyendo esta base de datos desde cero, puede aprovechar las tecnologías más actualizadas del kernel de Linux y toda la potencia de las SSD para E/S asincrónica. Con E/S asincrónica, si una transacción requiere leer un estado desde el disco, esto no debería detener las operaciones a la espera de su finalización. En su lugar, debería comenzar la lectura y continuar procesando simultáneamente otras transacciones. Así es como la E/S asincrónica acelera significativamente el procesamiento para MonadDB. Monad puede extraer un mejor rendimiento del hardware optimizando el uso de las SSD y reduciendo la dependencia de RAM excesiva. Esto tiene el beneficio adicional de alinearse con la descentralización y la escalabilidad.

Resumen de comparaciones para Solana vs. Sei vs. Monad

Conclusión

En conclusión, explorar la paralelización en cadenas de bloques a través de la lente de Solana, Sei y Monad proporciona una comprensión integral de cómo diferentes arquitecturas y enfoques pueden mejorar el rendimiento y la escalabilidad. La paralelización determinista de Solana, con su énfasis en declarar el acceso al estado por adelantado, ofrece previsibilidad y eficiencia, lo que lo convierte en una opción potente para aplicaciones que requieren un alto rendimiento. Por otro lado, el enfoque optimista de paralelización de Sei prioriza la flexibilidad del desarrollador y es adecuado para entornos donde los conflictos de transacciones son poco frecuentes. Con su combinación única de paralelización optimista y MonadDB personalizado, Monad presenta una solución innovadora que aprovecha los últimos avances tecnológicos para optimizar el acceso al estado y el rendimiento.

Cada cadena de bloques presenta un enfoque distinto para abordar los desafíos de la paralelización, con su propio conjunto de compensaciones. El diseño de Solana está orientado a maximizar la utilización del hardware y el rendimiento, mientras que Sei se centra en facilitar el proceso de desarrollo, y Monad hace hincapié en una solución de base de datos a medida para los datos de la cadena de bloques. Estas diferencias resaltan la diversidad en el ecosistema de la cadena de bloques y la importancia de elegir la plataforma adecuada en función de las necesidades específicas de la aplicación.

A medida que el espacio de la cadena de bloques continúa evolucionando, los avances en técnicas de paralelización demostrados por Solana, Monad y Sei sin duda inspirarán más innovación. El viaje hacia cadenas de bloques más eficientes, escalables y amigables para los desarrolladores está en curso, y las lecciones aprendidas de estas plataformas jugarán un papel crucial en la formación del futuro de la tecnología de cadenas de bloques.

En la Parte II de esta serie, profundizaremos en las implicaciones económicas y compensaciones asociadas con estos sistemas de diseño paralelos.

Descargo de responsabilidad：

1. Este artículo es reproducido de [Reciprocal Ventures], Todos los derechos de autor pertenecen al autor original [Ali Sheikh]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Aprenderequipo, y ellos lo manejarán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las 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.