-
Notifications
You must be signed in to change notification settings - Fork 3.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replica not in sync with mainnet.optimism.io #877
Comments
A fix to the DTL released here: https://github.com/ethereum-optimism/optimism/releases/tag/%40eth-optimism%2Fdata-transport-layer%400.3.1 This patch fixed the problems that I was experiencing locally. Let me know if that fixes the problem for you |
Can you share the exact git commit that you are using? Can you confirm that the state roots are matching for the genesis block? |
Can reproduce locally:
|
Ah sorry Mark was away tinkering around with Kovan+Develop branch earlier and missed your replies... I did a fresh setup 2 hours back so I guess I was on commit cb2e9ad Should I go ahead with trying DTL v0.3.1? Thanks a ton! |
Hey @Enigmatic331, the fix should be here: #881 Going to get a release out asap after this goes through code review |
Just created new releases:
Feel free to reopen if the problem persists |
Thanks so much @tynes! One question - Albeit I know blockHash isn't really a thing but I'm worried it'd impact other areas of the database - Is it alright that the receipt is returning a different blockHash (mainnet.optimism.io being 0xbc5658f9eff19648ac60664880fcd2cbe5f595c7c944852610c056ee79cd4365 vs 0x18ebee690c2b482c528d394abe05331bb805af62af053bd8154c0b2ac454a7c8)? Data below is what is returned from getTransactionReceipt for 0xa8aa13df617039192ec6507aff76ea88a3f16e725b28105813fb545e23ca50ef on my replica:
|
The stateRoot does agree though, so not sure if this is an issue: mainnet.optimism.io
replica
|
Ok there's a difference on the parentHash so might be something from an earlier block... Hmmmmmm.... ADD: Checking back from block(0), and seems that the blockHash is different from the very start so I might just be pedantic and this is a non-issue, so just to check.... :) |
@Enigmatic331 Currently the blockhashes are non-canonical because we are using Clique consensus with a single signer and no peers for each node. Every node creates its own signer key and includes a signature in the extra data field of the block. The extra data is included in the block hash so every node generates a different block hash. This could be fixed by hardcoding a single clique signer key in the node but a better solution is being worked on in #875. This implements a custom |
Aha! Thanks so much Tynes - That makes total sense. Should be the same thing which was bothering me over at Kovan as well so good to know it's not really an "issue" per se. Great - Gonna get to work. |
Describe the bug
A transaction deploying a contract to mainnet.optimism.io was done (0xa8aa13df617039192ec6507aff76ea88a3f16e725b28105813fb545e23ca50ef) - When querying from mainnet.optimism.io I can see that the transaction receipt is valid with status 0x1, however on my replica the transaction receipt returns 0x0.
mainnet.optimism.io

replica:

To Reproduce
Steps to reproduce the behavior:
develop
branch.env
start.sh
Currently still digging about to see what else I may be missing... Any ideas will be very much appreciated 🙇
The text was updated successfully, but these errors were encountered: