TL;DR

1. As EVMs Paralelos representam uma nova narrativa que surge à medida que os volumes de transações on-chain atingem um certo nível. Eles são principalmente divididos em blockchains monolíticos e blockchains modulares, sendo os monolíticos ainda categorizados em L1 e L2. As cadeias públicas paralelas L1 são divididas em dois campos: EVM e não-EVM. Atualmente, a narrativa paralela de EVM está nos estágios iniciais de desenvolvimento.
2. O caminho de implementação técnica de EVMs paralelas inclui máquinas virtuais e mecanismos de execução paralela. No contexto das blockchains, uma máquina virtual é uma máquina virtual de processo que virtualiza a máquina de estado distribuída para executar contratos.
3. A execução paralela refere-se à alavancagem de processadores multicore para executar múltiplas transações simultaneamente, tanto quanto possível, garantindo que o estado final seja consistente com o que seria alcançado através da execução em série.
4. Os mecanismos de execução paralela são divididos em três categorias: passagem de mensagens, memória partilhada e listas de acesso a estados estritos. A memória partilhada é ainda dividida no modelo de bloqueio de memória e na paralelização otimista. Independentemente do mecanismo, cada um aumenta a complexidade técnica.
5. A narrativa de EVMs paralelos não só tem impulsionadores intrínsecos do crescimento da indústria, como também requer que os praticantes prestem muita atenção às potenciais questões de segurança.
6. Cada projeto EVM paralelo fornece sua abordagem única para a execução paralela, mostrando tanto as semelhanças técnicas quanto as inovações distintas.

1.Visão geral da indústria

1.1 Evolução histórica

O desempenho tornou-se um obstáculo para o desenvolvimento futuro na indústria. As redes de Blockchain criam uma base de confiança nova e descentralizada para transações entre indivíduos e empresas.

As redes blockchain de primeira geração, representadas pelo Bitcoin, pioneiraram um novo modo de transações de moeda eletrônica descentralizada com tecnologia de livro-razão distribuído, revolucionando uma nova era. A segunda geração, exemplificada pelo Ethereum, utilizou plenamente a imaginação para propor aplicações descentralizadas (dApps) através de uma abordagem de máquina de estado distribuída.

Desde então, as redes blockchain embarcaram em seu próprio desenvolvimento rápido ao longo de mais de uma década, desde a infraestrutura Web3 até várias áreas como DeFi, NFTs, redes sociais e GameFi, dando origem a inúmeras inovações em tecnologia e modelos de negócios. A indústria próspera precisa atrair continuamente novos usuários para participar do ecossistema de aplicativos descentralizados, o que, por sua vez, aumenta as exigências para a experiência do produto.

Web3, como uma forma de produto inovadora “sem precedentes na história,” deve inovar ao atender às necessidades do utilizador (requisitos funcionais) enquanto equilibra entre segurança e desempenho (requisitos não funcionais). Desde a sua criação, diversas soluções têm sido propostas para abordar questões de desempenho.

Estas soluções podem geralmente ser categorizadas em dois tipos: soluções de escalonamento on-chain, como shardings e Gráficos Acíclicos Direcionados (DAGs), e soluções de escalonamento off-chain, como Plasma, Lightning Networks, sidechains e Rollups. No entanto, estas ainda estão longe de acompanhar o rápido crescimento das transações on-chain.

Especialmente após o Verão DeFi de 2020 e o crescimento explosivo das inscrições no ecossistema Bitcoin no final de 2023, a indústria precisa urgentemente de novas soluções de melhoria de desempenho para atender às demandas por 'alto desempenho e baixas taxas.' As blockchains paralelas nasceram neste contexto.

1.2 Tamanho do mercado

A narrativa do EVM paralelo significa um cenário competitivo onde dois grandes players dominam no campo das blockchains paralelas. O Ethereum processa transações em série, executando-as uma após a outra, o que resulta em baixa utilização de recursos. A mudança de processamento em série para paralelo poderia melhorar significativamente o desempenho.

Os rivais da Ethereum, como Solana, Aptos e Sui, todos apresentam capacidades de processamento paralelo incorporadas e desenvolveram ecossistemas robustos. Suas respectivas capitalizações de mercado de tokens atingiram $45 bilhões, $3.3 bilhões e $1.9 bilhões, formando um campo paralelo não-EVM. Em resposta a esses desafios, o ecossistema da Ethereum não fica para trás, com diversos projetos avançando para potencializar o EVM, criando assim um campo EVM paralelo.

Sei, na sua proposta de atualização da versão 2, declarou em alto e bom som que se tornará o “primeiro blockchain EVM paralelo,” com uma capitalização de mercado atual de $2.1 bilhões e potencial para um crescimento ainda maior. O novo blockchain EVM paralelo Monad, atualmente o mais quente em fervor de marketing, é muito apreciado pelos investidores e tem um potencial significativo. Enquanto isso, o blockchain L1 Canto, com uma capitalização de mercado de $170 milhões e sua própria infraestrutura pública gratuita, também anunciou sua proposta de atualização paralela do EVM.

Além disso, vários projetos L2 em estágio inicial estão aprimorando o desempenho entre ecossistemas, integrando as capacidades de várias cadeias L1. Além do Neon, que atingiu um valor de mercado circulante de $69 milhões, outros projetos ainda carecem de dados relevantes. Espera-se que mais projetos L1 e L2 se juntem ao campo de batalha blockchain paralelo no futuro.

Não só existe um potencial significativo de crescimento de mercado para a narrativa paralela da EVM, mas o setor mais amplo de blockchains paralelos aos quais a EVM paralela pertence também possui um potencial significativo de crescimento de mercado, prometendo uma perspectiva de mercado abrangente.

Atualmente, a capitalização de mercado total para a Camada 1 e Camada 2 é de $752.123 bilhões, com blockchains paralelos tendo uma capitalização de mercado de $52.539 bilhões, representando aproximadamente 7%. Dentro disso, os projetos relacionados com a narrativa EVM paralela têm uma capitalização de mercado de $2.339 bilhões, representando apenas 4% da capitalização de mercado do blockchain paralelo.

1.3 Mapa da Indústria

A indústria geralmente divide as redes blockchain numa estrutura de quatro camadas:

Camada 0 (Rede): Esta é a camada de rede blockchain subjacente que lida com os protocolos básicos de comunicação em rede.

Camada 1 (Infraestrutura): Esta camada depende de vários mecanismos de consenso para validar transações dentro de uma rede descentralizada.

Camada 2 (Expansão): Dependente da Camada 1, isso envolve vários protocolos de segunda camada destinados a abordar as limitações da Camada 1, especialmente em termos de escalabilidade.

Camada 3 (Aplicação): Dependente da Camada 2 ou Camada 1, esta camada é usada para construir várias aplicações descentralizadas (dApps).

Os projetos narrativos paralelos da EVM (Máquina Virtual Ethereum) são principalmente divididos em blockchains monolíticos e blockchains modulares, com os blockchains monolíticos divididos ainda em L1 e L2. A partir do número total de projetos e do desenvolvimento de várias principais vertentes, pode-se ver que os ecossistemas de blockchains públicos L1 paralelos da EVM ainda têm um espaço significativo para crescimento em comparação com o ecossistema do Ethereum.

