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

Nos nove anos desde que o Ethereum lançou o primeiro blockchain descentralizado e programável, a criptografia enfrentou múltiplos obstáculos na busca por escalar aplicativos descentralizados para bilhões de usuários. E para desenvolver soluções de escalabilidade para lidar com isso, a indústria de criptografia tem continuamente financiado e desenvolvido tipos inteiramente novos de blockchains para resolver o "problema de desempenho".

No entanto, o “problema de desempenho” tem sido mal definido e quantificado. Memes sintéticos como “transações por segundo” têm embalado de forma organizada o que são realmente comparações entre maçãs e laranjas entre transações que não requerem 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, nos distraindo de uma abordagem fundamentada para identificar os conjuntos de otimizações que podemos fazer para resolver problemas altamente interdependentes.

Apesar dessa neblina, testemunhamos melhorias credíveis e sustentadas na escalabilidade do blockchain ao longo dos últimos anos. À medida que o Ethereum avança em seu roadmap centrado em rollup, uma nova onda de rollups, coprocessadores,disponibilidade de dados (DA) camadas e L1s concorrentes estão surgindo - cada uma com escolhas de design únicas para fornecer aos desenvolvedores ambientes mais eficientes para a construção de dapps escaláveis e amigáveis ao usuário.

Hoje, a introdução do EIP4844 e camadas DA alternativas aliviaram o gargalo crítico do DA. Apesar deste marco crítico, as evidências sugerem que outros gargalos importantes precisam ser resolvidos. No mês passado, Basecoletado$1.57M em taxas de transação em um único diaenquanto pagava apenas $5K em custos de disponibilidade de dados para o Ethereum. Isso sugere que o trabalho computacional necessário para validar e processar 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 um desempenho superior e expandir o escopo de aplicativos que podem viver onchain.

Desafios de hoje

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

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

O acesso ineficiente ao estado refere-se ao overhead de recuperar e atualizar o estado do blockchain, o que pode retardar o processamento de transações. Por outro lado, a computação ineficiente é uma função do overhead incorrido pelos algoritmos que executam operações e transições de estado, que podem incluir desde transferências simples até contratos inteligentes complexos e verificações de assinatura.

Esses gargalos se reforçam mutuamente - atrasos no acesso ao estado podem prolongar o tempo de computação, enquanto práticas computacionais ineficientes podem sobrecarregar o gerenciamento de estado. Além disso, as melhorias propostas para abordar essas questões frequentemente requerem 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.

Gargalo #1: Acesso estatal ineficiente

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

Nas blockchains, o estado do mundo é gerenciado e atualizado através de estruturas de dados específicas chamadas árvores. Árvores são essenciais para blockchains, fornecendo uma maneira segura e eficiente de dar às partes externas ao nó executor garantias em torno do estado correto do blockchain. Cada atualização dentro de uma trie gera um novo hash raiz, ao qual clientes leves podem fazer referência para verificar transações e saldos de contas sem precisar manter toda a cadeia.

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

À medida que o Ethereum adiciona mais contratos inteligentes e tokens ao seu estado, sua árvore de estado se torna maior e mais complexa. Conforme o estado cresce, ele 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 de estado impacta diretamente no desempenho do Ethereum porque o estado é armazenado em disco, e operações de disco incorrem em uma sobrecarga alta. Enquanto acessar dados de um registro de CPU pode levar 0.1 nanossegundos, pode levar entre 10 e 100 microssegundos(100x–1000x mais lento)para acessar 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 leitura e escrita no estado. Por exemplo, a estrutura não sequencial do trie de Merkle Patricia leva inerentemente a essas operações de entrada/saída (I/O) de disco lendo e escrevendo em várias localizações imprevisíveis no disco. A natureza aleatória das entradas de transações e as alterações de estado subsequentes que elas desencadeiam levam a um padrão de acesso de dados dispersos que reduz significativamente o processo de verificação e atualização do estado e utiliza apenas uma parte de umcapacidade do dispositivo de hardware.

Em suma, os primitivos de gerenciamento de estado para blockchains estão longe de alcançar seu potencial absoluto, e inúmeros avanços podem ser feitos 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 de vários núcleos capazes de lidar com múltiplas operações simultaneamente. Essa execução sequencial leva a tempos ociosos inevitáveis da CPU 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 mais baixo e independente de plataforma - que é então executado instrução por instrução. Esse processo de tradução e execução introduz uma sobrecarga significativa, especialmente para aplicativos com tarefas específicas de aplicativo complexas e frequentemente repetidas.

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

