Network Identity - Algorand Specifications

Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Algorand Specifications

To avoid duplicated connections between peers, the node keeps track of the IdentityIdentity of each connected PeerPeer. The method is different for each network layer.

Important IMPLEMENTATION: Network identity reference implementation. Additional parts are in each network’s implementation.

This method is optional, and is enabled by setting the configuration value PublicAddress to the node’s public endpoint address stored in other peers’ phonebooks (e.g., r-aa.algorand-mainnet.network:4160).

The identity is verified in the WSWS network with a 3-way handshake between two peers.

ResponderRequesterResponderRequesterRequester verifies Responder’s identityResponder verifies Requester’s identityIf identity is already in use by another peer,connection is closed as duplicateStep 1: Identity ChallengeStep 2: Identity Challenge ResponseStep 3: Identity Verification

The challenge consists of three steps:

  1. Identity Challenge: when a request is made to start a gossip connection, an identityChallengeSigned message is added to HTTP request headers, containing:
    • A 32-byte random challenge,
    • The requester’s Identity(pk)Identity(pk),
    • The PublicAddress of the intended recipient,
    • Signature on the above by the requester’s sksk.
  2. Identity Challenge Response: when responding to the gossip connection request, if the identity challenge is valid, an identityChallengeResponseSigned message is added to the HTTP response headers, containing:
    • The original 32-byte random challenge from Message 1,
    • A new “response” 32-byte random challenge,
    • The responder’s Identity(pk)Identity(pk),
    • Signature on the above by the responder’s sksk.
  3. Identity Verification: if the identityChallengeResponse is valid, the requester sends a NetIDVerificationTag message over websocket to verify it owns its pkpk, with:
    • Signature on the response challenge from Message 2, using the requester’s sksk.

In steps 2 and 3, the PeerPeer that verified the identity tries to add the other one to its IdentityTrackerIdentityTracker, referencing the PeerPeer with their Identity(pk)Identity(pk).

Important IMPLEMENTATION: The IdentityIdentity challenge is derived from a random seed.

Important IMPLEMENTATION: Identity challenge reference implementation in:

When a PeerPeer requests to start a gossip connection in the P2PP2P network, instead of running an IdentityIdentity challenge, the peer’s raw pkpk is extracted from the libp2p’s PeerID as unique identifier for the PeerPeer.

In this case, there is no IdentityTrackerIdentityTracker, as libp2p handles it internally.

Important IMPLEMENTATION: P2PP2P network identity reference implementation.

In the HYBHYB network, the tracking of peers works with the IdentityIdentity challenge as seen in the WSWS Network, but using the libp2p private key as the IdentityIdentity challenge signer.

In this case, there is an IdentityTrackerIdentityTracker as the PeerPeer needs to keep track of the identities for the WSWS network.

Important IMPLEMENTATION: HYBHYB network identity reference implementation.