【发布时间】：2020-11-13 18:10:12
【问题描述】：
我正在尝试仅在客户端（而不是运行时）中获取最终块的块数据（外部数据）。我可以看到有一个名为 chain_getBlock 的 RPC 端点。我认为这个端点不只过滤最终块是正确的吗？
如果是这样，如果我只关心最终块，是否足以检查 Justification 是否为 None？
谢谢
【问题讨论】：
【发布时间】：2020-11-13 18:10:12
【问题描述】：
解决方案：
我会通过以下方式获得最终头部的外在信息：
- chain_getFinalizedHead 获取最佳最终区块的哈希值。
- 将该区块哈希传递给chain_getBlock以获取签名区块。
chain_getFinalizeHead 使用客户端的本地信息，因此它不是来自运行时。
上下文：
在您描述的用例中，我认为使用 justification 字段来检查块是否已完成是没有意义的。基于 GRANDPA 的链中的大多数区块都没有理由，原因如下：
- 理由可能根本不存在，因为 GRANDPA 最终确定的是一条链，而不是一个区块。 （即，您始终可以证明佳能区块 #5 是最终的，并证明佳能区块 #10 的合理性，并且实际上每隔几个区块就完成一次，而不是每个区块。）
- GRANDPA 的当前实现只需要存储理由 对于链上会话的第一个块，此时 GRANDPA 权限集可能会更改。同步客户端需要验证每个 GRANDPA 权限集更改的最终性，并且他们使用存储在链上的理由来这样做。
- 目前，周期性理由以比会话更改更频繁的速率存储在链状态中。
值得注意的是，客户端确实在其本地数据库中的每个块旁边存储了对齐，但除了上面提到的情况之外，它们不是运行时状态的一部分。
感谢André Silva，因为大部分回复都是他向我解释的信息。
【讨论】：
-
感谢您的回复。只是为了确认，如果我只需要来自客户端的理由（而不是运行时状态），是否应该始终填充它？
-
不，它不会总是被填充，因为每个块都没有理由。在实践中，客户每隔几个块就有一个理由，因为它只每隔几个块就完成一次。 （第一个要点中提到的概念）。