Cardano-db-sync: As recompensas foram distribuídas para endereços de apostas não registrados
Mainnet, db-sync 6.0.1, endereço de estaca stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86
histórico de registro
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)
histórico de cancelamento de registro
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)
como podemos ver, o endereço não foi registrado no final da época 232, e as recompensas para a época 231 não deveriam ser distribuídas para este endereço, mas
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
Todos 28 comentários
: facepalm:
Olhei para isso por um tempo e de repente percebi que a primeira consulta não mostra o que @dmitrystas pensa que mostra. Ao ingressar em tx.id = stake_registration.tx_id e obter block.epoch_no da transação, você obtém a época em que ocorre o registro / cancelamento da aposta, mas não quando está realmente ativo .
Para a maioria das operações relacionadas ao piqueteamento, ações (como registros, aumentos no valor apostado etc.) que ocorrem na época N tornam - se N + 2 .
Isso significa que a primeira consulta deve realmente ser:
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
e o segundo:
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 Isso tudo faz sentido? Ajudaria a adicionar uma coluna active_epoch_no extra às tabelas stake_registration e stake_deregistration como eu tenho a tabela delegation ?
erikd
em 17 dez. 2020
@erikd Bom dia. Esse é o problema original https://github.com/Emurgo/yoroi-frontend/issues/1832#issue -754776885
Talvez pudesse ser útil
Yoroi e Adalite mostram a recompensa 192 FAKE ADA errada, mas na verdade é 0. As últimas 2 recompensas são retiradas através de adawallet.io (não usa db-sync)
Breve descrição do problema em etapas:
1) Epoch 232 . Eu retiro as recompensas e cancelo o registro da chave de piquetagem ao mesmo tempo. As recompensas são 0. Tenho ADA suficiente para as taxas
2) Época 233 . Eu deveria receber a primeira recompensa restante se minha chave foi registrada, mas não está, mas Yoroi mostra 192ADA recebido. Yoroi comete um erro quando tento me retirar. Outras carteiras que não usam db-sync mostram recompensa 0ADA
3) Época 233 . Eu delego para a mesma piscina novamente. A chave está registrada . Recompensas verdadeiras 0. Recompensas Yoroi 192.
4) Época 234 . Eu recebo a segunda recompensa restante 135ADA. O verdadeiro saldo da recompensa é 135ADA.
Yoroi mostra 327ADA (192 + 135). Não posso sacar nenhuma recompensa através do Yoroi. Recebi o Erro do servidor ao enviar a transação
5) Época 235 . Eu recebo o último terço da recompensa 145ADA. O verdadeiro saldo da recompensa é 280ADA (135 + 145).
Yoroi mostra 472ADA (192 + 135 + 145) Não é possível sacar nenhuma recompensa através do Yoroi. Recebi o erro do servidor durante o envio da transação.
6) Época 235 . Eu retiro 280ADA sem problemas através do adawallet.io que não usa db-syns e mostra o saldo de recompensa 280ADA
7) Depois que as verdadeiras recompensas de 280ADA são retiradas (permanece 0ADA), Yoroi ainda mostra o saldo de recompensa 192ADA.
IlyaSofronov
em 17 dez. 2020
Yoroi ainda mostra o saldo de recompensa 192ADA.
Existem pelo menos duas possibilidades;
- existe um bug
db-sync - há um bug Yoroi
Eu só lido com db-sync . Isso significa que os problemas precisam ser apresentados a mim como consultas SQL, não como informações de Yoroi.
stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86 a chave da aposta de interesse aqui?
erikd
em 17 dez. 2020
@erikd sim, a chave da aposta é stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86
Observe que não apenas Yoroi TEM ESSE BUG, mas Adalite.io e adastat.net
Estes NÃO TÊM esse bug: cardanoscan.io e adawallet.io
IlyaSofronov
em 18 dez. 2020
Se algumas carteiras online tiverem esse bug e outras não, e todas elas dependerem de db-sync , é muito improvável que o problema esteja em db-sync .
erikd
em 18 dez. 2020
@erikd Mas adawallet.io não usa db-sync e mostra o saldo de recompensa correto (0ADA) e me permite retirar as últimas recompensas
IlyaSofronov
em 18 dez. 2020
Novamente, isso sugere que este é um bug do Yoroi, não um bug de db-sync .
erikd
em 18 dez. 2020
O Exodus também encontrou esse bug.
roccomuso
em 4 jan. 2021
Este é definitivamente um bug do cardano-db-sync e não um bug do Yoroi, já que isso afeta não apenas o Yoroi, mas também vários outros usuários do cardano-db-sync. cardanoscan e adawallet não usam cardano-db-sync, por isso não são afetados.
Quais relatórios cardano-db-sync
Aqui está a consulta SQL que fornece o histórico de recompensas para o endereço fornecido por @IlyaSofronov
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'
e dá o seguinte resultado
\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
Observação : a soma dessas linhas é 3.765.004.402
Estado atual (incorreto) de nosso back-end
{
"remainingAmount": "193172340",
"rewards": "3765004402",
"withdrawals": "3571832062",
}
Você pode ver que nosso back-end retorna a soma das linhas db-sync para o rewards (explicarei por que esse é o problema mais tarde)
Você também pode verificar se o withdrawals está correto somando os valores em cardanoscan que sabemos não serem afetados por este bug.
remainingAmount é apenas rewards - withdrawals
Histórico de registro da carteira
Olhando a história desta chave de piquetagem , você pode ver:
- Foi cancelado na época 232
- Foi registrado novamente na época 233
Estado atual do nó cardano
De acordo com minha instância de nó de cardano, este é o valor atual dentro do endereço de piquetagem
[
{
"address": "stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86",
"delegation": "pool1kkfkdces5mdcyc9dn2hgg3463jggjvw3h89nejjarkz25uavaqu",
"rewardAccountBalance": 202780
}
]
Então você pode ver que, de acordo com o nó, o saldo da carteira é época 235 + época 236 (100702 + 102078 = 202780)
Então qual é o problema?
Observando o cardanoscan , podemos ver o histórico completo de retirada da carteira. Vamos ver a que cada retirada corresponde:
| Epoch retirado | Quantia retirada | linhas de época db-sync incluídas |
| ----------------- | ------------------ | ------------ ----------------- |
| 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
NO ENTANTO, você pode ver que a época 231 em cardano-db-sync (192969560) não está incluída em nenhum desses!
Com certeza, se você olhar nossa resposta de back-end, "remainingAmount": "193172340", e remover a época 231 incluída erroneamente, você obtém 193172340 - 192969560 = 202780 que é o resultado esperado de nosso fullnode!
Conclusão
Com base em minha investigação, parece que cardano-db-sync inclui a linha 231 no resultado do histórico de recompensas, embora não devesse.
SebastienGllmt
em 4 jan. 2021
Simplifiquei a primeira consulta e verifiquei se obtive os mesmos resultados (obtive).
Estado atual (incorreto) de nosso back-end
Eu preferiria obter todas as informações de uma única fonte para:
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
e:
cexplorer=# select sum (amount) from withdrawal where addr_id = 38266;
sum
------------
3571832062
ambos concordam com seus números.
Curiosamente 3571832062 + 192969560 + 202780 - 3765004402 onde 3571832062 é a soma da retirada e 3765004402 é a soma da recompensa. Os outros valores são; 202780 que é o valor do saldo da recompensa após retiradas e 192969560 são as recompensas da época 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
Portanto, essa recompensa pela época 231 (que db-sync simplesmente retira do estado do razão e insere no banco de dados com zero de processamento extra) está correta? Vejamos o histórico de registro da estaca para esse endereço de estaca:
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
Observe que, tanto para o registro quanto para o cancelamento do registro, incluí tx_id (o id do tx que continha o registro / cancelamento), tx_epoch_no (a época em que o tx foi incluído) e active_epoch_no (a época em que o registro / cancelamento de registro se torna ativo).
Olhando para os números das épocas ativas , o registro da aposta deveria estar ativo nas épocas [210 .. 233] e [235 ..] . Isso corresponde às recompensas reais para este endereço:
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)
Ou seja, há recompensas para cada época, exceto 234 .
Portanto, acho que sua conclusão:
Com base em minha investigação, parece que cardano-db-sync inclui a linha 231 no resultado do histórico de recompensas, embora não devesse.
está incorreto, esse endereço de aposta deve ter recompensas para a época 231 .
Além disso, acredito que seu comentário:
Estado atual (incorreto) de nosso back-end
{
"restanteAmount": "193172340",
"recompensas": "3765004402",
"retiradas": "3571832062",
}
está realmente correto. A diferença entre o valor da recompensa e o valor da retirada é o saldo da recompensa atual não retirado.
erikd
em 5 jan. 2021
está realmente correto. A diferença entre o valor da recompensa e o valor da retirada é o saldo da recompensa atual não retirado.
Esse não pode ser o caso porque sabemos que o nó retorna 202780 como o saldo da recompensa para a conta e não 193172340
Ou seja, há recompensas para todas as épocas, exceto 234.
Você deve esperar a falta de duas épocas:
- A época em que as recompensas foram enviadas de volta para as reservas porque eles não tinham sua chave de aposta registrada
- A época que representa a lacuna de 1 época entre quando eles cancelaram o registro de sua chave e quando eles registraram novamente
A época ausente de 234 corresponde a (2), e acredito que 231 corresponde a (1), pois 231 significa que deve estar visível na carteira do usuário na época 233, que é precisamente a época pela qual esperamos ter sido perdidos (1)
SebastienGllmt
em 5 jan. 2021
Você deve esperar a falta de duas épocas:
Por quê? De acordo com as operações neste endereço de estaca:
| operação | tx_epoch_no | active_epoch_no |
| ------------------- | --------------------- | ------- --------- |
| registro | 208 210
| deregistraion | 232 234
| registro | 233 235
o registro foi cancelado apenas por uma única época ( 234 ) e não recebeu recompensas por essa época.
Por que haveria duas épocas sem recompensas? Tenho certeza de que os dois casos que você mencionou são na verdade a mesma coisa e, portanto, apenas uma época passa sem uma recompensa.
erikd
em 5 jan. 2021
@SebastienGllmt no Slack disse:
o cancelamento do registro é especial porque ocorre imediatamente, não em 2 épocas
Se o cancelamento do registro ocorrer imediatamente, este aconteceu em tx_epoch_no == 232 portanto, as recompensas para as épocas [231..234] seriam todas perdidas, não apenas as recompensas para 231.
Acho que precisamos de @JaredCorduan nisso.
erikd
em 5 jan. 2021
A explicação de @SebastienGllmt é consistente com as regras do razão.
É um pouco filosófico "quando" uma credencial de estaca é cancelada, mas eu diria assim: o cancelamento do registro ocorre imediatamente, mas as recompensas são atrasadas. Se uma credencial for cancelada na época e , ela receberá recompensas no limite e / e+1 (proveniente do instantâneo obtido no limite e-2 / e -1 ) e também receba recompensas no limite e+1 / e+2 (vindo do instantâneo tirado no limite e-1 / e ).
JaredCorduan
em 5 jan. 2021
Parece que temos alguma confusão com a nomenclatura.
Do ponto de vista de dbs-ync ::
tx_epoch_no: a época contendo as transações do certificado de registro / cancelamento.active_epoch_no: basicamentetx_epoch_no + 2, a época em que as alterações no endereço da aposta tornam-se ativas.epoch_nona mesareward: a época real em que as recompensas foram ganhas.
erikd
em 5 jan. 2021
se a credencial da estaca estivesse em um certificado de cancelamento de registro de uma transação na época 232, ela não seria incluída no instantâneo obtido no limite 232/233. isso significa que não faria parte da atualização de recompensa distribuída no limite 235/236. que, nos termos de @erikd , são 234 recompensas. além disso, se o certificado de (re) registro desembarcasse em uma transação na época 233, então esta seria a _única_ atualização de recompensa que ele perderia.
JaredCorduan
em 5 jan. 2021
é importante notar que coisas como "cancelar o registro quando", "recompensas em" e "ativo quando", etc, podem ser confusas se não formos muito claros. então não está claro para mim com quem estou concordando :)
JaredCorduan
em 5 jan. 2021
Como parece haver confusão, fiz uma imagem que mostra as duas épocas ausentes esperadas (db-sync 231 e db-sync 234)
Acho que a confusão vem do fato de que 231 pode não estar tecnicamente ausente - pode ser o estado do razão apenas o considera distribuído para as reservas em vez do usuário. Do ponto de vista do estado do razão, as recompensas existem (distribuídas para as reservas), mas do ponto de vista do usuário 231 não deve ser incluído
SebastienGllmt
em 6 jan. 2021
Fiz uma imagem que mostra as duas épocas ausentes esperadas (db-sync 231 e db-sync 234)
Mas as recompensas reais, conforme relatado por db-sync são:
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)
e apenas a época 234 não tem recompensas. db-sync obtém o conteúdo desta tabela do estado do ledger e a única coisa que db-sync adiciona é a coluna epoch_no .
Seu diagrama não corresponde a esta tabela, portanto, seu diagrama provavelmente está incorreto. Também pode haver um bug no node (especificamente o cálculo do saldo da recompensa do endereço), mas eu preferiria lidar apenas com uma única variável ( db-sync ) por enquanto.
erikd
em 6 jan. 2021
Em seu diagrama, você tem "recompensas entregues" riscadas para a época 233, e tanto Jared quanto eu achamos que isso está incorreto e que as recompensas devem ser entregues (porque são baseadas no instantâneo no início da época 231, não no estado atual de a corrente).
erikd
em 6 jan. 2021
@SebastienGllmt diz:
Acho que a confusão vem do fato de que 231 pode não estar tecnicamente ausente - pode ser o estado do razão apenas o considera distribuído para as reservas em vez do usuário.
Mas a tabela rewards mostra a recompensa sendo distribuída para o endereço da aposta. Se fosse distribuído para reservas, não estaria nesta tabela. db-sync recebe essas informações de recompensa como um mapa do endereço da aposta até o valor da recompensa. Agora, o próprio estado do razão pode estar errado, mas há muito pouco espaço para erros que se insinuam depois que o mapa é recuperado do estado do razão.
erikd
em 6 jan. 2021
Eu estava errado quando disse:
além disso, se o certificado de (re) registro desembarcasse em uma transação na época 233, então esta seria a única atualização de recompensa que perderia.
Na verdade, @SebastienGllmt estava exatamente certo quando disse:
Você deve esperar a falta de duas épocas:
- A época em que as recompensas foram enviadas de volta para as reservas porque eles não tinham sua chave de aposta registrada
- A época que representa a lacuna de 1 época entre quando eles cancelaram o registro de sua chave e quando eles registraram novamente
Por não ser registrada no limite de época 232/233, a credencial da estaca:
- não obtém as recompensas da atualização sendo aplicada no limite 232/233, e
- não está incluído no instantâneo de distribuição da aposta feito no limite 232/233 (de modo que não receba as recompensas distribuídas no limite 235/236).
Eu posso adivinhar como o db-sync está relatando recompensas sendo distribuídas no limite 232/233 (o que é realmente apenas o palpite de @SebastienGllmt :)). O estado do razão não pode saber até o último momento antes do limite da época quais credenciais ainda estão registradas. Devolvemos recompensas por credenciais não registradas para as reservas. (Veja Figure 51: Reward Update Application nas especificações formais ). db-sync provavelmente não está removendo credenciais não registradas.
JaredCorduan
em 6 jan. 2021
A imagem de @SebastienGllmt acima parece ótima, mas observe que, na verdade, as setas precisam abranger outra época para contabilizar a fase de produção do bloco. por exemplo, as recompensas do instantâneo tirado no limite 230/231 não são realmente entregues até o limite 233/234.
JaredCorduan
em 6 jan. 2021
Ok, agora temos uma explicação para isso. db-sync mantém o estado de espírito e retira as recompensas da época como Map StakeAddress Coin que insere no banco de dados. No entanto, esse mapa contém StakeAddress entradas que não são válidas e, por outro lado, descartariam essas entradas, contribuindo efetivamente com as recompensas ganhas de volta para as reservas.
A solução também é extrair o conjunto de StakeAddress válidos do estado do razão e, em seguida, filtrar Map eliminando todas as entradas que não ocorrem no conjunto de StakeAddress es válidos.
erikd
em 6 jan. 2021
Seria ótimo se essas recompensas 'fantasmas' fossem colocadas em uma nova tabela como 'nondistributed_rewards' ou algo assim. Isso nos permitirá calcular corretamente a lucratividade do pool
dmitrystas
em 6 jan. 2021
@dmitrystas :
Seria ótimo se essas recompensas 'fantasmas' fossem colocadas em uma nova tabela como 'nondistributed_rewards' ou algo assim. Isso nos permitirá calcular corretamente a lucratividade do pool.
Posso ver que essas recompensas não distribuídas (que remontam às reservas) poderiam ser usadas para calcular a lucratividade da pesquisa, mas tenho certeza de que essa não é a melhor ou a maneira mais fácil de calculá-la.
Criei um tíquete especificamente para esse problema.
erikd
em 6 jan. 2021
Ok, eu tenho uma solução que filtra recompensas inválidas da lista de recompensas antes de ser inserida e, de fato, há uma recompensa para esse endereço na época 231 .
Agora preciso modificar isso para que essas recompensas "inválidas" possam ser adicionadas a uma tabela separada.
erikd
em 7 jan. 2021
Usando a versão de db-sync em PR # 469. a recompensa pelo endereço da aposta \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde está inserida corretamente na tabela 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
e também está ausente da tabela de recompensas:
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)
Questões relacionadas
alexqrid
·
11Comentários
erikd
·
3Comentários
reliablestaking
·
31Comentários
erikd
·
7Comentários
dmitrystas
·
7Comentários
Comentários muito úteis
Usando a versão de
db-syncem PR # 469. a recompensa pelo endereço da aposta\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fdeestá inserida corretamente na tabelaorphaned_rewards:e também está ausente da tabela de recompensas: