Hyperion 3.0 – ein EOSIO History API der Extraklasse

Lesezeit: ca. 3 Minuten

Die mit Spannung erwartete Veröffentlichung von Hyperion 3.0 ist jetzt bereit für Prime Time Action in allen EOSIO Netzwerken!

Hyperion ist eine von EOS Rio entwickelte Open-Source History API, die vor einem Jahr entwickelt wurde als Lösung für einen erheblichen Engpass bei EOS History. Seitdem haben mehr als 12 Teams EOS Rio geholfen, Hyperion weiter zu verbessern, um es weiterhin an die aktuellen und sich ständig weiterentwickelnden Bedürfnisse der Community anzupassen.

Laut dem Team ist „das EOS Mainnet die mit Abstand anspruchsvollste Datenumgebung im Blockchain-Bereich“, und Hyperion ist darauf ausgelegt, damit umgehen zu können. Hyperion ist auch verfügbar für Entwickler in anderen EOSIO-Netzwerken wie BOS, Worbli, Ultra und anderen. 

Zu den neuen Funktionen in Hyperion 3.0 gehören:

  • Streaming
  • API-Polyfills für v1
  • Modularisierte Parser
  • Ein integrierter Lightweight Explorer
  • Erweitertes Filtern und Sortieren von Queries
  • Verbesserte Performance
  • Verbesserte Dokumentation
  • Vollständige Projektkonvertierung in Typescript
  • Installationsskript
  • Hyperion Docker

Die Welt vor Hyperion

dApps, Block Explorer und Wallets müssen Informationen zur Blockchain History (Transaktionsverlauf) lesen, um ordnungsgemäß zu funktionieren und um den Service zu bieten den die Token Inhaber wünschen. Dies erfolgt durch ein Abfragen der API eines EOS Mainnet Full History Node Anbieters. Full History bedeutet den vollständigen Verlauf aller Transaktionen die bisher auf der EOS Blockchain festgehalten worden. Für ein reibungsloses Benutzererlebnis wird all dies vom Benutzer wegabstrahiert und läuft nahtlos im Backend. Die Verfügbarkeit hochwertiger API-Dienste mit geringer Latenz ist somit für die Entwicklung eines jeden Blockchain-Ökosystems von entscheidender Bedeutung. Das Ausführen solcher (Full History) Nodes wurde jedoch mit der Zeit und wachsenden Datenmenge immer teurer, komplexer und zeitaufwändiger.

Schwierigkeiten bei der Bereitstellung von zuverlässiger und nachhaltiger historischer Blockchain Daten können die Fähigkeit von EOS beeinträchtigen, die Erwartung die wir in die Skalierbarkeit von EOS haben zu erfüllen. Vor diesem Hintergrund machte sich das EOS Rio-Team Anfang 2019 daran, zu analysieren, wie der History Service im EOS Mainnet optimiert werden kann. Sie stellten schnell fest, dass in der veralteten History-API v1 viele für den End-Benutzer überflüssige Informationen gespeichert wurden, wie z. B. Inline-Action Traces, die in die Root-Action eingebettet sind. Dies führte dazu, dass eine übermäßige Datenmenge gespeichert und übertragen wurde, wenn ein Benutzer den Aktionsverlauf für einen bestimmten Account angefordert hatte.

Die Geburtsstunde der Hyperion History

Hyperion History hat einen neuen Ansatz für die Datenstruktur und -speicherung implementiert:

  1. Aktionen, die in einem reduzierten Format gespeichert sind;
  2. Ein Parent Feld wurde zu den Inline-Aktionen hinzugefügt, um auf die übergeordnete globale Sequenz zu verweisen.
  3. Wenn Inline-Aktionsdaten mit den übergeordneten Daten identisch sind, werden sie als Benachrichtigung betrachtet und somit aus der Datenbank entfernt.
  4. Es werden keine Blöcke oder Transaktionsdaten gespeichert, alle Informationen werden aus Aktionen rekonstruiert. und,
  5. Es werden keine Informationen zur Validierung von Transaktionen gespeichert, da bereits alle Informationen in den Blockinformationen mithilfe der Chain-API überprüft werden können.

Bei dem oben genannten Ansatz konzentrierte sich das API-Format auf kürzere Antwortzeiten, geringeren Bandbreitenaufwand und bessere Benutzerfreundlichkeit für UI / UX-Entwickler. Die optimierte Datenstruktur, die als Elasticsearch-Cluster bereitgestellt wird, reduziert desweiteren auch den CPU- und Bandbreitenverbrauch, wodurch die Infrastruktur skalierbarer wurde, und ermöglichte eine Reduzierung der Datenbankgröße um etwa 85%.

Um die Leistung weiter zu verbessern, entwickelten sie einen Multi-threaded-Indexer, der Daten aus dem State-History-Plugin extrahierte, schnellere Aufnahmezeiten mit der richtigen Hardwareoptimierung ermöglichte und mit dem „ABI History Caching Layer“ eine komplett neue Komponente einführte, um Deserialisierungsfehler bei Parallelität, bei der Verarbeitung historischer Daten über ABI-Änderungen, zu verhindern.

Ein weiteres Beispiel für die durch das Update gewonnenen Vorteile sind die Integrity Check Scripts , die die Datenbank kontinuierlich nach fehlenden Blöcken durchsuchen und diese automatisch reparieren. Solche Crash-Recovery-Funktionen vereinfachen die Bedienung von Hyperion, reduzieren Ausfallzeiten und Wiederholungszeiten erheblich und machen es noch zuverlässiger.

Alles in allem führte dieses Update zu einer signifikanten Reduzierung der Datenbankgröße und der Kosten für die Wartung einer Full History Node.

Hyperion 3.0 ist die Weiterentwicklung dieser wertvollen Lösung zum Speichern der History von EOSIO Blockchains. Wir empfehlen unseren Lesern den offiziellen Release Artikel zu lesen, um mehr über die neuen Funktionen zu erfahren. Und wer einen tieferen technischen Einblick haben möchte, kann sich auch das Release-Tag auf GitHub ansehen, sowie durch die überarbeitete Dokumentation browsen.

Vielen Dank an EOS Rio für dieses herausragende Werkzeug.

Schreiben Sie einen Kommentar

Share on telegram
Telegram
Share on reddit
Reddit
Share on whatsapp
WhatsApp
Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn
Share on pocket
Pocket

Erfahren Sie mehr:

Zurück