Fragmentação de estado

O que é fragmentação de estado em cripto?

A fragmentação de estado é um modelo de escalabilidade de blockchain que divide o estado ativo da rede em partes menores, chamadas shards, para que diferentes grupos de validadores possam processar e armazenar diferentes partes da blockchain em paralelo.

Em cripto, estado é o registro atual de contas, saldos, dados de contratos inteligentes, slots de armazenamento, informações de validadores e outros valores necessários para processar novas transações.

Sharding significa dividir um sistema grande em seções menores para que toda a rede não precise executar todas as tarefas ao mesmo tempo.

A documentação oficial de escalabilidade do Ethereum descreve o sharding como o processo de dividir um banco de dados para que subconjuntos de validadores sejam responsáveis por shards individuais, em vez de acompanhar tudo.

A fragmentação de estado aplica essa ideia diretamente ao estado da blockchain.

Em vez de cada validador armazenar e executar todo o estado de toda a blockchain, cada shard pode manter apenas uma parte do estado.

Isso pode aumentar o throughput, pois vários shards podem processar transações ao mesmo tempo.

Também pode reduzir a demanda de hardware, pois cada nó pode não precisar armazenar todo o estado ativo.

No entanto, a fragmentação de estado é difícil porque os aplicativos de blockchain frequentemente precisam interagir entre shards.

Em termos simples, a fragmentação de estado busca escalar uma blockchain dividindo seu banco de dados ativo e sua carga de execução entre vários grupos de shards paralelos.

Por que a fragmentação de estado é importante

A fragmentação de estado é importante porque blockchains de contratos inteligentes podem se tornar caras de operar à medida que o uso cresce.

Cada nova conta, saldo de token, contrato, NFT, posição de liquidez, registro de governança e slot de armazenamento pode aumentar a quantidade de estado ativo que a rede precisa manter.

Se cada validador precisar armazenar e executar todo o estado para sempre, a rede poderá se tornar mais difícil de ser verificada de forma independente por pessoas comuns.

Isso pode enfraquecer a descentralização, pois apenas grandes operadores podem conseguir executar nós completos.

A fragmentação de estado busca resolver esse problema permitindo que a rede escale horizontalmente.

Escalabilidade horizontal significa adicionar mais grupos de validadores e mais shards, em vez de exigir que cada nó se torne mais poderoso.

A página oficial de artigos da NEAR descreve o Nightshade como um modelo de sharding no qual a blockchain é dividida em várias cadeias paralelas, ou shards, para escalar horizontalmente conforme a demanda.

Essa abordagem é atraente porque pode aumentar a capacidade sem exigir que cada nó processe todas as transações.

Portanto, a fragmentação de estado não é apenas uma melhoria de velocidade.

Ela também é uma estratégia de descentralização, pois manter os requisitos dos nós em níveis gerenciáveis ajuda mais participantes a verificar a rede.

Como funciona a fragmentação de estado

Uma blockchain com fragmentação de estado divide o estado global em vários shards.

Cada shard é responsável por um subconjunto de contas, contratos, objetos ou entradas de estado.

Os validadores podem ser atribuídos a um shard, a vários shards ou a comitês de shards rotativos, dependendo do modelo do protocolo.

Transações que afetam apenas um shard geralmente podem ser processadas dentro desse shard.

Transações que afetam vários shards exigem comunicação entre shards.

Um coordenador, beacon chain, cadeia principal, camada global de consenso ou protocolo de comunicação entre shards pode ajudar a manter o sistema consistente.

A rede deve garantir que nenhum shard aceite transações inválidas.

A rede também deve garantir que uma ação entre shards não crie gasto duplo, mensagens perdidas ou estado inconsistente.

Por isso, a fragmentação de estado é mais complexa do que simplesmente operar várias blockchains separadas.

Uma verdadeira cadeia com fragmentação de estado deve fazer vários shards se comportarem como um sistema de blockchain único e coerente.

Fragmentação de estado vs. fragmentação de transações

A fragmentação de transações divide o processamento de transações entre diferentes grupos.

A fragmentação de estado divide o estado real da blockchain entre diferentes grupos.

Um sistema pode fragmentar transações sem fragmentar totalmente o estado, caso todos os validadores ainda precisem conhecer todo o estado.

A fragmentação de estado é mais profunda porque cada shard armazena e atualiza apenas parte do banco de dados ativo.

Isso pode criar benefícios de escalabilidade mais fortes, mas também desafios de coordenação maiores.

Por exemplo, um pagamento de uma conta para outra conta no mesmo shard pode ser simples.

Um pagamento de um shard para outro precisa de um sistema seguro de mensagens ou recibos entre shards.

Uma chamada de contrato inteligente que afeta contratos em dois shards pode exigir execução assíncrona, bloqueios, recibos ou outras regras de consistência.

A fragmentação de transações melhora o throughput ao dividir o trabalho.

A fragmentação de estado melhora tanto o throughput quanto a escalabilidade de armazenamento ao dividir os dados dos quais o trabalho depende.

Fragmentação de estado vs. fragmentação de dados

