区块链数据深度分析

每个区块链都保存了不可更改的交易和事件记录。Web3 应用依赖于区块链数据来提供警报、仪表板、决策支持或提出新特性。它对于 Web3 是至关重要的，因为它为去中心化应用、基础设施和 NFT 提供支持。

本指南将涵盖区块链数据的各个方面，从链上数据和链下数据，到区块链索引和子图。到本指南结束时，你应该能更深入地理解区块链数据是如何创建、存储和访问的。

什么是链上数据？

链上数据就是存储在区块链网络上的所有信息。它是该网络上所有曾发生过的交易的不可更改记录，所有人都可以公开查看。有许多不同类型的链上数据，例如：

• 交易数据： 这涵盖了与区块链上每笔交易相关的信息，如发送者和接收者、转账金额和交易费用。

• 区块数据： 这涵盖了关于区块链上每个区块的信息，如前一个区块的哈希、包含在区块中的交易、区块的时间戳，以及矿工费用和奖励。

• 智能合约数据： 这涵盖了所有已在区块链上部署的智能合约的信息，如合同代码、合同状态及合同发出的事件。

与链下数据不同，链上数据无法被更改，这对于获取区块链网络的整体视图至关重要。这些数据可用于跟踪区块链上的资产流动，验证交易是否成功，以及生成网络活动的见解。

链上数据的挑战在于有效访问它可能是麻烦的。尽管它可以方便地获取，但链上数据是以机器可读的格式编码的；这优先保证了安全性，但牺牲了人类可读性。人类可读格式可以是 JSON 和 XML，这就是 ABI（应用程序二进制接口）发挥作用的地方。

数据结构如何定义？

如前所述，链上数据的存储方式与常规数据不同。相反，它通常存储为机器可读格式，例如字节码。

ABI（应用程序二进制接口）帮助开发人员监控和解码数据成可供人类阅读的格式。智能合约中的数据结构是通过 ABI 定义的。ABI 充当函数选择器，帮助定义如何与智能合约互动，及每个函数接受和返回的数据类型。换句话说，它是一种标准的方式来表示数据结构，使得人类和机器都能轻松理解。

区块链数据存储在哪里？

区块链数据通常存储在分布式账本中，这意味着它不存储在单一位置，而是存储在一个节点网络中。节点是存储和确保区块链数据安全的基本组件，因为每个节点都维护一份数据副本。下面概述了几种不同类型的节点及其工作原理：

• 完整节点： 顾名思义，完整节点存储整个区块链历史以及网络的最新状态（最新的 128 个区块）。最近的状态是所有客户端需要验证传入交易的内容。理论上，所有以前的状态都可以从完整节点推导出来，然而，这会使用大量的计算能力。开发者在需要访问最新数据和区块链状态时应查询完整节点。在以太坊上，生产新块的平均时间约为 13 秒，你只能从过去28-29分钟内检索链状态。

• 归档节点： 除了完整的区块链历史，归档节点还维护每个区块历史状态的记录。这使得归档节点能够比完整节点更高效地处理历史数据请求。当需要历史数据时，开发者应该查询归档节点，因为它不需要像完整节点那样再生成状态。对于创建分析工具和需要快速访问历史的其他工具的开发者来说，归档节点是理想的。

• 轻节点： 这些节点仅存储块头；在网络上进行交易所需的最小数据。当从块头检索基本区块链数据时，开发者可以选择从轻节点查询。

节点并不是存储数据的唯一方式。数据也可以存储在链下的数据库、云存储服务或甚至本地服务器中。链下存储的数据可能不如链上安全，但对于许多应用来说仍然有用，因为其访问成本更低且速度更快。当数据存储在链下时，通常只有用于定位链下数据的信息存储在区块链上。

智能合约与区块链存储

智能合约存储在区块链内的节点上，但是，智能合约本身也有数据存储机制。数据在智能合约中存储于称为合约存储布局的内容中。合约存储布局指的是支配合约存储变量在长期内存中布局的规则。

对于 Solidity（构建智能合约的高级编程语言），有三种不同的内存类型可以指示 EVM 将变量存储在哪里：内存、调用数据和存储。

内存： 用于存储在函数执行期间所需的临时数据。

调用数据： 这是一个特殊的数据位置，包含功能参数。

存储： 这是数据在区块链上永久存储的地方。

数据存储与文件存储

数据存储在最简单的形式上是保存数据的过程，以便后续可以检索和使用。另一方面，文件存储则不同，当实际文件存储在与关于文件的元数据不同的位置时。通常分离存储是为了提高性能、降低成本或提升安全性。

将文件存储与数据存储分开的常见方式是使用去中心化的文件存储系统，如 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 通过激励节点永久保存数据，采取了不同的激励和持久性方法。

数据发布与数据存储与数据可用性

要更好地理解区块链数据，我们还必须理解数据发布、存储和可用性意味着什么。简而言之定义这些术语：数据发布 是使数据在区块链上可供他人使用的过程，数据存储 是将数据保留在区块链上的过程，数据可用性 是所有区块链网络参与者均可访问数据的保证。

数据可用性很重要，因为当验证者将区块添加到以太坊区块链时，他们必须将该区块的所有交易数据广播给网络上的其他验证者。验证者的任务是执行所有交易数据，这意味着区块链只能处理与其验证者能执行的相等数量的交易——这简而言之描述了数据可用性问题。

数据可用性问题的一个核心是，知道一个块是否已发布而无需访问整个块（数据发布）。

数据发布面临的主要挑战是区块生成者不会在包含未知内容的区块之上生成区块。这意味着包含未发布数据的区块可能完全被忽略。数据存储在数据发布后进入画面，但仍不清楚完整节点会存储这些数据多久。这可能令人担忧，因为我们无法强制节点保留这些数据，因此在数据可用性方面增加了更多担忧。

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

模块化区块链是处理特定功能的区块链。例如，一个模块化区块链可能专注于数据可用性，而依赖其他区块链或系统执行或共识等其他任务。

模块化区块链创建替代数据可用性层，使得将调用数据发布到以太坊的成本低于直接在链上发布的成本，使用各种技术如链下数据存储、数据压缩、分片等。

使用替代数据可用性层的一个模块化区块链的例子是 EigenDA。EigenDA 是一个去中心化的数据可用性层，它构建在 Arweave 之上。EigenDA 允许用户将调用数据发布到 Arweave，然后向以太坊证明调用数据已被发布。这使得用户可以将调用数据发布到以太坊，而无需支付与在链上存储调用数据相关的高昂 gas 费用。

链上数据的类型

现在我们已经讲解了链上数据的定义，接下来我们将更深入探讨不同类型的链上数据以及它们的生成、存储和访问方式。

什么是交易数据？

交易数据包含与区块链上交易相关的所有信息，如：

• 发送者

• 接收者

• 转账金额

• 交易费用

• 交易的时间戳

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

交易数据可以使用称为 Merkle 树的树形数据结构存储和验证。Merkle 树是二叉树，可实现快速数据验证，其中树中的每个节点都是其包含数据的哈希。要验证 Merkle 树中数据的完整性，你所需的仅是树的根哈希。将数据存储在 Merkle 树中的优点是可以帮助保持区块链的规模尽可能小。由于 Merkle 树中可以涉及更多详细内容，你可以在 Alchemy 文档中了解更多有关 Merkle 树的内容。具体来说，在以太坊上，数据是使用 Patricia Merkle Tries 存储的——这是一种基数 trie（Patricia trie）和 Merkle tree 的组合。

在快速访问交易数据方面，你可以使用像 Etherscan 这样的区块链浏览器来查询以太坊的交易。区块链浏览器允许用户查看并搜索所有交易数据，并可用于跟踪代币的流动、识别欺诈交易、开发区块链应用等。要查找有关特定交易的数据，你将需要交易哈希。如果你需要定期访问应用程序的区块链数据，Alchemy 可以提供帮助。

元数据

元数据是提供有关区块链上交易和资产的附加信息的数据。这可能包括附加细节，如：

• 资产的名称或符号

• 资产的总供应量

• 资产的所有权历史

• 资产的合约地址

