I am creating an electronic voting software on the Hyperledger Fabric platform and I need some transactions to be carried out by using ecerts "X509 MSP" and other transactions using "idemix MSP". That is, in some transactions, users must be recognized and in other transactions they must not. I thought about doing two different channels, one that uses "X509 MSP" and the other that uses "idemix MSP", is it possible that both channels communicate with each other? Is there any other better option to implement the above?
I am a bit lost if someone were able to direct me to a solution I would appreciate it very much.
So there is a 1-1 mapping between an MSPID and the MSP provider type. But an organization can have course have 1 or more MSPIDs.
So for any given organization "N", you could have OrgNMSP1 use X509 and OrgNMSP2 use Identity Mixer. Both of these can be added to the same channel(s).
A more likely scenario would be to have a single Idemix MSP used by all orgs, but either case will work.
Related
I want to ask about blockhain Hyperledger Fabric. Is it possible to let Peer nodes to do Orderer node's task which is packing the transaction into new block?
I kind of think the orderer node is kind of a redundant node since for example in Bitcoin network, the packing of the transactions into block and the verification of new transaction is solely done by the full node(miner node).
Can anyone give me justification why there should be orderer's node in the Hyperledger Fabric?
And if I were to build my project on Hyperledger network and forgo orderer node(which means the peer node will do both the verification of transaction and the packing of transaction) is it possible?
Please tell me your thoughts and ideas.
Thank you.
TL;DR
HLF by design is deterministic so the orderer nodes are important. Only they participate in consensus not all peers and the blocks they produce are Final (Not prone to forks).
No you cannot make a peer orderer as well. Your network configuration for HLF must have at least one orderer to work
Hyperledger Fabric (HLF) vs Bitcoin
HLF is a private permissioned blockchain where as Bitcoin is a public permissionless blockchain. You should not expect them to work similarly.
Public blockchains
In public blockchain for example bitcoin everyone is treated equal in other words no one have special privileges you may think well miner are the ones minning block but the important point is anyone can become miner its open game no restriction on who can become miner or who can run a node etc.
Private Blockchain
In private blockchain for example HLF roles are predefined at the time of setting up and starting blockchain. Each role has certain tasks and privileges and restriction. The no of organisations peers, endorser peers, orderers, channels all are predefined and some have special privileges which no other role has like orderer whose is responsible for receiving endorsed transactions from peers and put them into blocks then these blocks are distributed to all peers. These blocks are Final.
But Why?
Private Blockchains (Like HLF) full-fill special use cases for example supply chain, B2B operations In such use cases one may want to harness positives of blockchain like transparency, auditing, provenance but may also want some sort of role based access or restrictions of certain data to certain audience public blockchains like Ethereum and bitcoin does not fit here.
Now coming toward your question
Why is there an orderer node in HLF isn't it redundant ?
No it's not redundant, HLF has deterministic consensus algorithms where as Ethereum and Bitcoin have probabilistic consensus algorithms which means there can be ledger forks. In HLF there are no Ledger forks because fork occur when two equal participants have conflict at a common point. Incase of HLF the participants are not equal as peers cannot participate in consensus process the block order set by orderers is Final. And rightfully so because for the use cases it is designed for does not want forks and want to have special roles and much much more transaction throughput.
Must must Read !
https://hyperledger-fabric.readthedocs.io/en/release-2.2/orderer/ordering_service.html#what-is-ordering
No it is not possible to assign peers orderer's role you must have at least 1 orderer in your HLF network to work.
I have this scenario that a single node is part of different channels. In one channel there are only traders. In the other channel there are traders and regulator. Details of the trades should not be shared with the regulator. The only thing which is being shared is aggregated value at the end of the business day. By aggregated value, we mean how much of each asset is sold, not the detail of each trade. In other words there is confidential information between two parties that cannot be shared with regulator, and there is aggregated value that is not confidential and must be shared with the regulator.
Now I have an event when there is a nomination. By nomination I mean a trade made over some asset in the first channel, the one without regulator. Is it possible to handle this trading event in the other channel where the regulator is?
As I read through the documents, channels are isolated. But how isolated are they? Are they isolated in a way that events raised in one channel cannot be seen or handled in another channel? In that case, how do you suggest to implement this scenario? I mean do you suggest any specific architecture or tools enabling implementation of this scenario? Also do you think Hyperledger Fabric or Composer are suitable for these requirements?
I appreciate any help. Thank you.
So you have two channels, two separate ledgers and two separate business networks (as you've configured it).
Your 'nomination' is, in effect, a 'transaction' as described above. (events in Composer mean, business events that are usually subscribed to by a client application FYI).
In Hyperledger Composer, you can do 'cross-channel' or 'inter business network' queries. So can allow [only] the Regulator (from the 2nd channel) to query [only] those trade 'events' (ie transactions with the fields that contain the 'trade') or indeed assets (updated by the transaction), if need be - back in the '1st' channel (and access controls) in the 2nd channel can restrict the Regulator to do only that 'query' (if that's all he/she is supposed to have jurisdiction to do). Hope this helps.
See example
https://hyperledger.github.io/composer/latest/tutorials/invoke-composer-network
I am trying to understand why a verification of endorsed transactions has been positioned at the application layer instead of Hyperledger Fabric 1.0 ledger network.
Let's assume three possible scenarios :
a) Using Oracles to request information needed to perform a function, and that the address to the Oracle is embedded into transaction attribute.
b) Execution of different actions depending on the origin of the transaction (i.e. through the unmarshalled peer or sender identity)
c) Original smart contract code is tampered with through an injection of malicious binary code into the dev-* container
If, let's say, a genuine network participant with malicious intents wants to inject some garbage into the ledger and has an access to the application source code, she/he can tweak around this SDK function in order to force proposed transactions with dissimilar results to be sent straight to Orderers. If I understand right, the network will not detect such a misconduct.
Please correct me if I am wrong and if this issue can somehow be mitigated at the network layer.
The application layer is the one to fulfill the endorsement policy, since the application to invoke the chaincode, therefore to make it valid the application has to go and literally invoke chaincode against all parties involved or related to given transaction.
That being said, it become kind of obvious that once application at any case to invoke and collect endorsements it's make many sense to have the application layer to verify endorsement results and make sure they are correct before submitting to the ordering service.
However if client won't do that check or will try to temper the endorsement results, first of all it won't be able to provide required signatures over tampered data. While moreover there is a VSCC (Validation System Chaincode) which takes care to validate transaction to ensure that endorsement policy satisfied, overwise rejects/invalidates the transaction.
I'd say doing verification on the application side is more like a best practices and the optimization path which aims to spare validation cycles for transaction known not to be consistent once application receives all endorsement results.
I would really like to understand how endorsments work in Hyperledger Fabric in order to help me in designing a solution to a problem.
let's assume I am an endorser and a transaction proposal has just arrived. I would randomly select a participant within my organization, use its identity to perform the validations, checking for replay attacks etc then sign an endorsement with that participant's private key. Assuming I used an admin's credentials, the admin(person) may not be aware that I used its identities to validate and endorse a transaction proposal. Is this example correct?
Initial discussions here makes me feel like the more I look into it, the more confused I become. Could anyone help?
Just to start with, the endorser is the peer that capable to handle incoming invocation, maintain and run the chaincode. The flow works as following, support you have a client (C) and the endorsing peer (P), which runs a chaincode (CC).
Client forms transaction proposal request which includes parameters for chaincode invocation.
In order to get an endorsement for this proposal he sends it the endorsing peer.
Endorsing peer opens a transaction proposal and forwards requests to the required chaincode along the way it passes all parameters.
Chaincode get invoked which produces a RWset (set of keys and values read of changed during the invocation)
Peer collects RWset and forms proposal response and signs it
Client gets the proposal response, signs it as well and send it to the ordering service
Ordering service collects proposal responses and cuts the block which got distributed to the peers in the network.
Upon arrival peers opens a block and validates all transactions, one of the validation is to check whenever transaction conforms the endorsement policy, where basically it checks whenever transaction has enough signatures which satisfies the policy.
Back to your question, please note that at each step everyone uses its own key and certificate to sign, no one randomly selects participants to use they identities for signatures or whatever else.
PS. Note that process above a bit simplified and lack a lot of technical details.
PPS. There is a new course on Coursera which covers pretty well many technical aspects of Hyperledger Fabric architecture and the interaction between different components, I would urge you to consider taking this course.
Is there a way to disable reading from Hyperledger Fabric for a period of time?
I need this to allow only to write in hyperledger Fabric for a period of time, after this to allow only reading from hyperledger Fabric.
You might add a transaction to your chaincode that would update a state value that your other chaincode functions could check.
For example a disable_write transaction might set a state variable that other transaction chaincode could check before writing/modifying the world state. If the variable is set, don't allow the "write" transaction to occur.
You could then also add a second transaction to enable writes.
The only way to block any client from reading from blockchain has to be coded in the deployed smart contract and applying appropiate logic depending on your desired time policies, you will return requested data or an error indicating that reading is not allowed.
Found this today on https://chat.hyperledger.org/channels/fabric-questions:
Question:
from an operational standpoint, can you
'stop' a channel - for application-type transactions? That is,
'quiesce' the channel (ie the question posed is from an operational
management perspective based on a time-event)
jeffgarratt Answered:
one possibility is to alter the policies associated with the
channel with a config update. However, in general config changes
require multiple signatures from channel members. but once the
config is changed, you can effectively 'stop' the channel, i.e. alter
ability to write. this would still allow for reads, but the chain
would not progress, as no writes are allowed