Equilíbrio entre escalabilidade, segurança e Descentralização: as escolhas tecnológicas do Polkadot

Na busca contínua por maior eficiência na blockchain, uma questão crucial está gradualmente se destacando: ao melhorar a escalabilidade, será necessário sacrificar a segurança e a resiliência do sistema?

Este não é apenas um desafio a nível técnico, mas também uma escolha profunda no design da arquitetura. Para o ecossistema Web3, um sistema mais rápido que se baseie na sacrifício da confiança e da segurança frequentemente tem dificuldade em sustentar inovações verdadeiramente sustentáveis.

Polkadot, como um importante impulsionador da escalabilidade do Web3, fez algumas concessões em busca de alta capacidade de processamento e baixa latência? O seu modelo de rollup fez concessões em termos de Descentralização, segurança ou interoperabilidade da rede?

Este artigo abordará estas questões, analisando em profundidade as concessões e compromissos do Polkadot no design de escalabilidade, e comparando-o com as soluções de outras blockchains principais, explorando as diferentes escolhas de caminhos entre desempenho, segurança e Descentralização.

Desafios enfrentados no design de expansão do Polkadot

Equilíbrio entre elasticidade e Descentralização

A arquitetura do Polkadot depende de uma rede de validadores e de uma cadeia de relé centralizada, será que isso pode introduzir riscos de centralização em certos aspectos? É possível que se forme um ponto único de falha ou controle, afetando assim suas características de Descentralização?

A execução do Rollup depende de um ordenadora 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 usá-lo, conectando-se a um pequeno número de nós da cadeia de retransmissão e submetendo solicitações de conversão de estado do rollup. Essas solicitações serão verificadas por um core da cadeia de retransmissão, desde que seja atendido um pré-requisito: deve ser uma conversão de estado válida, 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 ao aproveitar a arquitetura de múltiplos núcleos do Polkadot. Esta nova capacidade é introduzida pela funcionalidade de "expansão flexível". Durante o processo de design, foi descoberto que, como a validação dos blocos de rollup não é fixada em um núcleo 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 recursos de forma maliciosa, e assim reduzindo a capacidade geral e a eficiência do rollup.

O objetivo do Polkadot é manter a flexibilidade do rollup e a utilização eficaz dos recursos da cadeia de retransmissão, sem comprometer as características essenciais do sistema.

O 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 padrão que o ordenadora não agirá 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 precisamos manter as características de "sem confiança" e "sem permissão" do sistema. Qualquer pessoa deve poder usar o protocolo collator para submeter pedidos de transformação de estado do rollup.

Polkadot: Solução sem compromissos

A solução final 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 explicitamente declarado em qual núcleo do Polkadot a validação deve ser executada.

Este design proporciona uma dupla garantia de flexibilidade e segurança. 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 de criptografia ELVES.

Antes de escrever os dados da rollup no layer 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 submetidos pelo ordenadores, que contêm o bloco rollup e a prova de armazenamento correspondente. Essas informações serão processadas pela função de validação da cadeia paralela, que será reexecutada pelos validadores na cadeia de retransmissão.

O resultado da verificação inclui um selector core, que é usado para especificar em qual core o bloco deve ser validado. O validador irá comparar se esse í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 manipuladores maliciosos, como ordenadores, controlem a posição de verificação, assegurando que mesmo que o rollup utilize vários núcleos, a elasticidade seja mantida.

Segurança

Na busca pela escalabilidade, a Polkadot não comprometeu a segurança. A segurança dos rollups é garantida pela cadeia de retransmissão, necessitando apenas de um ordenante honesto para manter a sobrevivência.

Através do protocolo ELVES, o Polkadot expande a sua segurança de forma completa para todos os rollups, validando todos os cálculos no core, sem necessidade de impor qualquer limitação ou suposição sobre o número de núcleos utilizados.

Assim, os rollups do Polkadot podem alcançar uma verdadeira escalabilidade sem sacrificar a segurança.

Universalidade

A escalabilidade elástica não 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 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

Maior throughput e menor latência 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 implementar parte dos 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: Monitorizar a carga de transações específicas no mempool dos nós;

• 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 automatizaçã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 fora da cadeia, com a cadeia de retransmissão servindo como a camada de controle, em vez da camada de dados. Esta atualização irá melhorar a capacidade de comunicação entre rollups juntamente com a escalabilidade elástica, aumentando ainda mais a capacidade de escalabilidade vertical do sistema.

Que compromissos foram feitos por outros protocolos?

É bem sabido que o aumento de desempenho geralmente vem à custa da Descentralização e da segurança. No entanto, em termos do coeficiente de Nakamoto, mesmo que alguns concorrentes do Polkadot tenham um nível de Descentralização mais baixo, o 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 alta capacidade de processamento 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 de até 65.000.

Um design chave é o seu mecanismo de agendamento de líderes, que é 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ê delegar, mais você receberá. Por exemplo, um validador que delega 1% terá cerca de 1% de chance de produzir blocos;

• Todos os produtores de blocos são anunciados antecipadamente, aumentando o risco de o rede sofrer ataques DDoS direcionados e quedas frequentes.

PoH e o processamento paralelo têm altas exigências de hardware, levando à centralização dos nós de validação. Quanto mais nós estiverem em staking, maior será a chance de criar blocos, enquanto nós pequenos quase não têm slots, 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 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 atingir 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 vulnerabilidades de segurança: a identidade dos nós de validação de fragmentos pode ser exposta antecipadamente. O white paper do TON também deixa claro que, embora isso possa otimizar a largura de banda, também pode ser explorado maliciosamente. Devido à falta de um mecanismo de "falência do apostador", os atacantes podem esperar que um fragmento seja totalmente controlado por eles ou interromper validadores honestos através de ataques DDoS, a fim de adulterar o estado.

Em comparação, os validadores do Polkadot são atribuídos aleatoriamente e revelados com atraso, os atacantes não podem saber a identidade dos validadores com antecedência, o ataque deve apostar o controle total para ter sucesso, desde que haja um validador honesto que inicie uma disputa, o ataque falhará e resultará na perda da garantia do atacante.

Avalanche

Avalanche utiliza uma arquitetura de rede principal + sub-rede para escalabilidade, com a rede principal composta por X-Chain (transferências, ~4.500 TPS), C-Chain (contratos inteligentes, ~100-200 TPS) e P-Chain (gestão de validadores e sub-redes).

Cada sub-rede pode ter um TPS teórico de até ~5.000, similar à 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 estas podem 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 garantia de segurança por padrão, algumas podem ser totalmente centralizadas. Para aumentar a segurança, ainda é necessário comprometer o desempenho, e é difícil fornecer uma garantia 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 os problemas, mas sim os transfere para a camada superior da pilha.

Rollup otimista

Atualmente, a maioria das Optimistic rollups é descentralizada (algumas têm até um único sequenciador), apresentando problemas como falta de segurança, isolamento entre si e alta latência (é necessário esperar pelo período de prova de fraude, que geralmente leva alguns dias).

ZK Rollup

A implementação de ZK rollup é limitada pela quantidade de dados que uma única transação pode processar. A necessidade de computação para gerar provas de conhecimento zero é extremamente alta, e o mecanismo de "winner takes all" pode levar à centralização do sistema. Para garantir o TPS, os ZK rollups frequentemente limitam o volume de transações por lote, o que pode causar congestionamento na rede e aumento do gas durante períodos de alta demanda, afetando a experiência do usuário.

Em comparação, o custo do ZK rollup Turing completo é aproximadamente 2x10^6 vezes o do protocolo de segurança econômica central do Polkadot.

Além disso, os problemas de disponibilidade de dados do ZK rollup também agravarão suas desvantagens. Para garantir que qualquer pessoa possa validar as transações, ainda é necessário fornecer dados de transação completos. Isso geralmente depende de soluções adicionais de disponibilidade de dados, aumentando ainda mais os custos e 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 de 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 suporta o desenvolvimento a longo prazo do Web3.