在操作被CITA节点确认前, 产品中的数据状态应该如何处理?

#1

我觉得这是一个所有开发区块链应用中必然会遇到的问题. 我是第一次做, 所以想请教业界的最佳实践.

我把问题具体化一些. 比如App的用户每天可以获得5个体力, 每天0点清零. 每个体力可以用于[打工], 触发一次智能合约, 转化为1个金币, 金币可以累计. 体力的获得, 消耗, 金币的增加都在链上记录.

假设我已经有了5个体力, 现在点击App上的 [打工] 按钮. 每按一次, App都会把动作发给CITA去执行那个智能合约. 但是链上确认是需要一定时间的, 比如30秒. 那么此时产品端对于剩余体力应该如何显示呢?

  1. 如果立刻显示4次, 但之前的[打工]请求最终执行失败了, 则用户再次进入此页面时会显示5次, 等于没执行过.
  2. 依旧显示5次, 用户甚至可以连续 [打工] 10次, 只不过一段时间后, 会确认其中只有5次打工成立, 兑换了5个金币, 另外5次都被驳回了.

这两种方法都涉及后端DB状态和区块链状态如何同步的问题, 感觉挺恶心的. 希望各位大佬能指一条明路. 先谢谢啦.

#2

你可以考虑加一个 working 状态啊！

在调用合约前体力是 5, 金币是 0. working 是 0.
在发交易后，数据上链前，体力是 4, 金币是 0, working 是 1.
在数据上链后，体力是 4, 金币是 1, working 是 0.

…

1赞
#3

哦. 就是说, 产品上加一个字段, 表示 [待确认金币] 之类的东西即可. 对吗? working在这个上下文中有什么专业的翻译名词吗?

#4

就好比玩游戏的时候，一直砍树的那个过程。

#5

我觉得这跟区块链无关，你的场景其实就跟普通 web app 中要解决的并发问题一样。比如同一笔数据，存在两个线程同时去更新的场景，如果没有相应的状态条件去做限制，就会有脏读或者脏写的问题。

1赞
#6

确实和区块链无关，任何的异步系统都有这样的问题。

#7

【工作中】 体力-1 金币不变

上链成功：发工资-> 体力不变 金币+1
上链失败：发红牛-> 体力+1 金币不变