1

I wish to enquire if there are maximum no. of participants, assets, transaction that hyperledger can support?

Also, is there rollback (ACID compliant, example) if the submission of a transaction fails?

Thank you.

Nathan Aw

Nathan Aw
  • 545
  • 5
  • 18

2 Answers2

1

I wish to enquire if there are maximum no. of participants, assets, transaction that hyperledger can support?

Of course there will be limits. But they are, for practical purposes, high enough to allow serious work to be done. Participants can take several forms:

  • organizations with a separate identity and potentially with their own CA, MSP, orders, endorsers, and committers in any combination
  • roles in chaincodes
  • identities with a specific role in an organization

The most limited will be organizations and peers etc, but a consortium can still be big enough to accommodate more than a small number of these to my knowledge. Roles and identities are dependent on your needs and the design of your smart contracts. Unless you are stress testing, how many of each do you really need? (Identities will be of course be largest in number, but the system is designed with that in mind, again to my knowledge).

So my point here is that the limits should be adequate for most practical purposes.

Also, is there rollback (ACID compliant, example) if the submission of a transaction fails?

The whole point of a blockchain is to provide a transparent, distributed ledger with perfect consistency at all times. So the answer is yes.

Note, though, that roll-back simply means that at transaction succeeds or fails and that all copies of the ledger will have the identical result. If the transaction fails, then none of its changes will appear in the ledger.

Transaction failure modes:

  • Fail during endorsement happens when the chaincode chooses to fail the transaction for violation of business rules or for internal errors.

  • Fail during commit happens when two transactions execute in parallel (for practical purposes that is -- they could execute too close together and get the same effect) and (a) touch the same keys, and (b) end up in the same block. In this case, the endorsers happily create the read / write sets for both, but the committers find that the second transaction is reading an invalid version of a key that was updated by an earlier transaction in the same block. The read / write set is never applied, thus providing the roll-back.

The solution to consistent failures during commit is to add flow control into the application. You cannot solve that in the chaincode.

Kim
  • 592
  • 3
  • 13
  • Thanks Kim. Is there a possibility that for some reasons that some ongoing transactions might result in a inconsistent ledger state which result in inaccurate queries while reading the ledger state? – Nathan Aw Oct 01 '17 at 17:43
  • Nathan, Queries come through in two modes (and here I cannot claim direct experience, so take with grain of salt for now): A weak query is sent to one local peer and is answered immediately with the peer in whatever state it happens to be (as in, there might be slight inconsistencies in recent updates that are in the process of being applied). A strong query goes through full endorsement so that you get the consensus policy applied to the results, which means that at the least you get an answer that the networks considers consistent and accurate at the time. – Kim Oct 02 '17 at 13:28
  • However, in *neither* case does the network make sure that your latest block has been committed to all peers, so the data you think you should see might still be in transit to world state. I.e. if you read too fast after sending an update, you get old data because the query and the update can run in parallel. – Kim Oct 02 '17 at 13:28
  • Understood. thanks a lot Kim! I have been cracking my head over --smart contracts as well --> https://stackoverflow.com/questions/46569843/smart-contracts-hyperledger-vs-eth – Nathan Aw Oct 04 '17 at 16:36
0

There is no limit in the number of participants that can take part in an Hyperledger Blockchain. However, they will be private Blockchains, so everybody wouldn't take part on it.

About the fail of the submission of a transaction, it depends on what you mean with it. A transaction could fail when it is send by a user. However, once a transaction starts its trip, it will terminate.

Once a Peer sends a transaction, it waits to get an answer. It could be successfull or not, but it needs an answer. If I were you, I'd read about the transaction flow of a transaction in Hyperledger Fabric. Or about the Basic workflow of transaction endorsement

Urko
  • 1,479
  • 1
  • 14
  • 20
  • Thanks. I was referring to when a transaction is sent by a user, not via smart contract/chaincode. based on the link (http://hyperledger-fabric.readthedocs.io/en/latest/txflow.html), can I conclude that this is async call and not sync call? - Nathan Aw – Nathan Aw Sep 13 '17 at 17:21
  • I think so. I understand the same as you. – Urko Sep 13 '17 at 17:26