中心化交易所：钱包系统设计——以太坊

矿工费：是发起转账的手续费，手续费等于Gas Limit * Gwei

ERC20代币：ERC20是ETH的代币（例如：黄金有纯金、开金、千纯金等不同标准。），ERC20转账和ETH转账手续费一般不同，ETH转账会更便宜，并且代币转账的手续费是ETH，不是代币。

区块确认：以太坊区块确认一般通过12个区块确认完成。 事实上，在大多数场景下，1 个区块确认就足够了。

确认状态：转账确认状态包括“等待处理”、“处理中”、“失败”和“确认中”。

Nonce：可以理解为一个ID。 Nonce 在钱包发起转账时设置。 以太坊转账需要严格按照顺序进行转账。 如果当前的Nonce为1，下次转账的Nonce设置为3是不可能转账成功的。 必须发起一个Nonce如果为2且转账完成，则Nonce为3的转账将继续，否则Nonce为3的转账将处于等待状态。

Nonce覆盖方法：

overlay方式，钱包中有一笔转账需要区块确认。 如果再发起一次转账，后一次转账会覆盖前一次转账，即与Nonce相同，后一次转账会覆盖前一次。 这种方式一般用在像imtoken这样的以太坊钱包中。 这种方式的好处是，用户发起转账后，由于各种原因导致网络受阻，希望取消转账，重新增加邮费。 增加邮费，再转一笔来补上一笔，就不会出现重复转账的问题。

Nonce 阻塞方法：

阻塞方式在钱包中发起多次转账，Nonce依次发送到网络等待打包，等待上一个Nonce完成自动执行下一个。 这种方式一般用于去中心化交易所。 在去中心化交易中，由于用户的代币在自己的钱包里，撮合完成后代币会自动转给庄家。 所以这里如果使用overlay的方式，是无法完成的。 多笔撮合，在多笔交易撮合时，应该会导致前一笔覆盖下一笔，因此阻塞方式多用于去中心化交易所。 阻塞方式是在发起转账时获取以太网络中最新的Nonce和本地钱包队列数进行比对+1处理。

例如：首先以太坊钱包提币到交易所，该地址最新区块收到的转账Nonce为5，第二个本地钱包有2条记录等待转账（即两个账户已经发起，还没有转账），然后另一个传输启动。 那么这次转账的Nonce应该是5+2+1=8

这里也有隐藏的坑：

这种方式往往会造成跳过Nonce的问题。 如果8号跳到9号，如果不加8号号，9号的转账会一直在那里排队，不能转账，也不能取消。 好的，这是什么原因？ 原因是本地节点同步不够及时，通知队列数异常。 用上面的例子，有2条记录在排队，其中一条已经被区块确认，但是节点没有及时同步，那么此时发起转账以太坊钱包提币到交易所，正确的Nonce应该是6+1+1= 8、错误的Nonce Nonce case 6+2+1=9。 因为原网最新的Nonce是5，队列里有2个，其中一个已经被确认，那么区块最新的Nonce是6，队列里有1个。 但是，节点同步存在问题。 钱包获取到的区块最新的Nonce为6，但是节点没有及时同步队列中的确认数，仍然返回2给钱包，就会出现Nonce跳转问题。

中心化交易所ETH提现方式建议：

在中心化交易所中，热钱包的提现和转账是一个非常高频的操作。 肯定不能使用Nonce覆盖的方式，也不能使用Nonce阻塞的方式。 应该是因为阻塞方法跳转Nonce的问题。 多转问题。 集中方式推荐使用本地队列的方式，在本地记录要提取的记录条数，不要将记录发送到外网。 获取区块的最新确认Nonce，发送下一笔转账，收到成功确认记录后发送下一条记录。

（注意：只能单点操作，多点操作会造成Nonce跳变问题）

（问题又来了，那为什么上面说的去中心化交易做不到呢？应该是因为很多去中心化交易都是钱包和交易共享的，交易也可以进行转账，如果使用本地队列，那么转账就是同为交易同时存在时如何处理？只能通过阻塞Nonce来中和。当然最好的办法是不提供转账功能，只提供交易。我没有想到暂时完美解决，去中心化交易所的坑还是很多的）

收款需要将矿工费输入用户地址：

别忘了，以太坊的代币转账是扣除以太币作为gas费的，那么交易所分配给用户充值的地址是不是也得准备一些以太币给用户的地址存放用来收款呢？ 答：是和不是，当然有条件。 注册用户分配的每个地址不可能都给以太坊充值。 成本太高，需要过滤垃圾账户，只有有充值资金的账户才用于gas支付。 资金的收取取决于每个交易所项目的产品经理如何设计。 这里没有对错之分。 下面简单介绍一下我们的初步设计方案。

I 交易所钱包组成结构

图片

数字货币兑换钱包的结构分为冷钱包、热钱包和账户钱包。 一般冷热钱包设计有多个热钱包A、热钱包B、热钱包C、冷钱包A、冷钱包B、冷钱包C等，冷热钱包的设计数量需要根据自己的业务规模不断。

账户钱包：每个注册用户分配一个单独的充值地址。 每个注册用户在交易所的充值地址都是不同的。 每个注册用户都会被分配一个地址，所有用户的地址和私钥都由交易所统一保管。

热钱包：热钱包可以理解为常用的钱包。 一般交易所用户提现，资金通过交易所热钱包转账。

冷钱包：由于经常使用热钱包，签名时经常需要私钥，所以有一定的安全性。 如果所有资金都存放在热钱包中，对于交易所来说是非常不安全的。 万一资金被交易所盗走即将倒闭。 因此，大部分不经常使用的资金一般都存放在离线冷钱包中。

业务流程：上面的大致业务流程已经很清楚了。 用户向交易所分配的账户地址充值代币，交易所监控账户地址的资金变动。 如果资金转入，同步数据将添加到用户账户中。 余额记录。 （注意账户地址只监听转账结果）。 当然，每个用户都分配了不同的地址，如果所有的钱都放在地址里，就会出现“资金分散”的问题，难以管理。 因此，在监控地址转入后，交易所需要将该地址内的资金汇入交易所官方热钱包进行集中管理。 由于经常使用的资金不能过于集中在热钱包中，部分不可动用的资金会存放在安全的冷钱包中。

图片

上图是一个比较完整的钱包业务流程图，涉及到：生成用户充值地址、监控充值入口代币、资金归集、收取的矿工费划转、热钱包资金分配到冷钱包、提现转账。

生成用户地址：

当账户注册完成后，需要创建相应的钱包信息，并为账户分配充值地址。 充值地址暴露给用户，私钥由系统保存用于收款。

图片

之前写过一篇关于以太坊钱包的文章，大家可以看看

监控充值代币：

第二步，用户充值时，我们需要监控进入钱包的区块确认数，一般设计为12个区块，okex设计为1个区块，Binance设计为24个区块。 我们将 Binance 定义为完成 24 个区块确认后充值成功。 当充值成功完成后，需要判断进入账户的token类型。 如果系统中存在所输入代币的合约地址，则对应的代币余额将添加到账户余额中。

图片

基金征收：

图片

判断代币：在收款之前，首先要判断代币类型是ETH还是代币。 如果是ETH，则判断地址中的资金是否大于0.1ETH。 因此，对于低于0.1ETH的地址，可能不会先触发池化状态，如果大于0.1ETH，则直接入池。 如果是token，需要先判断地址中是否有足够的ETH作为矿工费，将推荐的矿工费与当前地址的ETH余额进行比较，如果足够则直接收取.

判断网络状态：由于以太坊网络经常处于拥塞状态，出现拥塞状态时转账成本会非常高，也不一定能成功。 以太坊网络推荐邮费大于100Gwei时，比较拥堵。 在这种状态下，我们没有必要增加收款成本，选择等待。 收取前需要对推荐矿工费进行判断，避免资源浪费。

转账矿工费：如果代币收款地址中的ETH不足以支付转账手续费，需要记录缺少邮费的地址，使用智能合约在次日10:00分批转账0.01EHT矿工费早上募集资金。

（为什么是早上10:00？/方便技术在早上监控，防止出现异常问题导致多轮转。）

（为什么要转0.01ETH？/鉴于以往经验，矿工费最高一般为0.00X，所以转0.01ETH比较合理，多出的余额可以用于下次收款。）

（为什么要用智能合约去中心化转账？/因为智能合约可以大大降低矿工费，降低成本。）

图片

资金配置：资金存储比例设计为冷钱包存储80%，热钱包存储20%。 对于目前数字货币钱包的使用门槛，大部分玩家的资金几乎都存放在交易所，热钱包20%的流动性就足以支撑用户的提现需求。

资金转移：何时转移资金？ 这个问题要看你自己的业务量。 我们计划每周分配一次资金，每周一下午2:00进行资金划拨。 转账前需要清点有效资金，因为空投币经常出现在数字货币钱包中，分配垃圾空投币是没有用的，所以需要筛选钱包中的有效币种进行转账。 有效代币为 平台提供充提币合约。 筛选总资产计算的代币“热钱包地址资金/（热钱包资金+冷钱包资金）%”

特殊处理：并不是说热钱包里的资金一定要大于20%。 当然会出现集中提现，导致资金不足20%。 这时候就需要向热钱包注入资金。 注入资金应从冷钱包或其他渠道注入。 如果使用系统自动注入，需要将私钥放入系统，非常不安全，建议离线手动处理。

图片

这里所说的提币矿工费并不是平台向用户收取提币费用多少，而是提币转账需要设置多少手续费，方便转出。 答案是获取当前区块网络的推荐手续费，再加一点。 110% 效果最佳。

（结尾）

风控设计-暂时搁置