Soluções: Acesso Ineficiente ao Estado

Existem algumas maneiras distintas pelas quais as equipes estão melhorando a taxa na qual 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 busca de maneiras de reduzir as operações custosas de E/S de disco que levam ao inchaço do estado.

Statelessness & 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 a memória de acesso aleatório (RAM) mais rápida. Acesso às informações de estado na RAM reduz significativamente a sobrecarga associada às operações de disco, que são mais lentas e consomem mais recursos.

No entanto, esta abordagem desafia o princípio central da descentralização. Armazenar quantidades cada vez maiores de dados de estado na RAM torna necessário hardware mais avançado e caro, o que pode limitar a capacidade dos indivíduos de participar como operadores de nó. Consequentemente, à medida que os requisitos de hardware aumentam, menos entidades podem se dar ao luxo de executar esses nós.

Para equilibrar a atratividade da computação na memória com a minimização da confiança, tanto os L1s (como o Ethereum) quanto os L2s estão seguindo um roadmap de escalabilidade que depende da separação do papel de validador em nós de execução centralizados separados com muitos nós de verificação. Neste modelo, produtores de blocos altamente performáticos com requisitos de hardware para computação em memória são responsáveis por gerar blocos, e provas criptográficas (provas de fraude e de validade) são utilizadas pelos nós de verificação para responsabilizar os produtores de blocos.

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

Em paralelo, provas de fraude e validade são usadas em vez de consenso descentralizado para ampliar as propriedades de minimização de confiança do sistema juntamente com sua capacidade de processamento. Como resultado, nós poderosos de produção de blocos centralizados são contrabalançados por nós verificadores que podem ser executados em hardware muito menos caro. Esses nós realizam a função crítica de verificar independentemente as 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 esse processo de forma minimizada em confiança, as camadas de execução devem implementar um grau deestado de apatridia, 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ó verificador. Esta testemunha encapsula todas as mudanças de estado propostas pelo novo bloco, permitindo que os validadores verifiquem essas mudanças sem dados históricos adicionais.

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

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

Árvores Verkle aprimoram a estrutura das tradicionais árvores de Merkle, simplificando as conexões entre as folhas e a raiz e eliminando a necessidade de incluir nós irmãos no processo de verificação. Em uma árvore Verkle, verificar uma prova envolve apenas o valor no nó folha, um compromisso com o nó raiz e um único compromisso de vetor com base em compromissos polinomiais, que substitui os múltiplos compromissos baseados em hash encontrados nas árvores de Merkle. Essa 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.

Nos próximos anos, veremos implementações de estado sem estado acontecerem nos níveis L1 e L2 com configurações variadas. De acordo com o último roteiro do Ethereum, os validadores podem confiar nos construtores de blocos para fornecer provas Verkle sobre o estado de determinados blocos e verificar essas provas leves em vez de manter o estado do Ethereum diretamente.

No nível L2, equipes como MegaETHestão aplicando ativamente o conceito de statelessness ao design de rollups otimistas. Em seu design, o nó sequenciador gera uma testemunha para cada bloco contendo os valores de estado necessários e hashes intermediários enquanto emite um delta de estado representando as mudanças no estado. Os nós verificadores podem então reexecutar qualquer bloco recuperando a testemunha da camada DA ou de uma rede peer-to-peer sem armazenar todo o estado. Em paralelo, os nós completos atualizam seu estado aplicando os deltas de estado disseminados pela rede, permitindo que eles permaneçam sincronizados sem reexecutar transações ou armazenar todo o histórico de estado.

No entanto, também vale ressaltar que os benefícios da falta de estado e a capacidade resultante de computar na memória não são uma bala de prata para o desempenho da camada de execução.

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

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

Melhorando os Bancos de Dados

As equipes que trabalham nas camadas de execução estão encontrando maneiras de melhorar a estrutura desses bancos de dados em si para eliminar alguns dos gargalos experimentados pelo Ethereum e por outras blockchains compatíveis com o 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 otimização puramente para eficiência computacional e alcançar 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 as solicitações de leitura e escrita multithread 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 leitura ou gravação em dispositivos de armazenamento, muitas vezes criam gargalos, principalmente com unidades de disco rígido mecânicas (HDDs). Essas unidades requerem o movimento físico de uma cabeça de leitura/gravação para acessar dados, o que pode retardar significativamente o processamento de dados.

