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. Destaca as diferenças entre paralelização otimista e determinística e examina as nuances do acesso ao estado e à memória em todas essas cadeias.

Introdução

Em 1837, o cientista da computação e matemático Charles Babbage projetou o “Máquina Analítica,” que estabeleceu a base teórica para a computação paralela. Hoje, a paralelização é um tema fundamental no mundo das criptomoedas, à medida que as blockchains tentam empurrar os limites do processamento, eficiência e débito.

O Universo Paralelo

A computação paralela permite que muitos cálculos ou processos sejam executados simultaneamente, em oposição a cálculos executados de forma serial 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 que comunicam através de memória partilhada. Os sistemas paralelos têm várias vantagens, como maior eficiência e velocidade, escalabilidade, melhor fiabilidade e tolerância a falhas, 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 e implementação subjacentes. Dois dos principais gargalos das blockchains são funções criptográficas (funções de hash, assinaturas, curvas elípticas, etc.) e acesso à memória/estado. Com as blockchains, um dos principais componentes de design de um sistema paralelo eficiente está 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 paralela seja eficaz e eficiente, o acesso ao estado deve ser otimizado.

Atualmente, existem duas correntes de pensamento sobre a otimização do acesso ao estado para blockchains paralelizadas: 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, isso cria mais complexidade para os desenvolvedores.

A paralelização otimista não requer que o código declare antecipadamente o acesso ao seu estado e processa transações em paralelo como se não houvesse conflitos. Se um conflito surgir, a paralelização otimista irá reexecutar, reprocesar ou executar as transações conflituosas em série. Embora a paralelização otimista permita mais flexibilidade para os desenvolvedores, a reexecução é necessária para conflitos, resultando nesse 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, exploraremos primeiro alguns conceitos básicos de sistemas paralelos não criptográficos, seguidos pelo espaço de design para execução paralela de blockchains, com foco em três áreas principais:

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

Sistemas Paralelos Não-Cripto

Tendo em conta o que acabamos de ler sobre o que a computação paralela permite e as vantagens dos sistemas paralelos, é fácil perceber por que a adoção da computação paralela tem descolado nos últimos anos. O aumento da adoção da computação paralela tem permitido muitos avanços, 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 MRI, CT, raios-X e tomografia ótica. A Nvidia está na vanguarda desses avanços, fornecendo aos radiologistas capacidades aprimoradas de inteligência artificial através do seu toolkit de processamento paralelo, o 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 a compreensão de buracos negros, só foram possíveis graças a 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 maciças - para ajudar com o desempenho e a velocidade. O motor está equipado com funcionalidades de processamento multithreaded e paralelo, proporcionando uma experiência de jogo perfeita e criando ambientes de jogo complexos e detalhados.

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

Visão Geral do Design Paralelo – Solana

Num nível elevado, a filosofia de design da Solana é que a inovação 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 beneficiar do aumento de desempenho e escalabilidade. Co-Fundador da Solana Anatoly Yakovenkoinicialmente projetadoarquitetura de paralelização da Solanahá mais de cinco anos, e hoje, o paralelismo como um princípio de design blockchain está se espalhando rapidamente.

Solana utiliza a paralelização determinística, que vem da experiência passada de Anatoly a trabalhar com sistemas incorporados, onde normalmente se declara todo o estado de antemão. Isto permite à CPU conhecer todas as dependências, o que lhe permite pré-carregar as partes necessárias da memória. O resultado é uma execução do sistema otimizada, mas novamente, requer que os programadores 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 múltiplas transações em paralelo de forma eficiente.

O próximo grande componente da arquitetura da Solana é a VM Sealevel, que é o tempo de execução de contrato inteligente paralelo da Solana. O Sealevel suporta nativamente o processamento de múltiplos 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. Uma vez que as transações declaram quais contas precisam ser lidas e bloqueadas 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 Bloco” ou Líder é capaz de classificar milhares de transações pendentes e agendar as transações não sobrepostas em paralelo.

O elemento de design final para 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 dados que precisam ser executados em série 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.

Estas otimizações permitem à Sealevel organizar e executar transações independentes simultaneamente, utilizando a capacidade do hardware para processar vários pontos de dados de uma só vez com um único programa. A Sealevel classifica as instruções por programID e executa a mesma instrução em todas as contas relevantes em paralelo.

