In the bitcoin blockchain, a block is created every 10 minutes and the size limit of a block is 1 MB. This limits the total number of transactions possible in a particular period of time. As we know from our previous articles in the S-series, Ethereum has better throughput than Bitcoin, but it is limited by the block gas limit. Many different projects such as Plasma, Raiden and Lightning Network are trying to solve this problem, as explained in the previous part of this series. This article will take our discussion further, and talk about directed acyclic graph.

Directed Acyclic Graph (DAG)

Directed acyclic graph solves the issue of scalability by taking a totally different approach. There are no blocks and no concept of mining. In a directed acyclic graph, one transaction validates the other to get approved. So, instead of a miner validating all the transaction in a block as in the case of blockchain, each new transaction validates old transactions in DAG. Every new transaction adds to the security of the directed acyclic graph. This results in a graph like structure instead of a chain of blocks.

So, what is a directed acyclic graph ?

A directed acyclic graph is composed of vertices and edges. Vertices represent transactions. An edge is directed from the new transaction (child) to a transaction (parent) it has validated. The first transaction of the network is the Genesis transaction. A parent vertex will never validate a child vertex which makes the graph acyclic. Transactions that don’t have any child transactions are referred as tips.

The graph is directed and acyclic, and hence the name.

If there is a directed edge from transaction A to transaction B, then we could say transaction A directly approves transaction B. If the length of the path from A to B is more than one, we could say transaction A indirectly approves transaction B.

Directed acyclic graph is also based on peer-to-peer network similar to blockchain. In DAG, nodes are distributed throughout the world. Each of them maintain their own copy of the ledger. The transactions are added in a fraction of time in the network. Thus, the DAG network is asynchronous, which makes the system fast. In a directed acyclic graph, you can have a bunch of transactions in parallel and the degree of parallelism adapts dynamically to the current load.

In case of blockchain, the blocks are linked linearly. Their spacing in time and their size are optimized for near-synchrony among nodes. This leads to a cap on the block size which results in a cap on the throughput of the network. If we increase the block size as per traffic, it takes too long for a block to propagate to all nodes in the network. In such situations, there is greater uncertainty about which block is the last block to be added to the network. This leads to chain reorganisation, as discussed in the part one of S-trilogy. More resources are wasted on extending chains that would later be orphaned.

To understand the technology, we will go through two hot projects currently based on DAG – IOTA and Byteball. The mechanism behind these two projects will also help you understand how directed acyclic graph solves the double spending problem .

IOTA

IOTA is, by design, a cryptocurrency for the Internet-of-Things (IoT) industry. The importance of micro-payments is indispensable in the rapidly developing IoT industry, and to pay a fee that is larger than the amount of the value being transferred is not logical. This makes blockchain-based cryptocurrencies such as Bitcoin and Ether unsuitable for such transactions. IOTA is based on DAG which is referred as Tangle in their whitepaper.

Instead of a miner validating a transaction, in IOTA, each transaction must validate at least two previous transactions to get approved. This is analogous to an examination hall where, instead of an invigilator checking for cheating in an exam, each student is programmed in a way that he checks at least two unchecked students.

Weight of a Transaction

There are two types of weights associated with a transaction. First is the transaction’s own weight and second is the cumulative weight.

• Transaction’s own weight refers to the amount of work (POW) put in by the node in issuing that transaction. This weight can only be in the form of 3^n.
• Cumulative weight of a transaction is the sum of its own weight and the self weights of all transactions directly or indirectly approving it. Cumulative weight is very important term as it represents the importance of a transaction.  More the weight of a transaction, less likely for it is to get orphaned.

In above figure, each transaction has cumulative weight and its own weight. Cumulative weight is represented in bold and the self weight is represented in the bottom right corner of that transaction.

For example, Transaction B has own weight of three and cumulative weight of four. Cumulative weight of B = own weight of B + own weight of A, since, A is the only transaction approving it.

In the above figure, when a new transaction X with its own weight equal to three is added to the tangle it approves tips A and C. It directly or indirectly increases the cumulative weight of every transaction by three.

Score of a Transaction

