问题域
数字资产平台既有金融系统对正确性的要求，又多了一项传统金融没有的约束：公有区块链上的交易通常不可逆，掌握私钥就等于掌握资金。一笔错误的或恶意的提现，无法由对手方银行撤回。因此工程从密钥托管和交易授权出发，其他一切都围绕保护它们来安排。
第二个决定性的问题是，区块链是平台无法控制的外部系统。节点会落后，也会彼此不一致。区块会被重组，一笔看似已确认的交易可能消失。手续费剧烈波动，已提交的交易可能数小时得不到确认。每个网络都有自己的账户模型、最终性行为和代币规范。平台必须消化这一切，同时向用户和财务团队呈现一幅一致的内部图景。
本页仅描述工程内容。Starone 不提供投资建议，不对任何资产的价值或前景作出表述，也不声称持有牌照或获得监管批准。平台的设计用于支持运营方所需的各项控制措施。运营方适用哪一套监管制度，应由运营方及其法律顾问判断。
难在哪里
工程挑战
私钥泄露
保存在应用内存或配置存储中的密钥，任何攻破该主机的人都能提取，损失即时发生且无法挽回。拥有宽泛签名权限的单密钥热钱包，是大额损失最常见的根源。密钥材料必须隔离在硬件中或拆分给多方，签名则由策略管控。
链重组与最终性
充值一出现在区块中就入账，会让平台暴露于链重组的风险：用户已经交易或提现之后，这笔充值被重组移除。各网络的最终性各不相同：有的是概率性的，有的有明确的最终性检查点。确认策略必须按链设定，在达到阈值之前，充值在内部必须可以撤销。
卡住或重复的提现
已广播的交易可能被丢弃、出价过低或被替换。草率地重新提交可能导致资金发送两次；在账户模型的链上，nonce 管理不当会阻塞同一地址之后的所有交易。提现流水线需要显式的 nonce 管理、手续费加价规则，并保证一个请求只对应一笔链上转账。
链上账本与内部账本逐渐偏离
内部账本记录每位客户拥有什么；链上记录平台地址持有什么。漏记的充值、未入账的手续费和失败的归集，都会让两者出现差异。如果没有持续对账，资金缺口可能存在数周才被人发现。
节点与服务商的可靠性
单个节点或单家 RPC 服务商，既是单点故障，也是一个可能出错的单一事实来源。落后的节点报告过期的余额；有故障的节点可能报告规范链上并不存在的交易。关键读取需要不止一个独立来源，以及发现它们之间不一致的手段。
高负载下撮合引擎的正确性
交易所必须以严格、可重现的顺序处理订单。并发缺陷会造成成交价格错误或余额变为负数，崩溃后的恢复必须还原出完全相同的订单簿。吞吐量不能以牺牲确定性为代价来换取。
我们如何构建
架构
平台把密钥托管与签名同所有其他服务分离，以内部复式记账账本作为客户资产归属的记录，并把每条区块链视为通过冗余节点观测的外部系统。
- 01
密钥管理与签名服务
私钥在硬件安全模块（HSM）中生成并保管，或通过多方计算（MPC）拆分，因此没有任何一台机器或一个人持有完整的密钥。签名服务只接受结构化、经过校验的请求，并且只对极少数内部调用方开放。运营人员的访问需要多人批准并留有记录。
- 02
钱包分层与策略引擎
资金分布在热、温、冷三层，只有近期提现所需的额度保持在线。策略引擎依据金额限制、频率限制、目标地址白名单、时间锁和所需审批人数等规则，评估每一个签名请求。策略是有版本的配置，对策略的修改要经过它自己的审批流程。
- 03
充值检测流水线
链索引器通过多个节点跟踪每个受支持的网络，提取转入平台地址的转账并跟踪确认数。充值依据按链设定的确认策略，依次经过待确认与已确认状态，只有满足该策略后才计入内部账本。索引器处理链重组的方式，是回滚到分叉点并重新处理。
- 04
提现流水线
提现请求先通过风险检查，在账本中预留资金，然后进入队列。交易构建器分配 nonce 或选择输入，估算手续费，并在网络允许时合并多笔转账。签名并广播之后，流水线跟踪交易直至最终确认，在交易卡住时应用替换规则，并依据结果结清或释放账本中的预留。
- 05
内部账本与交易所核心
客户余额保存在只追加的复式记账账本中，独立于链上地址，因此内部转账和交易的结算无需触及区块链。当交易功能在范围之内时，由单线程的确定性撮合引擎处理保存在内存中的有序订单流，每一个输入都写入日志，订单簿因此可以通过重放重建。行情数据和结算结果以事件形式发布。
- 06
链上监控与交易风险
监控服务监视平台地址、合约事件和待确认交易中的异常变动，并实时告警。转入和转出的转账通过区块链分析服务商进行筛查，识别与受制裁地址或高风险地址的关联，不确定的结果转交人工审核。检测到异常时，自动化控制可以暂停某一资产或整个平台的提现。
- 07
资金管理与对账
定时任务按资产把账本上的负债与各层的链上持仓进行比对，并报告任何差异。资金管理工具负责充值地址的归集、经审批的各层之间再平衡，以及手续费资产的管理，使提现不会因为缺少 gas 而受阻。每一笔资金调拨都记入账本，并纳入对账。
应用与 API
- 客户端应用
- API 网关
- 合作方 API
- 运营控制台
钱包与交易
- 地址管理
- 交易构建器
- Nonce 与手续费控制
- 策略引擎
密钥管理
密钥绝不离开签名边界
- HSM
- MPC 签名
- 多人审批门限
- 密钥轮换
节点 / RPC 层
- 全节点
- RPC 服务商
- 故障切换路由
- Mempool 访问
索引与分析
链上数据在最终确认前都是暂定的
- 区块摄取
- 事件解码
- 重组处理
- 查询 API
监控与合规
- 交易监控
- 地址筛查
- 审计轨迹
- 告警
一次合作交付什么
- 托管架构与密钥仪式流程
- 带策略引擎与审批工作流的签名服务
- 面向约定网络的充值与提现流水线
- 内部账本，以及在范围内时的撮合引擎
- 链上监控、筛查集成与告警
- 对账与资金运营工具
- 威胁模型与事故处置手册，包括暂停提现的流程
开始之前
需要尽早做出的决策
- HSM、MPC，还是多重签名托管
- 硬件安全模块的原理为业界所熟知，适合配有严格物理管控的集中式签名。多方计算消除了单一的完整密钥，无需链上改动即可跨链使用，代价是协议和运维更为复杂。链上多重签名透明且易于审计，但与具体的链绑定，并且对外部观察者可见。许多设计会按钱包层级把它们组合使用。
- 自建节点，还是使用服务商
- 节点服务商免去了运维负担，在起步阶段对大多数网络而言是合理的选择。对于承载价值或交易量最大的网络，或者需要 trace 数据和归档数据的场合，应自行运行节点。关键读取至少使用两个独立来源，并比对它们的结果。
- 自建托管，还是接入托管机构
- 接入成熟的托管服务商可以缩短交付周期，并转移一部分运营风险，代价是支付费用，并依赖其产品路线图和所支持的资产。自建可以在规模化之后掌握策略和成本，但需要花时间建立安全工程能力和运营成熟度。这一决定往往取决于运营方所在司法管辖区的监管预期。
- 多少个确认后入账
- 按网络设定，依据其最终性模型和所涉风险金额。具有确定性最终性的链可以在最终确认时入账；概率性最终性的链则需要一个足够的深度，使得就所涉金额而言，重组在经济上不具可行性。金额较大的充值可以合理地等待更久，而且这项策略应当是配置项，在网络不稳定时可以迅速收紧。
常见问题
常见问题
Starone 是否提供托管服务或运营交易所？
不提供，也不运营。Starone 负责的是技术工程。托管和交易所的运营由客户依据适用于其自身的牌照和批准开展。我们不就自身、也不就我们设计的系统声称具有任何监管地位。
可以支持哪些区块链？
架构把每个网络隔离在一个链适配器之后，适配器涵盖地址生成、交易构建、手续费估算和确认跟踪。账户模型的链和 UTXO 模型的链都适用这一设计。具体支持哪些网络按项目约定，因为每增加一个网络都意味着额外的集成、测试和运维工作。
系统如何防范内部人员威胁？
确保没有任何个人能够独自转移资金。签名需要多方的策略审批，密钥分片或 HSM 凭证按角色分开保管，管理操作以不可篡改的方式记录，策略变更也需要达到其自身的法定审批人数。监控的设计是向审批群体之外的人员告警。
你们编写和审计智能合约吗？
当设计需要时，我们开发并测试智能合约，使用成熟的库、基于属性的测试和静态分析。对于承载价值的合约，我们建议在部署前进行独立的外部审计。审计可以降低风险，但不能消除风险。