ERPC stellt in allen Regionen vollständigen historischen Datenzugriff für Solana-RPC bereit – lückenloser Abruf durch die Old-Faithful-Integration

ERPC, betrieben von ELSOUL LABO B.V. (Hauptsitz: Amsterdam, Niederlande; CEO: Fumitake Kawasaki), gibt gemeinsam mit Validators DAO die offizielle Verfügbarkeit des historischen Datenzugriffs für Solana-RPC bekannt.

Am Endpunkt edge.erpc.global stellt das Solana-RPC von ERPC historische Daten über History Access bereit. Nutzer mit dem Free-Plan, mit anderen kostenlosen Kontingenten oder mit einem kostenpflichtigen Plan fordern History Access für ältere Blöcke und Transaktionen an, indem sie history=true an die URL edge.erpc.global anhängen.

Diese Erweiterung wird durch die Integration von Old Faithful in die RPC-Infrastruktur von ERPC ermöglicht – einer Open-Source-Technologie, die speziell für das Solana-Archiv und die Verteilung historischer Daten entwickelt wurde.

Auf Solana werden pro Epoche etwa 500 GB Daten erzeugt, wobei eine Epoche typischerweise ein bis zwei Tage umfasst. Dieses Datenvolumen wächst von Jahr zu Jahr weiter und stellt hohe Anforderungen an die Speicherkapazität und die I/O-Leistung von RPC-Knoten.

Um Leistung und Betriebsstabilität aufrechtzuerhalten, speichern die meisten Standard-RPC-Knoten nur eine begrenzte Anzahl der jüngsten Epochen. In vielen Fällen können Konfigurationen mit etwa 4 TB Speicher nur Daten aus drei bis vier Epochen halten, was ungefähr einer Woche Historie entspricht. Daher führen Versuche, ältere Blöcke, Transaktionen oder Kontozustände abzurufen, häufig zu fehlenden oder unvollständigen Antworten.

Diese Einschränkungen stellen seit Langem eine praktische Herausforderung für Anwendungsfälle dar, die auf historische Daten angewiesen sind, darunter On-Chain-Analysen, Langzeit-Verhaltensanalysen, Backtesting, Auditing und Forschung.

Traditionell gilt der Betrieb eines Archivknotens als wichtigste Methode für den Zugriff auf die vollständige Ledger-Historie von Solana. Dieser Ansatz erfordert jedoch eine massive Datenreplikation, eine lange Erstsynchronisierung und dauerhaft hohe Betriebskosten.

Archivkonfigurationen auf Basis von Google Cloud Bigtable verursachen insbesondere bei der Bereitstellung erhebliche Datenmigrationskosten und weiterhin hohe Betriebskosten. Für viele Entwickler und Organisationen macht dies solche Lösungen unpraktisch. Darüber hinaus hat die starke Abhängigkeit von einem einzelnen Cloud-Anbieter Bedenken aufgeworfen, da Dezentralisierung ein grundlegendes Prinzip von Blockchain-Systemen ist.

Old Faithful ist eine Open-Source-Archiv-Infrastruktur, die diese Herausforderungen im Solana-Ökosystem adressiert. Sie erzeugt historische Archive im Format Content Addressable Archives (CAR) aus RocksDB-Archiven, die von Solana-Warehouse-Knoten erstellt wurden, und stellt sie bereit.

Im CAR-Format werden jede Epoche, jeder Block, jede Transaktion und jeder Shred eindeutig durch einen Content-Hash identifiziert. Dadurch sind überprüfbare Integritätsprüfungen möglich, sodass Nutzer bestätigen können, dass abgerufene Daten nicht manipuliert wurden – auch wenn sie aus nicht vertrauenswürdigen Verteilungsquellen stammen.

Old Faithful ist darauf ausgelegt, die vollständige Ledger-Historie von Solana von der Genesis bis zur Gegenwart zu verarbeiten, und unterstützt zahlreiche Verteilungsmethoden, darunter HTTP, CDNs und verteilte Speichersysteme.

Durch die Integration von Old Faithful in seine Solana-RPC-Infrastruktur ermöglicht ERPC den historischen Datenzugriff über die bestehende Solana-RPC-Schnittstelle. Historische Daten werden über denselben Endpunkt edge.erpc.global und dieselben Solana-RPC-Methoden bereitgestellt wie aktuelle Daten; eine Anfrage fordert History Access an, indem sie history=true an die Endpunkt-URL anhängt.

Dieses Upgrade wurde einheitlich auf alle ERPC-Regionen angewendet und gewährleistet eine konsistente Verfügbarkeit historischer Daten unabhängig vom geografischen Standort. Auch bei global verteilten Bereitstellungen können sich Nutzer in allen Regionen auf dieselbe historische Datenabdeckung verlassen.

Aufgrund des naturgemäß großen Umfangs historischer Daten kann die Ausführung bestimmter Abfragen im Vergleich zu Abfragen für die neuesten Daten länger dauern. Dieses Verhalten spiegelt die strukturellen Eigenschaften des Zugriffs auf historische Daten wider und weist weder auf Systemfehler noch auf eine Leistungsminderung hin.

ERPC forscht und entwickelt weiterhin an der Verbesserung der Antwortzeiten beim Abruf historischer Daten, einschließlich der Bewertung von Konfigurationen mit NVMe-Speicher der nächsten Generation und hoher Kapazität. Schrittweise Optimierungen werden auf Grundlage der im praktischen Betrieb gewonnenen Erkenntnisse eingeführt.

Mit diesem Upgrade unterstützt ERPCs Solana-RPC ein breiteres Anwendungsspektrum über Echtzeitanwendungen hinaus. Langfristige Analysen, historische Überprüfungen, Forschung, Auditing und die Analyse des Anwendungsverhaltens können nun ohne zusätzliche Infrastruktur durchgeführt werden.

Die Bereitstellung des Zugriffs auf historische Daten als natürliche Erweiterung der Standard-RPC-Nutzung erweitert die praktische Einsatzmöglichkeit der Solana-RPC-Dienste von ERPC erheblich.

Um ältere Blöcke und Transaktionen zu lesen, ist history=true an die Endpunkt-URL edge.erpc.global einer HTTP-Anfrage anzuhängen. Mit Ausnahme von getTransactionsForAddress wird eine Anfrage ohne history=true aus dem jüngsten Bereich beantwortet, den jeder Knoten vorhält.

Eine HTTP-Anfrage kann den API key in der URL übergeben:

https://edge.erpc.global?api-key=<YOUR_API_KEY>&history=true

https://edge.erpc.global?api-key=<YOUR_API_KEY>&history=true

Oder der API key steht in einem Authorization-Header, mit history=true in der URL:

https://edge.erpc.global?history=true

https://edge.erpc.global?history=true

Der Header ist Authorization: Bearer <YOUR_API_KEY>.

ERPC-RPC-Dokumentation: https://erpc.global/de/doc/rpc/general/

Mit Ausnahme von getTransactionsForAddress im Modus "full" kostet ein Aufruf, der über History Access beantwortet wird, 640 Tokens mehr als der reguläre Preis seiner Methode, und ein Aufruf, der aus dem jüngsten Bereich beantwortet wird, den jeder Knoten vorhält, behält seinen regulären Preis, auch mit history=true. getTransactionsForAddress im Modus "full" kostet den regulären Preis plus 640 Tokens für jede abgerufene Transaktion, aktuell oder alt. Kostenlose Kontingente, einschließlich des Kontingents des Free-Plans, haben ein Limit für History Access.

Eine Abfrage historischer Daten kann deutlich länger dauern als eine reguläre Anfrage, in manchen Fällen Sekunden. ERPC bietet History Access als eigene Option an, die Abfragen historischer Daten von regulären Anfragen getrennt hält, damit reguläre Anfragen schnell bleiben.

Nutzer können ihren ERPC API key im ERPC Web Dashboard abrufen und prüfen.

Offizieller Validators DAO Discord: https://discord.gg/C7ZQSr CkYR
Offizielle ERPC-Website: https://erpc.global/de