A ponderação da escalabilidade do Blockchain: O caminho do equilíbrio entre Polkadot e Web3

Hoje, em um momento em que a Blockchain busca constantemente maior eficiência, uma questão chave começa a se destacar: ao melhorar o desempenho de escalabilidade, é necessário sacrificar a segurança e a resiliência do sistema? Isso não é apenas um desafio a nível técnico, mas uma escolha profunda no design da arquitetura. Para o ecossistema Web3, um sistema mais rápido, se baseado na sacrifício da confiança e da segurança, muitas vezes tem dificuldade em sustentar inovações verdadeiramente sustentáveis.

Polkadot, como um importante impulsionador da escalabilidade do Web3, fez concessões em descentralização, segurança ou interoperabilidade da rede com seu modelo de rollup? Este artigo irá analisar profundamente as concessões e trade-offs do Polkadot no design de escalabilidade, comparando-os com as soluções de outras principais blockchains, explorando as diferentes escolhas de caminhos entre desempenho, segurança e descentralização.

Desafios enfrentados pelo design de expansão do Polkadot

O equilíbrio entre elasticidade e descentralização

A arquitetura do Polkadot depende da rede de validadores e da Relay Chain (, será que isso pode introduzir riscos de centralização em certos aspectos? É possível que se forme um ponto único de falha ou controle, afetando assim suas características de descentralização?

A execução do Rollup depende do sequenciador ) que conecta a cadeia de retransmissão (, cuja comunicação utiliza um mecanismo chamado protocolo collator. Este protocolo é totalmente sem permissão e sem confiança, qualquer pessoa com conexão à rede pode usá-lo, conectando-se a um pequeno número de nós da cadeia de retransmissão e enviando pedidos de alteração de estado do rollup. Esses pedidos serão verificados por algum core da cadeia de retransmissão, desde que satisfaçam uma premissa: devem ser alterações de estado válidas, caso contrário, o estado do rollup não será avançado.

) Compromissos de expansão vertical

O Rollup pode alcançar a escalabilidade vertical ao aproveitar a arquitetura multicore do Polkadot. Esta nova capacidade é introduzida pela funcionalidade "Elastic Scaling"###Elastic Scaling(. Durante o processo de design, descobrimos que, uma vez que a validação de blocos do rollup não é fixa em um core específico, isso pode afetar sua elasticidade.

Como o protocolo para submeter blocos à cadeia de retransmissão é sem permissão e sem confiança, qualquer pessoa pode submeter blocos a qualquer core atribuído ao rollup para validação. Um atacante pode explorar isso, submetendo repetidamente blocos legítimos que já foram validados a diferentes cores, consumindo recursos de forma maliciosa, reduzindo assim a capacidade de throughput e eficiência geral do rollup.

O objetivo do Polkadot é manter a elasticidade do rollup e a utilização eficaz dos recursos da cadeia de retransmissão, sem comprometer as características-chave do sistema.

) Sequencer é confiável?

Uma solução simples é configurar o protocolo como "com licença": por exemplo, adotando um mecanismo de lista branca, ou confiando por padrão que o ordenado não terá comportamentos maliciosos, garantindo assim a atividade do rollup.

No entanto, na filosofia de design do Polkadot, não podemos fazer qualquer suposição de confiança sobre o sequenciador, pois é necessário manter as características de "sem confiança" e "sem permissão" do sistema. Qualquer pessoa deve poder usar o protocolo collator para submeter pedidos de alteração de estado do rollup.

Polkadot: uma solução intransigente

A solução finalmente escolhida pelo Polkadot é: deixar a questão completamente a cargo da função de transição de estado do rollup ###Runtime(. O Runtime é a única fonte confiável de todas as informações de consenso, portanto, deve ser declarado claramente na saída onde a validação deve ser executada no core do Polkadot.

Este design alcançou uma dupla garantia de flexibilidade e segurança. Polkadot irá reexecutar a conversão de estado do rollup no processo de disponibilidade e garantir a correção da alocação core através do protocolo econômico criptográfico ELVES.

Antes de qualquer rollup Bloco ser escrito na camada de disponibilidade de dados do Polkadot )DA(, um grupo de cerca de 5 validadores irá primeiro verificar sua legalidade. Eles recebem os recibos candidatos )candidate receipt( e a prova de validade )PoV(, que contêm o Bloco rollup e as respectivas provas de armazenamento. Essas informações serão processadas pela função de verificação da cadeia paralela, sendo reexecutadas pelos validadores na cadeia de retransmissão.

O resultado da verificação inclui um core selector, utilizado para especificar em qual core deve ser validado o bloco. O validador irá comparar se esse índice corresponde ao core de sua responsabilidade; se não corresponder, o bloco será descartado.

Este mecanismo assegura que o sistema mantenha sempre as propriedades de não confiança e não permissão, evitando que agentes maliciosos como ordenadores manipulem a posição de validação, garantindo que mesmo com múltiplos núcleos em uso, o rollup possa manter a resiliência.

) segurança

No processo de busca por escalabilidade, o Polkadot não comprometeu a segurança. A segurança do rollup é garantida pela cadeia de relé, sendo necessário apenas um ordenante honesto para manter a vitalidade.

Com o protocolo ELVES, o Polkadot estende a sua segurança de forma completa a todos os rollups, validando todos os cálculos na core, sem a necessidade de impor qualquer limitação ou suposição sobre o número de núcleos utilizados.

Assim, os rollups do Polkadot podem alcançar uma verdadeira escalabilidade sem sacrificar a segurança.

Utilidade

A escalabilidade elástica não limitará a programabilidade do rollup. O modelo de rollup do Polkadot suporta a execução de cálculos Turing-completos em um ambiente WebAssembly, desde que a execução única seja concluída em até 2 segundos. Com a escalabilidade elástica, a quantidade total de cálculos executáveis a cada 6 segundos pode ser aumentada, mas o tipo de cálculo não é afetado.

Complexidade

Um maior throughput e uma menor latência inevitavelmente introduzem complexidade, que é a única forma aceitável de compensação no design de sistemas.

O Rollup pode ajustar dinamicamente os recursos através da interface Agile Coretime, para manter um nível de segurança consistente. Eles também precisam cumprir parcialmente os requisitos do RFC103, para se adaptarem a diferentes cenários de uso.

A complexidade específica depende da estratégia de gestão de recursos do rollup, que pode depender de variáveis on-chain ou off-chain. Por exemplo:

• Estratégia simples: use sempre uma quantidade fixa de core, ou ajuste manualmente fora da cadeia;

• Estratégia leve: monitorar a carga de transações específicas no mempool do nó;

• Estratégia de Automação: Chamar antecipadamente o serviço coretime através de dados históricos e da interface XCM para configurar recursos.

Embora a automação seja mais eficiente, os custos de implementação e teste também aumentam significativamente.

Interoperabilidade

Polkadot suporta a interoperabilidade entre diferentes rollups, enquanto a escalabilidade flexível não afeta a capacidade de transmissão de mensagens.

A comunicação de mensagens entre rollups é realizada pela camada de transporte subjacente, e o espaço de bloco de comunicação de cada rollup é fixo, independentemente do número de núcleos atribuídos.

No futuro, o Polkadot também suportará a comunicação off-chain ###, com a cadeia de retransmissão a atuar como a camada de controle, em vez de camada de dados. Esta atualização irá melhorar a capacidade de comunicação entre rollups juntamente com a escalabilidade elástica, aumentando ainda mais a capacidade de escalabilidade vertical do sistema.

Que compromissos foram feitos por outros protocolos?

É bem conhecido que a melhoria de desempenho geralmente vem à custa da descentralização e da segurança. No entanto, do ponto de vista do coeficiente de Nakamoto, mesmo que alguns concorrentes do Polkadot tenham um grau de descentralização mais baixo, seu desempenho não é satisfatório.

( Solana

A Solana não utiliza a arquitetura de fragmentação do Polkadot ou do Ethereum, mas sim uma arquitetura de camada única de alta capacidade de processamento para alcançar escalabilidade, dependendo da prova de histórico )PoH###, do processamento paralelo de CPU e de um mecanismo de consenso baseado em líderes, com um TPS teórico que pode chegar a 65.000.

Um design chave é o seu mecanismo de agendamento de líderes, que é previamente divulgado e verificável.

• Cada epoch ( dura cerca de dois dias ou 432.000 slots ), e os slots são atribuídos com base na quantidade de staking.

• Quanto mais se aposta, mais se distribui. Por exemplo, um validador que aposta 1% terá cerca de 1% de chance de criar blocos;

• Todos os produtores de blocos são anunciados antecipadamente, aumentando o risco de ataques DDoS direcionados à rede e falhas frequentes.

PoH e o processamento paralelo têm requisitos de hardware extremamente altos, levando à centralização dos nós de validação. Quanto mais um nó é estacado, maior a chance de criar blocos, enquanto pequenos nós quase não têm slots, o que agrava ainda mais a centralização e aumenta o risco de colapso do sistema após um ataque.

