Escalabilidade e Compromissos: Polkadot e as Decisões Técnicas do Ecossistema Web3
Na atualidade, em que a tecnologia blockchain busca constantemente maior eficiência, uma questão chave começa a se evidenciar: como garantir segurança e resiliência do sistema ao mesmo tempo em que se expande o desempenho? Este é um desafio que vai além da tecnologia, sendo uma escolha profunda de design de arquitetura. Para o ecossistema Web3, simplesmente buscar sistemas mais rápidos à custa da confiança e segurança não é suficiente para sustentar inovações verdadeiramente sustentáveis.
Como um importante impulsionador da escalabilidade do Web3, o Polkadot fez algumas concessões em sua busca por alta taxa de transferência e baixa latência? O seu modelo de rollup comprometeu a descentralização, a segurança ou a interoperabilidade da rede? Este artigo abordará essas questões, analisando em profundidade as escolhas e compromissos do Polkadot no design da escalabilidade, e fará uma comparação com as soluções de outras blockchains principais, explorando suas diferentes escolhas de caminhos entre desempenho, segurança e descentralização.
Desafios enfrentados no design de expansão do Polkadot
O equilíbrio entre flexibilidade e descentralização
A arquitetura do Polkadot depende de uma rede de validadores e de uma cadeia de retransmissão. Isso pode introduzir riscos de centralização em certos aspectos? É possível que surjam pontos únicos de falha ou controle, afetando assim suas características de descentralização?
A operação do Rollup depende do ordenamento do conector de cadeia intermediária, cuja comunicação utiliza o mecanismo de protocolo collator. Este protocolo é totalmente sem permissão e sem confiança, qualquer pessoa com uma conexão à rede pode utilizá-lo, conectando-se a um pequeno número de nós da cadeia intermediária e submetendo pedidos de conversão de estado do rollup. Esses pedidos serão verificados por um core da cadeia intermediária, desde que satisfaçam uma condição: devem ser conversões de estado válidas, caso contrário, o estado do rollup não será avançado.
Compromissos de escalabilidade vertical
O Rollup pode alcançar a escalabilidade vertical ao aproveitar a arquitetura multicore do Polkadot. Essa nova capacidade foi introduzida pela funcionalidade de "escalabilidade flexível". Durante o processo de design, foi descoberto que, como a validação de blocos de rollup não é fixada em um core específico, isso pode afetar sua flexibilidade.
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 de processamento e eficiência geral 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 essenciais do sistema.
Problemas de confiabilidade 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 os ordenadores não terão 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 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 transformação de estado do rollup.
Polkadot: A solução sem compromissos
A solução finalmente escolhida pelo Polkadot é: deixar a questão completamente a cargo da função de transição de estado do rollup (Runtime). O Runtime é a única fonte confiável de todas as informações de consenso, portanto, deve ser declarado claramente na saída onde a validação deve ser executada no núcleo do Polkadot.
Este design garante simultaneamente flexibilidade e segurança. Polkadot reexecutará a transição de estado do rollup no processo de disponibilidade e garantirá a correção da alocação do core através do protocolo econômico criptográfico ELVES.
Antes de escrever os dados na camada de disponibilidade de dados (DA) do Polkadot em qualquer bloco rollup, um grupo composto por cerca de 5 validadores irá primeiro verificar a sua legalidade. Eles recebem os recibos candidatos e as provas de validade submetidos pelo ordenator, que contêm o bloco rollup e as respectivas provas de armazenamento. Essas informações serão processadas pela função de validação da cadeia paralela e reexecutadas pelos validadores na cadeia de retransmissão.
O resultado da validação inclui um seletor de core, que é utilizado para especificar em qual core o bloco deve ser validado. O validador irá comparar se este í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 confiança e sem 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 por escalabilidade, a Polkadot não comprometeu a segurança. A segurança do rollup é garantida pela cadeia de retransmissão, sendo necessário apenas um organizador honesto para manter a sobrevivência.
Com o protocolo ELVES, a Polkadot estende a sua segurança de forma completa a todos os rollups, validando todos os cálculos no core, sem necessidade de limitar ou fazer 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.
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 menor latência inevitavelmente introduzem complexidade, que é a única forma aceitável de compromisso no design de sistemas.
Os Rollups podem ajustar dinamicamente os recursos através da interface Agile Coretime, para manter um nível de segurança consistente. Eles também precisam atender a alguns 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 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 chamando o serviço coretime.
Embora a automação seja mais eficiente, os custos de implementação e teste também aumentam significativamente.
Interoperabilidade
Polkadot suporta a interoperabilidade entre diferentes rollups, 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 alocados.
No futuro, o Polkadot também suportará a comunicação de mensagens off-chain, com a cadeia de retransmissão atuando como a camada de controle, em vez da camada de dados. Esta atualização aumentará a capacidade de comunicação entre rollups juntamente com a expansão 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, do ponto de vista do coeficiente de Nakamoto, mesmo que alguns concorrentes do Polkadot tenham um nível de descentralização mais baixo, seu desempenho não é tão satisfatório.
Uma Blockchain A
Uma determinada blockchain A não utiliza a arquitetura de sharding do Polkadot ou do Ethereum, mas sim uma arquitetura de camada única de alta capacidade de processamento 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 que é previamente divulgado 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 stake;
Quanto mais se aposta, mais se distribui. Por exemplo, um validador que aposta 1% terá cerca de 1% de chance de produzir blocos;
Todos os mineradores são anunciados antecipadamente, aumentando o risco da rede sofrer ataques DDoS direcionados e frequentes interrupções.
A história prova que o processamento paralelo exige altos requisitos de hardware, levando à centralização dos nós de validação. Quanto mais um nó está em stake, maiores são as suas chances de produzir blocos, enquanto nós menores quase não têm slots, agravando ainda mais a centralização e aumentando o risco de colapso do sistema após um ataque.
A certa blockchain A, em busca de TPS, sacrificou a descentralização e a capacidade de resistência a ataques, com um coeficiente de Nakamoto de apenas 20, muito abaixo dos 172 do Polkadot.
Uma blockchain pública B
Uma blockchain pública B afirma que o TPS pode atingir 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. Por outro lado, o Polkadot já alcançou 128K TPS em uma rede pública descentralizada.
O mecanismo de consenso da blockchain pública B apresenta vulnerabilidades de segurança: a identidade dos nós de validação de sharding pode ser exposta antecipadamente. O white paper da blockchain pública B 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 jogador", os atacantes podem esperar que um determinado sharding 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 aleatoriamente e revelados com atraso, os atacantes não conseguem saber a identidade dos validadores com antecedência, o ataque requer que apostem todo o controle com sucesso; assim que um validador honesto iniciar uma disputa, o ataque falhará e causará perdas ao atacante.
Alguma Blockchain C
A certa blockchain pública C utiliza uma arquitetura de rede principal + sub-rede para escalabilidade, sendo que 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).
Teoricamente, cada sub-rede pode atingir uma TPS de ~5.000, semelhante à abordagem do Polkadot: reduzir a carga de um único shard para alcançar a escalabilidade. No entanto, uma determinada blockchain C permite que os validadores escolham livremente participar de sub-redes, e as sub-redes podem estabelecer requisitos adicionais como geográficos e KYC, sacrificando a descentralização e a segurança.
No Polkadot, todos os rollups compartilham uma garantia de segurança unificada; enquanto que a subnet da blockchain pública C não possui uma garantia de segurança padrão, algumas podem até ser completamente centralizadas. Se se deseja aumentar a segurança, ainda é necessário fazer compromissos em termos de desempenho, e é difícil fornecer promessas de segurança determinísticas.
Uma cadeia pública D
A estratégia de escalabilidade da blockchain pública D 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 acima na pilha.
Rollup Otimista
Atualmente, a maioria das Optimistic rollups são centralizadas (algumas até têm apenas um sequenciador), enfrentando problemas como insuficiência de segurança, isolamento entre si e alta latência (é necessário aguardar o 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 conhecimento zero é extremamente alta, e o mecanismo de "vencedor leva tudo" pode facilmente 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 períodos de alta demanda, afetando a experiência do usuário.
Em comparação, o custo de um ZK rollup Turing completo é aproximadamente 2x10^6 vezes o do protocolo de segurança econômica central do Polkadot.
Além disso, os problemas de disponibilidade de dados do ZK rollup também agravarão 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 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 protocolo 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 "escabilidade de zero confiança" defendida pelo Polkadot pode ser a verdadeira solução que sustenta o desenvolvimento a longo prazo do Web3.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
13 Curtidas
Recompensa
13
6
Compartilhar
Comentário
0/400
FlashLoanKing
· 6h atrás
Conseguir ganhar apenas com velocidade? Culpar os usuários, certo?
Ver originalResponder0
LiquidityWizard
· 6h atrás
falando teoricamente, a escalabilidade do dot = 73.8% compromisso de segurança... não é ótimo, para ser honesto
Ver originalResponder0
0xOverleveraged
· 6h atrás
Continua a mesma coisa, tudo se resume a rollup.
Ver originalResponder0
OneBlockAtATime
· 7h atrás
Dot é a pedra angular, o resto é ilusão.
Ver originalResponder0
WalletDoomsDay
· 7h atrás
Brinque à vontade, deixa eu começar. O que há de tão complicado no Blockchain?
Ver originalResponder0
ContractSurrender
· 7h atrás
Sacrifique a segurança e tal, já chega, é melhor capitular cedo.
Polkadot escalabilidade elástica: a troca entre escalabilidade e segurança no ecossistema Web3
Escalabilidade e Compromissos: Polkadot e as Decisões Técnicas do Ecossistema Web3
Na atualidade, em que a tecnologia blockchain busca constantemente maior eficiência, uma questão chave começa a se evidenciar: como garantir segurança e resiliência do sistema ao mesmo tempo em que se expande o desempenho? Este é um desafio que vai além da tecnologia, sendo uma escolha profunda de design de arquitetura. Para o ecossistema Web3, simplesmente buscar sistemas mais rápidos à custa da confiança e segurança não é suficiente para sustentar inovações verdadeiramente sustentáveis.
Como um importante impulsionador da escalabilidade do Web3, o Polkadot fez algumas concessões em sua busca por alta taxa de transferência e baixa latência? O seu modelo de rollup comprometeu a descentralização, a segurança ou a interoperabilidade da rede? Este artigo abordará essas questões, analisando em profundidade as escolhas e compromissos do Polkadot no design da escalabilidade, e fará uma comparação com as soluções de outras blockchains principais, explorando suas diferentes escolhas de caminhos entre desempenho, segurança e descentralização.
Desafios enfrentados no design de expansão do Polkadot
O equilíbrio entre flexibilidade e descentralização
A arquitetura do Polkadot depende de uma rede de validadores e de uma cadeia de retransmissão. Isso pode introduzir riscos de centralização em certos aspectos? É possível que surjam pontos únicos de falha ou controle, afetando assim suas características de descentralização?
A operação do Rollup depende do ordenamento do conector de cadeia intermediária, cuja comunicação utiliza o mecanismo de protocolo collator. Este protocolo é totalmente sem permissão e sem confiança, qualquer pessoa com uma conexão à rede pode utilizá-lo, conectando-se a um pequeno número de nós da cadeia intermediária e submetendo pedidos de conversão de estado do rollup. Esses pedidos serão verificados por um core da cadeia intermediária, desde que satisfaçam uma condição: devem ser conversões de estado válidas, caso contrário, o estado do rollup não será avançado.
Compromissos de escalabilidade vertical
O Rollup pode alcançar a escalabilidade vertical ao aproveitar a arquitetura multicore do Polkadot. Essa nova capacidade foi introduzida pela funcionalidade de "escalabilidade flexível". Durante o processo de design, foi descoberto que, como a validação de blocos de rollup não é fixada em um core específico, isso pode afetar sua flexibilidade.
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 de processamento e eficiência geral 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 essenciais do sistema.
Problemas de confiabilidade 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 os ordenadores não terão 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 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 transformação de estado do rollup.
Polkadot: A solução sem compromissos
A solução finalmente escolhida pelo Polkadot é: deixar a questão completamente a cargo da função de transição de estado do rollup (Runtime). O Runtime é a única fonte confiável de todas as informações de consenso, portanto, deve ser declarado claramente na saída onde a validação deve ser executada no núcleo do Polkadot.
Este design garante simultaneamente flexibilidade e segurança. Polkadot reexecutará a transição de estado do rollup no processo de disponibilidade e garantirá a correção da alocação do core através do protocolo econômico criptográfico ELVES.
Antes de escrever os dados na camada de disponibilidade de dados (DA) do Polkadot em qualquer bloco rollup, um grupo composto por cerca de 5 validadores irá primeiro verificar a sua legalidade. Eles recebem os recibos candidatos e as provas de validade submetidos pelo ordenator, que contêm o bloco rollup e as respectivas provas de armazenamento. Essas informações serão processadas pela função de validação da cadeia paralela e reexecutadas pelos validadores na cadeia de retransmissão.
O resultado da validação inclui um seletor de core, que é utilizado para especificar em qual core o bloco deve ser validado. O validador irá comparar se este í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 confiança e sem 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 por escalabilidade, a Polkadot não comprometeu a segurança. A segurança do rollup é garantida pela cadeia de retransmissão, sendo necessário apenas um organizador honesto para manter a sobrevivência.
Com o protocolo ELVES, a Polkadot estende a sua segurança de forma completa a todos os rollups, validando todos os cálculos no core, sem necessidade de limitar ou fazer 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.
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 menor latência inevitavelmente introduzem complexidade, que é a única forma aceitável de compromisso no design de sistemas.
Os Rollups podem ajustar dinamicamente os recursos através da interface Agile Coretime, para manter um nível de segurança consistente. Eles também precisam atender a alguns 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:
Embora a automação seja mais eficiente, os custos de implementação e teste também aumentam significativamente.
Interoperabilidade
Polkadot suporta a interoperabilidade entre diferentes rollups, 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 alocados.
No futuro, o Polkadot também suportará a comunicação de mensagens off-chain, com a cadeia de retransmissão atuando como a camada de controle, em vez da camada de dados. Esta atualização aumentará a capacidade de comunicação entre rollups juntamente com a expansão 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, do ponto de vista do coeficiente de Nakamoto, mesmo que alguns concorrentes do Polkadot tenham um nível de descentralização mais baixo, seu desempenho não é tão satisfatório.
Uma Blockchain A
Uma determinada blockchain A não utiliza a arquitetura de sharding do Polkadot ou do Ethereum, mas sim uma arquitetura de camada única de alta capacidade de processamento 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 que é previamente divulgado e verificável:
A história prova que o processamento paralelo exige altos requisitos de hardware, levando à centralização dos nós de validação. Quanto mais um nó está em stake, maiores são as suas chances de produzir blocos, enquanto nós menores quase não têm slots, agravando ainda mais a centralização e aumentando o risco de colapso do sistema após um ataque.
A certa blockchain A, em busca de TPS, sacrificou a descentralização e a capacidade de resistência a ataques, com um coeficiente de Nakamoto de apenas 20, muito abaixo dos 172 do Polkadot.
Uma blockchain pública B
Uma blockchain pública B afirma que o TPS pode atingir 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. Por outro lado, o Polkadot já alcançou 128K TPS em uma rede pública descentralizada.
O mecanismo de consenso da blockchain pública B apresenta vulnerabilidades de segurança: a identidade dos nós de validação de sharding pode ser exposta antecipadamente. O white paper da blockchain pública B 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 jogador", os atacantes podem esperar que um determinado sharding 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 aleatoriamente e revelados com atraso, os atacantes não conseguem saber a identidade dos validadores com antecedência, o ataque requer que apostem todo o controle com sucesso; assim que um validador honesto iniciar uma disputa, o ataque falhará e causará perdas ao atacante.
Alguma Blockchain C
A certa blockchain pública C utiliza uma arquitetura de rede principal + sub-rede para escalabilidade, sendo que 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).
Teoricamente, cada sub-rede pode atingir uma TPS de ~5.000, semelhante à abordagem do Polkadot: reduzir a carga de um único shard para alcançar a escalabilidade. No entanto, uma determinada blockchain C permite que os validadores escolham livremente participar de sub-redes, e as sub-redes podem estabelecer requisitos adicionais como geográficos e KYC, sacrificando a descentralização e a segurança.
No Polkadot, todos os rollups compartilham uma garantia de segurança unificada; enquanto que a subnet da blockchain pública C não possui uma garantia de segurança padrão, algumas podem até ser completamente centralizadas. Se se deseja aumentar a segurança, ainda é necessário fazer compromissos em termos de desempenho, e é difícil fornecer promessas de segurança determinísticas.
Uma cadeia pública D
A estratégia de escalabilidade da blockchain pública D 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 acima na pilha.
Rollup Otimista
Atualmente, a maioria das Optimistic rollups são centralizadas (algumas até têm apenas um sequenciador), enfrentando problemas como insuficiência de segurança, isolamento entre si e alta latência (é necessário aguardar o 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 conhecimento zero é extremamente alta, e o mecanismo de "vencedor leva tudo" pode facilmente 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 períodos de alta demanda, afetando a experiência do usuário.
Em comparação, o custo de um ZK rollup Turing completo é aproximadamente 2x10^6 vezes o do protocolo de segurança econômica central do Polkadot.
Além disso, os problemas de disponibilidade de dados do ZK rollup também agravarão 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 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 protocolo 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 "escabilidade de zero confiança" defendida pelo Polkadot pode ser a verdadeira solução que sustenta o desenvolvimento a longo prazo do Web3.