Cardano-db-sync: El depósito después de la jubilación del grupo debe estar en la tabla de recompensas

Creado en 13 nov. 2020  ·  18Comentarios  ·  Fuente: input-output-hk/cardano-db-sync

Después de retirar un grupo, el depósito debe llegar a la cuenta de recompensas. Aunque está visible en cardano-cli, no se puede encontrar en la base de datos.

cardano-cli shelley query stake-address-info \
> --mainnet \
> --address stake1uywjy7h05jmhx9y3wzy94td6xz4txynuccgam0zfn800v8qq33z29
[
    {
        "address": "stake1uywjy7h05jmhx9y3wzy94td6xz4txynuccgam0zfn800v8qq33z29",
        "delegation": "pool1qnrqc7zpwye2r9wtkayh2dryvfqs7unp99f2039duljrsaffq5c",
        "rewardAccountBalance": 500009820
    }
]

image

Comentario más útil

@erikd
De la especificación del

Página 21

Recuerde que los reembolsos de jubilación del grupo de interés no se emiten cuando un certificado que programa la
se procesa la jubilación, pero en el límite de la época para la que está programada la jubilación.

Página 40

• La función poolRefunds se utiliza para calcular los reembolsos totales que deben distribuirse
para grupos de interés programados para retirarse. Tenga en cuenta que este cálculo toma un número de intervalo correspondiente al intervalo de límite de época cuando se realiza el cálculo. El retorno
map mapea los hashkeys del operador del grupo a los reembolsos, que finalmente serán devueltos al
cuenta de recompensa registrada.

Todos 18 comentarios

Pero la tabla de 'recompensas' no es lo mismo que Stake_address change ... Si hacemos esto, también deberíamos almacenar en esta tabla otras cosas, como recompensas ITN (tabla 'reserva' en este momento) por ejemplo

La única otra forma de obtener esos depósitos junto con las recompensas sería consultar la tabla de retiro del grupo, si un grupo conectado a esta dirección de participación expiró en una época determinada, y agregar un valor 500000000 codificado de forma rígida a las recompensas si ese valor aún no ha sido retirado, que nuevamente requiere calcular si los retiros no son más altos que las recompensas hasta ese momento, y así sucesivamente, lo que parece realmente torpe.

Sin embargo, todavía creo que debería indicarse en la base de datos de manera más explícita sin estos valores codificados y tal. ¿Quizás otra mesa? ¿O una relación más simple?

Si opto por obtener estos 500 ADA de la tabla pool_retirement, si el grupo tiene varios propietarios, ¿cómo averiguaría a qué dirección de participación se han recompensado estos 500 ADA?

Si el grupo tiene varios propietarios, ¿cómo puedo saber a qué dirección de participación se han recompensado estos 500 ADA?

el depósito se devuelve a la dirección de recompensas (siempre es una para un grupo), no a la dirección del propietario

el depósito se devuelve a la dirección de recompensas (siempre es una para un grupo), no a la dirección del propietario
¡Eso tiene sentido, gracias!

Entonces, el depósito de un grupo retirado se devolverá a la dirección de recompensa del grupo que se declara en la tabla pool_update, ¿verdad?

Lo pregunto porque tengo el ejemplo actual que me confunde:

SELECT SUM(amount) as reward, NULL as withdrawal
FROM reward
         LEFT JOIN stake_address sa on reward.addr_id = sa.id
WHERE sa.view = 'stake1u9rqg96sdsdrqshpx0x77jna40ws90drts2wks7vuy63dpqj6txws'
UNION
SELECT NULL, SUM(amount)
FROM withdrawal
         LEFT JOIN tx ON withdrawal.tx_id = tx.id
         LEFT JOIN block ON tx.block_id = block.id
         LEFT JOIN stake_address sa on withdrawal.addr_id = sa.id
WHERE sa.view = 'stake1u9rqg96sdsdrqshpx0x77jna40ws90drts2wks7vuy63dpqj6txws';

Esta consulta nos da las recompensas totales y los retiros totales de una dirección de apuesta de ejemplo. La diferencia entre ellos es exactamente 500000000 lovelace. Seguro que podría ser una coincidencia, pero eso es bastante difícil de imaginar ya que hay otros ejemplos como ese. Así que supongamos que se trata de un depósito de grupo devuelto, entonces esta dirección de apuesta debería aparecer como una dirección de recompensa en la tabla pool_update, ¿verdad?

SELECT pool_retire.hash_id, sa.view FROM pool_retire
    LEFT JOIN pool_update pu ON pool_retire.hash_id = pu.hash_id
    LEFT JOIN stake_address sa on sa.id = pu.hash_id
WHERE sa.view = 'stake1u9rqg96sdsdrqshpx0x77jna40ws90drts2wks7vuy63dpqj6txws'

Pero esta consulta no arroja resultados. Lo que pude averiguar es que la dirección de la apuesta es un copropietario de un grupo retirado (pool_hash_id = 8), lo que me llevó a mi primera pregunta.

Me pregunto cómo podría determinar de dónde provienen estos 500 ADA. ¿Este depósito podría estar relacionado con el ITN?

Entonces, el depósito de un grupo retirado se devolverá a la dirección de recompensa del grupo que se declara en la tabla pool_update, ¿verdad?

Derecha

Pero esta consulta no arroja resultados

sa.id! = pu.hash_id -> sa.id = pu.reward_addr_id