Na pista DeFi, há uma demanda por “alta velocidade e baixas taxas”, enquanto a pista de jogos exige “interação forte em tempo real”; ambos exigem uma certa velocidade de execução. As EVMs paralelas inevitavelmente trarão melhores experiências de usuário para esses projetos, impulsionando o desenvolvimento da indústria para uma nova fase.

L1 representa novas cadeias públicas com capacidades inerentes de execução paralela e serve como infraestrutura de alto desempenho. Nesta facção, projetos como Sei v2, Monad e Canto têm EVMs paralelas independentemente projetadas, que são compatíveis com o ecossistema Ethereum e oferecem altas capacidades de throughput de transações.

L2, ao integrar as capacidades de outras cadeias L1, oferece capacidade expandida para cooperação entre ecossistemas e é um exemplo proeminente da tecnologia rollup. Nesta facção, Neon atua como um emulador EVM na rede Solana, enquanto Eclipse executa transações na Solana mas liquida no EVM. Lumio é semelhante ao Eclipse, exceto que a camada de execução foi alterada para Aptos.

Além das mencionadas soluções de blockchain autónomas, a Fuel introduziu o seu próprio conceito modular de blockchain. Na sua segunda versão, tem como objetivo posicionar-se como um sistema operativo de rollup Ethereum, oferecendo capacidades de execução modular mais flexíveis e abrangentes.

A Fuel concentra-se na execução de transações, enquanto terceiriza outros componentes para uma ou mais camadas independentes de blockchain, permitindo assim combinações mais flexíveis: pode funcionar como uma Camada 2, uma Camada 1, ou até mesmo como uma sidechain ou um canal de estado. Atualmente, existem 17 projetos dentro do ecossistema Fuel, focando principalmente em DeFi, NFTs e infraestrutura.

No entanto, apenas o Orally cross-chain oracle foi colocado em uso prático. A plataforma de empréstimos descentralizada Swaylend e a plataforma de negociação de contratos perpétuos SPARK foram lançadas em testnets, enquanto outros projetos ainda estão em desenvolvimento.

2. Caminhos de Implementação Técnica

Para alcançar a execução de transações descentralizada, as redes blockchain devem cumprir quatro responsabilidades:

• Execução: Executando e validando transações.
• Disponibilidade de Dados: Distribuição de novos blocos para todos os nós na rede blockchain.
• Mecanismo de Consenso: Verificação de blocos e alcançar consenso.
• Settlement: Liquidar e registar o estado final das transações.

O EVM paralelo concentra-se principalmente na otimização de desempenho da camada de execução. Isso é dividido em soluções de Camada 1 (L1) e soluções de Camada 2 (L2). As soluções L1 introduzem um mecanismo para a execução paralela de transações, permitindo que as transações sejam executadas em paralelo dentro da máquina virtual tanto quanto possível. As soluções L2 alavancam fundamentalmente a máquina virtual L1 já paralelizada para alcançar algum nível de "execução off-chain + liquidação on-chain".

Portanto, para entender os princípios técnicos do EVM paralelo, é necessário desmembrá-lo: primeiro, entender o que é uma máquina virtual (VM) e depois compreender o que implica a execução paralela.

2.1 Máquina virtual

Em ciência da computação, uma máquina virtual refere-se à virtualização ou emulação de um sistema de computador.

Existem dois tipos de máquinas virtuais: máquinas virtuais de sistema, que podem virtualizar uma única máquina física em várias máquinas executando sistemas operativos diferentes, melhorando assim a utilização de recursos; e máquinas virtuais de processo, que fornecem uma abstração para certas linguagens de programação de alto nível, permitindo que programas de computador escritos nessas linguagens sejam executados de forma independente da plataforma em diferentes plataformas.

A JVM é uma máquina virtual de processos projetada para a linguagem de programação Java. Os programas escritos em Java são primeiro compilados em bytecode Java (um estado intermediário de código binário), que é então interpretado pela JVM: a JVM envia o bytecode para um intérprete, que o traduz em código de máquina para diferentes máquinas e, em seguida, o executa na máquina.

As máquinas virtuais blockchain são um tipo de máquina virtual de processo. No contexto da blockchain, uma máquina virtual refere-se à virtualização de uma máquina de estado distribuída usada para a execução distribuída de contratos, executando dApps. Analogamente ao JVM, o EVM é uma máquina virtual de processo projetada para a linguagem Solidity, onde os contratos inteligentes são primeiro compilados em bytecode de opcode, e depois interpretados pelo EVM.

As cadeias públicas emergentes para além da Ethereum frequentemente adotam máquinas virtuais baseadas em WASM ou bytecode eBPF. WASM é um formato compacto, de carregamento rápido, portátil, baseado em mecanismos de segurança de sandbox. Os desenvolvedores podem escrever contratos inteligentes em várias linguagens de programação (C, C++, Rust, Go, Python, Java, ou até mesmo TypeScript), compilá-los em bytecode WASM e executá-los. Os contratos inteligentes executados na blockchain Sei usam este formato de bytecode.

eBPF originou-se de BPF (Berkeley Packet Filter), inicialmente usado para filtragem eficiente de pacotes de rede, e evoluiu para eBPF, oferecendo um conjunto de instruções mais rico.

É uma tecnologia revolucionária que permite a intervenção dinâmica e modificação do comportamento do núcleo do sistema operativo sem alterar o código-fonte. Mais tarde, esta tecnologia avançou para além do núcleo, levando ao desenvolvimento do tempo de execução eBPF no espaço do utilizador, que é altamente performante, seguro e portátil. Os contratos inteligentes executados na Solana são compilados em bytecode eBPF e executados na sua rede blockchain.

Outras cadeias públicas L1 como Aptos e Sui utilizam a linguagem de programação de contratos inteligentes Move, compilando em bytecode proprietário executado na máquina virtual Move. Monad projetou sua própria máquina virtual compatível com bytecode de opcode EVM (fork de Xangai).

2.2 Execução paralela

A execução paralela é uma técnica que aproveita as vantagens dos processadores multi-core para lidar com várias tarefas simultaneamente, aumentando assim o throughput do sistema. Garante que os resultados das transações sejam idênticos aos obtidos quando as transações são executadas em série.

Nas redes blockchain, o TPS (Transações Por Segundo) é comumente usado como um indicador técnico para medir a velocidade de processamento. O mecanismo de execução paralela é complexo e representa um desafio às habilidades técnicas dos desenvolvedores, tornando difícil de explicar. Aqui, usaremos o exemplo de um "banco" para explicar o que é a execução paralela.

(1) Primeiro, o que é execução em série?

