We collect, clean and format all types of data gathered from Ethereum clients, and regularly fall into problems where different nodes return different types. We have written a few blogs and opened several PR’s on the issue, but I think this ring can be a good place to standardize the data returned from Ethereum clients.
Summary of findings from the above article [with my comments]:
Use an SSD. [Confirmed]
Parity RPC responds even while syncing, Geth does not. [Not confirmed]
There is no standard error reporting from the nodes. Different nodes report errors in different ways. [Confirmed]
‘r’, ‘s’, and ‘v’ fields differ between clients. [Not confirmed]
Parity syncs faster than Geth. [Believed to be true]
JSON-RPC interface is not type-safe. [Is any JSON type safe?]
Tracing and state diff appear only in Parity (not Geth) and then with some inconsistancies. [Not confirmed]
RPC and Web socket interfaces handle block re-orgs. There’s a question if they are correctly handled. [Not confirmed]
Small differences between Geth and Parity: [Not confirmed]
Uncle size is null in Parity, but does exist in Geth.
Filter IDs on Geth and Parity are different.
Geth assigns random IDs, and Parity uses an incremental counter.
The consensus rules among clients have to match in order to make Ethereum work, but everything else, e.g. the exposed API, or RPC interface can be totally different. [Should be the same but are possibly different]
Take each client with a grain of salt. [Confirmed]
Thanks for checking on the findings, when you write “Not confirmed” do you mean a) you are going to evaluate it or b) you evaluated it and you did confirm that this issue exists.
@jpzk When I say ‘not confirmed’ above I meant that I did not independently test the claim made by Ankit. In other words, I don’t know if it right or wrong.