Com estas inovações em mente, podemos ver que Solana foi projetada 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. O Sei V2 aproveita a paralelização otimista e, como resultado, é mais amigável para os desenvolvedores do que seu homólogo determinístico. Na paralelização otimista, os contratos inteligentes podem ser executados de forma mais transparente 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 conflitante impacta.

A blockchain da Sei aborda a execução de transações usando o “Controlo de Concorrência Otimista (OCC).” O processamento de transações concorrentes ocorre quando múltiplas transações estão simultaneamente ativas num sistema. Existem duas fases neste método 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 temporariamente armazenadas 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 da loja temporária são verificadas em relação a quaisquer alterações de estado feitas por transações anteriores. Se uma transação for independente, ela será executada em paralelo. Se uma transação ler dados modificados por outra transação, isso criaria um conflito. O sistema paralelo do Sei identificará cada conflito comparando os conjuntos de leitura das transações com as últimas alterações de estado em uma loja de várias versões (indexadas por ordem de transação). Sei reexecutará e revalidará os casos em que surgirem conflitos. Este é um processo iterativo que envolve execução, validação e nova execução para corrigir os conflitos. O gráfico abaixo ilustra a abordagem do Sei para transações quando surge um conflito.

Origem: 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 do EVM. Historicamente, os ambientes EVM têm sido limitados a <50 TPS, o que forçou os desenvolvedores a criar aplicativos que seguiam anti-padrõ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

A Monad está a construir uma camada paralela EVM Layer 1 com total compatibilidade de bytecodes. O que torna a Monad única não é apenas o seu motor de paralelização, mas sim o que construíram por baixo para o otimizar. A Monad adota uma abordagem única ao seu design global, incorporando várias funcionalidades-chave, incluindo pipeline, I/O assíncrono, separação de consenso e execução eMonadDB.

Uma inovação chave no design do Monad épipeliningcom um ligeiro desfasamento. O desfasamento permite paralelizar mais processos, executando várias instâncias simultaneamente. Portanto, o encadeamento é usado para otimizar um número 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 entrar em detalhes na peça de paralelização do Monad. No Monad, as transações são ordenadas linearmente dentro do bloco, mas o objetivo é atingir este estado final mais rapidamente, aproveitando a execução paralela. O Monad utiliza um algoritmo de paralelização otimista para o design do seu mecanismo de execução. O mecanismo do Monad processa transações simultaneamente e depois realiza uma análise para garantir que o resultado seja idêntico se as transações fossem executadas uma após a outra. Se houver conflitos, é necessário reexecutar. A execução paralela aqui é um algoritmo relativamente simples, mas a combinação com as outras inovações-chave do Monad é o que torna essa abordagem inovadora. Um ponto a observar é que mesmo que ocorra uma reexecução, geralmente é barata, pois as entradas necessárias para uma transação inválida quase sempre permanecem em cache, sendo assim, é apenas uma simples consulta ao cache. A reexecução é garantida para ter sucesso, pois 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, ao relaxar a condição para que a execução seja concluída no momento em que o consenso é concluído, você pode executar ambos em paralelo, resultando em tempo adicional para ambos. Claro que o Monad usa um algoritmo determinístico para lidar com essa condição e garantir que um deles não avance demais sem possibilidade de alcançar o outro.

Abordagens Únicas para Acesso ao Estado & Memória

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

Acesso ao Estado da Solana: ContasDB / Cloudbreak

Solana utiliza escalonamento horizontal para distribuir e gerir dados de estado em vários dispositivos SSD. Muitas blockchains hoje em dia utilizam bases de dados genéricas (ou seja, LevelDB) com limitações no tratamento de um grande número de leituras e escritas concorrentes de dados de estado. Para evitar isso, Solana construiu a sua própria accountsDB personalizada aproveitandoCloudbreak.

O Cloudbreak é projetado para acesso paralelo em operações de E/S, em vez de depender exclusivamente da RAM, que é inherentemente rápida. Operações de E/S (Entrada/Saída) referem-se à leitura de dados de ou escrita de dados para uma fonte externa, como um disco, rede ou dispositivo periférico. Inicialmente, o Cloudbreak empregava um índice em RAM para mapear chaves públicas para contas que possuem saldos e dados. No entanto, no momento da redação deste artigo e na versão 1.9, o índice foi movido para fora da RAM e para SSDs. Essa mudança permite que o Cloudbreak lide simultaneamente com 32 operações de E/S em sua fila, aumentando o throughput em vários SSDs. Consequentemente, dados de 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, 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 por vários dispositivos, o Cloudbreak reduz a latência e melhora a eficiência, a descentralização e a resiliência da rede dentro do ecossistema Solana.

