feat(consensus): auto checkpointing mechanism with a master node

[dimxy]

New Auto Checkpoints feature

This PR adds Auto Checkpoints feature (timestamp or height activated)
Auto Checkpoints is a lightweight finality mechanism in Komodo-based blockchains based on dynamically created checkpoints as the chain progresses.

A single designated master node for each block issues a synchronization checkpoint, ensuring that no chain reorganisation is permitted below the most recent checkpoint. This effectively guarantees transaction finality up to a checkpoint depth of 4 blocks behind the chain tip.

Komodo’s implementation is derived from the Gulden (Munt) codebase and is used for both KMD mainnet and asset chains.

Updated and new RPCs:

• getblockchaininfo: added syncCheckpoint and syncCheckpointUpgrade fields,
• getcheckpoint: returns the latest checkpoint.

More info: https://github.com/dimxy/komodo/wiki/Auto-Checkpoints-description

DPoW sunsetting

This PR also adds sunsetting for the Komodo DPoW consensus code (timestamp or height deactivated):

• komodo_checkpoint()
• dPoW code in ActivateBaseChainStep()

TODO:

• fix master pubkey for KMD
• fix master pubkeys for asset chains
• auto-checkpoint activation height for KMD
• auto-checkpoint activation timestamp for asset chains
• dpoW sunsetting height (for KMD) and timestamp (for asset chains)

[DeckerSU]

Here https://github.com/dimxy/komodo/wiki/Auto-Checkpoints-description you mentioned that the auto-checkpointing system was derived from the Gulden (Munt) codebase, but Munt itself seems to have never had auto-checkpoints. Gulden’s auto-checkpointing is actually based on the checkpoint system originally developed by Peercoin (PPCoin). So I think it would be better to also mention the original implementation source.

p.s. Checkpoints were removed from the Peercoin codebase in this PR: peercoin/peercoin#588. Commit: peercoin/peercoin@6b43fbd.

[dimxy]

Here https://github.com/dimxy/komodo/wiki/Auto-Checkpoints-description you mentioned that the auto-checkpointing system was derived from the Gulden (Munt) codebase, but Munt itself seems to have never had auto-checkpoints. Gulden’s auto-checkpointing is actually based on the checkpoint system originally developed by Peercoin (PPCoin). So I think it would be better to also mention the original implementation source.

p.s. Checkpoints were removed from the Peercoin codebase in this PR: peercoin/peercoin#588. Commit: peercoin/peercoin@6b43fbd.

As I understood Gulden was renamed to Munt for some time. And their repo had auto checkpoints as an interim feature (where I took it from: https://github.com/muntorg/munt-official/commits/e6b6223c10d4123c170eb2e14897430cef24349e)

[DeckerSU]

As I understood Gulden was renamed to Munt for some time. And their repo had auto checkpoints as an interim feature (where I took it from: https://github.com/muntorg/munt-official/commits/e6b6223c10d4123c170eb2e14897430cef24349e)

My mistake, you are right. The Munt repository does include checkpoints. However, they are still derived from Peercoin, as indicated here:

https://github.com/muntorg/munt-official/blob/e6b6223c10d4123c170eb2e14897430cef24349e/src/Gulden/auto_checkpoints.cpp#L23-L24

// Automatic checkpoint system.
// Based on the checkpoint system developed initially by peercoin, however modified to work for Gulden.

p.s. I just wanted to find the origin to trace the full history of this feature. Maybe another branch or repository contains updates that Gulden (Munt) does not have, etc. That’s why I tried to draw attention to this.

[DeckerSU]

@dimxy It looks like I’ve found at least one logic error. Please take a look:

bool IsSunsettingActive(int nHeight, int64_t timestamp) {
    AssertLockHeld(cs_main);

    if (chainName.isKMD()) {
        return nHeight > nSunsettingHeight;
    } else {
        return timestamp > nSunsettingTimestamp;
    }
}

IsSunsettingActive compares the chain tip timestamp against the hardcoded nSunsettingTimestamp, which is the same for all asset chains. This becomes problematic if different chains are intended to have different activation times.

For example:

{ "MARTY",  { nSyncChkPointTimestamp, "03fdc6ca526c0cfaed2211d03dc2ea9c083aea127c7769d97dc92fed2085803ce3" }},
{ "GULDEN", { 1764606619, "02f9dc5271cc789aab77fb27e8007e681f93135cfcf92d4a514a4649c0e36f14ad" }},

In this case, the planned activation time for GULDEN is 1764606619 (Mon, Dec 01 2025 16:30:19 UTC). However, IsSunsettingActive will still report dPoW as active for GULDEN because nSunsettingTimestamp is set to 1767528000 (Jan 04 2025 12:00 UTC).

As a result, dPoW remains active independently of the chain’s checkpoint activation time. In other words, dPoW ends at nSunsettingTimestamp regardless of when checkpoints are actually activated. This behavior specifically affects asset chains and appears to be inconsistent with the intended activation logic.

[cipig]

the current implementation increases the confirmations for a tx beyond 1 only if it was notarized... if a CEX looks at confirmations (and not at rawconfirmations) and waits for eg 10, then deposits are not accounted if the tx was not notarized
was this accounted for?

[dimxy]

confirmations

Oh I should fix this, tyvm.
We should return ordinary "confirmations"

[dimxy]

confirmations

Oh I should fix this, tyvm. We should return ordinary "confirmations"

fixed c45d817