WHY SCALING IS IMPORTANT:
The faster a blockchain can process transactions, the more competitive it will be with legacy centralized systems.
For example, Ethereum's initial Proof of Work network can only handle about 15 transactions per second (tps), whereas Visa's network can handle over 65,000 tps.
In blockchain networks, this ability to scale often comes at the sacrifice of centralization and security. For instance, you can make the network move a lot faster (handle many more tps), if you have a few specified nodes in charge of validating the transactions. Those few specified nodes will have a much easier job finding each other to collude and validate dishonest transactions; opposed to a more secure network with a larger number of anonymous and widely-distributed nodes.
This brings us to the purpose of this section...
For example, Ethereum's initial Proof of Work network can only handle about 15 transactions per second (tps), whereas Visa's network can handle over 65,000 tps.
In blockchain networks, this ability to scale often comes at the sacrifice of centralization and security. For instance, you can make the network move a lot faster (handle many more tps), if you have a few specified nodes in charge of validating the transactions. Those few specified nodes will have a much easier job finding each other to collude and validate dishonest transactions; opposed to a more secure network with a larger number of anonymous and widely-distributed nodes.
This brings us to the purpose of this section...
HOW TO SCALE & THE RISKS OF EACH METHOD:
LAYER 1 SOLUTIONS
Layer 1 solutions are scaling solutions that occur on the original blockchain (main chain).
---
Block Size
Top two considerations to make regarding block size are:
1) Larger block size makes for a faster network because you can fit more transactions into each block, and there is a specified amount of blocks that can be processed within a certain amount of time. For example, only one new block is mined on the Bitcoin network, every ten minutes. If you can fit more transactions into a block, then you are able to process more transactions per second. However, this takes more expensive computing power to process a larger block, usually resulting in fewer validators, thus more centralization. If you make it more expensive to write to the blockchain, via larger block sizes, then layer 2 (usually more centralized) options also become more appealing.
2) Smaller block sizes means fewer transactions getting loaded into each block, resulting in fewer transaction per second getting validated within the specified block time (i.e. ten minutes). Lots of smaller blocks makes it more computationally expensive to read the blockchain, thus more centralized trust gets placed with the few participants willing to expend the computing power to read and provide accurate data from the chain.
Why not have smaller block sizes (easier and faster to process), and get rid of specified block time (i.e. one new block every ten minutes)? This does not work well because once each new little block is quickly mined, it takes time for all the other validator nodes, from all around the world to find out about the new valid block. If a validator node does not find out about the new correct block that all other nodes agreed on (came to consensus on) in a timely manner, then that node may end up building on another false block that was not agreed upon by majority of the nodes, causing a split to the main chain. As internet communication get faster, allowing nodes to sync info faster, perhaps this can become a solution.
An example of a less effective block size update is the Segregated Witness "SegWit" soft fork of the Bitcoin blockchain. SegWit placed the transaction signatures outside of the blocks, in order to make blocks lighter to process. The computing power required didn't really change though, because a rule was made that in order for a block to be considered valid, it must come with a separate extension block that contains all the signatures.
1) Larger block size makes for a faster network because you can fit more transactions into each block, and there is a specified amount of blocks that can be processed within a certain amount of time. For example, only one new block is mined on the Bitcoin network, every ten minutes. If you can fit more transactions into a block, then you are able to process more transactions per second. However, this takes more expensive computing power to process a larger block, usually resulting in fewer validators, thus more centralization. If you make it more expensive to write to the blockchain, via larger block sizes, then layer 2 (usually more centralized) options also become more appealing.
2) Smaller block sizes means fewer transactions getting loaded into each block, resulting in fewer transaction per second getting validated within the specified block time (i.e. ten minutes). Lots of smaller blocks makes it more computationally expensive to read the blockchain, thus more centralized trust gets placed with the few participants willing to expend the computing power to read and provide accurate data from the chain.
Why not have smaller block sizes (easier and faster to process), and get rid of specified block time (i.e. one new block every ten minutes)? This does not work well because once each new little block is quickly mined, it takes time for all the other validator nodes, from all around the world to find out about the new valid block. If a validator node does not find out about the new correct block that all other nodes agreed on (came to consensus on) in a timely manner, then that node may end up building on another false block that was not agreed upon by majority of the nodes, causing a split to the main chain. As internet communication get faster, allowing nodes to sync info faster, perhaps this can become a solution.
An example of a less effective block size update is the Segregated Witness "SegWit" soft fork of the Bitcoin blockchain. SegWit placed the transaction signatures outside of the blocks, in order to make blocks lighter to process. The computing power required didn't really change though, because a rule was made that in order for a block to be considered valid, it must come with a separate extension block that contains all the signatures.
---
Sharding
Sharding is when a node is only responsible for validating a portion of a block, instead of the entire thing. Nodes get assigned to shards, which operate as a subset of the blockchain, allowing for computation to get split apart into smaller sections.
Each node only needs to store a shard (small portion) of the entire block data, making the data load much lighter (thus faster) to process. Together, each node's portion of the data completes the entire block; think of it like BitTorrent. Each validator can check to verify honesty of another shard's work via 1) random sampling, where if most validators sign a transaction, then you can probably accept it as honest, and 2) zk-snarks, providing proof that the validator ran a complex computation on the specified block data, and received a specified output. If a zk-snark says the data is valid, then it probably is, because a well designed proof means you can't get a valid result from bad block data. In order for zk-snarks to be worth while, the proof must require much less computing power than what is needed to fully validate the original block.
For more about how zk-snarks (zero knowledge proofs) work, please see "The Crypt" section on it.
Shards operate as domains- regions of blockchain state. The domains allow for synchronous interactions where processing can happen much faster because programs are communicating within the same domain. Asynchronous (less efficient) interactions happen between shards or rollups.
Each node only needs to store a shard (small portion) of the entire block data, making the data load much lighter (thus faster) to process. Together, each node's portion of the data completes the entire block; think of it like BitTorrent. Each validator can check to verify honesty of another shard's work via 1) random sampling, where if most validators sign a transaction, then you can probably accept it as honest, and 2) zk-snarks, providing proof that the validator ran a complex computation on the specified block data, and received a specified output. If a zk-snark says the data is valid, then it probably is, because a well designed proof means you can't get a valid result from bad block data. In order for zk-snarks to be worth while, the proof must require much less computing power than what is needed to fully validate the original block.
For more about how zk-snarks (zero knowledge proofs) work, please see "The Crypt" section on it.
Shards operate as domains- regions of blockchain state. The domains allow for synchronous interactions where processing can happen much faster because programs are communicating within the same domain. Asynchronous (less efficient) interactions happen between shards or rollups.
LAYER 2 SOLUTIONS
Layer 2 solutions are scaling solutions that happen outside of the original blockchain network.
---
Sidechains
Sidechains are considered a layer 2 scaling method, because they are not part of the main blockchain; it is a separate layer. A sidechain is attached to its parent blockchain using a two-way peg. The original blockchain is usually referred to as the ‘main chain’ and all additional blockchains are referred to as ‘sidechains’.
Use- Sidechains allow some of the burden of processing transactions to happen off the main blockchain, meaning that the main chain does not get overwhelmed by too many transactions. In practice, many users consider side chains for relatively small and insignificant transactions (low risk transactions), and use main chains for larger and more important transactions. This is because the main chain is often more secure.
Security- Main chains are often more secure, especially if they have a relatively large number of anonymous and widely-distributed nodes. Sidechains can be more risky because they are run by 3rd party companies that may not have established trust among users.
The classic example of a side chain in the Bitcoin network is the Lightning network. Many transactions are conducted on the faster (less secure) Lightning network, then can eventually be uploaded onto the Bitcoin main chain, all at once.
Plasma is a framework that allows the creation of child blockchains that use the main Ethereum chain as a layer of trust and arbitration. Works well for payments, but not smart contracts.
Use- Sidechains allow some of the burden of processing transactions to happen off the main blockchain, meaning that the main chain does not get overwhelmed by too many transactions. In practice, many users consider side chains for relatively small and insignificant transactions (low risk transactions), and use main chains for larger and more important transactions. This is because the main chain is often more secure.
Security- Main chains are often more secure, especially if they have a relatively large number of anonymous and widely-distributed nodes. Sidechains can be more risky because they are run by 3rd party companies that may not have established trust among users.
The classic example of a side chain in the Bitcoin network is the Lightning network. Many transactions are conducted on the faster (less secure) Lightning network, then can eventually be uploaded onto the Bitcoin main chain, all at once.
Plasma is a framework that allows the creation of child blockchains that use the main Ethereum chain as a layer of trust and arbitration. Works well for payments, but not smart contracts.
---
Rollups
Rollups are not side chains, but are considered a layer 2 scaling method, because they are not part of the main blockchain; it is a separate layer. Rollups inherit the security of the main chain, whereas sidechains do not. Sidechains employ their own consensus mechanism, and have their own native token, which can be vulnerable to its own 51% attack.
Rollups have some properties of sharding, but not all. Rollups are also designed to split apart computation into smaller sections. Rollups rely on the same data layer, which is downloaded and verified by all users. This is different from shards where certain data is not verified by all. One rollup can use data from multiple shards.
In rollups, users send transactions to a central "aggregator". The aggregator then removes the more static transaction data that is not relevant to updating the blockchain state. This can include account balances, code, smart contract internal memory, etc. The aggregator then takes the new, more dynamic data, that is relevant to updating the blockchain state and compresses it. Thus, the only new data that gets published on the main chain is the small (compressed) state-relevant data.
Rollups also use zk-snarks to prove validity of a computation using a hash (small finger print) of the proof result. Other nodes can then verify the hash.
Optimistic rollups is when a node reports what it thinks the result of a transaction is. If another node disagrees with the result, it triggers all the data to be run on chain. Optimistic rollups thus tie-up assets if users have to wait for an on chain dispute-resolution.
Rollups have subsets of participants. They operate as domains- regions of blockchain state. The domains allow for synchronous interactions where processing can happen much faster because programs are communicating within the same domain. Asynchronous (less efficient) interactions happen between shards or rollups.
Rollups have some properties of sharding, but not all. Rollups are also designed to split apart computation into smaller sections. Rollups rely on the same data layer, which is downloaded and verified by all users. This is different from shards where certain data is not verified by all. One rollup can use data from multiple shards.
In rollups, users send transactions to a central "aggregator". The aggregator then removes the more static transaction data that is not relevant to updating the blockchain state. This can include account balances, code, smart contract internal memory, etc. The aggregator then takes the new, more dynamic data, that is relevant to updating the blockchain state and compresses it. Thus, the only new data that gets published on the main chain is the small (compressed) state-relevant data.
Rollups also use zk-snarks to prove validity of a computation using a hash (small finger print) of the proof result. Other nodes can then verify the hash.
Optimistic rollups is when a node reports what it thinks the result of a transaction is. If another node disagrees with the result, it triggers all the data to be run on chain. Optimistic rollups thus tie-up assets if users have to wait for an on chain dispute-resolution.
Rollups have subsets of participants. They operate as domains- regions of blockchain state. The domains allow for synchronous interactions where processing can happen much faster because programs are communicating within the same domain. Asynchronous (less efficient) interactions happen between shards or rollups.
---
About Me:
BA in Economics. BS in Finance.
Hostess of the Crypt Keepers’ Club.
Passionate about research and data.
I don’t fold sheets, I spread them.
Hostess of the Crypt Keepers’ Club.
Passionate about research and data.
I don’t fold sheets, I spread them.
Connect with Me:
Note that you must be logged into Facebook to be directed to my page.
DISCLAIMER:
Keep in mind that information on this site is only from my perspective, and this industry is constantly evolving. Do more research. Be accountable for your decisions.
ALL INVESTMENTS ARE DONE SO AT YOUR OWN RISK!
Keep in mind that information on this site is only from my perspective, and this industry is constantly evolving. Do more research. Be accountable for your decisions.
ALL INVESTMENTS ARE DONE SO AT YOUR OWN RISK!
Have something constructive to add? Do so in this comment box, below.
BE KIND! Insecure egos do not appeal to anyone's better nature.
© COPYRIGHT 2017-2021 ALL RIGHTS RESERVED.