BTC链上原生的扩展设计

目前BTC扩展性约束

BTC原始协议上线于2009年，在协议白皮书中基本奠定了90%的设计方案，包括PoW工作量安全机制、非对称密钥验证体系等。随着社区开发(BIPs)的不断演进，BTC在扩展性也有了缓慢的进展，Taproot升级给BTC带来了更大的数据存储空间、Schnorr 签名以及新的OP Code操作等。从历史BIP提案中可以看出，BTC的升级需要凝聚广泛的开发者共识和矿工利益激励，新的协议提议需要尽可能的向上兼容和轻量化扩展，做核心的需求依旧在安全性的前提下扩展性能和功能。

基于上述的BTC基本设计架构，本文尝试提出一种可能链上原生扩展方案，主要设计目标是不牺牲BTC原始安全性实现：TPS性能提升，交易隐私保护以及更丰富的状态转移函数，主要架构设计如下图。

在上述BTC的抽象系统架构基础上，我们可以基于不同模块进行优化设计来提升整体的扩展性和吞吐能力，主要包含了三个方向：安全前提下的数据IO性能优化、轻量化的脚本语言和Mini_VM、可控隐私化交易。

安全前提下的数据IO性能优化

在目前BTC的架构下，吞吐性能的提升是一个很复杂的问题待解决，特别是要保证基本的安全水准不降低。BTC本质上也是一个IO数据处理系统，包括了读写IO、数据存储和索引查询等模块。在不改变POW共识协议的前提下，优化数据IO的性能是一个可行性比较高路径。本文设计中，尝试增加一些嵌入模块来增强数据结构系统的性能，包含了全局状态数据、混合索引查询(HTAP)、快速验证树。

全局状态数据。由于BTC目前的账本中只有UTXO交易账本，对于历史状态的查询需要从头构建交易重放，这种结构限制了链上的状态快速查询和更新，无法支持复杂的链上脚本扩展、甚至合约支持。新的状态模块可以是单独的数据区域，提供读写、查询的存储空间。类似于witness空间，但是更适用于小数据体量、高IO的状态数据模块。

混合索引查询(HTAP)。目前BTC的核心持久化存储主要依赖于文件系统和level DB数据库，原始明细交易存储在本地文件，核心的元数据在level DB。这种数据模块是相当比较粗放的，文件系统的读写性能很差，leveldb是一个写性能十分优秀的存储引擎，是典型的LSM树(Log Structured-Merge Tree)实现。LSM树的核心思想就是放弃部分读的性能，换取最大的写入能力，并且不支持建立索引点查。

BTC的数据扩容有俩个关键的要求，交易明细的快速点查以及账本大吞吐写入。在这种需求下，参考数据库行业的经典做法，可以设计一种支付事务和高吞吐写、读的混合数据引擎(HTAP Engine)[7]来提供数据落盘的环节。

快速验证树。原生的BTC计算验证主要依赖于非对称密钥体系和Merkle树，这种验证数据结构可以快速的通过Root Hash算法来确认区块中的数据篡改，简洁高效。但是随着吞吐设计的提升，存在Merkle树构建缓慢，叶子节点状态膨胀等问题。基于高阶密码算法构建新的数据结构的想法被广泛的提出和讨论，比如基于ZK的Merle树结构，在压缩状态的同时还可以提高验证效率。

轻量化的脚本语言和Mini_VM

目前BTC只支持有限的脚本Script操作码[8]，相比较ETH而言，在应用曾缺乏丰富的底层可编程能力的支持。之所以BTC可编程能力一直受到约束，主要是为了防止状态膨胀和大计算量依赖，带来中心化部署的威胁。

由于硬件的不断升级带来算力的提升，在优化的数据IO模块前提下，可以根据场景合适的带来更多的OP Code。比如，交易状态条件操作(OP State)，复杂的签名验证机制(OP Sign)等。举例来说，当前BTC的资产跨链安全性基本依赖于链下安全设计，如果OP State能支持链上状态自锁定、映射、解冻等操作，就可以尽大可能的不转移BTC到第三方账户情况下实现资产的跨链。

在不段丰富的底层OP Code支持的基础上，特别是支持递归嵌套的操作码，就可以抽象出更高阶的轻量化脚本语言以及虚拟机支持，短期内可以是非图灵完备但开发者优化的语言。但从长期来看，该发展路线为BTC图灵虚拟机设计提供了路线和底层功能支撑。

可控隐私化交易

目前BTC虽然地址信息没有KYC关联，但是实际上所有的交易都公开可查询，一定程度上保证了安全性，但是在实际支付等场景中也带来了用户隐私泄漏。虽然有门罗、Zcash这些匿名链完全隐藏了交易信息，但是这种更属于匿名系统，也带来了混乱的治理问题。隐私和匿名的不同在于，可控的数据信息分享，以用户的需求为中心设计不同的数据保护主题。

BTC基于高级密码协议实现权限可控的交易隐私是一个比较长期的话题，基于FHE[9]、ABE[10]的新密码算法可能带来更多的落地案例。