A ponderação da escalabilidade no Web3: A solução do Polkadot

Na busca contínua por maior eficiência na blockchain, uma questão chave começa a se destacar: como garantir segurança e 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 uma escolha profunda na concepção da arquitetura. Para o ecossistema Web3, um sistema mais rápido, se baseado na sacrifício da confiança e da segurança, muitas vezes tem dificuldade em sustentar inovações verdadeiramente sustentáveis.

Polkadot, como um importante impulsionador da escalabilidade do Web3, fez concessões em descentralização, segurança ou interoperabilidade da rede com seu modelo de rollup? Este artigo irá analisar profundamente os trade-offs e compensações do Polkadot em seu design de escalabilidade, comparando com soluções de outras blockchains principais, explorando suas diferentes escolhas de caminho entre desempenho, segurança e descentralização.

Os Desafios do 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 suas características de descentralização?

A execução do Rollup depende de um ordenado do relay chain, cuja comunicação utiliza um mecanismo denominado protocolo collator. Este protocolo é completamente 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 relay chain e submetendo pedidos de mudança de estado do rollup. Esses pedidos serão verificados por um core da relay chain, bastando atender a uma condição: devem ser mudanças 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 aproveitando a arquitetura de múltiplos núcleos do Polkadot. Esta nova capacidade é introduzida pela funcionalidade de "escalabilidade elástica". Durante o processo de design, descobrimos que, uma vez que a validação dos blocos rollup não é fixada em um núcleo específico, isso pode afetar sua elasticidade.

Como o protocolo para a submissão de blocos à cadeia de interconexão é sem permissões e sem confiança, qualquer pessoa pode submeter blocos a qualquer core atribuído ao rollup para validação. Um atacante pode explorar isso, submetendo repetidamente blocos legítimos que já foram validados a diferentes cores, consumindo recursos de forma maliciosa e, assim, reduzindo a capacidade 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 de retransmissão, sem comprometer as características fundamentais do sistema.

O 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 defeito que o ordenadores não agirão de forma maliciosa, garantindo assim a atividade do rollup.

No entanto, na filosofia de design do Polkadot, não podemos fazer quaisquer pressupostos de confiança sobre o sequencer, pois precisamos manter as características de "sem confiança" e "sem permissão" do sistema. Qualquer pessoa deve ser capaz de usar o protocolo collator para enviar pedidos de transformação de estado do rollup.

Polkadot: A solução sem compromissos

A solução final escolhida pelo Polkadot é: deixar a questão totalmente a cargo da função de conversão de estado do rollup (Runtime). A Runtime é a única fonte confiável de todas as informações de consenso, portanto, deve ser declarado claramente na saída em qual núcleo do Polkadot a validação deve ser executada.

Este design proporciona uma dupla garantia de flexibilidade e segurança. Polkadot irá reexecutar a transição de estado do rollup no processo de disponibilidade e garantirá a correção da alocação do core através do protocolo econômico criptográfico ELVES.

Antes de qualquer rollup bloco ser escrito na camada de disponibilidade de dados (DA) do Polkadot, um grupo composto por cerca de 5 validadores verificará sua legitimidade. Eles recebem os recibos candidatos e as provas de validade submetidos pelo ordenadores, que contêm o bloco rollup e as respectivas provas de armazenamento. Essas informações serão processadas pela função de verificação da cadeia paralela, sendo reexecutadas pelos validadores na cadeia de retransmissão.

O resultado da verificação inclui um selector core, que é utilizado para especificar em qual core deve ser validado o bloco. O validador irá 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 características de não confiança e não permissão, evitando a manipulação da posição de verificação por agentes maliciosos como os ordenadores, garantindo que mesmo que o rollup utilize múltiplos núcleos, a resiliência seja mantida.

segurança

No processo de 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 ordenadora honesto para manter a sobrevivência.

Com o protocolo ELVES, o Polkadot estende a sua segurança de forma completa 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 sacrificar a segurança.

