search

bnb-chain / bsc

A BNB Smart Chain client based on the go-ethereum fork
GNU Lesser General Public License v3.0
2.73k stars 1.56k forks source link

Geth 1.10 txpool ordering #269

Closed patllc closed 2 years ago

patllc commented 3 years ago

Rationale

With the latest update of geth 1.10, transactions with the same gas price are ordered by receive time, rather than by random order.

This receive time ordering may not be suitable to binance smart chain. Since BSC's validation mechanism is 21 validators taking turn deterministically to wrap transactions, deterministic transaction ordering can lead to below problems : 1) validators can GUARANTEED frontrun/ backrun pending pool transactions, as validators do not need to compete for POW. For example, a validator can guaranteed front running IDO starts at a pre-determined block number. 2) since latency becomes critical after the update, nodes have less incentives to include light nodes and nodes located remotely (like in New Zealand) as peers. Nodes are concentrated located and connected. This causes the nodes become more and more centralized and defeats the purpose of decentralization.

Also, I think this change is vital and wonder is that any reason not stating it in the change list?

Implementation

The origin of this change in ethereum mainnet is to avoid spam back running transactions occupying block spaces. To achieve the same goal in bsc, could we propose the below change instead? 1) sort the transaction order by receive time, with a noise added so that order is sorted by T + N(0,sigma) 2) revert the change if the spam issue not serious. Seems to me that the 60m gas limit is not fully utilized recently.

Welcome any thoughts!

a04512 commented 3 years ago

I hope so, so many bots using same gas price to stuck the blockchain in IDO or pancake listing

daisy071 commented 3 years ago

I think this relates to below issue. https://github.com/ethereum/go-ethereum/issues/21350

Agree that bsc specific PoA nature may bring some interest conflicts due to this enhancement.

Dondudu commented 3 years ago

validators can GUARANTEED frontrun/ backrun pending pool transactions, as validators do not need to compete for POW. For example, a validator can guaranteed front running IDO starts at a pre-determined block number.

This has nothing to do with tx ordering by received time.

since latency becomes critical after the update, nodes have less incentives to include light nodes and nodes located remotely (like in New Zealand) as peers. Nodes are concentrated located and connected. This causes the nodes become more and more centralized and defeats the purpose of decentralization.

I don't see how the incentives for nodes to connect to light nodes change based on how validators order their tx.

As for your solutions:

sort the transaction order by receive time, with a noise added so that order is sorted by T + N(0,sigma)

If there is randomization involved then people will spam tx to get the lowest random number. It takes us back to where we started.

revert the change if the spam issue not serious. Seems to me that the 60m gas limit is not fully utilized recently.

It is already getting increasingly difficult to run BSC nodes - we shouldn't be trying to make the problem worse.

patllc commented 3 years ago

With deterministic tx ordering, validators and their friends can ensure 100% send the transactions earlier to the deterministic-ordered node. Internet signal latency is limited by speed of light. If my node is located in Africa, it MUST be slower than the node located next to validators.

This change has rewarded validators with higher transaction positioning, while penalizing non-validators' nodes. This problem exists in ethereum mainnet, but bsc deterministic validator order magnified the problem.

Adding a noise to receive time will solve the problem if we set sigma (standard deviation of the noise) small enough. Send and populate every transaction needs time.

Running a bsc node nowadays is difficult. But it does not imply we do not need to enhance the tools. We shall make the playground more fair to all people, not just focus on the benefits of validators. Validators are well paid for the gas fee, and preferential tx ordering is a critical change that shall have at least consulted community.

daisy071 commented 3 years ago

I think here we are addressing the issue on fairness. Given validators and their associates have the absolute advantage in transactions with the same gas price as they must be the closest with the shortest request time.

I believe Binance shall address this issue, to ensure we are participating in a fair game.

RayCCY commented 3 years ago

Kind of new to this tx ordering thing. Are you saying that as long as the validator node or the nodes in its vicinity are paying the same gas as mine, I would almost certainly be placed after the validator's transaction due to latency issue?

heliosVII-tech commented 3 years ago

If a validator wanted to insert their own transactions, and reorder transactions, they could regardless of how the txpool is implemented in the standard bsc node. (see eg MEV, flashbots, etc...) Ordering transactions with the same gas price by time of arrival in the standard bsc implementation, instead of randomly, disincentivizes spam, which is good for the long term health of the bsc network. It just sounds like you used to spam and are now frustrated that it no longer works.

