I am building a hyperledger fabric blockchain application where several users interact. It seems to be working. Using hyperledger explorer I can also view the blocks and transactions in the blockchain.
However, it is not clear to me how to see get the transaction history for 1 user (based on his / her identity key)?
Basically, like for a customer of a bank, I would like to get only the transactions relevant to a particular user to provide him/her with a transaction overview.
Is there a tool for this? Is it integrated into Fabric?
There are several different ways to go about this.
On-chain: You'd write a chaincode function to return the corresponding transactions. To do this you need to keep track of each user's submitted transactions by storing the transaction UUIDs in the chaincode state (stub.PutState). With stub.getState you can later retrieve the state and return the transaction list. (inspired by this StackOverflow answer)
Peer SDK: As far as chaincode-independent transaction history goes I'm not aware of any API calls that support this. You can only get a transaction by its UUID.
Off-chain: Since you're already using Hyperledger Explorer, you should have a Postgres database containing indexed transaction data. You can query the transactions table from your application by filtering for the creator_id_bytes. Since Hyperledger Explorer needs to fetch new transactions from the peer first, there is some additional latency with this approach compared to 1/2.
Related
I have some questions regarding the deployment of a HLF use case. Suppose we build a platform in which users sell items. The users and their items are stored on the ledger via chaincode. The purpose is to also enforce access control on the items via the chaincode, so that another user for example cannot see a specific item. Then the 2 options regarding the whole identity management are:
The users do not have certificates in Fabric, and all transactions made by the users are forwarded to a single registered Client who interacts with the chaincode. Therefore, the transaction context will always have this client's ID. So from my point of view the username should be always passed to each transaction and implement access control using this username, though a registered Client has full authority over their data.
Every user is registered and enrolled and have their own identity. Every user makes a transaction directly on the blockchain via the chaincode, and access control can be implemented easily by using the stub.ID() and other attributes. That would mean that >100k users would be registered on a CA or multiple CAs.
The questions are:
Is HLF intended and suitable for the 2nd option, or is it made solely for the purpose of interaction between clients of organizations?
Is there a best way to handle this matter?
A ledger stores facts about the history of transactions that led to the current state of an object. The history also stores the users responsible for the current state of the object. If the state of an object is being changed, the admin/authorized user of an organization must be able to see who performed that change.
In the first approach, if you want to see the details of the user doing the "transaction", you'll have to store it somewhere different from the blockchain. While that can be a use-case of your project, it defeats the purpose of storing all facts about the history of a transaction of an object as every time the same user would be doing the transaction.
The second approach fulfills all the motives of incorporating blockchain in a project. Sure, you'll have to register and enroll every user who's creating/modifying an asset but then Access Control Management can be done in a better way. Please read about ACL to know about the granular access you can achieve in Hyperledger Fabric.
Also, you can also encode some information about a user in its x509 certificate with ASN.1
Second option is more preferred and Hyperledger Fabric ca could handled number of user registrations. There is Attribute access control also available which you can use at chaincode level to control use access.
https://www.youtube.com/watch?v=CAXRMJ-quhg
I am trying to implement a tamper proof uncentralized database of some records. these record are static and they cannot be transferred between participants, i.e, not like some currency or a stock. i just want them to be stored as they are. Identity is an important thing with my project. only certain people can add blocks to the chain, rest of them should be only there to verify the chain. Can i implement a blockchain for this usecase? if it is possible should i use an ethereum chain or hyperledger fabric?
According to your use case which is, certain people, add records and certain query records. A typical normal access control application and the database can solve your issue but,
If you deal with untrusted people and need complete transparency with identity-based access control and equal rights of all participants then hyperledger fabric is best.
Use case: a smart home which gathers raw data from all the sensors within it, processes them and extracts high level information from them. The owner of the house might want to share these information with other people, such as doctors, family members, friends... So, I'm trying to figure out which would be the best way to handle the access permissions on these data. Right now all the information are carefully encrypted and stored in a database (untrusted) and only the people with the right keys can properly decrypt those data.
My idea: I want to use Hyperledger Fabric to store and manage the access permissions to these files and also to store the hash digest of the gathered information for immutability purposes. Once the smart home generates an high level information from the raw data, it stores it inside the database and then it issues a transaction to Hyperledger Fabric with the timestamp and the hash digest of the data.
The smart home owner can share these information with other people, issuing a transaction with the ID of this person and an identifier of the data he would have the access rights on.
So before accessing the information stored inside the encrypted database, the application would check if the requester has the valid permissions stored within the blockchain.
My doubts and questions: since I'm really new on this topic, even though I've read a lot about it, I don't know if this would be an improper use of the Hyperledger Fabric. All the use cases I read about it, store all the data with Hyperledger Fabric, without relying on an external cloud storage service.
Since all the transactions would be stored in the blockchain and the blockchain is maintained by all the peers inside the same channel (btw I would use just one channel to keep everything), they may be able to access to the Hyperledger Fabric database and extract information about the smart home. Am I wrong? If not, how can I solve this issue? I could use the identity mixer feature to "hide" the transaction issuer, but still the transaction would be visible to all of the peers who keep the blockchain available.
I understand your questions. We could not hide all information from Peers, but you can encrypt sensitive information and allow specific people to decrypt it as you mentioned. In addition, even you cannot prevent malicious access on time, but you can collect malicious access activities for auditing in the future. for example: using access control on each world state database of peers.
In my Hyperledger-Fabric application (developed with Hyperledger Composer), I want to prevent participants from being able to look at the old transactions.
Old transactions can be viewed either in the Hyperledger Composer Historian or in the Hyperledger Explorer.
I know how to make old transactions non-visible to participants in the case of Hyperledger Composer Historian (namely in the file permissions.acl). But preventing participants from looking at old transactions in the Hyperledger Composer Historian is not of any use, as long as they can instead view the transaction history in the Hyperledger Explorer.
So my question is this: how can I make the transaction history non-visible to participants in the case of the Hyperledger Explorer?
UPDATE:
Is it possible at all for an organisation to use Hyperledger Explorer without the knowledge of other members of the network?
If it is not possible for one member to use Hyperledger Explorer on the network without the other members allowing it, then the problem is gone anyway.
You can't make participants not being able to access data they have already seen, thus you can't make transaction history disappear from the channel members local peers.
I know how to make old transactions non-visible to participants in the
case of Hyperledger Composer Historian (namely in the file
permissions.acl).
Even if you define access control for clients in the application layer:
All peers in the channel can still see the transactions
Every client that has permission to pull blocks from peers or orderers, can still see the transactions via pulling them itself.
But preventing participants from looking at old transactions in the
Hyperledger Composer Historian is not of any use, as long as they can
instead view the transaction history in the Hyperledger Explorer.
Such a fact should instill doubt in the mind of anyone, and make him/her wonder whether the hiding is of any use, to someone that has access to the blockchain itself.
I am new to composer, and now practicing some of the tutorials and examples. But while doing this I can not understand some of the features, so here are the questions which I do not clearly understand:
Are queries restricted by .acl file (when, for example, we use them in rest server)?
Do the rules written in the .acl restrict some of the transactions which are allowed for certain participant to submit? (For example, for participantA it is not allowed to CREATE new participants, but what happens if participantA submits the transaction(which is allowed for him to submit)which creates another participant, will this transaction fail?
Could cards be created by rest api server?(I know that participants could be created using JS api, but is it possible to create and issue the identity for those participants through RestServerApi?)
What happens when PeerAdmin upgrade certain node to a new version? How do other nodes act in this case? Do they upgrade themself automaticly?(Also found that upgrade takes a lot of time(2-4 minutes) when deployed locally, whereas in browser for local connection it takes 3-4 seconds)
Does Hyperledger fabric allow some of the ledger data be stored in one private network, whereas other network connected to the private one would not store this part of ledger( or the data will be simply crypted)? The same question regarding the transactions: will the be executed on outer networks?
Yes Composer Queries (and therein, results) are subject to ACL restrictions or filters.
It will still fail due to ACL rule restriction. Once denied to create, always denied as that is the final operation (in this scenario). The actual transaction would fail.
Yes of course use POST /system/identities/issue REST endpoint (eg http://localhost:3001/api/system/identities/issue) - see an example here -> https://medium.com/#CazChurchUk/developing-multi-user-application-using-the-hyperledger-composer-rest-server-b3b88e857ccc
An administrator with PeerAdmin capability has responsibility to install new version on his peers (in his Org). The other Org peer Admins are responsible for theirs, that's how a blockchain consortium with different Orgs will work. They will agree the 'what' and when but will need to install the new version on own Org's peers, so the new version can be started on the same channel. Of course, there will be a difference between a Fabric infrastructure response time, and that of a web connection using local storage.
Channels in Fabric implement privacy. You can have one or more business networks on that channel (ledger), therefore transactions in that business network are private to that ledger. It is the client's responsibility to encrypt data or not. Hyperledger Composer can allow call one business network from another, on the same channel, or if permitted to do so, on different channels too - see https://hyperledger.github.io/composer/latest/tutorials/invoke-composer-network