- Tema
62k Popularidade
38k Popularidade
13k Popularidade
4k Popularidade
4k Popularidade
30k Popularidade
16k Popularidade
23k Popularidade
13k Popularidade
3k Popularidade
- Marcar
62k Popularidade
38k Popularidade
13k Popularidade
4k Popularidade
4k Popularidade
30k Popularidade
16k Popularidade
23k Popularidade
13k Popularidade
3k Popularidade
Caminho de inovação do Polkadot: como alcançar um equilíbrio entre escalabilidade, segurança e Descentralização
A escolha da escalabilidade do Blockchain: O caminho inovador do Polkadot
Na era da tecnologia Blockchain, onde se busca constantemente maior eficiência, uma questão chave começa a emergir: como melhorar o desempenho sem sacrificar a segurança e a resiliência do sistema? Este é não apenas um desafio a nível técnico, mas uma escolha profunda no design da arquitetura. Para o ecossistema Web3, um sistema mais rápido, se construído sobre a base da perda de confiança e segurança, muitas vezes não consegue sustentar inovações verdadeiramente sustentáveis.
Como um importante impulsionador da escalabilidade do Web3, a Polkadot fez algumas concessões ao perseguir o objetivo de alta taxa de transferência e baixa latência? O seu modelo de rollup fez concessões em termos de descentralização, segurança ou interoperabilidade da rede? Este artigo irá analisar em profundidade as concessões e trade-offs da Polkadot no design de escalabilidade e comparar com as soluções de outras blockchains principais, explorando suas diferentes escolhas de caminhos 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 da Relay Chain (, isso pode introduzir riscos de centralização de alguma forma? É possível que se forme um ponto único de falha ou controle, afetando assim suas características de descentralização?
A operação do Rollup depende do sequenciador ) que conecta a cadeia de retransmissão, cuja comunicação utiliza um mecanismo chamado protocolo collator. Este protocolo é completamente sem permissão e sem confiança, qualquer pessoa com conexão à rede pode usá-lo, conectando um pequeno número de nós da cadeia de retransmissão e submetendo solicitações de alteração de estado do rollup. Essas solicitações serão verificadas por um core da cadeia de retransmissão, desde que cumpram uma condição: devem ser alterações de estado válidas, caso contrário, o estado do rollup não será avançado.
( Compromisso de expansão vertical
Rollup pode alcançar a escalabilidade vertical ao utilizar a arquitetura multicore do Polkadot. Esta nova capacidade é introduzida pela funcionalidade de "Elastic Scaling")Elastic Scaling###. Durante o processo de design, foi descoberto que, uma vez que a validação de blocos rollup não é fixada em um core específico, isso pode afetar sua elasticidade.
Uma vez que o protocolo para submeter blocos à cadeia de retransmissã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 maliciosamente recursos e, assim, reduzindo a capacidade e eficiência geral do rollup.
O objetivo do Polkadot é manter a flexibilidade dos rollups e a utilização eficaz dos recursos da cadeia de retransmissão, sem afetar as características-chave do sistema.
( Problema de confiança do Sequencer
Uma solução simples é definir o protocolo como "com licença": por exemplo, adotar um mecanismo de lista branca, ou confiar por defeito que o ordenadores não agem de forma maliciosa, garantindo assim a atividade do rollup.
No entanto, na filosofia de design do Polkadot, não podemos fazer suposições de confiança sobre o sequenciador, 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 enviar pedidos de transformação de estado do rollup.
Polkadot: uma solução sem compromissos
A solução finalmente escolhida pelo Polkadot é: delegar completamente a questão à função de transiçã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. 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 qualquer bloco de rollup seja escrito na camada de disponibilidade de dados do Polkadot (DA), um grupo composto por cerca de 5 validadores irá primeiro verificar sua legitimidade. Eles recebem os recibos candidatos (candidate receipt) e a prova de validade (PoV), que contêm o bloco de rollup e a respectiva prova de armazenamento. Essas informações serão processadas pela função de verificação da cadeia paralela, e serão reexecutadas pelos validadores na cadeia de retransmissão.
O resultado da verificação contém um selector core, que é usado para especificar em qual core o bloco deve ser verificado. O validador irá comparar se esse í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 não permissão, evitando que atores maliciosos, como ordenadores, manipulem a posição de verificação, assegurando que mesmo que o rollup utilize vários cores, consiga manter a resiliência.
( 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 ordenante honesto para manter a sobrevivência.
Com o protocolo ELVES, o Polkadot estende a sua segurança completa a todos os rollups, validando todos os cálculos na core, sem a necessidade de impor qualquer limitação ou suposição sobre o número de núcleos utilizados.
Portanto, o rollup do Polkadot pode 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 um 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.
Rollup pode ajustar dinamicamente os recursos através da interface Agile Coretime, para manter um nível de segurança consistente. Eles também precisam cumprir parcialmente os 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
Polkadot suporta a interoperabilidade entre diferentes rollups, e a escalabilidade elástica não afetará 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 atribuídos.
No futuro, Polkadot também suportará ### mensagens off-chain ###, com a cadeia de retransmissão atuando como a camada de controle, em vez da camada de dados. Esta atualização permitirá que a capacidade de comunicação entre rollups seja melhorada juntamente com a escalabilidade elástica, reforçando ainda mais a capacidade de escalabilidade vertical do sistema.
Compromissos de outros protocolos
É amplamente conhecido 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, o seu desempenho não é satisfatório.
( Solana
A Solana não utiliza a arquitetura de sharding do Polkadot ou do Ethereum, mas sim uma arquitetura de camada única de alta capacidade para alcançar escalabilidade, dependendo da prova histórica )PoH###, processamento paralelo de CPU e um mecanismo de consenso baseado em líderes, com uma TPS teórica que pode chegar a 65.000.
Um design chave é o seu mecanismo de agendamento de líderes pré-publicado e verificável:
PoH e processamento paralelo exigem hardware extremamente elevado, levando à centralização dos nós de validação. Quanto mais um nó é apostado, maior a chance de criar blocos, enquanto nós menores quase não têm slot, agravando ainda mais a centralização e aumentando 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 a 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. Já o Polkadot 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 shard 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 de forma maliciosa. Devido à falta de um mecanismo de "falência do apostador", um atacante pode esperar que um shard seja completamente controlado por ele, ou bloquear validadores honestos através de um ataque DDoS, manipulando assim o estado.
Em comparação, os validadores do Polkadot são atribuídos de forma aleatória e revelados com atraso, os atacantes não podem saber antecipadamente a identidade dos validadores, o ataque deve apostar no controle total para ter sucesso, e 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 rede principal + sub-rede para escalabilidade, onde a rede principal é composta por transferências X-Chain###, ~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 um TPS de ~5.000, semelhante à ideia 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 ter requisitos adicionais de geolocalização, KYC, etc., 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. Para aumentar a segurança, ainda é necessário 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 os problemas diretamente na camada base. Esta abordagem, na essência, não resolve o problema, mas transfere-o para a camada superior da pilha.
)# Optimistic Rollup
Atualmente, a maioria das rollups otimistas são centralizadas ###, algumas têm até apenas um sequenciador ###, o que resulta em problemas como falta de segurança, isolamento mútuo e alta latência (, necessitando esperar pelo período de prova de fraude, que normalmente 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 "ganhador leva tudo" tende a 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 momentos 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, 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 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 seguiu o caminho de trocar descentralização por desempenho ou de trocar 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 por uma aplicação em maior escala hoje, o "escalonamento sem confiança" defendido pelo Polkadot pode ser a verdadeira solução que suporta o desenvolvimento a longo prazo do Web3.