Für Solana-App-Performance: Wer selbst 20 ms sparen will, braucht Dedicated RPC-Endpunkte + SWQoS

Für Solana-App-Performance: Wer selbst 20 ms sparen will, braucht Dedicated RPC-Endpunkte + SWQoS

Für Solana-App-Performance: Wer selbst 20 ms sparen will, braucht Dedicated RPC-Endpunkte + SWQoS
Bei High-Frequency-Trading und unternehmenskritischen Solana-Anwendungen können selbst 20 ms den Ausschlag geben. Dedicated RPC-Endpunkte und Shared RPC-Endpunkte unterscheiden sich grundlegend in ihrem Design; diese 20-ms-Lücke lässt sich bei Shared Endpunkte nicht vollständig schließen. Dieser Artikel erklärt, warum das so ist und wie ERPC das Problem End-to-End 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 Shared Endpunkte nicht möglich ist

Man könnte fragen: „Warum erlaubt man http dann nicht einfach auf Shared Endpunkte?“ 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, Paketmitschnitten und sogar dem Diebstahl signierter Transaktionen ausgesetzt. Ein Angreifer, der denselben Shared Endpunkt nutzt, könnte Transaktionen realistisch manipulieren oder erneut einspielen.
Aus diesem Grund müssen Shared Endpunkte immer TLS/SSL erzwingen. Unsere Shared 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 erlauben.
Das Ergebnis ist eine garantierte Reduktion um 20 ms. Unabhängig von Nutzerlast oder Angriffsrisiken stellt dieser strukturelle Unterschied sicher, dass die 20-ms-Lücke zwischen Shared und Dedicated Endpunkte nicht ü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-%-Lane beschränkt. Das bedeutet: Selbst wenn ein Paket schnell ankommt, muss es mit deutlich niedrigeren Inclusion Rates rechnen.
Dedicated RPC zu nutzen, um 20 ms zu sparen, ist wichtig. Die Kombination mit SWQoS ist jedoch entscheidend, um sowohl Geschwindigkeit als auch Transaktionserfolg 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-NFT-Kartenspiel auf Solana, 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.