A 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 melhorar 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 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 tem dificuldade em sustentar inovações verdadeiramente sustentáveis.
Este artigo irá explorar profundamente as concessões e trade-offs do Polkadot no design de escalabilidade, e compará-los com as soluções de outras blockchains populares, analisando suas diferentes escolhas de caminhos entre desempenho, segurança e descentralização.
Desafios enfrentados pelo design de expansão do Polkadot
O equilíbrio entre elasticidade e descentralização
A arquitetura do Polkadot depende da rede de validadores e da cadeia de retransmissão (Relay Chain). A operação do Rollup depende de um sequenciador (sequencer) conectado à 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 um pequeno número de nós da cadeia de retransmissão e submetendo pedidos de transformação de estado do rollup. Esses pedidos serão verificados por um núcleo da cadeia de retransmissão, bastando que atendam a uma condição: devem ser transformações de estado válidas, 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 multicore do Polkadot. Esta nova capacidade é introduzida pela funcionalidade de "Escalonamento Elástico". Durante o processo de design, foi descoberto que, como a validação de bloco 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 verificação. Os atacantes podem explorar isso, submetendo repetidamente blocos legítimos que já foram verificados a diferentes cores, consumindo maliciosamente recursos e, assim, reduzindo a throughput 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 afetar as características essenciais do sistema.
Problemas 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 assumindo que os ordenadores de confiança padrão não terão comportamentos maliciosos, garantindo assim a vitalidade do rollup. No entanto, na filosofia de design do Polkadot, não podemos fazer nenhuma suposição de confiança sobre o sequenciador, pois precisamos manter as características de "sem confiança" e "sem licença" do sistema. Qualquer pessoa deve ser capaz de usar o protocolo collator para submeter solicitações de transformação de estado do rollup.
Polkadot: Solução sem compromissos
A solução escolhida pelo Polkadot é: deixar a questão completamente a cargo da função de conversão de estado do rollup (Runtime). O Runtime é a única fonte confiável de todas as informações de consenso, portanto, deve ser declarado claramente na saída onde a validação deve ser executada no core do Polkadot.
Este design proporciona uma dupla garantia de elasticidade e segurança. Polkadot irá reexecutar 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 que qualquer bloco rollup seja escrito na camada de disponibilidade de dados (DA) do Polkadot, um grupo composto por cerca de 5 validadores irá primeiro verificar sua legitimidade. Eles recebem os recibos candidatos (candidate receipt) e as provas de validade (PoV) submetidos pelos ordenadores, que contêm o bloco rollup e as respectivas provas de armazenamento. Essas informações serão tratadas pela função de verificação da cadeia paralela e reexecutadas pelos validadores na cadeia de retransmissão.
O resultado da verificação inclui um selector core, 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 sem necessidade de confiança e sem necessidade de permissão, evitando que atores maliciosos como ordenadores manipulem a posição de validação, assegurando que mesmo quando o rollup utiliza múltiplos núcleos, a resiliência é mantida.
Segurança
No processo de busca pela escalabilidade, o Polkadot não comprometeu a segurança. A segurança do rollup é garantida pela cadeia relé, sendo necessário apenas um organizador honesto para manter a sobrevivência.
Com o protocolo ELVES, o Polkadot estende completamente a sua segurança a todos os rollups, validando todos os cálculos no core, sem a necessidade de impor qualquer limite 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.
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 completos em Turing 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
Um maior throughput e uma latência mais baixa inevitavelmente introduzem complexidade, que é a única forma aceitável de compensação no design de sistemas.
Rollup pode ajustar dinamicamente os recursos através da interface Agile Coretime, para manter um nível de segurança consistente. Eles também precisam implementar parte dos requisitos 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 através de dados históricos e da interface XCM para chamar o serviço coretime.
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, 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 de bloco de comunicação de cada rollup é fixo, independentemente do número de núcleos alocados a ele.
No futuro, o Polkadot também suportará a comunicação off-chain, com a cadeia de retransmissão a atuar como uma camada de controle, em vez de uma camada de dados. Esta atualização irá melhorar a capacidade de comunicação entre rollups juntamente com a escalabilidade elástica, aumentando ainda mais a capacidade de escalabilidade vertical do sistema.
Compromissos de outros protocolos
É amplamente reconhecido que o aumento de desempenho muitas vezes vem à custa da descentralização e segurança. No entanto, do ponto de vista do coeficiente de Nakamoto, mesmo que alguns concorrentes do Polkadot tenham um grau de descentralização mais baixo, seu desempenho não é satisfatório.
Solana
A Solana não adota a arquitetura de sharding do Polkadot ou do Ethereum, mas sim uma arquitetura de camada única de alta taxa de transferência para alcançar escalabilidade, dependendo da prova histórica (PoH), do processamento paralelo de CPU e de um mecanismo de consenso baseado em líderes, com um TPS teórico que pode atingir 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 alocados com base na quantidade de staking;
Quanto mais você apostar, mais você recebe. 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 de paragens frequentes.
PoH e o processamento paralelo exigem hardware extremamente elevado, levando à centralização dos nós de validação. Quanto mais a quantidade de staking, maior a oportunidade de bloco dos nós, enquanto nós menores têm quase nenhum slot, agravando ainda mais a centralização e aumentando o risco de paralisação do sistema após um ataque.
A Solana sacrificou a descentralização e a resistência à ataques em busca de TPS, com um coeficiente de Nakamoto de apenas 20, muito inferior ao de 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 teste privada, com 256 nós, em condições ideais de rede e hardware. O Polkadot já alcançou 128K TPS em uma rede pública descentralizada.
O mecanismo de consenso 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 claramente 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 esteja completamente sob seu controle ou interromper validadores honestos por meio de ataques DDoS, alterando assim o estado.
Em comparação, os validadores da Polkadot são distribuí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 ter sucesso, desde que haja um validador honesto que inicie uma disputa, o ataque falhará e resultará na perda do staking pelo 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 (gestão de validadores e sub-redes).
Cada subnet pode atingir uma TPS teórica 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 os validadores escolham livremente participar da subnet, e a subnet pode estabelecer requisitos adicionais como geográficos e KYC, sacrificando a descentralização e a segurança.
No Polkadot, todos os rollups partilham uma 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. Se quisermos 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 os problemas diretamente na camada base. Essencialmente, essa abordagem não resolve o problema, mas sim o transfere para a camada superior da pilha.
Optimistic Rollup
Atualmente, a maioria das rollups otimistas são centralizadas (algumas têm até apenas um sequenciador), apresentando problemas como falta de segurança, isolamento entre si e alta latência (é necessário esperar pelo 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 pode ser processada em uma única transação. A demanda computacional para gerar provas de zero conhecimento é extremamente alta, e o mecanismo de "o vencedor leva tudo" tende a resultar em centralização do sistema. Para garantir TPS, o ZK rollup frequentemente limita o volume de transações por lote, o que pode causar congestionamento da 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 agravará suas desvantagens. Para garantir que qualquer pessoa possa verificar as transações, ainda é necessário fornecer dados completos das transações. Isso geralmente depende de soluções adicionais de disponibilidade de dados, aumentando ainda mais os custos e as taxas dos usuários.
Conclusão
O fim da escalabilidade não deve ser um compromisso.
Comparado a outras blockchains, a 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 entre segurança, descentralização e alto desempenho através de uma escalabilidade flexível, design de protocolo sem permissão, camada de segurança unificada e mecanismos de gestão de recursos flexíveis.
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 suporta 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.
10 Curtidas
Recompensa
10
6
Compartilhar
Comentário
0/400
GateUser-a5fa8bd0
· 13h atrás
É preciso aprender bem dot! O velho ofício já não é confiável.
Ver originalResponder0
AirdropworkerZhang
· 08-01 00:33
Esta eficiência é muito alta e o custo é muito baixo. Chefe, eu fui minerar.
Ver originalResponder0
MEVHunter
· 07-31 10:51
meh... a relaychain do dot ainda apresenta gargalos sob pressão intensa do pool de mem, para ser honesto. vi picos de fluxo tóxico na semana passada
Ver originalResponder0
Lonely_Validator
· 07-31 10:51
Sou um jogador experiente de blockchain, Dot é muito popular.
Escalabilidade flexível do Polkadot: equilíbrio inabalável entre desempenho e segurança do Web3
A 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 melhorar 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 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 tem dificuldade em sustentar inovações verdadeiramente sustentáveis.
Este artigo irá explorar profundamente as concessões e trade-offs do Polkadot no design de escalabilidade, e compará-los com as soluções de outras blockchains populares, analisando suas diferentes escolhas de caminhos entre desempenho, segurança e descentralização.
Desafios enfrentados pelo design de expansão do Polkadot
O equilíbrio entre elasticidade e descentralização
A arquitetura do Polkadot depende da rede de validadores e da cadeia de retransmissão (Relay Chain). A operação do Rollup depende de um sequenciador (sequencer) conectado à 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 um pequeno número de nós da cadeia de retransmissão e submetendo pedidos de transformação de estado do rollup. Esses pedidos serão verificados por um núcleo da cadeia de retransmissão, bastando que atendam a uma condição: devem ser transformações de estado válidas, 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 multicore do Polkadot. Esta nova capacidade é introduzida pela funcionalidade de "Escalonamento Elástico". Durante o processo de design, foi descoberto que, como a validação de bloco 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 verificação. Os atacantes podem explorar isso, submetendo repetidamente blocos legítimos que já foram verificados a diferentes cores, consumindo maliciosamente recursos e, assim, reduzindo a throughput 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 afetar as características essenciais do sistema.
Problemas 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 assumindo que os ordenadores de confiança padrão não terão comportamentos maliciosos, garantindo assim a vitalidade do rollup. No entanto, na filosofia de design do Polkadot, não podemos fazer nenhuma suposição de confiança sobre o sequenciador, pois precisamos manter as características de "sem confiança" e "sem licença" do sistema. Qualquer pessoa deve ser capaz de usar o protocolo collator para submeter solicitações de transformação de estado do rollup.
Polkadot: Solução sem compromissos
A solução escolhida pelo Polkadot é: deixar a questão completamente a cargo da função de conversão de estado do rollup (Runtime). O Runtime é a única fonte confiável de todas as informações de consenso, portanto, deve ser declarado claramente na saída onde a validação deve ser executada no core do Polkadot.
Este design proporciona uma dupla garantia de elasticidade e segurança. Polkadot irá reexecutar 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 que qualquer bloco rollup seja escrito na camada de disponibilidade de dados (DA) do Polkadot, um grupo composto por cerca de 5 validadores irá primeiro verificar sua legitimidade. Eles recebem os recibos candidatos (candidate receipt) e as provas de validade (PoV) submetidos pelos ordenadores, que contêm o bloco rollup e as respectivas provas de armazenamento. Essas informações serão tratadas pela função de verificação da cadeia paralela e reexecutadas pelos validadores na cadeia de retransmissão.
O resultado da verificação inclui um selector core, 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 sem necessidade de confiança e sem necessidade de permissão, evitando que atores maliciosos como ordenadores manipulem a posição de validação, assegurando que mesmo quando o rollup utiliza múltiplos núcleos, a resiliência é mantida.
Segurança
No processo de busca pela escalabilidade, o Polkadot não comprometeu a segurança. A segurança do rollup é garantida pela cadeia relé, sendo necessário apenas um organizador honesto para manter a sobrevivência.
Com o protocolo ELVES, o Polkadot estende completamente a sua segurança a todos os rollups, validando todos os cálculos no core, sem a necessidade de impor qualquer limite 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.
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 completos em Turing 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
Um maior throughput e uma latência mais baixa inevitavelmente introduzem complexidade, que é a única forma aceitável de compensação no design de sistemas.
Rollup pode ajustar dinamicamente os recursos através da interface Agile Coretime, para manter um nível de segurança consistente. Eles também precisam implementar parte dos requisitos 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, 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 de bloco de comunicação de cada rollup é fixo, independentemente do número de núcleos alocados a ele.
No futuro, o Polkadot também suportará a comunicação off-chain, com a cadeia de retransmissão a atuar como uma camada de controle, em vez de uma camada de dados. Esta atualização irá melhorar a capacidade de comunicação entre rollups juntamente com a escalabilidade elástica, aumentando ainda mais a capacidade de escalabilidade vertical do sistema.
Compromissos de outros protocolos
É amplamente reconhecido que o aumento de desempenho muitas vezes vem à custa da descentralização e segurança. No entanto, do ponto de vista do coeficiente de Nakamoto, mesmo que alguns concorrentes do Polkadot tenham um grau de descentralização mais baixo, seu desempenho não é satisfatório.
Solana
A Solana não adota a arquitetura de sharding do Polkadot ou do Ethereum, mas sim uma arquitetura de camada única de alta taxa de transferência para alcançar escalabilidade, dependendo da prova histórica (PoH), do processamento paralelo de CPU e de um mecanismo de consenso baseado em líderes, com um TPS teórico que pode atingir 65.000.
Um design chave é o seu mecanismo de agendamento de líderes que é previamente divulgado e verificável:
PoH e o processamento paralelo exigem hardware extremamente elevado, levando à centralização dos nós de validação. Quanto mais a quantidade de staking, maior a oportunidade de bloco dos nós, enquanto nós menores têm quase nenhum slot, agravando ainda mais a centralização e aumentando o risco de paralisação do sistema após um ataque.
A Solana sacrificou a descentralização e a resistência à ataques em busca de TPS, com um coeficiente de Nakamoto de apenas 20, muito inferior ao de 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 teste privada, com 256 nós, em condições ideais de rede e hardware. O Polkadot já alcançou 128K TPS em uma rede pública descentralizada.
O mecanismo de consenso 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 claramente 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 esteja completamente sob seu controle ou interromper validadores honestos por meio de ataques DDoS, alterando assim o estado.
Em comparação, os validadores da Polkadot são distribuí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 ter sucesso, desde que haja um validador honesto que inicie uma disputa, o ataque falhará e resultará na perda do staking pelo 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 (gestão de validadores e sub-redes).
Cada subnet pode atingir uma TPS teórica 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 os validadores escolham livremente participar da subnet, e a subnet pode estabelecer requisitos adicionais como geográficos e KYC, sacrificando a descentralização e a segurança.
No Polkadot, todos os rollups partilham uma 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. Se quisermos 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 os problemas diretamente na camada base. Essencialmente, essa abordagem não resolve o problema, mas sim o transfere para a camada superior da pilha.
Optimistic Rollup
Atualmente, a maioria das rollups otimistas são centralizadas (algumas têm até apenas um sequenciador), apresentando problemas como falta de segurança, isolamento entre si e alta latência (é necessário esperar pelo 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 pode ser processada em uma única transação. A demanda computacional para gerar provas de zero conhecimento é extremamente alta, e o mecanismo de "o vencedor leva tudo" tende a resultar em centralização do sistema. Para garantir TPS, o ZK rollup frequentemente limita o volume de transações por lote, o que pode causar congestionamento da 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 agravará suas desvantagens. Para garantir que qualquer pessoa possa verificar as transações, ainda é necessário fornecer dados completos das transações. Isso geralmente depende de soluções adicionais de disponibilidade de dados, aumentando ainda mais os custos e as taxas dos usuários.
Conclusão
O fim da escalabilidade não deve ser um compromisso.
Comparado a outras blockchains, a 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 entre segurança, descentralização e alto desempenho através de uma escalabilidade flexível, design de protocolo sem permissão, camada de segurança unificada e mecanismos de gestão de recursos flexíveis.
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 suporta o desenvolvimento a longo prazo do Web3.