交易所钱包系统开发 #1 - 系统设计

  • Tiny熊
  • 发布于 12小时前
  • 阅读 75

前不久,我写了一篇设计稳定币系统的文章,有很多朋友和交流一些细节,我发现很多同学想详细了解托管类系统,如何处理资金安全问题。从这篇文章开始,将以交易所为例,设计和实现一个安全且极简的加密货币托管系统,以便大家在实现类似系统的时候有一个参考。因为管理资金的是钱包,托管系统有时也叫交易所钱包系统。交

前不久,我写了一篇设计稳定币系统的文章,有很多朋友和交流一些细节,我发现很多同学想详细了解托管类系统,如何处理资金安全问题。

从这篇文章开始,将以交易所为例,设计和实现一个安全且极简的加密货币托管系统,以便大家在实现类似系统的时候有一个参考。因为管理资金的是钱包,托管系统有时也叫交易所钱包系统。

交易所钱包,在用户层面看到的主要功能有:

  1. 为每一个用户生成各个链的地址,以便用户向交易所充值
  2. 在数据库中,根据用户充值,记录用户各种资产余额
  3. 用户可以将其在交易所的资金提现到自己的钱包

初步设计

我们在后端应该需要两个模块:

  • 充值服务(Deposit Service):用来不断的监听区块链网络的上的交易,确认用户充值。
  • 提现服务(Withdrawal Service):将用户的提现请求打包并签名,广播到区块链。

再加个一个业务接口和数据库,业务模型大概如下设计:

image-20250903173323546

充值时,用户先从业务接口获取到分配给用户的账号,然后用户给账号充值,充值的交易在区块链网络上确认, 通过我们的充值服务不断的监听用户的充值交易, 并记录到数据库中。

image-20250903173710945

提现时,用户向业务接口发起提现,提现请求发行给提现服务,然后发起一个向用户的转账,在转账交易在区块链网络确认后,用户收到对应的资金,同时更新用户的余额。

这个设计很直观,但是还有一些安全问题需要我们考虑,例如: 为用户生成的账号对应私钥直接保存在数据库中,如果被黑客入侵到数据库,所有的资金都会被盗取。

为了应对这个安全问题,通常会做两个措施:

  1. 用户的私钥会独立保存在一台不连外网的机器中(或者采用云服务的 HSM - 硬件安全模块), 减少被入侵的风险
  2. 用户充值的资金,超过一定额度之前,转移到更安全的钱包,例如更高安全管理的账号,或者多人管理的钱包(多签名钱包),这样即便用户的私钥被盗,也可以降低损失。

设计二: 加入签名机及资金调度

独立的保存用户私钥的机器,通常成为签名机,除了持有私钥之外,还需在用户资金的归集时进行签名,另外,我还需要一个资金调度服务(Fund Management):负责在用户钱包和更高级别的钱包之间自动划转,这个通常会安排几个热钱包和多签钱包,资金调度服务既要保证热钱包流动性,同时降低集中资金的风险。

加入这些模块后, 设计是这样的:

image-20250903211228673

有了签名机之后,用户账号的生成,通常由业务接口调用签名机,为用户生成账号,然后存入到数据库中。

资金调度服务则监控各钱包的余额,并进行资金平衡,这里和稳定币系统中类似, 用户充值钱包多于一定资金时(例如 1000U) , 转移到热钱包(也称为资金归集),热钱包多于一定资金时 (例如 50 万U)转移到 T2 多签, T2 多签( 3/5 多签)多于一定资金时 (例如 300 万U)转移到 T1 多签。当资金不足时,有更高级别的钱包向低级别钱包转账。

这里关键的逻辑是资金分级管理, 越多的资金需要更多的人来管理, 避免单一人员的问题影响到所有的资金安全。

用户在提现时,提现服务将请求发送到热钱包签名机获取交易进行签名,然后将交易的签名广播到区块链网络。

但是还有一些安全问题,需要我们继续考虑,用户可能利用我们的系统来洗钱:用户充值充入了一笔黑钱,然后通过热钱包将自己提走。为了解决给个问题,我们要加入 KYC 和 风控模块。

KYC(Know Your Customer):通常在用户注册(或提现)时,要求用户填写相应的个人信息,通常要对用户人脸识别,并与身份 ID 资料比对, 有专门的 KYC 服务商,这里我们主要考虑风控模块。

设计三: 加入风控

风控模块,可以在用户充值时,检查用户充值的资金来源,如果资金来源from是被监管机构标记的黑地址(或者是内部管理的黑名单),那么该笔交易将不会为用户入账到余额数据库。

同时在用户提现时,风控模块检查用户提现目标地址被监管机构标记的地址(或者是内部管理的黑名单),则阻止用户的提现,如果是正常地址,通过风控后,继续请求热钱包进行签名。

加入风控模块后,设计如下:

image-20250904171556525

用户充值后,经过风控模块的确认,在风控模块确认后,才写入数据库,如果是提现,风控模块确认后,再请求热钱包的签名,提现服务拿到签名后广播交易,将资金发送给用户。

但是还有另一个问题, 如果充值的数据和提现的请求被内部人员或者或者黑客篡改,依旧很难防范,因此通常风控模块会作为一个独立的系统运行。其会独立验证用户的充值交易, 在提现时,要求业务端对完整的数据签名,在风控系统验证后,再次签名确认,发送给签名机验证,做最后的交易签名。

设计四: 独立的风控系统

风控系统独立后,系统设计图大概是这样的:

e93ec5d9-b490-4f89-b3ed-6de6dd9cb1fe

这个差不多就是最终的形态了,每个模块有自己的清晰的角色和任务,只能在职责范围内工作, 例如充值服务服务直接向数据库写入用户余额,提现服务需要经过风控才能请求到对用户的转账签名。

可以在这个设计框架下,可以根据自己的需要做相应调整,例如:多签钱包可以根据需要设置更多的级别。

签名机可以使用 CloadHSM 、 KMS + Tee (密钥管理 + 可信执行环境)、或者 MPC 多方安全计算方案,提升安全性,这些方案也会额外增加运营的成本,大家可综合考虑。

另外,通常为了安全,所有的用户及后端的操作均保留所有的日志,以便追溯。

点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ,好文好收益,欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
Tiny熊
Tiny熊
0xD682...E8AB
登链社区发起人 通过区块链技术让世界变得更好而尽一份力。