Inicio/Whitepaper Técnico
Versión 1.0 · Octubre 2026 · Especificación Formal de Protocolo

Whitepaper Técnico de SilentPipe

Protocolo descentralizado de ancho de banda residencial (DePIN) con aislamiento de red, atestación criptográfica de tráfico mediante Proof-of-Bandwidth (PoB) y liquidación verificable.

1. Resumen Ejecutivo

La economía digital y el entrenamiento de modelos de inteligencia artificial dependen de la recolección continua de datos públicos y auditoría web en tiempo real. Sin embargo, el mercado de proxies residenciales ha estado históricamente dominado por intermediarios centralizados opacos, software malicioso empaquetado (PUA) y falta de consentimiento de los usuarios domésticos.

SilentPipe introduce una arquitectura de infraestructura física descentralizada (DePIN) basada en consentimiento explícito del operador, aislamiento estricto mediante sandboxing y atestación criptográfica verificable de tráfico transferido, sustituyendo la confianza ciega por pruebas matemáticas irrefutables.

2. Arquitectura de Doble Plano (Dual-Plane)

Para lograr latencias de conexión sub-milisegundo sin comprometer la seguridad ni saturar bases de datos, el protocolo desacopla la señalización y el inventario del flujo de datos masivo:

Plano de Control (Edge Control Plane)

Implementado en Cloudflare Workers y Durable Objects (NodeRegistryDO, NodeSessionDO). Mantiene en memoria RAM viva el inventario de nodos conectados, latencias TCP, scoring de salud y ruteo geoespacial, eliminando escrituras síncronas costosas.

Plano de Datos (Data Gateways)

Gateways de retransmisión de alta capacidad que terminan sesiones CONNECT y SOCKS5, aplican filtros de egress SSRF, evalúan allowlists de dominios por comprador y multiplexan túneles WebSockets cifrados hacia los nodos.

[Comprador B2B] ---> (HTTP CONNECT / SOCKS5) ---> [Gateway Edge] | +--------------------------+--------------------------+ | Filtro SSRF / Allowlist | Atestación de Metering | +--------------------------+--------------------------+ | (Túnel WebSocket Sandboxed) v [Nodo Residencial Operador] | (Petición Egress TLS 1.3) v [Web Pública Destino]

3. Especificación Criptográfica de Metering

Cada sesión de transferencia genera un comprobante criptográfico inmutable denominado BandwidthReceipt emitido por el Gateway al verificar un desafío (Challenge-Response) con nonce aleatorio.

Estructura Canónica del Recibo:
interface BandwidthReceipt {
  receiptId: string;       // SHA-256(nodeId + requestId + ts + nonce)
  epoch: number;           // Época de liquidación (ej. Season 1 = 1)
  nodeId: string;          // Identificador anónimo de nodo
  bytesTransferred: number;// Bytes brutos de payload atestiguados
  overheadBytes: number;   // Estimación determinística TLS/TCP
  timestampMs: number;     // Marca temporal UTC Unix ms
  gatewaySignature: string;// HMAC-SHA256(canonicalPayload, GATEWAY_SECRET)
}
Ecuación de Hash de la Hoja (Leaf Hash):
$$\text{Leaf} = \text{SHA-256}(\text{"receipt:"} \parallel \text{epoch} \parallel \text{receiptId} \parallel \text{buyerId} \parallel \text{nodeId} \parallel \text{bytes} \parallel \text{ts} \parallel \text{salt})$$
Umbral de Conciliación de Bytes (Anti-Inflation):

Si el nodo declara en sus heartbeats una transferencia que supere en más de un 15% lo medido de forma independiente por el gateway (reconciliation.ts), el delta excedente se anula automáticamente y se emite una alerta de auditoría forense.

4. Invariantes del Ledger y Árbol de Merkle Ordenado

El estado de créditos y puntos se asienta en un registro de solo anexado (append-only) basado en contabilidad de doble entrada. Para cada crédito concedido a un nodo residencial, existe un débito financiero correspondiente en la cuenta del comprador B2B o en el pool de incentivos de génesis:

$$\sum \text{Créditos a Operadores} + \sum \text{Comisiones de Protocolo} = \sum \text{Consumo de Compradores B2B}$$

Árbol de Merkle con Pares Ordenados (Sorted-Pair Binary Tree)

Al concluir cada época, los recibos válidos se consolidan en un árbol de Merkle determinístico. Para evitar ataques de maleabilidad y permitir verificación en tiempo constante sin importar el orden de los elementos, los nodos hermanos se ordenan lexicográficamente antes de aplicar la función de hash:

$$\text{Parent}(A, B) = \text{SHA-256}(\text{"pair:"} \parallel \min(A, B) \parallel \max(A, B))$$

Esto garantiza compatibilidad nativa con contratos inteligentes de distribución en Ethereum (EVM), Solana y pruebas ZK fuera de cadena.

5. Economía de Tokens y Proof of Backhaul (PoB)

La retribución a los operadores premia la calidad y la naturaleza genuina del acceso a internet:

Tipo de ConexiónMultiplicadorRequisito de CalidadAcción Anti-Fraude
Residencial Fijo (ISP)1.35×ASN Residencial + Uptime ≥ 98%Permitido
Móvil 4G / 5G2.00×Rotación CGNAT / Red CelularPermitido (Alta demanda)
Datacenter / Servidor Cloud0.00×ASN de Alojamiento (AWS, Hetzner, etc.)Bloqueo Inmediato (Slash)

Distribución de Tarifas y Modelo Deflacionario

Por cada gigabyte comercializado en la red comercial B2B ($2,50 USD base):

  • 70% ($1,75 USD): Se acredita directamente al pool de liquidación para operadores de nodos residenciales.
  • 20% ($0,50 USD): Destinado al mecanismo de recompra y quema permanente del token de red.
  • 10% ($0,25 USD): Fondo de reserva de protocolo y mantenimiento de infraestructura de gateways.

6. Modelo de Amenazas y Restricciones de Seguridad

Defensa Anti-SSRF (Server-Side Request Forgery)

Los túneles de salida rechazan de forma determinística peticiones dirigidas a rangos IPv4/IPv6 privados (RFC 1918, RFC 3927 link-local, loopback 127.0.0.0/8) y endpoints de configuración cloud (169.254.169.254).

Prevención de Abuso y Allowlist B2B

El tráfico comercial de compradores institucionales solo tiene permiso de alcanzar dominios pre-autorizados en su perfil de compliance (SERP, portales de comercio electrónico autorizados, índices públicos).

Lo que el Protocolo NO Garantiza

SilentPipe no es una red para actividades ilícitas ni un mixer de anonimato tipo Tor. Las identidades comerciales de los compradores están verificadas (KYB) y cada petición deja huella criptográfica auditable.

7. Matriz de Trazabilidad Código y Tests

En cumplimiento del estándar de rigor de SilentPipe, cada afirmación técnica del documento está enlazada al archivo de implementación y a su suite de pruebas automatizadas:

Módulo / AfirmaciónArchivo FuenteTest de CoberturaEstado
Metering HMAC-SHA256workers/proxy/src/metering.tstest/metering_pipeline.test.tsImplementado
Árbol de Merkle Ordenadoworkers/proxy/src/merkle.tstest/merkle_contract.test.tsImplementado
Filtro SSRF Egressworkers/proxy/src/egress-filter.tstest/ssrf.test.tsImplementado
Durable Objects Registryworkers/proxy/src/objects/NodeRegistryDO.tstest/durable_objects.test.tsImplementado
Allowlist Compradoresworkers/proxy/src/allowlist.tstest/buyer_gateway.test.tsImplementado
Conciliación de Bytesworkers/proxy/src/reconciliation.tstest/reconciliation.test.tsImplementado
Public Explorer APIworkers/api/src/routes/public/explorer.tstests/explorer/contract.test.tsImplementado