在前两期《预言机》中，我们推广了甲骨文的基本概念和操作模式，并介绍了在Neo3环境下甲骨文与智能合同的互通规则，以确保特定数据能够传输到网上世界。

在第三堂课中，我们将介绍如何在近地天体虚拟机中执行甲骨文请求，并就结果以及近地天体3目前正在考虑的协议、过滤器和响应机制达成共识。 执行甲骨文请求 常规Neo节点将有助于处理甲骨文交易。收到事务请求后，他们只能根据已知的哈希列表审核事务哈希，并在他们的内存池中更新它。但是，当Oracle节点收到Oracle事务请求时，它可以将事务哈希添加到已知哈希列表中，并在上执行请求。

当需要甲骨文服务时，甲骨文系统将输入网址并过滤以发出指令。在新虚拟机中，Oracle节点将执行Oracle系统调用，首先检查是否有缓存的结果。如果没有结果，Oracle节点将通过给定的URL下载内容，启动过滤器，最后缓存数据结果。

此时，Oracle节点已经通过Oracle协议机制完成了对缓存结果的一致确认。基于Oracle节点的共识，用户可以信任这个结果。 甲骨文共识 共识是甲骨文网络中非常重要的一部分。通过让多个节点执行相同的审核并比较每个节点收到的响应，最终结果的一致性得到了确认，并且所请求数据的可靠性得到了保证。这旨在防止数据篡改，并创建一个开放和透明的信息环境，以便开发人员可以安全地为智能合同引入离线数据。 关于Oracle节点的一致机制，采用批准阈值是一种相对简单的方法。共识机制只有在对反馈数据的共识达到一定数量/百分比时才会生效。当然，也可以添加其他共识规则。 正如Neo核心开发者Belane提供的例子: 1.将Oracle反馈数据放入经过验证的内存池至少需要10个签名。只有当50%的Oracle节点批准并且不超过10%的节点反对时，才能达成共识。 2.将Oracle反馈数据放入经过验证的内存池至少需要5个签名。达成协议的Oracle节点数量必须是反对协议的节点数量的两倍，并且反对签名的数量不得超过10个才能达成协议。 在目前的协商一致提案中，有人建议在提案阶段纳入批准门槛。 例如，采用第一个共识规则。未经验证的甲骨文事务被发送到网络，通过天气监测应用编程接口请求上海的当前温度。 如果9个Oracle节点调用API并批准20度的温度数据，1个节点返回19度的温度数据，则20度是基于共识的最终结果。9个节点中的每一个都将签署一个“20”。在有足够数量的签名可用之后，反馈数据可以被移动到已验证的池中并存储在块中。 由于可以采用多种规则，协商一致进程的最终设计仍在讨论之中。例如，批准阈值可以是在Oracle策略中定义的固定值，或者每个智能合同都可以指定自己的批准阈值。或者，可以探索其他共识进程。 关于Oracle节点的一致机制，采用批准阈值是一种相对简单的方法。共识机制只有在对反馈数据的共识达到一定数量/百分比时才会生效。当然，也可以添加其他共识规则。 支持的协议、过滤器和响应 根据开发人员的要求，Oracle请求可以采取不同的形式。需要访问不同的资源，并且需要标准化的响应和过滤器，以便在Oracle节点达成共识之前优化结果。 甲骨文服务需要支持的主要协议是HTTP(及其安全对等体HTTPS)，这是一种基于互联网的数据交换标准。最初的实现将基于支持HTTP和HTTPS，但是支持方法仍在讨论中。 Neo的联合创始人和核心开发人员张正文认为，由于GET的简单性及其对甲骨文请求的适用性，应该只支持GET，但是由于GET在REST应用编程接口中的广泛使用，也建议使用POST。 此外，甲骨文服务可以处理近地天体分布式存储网络的请求，从而使智能合同开发商能够访问离线数据。也有关于esta的讨论 核心开发人员Shargon提出的过滤概念是Oracle系统调用的扩展，用于过滤掉不必要的数据响应。我们还在“预言机”的第二堂课中提到，过滤器的使用可以减轻链上的存储空间，并提高一致性的确定性。 使用过滤器的一个问题是，对于同一个过滤器，每种语言需要不同的实现，这可能导致不同软件的节点在过滤后的响应不同。 伊戈尔·科埃略提出了一个解决方案，建议将甲骨文过滤器作为智能合同来实施。这将允许开发人员为调用创建自定义过滤器或重置它们以在Oracle系统之外使用。 对于最初的Oracle实现，JSONPath标准用于过滤不必要的响应。对于响应本身，请求API需要提供响应反馈的数据格式。经过对Github的深入讨论后，Neo核心开发人员建议用户应该提前对他们期望的格式或内容类型进行标准化。 与过滤器实现相匹配，最初支持JSON响应，但未来将陆续支持其他格式(例如，XML或HTML)，以满足智能合同开发人员的潜在需求。 在“预言机”的第四堂课中，我们将介绍甲骨文在Neo3环境下的其他机制、——去集中化和经济模型。