> ## 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. # Resumen > Entendiendo la arquitectura modular de nodos de Plasma y los roles de los operadores ## TL;DR Plasma separa los **nodos validadores** (que proponen y finalizan bloques) de los **nodos no validadores** (que sirven RPCs y siguen la cadena sin afectar el consenso). Esto le permite a Plasma mantener un conjunto de validadores pequeño y seguro, permitir que los proveedores RPC escalen independientemente y evitar agregar riesgo de consenso o de red. ## Arquitectura de alto nivel | **Capa** | **Rol** | **Modelo de confianza** | | :--------------------- | :------------------------------------------------------- | :--------------------------------------- | | Capa de consenso (CL) | Proponer y finalizar bloques | PlasmaBFT | | Capa de ejecución (EL) | Procesar transacciones, gestionar el estado, servir RPCs | Confía completamente en su CL emparejada | Cada validador ejecuta un nodo de consenso y un nodo de ejecución, conectados directamente. Excepto por sus pares, los nodos no se comunican fuera de los peers de su capa (CL-a-CL, EL-a-EL). Esta separación mantiene el sistema predecible, seguro y fácil de razonar. ### El desafío del escalado A medida que el uso aumenta, más aplicaciones y usuarios necesitan acceso RPC para consultar datos de la cadena o enviar transacciones. Pero si cada nuevo nodo de ejecución *debe* emparejarse con un nuevo nodo de consenso, el escalado se vuelve ineficiente y arriesga inflar el conjunto de validadores. Dejar que los proveedores RPC ejecuten validadores adicionales solo para satisfacer la demanda de lectura no es práctico ni alineado con los objetivos de rendimiento de Plasma. ### La solución: nodos no validadores Los nodos no validadores se comportan como nodos de consenso pero no participan en el consenso. En su lugar, «siguen» a un validador confiable para obtener bloques finalizados y actualizaciones de fork-choice. Comportamientos clave: * Se **suscriben** al nodo de consenso de un validador para mantenerse sincronizados. * **Exponen** la misma vista de fork-choice que tendría un validador real. * **Solo leen**, por lo que no agregan carga ni introducen riesgos de seguridad. Para las aplicaciones, un nodo no validador se ve exactamente como un nodo completo: puede responder a solicitudes RPC y reflejar el estado actual, pero no puede proponer bloques ni votar. ### Beneficios de este diseño | **Objetivo** | **Cómo ayudan los nodos no validadores** | | :------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Mantener el conjunto de validadores reducido | Los nodos no validadores no votan; solo lo hacen los validadores. | | Escala horizontal ilimitada | Los proveedores RPC pueden lanzar cientos de nodos RPC de lectura/escritura, cada uno con su propio nodo no validador, sin necesidad de nuevos espacios de validador. | | Mantener la corrección del consenso | Cada nodo de ejecución sigue exactamente una CL. No hay riesgo de divergencia de estado. | | Reducir el riesgo | Los nodos no validadores son de solo lectura y no pueden afectar los mensajes de consenso. | | Simplificar el failover | Al seguir múltiples validadores, si uno se desconecta, pueden cambiar a uno nuevo automáticamente. | ### Comparación resumida | Característica | Validadores | Nodos no validadores | | :--------------------------- | :------------------------------------ | :-------------------------- | | Participación en el consenso | Completa (proponer, votar, finalizar) | Ninguna (solo reciben) | | Tipos de mensajes | Todos los mensajes de consenso | Solo mensajes de bloque | | Rol de red | Participante activo | Seguidor pasivo | | Requisitos de recursos | Más altos (consenso completo) | Más bajos (solo mensajería) | ## Descentralización progresiva Plasma sigue un [modelo de descentralización progresiva](https://a16zcrypto.com/posts/article/progressive-decentralization-crypto-product-management/). En lugar de abrir el conjunto de validadores desde el día uno, el enfoque inicial está en la estabilidad, el rendimiento y la usabilidad para desarrolladores. Este enfoque prioriza la confiabilidad de la red mientras los componentes centrales del protocolo aún están evolucionando. La descentralización sigue siendo un objetivo a largo plazo, pero se introducirá gradualmente. El conjunto de validadores se expandirá a través de tres etapas: Durante la testnet, todos los nodos de consenso son operados por el equipo de Plasma para permitir una rápida iteración y minimizar el riesgo operativo. Después del lanzamiento de la mainnet, un pequeño grupo de validadores externos se unirá, seleccionados por confiabilidad, disposición operativa y distribución geográfica. Con el tiempo, el acceso a validadores se abrirá al público, respaldado por salvaguardas a nivel de protocolo para la seguridad, vivacidad y alineación económica. Este despliegue por etapas equilibra la descentralización con la integridad de la red. Permite que el protocolo se endurezca antes de transferir las responsabilidades de infraestructura crítica a un conjunto más amplio de validadores. ## Descubrimiento de peers Los nodos de Plasma descubren y se conectan a los peers a través de dos mecanismos independientes — uno para cada capa del stack. ### Capa de ejecución (Reth) El cliente de ejecución usa el protocolo estándar de Ethereum [devp2p](https://github.com/ethereum/devp2p) para el descubrimiento de peers. Al inicio, tu nodo Reth se conecta a un conjunto de peers de ejecución confiables definidos en `enodes.txt`. Estos son [URLs enode](https://ethereum.org/en/developers/docs/networking-layer/#enode) que codifican la clave pública, dirección IP y puerto de cada peer. El `enodes.txt` de cada red está preconfigurado en el repositorio [non-validator-templates](https://github.com/PlasmaLaboratories/non-validator-templates). Después de conectarse al conjunto inicial, el protocolo de descubrimiento integrado de Reth (discv4/discv5) encuentra peers adicionales automáticamente. La capa P2P de ejecución opera en el puerto `30303` (TCP/UDP). ### Capa de consenso (PlasmaBFT) El cliente observador de consenso descubre peers a través de nodos bootstrap definidos en `non-validator.toml`. Cada entrada de nodo bootstrap incluye un host API, puerto P2P y un [peer ID de 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 red incluye 3 nodos bootstrap. Tu cliente observador se conecta a estos al inicio y, con el descubrimiento de peers habilitado (`discovery.enabled = true`), encuentra automáticamente peers adicionales en la red. La capa P2P de consenso opera en el puerto `34070` (TCP). ### Nodos detrás de NAT Si tu nodo está detrás de un gateway NAT o firewall, otros peers podrían no poder alcanzarlo usando su dirección interna. Puedes configurar una dirección externa para que los peers puedan descubrir y conectarse a tu nodo: ```toml non-validator.toml theme={null} [network] external_address = "node.example.com:34070" ``` ```bash CLI theme={null} --p2p.external-address node.example.com:34070 ``` Si se omite el puerto, se usa por defecto el valor de `p2p_port`. Asegúrate de que la dirección externa sea accesible y que los puertos relevantes estén reenviados a través de tu firewall. ### Resumen | Capa | Protocolo | Puerto | Método de descubrimiento | | :-------- | :-------- | :------ | :-------------------------------------------- | | Ejecución | devp2p | `30303` | Enodes confiables + descubrimiento automático | | Consenso | libp2p | `34070` | Nodos bootstrap desde `non-validator.toml` | Para detalles de puertos y firewall, consulta la guía de [Configuración de nodo no validador](./non-validator-node-setup#port-configuration). ## Inicio rápido Comprende los roles de validador, no validador y proveedor RPC Despliega tu nodo con Docker Compose Especificaciones mínimas y recomendadas para tu nodo Empieza con la operación de nodos sin permisos