[Ethereum] How is Parity’s “warp” sync related to Geth’s “fast” sync

paritypeerswarp-sync

A follow-up to this question.

Geth's fast sync is one-shot. i.e. once we have synced some of the blockchain, we cannot use fast sync anymore. Is this the case for Parity? I ran it with warp, then without warp, then with warp again. It doesn't complain, so I guess this is doable in Parity.

One other issue I notice is the number of peers are way lower when I run parity with --warp. This is strange. Is warp sync exclusive? i.e. some nodes are warp, some nodes are not? Or is it just a coincidence whenever I run parity --warp, I find less peers?

Best Answer

You can warp from any point in the blockchain, the client notices if you are more than 30_000 blocks behind and kicks in a warp sync unless you disabled it with --no-warp

The --warp flag literally does nothing because warp is enabled by default. So it does not affect your connected peers in any way. It must be a coincidence. You can try to increase your minimum number of peers with --min-peers and add additional snapshot clients with --snapshot-peers.

So, to answer your initial question how geth --warp relates to geth --fast, yes, geth' fast sync mode does only work on first run, parity's warp sync works always if it detects the chain is a catch up a lot of blocks.

Related Solutions

[Ethereum] Parity’s “warp” sync, and why is it faster than Geth “fast”

It's difficult to give an answer without just re-hashing the explanation on the Parity wiki...

The pertinent part is as follows:

These snapshots can be used to quickly get a full copy of the state at a given block. Every 30,000 blocks, nodes will take a consensus-critical snapshot of that block's state. Any node can fetch these snapshots over the network, enabling a fast sync.

The snapshot itself is comprised of 3 parts:

A manifest, which is basically metadata about the snapshot;
Block chunks, which contain raw block data about blocks and their transaction receipts;
State chunks, which contain data about the state at a given block.

Chunks are currently set to 4MB in size.

So how does this actually speed up the sync? What that wiki page doesn't say is that we only sync the snapshots initially. So for each block at intervals of 30,000, we obtain a set of 4MB chunks. Then in the background we continue to sync the remaining block data.

This is equivalent to Geth's --fast sync, which first syncs the block headers, and then in the background syncs the rest of the data. It's just that --warp is syncing even less data on the first pass, and filling in the bigger gaps later on.

Edit:

See also the relevant official Ethcore blog post, specifically the section entitled Core Strength.

[Ethereum] How to find ETC nodes (to pass their enode URI to –reserved-peers) because the classic chain no longer syncs through tor

...and I can't find new ones because peer discovery is done through UDP and tor only runs through TCP. Is this an accurate understanding?

Yes.

As per the issue thread you linked to, you could attempt to add peers (using --reserved-peers) from the hard-coded bootnodes list in the ETC (go-ethereum, not Parity) codebase, located in bootnodes.go.

The list, as of late January 2017, is as follows:

enode://08c7ee6a4f861ff0664a49532bcc86de1363acd608999d1b76609bb9bc278649906f069057630fd9493924a368b5d1dc9b8f8bf13ac26df72512f6d1fabd8c95@45.32.7.81:30303
enode://e809c4a2fec7daed400e5e28564e23693b23b2cc5a019b612505631bbe7b9ccf709c1796d2a3d29ef2b045f210caf51e3c4f5b6d3587d43ad5d6397526fa6179@174.112.32.157:30303
enode://687be94c3a7beaa3d2fde82fa5046cdeb3e8198354e05b29d6e0d4e276713e3707ac10f784a7904938b06b46c764875c241b0337dd853385a4d8bfcbf8190647@95.183.51.229:30303
enode://6e538e7c1280f0a31ff08b382db5302480f775480b8e68f8febca0ceff81e4b19153c6f8bf60313b93bef2cc34d34e1df41317de0ce613a201d1660a788a03e2@52.206.67.235:30303
enode://ca5ae4eca09ba6787e29cf6d86f7634d07aae6b9e6317a59aff675851c0bf445068173208cf8ef7f5cd783d8e29b85b2fa3fa358124cf0546823149724f9bde1@138.68.1.16:30303
enode://217ebe27e89bf4fec8ce06509323ff095b1014378deb75ab2e5f6759a4e8750a3bd8254b8c6833136e4d5e58230d65ee8ab34a5db5abf0640408c4288af3c8a7@188.138.1.237:30303
enode://fa20444ef991596ce99b81652ac4e61de1eddc4ff21d3cd42762abd7ed47e7cf044d3c9ccddaf6035d39725e4eb372806787829ccb9a08ec7cb71883cb8c3abd@50.149.116.182:30303
enode://4bd6a4df3612c718333eb5ea7f817923a8cdf1bed89cee70d1710b45a0b6b77b2819846440555e451a9b602ad2efa2d2facd4620650249d8468008946887820a@71.178.232.20:30304
enode://921cf8e4c345fe8db913c53964f9cadc667644e7f20195a0b7d877bd689a5934e146ff2c2259f1bae6817b6585153a007ceb67d260b720fa3e6fc4350df25c7f@51.255.49.170:30303
enode://ffea3b01c000cdd89e1e9229fea3e80e95b646f9b2aa55071fc865e2f19543c9b06045cc2e69453e6b78100a119e66be1b5ad50b36f2ffd27293caa28efdd1b2@128.199.93.177:3030
enode://ee3da491ce6a155eb132708eb0e8d04b0637926ec0ae1b79e63fc97cb9fc3818f49250a0ae0d7f79ed62b66ec677f408c4e01741504dc7a051e274f1e803d454@91.121.65.179:40404
enode://48e063a6cf5f335b1ef2ed98126bf522cf254396f850c7d442fe2edbbc23398787e14cd4de7968a00175a82762de9cbe9e1407d8ccbcaeca5004d65f8398d759@159.203.255.59:30303
enode://42d8f29d1db5f4b2947cd5c3d76c6d0d3697e6b9b3430c3d41e46b4bb77655433aeedc25d4b4ea9d8214b6a43008ba67199374a9b53633301bca0cd20c6928ab@104.155.176.151:30303

Best Answer

Related Solutions

[Ethereum] Parity’s “warp” sync, and why is it faster than Geth “fast”

[Ethereum] How to find ETC nodes (to pass their enode URI to –reserved-peers) because the classic chain no longer syncs through tor

Related Topic