Cardano-db-sync: Hadiah didistribusikan ke alamat pasak yang tidak terdaftar

Dibuat pada 2 Des 2020 · 28Komentar · Sumber: input-output-hk/cardano-db-sync

Mainnet, db-sync 6.0.1, alamat pasak stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86

sejarah pendaftaran

SELECT stake_registration.addr_id, block.epoch_no, block.time
FROM stake_address
LEFT JOIN stake_registration ON stake_registration.addr_id = stake_address.id
LEFT JOIN tx ON tx.id = stake_registration.tx_id
LEFT JOIN block ON block.id = tx.block_id 
WHERE stake_address.view = 'stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86';

 addr_id | epoch_no |        time
---------+----------+---------------------
   38278 |      208 | 2020-08-01 07:45:51
   38278 |      233 | 2020-12-01 22:31:13
(2 rows)

riwayat de-registrasi

SELECT stake_deregistration.addr_id, block.epoch_no, block.time
FROM stake_address
LEFT JOIN stake_deregistration ON stake_deregistration.addr_id = stake_address.id
LEFT JOIN tx ON tx.id = stake_deregistration.tx_id
LEFT JOIN block ON block.id = tx.block_id 
WHERE stake_address.view = 'stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86';

 addr_id | epoch_no |        time
---------+----------+---------------------
   38278 |      232 | 2020-12-01 18:25:59
(1 row)

seperti yang kita lihat, alamat tersebut belum terdaftar di akhir zaman 232, dan hadiah untuk zaman 231 tidak boleh didistribusikan ke alamat ini, tetapi

SELECT reward.*, block.epoch_no AS block_epoch_no, block.time
FROM reward
LEFT JOIN block ON block.id = reward.block_id 
WHERE reward.addr_id = 38278 AND reward.epoch_no = 231;

   id    | addr_id |  amount   | epoch_no | pool_id | block_id | block_epoch_no |        time
---------+---------+-----------+----------+---------+----------+----------------+---------------------
 1041508 |   38278 | 192969560 |      231 |     144 |  5023676 |            233 | 2020-12-01 21:44:51
(1 row)

bug priority high

Sumber

dmitrystas

👀4 👍1

Komentar yang paling membantu

Menggunakan versi db-sync di PR #469. hadiah untuk alamat pasak \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde dimasukkan dengan benar ke dalam tabel orphaned_rewards :

cexplorer=# select stake_address.hash_raw, orphaned_reward.epoch_no, orphaned_reward.amount
         from orphaned_reward inner join stake_address on stake_address.id = orphaned_reward.addr_id
         where stake_address.hash_raw = '\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde'; 
                           hash_raw                           | epoch_no |  amount   
--------------------------------------------------------------+----------+-----------
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |      231 | 192969560

dan itu juga tidak ada di tabel hadiah:

cexplorer=# select stake_address.hash_raw as "stakeAddress", "totalReward".* from stake_address
    left outer join (SELECT addr_id, amount, epoch_no  FROM reward) as "totalReward"
     on stake_address.id = "totalReward".addr_id
     where stake_address.hash_raw = '\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde' ;
                         stakeAddress                         | addr_id |  amount   | epoch_no 
--------------------------------------------------------------+---------+-----------+----------
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 162720747 |      211
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 162485461 |      212
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 167344099 |      213
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 167043060 |      214
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 200722225 |      215
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 191413549 |      216
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 143111843 |      217
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 147836812 |      218
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 154740829 |      219
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 145433327 |      220
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165631299 |      221
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 151825651 |      222
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 169141624 |      223
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165184716 |      224
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 148899668 |      225
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 157838234 |      226
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 223252352 |      227
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 147889017 |      228
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 151858721 |      229
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165782849 |      230
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 135711434 |      232
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 145964545 |      233
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 |    100702 |      235
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 |    102078 |      236
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 |        65 |      238
(25 rows)

erikd pada 8 Jan 2021

👍2

Semua 28 komentar

:Telapak tangan:

Melihat ini sebentar dan kemudian tiba-tiba menyadari bahwa kueri pertama tidak menunjukkan apa yang menurut @dmitrystas ditampilkan. Dengan bergabung di tx.id = stake_registration.tx_id dan kemudian mendapatkan block.epoch_no dari transaksi, Anda mendapatkan waktu bahwa pendaftaran/pencabutan pendaftaran pasak terjadi, tetapi tidak ketika itu benar-benar aktif .

Untuk sebagian besar operasi yang terkait dengan staking, tindakan (seperti pendaftaran, peningkatan jumlah yang dipertaruhkan, dll.) yang terjadi di epoch N menjadi aktif di epoch N + 2 .

Itu berarti kueri pertama seharusnya:

cexplorer=# SELECT stake_registration.addr_id, block.epoch_no + 2 as epoch_no, block.time FROM stake_address 
              INNER JOIN stake_registration ON stake_registration.addr_id = stake_address.id 
              INNER JOIN tx ON tx.id = stake_registration.tx_id INNER JOIN block ON block.id = tx.block_id
              WHERE stake_address.view = 'stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86';
addr_id | epoch_no |        time         
---------+----------+---------------------
   38266 |      210 | 2020-08-01 07:45:51
   38266 |      235 | 2020-12-01 22:31:13

dan yang kedua:

cexplorer=# SELECT stake_deregistration.addr_id, block.epoch_no + 2 as epoch_no, block.time FROM stake_address
              INNER JOIN stake_deregistration ON stake_deregistration.addr_id = stake_address.id
              INNER JOIN tx ON tx.id = stake_deregistration.tx_id INNER JOIN block ON block.id = tx.block_id
              WHERE stake_address.view = 'stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86';
 addr_id | epoch_no |        time         
---------+----------+---------------------
   38266 |      234 | 2020-12-01 18:25:59

@dmitrystas Apakah itu semua bertambah? Apakah akan membantu menambahkan tambahan active_epoch_no kolom ke stake_registration dan stake_deregistration tabel seperti saya memiliki yang delegation table?

erikd pada 17 Des 2020

@erikd Selamat siang. Itu adalah masalah asli https://github.com/Emurgo/yoroi-frontend/issues/1832#issue -754776885
Mungkin bisa bermanfaat

Yoroi & Adalite salah menunjukkan 192 hadiah ADA PALSU tapi sebenarnya 0. 2 hadiah terakhir ditarik melalui adawallet.io (tidak menggunakan db-sync)

Deskripsi singkat tentang masalah dalam langkah-langkah:
1) Zaman 232 . Saya menarik hadiah dan membatalkan pendaftaran kunci pasak secara bersamaan. Hadiahnya 0. Saya punya cukup ADA untuk biaya
2) Zaman 233 . Saya harus menerima hadiah pertama yang tersisa jika kunci saya terdaftar tetapi tidak, tetapi Yoroi menunjukkan 192ADA diterima. Yoroi melakukan kesalahan ketika saya mencoba untuk menarik. Dompet lain yang tidak menggunakan db-sync menunjukkan hadiah 0ADA
3) Zaman 233 . Saya mendelegasikan ke kolam yang sama lagi. Kunci terdaftar . Hadiah sejati 0. Hadiah Yoroi 192.
4) Zaman 234 . Saya menerima sisa hadiah kedua 135ADA. Saldo hadiah yang sebenarnya adalah 135ADA.
Yoroi menunjukkan 327ADA (192+135). Tidak dapat menarik hadiah apa pun melalui Yoroi Saya memiliki Kesalahan yang diterima dari server saat mengirim transaksi.
5) Zaman 235 . Saya menerima hadiah ketiga terakhir 145ADA. Saldo hadiah yang sebenarnya adalah 280ADA (135+145).
Yoroi menunjukkan 472ADA (192+135+1145) Tidak dapat menarik hadiah apa pun melalui Yoroi Saya menerima Kesalahan dari server saat mengirim transaksi.
6) Zaman 235 . Saya menarik 280ADA dengan lancar melalui adawallet.io yang tidak menggunakan db-syns dan menunjukkan saldo hadiah 280ADA dengan benar
7) Setelah hadiah 280ADA yang sebenarnya ditarik (tetap 0ADA) Yoroi masih menunjukkan saldo hadiah 192ADA.

IlyaSofronov pada 17 Des 2020

Yoroi masih menunjukkan saldo hadiah 192ADA.

Setidaknya ada dua kemungkinan;

ada bug db-sync
ada bug Yoroi

Saya hanya berurusan dengan db-sync . Itu berarti bahwa masalah perlu disajikan kepada saya sebagai kueri SQL bukan sebagai informasi dari Yoroi.

Apakah stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86 adalah kunci pasak yang menarik di sini?

erikd pada 17 Des 2020

@erikd ya kunci pasak adalah stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86
Perhatikan bahwa tidak hanya Yoroi MEMILIKI BUG ITU, tetapi Adalite.io dan adastat.net
Ini TIDAK MEMILIKI bug itu: cardanoscan.io dan adawallet.io

IlyaSofronov pada 18 Des 2020

Jika beberapa dompet online memiliki bug ini dan yang lainnya tidak, dan semua ini bergantung pada db-sync maka masalahnya sangat kecil kemungkinannya berada di db-sync .

erikd pada 18 Des 2020

@erikd Tapi adawallet.io tidak menggunakan db-sync dan menunjukkan saldo hadiah yang benar (0ADA) dan itu memungkinkan saya menarik hadiah terakhir

IlyaSofronov pada 18 Des 2020

Sekali lagi itu menunjukkan bahwa ini adalah bug Yoroi, bukan bug db-sync .

erikd pada 18 Des 2020

Exodus juga menemukan bug ini.

roccomuso pada 4 Jan 2021

Ini jelas merupakan bug cardano-db-sync dan bukan bug Yoroi mengingat bagaimana ini tidak hanya memengaruhi Yoroi tetapi juga beberapa pengguna cardano-db-sync lainnya. cardanoscan dan adawallet keduanya tidak menggunakan cardano-db-sync itulah sebabnya mereka tidak terpengaruh.

Apa laporan sinkronisasi cardano-db

Berikut adalah kueri SQL yang memberikan riwayat hadiah untuk alamat yang disediakan oleh @IlyaSofronov

select stake_address.hash_raw as "stakeAddress"
      , "totalReward".*

from stake_address

left outer join (
  SELECT addr_id, amount, epoch_no
  FROM reward
) as "totalReward" on stake_address.id = "totalReward".addr_id

where encode(stake_address.hash_raw, 'hex') = 'e1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde'

dan memberikan hasil sebagai berikut:

 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 162720747 |      211
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 162485461 |      212
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 167344099 |      213
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 167043060 |      214
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 200722225 |      215
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 191413549 |      216
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 143111843 |      217
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 147836812 |      218
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 154740829 |      219
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 145433327 |      220
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165631299 |      221
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 151825651 |      222
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 169141624 |      223
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165184716 |      224
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 148899668 |      225
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 157838234 |      226
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 223252352 |      227
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 147889017 |      228
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 151858721 |      229
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165782849 |      230
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 192969560 |      231
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 135711434 |      232
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 145964545 |      233
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 |    100702 |      235
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 |    102078 |      236

Catatan : Jumlah baris ini adalah 3.765.004.402

Status saat ini (salah) dari backend kami

{
    "remainingAmount": "193172340",
    "rewards": "3765004402",
    "withdrawals": "3571832062",
}

Anda dapat melihat backend kami mengembalikan jumlah baris db-sync untuk nilai rewards (akan menjelaskan mengapa ini menjadi masalah nanti)

Anda juga dapat memverifikasi jumlah withdrawals benar dengan menjumlahkan nilai pada cardanoscan yang kami tahu tidak terpengaruh oleh bug ini.

remainingAmount hanya rewards - withdrawals

Riwayat pendaftaran untuk dompet

Dengan melihat history dari staking key ini , Anda dapat melihat:

Itu dibatalkan pendaftarannya pada Epoch 232
Itu didaftarkan ulang pada Epoch 233

Status saat ini dari cardano-node

Menurut instance cardano-node saya, ini adalah nilai saat ini di dalam alamat staking

[
    {
        "address": "stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86",
        "delegation": "pool1kkfkdces5mdcyc9dn2hgg3463jggjvw3h89nejjarkz25uavaqu",
        "rewardAccountBalance": 202780
    }
]

Jadi Anda bisa melihat bahwa menurut node, saldo dompet adalah epoch 235 + epoch 236 (100702 + 102078 = 202780)

Jadi apa masalahnya?

Dengan melihat cardanoscan kita dapat melihat riwayat penarikan dompet secara lengkap. Mari kita lihat apa yang sesuai dengan setiap penarikan:

| Epoch ditarik | Jumlah yang ditarik | baris zaman db-sync disertakan |
|-----------------|------------------|------------ -----------------|
| 228 | 2601.373144 | 211, 212, ..., 225, 226 |
| 230 | 371.141369 | 227, 228 |
| 232 | 317.641570 | 229, 230 |
| 234 | 135.711434 | 232 |
| 235 | 145.964545 | 233 |

NAMUN Anda dapat melihat Epoch 231 di cardano-db-sync (192969560) tidak termasuk dalam semua ini!

Benar saja, jika Anda melihat respons backend kami, "remainingAmount": "193172340", dan Anda menghapus Epoch 231, Anda mendapatkan 193172340 - 192969560 = 202780 yang merupakan hasil yang diharapkan dari fullnode kami!

Kesimpulan

Berdasarkan penyelidikan saya, tampaknya cardano-db-sync menyertakan baris 231 dalam hasil riwayat hadiah meskipun seharusnya tidak.

SebastienGllmt pada 4 Jan 2021

Saya menyederhanakan kueri pertama dan memvalidasi bahwa saya mendapatkan hasil yang sama (saya lakukan).

Status saat ini (salah) dari backend kami

Saya lebih suka mendapatkan semua informasi dari satu sumber jadi:

cexplorer=# select sum (amount) from stake_address
        left outer join (SELECT addr_id, amount, epoch_no 
        FROM reward) as "totalReward" on stake_address.id = "totalReward".addr_id
        where stake_address.hash_raw = '\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde' ;
    sum     
------------
 3765004402

dan:

cexplorer=# select sum (amount) from withdrawal where addr_id = 38266;
    sum     
------------
 3571832062

keduanya setuju dengan angka Anda.

Menariknya 3571832062 + 192969560 + 202780 - 3765004402 mana 3571832062 adalah jumlah penarikan dan 3765004402 adalah jumlah hadiah. Nilai lainnya adalah; 202780 yang merupakan angka Anda untuk saldo hadiah setelah penarikan dan 192969560 adalah hadiah untuk epoch 231 .

cexplorer=# select stake_address.view as "stakeAddress", "totalReward".* from stake_address
     left outer join (SELECT addr_id, amount, epoch_no  FROM reward) as "totalReward"
     on stake_address.id = "totalReward".addr_id
     where stake_address.hash_raw = '\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde'
     and epoch_no = 231 ;
                        stakeAddress                         | addr_id |  amount   | epoch_no 
-------------------------------------------------------------+---------+-----------+----------
 stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86 |   38266 | 192969560 |      231

Jadi, apakah hadiah itu untuk Epoch 231 (yang db-sync hanya menarik keluar dari status buku besar dan memasukkan ke dalam database tanpa pemrosesan ekstra) benar? Mari kita lihat sejarah pendaftaran pasak untuk alamat pasak itu:

cexplorer=# select stake_address.hash_raw, stake_registration.tx_id, block.epoch_no
    as tx_epoch_no, (block.epoch_no + 2) as active_epoch_no
    from stake_registration inner join stake_address on stake_registration.addr_id = stake_address.id 
    inner join tx on tx.id = stake_registration.tx_id inner join block on tx.block_id = block.id
    where stake_address.hash_raw = '\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde' ;
                           hash_raw                           |  tx_id  | tx_epoch_no | active_epoch_no 
--------------------------------------------------------------+---------+-------------+-----------------
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde | 2449294 |         208 |             210
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde | 3103705 |         233 |             235
(2 rows)

cexplorer=# select stake_address.hash_raw, stake_deregistration.tx_id, block.epoch_no
    as tx_epoch_no, (block.epoch_no + 2) as active_epoch_no from stake_deregistration
    inner join stake_address on stake_deregistration.addr_id = stake_address.id
    inner join tx on tx.id = stake_deregistration.tx_id inner join block
    on tx.block_id = block.id
    where stake_address.hash_raw = '\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde' ;
                           hash_raw                           |  tx_id  | tx_epoch_no | active_epoch_no 
--------------------------------------------------------------+---------+-------------+-----------------
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde | 3101670 |         232 |             234

Perhatikan bahwa untuk registrasi dan deregistrasi saya telah menyertakan tx_id (id dari tx yang berisi registrasi/deregistration), tx_epoch_no (Epoch di mana tx dimasukkan) dan active_epoch_no (Epoch saat registrasi/deregistrasi aktif).

Melihat nomor epoch yang aktif , seharusnya pendaftaran stake sudah aktif di epoch [210 .. 233] dan [235 ..] . Ini cocok dengan hadiah sebenarnya untuk alamat ini:

cexplorer=# select stake_address.hash_raw as "stakeAddress", "totalReward".* from stake_address
    left outer join (SELECT addr_id, amount, epoch_no  FROM reward) as "totalReward"
     on stake_address.id = "totalReward".addr_id
     where stake_address.hash_raw = '\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde' ;
                         stakeAddress                         | addr_id |  amount   | epoch_no 
--------------------------------------------------------------+---------+-----------+----------
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 162720747 |      211
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 162485461 |      212
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 167344099 |      213
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 167043060 |      214
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 200722225 |      215
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 191413549 |      216
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 143111843 |      217
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 147836812 |      218
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 154740829 |      219
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 145433327 |      220
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165631299 |      221
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 151825651 |      222
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 169141624 |      223
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165184716 |      224
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 148899668 |      225
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 157838234 |      226
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 223252352 |      227
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 147889017 |      228
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 151858721 |      229
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165782849 |      230
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 192969560 |      231
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 135711434 |      232
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 145964545 |      233
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 |    100702 |      235
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 |    102078 |      236
(25 rows)

Yaitu, ada hadiah untuk setiap Epoch kecuali 234 .

Oleh karena itu saya pikir kesimpulan Anda:

Berdasarkan penyelidikan saya, tampaknya cardano-db-sync menyertakan baris 231 dalam hasil riwayat hadiah meskipun seharusnya tidak.

salah, alamat pasak itu seharusnya memiliki hadiah untuk Epoch 231 .

Selanjutnya, saya percaya bahwa komentar Anda:

Status saat ini (salah) dari backend kami
{
"jumlah yang tersisa": "193172340",
"hadiah": "3765004402",
"penarikan": "3571832062",
}

sebenarnya benar. Perbedaan antara nilai hadiah dan nilai penarikan adalah saldo hadiah yang belum ditarik saat ini.

erikd pada 5 Jan 2021

sebenarnya benar. Perbedaan antara nilai hadiah dan nilai penarikan adalah saldo hadiah yang belum ditarik saat ini.

Itu tidak mungkin terjadi karena kita tahu node mengembalikan 202780 sebagai saldo hadiah untuk akun dan bukan 193172340

Yaitu, ada hadiah untuk setiap epoch kecuali 234.

Anda harus mengharapkan dua zaman hilang:

Zaman di mana hadiah dikirim kembali ke cadangan karena mereka tidak memiliki kunci pasak yang terdaftar
Epoch yang mewakili celah 1 epoch antara saat mereka membatalkan pendaftaran kunci dan saat mereka mendaftar ulang

Epoch 234 hilang sesuai dengan (2), dan saya yakin 231 sesuai dengan (1) karena 231 berarti itu harus terlihat di dompet pengguna di Epoch 233 yang merupakan epoch yang kami harapkan telah hangus (1)

SebastienGllmt pada 5 Jan 2021

Anda harus mengharapkan dua zaman hilang:

Mengapa? Menurut operasi di alamat pasak ini:

| operasi | tx_epoch_no | active_epoch_no |
|-------------------|---------------------|------- ---------|
| pendaftaran | 208 | 210 |
| pencabutan pendaftaran | 232 | 234 |
| pendaftaran | 233 | 235 |

itu hanya dibatalkan pendaftarannya untuk satu zaman ( 234 ) dan tidak menerima hadiah untuk zaman itu.

Mengapa ada dua zaman tanpa imbalan? Saya cukup yakin dua kasus yang Anda sebutkan sebenarnya adalah hal yang sama dan karenanya hanya satu zaman yang berjalan tanpa hadiah.

erikd pada 5 Jan 2021

@SebastienGllmt di Slack berkata:

deregistrasi istimewa karena terjadi segera, bukan dalam 2 zaman

Jika deregistrasi segera dilakukan, ini terjadi di tx_epoch_no == 232 jadi hadiah untuk epoch [231..234] akan hilang semua, bukan hanya hadiah untuk 231.

Saya pikir kita perlu @JaredCorduan untuk ini.

erikd pada 5 Jan 2021

Penjelasan @SebastienGllmt konsisten dengan aturan buku besar.

Ini agak filosofis "ketika" kredensial pasak dibatalkan pendaftarannya, tetapi saya akan mengatakannya seperti ini: pembatalan pendaftaran dilakukan segera, tetapi imbalannya tertunda. Jika kredensial dibatalkan pendaftarannya di Epoch e , maka kredensial itu akan menerima hadiah pada batas e / e+1 (berasal dari snapshot yang diambil pada batas e-2 / e -1 ) dan juga akan menerima hadiah pada batas e+1 / e+2 (berasal dari snapshot yang diambil pada batas e-1 / e ).

JaredCorduan pada 5 Jan 2021

Ini terdengar seperti kita memiliki beberapa kebingungan dengan nomenklatur.

Dari POV dbs-ync : :

tx_epoch_no : epoch yang berisi transaksi-transaksi pendaftaran/pembatalan pendaftaran.
active_epoch_no : pada dasarnya tx_epoch_no + 2 , epoch di mana perubahan alamat stake menjadi aktif.
epoch_no di tabel reward : zaman sebenarnya di mana hadiah diperoleh.

erikd pada 5 Jan 2021

jika kredensial pasak berada dalam sertifikat pembatalan pendaftaran dari transaksi di Epoch 232, maka kredensial tersebut tidak akan disertakan dalam snapshot yang diambil pada batas 232/233. ini berarti bahwa itu tidak akan menjadi bagian dari pembaruan hadiah yang diberikan pada batas 235/236. yang, dalam istilah @erikd , adalah 234 hadiah. terlebih lagi, jika sertifikat pendaftaran ulang masuk dalam transaksi di Epoch 233, maka ini akan menjadi pembaruan hadiah _only_ yang akan dilewatkannya.

JaredCorduan pada 5 Jan 2021

perlu diperhatikan bahwa hal-hal seperti "dicabut pendaftarannya saat", "hadiah di", dan "aktif saat", dll, dapat membingungkan jika kita tidak begitu jelas. jadi tidak jelas bagi saya dengan siapa saya setuju :)

JaredCorduan pada 5 Jan 2021

Karena tampaknya ada kebingungan, saya membuat gambar yang menunjukkan dua zaman yang diharapkan hilang (db-sync 231 dan db-sync 234)

Saya pikir kebingungan berasal dari fakta bahwa 231 mungkin secara teknis tidak hilang -- bisa jadi status buku besar hanya menganggapnya didistribusikan ke cadangan alih-alih pengguna. Dari sudut pandang status buku besar, imbalan ada (didistribusikan ke cadangan), tetapi dari sudut pandang pengguna 231 tidak boleh disertakan

SebastienGllmt pada 6 Jan 2021

Saya membuat gambar yang menunjukkan dua zaman yang hilang yang diharapkan (db-sync 231 dan db-sync 234)

Tetapi hadiah sebenarnya seperti yang dilaporkan oleh db-sync adalah:

cexplorer=# select stake_address.hash_raw as "stakeAddress", "totalReward".* from stake_address
    left outer join (SELECT addr_id, amount, epoch_no  FROM reward) as "totalReward"
     on stake_address.id = "totalReward".addr_id
     where stake_address.hash_raw = '\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde' ;
                         stakeAddress                         | addr_id |  amount   | epoch_no 
