Dominando o Último Estágio da Escalabilidade das Blockchains: O Crescimento do Estado

Aviso: Este artigo foi originalmente publicado no blog do CEO e co-fundador da Fuel Nick Dodson em 30 de Janeiro de 2024, e também no blog da Fuel em 1 de Fevereiro de 2024. O artigo foi traduzido de seu idioma original para sua conveniência. Embora nos esforcemos para manter a precisão, pode haver pequenos erros ou diferenças de interpretação. Agradecemos sua compreensão e o incentivamos a consultar a fonte original para obter informações detalhadas.

Reidratação Nativa do Estado, Técnicas de Minimização do Estado e um Modelo de Transação Minimizador do Estado.

Recentemente, fiz várias palestras sobre o crescimento do estado da blockchain, e vendo também muitas discussões sobre o tema no X (Twitter) pensei que escrever sobre o assunto acrescentaria em minhas apresentações e abordagens dentro da Fuel.

Então, vamos direto ao ponto. Um dos maiores obstáculos enfrentados pelas blockchains é o crescimento do estado das redes — um problema que, se não for deixado de lado, pode destruir a escalabilidade e eficiência das mesmas. Neste artigo vamos explorar o que é o crescimento do estado, por quê ele é um problema, e as soluções existentes para manter as blockchains enxutas e funcionais à medida que escalam.

Entendo os gargalos de processamento de uma blockchain

Antes de mergulhar nas complexidades do aumento do estado da rede, vamos observar os três componentes tipicamente associados aos gargalos de escalabilidade em blockchains:

• Execução: O trabalho realizado pela CPU para garantir a sincronização, validação e criação de blocos de maneira apropriada. ✅ Resolvido: há muitas opções que solucionam essa questão, como máquinas virtuais mais eficientes (FuelVM, SVM, MoveVM), execução paralela de transações (usando todos os cores da CPU), e melhores pré-compilados (funções predefinidas em uma VM).

• Dados (armazenamento e disponibilidade): Os dados reais das transações que permitem transições de estado na blockchain. Eles são essenciais para que outros nós possam sincronizar com a rede e para permitir a comprovação de fraudes ou validações em rollups. ✅ Resolvido: há algumas opções que solucionam essa questão, como o EIP-4844, sharding e camadas de disponibilidade de dados externos como Celestia, EigenDA e Avail.

• Estado: A informação armazenada ativamente em um banco de dados local que garante a validação adequada da cadeia e transições de estado. Estas informações estão frequentemente no caminho crítico (hot path) de processamento em blockchains, necessitando de muito acesso aleatório ao disco e gerando muitas entradas e saídas, tipicamente a parte mais lenta do processamento depois das assinaturas e hashing. ❌ Não Resolvido.

Cada um desses componentes desempenha um papel crucial na operação de uma blockchain, mas é principalmente o estado aquele que mais nos interessa quando discutimos questões de escalabilidade.

O desafio do crescimento do estado da rede

O crescimento do estado da rede se refere ao acúmulo crescente e constante de dados que precisam ser armazenados e gerenciados pelos nós em uma blockchain. Como é algo que leva tempo, é frequentemente tratado como um problema futuro. No entanto, à medida que a bola de neve crescente se aproxima do limite, a operação dos nós é subitamente sobrecarregada e torna-se um gargalo para a escalabilidade — podendo ser comprovadamente fatal quando impede uma adoção mais ampla ou desacelera a inovação da rede.

https://x.com/peter_szilagyi/status/1706563595264295411

Por favor, pare de dizer isso. Ethereum não é lento por causa do Geth. Você poderia aumentar o limite de gás em 10 vezes e o Geth ficaria perfeitamente bem. Ethereum é lento porque o estado cresce loucamente. Seja Geth ou qualquer outro cliente, é a mesma coisa. Você precisa armazenar esse estado em algum lugar.

O crescimento do estado leva à blockchains inchadas, onde transações mais lentas e maiores custos de armazenagem tornam-se o padrão, limitando a escalabilidade e acessibilidade da rede. Soa familiar? Provavelmente porque combater o crescimento do estado será o proximo catalizador para impulsionar a economia das rollups, assim como o problema anterior, as taxas de transferências, deu inicio à revolução das rollups.

Mas… as rollups não resolvem o crescimento do estado?

As rollups abrem as portas da Ethereum para um mundo novo. As soluções existentes resolvem a camada de execução, sendo que algumas soluções modulares lidam também com a disponibilidade de dados. Mas se elas não resolverem a questão central do estado da rede, temos novamente um jogo de soma zero. Qualquer blockchain projetada hoje — rollup ou não — que não tenha uma estratégia pra endereçar o crescimento do estado acabará, invariavelmente, se limitando devido ao inchaço do estado. E não importa o seu ambiente de execução ou de dados.

