OBE 设计原则

在上述抽象的系统架构和状态转移函数的基础上，本文可以更为清晰的提出一些基本扩展性设计准则，从两个不同的角度：状态转函数和系统工程角度，核心宗旨是不牺牲安全的前提下进行创新探索。

我们从状态函数的基础上，总结出三个核心的设计目标：状态Si的安全表达，状态机的Ti 的丰富扩展性以及全网的状态转移吞吐能力，并提出相应的设计准则。

设计对象	核心目标	设计准则
状态Si的安全表达	安全的State()函数	全局唯一的状态索引 无状态映射 保证交易查询的原子安全
	最小化状态Mini_Sum(Si)	扩展多层状态需要安全计算验证 全局状态支持完整性校验和恢复 支持压缩垃圾状态
状态机的Ti 的丰富扩展性	指令集OP _Code扩展	软分叉 轻量化转移函数Ti 具备最大化的组合扩展性 计算验证函数V兼容
	图灵计算扩展	满足上述状态安全表达设计准则 轻量化计算验证函数V
全网的状态转移吞吐能力	区块容量增加	满足上述状态安全表达设计准则 抑制硬件依赖 防止区块DDOS攻击
	区块共识协议收敛加快	满足状态安全表达设计准则 数学算法公平，抑制规模效应

状态Si的安全表达

在BTC扩展的历史上，我们看到了多样化的探索尝试，其中最主要的方向是链下账本扩容，本质上需要创建两套账本状态，并且相互映射，这种方案就显示的增加了链上状态表达的不安全性。同时，多种BTC原生的染色协议和交易扩展等提案，都会带来链上状态的污染和极速膨胀，为去中心化验证V带来了更多的挑战，影响了状态Si的安全性。

因此在Si的安全表达设计准则中，有俩个基本要素需要遵守：安全的State()查询函数设计以及全局状态增长控制Mini_Sum(Si)。

状态机的Ti 的丰富扩展性

关于扩展BTC状态函数的计算能力，一直都是社区和核心开发者的使命和目标。从短期来看，扩展BTC原生的有限状态机函数会更加容易和可落地，比如新的交易模式和OP Code支持等。但是最终目标还是BTC具备计算图灵完备性，从而支持任意的上层应用开发。历史上OP CAT[5]指令集曾经被被中本聪提议移除主网，主要是循环嵌套容易造成节点被攻击。目前众多BTC L2基于链下虚拟机VM进行图灵扩容，但是计算的可验证能力和状态全局原子性都带来了很大的挑战。

因此，BTC的扩展性设计难度在于既要增加计算的能力又要符合上述状态表达的安全性，并且不影响计算安全性验证。

全网的状态转移吞吐能力

除了支持计算函数本身的扩展，全网交易吞吐能力一直是BTC应用拓展的阻碍。BTC核心开发者一直控制区块本身的大小，非常克制的进行区块大小升级，2010年软分叉升级到1MB区块空间，2017年升级激活了隔离见证(SegWit)[6]，单独增加了数据验证区域。原生的BTC区块大小和交易性能一直发展的很慢，很重要的原因是妥协于安全性。BSV/BCH不满足原生的升级能力，直接分叉BTC开启了独立的验证网络，很快实现了32MB的大区块网络，但是整体开发者发展很缓慢，安全性的担忧一直是发展的瓶颈。

因此BTC的吞吐能力设计一个重要的设计准则就是：不影响去中心化安全能力，具体设计落地可以是共识协议的改进或者工程能力的提升。