--------------------------------------------------------------+---------+-----------+----------
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 162720747 |      211
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 162485461 |      212
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 167344099 |      213
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 167043060 |      214
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 200722225 |      215
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 191413549 |      216
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 143111843 |      217
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 147836812 |      218
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 154740829 |      219
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 145433327 |      220
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165631299 |      221
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 151825651 |      222
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 169141624 |      223
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165184716 |      224
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 148899668 |      225
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 157838234 |      226
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 223252352 |      227
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 147889017 |      228
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 151858721 |      229
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165782849 |      230
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 192969560 |      231
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 135711434 |      232
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 145964545 |      233
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 |    100702 |      235
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 |    102078 |      236
(25 rows)

dan hanya Epoch 234 tidak memiliki hadiah. db-sync mendapatkan isi tabel ini dari status buku besar dan satu-satunya hal yang ditambahkan db-sync adalah kolom epoch_no .

Diagram Anda tidak cocok dengan tabel ini, jadi diagram Anda kemungkinan salah. Mungkin juga ada bug di node (khususnya perhitungan saldo hadiah alamat) tetapi saya lebih suka hanya menangani satu variabel ( db-sync ) untuk saat ini.

erikd pada 6 Jan 2021

Dalam diagram Anda, Anda memiliki "hadiah yang dikirimkan" dicoret untuk Epoch 233, dan Jared dan saya pikir itu salah dan bahwa reward harus dikirimkan (karena mereka didasarkan pada snapshot di awal Epoch 231, bukan keadaan saat ini dari rantai).

erikd pada 6 Jan 2021

@SebastienGllmt mengatakan:

Saya pikir kebingungan berasal dari fakta bahwa 231 mungkin secara teknis tidak hilang -- bisa jadi status buku besar hanya menganggapnya didistribusikan ke cadangan alih-alih pengguna.

Tetapi tabel rewards menunjukkan hadiah yang didistribusikan ke alamat pasak. Jika didistribusikan ke cadangan, itu tidak akan ada di tabel ini. db-sync menerima informasi hadiah ini sebagai peta dari alamat pasak ke jumlah hadiah. Sekarang status buku besar itu sendiri mungkin salah, tetapi hanya ada sedikit ruang untuk kesalahan yang menyelinap masuk setelah peta diambil dari status buku besar.

erikd pada 6 Jan 2021

Saya salah ketika saya berkata:

apalagi, jika sertifikat pendaftaran (ulang) mendarat dalam transaksi di Epoch 233, maka ini akan menjadi satu-satunya pembaruan hadiah yang akan dilewatkan.

Faktanya, @SebastienGllmt sangat tepat ketika dia berkata:

Anda harus mengharapkan dua zaman hilang:
Zaman di mana hadiah dikirim kembali ke cadangan karena mereka tidak memiliki kunci pasak yang terdaftar
Epoch yang mewakili celah 1 epoch antara saat mereka membatalkan pendaftaran kunci dan saat mereka mendaftar ulang

Dengan tidak terdaftar pada batas epoch 232/233, kredensial pasak keduanya:

tidak mendapatkan hadiah dari pembaruan yang diterapkan pada batas 232/233, dan
tidak termasuk dalam snapshot distribusi pasak yang diambil pada batas 232/233 (sehingga tidak mendapatkan hadiah yang dibagikan pada batas 235/236).

Saya bisa menebak bagaimana db-sync melaporkan hadiah yang dibagikan pada batas 232/233 (yang sebenarnya hanya tebakan @SebastienGllmt :)). Status buku besar tidak dapat mengetahui sampai saat terakhir sebelum batas epoch kredensial mana yang masih terdaftar. Kami mengembalikan hadiah untuk kredensial yang tidak terdaftar ke cadangan. (Lihat Figure 51: Reward Update Application dalam spesifikasi formal ). db-sync mungkin tidak menghapus kredensial yang tidak terdaftar.

JaredCorduan pada 6 Jan 2021

Gambar @SebastienGllmt di atas tampak hebat, tetapi perhatikan bahwa sebenarnya panah perlu menjangkau zaman lain untuk memperhitungkan fase produksi blok. misalnya, hadiah dari snapshot yang diambil pada batas 230/231 tidak benar-benar dibagikan sampai batas 233/234.

JaredCorduan pada 6 Jan 2021

