Imagine isto: estás numa cozinha ocupada onde os chefs têm de esperar que um termine de cortar legumes antes que o próximo possa começar a assar batatas. Parece frustrantemente lento e ineficiente, certo? É isso que a execução síncrona é na computação e na blockchain: uma tarefa deve ser finalizada antes que a próxima possa ser iniciada. Agora, imagina uma cozinha bem coordenada onde cada chef trabalha em diferentes partes de vários pratos simultaneamente, preparando ingredientes, cozinhando e empratando tudo ao mesmo tempo. Isso é a execução assíncrona - as tarefas são executadas em simultâneo, criando um fluxo de trabalho mais eficiente e rápido.

Na encruzilhada da evolução da blockchain, a composabilidade síncrona tornou-se uma palavra da moda porque parece oferecer uma solução para unir a camada rollup 2s fragmentada na rede Ethereum. Esta abordagem aborda a UX e DevEx desastrosas, onde mesmo uma transferência simples entre camadas 2s pode custar um dólar e levar até 7 dias.Envolvimento de Vitaliknestes debates destaca que a sincronicidade universal não é necessariamente um requisito para resolver essas questões. Concordamos que a execução da tradução eficaz não precisa envolver sincronicidade, e há custos reais para construir e manter uma infraestrutura síncrona. Acreditamos que não é uma escolha binária entre tudo ser síncrono ou assíncrono. Ambos podem coexistir de forma ad hoc, com uma provável mudança para o último.

1. Assíncrono Decomponível

Na busca de um desempenho escalável na tecnologia blockchain, a execução paralela de contratos inteligentes individuais tem recebido atenção significativa. Convencionalmente, o desempenho de cada contrato inteligente tem sido limitado pelas capacidades de uma única máquina virtual (EVM), mesmo com o surgimento de sistemas de várias cadeias ou camada 2. Máquinas virtuais paralelas oferecem uma solução promissora, permitindo que transações de um único contrato inteligente sejam executadas simultaneamente, aproveitando assim mais núcleos de CPU para melhor desempenho.

A Arquitetura Distribuída de Execução de Relé Paralelo (PREDA) é um modelo de programação distribuído, funcional, orientado a escopo e de alto nível projetado para contratos inteligentes gerais inerentemente paralelizados em sistemas de blockchain multi-EVM distribuídos. Do ponto de vista do sistema, o PREDA torna os EVMs paralelos decomponíveis e assíncronos, permitindo a plena paralelização de uma função de contrato e maximizando a concorrência de um conjunto de transações. Isso garante que todas as instâncias de EVMs possam ser utilizadas ao máximo, alcançando desempenho e escalabilidade ideais.

Antes de entrar nos detalhes minuciosos, vamos primeiro esclarecer a que se referem vários termos-chave neste artigo:

Tx1= Transação 1

Tx2= Transação 2

Partimos do pressuposto de que,

A execução de Tx1 precisa alterar o estado A, estado B, estado C

A execução do Tx2 precisa alterar o estado A, estado D, estado E

Os métodos de paralelização de última geração para EVMs¹, como os implementados por Sei, Aptos e Sui, tentam executar todos os passos em cada transação de forma síncrona. Imagine aproximar-se de uma única cena de transação, nestes sistemas uma transação é executada dentro de uma altura de bloco, independentemente da natureza das dependências de dados dispersos (ou seja, acessando diferentes partes dos estados do contrato). Como resultado, se qualquer passo dos estados de contrato acessados for compartilhado ou atualizado entre duas transações, eles são identificados como conflitos de leitura-escrita ou escrita-escrita e não podem ser executados em paralelo, prejudicando o throughput e escalabilidade geral do sistema. Esta situação piora significativamente quando a atividade on-chain aumenta repentinamente.

PREDA adota uma abordagem nova e diferente dos sistemas mencionados acima. Ele adota um modelo de execução de contrato inteligente que implementa a decomposição assíncrona, onde as etapas de uma transação são decompostas de acordo com suas dependências de acesso a dados, permitindo que as etapas sejam executadas de forma assíncrona. O modelo de execução PREDA resulta em maior eficiência e escalabilidade teoricamente infinita. Vamos aprofundar como PREDA alcança isso e demonstrar resultados experimentais para apoiar essa afirmação.

2. Avaliação de Desempenho