IMO if binance validators started doing MEV that would look very bad, as they would be directly taking money from their users and reordering their transactions.

patllc commented 3 years ago

Everyone can modify geth for their own interest. But this does not mean we do not need to modify the default geth version.

The problem here is the tx pool logic change is favorable to validators and their friends. This is unfair especially due to bsc deterministic validator ordering.

I pointed out this undesirable change is caused by preventing spam at the beginning. I am wondering if any method can help fix the issue while promoting fairness.

I would not accuse anyone against this is having benefit due to this change. Let's focus on the matter.

patllc commented 3 years ago

@RayCCY You are right that so far as I observed, all the validators are using v1.10 with tx sort by receive time under same gas price.

Under normal market condition, most transactions are with 5 gwei gas price. Transactions submitted close to validators node will be front, while other nodes and public node (most of us just use public node in metamask) orders are at the back.

chungyin383 commented 3 years ago

@patllc if this is the case, validators can profit a lot from this change. For example, they would definitely be the first user to participate in initial offerings, front running all the other users. Validators can also make use of their advantage to do arbitrage trading on BSC, eliminating all the other regular arbitrageurs.

To conclude, this change is so-called a way to prevent spamming, but in fact, the ultimate goal is to benefit the validators with a HUGE amount of extra profit. Therefore we can expect a lot of people with vested interests to oppose your suggestion to revert this change.

chungyin383 commented 3 years ago

validators can GUARANTEED frontrun/ backrun pending pool transactions, as validators do not need to compete for POW. For example, a validator can guaranteed front running IDO starts at a pre-determined block number.

This has nothing to do with tx ordering by received time.

Yes it is related to tx ordering by received time. Consider an initial offering that starts at block X, right now the validators can insert their tx as the first tx in block X, thus front running all the other participants. @Dondudu please correct me if you think otherwise.

Dondudu commented 3 years ago

validators can GUARANTEED frontrun/ backrun pending pool transactions, as validators do not need to compete for POW. For example, a validator can guaranteed front running IDO starts at a pre-determined block number.

This has nothing to do with tx ordering by received time.

Yes it is related to tx ordering by received time. Consider an initial offering that starts at block X, right now the validators can insert their tx as the first tx in block X, thus front running all the other participants. @Dondudu please correct me if you think otherwise.

As mentioned by @patllc, any validator can always edit their own geth to have whatever behaviour they like. They can put their own tx ahead of yours even if their gas price is 0. Actually a validator will always use a "plausible" gas price to hide their behaviour since the gas gets paid to themselves anyway. This is called MEV extraction if you want to read more about it.

patllc commented 3 years ago

Yes @Dondudu Open source means that anyone can edit the code. But I think at least in the official published release, we shall equalize chances of all nodes getting earlier transaction position.

Most of the transaction concentrated in 5 gwei ( around 70% transactions in below block using 5gwei https://bscscan.com/txs?block=7960114&p=2), Unlike ethereum the gas price more diversified. This fairness issue is serious in bsc chain.

soltrac commented 3 years ago

I'm seeing this problem in some frontrunning actions. Some users are just invincible, they always put their transaction just after the needed one and the rest of users can just only look. They don't ever need to spam the 5 gas transaction, they are always ahead.

patllc commented 3 years ago

Orginally bsc chain is random validator order with random transaction position. This means that even submitting order through public node can be ahead of validators' friends. (Not to mention MEV extraction here as seems cannot avoid) It is more fair than current deterministic order and deterministic transaction position.

Can we think of some new method that can both avoid spam attack and more fair?

I have proposed 1) transaction position based on received Time plus a random noise (depending on the distribution and parameters chose, spam problem may still exist)

2) revert the change (seems not okay? Any objection?)

Is there any other method?

For the benefits of all bsc users, I do think that we can think of some new ways to improve the chain.

RayCCY commented 3 years ago

Is randomizing the mining order of validators a possible solution to this? I don't see there will be spamming this way while ensuring no one can take advantage of the deterministic mining order.

spec42 commented 3 years ago

This has to be reverted to 1.0.6/1.0.7 behaviour... I do not think it was intentionally, but 1.1.0 was released under pressure of time.

patllc commented 3 years ago

@guagualvcha Any thought ?

spec42 commented 3 years ago

