Correct me if I am wrong, or confirm, is consensus synchronizing history between peers?
Each peer stores all transactions history?
Each peer is running on separated machines or all peers are running on same machine(in docker for example) ?
Simply the consensus or (total-order broadcast, atomic broadcast) done between peers are on same channel.
Ordering service provides a shared communication channel to clients and peers, offering a broadcast service for messages containing transactions. Clients connect to the channel and may broadcast messages on the channel which are then delivered to all peers.
The channel supports atomic delivery of all messages, that is, message communication with total-order delivery and (implementation specific) reliability. In other words, the channel outputs the same messages to all connected peers and outputs them to all peers in the same logical order. This atomic communication guarantee is also called total-order broadcast, atomic broadcast, or consensus in the context of distributed systems. The communicated messages are the candidate transactions for inclusion in the blockchain state.
Consensus is the process of multiple peers determining if their records of transactions match. With Hyperledger Fabric version 0.6, all of the blocks on the ledger will match across peers if the peers are in consensus. In this version, each validating peer does store all transactions.
Hyperledger Fabric version 1.0 which is under development should make it possible for a subset of participants in a blockchain network to process certain transactions. Information on the future consensus architecture has more details.
The peers usually run in multiple Docker containers that are owned by one entity when using Hyperledger Fabric version 0.6. With upcoming Hyperledger Fabric version 1.0 it should be possible for one entity to start a blockchain network and then invite other parties (such as other companies) to join. In this case, peers would be distributed across multiple entities.
Related
This is a scalability question for Hyperledger Fabric.
Understand that Hyperledger Fabric leverages couch DB to maintain current state.
Questions:
Is there HA (A/A and/or A/P) configuration for the state DB? How to avoid SPOF?
The chain is a transaction log. How big can this transaction log get? 100GB? without affecting speed of append
1) Fabric can utilize embedded LevelDB or external CouchDB to maintain state. In either case, think of the state database as part of the peer - there is a 1:1 relationship between peer and its state database. HA (A/A) in Fabric, and in blockchain in general, is provided at the node (peer) level. Transactions can be endorsed by any peer(s) and are then ordered and delivered to all peers in the network. There is natural HA across the network, plus most organizations would typically host multiple peers for 'local' HA as well. If a peer goes down you route traffic to your other peers. If a peer or state database becomes corrupt you can rebuild it and it will state transfer blocks from other peers upon joining the channel.
2) The chain is an append-only transaction log on local disk or direct attached storage. It is not a single file but appends to a new file once the prior file reaches a threshold size (64MB by default). Therefore the maximum size of the transaction log is bound only by disk space.
What is peer and node in hyper ledger and also what peer node start will do?
what is the meaning of peer and node and how it can use in hyperledger
unless you have a business requirement to pursue the v0.6 architecture, you should definitely pivot to v1.0 and the current stack.
To answer your question, there are two important entities to consider in a Fabric network (there are many components in the network, but we'll stick with two for now). You have peers and orderers. We tend to use the term peer and peer node interchangeably; they are the same thing. You may also come across orderer and orderer node; again they are the same thing.
All peer nodes in Fabric v1.0 architecture are validating and committing peers (i.e. they maintain a ledger and run validation checks against blocks of transactions before appending to their ledger and updating world state). Ordering nodes do what you expect they might - play a central role in the ordering of transactions. We don't need to delve into the specific role of orderers, but as a quick synopsis: responsible for accepting broadcasts of incoming transactions and responsible for delivering blocks of transactions to peers on a channel; with a kafka implementation, the ordering node(s) will actually relay the txs to the appropriate partition in the kafka cluster. Ok enough on that.
Peer node start is simply the command to launch a peer container. If you inspect a docker-compose file, you'll notice there is a command variable where peer node start is passed.
In Bitcoin blockchain a node/peer will order transactions, create a block, does the PoW and "announces" this block to the other miners.
Once the other miners agree (by hashing the block+nounce+etc...) that the block is valid it is part of the blockchain.
But in Hyperledger (as far as I understood) the VPs don't do mining (and hence don't spread the mined block). So how does the individual VPs order them so that all VPs have the same ordered transactions of blocks?
For the Fabric implementation the goal is to have (link):
Consensus is a method for validating the order of network requests, or
transactions (deploy and invoke), on a blockchain network. The correct
ordering of transactions is critical, because many types of network
transactions have a dependency on one or more prior transactions
(account debits often have a dependency on prior credits, for
example). On a blockchain network, there is no single authority that
determines the transaction order; instead, each blockchain node (or
peer) has an equal say in establishing the order, by implementing the
network consensus protocol. Consensus, therefore, ensures that a
quorum of nodes agree on the order in which transactions are appended
to the shared ledger. By resolving any discrepancies in the proposed
transaction order, consensus guarantees that all network nodes are
operating on an identical blockchain. In other words, consensus
guarantees the integrity and consistency of blockchain network
transactions.
Nevertheless in current version there is a leader (one of validation peers) who is responsible for ordering transactions before they are executed by other peers.
In next Fabric’s version this behavior can be changed (Next Consensus Architecture Proposal):
…
A peer communicates with the consensus service and maintain the
blockchain state and the ledger. Such peers receive ordered state
updates from the consensus service and apply them to the locally held
state
…
Peers are clients of the consensus service, to which the consensus
service provides a shared communication channel offering a broadcast
service for messages containing transactions. Peers connect to the
channel and may send and receive messages on the channel. The channel
supports atomic delivery of all messages, that is, message
communication with total-order delivery and (implementation specific)
reliability. In other words, the channel outputs the same messages to
all connected peers and outputs them to all peers in the same logical
order. This atomic communication guarantee is also called total-order
broadcast, atomic broadcast, or consensus in the context of
distributed systems. The communicated messages are the candidate
transactions for inclusion in the blockchain state.
What is a client in a network of Hyperledger fabric peer?
What is the role of a client?
What can qualify as a client in the Hyperledger fabric blockchain network?
have a look at this (and specifically, look into the Network Entities / Systems part):
https://github.com/hyperledger/fabric/blob/master/docs/glossary.md
I'm still rather new to this, but my understanding is that you have a) peers in a P2P network that can be either validator or non-validator - the latter existing mostly for performance purposes; and b) you have clients, who talk to peers in a client-server manner to issue queries and request transactions from the P2P network.
What can qualify as a client: basically anything that can talk to peers in this manner. (I think there are even some SDKs, but I'm concentrating on other aspects of Hyperledger, so I don't know yet.) Have a look at the IBM Marbles demo:
https://github.com/IBM-Blockchain/marbles
A client application talks to a peer over either REST or GRPC interface and submits transactions and queries to the peer to chaincodes.
A client is an end user of the application. The client invokes the smart contract by placing a request on the channel. Each smart contract has a set of endorsing pairs required. The request is picked by the required endorsing peers and executed. The resulting read-write sets are sent back to the client.
what is Client in Hyperledger :
The Hyperledger Fabric Client SDK makes it easy to use APIs
to interact with a Hyperledger Fabric blockchain.
Features:
create a new channel
send channel information to a peer to join
install chaincode on a peer
instantiate chaincode in a channel, which involves two steps: propose and transact
submitting a transaction, which also involves two steps: propose and transact
query a chaincode for the latest application state
various query capabilities:
logging utility with a built-in logger (winston)
I'm going to implement a distributed message bus over ZeroMQ and I'm trying to make it as efficient as possible. My requirements are:
multiple processes are connected to a bus, some of them are on the same machine, some not.
processes can subscribe to some topics
unfortunately, no multicast (it is not supported in the production environment - Amazon)
I need multilanguage soultion (at least for C++, Haskell and Python)
Approaches I'm considering are:
1. Directory Service + Mesh topology
there is a single Directory Service which has a list of all connected processes and their addresses.
each process connects to DS on start and asks for addresses of others
each process has a Pub and Sub sockets connected to all other processes (mesh topology)
2. Broker
all processes are connected to a broker which distributes messages using Pub socket.
Are there any other/better architectures to use with ZeroMQ to create such message bus?
I suggest you to have a look to nanomsg, which has a built-in BUS topology and some
other interesting ones like SURVEY. It is a library by Martin Sustrik the original zmq
author.
You can find some discussion about BUS on Martin Sustrik blog: http://250bpm.com/blog:17