在过去的几个月中，随着越来越多的开发者开始实施基于Tangle的解决方案，IOTA网络的活动显著增加。虽然这是一个非常有前途的发展状态，反映了IOTA越来越多的采用，但它也导致了数据库体积的增加，这可能会给硬件资源（特别是磁盘空间）有限的节点带来问题。
IOTA基金会一直在定期的执行全局快照（查看
全局快照的视频说明
和
最近的一次全局快照
），通过这种方式来修剪交易历史记录，并将得到的余额合并到一个新的创世状态，允许节点使用空数据库重新开始。然而，对于不断增长的帐本体积来说，这种处理方式越来越不切实际，因为它要求我们：
-
暂时停止协调员。
-
生成快照状态。
-
为社区提供时间来验证生成的文件。
-
最后重启协调员。
解决方案 - 本地快照
为了解决这个问题，我们一直在努力的实现一个名为Local Snapshots（本地快照）的功能。本地快照功能一直是IOTA路线图的核心部分。现在正在对该功能的初始实现进行内部测试，我们会及时向大家通告接下来的步骤，但是我们必须先对所有已经实施的更改进行校验，并收集与这个新功能的行为有关的足够指标。
本地快照期间的控制台输出
对节点运营者的意义
在深入研究本地快照的技术方面之前，我们想简要总结一下这个新功能为节点运营者带来的变化：
-
在搭建新节点时，可以基于小型本地快照文件进行同步，不再需要使用大型数据库文件来引导节点，这样节点可以在几分钟内完全同步。
-
节点对磁盘空间的需求大幅减少 - 实际上我们已经有节点运行在只有几百MB的硬盘空间中。
-
由于不再需要全局快照，因此理论上节点可以在无需维护的情况下运行数年。
-
节点应该能够每秒处理数千个交易，而且不再会出现数据库体积过大的问题。
本地快照的工作原理
为了理解本地快照的工作原理，我们首先需要澄清一些与Tangle工作方式有关的事情：
-
Tangle是一种数据结构，它的tips有很大的不确定性，但是随着时间的推移，确定性会逐渐提高。
-
因此，随着时间的推移，交易处在未确认状态的时间越长，那么该交易突然成为共识的可能性就越小。这就是需要对pending时间过长的交易执行“reattach”的原因。
-
为了验证交易并参与IOTA的共识，只需要知道pending交易的近期历史以及帐本的当前状态（余额）。
...
本地快照背后的基本原理相对容易理解，可以分为不同的方面：
修剪旧交易并保持余额
-
首先选择一个足够旧的已确认交易，并将此交易用作本地快照的“锚点”。
-
然后，修剪该交易直接或间接引用的所有交易，并相应地清理数据库。
-
在清理旧交易之前，检查哪些余额受到它们的影响，并将得到的帐本状态保存在本地快照文件中，随后IRI将其用作新的起始点。
固化入口点（新节点的快速同步）
虽然对于已经与网络完全同步的节点来说，全局快照时修剪旧交易并不是个问题，但是对于尝试进入网络的新节点来说，这会产生问题，因为它们不再能够轻松的检索可追溯至上一次全局快照的完整交易历史。
即使我们假设他们能够通过向permanodes请求丢失的交易来检索完整的历史记录，但是仍然需要很长的时间才能追赶上帐本的最新状态。这个问题并不新鲜，也是许多节点运营者使用另一个同步节点的数据库副本引导其节点的原因之一。
为了解决这个问题，我们不仅可以使用本地快照文件来作为保持节点状态的一种方法，而且还可以基于一个完全相同的文件（可以由社区和IF定期共享该文件）开始引导新节点的搭建。
要使用本地快照文件引导新节点，我们需要存储包括余额在内的更多细节：
这使我们可以将本地快照文件作为引导机制，以便快速的（在几分钟内）同步新节点，与使用整个数据库副本来引导新节点相比，本地快照文件更易提供和检索。
里程碑（更快的同步）
Permanodes
由于数据的修剪将通过一个简单的配置设定来控制，因此现在可以运行保留完整交易历史的permanode。在此之前，由于全局快照是一个网络范围的事件，所以无法实现permanode。
...
然后，自动重复获取本地快照的整个过程，这样节点就能够以相对恒定的空间需求运行，而且无需进行不必要的维护。
概要
即将推出的本地快照功能不仅可以解决随着IOTA采用的不断增长而出现的磁盘空间不足的问题，还可以简化新节点的设置，并允许组织和社区成员运行permanodes。
