Encaminhado o Título Original: Designer Blockspace: O Futuro dos Ambientes de Execução

Nos nove anos desde o lançamento do Ethereum, a primeira blockchain descentralizada e programável, as criptomoedas enfrentaram múltiplos obstáculos na busca por escalar aplicações descentralizadas para bilhões de usuários. E, a fim de desenvolver soluções de escalabilidade para lidar com isso, a indústria das criptomoedas tem continuamente financiado e desenvolvido tipos completamente novos de blockchains para resolver o "problema de desempenho".

No entanto, o “problema de desempenho” foi mal definido e quantificado. Memes sintéticos como “transações por segundo” têm embalado convenientemente o que são comparações entre laranjas e maçãs entre transações que não exigem um trabalho computacional equivalente. A falta de nuances nessas métricas também encobre nossa capacidade de avaliar os impactos independentes dos componentes de uma blockchain no desempenho, distraindo-nos de uma abordagem fundamentada para identificar os conjuntos de otimizações que podemos fazer para resolver problemas altamente interdependentes.

Apesar desta neblina, temos visto melhorias credíveis e sustentadas na escalabilidade da blockchain ao longo dos últimos anos. À medida que a Ethereum avança no seu roadmap centrado em rollup, uma nova onda de rollups, coprocessadores,disponibilidade de dados(DA) camadas e L1s concorrentes estão a surgir - cada uma com escolhas de design únicas para fornecer aos programadores ambientes mais eficientes para construir dapps escaláveis e fáceis de usar.

Hoje, a introdução do EIP4844 e camadas DA alternativas aliviaram o gargalo crítico de DA. Apesar deste marco crítico, as evidências sugerem que outros gargalos importantes devem ser resolvidos. No mês passado, Basecoletado1,57 milhões de dólares em taxas de transação num único diapagando apenas $5K em custos de disponibilidade de dados para o Ethereum. Isso sugere que o trabalho computacional necessário para validar e processar as atualizações de estado permanece um gargalo crítico e uma oportunidade de melhoria.

Este artigo avaliará as escolhas de design feitas pelos ambientes de execução integrados e modulares em seu caminho para resolver problemas de desempenho mais altos e expandir o escopo de aplicações que podem viver on-chain.

Desafios de Hoje

O desempenho de uma camada de execução pode ser avaliado de acordo com o trabalho computacional que os nós executivos alcançam em relação ao tempo de bloco de suas cadeias, ou "gás calculado por segundo".

Com isto em mente, podemos reduzir os gargalos da camada de execução a dois fatores interligados: acesso ineficiente ao estado e computação ineficiente.

Acesso ineficiente ao estado refere-se ao custo de recuperação e atualização do estado da blockchain, que pode retardar o processamento de transações. Por outro lado, a computação ineficiente é uma função do custo incorrido pelos algoritmos na execução de operações e transições de estado, que pode incluir desde transferências simples até contratos inteligentes complexos e verificações de assinatura.

Esses gargalos são mutuamente reforçadores - atrasos no acesso ao estado podem prolongar o tempo de computação, enquanto práticas computacionais ineficientes podem sobrecarregar a gestão do estado. Além disso, melhorias propostas para lidar com esses problemas frequentemente exigem melhorias sistêmicas, como fragmentação ou adoção de arquiteturas sem estado, que melhoram o acesso ao estado e a eficiência de computação para melhorar o desempenho da execução.

Estrangulamento #1: Acesso ineficiente ao estado

O custo e a velocidade necessários para aceder ao estado de uma blockchain são gargalos críticos para ambientes de execução de alto desempenho e podem ser reduzidos à questão do inchaço do estado.

Nas blockchains, o estado do mundo é gerido e atualizado através de estruturas de dados específicas chamadas árvores. As árvores são essenciais para as blockchains, proporcionando uma forma segura e eficiente de dar às partes externas ao nó executor garantias em torno do estado correto da blockchain. Cada atualização dentro de um trie gera um novo hash raiz, que os clientes leves podem referenciar para verificar transações e saldos de conta sem manter toda a cadeia.

Ethereum depende especificamente de uma estrutura de dados conhecida como a árvore de Patricia Merkle (MPT), que é composta@chiqing/merkle-patricia-trie-explained-ae3ac6a7e123">four sub-tries.

À medida que o Ethereum adiciona mais contratos inteligentes e tokens ao seu estado, a sua árvore de estados torna-se maior e mais complexa. À medida que o estado cresce, requer mais espaço de armazenamento, mais recursos computacionais para processar e mais largura de banda para transmitir. Ao mesmo tempo, as restrições de hardware do nó permanecem aproximadamente as mesmas.

Este crescimento do estado impacta diretamente o desempenho do Ethereum porque o estado é armazenado em disco e as operações de disco incorrem em um alto custo. Enquanto acessar dados de um registro da CPU pode levar 0,1 nanossegundos, pode levar entre 10 e 100 microssegundos(100x–1000x mais lento)para aceder a dados de um disco, traduzindo aproximadamente para 200.000 instruções de CPU que poderiam ter sido executadas nesse tempo. Isso equivale a uma estimativa conservadora de 36 transferências ERC-20 que poderiam ter sido realizadas!

Agravando este problema, as blockchains têm muitos padrões de acesso ineficientes para ler e escrever no estado. Por exemplo, a estrutura não sequencial do trie de Merkle Patricia leva inherentemente a estas operações de entrada/saída (I/O) no disco a ler e a escrever em várias localizações imprevisíveis no disco. A natureza aleatória das inputs das transações e as alterações de estado subsequentes que desencadeiam levam a um padrão de acesso de dados dispersos que abranda significativamente o processo de verificação e atualização de estado e apenas utiliza uma parte de capacidade do dispositivo de hardware.

No geral, os primitivos de gestão de estado para blockchains estão longe de atingir o seu potencial absoluto, e podem ser feitos numerosos avanços para melhorar a eficiência computacional.

Estrangulamento #2: Computação Ineficiente

As camadas de execução também enfrentam o gargalo da computação ineficiente, que se manifesta de várias maneiras.

Por um lado, muitos processam transações sequencialmente, subutilizando processadores modernos multi-core capazes de lidar com múltiplas operações simultaneamente. Essa execução sequencial leva a tempos de inatividade da CPU inevitáveis entre transações, desperdiçando recursos computacionais valiosos.

Além disso, o uso de máquinas virtuais envolve a tradução de operações de contrato inteligente de alto nível em bytecode - um código de nível inferior e independente da plataforma - que é então executado instrução por instrução. Este processo de tradução e execução introduz uma sobrecarga significativa, especialmente para aplicações com tarefas específicas de aplicação complexas e frequentemente repetidas.

Essas ineficiências levam a uma utilização subótima dos recursos computacionais e prejudicam o desempenho das camadas de execução.

Soluções: Acesso Ineficiente ao Estado

Existem algumas maneiras distintas pelas quais as equipas estão a melhorar a velocidade com que o estado pode ser recuperado e atualizado a partir do hardware de um nó em execução, incluindo a simplificação de estruturas de dados complexas e a redução das operações dispendiosas de E/S em disco que levam ao inchaço do estado.

Estado de Não Pertencimento & Computação em Memória

Algumas camadas de execução lidam com o inchaço do estado simplesmente aceitando-o a curto prazo. Elas transferem o armazenamento de dados de estado de sistemas baseados em disco mais lentos para memória de acesso aleatório (RAM) mais rápida. Acesso às informações de estado na RAM reduz significativamente os custos indiretos associados às operações de disco, que são mais lentas e consomem mais recursos.

No entanto, esta abordagem desafia o princípio fundamental da descentralização. Armazenar quantidades cada vez maiores de dados de estado na RAM requer hardware mais avançado e caro, o que poderia limitar a capacidade das pessoas de participar como operadores de nós. Como resultado, à medida que os requisitos de hardware aumentam, menos entidades podem arcar com os custos de executar esses nós.

Para equilibrar o atratividade de computação em memória com a minimização de confiança, tanto os L1s (como Ethereum) quanto os L2s estão a seguir um plano de escalabilidade que depende do desmembramento do papel de um validador em nós executivos separados e centralizados com muitos nós verificadores. Neste modelo, os produtores de blocos altamente performantes com os requisitos de hardware para computar em memória são responsáveis pela geração de blocos, e provas criptográficas (provas de fraude e validade) são utilizadas pelos nós verificadores para responsabilizar os produtores de blocos.

Como resultado, esses sistemas devem permitir que os produtores de blocos maximizem sua velocidade, pois espera-se que possam calcular na memória, eliminando completamente as E/S de disco durante a execução. Como a latência da RAM normalmente é inferior a 100 nanossegundos, a latência de acesso ao estado é reduzida em até 1000 vezes em relação às implementações baseadas em disco.

Em paralelo, as provas de fraude e validade são utilizadas em vez de consenso descentralizado para escalar as propriedades de minimização de confiança do sistema juntamente com sua capacidade de processamento. Como resultado, nós poderosos e centralizados na produção de blocos são contrabalançados por nós verificadores que podem ser executados em hardware muito menos dispendioso. Estes nós desempenham a função crítica de verificar independentemente provas de transições de estado (ou transições de estado inválidas) para manter uma visão precisa do estado sem o ônus de armazenar todo o estado da blockchain.

Para facilitar este processo de forma minimizada em termos de confiança, as camadas de execução devem implementar um grau deapatridia, o mais popular sendo o conceito de "fraqueza da ausência de estado." A fraqueza da ausência de estado é alcançada ao exigir que os produtores de blocos forneçam uma atestação criptográfica conhecida como um testemunhapara um nó de verificação. Esta testemunha encapsula todas as alterações de estado propostas pelo novo bloco, permitindo que os validadores verifiquem essas alterações sem dados históricos adicionais.

Embora este conceito possa ser aplicado utilizando várias estruturas de árvore, as árvores Verkle são frequentemente preferidas às árvores Merkle pela sua eficiência. As árvores Merkle requerem a inclusão de todos os hashes dos nós irmãos ao longo do caminho a partir de um ponto de dados (folha) até à raiz da árvore para provar a integridade dos dados. Esta exigência significa que o tamanho da testemunha (a prova de integridade) aumenta com a altura da árvore, uma vez que cada nível requer hashes adicionais. Consequentemente, verificar a integridade dos dados nas árvores Merkle torna-se intensivo computacionalmente e dispendioso, especialmente para conjuntos de dados grandes. Em contraste, as árvores Verkle simplificam este processo, reduzindo a sobrecarga associada à computação e armazenamento na geração e verificação de novos blocos.

Verkle tree escalando a partir da Ethereum inevitável “Verkle Tree”

As árvores Verkle melhoram a estrutura das tradicionais árvores Merkle ao simplificar as conexões entre as folhas e a raiz, eliminando a necessidade de incluir nós irmãos no processo de verificação. Numa árvore Verkle, verificar uma prova envolve apenas o valor no nó folha, um compromisso com o nó raiz e um compromisso de vetor único baseado em compromissos polinomiais, que substitui os múltiplos compromissos baseados em hash encontrados nas árvores Merkle. Esta mudança permite que as árvores Verkle mantenham uma testemunha de tamanho fixo, que não aumenta com a altura da árvore ou o número de folhas verificadas, melhorando significativamente a eficiência de armazenamento e computação durante a verificação de dados.

Ao longo dos próximos anos, veremos implementações de estado de não pertencer acontecer nos níveis L1 e L2 com configurações variadas. De acordo com o mais recente roteiro do Ethereum, os validadores podem contar com os construtores de blocos para fornecer provas Verkle sobre o estado de certos blocos e verificar essas provas leves em vez de manter o estado do Ethereum diretamente.

No nível L2, equipas como MegaETHestão a aplicar ativamente o conceito de estado de não pertença ao design de rollups otimistas. No seu design, o nó sequenciador gera uma testemunha para cada bloco contendo os valores de estado necessários e hashes intermédios enquanto emite um delta de estado representando as mudanças no estado. Os nós verificadores podem então reexecutar qualquer bloco ao recuperar a testemunha da camada DA ou de uma rede peer-to-peer sem armazenar todo o estado. Em paralelo, os nós completos atualizam o seu estado aplicando os deltas de estado disseminados através da rede, permitindo-lhes manter-se sincronizados sem reexecutar transações ou armazenar todo o histórico do estado.

No entanto, vale também a pena salientar que os benefícios da ausência de estado e a capacidade resultante de computar na memória não são uma solução milagrosa para o desempenho da camada de execução.

TPS em tempo real a partir de "Compreensão do Desempenho da Camada de Execução do Ethereum do MegaETH"

Como co-fundador da MegaETH, Yilong Li, identifica no seguinteapresentação de pesquisana execução Ethereum, existem outras ineficiências nas estruturas de dados e padrões de acesso onchain que permanecem otimizados.

Melhorando as Bases de Dados

As equipas que trabalham nas camadas de execução estão a encontrar formas de melhorar a estrutura destas bases de dados por si só, para eliminar alguns dos gargalos experimentados pela Ethereum e outras blockchains compatíveis com a EVM ao lidar com o acesso ineficiente ao estado, o que tem um efeito dominó na eficiência computacional.

Na verdade, as limitações dos designs de banco de dados existentes encontrados no EVM informaramMonad’s* decisão de ir além da mera otimização da eficiência computacional para alcançar a paralelização. O Monad descobriu que, mesmo após a implementação da execução paralela, eles viram apenas um pequeno aumento de desempenho porque solicitações de leitura e escrita em várias threads para o banco de dados bloqueavam umas às outras. Como resultado, o Monad implementou um banco de dados compatível com E/S assíncrona (AIO), ou acesso paralelo, como parte crítica da solução.

I/O assíncrona

Operações de E/S - como ler de ou escrever em dispositivos de armazenamento - frequentemente criam gargalos, especialmente com discos rígidos mecânicos (HDDs). Estes discos requerem o movimento físico de uma cabeça de leitura/escrita para aceder aos dados, o que pode abrandar significativamente o processamento de dados.

