As currently, I'm working on fabric SDKs. I want to get all the past transactions of fabric on the client-side.
Example: I already have 1 installed chain code. On fabric, I called delete_user and edit_user methods. I want those all transaction on client side without storing in offchain DB.
Can anyone suggest Node SDK method for the same?
Have each transaction function emit a suitably named chaincode event (such as "deleteUser" and "editUser"). The chaincode event gets emitted be peers only when the transaction is successfully committed and updates the ledger. Your client application can listen for those chaincode events and take action on each chaincode event.
You can start listening for chaincode events from a specific block number to replay historic events. You may also want to use a "checkpointer" (or roll-your-own) mechanism for persisting the block number and transaction ID your listener last successfully processed so you can resume listening from exactly the same point after an application restart. This would allow you to process each chaincode event exactly once, with no duplication or missed events.
See these Fabric samples for examples:
https://github.com/hyperledger/fabric-samples/tree/main/asset-transfer-events
https://github.com/hyperledger/fabric-samples/tree/main/off_chain_data
Related
Currently ,in fabric gateway API when we submit the transaction using APIs provided by TransactionImpl ,inside commitTransaction method of TranscatioImpl it creates commitHandler on network and transaction Id and after sending the transaction to channel,it waits for the response to come back by calling commitHandler.waitForevents .Is there any way I can do this in asynchronous way ,i.e. after submitting the transaction to orderer, I want to proceed submitting next transaction and write a separate event listener which would listen on the events coming back from fabric and take some action on them as and when they recieve.
You don't have to wait on submitTransaction if you don't want to, for example suppose you want to submit a number of transactions and wait for them all to commit then you can just collect the promises from submitTransaction and wait on them at a later point in time. If you don't care when your transaction is committed then you can specify the gateway commit strategy as null which means it won't even bother to listen for transaction committed events. see https://hyperledger.github.io/fabric-sdk-node/release-1.4/tutorial-transaction-commit-events.html
for more info
If you want to do your own event handling you can add contract/block/transaction event listeners yourself
see https://hyperledger.github.io/fabric-sdk-node/release-1.4/tutorial-listening-to-events.html
for more details
I am new on Hyperledger fabric. When I was reading https://fabric-sdk-node.github.io/EventHub.html#registerBlockEvent
It talks:
registerBlockEvent(onEvent, onError)
Register a listener to receive all block events from all the channels that the target peer is part of. The listener's "onEvent" callback gets called on the arrival of every block.
I suppose the onEvent happens AFTER "Ordering service has made the block and send it to Peers". The "Arrival of every block" is from Peer's point of view. am I correct? Thanks.
After the transaction proposal has been successfully endorsed, and before the transaction message has been successfully broadcast to the orderer, the application should register a listener to be notified of the event when the transaction achieves finality, which is when the block containing the transaction gets added to the peer's ledger/blockchain.
technically there are 3 types of events which depend on the approch that you have you can go with one of below
TransactionEvent
BlockEvent
Chaincodeevent
To my knowledge, there isn't a way to do timed transaction in Hyperledger Fabric.
Consider the use case using the marbles example. Say I want to transfer a marble 600 seconds after I received it. Does the Fabric SDK provide anyway for me to get the unix timestamp of the event when I received my marble then send another transaction to a queue that will happen exactly 600 seconds later by calculating the timestamp + 600?
As you are talking about the time when the Marbles are actually received, then in my opinion you have to write some code on both sides. i.e, both at client and the chaincode sides.
I am not sure how to do the same with only SDK/Client side code.
If you are willing to write something in your transaction processing logic, there is a method ChaincodeStubInterface.GetTxTimestamp() in the github.com/hyperledger/fabric/core/chaincode/shim package to get the time when the transaction is processed by the Fabric.
You could return the same to your SDK, and then to your external calling program. And then compute the +600 seconds and send the next transaction.
No, there is no way to automate a timed transaction from within the chaincode and it would be bad practice to try handle it there. If you try to create a timestamp from within the chaincode, it is guaranteed that all peers processing the transaction proposal will return different values as they do not all being processing the proposal at the same exact instance. Since the results sets will return non-deterministic, the transaction will always fail when it enters the validation phase. If you try to use stub.GetTxTimestamp() you will only be returning the timestamp that the client itself sent up, as per the docs.
The best way to do this is with pure sdk code. After acquiring requisite transaction proposals and sending the transaction for ordering, listen for a transaction commitment event.
Upon receiving notification of transaction commitment, you can queue up another transaction to be sent endorsement and commitment 600 seconds later. The specifics of how will differ from sdk to sdk, but all sdk's support notification of transaction commitment.
I'm aware that read query is a chaincode invocation which reads the ledger current state but does not write to the ledger.
The client app can choose to submit the read-only transaction for ordering, validation, and commit (for auditing purpose)
Question:
Is it possible to read the ledger db without going via the chaincode ?
What prevents someone on channel from directly reading CouchDB (assuming that is the underlying DB used) without using contracts and avoiding recording of reads
Fundamentally, we use an async communication in fabric. The node initiating transaction talks only with the peers synchronously and after that ordering service is initiated which will commit the txn to ledger after all verification check..
Is the following possible ?
node A submits a data to the ledger request for an operation -> which needs to be done by node B.
Is this possible for node A to notify B to check ledger and perform operation and B upon completion notify A to check the updated ledger ?
Is it possible to read the ledger db without going via the chaincode ?
What prevents someone on channel from directly reading CouchDB
(assuming that is the underlying DB used) without using contracts and
avoiding recording of reads
Nothing prevents you from doing it, if you have access to the database itself.
However, the clients usually don't have access to the database and thus the peer (through the chaincode) may enforce selective logic on which clients and what data can be read.
Think of an application server, a servlet container, etc.
The user that browses from the browser doesn't have access to the database the application server uses, right?
A similar thing takes place here.
Fundamentally, we use an async communication in fabric. The node
initiating transaction talks only with the peers synchronously and
after that ordering service is initiated which will commit the txn to
ledger after all verification check..
Strictly speaking, the ordering service does not commit the txn to the ledger, as the ordering service has no ledger. It packages transactions into blocks, then sends the blocks to peers. It is the peers that then validate and commit the block to their own ledgers.
Is this possible for node A to notify B to check ledger and perform
operation and B upon completion notify A to check the updated ledger ?
You need the client SDK to orchestrate all of these. User Chaincodes only run in the context of a client's request.
So, you can have a client perform an operation that submits a transaction, and then the client sends another transaction in which the chaincode checks the current ledger, etc.
According to architecture explained (http://hyperledger-fabric.readthedocs.io/en/latest/arch-deep-dive.html), ordering service collects transactions (RWSets) into block for distribution to committing peers. Then, committing peer validates endorsement policy and RWsets then apply the transaction to ledger.
To verify the transaction was succeeded, should client application wait until all committing peers returned "Success" event ? Or just need to verify only one "Success" event ?
To verify the transaction was succeeded, should client application
wait until all committing peers returned "Success" event ? Or just
need to verify only one "Success" event ?
Tanaka, that's a very good question!
The short answer is No.
The reason is that in contrast to existing popular blockchains, HLF has a unique transaction lifecycle which does:
A transaction is simulated on some endorser or a few endorsers
It is sent to the ordering service and is cut into some block
The block is sent to peers, and they all execute the same validation code and all validation code for a specific transaction is guaranteed to reach the same conclusion in all peers, because they run it in the same order across all of them.
Therefore, if a transaction is validated on some peer - when other peers will receive the block the transaction resides in - they will too consider it as valid.
However - a very important aspect you should consider is data availability and synchronization.
For example, if you have an application that uses 10 peers and only 1 peer got the event and the rest didn't, and you invoke another transaction on the other peers, it might be that the endorsements that the other peers will compute will be turned into an invalid transaction, because they will simulate on old data (the fact that they didn't get the event yet proves that they have not processed the block for that transaction), so you need to keep that in mind.