Cardano-db-sync: 보상 테이블과 블록 테이블 간의 홀수 불일치

이것은 #361과 다릅니다. 위에서 addr_id 를 보면 다음과 같습니다.

cexplorer=# select * from delegation where addr_id = 92628 ;
 id | addr_id | cert_index | pool_hash_id | active_epoch_no | tx_id 
----+---------+------------+--------------+-----------------+-------
(0 rows)

즉, 이 addr_id 는 확인하기 쉬운 풀 업데이트에 대한 보상 주소여야 합니다.

cexplorer=# select id, hash_id, pledge, margin, fixed_cost, active_epoch_no, reward_addr_id
              from pool_update where reward_addr_id = 92628 ;
  id  | hash_id | pledge | margin | fixed_cost | active_epoch_no | reward_addr_id 
------+---------+--------+--------+------------+-----------------+----------------
 4621 |    1245 |      0 |      1 |  340000000 |             218 |          92628
 4622 |    1246 |      0 |      1 |  340000000 |             218 |          92628
 4623 |    1247 |      0 |      1 |  340000000 |             218 |          92628
 4624 |    1248 |      0 |      1 |  340000000 |             218 |          92628
 4625 |    1249 |      0 |      1 |  340000000 |             218 |          92628
 4626 |    1250 |      0 |      1 |  340000000 |             218 |          92628
 5683 |    1245 |      0 |      1 |  340000000 |             224 |          92628
 5684 |    1246 |      0 |      1 |  340000000 |             224 |          92628
 5685 |    1247 |      0 |      1 |  340000000 |             224 |          92628
(9 rows)

이는 이 주소가 여러 다른 풀에 대한 보상 주소임을 의미합니다. 이것이 문제여야 합니다.

이것은 까다 롭습니다. 내 머릿속에는 단일 stake_address 가 단일 풀에만 위임할 수 있다는 가정이 있었습니다. 그것이 사실이지만 단일 stake_address 는 둘 이상의 풀에 대한 보상 주소로 사용될 수 있습니다.

실제로는 그보다 더 복잡합니다. stake_address 가 두 개의 풀에 대한 보상 주소로 사용되는 경우 보상 금액은 각 풀에 대한 보상의 합이 됩니다. 내가 현재 가지고 있는 것을 감안할 때 이 달걀이 스크램블 해제될 수 있는지 확신할 수 없습니다.

이것은 까다롭기만 한 것이 아니라 완전한 벌레 통조림입니다.

@JaredCorduan과 IOHK 내부 Slack에서 채팅한 후 db-sync 의 온체인 데이터 처리가 완전히 정확하지 않고 일부 SPO가 풀을 올바르게 설정하지 않았을 수 있음을 깨달았습니다.

첫째, 풀 자체가 스테이크 주소로 등록된 적이 없는 스테이크/보상 주소로 등록된 경우 Shelley 디자인 사양 의 섹션 3.3.4 또는 3번 항목에 따라:

보상 주소가 등록되지 않은 경우 스테이크 풀 운영자는 보상을 받을 수 없습니다. 이 경우, 그들이 받아야 할 모든 보상은 대신 예비금으로 다시 보내집니다(그러나 스테이크 풀 구성원은 여전히 ​​일반적인 보상을 받습니다).

둘째, 두 개 이상의 풀이 동일한 스테이크/보상 주소로 등록되고 두 개 이상의 풀이 보상을 받으면 첫 번째("첫 번째"는 어떻게 결정되나요?) 풀에 대한 보상만 해당 주소로 이동하고 나머지는 모두 다음으로 이동합니다. 준비금/재고. 아직 이에 대한 적절한 문서를 찾지 못했습니다.

@erikd 어제 제가 말한 내용이 틀렸습니다. 죄송합니다. 오늘 사양과 구현을 모두 확인했으며 다음과 같이 동의하고 작동합니다.

스테이크 풀 인증서의 보상 계정:

• 등록해야합니다
• 위임할 필요가 없습니다

또한 두 개의 풀이 공통 보상 계정을 나열하는 경우 해당 계정은 보상의 합계를 얻습니다.

현재 이 문제에 대한 수정 사항이 하위 수준 라이브러리에 있는 것 같습니다. @JaredCorduan 이 조사 중입니다.

여기서 무슨 일이 일어나고 있는지 확실하지 않습니다. 여러가지가 바뀌었다.

> select * from pool_hash
      where pool_hash.hash_raw = '\x964d8d35d91603e0dcfbc64891ee8ffeba0e503ca96bf627bc8bcb55' ;
  id  |                          hash_raw                          |                           view                           
------+------------------------------------------------------------+----------------------------------------------------------
 4626 | \x964d8d35d91603e0dcfbc64891ee8ffeba0e503ca96bf627bc8bcb55 | pool1jexc6dwezcp7ph8mceyfrm50l6aqu5pu494lvfau309422t9c6z

하지만:

> select reward.* from pool_hash
      inner join reward on reward.pool_id = pool_hash.id
      where pool_hash.hash_raw = '\x964d8d35d91603e0dcfbc64891ee8ffeba0e503ca96bf627bc8bcb55' ;
 id | addr_id | amount | epoch_no | pool_id | block_id | type 
----+---------+--------+----------+---------+----------+------
(0 rows)

이 쿼리는 f7ee30a245131255f816d6952ef6f0b938e61b94 커밋 시 master 를 실행하는 데이터베이스에 대해 실행되었습니다.

아, 하지만 보상 테이블(0개 항목을 반환함)의 쿼리는 정확합니다.

> select block.block_no, slot_leader.pool_hash_id
              from block inner join slot_leader on block.slot_leader_id = slot_leader.id
              where pool_hash_id = 4626 ;
 block_no | pool_hash_id 
----------+--------------
(0 rows)

따라서 이상한 불일치가 사라지고 이 티켓을 닫을 수 있습니다.