A Solana sacrificou a descentralização e a capacidade de resistência a ataques em busca de TPS, com um coeficiente de Nakamoto de apenas 20, muito abaixo dos 172 da Polkadot.

( TON

A TON afirma que o TPS pode chegar a 104.715, mas esse número foi alcançado em uma rede de testes privada, com 256 nós, em condições ideais de rede e hardware. Já o Polkadot alcançou 128K TPS em uma rede pública descentralizada.

O mecanismo de consenso do TON apresenta vulnerabilidades de segurança: a identidade dos nós de validação de fragmentos pode ser exposta antecipadamente. O white paper do TON também afirma claramente que, embora isso possa otimizar a largura de banda, também pode ser explorado maliciosamente. Devido à falta de um mecanismo de "falência de apostador", os atacantes podem esperar que um fragmento seja completamente controlado por eles ou bloquear validadores honestos através de ataques DDoS, permitindo assim a manipulação do estado.

Em comparação, os validadores do Polkadot são atribuídos aleatoriamente e revelados com atraso, os atacantes não podem saber a identidade dos validadores com antecedência, o ataque deve apostar todo o controle para ter sucesso, assim que um validador honesto iniciar uma disputa, o ataque falhará e resultará na perda da garantia do atacante.

) Avalanche

Avalanche utiliza uma arquitetura de mainnet + subnets para escalabilidade, onde a mainnet é composta por transferências na X-Chain###, ~4,500 TPS###, contratos inteligentes na C-Chain(, ~100--200 TPS), e a P-Chain( que gerencia validadores e subnets).

Cada sub-rede tem um TPS teórico de cerca de 5.000, semelhante à abordagem do Polkadot: reduzir a carga de um único shard para alcançar a escalabilidade. No entanto, o Avalanche permite que os validadores escolham livremente participar de sub-redes, e estas podem estabelecer requisitos adicionais geográficos, KYC, etc., sacrificando a descentralização e a segurança.

No Polkadot, todos os rollups compartilham uma proteção de segurança unificada; enquanto as sub-redes da Avalanche não têm garantias de segurança por padrão, algumas podem ser completamente centralizadas. Para aumentar a segurança, ainda é necessário comprometer o desempenho, e é difícil oferecer uma promessa de segurança determinística.

( Ethereum

A estratégia de escalabilidade do Ethereum aposta na escalabilidade da camada rollup, em vez de resolver os problemas diretamente na camada base. Essencialmente, essa abordagem não resolve o problema, mas sim o transfere para a camada superior da pilha.

)# Optimistic Rollup

Atualmente, a maioria dos Optimistic rollups é centralizada ###, alguns têm até apenas um sequencer ###, o que resulta em problemas de segurança insuficiente, isolamento entre si, alta latência ( e a necessidade de esperar pelo período de prova de fraude, que geralmente leva alguns dias ).

(# ZK Rollup

A implementação do ZK rollup é limitada pela quantidade de dados que uma única transação pode processar. A demanda computacional para gerar provas de zero conhecimento é extremamente alta, e o mecanismo de "winner takes all" tende a centralizar o sistema. Para garantir TPS, o ZK rollup geralmente limita a quantidade de transações por lote, o que pode causar congestionamento na rede e aumento do gas durante períodos de alta demanda, afetando a experiência do usuário.

Em comparação, o custo do ZK rollup Turing completo é aproximadamente 2x10^6 vezes o do protocolo de segurança econômica criptográfica central do Polkadot.

Além disso, o problema de disponibilidade de dados do ZK rollup também agravará suas desvantagens. Para garantir que qualquer pessoa possa validar as transações, ainda é necessário fornecer dados completos das transações. Isso geralmente depende de soluções adicionais de disponibilidade de dados, aumentando ainda mais os custos e as taxas para os usuários.

Conclusão

O fim da escalabilidade não deve ser um compromisso.

Comparado a outras blockchains, o Polkadot não seguiu o caminho de trocar descentralização por desempenho ou de trocar confiança pré-definida por eficiência, mas sim alcançou um equilíbrio multidimensional entre segurança, descentralização e alto desempenho através de uma escalabilidade flexível, design de protocolo sem permissão, uma camada de segurança unificada e um mecanismo de gestão de recursos flexível.

Na busca pela implementação em maior escala hoje, a "escalabilidade sem confiança" defendida pelo Polkadot pode ser a verdadeira solução que sustenta o desenvolvimento de longo prazo do Web3.