Compromisso entre escalabilidade e segurança: O design da arquitetura Web3 do Polkadot
Hoje, em um contexto em que a tecnologia blockchain busca constantemente maior eficiência, uma questão crucial está gradualmente emergindo: como melhorar o desempenho sem sacrificar a segurança e a resiliência do sistema? Isso não é apenas um desafio no nível técnico, mas também envolve considerações profundas sobre o design da arquitetura. Para o ecossistema Web3, um sistema de alta velocidade que sacrifica confiança e segurança costuma ter dificuldade em sustentar inovações verdadeiramente sustentáveis.
Como um importante impulsionador da escalabilidade do Web3, Polkadot fez algumas concessões na busca por alta taxa de transferência e baixa latência? O seu modelo de rollup fez algum sacrifício em termos de descentralização, segurança ou interoperabilidade da rede? Este artigo discutirá essas questões, analisando profundamente as concessões e compensações que Polkadot fez no design de escalabilidade, e comparando-as com as soluções de outras principais blockchains, explorando suas diferentes escolhas 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 ocorram pontos únicos de falha ou controle, afetando assim suas características de descentralização?
A operação do Rollup depende do ordenante da cadeia de retransmissão conectada, cuja comunicação utiliza o mecanismo de protocolo collator. Este protocolo é totalmente sem permissão e sem confiança, qualquer pessoa com conexão à rede pode usá-lo, conectando-se a um pequeno número de nós da cadeia de retransmissão e submetendo pedidos de alteraçã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 alteração de estado válida, caso contrário, o estado do rollup não será avançado.
Compromissos de escalabilidade vertical
Os Rollups podem alcançar a escalabilidade vertical aproveitando a arquitetura multicore do Polkadot. Esta nova capacidade foi introduzida pela funcionalidade de "escalabilidade elástica". Durante o processo de design, foi descoberto que, como 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 pessoa pode submeter blocos a qualquer core atribuído ao rollup para validação. Um atacante pode explorar isso para submeter repetidamente blocos legítimos que já foram validados a diferentes cores, consumindo recursos maliciosamente e, assim, reduzindo a capacidade e eficiência geral do rollup.
O objetivo do Polkadot é manter a elasticidade dos rollups e a utilização eficaz dos recursos da cadeia de retransmissão, sem comprometer as características essenciais do sistema.
Problema de confiança do Sequencer
Uma solução simples é definir o protocolo como "com licença": por exemplo, adotando um mecanismo de lista branca, ou confiando por defeito que os ordenadores não se comportem 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 ser capaz de usar o protocolo collator para enviar pedidos de transformação de estado do rollup.
Polkadot: Solução sem compromissos
A solução final 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 declarar claramente 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 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 de escrever os dados da rollup no nível de disponibilidade de dados do Polkadot, um grupo composto por cerca de 5 validadores verificará primeiro sua legitimidade. Eles recebem os recibos candidatos e as provas de validade submetidos pelo ordenadores, que incluem o bloco rollup e as respectivas provas de armazenamento. Essas informações serão processadas pela função de verificação da cadeia paralela, sendo re-executadas pelos validadores na cadeia de retransmissão.
O resultado da validação inclui um selector core, que é usado para especificar em qual core o bloco deve ser validado. O validador comparará se esse índice corresponde ao core que lhe é atribuído; 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, assegurando que mesmo quando o rollup utiliza vários núcleos, consegue manter a resiliência.
segurança
Na busca pela 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 ordenado honesto para manter a sobrevivência.
Com o protocolo ELVES, a Polkadot estende a sua segurança integral a todos os rollups, validando todos os cálculos no core, sem necessidade de impor qualquer limitação ou suposição sobre o número de núcleos utilizados.
Assim, os rollups do Polkadot podem alcançar uma verdadeira escalabilidade sem sacrificar a segurança.
versatilidade
A escalabilidade elástica não irá 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 executados a cada 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.
Os Rollups podem 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 dos requisitos do RFC103 para se adaptarem a diferentes cenários de uso.
A complexidade específica depende da estratégia de gestão de recursos do rollup, que pode depender de variáveis on-chain ou off-chain. Por exemplo:
Estratégia simples: use sempre uma quantidade fixa de cores, ou ajuste manualmente fora da cadeia;
Estratégia leve: Monitorar cargas de transação específicas no mempool do nó;
Estratégias automatizadas: configurar recursos antecipadamente através de dados históricos e da interface XCM chamando o serviço coretime.
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 de 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 transmissão de mensagens fora da cadeia, com a cadeia de retransmissão atuando como uma camada de controle, em vez de uma camada de dados. Esta atualização permitirá que a capacidade de comunicação entre rollups seja melhorada junto com a escalabilidade elástica, aumentando ainda mais a capacidade de escalabilidade vertical do sistema.
Compromissos de Outros Protocolos
Como é bem conhecido, o aumento de desempenho muitas vezes vem à custa da descentralização e da segurança. Mas, de acordo com o 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 utiliza a arquitetura de fragmentação do Polkadot ou do Ethereum, mas sim uma arquitetura de alto throughput de camada única para alcançar escalabilidade, dependendo da prova histórica, do processamento paralelo de CPU e de 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 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 se aposta, mais se distribui. Por exemplo, um validador que aposta 1% terá cerca de 1% de chance de produzir blocos;
Todos os mineradores são anunciados com antecedência, aumentando o risco de ataques DDoS direcionados à rede e frequentes quedas de sistema.
A história prova que o processamento paralelo exige hardware extremamente potente, o que leva à centralização dos nós de validação. Quanto mais nós estão em staking, maior a chance de produzir blocos, enquanto nós menores praticamente 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 resistência a ataques em busca de TPS, com um coeficiente de Nakamoto de apenas 20, muito inferior aos 172 do 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. O Polkadot já 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 shards pode ser exposta antecipadamente. O white paper do TON também aponta claramente que, embora isso possa otimizar a largura de banda, também pode ser explorado maliciosamente. Devido à falta de um mecanismo de "falência de apostadores", os atacantes podem esperar que um shard esteja completamente sob seu controle ou interromper validadores honestos por meio de ataques DDoS, permitindo assim a manipulação do estado.
Em comparação, os validadores do Polkadot são atribuídos aleatoriamente e revelados com atraso, os atacantes não conseguem saber de antemão a identidade dos validadores, o ataque precisa apostar todo o controle para ter sucesso, e assim que um validador honesto iniciar uma disputa, o ataque falhará e resultará em perdas para o atacante.
Avalanche
Avalanche utiliza uma arquitetura de rede principal + sub-rede para escalar, 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 subnet pode teoricamente atingir um TPS de ~5.000, semelhante à abordagem do Polkadot: reduzir a carga de um único shard para alcançar a escalabilidade. No entanto, o Avalanche permite que validadores escolham livremente participar de subnets, e as subnets podem definir requisitos adicionais como geográficos e KYC, sacrificando descentralização e 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 até ser completamente centralizadas. Se quisermos aumentar a segurança, ainda precisamos 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 Optimistic rollups é centralizada, apresentando problemas como falta de segurança, isolamento mútuo 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 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 causar centralização do sistema. Para garantir o TPS, o ZK rollup geralmente limita a quantidade de transações por lote, o que pode levar a congestionamentos 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 Turing-completo é aproximadamente 2x10^6 vezes o do protocolo de segurança econômica central da Polkadot.
Além disso, os problemas de disponibilidade de dados do ZK rollup também acentuam suas desvantagens. Para garantir que qualquer pessoa possa verificar as transações, ainda é necessário fornecer os dados completos das transações. Isso geralmente depende de soluções adicionais de disponibilidade de dados, aumentando ainda mais os custos e as taxas para os usuários.
Conclusão
O fim da escalabilidade não deve ser um compromisso.
Comparado a outras blockchains públicas, 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 mecanismos de gestão de recursos flexíveis.
Na busca pela aplicação em maior escala hoje, o "escopo de zero confiança" defendido pelo Polkadot pode ser a verdadeira solução que sustentará o desenvolvimento de 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.
19 Curtidas
Recompensa
19
5
Compartilhar
Comentário
0/400
NFT_Therapy
· 07-16 00:58
Outra vez o meu velho fren dot!
Ver originalResponder0
LayerZeroHero
· 07-14 19:38
A verdade é que deve haver trade-off, e ainda é necessário executar benchmarks para verificar...
A arquitetura Web3 do Polkadot: o equilíbrio perfeito entre escalabilidade e segurança
Compromisso entre escalabilidade e segurança: O design da arquitetura Web3 do Polkadot
Hoje, em um contexto em que a tecnologia blockchain busca constantemente maior eficiência, uma questão crucial está gradualmente emergindo: como melhorar o desempenho sem sacrificar a segurança e a resiliência do sistema? Isso não é apenas um desafio no nível técnico, mas também envolve considerações profundas sobre o design da arquitetura. Para o ecossistema Web3, um sistema de alta velocidade que sacrifica confiança e segurança costuma ter dificuldade em sustentar inovações verdadeiramente sustentáveis.
Como um importante impulsionador da escalabilidade do Web3, Polkadot fez algumas concessões na busca por alta taxa de transferência e baixa latência? O seu modelo de rollup fez algum sacrifício em termos de descentralização, segurança ou interoperabilidade da rede? Este artigo discutirá essas questões, analisando profundamente as concessões e compensações que Polkadot fez no design de escalabilidade, e comparando-as com as soluções de outras principais blockchains, explorando suas diferentes escolhas 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 ocorram pontos únicos de falha ou controle, afetando assim suas características de descentralização?
A operação do Rollup depende do ordenante da cadeia de retransmissão conectada, cuja comunicação utiliza o mecanismo de protocolo collator. Este protocolo é totalmente sem permissão e sem confiança, qualquer pessoa com conexão à rede pode usá-lo, conectando-se a um pequeno número de nós da cadeia de retransmissão e submetendo pedidos de alteraçã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 alteração de estado válida, caso contrário, o estado do rollup não será avançado.
Compromissos de escalabilidade vertical
Os Rollups podem alcançar a escalabilidade vertical aproveitando a arquitetura multicore do Polkadot. Esta nova capacidade foi introduzida pela funcionalidade de "escalabilidade elástica". Durante o processo de design, foi descoberto que, como 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 pessoa pode submeter blocos a qualquer core atribuído ao rollup para validação. Um atacante pode explorar isso para submeter repetidamente blocos legítimos que já foram validados a diferentes cores, consumindo recursos maliciosamente e, assim, reduzindo a capacidade e eficiência geral do rollup.
O objetivo do Polkadot é manter a elasticidade dos rollups e a utilização eficaz dos recursos da cadeia de retransmissão, sem comprometer as características essenciais do sistema.
Problema de confiança do Sequencer
Uma solução simples é definir o protocolo como "com licença": por exemplo, adotando um mecanismo de lista branca, ou confiando por defeito que os ordenadores não se comportem 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 ser capaz de usar o protocolo collator para enviar pedidos de transformação de estado do rollup.
Polkadot: Solução sem compromissos
A solução final 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 declarar claramente 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 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 de escrever os dados da rollup no nível de disponibilidade de dados do Polkadot, um grupo composto por cerca de 5 validadores verificará primeiro sua legitimidade. Eles recebem os recibos candidatos e as provas de validade submetidos pelo ordenadores, que incluem o bloco rollup e as respectivas provas de armazenamento. Essas informações serão processadas pela função de verificação da cadeia paralela, sendo re-executadas pelos validadores na cadeia de retransmissão.
O resultado da validação inclui um selector core, que é usado para especificar em qual core o bloco deve ser validado. O validador comparará se esse índice corresponde ao core que lhe é atribuído; 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, assegurando que mesmo quando o rollup utiliza vários núcleos, consegue manter a resiliência.
segurança
Na busca pela 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 ordenado honesto para manter a sobrevivência.
Com o protocolo ELVES, a Polkadot estende a sua segurança integral a todos os rollups, validando todos os cálculos no core, sem necessidade de impor qualquer limitação ou suposição sobre o número de núcleos utilizados.
Assim, os rollups do Polkadot podem alcançar uma verdadeira escalabilidade sem sacrificar a segurança.
versatilidade
A escalabilidade elástica não irá 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 executados a cada 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.
Os Rollups podem 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 dos requisitos do RFC103 para se adaptarem a diferentes cenários de uso.
A complexidade específica depende da estratégia de gestão de recursos do rollup, que pode depender de variáveis on-chain ou off-chain. Por exemplo:
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 de 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 transmissão de mensagens fora da cadeia, com a cadeia de retransmissão atuando como uma camada de controle, em vez de uma camada de dados. Esta atualização permitirá que a capacidade de comunicação entre rollups seja melhorada junto com a escalabilidade elástica, aumentando ainda mais a capacidade de escalabilidade vertical do sistema.
Compromissos de Outros Protocolos
Como é bem conhecido, o aumento de desempenho muitas vezes vem à custa da descentralização e da segurança. Mas, de acordo com o 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 utiliza a arquitetura de fragmentação do Polkadot ou do Ethereum, mas sim uma arquitetura de alto throughput de camada única para alcançar escalabilidade, dependendo da prova histórica, do processamento paralelo de CPU e de 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 previamente divulgado e verificável:
A história prova que o processamento paralelo exige hardware extremamente potente, o que leva à centralização dos nós de validação. Quanto mais nós estão em staking, maior a chance de produzir blocos, enquanto nós menores praticamente 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 resistência a ataques em busca de TPS, com um coeficiente de Nakamoto de apenas 20, muito inferior aos 172 do 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. O Polkadot já 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 shards pode ser exposta antecipadamente. O white paper do TON também aponta claramente que, embora isso possa otimizar a largura de banda, também pode ser explorado maliciosamente. Devido à falta de um mecanismo de "falência de apostadores", os atacantes podem esperar que um shard esteja completamente sob seu controle ou interromper validadores honestos por meio de ataques DDoS, permitindo assim a manipulação do estado.
Em comparação, os validadores do Polkadot são atribuídos aleatoriamente e revelados com atraso, os atacantes não conseguem saber de antemão a identidade dos validadores, o ataque precisa apostar todo o controle para ter sucesso, e assim que um validador honesto iniciar uma disputa, o ataque falhará e resultará em perdas para o atacante.
Avalanche
Avalanche utiliza uma arquitetura de rede principal + sub-rede para escalar, 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 subnet pode teoricamente atingir um TPS de ~5.000, semelhante à abordagem do Polkadot: reduzir a carga de um único shard para alcançar a escalabilidade. No entanto, o Avalanche permite que validadores escolham livremente participar de subnets, e as subnets podem definir requisitos adicionais como geográficos e KYC, sacrificando descentralização e 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 até ser completamente centralizadas. Se quisermos aumentar a segurança, ainda precisamos 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 Optimistic rollups é centralizada, apresentando problemas como falta de segurança, isolamento mútuo 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 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 causar centralização do sistema. Para garantir o TPS, o ZK rollup geralmente limita a quantidade de transações por lote, o que pode levar a congestionamentos 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 Turing-completo é aproximadamente 2x10^6 vezes o do protocolo de segurança econômica central da Polkadot.
Além disso, os problemas de disponibilidade de dados do ZK rollup também acentuam suas desvantagens. Para garantir que qualquer pessoa possa verificar as transações, ainda é necessário fornecer os dados completos das transações. Isso geralmente depende de soluções adicionais de disponibilidade de dados, aumentando ainda mais os custos e as taxas para os usuários.
Conclusão
O fim da escalabilidade não deve ser um compromisso.
Comparado a outras blockchains públicas, 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 mecanismos de gestão de recursos flexíveis.
Na busca pela aplicação em maior escala hoje, o "escopo de zero confiança" defendido pelo Polkadot pode ser a verdadeira solução que sustentará o desenvolvimento de longo prazo do Web3.