I have developed two participants in two different hyperledger composer networks(A and B). A and B have a common asset. Since the asset is common, both networks must be able to update the shared asset. I have developed the shared asset in A, and I want to update it by B. B can read the asset by following the hyperledger tutorial[1], and also it can invoke low level commands of hyperledger fabric by its APIs[2] but I do not know how B can update the shared asset.
if the business networks are on the same channel in the same Fabric network (not different Fabric networks), then you can use invokeChaincode (as referred to in that 1st tutorial) to do an update call that would be atomic (ie all update(s) occur, or none at all, in the transaction function). You need to read up more on invokeChaincode usage in that regard.
Beyond that, it becomes a complex question, such as business networks on different Fabric channels or, in different Fabric networks - suffice to say, it would not be atomic in that case.
Related
I have a problem with understanding why Hyperledger Fabric (HLF) uses blockchain structure.
I know that in Bitcoin blockchain structure ensures big security due to PoW algorithm and longest chain rule, but what are advantages of using a blockchain structure in HLF?
It seems to me that in Hyperledger Fabric, instead of the blockchain structure, there could be one transaction history log and network could work in the same way - I bet I'm wrong, but I haven't been able to find an explanation yet.
I would be grateful for the clarification of this issue.
I think a lot of questions you have in your mind comes from the overlapped definitions of DLT and blockchain.
DLT:
A DLT is simply a decentralized database that is managed by various participants. There is no central authority that acts as an arbitrator or monitor. As a distributed log of records, there is greater transparency – making fraud and manipulation more difficult – and it is more complicated to hack the system.
All of this could well be familiar because it’s written about the features of blockchain as well.
Blockchain:
Blockchain is nothing else but a DLT with a specific set of features. It is also a shared database – a log of records – but in this case shared by means of blocks that, as the name indicates, form a chain. The blocks are closed by a type of cryptographic signature called a ‘hash’; the next block begins with that same ‘hash’, a kind of wax seal. That is how it is verified that the encrypted information has not been manipulated and that it can’t be manipulated.
DLT platforms that are not blockchain provide immutability too, but it's just the way Hyperledger Fabric provides this characteristic which makes it a blockchain framework.
Every blockchain framework, be it the Ethereum, Bitcoin, etc all store the transaction information in blocks, where each block is linked to its predecessor by a hash and provides immutability.
Corda is very much similar to Hyperledger Fabric, but it is said to be both a blockchain and not a blockchain. Architecturally, it's very much similar to Hyperleder Fabric, but with only a key difference which makes Hyperledger Fabric a blockchain framework, and Corda a DLT.
I'll try to answer your question by emphasizing on the point that why Corda is not a blockchain.
Why is Corda a blockchain, and not a blockchain?
A Transaction in Corda is cryptographically linked (chained) to the transactions it depends on. Just like Bitcoin, but the range of concepts that can be expressed is far wider.
Transactions in Corda are processed by having each participant in the transaction execute the same code deterministically to verify the proposed updates to the ledger. Just like Ethereum, but the languages you can use are high-level and productive, like Java, rather than obscure ones like Solidity.
Transactions in Corda are shared only with those who have a need to know. Just like channels in Fabric but designed in from day one and fully integrated into the programming model.
Transactions in Corda are confirmed through a process of consensus forming using one of a range of algorithms, including Byzantine Fault Tolerant algorithms. Just like any other blockchain, but with the unique features that a Corda network can support multiple different consensus pools using different algorithms.
So, for all intents and purposes, Corda is a blockchain. And yet… there’s also an utterly critical difference.
Unlike the platforms mentioned above, Corda does not periodically batch up transactions needing confirmation — into a block — and confirm them in one go. Instead, Corda confirms each transaction in real-time. No need to wait for a bunch of other transactions to come along. No need to wait for a “block interval”. Each transaction is confirmed as we go.
Now coming onto your question why Hyperledger Fabric (HLF) uses blockchain structure? The answer is simply because they chose to.
References:
https://www.bbva.com/en/difference-dlt-blockchain/
https://cointelegraph.com/news/what-is-the-difference-between-blockchain-and-dlt
https://www.corda.net/blog/corda-top-ten-facts-7-both-a-blockchain-and-not-a-blockchain/
To keep the record immutable, Hyperledger Fabric uses blockchain structure. So by using Hyperledger Fabric, you can get an immutable record of all the transactions which is tough to temper with fraudulent activities.
Suppose you buy an valuable asset and you are the current owner of that asset. Now it is very hard for others to temper that records or change your ownership without your permission as Hyperledger Fabric uses blockchain structure to keep the record immutable.
Lets say there are 100 banks on the street, they trade each other but they also don't want to share the data with the other banks who is not the part of the transaction. so basically in that case they will have to create a dedicated channel for each possible combination, so assuming 100 banks each trading with each other 100 x 9 = 900. If i put them in same channel they will get to see the data for the transaction they are not part of, so only option i have left is to keep them on a separate channel but is there any scalability issue with having too many participants in the network. how is really going to scale in Hyperledger Fabric or How can we manage this type of use case in Hyperledger Fabric ?
Seems like you duplicate the question
I have answered in your previous question
How to prevent third party to seeing the data on same channel in Hyperledger Fabric?
There is one very important feature provided by the Hyper-ledger fabric for scenarios like these. Its called Private Data. A set of Organizations in a consortium can hide the data from other organizations using this feature, and avoid creating a new channel altogether.
Please see below link for detailed explanation. It has everything , including an use case which will help in understanding the practical usage of private data.
Private Data in Hyperledger fabric
I am working on how to develop a blockchain app using Hyperledger Composer. Since I have just begun with Hyperledger Fabric so I am pretty confused over Some Points-:
1) What are assets, participants and transactions.
2) What is the meaning of the symbol '-->' used for some variable.
3) Why do we need .bna file.
I am new to this concept so please bear with me as I have tried with documentation but it confuses me even more.
An asset is anything of value, whether physical or virtual.
A participant is a person or organization participating (taking part) in the blockchain network.
A transaction is an operation submitted by a participant to modify the blockchain. It could be transferring or modifying the amount of an asset. It could be recording an event. In any case, it modifies or creates a value in the blockchain network's ledger (also known as world state).
Both, Hyperledger Fabric and BichainDB offer the possibility to have a private, permissioned blockchain database. With their concepts they try to address the main disadvantages of public blockchains like lack of privacy and lack of performance (low throughput etc).
What are the main differences between the two technologies?
If you try out example application of both frameworks, you will quickly notice that BigchainDB is easier to start with. Hyperledger Fabric involves a lot of more knowledge to master it.
Fabric knows different kinds of nodes (peers, peers additionally being endorser nodes, orderer) and thereby allows a very flexible setup, depending on the consortium design and organisations themselves. BigchainDB has one kind of node that can be deployed. Also every involved organisation gets one node of course.
Fabric has richer capabilities to model assets and all kinds of transactions. One transaction kind can always be implemented by a custom processor function doing whatever is needed to query or modify the state of the ledger. BigchainDB only knows CREATE and TRANSFER transactions on every defined asset. You can create something (that may be also divisable, e.g. amounts of tokens) and can transfer them completely or partly.
Both seem to have pretty low level APIs. Fabric has more APIs and config models that need to be mastered. But Fabric is being complemented by frameworks such as Composer (with all its nice libraries involved, like playground and rest-server) that really improve the programming model. As far as I know there is nothing like that for BigchainDB, also because it is pretty simple from the start.
Consensus: BigchainDB uses Tendermint which is Byzantine Fault Tolerant. Fabric does PBFT which is Practically Byzantine Fault Tolerance, based on the idea of Miguel Castro.
In general I would say that Fabric is intended to be used for complex business use cases. BigchainDB is simpler and nice for assets that can be divided (financal stuff like coins/tokens maybe).
A couple of questions on channel:
Characteristics of a channel:
besides partition does the channel have the characteristic of hierarchy - meaning, if I have 3 channels can I arrange them into a hierarchy structure, channel a contains channel b and channel b contains c?
Management of channel:
sort of related to above question;
what is the best practice to manage all channels under one peer/user,such as, CRUD? In my mind this concept of channel seems to be a great idea but could possibly become out of control quickly - the impact on scalability, performance, storage and data segregation of the network.
Is there any details around the roadmap of how to manage the channel in both the micro and macro sense?
These are Hyperledger Fabric questions, as Composer does not manage channels (you deploy a Composer business network archive TO an existing channel).
Channels are essentially separate ledgers. They allow you to manage a single Fabric, that supports multiple ledgers across different subsets of your peers.