Lokale Caching-Datenbank für schnellen Abruf

Ich arbeite derzeit an dApps für eine private Blockchain auf Basis von Ethereum. Während es gut funktioniert und die dApps wirklich die Leistungsfähigkeit der Blockchain zeigen, fehlt es ihr an der Geschwindigkeit und Vielseitigkeit einer SQL-Datenbank. (Ich weiß, dass ich Blockchain kenne! = Datenbank).

Ein Beispiel, wo es fehlt, ist das Erhalten spezifischer Daten. Da Sie keine SQL-ähnlichen Abfragen haben, müssen Sie viele Daten durchlaufen. Oder wenn Sie ein Array einer Struktur haben, die Sie zurückhaben möchten, stellt dies ebenfalls ein Problem dar.

Also dachte ich über einen Caching-Mechanismus nach, um Daten, die vom Netzwerk überprüft werden, in einer lokalen Datenbank für schnelle Abfragen zwischenzuspeichern.

Google hat bei der Suche danach versagt, also meine Frage, gibt es so etwas wirklich nicht? Wenn es nicht existiert, was muss ich beachten, wenn ich selbst ein System wie dieses entwerfen möchte.

Antworten (1)

Eine zweiteilige Antwort.

"you need to loop" : Das fällt mir gerade auf und verdient einen Kommentar. Smart Contracts geben Ihnen keinen indizierten Speicher, aber das bedeutet nicht, dass ein Vertrag unorganisierte Daten durchlaufen sollte. Tatsächlich dürfen Verträge keine unbegrenzten Mengen durchlaufen. Stattdessen bedeutet dies, dass Verträge für die interne Organisation der Daten verantwortlich sind. Organisieren Sie Zeiger/Indizes, um den wahlfreien Zugriff und die Interaktion nach Bedarf zu unterstützen. Einige Beispiele hier. Siehe Mapped Struct with Index: Gibt es gut gelöste und einfache Speichermuster für Solidity?

Verträge dürfen Zeilen/Instanzen nicht durchlaufen, da dies tendenziell zu steigenden Transaktionskosten führt. Mehr Hin- und Rückfahrten = höhere Kosten. Am Blockgaslimit schlagen alle Transaktionen fehl . Nicht gut.

DB-Cache : Es ist vollkommen gültig, eine Off-Chain-Datenbank zu erstellen, die an eine On-Chain-Quelle gebunden ist. Die On-Chain-Quelle wird normalerweise als maßgebend angesehen. Wenn Sie der Praxis folgen, dass alle signifikanten Statusänderungen von einem ausgegebenen Ereignis begleitet werden sollten, kann ein Server auf Erstellungs-, Aktualisierungs- und Löschvorgänge lauschen. Wenn dies sorgfältig durchgeführt wird, sollte es möglich sein, eine leere Datenbank zu booten und den gesamten Statusverlauf des Vertrags neu zu erstellen – die Datenbank sollte den Live-Status einholen.

Seiten wie etherscan.io und Börsen verwenden ähnliche Ansätze. Besucher "schlagen" aus Leistungsgründen wirklich auf Datenbanken und nicht auf die eigentliche Blockchain.

Ich hoffe es hilft.

Out of the Loop war vielleicht der falsche Ausdruck, da Sie sagten, dass Looping etwas ist, was Sie wirklich nicht tun sollten. Die Frage bezieht sich eher darauf, ob Off-Chain-Caching etwas ist, das Sie tun sollten, und wenn ja, wie Sie dies angehen würden / oder ob es bereits ein Tool für die Ethereum-Blockchain gibt.
"Ein Server kann auf Erstellungs-, Aktualisierungs- und Löschvorgänge lauschen". Ereignisemitter sind ein wirklich wichtiges Merkmal von Smart Contracts, die es Parteien außerhalb der Blockchain ermöglichen, auf Ereignisse zu „lauschen“ oder sogar vergangene Ereignisse der Reihe nach wiederzugeben. Dies ist möglich, da die Off-Chain-Datenbank alle Arten von Indizierungen und Optimierungen enthalten kann.
Gibt es einen generischen Weg, um die Ereignisse zu erhalten. Wie ich aus der Dokumentation richtig verstehe, können Sie den Ereignisemitter nur auf Vertragsebene festlegen, um die Daten zu erhalten. Können Sie zum Beispiel einen Ereignis-Emitter auf einen neu hinzugefügten Block setzen, der mit dem richtigen Vertrag verknüpft ist. Ich weiß, dass Ereignisse zu neuen Blöcken hinzugefügt wurden, aber das gibt Ihnen nicht die Informationen, die Ihnen ein Vertragsereignis gibt, oder?
Das sieht nach einem ziemlich guten Beispiel aus: ethereum.stackexchange.com/questions/17214/…