AIO addresses this challenge by allowing programs to perform I/O operations concurrently with other processes. Essentially, a program can initiate an I/O operation and move on without waiting for it to complete. It does this by registering a callback function or a promise that the operating system or an I/O library will fulfill once the I/O operation finishes. This asynchronous approach allows the main program to continue executing other tasks, improving overall efficiency by not stalling for I/O tasks to complete.

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

Por exemplo, 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. Essa configuração é mais eficiente do que sistemas que dependem exclusivamente de armazenamento baseado em disco tradicional ou aqueles que usam bancos de dados em memória, que ainda podem enfrentar atrasos devido a gravações frequentes de dados em mídias de armazenamento mais lentas e leituras.

Da mesma forma, Reth utiliza um método que separa as operações do banco de dados do núcleo do mecanismo de execução EVM. Essa configuração permite que o bytecode 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 desviadas para processos paralelos. Reth utiliza o modelo de ator - um padrão de arquitetura de software - para gerenciar esses processos paralelos de forma eficaz, garantindo que as operações de E/S não interrompam o interpretador EVM.

Frequência de Merklização de 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 gravações frequentes no disco e leituras e travessias contínuas da árvore. As árvores de Merkle geralmente funcionam agrupando hashes intermediários em conjuntos de 16 (chamado de nó) e armazenando-os em um banco de dados de armazenamento de chave-valor, onde a chave é o hash do nó e o valor é o próprio nó.

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

A abordagem da Solana de atualizar o compromisso do 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 na raiz de Merkle. Isso reduz o custo computacional geral associado à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 a sobrecarga de leituras e gravações de estado, melhorando o desempenho. No entanto, os clientes leves precisariam reproduzir as alterações de bloco para rastrear o estado entre os períodos ou enviar transações onchain para verificação de estado, e essa mudança não é compatível atualmente com o Ethereum.

Estruturas de Dados Eficientes & Especializadas

Além disso, as estruturas de árvores em camadas dentro dos clientes Ethereum existentes geralmente causam padrões de acesso ao estado ineficientes, contribuindo ainda mais para a expansão do estado. Enquanto o estado do Ethereum é estruturado como um MPT, ele também é armazenado nos bancos de dados do cliente Ethereum, como LevelDB,PebbleDB(utilizado pelo go-ethereum), ou MDBX (empregado pelo Erigon) que armazenam dados em árvores de Merkle como um B-TreeouLSM-Tree.

Nesta configuração, uma estrutura de dados é enraizada em outra estrutura de dados de um tipo separado, criando '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 da leitura pode ser entendida como o resultado das várias etapas para acessar ou atualizar informações contidas em um estado, o que requer navegar na árvore externa para encontrar o ponto de entrada no 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 utiliza nativamente uma estrutura de dados de árvore Patricia em disco e na memória. Do ponto de vista técnico, as árvores Patricia são frequentemente superiores a outras estruturas de árvore Merkle devido à sua combinação única de eficiência de espaço, correspondência de prefixo eficiente e travessia mínima de nós. O design da trie colapsa nós com filhos únicos e simplifica pesquisas, inserções e exclusões, reduzindo o número de operações de E/S de disco ou de rede necessárias. Além disso, a habilidade de uma trie Patricia em lidar com correspondência de prefixo melhora o desempenho em aplicações que necessitam de buscas rápidas de chaves parciais.

Outro gargalo específico das estruturas baseadas em árvores é que acessar ou atualizar dados requer percorrer várias camadas, resultando em numerosos acessos sequenciais ao disco.Laboratórios Soberanosaborda essa ineficiência ao advogar por uma configuração de árvore de Merkle binária. Essa 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 de Merkle binária do "Nearly Optimal State Merklization" do Sovereign Labs

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

Expiração do Estado

O vencimento de estado é um mecanismo para gerenciar e reduzir o tamanho do estado do blockchain, removendo dados que não foram acessados por um período de tempo determinado. Embora o vencimento seja frequentemente agrupado na categoria de 'estado sem estado', é crucial distinguir esses conceitos no contexto de execução.

A apatridia 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. Em contraste, a expiração de estado pode ser aplicada a blockchains com poucos e muitos nós em execução.

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

• Expiração por Locação: Este método envolve a cobrança de uma taxa de manutenção, ou "aluguel," para manter as contas ativas no banco de dados do estado. Se o aluguel não for pago, as contas são arquivadas até que uma taxa seja paga para restaurá-las.
• Expiração por tempo: Aqui, as contas são consideradas inativas se não tiverem sido acessadas - ou seja, sem transações ou interações - por uma duração especificada.

Ambos os métodos visam manter apenas os dados usados ativamente 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, pois os nós gastam menos tempo escaneando e mais tempo processando.

Execução Sharding

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

Em uma arquitetura de blockchain shard, o estado global é dividido em partições distintas chamadas shards. Cada shard mantém sua parte do estado e é responsável pelo processamento de um subconjunto das transações da rede. As transações são atribuídas a shards específicos com base em uma função de shard 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. Isso 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 do Blockchain"

Isso se torna evidente ao explorar Protocolo NEARdesign de fragmentação, Nightshade, que alcança a estado de não pertencer para escalar o shard sem comprometer a minimização da confiança.

Na Nightshade, o blockchain é estruturado como uma única cadeia lógica, com cada bloco composto por vários “chunks” e um chunk sendo alocado por shard. Esses 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 completo do blockchain e simplifica o processo de comunicação entre shards.

Similar ao modelo de separação de construtor adequado (PBS) no Ethereum, Nightshade delimita explicitamente os papéis dos nós com estado e sem estado. Na NEAR, validadores com estado são designados para shards específicos e são responsáveis por coletar transações, executá-las e produzir fragmentos específicos da shard. Eles mantêm o estado completo de sua shard designada e geram testemunhas de estado para que os validadores usem durante o processo de validação.

Enquanto isso, os validadores sem estado são atribuídos aleatoriamente para validar shards específicos em uma base por bloco. Eles não precisam 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 chunk. 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 de sua respectiva shard, em vez dos dados de toda a rede, a carga de armazenamento e computacional nos nós individuais é reduzida.

Soluções: Computação Ineficiente

Paralelizando a execução

Hora de abordar o elefante na sala: paralelização. A execução paralela de transações permite processar várias transações utilizando recursos computacionais múltiplos simultaneamente. Isso permite aumentar a taxa de transferência à 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 dos blockchains. Especificamente, a paralelização pode envolver:

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

Acesso Paralelizado ao Estado

Acesso paralelo ao estadotraz dois benefícios críticos:

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

O principal desafio na paralelização da execução de transações decorre da gestão do acesso concorrente ao estado global compartilhado sem violar o ACIDregras para atualização de sistemas distribuídos. Se uma blockchain tem um monte de transações sendo executadas em paralelo, algumas delas entrarão em conflito. Como resultado, as duas metodologias principais para paralelizar o acesso ao estado diferem quanto ao momento em que 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 que acessarão (leitura ou escrita) durante a execução. Essas informações são incluídas 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 e 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, melhorando o throughput. O tempo de execução cria filas de transações paralelas para cada thread da CPU em um nó validador, garantindo que transações com padrões de acesso não conflitantes sejam processadas simultaneamente.

