Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE] - Update cardano-cli conway query spo-stake-distribution #911

Closed
2 of 17 tasks
CarlosLopezDeLara opened this issue Sep 24, 2024 · 29 comments · Fixed by #990
Closed
2 of 17 tasks

[FEATURE] - Update cardano-cli conway query spo-stake-distribution #911

CarlosLopezDeLara opened this issue Sep 24, 2024 · 29 comments · Fixed by #990
Assignees
Labels
conway-feature intra-era-hardfork feature to be added for protocol version 10

Comments

@CarlosLopezDeLara
Copy link
Contributor

CarlosLopezDeLara commented Sep 24, 2024

What

We need to update the output of cardano-cli conway query spo-stake-distribution to include the DREP delegation choices of the Pool's reward account. This, once IntersectMBO/cardano-ledger#4645 is implemented, in particular:

To be more specific the solution to this problem is:

1.  To change the default vote for SPOs to `No` from `Abstain` for all of the three proposals in question
2. Check whether SPO's reward address is delegated to the predefined `AlwaysNoConfidence` DRep and count default vote as `Yes` only on `NoConfidence` proposals for that SPO.
3. Check whether SPO's reward address is delegated to predefined `AlwaysAbstain` DRep and count default vote as `Abstain` for that SPO on all three: `NoConfidence`, `UpdateCommitee` and `ParameterUpdate` proposals.

For example:

    [
        "dec39dd553180bf78b206258aba3861537b185580086ca3f62716f8d",
        10868846712397,
        "drep-alwaysAbstain"
    ],
    [
        "e2fd1cd89bba55dc457574adf420240c28a2bfdb3d460279e453c57a",
        10671709098807,
        "drep-keyHash-ffc25bcec3379aea4e32f353b4048fc7ab9fc1124c01738546e2f7bb"
    ],
    [
        "eec73ca2652e1ae92852195ff3289dd991a83dbe5f989f06e1c96b64",
        10703582488560,
        "drep-alwaysNoConfidence"
    ],
    [
        "f386ee192cf53c26da7457b7d8992ae0e52a05fc1c88c5d653a90021",
        10466189795103,
        "drep-scriptHash-186e32faa80a26810392fda6d559c7ed4721a65ce1c9d4ef3e1c87b4"
    ]

(Thank you @gitmachtl)

Why

IntersectMBO/cardano-ledger#4645 changes the way SPO votes are counted. The SPO reward account delegation choice will impact how the pool's stake counts for voting. It is important to show this information so that downstream tools can recreate the vote count.

Personas

  • SPOs
  • dApp Devs
  • Exchanges
  • Wallets
  • 3rd party tools
  • ADA holders

Definition of Done (DoD)

  • Acceptance Criteria + User Stories & DoD created and singed-off (by PO, dev & test owners)
  • Builds successfully on CI
  • Code & Test review (as per Acceptance Criteria)
  • There is documentation and/or examples for the new functionality (usage/response)
  • Log/record changes on Vnext (or similar depending on what we adopt)
  • Ticket number(s) included in PR description
  • All Acceptance Criteria met and covered by dev/unit/property/integration tests
  • System/E2E automated tests + System Test Engineer Owner Sign-off

NOTE: Ideally, we should merge only fully implemented and tested features into the master branch.
So all the above steps are required for the PR to be merged.
In order to avoid the PRs becoming stale and requiring to be rebased on master, these can be merged
after a reasonable time (current agreement is 3 days) if the System Test Engineer Owner's sign-off
was not provided (last step in the DoD).

IMPORTANT: Any deviation from the plan should be discussed and agreed as a comment in the Feature file.

Sign-off

  • Product Owner
  • Dev Owner
  • System Test Engineer Owner

Related PRs

Acceptance Criteria

The output must show the SPO rewards account delegation choice: "registered DRep", "Always abstain" or "Always no confidence"

@CarlosLopezDeLara CarlosLopezDeLara added conway-feature intra-era-hardfork feature to be added for protocol version 10 labels Sep 24, 2024
@gitmachtl
Copy link
Contributor

