Skip to main content

​
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

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

​
Comparación resumida

​
Descentralización progresiva

Plasma sigue un modelo de descentralización progresiva. 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:
1

Operación centralizada

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.
2

Conjunto de validadores de confianza

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.
3

Participación sin permisos

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 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 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. 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:
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:
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

Para detalles de puertos y firewall, consulta la guía de Configuración de nodo no validador.

​
Inicio rápido

Tipos de nodos

Comprende los roles de validador, no validador y proveedor RPC

Configuración de nodo no validador

Despliega tu nodo con Docker Compose

Requisitos de hardware

Especificaciones mínimas y recomendadas para tu nodo

Onboarding de operadores

Empieza con la operación de nodos sin permisos