Cardano-db-sync: 账户余额示例

感谢您代表我打开此问题！ 只是为了澄清一点 - 它不仅仅是关于账户本身，而是主要关于跟踪数据库中某处的reap以便它可以很容易地用于计算账户余额（在任何地方都使用，例如 pool live权益大小、池活质押等）。

@1000101什么是“收获”？ db-sync 中没有称为“reap”的表或列。

账户余额并非微不足道。

雪莱和后来时代的地址有两个组成部分； 支付凭证和质押凭证。 股权地址（例如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 存款和退休之间有足够的联系，您将如何仅针对其所有者账户之一的退回存款编写查询 - e127e9e94eaa9287680e877832700a1724255e9688609497e09a6c440f？ 如果没有，我们可以将其显式添加到 db-sync 吗？ 比方说，作为一个名为pool_refunds的新表，带有addr_id 、金额（当前应该是 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共享的负余额，但它大约有 100 行 not-so-pretm :tm ：必须为每个帐户计算的 SQL。 这肯定会帮助很多。 谢谢一米！！！