Cenário 1: Se considerarmos o sistema como um banco e a CPU de processamento de tarefas como um balcão, então a execução de tarefas em série é semelhante a este banco ter apenas um balcão disponível para o serviço. Neste caso, os clientes (tarefas) que vêm ao banco devem formar uma longa fila e tratar dos seus assuntos um por um. Para cada cliente, o pessoal do balcão deve repetir as mesmas ações (executar instruções) para atender o cliente. Os clientes devem esperar a sua vez, o que leva a tempos de transação prolongados.

(2) Então, o que é execução paralela?

Cenário 2: Se o banco perceber que está lotado, pode abrir vários balcões para tratar dos negócios, com quatro funcionários a trabalhar nos balcões simultaneamente. Isto aumenta a velocidade aproximadamente quatro vezes em comparação com a original, e o tempo que os clientes passam na fila também é reduzido para cerca de um quarto do original. Assim, a velocidade de tratamento dos negócios no banco é aumentada.

(3) Que erro ocorre se não houver proteções em vigor e duas pessoas transferirem dinheiro simultaneamente para outra pessoa?

Cenário 3: Vamos considerar A, B e C, que têm 2 ETH, 1 ETH e 0 ETH nas suas contas, respetivamente. Agora, A e B querem transferir 0,5 ETH para C. Num sistema que executa transações em série, não ocorreriam problemas (a seta esquerda "\u003c=" indica leitura do livro-razão, e a seta direita "=\u003e" indica escrita no livro-razão, o mesmo abaixo):

No entanto, a execução paralela não é tão simples como parece. Existem muitos detalhes subtis que podem levar a erros graves se não forem tratados com cuidado. Se as transações de A e B transferindo para C forem executadas em paralelo, a sequência de passos pode resultar em resultados inconsistentes:

A Tarefa Paralela 1 executa a transferência de A para C, e a Tarefa Paralela 2 executa a transferência de B para C. Os passos marcados com um asterisco são problemáticos: porque as tarefas são executadas em paralelo, no Passo 2, o cálculo de saldo feito pela Tarefa Paralela 1 ainda não foi escrito no livro-razão. No Passo 3, a Tarefa Paralela 2 lê o saldo da conta de C (que ainda é 0) e realiza um cálculo de saldo errôneo com base nisso no Passo 5. Em seguida, na operação de atualização do livro-razão no Passo 6, ele atualiza incorretamente o saldo da conta, que já foi atualizado para 0.5 no Passo 4, de volta para 0.5 novamente. Isso resulta no saldo da conta de C sendo apenas 0.5 ETH, apesar de tanto A quanto B terem transferido 0.5 ETH cada, fazendo com que os outros 0.5 ETH desapareçam efetivamente.

(4) Se não houver proteções implementadas, duas tarefas que não dependem uma da outra podem ser executadas em paralelo sem erros

Cenário 4: A Tarefa Paralela 1 executa uma transferência de 0.5 ETH de A (saldo 2 ETH) para C (saldo 0 ETH), e a Tarefa Paralela 2 executa uma transferência de 0.5 ETH de B (saldo 1 ETH) para D (saldo 0 ETH). É evidente que não há dependência entre essas duas tarefas de transferência. Independentemente de como os passos das duas tarefas são entrelaçados, elas não encontrarão os problemas descritos acima:

Da comparação destes cenários, pode ser analisado que sempre que haja uma dependência entre tarefas, poderão ocorrer erros na atualização de estado durante a execução paralela; caso contrário, não ocorrerão erros. Uma tarefa (transação) é considerada ter uma relação de dependência se cumprir uma das seguintes duas condições:

1. Uma tarefa escreve para um endereço de saída que outra tarefa lê como um endereço de entrada;
2. Duas tarefas de saída para o mesmo endereço.

Este problema não é exclusivo de sistemas descentralizados. Qualquer cenário envolvendo execução paralela pode sofrer de inconsistências de dados devido ao acesso desprotegido a recursos compartilhados (como o "livro-razão" no exemplo bancário ou memória compartilhada em sistemas informáticos) entre múltiplas tarefas dependentes, conhecidas como corridas de dados.

A indústria propôs três mecanismos para resolver os problemas de corrida de dados na execução paralela: mecanismos de passagem de mensagens, mecanismos de memória compartilhada e mecanismos de lista de acesso estrito ao estado.

2.3 Mecanismo de Passagem de Mensagens

Cenário 5: Considere um banco com quatro balcões de serviço operando simultaneamente para os clientes. Cada caixa nesses balcões recebe um bloco único, que só eles podem modificar. Este bloco regista os saldos das contas dos clientes que atendem.

Sempre que um caixa lida com uma transação, se as informações do cliente estiverem disponíveis no seu livro-razão, ele prossegue diretamente. Se não, ele chama outros caixas para informá-los das necessidades de transação do cliente, e o caixa que ouviu assume a tarefa.

Isto exemplifica o princípio do modelo de passagem de mensagens. O modelo de Actor é um tipo de modelo de passagem de mensagens, onde cada entidade que manipula transações é um ator (atendente), cada um com acesso aos seus dados privados (o livro-razão exclusivo). Acesso aos dados privados de outra pessoa só pode ser alcançado através do envio de mensagens.

Vantagens do Modelo de Ator:

Cada ator tem acesso apenas aos seus dados privados, evitando assim problemas de condição de corrida.

Desvantagens do Modelo de Ator:

Cada ator só pode executar tarefas sequencialmente. Em certos cenários, isso não aproveita as vantagens do paralelismo. Por exemplo, se os caixas n.º 2, 3 e 4 enviarem mensagens simultaneamente para perguntar ao caixa n.º 1 sobre o saldo da conta do cliente A, o caixa n.º 1 só pode processar esses pedidos um de cada vez, mesmo que pudessem ser tratados em paralelo.

Não há uma visão global do estado atual do sistema. Se as operações do sistema forem complexas, torna-se desafiador entender a situação geral, localizar e corrigir bugs.

Mecanismo de Memória Compartilhada 2.4

2.4.1 Modelo de Bloqueio de Memória

Cenário 6: Imagine um banco com apenas um grande livro-razão que regista os saldos das contas de todos os seus clientes. Ao lado do livro-razão, há apenas uma caneta disponível para efetuar modificações nele.

Neste cenário, a competição entre quatro caixas de banco torna-se uma corrida de velocidade: um caixa agarra a caneta primeiro (trava-a) e começa a modificar o livro-razão, enquanto os outros três têm de esperar. Uma vez que o caixa termina e pousa a caneta (destrava-a), os três caixas seguintes apressam-se a agarrar a caneta. Este ciclo repete-se, exemplificando o modelo de bloqueio de memória.

Um bloqueio de memória permite que tarefas em execução em paralelo bloqueiem um recurso compartilhado antes de acessá-lo. Após o recurso ser bloqueado, outras tarefas devem esperar até que tenha sido modificado e desbloqueado antes que possam bloquear e acessá-lo novamente.

O modelo de bloqueio de leitura-escrita oferece uma abordagem mais refinada, permitindo que várias tarefas paralelas adicionem bloqueios de leitura a um recurso compartilhado e acessem seus dados várias vezes. Durante isso, modificações não são permitidas; no entanto, um bloqueio de escrita pode ser aplicado apenas por um de cada vez e, uma vez aplicado, concede acesso exclusivo ao detentor do recurso.