A fragmentação de estado é diferente da fragmentação de dados.

A fragmentação de estado divide o estado de execução ativo de uma blockchain.

A fragmentação de dados se concentra em disponibilizar dados de transações em partes menores ou paralelas para que sistemas de escalabilidade possam publicar e verificar dados com menor custo.

Essa distinção é importante porque o roteiro moderno de escalabilidade do Ethereum se concentra na disponibilidade de dados, em vez da fragmentação de estado tradicional.

A documentação do danksharding do Ethereum afirma que nem o danksharding nem o proto-danksharding seguem o modelo tradicional de sharding que divide a blockchain em várias partes.

Essa documentação explica que o danksharding é projetado em torno de grandes blobs de dados para rollups, em vez de dividir a Ethereum Mainnet em shards de execução tradicionais.

Isso significa que os usuários não devem presumir que toda menção ao sharding do Ethereum se refere à fragmentação de estado.

Discussões mais antigas sobre o roteiro do Ethereum incluíam ideias de fragmentação de execução e de estado.

A escalabilidade moderna do Ethereum usa rollups, blobs, pesquisas sobre amostragem de disponibilidade de dados e conceitos de danksharding, em vez de um modelo tradicional de execução com vários shards.

A fragmentação de estado e a fragmentação de dados são ambas ideias de escalabilidade, mas resolvem gargalos diferentes.

Fragmentação de estado vs. rollups

Os rollups escalam uma blockchain executando muitas transações fora da camada base e publicando dados ou provas de volta na camada base.

A fragmentação de estado escala uma blockchain dividindo o estado e a execução da camada base entre shards.

Os rollups podem ser mais fáceis de adicionar a uma cadeia existente porque não exigem que a camada base divida seu próprio estado de execução.

A fragmentação de estado é uma alteração arquitetural mais profunda na camada base.

Os rollups ainda precisam de disponibilidade de dados, liquidação e verificação de provas da cadeia base.

Cadeias com fragmentação de estado precisam de atribuição de shards, comunicação entre shards, segurança dos shards e finalidade compartilhada.

A documentação de disponibilidade de dados do Ethereum explica que a disponibilidade de dados é importante porque os rollups precisam que os dados das transações estejam disponíveis para que outras pessoas possam verificar ou reconstruir o estado do rollup.

Por isso, o roteiro atual do Ethereum oferece suporte à escalabilidade de rollups com dados em blobs, e não à fragmentação de estado tradicional.

A fragmentação de estado ainda pode ser usada por outros modelos de Layer 1.

A principal diferença é que os rollups separam a execução em sistemas de Layer 2, enquanto a fragmentação de estado divide a execução e o estado dentro da própria Layer 1.

Por que a fragmentação de estado é difícil

A fragmentação de estado é difícil porque as blockchains precisam permanecer seguras, consistentes e descentralizadas enquanto dividem o trabalho.

Se um shard tiver poucos validadores, atacantes poderão ter mais facilidade para atacar esse shard.

Se os validadores não forem atribuídos de forma aleatória e segura, atacantes poderão concentrar poder em um shard.

Se as mensagens entre shards forem lentas, os aplicativos poderão parecer fragmentados.

Se as mensagens entre shards não forem seguras, os usuários poderão enfrentar riscos de gasto duplo ou estado inconsistente.

Se os desenvolvedores precisarem considerar constantemente a localização dos shards, o desenvolvimento de aplicativos se tornará mais difícil.

Se os usuários precisarem entender shards manualmente, a experiência do usuário piorará.

O estudo acadêmico Building Blocks of Sharding Blockchain Systems identifica componentes importantes de sharding, como seleção de nós, aleatoriedade, atribuição de nós, consenso dentro do shard, processamento de transações entre shards, reconfiguração de shards e mecanismos de incentivo.

Isso mostra que a fragmentação de estado não é um único recurso.

Ela é uma arquitetura completa de sistema com muitas partes móveis.

Shards

Um shard é uma partição do estado da blockchain e do ambiente de execução.

Cada shard pode conter um subconjunto de contas, contratos, objetos, armazenamento ou transações.

Em um modelo simples, as contas podem ser atribuídas a shards com base em intervalos de endereços, valores de hash ou localizações explícitas de contas.

Em um modelo mais avançado, os limites dos shards podem mudar ao longo do tempo por meio de resharding.

Um shard deve ser capaz de processar transações locais sem solicitar aprovação de todos os outros shards.

Esse processamento paralelo é o principal benefício de escalabilidade.

No entanto, os shards não podem ser completamente isolados se os usuários e aplicativos precisarem interagir em toda a rede.

Um bom modelo de sharding deve tornar os shards independentes o suficiente para desempenho, mas conectados o suficiente para usabilidade.

Esse equilíbrio é difícil porque independência excessiva fragmenta a rede, enquanto coordenação excessiva reduz o benefício de escalabilidade.

Portanto, um shard é simultaneamente uma unidade de escalabilidade e um desafio de coordenação.

Validadores de shards

