num*prefix并没有阻止合约账号，目前发现大量作弊账号，
他们在starttime+11秒的时候提前发起了几百个请求， 每次请求的时间点都不一样（会导致prefix,num不一样， 合约发起的delay trans的num和prefix是采用的最近一个已确认的快id）
这样delay执行的合约在同一秒执行几百个， 总有一个撞运气满足 val%mod==0
（其他的elay trans都会被eosio_assert拦住，导致大量eosio::onerror，没多少关系代价）
建议此处增加冷却机制， 当发现被random_offset拦住了， 不要直接eosio_assert,
而是放行该trans：
1: 全额退回eos， INLINE ACTION SEND
2: empalce用户表， 写userinfo的action.colldown
这样就不用怕合约账户的同一秒n次的洪水攻击了， 只要第一个求模被random拦住
就只能等10几秒， 然后第二个又被拦住。。。
对于普通钱包用户， 影响不大，因为操作也要个几秒的时间
num*prefix并没有阻止合约账号，目前发现大量作弊账号，
他们在starttime+11秒的时候提前发起了几百个请求， 每次请求的时间点都不一样（会导致prefix,num不一样， 合约发起的delay trans的num和prefix是采用的最近一个已确认的快id）
这样delay执行的合约在同一秒执行几百个， 总有一个撞运气满足 val%mod==0
（其他的elay trans都会被eosio_assert拦住，导致大量eosio::onerror，没多少关系代价）
建议此处增加冷却机制， 当发现被random_offset拦住了， 不要直接eosio_assert,
而是放行该trans：
1: 全额退回eos， INLINE ACTION SEND
2: empalce用户表， 写userinfo的action.colldown
这样就不用怕合约账户的同一秒n次的洪水攻击了， 只要第一个求模被random拦住
就只能等10几秒， 然后第二个又被拦住。。。
对于普通钱包用户， 影响不大，因为操作也要个几秒的时间