Cardano-db-sync: 보상은 미등록 지분 주소로 분배되었습니다.

에 만든 2020년 12월 02일 · 28코멘트 · 출처: input-output-hk/cardano-db-sync

메인 넷, db-sync 6.0.1, 지분 주소 stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86

등록 내역

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)

등록 취소 내역

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)

보시다시피, 주소는 232 에포크가 끝날 때 등록되지 않았으며 에포크 231에 대한 보상은이 주소로 분배되지 않아야합니다.

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

출처

dmitrystas

👀4 👍1

가장 유용한 댓글

PR # 469에서 db-sync 버전 사용. 스테이크 주소 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde 대한 보상이 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

또한 보상 테이블에도 없습니다.

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 에 2021년 01월 08일

👍2

모든 28 댓글

: 페이스 팜 :

잠시 동안 이것을보고 갑자기 첫 번째 쿼리가 @dmitrystas 가 보여준 것을 보여주지 않는다는 것을 깨달았습니다. tx.id = stake_registration.tx_id 에 가입 한 다음 거래에서 block.epoch_no 를 가져 오면 스테이크 등록 / 해체가 발생하는 시대를 얻을 수 있지만 실제로 활성화 된 시기는 얻을 수 없습니다.

스테이 킹과 관련된 대부분의 작업의 경우 N 에포크에서 발생하는 동작 (등록, 스테이 킹 금액 증가 등)이 N + 2 활성화 됩니다.

즉, 첫 번째 쿼리는 실제로 다음과 같아야합니다.

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

그리고 두 번째 :

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 그 모든 것이 active_epoch_no 받는 열 stake_registration 및 stake_deregistration I이 (가)이 같은 테이블을 delegation 테이블을?

erikd 에 2020년 12월 17일

@erikd 안녕하세요. 그것은 원래 문제입니다 https://github.com/Emurgo/yoroi-frontend/issues/1832#issue -754776885
아마도 유용 할 수 있습니다

Yoroi & Adalite는 잘못된 192 FAKE ADA 보상을 보여 주지만 실제로는 0입니다. 마지막 2 개의 보상은 adawallet.io를 통해 인출됩니다 (db-sync를 사용하지 않음).

단계별 문제에 대한 간단한 설명 :
1) 에포크 232 . 나는 보상을 철회하고 동시에 스테이 킹 키 를
2) 에포크 233 . 키가 등록 된 경우 먼저 남은 보상을 받아야하는데, 그렇지 않은 경우 Yoroi가 192ADA를 받았다고 표시합니다. 출금을 시도하면 Yoroi가 오류를 발생시킵니다. db-sync show reward 0ADA를 사용하지 않는 다른 지갑
3) 에포크 233 . 다시 같은 풀에 위임합니다. 키가 등록되었습니다 . 진정한 보상 0. Yoroi 보상 192.
4) 에포크 234 . 남은 두 번째 보상 135ADA를받습니다. 실제 보상 잔액은 135ADA입니다.
Yoroi는 327ADA (192 + 135)를 보여줍니다. 요로이를 통해 어떤 보상도 인출 할 수 없습니다. 거래를 보내는 동안 서버에서 오류를 받았습니다.
5) 에포크 235 . 마지막 세 번째 보상 인 145ADA를 받았습니다. 실제 보상 잔액은 280ADA (135 + 145)입니다.
Yoroi는 472ADA를 보여줍니다. (192 + 135 + 145) Yoroi를 통해 어떤 보상도 인출 할 수 없습니다. 트랜잭션을 보내는 동안 서버에서 오류를 받았습니다.
6) 에포크 235 . db-syns를 사용하지 않는 adawallet.io를 통해 원활하게 280ADA를 인출하고 정확한 보상 잔액을 보여줍니다 280ADA
7) 280ADA의 실제 보상이 철회 된 후에도 (0ADA로 남아 있음) Yoroi는 여전히 보상 잔액 192ADA를 보여줍니다.

IlyaSofronov 에 2020년 12월 17일

Yoroi는 여전히 보상 잔액 192ADA를 보여줍니다.

적어도 두 가지 가능성이 있습니다.

db-sync 버그가 있습니다
요로이 버그가 있습니다

나는 db-sync 만 처리합니다. 즉, Yoroi의 정보가 아닌 SQL 쿼리로 문제가 표시되어야합니다.

stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86 가 여기서 관심의 대상이됩니까?

erikd 에 2020년 12월 17일

@erikd yes 스테이크 키는 스테이크입니다.
Yoroi뿐만 아니라 Adalite.io 및 adastat.net에도 해당 버그가 있습니다.
Theese에는 해당 버그가 없습니다 : cardanoscan.io 및 adawallet.io

IlyaSofronov 에 2020년 12월 18일

일부 온라인 지갑에는이 버그가 있고 다른 지갑에는 버그가없고이 모든 것이 db-sync 에 의존한다면 문제는 db-sync 에있을 가능성이 매우 낮습니다.

erikd 에 2020년 12월 18일

@erikd 하지만 adawallet.io는 db-sync를 사용하지 않고 올바른 보상 잔액 (0ADA)을 보여 주므로 마지막 보상을 인출 할 수 있습니다.

IlyaSofronov 에 2020년 12월 18일

다시 이것은 이것이 db-sync 버그가 아니라 Yoroi 버그임을 시사합니다.

erikd 에 2020년 12월 18일

출애굽기에서도이 버그가 발생했습니다.

roccomuso 에 2021년 01월 04일

이것은 확실히 cardano-db-sync 버그이며 Yoroi뿐만 아니라 cardano-db-sync의 여러 다른 사용자에게 영향을 미치는 방식을 고려할 때 Yoroi 버그가 아닙니다. cardanoscan과 adawallet은 모두 cardano-db-sync를 사용하지 않으므로 영향을받지 않습니다.

cardano-db-sync가보고하는 내용

@IlyaSofronov에서 제공 한 주소에 대한 보상 내역을 제공하는 SQL 쿼리는 다음과 같습니다.

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'

다음 결과를 제공합니다

 \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

참고 :이 행의 합계는 3,765,004,402입니다.

백엔드의 현재 (잘못된) 상태

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

백엔드가 rewards 값에 대한 db-sync 행의 합계를 반환하는 것을 볼 수 있습니다 (이 문제가 나중에 발생한 이유를 설명합니다).

이 버그의 영향을받지 않는다는 것을 알고있는 cardanoscan의 값을 합산 하여 withdrawals 금액이 정확한지 확인할 수도 있습니다.

remainingAmount 은 (는) rewards - withdrawals

지갑 등록 내역

이 스테이 킹 키의 내역을 보면 다음을 확인할 수 있습니다.

Epoch 232에 등록 취소 되었습니다.
에포크 233에 재 등록 되었습니다.

카르 다노 노드의 현재 상태

내 cardano-node 인스턴스에 따르면 이것은 스테이 킹 주소 내의 현재 값입니다.

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

따라서 노드에 따라 지갑의 잔액이 epoch 235 + epoch 236 (100702 + 102078 = 202780)임을 알 수 있습니다.

그래서 무엇이 문제입니까?

cardanoscan 을 보면 지갑의 전체 출금 내역을 볼 수 있습니다. 각 인출에 해당하는 내용을 살펴 보겠습니다.

| Epoch 철회 | 인출 금액 | db-sync epoch 행 포함 |
| ----------------- | ------------------ | ------------ ----------------- |
| 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 |

그러나 cardano-db-sync (192969560)의 epoch 231은 이들 중 어느 것도 포함되지 않음을 알 수 있습니다!

물론 백엔드 응답 "remainingAmount": "193172340", 를보고 잘못 포함 된 epoch 231을 제거하면 193172340 - 192969560 = 202780 이는 풀 노드에서 예상되는 결과입니다!

결론

내 조사에 따르면 cardano-db-sync가 보상 내역 결과에 231 행을 포함해서는 안되는 것 같습니다.

SebastienGllmt 에 2021년 01월 04일

첫 번째 쿼리를 단순화하고 동일한 결과를 얻었는지 확인했습니다.

백엔드의 현재 (잘못된) 상태

단일 소스에서 모든 정보를 얻고 싶습니다.

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

과:

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

둘 다 당신의 수치와 일치합니다.

흥미롭게도 3571832062 + 192969560 + 202780 - 3765004402 여기서 3571832062 는 인출 합계이고 3765004402 는 보상 합계입니다. 다른 값은 다음과 같습니다. 202780 는 인출 후 보상 잔액에 대한 수치이고 192969560 는 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

그렇다면 그 보상은 231 ( db-sync 단순히 원장 상태에서 꺼내 추가 처리없이 데이터베이스에 삽입 함)가 맞습니까? 해당 스테이크 주소에 대한 스테이크 등록 내역을 살펴 보겠습니다.

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

등록 및 등록 취소 모두에 대해 tx_id (등록 / 해제를 포함하는 tx의 ID), tx_epoch_no (tx가 포함 된 epoch) 및 active_epoch_no (등록 / 해체가 활성화되는 시대).

활성화 된 에포크 번호를 보면 스테이크 등록이 에포크 [210 .. 233] 및 [235 ..] 에 활성화되어 있어야합니다. 이것은이 주소에 대한 실제 보상과 일치합니다.

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)

즉, 234 제외한 모든 세대에 대한 보상이 있습니다.

따라서 나는 당신의 결론을 생각합니다.

내 조사에 따르면 cardano-db-sync가 보상 내역 결과에 231 행을 포함해서는 안되는 것 같습니다.

정확하지 않은 경우 해당 스테이크 주소에는 231 에포크에 대한 보상이 있어야합니다 .

또한 귀하의 의견은 다음과 같습니다.

백엔드의 현재 (잘못된) 상태
{
"remainingAmount": "193172340",
"보상": "3765004402",
"출금": "3571832062",
}

실제로 정확합니다. 보상 가치와 인출 가치의 차이는 현재 인출되지 않은 보상 잔액입니다.

erikd 에 2021년 01월 05일

실제로 정확합니다. 보상 가치와 인출 가치의 차이는 현재 인출되지 않은 보상 잔액입니다.

우리는 노드가 정상으로 돌아 알고 있기 때문에 그 경우가 될 수 없습니다 202780 계정에 대한 보상의 균형 등이 아닌 193172340

즉, 234를 제외한 모든 시대에 대한 보상이 있습니다.

두 시대가 누락 될 것으로 예상해야합니다.

지분 키가 등록되지 않았기 때문에 보상이 예비금으로 다시 전송 된 시대
키 등록 취소 시점과 재 등록 시점 사이의 1 세대 간격을 나타내는 시대

누락 된 234 epoch는 (2)에 해당하고 231은 (1)에 해당한다고 생각합니다. (1)

SebastienGllmt 에 2021년 01월 05일

두 시대가 누락 될 것으로 예상해야합니다.

왜? 이 스테이크 주소에 대한 운영에 따르면 :

| 운영 | tx_epoch_no | active_epoch_no |
| ------------------- | --------------------- | ------- --------- |
| 등록 | 208 | 210 |
| deregistraion | 232 | 234 |
| 등록 | 233 | 235 |

단일 에포크 ( 234 )에 대해서만 등록이 취소되었으며 해당 에포크에 대한 보상을받지 못했습니다.

보상이없는 두 시대가있는 이유는 무엇입니까? 나는 당신이 언급 한 두 가지 사례가 실제로 동일한 것이라고 확신하므로 보상 없이는 단 하나의 시대 만 진행됩니다.

erikd 에 2021년 01월 05일

Slack의 @SebastienGllmt 는 다음과 같이 말했습니다.

등록 취소는 2 epoch가 아니라 즉시 수행된다는 점에서 특별합니다.

등록 취소가 즉시 진행되면 tx_epoch_no == 232 했으므로 231에 대한 보상뿐만 아니라 epochs [231..234] 대한 보상이 모두 손실됩니다.

@JaredCorduan 이 필요하다고 생각합니다.

erikd 에 2021년 01월 05일

@SebastienGllmt 의 설명은 원장 규칙과 일치합니다.

