Fragmentação: outra possibilidade de escalabilidade do Blockchain

No dia 15 de setembro de 2022, o Ethereum completou a fusão (Merge). Este é um momento histórico, pelo qual o Ethereum se preparou durante 5 anos, com 6 adiamentos. Devido ao longo desenvolvimento e à ampla atenção, muitos erroneamente acreditam que a fusão trará naturalmente maior escalabilidade, segurança e sustentabilidade, mas isso não é verdade. A transição de Prova de Trabalho (PoW) para Prova de Participação (PoS) é apenas uma troca de "trilhos e rodas", e não trará diretamente mais rapidez, maior capacidade ou menores taxas. O que realmente pode alcançar esses objetivos é um conjunto completo de soluções: uma rede principal com capacidade de fragmentação combinada com soluções Layer2 que aumentam a escalabilidade.

Como apontado por Vitalik Buterin, o fundador do Ethereum, a fragmentação é uma solução de escalabilidade para o dilema da escalabilidade. Ao dividir os nós na rede em grupos menores, processando diferentes conjuntos de transações e alcançando processamento paralelo. Isso é como fazer compras no Walmart e pagar, onde a abertura de mais caixas pode reduzir visualmente o tempo de espera e aumentar a eficiência do checkout.

Esta é a lógica da Fragmentação, direta e simples, mas o diabo está nos detalhes. O princípio e a direção estão corretos, mas na implementação sempre surgem muitos problemas. Este artigo pretende, ao esclarecer a direção e os dilemas na "Fragmentação", traçar um mapa de exploradores da Fragmentação que olham para as estrelas e têm os pés no chão. Ao mesmo tempo, ao comparar as soluções de Fragmentação existentes, encontrar alguns problemas comuns e propor uma direção de exploração viável: Shardeum e Fragmentação dinâmica.

Um, sobre "Fragmentação"

De forma simples, considerando as restrições do triângulo impossível, a partir do Ethereum como ponto de origem do sistema de coordenadas (0,0), de acordo com duas abordagens, "vertical" e "horizontal", classificamos os métodos de escalabilidade da blockchain atual em duas grandes categorias:

Escalabilidade Vertical (: é alcançada melhorando o desempenho do hardware existente do sistema. Estabelecer uma rede descentralizada, onde cada nó na rede possui capacidade de supercomputação, ou seja, cada nó precisa de um hardware "melhor". Essa abordagem é simples e eficaz, podendo alcançar melhorias iniciais na capacidade de processamento, especialmente adequada para negociações de alta frequência, jogos e outras aplicações sensíveis à latência. No entanto, esse método de escalabilidade limita o nível de descentralização da rede, pois o custo de operar nós de validação ou nós completos aumenta. Manter o nível de descentralização é limitado pela velocidade de crescimento do desempenho do hardware de computação ) o que é chamado de "Lei de Moore": o número de transistores em um chip dobra a cada dois anos, enquanto o custo de computação é reduzido pela metade (.

Escalabilidade Horizontal )Horizontal Scaling (: A escalabilidade horizontal geralmente tem algumas abordagens. Uma delas é, no contexto da blockchain, dispersar a carga de transação de um ecossistema em várias blockchains independentes, cada uma com seus próprios produtores de blocos e capacidade de execução. Essa abordagem permite a customização completa da camada de execução de cada cadeia, como requisitos de hardware de nós, funcionalidades de privacidade, taxas de gas, máquinas virtuais e configurações de permissão, entre outras. Outra solução de escalabilidade horizontal é a blockchain modular, que divide a infraestrutura da blockchain em camada de execução, camada de disponibilidade de dados )DA ( e camada de consenso. O mecanismo modular de blockchain mais comum é o rollup. Há também a opção de dividir uma blockchain em várias partes, executando em paralelo. Cada fragmento pode ser considerado uma blockchain, ou seja, muitas blockchains podem ser executadas em paralelo. Além disso, normalmente haverá uma cadeia principal, cuja única tarefa é manter todos os fragmentos sincronizados.

![Explicação detalhada da nova blockchain Shardeum: outra possibilidade de fragmentação])https://img-cdn.gateio.im/webp-social/moments-7aa1677db6b8128b68accfe04fcda738.webp(

É importante notar que as abordagens de escalabilidade acima não existem isoladamente; cada solução encontra um ponto de equilíbrio dentro do triângulo impossível, combinando com o design de mecanismos de incentivo criados pelas forças econômicas no sistema, para alcançar um equilíbrio eficaz nos níveis macro e micro.

Para discutir "Fragmentação", precisamos começar do zero.

Ainda assumimos uma situação em que, ao fazer compras no Walmart, para aumentar a eficiência do checkout e reduzir o tempo de espera dos clientes, expandimos de um único canal de checkout para 10 janelas de checkout. Para evitar erros na contabilidade, nesta altura precisamos de estabelecer regras uniformes:

Primeiro, se tivermos 10 caixas, como devemos distribuí-los para trabalhar em qual janela?

Segundo, se tivermos 1000 clientes na fila à espera, como devemos decidir a que janela cada cliente vai para o pagamento?

Terceiro, como devemos consolidar os 10 livros contábeis correspondentes a essas 10 janelas?

Quarto, como evitar que os caixeiros cometam erros para prevenir discrepâncias nas contas?

Estas várias questões correspondem, na verdade, a várias questões chave na fragmentação, que são:

Como determinar a que fragmentação pertencem os nós/validadores da rede? Ou seja: como realizar a Fragmentação da Rede )Network Sharding(;

Como determinar a que fragmentação cada transação é atribuída? Ou seja: como realizar a fragmentação de transações )Transaction Sharding(;

Como os dados da Blockchain são armazenados em diferentes Fragmentações? Ou seja: como realizar a Fragmentação de Estado )State Sharding(;

Complexidade implica risco. Com base em tudo isso, como evitar a fragmentação da segurança de todo o sistema?

) 01 Fragmentação de Rede ### Network Sharding (

Se entendermos a blockchain como um livro-razão descentralizado, quer seja o mecanismo de consenso PoS ou PoW, ambos visam permitir que vários nós disputem o direito de contabilização de acordo com regras predefinidas, garantindo a precisão do livro-razão nesse processo. A fragmentação da rede refere-se a uma outra regra predefinida que fragmenta a rede blockchain, permitindo que cada fragmento processe transações na cadeia e dispute o direito de contabilização, ou seja, as regras de agrupamento dos nós.

E o problema encontrado neste processo é que, à medida que os nós internos do Blockchain são divididos em diferentes Fragmentação, a dificuldade e o custo para os atacantes diminuem drasticamente. Podemos inferir que, assumindo que as regras e resultados desse processo de agrupamento são fixos e previsíveis, um atacante que deseja controlar toda a rede Blockchain só precisa controlar direcionadamente uma das Fragmentações, corrompendo alguns nós dentro da Fragmentação.

O fundador da Near, Alexander Skidanov, descreveu assim o problema: se uma única cadeia com X validadores decidir realizar um hard fork em uma cadeia de fragmentação e dividir os X validadores em 10 fragmentos, cada fragmento terá agora apenas X/10 validadores, e para comprometer um fragmento, apenas 5.1%)51% / 10( do total de validadores seria necessário. Isso leva ao segundo ponto: quem escolhe os validadores para cada fragmento? Apenas quando todos esses 5.1% de validadores estão no mesmo fragmento, controlar 5.1% dos validadores se torna prejudicial. Se os validadores não puderem escolher em qual fragmento validar, é extremamente improvável que participantes que controlam 5.1% dos validadores coloquem todos os validadores no mesmo fragmento, reduzindo assim drasticamente sua capacidade de comprometer o sistema.

O sistema de fragmentação deve desenvolver um mecanismo para confiar que a rede não reverterá essas transações a partir de fragmentos externos. Até agora, a melhor resposta pode ser garantir que o número de validadores dentro do fragmento seja superior a um certo limite mínimo, de modo que a probabilidade de validadores desonestos dominarem um único fragmento seja muito baixa. A maneira mais comum é construir um certo nível de aleatoriedade imparcial, dependendo de métodos matemáticos, para minimizar a probabilidade de sucesso do atacante. Por exemplo, no Ethereum, a solução do Ethereum é selecionar aleatoriamente um validador de um fragmento a partir de todos os validadores, e a cada 6,4 minutos ) a duração de um epoch ( os validadores são trocados.

Dizendo de forma simples, é agrupar aleatoriamente os nós e depois atribuir o trabalho para que cada grupo de nós valide de forma independente.

No entanto, é necessário apontar que a aleatoriedade na Blockchain é um tópico bastante desafiador; logicamente, o processo de geração desse número aleatório não deve depender do cálculo de qualquer Fragmentação específica. Para esse cálculo, muitas das abordagens de design existentes consistem em desenvolver uma Blockchain separada para manter toda a rede. Essa cadeia é chamada de Beacon chain na Ethereum e na Near, Relay chain na PolkaDot e Cosmos Hub na Cosmos.

![Explicação detalhada da nova blockchain Shardeum: outra possibilidade de fragmentação])https://img-cdn.gateio.im/webp-social/moments-6e8d3331d7d68cb512eb2eb47bd9064d.webp(

) 02 Transação de Fragmentação ###Transaction Sharding (