here is the cross reference to the ledger part
IntersectMBO/cardano-ledger#4663

@smelc smelc self-assigned this Oct 30, 2024
@gitmachtl
Copy link
Contributor

i will extended this FR to also change the spo-stake-distribution name into spo-power-distribution or spo-votepower-distribution.

@gitmachtl
Copy link
Contributor

@smelc did you have time yet to look into this? how realistic is it to have a new cli release with this update before the hf?

@smelc
Copy link
Contributor

smelc commented Dec 2, 2024

@gitmachtl> sorry no progress nearly yet because I've been helping with query proposals the last week (#984 and IntersectMBO/cardano-node#6045). When is the hf planned?

@gitmachtl
Copy link
Contributor

@smelc i think sometimes in january

@smelc
Copy link
Contributor

smelc commented Dec 2, 2024

@smelc i think sometimes in january

Then this might be doable. I'll focus on this one during the next days 👍 FYI @Jimbo4350

@smelc
Copy link
Contributor

smelc commented Dec 3, 2024

Work being done here: https://github.com/IntersectMBO/cardano-cli/commits/smelc/augment-spo-stake-distribution/

@gitmachtl
Copy link
Contributor

gitmachtl commented Dec 3, 2024

Work being done here: https://github.com/IntersectMBO/cardano-cli/commits/smelc/augment-spo-stake-distribution/

Have not checked your code yet, is the goal to mimic the output we set up as an example output here? #911 (comment)

I guess if there is no delegation of the rewards account yet, the output will simply be null for the default-delegation of that pool?

@smelc
Copy link
Contributor

smelc commented Dec 3, 2024

Have not checked your code yet, is the goal to mimic the output we set up as an example output here? #911 (comment)

I can but I think it's not a really nice output. So far I went for this, but really it's up to you tell me what you want (taking the community's opinion into account):

[{"stake":45017728438785,
  "stakePool":"6d598b98e752c8e3efa20134bb498b7a63daf2def7ea559654584ea3",
  "voteDelegation":null}]

Tackling this issue can be a good moment to change the output's format.

Have not checked your code yet, is the goal to mimic the output we set up as an example output here? #911 (comment)

Yes

@gitmachtl> would you be able to test this branch? It's right now based on cardano-cli-10.1.0.0, so that I can more easily test it locally with cardano-testnet-test, but I can rebase on another version if that would help you.

@gitmachtl
Copy link
Contributor

gitmachtl commented Dec 3, 2024

@smelc the thing is that this than would be a breaking change for tooling, adding just a 3rd entry will most likely not break any tooling.

yeah... let me test your branch

@smelc
Copy link
Contributor

smelc commented Dec 3, 2024

@smelc the thing is that this than would be a breaking change for tooling, adding just a 3rd entry will most likely not break any tooling.

@gitmachtl> Sounds good 👍 I added commit Revert to triplet JSON to just add the third entry 👍

@gitmachtl
Copy link
Contributor

@smelc having some issues compiling this branch. can you give me a hint on how to link the correct cardano.api.ledger ?

src/Cardano/CLI/EraBased/Run/Query.hs:1687:71: error:
    Not in scope: ‘L.coerceKeyRole’
    Module ‘Cardano.Api.Ledger’ does not export ‘coerceKeyRole’.
     |
1687 |         _stakeCreds' :: [L.Credential L.Staking StandardCrypto] = map L.coerceKeyRole _stakeCreds
     |                                                                       ^^^^^^^^^^^^^^^

src/Cardano/CLI/EraBased/Run/Query.hs:1693:60: error:
    Not in scope: ‘L.coerceKeyRole’
    Module ‘Cardano.Api.Ledger’ does not export ‘coerceKeyRole’.
     |
1693 |              ) = Map.fromSet (fromShelleyStakeCredential . L.coerceKeyRole . L.KeyHashObj) spos
     |                                                            ^^^^^^^^^^^^^^^
Error: cabal: Failed to build cardano-cli-10.1.0.0 (which is required by
test:cardano-cli-test from cardano-cli-10.1.0.0 and test:cardano-cli-golden
from cardano-cli-10.1.0.0).

@smelc
Copy link
Contributor

smelc commented Dec 4, 2024

@gitmachtl> sorry my bad, I should have thought of this.

I have added an SRP in an additional commit to the https://github.com/IntersectMBO/cardano-cli/commits/smelc/augment-spo-stake-distribution/ branch, so it should compile on your end now.

@gitmachtl
Copy link
Contributor

gitmachtl commented Dec 4, 2024

@smelc hmm...

remote: Enumerating objects: 108652, done.
remote: Counting objects: 100% (1629/1629), done.
remote: Compressing objects: 100% (647/647), done.
remote: Total 108652 (delta 808), reused 1412 (delta 642), pack-reused 107023 (from 1)
Receiving objects: 100% (108652/108652), 54.03 MiB | 3.46 MiB/s, done.
Resolving deltas: 100% (68059/68059), done.
fatal: Could not parse object 'e2c544815bc3a8994e8fdb70a0153244ee77ea75'.

i guess the error is because this commit belongs to your repository?

@smelc
Copy link
Contributor

smelc commented Dec 4, 2024

@gitmachtl> it's there but not on a branch (because I rebased since then):

image

Maybe that's the issue, so creating the branch right away.

[edit] Created a branch for IntersectMBO/cardano-api@e2c5448: https://github.com/IntersectMBO/cardano-api/tree/smelc/legacy-additional-exports

@gitmachtl
Copy link
Contributor

@smelc yup, that worked, thx!

@gitmachtl
Copy link
Contributor

@smelc when i try the updated command, i get the result of null for all pool entries drep-delegation. currently using sanchonet and preview for this with node 10.1.3.

@smelc
Copy link
Contributor

smelc commented Dec 5, 2024

@smelc when i try the updated command, i get the result of null for all pool entries drep-delegation. currently using sanchonet and preview for this with node 10.1.3.

@gitmachtl> yes I think something is off, but I've been blocked by other bugs to fully grasp the problem using cardano-testnet. How can I reproduce your test on sanchonet?

@gitmachtl
Copy link
Contributor

gitmachtl commented Dec 5, 2024

I am running a synced node 10.1.3 on sanchonet. Than i ran the cli command:

cardano-cli conway query spo-stake-distribution --all-spos

which resulted in the output

[
    [
        "02641404878b0b7efce28de535c67ddcf073606082d01a3eb01a82ab",
        10448318886193,
        null
    ],
    [
        "1b7a61ba3e5292f34666af3bb2f0b8d36e5001aa41e235709ffa6910",
        10370106478741,
        null
    ],
    [
        "30c650e28e1df418bf6881a893fbf872043b522d27d7ad8ead443c82",
        10351296264363,
        null
    ],
    [
        "350856bd7854339f7baef0e71e34dbc73f256552814f1d94e42281c3",
        10349889752909,
        null
    ],
    [
        "3531737ad43673ec059ff03249c3b8d4cfe29fa764d7fd96cc731805",
        97467769,
        null
    ],
    [
        "395933c7b6ca33d1f4a2b22472a6321bc050b166f3f89bb4195f68d5",
        47288144,
        null
    ],
    [
        "3c4fb94e1a2c5649a870aee5a70f21cd64807c7dc38632efcaf3d921",
        13033009187006,
        null
    ],
...
    [
        "e561b840eb762b0468e123b5fb38b1e1da1a02f25a97308309e10d9d",
        99761010184,
        null
    ],
    [
        "eae7268bbae047d838d95de2d635681df9eb1f122a4798779f3e8918",
        10351489475676,
        null
    ],
    [
        "f08b6d872f3caa1b4e65cd1e74d51e6ac000e7303ac18c92d0fca1c1",
        97469265,
        null
    ],
    [
        "f5fddd5469f8bbedb726227df2c6feaeaaeaf79aa597a1fb7f971af4",
        10450752644786,
        null
    ]
]

