BTC Native Extension Design

Current Limitations and Constraints of BTC Scaling

The original BTC protocol was launched in 2009, and its white paper basically laid the foundation for 90% of the design scheme, including the PoW security mechanism and the asymmetric key verification system. With the continuous evolution of community development (BIPs), BTC has also made slow progress in scalability. The Taproot upgrade brought larger data storage space, Schnorr signatures, and new OP Code operations to BTC. From the historical BIP proposals, it can be seen that BTC upgrades require the broad developer consensus and miner incentives. New protocol proposals need to be as upward compatible and lightweight as possible, and the core requirement remains to expand performance and functionality under the premise of security.

Based on the aforementioned basic BTC design architecture, State Lab attempts to propose a possible on-chain native extension solution. The main design goals are to achieve performance improvement, transaction privacy protection, and richer state transition functions without sacrificing the original security of BTC. The main architecture design is shown in the following figure.

Data IO Performance Improvement under the Premise of Security

Under the current BTC architecture, improving throughput performance is a complex problem to be solved, especially to ensure that there is no security compromise. BTC is essentially an IO processing system, including read/write, data storage, and index query modules. Under the premise of not changing the POW consensus protocol, optimizing the performance of data IO is a feasible path with relatively high feasibility. In this article's design, we try to add some embedded modules to enhance the performance of the data system, including state data, hybrid index query (HTAP), and fast verification trees.

State Data

Currently, BTC's ledger only contains the UTXO transactions. Querying historical states requires reconstructing transactions from the beginning. This structure limits fast on-chain state query and update, making it unable to support complex on-chain script extensions or even contract support.

The new state module can be a separate data area, providing read, write, and query storage space. It's similar to the witness space but more suitable for state data modules with small data volumes and high IO.

Hybrid Index Query

Currently, BTC's core persistent storage mainly relies on the local file system and LevelDB database. Original transaction details are stored in local files, and core metadata is in LevelDB. This data module is relatively coarse-grained. The file system has poor read and write performance, while LevelDB is a storage engine with excellent write performance, a typical implementation of LSM tree (Log Structured-Merge Tree). The core idea of LSM tree is to sacrifice some read performance in exchange for maximum write capability, and it doesn't support establishing indexes for point queries.

BTC's data IO optimization has two key requirements: fast point queries for transaction details and high-throughput writes for the ledger. Under these requirements, referencing the classic approach in the database industry, a hybrid data engine (HTAP Engine)[7] can be designed to handle data persistence, providing both atomic transaction support and high-throughput read and write capabilities.

Fast Verification

Bitcoin's native computation verification relies primarily on asymmetric cryptography and Merkle trees. This verification data structure efficiently confirms data tampering within a block through the root hash algorithm, offering a concise and effective solution. However, as throughput increases, limitations emerge, such as slow Merkle tree construction and state bloat at the leaf nodes. This has led to widespread discussion and proposals for new data structures based on advanced cryptographic techniques. One such idea is the utilization of zero-knowledge (ZK) Merkle tree structures, which offer both state compression and improved verification efficiency.

Lightweight Script Extension and Mini_VM

Currently, BTC only supports a limited set of script OP codes[8]. Compared to ETH, it lacks rich underlying programmability support at the application layer. The reason why BTC's programmability has always been constrained is mainly to prevent state bloat and heavy computational reliance, which could lead to the threat of centralized deployment.

Due to the continuous upgrade of hardware, bringing increased computing power, under the premise of optimized data IO modules, more OP Codes can be introduced appropriately based on scenarios. For example, transaction state conditional operations (OP State), complex signature verification mechanisms (OP Sign), etc. For instance, currently, BTC's cross-chain asset security mainly relies on off-chain security designs. If OP State can support on-chain state self-locking, mapping, unfreezing, and other operations, it can achieve asset cross-chain to the greatest extent possible without transferring BTC to third-party accounts.

With ongoing enrichment of the underlying opcode support, particularly the introduction of opcodes that enable recursive nesting, it becomes possible to abstract higher-level, lightweight scripting languages and provide virtual machine support. In the near term, these languages might not be Turing-complete but can be optimized for developer experience. However, in the long run, this development path paves the way for the design and implementation of a Turing-complete virtual machine for Bitcoin, providing the necessary foundation and functionality.

Controllable Privacy Transactions

Currently, although BTC address information is not KYC-linked, all transactions are publicly queryable, ensuring privacy to a certain extent. However, this also leads to user privacy leakage in actual payment scenarios. While anonymous chains like Monero and Zcash completely hide transaction information, they belong more to anonymous systems and also bring chaotic governance issues. The difference between privacy and anonymity lies in controllable data sharing, designing different data protection themes centered around user needs.

Achieving permission-controlled transaction privacy in BTC based on advanced cryptographic protocols is a relatively long-term topic. New cryptographic algorithms based on FHE[9] and ABE[10] may bring more practical use cases.