Skip to content
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

core: change ordering of txs of equal gas price from arrival time to hash #915

Closed
wants to merge 7 commits into from

Conversation

ktrout1111
Copy link

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:

  • add TxByPriceAndHash type
  • replace TxByPriceAndTime with TxByPriceAndHash in TransactionsByPriceAndNonce

N.B. commit is tagged "eth" by mistake - it should be "core"

Copy link

@lennybakkalian lennybakkalian left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

EDIT: my summary of this PR: #915 (comment)

@ktrout1111 Can you merge my pull request where I fixed the unit tests?

lennybakkalian and others added 2 commits May 18, 2022 01:55
@ktrout1111
Copy link
Author

@ktrout1111 Can you merge my ktrout1111#1 where I fixed the unit tests?

Done. Thanks.

@ktrout1111
Copy link
Author

@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:

--- FAIL: TestBlockchain/ValidBlocks/VMTests/vmPerformance/loop-add-10M.json (4.60s)
    --- FAIL: TestBlockchain/ValidBlocks/VMTests/vmPerformance/loop-add-10M.json/loop-add-10M_Berlin (0.00s)
        block_test.go:52: test without snapshotter failed: unsupported fork ordering: eulerBlock not enabled, but berlinBlock enabled at 0
        block_test.go:55: test with snapshotter failed: unsupported fork ordering: eulerBlock not enabled, but berlinBlock enabled at 0
--- FAIL: TestBlockchain/ValidBlocks/VMTests/vmPerformance/loop-divadd-unr100-10M.json (5.81s)
    --- FAIL: TestBlockchain/ValidBlocks/VMTests/vmPerformance/loop-divadd-unr100-10M.json/loop-divadd-unr100-10M_Berlin (0.00s)
        block_test.go:52: test without snapshotter failed: unsupported fork ordering: eulerBlock not enabled, but berlinBlock enabled at 0
        block_test.go:55: test with snapshotter failed: unsupported fork ordering: eulerBlock not enabled, but berlinBlock enabled at 0
--- FAIL: TestBlockchain/ValidBlocks/VMTests/vmPerformance/loop-divadd-10M.json (8.44s)
    --- FAIL: TestBlockchain/ValidBlocks/VMTests/vmPerformance/loop-divadd-10M.json/loop-divadd-10M_Berlin (0.00s)
        block_test.go:52: test without snapshotter failed: unsupported fork ordering: eulerBlock not enabled, but berlinBlock enabled at 0
        block_test.go:55: test with snapshotter failed: unsupported fork ordering: eulerBlock not enabled, but berlinBlock enabled at 0
--- FAIL: TestBlockchain/ValidBlocks/bcExploitTest/SuicideIssue.json (25.79s)
    --- FAIL: TestBlockchain/ValidBlocks/bcExploitTest/SuicideIssue.json/SuicideIssue_Berlin (0.72s)
        block_test.go:52: test without snapshotter failed: unsupported fork ordering: eulerBlock not enabled, but berlinBlock enabled at 0
        block_test.go:55: test with snapshotter failed: unsupported fork ordering: eulerBlock not enabled, but berlinBlock enabled at 0

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!

@lennybakkalian
Copy link

@ktrout1111 The test "TestLargeReorgTrieGC" also fails in the github pipeline, but when i run the test locally it works. weird.... ill look into it

@lennybakkalian
Copy link

I am getting nowhere as this failing test works locally for me. Maybe a maintainer will be here soon.

@ktrout1111
Copy link
Author

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.

@lennybakkalian
Copy link

lennybakkalian commented May 19, 2022

I believe the failing test is not coming from us, as it also fails in another pull request.

@ktrout1111
Copy link
Author

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.

@lennybakkalian
Copy link

And now the test "TestProcessDiffLayer" fails. What kind of test environment is this?

@ktrout1111
Copy link
Author

ktrout1111 commented May 19, 2022

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.

@48ClubIan
Copy link

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?

@ktrout1111
Copy link
Author

this way, arb bots will have 100% confidence about how txs will be ordered,

Why is this a bad thing?

thus instead of sending multiple txs, they "mine" the arbitration opportunities,

Thus hugely reducing spam. You are against this? Why?

which is even easier and more predictable.

What do you even mean by this?

remind me, what's the purpose again?

