OBE Guidline Principles

Building upon the abstract system architecture and state transition function outlined above, this paper proposes a set of fundamental design principles for BTC scalability. These principles are considered from two perspectives: the state transition function and system engineering, with the core objective of fostering innovation without compromising security.

Based on the state transition function, we identify three primary design goals: secure representation of state Si, extensible state transition functions Ti, and global network state transition throughput. Corresponding design principles are then presented to address each of these goals

Object	Design Target	Design Principles
Secure Representation of State Si	Asset Security	Globally unique state indexing None State mapping for multi-layer chains None third-party custodial account addresses Guarantee atomic security of transaction queries
	State Saving Mini_Sum(Si)	Secure computation verification for multi-layer state extensions Support for integrity checks and recovery of global state Support for compressing obsolete state data
Extensible Ti Functions	BTC Native OP Code	Soft forks Lightweight transition functions Ti Maximize combinatorial extensibility Compatibility with computation verification function Vi
	Turing-complete computation extensions	subject to satisfying the secure state representation principles Lightweight computation verification function Vi
State Transition Throughput	Increase block capacity	subject to satisfying the secure state representation principles Mitigate hardware dependency Prevent block DDOS attacks
	Accelerate block consensus protocol convergence	subject to satisfying the secure state representation principles Ensure fairness of mathematical algorithms and mitigate scale effects Consensus protocol enhancement based on PoW security foundation

Secure Representation of State

The history of BTC scaling has witnessed diverse exploration, with a primary focus on off-chain ledger expansion. This approach inherently involves creating two sets of ledger states that are mapped to each other. However, this introduces increased insecurity in the representation of on-chain states. Similarly, various proposals for native BTC coloring protocols and transaction extensions can lead to on-chain state pollution and rapid expansion. This presents challenges for decentralized verification Vand impacts the security of state Si.

Therefore, two fundamental elements must be adhered to in the design principles for secure state representation: secure design of the State() query function and control over global state growth Mini_Sum(Si).

Extensible State Transition Functions

Expanding the computational capabilities of the BTC state transition function has been a continuous mission and goal for the community and core developers. In the short term, extending the native BTC finite state machine functions, such as introducing new transaction models and OP Code support, appears more feasible and achievable. However, the ultimate goal is to achieve Turing completeness for BTC, enabling the development of arbitrary applications. Historically, the opcode OP_CAT [5] was proposed for removal from the mainnet by Satoshi Nakamoto due to concerns about nested loops potentially leading to node attacks. Currently, many BTC Layer 2 solutions utilize off-chain virtual machines (VMs) for Turing-complete scaling. However, this approach introduces significant challenges related to the verifiable of computations and the global atomicity of state.

Consequently, the difficulty in designing for BTC scalability lies in the need to increase computational capabilities while adhering to the aforementioned state representation security principles and without compromising computational security verification.

State Transition Throughput

In addition to expanding the computational functions themselves, network transaction throughput has been a persistent obstacle to broader BTC adoption. BTC core developers have maintained strict control over block size, exercising restraint in block size upgrades. In 2010, a soft fork increased the block size to 1MB. In 2017, Segregated Witness (SegWit) [6] was activated, adding a separate data validation area.

The development of native BTC block size and transaction performance has been slow, largely due to a prioritization of security. BSV/BCH, dissatisfied with the native upgrade capabilities, directly forked BTC to create independent validation networks, quickly achieving 32MB block sizes. However, overall developer activity on these networks remains limited, and security concerns continue to hinder their growth.

Therefore, a crucial design principle for BTC throughput is to avoid compromising decentralized security. Specific implementations can involve improvements to consensus protocols or enhancements to engineering capabilities.