最近，大家的注意力似乎都聚焦在 L2 上。
Coinbase 上线了 Base 的测试网络、Arbitrum 开启了空投，zkSync Era 宣布主网启动，Polygon上线 zkEVM.... 在我们乐于讨论不同的估值、技术架构和应用生态时，不要忘记它们也拥有着相同的刚需：
预言机。
所有的区块链网络，都需要从各类数据源获取加密资产甚至是真实世界资产的价格，来为链上应用提供重要的参考和输入。
按照这个思路细心观察，你会发现无论上述哪个 L2 刚刚官宣启动，几乎同时就会看到预言机项目 Pyth Network 已经开始为其提供喂价服务的消息出现。
不仅是 L2，当一条链的主网或测试网上线，集成预言机来进行报价往往需要技术对接的时间。当“先宣发，后干事”成为常态时，Pyth 这种快速的无缝集成是如何实现的？
一直以来，预言机并不直接被终端用户感知，但随着 L2 们的密集崛起，预言机似乎有了更多的表现机会，其中的原因在于：
高性能和低费用必然催生更多的生态应用，同时让更多金融乐高的创新应用成为可能。比如高频交易的去中心化合约产品、基于真实世界资产的衍生品合约等。这也自然会对金融/加密资产价格的准确性、质量、更新速度等有着更多的诉求。
那么，对应用们来说，使用 Pyth 会是一个好选择吗？
对用户们来说，Pyth Network 也仍未发布 token，与各公链合作预期拉满的情况下，是否也值得埋伏，又有哪些可以参与的方式？
最近 Pyth Network 也更新了 V2 版本和众多新功能，而距离其上一次版本发布，已过去了 5 个多月。这其中的进展和变化如何，除了官方的一些介绍，我们很难再找到更多深入的解读。
因此，考虑到 L2 的爆发背景，以及 Pyth 本身的代币预期，我们也再一次启动了对该预言机项目的研究。
无论你是相关赛道的投研者、又或是正在考虑集成预言机的开发者，这篇文章都会对你有所帮助。
在进入具体的机制研究前，不妨先看一眼 Pyth Network 目前的数据表现。
首先，考虑预言机整体的赛道格局，TVS（Total Value Secured)是一个较为重要的指标。与常见的 TVL 略有不同，TVS 多用来总结预言机网络的总体经济影响和采用情况，意味着“总保护价值”：
例如 Pyth 在 A 协议中的 TVS 为 100 美金，意味着 A 协议由 Pyth 喂价而产生的各类交易总价值为 100 美金。同时，预言机的喂价实际上在防止可能导致用户资金损失的数据操纵和业务损坏情况。
根据 DefiLlama 的数据，除开 2 个为单一协议提供预言机服务的项目，Pyth 的 TVS 排在预言机龙头 Chainlink 之后的第二位；同时其预言机服务覆盖的项目数，同样也排在第二位（54个）。
而考虑自身的增长情况可以发现，自去年 12 月之后， Pyth 的 TVS 数据呈现出了较为明显的增势。这种增长趋势，也与其 V2 版本在去年年底上线的时间点吻合。
需要解释的是，Pyth 于 2 年前发布 V1 版本时，最初仅支持 Solana 链上的生态项目；V2 版本则采取了多链策略，为 EVM 和非 EVM 公链们同时提供预言机服务，而目前跨链服务的各类项目，其 TVS 已经超过了 Solana 的总 TVL。
下图则更加直观地展现了 Pyth 预言机在多条链上的使用情况。以 4 月 1 日为例，Pyth 为各个链上提供的价格更新事件，总量达到了 60w+，这也就意味着多个链上的各类 Defi 协议在需要价格更新时，都会通过以 Pyth 的喂价为数据源来执行业务（如用户使用某个 defi 协议以实时价格交易 BTC）。
那么，究竟有哪些协议目前在使用 Pyth 的服务？我们发现 Synthetix 占据了 TVS中 40% 以上的份额，可谓其第一大客户；此外例如 Mango Finance 、Drift、CAP、ZETA、Perpy、Cypher 等不同公链和 L2 上的知名 Defi 协议，也都使用了 Pyth 的预言机服务。
这些协议看中了 Pyth 的哪些亮点？或者换个角度来说，如果我们要研究一个预言机项目，应该重点关注哪些方面？
分析预言机的基本逻辑
想要回答上一节的问题，首先需要理解的是：为何 Web2 不需要预言机，但 Web3 一定需要？
不少读者经常有这样一种困惑，Binance、Coinmarket Cap 或者其他地方都有加密资产的数据，为什么 DeFi 协议和其他应用不直接拿来使用，而是需要一个预言机起作用？
答案的关键，在于链上环境的封闭性。
链上应用依照智能合约的设计执行业务并带来结果，但执行的触发条件却是从外部接收的——必须把一个外界条件带入合约中。
某些网站上的加密资产价格，本质还是独立于区块链世界的外部数据，虽然是现成的，但并不意味着能用：我们仍需要一个助攻者的角色来把价格数据传递给链上协议，而这才是预言机必然存在的理由。
那么，在区块链的世界中，假设你从某个 Defi 中按照时价购买了加密资产，大致会经历了以下过程：
- 数据源将资产价格提供给预言机；
- 预言机将价格传递给 DeFi 等应用；
- 用户以 DeFi 应用中展示的价格购买资产；
于是，预言机在其中起到了“报价员”的作用：从上游数据源获取价格，传递给下游应用，支持应用的使用场景。在串联上下游的过程中，我们可以很自然地针对上述 3 个关键环节提出问题：
-
数据源的质量如何？——既然要获取价格，那数据源本身是否正确可信，如何处理这些数据？
-
数据如何传递？——包括传递效率和成本如何，应用是否能够方便地使用和集成；
-
支持哪些使用场景？——例如是否能够按需定制，满足不同 DeFi 应用的个性化需求。
以上这些方面，是衡量一个预言机基本面是否良好的重要参考，同时也是我们分析 Pyth Network 新变化的关键思路。
数据源新变化：聚合更多价格的置信区间，专属的应用链
Pyth Network 之所以能在预言机赛道中占有一席之地，重要的原因在于其强大的数据提供者资源。
早在前年项目发布之初，Pyth 就公布了 40 余家金融市场和加密行业的顶级价格数据提供者，知名的如纽交所最大的做市公司之一 GTS，以及芝加哥商交所结算单位 Jump Trading；而在加密领域则包含了 Binance、OKX 和 Coinbase 等知名 CEX，以做市商如 DWF Labs 的数据 。
时间来到今年 4 月，公开信息显示数据提供者的总数已经达到了 80 余家。在加密市场，这些数据源除了提供 BTC、ETH 等主流加密资产外，也增加了大量的长尾资产；同时在传统金融市场，大宗商品、贵金属和外汇等现实资产的价格也逐渐被 Pyth 独家收录其中。
图：Pyth Network 官网所提供的多类金融资产数据报价
但当数据源变得越来越多时，实际上我们首先更应该持怀疑态度的是：到底以谁提供的价格为准，又怎么保证诸多数据源所提供价格的正确性？
这个问题关乎所有 DeFi 应用的正常运行，也是整个加密世界秩序稳定的基础。
而面对更多数据源所提供的价格，Pyth Network 设计了的置信区间机制，为价格的正确性和稳定性提供了准绳。
图：置信区间的设计保证价格的正确性
据深潮从 Pyth 产品团队获悉，其给出的每一个相同的报价，背后都至少需要 5 个以上的数据源提供数据。
例如关于同一资产 a 的价格，有 4 个数据源的实时报价都在 100-120 美元，而另 1 个数据源的报价仅为 80 美元左右。正常情况下 Pyth 会将 a 资产的价格置信区间设置在 100-120 美元左右，即认为 a 资产的价格在该区间内具备更高的可信度，保证了发布出去的数据并不会受到极端数据源的影响（图a)；
而当不同的数据源给出的价格并不极端，但准确度上略有不同时，Pyth 会适当加权不同准确度的数据来源，综合地给出一个置信区间（图b)。例如对于资产b的价格，两个数据源给出的报价在 100-101 美元，另外两个数据源则为 100-120 美元，那么 Pyth 的置信区间会对两种价格范围做出加权综合，可能最终的综合价格在 100-110 美元左右。
通过以上例子可以看出，Pyth Network 吸纳了多个数据源的价格，在反映数据源之间差异的同时，通过数理的方式，让价格得以被正确地聚合。
理解了这种设计方式后，你很容易会产生另一个疑问：怎么保证价格聚合确实被执行了，有什么证据吗？Pyth Network 给出的答案出乎意料，但又在情理之中—— 自己做一条区块链。
意料之外，是在 Pyth之前的 V1 版本中，我们能够直观地感受到它与 Solana 高度绑定的关系。预言机的运行依赖于 Solana 网络，价格的上链、验证和发送执行等都需要在 Solana 上完成；
情理之中则是由于虽然价格聚合的执行可以在 Solana 上得到验证，但一旦 Solana 宕机，或者由于链上某些其他应用对网络资源的挤占（例如某个 NFT 上线后疯狂 mint)，就会导致 Pyth 的预言机服务“躺枪”——报价产生延迟，或者无法正常提供服务等。
图：Pythnet 设计和相关角色简述
而在目前公布的 V2 版本中，Pyth 有了一条“专事专办”的独立应用链 ：Pythnet。Pythnet 是 Solana 链的一个分叉，既能够利用 Solana 的高性能，又与 Solana 宕机、网络拥挤等因素无关。
这条链的基本运行逻辑在于，将数据提供者发送的价格数据进行聚合，形成一个综合价格并记录在自己的链上；同时，价格聚合的计算过程等也放在了链上，当价格需要被调用时，可以很容易通过区块链来验证过程和结果，以保证最终价格的正确性。
此外，数据提供者也会通过质押 Pyth 的代币来充当这条链的验证节点， 对数据本身的真实性和数据交易的验证负责。目前我们尚不知道普通用户是否也可以将自己持有的 Pyth 代币存入这些节点以获取收益，但独立应用链的设计也确实给代币的用途提供了更多的想象空间。
更重要的是，Pythnet 的独立运作使得预言机服务不会受到其他公链的影响，当目标链资源占用明显时，Pyth 依然可以对链上的应用进行报价，“专链专办”的设计为其服务的稳定性提供了更为强有力的支撑。
数据传递新变化：支持跨链，从“持续推送”到“按需拉取”
有了大量的数据源并保证准确性后，我们更关心 Pyth 如何将这些价格数据传递给有需求的应用们。
因为从本质上来说，各类预言机的产品功能是趋同的，最终目的都是将价格数据喂给应用；而传递方式的不同，则可能造成预言机在喂价效率和成本上的差异，从而形成某个产品独特的优势。
那么对于 Pyth Network 的 V2 新版本来说，数据传递上有哪些值得称道的地方？
更进一步的，我们可以把问题分解为两个部分—— 数据可以传递给谁，以及怎么传？
在传递给谁的问题上，首先其最明显的进步在于跨链。在 Pyth 最初的设计中，由于基于Solana构建，因此大多数时候其喂价服务都围绕着Solana的生态项目展开；
而预言机与单一区块链的绑定的策略，在急剧变化的加密市场中并不是一个稳定的选择；更多新公链和 L2 的出现，也让许多 DeFi 应用 有了跨链部署的需求，这也对预言机的喂价范围提出了挑战。
图 Pyth 官网列出的支持公链情况
因此，Pyth 自身也在积极拥抱跨链，目前其喂价服务不仅支持 Solana， 还支持了 12 个主流的 L1 和 L2，包括最近火热的 Arbitrum 和 ZkSync Era。
但每个链的技术特性和需求可能都不一样，Pyth 又是如何做到将价格数据快速传递给多个不同链上应用的？
这个问题相当重要，因为它涉及到了预言机喂价模型的设计，也是 Pyth 目前显著区别于其他预言机的优势所在。
传统的预言机喂价，一般都采用了“推送”模式：
-
数据源将数据提供给预言机；
-
预言机持续不断地按照某个时间间隔，向不同的区块链推送价格更新；
-
链上的 DeFi 协议得到价格，按照推送价格执行业务。
这种模式符合我们对预言机工作原理的理解，但深究你会发现成本和扩展性的问题：
预言机需要为每次价格更新支付交易费用，因为数据推送是一种链上交互，必然会产生 Gas 费等。
那么如果希望让预言机的价格推送变得更加密集，则费用一定就会上涨；此外，如果你需要在 3 个公链上都得到 BTC/USDT、ETH/USDT、Doge/USDT 这 3 个标的的价格，则需要在单位时间内支付 9 次费用（1 个公链上的 1 次标的价格推送单独计算）。
一旦 DeFi 协议需要跨链运作，或者支持更多的交易对，使用预言机的成本会指数级上升。同时，受制于每个链的性能问题，一旦网络发生拥堵，那么应用得到滞后报价的概率可能也会更高。
而在 Pyth Network 的 V2 版本里，产品将这种被动的“时刻不断推送”，替换成了主动的“有需要时请自取”：
-
数据源将数据提供给预言机；
-
预言机的价格更新不在目标链上持续进行，而是在 Pythnet 中进行；
-
通过区块链机制，确保 2 中的价格更新真实有效；
-
链上 DeFi 协议需要喂价时，从目标链上拉取价格；
-
得到价格，按照推送价格执行业务。
这种按需拉取也就意味着，使用一次喂价服务才会产生一次费用，不必再持续不断地向目标链上推送价格。而在 Pyth 的实际运作流程中，如果更加细化的研究上述拉取模式的原理，你很容易发现扩展性上的提升：
-
经由 Pythnet 聚合和验证过的价格数据，具备通过虫洞（一种跨链产品）跨到不同链上的能力；
-
同一类价格数据，同一个虫洞跨链，虽然目标链可能不同，但它们都只需要部署一个接收价格服务的智能合约；
-
每当下游应用要调取数据时，向虫洞发出请求；虫洞验证无误后从 Pythnet 上拉取数据给到下游。
图：按需求更新的“拉取”式喂价服务流程
那么，不同链使用 Pyth 所提供的喂价服务，条件相同——仅需设计对应的价格接收合约，开发部署成本极低。而且这些合约实际上只需要包含一个面向不同区块链（特别是 EVM），但内容大同小异的价格数据存储和跨链信息传递模型，因此非常容易部署（据 Pyth 团队成员透露，一般只需要不到 2 周时间）；而喂价的核心合约（包含性能提升、数据集成的深度运算等）都只需要保持在 Pythnet 上运维。
当随取随用成为现实，对于下游的 DeFi 协议来说无疑具有极高的吸引力。DeFi 应用们当然更希望将精力和成本投入到自身产品的打磨中，而不是过多地考虑如何与预言机对接。
同时，喂价模式的转变也会可预见地带来商业模式的转变：
在传统的推送模式下，DeFi 协议可能与预言机签署了合作的合同，按照订阅制的方式购买了预言机的服务，在一段时间内能够享受到数据的喂价和推送。这其中必然有链下的商谈环节和时间花费；
而在 Pyth 目前的按需拉取模式下，协议与预言机的合作则显得更加的 Web3 化：你甚至都不需要线下联系 Pyth 的商业团队，仅通过开发文档和智能合约的部署，就可以完成对价格数据的拉取——合约触发、付 gas 费、数据拉取和拉取后的使用全部自动执行，体现出一种“**无许可”和“全链上”**的特质。
应用场景拓展：兼顾广度与深度， 关注 DeFi 的长尾场景
在我们通常的认知里，预言机更多的是在解决价格数据”有无“的问题。衡量预言机好坏时，我们往往会以”广度“作为重要的参考指标。
如果一个预言机能够为多个协议提供喂价服务，我们就会觉得它的业务做得还不错。
但实际上，当预言机赛道的竞争日益激烈时，决定一个预言机能否脱颖而出的亮点，则转移到了”深度“上：
解决数据的有无问题，可能只用来衡量预言机的下限，上限的比拼要看能否适配更多垂直的场景。
今天更多的 DeFi 协议对数据提出了更多的要求，不仅仅是需要价格数据，而是需要”符合我业务场景的数据“。针对这种情况，我们同样看到了 Pyth Network 在场景适配上的探索。
今年 2 月，Pyth 推出了针对 DeFi 流动性风险预测与管理的预言机产品：流动性预言机 V1。
简单来说，某些 DeFi 产品中的加密资产价格可能会显著受到流动性影响。如果某标的流动性较低，那么一笔巨额的买单可能会引起价格的巨额变化，从而导致部分业务（比如高频交易、永续合约等）受到价格变化的冲击而导致不正常的波动。
如果说预言机一般解决价格数据的有无，那么流动性预言机则是在解决风险提示的有无。
Pyth 的流动性预言机实际上在提供关于各类加密资产的流动性指标，为受流动性影响大的 DeFi 产品提供参考。当流动性可能出现突变的迹象时，Pyth 会提前给出预估，告知协议流动性的变化可能会产生多大的影响。
在此我们并不具体解释该预言机的技术原理，更为值得探究的点则在于风险管理：随着更多 DeFi 使用场景的出现，对于未来风险的预测将变得更加重要。
在今年 3 月，Pyth 也上线了另一个产品：Benchmarks 基准数据。
Benchmark 产品更像是面向历史，为链上和链下应用程序提供了调取历史 Pyth 价格数据的功能。
在 Pyth Benchmarks 基准数据产品中，Pyth Network 创建了一个储存 200+资产历史价格的数据库，并公开了用于搜索和检索这些数据的 APIs。
这也就意味着使用 Pyth 的 DeFi项目不光可以接收到实时的数据，也可以通过 API 拉取到过往的历史数据。这对于某些需要依据历史价格数据的使用场景来说十分有用。
例如主打期权交易（DOV）的 Ribbon Finance，一般期权交易往往需要根据历史价格来结算。假设结算时间在早上 8 点，但预言机可能到 8 点 10 分才延迟推送 8 点的价格数据，那么这 10 分钟内的价格波动发生后，如果再进行结算，必然会造成结果的误差。
而使用 Benchmarks 的好处在于，Pyth 以秒级对价格进行更新，并且历史时间中的数据全部存放在 Benchmarks 的数据库中。如果希望以 8 点的数据为准进行结算，协议可以直接在 8 点后的数秒内向 API 发起请求，随后快速获得价格数据来发起结算，不用担心因为时延所造成的价格变化。
此外，我们也了解到 Pyth 目前也正在与 Synthetix 合作，针对因预言机延迟导致的抢跑和 MEV 问题，开发相应的解决方案。
因此总体来看，面向某些对数据有特殊需求的场景，提供符合需求的喂价服务，抓住这些长尾市场在提供服务的深度上做文章，才是 Pyth 未来增长潜力的重要体现。
结语
头部 DeFi 协议的合作、跨链服务的启动、多场景适配等目前都体现出 Pyth Network 生态覆盖范围的扩大，而脱离与 Solana 的绑定自建 Pythnet，也给了项目更多的灵活性。
考虑到 Pyth 目前还并不是预言机赛道的 TOP1，在发展过程中也必然会有相应的手段鼓励更多用户的体验与使用。对于 DeFi协议和更多的数据源而言，可选择与其展开合作，以期获得补贴和激励计划的支持；
而对于更多的最终用户而言，上述产品力的提升、合作范围的扩大以及更多的发展计划，归根结底都会聚焦在 Pyth 的 token 上。
目前公开的信息显示，Pyth 的 token将会更多的用于 gas 费的支付、真实收入的分享以及治理的权益上。
在发币预期和基本面向好的情况下，用户可以选择提早进入其 Discord 社区，在力所能及的条件下开展混身份、做活动等各类常规操作，以期博取可能的空投和权益。
上一个牛市周期中，我们看到了 Link 的高速发展。而在新的周期中，脚踏实地做基建的预言机们往往并不在台前露面，但我们也有理由期待，赋能 DeFi 应用的幕后工作者，也终究会迎来属于自己的高光时刻。
深潮 TechFlow 是由社区驱动的深度内容平台，致力于提供有价值的信息，有态度的思考。
社区：
订阅频道：https://t.me/TechFlowDaily
推特：@TechFlowPost
进微信群添加助手微信：blocktheworld