AIO aborda este desafio permitindo que os programas realizem operações de E/S simultaneamente com outros processos. Essencialmente, um programa pode iniciar uma operação de E/S e avançar sem esperar que ela seja concluída. Faz isso registrando uma função de retorno de chamada ou uma promessa que o sistema operacional ou uma biblioteca de E/S cumprirá uma vez que a operação de E/S termine. Esta abordagem assíncrona permite que o programa principal continue executando outras tarefas, melhorando a eficiência geral ao não ficar parado para que as tarefas de E/S sejam concluídas.

A E/S assíncrona pode ser implementada tanto com discos rígidos tradicionais como com unidades de estado sólido (SSDs), embora os benefícios sejam mais evidentes com SSDs. Os discos rígidos podem realizar AIO, mas a sua natureza mecânica significa que são inerentemente mais lentos do que os SSDs, que armazenam dados na memória flash e não têm partes móveis, resultando em tempos de acesso mais rápidos.

Por exemplo, o Monad utiliza um backend de estado personalizado otimizado para armazenamento SSD, que suporta altos níveis de processamento de dados em paralelo e reduz a latência de I/O. Esta configuração é mais eficiente do que os sistemas que dependem exclusivamente de armazenamento em disco tradicional ou aqueles que utilizam bases de dados em memória, que ainda podem enfrentar atrasos devido às frequentes gravações e leituras de dados em meios de armazenamento mais lentos.

Da mesma forma, o Reth emprega um método que separa as operações de banco de dados do núcleo do mecanismo de execução EVM. Esta configuração permite que o bytecode do EVM seja executado sequencialmente em uma única thread para manter a consistência, enquanto as tarefas de E/S do banco de dados são transferidas para processos paralelos. O Reth utiliza o modelo de ator - um padrão de arquitetura de software - para gerir esses processos paralelos de forma eficaz, garantindo que as operações de E/S não interrompam o intérprete EVM.

Frequência de Merklização do Estado

Outro vetor para otimização é a frequência de merklização do estado. O modelo atual da Ethereum de merklizar o estado após cada bloco introduz uma sobrecarga significativa, exigindo escritas frequentes no disco e leituras e travessias contínuas da trie. As árvores de Merkle geralmente funcionam agrupando hashes intermediários em conjuntos de 16 (chamados de nó) e armazenando-os em um banco de dados de loja de chave-valor onde a chave é o hash do nó e o valor é o próprio nó.

Atravessar esta árvore para encontrar e atualizar dados requer um acesso aleatório ao disco para cada camada da árvore a ser percorrida, e atravessar uma árvore de Merkle ingênua exigirá aproximadamente oito consultas sequenciais ao banco de dados por entrada.

A abordagem da Solana de atualizar o compromisso de estado apenas no final de cada época permite a amortização dos custos de escrita ao longo de muitas transações dentro desse período. Se uma entrada de estado for modificada várias vezes dentro da mesma época, cada escrita não requer uma atualização imediata para a raiz de Merkle. Isso reduz a sobrecarga computacional global associada às atualizações de estado durante a época. Consequentemente, o custo associado à leitura do estado permanece constante, ou O(1), porque o estado pode ser lido diretamente sem precisar percorrer um caminho de Merkle cada vez.

Reduzir a frequência de merklização no Ethereum poderia diminuir o overhead das leituras e escritas de estado, melhorando o desempenho. No entanto, os clientes leves precisariam reproduzir as alterações de bloco para rastrear o estado entre épocas ou enviar transações onchain para verificação de estado, e tal alteração não é atualmente compatível com o Ethereum.

Estruturas de Dados Eficientes & Especializadas

Além disso, as estruturas de árvore em camadas dentro dos clientes Ethereum existentes geralmente causam padrões de acesso ao estado ineficientes, contribuindo ainda mais para o inchaço do estado. Embora o estado do Ethereum seja estruturado como um MPT, é então armazenado em bancos de dados de clientes Ethereum como LevelDB,PebbleDB(utilizado pelo go-ethereum), ou MDBX (usado pelo Erigon) que armazenam dados em árvores de Merkle como umB-TreeouLSM-Tree.

Nesta configuração, uma estrutura de dados é enraizada em outra estrutura de dados de um tipo separado, criando uma 'amplificação de leitura' ao navegar em estruturas de árvore internas sobre clientes que operam sob outro sistema baseado em árvore de Merkle. A amplificação de leitura pode ser entendida como o resultado das múltiplas etapas para acessar ou atualizar informações contidas dentro de um estado, o que requer navegar na árvore externa para encontrar o ponto de entrada na MPT antes de executar a operação necessária. Como resultado, o número de acessos ao disco para uma leitura aleatória é multiplicado por um fator log(n).

Para resolver isso, o Monad usa nativamente uma estrutura de dados trie de Patricia em disco e na memória. Do ponto de vista técnico, as tentativas de Patricia são frequentemente superiores a outras estruturas de árvore Merkle devido à sua combinação única de eficiência de espaço, correspondência eficiente de prefixos e travessia mínima de nós. O design da trie colapsa nós com filhos únicos e otimiza pesquisas, inserções e exclusões, reduzindo o número de operações de I/O de disco ou de rede necessárias. Além disso, a habilidade de uma trie de Patricia em lidar com a correspondência de prefixos melhora o desempenho em aplicações que necessitam de pesquisas rápidas de chaves parciais.

Outra restrição específica das estruturas baseadas em árvores é que o acesso ou a atualização de dados requer a travessia de várias camadas, o que leva a inúmeros acessos sequenciais ao disco.Laboratórios Soberanosaborda esta ineficiência ao advogar por uma configuração de árvore de Merkle binária. Esta mudança fundamental para uma estrutura binária reduz drasticamente o número de caminhos potenciais durante a travessia da árvore, reduzindo diretamente os cálculos de hash necessários para atualizações, inserções e provas criptográficas.

Configuração da árvore Merkle binária do “Nearly Optimal State Merklization” da Sovereign Labs

Um exemplo adicional nesta categoria é a equipe Reth configurando Reth parapré-busque nós intermediários da árvore do disco durante a execuçãoao notificar o serviço raiz do estado sobre os slots de armazenamento e contas afetadas.

Expiração de Estado

O vencimento do estado é um mecanismo para gerir e reduzir o tamanho do estado da blockchain, removendo dados que não foram acedidos durante um período de tempo definido. Embora o vencimento seja frequentemente agrupado na categoria de "ausência de estado", é fundamental distinguir estes conceitos no contexto da execução.

A falta de estado melhora a execução aumentando a capacidade de cálculo de um nó em execução na memória, mas as melhorias na execução decorrem dos requisitos de hardware mais robustos em menos nós que executam transações. Por outro lado, a expiração do estado pode ser aplicada a blockchains com poucos e muitos nós em execução.

Existem alguns métodos comumente discutidos para implementar a expiração do estado:

