Get Account balance from Peer by Snap Protocol

[suhoangson]

i am testing method GetAccountRange in Snap Protocool https://github.com/ethereum/devp2p/blob/master/caps/snap.md
this is my code:

account address:="0xC0fcFAd6a5db86F566102B8a7115823068a93c50"
startingHash:=crypto.Keccak256Hash(address[:])
limitHash:=startingHash
fmt.Println("1. Address Hash: ",startingHash)
req := &snap.GetAccountRangePacket{
		ID:     uint64(rand.Int63()),
		Root:   "0xeefa615bf3990adb86ded057488aad886e112b5c664359b836220c742c360866", 
		Origin: start_hash,
		Limit:  limit_hash,
		Bytes:  4000,
	}
msg, err := conn.snapRequest(snap.GetAccountRangeMsg, req) 
if err != nil {
     return 
}
res, ok := msg.(*snap.AccountRangePacket)
if !ok {
    return 
}
for _,acc:=range res.Accounts{
    fmt.Printf("2. Account: %+v\n",acc)
}
_, accounts, err: = res.Unpack()
if err != nil {
    return
}
for _, account := range accounts {
    acc := new(types.StateAccount)
    if err := rlp.DecodeBytes(account, acc); err != nil {
	fmt.Println("err rlp decode: ",err)
	continue 
    }
    fmt.Printf("3. Account Decode: %+v\n",acc)
}

i am using conn.snapRequest in above code from this : conn from this https://github.com/ethereum/go-ethereum/blob/master/cmd/devp2p/internal/ethtest/conn.go
When i excuted above code, this is result:

1. Address Hash: 0x592d13806a8adb6c6963d1561173b468607f74982742d83b9f98f935a29fe958
2. Account: &{0x592d138c3fb74c5f667d81f819f49290a33d27960b2e533def4bf7760772600e [203 3 135 167 240 243 25 33 32 0 128 128]}
3. Account Detail: &{Nonce:3 Balance:+47271248000000000 Root:0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421 CodeHash:[197 210 70 1 134 247 35 60 146 126 125 178 220 199 3 192 229 0 182 83 202 130 39 59 123 250 216 4 93 133 164 112]}

My questions: why result from Peer is differenent my account? seem that is difference account.

[karalabe]

That should work. Are you sure the peer you're connecting to / the root hash in the request is valid? The peer is returning an address very very close to what you requested, as if that one didn't exist, so giving you the next one in line.

For what is worth, the reply also contains a Merkle proof that can "prove" that between the hash you requested and the hash returned there are no accounts, but for that you need to implement validating the proofs too.

My gut feeling is that there's something wrong on your end because Geth's snap sync works correctly, so it would be very off if it's skipping something. That said, it wouldn't be the first time there's a bug, so if you can send us a more complete repro to run against say a mainnet code, we can investigate some more.

[holiman]

I don't know what you're doing here (did you alias account as a string?):

account address:="0xC0fcFAd6a5db86F566102B8a7115823068a93c50"
startingHash:=crypto.Keccak256Hash(address[:])

but,

func TestFoobar(t *testing.T) {
	address := "0xC0fcFAd6a5db86F566102B8a7115823068a93c50"
	startingHash := crypto.Keccak256Hash([]byte(address[:]))
	t.Logf("hash %#x", startingHash)
	addr := common.HexToAddress("0xC0fcFAd6a5db86F566102B8a7115823068a93c50")
	t.Logf("addr %v hash %#x", addr, crypto.Keccak256(addr[:]))
}

=== RUN   TestFoobar
    txindexer_test.go:248: hash 0xab103af88bf491548357f72c56c3026e9495f7afa621a7395e919bb2a43c9f35
    txindexer_test.go:250: addr 0xC0fcFAd6a5db86F566102B8a7115823068a93c50 hash 0x9e77a924051ce4c3f7defc133d107d1361563472b038e1bcae5058c56dd90100

The hash you should wind up with is 0x9e77a924051ce4c3f7defc133d107d1361563472b038e1bcae5058c56dd90100, not 0x592d13806a8adb6c6963d1561173b468607f74982742d83b9f98f935a29fe958

[karalabe]

	address := "0xC0fcFAd6a5db86F566102B8a7115823068a93c50"
	startingHash := crypto.Keccak256Hash([]byte(address[:]))

@holiman This is wrong, this hashes the ASCII of the address. You need address = common.HexToAddres("..."). And then hash those bytes. OP's code was correct, they were just giving the example data.

[holiman]

I know that was wrong. I tried to see if that's what op was doing (it wasn't). The second one was correct (?)

[suhoangson]

That should work. Are you sure the peer you're connecting to / the root hash in the request is valid? The peer is returning an address very very close to what you requested, as if that one didn't exist, so giving you the next one in line.

For what is worth, the reply also contains a Merkle proof that can "prove" that between the hash you requested and the hash returned there are no accounts, but for that you need to implement validating the proofs too.

My gut feeling is that there's something wrong on your end because Geth's snap sync works correctly, so it would be very off if it's skipping something. That said, it wouldn't be the first time there's a bug, so if you can send us a more complete repro to run against say a mainnet code, we can investigate some more.

@karalabe

• i connected to a peer on mainnet, you mean rootHash in the request is not existing in the peer which i connected right? my understanding except that peer doesn't sync that block yet, else all peers include Full Node and Archive Node always contains that rootHash of that block right?
• root hash which i used in the request, i get it from etherscan as below picture, "StateRoot" field is it correct? i find a random block on etherscan.io, this block is existing in last 128 blocks :
  

[holiman]

As I've already explained, though:
0x592d13806a8adb6c6963d1561173b468607f74982742d83b9f98f935a29fe958 is the wrong hash.
0x9e77a924051ce4c3f7defc133d107d1361563472b038e1bcae5058c56dd90100 is the correct hash.

[suhoangson]

@holiman , you are right. i used wrong method, thanks!. i closed this issue.