Für bessere Solana-App-Performance: 20 ms sparen mit Dedicated RPC-Endpunkten und SWQoS

Für bessere Solana-App-Performance: 20 ms sparen mit Dedicated RPC-Endpunkten und SWQoS

Für bessere Solana-App-Performance: 20 ms sparen mit Dedicated RPC-Endpunkten und SWQoS
Beim Hochfrequenzhandel und bei unternehmenskritischen Solana-Anwendungen können selbst 20 ms den Ausschlag geben. Dedicated RPC-Endpunkte und gemeinsam genutzte RPC-Endpunkte unterscheiden sich grundlegend in ihrem Design, und diese Lücke von 20 ms kann niemals geschlossen werden. Dieser Artikel erklärt, warum das so ist und wie ERPC das Problem von Anfang bis Ende löst.

20 ms sparen durch http statt https

Vielleicht ist Ihnen aufgefallen, dass RPC-Endpunkt-URLs normalerweise mit https beginnen. Das „s“ steht für TLS/SSL-Verschlüsselung, die die Kommunikation absichert. Diese Verschlüsselung erfordert jedoch einen Handshake sowie laufende Ver- und Entschlüsselung und fügt dadurch rund 20 ms Latenz pro Anfrage hinzu.
Wenn RPC-Kommunikation also über http statt https läuft, lässt sich dieser Overhead an der Wurzel vermeiden. In Solana, wo Blockauktionen in ungefähr 50 ms entschieden werden, ist dieser Unterschied kritisch.

Warum http bei gemeinsam genutzten Endpunkten nicht möglich ist

Man könnte fragen: „Warum erlaubt man http dann nicht einfach bei gemeinsam genutzten Endpunkten?“ Die Antwort ist schlicht: Das ist nicht möglich.
Http in einer gemeinsam genutzten Umgebung würde unverschlüsselte Kommunikation bedeuten. Transaktionen wären dadurch Man-in-the-Middle-Angriffen, dem Abfangen von Paketen und sogar dem Diebstahl signierter Transaktionen ausgesetzt. Ein Angreifer, der denselben gemeinsam genutzten Endpunkt verwendet, könnte Ihre Transaktionen realistisch manipulieren oder erneut abspielen.
Aus diesem Grund müssen gemeinsam genutzte Endpunkte immer TLS/SSL erzwingen. Unsere gemeinsam genutzten RPC-Endpunkte sind innerhalb dieser Einschränkung auf maximale Geschwindigkeit ausgelegt, aber der TLS-Overhead von etwa 20 ms lässt sich dort konstruktionsbedingt nicht entfernen.

Wie Dedicated RPC die 20 ms eliminiert

Dedicated RPC-Endpunkte beschränken den Zugriff auf bestimmte vertrauenswürdige Clients. Dadurch können wir die TLS-Pflicht entfernen und direkte http-Kommunikation ermöglichen.
Das Ergebnis ist eine garantierte Reduktion um 20 ms. Unabhängig von der Nutzerlast oder den Angriffsrisiken stellt dieser strukturelle Unterschied sicher, dass die 20-ms-Lücke zwischen gemeinsam genutzten und dedizierten Endpunkten niemals überbrückt werden kann.

Die verbleibende Herausforderung: SWQoS

Geschwindigkeit allein reicht nicht aus. Solana setzt Stake-weighted QoS (SWQoS) durch. Knoten ohne stakebasiertes Vertrauen sind dabei auf nur 20 % der verfügbaren Transaktionsbahnen beschränkt.
Lite-RPC-Designs, die Transaktionen direkt an den aktuellen Leader-Validator senden, können beispielsweise schnell wirken. Ohne SWQoS bleiben sie jedoch auf diese 20-%-Transaktionsspur beschränkt. Das bedeutet: Selbst wenn ein Paket schnell ankommt, ist seine Aufnahmerate deutlich niedriger.
Dedicated RPC zu nutzen, um 20 ms zu sparen, ist wichtig. Die Kombination mit SWQoS ist jedoch entscheidend, um sowohl Geschwindigkeit als auch erfolgreiche Transaktionen zu erreichen.
ERPC bietet eine Option, SWQoS auf Dedicated RPC-Endpunkten zu aktivieren.
Damit können Sie Dedicated RPC + SWQoS kombinieren, um sowohl geringere Latenz als auch höhere Erfolgsraten zu erreichen.
Solana RPC Price

Die Probleme, die Validators DAO und ERPC lösen

ERPC löst folgende Probleme:
  • Transaktionsfehler und Latenzschwankungen in RPC-Umgebungen
  • Leistungsdrosselung durch viele Infrastrukturanbieter
  • Starker Einfluss der Netzwerkdistanz auf die Kommunikationsqualität
  • Begrenzter Zugang zu hochwertiger Infrastruktur für kleinere Projekte
Bei der Entwicklung von Epics DAO, einem Open-Source-Projekt für Beiträge zum Solana-Ökosystem, standen wir vor der Schwierigkeit, eine wirklich leistungsfähige Solana-Entwicklungsumgebung mit niedriger Latenz aufzubauen. Diese Herausforderung führte dazu, dass wir unsere eigene Plattform entwickelten. Auf dieser Grundlage stellen wir heute ERPC und SLV bereit.
Finanzielle und andere unternehmenskritische Anwendungen reagieren besonders empfindlich auf Latenz und Fehler, weil diese direkt die Nutzererfahrung beeinflussen. Solana-Umgebungen sind hochkomplex. Anders als in der traditionellen Internet-Finanzinfrastruktur sind Validatoren weltweit verteilt. Zusammen mit der zusätzlichen Web3-Komplexität macht es das Entwicklern schwer, das Gesamtbild vollständig zu erfassen, was Optimierungen häufig verlangsamt.
Durch leistungsfähige Solana-Infrastruktur wollen wir diese Hürden senken und die Nutzererfahrung im gesamten Ökosystem verbessern. ERPC und unser Open-Source-Projekt SLV sind beide zentrale Bestandteile dieser Mission.