A escolha e o equilíbrio da escalabilidade do Blockchain: o caso do Polkadot
Na era em que a tecnologia Blockchain busca constantemente maior eficiência, uma questão crucial começa a emergir: como expandir o desempenho sem sacrificar a segurança e a resiliência do sistema? Este é não apenas um desafio no nível técnico, mas também uma escolha profunda no design da arquitetura. Para o ecossistema Web3, um sistema mais rápido, se construído sobre a base do sacrifício da confiança e da segurança, muitas vezes é incapaz de sustentar inovações verdadeiramente sustentáveis.
Como um importante impulsionador da escalabilidade do Web3, o Polkadot fez alguns sacrifícios em relação ao objetivo de alta capacidade de processamento e baixa latência? O seu modelo de rollup fez concessões em descentralização, segurança ou interoperabilidade da rede? Este artigo abordará essas questões, analisando profundamente as escolhas e compromissos do Polkadot no design de escalabilidade, e comparando-os com soluções de outras blockchains principais, explorando suas diferentes opções de caminho entre desempenho, segurança e descentralização.
Desafios enfrentados pelo design de expansão do Polkadot
O equilíbrio entre flexibilidade e descentralização
A arquitetura do Polkadot depende de uma rede de validadores e de uma cadeia de retransmissão. Isso pode introduzir riscos de centralização em certos aspectos? É possível que surjam pontos únicos de falha ou controle, afetando suas características de descentralização?
A operação do Rollup depende dos ordenadores da cadeia de retransmissão conectada, 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 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, bastando atender a uma premissa: deve ser uma conversão de estado válida, caso contrário, o estado do rollup não será avançado.
Compromissos de expansão vertical
Rollup pode alcançar escalabilidade vertical ao aproveitar a arquitetura multi-core do Polkadot. Esta nova capacidade foi introduzida pela funcionalidade de "escalabilidade elástica". Durante o processo de design, foi descoberto que, uma vez que a validação de blocos rollup não é fixada em um único core, isso pode afetar sua elasticidade.
Como o protocolo para submeter blocos à cadeia de retransmissão é sem permissão e sem confiança, qualquer um pode submeter blocos a qualquer core atribuído ao rollup para validação. Ataques podem explorar isso, submetendo repetidamente blocos legítimos que já foram validados a diferentes cores, consumindo recursos de forma maliciosa, o que reduz a capacidade 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.
O 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 os ordenadores não agirão de forma maliciosa, 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 alteração de estado do rollup.
Polkadot: Solução Sem Compromissos
A solução finalmente escolhida pelo Polkadot é: deixar a questão completamente nas mãos 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 explicitamente declarado onde a validação deve ser executada no core do Polkadot.
Este design proporciona uma dupla garantia de resiliência e segurança. O Polkadot irá reexecutar a transição 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 bloco rollup escreva na camada de disponibilidade de dados do Polkadot, um grupo composto por cerca de 5 validadores irá primeiro verificar sua legalidade. Eles recebem os recibos candidatos e as provas de validade submetidos pelo organizador, 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, e serão reexecutadas pelos validadores na cadeia de retransmissão.
O resultado da verificação inclui um core selector, que é usado para especificar em qual core o bloco deve ser validado. O validador irá comparar se o índice corresponde ao core pelo qual é responsável; se não corresponder, o bloco será descartado.
Este mecanismo garante que o sistema mantenha sempre as propriedades de não confiança e de não permissão, evitando que agentes maliciosos como ordenadores manipulem a posição de verificação, assegurando que mesmo que o rollup utilize múltiplos núcleos, a resiliência seja mantida.
Segurança
No processo de busca pela escalabilidade, a Polkadot não comprometeu a segurança. A segurança dos rollups é garantida pela cadeia de retransmissão, sendo necessário apenas um ordenado honesto para manter a sobrevivência.
Com o protocolo ELVES, Polkadot estende sua segurança de forma completa a todos os rollups, validando todos os cálculos no núcleo, sem a necessidade de impor limitações ou fazer suposições sobre o número de núcleos utilizados.
Assim, os rollups do Polkadot podem alcançar uma verdadeira escalabilidade sem sacrificar a segurança.
Versatilidade
A escalabilidade elástica não limitará a programabilidade dos rollups. O modelo de rollup do Polkadot suporta a execução de cálculos Turing-completos no ambiente WebAssembly, desde que a execução única seja concluída em menos de 2 segundos. Com a escalabilidade elástica, a quantidade total de cálculos que podem ser executados a cada 6 segundos é aumentada, mas o tipo de cálculo não é afetado.
Complexidade
Taxa de transferência mais alta e latência mais baixa 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 atender parcialmente aos requisitos do RFC103 para se adaptar 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 cargas de transação específicas no mempool do nó;
Estratégia de automação: configurar recursos antecipadamente chamando o serviço coretime 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, enquanto a escalabilidade elástica não afeta a taxa de transferência 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 da camada de dados. Esta atualização permitirá que a capacidade de comunicação entre rollups seja aprimorada juntamente com a escalabilidade elástica, aumentando ainda mais a capacidade de escalabilidade vertical do sistema.
Que compromissos foram feitos por outros protocolos?
É bem sabido que o aumento de desempenho muitas vezes vem à custa da descentralização e da segurança. Mas, do ponto de vista do coeficiente de Nakamoto, mesmo que alguns concorrentes do Polkadot tenham um nível de descentralização mais baixo, o seu desempenho não é satisfatório.
Solana
A Solana não utiliza a arquitetura de sharding do Polkadot ou do Ethereum, mas sim uma arquitetura de alta capacidade de processamento em uma única camada para alcançar escalabilidade, dependendo de provas históricas, processamento paralelo em CPU e um mecanismo de consenso baseado em líderes, com TPS teórico de até 65.000.
Um design chave é o seu mecanismo de agendamento de líderes que é publicamente divulgado e verificável:
No início de cada epoch (cerca de dois dias ou 432.000 slots), os slots são distribuídos com base na quantidade de staking;
Quanto mais você stakear, mais você receberá. Por exemplo, um validador que stakeia 1% terá cerca de 1% de chance de produzir blocos;
Todos os blocos são anunciados antecipadamente, o que aumenta o risco de ataques DDoS direcionados e quedas frequentes da rede.
A história prova que o processamento paralelo exige um alto nível de hardware, levando à centralização dos nós de validação. Quanto mais nós estiverem em staking, maior será a chance de produzir blocos, enquanto pequenos nós quase não têm slots, o que agrava ainda mais a centralização e aumenta o risco de falência do sistema após um ataque.
A Solana sacrifica 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 e em condições ideais de rede e hardware. Já o Polkadot atingiu 128K TPS em uma rede pública descentralizada.
O mecanismo de consenso do TON apresenta riscos de segurança: a identidade dos nós de verificação de fragmentos pode ser exposta antecipadamente. O white paper do TON também destaca que, embora isso possa otimizar a largura de banda, também pode ser explorado maliciosamente. Devido à falta de um mecanismo de "falência de apostadores", os atacantes podem esperar que um fragmento esteja completamente sob seu controle ou bloquear validadores honestos através de ataques DDoS, alterando assim o estado.
Em comparação, os validadores do Polkadot são atribuídos aleatoriamente e revelados com atraso, os atacantes não conseguem saber de antemão a identidade dos validadores, o ataque deve apostar todo o controle para ser bem-sucedido, desde que haja um validador honesto que inicie uma disputa, o ataque falhará e resultará na perda do depósito do atacante.
Avalanche
Avalanche utiliza uma arquitetura de mainnet + subnets para escalabilidade, sendo a mainnet composta por X-Chain (transferências, ~4.500 TPS), C-Chain (contratos inteligentes, ~100-200 TPS) e P-Chain (gestão de validadores e subnets).
Cada sub-rede pode teoricamente alcançar um TPS de ~5.000, semelhante à abordagem do Polkadot: reduzir a carga de um único shard para alcançar a escalabilidade. No entanto, a Avalanche permite que os validadores escolham livremente participar de sub-redes, e as sub-redes podem definir requisitos adicionais, como geografia e KYC, sacrificando a descentralização e a segurança.
No Polkadot, todos os rollups partilham 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 melhorar a segurança, ainda é necessário comprometer o desempenho, e é difícil fornecer promessas de segurança determinísticas.
Ethereum
A estratégia de escalabilidade do Ethereum aposta na escalabilidade da camada rollup, em vez de resolver o problema diretamente na camada base. Essa abordagem, na essência, 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 sequenciador), apresentando problemas como segurança insuficiente, isolamento entre si e alta latência (é necessário aguardar o período de prova de fraude, que geralmente leva dias).
ZK Rollup
A implementação de 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 "o vencedor leva tudo" tende a centralizar o sistema. Para garantir o TPS, ZK rollup muitas vezes limita o volume de transações por lote, o que pode causar congestão na rede e aumento do gas em períodos de alta demanda, afetando a experiência do usuário.
Em comparação, o custo do ZK rollup totalmente funcional é cerca de 2x10^6 vezes o protocolo de segurança da economia 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 verificar as transações, ainda é necessário fornecer dados de transação completos. 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 centralização por desempenho ou 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 escalabilidade flexível, 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 implementação em maior escala hoje, a "escalabilidade sem confiança" defendida pela Polkadot pode ser a verdadeira solução que sustenta o desenvolvimento a longo prazo da 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.
Escalabilidade flexível do Polkadot: buscando um equilíbrio entre desempenho e Descentralização
A escolha e o equilíbrio da escalabilidade do Blockchain: o caso do Polkadot
Na era em que a tecnologia Blockchain busca constantemente maior eficiência, uma questão crucial começa a emergir: como expandir o desempenho sem sacrificar a segurança e a resiliência do sistema? Este é não apenas um desafio no nível técnico, mas também uma escolha profunda no design da arquitetura. Para o ecossistema Web3, um sistema mais rápido, se construído sobre a base do sacrifício da confiança e da segurança, muitas vezes é incapaz de sustentar inovações verdadeiramente sustentáveis.
Como um importante impulsionador da escalabilidade do Web3, o Polkadot fez alguns sacrifícios em relação ao objetivo de alta capacidade de processamento e baixa latência? O seu modelo de rollup fez concessões em descentralização, segurança ou interoperabilidade da rede? Este artigo abordará essas questões, analisando profundamente as escolhas e compromissos do Polkadot no design de escalabilidade, e comparando-os com soluções de outras blockchains principais, explorando suas diferentes opções de caminho entre desempenho, segurança e descentralização.
Desafios enfrentados pelo design de expansão do Polkadot
O equilíbrio entre flexibilidade e descentralização
A arquitetura do Polkadot depende de uma rede de validadores e de uma cadeia de retransmissão. Isso pode introduzir riscos de centralização em certos aspectos? É possível que surjam pontos únicos de falha ou controle, afetando suas características de descentralização?
A operação do Rollup depende dos ordenadores da cadeia de retransmissão conectada, 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 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, bastando atender a uma premissa: deve ser uma conversão de estado válida, caso contrário, o estado do rollup não será avançado.
Compromissos de expansão vertical
Rollup pode alcançar escalabilidade vertical ao aproveitar a arquitetura multi-core do Polkadot. Esta nova capacidade foi introduzida pela funcionalidade de "escalabilidade elástica". Durante o processo de design, foi descoberto que, uma vez que a validação de blocos rollup não é fixada em um único core, isso pode afetar sua elasticidade.
Como o protocolo para submeter blocos à cadeia de retransmissão é sem permissão e sem confiança, qualquer um pode submeter blocos a qualquer core atribuído ao rollup para validação. Ataques podem explorar isso, submetendo repetidamente blocos legítimos que já foram validados a diferentes cores, consumindo recursos de forma maliciosa, o que reduz a capacidade 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.
O 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 os ordenadores não agirão de forma maliciosa, 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 alteração de estado do rollup.
Polkadot: Solução Sem Compromissos
A solução finalmente escolhida pelo Polkadot é: deixar a questão completamente nas mãos 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 explicitamente declarado onde a validação deve ser executada no core do Polkadot.
Este design proporciona uma dupla garantia de resiliência e segurança. O Polkadot irá reexecutar a transição 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 bloco rollup escreva na camada de disponibilidade de dados do Polkadot, um grupo composto por cerca de 5 validadores irá primeiro verificar sua legalidade. Eles recebem os recibos candidatos e as provas de validade submetidos pelo organizador, 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, e serão reexecutadas pelos validadores na cadeia de retransmissão.
O resultado da verificação inclui um core selector, que é usado para especificar em qual core o bloco deve ser validado. O validador irá comparar se o índice corresponde ao core pelo qual é responsável; se não corresponder, o bloco será descartado.
Este mecanismo garante que o sistema mantenha sempre as propriedades de não confiança e de não permissão, evitando que agentes maliciosos como ordenadores manipulem a posição de verificação, assegurando que mesmo que o rollup utilize múltiplos núcleos, a resiliência seja mantida.
Segurança
No processo de busca pela escalabilidade, a Polkadot não comprometeu a segurança. A segurança dos rollups é garantida pela cadeia de retransmissão, sendo necessário apenas um ordenado honesto para manter a sobrevivência.
Com o protocolo ELVES, Polkadot estende sua segurança de forma completa a todos os rollups, validando todos os cálculos no núcleo, sem a necessidade de impor limitações ou fazer suposições sobre o número de núcleos utilizados.
Assim, os rollups do Polkadot podem alcançar uma verdadeira escalabilidade sem sacrificar a segurança.
Versatilidade
A escalabilidade elástica não limitará a programabilidade dos rollups. O modelo de rollup do Polkadot suporta a execução de cálculos Turing-completos no ambiente WebAssembly, desde que a execução única seja concluída em menos de 2 segundos. Com a escalabilidade elástica, a quantidade total de cálculos que podem ser executados a cada 6 segundos é aumentada, mas o tipo de cálculo não é afetado.
Complexidade
Taxa de transferência mais alta e latência mais baixa 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 atender parcialmente aos requisitos do RFC103 para se adaptar 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 cargas de transação específicas no mempool do nó;
Estratégia de automação: configurar recursos antecipadamente chamando o serviço coretime 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, enquanto a escalabilidade elástica não afeta a taxa de transferência 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 da camada de dados. Esta atualização permitirá que a capacidade de comunicação entre rollups seja aprimorada juntamente com a escalabilidade elástica, aumentando ainda mais a capacidade de escalabilidade vertical do sistema.
Que compromissos foram feitos por outros protocolos?
É bem sabido que o aumento de desempenho muitas vezes vem à custa da descentralização e da segurança. Mas, do ponto de vista do coeficiente de Nakamoto, mesmo que alguns concorrentes do Polkadot tenham um nível de descentralização mais baixo, o seu desempenho não é satisfatório.
Solana
A Solana não utiliza a arquitetura de sharding do Polkadot ou do Ethereum, mas sim uma arquitetura de alta capacidade de processamento em uma única camada para alcançar escalabilidade, dependendo de provas históricas, processamento paralelo em CPU e um mecanismo de consenso baseado em líderes, com TPS teórico de até 65.000.
Um design chave é o seu mecanismo de agendamento de líderes que é publicamente divulgado e verificável:
No início de cada epoch (cerca de dois dias ou 432.000 slots), os slots são distribuídos com base na quantidade de staking;
Quanto mais você stakear, mais você receberá. Por exemplo, um validador que stakeia 1% terá cerca de 1% de chance de produzir blocos;
Todos os blocos são anunciados antecipadamente, o que aumenta o risco de ataques DDoS direcionados e quedas frequentes da rede.
A história prova que o processamento paralelo exige um alto nível de hardware, levando à centralização dos nós de validação. Quanto mais nós estiverem em staking, maior será a chance de produzir blocos, enquanto pequenos nós quase não têm slots, o que agrava ainda mais a centralização e aumenta o risco de falência do sistema após um ataque.
A Solana sacrifica 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 e em condições ideais de rede e hardware. Já o Polkadot atingiu 128K TPS em uma rede pública descentralizada.
O mecanismo de consenso do TON apresenta riscos de segurança: a identidade dos nós de verificação de fragmentos pode ser exposta antecipadamente. O white paper do TON também destaca que, embora isso possa otimizar a largura de banda, também pode ser explorado maliciosamente. Devido à falta de um mecanismo de "falência de apostadores", os atacantes podem esperar que um fragmento esteja completamente sob seu controle ou bloquear validadores honestos através de ataques DDoS, alterando assim o estado.
Em comparação, os validadores do Polkadot são atribuídos aleatoriamente e revelados com atraso, os atacantes não conseguem saber de antemão a identidade dos validadores, o ataque deve apostar todo o controle para ser bem-sucedido, desde que haja um validador honesto que inicie uma disputa, o ataque falhará e resultará na perda do depósito do atacante.
Avalanche
Avalanche utiliza uma arquitetura de mainnet + subnets para escalabilidade, sendo a mainnet composta por X-Chain (transferências, ~4.500 TPS), C-Chain (contratos inteligentes, ~100-200 TPS) e P-Chain (gestão de validadores e subnets).
Cada sub-rede pode teoricamente alcançar um TPS de ~5.000, semelhante à abordagem do Polkadot: reduzir a carga de um único shard para alcançar a escalabilidade. No entanto, a Avalanche permite que os validadores escolham livremente participar de sub-redes, e as sub-redes podem definir requisitos adicionais, como geografia e KYC, sacrificando a descentralização e a segurança.
No Polkadot, todos os rollups partilham 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 melhorar a segurança, ainda é necessário comprometer o desempenho, e é difícil fornecer promessas de segurança determinísticas.
Ethereum
A estratégia de escalabilidade do Ethereum aposta na escalabilidade da camada rollup, em vez de resolver o problema diretamente na camada base. Essa abordagem, na essência, 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 sequenciador), apresentando problemas como segurança insuficiente, isolamento entre si e alta latência (é necessário aguardar o período de prova de fraude, que geralmente leva dias).
ZK Rollup
A implementação de 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 "o vencedor leva tudo" tende a centralizar o sistema. Para garantir o TPS, ZK rollup muitas vezes limita o volume de transações por lote, o que pode causar congestão na rede e aumento do gas em períodos de alta demanda, afetando a experiência do usuário.
Em comparação, o custo do ZK rollup totalmente funcional é cerca de 2x10^6 vezes o protocolo de segurança da economia 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 verificar as transações, ainda é necessário fornecer dados de transação completos. 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 centralização por desempenho ou 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 escalabilidade flexível, 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 implementação em maior escala hoje, a "escalabilidade sem confiança" defendida pela Polkadot pode ser a verdadeira solução que sustenta o desenvolvimento a longo prazo da Web3.