Cardano-db-sync: Blok yatim piatu tidak dihapus dari tabel Blok

Solusi paling sederhana untuk ini adalah menghapus blok yang telah menjadi yatim piatu seperti ini.

Sebagai alternatif untuk menghapusnya, kita dapat memindahkannya ke tabel orphaned_blocks tetapi kemudian kita perlu memutuskan apa yang ingin kita lakukan dengan tx s yang terpasang pada blok itu. Perasaan awal saya adalah mereka harus diabaikan / disingkirkan.

Memiliki tabel orphaned_block mungkin berguna ketika kita beralih ke Praos, tetapi dapat dengan mudah diterapkan bahkan sekarang ketika db-sync benar-benar hanya mendukung Byron.

Pikiran pertama saya juga: bersihkan blok yatim piatu, tapi simpan di suatu tempat.

Ini bahkan bisa menjadi opsi bagi node untuk menyimpan semua garpu yang terdeteksi termasuk semua blok dari lengan samping yang ditinggalkan dalam tabel ini. Membersihkan setelah slot x itu sederhana. mendiagnosis dan menelusuri apa yang terjadi jauh lebih mudah.

Pertanyaan tentang TX yang hilang itu menarik. Sebagai ide cepat, tanpa mengetahui apakah itu mungkin secara kriptografis dan 100% aman:

Jika node (db-sync enabled) mendeteksi TX dari blok yatim piatu, dia dapat mencoba memasukkannya kembali dalam mempool-nya. Bukan menyiarkannya lebih jauh, tetapi hanya memprosesnya jika gilirannya menghasilkan satu blok.
(siaran seharusnya tidak diperlukan karena banyak kumpulan lain mendeteksi blok yatim piatu dengan TX-nya dan memasukkannya kembali ke mempool mereka dari sumber itu)

Jika pemilik utxo sementara itu (hingga percabangan diselesaikan dan blok yatim piatu terdeteksi) mengirimkan upaya kedua, TX sebelumnya menjadi tidak valid. Jika tx masih valid, maka secara otomatis akan muncul di blok valid baru lagi.

Dompet harus dapat menangani situasi saat itu, di mana mereka mungkin melihat tx mereka dalam sebuah blok, yang kemudian menjadi yatim piatu, dan beberapa blok kemudian tx yang sama ditempatkan di blok lain, kemudian blok yang semoga valid.

Jika node (db-sync enabled) mendeteksi TX dari blok yatim piatu, dia dapat mencoba memasukkannya kembali dalam mempool-nya. Bukan menyiarkannya lebih jauh, tetapi hanya memprosesnya jika gilirannya menghasilkan satu blok.

Penting untuk dicatat bahwa db-sync terpisah dari node dan cukup mengikuti rantai node .
Secara khusus, db-sync tidak menyimpan salinan mempool-nya sendiri. Dalam kasus yang saya deteksi, transaksi di blok yatim piatu hampir pasti termasuk dalam blok non-yatim piatu, jadi db-sync seharusnya hanya menjatuhkannya.

Dompet tentu saja memiliki perilaku yang berbeda dari db-sync .

Jika TX hampir pasti diproses oleh produsen blok lain maka ofc tidak perlu "menginjeksi ulang" mereka dengan beberapa alat dari db ke node mempool.
Pertanyaannya adalah apakah ini yang terjadi di semua varian pertempuran slot / ketinggian. Jika tidak, pertanyaan berikutnya adalah apakah berguna (dimaksudkan) untuk membiarkan salah satu node yang mendeteksi TX yang tidak diproses dalam blok yatim piatu, memasukkannya kembali ke mempool-nya, berdasarkan database db-sync

db-sync seharusnya hanya digunakan untuk melihat apa yang telah terjadi di masa lalu. Node itu sendiri akan menarik transaksi keluar dari blok yatim piatu dan menempatkannya kembali dalam mempoolnya sendiri. db-sync tidak dimaksudkan untuk menjadi bagian dari itu.

Akan tetapi, mempertahankan daftar blok yang tidak lagi ada dalam 100 atau lebih slot terakhir mungkin berguna untuk debugging.

Saya pikir blok harus dihapus saat rollback, dan kita harus menggunakan penghapusan bertingkat untuk menghapus semua yang secara logis di dalam blok yang dihapus.

Tidak ada gunanya mencoba mempertahankan blok yang telah digulung kembali. Ini bukan alat pemantauan untuk memantau penyebaran blok di dalam jaringan. Itu hanya mengamati di satu tempat, dan sebagai klien node, jadi akan sangat tidak bisa diandalkan ketika digunakan dalam peran itu.

Saya setuju kita harus menjaga sinkronisasi db semurni mungkin sebagai refleksi dari status rantai aktual.

Namun, itu akan sangat menyederhanakan hidup saya jika SEMUA blok membuatnya menjadi sinkronisasi db, dan kemudian dihapus saat rollback. Dengan cara itu saya dapat memicu penghapusan postgres dan melakukan apa yang saya inginkan dengan data.

Ini diperlukan oleh klien lain dan Sam mengatakan ini penting untuk rilis db-sync, termasuk Testnet.

Sepertinya rollback tidak berfungsi seperti yang diharapkan. Kami melihat banyak blok di DB dengan tinggi blok yang sama. Berikut contohnya (di mainnet):

cexplorer = # PILIH * DARI blok MANA block_no = 4224831;
id | hash | slot_no | block_no | sebelumnya | merkel_root | slot_leader | ukuran | epoch_no | waktu | 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 baris)