区块链数据深度解析

每条区块链都保存着不可篡改的交易和事件记录。Web3 应用依赖区块链数据来实现警报、仪表盘、决策制定或开发新功能。这对 web3 至关重要,因为它驱动着从去中心化应用到基础设施、再到 NFT 的一切。

本指南将涵盖区块链数据的各个方面,从链上和链下数据,到区块链索引和子图。读完本指南后,你应该能更深入地理解区块链数据是如何生成、存储和访问的。

什么是链上数据?

链上数据是指存储在区块链网络上的所有信息。它是该网络上发生过的所有交易的不可篡改记录,且公开可供所有人查看。链上数据有许多不同的类型,例如:

• **交易数据:**涵盖每笔链上交易的信息,如发送方和接收方、转账金额以及交易手续费。
• 区块数据:涵盖每个区块的信息,如前一个区块的哈希、区块内包含的交易、区块的时间戳,以及矿工手续费和奖励。
• **智能合约数据:**涵盖链上已部署的所有智能合约的信息,如合约代码本身、合约状态以及合约发出的事件。

与链下数据不同,链上数据不可更改,这对于全面了解区块链网络的状态非常重要。这些数据可用于追踪链上资产的流动、验证交易是否成功完成,以及生成关于网络活动的洞察。

链上数据面临的挑战是,有效地访问它可能很繁琐。尽管链上数据随时可用,但它是以机器可读的格式编码的;这种方式优先考虑安全性,但牺牲了人类可读性。人类可读的格式可以是 JSON 和 XML 之类的类型,这正是 ABI(应用二进制接口)发挥作用的地方。

数据结构是如何定义的?

如前所述,链上数据的存储方式与常规数据不同。它通常以字节码等机器可读格式存储。

ABI(应用二进制接口)帮助开发者监控数据并将其解码为人类可读的格式。智能合约中的数据结构是使用 ABI 定义的。ABI 充当函数选择器,有助于定义如何与智能合约交互,以及每个函数接受和返回的数据类型。换句话说,它是一种以人类和机器都能轻松理解的方式表示数据结构的标准方法。

区块链数据存储在哪里?

区块链数据通常存储在分布式账本中,这意味着它不是存储在单一位置,而是存储在一个节点网络上。节点是存储和确保区块链数据安全的基本组成部分,因为每个节点都维护着一份数据副本。下面列出了几种不同类型的节点及其大致工作方式:

• 全节点:顾名思义,全节点存储完整的区块链历史记录以及网络的最新状态(最近的 128 个区块)。所有客户端都需要最新状态来验证新到来的交易。理论上,所有以前的状态都可以从全节点推导出来,但这需要消耗大量的计算资源。当开发者需要访问区块链的最新数据和状态时,应该查询全节点。举例来说,在 Ethereum 上,产生一个新区块的平均时间约为 13 秒,你只能检索到最近 28-29 分钟的链上状态。
• 归档节点:除了完整的区块链历史记录外,归档节点还保留每个区块的历史状态记录。这使得归档节点在处理历史数据请求时,效率比全节点高得多。当需要历史数据时,开发者应该查询归档节点,因为它不像全节点那样需要重新生成状态。对于创建分析工具以及其他需要快速访问历史记录的工具的开发者来说,归档节点是理想的选择。
• 轻节点:这类节点只存储区块头,即在网络上进行交易所需的最少数据。当开发者需要从区块头中检索基本的区块链数据时,可以选择查询轻节点。

节点并不是存储数据的唯一方式。数据也可以在链下存储在数据库、云存储服务甚至本地服务器中。链下存储数据可能不如链上存储安全,但它对许多应用来说仍然很有用,因为访问起来更便宜、更快速。当数据存储在链下时,链上通常只存储用于定位链下数据所需的信息。

智能合约与区块链存储

智能合约存储在节点内的区块链上,然而智能合约本身也有其数据存储机制。智能合约中的数据存储遵循一种叫做合约存储布局的机制。合约存储布局是指规定合约的存储变量如何在长期内存中排列的一系列规则。

对于 Solidity(一种用于构建智能合约的高级编程语言)而言,有 3 种不同的内存类型可以指示 EVM 将变量存储在何处:memory、calldata 和 storage。

Memory:用于存储在函数执行期间所需的临时数据

Calldata:一个特殊的数据位置,包含函数参数

Storage:数据在区块链上永久存储的位置

数据存储 vs. 文件存储

数据存储在最简单的形式下,是指保存数据以便日后检索和使用的过程。而文件存储则不同于数据存储,它是将实际文件存储在与文件元数据不同的位置。这种分离通常是为了提升性能、降低成本或提高安全性。

将文件存储与数据存储分离的一种常见方式是使用去中心化文件存储系统,如 IPFS 或 Arweave。这些系统允许用户将文件存储在分布式计算机网络中,并可以通过减少需要存储在区块链本身上的数据量来降低成本。

概括来说,关于文件的元数据存储在链上,而文件本身存储在链下。当应用需要访问该文件时,可以从元数据中检索 IPFS 或 Arweave 的 URL。应用随后可以使用该 URL 从 IPFS 或 Arweave 下载文件。

什么是 IPFS?

IPFS 使用内容寻址系统,每个文件都基于 CID(内容标识符)进行标识。CID 是唯一的哈希值,始终指向同一个文件,无论该文件存储在何处。

这意味着如果文件发生更改或更新,哈希值也会随之改变。这种内容寻址系统使得文件可以根据其 CID 而非其存储位置进行存储和检索。

IPFS 的大致工作流程如下:

1. 为文件创建一个 CID
2. 然后将文件上传到 IPFS 网络
3. IPFS 在一个 DHT(分布式哈希表)中存储关于网络中哪个节点持有与该 CID 关联的文件的信息
4. 随后可以用该哈希值查询 DHT,以找到存储该文件的节点
5. CID 存储在代币智能合约中

Arweave

Arweave 是另一种分布式存储方案,同样使用 CID 来存储和访问内容,并在元数据中引用内容。主要区别在于,Arweave 在激励机制和永久性方面采取了不同的做法,通过激励节点永久保存数据。

数据发布 vs. 数据存储 vs. 数据可用性

要更好地理解区块链数据,我们还需要理解数据发布、数据存储和数据可用性分别意味着什么。简单来说:数据发布是指在区块链上使数据可供他人获取的过程,数据存储是指在区块链上保留数据的过程,数据可用性则是指确保区块链网络中的所有参与者都能访问数据的保证。

数据可用性之所以重要,是因为当验证者向 Ethereum 区块链添加区块时,必须将该区块的所有交易数据广播给网络中的其他验证者。验证者需要执行所有的交易数据,这意味着区块链能处理的交易量取决于其验证者能执行多少——简而言之,这就是数据可用性问题。

数据可用性的核心问题之一,是在无法获取整个区块的情况下(数据发布),如何知道某个区块是否已被发布。

数据发布面临的主要挑战在于,区块生产者不会在包含未知内容的区块之上继续生产区块。这意味着含有未发布数据的区块可能会被直接忽略。一旦数据发布完成,数据存储的问题便随之出现,然而全节点会将数据保存多久尚不明确。这可能令人担忧,因为我们无法强制节点保留数据,从而进一步加剧了数据可用性方面的顾虑。

模块化区块链与替代性数据可用性

模块化区块链是专注于特定功能的区块链。例如,某个模块化区块链可能专注于数据可用性,同时依赖其他区块链或系统来完成执行或共识等其他任务。

模块化区块链通过采用多种技术,如链下数据存储、数据压缩、分片等,创建替代性数据可用性层,使得发布 calldata 比发布到 Ethereum 上更便宜。

使用替代性数据可用性层的模块化区块链的一个例子是 EigenDA。EigenDA 是一个建立在 Arweave 之上的去中心化数据可用性层。EigenDA 允许用户将 calldata 发布到 Arweave,然后向 Ethereum 证明该 calldata 已经发布。这使得用户无需支付将 calldata 存储在链上所需的高昂 gas 费用,即可将 calldata 发布到 Ethereum。

链上数据的类型

在了解了什么是链上数据之后,我们将进一步深入探讨不同类型的链上数据,以及它们是如何生成、存储和访问的。

什么是交易数据?

交易数据包含与区块链上某笔交易相关的所有信息,例如:

• 发送方
• 接收方
• 转账金额
• 交易手续费
• 交易的时间戳

每当用户在区块链上进行交易时,就会生成这类数据。随后,这些数据会被广播给网络节点,以验证该交易并将其添加到账本中。

交易数据可以通过一种称为 Merkle 树的树形数据结构来存储和验证。Merkle 树是一种二叉树,可以实现快速的数据验证,树中的每个节点都是其所包含数据的哈希值。要验证 Merkle 树中数据的完整性,只需要树的根哈希即可。将数据存储在 Merkle 树中有助于尽量减小区块链的体积。由于关于 Merkle 树还有很多可以深入探讨的细节,你可以阅读 Alchemy 文档中关于 Merkle 树的更多内容。特别是对于 Ethereum,数据是使用 Patricia Merkle Tries 存储的——这是 radix trie(Patricia trie)和 Merkle 树的结合体。

在快速访问交易数据方面,你可以简单地使用区块链浏览器,比如用于 Ethereum 交易的 Etherscan。区块链浏览器允许用户查看和搜索所有交易数据,可用于追踪代币的流动、识别欺诈性交易、开发区块链应用等。要查找某笔特定交易的数据,你需要该交易的哈希值。如果你的应用需要经常访问区块链数据,Alchemy 可以提供帮助。

元数据

元数据是提供关于区块链上交易和资产额外信息的数据。这可能包括如下额外细节:

• 资产的名称或符号
• 资产的总供应量
• 资产的所有权历史
• 资产的合约地址

与交易数据不同,元数据并非区块链运行所必需,但它对开发者构建区块浏览器、钱包和仪表盘等应用非常有用。元数据可以由智能合约或区块链自动生成并定义(例如交易元数据),也可以由用户手动定义(例如资产元数据)。

为了访问元数据,开发者可以使用 getMetadata 查询。要使用这些查询,开发者需要使用区块链 API,比如 Alchemy API。通过使用 getMetadata 查询,开发者可以构建各种应用,帮助用户理解并与区块链网络进行交互。

事件数据

事件数据是指智能合约在执行交易时发出的数据。这类数据可以包括如下信息:

• 发生的事件类型
• 发出该事件的智能合约的地址
• 关于该事件的详细信息(例如转移的代币数量、资产的新所有者等)

这些信息有助于开发者监控智能合约的活动,可以通过日志访问。日志是区块链上发生的所有事件的记录,由智能合约生成。这些日志可以在交易回执中找到,也可以通过向 eth_getLogs 发起请求来查看。

Calldata

Calldata 是调用函数时传递给智能合约的数据。换句话说,它是一种临时数据存储形式,外部调用者传入的函数参数在被传递到智能合约之前会存储在这里。Calldata 可以包含任何类型的数据,无论是整数、字符串、数组等等。它之所以重要,是因为它使得智能合约之间以及智能合约与用户之间能够进行通信;例如,在一个 NFT 智能合约中,calldata 可用于将某个 NFT 的所有权转移给某个用户。

区块链上所有操作都要收取 gas 费用,使用 calldata 也不例外。当一笔 L2 交易被发布到 Ethereum 上时,calldata 会包含在该交易中。这是因为 Ethereum 网络需要 calldata 来验证该交易,以及执行被调用的智能合约函数。calldata 所消耗的 gas 取决于 calldata 的大小以及其中所包含的数据类型。对于 Ethereum,每个区块所能包含的最大 calldata 为 1,048,576 字节。

Blobs

Blobs(二进制大对象)旨在通过让网络确认区块所附带的 blob 携带了正确的数据,从而使交易验证更加高效。Blobs 是随 proto-danksharding 提出的,这是一项旨在降低 calldata 成本并增加每个区块 calldata 容量的提案。

据称,proto-danksharding 通过引入一种名为 blob-carrying transaction 的新交易类型,使区块链上的 calldata 更加便宜。Blob-carrying transaction 与常规交易类似,但它们可以包含 data blobs。

Blob-carrying transaction 比常规交易更便宜,因为它们处理所需的 gas 更少。这是因为 data blobs 存储在链下,不需要包含在交易本身中。

data blobs 和 blob-carrying transaction 的引入,将使得在 Ethereum 区块链上更便宜地存储和处理大量数据成为可能。

什么是区块链索引?

书中的索引包含了关键词和概念所在的页码。类似地,区块链索引是指以便于搜索和查询的方式组织和存储区块链数据的过程。理解这一点对于理解区块链数据非常重要,因为它使用户能够以更高效、更有效的方式访问和分析数据。

由于区块链遵循按时间排序的结构,数据可能分散在众多区块中,并变得错综复杂。索引旨在通过为区块链数据建立索引来解决这个问题。

这个索引是一个数据库,它以针对搜索和查询进行了优化的方式存储区块链数据的一个子集。对数据建立索引有多种不同的方法,例如:对交易相关信息建立索引、对地址建立索引、对智能合约交互建立索引等等。已建立索引的数据随后可以由开发者通过 GraphQL、Alchemy 以及其他 web3 协议提供的 API 进行访问。

常见的索引使用场景

既然我们已经了解了区块链索引对于开发者更高效地搜索和查询数据有多大帮助,接下来让我们看看索引的几个常见使用场景。

索引交易历史 - 这可用于追踪像 Uniswap 资金池这样的交易量和流动性,以及识别最大的交易者和巨鲸。

用于分析和报告的索引 - 这可用于针对交易量、gas 费用和用户活动等各类指标生成报告。在追踪和分析某个特定智能合约、加密货币、市场趋势的表现,或者理解用户活动(例如活跃钱包数量、已处理交易数量等)时,这尤其有用。

