Brief of your idea
reserved contract needs initiator and auth_require field.

What could be better if XuperChain using your idea
Describe the benefits of your idea

Are there any side effects?
Describe what might be worse.

Additional information
If possible, include a minimal, complete, and verifiable example to help us identify the issue.

Brief of your idea
Currently, we can not get some key indicators of system by using xchain-cli status . For example, average confirmed delay of tx, total unconfirmed tx amount.

What could be better if XuperChain using your idea
"blockchains": [
{
"name": "xuper",
"ledger": {
.....
},
"utxo": {
......
"avgDelay": 2742,
"unconfirmed": 5
....
}
}

Are there any side effects?
No

Chinese document ?

Brief of the issue

Invoke wasm contract failed.

Your environment
XuperUnion and OS/Go/gcc version etc.

Brief of the issue
Describe here
出于什么原因选择了go内置的椭圆曲线P256？而不是比特币secp256k1或者ed25519算法？
Your environment
XuperUnion and OS/Go/gcc version etc.

Repo steps
Describe how to reproduce this issue.
文件路径crypto/client/xchain/xchain_crypto_client.go 20行
// GenerateKeyBySeed 通过随机数种子来生成椭圆曲线加密所需要的公钥和私钥
func (xcc XchainCryptoClient) GenerateKeyBySeed(seed []byte) (*ecdsa.PrivateKey, error) {
curve := elliptic.P256()
privateKey, err := utils.GenerateKeyBySeed(curve, seed)
return privateKey, err
}
Expected behaviours
Describe what you expected to happen.
出于性能还是安全性？具体考虑方向
What actually happened
Describe what actually happened. Include the full traceback if there was an exception.

Additional information
If possible, include a minimal, complete, and verifiable example to help us identify the issue. This also helps check that the issue is not with your own code.

libp2p in go.mod is too old. Can you upgrade them?

Brief of the issue
Describe here
At present, there are two identities among XChain nodes: P2P node ID and XChain address. In order to solve the identity trust between nodes and prevent man-in-the-middle attack and message tampering, an authentication mechanism is needed between nodes, which can prove that the XChain address declared by symmetric nodes are true and effective.

Your environment
XuperUnion and OS/Go/gcc version etc.

Repo steps
Describe how to reproduce this issue.

Expected behaviours
Describe what you expected to happen.
Xchain address from peer is effective

What actually happened
Describe what actually happened. Include the full traceback if there was an exception.
Network is more secure

Additional information
If possible, include a minimal, complete, and verifiable example to help us identify the issue. This also helps check that the issue is not with your own code.

Brief of the issue
Describe here
The aim of the contract is that is used to control endorsement nodes

Your environment
XuperUnion and OS/Go/gcc version etc.

Repo steps
Describe how to reproduce this issue.
First of all, User contract need to be approved by anti-yellow contract

Expected behaviours
Describe what you expected to happen.
User contract conforms to regulations.

What actually happened
Describe what actually happened. Include the full traceback if there was an exception.

Additional information
If possible, include a minimal, complete, and verifiable example to help us identify the issue. This also helps check that the issue is not with your own code.

Brief of your idea
The consensus contract return nil though it run failed. This is inconvenient for users.

What could be better if XuperChain using your idea
Return error information so that core can marked it.

是一层基于leveldb的数据表封装，还有一层是LRU缓冲？直接读取数据库表文件效率怎么样？还是维护了一个最新的UTXO表，不是账户状态机对应的最新账户库？是基于什么考虑的，选择了UTXO模型？

Brief of your idea
Add direct connections between core peers, so that core peers could send data directly to each other.

What could be better if XuperChain using your idea

1. Improve routing security, keep core network health.
2. Provide underly support for BFT-like consensus.

Are there any side effects?
No

Additional information
If possible, include a minimal, complete, and verifiable example to help us identify the issue.

Brief of the issue
Upgrade consensus, one node verification failed and walks error.The node fails due to the txid of the proposal and the txid of the vote in a block.

Your environment
XuperUnion and OS/Go/gcc version etc.

Repo steps
Describe how to reproduce this issue.
Proposal and voting time interval reduced can be reproduced

Expected behaviours
Describe what you expected to happen.
Update consensus is successful
What actually happened
Describe what actually happened. Include the full traceback if there was an exception.
TxOfRunningContractVerify fasiled when walking, err="found invalid autogen-tx" idx=0

Additional information
If possible, include a minimal, complete, and verifiable example to help us identify the issue. This also helps check that the issue is not with your own code.

The verified code commit id is 391f494
The node fails due to the txid of the proposal and the txid of the vote in a block.

Brief of your idea
Set args for reserved contracts

What could be better if XuperChain using your idea
We need to add a function to set args for reserved contracts because each contract has its respective args.

Are there any side effects?
When a contract needs to set args differing from existing function, the code has to be updated.

Brief of the issue
A node will sync block failed while a peer around it lagging behind.

Your environment
XuperUnion and OS/Go/gcc version etc.

Expected behaviours
It can synchronize to the latest height.

What actually happened
This node cannot synchronize to the latest state unless the problem node is closed.

Brief of the issue
support badger storage, log perf, async perf, p2p broadcast perf, and so on

Brief of the issue
Describe here
Judging whether the number of coinbase tx is reasonable, prevent miners from wrapping up a lot of coinbase txs and cheating on mining rewards

Your environment
XuperUnion and OS/Go/gcc version etc.

Repo steps
Describe how to reproduce this issue.
The block generated by miner can contain two coinbase txs

Expected behaviours
Describe what you expected to happen.
Just only one coinbase tx

What actually happened
Describe what actually happened. Include the full traceback if there was an exception.

Additional information
If possible, include a minimal, complete, and verifiable example to help us identify the issue. This also helps check that the issue is not with your own code.

Brief of the issue
no gofmt check in travis-ci config

Your environment
XuperUnion V3.1

Repo steps
submit new PR with code style issue, no gofmt check

Expected behaviours
code style issue could be found in CI workflow.

What actually happened
code style issue could NOT be found in CI workflow.

Additional information
None

xuperchain能跨链吗？xuperchain上的各个平行链之间数据能相互访问交互吗？如果现有的eth、eos或者fabric要和xuperchain对接该如何对接呢？

Brief of the issue
Add the function to limit the amount of same ip, including server and client limitation.

Your environment
XuperUnion and OS/Go/gcc version etc.
OS: Linux
Go: 1.12.5
gcc: g++ (GCC) 4.8.2

Expected behaviours
Describe what you expected to happen.
Limiting the amount of same ip when a new stream generated, default the limitation of same ip is 10, and you can adjust the parameter in the config file.

Brief of the issue
Currently no Chinese version of contribution guidelines.

Brief of the issue
Describe here
有一个配置问题和注释拼写错误
Your environment
XuperUnion and OS/Go/gcc version etc.

Repo steps
Describe how to reproduce this issue.
common/config/config.go 285
common/config/config.go 195
Expected behaviours
Describe what you expected to happen.
func newP2pConfigWithDefault() P2PConfig {
return P2PConfig{
...
IsNat: DefaultNetIsNat,
IsSecure: DefaultNetIsSecure,
...
}
}

// KernelConfig kernel config
What actually happened
Describe what actually happened. Include the full traceback if there was an exception.
func newP2pConfigWithDefault() P2PConfig {
return P2PConfig{
...
IsNat: DefaultNetIsNat,
IsSecure: DefaultNetIsNat,
...
}
}

// KernelConfig kerner config

Brief of the issue
Add identity contract.

Description
A reserved contract which be used for real-name authentication.

Brief of the issue
日志级别疑问,"github.com\xuperchain\log15\logger.go"文件中日志级别为:
const (
LvlCrit Lvl = iota
LvlError
LvlWarn
LvlInfo
LvlTrace
LvlDebug
)
也就是说,crit<err<warn<info<trace<debug,但在文档中5.2 配置文件说明
level : trace // 日志等级，debug < trace < info < warn < error < crit,而且阅读日志源码也有此疑问,是为了便于理解的改变?

Repo steps
https://github.com/xuperchain/log15/blob/master/logger.go 19
common/log/log.go 57 60
Expected behaviours
common/log/log.go 57 60
// prints log level between lvLevel to Info to common log
nmfileh := log.BoundLvlFilterHandler(lvLevel, log.LvlError, nmHandler)

What actually happened
按照注释的修改
// prints log level between lvLevel to Info to common log
nmfileh := log.BoundLvlFilterHandler(lvLevel,LvlInfo,nmHandler)

Brief of the issue
flags Parameters are not used ,May I delete it?

Repo steps
https://github.com/xuperchain/xuperunion/blob/e35a2156c94154232fa3bf7e78c2105675575266/cmd/xchain/xchain.go#L110

Expected behaviours
cfg.LoadConfig()

What actually happened
cfg.LoadConfig(flags)

Brief of your idea
reserved contract needs contract_names field.

What could be better if XuperChain using your idea
Describe the benefits of your idea

Are there any side effects?
Describe what might be worse.

Additional information
If possible, include a minimal, complete, and verifiable example to help us identify the issue.

先有区块链?先有比特币？两者发展局限性分析
https://mp.weixin.qq.com/s/zSQ1f9pieRh-SUqpxuKxpA
摘抄来源--微信公众号：财貌直升机

Requirements

OS Support: Linux and Mac OS
Go 1.12.x or later
G++ 4.8.x or later

编译器应该是小写g++合适吧。

Brief of the issue
version confilict，
set account method should be removed

Your environment
XuperUnion 3.1

Repo steps
Contract preExe process use the same input.
User can call set method to change account acl.

Expected behaviours
Version is not conflict, user cannot use set account method.

What actually happened

Additional information

Brief of your idea
By the current version, users can only query block by blockid, which is not so convenient.

What could be better if XuperChain using your idea
Users can do query like this: ./xchain-cli block -N 100 , then they go the 100th block on the trunk of ledger.

Are there any side effects?
need one more index in storage

Brief of the issue
autogen tx is generated by system contract, but currently there are two issues may lead to security risks:

• PostTx could accept tx with autogen=true, but this kind of tx could not pass validation on other nodes. So the data would be inconsistent on the network.

• Autogen tx not verified signature in block, this give changes to Byzantine miners to transfer xuper from any accounts.

Your environment
XuperUnion master branch

Repo steps
Use RPC posting tx with Autogen=true

Expected behaviours
Receive invalid tx error

What actually happened
miner accepted the tx, but this tx cannot pass verification on other nodes.

Additional information
If possible, include a minimal, complete, and verifiable example to help us identify the issue. This also helps check that the issue is not with your own code.

Brief of the issue
standardize the issue/PR flow:

• Now most issues does not follow the issue template.
• contributions would be better in English for communicating without barriers.

Your environment
Do not apply.

Repo steps
Do not apply.

Expected behaviours
Do not apply.

What actually happened
Do not apply.

Brief of the issue
credentials is hardcoded in crypto/account/filekey.go:120

password := "jingbo is handsome!"

go版本
1.12.5
gcc版本 7.4.0

错误如下

There should be a .gitignore to include at least build artifacts, e.g. output and plugins dir

Brief of the issue
The API of PreExecWithSelectUTXO supports only a call for the client to get the utxo for PreExec.

In the latest version, you have to have a first call of PreExec to get the amount of GasUsed and have another call of SelectUTXO to get the utxoOutput when you want to post a transaction, such as create an contract account.

However, when the API of PreExecWithSelectUTXO is available, you need only one call to finish the work above.

Brief of the issue
The reserved contracts mechanism for XuperUnion.

Your environment
OS: Linux
GO: 1.12.5
gcc: g++ (GCC) 4.8.2

Description
We want to provide a generic reserved contract mechanism. It configured by genesis block configuration. It will be invoked during pre-execution and validation.

在代码中只看到TDPOS和POW的实现，但是白皮书里描述了PBFT的实现，没有看到具体的代码

dpos我知道，这个tdpos是什么，和dpos有什么区别呢

链内并行在开源版本实现了吗？翻了一遍代码好像没看到。

简单的翻了下，没找到明确的执行器。有计划写个执行器么。

麻烦问一下，是否有整个交易流的时序图，有标记非常详细的最好了，谢谢~

Brief of the issue
Describe here
Enhance encapsulation

Your environment
XuperUnion and OS/Go/gcc version etc.

Repo steps
Describe how to reproduce this issue.

Expected behaviours
Describe what you expected to happen.

What actually happened
Describe what actually happened. Include the full traceback if there was an exception.

Additional information
If possible, include a minimal, complete, and verifiable example to help us identify the issue. This also helps check that the issue is not with your own code.

Brief of the issue
In some cases, local node may have transactions that have been unsuccessfully confirmed, such as read/write set conflicts, and so on.Therefore, there needs to be a mechanism to clean up local unconfirmed transactions that have not been successfully confirmed for a long time.The default value is 300 seconds, which can be configured in the file of xchain.yaml.

Your environment
XuperUnion and OS/Go/gcc version etc.

Repo steps
make a network of tow nodes, one is miner, the other is verify node.
Then, shutdown the miner, and submit a transaction to verify node.
Wait 300 seconds, and then restart the miner.

Expected behaviours
The previous submitted transaction should be rollback, and we can see some undo logs in xchain.log.

Brief of the issue
Currently test_write.go and test_read.go in kv/mstorage/test/ makes two main() in a single main package and GoLang will keep complaining about it. Try redesigning the testing code to avoid such a problem.

For example, maybe TestWrite(t *testing.T) & TestRead(t *testing.T) in multi_disk_storage_test.go in mstorage package under kv/mstorage

Brief of the issue
Add banning dapp contract

Your environment
XuperUnion and OS/Go/gcc version etc.
OS: Linux
GO: 1.12.5
gcc: g++ (GCC) 4.8.2

Expected behaviours
reserved contract, when banning a dapp, the dapp can't be called any more in any way until the dapp is released again.

请指点一下，看了示例合约和代码，感觉还是有状态的。

Brief of your idea
We should disable "p2p peer direct connection" by default before we do enough test on this feature.

This feature is merged in #76

Are there any side effects?
No

Additional information
If possible, include a minimal, complete, and verifiable example to help us identify the issue.

#Q go Language：deployment contract failed
Deployment code: The compiled contract is placed in the data/counter/counter directory
./xchain-cli wasm deploy --account XC1111111111111111@xuper --cname counter -H localhost:37101 -a '{"creator":"xchain"}' data/counter/counter --runtime go
error:
PreExe contract response : rpc error: code = Unknown desc = get account XC1111111111111111@xuper error: Key not found

Firstly, I executed the Create Account command../xchain-cli account new --account 1111111111111111 and returned contract response and the gas you consume is : 1000 , you need add free . Then I checked the account under data/accounts, no 1111111111111111, only the account alice and bob.
and then I executed the command : /xchain-cli acl query --account XC1111111111111111@xuper and returned null / unconfirmed . So it means ......

Brief of the issue
The timestamp of the transaction can not be trusted. And, it is set by client, but the xchain node does not verify it. Therefore, it can be fake.

Your environment
XuperUnion and OS/Go/gcc version etc.