Compromissos de escalabilidade: Desafios do Polkadot e Web3
Na busca por maior eficiência na blockchain hoje em dia, uma questão fundamental começa a se destacar: como escalar o desempenho sem sacrificar a segurança e a resiliência do sistema? Isso não é apenas um desafio técnico, mas uma escolha profunda na arquitetura de design. Para o ecossistema Web3, um sistema mais rápido, se construído sobre a base de sacrificar a confiança e a segurança, muitas vezes luta para sustentar inovações verdadeiramente sustentáveis.
Como um importante impulsionador da escalabilidade do Web3, o Polkadot fez algumas concessões em relação ao alto rendimento e baixa latência? O seu modelo de rollup fez concessões em descentralização, segurança ou interoperabilidade da rede?
Este artigo abordará essas questões, analisando profundamente os compromissos e trade-offs do Polkadot no design de escalabilidade, comparando-os com as soluções de outras principais blockchains e explorando 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 de uma rede de validadores e de uma cadeia de retransmissão. Isso pode, de alguma forma, introduzir riscos de centralização? É possível que surjam pontos únicos de falha ou controle, afetando assim suas características de descentralização?
A operação do Rollup depende do ordenamento do relé conectado à cadeia, cuja comunicação utiliza o mecanismo de protocolo de collation. 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 relé e submetendo pedidos de alteração de estado do Rollup. Esses pedidos serão verificados por algum núcleo da cadeia de relé, bastando satisfazer uma condição: deve ser uma alteração de estado válida, caso contrário, o estado desse Rollup não será avançado.
Compromissos de escalabilidade vertical
Rollup pode alcançar escalabilidade vertical ao aproveitar a arquitetura multi-core do Polkadot. Essa nova capacidade é 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 verificação. Um atacante pode explorar isso, submetendo repetidamente blocos legítimos que já foram verificados a diferentes cores, consumindo recursos de forma maliciosa e, assim, reduzindo a capacidade de processamento e a eficiência geral do rollup.
O objetivo do Polkadot é manter a elasticidade do rollup e a utilização eficaz dos recursos da cadeia de retransmissão, sem comprometer as características essenciais do sistema.
Sequencer é confiável?
Uma solução simples é definir o protocolo como "com licença": por exemplo, adotando um mecanismo de lista branca, ou confiando por defeito que os ordenadores não se comportarão de forma maliciosa, garantindo assim a atividade do rollup.
No entanto, na filosofia de design do Polkadot, não podemos fazer nenhuma suposição de confiança sobre o sequenciador, pois é necessário manter as características de "sem confiança" e "sem permissão" do sistema. Qualquer pessoa deve ser capaz de usar o protocolo collator para submeter solicitações de transformação de estado do rollup.
Polkadot: Uma solução sem compromissos
A solução final escolhida pelo Polkadot é: deixar a questão completamente a cargo da função de transformaçã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 onde a validação deve ser executada no núcleo do Polkadot.
Este design proporciona uma dupla garantia de flexibilidade e segurança. O Polkadot irá reexecutar as transições 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 rollup bloco escreva na camada de disponibilidade de dados do Polkadot, um grupo composto por cerca de 5 validadores irá primeiro verificar sua legalidade. Eles recebem os recibos candidatos e as provas de validade submetidas pelo ordenadores, que contêm o bloco rollup e os correspondentes comprovantes de armazenamento. 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 core selector, que é usado para especificar em qual core o bloco deve ser verificado. O validador comparará se esse índice é consistente com o core pelo qual é responsável; se não for consistente, o bloco será descartado.
Este mecanismo garante que o sistema mantenha sempre as características de confiança e permissão, evitando que agentes maliciosos, como ordenadores, manipulem a posição de verificação, garantindo que mesmo com múltiplos núcleos, o rollup possa manter a resiliência.
segurança
No processo de busca pela escalabilidade, o Polkadot não fez concessões na segurança. A segurança dos rollups é garantida pela cadeia de retransmissão, sendo necessário apenas um ordenado honesto para manter a sobrevivência.
Com o protocolo ELVES, o Polkadot estende completamente sua segurança a todos os rollups, validando todos os cálculos no núcleo, sem a 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.
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 Turing completos em um ambiente WebAssembly, desde que a execução única seja concluída em até 2 segundos. Com a escalabilidade elástica, a quantidade total de cálculos executáveis 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 maneira aceitável de compensação no design de sistemas.
O Rollup pode ajustar dinamicamente os recursos através da interface Agile Coretime para manter um nível de segurança consistente. Eles também precisam implementar parcialmente os requisitos do RFC103 para se adaptar a diferentes cenários de uso.
A complexidade específica depende da estratégia de gestão de recursos do rollup, que pode depender de variáveis on-chain ou off-chain. Por exemplo:
Estratégia simples: use sempre uma quantidade fixa de core, ou ajuste manualmente fora da cadeia;
Estratégia leve: monitorar cargas de transação específicas no mempool do nó;
Estratégias de automação: configurar recursos chamando antecipadamente o serviço coretime através de dados históricos e da interface XCM.
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 de mensagens fora da cadeia, com a cadeia de retransmissão atuando como a camada de controle, em vez da 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.
Que compromissos foram feitos por outros protocolos?
É bem conhecido que o aumento de desempenho muitas vezes vem à custa da descentralização e da segurança. Mas, 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 utiliza a arquitetura de sharding do Polkadot ou do Ethereum, mas sim uma arquitetura de camada única de alto throughput 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 alcançar 65.000.
Um design chave é o seu mecanismo de agendamento de líderes pré-publicado e verificável:
No início de cada epoch (cerca de dois dias ou 432.000 slots), os slots são distribuídos com base na quantidade de staking.
Quanto mais você apostar, mais será distribuído. Por exemplo, um validador que aposta 1% terá cerca de 1% de chance de criar blocos;
Todos os mineradores são anunciados antecipadamente, aumentando o risco de ataques DDoS direcionados à rede e quedas frequentes.
PoH e o processamento paralelo exigem hardware de alta qualidade, levando à centralização dos nós de validação. Quanto mais um nó estiver em stake, maior será a sua oportunidade de criar blocos, enquanto nós menores quase não têm slots, o que acentua 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 inferior ao de Polkadot, que é 172.
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 atingiu 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 sharding pode ser exposta antecipadamente. O white paper do TON também aponta que, embora isso possa otimizar a largura de banda, também pode ser explorado maliciosamente. Devido à falta de um mecanismo de "falência do apostador", os atacantes podem esperar que um determinado shard seja totalmente controlado por eles, ou interromper validadores honestos por meio de ataques DDoS, alterando assim o estado.
Em comparação, os validadores do Polkadot são atribuídos aleatoriamente e revelados com atraso, os atacantes não podem saber de antemão a identidade dos validadores, o ataque deve apostar todo o controle para ser bem-sucedido; assim que um validador honesto iniciar uma disputa, o ataque falhará e resultará na perda do colateral do atacante.
Avalanche
Avalanche utiliza 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 (gerenciamento de validadores e subnets).
Cada sub-rede pode atingir uma TPS teórica de ~5.000, semelhante à ideia 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 geográficos, KYC e outros requisitos adicionais, 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 ser completamente centralizadas. Para aumentar a segurança, ainda é necessário comprometer o desempenho, e é difícil oferecer um compromisso de segurança determinístico.
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.
Rollup Optimista
Atualmente, a maioria dos optimistic rollups é centralizada (alguns têm apenas um sequenciador), o que leva a 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 necessidade computacional para gerar provas de conhecimento zero é extremamente alta, e o mecanismo de "o vencedor leva tudo" pode levar à centralização do sistema. Para garantir o TPS, o ZK rollup frequentemente limita o volume de transações por lote, o que pode causar congestionamento na rede e aumento do gas em momentos de alta demanda, afetando a experiência do usuário.
Em comparação, o custo do ZK rollup Turing completo é cerca de 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 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 públicas, o Polkadot não seguiu o caminho de trocar centralização por performance ou confiança pré-estabelecida por eficiência, mas sim alcançou um equilíbrio multidimensional entre segurança, descentralização e alta performance através de escalabilidade flexível, design de protocolos sem permissão, uma camada de segurança unificada e um mecanismo de gestão de recursos flexível.
Na busca pela implementação em maior escala hoje, a "escalabilidade de confiança zero" 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.
12 gostos
Recompensa
12
8
Partilhar
Comentar
0/400
LiquidityWhisperer
· 18h atrás
Velocidade e segurança não podem ser ambas?
Ver originalResponder0
DiamondHands
· 20h atrás
A velocidade e a segurança são mutuamente exclusivas, não são?
Ver originalResponder0
GasGuru
· 07-21 22:12
Mais uma vez, a chain está a fazer um trabalho de equilíbrio.
Ver originalResponder0
TokenVelocity
· 07-21 22:10
A Polkadot é realmente estável? Ou é fazer as pessoas de parvas?
Ver originalResponder0
BearMarketSage
· 07-21 21:53
Não se pode ter tanto o peixe como o urso.
Ver originalResponder0
MidnightSeller
· 07-21 21:52
Sacrificar a segurança pela velocidade é quase como esperar pelo desastre.
Ver originalResponder0
PermabullPete
· 07-21 21:48
Entendi, mas e os pontos?
Ver originalResponder0
MEVSandwichMaker
· 07-21 21:48
O custo do sacrifício sempre tem que ser pago, só depende de quem explode primeiro.
Como o Polkadot implementa a escalabilidade sem confiança para liderar o futuro da Web3
Compromissos de escalabilidade: Desafios do Polkadot e Web3
Na busca por maior eficiência na blockchain hoje em dia, uma questão fundamental começa a se destacar: como escalar o desempenho sem sacrificar a segurança e a resiliência do sistema? Isso não é apenas um desafio técnico, mas uma escolha profunda na arquitetura de design. Para o ecossistema Web3, um sistema mais rápido, se construído sobre a base de sacrificar a confiança e a segurança, muitas vezes luta para sustentar inovações verdadeiramente sustentáveis.
Como um importante impulsionador da escalabilidade do Web3, o Polkadot fez algumas concessões em relação ao alto rendimento e baixa latência? O seu modelo de rollup fez concessões em descentralização, segurança ou interoperabilidade da rede?
Este artigo abordará essas questões, analisando profundamente os compromissos e trade-offs do Polkadot no design de escalabilidade, comparando-os com as soluções de outras principais blockchains e explorando 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 de uma rede de validadores e de uma cadeia de retransmissão. Isso pode, de alguma forma, introduzir riscos de centralização? É possível que surjam pontos únicos de falha ou controle, afetando assim suas características de descentralização?
A operação do Rollup depende do ordenamento do relé conectado à cadeia, cuja comunicação utiliza o mecanismo de protocolo de collation. 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 relé e submetendo pedidos de alteração de estado do Rollup. Esses pedidos serão verificados por algum núcleo da cadeia de relé, bastando satisfazer uma condição: deve ser uma alteração de estado válida, caso contrário, o estado desse Rollup não será avançado.
Compromissos de escalabilidade vertical
Rollup pode alcançar escalabilidade vertical ao aproveitar a arquitetura multi-core do Polkadot. Essa nova capacidade é 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 verificação. Um atacante pode explorar isso, submetendo repetidamente blocos legítimos que já foram verificados a diferentes cores, consumindo recursos de forma maliciosa e, assim, reduzindo a capacidade de processamento e a eficiência geral do rollup.
O objetivo do Polkadot é manter a elasticidade do rollup e a utilização eficaz dos recursos da cadeia de retransmissão, sem comprometer as características essenciais do sistema.
Sequencer é confiável?
Uma solução simples é definir o protocolo como "com licença": por exemplo, adotando um mecanismo de lista branca, ou confiando por defeito que os ordenadores não se comportarão de forma maliciosa, garantindo assim a atividade do rollup.
No entanto, na filosofia de design do Polkadot, não podemos fazer nenhuma suposição de confiança sobre o sequenciador, pois é necessário manter as características de "sem confiança" e "sem permissão" do sistema. Qualquer pessoa deve ser capaz de usar o protocolo collator para submeter solicitações de transformação de estado do rollup.
Polkadot: Uma solução sem compromissos
A solução final escolhida pelo Polkadot é: deixar a questão completamente a cargo da função de transformaçã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 onde a validação deve ser executada no núcleo do Polkadot.
Este design proporciona uma dupla garantia de flexibilidade e segurança. O Polkadot irá reexecutar as transições 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 rollup bloco escreva na camada de disponibilidade de dados do Polkadot, um grupo composto por cerca de 5 validadores irá primeiro verificar sua legalidade. Eles recebem os recibos candidatos e as provas de validade submetidas pelo ordenadores, que contêm o bloco rollup e os correspondentes comprovantes de armazenamento. 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 core selector, que é usado para especificar em qual core o bloco deve ser verificado. O validador comparará se esse índice é consistente com o core pelo qual é responsável; se não for consistente, o bloco será descartado.
Este mecanismo garante que o sistema mantenha sempre as características de confiança e permissão, evitando que agentes maliciosos, como ordenadores, manipulem a posição de verificação, garantindo que mesmo com múltiplos núcleos, o rollup possa manter a resiliência.
segurança
No processo de busca pela escalabilidade, o Polkadot não fez concessões na segurança. A segurança dos rollups é garantida pela cadeia de retransmissão, sendo necessário apenas um ordenado honesto para manter a sobrevivência.
Com o protocolo ELVES, o Polkadot estende completamente sua segurança a todos os rollups, validando todos os cálculos no núcleo, sem a 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.
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 Turing completos em um ambiente WebAssembly, desde que a execução única seja concluída em até 2 segundos. Com a escalabilidade elástica, a quantidade total de cálculos executáveis 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 maneira aceitável de compensação no design de sistemas.
O Rollup pode ajustar dinamicamente os recursos através da interface Agile Coretime para manter um nível de segurança consistente. Eles também precisam implementar parcialmente os requisitos do RFC103 para se adaptar a diferentes cenários de uso.
A complexidade específica depende da estratégia de gestão de recursos do rollup, que pode depender de variáveis on-chain ou off-chain. Por exemplo:
Estratégia simples: use sempre uma quantidade fixa de core, ou ajuste manualmente fora da cadeia;
Estratégia leve: monitorar cargas de transação específicas no mempool do nó;
Estratégias de automação: configurar recursos chamando antecipadamente o serviço coretime através de dados históricos e da interface XCM.
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 de mensagens fora da cadeia, com a cadeia de retransmissão atuando como a camada de controle, em vez da 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.
Que compromissos foram feitos por outros protocolos?
É bem conhecido que o aumento de desempenho muitas vezes vem à custa da descentralização e da segurança. Mas, 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 utiliza a arquitetura de sharding do Polkadot ou do Ethereum, mas sim uma arquitetura de camada única de alto throughput 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 alcançar 65.000.
Um design chave é o seu mecanismo de agendamento de líderes pré-publicado e verificável:
No início de cada epoch (cerca de dois dias ou 432.000 slots), os slots são distribuídos com base na quantidade de staking.
Quanto mais você apostar, mais será distribuído. Por exemplo, um validador que aposta 1% terá cerca de 1% de chance de criar blocos;
Todos os mineradores são anunciados antecipadamente, aumentando o risco de ataques DDoS direcionados à rede e quedas frequentes.
PoH e o processamento paralelo exigem hardware de alta qualidade, levando à centralização dos nós de validação. Quanto mais um nó estiver em stake, maior será a sua oportunidade de criar blocos, enquanto nós menores quase não têm slots, o que acentua 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 inferior ao de Polkadot, que é 172.
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 atingiu 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 sharding pode ser exposta antecipadamente. O white paper do TON também aponta que, embora isso possa otimizar a largura de banda, também pode ser explorado maliciosamente. Devido à falta de um mecanismo de "falência do apostador", os atacantes podem esperar que um determinado shard seja totalmente controlado por eles, ou interromper validadores honestos por meio de ataques DDoS, alterando assim o estado.
Em comparação, os validadores do Polkadot são atribuídos aleatoriamente e revelados com atraso, os atacantes não podem saber de antemão a identidade dos validadores, o ataque deve apostar todo o controle para ser bem-sucedido; assim que um validador honesto iniciar uma disputa, o ataque falhará e resultará na perda do colateral do atacante.
Avalanche
Avalanche utiliza 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 (gerenciamento de validadores e subnets).
Cada sub-rede pode atingir uma TPS teórica de ~5.000, semelhante à ideia 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 geográficos, KYC e outros requisitos adicionais, 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 ser completamente centralizadas. Para aumentar a segurança, ainda é necessário comprometer o desempenho, e é difícil oferecer um compromisso de segurança determinístico.
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.
Rollup Optimista
Atualmente, a maioria dos optimistic rollups é centralizada (alguns têm apenas um sequenciador), o que leva a 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 necessidade computacional para gerar provas de conhecimento zero é extremamente alta, e o mecanismo de "o vencedor leva tudo" pode levar à centralização do sistema. Para garantir o TPS, o ZK rollup frequentemente limita o volume de transações por lote, o que pode causar congestionamento na rede e aumento do gas em momentos de alta demanda, afetando a experiência do usuário.
Em comparação, o custo do ZK rollup Turing completo é cerca de 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 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 públicas, o Polkadot não seguiu o caminho de trocar centralização por performance ou confiança pré-estabelecida por eficiência, mas sim alcançou um equilíbrio multidimensional entre segurança, descentralização e alta performance através de escalabilidade flexível, design de protocolos sem permissão, uma camada de segurança unificada e um mecanismo de gestão de recursos flexível.
Na busca pela implementação em maior escala hoje, a "escalabilidade de confiança zero" defendida pelo Polkadot pode ser a verdadeira solução que sustenta o desenvolvimento a longo prazo da Web3.