33cn/plugin

chain33 官方插件系统

plugin's Issues

更新lottery执行器

1. 需求更新，根据产品建议，时时彩中奖分配金额进行调整。从传统的赔率1:5,提升到1:10，但是，增加开发者和运营方费用提成，提成地址固定，提成比例在游戏创建时指定
2. 实现更新，由于新增了randnum模块，时时彩可以直接使用，去掉时时彩之前独立的代码，时时彩之前获取随机数的逻辑和randnum模块逻辑有些不同，randnum模块引用了ticket的随机数；
3. BUG修改，lottery存储了一个MAP，为了防止分叉，改为切片，由于主链不存在lottery交易，此修改不影响主链
4. 内部需求更新，开奖动作:（创建者，当期参与者）可发起 -> 游戏创建者可发起

plugin测试链同步71506无法继续同步

plugin最新代码同步至71505无法同步，查看日志71506高度状态哈希检验错误

查看71506高度中有一笔向类似多重签名地址的地址转账操作，可能是因此这个地址引起

@icehawk-hyb

Javascript VM 支持

Javascript VM 相对比较成熟，可以考虑确定性改造过的JavaScript VM 以避免分叉

更新Makefile，辅助支持fork分支的master同步

在Makefile中参考chain33的实现，添加addupstream、sync、branch、push的命令

最新plugin代码同步至386155后无法继续同步

最新plugin代码同步至386155后无法继续同步，停在386154
区块386155中的第二笔交易的执行结果旧版本与新版本不同，导致状态哈希校验不过
交易链接：
https://testnet.bityuan.com/tradeHash?hash=0x22ca8448ea395d238be74dcb8f06d7f5e3cbde8de785346083b9cb08e6ffdf50

旧版本：

新版本：

relay

relay 模块的ci 经常发生错误，详细的错误查看：
http://39.98.41.13:8080/blue/organizations/jenkins/33cn-plugin/detail/33cn-plugin/243/pipeline/

EVM合约的只读调用数据不上链

目前EVM合约的调用全部是通过交易的方式实现，即使是调用合约的查询接口，也会将交易数据上链，这样做会导致两个问题：

1. 链上无用数据增多； 因为只读交易不改变数据状态，存储到链上将会生成垃圾数据；
2. 用户多余花费； 上链的交易需要收取手续费，用户的查询操作会导致用户承担额外的支出；

travis deploy testcase 不稳定

travis 云端跑testcase 不稳定，jq解析不对，命令卡住，docker 启动失败等问题
建议：
1， travis 工程 setting里面可以设置变量DAPP，如果DAPP设置了，travis只跑DAPP的testcase，否则不跑
2，all plugin的case当前放到jenkins里面跑，独立服务器，更加稳定

trade合约 用接口GetOnesOrderWithStatus 查询到未完成订单能查到被撤销的订单

输入参数如下， 查询未完成订单， 会返回已经撤销的订单。（ 主链上 ）

{
    "id" : 1 ,
    "method" : "Chain33.Query", 
    "params":[{ 
        "execer" : "trade",
        "funcName" : "GetOnesOrderWithStatus",
        "payload" : {
            "status" : 1,
                        "addr" : "12ZAyk9R1hTC6Fs2RmMeV34vcikR28DwSd",
                        "direction": 1,
                        "count" : 10,
                        "fromKey" : ""
        }
    }]
}

plugin代码将钱包锁定后，依然可以挖矿

plugin代码将钱包锁定后，依然可以挖矿

锁定于18:15

该地址依然可以挖矿，但无法open和close

更新到最新版本后cli version显示为6.0.1

更新到最新版本后cli version显示为6.0.1
实际最新版本应为6.0.2

token 命令行缺少一个send-exec的命令

bty有send-exec的命令，token合约中已经实现send-exec的处理，但是cmd命令行没有支持。提个issues 跟踪

@ linj-disanbo

paracross 缺少命令行看出转移到平行链的资产， 集成测试缺少对应的测试

@linj-disanbo

seed get 密码输入错误时，返回信息有误

seed get 密码输入错误时，返回信息有误，应提示密码错误

solo配置下token预创建操作失败

执行命令：

cli send token precreate -f 0.01 -i testToken -n testToken -s TC -a 12qyocayNF7Lv6C9qW4avxs2E7U41fKSfv -t 100000 -p 1 -k 12qyocayNF7Lv6C9qW4avxs2E7U41fKSfv

结果：

{
    "tx": {
        "execer": "token",
        "payload": {
            "tokenPreCreate": {
                "name": "testToken",
                "symbol": "TC",
                "introduction": "testToken",
                "total": "10000000000000",
                "price": "100000000",
                "owner": "12qyocayNF7Lv6C9qW4avxs2E7U41fKSfv"
            },
            "Ty": 7
        },
        "rawpayload": "0x38070a4b0a0974657374546f6b656e120254431a0974657374546f6b656e2080c0caf384a3022880c2d72f3222313271796f6361794e46374c7636433971573461767873324537553431664b536676",
        "signature": {
            "ty": 1,
            "pubkey": "0x0320bbac09528e19c55b0f89cb37ab265e7e856b1a8c388780322dbbfd194b52ba",
            "signature": "0x30440220598679f49176afd76c96d827db41be705256e2d0d90a314665d9edb21d239b2f022035fe3f647db75d5c42259aa1e27719fb0cc476413d0c3db2ffd5afd19a57a944"
        },
        "fee": "0.0010",
        "expire": 1542261508,
        "nonce": 7369629917767364095,
        "to": "12hpJBHybh1mSyCijQ2MQJPk7z7kZ7jnQa",
        "from": "12qyocayNF7Lv6C9qW4avxs2E7U41fKSfv"
    },
    "receipt": {
        "ty": 1,
        "tyName": "ExecPack",
        "logs": [
            {
                "ty": 2,
                "tyName": "LogFee",
                "log": {
                    "prev": {
                        "currency": 0,
                        "balance": "985999400000",
                        "frozen": "0",
                        "addr": "12qyocayNF7Lv6C9qW4avxs2E7U41fKSfv"
                    },
                    "current": {
                        "currency": 0,
                        "balance": "985999300000",
                        "frozen": "0",
                        "addr": "12qyocayNF7Lv6C9qW4avxs2E7U41fKSfv"
                    }
                },
                "rawLog": "0x0a2b10c0b89391d91c2222313271796f6361794e46374c7636433971573461767873324537553431664b536676122b10a0ab8d91d91c2222313271796f6361794e46374c7636433971573461767873324537553431664b536676"
            },
            {
                "ty": 1,
                "tyName": "LogErr",
                "log": "ErrNotFound",
                "rawLog": "0x4572724e6f74466f756e64"
            }
        ]
    },
    "proofs": [
        "0xf8f99a2d1126a1fb16e464ef326bf5a8395dcb1ab92c1b73836e8db7c3057e42"
    ],
    "height": 9,
    "index": 1,
    "blocktime": 1542261391,
    "amount": "0.0000",
    "fromaddr": "12qyocayNF7Lv6C9qW4avxs2E7U41fKSfv",
    "actionname": "tokenPreCreate",
    "assets": null
}

通过本地启动单机版本chain solo挖坑，启动autotest测试，发现token预创建失败
本地启动autotest命令， make autotest dapp=token（需要合并最新的autotest pr）

最新plugin代码同步至279186后无法继续同步

最新plugin代码同步至279186后无法继续同步，停在279185

区块链上的数据发布合约实现

需求背景：
为保证数据的公平公正性，在区块链上提供权威数据发布合约。满足以下需求：

1. 合约提供录入和查询接口。
2. 合约录入时对数据的key和value定义好标准的格式。
3. 合约是否要满足一定的经济模型，惩罚机制（一期可以不实现，后面再加入）

