A ponderação da escalabilidade do Blockchain: Polkadot e a escolha do Web3
Hoje, em um contexto em que a tecnologia Blockchain busca constantemente maior eficiência, uma questão crucial vem à tona: como melhorar o desempenho mantendo a segurança e a resiliência do sistema? Isso não é apenas um desafio técnico, mas uma escolha profunda de design arquitetônico. Para o ecossistema Web3, um sistema que é apenas mais rápido, se construído sobre a sacrifício da confiança e da segurança, muitas vezes tem dificuldade em sustentar inovações realmente sustentáveis.
Como um importante impulsionador da escalabilidade do Web3, a Polkadot fez algumas concessões na busca por alta taxa de transferência e baixa latência? O seu modelo de rollup fez concessões em descentralização, segurança ou interoperabilidade da rede? Este artigo irá discutir essas questões, analisando profundamente as escolhas e compromissos da Polkadot no design da escalabilidade, e comparando-as com as soluções de outras blockchains principais, explorando suas diferentes escolhas de caminhos entre desempenho, segurança e descentralização.
Desafios enfrentados pelo design de expansão do Polkadot
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 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 de um ordenadora 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 um pequeno número de nós da cadeia de retransmissão e submetendo solicitações de transição de estado do rollup. Essas solicitações serão verificadas por algum core da cadeia de retransmissão, bastando atender a uma condição: deve ser uma transição de estado válida, caso contrário, o estado do rollup não será avançado.
Compromisso de expansão vertical
O Rollup pode alcançar a escalabilidade vertical ao utilizar a arquitetura multicore do Polkadot. Essa nova capacidade é introduzida pela funcionalidade de "escalabilidade elástica". Durante o processo de design, foi descoberto que, como a validação de blocos de rollup não é executada de forma fixa em um único core, isso pode afetar sua elasticidade.
Como o protocolo para submeter blocos à cadeia de relé é sem permissão e sem confiança, qualquer pessoa pode submeter um bloco a qualquer core atribuído ao rollup para validação. Os atacantes podem explorar isso, submetendo repetidamente blocos legítimos que já foram validados a diferentes cores, consumindo recursos de forma maliciosa 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 fundamentais do sistema.
O Sequencer é confiável?
Uma solução simples é definir o protocolo como "com licença": por exemplo, adotar um mecanismo de lista branca, ou confiar por default que os ordenadores não terão comportamentos maliciosos, garantindo assim a atividade do rollup.
No entanto, na filosofia de design do Polkadot, não podemos fazer quaisquer suposições 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 ser capaz de usar o protocolo collator para submeter pedidos de transformação de estado do rollup.
Polkadot: uma solução intransigente
A solução escolhida pelo Polkadot é: deixar o problema completamente nas mãos 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 explicitamente em qual núcleo do Polkadot a validação deve ser executada.
Este design garante uma dupla proteção de flexibilidade e segurança. 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 de rollup seja escrito na camada de disponibilidade de dados do Polkadot, um grupo composto por cerca de 5 validadores validará sua legalidade. Eles recebem os recibos candidatos e as provas de validade submetidos pelo ordenadores, que contêm blocos de 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, que é utilizado para especificar em qual core o bloco deve ser validado. O validador irá comparar se esse índice é consistente com o core pelo qual é responsável; caso contrário, o bloco será descartado.
Este mecanismo assegura que o sistema mantenha sempre as propriedades de sem confiança e sem permissão, evitando que actores maliciosos, como os ordenadores, manipulem a posição de validação, garantindo que mesmo quando o rollup utiliza múltiplos núcleos, a elasticidade seja mantida.
Segurança
No processo de busca por escalabilidade, a Polkadot não comprometeu a segurança. A segurança do rollup é garantida pela cadeia de retransmissão, sendo necessário apenas um ordenator honesto para manter a viabilidade.
Com o protocolo ELVES, o Polkadot expande completamente a sua segurança a todos os rollups, validando todos os cálculos no core, sem precisar impor quaisquer limitações ou suposições sobre o número de núcleos utilizados.
Portanto, o rollup do Polkadot pode alcançar uma verdadeira escalabilidade sem sacrificar a segurança.
Universalidade
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 que podem ser realizados em um ciclo de 6 segundos é 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 compromisso 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 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: sempre usar uma quantidade fixa de core, ou ajustar manualmente off-chain;
Estratégia leve: monitorizar a carga de transações específicas no mempool do nó;
Estratégia de automação: Configurar recursos chamando antecipadamente 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 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 alocados.
No futuro, o Polkadot também suportará a comunicação off-chain, com a cadeia de retransmissão agindo como a camada de controle, em vez da camada de dados. Esta atualização permitirá que a capacidade de comunicação entre rollups seja melhorada 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 desempenho deles não é satisfatório.
Solana
A Solana não utiliza a arquitetura de sharding do Polkadot ou do Ethereum, mas sim uma arquitetura de camada única de alto throughput para alcançar a escalabilidade, dependendo da prova histórica (PoH), do processamento paralelo pela 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:
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 se aposta, mais se distribui. Por exemplo, um validador que aposta 1% terá cerca de 1% de chance de produzir blocos;
Todos os produtores de blocos são anunciados antecipadamente, aumentando o risco de ataques DDoS direcionados à rede e frequentes falhas.
PoH e o processamento paralelo exigem hardware extremamente alto, levando à centralização dos nós de validação. Quanto mais tokens são apostados, maior é a chance de um nó produzir um bloco, enquanto os nós menores 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 destaca que, embora isso possa otimizar a largura de banda, também pode ser explorado maliciosamente. Devido à falta de um mecanismo de "falência do apostador", os atacantes podem esperar que um fragmento seja totalmente controlado por eles ou bloquear validadores honestos por meio de ataques DDoS, alterando assim o estado.
Em comparação, os validadores do Polkadot são distribuídos aleatoriamente e revelados com atraso, o que impede que os atacantes conheçam previamente a identidade dos validadores. O ataque deve apostar no sucesso do controle total; 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 + sub-rede para escalar, onde 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 sub-redes).
Cada sub-rede pode alcançar uma TPS teórica de ~5.000, semelhante à abordagem do Polkadot: reduzir a carga de um único shard para conseguir escalabilidade. No entanto, o Avalanche permite que os validadores escolham livremente participar de sub-redes, e as sub-redes podem definir requisitos adicionais como geográficos 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 totalmente centralizadas. Para aumentar a segurança, ainda é necessário comprometer o desempenho, e é difícil fornecer 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 o problema diretamente na camada base. Essa abordagem, em essência, não resolve o problema, mas o transfere para a camada superior da pilha.
Optimistic Rollup
Atualmente, a maioria das Optimistic rollups é centralizada (algumas têm até um único 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 dura alguns dias).
ZK Rollup
A implementação do ZK rollup é limitada pela quantidade de dados que podem ser processados em uma única transação. A necessidade de cálculo para gerar provas de conhecimento zero é extremamente alta, e o mecanismo de "ganhador leva tudo" pode levar à centralização do sistema. Para garantir TPS, o ZK rollup frequentemente limita o volume 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, o problema de disponibilidade de dados do ZK rollup também agrava suas desvantagens. Para garantir que qualquer pessoa possa validar as transações, ainda é necessário fornecer dados de transação completos. Isso geralmente depende de soluções de disponibilidade de dados adicionais, 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é-estabelecida por eficiência, mas sim alcançou um equilíbrio multidimensional de segurança, descentralização e alto desempenho através de uma expansão elástica, design de protocolo sem permissão, camada de segurança unificada e mecanismos flexíveis de gestão de recursos.
Na busca pela implementação em maior escala hoje, a "escalabilidade de zero confiança" defendida pelo Polkadot pode ser a verdadeira solução que sustenta 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.
A escalabilidade flexível do Polkadot: uma solução sem compromissos no ecossistema Web3
A ponderação da escalabilidade do Blockchain: Polkadot e a escolha do Web3
Hoje, em um contexto em que a tecnologia Blockchain busca constantemente maior eficiência, uma questão crucial vem à tona: como melhorar o desempenho mantendo a segurança e a resiliência do sistema? Isso não é apenas um desafio técnico, mas uma escolha profunda de design arquitetônico. Para o ecossistema Web3, um sistema que é apenas mais rápido, se construído sobre a sacrifício da confiança e da segurança, muitas vezes tem dificuldade em sustentar inovações realmente sustentáveis.
Como um importante impulsionador da escalabilidade do Web3, a Polkadot fez algumas concessões na busca por alta taxa de transferência e baixa latência? O seu modelo de rollup fez concessões em descentralização, segurança ou interoperabilidade da rede? Este artigo irá discutir essas questões, analisando profundamente as escolhas e compromissos da Polkadot no design da escalabilidade, e comparando-as com as soluções de outras blockchains principais, explorando suas diferentes escolhas de caminhos entre desempenho, segurança e descentralização.
Desafios enfrentados pelo design de expansão do Polkadot
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 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 de um ordenadora 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 um pequeno número de nós da cadeia de retransmissão e submetendo solicitações de transição de estado do rollup. Essas solicitações serão verificadas por algum core da cadeia de retransmissão, bastando atender a uma condição: deve ser uma transição de estado válida, caso contrário, o estado do rollup não será avançado.
Compromisso de expansão vertical
O Rollup pode alcançar a escalabilidade vertical ao utilizar a arquitetura multicore do Polkadot. Essa nova capacidade é introduzida pela funcionalidade de "escalabilidade elástica". Durante o processo de design, foi descoberto que, como a validação de blocos de rollup não é executada de forma fixa em um único core, isso pode afetar sua elasticidade.
Como o protocolo para submeter blocos à cadeia de relé é sem permissão e sem confiança, qualquer pessoa pode submeter um bloco a qualquer core atribuído ao rollup para validação. Os atacantes podem explorar isso, submetendo repetidamente blocos legítimos que já foram validados a diferentes cores, consumindo recursos de forma maliciosa 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 fundamentais do sistema.
O Sequencer é confiável?
Uma solução simples é definir o protocolo como "com licença": por exemplo, adotar um mecanismo de lista branca, ou confiar por default que os ordenadores não terão comportamentos maliciosos, garantindo assim a atividade do rollup.
No entanto, na filosofia de design do Polkadot, não podemos fazer quaisquer suposições 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 ser capaz de usar o protocolo collator para submeter pedidos de transformação de estado do rollup.
Polkadot: uma solução intransigente
A solução escolhida pelo Polkadot é: deixar o problema completamente nas mãos 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 explicitamente em qual núcleo do Polkadot a validação deve ser executada.
Este design garante uma dupla proteção de flexibilidade e segurança. 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 de rollup seja escrito na camada de disponibilidade de dados do Polkadot, um grupo composto por cerca de 5 validadores validará sua legalidade. Eles recebem os recibos candidatos e as provas de validade submetidos pelo ordenadores, que contêm blocos de 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, que é utilizado para especificar em qual core o bloco deve ser validado. O validador irá comparar se esse índice é consistente com o core pelo qual é responsável; caso contrário, o bloco será descartado.
Este mecanismo assegura que o sistema mantenha sempre as propriedades de sem confiança e sem permissão, evitando que actores maliciosos, como os ordenadores, manipulem a posição de validação, garantindo que mesmo quando o rollup utiliza múltiplos núcleos, a elasticidade seja mantida.
Segurança
No processo de busca por escalabilidade, a Polkadot não comprometeu a segurança. A segurança do rollup é garantida pela cadeia de retransmissão, sendo necessário apenas um ordenator honesto para manter a viabilidade.
Com o protocolo ELVES, o Polkadot expande completamente a sua segurança a todos os rollups, validando todos os cálculos no core, sem precisar impor quaisquer limitações ou suposições sobre o número de núcleos utilizados.
Portanto, o rollup do Polkadot pode alcançar uma verdadeira escalabilidade sem sacrificar a segurança.
Universalidade
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 que podem ser realizados em um ciclo de 6 segundos é 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 compromisso 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 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: sempre usar uma quantidade fixa de core, ou ajustar manualmente off-chain;
Estratégia leve: monitorizar a carga de transações específicas no mempool do nó;
Estratégia de automação: Configurar recursos chamando antecipadamente 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 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 alocados.
No futuro, o Polkadot também suportará a comunicação off-chain, com a cadeia de retransmissão agindo como a camada de controle, em vez da camada de dados. Esta atualização permitirá que a capacidade de comunicação entre rollups seja melhorada 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 desempenho deles não é satisfatório.
Solana
A Solana não utiliza a arquitetura de sharding do Polkadot ou do Ethereum, mas sim uma arquitetura de camada única de alto throughput para alcançar a escalabilidade, dependendo da prova histórica (PoH), do processamento paralelo pela 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:
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 se aposta, mais se distribui. Por exemplo, um validador que aposta 1% terá cerca de 1% de chance de produzir blocos;
Todos os produtores de blocos são anunciados antecipadamente, aumentando o risco de ataques DDoS direcionados à rede e frequentes falhas.
PoH e o processamento paralelo exigem hardware extremamente alto, levando à centralização dos nós de validação. Quanto mais tokens são apostados, maior é a chance de um nó produzir um bloco, enquanto os nós menores 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 destaca que, embora isso possa otimizar a largura de banda, também pode ser explorado maliciosamente. Devido à falta de um mecanismo de "falência do apostador", os atacantes podem esperar que um fragmento seja totalmente controlado por eles ou bloquear validadores honestos por meio de ataques DDoS, alterando assim o estado.
Em comparação, os validadores do Polkadot são distribuídos aleatoriamente e revelados com atraso, o que impede que os atacantes conheçam previamente a identidade dos validadores. O ataque deve apostar no sucesso do controle total; 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 + sub-rede para escalar, onde 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 sub-redes).
Cada sub-rede pode alcançar uma TPS teórica de ~5.000, semelhante à abordagem do Polkadot: reduzir a carga de um único shard para conseguir escalabilidade. No entanto, o Avalanche permite que os validadores escolham livremente participar de sub-redes, e as sub-redes podem definir requisitos adicionais como geográficos 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 totalmente centralizadas. Para aumentar a segurança, ainda é necessário comprometer o desempenho, e é difícil fornecer 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 o problema diretamente na camada base. Essa abordagem, em essência, não resolve o problema, mas o transfere para a camada superior da pilha.
Optimistic Rollup
Atualmente, a maioria das Optimistic rollups é centralizada (algumas têm até um único 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 dura alguns dias).
ZK Rollup
A implementação do ZK rollup é limitada pela quantidade de dados que podem ser processados em uma única transação. A necessidade de cálculo para gerar provas de conhecimento zero é extremamente alta, e o mecanismo de "ganhador leva tudo" pode levar à centralização do sistema. Para garantir TPS, o ZK rollup frequentemente limita o volume 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, o problema de disponibilidade de dados do ZK rollup também agrava suas desvantagens. Para garantir que qualquer pessoa possa validar as transações, ainda é necessário fornecer dados de transação completos. Isso geralmente depende de soluções de disponibilidade de dados adicionais, 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é-estabelecida por eficiência, mas sim alcançou um equilíbrio multidimensional de segurança, descentralização e alto desempenho através de uma expansão elástica, design de protocolo sem permissão, camada de segurança unificada e mecanismos flexíveis de gestão de recursos.
Na busca pela implementação em maior escala hoje, a "escalabilidade de zero confiança" defendida pelo Polkadot pode ser a verdadeira solução que sustenta o desenvolvimento a longo prazo do Web3.