Cardano-db-sync: Las recompensas se distribuyeron a una dirección de participación no registrada.

Creado en 2 dic. 2020  ·  28Comentarios  ·  Fuente: input-output-hk/cardano-db-sync

Mainnet, db-sync 6.0.1, dirección de participación stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86

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

historial de baja

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, la dirección no se ha registrado al final de la época 232, y las recompensas por la época 231 no deben distribuirse a esta dirección, pero

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)
bug priority high
Fuente
picture dmitrystas
👀4 👍1

Comentario más útil

Usando la versión de db-sync en PR # 469. la recompensa por la dirección de apuesta \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde está correctamente insertada en la tabla 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

y también está ausente en la tabla 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)
picture erikd en 8 ene. 2021
👍2

Todos 28 comentarios

: palma de la mano:

Miré esto por un tiempo y luego de repente me di cuenta de que la primera consulta no muestra lo que @dmitrystas cree que muestra. Al unirse en tx.id = stake_registration.tx_id y luego obtener el block.epoch_no de la transacción, obtiene la época en la que se produce el registro / cancelación de la participación, pero no cuando está realmente activo .

Para la mayoría de las operaciones relacionadas con el replanteo, las acciones (como registros, aumentos en la cantidad apostada, etc.) que ocurren en la época N se activan en la época N + 2 .

Eso significa que la primera consulta debería 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

y el 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 ¿Todo eso active_epoch_no a las tablas stake_registration y stake_deregistration como tengo la tabla delegation ?

erikd picture erikd en 17 dic. 2020

@erikd Buen día. Ese es el problema original https://github.com/Emurgo/yoroi-frontend/issues/1832#issue -754776885
Quizás podría ser útil

Yoroi y Adalite muestran una recompensa 192 FAKE ADA incorrecta pero en realidad es 0. Las últimas 2 recompensas se retiran a través de adawallet.io (no usa db-sync)
image

Breve descripción del problema en pasos:
1) Época 232 . Retiro las recompensas y anulo el registro de la clave de apuesta al mismo tiempo. Las recompensas son 0. Tengo suficiente ADA para las tarifas
2) Época 233 . Debería recibir la primera recompensa restante si mi clave fue registrada pero no lo está, pero Yoroi muestra 192ADA recibida. Yoroi arroja un error cuando intento retirarme. Otras carteras que no utilizan db-sync muestran recompensa 0ADA
3) Época 233 . Delego en el mismo grupo de nuevo. La clave está registrada . Recompensas verdaderas 0. Recompensas de Yoroi 192.
4) Época 234 . Recibo la segunda recompensa restante 135ADA. El saldo de recompensa real es 135ADA.
Yoroi muestra 327ADA (192 + 135). No puedo retirar ninguna recompensa a través de Yoroi. Recibí el error del servidor al enviar la transacción.
5) Época 235 . Recibo el último tercio de recompensa 145ADA. El saldo de recompensa real es 280ADA (135 + 145).
Yoroi muestra 472ADA (192 + 135 + 145) No se puede retirar ninguna recompensa a través de Yoroi Tengo el error recibido del servidor al enviar la transacción.
6) Época 235 . Retiro 280ADA sin problemas a través de adawallet.io que no usa db-syns y muestra correctamente el saldo de recompensa 280ADA
7) Después de que se retiren las recompensas verdaderas de 280ADA (sigue siendo 0ADA), Yoroi todavía muestra el saldo de recompensa 192ADA.

IlyaSofronov picture IlyaSofronov en 17 dic. 2020

Yoroi todavía muestra un saldo de recompensa 192ADA.

Hay al menos dos posibilidades;

  • hay un error db-sync
  • hay un error de Yoroi

Solo trato con db-sync . Eso significa que los problemas deben presentarse como consultas SQL, no como información de Yoroi.

¿Es stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86 la clave de interés de interés aquí?

erikd picture erikd en 17 dic. 2020

@erikd sí, la clave de la apuesta es estaca1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86
Tenga en cuenta que no solo Yoroi TIENE ESE ERROR, sino también Adalite.io y adastat.net
Estos NO TIENEN ese error: cardanoscan.io y adawallet.io

IlyaSofronov picture IlyaSofronov en 18 dic. 2020

Si algunas billeteras en línea tienen este error y otras no, y todas ellas dependen de db-sync entonces el problema es muy improbable de estar en db-sync .

erikd picture erikd en 18 dic. 2020

@erikd Pero adawallet.io no usa db-sync y muestra el saldo de recompensa correcto (0ADA) y me permite retirar las últimas recompensas

IlyaSofronov picture IlyaSofronov en 18 dic. 2020

Nuevamente, eso sugiere que esto es un error de Yoroi, no un error de db-sync .

erikd picture erikd en 18 dic. 2020

Exodus también encontró este error.

