- Tema
69k Popularidade
41k Popularidade
15k Popularidade
4k Popularidade
5k Popularidade
29k Popularidade
16k Popularidade
23k Popularidade
13k Popularidade
3k Popularidade
- Marcar
69k Popularidade
41k Popularidade
15k Popularidade
4k Popularidade
5k Popularidade
29k Popularidade
16k Popularidade
23k Popularidade
13k Popularidade
3k Popularidade
A escolha entre Polkadot e a escalabilidade do Web3: segurança e Descentralização intransigentes
Escolhas de escalabilidade: O equilíbrio entre Polkadot e Web3
Hoje, em um mundo onde a blockchain busca constantemente maior eficiência, uma questão chave começa a se destacar: como escalar o desempenho sem sacrificar a segurança e a resiliência do sistema? Este é não apenas um desafio técnico, mas uma escolha profunda na arquitetura do design. Para o ecossistema Web3, um sistema mais rápido que é construído às custas da confiança e da segurança frequentemente tem dificuldade em sustentar inovações verdadeiramente sustentáveis.
Como um importante impulsionador da escalabilidade do Web3, o Polkadot fez alguns sacrifícios em busca de alta capacidade de processamento e baixa latência? O seu modelo de rollup comprometeu a descentralização, a segurança ou a interoperabilidade da rede?
Este artigo irá abordar essas questões, analisando profundamente as concessões e trade-offs do Polkadot no design de escalabilidade, e comparando suas soluções com as de outras blockchains principais, explorando as diferentes escolhas de caminhos entre desempenho, segurança e descentralização.
Desafios enfrentados pelo 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 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 do ordenadores da cadeia intermediária conectados, 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 usá-lo, conectando-se a um pequeno número de nós da cadeia intermediária e submetendo pedidos de transformação de estado do rollup. Esses pedidos serão verificados por algum core da cadeia intermediária, desde que satisfaçam uma condição: devem ser transformações de estado válidas, caso contrário, o estado do rollup não será avançado.
trade-offs de escalabilidade vertical
Os Rollups podem alcançar a escalabilidade vertical ao aproveitar a arquitetura multi-core do Polkadot. Esta nova capacidade foi introduzida pela funcionalidade de "escalabilidade flexível". Durante o processo de design, foi descoberto que, uma vez que a validação dos blocos de rollup não está fixa em um único core, 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 validação. Um atacante pode tirar proveito disso, submetendo repetidamente blocos legítimos que já foram verificados a diferentes cores, consumindo recursos de forma maliciosa, reduzindo assim a throughput e 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 afetar as características fundamentais do sistema.
Problemas de confiança do Sequencer
Uma solução simples é definir o protocolo como "com licença": por exemplo, adotando um mecanismo de lista branca, ou confiando por defeito que o ordenado não terá 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 em relação ao sequenciador, pois é necessário manter as características de "sem confiança" e "sem permissão" do sistema. Qualquer pessoa deve ser capaz de usar o protocolo de colator para enviar solicitações de transformação de estado do rollup.
Polkadot: uma solução sem compromissos
A solução escolhida pelo Polkadot é: deixar a questão inteiramente 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 claramente 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 transformação de estado do rollup no processo de disponibilidade e garantirá a correção da distribuição central através do protocolo econômico criptográfico ELVES.
Antes de qualquer rollup bloco ser escrito na camada de disponibilidade de dados do Polkadot, um grupo composto por cerca de 5 validadores irá primeiro verificar sua legalidade. Eles recebem recibos candidatos e provas de validade submetidos pelo ordenadores, que contêm blocos rollup e as respectivas provas de armazenamento. Essas informações serão processadas pela função de verificação da rede paralela, sendo reexecutadas pelos validadores na cadeia de retransmissão.
O resultado da verificação inclui um seletor de core, usado para especificar em qual core o bloco deve ser verificado. O validador 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 as propriedades de não confiança e de não permissão, evitando que manipuladores maliciosos, como ordenadores, controlem a posição de validação, assegurando que mesmo com múltiplos núcleos, o rollup mantenha a resiliência.
segurança
Durante o processo de busca pela escalabilidade, o 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 sobrevivência.
Com o 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 impor quaisquer restriçõ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.
Generalidade
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 que podem ser executados a cada 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.
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 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:
Embora a automação seja mais eficiente, os custos de implementação e teste também aumentam significativamente.
Interoperabilidade
O Polkadot suporta a interoperabilidade entre diferentes rollups, e 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. O espaço de bloco de comunicação de cada rollup é fixo e não depende do número de núcleos alocados.
No futuro, o Polkadot também suportará a transmissão de mensagens fora da cadeia, com a cadeia de retransmissão atuando como uma camada de controle, em vez de uma camada de dados. Esta atualização permitirá que a capacidade de comunicação entre rollups seja aumentada juntamente com a escalabilidade elástica, melhorando ainda mais a capacidade de escalabilidade vertical do sistema.
Compromissos de Outros Protocolos
É do conhecimento geral que o aumento de 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 não utiliza a arquitetura de shard do Polkadot ou do Ethereum, mas sim uma arquitetura de camada única de alta capacidade de processamento para alcançar escalabilidade, dependendo da prova de história (PoH), 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 pré-publicado e verificável:
PoH e o processamento paralelo têm requisitos de hardware muito elevados, levando à centralização dos nós de validação. Quanto mais um nó é apostado, maior a chance de produzir blocos, enquanto os 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 em caso de ataque.
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 do Polkadot.
TON
A TON afirma que o TPS pode alcançar 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á a Polkadot atingiu 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 claramente 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 determinado fragmento esteja sob seu controle total 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 podem saber a identidade dos validadores antecipadamente, o ataque deve apostar todo o controle para ter sucesso; contanto que haja um validador honesto que inicie uma disputa, o ataque falhará e causará perdas ao atacante.
Avalanche
Avalanche utiliza uma arquitetura de mainnet + sub-rede para escalabilidade, onde a mainnet é composta pelo X-Chain( para transferências, ~4.500 TPS), contratos inteligentes C-Chain(, ~100-200 TPS), e P-Chain( que gerencia validadores e sub-redes).
Cada sub-rede pode teoricamente atingir ~5.000 TPS, 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 da sub-rede, e a sub-rede pode 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 uma garantia de segurança por padrão, algumas podem até ser totalmente centralizadas. Para 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 de rollup, em vez de resolver os problemas diretamente 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 das rollups otimistas é centralizada (, algumas têm até apenas um sequenciador ), o que resulta em problemas de segurança insuficiente, isolamento mútuo, alta latência ( e a necessidade de esperar pelo 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 demanda computacional para gerar provas de conhecimento zero é extremamente alta, e o mecanismo de "o vencedor leva tudo" tende a 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 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 verificar as transações, ainda é necessário fornecer dados de transação completos. Isso geralmente depende de soluções de disponibilidade de dados adicionais, 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 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 "escabilidade sem confiança" defendida pela Polkadot talvez seja a verdadeira solução que pode sustentar o desenvolvimento de longo prazo da Web3.