If someone manipulates the local blockchain data, does ethereum clients like geth return false data?
For example, after cracker manipulates local blockchain files or leveldb, does geth return manipulated data?
asked Jul 17, 2016 at 7:45
-
Sorry if I misunderstood, but are you talking about hacking only one node database after it synced or hacking many nodes?– Nicolas MassartCommented Jul 18, 2016 at 19:22
-
For example, my node is cracked and blockchain data is manipulated after it synced.– Satoshi NakanishiCommented Jul 19, 2016 at 3:31
Add a comment
|
2 Answers
The simple answer is yes and no.
You have to understand how a blockchain works and how it is related to all the other nodes on the network and how they reach consensus about the state of the blockchain.
Firstly if the database is properly corrupted (ie stored bits are missing or inaccessible) you will get read errors, which means that no, you won't be able to show incorrect data, because you won't show data at all.
Secondly if you are talking about false transactions, then it is difficult to see how that could occur at all on the mainnet. (Although this is simplification for the purpose of an answer).
The network agrees all transactions and the blockhash is calculated from transaction data and the previous blockhash. This is the whole idea of a chain of blocks! Any change in the transaction data would result in a different blockhash and therefore would break the chain.
A false block could not be simply inserted because all subsequent hashes would have to be recalculated from your fake block. This is the underlying security model of the blockchain. Although it is not technically impossible to insert a block, your attacker would then have to recompute all subsequent transactions hashes and blocks faster than the network is doing it already. This is computationally impractical, and therefore generally accepted as secure enough.
Thirdly, for anything like false blocks to happen your node would
- have to be disconnected from the mainnet peers AND you would have to be mining your own fork or,
- you would have to be only connected to a malicious group of peers who are only sending your (non-mining) node blocks from their chain which is a fork of the main chain.
In either case you would be seeing false data, but again you would be operating on a fork and not the main chain.
As your question was quite vague, this should cover the general points to think about.
-
Do you know the mechanism by which local
.dbfiles are checked for validity/consistency, and how often this occurs? Presumably only when they're read, but how often does that happen? (I had a quick look in the code but it wasn't immediately obvious.) Commented Jul 22, 2016 at 13:17 -
>if the database is properly corrupted (ie stored bits are missing or inaccessible) you will get read errors, How does the client check if the data is incorrect? Each time the geth is asked the data via JSON-RPC API, does the geth check if the data which the geth tries to return is correct/valid? Commented Jul 23, 2016 at 6:03
-
Maybe someone is going to have to write a patch to geth or other ethereum client to prove that you an lie to an RPC client about the state of the network. It's entirely possible to do, therefore, you shoulde NEVER trust one node or one node technology. The truly paranoid (e.g. exchanges, anyone dealing with large amounts of ether) should be setting up multiple nodes in multiple security domains with different node technology and verifying large value transactions with multiple RPC calls. Alas, nobody has published such code yet AFAICT– Paul SCommented Jul 25, 2016 at 3:44
-
@SatoshiNakanishi This is another question, but to answer it, you cannot read corrupt file data and get anything meaningful back. You are over-thinking the problem. This is a low level file read and save issue.– T9bCommented Aug 15, 2016 at 16:15
geth, parity, et. al. are nodes running software that have two main interfaces - one RPC, and one to the blockchain. It's entirely possible to hack a node and lie to the RPC client. It's not possible to lie to the blockchain in a useful manner. (details in the other answer).
If your RPC client is dealing with significant amounts of value external to the blockchain (e.g. an exchange), you should verify transaction hashes against multiple nodes in different security domains and using different node technologies, and make sure the network firewalls are set up so the nodes cannot talk to each other other than by the blockchain protocol.
It's probably even useful to verify hashes against one of the public blockchain tracker websites, which gives you some value in a human watching what's going on, but those websites tend to discourage automated systems querying them.
Nobody should ever trust a single software node for anything of significant value.
