当我们说“BTC Layer 2”，其实说的是一种愿景：在不改变比特币底层共识的前提下，赋予它更高的扩展性与可编程能力。这个方向上已经有不少尝试，比如 Stacks、Merlin、Hemi 等，而我一直认为，真正值得对比的，是 Stacks 和 Hemi：一个是老牌方案，另一个是后来者，但它们的技术路线截然不同，也正因为如此，才让比较更有价值。 Stacks 是很多人最早接触到的比特币扩展协议，它建立了自己的链，并引入了 Clarity 语言以实现智能合约，同时通过一种称为“锚定比特币”的方式，把区块状态写入 BTC 主链来获得某种意义上的安全性继承。但 Stacks 本质上更像是一个“平行链”而不是“Layer 2”，它并不能读取或实时交互比特币上的状态，也就是说，比特币对它而言是静态的、不可感知的。这种模式更接近“贴着 BTC 的独立链”。 而 Hemi 的切入角度则非常不同。它没有试图重新发明一个合约语言，而是直接兼容 EVM，意味着开发者可以直接使用 Solidity 开发智能合约。更关键的是，Hemi 构建了 hVM 和 hBK 两大核心模块，其中 hBK 是一个能够原生访问比特币链状态的工具集。这就让 Hemi 的智能合约可以感知 UTXO 是否被花费、某地址是否收到资金、某个 BTC 交易是否上链，甚至可以作为触发某些链上行为的条件。 你会发现，Stacks 和 Hemi 最大的区别，不是在性能上，而在于“能不能读懂 BTC 状态”。在我看来，这才是真正决定是否配得上 BTC L2 之名的标准。 很多人说 Stacks 有更成熟的生态、更早的社区，但这也恰恰是它的瓶颈：生态习惯于一个和 BTC 本身几乎没有互动的开发模式。而 Hemi 从一开始就不是做一个“比特币旁边的链”，它是把比特币变成一等公民纳入智能合约世界。它不只是要支持 BTC 资产的使用，更是要让 BTC 状态成为合约逻辑的一部分。 再从安全模型来看，Stacks 依赖的是一种链上“锚定”机制，但它并不具备真正的不可逆状态验证。而 Hemi 的 PoP（Proof-of-Proof）机制，是直接把 Hemi 的状态哈希锚定进比特币区块，一旦写入就不可更改。这意味着即便 Hemi 自己发生回滚或被攻击，也无法修改已经被比特币记录下来的链状态，这种终极背书，是目前我看到最接近“BTC 本体信任”的做法。 当然，如果你只是想做一个 DEX 或普通的合约应用，Stacks 已经足够。但如果你的野心是构建真正理解 BTC、以 BTC 行为为输入变量的 DApp，那么 Hemi 显然是更适合的环境。 这就像一个懂你的朋友 VS 一个站在你身边却听不懂你说话的人——我更愿意选前者。Hemi 能听懂 BTC，不是通过中间桥或预言机，而是通过原生读取、逻辑融合。这种底层设计上的尊重与对接，才是我心中 BTC L2 的正确打开方式。@Hemi $HEMI #Hemi