几乎每一位对技术感兴趣的投资者，在与我们见面的前十分钟里，都会问出同一个问题的某种变体。

“你们用自己的预言机？为什么不直接接入 Chainlink？”

这是个合理的问题。Chainlink 是目前遥遥领先的去中心化预言机网络，声誉卓著，安全记录扎实，开发者生态也十分广泛。另辟蹊径，我们是要付出代价的。那我们为什么还要这样做？

简短的回答：酒店旅游业有一些需求，通用型预言机网络在设计之初就没有把它们服务好。

给不熟悉这一领域的朋友，先做个简单入门

智能合约是在区块链上运行的代码。它可以持有资产、执行规则，并根据条件释放款项。但它天生做不到的一件事，是了解外部世界的任何信息。它读不到酒店的可订日历，看不到当前的汇率，也无法核实住客是否真的办理了入住。

预言机是区块链与现实之间的桥梁。它把外部数据（价格、事件、验证、身份）输送给智能合约，让合约据此行动。如果预言机说谎或出了故障，合约就会依据错误的信息行事。这正是预言机设计成为区块链工程中风险最高的难题之一的原因。

我们需要预言机做什么

Tratok 的智能合约每天要处理大量决策：退款、预订确认、动态定价、争议解决。每一项都需要可信的外部数据：

坦诚谈谈取舍

通用型预言机网络是为通用数据而设计的。它们追求广度（每种资产、每条链的价格数据），并且做得相当出色。但这种广度也意味着，它们必然比我们所需的具体领域逻辑高出一到两个抽象层。

对我们而言，这道差距变成了三个实实在在的问题：

延迟。预订决策在几秒之内发生。住客在页面上点击，就期待收到确认。让数据在通用型预言机网络里来回一趟，会增加延迟，而对最核心的操作，我们承受不起。我们需要可订状态和价格查询做到亚秒级响应。

规模化后的成本。每一次预言机调用都有成本。对于一个以每月数百万笔交易为目标的平台，向第三方网络按查询次数付费，会让我们的经济模型彻底倒转。我们回馈给服务提供方和消费者的节省，取决于把每笔交易的单位成本保持在接近零的水平。

领域定制。“住宿入住确认”不是标准的预言机基本功能，“部分退款的争议仲裁”也不是。在通用的数据网络之上构建这些功能是可行的，但最后您会围绕预言机写下大量定制逻辑，等于实际上自己做了半个预言机。我们决定干脆整套自己写。

我们改为构建的：GHOST

GHOST 是我们自有的预言机协议，专为酒店旅游数据量身打造。这个名字并不代表什么高深的含义，它简短，我们的后端团队喜欢。

GHOST 带给我们的几样东西，是通用型预言机做不到的：

• 亚秒级核心路径。可订状态和价格查询以毫秒计返回，因为它们是系统原生的，而不是靠桥接。
• 理解领域的数据结构。协议能读懂“预订”“价格方案”“取消政策”“入住事件”，而不只是通用的数值数据。
• 成本随规模下降。交易量大时，单次预言机的边际成本趋近于零，这是服务提供方能够持续节省 28% 至 36% 的唯一办法。
• 多源聚合。GHOST 聚合来自我们覆盖数千处住宿的网络的库存与价格。聚合逻辑专门针对酒店旅游场景调校。
• 独立审计。整个系统已通过独立的安全审计，这是我们更广泛的智能合约审查流程的一部分。

我们放弃了什么

这一点我想坦率地说。走自有路线并不是免费的。我们接受了三项实实在在的代价：

我们无法开箱即用地获得大型去中心化验证者集合带来的网络效应安全性。我们用审计、协议上的多重签名治理，以及持续更新的漏洞赏金计划来弥补，但这是另一种信任模型。我们公开承认这一点。

工程负担由我们自己承担。每一次协议升级，每一个安全补丁，每一种新的数据类型，都由我们的团队负责。而用 Chainlink 的话，大量这样的重担是由整个生态系统共同分担的。

我们无法免费获得与更广泛的去中心化金融生态的互操作性。如果我们想与一个需要 Chainlink 数据的去中心化金融协议对接，就必须自己搭桥。其中一部分我们已经完成，今后还会做更多。

一句话说清这场押注

对一个核心价值主张取决于近乎为零的边际交易成本和毫秒级预订决策的平台来说，掌握数据层是正确的取舍，即使随之而来的是工程负担。

这场押注未必适合每一个区块链项目。对于去中心化金融协议或合成资产平台，答案几乎总是 Chainlink。但酒店旅游业的数据需求如此特殊，在保持单位成本低廉上的经济压力也如此特殊，所以账要重新算。

如果您也在权衡类似的决定，我们很乐意交流心得。加密生态对这一取舍谈得还不够多。

Carol

社区经理，Tratok