Compromissos de escalabilidade: Polkadot e a escolha do Web3

Hoje, em que a tecnologia blockchain busca constantemente a melhoria da eficiência, uma questão crucial começa a emergir: como melhorar a escalabilidade sem 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, se construído sobre a base de sacrificar a confiança e a segurança, muitas vezes não consegue sustentar inovações verdadeiramente sustentáveis.

Como um importante impulsionador da escalabilidade do Web3, Polkadot fez algumas concessões na busca por alta taxa de transferência e baixa latência? O seu modelo de rollup fez concessões em descentralização, segurança ou interoperabilidade da rede? Este artigo irá analisar profundamente as escolhas e compromissos do Polkadot no design de escalabilidade e compará-los com as soluções de outras blockchains principais, explorando suas diferentes opções em 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 de um ordenado que conecta a cadeia de retransmissão, e sua comunicação utiliza um mecanismo chamado protocolo collator. Este protocolo é completamente sem permissão e sem confiança, qualquer pessoa com uma conexão de rede pode utilizá-lo, conectando-se a um pequeno número de nós da cadeia de retransmissão e enviando pedidos de transformação de estado do rollup. Esses pedidos serão verificados por algum núcleo da cadeia de retransmissão, desde que cumpra uma condição: deve ser uma transformação de estado válida, caso contrário, o estado desse rollup não será avançado.

Compromissos de escalabilidade vertical

Os Rollups podem alcançar a escalabilidade vertical ao aproveitar a arquitetura multicore do Polkadot. Esta nova capacidade foi introduzida pela funcionalidade de "escalabilidade elástica". Durante o processo de design, foi descoberto que, como a validação de blocos de rollup não é fixa 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 validação. Um atacante pode explorar isso, submetendo repetidamente blocos legítimos que já foram validados a diferentes cores, consumindo maliciosamente recursos e, assim, reduzindo a taxa de transferência e a eficiência geral do rollup.

O objetivo do Polkadot é manter a elasticidade dos rollups e a utilização eficaz dos recursos da cadeia de retransmissão, sem afetar as características chave 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 default que o ordenante 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 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 solicitações de transição de estado do rollup.

Polkadot: Uma solução intransigente

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 declarar claramente em qual núcleo do Polkadot a validação deve ser executada.

Este design oferece uma dupla garantia de elasticidade 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 que os dados sejam escritos na camada de disponibilidade de dados do Polkadot em qualquer bloco rollup, um grupo composto por cerca de 5 validadores irá primeiro verificar a sua legitimidade. Eles recebem os recibos candidatos e as provas de validade submetidas pelo ordenadora, 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 é usado para especificar em qual core o bloco deve ser validado. O validador comparará se esse índice coincide com o core sob sua responsabilidade; se não coincidir, o bloco será descartado.

Este mecanismo garante que o sistema mantenha sempre as propriedades de não confiança e de não permissão, evitando que agentes maliciosos como ordenadores manipulem a posição de verificação, assegurando que mesmo que o rollup utilize múltiplos núcleos, ele possa manter a resiliência.

segurança

No processo de busca por escalabilidade, o Polkadot não comprometeu a segurança. A segurança do rollup é garantida pela cadeia de retransmissão, bastando 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 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 limitará a programabilidade dos rollups. 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

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, a fim de 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 um número fixo de core, ou ajuste manualmente fora da cadeia;

• Estratégia leve: Monitorar cargas de transação específicas no mempool do nó;

• Estratégia de automação: configurar recursos antecipadamente através de dados históricos e da interface XCM para chamar 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 do bloco de comunicação de cada rollup é fixo, independentemente do número de núcleos atribuídos a ele.

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 melhorará a capacidade de comunicação entre rollups, aumentando a escalabilidade do sistema de forma elástica e reforçando ainda mais a capacidade de escalabilidade vertical do sistema.

Que trade-offs foram feitos por outros protocolos?

Como é bem sabido, o aumento de desempenho muitas vezes vem à custa da descentralização e da segurança. No entanto, 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 não adota 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), processamento paralelo de CPU e um mecanismo de consenso baseado em líderes, com TPS teórica 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 alocados de acordo com a quantidade de staking;

• Quanto mais você apostar, mais você receberá. Por exemplo, um validador que aposta 1% terá cerca de 1% de chance de produzir blocos;

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

PoH e o processamento paralelo têm exigências de hardware extremamente altas, levando à centralização dos nós de validação. Quanto mais um nó é apostado, maior a chance de gerar blocos, enquanto nós menores quase não têm slots, o que agrava 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 resistência a ataques em busca de TPS, com um coeficiente de Nakamoto de apenas 20, muito abaixo dos 172 da Polkadot.

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. Por outro lado, a 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, pode ser mal utilizado. Devido à falta de um mecanismo de "falência do apostador", os atacantes podem esperar que um determinado fragmento esteja completamente sob seu controle ou usar ataques DDoS para bloquear validadores honestos, 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 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 + subnetwork para escalabilidade, 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 subredes).

Cada sub-rede pode alcançar uma TPS teórica de ~5.000, semelhante à abordagem 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 estabelecer requisitos adicionais, como geográficos e KYC, sacrificando a descentralização e a segurança.

No Polkadot, todos os rollups partilham uma segurança unificada; enquanto as subredes da Avalanche não têm garantias de segurança por padrão, algumas podem até ser totalmente centralizadas. Para aumentar a segurança, ainda é necessário fazer compromissos no 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 de rollup, em vez de resolver os problemas diretamente na camada base. Essencialmente, essa abordagem não resolve o problema, mas sim transfere-o para a camada superior da pilha.

Rollup Optimista

Atualmente, a maioria das Optimistic rollups são centralizadas, 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 dura vários 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 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 da rede e aumento do gas em 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 da Polkadot.

Além disso, o problema de disponibilidade de dados do ZK rollup também agravará 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 dos 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 pelo 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, 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 de confiança zero" defendida pelo Polkadot pode ser a verdadeira solução que sustentará o desenvolvimento a longo prazo da Web3.