Scalability solutions - Part 2
Hello Stemians and welcome to the next part of the solution for the Bitcoin scalability issue.
Today we going to overview 3 other solutions: Sharding and Schnorr signatures
Take your mask and let's deep in
Before I am continuing the reason why we choose not to increase the block size even to 1GB is that we need miners, and the more block size it will be, the bigger miners asics will be needed and the only one who will afford it will be the rich or corporation so it will be centralized.
The Blockchain Trilemma
We can't have all, we have to decide which one is much important and focus on it while trying to push the limit for the other properties
Sharding
Basically, the definition of this term is to partitioning existing very large databases the into smaller, faster, more easily managed parts called data shards.
Nowadays each nodes stores all states (account balances, contract code, and storage, etc.) and processes all transactions. This provides a large amount of security, but greatly limits scalability: a blockchain cannot process more transactions than a single node can. This is one of the reason that Bitcoin is limited to ~3-7 transactions per second, Ethereum to 7-15, etc.
Ethereum is also looking, for this option, in other words, that means each node will treat different transaction number, for example, one node will treat this kind of transaction 12xxxxxxx
and another one will treat 13xxxxxx transactions creating new chains. It can process much more transactions per second but the only issue is the security.
Cons - the split is weaker and can be attacked
Vitalik ppt
Sharding github
Schnorr signatures
Today Bitcoin’s digital signature algorithm (ECDSA) is valid for every transaction, each person sending money to a receiver create a signature. What if we are concatenating 50 transaction signature into one having the same size. A simple algorithm leveraging elliptic curve cryptography, Schnorr enables several improvements over the existing scheme all while preserving all of its features and security assumptions. Schnorr signatures support “native multisig” which enables the aggregation of multiple signatures into a single one valid for the sum of the keys of their respective inputs.
Cons - the Schnorr algorithm has not been standardized since its invention, likely because of the original patent enforced on it (which has since expired - 2008). There is a lack of documentation and specification making it more challenging to implement. Specifically, its application to the ephemeral keypairs design of Bitcoin involves security considerations that require further optimization.
Hope you enjoyed
![upvote- steemit.gif](https://steemitimages.com/DQmWHUZjHQFFJKUioxVAkfyHpKP4QYTyM2R5bqjQfHvsbUH/upvote-%20steemit.gif)
Very good post, thanks.
@racoo
solution: just buy more EOS...
it is another platform for different uses