Escalabilidade e Compromissos: Como o Polkadot Busca Equilíbrio no Ecossistema Web3
No contexto atual em que a blockchain busca constantemente maior eficiência, uma questão-chave começa a emergir: como evitar sacrificar a segurança e a resiliência do sistema ao mesmo tempo em que se amplia o desempenho? Isso não é apenas um desafio de nível técnico, mas uma decisão profunda no design da arquitetura. Para o ecossistema Web3, um sistema mais rápido que se baseia na sacrifício da confiança e da segurança muitas vezes tem dificuldade em sustentar inovações verdadeiramente sustentáveis.
Como um importante impulsionador da escalabilidade do Web3, o Polkadot fez algumas concessões em busca de alta taxa de transferência e baixa latência? O seu modelo de rollup fez compromissos em termos de descentralização, segurança ou interoperabilidade da rede? Este artigo irá abordar essas questões, analisando em profundidade as escolhas e trade-offs do Polkadot no design de escalabilidade, e comparando-as com as soluções de outras blockchains de destaque, explorando suas 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 de uma rede de validadores e de uma cadeia de retransmissão centralizada. Isso poderia, de alguma forma, introduzir riscos de centralização? É possível que ocorram pontos únicos de falha ou controle, afetando assim suas características de descentralização?
A operação do Rollup depende de um ordenado que conecta a cadeia de retransmissão, cuja comunicação utiliza um mecanismo denominado protocolo collator. Este protocolo é completamente sem permissão e sem confiança, qualquer pessoa com conexão à rede pode utilizá-lo, conectando-se a um pequeno número de nós da cadeia de retransmissão e submetendo pedidos de conversão de estado do rollup. Esses pedidos serão verificados por algum core da cadeia de retransmissão, desde que satisfaçam uma condição: devem ser conversões de estado válidas, caso contrário, o estado do rollup não será avançado.
Compromisso de escalabilidade vertical
O Rollup pode alcançar a escalabilidade vertical ao aproveitar a arquitetura multi-core do Polkadot. Esta nova capacidade é introduzida pela funcionalidade de "escalabilidade elástica". Durante o processo de design, descobrimos que, uma vez que a validação de blocos do rollup não é fixada em um único core, isso pode afetar sua elasticidade.
Como o protocolo para submeter blocos à cadeia de intermediação é sem permissão e sem confiança, qualquer pessoa pode submeter blocos a qualquer core atribuído ao rollup para verificação. Um atacante pode tirar proveito disso, submetendo repetidamente blocos legítimos que já foram verificados a diferentes cores, consumindo recursos maliciosamente e, assim, reduzindo a capacidade de processamento 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 essenciais do sistema.
O Sequencer é confiável?
Uma solução simples é definir o protocolo como "com licença": por exemplo, adotando um mecanismo de lista de permissões, 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 nenhuma suposição de confiança sobre o sequencer, pois precisamos manter as características de "sem confiança" e "sem permissão" do sistema. Qualquer pessoa deve poder usar o protocolo collator para enviar solicitações de transição de estado do rollup.
Polkadot: A solução sem compromissos
A solução finalmente escolhida pelo Polkadot é: deixar a questão completamente a cargo da função de conversã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 em qual núcleo do Polkadot a validação deve ser executada.
Este design implementa uma dupla garantia de elasticidade e segurança. O Polkadot irá reexecutar as transições de estado do rollup no processo de disponibilidade e garantir a correção da alocação do core através do protocolo econômico criptográfico ELVES.
Antes que qualquer rollup bloco seja escrito na camada de disponibilidade de dados (DA) do Polkadot, um grupo composto por cerca de 5 validadores irá primeiro verificar sua legalidade. Eles recebem os recibos candidatos e provas de validade submetidos pelo ordenadores, que contêm o bloco rollup e as provas de armazenamento correspondentes. Essas informações serão processadas pela função de validação da cadeia paralela, sendo reexecutadas pelos validadores na cadeia de retransmissão.
O resultado da validação inclui um seletor de core, que é usado para especificar em qual core o bloco deve ser validado. O validador irá comparar se esse índice corresponde ao core pelo qual é responsável; se não corresponder, o bloco será descartado.
Este mecanismo garante que o sistema mantenha sempre características de confiança zero e permissões zero, evitando que agentes maliciosos, como ordenadores, manipulem a posição de validação, assegurando que mesmo quando o rollup utiliza vários núcleos, a resiliência é mantida.
segurança
No processo de busca por escalabilidade, a Polkadot não comprometeu a segurança. A segurança dos rollups é garantida pela cadeia relé, e apenas um organizador honesto é necessário para manter a viabilidade.
Com o protocolo ELVES, o Polkadot estende a sua segurança completa a todos os rollups, validando todos os cálculos na core, sem precisar de impor quaisquer limitações ou suposições sobre o número de núcleos utilizados.
Assim, os rollups do Polkadot podem alcançar uma verdadeira escalabilidade sem comprometer a segurança.
versatilidade
A escalabilidade elástica não limitará a programabilidade do rollup. O modelo de rollup do Polkadot suporta a execução de computações Turing-completas 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 computações que podem ser executadas a cada 6 segundos é aumentada, mas o tipo de computação não é afetado.
Complexidade
Um maior throughput e uma latência mais baixa inevitavelmente introduzem complexidade, que é a única forma aceitável de compromisso no design de sistemas.
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 adaptar a diferentes cenários de uso.
A complexidade específica depende da estratégia de gerenciamento 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 cargas de transação específicas no mempool do nó;
Estratégia de automação: chama antecipadamente o serviço coretime para configurar recursos através de dados históricos e da interface XCM.
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, e a escalabilidade flexível não afeta a taxa de transferência das mensagens.
A comunicação de mensagens entre rollups é realizada pela camada de transporte subjacente, e o espaço do bloco de comunicação de cada rollup é fixo, independentemente do número de núcleos alocados.
No futuro, o Polkadot também suportará a comunicação de mensagens fora da cadeia, com a cadeia de retransmissão atuando como a camada de controle, e não como a camada de dados. Esta atualização permitirá que a capacidade de comunicação entre rollups melhore juntamente com a escalabilidade elástica, reforçando ainda mais a capacidade de escalabilidade vertical do sistema.
Que compromissos foram feitos por outros protocolos?
É amplamente reconhecido que o aumento de desempenho muitas vezes 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 nível de descentralização mais baixo, seu desempenho não é satisfatório.
Solana
A Solana não adota a arquitetura de fragmentação do Polkadot ou do Ethereum, mas sim uma arquitetura de camada única de alta taxa de transferência para alcançar escalabilidade, dependendo da prova histórica (PoH), processamento paralelo de CPU e um mecanismo de consenso baseado em líderes, com um TPS teórico de até 65.000.
Um design chave é o seu mecanismo de agendamento de líderes que é previamente divulgado e verificável:
No início de cada epoch (aproximadamente dois dias ou 432.000 slots), os slots são alocados com base na quantidade de staking;
Quanto mais você aposta, mais você recebe. Por exemplo, um validador que aposta 1% terá cerca de 1% de chance de gerar um bloco;
Todos os mineradores são anunciados antecipadamente, aumentando o risco de ataques DDoS direcionados e interrupções frequentes na rede.
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ó é apostado, maior a oportunidade de produzir blocos, enquanto nós pequenos quase não têm slots, o que agrava ainda mais a centralização e aumenta o risco de paralisação do sistema após um ataque.
A Solana sacrificou a descentralização e a resistência a ataques em busca de TPS, com um coeficiente de Nakamoto de apenas 20, muito abaixo dos 172 da Polkadot.
TON
Um projeto de blockchain afirma que o TPS pode chegar a 104.715, mas esse número foi alcançado em uma rede de teste privada, com 256 nós, em condições ideais de rede e hardware. O Polkadot já alcançou 128K TPS em uma rede pública descentralizada.
O mecanismo de consenso deste projeto apresenta vulnerabilidades de segurança: a identidade dos nós de validação de sharding pode ser exposta antecipadamente. O seu white paper 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 dos apostadores", os atacantes podem esperar que um shard esteja completamente sob seu controle ou interromper validadores honestos através de ataques DDoS, alterando assim o estado.
Em comparação, os validadores do Polkadot são distribuídos aleatoriamente e revelados com atraso, tornando impossível para um atacante saber a identidade dos validadores com antecedência. O ataque deve apostar no controle total 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 rede principal + subredes para escalar, com a rede principal composta por X-Chain (transferências, ~4.500 TPS), C-Chain (contratos inteligentes, ~100-200 TPS) e P-Chain (gerenciamento de validadores e subredes).
Cada sub-rede pode atingir uma TPS teórica de ~5.000, semelhante à abordagem do Polkadot: reduzir a carga de um único shard para alcançar escalabilidade. No entanto, o Avalanche permite que os validadores escolham livremente participar de sub-redes, e essas sub-redes podem estabelecer requisitos adicionais, como geográficos e KYC, sacrificando a descentralização e a segurança.
No Polkadot, todos os rollups compartilham uma garantia de segurança unificada; enquanto as sub-redes do 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 fornecer um compromisso de segurança determinístico.
Ethereum
A estratégia de escalabilidade do Ethereum aposta na escalabilidade da camada rollup, em vez de resolver diretamente os problemas na camada base. Essa abordagem, essencialmente, não resolve o problema, mas sim o transfere para a camada superior da pilha.
Rollup otimista
Atualmente, a maioria dos Optimistic rollups é centralizada (alguns têm apenas um sequenciador), apresentando problemas como falta de segurança, isolamento entre si e alta latência (é necessário aguardar o período de prova de fraude, que normalmente dura 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 conhecimento zero é extremamente alta, e o mecanismo de "vencedor leva tudo" tende a levar à centralização do sistema. Para garantir o TPS, o ZK rollup frequentemente 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 central do Polkadot.
Além disso, os problemas de disponibilidade de dados do ZK rollup também agravarão suas desvantagens. Para garantir que qualquer pessoa possa verificar 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 taxas para os usuários.
Conclusão
O fim da escalabilidade não deve ser um compromisso.
Comparado com outras blockchains públicas, o Polkadot não seguiu o caminho de trocar a centralização por desempenho ou de trocar a confiança pré-estabelecida por eficiência, mas sim alcançou um equilíbrio multidimensional de segurança, descentralização e alto desempenho através de escalabilidade elástica, design de protocolos sem permissão, uma camada de segurança unificada e um mecanismo de gestão de recursos flexível.
Na busca pela aplicação de maior escala hoje em dia, a "escalabilidade sem confiança" defendida pela Polkadot pode ser a verdadeira solução que sustentará o desenvolvimento a longo prazo do Web3.
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
13 Curtidas
Recompensa
13
8
Compartilhar
Comentário
0/400
MysteryBoxOpener
· 10h atrás
dot realmente supera outras blockchains
Ver originalResponder0
NotFinancialAdviser
· 11h atrás
Deixa pra lá, o dot também não é grande coisa.
Ver originalResponder0
LuckyBearDrawer
· 07-22 00:01
Esta onda de DOT vai até à lua!
Ver originalResponder0
P2ENotWorking
· 07-19 22:40
De que adianta a velocidade? Primeiro é preciso sobreviver.
Ver originalResponder0
BrokenDAO
· 07-19 22:39
Mais uma vez a descrever uma perfeita balança... Lembramo-nos daquela onda de paralisia ecológica em 2021?
Ver originalResponder0
ser_we_are_early
· 07-19 22:39
Top! Neste tipo de artigo técnico, só me interessa uma coisa, subir ou não subir.
Ver originalResponder0
DevChive
· 07-19 22:32
dot é o futuro, quem é que se opõe?
Ver originalResponder0
MagicBean
· 07-19 22:31
aguardando os resultados dos competidores de polka, não consigo deixar de dizer que ainda podem Até à lua.
O caminho de compromisso do Polkadot: escalabilidade sem concessões no ecossistema Web3
Escalabilidade e Compromissos: Como o Polkadot Busca Equilíbrio no Ecossistema Web3
No contexto atual em que a blockchain busca constantemente maior eficiência, uma questão-chave começa a emergir: como evitar sacrificar a segurança e a resiliência do sistema ao mesmo tempo em que se amplia o desempenho? Isso não é apenas um desafio de nível técnico, mas uma decisão profunda no design da arquitetura. Para o ecossistema Web3, um sistema mais rápido que se baseia na sacrifício da confiança e da segurança muitas vezes tem dificuldade em sustentar inovações verdadeiramente sustentáveis.
Como um importante impulsionador da escalabilidade do Web3, o Polkadot fez algumas concessões em busca de alta taxa de transferência e baixa latência? O seu modelo de rollup fez compromissos em termos de descentralização, segurança ou interoperabilidade da rede? Este artigo irá abordar essas questões, analisando em profundidade as escolhas e trade-offs do Polkadot no design de escalabilidade, e comparando-as com as soluções de outras blockchains de destaque, explorando suas 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 de uma rede de validadores e de uma cadeia de retransmissão centralizada. Isso poderia, de alguma forma, introduzir riscos de centralização? É possível que ocorram pontos únicos de falha ou controle, afetando assim suas características de descentralização?
A operação do Rollup depende de um ordenado que conecta a cadeia de retransmissão, cuja comunicação utiliza um mecanismo denominado protocolo collator. Este protocolo é completamente sem permissão e sem confiança, qualquer pessoa com conexão à rede pode utilizá-lo, conectando-se a um pequeno número de nós da cadeia de retransmissão e submetendo pedidos de conversão de estado do rollup. Esses pedidos serão verificados por algum core da cadeia de retransmissão, desde que satisfaçam uma condição: devem ser conversões de estado válidas, caso contrário, o estado do rollup não será avançado.
Compromisso de escalabilidade vertical
O Rollup pode alcançar a escalabilidade vertical ao aproveitar a arquitetura multi-core do Polkadot. Esta nova capacidade é introduzida pela funcionalidade de "escalabilidade elástica". Durante o processo de design, descobrimos que, uma vez que a validação de blocos do rollup não é fixada em um único core, isso pode afetar sua elasticidade.
Como o protocolo para submeter blocos à cadeia de intermediação é sem permissão e sem confiança, qualquer pessoa pode submeter blocos a qualquer core atribuído ao rollup para verificação. Um atacante pode tirar proveito disso, submetendo repetidamente blocos legítimos que já foram verificados a diferentes cores, consumindo recursos maliciosamente e, assim, reduzindo a capacidade de processamento 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 essenciais do sistema.
O Sequencer é confiável?
Uma solução simples é definir o protocolo como "com licença": por exemplo, adotando um mecanismo de lista de permissões, 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 nenhuma suposição de confiança sobre o sequencer, pois precisamos manter as características de "sem confiança" e "sem permissão" do sistema. Qualquer pessoa deve poder usar o protocolo collator para enviar solicitações de transição de estado do rollup.
Polkadot: A solução sem compromissos
A solução finalmente escolhida pelo Polkadot é: deixar a questão completamente a cargo da função de conversã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 em qual núcleo do Polkadot a validação deve ser executada.
Este design implementa uma dupla garantia de elasticidade e segurança. O Polkadot irá reexecutar as transições de estado do rollup no processo de disponibilidade e garantir a correção da alocação do core através do protocolo econômico criptográfico ELVES.
Antes que qualquer rollup bloco seja escrito na camada de disponibilidade de dados (DA) do Polkadot, um grupo composto por cerca de 5 validadores irá primeiro verificar sua legalidade. Eles recebem os recibos candidatos e provas de validade submetidos pelo ordenadores, que contêm o bloco rollup e as provas de armazenamento correspondentes. Essas informações serão processadas pela função de validação da cadeia paralela, sendo reexecutadas pelos validadores na cadeia de retransmissão.
O resultado da validação inclui um seletor de core, que é usado para especificar em qual core o bloco deve ser validado. O validador irá comparar se esse índice corresponde ao core pelo qual é responsável; se não corresponder, o bloco será descartado.
Este mecanismo garante que o sistema mantenha sempre características de confiança zero e permissões zero, evitando que agentes maliciosos, como ordenadores, manipulem a posição de validação, assegurando que mesmo quando o rollup utiliza vários núcleos, a resiliência é mantida.
segurança
No processo de busca por escalabilidade, a Polkadot não comprometeu a segurança. A segurança dos rollups é garantida pela cadeia relé, e apenas um organizador honesto é necessário para manter a viabilidade.
Com o protocolo ELVES, o Polkadot estende a sua segurança completa a todos os rollups, validando todos os cálculos na core, sem precisar de impor quaisquer limitações ou suposições sobre o número de núcleos utilizados.
Assim, os rollups do Polkadot podem alcançar uma verdadeira escalabilidade sem comprometer a segurança.
versatilidade
A escalabilidade elástica não limitará a programabilidade do rollup. O modelo de rollup do Polkadot suporta a execução de computações Turing-completas 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 computações que podem ser executadas a cada 6 segundos é aumentada, mas o tipo de computação não é afetado.
Complexidade
Um maior throughput e uma latência mais baixa inevitavelmente introduzem complexidade, que é a única forma aceitável de compromisso no design de sistemas.
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 adaptar a diferentes cenários de uso.
A complexidade específica depende da estratégia de gerenciamento 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 cargas de transação específicas no mempool do nó;
Estratégia de automação: chama antecipadamente o serviço coretime para configurar recursos através de dados históricos e da interface XCM.
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, e a escalabilidade flexível não afeta a taxa de transferência das mensagens.
A comunicação de mensagens entre rollups é realizada pela camada de transporte subjacente, e o espaço do bloco de comunicação de cada rollup é fixo, independentemente do número de núcleos alocados.
No futuro, o Polkadot também suportará a comunicação de mensagens fora da cadeia, com a cadeia de retransmissão atuando como a camada de controle, e não como a camada de dados. Esta atualização permitirá que a capacidade de comunicação entre rollups melhore juntamente com a escalabilidade elástica, reforçando ainda mais a capacidade de escalabilidade vertical do sistema.
Que compromissos foram feitos por outros protocolos?
É amplamente reconhecido que o aumento de desempenho muitas vezes 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 nível de descentralização mais baixo, seu desempenho não é satisfatório.
Solana
A Solana não adota a arquitetura de fragmentação do Polkadot ou do Ethereum, mas sim uma arquitetura de camada única de alta taxa de transferência para alcançar escalabilidade, dependendo da prova histórica (PoH), processamento paralelo de CPU e um mecanismo de consenso baseado em líderes, com um TPS teórico de até 65.000.
Um design chave é o seu mecanismo de agendamento de líderes que é previamente divulgado e verificável:
No início de cada epoch (aproximadamente dois dias ou 432.000 slots), os slots são alocados com base na quantidade de staking;
Quanto mais você aposta, mais você recebe. Por exemplo, um validador que aposta 1% terá cerca de 1% de chance de gerar um bloco;
Todos os mineradores são anunciados antecipadamente, aumentando o risco de ataques DDoS direcionados e interrupções frequentes na rede.
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ó é apostado, maior a oportunidade de produzir blocos, enquanto nós pequenos quase não têm slots, o que agrava ainda mais a centralização e aumenta o risco de paralisação do sistema após um ataque.
A Solana sacrificou a descentralização e a resistência a ataques em busca de TPS, com um coeficiente de Nakamoto de apenas 20, muito abaixo dos 172 da Polkadot.
TON
Um projeto de blockchain afirma que o TPS pode chegar a 104.715, mas esse número foi alcançado em uma rede de teste privada, com 256 nós, em condições ideais de rede e hardware. O Polkadot já alcançou 128K TPS em uma rede pública descentralizada.
O mecanismo de consenso deste projeto apresenta vulnerabilidades de segurança: a identidade dos nós de validação de sharding pode ser exposta antecipadamente. O seu white paper 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 dos apostadores", os atacantes podem esperar que um shard esteja completamente sob seu controle ou interromper validadores honestos através de ataques DDoS, alterando assim o estado.
Em comparação, os validadores do Polkadot são distribuídos aleatoriamente e revelados com atraso, tornando impossível para um atacante saber a identidade dos validadores com antecedência. O ataque deve apostar no controle total 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 rede principal + subredes para escalar, com a rede principal composta por X-Chain (transferências, ~4.500 TPS), C-Chain (contratos inteligentes, ~100-200 TPS) e P-Chain (gerenciamento de validadores e subredes).
Cada sub-rede pode atingir uma TPS teórica de ~5.000, semelhante à abordagem do Polkadot: reduzir a carga de um único shard para alcançar escalabilidade. No entanto, o Avalanche permite que os validadores escolham livremente participar de sub-redes, e essas sub-redes podem estabelecer requisitos adicionais, como geográficos e KYC, sacrificando a descentralização e a segurança.
No Polkadot, todos os rollups compartilham uma garantia de segurança unificada; enquanto as sub-redes do 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 fornecer um compromisso de segurança determinístico.
Ethereum
A estratégia de escalabilidade do Ethereum aposta na escalabilidade da camada rollup, em vez de resolver diretamente os problemas na camada base. Essa abordagem, essencialmente, não resolve o problema, mas sim o transfere para a camada superior da pilha.
Rollup otimista
Atualmente, a maioria dos Optimistic rollups é centralizada (alguns têm apenas um sequenciador), apresentando problemas como falta de segurança, isolamento entre si e alta latência (é necessário aguardar o período de prova de fraude, que normalmente dura 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 conhecimento zero é extremamente alta, e o mecanismo de "vencedor leva tudo" tende a levar à centralização do sistema. Para garantir o TPS, o ZK rollup frequentemente 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 central do Polkadot.
Além disso, os problemas de disponibilidade de dados do ZK rollup também agravarão suas desvantagens. Para garantir que qualquer pessoa possa verificar 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 taxas para os usuários.
Conclusão
O fim da escalabilidade não deve ser um compromisso.
Comparado com outras blockchains públicas, o Polkadot não seguiu o caminho de trocar a centralização por desempenho ou de trocar a confiança pré-estabelecida por eficiência, mas sim alcançou um equilíbrio multidimensional de segurança, descentralização e alto desempenho através de escalabilidade elástica, design de protocolos sem permissão, uma camada de segurança unificada e um mecanismo de gestão de recursos flexível.
Na busca pela aplicação de maior escala hoje em dia, a "escalabilidade sem confiança" defendida pela Polkadot pode ser a verdadeira solução que sustentará o desenvolvimento a longo prazo do Web3.