스테이크 자격 증명이 등록 취소되는 것은 다소 철학적 인 "언제"이지만 다음과 같이 표현합니다. 등록 취소는 즉시 이루어 지지만 보상은 지연됩니다. 자격 증명이 e 에포크에서 등록 취소되면 e / e+1 경계 ( e-2 / e -1 경계에서 찍은 스냅 샷에서 발생)에서 보상을 받게되며 또한 에 대한 보상을받을 e+1 / e+2 경계 (에 찍은 스냅 샷에서 나오는 e-1 / e 경계).

JaredCorduan 에 2021년 01월 05일

명명법과 약간의 혼동이있는 것 같습니다.

dbs-ync 의 POV에서 : :

tx_epoch_no : 등록 / 해체 인증서의 거래를 포함하는 시대.
active_epoch_no : 기본적으로 tx_epoch_no + 2 , 스테이크 주소 변경이 활성화되는 시대.
epoch_no reward 테이블의 epoch_no : 보상이 획득 된 실제 시대.

erikd 에 2021년 01월 05일

스테이크 자격 증명이 epoch 232 트랜잭션의 등록 취소 인증서에있는 경우 232/233 경계에서 찍은 스냅 샷에 포함되지 않습니다. 이는 235/236 경계에서 전달되는 보상 업데이트의 일부가 아님을 의미합니다. @erikd 의 용어로는 234 개의 보상이 있습니다. 또한, (재) 등록 인증서가 233기에 거래에 들어갔다면 놓칠 _only_ 보상 업데이트가 될 것입니다.

JaredCorduan 에 2021년 01월 05일

"언제 등록 취소", "보상", "활성화시기"등과 같은 항목이 명확하지 않은 경우 혼란 스러울 수 있습니다. 그래서 내가 동의하는 사람이 누구인지 명확하지 않습니다. :)

JaredCorduan 에 2021년 01월 05일

혼란스러워 보이기 때문에 예상했던 두 개의 누락 된 epoch (db-sync 231 및 db-sync 234)를 보여주는 사진을 만들었습니다.

혼란은 231이 기술적으로 누락되지 않았을 수 있다는 사실에서 비롯된 것이라고 생각합니다. 원장 상태가 사용자 대신 예비금에 배포 된 것으로 간주 할 수 있습니다. 원장 상태 관점에서 보상이 존재하지만 (예비금에 분배 됨) 사용자 관점에서 231은 포함되지 않아야합니다.

SebastienGllmt 에 2021년 01월 06일

두 가지 예상 누락 된 epoch (db-sync 231 및 db-sync 234)를 보여주는 사진을 만들었습니다.

그러나 db-sync 보고 한 실제 보상은 다음과 같습니다.

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)

그리고 234 시대에만 보상이 없습니다. db-sync 는 원장 상태에서이 테이블의 내용을 가져오고 db-sync 추가하는 유일한 것은 epoch_no 열입니다.

다이어그램이이 표와 일치하지 않으므로 다이어그램이 올바르지 않을 수 있습니다. node (특히 주소 보상 잔액 계산)에도 버그가있을 수 있지만 지금은 단일 변수 ( db-sync ) 만 처리하는 것이 좋습니다.

erikd 에 2021년 01월 06일

당신의 다이어그램에서 당신은 에포크 233에 대해 "보상 전달"을 지우고, Jared와 저는 그것이 틀 렸으며 보상이 전달되어야한다고 생각합니다. 사슬).

erikd 에 2021년 01월 06일

@SebastienGllmt 말한다 :

혼란은 231이 기술적으로 누락되지 않았을 수 있다는 사실에서 비롯된 것이라고 생각합니다. 원장 상태가 사용자 대신 예비금에 배포 된 것으로 간주 할 수 있습니다.

그러나 rewards 테이블은 스테이크 주소로 분배되는 보상을 보여줍니다. 예비금에 분배 된 경우이 테이블에 없습니다. db-sync 는이 보상 정보를 스테이크 주소에서 보상 금액에 대한 맵으로받습니다. 이제 원장 상태 자체가 잘못되었을 수 있지만 원장 상태에서 맵을 검색 한 후에는 오류가 발생할 여지가 거의 없습니다.