Acesso ao Estado Sei: SeiDB

Sei redesenhou o seu armazenamento, SeiDB, para resolver vários problemas: amplificação de escrita (quanta metadados é necessário 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 compromisso de estado. Gravar e verificar quaisquer alterações nos dados é tratado pelo compromisso 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 do Estado usa um mapeamento de memória Arquitetura da árvore IAVL (MemIAVL). A árvore IAVL mapeada em 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 em 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.

O SeiDB atualizado permite suporte flexível ao banco de dados backend para a camada de armazenamento de estado. A Sei acredita que diferentes operadores de nós terão requisitos e necessidades de armazenamento diversos. Portanto, o SS foi projetado para acomodar diferentes backends, proporcionando aos operadores liberdade e flexibilidade, ou seja, PebbleDB, RocksDB, SQLite, etc.

Acesso ao Estado: MonadDB

Existem algumas nuances importantes no acesso ao estado do Monad. Em primeiro lugar, a maioria dos clientes Ethereum utiliza dois tipos de bases de dados: bases de dados B-Tree (ou seja, LMDB) ou bases de dados de árvore de mesclagem log-estruturada (LSM) (ou seja, RocksDB, LevelDB). Ambas são estruturas de dados genéricas não explicitamente concebidas para blockchains. Além disso, essas bases de dados não tiram partido das mais recentes inovações na tecnologia Linux, especialmente no que diz respeito a operações assíncronas e otimizações de I/O. Por último, o próprio Ethereum gere o estado utilizando 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 bases de dados mais genéricas (ou seja, B-Tree / LSM), com desvantagens de desempenho significativas, como acesso excessivo ao disco.

Tudo o que foi referido acima ajuda a preparar o terreno para a decisão da Monad de criar a sua base de dados personalizada MonadDB, especificamente concebida para lidar de forma mais eficiente com os dados da blockchain e o acesso ao estado. Algumas das principais características do MonadDB incluem uma base de dados de acesso paralelo, uma base de dados personalizada otimizada para Dados Merkle Trie, acesso eficiente ao estado sobre a utilização padrão da RAM, e descentralização e escalabilidade.

O MonadDB é explicitamente projetado para blockchains, tornando-o mais eficiente do que a utilização de bancos de dados genéricos. O MonadDB personalizado é especializado e adaptado para gerir eficientemente dados do tipo árvore de Merkle, permitindo o acesso paralelo a vários nós da árvore ao mesmo tempo. Embora o custo de uma única leitura no MonadDB versus 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, levando a uma aceleração maciça.

O MonadDB permite o acesso simultâneo ao estado ao banco de dados de acesso paralelo. Como o Monad está a construir esta base de dados do zero, consegue aproveitar as tecnologias mais atualizadas do kernel Linux e todo o poder dos SSDs para E/S assíncrona. Com E/S assíncrona, se uma transação requer ler um estado do disco, isso não deve parar as operações à espera da conclusão. Em vez disso, deve começar a leitura e continuar simultaneamente a processar outras transações. É assim que a E/S assíncrona acelera significativamente o processamento para o MonadDB. O Monad consegue extrair melhor desempenho do hardware, otimizando o uso do SSD e reduzindo a dependência de memória RAM excessiva. Isso tem o benefício adicional de estar alinhado 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 nas blockchains através das lentes da Solana, Sei e Monad fornece uma compreensão abrangente de como diferentes arquiteturas e abordagens podem melhorar 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 aplicações que requerem 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 os conflitos de transações são pouco frequentes. Com sua combinação única de paralelização otimista e MonadDB personalizado, a Monad apresenta uma solução inovadora que aproveita 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 está voltado para maximizar a utilização de hardware e throughput, enquanto a Sei se concentra em facilitar o processo de desenvolvimento, e o Monad enfatiza uma solução de banco de dados feita sob medida para dados de blockchain. Essas diferenças destacam a diversidade no ecossistema de 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 em técnicas de paralelização demonstrados por Solana, Monad e Sei, sem dúvida, irão inspirar ainda mais inovação. A jornada em direção 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.

Aviso Legal：

1. Este artigo é reproduzido a partir de [Reciprocal Ventures], Todos os direitos de autor pertencem ao autor original [Ali Sheikh]. Se houver objeções a esta reimpressão, por favor entre em contato com o Gate Learnequipa 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.