The score of a transaction = Sum of own weights of all transactions approved by this transaction + Own weight of the transaction itself.

Score of transaction A = own weight of transactions D,B,F,G + A’s own weight = 9
Score of transaction C = own weight of transactions D,E,F,G + C’s own weight = 7

Height of a transaction

Length of the longest path from the transaction to genesis transaction of Tangle.

Depth of a transaction

Length of the longest path from some tip to the transaction.

Lazy tip

A node might not want to keep up to date with the current state of the ledger. It might approve same old two transactions for all of its own new transactions. Such new transactions are called lazy tips. Also, this behavior is not appreciated as no new transactions are getting validated by this node. New transactions from honest and hard working nodes must not approve such tips.

Tip selection algorithm

The strategy for determining the two tips to approve is very important, and is the key to IOTA’s unique technology. Since there are usually no ways to enforce a particular tip selection strategy, there must be a good reason for nodes to voluntarily choose to follow a common strategy. A possible reason is knowing that a good portion of other nodes are following the same strategy.

If we choose any 2 random tips then our problem of lazy tips will not be solved. To solve this problem IOTA uses weighted random walks as described below.

In this algorithm, we start a walk from the genesis transaction towards the tips. At each transaction, we choose one of the transactions directly approving this transaction. More the cumulative weight of a transaction more is the probability of choosing that transaction. In this way, we ultimately choose a tip for approval.

How does this solve the lazy tip problem?

In figure 6, when we arrive at transaction 3, two transactions approving it are transaction 5 and transaction 14. The cumulative weight of transaction 14 will be much less than that of 5 until and unless 14 has very high own weight. If the cumulative weight of 5 is much more than probability of choosing 14 will become very low. Hence, we will be able to avoid lazy tips.

So, why not choose the transaction with most cumulative weight with the probability of 1?  In figure 6, suppose 4 is the genesis transaction. Transactions 5, 6 and 7 are approving it directly. Assume that the cumulative weight of the transaction 6 is highest. The algorithm will always choose transaction 6. This will cause a problem as the tips 12 and 13 will never be chosen. Thus, some of the transactions may never get approved.

If the probability is too high that might leave transactions unapproved. If the probability is zero that might approve a lazy tip. Thus, the value of probability, represented by α needs to be chosen cautiously. This algorithm is known as Markov Chain Monte Carlo algorithm.

How are IOTA tokens issued? Can someone mine IOTA tokens?

There is no mining of IOTA tokens. All tokens are considered to be present at an address in the beginning which were then transferred to founder addresses in the genesis transaction.

If there are no miners, how are transactions validated? What happens if a conflicting transaction is added in a Tangle?

Each node checks if the approved transactions are conflicting. If a node finds that a transaction is in conflict with the tangle history or it double spends other transaction, the node will not approve the conflicting transaction in either a direct or an indirect manner. If it validates a conflicting transaction, it fears that the majority of honest nodes will not approve the new transaction.

The local ledger of every node stores the conflicting transactions. Nodes don’t have to come to a consensus to decide which transaction has the right to be in a ledger, all they have to decide is to not approve conflicting transactions. The fraud transactions will ultimately get orphaned. An orphaned transaction is not dropped from the ledger. It will still be stored in the ledger.

But no one directly or indirectly approves the orphaned transactions.

In an IoT network, nodes are devices with specialized chips and they all follow the same set of protocols. It is not suitable for an attacker to submit a conflicting transaction. To do so, he must first reconfigure all other nodes to follow different set of protocols. So, it is best for a node to follow the same set of protocols as the rest of the network.

Confirmation Confidence

Suppose A pays to a merchant M in IOTAs for buying shoes. A might have double spent this same transaction to some other merchant also. Fraud transaction will be ultimately orphaned as discussed above. But, it will take some more time after the initial confirmation. 

How will M decide when to deliver shoes to him? 

The merchant can decide this, using the tip selection algorithm. Many iterations of tip selection algorithm are run and the percentage of tips that directly or indirectly approve the specified transaction is calculated. That represents confirmation confidence. If out of 100 tips 80 tips directly or indirectly approve the transaction, confirmation confidence is 80%. More the confidence more difficult to double spent that transaction. Merchant M can set his own criteria. He may fix a criteria that he will deliver only when confirmation confidence is more than 95%.

Byteball

Byteball is a decentralized system for storage and transfer of value. It can store arbitrary data and transferable values such as currencies, shares, property titles etc. All this data is stored in storage units. Likewise, transactions which transfer these values are stored as storage units. To make it easier to grasp, you should consider storage units as transactions for this blog, just as in case of IOTA. This article will also refer to ‘storage units’ just as ‘units’.

Each storage unit includes one or more hashes of earlier storage units. Hence, confirming them and establishing their partial order, i.e., which storage unit was stored first in the ledger. In IOTA , one transaction has to approve at least two other transactions, this is not compulsory in Byteball. A transaction has to confirm one or more storage units. This is discussed in detail ahead.

The set of storage units and their links form a directed acyclic graph.

Storage units are vertices and their links are edges in the graph. As more and more storage units are added older storage units get confirmations directly or indirectly just as in IOTA.

Everyone is allowed to add a new unit, provided that he signs it and pays a fee. Byteball charges fees, unlike IOTA. This fee plays an important role in keeping the system healthy.

Bytes

Bytes is an internal currency in Byteball network. To store 1 byte of data a user has to pay 1 byte. Anyone can issue their own currency which can then be transferred to any other user, just like the internal currency, bytes. All these transactions are stored as storage units. If we compare this with ethereum environment, bytes is similar to Ether and all these other currencies created by users on byteball platform are similar to tokens issued on Ethereum blockchain.

Blackbytes is another currency available on Byteball network. While bytes is easily traceable, it is much more difficult to trace blackbytes.

Fees in Byteball

As we have discussed before, to store some bytes of data a user has to pay equal number of bytes. This prevents spanning of the ledger with useless messages. The more space your unit takes, the more you have to pay.

For the purposes of calculating unit size, we assume that the unit has exactly two parents, irrespective of the number of the real parents. This is to prevent users who try to approve only a single unit to save fees. 

It is good for directed acyclic graph to be as narrow as possible. To achieve this, users are incentivized to confirm as many units as possible and as recent unit as possible. We can achieve this in two ways:

• Even if many parents are added, fees is same, as discussed above.
• A part of the fees that a new unit pays to store its data is payed to the units which include it first as parent. Other part of the fees is paid to witnesses as discussed later.

The total number of bytes in circulation is 10^15, and this number is constant. All bytes are issued in the genesis unit, then transferred from user to user.

Double Spending in Byteball

Two possible scenarios

There is a partial order between the two units that try to spend the same output, i.e. one of the units (directly or indirectly) includes the other unit, and therefore, comes after it. In this case, we can safely reject the later unit.

In figure 7 above, Red unit tries to double spent Green unit but ther is a partial order between these nodes as Red indirectly confirms Green. In this case, we reject the Red unit. There is no partial order between them. In this case, we accept both. We decide the total order between two units using the Main Chain. This is explained in the next section.

Witnesses

The DAG chain does not have a secure timestamp (or block number). The nodes need a reliable source of transactions that are guaranteed to be generated in a defined order. For this we need the help of the witnesses.

Witnesses are a list of users on Byteball who are non-anonymous and reputable people or companies, or their businesses depend on the health of the network. Part of the fees paid by all the users to get their transaction approved is allocated to witnesses. It is reasonable to expect them to behave honestly. It is also unreasonable to totally trust any single witness.

We have a fixed number of 12 witnesses. Even in case of hack or power out situation, Byteball network will be healthy. If anyone of these witnesses tries to cheat, it will be easy to identify which address cheated and as these addresses are non-anonymous everyone will know the deceiver, which will destroy his reputation as well as he will loose the incentive from Byteball. The task for these witnesses is to just post transactions serially i.e with a partial order and post these transactions frequently.

Main Chain

Based on the transactions posted by the witnesses, a single chain along child-parent links is chosen using an algorithm which can be referred from the Byteball whitepaper. We refer to this chain of transactions as Main Chain. All the units either lie on this chain or can be reached from this chain. This chain is like a highway connecting side roads.