As transações históricas de transferência de tokens ETH são reproduzidas para avaliar Sei (V2), Aptos, Sui e PREDA, em termos de throughput e escalabilidade. Note que a nossa avaliação utiliza transações reais de transferência de tokens ETH em vez de criar um conjunto de transações de transferência entre pares aleatórios de endereços. Transações aleatórias produzirão um resultado experimental excessivamente superior em relação ao desempenho em casos do mundo real, uma vez que as transações do mundo real envolvem endereços que estão relacionados de alguma forma, o que introduz uma grande quantidade de dependências de dados.

As configurações experimentais são as seguintes:

A comparação na Figura 1 destaca a necessidade de adotar o modelo de programação PREDA para obter melhorias significativas na taxa de transferência. PREDA demonstra uma taxa de TPS 3,3 a 28,2 vezes maior do que Aptos para transações de transferência históricas reais na rede Ethereum.

Uma vez que esses sistemas são implementados em diferentes linguagens (incluindo Go, Rust e C++) e diferentes máquinas virtuais, avaliamos a escalabilidade de diferentes sistemas com base no aumento relativo em relação à linha de base de usar um único EVM, para excluir o impacto de diferentes implementações do sistema.

Figura 1. Os números absolutos de rendimento em TPS de contratos inteligentes de transferência de tokens equivalentes executados em Sei, Aptos, Sui e PREDA

Figura 2. Acelerações relativas para Aptos, Sui, Sei e PREDA em relação às suas próprias bases

3. O Modelo de Programação

Para facilitar a compreensão do PREDA para qualquer pessoa familiarizada com o EVM paralelo, existem dois tipos típicos de mecanismos de paralelização nos sistemas de blockchain EVM paralelos de hoje¹.

• Parallelização otimista, incluindo Aptos, Sei (V2) e Monad, ignoram dependências de estado entre transações, executam e validam transações simultaneamente e revertam uma transação para reexecução em caso de conflito.
• Paralelização pessimista, incluindo Solana (Sealevel), Sui e Sei (V1), verifica as dependências de estado de pré-verificação para cada transação antes da execução, analisa suas dependências de estado e executa simultaneamente apenas aquelas transações sem conflito.

Ambos os métodos seguem a Arquitetura de Compartilhamento Total e tratam uma transação como um todo no controle de concorrência; todos os passos (por exemplo, acessar diferentes estados de contrato) não são decomponíveis e devem ser executados de forma síncrona. O modelo PREDA propõe@devteam_48518Arquitetura de Shared-nothing para quebrar dependências de estado e garantir que diferentes instâncias EVM nunca acessem a mesma parte do estado do contrato, evitando conflitos de escrita completamente.

No seu cerne, o PREDA introduz Escopos de Contrato Programáveis para decompor o estado do contrato em partes não sobrepostas e paralelizáveis com granularidade fina, e o Relay Funcional Assíncrono para descrever a troca de fluxo de execução entre diferentes EVMs.

Para explicar melhor o que esses conceitos significam, no PREDA, uma função de contrato é decomposta em várias etapas ordenadas, cada uma dependendo de uma única parte paralelizável do estado sem conflitos. Uma transação iniciada pelo usuário é primeiro direcionada a um EVM que mantém estados do endereço do usuário de maneira determinística, como usando um método de mapeamento de endereço do usuário para EVM. Durante a execução da transação, o fluxo de execução pode alternar de um EVM para outro que mantém os estados de contrato desejados emitindo uma transação de retransmissão. Dessa forma, o PREDA mantém os dados estacionários enquanto move o fluxo de execução ao redor dos EVMs de acordo com as dependências de dados.

Em cada EVM, as transações iniciadas pelo usuário e de relé são ordenadas e executadas sequencialmente, enquanto as transações em diferentes EVMs são executadas simultaneamente, pois não há dependências de dados entre as EVMs. Esse mecanismo evita a reexecução relacionada a conflitos em métodos baseados em paralelização otimista e a necessidade de análise de dependência de estado em tempo de execução e sobrecarga de bloqueio/desbloqueio em abordagens baseadas em paralelização pessimista. Portanto, o PREDA fornece uma arquitetura paralela e compartilhada para os sistemas de blockchain, diferindo da arquitetura sequencial e compartilhada em ambos Solidity e Move, que podem incorrer em sobrecarga significativa de controle de concorrência.

4. A Linguagem

Implementámos o modelo de programação PREDA como uma linguagem semelhante à Algo, semelhante a C/C++ e Javascript. Segue-se uma função simplificada de transferência de tokens, tanto em Solidity como na linguagem PREDA.

O código Solidity na Figura (a) apresenta um estado do contrato (saldos) que representa os saldos dos endereços e uma função de transferência para transferir uma quantidade especificada de tokens do remetente da transação (msg.sender) para um destinatário (beneficiário).

