Proof of Node by Staking & Slashing

[shargon]

I'm agree with @erikzhang in:

I believe that if a node deliberately pretends to be online while refusing to participate in the consensus process, there is essentially no reliable way for us to detect such behavior. Therefore, the primary purpose of “proof of node” should not be to identify malicious non-participation. Instead, it should focus on preventing accidental misconfigurations by candidates—such as forgetting to run the node, failing to start the consensus module, or unintentionally launching multiple consensus instances.

So my proposal is:

Replace PoW Handshake with On-Chain Node Registration (Staking & Slashing) for P2P Sybil Prevention

To eliminate the need for Proof-of-Work (PoW) in the Proof of Node, which is inefficient and vulnerable to large-scale Sybil attacks if the difficulty is low, or overly resource-intensive if the difficulty is high. Instead, we will implement an economically guaranteed and on-chain verifiable Node Registration mechanism based on Staking (Proof-of-Stake) and penalties (Slashing) to prove node existence.

Solution Overview (Staking Registry)

A central native Smart Contract will be created (Staking) to act as the immutable source of truth for P2P node identities.

Registration (Staking)

For a node to participate in the network, it must stake a minimum amount of native tokens (e.g., 500 or 1000 NEO).

• The aspiring node calls an SC function, registerNode(publicKey), and attaches the required staking amount.
• The SC stores the pair (publicKey, stakedAmount) in its storage.

Introducing Slashing (Penalty Mechanism)

While staking prevents attackers from registering thousands of nodes, the real threat is registered nodes engaging in malicious behavior.

Mechanism

A function slashNode(publicKey, reasonCode) will be added to the Staking.

Slashing Conditions

Slashing will be triggered when a registered node is reported and verified by the network (e.g., by Consensus Nodes or an off-chain committee governed by the DAO) for the following offenses:

• Malicious Behavior: Verifiable attempts at transaction malfeasance, such as equivocation (signing two different blocks for the same height), double-spending attempts, or broadcasting invalid consensus messages.
• Prolonged Denial-of-Service (DoS): Unacceptable downtime or long periods of inactivity that affect network performance and prevent the node from participating in block production or transaction relay.
• Excessive View Changes (Consensus Nodes Only): This condition applies specifically to Consensus Nodes.

Consequences

• Stake Confiscation: A portion (e.g., 50%) or the entirety of the offending node's locked stake is burned or redirected to the network treasury.
• Expulsion: The publicKey is removed from the registry, and the node is temporarily banned from re-registering.

Detection of Misbehavior for Slashing:

Detection is based on the principle that misbehavior must be obvious and verifiable by the rest of the network, allowing any participant to submit proof to the native contract.

For Consensus Nodes:

Excessive View Changes: The historical record of the blockchain (locally available to all nodes) shows which CN was the last Primary in the failed view or the proponent of the View Change that was accepted. Proof of continuous failures is submitted.

Regular Nodes (Non-CN):

For regular nodes that only relay transactions and blocks, a more explicit and less frequent proof-of-liveness mechanism is required.

Proof of Liveness Mechanism (Liveness Request)

Activation: Any node (or a designated committee) suspecting a registered node (targetPubKey) is inactive can send a transaction to the slashing SC, calling a function like requestLiveness(targetPubKey).

Grace Period: The SC starts a timer (gracePeriod) for that targetPubKey (e.g., 100 blocks). The SC emits an on-chain event that the targetPubKey must listen for.

Response Requirement: Within this grace period, the targetPubKey must send a second transaction to the SC, calling respondLiveness(myPubKey, signature). This transaction acts as an on-chain ACK (acknowledgment), proving: a. The node is online and relaying blocks (it was able to see the event). b. It controls the private key associated with myPubKey.

Slashing: If the gracePeriod expires without the SC receiving the respondLiveness from the target node, any node can call the finalizeSlashing(targetPubKey) function on the SC. The contract verifies that the timer has expired and executes the penalty.

This method ensures that punishment is only applied if inactivity can be undeniably proven through the immutable state of the contract.

[vncoelho]

It is much better now, @shargon
I think it is a good direction.

I will soon come back here.