FP是链上数据分析平台以及数据处理基础设施,使命是让链上数据分析以及使用随手可得。目前,Footprint 从 22 条公链上收集、解析和清理数据,把无语义以及无序的链上数据,转化成让用户能使用无代码拖放界面、SQL等多种形式构建图表以及仪表盘。除了提供链上原始数据,Footprint 根据业务逻辑抽象出具有业务逻辑的流水数据,既能实现快速生产数据,也能方便分析师在此数据的基础上,快速计算自己需要的业务指标。而这也适用于开发者使用。
我们先来谈谈开发整合数据的方法。目前,有几种不同的方法来处理区块链数据,而选择哪种方法将取决于你的具体需求和目标。
区块链浏览器是一个网站或工具,允许你查看存储在区块链上的数据。这是一种快速和简单的方式来访问有关区块链上的特定交易、区块和其他数据的信息。
区块链浏览器可以成为访问和查看存储在区块链上的数据的有用工具,但它们对于软件开发集成存在一些限制。以下是区块链浏览器可能存在限制的几个例子:
主要是围绕原始数据。区块链浏览器通常显示区块链的原始数据。如果要使用,需要在原始数据上实现抽象,特别是对于那些专注于交付而不是某些区块链的技术细节的项目来说,会十分繁琐。
定制选项。区块链浏览器通常被设计为用户友好和易于使用,这意味着他们可能不提供大量的定制选项。你难以根据你的具体需求或偏好来进行二次开发与统计。
高级搜索功能。区块链浏览器通常有基本的搜索功能,但他们可能不支持更高级的搜索功能,如布尔运算符或正则表达式。这可能使搜索区块链上的特定信息变得困难。
互动性。许多区块链浏览器本质上是只读工具。
虽然区块链浏览器可以成为访问和查看区块链原始数据的有用方式,但它们确实有一些限制,在决定基于它们实施你的解决方案基础设施之前,你应该意识到这些限制。
设置自己的索引器来处理区块链数据可以有几个优势,也有一些潜在的劣势。下面是对应的几个例子:
优势:
定制化。当你建立你自己的索引器时,你可以完全控制数据如何被索引和访问。这可以让你根据你的具体需要和喜好来定制索引器。
独立性。通过建立你自己的索引器,你并不依赖第三方服务来维护和更新索引。这可以为你如何处理区块链数据提供更大的控制和灵活性。
提高安全性。当你设置自己的索引器时,你可以实施自己的安全措施来保护数据,防止未经授权的访问。
劣势
复杂性。建立自己的索引器可能是一个复杂而耗时的过程,特别是如果你是区块链技术工作的新手。你需要对底层技术有深刻的理解,并愿意投入所需的时间和精力来启动和运行索引器。
维护。一旦你建立了自己的索引器,你将负责维护和更新它。这可能需要持续的技术专长和资源,如果你没有必要的知识或支持,这可能是一个不利因素。
成本:建立你自己的索引器可能是昂贵的,因为你将需要购买运行索引器所需的硬件和软件,以及支付任何相关费用,如电力和带宽。
总的来说,设置自己的索引器来处理区块链数据可以提供更大的控制和定制,但它也可能是一个复杂而昂贵的过程。
使用第三方索引器来处理区块链数据可以有几个优势,也有一些潜在的劣势。下面是对应的几个例子:
优点:
易用性。第三方索引器通常被设计成易于使用,这意味着你可以迅速开始处理区块链数据,而不需要学习大量的技术细节或运行你的自定义索引解决方案(不管是自主开发还是现成的SDK)。
高级搜索功能。许多第三方索引器提供高级搜索功能,如布尔运算符和正则表达式,这可以使搜索区块链上的特定信息更加容易。这些可以有许多真正的实现,但最常见的是将索引的数据添加到关系数据库中,这意味着完全的 SQL 支持。
可扩展性。第三方索引器通常被设计为处理大量数据,这意味着如果你需要搜索或访问大型区块链的数据,它们可以是一个不错的选择。
可靠性。第三方索引器通常由专业机构运行,它们拥有资源和专业知识,以确保索引始终是最新的和准确的。解决方案并不总是去中心化的,因为它们专注于处理大量的数据,但绝大多数都是开源的,这增加了用户对服务的信心。
缺点:
依赖性。通过使用第三方索引器,你要依靠该服务来维护和更新索引。如果索引器遇到技术问题或脱机,你可能无法访问区块链数据。
有限的定制。第三方索引器通常被设计为易于使用,这意味着它们可能不提供大量的定制选项。这可能使你很难根据你的具体需求或喜好来定制索引器。
成本:一些第三方索引器可能对其服务收取费用,如果你的预算紧张,这可能是一个不利因素。
综上所述,使用第三方索引器来处理区块链数据可以是一个方便有效的选择,但有局限性,有时缺乏定制。
Footprint 的目标主要是降低分析数据和处理 web3 数据的门槛。这种方法是在易用性和灵活性之间取得平衡。这就是为什么我们的服务之一是 DaaS(数据库作为服务类型)。在我们仔细研究我们服务的优势之前,我们还将研究索引器的另一种实现方案,即SDK。
在接下来的章节中,我们将探讨只读区块链 API 应该具备的核心功能。我们将从不同的角度来看待这个问题,以及考虑其他的解决方案。区块链 API 的一些最重要的特征包括。
易用性和灵活性
可扩展性
兼容性
易用性和灵活性是区块链 API 的两个重要特征。一个易于使用的区块链 API 将使开发人员更容易开始构建基于区块链的应用程序,使他们能够快速建立原型并测试他们的想法,而不必花费大量时间学习如何使用API。
另一方面,灵活性是指区块链API支持广泛的用例和应用的能力。一个灵活的区块链 API 将允许开发者访问区块链的不同部分,并建立可以与不同类型的智能合约和其他基于区块链的资产互动的应用程序。这对那些希望建立可用于各种不同行业和背景的应用程序的开发者来说可能特别重要。
总的来说,拥有一个既容易使用又灵活的区块链 API 可以使开发者更容易建立创新和有用的应用程序,可以利用区块链技术的独特特点和能力。
我们的数据组织结构保障了 API 的易用性和灵活性,事实上,它影响到与 Footprint 生态系统互动的所有方面。Footprint 有一个建立在这个数据模型之上的 API,允许用户建立成熟的数据流程并进行数据分析,以及机器学习应用。我们称它为数据 AP I。我们同时支持两种类型的 API 和其中的两种子类型,以涵盖大多数情况。Rest API 和 SQL API。
REST API 允许我们快速集成一个应用程序,因为每个端点都是一个预先建立的、固定编码的、我们自己已经确定为最受欢迎的脚本。所有的端点都带有易于使用的过滤、排序和分页的工具。
SQL API 的接口适应性更强。在网络应用程序和 API 中使用相同的 SQL 查询的一个好处是,它可以简化开发和维护。通过在两个界面中使用相同的查询,开发人员可以避免为网络应用程序和 API 编写和维护不同的查询集。这可以节省时间和精力,并减少两个界面之间发生错误或不一致的风险。
另一个好处是,它可以提高网络应用程序和 API 所访问和操作的数据的一致性。通过使用相同的查询,两个界面将以相同的方式访问和操作相同的数据,确保数据保持一致和最新。
许多替代性分析解决方案允许用户根据不同层次的要求来分析不同的网络。然而,在大多数情况下,替代性解决方案往往走极端,要么实现一个非常灵活的产品,需要查询语言甚至编程语言的知识;或者提供一个非常简单的界面,固定的查询接口,但是相应地,灵活性低。
像 Moralis 和 Quicknode 这样的解决方案只有一个 REST API 接口。尽管有相当多的端点,但在返回数据的灵活性方面,它仍然限制了开发者。
Dune 最近推出了自己的 API。这个异步解决方案意味着在平台上初步存在一个特定 id(dune.com/query/{{query id}})下的查询,通过它可以执行 SQL 形式的查询。这种解决方案的关键限制是需要预先修改平台上的 SQL,以便随后执行更新的查询。
Chainbase 发布 SQL API 的方式与 Footprint 相同,但与 Footprint 不同的是,Chainbase 没有如此复杂的 ETL 以及语义化的数据,所以基本上 SQL 查询只能针对原始事务执行。
区块链 API 应该能够处理大量的数据和交易,允许开发者建立可以被许多用户同时使用的应用程序。
自2021年8月启动以来,Footprint Analytics 团队已经进行了多次架构升级,这得益于其强大的技术探索和迭代能力。在不到一年半的时间里,该团队已经能够成功实施这些变化。这证明了该团队在技术和数据科学领域的技能和专业知识。
通过实验,Footprint反复进行了三次全局性的架构更新,最终达成了一个满足平台各种用例要求的架构。关于实施的演变的更多信息可以在下一篇文章《Iceberg-Trino 如何解决链上数据面临的挑战》中找到。
在 Footprint 中,有两种模式可以执行对 SQL API 的查询 - 同步和异步。对同步端点的 API 调用意味着一旦收到应用程序的 HTTP 请求,SQL 查询就会被 Footprint 服务器执行,从而保持连接。这在使用轻量级请求时是有意义的,因为在这种情况下,应用程序不需要长时间等待执行。
对于大量的请求,建议使用异步请求。与同步请求不同,客户端应用程序在执行过程中不必与服务器保持连接,而是可以简单地立即获得请求 ID,根据该 ID,在一段时间后,分别获得执行结果。作为异步 API 的一部分,应该涵盖两个步骤来获取数据--下面的端点将被用来发送SQL 执行的 "命令"。
第二步是按访问前一个端点时获得的标识符发送请求以接收结果。
DuneV2 改变了整个数据库架构。Dune 现在正从 PostgreSQL 数据库过渡到托管在[[Databricks]] 的 [[Apache Spark]] 实例。当前,只有异步的 API。
区块链 API 应该与各种编程语言和开发环境兼容,这样开发者就可以使用他们最熟悉的工具和框架。
REST 当然更容易集成,因为每种编程语言都有许多库,方便提供与使这种类型的 API 的使用起来更加便捷。然而,归根结底,SQL API 和 REST 都是通过 HTTP 工作的,所以默认情况下,当涉及到发送请求时,开发经验几乎是相同的。
正如我们所分析的,在大多数情况下,一个应用程序使用现成的 DaaS 解决方案就足够了,原因是它们可以返回经过抽象的数据(而不仅仅是原始数据),并节省大量的时间和金钱。因为它们最终允许团队无需花费心思在基础设施搭建与维护上,而更加专注在为用户提供产品的价值。通过对比 DaaS 市场上的各种解决方案,Footprint 似乎是最理想的整合方案,因为它有最灵活的模型来生成请求,同时既容易使用。建立在现代的开源数据技术栈基础上,同时有效确保了数据获取的可用性,以及支持快速执行最复杂的请求。