如何正确解析NEAR Data Lake Indexer中的交易信息

一、获取已执行交易信息需解析的文件 #

核心解析Shard_(N).json文件，Block.json仅存储区块元数据（高度、时间戳等），不包含交易执行细节。重点关注分片文件里的两个关键结构：

• transactions数组：存储当前区块中用户提交的原始交易（此时交易仅完成提交，尚未执行）
• receipt_execution_outcomes数组：存储当前区块中执行完成的收据结果，这才是交易最终执行的状态（成功/失败、日志、返回值等）

二、交易执行结果是否会在下一个区块生成？ #

不一定是下一个区块，但肯定在后续某个区块生成。NEAR的交易执行逻辑是：

1. 交易在提交区块中被处理，生成对应收据（可能是多个，比如跨分片调用或嵌套执行场景）
2. 收据由网络调度到后续区块执行，调度时间取决于网络负载、分片逻辑，没有固定的区块间隔

三、如何解析后续区块中完成确认的交易？ #

按以下步骤追踪：

1. 在交易提交的原始区块中，从transactions数组拿到目标交易的hash，同时记录该交易生成的所有收据hash（在transactions[].receipts中）
2. 遍历后续所有区块的Shard_(N).json文件，在receipt_execution_outcomes数组中匹配收据hash
3. 找到匹配项后，通过outcome.status判断执行结果（SuccessValue/SuccessReceipt为成功，Failure为失败），outcome.logs可查看合约输出日志，outcome.receipt_ids可追踪嵌套执行的后续收据

注意：如果是跨分片交易，收据可能被发送到其他分片的区块，需要监听所有分片的文件。

四、"list_nft"交易在当前区块分片数据的位置 #

如果这笔交易刚提交到当前区块（尚未执行完成），它会出现在当前区块对应分片文件的transactions数组中：
具体层级为：transactions[].actions[]，其中该action的类型为FunctionCall，且function_call.method_name等于"list_nft"

交易执行生成的收据会出现在当前区块的receipts数组中，但收据的执行结果要等后续区块的receipt_execution_outcomes里才能获取到。

内容的提问来源于stack exchange，提问作者Cristian Romero