TLDR: Este artigo de pesquisa fornece uma visão geral das arquiteturas de design paralelo para blockchains, usando três exemplos relevantes: Solana, Sei e Monad. Ele destaca as diferenças entre a paralelização otimista e determinística e examina as nuances do acesso ao estado e à memória em meio a essas cadeias.

Introdução

Em 1837, o cientista da computação e matemático Charles Babbage projetou o “Máquina Analítica,” que lançou as bases teóricas para a computação paralela. Hoje, a paralelização é um tema fundamental dentro do mundo cripto, à medida que as blockchains tentam empurrar os limites de processamento, eficiência e throughput.

O Universo Paralelo

A computação paralela permite que muitos cálculos ou processos sejam executados simultaneamente, em oposição a cálculos executados em série ou um após o outro. A computação paralela refere-se à divisão de problemas maiores em partes menores e independentes que podem ser executadas por vários processadores comunicando-se via memória compartilhada. Sistemas paralelos têm várias vantagens, como eficiência e velocidade aumentadas, escalabilidade, confiabilidade e tolerância a falhas aprimoradas, melhor utilização de recursos e a capacidade de lidar com conjuntos de dados muito grandes.

No entanto, é crucial reconhecer que a eficácia da paralelização depende dos detalhes da arquitetura subjacente e da implementação. Dois gargalos principais para blockchains são funções criptográficas (funções hash, assinaturas, curvas elípticas, etc.) e acesso à memória/estado. Com blockchains, um dos componentes-chave do design de um sistema paralelo eficiente reside nos detalhes do acesso ao estado. O acesso ao estado refere-se à capacidade de uma transação de ler e escrever no estado de uma blockchain, incluindo armazenamento, contratos inteligentes e saldos de contas. Para que uma blockchain paralelizada seja eficaz e performática, o acesso ao estado deve ser otimizado.

Atualmente, existem duas correntes de pensamento sobre a otimização do acesso ao estado para blockchains paralelizados: paralelização determinística vs. paralelização otimista. A paralelização determinística requer que o código declare explicitamente antecipadamente quais partes do estado do blockchain serão acessadas e modificadas. Isso permite que um sistema determine quais transações podem ser processadas em paralelo sem conflitos antecipadamente. A paralelização determinística permite previsibilidade e eficiência (especialmente quando as transações são principalmente independentes). No entanto, ela cria mais complexidade para os desenvolvedores.

A paralelização otimista não requer que o código declare antecipadamente o acesso ao estado e processa transações em paralelo como se não houvesse conflitos. Se um conflito surgir, a paralelização otimista irá ou reexecutar, reprocesar ou executar as transações conflitantes em série. Embora a paralelização otimista permita mais flexibilidade para os desenvolvedores, a reexecução é necessária para conflitos, resultando neste método sendo mais eficiente quando as transações não estão em conflito. Não há uma resposta certa quanto a qual dessas abordagens é melhor. Elas são simplesmente duas abordagens diferentes (e viáveis) para a paralelização.

Na Parte I desta série, primeiro exploraremos alguns conceitos básicos de sistemas paralelos não criptográficos, seguidos pelo espaço de design para execução paralela para blockchains, focando em três áreas principais:

1. Visão geral dos Sistemas Paralelos de Criptomoeda
2. Abordagens para Acesso à Memória e Estado
3. Oportunidades de Design Paralelo

Sistemas Paralelos Não-Cripto

Levando em consideração o que acabamos de ler sobre o que a computação paralela possibilita e as vantagens dos sistemas paralelos, é fácil entender por que a adoção da computação paralela decolou nos últimos anos. O aumento da adoção da computação paralela possibilitou muitas descobertas apenas nas últimas décadas.

1. Imagem Médica: O processamento paralelo transformou fundamentalmente a imagem médica, levando a aumentos significativos na velocidade e resolução em várias modalidades, como RM, TC, raios-X e tomografia óptica. A Nvidia está na vanguarda desses avanços, fornecendo aos radiologistas capacidades aprimoradas de inteligência artificial por meio de seu kit de processamento paralelo, que permite que os sistemas de imagem lidem de forma mais eficaz com o aumento de dados e cargas computacionais.
2. Astronomia: Alguns novos fenômenos, como entender os buracos negros, só foram possíveis utilizando supercomputadores paralelos.
3. Motor de Jogo da Unity: O motor da Unity utiliza as capacidades das GPUs - que são construídas para cargas de trabalho gráficas massivas - para ajudar na performance e velocidade. O motor está equipado com recursos de processamento multithread e paralelo, proporcionando uma experiência de jogo fluida e criando ambientes de jogo complexos e detalhados.

Vamos examinar três blockchains que implementaram ambientes de execução paralelos. Primeiro, iremos desempacotar Solana, seguido por duas cadeias baseadas em EVM, Monad e Sei.

Visão geral do Design Paralelo - Solana

Em um nível elevado, a filosofia de design da Solana é que a inovação em Blockchain deve evoluir com os avanços de hardware. À medida que o hardware melhora ao longo do tempo através da Lei de Moore, a Solana é projetada para se beneficiar do aumento de desempenho e escalabilidade. Co-Fundador da SolanaAnatoly Yakovenkoinicialmente projetadoA arquitetura de paralelização da Solanahá mais de cinco anos, e hoje, o paralelismo como um princípio de design de blockchain está se espalhando rapidamente.

Solana usa paralelização determinística, que vem da experiência passada de Anatoly trabalhando com sistemas embarcados, onde normalmente você declara todo o estado antecipadamente. Isso permite que a CPU conheça todas as dependências, o que possibilita pré-buscar as partes necessárias da memória. O resultado é uma execução do sistema otimizada, mas novamente, requer que os desenvolvedores façam trabalho extra antecipadamente. Na Solana, todas as dependências de memória para um programa são necessárias e declaradas na transação construída (ou seja, Listas de Acesso), permitindo que o tempo de execução agende e execute várias transações em paralelo de forma eficiente.

O próximo componente principal da arquitetura da Solana é o Sealevel VM, que é o tempo de execução de contratos inteligentes paralelos da Solana. O Sealevel suporta nativamente o processamento de vários contratos e transações em paralelo com base no número de núcleos que um validador possui. Um validador em uma blockchain é um participante da rede responsável por verificar e validar transações, propor novos blocos e manter a integridade e segurança da blockchain. Como as transações declaram quais contas precisam ser lidas e gravadas antecipadamente, o agendador da Solana é capaz de determinar quais transações podem ser executadas em paralelo. Devido a isso, quando se trata de validação, o “Produtor de Blocos” ou Líder é capaz de classificar milhares de transações pendentes e agendar as transações não sobrepostas em paralelo.

O último elemento de design para o Solana é o “pipelining”. O pipelining ocorre quando os dados precisam ser processados em uma série de etapas, e diferentes hardwares são responsáveis por cada um. A ideia chave aqui é pegar os dados que precisam ser executados de forma serial e paralelizá-los usando o pipelining. Esses pipelines podem ser executados em paralelo, e cada estágio do pipeline pode processar lotes de transações diferentes.

Essas otimizações permitem que Sealevel organize e execute transações independentes simultaneamente, utilizando a capacidade do hardware de processar vários pontos de dados ao mesmo tempo com um único programa. Sealevel classifica as instruções por programID e executa a mesma instrução em todas as contas relevantes em paralelo.

Com essas inovações em mente, podemos ver que Solana foi projetado intencionalmente para suportar a paralelização.

Visão Geral do Design Paralelo - Sei

Sei é uma blockchain de camada 1 de código aberto de uso geral especializada na troca de ativos digitais. Sei V2 utiliza a paralelização otimista e, como resultado, é mais amigável aos desenvolvedores do que sua contraparte determinística. Na paralelização otimista, contratos inteligentes podem ser executados de forma mais fluida e simultânea sem exigir que os desenvolvedores declarem seus recursos antecipadamente. Isso significa que a cadeia executa otimisticamente todas as transações em paralelo. Ainda assim, quando há conflitos (ou seja, múltiplas transações acessando o mesmo estado), a blockchain manterá o controle do componente de armazenamento específico que cada transação em conflito impacta.

A blockchain da Sei aborda a execução de transações usando o “Optimistic Concurrency Control (OCC)”. O processamento de transações simultâneas ocorre quando várias transações estão vivas simultaneamente em um sistema. Existem duas fases neste enfoque de transação: execução e validação.

