Peers constitute a blockchain network and host ledgers and chaincode. We saw in the conceptual view of architecture that each peer has a copy of the chaincode and ledger. Peers offer APIs, which allow applications to interact with them and also to start, stop, configure, delete, and reconfigure the peers. A peer can host a ledger and chaincode, and it is feasible for peers to host only ledgers and not chaincode (application chaincode). Peers usually always have system chaincode. The HLF SDK offers APIs, which allows applications to interact with peers, since it is the peers to which applications connect if they need to query a ledger or invoke a transaction on the ledger. Then, in turn, the peer invokes the chaincode to effect the execution of that transaction.

Along with orderers, peers ensure the synchronicity of ledgers on every peer. We will walk through the transaction flow in subsequent sections, which will highlight peer involvement. Here is a brief synopsis of that:

• The application (the party that wants to execute a transaction) connects to a peer. Where the application and peer are from the same organization, certificates are issued by an organization's CA.
• The peer invokes the chaincode, which results in the generation of a proposal response. The response depends on the transaction request from the application. For instance, if the application requested a query to the ledger, then the proposal response will have a query result or, if the application requested an update to the ledger, then the proposal response will include the proposed ledger updates.
• The application receives a proposal response from the peer:
  • If it was a query (ledger-query-transaction), then the process is completed as the application has received its response
  • If it was a ledger update (ledger-update-transaction), the request then proceeds to the next step
    
• For a ledger update request (ledger-update-transaction), the peer cannot send the response as the update to the ledger first needs to be agreed by all the participating peers. This agreement to change the ledger is termed a consensus.
• As a consensus is required for the ledger-update-transaction, the peer returns a proposed update response to the application, which is actually a snapshot of the change that the peer is proposing. This is similar to a change being performed on the ledger only once a consensus is reached.
• The application receives responses. The application will build a transaction from all the responses and send it to the orderer's node.
• Orderers will collect this transaction and various other transactions from the blockchain network and compile them into a block.
• Orderers will then distribute this block to all the peer (committer) nodes, which also includes the peer to which the application (in this sample) sent the initial request.
• All the peers, including the peer in this context, will validate the transaction.
• Upon successful transaction validation, the peers will update the local copy of the ledger.
• Once the ledger is updated, the peer to which the initial request was sent will generate an event.
• This event will be received by the application, which marks the completion of the update transaction.

We saw in the Architecture – conceptual view section that peers are owned and contributed by various organizations, and this group of peers forms the blockchain network. Applications that are developed by an organization usually connect to the peers of that organization.

From the Architecture: conceptual view diagram, we know that peers are connected to channels. Channels also have channel configuration and contain the global MSP. This global MSP helps to map peers to their organization, as the certificate issued to the peer emanates from the CA of that organization. By way of an example, refer to the MSP diagram in this chapter. Here, peer P1's certificate is issued by the CA (CA O1). The channel configuration (CCon1) determines that the identities (participants such as P1) are issued by the CA (CA O1), which is from organization 1 (O1). This is defined in O1. The MSP is contained in the global MSP of the channel configuration. This helps in associating a peer with an organization.

At a given point in time, a peer can only belong to/be owned by one organization. A peer can reside anywhere; on a local machine, in an enterprise on premise, on the cloud, and suchlike. It is the certificate (identity) of the peer that maps and associates that peer with an organization. This mapping is provided by the MSP. Along with the authentication of the user via the MSP, channel configuration also involves access policies, which determines the privileges assigned to a peer (the peer's identity). Details of this can be found in the MSP section. However, in short, the mapping of an identity to an organization is defined by the MSP, along with the roles assigned to the peer in that particular organization, and also the rights (privileges) assigned to that identity.