Node Identity Authentication Layer

This layer not only ensures the uniqueness of node identities and resistance to forgery, but also provides fundamental authentication interfaces for computing-power verification, incentive attribution

In a decentralized computing power network, identity unforgeability is a prerequisite for building trusted collaborative relationships. Built on top of the communication encryption layer, DF Protocol designs a complete node identity authentication layer, which generates and verifies the unique identity identifier of each node—Node DH-ID—through cryptographic means, achieving "establishing trusted identities in a trustless environment."

Node DH-ID Generation

In the DF Protocol, node identities do not rely on traditional account systems (such as centralized wallet addresses or on-chain contract accounts). Instead, they are derived through cryptographic methods as native encrypted identity identifiers, known as Node DH-IDs.

This mechanism ensures that each node possesses a unique, non-forgeable, and verifiable on-chain identity, serving as the foundational authentication reference throughout data transmission and computing-power attestation processes.

1) Foundational Principles

Node DH-ID is an identity system derived from asymmetric key pair + hash mapping, constructed based on the following cryptographic primitives:

  • Elliptic Curve Diffie–Hellman (ECDH)

  • One-way hash functions (SHA-256 / Keccak-256)

  • Signature algorithms (ECDSA / Ed25519 / BLS)

The identity generation process is independent of on-chain account structures, featuring native cryptographic independence and natural compatibility with decentralized and anonymous environments.

2) Generation Process

Each DF node executes the following steps to generate its unique identity during initialization:

Step 1: Generate Key Pair

  • The node generates an ECDH key pair(sk, pk) through a secure entropy source.

  • Example curves: secp256r1 or curve25519 (used for deriving encrypted channel keys).

Step 2: Compute Identity Fingerprint

  • Hash the public key：DH_ID = SHA256(pk)

  • DH_ID serves as the unique identity identifier of the node in the DF network.

Step 3: Generate Declaration Signature

  • The node signs the DH_ID with its own wallet address to prove ownership.

  • The signature structure complies with the format of on-chain verification interfaces (e.g., EIP-712).

3) Identity Attribute Requirements

The design of Node DH-ID meets the following requirements:

Attribute
Requirement Description

Uniqueness

Each node's generated DH-ID is unique across the entire network and non-duplicable

Decentralization

Does not rely on registration servers or node lists; identity is self-generated

Anti-Forgery

Only nodes holding the private key can complete identity registration and signing

Verifiability

All DH-IDs can be verified via on-chain registries and off-chain signature checks

Anonymity (Optional)

Not bound to real user information; suitable for privacy-focused networks

4) Differences from Traditional Identity Models

Model Type
Description
Risk Description

Address-Bound Identity

Bind to wallet address (e.g., EOA)

Forgery-prone; difficult to prove consistency of physical devices

Registration-Based Identity

Rely on centralized platforms to assign UIDs

Non-reusable; lacks migration capability

DH-ID Identity (DF)

Natively generated based on key pairs, with on-chain hash declaration

Private keys, auditable data, and high security

5) Revocation and Re-registration Mechanism

If a node’s private key is lost or the key pair is replaced, the process of on-chain revocation of the old DH-ID and registration of a new identity must be performed;

  • The system supports the NodeRevoke() and NodeRebind() interfaces to prevent attack vectors caused by identity drift;

  • All change records are stored on-chain, available for invocation by the computing power verification and reward distribution systems.

6) Usage Integration

Node DH-ID will be used for:

  • Encrypted identity marker in the communication layer (Encrypted Packet Header);

  • Computing power verification signature field;

  • Reward attribution and distribution mapping;

  • Identity verification for node governance participation;

  • Zero-knowledge identity binding (future expansion).

Example

ECDH public  key：
pk = 0x04593a8f...acf11

DH-ID = SHA256(pk) = 
0xb14e925c6fe498bb2d7a12c7cf3af6fd48ff28f1b9...

sign：
Sig(0xb14e... | wallet_addr)

On-chain Node Identity Registration

To ensure verifiability, anti-forgery capability, and on-chain traceability of all node identities, DF Protocol implements an identity declaration mechanism that integrates cryptographic signatures with smart contracts. This process serves as the trust foundation for secure communication, computing-power verification, and revenue attribution.

1) Design Objectives

  • Ensure every node’s DH identity is publicly verifiable on-chain

  • Bind each identity to the node’s controlled wallet address to prevent impersonation and attacks

  • Provide a secure, lightweight, and auditable declaration and update workflow

  • Offer an identity anchor for communication encryption and computing-power rewards

2) Core Components

  • Node DH-ID: A unique identity identifier generated by hashing the node’s ECDH public key

  • Wallet Address: The wallet address controlled by the node, used for declaration signatures and governance binding

  • Identity Registry Contract: The smart contract deployed on-chain to manage node-identity registration

  • Sig_Wallet(DH-ID): A signature of the DH-ID using the wallet’s private key, proving ownership of the DH identity

3) Registration Workflow

Step 1: Identity Generation The node locally generates an ECDH key pair (sk, pk), and computes its DH-ID by hashing the public key:

DH-ID = SHA256(pk)

Step 2: Declaration Signature

The node uses its wallet private key to sign the DH-ID, producing the ownership proof:

Signature = Sign(wallet_sk, DH-ID)

Step 3: On-chain Registration Submission The node calls the on-chain registry contract method registerNode(DH-ID, pk, signature) and submits:

  • DH-ID: Identity identifier

  • pk: ECDH public key (or compressed form)

  • Signature: Wallet signature proving ownership

Step 4: On-chain Verification The registry contract performs the following checks:

  • Verify the signature: Verify(wallet_addr, DH-ID, signature)

  • Check whether the DH-ID already exists to prevent duplicate registrations

  • Write the identity mapping into on-chain storage

mapping(bytes32 => NodeIdentity) public nodeRegistry;

struct NodeIdentity {
    address wallet;
    bytes pubkey;
    uint64 registeredAt;
    bool revoked;
}

4）Interface Description

function registerNode(bytes32 dhId, bytes calldata pubkey, bytes calldata signature) external;
function revokeNode(bytes32 dhId) external;
function getNode(bytes32 dhId) view returns (NodeIdentity memory);

5）Security Properties

Mechanism
Security Objective

Wallet Signature

Proves identity ownership and prevents forged declarations

On-chain Storage

Provides an auditable, queryable identity index

Immutable Mapping

Prevents identity spoofing and replay attacks

Freeze & Revoke

Supports identity rotation or handling lost private keys

6）Identity Lifecycle

State
Description

Unregistered

The node has not yet declared its identity

Registered

Identity declaration completed; node becomes eligible to participate

Revoked

Identity is terminated by the node or the governance system

Re-bindable

Allows registering a new identity after unbinding the old DH-ID

7）Application Interface Call Paths

  • The communication layer reads the on-chain DH-ID mapping to prevent MITM attacks.

  • When verifying a node’s signature on computing-power submissions, it retrieves the DH-ID → wallet-address mapping.

  • The reward module uses the wallet address to determine the rightful incentive recipient.

PreviousCommunication Encryption LayerNextVerifiable Computing-Power Collaboration Layer

Last updated