Na fase de execução, as transações são processadas de forma otimista, com todas as leituras/escritas armazenadas temporariamente em uma loja específica da transação. Após isso, cada transação entrará na fase de validação, onde as informações nas operações de armazenamento temporário são verificadas em relação a quaisquer alterações de estado feitas por transações anteriores. Se uma transação for independente, a transação será executada em paralelo. Se uma transação ler dados modificados por outra transação, isso criaria um conflito. O sistema paralelo da Sei identificará cada conflito comparando os conjuntos de leitura das transações versus as últimas alterações de estado em uma loja de várias versões (estas são indexadas pela ordem da transação). A Sei reexecutará e revalidará instâncias onde surgirem conflitos. Este é um processo iterativo envolvendo execução, validação e reexecução para corrigir os conflitos. O gráfico abaixo ilustra a abordagem da Sei para transações quando surge um conflito.

Fonte: https://blog.sei.io/sei-v2-o-primeiro-evm-paralelizado/

A implementação da Sei resulta em taxas de gás mais baratas e um espaço de design mais amplo para os desenvolvedores da EVM. Historicamente, os ambientes da EVM têm sido limitados a menos de 50 TPS, o que forçou os desenvolvedores a criar aplicativos que seguiam antipadrões. A Sei V2 permite que os desenvolvedores abordem setores que normalmente requerem alto desempenho e baixas taxas, como DeFi, DePIN e Jogos.

Visão geral do design paralelo - Monad

Monad está construindo uma camada paralela EVM Layer 1 com compatibilidade total de bytecode. O que torna o Monad único não é apenas seu mecanismo de paralelização, mas o que eles construíram por baixo do capô para otimizá-lo. Monad adota uma abordagem única para seu design geral ao incorporar várias características-chave, incluindo encadeamento, E/S assíncrona, separação de consenso e execução e MonadDB.

Uma inovação chave no design do Monad épipeliningcom um leve deslocamento. O deslocamento permite que mais processos sejam paralelizados executando várias instâncias simultaneamente. Portanto, o encadeamento é usado para otimizar uma série de funções, como encadeamento de acesso ao estado, encadeamento de execução de transações, encadeamento dentro do consenso e execução, e encadeamento dentro do mecanismo de consenso em si.

A seguir, vamos dar um duplo clique na peça de paralelização do Monad. No Monad, as transações são ordenadas linearmente dentro do bloco, mas o objetivo é alcançar mais rapidamente esse estado final, aproveitando a execução paralela. O Monad utiliza um algoritmo de paralelização otimista para o design de sua engine de execução. A engine do Monad processa as transações simultaneamente e depois realiza uma análise para garantir que o resultado seria idêntico se as transações fossem executadas uma após a outra. Se houver algum conflito, será necessário reexecutar. A execução paralela aqui é um algoritmo relativamente simples, mas combiná-lo com as outras inovações-chave do Monad é o que torna essa abordagem inovadora. Uma coisa a se observar aqui é que, mesmo que ocorra a reexecução, geralmente é barata porque as entradas necessárias para uma transação inválida quase sempre permanecerão em cache, então será uma simples busca em cache. A reexecução está garantida para ter sucesso porque você já executou as transações anteriores no bloco.

Monad também melhora o desempenho ao separar a execução e o consenso, semelhante ao Solana e Sei, além da execução adiada. A ideia aqui é que, se você relaxar a condição para a execução ser concluída no momento em que o consenso estiver completo, você pode executar ambos em paralelo, resultando em tempo adicional para ambos. Claro, Monad usa um algoritmo determinístico para lidar com essa condição para garantir que um deles não avance muito sem a possibilidade de alcançar.

Abordagens Únicas para Acesso ao Estado & Memória

Como mencionei no início deste post, o acesso ao estado é um dos gargalos de desempenho típicos para blockchains. As escolhas de design em torno do acesso ao estado e da memória podem determinar, em última instância, se uma implementação específica de um sistema paralelo melhorará o desempenho na prática. Aqui, iremos desembalar e comparar as diferentes abordagens tomadas por Solana, Sei e Monad.