erikd 에 2021년 01월 06일

내가 말했을 때 나는 틀렸다.

또한 (재) 등록 인증서가 233 년에 거래에 들어갔다면 이것이 놓칠 유일한 보상 업데이트가 될 것입니다.

실제로 @SebastienGllmt 는 다음과 같이

두 시대가 누락 될 것으로 예상해야합니다.
지분 키가 등록되지 않았기 때문에 보상이 예비금으로 다시 전송 된 시대
키 등록 취소 시점과 재 등록 시점 사이의 1 세대 간격을 나타내는 시대

232/233 epoch 경계에 등록되지 않은 스테이크 자격 증명은 다음과 같습니다.

232/233 경계에 적용되는 업데이트로부터 보상을받지 못하며
232/233 경계에서 촬영 한 지분 분배 스냅 샷에는 포함되지 않습니다 (235/236 경계에서 보상을받지 못함).

나는 db-sync가 232/233 경계 (실제로는 @SebastienGllmt 의 추측 일 공식 사양의 Figure 51: Reward Update Application 참조). db-sync가 등록되지 않은 자격 증명을 제거하지 않을 수 있습니다.

JaredCorduan 에 2021년 01월 06일

위의 @SebastienGllmt 의 사진은 멋져 보이지만 실제로 화살표는 블록 생성 단계를 설명하기 위해 다른 시대에 걸쳐 있어야합니다. 예를 들어, 230/231 경계에서 찍은 스냅 샷의 보상은 233/234 경계까지 실제로 나눠지지 않습니다.

JaredCorduan 에 2021년 01월 06일

이제 이에 대한 설명이 있습니다. db-sync 는 legder-state를 유지하고 epoch 보상을 Map StakeAddress Coin 가져 와서 데이터베이스에 삽입합니다. 그러나 해당 맵에는 유효하지 않은 StakeAddress 항목이 포함되어 있으며, legder-state는 이러한 항목을 삭제하여 적립금에 대한 보상을 효과적으로 기여합니다.

해결책은 또한 원장 상태에서 유효한 StakeAddress 집합을 가져온 다음 유효한 StakeAddress es 집합에서 발생하지 않는 모든 항목을 삭제하여 Map 를 필터링하는 것입니다.

erikd 에 2021년 01월 06일

이 '팬텀'보상이 'nondistributed_rewards'또는 이와 비슷한 새로운 테이블에 배치되면 좋을 것입니다. 이를 통해 풀 수익성을 정확하게 계산할 수 있습니다.

dmitrystas 에 2021년 01월 06일

@dmitrystas :

이 '팬텀'보상이 'nondistributed_rewards'또는 이와 비슷한 새로운 테이블에 배치되면 좋을 것입니다. 이를 통해 풀 수익성을 올바르게 계산할 수 있습니다.

나는 (예비로 돌아가)이 유보 보상이 계산 설문 조사 수익성에 사용하지만 난 확신 최선하거나 계산하는 가장 쉬운 방법은 아니라고 생각 될 수 있음을 알 수있다.

이 문제에 대한 티켓을 특별히 만들었습니다.

erikd 에 2021년 01월 06일

좋아, 삽입하기 전에 보상 목록에서 잘못된 보상을 걸러내는 솔루션이 있으며 실제로 해당 주소에 대한 보상이 231 있습니다.

이제 이러한 "잘못된"보상을 별도의 테이블에 추가 할 수 있도록 수정해야합니다.

erikd 에 2021년 01월 07일

🚀1

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

또한 보상 테이블에도 없습니다.

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 에 2021년 01월 08일

👍2

이 페이지가 도움이 되었나요?

0 / 5 - 0 등급

Cardano-db-sync: 보상은 미등록 지분 주소로 분배되었습니다.

가장 유용한 댓글

모든 28 댓글

cardano-db-sync가보고하는 내용

백엔드의 현재 (잘못된) 상태

지갑 등록 내역

카르 다노 노드의 현재 상태

그래서 무엇이 문제입니까?

결론

관련 문제