NEP: Dead Man’s Switch for Committee Node Maintenance

[shargon]

NEP: Dead Man’s Switch for Committee Node Maintenance

• Author: Fernando Diaz Toledano (shargon) [email protected]
• Discussions-To: https://github.com/neo-project/proposals/issues
• Status: Draft
• Type: Standards Track
• Category: Core
• Created: 2025-08-19

Abstract

This proposal introduces a "dead man’s switch" mechanism for committee nodes. Committee members must periodically sign a maintenance message within a policy-defined timeframe (e.g., 2 weeks). Failure to do so indicates that the node is unattended or not actively maintained. In such cases, the member loses its committee role, forfeits votes, and must repay the entry fee to rejoin.

Motivation

Committee members must actively maintain their infrastructure to ensure reliable governance and consensus. Without regular check-ins, inactive nodes may compromise the performance and trust of the network. This mechanism enforces ongoing responsibility by requiring explicit and periodic confirmation of activity.

Specification

Contract Overview

The DeadManSwitchContract will:

1. Define a maintenance window (e.g., 2 weeks).
2. Require committee members to sign and submit a keep-alive message within this window.
3. Verify signatures against committee public keys.
4. Penalize members who miss the deadline by removing them from the committee, resetting their votes, and requiring a new payment to rejoin.

Contract (Example)

public class DeadManSwitchContract : SmartContract
{
    // Events
    [DisplayName("KeepAliveSigned")]
    public static event Action<byte[]> OnKeepAliveSigned;

    [DisplayName("CommitteeRemoved")]
    public static event Action<byte[]> OnCommitteeRemoved;

    // Policy-defined maintenance window (e.g., 2 weeks)
    private static readonly string PolicyKey = "MaintenanceWindow";

    // Store latest keep-alive signature for each committee member
    public static void KeepAlive(byte[] member, byte[] signature)
    {
        if (!Crypto.Verify(signature, Runtime.PreviousBlockHash, member))
            throw new Exception("Invalid signature");

        Storage.Put(Storage.CurrentContext, member, Runtime.Time);
        OnKeepAliveSigned(member);
    }

    // Enforce removal of inactive members
    public static void EnforceDeadSwitch()
    {
        var committee = NEO.GetCommittee();
        var window = Policy.Get(PolicyKey);

        foreach (var member in committee)
        {
            var lastSigned = (BigInteger)Storage.Get(Storage.CurrentContext, member);

            if (Runtime.Time > lastSigned + window)
            {
                // Member failed to maintain activity
                Governance.RemoveCommitteeMember(member);

                // Clear stored record
                Storage.Delete(Storage.CurrentContext, member);

                // Votes are lost, re-entry requires fee
                Governance.ResetVotes(member);
                OnCommitteeRemoved(member);
            }
        }
    }
}

Policy

• MaintenanceWindow: Defines the maximum allowed interval between keep-alive signatures (e.g., 2 weeks).
• Signature Requirement: Each keep-alive must be signed using the committee member’s registered key and validated against the previous block hash.

Rationale

This approach enforces continuous maintenance by committee members. Missing the maintenance deadline signals an inactive or abandoned node, which weakens governance. By forcing the member to repay the entry fee and re-earn votes, the system ensures commitment and accountability.

Backwards Compatibility

No compatibility issues are expected. This contract introduces an additional safeguard without altering existing consensus rules.

Security Considerations

• Uses cryptographic signatures to prevent forgery of keep-alive messages.
• The previous block hash ensures uniqueness and prevents replay attacks.
• Strict penalties discourage negligence and enforce responsible participation.

[shargon]

#202 and #203 can have little proof of work to ensure that the node it's not a dummy one

[vncoelho]

#202 and #203 can have little proof of work to ensure that the node it's not a dummy one

I think that little proof of work compared to none is almost the same, @shargon. The point is to reach a hard proof of work...

[roman-khimov]

Uses cryptographic signatures to prevent forgery of keep-alive messages.

Isn't transaction signed by committee member key already sufficient for that?

The previous block hash ensures uniqueness and prevents replay attacks.

Transaction VUB is merciless, it prevents replays already.

To me it's a keepalive mechanism for committee nodes. If we want to ensure there is a node behind the key the code for this keepalive should be implemented in the dBFT plugin (because committee members should always be ready to become validators).

A separate contract doesn't look correct then, candidates are managed by NEO contract, so any kicking should be implemented there as well. There is also a technical problem of user votes/voter turnout if we're forcing deregistration (mentioned in https://github.com/neo-project/neo/pull/4126#issuecomment-3182875395).

Overall, the mechanism can be useful for the network, but if implemented we gonna lose half of the mainnet committee next day.