过去半个月，OP_NET 与 Arch 这两个比特币主网上的智能合约实现方案引发了较多的讨论。有意思的事情是，OP_NET 这个名字与大家熟悉的 OP_CAT 很像，都以「OP_」开头，具有很强的、让大家认为这哥俩差不多的迷惑性。
所以，在开篇要和大家先提一嘴 OP_CAT。首先，OP_CAT 是比特币操作码，从去年开始有以「量子猫」Quantum Cats，也就是「大巫师」Taproot Wizards 的创始人 Udi Wertheimer 为首的社区力量一直在呼喊要「复活」OP_CAT。说是「复活」，是因为 OP_CAT 是本就存在的比特币操作码，但中本聪在 2010 年将该操作码因可能导致潜在的 DoS 攻击的原因给去除了。CAT 是「concatenate」一词的缩写，如同这个词的意思，OP_CAT 的作用就是允许进行字符串的连接操作，将两个字符串拼接成一个。
那么这个操作码如何使比特币实现智能合约？讲真的这真的非常抽象难懂，因此在这里我推荐有兴趣的朋友阅读来自另一位律动作者 Jaleel 的文章（「13 行代码助力比特币实现智能合约？读懂 OP_CAT 软分叉」）。在这里我想为大家快速总结的几个要点是：
OP_CAT 涉及到比特币网络的软分叉，而要走到这一步，首先需要 BIP-347 提案通过，目前该提案仅进展到整个提案流程的第二阶段「Proposed」状态。
在 BCH 和 BSV 上的 OP_CAT 已经复活了几年有余，但是相关的用例还是非常抽象。在目前的讨论中，我们几乎看不到特别清晰直接的、到底用 OP_CAT 能做出一个什么样的 dApp 这种程度的案例。
OP_CAT 不是一步到位的「解药」，复活 OP_CAT 更像是解除比特币智能合约封印的第一步。合理的期待是，如果 OP_CAT 能够成功复活，一些优秀的用例出现，随后又会继续讨论解锁更多的比特币操作码。我们可以先期待在激活了 OP_CAT 的 Fractal 上会不会有令我们耳目一新的创新出现。
而 OP_NET 实际上应该归为符文、BRC-20、ARC-20 这些「协议」一类。虽然它的名字也有一个「OP_」，但其实现方式和比特币操作码完全没有关系。
OP_NET
OP_NET 的框架大体上可以分为两个部分，首先既然是比特币主网的智能合约实施方案，那么比特币主网一定在整个技术框架中占据了一部分。可以说，比特币主网在 OP_NET 的技术框架中扮演的角色是「行为发起层」与「最终确认层」。而智能合约的执行与状态确认则是另一部分，也就是 OP_VM 和 OP_NET 节点共同组成的「执行层」。
从上图我们可以大概地阐述 Arch 的工作流程。用户从比特币主网发起交易，Arch 节点嗅探交易并进行处理与验证，领导者节点则负责「区块事务」，即建立 Arch 网络的区块，另外还负责将最终确认的比特币交易提交回比特币主网。
看上去和 OP_NET 有点像？但其实如果仔细阅读 Arch 的官方文档，会发现他们在如何保证网络稳定性以及其它与「执行层」相关的技术阐述中要比 OP_NET 更详细一些。比如他们使用了「FROST + ROAST」的签名方案，使得 Arch 能够确保只要 51% 的网络成员诚实且合作，就可以签署签名来保证网络的稳健性。
最后，虽然 Arch 有自己的 Token 作为「执行层」也就是 Arch 网络的 Gas 费用，但是用户在通过 Arch 来进行合约交互的时候还是可以用比特币支付，费用转换会在后端进行。因此在使用上，Arch 不会出现需要另一套钱包这样的情况。
结语
OP_NET 与 Arch 技术实现上有一点点相似，总体上我们都可以说是把比特币主网当成了「发起端」与「确认层」，「执行层」则是他们自己。但这两个项目的定位却是风格迥异，前者是「协议」，后者是「比特币 1.5 层」。
当然了，比特币主网爆块时间过长的问题可能还是会限制二者发展出的 dApp 的效率，他们自身的执行和确认是足够快的，但是最终在比特币主网上的那个确认还是要看比特币主网的矿工们给不给力。尽管如此，我们都乐见比特币生态的不断探索，只有探索，才有发展。
最后值得注意的就是 Arch 的 Token 可能在明年的第一季度 TGE，因此如果未来推出相关的测试等活动，或是基于 Arch 推出的 dApp，大家有兴趣可以留心并且去交互。OP_NET 则没有什么好撸的，目前还是只能期待它上面跑出什么爆款 Token，但是现在整个生态的热度可能比较难支持 OP_NET 像过去 ARC-20 之类的协议一样跑出来。
