Compromissos de escalabilidade: A escolha entre Polkadot e Web3

Na busca incessante por maior eficiência na blockchain, uma questão crucial vem à tona: como garantir segurança e resiliência do sistema ao mesmo tempo em que se melhora o desempenho de escalabilidade? Este é um desafio não apenas no 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 baseia na sacrificação da confiança e da segurança geralmente tem dificuldade em sustentar inovações verdadeiramente sustentáveis.

Como um importante impulsionador da escalabilidade do Web3, o Polkadot fez algumas concessões na busca por alta taxa de transferência e baixa latência? Seu modelo de rollup fez alguma concessão em descentralização, segurança ou interoperabilidade de rede? Este artigo irá analisar em profundidade as escolhas e trade-offs do Polkadot no design de escalabilidade, comparando-os com as soluções de outras blockchains principais, explorando suas diferentes escolhas de caminho 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 centralizada. Isso pode introduzir riscos de centralização de algumas maneiras? É 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 organizador que conecta a cadeia de retransmissão, 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 enviando solicitações de mudança de estado do rollup. Essas solicitações serão verificadas por algum núcleo da cadeia de retransmissão, desde que atendam a um pré-requisito: 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 multicore 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 de blocos do rollup não é fixada em um único core, isso pode afetar sua elasticidade.

Como o protocolo para submeter blocos à cadeia intermediária é 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, reduzindo assim a capacidade de processamento e eficiência geral do rollup.

O objetivo do Polkadot é manter a elasticidade do rollup e a utilização eficiente 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, adotando um mecanismo de lista branca, ou confiando por padrão que o 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 sequencer, pois devemos 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 solicitações de transição de estado do rollup.

Polkadot: uma solução que não compromete

A solução final escolhida pelo Polkadot é: deixar o problema completamente nas mãos 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 declarado de forma clara em qual núcleo do Polkadot a validação deve ser executada.

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

Antes de escrever os dados de disponibilidade do Polkadot em qualquer bloco rollup (DA), um grupo composto por cerca de 5 validadores irá primeiro 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, que será reexecutada pelos validadores na cadeia de retransmissão.

O resultado da validação inclui um selector core, utilizado para especificar em qual core o bloco deve ser validado. O validador 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 as características de sem confiança e sem permissão, evitando que agentes maliciosos, como ordenadores, manipulem a posição de validação, assegurando que, mesmo que o rollup utilize múltiplos núcleos, consiga manter a resiliência.

segurança

No processo de busca pela escalabilidade, a Polkadot não comprometeu a segurança. A segurança dos rollups é garantida pela cadeia de retransmissão, sendo necessário apenas um ordenante honesto para manter a vitalidade.

Através do protocolo ELVES, o Polkadot estende completamente a sua segurança a todos os rollups, validando todos os cálculos no core, sem a necessidade de quaisquer limitações ou pressupostos 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 2 segundos. Com a escalabilidade elástica, a quantidade total de cálculos executáveis a cada período 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 do RFC103, para se adaptar a diferentes cenários de uso.

A complexidade específica depende da estratégia de gerenciamento 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 off-chain;

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

• Estratégia automatizada: chama antecipadamente o serviço coretime configurando recursos através de dados históricos e da interface XCM.

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, e a escalabilidade elástica não afeta a capacidade de transferência 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, Polkadot também suportará a transmissão de mensagens fora da cadeia, com a cadeia relé atuando como a camada de controle, em vez da camada de dados. Esta atualização permitirá que a capacidade de comunicação entre rollups melhore junto com a escalabilidade elástica, aumentando ainda mais a capacidade de escalabilidade vertical do sistema.

Quais compromissos foram feitos por outros protocolos?

É amplamente conhecido que 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 utiliza a arquitetura de sharding do Polkadot ou Ethereum, mas sim uma arquitetura de camada única de alta taxa de transferência 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órico de até 65.000.

Um design chave é o seu mecanismo de agendamento de líderes que é pré-publicado e verificável:

• Cada epoch ( dura cerca de dois dias ou 432.000 slots ) e, no início, os slots são alocados com base na quantidade de staking;

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

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

PoH e o processamento paralelo exigem hardware extremamente elevado, levando à centralização dos nós de validação. Quanto mais um nó está em stake, maior a chance de produzir blocos, enquanto nós menores quase não têm slots, exacerbando ainda mais a centralização e aumentando o risco de paralisia 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. O Polkadot já 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 shard 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", um atacante pode esperar que um shard esteja completamente sob seu controle 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 com atraso, os atacantes não conseguem saber a identidade dos validadores com antecedência, o ataque precisa 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 escalar, com a mainnet composta por transferências X-Chain(, ~4,500 TPS), contratos inteligentes C-Chain(, ~100-200 TPS), e a P-Chain( que gerencia validadores e subnetwork).

A TPS teórica de cada sub-rede pode chegar a ~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 definir 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 sub-redes da Avalanche não têm garantias de segurança por padrão, algumas podem ser completamente centralizadas. Para aumentar a segurança, ainda é necessário comprometer o desempenho, tornando difícil oferecer 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 o problema na camada base. Essa abordagem, na essência, não resolve o problema, mas sim o transfere para a camada superior da pilha.

Optimistic Rollup

Atualmente, a maioria dos Optimistic rollups é centralizada, apresentando problemas de segurança insuficiente, isolamento entre si, alta latência e necessidade de esperar o 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 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 na rede e aumento do gas em momentos 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 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 para os usuários.

Conclusão

O fim da escalabilidade não deve ser um compromisso.

Em comparação com outras blockchains públicas, 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 protocolos sem permissão, uma camada de segurança unificada e mecanismos de gestão de recursos flexíveis.

Na busca por uma implementação em maior escala nos dias de hoje, a "escalabilidade de zero confiança" defendida pelo Polkadot pode ser a verdadeira solução que sustenta o desenvolvimento a longo prazo da Web3.