If you look at this, i think this wont change.. too lucrative for binance. They have a bot at https://bscscan.com/address/0xf662b54e8f96caef0336ef44f7bef6f5921d0e51 Earnings go to https://bscscan.com/address/0x1bbb0c5cab3798b16a66220365426e8c01d091d7 then to https://bscscan.com/address/0x8def74b2df35cff9137e0fd45a0754fe31d05229 and from there directly to Binance Hot Wallet.

patllc commented 3 years ago

Well... Binance hot wallet is indeed binance official wallet... It is NOT Users accounts in binance.

Arbitragers are necessary for an efficient exchange. But is binance necessarily extracting all opportunities?

I hope it is not intentional.

patllc commented 3 years ago

@spec42 You have pointed out a serious problem.

Geth 1.10 (unintentionally) causing binance and its friends to exploit all the arbitrage opportunities. As all records are traceable in blockchain, I don't think binance is intentionally making money here. Another issue to raise is bscscan stop providing full transaction records. I need some time to dig out when the bot was created

At the same time, as most transactions in bsc is 5 gwei, the 5-gwei region is the hunting ground of nodes with preferential orders.

Hope this can be improved although the profit is really so big... binance of cause can hire computer experts to earn money from bsc chain, but the go ethereum algorithm shall be fair.

spec42 commented 3 years ago

It has to be intentionally. And i think it is unfair with the current transaction ordering, because they use their infrastructure. Sure it could be a modified node too, which i would also name as bot. Miners on ethereum can do that too, and there is no problem, but with binance owning all validators this seems strange. There is no competition possible...

daisy071 commented 3 years ago

Normal arbitrager would be suffering in this situation, but more importantly, even general user would be suffering too. As ALL users' transaction will be front run-ed or back run-ed with 100% successful rate as well. Logic of BSC chain shall be enhanced but not follow strictly to Ethereum.

zhongfu commented 3 years ago

From @spec42:

If you look at this, i think this wont change.. too lucrative for binance. [...] Earnings go to [...] then to https://bscscan.com/address/0x8def74b2df35cff9137e0fd45a0754fe31d05229 and from there directly to Binance Hot Wallet.

From @patllc:

Binance hot wallet is indeed binance official wallet... It is NOT Users accounts in binance.

Uh, isn't that behavior expected of literally all Binance user deposit addresses? Users deposit to a Binance-controlled wallet (which seems to be 0x8def here) in order to get their funds into Binance, and Binance sweeps all balances to their hot wallet every now and then.

I'm inclined to believe that's the case since 0x8def only ever transfers coins to the Binance hot wallet -- so far, it hasn't made any other transactions or contract calls.

patllc commented 3 years ago

@zhongfu agree that the address may be binance user address.

Another look at this bot. This is the spam bot people talking about. Interesting that the spam issue isn't fixed. https://bscscan.com/address/0xf662b54e8f96caef0336ef44f7bef6f5921d0e51

patllc commented 3 years ago

image

Multiple wallets sending transactions to the same smart contract. The spam issue seems not fixed. Another reason why we need to change the logic.

spec42 commented 3 years ago

Thats how those bots work. Multiple sender accounts. I would not call it spam.

About the Hot Wallet address - I think @zhongfu is right, sorry. I ignored the extra hop...

heliosVII-tech commented 3 years ago

I think we can all agree that ordering transactions by time, like ethereum does, is the best move for the long term security of BSC. When transaction spamming was viable, BSC was on the verge of collapse will full blocks and forks. Any solution other than time of arrival based transaction ordering incentivizeS spam. Also, the claim that binance runs or otherwise props up the successful bots is ludicrous. I don’t see any evidence that that is the case, and I don’t see any reason why changing the transaction ordering code in the standard bsc node would affect that if it happened to be the case. If binance validators started doing that, it would be very bad PR for them. (Also they already make $2m+ per day in txn fees, up to $6m on a good day.)

patllc commented 3 years ago

@heliosVII-tech I think we all know the change in ethereum is to avoid spam attack. But the problem we keep mentioning here is fairness.

In ethereum it is okay because of POW. No one can guaranteed mining a block. In bsc, deterministic validator order and deterministic tx order is far less fair than previous geth version. That's why I raise this issue to improve. I did not question why we need to avoid spam.

I think people opposing any change in this thread did not answer whether this change is fair or not. They just repeat stating the purpose of this change, which I have mentioned it at the beginning.

I see that this change causes the number of arbitragers decrease because only the one closest with validators take all. This is the first fairness problem.

