21 Replies to “7 – How exactly Hyperledger Fabric works. Basic workflow of transaction endorsement”

  1. As far as I am concerned the orderer doesn't do any verification. The orderer only package the patches of transactions from different channels into blocks as per a strict sequence mechanism. Then sends them to the peer for validation. Peers will check endorsements and other elements of each trx. Then mark them as valid or invalid.

  2. Здравей, много хубаво видео, може ли по задълбочено инфо от коя бригада за бране на ягоди в Англия се научи така да говориш, и с коя фирма замина? За един приятел питам

  3. What does it mean for Peers to be synchronized when they are part of a different organization?
    Peers of the same Organization have access to the same channels, so it is clear: across every channel, they have the same values.
    For peers of different Organizations, synchronization must then mean they have the same BC for the channel they share – correct?

  4. is it possible to have 1 transaction per block?
    I mean may i release a block with one single transaction?

  5. Dear Иван Ванков,
    Thanks for your excellent explanation! It helps me a lot to know how Fabric network work.
    I would like to ask you two questions:
    Question 1: Does Orderer in Organisation 1 tell all peers in both Orgs to update their ledger? I didn't hear you mentioned about that.
    Question 2: Orderer is not tell peers to update the ledger for transaction one by one, but the Orderer will queue and pack into a bunch of transactions for a while (let say 10 seconds), then send them all to the peers. So how we can avoid versioning outdated problem. Which is the best approach you think?

  6. Thanks Ivan. If you have any further guidance on implementing a REST API on top of the HLF SDK (as you indicate at 20:45) or guidance for best practices there, that would be very interesting. Thank you again, these are very informative.

  7. Nice videos! Keep going. One question on double spending, so the assest had version 1 while the first organization was peocessing the txn. Same time even organization 2 will also have same version isnt it since the ledger is not updated. So how will org2 know that the version is updated?is it because orderers are connexted acroos orgs, so prior ordering the txns it check across network to ensure no other orderers have this key/version?

  8. Thanks for the video. How can I maintain data privacy between the peers in a same channel..??

  9. Great video, but there's a small error in it. Currently the Orderer (e.g. using Kafka) belongs to a single organisation. There is still no support for multiple organisations hosting orderer nodes. This should come when they implement BFT.

  10. Very nice! One of the comments was related to the number of Orderers, which I also share: all documentation seems to indicate one Orderer. Could you confirm?

  11. Could you share the source of the diagram that you used in this video? I want to include it in a presentation and I would rather have the original then a screenshot of the video. Unless there are copyright issues with doing that. I appreciate the effort that you put in making this series and the utility of the information. Thank you!

  12. Hello, Ivan. Thanks for your videos. I have a question. For example we have an organization. And there a lot of staff members. Do they all have a copy of ledger? Or there just one server via which users able to add blocks and read a ledger current state? Maybe it's simple, but I can not to understand. I would be grateful if you explain me this moment.

  13. Hi Иван. Great video. I have a few question though which I hope you can help. What happens to those invalid transaction that the orderer rejected? Does this mean as far as the client is concern the call failed and it has to perform a retry? Or will the system automatically perform a retry? If a peer is out of sync what's the normal process to bring it in-sync with the rest of the peers?


Leave a Reply

Your email address will not be published. Required fields are marked *