Plataformas Blockchain como Solana, Sui e Sei v1 usam um modelo de memória compartilhada baseado em bloqueios de memória. Este mecanismo pode parecer simples, mas é complexo de implementar e requer que os desenvolvedores tenham habilidades sofisticadas em programação multithreading. Descuido pode levar a vários bugs:

Cenário 1: Uma tarefa bloqueia um recurso compartilhado, mas falha durante a execução, deixando o recurso inacessível.

Cenário 2: Uma tarefa bloqueia um recurso, mas acaba bloqueando-o novamente devido à lógica de negócios aninhada, resultando num impasse onde aguarda a si mesma.

O modelo de bloqueio de memória é propenso a problemas como deadlocks, livelocks e starvation:

1. O impasse ocorre quando várias tarefas paralelas disputam vários recursos compartilhados, com cada tarefa detendo uma parte deles e aguardando que outros liberem suas partes.
2. O livelock ocorre quando tarefas paralelas detetam que outras tarefas estão ativas e voluntariamente renunciam à sua posse de recursos partilhados, levando a um ciclo contínuo de cedência.
3. A inanição ocorre quando as tarefas de alta prioridade ganham consistentemente acesso a recursos compartilhados, enquanto as tarefas de baixa prioridade suportam uma espera prolongada.

2.4.2 Optimistic Parallelism

Cenário 7

Num banco, quatro caixas têm a capacidade de aceder e modificar independentemente o razão durante as transações, independentemente de os outros caixas estarem a utilizar o razão. Ao utilizar o razão, cada caixa aplica um rótulo pessoal às entradas que acedem ou modificam. Após completar uma transação, eles revêem as entradas novamente; se encontrarem um rótulo que não é o deles, indica que a entrada foi modificada por outro caixa, e a transação deve ser anulada e processada novamente.

Isto exemplifica o princípio básico do paralelismo otimista. A ideia central do paralelismo otimista é assumir inicialmente que todas as tarefas são independentes. As tarefas são executadas em paralelo e, em seguida, cada tarefa é validada. Se uma tarefa falhar na validação, ela é reexecutada até que todas as tarefas sejam concluídas. Suponha que haja oito tarefas paralelas realizadas de forma otimista, precisando de acesso a dois recursos compartilhados, A e B.

Durante a Fase 1, as tarefas 1, 2 e 3 são executadas em paralelo. No entanto, as tarefas 2 e 3 acedem ao recurso partilhado B simultaneamente, causando um conflito, assim a tarefa 3 é reprogramada para a próxima fase. Na Fase 2, as tarefas 3 e 4 acedem ambas ao recurso B, resultando na tarefa 4 ser reprogramada, e assim sucessivamente, até que todas as tarefas estejam completas. Como se pode ver, as tarefas que encontram conflitos são repetidamente reexecutadas.

Modelo de Paralelismo Otimista

O modelo de paralelismo otimista utiliza uma estrutura de dados em memória multi-versão para registar cada valor escrito e a sua informação de versão (semelhante aos rótulos usados pelos caixas de banco).

A execução de cada tarefa paralela é dividida em duas fases: execução e validação. Durante a fase de execução, todas as ações de leitura e escrita de dados são registadas, formando um conjunto de leitura e um conjunto de escrita. Na fase de validação, o conjunto de leitura e o conjunto de escrita são comparados com a estrutura de dados de múltiplas versões. Se a comparação revelar que os dados não são os mais recentes, a validação falha.

O modelo de paralelismo otimista teve origem no Software Transaction Memory (STM), um mecanismo de programação sem bloqueio no campo da base de dados. Como as redes de blockchain mantêm inherentemente uma ordem definida de transações, este conceito foi introduzido e evoluiu para o mecanismo de Bloco-STM. Plataformas de blockchain como Aptos e Monad adotaram o Bloco-STM como seu mecanismo de execução paralela.

Vale a pena mencionar que a cadeia pública Sei, na sua próxima versão v2, abandonou o modelo de bloqueio de memória original em favor do modelo de paralelismo otimista. O Bloco-STM executa transações a um ritmo extremamente rápido; num ambiente de teste, o Aptos alcançou uma impressionante velocidade de execução de transações de 160k transações por segundo (tps), que é 18 vezes mais rápido do que o processamento de transações sequenciais.

O Block-STM delega a execução e validação complexas das transações à equipa de desenvolvimento principal, permitindo aos programadores escrever contratos inteligentes tão facilmente como se estivessem a programar num ambiente de execução sequencial.

2.5 Lista Estrita de Acesso ao Estado

Os mecanismos de passagem de mensagens e de memória partilhada baseiam-se no modelo de dados de conta/saldo, que regista as informações de saldo de cada conta na blockchain. É semelhante a como o livro-razão de um banco mostra que o Cliente A tem um saldo de 1.000 unidades e o Cliente B tem um saldo de 600 unidades. As transações são processadas simplesmente atualizando o estado de saldo das contas.

Alternativamente, também se poderia registar os detalhes de cada transação no momento da transação, criando um livro-razão de transações. Este livro-razão pode ser usado para calcular os saldos das contas. Por exemplo:

• O cliente A abre uma conta e deposita 1.000 unidades;
• O cliente B abre uma conta (0 unidades);
• O cliente A transfere 100 unidades para o cliente B.

Ao ler e calcular o livro-razão, pode determinar-se que o Cliente A tem um saldo de 900 unidades e o Cliente B tem um saldo de 100 unidades.

UTXO (Unspent Transaction Output) é semelhante a este modelo de dados de registro de transações. Representa um método de denotar moeda digital no Bitcoin, a blockchain de primeira geração. Cada transação tem inputs (como os fundos foram recebidos) e outputs (como os fundos foram gastos), e os UTXOs podem ser entendidos simplesmente como os recibos de fundos que ainda não foram gastos.

Por exemplo, se o Cliente A tiver 6 BTC e transferir 5,2 BTC para o Cliente B, deixando 0,8 BTC, do ponto de vista do UTXO, parece assim: Os 6 UTXOs avaliados em 1 BTC cada são destruídos, e B recebe um novo UTXO no valor de 5,2 BTC, enquanto A recebe um novo UTXO no valor de 0,8 BTC como troco. Assim, 6 UTXOs são destruídos para criar 2 novos UTXOs.

As entradas e saídas de uma transação estão ligadas e usam assinaturas digitais para registrar informações de propriedade, formando assim o modelo UTXO. As blockchains que adotam este modelo de dados precisam somar todos os UTXOs para um determinado endereço de conta para determinar o saldo atual da conta. A Lista de Acesso ao Estado Estrito (SSAL) é baseada no modelo UTXO e permite a execução paralela. Ela pré-calcula os endereços de conta que cada transação acessará, formando uma lista de acesso.

A lista de acesso serve dois propósitos:

1. Avaliação de Segurança da Transação: Se uma transação acede a um endereço que não está na lista de acesso, a execução falha.
2. Execução Paralela de Transações: De acordo com a lista de acesso, as transações são agrupadas em vários conjuntos. Como não existem dependências (sem interseções) entre os conjuntos na lista de acesso, esses conjuntos de transações podem ser executados em paralelo.

3. Impulsionadores de crescimento da indústria

De uma perspectiva intrínseca, o desenvolvimento de qualquer coisa geralmente progride desde a conceção até à refinamento, e a busca da humanidade pela velocidade é eterna. Para resolver os problemas de velocidade de execução nas redes blockchain, uma variedade de soluções, tanto on-chain como off-chain, surgiram. As soluções off-chain, como rollups, têm sido plenamente reconhecidas pelo seu valor, enquanto a narrativa das Máquinas Virtuais Ethereum paralelas (EVM) ainda oferece significativas oportunidades de exploração.

Historicamente, com a aprovação da SEC de um ETF spot de Bitcoin e o próximo evento de redução pela metade do Bitcoin, juntamente com possíveis cortes nas taxas de juros pela Reserva Federal, espera-se que as criptomoedas entrem em um mercado touro significativo. O crescimento robusto da indústria requer infraestruturas de rede blockchain capazes de lidar com maior throughput como uma base sólida.

Em termos de gestão de recursos, as redes blockchain tradicionais processam transações em série, um método direto mas ineficiente que desperdiça recursos do processador. Em contraste, os blockchains paralelos fazem pleno uso dos recursos de computação, extraem significativamente o potencial de desempenho dos processadores multi-core, melhorando assim a eficiência global das redes blockchain.

No que diz respeito ao desenvolvimento da indústria, embora várias inovações tecnológicas e de modelos de negócio estejam continuamente a surgir, o potencial de crescimento na Web3 permanece amplamente inexplorado. As redes centralizadas podem lidar com mais de 50.000 mensagens por segundo, enviar 3,4 milhões de emails, completar 100.000 pesquisas no Google e suportar dezenas de milhares de jogadores online simultaneamente, feitos ainda não alcançados pelas redes descentralizadas. Para os sistemas descentralizados competirem e conquistarem o seu território, a otimização contínua dos mecanismos de execução paralela e o aumento da capacidade de transações são essenciais.

Do ponto de vista das aplicações descentralizadas, atrair mais usuários requer esforços significativos na melhoria da experiência do usuário. A otimização de desempenho é uma direção chave para melhorar a experiência do usuário. Para os usuários de DeFi, atender às demandas de alta velocidade de transação e baixas taxas é crucial. Para os usuários de GameFi, a interação em tempo real é necessária. Todos esses requisitos são suportados pela robustez da execução paralela.

4.Existing problems

O “trilema do blockchain” afirma que a descentralização, segurança e escalabilidade só podem satisfazer dois dos três atributos simultaneamente. Como a “descentralização” é um pilar imutável, melhorar a “escalabilidade” implica uma redução na “segurança”. Uma vez que o código é escrito por humanos, está sujeito a erros. A complexidade técnica introduzida pela computação paralela fornece um terreno fértil para potenciais vulnerabilidades de segurança.

A programação multithread é particularmente desafiadora devido a dois problemas principais: primeiro, está sujeita a condições de corrida devido ao tratamento inadequado de várias operações complexas de controle concorrente; segundo, pode levar a falhas ao aceder a endereços de memória inválidos, o que pode até levar a vulnerabilidades de overflow de buffer exploráveis por atacantes.

Existem pelo menos três perspetivas a partir das quais avaliar a segurança de um projeto:

1. Antecedentes da Equipa: As equipas com experiência em programação de sistemas são hábeis em programação multithreaded e podem lidar com 80% dos problemas complexos. A programação de sistemas geralmente envolve as seguintes áreas:

• Sistemas operativos
• Vários drivers de dispositivos
• Sistemas de ficheiros
• Bases de dados
• Sistemas embarcados
• Criptografia
• Codecs multimédia
• Gestão de memória
• Rede
• Virtualização
• Jogos
• Linguagens de programação avançadas

2. Manutenção de Código: Escrever código mantível segue uma metodologia clara, como ter um design arquitetônico claro, utilizar padrões de design para implementar reutilização de código, empregar técnicas de desenvolvimento orientado a testes para escrever testes de unidade suficientes e eliminar código redundante através de refatoração cuidadosa.

3. Linguagem de Programação Utilizada: Algumas linguagens de programação de ponta são projetadas com um forte ênfase na segurança de memória e alta concorrência. Os compiladores verificam o código quanto a problemas concorrentes ou potencial acesso a endereços de memória inválidos, resultando em falha de compilação se detectados, forçando assim os desenvolvedores a escrever código robusto.

A linguagem Rust é exemplar neste sentido, razão pela qual vemos que a maioria dos projetos de blockchain paralelos são desenvolvidos em Rust. Alguns projetos até mesmo se inspiram no design do Rust para implementar suas próprias linguagens de contratos inteligentes, como a linguagem Sway da Fuel.

5. Arranjo Alvo

5.1 Com base no modelo de paralelização otimista

5.1.1 De bloqueios de memória ao paralelismo otimista

Sei é uma blockchain pública de uso geral baseada em tecnologia de código aberto, estabelecida em 2022. Os fundadores são ex-alunos da Universidade da Califórnia, Berkeley, e outros membros da equipe também têm formação em prestigiadas universidades no exterior.

Sei recebeu financiamento em três rodadas: uma rodada inicial de $5 milhões, uma primeira rodada de financiamento estratégico de $30 milhões, e uma segunda rodada de financiamento estratégico em que o valor não foi divulgado. A Rede Sei também levantou um total de $100 milhões em fundos para apoiar o desenvolvimento de seu ecossistema.

Em agosto de 2023, a Sei foi lançada na sua mainnet, alegando ser a blockchain pública L1 mais rápida, capaz de processar 12.500 transações por segundo, com finalidade alcançada em apenas 380 ms. Atualmente, tem uma capitalização de mercado de quase $2.2 bilhões.

Atualmente, o ecossistema Sei é composto por 118 projetos, focando principalmente em DeFi, infraestrutura, NFTs, jogos e carteiras. A comunidade atualmente tem 650.000 membros no Twitter, 600.000 no Discord e 40.000 no Telegram.

No final de novembro de 2023, a Sei anunciou em seu blog oficial que iria iniciar a atualização de versão mais significativa desde o lançamento da mainnet na primeira metade de 2024: Sei v2. A Sei v2 é apresentada como a primeira blockchain EVM paralela. Esta atualização de versão irá introduzir as seguintes novas funcionalidades:

• Compatibilidade com versões anteriores para contratos inteligentes EVM: Os desenvolvedores podem migrar e implantar contratos inteligentes EVM sem modificar o código.
• Reutilização para ferramentas/aplicações comuns como Metamask.
• A paralelização otimista: O Sei v2 abandonará o mecanismo de acesso compartilhado de travas de memória em favor da paralelização otimista.
• SeiDB: Otimização da camada de armazenamento.
• Suporte para interoperabilidade contínua entre Ethereum e outras cadeias.

Originalmente, a execução paralela de transações da Sei Network baseava-se num modelo de bloqueio de memória. Antes da execução, todas as dependências entre transações pendentes eram resolvidas e era gerado um DAG, então, com base no DAG, a ordem de execução das transações era precisamente arranjada. Este método aumentou a carga mental nos desenvolvedores de contratos, porque tinham de incorporar a lógica no código durante o desenvolvimento.

Como introduzido na seção de princípios técnicos acima, com a adoção da paralelização otimista na nova versão, os desenvolvedores agora podem escrever contratos inteligentes como se estivessem escrevendo programas executados sequencialmente. Mecanismos complexos, como agendamento, execução e verificação de transações, são tratados pelos módulos subjacentes. O design da proposta de otimização da equipe central também introduziu um aprimoramento adicional das capacidades de execução paralela por meio do preenchimento de dependências.

Especificamente, isso envolve a introdução de um gerador de dependências dinâmico que analisa as operações de escrita de transações antes da execução e as preenche em uma estrutura de dados de memória multi-versão, otimizando possíveis conflitos de dados. Após a análise, a equipe principal concluiu que, embora tal mecanismo de otimização não seja vantajoso no cenário ideal para processamento de transações, melhora significativamente a eficiência de execução no cenário de pior caso.

5.1.2 Potencial Disruptor na Faixa L1: Monad

Se perdeu o desenvolvimento dos blockchains públicos mencionados acima, então definitivamente não deve perder o Monad. É aclamado como um potencial disruptor na categoria L1.

Monad foi fundada por dois engenheiros seniores da Jump Crypto em 2022. O projeto completou uma rodada de financiamento inicial de $19 milhões em fevereiro de 2023. Em março de 2024, a Paradigm liderou as negociações para uma rodada de financiamento de mais de $200 milhões para o Monad. Se bem-sucedido, este seria o maior financiamento de criptomoedas desde o início do ano.

O projeto já alcançou o marco de lançar uma testnet interna e está trabalhando em direção ao próximo passo de abrir uma testnet pública.

Monad é muito favorecido pelo capital por duas razões proeminentes: uma é o seu sólido background técnico, e a outra é a sua proficiência em hype de marketing. A equipe central da Monad Labs é composta por 30 membros, todos os quais têm décadas de experiência profunda em trading de alta frequência, drivers de kernel e tecnologia financeira, e extensa experiência em desenvolvimento em sistemas distribuídos.

As operações diárias do projeto também são muito “fundamentadas”: envolvendo continuamente em “marketing mágico” com seus 200.000 seguidores no Twitter e 150.000 membros no Discord. Por exemplo, realizar concursos semanais de memes, coletar vários emojis ou vídeos de animais roxos peculiares da comunidade, para realizar “disseminação espiritual.”

A visão da Monad é tornar-se uma plataforma de contratos inteligentes para desenvolvedores, trazendo melhorias de desempenho extremas para o ecossistema Ethereum. A Monad introduz dois mecanismos na Máquina Virtual Ethereum: um é a pipelining superescalar e o outro é um mecanismo paralelo otimista aprimorado.

A segmentação superescalar paraleliza a fase de execução das transações. Um exemplo ilustrativo dado na documentação oficial é lavar roupas, que é semelhante à forma como a blockchain processa transações, também concluídas em várias etapas. O método tradicional processa cada pilha de roupas sujas através da lavagem, secagem, dobragem e armazenamento antes de passar para a próxima pilha.

Por outro lado, a canalização de superescalar começa a lavar a segunda pilha de roupas enquanto a primeira está a secar. À medida que a primeira pilha está a ser dobrada, a segunda e terceira pilhas estão, respetivamente, a secar e a lavar, mantendo assim cada fase ativa.

O mecanismo paralelo otimista paraleliza a execução de transações. Monad usa o paralelismo otimista para execução paralela. Também desenvolveu seu próprio analisador de código estático para prever dependências entre transações, agendando transações subsequentes apenas após as transações dependentes pré-requisito terem sido executadas, reduzindo significativamente a reexecução de transações devido a validações falhadas.

Atualmente, o seu desempenho atinge 10.000 TPS e pode produzir blocos dentro de um segundo. À medida que o projeto avança, a equipa principal continuará a explorar mais mecanismos de otimização.

5.1.3 Projeto L1 Altamente Descentralizado: Canto

Estabelecido em 2022, Canto é um projeto L1 altamente descentralizado construído na Cosmos SDK. Opera sem uma fundação oficial, não se envolve em pré-vendas, não está afiliado a nenhuma organização, não procura financiamento e é totalmente impulsionado pela comunidade. Até mesmo a equipe central permanece anônima, trabalhando de forma pouco organizada.

Embora seja uma blockchain geral compatível com a EVM, a visão principal da Canto é tornar-se uma plataforma de valor DeFi acessível, transparente, descentralizada e gratuita. Através de uma extensa pesquisa no setor, descobriu-se que qualquer ecossistema DeFi saudável é composto por três elementos fundamentais:

1. Trocas descentralizadas (DEX) como Uniswap e Sushiswap;
2. Plataformas de empréstimo como Compound e Aave;
3. Tokens descentralizados como DAI, USDC ou USDT.

No entanto, os ecossistemas DeFi tradicionais partilham, em última análise, um destino comum: emitem tokens de protocolo de governação, cujo valor depende da taxa de utilização que o ecossistema pode extrair dos seus futuros utilizadores — quanto mais extraído, maior o valor. Isto é semelhante a cada protocolo DeFi ser um parque de estacionamento de propriedade privada que cobra por hora — quanto mais é usado, maior a sua valoração.

Canto adota outra abordagem: Construir infraestrutura pública gratuita para DeFi (Infraestrutura Pública Gratuita), tornar-se um estacionamento gratuito para seus projetos ecológicos.

A infraestrutura é composta por 3 protocolos: a bolsa descentralizada Canto DEX, a plataforma de empréstimos em pool Canto Lending Market (CLM) bifurcada do Compound v2, e a moeda estável NOTE que pode ser emprestada do CLM através de ativos de garantia.

Canto adotou uma abordagem inovadora: construir infraestrutura pública gratuita direcionada para DeFi, posicionando-se como um estacionamento gratuito disponível para os projetos de seu ecossistema usarem sem custos.

A infraestrutura é composta por três protocolos: a exchange descentralizada Canto DEX, a plataforma de empréstimos agrupada Canto Lending Market (CLM) bifurcada do Compound v2 e a stablecoin NOTE, que pode ser emprestada do CLM usando ativos como garantia.

O Canto DEX opera perpetuamente como um protocolo não atualizável e livre de governança. Nem emite os seus tokens nem cobra taxas adicionais. Este design evita vários comportamentos de busca de renda dentro das aplicações DeFi do ecossistema, evitando jogos predatórios de soma zero.

A governança da plataforma de empréstimos CLM é controlada pelos detentores de interesse, que beneficiam totalmente do crescimento do ecossistema e, por sua vez, criam o melhor ambiente para os desenvolvedores e utilizadores de DeFi, motivando-os a contribuir continuamente. Os juros gerados a partir de empréstimos emitidos em NOTE são pagos aos mutuários, sem o protocolo receber qualquer corte.