实现点：

1. 发布者的地址需要通过superManager添加，调用我们系统manage合约。
2. 数据发布的key要遵循一定的格式，比如游戏类的格式要满足一定的前缀（发布者地址+ 运营特征值+游戏类别 等）
3. 数据发布的时候要能输入数据来源描述（比如：数据来源于新浪体育）
4. 数据发布的 value要根据现有的业务做一定的抽象，这块一期可以先考虑下，不用实现的很完备。 一期可以用json格式，数据提供方和开发方可以事先先约定好。
5. 合约对外提供查询接口供具体的应用合约调用， 具体的应用合约只查询满足条件的key，获取数据做相应的运算。
6. 数据的发布需要先预发布，再审核后切换成正式发布。（类似于token的预创建和完成这两步）

tendermint共识存在投票信息丢失，导致共识失败

部署4个tendermint节点的环境中，出现过区块高度达到20多万后，共识失败的情况。目前分析结果是共识投票信息的丢失，需要进一步完善tendermint处理投票信息的机制。

lottery合约增加查询功能：为每个地址提供方便地收益统计

EVM合约需要支持绑定ABI

增加以下特性：

• EVM合约支持绑定ABI；
• EVM合约支持ABI格式的rpc调用；
• EVM合约支持ABI格式的命令行调用；

plugin代码ticket open和close时出现重复交易

1.调用cli wallet auto_mine -f 1进行购票并open
2.调用cli wallet auto_mine -f 0 关闭自动购票后再cli ticket close关闭选票
以上两种ticket相关的操作会造成重复交易

Makefile的build指令引用了GOPATH中的包，会导致CI中潜在的编译错误

问题描述：
在本地Makefile编译工程时，会从GOPATH和vendor两个目录下查找依赖的包，CI环境上的GOPATH内容未知，可以认为编译仅依赖vendor内容，这样会导致一个潜在问题：

本地开发代码时引入了GOPATH中的包，在本地编译、打包、测试都是正常的，但是向Github提交代码时ci失败，因为vendor中没有此包；

建议解决方案：
方案一：
升级到Go111版本，启用module开关，通过go.mod管理依赖关系；

方案二：
修改Makefile，build指令中避免引用GOPATH中的包；

挖矿时，关闭选票报错

挖矿时，关闭选票报错
"log": "ErrTicketClosed"
可能是由于矿机一次需要关闭的票数过多导致的
测试矿机有1000票，而关票上限为250左右，再次关闭造成重复关闭
https://testnet.bityuan.com/tradeHash?hash=0x46bacbde6565fa061cad8de191155e35eb17004870fdd85fd7a9564661ea4e42

ERC777 ERC20 ERC1410

token 合约实现类似 ERC20 ERC777 以及 ERC1410 的功能.

按照名称前缀，配置相关功能权限。

没有前缀，基本的token功能

定义前缀S
S: 1410 sto 相关的币

显示的时候可以这样 S:FZM -> FZM(股权)

建议增加本地ci检测

现在有多个步骤检测ci，分别是make fmt , make linter make ...，步骤一多，容易忘记。
建议增加一个make localci，用于本地格式化、检测、测试和验证，通过以后再执行Pull Request。
@vipwzw

增加dapp/privacy， consensus/ticket测试用例，提高测试覆盖率

目前的测试覆盖率低于标准测试覆盖率，需要增加测试用例，提高测试代码覆盖率

• dapp/privacy 目前测试覆盖率是29.09%，目标测试覆盖率是45.8%
• consensus/ticket 目前测试覆盖率是45.85%， 目标测试覆盖率是70.97%

trade 模块引起 bityuan同步不了

trade 为了支持更广义的资产， 不仅限于token 资产，去掉了对token 合约的依赖.

删除了判断token资产是否存在的步骤， 导致了新老版本执行结果不 一致， 现在回滚代码。

