Sui 上的 Hashi 测试网上线后，已有 25 家以上机构参与压力测试。项目想解决的不是“BTC 能不能进 DeFi”，而是让 BTC 不离开比特币网络也能参与 DeFi。围绕这一方向，行业讨论的重点也在变化：问题不再只是要不要可编程，而是可编程能力究竟该放在哪一层、哪一种架构里。
万亿美元规模的 BTC 仍大多处于沉睡状态
文章称，比特币市值已超过 1 万亿美元。现货 ETF 和金库策略推动了机构持仓上升，但绝大多数 BTC 仍然处于“沉睡”状态。症结并非机构没有使用意愿，而是市场一直没有找到被认为足够安全的使用方式。
wBTC 和 cbBTC 解决的是“能不能用”的问题，但对应代价是桥和托管风险。用户需要把 BTC 换成包装资产，把信任交给中心化托管方，底层资产也随之离开比特币主网。按文中的说法，这并不是比特币原生金融，而是“借比特币名字的别链金融”。
Hashi 的做法，是让用户在存入 BTC 时，把资金放入为账户生成的 2-of-2 多签比特币地址，底层 BTC 仍留在比特币网络。Hashi 验证者委员会（MPC）与 Guardian Layer 飞地各持一把签名，单独任何一方都无法转走 BTC。Guardian Layer 还可以设置额外防护，对大额或可疑的抵押出入进行放缓或拦截。
这一路径解决的是资产安全层面的顾虑，但没有绕开另一个问题：资产留在比特币多签地址中，可编程逻辑却在 Sui 上执行。用户最终仍要同时信任两套系统，一套是比特币多签的安全模型，另一套是 Sui 的执行环境。文章把这种双系统下的信任与协调成本，定义为新的信任裂缝。
从行业格局看，Hashi 主网的上线时间尚未公布，目前还处在压力测试阶段。与此同时，市场上已有超过 75 个 L2 项目在尝试回答同一个问题，即怎样把闲置 BTC 变成可编程金融的底层资产。文中认为，这些方案中的多数都把资产与可编程性拆到了两条链上。
真正的分歧在于 UTXO 与账户模型的结构差异
文章提到，一些把 SVM 引入比特币 L2 的项目强调“亚秒级速度”，Stacks 的 PoX-5 则推进“自托管、BTC 本位收益”。这些路线各自有其价值，但都要面对同一个结构性问题：资产位于 UTXO 模型里，智能合约却通常运行在账户模型里。
文中将这一定义为架构层面的分歧，而不是技术实现上的小差别。UTXO 模型的优势，是并行性和去中心化。每笔交易相对独立，不依赖全局状态，天然适合高并发处理；代价则是传统 UTXO 脚本表达能力有限，难以承载复杂业务逻辑。
账户模型以 EVM 为代表，优势在于智能合约表达能力更强，开发者更容易实现 DeFi、NFT 和借贷协议。但对应成本也很明确：全局状态竞争会拖慢交易处理速度，Gas 费用在高峰期可能快速上升。
大多数项目采取的办法，是在两种模型之间搭桥：让资产留在 UTXO 链上，把合约放到账户模型链上运行。文章列出了这种方案带来的三类问题：
- 桥风险：资产跨链需要信任桥的验证机制；
- 执行风险：合约执行结果需要反馈到资产所在链；
- 协调成本：两条链的共识、确认时间和回滚机制并不一致。
按照这一框架，Hashi 是把资产留在比特币多签地址中，把合约执行放在 Sui；SVM L2 方案则是把资产桥接进 L2，在 Solana 虚拟机中执行合约；Stacks 通过 PoX 把 BTC 质押到 Stacks 链。文中给出的判断是，这些路线都仍在“包装”或“桥接”资产，还没有真正改动 UTXO 模型本身。
TBC 把图灵完备直接写入 UTXO
相较之下，TuringBitChain（TBC）选择的是另一条路。文章称，TBC 不拆分资产与合约，而是把图灵完备智能合约直接写进 UTXO 模型。这不是一个 L2 方案，而是从比特币原始协议出发，在 Layer-1 上实现 UTXO 图灵完备智能合约。
文中把这一路径的核心差异概括为三项设计。
OP_PUSH_META
文章称，OP_PUSH_META 让脚本第一次可以“看见”自己。脚本能够读取交易内部元数据，包括版本号、锁定时间、输入输出数量，以及上下游交易的哈希指纹。对应结果是，脚本可以回答“我从哪里来、要到哪里去”。
OP_PARTIAL_HASH
OP_PARTIAL_HASH 让脚本可以在受限栈空间里，对任意长度的数据流分段重算哈希。按文中的描述，这不再是简单相信某个哈希值真实存在，而是脚本可以自己一段一段完成验证。
分层 TXID
分层 TXID 机制的作用，是把自省和自证在不同代际之间的成本控制在恒定水平。每一代只需要继承父辈 TXID 这一枚 32 字节指纹，数据携带量不随深度增加。文章把它称作 UTXO 模型下的“遗传式合约”。
在作者看来，这三项设计共同指向同一个目标：在不依赖全局状态的情况下，实现接近 EVM 级别的合约表达能力。
性能数据与生态现实同时摆在面前
文中列出的性能数据包括：TBC 主网 TPS 已超过 13,000，初始区块上限为 4GB，费用会随着用户增长而递减。这被用来对照传统区块链中“用户越多、费用越高”的常见局面。
不过，文章也明确提到这条路径的现实代价。TBC 的生态应用规模仍处于早期阶段。相比之下，Hashi 已公布 25 家以上机构合作伙伴名单，其中包括 BitGo、Cumberland、OCC 持牌银行 Erebor，以及 SEC 注册投顾 Wave Digital Assets。围绕合规产品和机构工具链的成熟度，TBC 目前还无法与之对标。
与此同时，UTXO 开发的学习成本也被点出。习惯 EVM 的开发者，仍需要适应新的合约范式。随着这一赛道升温，竞争也在同步加剧，TBC 还需要补齐生态和应用层短板。
争论的焦点已转向“可编程性写在哪”
文章最后认为，Hashi 的测试网上线释放出的信号在于，市场正在从“要不要可编程”转向“可编程写在哪”。机构并不满足于把包装资产拿去做 DeFi，而是希望同时获得原生 BTC 的安全锚点和可编程能力的灵活性。
TBC 给出的主张则是，资产和合约逻辑不应被拆到两条链上。若把图灵完备能力直接写进 UTXO，让交易自身成为状态载体，状态沿着 UTXO 传递，那么当 BTC 被用作 DeFi 抵押品时，借贷、清算、质押等合约执行就可以放在与资产相同的安全模型中完成。
围绕 BTC 是否会成为可编程金融的底层，文中的追问很直接：可编程性到底写在外部虚拟机里，还是写在 UTXO 本身？Hashi 的 25 家机构正在测试“BTC 不离开比特币网络”的可行性，TBC 则在测试“不离开 UTXO 模型”的可编程能力。两条路线都在回应同一个问题，只是给出的答案并不相同。
文章最终给出的判断是，25 家机构当前测试的是资产安全，而真正的考验在于：当合约逻辑与资产安全需要在同一条链上完成时，哪条路径能够真正跑通。