In Hyperledger Fabric you can use peer channel update to submit updates to your nextwork. For instance, once you have your block in protobuf format ready, you can submit it like so:
peer channel update -f .someupdate.pb -c somechannel
However, you can also use it to submit a channel transaction, for instance:
peer channel update -f someTransaction.tx -c somechannel
I'm really confused about this. Does peer update channel create a transaction when is submitting the update block? What are the scenarios when you would use a block instead of a transaction?
Same happens with the cyptotxgen tool. You can use it to create a genesis block:
configtxgen -outputBlock ./genesis.block \ -profile SomeProfile \ -channelID somechannel
or you can use to create a transaction:
configtxgen -outputCreateChannelTx ./sometransaction.tx \ -profile SomeProfile \ -channelID somechannel
The official docs about peer channel update says about the -f param:
-f, --file string Configuration transaction file generated by a tool such as configtxgen for submitting to orderer
So it's referring to transactions, not blocks. But apparently you can indeed use to submit a block. Is the command creating a transaction on background?
As far as I can see, peer channel update only accepts a config update transaction. It doesn't care what the file is called (and could end in .pb or .tx for example). The file will be a serialised collection of protobufs and definitely won't be a block, The format of this is described here https://hyperledger-fabric.readthedocs.io/en/latest/configtx.html#configuration-updates but suffice to say that a config update transaction is a set of diffs which the orderer will use to generate a complete channel config from putting that as the only transaction into a block. Peers will receive this block, validate it and make it the new channel configuration block
cryptogen in fabric prior to 2.3 had 2 purposes.
The first purpose is to generate a genesis block which will contain the system channel configuration. When an orderer first starts and the system channel hasn't been created it will read this file and the system channel created, subsequent restart of the orderer will ignore this file as that block is now stored in the appropriate place in the orderer.
The second purpose of configtxgen prior to 2.3 is to generate an application channel creation transaction file which can be used by peer channel create. This is submitted to the orderer which will generate a genesis block for the application channel containing the channel configuration.
In fabric 2.3 the need for the system channel was removed, now cryptogen has a 3rd purpose (as it still needs to support the system channel mechanism for now), to generate an application channel genesis block. This is then given as input to the osnadmin command to send to the first orderer who basically bootstraps the application channel with that genesis block. Then more orderers (via osnadmin) and peers can join that channel (via peer channel join) using the same genesis block.
Related
I have hyper-ledger fabric setup with 2 organisation which works well.I am keeping the separate storage for the blocks state in file system. Now i turn down the all organisation container, all the states inside the container is deleted, but i am keeping states which are stored the my file path. Next, when i use the existing file storage, and turn up the docker, all the peers and ordered load well from the state which i was stop. The problem here is, I am unable to reinitiate the channel transaction and i am unable to join the same channel from the peer. where does the mychannel.block get stored. when i try to join the channel i get error
2019-11-27 03:49:01.631 UTC [channelCmd] InitCmdFactory -> INFO 001 Endorser and orderer connections initialised
Error: genesis block file not found open mychannel.block: no such file or directory
You should know what volumes are you using to persist that file.
You should persist:
/var/hyperledger/production in your orderers and peers.
/opt/couchdb/data in your CouchDB containers.
Wherever you store your MSP, TLS files and other configuration files (genesis block, etc.). Only you know about your configuration.
/var/lib/postgresql/data in your CA's PostgreSQL container.
Whatever other file/folder you want to persist.
Anyway, I don't know if I have understood you, but if you persist all these, you don't need to join a channel again, the peers remain joined after restarting the network.
It's possible in Hyperledger Fabric to specify that all peers in an organization must endorse the transactions?
I'll try to explain better what I am doing. Starting from the examples in the fabric-samples repository, I want to realize a scenario in which I have two separate nodes (on two different VM): on the first one I have my first peer (peer0.org1.example.com), the orderer and the fabric-ca; on the second one I have my second peer (peer1.org1.example.com).
For now, I am been able to do that: I install the chaincode on both peers and instantiate it on the channel, so I can (from both the peers on the two VMs) send transactions. But when I instantiate the chaincode, I can only say that only one of the two peer is needed to endorse the transactions (I am instantiating it with something like: docker exec cli peer chaincode instantiate -o orderer.example.com:7050 -C mychannel -n mychaincode -l java -v 1.0 -c '{"Args":["init"]}' -P "OR('Org1MSP.member')" ).
Can I specify that both peer0.org1.example.com and peer1.org1.example.com must endorse all transactions? In my configuration they both belong to the Org1 organization, I wouldn't want to split them in two ones.
Of course you can. With the syntax OutOf(), you can set how many peers needs to sign.
For example:
OutOf(1, 'Org1.member', 'Org2.member')
OutOf(3, 'Org1.member')
OutOf(2, 'Org1.member', 'Org2.member', 'Org3.member')
You can check more of this sintax here.
While generating orderer genesis block the channel ID supplied to configtxgen is byfn-sys-channel despite the name of the channel being mychannel
Can somebody throw up some light about it's significance. Also this change has been incorporated in 1.4 release, it wasn't there in the earlier releases.
The channelID given while generating the genesis block is referring to the system channel which should contain consortium details, Eg. Org which should be part of the consortium is defined in this channel's MSP.
By default in earlier versions it uses testchainid as the system channel and allowed overriding options using -channelID option. In recent versions it was suggested to make this a necessary field.
In the hyperledger fabric documentation, there are 2 terms used
1. Install the chaincode on peers and
2. Instantiate the chaincode on the channel
What are the major differences between these two?
In the documentation it said that a chaincode can be installed on multiple peers but can be instantiated once. I understood this point as a channel only needs the information about the channel.
I was following the balance-transfer example, so after channel creation, peers need to be joined to that channel.
There are 2 peers which joined the channel ["peer0.org1.example.com", "peer0.org1.example.com"], so when I am instantiating the chaincode it is creating 2 docker images of chaincode
dev-peer0.org1.example.com-chaincode-v0
dev-peer1.org1.example.com-chaincode-v0
What these 2 images really mean?
Isn't initializing the chaincode means for the channel?
Or channel initialize it on all the peers who joined it?
Where actually this initialization is happening?
Thanks!
Thanks to #PaulO'Mahony and #kajuken for the resources and explanation.
Following are the summary of my doubts:
A chaincode runs in a Docker container that is associated with any peer that needs to interact with it.
Chaincode is installed on a peer, then instantiated on a channel.
All members that want to submit transactions or read data by using a chaincode need to install the chaincode on their peer.
Instantiation will input the initial data used by the chaincode, and then start the chaincode containers on peers joined to the channel with the chaincode installed.
Note that only one network member needs to instantiate a chaincode. If a peer with a chaincode installed joins a channel where it has already been instantiated, the chaincode container will start automatically.
a chaincode is installed onto the file system of every peer that joins a channel, the chaincode must then be instantiated on the channel so that peers can interact with the ledger via the chaincode container. The instantiation performs any necessary initialization of the chaincode. This will often involve setting the key value pairs that comprise a chaincode's initial world state.
A peer can the install the chaincode once, and then use the same chaincode container on any channel where it has been instantiated.
References:
install and instantiate the chaincode
instantiate the chaincode
What these 2 images really mean?
Isn't initializing the chaincode means for the channel?
Yes and no. Every peer needs the same version of the chaincode installed on itself since everybody needs to be able to execute and verify incoming queries/invokes.
So there are 2 steps to do.
install the chaincode on every peer on the channel
instantiate the chaincode on the channel
Where actually this initialization is happening?
So the instantiating of chaincode is happening last after every peer has "knowledge" of the chaincode and it can be verified.
I built fabric network using kafka.
I created new "mytestchannel".
When I saw /var/hyperledger/production/ledgersData/chains/chains on peer server,
I found that both "mytestchannel" and "testchainid" directories.
Also, I checked kafka topic, I found both "mytestchannel" and "testchainid".
What is "testchainid"?
This channel contains important data?
I mean that if I delete(break) "testchainid" data in Kafka topic, does it affect my entire fabric network?
TL;DR - You cannot delete testchainid. It is the system channel.
Assuming you followed the normal configtxgen sequence of creating the genesis block first and then doing a create channel transaction, then testchainid is actually the system channel (if you don't specify a channel name using the -channelID flag when using the -outputBlock flag then the system channel name defaults to testchainid).