June 13, 2017 at 10:18How to scale bitcoin blockchain
In one of our previous materials, we noted that the main advantages of the blockchain are openness, security and security. However, any technology always has certain disadvantages.
Bitcoin, as the largest, most popular and most reliable blockchain, is also not without such ones, however, the community actively solves them. Therefore, in today's post, we will address the following issues:
/ image Susana Fernandez CC
Today, banks, energy companies, participants in the Internet of Things market and government organizations are actively eyeing the blockchain. For example, Bank of America and Microsoft began a joint development of the financial blockchain platform, and Chronicled launched the blockchain platform for the Internet of things, which creates digital identifiers that are secure and compatible with many other systems. However, the environment and the conditions in which Bitcoin works, are significantly different from what they were at the time of the cryptocurrency's inception. The number of users has grown to several tens of millions of people ( more than 13 million), which caused an increase in the number of daily transactions ( about400 thousand).
The amount of resources that you have to spend on running the software and storing the Bitcoin registry with a list of transactions is quite large. The entire Bitcoin blockchain transaction chain is traceable starting from 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 bitcoin scaling 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 probable DoS attacks by attackers when they create large (in theory unlimited) blocks to paralyze the network.
However, this security measure had a negative effect on the throughput of the network as a whole (in the long run). To date, Bitcoin can processabout 7 transactions per second (TPS). At the same time, the actual load on the bitcoin network is 3.5 TPS. For comparison, the TPS in the Visa system is 2,000 (at times of peak activity - 50,000).
The first suggestions for improving bitcoin were presented in 2015 ( BIP 100 and BIP 101 ) by core developers Jeff Garzik and Gavin Andresen. Both solutions suggested increasing the block size, but they were hard forks, that is, they did not have backward compatibility. This meant that when they were implemented, the old software became incompatible with the new network. In BIP 100, it was proposed to adjust the block size according to the decision of the miners, and in BIP 101 it was proposed to increase the block size to 8 megabytes at a time.
At that time, an increaseblock sizes was the simplest solution from a technical point of view, however, none of the schemes were ever implemented. The 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 would be able to allocate such volumes of resources. Thus, there would be a contradiction with the main idea of the Bitcoin blockchain as a user-managed cryptocurrency.
At the end of 2015, developer Peter Wuille presented a proposal called Segregated Witness to increase network bandwidth. The approach did not change block sizes, but the way transactions were stored. One of the advantages of the solution was the possibility of its implementation through soft fork (that is, providing backward compatibility). After the release of the Segregated Witness technical description, the proposed solutions to the scalability problem were divided into two groups: some sought to increase the block size, while others sought to leave the block unchanged, optimizing other aspects of the protocol. No consensus was reached on this issue. Until recently.
On May 20, the key players in the bitcoin industry were still able to find common ground. The participants in the Hong Kong Bitcoin Roundtable Consensus conference (including BitFury) agreed to support several upgrades to the Bitcoin protocol. One of them is the activation of Segregated Witness upon reaching a support level of 80% (miner capacity). The second is associated with an increase in block size up to 2 MB. This decision even affected the cost of bitcoin. Interest in cryptocurrency and new opportunities for scaling the blockchain 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 releases 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 component of the transaction contains a set of outputs (ScriptPubKeys scripts) that lock the freed bitcoins (or slightly less). Each locking script determines the conditions under which the corresponding bitcoins can be spent (for example, provided that a certain private key is known). It turns out that bitcoins move from inputs to outputs of a transaction and from one transaction to another.
Locking and unlocking of bitcoins is carried outsenders of transactions, and is broadcast over the network in the form of information packets. The outputs that lock bitcoins, as a rule, contain instructions, the meaning of which is to make sure that the user knows the desired private key corresponding to the specified public key.
Segregated Witness technology modifies this chain of interactions. The newly created conclusions begin to use a different type of locking script, which was called "anyone can spend" (anyone can spend), because it does not require digital signatures, and at first glance it can be spent by anyone. The trick is that a locking script of the form anyone can spend contains a specific sequence of bytes that binds to the script the "real" conditions for spending bitcoins.
A similar technique is usedin P2SH (Pay to Script Hash). As with SegWit, with P2SH, bitcoins are still locked in the script, however, not the locking script itself, but its hash is added to the transaction output. In order to spend the bitcoins locked by such a script, you need to know not only the “real” locking script (as it might seem when you first read scriptPubKey), but also the unlocking scriptSig for this script (for example, digital signature).
Segregated Witness, in fact, highlightsscriptSig (transaction signatures) into a separate data structure - witness (evidence). Thus, SegWit is an addon that is completely ignored by the old nodes, but recognized as new. Both old and new nodes consider transactions with SegWit to be correct: the former see scripts “anyone spends” and consider the transaction correct (albeit strange in terms of semantics), and the latter refer to the signature in witness. Due to this, the technology allows to eliminate transaction smoothness (tx malleability), save disk space and optimize the speed of signature verification.
There is, however, a slight difficulty: if the signatures do not affect the hashes of the transactions, it can no longer be a proof that for the transactions included in the block, valid signatures exist in nature. To get around this feature, the miner writes a hash in a certain place in the block, depending on all witness in the transactions, which is calculated similarly to the block transaction hash, that is, using Merkle trees.
Another advantage of SegWit is the fact that version bytes are stored in it. They precede the script and indicate its type. This makes it possible to indicate the requirements necessary for the release of bitcoins. In fact, this will allow you to lock bitcoins in a variety of ways. Schnorr's signature will be able to realize the potential of this function.which are more compact and verified faster than current ECDSA signatures, as well as more complex types of multisignature transactions and even smart contracts like Ethereum.
In practice, locking scripts in SegWit look like this (this example is taken from a real transaction , but not in bitcoin, but in another blockchain very similar from a technical point of view - lightcoin; SegWit is already activated on it):
The script consists of a byte of the script version (0), after which there are 20 bytes corresponding to the usual address in the bitcoin network (public key hash). Seen from the point of view of a node that does not know anything about SegWit, this script can be spent by anyone, for example, an empty unlocking script scriptSig. In fact, scriptPubKey only adds data to the stack and does not perform any checks on the data pushed onto the stack by the scriptSig script.
If you look from the point of view of a node that knows about SegWit, this script signals that the witness field of the spending transaction should contain a digital signature of the transaction along with the public key whose hash is specified in the script. The scriptSig field must be empty.
How it is worth checking the SegWit script, the node determines based on the version byte and the length of the next scriptPubKey element (in the example above - 20). So far, 2 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 scriptPubKey. When spending money, this script, together with a suitable unlocking script, should be provided in the witness field. In this case, the hash of the locking script must match the value specified in scriptPubKey.
As part of this material, I would like to mention the Lightning Network (LN) scaling technology, which is made possible largely due to SegWit, and in the development of which BitFury is actively involved. The Lightning Network is based on ordinary Bitcoin transactions, only these transactions are not transferred to the Bitcoin network (at least right away). Instead, they are stored locally on the nodes of the LN network.
The main feature of the Lightning Network is its bidirectional “untrusted” payment channels that allow you to exchange bitcoins directly, bypassing the blockchain. Only transactions that open and close the channel are transmitted to the blockchain, even if millions of payments have been made between them. This allows you to seriously “unload” the blockchain and increase its throughput, as well as make microscopic payments (for example, pay for digital content per second or Internet connection). Moreover, LN allows payments through one or more intermediate network nodes without the risk that these nodes can steal funds. This ensures scalability of LN to millions of nodes. We plan to tell you more about the operating principles of LN in subsequent materials.
PS Our vacancies at HHand the English-language blog on Medium .
PPS Related Resources:
Bitcoin, as the largest, most popular and most reliable blockchain, is also not without such ones, however, the community actively solves them. Therefore, in today's post, we will address the following issues:
- What is the biggest drawback of bitcoin blockchain?
- What solutions did the global community offer?
- Which one will become part of the bitcoin network?
/ image Susana Fernandez CCToday, banks, energy companies, participants in the Internet of Things market and government organizations are actively eyeing the blockchain. For example, Bank of America and Microsoft began a joint development of the financial blockchain platform, and Chronicled launched the blockchain platform for the Internet of things, which creates digital identifiers that are secure and compatible with many other systems. However, the environment and the conditions in which Bitcoin works, are significantly different from what they were at the time of the cryptocurrency's inception. The number of users has grown to several tens of millions of people ( more than 13 million), which caused an increase in the number of daily transactions ( about400 thousand).
The amount of resources that you have to spend on running the software and storing the Bitcoin registry with a list of transactions is quite large. The entire Bitcoin blockchain transaction chain is traceable starting from 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 bitcoin scaling 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 probable DoS attacks by attackers when they create large (in theory unlimited) blocks to paralyze the network.
However, this security measure had a negative effect on the throughput of the network as a whole (in the long run). To date, Bitcoin can processabout 7 transactions per second (TPS). At the same time, the actual load on the bitcoin network is 3.5 TPS. For comparison, the TPS in the Visa system is 2,000 (at times of peak activity - 50,000).
Early suggestions for resolving a problem
The first suggestions for improving bitcoin were presented in 2015 ( BIP 100 and BIP 101 ) by core developers Jeff Garzik and Gavin Andresen. Both solutions suggested increasing the block size, but they were hard forks, that is, they did not have backward compatibility. This meant that when they were implemented, the old software became incompatible with the new network. In BIP 100, it was proposed to adjust the block size according to the decision of the miners, and in BIP 101 it was proposed to increase the block size to 8 megabytes at a time.
At that time, an increaseblock sizes was the simplest solution from a technical point of view, however, none of the schemes were ever implemented. The 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 would be able to allocate such volumes of resources. Thus, there would be a contradiction with the main idea of the Bitcoin blockchain as a user-managed cryptocurrency.
Segregated witness
At the end of 2015, developer Peter Wuille presented a proposal called Segregated Witness to increase network bandwidth. The approach did not change block sizes, but the way transactions were stored. One of the advantages of the solution was the possibility of its implementation through soft fork (that is, providing backward compatibility). After the release of the Segregated Witness technical description, the proposed solutions to the scalability problem were divided into two groups: some sought to increase the block size, while others sought to leave the block unchanged, optimizing other aspects of the protocol. No consensus was reached on this issue. Until recently.
On May 20, the key players in the bitcoin industry were still able to find common ground. The participants in the Hong Kong Bitcoin Roundtable Consensus conference (including BitFury) agreed to support several upgrades to the Bitcoin protocol. One of them is the activation of Segregated Witness upon reaching a support level of 80% (miner capacity). The second is associated with an increase in block size up to 2 MB. This decision even affected the cost of bitcoin. Interest in cryptocurrency and new opportunities for scaling the blockchain 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 releases 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 component of the transaction contains a set of outputs (ScriptPubKeys scripts) that lock the freed bitcoins (or slightly less). Each locking script determines the conditions under which the corresponding bitcoins can be spent (for example, provided that a certain private key is known). It turns out that bitcoins move from inputs to outputs of a transaction and from one transaction to another.
Locking and unlocking of bitcoins is carried outsenders of transactions, and is broadcast over the network in the form of information packets. The outputs that lock bitcoins, as a rule, contain instructions, the meaning of which is to make sure that the user knows the desired private key corresponding to the specified public key.
Segregated Witness technology modifies this chain of interactions. The newly created conclusions begin to use a different type of locking script, which was called "anyone can spend" (anyone can spend), because it does not require digital signatures, and at first glance it can be spent by anyone. The trick is that a locking script of the form anyone can spend contains a specific sequence of bytes that binds to the script the "real" conditions for spending bitcoins.
A similar technique is usedin P2SH (Pay to Script Hash). As with SegWit, with P2SH, bitcoins are still locked in the script, however, not the locking script itself, but its hash is added to the transaction output. In order to spend the bitcoins locked by such a script, you need to know not only the “real” locking script (as it might seem when you first read scriptPubKey), but also the unlocking scriptSig for this script (for example, digital signature).
Segregated Witness, in fact, highlightsscriptSig (transaction signatures) into a separate data structure - witness (evidence). Thus, SegWit is an addon that is completely ignored by the old nodes, but recognized as new. Both old and new nodes consider transactions with SegWit to be correct: the former see scripts “anyone spends” and consider the transaction correct (albeit strange in terms of semantics), and the latter refer to the signature in witness. Due to this, the technology allows to eliminate transaction smoothness (tx malleability), save disk space and optimize the speed of signature verification.
There is, however, a slight difficulty: if the signatures do not affect the hashes of the transactions, it can no longer be a proof that for the transactions included in the block, valid signatures exist in nature. To get around this feature, the miner writes a hash in a certain place in the block, depending on all witness in the transactions, which is calculated similarly to the block transaction hash, that is, using Merkle trees.
Another advantage of SegWit is the fact that version bytes are stored in it. They precede the script and indicate its type. This makes it possible to indicate the requirements necessary for the release of bitcoins. In fact, this will allow you to lock bitcoins in a variety of ways. Schnorr's signature will be able to realize the potential of this function.which are more compact and verified faster than current ECDSA signatures, as well as more complex types of multisignature transactions and even smart contracts like Ethereum.
In practice, locking scripts in SegWit look like this (this example is taken from a real transaction , but not in bitcoin, but in another blockchain very similar from a technical point of view - lightcoin; SegWit is already activated on it):
"scriptPubKey": {
"asm": "0 07389b37ea077e9431a2e64530649f8a61befa54",
"hex": "001407389b37ea077e9431a2e64530649f8a61befa54",
"type": "witness_v0_keyhash"
}The script consists of a byte of the script version (0), after which there are 20 bytes corresponding to the usual address in the bitcoin network (public key hash). Seen from the point of view of a node that does not know anything about SegWit, this script can be spent by anyone, for example, an empty unlocking script scriptSig. In fact, scriptPubKey only adds data to the stack and does not perform any checks on the data pushed onto the stack by the scriptSig script.
If you look from the point of view of a node that knows about SegWit, this script signals that the witness field of the spending transaction should contain a digital signature of the transaction along with the public key whose hash is specified in the script. The scriptSig field must be empty.
How it is worth checking the SegWit script, the node determines based on the version byte and the length of the next scriptPubKey element (in the example above - 20). So far, 2 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 scriptPubKey. When spending money, this script, together with a suitable unlocking script, should be provided in the witness field. In this case, the hash of the locking script must match the value specified in scriptPubKey.
Lightning network
As part of this material, I would like to mention the Lightning Network (LN) scaling technology, which is made possible largely due to SegWit, and in the development of which BitFury is actively involved. The Lightning Network is based on ordinary Bitcoin transactions, only these transactions are not transferred to the Bitcoin network (at least right away). Instead, they are stored locally on the nodes of the LN network.
The main feature of the Lightning Network is its bidirectional “untrusted” payment channels that allow you to exchange bitcoins directly, bypassing the blockchain. Only transactions that open and close the channel are transmitted to the blockchain, even if millions of payments have been made between them. This allows you to seriously “unload” the blockchain and increase its throughput, as well as make microscopic payments (for example, pay for digital content per second or Internet connection). Moreover, LN allows payments through one or more intermediate network nodes without the risk that these nodes can steal funds. This ensures scalability of LN to millions of nodes. We plan to tell you more about the operating principles of LN in subsequent materials.
PS Our vacancies at HHand the English-language blog on Medium .
PPS Related Resources: