Bookmark EOS: the dawn is here.
This post marks the first in a new EOS series I am starting in an effort to provide some easy to read instructions covering topics I found online, particularly vast and hard to get started.
In this post, we are going to cover a basic overview of EOS. But if you want to get your hands dirty, then you can go here . Also, I am working on stress-testing Quorum network, EOS, HyperLedger Fabric. I have stress-tested Quorum and the results are out.
Stay tuned and follow me to get the updates in next few posts.
But for now, let’s get started.
Introduction: The Dawn is here…
EOSIO is one of the blockchain platforms,(well, one of the best) on which you can write dapps like in ethereum(actually, it’s ethereum on steroids). But it’s a bit different from it.
It uses C++ as programming language for smart contract development, which makes it much easier to get started and also supports much complicated operations that solidity(ethereum’s contract language).
Also, it’s the only blockchain which has blocktime of less than a second: 0.5 sec! when you listen about EOS blocktime
The best part is that it’s one of the only blockchains who have demonstrated high performance in public. Steemit (a social blogging platform) and Bitshares (decentralized crypto-currency exchange)are based on a slightly different version of EOS platform.
Well, this is enough of praise…let’s get back to work. get back to work!
EOSIO comes with a number of programs.
But there are 3 core components: basic architecture of EOS nodeos – server-side blockchain node component. cleos – command line interface to interact with the blockchain and to manage wallets. keosd – component that manages EOSIO wallets.
Let’s break down them a bit. Nodeos
The core EOSIO daemon that can be configured with plugins to run a node. It is responsible for running your node and interacting with the EOS blockchain by creating blocks. Cleos
The command line tool that interfaces with the REST API exposed by nodeos. In order to use cleos you will need to have the end point (IP address and port number) to a nodeosinstance and also configure cleos to load the ‘eosio::chain_api_plugin’.
cleos contains documentation for all of its commands. For a list of all commands known to cleos, simply run it with no arguments: $ cleosCommand Line Interface to EOSIO ClientUsage: ./cleos [OPTIONS] SUBCOMMAND -h,–help Print this help message and exit -H,–host TEXT=localhost the host where nodeos is running -p,–port UINT=8888 the port where nodeos is running –wallet-host TEXT=localhost the host where keosd is running –wallet-port UINT=8888 the port where keosd is running -v,–verbose output verbose messages on errorSubcommands: create Create various items, on and off the blockchain get Retrieve various items and information from the blockchain set Set or update blockchain state transfer Transfer token from account to account net Interact with local p2p network connections wallet Interact with local wallet benchmark Configure and execute benchmarks push Push arbitrary transactions to the blockchain Keosd
An EOSIO wallet daemon that loads wallet related plugins, such as the HTTP interface and RPC API.
Let’s talk a bit about some tools available in EOSIO… Tools Launcher
The launcher application simplifies the distribution of multiple nodeos nodes across a LAN or a wider network.
It can be configured via CLI to compose per-node configuration files, distribute these files securely amongst the peer hosts and then start up the multiple instances of nodeos. Eosiocpp
It’s main use comes in developing smart-contracts. It is used to generate ABI files and can also generate helper functions that serialize/deserialize the types defined in the ABI for the contract development. We will talk about it more in next article in which we will see how to write smart contracts in EOSIO .
Well, this was good. But, this is not only what makes EOS what it is. So, let’s talk about it’s consensus mechanism which powers the 0.
5 sec blocktime. Consensus mechanism (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.
Well, this is it for this post…In the next part, we will go into the wallet implementation of EOS, it’s structure and functioning which keeps the account secure and still allows flexibility. Stay tuned for that next part…
Want to learn more? Check out my previous articles .