ERPC erweitert Solana Leader Slot API um Ping-Messung aus 7 globalen Regionen — Validators Information API ebenfalls gestartet
ERPC erweitert Solana Leader Slot API um Ping-Messung aus 7 globalen Regionen — Validators Information API ebenfalls gestartet
ELSOUL LABO B.V. (Hauptsitz: Amsterdam, Niederlande; CEO: Fumitake Kawasaki) und Validators DAO, die Betreiber von ERPC, haben die APIs zur Erfassung von Solana-Leader-Informationen, geschätzten Standorten und Latenz verbessert: Die Leader Slot API unterstützt nun Referenz-RTT (Ping-Messung) aus 7 Regionen weltweit, und die neue Validators Information API wird ab sofort bereitgestellt.
Zunächst haben wir die Leader Slot API (
getLeaderSlots) erweitert, sodass Referenz-RTT aus 7 ERPC-Beobachtungsregionen weltweit (Frankfurt, Amsterdam, New York, London, Tokio, Singapur und Sydney) abgerufen werden kann. Bisher wurden Messungen nur von Frankfurt aus durchgeführt.Zugleich haben wir die neue Validators Information API (
getValidatorsInformation) veröffentlicht. Diese API listet in einem einzigen Aufruf jeden Validator auf, der in der aktuellen Epoche mindestens einen Leader-Slot innehat. Neben Slot-Anzahl und aktivem Stake gibt sie, sofern verfügbar, auch den geschätzten Standort, Netzwerk-Endpunkte, die Client-Version und die Referenz-RTT aus den 7 Regionen zurück.Beide APIs stehen allen ERPC-Nutzern über die Standard-JSON-RPC-Schnittstelle zur Verfügung.
- Dokumentation zur Leader Slot API: https://erpc.global/en/doc/rpc/leader-slot-api/
- Dokumentation zur Validators Information API: https://erpc.global/en/doc/rpc/validators-information-api/
Der Unterschied zu herkömmlicher Handelsinfrastruktur: In Solana ändert sich das Kommunikationsziel dynamisch
In herkömmlichen Börsen und Finanzsystemen sind die Ziele, an die Orders gesendet werden — Börse, Gateway, Matching Engine — in der Regel an bestimmte Rechenzentren oder Netzwerke gebunden.
Dadurch können Nutzer, sobald sie das Verbindungsziel kennen, ihren Netzwerkpfad dorthin kontinuierlich optimieren. Da sich die Standorte der Zielserver nicht häufig ändern, lassen sich Infrastrukturplatzierung und Kommunikationsrouten relativ statisch planen.
In Solana dagegen rotiert der Leader — der Validator, der für die Produktion der Blöcke verantwortlich ist — gemäß dem Leader-Schedule alle paar Slots. Da die als Leader fungierenden Validatoren über die ganze Welt verteilt sind, ändern sich sowohl das Ziel, das Ihre Transaktionen erreichen müssen, als auch der Netzwerkpfad, der diesem Ziel am nächsten liegt, kontinuierlich.
Mit anderen Worten: In Solana kann das zu optimierende Kommunikationsziel nicht als fester, einzelner Verbindungspunkt behandelt werden.
Zunächst müssen Sie die aktuellen und künftigen Leader aus dem Leader-Schedule ermitteln. Darüber hinaus prüfen Sie, in welcher Region oder welchem Netzwerk sich jeder Validator am wahrscheinlichsten befindet und wie hoch die Latenz von jedem Sendestandort aus ist, bevor Sie eine Senderoute festlegen.
Dieses Strukturverständnis ist der Ausgangspunkt für latenzarme Transaktionsübermittlung und globales Infrastrukturdesign auf Solana.
Leader-Schedule und Netzwerkpositionen als Daten nutzen
In einer Umgebung, in der sich das Ziel dynamisch ändert, ist es nicht praktikabel, dass ein Mensch jedes Mal Leader und Sendestandort prüft und Routen manuell umschaltet.
Erforderlich ist, die folgenden Informationen kontinuierlich zu erfassen und in die Entscheidungslogik von Anwendungen und Infrastruktur zu integrieren.
- Die Leader, die für aktuelle und kommende Slots verantwortlich sind
- Die Anzahl der Slots, für die jeder Validator verantwortlich ist
- Geschätztes Land, Stadt und Region jedes Validators
- Netzwerk-Endpunkte wie TPU und QUIC
- Referenz-RTT, erfasst aus jeder Beobachtungsregion
- Zeitpunkt jeder Messung und ihr Antwortstatus
Geschätzter Standort und gemessene Latenz spielen jeweils unterschiedliche Rollen.
Standortinformationen lassen sich für mittel- bis langfristige Entscheidungen nutzen, wo Infrastruktur und Kapazität platziert werden sollten. Die Referenz-RTT aus jeder Region dagegen liefert eine Entscheidungsgrundlage dafür, welcher Standort derzeit am ehesten einen kurzen Pfad bietet.
Ein physisch oder geografisch naher Standort ist nicht immer auch der kürzeste Weg im Netzwerk. Daher ist es wichtig, Entscheidungen durch die Kombination von geschätztem Standort und tatsächlich beobachteten Werten zu treffen.
Die Leader Slot API und die Validators Information API von ERPC sind APIs, mit denen Sie diese Entscheidungen auf Datenbasis programmieren können.
Leader Slot API: Referenz-RTT-Messung aus 7 Regionen weltweit
Die Leader Slot API gibt kommende Leader-Slots zusammen mit Validator-Identität, aktivem Stake, Netzwerk-Endpunkten, geschätztem Standort, Referenz-RTT und mehr zurück.
Bisher wurden
pingToLeaders-Messungen nur vom Frankfurter Ursprung aus erfasst — ein einziger Beobachtungspunkt gegenüber einem global verteilten Solana-Netzwerk.Mit diesem Update können Sie nun Referenz-RTT abrufen, die aus den folgenden 7 Regionen gemessen wurde.
frankfurtamsterdamnylondontokyosingaporesydney
Indem Sie die Referenz-RTT aus den 7 Beobachtungsregionen für jeden Leader vergleichen, können Sie beurteilen, von welchem Sendestandort aus am ehesten ein kurzer Netzwerkpfad erreicht werden kann.
Dies dient als Entscheidungsgrundlage nicht nur für das Transaktionsrouting, sondern auch für die Entscheidung, in welchen Regionen Kapazität für RPC, gRPC, Direct Shreds, Transaktions-Sendeserver und mehr platziert werden soll.
Die Messergebnisse enthalten
icmpReplied, das angibt, ob der Validator auf ICMP geantwortet hat, und measuredAt, das den Zeitpunkt der letzten erfolgreichen Messung angibt.Ein Validator, der nicht auf ICMP antwortet, kann Dienste wie TPU und QUIC dennoch normal betreiben. Daher sollte
icmpReplied mit dem Wert false nicht als „weit entfernt“, sondern als „per ICMP nicht messbar“ behandelt werden.Wird bei einer Aktualisierung keine erfolgreiche Messung erzielt, wird der Eintrag außerdem nicht mit einem ungemessenen Wert überschrieben — der letzte erfolgreich gemessene Wert und sein Messzeitpunkt bleiben erhalten.
Validators Information API: Leader-Informationen der gesamten Epoche auflisten
Die Leader Slot API eignet sich für Entscheidungen auf Slot-Ebene — „wer ist der Leader für die nächsten Slots?“
Infrastrukturplatzierung und Kapazitätsplanung erfordern dagegen eine breitere Perspektive.
- Welche Validatoren in der aktuellen Epoche als Leader fungieren
- Für wie viele Slots jeder einzelne verantwortlich ist
- Auf welche Länder und Regionen sie verteilt sind
- Wo Infrastruktur platziert werden sollte, um mehr Leadern näherzukommen
Die neue Validators Information API (
getValidatorsInformation) ist die API, die diese Fragen beantwortet.Ohne Parameter aufgerufen, gibt sie jeden Validator zurück, der in der aktuellen Epoche mindestens einen Slot als Leader führt — eine Zeile pro Validator. Standardmäßig werden die Ergebnisse absteigend nach der Anzahl der gehaltenen Leader-Slots zurückgegeben.
Jede Zeile enthält die folgenden Informationen.
slotCountstakeWeight(aktiver Stake in SOL)- Validator-Identität
Sofern verfügbar, werden zusätzlich die folgenden Informationen zurückgegeben.
- Geschätzte Region, Stadt und Land
- Netzwerk-Endpunkte
- Client-Version
- Referenz-RTT aus den 7 Regionen
Da die Daten regelmäßig aktualisiert werden, hält ein regelmäßiger Aufruf der API Ihren Planungsdatensatz aktuell.
Sie können die Ergebnisse auch mit den optionalen Parametern
limit (1–2000), country und region eingrenzen.Die Abrechnung richtet sich nach der Anzahl der zurückgegebenen Validatoren. Die Anzahl der Leader-Validatoren variiert von Epoche zu Epoche; im Beispiel zum Redaktionszeitpunkt verbraucht der Abruf aller 673 Validatoren 6,800 API-Tokens (API-Nutzungsguthaben von ERPC), der Abruf von bis zu 10 Validatoren 100 API-Tokens.
Auf dem Weg zu programmierbarem, datengestütztem Routing
Diese APIs sind nicht einfach dazu gedacht, eine Liste von Validatoren oder Referenz-RTT anzuzeigen.
Das letztendliche Ziel ist, dass Sie den Leader-Schedule, die geschätzten Standorte der Validatoren und die Referenz-RTT aus jeder Beobachtungsregion in die Entscheidungslogik Ihrer Anwendungen einbauen können.
Eine Anwendung kann beispielsweise den kommenden Leader-Schedule abrufen, die Referenz-RTT aus den 7 Beobachtungsregionen für jeden Leader vergleichen und anschließend die zu nutzende RPC- bzw. Transaktions-Senderoute auswählen.
Sie können auch die Leader-Verteilung über die gesamte Epoche analysieren und Infrastruktur vorab in Regionen platzieren, die nahe an Validatoren mit hohen Slot-Zahlen liegen.
Zu den Hauptanwendungsfällen gehören die folgenden.
- Auswahl von Senderouten auf Slot-Ebene
- Kapazitätsplanung auf Epochenebene
- Analyse der Leader-Validatoren nach Region
- Priorisierung unter Berücksichtigung von aktivem Stake und Slot-Anzahl
- Beobachtung von Veränderungen der geografischen und netzwerkbezogenen Verteilung über Epochen hinweg
- Automatische Auswahl zwischen RPC- und Sendeservern, die über mehrere Regionen verteilt sind
In Solana, wo sich das Ziel dynamisch ändert, reicht statische Netzwerkoptimierung allein nicht aus.
Es wird wichtig, den wechselnden Leader kontinuierlich zu verfolgen und Senderouten und Infrastruktur entsprechend seinem Standort und den Netzwerkbedingungen dynamisch auszuwählen.
Auf dem Weg zu Solana-Infrastruktur für den globalen Betrieb
ERPC ist eine Hochleistungs-Infrastruktur für Solana, die vom ersten Tag an für den globalen Betrieb konzipiert wurde.
Unser Edge-Netzwerk, unsere Bare-Metal- und VPS-Angebote, Direct Shreds, Geyser gRPC, SWQoS-Endpunkte und diese Operational-Intelligence-APIs werden alle für einen gemeinsamen Zweck bereitgestellt.
Dieser Zweck ist, Entwicklern, die in einer Umgebung mit weltweit verteilten Nutzern und Leadern eine latenzarme, effiziente Ausführung fordern, sowohl Daten als auch Infrastruktur bereitzustellen.
Referenz-RTT aus 7 Regionen weltweit und epochenweite Validator-Informationen sind jetzt über einfache RPC-Aufrufe verfügbar. Solana-Anwendungen können Sendestandorte und Netzwerkrouten nun datengestützt auswählen — als Reaktion auf den sich ständig ändernden Leader.
Für Entwickler, die auf Solana latenzarme Übermittlung, globale Infrastrukturplatzierung und dynamische Routing-Optimierung anstreben, ist dies eine Entscheidungsgrundlage, die unmittelbar an den realen Betrieb anknüpft.
Wir hoffen, dass dies bei der Auswahl latenzarmer Senderouten, beim Design von Infrastruktur mit weniger unnötigen Weitstreckenübertragungen und bei der Planung globaler Kapazitätsplatzierung hilft.
Weitere Details finden Sie in der Dokumentation.
- Leader Slot API: https://erpc.global/en/doc/rpc/leader-slot-api/
- Validators Information API: https://erpc.global/en/doc/rpc/validators-information-api/
- ERPC Web Dashboard: https://dashboard.erpc.global/en
Nachrichten
