9 篇博文 含有标签「项目」

一开始，我们重构了 clear-lyquid 和 match-lyquid，现在它们都通过一个 Lyquor 实例作为入口来调用。所有状态都已经转换为实例级状态。整体思路是，多个实例先为一笔交易发起某种本地共识，然后再把结果提交到链上。

3 月 27 日，我们在工程、基础设施和内容运营几个方向上，对齐了一些实际推进事项。

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

很多时候，一提到交易系统，大家首先想到的都是性能，比如撮合速度、延迟和吞吐量。这些当然很重要，但这次内部讨论让我感觉，真正值得反复琢磨的，未必只有“快”这一件事。

这次 3 月 22 日的周会，讨论的内容比平时更发散一些，但回头看，其实主线很清楚。一条主线是技术上怎么把系统做得更稳定、更适合演示，也更接近可落地的交易基础设施；另一条主线则是，如果项目继续往前推进，应该以什么样的产品定位、公开方式和创业节奏去展开。

3 月 9 日的讨论把项目推向了一个更统一的架构方向。团队不再继续以“多个 Lyquid 实例分别承担预设职责”的方式思考，而是对齐到一个单 Lyquid 设计：同一个 Lyquid 可以承载多个角色，并共享同一份底层状态。这个变化很重要，因为它会同时影响技术实现路径，以及撮合、指数价格等不同功能应该如何共存。

这张图对应的是 2 月 27 日讨论过的架构概念。可以参考之前的文章：02-27 合约测试与架构取舍。

2 月 27 日的讨论把项目中通常很难同时对齐的三层问题放在了一起：合约执行、日常交付节奏，以及更长期的系统架构。结果是，团队对哪些内容已经验证、哪些执行环节正在拖慢进度、哪些架构问题还需要更清晰的答案，有了更接地气的判断。

2 月 22 日的讨论把项目推进路径收敛到一个更实际的迁移顺序：先在接近真实的环境中验证当前系统，再在不破坏现有运行模式的前提下，逐个服务向 Lyquid 迁移。重点不是做一次大的架构重写，而是先建立基准、保留可比性，并在每一层适配过程中逐步降低不确定性。

项目今天正式启动，我们开始探索一种实现 DEX 的新路径。