Peer to Peer

Peer-to-Peer is a mechanism that enables the participant (or in our it is the zoobc node) of the network to talk to each other directly. Blockchain as a decentralized system and so called trustless netwok, it is very critical for nodes to have functionality to talk to other nodes directly to give ability to individual nodes to decide the blockchain states he think is the correct one.

The peers list are some of the data that every nodes are allowed to have different opinion about. It means, every nodes can have different list of peers and it is not part of the blockchain state.

In our code structure, it implements strategy pattern to enable selectig peer to peer algorithm want to use.

• Native Strategy

  using gRPC framework to request & receive service on a network.

  gRPC service for p2p defined in common/service/P2PCommunication.proto.

  Available p2p service:

   service P2PCommunication {
       rpc GetPeerInfo(model.GetPeerInfoRequest) returns (model.Node) {}
       rpc GetMorePeers(model.Empty) returns (model.GetMorePeersResponse) {}
       rpc SendPeers(model.SendPeersRequest) returns (model.Empty) {}
       rpc SendBlock (model.Block) returns (model.Empty) {}
       rpc SendTransaction (model.SendTransactionRequest) returns (model.Empty) {}
  
       // used for blockchain synchronization functionality
       rpc GetCumulativeDifficulty(model.GetCumulativeDifficultyRequest) returns (model.GetCumulativeDifficultyResponse){}
       rpc GetCommonMilestoneBlockIDs(model.GetCommonMilestoneBlockIdsRequest) returns (model.GetCommonMilestoneBlockIdsResponse) {}
       rpc GetNextBlockIDs(model.GetNextBlockIdsRequest) returns (model.BlockIdsResponse) {}
       rpc GetNextBlocks(model.GetNextBlocksRequest) returns (model.BlocksData) {}
   }
  

  • Peer Discovery

    Peer Discovery is process to maintaining peer listed by a node. The purpose of this functionality is to populate his Peers list from the peers list that other node has. In the beginning, all nodes do not know the other participant in the network, it will only have a set of WellKnownPeers that acts as a seed for the peers. A new node first of all will try to contact the nodes in the WellKnownPeers list. Once they are connected, the new node will request a set of peers that the WellKnownPeers has connected to. Eventually, the new node will have collective peers that he has collected from other nodes.

    The peer discovery implements Peer Cycling mechanism in the core to virtually make a complete mesh connection between all the nodes in the network. In ideal world where we have infinite amount of space and infinite computing power, there is no problem in storing all the node address of every node in the network and process them whne necesssary. But unfortunately we can not do that in our beautiful world. Each node will have a configuration stating the limit of the number of nodes a node can connect, so the user can adjust this number based on the machine capability. With this limit in mind, to "virtually" connect to each nodes in the network, if the amount of nodes in the network is more than the limit a node has, a node has to cycle through its peers with the incoming communication from the node that has not been in the list.

  • Blacklisting

    Blacklisting is a mechanism to set aside a peer from being contacted by the node for a definite amount of time. In the code the p2p service explicitly provides a function to blacklist a peer that any function in the code can use when necessary. After the blacklist period has ended, a peer will be tried to be reconnected again.

  • Block Broadcast

    Using Observer pattern for communication between p2p service and core service when received or send block to a network.

    P2PCommunication service that used to send & receive block:
    rpc SendBlock (model.Block) returns (model.Empty) {}

    • Send Block

      Send block is process sending block to another node in network. Node to be received a block is in listed peers that already resolved from Peer Discovery process.

      Send block will happen in two cases:

      1. when core service successfully created new block or
      2. when core service received new block from another node and accepted as next block.

    • Received Block

      Received Block will happen when p2p service received block from another node and directly send to block listener in core service.

      Block Validation Step:

      1. Checking signature block.
      2. Checking perevious block hash and comparing with last block that already have.

      If all validation step pass, block will accept as next block

  • Transaction Broadcast

    Using Observer pattern for communication between p2p service and core service when received or send transacton to a network.

    P2PCommunication service that used to send & receive transaction:
    rpc SendTransaction (model.SendTransactionRequest) returns (model.Empty) {}

    • Send Transacton

      Send transaction is a process sending new transaction from mempool to another node in network. Node to be received a transaction is in listed peers that already resolved from Peer Discovery process.

      Send transaction will happen in two cases:

      1. when core service received new transaction from client and successfully added to mempool transaction.
      2. when core service received new transaction from another node and successfully added to mempool transaction.

    • Received Transacton

      Received transaction is a process when p2p service received transaction from another node and directly send to transaction listener in core service.

      Validation step in transaction listener :

      1. Cheking Account Balance and Account Address.
      2. Go into process Apply Unconfirmed transaction.
      3. Adding to mempool transaction.

P2P strategy in Proof Of Participation

As the Proof of participation measures, well... the participation of the nodes to the blockchain network, Peer-to-peer process is part of important piece of Proof of Participation consensus algorithm in ZooBC. The reason is as the following:

• Without this mechanism, each node can limit themselves to connect to his preferred nodes. This will create a cluster of nodes that will raise their own participation, thus will hurt the measurement of participation of other nodes.

• This algorithm can effectively be a filter for receipt validation upon submission of a block. A receipts in a block will be valid if only the receipts attached to a block matches the allowed receipts coming from a set of peers a node has to connect at a given point of time.

These are some subprocesses of this mechanism:

1. Srambling Node Registry

This process will scramble pseudo-randomly the node registry (separated from the original node registry). This scrambled list will be basis of which peers are priority for a node to connect, and which peers are priority for a node to receive connection at a given point of time. The mechanism is to be performed periodically (e.g. every 60 blocks). The ouput of this process used as based for build node scramble list.

2. Define Peers Priority

This process is to define peers priority of node. First build a list of node scramble (sorted node registry) based on scrambled node registry. After that, define priority peers of each node scramble.

3. Trying to Connect Priority Peers

This process will handle smooth transition of peers that a node connects from the priority peers list, so that no need of dropping all of the node connection all at once that may affect the blockchain processes. This process is performed periodically (e.g. every 1 minute). It compares the node's peers list to his priority peers list. if he has not connect to his priority peers list at a given time, this process will try to connect to them gradually, that will result the node to be connected to all of his priority list (if possible) not long after the a new priority peers list has changed.

4. Limitation to Response of Inbound Connection

From the Peers Priority table, we know which peers are out priority to us to connect to, and which peers have us as their priority peers. By using this fact, we can limit the processing of inbound connection to prioritize the priority peers. This process will check the peer who try to get response of a node and will response or ignore based on check output. There is some case in this process based on maximum peers that node have :

Case 1 :

If the node's peers list is not full, they will accept all inbound connection

Case 2 :

If the node's peers list is already full, node will check whether the inbound connection comes from priority peers or not. If that's found to be true, the node will hand out the connection from the "unprioritized peer" to the prioritized one.