Cardano-db-sync: ブロックテーブルから削除されていない孤立したブロック

これに対する最も簡単な解決策は、このように孤立しているブロックを削除することです。

それらを削除する代わりに、それらを別のorphaned_blocksテーブルに移動することもできますが、そのブロックにアタッチされたtxを使用して何をするかを決定する必要があります。 私の最初の気持ちは、それらは無視/削除されるべきだということです。

orphaned_blockテーブルがあると、Praosに切り替えるときに便利な場合がありますが、db-syncが実際にByronのみをサポートしている場合でも、今でも簡単に実装できます。

私の最初の考えは、孤立したブロックを一掃し、どこかに保管することでもありました。

ノードが、放棄されたサイドアームからのすべてのブロックを含むすべての検出されたフォークをこのテーブルに格納することもオプションになる可能性があります。 xスロット後のパージは簡単です。 その場合、何が起こったかの診断と追跡がはるかに簡単になります。

失われたTXに関する質問は興味深いものです。 簡単なアイデアとして、それが暗号的に可能であり、100％安全であるかどうかを知らなくても：

（db-syncが有効になっている）ノードが孤立したブロックからTXを検出した場合、ノードはそれらを自分のmempoolに再挿入しようとする可能性があります。 それ以上ブロードキャストするのではなく、ブロックを作成するのが彼の番である場合にのみ処理します。
（他の多くのプールが孤立したブロックをそのTXで検出し、そのソースからmempoolに再挿入するため、ブロードキャストは必要ありません）

その間にutxoの所有者が（フォークが解決され、孤立したブロックが検出されるまで）2回目の試行を送信すると、前のTXは無効になります。 代わりにtxがまだ有効である場合、それは自動的に新しい有効なブロックに再び表示されます。

ウォレットは、ブロック内にtxが表示され、その後孤立し、その後、同じtxが別の、できれば有効なブロックに配置される状況を処理できる必要があります。

（db-syncが有効になっている）ノードが孤立したブロックからTXを検出した場合、ノードはそれらを自分のmempoolに再挿入しようとする可能性があります。 それ以上ブロードキャストするのではなく、ブロックを作成するのが彼の番である場合にのみ処理します。

db-syncはnodeとは別であり、単にnodeのチェーンに従うことに注意することが重要です。
具体的には、 db-syncはmempoolの独自のコピーを維持しません。 私が検出した場合、孤立したブロック内のトランザクションは、ほぼ確実に後の孤立していないブロックに含まれていたため、 db-syncはそれらを削除する必要があります。

もちろん、ウォレットの動作はdb-syncは異なります。

TXが他のブロックプロデューサーによってほぼ確実に処理される場合は、dbからノードのmempoolに何らかのツールを使用してTXを「再注入」する必要はありません。
問題は、これがすべてのスロット/高さの戦闘バリアントに当てはまるかどうかです。 次の質問ではない場合は、孤立したブロックで未処理のTXを検出するノードの1つに、db-syncデータベースに基づいてそれらをmempoolに再挿入させることが有用かどうか（意図されているかどうか）です。

db-syncは、実際には過去に起こったことを表示するためにのみ使用する必要があります。 ノード自体は、孤立したブロックからトランザクションを引き出し、それらを独自のmempoolに戻します。 db-syncは、その一部となることを意図したものではありません。

ただし、最後の100程度のスロット内で孤立したブロックのリストを維持すると、デバッグに役立つ場合があります。

ブロックはロールバック時に削除する必要があると思います。カスケード削除を使用して、削除されたブロック内に論理的に含まれるすべてのものを削除する必要があります。

ロールバックされたブロックを保持しようとしても意味がありません。 これは、ネットワーク内のブロック伝播を監視するための監視ツールではありません。 1つの場所で、ノードクライアントとしてのみ監視しているため、その役割で使用すると非常に信頼性が低くなります。

実際のチェーン状態を反映して、db-syncを可能な限り純粋に保つ必要があることに同意します。

ただし、すべてのブロックがdb-syncになり、ロールバック時に削除された場合は、私の生活が大幅に簡素化されます。 そうすれば、postgresの削除をトリガーして、データを使ってやりたいことを実行できます。

これは他のクライアントにも必要であり、Samは、Testnetを含むすべてのdb-syncリリースにとって重要であると述べています。

ロールバックが期待どおりに機能していないようです。 DB内に同じブロック高さの複数のブロックが表示されます。 これが（メインネット上の）例です：

cexplorer =＃SELECT * FROMブロックWHEREblock_no = 4224831;
id | ハッシュ| slot_no | block_no | 前| merkel_root | slot_leader | サイズ| epoch_no | 時間| 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行）