问答 - FAQs

FAQs #


这个方案要修改比特币脚本吗? #

不需要。在两种方案中,我们希望能促使比特币节点软件升级的第二个方案,仅对 PreImage 的格式(也就是软件实现)做了扩充,脚本系统并无改变。


“(类似的方案) 之前已经讨论过,改底层协议就能做到纯一层方案” #

这正是此提案的精髓之处,之前对基础协议的修改被认为是必须的,但实际上只需要在特定的地方处理下,即可保证修改被局限在比特币节点软件实现层面。至于在 2016 年才经由 Johnson Lau 和 Pieter Wuille 编写的 BIP 143 而引入比特币节点软件实现的 PreImage 结构,是否算是基础协议的一部分,这就见仁见智了。我们的观点是,这不是基础比特币协议,而只是实现的一部分。


"(你们提出的) oracle 方案应该和 btp 差不多,现在不考虑改协议的都是 oracle 这个方向” #

Oracle 是很不精确的表达。这提醒我,我们也许需要换个名字。我们的 Oracle 可以不存储链外数据,无需检索交易历史和 utxo 集。

它仅仅执行固定的单一动作,对一组固定的公开信息进行签名。该 Oracle 甚至无需监听 mempool,只需要调用方提供 UTXO 所在的 Tx 原始内容,和花费此 UTXO 的 Tx 原始内容,即可对正确性进行验证。这些数据是公开、通用、固定、且有限的。

链下功能集的尺寸,直接影响了合约的强弱,同时也会影响后续的工程难度。基于越复杂的 Oracle 在后期越僵化,扩展性越差。


这个签名器只是执行固定的动作,是否可以把它的执行动作放在合约函数里,解锁时把UTXO的rawtx内容作为参数传进去?签名器是为了减小合约Tx大小吗? #

在路上:
@顾露 请教下:这个签名器只是执行固定的动作,是否可以把它的执行动作放在合约函数里,解锁时把UTXO的rawtx内容作为参数传进去?
签名器是为了减小合约Tx大小吗?

陈耀欢:
签名器是为了溯源和感应同类型合约,合约函数里面肯定会有相应的执行动作。解锁时传入外部的签名,需要通过合约内的执行动作进行签名校验。

在路上:
明白,我的疑问是把签名器里的执行代码直接放入合约锁定脚本里,省掉签名器,是否可以?

陈耀欢:
那你需要把所有前序的rawtx全部传进去校验合法性了

蒋杰:
暂时做不到只传递锁定脚本到合约内,因为无法验证锁定脚本属于某个utxo。签名器就是为了提供这种证明

蒋杰:
除非将整个utxo所在的tx全部放入合约解锁,但这样会导致合约膨胀

在路上:
明白了,谢谢解答