fetchai/fetchd

Source code for Fetch.ai blockchain nodes

Fetch.ai fetchd repository

This repository contains the source code for validators on the Fetch network. The source is based on the wasmd variant of the Cosmos-SDK, which includes a virtual machine that compiles to WebAssembly. It contains Fetch.ai-specific updates required for the test networks and future mainnet, including a decentralized random beacon (DRB) and a novel, compact multi-signatures scheme. Versions of this repository are not currently synchronised with either wasmd or the Cosmos-SDK. Please refer to the releases section for the compatibility with upstream versions.

Note: Requires Go 1.18+

Supported Systems

The supported systems are limited by the dlls created in go-cosmwasm. In particular, we only support MacOS and Linux.

Quick Start

Building and testing the project

First, install golang >= v1.18 (follow the guide from https://golang.org/dl/) and execute the following commands:

# make sure you have the following packages:
apt-get update && apt-get install -y make gcc

# install fetchd. This will output the binary in ~/go/bin/ folder by default.
make install

You should now have fetchd successfully installed in your path. You can check this with the following command:

which fetchd

This should return a path such as ~/go/bin/fetchd (might be different depending on your actual go installation).

If you get no output, or an error such as which: no fetchd in ..., possible cause can either be that make install failed with some errors or that your go binary folder (default: ~/go/bin) is not in your PATH.

To add the ~/go/bin folder to your PATH, add this line at the end of your ~/.bashrc:

export PATH=$PATH:~/go/bin

and reload it with:

source ~/.bashrc

You can also verify that you are running the correct version

fetchd version

This should print a version number that must be compatible with the network you're connecting to (see the network page for the list of supported versions per network).

Alternatively, you can also build without installing the binary with:

make build

The fetchd binary will be available under ./build/fetchd.

Run a simple local test network

The easiest way to get started with a simple network is to run the docker-compose. The details of this can be found here. By default it will launch a small 3 validator nodes network.

Resources

1. Website
2. Documentation
3. Discord Server
4. Blog
5. Community Website
6. Community Telegram Group

fetchd's Issues

Release v0.12.0

Outstanding

• cosmos/cosmos-sdk#11096

Feature request: Only mine on new transaction

Prerequisites

• I checked the documentation and made sure this feature does not already exist.
• I checked the existing issues to make sure this feature has not already been requested.

Problem

Development is very slow or very resource intensive.

If I run a local fetchd node with default (5 second) block times then it can take minutes to run through a single scenario using cosmpy. This means our integration tests can take half an hour.

If I set skip_timeout_commit = true in the config then I get much faster mining, but it quickly uses up large amounts of disc space.

Feature / Solution

I want to not mine blocks until a transaction comes in and then immediately mine (ganache does this)

Alternatives

No response

Additional Context

No response

Test v0.10.5 upgrade

Concerns

• Contract updates (things might break)
  • cosmwasm version updated
• Compile changelog

Deploy Eridanus testnet

Summary

Tracking issue for the v0.11.0 (Eridanus) ledger testnet deployment

Dependencies

• #251

fetchd tx bank send command errors when using address instead of name in --from parameter

According to the help documentation the fetchd tx bank send command accepts both the name or address of private key:
--from string Name or address of private key with which to sign

When trying to send a command using the wallet address as the from parameter, I receive the following error:
./fetchd tx bank send fetch1234567890fromaddress fetch1234567890toaddress 100000000afet
Error: The specified item could not be found in the keyring

When switching the wallet address with the name of the key, the transaction processed just fine.
./fetchd tx bank send staking.land fetch1234567890toaddress 100000000afet

Mobile SOEF on P2P_lib on 5G / modified Exposure Notifications API

Years ago people use their laptops on email that is cool.
Today, everything is mobile based.
AEA must have options to be on mobile SOEF on P2P_lib on 5G / modified Exposure Notifications API.
Such as Status, Helium for example

naming of fetchd module

Currently the module in go.mod is named github.com/Cosmwasm/wasmd but ideally would be named to this repo.

Make unbonding of entire validator stake easier via the CLI

It should be possible for the validator to be able to unbond the entirety of their stake without being required to explicitly specify what that value is

unreliable `--gas=auto` when storing contracts

When storing contracts with fetchd tx wasm store contract.wasm --gas=auto, it randomly succeeds or fails with an out of gas error. It seems the estimation from --gas=auto falls a bit short from time to time.

Feature request: Set time on local fetchd node

Prerequisites

• I checked the documentation and made sure this feature does not already exist.
• I checked the existing issues to make sure this feature has not already been requested.

Problem

I need to run integration tests on a local node and cosmpy which test things over a long time frame.

E.g. take out a loan at 10% APR. Run time forward by one year. Check the debt is exactly 10% bigger.

I can't do this at the moment,

Feature / Solution

Ganache as an option to set the next block time. This combined with only mining when transactions come in give you ver fine control over such things and I can can completely deterministic time-based integration tests.

Alternatives

No response

Additional Context

No response

v0.10.5 gives error with "max_wasm_code_size" on genesis file, doesn't sync from scratch

Prerequisites

• I am running the latest fetchd version.
• I checked the documentation and found no answer to my problem.
• I checked the existing issues to make sure my problem has not already been reported.

Expected Behavior

Using the latest genesis file: https://github.com/fetchai/genesis-fetchhub/blob/main/fetchhub-4/data/genesis_migrated_5300200.json

Renamed to genesis.json, and placed in the config/ path of the node, the output of fetchd validate-genesis genesis.json should not list any errors. A new, fresh node should be able to start syncing from this genesis file.

Current Behavior

The output of `fetchd validate-genesis is:

Error: error validating genesis file genesis.json: unknown field "max_wasm_code_size" in types.Params
Usage:
  fetchd validate-genesis [file] [flags]

Flags:
  -h, --help   help for validate-genesis

Global Flags:
      --home string         directory for config and data (default "/home/fetchd/.fetchd")
      --log_format string   The logging format (json|plain) (default "plain")
      --log_level string    The logging level (trace|debug|info|warn|error|fatal|panic) (default "info")
      --trace               print out full stack trace on errors

When starting the node, this check is also done, and the node crashes with panic message.

Partial log showing the error:

5:12PM INF ABCI Handshake App Info hash= height=0 module=consensus protocol-version=0 software-version=v0.10.5
5:12PM INF ABCI Replay Blocks appHeight=0 module=consensus stateHeight=0 storeHeight=0
5:12PM INF asserting crisis invariants inv=1/11 module=x/crisis name=distribution/nonnegative-outstanding
5:12PM INF asserting crisis invariants inv=2/11 module=x/crisis name=distribution/can-withdraw
5:13PM INF asserting crisis invariants inv=3/11 module=x/crisis name=distribution/reference-count
5:13PM INF asserting crisis invariants inv=4/11 module=x/crisis name=distribution/module-account
5:13PM INF asserting crisis invariants inv=5/11 module=x/crisis name=staking/module-accounts
5:13PM INF asserting crisis invariants inv=6/11 module=x/crisis name=staking/nonnegative-power
5:13PM INF asserting crisis invariants inv=7/11 module=x/crisis name=staking/positive-delegation
5:13PM INF asserting crisis invariants inv=8/11 module=x/crisis name=staking/delegator-shares
5:13PM INF asserting crisis invariants inv=9/11 module=x/crisis name=bank/nonnegative-outstanding
5:13PM INF asserting crisis invariants inv=10/11 module=x/crisis name=bank/total-supply
5:13PM INF asserting crisis invariants inv=11/11 module=x/crisis name=gov/module-account
5:13PM INF asserted all invariants duration=45141.050308 height=5300201 module=x/crisis
panic: unknown field "max_wasm_code_size" in types.Params
goroutine 1 [running]:
github.com/cosmos/cosmos-sdk/codec.(*ProtoCodec).MustUnmarshalJSON(0x0?, {0xc002fac000?, 0x0?, 0x0?}, {0x2507550?, 0xc022b85800?})
        github.com/cosmos/[email protected]/codec/proto_codec.go:176 +0x45
github.com/CosmWasm/wasmd/x/wasm.AppModule.InitGenesis({{}, {_, _}, _, {_, _}, {_, _}, {_, _}}, ...)
        github.com/CosmWasm/[email protected]/x/wasm/module.go:161 +0xc2

The panic does not occur on a node that already has chain data. The output of fetchd validate-genesis genesis.json does show the error there however.

To Reproduce

See above.

Context

Fetchd 0.10.5. In the above case the synced node is Ubuntu 20.04 and the fresh node is Ubuntu 22.04. I think it's unlikely that the OS version difference would cause this. I will manually get chain data to the fresh node and test whether the panic then still occurs and update this issue to confirm.

Failure Logs

No response

Release v0.10.5

This issue tracks the progress for the v0.10.5 release for the fetchd ledger.

Tasks

• #247
• #246
• fetchai/cosmos-sdk#131

Release

• Create release candidate
• Test upgrade procedure on testnet
• Create release version
• Submit governance proposal for upgrade

Potential dependency inconsistency

Dependency line:

github.com/fetchai/fetchd --> github.com/CosmWasm/wasmd --> github.com/99designs/keyring

github.com/CosmWasm/wasmd v0.27.0 --> github.com/cosmos/keyring ef00f8a

https://github.com/CosmWasm/wasmd/blob/v0.27.0/go.mod#L127

Background

Repo github.com/CosmWasm/wasmd at version v0.27.0 uses replace directive to change dependency path from github.com/99designs/keyring to github.com/cosmos/keyring.

According to Go Modules wikis, replace directives in modules other than the main module are ignored when building the main module.
It means such replace usage in dependency's go.mod cannot be inherited when building main module. And it turns out that fetchai/fetchd indirectly relies on 99designs/[email protected], which is different from the new dependency path CosmWasm/wasmd needed.

https://github.com/fetchai/fetchd/blob/master/go.mod(Line 21)

github.com/99designs/keyring v1.1.6 // indirect

https://github.com/CosmWasm/wasmd/blob/v0.27.0/go.mod(line 37&127)

github.com/99designs/keyring v1.1.6 // indirect
github.com/99designs/keyring => github.com/cosmos/keyring v1.1.7-0.20210622111912-ef00f8ac3d76

So this is just a reminder in the hope that you can notice such an inconsistency.

Solution

1. Bump the version of dependency github.com/CosmWasm/wasmd

You can try upgrading dependency github.com/CosmWasm/wasmd to a newer version, which may have eliminated the use of this directive.

2. Add the same replace rule to your go.mod

github.com/99designs/keyring => github.com/cosmos/keyring v1.1.7-0.20210622111912-ef00f8ac3d76

Malformed fetchcli request when trying to stake

I ran into an issue when trying to stake tokens on the AW1 testnet.

root@fetch:~/fetchd# fetchcli tx staking delegate fetchvaloper108hhutnylgz09acca2ljde8dp6huhsu67hn8v7 900atestfet --from agent
Enter keyring passphrase:
ERROR: cannot parse disfix JSON wrapper: json: cannot unmarshal string into Go value of type amino.disfixWrapper

My key is imported and configured properly (I'll post it anyway for the sake of completness):

root@fetch:~/fetchd# fetchcli keys list
Enter keyring passphrase:
- name: agent
  type: local
  address: fetch1yvk5jz8y4h7pftxeherf76utl6yk5mra034e2g
  pubkey: fetchpub1addwnpepq2ymtpp9a8metv3982j3kpazc842xe7r6egdxwq4frnz3rrcswn45tft9nx
  mnemonic: ""
  threshold: 0
  pubkeys: []

My best guess is that the fetchcli posts a malformed request because a similar issue has been opened in the cosmos SDK:
cosmos/cosmos-sdk#3743

root@fetch:~/fetchd# fetchcli status
{"node_info":{"protocol_version":{"p2p":"7","block":"10","app":"0"},"id":"1832bda19fed5785afcd4767f5ccdb1d9e0df601","listen_addr":"tcp://127.0.0.1:26656","network":"agentworld-1","version":"0.33.3","channels":"4020212223303800","moniker":"Bond","other":{"tx_index":"on","rpc_address":"tcp://127.0.0.1:26657"}},"sync_info":{"latest_block_hash":"C5FD08A60C49B7334AE882121FC231D04D2286029793EF530C69302A8528CED0","latest_app_hash":"0D20528BB629E75B430DCC5A3FAF4AA0FE926CF2DF4BEC3A4F8A0878CC41D415","latest_block_height":"2029362","latest_block_time":"2021-03-02T13:30:00.431689059Z","earliest_block_hash":"","earliest_app_hash":"","earliest_block_height":"0","earliest_block_time":"0001-01-01T00:00:00Z","catching_up":false},"validator_info":{"address":"D15C2986B4D68422BBF6319BFCDE1415DE370E48","pub_key":{"type":"tendermint/PubKeyEd25519","value":"46KurFbOwziJefIjS5bEDBl0NYxyuuzvt2t0ulKxa94="},"voting_power":"0"}}

root@fetch:~/fetchd# fetchcli version
0.6.1-1-g6729bba

Edit

I just tried to do a regular tx using the fetchcli and ran into the same error message.
So maybe it's an issue with my local installation but I have no clue how to tackle that problem....
---> I reinstalled go, its dependencies, and fetchcli 3 times without any success

logging level bug

Running:

➜ fetchd keys add vendor

leads to error:

Error: failed to parse log level (main:info,state:info,:error): Unknown Level String: 'main:info,state:info,:error', defaulting to NoLevel
Usage:
fetchd keys add [flags]

Can be fixed with:

➜ fetchd keys add vendor --log_level debug

make build command with errors

"make build" command returns two errors "/go/pkg/mod/github.com/fetchai/[email protected]/x/evidence/exported/evidence.go:28:2: duplicate method String"

Release v0.10.7

Summary

Tracking issue for the v0.10.7 ledger release

Outstanding Tasks

• fetchai/cosmos-sdk#133
• Release cosmos-sdk v0.18.3
• Update cosmos-sdk in fetchd
• Sanity checks on local network (optionally GKE sandbox)
  • Staking
    • Adding / removing validator
    • (Un/)Delegating
    • ...
  • Contracts
    • Store
    • Exec
  • Network upgrade procedures
    • Simulated upgrade (run new version against chain from old version)
      • Download state snapshot for testnet & mainnet to load in local node
        • modify validators
      • Run the upgrade process locally
    • Upgrade handler
    • Is there anything that node operators need to do to upgrade successfully?

Release

• Cut release candidate
• Upgrade testnet with release candidate
• Create final release
• Update testnet with production version
• Submit network upgrade proposal

Feature request: Get Stack trace on panic!()

Prerequisites

• I checked the documentation and made sure this feature does not already exist.
• I checked the existing issues to make sure this feature has not already been requested.
• I have read the code of conduct before creating this issue.

Problem

when developing and running a local node, if my code panic!() in the contract (perhaps through an unwrap or whatever) I have no idea what caused it or where it panicked.

Feature / Solution

It would be great to see the stack trace of the error somewhere.

Ideally it would be returned to the calling code, but even if it was outputed to the terminal in way that we can grep it.

Alternatives

No response

Additional Context

No response

Swagger doesn't work with fetchd v0.10.1

I've enabled swagger in app.toml and when I open http://localhost:1317/swagger/ It shows:

Errors
Hide
 
Parser error on line 5370
duplicated mapping key

Bug report: Sending transactions with block explorers on Eridanus

Prerequisites

• I am running the latest fetchd version.
• I checked the documentation and found no answer to my problem.
• I checked the existing issues to make sure my problem has not already been reported.

Expected Behavior

Users should be able to send transactions from block explorers and dapps running on the Eridanus network.

Current Behavior

@daeMOn63, can you elaborate?

To Reproduce

No response

Context

@daeMOn63, can you elaborate?

Failure Logs

No response

Mainnet contract deployment error

While trying to deploy the contract on Mainnet I'm facing this issue.

`failed to execute message; message index: 0: can not create code: unauthorized

Mainnet Tx hash : 63BC0BBC1F347BA30050B27E00DAB387CC20190F3821ACC1E77F27F78CE2887E

`

Any suggestions?

Note : Same contract deployed fine on testnet (Stage-world-3)

Bug report: Docker Image fetchai/fetchd:0.10.7 is not working with testnet Dorado "dorado-1"

Prerequisites

• I am running the latest fetchd version.
• I checked the documentation and found no answer to my problem.
• I checked the existing issues to make sure my problem has not already been reported.

Expected Behavior

I want to run a docker container with the image fetchai/fetchd:0.10.7. I have set the environment variable $NETWORK to dorado. I expect the container to start without any errors. These are the commands i am using:

docker run -e NETWORK=dorado-1 -e MONIKER=test fetchai/fetchd:0.10.7
docker run -e NETWORK=dorado -e MONIKER=test fetchai/fetchd:0.10.7

Current Behavior

After executing the docker run, i receive an error:

parse error: Expected string key before ':' at line 1, column 4

This error is caused in the entrypoint script

The script is trying to execute the following:

bootstrap_url="https://raw.githubusercontent.com/fetchai/networks-$NETWORK/feature/next/bootstrap/boostrap.json"

The URL's https://raw.githubusercontent.com/fetchai/networks-dorado/feature/next/bootstrap/boostrap.json and https://raw.githubusercontent.com/fetchai/networks-dorado-1/feature/next/bootstrap/boostrap.json do not exist, which causes the error.

To Reproduce

Execute the following:

docker run -e NETWORK=dorado -e MONIKER=test fetchai/fetchd:0.10.7
docker run -e NETWORK=dorado-1 -e MONIKER=test fetchai/fetchd:0.10.7

Context

• Using Docker Image fetchai/fetchd:0.10.7
• Using Dorado Testnet

Failure Logs

See above

Bug report: Events from multiple contracts not returned correctly

Prerequisites

• I am running the latest fetchd version.
• I checked the documentation and found no answer to my problem.
• I checked the existing issues to make sure my problem has not already been reported.

Expected Behavior

When a contract calls another contract, we should be able to determine which emitted events come from which contract.

Current Behavior

Here is a transaction where one contract has called another (and maybe that called another one)- they all emit events.

Type this:
fetchd query tx --type hash EA8C0B4DF96C9E2A6D62F51FEFFFF9DFD23E25841E7D0CA23F180F85A58E7797

Look at the raw_log
Formatted in python with pprint we get:

[{'events': [{'attributes': [{'key': '_contract_address',
                              'value': 'fetch1k4x9c4qp5f2dtdrlxw2yk4ahksytw3tnpvcsg4zf6zftdukxt20q7lqgyd'},
                             {'key': '_contract_address',
                              'value': 'fetch1skemrn8c44vh8k5rag8rgfzus9w6ngptqpdyk4d2q3mg23mlljnq0nqmu2'},
                             {'key': '_contract_address',
                              'value': 'fetch1h3er28zy2pnrcc2vld4sk4wj2pjzu2tndyfy2apfp8cutr0cz5usggk36u'},
                             {'key': '_contract_address',
                              'value': 'fetch1skemrn8c44vh8k5rag8rgfzus9w6ngptqpdyk4d2q3mg23mlljnq0nqmu2'}],
              'type': 'execute'},
             {'attributes': [{'key': 'action',
                              'value': '/cosmwasm.wasm.v1.MsgExecuteContract'},
                             {'key': 'module', 'value': 'wasm'},
                             {'key': 'sender',
                              'value': 'fetch1kc07mf256cy244r4t3vxsth9gfcay8pxmgneap'}],
              'type': 'message'},
             {'attributes': [{'key': '_contract_address',
                              'value': 'fetch1k4x9c4qp5f2dtdrlxw2yk4ahksytw3tnpvcsg4zf6zftdukxt20q7lqgyd'},
                             {'key': 'token_id', 'value': 'token_id_2'},
                             {'key': '_contract_address',
                              'value': 'fetch1skemrn8c44vh8k5rag8rgfzus9w6ngptqpdyk4d2q3mg23mlljnq0nqmu2'},
                             {'key': 'action', 'value': 'transfer'},
                             {'key': 'token_id', 'value': 'token_id_2'},
                             {'key': 'amount', 'value': '1000000000000000000'},
                             {'key': 'to',
                              'value': 'fetch1fty4wekjea7ndy6auax70736hkyqvqf3h29thz'},
                             {'key': '_contract_address',
                              'value': 'fetch1h3er28zy2pnrcc2vld4sk4wj2pjzu2tndyfy2apfp8cutr0cz5usggk36u'},
                             {'key': 'action', 'value': 'update_asset'},
                             {'key': 'id', 'value': '2'},
                             {'key': 'borrower',
                              'value': 'fetch1fty4wekjea7ndy6auax70736hkyqvqf3h29thz'},
                             {'key': 'denomination', 'value': 'GBP'},
                             {'key': 'description', 'value': 'test asset01'},
                             {'key': 'fixed_fee', 'value': '0'},
                             {'key': 'fixed_recovery_costs', 'value': '0'},
                             {'key': 'guaranteed_recovery_ratio',
                              'value': '70'},
                             {'key': 'max_rate_bias', 'value': '0'},
                             {'key': 'max_recovery_time', 'value': '12'},
                             {'key': 'valuation_duration', 'value': '1'},
                             {'key': 'value', 'value': '100000'},
                             {'key': 'create_time', 'value': '1651835581'},
                             {'key': 'status', 'value': 'Secured'},
                             {'key': 'trustee',
                              'value': 'fetch1kc07mf256cy244r4t3vxsth9gfcay8pxmgneap'}],
              'type': 'wasm'}]}]

The event data is not split into seperate events - it is just a list of key-value pairs. At the moment, we are just seperating them by assuming that when there is a "_contract_address" key then this is the start of a new event...but is this valid? Can someone mess things up by emitting an event from a contract with a key _contract_address and spoof the indexer (for example) into thinking that the even has come from another contract?

To Reproduce

Se above

Context

Mac OS pointing at Dorado

Failure Logs

No response

Error when querying for validators

I've just installed fetchd and get an error when executing a command to get the validators

Command:
fetchd query staking validators

Error:
Error: error unmarshalling result: unknown field "proof" in types.ResponseQuery

Fetchd version:
fetchd version --long

name: fetch
server_name: <appd>
version: 0.8.1-4-g4b7f792
commit: 4b7f792375bb17a91a34b49bd006d7c831d35c8c
build_tags: netgo,ledger
go: go version go1.16.5 linux/amd64

Steps to reproduce the error:

mkdir ~/fetch && cd ~/fetch
git clone https://github.com/fetchai/fetchd.git && cd fetchd
make build
make install
fetchd query staking validators

Axelar bridge update incident response

New IBC client and governance proposal

Feature request: <Dünyada insan eliyle yapılan yapı ve eserler ve kalıntıları>

Prerequisites

• I checked the documentation and made sure this feature does not already exist.
• I checked the existing issues to make sure this feature has not already been requested.

Problem

Dünyanın Arkeolojik kalıntılarının envanter kayıtlarının tutulması.

Feature / Solution

Dünyanın bir çok bölgesinde insanlığın geçmiş yaşam izlerinin, kültür kalıntılarının kronolojik olarak listelenmesini sağlamak.

Alternatives

Arkeoloji alanında bilimsel araştırmaları sürdüren tüm bilim insanlarının yaptığı çalışmaları kayıt altına almak ve kültürel kalıntıların kronolojisi ile birlikte yapılan çalışmalarında kronolojik olarak sıralanmasını sağlamak.

Additional Context

Çalışmalarını buraya ekleyen her Araştırmacıdan istenecek tek belgenin Lisans Diploması sunması gerekliliği.

Davletuner Test

Test for Beacon 1

Invalid cli flag in docs: Importing a private key generated from the Agent Framework

In the docs/docs/cli-keys documentation, the example cli command given to import private key generated from the Agent Framework:

fetchd keys import --agent-raw-key <name of the new key> <path to the key file>

results to an error because the flag --agent-raw-key is invalid.

Error:

Error: unknown flag: --agent-raw-key
Usage:
  fetchd keys import <name> <keyfile> [flags]

Flags:
  -h, --help   help for import

Global Flags:
      --home string              The application home directory (default "/home/user/.fetchd")
      --keyring-backend string   Select keyring's backend (os|file|test) (default "os")
      --keyring-dir string       The client Keyring directory; if omitted, the default 'home' directory will be used
      --log_format string        The logging format (json|plain) (default "plain")
      --log_level string         The logging level (trace|debug|info|warn|error|fatal|panic) (default "info")
      --output string            Output format (text|json) (default "text")
      --trace                    print out full stack trace on errors

Using version 0.8.7

$ fetchd version
0.8.7

Add new faucets' details to the documentation

There are new faucets. Message from Ian:

I've modified the token faucet app so that it can provide tokens other than fet (or, more pedantically, provide tokens other than those in which it's paying the gas), and spun up separate faucets for each denom in the dorado testnet...
get some atestfet (no change here!)
curl -X POST -H 'Content-Type: application/json' -d '{"address":"fetch1tester2p8g2726furxwl7kvmxu49et7vd8ucum"}' https://faucet-dorado.fetch.ai/api/v3/claims

get some nanomobx
curl -X POST -H 'Content-Type: application/json' -d '{"address":"fetch1tester2p8g2726furxwl7kvmxu49et7vd8ucum"}' https://faucet-mobx-dorado.fetch.ai/api/v3/claims

get some ulrn
curl -X POST -H 'Content-Type: application/json' -d '{"address":"fetch1tester2p8g2726furxwl7kvmxu49et7vd8ucum"}' https://faucet-lrn-dorado.fetch.ai/api/v3/claims

results in...
fetchd query bank balances fetch1tester2p8g2726furxwl7kvmxu49et7vd8ucum
balances:

• amount: "10000000000000000000"
  denom: atestfet
• amount: "1000"
  denom: nanomobx
• amount: "1000"
  denom: ulrn
  https://explore-dorado.t-v3-london.fetch-ai.com/account/fetch1tester2p8g2726furxwl7kvmxu49et7vd8ucum

Add these details to the documentation.

fetchd query wasm list-code --log_format json prints output in plain text instead of json

I am running local-net using fetchd in feature/stargate branch

fetchd query wasm list-code --log_format json
code_infos:
- builder: ""
  code_id: "1"
  creator: fetch1a3n8ndap8xd37vwljthv8sdsk6d7xx9mwfhq7n
  data_hash: 4D3A9F90A8E46925DE05A5B03533DD0A89AF49232E8071C6BF3BC0B0BC833F72
  source: ""
pagination:
  next_key: null
  total: "0"

daemon stopped at 116263 height

fetchd[4842]: panic: Failed to process committed block (116263:BB091EED72F1E54FCC1E8AB65F3502319327418576656592D4F59FE7BF200820): wrong Block.Header.AppHash. Expected DD2A6C7057BED250C67D814A7166980701C1106A52CD898297F81155446ABC36, got 38B5599B7EABA50564D660DB12B51A115813416D341D779F341084EB1F7058D7

Apr 08 19:58:59 systemd[1]: Started Fetch Validator.
Apr 08 19:58:59 fetchd[5804]: I[2021-04-08|19:58:59.736] starting ABCI with Tendermint module=main
Apr 08 19:59:00 fetchd[5804]: ERROR: error during handshake: error on replay: wrong Block.Header.AppHash. Expected DD2A6C7057BED250C67D814A7166980701C1106A52CD898297F81155446ABC36, got 38B5599B7EABA50564D660DB12B51A115813416D341D779F341084EB1F7058D7
Apr 08 19:59:00 systemd[1]: fetchd.service: Main process exited, code=exited, status=1/FAILURE
Apr 08 19:59:00 systemd[1]: fetchd.service: Failed with result 'exit-code'.
Apr 08 19:59:01 systemd[1]: Stopped Fetch Validator.

fetchd version --long
name: fetch
server_name: fetchd
client_name: fetchcli
version: 0.7.2
commit: f49ffed
build_tags: netgo,ledger
go: go version go1.15.6 linux/amd64

unsafe-reset-all didnt helped

Block time is incorrect if mining interval is less than 1

Prerequisites

• I am running the latest fetchd version.
• I checked the documentation and found no answer to my problem.
• I checked the existing issues to make sure my problem has not already been reported.

Expected Behavior

I expect the block.time.seconds() to go up about 1 every second

Current Behavior

If I run the node replacing 5 in the timeout_commit config with 0.25, then time rises about twice as quickly as realtime in the contracts. My initialisation script does this:
sed -i 's/timeout_commit = "5s"/timeout_commit = "0.25s"/g' ~/.fetchd/config/config.toml

prior to calling fetchd start

I then ran a python script which every second queried a contract which returned the block.time. This is the table:

Rust: env.block.time.seconds(), Python time.time()
0.0, 0.0
3.0. 1.0
5.0, 2.0
7.0. 3.0
9.0. 4.0
11.0, 5.0
13.0, 6.0
15.0, 7.0
17.0, 8.0
19.0, 9.0

You can see that the contract time rises about twice as fast as the realtime (measured in python).

This is only an issue when the timeout_commit time is < 1. However, this is kind of crucial for us otherwise development becomes impossibly slow.

To Reproduce

Talk to Diarmid and I can point you to code.

Context

OSX
Fetchd version (docker image) image: fetchai/fetchd:0.9.0-rc4

Failure Logs

No response

Feature request: Get stack trace from returned contract errors

Prerequisites

• I checked the documentation and made sure this feature does not already exist.
• I checked the existing issues to make sure this feature has not already been requested.
• I have read the code of conduct before creating this issue.

Problem

When my contracts return an error to cosmpy, then I often see the error message but have no idea where it arose (not even which contract it came from - as it could have come from a contract calling another contract etc.)

Feature / Solution

I'd like to run a local node with an option to return the stack trace on error.

Alternatives

No response

Additional Context

No response

storing contract with `--gas-adjustment` flag doesn't broadcast tx

when storing contract with something like:

fetchd tx wasm store contract.wasm --from mykey --gas=auto --gas-adjustment=1.2 

it produces a successful output similar to:

{"height":"0","txhash":"TXHASH","codespace":"","code":0,"data":"","raw_log":"[]","logs":[],"info":"","gas_wanted":"0","gas_used":"0","tx":null,"timestamp":""}

but the query can't be found on the chain:

fetchd query tx TXHASH
Error: RPC error -32603 - Internal error: tx (TXHASH) not found

Removing the --gas-adjustment flag then works (either successfully storing the contract or failing with an "out of gas" error, as --gas=auto seems to underestimate sometimes)

Release v0.11.0 (Eridanus)

Summary

Tracking issue for the v0.11.0 (Eridanus) ledger release

Outstanding Tasks

• cosmos/cosmos-sdk#12111
• fetchai/cosmos-sdk#143
• fetchai/cosmos-sdk#145

Release

• Create intital betas
• Launch beta testnet
• Cut release candidate
• Upgrade testnet with release candidate
• Create final release
• Update testnet with production version
• Submit network upgrade proposal

Bug report: "fetchd tx distribution set-withdraw-address" fails

Prerequisites

• I am running the latest fetchd version.
• I checked the documentation and found no answer to my problem.
• I checked the existing issues to make sure my problem has not already been reported.

Expected Behavior

fetchd tx distribution set-withdraw-address <wallet> --from <key> should allow to specify the address where the staking rewards are withdrawn (the command works on other chains).

Current Behavior

The command fails with 'failed to execute message; message index: 0: set withdraw address disabled'

To Reproduce

No response

Context

running this command on any node, validator or not (fetchd latest version)

Failure Logs

No response

issue with agent-land network

This might not be the right repo to mention regarding the Agent-Land testnet but I have already raised my issue over there and realized nothing much going on in there (no engagement).

The issue is that the agent-land network seem to have problems generating funds for fetchai user, both over CLI and website "https://explore-agent-land.fetch.ai/". Anyone over here happen to know anything about this?

I like the project and want fetch to succeed but the lack of info and guides for devs makes it hard to fully utilize fetch's capabilities.

Bug report: Unable to generate the expected addresses for Injective

Prerequisites

• I am running the latest fetchd version.
• I checked the documentation and found no answer to my problem.
• I checked the existing issues to make sure my problem has not already been reported.

Expected Behavior

Injective support was added by the developer of bip_utils, which now allows to generate the expected addresses from a mnemonic.

from cosmpy.aerial.wallet import LocalWallet
from cosmpy.crypto.keypairs import PrivateKey, PublicKey
from bip_utils import Bip39SeedGenerator, Bip44, Bip44Coins

mnemonic = "24 WORDS HERE"
seed_bytes = Bip39SeedGenerator(mnemonic).Generate()

bip44_mst_ctx = Bip44.FromSeed(seed_bytes, Bip44Coins.INJECTIVE)
bip44_acc_ctx = bip44_mst_ctx.Purpose().Coin().Account(0)
bip44_chg_ctx = bip44_acc_ctx.Change(Bip44Changes.CHAIN_EXT)

bip44_addr_ctx = bip44_chg_ctx.AddressIndex(0)   #index 0 appears to be the right one here

print(bip44_addr_ctx.PublicKey().ToAddress())  # --> CORRECT ADDRESS

print(LocalWallet(PrivateKey(bip44_addr_ctx.PrivateKey().Raw().ToBytes()), prefix='inj')) #--> WRONG ADDRESS

The above is expected to print the same address twice.

Current Behavior

Using LocalWallet the generated address is incorrect.
This seems to be related to the fact that Cosmpy uses the Atom address encoder.

Running this code generates the same address than LocalWallet:

from bip_utils import AtomAddrEncoder

print(AtomAddrEncoder.EncodeKey(
    bip44_addr_ctx.PublicKey().Bip32Key().KeyObject(),
    hrp="inj"
))

To Reproduce

No response

Context

Tested on Ubuntu 23.04 with python3.11 and latest Fetchd and bip_utils.

Do you know of a workaround to this issue?

Failure Logs

No response

Node startup failed

I failed to start node with v0.10.2 version
I use this genesis file 【https://raw.githubusercontent.com/fetchai/genesis-fetchhub/main/fetchhub-4/data/genesis_migrated_5300200.json】

Make specifying whole FET easier via the command line tool

The current implementation of the CLI requires the user to specify values in terms of the base unit i.e. atestfet. 10^-18.

This is cumbersome and more importantly error prone. It should be possible to specify these values as whole FET.

Bug report: Fetchd node is not syncing without snapshot with Dorado Testnet

Prerequisites

• I am running the latest fetchd version.
• I checked the documentation and found no answer to my problem.
• I checked the existing issues to make sure my problem has not already been reported.

Expected Behavior

I want to run a fetchd node with version 0.10.7 on Dorado Testnet. I am executing the following commands:

fetchd init my-first-fetch-node --chain-id dorado-1

# Downloading genesis-dorado-testing.json because of bug #285
curl https://storage.googleapis.com/fetch-ai-testnet-genesis/genesis-dorado-testing.json --output ~/.fetchd/config/genesis.json

fetchd start --p2p.seeds=[e-mail]:36556,[email protected]:36557,[email protected]:36558

The genesis file is different from what the documentation mentions, as a workaround for bug #285.

After executing these commands, I expect the node to be syncing and to be showing logs like this at some point:

1:43PM INF minted coins from module account amount=5686072173522214069atestfet from=mint module=x/bank
1:43PM INF executed block height=7459287 module=state num_invalid_txs=0 num_valid_txs=0
1:43PM INF commit synced commit=436F6D6D697449447B5B37203133332032333820323434203635203938203830203139352031303220313435203135362031353420323220323239203134382033312034362031393420383820323034203439203137322039362034332031303120323133203132352034352031363920313535203837203230375D3A3731443144377D
1:43PM INF committed state app_hash=0785EEF4416250C366919C9A16E5941F2EC258CC31AC602B65D57D2DA99B57CF height=7459287 module=state num_txs=0
1:43PM INF indexed block height=7459287 module=txindex

Current Behavior

After running the command mentioned above, I am running into the following errors:

9:41AM ERR Error in validation err="wrong Block.Header.AppHash.  Expected 3D16786E814F718C3A359F4D2A5B6AD2D762393A59937B8EA267E684BF130F83, got 01BF3A3289F0AC78F950B8F6BE8F144AD33F4A74D0336D412778F5239B8BBCBD" module=blockchain
9:41AM ERR Stopping peer for error err="blockchainReactor validation error: wrong Block.Header.AppHash.  Expected 3D16786E814F718C3A359F4D2A5B6AD2D762393A59937B8EA267E684BF130F83, got 01BF3A3289F0AC78F950B8F6BE8F144AD33F4A74D0336D412778F5239B8BBCBD" module=p2p peer={"Data":{},"Logger":{}}

Interestingly, when using a Snapshot, everything works fine:

fetchd init my-first-fetch-node --chain-id dorado-1

# Downloading genesis-dorado-testing.json because of bug #285
curl https://storage.googleapis.com/fetch-ai-testnet-genesis/genesis-dorado-testing.json --output ~/.fetchd/config/genesis.json

# Downloading Dorado Snapshot
curl -v https://storage.googleapis.com/fetch-ai-testnet-snapshots/dorado-pruned.tgz -o- 2>headers.out | gunzip -c | tar -xvf - --directory=/root/.fetchd

fetchd start --p2p.seeds=[e-mail]:36556,[email protected]:36557,[email protected]:36558

To Reproduce

1. Make sure to have a completely clean state for fetchd. No config or anything else should exist.
2. Execute the following commands:

fetchd init my-first-fetch-node --chain-id dorado-1

# Downloading genesis-dorado-testing.json because of bug #285
curl https://storage.googleapis.com/fetch-ai-testnet-genesis/genesis-dorado-testing.json --output ~/.fetchd/config/genesis.json

fetchd start --p2p.seeds=[e-mail]:36556,[email protected]:36557,[email protected]:36558

Context

Using Docker Image fetchd:0.10.7 with overwritten entrypoint. All commands executed inside the container.
Result should be the same without Docker.

Failure Logs

See above.

Broadcast transaction got Error

Hi, I broadcast FET tx got error since yesterday, the error is Error: Error: 0ufet is smaller than 20ufet: insufficient funds: insufficient funds, but my sender's address has FETs in it, is there some upgrade?
Transaction hex is
0a8a010a87010a1c2f636f736d6f732e62616e6b2e763162657461312e4d736753656e6412670a2c6665746368316335396c35326138613733667366776138677233786e7275373237327871333865336c743365122c66657463683161393667346d73777737356d35636d707a39337561726a3978796630376b766b776d6636346c1a090a047566657412013812640a500a460a1f2f636f736d6f732e63727970746f2e736563703235366b312e5075624b657912230a21035a27b3564c6a08337ba07f8120551d5721e9ae888bcd60df705de7509d2bc73d12040a020801180a12100a0a0a04756665741202323010c09a0c1a408438798a3cb2123234b127db64352898a207cd447c9c4b49b8b3a775989c1ae200b154d48c0d390d8aa7594b0cd8898ca0ae89e3bea97efbf4981e22fd02e1a4

sender: fetch1c59l52a8a73fsfwa8gr3xnru7272xq38e3lt3e