Question

根据Etherscan，我有7.5个Ether，但是当我在Javascript控制台中执行eth.getBalance（eth.accounts [0]）时，它始终返回“ 0”

这就是我将geth连接到rinkeby的方式（运行超过24小时）

geth  --rinkeby

这是同步状态

λ geth --rinkeby attach ipc:\\.\pipe\geth.ipc
Welcome to the Geth JavaScript console!

instance: Geth/v1.9.9-stable-01744997/windows-amd64/go1.13.4
coinbase: 0x7f9153e8fe06c4b3eb10e8457c20d0559921de5c
at block: 0 (Wed, 12 Apr 2017 16:59:06 CEST)
 datadir: C:\Users\andre_000\AppData\Local\Ethereum\rinkeby
 modules: admin:1.0 clique:1.0 debug:1.0 eth:1.0 miner:1.0 net:1.0 personal:1.0 rpc:1.0 txpool:1.0 web3:1.0

> eth.syncing
{
  currentBlock: 5746334,
  highestBlock: 5746402,
  knownStates: 32641057,
  pulledStates: 32636964,
  startingBlock: 5746304
}
> eth.getBalance(eth.accounts[0])
  0
> eth.getBalance(eth.coinbase)
  0
> web3.fromWei(eth.getBalance(eth.coinbase)); 
  0
> eth.getBalance("0x7f9153e8fe06c4b3eb10e8457c20d0559921de5c")
  0
> eth.blockNumber
  0

du -h 30G

Answer 1

听起来geth尚未同步。

请在您的geth控制台中输入以下内容：

eth.getBlock("latest").number

截至本文，您应达到 5757199 或更高。

Péter Szilágyi（以太坊团队负责人）说，“同步以太坊是一个痛点”。

来自https://github.com/ethereum/go-ethereum/issues/16875：

Geth当前的默认默认同步模式称为快速同步。代替从创世块开始并重新处理所有曾经发生过的交易（可能需要数周），快速同步下载块，仅验证相关的工作量证明。下载所有块是一个简单，快速的过程，并且将相对快速地重新组装整个链条。

许多人错误地认为，因为他们有积木，所以他们同步中。不幸的是，事实并非如此，因为没有交易已执行，因此我们没有任何可用的帐户状态（即余额，随机数，智能合约代码和数据）。这些需要下载分别进行交叉检查，并与最新的块进行交叉检查。这个阶段是称为状态Trie下载，它实际上与块下载； las，如今花费的时间比下载块。

那么，国家特里是什么？在以太坊主网中，有大量的已经存在的帐户，该帐户跟踪每个帐户的余额，随机数等用户/合同。但是帐户本身不足以运行一个节点，需要将它们加密链接到每个块，以便节点实际上可以验证该帐户的未被篡改。通过创建树数据结构来完成此密码链接帐户上方，每个级别将其下方的层汇总为一个越来越小的层，直到达到单根。这个巨大的包含所有帐户和中间帐户的数据结构密码证明称为状态特里。

好，那为什么会引起问题？这个特里数据结构是数亿个微小密码的复杂互连证明（trie节点）。要真正拥有一个同步节点，您需要下载所有帐户数据以及所有微小的密码证明网络中没有人试图欺骗您。这本身已经是疯狂的数据项。它在哪里变得更加混乱的是，这些数据在不断地变形：块（15s），从该Trie中删除了大约1000个节点，大约添加了2000个新的。这意味着您的节点需要同步每秒变化200次的数据集。最糟糕的是在同步时，网络正在前进，并且状态开始下载时可能会消失，因此，您的节点需要不断地跟踪网络，同时尝试收集所有最近的数据。但是直到您真正收集到所有数据，您的本地节点无法使用，因为它无法加密证明有关任何帐户的任何信息。

如果您发现主网落后64个街区，那么您还没有同步，甚至没有关闭。您已完成区块下载阶段，仍处于下载状态。你可以看到这个通过看似无止境的导入状态条目流自己的日志。您还需要等到节点真正出现在线。

盖斯：--rinkeby上的余额始终为0

1 个答案: