validate election proofs

[prednaz]

nix run github:intersectmbo/cardano-node#cardano-cli -- conway query leadership-schedule --help probably queries the relevant information, sometimes called "ledger view"

[prednaz]

we identified validateHeader as the ideal function to call, but gave up because the LedgerView is so difficult to construct and, internally, is not even used for the election proof validation. the election proof validation is eventually delegated to doValidateVRFSignature in the case of ConsensusProtocol (Praos c), which in turn delegates it to checkLeaderNatValue. cardano-cli -- conway query leadership-schedule eventually delegates the election proof validation to this function too, which is a nice sanity check.

i did not manage to track what function validateHeader eventually delegates the election proof validation to in the ConsensusProtocol (TPraos c) case, and directly imitated cardano-cli -- conway query leadership-schedule's behavior on my philipp/election_proof branch.

i have not tested this yet but i am quite sure that the local state query protocol would constantly throw AcquireFailurePointNotOnChain and AcquireFailurePointTooOld at us because the local state query protocol can only be used for known chain points between the immutable tip and the volatile tip.

AcquireFailurePointNotOnChain is thrown when validating a header our full node has not seen yet. theoretically, this could be fixed because we need not local state query for the PoolDistr at the exact chain point but just at a chain point of the same epoch. practically, there is no obvious way of coming up with an arbitrary chain point in a specific epoch. ChainSync.Client.SendMsgFindIntersect comes to mind. does it give you the greatest known chain point less than or equals to the passed chain point?

AcquireFailurePointTooOld is thrown when validating a header from before the immutable tip. i think, persisting the complete PoolDistr for every EpochNo is the only solution.

[prednaz]

we need not local state query for the PoolDistr at the exact chain point but just at a chain point of the same epoch.

this is not sufficient. their intersection, that is, their greates common ancestor, must be within the same epoch too.

ChainSync.Client.SendMsgFindIntersect comes to mind. does it give you the greatest known chain point less than or equals to the passed chain point?

as a consequence, this is actually the best you can do even though it does not give you the greatest known chain point less than or equals to the passed chain point.

persisting the complete PoolDistr for every EpochNo

as another consequence, this is not sufficient and our full node never even has sufficient information, which would require having all forks followed by 1 full node each, which is unfeasible.

just persisting the complete PoolDistr for every EpochNo does allow validation of some headers with intersection points before the immutable tip. but this can be just a separate optional future feature.