[Feature Request] - Show next epoch's nonce (null until 7/10th of epoch) in output of cardano-cli protocol-state

[rdlrt]

External

Area Other Any other topic (Delegation, Ranking, ...).

Summary

(*Edited: original description was a misunderstanding regarding CandidateNonce being inaccurate, which isnt the case) Once passing the stability window from end (7/10th of an epoch), it is possible to fetch epoch nonce for next epoch. Currently , issuing cardano-cli query protocol-state --testnet-magic 2 | jq . requires post-processing on user end (see response from @JaredCorduan here , while the epoch nonce for current epoch can be used as-is.

Currently we'd end up having to do the below to get the equivalent:

echo "$(cardano-cli query protocol-state --testnet-magic 141 | jq -r .candidateNonce.contents)$(cardano-cli query protocol-state --testnet-magic 141| jq -r .lastEpochBlockNonce.contents)" | xxd -r -p | b2sum -b -l 256 | awk '{print $1}'

The feature request is to present the epoch nonce for next epoch once it's available.

[dostrelith678]

It's been more than a month since this issue was opened. Could we please get an update on this from someone? I have reproduced the bug with the steps above as well.

[JaredCorduan]

@rdlrt - I don't see a bug here.

• The candidate nonce does not freeze at the 2/3 mark in the epoch, but rather at the 7/10 mark (one stability window from the end). See "Figure 60: Update Nonce rules" of Shelley ledger spec.
• The candidate nonce is combined with a block header hash to produce the next epoch nonce. See "Figure 58: Tick Nonce rules" of Shelley ledger spec. Note that the extra-entropy field can also change the epoch nonce, but we used that feature precisely once, and it was removed with the Vasil HF.

Note that the spec uses the following notation:

• $η_0$ - the epoch nonce
• $η_c$ - the candidate nonce
• $η_{ph}$ - the previous hash of the first block in the epoch
• $η_e$ - the extra entropy

[rdlrt]

The candidate nonce does not freeze at the 2/3 mark in the epoch

Indeed, that was an inaccurate generalised statement to mention 2/3rd, but the nonce we're looking at was 5 mins before end of 1-hour long epoch.

The candidate nonce is combined with a block header hash to produce the next epoch nonce

That's interesting, thanks - was unaware that it's not usable as-is. But then also, this would mean we cannot rely on fetching epoch nonce for next epoch purely using output from CLI (without post-processing on client side) - as against epoch nonce for current epoch which is available from protocol-state readily usable. Do you think it would be a contention open for a change for CLI output?

[JaredCorduan]

But then also, this would mean we cannot rely on fetching epoch nonce for next epoch purely using output from CLI (without post-processing on client side) - as against epoch nonce for current epoch which is available from protocol-stake readily usable. Do you think it would be a contention open for a change for CLI output?

I think it's a totally reasonable feature request for the CLI to supply an additional field for the nextEpochNonce, which would either let the user know that the nonce is not yet frozen, or provide the value for the next epoch.

I had a quick look, and I think that lastEpochBlockNonce is what the ledger spec calls $η_{ph}$. This means that once the candidate nonce is frozen, the next epoch nonce will be the BLAKE2b-256 hash of the concatenation candidateNonce|lastEpochBlockNonce (the "seed operation" used in the ledger spec is specified in A.6 Abstract functions, and is implemented here in the ledger code).

[JaredCorduan]

@rdlrt would you like to edit the original issue to make it clear that this is now a feature request? or alternatively, you could close this one and make a new one (which references this one). I just don't want it to be obscured (and I don't myself often work in this repo, someone else will likely have to pick it up).

[rdlrt]

could you like to edit the original issue

done, thanks