diff --git a/docs/SolanaValidatorDocumentation/Validators/Blockstore.md b/docs/SolanaValidatorDocumentation/Validators/Blockstore.md
index ba36b79..5c54fe8 100644
--- a/docs/SolanaValidatorDocumentation/Validators/Blockstore.md
+++ b/docs/SolanaValidatorDocumentation/Validators/Blockstore.md
@@ -1,12 +1,12 @@
 # Solana 验证者节点中的区块存储(Blockstore)
 
-在一个区块达到最终确定性后，从该区块到起源区块的所有区块将形成一个线性链，也就是我们熟悉的区块链。然而，在此之前，验证者节点必须维护所有潜在有效的链条，称为分叉。分叉的自然形成过程是领导者轮换的结果，相关描述可见于[分叉生成](https://docs.solanalabs.com/consensus/fork-generation)。本文描述的区块存储数据结构是验证节点在区块最终确定之前应对这些分叉的方式。
+在一个区块达到最终确定性后，从该区块到起源区块的所有区块将形成一个线性链，也就是我们熟悉的区块链。然而，在此之前，验证者节点必须维护所有潜在有效的链，称为分叉。分叉的自然形成过程是领导者轮换的结果，相关描述可见于[分叉生成](https://docs.solanalabs.com/consensus/fork-generation)。本文描述的区块存储数据结构是验证节点在区块最终确定之前应对这些分叉的方式。
 
-区块存储允许验证者节点记录它在网络上观察到的所有分片（shred），无论顺序如何，只要分片是由预期领导者在给定槽位（slot）上签名的。
+区块存储允许验证者节点记录它在网络上收集到的所有分片（shred），无论顺序如何，只要分片是由预期领导者在给定槽位（slot）上签名的。
 
 分片被移动到一个可分叉的键空间，该键是`领导者槽位`和`分片索引`（在槽位内）的元组。这允许Solana协议的跳表结构被完全存储，而无需预先选择遵循哪个分叉、持久化哪些条目或何时持久化它们。
 
-对于最近的分片，修复请求会从RAM或最近的文件中服务；对于不太近的分片则将服务于更深层存储，作为区块存储以支持存储实现。
+对于最近的分片，修复请求会从RAM或最近的文件中获取；对于不太近的分片则从更深层存储获取，这种机制由Blockstore后端存储实现。。
 
 ## 区块存储的功能
 
@@ -38,7 +38,7 @@
 3. 链接- 当新槽位x的分片到达时，我们检查该新槽位的`区块数`（num_blocks，该信息被编码在分片中）。然后我们知道该新槽位链接到槽位`x-num_blocks`。
 4. 订阅 - 区块存储记录已“被订阅”的一组槽位。这意味着链接到这些槽位的条目将被发送到区块存储渠道以供重播阶段应用。详情见`区块存储API`。
 5. 更新通知 - 对于任意`n`，当slot(n).is_connected从假变为真时，区块存储通知监听器。
-6. 
+
 ## 区块存储API
 
 区块存储提供了基于订阅的API，重播阶段用来请求它感兴趣的条目。这些订阅API如下：
@@ -51,7 +51,7 @@
 ## 与银行的接口
 
 银行向重播阶段暴露了：
-1. `prev_hash`：它正在处理的PoH链，如由它处理的最后一个条目的哈希所指示。
+1. `prev_hash`：它正在处理的PoH链，由它处理的最后一个条目的哈希所指示。
 2. `tick_height`：当前由该银行验证的PoH链中的tick高度。
 3. `votes`：包含以下内容的记录堆栈：
 - `prev_hashes`：此投票之后的任何内容都必须链接到PoH。
@@ -59,6 +59,8 @@
 - `lockout period`：必须在分类账中观察多长时间链条才能在此投票下方链接。
 
 重播阶段使用区块存储API查找可以从之前的投票中挂靠的最长条目链。如果该条目链未挂靠在最新投票上，重播阶段会将银行回滚到该投票并从那里重播该链。
+
 ## 区块存储修剪
+
 一旦区块存储条目足够旧，表示所有可能的分叉变得不太有用，甚至可能在重启时导致重播问题。然而，一旦验证者的投票达到最大锁定期，任何不在该投票PoH链上的区块存储内容都可以被修剪和删除。