Os compromissos e desafios da escalabilidade do Blockchain: a solução da Polkadot

Hoje, em um contexto em que a tecnologia Blockchain busca constantemente maior eficiência, uma questão chave começa a se destacar: como melhorar o desempenho sem sacrificar a segurança e a resiliência do sistema? Isso não é apenas um desafio em nível técnico, mas também uma escolha profunda em termos de design de arquitetura. Para o ecossistema Web3, um sistema mais rápido, se construído sobre a base de sacrificar confiança e segurança, muitas vezes não consegue sustentar inovações verdadeiramente sustentáveis.

Polkadot, como um importante impulsionador da escalabilidade do Web3, fez concessões no seu modelo de rollup em termos de descentralização, segurança ou interoperabilidade da rede? Este artigo irá analisar profundamente as escolhas e compromissos da Polkadot no design de escalabilidade, comparando-os com as soluções de outras blockchains populares, e explorará as diferentes opções que elas fazem entre 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 de uma cadeia de retransmissão (Relay Chain), o que pode introduzir riscos de centralização em certos aspectos. O funcionamento do Rollup depende dos sequenciadores que conectam a cadeia de retransmissão, cuja comunicação utiliza o mecanismo de protocolo collator. Este protocolo é completamente sem permissão e sem confiança, qualquer pessoa com conexão à rede pode utilizá-lo, conectar-se a um pequeno número de nós da cadeia de retransmissão e submeter pedidos de mudança de estado do rollup.

Compromisso de expansão vertical

Rollup pode conseguir escalabilidade vertical ao aproveitar a arquitetura multicore do Polkadot. Esta nova capacidade é introduzida pela funcionalidade de "Escalonamento Elástico" (Elastic Scaling). No entanto, como a validação dos blocos rollup não é fixada em um único core, isso pode afetar sua elasticidade. Um atacante pode aproveitar isso, submetendo blocos legítimos que já foram validados repetidamente em diferentes cores, consumindo maliciosamente recursos e, assim, reduzindo a taxa de transferência e eficiência geral do rollup.

Problema de confiança do Sequencer

Uma solução simples é configurar o protocolo como "com licença", por exemplo, adotando um mecanismo de lista branca, ou assumindo que o ordenadores de sequência por padrão não terão comportamentos maliciosos. No entanto, na filosofia de design do Polkadot, não se pode fazer nenhuma suposição de confiança sobre o sequenciador, uma vez que é necessário manter as características de "sem confiança" e "sem permissão" do sistema.

A solução do Polkadot

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, devendo declarar claramente na saída onde a validação deve ser executada no core do Polkadot.

Este design oferece 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 criptografado ELVES.

Antes de qualquer bloco rollup ser escrito na camada de disponibilidade de dados (DA) do Polkadot, um grupo de 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 as provas de armazenamento correspondentes. Estas 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 validação inclui um core selector, que é utilizado para especificar em qual core o bloco deve ser validado. O validador irá comparar se o índice corresponde ao core pelo qual é responsável; se não corresponder, o bloco será descartado.

Este mecanismo garante que o sistema mantenha sempre propriedades de não confiança e não 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 consiga manter a resiliência.

Segurança

No processo de busca por escalabilidade, o Polkadot não fez concessões em 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 expande sua segurança integralmente para todos os rollups, validando todos os cálculos no core, sem necessidade de impor quaisquer restrições ou suposições sobre o número de núcleos utilizados.

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 em cada ciclo de 6 segundos é aumentada, mas o tipo de cálculo não é afetado.

Complexidade

Um maior throughput e uma latência mais baixa inevitavelmente introduzem complexidade, que é a única forma aceitável de compromisso no design de sistemas. 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 adequar 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 carga de transações específicas no mempool do nó;
• Estratégia de automação: configurar recursos do serviço coretime antecipadamente 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, e a escalabilidade elástica 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 a atuar como camada de controlo, em vez de camada de dados. Esta atualização melhorará a capacidade de comunicação entre rollups juntamente com a escalabilidade elástica, aumentando ainda mais a capacidade de escalabilidade vertical do sistema.

Compromissos de outros protocolos

É bem conhecido que a melhoria do 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 é satisfatório.

Solana

A Solana utiliza 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 que pode chegar a 65.000. O seu design chave é um mecanismo de agendamento de líderes que é previamente público e verificável.

No entanto, o PoH e o processamento paralelo exigem hardware extremamente potente, levando à centralização dos nós de validação. Quanto mais um nó é staked, maior a sua chance de produzir blocos, enquanto pequenos nós têm quase nenhum slot, o que agrava ainda mais a centralização e aumenta o risco de paralisação do sistema após um ataque. A Solana, na busca por TPS, sacrificou a descentralização e a resistência a ataques, com um coeficiente de Nakamoto de apenas 20, muito abaixo dos 172 do Polkadot.

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. O Polkadot já 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 aponta que, embora isso possa otimizar a largura de banda, também pode ser explorado de forma maliciosa. Devido à falta de um mecanismo de "falência dos apostadores", os atacantes podem esperar que um fragmento seja totalmente controlado por eles ou bloquear 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 após um atraso, tornando impossível para um atacante saber antecipadamente a identidade dos validadores. O ataque deve apostar todo o controle para ter sucesso; desde que haja um validador honesto que inicie uma disputa, o ataque falhará e resultará na perda do depósito do atacante.

Avalanche

Avalanche utiliza uma arquitetura de mainnet + subnets para escalar, onde a mainnet é composta pela X-Chain (transferências, ~4.500 TPS), C-Chain (contratos inteligentes, ~100-200 TPS) e P-Chain (gestão de validadores e subnets). Cada subnet pode teoricamente alcançar TPS de ~5.000, semelhante à abordagem do Polkadot: reduzir a carga de um único shard para atingir a escalabilidade.

Mas o Avalanche permite que os validadores escolham livremente participar em sub-redes, e as sub-redes 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 garantias de segurança por padrão, algumas podem ser completamente centralizadas. Se se deseja aumentar a segurança, ainda é necessário comprometer o desempenho, e é difícil fornecer 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 o transfere para a camada superior da pilha.

Atualmente, a maioria dos Optimistic Rollups é centralizada, apresentando problemas como insuficiência de segurança, isolamento entre si e alta latência (é necessário esperar pelo período de prova de fraude, que geralmente dura vários dias).

A implementação do ZK Rollup é limitada pela quantidade de dados que uma única transação pode processar. A necessidade de cálculo 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 a quantidade 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 os 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 optou por trocar descentralizaçã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 design de protocolos de escalabilidade flexível, sem permissões, 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 sem confiança" defendida pelo Polkadot pode ser a verdadeira solução que sustentará o desenvolvimento de longo prazo do Web3.