I am new to blockchain and have a question about its transaction verification process. I have read some articles related to Bitcoin. They said it takes about 10 minutes to verify a bitcoin transaction. Does this mean if I purchase a bitcoin I have to wait 10 minutes for this transaction? If yes, how can I handle the real-time system requirement in the blockchain?
They said it takes about 10 minutes to verify a bitcoin transaction.
Does this mean if I purchase a bitcoin I have to wait 10 minutes for
this transaction?
Yes if your transaction was lucky enough (or expensive enough) to make it into the next block. Since Bitcoin's 10-minute blocks hold a finite number of transactions, you might need to wait longer than that if your transaction wasn't included in the upcoming block.
On top of that, once your transaction is on the blockchain, you should ideally wait until several more blocks are mined until you're confident that your transaction got included in the globally-accepted branch (the longest branch).
So, to be safe, if you decide to wait for 6 blocks after your transaction is included, you'd end up waiting an additional hour until you're relatively confident that your transaction has been accepted.
If yes, how can I handle the real-time system requirement in the
blockchain?
That's one challenge that Bitcoin hasn't overcome yet. The closest work-in-progress solution is the Lightning Network, but that's still in development.
In the meantime, some applications might decide to process real-time transactions off-chain by accepting transactions before they're included in the blockchain. But this is a risky trade-off; you'd allow fast transactions at the cost of security, opening yourself up to double-spending.
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.
I'm doing an ad server (sort of RTB), there are advertisers who pay to promote their ad campaigns.
When the user watched the ad I want to charge the advertiser.
Ad campaigns should participate in auctions without blocking, means he can bid for multiple ad requests at the same time. It would make it difficult to charge advertiser immediately since I'll have to block his balance.
Another approach is to not charge him immediately, but in the separate process once every N seconds, and hope so he didn't buy more impressions than he can afford. I can make some sort of threshold credit he should have to participate in auctions, it would eliminate most of the overruns but what if the process is exited and the advertiser wasn't charged and overrun a lot, that would be a problem.
Can someone please advise me how these things are usually handled, maybe recommend some book/article on the topic, please?
If this is a problem of asynchronous programming, meaning that you are concerned about overcharging a bidder when they place too many impression bids at once. Then I suggest using a mutex (i.e. locking system). You can set a threshold on the number of locks a bidder can have in your system at any given time. This threshold can be equivalent to the maximum amount the bidder is willing to spend on impressions. When the bidder requests a bid a lock for that bid on his account should be sent to your server. When the server responds with the ok response that the lock has been created, then the bid can take place. The bid is active until the lock is released by your server. This makes it so the server keeps track of all the bids and places locks on all of them. If the bidder has a threshold of 10 bids and he tries to make a bid for the 11th the server will not release a lock to the bidder to make this bid. Furthermore, if you are using a microservice architecture I suggest making a transaction manager service to handle all these requests and even use Saga based transactions for rollback functionally in case of a server failure.
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 am new to blockchain technology and have a basic question.
I understand that in any blockchain network, if any node tries to commit something which is not in sync with other nodes , it gets rejected.Then how the new transaction is commited and validated? Who has authority to do it.
That's the thing about blockchain. There is no authority that determines which block will get added to the chain. And by blockchain, I mean public blockchain.
Blockchain's typically are either public or permissioned.
Public
Public blockchain's, such as bitcoin and ethereum work on the principle of proof of work. In layman's terms, if any participant wants there transaction to be processed, i.e added to the chain, they submit it to the network. This transaction is then processed by independent entities called miners who have to solve a computational puzzle in order to produce a valid block, which if accepted results in compensation in form of the said digital currency for the work put in by the miner. Also, the longest chain is always accepted as the valid chain.
There is absolutely no criteria or organisation that overlooks mining, meaning anybody can become a miner and start contributing. So the network is for the people, by the people, anybody can join and both submit as well as process transactions.
If the transaction is valid, that is you own the coin and are not double spending it, it will be processed by a miner. And if the block produced by the miner is accepted, so is your transaction.
Private/Permissioned
On the other hand, in case of private/permissioned blockchain's like hyperledger fabric for example, participation and block processing is decided by a single or multiple organisations. Hence in this case, a block is processed only if it produced by a valid member and it is endorsed by nodes of all participating organizations.
As you said "if any node tries to commit something which is not in sync with other nodes" what I get is that you are asking about the block which one node produce but rejected by the blockchain. This scenario happens when 2 nodes try to find the proof of work and one node finds it first and broadcast to the network but due to network delay (there could be other reasons too for that), and the other node didn't get the block in this way stale/uncle blocks are created. Bitcoin blockchain considers the longest blockchain and discards the other.
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