A ponderação da escalabilidade da Blockchain: A escolha entre Polkadot e Web3
No contexto atual de busca por eficiência na blockchain, uma questão chave 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 a nível técnico, mas uma escolha profunda no design da arquitetura. Para o ecossistema Web3, apenas buscar sistemas mais rápidos enquanto ignora a confiança e a segurança torna difícil sustentar inovações verdadeiramente sustentáveis.
Como um importante impulsionador da escalabilidade do Web3, o Polkadot fez algumas concessões na busca por alta taxa de transferência e baixa latência? O seu modelo rollup comprometeu-se em termos de descentralização, segurança ou interoperabilidade da rede?
Este artigo discutirá estas questões, analisando a fundo as compensações do Polkadot no design de escalabilidade e comparando-as com as soluções de outras blockchains principais, explorando as diferentes escolhas 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. Isso pode, de alguma forma, introduzir riscos de centralização? É possível que surjam pontos únicos de falha ou controle, afetando assim suas características de descentralização?
A execução do Rollup depende do ordenadores da cadeia de retransmissão, cuja comunicação utiliza o mecanismo de protocolo collator. Este protocolo é completamente sem permissão e sem confiança, qualquer pessoa com conexão à rede pode usá-lo, conectando-se a alguns nós da cadeia de retransmissão e enviando solicitações de conversão de estado do rollup. Essas solicitações serão verificadas 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 expansão vertical
O Rollup pode alcançar a escalabilidade vertical ao aproveitar a arquitetura multicore do Polkadot. Esta 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 é fixa 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 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 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 relé, sem comprometer as características chave do sistema.
O Sequencer é confiável?
Uma solução simples é definir o protocolo como "com licença": por exemplo, adotando um mecanismo de lista branca, ou confiando por defeito que o ordenadores não se comportarã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 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 enviar pedidos de alteração de estado do rollup.
Polkadot: uma solução sem compromissos
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 em qual núcleo do Polkadot a validação deve ser executada.
Este design alcançou uma dupla garantia de elasticidade e segurança. O Polkadot executará novamente a conversã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 de qualquer bloco de rollup ser escrito 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 de rollup e as provas de armazenamento correspondentes. 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 especifica em qual core o bloco deve ser verificado. 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 não permissão, evitando que agentes maliciosos, como ordenadores, manipulem a posição de validação, garantindo que mesmo que o rollup utilize múltiplos cores, possa manter a resiliência.
Segurança
Durante o processo de busca por escalabilidade, o 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, o Polkadot estende a sua segurança de forma completa a todos os rollups, validando todos os cálculos no core, sem a necessidade de impor quaisquer limitações ou suposições sobre o número de núcleos utilizados.
Assim, o rollup do Polkadot pode 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 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 em cada 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 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 a alguns 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: chamar antecipadamente o serviço coretime através de dados históricos e da interface XCM para configurar recursos.
Embora o método automatizado 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 elastica 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, Polkadot também irá suportar a comunicação off-chain, com a cadeia de retransmissão a funcionar como a camada de controle, em vez da camada de dados. Esta atualização irá melhorar a capacidade de comunicação entre rollups, aumentando juntamente a escalabilidade elástica, e reforçando ainda mais a capacidade de escalabilidade vertical do sistema.
Compromissos de outros protocolos
É de conhecimento geral 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, 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 camada única de alta capacidade de processamento para alcançar escalabilidade, dependendo da prova histórica (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 pré-publicado e verificável:
No início de cada epoch (cerca de dois dias ou 432.000 slots), os slots são alocados com base na quantidade de staking;
Quanto mais se faz staking, mais se distribui. Por exemplo, um validador que faz staking de 1% terá aproximadamente 1% de chance de produzir um bloco;
Todos os mineradores são anunciados antecipadamente, aumentando o risco de ataques DDoS direcionados e paragens frequentes da rede.
PoH e o processamento paralelo exigem hardware extremamente elevado, levando à centralização dos nós de validação. Quanto mais estacado, maior a chance de um nó produzir blocos, enquanto os nós pequenos quase não têm slots, exacerbando ainda mais a centralização e aumentando 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 inferior aos 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. Por outro lado, a Polkadot já alcançou 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 validação de fragmentos pode ser exposta antecipadamente. O white paper do TON também aponta 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 fragmento esteja sob seu controle total ou bloquear 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, de modo que os atacantes não podem saber antecipadamente a identidade dos validadores. O ataque precisa apostá-los todos para ter sucesso; assim que um validador honesto iniciar uma disputa, o ataque falhará e resultará na perda do depósito do atacante.
Avalanche
Avalanche utiliza uma arquitetura de rede principal + sub-rede para escalabilidade, onde a rede principal é composta pela 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 teoricamente alcançar ~5.000 TPS, semelhante à abordagem do Polkadot: reduzir a carga de um único bloco para alcançar a escalabilidade. No entanto, o Avalanche permite que os validadores escolham livremente participar de sub-rede, 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 isso, as sub-redes do Avalanche não têm garantias de segurança por padrão, e algumas podem ser completamente 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. Essencialmente, essa abordagem não resolve o problema, mas o transfere para a camada superior da pilha.
Optimistic Rollup
Atualmente, a maioria das rollups otimistas é centralizada (algumas têm apenas um sequenciador), enfrentando problemas de segurança insuficiente, isolamento entre si e alta latência (é necessário esperar pelo período de prova de fraude, que geralmente dura vários dias).
ZK Rollup
A implementação do ZK rollup é limitada pela quantidade de dados que uma única transação pode processar. A necessidade computacional para gerar provas de conhecimento zero é extremamente alta, e o mecanismo de "o vencedor leva tudo" pode levar à centralização do sistema. Para garantir o TPS, o ZK rollup frequentemente limita o volume de transações por lote, o que pode causar congestionamento da rede e aumento do gas em momentos 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 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 descentralização por desempenho ou de trocar confiança pré-estabelecida 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 aplicação em maior escala hoje, a "escalabilidade de zero confiança" defendida pelo 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.
16 Curtidas
Recompensa
16
6
Repostar
Compartilhar
Comentário
0/400
Fren_Not_Food
· 07-23 13:22
O projeto parece bastante promissor, vamos ver o desempenho real.
Ver originalResponder0
BlockchainDecoder
· 07-23 11:10
Citando dados recentes do grupo de pesquisa Cho, o tps de cadeia única é geralmente inferior a 3k, e a questão do equilíbrio precisa ser superada urgentemente.
Polkadot sem compromissos de escalabilidade: uma nova opção para o ecossistema Web3
A ponderação da escalabilidade da Blockchain: A escolha entre Polkadot e Web3
No contexto atual de busca por eficiência na blockchain, uma questão chave 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 a nível técnico, mas uma escolha profunda no design da arquitetura. Para o ecossistema Web3, apenas buscar sistemas mais rápidos enquanto ignora a confiança e a segurança torna difícil sustentar inovações verdadeiramente sustentáveis.
Como um importante impulsionador da escalabilidade do Web3, o Polkadot fez algumas concessões na busca por alta taxa de transferência e baixa latência? O seu modelo rollup comprometeu-se em termos de descentralização, segurança ou interoperabilidade da rede?
Este artigo discutirá estas questões, analisando a fundo as compensações do Polkadot no design de escalabilidade e comparando-as com as soluções de outras blockchains principais, explorando as diferentes escolhas 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. Isso pode, de alguma forma, introduzir riscos de centralização? É possível que surjam pontos únicos de falha ou controle, afetando assim suas características de descentralização?
A execução do Rollup depende do ordenadores da cadeia de retransmissão, cuja comunicação utiliza o mecanismo de protocolo collator. Este protocolo é completamente sem permissão e sem confiança, qualquer pessoa com conexão à rede pode usá-lo, conectando-se a alguns nós da cadeia de retransmissão e enviando solicitações de conversão de estado do rollup. Essas solicitações serão verificadas 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 expansão vertical
O Rollup pode alcançar a escalabilidade vertical ao aproveitar a arquitetura multicore do Polkadot. Esta 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 é fixa 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 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 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 relé, sem comprometer as características chave do sistema.
O Sequencer é confiável?
Uma solução simples é definir o protocolo como "com licença": por exemplo, adotando um mecanismo de lista branca, ou confiando por defeito que o ordenadores não se comportarã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 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 enviar pedidos de alteração de estado do rollup.
Polkadot: uma solução sem compromissos
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 em qual núcleo do Polkadot a validação deve ser executada.
Este design alcançou uma dupla garantia de elasticidade e segurança. O Polkadot executará novamente a conversã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 de qualquer bloco de rollup ser escrito 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 de rollup e as provas de armazenamento correspondentes. 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 especifica em qual core o bloco deve ser verificado. 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 não permissão, evitando que agentes maliciosos, como ordenadores, manipulem a posição de validação, garantindo que mesmo que o rollup utilize múltiplos cores, possa manter a resiliência.
Segurança
Durante o processo de busca por escalabilidade, o 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, o Polkadot estende a sua segurança de forma completa a todos os rollups, validando todos os cálculos no core, sem a necessidade de impor quaisquer limitações ou suposições sobre o número de núcleos utilizados.
Assim, o rollup do Polkadot pode 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 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 em cada 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 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 a alguns 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:
Embora o método automatizado 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 elastica 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, Polkadot também irá suportar a comunicação off-chain, com a cadeia de retransmissão a funcionar como a camada de controle, em vez da camada de dados. Esta atualização irá melhorar a capacidade de comunicação entre rollups, aumentando juntamente a escalabilidade elástica, e reforçando ainda mais a capacidade de escalabilidade vertical do sistema.
Compromissos de outros protocolos
É de conhecimento geral 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, 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 camada única de alta capacidade de processamento para alcançar escalabilidade, dependendo da prova histórica (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 pré-publicado e verificável:
PoH e o processamento paralelo exigem hardware extremamente elevado, levando à centralização dos nós de validação. Quanto mais estacado, maior a chance de um nó produzir blocos, enquanto os nós pequenos quase não têm slots, exacerbando ainda mais a centralização e aumentando 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 inferior aos 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. Por outro lado, a Polkadot já alcançou 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 validação de fragmentos pode ser exposta antecipadamente. O white paper do TON também aponta 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 fragmento esteja sob seu controle total ou bloquear 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, de modo que os atacantes não podem saber antecipadamente a identidade dos validadores. O ataque precisa apostá-los todos para ter sucesso; assim que um validador honesto iniciar uma disputa, o ataque falhará e resultará na perda do depósito do atacante.
Avalanche
Avalanche utiliza uma arquitetura de rede principal + sub-rede para escalabilidade, onde a rede principal é composta pela 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 teoricamente alcançar ~5.000 TPS, semelhante à abordagem do Polkadot: reduzir a carga de um único bloco para alcançar a escalabilidade. No entanto, o Avalanche permite que os validadores escolham livremente participar de sub-rede, 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 isso, as sub-redes do Avalanche não têm garantias de segurança por padrão, e algumas podem ser completamente 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. Essencialmente, essa abordagem não resolve o problema, mas o transfere para a camada superior da pilha.
Optimistic Rollup
Atualmente, a maioria das rollups otimistas é centralizada (algumas têm apenas um sequenciador), enfrentando problemas de segurança insuficiente, isolamento entre si e alta latência (é necessário esperar pelo período de prova de fraude, que geralmente dura vários dias).
ZK Rollup
A implementação do ZK rollup é limitada pela quantidade de dados que uma única transação pode processar. A necessidade computacional para gerar provas de conhecimento zero é extremamente alta, e o mecanismo de "o vencedor leva tudo" pode levar à centralização do sistema. Para garantir o TPS, o ZK rollup frequentemente limita o volume de transações por lote, o que pode causar congestionamento da rede e aumento do gas em momentos 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 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 descentralização por desempenho ou de trocar confiança pré-estabelecida 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 aplicação em maior escala hoje, a "escalabilidade de zero confiança" defendida pelo Polkadot pode ser a verdadeira solução que sustentará o desenvolvimento a longo prazo do Web3.