Na implementação PREDA mostrada na Figura (b), a palavra-chave @endereçodefine escopos de contrato programáveis, onde estados de contrato pertencentes a uma variável de contrato (saldo) são particionados por endereço e espalhados e gerenciados por EVMs. A palavra-chave relay identifica um relé funcional assíncrono.

Existem três partes na implementação do PREDA. Na parte (1), a palavra-chave @endereço define os saldos dos usuários, fornecendo uma descrição de estado refinada e separável. O saldo da variável de escopo de endereço tem uma instância exclusiva para cada endereço de usuário. As instâncias de diferentes endereços de usuário são acessadas e mantidas por diferentes EVMs sem sobreposição. A função de transferência é definida no mesmo âmbito de endereço na parte (2), invocada fornecendo o endereço do ordenante como âmbito de destino ao inicializar uma transação de transferência por um utilizador. Na parte (3), para prosseguir com o depósito ao beneficiário após um levantamento bem-sucedido, é iniciado um retransmissão com o endereço do beneficiário como âmbito de destino, adicionando fundos ao saldo do beneficiário e executado por um EVM que hospeda a instância do saldo do endereço do beneficiário.

O fluxo de execução de uma transação de transferência de token na PREDA

A figura acima mostra o fluxo de execução de uma transação de transferência de token no sistema EVM paralelo da PREDA. Bob inicia uma transação para chamar a função de transferência, que será direcionada para o EVM que possui o saldo de Bob e a retirada é executada lá. Depois disso, uma transação de relé é emitida e direcionada para o EVM que possui o saldo de Alice e o depósito é executado. A paralelização ocorre de duas maneiras:

1. Entre transações iniciadas pelo utilizador: Uma vez que os estados particionados por endereço não se sobrepõem, as transações iniciadas pelo utilizador podem ser executadas em simultâneo sem conflitos. Por exemplo, no contrato de transferência de tokens que atualiza o estado do pagador por endereço, diferentes transações iniciadas pelo utilizador podem ser paralelizadas através de EVMs.
2. Com transações de retransmissão: Num cenário em que Bob transfere tokens para Alice e Carol, a transação de retransmissão para o depósito para Alice (da transferência de Bob para Alice) pode ser executada em simultâneo com a transação iniciada pelo utilizador para a retirada de Bob (na transferência de Bob para Carol) e o depósito para Carol. Apenas com a decomponibilidade do modelo PREDA é que a paralelização inerente a um contrato inteligente pode ser exposta ao sistema blockchain subjacente, permitindo que as transações iniciadas pelo utilizador e de retransmissão sejam processadas de forma encadeada, facilitando a execução paralela.

Seguinte e Além

PREDA marca um grande avanço no desempenho da blockchain e, mais importante ainda, na escalabilidade. Ao implementar a decomponibilidade assíncrona, permite o processamento eficiente de transações sem os gargalos dos modelos convencionais de paralelização síncrona. Esta abordagem decompõe transações em micro-transações de acordo com as dependências de dados, permitindo mudanças de estado simultâneas e evitando conflitos de escrita completamente.

A generalidade do PREDA estende-se para além do uso@addresspara particionar estados de contrato por endereço. Isso permite tipos de partição personalizados com palavras-chave como@type, onde o tipo pode ser qualquer nome de tipo elementar Solidity, como @uint. Além disso, PREDA suporta estados de contrato não particionados com @global, garantindo que cada EVM mantenha valores consistentes para tais estados. Esta flexibilidade na partição de estados melhora a adaptabilidade e eficácia do modelo em diversos contratos inteligentes.

Nossos experimentos demonstram que o PREDA supera significativamente outros métodos de paralelização, alcançando maior rendimento e escalabilidade. Os próximos artigos da equipe PREDA irão aprofundar ainda mais nossas descobertas, oferecendo comparações mais abrangentes com vários tipos de contratos inteligentes e análises detalhadas do modelo de programação e da linguagem PREDA. Fiquem atentos a essas explorações detalhadas.

Aviso Legal:

1. Este artigo é uma republicação de [Médio]. The copyright belongs to the original author, [PREDA Parallel VMs]. If you have any objections regarding this repost, please contact thegate Aprender EquipeA equipa tratará das suas preocupações prontamente, de acordo com os procedimentos relevantes.
2. Aviso de Responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem aconselhamento de investimento.
3. A equipe do Learn gate traduziu o artigo para outros idiomas. A cópia, distribuição ou plágio dos artigos traduzidos é proibida, a menos que seja mencionado.