Ok sekarang kita punya penjelasan tentang ini. db-sync mempertahankan status legder dan mengeluarkan hadiah epoch sebagai Map StakeAddress Coin yang dimasukkan ke dalam database. Namun, peta itu berisi entri StakeAddress yang tidak valid dan legder-state akan menghapus entri ini secara efektif yang menyumbangkan hadiah yang diperoleh kembali ke cadangan.

Solusinya adalah juga menarik set StakeAddress valid dari status buku besar dan kemudian memfilter Map menghapus semua entri yang tidak muncul di set StakeAddress valid.

erikd pada 6 Jan 2021

Akan sangat bagus jika hadiah 'hantu' ini akan diletakkan di tabel baru seperti 'nondistributed_rewards' atau semacamnya. Ini akan memungkinkan kami untuk menghitung profitabilitas kumpulan dengan benar

dmitrystas pada 6 Jan 2021

@dmitrystas :

Akan sangat bagus jika hadiah 'hantu' ini akan diletakkan di tabel baru seperti 'nondistributed_rewards' atau semacamnya. Ini akan memungkinkan kami untuk menghitung profitabilitas kumpulan dengan benar.

Saya dapat melihat bahwa hadiah yang tidak dibagikan ini (yang kembali ke cadangan) dapat digunakan untuk menghitung profitabilitas jajak pendapat, tetapi saya cukup yakin itu bukan cara terbaik atau termudah untuk menghitungnya.

Saya telah membuat tiket khusus untuk masalah ini.

erikd pada 6 Jan 2021

Ok, saya punya solusi untuk menyaring hadiah yang tidak valid dari daftar hadiah sebelum dimasukkan dan memang ada hadiah untuk alamat itu di zaman 231 .

Sekarang saya perlu memodifikasinya sehingga hadiah "tidak valid" ini dapat ditambahkan ke tabel terpisah.

erikd pada 7 Jan 2021

🚀1

Menggunakan versi db-sync di PR #469. hadiah untuk alamat pasak \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde dimasukkan dengan benar ke dalam tabel orphaned_rewards :

cexplorer=# select stake_address.hash_raw, orphaned_reward.epoch_no, orphaned_reward.amount
         from orphaned_reward inner join stake_address on stake_address.id = orphaned_reward.addr_id
         where stake_address.hash_raw = '\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde'; 
                           hash_raw                           | epoch_no |  amount   
--------------------------------------------------------------+----------+-----------
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |      231 | 192969560

dan itu juga tidak ada di tabel hadiah:

cexplorer=# select stake_address.hash_raw as "stakeAddress", "totalReward".* from stake_address
    left outer join (SELECT addr_id, amount, epoch_no  FROM reward) as "totalReward"
     on stake_address.id = "totalReward".addr_id
     where stake_address.hash_raw = '\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde' ;
                         stakeAddress                         | addr_id |  amount   | epoch_no 
--------------------------------------------------------------+---------+-----------+----------
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 162720747 |      211
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 162485461 |      212
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 167344099 |      213
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 167043060 |      214
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 200722225 |      215
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 191413549 |      216
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 143111843 |      217
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 147836812 |      218
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 154740829 |      219
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 145433327 |      220
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165631299 |      221
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 151825651 |      222
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 169141624 |      223
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165184716 |      224
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 148899668 |      225
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 157838234 |      226
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 223252352 |      227
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 147889017 |      228
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 151858721 |      229
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165782849 |      230
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 135711434 |      232
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 145964545 |      233
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 |    100702 |      235
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 |    102078 |      236
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 |        65 |      238
(25 rows)

erikd pada 8 Jan 2021

👍2

Apakah halaman ini membantu?

0 / 5 - 0 peringkat

Masalah terkait

Pencarian DB gagal di insertTxIn: tx hash (erikd/shelley-32byte-address-hash)

cardanians · 15Komentar

cardano-cli dan db-sync menunjukkan jumlah hadiah yang berbeda dari zaman 243

dmitrystas · 7Komentar

Menjaga DB diperbarui

kzka90 · 3Komentar

Menjalankan sinkronisasi db dengan jaringan Shelley

refi93 · 15Komentar

Ketidakcocokan yang aneh antara tabel hadiah dan tabel blok

erikd · 7Komentar