Comparando os projetos de estado

Para ilustrar o problema, vamos comparar a gestão de estado do Bitcoin e da Ethereum:

• Estado do Bitcoin: Utiliza um conjunto de UTXO (Output de Transação Não Gasta), que é mais simples e tradicionalmente mais fácil de gerenciar, mas com uma programabilidade limitada.

• Estado da Ethereum: Inclui saldos de contas, código de contratos inteligentes e estado dos contratos inteligentes — abrangendo saldos de tokens, aprovações e mais.

O modelo de gestão de estado do Bitcoin é simplificado, mas limitado em escopo. O estado do Bitcoin é gerenciado por meio das saídas de transações individuais que podem apenas gastas ou não gastas. Seu modelo UTXO (Output de Transação Não Gasta) mantém um estado claro através de saídas de transações que estão não gastas e prontas para transações futuras, ou gastas e, portanto, arquivadas no histórico da blockchain. Isso torna o modelo UTXO relativamente mais gerenciável e garante que o estado não cresça descontroladamente a cada transação. No entanto, essa simplicidade tem como contrapartida a programabilidade limitada, em comparação ao sistema Turing completo da Ethereum.

Na Ethereum, encontramos um rico ecossistema de saldos de contas, códigos de contratos inteligentes e uma miríade de estados de contratos — cada interação sendo um fio em um tecido sempre crescente de dados. Essa constante evolução do estado, embora seja um testemunho da versatilidade do Ethereum, apresenta desafios significativos de escalabilidade. À medida que o estado se infla com cada execução de contrato inteligente e transação, leva a uma sobrecarga com maiores requisitos de armazenamento e tempos de processamento mais lentos, o que, por sua vez, sufoca a inovação e a adoção de novos usuários.

O contraste entre as abordagens de gestão de estado do Bitcoin e da Ethereum ilustra um trade-off fundamental no design de blockchains: a simplicidade e eficiência da gestão de estado versus a complexidade e potencial das operações on-chain.

As soluçoes propostas para o crescimento do estado

Várias estratégias foram propostas para abordar o crescimento do estado:

a. Deixar o estado crescer

Aceitar o crescimento do estado em troca de um maior uso de largura de banda. Esta não é uma boa opção, pois impõe requisitos mais altos para os nós (full nodes), o que reduz a descentralização da rede.

https://x.com/aeyakovenko/status/1699460999697555512

1. apenas deixe o estado crescer. Realizamos testes internos que alcançaram 15 bilhões de contas com snapshots de apenas 700GB, com a RAM mantendo-se estável em menos de 32GB. Isso acontece porque cada transação especifica todo o estado de que precisa para execução. As transições da EVM podem acessar qualquer estado sob demanda. Essa busca sob demanda é cara e piora com o crescimento do estado. Então, na @solana o tamanho do estado não afeta a execução da VM, apenas impacta o tamanho do snapshot, que principalmente afeta a velocidade de restart do nó. Basicamente, a rede poderia dobrar com segurança o tamanho do snapshot a cada 2 anos sem enfrentar grandes problemas, assumindo que os validadores atualizem seus discos de armazenamento a cada 2 anos.

b. Aluguel do Estado

Cobrar taxas pelo armazenamento de dados do estado, com o risco potencial de problemas de "apodrecimento da árvore" (quando todos os elementos de estado estão em uma árvore e algumas das folhas são esquecidas, corrompendo a ramificação), entre outros problemas.

c. Ausência de Estado

Os nós completos não precisariam armazenar o estado, confiando em provas de estado incluídas com transações e blocos. Essencialmente, movendo o estado da primeira camada para as rollups. Esta é a direção que a Ethereum está tomando, mas há muitas questões não respondidas sobre quão eficiente e sustentável será isso.

https://vitalik.eth.limo/general/2021/06/18/verkle.html

d. Desmerkalização do Estado

Uma abordagem técnica para gerenciar os dados do estado de forma diferente. Efetivamente, você estaria usando nós completos para validar tudo, ou amostrar coisas com clientes leves e esquecer completamente a árvore de estado.

https://x.com/TrustlessState/status/1699457615615402147

e. Compressão do estado no nível da aplicação

Usando técnicas de call-data para comprimir os dados do estado. Essencialmente, você está trocando estado por largura de banda. Altas demandas de largura de banda levam a redes restritas, com implicações pesadas sobre a robustez e eficiência da infraestrutura.

Exemplo 1: Uniswap V3 staker (imagem do lado esquerdo). O estado precisa ser reidratado através da largura de banda. Isso possibilita um design minimizado do estado, e o call-data é muito mais barato do que o armazenamento na Ethereum.

Exemplo 2: NFTs Compactados (imagem do lado direito). Merkalizar os dados de propriedade de NFT e armazenar a raiz no estado.