Your tone smacks of trolling. Maybe read the rationale and points raised in the linked issues before criticising a proposal you don't understand.

@lennybakkalian
Copy link

lennybakkalian commented May 22, 2022

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

this way, arb bots will have 100% confidence about how txs will be ordered

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?
If someone wants to make a transaction without the arb bots finding it, they can use the "Direct-Route" of NodeReal. (Which in my opinion also sucks, because it breaks the decentralization and openness of the blockchain).

@ktrout1111
Copy link
Author

ktrout1111 commented May 22, 2022

I find it interesting that someone who works at a #911.

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.

@0xEcE
Copy link

0xEcE commented May 22, 2022

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.

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.

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.

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.

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.

jbriaux
jbriaux previously approved these changes May 25, 2022
Copy link

@jbriaux jbriaux left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would reduce noise on BSC like a lot. So it means less storage used, less computing capacity required = more people running full nodes = good :D

@ktrout1111
Copy link
Author

This would reduce noise on BSC like a lot. So it means less storage used, less computing capacity required = more people running full nodes = good :D

That's the idea. It would drastically reduce block spam, network spam, and level the playing field for arbitrage, as well as improve transparency.

@berktaylan
Copy link

Good work. Any comment from devs yet ?

@TxByTime
Copy link

TxByTime commented May 25, 2022

This would reduce noise on BSC like a lot. So it means less storage used, less computing capacity required = more people running full nodes = good :D

That's the idea. It would drastically reduce block spam, network spam, and level the playing field for arbitrage, as well as improve transparency.

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.
There were two full blown discussion if tx time or tx hash should be used. Please refer to ethereum/go-ethereum#21358 and ethereum/go-ethereum#21350. The Etherum team, including some of it's long standing core members came to the conclusion that tx order by time is preferd over hash.

Why it doesn't improve block spam:
As you can see in ethereum/go-ethereum#21350 (comment) it will just lead to a situation where bots will mine for a hash and at some point submit that tx. Now any of the other bots submits a better hash. The first bot can't replace his first tx, since the gasPrice has to remain the same. It will just submit another tx. This doesn't improve block spam.
Bot operators can't be certain about their tx placement. Their competition can just send them a "fake" transaction with same nonce and bad hash - they will never know the good hash. So they will keep mining and still spam when they find a better hash.
Block spam isn't even a problem - a failing bot tx needs only ~40.000 gas blockspace and the gasLimit is rarely reached. I personally find the spam from gamefi or nft mints more disturbing - we are already creating BAS for that.

Why is doen't improve network spam:
Same reasons as above.
Users are encouraged to use DisablePeerTxBroadcast flag - Network spam doesn't effect them. With this flag bot operators won't peer with you, since you don't propagate their tx and dont send them any.
The only bots I have seen sending hundrets of tx are liquidity snipers and liquidators. But these are rare occasion that only last one or two blocks. We should be able to live with that. A single arbitrage bot is sending maybe 30 transactions for big opportunities if you include the "fake" ones.

Why it doesn't level the playing field:
It's already possible to do arbitrage with only a single or a small amount of nodes. I haven't seen any bots that rent hundrets of VPS for that - do you have any proof for that or is this another exaggerated statement?
If the tx were to be sorted by hash this won't be the case anymore. The big guy's will rent a lot of computing power in order to generate the best hashes. This will lead to the successful bots getting even more profit since they can afford to rent the most computing power. The smaller guy's that were able to compete for some of the opportunities won't be able to compete anymore and the bar for entry of any new player will be high and unkown.
It will even open the door for some really bad MEV that I would rather not say openly here - but it will tip the scale further to the big guys.

Why it doesn't reduce the "fake" nodes:
Bot operators will still have all these nodes. If they get a tx a couple of ms faster or can send it a little later it gives them more time to mine for hashes. They won't give up this edge if they already have it.

Why it doesn't effect the storage:
A reverting arbitrage transaction will just be storage read operations. It will not have any noticeable effect on storage.

Why it doesn't improve transparency:
A corrupt Validator can still ignore the tx with a better hash and include a different one. They can always claim that the tx reached them after the block was already under construction.
I agree, that it will be possible to see if any validator is using a different sorting mechanism. But what do you propose should happen if they don't obey by it? The whitepaper does not mention that. If you merge this anyways against mine and the geth-team's advice, then this is something that should be decided by governance before merging it.
This change might be small, but has a huge impact.

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.

