关于以太坊钱包的几个问题
分类： Web3 钱包
作者：小问
浏览：57
2025-08-21 06:47:04
- 当前项目充值的时候是直接把用户的金额加上去了，没有等到确认块数，如果按照之前讲的中心化交易所的业务，过了32块可以交易，过了64块可以提现这个流程应该怎么设计
- 在接口层收到交易以后直接发出去不行吗？这样就可以不扫数据库了
- 当前项目的 deposits、withdraws、internals，三张表分别存放了三种交易表，为什么需要这三张表，只用 transactions 一张表不行吗？它本身就有 tx_type 字段表示了交易类型了，这三张表也没有额外的一些有用的字段。如果说一定要这三张表，那么直接根据 transactions 表的模板创建出这三张表怎么样？
- 如果用户发起一笔提现，同时发生了归集，这时候 lock_balance 会怎么变化？代码中的 lock_balance 好像是直接覆盖
- balance 表关于锁定资金的的设计，加入 withdraw_lock_balance, collect_lock_balance，hot2old_lock_balance 来区分是不是合理一点
- 提现的 lock_balance 是在什么情况下释放掉的
- 锁定资金的时机是在交易是 pending ，也就是交易已发出就锁定，那么如果这笔交易已经发送成功了，但是饥饿游戏竞争失败被旷工丢弃（上链失败），有没有这种情况？此时交易资金已被锁定，代码中有处理这样的逻辑，有被解出锁定吗？
- 这套业务有没有前端后台管理系统？
- 业务方没有设置密码的吗？怎么防止业务方 id 被盗用？
- 业务方发起一笔提现请求，他怎么知道用户余额可提现金额是多少？当前没有相关的 rpc 接口
- 按照这一期新版的签名机代码，签名机已经将构建好的完整交易 raw_tx 返回了，考虑 walletKeyHash 的话，提现业务是不是应该变成这样
- 业务方根据签名机规定好的交易体结构构建交易对象然后生成 tx_base_64 在这个项目中新增一个 rpc 接口接收 tx_base_64，代码中根据 tx_base_64 和 wallet_key 生成 walletKeyHash 并返回，同时交易入库为待发送状态
- 业务方将 tx_base_64 和 wallet_key_hash 发送到签名机，签名机验证并构建完整的交易并返回 raw_tx 到业务方
- 业务方将 raw_tx 发送到这里，通过 rpc client 发送到区块链，raw_tx 是可以解析出交易体的，解析出交易信息，同时将交易状态更改为为已发送状态，等待后续扫链确定链上状态
- 数据库的交易表新增一个 notify_status 表示通知状态，或者使用消息队列的实现方式，和原来的 tx_status 分离开实现可不可以
- notify 可以用 rpc 来实现吗？这样把消息规则定义到 protobuf 里面，业务方实现 grpc server 就可以了
- 有的交易所提现是会进行打包的，这个业务怎么实现呢？
- 当前的通知和交易状态是强关联的吗？假如当前交易是 safe 状态，一直处于通知失败的状态，但是根据区块链上的确认数这笔交易已经 finalized 了，那么交易状态还是 safe 吗？
- 扫链的 endHeight 需要一定限制到最新区块高减去 confirmationBlocks 这个数字吗？
- rpc 接口设计中的 amount 用 Wei 还是 Ether ？
- 归集是当用户钱包金额达到一定程度触发，目前只有通过 rpc 来发送交易，业务方需要对每个用户都发起一个交易吗？
- 热转冷，和冷转热都是业务方通过 buildSignedTransaction 这个 接口来发送交易吗？
- 扫链与处理的过程中如果某个环节执行有 err 失败了，怎么中断和继续
我来回答