• Expiração por Aluguer: Este método envolve cobrar uma taxa de manutenção, ou "aluguer," para manter as contas ativas no banco de dados do estado. Se o aluguer não for pago, as contas são arquivadas até que uma taxa seja paga para as restaurar.
• Expiração por Tempo: Aqui, as contas são consideradas inativas se não tiverem sido acedidas - o que significa que não houve transações ou interações - durante uma duração especificada.

Ambos os métodos visam manter apenas os dados ativamente usados no estado imediato e acessível, enquanto empurram os dados mais antigos e menos frequentemente acessados para um estado arquivado que não sobrecarrega o sistema principal.

Ao manter um estado menor e mais gerenciável, o vencimento do estado reduz o "inchaço do estado" que pode prejudicar severamente o desempenho da blockchain. Um tamanho de estado menor permite que os nós naveguem e atualizem rapidamente o estado, resultando em uma execução mais rápida, porque os nós gastam menos tempo escaneando e mais tempo processando.

Compartilhamento de execução

Sharding otimiza a utilização de recursos e o desempenho ao distribuir tarefas e dados por um número limitado de nós especializados (não todos os nós executam um estado global).

Numa arquitetura de blockchain shardada, o estado global é dividido em partições distintas chamadas shards. Cada shard mantém a sua parte do estado e é responsável por processar um subconjunto das transações da rede. As transações são atribuídas a shards específicos com base numa função de shardagem determinística, que considera vários fatores como o endereço do remetente, o endereço do destinatário e o hash dos dados da transação. Isto minimiza a necessidade de comunicação entre shards e permite uma execução de transações mais eficiente.

Diagrama de fragmentação de Vitalik em "Os Limites da Escalabilidade da Blockchain"

Isto torna-se evidente quando se explora NEAR Protocol’sdesign de fragmentação, Nightshade, que alcança a ausência de estado para escalar o shard sem comprometer a minimização da confiança.

Em Nightshade, a blockchain é estruturada como uma única cadeia lógica, com cada bloco composto por múltiplos "chunks" e um chunk sendo alocado por shard. Estes chunks contêm as transações e transições de estado específicas de cada shard. Incluir chunks de todos os shards dentro de um único bloco permite uma visão unificada do estado inteiro da blockchain e simplifica o processo de comunicação entre shards.

Da mesma forma que a separação entre construtor adequado (PBS) na Ethereum, o Nightshade delineia explicitamente os papéis dos nós com estado e sem estado. Na NEAR, os validadores com estado são atribuídos a fragmentos específicos e são responsáveis por recolher transações, executá-las e produzir fragmentos específicos de fragmento. Mantêm o estado completo do seu fragmento atribuído e geram testemunhos de estado para os validadores usarem durante o processo de validação.

Entretanto, os validadores sem estado são atribuídos aleatoriamente para validar shards específicos numa base de bloco por bloco. Eles não precisam de manter o estado completo do shard e dependem de testemunhas de estado fornecidas pelos produtores de bloco de outros shards para validar as transições de estado e transações dentro de um pedaço. A atribuição aleatória de validadores para shards ajuda a garantir a segurança e integridade da rede, pois torna mais difícil para atores maliciosos conspirar e controlar um shard específico.

Uma vez que cada nó na rede só precisa lidar com os dados da sua respetiva shard em vez dos dados de toda a rede, o fardo de armazenamento e computacional em cada nó é reduzido.

Soluções: Computação Ineficiente

Execução em Paralelo

Hora de abordar o elefante na sala: paralelização. A execução paralela de transações permite processar várias transações utilizando múltiplos recursos computacionais simultaneamente. Isso permite aumentar o rendimento à medida que os recursos de hardware são escalados durante períodos de alta demanda.

No entanto, é importante considerar que vários componentes de execução podem ser paralelizados, muitos dos quais são implementados por coprocessadores como Lagrange* e clientes alternativos de blockchain como Firedancerpara melhorar significativamente o desempenho das blockchains. Especificamente, a paralelização pode envolver:

• Paralelizando Acesso ao Estado
• Paralelizando Operações Específicas
• Paralelizando Consenso e Execução

Paralelizando Acesso ao Estado

Paralelizando o acesso ao estadotraz dois benefícios críticos:

• Os EVMs paralelos distribuem o processamento de transações por vários núcleos de CPU. Esta configuração permite que várias transações sejam tratadas em simultâneo, em vez de as forçar a aguardar numa fila por um único recurso.
• Quando uma transação aguarda dados do armazenamento - o que pode introduzir uma latência significativa - o sistema não fica inativo. Em vez disso, pode mudar para outra transação que está pronta para ser executada. Isto é possível porque vários núcleos podem lidar com diferentes tarefas de forma independente e simultânea.

O principal desafio na paralelização da execução de transações advém da gestão do acesso concorrente ao estado global partilhado sem violar o Ácidoregras para atualizar sistemas distribuídos. Se uma blockchain tem um monte de transações executando em paralelo, algumas delas entrarão em conflito. Como resultado, as duas metodologias principais para paralelizar o acesso ao estado diferem em quando dedicam recursos para resolver conflitos: o modelo de execução pessimista (ou bloqueio de memória) e o modelo de execução otimista.

Execução Pessimista

O modelo de execução pessimista é uma abordagem de processamento de transações que requer que as transações declarem as variáveis de estado a que terão acesso (leitura ou escrita) durante a execução. Esta informação é incluída nos metadados da transação, permitindo que o tempo de execução analise os padrões de acesso antes da execução.

Ao examinar os padrões de acesso de leitura-escrita, o tempo de execução pode identificar transações com conjuntos de acesso não sobrepostos, permitindo a execução paralela de transações não sobrepostas e somente leitura, e melhorando o rendimento. O tempo de execução cria filas de transações paralelas para cada thread de CPU em um nó validador, garantindo que as transações com padrões de acesso não conflituosos sejam processadas em simultâneo.

Como resultado desta escolha de design, o modelo de execução pessimista beneficia do controlo fino sobre a alocação de recursos, permitindo a segmentação ou particionamento do espaço de estado de uma blockchain.

A paralelização cria efetivamente vários fragmentos de execução independentes síncronos e compostos, sustentados por um modelo de segurança unificado. Ajuda a resolver o congestionamento da rede e a otimizar os custos do gás através de uma gestão precisa dos recursos e dos mercados dinâmicos de taxas. Ao identificar "hotspots" de acesso estatal (áreas de alta demanda transacional), o sistema pode implementar otimizações direcionadas, como preços diferenciados de taxas, limitação de taxas ou alocação de recursos adicionais para estados de alta contenção. É importante notar que a atual implementação de paralelização de Solana não realizar plenamente o potencial dos mercados de taxas localizadas.

Para garantir a consistência dos dados no acesso concorrente, o modelo de execução pessimista utiliza um mecanismo de bloqueio. Antes que uma transação possa aceder a uma variável de estado específica, deve adquirir um bloqueio nessa variável. O bloqueio fornece à transação acesso exclusivo à variável, impedindo que outras transações a modifiquem simultaneamente. O bloqueio é libertado assim que a transação é executada, permitindo que outras transações acedam à variável.

