coreumfoundation/coreum

coreum's Issues

coreznet tool fails to run on macOS after recent commits

> coreznet stop
> coreznet remove
> coreznet start
no sessions

Error: exit status 1:

It tries to attach to an existing session in tmux without starting the node. The logs are empty in the cache dir ~/Library/Caches/coreznet

Full trace of start -v
https://gist.github.com/xlab/348c9fd9d4309d7b1333eff147988051

Connection Refused 127.0.0.1:26657

Connections to tendermint is being refused. Picture attached for details.

error while loading shared libraries: libwasmvm.x86_64.so

What happened?

Cosmovisor verision command produces "error while loading shared libraries: libwasmvm.x86_64.so" on v0.0.1-dev.

What did you expect to happen?

null

Steps to reproduce the behavior (as precisely as possible)

Versions (please complete the following information)

cored - 624a5e0
crust - b043d34

Logs

Screenshots

Anything else we need to know?

`hermes` fails to import account created by `cored`

What happened?

I need to create a relayer with coreum, but I'm having this problem when importing a coreum account using hermes.

What did you expect to happen?

hermes will successfully import coreum's account

Steps to reproduce the behavior (as precisely as possible)

1. use cored to create account.

cored keys add keycoreum --output json > keycoreum.json

2. import this account to hermes.

hermes keys add --chain coreum-mainnet-1 --key-file keycoreum.json

Versions (please complete the following information)

cored v3.0.0

Logs

error message

➜  relayer-keys hermes keys add --chain coreum-mainnet-1 --key-file keycoreum.json
2023-11-29T14:32:04.597459Z  INFO ThreadId(01) using default configuration from '/home/ubuntu/.hermes/config.toml'
2023-11-29T14:32:04.598236Z  INFO ThreadId(01) running Hermes v1.7.2
ERROR An error occurred adding the key on chain coreum-mainnet-1 from file "keycoreum.json": mismatch between the public key in the key file and the public key in the mnemonic

Screenshots

Anything else we need to know?

Generated `gnesis.json` contains invalid address prefixes if prefixes are not set

n, _ := NetworkByChainID(Devnet)
// n.SetupPrefixes()
n.SaveGenesis(".")

If the line containing n.SetupPrefixes() stays commented, generated genesis.json uses cosmos as a prefix for addresses.
If another network was used to set prefixes up, then addresses with prefixes of that other network are stored in genesis.json.
It also means that if SetupPrefix() is called by one network, it's no longer possible to generate genesis.json for the other network because SetupPrefixes() might be called only once.

Solution

Network.EncodeGenesis() method should not use address encoder provided by cosmos-sdk because it uses global configuration.
Instead we should implement our own encoder taking prefix from the current network genesis.json is generated from.

sentry-nodes generation is weird for node '0'

On the commit 4cba343 of coreznet-benchmark branch, the command

corezstress generate --validators 3

generates weird config folder for '0'-th sentry. There is a dir priv_validator_key.json and the config dir has structure like a validator.