The main chain is indexed from 0 (genesis) in an increasing order. The index number is referred as Main Chain Index (MCI). Units with higher MCI directly or indirectly approves all the units with lower MCI. Therefore, all the units lying on the main chain have their total order defined.

To solve the problem of double spent we need true order in all of the units in the DAG.

Total order needs to be defined for units that do not lie on the main chain. The total order of a unit which does not lie on the main chain is equal to the MCI of the unit (on main chain) which first includes the unit directly or indirectly.

The above figure shows two non-serial storage units (shaded in orange), both of these does not lie on the main chain. One of the transactions is first included by unit with MCI 5 and other is included first by unit with MCI 6. One with MCI 5 wins and is valid unit, the other unit is deemed invalid. In case if both the units have the same main chain index there is a tiebreaker rule that the unit with the lower hash value (as represented in base64 encoding) is valid.

Conclusion

This marks the end of S- trilogy. Thank you for diving deep with us into blockchain scalability issues. If you have any questions regarding this article, please contact the author at pgupta@deqode.com or drop your email here.

Sources

• IOTA Whitepaper.
• Byteball Whitepaper.
• https://medium.com/coinmonks/scaling-a-blockchain-vs-scaling-a-tangle-8b7182eda980
• https://hackernoon.com/a-hitchhikers-guide-to-consensus-algorithms-d81aae3eb0e3

The post S-Trilogy, Part Three: Direct Acyclic Graph, IOTA and Byteball appeared first on Deqode Blog.

State Channels

As we discussed in the previous part of the S-trilogy, layer 2 solutions try to squeeze in the maximum number of possible operations with currently available throughput. A second layer is built in layer 2 solutions, which hinges around the first layer.

State Channels – A Layer 2 Solution

State channels follow the same principle, and are a layer 2 solution. Firstly, a channel is created on-chain. Secondly, transactions are made off-chain, and finally, net result is settled on-chain. Even if you send millions of transactions off-chain, your gas fees is still very low, because only a small number of on-chain transactions is needed to secure the settlement . This opens up the doors for micro-payments using public blockchain.

Transactional capacity is increased dramatically as channels are net-settled on the blockchain.

Bitcoin is implementing this concept of state channels to make payments scalable and with a project called the Lightning Network. Raiden is Ethereum’s version of Bitcoin’s Lightning Network. Both of these projects are in the development phase. These projects are quite similar and discussing any one of these will be sufficient enough to understand the concept of state channels. We will be discussing Raiden in this blog. As these projects are focused on making payments scalable, we refer to these channels as payment channels.

Raiden

For understanding this section, you should have a basic understanding of what ERC20 tokens are and how they work. Also, you should have a basic understanding of what smart contracts are and how they work.

Raiden is a scaling solution for transfer of ERC20 tokens on ethereum blockchain.

As we discussed before, it is built on the concept of payment channels. Instead of making thousands of on-chain transfer of these tokens, we can send these transactions off-chain with ultimate settlement on-chain leading to minimum fees and maximum throughput. It is actually a system of smart contracts built on Ethereum blockchain which allows these fast and cheap token transfers between two parties.

How does it work?

Suppose A and B want to make cheap and fast ERC20 token transactions using payment channels. They need to take the following steps:

1. A channel with a channel Id will be created on-chain where atleast one of them will escrow some amount of ERC20 tokens. Assume both of them deposit 10 tokens each, which means the initial state of channel is [10,10].
2. A transfers 4 tokens to B. They both sign a message which stores the current state of channel as [6,14] with the timestamp. This means that both of them agree to the current state of channel and they cannot refute their signature. These signed messages are just like checks – which once signed cannot bounce back. Signed message is not updated on blockchain instead both parties keep a copy of it. Let’s name this copy of message as SM1.
3. B transfers 8 tokens to A. Current state of channel becomes [14,6]. They both sign a message with current state and the timestamp and keep a copy of it with them. Let’s name this copy of message as SM2.
4. Any one of them can settle the channel by providing the channel Id and latest signed message to the Raiden smart contract. 14 tokens will be transferred to address of A and 6 tokens to address of B.

Challenge Period

Now, what if B submits the signed message, SM1? Raiden contract doesn’t know that there is another signed message SM2. So, B can cheat this way and get himself 14 tokens. This is why there is a challenge period where A can submit the copy of signed message SM2. As its time stamp is higher than that of SM1, Raiden contract will settle the channel in favour of A giving him 14 tokens. If A does not submit his proof before challenge period is over, channel is settled in favour of B. If both A and B are honest, channel can settle immediately as soon as both of them submit the same signed message.

Raiden Network

You don’t need to open a new channel with every new party you want to transact with. Raiden is constructed as a network. This means, although Alice in the figure above might not yet have an open payment channel with Dave, she is indirectly connected to Dave via Bob, or even using multiple steps in between. With the Raiden Network, users are able to transact with anyone who is connected to their network of payment channels through multiple hops. Bob cannot steal Alice’s funds, as he will only receive the sender’s incoming payment if he has already sent the outgoing payment to the recipient.

Let us understand this with another example. Suppose you have to receive a check from a person with whom you have no contact. It is entirely sufficient if you know someone who knows someone – who eventually knows someone – that knows this other person. They all pass checks on to each other until one finally reaches you. But all of them are only valid if you confirm to everyone that you have received yours in the end. None of the middle man can take away your check and this is achieved using cryptography tricks. These middle man can be incentivized with a fees for a healthy network.

Benefits of Raiden Network

Scalability

Most of the transactions are made off-chain, bigger the network the lesser number of on-chain transactions. This will make the system highly scalable.

Latency

It takes about 15–30 seconds to mine a new block in Ethereum. For the finality of transaction, we need to wait for some number of confirmations. Many exchanges wait for 32 confirmations before finalizing a transaction. In Raiden Network, once you have the signed message you can be certain that you hold the amount included in the message. There is no need to wait for any confirmations.

Transaction Fees

Transaction fees is much lower, as only a very small fraction of transactions is made on-chain. Combined fees on all transactions is greatly reduced in comparison to a case where all transactions are made on-chain.

Privacy

Privacy is improved as only net settled transaction is stored on public blockchain. All transactions are not visible to the entire world.

Plasma

Plasma is a scaling solution proposed by Joseph Poon and Vitalik Buterin. They have published a whitepaper on Plasma. Joseph Poon is also coauthor of Lightning Network whitepaper.

Plasma is blockchain within blockchains. Root blockchain, the main Ethereum blockchain, has many child plasma blockchains and each of those blockchains can have their own child blockchains. It is a series of smart contracts which runs on top of a root blockchain, this allows for many blockchains within root blockchain. Root blockchain contract processes only a tiny amount of commitments from child blockchains hence providing high scalability.

Separate plasma contracts can be deployed on root chain each working for different purposes such as private blockchain, decentralised exchange, social network, micropayments.

Private blockchains are a beneficial choice for institutions. Vitalik Buterin discusses in this blog about the comparison between private blockchain and public blockchain. He says that although private blockchain seems more feasible for institutions, public blockchain has its own advantages.

Plasma makes it possible to run a private blockchain over public blockchain hence providing benefits of both, making it perfect for private institutions. 

Now, that you have a understanding of state channels and plasma – a solution for the issue of scalability in blockchain, we will move forward to DAG in the next part of this series. Please click here to navigate to the next article in this trilogy.

To learn more about how Deqode is working towards solving the scalability issues of blockchain, drop your email here.

The post S-Trilogy, Part Two: State Channels and Plasma appeared first on Deqode Blog.

It all started with Satoshi Nakamoto’s whitepaper that was published in 2008. Before the now-legendary paper was published there was no known way to create an authentic digital currency without the help of a centralized authority.

The main issue here was the problem of double spending.

What is the Double Spending Problem?

Any digital currency is just another form of digital files. There is no authority stopping anyone from copying these files and sending them to multiple people. For instance assume that Peter has a file that has been saved locally to his computer. There is nothing preventing Peter from simply copying this file as many times as he wants and sharing the file with multiple individuals. This is known as the double spending problem. This same principle can be applied to digital currencies, which is portrayed in the image below.

The only solution to this issue, before Bitcoin, was to trust a central authority to manage these digital files. In such a system, if a single authority cheats – then the user is doomed and the only way for them to reinforce the breached contract is by taking help of the law, which we know is slow, expensive and uncertain. Another big issue was that this centralization makes the system prone to a single point of failure.

Satoshi Nakamoto’s whitepaper gave a solution for the double spending problem and made it possible to make digital payments without the need for a central authority, which was Bitcoin. The paper solved this problem by using a trustless peer to peer network. Instead of storing data only in a centralized ledger the data is broadcasted throughout the network using gossip protocol and every peer updates its own ledger. This way within a small period of time, the entire network has the same copy of ledger, or we can say that the whole network has the same state.

What is a transaction and what is a block?

A transaction is an exchange of assets between 2 users, for example, bitcoins are assets on the bitcoin blockchain. An exchange of bitcoins among peers is known as a transaction. A block is the collection of these transactions. Every single transaction is not propagated throughout the network, instead, a block once filled is propagated in the network. Every block has a fixed maximum size or the number of maximum number of transactions it can have.

All the blocks are lined up one after other and each block includes the hash of the previous block, in this way forming a chain. 

How is double spending prevented?

A network is composed of nodes (the peers). Some of the nodes are miners. Any node can become a miner, and no permission is needed because it is a public ledger. In simplest terms, miners compete with each other to solve a computational puzzle. One who solves it first broadcasts the block which has a collection of transactions – that miner validates and confirms that there is no double spending. He also broadcasts the solution of the puzzle so that everyone can verify that he has actually solved the puzzle. All nodes also verify the transactions in the block before adding that block in their own copy of ledger. In case a miner has added a double spent transaction in the block the nodes will reject that block and that block will be dropped.

Why would anyone want to be a miner? 

A miner who solves the puzzle and broadcasts the block gets a fixed number of native currency. For example: bitcoins in bitcoin blockchain, miner also gets the transaction fees paid by the user. Miner can choose the transactions that he wants to add in his block, generally miners choose transactions with high fees first, so as to maximize their profit.

Why do we need to waste all this energy to solve a puzzle?

Consider the following attack scenario to understand.

Suppose an attacker wants to double spend a transaction that is in block number 1000 and current block number is 1005. The attacker will make a change in block number 1000 but he can change it only in his own node, as the state of blockchain is same at all other nodes. Attacker forks his own chain from the main chain and adds new blocks to this forked chain and hopes that everyone in the network accepts his chain.

There can be two cases from here. 

• Attacker’s hashing power (computational power to solve the puzzle) is less then 50% of the total hashing power. The speed with which his chain size increases will be less than that of the honest chain.
• Attacker’s hashing power is more then 50% of the total hashing power. The speed with which his chain size increases will be more than that of the honest chain.

Longest Chain Rule

All nodes follow the longest chain rule i.e. the longest chain has most work done on it and so it is honest. 

So in the former case, attacker chain length will be less than honest chain, the probability of successful attack is less and hence attacker will not be able to double spend.

In the latter case attacker chain length will get longer than honest chain and suppose that after 2 hours, length of honest chain is now 1010 and that of attacker chain is 1011. All nodes will update to the chain of attacker and the blocks from 1000 to 1010 mined in honest chain will be dropped. The computational power spent to change a block increases with the depth of the block being changed. If the value of double spending exceeds the computational power cost, it is not sensible to perform such an attack.

Once many blocks are mined on top of a block the transactions in that block may be considered as irreversible.This attack scenario explains the importance of solving a computational expensive puzzle.

This requirement that expensive computations be performed in order to facilitate transactions on the blockchain is popularly known as Proof Of Work.

Scalability Issues with Blockchain

Bitcoin and Ethereum are based on the above explained technology and we all know how popular they are today. Despite the amazing technology there are some problems. The main issue that this technology is facing today is the problem of scalability.

The throughput is small, for bitcoin it is in single digits while throughput of Visa is in 1000s of tranactions per second. As more and more people start adopting bitcoin, the transaction fees will rise (demand is more than supply) thus making small value transactions in bitcoin futile (fees will be more than the value of transaction). 

