Plasma Docs - Build on Plasma

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

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.

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.

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:

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

[network]
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.

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

​TL;DR

​Arquitectura de alto nivel

​El desafío del escalado

​La solución: nodos no validadores

​Beneficios de este diseño

​Comparación resumida

​Descentralización progresiva

​Descubrimiento de peers

​Capa de ejecución (Reth)

​Capa de consenso (PlasmaBFT)

​Nodos detrás de NAT

​Resumen

​Inicio rápido