Algoritmos abiertos, datos abiertos.
Competencia de algoritmos de latencia simulada
Optimiza el protocolo UR. Las propuestas se evalúan frente a una rama del código y la ganadora se convierte en la nueva línea base y gana SN1α. Seis rondas de una semana cada una, próximamente. ¡Vamos!
El protocolo es un sistema nativo descentralizado, multi-IP y multi-transporte diseñado para escalar a millones de mineros por operador de red. Cada área algorítmica a continuación se publica con su código fuente y, cuando corresponde, conjuntos de datos anonimizados para análisis independiente.
URTRANSPORT1Rendimiento
Enrutamiento multi-salto a través de transportes TCP enfocado en la accesibilidad global. Se admiten actualizaciones a UDP y a flujos punto a punto, con integración planificada de WebRTC, XRay y WireGuard.
Enfoque actual
El transporte está construido primero para la accesibilidad, de modo que cualquier persona del mundo pueda conectarse. El enrutamiento multi-salto corre sobre transportes TCP a través de un salto central. Los transportes UDP como H3 y DNS están implementados pero desactivados: en uso real rindieron por debajo de la ruta TCP en esta configuración. Un salto multi-minero con actualización a flujo punto a punto también está implementado y desactivado por ahora. La selección de transporte y la ruta de actualización de flujos viven en transport.go y transfer_stream_manager.go.
Implementación
Líneas de investigación
Integrar protocolos establecidos como WebRTC, XRay y WireGuard como actualizaciones de flujo en el salto multi-minero, y reactivar los transportes UDP donde las mediciones muestren que ayudan. El algoritmo de emparejamiento también podría empezar a distinguir los saltos con IP y puerto públicos de los que no los tienen, para equilibrar velocidad y calidad de conexión. Cada uno de estos cambios puede probarse en un operador de red experimental antes de convertirse en el predeterminado.
UREXTENDER1Accesibilidad
Encriptación TLS de N capas (N≥2) donde cada capa exterior usa un certificado autofirmado con suplantación de SNI hacia una IP intermediaria, reenviando a otro salto o a una conexión TLS de extremo a extremo. Cualquiera puede alojar un extensor en cualquier dominio.
Enfoque actual
La pila de red central admite encriptación TLS de N capas, con N de al menos dos. Cada capa exterior puede usar un certificado autofirmado para un nombre de host elegido y alcanzar una IP intermediaria, que reenvía el tráfico a otro salto o a una conexión TLS de extremo a extremo con el dominio del operador de red, de modo que la conexión parece tráfico ordinario hacia ese nombre de host. Cualquiera puede alojar un extensor en un dominio que controle. Los usuarios de un extensor comparten un límite de tasa común, ajustable caso por caso.
Implementación
Líneas de investigación
Los extensores pueden añadirse a una lista de subvenciones del protocolo que reparte una parte de los incentivos entre los extensores participantes; los detalles de incorporación se publicarán cuando la lista abra. Cada minero ya asume el rol de extensor junto al de salida. Las preguntas abiertas son cómo medir el alcance de un extensor donde más importa sin exponer a sus usuarios, y cómo deberían rotar las capas exteriores los nombres de host y los certificados a medida que el bloqueo se adapta.
UR-FP2Emparejamiento cliente-minero
Algoritmo de muestreo que carga una muestra aleatoria 10× de mineros potenciales y los mezcla proporcionalmente a fiabilidad × puntuación del cliente. La resistencia Sybil se garantiza por la restricción de que la fiabilidad suma como máximo 1 por subred IP.
Enfoque actual
El sistema de emparejamiento carga desde memoria una muestra aleatoria de mineros candidatos, unas diez veces el número que necesita, y la mezcla en proporción a fiabilidad × puntuación del cliente para producir los finalistas. Su protección contra el aliasing de mineros (ataques Sybil) es un tope por subred IP: las puntuaciones de fiabilidad de todos los mineros de una subred suman como máximo 1, así que dividir una conexión en muchas identidades no aumenta su cuota de emparejamientos. El punto de entrada es FindProviders2.
Implementación
Líneas de investigación
Distinguir al emparejar los saltos con IP y puerto públicos de los que no los tienen, para equilibrar explícitamente velocidad y calidad de conexión en lugar de solo a través de la fiabilidad. Los pesos de fiabilidad y de puntuación del cliente y el tamaño de la muestra son las entradas naturales que un operador experimental puede variar frente a las exportaciones de bloque anonimizadas descritas abajo, manteniendo fijo el tope por subred como cota Sybil.
UR-MULTIMulti cliente
Algoritmo heurístico de barrido que gestiona una ventana de mineros. Fija el tráfico en el mejor nivel disponible basándose en umbrales de transferencia en lugar de análisis de protocolo.
Enfoque actual
Un barrido heurístico gestiona una ventana de mineros y fija el tráfico en los mineros del nivel más alto disponible. Las decisiones se toman sobre umbrales de transferencia, cuánto ha movido realmente un minero, y no inspeccionando el protocolo dentro del túnel, así que el enrutador nunca necesita mirar el tráfico de aplicación. La ventana es lo que permite a un cliente mantener varios mineros en juego a la vez y mover el tráfico entre ellos a medida que cambia su transferencia medida.
Implementación
Líneas de investigación
Los umbrales y los límites de nivel hoy se fijan a mano. Preguntas abiertas para un operador experimental: si deberían derivarse de distribuciones de transferencia medidas, y si la ventana debería incorporar también las estadísticas de disponibilidad y latencia por minero que ahora producen los validadores (ver Verificación de enrutamiento), para que un cliente evite un eslabón débil antes de pagarlo con su propio tráfico.
UR-TRANSFERTransferencia
Ventana de entrega fiable ajustada para entornos de alta latencia. Las retransmisiones del protocolo están desactivadas ya que la ventana proporciona entrega fiable. Distribuye el tráfico entre transportes según el rendimiento clasificado.
Enfoque actual
Una ventana de transferencia fiable está ajustada para entornos de alta latencia. Como la propia ventana proporciona entrega fiable, las retransmisiones del protocolo hacia la capa de transferencia están desactivadas: un flujo TCP que viaja por el túnel no se retransmite encima. El tráfico se distribuye entre los transportes disponibles según su rendimiento clasificado y su disponibilidad, de modo que un transporte lento o fallido pierde cuota en lugar de detener el flujo.
Implementación
Líneas de investigación
Preguntas abiertas: cómo debería dimensionarse la ventana a lo largo del abanico de latencias reales en lugar de para un único perfil fijo, cómo reclasificar los transportes cuando su rendimiento cambia a mitad del flujo, y cómo debería cooperar la capa de transferencia con las actualizaciones de flujo planificadas para el transporte (ver Rendimiento) cuando un salto es punto a punto y el siguiente no.
UR-IPSalida IP
Implementación de pila IP con consumo mínimo de memoria. Asume comunicación fiable entre pares a través de la capa de transferencia, por lo que las retransmisiones se optimizan en consecuencia.
Enfoque actual
La pila IP está diseñada para funcionar con memoria mínima, de modo que un minero pueda servir como salida en un teléfono o en un dispositivo pequeño. Asume comunicación fiable con el par a través de la capa de transferencia, lo que permite optimizar y eliminar su propio manejo de retransmisiones en lugar de duplicarlo. La capa de seguridad (ver Seguridad) está en la misma ruta, así que cada paquete se comprueba antes de salir del minero.
Implementación
Líneas de investigación
Preguntas abiertas: cuánto más puede reducirse la huella de memoria en los dispositivos más pequeños, y cómo conserva sus garantías la pila de salida cuando se relajan las suposiciones de fiabilidad de la capa de transferencia para las actualizaciones de flujo punto a punto planificadas para el transporte. Como con el transporte, los cambios se prueban en un operador experimental antes de convertirse en predeterminados.
UR-PSUB2Asignación de recompensas
Los validadores independientes puntúan cada pool de operador según la demanda y la calidad medida; el Yuma Consensus de Bittensor convierte esas puntuaciones en emisión. Dentro de un pool, un operador clasifica a sus mineros según los contratos servidos y la fiabilidad, registra una raíz de pagos Merkle en cada ciclo, y cada minero reclama su parte directamente del contrato de liquidación.
Enfoque actual
Las recompensas son la emisión de la subred UR en SN25. Los mineros de cada operador forman un pool con un UID de minero. En cada tempo, los validadores independientes puntúan cada pool según uso implícito × calidad medida (el depósito de época del operador dividido por la tasa publicada de su nivel de convicción, multiplicado por la calidad de los mineros del pool según los recorridos propios del validador) bajo commit-reveal, y el Yuma Consensus convierte la mediana en emisión. Dentro del pool, el operador clasifica a los mineros por contratos servidos × fiabilidad, registra una raíz de pagos Merkle en cada época, y cada minero reclama su parte directamente del contrato de liquidación. Las principales flotas por amplitud de IPs enrutables tienen sus propios UIDs y reciben pago nativo. Mientras el precio publicado sea 0, no se recogen depósitos y cada pool lleva la misma demanda implícita, así que solo la calidad medida dirige el canal de pools.
Implementación
Líneas de investigación
θ es un parámetro de gobernanza publicado: empezar cargado hacia la cola (θ ≈ 0,3), instrumentar el pago realizado por nivel y ampliarlo a medida que maduren el conjunto de mineros de nivel superior y el consenso de calidad de los validadores independientes, con la restricción de que el minero de nivel superior peor pagado siga ganando al menos lo que el minero de pool mejor pagado. La oscilación que la calidad ejerce sobre el peso del pool está acotada en el arranque y se amplía gradualmente. Una prima de esfuerzo para validadores está diseñada pero aparcada, para construirse solo si la red en vivo muestra que la cobertura independiente la necesita. Descentralizar el conjunto de validadores más allá de la mayoría del propietario es un paso de gobernanza posterior y deliberado.
UR-CONTRACTPermiso
La transferencia entre partes requiere un contrato encriptado con saldo en custodia y un conjunto de permisos. Ambas partes deben cerrar con recuentos de bytes confirmados; los desacuerdos activan un proceso de resolución forzada.
Enfoque actual
La transferencia entre un iniciador y un acompañante requiere un contrato encriptado con la clave secreta del cliente de destino. El contrato mantiene un saldo de transferencia fijo en custodia y define los permisos entre ambas partes. El acompañante puede crear contratos emparejados para el tráfico de retorno, y las rutas multi-salto envían eventos de apertura y cierre de flujo a los intermediarios. Tras el uso, ambas partes cierran el contrato con un recuento de bytes confirmado. Si alguna parte no cierra, o los totales no coinciden, la resolución del contrato determina el resultado; si alguna parte denuncia abuso, se bloquea la transferencia futura entre esas partes.
Implementación
Líneas de investigación
Contratos servidos × fiabilidad es también la base predeterminada del operador para su lista de pagos del pool, así que la exactitud de los recuentos de bytes cerrados alimenta las recompensas. Preguntas abiertas: cómo resolver un desacuerdo entre dos recuentos de cierre sin un tercer total de confianza, cómo dimensionar los contratos de retorno emparejados para tráfico asimétrico, y cómo ponderar una denuncia de abuso cuando los recuentos de ambas partes ya han discrepado antes.
UR-SEC1Seguridad
Lista de bloqueo de puertos y lista de bloqueo de IP que protegen la red de mineros. No realiza inspección de protocolo: los mineros solo enrutan tráfico cifrado.
Enfoque actual
La capa de seguridad usa listas de bloqueo de puertos y de IP. No inspecciona protocolos de aplicación: los mineros solo enrutan tráfico cifrado, así que no hay nada que inspeccionar, y las listas de bloqueo son lo que permite a un minero rechazar el tráfico que entra en conflicto con directrices regulatorias comunes como CFAA y DMCA y descartar destinos maliciosos conocidos. Las listas se aplican en el minero, de modo que el tráfico de un usuario encuentra las mismas reglas en cada salida.
Implementación
Líneas de investigación
Preguntas abiertas: cómo distribuir y actualizar las listas de bloqueo en una flota sin un punto central que pueda ver el tráfico, si la capa de seguridad debería aprender la reputación por destino a partir de datos de salida anonimizados en lugar de listas estáticas, y qué debería poder añadir un minero a sus propias listas sin dividir el comportamiento de la red entre salidas.
UR-VERIFY1Verificación de enrutamiento
Los validadores recorren cadenas de mineros asignadas por el servidor, probando la salida en vivo desde cada salto con cuatro firmas Ed25519. Las estadísticas de completado y latencia por paso encuentran el eslabón más débil y se convierten en la señal de calidad que dirige la emisión de los pools.
Enfoque actual
Un validador siembra un recorrido a través de un minero de su elección y llama a /verify; el servidor deriva el salto de la IP de origen de la petición, nunca de una afirmación. Cada salto siguiente se extrae uniformemente al azar, sin reemplazo, y se revela solo cuando el salto actual se confirma, así que una ruta no puede precalcularse. Cuatro firmas Ed25519 atan el recorrido: SEED y EXTEND del validador, ASSIGN y FINAL del servidor, que además sella el tiempo de cada salto. Un fallo se atribuye al único salto que nunca se alcanzó, la latencia se registra por paso al confirmarse, el salto semilla elegido por el validador se excluye, y cada minero se reporta con un intervalo de Wilson para el completado y percentiles de latencia una vez que tiene exposición suficiente.
Implementación
Líneas de investigación
Un recorrido completado prueba tránsito secuencial en vivo hacia un destino conocido, no el reenvío honesto del tráfico de usuario, y el autobeneficio por salto solo está acotado estadísticamente, por una población de validadores independientes. La hoja de ruta hacia una medición apta para pagos: prueba de enrutamiento mediante atestación de vecinos, diversidad de destinos para que un minero no pueda optimizar la única ruta medida, resistencia Sybil de los validadores mediante stake, y un modelo de riesgo jerárquico para la atribución. Hasta entonces, las estadísticas son monitorización de disponibilidad y latencia y puntuación provisional.
Anonimización
El bloque de pagos de la red es de 7 días, y las exportaciones de las entradas y salidas de cada algoritmo se anonimizan por bloque. Cada id de cliente y cada hash de subred IP se sustituye por un simple contador entero, de modo que una identidad es consistente dentro de un bloque pero no lleva nada entre bloques ni de vuelta a un id de producción. No se incluyen metadatos de ciudad. Las exportaciones por bloque están preparadas para su publicación pero aún no publicadas; esta página las enlazará cuando lo estén.
Para investigadores y desarrolladores
UR quiere que los usuarios puedan optar por algoritmos experimentales a través de operadores de red federados. Un nuevo operador se une al mismo sistema de incentivos que hoy paga a los mineros, y un minero puede servir a tantos operadores como quiera. La app ofrecerá a cada usuario la opción de introducir un dominio de operador alternativo. Los detalles de acceso a los operadores experimentales se publicarán cuando el programa abra, y esta página sigue el algoritmo predeterminado actual y las líneas experimentales. Para la investigación de seguridad, sigue la Política de divulgación de vulnerabilidades.
Auditorías
Auditorías de pares del protocolo y sus implementaciones.
- ProgramadaAuditoría de cifrado 2026Cure53Programada para noviembre – diciembre de 2026Alcance: diseño del cifrado y corrección de la implementación.Los resultados serán publicados por UR y Cure53.
- Auditoría de paresMASA L2 2025Leviathan Security GroupCompletada en mayo de 2025