neo-project
NEP: Heartbeat Smart Contract for Committee Liveness
NEP: Heartbeat Smart Contract for Committee Liveness
- 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 heartbeat smart contract that ensures the liveness of NEO committee nodes. The mechanism requires committee members to manually acknowledge heartbeat challenges within a defined time window, preventing automated responses. Failure to respond in time leads to removal from the committee, ensuring that only active and responsive nodes remain.
Motivation
Committee members are responsible for maintaining consensus and governance in the NEO blockchain. However, inactive or unattended committee nodes may hinder governance and security. This proposal introduces a transparent mechanism to guarantee that committee members are alive, active, and responsive.
Specification
Contract Overview
The HeartbeatContract will:
- Allow any user to propose a heartbeat challenge.
- Require each committee member to respond within a policy-defined timeframe.
- Ensure responses cannot be automated, enforcing human verification.
- Penalize members who fail to respond by losing their committee seat, passing it to the next eligible candidate.
Contract (Example)
public class HeartbeatContract : SmartContract
{
// Events
[DisplayName("HeartbeatProposed")]
public static event Action<byte[]> OnHeartbeatProposed;
[DisplayName("HeartbeatResponded")]
public static event Action<byte[], byte[]> OnHeartbeatResponded;
[DisplayName("CommitteePenalized")]
public static event Action<byte[]> OnCommitteePenalized;
// Policy-defined heartbeat window (in seconds)
private static readonly string PolicyKey = "HeartbeatWindow";
// Propose a heartbeat challenge
public static void ProposeHeartbeat(byte[] proposer)
{
// Store challenge with timestamp
Storage.Put(Storage.CurrentContext, "challenge", Runtime.Time);
OnHeartbeatProposed(proposer);
}
// Committee member response
public static void RespondHeartbeat(byte[] member, byte[] proof)
{
var challengeTime = (BigInteger)Storage.Get(Storage.CurrentContext, "challenge");
var window = Policy.Get(PolicyKey);
if (Runtime.Time > challengeTime + window)
throw new Exception("Response window expired");
// Save response
Storage.Put(Storage.CurrentContext, member, proof);
OnHeartbeatResponded(member, proof);
}
// Check expired responses and penalize inactive committee members
public static void EnforcePenalties()
{
var challengeTime = (BigInteger)Storage.Get(Storage.CurrentContext, "challenge");
var window = Policy.Get(PolicyKey);
if (Runtime.Time <= challengeTime + window)
throw new Exception("Window still open");
var committee = NEO.GetCommittee();
foreach (var member in committee)
{
if (Storage.Get(Storage.CurrentContext, member).Length == 0)
{
// Penalize inactive member
Governance.RemoveCommitteeMember(member);
OnCommitteePenalized(member);
}
}
}
}
Policy
- HeartbeatWindow: Defines the time (in seconds) allowed for responses.
- Proof Requirements: Each response must include non-automated data (e.g., signed nonce, human factor challenge).
Rationale
This contract strengthens committee accountability by requiring active presence. Automatable solutions are explicitly rejected by design, requiring manual interaction.
Backwards Compatibility
No incompatibilities expected. The contract can be introduced as an additional governance safeguard without altering existing consensus rules.
Security Considerations
- Responses must require cryptographic signatures to prevent replay.
- Non-automated proof is required to ensure human validation.
- The penalty mechanism prevents inactive nodes from stalling governance.
This proposal introduces a heartbeat smart contract that ensures the liveness of NEO committee nodes. The mechanism requires committee members to manually acknowledge heartbeat challenges within a defined time window, preventing automated responses. Failure to respond in time leads to removal from the committee, ensuring that only active and responsive nodes remain.
I think that this challenge could be something related to the current MPT or something that requires a full node to keep that information. We can make something related to that merged with the address of the committee.
This proposal introduces a heartbeat smart contract that ensures the liveness of NEO committee nodes. The mechanism requires committee members to manually acknowledge heartbeat challenges within a defined time window, preventing automated responses. Failure to respond in time leads to removal from the committee, ensuring that only active and responsive nodes remain.
I think that this challenge could be something related to the current MPT or something that requires a full node to keep that information. We can make something related to that merged with the address of the committee.
Agree, a proof of work according the MPT it's good to me
Ensure responses cannot be automated, enforcing human verification.
That's hard. And I don't think it's needed. If there is a node running with committee member key and if it's ready to serve as a validator node --- it's fine to me. Any "unattended committee nodes" (like not following network upgrades) will break eventually anyway. And if they're not broken --- it's all fine.
Automated removal is dangerous and introduces some opportunity for exploitation. Logging and publically reporting analytics so the token holders can vote is cleaner imho and more accurately aligns with the role of governance in the ecosystem.
I think(personally), that there is an obligation for some base availability of the nodes, but think the token holders should decide the balance between availability and other value propositions. I dont think we should be deciding who lives/dies. That should be a decision for the token holders and we already have a comprehensive solution through voting.
For example, if there are two candidates:
(1) a non-technical council member with incredible ROI on the GAS generation, but only 5 9s in availability.
(2) a technical council member that dumps GAS on the community with 0 involvement, but with 10 9s of availability.
As a NEO token holder, I want the opportunity to vote on the importance of availability alongside other valuable council traits.
I dont like the idea of it being something that is controlled by whoever controls the code (core devs) and its deployment (council), both of which have some implicit conflict of interest.
