I run a private network of 6 nodes using substrate node-template v3.0.0. During tests, I noticed a difference between "submitted" and "finished" transactions when sending at a constant transaction rate to the blockchain.
I have sent valid transactions (picture) and there is very big difference between "submitted" and "finished" transactions, what does "submitted" and "finished" transactions actually mean ?
Prometheus queries are respectively:
substrate_sub_txpool_submitted_transactions
substrate_sub_txpool_validations_finished
Also there aren't any invalid transactions.
Related
I am new to blockchain and learning about bitcoin & blockchain. As I understood that miners discovered new BLOCK and get the rewards as bitcoin and these BLOCKS are used to keep record of various transactions.
I also learned that there is a cap on max number of bitcoins (21 million) can be mined. This means there won't be any BLOCK left to record any new transaction. Does it mean that once all bitcoins are mined the blockchain will not be operational and no further transactions can be done.
No, after the completion of the bitcoin emission, miners will receive a reward from the fee for each transaction included in the block. This fee will need to be included in transactions.
Is there any statistics on number of successful transactions comparing to number of sent transactions to the Ethereum main network?
In my own experience of sending bunch of transacitons (by Go), I could see that something like 20% of transactions which primarily is pending on Ethereum network will not become successful (same happens when I am using Ethereum wallet).
I want to know whether I should modify my code (e.g. gas price) or this successful ratio is something normal for the Ethereum transactions.
You can write a simple application using etherscan api, but remember they have a limit for how many transactions you can do in a given span of time.
I'm going through the documentation on Hyperledger Fabric, and there's a portion in the introduction that writes:
"Hyperledger Fabric assigns network roles by node type. To provide concurrency and parallelism to the network, transaction execution is separated from transaction ordering and commitment. Executing transactions prior to ordering them enables each peer node to process multiple transactions simultaneously."
Maybe this is some fundamental misunderstanding on my part about the structure of the network and the different functions and mechanics of nodes, but how can one execute a transaction prior to ordering one?
Within a Hyperledger Fabric network, transactions start out with client applications sending transaction proposals, or, in other words, proposing a transaction to endorsing peers.
Each endorsing peer simulates the proposed transaction, without updating the ledger. The endorsing peers will capture the set of Read and Written data, called RW Sets.
These RW sets are then signed by the endorsing peer, and returned to the client application to be used in future steps of the transaction flow. Endorsing peers must hold smart contracts in order to simulate the transaction proposals.
The application then submits the endorsed transaction and the RW sets to the ordering service. Ordering happens across the network, in parallel with endorsed transactions and RW sets submitted by other applications.
The ordering service takes the endorsed transactions and RW sets, orders this information into a block, and delivers the block to all committing peers.
The committing peer validates the transaction by checking to make sure that the RW sets still match the current world state.
Committing peers are responsible for adding blocks of transactions to the shared ledger and updating the world state.
Here, you have the roles that there are in Hyperledger Fabric:
Endorser Peers: they receive a transaction. Then, they execute the transaction against the Smart Contrat and they sign the result. They send the transaction signed to the peer that has sent it.
Committer Peers: the Peers get the Blocks (with the validates transactions) and commit them to its ledger.
Orderes: nodes that sort the transactions and generate the blocks.
I take this info from an answer that I write for a question.
I am trying to send a transaction.
eth.sendTransaction({from: eth.accounts[0], to: eth.accounts[1], value: web3.toWei(5, "ether")})
eth.sendTransaction({from: eth.accounts[0], to: eth.accounts[1], value: web3.toWei(5, "ether")})
INFO [08-25|21:14:21] Submitted transaction
fullhash=0xe1b58ddcb6d8c3f3a8308e0eb275f10c0c3b7bd8807cd24ff6a315a3917ab2a5
recipient=0x939f34bc9253a62927871c889bcf62f398d264a6 INFO
[08-25|21:14:29] Submitted transaction
fullhash=0x33ca6bb00a70de13bd8b1fdec5d0a7995ad09a90e416ac8ab686fc650a324331
recipient=0x939f34bc9253a62927871c889bcf62f398d264a6 INFO
[08-25|21:14:57] Updated mining threads threads=1
INFO [08-25|21:14:57] Transaction pool price threshold updated
price=18000000000 INFO [08-25|21:14:57] Starting mining operation
INFO [08-25|21:14:57] Commit new mining work
number=1 txs=2 uncles=0 elapsed=73.574ms
But when i run
eth.pendingTransactions
i am able to see the list of above sent transactions
SO my question is
When will the transactions be mined?
P.S.- i am running it on my local machine(private blockchain)
Thanks in advance :)
If you are using private blockchain then you can run miner.start() function using the console. After that it will take 5-6 min and miner will be ready to pick your transaction and automatically coinbase account balance will be increased.
Some time if you send very less gas and gasprice with your transaction with your transaction then may be transaction gets stuck. So please send enough gas with your transaction. It will get executed.
You can also send gas and gasprice in your command as below--
eth.sendTransaction({from: eth.coinbase, to: "0x154230ed91d1e711e56b9c0f88b5ba5fd2bghjgf", value: web3.toWei(5, "ether"),gas:21000,gasPrice:web3.toWei(45,"wei")})
Hope this will help
I have been reading the documentation on how HyperLedger Fabric's project is implementing a open source BlockChain solution: https://github.com/hyperledger/fabric/blob/master/docs/protocol-spec.md
I have seen that PBFT consensus algorithm is used, but I do not understand how blocks are mined and shared among all Validating Peers in the BlockChain network.
Hyperledger Validating Peers (VPs) do not mine blocks and do not share the blocks between them. Here is how it works:
A transaction is send to one trusted VP.
The VP broadcasts the transaction to all other VPs.
All VPs reach consensus (using PBFT algorithm) on the order to follow to execute the transactions.
All VPs execute the transactions "on their own" following the total order and build a block (calculating hashes mainly) with the executed transactions.
All the blocks will be the same because: the transaction execution is deterministic (should be) and the number of tx in a block is fixed.
According to Hyperledger Fabric 1.X
User through Client SDK send the transaction proposal to Endorsing Peers.
Endorsing Peer check the transaction and make endorsement proposal of transaction(with read/write set (previous value/Changed value)) and send to again client SDK.
Client SDK wait for all endorsement, once it get all endorsement proposal it make one invocation request and send to Orderer.
Orderer verify invocation request rent by client SDK by checking Policies defined(Consensus), verify the transaction and add to the block.
According to configuration defined for block, after specified time or number of transaction it form a Hash of block by using transaction hash, metadata and previous block hash.
The blocks of transactions are “delivered” to all peers on the channel by the Orderer.
All committing peers verify the endorsing policy and ensure that there have been no changes to ledger state for read set variables since the read set was generated by the transaction execution. After this all the transactions in the block and update the ledger with new block and current state of asset.
Ledger Contains
1) Current state Database(Level BD or Couch DB)
2) Blockchain(Files)(Linked blocks)
Read the transaction flow of hyperledger fabric
Check image for reference
Hyperledger is an umbrella of blockchain technologies. Hyperledger Fabric, mentioned above, is one of them. Hyperledger Sawtooth also does not use mining and adds these consensus algorithms:
PoET Proof of Elapsed Time (optional Nakamoto-style consensus algorithm used for Sawtooth). PoET with SGX has BFT. PoET Simulator has CFT. Not CPU-intensive as with PoW-style algorithms, although it still can fork and have stale blocks . See PoET specification at https://sawtooth.hyperledger.org/docs/core/release s/latest/architecture/poet.html
RAFT Consensus algorithm that elects a leader for a term of arbitrary time. Leader replaced if it times-out. Raft is faster than PoET, but is not BFT (Raft is CFT). Also Raft does not fork.
With unpluggable consensus, another consensus algorithm can be changed without reinitializing the blockchain or even restarting the software.
For completeness, the original consensus algorithm with bitcoin (and does use mining) is:
PoW Proof of Work. Completing work (CPU-intensive Nakamoto-style consensus algorithm). Usually used in permissionless blockchains