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)
Related
I am new to cryptocurrency development.Today I learned that the ETH transaction requires an RPC server. I found a list of RPC servers like Binance. But is there any official RPC server? Or do you need to create it yourself? What is the difference? Where to get the official exchange rate eth to USD? Many thanks.
There is no official centralised server, because peer-to-peer cryptocurrencies are about decentralisation. Creating single points of failure is bad.
Ethereum software-as-a-service node alternatives can found on:
https://ethereumnodes.com
I also recommend you to try to host the node yourself.
I'm reading the Hyperledger Fabric Architecture Explained document.
I understand that when a client wants to invoke a transaction, it must get that transaction endorsed, and then send it to the ordering service.
I'm confused about if the client must connect directly to the endorsers and orderers, or whether it can just connect to an available peer and have the proposal be forwarded to the necessary nodes.
For the ordering service, this is explained clearly:
If the client does not have capability of invoking ordering service directly, it may proxy its broadcast through some peer of its choice.
However for the endorsers, it's not so clear:
To invoke a transaction, the client sends a PROPOSE message to a set of endorsing peers of its choice (possibly not at the same time - see Sections 2.1.2. and 2.3.). The set of endorsing peers for a given chaincodeID is made available to client via peer, which in turn knows the set of endorsing peers from endorsement policy
I understand a client must send a PROPOSE message to the endorsing peers. But what does it mean by "The set of endorsing peers for a given chaincodeID is made available to client via peer"? Does it mean "via any peer", thus implying the client does not have to connect directly to the endorsers? Or must the client connect directly to the endorser peers?
Looks like we need to update the architecture doc you reference to match the current implementation in Hyperledger Fabric v1.0.x and the upcoming v1.1.0.
The client MUST send transactions directly to the orderer and must directly communicate with all endorsing peers. It cannot "proxy" any of these calls through a peer in the current implementation.
Typically the client will get the information about which peers/orgs are required to endorse a specific chaincode through an out of band mechanism.
I'm trying to get my head around blockchain and I'm finding it difficult to get a straight forward answer to this. Say I create a web application that interacts with a blockchain. A user opens my web app, logs in and uses that web application and so a transaction occurs and a new block is added to the chain. How is that blockchain stored on their PC, since the point of blockchain is that it is stored on every participating node? In what format is it stored?
Your web application will interact with the blockchain as a client (likely using one of the Hyperledger Fabric SDKs). The "blocks" will be stored on one or more peer nodes (depending on how many peers are connected to a given channel) not on your client nor on the server hosting your web application.
I'd recommend looking at this to understand the overall transaction flow and this to understand the ledger.
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.
I have got this example https://github.com/IBM-Blockchain/marbles run locally. I saw that the example downloaded the golang chaincode from https://github.com/ibm-blockchain/marbles-chaincode. And the chaincode was stored on harddisk at /marbles/node_modules/ibm-blockchain-js/temp/unzip.
Could you please explain how the golang chaincode was executed inside the nodejs code?
I haven't looked at the Marbles app in detail, but generally speaking, the nodejs code is just a client to the validator network, and the validator is processing the golang based chaincode in a way that is completely decoupled from the nodejs based client. In this process, the validator downloads/acquires the chaincode and compiles it locally within an isolating container. You could look at the process like [golang::chaincode]->[nodejs::client]->(network)->[golang::validator]->[golang::container]. So the first and last parts are golang/chaincode related, the stuff that happens in the middle is more or less a transport. I.e. the fact that the client is nodejs and the validator is golang matter little here.
The Golang code that implements the Marbles chaincode (aka smart contract) does not get executed inside the Node.js app. The chaincode is what the application interacts with to modify state variables stored in the blockchain. State in this case is: what marbles exist, who their owner is, what color it is, etc. But the chaincode itself (the Golang code) is packaged as a docker container, deployed to the blockchain, and is up and running waiting for transactions. The Node.js code constructs and sends these transactions to the docker container, receives results of the chaincode execution, and updates the application view of the current state.
Just FYI, the Marbles app was implemented to demonstrate how to implement an application running on top of the Hyperledger Fabric project. Hyperledger currently only fully supports Golang as it's smart contract language, but more languages are coming soon.
As described here,
Interacting with the cc is done with a HTTP REST call to a peer on the
network. The ibc-js SDK will abstract the details of the REST calls
away. This allows us to use dot notation to call our GoLang functions
(such as chaincode.invoke.init_marble(args)).
The user will interact with our Node.js application in their browser.
This client side JS code will open a websocket to the backend Node.js
application. The client JS will send messages to the backend when the
user interacts with the site.
The backend Node.js will send HTTP
requests (via the SDK) to a blockchain peer to carry out the user's
actions. The peer will communicate to its chaincode container at its
leisure. Note that the previous HTTP request was really a 'submission'
of chaincode to be run, it will actually run at a later date (usually
milliseconds).
The cc container will carry out the desired operation
and record it to the ledger. ie create/transfer a marble.