Cardano-db-sync: Verwaiste Blöcke, die nicht aus der Blocktabelle entfernt wurden

Die einfachste Lösung besteht darin, Blöcke zu entfernen, die so verwaist sind.

Als Alternative zum Entfernen könnten wir sie in eine separate orphaned_blocks -Tabelle verschieben, aber dann müssen wir entscheiden, was wir mit den an diesen Block angehängten tx tun möchten. Mein anfängliches Gefühl ist, dass sie einfach ignoriert / entfernt werden sollten.

Eine orphaned_block -Tabelle kann nützlich sein, wenn wir zu Praos wechseln, kann aber auch jetzt einfach implementiert werden, wenn db-sync wirklich nur Byron unterstützt.

Mein allererster Gedanke war auch: Reinigen Sie den verwaisten Block, aber bewahren Sie ihn irgendwo auf.

Es könnte sogar eine Option für den Knoten werden, alle erkannten Gabeln einschließlich aller Blöcke vom verlassenen Seitenarm in dieser Tabelle zu speichern. Das Löschen nach x Slots ist einfach. Die Diagnose und Rückverfolgung des Geschehens ist dann viel einfacher.

Die Frage nach verlorenen TXs ist interessant. Als schnelle Idee, ohne zu wissen, ob es kryptografisch möglich und 100% sicher ist:

Wenn ein (DB-Sync-fähiger) Knoten TXs von verwaisten Blöcken erkennt, kann er versuchen, sie erneut in seinen Mempool einzufügen. Nicht weiter senden, sondern nur verarbeiten, wenn er an der Reihe ist, einen Block zu produzieren.
(Broadcast sollte nicht erforderlich sein, da viele andere Pools den verwaisten Block mit seinen TXs erkennen und von dieser Quelle aus wieder in ihren Mempool einfügen.)

Wenn der utxo-Besitzer währenddessen (bis Gabeln aufgelöst und verwaiste Blöcke erkannt wurden) einen zweiten Versuch eingereicht hat, wird die vorherige Übertragung ungültig. Wenn stattdessen der TX noch gültig ist, wird er automatisch wieder in einem neuen gültigen Block angezeigt.

Brieftaschen müssen dann in der Lage sein, mit einer Situation umzugehen, in der sie möglicherweise ihren Empfang in einem Block sehen, der dann verwaist ist, und einige Blöcke später wird derselbe Empfang in einem anderen, dann hoffentlich gültigen Block abgelegt.

Wenn ein (DB-Sync-fähiger) Knoten TXs von verwaisten Blöcken erkennt, kann er versuchen, sie erneut in seinen Mempool einzufügen. Nicht weiter senden, sondern nur verarbeiten, wenn er an der Reihe ist, einen Block zu produzieren.

Es ist wichtig zu beachten, dass db-sync von node und einfach der Kette von node folgt.
Insbesondere verwaltet db-sync keine eigene Kopie des Mempools. In dem Fall, in dem ich festgestellt habe, dass die Transaktionen im verwaisten Block mit ziemlicher Sicherheit in späteren nicht verwaisten Blöcken enthalten waren, sollten db-sync sie einfach löschen.

Die Brieftasche hat natürlich ein anderes Verhalten als db-sync .

Wenn die TXs mit ziemlicher Sicherheit von anderen Blockherstellern verarbeitet werden, müssen sie nicht mit einem Tool von db in den Mempool des Knotens "neu injiziert" werden.
Die Frage ist, ob dies bei allen Slot- / Höhenkampfvarianten der Fall ist. Wenn nicht, ist die nächste Frage, ob es nützlich (beabsichtigt) ist, einen der Knoten, die unverarbeitete TXs in einem verwaisten Block erkennen, diese basierend auf der Datenbank-Sync-Datenbank erneut in seinen Mempool einfügen zu lassen

db-sync sollte eigentlich nur verwendet werden, um zu sehen, was in der Vergangenheit passiert ist. Der Knoten selbst zieht Transaktionen aus verwaisten Blöcken und legt sie wieder in seinem eigenen Mempool ab. db-sync soll nicht Teil davon sein.

Das Verwalten einer Liste von Blöcken, die in den letzten 100 oder so Slots verwaist sind, kann jedoch zum Debuggen hilfreich sein.

Ich denke, der Block sollte beim Rollback entfernt werden, und wir sollten kaskadierende Löschvorgänge verwenden, um alles zu löschen, was logisch in den gelöschten Blöcken enthalten ist.

Es macht keinen Sinn, zurückgerollte Blöcke beizubehalten. Dies ist kein Überwachungstool zur Überwachung der Blockausbreitung innerhalb des Netzwerks. Es wird nur an einer Stelle und als Knotenclient beobachtet, daher wäre es sehr unzuverlässig, wenn es in dieser Rolle verwendet wird.

Ich bin damit einverstanden, dass wir db-sync so rein wie möglich halten, um den tatsächlichen Kettenzustand widerzuspiegeln.

Es würde jedoch mein Leben erheblich vereinfachen, wenn ALLE Blöcke es in db-sync schaffen würden und dann bei Rollbacks gelöscht würden. Auf diese Weise kann ich auf dem Postgres Löschen auslösen und mit den Daten machen was ich will.

Dies wird von anderen Clients benötigt und Sam sagt, dass es für jede Datenbank-Synchronisierungsversion, einschließlich Testnet, von entscheidender Bedeutung ist.

Es scheint, dass Rollbacks nicht wie erwartet funktionieren. Wir sehen mehrere Blöcke in der DB mit derselben Blockhöhe. Hier ist ein Beispiel (im Mainnet):

cexplorer = # SELECT * FROM block WHERE block_no = 4224831;
id | Hash | slot_no | block_no | vorherige | merkel_root | slot_leader | Größe | epoch_no | Zeit | tx_count
--------- + ------------------------------------ ---------------------------- + --------- + ---------- + ---------- + --------------------------------------- ----------------------------- + ------------- + ------ + ---------- + --------------------- + ----------
4225044 | \ x941a71094c7b10243845a82e53dc45959d8fde5f6d87e463efe660aa9611b965 | 4226979 | 4224831 | 4225043 | \ x95549f5fcfc370eb4b24c981a6053f909bdef6418ce896828c6be18fa31ab406 | 6 | 1731 | 195 | 2020-05-29 08:57:51 | 3
4225045 | \ x275ee8b9ae441e6e32e1f7f36290e6a048722619d91195773a07b06682418209 | 4226980 | 4224831 | 4225043 | \ x6eb04497431d77657a94b0eee70dae59e7403980d4fc9d06ba5295436b8f0f54 | 7 | 1418 | 195 | 2020-05-29 08:58:11 | 2
(2 Reihen)