Os validadores de shards são validadores atribuídos para verificar, produzir ou aprovar atividades em um shard específico.

Em alguns modelos, os validadores alternam entre shards para reduzir o risco de captura de longo prazo de um shard.

Em outros modelos, os validadores podem acompanhar apenas determinados dados de shards ou fornecer validação sem estado com testemunhas.

A atribuição de validadores é essencial porque cada shard deve permanecer seguro, mesmo que apenas um subconjunto da rede o valide diretamente.

Se um atacante puder prever ou influenciar a atribuição de validadores, poderá tentar controlar um shard.

Por isso, a aleatoriedade é importante em muitos sistemas de sharding.

Os incentivos dos validadores também são importantes, pois os validadores de shards devem ser recompensados pela participação honesta e punidos por comportamentos desonestos.

A fragmentação de estado não elimina a necessidade de consenso.

Ela cria várias responsabilidades menores de consenso que ainda precisam se conectar à segurança de toda a rede.

A segurança de uma cadeia com fragmentação de estado depende fortemente de como os validadores são atribuídos, alternados, monitorados e protegidos economicamente.

Transações entre shards

Uma transação entre shards é uma transação que afeta o estado em mais de um shard.

As transações entre shards são uma das partes mais difíceis da fragmentação de estado.

Uma transferência simples dentro de um shard pode ser processada localmente.

Uma transferência de uma conta em um shard para uma conta em outro shard deve coordenar os dois shards.

Uma chamada de contrato inteligente que envolve vários shards pode ser ainda mais complexa.

O sistema deve garantir que o shard de origem e o shard de destino concordem sobre o que ocorreu.

Também deve garantir que os fundos não sejam gastos duas vezes e que os efeitos dos contratos ocorram na ordem correta.

Alguns sistemas usam recibos assíncronos, nos quais um shard registra uma ação de saída e outro shard aplica posteriormente o resultado de entrada.

Outras pesquisas exploram execução síncrona entre shards, confirmação em duas fases ou coordenação baseada em provas.

O modelo de transações entre shards frequentemente determina se a fragmentação de estado parece fluida ou fragmentada aos usuários.

Execução assíncrona

Execução assíncrona significa que as ações entre shards não ocorrem instantaneamente em uma única etapa global.

Em vez disso, um shard pode criar uma mensagem ou recibo que outro shard processa posteriormente.

Isso pode melhorar a escalabilidade porque os shards não precisam parar e coordenar todas as ações ao mesmo tempo.

No entanto, a execução assíncrona muda a forma como os desenvolvedores criam aplicativos.

Um contrato pode não conseguir chamar outro shard e receber o resultado imediatamente na mesma transação.

Os desenvolvedores podem precisar criar fluxos de trabalho em torno de callbacks, recibos, liquidação atrasada ou transições de estado em várias etapas.

Isso pode tornar DeFi entre shards, jogos, marketplaces e aplicativos compostos mais difíceis.

O sharding assíncrono é poderoso, mas pode enfraquecer a composabilidade simples que os usuários esperam de ambientes de contratos inteligentes de shard único.

O trade-off é velocidade e paralelismo versus simplicidade de aplicativos síncronos.

Um bom ecossistema com fragmentação de estado precisa de ferramentas para desenvolvedores que facilitem o uso seguro da execução assíncrona.

Composabilidade atômica

Composabilidade atômica significa que várias ações de contratos inteligentes podem ocorrer juntas como uma única transação indivisível.

Se qualquer parte falhar, toda a transação falha.

Sistemas de contratos inteligentes de shard único geralmente facilitam a composabilidade atômica porque todo o estado relevante está disponível em um ambiente de execução.

A fragmentação de estado pode tornar a composabilidade atômica mais difícil quando os contratos estão em shards diferentes.

Uma negociação DeFi pode precisar interagir com um protocolo de empréstimos, pool de liquidez, oráculo e cofre em uma única transação.

Se esses contratos estiverem em shards diferentes, a execução síncrona poderá ser difícil ou cara.

Esse é um dos motivos pelos quais a fragmentação de estado cria desafios de design para DeFi.

Alguns sistemas fragmentados podem incentivar que contratos relacionados permaneçam no mesmo shard.

Outros sistemas podem fornecer ferramentas especiais de comunicação entre shards.

A composabilidade atômica é um dos principais trade-offs que usuários e desenvolvedores devem entender ao estudar fragmentação de estado.

Fragmentação de estado e contratos inteligentes

Os contratos inteligentes tornam a fragmentação de estado mais difícil porque podem depender de estado compartilhado.

Um sistema simples de pagamentos pode atribuir contas a shards e enviar mensagens entre eles.

Um ecossistema de contratos inteligentes precisa lidar com chamadas de contratos, leituras e gravações de armazenamento, transferências de tokens, aprovações, liquidações, swaps e transações compostas.

Se todo contrato puder chamar qualquer outro contrato de forma síncrona, a rede poderá perder grande parte do benefício do sharding.

Se as chamadas entre shards forem assíncronas, os desenvolvedores precisarão de um modelo de programação diferente.

Por isso, plataformas de contratos inteligentes fragmentadas devem projetar cuidadosamente a alocação de contas, a implantação de contratos, a troca de mensagens e as ferramentas para desenvolvedores.

A fragmentação de estado é mais simples para transferências básicas entre contas do que para sistemas DeFi altamente compostos.

Também é mais simples quando os aplicativos podem ser agrupados naturalmente em shards.

Por exemplo, um jogo ou ambiente semelhante a uma appchain pode manter a maior parte da atividade dentro de um shard.

Aplicações financeiras altamente interconectadas podem exigir um modelo mais complexo entre shards.

Fragmentação de estado e NEAR

A NEAR é um dos exemplos mais conhecidos de blockchain projetada em torno de sharding.

A documentação oficial da NEAR afirma que o sharding Nightshade permite escalabilidade linear de throughput à medida que a quantidade de validadores cresce.

Nightshade é o modelo de sharding da NEAR.

A página oficial de artigos da NEAR descreve o Nightshade como um modelo em que tanto o estado quanto o processamento são divididos entre shards em sua forma atualizada.

A arquitetura da NEAR é importante porque demonstra a fragmentação de estado como uma direção de projeto em uso, e não apenas como um conceito de pesquisa.

A NEAR também trabalhou em validação sem estado, que altera a forma como os validadores participam da validação de shards.

A publicação de lançamento do NEAR Nightshade 2.0 afirma que o Nightshade 2.0 introduziu a validação sem estado na NEAR Mainnet em agosto de 2024.

A validação sem estado pode reduzir a quantidade de estado que um validador precisa manter localmente para um shard.

Isso mostra como a fragmentação de estado e a validação sem estado podem ser combinadas para melhorar a escalabilidade e a participação de nós.

Fragmentação de estado e Ethereum

O Ethereum é importante para a história da fragmentação de estado porque os primeiros roteiros de escalabilidade do Ethereum discutiam extensivamente o sharding.

No entanto, o roteiro atual do Ethereum não se concentra na fragmentação tradicional de execução ou de estado para a Mainnet.

A página oficial de danksharding do Ethereum afirma que nem o proto-danksharding nem o danksharding seguem o modelo tradicional de sharding.

Em vez disso, o Ethereum agora se concentra em escalar rollups ao fornecer disponibilidade de dados mais barata por meio de blobs e do futuro danksharding.

Essa distinção é importante para SEO e educação dos usuários, pois muitos artigos antigos ainda descrevem o Ethereum como avançando em direção a cadeias de shards tradicionais.

Essas descrições antigas podem ser enganosas se forem apresentadas como fatos do roteiro atual.

A direção atual da escalabilidade do Ethereum é centrada em rollups.

Isso significa que os sistemas de Layer 2 realizam a maior parte da execução, enquanto o Ethereum fornece liquidação, segurança e melhorias de disponibilidade de dados.

A fragmentação de estado continua sendo um conceito importante de blockchain, mas não deve ser descrita como o plano atual de execução da Mainnet do Ethereum.

Para uma educação cripto precisa, o Ethereum deve ser usado como exemplo de como a pesquisa sobre sharding evoluiu, e não como uma implantação atual de fragmentação de estado.

Fragmentação de estado e validação sem estado

Validação sem estado significa que um validador pode verificar a execução de um bloco ou shard sem armazenar localmente todo o estado relevante.

Em vez disso, o validador recebe testemunhas ou provas que incluem os dados de estado necessários para a verificação.

Esse conceito pode funcionar com fragmentação de estado, pois os validadores podem não querer armazenar o estado de todos os shards.

Também pode tornar a validação de shards mais flexível, pois os validadores podem verificar o trabalho com requisitos menores de armazenamento local.

O Nightshade 2.0 da NEAR é um exemplo prático de validação sem estado adicionada a uma arquitetura de sharding.

Pesquisas do Ethereum também exploraram clientes sem estado e testemunhas menores por meio de alterações nos compromissos de estado.

Validação sem estado não é igual à fragmentação de estado.

A fragmentação de estado divide o estado entre shards.

A validação sem estado reduz a quantidade de estado que um validador precisa armazenar para verificar um bloco ou shard.

Juntas, elas podem ajudar a reduzir os requisitos de hardware dos nós, preservando a verificação.

Fragmentação de estado e disponibilidade de dados

Disponibilidade de dados é a garantia de que os dados necessários para verificar ou reconstruir transições de estado estão disponíveis para a rede.

A fragmentação de estado não pode ser segura se os validadores não conseguirem acessar os dados necessários para verificar blocos de shards.

Um produtor malicioso de shard poderia ocultar dados e impedir que outras pessoas verificassem se a transição de estado do shard é válida.

Por isso, a disponibilidade de dados é um problema central em sistemas fragmentados.

Uma blockchain fragmentada pode precisar de amostragem de disponibilidade de dados, codificação de apagamento, comitês, provas de fraude, provas de validade ou outros mecanismos para dificultar ataques de ocultação de dados.

A documentação de disponibilidade de dados do Ethereum explica que disponibilidade de dados não é o mesmo que armazenamento de dados, pois se concentra em saber se os dados foram suficientemente publicados para verificação.

Esse conceito se aplica amplamente a sistemas de escalabilidade, incluindo rollups e cadeias fragmentadas.

A fragmentação de estado aumenta a importância da disponibilidade de dados porque cada shard pode produzir dados nos quais outras partes da rede precisam confiar.

Se os dados de um shard não estiverem disponíveis, mensagens entre shards e o consenso global poderão se tornar inseguros.

Um modelo robusto de fragmentação de estado deve resolver tanto a divisão de execução quanto a disponibilidade de dados.

Fragmentação de estado e segurança

A segurança na fragmentação de estado depende da atribuição de shards, da honestidade dos validadores, da aleatoriedade, das provas entre shards, da finalidade e dos incentivos.

Um único shard não deve se tornar fácil de corromper apenas porque menos validadores foram atribuídos a ele.

Isso às vezes é chamado de problema de tomada de controle de um único shard.

Se um atacante puder controlar um shard, poderá tentar criar transações inválidas, roubar fundos ou corromper mensagens entre shards.

Os protocolos reduzem esse risco por meio de atribuição aleatória de validadores, comitês rotativos, slashing, segurança compartilhada, provas de fraude, provas de validade ou regras de finalidade global.

A segurança também deve lidar com atacantes adaptativos que tentam corromper validadores após conhecerem sua atribuição de shard.

A reconfiguração de shards deve ser projetada cuidadosamente, pois mover validadores e estado entre shards pode criar janelas de ataque.

Transações entre shards precisam de sistemas de prova que impeçam um shard de mentir para outro.

A fragmentação de estado pode escalar uma rede, mas também aumenta a quantidade de pontos em que o design do protocolo pode falhar.

Para os usuários, a questão principal é se a cadeia fragmentada mantém cada shard tão seguro quanto a rede como um todo exige.

Fragmentação de estado e descentralização

A fragmentação de estado pode apoiar a descentralização ao reduzir a carga de recursos sobre nós individuais.

Se um nó não precisar armazenar e executar todo o estado global, mais participantes poderão conseguir entrar na rede.

Isso pode ajudar a evitar um futuro em que apenas grandes centros de dados possam verificar a cadeia.

No entanto, a fragmentação de estado também pode criar riscos de descentralização se apenas uma infraestrutura especializada conseguir lidar com a coordenação entre shards.

Se os usuários dependerem de um pequeno número de provedores de RPC para acompanhar todos os shards, a camada de aplicativos poderá se tornar centralizada.

Se bridges ou roteadores entre shards se tornarem gargalos, a atividade econômica poderá se concentrar nesses serviços.

Se os validadores precisarem de infraestrutura complexa para participar, o conjunto de validadores ainda poderá se centralizar.

Uma boa fragmentação de estado deve reduzir a carga de cada nó sem criar novas dependências centralizadas em outros pontos.

A descentralização deve ser medida entre validadores, nós completos, clientes, provedores de RPC, bridges, carteiras e infraestrutura de aplicativos.

A fragmentação de estado só ajuda se todo o sistema permanecer aberto e verificável.

Fragmentação de estado e experiência do usuário

Idealmente, a fragmentação de estado deve ser invisível para os usuários.

Um usuário não deveria precisar saber qual shard mantém sua conta ou qual shard contém um contrato inteligente.

Uma carteira deve encaminhar transações corretamente sem exigir seleção manual de shard.

Um dApp deve explicar claramente atrasos ou etapas entre shards quando eles ocorrerem.

Se os usuários precisarem gerenciar manualmente endereços de shards, saldos de gas por shard e tempos entre shards, a adoção poderá ser prejudicada.

As transferências entre shards podem levar mais tempo que transferências no mesmo shard, dependendo do modelo do protocolo.

Interações de contratos inteligentes entre shards também podem exigir mais confirmações ou callbacks assíncronos.

Boas interfaces de usuário podem ocultar grande parte dessa complexidade.

No entanto, os usuários ainda devem entender que a fragmentação de estado pode afetar o tempo das transações, a composabilidade, a liquidez e o design dos aplicativos.

Os melhores sistemas fragmentados parecem uma única cadeia, embora operem internamente como vários ambientes de execução paralelos.

Fragmentação de estado e desenvolvedores

Os desenvolvedores que criam em cadeias com fragmentação de estado precisam entender onde está o estado de seus aplicativos.

Se a plataforma expõe os limites dos shards, os desenvolvedores podem precisar escolher onde os contratos serão implantados.

Se as chamadas entre shards forem assíncronas, os desenvolvedores precisarão projetar para resultados atrasados e fluxos de trabalho parciais.

Se os usuários puderem vir de shards diferentes, os desenvolvedores deverão lidar com roteamento de mensagens e movimentação de saldos.

Se a liquidez estiver dividida entre shards, aplicativos DeFi poderão precisar de roteamento ou agregação especiais.

Os testes também são mais complexos porque os desenvolvedores precisam testar casos no mesmo shard e entre shards.