Even it is okay to sacrifice these minority arbitragers, general public using standard gas is 100% front run or back run by those successful arbitragers, whether the arbitragers are binance itself or not. This is the second fairness issue.

I think @RayCCY solutipn to randomize the order of validators somehow is useful. Validators cannot mine two consecutive blocks are their own hardware problem.

Such important change is not stated in bsc change log. I am very puzzled why this happens.

Reve957 commented 3 years ago

There are some valid points in this thread. Binance is advertisting with "no frontrunning in the binance smart chain"

Front-running means someone can get prior knowledge of transactions from other beneficial owners via technology or market advantage, so that they can influence the price beforehand and result in economic gain, which usually brings loss or cost to others. It is a daunting question asked to both centralized and other decentralized exchanges (DEX). Especially on some DEX, front-running actually happens quite often, e.g. via gas or timestamp manipulations, or slow matching. There are several design points in Binance DEX that make front-running very difficult to execute. Source: https://docs.binance.org/anti-frontrun.html

but the latest implementation enables exactly that.

The ordering with gas price as the first priority and arriving time as the second priority makes it easier for botter to sandwich transactions and thus eliminates the statement stated above.

Also this is a step backwards in decentralization. In the ETH chain this change was required because of the blocksize which is relative small in comparsion to the block size in bsc. The outcome was that the gas price exploded in the ETH chain, but the BSC has almost a constant gas price of 5 gwei, therefore is this change not needed and should be reverted (since BSC doesn't have a blocktime of 12 seconds and also BSC blocks are 4 times larger).

If the devs keep just continuously copying the code of gETH and not stick to their own words (see citation) what is stopping this chain of becoming an 1:1 fork of gETH.

It seems that we are going in the direction of having MEV soon on the bsc (which is imo very centralized especially since we have only 21 validators).

zhongfu commented 3 years ago

@Reve957

Binance is advertisting with "no frontrunning in the binance smart chain"

The doc you linked is for Binance Chain, not Binance Smart Chain

image

The only two mentions of "Binance Smart Chain" on that page are in the top navbar and sidebar

Despite its name, MEV didn't initially involve miners -- it was just non-miners searching in the txpool for profitable txns, then spamming TXes in order to increase the probability that their sandwich TXes actually sandwich the victim's TX

This can still be done in BSC -- even though searchers with nodes that are closer to validators (including validators themselves!) will have an advantage, others will still able to sandwich TXes, especially if TXes go through their nodes on the way to the validators. So yes, MEV is already a thing on BSC (except without flashbots and all the fancy stuff that Ethereum has today)

It's also worth noting that block producers (i.e. validators, miners) will still be able to order transactions however they want, regardless of the default behavior of geth

So, reverting this change will not do anything to prevent validators from sandwiching/frontrunning/backrunning (etc) transactions

On the other hand, it may force other searchers (even those with well-placed nodes) to resort to spamming TXes again -- and while BSC has a 4x higher block gas limit and 4-5x more frequent block production rate, it'll only slightly alleviate the spam problem:

patllc commented 3 years ago

The fact that binance can influence most validators to update to 1.10 in early May means that validators so far honor the changes of default geth version binance made. are you implying that validators will not follow any enhancement that brings disadvantages to them?

You mentioned that the change is to prevent spams Txs for the benefits of all users. Do you think validators and their friends getting preferential tx position fair to all users? You mentioned IDOs. The change implied that public trying to involve in IDO are somehow idiot. Validators and their friends have absolute advantage. They just need to set the IDO block height so that the block is their own node( bsc validator order) If it is not fair, why not consider making an enhancement that can both avoid spam and be fair?

@zhongfu may I know your stance: 1) you think the change is fair. Any enhancement is unnecessary. or 2) you think the change is not fair. But the proposals in this thread are not workable. Seems you just mentioned reverting the change is not workable.

Reve957 commented 3 years ago

I think we all can agree that the update made front-/backrunning even easier for botters and one 10 gwei block is still better then 24/7 sandwich enabling

heliosVII-tech commented 3 years ago

“Do you think validators and their friends getting preferential tx position fair to all users? You mentioned IDOs. The change implied that public trying to involve in IDO are somehow idiot. Validators and their friends have absolute advantage.”

Please provide concrete evidence before making such accusations.

How is the system not fair? Transaction order is determined by time of arrival - that seems pretty “fair”. If you want your transactions sooner, get them there faster.

