Axiom: Filling the gap in Web3 data access and empowering smart contracts

All articles1年前 (2023)发布 wyatt
100 0 0
Axiom旨在解决由于缺乏不可靠的数据访问和计算而导致的 Web3 应用程序乏善可陈的挑战。

撰写:camiinthisthang

Compiled by: Xiaobai Navigation Coderworld

“把所有东西都放在链上”对我来说一直感觉有点牵强。没有理由把许多东西放在链上,因为除了永久存储之外,你没法对这些数据做太多事情。虽然 The Graph 和类似的协议通过 GraphQL 实现了查询链上数据以用于前端集成的功能,包括全Xiaobai Navigation文搜索和过滤,但这些操作都是在客户端层面完成的。这意味着你实际上无法在智能contract层面利用这些数据来基于这些数据编写逻辑。这种限制导致 Web3 应用平面化和单一化——它们可以利用的唯一数据只是与用户交互的实时数据,如账户余额、当前区块号等。

传统应用程序通过利用用户在线活动来策划个性化和沉浸式的体验而蓬勃发展。不幸的是,Web3 的体验还没有办法做到这一点,这很大程度上导致了人们普遍认为 Web3 难以提供与用户产生共鸣的有意义的应用程序。

塑造数字格局的著名应用程序——Instagram、TikTok、Spotify、YouTube 等在它们的用户界面中展示用户过去的活动,并利用这些数据制定推荐算法、投放个性化广告以及将用户与符合其偏好的创作者连接起来,这种动态的设计空间在 Web3 中明显缺失。

之所以 Web3 做不到这一点,是因为我们没有可以在intelligentcontract层面信任地访问链上数据的工具。虽然可能令人惊讶,智能contract没有办法从存档节点读取数据——比如特定区块高度的历史 NFT 所有权或账户余额等信息——并利用这些数据驱动其操作中的条件逻辑。允许这种类型的数据在智能合约中被访问有一系列涉及Safety性和成本的不同折衷方案:

  • 开发运行该应用程序的人以 EOA 或多签的完全可信的方式将数据放在链上;

  • Chainlink 支持您需要的特定数据类型;

  • 您在合约中缓存数据(支付额外的合约存储)。

Axiom 提供无需信任的读取和计算

最近几个月,几个高性能的 ZK 团队的出现为以太坊生态系统开辟了新的可能性时代。其中包括 Axiom,这是一个 zk 项目,旨在解决由于缺乏不可靠的数据访问和计算而导致的 web3 应用程序乏善可陈的挑战。目前 alpha 版本已经在以太坊主网上线。

开发者可以向 Axiom 提交查询,通过存储证明信任地访问以太坊整个历史上的任何区块头、账户或存储值。Axiom 使用 zk 为所有查询结果生成有效性证明,并在链上进行验证,这意味着智能合约可以直接对这些结果进行操作,而无需额外的信任假设。

Axiom 抽象了许多与 zk 相关的特定于数学的知识,这在历史上一直是使用 zk 所必需的。关于 Axiom 最激动人心的事情是它允许开发者用 Solidity 编写智能合约,通过查询 Axiom 的合约然后开发者验证它们收到的响应,在自己的智能合约中使用这些数据。

Axiom 为开发者提供了 TS SDK 和他们的 AxiomV1Query 智能合约,让开发者可以在链上创建和提交查询,然后在他们的智能合约中使用经过验证的响应。交互如下所示:

  1. 发送链上查询:使用 Axiom SDK 创建查询并提交到 AxiomV1Query 智能合约。

  2. 等待查询完成:链下证明者将索引该查询,生成查询结果,并用 ZK 证明其有效性。该证明在链上进行验证,结果以 Merkle 化的形式写入 AxiomV1Query 合约存储。

  3. 读取查询结果:一旦结果在链上被验证,使用 SDK 从合约存储中获取查询结果,并在智能合约应用中信任地使用它们。

在我的心智模型中,使用 Axiom 有两个主要组件:

  1. 构建查询并将其发送到 Axiom 智能合约。

  2. 从 Axiom 智能合约中读取和验证响应。

构建和发送查询

第一步是使用 TS SDK 从 Node/Nextjs 项目向 Axiom 合约发送查询:

Axiom:填补 Web3 数据访问的空白,赋予智能合约新能力

开发者可以使用四种方法创建并发送查询:

  • newQueryBuilder – 创建查询的新实例;

  • append – 传入你想要证明的地址、存储槽和/或区块号;

  • build – 获取 keccakQueryResponse 和序列化查询;

  • sendQuery – 将查询发送到 AxiomV1Query 合约。

读取和验证响应

Axiom:填补 Web3 数据访问的空白,赋予智能合约新能力

一旦 Prover 生成 ZK 证明,它将写出该查询的“keccakQueryResponse”已被满足,并会触发“QueryFulfilled”事件。 开发者从 Axiom 合约存储中读取响应,并使用这些 SDK 方法在链上验证结果:

  • getValidationWitness – 允许用户证明他们声称的数据实际上提交到了 keccakQueryResponse 中;

  • areResponsesValid – 检查你提供的数据与链上存储的哈希是否匹配。

一旦你验证响应有效,你就可以将此响应作为参数传递给任何智能合约函数,该函数将根据此过程对账户施加限制,并在函数调用中传递经过验证的有效证明。

ZK 是否将使我们最终能够构建普通用户在意的应用?

你现在不仅可以生成存储证明并在智能合约中使用它们根据历史链上活动来编写逻辑限制操作,而且你可以首次使用这些历史数据创建丰富的体验,类似于 Web2 中的体验。

随着越来越多的用户、活动和数据上链,像 Axiom 这样的工具将对在不牺牲Safety性的前提下创建丰富的用户体验至关重要。

一些启发项目的想法,摘自 Axiom 的博文:

  • 通过智能合约根据链上活动进行的自治空投,而无需中心化机构。

  • 基于可信参与度评分的链上忠诚度系统。

  • 使用可证明的链下求解器来结算市场的求解器驱动型 DeFi 协议。

  • 参考过去交易的 NFT 地板价格预言机,以支持 NFT 借贷和衍生品的承保。

  • 利用随机性挖矿的随机性预言机。

  • 用于调整 AMM 中的费用或借贷协议中的 LTV 的可信波动率预言机。

  • 在 ZK 中被证明是从声称的算法生成的生成式 NFT。

The article comes from the Internet:Axiom: Filling the gap in Web3 data access and empowering smart contracts

相关推荐: 2013、2017、2021 牛市只有“减半”这一个驱动因素吗?

“减半”推动牛市的逻辑不仅是情况,还有成本因素。 减半的情绪与逻辑性 很多小伙伴认为“减半”给 #比特币 带来的影响是——稀缺,因此带动了人们囤积和炒作BTC的情绪。 其实,所谓“减半”是产量减半,全网投入同样的成本(算力)去挖矿,但是产出的 BTC 减半了。…

share to
© 版权声明

相关文章