MATRIX：从数字资产行情工具到链上风险基础设施

MATRIX 开始于一个看似清晰的入口：怎样把分散、快速变化的数字资产数据，变成普通用户可以理解和使用的分析工具。随着研究深入，团队发现行情展示只是表层问题，真正困难的是数据获取、策略表达、链上实体识别，以及长期运行所需的基础设施。

这使项目逐渐形成两条相互关联的产品线：一条面向投资分析，以行情、策略和信息服务为核心；另一条面向机构风控，尝试从公开链数据中识别地址关系、追踪资金流并提供风险预警。

从行情查看走向策略工具

第一条产品线围绕数字资产行情展开。早期版本先解决搜索、自选、币对详情、K 线指标和交互一致性等基础体验，随后逐步加入智能选币、策略回放、模拟交易、币价预警、市场情绪、快讯资讯、资产管理和事件日历。

从留存的产品记录看，这不是一次性完成的功能堆叠，而是一系列连续迭代：团队不断修正报价精度、指标展示、交易对规范和页面导航等细节，同时探索如何让用户定义自己的量化策略。项目后期的重心也由“展示更多数据”转向“帮助用户形成判断”。

风控需要先理解链上世界

第二条产品线关注数字货币风险。区块链账本虽然公开，却不直接告诉分析者一个地址属于谁、多个地址是否由同一实体控制，或者一笔资金最终流向了哪里。

团队因此把问题拆成四层：

1. 运行全节点并提取区块、交易、输入、输出和地址数据；
2. 建立适合增量同步与查询的数据模型；
3. 通过地址聚类、标签和外部线索，把地址映射为钱包或实体；
4. 在图结构上实现资金流追踪、异常预警、反洗钱分析和可视化报告。

方案中曾评估 PostgreSQL、MongoDB 和 Neo4j 等不同存储形态。关系型或文档型数据库负责承载原始数据与业务查询，图数据库则用于表达地址、钱包、实体和交易之间的复杂关系。这个分工反映出一个重要认识：链上风控并不是简单的区块浏览器，而是一个持续积累标签、关系和风险判断的知识系统。

浏览器方案先把账本拆成可计算对象

技术文档逐字段设计了区块、交易、输入、输出和地址模型。区块保存哈希、高度、前块、默克尔根、难度和主链状态；交易保存交易标识、锁定时间、所在区块和输入输出数量；输入通过前序交易与输出序号指回资金来源；输出保存脚本、金额、地址、是否已花费和下一笔消费交易。

这个模型的核心是 UTXO 关系。地址余额不是账本中的一个可直接更新字段，而是所有未花费输出的派生结果；资金追踪则沿“输出—下一笔输入”继续遍历。资料提出三种摄取路线：直接解析无序区块文件、使用有序块数据，或通过节点 RPC 按高度增量拉取。增量方案比较节点最新高度与本地已同步高度，再补齐缺口。

下面是依据数据模型文档整理的等价伪代码，用于说明增量同步如何把前序输出连接到新输入。当前没有对应代码仓库，所以它不构成历史实现证据：

def sync_chain(node, store):
    start = store.last_height() + 1
    for height in range(start, node.latest_height() + 1):
        block = node.block_at(height)
        for tx in block.transactions:
            store.save_transaction(block.hash, tx)
            for tx_input in tx.inputs:
                previous = store.output(tx_input.previous_tx, tx_input.index)
                store.link_spend(previous.id, tx.id)
                store.mark_spent(previous.id, tx.id)
            for index, tx_output in enumerate(tx.outputs):
                store.save_output(tx.id, index, tx_output)
                store.link_addresses(tx.id, tx_output.addresses)
        store.commit_height(height, block.hash)

风控层在基础账本上继续构造“地址—钱包—实体”三层对象。地址聚类需要识别找零地址和共同控制关系；实体标签覆盖交易服务、矿池、博彩、个人等类别，并计划结合公开痕迹与投诉记录形成风险信号。这些是文档确认的分析路线，不等于代码已实现：当前实例没有对应仓库，也没有精度评测或标注集。