@b10c77
Copy link

b10c77 commented May 25, 2022

Let me start by saying that the tx order by time was not "silently merged" like you are falsely stating. There were two full blown discussion if tx time or tx hash should be used. Please refer to ethereum/go-ethereum#21358 and ethereum/go-ethereum#21350. The Etherum team, including some of it's long standing core members came to the conclusion that tx order by time is preferd over hash.

There was none on BSC. We simply found out about it after the fact (new build released with this different block ordering mechanics).

Why it doesn't level the playing field: It's already possible to do arbitrage with only a single or a small amount of nodes. I haven't seen any bots that rent hundrets of VPS for that - do you have any proof for that or is this another exaggerated statement?

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.

@lennybakkalian
Copy link

lennybakkalian commented May 25, 2022

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

There were two full blown discussion if tx time or tx hash should be used. Please refer to ethereum/go-ethereum#21358 and ethereum/go-ethereum#21350.

I don't think you should compare ethereum to bsc. The way it works is completely different.

A single arbitrage bot is sending maybe 30 transactions for big opportunities if you include the "fake" ones.

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$.
Now we have to imagine that tx sorting over the hash prevents this "wild" tx spamming. Mining a good hash is not that fast. Theoretically, a validator would only have to send its enode to an arbitrage trader, then the trader would always be prioritized. With ethereum, there are so many miners that this would not work.

It's already possible to do arbitrage with only a single or a small amount of nodes. I haven't seen any bots that rent hundrets of VPS for that - do you have any proof for that or is this another exaggerated statement?

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

It's already possible to do arbitrage with only a single or a small amount of nodes.

If you are in the business yourself, then you know very well that this is not the case ;)

If you merge this anyways against mine and the geth-team's advice, then this is something that should be decided by governance before merging it.

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).

@MrSonicMaster
Copy link

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.

Now we have to imagine that tx sorting over the hash prevents this "wild" tx spamming. Mining a good hash is not that fast.

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.

@48ClubIan
Copy link

Simple, adding 1 gwei is not absolutely cheaper than electricity for mining the hash. It's not as "probably" as you can easily say it without any evidence.

I said 1 WEI, not GWEI. 1 quintillionth of a BNB per unit of gas. Cheaper than second-hand pocket lint. It may or may not be cheaper than one single hash. I used this example to illustrate how insane your argument is.

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.

@48ClubIan
Copy link

After they "connects to a full node to query the state there" and relay the response to the requester, the issue that fake nodes cause will be solved. Now people who are connected to them will be able to sync from them.

this assumption is completely wrong. you are talking about request/response syncing here. But that's not how eth p2p works. Do you want to query blocks & txs blindly from a node? If some nodes are a few minutes behind and don't have this information, what should happen? Currently a node only requests information where it knows that the peer has it and that should not have changed. What you are proposing is a deep intrusion into the p2p protocol which should not be enforced at all.

Simple, adding 1 gwei is not absolutely cheaper than electricity for mining the hash. It's not as "probably" as you can easily say it without any evidence.

maybe you should read correctly: he said 1wei. hardware to calculate hashes is more expensive than adding 1 wei in a tx

It doesn't change anything, 'cause it doesn't depend on a single tx sender that how big a raise will effectively work.

@TxByTime
Copy link

TxByTime commented May 29, 2022

ktrout1111

So how would this be implemented? I'm not against the idea at all, it's obviously a good one - but what does the implementation look like? During my analysis I found many "types" of apparently fake nodes, and had to use some very ugly, inaccurate heuristics to detect them, and even those often fell short. What criteria would we impose upon a node in order to accept it as "real"?

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

As @lennybakkalian has pointed out, better to remove the incentive for running fake nodes than trying to tackle the problem directly, IMO.

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.

@lennybakkalian
Copy link

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

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.

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.

there is no argument if you do not describe it. simply saying: they use fake nodes for "PGA strategies" is not an argument

@lennybakkalian
Copy link

lennybakkalian commented May 29, 2022

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

@MrSonicMaster
Copy link