also, this change does nothing to make sandwiching/front-running easier or harder. All you need is a transaction before (with higher gas price), and one transaction after, which was easy to do in the old system by just spamming a few transactions. So, if anything, this change makes sandwiching use less block space, which is good.

zhongfu commented 3 years ago

@patllc

are you implying that validators will not follow any enhancement that brings disadvantages to them?

I suspect most will upgrade nonetheless, but then again -- txpool ordering isn't enforced by consensus iirc (plus, like I've mentioned before -- block producers can, in theory, include whichever transactions they want to, in any order they desire)

You mentioned that the change is to prevent spams Txs for the benefits of all users. Do you think validators and their friends getting preferential tx position fair to all users?

No, but I think it's probably a lesser evil to stick with the current deterministic txpool ordering scheme. Randomizing tx order will only make it slightly harder for non-validator MEV searchers to put their sandwich TXes in the desired position -- it'll still be possible, at the expense of network usability

You mentioned IDOs. The change implied that public trying to involve in IDO are somehow idiot. Validators and their friends have absolute advantage. They just need to set the IDO block height so that the block is their own node( bsc validator order) If it is not fair, why not consider making an enhancement that can both avoid spam and be fair?

Okay, you've lost me here. What?

I brought it up as an example of degraded user experience resulting from tx congestion, even with (theoretically) reduced spam TX from MEV searchers. The original claim by @Reve957 was that: (emphasis and elaborations mine)

In the ETH chain this change was required because of the blocksize which is relative small in comparsion to the block size in bsc. The outcome was that the gas price exploded in the ETH chain [because of TX spam], but the BSC has almost a constant gas price of 5 gwei, therefore is this change not needed and should be reverted (since BSC doesn't have a blocktime of 12 seconds and also BSC blocks are 4 times larger).

i.e., BSC will be fine even with spam TXes because theoretical transaction throughput is high enough to mitigate tx load

Evidently that's not always the case, and BSC has definitely seen worse in the past

@zhongfu may I know your stance:

  1. you think the change is fair. Any enhancement is unnecessary. or
  2. you think the change is not fair. But the proposals in this thread are not workable. Seems you just mentioned reverting the change is not workable.

I don't have a particularly strong stance on this, since I don't think it'll affect me much (I'm not a MEV searcher, after all). But I still think this change is a necessary evil to (hopefully) reduce tx load, especially from spam TXes.

