jakiro
Author: Chakra; Translation: 0xjs@Bitchain Vision
Bitcoin is the earliest, safest, most decentralized and highest market value blockchain in the world.However, its low transaction volume per second (TPS) and limited programming capabilities are often criticized for their difficulty in supporting large-scale applications, seriously hindering the development of the Bitcoin ecosystem.As a builder of the Bitcoin ecosystem, this article will guide you through the past, present and future of Bitcoin expansion solutions.
This article is the first article in a series of Bitcoin scalability articles, mainly introducing the native expansion solutions implemented in the history of Bitcoin’s main network.The next article will discuss off-chain expansion solutions with higher scalability.Stay tuned.
Increase block size limit
In 2010, Satoshi Nakamoto introduced a 1MB block size limit in bitcoin-core.This clear restriction has not been revised for more than ten years since then.
Interestingly, Satoshi Nakamoto did not publicly explain why he proposed the block size limit, which is “hidden” in the PR of code merge and has no detailed explanation.A few years after Satoshi Nakamoto left, the community had a serious disagreement over block size restrictions, and the demand for larger blocks sparked widespread discussion.
The larger the block, the more transactions it accommodates.Assuming that the consensus time remains unchanged, the larger the block, the higher the TPS.
Why is TPS so important?Because under the 1MB block limit, with the transaction scale at that time, the number of transactions that can be completed per second can only be 3-7 transactions, which is far from enough for large-scale applications, and it is impossible to realize the “point-to-point electronic cash system of Bitcoin”.” Vision.
However, larger blocks also bring problems to varying degrees.
First, larger blocks have higher requirements for hardware such as storage, computing, and bandwidth, resulting in increased operating costs for the entire node.Bitcoin’s historical transaction data is rapidly expanding, requiring new full nodes to spend more time synchronizing with the network.These requirements reduce users’ willingness to operate full nodes, thereby reducing the degree of decentralization.
Secondly, the larger the block, the longer the synchronization time between nodes, the greater the possibility of orphan blocks appearing, resulting in more frequent block reorganization, increasing the risk of forking, greatly reducing security.
Later, this problem was called the blockchain impossible triangle by Vitalik, that is, blockchain cannot achieve decentralization, scalability and security at the same time.The larger the block, the stronger the scalability, but the cost is the weaker the decentralization and security.
The most important thing is that modifying the block size limit requires hard fork, which requires all nodes in the entire network to be upgraded at the same time, otherwise it will lead to network split.This is not a good choice for Bitcoin that relies on decentralized consensus.Under the influence of Satoshi Nakamoto, avoiding hard forks seems to have become the de facto principle of Bitcoin.
Unfortunately, the split did happen.Despite the lack of consensus within the community, some miners and developers have changed the block size limit in the client, which ultimately leads to a network fork.In 2016, Bitcoin Classic used BIP 109 to fork the block size limit to 2MB; in 2016, Bitcoin XT client adopted BIP 101, increasing the block size to 8MB.However, the vast majority of miners and users remain on the Bitcoin mainnet as we know it now.
The effort to explicitly increase the block size by hard fork failed.
Quarantine Witness
If hard forks are unacceptable, can soft forks be used as a solution?SegWit is one of the methods.
Witness is the voucher to unlock UTXO, and for a long time, Witness has been placed in the input script field of UTXO to complete the transaction.However, this method has potential problems such as circular dependence, third-party transaction ductility, and second-party transaction ductility.
As early as 2011, developers noticed this issue and proposed a solution to SegWit, which is about to separate Witness from other transaction data.However, the hard fork proposal at that time was not supported, and it was not until the proposal of SegWit soft fork in 2015 that the merger was finally achieved.
How does SegWit achieve backward compatibility through soft forks?This mainly includes the following two aspects:
-
New version nodes can recognize and accept blocks and transactions generated by old version nodes.
-
Although old version nodes cannot recognize new rules and features introduced by new versions, they still treat blocks generated by new versions as valid.
SegWit soft fork allows new transactions to use empty input scripts and add witness fields in the block structure to store witnesses.Since the Bitcoin core before the upgrade supports empty input scripts, the old version node will not reject blocks generated by the new version.Additionally, by using the version field, old transaction types are still available and nodes process them in different ways depending on the version.
The extension in SegWit is implemented in the form of weights, with the witness byte weights of 1 and the other data bytes being 4, thus limiting the maximum weight of each block to 4 million.Why do you want to assign different weights to different types of data?A common sense idea is that witness data only serves as a verification function when used and does not need to be stored in storage for a long time, so it is relatively low in cost and has low weight.
This actually increases the block size limit in disguise. The theoretical upper limit of block size is increased to 4MB (total thanks to witness data), and on average, the block can reach about 2MB.Judging from the old block structure, this still adheres to the original limit of Satoshi Nakamoto’s block of no more than 1MB per block.
Taproot
Using Bitcoin’s opcodes such as OP_IF, we can set complex conditions for Bitcoin spending scripts, such as time locks, multi-signatures, etc.However, complex spending conditions often require multiple inputs and signatures for verification, thereby increasing block load and reducing transaction speeds while exposing all payment conditions, resulting in privacy leaks.
Taproot uses MAST to enhance Bitcoin, and users use Merkle Trie to indicate spending conditions.Each leaf node represents a spending script. During the spending process, you only need to provide the actual executed script and the corresponding Merkle Path without revealing other conditions.This reduces block space consumption and increases privacy.
The Taproot upgrade also introduces a Schnorr signature that has additive homomorphic properties that allow signature aggregation and batch validation, thereby increasing the overall transactions per second (TPS).The aggregation signature advantage of Schnorr signatures greatly simplifies the logic of validating multi-signature transactions.Previously, ECDSA signatures required sending multiple signatures to the chain to match the script, while Schnorr signatures only required sending a single off-chain aggregate signature to the chain, reducing the use of on-chain space by multi-signature payments.
Complex contract codes are submitted through the MAST root by combining Schnorr signatures with MAST and using the Pay to Contract (P2C) concept to tweak and generate a standard Bitcoin public key that supports payments with a single Schnorr signature.
Interestingly, because the single signature and multiple signatures of Schnorr signatures look the same on the chain, the logic of complex scripts, multiple signatures and single signatures is indistinguishable on the chain, further enhancing privacy.
in conclusion
Bitcoin’s scalability solutions reflect its evolving approach to improving performance while maintaining decentralization and security.
Initially, considering increasing the block size directly addressing the problem of low transaction rates, but raising issues related to node costs and network forks, posing challenges to community consensus.
The introduction of SegWit marks a significant advancement by optimizing block capacity through soft forks, ensuring backward compatibility and avoiding split hard forks.
Taproot then further improved scalability and privacy through MAST and Schnorr signatures, reducing transaction space and improving verification efficiency.More importantly, Taproot can implement complex scripting on Bitcoin, paving the way for future expansion attempts.
These developments highlight Bitcoin’s cautious and innovative move towards a more scalable and powerful network, which is crucial to its future as a global payment system.
However, the impact of these expansion solutions is not enough to realize the vision of a “point-to-point electronic cash system”.
