SOC 2 Typ II-zertifiziert · ISO 27001

Solana Entwickler stoßen auf Hindernisse, wenn sie Methoden verwenden, die große Datenmengen zurückgeben oder das Durchsuchen des gesamten Kontosatzes erfordern. getProgramAccounts wird gedrosselt oder deaktiviert. getLargestAccounts kehrt nie zurück. Die Ursache liegt in der Systemarchitektur. Agave-RPC-Knoten sind auf Schreibvorgänge optimierte Systeme, und die Drosselung ressourcenintensiver Lesevorgänge ist eine Notwendigkeit, keine strategische Entscheidung. Anwendungen gleichen dies letztendlich durch Wiederholungslogik, Caching-Ebenen und Abfrageintervalle aus, die ausschließlich dazu dienen, die infrastrukturellen Einschränkungen ihres Blockchain-Anbieters zu umgehen.

Während sich das gesamte Ökosystem nun langsam mit diesem Problem auseinandersetzt, hat Quicknode bereits die Leseebene entwickelt, die das Ökosystem von Solana tatsächlich benötigt. Zwei Jahre iterative Arbeit, eine speziell entwickelte In-Memory-Architektur und Ergebnisse, die 10- bis über 1000-mal schneller sind als die Standardwerte von Agave.

Wenn Sie Kunde von „ Quicknode “ sind, müssen Sie diese Vorteile nicht extra aktivieren. Ihr „ endpoint “ stellt sie Ihnen bereits zur Verfügung.

Das strukturelle Problem mit der Leseschicht von „ Solana “

Agave-RPC-Knoten sind darauf ausgelegt, Transaktionen zu verarbeiten, einen Konsens zu erzielen und das Ledger fortzuschreiben. Der von ihnen verwaltete Kontostatus ist ein Nebenprodukt dieses Prozesses und kein für Lesevorgänge optimierter Speicher. Es gibt keinen Abfrageplaner, keine nativen Sekundärindizes und keine Trennung zwischen Lese- und Schreib-E/A.

Eine Skalierung der Hardware löst dieses Problem nicht. Leseabfragen und Konsensbildung konkurrieren auf demselben Rechner um dieselbe CPU, sodass mehr Hardware zwar mit Kosten auf Validator-Niveau verbunden ist (768 GB RAM, schnelles NVMe, Netzwerk mit hoher Bandbreite), die Konkurrenzsituation jedoch nicht beseitigt wird.

Das Hinzufügen weiterer RPC-Knoten verschärft das Problem: Zusätzliche Knoten belasten die Gossip- und Turbine-Netzwerke von Solana und verlangsamen so die Statusweitergabe für die Validatoren, die diese tatsächlich benötigen. Die Skalierung der Leseebene über die Validator-Architektur führt zu einer aktiven Verschlechterung der Schreibebene.

Die Paginierung von Daten birgt ein Konsistenzrisiko. Wenn neue Blöcke zwischen den Seiten eintreffen, ändert sich der der Antwort zugrunde liegende Kontostand während des Lesevorgangs. Anwendungen, die große Ergebnismengen durchlaufen, erhalten Daten, die sich verschoben haben, bevor sie den Lesevorgang abgeschlossen haben.

Wie „ Quicknode “ eine bessere Leseebene entwickelt hat

Quicknode hat dieses Problem frühzeitig erkannt und die Lese-Workloads vom Validator getrennt, um sie über eine speziell dafür entwickelte Infrastruktur bereitzustellen. Die Architektur, die heute den Datenverkehr abwickelt, ist die dritte Iteration dieser Bemühungen. Mit jeder Iteration wurde man näher an die Daten herangeführt und Abstraktionsschichten entfernt, die Latenz verursachten, ohne einen Mehrwert zu bieten – und diese Arbeit wird fortgesetzt.

Iteration 1: Relationale Datenbanken

Die erste Iteration folgte dem herkömmlichen Ansatz: Kontostände und Hauptbuchdaten wurden in eine relationale Datenbank geleitet, Indizes erstellt und Abfragen daran durchgeführt. Damit war das Problem der Ressourcenkonflikte sofort gelöst. Die Validatoren konnten sich auf den Konsens konzentrieren, während ein separates System die Lesevorgänge übernahm. Relationale Datenbanken verursachen jedoch einen Overhead, der bei der Größenordnung von Solana ins Gewicht fällt: Abfrageplanung, Zeilensperren, die Verwaltung von Write-Ahead-Logging, Autovacuum und die inhärente Latenz von festplattenbasiertem Speicher. Bei einer Blockchain, die alle 400 Millisekunden Blöcke erzeugt, summiert sich jede Mikrosekunde Lese-Latenz über Millionen von täglichen Anfragen. Als der Datenverkehr von Solana zunahm, wurde die Festplatten-E/A zur nächsten Hürde, die es zu überwinden galt.

Iteration 2: Spezialisierte Hochleistungsdatenbanken

Die nächste Iteration begann mit dem Schema selbst. Das „ equipe “ vereinfachte und denormalisierte das Datenmodell, um es an die tatsächlichen Zugriffsmuster von Solana anzupassen, und verzichtete dabei auf die relationale Struktur, die sich nicht mehr bezahlt machte. Diese Umgestaltung ermöglichte den Umstieg auf eine leistungsstarke NoSQL-Datenbank, die für schreibintensive Dateneingaben und Punktabfragen mit geringer Latenz ausgelegt ist – ohne den Overhead durch Abfrageplanung, Zeilensperren und Write-Ahead, der mit dem relationalen Ansatz einherging.

Sowohl der Durchsatz als auch die Latenz haben sich spürbar verbessert, und die betrieblichen Probleme, die mit dem Betrieb eines relationalen Systems in großem Maßstab einhergingen (Autovacuum-Blockaden, Spitzen bei Sperrkonflikten, WAL-Aufblähung), sind verschwunden.

Iteration 3: Vollständig im Arbeitsspeicher basierende Architektur

Die Motivation für den nächsten Schritt war eine andere. Festplattenbasierte Systeme stoßen, egal wie gut sie auch optimiert sein mögen, an eine harte Grenze: Jeder Lesevorgang greift letztendlich auf ein Speichermedium zu, das um Größenordnungen langsamer ist als der Arbeitsspeicher. Um diese Grenze zu überwinden, musste der Lesepfad selbst die Festplatte hinter sich lassen.

Die aktuelle Architektur eliminiert Festplatten vollständig aus dem Lesepfad. Der Zustand der AccountsDB wird im Arbeitsspeicher gehalten und durch speziell für die spezifischen Abfragemuster von Solana entwickelte Datenstrukturen indiziert. Es gibt keinen Abfrageplaner, keine B-Baum-Durchlauf und keine Fehlgriffe im Seiten-Cache: lediglich direkten Speicherzugriff auf vorab indizierte Daten.

Die Umstellung auf eine vollständig im Arbeitsspeicher basierende Architektur war eine bewusste Entscheidung, um ein einziges Ziel zu optimieren: die reine Leseleistung.

Der LedgerDB-Cache (der die historischen Daten aller Blöcke, Transaktionen und Metadaten jedes Slots speichert) folgt derselben Designphilosophie, weist jedoch eine andere Speicherstrategie auf. Das Ledger von Solana ist zu groß, um vollständig in den Arbeitsspeicher zu passen, weshalb ein mehrstufiges Design zum Einsatz kommt: Die Daten am Ende der Blockchain (Tip-of-Chain) bleiben im Arbeitsspeicher, während historische Daten aus einer hochleistungsfähigen, verteilten Datenbank bereitgestellt werden, die speziell auf diese Arbeitslast optimiert ist.

So funktioniert es: Der In-Memory-Cache von „ Quicknode “

QuicknodeDer „ Solana -Cache“ ist eine einzelne, in sich geschlossene Binärdatei, die alle „Tip-of-Chain“-Methoden ohne externe Abhängigkeiten bereitstellt. Lediglich bei Abfragen des historischen Ledgers wird auf eine externe Datenbank zugegriffen.

Der Cache der AccountsDB (der den aktuellen Status jedes Kontos speichert) befindet sich vollständig im Arbeitsspeicher, und die Designentscheidungen, die für seine Schnelligkeit sorgen, sind kein Zufall. Vier Mechanismen wirken zusammen, um jede vermeidbare Latenzquelle auf den Lese- und Schreibpfaden zu beseitigen.

Der Kette voraus

Die Aktualität der Daten ist eine Leistungseigenschaft, die bereits vor dem Eintreffen einer Leseanfrage beginnt. Der Cache bezieht Daten direkt aus einer Shred-Stream-Datenquelle und erhält Kontoaktualisierungen 200–400 ms früher, als sie auf einem typischen Agave-RPC-Knoten erscheinen würden, der auf vollständig gebildete Blöcke wartet. Diese Aktualisierungen gelangen über einen Schreibpfad mit geringer Latenz (In-Memory-Schreibvorgänge mit einem lock-freien „ near “-Design) in den Cache, sodass der Vorsprung durchgehend erhalten bleibt und nicht durch den Overhead bei der Datenaufnahme aufgezehrt wird.

Der kombinierte Effekt lässt sich an der Spitze messen: Im Produktionsbetrieb liegt der aktuellste beobachtbare Slot des Caches durchweg 1–2 Slots vor einem vergleichbar konfigurierten Agave-RPC-Knoten. Bei Workloads, bei denen es um die Frage „Wie ist der aktuelle Zustand?“ geht – beispielsweise bei Handelssystemen, MEV, Liquidations-Engines und Echtzeit-Dashboards –, macht dies den Unterschied aus, ob auf den aktuellen Zustand reagiert wird oder auf Daten, die bereits veraltet sind.

Benutzerdefinierte Datenstrukturen

Die Indizes, die die Kontensuche, Token-Abfragen und die Filterung von Programmkonten ermöglichen, basieren auf Low-Level-Datenstrukturen, die anhand von Benchmarks ausgewählt wurden – nicht die allgemeinste Wahl, sondern diejenige, die bei den tatsächlich im System auftretenden Zugriffsmustern die schnellsten Ergebnisse lieferte. Der gemeinsam genutzte Zustand verwendet, wo immer möglich, nur minimale Sperren, sodass sich gleichzeitige Leser nicht gegenseitig behindern.

Auf die Hardware abgestimmt

Das System optimiert die Hardwareauslastung umfassend, indem es die Datenerfassung, Indizierung und Abfragebearbeitung auf dedizierte CPU-Kerne festlegt, um den Overhead durch Kontextwechsel zu minimieren, und indem es für jede Komponente auf der Grundlage ihrer spezifischen Zuweisungsprofile einen geeigneten Speicherzuordner auswählt, um die Fragmentierung unter Last zu reduzieren.

Vorberechnung

Soweit möglich, berechnet das System abgeleitete Ansichten im Voraus und hält sie auf dem neuesten Stand, während der Kontostatus eingelesen wird: Angebotsaggregate, sortierte Kontolisten, gefilterte Programm-Caches. Dadurch werden die CPU-Kosten vom latenzempfindlichen Lesepfad auf den durchsatzorientierten Schreibpfad verlagert. Abfragen lösen niemals Berechnungen aus. Sie lesen Ergebnisse aus, die bereits vorhanden sind. Die 17 ms getSupply Die Reaktion in den Benchmarks spiegelt diesen Mechanismus in der Praxis wider: Das Aggregat ist bereits vorhanden, wenn die Abfrage eintrifft.