Em Solana Nível do martempo de execução, que implementa este modelo de execução pessimista, as transações especificam as contas que irão ler ou escrever durante a execução. O Sealevel analisa os padrões de acesso e constrói filas de transações paralelas para cada 'thread' de CPU num nó validador. Se uma conta for acedida várias vezes, é listada sequencialmente numa única fila para evitar conflitos. As transações não processadas dentro do tempo de bloco do nó líder são agrupadas e encaminhadas para o próximo líder agendado para processamento.

Sistemas baseados em saídas de transações não gastas (UTXO) também melhoram a eficiência computacional. As UTXOs envolvem unidades específicas de moeda - UTXOs - associadas à carteira de um indivíduo. Para cada uma das transações da referida carteira, as UTXOs são gastas e substituídas por novas; uma ou mais UTXOs são criadas para o destinatário, representando o pagamento, e outra geralmente é criada para o iniciador, representando qualquer troco devido.

Ao definir quais contratos serão tocados, transações que tocam conjuntos desconexos de contratos podem ser executadas em paralelo por nós de execução (o que pode ser feito no modelo de dados "contas" com listas de acesso estritas). No entanto, para obter compatibilidade com contratos inteligentes no estilo Ethereum, esquemas de UTXO, como os do Fuel, restringem os nós produtores de blocos a executar transações com listas de acesso sobrepostas sequencialmente.

No entanto, o modelo de execução pessimista tem limitações. As transações devem declarar com precisão seus padrões de acesso antecipadamente, o que pode ser desafiador para transações complexas ou dinâmicas onde os padrões de acesso podem depender de dados de entrada ou lógica condicional. Declarações de padrões de acesso imprecisos ou incompletos podem causar desempenho subótimo e potenciais erros em tempo de execução. Além disso, o mecanismo de bloqueio pode introduzir latência e reduzir a concorrência quando muitas transações competem pelos mesmos variáveis de estado. Essa contenda pode formar gargalos de desempenho, já que as transações podem passar uma parte significativa do tempo de execução aguardando para adquirir bloqueios em variáveis de estado de alta demanda.

Mais importante, este modelo coloca um fardo considerável sobre os desenvolvedores, que devem ter um profundo entendimento das dependências de dados dos seus contratos para especificar com precisão os acessos necessários ao estado antecipadamente. Esta complexidade pode introduzir desafios, especialmente na conceção de aplicações com interações de estado dinâmicas e complexas, como as exchanges descentralizadas ou os criadores de mercado automatizados.

Execução Otimista

Em contraste, o modelo de execução otimista adota uma abordagem "especulativa" para a execução de transações, permitindo que as transações sejam executadas em paralelo sem a necessidade de declarações de acesso ao estado antecipado.

Em vez de prevenir conflitos antes de acontecerem, as transações são executadas otimisticamente em paralelo, assumindo que são independentes. O tempo de execução emprega técnicas como controlo de concorrência de várias versões(MVCC) ememória transacional de software(STM) para rastrear conjuntos de leitura e escrita durante a execução. Após a execução, o tempo de execução deteta quaisquer conflitos ou dependências. Toma medidas corretivas, como abortar e reexecutar transações em conflito, mas pode fazê-lo lendo da memória em vez do disco para identificar transações em conflito.

O modelo de execução otimista simplifica o processo de desenvolvimento, permitindo que programadores se concentrem em escrever a lógica do contrato sem se preocuparem com a declaração de padrões de acesso ao estado. Como as transações não precisam declarar suas interações de estado antecipadamente, os desenvolvedores têm mais liberdade para projetar seus contratos inteligentes, permitindo interações mais complexas e dinâmicas com o estado da blockchain. O modelo de execução otimista é particularmente adequado para plataformas que suportam um alto volume de transações e dapps complexos, pois pode oferecer maior throughput e escalabilidade do que o modelo pessimista.

Uma implementação notável deste modelo é encontrada emAptose o MoveVM daLaboratórios de Movimento*, que utiliza uma técnica conhecida como Block-STMEm Block-STM, as transações são primeiro executadas em paralelo; em seguida, as transações conflituosas são identificadas e agendadas para reexecução com base nas dependências detetadas. Esta abordagem garante que os recursos de processamento são continuamente utilizados, melhorando o débito enquanto mantêm a integridade do fluxo de trabalho transacional.

O Bloco-STM da Aptos de "Escalando a Execução de Blockchain ao Transformar a Maldição da Ordenação numa Bênção de Desempenho"

Apesar das suas vantagens, o modelo de execução otimista também apresenta desafios. A necessidade de deteção de conflitos em tempo de execução e a possibilidade de abortos e tentativas de transação introduzem sobrecarga computacional e complexidade. Além disso, a manutenção de múltiplas versões do estado e a gestão da sobrecarga associada à resolução de conflitos requerem um design de sistema sofisticado e mecanismos robustos de controlo de concorrência para garantir a integridade e o desempenho da blockchain.

Block-STM aproveita o MVCC para gerir eficazmente as escritas concorrentes e manter múltiplas versões de dados, evitando assim conflitos entre operações de escrita simultâneas. Incorpora um escalonador colaborativo para coordenar a execução e validação das tarefas em várias threads, garantindo que as transações são confirmadas na ordem em que foram iniciadas. Esta configuração minimiza as anulações de transações ao usar a estimativa de dependência dinâmica, o que permite que as transações com dependências esperem e resolvam eficientemente essas dependências antes de prosseguir.

Além disso, o modelo de conta usado pelo MoveVM difere do EVM do Ethereum, o que leva a menos colisões. No Ethereum, um token é tipicamente gerido por um único contrato inteligente, potencialmente causando múltiplas transações de token para interagir através do mesmo endereço de contrato, aumentando a probabilidade de conflitos. Em contraste, o MoveVM atribui tokens a contas de usuários individuais, reduzindo a chance de tais conflitos, já que cada transação geralmente interage com diferentes endereços de conta.

Em Monad, o conjunto inicial de transações executadas em paralelo pode ser enquadrado como uma fase de I/O, que pode produzir resultados imediatamente comprometidos, e a seguinte fase de “repetição”, que requer uma pequena quantidade de trabalho para limpar transações restantes conflitantes. Essas transições conflituosas são identificadas e colocadas em cache, permitindo que o overhead de execução seja reduzido porque estão na memória. Embora a maioria dos estados viva no disco, as transações conflituosas são rapidamente acessadas no momento da execução.

Os modelos de execução pessimista e otimista oferecem abordagens distintas para lidar com a execução de transações e gerenciamento de estado em blockchains. A escolha entre esses modelos envolve compensações entre a complexidade inicial na especificação de acesso ao estado e o overhead computacional associado à resolução dinâmica de conflitos.

Paralelismo de Dados e Tarefas

O paralelismo de dados e tarefas foca na otimização do desempenho distribuindo cargas computacionais por vários processadores: o paralelismo de dados segmenta um conjunto de dados para processamento simultâneo, enquanto o paralelismo de tarefas atribui diferentes tarefas a vários processadores para operar em simultâneo.

Essas otimizações são distintas, mas interdependentes com o paralelismo de acesso ao estado, que gerencia e sincroniza o acesso a recursos compartilhados como memória ou bancos de dados para evitar conflitos e garantir a integridade dos dados quando vários processos ou threads operam simultaneamente.

Paralelismo de Dados

O paralelismo de dados envolve a paralelização de operações específicas em vários elementos de dados simultaneamente. Esta abordagem é particularmente benéfica quando a mesma operação precisa ser aplicada a um grande conjunto de dados ou ao realizar operações computacionalmente intensivas em múltiplos valores de entrada. A chave desbloqueada vem da distribuição dos dados em várias unidades de processamento e da execução da mesma operação em simultâneo em diferentes elementos de dados.

Uma técnica comum para o paralelismo de dados é instrução única, dados múltiplos(SIMD), que permite que uma única instrução seja executada simultaneamente em vários elementos de dados. As CPUs modernas frequentemente possuem capacidades SIMD integradas, permitindo-lhes realizar operações paralelas em vários pontos de dados. Ao aproveitar as instruções SIMD, os desenvolvedores podem obter melhorias significativas de velocidade para certos tipos de operações, como cálculos matemáticos, transformações de dados ou processamento de sinais.

Por exemplo, considere um cenário em que é necessário aplicar uma função matemática complexa a uma grande matriz de números. Em vez de processar cada número sequencialmente, SIMD pode operar em vários números simultaneamente. Este processamento simultâneo é alcançado carregando um subconjunto dos números nos registos SIMD da CPU, executando a função matemática em todos os números carregados em paralelo e depois armazenando os resultados de volta na memória. Ao processar vários números de uma só vez, SIMD pode reduzir significativamente o tempo de execução global.

Trabalho do Firedancer em ED25519A verificação de assinatura demonstra o poder do SIMD para otimizar cálculos complexos. O processo de verificação de assinatura envolve operações aritméticas dentro de Campos de Galois, que podem ser computacionalmente intensivas. Ao aproveitar as instruções SIMD, o Firedancer pode realizar essas operações em múltiplos elementos de dados simultaneamente, resultando em melhorias significativas de desempenho. Essas otimizações serão críticas para melhorar o desempenho do Solana, que já implementou a paralelização do acesso ao estado.

Paralelismo de Tarefas

O paralelismo de tarefas envolve a paralelização de diferentes tarefas ou operações dentro de um programa em várias unidades de processamento. Essa abordagem é útil quando um programa consiste em várias tarefas independentes que podem ser executadas simultaneamente. Ao atribuir cada tarefa a uma unidade de processamento separada, como um núcleo de CPU ou uma GPU, o tempo de execução geral pode ser reduzido.

O paralelismo de tarefas é comumente utilizado em cenários em que um programa precisa executar várias operações complexas simultaneamente. Por exemplo, considere uma aplicação de processamento de vídeo que precisa aplicar diferentes filtros e efeitos a um fluxo de vídeo em tempo real. Em vez de usar todas as unidades de cálculo para aplicar coletivamente cada filtro sequencialmente, o paralelismo de tarefas pode distribuir a carga de trabalho pelas várias unidades de processamento. Uma unidade de processamento pode ser responsável por aplicar um filtro de desfoque enquanto outra unidade aplica um filtro de correção de cor, e assim por diante. Ao executar essas tarefas em paralelo, a aplicação pode alcançar um processamento mais rápido e manter uma experiência do utilizador suave.

Lagrange’s@lagrangelabs/a-big-data-primer-introducing-zk-mapreduce-12cf404eab75">ZK MapReduce (ZKMR) aproveita dados e paralelismo de tarefas para paralelizar e gerar provas de cálculos distribuídos em grandes conjuntos de dados. Na fase de mapa, o conjunto de dados de entrada é particionado em partes menores, e cada parte é processada independentemente por um operador de mapeamento separado ou máquina em paralelo (paralelismo de tarefa). A operação de "mapa" pode ser paralelizada dentro de cada tarefa do mapeador em vários núcleos ou processadores (paralelismo de dados). Da mesma forma, na fase de redução, a operação de "redução" nos valores associados a cada chave pode ser paralelizada dentro de cada tarefa redutora (paralelismo de dados). Em contraste, as tarefas do redutor são executadas paralelamente em vários trabalhadores (paralelismo de tarefas).

Ao combinar o paralelismo de dados e o paralelismo de tarefas, ZKMR pode alcançar escalabilidade e desempenho eficientes para cálculos complexos em conjuntos de dados massivos, mantendo garantias de conhecimento zero através da composição de prova recursiva.

Verificar um procedimento de MapReduce arbitrário em ZK a partir de "Introduzindo ZK MapReduce" de Lagrange

Capacidade do Lagrange de gerar provas de armazenamento para cálculos SQL ao longo de @lagrangelabs/anunciando-testnet-euclid-o-primeiro-banco-de-dados-verificável-e-coprocesador-zk-da-ethereum-cc4a5595365c">888.888 slots de armazenamento em 1 minuto e 20 segundos demonstram o poder do ZKMR, bem como a tarefa e paralelismo de dados que o sustentam. Além disso, o recente de Lagrange Árvores Reckleo artigo sublinha a necessidade de paralelismo, garantindo que as provas em lote dos dados onchain também sejam computáveis em O(logn), independentemente do tamanho do lote.

Paralelizando Consenso & Execução

Embora este artigo não aborde consenso, as blockchains também podem paralelizar o processo de consenso e execução. As blockchains tradicionais frequentemente processam transações de forma sequencial, chegando a um consenso sobre as transações de um bloco (bloco N) antes de as executar. O processamento paralelo das fases de consenso e execução aumenta significativamente a eficiência de execução e é uma técnica exemplificada por sistemas como o Monad. À medida que a rede alcança consenso para o bloco N, executa simultaneamente transações para o bloco anterior (N-1).

Esta estratégia garante a utilização contínua e eficiente dos recursos computacionais, reduzindo eficazmente os tempos de inatividade e melhorando a capacidade da rede de processar transações rapidamente. Estas melhorias aumentam o throughput do sistema e o custo de capital necessário para enviar spam para a rede.

Intérpretes & Redução de Despesas Gerais

Quando os contratos inteligentes são escritos em linguagens como Solidity, eles são primeiro compilados para o bytecode de nível inferior. Em seguida, o EVM usa um intérprete para executar este bytecode. O intérprete lê e executa cada instrução sequencialmente, semelhante à tradução de uma língua estrangeira em tempo real enquanto está sendo falada. Paradigma’s última peça sobre Rethaponta que isso leva a sobrecarga, uma vez que cada instrução deve ser processada individualmente e convertida de bytecode para instruções de máquina durante o tempo de execução.

Reth está a resolver as ineficiências da EVM através da incorporação de um compilador just-in-time (JIT). Este compilador traduz o bytecode em código de máquina nativo pouco antes da execução, contornando o processo de interpretação intensivo em recursos normalmente necessário durante o tempo de execução.

O Artigo Rethmenciona que 50% do tempo de execução do EVM sob um sistema baseado em interpretador é dedicado a processos que o JIT poderia teoricamente otimizar, sugerindo a possibilidade de dobrar a velocidade de execução com a implementação do JIT. No entanto, como Yilong aponta em esta apresentação, embora o JIT possa diminuir significativamente o tempo necessário para processar opcodes específicos, pode não impactar drasticamente a execução geral. Isso ocorre porque uma parte substancial dos 50% do tempo de execução do EVM que o JIT consome envolveoperações "host" e "sistema" (Slide 13), que não são passíveis de otimizações JIT como "aritmética" ou "controle" devido à sua natureza não computacional.

Embora os intérpretes possam limitar o desempenho, eles criam a oportunidade de "tradução", o que aumenta o escopo do código que pode aproveitar novas máquinas virtuais, reduzindo a sobrecarga para os desenvolvedores usarem o espaço de bloco do designer. Por exemplo, o Movement Labs desenvolveu o Fractal, permitindo que os desenvolvedores implantem seus contratos baseados em Solidity no MoveVM. Fractal funciona compilando o Solidity em uma linguagem intermediária contendo instruções articuladas em opcodes EVM, que são então mapeadas para suas contrapartes de bytecode MoveVM, permitindo que os contratos Solidity sejam executados no ambiente MoveVM.

Máquinas de Estado Especializadas e Personalizadas

Personalizar a camada de execução envolve projetar máquinas de estado especializadas otimizadas para aplicações específicas. Isso não só significa que um ambiente de execução pode dispensar completamente a necessidade de uma máquina virtual, mas também permite que as aplicações adaptem-se arquitetura de conjunto de instruções (ISA), estruturas de dados e modelo de execução às suas necessidades específicas. O principal benefício de desempenho de adaptar uma ISA a uma aplicação específica advém da redução do overhead de traduzir os padrões computacionais da aplicação nas instruções de propósito geral de uma ISA tradicional. As CPUs de propósito geral utilizam conjuntos de instruções básicas (ou seja, adicionar, carregar, ramificar) para suportar a execução de diferentes tipos de software. No entanto, quando as aplicações repetem frequentemente as mesmas operações multietapas, implementar esses padrões usando sequências de instruções simples se torna ineficiente.

Por exemplo, as aplicações de base de dados podem precisar de percorrer constantemente estruturas de dados de árvore, procurar entradas, atualizar valores e reequilibrar árvores. Num CPU normal, o mapeamento destas operações de nível superior requer quebrá-las em sequências longas de micro-operações de baixo nível, como carregamentos, armazenamentos, bifurcações e aritmética, executando individualmente no hardware geral. Em contraste, uma ISA personalizada para bases de dados pode fundir esses padrões recorrentes em instruções mais amplas otimizadas que aproveitam hardware especializado. Uma instrução “TraverseTree” poderia calcular endereços de memória, carregar nós relevantes e comparar chaves usando circuitos de comparação paralelos projetados para essa operação. “UpdateEntry” poderia reunir diretamente a entrada a partir do layout de armazenamento de base de dados otimizado, modificá-la e confirmar o novo estado tudo numa única instrução.

Isto elimina a sobrecarga redundante de traduzir operações de alto nível para instruções simples. Também permite que o hardware execute de forma otimizada a aplicação usando instruções paralelas explicitamente mais amplas, mas menos, adaptadas precisamente às suas necessidades.

LayerN’s Norddemonstra os benefícios de desempenho da especialização de ambientes de execução e estruturas de dados através do seu caso de uso específico de um livro de ordens verificável. A abordagem da LayerN concentra-se na otimização da colocação de negociações na estrutura de dados do livro de ordens, enquanto o seu mecanismo de pipeline é projetado para inserir novas ordens de forma eficiente na posição apropriada dentro da árvore de dados do livro de ordens. Ao adaptar a estrutura de dados e o algoritmo de inserção aos requisitos específicos de um livro de ordens, a LayerN alcança uma colocação de ordens de baixa latência e alta throughput.

Alternativamente, é possível aproveitar os ambientes de execução de propósito geral que permitem módulos programáveis de forma arbitrária aos quais as apps podem se conectar para otimizar seu desempenho. Esta abordagem prioriza a experiência do desenvolvedor em relação ao desempenho bruto.

FluenteeCWDutilizar uma estratégia que equilibra os compromissos entre a otimização do desempenho computacional bruto e a melhoria da experiência do desenvolvedor e a compatibilidade do ecossistema. Esta abordagem centra-se na utilização do WebAssembly (Wasm) como a VM para executar código. O Wasm tornou-se uma escolha preferida no desenvolvimento web devido ao seu amplo suporte a linguagens e ao amplo grau em que foi adotado.

A decisão de um desenvolvedor de usar Wasm em vez de execução nativa do cliente reflete uma preferência estratégica pela versatilidade e ampla acessibilidade de um ambiente de execução de propósito geral. Embora a execução nativa, que executa código diretamente no hardware sem uma máquina virtual, possa oferecer melhor desempenho, ela restringe a compatibilidade entre plataformas e é menos acessível aos desenvolvedores. Em contraste, o Wasm garante um ambiente de execução uniforme e seguro em diferentes plataformas, apesar de não alcançar a mesma velocidade bruta que a execução nativa. Esse compromisso está alinhado com as filosofias de design do Fluent e CWD, priorizando a produtividade do desenvolvedor e a integração mais ampla do ecossistema em detrimento da eficiência máxima de desempenho.

Implementação do CosmWasm (CWD), em particular, exemplifica esta abordagem não só ao empregar o Wasm para a execução de contratos inteligentes, mas também ao incorporá-lo a um quadro mais extenso projetado para suportar as complexidades das operações de blockchain. Enriquecido com a 'lógica periférica', este quadro oferece um avançado gerenciamento de contas, um mecanismo de gás personalizável e uma ordenação otimizada de transações. Estas características contribuem para um ambiente de desenvolvimento flexível, eficiente e seguro que capacita os desenvolvedores a construir dapps escaláveis e complexos relativamente facilmente.

Stackr* adota uma abordagem diferente combinando os benefícios de ambientes de execução personalizados com a flexibilidade das plataformas tradicionais de contratos inteligentes. O Stackr permite aos desenvolvedores codificar aplicações como rollups, permitindo-lhes definir suas próprias regras para a ordenação, execução e configuração das transações. No modelo Stackr, os desenvolvedores podem escolher a ISA, as estruturas de dados e o modelo de execução que melhor se adequam aos requisitos de sua aplicação.

O design de micro-rollup da Stackr a partir de "Apresentando o Stackr SDK"

Com o Stackr, os desenvolvedores podem aplicar regras de transição de estado diretamente no tempo de execução da aplicação, em vez de serem limitados pelas regras de uma máquina virtual de propósito geral, dando-lhes a capacidade de otimizar o seu conjunto de instruções para ser mais eficiente e redefinir o conjunto de coisas que podem ser feitas num ambiente de tempo de execução.

Isso resulta em uma execução mais leve e eficiente, uma vez que a lógica de negócios é implementada ao nível do cliente, eliminando a necessidade de invocações e validações dispendiosas de contratos inteligentes. Como resultado, as possibilidades em torno de como uma aplicação é configurada expandem-se em termos dos diferentes tipos de linguagens, estruturas de dados e assinaturas que os desenvolvedores podem usar para uma única aplicação sem sacrificar o desempenho.

Conclusão

Existem múltiplos caminhos para o desempenho ideal da camada de execução.

Nenhuma otimização singular para acesso ao estado ou paralelização se destaca como um ponto proprietário de diferenciação técnica entre as camadas de execução ao tentar capturar dapps. Conforme passámos, os benefícios da paralelização baseada em recursos no Solana podem ser igualmente aplicados ao modelo UTXO da Fuel. Qualquer pessoa pode usar a Amazon'ssoluções perspicazes para melhorar a escalabilidade horizontal através de shardageme melhorar o desempenho da camada de execução.

Embora o desempenho da camada de execução seja um vetor crítico para conquistar construtores de aplicações descentralizadas, novas L1s e L2s centradas na melhoria da execução devem competir em outras variáveis, incluindo segurança, interoperabilidade e compatibilidade com ferramentas existentes. Por esta razão, a proliferação de novas camadas de interoperabilidade—de Nebra a Statenet até ao AggLayer da Polygon—será crítica para os programadores que compram blockspace de designers, pois podem construir ou comprar blockspace especializado sem sacrificar a composabilidade síncrona e a liquidez partilhada das L1s tradicionais de propósito geral.

As melhorias na gestão do estado e eficiência computacional são interdependentes.

Em todas as comunidades que projetam novas camadas de execução, a paralelização do acesso ao estado tornou-se um meme definidor para as melhorias de desempenho que prometem trazer. Embora isso seja por uma boa razão, pois poderia levar a um 5x melhoria na execução do EVM, a evidência da experimentação inicial do Monad com paralelização demonstra que o seu papel está sendo enfatizado em excesso se outras melhorias, como I/O assíncrono, não forem desenvolvidas em conjunto.

Com base nisso, podemos concluir que a eficiência computacional é frequentemente alcançada apenas quando melhoramos como o estado é acessado e armazenado. O gerenciamento eficiente do estado reduz o tempo e os recursos necessários para acessar e manipular dados, o que acelera o processamento e reduz a carga computacional.

Indo um passo além, os incumbentes podem estar a tomar decisões dependentes do caminho que impedem a sua capacidade de competir com novos designs de blockchain que reestruturam como o estado é gerido e atualizado, dada a inércia que um hard fork implica. Como resultado, camadas de execução especializadas e modulares e L1s alternativos podem ser capazes de criar defensibilidade em torno das escolhas de design para um armazenamento de estado mais eficiente e os protocolos para leitura e escrita nele. Essas decisões de design oferecem uma vantagem competitiva, uma vez que os incumbentes podem encontrar inércia na atualização das suas estruturas de base de dados sem um hard fork.

No final do dia, os valores do espaço de bloco impactam o espaço de design para camadas de execução.

Ao compreendermos como podemos melhorar as camadas de execução, podemos agora delinear que as classes de otimizações diferem de acordo com duas escolhas de design críticas — quem está a executar transações e quantos nós precisam de estar envolvidos. As técnicas disponíveis para os desenvolvedores resolverem os gargalos de execução diferem significativamente dependendo das respostas iniciais de uma equipa a essas perguntas.

Por um lado, monolíticos L1s como Solana e Monad não aceitam separar o papel do validador em nós poderosos e fracos heterogêneos para acelerar o desempenho. “Aceitar” a dilatação do estado a curto prazo não é uma solução viável, por isso apoiam-se em melhorias ao nível da base de dados e outros componentes do motor de produção de blocos, como o consenso, para compensar o maior número de nós executantes considerados como um componente crítico e valor central da rede. Porque os modelos de segurança destes L1s dependem do consenso de um conjunto mais distribuído de validadores com requisitos de hardware mais fracos, os seus dados precisam de ser escritos numa base de dados que reside num disco, o que é necessariamente mais barato para uma blockchain sem permissão e maximamente descentralizada.

Por outro lado, projetos como Ethereum e suas L2s estão seguindo um plano que tende à centralização em seus nós de execução, através de construtores de blocos centralizados responsáveis perante nós proponentes de verificação mais fracos através de provas de fraude ou validade.

Suponha que os 'executores' centralizados de transações e transições de estado sejam considerados aceitáveis na busca de um futuro descentralizado. Nesse caso, a lei da física afirma que sistemas que podem 1) adicionar blocos a uma cadeia sem exigir que múltiplos atores reexecutem transações, 2) aumentar os requisitos do validador para maximizar a computação em memória (e ignorar o problema de inchaço do estado) e 3) reduzir a latência e os gargalos de consenso claramente superam os sistemas que dependem de uma descentralização extensiva e consenso entre os nós.

Na busca de um equilíbrio entre escalabilidade e minimização de confiança, está a tornar-se evidente que o objetivo das camadas de execução não deve ser otimizar a descentralização cegamente, nem a execução deve ser sempre completamente sem permissão.

À medida que desenvolvemos e implementamos uma gama mais ampla de ferramentas criptográficas, como provas de validade e fraude, reduzimos efetivamente o número de nós necessários para resistir à censura e manter a segurança e a vivacidade. No entanto, esta abordagem envolve compromissos, podendo impactar a resistência à censura, a integridade da ordem e as garantias de vivacidade devido à possível centralização dos executores.

Conforme observado por Sreeram, a “decentralização mínima viável” não significa que a “validação deve ser sem permissão”, mas sim que ela deve ser “adequadamente incentivada”. Isso implica que um sistema bem monitorizado, onde os validadores enfrentam significativas repercussões por má conduta, pode manter a segurança e a vitalidade sem a necessidade de uma descentralização excessiva.h/t Sreeram).

Tais modelos de governança já estão a ser testados em aplicações práticas. Por exemplo, rollups como Arbitrum estão a explorar sistemas de governança ou comitês para impor regras de ordenamento de transações e seleção de líderes, e estão a considerar mecanismos nos quais os sequenciadores usam dados onchain para garantir políticas de ordenamento de transações.

Apesar desses avanços, não existe uma "fronteira pareto ótima" definitiva para equilibrar a descentralização com o desempenho.

Considerações ideológicas e técnicas continuam a favorecer a descentralização dos nós de execução para validar o estado. Embora a centralização dos nós reduza a sobrecarga de consenso e a atualização de hardware possa melhorar significativamente o desempenho, ainda resta saber se essas otimizações atrairão desenvolvedores focados na criação de aplicações resistentes à censura e em que medida a resistência à censura continua a ser um valor central na indústria.

*denotes uma empresa do portfólio de Arquétipos

Aviso legal:

1. Este artigo é reproduzido a partir de [Gateespelho), Encaminhe o Título Original 'Designer Blockspace: O Futuro dos Ambientes de Execução', Todos os direitos autorais pertencem ao autor originalBenjamin Funk]. Se houver objeções a esta reimpressão, por favor contacte o Gate Learnequipa e eles vão tratar do assunto prontamente.

2. Aviso 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, é proibido copiar, distribuir ou plagiar os artigos traduzidos.