智能合约 Event 恢复

·v1 | 👀104
Dapp, Database

其实数据库被误删这种事情不是 Dapp 专属的一种事故，而应该在所有具有数据库应用的防范列表中。这一次只是结合智能合约的数据库的一种特例和它特殊的「修复」方式。

成本核算

  • 显性成本：50USD + 275USD （Infura Team Plan + Archive Node Access Permission）
  • 隐形成本：用户信任度降低，项目的打击
  • 健康成本：团队所有人两天精神紧绷

Dapp 架构

sequenceDiagram autonumber par 用户注册流程 用户->>前端: 钱包签名 前端->>智能合约: 调用只能合约注册账户 智能合约->>后端: 通过 Event(emit Register(用户ID, 用户以太坊地址)) 数据同步 end par 登陆到后端 用户->>前端: 钱包签名 前端->>后端: 签名信息传递给后端 后端->>前端: 验签取到用户以太坊地址，返回用户ID end

在本案例中 Dapp 的架构如上所示，有三个端，前端用户界面，业务全在智能合约中，后端收集一些信息做统计、分析的工作。

在这个架构下，event 的 subscribe 和 持久化显得十分重要，所有的数据都是由 event 生成。

发生原因

工程师在重置已使用的测试环境时，误删了线上环境数据库，由于用户的所有信息都是从 API 读取的，数据库删除后所有用户进入前端都是空空一片，只能保证基本的业务流程的使用，所有的统计信息都没了。

团队成员马上进入战斗状态，

  1. 首先询问删除了什么表：delete from table 的方式删除了用户表、event 原始数据表
  2. 其次判断恢复方式
    1. MySQL 层面：备份文件、binlog，这两个都没有！
    2. Event 层面：重新拉取一下从项目开始到现在只能合约发到后端的 event，重新组织数据。

因为并没有做备份，没有开 binlog，没有使用云服务，现在从 MySQL 层面无法下手。因为后端只是收到 event 然后转换为结构化数据，持久化到数据库中，所以决定使用从头处理一遍 Event 的方式去恢复被删除的数据。

然后经过实际试用后选择了 Infura 这家的 Archive 节点的服务，当时我们找到了三种方式：

  1. 自建以太坊全节点，以太坊轻节点我们搭建过一次，但是有足足 10 个区块的延迟，是无法接受的，现在需要搭建全节点来拉取 event 的话，从同步需要的时间和前期积累的经验来看，不考虑这种方式
  2. QuikNode 的服务，他们的 rpc 节点我们试用过，Dashboard 做的十分简陋，节点使用起来速度也比较慢，并且区块同步有延迟，不考虑
  3. Infura 的服务，Infura 的服务是非常不错的，已经经过了 MetaMask 及各种钱包的验证。经过我们本次事故恢复的体验来说，Infura 做的以太坊服务是非常值得推荐的（除了他们的 billing 系统，操作的时候一定要慎重，订单、优惠券管理一塌糊涂，重复扣费蒙眼扣费）。

然后我们从 Infura Archive 节点拉取了从合约部署到当前区块的所有 event 重新持久化后替换了线上数据库，完成事件处理。

吃一堑长一智

  • MySQL（持久化数据） 一定要定期备份、开启 binlog

Comments