Acesso ao Estado Solana: AccountsDB / Cloudbreak

Solana utiliza escalonamento horizontal para distribuir e gerenciar dados de estado em vários dispositivos SSD. Muitas blockchains hoje utilizam bancos de dados genéricos (ou seja, LevelDB) com limitações no manuseio de um grande número de leituras e gravações simultâneas de dados de estado. Para evitar isso, Solana construiu sua própria conta personalizadaDB aproveitandoCloudbreak.

Cloudbreak é projetado para acesso paralelo em operações de I/O, em vez de depender apenas da RAM, que é inerentemente rápida. Operações de I/O (Input/Output) referem-se à leitura de dados de ou escrita de dados para uma fonte externa, como um disco, rede, ou dispositivo periférico. Inicialmente, Cloudbreak utilizava um índice em RAM para mapear chaves públicas para contas que possuíam saldos e dados. No entanto, ao escrever este documento e na versão 1.9, o índice foi movido da RAM para SSDs. Essa mudança permite que o Cloudbreak lide simultaneamente com 32 operações de I/O em sua fila, melhorando a taxa de transferência em vários SSDs. Consequentemente, os dados da blockchain, como contas e transações, podem ser acessados de forma eficiente, como se estivessem na RAM usando arquivos mapeados em memória. O gráfico abaixo representa uma hierarquia de memória ilustrativa. Embora a RAM seja mais rápida, ela tem menos capacidade do que SSD e geralmente é mais cara:

Diagrama ilustrativo da hierarquia de memória

Ao escalar horizontalmente e distribuir dados de estado em vários dispositivos, o Cloudbreak reduz a latência e melhora a eficiência, descentralização e resiliência da rede dentro do ecossistema Solana.

Acesso ao Estado Sei: SeiDB

Sei redesenhou seu armazenamento, SeiDB, para resolver várias questões: amplificação de escrita (quanta metadados são necessários para manter estruturas de dados, menor = melhor), inchaço de estado, operações lentas e degradação de desempenho ao longo do tempo. O novo redesenho agora está dividido em dois componentes: armazenamento de estado e confirmação de estado. O registro e verificação de quaisquer alterações nos dados são tratados pela confirmação de estado, enquanto o banco de dados que mantém registro de todos os dados em qualquer ponto é tratado pelo armazenamento de estado (SS).

No Sei V2, o Compromisso de Estado usa um mapeamento de memória Arquitetura de árvore IAVL (MemIAVL). A árvore IAVL mapeada na memória armazena menos metadados, o que reduz o armazenamento de estado e os tempos de sincronização de estado e torna a execução de um nó completo muito mais fácil. A árvore IAVL mapeada na memória é representada como três arquivos no disco (kv, branch, leaves); portanto, menos metadados precisam ser rastreados, o que ajuda a reduzir o armazenamento de estado em mais de 50%. A nova estrutura MemIAVL ajuda a reduzir o fator de amplificação de gravação porque reduz os metadados necessários para manter as estruturas de dados.

A atualização do SeiDB permite suporte flexível ao backend do banco de dados para a camada de armazenamento de estado. Sei acredita que diferentes operadores de nó terão requisitos e necessidades de armazenamento diversos. Portanto, o SS foi projetado para acomodar diferentes back-ends, fornecendo aos operadores liberdade e flexibilidade, ou seja, PebbleDB, RocksDB, SQLite, etc.

Acesso Estadual: MonadDB

Existem algumas nuances importantes para o acesso ao estado do Monad. Em primeiro lugar, a maioria dos clientes Ethereum alavanca dois tipos de bancos de dados: bancos de dados B-Tree (ou seja, LMDB) ou bancos de dados de árvore de mesclagem estruturada de log (LSM) (ou seja, RocksDB, LevelDB). Ambos são estruturas de dados genéricas não projetadas explicitamente para blockchains. Além disso, esses bancos de dados não aproveitam os avanços mais recentes na tecnologia Linux, especialmente em relação às operações assíncronas e otimizações de E/S. Por fim, o próprio Ethereum gerencia o estado usando Patricia Merkle Trie, que se especializa em criptografia, verificação e provas. O principal problema é que os clientes devem integrar esta árvore Patricia Merkle específica em bancos de dados mais genéricos (ou seja, B-Tree / LSM), com inconvenientes de desempenho significativos, como acesso excessivo ao disco.

