EOS dapp in exchange
Make Your Trade and Exchange More Simple and Secure With Out Remarkable EOS DApp Development Services.
Home
EOS DAPP in Exchange
EOS dapp in exchange
How EOS is different than Ethereum that it brings block time to 0.5 seconds? How is this possible since Ethereum's average block time is around ~12 seconds?
In EOS, each producer creates 6 consecutive blocks before handing off to the next producer. Therefore, in these 3 seconds (6 x 0.5), there is no latency to propagate blocks as they're created by the same producer. The latency is a problem during hand-off, so it's possible that the last few blocks or the next few blocks get orphaned, which is why there are plugins suggested to minimize latency by accounting for geographical location of BPs.
Currently Ethereum uses Proof-of-Work based mining algorithm "dagger-hashimoto" and in future going to change it to Proof-of-Stake based mining algorithm "casper" to select block producer who will sign next block.
Whereas EOS uses Delegated-Proof-of-Stake based algorithm, in EOS, token holders vote to choose 21 block producers(There might be certain requirements here ex. certain amount of EOS token locked). Only these 21 chosen block producers will sign blocks on behalf of all EOS users.
Given above conditions block time in EOS will drastically reduced given only 21 block producers exists, whereas in Ethereum it is open that any one mining in network can theoretically be a block producer, so fixing block time to 15 seconds is design decision. If block time in Ethereum is reduced more orphan blocks will be produced and it will be difficult to chose longest chain.
requirements
In order to gain widespread use, applications on the blockchain require a platform that is flexible enough to meet the following requirements:
SUPPORT MILLIONS OF USERS
Competing with businesses such as eBay, Uber, AirBnB, and Facebook, require blockchain technology capable of handling tens of millions of active daily users. In certain cases, an application may not work unless a critical mass of users is reached and therefore a platform that can handle very large numbers of users is paramount.
FREE USAGE
Application developers need the flexibility to offer users free services; users should not have to pay in order to use the platform or benefit from its services. A blockchain platform that is free to use for users will likely gain more widespread adoption. Developers and businesses can then create effective monetization strategies.
Easy Upgrades and Bug Recovery
Businesses building blockchain based applications need the flexibility to enhance their applications with new features. The platform must support software and smart contract upgrades.
LOW LATENCY
A good user experience demands reliable feedback with a delay of no more than a few seconds. Longer delays frustrate users and make applications built on a blockchain less competitive with existing non-blockchain alternatives. The platform should support low latency of transactions.
SEQUENTIAL PERFORMANCE
There are some applications that just cannot be implemented with parallel algorithms due to sequentially dependent steps. Applications such as exchanges need enough sequential performance to handle high volumes. Therefore, the platform should support fast sequential performance.
PARALLEL PERFORMANCE
Large scale applications need to divide the workload across multiple CPUs and computers.
Consensus Algorithm (BFT-DPOS)
EOS.IO software utilizes the only known decentralized consensus algorithm proven capable of meeting the performance requirements of applications on the blockchain, Delegated Proof of Stake (DPOS). Under this algorithm, those who hold tokens on a blockchain adopting the EOS.IO software may select block producers through a continuous approval voting system. Anyone may choose to participate in block production and will be given an opportunity to produce blocks, provided they can persuade token holders to vote for them.
The EOS.IO software enables blocks to be produced exactly every 0.5 second and exactly one producer is authorized to produce a block at any given point in time. If the block is not produced at the scheduled time, then the block for that time slot is skipped. When one or more blocks are skipped, there is a 0.5 or more second gap in the blockchain.
Using the EOS.IO software, blocks are produced in rounds of 126 (6 blocks each, times 21 producers). At the start of each round 21 unique block producers are chosen by preference of votes cast by token holders. The selected producers are scheduled in an order agreed upon by 15 or more producers.
If a producer misses a block and has not produced any block within the last 24 hours they are removed from consideration until they notify the blockchain of their intention to start producing blocks again. This ensures the network operates smoothly by minimizing the number of blocks missed by not scheduling producers who are proven to be unreliable.
Under normal conditions a DPOS blockchain does not experience any forks because, rather than compete, the block producers cooperate to produce blocks. In the event there is a fork, consensus will automatically switch to the longest chain. This method works because the rate at which blocks are added to a blockchain fork is directly correlated to the percentage of block producers that share the same consensus. In other words, a blockchain fork with more producers on it will grow in length faster than one with fewer producers, because the fork with more producers will experience fewer missed blocks.
Furthermore, no block producer should be producing blocks on two forks at the same time. A block producer caught doing this will likely be voted out. Cryptographic evidence of such double-production may also be used to automatically remove abusers.
Byzantine Fault Tolerance is added to traditional DPOS by allowing all producers to sign all blocks so long as no producer signs two blocks with the same timestamp or the same block height. Once 15 producers have signed a block the block is deemed irreversible. Any byzantine producer would have to generate cryptographic evidence of their treason by signing two blocks with the same timestamp or blockheight. Under this model a irreversible consensus should be reachable within 1 second.
