Search code examples
blockchainhyperledgerconsensus

Who is a validating peer?

I don't see a definition of the terms Validating Peer and Non-Validating Peer in the Glossary. It is important to have this definition as a good deal of literature seems to depend on these types of peers.

Coming to my main question.

Looking at the Blockchain as a data-store, it is clear that, this datastore will expose functions to change and read the state of its store. Therefore, is the validating peer an entity that will verify the fact that, X was before state, T was the transaction applied and X' the resulting state?

Or, will the validating peer also verify the business logic that T represents and the access level that should exist to invoke T?

A centralized analogy is an RDBMS that uses a SQL engine to expose the state of store. This store can be updated via a combination of business logic (e.g. a rules engine) and SQL commands (e.g. INSERT, SELECT, etc.) My question is, is a validator interested in ensuring the SQL command worked successfully? Or, does it extend the validation to the rules engine also?

Solution

  • The term validating peer was used in the v0.6 of Hyperledger Fabric. They were the orderers, and the No-validating peers, the Peers.

    In the v1.0 there are:

    • Endorser Peers: they receive a transaction. Then, they execute the transaction against the Smart Contrat and they sign the result. They send the transaction signed to the peer that has sent it.
    • Committer Peers: the Peers get the Blocks (with the validates transactions) and commit them to its ledger.
    • Orderes: nodes that sort the transactions and generate the blocks.

    Edit (adding the following):

    A peer can be Endorser and Comitter. Also, a Endorser Peer can execute its own transactions.

    The flow (briefly):

    • A peer gets the client request. This peer (the initial Peer) sends to the Endorser Peers the corresponding request.
    • The Endorser Peers execute the request against their Smart Contract. They sign the response and send it to the initial Peer.
    • If the result of all the responses is equal and the signatures are correct, the initial Peer builds the transaction with the signs. It is sent to de orderer.
    • In the Ordering Service the signatures are verified. The Ordering Service creates the blocks cronologically and by channel. They are sent to the Comitter Peers.
    • Each Comitter Peer validates each transaction of the Block. If OK, it append the Block to each local ledger.