core: change ordering of txs of equal gas price from arrival time to hash #915
Conversation
There was a problem hiding this comment.
EDIT: my summary of this PR: #915 (comment)
@ktrout1111 Can you merge my pull request where I fixed the unit tests?
core: fix unit test for tx hash ordering
Done. Thanks. |
|
@lennybakkalian Thanks for the fixes. I'm not familiar with Go's CI tools so was unaware of the need for unit testing and linting. According to GitHub's built-in checks, your changes fixed the Unit Test but not the Lint. On inspection, I found that I had added too many blank lines in transaction.go, so I removed them and recommitted. The lint now passes, but bizarrely the Unit Test is failing again on a step that appears unrelated to our changes. When i run "make test" locally (Go 1.17.1, Ubuntu 21.04), it fails at a completely different part: The only culprit I could think of is the change from making 5 test transactions to 10, so I changed it back locally but got the same failure at the same point in the test. The Unit Test running on GitHub seems to be rather rickety if it is succeeding, and then failing simply by removing 2 empty lines from one source file! |
|
@ktrout1111 The test "TestLargeReorgTrieGC" also fails in the github pipeline, but when i run the test locally it works. weird.... ill look into it |
|
I am getting nowhere as this failing test works locally for me. Maybe a maintainer will be here soon. |
|
I tried cloning the repo again from scratch and just copy pasting our changes over the top and that caused the test to succeed locally, so I might just trash this pr in the morning and try again with a new one with all the changes in one commit. |
|
I believe the failing test is not coming from us, as it also fails in another pull request. |
I concur. It seems a bit nondeterministic, especially given that it succeeded on the previous commit. All it took to make it fail next run was the removal of 2 empty lines from a source file. I'm tempted to make a trivial change and recommit and see what happens. |
|
And now the test "TestProcessDiffLayer" fails. What kind of test environment is this? |
|
Beats me. Same error also comes up in this PR. Looks like it's an issue in its own right. Edit: Also this one fails the unit test in the exact same way, and it only makes two tiny changes to one source file. Our changes are also tiny, and to a completely different part of the codebase. Seems either there is some kind of data race in the unit test code, and/or some broken config data is being persisted that isn't being detected by git/hub. Really hard to say. What we do know for an absolute fact is that the unit test passed before i removed those two empty lines from transaction.go, and has failed with the same error on both subsequent runs. Very weird. |
|
A different aspect: this way, arb bots will have 100% confidence about how txs will be ordered, thus instead of sending multiple txs, they "mine" the arbitration opportunities, which is even easier and more predictable. remind me, what's the purpose again? |
Why is this a bad thing?
Thus hugely reducing spam. You are against this? Why?
What do you even mean by this?
Your tone smacks of trolling. Maybe read the rationale and points raised in the linked issues before criticising a proposal you don't understand. |
|
I find it interesting that someone who works at a validator finds hash based sorting bad. And someone else who works at 48Club downvoted the pull request without making any counterarguments. But anyway I have the feeling that half of all validators are corrupt and exploit MEV on their own because sorting is not traceable (just a guess). I agree in all points with @ktrout1111
Currently i can assure that arb bots have a confidence of 99%. This is due to the spamming of transactions. Also, a corrupt validator can sort transactions as he wants without this being traceable. A big point of the blockchain is also traceability, or would you (@48ClubSirIan) disagree with me? |
Very telling indeed! A real sign that at least one of the validators is indeed happy with the status quo (to the detriment of anyone running a full node). Us outsiders can of course only speculate as to exactly how they benefit, but one obvious reason is the fees they rake in from all the spam txs, especially when some blocks are as much 50% spam txs from a single bot. Edit: So this raises an interesting point. The original change to order by arrival time made by the Eth devs would likely not have been objected to by the miners, since Eth blocks are always saturated, so spam arb txs (or the absence thereof) would not have much impact on their fee revenues. On BSC, however, that is not the case, due to the much higher, mostly vacant, block capacity. Reducing spam is good for node operators and end users, but not for validators. |
|
If this PR doesn't make it we all should know why... The overall health of the network would greatly benefit from it since block space wouldn't be wasted and hardware space with it. At some point it won't be feasible to run a node for most of the people which is obviously terrible for the network.
How does that matter? Someone will arb it anyway with arrival time or hash sorting, the advantage is that all arb bots do their computing outside of the chain. Also, arbitrage is a good thing.
Have to keep in mind that ETH gas fees are also way higher. On BSC you pay around 0.05$ which enables and incentivizes certain parties to take advantage of that. |
That's the idea. It would drastically reduce block spam, network spam, and level the playing field for arbitrage, as well as improve transparency. |
|
Good work. Any comment from devs yet ? |
I don' think this should be merged since it does not inprove most things you mention. Let me start by saying that the tx order by time was not "silently merged" like you are falsely stating. Why it doesn't improve block spam: Why is doen't improve network spam: Why it doesn't level the playing field: Why it doesn't reduce the "fake" nodes: Why it doesn't effect the storage: Why it doesn't improve transparency: As i mentioned earlier, ethereum had this disscusion already two years ago. They concluded tx by time is the best solution. We should follow their lead and keep the existing system. |
There was none on BSC. We simply found out about it after the fact (new build released with this different block ordering mechanics).
Do you have any proof that it's possible to arbitrage using single or a small amount of nodes? Are you referring to BSC right, not ETH? I know for a fact that the fastest "bots" use hundreds of nodes (heavily modified) on many different locations. Now, I can't and wont reveal private details on a public forum but this was revealed directly by a bot operator. @TxByTime Are you affiliated with any bot/node operator on eth or bsc? You created a new account just to come reply to this thread, seems quite intriguing why. |
|
Honestly, I find it strange that suddenly developers of validators and now also someone with a new github account replies here and is against this pull request. cough
I don't think you should compare ethereum to bsc. The way it works is completely different.
With ethereum, tx spam only makes sense if there are large MEV opportunities due to the transaction costs. with bsc, hundreds of transactions are already sent for 1-2$.
I have logged over a week at 3 nodes my peers, about 30% were with a duplicate ip but different publickey. i'll look it up and post it later here on github
If you are in the business yourself, then you know very well that this is not the case ;)
Again: ethereum and bsc are different blockchains. Just because something works well for ethereum (POW) doesn't mean it will work well for bsc (PoSA). |
|
I don't personally see why TxByTime's account creation time matters - every point he brings up is valid. Such a change will only centralize MEV and support "the rich get richer." Those with the most hashpower will continue to dominate, smaller fish will get crushed, validators will still be able to order however they want without anyone knowing, and spam will still be a problem.
Mining a good hash that's at least 1 bit closer won't take long, and bots will likely continue to spam new txns for every extra bit accuracy they get. |
Fine, I will forgive you for not knowing the prisoner's dilemma and believing you are the only one who is able to add gas prices. |
It doesn't change anything, 'cause it doesn't depend on a single tx sender that how big a raise will effectively work. |
Have you actually read the suggetion from henopied? He already provided some information on how this implemation would look like. Could you please point out what he might have missed or some flaws in that idea? If they cause users to get out of sync, force the nodes to help them sync or drop them base on the suggestion from henopied
This PR does not remove the incentive to remove these fake nodes. They gain the same advantages from them for their PGA strategies as their backrun strategies. They will still be there if it gives them any advantage for there. You seem to ignore this argument. |
also i think we are talking about two different points here. the fake nodes don't care about peers that are not yet fully synced, since they don't forward txs anyway (as i understand it). and after a peer becomes a full node, we shouldn't force other peers to send blocks or txs, since i can well imagine that this will make the network unstable since never all nodes are equally synced. you can give as many implementation ideas as you want, but detecting fake nodes (which can't be bypassed) and without running the risk that the current network suffers from it will be difficult and in my opinion impossible, which is why we should remove the incentive to want to run such a fake node altogether.
there is no argument if you do not describe it. simply saying: they use fake nodes for "PGA strategies" is not an argument |
To all participants:what do you think if each side summarizes their arguments and counter-arguments, posts them here and then there is no further discussion until a bsc maintainer is there? this PR is much too big to have an overview of arguments here. then we have two pro/contra texts at the end that summarize everything briefly |
First I will point out that he should not need to describe it - it has already been described many times here. But let me reiterate it once more, and pray that it will actually be read in full. I feel that this will also serve as an overview of counter-arguments as you have asked for, and a collection of ideas that I believe to be better for BSC than this PR. So lets play this idea out. So I'm running a bot, and this PR is successfully merged. Now I must switch my strategy to mine for best hashes (which of course goes without saying that it has negative impact to environment, and honestly would be a huge regression for DeFi). So I mine a decent hash, submit it using my connection to validator and/or network of fake nodes to gain latency advantage, and wait. Then - oh no! Using my network of fake nodes to gain a larger presence and low-latency access to the mempool, I'm able to see that a better hash has been submitted by a competitor. Now I must mine another hash, submit it, and - oh, well now both my transactions will land on-chain. Why? Because once the txn has gotten far enough on its way to validator, it can only be replaced by fee bump. As this PR pushes for hash sort only for same gas price, fee bump will not be possible if we want txn to order before/after a trigger txn of set gas price - so a completely new txn must be submitted. Yes as better and better hashes are found this will become exponentially slower, but perhaps will iterate a couple times per opportunity amongst all the bots. This is the new form of priority auction that this PR will cause and inherently will still incentivise fake nodes to gain a latency & txpool advantage, while also worsening the issue of spam by causing every 'better' transaction to actually land on-chain, rather than only existing in mempool. Now we have an even worse issue - more blockspace is taken up by botting, while still having the issue of incentive for fake nodes, and incentive to connect to or make deals with validators. And, of course, this PR would also centralize MEV among those with the most money. Even if I can buy 1% of total hashrate, I will waste so much on gas fees during the 99% of fails in futile attempts to beat whales that it will not be feasable to attempt this. Maybe one could argue that I can 'sit out' of opportunities if I see that someone already has better hash, but how will I have any chance to know this without my network of fake nodes to cheaply gain large presence and low latency access in mempool? And maybe whales have direct connection/deal with validator, and can afford to wait a second or two before submitting their transaction. As arrival time no longer matters, they can afford to wait long time to get best hash before submitting. Perhaps I, the small fish, do not have this luxury and will see it only after I have submitted my txn earlier and inevitably wasted money on gas fee. It becomes quite clear that this PR will only worsen the situation on BSC, and a better solution must be implemented instead. In p2p 'eth' subprotocol, peers are supposed to advertise hashes of block headers, bodies & txns that they are aware of, and under official spec can be penalized if they refuse to honor this at a later time. A very simple enforcement that peers must consistently advertise & honor these can go a long way. Something like this overview: td: means total difficulty, measurement of how synced they are. -if the remote node is < your td on connect, ignore txns from them (they aren't synced and can't possibly have validated the txns they're sending - will stop us from helping 'fake nodes' send their spam txns) and help them to sync if they ask for it. if they don't ask for it after X time has passed, kick them and put them in timeout. We aren't clearly helping them sync and they aren't helping us, no point to be connected. Such ideas obviously require a lot of thought and testing before they can be implemented, and would require a commitment from a team of smart people. Most likely this idea would need to be entertained by core bsc developers, but I feel as though this is a solid "starting point" to get the mind going. I will also once again quote henopied's similar ideas on the subject:
(Though I hate to again repeat the discussion, I feel that to prevent unnecessary repetition in further comments I must quickly repeat this here. The quote that "your requests will increase your bandwidth so some operators may prefer to keep an actual node" has been discussed, and I would agree that it is likely that they will not switch to full nodes over 'fake nodes,' but regardless would be forced to make their "fake nodes" helpful to the network if such a system was put in place.) I feel like the focus should be shifted to perfecting ideas such as these, as such ideas will be far more helpful to BSC and will not have the major downsides that this PR imposes. |
|
In addition to the post of MrSonicMaster i want to add: Why it should not be merged:Why it won't significantly reduce tx spam:I have shown here #915 (comment) that this bot thats accused of sending hundrets of tx per opportunity is actually only sending about 1.4 tx per block on an average day at about 300k gas out of 80m block space. This is not spam. Why it won't get rid fakes nodes:What this PR claims they are: "fakes that only exist to flood the network with their own arb txs and censor all other txs and block data" The fake nodes will also still be there if it gives some advantage for backrun strategies: flood the network with fake transactions, censor a better hash of a competitor, send a tx to the validator at the last possible moment, give a few ms more time to mine hashes and maybe some other adverse methods we are currently unaware of. The real extent of this problem is unkown: no one has provided any actual or recent data on how many of these might exist. Why it won't significantly reduce fake nonce tx spam:What are they? Same nonce tx with the same sender, but some difference (gasPrice, data, gasLimit) and different hash. Any advantage these might give bot operators for their backrun strategies also apply to PGA strategies. Like above, I can explain more details about PGA to the maintainers in private. They will also still be there for backrun strategies: There is no data if this is a problem and how big it is. Why it will not level the uniswap arbitrage playing field:Only the big whales with most of the hashpower would be able to compete. The whales will be able to rent ASICS mining farms from their past profits. No new player will be able to enter the game. Any small player that can currently compete would not have a chance anymore. MEV would be further centralized. As WatchDogReport said on the BNB chain discord: Ethereum decided against this two years agoEth and BSC are not that diferent in term of centralization: https://etherscan.io/stat/miner?range=1&blocktype=blocks The Top 25 mining pools mine close to 98% of all blocks - the best and openly corrupt one mines even more than 25% at the time of this writing. Locating these 25 is just as simple as locating the 21 Validators on Bsc. No other chain running on geth, even those with worse tx spam situation like polygon (maticnetwork/bor#292) are discussing tx order by hash. Ethereum, with a lower tx/s capacity and blockspace to absorb spam as bsc has decided against it two years ago. ethereum/go-ethereum#21350 ethereum/go-ethereum#21358 Apparently some of the discussion was held in the Ethereum devs discord or other forums and not everything regarding this is on github. Some of it can be found here: discussion. It turns part of BSC into a POW networkUseless waste of huge sums of money, bad for environment and public reception when some chains already switch from POW to POS. If someone wants to add something here, you are free to contact me. |
|
I will now summarize my view of this PR for the last time. Perhaps I will respond with references to this comment, but no longer argue because we are going around in circles anyway. Why i think this PR should be merged (my personal summary)1. Resolves pending tx spam
2. Resolves unique tx spam (for arb mev at least)
I would like to quote a comment from @ktrout1111 at this point.
3. Resolves fake nodes
4. Ethereum devs were against tx hash sorting
5. MEV
of course, this PR is not a cure for all problems, but it should be remembered if it turns out that it only improves one point and does not harm the BSC network. I'm sorry if I haven't mentioned some of the counterarguments here, but this PR has become so confusing that I can't keep up. i will change this comment if there is any new insight |
|
So some private companies already partnered with some validators ( 3 or 4 ) for private transactions. So no one cant believe me validators are fair and not changing/manipulating tx order. With this change we can review and confirm tx order and prevent manipulation. Also ive seen some guys mentioned whales may pre compute hashes on bulk and use it regularly for backrun. This wont work since nonce , tx data and backrun gasprice changes dynamically. So they cant just pre compute hashes and use the txs from hash pool or something. Currently network is unhelathy, operating a binance node cost approx 700$ because of high performance I/O and nvme needs. That fakes nodes not even helping the security of the network and on top of that they are just congesting network with that spams. We should atleast get some comments from the dev team on this case. |
They appear to have a code of silence on this matter (the MEV side of it anyway). The extreme centralisation of MEV on this chain caused by sorting by time has been mentioned in several other issues over the last year, and the contributors won't touch the issue with a 10 foot pole. It's all very mysterious. |
|
The |
Agree with @48ClubIan |
--- This make no sense, if you have such feeling, what is the purpose of this PR? The modification is for validators, is't it? I talked with most validators, they did not sell special service except Nodereal, and Nodereal limited the function of Direct Route to provide only privacy rather than MEV in their latest update.
---- Flashbots controls more than 40% hashrate, would you say Ethereum is not decentralized? |
|
@guagualvcha
those were secondary reasons (which was a personal assessment) but not the main reasons i had listed here
but i think everyone here is also aware that currently every mev tx is sandwiched anyway. no matter if with or without this PR
all traffic on direct route is routed through a domain belonging to a single validator. let's assume that all participants (so that they are not frontrunned for example) use this service: then nodereal would always have control e.g. which tx are forwarded to the other validators and which are not. so i conclude it's only a matter of how many people use this service before it becomes a problem. apart from the fact that you are forced to pay 20GWEI there because otherwise the tx is rejected (probably then that's the fee for this service). does this sound like decentralization if all txs run through one endpoint? |
|
@guagualvcha
In order for a single entity to be confident they can pull this off, they would need nearly all of the hashrate, no? It's already known there are 2 or 3 big players, so if one has 40%, another 30%, and another 20%, with the remaining 10% made up by smaller players, then even the biggest whale has only a 0.4 * 0.4 = 16% chance of a sandwich attack not being sniped. |
|
@guagualvcha
How can they possibly have 100% confidence of the tx ordering? Assuming all players openly submit their best hashes, they can see (not taking into account latency) the current best hash, which only has a probability of being theirs. Assuming players don't openly submit, and try to conceal them by submitting only to validators at the last moment (which would be very tricky to do, considering how geographically centralised the nodes are), then in the worst case it becomes a blind auction where each player uses a probability heuristic to determine whether or not to send a tx. His argument is a disingenuous non-sequitur backed up by no evidence. There are many such claims in this thread, most of which I have debunked if you have the time to read further up. I understand if you don't, it's become very long. |
Could you clarify what you mean here? In what way is every mev tx sandwiched already? What do you mean by "sandwiched" in this case?
First, you appear to have misunderstood @guagualvcha's argument - all traffic for flashbots is routed through a domain belonging to one company, who can chose which txns to forward to the miners and which ones not to. Do you argue that eth is centralized? It seems you are trying to argue that nodereal on bsc is any different than flashbots on eth. In fact, nodereal can in some ways be considered more "fair" in the way that it does not provide help for sandwich bots (by requiring bundles must only have txns from same sender). You make the incorrect assumption in your example that "all participants use this service" - which is not true and never will be. There will always be other options, hence the title "decentralized." Not one company "controls" or "enforces" who you submit your txns to. You have the choice. If you want to have shielding from public mempool, you muse use directroute or flashbots services, and pay their fees. If you do not trust nodereal or flashbots to be fair in distributing your vs others txns then you may chose not use it - just like you may chose to run your own node, or trust the one hosted at bsc-dataseed.binance.org.
I don't see how you conclude that that hashrate distribution has any relation to a sandwich opportunity not being sniped. With at least one person mining for it, every opportunity will be sniped by whoever had enough resources to win the competition. Unless, by pure chance, some other unrelated user submits a txn at just the right time to accidentally "beat" everyone - though such situations are negligible in probability.
How can they not have 100% confidence about ordering if the ordering is deterministic? What you are describing is not how txns will order within the block, but rather how probably it is that their hash is the "best" one submitted. Yes, maybe they will not know realtime if they have won the competition, but they will know that this will give them a deterministic approach - closest hash to trigger txn = win, 100% confidence. More hashrate = better win rate. Not even just more predictable, it is 100% predictable. also @lennybakkalian I thought you were pushing for final comments to be put, then wait for bsc team to come and make their decision. Now we have done that, and bsc maintainer @guagualvcha has commented, yet we are still in debate? I feel this PR is now concluded, and should be closed in favor of better solutions. |
Why is that a problem? This confidence (whether it is elicited by scanning the mempool or by porbabilistic modelling) is what would alleviate the current high levels of block spam.
It's entirely unpredictable for any player to know ahead of time if they will win an arb. What are you talking about? All they know is their approximate probability of winning by calculating their relative hash rate. You could make the same argument about the current system - more nodes = better win rate. What's your point? |
I wasn't sure if @guagualvcha had read my summary, as he was referring to other points which were not a primary reason for this PR. |
I would ask that you to read what I wrote and comment on that rather than cherrypicking bits from it. I'll quote myself:
With current system it is based on latency, where there is an upper bound to how low you can get it. You said it yourself that many nodes are "geographically centralized" so this can be optimized easily (quality beats quantity). With sandwich attacks, there is risk involved with current system as latency is not deterministic - with deterministic txn ordering, sandwich attacks become more viable.
I see, hopefully we can get more of bsc team to come in here and make a final decision. I'm sure we are all tired of this by now. |
OK, I get you now. The use of the word "deterministic" threw me off. What you are saying is that under sorting by hash, a bot can decide whether a given tx comes before or after a mark, whereas under the current system each tx could occur before or after. The latter fact is then used to argue that sorting by hash increases the viability of sandwich attacks. OK, that sounds reasonable on the surface but surely it's reasonably straightforward to write a contract that automagically detects whether it has landed before or after the mark. It seems a little fiddly, but doable to a reasonable margin of error. This strategy could then work regardless of the tx sorting algorithm. |
In theory, I'd agree with you, but my practical experiments have not backed this up. I don't fully understand why it is apparently necessary to run hundreds (or at least dozens) of nodes to get the edge, when nearly all nodes are clustered in 10 data centres around the world. It probably has something to do with always needing to have a node in the square root of the nearest dataseed peer. The margins are probably razor thin in most cases (<1ms), but enough to make all the difference. So, whatever the reason is, quantity does matter. |
|
This has been fully discussed in ethereum/go-ethereum#21350 (comment) , agree with the statement that: Hash ordering is a deterministic sorting algorithm that makes the winner always win. While P2P connection latency is a more uncontrollable factor, the randomness of transaction propagation protocol also erodes the geographical advantage. It is fairer for the small fish. There are two kinds of spam we are talking about here. 1. P2P networking spam: the spam transactions sent by fake nodes; The transaction is sent by the same sender with the same nonce, the txpool will discard the duplicated tx, it won’t cause traffic flooding over the network, seems sustainable so far. 2. Spam transactions within blocks. Random ordering will encourage spam transactions, Receive Time and Hash ordering are better choices in this aspect. In general, deterministic and totally random sorting algorithms are something we want to avoid, the current implementation is a trade-off. This PR will affect a lot of arbs and liquidation providers, no rush decision should be made before we get a very very STRONG reason. |
While that is possible for certain things, sandwich attacks are not atomic. You must frontrun with a buy, then backrun with a sell in 2 separate txns. Since each txn lives in its own VM, it can't know whether or not the other has been successfully executed or was in the correct order.
Yes, now that you remind me of the random txn distribution I can see why more connections to the same people can improve latency. I guess it would make sense that, given the time these bot developers have had (and the incentive to stay on top), they will have optimized for any millisecond they can get. |
I'm aware of this. Each tx can know if its before or after the mark by calling getReserves() on the target pair and comparing against an input value. It can use storage fields of its own contract to record if the front and/or backruns have already taken place. Easy peasy. So even under a scheme where "deterministic" ordering isnt endemic, it can be emulated with little trouble. |
This is correct, you can tell during inclusion if you are in a position to execute the buy at equal or better position than the off-chain math was computed with by passing 'reference' value in calldata and using getReserves (slippage tolerance). You submit buy+sell in the same packet, and rely on gas price to order the 'buy' ahead of the target, and rely on latency advantage to get the 'sell' directly after target. But imagine a competitor is 1ms faster than you, but uses a lower but still effective gas price than you for the 'buy' (ex. target is 5gwei, you used 6 gwei, he uses 5.5gwei). Now it will order like this: your buy, his buy, target buy, his sell, your sell. You can not conclude from EVM that his buy was after yours, or that his sell was before yours. You can pull tricks to minimize risk - but no matter the scenario, the current system will imply some form of risk. |
|
Will close this PR with no plan to merge in short term. |
|
a bit sad that the maintainers did not even address the individual points of criticism (e.g. fake nodes) for such a widely discussed topic. |
Any PR like this that would interrupt the flow of profits to the richest people has no chance of being implemented. I'm sure Binance itself is one of the major competitors running tons of spam nodes, and they aren't going to cost themselves money. I would have liked to see it happen, but I knew it wouldn't. I think we all did on some level. Any explanation they would have made other than "we are protecting the profits of ourselves and the couple of other giant players" would have been a lie, so instead they just said nothing. Rich people stay rich by building moats around their castles and defending them from the masses by any means necessary. That's all that has happened here. Either raise money to build out the infrastructure to spam the network at a level that will bring it to its knees, or quit MEV on BSC. Those are the only choices we have now. |
Description
This pr changes the ordering of equal-gas-priced txs to be lexicographical by hash rather than by arrival time.
Rationale
About a year ago, version 1.10 silently merged in a change made by the Ethereum devs in a bid to mitigate spam by arb bots. They changed the sortation method of gas-equal txs from random (map key) to the time they were first seen by the node. This change has very negatively affected BSC, due to the huge number of fake spammer nodes that each bot owner now has to run in order to beat the competition.
Before 1.10, there was indeed tx spam by arb bots on BSC, but now not only is that spam now far worse (a single bot owner very often sends hundreds of txs per block to grab the high value arbs), but a very high proportion of the "nodes" on the network aren't actual full nodes at all - they are fakes that only exist to flood the network with their own arb txs and censor all other txs and block data. This is all easily seen with some basic per-peer analysis of the txs that pass through eth/fetcher/tx_fetcher.go - the majority of "nodes" are in fact bad actors - so many of the syncing problems honest full node operators experience could well be influenced by the fact that only a small fraction of the MaxPeers they have set in the config are actually legit peers.
Another issue with the "first seen" tx sorting method is that we have to take it on faith that the validators are indeed ordering by the time seen and not giving preferential treatment to friends. Sorting the txs by hash would eliminate a lot of doubt, as violations of the rule would be easily spotted. Yes, they could delay "unwanted" txs by a full block, but that would look very obvious.
Sorting txs by hash would create a negative feedback loop as far as spam is concerned. As each bot hashes, the probability per second of beating the current best hash diminishes, thus therefore so does the overall rate of bot txs per arb. It would significantly reduce the block size and demands on I/O space and bandwidth, going a long way to solving the problems that have plagued full node operators for a long time.
As discussed in 269, 911.
Changes
Notable changes:
N.B. commit is tagged "eth" by mistake - it should be "core"