Cardano-db-sync: Blocs orphelins non supprimés de la table Block

La solution la plus simple consiste à supprimer les blocs devenus orphelins comme celui-ci.

Au lieu de les supprimer, nous pourrions les déplacer vers une table orphaned_blocks séparée, mais nous devons ensuite décider ce que nous voulons faire avec les tx attachés à ce bloc. Mon sentiment initial est qu'ils devraient simplement être ignorés / supprimés.

Avoir une table orphaned_block peut être utile lorsque nous passons à Praos, mais peut être facilement implémentée même maintenant lorsque db-sync ne prend vraiment en charge que Byron.

Ma toute première pensée fut aussi: nettoyez le bloc orphelin, mais gardez-le quelque part.

Cela pourrait même devenir une option pour le nœud de stocker toutes les fourches détectées, y compris tous les blocs du bras latéral abandonné dans cette table. La purge après x slots est simple. le diagnostic et le traçage de ce qui s'est passé sont alors beaucoup plus faciles.

La question des TX perdus est intéressante. En guise d'idée rapide, sans savoir si c'est possible cryptographiquement et 100% sûr:

Si un nœud (db-sync enabled) détecte des TX de blocs orphelins, il pourrait essayer de les réinsérer dans son mempool. Ne pas la diffuser plus loin, mais la traiter uniquement si c'est à son tour de produire un bloc.
(la diffusion ne devrait pas être nécessaire car de nombreux autres pools détectent le bloc orphelin avec ses TX et le réinsèrent dans leur mempool à partir de cette source)

Si le propriétaire de l'utxo entre-temps (jusqu'à ce que les fourchettes soient résolues et que les blocs orphelins soient détectés) soumet une deuxième tentative, le TX précédent devient invalide. Si à la place le tx est toujours valide, il réapparaîtra automatiquement dans un nouveau bloc valide.

Les portefeuilles doivent alors être en mesure de gérer une situation où ils pourraient voir leur tx dans un bloc, qui est alors orphelin, et certains blocs plus tard, le même tx est placé dans un autre bloc, espérons-le, valide.

Si un nœud (db-sync enabled) détecte des TX de blocs orphelins, il pourrait essayer de les réinsérer dans son mempool. Ne pas la diffuser plus loin, mais la traiter uniquement si c'est à son tour de produire un bloc.

Il est important de noter que db-sync est séparé de node et suit simplement la chaîne de node .
Plus précisément, db-sync ne maintient pas sa propre copie du mempool. Dans le cas que j'ai détecté, les transactions dans le bloc orphelin étaient presque certainement incluses dans des blocs non orphelins ultérieurs, donc db-sync devrait simplement les supprimer.

Le portefeuille a bien sûr un comportement différent de db-sync .

Si les TX sont presque certainement traités par d'autres producteurs de blocs, il n'est donc pas nécessaire de les «réinjecter» avec un outil de la base de données au mempool du nœud.
La question est de savoir si c'est le cas dans toutes les variantes de bataille de fente / hauteur. Sinon, la question suivante est de savoir s'il est utile (prévu) de laisser l'un des nœuds qui détectent les TX non traités dans un bloc orphelin, les réinsérer dans son mempool, basé sur la base de données db-sync

db-sync ne devrait vraiment être utilisé que pour voir ce qui s'est passé dans le passé. Le nœud lui-même extraira les transactions des blocs orphelins et les remettra dans son propre mempool. db-sync n'est pas censé en faire partie.

Cependant, maintenir une liste de blocs orphelins dans les 100 derniers emplacements environ peut être utile pour le débogage.

Je pense que le bloc devrait être supprimé lors de la restauration, et nous devrions utiliser des suppressions en cascade pour supprimer tout ce qui se trouve logiquement dans les blocs supprimés.

Il ne sert à rien d'essayer de préserver les blocs qui ont été annulés. Il ne s'agit pas d'un outil de surveillance pour surveiller la propagation des blocs au sein du réseau. Il n'observe qu'à un seul endroit, et en tant que client de nœud, il serait donc très peu fiable lorsqu'il est utilisé dans ce rôle.

Je suis d'accord que nous devrions garder db-sync aussi pur que possible, reflétant l'état réel de la chaîne.

Cependant, cela simplifierait grandement ma vie si TOUS les blocs se transformaient en db-sync, puis étaient supprimés lors des restaurations. De cette façon, je peux déclencher la suppression des postgres et faire ce que je veux avec les données.

Ceci est nécessaire pour d'autres clients et Sam dit que c'est essentiel pour toute version de db-sync, y compris Testnet.

Il semble que les restaurations ne fonctionnent pas comme prévu. Nous voyons plusieurs blocs dans la base de données avec la même hauteur de bloc. Voici un exemple (sur le réseau principal):

cexplorer = # SELECT * FROM bloc WHERE block_no = 4224831;
id | hachage | slot_no | block_no | précédent | merkel_root | slot_leader | taille | epoch_no | temps | 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 rangées)