In any case, a large portion of the disdain seems to be directed at validators because of a perceived disadvantage. (For the record, I'm neither a validator, nor do I have any relationship with any validator.)

But, well... don't forget that block producers can arrange transactions however they want. Reverting this change will very likely not prevent validators from continuing with MEV strategies, if any of them are currently doing so.

However, don't forget about other MEV searchers either. Reverting this change:

edit:

I think we all can agree that the update made front-/backrunning even easier for botters

not denying that

one 10 gwei block is still better then 24/7 sandwich enabling

I believe the former will happen a lot more often if this change were to be reverted. The latter -- well, reverting this change won't prevent "24/7 sandwich enabling" anyway.

Reve957 commented 3 years ago

If we order by time, to sandwich a tx we send the backrun transaction asap then the frontrun the tx with 1 wei more which is a lot easier then randomly sending a few tx. Also we will see a lot of nodes pop up in the near of the validator nodes if not in the same datacenters. Then we live again in a world where AWS controls more then 50% of the nodes which is imo a problem.

edit: I guess we are in a dilemma and won't find a final solution.

zhongfu commented 3 years ago

If we order by time, to sandwich a tx we send the backrun transaction asap then the frontrun the tx with 1 wei more which is a lot easier then randomly sending a few tx.

The alternative would be to force MEV searchers to fill the blockchain with much more useless transactions, it seems

Also we will see a lot of nodes pop up in the near of the validator nodes if not in the same datacenters.

Perhaps mostly for those interested in MEV searching. For other uses -- e.g. a local node for faster read contract calls, or digging through old TXes -- not so much.

I think it's a reasonable assumption that a quite a few of those AWS node operators do so simply because:

Then we live again in a world where AWS controls more then 50% of the nodes which is imo a problem.

The proposition that reverting this change will significantly alleviate/fix this issue relies on the assumption that the majority of the operators of the 50% (citation needed?) are doing so because of this exact issue

patllc commented 3 years ago

Seems no one is opposing enhancing the tx sorting mechanism.

Is it possible to sort tx with same gas by an utility function?

U = a ReceivedTime + b miningEffort + other parameters

The function consists of both receive time and hash alphabetical order. Nodes close to validators have advantages in receive time, but not in hash solving. For spam attackers, they cannot succeed because they can solve for better hash, but the receive time will delay a lot.

@zhongfu You mentioned that first come first serve is fair and people shall buy better equipment and move closer if want smaller latency. There are two issues.

chungyin383 commented 3 years ago

How is the system not fair? Transaction order is determined by time of arrival - that seems pretty “fair”. If you want your transactions sooner, get them there faster.

That isn't fair at all. To make my transaction reach the node faster, I need to move closer to the validators. Question 1: As a normal user, do I know where exactly the validator nodes are located? Question 2: Who can be the closest to the validator nodes? The validator themselves and their friends. A system that only allows the validator and their friends to get preferential tx orders, so this is what you call a fair system?

b10c77 commented 3 years ago

@patllc Can you share how you ended up with that image with the host distribution by country?

I also share the same view that when ordering txs by time stamp you end up giving a select few more power than the rest. It's been more than apparent lately with only a select few always getting in first right after the key tx. With a random tx block org at least you get an element of chance. Arbitration and front run bots are starting to significantly increase as well because it's much easier for them to accurately place their txs in the desired order.

misu200 commented 3 years ago

@patllc Can you share how you ended up with that image with the host distribution by country?

I also share the same view that when ordering txs by time stamp you end up giving a select few more power than the rest. It's been more than apparent lately with only a select few always getting in first right after the key tx. With a random tx block org at least you get an element of chance. Arbitration and front run bots are starting to significantly increase as well because it's much easier for them to accurately place their txs in the desired order.

It might have to do more with knowing validators locations and setting global infrastructure to hear fast about txs and forward them quickly near the validators ....otherwise why they flooding with txs the blocks were "key tx" happens?

ajb commented 3 years ago

This is a good thread. I am just chiming in to note that this is also happening on Polygon as well; despite the fact that the validators are not solely operated by Binance, there are only 100 validators at present, and I believe that this leaves them with a significant opportunity to extract millions with MEV techniques that non-validator nodes cannot accomplish.

happysammy commented 3 years ago

Interesting thread, and is there any way to find BSC validators geographic location? The arbitrageurs would like to trade with the lowest latency possible.

patllc commented 3 years ago

You can try to have all nodes around the globe and test. But I think the topic discussing here is not how to make money from arbitraging.

happysammy commented 3 years ago

Seems no one is opposing enhancing the tx sorting mechanism.

Is it possible to sort tx with same gas by an utility function?

U = a ReceivedTime + b miningEffort + other parameters

The function consists of both receive time and hash alphabetical order. Nodes close to validators have advantages in receive time, but not in hash solving. For spam attackers, they cannot succeed because they can solve for better hash, but the receive time will delay a lot.

@zhongfu You mentioned that first come first serve is fair and people shall buy better equipment and move closer if want smaller latency. There are two issues.

  • Information asymmetry. Only validators and their friends know where they locate, and validators can have sentry nodes so that only a few friends are directly connected to them.
  • because of this change, bsc chain built a transaction position hierarchy, from validators, their friends, more remote local nodes, general public in europe/Asia/north America, then the bottom is public in Africa, austrilia/other regions where few nodes located. I thought binance is promoting hard in Africa. But seems this change silently put Africa in an absolute disadvantage. image Before this change, the hierarchy is only two layers. Validators and then all other users.

hi pattlc, how to get bsc validators region?

patllc commented 3 years ago

There is no way u can get valdiator real location. U can only test it

happysammy commented 3 years ago

There is no way u can get valdiator real location. U can only test it

Thank you, I will have a try later.

myuniswap2000 commented 3 years ago

bsc have 21 nodes, and the location of each node should be different? So many different areas need to be tested？

patllc commented 3 years ago

@myuniswap2000 i think so. But even you know the location of each node, you cannot get close enough to beat the existing profit makers. If your strategy relies on latency, it needs no evidence to conclude general public cannot beat the insiders.

myuniswap2000 commented 3 years ago

@myuniswap2000 i think so. But even you know the location of each node, you cannot get close enough to beat the existing profit makers. If your strategy relies on latency, it needs no evidence to conclude general public cannot beat the insiders.

thank you,Another question, eth does not have this problem, is it because the eth nodes are relatively scattered?When will bsc improve this problem~