We have some testpools running on sanchonet, one is for example pool id 1b7a61ba3e5292f34666af3bb2f0b8d36e5001aa41e235709ffa6910

${cardanocli} conway query spo-stake-distribution --spo-key-hash 1b7a61ba3e5292f34666af3bb2f0b8d36e5001aa41e235709ffa6910

[
    [
        "1b7a61ba3e5292f34666af3bb2f0b8d36e5001aa41e235709ffa6910",
        10370106478741,
        null
    ]
]

and that output should actually be like:

[
  [
    "1b7a61ba3e5292f34666af3bb2f0b8d36e5001aa41e235709ffa6910",
    10370106478741,
    "drep-alwaysNoConfidence"
  ]
]

@smelc
Copy link
Contributor

smelc commented Dec 6, 2024

@gitmachtl> how would yo obtain the information using other queries? This is so that I can debug using a successful case.

@gitmachtl
Copy link
Contributor

gitmachtl commented Dec 6, 2024

@smelc here is a code snippet you can run to get the values via koios and some conversion magic:

#!/bin/bash
koiosAPI="https://sancho.koios.rest/api/v1"
echo "### KOIOS: get pool list"
tmpPoolList=$(curl -s -X GET "${koiosAPI}/pool_list" -H "accept: application/json" | jq -r '[.[].pool_id_bech32]')
echo "### KOIOS: get detailed pool infos"
tmpPoolInfos=$(curl -s -X POST "${koiosAPI}/pool_info" -H "accept: application/json" -H "content-type: application/json" -d "{\"_pool_bech32_ids\":${tmpPoolList}}")
poolStakeDistributionJSON=$(jq -r '[ .[] | [ .pool_id_hex, ((.voting_power // 0) | tonumber), .reward_addr_delegated_drep ] ]' <<< ${tmpPoolInfos})
poolStakeDistributionJSON=$(sed "s/drep_always_abstain/drep-alwaysAbstain/g" <<< ${poolStakeDistributionJSON})
poolStakeDistributionJSON=$(sed "s/drep_always_no_confidence/drep-alwaysNoConfidence/g" <<< ${poolStakeDistributionJSON})
echo "### POOL LIST:"
jq -r <<< ${poolStakeDistributionJSON}

query takes a while. that little snippet would not work on preview or any other network because the number of pools is too large to query the info in one take. that would require multiple queries. but i think if you can use sanchonet than that should be ok.

the drep output for individuals is in bech format (cip129) with that query, but that should be ok for comparision?

cli output is drep-keyHash-... and drep-scriptHash-... right? to be consistent with the outputs from the proposal queries, etc.

@smelc
Copy link
Contributor

smelc commented Dec 6, 2024

@gitmachtl> in terms of CLI only, can you confirm that I get the info you want as follows (using the SPO id 1b7a61ba3e5292f34666af3bb2f0b8d36e5001aa41e235709ffa6910 as guidance):

# First obtain the reward account key hash
>  cabal run cardano-cli -- conway query pool-state --stake-pool-id 1b7a61ba3e5292f34666af3bb2f0b8d36e5001aa41e235709ffa6910 --testnet-magic 4
{
    "1b7a61ba3e5292f34666af3bb2f0b8d36e5001aa41e235709ffa6910": {
        "futurePoolParams": null,
        "poolParams": ...
            "rewardAccount": {
                "credential": {
                    "keyHash": "468bfb1fc096297a108bfdfb3bd6aa7eb4182f378bbe0241fd50c18c"
                },
                ...
            },
            ...
        },
    }
