I have basic understanding of both model.There are two popular approaches to defining assets in most block chain solutions: the stateless UTXO model, where account balances are encoded into past transaction records; and the account model, where account balances are kept in state storage space on the ledger.
which model does Hyperledger Fabric support to create assets ?
is it handled by the sdk or the responsibility of the smart contract developer to handle this?
Developer handles definition of assets in the the chaincode. The values are then kept in world state storage which is actually different storage from the ledger. The ledger lives on the peer's file system and the current values of "accounts" aka key value pairs are stored in the world state which is database. Typically couchDB but can be configured to connect to other types of databases
Related
I have some questions regarding the deployment of a HLF use case. consider that we want to implement a network for insurance industry.
clients want to interact with an insurance company to make an agreement and whenever they suffer from an accident, make a request to claim their funds.
We also have an organization that assesses the damage.
When the customer requests an assessment, the damage assessment process may take several days.
In the compensation process, the assessors must endorse the transaction.
Do customers in the network need an organization and peer or is it enough to be interacted with the application?
Doesn't the fact that transactions take several days to be endorsed pose a problem for the network? What solution do you suggest for its implementation? What functions should be used in a developing Chaincodes?
The documents that assessors want to record after completing their work may include images, videos, and a lot of information. How should this information be stored on the network? Doesn't it create a heavy load on the network?
Do customers in the network need an organization and peer or is it enough to be interacted with the application?
It's up to you whether or not you want to register your users on the blockchain. Registering and enrolling an identity in a Hyperleder Fabric network means you're making them a member of an organization. With registering identities on the blockchain, you can have better access control management of identities. Also, if you're registering a user on the blockchain, the admin would be able to see in the ledger which member did a particular transaction. You can achieve the same without registering members on blockchain but it's one of the perks and underlying principles of Hyperledger Fabric so why not leverage it.
Doesn't the fact that transactions take several days to be endorsed pose a problem for the network? What solution do you suggest for its implementation? What functions should be used in a developing Chaincodes?
No, transactions don't take several days to get endorsed in Hyperleder Fabric. It takes only a few seconds to complete a transaction. And, you can increase the throughput by structuring your application better(have more no. of peers etc). Yes, there'll be a limit to how many transactions you can do per second even when you have a good architecture, but isn't it what blockchain infamous for?
There're other ways of increasing the throughput depending on the use-case. One could be returning the response to the API caller as soon as the transaction gets endorsed, not waiting for the transaction to get committed in the ledger. There're definitely some cons to this approach like getting an MVCC error later but if handled properly, this can be one of the best ways to increase the throughput in Hyperledger Fabric.
The documents that assessors want to record after completing their work may include images, videos, and a lot of information. How should this information be stored on the network? Doesn't it create a heavy load on the network?
There's no need of storing blob files in the database. It doesn't have anything to do with blockchain. In a simple project which handles uploading and downloading images/videos, you don't save those files in your database. You just store the name in the database which points to a file in the filesystem.
You can read more about "Should you store images in DB or not?" here.
I currently have two business networks modeled in my Composer. The idea is that one network stores reference data (NetworkA) and the other stores processed transactions (NetworkB).
NetworkB needs to query the data in NetworkA in order to process the transactions properly. This means that the users in NetworkB needs to have NetworkA ACLs as well.
Is it possible to define participants once in Composer? Or are you forced to duplicate your particpants in both business networks?
No - the participants are unique to the Business Network.
Using standard composer functions, the 2 networks are separate and do not communicate. You could use the getNativeApi() function to use Native Fabric calls to connect to the second network.
This tutorial illustrates how you might achieve what you are are suggesting. However, you should be aware that using this method will bypass the Composer ACLs when accessing the 2nd Network. getNativeApi() is described in this Composer document.
In hyperledger fabric, we can have multiple state databases corresponding to each channel the node has joined. Do we also have multiple blockchains corresponding to each channel for a node?
Note that in Fabric there is only one ledger per channel. Ledger in Fabric contains two components. One is called the world state which stores the latest value of the keys. Another one is called blockchain which stores all the transaction log that leads to the world state. So back to your question, there should be one state databases (world state) and blockchain per channel. Each peer in the channel hold a copy of the ledger and thus should have a consistent view on the world state within the channel.
For more information, you may refer to the following:
Docs on Ledger
https://hyperledger-fabric.readthedocs.io/en/latest/ledger/ledger.html
I have a multi-org fabric network where all the orgs are on a single channel.
I understand that using the composer acl file we can hide data from the users based on their roles and other conditions.
However, the data will be visible when we get into the peer container of any org and issue a peer channel fetch.
So, my question is, is there a way to encrypt this ledger data when the orgs shares the same channel? Here, they mention about encrypting the data. Is there any example/reference that can get me started on that one?
Currently, I'm not planning to use different channels between different orgs.
Yes, there are few ways to protect the ledger data. Like your mentioned in your question, Hyperledger Fabric FAQ, official gives five different ways to help us to achieve security and access control.
In the newest version of Fabric, which is tagged v1.2.0, provided a new definition called private data. I prefer to use this method to build my access control in my apps.
Since I am using Fabric Node SDK to deploy and control the fabric network, and it provides a convenient way for me to embed it into the exists projects.
Using the configuration file to define who can persist data, how many peers the data is distributed to, how many peers are required to disseminate the private data, and how long the private data is persisted in the private database. All the upgrade that you need to do is adding some parameters when install and instantiate, modifying some function to invoke the private data, writing some codes to handle the configuration file and users control.
It gives some examples for us to use this new feature:
Chaincode example
SDK example
I have created a network composed by two nodes using this tutorial: Multiple Machine.
In the node with orderer and ca installed, I can use the composer-playground to interact with the blockchain. Instead, analysing the logs of the docker on the second node, I am able to see the communication between the nodes but I am not able to access the data.
How can I access data on the second machine?
It is a simple node connect to the first node (where is installed the orderer and the ca).
Thanks,
What do you mean by accessing the data?
In Hyperledger Fabric the ledger data is composed of two components i.e. World State and Transaction History Log (the blockchain).
Here World state refers to the most recent (current) state of the assets you have and Transaction History log refers to the transaction executed on these assets. Assets or Key Value set when using CouchDB as the World State allows you to have KeyValue with Value as JSON documents.
The World State by default is stored in levelDB or couchDB, if you have docker containerized network the World State levelDB is stored on the peer container while using couchDB sets up its own couchDB container associated with each peer. The couchdb for each peer can be accessed from host machine using http://couchdbIp:port
The Transaction log get's stored in the underlying file system as blockFiles somewhere under location /var/hyperledger/ledgerdata or something in the peer container.
When you mention Orderer, which is another component like peer, is a docker container assigned the role of making sure that transactions are properly ordered and verified that their endorsement are valid. This gets complicated as you go to having multiple ordering service nodes and requires Kafka implementation rather than the default SOLO implementation. You can read about each of these implementations in Hyperledger Fabric official documentation.
Also CA is associated with each organization responsible for establishing chain of trust is another component of Hyperledger Fabric that signs certificates of network components like organization peers, client and participants following PKI.
The Playground will connect to the Fabric based on the connection profile (connection.json) for the Business Network Cards you have. If you want to specifically connect to second node you could modify a card.
But remember that Playground is a development and test tool not a production tool so you shouldn't worry too much about hitting different containers with it - particularly as the data will be the same replicated across Peers.