数据规模推动基础设施升级

留存方案估算，两条产品线当时已有约 1.6 TB 数据，并需要持续接收行情、媒体、项目资料和公链节点数据。团队比较了托管服务器、云数据库、新购云主机与本地设备等方案，并在成本、扩容、备份、容灾、带宽和混部风险之间进行权衡。

最终建议优先利用已有托管资源，这能控制早期成本，但文档也明确指出了单机、缺少自动备份和服务混部的风险。这是典型的探索期决策：先用现有资源验证产品方向，同时把可靠性债务记录下来，而不是假装它不存在。

容量表进一步把约 700 GB 行情及媒体数据、约 900 GB 公链数据和额外全节点空间分开估算，并比较已有托管机、云数据库升级、新购云主机与内网设备。选择维度包括一次性成本、年度费用、最大容量、带宽、自动备份、扩容和混部风险。因此“复用已有机器”是预算选择，不是可靠性已经解决。

Data Lake 调研则把消息流与采集组件放在摄取层，分布式文件系统保存原始数据，Spark 承担分析计算，MongoDB 与 PostgreSQL 向应用提供结果，交互式笔记工具服务探索。材料能证明团队形成了计算、存储与服务分离的目标架构，不能证明整套组件实际落地。

从单项产品延伸到 BaaS

在项目后期，团队还提出基于 Hyperledger Fabric 的 BaaS 平台规划，希望把联盟链部署、租户管理、资源隔离、智能合约、监控和运维封装为平台能力。

规划采用基础服务、业务服务和应用三层结构，并设想通过容器、Kubernetes、镜像仓库和自动化脚本实现一键部署。其目标不是再造一条链，而是降低业务团队创建和维护区块链应用的门槛。不过，现有材料更能证明需求设计和技术规划，尚不足以证明这些能力全部形成了稳定的生产平台。

第一阶段边界写得较具体：以联盟链框架为底座，优先完成源码构建、节点与账本存储、容器镜像、一键初始化、链码部署、租户注册、资源模板、基础设施监控和阈值告警。可插拔共识、智能合约语法与安全检查、镜像市场和深度持续交付被放到后续。把这些优先级放回时间线可以看出，2019 年中后期的大量成果属于可行性与技术边界，而不是全功能平台已交付。

账本调研还区分区块账本、世界状态、历史索引和读写集：背书节点先模拟交易得到读写集，提交阶段再经过背书策略与版本冲突检查。状态存储分别评估只支持键查询与支持富查询的方案，认证数据则计划放在关系数据库。真正可复用的是按查询语义区分不可变账本、当前状态、历史索引和平台账户。

项目留下的经验

MATRIX 最有价值的地方，是把一个前台行情产品逐步拆解为数据、算法、风控与基础设施问题。

• 可视化只是数据产品的最后一公里，稳定的数据采集、统一口径和增量处理决定了上层体验。
• 地址聚类与实体标签是链上风控的核心资产，单纯保存交易记录并不能产生风险判断。
• 在探索期复用现有基础设施可以提高验证速度，但备份、容灾和隔离必须被明确列为后续成本。
• 平台化规划应与已验证的业务需求同步推进，否则宏大的能力清单很容易超过团队当时的交付边界。
• 链上追踪应保存图构建规则与标签证据；地址聚类只能作为概率判断。
• BaaS 验收必须逐项验证租户隔离、通道、证书、链码生命周期、资源回收和灾难演练。

证据边界

现有资料覆盖 2018 年 9 月至 2019 年 8 月。Jira 中共有 324 条相关工单，全部处于完成状态；任务高峰集中在 2018 年 12 月和 2019 年 4 月。Confluence 保存了 103 篇相关页面，包含产品版本、调研、数据架构、部署和 BaaS 需求。

当前 GitLab 实例中尚未找到明确对应 MATRIX 的代码仓库，也没有足够材料验证用户规模、收入、准确率或长期运行情况。因此，本文把它定义为一段有连续交付记录的产品与技术探索，而不把规划内容等同于最终上线成果。