# Obtain the address 
> cabal run cardano-cli -- conway stake-address build --stake-key-hash 468bfb1fc096297a108bfdfb3bd6aa7eb4182f378bbe0241fd50c18c --testnet-magic 4 > stake-468bfb1fc096297a108bfdfb3bd6aa7eb4182f378bbe0241fd50c18c.addr
# For reference
> cat stake-468bfb1fc096297a108bfdfb3bd6aa7eb4182f378bbe0241fd50c18c.addr 
stake_test1uprgh7clcztzj7ss307lkw7k4fltgxp0x79muqjpl4gvrrqxcnvpz
# Obtain info
> cabal run cardano-cli -- conway query stake-address-info --testnet-magic 4 --address $(cat stake-468bfb1fc096297a108bfdfb3bd6aa7eb4182f378bbe0241fd50c18c.addr)
[
    {
        "address": "stake_test1uprgh7clcztzj7ss307lkw7k4fltgxp0x79muqjpl4gvrrqxcnvpz",
        "delegationDeposit": 2000000,
        "rewardAccountBalance": 175821528233,
        "stakeDelegation": "pool1rdaxrw3722f0x3nx4uam9u9c6dh9qqd2g83r2uyllf53qmmj5uu",
        "voteDelegation": "alwaysNoConfidence"
    }

And so you want spo-stake-distribution (or renamed like you want) to show the voteDelegation field obtained in this manner ☝️?


Or do you want the default vote of an SPO? (i.e. using IntersectMBO/cardano-ledger#4735 @CarlosLopezDeLara who pointed this out to me!)

@gitmachtl
Copy link
Contributor

gitmachtl commented Dec 6, 2024

@smelc the voteDelegation of the pools rewards account is the default vote of an SPO. is it not implemented that way?

your question confuses me now. the result should be the same.

@smelc
Copy link
Contributor

smelc commented Dec 6, 2024

@smelc the voteDelegation of the pools rewards account is the default vote of an SPO. is it not implemented that way?

From the CLI point of view, no, until we have access to IntersectMBO/cardano-ledger#4735. This PR made it to cardano-ledger-api in version 1.9.5, but CLI depends on version 1.9.3. right now.

What I can do is go through the hoops shown above until we have access to the ledger's query, so that you have the desired output asap. It's a small task.

@gitmachtl
Copy link
Contributor

@smelc can you specify what you mean with SPO? the pledge account of a pool is not the account we are looking here for the voteDelegation. its the rewards account of a pool. that can be one of the pledge accounts, but its not a must.

@gitmachtl
Copy link
Contributor

gitmachtl commented Dec 6, 2024

ah ok, so you are missing the query in ledger-api 1.9.3 which would be a quicker already made solution for that.

well i guess it depends on the release schedule of api 1.9.5? if its around the corner i think you can wait until its available. if it takes longer and will be finished after the holidays or so, than it would be nice to get it implemented (even temporary) earlier. so we can play around with it over the holidays.

@smelc
Copy link
Contributor

smelc commented Dec 6, 2024

@smelc can you specify what you mean with SPO?

@gitmachtl> I mean the identifier that is passed to query spo-stake-distribution.

the pledge account of a pool is not the account we are looking here for the voteDelegation. its the rewards account of a pool. that can be one of the pledge accounts, but its not a must.

Sorry I'm not super savvy regarding how pools operate. I have a programmatic thinking here, so really I meant following the process described above but programmatically in Haskell. If this process is not always right, then there is no other choice than waiting for the ledger's query to be available to CLI, which is probably a few weeks away at this point.

And I will personally be off starting from the end of next week (EOD Friday 13th), so either I try to give you something during the next days; or it will probably be next year. Except if someone else from the CLI team picks it up, but we are all on PTO at some point during the next weeks.

@gitmachtl
Copy link
Contributor

hi, ah ok, thanks for the reply. so yes, the process described above will lead to the right result all the time. if you have the time to integrate it that way before the holidays that would be awesome. :-)

@smelc
Copy link
Contributor

smelc commented Dec 6, 2024

if you have the time to integrate it that way before the holidays that would be awesome. :-)

@gitmachtl> I'll look at this next week. I have quite a few duties planned already, but should be able to ship it before I leave for vacation 👍 cc @Jimbo4350

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
conway-feature intra-era-hardfork feature to be added for protocol version 10
Projects
None yet
3 participants