I've been running a geth light client to deploy smart contracts through Truffle Migrations to mainnet. I'm getting: "Error: No trusted canonical hash trie".
Any help in what this entails and how to resolve it?
Asked
Active
Viewed 1,900 times
12
-
which version of geth you're using? – Tony Dang Oct 02 '18 at 02:25
-
v 1.8.7 stable. – Simon de la Rouviere Oct 02 '18 at 16:57
-
I did update to stable 1.8.16 and it still happens – Simon de la Rouviere Oct 02 '18 at 18:30
-
They also mentioned that not sure about the mainnet; you can create an issue on github to report the problem – Tony Dang Oct 02 '18 at 22:34
-
I'm getting the (exact?) same problem with 1.8.7, but with rinkeby. I'm also getting "Error: no suitable peers available" It is submitting the transactions, btw, but it is not picking up responses properly. – celeduc Oct 25 '18 at 12:59
-
- correction: error occurs with 1.8.17.
– celeduc Oct 25 '18 at 13:52
4 Answers
1
When starting geth make sure to have --syncmode "fast" rather than --syncmode "light" .
mega_creamery
- 123
- 4
1
Since a light client doesn't hold full database, it needs to have a canonical hash to validate a newly received block.
If the node is pruned (or new), it needs to download block bodies and receipts on demand through an ODR interface, then make sure it's covered by a local checkpoint.
Basically it means your node needs to find peers to download data from, with time it should find some and proceed, unless there's a connectivity issue.
Can see the condition that produces this error here.
Kof
- 2,954
- 6
- 23
1
The error message "No trusted canonical hash trie" usually indicates that the Ethereum client you are using (in your case Geth light client) has not fully synchronized with the Ethereum blockchain.
To resolve the issue, you can try the following steps:
- Increase the timeout value in your client configuration file.
- Restart your client and allow it to synchronize completely.
- If the issue persists, try switching to a different Ethereum client, such as Parity or Geth full node.
It's important to note that running a light client may not always be sufficient for deploying smart contracts to the Ethereum mainnet, as light clients have limited capabilities compared to full nodes.
Manrique
- 196
- 5
1
For light clients and maybe more so for super light clients which don't have the state local a get_proof() RPC call will be needed for these use cases. There is some work being done here: ethereum/EIPs#1186
MOORETOKEN
- 45
- 9