Cardano-db-sync: Ejemplo de saldo de cuenta

¡Gracias por abrir este número en mi nombre! Solo para aclarar un poco más: no se trata solo de la cuenta en sí, sino principalmente de rastrear reap en algún lugar de la base de datos para que pueda usarse fácilmente en el cálculo del saldo de la cuenta (que se usa en todas partes, por ejemplo, pool live tamaño de la apuesta, apuesta en vivo del grupo, etc.).

@1000101 ¿Qué es "cosechar"? No hay una tabla o columna en db-sync llamada "cosecha".

El saldo de la cuenta no es trivial.

Las direcciones en Shelley y épocas posteriores tienen dos componentes; una credencial de pago y una credencial de participación. La dirección de la apuesta (por ejemplo stake1uyluup0rh6r2cc7kcw8nudqz990ezf5ltagxmw3u8deukvqwq7etq ) se deriva de la última. Sin embargo, es posible construir una dirección válida que no contenga ninguna credencial de replanteo.

Entonces, si bien sería posible obtener el saldo de la cuenta para una dirección de participación en particular, no hay forma de obtener el saldo de la cuenta de una billetera a menos que cada dirección en esa billetera incluya la misma credencial de participación.

@1000101 ¿Qué es "cosechar"? No hay una tabla o columna en db-sync llamada "cosecha".

Oh, lo siento por no aclarar esto lo suficiente. Lo que quise decir se describe en https://github.com/input-output-hk/cardano-db-sync/issues/474 , es decir, lo que digo es exactamente que no hay una columna para esto, pero sería genial. si lo hubiera.

Actualmente no hay forma de calcular fácilmente el saldo de una cuenta, cuando esta cuenta se ha utilizado en el registro del grupo (como una cuenta de recompensa) y luego se retiró el grupo, recuperando así el depósito del grupo. El "pago" del depósito del grupo se rastrea en dbsync, pero no su "reembolso" cuando se retira un grupo.

Estoy de acuerdo con ésto. También hay numerosos casos extremos que cada "usuario" de cardano-db-sync tendría que manejar. Tanto Adalite como Yoroi se confunden cuando ven una cuenta que anteriormente era una cuenta de recompensas de un grupo retirado:

Además, AFAIK solo cardanoscan maneja las recompensas restantes correctamente y no usan db-sync.

Debe haber una relación fácil que se actualice de la misma manera que se agregan automáticamente las recompensas. Tomemos un grupo con múltiples cancelaciones de registro como ejemplo, ya que en realidad es bastante común y es difícil manejar el saldo de recompensas de su cuenta de propietario.

Hay 9 certificados de jubilación.

Y 15 certificados de registro

Existen numerosos casos extremos y reglas vagas de jubilación anuladas por nuevos certificados .

@erikd , si insiste en una conexión suficiente entre el depósito de 500 tx y las jubilaciones, ¿cómo escribiría una consulta solo para los depósitos devueltos de una de sus cuentas de propietario: e127e9e94eaa9287680e877832700a1724255e9688609497e09a6c440f? Si no, ¿podemos agregar esto explícitamente a db-sync? Digamos, como una nueva tabla, llamada pool_refunds , con addr_id , cantidad (actualmente debe ser un múltiplo de 500) y epoch_no , para que esto se maneje correctamente y en un solo lugar.

Actualmente db-sync extrae datos del estado del libro mayor y los inserta en la base de datos. Descarta parte de la información, pero no realiza ninguna agregación. Lo que se inserta en la base de datos es simplemente un reflejo de lo que proporciona el estado del libro mayor.

Veamos el pool_hash.id relevante:

> select id, hash_raw from pool_hash
    where hash_raw = '\x9c8e59ea7004a51f953642653d70a94d066359b9dd6e6416a5430ff3' ;
  id  |                          hash_raw                          
------+------------------------------------------------------------
 5022 | \x9c8e59ea7004a51f953642653d70a94d066359b9dd6e6416a5430ff3
(1 row)

El grupo se registró (combinaciones adicionales para ponerlas en orden de block_no ascendente) de la siguiente manera:

> select pool_update.id, hash_id, cert_index, active_epoch_no, block.block_no, block.epoch_no
    from pool_update
      inner join tx on tx.id = pool_update.registered_tx_id
      inner join block on tx.block_id = block.id
    where pool_update.hash_id = 5022
    order by block.block_no asc; 
  id  | hash_id | cert_index | active_epoch_no | block_no | epoch_no 
------+---------+------------+-----------------+----------+----------
 5022 |    5022 |          0 |             220 |  4717004 |      218
 5023 |    5022 |          0 |             220 |  4717035 |      218
 5024 |    5022 |          0 |             220 |  4717057 |      218
 5029 |    5022 |          0 |             220 |  4717140 |      218
 5030 |    5022 |          0 |             220 |  4717146 |      218
 5031 |    5022 |          0 |             220 |  4717169 |      218
 5032 |    5022 |          0 |             220 |  4717189 |      218
 5033 |    5022 |          0 |             220 |  4717216 |      218
 5034 |    5022 |          0 |             220 |  4717234 |      218
 5035 |    5022 |          0 |             220 |  4717241 |      218
 5037 |    5022 |          0 |             220 |  4717296 |      218
 5038 |    5022 |          0 |             220 |  4717425 |      218
 5061 |    5022 |          0 |             220 |  4721000 |      218
 5080 |    5022 |          0 |             221 |  4725394 |      219
 5081 |    5022 |          0 |             221 |  4725435 |      219
(15 rows)

y dado de baja en:

> select pool_retire.id, hash_id, cert_index, retiring_epoch, block.block_no, block.epoch_no
    from pool_retire
      inner join tx on tx.id = pool_retire.announced_tx_id
      inner join block on tx.block_id = block.id
    where hash_id = 5022
    order by block.block_no asc ; 
 id  | hash_id | cert_index | retiring_epoch | block_no | epoch_no 
-----+---------+------------+----------------+----------+----------
 180 |    5022 |          0 |            219 |  4717395 |      218
 181 |    5022 |          0 |            219 |  4717397 |      218
 182 |    5022 |          0 |            219 |  4717401 |      218
 183 |    5022 |          0 |            219 |  4717403 |      218
 184 |    5022 |          0 |            219 |  4717405 |      218
 185 |    5022 |          0 |            219 |  4717417 |      218
 186 |    5022 |          0 |            219 |  4717430 |      218
 187 |    5022 |          0 |            220 |  4725366 |      219
 188 |    5022 |          0 |            220 |  4725717 |      219
(9 rows)

Desentrelazar actualizaciones y bajas:

action   | block_no
---------+------------
register | 4717004
update   | 4717035
update   | 4717057
update   | 4717140
update   | 4717146
update   | 4717169
update   | 4717189
update   | 4717216
update   | 4717234
update   | 4717241
update   | 4717296
retire   | 4717395
retire   | 4717397
retire   | 4717401
retire   | 4717403
retire   | 4717405
retire   | 4717417
update   | 4717425
retire   | 4717430
update   | 4721000
retire   | 4725366
update   | 4725394
update   | 4725435
retire   | 4725717

Continuará ....

Esto definitivamente es demasiado dolor en el cuello. Hablando con personas de especificaciones contables para tratar de encontrar una solución.

Hablé con las personas de ledger-specs que sugirieron una forma rápida y sucia de arreglarlo por ahora mientras esperaban una solución mejor.

La idea sería tener algo así como una tabla pool_registration_refund que contenga la dirección de la apuesta y la cantidad.

¡Eso sería genial!

Hablé con las personas de ledger-specs que sugirieron una forma rápida y sucia de arreglarlo por ahora mientras esperaban una solución mejor.

La idea sería tener algo así como una tabla pool_registration_refund que contenga la dirección de la apuesta y la cantidad.

¡Impresionante! Quiero decir, tenemos una solución alternativa por ahora para no alcanzar el saldo negativo que compartió @xdzurman , pero son alrededor de 100 líneas de no tan bonito: tm : SQL que debe calcularse para cada cuenta. Esto definitivamente ayudaría mucho. mil gracias!!!