yihuang

it feels that ibc shouldn't store so many pairs, can you see the prefixes?

https://github.com/cosmos/ibc-go/blob/release/v2.2.x/modules/light-clients/07-tendermint/types/update.go#L137 for the `consensusStates`, there's a pruning logic, but it only deletes at most one item at a time. we might need to check how many expired ones are currently....

The EVM module's storage schema is much simpler, contract code and storage, and the storage slots are calculated by evm internally, I guess there's not much to prune there.

> 2: storage, the key will be the prefix 02 + eth account address + hash of something (trying to figure out) it's the storage slot number, computed by evm...

> > > 2: storage, the key will be the prefix 02 + eth account address + hash of something (trying to figure out) > > > > > >...

I just had an idea to trade some speed for disk space: currently, the storage format is like this: ``` 02 + address{20} + slot1{32} -> value1{32} 02 + address{20}...

go-ethereum stores each contract's state in an independent trie, so their structure is like this: ``` accounts-trie: contract address -> rootHash rootHash: slot1 -> value1 slot2 -> value2 ``` Much...

`ws://127.0.0.1:8546` should work, any error messages? does the http one works?

I believe there are many NFT implementations on solidity which can be deployed to cronos. Is there a particular reason to use cosmos-sdk native nft on cronos?

There's a native nft module in cosmos-sdk 0.46 now, and the plan is to integrate after interchain-nft is implemented in ibc. closing now, duplicated: https://github.com/crypto-org-chain/cronos/issues/641