roccomuso picture roccomuso en 4 ene. 2021

Este es definitivamente un error de cardano-db-sync y no un error de Yoroi dado que esto afecta no solo a Yoroi sino también a muchos otros usuarios de cardano-db-sync. cardanoscan y adawallet no usan cardano-db-sync, por lo que no se ven afectados.

Lo que informa cardano-db-sync

Aquí está la consulta SQL que proporciona el historial de recompensas para la dirección proporcionada 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'

y da el siguiente 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

Nota : la suma de estas filas es 3.765.004.402

Estado actual (incorrecto) de nuestro backend

{
    "remainingAmount": "193172340",
    "rewards": "3765004402",
    "withdrawals": "3571832062",
}

Puede ver que nuestro backend devuelve la suma de las filas de db-sync para el rewards (explicará por qué este es el problema más adelante)

También puede verificar que la cantidad withdrawals es correcta sumando los valores en cardanoscan que sabemos que no se ven afectados por este error.

remainingAmount es solo rewards - withdrawals

Historial de registro de la billetera

Al mirar el historial de esta clave de replanteo , puede ver:

  • Fue dado de
  • Se volvió a registrar en la época 233.

Estado actual de cardano-node

Según mi instancia de cardano-node, este es el valor actual dentro de la dirección de replanteo

[
    {
        "address": "stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86",
        "delegation": "pool1kkfkdces5mdcyc9dn2hgg3463jggjvw3h89nejjarkz25uavaqu",
        "rewardAccountBalance": 202780
    }
]

Entonces puede ver que según el nodo, el saldo de la billetera es época 235 + época 236 (100702 + 102078 = 202780)

Entonces, ¿cuál es el problema?

Al mirar cardanoscan podemos ver el historial completo de retiros de la billetera. Veamos a qué corresponde cada retiro:

| Epoch retirado | Importe retirado | filas de época de db-sync incluidas |
| ----------------- | ------------------ | ------------ ----------------- |
| 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 |

SIN EMBARGO, puede ver que la época 231 en cardano-db-sync (192969560) no está incluida en ninguno de estos.

Efectivamente, si observa nuestra respuesta de backend, "remainingAmount": "193172340", y elimina la época 231 incluida erróneamente, obtiene 193172340 - 192969560 = 202780 que es el resultado esperado de nuestro nodo completo.

Conclusión

Según mi investigación, parece que cardano-db-sync incluye la fila 231 en el resultado del historial de recompensas, aunque no debería.

SebastienGllmt picture SebastienGllmt en 4 ene. 2021

Simplifiqué la primera consulta y validé que obtengo los mismos resultados (lo hice).

Estado actual (incorrecto) de nuestro backend

Preferiría obtener toda la información de una sola fuente, por lo que:

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

y:

cexplorer=# select sum (amount) from withdrawal where addr_id = 38266;
    sum     
------------
 3571832062

ambos concuerdan con sus cifras.

Curiosamente 3571832062 + 192969560 + 202780 - 3765004402 donde 3571832062 es la suma de retiro y 3765004402 es la suma de recompensa. Los otros valores son; 202780 que es su cifra para el saldo de recompensa después de los retiros y 192969560 son las recompensas por la é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

Entonces, ¿esa recompensa por la época 231 (que db-sync simplemente saca del estado del libro mayor y se inserta en la base de datos sin procesamiento adicional) es correcta? Veamos el historial de registro de estaca para esa dirección 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

Tenga en cuenta que tanto para el registro como para la cancelación del registro, he incluido tx_id (la identificación del tx que contenía el registro / cancelación del registro), tx_epoch_no (la época en la que se incluyó el tx) y active_epoch_no (la época en la que se activa el registro / baja).

Mirando los números de época activa , el registro de la apuesta debería haber estado activo en las épocas [210 .. 233] y [235 ..] . Esto coincide con las recompensas reales para esta dirección:

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)

Es decir, hay recompensas para cada época excepto 234 .

Por eso creo que tu conclusión:

Según mi investigación, parece que cardano-db-sync incluye la fila 231 en el resultado del historial de recompensas, aunque no debería.

es incorrecta, esa dirección de participación debería tener recompensas para la época 231 .

Además, creo que tu comentario:

Estado actual (incorrecto) de nuestro backend
{
"leftAmount": "193172340",
"recompensas": "3765004402",
"retiros": "3571832062",
}

es realmente correcto. La diferencia entre el valor de las recompensas y el valor de retiro es el saldo de recompensas no retirado actual.

erikd picture erikd en 5 ene. 2021

es realmente correcto. La diferencia entre el valor de las recompensas y el valor de retiro es el saldo de recompensas no retirado actual.

Ese no puede ser el caso porque sabemos que el nodo devuelve 202780 como saldo de recompensa para la cuenta y no 193172340

