A ponderação da escalabilidade do Blockchain: Exploração do Polkadot e do ecossistema Web3
Hoje, em que a Blockchain busca constantemente maior eficiência, uma questão chave começa a se destacar: como evitar sacrificar a segurança e a resiliência do sistema ao mesmo tempo em que se expande o desempenho?
Este não é apenas um desafio a nível técnico, mas também uma escolha profunda de design de arquitetura. Especialmente para o ecossistema Web3, um sistema mais rápido que é construído à custa da confiança e da segurança, muitas vezes tem dificuldade em sustentar inovações verdadeiramente sustentáveis.
Como um importante impulsionador da escalabilidade do Web3, a Polkadot fez algumas concessões em busca de alta taxa de transferência e baixa latência? O seu modelo de rollup fez compromissos em descentralização, segurança ou interoperabilidade da rede?
Este artigo irá abordar essas questões, analisando em profundidade as escolhas e compromissos de design de escalabilidade do Polkadot, comparando-as com as soluções de outras blockchains principais, e explorando suas diferentes opções de caminho em relação ao 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 da cadeia de retransmissão (Relay Chain), será que isso pode introduzir riscos de centralização em certos aspectos? É possível que surjam pontos únicos de falha ou controle, afetando assim as suas características de descentralização?
A operação do Rollup depende do sequenciador (sequencer) da cadeia de retransmissão conectada, cuja comunicação utiliza um mecanismo chamado protocolo collator. Este protocolo é totalmente sem permissão e sem confiança, qualquer pessoa com conexão à rede pode utilizá-lo, conectando-se a um pequeno número de nós da cadeia de retransmissão e enviando pedidos de alteração de estado do rollup. Esses pedidos serão verificados por algum core da cadeia de retransmissão, desde que satisfaçam uma condição: devem ser alteraçõ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 "Escala Elástica" (Elastic Scaling). Durante o processo de design, percebemos que, como a validação de blocos de rollup não é executada em um core específico, isso pode afetar sua elasticidade.
Como o protocolo para submeter blocos à cadeia de retransmissão é sem permissões e sem confiança, qualquer pessoa pode submeter blocos a qualquer core designado 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 taxa de transferência e a eficiência geral do rollup.
O objetivo do Polkadot é manter a flexibilidade do rollup e a utilização eficaz dos recursos da cadeia relé, sem comprometer as características essenciais do sistema.
Sequencer é confiável?
Uma solução simples é definir o protocolo como "com licença": por exemplo, usar um mecanismo de lista branca, ou confiar por padrão que os ordenadores não agirão de forma maliciosa, assegurando assim a atividade do rollup.
No entanto, na filosofia de design do Polkadot, não podemos fazer quaisquer suposições de confiança sobre o sequenciador, pois precisamos manter as características de "sem confiança" e "sem permissão" do sistema. Qualquer pessoa deve ser capaz de usar o protocolo collator para submeter pedidos de mudança de estado do rollup.
Polkadot: Solução Sem Compromissos
A solução final escolhida pelo Polkadot é: deixar o problema totalmente 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 em qual core do Polkadot a validação deve ser executada.
Este design proporciona uma dupla garantia de flexibilidade e segurança. O Polkadot executará novamente 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 de rollup ser escrito na camada de disponibilidade de dados (DA) do Polkadot, um grupo composto por cerca de 5 validadores irá primeiro verificar sua legalidade. Eles recebem os recibos candidatos (candidate receipt) e provas de validade (PoV) submetidos pelo ordenadores, que contêm o bloco de rollup e a respectiva prova de armazenamento. Essas informações serão processadas pela função de validação da cadeia paralela e reexecutadas pelos validadores na cadeia relé.
O resultado da verificação inclui um core selector, que é usado para especificar em qual core o bloco deve ser verificado. O validador irá comparar se esse índice corresponde ao core de sua responsabilidade; se não corresponder, o bloco será descartado.
Este mecanismo garante que o sistema mantenha sempre as propriedades de confiança e permissão, evitando que atores maliciosos, como ordenadores, manipulem a posição de verificação, assegurando que mesmo que o rollup utilize múltiplos núcleos, continue a ser resiliente.
Segurança
No processo de busca pela escalabilidade, o Polkadot não comprometeu a segurança. A segurança do rollup é garantida pela cadeia de retransmissão, e apenas um ordenado honesto é necessário para manter a viabilidade.
Com o protocolo ELVES, o Polkadot expande a sua segurança completamente para todos os rollups, validando todos os cálculos na 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 comprometer a segurança.
Universalidade
A expansão elástica não limita 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 menor latência inevitavelmente introduzem complexidade, que é a única forma aceitável de compromisso 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 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 um número fixo de cores, ou ajuste manualmente fora da cadeia;
Estratégia leve: monitorizar a carga de transações 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, enquanto a escalabilidade elástica 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 comunicação off-chain, com a cadeia de retransmissão a atuar como superfície de controlo, em vez de superfície de dados. Esta atualização irá melhorar a capacidade de comunicação entre rollups juntamente com a escalabilidade elástica, reforçando ainda mais a capacidade de escalabilidade vertical do sistema.
Que compromissos foram feitos por outros protocolos?
É bem sabido que o aumento de desempenho muitas vezes vem à custa da descentralização e da segurança. 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 é tão satisfatório.
Solana
A Solana não adota a arquitetura de sharding do Polkadot ou do Ethereum, mas sim uma arquitetura de alta capacidade em uma única camada para alcançar escalabilidade, confiando na prova histórica (PoH), no processamento paralelo de CPU e em um mecanismo de consenso baseado em líderes, com um TPS teórico de até 65.000.
Um dos principais desenhos é 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ê receberá. Por exemplo, um validador que aposta 1% terá cerca de 1% de chance de produzir um bloco;
Todos os validadores de bloco são anunciados antecipadamente, aumentando o risco de ataques DDoS direcionados à rede e quedas frequentes.
PoH e o processamento paralelo exigem hardware extremamente elevado, resultando na centralização dos nós de validação. Quanto mais um nó é apostado, maior a chance de produzir blocos, enquanto os pequenos nós têm quase nenhum slot, 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 abaixo dos 172 da Polkadot.
TON
A TON afirma que o TPS pode chegar a 104.715, mas esse número foi alcançado em uma rede de testes privada, com 256 nós, em condições ideais de rede e hardware. Já o Polkadot alcançou 128K TPS em uma rede pública descentralizada.
O mecanismo de consenso do TON apresenta 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 indica 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 jogador", os atacantes podem esperar que um determinado fragmento esteja completamente sob seu controle ou bloquear validadores honestos por meio de ataques DDoS, alterando assim o estado.
Em comparação, os validadores do Polkadot são atribuídos de forma aleatória e revelados com atraso, os atacantes não podem saber antecipadamente a identidade dos validadores, o ataque deve apostar todo o controle para ser bem-sucedido, e assim que um validador honesto iniciar uma disputa, o ataque falhará e resultará na perda da garantia para o atacante.
Avalanche
Avalanche adota uma arquitetura de mainnet + subnets para escalabilidade, onde a mainnet é composta por X-Chain (transferências, ~4.500 TPS), C-Chain (contratos inteligentes, ~100-200 TPS) e P-Chain (gestão de validadores e subnets).
A TPS teórica de cada sub-rede pode alcançar ~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 na sub-rede, e a sub-rede pode definir requisitos adicionais, como geográficos e KYC, sacrificando a descentralização e a segurança.
No Polkadot, todos os rollups partilham uma garantia de segurança unificada; enquanto as sub-redes do Avalanche não têm garantias de segurança por padrão, algumas podem até 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 os problemas diretamente na camada base. Esta abordagem, na essência, não resolve o problema, mas apenas o transfere para a camada superior da pilha.
Optimistic Rollup
Atualmente, a maioria das Optimistic rollups é centralizada (algumas têm apenas um sequenciador), apresentando problemas de segurança insuficiente, isolamento entre si e alta latência (é necessário aguardar o 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 pode ser processada por transação única. A demanda computacional para gerar provas de conhecimento zero é extremamente alta, e o mecanismo de "vencedor leva tudo" pode levar à centralização do sistema. Para garantir o TPS, o ZK rollup costuma limitar o volume de transações por lote, o que, em períodos de alta demanda, pode causar congestionamento na rede e aumento do gas, impactando 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 irá 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 para os usuários.
Conclusão
O fim da escalabilidade não deve ser um compromisso.
Comparado a outras blockchains, o Polkadot não seguiu o caminho de trocar centralização por desempenho ou confiança pré-estabelecida por eficiência, mas sim alcançou um equilíbrio multidimensional 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 implementação em maior escala hoje, a "escalabilidade sem confiança" defendida pelo Polkadot pode ser a verdadeira solução que sustenta o desenvolvimento a 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.
14 gostos
Recompensa
14
5
Partilhar
Comentar
0/400
SignatureCollector
· 07-30 01:18
Ponto de cadeia, vai! Subir, subir!
Ver originalResponder0
ForumMiningMaster
· 07-30 01:15
Com um rendimento mensal de cem mil, tudo depende destas algumas cadeias.
Ver originalResponder0
LostBetweenChains
· 07-30 01:12
Aumentar a posição em BTC é só isso.
Ver originalResponder0
BearMarketSunriser
· 07-30 01:12
Nem sequer têm vergonha de se gabar de tão poucos tps.
Escalabilidade flexível do Polkadot: O caminho de alto desempenho para o Web3 sem compromissos
A ponderação da escalabilidade do Blockchain: Exploração do Polkadot e do ecossistema Web3
Hoje, em que a Blockchain busca constantemente maior eficiência, uma questão chave começa a se destacar: como evitar sacrificar a segurança e a resiliência do sistema ao mesmo tempo em que se expande o desempenho?
Este não é apenas um desafio a nível técnico, mas também uma escolha profunda de design de arquitetura. Especialmente para o ecossistema Web3, um sistema mais rápido que é construído à custa da confiança e da segurança, muitas vezes tem dificuldade em sustentar inovações verdadeiramente sustentáveis.
Como um importante impulsionador da escalabilidade do Web3, a Polkadot fez algumas concessões em busca de alta taxa de transferência e baixa latência? O seu modelo de rollup fez compromissos em descentralização, segurança ou interoperabilidade da rede?
Este artigo irá abordar essas questões, analisando em profundidade as escolhas e compromissos de design de escalabilidade do Polkadot, comparando-as com as soluções de outras blockchains principais, e explorando suas diferentes opções de caminho em relação ao 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 da cadeia de retransmissão (Relay Chain), será que isso pode introduzir riscos de centralização em certos aspectos? É possível que surjam pontos únicos de falha ou controle, afetando assim as suas características de descentralização?
A operação do Rollup depende do sequenciador (sequencer) da cadeia de retransmissão conectada, cuja comunicação utiliza um mecanismo chamado protocolo collator. Este protocolo é totalmente sem permissão e sem confiança, qualquer pessoa com conexão à rede pode utilizá-lo, conectando-se a um pequeno número de nós da cadeia de retransmissão e enviando pedidos de alteração de estado do rollup. Esses pedidos serão verificados por algum core da cadeia de retransmissão, desde que satisfaçam uma condição: devem ser alteraçõ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 "Escala Elástica" (Elastic Scaling). Durante o processo de design, percebemos que, como a validação de blocos de rollup não é executada em um core específico, isso pode afetar sua elasticidade.
Como o protocolo para submeter blocos à cadeia de retransmissão é sem permissões e sem confiança, qualquer pessoa pode submeter blocos a qualquer core designado 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 taxa de transferência e a eficiência geral do rollup.
O objetivo do Polkadot é manter a flexibilidade do rollup e a utilização eficaz dos recursos da cadeia relé, sem comprometer as características essenciais do sistema.
Sequencer é confiável?
Uma solução simples é definir o protocolo como "com licença": por exemplo, usar um mecanismo de lista branca, ou confiar por padrão que os ordenadores não agirão de forma maliciosa, assegurando assim a atividade do rollup.
No entanto, na filosofia de design do Polkadot, não podemos fazer quaisquer suposições de confiança sobre o sequenciador, pois precisamos manter as características de "sem confiança" e "sem permissão" do sistema. Qualquer pessoa deve ser capaz de usar o protocolo collator para submeter pedidos de mudança de estado do rollup.
Polkadot: Solução Sem Compromissos
A solução final escolhida pelo Polkadot é: deixar o problema totalmente 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 em qual core do Polkadot a validação deve ser executada.
Este design proporciona uma dupla garantia de flexibilidade e segurança. O Polkadot executará novamente 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 de rollup ser escrito na camada de disponibilidade de dados (DA) do Polkadot, um grupo composto por cerca de 5 validadores irá primeiro verificar sua legalidade. Eles recebem os recibos candidatos (candidate receipt) e provas de validade (PoV) submetidos pelo ordenadores, que contêm o bloco de rollup e a respectiva prova de armazenamento. Essas informações serão processadas pela função de validação da cadeia paralela e reexecutadas pelos validadores na cadeia relé.
O resultado da verificação inclui um core selector, que é usado para especificar em qual core o bloco deve ser verificado. O validador irá comparar se esse índice corresponde ao core de sua responsabilidade; se não corresponder, o bloco será descartado.
Este mecanismo garante que o sistema mantenha sempre as propriedades de confiança e permissão, evitando que atores maliciosos, como ordenadores, manipulem a posição de verificação, assegurando que mesmo que o rollup utilize múltiplos núcleos, continue a ser resiliente.
Segurança
No processo de busca pela escalabilidade, o Polkadot não comprometeu a segurança. A segurança do rollup é garantida pela cadeia de retransmissão, e apenas um ordenado honesto é necessário para manter a viabilidade.
Com o protocolo ELVES, o Polkadot expande a sua segurança completamente para todos os rollups, validando todos os cálculos na 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 comprometer a segurança.
Universalidade
A expansão elástica não limita 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 menor latência inevitavelmente introduzem complexidade, que é a única forma aceitável de compromisso 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 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 um número fixo de cores, ou ajuste manualmente fora da cadeia;
Estratégia leve: monitorizar a carga de transações 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, enquanto a escalabilidade elástica 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 comunicação off-chain, com a cadeia de retransmissão a atuar como superfície de controlo, em vez de superfície de dados. Esta atualização irá melhorar a capacidade de comunicação entre rollups juntamente com a escalabilidade elástica, reforçando ainda mais a capacidade de escalabilidade vertical do sistema.
Que compromissos foram feitos por outros protocolos?
É bem sabido que o aumento de desempenho muitas vezes vem à custa da descentralização e da segurança. 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 é tão satisfatório.
Solana
A Solana não adota a arquitetura de sharding do Polkadot ou do Ethereum, mas sim uma arquitetura de alta capacidade em uma única camada para alcançar escalabilidade, confiando na prova histórica (PoH), no processamento paralelo de CPU e em um mecanismo de consenso baseado em líderes, com um TPS teórico de até 65.000.
Um dos principais desenhos é 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ê receberá. Por exemplo, um validador que aposta 1% terá cerca de 1% de chance de produzir um bloco;
Todos os validadores de bloco são anunciados antecipadamente, aumentando o risco de ataques DDoS direcionados à rede e quedas frequentes.
PoH e o processamento paralelo exigem hardware extremamente elevado, resultando na centralização dos nós de validação. Quanto mais um nó é apostado, maior a chance de produzir blocos, enquanto os pequenos nós têm quase nenhum slot, 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 abaixo dos 172 da Polkadot.
TON
A TON afirma que o TPS pode chegar a 104.715, mas esse número foi alcançado em uma rede de testes privada, com 256 nós, em condições ideais de rede e hardware. Já o Polkadot alcançou 128K TPS em uma rede pública descentralizada.
O mecanismo de consenso do TON apresenta 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 indica 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 jogador", os atacantes podem esperar que um determinado fragmento esteja completamente sob seu controle ou bloquear validadores honestos por meio de ataques DDoS, alterando assim o estado.
Em comparação, os validadores do Polkadot são atribuídos de forma aleatória e revelados com atraso, os atacantes não podem saber antecipadamente a identidade dos validadores, o ataque deve apostar todo o controle para ser bem-sucedido, e assim que um validador honesto iniciar uma disputa, o ataque falhará e resultará na perda da garantia para o atacante.
Avalanche
Avalanche adota uma arquitetura de mainnet + subnets para escalabilidade, onde a mainnet é composta por X-Chain (transferências, ~4.500 TPS), C-Chain (contratos inteligentes, ~100-200 TPS) e P-Chain (gestão de validadores e subnets).
A TPS teórica de cada sub-rede pode alcançar ~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 na sub-rede, e a sub-rede pode definir requisitos adicionais, como geográficos e KYC, sacrificando a descentralização e a segurança.
No Polkadot, todos os rollups partilham uma garantia de segurança unificada; enquanto as sub-redes do Avalanche não têm garantias de segurança por padrão, algumas podem até 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 os problemas diretamente na camada base. Esta abordagem, na essência, não resolve o problema, mas apenas o transfere para a camada superior da pilha.
Optimistic Rollup
Atualmente, a maioria das Optimistic rollups é centralizada (algumas têm apenas um sequenciador), apresentando problemas de segurança insuficiente, isolamento entre si e alta latência (é necessário aguardar o 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 pode ser processada por transação única. A demanda computacional para gerar provas de conhecimento zero é extremamente alta, e o mecanismo de "vencedor leva tudo" pode levar à centralização do sistema. Para garantir o TPS, o ZK rollup costuma limitar o volume de transações por lote, o que, em períodos de alta demanda, pode causar congestionamento na rede e aumento do gas, impactando 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 irá 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 para os usuários.
Conclusão
O fim da escalabilidade não deve ser um compromisso.
Comparado a outras blockchains, o Polkadot não seguiu o caminho de trocar centralização por desempenho ou confiança pré-estabelecida por eficiência, mas sim alcançou um equilíbrio multidimensional 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 implementação em maior escala hoje, a "escalabilidade sem confiança" defendida pelo Polkadot pode ser a verdadeira solução que sustenta o desenvolvimento a longo prazo da Web3.