What is an Artifact in Hyperledger? - hyperledger-fabric

I see the word everywhere in building a Hyperledger network, but I don't exactly know what it is and the Hyperledger docs don't return a definition when I query them.
Maybe it's a dumb question because the docs don't define it and assume you should know, but I don't and can't find a precise answer to it.

Artifacts in Hyperledger are channel configuration files which are required for the Hyperledger Fabric network. They are generated at the time of network creation.
These include:
Genesis.block: First block of a chain, that initializes a block chain
Channel.tx: Channel configuration transaction
Org1MSPanchors.tx: Anchor Peer update (Defining a peer from Org1 as an anchor peer)
configtxgen command is used to create the above channel config artifacts.

Related

Is it possible to make orderer node validate the block and the peer node only accepts block created by orderer node?

I'm trying to apply Proof of Authority concept on Hyperledger Fabric. The idea is to make the orderer node validate the transactions signed by peer node, pack it into block and then distribute it to other orderer node(i.e. orderer2, orderer3, etc)for validation of the block and once the block has been finalized, distribute it to the rest of the network.
What I plan to do is I want to make the validate step which is done by peer0.org1 and peer0.org2 as above picture to be done by orderer.example, orderer2.example and orderer3.example. And peer0.org1 and peer0.org2 only storeBlock and commit the block.
My questions are as below.
Can my idea be realized on Hyperledger Fabric? (I tried to find the code for this [propose -> writeBlock -> storeBlock -> Validate -> commit] but I couldn't find it ...)
I'm wondering if this thing can be realized by just modifying the core.yaml or configtx.yaml or it's more than just modifying these two files? If it's more than modifying these files, which files should I modify?
Any reference regarding this will help me greatly.

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.

Does committing peer sign the new block using private key to produce new block in Hyperledger Fabric?

I tried to find about how committing peer works in hyperledger fabric technically in producing new block but I couldn't seem to find resources that explain to me in a very detail manner(such as sign using private key, how transaction is validated technically, etc). My question is after committing peer validate the transaction which they got from ordering service node, who will create the new block exactly? If it's the committing peer, committing peer is not one node but usually it has multiple committing peer node(which represents number of company participating in the network), so how do the system decide which committing peer will produce the new block?
Any reference link about this will be highly appreciated.
Please refer to the Transaction Flow in the documentation. Furthermore, Please check out the Key Concept Section too (Both Ledger and Ordering Service for you to understand the flow and also what is inside a block).
Committing peers do not create new blocks, they execute, validate and commit the block created by orderer to their ledger. The signing is done by Endorsing Peers using private key with ECDSA-SHA256 signing. Then of course, verification uses ECDSA-SHA256 too.
Validation is basically executing the read write set and check if the output is deterministic (and thus the result should be same with all other nodes).
I am over simplifying here tho.

What install and instantiation chaincode really mean in hyperledger fabric? and what are the differences between them?

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.

Hyperledger Fabric. Is it possible to deploy more than one chaincode to the same channel?

Is it possible to deploy two different chaincodes to the same channel in Hyperledger fabric
Yes. And its possible to deploy the same chaincode to 2 or more channels. You can even deploy the same chaincode to the same channel if you use a different name.
when inspect into the block structure, I find a 'Chaincode Name' field in block, and I suppose that:
One channel has one ledger(offcial doc)
One channel can have two or more chaincodes
The block generated by different chaincode(we can simplely think so) will be stored in the same one ledger
The field 'Chaincode Name' in block will distinguish it's generated from which chaincode
jworthington answer is correct but i want to clear some things from comments.
One channel means one ledger. (official doc)
Every chaincode have separated "view" on ledger (I visualize it as every key in db has chaincode name prefix and chaincode can access
only specific keys with same prefix as its name).
You can invoke read/write of second chaincode from first one and that will make only one blockchain transaction (at condition that chaincodes are on same channel/ledger, if they are not, write operation will be ignored)
I do not know how much is changed over the years, but I share information based on version 2.x.
Ledger is associated with the channel, not with the Chaincode. Even a peer can have a ledger without any Chaincode installed. https://hyperledger-fabric.readthedocs.io/en/latest/peers/peers.html#multiple-ledgers
P1 is Peer
L1 & L2 are ledgers
S1, S2, and S3 are Chaincodes
There isn’t a fixed relationship between the number of ledgers a peer has and the number of Chaincodes that can access that ledger. A peer might have many Chaincodes and many ledgers available to it.
https://hyperledger-fabric.readthedocs.io/en/latest/peers/peers.html#multiple-chaincodes
P1 is Peer
L1 & L2 are ledgers
S1, S2, and S3 are Chaincodes
Yes, we can deploy multiple chaincodes to the same channel with different chaincode ID.
Each chaincode will have separate ledger in channel, we can consider this as namespace.
One chaincode can not read/update other channel ledger directly.
However, fabric shim package provides "InvokeChaincode" functionality to call another chaincode to read/update it's ledger.
stub.InvokeChaincode("anotherCCName", chainCodeArgs, "channelName")

Resources