Es decir, hay recompensas para cada época excepto la 234.

Debe esperar que falten dos épocas:

  1. La época en la que las recompensas se enviaron de vuelta a las reservas porque no tenían registrada su clave de participación.
  2. La época que representa la brecha de 1 época entre el momento en que anularon el registro de su clave y el momento en que se volvieron a registrar.

El 234 época faltante corresponde a (2), y creo que 231 corresponde a (1) ya que 231 significa que debería ser visible en la billetera del usuario en la época 233, que es precisamente la época por la que esperamos haber perdido. (1)

SebastienGllmt picture SebastienGllmt en 5 ene. 2021

Debe esperar que falten dos épocas:

¿Por qué? Según las operaciones en esta dirección de participación:

| operación | tx_epoch_no | active_epoch_no |
| ------------------- | --------------------- | ------- --------- |
| registro | 208 | 210 |
| baja del registro | 232 | 234 |
| registro | 233 | 235 |

solo se canceló el registro por una sola época ( 234 ) y no recibió recompensas por esa época.

¿Por qué habría dos épocas sin recompensas? Estoy bastante seguro de que los dos casos que menciona son en realidad lo mismo y, por lo tanto, solo una época pasa sin recompensa.

erikd picture erikd en 5 ene. 2021

@SebastienGllmt en Slack dijo:

la cancelación del registro es especial porque se realiza de inmediato, no en 2 épocas

Si la cancelación del registro se produce de inmediato, esto sucedió en tx_epoch_no == 232 por lo que las recompensas por épocas [231..234] perderían todas, no solo las recompensas por 231.

Creo que necesitamos a @JaredCorduan en esto.

erikd picture erikd en 5 ene. 2021

La explicación de @SebastienGllmt es consistente con las reglas del libro mayor.

Es un poco filosófico "cuando" se cancela el registro de una credencial de participación, pero lo expresaría así: la cancelación del registro se lleva a cabo de inmediato, pero las recompensas se retrasan. Si se da de baja una credencial en la época e , entonces recibirá recompensas en el límite e / e+1 (que proviene de la instantánea tomada en el límite e-2 / e -1 ) y también recibir recompensas en el límite de e+1 / e+2 (procedente de la instantánea tomada en el límite de e-1 / e ).

JaredCorduan picture JaredCorduan en 5 ene. 2021

Parece que tenemos cierta confusión con la nomenclatura.

Desde el punto de vista de dbs-ync ::

  • tx_epoch_no : la época que contiene las transacciones del certificado de registro / baja.
  • active_epoch_no : básicamente tx_epoch_no + 2 , la época en la que se activan los cambios en la dirección de la apuesta.
  • epoch_no en reward tabla: la época real en la que se obtuvieron las recompensas.
erikd picture erikd en 5 ene. 2021

si la credencial de participación estaba en un certificado de cancelación de registro de una transacción en la época 232, entonces no se incluiría en la instantánea tomada en el límite 232/233. esto significa que no sería parte de la actualización de recompensas que se entrega en el límite 235/236. que, en términos de @erikd , son las 234 recompensas. además, si el certificado de (re) registro aterrizara en una transacción en la época 233, entonces esta sería la _única_ actualización de recompensa que se perdería.

JaredCorduan picture JaredCorduan en 5 ene. 2021

Vale la pena señalar que cosas como "anular el registro cuando", "recompensas en" y "activo cuando", etc., pueden ser confusas si no lo tenemos muy claro. así que no tengo claro con quién estoy de acuerdo :)

JaredCorduan picture JaredCorduan en 5 ene. 2021

Como parece haber confusión, hice una imagen que muestra las dos épocas faltantes esperadas (db-sync 231 y db-sync 234)

Creo que la confusión proviene del hecho de que técnicamente 231 no puede faltar; podría ser que el estado del libro mayor simplemente lo considere distribuido a las reservas en lugar del usuario. Desde el punto de vista del estado del libro mayor, las recompensas existen (distribuidas a las reservas), pero desde el punto de vista del usuario, 231 no deberían incluirse

image

SebastienGllmt picture SebastienGllmt en 6 ene. 2021

Hice una imagen que muestra las dos épocas faltantes esperadas (db-sync 231 y db-sync 234)

Pero las recompensas reales según lo informado por db-sync son:

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)

y solo la época 234 no tiene recompensas. db-sync obtiene el contenido de esta tabla del estado del libro mayor y lo único que db-sync agrega es la columna epoch_no .

Su diagrama no coincide con esta tabla, por lo que es probable que su diagrama sea incorrecto. También puede haber un error en el node (específicamente el cálculo del saldo de recompensa de la dirección) pero preferiría tratar solo con una sola variable ( db-sync ) por ahora.

erikd picture erikd en 6 ene. 2021