A fragmentação de transações refere-se à formulação de regras sobre "quais transações devem ser alocadas a quais fragmentos", permitindo tanto o processamento paralelo quanto evitando a ocorrência do problema de gasto duplo. As diferenças no modelo de livro-razão da Blockchain podem afetar o desenvolvimento da fragmentação de transações.

Atualmente, existem duas categorias de métodos de contabilização na rede Blockchain, nomeadamente o modelo UTXO) (Unspent Transaction Outputs) e o modelo de conta/saldo. O primeiro é tipicamente representado pelo BTC, enquanto o segundo é exemplificado pelo ETH.

Modelo UTXO: Em transações BTC, cada transação terá uma ou mais saídas, UTXO refere-se às saídas de transações na blockchain que ainda não foram gastas e podem ser usadas como entradas em novas transações, enquanto as saídas de transações já gastas não podem ser gastas novamente, semelhante à situação de pagamento e troco em transações com dinheiro em papel, onde o cliente entrega uma ou mais notas ao comerciante, e o comerciante então devolve uma ou mais notas como troco ao cliente. No modelo UTXO, a fragmentação de transações requer comunicação entre fragmentos. Uma transação pode incluir várias entradas e várias saídas, não há o conceito de conta, nem registros de saldo. Uma possível abordagem é: processar o valor de entrada de uma transação em uma função hash para gerar um valor hash discreto que determina para qual fragmento os dados devem ir. Veja abaixo:

Para garantir que os itens sejam colocados de maneira consistente no bloco correto, os valores inseridos na função de hash devem vir da mesma coluna. Esta coluna é chamada de Chave de Fragmentação. Depois, as transações que geram o valor 1 são alocadas ao bloco 1, enquanto as transações que geram o valor 2 são alocadas ao bloco 2. No entanto, a desvantagem desse método é que os blocos precisam se comunicar para evitar ataques de double spending. Restringir transações entre blocos limitaria a usabilidade da plataforma, enquanto permitir transações entre blocos exigiria um balanço entre os custos de comunicação entre blocos e os benefícios trazidos por melhorias de desempenho.

Modelo de conta/saldo: o sistema registra o saldo de cada conta e, ao realizar uma transação, verifica se a conta tem saldo suficiente para o pagamento. Isso é semelhante a uma transferência bancária, onde o banco registra o saldo de cada conta e a transação só pode ser realizada se o saldo for maior do que o montante a ser transferido. No modelo de conta/saldo, como uma transação possui apenas uma entrada, basta fragmentar a transação de acordo com o endereço do remetente para garantir que várias transações da mesma conta sejam processadas no mesmo fragmento, prevenindo efetivamente a dupla despesa. Portanto, a maioria das blockchains que adotam a tecnologia de fragmentação são sistemas de livro de contas como o Ethereum.

( 03 Estado de Fragmentação ) State Sharding ###

O estado de fragmentação refere-se a como os dados na Blockchain são distribuídos e armazenados em diferentes fragmentos.

Continuando com o exemplo da fila do Walmart, cada janela tem um registo, como é que os seus livros de contas são mantidos? Se: um cliente vai para qual fila, regista-se na conta correspondente, por exemplo, se o cliente A foi à janela A, e no dia seguinte o mesmo cliente foi a outra janela de pagamento, como a janela B, e a janela B não tem as informações da conta anterior do cliente (, por exemplo, relacionadas a métodos de pagamento como cartão pré-pago ), o que deve ser feito? Chamar as informações da conta desse cliente da janela A?

O estado da fragmentação é o maior desafio da fragmentação, mais complicado do que a fragmentação de rede e a fragmentação de transações mencionadas acima. Isso porque, sob o mecanismo de fragmentação, as transações são alocadas em diferentes fragmentos com base no endereço, ou seja, o estado só será armazenado no fragmento correspondente ao seu endereço. Nesse caso, um problema a ser enfrentado é que as transações não ocorrem apenas em um fragmento, frequentemente envolvendo a fragmentação cruzada (Cross-Sharding).

Considere uma situação de transferência, a conta A transfere 10U para a conta B, e o endereço de A está alocado na Fragmentação 1, o registro da transação também será armazenado na Fragmentação 1. O endereço de B está alocado na Fragmentação 2, o registro da transação será armazenado na Fragmentação 2.

Uma vez que A queira transferir para B, isso resultará em uma transação entre fragmentos, o fragmento 2 chamará os registros de transações anteriores do fragmento 1 para confirmar a validade da transação. Se A transferir frequentemente moedas para B, o fragmento 2 terá que interagir constantemente com o fragmento 1, o que diminuirá a eficiência do processamento das transações. No entanto, se não baixar e verificar todo o histórico de um fragmento específico, os participantes podem não necessariamente...