Tudo isso ajuda a preparar o terreno para o motivo pelo qual o Monad decidiu criar seu banco de dados personalizado MonadDB, especialmente projetado para lidar de forma mais eficiente com dados e acesso ao estado da blockchain. Algumas das principais características do MonadDB incluem um banco de dados de acesso paralelo, um banco de dados personalizado otimizado para dados de Merkle Trie, acesso eficiente ao estado sobre o uso padrão de RAM e descentralização e escalabilidade.

MonadDB é explicitamente projetado para blockchains, tornando-o mais eficiente do que o uso de bancos de dados genéricos. O MonadDB personalizado é especializado e adaptado para gerenciar eficientemente dados do tipo Merkle trie, permitindo acesso paralelo a vários nós de trie ao mesmo tempo. Embora o custo de uma única leitura no MonadDB em comparação com alguns dos bancos de dados genéricos listados acima seja o mesmo, a propriedade-chave aqui é que o MonadDB pode executar muitas leituras em paralelo, resultando em uma aceleração massiva.

MonadDB permite o acesso simultâneo ao estado do banco de dados de acesso paralelo. Como o Monad está construindo esse banco de dados do zero, ele é capaz de aproveitar as tecnologias mais atualizadas do kernel Linux e todo o poder dos SSDs para E/S assíncronas. Com E/S assíncronas, se uma transação requer a leitura de estado do disco, isso não deve interromper as operações aguardando a conclusão. Em vez disso, deve iniciar a leitura e continuar processando outras transações simultaneamente. É assim que E/S assíncronas acelera significativamente o processamento para MonadDB. Monad é capaz de extrair melhor desempenho do hardware otimizando o uso do SSD e reduzindo a dependência de RAM excessiva. Isso tem o benefício adicional de se alinhar com a descentralização e escalabilidade.

Resumo das Comparações para Solana vs. Sei vs. Monad

Conclusão

Em conclusão, explorar a paralelização em blockchains através das lentes de Solana, Sei e Monad fornece uma compreensão abrangente de como diferentes arquiteturas e abordagens podem aprimorar o desempenho e a escalabilidade. A paralelização determinística da Solana, com ênfase na declaração antecipada do acesso ao estado, oferece previsibilidade e eficiência, tornando-a uma escolha poderosa para aplicativos que exigem alta taxa de transferência. Por outro lado, a abordagem de paralelização otimista da Sei prioriza a flexibilidade do desenvolvedor e é adequada para ambientes onde conflitos de transação são pouco frequentes. Com sua combinação única de paralelização otimista e MonadDB personalizado, o Monad apresenta uma solução inovadora que alavanca os mais recentes avanços tecnológicos para otimizar o acesso ao estado e o desempenho.

Cada blockchain apresenta uma abordagem distinta para enfrentar os desafios da paralelização, com seu próprio conjunto de compensações. O design da Solana é voltado para maximizar a utilização de hardware e o throughput, enquanto o Sei se concentra em facilitar o processo de desenvolvimento, e o Monad enfatiza uma solução de banco de dados sob medida para dados de blockchain. Essas diferenças destacam a diversidade no ecossistema blockchain e a importância de escolher a plataforma certa com base nas necessidades específicas da aplicação.

À medida que o espaço blockchain continua a evoluir, os avanços nas técnicas de paralelização demonstradas pela Solana, Monad e Sei certamente inspirarão mais inovação. A jornada rumo a blockchains mais eficientes, escaláveis e amigáveis aos desenvolvedores está em andamento, e as lições aprendidas dessas plataformas desempenharão um papel crucial na formação do futuro da tecnologia blockchain.

Na Parte II desta série, vamos mergulhar nas implicações econômicas e compensações associadas a esses sistemas de design paralelos.

Disclaimer：

1. Este artigo foi reimpresso de [Empresas Recíprocas], Todos os direitos autorais pertencem ao autor original [Ali Sheikh]. Se houver objeções a esta reimpressão, entre em contato com o Gate Aprenderequipe e eles vão lidar com isso prontamente.
2. Isenção de Responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. Salvo indicação em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.