Para os desenvolvedores, Canto introduziu o modelo de Receita Segura do Contrato, que aloca uma certa percentagem das taxas geradas a partir de interações on-chain com contratos para os desenvolvedores. Esta série de inovações de modelos de negócios pela Canto, denominada "matar três coelhos com uma cajadada só," promove um ecossistema construtivo e próspero fornecendo infraestrutura financeira aberta e gratuita.

Por vários meios, o Canto incentiva os desenvolvedores e utilizadores do ecossistema a juntarem-se e a enriquecer continuamente o ecossistema. Ao controlar rigorosamente os "direitos de cunhagem", o Canto cria possibilidades de liquidez entre várias aplicações descentralizadas. À medida que o ecossistema prospera, os seus tokens aumentam de valor. Após a proposta do CSR ter sido aprovada pela votação da comunidade em 26 de janeiro de 2024, o token $CANTO teve um aumento de preço.

Após esta série de inovações no modelo de negócios, em 18 de março de 2024, a Canto anunciou a sua mais recente rodada de iterações técnicas no seu blog oficial.

Além de adotar uma nova versão do Cosmos SDK e integrar novas tecnologias para reduzir gargalos de acesso ao armazenamento, Canto também irá atualizar para EVMs paralelas: introduzindo paralelização otimista através da implementação do EVM Cyclone.

O Cosmos SDK usado pelo Canto divide o processamento de transações em três etapas: Proposta, Votação e Finalização. O sub-processo ProcessProposal durante a Votação é responsável pela execução paralela de transações. O motor de execução paralela lida com a execução, enquanto o motor de detecção de conflitos verifica a validade das transações.

Se uma transação for inválida, é enviada de volta para o motor de execução para ser reexecutada; se for válida, é comprometida com o fluxo de processamento subsequente. Acredita-se que esta rodada de atualizações tecnológicas tornará os tokens da Canto ainda mais atrativos.

5.2 Baseado em Listas de Acesso de Estado Estritas: Combustível

O Fuel, composto pela máquina virtual FuelVM, a linguagem de desenvolvimento de contratos Sway inspirada em Rust e sua cadeia de ferramentas associada, é um “sistema operacional de rollup Ethereum” modular personalizado. O projeto Fuel foi estabelecido em 2019 e, em dezembro de 2020, a Fuel Labs lançou a primeira camada de execução de rollup otimista no Ethereum, Fuel v1. Após mais de três anos de desenvolvimento, o projeto está finalmente pronto para lançar sua mainnet no terceiro trimestre de 2024.

A Fuel completou rondas de financiamento de $1.5 milhões e $80 milhões em 2021 e 2022, respetivamente. A equipa principal é composta por mais de 60 engenheiros, com o fundador John Adler a ser também co-fundador da solução de disponibilidade de dados Celestia Labs e um dos primeiros defensores da abordagem optimistic rollup. Em termos de operações, o projeto tem 270,000 membros no Twitter e 390,000 no Discord.

A execução de transações uma a uma na blockchain incorre em taxas de gás e compete por espaço de bloco valioso, o que é lento. Naturalmente, surgem várias soluções de escalonamento, como o processamento em lote de transações que são então agrupadas e liquidadas em conjunto na cadeia para acelerar a execução.

Um rollup é uma solução de dimensionamento que opera fora de L1, executando transações em lotes off-chain e depois enviando dados de transação ou provas de execução para L1. Isso garante segurança por meio da camada DA e liquida transações. Existem dois principais tipos de rollups: otimistas e de conhecimento zero (ZK).

Os rollups otimistas assumem que as transações são válidas e produzem uma prova de fraude para reverter transações maliciosas ou incorretas no L1 quando detectadas. Os rollups ZK geram provas de validade da transação através de cálculos complexos sem expor detalhes da transação e publicam-nas no L1 para demonstrar que o rollup executou as transações corretamente. Assim, os rollups são uma tecnologia de camada de execução de blockchain.

Embora os rollups acelerem a execução de transações, a maioria das implementações existentes são projetadas para blockchains monolíticas. Os desenvolvedores têm que fazer vários compromissos tecnicamente, o que limita o desempenho total dos rollups. Com a nova tendência em direção às blockchains modulares, não houve nenhuma solução de rollup adequada na indústria. O Fuel foi criado para preencher essa lacuna.

O Fuel utiliza o modelo de dados UTXO, que tem a vantagem de que as suas saídas de transação têm apenas dois estados: ou são gastas, ficando permanentemente registadas no histórico de transações do bloco, ou não gastas, disponíveis para transações futuras. Isso minimiza os dados de estado armazenados em cada nó na cadeia. Com base nisso, o Fuel verifica as informações da conta acedidas por cada transação antes da execução, identificando dependências e agendando transações sem dependências para serem executadas em paralelo, melhorando a capacidade de processamento de transações.

5.3 Integração de Cadeias L1 com Soluções L2: Neno, Eclipse e Lumio

As soluções L2 partilham uma característica comum: combinam as capacidades de dois tipos de máquinas virtuais para melhorar a velocidade de execução de transações. Especificamente, isto envolve usar L1s paralelas para executar transações mantendo a compatibilidade com outras cadeias (suporte para máquina virtual dupla). No entanto, os mecanismos de compatibilidade adotados por diferentes projetos variam. Neste sentido, Neon, Eclipse e Lumio são particularmente representativos.

Neon afirma ser o primeiro projeto EVM paralelo no ecossistema Solana, permitindo que os desenvolvedores migrem projetos do ecossistema Ethereum para o ecossistema Solana de forma transparente. Eclipse é outro protocolo no ecossistema Solana compatível com EVM, construído com uma arquitetura modular. Entre esses três projetos, apenas o Neon emitiu seu próprio token, alcançando um valor de mercado em circulação de mais de 78 milhões.

Os outros dois projetos ainda estão em estágios relativamente iniciais. Lumio combina Aptos e Ethereum para criar um protocolo otimista rollup L2, executando eficientemente aplicações Ethereum à velocidade da Move VM.

Em termos de financiamento, a Neon completou a angariação de fundos de 40 milhões de dólares em novembro de 2021 e 5 milhões de dólares em junho de 2023, totalizando 45 milhões de dólares. A Eclipse completou a angariação de fundos de 6 milhões de dólares em agosto de 2022, 9 milhões de dólares em setembro de 2022 e 50 milhões de dólares em março de 2024, totalizando 65 milhões de dólares. A Lumio ainda não levantou fundos.

Nenhum dos três projetos conseguiu ainda formar um ecossistema de aplicação em grande escala, mas têm dezenas a centenas de milhares de seguidores ou membros em grandes plataformas de redes sociais, o que indica uma atividade comunitária significativa.