En su diagrama, tiene "recompensas entregadas" tachadas para la época 233, y tanto Jared como yo creemos que eso es incorrecto y que las recompensas deben entregarse (porque se basan en la instantánea al comienzo de la época 231, no en el estado actual de La cadena).

erikd picture erikd en 6 ene. 2021

@SebastienGllmt dice:

Creo que la confusión proviene del hecho de que técnicamente 231 no puede faltar; podría ser que el estado del libro mayor simplemente lo considere distribuido a las reservas en lugar del usuario.

Pero la tabla rewards muestra la recompensa que se distribuye a la dirección de la apuesta. Si se distribuyera a reservas, no estaría en esta tabla. db-sync recibe esta información de recompensa como un mapa desde la dirección de la apuesta hasta el monto de la recompensa. Ahora bien, el estado del libro mayor en sí mismo puede ser incorrecto, pero hay muy poco margen para que se produzcan errores después de que el mapa se recupere del estado del libro mayor.

erikd picture erikd en 6 ene. 2021

Me equivoqué cuando dije:

Además, si el certificado de (re) registro aterrizara en una transacción en la época 233, esta sería la única actualización de recompensa que se perdería.

De hecho, @SebastienGllmt tenía toda la razón cuando dijo:

Debe esperar que falten dos épocas:

  1. La época en la que las recompensas se enviaron de vuelta a las reservas porque no tenían registrada su clave de participación.
  2. La época que representa la brecha de 1 época entre el momento en que anularon el registro de su clave y el momento en que se volvieron a registrar.

Al no estar registrado en el límite de época 232/233, la credencial de estaca:

  • no obtiene las recompensas de la actualización que se aplica en el límite 232/233, y
  • no se incluye en la instantánea de distribución de participación tomada en el límite 232/233 (por lo que no recibe las recompensas entregadas en el límite 235/236).

Puedo adivinar cómo db-sync informa que las recompensas se entregan en el límite 232/233 (que en realidad es solo una suposición de Figure 51: Reward Update Application en la especificación formal ). Es probable que db-sync no elimine las credenciales no registradas.

JaredCorduan picture JaredCorduan en 6 ene. 2021

La imagen de @SebastienGllmt de arriba se ve muy bien, pero tenga en cuenta que, de hecho, las flechas deben abarcar otra época para tener en cuenta la fase de producción de bloques. por ejemplo, las recompensas de la instantánea tomada en el límite 230/231 no se entregan realmente hasta el límite 233/234.

JaredCorduan picture JaredCorduan en 6 ene. 2021

Ok, ahora tenemos una explicación de esto. db-sync mantiene legder-state y extrae las recompensas de época como Map StakeAddress Coin que inserta en la base de datos. Sin embargo, ese mapa contiene entradas de StakeAddress que no son válidas y legder-state eliminaría estas entradas contribuyendo efectivamente con las recompensas ganadas a las reservas.

La solución es también extraer el conjunto de StakeAddress válidos del estado del libro mayor y luego filtrar el Map eliminando todas las entradas que no ocurren en el conjunto de StakeAddress es válido.

erikd picture erikd en 6 ene. 2021

Sería genial si estas recompensas 'fantasmas' se pusieran en una nueva tabla como 'nondistributed_rewards' o algo como esto. Esto nos permitirá calcular correctamente la rentabilidad del pool.

dmitrystas picture dmitrystas en 6 ene. 2021

@dmitrystas :

Sería genial si estas recompensas 'fantasmas' se pusieran en una nueva tabla como 'nondistributed_rewards' o algo como esto. Esto nos permitirá calcular correctamente la rentabilidad del pool.

Puedo ver que estas recompensas no distribuidas (que regresan a las reservas) podrían usarse para calcular la rentabilidad de la encuesta, pero estoy bastante seguro de que esa no es la mejor ni la forma más fácil de calcularla.

He creado un ticket específicamente para este problema.

erikd picture erikd en 6 ene. 2021

Ok, tengo una solución que filtra las recompensas no válidas de la lista de recompensas antes de ser insertadas y, de hecho, hay una recompensa para esa dirección en la época 231 .

Ahora necesito modificar eso para que estas recompensas "no válidas" se puedan agregar a una tabla separada.

erikd picture erikd en 7 ene. 2021
🚀1

Usando la versión de db-sync en PR # 469. la recompensa por la dirección de apuesta \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde está correctamente insertada en la tabla 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

y también está ausente en la tabla 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)
erikd picture erikd en 8 ene. 2021
👍2
¿Fue útil esta página
0 / 5 - 0 calificaciones

Temas relacionados

cardanians picture cardanians  ·  3Comentarios
xdzurman picture xdzurman  ·  18Comentarios
erikd picture erikd  ·  10Comentarios
erikd picture erikd  ·  4Comentarios
xdzurman picture xdzurman  ·  3Comentarios