What is "testchainid" channel? - hyperledger-fabric

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).

Related

Does peer channel update create a transaction?

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.

Hyperledger join one org from one consortium to a channel in another consortium with already existing name. Best ways to do this

Hyperledger Fabric 2.2
Current situation. We have two separate consortiums. Both have, however, channels with the same names. If I add Org from one consortium to the channel of another consortium I get error:
Error: proposal failed (err: bad proposal response 500: cannot create ledger from genesis block: ledger [data-channel] already exists with state [ACTIVE])
What's the best way to solve this situation? Do we have to rename a channel (is it possible?) in one of the consortiums? If I make a name-update config transaction, will the Couch DB databases follow this update?
A Fabric node cannot participate in two channels with the same name. You can simply have different nodes that each participates in one of the channels.

Dynamic Channel artifacts(channel.tx) in Hyperledger Fabric

Is there any other way to generate a generic channel artifacts(channel.tx) for Hyperledger-Fabric channel creation, So that a channel name alone can be changed at runtime instead of issuing the below command with different channel name for every new channel.
./bin/configtxgen -profile OneOrgChannel -outputCreateChannelTx
./config/channel5.txt
It's not exactly the answer you are looking for but we do this dynamically inside a java application with a ProcessBuilder. That way we can create new channels on demand - it's embedded ultimately in a REST service that allows you (one) to pass up a configtx file as required.
So long as the crypto is already generated (we do that in another service) you can do this on demand.
So aatk's answer applies the sidecar pattern to solve the issue, by running the configtxgen on the side of the actual application. However you can do this from within the application itself.
A channel configuration transaction that is generated with configtxgen is a file containing a protobuf of the common.Envelope message. There is support for protobuf in Java, and the Envelope message has been compiled to Java thanks to the Fabric Java SDK. We can piggyback on the SDK to create the objects and get the ByteArray to create the ChannelConfiguration object that will be used to create a channel. This method doesn't require a configtx.yaml file at all, so you will need to keep track of organizations and their MSP IDs in the app.

Mentioning orderer name while using kafka configuration

I am using orderer in kafka mode. Now while invoking chaincode, I need to supply orderer name. But then whats the use of kafka to select orderer if I need to supply the orderer name by my own.
I'll note that the client can initialize a channel in memory that has record of multiple orderers, and the SDK should provide the option of sending your transaction via a random orderer. While one organization's client may communicate with one orderer, another organization might prefer to have its client set up to use a different orderer (or group of orderers, and perhaps these are running on the organizations own servers).
Where kafka comes in is that it's a way to provide crash-fault tolerance to channels with high throughput and a set up of multiple orderers by helping keep track of transactions and thus allowing proper sequencing of blocks. Specifically, when the client sends the transaction to an orderer, the orderer then relays to a partition that the kafka cluster maintains, and then orderers then consume/read from this partition to package transactions into blocks (orderers are both producers and consumers in this set up). kafka keeps all the orderers in sync by maintaining a stream of transactions that's used by all of them.
The full technical solution is outlined in https://docs.google.com/document/d/19JihmW-8blTzN99lAubOfseLUZqdrB6sBR0HsRgCAnY/edit, the below image is from page 11.
From the readthedocs page (https://hyperledger-fabric.readthedocs.io/en/release-1.2/kafka.html):
Each channel maps to a separate single-partition topic in Kafka. When an OSN receives transactions via the Broadcast RPC, it checks to make sure that the broadcasting client has permissions to write on the channel, then relays (i.e. produces) those transactions to the appropriate partition in Kafka. This partition is also consumed by the OSN which groups the received transactions into blocks locally, persists them in its local ledger, and serves them to receiving clients via the Deliver RPC. For low-level details, refer to the document that describes how we came to this design — Figure 8 is a schematic representation of the process described above.

Does Orderer have Block(Ledger) data?

I built hyperledger fabric network using Kafka-based Ordering Service.
I thought that Orderer doesn't have Block data.
But, when I checked /var/hyperledger/production/orderer/chains/mychannel in Orderer server, I found blockfile_000000 file.
I checked this file using "less" command.
Then, I found key-value data which I registered by invoking chaincode.
What is this file?
This means that Orderer also maintain Block data(i.e. Ledger)?
The orderer has the blockchain of all channels it is part of.
However, it doesn't have the world state and it doesn't inspect the content of the transactions.
It just writes the blocks into the disk, to serve peers that pull the blocks from it.

Resources