Imagine isso: você está em uma cozinha movimentada onde os chefs devem esperar um terminar de picar legumes antes que o próximo possa começar a assar batatas. Parece frustrantemente lento e ineficiente, certo? É assim que a execução síncrona é na computação e blockchain: uma tarefa deve ser concluída antes que a próxima possa ser iniciada. Agora, imagine uma cozinha bem coordenada onde cada chef trabalha em diferentes partes de vários pratos simultaneamente, preparando ingredientes, cozinhando e montando tudo de uma vez. Isso é execução assíncrona - as tarefas são executadas concorrentemente, criando um fluxo de trabalho mais eficiente e rápido.

No cruzamento da evolução blockchain, a componibilidade síncrona se tornou uma palavra da moda porque parece oferecer uma solução para unir as camadas 2 rollup fragmentadas na rede Ethereum. Essa abordagem aborda a UX e DevEx desastrosas, onde até mesmo uma transferência simples entre as camadas 2 pode custar um dólar e levar até 7 dias.Envolvimento de Vitaliknestes debates destaca que a sincronia universal não é necessariamente um requisito para resolver essas questões. Concordamos que a execução de tradução eficaz não precisa envolver sincronia e há custos reais para construir e manter 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. Decomponível Assíncrono

Na busca de desempenho em escala 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 multi-chain ou Layer-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 total 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 amplamente utilizadas, alcançando desempenho e escalabilidade ótimos.

Antes de nos aprofundarmos nos detalhes minuciosos, vamos primeiro esclarecer a que se referem alguns termos-chave neste artigo:

Tx1 = Transação 1

Tx2 = Transação 2

Assumimos que,

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

A execução de Tx2 precisa mudar o estado A, estado D, estado E

Métodos de paralelização de ponta para EVMs¹, como os implementados por Sei, Aptos e Sui, tentam executar todos os passos em cada transação de forma síncrona. Imagine dar um zoom em uma única cena de transação, nesses 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 de contrato). Como resultado, se algum 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 a capacidade total e escalabilidade do sistema. Essa situação piora significativamente quando a atividade on-chain de repente dispara.

PREDA adota uma abordagem nova e diferente dos sistemas mencionados acima. Ele adota um modelo de execução de contrato inteligente que implementa decomponibilidade 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 do PREDA resulta em maior eficiência e escalabilidade teoricamente infinita. Vamos nos aprofundar mais em como o 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, por meio deputação e escalabilidade. Note que nossa avaliação emprega transações reais de transferência de tokens ETH históricos, 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 acima do desempenho em casos reais, uma vez que transações do mundo real envolvem endereços que estão relacionados de uma forma ou de outra, 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. O PREDA demonstra uma taxa de transações por segundo (TPS) de 3,3 a 28,2 vezes maior do que o 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 na aceleração relativa em relação à linha de base do uso de um único EVM, para excluir o impacto de diferentes implementações do sistema.

Figura 1. Os números de rendimento absoluto em TPS de contratos inteligentes de transferência de token 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 linhas de base

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¹.

• A Paralelização Otimista, incluindo Aptos, Sei (V2) e Monad, ignora as dependências de estado entre transações, executa e valida transações em paralelo e reverte 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 cada transação antes da execução, analisa suas dependências de estado e executa simultaneamente apenas as 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_48518/crystality-o-modelo-evm-paralelo-que-implementa-a-arquitetura-de-nada-em-comum-para-quebrar-dependências-de-estado-e-garantir-que-diferentes-instâncias-de-EVM-nunca-acessarão-a-mesma-parte-do-estado-do-contrato-evitando-conflitos-de-escrita-completamente.

No seu núcleo, PREDA introduz Scopes de Contrato Programáveis para decompor o estado do contrato em partes não sobrepostas e paralelizáveis com granularidade fina, e Relevo Funcional Assíncrono para descrever a mudança 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 os estados do endereço do usuário de maneira determinística, como usando um método de mapeamento do endereço do usuário para o 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 do contrato desejados emitindo uma transação de relé. 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 porque 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 sem compartilhamento para sistemas de blockchain, diferindo da arquitetura sequencial e com compartilhamento em Solidity e Move, que podem incorrer em sobrecarga significativa de controle de concorrência.

4. O Idioma

Implementamos o modelo de programação PREDA como uma linguagem semelhante à Algo, semelhante a C/C++ e Javascript. A seguir, uma função simplificada de transferência de token em Solidity e na linguagem PREDA.

O código Solidity na Figura (a) apresenta um estado de contrato (saldos) que representa saldos de 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 (receptor).

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

A implementação PREDA possui três partes. Na parte (1), a palavra-chave @addressdefine os saldos dos usuários, fornecendo uma descrição de estado granular e separável. A variável de escopo de endereço saldo tem uma instância única 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 não sobrepostos. A função de transferência é definida no mesmo escopo de endereço na parte (2), invocada fornecendo o endereço do pagador como o escopo alvo ao inicializar uma transação de transferência por um usuário. Na parte (3), para prosseguir com o depósito para o beneficiário após uma retirada bem-sucedida, um relé é iniciado com o endereço do beneficiário como escopo alvo, adicionando fundos ao saldo do beneficiário e executado por um EVM que hospeda a instância de saldo do endereço do beneficiário.

O fluxo de execução de uma transação de transferência de token em 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. Transações iniciadas pelo usuário: Como os estados particionados por endereço não se sobrepõem, as transações iniciadas pelo usuário podem ser executadas em paralelo 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 usuário podem ser paralelizadas em EVMs.
2. Com transações de relé: Em um cenário em que Bob transfere tokens para Alice e Carol, a transação de relé para o depósito para Alice (da transferência de Bob para Alice) pode ser executada simultaneamente com a transação iniciada pelo usuário para a retirada de Bob (na transferência de Bob para Carol) e o depósito para Carol. Apenas com a decomposição do modelo PREDA pode-se expor a parallelização inerente em um contrato inteligente para o sistema blockchain subjacente, permitindo que transações iniciadas pelo usuário e de relé sejam processadas de maneira pipelined, facilitando a execução paralela.

Próximo e Além

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

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

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

Aviso legal:

1. Este artigo é uma repostagem de [Médio]. The copyright belongs to the original author, [PREDA Parallel VMs]. If you have any objections regarding this repost, please contact thegate Learn Team. A equipe tratará prontamente de suas preocupações de acordo com os procedimentos relevantes.
2. Isenção de Responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem conselho de investimento.
3. A equipe Learn da gate traduziu o artigo para outros idiomas. Copiar, distribuir ou plagiar os artigos traduzidos é proibido, a menos que mencionado.