> ## Documentation Index > Fetch the complete documentation index at: https://docs.plasma.org/llms.txt > Use this file to discover all available pages before exploring further. # Visão Geral > Entendendo a arquitetura modular de nós da Plasma e as funções dos operadores ## 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 | **Camada** | **Função** | **Modelo de Confiança** | | :---------------------- | :--------------------------------------------------- | :------------------------------ | | Camada de Consenso (CL) | Propor e finalizar blocos | PlasmaBFT | | Camada de Execução (EL) | Processar transações, gerenciar estado, atender RPCs | Confia 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 | **Objetivo** | **Como os Nós Não Validadores Ajudam** | | :-------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------- | | Manter o conjunto de validadores enxuto | Nós não validadores não votam; apenas validadores votam. | | Escala horizontal ilimitada | Provedores 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 consenso | Cada nó de execução ainda segue exatamente um CL. Não há risco de divergência de estado. | | Reduzir risco | Nós não validadores são somente leitura e não podem afetar mensagens de consenso. | | Simplificar failover | Ao seguir vários validadores, se um ficar offline, eles podem mudar para um novo automaticamente. | ### Comparação Resumida | Recurso | Validadores | Nós Não Validadores | | :----------------------- | :------------------------------- | :----------------------------- | | Participação no Consenso | Total (propor, votar, finalizar) | Nenhuma (apenas receber) | | Tipos de Mensagens | Todas as mensagens de consenso | Apenas mensagens de bloco | | Função na Rede | Participante ativo | Seguidor passivo | | Requisitos de Recursos | Mais altos (consenso completo) | Mais baixos (apenas mensagens) | ## Descentralização Progressiva A Plasma segue um [modelo de descentralização progressiva](https://a16zcrypto.com/posts/article/progressive-decentralization-crypto-product-management/). 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: 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. 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. 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](https://github.com/ethereum/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](https://ethereum.org/en/developers/docs/networking-layer/#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](https://github.com/PlasmaLaboratories/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](https://docs.libp2p.io/concepts/fundamentals/peers/): ```toml theme={null} [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ó: ```toml non-validator.toml theme={null} [network] external_address = "node.example.com:34070" ``` ```bash CLI theme={null} --p2p.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 | Camada | Protocolo | Porta | Método de Descoberta | | :------- | :-------- | :------ | :---------------------------------------- | | Execução | devp2p | `30303` | Enodes confiáveis + descoberta automática | | Consenso | libp2p | `34070` | Bootstrap nodes do `non-validator.toml` | Para detalhes de porta e firewall, consulte o guia [Configuração de Nó Não Validador](./non-validator-node-setup#port-configuration). ## Início Rápido Entenda as funções de validador, não validador e provedor de RPC Implante seu nó com Docker Compose Especificações mínimas e recomendadas para o seu nó Comece com operação de nós sem permissão