What happens if the ledger is taken out and attached to a new fabric network? especially in the below case
1 Fabric is used for storing confidential data among 3 parties.(via chaincode abac, chaincode multi ownership among 3 parties so there are three ledgers synced)
2 One party(party A) takes out the ledger and setup a new hlf behind and attaches the ledger to the new hlf and changes the chaincode in order to see all the data.......
In this scenario what can be implemented to prevent the party A from seeing the data.....isn't it true that the ledger is taken out so the ledger is just a chuck of file(impossible to function as long as it is not in the original HLF setup(the orginal hlf network.......even ip change blow up all the ledger and setting......).....
Look forward to your replies
For any given peer or orderer that is part of a Fabric "network", some person or entity will inevitably have physical access to the platform on which it is hosted. They will be able to physically read the ledger file(s) as well as the state database(s). So if they are not supposed to have access to the data, then you either need to encrypt the payloads at the application layer or you can use private data collections.
Related
I am currently designing an application to be used to conduct transactions of an entity (e.g. a corporation).
When should the application have multiple chaincodes? In other words, what is the purpose of multiple chaincodes?
Why should a chaincode have multiple smart contracts? Should I have multiple smart contract for one that is used to submit transactions (e.g. making changes to world state) and another for evaluating transactions (e.g. querying from world state)?
Thank you!
For running a business, some organizations have to come into a consensus and so they have to create a channel where only permissioned organizational properties have access.
Here within a channel every valid organizational peer hold a physical copy of business transactional records which is known as ledger where the ledger is identical which means every ledger that belongs to same channel must hold the same records.
A ledger consists of two distinct, though related, parts – a world state and a blockchain. The world state – a database that holds current values of a set of ledger states. The blockchain – a transaction log that records all the changes that have resulted in the current the world state.
A chaincode is the business logic that is used to read the records of ledger or to write new records into the ledger or to update existing records.
A chaincode is consist with multiple smart contracts.
So The convention is for each channel, you need an identical chaincode. If you have 2 channel, than it's the convention that you have two different chaincodes.
According to most examples, there are logically minimum 3 organizations (org1, org2, orderer).
Actually there are only 2 physical organizations (org1, org2). Either one of the organizations or an agreed 3rd party has to hand over the orderer organization's responsibilities.
Q1: Who should be the owner of the "Orderer Organization" in Hyperledger Network?
Q2: Would there be a security flaw if an organization becomes the "Orderer Organization" and owns all of the orderer nodes (Raft) in the Hyperledger Network?
Q1: Who should be the owner of the "Orderer Organization" in Hyperledger Network?
Answer to first question is tricky. Just to give preface to answer, because Fabric’s design relies on deterministic consensus algorithms, any block validated by the peer is guaranteed to be final and correct. Ledgers cannot fork the way they do in many other distributed and permissionless blockchain networks like Bitcoin or Etherium. Orderer/Ordering node does this transaction ordering, which along with other orderer nodes forms an ordering service.
Just like peers, ordering nodes belong to an organization and everything that interacts with a blockchain network, including orderers acquires their organizational identity from their digital certificate and their Membership Service Provider (MSP) definition.
Every channel runs on a separate instance of the Raft protocol, which allows each instance to elect a different leader. This configuration also allows further decentralization of the service in use cases where clusters are made up of ordering nodes controlled by different organizations. While all Raft nodes must be part of the system channel, they do not necessarily have to be part of all application channels. Channel creators (and channel admins) have the ability to pick a subset of the available orderers and to add or remove ordering nodes as needed (as long as only a single node is added or removed at a time).
So Channel Creator and Channel Admins can choose subset of the available orderers or add/remove single orderer. Also multiple organizations can control cluster having ordering nodes. So it is upto you whom you call owner.
Q2: Would there be a security flaw if an organization becomes the "Orderer Organizaion" and owns all of the orderer nodes (Raft) in the Hyperledger Network?
Just some points to Note before answering definitively:
Orderers can not see transaction data, they only order the transactions.
Everything that interacts with a blockchain network, including peers, applications, admins, and orderers, acquires their organizational identity from their digital certificate and their Membership Service Provider (MSP) definition.
Although an organization can act both in an ordering and application role but it is a highly discouraged configuration. By default the /Channel/Orderer/BlockValidation policy allows any valid certificate of the ordering organizations to sign blocks. If an organization is acting both in an ordering and application role, then this policy should be updated to restrict block signers to the subset of certificates authorized for ordering.
Before any transaction(ordering) is authorized it is validated by peers and after validation consensus transaction is committed.
In Hyperledger Fabric, the blocks generated by the ordering service are final. Once a transaction has been written to a block, its position in the ledger is immutably assured. As we said earlier, Hyperledger Fabric’s finality means that there are no ledger forks and validated transactions will never be reverted or dropped.
Raft follows a “leader and follower” model, where a leader node is elected (per channel) and its decisions are replicated by the followers.
So if above points are considered in implementation with security consideration it should not be a security flaw since orderer is only doing ordering, can't see transaction, is validated by Peers before transaction is committed, Peers & orderers are different organisations and once transaction is committed in order it is final & immutable in it's order & position.
Sources:
https://hyperledger-fabric.readthedocs.io/en/release-2.0/orderer/ordering_service.html
https://hyperledger-fabric.readthedocs.io/en/release-2.0/Fabric-FAQ.html
https://medium.com/#kctheservant/add-a-new-organization-on-existing-hyperledger-fabric-network-2c9e303955b2
https://medium.com/swlh/hyperledger-chapter-6-hyperledger-fabric-components-technical-context-767985f605dd
I am new to the area of DLTs or "blockchain" and I am trying to create an application on top of Hyperledger Fabric. Before I describe my use case, I need to mention that due to my use case's nature I need a private & permissioned "blockchain" which justifies the choice of Fabric (I am aware of other platforms e.g. Corda, private Ethereum, but Fabric seems to match my use case better).
Use Case
My use case consists of two different types of participants. A number of organizations (which upload and share information about individuals on the distributed ledger) and a client who can query information about an individual.
The client should not be able to see the transactions uploaded by the organizations and will not have write rights on the DL. He has read-only rights. Moreover, the organizations trust each other and there is also a level of trust between them and the client.
Design thoughts
Based on what I've read, I was thinking of creating a DL network that includes all of these parties and use channels which, based on the documentation, can be used to create a grouping among a number of participants (the organizations in my case) thus "hiding" the transactions from the parties which are not included in this group (the client in my case).
However, later I read about chaincode (a.k.a. smart contracts) which:
can be invoked by an application external to the blockchain when that
application needs to interact with the ledger
which confused me since if the "blockchain" can be queried from an external entity, that probably means that the client should not be included in the trusted network.
Am I headed in the wrong direction (design-wise)?
Based on your description, Hyperledger Fabric channels sound like a good solution. You should also familiarise yourself with private data collections, as this is another way of hiding some of the data from some peers. Which option is best for your scenario will depend on how your datasets are structured, and whether you also need to keep the data private from the orderer.
Clients are not part of the network. They query the blockchain by connecting to a peer and then requesting data from that peer. They can then only access the data visible to that peer (which is stored locally by that peer). So, it is not possible for a client to access more data than is available to the peer the client is connected to.
In your example, you would have a "client" organisation, with at least one peer. This peer would be part of the network, and your client application would then connect to it for access to data on the ledger (typically using the Hyperledger Fabric Node SDK).
There are two types of chaincode in Hyperledger Fabric.
User Chaincode (often just referred to as "chaincode") is used to update the ledger for a channel, and is only installed on those peers which require it (i.e. endorsing peers). Since your "client" peer would not be an endorsing peer, it would not have access to the user chaincode for the channel.
System Chaincode which all peers have access to, provides (among other things) an interface to allow queries to be run against the ledger.
I have a web-based application for HR Employee management.
This application has many clients that login into the web app and uses the features.
I want to integrate this app into the blockchain. I want some of the data (compliance related, sensitive) to be recorded in the blockchain.
Data will be written to blockchain by my application only. My clients will only view the data.
What approach should I use?
a) Single Org (my app) with multiple peers (1 peer per client).
b) Multi-Org: Org1 = My app, Org 2 = Client 1, Org 3 = Client 2 .... n.
If any other approach please suggest.
Note: Individual Clients won't be sharing any data among themselves.
I want to use the hyper ledger fabric blockchain for only storing the information because it is immutable and tamper proof.
Even If I go with multi-org scenario, Both orgs will be added by me on servers managed by us. Will this cause trust issues in courts legally? Can I prove that data has not been tampered although all servers hosting blockchain are mine?
Based on your statement "Individual Clients won't be sharing any data among themselves", I would suggest 2 options based on the native capabilities of HLF, depending on whether all data in the transaction is private, or only a subset of the data.
No data is shared - one channel per peer, one peer/org per client OR one peer with multiple channels. In the multi-peer case, transaction data is only stored on the one peer which is a member of the channel. No other peers receive the data.
Some data is shared - one channel for all peers, one peer/org per client. In this case, a private data collection can be used to store private data. Transactions are stored on the ledgers of all peers, containing all the data in the case of the initiating peer, and only the public data plus the hash of the private data on all other peers.
Neither of these options provides data redundancy across peers, but since you didn´t state this as a requirement, I'm assuming this isn't a problem.
Since you state that you will be in control of all peers, the immutability guarantee doesn't count for much, as there is nothing to prevent you from rewriting the entire blockchain at any time. Despite this, such a solution would still be superior to a traditional database, since it would be immune to changes at an individual transaction level.
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