Cardano-db-sync: 口座残高の例

私に代わってこの号を開いてくれてありがとう！ もう少し明確にするために-それはアカウント自体だけでなく、主にデータベースのどこかでreapを追跡することについてであり、アカウント残高の計算に簡単に使用できます（プールライブなど、どこでも使用されます）ステークのサイズ、プールのライブ誓約など）。

@ 1000101 「刈り取り」とは何ですか？ db-syncには「reap」と呼ばれるテーブルまたは列はありません。

アカウントの残高は些細なことではありません。

シェリー以降の時代の住所には2つの要素があります。 支払いクレデンシャルとステーキングクレデンシャル。 ステークアドレス（例： stake1uyluup0rh6r2cc7kcw8nudqz990ezf5ltagxmw3u8deukvqwq7etq ）は後者から派生します。 ただし、ステーキングクレデンシャルを含まない有効なアドレスを作成することは可能です。

したがって、特定のステークアドレスのアカウント残高を取得することは可能ですが、ウォレット内のすべてのアドレスに同じステーククレデンシャルが含まれていない限り、ウォレットのアカウント残高を取得する方法はありません。

@ 1000101 「刈り取り」とは何ですか？ db-syncには「reap」と呼ばれるテーブルまたは列はありません。

ああ、これを十分に明確にしていないことをお詫び申し上げます。 私が意味したことはhttps://github.com/input-output-hk/cardano-db-sync/issues/474で説明されています-つまり、私が言っているのは、これには列がないということですが、それは素晴らしいことですあるとしたら。

現在、このアカウントがプール登録で（報酬アカウントとして）使用され、後でプールが廃止されてプールのデポジットが回復した場合、アカウントの残高を簡単に計算する方法はありません。 プールデポジットの「支払い」はdbsyncで追跡されますが、プールが廃止されたときの「払い戻し」は追跡されません。

私はこれに賛同する。 また、cardano-db-syncの各「ユーザー」が処理しなければならないエッジケースも多数あります。 以前は引退したプールの報酬アカウントであったアカウントを見ると、AdaliteとYoroiの両方が混乱しています。

また、AFAIKのみのcardanoscanが残りの報酬を正しく処理し、db-syncを使用しません。

報酬が自動的に追加されるのと同じ方法で更新される簡単な関係があるはずです。 例として、複数の登録解除を含むプールを取り上げましょう。これは実際にはかなり一般的であり、所有者アカウントの報酬残高を処理するのが難しいためです。

それに9つの退職証明書があります

そして15の登録証明書

新しい証明書によって却下される引退の多くのエッジケースと漠然としたルールがあります。

@ erikd 、500 txの預金と退職金の間の十分な接続を主張する場合、所有者アカウントの1つ（e127e9e94eaa9287680e877832700a1724255e9688609497e09a6c440f）の返還された預金だけのクエリをどのように記述しますか？ そうでない場合、これを明示的にdb-syncに追加できますか？ たとえば、 pool_refundsという名前の新しいテーブルとして、 addr_id 、 amount （現在は500の倍数である必要があります）およびepoch_noを使用して、これが正しく、単一の場所で処理されるようにします。

現在、 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が共有するマイナスのバランスに達することはありませんが、アカウントごとに計算する必要があるSQLは約100行です。 これは間違いなく1トンに役立ちます。 ミルありがとう!!!