与交易数据不同，元数据对于区块链的操作并不是至关重要的，但对于开发者创建应用（例如区块浏览器、钱包和仪表板）来说非常有用。元数据可以根据智能合约或区块链自动生成（例如交易元数据），也可以由用户手动定义（例如资产元数据）。

为了访问元数据，开发者可以使用 getMetadata 查询。使用这些查询时，开发者需要使用像 Alchemy API 这样的区块链 API。通过使用 getMetadata 查询，开发者可以构建多种应用程序，帮助用户理解和与区块链网络进行互动。

事件数据

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

• 发生的事件类型

• 发出事件的智能合约地址

• 事件的详细信息（例如，转移了多少代币、资产的新所有者等）

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

调用数据

调用数据是当调用函数时传递给智能合约的数据。换句话说，它是一种临时数据存储的形式，其中来自外部调用者的函数参数在传递到智能合约之前被存储。调用数据可以包含任何类型的数据，无论是整数、字符串、数组等。它是重要的，因为它允许智能合约之间以及与用户之间进行通信；例如，调用数据可以用于在 NFT 智能合约中将 NFT 的所有权转移给用户。

所有区块链操作都需要支付 gas 费用，使用调用数据也不例外。当将一个 L2 交易发布到以太坊时，调用数据就包含在交易中。这是因为调用数据是必要的，以便以太坊网络能够验证交易并执行被调用的智能合约函数。调用数据所需的 gas 由调用数据的大小和包含在调用数据中的数据类型来决定。对于以太坊，每个区块最多可以包含的调用数据为 1,048,576 字节。

Blob

Blob（二进制大对象）旨在通过让网络确认附加在区块上的 blob 携带正确的数据，从而提高交易验证的效率。Blob 的引入与 proto-danksharding 有关，这是为了降低调用数据成本并增加每个区块中调用数据的大小的提案。

原型 danksharding 被认为通过引入一种称为 blob-carrying transaction的新交易类型，使得在区块链中调用数据成本更低。Blob-carrying transactions 类似于常规交易，但可以包含数据 blobs。

Blob-carrying transactions 比常规交易便宜，因为它们在处理时所需的 gas 较少。这是因为数据 blobs 存储在链下，并且不需要包含在交易中。

数据 blobs 和 blob-carrying transactions 的引入将使得在以太坊区块链上以更便宜的方式存储和处理大量数据成为可能。

什么是区块链索引？

书中的索引包含提及关键字和想法的页码。同样，区块链索引是以一种便于搜索和查询的方式组织和存储区块链数据的过程。这在理解区块链数据时非常重要，因为它使用户能够以更高效和有效的方式访问和分析数据。

由于区块链遵循按时间顺序组织的结构，数据可能分散在多个区块中并可能变得交织在一起。索引的目的是通过创建一个区块链数据的 索引 来解决这个问题。

这个索引是一个数据库，它以优化搜索和查询的方式存储区块链数据的子集。要索引数据，有多种不同的索引方法，例如：索引与交易相关的信息、索引地址、索引智能合约互动等。然后，开发者可以通过 API 访问已索引的数据，提供与 GraphQL、Alchemy 和其他 web3 协议的交互。

常见的索引使用案例

现在我们知道区块链索引对开发者高效搜索和查询数据是多么有用，让我们来看看一些常见的索引使用案例。

索引交易历史 - 这可用于跟踪 Uniswap 流动池等的交易量和流动性，以及识别最大的交易者和鲸鱼。

用于分析和报告的索引 - 这可用于生成各种指标的报告，例如交易量、gas 费用和用户活动。在跟踪和分析特定智能合约、加密货币、市场趋势表现或了解用户活动（例如，活跃钱包数量、处理的交易数量等）时，这尤其有帮助。

索引元数据 - 这可用于跟踪 NFT 的所有权和转移。一个实际的例子可能是 NFT 分析工具，你可以针对特定 NFT 收藏的交易索引进行查询，以了解购买/所有权历史及其他相关细节。

索引智能合约事件 - 这可用于跟踪代币的流动（例如，特定 ERC-20 代币的转移事件）、借贷活动，或更好地理解 NFT 市场等特定示例。总体而言，索引智能合约事件帮助我们监控智能合约活动，这可能帮助识别弱点，或发现新的应用和服务机会。