O monitoramento pode ser mais difícil porque a atividade dos aplicativos pode ocorrer em vários shards.

As revisões de segurança devem incluir o tratamento de mensagens entre shards, proteção contra replay, lógica de callback e estados de falha.

A fragmentação de estado oferece mais capacidade aos desenvolvedores, mas também pode exigir uma arquitetura mais cuidadosa.

As melhores plataformas para desenvolvedores fornecem abstrações que tornam a programação ciente de shards mais segura e simples.

Fragmentação de estado e DeFi

As finanças descentralizadas (DeFi) são especialmente sensíveis à fragmentação de estado porque dependem de composabilidade e liquidez compartilhada.

Um swap pode depender de um pool de liquidez.

Uma liquidação pode depender de um oráculo, mercado de empréstimos, saldo de garantia e registro de dívida.

Uma estratégia de rendimento pode depender da interação de vários contratos em uma única transação.

Se esses contratos estiverem em shards diferentes, a execução poderá se tornar assíncrona ou mais cara.

Isso pode reduzir a composabilidade atômica.

Sistemas DeFi com fragmentação de estado podem precisar de roteamento de liquidez, mensagens entre shards, pools de liquidez específicos de shard ou agrupamento de aplicativos.

Alguns aplicativos podem optar por manter todos os contratos principais em um shard para simplificar.

Outros podem criar fluxos de trabalho nativos entre shards para alcançar mais usuários e liquidez.

A fragmentação de estado pode expandir o throughput total, mas os desenvolvedores DeFi devem gerenciar cuidadosamente o risco de fragmentação.

Para os usuários, a principal preocupação é se o DeFi entre shards continua seguro, líquido e previsível.

Fragmentação de estado e NFTs

Os tokens não fungíveis (NFTs) podem se beneficiar da fragmentação de estado porque grandes ecossistemas de NFTs podem criar muitos registros de propriedade, links de metadados, listagens em marketplaces e itens de jogos.

O sharding pode distribuir esse estado entre vários shards.

Isso pode reduzir o congestionamento quando muitos usuários interagem ao mesmo tempo com diferentes coleções ou jogos.

No entanto, os NFTs também criam desafios entre shards.

Um NFT em um shard pode precisar ser vendido a um comprador em outro shard.

Um item de jogo pode precisar interagir com contratos ou marketplaces em shards diferentes.

Uma carteira pode precisar exibir saldos de NFTs em vários shards.

Marketplaces podem precisar de sistemas de indexação e roteamento que compreendam a localização dos shards.

A fragmentação de estado pode facilitar a escalabilidade de NFTs, mas também pode tornar a descoberta, a liquidez e as transferências mais complexas.

Uma boa infraestrutura de carteiras e marketplaces é essencial para uma experiência fluida com NFTs em sistemas fragmentados.

Fragmentação de estado e bridges

A fragmentação de estado e as bridges estão relacionadas porque a comunicação entre shards se parece, em alguns aspectos, com a comunicação entre cadeias.

Uma mensagem deve passar de um ambiente de estado para outro.

O ambiente receptor deve saber que a mensagem é válida.

O ambiente de envio deve impedir o uso duplo ou replay.

A diferença é que os shards geralmente fazem parte de um protocolo compartilhado, enquanto cadeias separadas podem ter pressupostos de segurança independentes.

Portanto, mensagens entre shards podem ser mais seguras do que bridges comuns se estiverem incorporadas ao protocolo base e protegidas por consenso compartilhado.

No entanto, sistemas entre shards mal projetados ainda podem criar riscos semelhantes aos de bridges.

Os usuários devem observar se as transferências entre shards são ações nativas do protocolo ou ações de bridge na camada de aplicativo.

Mensagens nativas entre shards geralmente têm integração mais forte com as regras de consenso da cadeia.

Bridges na camada de aplicativo podem adicionar riscos extras de contratos inteligentes, validadores, relayers ou liquidez.

Fragmentação de estado e resharding

Resharding é o processo de alterar a estrutura de shards ao longo do tempo.

Uma cadeia pode precisar de resharding quando o uso cresce, quando alguns shards ficam muito ocupados ou quando a distribuição de estado se torna desigual.

Shards estáticos podem se tornar ineficientes se um shard receber a maior parte da atividade enquanto outros permanecem subutilizados.

O resharding dinâmico busca ajustar os limites ou a quantidade de shards com base na demanda.

Isso pode melhorar o uso de recursos, mas aumenta a complexidade.

Mover o estado entre shards deve ser seguro e consistente.

Os aplicativos devem continuar funcionando enquanto as atribuições de shards mudam.

Validadores e indexadores devem acompanhar corretamente a nova estrutura.

Carteiras e dApps não devem falhar quando ocorre resharding.

O resharding mostra que a fragmentação de estado não consiste apenas em dividir o estado uma vez, mas também em gerenciá-lo durante toda a vida da rede.

Benefícios da fragmentação de estado

O primeiro benefício da fragmentação de estado é um throughput maior.

