Geth client and Mist wallet are under the Ropsten network, why is the balance of the same account different?

Mist wallet
account: 0xB17000eB180dABEF81Eb110D175e096AF39C1203 has a balance

under the Ropsten Testnet network.

[the browser has a balance]
https://ropsten.etherscan.io/.

Geth client:

start script:

geth-- rpc-- rpcapi "db,eth,net,web3,personal,admin,miner"-- testnet console


> eth.getBalance("0xb17000eb180dabef81eb110d175e096af39c1203");
0
> eth.blockNumber;
480608
How can the output balance under

geth be 0? The current height of Synchronize block is 480608, which does not seem to be as complete as Synchronize.

under geth, testnet should be equivalent to Ropsten, right? See, that"s what it says, or the address won"t be right, right?

in fact, we want to achieve the function of transferring tokens of ERC20 to the address of ethernet place in batches on the server side.
idea: start geth first, and provide the operation of Ethernet Square through express-based packaging web3.js packaging based on the main network RPC,.
is this the right way of thinking? The test passed on the private chain! Does the main network geth want all the data blocks of Synchronize?

geth-h

ETHEREUM OPTIONS:
-- config value TOML configuration file
-- datadir "/ Users/junhuazhou/Library/Ethereum" Data directory for the databases and keystore
-- keystore Directory for the keystore (default = inside the datadir)
-- nousb Disables monitoring for and managing USB hardware wallets
-- networkid Value Network identifier (integer, 1 frontier, 2=Morden (disused), 3 Blockchain syncmode (br, 4=Rinkeby) (default: 1)
-- testnet Ropsten network: pre-configured proof-of-work test network
-- rinkeby Rinkeby network: pre-configured proof-of-authority test network
-- syncmode "fast" Blockchain syncmode ("fast", "full", Or "light")
-- gcmode value Blockchain garbage collection mode ("full", "archive") (default: "full")
-- ethstats value Reporting URL of an ethstats service (nodename:secret@host:port)
-- identity value Custom nodename
-- lightserv value Maximum percentage of time allowed for serving LES requests (0-90) (default: 0)
-- lightpeers value Maximum number of LES client peers (default: 100)
-- lightkdf Reduce key-derivation RAM & CPU usage at some expense of KDF strength

Mar.23,2021

I have this problem, too. How did you solve it

Menu