Como resultado dessa escolha de design, o modelo de execução pessimista se beneficia do controle 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 compostos de forma síncrona, sustentados por um modelo de segurança unificado. Ele ajuda a resolver o congestionamento da rede e otimizar os custos de gás por meio de gerenciamento preciso de recursos e mercados de taxas dinâmicos. Ao identificar "hotspots" de acesso ao estado (á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 implementação atual de paralelização da 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 acessar uma variável de estado específica, ela 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 é liberado assim que a transação é executada, permitindo que outras transações acessem a variável.

Em Solana Nível do mar tempo de execução, que implementa esse modelo de execução pessimista, as transações especificam as contas que lerão ou escreverão durante a execução. O Sealevel analisa os padrões de acesso e constrói filas de transações paralelas para cada thread da CPU em um nó validador. Se uma conta for acessada várias vezes, ela é listada sequencialmente em uma ú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ída de transações não gastas (UTXO) melhoram a eficiência computacional de forma semelhante. UTXOs envolvem unidades específicas de moeda — UTXOs — associadas à carteira de um indivíduo. Para cada transação da referida carteira, os UTXOs são gastos e substituídos por novos; um ou mais UTXOs são criados para o destinatário, representando o pagamento, e outro é tipicamente criado para o iniciador, representando qualquer troco devido.

Ao definir quais contratos serão tocados, transações que tocam conjuntos disjuntos de contratos podem ser executadas em paralelo pelos nós de execução (o que pode ser realizado no modelo de dados "contas" com listas de acesso restritas). No entanto, para obter compatibilidade com contratos inteligentes no estilo Ethereum, esquemas de UTXO como o da 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 imprecisas ou incompletas de padrões de acesso podem causar desempenho subótimo e erros de tempo de execução potenciais. 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 contenção pode formar gargalos de desempenho, pois as transações podem passar uma parte significativa do tempo de execução esperando para adquirir bloqueios em variáveis de estado de alta demanda.

Mais importante, este modelo coloca uma carga considerável sobre os desenvolvedores, que devem ter um entendimento profundo das dependências de dados de seus contratos para especificar com precisão os acessos de estado necessários antecipadamente. Essa complexidade pode trazer desafios, especialmente ao projetar aplicativos com interações de estado dinâmicas e complexas, como as bolsas descentralizadas ou fabricantes de mercado automatizados.

Execução otimista

Por outro lado, 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 antecipado ao estado.

Em vez de prevenir conflitos antes de acontecerem, as transações são executadas de forma otimista em paralelo, assumindo que são independentes. O tempo de execução emprega técnicas como controle 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 detecta quaisquer conflitos ou dependências. Ele toma medidas corretivas, como abortar e reexecutar transações conflitantes, mas pode fazer isso lendo da memória em vez do disco para identificar transações conflitantes.

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 preocupar 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 ao 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 em Aptose o MoveVM daLaboratórios de Movimento*, que emprega uma técnica conhecida como Block-STM. No Block-STM, as transações são primeiro executadas em paralelo; em seguida, as transações conflitantes são identificadas e agendadas para reexecução com base nas dependências detectadas. Essa abordagem garante que os recursos de processamento sejam continuamente utilizados, aumentando a capacidade de processamento e mantendo a integridade do fluxo de trabalho transacional.

O Block-STM da Aptos de "Scaling Blockchain Execution by Turning Ordering Curse to a Performance Blessing"

Apesar de suas vantagens, o modelo de execução otimista também apresenta desafios. A necessidade de detecçã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, manter várias versões do estado e gerenciar a sobrecarga associada à resolução de conflitos requer um design de sistema sofisticado e mecanismos de controle de concorrência robustos para garantir a integridade e o desempenho do blockchain.

Block-STM alavanca MVCC para gerenciar efetivamente gravações simultâneas e manter múltiplas versões de dados, evitando conflitos entre operações de gravação simultâneas. Ele incorpora um programador colaborativo para coordenar as tarefas de execução e validação em múltiplas threads, garantindo que transações sejam confirmadas na ordem em que foram iniciadas. Essa configuração minimiza abortos de transações usando estimativa dinâmica de dependência, o que permite que 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 gerenciado por um único contrato inteligente, podendo causar múltiplas transações de token interagirem 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 endereços de conta diferentes.

Em Monad, o conjunto inicial de transações executadas em paralelo pode ser enquadrado como uma fase de E/S, que pode produzir resultados imediatamente aplicáveis, e a seguinte fase de "retry", que requer uma pequena quantidade de trabalho para limpar transações restantes conflitantes. Essas transições conflitantes são identificadas e colocadas em cache, permitindo que o overhead de execução seja reduzido porque elas estão na memória. Enquanto a maioria dos estados vive no disco, as transações conflitantes são acessadas rapidamente 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 a sobrecarga computacional associada à resolução dinâmica de conflitos.

Paralelismo de Dados e Tarefas

O paralelismo de dados e tarefas concentra-se na otimização de desempenho distribuindo cargas computacionais entre 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 operarem simultaneamente.

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 vários valores de entrada. A chave destrancada vem da distribuição dos dados em várias unidades de processamento e da execução da mesma operação simultaneamente em diferentes elementos de dados.

Uma técnica comum para o paralelismo de dados é instrução única, vários dados(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 que executem operações paralelas em vários pontos de dados. Ao aproveitar as instruções SIMD, os desenvolvedores podem obter melhorias significativas de desempenho 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 você deve 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 registradores SIMD da CPU, executando a função matemática em todos os números carregados em paralelo e, em seguida, armazenando os resultados de volta na memória. Ao processar vários números de uma vez, SIMD pode reduzir significativamente o tempo de execução geral.

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, o que pode ser computacionalmente intensivo. Ao alavancar instruções SIMD, Firedancer pode realizar essas operações em vários elementos de dados simultaneamente, resultando em melhorias significativas de desempenho. Essas otimizações serão fundamentais 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. Esta abordagem é útil quando um programa consiste em múltiplas tarefas independentes que podem ser executadas em paralelo. 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 usado em cenários onde um programa precisa realizar várias operações complexas simultaneamente. Por exemplo, considere um aplicativo 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 cada unidade 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, o aplicativo pode obter um processamento mais rápido e manter uma experiência do usuário suave.

Lagrange’s@lagrangelabs/a-big-data-primer-introducing-zk-mapreduce-12cf404eab75">ZK MapReduce (ZKMR) aproveita o paralelismo de dados e 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 blocos menores, e cada bloco é processado independentemente por um mapeador, trabalhador ou máquina separados, em paralelo (paralelismo de tarefa). A operação "map" 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 "reduzir" 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 entre 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 por meio da composição de prova recursiva.

Verificando um procedimento MapReduce arbitrário no ZK de 'Introduzindo o ZK MapReduce' de Lagrange

A capacidade de Lagrange de gerar provas de armazenamento para cálculos SQL sobre@lagrangelabs/anunciando-testnet-euclid-o-primeiro-banco-de-dados-verificável-e-coprocessador-zk-da-ethereum-cc4a5595365c">888.888 slots de armazenamento em 1 minuto e 20 segundos demonstram o poder do ZKMR, bem como o paralelismo de tarefas e dados que o sustentam. Além disso, o recente de Lagrange Árvores Reckleo artigo destaca a necessidade de paralelismo, pois garante que as provas em lote dos dados onchain também sejam computáveis em 𝑂(log𝑛), independentemente do tamanho do lote.

Paralelizando Consenso & Execução

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

Essa estratégia garante o uso contínuo e eficiente dos recursos computacionais, reduzindo efetivamente os tempos ociosos e aprimorando a capacidade da rede de processar transações rapidamente. Essas melhorias aumentam a taxa de transferência do sistema e o custo de capital necessário para enviar spam à rede.

Intérpretes & Reduzindo Despesas

Quando contratos inteligentes são escritos em linguagens como Solidity, eles são primeiro compilados no bytecode de nível inferior. Em seguida, a EVM usa um interpretador para executar este bytecode. O interpretador lê e executa cada instrução sequencialmente, semelhante à tradução de um idioma estrangeiro em tempo real conforme está sendo falado. Paradigma's última peça sobre Rethaponta que isso leva a sobrecarga, já que cada instrução deve ser processada individualmente e convertida de bytecode para instruções de máquina durante a execução.

A Reth está abordando as ineficiências do EVM incorporando um compilador just-in-time (JIT). Esse compilador converte bytecode em código de máquina nativo pouco antes da execução, contornando o processo de interpretação intensivo de recursos normalmente necessário durante o tempo de execução.

O Artigo Reth menciona que 50% do tempo de execução do EVM sob um sistema baseado em interpretador é dedicado a processos que teoricamente o JIT poderia 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, enquanto o JIT pode 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 envolve operações de "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 para a “tradução”, que aumenta o escopo do código que pode alavancar novas máquinas virtuais, reduzindo os custos para os desenvolvedores usarem o espaço de bloco do designer. Por exemplo, a Movement Labs desenvolveu o Fractal, permitindo que os desenvolvedores implantem seus contratos baseados em Solidity no MoveVM. O Fractal funciona compilando o Solidity em uma Linguagem Intermediária contendo instruções articuladas em códigos de operação EVM, que são então mapeados para seus equivalentes em bytecode MoveVM, permitindo que os contratos Solidity sejam executados no ambiente MoveVM.

Máquinas de Estado Especializadas e Personalizadas

Customizar a camada de execução envolve projetar máquinas de estado especializadas otimizadas para aplicações específicas. Isso não apenas 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 personalizem o 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 um ISA a uma aplicação específica vem da redução do overhead de traduzir os padrões computacionais da aplicação nas instruções de propósito geral de um ISA tradicional. CPUs de propósito geral usam conjuntos de instruções básicas (ou seja, adição, carga, ramificação) para suportar a execução de diferentes tipos de software. No entanto, quando as aplicações repetem frequentemente as mesmas operações multi-estágio, implementar esses padrões usando sequências de instruções simples se torna ineficiente.

Por exemplo, os aplicativos de banco de dados podem precisar atravessar constantemente estruturas de dados de árvore, procurar entradas, atualizar valores e rebalancear árvores. Em uma CPU normal, o mapeamento dessas operações de nível superior requer dividi-las em longas sequências de microoperações de baixo nível, como cargas, armazenamentos, ramificações e aritmética, executadas individualmente no hardware geral. Por outro lado, um ISA personalizado para bancos 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 coletar diretamente a entrada do layout de armazenamento de banco de dados otimizado, modificá-la e confirmar o novo estado em uma única instrução.

Isso 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 e menos numerosas, adaptadas precisamente às suas necessidades.

LayerN’s Norddemonstra os benefícios de desempenho de ambientes de execução especializados e estruturas de dados através de seu caso de uso específico de um livro de ordens verificável. A abordagem da LayerN foca na otimização da colocação de negociações na estrutura de dados do livro de ordens, enquanto 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 pedidos de baixa latência e alta taxa de transferência.

Alternativamente, é possível adotar ambientes de execução de propósito geral que permitem módulos programáveis arbitrariamente aos quais os aplicativos podem se conectar para otimizar seu desempenho. Esta abordagem prioriza a experiência do desenvolvedor em detrimento do desempenho bruto.

FluenteeCWDutilizar uma estratégia que equilibra os tradeoffs entre otimizar o desempenho computacional bruto e aprimorar a experiência do desenvolvedor e a compatibilidade do ecossistema. Esta abordagem centra-se em usar o WebAssembly (Wasm) como a VM para executar o código. O Wasm tornou-se uma escolha preferida no desenvolvimento web devido ao amplo suporte de idiomas e ao amplo grau em que foi adotado.

A decisão de um desenvolvedor de usar o Wasm em vez da 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 o código diretamente no hardware sem uma máquina virtual, possa oferecer melhor desempenho, ela restringe a compatibilidade entre plataformas e é menos acessível para os desenvolvedores. Em contraste, o Wasm garante um ambiente de execução uniforme e seguro em diferentes plataformas, apesar de não atingir a mesma velocidade bruta da execução nativa. Essa compensação está alinhada com as filosofias de design da Fluent e da CWD, priorizando a produtividade do desenvolvedor e a integração mais ampla do ecossistema em detrimento da eficiência máxima de desempenho.

Implantação do CosmWasm (CWD), em particular, exemplifica essa abordagem não apenas empregando o Wasm para a execução de contratos inteligentes, mas também incorporando-o a um framework mais extenso projetado para suportar as complexidades das operações em blockchain. Enriquecido com 'lógica periférica', este framework oferece um gerenciamento avançado de contas, um mecanismo de gás personalizável e uma ordenação de transações otimizada. Esses recursos 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 ao combinar os benefícios de ambientes de execução personalizados com a flexibilidade das plataformas tradicionais de contratos inteligentes. O Stackr permite que os desenvolvedores programem aplicativos como rollups, permitindo-lhes definir suas próprias regras para a ordenação, execução e configuração de transações. No modelo Stackr, os desenvolvedores podem escolher a ISA, estruturas de dados e modelo de execução que melhor atendam aos requisitos de sua aplicação.

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

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

Isso resulta em uma execução mais leve e eficiente, pois a lógica de negócios é implementada no nível do cliente, eliminando a necessidade de invocações e validações caras de contratos inteligentes. Como resultado, as possibilidades em torno de como uma aplicação é configurada se expandem em termos dos diferentes tipos de idiomas, estruturas de dados e assinaturas que os desenvolvedores podem usar para um único aplicativo 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 camadas de execução ao tentar capturar dapps. Conforme avançamos, os benefícios da paralelização baseada em recursos no Solana podem ser igualmente aplicados ao modelo UTXO do 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.

Enquanto o desempenho da camada de execução é um vetor crítico para conquistar construtores de aplicativos descentralizados, 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 essa razão, a proliferação de novas camadas de interoperabilidade - do Nebra ao Statenet ao AggLayer da Polygon - será crítica para os desenvolvedores que compram espaço de bloco de designer, pois podem construir ou comprar espaço de bloco especializado sem sacrificar a composabilidade síncrona e a liquidez compartilhada das L1s tradicionais de propósito geral.

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

Entre as comunidades que projetam novas camadas de execução, a paralelização do acesso ao estado se tornou um meme definidor para as melhorias de desempenho que prometem trazer. Embora isso seja por um bom motivo, pois poderia levar a um Melhoria de 5x na execução do EVM, evidências dos primeiros experimentos de Monad com paralelização demonstram que seu papel é superestimado se outras melhorias, como E/S assíncrona, não forem desenvolvidas em conjunto.

Com base nisso, podemos concluir que a eficiência computacional muitas vezes só é alcançada quando melhoramos como o estado é acessado e armazenado. A gestão 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.

Levando isso um passo adiante, os incumbentes podem estar fazendo escolhas dependentes do caminho que prejudicam sua capacidade de competir com novos designs de blockchain que reestruturam como o estado é gerenciado 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 defensabilidade em torno das escolhas de design para armazenamento de estado mais eficiente e os protocolos para leitura e escrita nele. Essas decisões de design oferecem uma vantagem competitiva, já que os incumbentes podem encontrar inércia ao atualizar suas estruturas de banco de dados sem um hard fork.

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

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

Por um lado, L1s monolíticos como Solana e Monad não aceitam separar o papel de validador em nós poderosos e fracos heterogêneos para acelerar o desempenho. "Aceitar" o inchaço do estado no curto prazo não é uma solução viável, então eles se apoiam em melhorias na camada de banco de dados e em outros componentes do mecanismo de produção de blocos, como consenso, para compensar o número mais amplo de nós em execução considerados como um componente crítico e valor principal da rede. Como os modelos de segurança desses L1s dependem do consenso de um conjunto mais distribuído de validadores com requisitos de hardware mais fracos, seus dados precisam ser gravados em um banco de dados que vive em um disco, o que é necessariamente mais barato para um blockchain sem permissão e maximamente descentralizado.

Por outro lado, projetos como Ethereum e suas L2s estão seguindo um roadmap que tende à centralização em seus nós executivos através de construtores de bloco centralizados responsáveis perante nós proponentes verificadores 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 estabelece que sistemas que podem 1) adicionar blocos a uma cadeia sem exigir que vários atores reexecutem transações, 2) aumentar os requisitos do validador para maximizar a computação na memória (e ignorar o problema de inchaço do estado), e 3) reduzir a latência e gargalos de consenso claramente superam os sistemas que dependem de uma descentralização extensiva e consenso entre os nós.

