SingLinkLabs · Protocol Paper 01
Technisches Whitepaper zum SingLink-Protokoll
SingLink 2.0-Architektur, vollständiger Verbindungslebenszyklus und Protokollgrenzen
SingLink 2.0 ist ein formales Netzwerkübertragungsprotokoll, das unabhängig von SingLinkVPN entwickelt wurde, keine Client-Softwareversion. In diesem Artikel werden die öffentlichen Funktionen des Protokolls, das Referenzimplementierungsmodell, Testdatengrenzen und externe Protokollunterschiede anhand der Steuerebene, der Datenebene und des gesamten Verbindungslebenszyklus erläutert.
- Document
- SLP-WP-01
- Revision
- 1.0
- Published
- 2026-07-29
- Language
- Deutsch
Protokollgenerationen und Clientversionen werden unabhängig voneinander verwaltet. Die Knotenverfügbarkeit hängt vom Echtzeitstatus des Clients ab.
Abonnieren Sie den Atom-FeedScope and evidence
Umfang, Schlussfolgerungen und Evidenzgrenzen
Dies ist keine Marketingseite, sondern eine Systembeschreibung von der Konfigurationserfassung bis zur Verbindungsbereinigung. Bei jedem Punkt wird zwischen bestätigten Fähigkeiten, öffentlichen Designbeschreibungen und Referenzimplementierungsmodellen unterschieden.
SingLink 2.0 ist die offizielle Generation des Netzwerkübertragungsprotokolls, die unabhängig von SingLinkVPN entwickelt wurde. „2.0“ steht für den Protokollnamen und die Protokollgenerierung, nicht für die Softwareversionsnummer von Windows, macOS, Android, iOS oder anderen Clients.
Die Produktgrenze des Protokolls ist nicht nur ein Byteformat vom Client zum Server, sondern umfasst auch Konto- und Knotenberechtigungen, DNS-Verarbeitung, intelligentes Offloading, Knotenauswahl, Sitzungszustandserkennung, Netzwerkumschaltung und Fehlerbehebung.
Von der Produktseite, den Kundenfunktionen und dem offiziellen öffentlichen Kaliber.
Beschreiben Sie das Problem, das das Protokoll lösen muss, und die derzeit offengelegten Systemgrenzen.
Wird zur Erläuterung möglicher Implementierungen verwendet und ist nicht gleichbedeutend mit einer veröffentlichten Binärspezifikation.
Versioning
Protokollgenerationen sind keine Softwareversionen
Protocol
SingLink 2.0
Stellt die Gesamtentwicklung der Transportprotokollgenerationen, der Fähigkeitsaushandlung, der Sitzungsmodelle und der Kompatibilitätsrichtlinien dar.
Client software
Jede Plattform hat ihre eigene Nummer
Windows-, macOS-, Android-, iOS-, Linux- und TV-Clients werden entsprechend ihrem jeweiligen Release-Rhythmus verwaltet und nicht mit Protokoll 2.0 vermischt.
System architecture
Trennung von Steuerebene und Datenebene
Die Kontrollebene ist für Berechtigungen, Konfiguration und Knotenplanung verantwortlich; Die Datenebene ist für die Kanäle verantwortlich, die tatsächlich den Benutzerverkehr übertragen. Die Trennung der beiden trägt dazu bei, den Umfang sensibler Daten zu begrenzen und Fehler zu isolieren.
Control plane
Bedienoberfläche
- 01 Konto- und Paketberechtigungen
- 02 Knoten- und Protokollfähigkeitsliste
- 03 Kurzfristige Konfiguration, Strategie und Widerruf
- 04 Knotenzustands- und Planungsinformationen
Data plane
Datenebene
- 01 Verkehrsübernahme und -weiterleitung
- 02 TCP, UDP und logischer Flussträger
- 03 Sitzungsstatus und Gesundheitserkennung
- 04 Entkapselung der Rückgabedaten
Connection lifecycle
22 Bearbeitungsstufen
Von den Kontoberechtigungen über den Zugang zum Systemnetzwerk bis hin zur Entkapselung der Rückgabedaten und der Sicherheitsbereinigung behält der folgende Prozess vollständige technische Links bei und markiert den Beweisstatus für jeden Schritt.
- 01
Kontoanmeldung und Berechtigungsbestätigung
Bestätigte FähigkeitenDer Client erhält die verfügbaren Pakete, Knoten und Protokollberechtigungen des aktuellen Kontos. Authentifizierungsdaten sollten kurzlebig, widerrufbar und vom nachfolgenden Datenweiterleitungsstatus entkoppelt sein.
- 02
Bereitstellung der Knoten- und Protokollkonfiguration
Öffentliche DesignbeschreibungDie Kontrollebene gibt die Knotenadresse, den Port, die verfügbaren Protokolle und die erforderlichen Richtlinien zurück und sollte dem Client keine direkten Langzeit-Hauptschlüssel oder unnötige sensible Felder liefern.
- 03
Stellen Sie den Zugang zum Systemnetzwerk her
Bestätigte FähigkeitenDer Client empfängt den Datenverkehr, der über den TUN-Modus, den System-Proxy oder die Plattform-Netzwerkerweiterung verarbeitet werden muss. Der konkrete Zugang hängt von den Fähigkeiten des Betriebssystems ab.
- 04
DNS-Auflösung und Domänennamenbestimmung
Bestätigte FähigkeitenFür DNS-Anfragen und nachfolgende Verbindungen müssen konsistente Richtlinien verwendet werden, um zu vermeiden, dass Domänennamen Proxys durchlaufen, während DNS noch aus dem lokalen Netzwerk austritt oder eine fehlerhafte Umleitung verursacht.
- 05
Intelligente Verkehrsverteilung und Routing-Beurteilung
Bestätigte FähigkeitenBestimmt Verbindungen als direkt, Proxy oder blockiert basierend auf Regeln, Anwendung, Zieldomänenname, IP und Netzwerkstatus.
- 06
Knotenauswahl
Bestätigte FähigkeitenDer manuelle Modus verwendet benutzerdefinierte Knoten; Der intelligente Modus kann Kandidatenknoten basierend auf Latenz, Verfügbarkeit, Auslastung, Region und Paketberechtigungen auswählen.
- 07
Aushandlung der Protokollfähigkeit
Öffentliche DesignbeschreibungDer Client und der Server bestätigen die von beiden Parteien unterstützten Protokollgenerationen und -funktionen. Der alte Client sollte inkompatible Verhaltensweisen nicht stillschweigend aktivieren, wenn er neue Funktionen nicht erkennen kann.
- 08
Authentifizierung und Anti-Replay
ReferenzimplementierungsmodellKnoten überprüfen, ob das Konto oder die Sitzung gültig ist, und sollten verhindern, dass alte Authentifizierungsdaten durch Alterung, Randomisierung oder gleichwertige Mechanismen wiederverwendet werden.
- 09
Schlüsselaustausch und Sitzungsschlüssel
ReferenzimplementierungsmodellDas Protokoll erfordert die Einrichtung eines separaten Verschlüsselungskontexts für die aktuelle Verbindung. Die spezifischen Cipher-Suites, Handshake-Felder und Rotationsperioden müssen künftigen öffentlichen Spezifikationen unterliegen.
- 10
Sitzung erstellen
ReferenzimplementierungsmodellSitzung stellt die Übertragungssitzung zwischen dem Client und dem Knoten dar, die den Verbindungsstatus, Funktionsinformationen, Heartbeats und einen oder mehrere logische Abläufe übertragen kann.
- 11
Stellen Sie eine Stream- oder unabhängige Proxy-Verbindung her
ReferenzimplementierungsmodellJede Anwendungsanforderung kann einem logischen Stream innerhalb der Sitzung zugeordnet werden, oder es kann eine unabhängige Verbindung hergestellt werden; Die endgültige Methode hängt von der öffentlichen Implementierung ab.
- 12
Datenrahmenkapselung
ReferenzimplementierungsmodellZielinformationen, Stream-Identifikation, Nutzlastlänge, Steuerbefehle und Daten sind erforderlich, um einen analysierbaren Frame zu bilden; Diese Seite erfindet keine undokumentierten Binärfelder.
- 13
Verarbeitung des TCP-Verkehrs
Öffentliche DesignbeschreibungTCP-Byteströme müssen die Ordnung aufrechterhalten, Halbschließungen und abnormale Schließungen verarbeiten und den Gegendruck der Anwendungsseite an die Transportseite weiterleiten.
- 14
UDP- und QUIC-Verkehrsverarbeitung
Öffentliche DesignbeschreibungUDP-Datagramme müssen Nachrichtengrenzen beibehalten und Sitzungszeitüberschreitungen verwalten. UDP-artige Dienste wie QUIC müssen außerdem unnötige Head-of-Line-Blockierungen vermeiden.
- 15
Durchflusskontrolle und Gegendruck
ReferenzimplementierungsmodellWenn die Verbrauchsgeschwindigkeit des Clients, Knotens oder Zieldienstes nachlässt, sollte das Pufferwachstum begrenzt werden, um zu verhindern, dass ein einzelner Stream die gesamte Sitzung zum Erliegen bringt.
- 16
Unterverpackung, Polsterung und Verkehrsauftritt
ReferenzimplementierungsmodellPaketierung und Padding können nur als Teil der Übertragungsstrategie verwendet werden und können nicht als absolute Heimlichkeit bezeichnet werden; Seine Aktivierungsbedingungen und sein Overhead erfordern Tests und Verifizierung.
- 17
Handhabung von MTU und Paketgröße
Öffentliche DesignbeschreibungDer Tunnel-Overhead reduziert die verfügbare MTU, und große Paketausfälle müssen durch Fragmentierungsvermeidung, MSS-Anpassung oder gleichwertige Mechanismen reduziert werden.
- 18
Verzögerung, Paketverlust und Überlastungsbehandlung
ReferenzimplementierungsmodellDas Protokoll sollte den Senderhythmus und die erneute Übertragung auf der Grundlage von Netzwerk-Feedback steuern und zwischen echtem Paketverlust, Warteschlangenverzögerung und kurzfristigem Netzwerk-Jitter unterscheiden.
- 19
Herzschlag- und Gesundheitserkennung
Bestätigte FähigkeitenÜberwachen Sie kontinuierlich den Sitzungs- und Knotenstatus, um zu vermeiden, dass Sie sich bei der Erkennung unterbrochener Verbindungen ausschließlich auf die langen Zeitüberschreitungen des Betriebssystems verlassen.
- 20
Netzwerkumschaltung und Sitzungswiederherstellung
Bestätigte FähigkeitenNach dem Wechsel zwischen Wi-Fi und Mobilfunknetzen bestätigt der Client erneut den Netzwerkzugang, DNS, Routing und Übertragungssitzungen und nimmt die Verbindung entsprechend seinen Fähigkeiten wieder auf.
- 21
Knotenausfall und automatische Umschaltung
Bestätigte FähigkeitenIm Falle eines Soft-Failures kann die Sitzung zunächst neu aufgebaut werden, im Falle eines Hard-Failures können verfügbare Knoten gewechselt werden. Während des Umschaltvorgangs muss das Systemrouting wiederhergestellt werden und Datenverkehr durch unerwartete Direktverbindungen vermieden werden.
- 22
Rückgabe von Daten, Entkapselung und Sicherheitsbereinigung
Öffentliche DesignbeschreibungDer Client überprüft und entkapselt die zurückgegebenen Daten und löscht den temporären Sitzungsstatus, Cache-Schlüssel, Routing und DNS-Änderungen, nachdem die Verbindung hergestellt wurde.
Traffic entry and routing
Traffic-Übernahme, DNS und intelligentes Offloading
Systemnetzwerkeintrag, Domänennamenauflösung und Routing-Beurteilung müssen denselben Kontext haben, um DNS-Lecks, Fehlerausgänge und unerwartete direkte Verbindungen zu vermeiden.
Desktop-Systeme können den TUN-Modus oder den System-Proxy verwenden; Mobil- und TV-Plattformen nutzen ihre jeweiligen Netzwerkerweiterungsmöglichkeiten. Verschiedene Plattformen verfügen über unterschiedliche APIs, aber die Richtlinienziele sind dieselben: Datenverkehr, der einen Proxy erfordert, gelangt in den Tunnel, und Datenverkehr, der keinen Proxy erfordert, wird gemäß den Regeln direkt verbunden.
Das Proxying nur des Anwendungsdatenverkehrs und das Zulassen, dass DNS weiterhin über das lokale Netzwerk läuft, kann dazu führen, dass der Domänenname offengelegt wird oder Auflösungsergebnisse erhalten werden, die für den aktuellen Exit nicht geeignet sind. Daher müssen der Domänennamenabgleich, die DNS-Abfrage, das IP-Caching und der Verbindungsaufbau denselben Routingkontext verwenden.
direkte Verbindung
Lokale Dienste oder Ziele, die explizit keinen Proxy benötigen, nutzen das lokale Netzwerk.
Agent
Nach der Berechtigungsüberprüfung wird die Verbindung über den ausgewählten SingLink-Knoten hergestellt.
blockieren
Verbindung wird verweigert, wenn die Sicherheitsregel erreicht wird oder ein Ziel ohne Erlaubnis erreicht wird.
Authentication
Authentifizierung und verschlüsselte Sitzungen
Berechtigungsbestätigung antwortet „Kann dieses Konto diesen Knoten und dieses Protokoll verwenden“; Die Übertragungsauthentifizierung antwortet: „Ob die aktuelle Verbindung von einem gültigen Client stammt“. Beide sollten einen kurzlebigen, widerrufbaren Sitzungsstatus verwenden und verhindern, dass alte Authentifizierungsinformationen wiedergegeben werden.
Der Client und der Knoten müssen außerdem die von beiden Parteien unterstützten Protokollgenerationen und -funktionen bestätigen. Eine Seite, die die neuen Funktionen nicht erkennt, muss die Verbindung sicher herabstufen oder verweigern und kann inkompatibles Verhalten nicht ohne Bestätigung aktivieren.
Disclosure boundary
Unveröffentlichte kryptografische Details
Die vorhandenen Informationen reichen nicht aus, um bestimmte Handshake-Felder, Verschlüsselungssammlungen, Schlüsselableitungsfunktionen, Rotationsperioden und binäre Paketformate zu identifizieren. Dieser Artikel beschreibt nur Sicherheitsziele und schreibt AES, TLS-Versionen, bestimmte Kurven oder feste Feldlängen nicht als vollendete Tatsachen vor.
Session model
Sitzung, Stream und Datenrahmen
Verwenden Sie ein hierarchisches Sitzungsmodell, um die Beziehung zwischen Anwendungsverbindungen, logischen Abläufen und Knotentransportkontexten zu erläutern und gleichzeitig nicht offengelegte Formatgrenzen zu klären.
Session
Der Transportkontext zwischen dem Client und dem Knoten kann Authentifizierungsergebnisse, Funktionen, Heartbeats und Flusskontrolle auf Verbindungsebene übertragen.
Stream
Eine Logic App-Verbindung. Ob mehrere Streams Sitzungen gemeinsam nutzen, hängt von der endgültigen öffentlichen Implementierung und der Plattformrichtlinie ab.
Der Datenrahmen muss mindestens Steuerbefehle, Logikfluss, Lastgrenzen und Fehlerstatus ausdrücken; Bevor das offizielle Format veröffentlicht wird, wird diese Seite keine ungeprüfte Feldtabelle enthalten.
Transport
TCP, UDP und QUIC
TCP
geordneter Bytestrom
Behalten Sie die Byte-Reihenfolge bei, behandeln Sie Halbschließvorgänge, abnormale Schließvorgänge, Rückstau- und Zielverbindungsfehler und verhindern Sie, dass langsame Verbindungen den Sitzungspuffer füllen.
UDP
Datagrammgrenzen
Behalten Sie die Grenzen des Datagramms bei und behalten Sie den Ziel- und Timeout-Status bei. Wenn UDP-over-TCP verwendet wird, müssen Head-of-Line-Blockierung und Paketverlustverstärkung bewertet werden.
QUIC
Zuverlässiger Transport über UDP
Versuchen Sie, die Vorteile von QUIC bei Überlastung und Neuübertragung beizubehalten, um eine wiederholte Wiederherstellung durch zusätzliche Zuverlässigkeitsschichten zu vermeiden.
Reliability
Flusskontrolle, MTU, Heartbeat und Wiederherstellung
Eine stabile Verbindung ist keine automatische Schaltfläche zum erneuten Verbinden, sondern eine Zustandsmaschine, die aus Pufferung, Paketverpackung, Zustandserkennung, Routenwiederherstellung und Knotenvermittlung besteht.
Flusskontrolle
Passen Sie das Sendefenster entsprechend der Verbrauchsgeschwindigkeit an, um zu vermeiden, dass die gesamte Sitzung mit einem einzigen Stream blockiert wird.
MTU-Handhabung
Berücksichtigen Sie den zusätzlichen Aufwand von Tunneln, um das Risiko von Fragmentierung und Schwarzen Löchern zu verringern.
Gesundheitscheck
Bestimmen Sie die Verbindung anhand von Heartbeat, Verzögerung, Paketverlust und tatsächlichem Weiterleitungsstatus.
Netzwerkwiederherstellung
Nachdem das Netzwerk unterbrochen wurde, werden Portal, DNS, Routing und Sitzungen neu aufgebaut, um zu verhindern, dass der Datenverkehr versehentlich direkt verbunden wird.
Product comparison
SingLink 2.0 und Beta
| Indikator | SingLink 2.0 | SingLink Beta |
|---|---|---|
| Positionierung | formelle Vereinbarung zwischen Generationen | Geschwindigkeitsorientiertes Vorschauprotokoll |
| Interne A/B-Teststabilitätsrate | 99.5％ | Bis zu etwa 97 % |
| Geschwindigkeitsfokus | Balance aus Geschwindigkeit, Stabilität und Kompatibilität | Der Spitzenwert überschreitet unter geeigneten Bedingungen 1 Gbit/s |
| Berechtigungen für Protokollknoten | Pro, Max und Rich | Alle Pakete |
| Strategie ändern | Konzentrieren Sie sich auf langfristige Kompatibilität und Wiederherstellung | Wird zur Überprüfung neuer Funktionen und Leistung verwendet |
External protocols
Grenzvergleich mit VLESS und AnyTLS
Vergleichsbasis sind die offiziellen öffentlichen Dokumente des jeweiligen Projekts. Hier vergleichen wir Positionierung, Systemgrenzen und Offenlegungsmöglichkeiten und mischen Marketingzahlen nicht in die zugrunde liegenden Protokollschlussfolgerungen ein.
| Abmessungen | Umfang des SingLink-Whitepapers | VLESS öffentlicher Bereich | Öffentlicher AnyTLS-Bereich |
|---|---|---|---|
| öffentliche Positionierung | Das Gesamtsystem aus Produktsteuerungsebene und Übertragungsdatenebene | Zustandsloses, leichtes Client- und Server-Transportprotokoll | TLS-basiertes Proxy-Protokoll und Referenzimplementierung |
| Identität und Zweck | Konto, Knotenberechtigungen, Sitzungs- und Routing-Zusammenarbeit | UUID, Befehl, Port und Zieladresse | TLS-Nachauthentifizierung, dann Sitzung aufbauen |
| Session／Stream | Erläuterung des Referenzmodells, genaues Format noch nicht bekannt gegeben | Unterstützen Sie Mux, die Details werden durch Implementierung und Konfiguration bestimmt | Machen Sie Sitzungsrahmen, Stream-Multiplexing und Befehle verfügbar |
| Verkehrsauftritt | Die zu überprüfende Übertragungsstrategie erhebt keinen Anspruch auf absolute Unsichtbarkeit | Offizielle Dokumente beschreiben optionale Flow- und andere Mechanismen | Offenlegung von Unteraufträgen, Auffüllplänen und Aktualisierungsmechanismen |
| Belastbarkeit | Gesundheitserkennung, Netzwerkunterbrechung, Sitzungsrekonstruktion und Knotenwechsel | Verantwortlich für die Röntgenökologie und spezifische Übertragungskombinationen | Protokoll v2 macht SYNACK, Heartbeat und Server-Aushandlung verfügbar |
| Produktsystem | DNS, intelligentes Offloading, Paketberechtigungen und Knotenplanung | Nicht gleichbedeutend mit einer vollständigen VPN-Produktkontrolloberfläche | Nicht gleichbedeutend mit einer vollständigen VPN-Produktkontrolloberfläche |
Diese Tabelle stellt keine Codekompatibilität, Leistungsrankings oder Schlussfolgerungen aus der Sicherheitsüberprüfung dar.
Platforms and openness
Plattformübergreifende Kompatibilität und Open-Source-Grenzen
Plattformkonsistenz
SingLinkVPN deckt iOS-, Android-, Windows-, macOS-, Linux- und TV-Geräte ab. Plattformübergreifende Konsistenz bedeutet nicht, dass jede Plattform genau dieselbe System-API verwendet, sondern dass sie dieselben Berechtigungen, dasselbe Routing, dieselbe Knoten- und Protokollauswahllogik beibehält und sich an die Netzwerkerweiterungsbeschränkungen jedes Betriebssystems hält.
Öffentlicher Geltungsbereich
Der Quellcode des SingLink 2.0-Kernprotokolls wurde noch nicht vollständig offengelegt. Zu den veröffentlichten Anweisungen gehören technische Dokumentation, Architekturbeschreibungen, Forschungsdaten, reproduzierbare Testmethoden, Datenformate, Verifizierungstools und eine Infrastruktur zur verantwortungsvollen Offenlegung von Schwachstellen.
Frequently asked questions
FAQ
Q01Was ist SingLink 2.0?
SingLink 2.0 ist eine formale Netzwerkübertragungsprotokollgeneration, die unabhängig von SingLinkVPN entwickelt wurde. Es wird verwendet, um Identitäts- und Autoritätsüberprüfung, Verkehrsrouting, Übertragungssitzungen, TCP- und UDP-Verarbeitung, Gesundheitserkennung und Ausnahmewiederherstellung zu organisieren.
Q02Ist SingLink 2.0 die Client-Softwareversion?
Nein. SingLink 2.0 ist der Protokollname und die Protokollgenerierung. Windows, macOS, Android, iOS und andere Clients verwenden unabhängige Softwareversionssysteme.
Q03Was ist der Unterschied zwischen SingLink Beta und SingLink 2.0?
Beta ist ein Vorschauprotokoll zur Überprüfung von Geschwindigkeit und neuen Funktionen. SingLink 2.0 ist die offizielle Protokollgeneration, die mehr Wert auf Stabilität, plattformübergreifende Konsistenz, Verbindungswiederherstellung und Langzeitkompatibilität legt.
Q04Wie hoch ist die Stabilitätsrate von SingLink 2.0?
Die interne A/B-Testbilanz von SingLinkVPN in bestimmten Testumgebungen liegt bei 99,5 %, mit einem Beta-Spitzenwert von etwa 97 %. Hierbei handelt es sich nicht um Garantien für alle Regionen und Zeiträume, und die tatsächlichen Ergebnisse werden von Netzwerkbetreibern, Knotenlasten, Geräten und Testmethoden beeinflusst.
Q05Wie geht SingLink mit dem Netzwerkverkehr um?
Der Client richtet zunächst einen Systemnetzwerkzugang ein, schließt DNS und intelligente Verteilung ab, wählt dann Knoten aus, überprüft Berechtigungen, richtet eine Übertragungssitzung ein und kapselt TCP- oder UDP-Daten, bevor er sie an den Knoten sendet.
Q06Wie geht SingLink mit Verbindungsabbrüchen und Netzwerkwechseln um?
Der Client überwacht kontinuierlich den Sitzungs- und Knotenstatus. Wenn eine Ausnahme auftritt, wird die Sitzung neu aufgebaut, DNS und Routing wiederhergestellt oder basierend auf den Fähigkeiten auf andere verfügbare Knoten umgeschaltet.
Q07Was ist der Unterschied zwischen SingLink und VLESS?
VLESS ist offiziell als zustandsloses, leichtes Client- und Server-Übertragungsprotokoll positioniert. Der im SingLink-Whitepaper beschriebene Umfang ist umfassender und umfasst auch die Produktsteuerungsebene, Knotenberechtigungen, intelligentes Routing, Gesundheitserkennung und Wiederherstellungsprozesse; Die beiden sollten nicht anhand eines einzelnen Frame-Formats verglichen werden.
Q08Was ist der Unterschied zwischen SingLink und AnyTLS?
Die öffentliche AnyTLS-Spezifikation konzentriert sich auf die Beschreibung von Authentifizierung, Sitzung, Stream-Wiederverwendung, Padding und Heartbeat über TLS. Das SingLink-Whitepaper beschreibt auch den Client-Traffic-Eintrag, DNS, Routing, Paketberechtigungen und Knotenplanung, sodass der Vergleich auf Systemgrenzen basiert und nicht behauptet, dass die zugrunde liegende Implementierung dieselbe ist.
Q09Wer kann SingLink 2.0 nutzen?
Derzeit sind SingLink 2.0-Protokollknoten hauptsächlich für Pro-, Max- und Rich-Pakete geöffnet; SingLink Beta-Protokollknoten sind für alle Pakete offen. Die tatsächlich verfügbaren Knoten werden auf dem Client in Echtzeit angezeigt.
Q10Ist SingLink 2.0 vollständig Open Source?
Derzeit ist der Quellcode des Kernprotokolls nicht vollständig offengelegt. Technische Dokumente, Forschungsdaten, Testmethoden, Datenformate, Verifizierungstools und Mechanismen zur Offenlegung von Schwachstellen wurden in den kontinuierlichen Open-Source-Plan aufgenommen. Der Umfang der Offenlegung unterliegt dem SingLinkLabs-Lager und offiziellen Ankündigungen.
References and revision
Daten, interne Links und Änderungsaufzeichnungen
Externe Protokollinformationen
Next step
Erleben Sie das SingLink 2.0-Protokoll
SingLink 2.0-Knoten stehen hauptsächlich Pro-, Max- und Rich-Paketen offen. Die Anzahl der Knoten und die Protokollverfügbarkeit unterliegen der Echtzeitanzeige auf dem Client.