De uma perspectiva de mecanismo, o Neon é um emulador EVM na rede Solana, executado como um contrato inteligente. Os desenvolvedores podem usar linguagens como Solidity e Vyper para escrever aplicações dApp, e podem usar ferramentas Ethereum e APIs RPC compatíveis com Ethereum, contas, assinaturas e padrões de token, como MetaMask, Hardhat e Remix. Enquanto isso, eles desfrutam dos benefícios de taxas baixas, alta velocidade de execução de transações e capacidades de processamento paralelo trazidas pela Solana.

As transações Ethereum enviadas a partir da interface da aplicação Ethereum são convertidas por um proxy em transações Solana, depois executadas no emulador, modificando o estado da cadeia. É como os emuladores de jogos que frequentemente usamos em PCs, que nos permitem jogar jogos exclusivos de consolas como a Switch e a PlayStation em computadores de secretária. A Neon permite aos programadores Ethereum executar aplicações Ethereum na rede Solana.

Eclipse adota uma abordagem de implementação diferente: executando transações através de SVM e liquidando transações através de EVM. Eclipse utiliza uma arquitetura de blockchain modular, onde apenas lida com a execução de transações e terceiriza outras responsabilidades, formando uma solução unificada através de combinações modulares.

Por exemplo, usa Celestia para gerir a disponibilidade de dados e Ethereum para executar e liquidar transações. Eclipse garante velocidade de execução através de SVM e segurança através da validação e liquidação do Ethereum.

Lumio adota uma filosofia de design independente das camadas de execução e liquidação, suportando várias máquinas virtuais e compatível com várias redes L1/L2: Ethereum, Aptos, Optimism, Avalanche, zkSync e outras. Executa transações através do Move VM e liquida-as através do EVM, conectando assim os ecossistemas Ethereum e Aptos.

No entanto, as ambições da Lumio não se ficam por aí. A sua visão é fornecer chamadas entre máquinas virtuais para alcançar conectividade de liquidez multi-blockchain à maior velocidade e às taxas mais baixas.

Os acima são os principais projetos atualmente relacionados à narrativa EVM paralela, conforme mostrado no diagrama seguinte.

6. Conclusão e Perspectivas

As pessoas frequentemente comparam o Bitcoin a um “registo distribuído” e o Ethereum a uma “máquina de estados distribuída”. Se considerarmos todos os nós a operar numa rede blockchain como um único computador, então as blockchains paralelas estudam fundamentalmente como maximizar a utilização dos recursos de processamento deste “computador” para alcançar as velocidades de execução mais rápidas.

Esta é uma evolução inevitável na história da tecnologia da computação, semelhante ao desenvolvimento de processadores de núcleo único para processadores multi-core, e sistemas operacionais evoluindo de single-user single-thread para multi-user multi-threading. Isso tem implicações significativas para o desenvolvimento contínuo da indústria.

Os princípios técnicos do EVM paralelo podem ser divididos em dois componentes: a máquina virtual e o mecanismo de execução paralela. No contexto da blockchain, a máquina virtual integra um conjunto de instruções para a execução distribuída de contratos e execução de dApps. O mecanismo de execução paralela foca principalmente em maximizar a velocidade de execução de transações, garantindo a precisão dos resultados das transações.

Por um lado, as EVMs paralelas partilham princípios técnicos comuns. Em primeiro lugar, o modelo de paralelização otimista é um consenso para blockchains públicas de L1. No entanto, isso não significa que o modelo de bloqueio de memória seja inútil. A superioridade tecnológica não existe; é antes o nível de habilidade dos desenvolvedores que varia.

Em segundo lugar, projetos como Fuel acreditam firmemente que mecanismos de escala fora da cadeia só podem atingir seu desempenho máximo após a modularização. Finalmente, numerosos projetos de L2 buscam aumentar a capacidade de transação integrando-se com blockchains públicas paralelas de L1, alcançando assim capacidades de escala entre ecossistemas.

Por outro lado, os blockchains paralelos têm suas próprias conquistas técnicas. Mesmo ao adotar o mesmo modelo de execução paralela, diferentes equipes implementaram padrões de design arquitetônico variados, modelos de dados ou mecanismos de pré-processamento. A exploração tecnológica é infinita e diferentes projetos desenvolvem tecnologias distintas com base em visões diferentes para levar a prática a níveis mais altos.

Olhando para o futuro, mais projetos L1 e L2 irão juntar-se à competição em paralelo EVMs. A pista L1 verá uma competição abrangente entre EVMs paralelos e campos não-EVM em recursos de processador, recursos de armazenamento, recursos de rede, recursos de sistema de arquivos e recursos de dispositivo. Esta competição também dará origem a novas narrativas relacionadas com a melhoria de desempenho. Entretanto, a pista L2 evoluirá para simuladores de máquinas virtuais blockchain ou blockchains modulares.

No futuro, as otimizações de infraestrutura trarão velocidades mais rápidas, custos mais baixos e maior eficiência. Os empreendedores da Web3 podem inovar ousadamente modelos de negócios para criar melhores experiências de produtos descentralizados em todo o mundo, enriquecendo ainda mais o ecossistema da indústria. Para os investidores da Web3, focar apenas na tecnologia é insuficiente.

Ao escolher alvos de investimento, os investidores devem considerar narrativas, capitalização de mercado e liquidez, selecionando projetos com “boas narrativas”, “baixa capitalização de mercado” e “alta liquidez.” Em seguida, eles devem aprofundar-se no negócio, antecedentes da equipe, modelo econômico, marketing e projetos ecológicos, descobrindo assim projetos potenciais e encontrando vias de investimento adequadas.

As EVMs paralelos ainda estão em estágios iniciais de desenvolvimento, com projetos como Neon, Monad, Canto, Eclipse, Fuel e Lumio na fase em que seu valor ainda não foi totalmente realizado. Especialmente, Monad, Canto e Fuel.

Do estilo de marketing da Monad, não só é notável por si só, mas os projetos de meme dentro do seu ecossistema também valem a pena serem observados, o que pode levar a histórias de enriquecimento rápido impulsionadas pela hype. Canto atende às condições de uma “boa narrativa” e uma “baixa avaliação de mercado”, mas se é um bom alvo de investimento ainda requer uma análise detalhada dos seus vários indicadores. Fuel representa uma direção popular no desenvolvimento de blockchains modulares e também pode dar origem a novas oportunidades de investimento, todas as quais são direções que merecem a nossa atenção.

declaração:

1. Este artigo é reproduzido de Academia Gryphsis), o título original é “Interpretação de Dez Mil Palavras do EVM Paralelo: Como Romper o Gargalo de Desempenho da Blockchain?”, os direitos autorais pertencem ao autor original [@leesper6], se tiver alguma objeção à reimpressão, entre em contato Equipe de Aprendizagem Gate, a equipa tratará disso o mais breve possível de acordo com os procedimentos relevantes.

2. Aviso Legal: As opiniões expressas neste artigo representam apenas as opiniões pessoais do autor e não constituem qualquer conselho de investimento.

3. Outras versões do artigo são traduzidas pela equipe Gate Learn e não são mencionadas emGate.ioO artigo traduzido não pode ser reproduzido, distribuído ou plagiado.