Vários shards podem processar transações em paralelo, em vez de forçar toda a atividade por um único pipeline de execução.

O segundo benefício é uma melhor escalabilidade de armazenamento.

Os nós podem não precisar armazenar todas as partes do estado global.

O terceiro benefício é uma escalabilidade horizontal melhorada.

A rede pode adicionar capacidade ao acrescentar shards ou recursos de validadores, em vez de apenas aumentar os requisitos de hardware dos nós.

O quarto benefício é a redução do congestionamento para aplicativos que podem operar principalmente dentro de um shard.

O quinto benefício é um caminho para participação mais ampla se os requisitos de validadores e nós permanecerem gerenciáveis.

O sexto benefício é uma especialização maior, pois diferentes shards podem atender a diferentes grupos de aplicativos ou cargas de trabalho, dependendo do modelo.

Esses benefícios explicam por que a fragmentação de estado continua sendo um conceito importante de escalabilidade.

Os benefícios são maiores quando a comunicação entre shards é segura, rápida e fácil para usuários e desenvolvedores.

Riscos e limitações da fragmentação de estado

O primeiro risco é a complexidade entre shards.

Aplicativos que precisam de estado de vários shards podem se tornar mais difíceis de criar e usar.

O segundo risco é a fragmentação de segurança.

Cada shard deve ser protegido contra ataques, mesmo que apenas parte do conjunto de validadores o valide diretamente.

O terceiro risco é a fragmentação de liquidez.

Ativos e mercados podem se dividir entre shards, tornando preços e execução menos eficientes.

O quarto risco é uma composabilidade atômica mais fraca.

Transações que eram simples em um estado compartilhado podem exigir um modelo assíncrono entre shards.

O quinto risco é a confusão do usuário.

Os usuários podem não entender atrasos, roteamento ou falhas de mensagens entre shards.

O sexto risco é a complexidade da infraestrutura.

Provedores de RPC, indexadores, carteiras, exploradores e bridges devem acompanhar corretamente vários shards.

O sétimo risco é a carga desigual.

Alguns shards podem ficar congestionados, enquanto outros têm capacidade ociosa.

A fragmentação de estado é poderosa, mas não é uma solução de escalabilidade sem custo.

Equívocos comuns sobre a fragmentação de estado

Um equívoco comum é que a fragmentação de estado significa simplesmente transações mais rápidas.

Na realidade, a fragmentação de estado é uma arquitetura complexa que divide responsabilidades de estado, execução, validação e comunicação.

Outro equívoco é que a fragmentação de estado é igual a rollups.

Os rollups movem a execução para sistemas de Layer 2, enquanto a fragmentação de estado divide o próprio estado e execução da camada base.

Um terceiro equívoco é que o roteiro atual do Ethereum é a fragmentação de estado tradicional.

O roteiro atual do Ethereum se concentra em rollups, blobs e disponibilidade de dados no estilo danksharding, em vez de cadeias de shards de estado de execução tradicionais.

Um quarto equívoco é que a fragmentação de estado preserva automaticamente a composabilidade.

A composabilidade entre shards é uma das partes mais difíceis do modelo.

Um quinto equívoco é que uma cadeia fragmentada é apenas várias cadeias separadas.

Uma verdadeira blockchain fragmentada precisa de segurança compartilhada, finalidade compartilhada e comunicação nativa entre shards.

Como avaliar uma blockchain com fragmentação de estado

Comece verificando se a cadeia realmente fragmenta o estado ou se apenas fragmenta dados ou transações.

Em seguida, verifique como os validadores são atribuídos aos shards.

Avalie se a atribuição de validadores usa uma aleatoriedade robusta.

Verifique como as transações entre shards são processadas.

Avalie se a execução entre shards é síncrona ou assíncrona.

Verifique se os aplicativos podem manter a composabilidade atômica entre shards.

Avalie como o protocolo lida com a disponibilidade de dados para blocos de shards.

Verifique se a rede oferece suporte a resharding dinâmico ou shards fixos.

Avalie a experiência do usuário nas transferências entre shards.

Estude se carteiras, exploradores, provedores de RPC e indexadores oferecem suporte confiável a todos os shards.

Uma blockchain com fragmentação de estado deve ser avaliada pela segurança, usabilidade, experiência dos desenvolvedores e throughput real em condições entre shards.

Boas práticas para usuários

Entenda se a rede utilizada tem endereços específicos por shard, saldos de gas ou atrasos de transferência.

Use carteiras que lidem automaticamente com o roteamento de shards, quando possível.

Comece com pequenas transferências de teste antes de mover valores relevantes entre shards.

Verifique se um aplicativo opera dentro de um shard ou entre vários shards.

Tenha cautela ao usar bridges ou roteadores que não sejam nativos do protocolo fragmentado.

Observe possíveis atrasos adicionais quando os fundos se movem entre shards.

Não presuma que uma transação é final em todos os shards até que o protocolo ou a carteira confirme isso.

Leia a documentação do aplicativo ao usar DeFi entre shards ou mercados de NFTs.

