Cardano-db-sync: Contoh saldo akun

Terima kasih telah membuka masalah ini atas nama saya! Hanya untuk memperjelas sedikit lebih lanjut - ini bukan hanya tentang akun itu sendiri, tetapi terutama tentang pelacakan reap di suatu tempat di db sehingga dapat dengan mudah digunakan dalam perhitungan saldo akun (yang digunakan di mana-mana, misalnya pool live ukuran pasak, janji langsung kumpulan, dll.).

@1000101 Apa itu "menuai"? Tidak ada tabel atau kolom di db-sync yang disebut "menuai".

Saldo akun tidak sepele.

Alamat di Shelley dan era selanjutnya memiliki dua komponen; kredensial pembayaran dan kredensial staking. Alamat pasak (misalnya stake1uyluup0rh6r2cc7kcw8nudqz990ezf5ltagxmw3u8deukvqwq7etq ) berasal dari yang belakangan. Namun dimungkinkan untuk membuat alamat yang valid yang tidak mengandung kredensial staking.

Jadi meskipun dimungkinkan untuk mendapatkan saldo akun untuk alamat pasak tertentu, tidak ada cara untuk mendapatkan saldo akun dompet kecuali setiap alamat di dompet itu menyertakan kredensial taruhan yang sama.

@1000101 Apa itu "menuai"? Tidak ada tabel atau kolom di db-sync yang disebut "menuai".

Oh, saya minta maaf karena tidak cukup menjelaskan ini. Apa yang saya maksud dijelaskan dalam https://github.com/input-output-hk/cardano-db-sync/issues/474 - yaitu apa yang saya katakan adalah persis bahwa tidak ada kolom untuk ini tetapi akan lebih bagus jika akan ada.

Saat ini tidak ada cara mudah untuk menghitung saldo akun, ketika akun ini telah digunakan dalam pendaftaran pool (sebagai akun hadiah) dan kemudian pool dihentikan, sehingga mendapatkan kembali deposit pool. "Pembayaran" deposit kumpulan dilacak di dbsync, tetapi bukan "pengembalian dana" ketika kumpulan dihentikan.

Saya setuju dengan ini. Ada juga banyak kasus tepi yang harus ditangani oleh setiap "pengguna" cardano-db-sync. Baik Adalite dan Yoroi bingung ketika mereka melihat akun yang sebelumnya merupakan akun hadiah dari kumpulan pensiunan:

Selain itu, hanya cardanoscan AFAIK yang menangani sisa hadiah dengan benar, dan mereka tidak menggunakan db-sync.

Seharusnya ada hubungan mudah yang akan diperbarui dengan cara yang sama seperti hadiah yang ditambahkan secara otomatis. Mari kita ambil kumpulan dengan beberapa deregistrasi sebagai contoh, karena itu sebenarnya cukup umum dan sulit untuk menangani saldo hadiah dari akun pemiliknya.

Ada 9 sertifikat pensiun untuk itu

Dan 15 sertifikat pendaftaran

Ada banyak kasus tepi dan aturan pensiun yang tidak jelas yang ditolak oleh sertifikat baru .

@erikd , jika Anda bersikeras pada koneksi yang memadai antara setoran 500 tx dan pensiun, bagaimana Anda akan menulis kueri hanya untuk setoran yang dikembalikan dari salah satu akun pemiliknya - e127e9e94eaa9287680e877832700a1724255e9688609497e09a6c440f? Jika tidak, dapatkah kita menambahkan ini secara eksplisit ke db-sync? Katakanlah, sebagai tabel baru, bernama pool_refunds , dengan addr_id , jumlah (saat ini harus kelipatan 500) dan epoch_no - sehingga ini ditangani dengan benar, dan di satu tempat.

Saat ini db-sync mengekstrak data dari status buku besar dan memasukkannya ke dalam database. Itu membuang beberapa informasi, tetapi tidak melakukan agregasi apa pun. Apa yang dimasukkan ke dalam database hanyalah cerminan dari apa yang disediakan oleh status buku besar.

Mari kita lihat pool_hash.id yang relevan :

> select id, hash_raw from pool_hash
    where hash_raw = '\x9c8e59ea7004a51f953642653d70a94d066359b9dd6e6416a5430ff3' ;
  id  |                          hash_raw                          
------+------------------------------------------------------------
 5022 | \x9c8e59ea7004a51f953642653d70a94d066359b9dd6e6416a5430ff3
(1 row)