getProgramAccounts: Das schwierigste Problem

getProgramAccounts Sie erfüllt eine einfach klingende Aufgabe: Sie gibt alle Konten zurück, die diesem Programm gehören und diesen Filtern entsprechen. Die Herausforderung besteht darin, dass es schwierig ist, sie gut zu indizieren. Bei dem Programm könnte es sich um eines von Tausenden von bereitgestellten Programmen handeln, von denen jedes sein eigenes Kontoschema hat.

Die Filter sind in der Regel memcmp Operationen an bestimmten Byte-Offsets, die nur dann Sinn ergeben, wenn die interne Datenstruktur des Programms bekannt ist. A memcmp Der Offset 32 hat in SPL Token eine bestimmte Bedeutung, in einem DEX-Programm jedoch eine ganz andere.

Es gibt keine allgemeingültige Indizierungsstrategie, die für alle Fälle funktioniert. Indizierung getProgramAccounts Um dies effizient zu bewerkstelligen, muss man wissen, wie die Konten der einzelnen Programme aufgebaut sind. Der Indexer von Quicknode löst dieses Problem durch das Zusammenspiel zweier Strategien:

Nativ indizierte Programme

Für eine kleine Gruppe stark frequentierter, gut bekannter Programme erstellt und pflegt Quicknode kontinuierlich dedizierte native Indizes, sobald die Konten aktualisiert werden. Dabei handelt es sich um die Programme, die den Traffic auf Solana dominieren: SPL Token (Legacy), SPL Token-2022 und das Stake-Programm.

Die Kontenstrukturen sind bekannt, die von den Kunden verwendeten Filtermuster sind bekannt, und Quicknode hat die Indizes so konzipiert, dass sie diese Besonderheiten direkt nutzen. Diese Indizes bearbeiten Abfragen in weniger als einer Millisekunde, unabhängig davon, wie viele Millionen Konten das Programm verwaltet, und sie decken den Großteil der getProgramAccounts Traffic, da sich die beliebtesten Suchanfragen auf eine kleine Anzahl von Programmen konzentrieren.

Dynamisch indizierte Programme

Für alles andere – wie jedes benutzerdefinierte DeFi-Protokoll, jedes in der vergangenen Woche bereitgestellte Programm und jeden Nischenanwendungsfall – wendet der Indexer eine dynamische Strategie an. Wenn ein Aufrufer zum ersten Mal eine Filterkombination für ein bestimmtes Programm anfordert, erstellt der Cache automatisch und im laufenden Betrieb einen neuen Index. Diese erste Anfrage wird unoptimiert ausgeführt. Der Indexer muss die Konten des Programms durchsuchen und den Index erstellen, bevor er antworten kann, sodass der Aufrufer die einmaligen Kosten für das Aufwärmen des Caches trägt. Und selbst dieser „kalte“ Durchlauf ist schneller als Agave.

Jede nachfolgende Anfrage für denselben Filter wird aus einem aktiven, inkrementell gepflegten Cache bedient, der stets auf dem neuesten Stand bleibt, sobald sich Konten in der Blockchain ändern. Aktualisierungen werden über dieselbe Streaming-Pipeline, die auch die nativ indizi flow iert, an „ “ weitergeleitet, sodass die im Cache gespeicherte Ansicht stets mit der Realität übereinstimmt.

Ab diesem Zeitpunkt ist die Latenz praktisch konstant, unabhängig von der Größe der Nutzdaten oder der Beliebtheit des Programms. Ein Filter, der zehn Konten zurückgibt, und ein Filter, der eine Million Konten zurückgibt, reagieren in derselben Größenordnung, da die Arbeit bereits erledigt ist. Die Antworten werden direkt aus dem vorab zusammengestellten Speicher gestreamt und nicht bei jeder Anfrage neu berechnet.

Neue Programme werden bereits am Tag ihrer Bereitstellung unterstützt. Es ist keine Schema-Integration, keine manuelle Konfiguration und kein Warten auf ein Technik equipe -Team erforderlich, um die Unterstützung hinzuzufügen. Der erste Client, der eine Abfrage an ein neues Programm sendet, löst die Indizierung aus, und jeder nachfolgende Client profitiert davon.

Native Indizes bieten maximale Leistung für den Großteil des realen Datenverkehrs. Der dynamische Indizierer stellt sicher, dass kein Programm und kein Filtermuster nicht unterstützt wird.

p50

p99

getProgramAccounts ist das schwierigste Problem auf der AccountsDB-Ebene, weshalb es eine eigene Optimierungsstrategie erhält. Alles andere (Punktabfragen, Aggregate, Token-Abfragen, Block- und Slot-Metadaten) wird aus demselben In-Memory-Zustand mit denselben Designprinzipien bereitgestellt: soweit möglich vorab berechnet, sperrfrei auf dem Lesepfad und in einer einzigen Abfrage statt durch einen Scan aufgelöst.

Was dies in der Produktion bewirkt

Das Ergebnis ist, dass jede AccountsDB-Methode – nicht nur die wichtigsten – unter gleichzeitiger Auslastung mit In-Memory-Geschwindigkeit ausgeführt wird. Es gibt keine unterstützte Methode, deren Leistung unter Last nachlässt, wenn der Datenverkehr zunimmt oder die Anzahl der Konten wächst.

Die folgenden Zahlen stammen aus einem Vergleich mit einem Standard-Agave-Validator im selben Netzwerk. Der Leistungsunterschied ist architektonisch bedingt und nicht auf bessere Hardware zurückzuführen.

Für einfache Punktabfragen, getAccountInfo, getBalance, und getTokenAccountBalance, Der Indexer von Quicknode erreicht bei Agave eine Geschwindigkeit von 2–4 ms. Der „Hot Path“ für diese Methoden ist ein einzelner indexierter Lesevorgang. Die Antwortzeit wird hauptsächlich durch die Netzwerk-Roundtrip-Zeit bestimmt, nicht durch die Rechenlast, die mit der Anzahl der Konten skaliert. Bei Methoden, die Aggregate, sortierte Ansichten oder Sekundärindizes erfordern, die der Validator nicht verwaltet, weichen die Leistungswerte ab.

Drei Ergebnisse stechen besonders hervor:

getTokenLargestAccounts Bei USDC: Agave benötigt fast 100 Sekunden. Bei jeder Anfrage muss der Validator das gesamte SPL-Token-Programm durchlaufen, nach Mint filtern, sortieren und die Top 20 zurückgeben – ohne zwischengespeicherte Ergebnisse und ohne sortierten Index. Der Indexer von Quicknode verwaltet eine nach Mint sortierte Menge, die bei Änderungen der Guthaben schrittweise aktualisiert wird.

getLargestAccounts wird auf Agave nicht innerhalb von fünf Minuten abgeschlossen. Der Validator berechnet bei jeder Anfrage von Grund auf ein sortiertes Aggregat über den gesamten Kontensatz neu. Der Indexer von Quicknode verwaltet dies als laufenden Index.

getTokenAccountsByDelegate wird auf Agave nicht unterstützt. Der Indexer von Quicknode liefert die Ergebnisse in Millisekunden im einstelligen Bereich.

Die Latenzwerte geben Aufschluss über die Geschwindigkeit einzelner Anfragen. Das Bild hinsichtlich der Parallelität sieht anders aus und ist ebenso wichtig. Wenn eine einzelne Agave getTokenLargestAccounts Die Abfrage dauert 97 Sekunden; diese Anfrage blockiert einen Server-Slot und verzögert alle nachfolgenden Abfragen: Eine langsame Anfrage führt zu Latenzspitzen bei allen gleichzeitig aktiven Aufrufern.