链下和链上的索引

索引可以存储在链上或链下，各有各的优势和权衡。例如，Satsuma 是一个链上 索引协议，已被 Alchemy 收购。Satsuma 使用 GraphQL，一种用于 API 的查询语言，通过使用扫描网络区块和智能合约以从各种来源收集数据的子图运行。链下索引协议则通过在节点的本地存储中保存索引（例如 SubQuery），或通过存储在 AWS 等传统云服务器中工作，这可能比链上索引更快。无论是链下还是链上的索引协议，开发者都可以轻松使用查询语言：

• GraphQL - 开发者可以利用 GraphQL 查询特定 ERC20 代币的转移历史的子图。

• SQL - 开发者可以使用 SQL 查询链下索引中已在特定区块链上部署的所有智能合约的列表。

• Elasticsearch - 开发者可以使用 Elasticsearch 查询链下索引中某个特定区块链上的最受欢迎的 NFT。

如何访问区块链数据？

现在我们已经了解了链上数据及其存储方式，我们可以更深入探讨开发者们实际上是如何访问区块链数据的。

查询节点

访问区块链数据的最直接方式之一是查询节点，然而，这也可能是资源密集型的。

为了查询节点，你必须使用 JSON-RPC 通过完整节点或归档节点（如前所述包含完整区块链副本的节点）访问数据。使用 JSON-RPC 查询节点时，开发者必须向节点发送一个 JSON 对象，该对象包含你要调用的方法、方法的参数和 JSON-RPC 版本。

这可以通过提供 JSON-RPC API 的解决方案，如 Alchemy 来轻松完成。

要查询节点的帐户余额，你将向节点发送以下 JSON 对象（来源）

事件过滤器在查询节点以获取特定区块链事件时也可能非常有用。要使用事件过滤器，你需要指定要过滤的事件类型和事件的参数。使用事件过滤器的简单方法是通过 Alchemy Supernode。Alchemy Supernode 是一个完全托管的服务，包含运行节点所需的所有基础设施，还有使与节点交互和查询变得简单的 API 和 SDK。

使用 Webhook 流式传输数据

使用 webhook 流式传输数据是一种获得区块链数据实时更新的方法。事件数据可以使用自定义 webhook 和 webhook 变量进行流式传输。这是通过选择一个区块链索引服务（如 Alchemy）、在你服务器上创建一个 webhook 端点、订阅事件并配置 webhook 变量来完成的。特别是，Alchemy 允许用户创建 自定义 webhook，这些 webhook 可以通过多种区块链事件触发，例如新交易、新智能合约部署和智能合约状态的更改。Alchemy 最近还 升级了他们的自定义 webhook，帮助开发者缩小数据流以提高精确度，并使用变量轻松更新 webhook 查询。

查询子图

子图是由社区创建的开源 API，用于从索引器、策展人和委托者处检索区块链数据。由于子图是使用 GraphQL 构建的，开发者可以使用 GraphQL API 查询子图。子图可以托管或自托管。托管子图可以通过向 GraphQL API URL 发送 GraphQL 查询进行查询。自托管子图可以通过将子图部署到 GraphQL 服务器进行查询。这可以通过类似于 Satsuma 的解决方案来实现，允许开发者部署自己的子图。

查询数据仓库

数据仓库优化了历史数据的查询，通常采取结构化格式。另一方面，数据湖存储大量通常是非结构化或半结构化的数据。Dune Analytics 是一种工具，可以用来查询、提取和可视化数据湖中的数据。Dune 通过提供工具（例如数据集浏览器）来实现这一目的，使你能够探索不同链、数据集、原始区块链数据等。你还可以通过填补数据库并通过自定义 webhook 流数据来创建自己的数据湖。

结论

总之，理解区块链数据对于任何希望使用或构建 Web3 基础设施或应用程序的开发者来说都是有用的。链上数据存储在区块链上，可以细分为不同类型，例如交易数据、元数据、事件数据、调用数据和 blobs。然后，这些数据存储在节点中，可以通过多种方法访问，具体取决于实际的使用案例。

• 原文链接： alchemy.com/overviews/bl...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～