Is it possible to check that does client's node's block number matches with the blockchain's best(latest) block number?

Question

I have a sorted linked list that contains around 1000 items. When I receive a new item my goal is to push the item to the list keeping the sorted order. So if I receive very small value, I am required to iterate all the list to find the tail of the list. I have suggested that I could retreive the index via constant function and my transaction function could use the returned index value to push the item to correct location without spending gas to iterate the list.

My goal is to follow this guide (https://ethereum.stackexchange.com/a/13855/4575) to call a constant function and submit its return value into a transaction function.

getIndex() => constant 
setArray() => transaction

setArray( getIndex() );

The question emerges that: when I call a constant function on my client node is it possible to check that does my client node's block number is the best block number or is it behind. If it is behind, constant function may return wrong information.

For example blockchain's best block is 100. But my node is in currently at blockNumber 90 (basically behind of the blockchain). So when the client node get the index of the list up to first 90 blocks and miss items generated on the remaining 10 blocks.

[Q] Is it possible to check that does client's node's block number matches with the blockchain's best which is the latest block number?

As you can see on the example image, block number on the client nodes may vary. Best block number is 1,002,312 but block number is 1,002,304 on node on the top. But sometimes all nodes are on the latest block number. So it is hard to trust to node's behaviour.

Following answer seems working:

web3.eth.syncing;
sync.highestBlock

But returned highestBlock number still seems few blocks number smaller than on my best block number on my private chain. Is it a normal case?

Answer 1

Ethereum is a probabilistic system.

In my opinion, there is just no way to be certain that one is looking at the latest block that will ultimately make it into the longest chain with vanishingly small improbability that a chain reorganization will rearrange things. Therefore, I don't think reliance on a client witness is good way to inform a sorting process.

I'm a strong believer in the principle that a Smart Contract must safeguard the integrity of the internal data storage. If the data must be accessible in sorted order (not necessarily an on-chain concern), then the order of the data lies within the scope of "guaranteed internal integrity".

By that rationale, reliance on correct information from the call() you describe and the need for it to be current must go. It's an unacceptable external dependency and probably not satisfactorily solvable.

Consider three general approaches

• Insert "Bob"
• Insert "Bob" after "Alice"
• Insert "Bob" near "Alice"

The first may call for considerable depth in the internal search and will not scale well. The second approach depends on reliable information from outside; reliability we probably can't achieve. The third approach relies on a hint for gas efficiency, but leaves it to the contract to make the final, correct decision.

"Near" is basically a head start on the search process. Importantly, the contract will complete the search and reach it's own conclusions about where & how to insert "Bob" given the current state of the ordered list. Any list in any state in any block on any chain would have to be correctly ordered, owing to not depending on precise external guidance.

In summary:

I would first consider if the sort necessarily really needs to be on the chain.

If the sort is unavoidable, then organize a sorted linked-list or similar index scheme in the contract. The contract alone should determine correct insertion points. A "hint" may reduce internal searching needed to do that, thereby reducing gas cost and helping ensure the process will work on a list of any size.

Hope it helps.

Answer 2

Yes it is possible to check whethers block number matches with the blockchain's best(latest) block number.

The steps would be

1. Query a public blockchain API to get latest block number
2. Check against clients block no.

The submitting transaction part requires some changes in the core/api layer.

Answer 3

The RPC API got your back.

Just use this function to check your and the client's latest block. Depending on how much you want to trust the client, you can compare the values on the client's side or make sure it gets transfered back to you without manipulation.

Function for getting the latest block:

web3.currentProvider.sendAsync({
  method: "eth_blockNumber",
  params: [],
  jsonrpc: "2.0",
  id: 83
} function (error, result) {...})

More details on the JSON RPC API and how you can use it in many different ways (with curl, for example): Here

You can use curl, by the way, to check the clients current block remotely, if it's node and firewall settings allow the connection.

Of course, don't forget to turn the result to a decimal number, parseInt(value, 16).

You can find an example of how to implement such web3 functions here.