there is no argument if you do not describe it. simply saying: they use fake nodes for "PGA strategies" is not an argument

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.
-if the remote node is synced (their td >= our td), and they never advertise block bodies or headers, or repeatedly refuse to reply with helpful data on request when they had advertised that they know it, then kick them & put them in timeout for X amount of time. They don't need help syncing, and aren't helping us at all so why stay connected. This forces the "spam bots" to serve data that benefits the network, and stops the issue where half of peoples peers are not helping them to sync.

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:

If the problem is fake nodes, we should ask what problem we want to solve. Do these nodes make it harder to sync? If this is the primary concern, enforcing nodes to respond to requests for data will improve syncing. Even if fake nodes proxy data requests, they will allow other nodes to stay synced. However, I doubt this is an issue because there should already be a checkpoint challenge system for ensuring peer nodes are in sync when the node is out of sync. This mechanism might need to be tested to ensure it works as intended, but if it does, then these nodes should not make it harder to sync. Anyways, passing your requests will increase your bandwidth so some operators may prefer to keep an actual node. Perhaps we should cherry-pick ethereum/go-ethereum#24652. Additionally, we could try to (maybe with help from the eth team) create a system where you can prove knowledge of the chain in a way that can't be proxied (probably involving some proof with chain data and your pubkey.)

(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.

@TxByTime
Copy link

TxByTime commented May 29, 2022

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.
This 1.4tx per block would not even be completly removed. As has been pointed out, there will still be spam each time a better hash is found.
There is no proof from the other side that tx spam or blockspace is actually a problem affecting the BSC network.
BAS will free up even more block space.

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 winner of a backrun is whoever has his tx first at the validator. The winner of a priority GAS auction (PGA, happens for CEX-DEX, Crosschain, Sandwich and other Strategies) is whoever has the highest priced tx at the validator during block constructions. Any advantage these fake nodes might give bot operators for their backrun strategies (get a target tx faster, sending fake nonce tx, censor other tx, getting it faster to a validator) also apply to PGA strategies. We have already established that this PR will not get rid of PGA's. This means the whales will still need these nodes to be able to compete against other whales for their PGA strategies and this PR would not remove any of them. I apologize if I do a bad job of explaining PGA's here. I would be willing to explain it to the BSC maintainers in private if they have any question regarding this argument or strategy. I'm obviously not leaking everything about this on a public forum.

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.
If there is actual proof of this being a serious concern: There are different suggestions here on how it would force them to be good citizens.

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:
Whales will use them to show the competition a tx with a worse hash than what they actually already have at the Validator. This is to confuse them about their actual tx with a better hash and to get the competition to submit a tx with a hash that would not be good enough. This type of strategy is called draining of inventory and something similar is already happening - I will only share details about this with the BSC maintainers in private.

There is no data if this is a problem and how big it is.
Users should use DisablePeerTxBroadcast anyway, they would not even be affected by fake nonce spam.

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.
It is possible to compete for these small players under the current system, even if the other side claims that is impossible. This PR would make it impossible to them to continue competing. I can share some of these small players making about $10k/month to the BSC maintainers in private. I will not leak them on this public forum, since this would lead to them being copied and destroyed.

As WatchDogReport said on the BNB chain discord:
DeFi is inherently meant to be, well, decentralized and MEV is vital to healthy market. Everyone should be allowed to participate in such activities with success rate equal to effort and brainpower, not money & hashrate.

Ethereum decided against this two years ago

Eth 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 network

Useless 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.

@lennybakkalian
Copy link

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

  • txs with the same nonce and gas price but with a different hash are spammed in the p2p network, because full txs are only forwarded to a handful of peers due to (peers/sqrt) in order to reach the validator as early as possible. after this PR hashes would have to be mined outside the network to influence the sorting, which would make spammed pending txs unnecessary.

2. Resolves unique tx spam (for arb mev at least)

  • currently several txs from different addresses are sent to the same contract for an arb trade (also in the hope to land as early as possible at the validator similar to pending tx spam).
  • with this method, exponentially fewer txs would be sent out by an arb trader, as it becomes harder and harder to find a better hash. also, it would make no sense to send out a tx right after an arb opportunity, as that hash will be outbid by the competition anyway. and as it becomes exponentially harder to find a hash, there will end up being only a handful of arb trades.

I would like to quote a comment from @ktrout1111 at this point.

You and others have repeated this, implying it is a rapid, regular thing, like machine gun fire, when in fact the rate at which a better hash occurs for any given miner decreases exponentially with time. This is even without taking into account the extra diminishing effect of listening to the mempool for the current global best hash. This is easy to prove. At the beginning of each "game" the probability of the next hash being lexicographically after the mark tx is p0 = (b0 - m) / (2^256), where m is the hash of the mark tx, and b0 is the current lowest known tx hash greater than m.
How b0, and thus p0, is determined is somewhat hazy but also irrelevant since bot operators will heuristically determine a realistic threshold distance (b - m) value that must be achieved before they send any txs. So let's say p0 = 0.001. Once they find a hash better than b0 - let's call it b1, they may or may not spam a tx (they will hold fire if the global best hash in the mempool is already better than theirs). Now, b1, by definition, has landed uniformly randomly in the interval (m, b0). This means, on average, the probability of subsequent hashes (b2) being better than b1 has now been halved. In extreme cases the probability might only be shaved by 1% or by 99%, but amortised over time, the probability is halved each time a better hash is found, damping any spam exponentially over time.

3. Resolves fake nodes

  • fake nodes are currently used to bring own txs as fast as possible into the network (because of the arrival time sorting) to have the few ms advantage.
    Q: why should fake nodes be a problem at all?
    A: because these do not contribute anything to the network and only consume resources & peer slots which makes syncing blocks and pending txs slower because these nodes do not forward anything.
    Q: then just have fake nodes recognized and kicked as a peer?
    A: this will not be possible. Fake node operators will always find a way around it.
    Q: but then we verify the blockchain state or if this peer does not send new information after x seconds/minutes he will be kicked as useless.
    A: will not work either, because the fake nodes know about the latest state via a "supernode" and can thus avoid verification. also, this change could lead to peers who often go out of sync (due to e.g. bad hardware) not being able to participate in the network anymore, because they are kicked again and again for not contributing anything new (but still strengthening the network and thus not being useless). running full nodes would therefore become more expensive which could lead to less people running a full node.

  • our goal should not be to recognize fake nodes, but to take the reason to run them! otherwise it becomes a game of cat and mouse

4. Ethereum devs were against tx hash sorting

  • someone had once linked this where the eth devs discuss it:

Rai: Is the consensus to sort by arrival time?
Alexey Akhunov: It seems like the simplest option with few downsides.
Peter Szilagyi: We can definitely investigate different sorting methods, it doesn't really matter as long as it's deterministic. The other two proposals, sorting by transaction hash allows it to be mined, and sorting by account hash or addess also has a negative effect on the chain, that people will start to mine accounts, and weird things that someone left their GPU miner on it for a week and now has a priority in all transactions. I didn't like these approaches, which is why we went with firs in first out, the worst you can do is try to find a direct connection to the miners, or miners could sell a direct connection. At that point, they may as well sell priority regardless.

  • it also says here that they are against deterministic sorting, but that it would also be bad if the miners are searched for.
    Q: ok if ethereum is against hash based tx sorting then we should not do that either.
    A: but eth (POW) and bsc (PoSA) are completely different. bsc is centralized in 21 places and thanks to the cheap tx costs you can spam txs.
    Q: well then this PR provides again for POW what hurts the environment.
    A: POW would be made only by the arb traders and only so much that they outbid the competition. Unfortunately, I do not want to and can not name any numbers here because I am not so deep in this subject. But I know one thing: to operate fake nodes and to generate extra effort for full nodes is also not environmentally friendly. Maybe there is someone here who can give numbers how bad this aspket would be.

5. MEV

  • I myself am not a MEV whale and therefore, like everyone else in this PR, can only answer with limited knowledge:
  • MEV is currently very centralized as has been described and confirmed many times in the PR. It cannot be more centralized. the big players will always have more nodes, more hashpower, more everything
  • these large mev participants are most likely connected directly or at most via 1 node (sentries) to the validator to send their txs milliseconds earlier to the validator.
  • should it really remain so that only the mev participants who are connected to a validator have a chance? If so, then I'm happy to announce the scavenger hunt on validators! Will be interesting to see what will happen after validators are spammed with connection requests to get a free peer slot.

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

@berktaylan
Copy link

berktaylan commented May 29, 2022

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.

@ktrout1111
Copy link
Author

Why dev team not making any comment 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.

@unclezoro
Copy link
Collaborator

The Hash can be brute-forced as long as you get enough hashrate, so if the transactions are sorted by Nonce->GasPrice->Hash, it will cause hashrate competition, the result is that the big organization can always do both frontrun and backrun, it is easy to perform sandwich attack.

@unclezoro
Copy link
Collaborator

unclezoro commented May 30, 2022

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.

Agree with @48ClubIan

@unclezoro
Copy link
Collaborator

unclezoro commented May 30, 2022

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

this way, arb bots will have 100% confidence about how txs will be ordered

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? If someone wants to make a transaction without the arb bots finding it, they can use the "Direct-Route" of NodeReal. (Which in my opinion also sucks, because it breaks the decentralization and openness of the blockchain).

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).