Recently on Ethereum, a game named cryptokitties took off and the traffic became high thus increasing the transaction fees and number of pending transactions by many folds. The issue of scalability is the biggest barrier for mass adoption of these currencies.

Throughput of blockchain is limited by the fixed size of a block and the propagation time of a new block through the whole peer to peer network.

Solutions to the Scalability Problem

The scalability issue is the most prominent field of research in the blockchain world. Many different solutions are being proposed to solve the issue. These solutions can be classified into two types:

Layer 1 Solutions

These solutions change the blockchain protocols to deal with the problem of scalability. 

Segregated Witness (SegWit)

This is exclusive to Bitcoin. It is a small improvement in the bitcoin protocol which increases the throughput by fitting more transactions in a single block by re-weighing the signatures of transaction data. Signature data of every transaction is moved from the main chain to the parallel side chain which frees up space in the block. Still, the throughput will be in single digits and hence not a solution for mass adoption of bitcoin. SegWit is currently active in the present bitcoin blockchain.

Block Size Increase

Right now as per bitcoin protocol the size of the block is limited to 1 MB this limits the throughput of the bitcoin network. 

Why don’t we just increase the size of the block?

This is currently a topic of debate, a part of bitcoin community believes that increasing block size is necessary for mass adoption of Bitcoin. As it will prevent increase of gas price at times of high traffic. They also believe that SegWit is not a permanent fix and size of blocks must be increased. When SegWit was implemented this community forked a new blockchain ‘Bitcoin Cash’ which does not implement SegWit and has a block size of 8MB.

Other part of the community believes that increasing the block size will centralize the Bitcoin network. As the block size increases, the amount of processing power required to mine a block will increase. This will make it impossible for small scale miners to mine a block and all the power will shift to a handful of miners. Thus making 51% attack more possible. Some of them also believe that Bitcoin should only be used as a store of value like gold.

Increasing block size will cause other problems as well. Size of the block is related to the propagation time of a new block through the network. More the size of the block more time it takes for each node to validate transactions in it. A node propagates a block only after it has validated the block. Increasing block size will increase the propagation time of new block through the whole network.

Chain Reorganization

Suppose there are 2 honest miners A and B, in two different parts of the world. A solves the puzzle and broadcasts his block in the network. Before this block reaches B, B has also solved the puzzle and he also broadcasts his block. So some of the nodes in the network have added the block mined by A to their local copy of ledger and others have added the block mined by B. Ultimately one of these blocks is dropped. This is known as chain reorganization. 

Although the dropped block had honest transactions it got dropped. All the hashrate is wasted which could have been used to mine another block which would have made the network more secure. More the size of the block more the wastage of hashrate.

Sharding
Any transaction that takes place on the ethereum network has to be validated and stored by each node in the network so that every node has the same state. This puts a limit on the throughput on a protocol level. Hence, no matter what the implementation, without changing the protocol it is difficult to solve the scalability issue. 

What if all nodes don’t have to process each transaction? The network is divided into some sections which can work semi-independently. Each section could process a different batch of transactions and hence increase the throughput by many folds. Each of these sections is termed as ‘shard’. This is the idea behind sharding.

Layer 2 Solutions

Layer 2 solutions don’t change anything on the protocol level. They are built on top of the same protocols, a kind of a second layer on top of Layer1.

The purpose is to make maximum possible use from available throughput. We try to squeeze in maximum possible number of operations. This works by creating a second layer which is hinged around first layer. All the transactions in Layer2 take place off chain, those transactions need not to be included in Layer1 instantly. All the transactions are recorded off chain. The net result is finally pushed in the Layer1 thus giving them security of Layer 1. 

Although the finality of the transaction is less in Layer2 transactions than Layer1 transactions. Layer2 transactions are also secure and final enough for many practical purposes.

State Channels and Plasma are a few examples of the proposed Layer2 solutions. We will discuss them here.

Must read: “Victory Royale: How Blockchain Could Fix Fortnite“

The post S-Trilogy, Part One: Understanding Blockchain, Its Scalability Issues, and their Solutions appeared first on Deqode Blog.