eth: don't accept transactions until we sync up with the network #2649
Conversation
Updated: Mon Jun 6 11:16:55 UTC 2016 |
karalabe
force-pushed
the
omit-startup-tx-processing
branch
from
43fc7ab to
170ee07
Compare
Current coverage is 56.83%@@ develop #2649 diff @@
==========================================
Files 216 216
Lines 24539 24543 +4
Methods 0 0
Messages 0 0
Branches 0 0
==========================================
- Hits 13953 13949 -4
- Misses 10585 10593 +8
Partials 1 1
|
|
https://gitter.im/ethereum/go-ethereum?at=5750a31110f0fed86f4accbf |
|
Glad to hear it. Btw, I've also identified an issue with the QoS PR. It works beautifully for fast sync but normal sync doesn't do enough requests fast enough to allow converging on to good peers. Maybe that's why it didn't produce the most stable results, I'm looking into fixing it. |
| // Transactions arrived, make sure we have a valid chain to handle them | ||
| if atomic.LoadUint32(&pm.fastSync) == 1 { | ||
| // Transactions arrived, make sure we have a valid and fresh chain to handle them | ||
| if atomic.LoadUint32(&pm.fastSync) == 1 || atomic.LoadUint32(&pm.synced) == 0 { |
There was a problem hiding this comment.
Do we still need the fast sync check? The fetcher doesn't run until fast sync is over, right?
There was a problem hiding this comment.
We agreed to remove the check in a call.
|
👍 |
karalabe
force-pushed
the
omit-startup-tx-processing
branch
from
45512e9 to
32559cc
Compare
When booting the node, we're most probably out of sync. There's no point in gathering and processing transactions at this point in time, as it could take a considerable amount of time to sync up, and shuffling transactions between every block is a wasted resource either way. This PR introduces a mechanism to discard inbound transactions until either the downloader reports a successful sync cycle, or until the fetcher schedules something for us. This should ensure that newly started nodes don't waste time processing transactions against a stale chain.
Further all the accumulates transactions are propagated to all newly joining peers, which additionally puts a large strain on the network and downloader, which needs to play nice with an already saturated connection.
Just for the reference, by the time a sync reaches 700K blocks, it accumulates currently about 7K pending transactions and 9K queued ones, each of which requires revalidation after every block and/or import batch.