Share and get +16 +16



Social Media and forums are buzzing with news about EOS, and for very good reasons. Their year-long ICO smashed all the records by collection a staggering $4 billion. Plus, all the drama surrounding their mainnet release has definitely put them under the spotlight. EOSIO Dawn 4.0 brought along a lot of interesting innovations and talking points. In this guide, we are going to do a deep dive of all these interesting features.

So what is EOS?

EOS are aiming to become a decentralized operating system which can support industrial-scale decentralized applications.

That sounds pretty amazing but what has really captured the public’s imagination is the following two claims:

They are claiming to have the ability to conduct millions of transactions per second.

They are planning to completely remove transaction fees.

So, how are they planning to bring along all these innovations? You can check out our in-depth guide to get all the details, however, we will glance over them briefly here.

The Team Behind EOS

Image Credit: Medium

The core team behind EOS is “Block.one”, which is based in the Cayman Islands. Brendon Blumer, the CEO, has been involved in blockchain since 2014. He has previously been involved in companies which dealt with currency exchanges in MMORPGs and in the real estate.

Dan Larimer, is the CTO. He is the creator of delegated proof-of-stake and decentralized autonomous organizations aka DAOs. He is the also the man behind BitShares and Steem.

Now that we know about the team behind the project, let’s look at how it plans to achieve its two biggest claims.

Millions of Transactions per Second

EOS achieves its scalability via the utilization of the delegated proof-of-stake (DPOS) consensus mechanism, which is a variation of the traditional proof-of-stake.

This is how traditional proof-of-stake (POS) works:

The validators participate by locking up some of their coins as stake.

After that, they will start validating the blocks. Meaning, when they discover a block which they think can be added to the chain, they will validate it by placing a bet on it.

If the block gets appended, then the validators will get a reward proportionate to their bets.

So, how is DPOS different from traditional POS?

Firstly, anyone who holds tokens on a blockchain integrated into the EOS software can select the block producers through a continuous approval voting system. Anyone can participate in the block producer election and they will be given an opportunity to produce blocks proportional to the total votes they receive relative to all other producers.

How does it work?

Blocks are produced in the rounds of 21.

At the start of every round 21 block producers are chosen. Top 20 are automatically chosen while the 21st one is chosen proportional to the number of their votes relative to the other producers.

The producers are then shuffled around using a pseudorandom number derived from the block time. This is done to ensure that a balance connectivity to all other producers is maintained.

To ensure that regular block production is maintained and that block time is kept to 3 seconds, producers are punished for not participating by being removed from consideration. A producer has to produce at least one block every 24 hours to be in consideration.

The DPOS system doesn’t experience a fork because instead of competing to find blocks, the producers will have to co-operate instead. In the event of a fork, the consensus switches automatically to the longest chain.

Removing Transaction Fees

EOS works on an ownership model whereby users own and are entitled to use resources proportional to their stake, rather than having to pay for every transaction. So, in essence, if you hold N tokens of EOS then you are entitled to N*k transactions. This, in essence, eliminates transaction fees.

The costs of running and hosting applications on Ethereum can be high for a developer who wants to test their application on the blockchain. The gas price involved in the early stages of development can be enough to turn off new developers.

The fundamental difference between the way Ethereum and EOS operate is that while Ethereum rents out their computational power to the developers, EOS gives ownership of their resources. So, in essence, if you own 1/1000th of the stake in EOS then you will have ownership of 1/1000th of the total computational power and resources in EOS.

As ico-reviews states in their article:

“EOS’s ownership model provides DAPP developers with predictable hosting costs, requiring them only to maintain a certain percentage or level of stake, and makes it possible to create freemium applications. Furthermore, since EOS token holders will be able to rent / delegate their share of resources to other developers, the ownership model ties the value of EOS tokens to the supply and demand of bandwidth and storage.”

So, these two are the biggest USP of EOS. Now that we have gained a bit of understanding of what EOS plans to do, let’s look at some of the features that Dawn 4.0 plans to bring along.