Kumpulan telah didaftarkan (gabungan tambahan untuk menempatkannya dalam urutan block_no menaik) sebagai berikut:

> select pool_update.id, hash_id, cert_index, active_epoch_no, block.block_no, block.epoch_no
    from pool_update
      inner join tx on tx.id = pool_update.registered_tx_id
      inner join block on tx.block_id = block.id
    where pool_update.hash_id = 5022
    order by block.block_no asc; 
  id  | hash_id | cert_index | active_epoch_no | block_no | epoch_no 
------+---------+------------+-----------------+----------+----------
 5022 |    5022 |          0 |             220 |  4717004 |      218
 5023 |    5022 |          0 |             220 |  4717035 |      218
 5024 |    5022 |          0 |             220 |  4717057 |      218
 5029 |    5022 |          0 |             220 |  4717140 |      218
 5030 |    5022 |          0 |             220 |  4717146 |      218
 5031 |    5022 |          0 |             220 |  4717169 |      218
 5032 |    5022 |          0 |             220 |  4717189 |      218
 5033 |    5022 |          0 |             220 |  4717216 |      218
 5034 |    5022 |          0 |             220 |  4717234 |      218
 5035 |    5022 |          0 |             220 |  4717241 |      218
 5037 |    5022 |          0 |             220 |  4717296 |      218
 5038 |    5022 |          0 |             220 |  4717425 |      218
 5061 |    5022 |          0 |             220 |  4721000 |      218
 5080 |    5022 |          0 |             221 |  4725394 |      219
 5081 |    5022 |          0 |             221 |  4725435 |      219
(15 rows)

dan dibatalkan pendaftarannya di:

> select pool_retire.id, hash_id, cert_index, retiring_epoch, block.block_no, block.epoch_no
    from pool_retire
      inner join tx on tx.id = pool_retire.announced_tx_id
      inner join block on tx.block_id = block.id
    where hash_id = 5022
    order by block.block_no asc ; 
 id  | hash_id | cert_index | retiring_epoch | block_no | epoch_no 
-----+---------+------------+----------------+----------+----------
 180 |    5022 |          0 |            219 |  4717395 |      218
 181 |    5022 |          0 |            219 |  4717397 |      218
 182 |    5022 |          0 |            219 |  4717401 |      218
 183 |    5022 |          0 |            219 |  4717403 |      218
 184 |    5022 |          0 |            219 |  4717405 |      218
 185 |    5022 |          0 |            219 |  4717417 |      218
 186 |    5022 |          0 |            219 |  4717430 |      218
 187 |    5022 |          0 |            220 |  4725366 |      219
 188 |    5022 |          0 |            220 |  4725717 |      219
(9 rows)

Membatalkan pemutakhiran dan pembatalan pendaftaran:

action   | block_no
---------+------------
register | 4717004
update   | 4717035
update   | 4717057
update   | 4717140
update   | 4717146
update   | 4717169
update   | 4717189
update   | 4717216
update   | 4717234
update   | 4717241
update   | 4717296
retire   | 4717395
retire   | 4717397
retire   | 4717401
retire   | 4717403
retire   | 4717405
retire   | 4717417
update   | 4717425
retire   | 4717430
update   | 4721000
retire   | 4725366
update   | 4725394
update   | 4725435
retire   | 4725717

Bersambung ....

Ini pasti terlalu banyak rasa sakit di leher. Berbicara dengan orang-orang dengan spesifikasi buku besar untuk mencoba menemukan solusi.

Disampaikan kepada orang-orang ledger-specs yang menyarankan cara cepat dan kotor untuk memalsukannya untuk saat ini sambil menunggu solusi yang lebih baik.

Idenya adalah memiliki sesuatu seperti tabel pool_registration_refund yang berisi alamat pasak dan jumlahnya.

Itu bagus!

Disampaikan kepada orang-orang ledger-specs yang menyarankan cara cepat dan kotor untuk memalsukannya untuk saat ini sambil menunggu solusi yang lebih baik.

Idenya adalah memiliki sesuatu seperti tabel pool_registration_refund yang berisi alamat pasak dan jumlahnya.

Luar biasa! Maksud saya, kami memiliki solusi untuk saat ini sehingga kami tidak akan mencapai saldo negatif yang dibagikan @xdzurman , tetapi ada sekitar 100 baris yang tidak terlalu cantik:tm : SQL yang harus dihitung per setiap akun. Ini pasti akan membantu banyak. Terima kasih satu juta!!!