如何设计一个安全的稳定币系统

引言

最近稳定币受到了很多的关注，今天在线下集训营的课后讨论多签时，聊到了稳定币资金管理，其实两年多前我们和 HK 老牌金融机构合作上线了一套稳定币系统（首期已经发行了千万美金），奈何当时的监管压力，机构怕影响自己牌照，下线了。

2 月份 Bybit 15 亿美金从多签合约中被盗，暴露了bybit 多签管理的很多问题，我们当时在设计稳定币多签管理时，有很多考虑，应该说很多地方还是比较先进的，这篇文章将介绍一下设计方案，供大家做类似系统时一个参考。

稳定币运行逻辑

先简述一下稳定币的运行逻辑， 稳定币是一种锚定法币（通常为美元）的数字货币， 为了描述简单，我们假定是一个名为 USTX 的 ERC 代币。大体的运行逻辑是这样的：

当用户存入 $10000 到发行方指定的托管银行，在链上发行对应的 10000 USTX （这里不考虑手续费）， 用户可以使用 USTX 购买其他数字资产，也可以用户跨境支付。当用户需要赎回美元时，将 USTX 代币转给发行方，发行方销毁代币（减少发行量），将美元转给用户。

然而，如果每次收到用户存款之后，都触发发行，会有很大的安全问题。因为如果处理发行逻辑的服务期被黑客攻击，可能会凭空增发大量的 USTX。

分级资金管理

以下是稍作简化后的方案：

管理 USTX 代币的账户是分级的：T1 账户、T2 账户、热钱包

T1账户 5/9 多签账户 ：最高权限，具有发行 USTX 的权限，实际在系统中， 5/9 多签将扩展为 6/10 多签，加入了机器人验证交易。

备注 m/n 多签钱包： 只有 n 个权限持有者中的 m 个签名才会真实触发交易。

T2 账户 3/5 多签 ：持有不超过 200 万 USTX， 作为 T1 和热钱包之间的缓冲层。T2 从 T1 接收资金，向热钱包补充流动性，当热钱包余额超过阈值时，也会转入到 T2 。 实际在系统中， 3/5多签将扩展为 4/6 多签。

热钱包：为了保持高可用性，要实时负责用户申购和赎回，如果私钥在公网可以访问服务上，会有很大的安全隐患，热钱包持有USTX不能超过 50 万 ， 超过时，将自动转移一半余额到 T2 账户。 热钱包使用了内网签名机方案（热钱包私钥使用 AWS 的 KMS 应该也可以）。

USTX 的资金管理，可以用下图表示：

其实分级权限管理，是托管类系统的默认的方式了。

后端及热钱包设计方案

热钱包负责用户申购和赎回，用户申购通常是这样的：

用户在注册完成 KYC 后， 申购动作会发送到后台记录到数据库，并获取一个单号，用户汇款时备注单号，以便后台获知是哪个申购单完成了汇款（海外的支付网络不像国内微信支付和支付宝这么方便，尤其是大额支付，因此汇款是主要方式）。这是后台服务会请求内网的签名机签署一个给用户的转账签名，后台拿到签名之后，调用 USTX 合约将 Token 转给用户。

签名机是在内网隔离的，用户是请求不到签名机的，签名机只接收来自后台服务内网请求的 USTX 的转账签名，在防火墙上会过滤掉其他的请求，签名机在启动时，会加载用复杂密码保护的私钥keystore，密码采用权限人员手动输入，并且只存在于内存中，防止黑客进入扫描磁盘泄露密钥的风险。

用户赎回则通过 USTX 的前端， 将资金转入到热钱包的地址，链监控服务通过日志监控到转账完成后，通知后台服务将美金转给用户。

多签钱包管理

Bybit 被盗主要原因是多签服务商 Safe Wallet 的前端被攻击了，误导了签名者。

我们当时设计了自己的多签管理后台界面，其实当时设计自己管理后台的原因是，老牌金融机构大佬们并不熟悉 Web3 ，他们觉得 Safe Wallet 的页面“看不懂”， 因此我们用 Safe SDK 定制了多签管理页面，同时在管理页面中包含了一些 USTX 的运营数据。

事后来看，设计自己内部使用的多签管理后台界面，也减少了攻击面，不过这套设计的关键特色是是在多签账户中多加入了一个签名 Bot 程序。T1 账户 5/9 多签将扩展为 6/10 多签， T2 账户 3/5 多签将扩展为 4/6 多签。

使用过多签的朋友都知道，在签名时，很多交易人工基本没法看懂的，例如下面是一个多签的签名确认：

而且由用户发起交易转账，也经常会担心交易地址填错了。

在我们的设计中，所有多签交易都由签名 Bot 程序来发起，而且在签名 Bot 的代码中限制了只能和白名单的几个地址交互（T1 账户 、T2 账户 、热钱包地址等）， 只要签名 Bot 代码经过严格测试，签名 Bot 发起的提案肯定要比人工提案的错误率低很多。多签的持有者只需要负责做二次确认签名。

每个签名 Bot 也有对应的签名机，运行在内网隔离的环境下，T1 T2多签合约间划拨资金时，运行逻辑是这样的：

链监控服务除了前面监听用户转账赎回美金的交易之外，也同时会监听热钱包和 T2 账户的余额，当T2 账户余额不足时，会通知 T1 Bot 程序，发起一个给 T2 账户的转账，并通知相应的多签持有人再次确认。多签持有人进入到多签管理后台界面时，会看到待签名的交易，后台界面也会对交易做相应的解析，转账的目标地址有标签标注，如果不是白名单地址，会显著提醒，比起在 Safe 前端中，识别交易要容易的多。

其他可改进点

总体的方案就是这样，这个设计方案其实可以应用在大多数的托管系统中，大家可以根据自己的需要做一些改进。

一些可能的改进点，包括：

1. Bot 程序也可以用来做多签交易的验证，人工肉眼识别交易很麻烦，而用 Bot 程序来解析交易就相对简单，其他多签持有人可以等待 Bot 程序确认后，再做二次确认。
2. 签名机修改使用 云服务的密钥管理方案 KMS
3. 分级管理，可以根据自己的需要增加层级，其实在真实的系统中，设置了 4 级。
4. 不同的多签持有人，使用不用的多签前端托管方案来进行签名，避免前端单点攻击，除 https://safe.global/wallet 官网在，还有 https://eternalsafe.vercel.app/welcome/ 和 https://eternalsafe.eth.limo/welcome/ 可用。

其他的改进点大家留言讨论。