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.
Related
I'm a newbie, currently interested in data security & integrity.
I'm quite new to blockchain and distributed system theories, and suffering from some unclear doubts/questions on the fault-tolerant consensus.
May I ask for your kind advice on my dull thoughts regarding on the blockchain's true objective?
It would be a great help for me to step forward on understading better concept of consensus.
Here's the summary of what I understand (please correct me if I'm wrong)
In a synchronous network model, it is assumed that one can guarantee the message being delivered within a certain amount of time.
In an asynchronous network model, there is no certain guarantee on the message delivery.
In a design perspective, it is easier & more efficient to design a system based on the synchronous model.
Even the quorum size requirement can be reduced - synchronous model needs only f+1 votes while asynchronous model needs 2f+1 votes on the consensus.
(This is because that the synchronous model can eliminate the possiblity of message dropout (up to f), while the async model needs to consider both message dropout & possibly malicious messages.)
But in a distributed system based on multiple nodes, it is normally impossible to guarantee the message delivery since there is no central manager who can monitor all nodes whether each receives the message or not.
That is why most of the blockchain-oriented distributed ledgers (non-currency) are based on the asynchronous consensus schemes such as PBFT (Castro, Liskov 99).
In a private blockchain scenario, I believe that the main & final purpose of the consensus is to let all nodes hold a chain of blocks, where each block has a certain amount of agreements (i.e. more than f signatures).
So, based on the facts above, I got curious whether the fault-tolerance model only stands for the standard "client-server" environment.
What happens if we give up the client-server model, and let the client supersede peers' broadcast communications? (For a scenario where the client has enough computation power but is just short on storage, so it wants to manage multiple (but few, e.g. 3) replicas to store data via transactions)
To be more specific with a simple example (an authenticated environment with PKI):
Each replica only performs a "block creation (+signing)" and "block finalization (verifying signatures)" logic, and there may exist some malicious replicas (up to f) which try to spread different outputs, which is not originated from the client's transaction.
Let the client (a "data owner/manager" would be a more suitable term now...) visit all replicas, and it handles each replica as below:
Enforce that all replicas work as a synchronized state machine; assure all 3 replicas are synced up (check the latest block of each, and supplement the lagged ones)
Sets a callback (with a timeout) for each replica to guarantee the message delivery
Send a transaction to all replicas, and receive the block (with a signature) generated from the corresponding transaction (assume that the block contains only one transaction)
If more than f signatures (from replicas) for the same block message are collected, deliver the collected signatures to all replicas and order them to finalize the block.
If we do as above, instead of replicas making consensus on their own (i.e. no view-changes), can we still say that the system suffices a BFT model?
It seems that byzantine replicas cannot breach safety, since the client (and honest replicas) will only order/accept block finalization when the block comes with more than f signatures.
The concern is the liveness - can we say that the liveness still holds, since the system can continue (not a client-server model anymore, but the "system" goes on) because the client will ignore the faulty replica response and order honest replicas to finalize?
This curiosity is just stuck in my head, and it's blocking me from clearly understanding why the private blockchain systems need asynchronous consensus process among peers themselves.
(since they already trust the client transactions, and participants are designated by PKI & signatures)
Could anyone be kind and inform that whether my dominant-client example can still suffice the BFT, or something would go wrong?
Thank you so much!
MPC involves running calculations on numbers, perhaps from different parties, and sharing the result without anyone seeing the underlying data. Even the person operating the computer cannot access the information
How is this possible on blockchains like ethereum/corda/hyperledger etc?
Corda is a permissioned blockchain platform, which focuses on Peer to Peer communication. It is direct, private, and secured.
If there is any multiparty computation happening with in a Corda network, it will be happened only among participating parties.
It will happen strictly according to the Corda contract code, which
is developed by the pre-agreed business rules.
Every transaction will collect digital signatures from the participating parties, and distributed the transaction to these participating parties when the transaction is done.
Please see more information at: https://docs.corda.net/docs/corda-os/4.4/key-concepts-ecosystem.html
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.
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.