最近 Stas Trock 撰写了一篇文章，内容是关于如何让能够体现现实世界状态的智能合约在 Bitcoin SV 区块链上实施、部署和交易。Stas 与 sCrypt 的创始人刘晓晖合作密切，正在利用 sCrypt 平台开发智能合约。在一篇关于状态型智能合约的 Medium 文章中， 刘晓辉将 OP_PUSH_TX 的概念归功于 nChain。

我们联系了 nChain 的首席技术官 Steve Shadders ，了解他如何参与了这一概念的验证过程。

谁最早提出的 OP_PUSH_TX？

这一概念最早产生于 2016 至 2017 年间，主要来自前 nChain 研究员 Ying Chan。我相信其他人也参与了该项目，但是 Ying 在这个领域的专业知识是最丰富的。

一个名为 Mr. Word 的人几个月前提问：OP_PUSH_TX 的想法是如何产生的？

因为那时我还没有参与进来，我想应该让 Ying 来直接回答这个问题：

“我就想看看当脚本操作码都解锁且不加限制之后，比特币的局限性将如何被突破。”“那时，还只有 BTC。”

在 OP_PUSH_TX 里，私钥将被推送至链上。请解释一下为何此时我们不需要顾虑私钥的安全性了？

私钥这里只是被用于在推送交易时生成签名。需要该签名来验证 OP_CHECKSIG 有效运行，并确认你计算出的内容与你当前正在进行的交易相匹配。

由于私钥实际上并没有在保护任何资产，因此只要你不再次使用它，它就不存在安全性问题。通过推送私钥，你可以重新计算 ECDSA 签名算法的许多元素，因此计算变得非常简单。

你需要使用另一个不同的私钥来保护交易本身，这个私钥当然是不公开的。

请谈谈为何当脚本语言被完全解锁后，密钥不再是支付比特币时所必需的了？

从技术上讲，脚本不需要签名检查，但通常签名检查被用作为一种机制，来限制向持有密文的人转移比特币的能力。

挖矿谜题也能做到这一点，但它需要你解出脚本谜题后公开密文。而 ECDSA 签名却能够允许在不泄露私钥的情况下对私钥进行验证。

所使用的任何技术都是 nChain 的知识产权吗？如果是，主要有哪些专利？

据我所知，至少有 9 项专利是针对该技术并涉及其相关扩展范畴的。之前由于 BTC 上人为施加的限制，我们不得不等待比特币协议被恢复后才能够在真实环境下展示它们。

目前，我们正在基于创世纪升级后的比特币规则下对这些技术进行审查，并开始重新测试。

OP_CODESEPARATOR 或其它脚本操作码会影响这项技术的功能吗？

我认为 OP_CODESEPERATOR 可以创造出混合功能，但在此处我们并不需要它。

Steve，你之前和我提起过，在 Bitcoin SV 诞生之前，你曾在 2018 年初向 Bitcoin Cash 的主要开发人员介绍过该技术。能详细说下那时的情况吗？

2018 年 3 月，BCH 社区就一个新的操作码 OP_GROUP 进行了激烈讨论。从本质上讲，这个操作码可以让你“用颜色标记 UTXO”，并附加了一个非常有限的转发条件，即该 UTXO 及其所有后代都必须都是相同的颜色。

这被吹捧为一种能够在 BCH 上“无需许可就可以操作资产”的方法。该提案极具争议，以至于讨论甚至可能引发算力战和分裂。

nChain 既不想分裂 BCH，也不想要引入新的 OP_GROUP 操作码，于是我们向他们说明了 OP_PUSH_TX 可以解决相同的问题，同时还可以实现更多操作功能。我们根本不需要引入任何新的操作码，我们只需要将脚本语言恢复到最初的形态，这本应该就在 BCH 的发展路线图里。

我们提出的方案既能满足 Bitcoin ABC 希望引入此操作码的愿望，还能满足 Bitcoin Unlimited 所追求的功能。不幸的是，该提案遭到质疑，他们认为该提案行不通，并且脚本太大。

现在，sCrypt 团队所做的工作已经证明了方案是可行的，而脚本太大的问题也迟早会被解决，我正在研究其他技术。

在你看来，为何这次脚本演示能够鼓励技术应用？

一直以来，人们总是认为比特币缺少以太坊所拥有的一个基本功能，那就是将脚本的条件推进到下一个事务的能力。举例来说，你可以设定花费一个比特币的条件，但是你不能这样设定这个条件——下一个事务中必须包含一个特定的条件，你才能花费这个比特币。

OP_PUSH_TX 这项技术打破了这个神话，展示出了比特币上可以实现这种功能。通过访问脚本中的事务，您可以针对这个事务检查部分脚本或者检查其它特性，如果状态不满足，你可以强制不履行脚本。

来源：比特币协会 BA