Me pregunto cómo podría determinar de dónde provienen estos 500 ADA. ¿Este depósito podría estar relacionado con el ITN?

Es casi seguro que no.

¿Dónde estamos con este problema? Parece haber sido un poco de ida y vuelta. ¿Quieres actualizarme sobre el estado actual de esto?

Claro, el problema fue secuestrado un poco ... Así que nada cambió en la pregunta: el depósito que debería regresar a la dirección de recompensas después de retirar un grupo no está explícitamente en ninguna parte de la base de datos (por ejemplo, 500 ADA llegaron en la época 245). Pero debe verificar la tabla de retiro del grupo, si el grupo cuya dirección de propietario es la dirección de recompensas que está buscando y luego agregar manualmente un valor codificado de '500' a las recompensas del usuario SI esta cantidad de este retiro exacto no se ha retirado todavía. Lo que me parece realmente engorroso y propuse si podría ir a la tabla de recompensas, o en otro lugar, pero explícitamente.

El depósito que debería volver a la dirección de recompensas después de retirar un grupo no está explícitamente en ninguna parte de la base de datos.

¿Tiene una dirección de mainnet de ejemplo para que la investigue?

e11d227aefa4b773149170885aadba30aab3127cc611ddbc4999def61c / stake1uywjy7h05jmhx9y3wzy94td6xz4txynuccgam0zfn800v8qq33z29

Tiene una idea errónea sobre el reembolso del depósito. Los reembolsos de depósitos no terminan en la tabla reward sino en la tabla tx . Así que encontrémoslo.

Para la dirección que nos interesa:

cexplorer=# select id, view, registered_tx_id from stake_address
               where view = 'stake1uywjy7h05jmhx9y3wzy94td6xz4txynuccgam0zfn800v8qq33z29' ;
  id  |                            view                             | registered_tx_id 
------+-------------------------------------------------------------+------------------
 2820 | stake1uywjy7h05jmhx9y3wzy94td6xz4txynuccgam0zfn800v8qq33z29 |          2420601

el campo id puede ser diferente en las instancias db-sync , pero el id será útil para esta exploración.

Un poco complejo, pero el reembolso se puede ver usando:

cexplorer=# select stake_deregistration.id, stake_deregistration.addr_id, stake_deregistration.tx_id,
               tx.deposit, block.epoch_no from stake_deregistration
               inner join tx on tx.id = stake_deregistration.tx_id
               inner join block on block.id = tx.block_id
               where stake_deregistration.addr_id = 2820 ; 
 id  | addr_id |  tx_id  | deposit  | epoch_no 
-----+---------+---------+----------+----------
 730 |    2820 | 2842157 | -2000000 |      223

Del mismo modo, el registro puede verse usando:

cexplorer=# select stake_registration.id, stake_registration.addr_id, stake_registration.tx_id, tx.deposit,
               block.epoch_no from stake_registration inner join tx on tx.id = stake_registration.tx_id
               inner join block on block.id = tx.block_id
               where stake_registration.addr_id = 2820 ; 
  id   | addr_id |  tx_id  | deposit | epoch_no 
-------+---------+---------+---------+----------
  1649 |    2820 | 2421547 | 2000000 |      208
 86926 |    2820 | 2842177 | 2000000 |      223
(2 rows)

Supongo que esta dirección de participación fue:

  • registrado en la época 208
  • dado de baja en época 223
  • reinscrito de nuevo en la época 223.

¿Tiene sentido todo eso?

Tiene sentido para el registro de participación, pero estaba hablando de la jubilación del grupo. Y la ADA 500 que debe devolverse a la dirección de recompensa del propietario de la piscina.

Todavía no creo que vuelva a la dirección de recompensa. ¿Tiene un ejemplo de un grupo que se está retirando?

La relación o el hecho de que aparecería en la base de datos en algún lugar es en realidad mi solicitud de una función, no un error en la versión actual. Ejemplo de grupo retirado: pool134dws3tyc7kphwl6gks26cm6l390554lns9lyatm3gkxs6dwj2z. La dirección que envié antes es su propietaria.

@erikd
De la especificación del

Página 21

Recuerde que los reembolsos de jubilación del grupo de interés no se emiten cuando un certificado que programa la
se procesa la jubilación, pero en el límite de la época para la que está programada la jubilación.

Página 40

• La función poolRefunds se utiliza para calcular los reembolsos totales que deben distribuirse
para grupos de interés programados para retirarse. Tenga en cuenta que este cálculo toma un número de intervalo correspondiente al intervalo de límite de época cuando se realiza el cálculo. El retorno
map mapea los hashkeys del operador del grupo a los reembolsos, que finalmente serán devueltos al
cuenta de recompensa registrada.

@xdzurman Lo siento en esto:

La relación o el hecho de que aparecería en la base de datos en algún lugar es en realidad mi solicitud de una función,

¿Qué es exactamente la solicitud de función?

@erikd Para poner el depósito del grupo (500 ADA) en algún lugar de la base de datos, después de que se retira un grupo. Actualmente, no se puede vincular explícitamente a la dirección de recompensa a la que pertenece.

¿Fue útil esta página
0 / 5 - 0 calificaciones

Temas relacionados

kzka90 picture kzka90  ·  3Comentarios

erikd picture erikd  ·  10Comentarios

rhyslbw picture rhyslbw  ·  4Comentarios

erikd picture erikd  ·  4Comentarios

dmitrystas picture dmitrystas  ·  28Comentarios