$INJ 围绕著一个理念建立：所有对资金安全和市场当前状态至关重要的内容，应该存储在共识中，而所有与深厚历史相关的内容可以移至单独的数据层。对于订单簿来说，这尤其重要，因为每个订单和每笔交易都会增加对记忆体、磁碟和节点网络的负担。如果将整个历史直接存储在链的状态中，任何节点都会迅速变成一个笨重的数据中心。
在基本区块链层面，#Injective 存储最低限度的必要集合：活跃的限价单、保证金头寸、帐户余额和执行的最终结果。 也就是说，这是进行正确匹配、平仓和结算所需的内容。 一旦订单完全执行或取消，交易的详细信息将进入区块链事件，而不会保留在不断增长的状态树中。 这已经是第一层优化：共识节点使用紧凑的状态，而历史则转移到日志中。
每个订单的执行，无论是部分还是全部，都伴随著事件的发出：谁买了，谁卖了，在哪个市场，以什么价格和数量。 这些事件进入区块，由验证者签名，并成为不可变的链的一部分。 节点不需要在内存中保留一年的所有交易的表格，他们只需保留当前的订单簿快照，其余的可以在需要时通过顺序读取事件来恢复。
优化的下一个层级是专门的索引和API节点层。 它们专门用于「消化」事件流，重新组装订单历史、交易汇总表、K线图和图表。 本质上，这样的节点提升了自己的数据库，与链进行同步，聆听事件并为交易者和应用构建方便的展示。 同时，API节点不参与共识，并且可以独立扩展。
在Indexer API的文档中明确指出，这一层从事件中重建网络状态，并能够提供任意期间的历史数据——例如，用于图表建构或订单分析。 更重要的是，使用了经典数据库（如MongoDB）之上的串流机制：客户不再需要频繁轮询，而是订阅更新，索引器将最新的变更推送给他们。 这减少了重复请求的数量，并降低了基础设施的负担。
为了处理订单和交易的历史，开发者提供了单独的Indexer API端点。 它们允许根据市场、帐户或状态请求订单历史，而无需直接请求共识的RPC节点。 实质上，对历史数据的重选完全转移到专门的服务，该服务缓存结果并针对分析请求进行优化。 参与投票的节点不会在多年交易中浪费资源来提供复杂的选择。
另一个重要细节是对验证者节点层面上积极使用剪枝和快照。 在生态系统#Injective 中，提供了配置了旧区块剪枝和自动状态备份的节点。 这意味著共识节点可以存储最近的N千个区块，以便快速回滚和验证，而对于深历史，总是可以访问索引或档案节点。 这种角色分工大幅降低了对磁碟的需求，并加速了新参与者的同步。
索引节点反过来优化了存储，不仅是基于数量，还有数据结构。 它们并不是字面上存储每个事件「原样」，而是构建了聚合：按分钟和小时的K线图、日交易量、特定时间点的订单簿快照。 这使得应用程序和分析师能够通过紧凑的样本而不是每天数以百万计的原始记录来处理订单簿和交易的历史。
感谢串流功能和gRPC/WebSocket介面，许多客户只需「订阅」感兴趣的市场。 他们不需要每几秒请求一次：「显示最新交易」或「显示我所有的订单」。 他们随著新区块的出现而获得更新。 这种反应式方法减少了索引器和代理层的总流量，从而减轻了整个网络的负担。
值得单独提及的是水平扩展。 API和索引节点@Injective 可以在不同区域以不同的历史深度运行多个实例。 有些人保留从网络开始的完整档案，有些人只保存一年的交易，有些人仅保存最近几个月的交易，但反应速度却是最快的。 这样的配置动物园在验证者层面上是无法实现的，但在数据服务层面却运行良好。
对于验证者来说，这意味著较低的入门资源门槛。 他们只需能够有效处理区块并保持当前状态的硬件，而不必保留多TB的订单和交易历史档案。 共识节点的要求越低，参与者之间的分散性和竞争就越容易实现，这意味著网络的去中心化程度更高。
对于交易者和开发者而言，这种设计看起来是透明的：他们使用丰富的历史API，能够构建复杂的图表、进行策略回测、分析流动性和订单簿的行为。 在此过程中，底层的重任由索引器承担，而不是基础节点。 用户获得了历史的深度与性能，而不必考虑这一切如何在同一区块链上共存。
当然，这种架构也带来了风险。 将越多的逻辑和索引移至单独层级，越重要的是确保其开放性和可重现性：任何参与者都应能够启动自己的索引器，并将其数据与链的原始事件进行核对，而不依赖於单一的API提供者。 在Injective的情况下，这是通过将Indexer API构建在标准事件和开源代码之上，而不是依赖于封闭的专有方案来实现的。
最终，Injective回答了基本问题：如何在不「杀死」节点的情况下存储丰富的订单和交易历史。 答案是——不试图让验证者同时成为交易引擎和档案分析数据库。 当前的订单簿和头寸存活在链状状态中； 其余的则在事件、索引器和专用API节点中，这些节点可以根据任何使用场景进行扩展和配置。 这种方法使订单簿-L1在交易量和市场数量爆炸性增长的情况下仍然可行。