EOS Dawn 4.0

EOS Dawn 4.0 is the latest testnet version that was released by Block. One prior to the launch of their mainnet. There are a lot of interesting talking points that have come to light thanks to the launch. One of the biggest changes that Dawn 4.0 is bringing along is changing the current time from “time of head block” to “time of current block”. With this change, all time-related issues are rectified at once.

Along with that, some of the other exciting features that EOSIO is bringing along or improving upon are:

The RAM Marketplace

Future Parallelism DPOS

Header-only Validation

Block Producer Rewards

Vote Decay

Last Irreversible Block Algorithm

As you can imagine, there is a lot of content to cover and that’s why we felt it was prudent to split up this guide into two parts. That way, we can give your proper value without compromising because of content length. So, without any further ado, let’s begin!

#1 The RAM Marketplace

Like we have mentioned before when you stake your EOS tokens, you are entitled to own resources like RAM, Network Bandwidth, and CPU Bandwidth in return. So, in essence, not only can you use EOS tokens as a simple payment token, you can use it as a toll both which entitles you to certain resources. Having said that, these resources are very scarce and that is why you can only hold on to the EOS tokens, without using them, for a period of 3 years. Holders who use their tokens will get their account terminated.

Now, when it comes to resources like CPU and Network Bandwidth, the interchange is pretty straightforward. If you plan to sell them and take back your staked tokens, you will get exactly the same amount of tokens back.

However, when it comes to RAM, it is not that simple.

You see, even though these resources are scarce, RAM happens to be even more scarce and precious. Here’s the kicker, even though RAM is scarce, there is always going to be a high demand for RAM.

High performance and scalability are two of the hottest topics in the blockchain space. Because of this, RAM is an extremely powerful and critical resource for blockchains. Before we go any further, let’s acquaint ourselves with one of the most basic concepts in microeconomics, supply, and demand.

Basically, more the demand and lessen the supply, more will be the price of the product. The supply-demand graph looks sorta like this:

The sweet spot where both the curves intersect is the equilibrium.

So, let’s look at what we have here, a scarce asset which will always be high in demand. That is definitely going to affect the price, to be more exact, it will definitely increase the price of the asset, i.e. RAM.

However, in EOS, if you staked a certain amount of and obtained a proportionate amount of resources, you can sell them back and get the exact amount of staked tokens back. This is where we hit our first road bump. This mechanism won’t work economically for RAM.

Think about this, early EOS adopters will obviously get the RAM for pretty cheap, however as the network grows and more and more developers enter the blockchain to build their Dapps on top of it, the demand for RAM will shoot through the roof. Now, remember two things:

RAM is already a scarce resource, so the supply will be low.

With the increased demand, the price of RAM will go up.

In an ecosystem where the cryptoeconomics needs are perfectly aligned, early movers should be able to sell their RAM for an increased price, however, EOS until recently, treated RAM as any other resource.

Now, if you remember, EOS holders can’t just hold onto their tokens and do nothing for more than 3 years, so at one point, these people would have to sell their tokens and resources without having any economic incentive of doing so.

Along with this, another obstacle was recognized by Block.One. Various tests concluded that the way the EOSIO System Contract was allocating RAM to stakeholders would inevitably lead to shortages down the road.

A solution was needed.

Enter, the RAM Marketplace.

By utilizing the Bancor algorithm, EOSIO is using a market-based approach for RAM allocation. This is how it is going to work:

Suppose someone wants to buy or sell RAM, a 0.5% fee is going to be charged on both the buyer and seller’s side. By introducing this fee, it gives a proper economic incentive to RAM sellers. Plus, EOS also plans on curbing speculative marketing and inflation as the fees that are collected burnt.

Dan Larimer showed how the calculation will work on his medium post:

“Our math indicates that if 1TB of RAM was allocated on a pro-rata basis to token holders then the cost-per-byte would be $0.018 (assuming $20/token). The reality is that most token-holders don’t actually have an active need to use the RAM they might be entitled to; therefore, we are initially pricing RAM at $0.000018 per byte (assuming $20/token). New accounts require about 4KB of RAM which means they will cost about $0.10. As RAM is reserved the price will automatically increase so that the price approaches infinity before the system runs out of RAM.”

Note: He was working with a 1% fee on both seller and buyer side in his calculations and not 0.5%.

Also keep in mind, the other problem that Block.One wanted to solve was the availability problem. A marketplace will go a long way in making sure that there is a steady availability of RAM. The price of RAM will also be based on the currently available supply and it will be set by the system.

The marketplace also introduces another way to curb speculation. Any block producer can simply add more RAM to the marketplace and increase the supply. With the increased supply the value of RAM will go down.

Future Expansion

In order to understand how an asset will behave in the long run, one must know about the Moore’s law. According to Investopedia:

“Moore’s law refers to an observation made by Intel co-founder Gordon Moore in 1965. He noticed that the number of transistors per square inch on integrated circuits had doubled every year since their invention. Moore’s law predicts that this trend will continue into the foreseeable future. Although the pace has slowed, the number of transistors per square inch has since doubled approximately every 18 months. This is used as the current definition of Moore’s law.”

According to Larimer, in accordance with Moore’s law, EOS block producers should be able to upgrade to 4TB or even 16TB of RAM. This increase in supply will decrease the price of RAM in the marketplace

#2 Future Parallelism

One of the more interesting features that EOSIO Dawn 4.0 hopes to bring along is parallelism. Scalability is the name of the game nowadays, and everyone who is anyone in the crypto-community is knee deep in research.

EOSIO realized that for their Dapps to scale properly, they need to maximize their RAM usage. An intriguing way that they are approaching this is by using side chains with independent memory regions.

Sidechains

Sidechain as a concept has been in the crypto circles for quite some time now. The idea is very straightforward; you have a parallel chain which runs along with the main chain. The side chain will be attached to the main chain via a two-way peg

The EOS developers are planning to use side-chains to kill two birds with one stone:

To scale up

To create a sense of competition between the side chains.

So, how is this going work?

The EOS block producers work on the side-chain of their choice and use the token to buy RAM from the side-chain. The side-chains will follow the governance protocols that have been laid down by the main EOS blockchain. Each of these sidechains can potentially have >1 TB of their own RAM.

NOTE: Dan Larimer said the following his Medium Post:

“Some community members expressed concern that some people will derive unjustified profits by buying up cheap RAM before anyone else can get on the chain. To mitigate this, we recommend that those who launch a chain start out with a very limited supply of RAM and then gradually increase the RAM over the first couple of months. If the RAM supply starts out at 32GB and then grows to 1TB over a period of months then the price of RAM may rapidly drop over time to 3% of its initial pricing. Only those who really need RAM or who factor in future RAM supply when bidding will buy the initial RAM. Either way, no one will get “cheap” RAM or “free profits”. “

These sidechains will gain interoperability by having the ability to “talk” to each other via Inter-Blockchain Communication (IBC). Using IBC, Daps will have the ability to buy unused RAM from the other sidechains, which will result in the scaling of RAM usage.

Now remember how we said that EOS is also planning to integrate a sense of competition between all these sidechains? Want to know how it achieves that?

The price of RAM is not fixed across all the side chains. So, a Dapp developer can choose to operate on a sidechain where they are getting the cheapest RAM. This will help incentivize the sidechains to offer the best value proposition.

Inter Blockchain Communication (IBC)

Block.One firmly believes that upgrading from a single-threaded execution to a multi-threaded one is the path to scalability. In order to do so, a new chain with multi-threaded support executed by the same block producers needs to be launched. By doing so, ay number of tests and upgrades can be done to the new chain without any risks to the live main chain.

This is why IBC is so critical. It will allow these chains to communicate with each other and lay down the foundations for exponential scalability. It will enable EOS to scale the use of all its available resources.

In order to understand how it works, you should be clear about Merkle Roofs.

What is a Merkle Tree?

Image Courtesy: Wikipedia

The above diagram shows what a Merkle tree looks like. In a Merkle tree, each non-leaf node is the hash of the values of their child nodes.

Leaf Node: The leaf nodes are the nodes in the lowest tier of the tree. So wrt the diagram above, the leaf nodes will be L1, L2, L3, and L4.

Child Nodes: For a node, the nodes below its tier which are feeding into it are its child nodes. Wrt the diagram, the nodes labeled “Hash 0-0” and “Hash 0-1” are the child nodes of the node labeled “Hash 0”.

Root Node: The single node on the highest tier labeled “Top Hash” is the root node.

So what does a Merkle Tree have to do with blockchains?

Each block contains thousands and thousands of transactions. It will be very time inefficient to store all the data inside each block as a series. Doing so will make finding any particular transaction extremely cumbersome and time-consuming. If you use a Merkle tree, however, you will greatly cut down the time required to find out whether a particular transaction belongs in that block or not.

Let’s see this in an example. Consider the following Merkle tree:

Image courtesy: Coursera

Now suppose I want to find out whether this particular data belongs in the block or not:

Instead of going through the cumbersome process of looking at each individual hash and seeing whether it belongs to the data or not, you can simply track it down by following the trail of hashes leading up to the data:

Doing this significantly reduces the time taken.

Back to IBC

So, as we have seen, Merkle Trees are a very useful indicator of showing proofs of user actions to lightweight clients (via Merkle Roots). In IBC, one blockchain acts as a lightweight client to the other. Imagine there are two chains A and B. If Chain A accepts and logs in a transaction, then by using IBC, Chain B can confirm the occurrence of that event. It does so by receiving messages from Chain A and following its block headers and processing all the Merkle proofs. The proofs have certain sequence numbers which Chain B can use to make sure that there have been no gaps in processing.

IBC involves validation of Merkle proofs from both the chains, which are 1KB+ in size and involve loads of cryptographic hash functions and/or >15 signature verifications. As such, the cost of validation for one single IBC 15X and sometimes even 30X higher than that or normal transactions.

Now you are probably wondering, the whole point of doing this was to scale up, however, this doesn’t really seem pretty scalable now, does it? Thankfully, it turns out that these proofs are pretty simple to parallelize since they are independent of blockchain state.

Instead of the state, EOS generates Merkle tree over sequenced action, in other words, instead of going through each individual actions, a light client can simply check to see the completion and verification of each proof.

Think of it like this. Suppose you have a huge account balance sheet in front of you. Instead of painstakingly going through the details of each and every transaction all you are checking is whether the transaction went through or not.

Since this means that IBC’s are only effective when one can guarantee the completeness and order of the transactions, the EOS protocol has created a TCP like communication channel between the chains. Using this simple innovation one can easily detect missing and out of order proofs. To prove completeness to the exact present moment, one must generate a transaction and then get a proof to show that the transaction was confirmed with the proper sequence number.

Regarding parallelization, Dan Larimer said,

“Under EOSIO Dawn 3.0 we made a lot of design decisions around the potential for future multi-threaded WASM execution. Unfortunately, until you actually implement a full multi-threaded implementation it is impossible to know whether we have all the corner cases covered. This means that EOSIO Dawn 3.0 had a lot of architecture complexity that was not giving any immediate benefit.”

Basically, a lot of things are needed to be ironed out for this to be fully effective.

#3 Header Only Validation

The last feature that we are going to be covering in this part is “Header Only Validation.” Earlier it was impossible to validate a single block-header without using the whole block. As you can imagine, this ate up a lot of unnecessary time and resources.

To speed up the process and make it more efficient, EOS Dawn 4.0 will now support header-only validation. This feature is extremely important because:

Allows block propagation across the network without waiting for full verification through each node.

Allows simple IBC execution

Prevents a lot of attack vectors

We will continue with the rest of the updates in part 2!