Mantenha tokens nativos suficientes para taxas se a rede exigir pagamentos de taxas específicos por shard.

Considere a fragmentação de estado como uma infraestrutura que pode melhorar o desempenho, mas não elimina riscos de contratos inteligentes ou de mercado.

Boas práticas para desenvolvedores

Projete aplicativos considerando a localização de shards e o comportamento entre shards.

Evite chamadas desnecessárias entre shards quando for possível usar um modelo no mesmo shard.

Use padrões assíncronos com segurança quando o protocolo exigir execução assíncrona entre shards.

Proteja mensagens entre shards contra replay, erros de ordenação e lógica de callback com falhas.

Teste separadamente os fluxos de transações no mesmo shard e entre shards.

Monitore a fragmentação de liquidez caso o aplicativo dependa de mercados de tokens.

Explique claramente atrasos entre shards nas interfaces de usuário.

Use SDKs oficiais e a documentação do protocolo para troca de mensagens e roteamento de shards.

Planeje o resharding se a rede oferecer suporte a alterações dinâmicas de shards.

Trate a execução entre shards como uma parte sensível à segurança no design do aplicativo.

FAQ

O que significa fragmentação de estado?

Fragmentação de estado significa dividir o estado ativo de uma blockchain em vários shards para que diferentes grupos de validadores possam processar e armazenar diferentes partes em paralelo.

O que é um shard?

Um shard é uma partição do estado de uma blockchain e de sua carga de trabalho de execução.

Por que as blockchains usam fragmentação de estado?

As blockchains usam fragmentação de estado para aumentar o throughput, reduzir a carga de armazenamento por nó e escalar a execução entre grupos de shards paralelos.

Fragmentação de estado é igual à fragmentação de dados?

Não. A fragmentação de estado divide o estado de execução ativo, enquanto a fragmentação de dados se concentra em disponibilizar dados de transações em partes escaláveis.

Fragmentação de estado é igual a rollups?

Não. Os rollups executam transações fora da camada base, enquanto a fragmentação de estado divide o próprio estado e execução da camada base.

O Ethereum usa atualmente fragmentação de estado?

Não. O roteiro atual do Ethereum se concentra em rollups, blobs e disponibilidade de dados no estilo danksharding, e não em fragmentação tradicional de execução ou de estado.

Qual blockchain é conhecida pela fragmentação de estado?

A NEAR é amplamente conhecida por seu modelo de sharding Nightshade, que divide o estado e o processamento entre shards.

O que são transações entre shards?

Transações entre shards são transações que afetam o estado em mais de um shard e exigem comunicação entre shards.

Por que a fragmentação de estado é difícil para DeFi?

A fragmentação de estado é difícil para DeFi porque DeFi frequentemente depende de composabilidade atômica, liquidez compartilhada e interações entre vários contratos em um estado unificado.

A fragmentação de estado torna uma blockchain livre de riscos?

Não. A fragmentação de estado pode melhorar a escalabilidade, mas ainda apresenta riscos, como erros entre shards, fragmentação de segurança, fragmentação de liquidez e complexidade de infraestrutura.

Conclusão

A fragmentação de estado é um método de escalabilidade de blockchain que divide o estado ativo e a execução entre vários shards.

Seu principal objetivo é aumentar o throughput e reduzir a carga sobre validadores ou nós individuais.

Ela é diferente da fragmentação de dados porque divide o estado real de execução, em vez de apenas melhorar a disponibilidade de dados.

Também é diferente dos rollups porque altera a arquitetura da camada base, em vez de mover a execução para um ambiente separado de Layer 2.

A fragmentação de estado pode tornar uma blockchain mais escalável, mas também introduz problemas complexos relacionados a transações entre shards, atribuição de validadores, disponibilidade de dados, composabilidade atômica, fragmentação de liquidez e experiência do usuário.

O modelo Nightshade da NEAR é um exemplo importante em produção de pesquisas sobre sharding se tornando infraestrutura operacional.

O Ethereum é importante historicamente, mas seu roteiro atual usa escalabilidade centrada em rollups e disponibilidade de dados no estilo danksharding, em vez da fragmentação de estado tradicional.

Para os usuários, a fragmentação de estado pode significar atividades de blockchain mais rápidas e baratas quando há forte suporte de carteiras e aplicativos.

Para os desenvolvedores, a fragmentação de estado significa que a arquitetura do aplicativo deve considerar localização de shards, mensagens entre shards, execução assíncrona e casos extremos de segurança.

Para as redes, a fragmentação de estado é uma forma de buscar escalabilidade horizontal enquanto tenta preservar a descentralização.

No contexto de glossário cripto, State Sharding significa dividir o estado ativo de uma blockchain em shards paralelos para que a rede possa processar e armazenar mais atividade sem exigir que cada validador lide com tudo.

A principal conclusão é que a fragmentação de estado pode melhorar muito a escalabilidade, mas apenas se o protocolo resolver a comunicação entre shards, a segurança compartilhada, a disponibilidade de dados e a usabilidade para desenvolvedores sem enfraquecer o modelo de confiança da blockchain.