Pular para o conteúdo principal

​
TL;DR

A Plasma separa os nós validadores (que propõem e finalizam blocos) dos nós não validadores (que atendem RPCs e seguem a chain sem afetar o consenso). Isso permite à Plasma manter o conjunto de validadores pequeno e seguro, permitir que provedores de RPC escalem independentemente e evitar adicionar risco de consenso ou rede.

​
Arquitetura de Alto Nível

CamadaFunçãoModelo de Confiança
Camada de Consenso (CL)Propor e finalizar blocosPlasmaBFT
Camada de Execução (EL)Processar transações, gerenciar estado, atender RPCsConfia totalmente no CL pareado
Cada validador executa um nó de consenso e um nó de execução, conectados diretamente. Exceto por seus pares, os nós não se comunicam fora dos peers de sua camada (CL-para-CL, EL-para-EL). Essa separação mantém o sistema previsível, seguro e fácil de raciocinar.

​
O Desafio de Escala

À medida que o uso aumenta, mais apps e usuários precisam de acesso RPC para consultar dados da chain ou enviar transações. Mas se cada novo nó de execução precisar ser pareado com um novo nó de consenso, escalar se torna ineficiente e arrisca inchar o conjunto de validadores. Permitir que provedores de RPC executem validadores adicionais apenas para atender à demanda de leitura não é prático nem alinhado com os objetivos de desempenho da Plasma.

​
A Solução: Nós Não Validadores

Os nós não validadores se comportam como nós de consenso, mas não participam do consenso. Em vez disso, eles ‘seguem’ um validador confiável para blocos finalizados e atualizações de fork-choice. Comportamentos-chave:
  • Eles se inscrevem no nó de consenso de um validador para se manterem sincronizados.
  • Eles expõem a mesma visão de fork-choice que um validador real teria.
  • Eles apenas leem, então não adicionam carga nem introduzem riscos de segurança.
Para as aplicações, um nó não validador parece exatamente um nó completo: pode responder a solicitações RPC e refletir o estado atual, mas não pode propor blocos nem votar.

​
Benefícios Desse Design

ObjetivoComo os Nós Não Validadores Ajudam
Manter o conjunto de validadores enxutoNós não validadores não votam; apenas validadores votam.
Escala horizontal ilimitadaProvedores de RPC podem provisionar centenas de nós RPC de leitura/escrita, cada um com seu próprio nó não validador, sem exigir novas vagas de validador.
Manter a correção do consensoCada nó de execução ainda segue exatamente um CL. Não há risco de divergência de estado.
Reduzir riscoNós não validadores são somente leitura e não podem afetar mensagens de consenso.
Simplificar failoverAo seguir vários validadores, se um ficar offline, eles podem mudar para um novo automaticamente.

​
Comparação Resumida

RecursoValidadoresNós Não Validadores
Participação no ConsensoTotal (propor, votar, finalizar)Nenhuma (apenas receber)
Tipos de MensagensTodas as mensagens de consensoApenas mensagens de bloco
Função na RedeParticipante ativoSeguidor passivo
Requisitos de RecursosMais altos (consenso completo)Mais baixos (apenas mensagens)

​
Descentralização Progressiva

A Plasma segue um modelo de descentralização progressiva. Em vez de abrir o conjunto de validadores desde o primeiro dia, o foco inicial é em estabilidade, desempenho e usabilidade para desenvolvedores. Essa abordagem prioriza a confiabilidade da rede enquanto os componentes principais do protocolo ainda estão evoluindo. A descentralização continua sendo um objetivo de longo prazo, mas será introduzida gradualmente. O conjunto de validadores se expandirá em três estágios:
1

Operação Centralizada

Durante a testnet, todos os nós de consenso são operados pela equipe da Plasma para permitir iteração rápida e minimizar o risco operacional.
2

Conjunto Confiável de Validadores

Após o lançamento da mainnet, um pequeno grupo de validadores externos ingressará, selecionado por confiabilidade, prontidão operacional e distribuição geográfica.
3

Participação Sem Permissão

Com o tempo, o acesso de validador será aberto ao público, apoiado por salvaguardas em nível de protocolo para segurança, liveness e alinhamento econômico.
Este lançamento por estágios equilibra descentralização com integridade da rede. Permite ao protocolo se fortalecer antes de entregar responsabilidades críticas de infraestrutura a um conjunto mais amplo de validadores.

​
Descoberta de Peers

Os nós Plasma descobrem e se conectam a peers por meio de dois mecanismos independentes — um para cada camada da stack.

​
Camada de Execução (Reth)

O cliente de execução usa o protocolo padrão devp2p do Ethereum para descoberta de peers. Na inicialização, seu nó Reth se conecta a um conjunto de peers de execução confiáveis definidos em enodes.txt. Estas são URLs enode que codificam a chave pública, o endereço IP e a porta de cada peer. O enodes.txt de cada rede está pré-configurado no repositório non-validator-templates. Após conectar-se ao conjunto inicial, o protocolo de descoberta integrado do Reth (discv4/discv5) encontra peers adicionais automaticamente. A camada P2P de execução opera na porta 30303 (TCP/UDP).

​
Camada de Consenso (PlasmaBFT)

O cliente observador de consenso descobre peers por meio de bootstrap nodes definidos em non-validator.toml. Cada entrada de bootstrap node inclui um host de API, porta P2P e um peer ID libp2p: 
[network.bootstrap_nodes.0]
api_host = "plasma-mainnet-observer-cs-1.plasmalabs.tech"
p2p_port = 34070
peer_id = "16Uiu2HAm4WdZmik6PVsRvcbCzc1eHuNfQHgj52CxUAjmdC7W5dXi"
Cada rede é entregue com 3 bootstrap nodes. Seu cliente observador se conecta a estes na inicialização e, com a descoberta de peers habilitada (discovery.enabled = true), encontra peers adicionais automaticamente na rede. A camada P2P de consenso opera na porta 34070 (TCP).

​
Nós Atrás de NAT

Se seu nó estiver atrás de um gateway NAT ou firewall, outros peers podem não conseguir alcançá-lo usando seu endereço interno. Você pode configurar um endereço externo para que os peers possam descobrir e se conectar ao seu nó: 
[network]
external_address = "node.example.com:34070"
Se a porta for omitida, o padrão é o valor de p2p_port. Certifique-se de que o endereço externo seja acessível e que as portas relevantes sejam encaminhadas através do seu firewall.

​
Resumo

CamadaProtocoloPortaMétodo de Descoberta
Execuçãodevp2p30303Enodes confiáveis + descoberta automática
Consensolibp2p34070Bootstrap nodes do non-validator.toml
Para detalhes de porta e firewall, consulte o guia Configuração de Nó Não Validador.

​
Início Rápido

Tipos de Nós

Entenda as funções de validador, não validador e provedor de RPC

Configuração de Nó Não Validador

Implante seu nó com Docker Compose

Requisitos de Hardware

Especificações mínimas e recomendadas para o seu nó

Onboarding de Operador

Comece com operação de nós sem permissão