主网，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 epoch结束时还没有注册，231 epoch的奖励不应该分配到这个地址，但是
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)
dmitrystas
所有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这一切都加起来了吗？ 是否有助于向stake_registration和stake_deregistration表添加额外的active_epoch_no列，就像我有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 。 我同时撤回奖励并注销staking key 。 奖励为 0。我有足够的 ADA 来支付费用
2）纪元233 。 如果我的钥匙被注册了，我应该收到第一个剩余的奖励，但它没有，但 Yoroi 显示收到了 192ADA。 当我尝试退出时，Yoroi 抛出错误。 其他不使用 db-sync 的钱包显示奖励 0ADA
3）纪元233 。 我再次委托给同一个池。 密钥已注册。 真实奖励 0. Yoroi 奖励 192。
4）纪元234 。 我收到第二个剩余的奖励 135ADA。 真正的奖励余额是 135ADA。
Yoroi 显示 327ADA (192+135)。 无法通过 Yoroi 提取任何奖励 我在发送交易时从服务器收到错误。
5）纪元235 。 我收到了最后三分之一的奖励 145ADA。 真正的奖励余额是 280ADA (135+145)。
Yoroi 显示 472ADA (192+135+145) 无法通过 Yoroi 提取任何奖励 我在发送交易时从服务器收到错误。
6）纪元235 。 我通过adawallet.io顺利提现280ADA，不使用db-syns，正确显示奖励余额280ADA
7）280ADA的真实奖励被撤回后（剩余0ADA）Yoroi仍然显示奖励余额192ADA。
IlyaSofronov
于 2020-12-17
Yoroi 仍然显示奖励余额 192ADA。
至少有两种可能；
- 有一个
db-sync错误 - 有一个 Yoroi 错误
我只处理db-sync 。 这意味着问题需要作为 SQL 查询而不是来自 Yoroi 的信息呈现给我。
stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86是这里感兴趣的权益密钥吗？
erikd
于 2020-12-17
@erikd是的，股权密钥是 stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86
请注意，不仅 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
这再次表明这是一个 Yoroi 错误，而不是db-sync错误。
erikd
于 2020-12-18
Exodus 也遇到了这个错误。
roccomuso
于 2021-01-04
这绝对是一个 cardano-db-sync 错误，而不是 Yoroi 错误，因为这不仅会影响 Yoroi，还会影响 cardano-db-sync 的多个其他用户。 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 行的总和（稍后将解释为什么会出现这个问题）
您还可以通过总结我们知道不受此错误影响的withdrawals金额是否正确。
remainingAmount只是rewards - withdrawals
钱包的注册历史
通过查看这个 staking key 的历史，你可以看到：
- 它在纪元 232 被注销
- 它在纪元 233重新注册
卡尔达诺节点的当前状态
根据我的 cardano-node 实例，这是质押地址内的当前值
[
{
"address": "stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86",
"delegation": "pool1kkfkdces5mdcyc9dn2hgg3463jggjvw3h89nejjarkz25uavaqu",
"rewardAccountBalance": 202780
}
]
所以可以看到根据节点，钱包的余额是epoch 235 + epoch 236 (100702 + 102078 = 202780)
那么问题是什么？
通过查看cardanoscan，我们可以看到钱包的完整提款历史。 让我们看看每次提款对应的是什么：
| 时代撤回| 提款金额 | 包含 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) 中的纪元 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是 epoch 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
那么对于 epoch 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 的纪元）和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之外，每个 epoch 都有奖励。
因此我认为你的结论是：
根据我的调查，cardano-db-sync 似乎在奖励历史结果中包含第 231 行，即使它不应该。
是不正确的，该权益地址应该有 epoch 231奖励。
此外，我相信您的评论：
我们后端的当前（不正确）状态
{
"remainingAmount": "193172340",
"奖励": "3765004402",
"提款": "3571832062",
}
实际上是正确的。 奖励值和提现值之间的差值是当前未提现的奖励余额。
erikd
于 2021-01-05
实际上是正确的。 奖励值和提现值之间的差值是当前未提现的奖励余额。
事实并非如此，因为我们知道节点返回202780作为帐户的奖励余额而不是193172340
即，除了 234 之外，每个 epoch 都有奖励。
您应该预期会丢失两个纪元：
- 奖励被送回储备的时代，因为他们没有注册他们的权益密钥
- 代表注销密钥和重新注册密钥之间的 1 个纪元间隔的纪元
丢失的234纪元对应于 (2)，我相信 231 对应于 (1)，因为 231 意味着它应该在 233 纪元的用户钱包中可见，这正是我们期望被没收的纪元(1)
SebastienGllmt
于 2021-01-05
您应该预期会丢失两个纪元：
为什么？ 根据对该权益地址的操作：
| 操作 | tx_epoch_no | active_epoch_no |
|--------------------|---------------------|------- ---------|
| 注册 | 208 | 210 |
| 注销| 第232话第234话
| 注册 | 第233话第235话
它仅在一个 epoch ( 234 ) 内被注销，并且在那个 epoch 中没有收到任何奖励。
为什么会有两个没有奖励的 epoch？ 我很确定你提到的两个案例实际上是一回事，因此只有一个时代没有奖励。
erikd
于 2021-01-05
Slack 中的@SebastienGllmt说：
注销的特殊之处在于它立即发生，而不是在 2 个时期内
如果立即取消注册，这会发生在tx_epoch_no == 232因此[231..234]时期的奖励将全部丢失，而不仅仅是 231 的奖励。
我认为我们需要@JaredCorduan 。
erikd
于 2021-01-05
@SebastienGllmt的解释与分类帐规则一致。
“何时”取消注册权益凭证有点哲学，但我会这样说：取消注册立即发生，但奖励会延迟。 如果凭证在 epoch 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_noreward表中的
erikd
于 2021-01-05
如果权益凭证在 232 纪元交易的注销证书中，则它不会包含在 232/233 边界上拍摄的快照中。 这意味着它不会成为在 235/236 边界上分发的奖励更新的一部分。 用@erikd的话来说，这是 234 奖励。 此外，如果（重新）注册证书在 233 纪元的交易中登陆，那么这将是它会错过的 _only_ 奖励更新。
JaredCorduan
于 2021-01-05
值得注意的是，如果我们不是很清楚，诸如“注销时间”、“奖励时间”和“活动时间”等内容可能会造成混淆。 所以我不清楚我同意谁:)
JaredCorduan
于 2021-01-05
由于似乎有混淆，我制作了一张图片，显示了两个预期的缺失时期（db-sync 231 和 db-sync 234）
我认为混淆来自这样一个事实，即 231 在技术上可能不会丢失——可能是账本状态只是认为它分配给储备而不是用户。 从账本状态的角度来看，奖励是存在的（分配给储备），但从用户的角度来看，231 不应该包括在内
SebastienGllmt
于 2021-01-06
我做了一张图片，显示了两个预期的缺失时期（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)
并且只有 epoch 234没有奖励。 db-sync从账本状态获取该表的内容， db-sync添加的唯一内容是epoch_no列。
您的图表与此表不匹配，因此您的图表可能不正确。 node （特别是地址奖励余额计算）中也可能存在错误，但我现在更愿意只处理单个变量（ db-sync ）。
erikd
于 2021-01-06
在您的图表中，您划掉了第 233 纪元的“奖励交付”，Jared 和我都认为这是不正确的，应该交付奖励（因为它们基于第 231 纪元开始时的快照，而不是当前的状态）连锁，链条）。
erikd
于 2021-01-06
@SebastienGllmt说：
我认为混淆来自这样一个事实，即 231 在技术上可能不会丢失——可能是账本状态只是认为它分配给储备而不是用户。
但是rewards表显示了分配到权益地址的奖励。 如果分配给储备，则不会出现在此表中。 db-sync接收此奖励信息作为从权益地址到奖励金额的映射。 现在分类帐状态本身可能是错误的，但是在从分类帐状态检索地图后，错误潜入的余地很小。
erikd
于 2021-01-06
我说错了：
此外，如果（重新）注册证书在 233 纪元的交易中登陆，那么这将是它会错过的唯一奖励更新。
事实上， @SebastienGllmt 说得完全正确：
您应该预期会丢失两个纪元：
- 奖励被送回储备的时代，因为他们没有注册他们的权益密钥
- 代表注销密钥和重新注册密钥之间的 1 个纪元间隔的纪元
由于没有在 232/233 时代边界上注册，权益凭证：
- 没有从 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 ，然后过滤Map删除所有未出现在有效StakeAddress es 集中的条目。
erikd
于 2021-01-06
如果将这个“幻影”奖励放入像“nondistributed_rewards”之类的新表中，那就太好了。 这将使我们能够正确计算池盈利能力
dmitrystas
于 2021-01-06
@dmitrystas ：
如果将这个“幻影”奖励放入像“nondistributed_rewards”之类的新表中，那就太好了。 这将使我们能够正确计算池盈利能力。
我可以看到这些未分配的奖励（回到储备金）可用于计算投票盈利能力，但我很确定这不是计算它的最佳或最简单的方法。
我专门为此问题创建了一张票。
erikd
于 2021-01-06
好的，我有一个解决方案，可以在插入之前从奖励列表中过滤掉无效奖励，并且确实在 epoch 231对该地址有奖励。
我现在需要修改它，以便可以将这些“无效”奖励添加到单独的表中。
erikd
于 2021-01-07
使用 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)
相关问题
rhyslbw
·
11评论
cardanians
·
15评论
erikd
·
7评论
johnalotoski
·
15评论
dmitrystas
·
7评论
最有用的评论
使用 PR #469 中的
db-sync版本。 权益地址\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde的奖励正确插入到orphaned_rewards表中：它也没有出现在奖励表中：