This file contains some remarks, that occured to me during the work on this task.
After cloning the latest commit (#41a7b4b), the init.sh fails to run properly.
It claims, that the genesis file cannot be found, even though it was created in
the correct location at $HOME/.evmosd/config/genesis.json. This is, because only
the relative path (.config/genesis.json) is searched, when executing evmosd validate-genesis.
Full error:
Error: couldn't read GenesisDoc file: open config/genesis.json: no such file or
directory. Make sure that you have correctly migrated all Tendermint consensus
params, please see the chain migration guide at
https://docs.cosmos.network/master/migrations/chain-upgrade-guide-040.html for more
info
The problem above also leads to evmosd start only working from within $HOME/.evmosd,
which was not the case in the previous version (v3.0.0), that I had installed on my laptop.
The Evmos docs (https://docs.evmos.org/validators/quickstart/binary.html#config-and-data-directory) describe a way to update the location, where configuration and data storage of the node resides.
However, neither evmosd --home [directory] nor evmosd config --home [directory]
are recognized as valid commands. This should either be updated in the docs if the
command is indeed futile or made clearer in case I misunderstood the documentation.
When exporting the private key using
evmosd keys unsafe-export-eth [KEYNAME]
an error is thrown, that the key is not found even though the key is listed in the output
of evmosd keys list. This works fine when explicitly defining the keyring backend to be
used: evmosd keys unsafe-export-eth [KEYNAME] --keyring-backend=test. This is a little
unintuitive when test is defined as the keyring-backend in evmosd config. I would find
it more natural if the config was used as the default if no further flags are set.
In the documentation for the CLI commands of modules, that are directly taken from the
Cosmos SDK, the CLI commands all use simd instead of evmosd.
e.g. https://docs.evmos.org/modules/bank/06_client.html
This could be changed, in order to be consistent with the rest of the docs.
When the deployment transaction reaches the gas limit, the smart contract is
not correctly deployed. There is no code at the contract address to be found
and the transaction receipt status is 0. Even though, this is the case, the
deployment function, generated by abigen throws no error or indicates the
failed deployment in another way.
This has to be explicitly checked using the transaction receipt. The problem is described in more detail here.
Some information in the go-ethereum-book contains deprecated code
(e.g. NewKeyedTransactor instead of NewKeyedTransactorWithChainID),
as well as some examples, which could be done easier with the available
tools.
For example, https://goethereumbook.org/en/transfer-tokens/ is manually
generating the byte array for the assignment in ethereum.CallMsg. This
includes several steps like converting method names and padding byte arrays.
Meanwhile, the solidity compiler generates the getABI() function for
the binding of the compiled contract, which can be used to return the
ABI type, which itself contains the Pack-method. This can be used, to
create the neccessary byte array with a single instruction, e.g.:
data, err := maltcoinABI.Pack("transfer", recipient, amount)