新节点在高度: 1181681 同步不了

挖矿时，无法自动close

开启自动挖矿的钱包挖矿时，不会自动close
地址：1K7Fko7e21F2qXdYriVLheJue5ZW5KerZL

go vet 还有一些文件没有过

main.go:10: +build comment must appear before package clause and be followed by a blank line
exit status 1
plugin/consensus/tendermint/consensus_state.go:865: missing verb at end of format string in Sprintf call
plugin/consensus/tendermint/node.go:230: call of node.addPeer copies lock value: tendermint.peerConn contains sync.WaitGroup contains sync.noCopy
plugin/consensus/tendermint/node.go:399: call of node.addPeer copies lock value: tendermint.peerConn contains sync.WaitGroup contains sync.noCopy
plugin/consensus/tendermint/node.go:411: addPeer passes lock by value: tendermint.peerConn contains sync.WaitGroup contains sync.noCopy
plugin/consensus/tendermint/node.go:703: return copies lock value: tendermint.peerConn contains sync.WaitGroup contains sync.noCopy
plugin/consensus/tendermint/node.go:732: return copies lock value: tendermint.peerConn contains sync.WaitGroup contains sync.noCopy
plugin/consensus/tendermint/node.go:738: return copies lock value: tendermint.peerConn contains sync.WaitGroup contains sync.noCopy
plugin/consensus/tendermint/state.go:177: wrong number of args for format in Errorf call: 1 needed but 2 args
exit status 1
plugin/consensus/tendermint/types/block.go:508: unreachable code
plugin/consensus/tendermint/types/height_vote_set.go:174: unreachable code
plugin/consensus/tendermint/types/util.go:192: struct field mtx has json tag but is not exported
exit status 1
plugin/dapp/evm/executor/vm/common/crypto/bn256/curve.go:194: possibly passing Go type with embedded pointer to C
plugin/dapp/evm/executor/vm/common/crypto/bn256/curve.go:194: possibly passing Go type with embedded pointer to C
plugin/dapp/evm/executor/vm/common/crypto/bn256/gfp6.go:274: possibly passing Go type with embedded pointer to C
plugin/dapp/evm/executor/vm/common/crypto/bn256/gfp6.go:274: possibly passing Go type with embedded pointer to C
plugin/dapp/evm/executor/vm/common/crypto/bn256/gfp6.go:276: possibly passing Go type with embedded pointer to C
plugin/dapp/evm/executor/vm/common/crypto/bn256/gfp6.go:276: possibly passing Go type with embedded pointer to C
plugin/dapp/evm/executor/vm/common/crypto/bn256/gfp6.go:296: possibly passing Go type with embedded pointer to C
plugin/dapp/evm/executor/vm/common/crypto/bn256/optate.go:149: possibly passing Go type with embedded pointer to C
plugin/dapp/evm/executor/vm/common/crypto/bn256/twist.go:204: possibly passing Go type with embedded pointer to C
exit status 1
plugin/dapp/privacy/crypto/ring_signature_test.go:164: no formatting directive in Errorf call
plugin/dapp/privacy/crypto/ring_signature_test.go:168: no formatting directive in Errorf call
plugin/dapp/privacy/crypto/ring_signature_test.go:337: no formatting directive in Errorf call
plugin/dapp/privacy/crypto/ring_signature_test.go:398: no formatting directive in Errorf call
exit status 1
plugin/dapp/privacy/wallet/privacystore.go:394: unreachable code
plugin/dapp/privacy/wallet/privacystore.go:401: unreachable code
exit status 1
plugin/dapp/relay/commands/relay.go:330: first argument to Println is os.Stderr
exit status 1
plugin/dapp/trade/executor/query.go:641: unreachable code
exit status 1
plugin/dapp/trade/types/trade.go:168: unreachable code
exit status 1
make: *** [vet] Error 1

lottery合约增加查询每期参与人数，投注金额统计查询

产品新增需求

离线挖矿时，离线地址无法关闭已授权的票

离线地址A授权给在线地址B挖矿，在遗失地址B的私钥后，cli中无法使用地址A的私钥关闭由地址Bopen的票。
重新给地址C授权后，C地址也没有权限关闭这部分的票。

evm合约转账操作实现冻结能力

目前用户操作EVM合约时，是先转账到自己地址下的合约账号，然后在合约操作时再转到evm自己合约实例地址下；

其中，第二步操作不可靠，如果此地址被攻破，所有钱将丢失，所以需要修改成使用frozen机制冻结在自己的合约账户，等合约操作完成后再进行转账操作；

@vipwzw @zhengjunhe @andyYuanFZM

双色球合约

需求内容：

• 管理员发布双色球竞猜到区块链合约上

• DAPP用户可参与投注
  如果已停止投注（到时间或者区块高度），则DAPP上不能再进行投注，如果尝试投注，将失败

• 过了投注时间后，管理员向区块链合约揭晓结果，并触发合约结算
  按照双色球的通用规则进行结算，奖池不断累加

• 用户可查询自己的投注历史记录

通过rpc创建evm合约后，调用返回空

问题描述：
通过rpc接口创建新evm合约时，同时指定code和abi，创建成功后，调用合约方法时返回空；

"log": {
                    "caller": "1Kkq2neiAWSGkk3djkJ9SPoG2tdGzfwDpa",
                    "contractName": "user.evm.0xea5b2eae4efd5d104604cec9a498e8f2f117d09b0bf76810667f6698794b09d4",
                    "contractAddr": "1CSavZCB4ky1PQrVbtXWmjfCq3HSbbLmFT",
                    "usedGas": "0",
                    "ret": null,
                    "jsonRet": ""
                },

竞猜合约

需求内容：

1.管理员可发布竞猜主题到区块链合约上。
topic：比如特朗普中期选举结果是什么？
选项：A：只赢得众议院 B：只赢得参议院 C：赢得参众两院 D：参众两院都输。
主题可限定什么时间或者什么区块高度之前停止投注。
2.DAPP用户可参与投注。
如果已停止投注（到时间或者区块高度），则DAPP上不能再进行投注，如果尝试投注，将失败。
3.过了投注时间后，管理员可向区块链合约揭晓结果，并触发合约结算。
合约将抽取一定比例的手续费，将剩余奖金按比例分发给赢家。
4.用户可查询自己的投注历史记录。

paracross 本地执行出错

出错信息
[12-17|08:16:06] call localexec error module=execs.base prefix=ExecLocal_ tx.exec="[112 97 114 97 99 114 111 115 115]" info="proto: field "types.ParacrossTx.TxHash" contains invalid UTF-8"
原因， protobuf 升级 string 不能包含 非utf8字符。

解决方式 使用hex格式保存

建议平行链上实现撮合交易

在主链上实现撮合交易会影响出块速度， 现在trade交易没有撮合功能， 要实现链上交易所， 撮合功能必不可少

平行链过滤主链的数据，过滤条件要包含整个title

目前以下的代码逻辑，只过滤了user.p.， 导致比如user.p.guodun链上的数据会串到别的平行链上。

func (client *ParaClient) FilterTxsForPara(main *types.BlockDetail) []*types.Transaction {
var txs []*types.Transaction
for i := 0; i < len(main.Block.Txs); i++ {
tx := main.Block.Txs[i]
if types.IsParaExecName(string(tx.Execer)) {
if tx.GroupCount >= ParaCrossTxCount {
mainTxs, endIdx := calcParaCrossTxGroup(tx, main, i)
txs = append(txs, mainTxs...)
i = endIdx - 1
continue
}
txs = append(txs, tx)
}
}
return txs

ticket 合约的autominer 限制

ticket 合约在配置 为 solo 挖矿的情况下，还在继续 购买票。应该限制只有 ticket 共识开启的情况下，才会自动购买票。

修复钱包功能无法使用的BUG

目前版本，系统内钱包模块的功能无法正常使用，需要进行处理。

evm 客户端创建合约参数应该支持从文件读取 abi bin

真实的合约可能abi bin 很大， 直接放在在参数里把内容写上，用起来不方便
$ ls 1.abi 1.bin -lh
-rw-rw-r-- 1 linj linj 12K 12月 11 16:19 1.abi
-rw-rw-r-- 1 linj linj 24K 12月 11 16:18 1.bin

用户合约log类型的定义有和系统日志冲突的可能性

因为当前每个合约是分而自治的，对于日志的解析一般情况是不会冲突的，
但是前提是，日志编号没有与系统日志号有冲突的情况，
即不占用以下日志编号：
TyLogReserved = 0
TyLogErr = 1
TyLogFee = 2
//TyLogTransfer coins
TyLogTransfer = 3
TyLogGenesis = 4
TyLogDeposit = 5
TyLogExecTransfer = 6
TyLogExecWithdraw = 7
TyLogExecDeposit = 8
TyLogExecFrozen = 9
TyLogExecActive = 10
TyLogGenesisTransfer = 11
TyLogGenesisDeposit = 12

但是目前没有，软件行为可以控制用户合约不定义以下系统编号，
可能需要写完代码调试的时候，发现日志解析错误了，就像系统日志用
用户合约日志格式在解析，因为默认是优先使用用户合约日志格式解析，
所以我觉得当前我们需要一种机制，帮助用户合约开发者规避以上问题，
系统占用的日志号不能被用户合约用来注册日志号，可以让其直接panic，
然后给出信息，提示注册的日志号占用了系统日志号。
因为当前合约都是之前统一编号，后来在重构过程中直接拷贝过去了，
没有发生这种情况

将auto_mine 置1后，automining状态未改变

如图将auto_mine 置1后，automining状态未改变为true

mempool插件化

目的：由于chain33已实现mempool的插件化改造，plugin里可以新增mempool的排队策略

实现：新增一种交易所排队方式，可以按照手续费，时间，交易字节数这三个因素对需要打包的交易进行排队

具体：对cache进行具体的实现，用跳跃表来存储交易，当mempool缓存池已满的情况下，会按照手续费，时间，交易字节数，这三个条件算出这笔交易的价格，然后与缓存池里价格最低的交易进行比较，抛弃价格低的交易，留价格高的交易在缓存池里

执行器retrieve,lottery,ticket本地数据执行逻辑错误

1. retrieve执行器在处理回滚数据时，出现代码循环调用
2. lottery，ticket执行器本地处理回滚数据缺少有效代码

ticket账户有钱，但是无法自动买票

故障描述：目前无法自动买票，区块高度在不到1W，增长开始缓慢

检查合约中 localdb的处理有没有考虑交易不成功的情况

func (c *Coins) ExecDelLocal_Transfer(transfer *types.AssetsTransfer, tx *types.Transaction, receipt *types.ReceiptData, index int) (*types.LocalDBSet, error) {
 	if receipt.GetTy() != types.ExecOk {
 		return &types.LocalDBSet{}, nil
 	}
       ....

调用libbyz的pbft版本

开发目的和功能说明

开发目的是实现chain33**识模块中的pbft模块。pbft原作者的主页上给出了一个官方的pbft实现，主要是用C语言实现，这里希望可以用go语言直接调用该pbft库提供的一些接口，实现模块要求。

代码说明

代码的实现在plugin/consensus/pbftlibbyz上进行。整体上代码沿用原先的结构，只是把共识部分替换成了调用官方库的接口。bft文件夹就是官方提供的库。

区块链中的节点用Client结构体表示，其中isClient变量表示该节点是client节点或replica节点，这里面的client节点和replica节点沿用的是pbft论文中的概念，client节点负责Propose区块，然后replica节点进行共识返回消息给client节点，client节点再把区块写入。

在CreateBlock()函数里面检查如果不是client节点就进行replica节点相应的初始化接着开始监听来自client的请求。如果是client节点则进行一些client的初始化，接着开始新建一个块。原先是Propose(&newblock)和readReply()两个函数，分别是往channel里写入request和读reply，原先开发的pbft代码会读到channel的request进行共识接着返回reply到channel里。现在把这两个函数合并成了一个ProposeAndReadReply函数，调用官方库的Byz_alloc_request，Byz_invoke函数发送request，这时候直到收到reply函数才会进行下去，接着打印出得到块的日志，pbft的工作就完成了。

最后在cfuns.go里面写了一些replica的helper函数供调用。

使用测试

使用docker进行相关测试。原先的pbft单元测试只运行了一个节点，我们这里需要运行5个节点，1个client节点和4个replica节点，在pbftlibbyz_test.go中，对于client节点会模拟一些交易，打包区块，而对于replica节点就负责共识部分。

主要的配置工作是节点的IP。在bft/config下配置节点的IP，以及在5个.toml文件中配置好节点IP和节点编号。

具体使用上，首先在plugin/consensus/pbftlibbyz目录下，运行./build-docker.sh编译出docker镜像，然后运行./run-docker.sh运行5个docker容器(容器名为replica-1,replica-2,replica-3,replca-4,client)，使用docker attach client就可以看到client节点打包区块等日志输出。

实现类fomo3D 游戏合约

1.1 背景

类Fomo 3D游戏，满足以下几个要求：

• 可以短时间结束游戏，尽量不让游戏时间拖太长；
• F3D的核心**不变，最后一把钥匙拿大奖；
• 早起参与者拥有相对优势；
• 游戏多轮长期运转，避免Fomo3D一轮终结的命运；

1.2 游戏设计

原版F3D的游戏机制比较复杂，一般参与人也很难搞清楚，所以本游戏设计尽量简单易懂，使参与者可以快速理解游戏玩法，及时参与。

下面分别从几方面介绍游戏的设计组成，然后再统一汇总下游戏的玩法及运作机制。

1.2.1 奖金分配

一轮游戏过程中不进行任何分配，一轮结束后，以所有募集到的金额为基础，按以下比例进行分配：
这里比例应该可动态调整

比例	用途	说明
40%	终极大奖	奖励给最后一把钥匙持有人
30%	持有分红	本轮游戏的所有钥匙持有人按比例分红
20%	奖金池	滚动到下一轮的奖金池，作为下一轮的初始金额
10%	平台运营	平台运营费用

如此设计的意图是，保留最后一把钥匙吸引力的同时（40%奖励），给予其他参与人分红鼓励（30%高比例分红），并且吸引下一轮玩家尽早参与（初始奖金池有上一轮的20%金额，早期钥匙有超高性价比）；

1.2.2 钥匙价格

使用统一的游戏代币，目前和BTY一比一兑换

第一把钥匙的初始价格：0.1 Token；

下一把钥匙的价格，在上一把成功交易价格基础上，上浮1%，即第二把钥匙价格为0.0101；

下一把钥匙的价格，在上一把成功交易价格基础上，固定上浮10%；

以此类推；

钥匙价格上浮范围，用户可控，幅度为：1%-10%；

如果一次购买多把钥匙，则多把钥匙的价格相同，也不会因为上一个人买了多把而影响下一个人买钥匙的价格；

---

同一个区块内，如何判定交易的先后并且使用不同的钥匙价格？多人同时购买时价格如何确定？

使用下面几点，保证可以正常运行：

1. 后台提供缓存接口，实时更新最后一把钥匙价格；
1. 游戏界面实时调用后台接口，刷新前端钥匙价格，并在界面提示价格仅供参考，可能会有小幅上浮；
1. 参与者购买钥匙时，仅提供钥匙把数、上浮比例，不提供钥匙的价格，实际价格由合约在执行时计算；
1. 游戏合约执行时，实时在缓存数据库中更新钥匙价格，以保证同一个区块内的多笔交易可以按顺序、钥匙价格递增的方式执行；

1. 同一个区块内，钥匙的价格不变，如果本区块有人购买钥匙，则下一个区块钥匙价格发生变化；

异常情况：

1. 有可能出现参与者余额不足的情况（界面显示余额足够，合约执行时不足），此时交易会失败；

1.2.3 游戏周期

本游戏一轮的运行时间为1小时，如果无人购买钥匙，则剩余时间会实时减小，如果有人购买钥匙，则可以延长剩余时间，但最大剩余事件仍然不会超过1小时；

项	值	说明
初始时间	1小时
一把钥匙延长	30秒	一个账户购买多把钥匙，最多延长300秒
最大可用时间	1小时	延长时间+剩余时间 <= 1小时

1.2.3.1 游戏合约中的计时器逻辑

需要在游戏平行链节点上运行一个定时检测程序，以30秒为周期，检测游戏的结束时间，当游戏结束后发送一个开奖交易，进行开奖；
定时检测程序可以优化如下：

剩余时间	下一检测周期
>10分钟	10分钟
>5分钟	1分钟
>1分钟	30秒
<1分钟	10秒

1.2.4 异常情况处理

游戏在运行过程中，可能会出现一些异常情况，需要有对应的处理机制可以保证游戏正常运转下去；

1.2.4.1 一轮周期内，无人参与游戏

游戏运行初期用户量较少，或夜间时，可能会出现这种情况

此种情况下，一轮游戏周期照常结束，奖金池100%全量转移到下一轮初始奖金池；

1.2.4.2 开奖交易和购买最后一把钥匙的交易同时到达

因为区块链系统并不记录交易发生或接收的时间，而一个交易的有效期又是客户可控的，所以需要一种机制即可以判断交易发生的时间，又可以防止参与者作弊获得奖金。

• 游戏开始时间：

  游戏开始交易打包区块的时间；

• 游戏结束判断：

  游戏开奖交易中处理，检测到上一区块的打包时间和本轮游戏中最后一个Key交易区块的打包时间间隔大于1小时；

因为定时处理机制，无法保证游戏精确到秒级开奖，所以，可能会出现1个小时的周期已经结束，但是还没有开奖，此时，如果再有买入钥匙的交易进入怎么处理？

游戏合约应当将此交易作为非法交易处理，以保证最后一把钥匙持有人的权益；

如果开奖交易和购买钥匙的交易在统一个区块内，开奖交易在前，购买钥匙的交易如何处理？

购买交易中应当包含本轮游戏的轮次数据，因为开奖交易在前，相当于本轮已经结束，购买交易也作为失败处理；

1.2.5 限制

• 游戏开始交易、开奖交易，必须由指定地址发出，其它均为非法；
• 因为游戏周期判断的需要，区块打包时间间隔不能太长，建议15秒；

consensus/ticket/ticket.go的delTicket() 偶发出现越界

问题代码文件: plugin/consensus/ticket/ticket.go
问题代码：

func (client *Client) delTicket(ticket *ty.Ticket, index int) {
	client.ticketmu.Lock()
	defer client.ticketmu.Unlock()
	//1. 结构体没有被重新调整过
	oldticket := client.tlist.Tickets[index]  // <--- 这里的index可能出现越界、过期index的情况
        ....
}

问题描述：
client.delTicket(ticket, index)的index参数通过Miner下的client.searchTargetTicket(parent, block)操作获取。
操作对象为client.tlist.Tickets， 该对象在运行过程中存在多个协程共同操作的现象，会导致client.searchTargetTicket返回的Index已经被其他协程删除、或者被调整，可能会引起数据处理错误甚至程序崩溃。