Cardano-db-sync: Exemplo de saldo de conta

Obrigado por abrir este problema em meu nome! Apenas para esclarecer um pouco mais - não é apenas sobre a conta em si, mas principalmente sobre rastrear reap em algum lugar no banco de dados para que possa ser facilmente usado no cálculo do saldo da conta (que é usado em todos os lugares, por exemplo, pool live tamanho da aposta, penhor ao vivo do pool, etc.).

@1000101 O que é "colheita"? Não há tabela ou coluna em db-sync chamada "reap".

O saldo da conta não é trivial.

Os endereços nas eras Shelley e posteriores têm dois componentes; uma credencial de pagamento e uma credencial de staking. O endereço da aposta (por exemplo stake1uyluup0rh6r2cc7kcw8nudqz990ezf5ltagxmw3u8deukvqwq7etq ) é derivado do último. No entanto, é possível construir um endereço válido que não contenha nenhuma credencial de staking.

Portanto, embora seja possível obter o saldo da conta para um endereço de aposta específico, não há como obter o saldo da conta de uma carteira, a menos que todos os endereços dessa carteira incluam a mesma credencial de aposta.

@1000101 O que é "colheita"? Não há nenhuma tabela ou coluna em db-sync chamada "reap".

Oh, me desculpe por não esclarecer isso o suficiente. O que eu quis dizer está descrito em https://github.com/input-output-hk/cardano-db-sync/issues/474 - ou seja, o que estou dizendo é exatamente que não há coluna para isso, mas seria ótimo se haveria.

Atualmente, não há como calcular facilmente o saldo de uma conta, quando esta conta foi usada no registro do pool (como uma conta de recompensa) e posteriormente o pool foi retirado, recuperando assim o depósito do pool. O "pagamento" do depósito do pool é rastreado no dbsync, mas não seu "reembolso" quando um pool é retirado.

Eu concordo com isto. Existem também vários casos de borda que cada "usuário" de cardano-db-sync teria que lidar. Tanto Adalite quanto Yoroi ficam confusos quando veem uma conta que anteriormente era uma conta de recompensa de um pool aposentado:

Além disso, apenas o AFAIK cardanoscan lida com as recompensas restantes corretamente e não usa db-sync.

Deve haver uma relação fácil que seria atualizada da mesma forma que as recompensas são adicionadas automaticamente. Vamos pegar um pool com vários cancelamentos como exemplo, já que isso é bastante comum e é difícil lidar com o saldo de recompensa de sua conta de proprietário.

Existem 9 certificados de aposentadoria para ele

E 15 certificados de registro

Existem inúmeros casos extremos e regras vagas de anulação de aposentadoria por novos certificados .

@erikd , se você insistir em conexão suficiente entre o depósito de 500 tx e as aposentadorias, como você escreveria uma consulta apenas para os depósitos devolvidos de uma de suas contas de proprietário - e127e9e94eaa9287680e877832700a1724255e9688609497e09a6c440f? Se não, podemos adicionar isso explicitamente ao db-sync? Digamos, como uma nova tabela, chamada pool_refunds , com addr_id , valor (atualmente deve ser um múltiplo de 500) e epoch_no - para que isso seja tratado corretamente e em um único local.

Atualmente db-sync extrai dados do estado do razão e os insere no banco de dados. Ele descarta algumas informações, mas não faz agregações. O que é inserido no banco de dados é simplesmente um reflexo do que o estado do razão fornece.

Vejamos o pool_hash.id relevante:

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

O pool foi registrado (junções extras para colocá-los em ordem crescente de block_no ) da seguinte forma:

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

e cancelado em:

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

Desintercalar atualizações e cancelamentos de registro:

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

Continua ....

Isso é definitivamente muita dor no pescoço. Conversando com pessoas de especificações de contabilidade para tentar encontrar uma solução.

Falado para as pessoas ledger-specs que sugeriram uma maneira rápida e suja de falsificá-lo por enquanto enquanto aguardam uma solução melhor.

A idéia seria ter algo como uma tabela pool_registration_refund contendo o endereço da aposta e o valor.

Seria ótimo!

Falado para as pessoas ledger-specs que sugeriram uma maneira rápida e suja de falsificá-lo por enquanto enquanto aguardam uma solução melhor.

A idéia seria ter algo como uma tabela pool_registration_refund contendo o endereço da aposta e o valor.

Impressionante! Quero dizer, nós temos uma solução alternativa por enquanto para não atingirmos o saldo negativo que @xdzurman compartilhou, mas são cerca de 100 linhas de SQL não tão bonitas:tm : que devem ser computadas por cada conta. Isso definitivamente ajudaria muito. Obrigado mil!!!