How to scale bitcoin blockchain
In one of our previous materials, we noted that the main advantages of the blockchain are openness, security and safety. However, any technology always has certain disadvantages.
Bitcoin, as the largest, most popular and reliable blockchain is also not without such, but the community is actively solving them. Therefore, in the framework of today's post, we will address the following questions:
/ image by Susana Fernandez CC
')
Today, banks, energy companies, Internet of Things and government organizations are actively eyeing the blockchain. For example, Bank of America and Microsoft have begun to jointly develop a financial blockchain platform, while Chronicled has launched a blockchain platform for the Internet of things, which creates secure digital identifiers that are compatible with many other systems. However, the environment and conditions in which Bitcoin operates are significantly different from what they were at the time of the birth of cryptocurrency. The number of users increased to several tens of millions of people ( more than 13 million), which caused an increase in the number of daily transactions ( about 400 thousand).
The amount of resources that have to be spent on the work of the software and storing the Bitcoin registry with the list of transactions performed is quite large. The entire transaction chain of bitcoin blockchain can be traced, starting with the very first operation conducted on January 12, 2009 by the creator of bitcoin Satoshi Nakamoto. To date, the size of the bitcoin blockchain is about 120 GB and continues to grow.
All these features of the functioning of the system led to the problem of scaling Bitcoin and limited its theoretical size. A blockchain is a sequence of blocks, each of which is a set of transactions protected by cryptographic algorithms. At the same time, Satoshi Nakamoto (about a year after the creation of Bitcoin) limited the block size to one megabyte. This was done in order to prevent possible DoS-attacks of intruders when they create large (in theory unlimited) blocks to paralyze the network.
However, such a security measure had a negative effect on the network capacity in general (in the long term). Today, bitcoin can process about 7 transactions per second (TPS). At the same time, the actual load on the Bitcoin network is 3.5 TPS. For comparison, the TPS indicator in the Visa system is 2,000 (at the moments of peak activity - 50,000).
The first proposals to improve Bitcoin were presented in 2015 ( BIP 100 and BIP 101 ) by core developers Jeff Garzik and Gavin Andresen. Both solutions proposed to increase the block size, but were hard forks, that is, they did not have backward compatibility. This meant that when they were implemented, the old software would become incompatible with the new network. In the BIP 100 it was proposed to adjust the block size by the decision of miners, and in BIP 101 - to simultaneously increase the block size to 8 megabytes.
At that time, an increase in the block size was the simplest solution from a technical point of view, but none of the schemes was implemented. Refusal to implement turned out to be associated more with political (within the Bitcoin ecosystem) problems than with technical ones. The presence of large blocks could lead to the centralization of Bitcoin, since their storage and processing would require even more computing power, and only large companies can allocate such amounts of resources. Thus, there would be a contradiction with the main idea of ​​Bitcoin blockchain as user-controlled cryptocurrency.
At the end of 2015, developer Peter Wullet (Pieter Wuille) presented a proposal called Segregated Witness, which increases network bandwidth. The approach did not change the size of the block, but the method of storing transactions. One of the advantages of the solution was the possibility of its implementation through softfork (that is, ensuring backward compatibility). After the release of the technical description of Segregated Witness, the proposed solutions to the scalability problem were divided into two groups: some sought to increase the block size, and others to leave the unit unchanged, optimizing other aspects of the protocol. No consensus could be reached on this issue. Until recently.
On May 20, the key players in the Bitcoin industry were able to find points of contact. Hong Kong Bitcoin Roundtable Consensus conference participants (including BitFury) agreed to support several bitcoin protocol upgrades. One of them is Segregated Witness activation upon reaching a support level of 80% (miner capacity). The second is associated with an increase in the size of the block to 2 MB. This decision even affected the cost of bitcoin. The interest in cryptocurrency and the new opportunities for blockchain scaling have led to the fact that the price for bitcoin has exceeded the mark of 2.5 thousand dollars.
We can say that transactions in Bitcoin consist of two components. The first component frees Bitcoins blocked in previous transactions using so-called inputs. Inputs include scripts (ScriptSigs); Each such script contains a set of instructions for opening Bitcoins (for example, a digital signature). The second transaction component contains a set of pins (ScriptPubKeys scripts) that lock in the freed bitcoins (or slightly less). Each locking script determines the conditions under which the corresponding bitcoins can be spent (for example, provided you know a certain private key). It turns out that bitcoins are moving from inputs to transactions and from one transaction to another.
Bitcoin locking and unlocking is done by transaction senders, and is transmitted over the network in the form of information packets. Bitcoin conclusions, as a rule, contain instructions, the meaning of which is to make sure that the user knows the necessary private key corresponding to the specified public key.
Technology Segregated Witness modifies this chain of interactions. The newly created conclusions begin to use a different type of locking script, which is called “anyone can spend”, because it does not require digital signatures, and at first glance it can be spent by anyone. The trick is that the locking script of the type can cant contains a specific sequence of bytes that binds to the script the “real” conditions of spending bitcoins.
A similar technique is used in P2SH (Pay to Script Hash). As in the case of SegWit, with P2SH, the bitcoins are still locked in the script, but not the locking script itself is added to the exit of the transaction, but its hash. In order to spend bitcoins locked in such a scenario, you need to know not only the “real” locking script (as it may seem when you first read scriptPubKey), but also the unlocking scriptSig for this script (for example, a digital signature).
Segregated Witness essentially separates scriptSig (transaction signatures) into a separate data structure - witness (proof). Thus, SegWit is an addon that is completely ignored by the old nodes, but is recognized as new. Both old and new nodes consider transactions with SegWit to be correct: the first ones see the “anyone spends” scripts and consider the transaction to be correct (albeit strange from the point of view of semantics), and the second refer to the signature in witness. Due to this technology allows you to eliminate the fusibility of transactions (tx malleability), save disk space and optimize the speed of verification of signatures.
There is, however, a small difficulty: if the signatures do not affect the transaction hashes, it can no longer be evidence that valid signatures exist in nature for the transactions included in the block. To get around this feature, the miner writes a hash to a specific location of the block, depending on all witness in transactions, which is calculated similarly to the transaction hash of the block, that is, using Merkle trees.
Another advantage of SegWit is the fact that it contains version bytes. They precede the script and indicate its type. This makes it possible to designate the requirements necessary for the release of bitcoins. In fact, this allows you to lock Bitcoins in many different ways. The potential of this function can be realized by Schnorr’s signatures , which are more compact and verified faster than the current ECDSA signatures, as well as more complex types of multi- signature transactions and even smart contracts like Ethereum.
In practice, locking scripts in SegWit look similarly (this example is taken from a real transaction , not in Bitcoin, but in another technically very similar blockchain - a lightcoin; SegWit is already activated on it):
The script consists of a script version byte (0), followed by 20 bytes corresponding to the usual address in the bitcoin network (public key hash). Viewed from the point of view of a node that knows nothing about SegWit, this script can be spent by anyone, for example, with an empty unlocking scriptSig. In fact, scriptPubKey only adds data to the stack and does not perform any checks for data pushed to the stack by scriptSig before.
When viewed from the point of view of a node that knows about SegWit, this script signals that the witness of the spending transaction should contain a digital signature of the transaction along with the public key, the hash of which is specified in the script. The scriptSig field must be empty.
How exactly it is worth checking the SegWit script, the node determines on the basis of the version byte and the length of the next scriptPubKey element (in the example above, it is 20). So far, two types of scenarios are defined in SegWit: based on the public key (our example) and more complex for arbitrary checks (for example, multisignatures). In the second case, a 32-byte hash of the “real” locking script is written to the scriptPubKey. When spending money, this scenario, along with a suitable unlocking scenario, must be provided in the witness field. In this case, the hash of the locking script must match the value specified in the scriptPubKey.
As part of this material, I would like to mention the Lightning Network (LN) scaling technology, which in many respects becomes possible due to SegWit, and in the development of which BitFury is actively involved. Lightning Network is based on ordinary Bitcoin transactions, only these transactions are not transferred to the Bitcoin network (at least, immediately). Instead, they are stored locally on LN nodes.
The main feature of the Lightning Network is bi-directional “non-trustworthy” payment channels that allow you to exchange bitcoins directly, bypassing the blockchain. Only blocking and closing transactions are broadcast on the blockchain, even if there are millions of payments between them. This allows you to seriously "unload" the blockchain and increase its bandwidth, as well as to carry out microscopic payments (for example, pay for digital content or Internet connection per second). Moreover, LN allows payments to be made through one or more intermediate nodes of a network without the risk that these nodes will steal funds. This provides LN scalability to millions of nodes. In more detail about the principles of work of LN we plan to tell in the subsequent materials.
PS Our jobs at HH and the English-language blog at Medium .
PPS Additional materials on the topic:
Bitcoin, as the largest, most popular and reliable blockchain is also not without such, but the community is actively solving them. Therefore, in the framework of today's post, we will address the following questions:
- What is the biggest disadvantage of bitcoin blockchain?
- What solutions did the world community offer?
- Which of them will become part of the bitcoin network?
/ image by Susana Fernandez CC')
Today, banks, energy companies, Internet of Things and government organizations are actively eyeing the blockchain. For example, Bank of America and Microsoft have begun to jointly develop a financial blockchain platform, while Chronicled has launched a blockchain platform for the Internet of things, which creates secure digital identifiers that are compatible with many other systems. However, the environment and conditions in which Bitcoin operates are significantly different from what they were at the time of the birth of cryptocurrency. The number of users increased to several tens of millions of people ( more than 13 million), which caused an increase in the number of daily transactions ( about 400 thousand).
The amount of resources that have to be spent on the work of the software and storing the Bitcoin registry with the list of transactions performed is quite large. The entire transaction chain of bitcoin blockchain can be traced, starting with the very first operation conducted on January 12, 2009 by the creator of bitcoin Satoshi Nakamoto. To date, the size of the bitcoin blockchain is about 120 GB and continues to grow.
All these features of the functioning of the system led to the problem of scaling Bitcoin and limited its theoretical size. A blockchain is a sequence of blocks, each of which is a set of transactions protected by cryptographic algorithms. At the same time, Satoshi Nakamoto (about a year after the creation of Bitcoin) limited the block size to one megabyte. This was done in order to prevent possible DoS-attacks of intruders when they create large (in theory unlimited) blocks to paralyze the network.
However, such a security measure had a negative effect on the network capacity in general (in the long term). Today, bitcoin can process about 7 transactions per second (TPS). At the same time, the actual load on the Bitcoin network is 3.5 TPS. For comparison, the TPS indicator in the Visa system is 2,000 (at the moments of peak activity - 50,000).
Early Problem Solving Suggestions
The first proposals to improve Bitcoin were presented in 2015 ( BIP 100 and BIP 101 ) by core developers Jeff Garzik and Gavin Andresen. Both solutions proposed to increase the block size, but were hard forks, that is, they did not have backward compatibility. This meant that when they were implemented, the old software would become incompatible with the new network. In the BIP 100 it was proposed to adjust the block size by the decision of miners, and in BIP 101 - to simultaneously increase the block size to 8 megabytes.
At that time, an increase in the block size was the simplest solution from a technical point of view, but none of the schemes was implemented. Refusal to implement turned out to be associated more with political (within the Bitcoin ecosystem) problems than with technical ones. The presence of large blocks could lead to the centralization of Bitcoin, since their storage and processing would require even more computing power, and only large companies can allocate such amounts of resources. Thus, there would be a contradiction with the main idea of ​​Bitcoin blockchain as user-controlled cryptocurrency.
Segregated Witness
At the end of 2015, developer Peter Wullet (Pieter Wuille) presented a proposal called Segregated Witness, which increases network bandwidth. The approach did not change the size of the block, but the method of storing transactions. One of the advantages of the solution was the possibility of its implementation through softfork (that is, ensuring backward compatibility). After the release of the technical description of Segregated Witness, the proposed solutions to the scalability problem were divided into two groups: some sought to increase the block size, and others to leave the unit unchanged, optimizing other aspects of the protocol. No consensus could be reached on this issue. Until recently.
On May 20, the key players in the Bitcoin industry were able to find points of contact. Hong Kong Bitcoin Roundtable Consensus conference participants (including BitFury) agreed to support several bitcoin protocol upgrades. One of them is Segregated Witness activation upon reaching a support level of 80% (miner capacity). The second is associated with an increase in the size of the block to 2 MB. This decision even affected the cost of bitcoin. The interest in cryptocurrency and the new opportunities for blockchain scaling have led to the fact that the price for bitcoin has exceeded the mark of 2.5 thousand dollars.
We can say that transactions in Bitcoin consist of two components. The first component frees Bitcoins blocked in previous transactions using so-called inputs. Inputs include scripts (ScriptSigs); Each such script contains a set of instructions for opening Bitcoins (for example, a digital signature). The second transaction component contains a set of pins (ScriptPubKeys scripts) that lock in the freed bitcoins (or slightly less). Each locking script determines the conditions under which the corresponding bitcoins can be spent (for example, provided you know a certain private key). It turns out that bitcoins are moving from inputs to transactions and from one transaction to another.
Bitcoin locking and unlocking is done by transaction senders, and is transmitted over the network in the form of information packets. Bitcoin conclusions, as a rule, contain instructions, the meaning of which is to make sure that the user knows the necessary private key corresponding to the specified public key.
Technology Segregated Witness modifies this chain of interactions. The newly created conclusions begin to use a different type of locking script, which is called “anyone can spend”, because it does not require digital signatures, and at first glance it can be spent by anyone. The trick is that the locking script of the type can cant contains a specific sequence of bytes that binds to the script the “real” conditions of spending bitcoins.
A similar technique is used in P2SH (Pay to Script Hash). As in the case of SegWit, with P2SH, the bitcoins are still locked in the script, but not the locking script itself is added to the exit of the transaction, but its hash. In order to spend bitcoins locked in such a scenario, you need to know not only the “real” locking script (as it may seem when you first read scriptPubKey), but also the unlocking scriptSig for this script (for example, a digital signature).
Segregated Witness essentially separates scriptSig (transaction signatures) into a separate data structure - witness (proof). Thus, SegWit is an addon that is completely ignored by the old nodes, but is recognized as new. Both old and new nodes consider transactions with SegWit to be correct: the first ones see the “anyone spends” scripts and consider the transaction to be correct (albeit strange from the point of view of semantics), and the second refer to the signature in witness. Due to this technology allows you to eliminate the fusibility of transactions (tx malleability), save disk space and optimize the speed of verification of signatures.
There is, however, a small difficulty: if the signatures do not affect the transaction hashes, it can no longer be evidence that valid signatures exist in nature for the transactions included in the block. To get around this feature, the miner writes a hash to a specific location of the block, depending on all witness in transactions, which is calculated similarly to the transaction hash of the block, that is, using Merkle trees.
Another advantage of SegWit is the fact that it contains version bytes. They precede the script and indicate its type. This makes it possible to designate the requirements necessary for the release of bitcoins. In fact, this allows you to lock Bitcoins in many different ways. The potential of this function can be realized by Schnorr’s signatures , which are more compact and verified faster than the current ECDSA signatures, as well as more complex types of multi- signature transactions and even smart contracts like Ethereum.
In practice, locking scripts in SegWit look similarly (this example is taken from a real transaction , not in Bitcoin, but in another technically very similar blockchain - a lightcoin; SegWit is already activated on it):
"scriptPubKey": { "asm": "0 07389b37ea077e9431a2e64530649f8a61befa54", "hex": "001407389b37ea077e9431a2e64530649f8a61befa54", "type": "witness_v0_keyhash" } The script consists of a script version byte (0), followed by 20 bytes corresponding to the usual address in the bitcoin network (public key hash). Viewed from the point of view of a node that knows nothing about SegWit, this script can be spent by anyone, for example, with an empty unlocking scriptSig. In fact, scriptPubKey only adds data to the stack and does not perform any checks for data pushed to the stack by scriptSig before.
When viewed from the point of view of a node that knows about SegWit, this script signals that the witness of the spending transaction should contain a digital signature of the transaction along with the public key, the hash of which is specified in the script. The scriptSig field must be empty.
How exactly it is worth checking the SegWit script, the node determines on the basis of the version byte and the length of the next scriptPubKey element (in the example above, it is 20). So far, two types of scenarios are defined in SegWit: based on the public key (our example) and more complex for arbitrary checks (for example, multisignatures). In the second case, a 32-byte hash of the “real” locking script is written to the scriptPubKey. When spending money, this scenario, along with a suitable unlocking scenario, must be provided in the witness field. In this case, the hash of the locking script must match the value specified in the scriptPubKey.
Lightning network
As part of this material, I would like to mention the Lightning Network (LN) scaling technology, which in many respects becomes possible due to SegWit, and in the development of which BitFury is actively involved. Lightning Network is based on ordinary Bitcoin transactions, only these transactions are not transferred to the Bitcoin network (at least, immediately). Instead, they are stored locally on LN nodes.
The main feature of the Lightning Network is bi-directional “non-trustworthy” payment channels that allow you to exchange bitcoins directly, bypassing the blockchain. Only blocking and closing transactions are broadcast on the blockchain, even if there are millions of payments between them. This allows you to seriously "unload" the blockchain and increase its bandwidth, as well as to carry out microscopic payments (for example, pay for digital content or Internet connection per second). Moreover, LN allows payments to be made through one or more intermediate nodes of a network without the risk that these nodes will steal funds. This provides LN scalability to millions of nodes. In more detail about the principles of work of LN we plan to tell in the subsequent materials.
PS Our jobs at HH and the English-language blog at Medium .
PPS Additional materials on the topic:
Source: https://habr.com/ru/post/330726/
All Articles