And Now…

f. Reidratação Nativa do Estado

A Tese da Fuel

Existem várias vantagens em usar o modelo baseado em UTXO:

• Árvores de Estado Localizadas: Não existe uma árvore do estado global, apenas árvores de estado locais para cada contrato inteligente.

• Ativos Nativos: Todas as transferências de ativos afetam apenas um único elemento do estado. Assets nativos podem ser utilizados para representar não apenas valores monetários, mas também estados não monetários, como a propriedade de ativos digitais (por exemplo, NFTs para representar a propriedade de arte digital ou outros itens colecionáveis). Eles não precisam ser merkalizados, simplificando o estado.

• Estado de Não Aprovação: Elimina mudanças de estado desnecessárias provenientes das funções Approve e transferFrom.

O modelo UTXO permite tudo isso enquanto mantém a verificabilidade e clientes leves criptográficos ricos — criando um "modo rápido" para a verdadeira interoperabilidade (mais sobre isso em um post futuro). A filosofia principal por trás da Fuel é: usar mais largura de banda e execução, ao mesmo tempo em que se usa menos estado. Mas como?

Reidratação Nativa do Estado

A reidratação nativa do estado descreve os métodos que os desenvolvedores podem usar para desidratar ou compartimentar o estado na Fuel. Os dados compactados são reidratados utilizando a largura de banda disponível, o que permite reacessar o estado quando necessário. Isso seria oposto à abordagem convencional da Ethereum ("usar contratos inteligentes para tudo"), que se baseia em consultas ao estado do contrato.

Essa nova abordagem:

• Armazena apenas root hashes / mudanças de estado

• Disponibiliza os dados utilizando a largura de banda para reidratar o estado

• Fornece técnicas de minimização do estado para o desenvolvedor se aproveitar disso

Técnicas de Minimização do Estado

O foco é maximizar a largura de banda e execução em detrimento do armazenamento do estado, e a Fuel oferece ao desenvolvedor várias maneiras de realizar tarefas para além do simples armazenamento em contratos inteligentes:

• Scripts: A lógica efêmera é incluída nas transações, e não armazenada no estado. Diferentemente das transações EVM, que podem chamar diretamente um contrato (mas apenas um único contrato por vez), as transações na Fuel executam um script que pode chamar zero ou mais contratos.

• Predicados: São contratos leves e sem estado. O predicado é um mecanismo novo e puro para autorizar transações. Um predicado só pode acessar os dados na transação; ele não pode visualizar o estado atual da cadeia. Os predicados podem ser usados, entre outras coisas, para habilitar a abstração de conta nativamente (sem estado).

Saiba mais sobre Predicados neste post do Ryan Sproule: um predicado não é um contrato inteligente, mas ainda permite uma lógica de autenticação personalizada para gastar tokens. Isso significa que predicados podem ser gastos sem a necessidade de uma chave privada, ao contrário de qualquer transação EVM. Na prática, isso significa que os usuários podem construir predicados que podem ser gastos sem permissão (permissionless). Isso, quando combinado com o conceito de scripts da Fuel, turbina a experiência do usuário para interagir com contratos inteligentes.

O modelo de transações de estado minimizado

A combinação de técnicas de minimização de estado com o modelo UTXO nos permite criar um novo Modelo de Transação Flexível. Isso proporciona mais opções para formar transações complexas envolvendo múltiplas partes, sem a necessidade de usar contratos inteligentes para acessar o estado.

Como fica isso na prática?

Um exemplo de uma carteira de contrato inteligente (com apenas um elemento de estado de 32 bytes):

• O estado do contrato é armazenado em um único hash raiz de uma UTXO.

• O estado é reidratado através da largura de banda se necessário.

• As UTXOs asseguram a verificabilidade por clientes leves sem necessidade de uma árvore de Merkle global.

• Requer apenas uma leitura de E/S.

• O estado pode ser modificado quando a UTXO do estado é gasta.

• Não há perda de funcionalidade da carteira de contrato inteligente em comparação com a Ethereum.

• A largura de banda e a execução têm prioridade sobre o estado.

• Tudo é realizado nativamente (através de predicados).

A arquitetura da Fuel é projetada para incorporar todas essas características juntamente com uma execução de estado minimizada, criando um pacote especialmente desenvolvido para rollups do Ethereum. A Fuel introduz novas capacidades no ecossistema Ethereum enquanto preserva a segurança por meio do settlement final na camada 1.

Enquanto a luta contra o crescimento do estado continua, ferramentas e estratégias como as da Fuel oferecem esperança para um futuro escalável e eficiente. Como diz o provérbio, "a necessidade é a mãe de todas as invenções," e no mundo do blockchain, a necessidade de superar o crescimento do estado levou, de fato, a uma solução inovadoras.