Offene Algorithmen, offene Daten.
Sim-Latenz-Algo-Wettbewerb
Optimiere das UR-Protokoll. Einreichungen werden gegen einen Branch des Codes bewertet, und der Gewinner wird zur nächsten Baseline und erhält SN1α. Sechs Runden zu je einer Woche, Start in Kürze. Los geht’s!
Das Protokoll ist ein dezentral-natives Multi-IP-, Multi-Transport-System, das auf Millionen von Minern pro Netzbetreiber skalieren soll. Jeder Algorithmenbereich unten ist mit seinem Quellcode und, wo zutreffend, mit anonymisierten Datensätzen für unabhängige Analyse veröffentlicht.
URTRANSPORT1Leistung
Multi-Hop-Routing über TCP-Transporte mit Fokus auf globale Erreichbarkeit. UDP- und Peer-to-Peer-Stream-Upgrades werden unterstützt, die Integration von WebRTC, XRay und WireGuard ist geplant.
Aktueller Ansatz
Der Transport ist zuerst auf Erreichbarkeit ausgelegt, damit jeder Mensch auf der Welt eine Verbindung aufbauen kann. Multi-Hop-Routing läuft über TCP-Transporte durch einen zentralen Hop. UDP-Transporte wie H3 und DNS sind implementiert, aber deaktiviert: Im realen Betrieb blieben sie in diesem Aufbau hinter dem TCP-Pfad zurück. Ein Multi-Miner-Hop mit Peer-to-Peer-Stream-Upgrade ist ebenfalls implementiert und derzeit deaktiviert. Transportauswahl und der Pfad für Stream-Upgrades liegen in transport.go und transfer_stream_manager.go.
Implementierung
Forschungsrichtungen
Etablierte Protokolle wie WebRTC, XRay und WireGuard als Stream-Upgrades auf dem Multi-Miner-Hop integrieren und UDP-Transporte dort wieder aktivieren, wo Messungen einen Nutzen zeigen. Der Zuordnungsalgorithmus könnte zudem Hops mit öffentlicher IP und Port von Hops ohne unterscheiden, um Geschwindigkeit und Verbindungsqualität gegeneinander abzuwägen. Jede dieser Änderungen lässt sich auf einem experimentellen Netzbetreiber erproben, bevor sie zum Standard wird.
UREXTENDER1Erreichbarkeit
N-Schicht-TLS-Verschlüsselung (N≥2), bei der jede äußere Schicht ein selbstsigniertes Zertifikat mit SNI-Spoofing zu einer Zwischen-IP verwendet und an einen weiteren Hop oder eine Ende-zu-Ende-TLS-Verbindung weiterleitet. Jeder kann einen Extender auf jeder Domain hosten.
Aktueller Ansatz
Der Kern-Netzwerkstack unterstützt N-Schicht-TLS-Verschlüsselung mit N von mindestens zwei. Jede äußere Schicht kann ein selbstsigniertes Zertifikat für einen gewählten Hostnamen verwenden, um eine Zwischen-IP zu erreichen, die den Verkehr an einen weiteren Hop oder an eine Ende-zu-Ende-TLS-Verbindung mit der Domain des Netzbetreibers weiterleitet — die Verbindung sieht so wie gewöhnlicher Verkehr zu diesem Hostnamen aus. Jeder kann einen Extender auf einer Domain hosten, die er kontrolliert. Die Nutzer eines Extenders teilen sich ein gemeinsames Rate-Limit, das im Einzelfall angepasst werden kann.
Implementierung
Forschungsrichtungen
Extender können in eine Protokoll-Grant-Liste aufgenommen werden, die einen Anteil der Anreize auf die teilnehmenden Extender verteilt; die Details zur Aufnahme werden veröffentlicht, sobald die Liste öffnet. Jeder Miner übernimmt die Extender-Rolle bereits neben dem Egress. Offen ist, wie sich die Reichweite eines Extenders dort messen lässt, wo sie am meisten zählt, ohne seine Nutzer preiszugeben, und wie die äußeren Schichten Hostnamen und Zertifikate rotieren sollten, wenn sich Blockaden anpassen.
UR-FP2Client-Miner-Zuordnung
Sampling-Algorithmus, der eine 10×-Zufallsstichprobe potenzieller Miner lädt und proportional zu Zuverlässigkeit × Client-Bewertung mischt. Sybil-Resistenz wird durch die Bedingung garantiert, dass die Summe der Zuverlässigkeit pro IP-Subnetz höchstens 1 beträgt.
Aktueller Ansatz
Das Zuordnungssystem lädt eine Zufallsstichprobe möglicher Miner aus dem Speicher — etwa das Zehnfache der benötigten Zahl — und mischt sie proportional zu Zuverlässigkeit × Client-Bewertung, um die Finalisten zu bestimmen. Sein Schutz gegen Miner-Aliasing (Sybil-Angriffe) ist eine Obergrenze pro IP-Subnetz: Die Zuverlässigkeitswerte aller Miner eines Subnetzes summieren sich auf höchstens 1, sodass das Aufteilen einer Verbindung in viele Identitäten ihren Anteil an Zuordnungen nicht erhöht. Der Einstiegspunkt ist FindProviders2.
Implementierung
Forschungsrichtungen
Bei der Zuordnung Hops mit öffentlicher IP und Port von Hops ohne unterscheiden, um Geschwindigkeit und Verbindungsqualität explizit gegeneinander abzuwägen statt nur über die Zuverlässigkeit. Die Gewichte für Zuverlässigkeit und Client-Bewertung sowie die Stichprobengröße sind die natürlichen Stellgrößen, die ein experimenteller Betreiber gegen die unten beschriebenen anonymisierten Block-Exporte variieren kann — bei fester Obergrenze pro Subnetz als Sybil-Schranke.
UR-MULTIMulti-Client
Heuristischer Sweep-Algorithmus, der ein Fenster von Minern verwaltet. Sperrt den Verkehr in die beste verfügbare Stufe basierend auf Übertragungsschwellen statt Protokollanalyse.
Aktueller Ansatz
Ein heuristischer Sweep verwaltet ein Fenster von Minern und sperrt den Verkehr in die Miner der höchsten verfügbaren Stufe. Entschieden wird anhand von Übertragungsschwellen — wie viel ein Miner tatsächlich übertragen hat — und nicht durch Inspektion des Protokolls im Tunnel, sodass der Router den Anwendungsverkehr nie ansehen muss. Das Fenster erlaubt einem Client, mehrere Miner gleichzeitig im Spiel zu halten und den Verkehr zwischen ihnen zu verschieben, wenn sich ihre gemessene Übertragung ändert.
Implementierung
Forschungsrichtungen
Die Schwellen und Stufengrenzen sind heute von Hand gesetzt. Offene Fragen für einen experimentellen Betreiber: ob sie stattdessen aus gemessenen Übertragungsverteilungen abgeleitet werden sollten, und ob das Fenster auch die Lebendigkeits- und Latenzstatistiken pro Miner einbeziehen sollte, die Validatoren jetzt erzeugen (siehe Routing-Verifizierung), damit ein Client ein schwaches Glied meidet, bevor er es mit eigenem Verkehr bezahlt hat.
UR-TRANSFERÜbertragung
Zuverlässiges Zustellungsfenster, optimiert für Umgebungen mit hoher Latenz. Protokoll-Neuübertragungen sind deaktiviert, da das Fenster zuverlässige Zustellung gewährleistet. Verteilt den Verkehr über Transporte nach Leistungsranking.
Aktueller Ansatz
Ein zuverlässiges Übertragungsfenster ist auf Umgebungen mit hoher Latenz abgestimmt. Da das Fenster selbst zuverlässige Zustellung gewährleistet, sind Protokoll-Neuübertragungen in die Übertragungsschicht deaktiviert: Ein durch den Tunnel geführter TCP-Stream wird nicht noch einmal obendrauf neu übertragen. Der Verkehr wird nach Leistungsranking und Verfügbarkeit auf die verfügbaren Transporte verteilt, sodass ein langsamer oder ausfallender Transport Anteil verliert, statt den Stream zum Stillstand zu bringen.
Implementierung
Forschungsrichtungen
Offene Fragen: wie sich das Fenster über die Bandbreite realer Latenzen statt für ein festes Profil selbst dimensionieren sollte, wie Transporte neu gereiht werden sollten, wenn sich ihre Leistung mitten im Stream ändert, und wie die Übertragungsschicht mit den für den Transport geplanten Stream-Upgrades (siehe Leistung) zusammenspielen sollte, wenn ein Hop Peer-to-Peer ist und der nächste nicht.
UR-IPIP-Egress
IP-Stack-Implementierung mit minimalem Speicherverbrauch. Setzt zuverlässige Peer-Kommunikation über die Übertragungsschicht voraus, daher werden Neuübertragungen entsprechend optimiert.
Aktueller Ansatz
Der IP-Stack ist auf minimalen Speicherverbrauch ausgelegt, damit ein Miner auch auf einem Telefon oder einem kleinen Gerät als Egress dienen kann. Er setzt zuverlässige Kommunikation mit der Gegenseite über die Übertragungsschicht voraus, wodurch seine eigene Neuübertragungslogik wegoptimiert statt dupliziert werden kann. Die Sicherheitsschicht (siehe Sicherheit) sitzt im selben Pfad, sodass jedes Paket geprüft wird, bevor es den Miner verlässt.
Implementierung
Forschungsrichtungen
Offene Fragen: wie weit der Speicherbedarf auf den kleinsten Geräten noch sinken kann, und wie der Egress-Stack seine Garantien behält, wenn die Zuverlässigkeitsannahmen der Übertragungsschicht für die für den Transport geplanten Peer-to-Peer-Stream-Upgrades gelockert werden. Wie beim Transport werden Änderungen auf einem experimentellen Betreiber erprobt, bevor sie zum Standard werden.
UR-PSUB2Belohnungszuteilung
Unabhängige Validatoren bewerten jeden Betreiber-Pool nach Nachfrage und gemessener Qualität; Bittensors Yuma Consensus verwandelt diese Bewertungen in Emission. Innerhalb eines Pools stuft ein Betreiber seine Miner nach bedienten Verträgen und Zuverlässigkeit ein, legt in jedem Zyklus eine Merkle-Auszahlungswurzel fest, und jeder Miner beansprucht seinen Anteil direkt vom Abrechnungsvertrag.
Aktueller Ansatz
Belohnungen sind die Emission des UR-Subnets auf SN25. Die Miner jedes Betreibers bilden einen Pool mit einer Miner-UID. In jedem Tempo bewerten unabhängige Validatoren jeden Pool nach implizierter Nutzung × gemessener Qualität (die Epochen-Einlage des Betreibers geteilt durch den veröffentlichten Satz seiner Conviction-Stufe, mal der Miner-Qualität des Pools aus den eigenen Trails des Validators) unter Commit-Reveal, und Yuma Consensus verwandelt den Median in Emission. Innerhalb des Pools stuft der Betreiber die Miner nach bedienten Verträgen × Zuverlässigkeit ein, legt in jeder Epoche eine Merkle-Auszahlungswurzel fest, und jeder Miner beansprucht seinen Anteil direkt vom Abrechnungsvertrag. Die Top-Flotten nach routbarer IP-Breite halten eigene UIDs und werden nativ bezahlt. Solange der veröffentlichte Preis 0 ist, werden keine Einlagen eingesammelt und jeder Pool trägt dieselbe implizierte Nachfrage, sodass allein die gemessene Qualität den Pool-Kanal steuert.
Implementierung
Forschungsrichtungen
θ ist ein veröffentlichter Governance-Parameter: tail-lastig starten (θ ≈ 0,3), die realisierte Vergütung pro Stufe messen und θ ausweiten, wenn die Menge der Top-Miner und der Qualitätskonsens unabhängiger Validatoren reifen — unter der Bedingung, dass der am schlechtesten bezahlte Top-Level-Miner weiterhin mindestens so viel verdient wie der bestbezahlte Pool-Miner. Der Ausschlag, den die Qualität auf das Pool-Gewicht hat, ist beim Bootstrap begrenzt und wird hochgefahren. Eine Aufwandsprämie für Validatoren ist entworfen, aber geparkt und wird nur gebaut, wenn das laufende Netzwerk zeigt, dass unabhängige Abdeckung sie braucht. Die Dezentralisierung der Validatorenmenge über die Eigentümermehrheit hinaus ist ein bewusster späterer Governance-Schritt.
UR-CONTRACTBerechtigung
Die Übertragung zwischen Parteien erfordert einen verschlüsselten Vertrag mit Treuhandguthaben und einem Berechtigungssatz. Beide Seiten müssen mit bestätigten Byte-Zählern abschließen; Meinungsverschiedenheiten lösen einen erzwungenen Lösungsprozess aus.
Aktueller Ansatz
Die Übertragung zwischen einem Initiator und einem Companion erfordert einen Vertrag, der mit dem geheimen Schlüssel des Ziel-Clients verschlüsselt ist. Der Vertrag hält ein festes Übertragungsguthaben in Treuhand und legt die Berechtigungen zwischen beiden Parteien fest. Der Companion kann gepaarte Verträge für den Rückverkehr anlegen, und Multi-Hop-Pfade senden Stream-Open- und Stream-Close-Ereignisse an die Zwischenstationen. Nach der Nutzung schließen beide Parteien den Vertrag mit einem bestätigten Byte-Zähler ab. Schließt eine Seite nicht ab oder weichen die Summen voneinander ab, entscheidet die Vertragsauflösung über das Ergebnis; meldet eine Seite Missbrauch, wird künftige Übertragung zwischen diesen Parteien blockiert.
Implementierung
Forschungsrichtungen
Bediente Verträge × Zuverlässigkeit ist zugleich die Standardbasis des Betreibers für seine Pool-Auszahlungsliste, sodass die Genauigkeit der abgeschlossenen Byte-Zähler in die Belohnungen einfließt. Offene Fragen: wie eine Abweichung zwischen zwei Abschlusszählern ohne eine vertrauenswürdige dritte Summe beigelegt werden kann, wie gepaarte Rückverträge für asymmetrischen Verkehr dimensioniert sein sollten und wie eine Missbrauchsmeldung zu gewichten ist, wenn die Zähler beider Parteien schon früher voneinander abwichen.
UR-SEC1Sicherheit
Port-Sperrliste und IP-Sperrliste zum Schutz des Miner-Netzwerks. Führt keine Protokollinspektion durch — Miner leiten nur verschlüsselten Verkehr weiter.
Aktueller Ansatz
Die Sicherheitsschicht verwendet Port- und IP-Sperrlisten. Sie inspiziert keine Anwendungsprotokolle: Miner leiten nur verschlüsselten Verkehr weiter, es gibt also nichts zu inspizieren, und die Sperrlisten sind es, die einen Miner Verkehr ablehnen lassen, der gängigen Regulierungsrichtlinien wie CFAA und DMCA widerspricht, und bekannte bösartige Ziele verwerfen lassen. Die Listen gelten auf dem Miner, sodass der Verkehr eines Nutzers an jedem Exit auf dieselben Regeln trifft.
Implementierung
Forschungsrichtungen
Offene Fragen: wie Sperrlisten über eine Flotte verteilt und aktualisiert werden sollten, ohne eine zentrale Stelle, die den Verkehr sehen kann; ob die Sicherheitsschicht die Reputation je Ziel aus anonymisierten Egress-Daten lernen sollte statt aus statischen Listen; und was ein Miner seinen eigenen Listen hinzufügen dürfen sollte, ohne das Verhalten des Netzwerks über die Exits hinweg zu spalten.
UR-VERIFY1Routing-Verifizierung
Validatoren durchlaufen vom Server zugewiesene Ketten von Minern und belegen den Live-Egress aus jedem Hop mit vier Ed25519-Signaturen. Statistiken zu Abschluss und Latenz pro Schritt finden das schwächste Glied und werden zum Qualitätssignal, das die Pool-Emission steuert.
Aktueller Ansatz
Ein Validator startet einen Trail über einen Miner seiner Wahl und ruft /verify auf; der Server leitet den Hop aus der Quell-IP der Anfrage ab, nie aus einer Behauptung. Jeder nächste Hop wird gleichverteilt zufällig ohne Zurücklegen gezogen und erst offengelegt, wenn der aktuelle Hop bestätigt ist, sodass sich ein Pfad nicht vorausberechnen lässt. Vier Ed25519-Signaturen binden den Trail: SEED und EXTEND vom Validator, ASSIGN und FINAL vom Server, der auch jede Hop-Zeit stempelt. Ein Fehlschlag wird dem einen Hop zugeschrieben, der nie erreicht wurde, die Latenz wird pro Schritt bei der Bestätigung erfasst, der vom Validator gewählte Seed-Hop wird ausgeschlossen, und jeder Miner wird, sobald er genug Exposition hat, über ein Wilson-Score-Intervall für den Abschluss und Latenzperzentile berichtet.
Implementierung
Forschungsrichtungen
Ein abgeschlossener Trail beweist sequenziellen Live-Transit zu einem bekannten Ziel, nicht die ehrliche Weiterleitung von Nutzerverkehr, und Selbstbegünstigung pro Hop ist nur statistisch beschränkt — durch eine unabhängige Validatorenpopulation. Der Weg zu auszahlungstauglicher Messung: Proof-of-Routing durch Attestierung der Nachbarn, Zielvielfalt, damit ein Miner den einen gemessenen Pfad nicht optimieren kann, Sybil-Resistenz der Validatoren über Stake und ein hierarchisches Hazard-Modell für die Zuschreibung. Bis dahin sind die Statistiken Lebendigkeits- und Latenzüberwachung sowie vorläufige Bewertung.
Anonymisierung
Der Auszahlungsblock des Netzwerks beträgt 7 Tage, und die Exporte der Ein- und Ausgaben jedes Algorithmus werden pro Block anonymisiert. Jede Client-ID und jeder IP-Subnetz-Hash wird durch einen einfachen ganzzahligen Zähler ersetzt, sodass eine Identität innerhalb eines Blocks konsistent ist, aber nichts über Blöcke hinweg und nichts zu einer Produktions-ID zurück trägt. Stadt-Metadaten sind nicht enthalten. Die Block-Exporte sind zur Veröffentlichung vorbereitet, aber noch nicht veröffentlicht; diese Seite wird sie verlinken, sobald sie es sind.
Für Forschende und Entwickler
UR möchte, dass Nutzer sich über föderierte Netzbetreiber für experimentelle Algorithmen entscheiden können. Ein neuer Betreiber tritt demselben Anreizsystem bei, das heute die Miner bezahlt, und ein Miner kann so viele Betreiber bedienen, wie er will. Die App wird jedem Nutzer die Option bieten, eine alternative Betreiber-Domain einzugeben. Zugangsdetails für experimentelle Betreiber werden veröffentlicht, sobald das Programm öffnet, und diese Seite verfolgt den aktuellen Standardalgorithmus und die experimentellen Richtungen. Für Sicherheitsforschung folge der Richtlinie zur Offenlegung von Schwachstellen.
Audits
Peer-Audits des Protokolls und seiner Implementierungen.
- GeplantVerschlüsselungsaudit 2026Cure53Geplant für November – Dezember 2026Umfang: Design der Verschlüsselung und Korrektheit der Implementierung.Die Ergebnisse werden von UR und Cure53 veröffentlicht.
- Peer-AuditMASA L2 2025Leviathan Security GroupAbgeschlossen im Mai 2025