03-26 交易所 Feed 与实例化执行研究记录

3 月 26 日，我们主要讨论了两个相互关联的话题：不同交易所的 feed 模型在实践中有什么差异，以及 Lyquid 应该如何继续向实例化执行推进。

讨论的一部分集中在比较 Hyperliquid、OKX 和 Binance 的 feed 结构。一个有用的结论是，这种比较并不像一开始看起来那么直接。Hyperliquid 并不是简单地暴露“更少数据”。相反，很多字段被拆分到不同 subscription 中，使整体模型更像事件流，而不是一个打包好的单一推送格式。

这种差异很重要，因为它会改变下游系统对重建、完整性和时序的理解方式。一个分散在多个 subscription 中的 feed，和一个把更多状态聚合到单一 channel 中的 feed，即使总信息量相近，系统行为也会不同。

与此同时，我们继续讨论 Lyquid 向实例化执行迁移的问题。这里的实际问题已经不只是代码迁移本身，还包括如何组织同步、如何降低锁竞争，以及如何在不退回到过粗锁粒度的情况下，让多线程执行变得可行。

我们也重新讨论了共识和下游状态分发应该如何建模。关键问题之一不只是结果如何达成一致，而是执行完成后应该传播多少信息。尤其是只发送很小的 delta 式更新，不一定总是足够。在某些路径里，更完整的状态传递可能比最小 payload 更稳健。

综合来看，这些讨论指向同一个更大的主题：系统设计同时取决于外部数据模型和内部执行模型。更准确地理解交易所 feed，有助于反过来塑造 Lyquid 内部的执行、共识和下游状态处理方式。

我仍然有一个印象：Hyperliquid 推送的数据可能更少，但这一点还需要继续验证。