---
title: "Red peer-to-peer"
description: "Una red peer-to-peer ofrece a cada nodo un conjunto limitado y cambiante de pares directos para descubrimiento, gossip e intercambios de solicitud-respuesta; no crea una vista global ni convierte la aceptación de mensajes en consenso."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Red peer-to-peer

> Solo con fines educativos; no constituye asesoramiento ni recomendación de inversión. Las inversiones pueden ocasionar pérdidas.

<a id="answer"></a>

## Respuesta directa

Una red peer-to-peer permite que cada nodo descubra y mantenga un conjunto limitado de pares directos, intercambie mensajes de protocolo autenticados y construya su propia vista local sin dirigirlo todo por un servidor central. No es un grafo completo, un mempool global ni una fuente de verdad por sí sola. Que un par reciba, valide o reenvíe un objeto no demuestra que todos los nodos lo hayan visto, que un bloque lo haya incluido ni que el consenso lo haya finalizado.

Ethereum después de The Merge utiliza dos redes P2P distintas. Los clientes de ejecución emplean descubrimiento, RLPx y la capacidad versionada `eth` para sincronización e intercambio de transacciones. Los clientes de consenso emplean discv5 para descubrimiento y gossip de libp2p más protocolos de solicitud-respuesta para bloques beacon, attestations y otros objetos de consenso. Ambos clientes se coordinan localmente mediante la Engine API autenticada; una wallet suele enviar mediante JSON-RPC y eso no la convierte en nodo gossip.

<a id="mechanism"></a>

## Cómo funciona

1. Fije cadena, red, génesis y configuración de forks, versiones de clientes de ejecución y consenso, identidades de nodo y momento de observación. Represente por separado cliente de ejecución, cliente de consenso, validator opcional, Engine API local y RPC para usuarios.
2. Compruebe cada vía de descubrimiento: bootnodes integrados, listas DNS, pares estáticos o de confianza, identidad ENR o enode, endpoint y secuencia anunciados, compatibilidad de red, NAT y accesibilidad entrante. Un ENR firmado vincula un registro a una clave; no demuestra honestidad, sincronización ni accesibilidad actual.
3. Registre por separado conexión y negociación de protocolo. Los pares de ejecución establecen sesiones RLPx y negocian capacidades como `eth`; los pares de consenso negocian transporte libp2p, seguridad e identificadores de protocolo tras el descubrimiento discv5. Encontrar un endpoint no implica compatibilidad de aplicación.
4. Siga cada objeto por su vía real. Una transacción puede pasar del envío RPC a la validación local y al mempool de ejecución, y después a anuncios y solicitudes `eth`. Los objetos de consenso usan validación gossip específica del topic, mientras los bloques ausentes pueden obtenerse por solicitud-respuesta.
5. Aplique decodificación acotada, deduplicación, límites de tasa y comprobaciones de firma, sintaxis y estado antes de admitir o reenviar localmente. Registre resultados inválidos, ignorados, no disponibles o limitados por recursos; la puntuación y desconexión de pares son decisiones locales de implementación, no reputación de consenso.
6. Mantenga recepción, validación, reenvío, inclusión de la transacción, resultado de ejecución, fork choice, justificación y finalidad como estados y relojes separados. Compare varios pares o nodos cuando un pool, head o historial local sea incompleto, conflictivo u obsoleto.
7. Supervise diversidad de pares entrantes y salientes, operador, concentración por prefijo IP y ASN, rotación, latencia, pérdida, ancho de banda, colas, tráfico inválido, reloj y dependencias RPC. Ensaye pérdida de bootnodes, fallo NAT, partición, eclipse, sobrecarga y recuperación sin afirmar resistencia absoluta.

Descubrimiento de pares, seguridad de transporte y validez de aplicación resuelven problemas distintos. Los bootnodes presentan candidatos, pero no retransmiten el tráfico ordinario ni eligen la cadena canónica. El cifrado protege contenido y autenticación de la sesión, pero los pares conocen endpoints y tiempos; un proveedor RPC remoto puede observar además consultas, direcciones y transacciones enviadas.

La propagación es concurrente y depende de la topología. Fanout, rutas duplicadas, serialización por ancho de banda, CPU de validación, colas, pérdidas, retransmisión, puntuación y reglas del objeto determinan distribución y cola de los tiempos de llegada. Una fórmula como `delay = hops * perHopTime` es solo un modelo didáctico serial declarado, no una garantía de red.

<a id="example"></a>

## Ejemplos

- **Ruta serial frente a pipeline.** En una ruta didáctica de `4 hops`, cada salto tiene `80 ms` de red y `20 ms` de validación. El proceso totalmente serial da `4 * (80 + 20) = 400 ms`. Si la validación se solapa con la siguiente transmisión, un límite inferior simplificado es `4 * 80 + 20 = 340 ms`. Ningún valor es el tiempo de propagación de toda la red.
- **Anuncio y obtención de transacciones.** Un nodo recibe `20` hashes y ya posee `6`, por lo que faltan `20 - 6 = 14` cuerpos. Si una solicitud didáctica admite como máximo `8`, necesita `ceil(14 / 8) = 2 batches`. Con `120 ms` de ida y vuelta más `30 ms` de validación por lote, el total serial es `2 * (120 + 30) = 300 ms`; el total paralelo ideal, `150 ms`. Los límites reales dependen de la versión `eth` negociada y del cliente.
- **Probabilidad simplificada de eclipse.** Si cada uno de `8` pares salientes se muestreara de forma independiente y los candidatos maliciosos fueran `25%`, la probabilidad de que todos fueran maliciosos sería `0.25^8 = 0.0000152587890625 = 0.00152587890625%`. Sesgo del descubrimiento, identidades Sybil, correlación IP/ASN y retención violan la independencia; no es una garantía de seguridad.
- **Sobrecarga de validación.** Entran `900 messages/s`; `4` workers validan `250 messages/s` cada uno, dando capacidad de `1,000 messages/s`, margen de `100 messages/s` y utilización de `90%`. Un ataque de `1,400 messages/s` acumula `400 messages/s` y `6,000 messages` en `15 seconds`. Una cola de `5,000-message` se llena en `5,000 / 400 = 12.5 seconds` antes de descartes o límites, ignorando variación del servicio.

<a id="risks"></a>

## Riesgos

- Cadena, génesis o configuración de fork equivocadas.
- Incompatibilidad entre cliente de ejecución, consenso o Engine API.
- Descubrimiento por bootnode o DNS concentrado o secuestrado.
- Metadatos de endpoint obsoletos, falsificados o inaccesibles.
- NAT, firewall o puertos bloquean la accesibilidad prevista.
- Ataque de eclipse que filtra la vista local del nodo.
- Identidades Sybil y concentración de IP, ASN, operador o nube.
- Dependencia excesiva de pares estáticos o de confianza.
- Censura de transacciones o retransmisión selectiva.
- Divergencia entre flujo de órdenes público y privado.
- Divergencia local de admisión, reemplazo y expulsión del mempool.
- Gossip inválido agota la CPU de validación.
- Solicitudes sobredimensionadas, descompresión o agotamiento de ancho de banda, memoria o disco.
- Manipulación de la puntuación de pares o penalizaciones falsas.
- Contrapresión de colas descarta mensajes sensibles al tiempo.
- Latencia, pérdida o desfase del reloj causan divergencia temporal del head.
- Incompatibilidad de versión de protocolo o fork digest.
- Historial podado o respuesta sin recursos se interpreta como inexistencia.
- Filtración de privacidad de IP, tiempos, consultas y origen de transacciones.
- RPC centralizado o expuesto permite seguimiento, vistas obsoletas, censura o compromiso.

<a id="misconceptions"></a>

## Errores comunes

- **Todos los nodos se conectan directamente entre sí.** Cada nodo tiene un conjunto local finito y cambiante; distintos nodos pueden ver temporalmente mensajes y heads diferentes.
- **Un bootnode es fuente fiable de bloques o participante del consenso.** Su función normal es presentar pares; validez de cadena y fork choice se verifican en otro lugar.
- **Una transacción aceptada por un par se difunde globalmente y tiene inclusión garantizada.** Admisión y retransmisión son locales, y builders o proposers pueden omitirla.
- **La validación gossip significa consenso y finalidad.** Es una barrera local temprana; fork choice, justificación y finalidad son máquinas de estado separadas.
- **Más pares o transporte cifrado proporcionan automáticamente anonimato y resistencia a eclipse.** Importan diversidad y selección; pares y proveedores RPC aún pueden correlacionar endpoints, tiempos y actividad.

<a id="related"></a>

## Temas relacionados

- [Nodo completo](/es/crypto/full-node/)
- [Mempool](/es/crypto/mempool/)
- [Resistencia a la censura](/es/crypto/censorship-resistance/)

<a id="sources"></a>

## Fuentes

- [Networking layer](https://ethereum.org/developers/docs/networking-layer) - Ethereum.org (consultado: 2026-08-13)
- [Ethereum Wire Protocol (ETH)](https://github.com/ethereum/devp2p/blob/master/caps/eth.md) - Ethereum devp2p (consultado: 2026-08-13)
- [The RLPx Transport Protocol](https://github.com/ethereum/devp2p/blob/master/rlpx.md) - Ethereum devp2p (consultado: 2026-08-13)
- [Node Discovery Protocol v5 - Wire Protocol](https://github.com/ethereum/devp2p/blob/master/discv5/discv5-wire.md) - Ethereum devp2p (consultado: 2026-08-13)
- [Phase 0 -- Networking](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/p2p-interface.md) - Ethereum Consensus Specs (consultado: 2026-08-13)
- [gossipsub v1.1: Security extensions to improve on attack resilience and bootstrapping](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md) - libp2p (consultado: 2026-08-13)
- [Connecting To The Network](https://geth.ethereum.org/docs/fundamentals/peer-to-peer) - go-ethereum (consultado: 2026-08-13)
- [Spin up your own Ethereum node](https://ethereum.org/developers/docs/nodes-and-clients/run-a-node/) - Ethereum.org (consultado: 2026-08-13)

Source: https://wiki.fcontext.com/es/crypto/peer-to-peer-network/index.mdx