Ao buscar um equilíbrio entre escalabilidade e minimização da confiança, está se tornando aparente que o objetivo das camadas de execução não deve ser otimizar para descentralização cegamente, nem a execução deve sempre ser 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, essa abordagem envolve compensações, potencialmente impactando 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 “mínima descentralização 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 monitorado, onde os validadores enfrentam repercussões significativas por conduta indevida, pode manter a segurança e a vivacidade sem a necessidade de uma descentralização excessiva (h/t Sreeram).

Tais modelos de governança já estão sendo testados em aplicações práticas. Por exemplo, rollups como Arbitrum estão explorando sistemas de governança ou comitês para impor regras de ordenação de transações e seleção de líderes, e estão considerando mecanismos nos quais sequenciadores usam dados onchain para manter as políticas de ordenação de transações.

Apesar desses avanços, não há uma "fronteira ótima de pareto" 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 está para ser visto se essas otimizações atrairão desenvolvedores focados em criar aplicações resistentes à censura e em que medida a resistência à censura permanece um valor central na indústria.

*denota uma empresa do portfólio da Archetype

Aviso Legal：

1. Este artigo é reproduzido a partir de [espelhoEncaminhar 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, entre em contato com o Gate Learnequipe, e eles lidarão com isso prontamente.

2. Responsabilidade do Gate: 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.