Common: add YoloV3 network #1129
Conversation
Codecov Report
Flags with carried forward coverage won't be shown. Click here to find out more. |
|
Will give this a short look now. We also still have this problem in the client (at least I am 80% sure on this), that the first 1-2 bootnode connections are (often? always?) not successful due to all the services not yet set up properly, this might also be the cause for the problems. Extremely hard to debug though (at least I wasn't successful on this yet). We'll see. 😄 |
|
Phew, had to fix 3-4 (!) partly serious bugs for this in a row (but luckily I had a streak here in this case 😁). For the The second "bug" is a bit eyebrow raising, I noticed that on a received ETH status reply (for completely unknown reason I once managed to get one before the bug fix 😜 ), the next forkblock by geth - if unknown - is apparently announced as the empty buffer and not the zero-Buffer, e.g. this Last thing: also stumbled upon the high chainID - this time in the client - could be fixed relatively easy. Anyhow: this is now working (so: the connection part 😋 ) 🎉 , so: happy debugging! 👍 Cool cool work @jochem-brouwer, so great that we are finally here now! 😄 |
|
Is there a problem in client with the high chain id? The number is high, but not so high that we run into rounding errors. If we are connecting now does that also mean we are syncing? |
|
Looks like we are actually syncing some blocks? Then I get an error Should be rather easy to fix though, we call |
|
Tests are going to fail, because this PR now needs these changes to I can report that we are successfully syncing with the YoloV3 network. I am currently at block 33424, head is at 79783. What a great milestone we have achieved here! 🎉 😄 |
|
We synced to (almost) head of chain! We can use this opportunity to figure out what should happen at the head of the chain. It looks like the block fetcher stops once we are synced. Note: to test this locally, pull the ethereumjs-util and checkout the |
|
Did a re-sync, I noticed that at some point I get this error (error also happened on the first sync)
(This is the bootnode). I wonder if we get banned from this peer, might be useful to take a look here. After this happens, we retrigger bootstrap, then it throws the same error. Then after a new re-bootstrap the peer suddenly likes us again. |
jochem-brouwer
force-pushed
the
eip2718-eip2930
branch
from
c5f1a48
to
9c6f2f6
Compare
|
Hi @jochem-brouwer, hope that was ok to merge in #1048, there was just so much other work heaping up! We'll continue to have a close eye on this of course and won't release anything prematurely, so don't worry! 😄 What is the plan here? Do we want to cherry-pick the respective commits? What is the first relevant commit here? |
|
I will check this tomorrow but I think we can directly rebase this one and once we integrate the util package I think we can directly merge this 👍 |
|
Absolutely no chance for a rebase here - that's what I meant with warning here a bit 😋 - once you have done a rebase on a parent branch all the commits are different and git perceives (close to) all changes done as concurrent changes and you have to manually fuddle yourself through everything, which is close to not doable (just tested locally and it already completely breaks at the first commit of #1048 😄 ). But nevermind, I think this really should be a good candidate for cherry-picking, will give this a try. |
…() not returning the correct forkHash (but: null) when hardforks with the same forkHashes found (applies with hardforks occuring on the same block number)
…rflow on large network IDs
|
Ok, have cherry-picked the new commits from this branch and force-pushed. There is still an error occurring on the Error is: INFO [03-05|11:02:42] Started libp2p server.
INFO [03-05|11:02:45] Listener up transport=rlpx url=enode://c904debea44d4a797208a3a07994a80aa0e80293700a960a2c638827c1cf85f3e134d04d0f188ebbc5483430e8e06936a4163685ec5e922c42565f2567fae153@[::]:30303
INFO [03-05|11:02:45] Listener up transport=libp2p url=/ip4/127.0.0.1/tcp/50580/ws/p2p/QmPeAfmNKut6emwQqqqpa6xddg8oBPG8WDLDxZmfWj5go9
INFO [03-05|11:02:45] Started eth service.
INFO [03-05|11:02:54] Imported blocks count=50 number=1 hash=1053e007... hardfork=berlin peers=1
INFO [03-05|11:02:54] Executed blocks count=50 first=0 hash=f1f2876e... hardfork=berlin last=50 hash=f3d236ac... with txs=0
INFO [03-05|11:02:54] Executed blocks count=5 first=50 hash=f3d236ac... hardfork=berlin last=55 hash=4fe2c891... with txs=0
ERROR [03-05|11:02:54] Error: invalid transactions: errors at tx 0: Invalid Signature (block number=73 hash=c56fbbd792fac0da5c8d20112c317346b6e07586afe3b68ba866a184d6aa3ad0) at BlockHeader._error (/ethereumjs-monorepo/packages/block/src/header.ts:762:15)
at Block.validateData (/ethereumjs-monorepo/packages/block/src/block.ts:264:25)
at Block.validate (/ethereumjs-monorepo/packages/block/src/block.ts:250:16)
at /ethereumjs-monorepo/packages/blockchain/src/index.ts:880:9
at Blockchain.runWithLock (/ethereumjs-monorepo/packages/blockchain/src/index.ts:407:21)
at Blockchain._putBlockOrHeader (/ethereumjs-monorepo/packages/blockchain/src/index.ts:851:5)
at Blockchain.putBlock (/ethereumjs-monorepo/packages/blockchain/src/index.ts:806:5)
at Blockchain.putBlocks (/ethereumjs-monorepo/packages/blockchain/src/index.ts:792:7)
at Chain.putBlocks (/ethereumjs-monorepo/packages/client/lib/blockchain/chain.ts:275:5)
at BlockFetcher.store (/ethereumjs-monorepo/packages/client/lib/sync/fetcher/blockfetcher.ts:84:5)Not sure if I have forgotten to cherry-pick a commit or this is something else. Have temporarily pushed the old branch to #1137 to ease debugging eventually. |
|
Ok, this is now working again, will merge this in. 😄 |
This PR is aimed towards the eip2718-eip2930 branch and creates the YoloV3 block in Common. We successfully import the block, but sadly it does not seem we are connecting to the network. My hunch is, that this is because we don't have the right fork hashes.
Genesis block source
Genesis block as reported by web3
The goal of this PR is to successfully connect and sync with YoloV3 (which is also why it is targeted towards the eip2718-eip2930 branch, because we need support for these EIPs in order to sync).