关于EOS交易过期丢弃,处理方式(主要针对配置低的私链)

管理员组 缘雨 3月前 151

现在主要讨论私链(小公司自己的生产环境),节点没有主网多,网络没主网好,但是又不能过期了全部人工处理

情况:

  1. 首先,自己的合约调用一个action,eos打包后返回正常数据。
  2. 由于种种原因,比如私链网络卡,节点倒。然后这次的操作过期,被丢弃了。

处理:

  1. 在主网,有不完全确认不可逆方式(为了提高性能与用户体验),判断当前出块节点是否切换。仔细考虑在此种情况不适用。

  2. 经向大神求教: if(block_id <= last_irreversible_block_num) 大意为,当查询到最新确认不可逆的块高于打包action的块,即为不可逆。 但是我有个疑问:(菜鸡一枚,勿怪)那么假如在往打包块确认的途中卡顿超过了交易过期时间,丢弃了,然后私链卡完了又继续不可逆确认呢?可能出现这样的情况么? 举例:打包块在10,现在不可逆块在5,当不可逆确认到8,卡了,很卡,卡的超过了交易过期时间,交易被丢弃,然后待会儿链恢复了继续不可逆确认。

  3. 我想到的处理方式:首先,看看自己链不可逆高度差,计算确认到最新块要多久(有交易过期时间更好,但是我没有找到)。然后,自己后台定时,到了这个时间根据交易哈希去链上查查,还在,就成功了。但是,我又觉得不保险,有可能卡一下还没不可逆到那里呢。所以,再给它用上面2的办法确认下块的状态。

总结:我的想法一套下来,一个操作运算半天,玩个屁,用户都跑完了。私链比不上主网,但是要用啊!求有经验的小伙伴帮帮忙!

还没有人收藏过本帖~
最新回复 (13)
  • 管理员组 Surou 3月前
    0 引用 2

    修正问题

    首先说下你问题中描述不合适的点

    原文

    经向大神求教: if(block_id <= last_irreversible_block_num) 大意为,当查询到最新确认不可逆的块高于打包action的块,即为不可逆。

    你应该描述的是交易,大致描述如下

    经向大神求教: 判断一个交易是不是达到不可逆,获取当前交易,此时交易存在,且所在的block_id小于 last_irreversible_block_num及达到不可逆
    说的是交易,不是action。

    参考

    如何判断交易的不可逆 :https://www.bcskill.com/index.php/archives/702.html

    解答具体问题

    EOS 使用的DPOS BFT共识协议。 针对你这问题简单来说,一个BP一边打包接收来的交易,出块,此时其他bp同步过来区块,本身要是要检验的。

    我们拿一个交易过期时不同情况举例 当一个交易被广播,如果在出块BP打包时,超过了过期时间,此时交易将被拒绝 (查看代码) 如果BP已经打完包了,这个块将会被其他的BP同步过去并作校验,如果校验通过的话,将被放到此BP的本地区块,当有超过2/3的BP验证通过时,即为不可逆。只要是出块BP打包完了,这个交易的超时就没用了,之后再也不会验证它。也就是说这个超时,只是校验的交易发起到出块BP打包的时间。

  • 管理员组 Surou 3月前
    0 引用 3
    或者说 只要这个交易被BP出块打包后,在没有被分叉丢弃,还是会被达到不可逆的。
  • 管理员组 Surou 3月前
    0 引用 4
    又回到了你前面的问题  http://wiki.bcskill.com/?thread-3.htm
  • 管理员组 缘雨 3月前
    0 引用 5
    surou 或者说 只要这个交易被BP出块打包后,在没有被分叉丢弃,还是会被达到不可逆的。
    我懂了,老大。切换了出块节点后,如果交易还在,证明bp打包成功,不存在过期。而且也不存在分叉丢弃,因为交易还在呢
  • 管理员组 Surou 3月前
    0 引用 6
    缘雨 我懂了,老大。切换了出块节点后,如果交易还在,证明bp打包成功,不存在过期。而且也不存在分叉丢弃,因为交易还在呢
    和分叉没关系,还是可能被分叉的,如果这个块没被及时同步,等被其他节点接收时,已经处于分叉的短分支了,就丢弃了,这个交易的生命周期,也就结束了
  • 管理员组 缘雨 3月前
    0 引用 7
    surou 和分叉没关系,还是可能被分叉的,如果这个块没被及时同步,等被其他节点接收时,已经处于分叉的短分支了,就丢弃了,这个交易的生命周期,也就结束了
    我又懵逼了:假如出块节点网络延迟,导致出块13,打包到13个块,那成功换出块节点后不是会把13丢了么
  • 一级用户组 fengzi 3月前
    0 引用 8
    缘雨 我又懵逼了:假如出块节点网络延迟,导致出块13,打包到13个块,那成功换出块节点后不是会把13丢了么
    导致出块13是啥意思?打包到13个块又是什么意思。。。
  • 管理员组 缘雨 3月前
    0 引用 9
    fengzi 导致出块13是啥意思?打包到13个块又是什么意思。。。
    一个bp出块12转下一个啊,13不是分叉了么
  • 一级用户组 fengzi 3月前
    0 引用 10
    缘雨 一个bp出块12转下一个啊,13不是分叉了么
    为啥网络延迟就会导致一个节点连续出13个块?
  • 管理员组 缘雨 3月前
    0 引用 11
    fengzi 为啥网络延迟就会导致一个节点连续出13个块?
    我也不太懂,可能我基础太差,我想的是:三个bp,当出块bp和其他两个bp网络延时无限时,可以认为其他两个bp倒了吧,然后它继续出块啦,但是刚出了一个块13,又连上了其他两个bp,接过去的时候就把这第13个块丢了
  • 管理员组 缘雨 3月前
    0 引用 12
    之前我在不稳定服务器上测试的时候,出现过多出块的情况,然后轮倒下个一个bp出块时报错,当时我在群里求教,听说是分叉
  • 一级用户组 fengzi 3月前
    0 引用 13
    缘雨 我也不太懂,可能我基础太差,我想的是:三个bp,当出块bp和其他两个bp网络延时无限时,可以认为其他两个bp倒了吧,然后它继续出块啦,但是刚出了一个块13,又连上了其他两个bp,接过去的时候就把这第1 ...
    你说的这种情况,等于节点正常,但是节点间通信断了,那就只能分叉了,各出各的块儿。
    重新连上之后,以出块节点多的链为准,出块节点少的链丢弃。
  • 管理员组 缘雨 3月前
    0 引用 14
    fengzi 你说的这种情况,等于节点正常,但是节点间通信断了,那就只能分叉了,各出各的块儿。 重新连上之后,以出块节点多的链为准,出块节点少的链丢弃。
    嗯,对啊,刚才的13就是这里被丢弃的那部分,老大说查看出块地址变更并不能完全保证不被丢,所以现在我找到更好的方法了,就是后台要做个轮询,嗯,我java同事估计不想做
返回