Cardano-db-sync: 계정 잔액 예

저를 대신하여 이 문제를 열어주셔서 감사합니다! 좀 더 명확히 하자면 - 계정 자체에 관한 것이 아니라 주로 db의 어딘가에서 reap 를 추적하는 것에 관한 것이므로 계정 잔액 계산에 쉽게 사용할 수 있습니다(예: 풀 라이브 스테이크 크기, 풀 라이브 서약 등).

@1000101 "reap"이 무엇입니까? db-sync에는 "reap"이라는 테이블이나 열이 없습니다.

계정 잔액은 사소한 것이 아닙니다.

Shelley 및 이후 시대의 주소에는 두 가지 구성 요소가 있습니다. 지불 자격 증명 및 스테이킹 자격 증명. 스테이크 주소(예: stake1uyluup0rh6r2cc7kcw8nudqz990ezf5ltagxmw3u8deukvqwq7etq )는 나중에 파생됩니다. 그러나 스테이킹 자격 증명을 포함하지 않는 유효한 주소를 구성하는 것은 가능합니다.

따라서 특정 스테이크 주소에 대한 계정 잔액을 얻을 수는 있지만 해당 지갑의 모든 주소에 동일한 스테이킹 자격 증명이 포함되어 있지 않으면 지갑의 계정 잔액을 얻을 수 있는 방법이 없습니다.

@1000101 "reap"이 무엇입니까? db-sync에는 "reap"이라는 테이블이나 열이 없습니다.

아, 이것에 대해 충분히 설명하지 못해 죄송합니다. 내가 의미하는 바는 https://github.com/input-output-hk/cardano-db-sync/issues/474 에 설명되어 있습니다. 즉, 내가 말하는 것은 정확히 이에 대한 열이 없지만 좋을 것입니다. 있다면.

이 계정이 풀 등록(보상 계정으로)에 사용되었고 나중에 풀이 폐기되어 풀 예치금을 되찾는 경우 현재 계정 잔액을 쉽게 계산할 수 있는 방법이 없습니다. 풀 보증금의 "지불"은 dbsync에서 추적되지만 풀이 폐기될 때의 "환불"은 추적되지 않습니다.

나는 이것에 동의합니다. 또한 cardano-db-sync의 각 "사용자"가 처리해야 하는 수많은 엣지 케이스가 있습니다. Adalite와 Yoroi는 이전에 은퇴 풀의 보상 계정이었던 계정을 보고 혼란스러워합니다.

또한 AFAIK only cardanoscan은 나머지 보상을 올바르게 처리하며 db-sync를 사용하지 않습니다.

보상이 자동으로 추가되는 것과 같은 방식으로 업데이트되는 쉬운 관계가 있어야 합니다. 여러 등록 취소가 있는 풀을 예로 들어 보겠습니다. 이는 실제로 매우 일반적이고 소유자 계정의 보상 잔액을 처리하기 어렵기 때문입니다.

9개의 퇴직 증명서가 있습니다.

그리고 15개의 등록증

새로운 인증서에 의해 무효화되는 수많은 예외적인 경우와 퇴직 의 모호한 규칙이 있습니다.

@erikd , 500 tx 예금과 퇴직금 사이에 충분한 연결을 주장한다면 소유자 계정 중 하나의 반환 된 예금에 대한 쿼리를 어떻게 작성하겠습니까? 그렇지 않다면 이것을 db-sync에 명시적으로 추가할 수 있습니까? addr_id , amount (현재는 500의 배수여야 함) 및 epoch_no 가 있는 pool_refunds 라는 이름의 새 테이블을 가정해 봅시다. 그래야 한 곳에서 올바르게 처리됩니다.

현재 db-sync 는 원장 상태에서 데이터를 추출하고 데이터베이스에 삽입합니다. 일부 정보를 삭제하지만 집계는 수행하지 않습니다. 데이터베이스에 삽입되는 것은 단순히 원장 상태가 제공하는 것을 반영한 것입니다.

관련 pool_hash.id 를 살펴보겠습니다.

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

풀은 다음과 같이 등록되었습니다( block_no 오름차순으로 추가 조인).

> 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)

다음에서 등록 취소:

> 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)

업데이트 및 등록 취소를 인터리빙 해제:

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

계속하려면 ....

이것은 확실히 목이 너무 아프다. 원장 사양의 사람들과 대화하여 솔루션을 마련하려고 합니다.

더 나은 해결책을 기다리는 동안 지금 당장은 그것을 퍼지할 빠르고 더러운 방법을 제안한 ledger-specs 사람들과 이야기했습니다.

아이디어는 스테이크 주소와 금액이 포함된 pool_registration_refund 테이블과 같은 것입니다.

정말 좋을 것 같아요!

더 나은 해결책을 기다리는 동안 지금 당장은 그것을 퍼지할 빠르고 더러운 방법을 제안한 ledger-specs 사람들과 이야기했습니다.

아이디어는 스테이크 주소와 금액이 포함된 pool_registration_refund 테이블과 같은 것입니다.

엄청난! 내 말은, 우리는 현재 해결 방법을 가지고 있으므로 @xdzurman이 공유한 마이너스 잔액에 도달하지 않습니다. 그러나 모든 계정마다 계산해야 하는 약 100줄의 not-so- pretty:tm : SQL입니다. 이것은 확실히 도움이 될 것입니다. 밀리 감사합니다!!!