QuicknodeDer Indexer von mode weist diesen Fehler nicht auf. Jede Abfrage wird aus einem vorab erstellten In-Memory-Index bedient, sodass keine einzelne Anfrage so lange läuft, dass der gleichzeitige Datenverkehr dadurch beeinträchtigt wird. Unter anhaltender Last bedient der AccountsDB-Cache Zehntausende von Anfragen pro Sekunde und hält dabei die P50-Latenz unter 10 ms, wobei der Durchsatz eher durch die Hardwarekapazität als durch die Größe der Kontogruppe oder die Komplexität der Abfrage begrenzt wird.

Nicht jede Methode liegt unter 10 ms. „Kaltanfragen“ an Programme außerhalb des nativ indizierten Satzes verursachen beim ersten Aufruf Initialisierungskosten von 11 bis 40 Sekunden, während das Abonnement eingerichtet und der gefilterte Cache gefüllt wird. Jede nachfolgende Anfrage an denselben Filter wird aus einem „warmen“ Cache im Arbeitsspeicher bedient.

Abfragen im Stake-Programm in großem Maßstab veranschaulichen den mittleren Bereich. Die 81.000 Stake-Konten von Marinade werden auf dem Indexer von Quicknode in etwa einer Sekunde abgefragt, auf Agave hingegen in 6,7 Sekunden. Die Indexsuche bleibt schnell, doch das Zusammenstellen und Serialisieren einer Antwort bei diesem Volumen ist mit einem erheblichen CPU-Aufwand verbunden.

Bei Anfragen in der Größenordnung von Raydium V4 (~705.000 Konten, ~869 MB JSON) stößt das System an eine andere Grenze: Die Zeit bis zum ersten Byte beträgt 1,5 Sekunden, und die vollständige Übertragung dauert noch länger, da sie durch die physikalischen Gegebenheiten der Übertragung von 869 MB über eine Leitung begrenzt ist.

Die Leistungssteigerungen sind durchweg enorm. Jede Methode läuft 10- bis 1000-mal schneller als ein Standard-Agave-Validator. In Lasttests mit einer einzigen Methode bewältigt eine einzelne Instanz 350.000 getTransaction Anfragen pro Sekunde bei einer Latenz von unter 40 ms und 120.000 getAccountInfo Anfragen pro Sekunde bei einem P50-Wert von unter 20 ms.

Zusammen decken die Caches von AccountsDB und LedgerDB etwa 95 % des RPC-Datenverkehrs in der Produktionsumgebung und etwa 90 % der JSON-RPC-Spezifikation „ Solana “ ab.

Das ist noch nicht das Ziel

Was heute existiert, ist das Ergebnis einer zweijährigen Entwicklungsphase. Es handelt sich dabei nicht um den Endzustand. Quicknode investiert kontinuierlich in die Leseschicht von Solana. Die Architektur wird immer schneller werden, die Methodendeckung wird sich weiter ausweiten, und die Arbeit daran, die Lücke zwischen den Anforderungen der Entwickler und dem, was die Infrastruktur bietet, zu schließen, geht weiter.

Das Fazit

SolanaLese- und Schreib-Workloads stellen grundlegend unterschiedliche Herausforderungen dar. Sie erfordern grundlegend unterschiedliche Architekturen. Quicknode hat die Leseschicht, die das Ökosystem von Solana tatsächlich benötigt, von Grund auf neu entwickelt – über einen Zeitraum von zwei Jahren und ohne Kompromisse bei der Leistung. Kontinuierliche Verbesserungen dieser Infrastruktur sind keine Option, für die man sich entscheiden muss. Sie sind das, was jeder Quicknode Solana endpoint bereits bietet.

Erstellen Sie eine „ Solana “ unterendpoint auf Quicknode und beginnen Sie mit der Entwicklung auf einer Leseebene, die speziell für genau diese Arbeitslast entwickelt und kontinuierlich optimiert wurde.