versatilidade

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 em cada ciclo de 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.

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 implementar parte dos requisitos da RFC103, a fim de 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 off-chain;

• Estratégia leve: Monitorar a carga de transações específicas no mempool do nó;

• Estratégia de automação: chamar antecipadamente o serviço coretime para configurar recursos através de dados históricos e da interface XCM.

Embora as abordagens automatizadas sejam mais eficientes, os custos de implementação e teste também aumentam significativamente.

Interoperabilidade

Polkadot suporta a interoperabilidade entre diferentes rollups, e a escalabilidade flexível não afeta a capacidade de throughput das 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 atuando como superfície de controle, em vez de superfície de dados. Esta atualização aumentará 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 conhecido que o aumento de desempenho muitas vezes vem à custa da descentralização e da segurança. Mas, olhando para o 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 blockchain pública 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 atribuídos com base na quantidade de staking;

• Quanto mais se aposta, mais se distribui. Por exemplo, um validador que aposta 1% terá cerca de 1% de chance de criar blocos;

• Todos os mineradores são anunciados com antecedência, aumentando o risco de ataques DDoS direcionados à rede e quedas frequentes.

A história prova que o processamento paralelo exige um hardware extremamente elevado, levando à centralização dos nós de validação. Quanto mais um nó é apostado, maiores são as chances de produzir um bloco, enquanto os nós menores praticamente não têm slots, exacerbando 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 pode atingir 104.715 TPS, 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. Já o Polkadot 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 esclarece que, embora isso possa otimizar a largura de banda, também pode ser explorado de forma maliciosa. Devido à falta do mecanismo de "falência do jogador", os atacantes podem esperar que um determinado shard esteja completamente sob seu controle ou bloquear os validadores honestos através de ataques DDoS, permitindo assim a manipulação do estado.

Em comparação, os validadores do Polkadot são distribuídos aleatoriamente e revelados com atraso, de modo que os atacantes não podem saber com antecedência a identidade dos validadores. O ataque deve apostar no controle total para ter sucesso; assim que um validador honesto iniciar uma disputa, o ataque falhará e causará perdas ao atacante.

Uma cadeia pública C

Uma cadeia pública C adota uma arquitetura de rede principal + sub-rede para expansão, onde a rede principal é composta por X-Chain (transferências, ~4.500 TPS), C-Chain (contratos inteligentes, ~100--200 TPS) e P-Chain (gerenciamento de validadores e sub-redes).

O TPS teórico de cada sub-rede pode chegar a ~5.000, semelhante à ideia do Polkadot: reduzir a carga de um único shard para alcançar escalabilidade. No entanto, uma determinada blockchain C permite que os validadores escolham livremente participar de sub-rede, e as sub-redes podem estabelecer requisitos adicionais como geográficos e KYC, sacrificando descentralização e segurança.

No Polkadot, todos os rollups compartilham uma garantia de segurança unificada; enquanto a sub-rede da blockchain pública C não tem garantias de segurança por padrão, algumas podem ser completamente centralizadas. Se quisermos aumentar a segurança, ainda precisamos fazer compromissos em termos de 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 diretamente os problemas na camada base. Esta abordagem, na essência, não resolve o problema, mas sim o transfere para a camada superior da pilha.

Rollup Otimista

Atualmente, a maioria dos Optimistic rollups é centralizada (alguns têm até 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 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 "winner takes all" pode levar à centralização do sistema. Para garantir o TPS, o ZK rollup frequentemente limita a quantidade de transações por lote, o que pode causar congestionamento na rede e aumento do gás durante períodos 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 agravará suas desvantagens. Para garantir que qualquer pessoa possa validar 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 optou por trocar a descentralização por desempenho ou a 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 um mecanismo de gestão de recursos flexível.

Na busca pela implementação em maior escala hoje, o "escalonamento de zero confiança" defendido pela Polkadot pode ser a verdadeira solução que sustenta o desenvolvimento a longo prazo do Web3.