Problema de escalabilidade do Blockchain: A solução do Polkadot
No campo da blockchain, à medida que buscamos maior eficiência hoje, uma questão crucial começa a se destacar: como escalar o desempenho sem sacrificar a segurança e a resiliência do sistema? Este não é apenas um desafio técnico, mas uma escolha profunda no design da arquitetura. Para o ecossistema Web3, um sistema mais rápido que se baseia na sacrifício da confiança e segurança geralmente tem dificuldade em sustentar inovações verdadeiramente sustentáveis.
Este artigo irá analisar em profundidade as concessões e trade-offs do Polkadot no design de escalabilidade, e compará-los com as soluções de outras blockchains principais, explorando as diferentes escolhas de caminho 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 de uma rede de validadores e de uma cadeia de retransmissão. A execução do Rollup depende de um ordenado que se conecta à cadeia de retransmissão, cuja comunicação utiliza o mecanismo de protocolo collator. Este protocolo é completamente sem permissões 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 enviando pedidos de transformação de estado do rollup. Esses pedidos serão verificados por um núcleo da cadeia de retransmissão, desde que satisfaçam uma premissa: 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
O Rollup pode alcançar a escalabilidade vertical aproveitando 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 do 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. Um atacante pode explorar isso, submetendo repetidamente blocos legítimos que já foram verificados a diferentes cores, consumindo maliciosamente recursos e, assim, reduzindo a capacidade geral e a eficiência do rollup.
O objetivo do Polkadot é manter a flexibilidade dos rollups e a utilização eficaz dos recursos da cadeia de retransmissão, sem comprometer as características fundamentais 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 padrão que o ordenado não terá comportamentos maliciosos, garantindo assim a atividade do rollup.
No entanto, na filosofia de design do Polkadot, não podemos fazer nenhuma suposição de confiança em relação ao 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 de rollup.
Polkadot: Solução sem compromissos
A solução finalmente 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 em um núcleo Polkadot.
Este design garante uma dupla segurança e elasticidade. 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 qualquer bloco rollup ser escrito na camada de disponibilidade de dados do Polkadot, um grupo composto por cerca de 5 validadores irá primeiro verificar a sua legalidade. Eles recebem os recibos candidatos e as provas de validade submetidas pelo ordenadores, que contêm blocos rollup e as provas de armazenamento correspondentes. Essas informações serão processadas pela função de validação da cadeia paralela, sendo reexecutadas pelos validadores na cadeia de retransmissão.
O resultado da verificação inclui um selector core, 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 verificação, garantindo que mesmo que o rollup utilize múltiplos núcleos, a resiliência seja mantida.
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ária apenas um ordenadora honesta para manter a sobrevivência.
Com o protocolo ELVES, a Polkadot estende integralmente a sua segurança a todos os rollups, validando todos os cálculos no core, sem necessidade de impor quaisquer limitações ou suposições sobre o número de núcleos utilizados.
Assim, os rollups do Polkadot podem alcançar uma verdadeira escalabilidade sem sacrificar a segurança.
Versatilidade
A expansão 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 expansão elástica, a quantidade total de cálculos executáveis 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 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 atender a alguns requisitos da 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: monitorizar cargas de transação específicas no mempool do nó;
Estratégia de automação: Configuração de 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, enquanto a escalabilidade flexível 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 atribuídos.
No futuro, o Polkadot também suportará a comunicação de mensagens fora da cadeia, com a cadeia de retransmissão servindo como plano de controle, em vez de plano de dados. Esta atualização irá aumentar a capacidade de comunicação entre rollups juntamente com a escalabilidade elástica, melhorando ainda mais a capacidade de escalabilidade vertical do sistema.
Compromissos de outros protocolos
É bem conhecido que 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 sharding do Polkadot ou do Ethereum, mas sim uma arquitetura de alta capacidade de throughput em uma única camada para alcançar escalabilidade, dependendo de provas históricas, processamento paralelo de CPU e 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 publicado 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 apostada;
Quanto mais você apostar, mais receberá. Por exemplo, um validador que aposta 1% terá cerca de 1% de chance de produzir um bloco;
Todos os produtores de blocos são anunciados antecipadamente, aumentando o risco de ataques DDoS direcionados à rede e frequentes interrupções.
A história prova que o processamento paralelo exige um hardware extremamente elevado, levando à centralização dos nós de validação. Quanto mais nós estiverem em staking, maior será a oportunidade de produzir blocos, enquanto nós menores quase não têm slots, o que agrava ainda mais a centralização e aumenta o risco de paralisação 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. Por outro lado, 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 fragmentos é 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 determinado fragmento esteja completamente sob seu controle ou interromper validadores honestos através de ataques DDoS, permitindo assim a manipulação do estado.
Em comparação, os validadores do Polkadot são atribuídos de forma aleatória e a sua identidade é revelada com atraso, tornando impossível para os atacantes conhecerem antecipadamente a identidade dos validadores. O ataque deve apostar todo o controle para ter sucesso; assim que um validador honesto iniciar uma disputa, o ataque falhará e resultará na perda da garantia pelo atacante.
Avalanche
Avalanche utiliza uma arquitetura de mainnet + subrede para escalabilidade, onde a mainnet é composta pela X-Chain (transferências, ~4.500 TPS), C-Chain (contratos inteligentes, ~100-200 TPS) e P-Chain (gerenciamento de validadores e subredes).
Cada sub-rede pode alcançar um TPS teórico 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 de sub-redes, e as sub-redes podem definir requisitos adicionais geográficos, de KYC, etc., sacrificando a descentralização e a segurança.
No Polkadot, todos os rollups partilham uma proteção de segurança unificada; enquanto as sub-redes da 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 teremos que fazer compromissos em termos de desempenho, e será 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. Essa abordagem, na essência, não resolve o problema, mas sim transfere-o para a camada superior da pilha.
Optimistic Rollup
Atualmente, a maioria dos Optimistic rollups é centralizada (alguns têm apenas um sequenciador), apresentando problemas de segurança insuficiente, isolamento entre si e alta latência (é necessário esperar pelo período de prova de fraude, que geralmente leva 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 zero conhecimento é extremamente alta, e o mecanismo de "vencedor leva tudo" pode facilmente levar à centralização do sistema. Para garantir o TPS, o ZK rollup costuma limitar o volume de transações por lote, o que pode causar congestionamento 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 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 transações, ainda é necessário fornecer dados completos das transações. Isso geralmente depende de soluções adicionais de disponibilidade de dados, o que aumenta ainda mais os custos e as taxas para os usuários.
Conclusão
O fim da escalabilidade não deve ser um compromisso.
Em comparação com outras blockchains, o Polkadot não optou por trocar a descentralização por desempenho, nem por eficiência através de confiança pré-definida, 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ões, uma 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 confiança zero" defendida pela Polkadot talvez seja a verdadeira solução que pode sustentar o desenvolvimento de longo prazo da Web3.
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
24 gostos
Recompensa
24
7
Partilhar
Comentar
0/400
OneBlockAtATime
· 07-21 14:44
又在画BTC DOT换谁了
Ver originalResponder0
RunWhenCut
· 07-21 10:51
Quem ainda se importa com a segurança? É só ir e acabou.
Ver originalResponder0
ImpermanentSage
· 07-18 23:56
Cantando há tanto tempo, a Polkadot continua morna.
Ver originalResponder0
RektCoaster
· 07-18 23:51
Sem palavras, o tps do dot é tão baixo e eu sempre vejo pessoas a exagerar.
Ver originalResponder0
SoliditySlayer
· 07-18 23:44
dot é o verdadeiro caminho.
Ver originalResponder0
SelfCustodyIssues
· 07-18 23:34
Finalmente percebi que dot não consegue competir com sol
Ver originalResponder0
Web3ProductManager
· 07-18 23:32
analisando os números de dau do dot... não estou a ver aquele crescimento em forma de taco de hóquei que precisamos, para ser honesto
O avanço da escalabilidade do Polkadot: desempenho e segurança sem compromissos
Problema de escalabilidade do Blockchain: A solução do Polkadot
No campo da blockchain, à medida que buscamos maior eficiência hoje, uma questão crucial começa a se destacar: como escalar o desempenho sem sacrificar a segurança e a resiliência do sistema? Este não é apenas um desafio técnico, mas uma escolha profunda no design da arquitetura. Para o ecossistema Web3, um sistema mais rápido que se baseia na sacrifício da confiança e segurança geralmente tem dificuldade em sustentar inovações verdadeiramente sustentáveis.
Este artigo irá analisar em profundidade as concessões e trade-offs do Polkadot no design de escalabilidade, e compará-los com as soluções de outras blockchains principais, explorando as diferentes escolhas de caminho 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 de uma rede de validadores e de uma cadeia de retransmissão. A execução do Rollup depende de um ordenado que se conecta à cadeia de retransmissão, cuja comunicação utiliza o mecanismo de protocolo collator. Este protocolo é completamente sem permissões 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 enviando pedidos de transformação de estado do rollup. Esses pedidos serão verificados por um núcleo da cadeia de retransmissão, desde que satisfaçam uma premissa: 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
O Rollup pode alcançar a escalabilidade vertical aproveitando 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 do 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. Um atacante pode explorar isso, submetendo repetidamente blocos legítimos que já foram verificados a diferentes cores, consumindo maliciosamente recursos e, assim, reduzindo a capacidade geral e a eficiência do rollup.
O objetivo do Polkadot é manter a flexibilidade dos rollups e a utilização eficaz dos recursos da cadeia de retransmissão, sem comprometer as características fundamentais 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 padrão que o ordenado não terá comportamentos maliciosos, garantindo assim a atividade do rollup.
No entanto, na filosofia de design do Polkadot, não podemos fazer nenhuma suposição de confiança em relação ao 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 de rollup.
Polkadot: Solução sem compromissos
A solução finalmente 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 em um núcleo Polkadot.
Este design garante uma dupla segurança e elasticidade. 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 qualquer bloco rollup ser escrito na camada de disponibilidade de dados do Polkadot, um grupo composto por cerca de 5 validadores irá primeiro verificar a sua legalidade. Eles recebem os recibos candidatos e as provas de validade submetidas pelo ordenadores, que contêm blocos rollup e as provas de armazenamento correspondentes. Essas informações serão processadas pela função de validação da cadeia paralela, sendo reexecutadas pelos validadores na cadeia de retransmissão.
O resultado da verificação inclui um selector core, 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 verificação, garantindo que mesmo que o rollup utilize múltiplos núcleos, a resiliência seja mantida.
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ária apenas um ordenadora honesta para manter a sobrevivência.
Com o protocolo ELVES, a Polkadot estende integralmente a sua segurança a todos os rollups, validando todos os cálculos no core, sem necessidade de impor quaisquer limitações ou suposições sobre o número de núcleos utilizados.
Assim, os rollups do Polkadot podem alcançar uma verdadeira escalabilidade sem sacrificar a segurança.
Versatilidade
A expansão 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 expansão elástica, a quantidade total de cálculos executáveis 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 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 atender a alguns requisitos da 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 flexível 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 atribuídos.
No futuro, o Polkadot também suportará a comunicação de mensagens fora da cadeia, com a cadeia de retransmissão servindo como plano de controle, em vez de plano de dados. Esta atualização irá aumentar a capacidade de comunicação entre rollups juntamente com a escalabilidade elástica, melhorando ainda mais a capacidade de escalabilidade vertical do sistema.
Compromissos de outros protocolos
É bem conhecido que 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 sharding do Polkadot ou do Ethereum, mas sim uma arquitetura de alta capacidade de throughput em uma única camada para alcançar escalabilidade, dependendo de provas históricas, processamento paralelo de CPU e 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 publicado e verificável:
A história prova que o processamento paralelo exige um hardware extremamente elevado, levando à centralização dos nós de validação. Quanto mais nós estiverem em staking, maior será a oportunidade de produzir blocos, enquanto nós menores quase não têm slots, o que agrava ainda mais a centralização e aumenta o risco de paralisação 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. Por outro lado, 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 fragmentos é 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 determinado fragmento esteja completamente sob seu controle ou interromper validadores honestos através de ataques DDoS, permitindo assim a manipulação do estado.
Em comparação, os validadores do Polkadot são atribuídos de forma aleatória e a sua identidade é revelada com atraso, tornando impossível para os atacantes conhecerem antecipadamente a identidade dos validadores. O ataque deve apostar todo o controle para ter sucesso; assim que um validador honesto iniciar uma disputa, o ataque falhará e resultará na perda da garantia pelo atacante.
Avalanche
Avalanche utiliza uma arquitetura de mainnet + subrede para escalabilidade, onde a mainnet é composta pela X-Chain (transferências, ~4.500 TPS), C-Chain (contratos inteligentes, ~100-200 TPS) e P-Chain (gerenciamento de validadores e subredes).
Cada sub-rede pode alcançar um TPS teórico 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 de sub-redes, e as sub-redes podem definir requisitos adicionais geográficos, de KYC, etc., sacrificando a descentralização e a segurança.
No Polkadot, todos os rollups partilham uma proteção de segurança unificada; enquanto as sub-redes da 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 teremos que fazer compromissos em termos de desempenho, e será 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. Essa abordagem, na essência, não resolve o problema, mas sim transfere-o para a camada superior da pilha.
Optimistic Rollup
Atualmente, a maioria dos Optimistic rollups é centralizada (alguns têm apenas um sequenciador), apresentando problemas de segurança insuficiente, isolamento entre si e alta latência (é necessário esperar pelo período de prova de fraude, que geralmente leva 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 zero conhecimento é extremamente alta, e o mecanismo de "vencedor leva tudo" pode facilmente levar à centralização do sistema. Para garantir o TPS, o ZK rollup costuma limitar o volume de transações por lote, o que pode causar congestionamento 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 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 transações, ainda é necessário fornecer dados completos das transações. Isso geralmente depende de soluções adicionais de disponibilidade de dados, o que aumenta ainda mais os custos e as taxas para os usuários.
Conclusão
O fim da escalabilidade não deve ser um compromisso.
Em comparação com outras blockchains, o Polkadot não optou por trocar a descentralização por desempenho, nem por eficiência através de confiança pré-definida, 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ões, uma 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 confiança zero" defendida pela Polkadot talvez seja a verdadeira solução que pode sustentar o desenvolvimento de longo prazo da Web3.