元数据索引 - 这可用于追踪 NFT 的所有权和转移情况。一个实际的例子是 NFT 分析工具,你可以针对某个特定 NFT 系列的交易索引进行查询,以了解购买/所有权历史等相关细节。

智能合约事件索引 - 这可用于追踪代币的流动(例如某个特定 ERC-20 代币的转账事件)、借贷活动,或者更好地理解 NFT 市场,仅举几个具体例子。总的来说,对智能合约事件建立索引有助于我们监控智能合约的活动,这有助于识别潜在弱点,甚至发现新应用和服务的机会。

链下与链上索引

索引可以存储在链上或链下,各自有其优点和取舍。例如,Satsuma 是一个被 Alchemy 收购的链上索引协议。Satsuma 使用 GraphQL,这是一种用于 API 的查询语言,其工作方式是通过子图扫描网络区块和智能合约,在一次 API 调用中从各种来源收集数据。链下索引协议的工作方式,要么是将索引保存在节点的本地存储中(例如 SubQuery),要么是将其存储在传统的云服务器中,如 AWS,这可能比链上索引更快。无论使用链下还是链上索引协议,开发者都可以方便地使用查询语言:

• GraphQL - 开发者可以使用 GraphQL 查询子图,以获取某个特定 ERC20 代币的转账历史。
• SQL - 开发者可以使用 SQL 查询链下索引,以获取在某条特定区块链上已部署的所有智能合约的列表。
• Elasticsearch - 开发者可以使用 Elasticsearch 查询链下索引,以获取某条特定区块链上最受欢迎的 NFT。

区块链数据是如何被访问的?

在了解了一些关于链上数据及其存储方式的知识后,我们可以进一步深入探讨开发者实际上如何访问区块链数据。

查询节点

访问区块链数据最直接的方式之一是查询节点,不过这也可能是资源消耗最大的方式。

要查询节点,你必须使用 JSON-RPC 通过全节点或归档节点(如前所述,即包含区块链完整副本的节点)来访问数据。要使用 JSON-RPC 查询某个节点,开发者必须向该节点发送一个 JSON 对象,其中包含要调用的方法、该方法的参数,以及 JSON-RPC 版本。

通过 Alchemy 这类提供 JSON-RPC API 供开发者查询节点的解决方案,可以轻松完成这一操作。

在查询节点以获取特定区块链事件时,事件过滤器也很有用。要使用事件过滤器,你需要指定想要过滤的事件类型以及该事件的参数。使用事件过滤器的一种简便方式是通过 Alchemy 的 Node API。Alchemy 的 Node API 是一项完全托管的服务,包含运行节点所需的全部基础设施,以及便于与节点交互和查询的 API 和 SDK。

通过 webhook 流式传输数据

通过 webhook 流式传输数据是一种实时获取区块链数据更新的方式。事件数据可以通过自定义 webhook 和 webhook 变量进行流式传输。具体做法是:选择一个区块链索引服务(如 Alchemy),在你的服务器上创建一个 webhook 端点,订阅相关事件,并配置 webhook 变量。Alchemy 特别允许用户创建自定义 webhook,这些 webhook 可以由多种区块链事件触发,例如新交易、新智能合约部署以及智能合约状态的变化。Alchemy 最近还升级了其自定义 webhook,以帮助开发者更精确地缩小数据流范围,并可以通过变量轻松更新 webhook 查询。

查询子图

子图是由社区创建的开源 API,用于从 Indexer、Curator 和 Delegator 处检索区块链数据。由于子图是基于 GraphQL 构建的,开发者可以使用 GraphQL API 来查询子图。子图既可以是托管的,也可以是自托管的。托管子图可以通过向 GraphQL API URL 发送 GraphQL 查询来查询。自托管子图可以通过将子图部署到 GraphQL 服务器来查询。这可以通过 Satsuma 这类解决方案来实现,它允许开发者部署自己的子图。

查询数据仓库

数据仓库针对查询历史数据进行了优化,通常采用结构化格式。而数据湖则存储大量通常是非结构化或半结构化的数据。Dune Analytics 是一款可用于查询、提取和可视化数据湖中数据的工具。Dune 通过提供诸如数据集浏览器等工具来实现这一点,让你能够探索不同链、数据集、原始区块链数据等内容。你也可以通过回填数据库并通过自定义 webhook 流式传输数据来创建自己的数据湖。

结语

总而言之,理解区块链数据对于任何希望使用或构建 web3 基础设施或应用的开发者都很有用。链上数据存储在区块链上,可以细分为不同类型,如交易数据、元数据、事件数据、calldata 和 blob。这些数据随后存储在节点中,并可以根据不同的使用场景通过多种方式进行访问。