--- 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.

If someone wants to make a transaction without the arb bots finding it, they can use the "Direct-Route" of NodeReal. (Which in my opinion also sucks, because it breaks the decentralization and openness of the blockchain).

---- Flashbots controls more than 40% hashrate, would you say Ethereum is not decentralized?

@lennybakkalian
Copy link

lennybakkalian commented May 30, 2022

@guagualvcha

This make no sense, if you have such feeling, what is the purpose of this PR? The modification is for validators, is't it?

those were secondary reasons (which was a personal assessment) but not the main reasons i had listed here

this way, arb bots will have 100% confidence about how txs will be ordered

but i think everyone here is also aware that currently every mev tx is sandwiched anyway. no matter if with or without this PR

Flashbots controls more than 40% hashrate, would you say Ethereum is not decentralized?

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?

@ktrout1111
Copy link
Author

@guagualvcha

The Hash can be brute-forced as long as you get enough hashrate, so if the transactions are sorted by Nonce->GasPrice->Hash, it will cause hashrate competition, the result is that the big organization can always do both frontrun and backrun, it is easy to perform sandwich attack.

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.

@ktrout1111
Copy link
Author

@guagualvcha

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.

Agree with @48ClubIan,

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.

@MrSonicMaster
Copy link

but i think everyone here is also aware that currently every mev tx is sandwiched anyway. no matter if with or without this PR

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?

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?

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.

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.

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.

@ktrout1111

How can they possibly have 100% confidence of the tx ordering?

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.

@ktrout1111
Copy link
Author

but they will know that this will give them a deterministic approach - closest hash to trigger txn = win, 100% confidence.

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.

More hashrate = better win rate. Not even just more predictable, it is 100% predictable.

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?

@lennybakkalian
Copy link

I thought you were pushing for final comments to be put, then wait for bsc team to come and make their decision.

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.

@MrSonicMaster
Copy link

but they will know that this will give them a deterministic approach - closest hash to trigger txn = win, 100% confidence.

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.

More hashrate = better win rate. Not even just more predictable, it is 100% predictable.

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 would ask that you to read what I wrote and comment on that rather than cherrypicking bits from it. I'll quote myself:

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

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 thought you were pushing for final comments to be put, then wait for bsc team to come and make their decision.

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 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.

@ktrout1111
Copy link
Author

With sandwich attacks, there is risk involved with current system as latency is not deterministic - with deterministic txn ordering, sandwich attacks become more viable.

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.

@ktrout1111
Copy link
Author

You said it yourself that many nodes are "geographically centralized" so this can be optimized easily (quality beats quantity).

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.

@unclezoro
Copy link
Collaborator

unclezoro commented May 30, 2022

This has been fully discussed in ethereum/go-ethereum#21350 (comment) , agree with the statement that:

Hash ordering is not a solution as bots will still spam better hashes as they mine them. They cannot rely on what they see in their local mempool to determine whether they will win with their last submitted hash. 

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.

@MrSonicMaster
Copy link

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.

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.

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.

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.

@ktrout1111
Copy link
Author

ktrout1111 commented May 30, 2022

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.

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.

@MrSonicMaster
Copy link

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.

@unclezoro
Copy link
Collaborator

Will close this PR with no plan to merge in short term.

@unclezoro unclezoro closed this Jun 13, 2022
@lennybakkalian
Copy link

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.

@cwazy2020
Copy link

cwazy2020 commented Jun 13, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.