Hyperledger Fabric metrics (https://hyperledger-fabric.readthedocs.io/en/latest/metrics_reference.html) has three metrics:ledger_block_processing_time, ledger_blockstorage_commit_time and ledger_statedb_commit_time. My questions are:
What does ledger_block_processing_time mean in terms of business? Does it refer to the process of putting multiple transactions into a block by orderer?Does it include subsequent process in which blocks are submitted by peers?
ledger_blockstorage_commit_time and ledger_statedb_commit_time look similar, what is the difference between them?
Thank you.
For Q 2:
The ledger has 2 parts, first is the actual blockchain/blockstorage, and the second is stateDB, which represents the current world-state. First metrics is commit time in blockstorage, second one is commit time in stateDB.
Related
I am currently participating in the hyperledger fabric project.
The concept of hyperledger fabric is still insufficient. I understand that the transaction is stored in the block. The transaction knows that the chaincode is executed.
For example, suppose you executed send chaincode. Suppose A sends 500 to B with A = 1000 and B = 1000. It will be A = 500 and B = 1500. Suppose this is TxId = AAA.
I want to see AAA's history of "A sent 500 to B" in this situation. Mychannel.block and mychannel in the channel-artifact directory created by running the current network.I tried to decode tx to json file.
However, it was found that there was no content related to this. Is there any way I can see the contents of TxId=AAA?
Decode .tx and .block file. but I didn't get what I wanted.
If you want to see the history of transactions, you can use the ctx.stub.getHistoryForKey(id) function, where the id parameter is a record key. This is the Node.js SDK method, I expect that it is similarly named for Java and Go. I think that the information that you require should be held in the contract, as the history only returns the different contract versions over time. If you want to see that A transacted with B, you would need the contract code to show that funds came from A and landed with B during the transfer. Depending on implementation, this might require a cross-contract call to a different contract (one containing clients A and B) so that 500 could be taken from Account A's fund and added to Account B's fund. In this scenario (if we are talking about a sale), the AssetTransfer contract could show the change of ownership, whereas the client contract will show 2 updates, one where A's fund decreases by 500 and another where B's fund increases by 500.
In the scenario above, there are now three updates that have history i.e. an asset sale, which you don't mention, but I am using as an example which will have a change of ownership history. A client A, whose fund record will have decreased, and a client B, who will have a corresponding increase in funds. Therefore, it's not a block history that you require, but a history of the Client records for A and B. Even if you only had a single contract e.g. (Client), and you exchanged funds, you will still have two updates, one for A and the other for B. It's the records within the contract code that change. The block is the manifestation of the entire transaction i.e. all rules have been satisfied by the different peers and whatever concensus policy is in place.
In fabric, if two transactions in a block conflicted(eg, two users try to buy an asset almost at the same time) ,then these two will not be committed to the ledger, or just the last one will not?
Only one is going to be successfully committed (the first one as ordered by the ordering service), as the version of the read set of the second transaction is not going to match the expected one.
Is very well explained in: https://medium.com/#arora.aditya520/chaincode-writing-best-practices-hyperledger-fabric-43d2adffbeec
I configured my Hyperledger Fabric network with 2 peers under 1 org and 2 couchdb, 1 each peer.
I am seeing that when I do a transaction, it takes some time to do it, sometimes around 1 second. For me it's too much time, it should be just some ms.
I have a simulator that is able to insert around 30k samples into the blockchain but it runs very slow because sometimes a transaction takes 1s, so you can imagine that with a such amount of data it takes a lot.
How can I solve this? Is Fabric able to handle more transaction than this?
What I have noticed and it seems wrong to me is that:
Using Fauxton to see inside couchdb, if I upload 300 samples on the blockchain, I see 300 blocks created. Could this be a problem? I know that a block should encapsulate more transaction, but my blockchains seems not to do this. How to solve?
Another thing that I have noticed is that I did not configure any endorsment policy. Should I do it and should it make it faster? How to do this?
And, finally: there is the possibility that couchdb is slowing down the network? How to disable it?
Two hidden complexities can impact performance
The complexity of your query, per record type. It’s important to form a performance histogram based on object types
Whether your data structure is pre-ordered to suiting the hashing algorithm. If not, you’ll experience a slight bit for drag if you object size is large.
In a Hyperledger Fabric network, ledgers which all peers(endorsing peers and committing peers) have are replicated ledgers.
It seems to imply there is a unique 'real/original/genuine' ledger per channel.
I'd like to ask these:
Is there a real ledger? If so, where is it(or where is it defined?) and who owns it?
Those replicated ledgers are updated by each peer, after VSCC, MVCC validation. Then who updates the 'real' ledger?
Does 'World State' only refers to the 'real' ledger?
I'd really appreciate if you answer my questions.
Please tell me if these questions are clarified to you. Thank you!
I don't understand what exactly you mean by 'real' ledger. There is one & only ledger per channel, replicated across all participants per channel. When I say participants, I mean all peers (both endorsing & committing) of an organization's MSP belonging to a given channel.
State DB (a.k.a World state) refers to the database that maintains the current value of a given key. Let me give you an example. You know that a blockchain is a liked list on steroids (with added security, immutability, etc). Say, you have a key A with value 100 in Block 1. You transact in the following manner.
Block 2 -- A := A-10
Block 15 -- A := A-12
.
.
.
Block 10,000 -- A := A-3
So, after Block 10,000, if you need the current value of key A, you have to calculate the value from Block 1. So to manage this efficiently, Fabric folks implemented a state database that updates the value of a key in the state after every transaction. It's sole responsibility is to improve efficiency. If your state gets corrupted, Fabric will automatically rebuild it from Block 0.
I believe the answer is no but I'd like confirmation.
With Fabric, endorsers simulate the transaction upon latest state and prepare the proposal adding the read and write set of keys.
At the commit phase, the peer will receive a block from the ordering service and the write set update is only applied if the read set has not been updated (versioning check).
So for the same block, the same key cannot be updated by 2 different transactions of the same block.
If it is the case, aggregating value and maintaining balance on-chain might be problematic for frequent transactions use-case. Such operation should be left for off-chain application layer.
So for the same block, the same key can not be updated by 2 different transactions of the same block.
The above is correct. Hyperledger Fabric uses an MVCC-like model in order to prevent collisions (or "double spend"). You'll want to wait for the previous state change transaction to commit before attempting to update the state again.