聊聊比特币BSV上的智能合约（二）-预言机（Oracle）
作者：互联网
之前的文章我们聊到纯一层合约和二层合约各有各的问题，二层合约的主要问题是达成共识比较困难，而一层合约的问题是无法拓展以及交易膨胀。没有看过的同学先回顾前一篇内容
在聊到一层合约的时候，我们总结出一层合约的主要矛盾点在于无法鉴别伪币，以及无法感应到同一个交易中的其他合约。本质上是因为比特币脚本无法读取到脚本代码以外的数据。一个token utxo是不是真币这个信息，其实包含了很大的信息量（需要溯源到第一笔交易才可以确定这个信息），如果把所有这些全量信息都包含到比特币脚本中，那么这个脚本会越来越大，最后膨胀到无法使用。如果不把这个信息包含在脚本中（二层合约），仅依靠一层矿工就无法判断一个utxo是不是真币。这是一个无解的问题，包括以太坊也是如此，如果你想依靠自己（不依赖外部API或者服务商）获取一个账户的token余额是否正确，你需要运行一个占大约5TB SSD硬盘的全节点，然后把以太坊所有历史上的智能合约都执行一遍，最终计算出现在这个账户的token余额是不是真的存在那么多。
那么既然判断真币所需要的信息量那么大，而且会越来越大导致utxo膨胀到无法使用，那么有没有办法只保存一部分的信息，或者信息的指纹摘要，在不会引起utxo信息量膨胀的情况下快速校验一个utxo是否是真币呢？
其实类似的方法已经被广泛应用到区块链中了。了解比特币协议的同学应该知道一种快速校验比特币真伪的方法，叫做SPV（simple payment verification）。钱包怎么可以判断一个收到的utxo是否为真的比特币交易呢？常规的做法是运行全节点，然后重建出所有的utxo，再来确定我们的utxo是否为真币。而比特币提供了一种快速安全的判断方法，可以让我们在不需要全量区块链数据的情况下，只拥有区块链的一个摘要信息（区块头），加上merkle路径，就可以以极低的成本判断utxo是否合法，SPV和Merkle树设计是比特币为了支持无限扩容而精心设计出来的，这个内容以后会提到。
在SPV的场景下，因为我们只有区块头，本质上拥有的只是全量区块链数据的一个摘要，或者说由全量区块链数据所提炼出来的一个简化版数据，我们无法仅凭摘要数据还原出全量数据，也无法自己重建出区块链的完全状态，更无法判断这个摘要本身的真伪。因此SPV钱包必须“完全信任”给自己提供区块头和merkle路径的服务器（或者全节点）。也就是说，当我们选择丢失掉部分信息以换取便利性的同时，我们就必须使用“信任”，来弥补这部分丢失的信息。
我们把这种可信的，拥有我们不具备的外部数据，提供摘要信息以及其证明的服务器称为预言机，英文是Oracle。预言机原意是指可以为合约提供合约本身所不具备的一些外部信息的可信数据源。我们这里把它的含义提炼和引申一下，总结具有以下几个特点：
- Oracle拥有一些我们合约或者SPV钱包所不拥有或者无法依靠自身获取到的信息（比如链外信息或者全量数据）
- Oracle是可信的，我们用信任Oracle来弥补丢失掉的部分校验信息
- Oracle提供的信息可以在外部判断真伪，如果Oracle提供假信息，会立刻被发现（比如和其他Oracle进行比对）
- Oracle只是提供真实事件的消息源，没有任何秘密，是开放准入的，任何知道真实事件的人或者实体都可以担当Oracle
通过这三个特点，我们知道因为必须信任oracle，所以无法防止oracle作恶，但是因为oracle只是提供一下真实发生的事情的信息，因此校验Oracle所提供的信息的真实性非常容易，比如Oracle提供给du球合约某场比赛的结果，再比如SPV server提供给钱包区块头，这些事件我们可以通过其他的消息源来获知，所以一旦oracle作恶，会立刻被发现，并且由于oracle需要提供自己的签名，作恶的证据无可抵赖。
Oracle这种用信任换便利的方式无处不在，以太坊里有大量的合约需要oracle从外部输入数据，大多数开发者查询合约状态都需要依赖和信任像Etherscan，Infura这样的数据服务商，很难有人可以自己通过区块链来确认合约的状态了。
通过SPV的启发，我们可以这样解决伪币问题和感应问题：
将摘要信息传入合约里进行校验，摘要信息包括这个utxo的来源交易id，以及来源的来源（先前校验2层），并且这个校验并不是拿完整的数据进行校验，而是校验oracle对摘要的一个签名，就可以将token的真实性传递下去。换句话说只要拿到oracle的签名，oracle说某个utxo合法，合约就可以用oracle的签名来解锁utxo。
通过Oracle还可以识别同一个交易中的其他合约是否为真实utxo，这就让同一个交易中，多种类型的token可以协作（这是做token swap的基础）。
实际的操作如下：钱包要花费某个token，需要向一个或者多个Oracle请求签名，询问Oracle这个utxo是不是真币，同时要求Oracle提供真币的SPV证明，如果这些Oracle都签名证明此utxo为真币，那么钱包就可以判断这个utxo为真币，用oracle提供的签名来解锁合约并发送交易。矿工打包交易的时候也会参与其中，校验oracle所提供的签名是否正确。
在Oracle不做恶的情况下，假币因为没有Oracle的签名，因此彻底无法被花费（由一层矿工进行保证），这是与二层合约本质上的不同，假钞utxo被彻底锁死，花不出去。钱包如果想造假币，哪怕造出来假utxo也因为没有Oracle的签名而花费不出去。
而如果Oracle作恶，根据钱包的处理的不同有这样两种情况。
一种是钱包不作恶。钱包请求多个Oracle获取签名，如果其中有个别Oracle提供的消息与其他Oracle不同（比如把真币标记成假的或者把假币标记成真的），钱包会立刻发现这种情况，中断交易构造，使得交易无法构造出来，也无法广播出去。在产生可能的损害之前进行规避。并且会通过其他消息源查到真实信息是什么，快速揪出作恶的Oracle，并将作恶Oracle的签名消息作为证据保留下来（也可以对外公开该Oracle的恶行，提醒其他钱包进行预警），以后不再信任此Oracle提供的任何信息。
另一种情况是钱包配合Oracle作恶。钱包收到Oracle签名的假消息，既不自己校验真实性，也不通过其他Oracle来比对，而是直接配合假Oracle来构造交易，以假乱真。这种情况非常严重，会将假币引入到整个utxo集中，也会破坏整个合约的状态。并且理论上，只要Oracle有意作恶，是有能力毁掉整个合约，造成极大的损失。同样，根据刚才描述，Oracle作恶会立刻被发现，同时证据会保留下来，但是整个由此Oracle来签名的合约和token会被毁掉。token发行方唯一可以做的，就是更换Oracle重新发行Token，空投到旧Token的所有地址，并1比1映射旧token到新的token上来挽回损失，同时保留Oracle作恶的证据，对所造成的经济损失诉诸法律。
由此可知，因为不是纯一层合约，Oracle对于一个合约的正常运行起着至关重要的作用，一旦Oracle被攻陷，或者Oracle主动作恶（只可能被盗或者主动作恶，不太可能因为bug导致作恶，因为想作恶的条件还是很苛刻的），是可以完全破坏一个合约的运行的，虽然重建一摸一样的合约并不难，但是一定会带来经济损失。所以发币方在挑选Oracle的时候，一定要慎重，既不能完全封闭准入门槛，也不能无条件开放。
Oracle运营商是一门生意，可以托管合约来赚钱，但是需要做信誉担保，一般会由信誉比较好的大交易所，大矿工或者服务商来提供专业Oracle服务。可以通过一些技术和经济的手段来避免或者减轻Oracle作恶的风险。
- Oracle作恶必定会被抓，从发出作恶交易的那一刻就会立刻被发现，而且证据确凿无法抵赖，其实很多罪犯就是抱着侥幸心理才实施犯罪的，如果犯罪100%会被抓，那么犯罪率会下降很多
- Oracle作恶会损失信用，损失潜在的生意，没有人会再将合约托管给这样的Oracle，被这样的Oracle托管的合约token，也没人会用
- Oracle作恶可能面临法律风险，需要赔偿经济损失。
- 可以用一些技术手段，比如说让Oracle锁定一部分钱作为押金，可以利用Oracle的作恶交易来解锁押金补偿给损失者（具体实现还没有想好），不作恶，押金就取不出来，而作恶的同时也就损失了押金。
介绍到这里，我们对Oracle方案的智能合约有了比较深入的了解，这里简单总结一下Oracle方案的优缺点，以及我个人为什么认为一层Oracle方案是目前最接近商用的方案：
优点：
- Oracle方案由矿工执行合约代码，相比于二层合约达成共识容易很多，也更易于推广，没有开发者中心化的问题
- Oracle方案通过校验信息摘要而不是校验信息全文，可以避免纯一层合约的交易膨胀问题
- Oracle方案天然与SPV设计相契合，区块头就是一种另类的Oracle，通过SPV化，校验真伪的成本和发现作恶的成本都非常低
- 可以部署多个Oracle来进行交叉校验，也可以设计多签或者门限签名，来降低单个Oracle作恶造成的风险
- 是基于utxo的分布式token，性能高，无限扩容
缺点：
- Oracle的作用以及可能的破坏力非常大
- 如果Oracle作恶，需要重建token合约，并且按原地址余额进行空投。
商用化方面，这里就要聊聊比特币合约和以太坊合约的本质不同了。以太坊合约一定会执行，但是执行结果不一定成功（因为可能执行一半gas没有了导致失败，白花手续费）。以太坊非Oracle的合约（以太坊上还存在大量依靠Oracle的合约）作恶的可能性非常低，几乎不可能，但是代价就是整个系统也就不可能扩容，不可能支持大规模使用。而比特币Oracle合约提高了部分作恶的可能性，换取了极大的性能提升。比特币合约允许出现差错或者作恶行为，但是可以保证这种差错会立刻被发现，证据也永久保存，而且有对应的方法可以纠正过来，少了一点100%的约束，降低的这一点安全性，带来了数量级上的性能提升。做系统的工程师可能了解，100%可靠的系统是不存在的，99%可靠性的系统和99.99999999%可靠性的系统对于用户体验上的差别并不大，但是这两者在成本和性能上可是天差地别。我们是需要一个99%可靠的，无限扩容快速便宜的系统，还是需要一个99.99999999%可靠的又贵又慢而且充满了性能瓶颈的龟速系统呢，这个仁者见仁智者见智了。
合约安全性排序：以太坊合约 = 纯一层合约 > 一层+Oracle合约 > 纯二层合约
性能和可拓展性排序：一层+Oracle合约 > 纯二层合约 > 纯一层合约 > 以太坊合约
合约灵活性排序：纯二层合约 > 一层+Oracle合约 > 以太坊合约 > 纯一层合约
合约交易成本排序：一层+Oracle合约 ~= 纯二层合约 < 纯一层合约 < 以太坊合约
综合各个维度来看，我认为最重要的是性能和成本，这两个指标下，Oracle方案胜出，其他指标的短板也并不明显。这就是为什么我最看好一层Oracle方案。
Oracle合约的发行方对于如何选择Oracle需要慎重考虑，也需要同时平衡开放性和安全性这两个要素。下一篇文章我会具体介绍一下发行方如何选择Oracle，如何添加新的oracle和撤回已有oracle的授权，给出一个具体可行的Oracle管理方案。
总结和分享这些文章需要耗费作者大量精力和时间，如果你觉得对你有帮助或者有启发，欢迎打赏BSV到下面的地址，支持作者继续创作。
1oaLed3qi3HXQvbQhiiXSBYP19kQ3uHRf
标签：作恶,utxo,比特,BSV,校验,token,Oracle,合约 来源： https://blog.csdn.net/weixin_43953732/article/details/114925962