-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Concern: Validators may be selling special treatment and bypassing Bruno burn #658
Comments
I guess mev-geth is forked for BSC. Never seen it before, is it happen after the transaction fee burn? |
Front runnings by validators with ZERO gas price! i see 3 validators(MathWallet, TwStaking ,NodeReal) |
This more worthy than doing gas war. Waiting explanation. But I don't see any fee transfered to the validators, it's transfered only on sell transaction. |
I think these validators deserved being jailed forever. |
Zero fee transaction is considered unhealthy and dangerous for the network. |
Looks like at least those 3 validators are running MEV-GETH fork now, maybe use nodereal's directRoute will send bundles to those validators. 1/7 chance though |
I am a developer from Nodereal. As we strive to provide top quality infrastructure for BSC and more blockchain users, NodeReal are researching with some partners on some features that will benefit users with special requirements and help them to use ensure their transaction security and fairness, for example, the https://community.venus.io/t/venus-protocol-weekly-update-w40-2021-shortfall-recovery-report/1890, but not frontrun or MEV. Direct Route is such a product but still in Alpha stage. 0 gas price was a bug overlooked by the engineers, which doesn’t make sense in the economics as no validator will survive without rewarding their delegators and the network. Thank the community for the discovery. Stay tuned for the Direct Route public rollout. |
Dude we are not blind, 0 gas price comes with an internal transfer directly to your validator address. Of course not all txs go with 0 gas, there must be victim right? Delegators still get reward but validator gets extra benefit this way. |
bot:https://bscscan.com/tx/0x762e097ab15fbefeee0e91c6a444e492ec7e9e00c84cad2a4c4765e1f85efe47 Position 0 gas 0gwei so why user1 is before user2? |
Venus NFTs: Example: https://bscscan.com/tx/0x457d103487abf50ff1379549db6fc4bdc6f547ff7296aa7a884f26ebb811a8d5 This clearly is frontrunning by definition and you are risking a jail. @48ClubSirIan |
I can say for sure it's a frontrunning. |
@realuncle open to collaboration with your team or any other validator , DMs open Twitter.com/@edgararout |
https://bscscan.com/address/0xaa6b37630906e4d7ad8591a1e5124e69cf052677 |
Are you sure?
|
People: praise blockchain for censorship and centralised governance resistance. I mean... "frontrunning-as-a-service" is definitely not cool, but it is what it is... I'm honestly surprised this wasn't (im)ported from ETH sooner. |
You say not frontrun or MEV. But this is exactly "SANDWICH ATTACK" with zero fee. thats unacceptable for the trusty of network. my advice is that other validators should check the gasPrice order of the block |
Have u even read the BSC's slashing mechanism? |
Why no punishment then ? They look quite fine. |
Also looking to collaborate with validators. I have infrastructure ready for you to start getting a cut of arbs on BSC. dms open @0xclaudeshannon |
@noXi89 Why do you cue me ? ? ? |
Didn't you realize MEV means off-chain behaviors involved? |
|
Not all abusive behaviors gets automatically fined. |
Binance could easily stop validators from doing this. I wonder what regulators will think about a centralized block chain that allows frontrunning. |
Can BSC be more centralized than what it already is? Is this something we want? The thing is, validators will ALWAYS have the ability to do MEV themselves, regardless of what rules you put in place. This is the nature of all EVM chains. Specifically:
It is important to understand that validators will ALWAYS have the ability to do MEV/frontrunning/sandwich. They can in any case censor transactions and put arbitrary gas prices on their own txs as this is paid to themselves anyway. An observer will have no way of detecting this. Flashbots make these tools equally available to all participants in a fair way, and is good for the ecosystem. |
Are validators even allowed to run non-standard forks of BSC Geth? My understanding was that this was a slashable offense, regardless of what they are doing with it. None of this behavior is healthy for the ecosystem. As we have seen with Flashbots on ETH, the inevitable result is effectively all MEV going straight into the pockets of validators. The difference here is that most validators appear to be run by Binance itself, so people will see it as nothing more than a predatory Binance cash grab. Existing users will pull their money and new users will steer clear of BSC. If they aren’t slashed immediately, and this behavior isn’t explicitly banned, BSC isn’t going to have a future. BNB values will collapse. Nobody wants to throw their money into a black hole that leads straight into CZ’s pocket. |
In a decentralized system, this is an abuse of power. The system ceases to be peer-to-peer in logic, since not all are equal to each other. |
That would be true, if BSC were truly decentralized. It isn't; most of the validators are controlled by Binance, and they are all chosen by Binance. That is the difference between ETH and BSC. That makes this behavior extremely problematic; effectively what this means is that Binance is now going to take all MEV on BSC, and will actively sandwich every trade that they can. "Come to my house, I'm going to mug you". That's basically the value proposition for BSC if this is allowed to continue. How many people will participate in that? |
@noXi89 For a sandwich, you must include the transaction of the victim in the bundle to guarantee proper ordering. If the front-runner can only include one sender in the bundle, he cannot include both his transactions and the victim's transaction in the same bundle. That's why it should in theory prevent front-runners to use NodeReal services. |
Is it only one NodeReal endpoint user per bundle, or is it limited per txn sender where u can have multiple transactions in the same bundle if they are from different addresses? |
In a bidding scene nothing changes at all. |
验证者始终有优先权.而我们没有嘛....相对来说看起来可能公平点....实际没什么用.哈哈 |
但是除非是我们的节点有机会能够连接到其他验证者节点,我们就有3/21的机会不被夹三明治......否则,就呵呵了 |
Can you keep it English? Much appreciated.. |
The sandwiching continues, now they just use a unique sender for the buy and a unique sender for the sell. @realuncle https://bscscan.com/address/0x00000000008bef34003b59bed4c4c0f6f1543928 |
https://docs.google.com/forms/d/e/1FAIpQLSe1QZlGoNQ6-JOXYxrbOTYBYtQm3mmIhmAS_fjbOt6OCZqSNg/viewform Shameless. By the way if all 21 are in the boat, you could gain even more if you just exclude all tx that didn't pay a "service fee" upfront. |
Their practice violates Consensus of BSC. |
hey, where is MathWallet & TwStaking? only NodeReal cares to respond? |
If all validators did that. In the end, wallets like Metamask or new apps would use the direct route and about 100% of the transactions would go directly to the validators. The full nodes would be useless and BSC would be a centralized network of 21 friends. I think that behaviors like that have to be heavily sanctioned. Validators cannot change the rules at their convenience. |
What kinda world we are living where there's some third party (aka Nodereal) destroying the good sight of BSC and no one step in. Now next thing could be censoring txns on BSC. |
没有人关心这个...(Google translate:No one cares about this...) |
这不光是交易的问题...这还涉及了各个游戏的NFT抢购问题,所有玩家都只是韭菜(This is not just a transaction issue...it also involves the NFT snap-up issue of various games, all players are just leeks) |
@realuncle there is now a bot with uses your service to do risk-free rug-pulling on pancakeswap 🙂 good game, well played. |
This is one of the things that I fear, with the direct route service there is no way to detect liquidity subtraction. Good news for criminals. |
@realuncle You guys are upto destroying the integrity of Blockchain's for your own greed? |
I think it is better to discuss this within NodeReal's community channel, it is the delegator's choice to decide whether unstake or not. @realuncle Please share the discord, Twitter, or any other social media. We probably close this issue in few days. |
Related : #699 |
Dear community, thanks for all the feedback. We decide to improve Direct-Route further by placing the transaction within bundles in orders, the transactions submitted through Direct-Route will also obey the gas price auction mechanism, it will rollout out later this month. If you have any questions, please go to our community channel: Discord https://discord.gg/8MPvdmXyRf, https://twitter.com/Nodereal_io, and https://github.com/node-real/ |
will kindly close this issue. |
They're the one abusing the validations, and discussing on their community. |
Take a look at this transaction: 0xc5fff8dfd621b964fabcd9e240d3a6d72927edb5f5195d9d41d6eb0a1859c92a
Things to note:
There are many more of these transactions going on to the same contract address with the same behavior. At least 3 validators seem to be involved (MathWallet, TwStaking and NodeReal). The transactions are also not publicly visible from the transaction pool (Possibly they are submitted directly to the validators). Clearly, there is an agreement between the originator of the transactions and the validators and the goal is to perform front-running without risk.
MathWallet denied this, but we can all see what's going on.
Needless to say, because the gas price is 0, there is no burn (Introduced in Bruno upgrade). It's possible that this is another thing these validators are starting to explore to bypass the burn feature and maximize their profits.
Is this behavior allowed from validators? I don't believe that it's healthy for the network if validators do such things for profit. Validators are held to high standards and are supposed to be trustworthy.
For completion, here is also the buy transaction associated with the above sell transaction: 0x762e097ab15fbefeee0e91c6a444e492ec7e9e00c84cad2a4c4765e1f85efe47
The text was updated successfully, but these errors were encountered: