On the current testnet (gravity-bridge-test{1..4}), my validator is not able to withdraw rewards or commission, but is able to successfully send other transactions like transferring tokens.

withdrawing:

./gravity tx distribution withdraw-rewards gravityvaloper156n6x0hvfd2zxq5vhehp2e20mz6tdskhhqxhm9 --commission --from validator --keyring-backend pass
{"body":{"messages":[{"@type":"/cosmos.distribution.v1beta1.MsgWithdrawDelegatorReward","delegator_address":"gravity156n6x0hvfd2zxq5vhehp2e20mz6tdskhxtlf33","validator_address":"gravityvaloper156n6x0hvfd2zxq5vhehp2e20mz6tdskhhqxhm9"},{"@type":"/cosmos.distribution.v1beta1.MsgWithdrawValidatorCommission","validator_address":"gravityvaloper156n6x0hvfd2zxq5vhehp2e20mz6tdskhhqxhm9"}],"memo":"","timeout_height":"0","extension_options":[],"non_critical_extension_options":[]},"auth_info":{"signer_infos":[],"fee":{"amount":[],"gas_limit":"200000","payer":"","granter":""}},"signatures":[]}

confirm transaction before signing and broadcasting [y/N]: y
{"height":"29485","txhash":"A612BAF0FB4B6A46D4DF51ADE93C746BF35366408A75A5CA2E0AEB2653F75180","codespace":"undefined","code":111222,"data":"","raw_log":"panic message redacted to hide potentially sensitive system info: panic","logs":[],"info":"","gas_wanted":"200000","gas_used":"97657","tx":null,"timestamp":""}

transferring:

./gravity tx bank send validator gravity15lpnf70ycjxyhhjysmlkm6k4uf0sm220ftqy79  1000000ugraviton --keyring-backend pass
{"body":{"messages":[{"@type":"/cosmos.bank.v1beta1.MsgSend","from_address":"gravity156n6x0hvfd2zxq5vhehp2e20mz6tdskhxtlf33","to_address":"gravity15lpnf70ycjxyhhjysmlkm6k4uf0sm220ftqy79","amount":[{"denom":"ugraviton","amount":"1000000"}]}],"memo":"","timeout_height":"0","extension_options":[],"non_critical_extension_options":[]},"auth_info":{"signer_infos":[],"fee":{"amount":[],"gas_limit":"200000","payer":"","granter":""}},"signatures":[]}

confirm transaction before signing and broadcasting [y/N]: y
{"height":"14131","txhash":"64FD8BDD953639CA0CB15CFBCF6A61B3028279F4A552ABBC075221F0E0D68563","codespace":"","code":0,"data":"0A1E0A1C2F636F736D6F732E62616E6B2E763162657461312E4D736753656E64"...

I was able to change my commission and withdraw once (maybe during gravity-bridge-test1 or gravity-bridge-test2), but something happened and I'm not able to anymore.

I am able to withdraw as a different delegator to my validator:

./gravity tx distribution withdraw-rewards gravityvaloper156n6x0hvfd2zxq5vhehp2e20mz6tdskhhqxhm9 --from mine --keyring-backend pass
Default sign-mode 'direct' not supported by Ledger, using sign-mode 'amino-json'.
{"body":{"messages":[{"@type":"/cosmos.distribution.v1beta1.MsgWithdrawDelegatorReward","delegator_address":"gravity1pqk05hdkyhlvj07tept96cwa3fj7axasq8cg0h","validator_address":"gravityvaloper156n6x0hvfd2zxq5vhehp2e20mz6tdskhhqxhm9"}],"memo":"","timeout_height":"0","extension_options":[],"non_critical_extension_options":[]},"auth_info":{"signer_infos":[],"fee":{"amount":[],"gas_limit":"200000","payer":"","granter":""}},"signatures":[]}

confirm transaction before signing and broadcasting [y/N]: y
{"height":"35806","txhash":"65A5654C7D0F79AE6FB67DBE4D8F0B5226E71A81BFBB3C7A972AA50EE65E6381","codespace":"","code":0,"data":"0A390A372F636F736D6F732E646973747269627574696F6E2E763162657461312E4D7367576974686472617744656C656761746F72526577617264",

This PR changes the underlying object for EthAddress from string to geth's Address. It also contains the necessary migrations to use the address' bytes instead of the hex representation in keys.

Closes #85

This PR addresses 2 issues:

~- ETH addresses are now required to be checksummed (these means all ETH addresses). This might be an issue for already running chains if relayers don't send all of the addresses in the compliant format.~

[email protected] this might be a change too drastic if there are any eth addresses in the store that aren't well-formatted, I think we are good on Umee's side because we use geth's common package for addresses. This might also break some of your shell tests~

• Accept confirms only from bonded or unbonding validators

• Don't panic when prepping the confirms for slashing if it can't find a validator

These last 2 are in the first 2 commits if you want to check them with less background noise.

EDIT: Removed Eth address related changes to make a better fix in a separate PR

The change in this PR solves the problem of submitting claims with unordered event nonce. This can happen if the last_checked_event on the orchestrator side is set to 'n' and in the next iteration when check_for_events is called, there is event with the nonce 'n+1' that should be submitted but in the meantime the governance vote reset the last event nonce by the validator to 'n-1' on the chain side. check_for_events will try to submit event with nonce 'n+1' to the chain where last submitted nonce is set to 'n-1' and that will fail. Before this fix there was no recovery from this scenario because the last_checked_block was reset only if check_for_events returns successful result and the last event nonce on orchestrator was greater than the last event nonce on the chain side. This check if last_checked_block should be adapted in order to replay old events is now moved before check_for_events.

I started working on the ERC 721 transfer PR here, at this stage I just set up a skeleton structure that I will override when I know more clearly what to update.

As far as I understand right now, we essentially just need to take the send_to_cosmos and change it from this:

	function sendToCosmos(
		address _tokenContract,
		string calldata _destination,
		uint256 _amount
	) 

to this:

	function sendToCosmos(
		address _tokenContract,
		string calldata _destination,
		uint256 tokenId
	) 

And then in the code, use ERC721 instead of ERC20 wherever we are interacting with ETH.

Problem: Running bash tests/all-up-test.sh on a Mac with Apple M1 Max processor. Getting error message that eth image can not be found and then failing setup.

qemu-x86_64: Could not open '/lib64/ld-linux-x86-64.so.2': No such file or directory

Solution: There are 3 bash scripts that need to be updated:

• tests/all-up-test.sh
• tests/build-container.sh
• tests/start-chains.sh

In each of these scripts I put an if branch on if Mac OS and M1 processor then append --platform=linux/amd64 to docker run. Linux users should see no change with this PR

Additional findings: There is a "Docker not found" error when running ./start-chains.sh

/usr/bin/which: no docker in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/go/bin:/usr/local/go/bin)

It seems like the script still runs to success, however if we want to additionally fix this we can add the following to container-scripts/reload-code.sh before the Make command:

sudo dnf -y install dnf-plugins-core
sudo dnf -y config-manager \
    --add-repo \
    https://download.docker.com/linux/fedora/docker-ce.repo
sudo dnf -y install docker-ce docker-ce-cli containerd.io

When building a batch, transactions are first collected from the outgoing transaction pool in order to calculate the total bridge fee and check if a more profitable batch of the same token type already exists in the pool. When doing this, there is no check if the translation’s destination address is included in the blacklist or not. Later, when transactions are collected to be included in the batch, additional blacklist filtering is applied. This can cause potential creation of the less profitable batch than the one of the same token type with the biggest nonce already in the pool. Also, the double retrieval of the calculations seems unnecessary.

If a user/app wants to use the gravity bridge (module) as a dependency, they currently have to rely on a git hash. e.g. https://github.com/umee-network/umee/pull/369/files#diff-33ef32bf6c23acb95f5902d7097b7a1d5128ca061167ec0716715b0b9eeaa5f6

I believe the top-level/root package needs to include a go.mod and that go.mod needs to include the sub-module. e.g. https://github.com/PeggyJV/gravity-bridge/blob/main/go.mod

This way, users can import the module via the semantic version 👍

This PR includes the following changes:

1. Store key prefixes are changed from strings to hashed strings (e.g. "ValsetRequestKey" -> HashFunc("ValsetRequestKey")). Methods for creating keys in key.go now use and return []byte, thus avoiding unnecessary string[]byte conversions. Some keys were not used anywhere, so we removed them.
2. Method ConvertByteArrToString() is no longer used in key creation, except in one place. This method produces bad results in cases when the highest bit in any of input bytes is set to 1. This results in one byte sometimes being converted into two bytes when casting back to bytes to create the key (e.g. []byte(ConvertByteArrToString(inputBytes)). Also, []byte can be directly casted into string so the method is redundant. The only place we had to keep this method is for the PastEthSignatureCheckpointKey, since the key was constructed from the prefix concatenated with ConvertByteArrToString(checkpoint). Since the checkpoint is 32 bytes long, if any of bytes had the highest bit set to 1 it would be converted to two bytes so the key length could be len(PastEthSignatureCheckpointKey) plus 32 to 64 bytes depending on the checkpoint content. Converting variable number of bytes back to correct 32 bytes isn't possible because we can't know which bytes are "real" and which ones are added as a result of running ConvertByteArrToString(). And since the value stored under the key is 0 or 1 we couldn't reconstruct the key from the value during store migrations, so we had to keep the method, but we made it unexported and added comment that it shouldn't be used anywhere except in this case.
3. Store migrations are written to migrate all keys from strings to hashed strings, while keeping the old values. Keys created with unused prefixes will be removed from the store during migration, if such values existed at all.
4. Chain upgrade handler is added in app.go. We named this initial upgrade handler "v1.5" since Justin mentioned that the next release of Gravity Bridge will be 1.5. Is this OK to you?

Allows users a bit more filtering control over getting attestations. Such possible queries include:

• query_attestations
• query_attestations?limit=100
• query_attestations?limit=100&order_by=asc|desc
• query_attestations?claim_type=foo&limit=100&order_by=asc|desc
• query_attestations?nonce=40
• query_attestations?height=999

Also fixes IterateAttestaions typo

closes: #102

• Updates the following batch related gRPC service URLs so they don't clobber with the other batch related URLs:
  • /gravity/v1beta/batch/{address} -> /gravity/v1beta/batch/last_pending_request_by_addr
  • /gravity/v1beta/batch/{nonce} -> /gravity/v1beta/batch/request_by_nonce
• Just a tad bit of linting cleanup :)

closes: #94

Hi, I'm trying to index balances of the gravity accounts. What I found out was that bridged token balances sometimes just 'dissappear' or are at least not handled in the same manner as with ibcs and native coin.

Example: Querying AllBalances for gravity16n3lc7cywa68mg50qhp847034w88pntqzx3ksm at height 4282575 gives me balances below:

 [
	{
	  "denom": "gravity0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48",
	  "amount": "5841000000"
	},
	{
	  "denom": "gravity0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2",
	  "amount": "2000000000000000000"
	},
	{
	  "denom": "ibc/00F2B62EB069321A454B708876476AFCD9C23C8C9C4A5A206DDF1CD96B645057",
	  "amount": "5536599288408"
	},
	{
	  "denom": "ibc/048BE20AE2E6BFD4142C547E04F17E5F94363003A12B7B6C084E08101BFCF7D1",
	  "amount": "505041821965"
	},
	{
	  "denom": "ibc/0C273962C274B2C05B22D9474BFE5B84D6A6FCAD198CB9B0ACD35EA521A36606",
	  "amount": "49379350709481"
	},
	{
	  "denom": "ibc/29A7122D024B5B8FA8A2EFBB4FA47272C25C8926AA005A96807127208082DAB3",
	  "amount": "1501500"
	},
	{
	  "denom": "ibc/2E5D0AC026AC1AFA65A23023BA4F24BB8DDF94F118EDC0BAD6F625BFC557CDED",
	  "amount": "309235788"
	},
	{
	  "denom": "ibc/406662DF40CFFCE3BBB80B2A2A7D476830C166981B14E18D8DD7446BB529377D",
	  "amount": "10500000000000000000"
	},
	{
	  "denom": "ibc/4F393C3FCA4190C0A6756CE7F6D897D5D1BE57D6CCB80D0BC87393566A7B6602",
	  "amount": "155120908"
	},
	{
	  "denom": "ibc/5012B1C96F286E8A6604A87037CE51241C6F1CA195B71D1E261FCACB69FB6BC2",
	  "amount": "2765691214888000"
	},
	{
	  "denom": "ibc/D956638E52570976F762354757863F60F2AFE4879E849CB1C77B163F0BF11C64",
	  "amount": "200002"
	},
	{
	  "denom": "ibc/F85BE85916DBE4721AC3CC9973925553B49171181C7A6096B798757833A1E79F",
	  "amount": "83000001"
	}
]

While querying height 4282576 (next one) :

[
	{
	  "denom": "gravity0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2",
	  "amount": "2000000000000000000"
	},
	{
	  "denom": "ibc/00F2B62EB069321A454B708876476AFCD9C23C8C9C4A5A206DDF1CD96B645057",
	  "amount": "5536599288408"
	},
	{
	  "denom": "ibc/048BE20AE2E6BFD4142C547E04F17E5F94363003A12B7B6C084E08101BFCF7D1",
	  "amount": "505041821965"
	},
	{
	  "denom": "ibc/0C273962C274B2C05B22D9474BFE5B84D6A6FCAD198CB9B0ACD35EA521A36606",
	  "amount": "49379350709481"
	},
	{
	  "denom": "ibc/29A7122D024B5B8FA8A2EFBB4FA47272C25C8926AA005A96807127208082DAB3",
	  "amount": "1501500"
	},
	{
	  "denom": "ibc/2E5D0AC026AC1AFA65A23023BA4F24BB8DDF94F118EDC0BAD6F625BFC557CDED",
	  "amount": "309235788"
	},
	{
	  "denom": "ibc/406662DF40CFFCE3BBB80B2A2A7D476830C166981B14E18D8DD7446BB529377D",
	  "amount": "10500000000000000000"
	},
	{
	  "denom": "ibc/4F393C3FCA4190C0A6756CE7F6D897D5D1BE57D6CCB80D0BC87393566A7B6602",
	  "amount": "155120908"
	},
	{
	  "denom": "ibc/5012B1C96F286E8A6604A87037CE51241C6F1CA195B71D1E261FCACB69FB6BC2",
	  "amount": "2765691214888000"
	},
	{
	  "denom": "ibc/D956638E52570976F762354757863F60F2AFE4879E849CB1C77B163F0BF11C64",
	  "amount": "200002"
	},
	{
	  "denom": "ibc/F85BE85916DBE4721AC3CC9973925553B49171181C7A6096B798757833A1E79F",
	  "amount": "83000001"
	}
]

I tried searching block 4282576 for balance changes (including start and end block events) but nowhere can I find where the amount for denom gravity0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 was subtracted.

I also searched the docs but have found nothing.

Do I have to look somewhere else on the chain? Are these kind of events emitted?

Hello gravity leaders.

I added support for arm64 :

• if statement for aarch64
• pushed buf version to 0.44.0 instead of 0.41.0 which has no published release of arm64 version It is currently running in production in 1.7.2 version.

A slight cleanup of @gadost 's amazing work to integrate ica into Gravity-Bridge.

@jkilpatr I added some comments in here to help with understanding during the review. Hopefully you won't necessarily need to read the whole ICA spec to understand what the functionality and flow is, but I am always available for questions.

This issue applies to the ica branch

Summary

The ICA code in gravity_proto should not be a part of gravity.v1.rs, a new ibcauth.v1.rs file should be generated instead. This will require changes to the gravity_proto generation functionality here: https://github.com/Gravity-Bridge/Gravity-Bridge/tree/2f81df9788deee76bde0a2ac6676b41f5685a0a5/orchestrator/proto_build

Desired Solution

Add ibcauth support to the proto_build module.

This issue applies to the ica branch

Summary

MsgRegisterAccount's ValidateBasic function does not check the ConnectionId field. https://github.com/Gravity-Bridge/Gravity-Bridge/blob/2f81df9788deee76bde0a2ac6676b41f5685a0a5/module/x/icaauth/types/msgs.go#L29

Desired Solution

Add ConnectionId validation, and anything else which makes sense to check to prevent user frustration.