Keep the videos coming. There are literally very few channels that explain such imperative concepts with utmost clarity. This is channel is one of those. Thank you
Very concise and self explanatory. One thing I try to figure out is how to make one's gas fees dynamic in terms of current block, current state of gas prices and current competition on the same block.
Thank you very much Scott for the informative and potentially project saving videos. I am sure I am not the only developer who appreciates being able to see these potential threats and how to handle them. Keep it up!
A great video. But I have a little confused about how a front runner can recognize they can get benefit from this contract so quickly since you said they even don't need to understand the contract itself.
Yeah that is not explained at all. They can't front-run billions of tx on good luck. The gas fees would kill them. So how do they know in advance which tx have any kind of value?
they scan all the transactions on the waiting pool, then calculate output - input eth if its greater than some value they copy the transaction and try doing it with higher fees.
@@ichigokurosaki5707 Thats pretty obvious but the question is how can they calculate this potential profit without knowing anything about the contract in advance? Are they somehow simulating how contracts will react to a transaction?
@@cedricdb not sure if you are still looking for an answer , but yes they simulate the contract on a testnet. copy the pending transaction function calls and if their wallet ends up with more ether than they put in, they shoot the transaction to the real network and front run
@@maptuffs Thanks Mike! But the Testnet contract may have different logic and different value... So they are risking money with every such try, correct?
Great video thanks for making it! As others have mentioned, a video on how these bots simulate these transactions (testnet? local node?) would be really interesting.
First of all, thank you very much for the video. It was quite entertaining and eye-opening. Got a couple of questions though, 1. Could you explain a little bit more about the parts where you were calculating the gas price (ie. 15:22 and 16:45)? I'm assuming you were calculating how much you'd have to pay for gas in order to get your transaction included quickly, but what about the locahost tab you opened around 15:22? what was it that you were checking? 2. How would a bot like the one that sniped you know that it'd get payed if they send the same data as your transaction? I'm guessing that they don't know, and they just replicate the transactions and payload with "payable" contract functions as destination, to outbid your gas price and just hope for the best. But if that's the case, how could they know if a function is payable? is that information public for all contracts living on the mainnet? Thanks,
Hey, Scott. This is indeed a great video man. So as of now I do have a long list of questions and doubts. And also I am desperately waiting for the next video on How to solve this Front-Running Issue?
In this particular example, can't you just guard by checking that the caller of take is the same as the contract owner? That is, if a front-runner tries to copy the transaction, they'll fail because they're not the contract owner?
In your example, i see how the frontrunners took advantage of the exploit, by i dont understand *how* they knew that calling your contract with those inputs will give them eth. can u explain?
The transactions in the pool are public. Which means the sender address, the contract called, the exact transaction of the contract, the inputs. Everything is in the open. The front running bots can then go through the pending transactions and try to evaluate which one would benefit them if they run it for themselves (using the now public inputs). In order to make sure their transaction comes first they pay more gas because miners prioritize the more expensive transactions.
@@SapiensHomo-k7r thanks but you didn't answer the core question: How can they "evaluate" (in your words) in microseconds, that running this transaction would send them ETH? Even spending a little gas on millions of useless contracts can get expensive for them. So HOW exactly do they "try to evaluate" something that's only known to the contract author, or somebody who reverse-engineers the bytecode in microseconds and opine that executing this probably makes money.
@@magicmedia.channel Anyone can run solidity code anywhere. The blockchain's state is public and free to use (reads are free, writes cost validation fees). They can just have a local blockchain with the same state and run tests there. The fees are required as a mean to ensure only valid transactions get recorded on the public network. Otherwise just running the code is (often) dirt cheap.
@@magicmedia.channel Also they don't need to read the source code of a contract. They just need to run it with the current state of the main net, which nothing prevents them from by design (Otherwise nobody would be able to validate transactions)
Great video, straight to the point and with a really good example. Only critique is what sounds like a door closing in the distance or perhaps footsteps above periodically.
amazing video thank you for sharing and spending your money to teach us!!! For these kind of attacks the first thing that comes to mind is to include the address of the sender in the message to be signed. That way, even if someone steals your transaction, it will end up being invalid as they will have a different address to yours. Is that the way to avoid this? Would be interested to know other approaches!
I know your comment is 4 months old, but I thought I would answer. Most of these guys are running ganache, which is a program that lets you simulate transactions in a given block. They can then see what the transaction does during the simulation, and then decide if they want to try to front run it. Ganache is not the only such program, there are a few others.
Thank you very much. I got a question: this mainly affects miners right? I would take it that those mining the eth are the ones validating the contract and getting the reward?
Not necessarily. Miners normally aren't in the game of creating these transactions, they usually let bot operators fight for them and, when multiple bot operators compete, the gas prices paid for taking the opportunity approach the value of the transaction over time
There are multiple ways to solve this, but a general solution would be to allow only authorised users to execute the "take" function. You could use this by having a custom modifier that checks if the message sender is in a whitelist stored in the smart contract.
great video mate, why not make a video on how to frontrun, i hate the front run feeling on bsc when ever we make a big buy the bots buy before us and sell after us, now i wonder how they do it.
I agree. I would think that you would be able to set a constant value that represents your address and put a conditional statement in the smart contract to check..
@@flatheadpolitics1895 yes, there are many ways to prevent front running, the problem he pointed out is that there are bots that simulate if they run the transaction, will it be profitable and if so do it. They pickup your message from the tx pool, check if profitable and then send it from their account.
Hello! I've started learning coding to eventually build NFT bots and flashbots. What language do you think I should learn first? Is python any good before I try solidity? Should I change to js? Should I do solidity immediately? Thank you :)
I would learn Python or JavaScript (or TypeScript, a language built on top of JavaScript that makes things friendlier) first. Don't learn solidity first, you need a "local" language to run the bot.
Where they able to front run because the secret you passed when calling the function was visible to everyone? Is there any way of encrypting the message call to make it difficult to frontrun?
Exactly, the pending pool is public (just somewhat difficult to see in time, requiring special tools). Encryption won't work, because the tx needs to work on the miner/validator. It can be privately relayed to that party or you could try some tricks using several transactions that work together, but it would still be possible to front-run, just more difficult for the counter-party
@@epheph33 so flashbots relay can be used to send transactions directly to miners in bundles.but if the block is mined by a validator that does not integrate flashbots, the transactions get failed right?Also flashbots transactions are not visible to anyone?
do front runners try any transaction? what if the transaction does not yield anything in return? it seems like they are taking a lot of risk without knowing they will be rewarded.
They simulate the transactions locally using a program called Ganache, and they get to see what the transaction will do when it is run in the blockchain. They only do this when that test shows that the transaction will result in a profit.
Nice video. Why wen I increase the slippage on the Uniswap the system says "Your transaction may be frontrun", if the the frontrun occurs I could lost the transaction funds? And, the frontrun would be similar to the exemple on this video? Thanks! :)
Not exactly. The front running you are seeing in this video is different than the front running in Uniswap. Your funds couldn't be "lost" per se on a Uniswap transaction. When Uniswap talks about front running, what they mean is that if you allow high slippage, people can insert a transaction in front of yours, that runs up the price up close to your allowed slippage, and then trade those coins back into the pool at a profit (through another separate transaction) after your purchase goes through (because you will have further raised the price when your purchase went through). They should actually tell you that your transaction may be "sandwiched" because this technique is referred to as a "sandwich attack" - one transaction gets inserted just before yours (to buy the coin) and then another right after yours (to sell it back at a profit). It is called a sandwich because you get stuck in the middle.
could you potentially get front runned if you are just transferring coins from one account to another? Or is that not a concern because there is no "reward" for copying the transaction and using higher gas fees?
Bryan Breznau the tokens need to be available to everyone to benefit from copying. Your own tokens are locked to your account, so they can’t be front-run. Here’s another article that discusses this: medium.com/@danrobinson/ethereum-is-a-dark-forest-ecc5f0505dff
Check out my other video about Honeypots: th-cam.com/video/DDn5mksOUCc/w-d-xo.html . Ethereum RPC offers simulation endpoints, and an advanced bot can simulate everything it sees
By storing the "secret" in a private state variable, there is no need in front running it. You can just simply read the states from the raw bytecode of the smart contract xd.
The secret wasn't there, the hash of the secret was. Nobody knew what the value that hashed to that state variable until it appeared in a pending transaction
i deployed a contract which pays its content to the msg.sender. i sent a tx to it and submitted it with very low gas, but now its 10 minutes and nobody copied/frontran my TX yet. but i made my function so it costs 0.01 ether, can it be cause of that?
In addition to Scott's reply, just FYI, very few front runners will run transactions where they have to send ETH to unknown contracts. Also, as he said, there has to be enough value to cover the all transaction costs plus a profit before they'll do it.
Portion of DEXs fees should be use to create a bunch of dummy contracts rekting all those bots.... one wins but all the others losses on transaction fees... rince and repeat
Keep the videos coming. There are literally very few channels that explain such imperative concepts with utmost clarity.
This is channel is one of those. Thank you
Love the video. Please do continue the series on front running!
Very concise and self explanatory. One thing I try to figure out is how to make one's gas fees dynamic in terms of current block, current state of gas prices and current competition on the same block.
Awesome so see the front-runners front-running. Great content, thanks.
thank you for this clear explanation, I also loved the medium article posted in the comments.
Thank you very much Scott for the informative and potentially project saving videos. I am sure I am not the only developer who appreciates being able to see these potential threats and how to handle them. Keep it up!
Its very intreesting video as a newbie web3 developer.
Expecting more videos like this.
Thank you so much 😘😘😘
Thanks for sharing this. Super helpful. It would be nice to see how to prevent the front running. Thanks
this was very informative! thanks for paying for our education :)
This is exceptional content! My only critique would be to speak slower for those of us not at your level. Keep it coming 🙌🏾
Excellent tutorial. No idea how this doesn't have more views
A great video. But I have a little confused about how a front runner can recognize they can get benefit from this contract so quickly since you said they even don't need to understand the contract itself.
Yeah that is not explained at all. They can't front-run billions of tx on good luck. The gas fees would kill them. So how do they know in advance which tx have any kind of value?
they scan all the transactions on the waiting pool, then calculate output - input eth if its greater than some value they copy the transaction and try doing it with higher fees.
@@ichigokurosaki5707 Thats pretty obvious but the question is how can they calculate this potential profit without knowing anything about the contract in advance? Are they somehow simulating how contracts will react to a transaction?
@@cedricdb not sure if you are still looking for an answer , but yes they simulate the contract on a testnet. copy the pending transaction function calls and if their wallet ends up with more ether than they put in, they shoot the transaction to the real network and front run
@@maptuffs Thanks Mike! But the Testnet contract may have different logic and different value... So they are risking money with every such try, correct?
I liked that you call the mempool "pending pool". That makes the concept so much easier to grasp
Oh my! it's really the wild west out there ! Thanks Scott for this video. Liked and subscribed !
Great video thanks for making it!
As others have mentioned, a video on how these bots simulate these transactions (testnet? local node?) would be really interesting.
First of all, thank you very much for the video. It was quite entertaining and eye-opening. Got a couple of questions though,
1. Could you explain a little bit more about the parts where you were calculating the gas price (ie. 15:22 and 16:45)? I'm assuming you were calculating how much you'd have to pay for gas in order to get your transaction included quickly, but what about the locahost tab you opened around 15:22? what was it that you were checking?
2. How would a bot like the one that sniped you know that it'd get payed if they send the same data as your transaction? I'm guessing that they don't know, and they just replicate the transactions and payload with "payable" contract functions as destination, to outbid your gas price and just hope for the best. But if that's the case, how could they know if a function is payable? is that information public for all contracts living on the mainnet?
Thanks,
Hey, Scott. This is indeed a great video man.
So as of now I do have a long list of questions and doubts. And also I am desperately waiting for the next video on How to solve this Front-Running Issue?
We would appreciate you making small solidity project tutorials. It'd be very helpful for the beginners.
Awesome vid, you are a great educator!
great explanation thanks
Awesome video!
Great explanation
In this particular example, can't you just guard by checking that the caller of take is the same as the contract owner? That is, if a front-runner tries to copy the transaction, they'll fail because they're not the contract owner?
In your example, i see how the frontrunners took advantage of the exploit, by i dont understand *how* they knew that calling your contract with those inputs will give them eth. can u explain?
can someone please answer this?
The transactions in the pool are public. Which means the sender address, the contract called, the exact transaction of the contract, the inputs. Everything is in the open. The front running bots can then go through the pending transactions and try to evaluate which one would benefit them if they run it for themselves (using the now public inputs). In order to make sure their transaction comes first they pay more gas because miners prioritize the more expensive transactions.
@@SapiensHomo-k7r thanks but you didn't answer the core question: How can they "evaluate" (in your words) in microseconds, that running this transaction would send them ETH? Even spending a little gas on millions of useless contracts can get expensive for them. So HOW exactly do they "try to evaluate" something that's only known to the contract author, or somebody who reverse-engineers the bytecode in microseconds and opine that executing this probably makes money.
@@magicmedia.channel Anyone can run solidity code anywhere. The blockchain's state is public and free to use (reads are free, writes cost validation fees). They can just have a local blockchain with the same state and run tests there.
The fees are required as a mean to ensure only valid transactions get recorded on the public network. Otherwise just running the code is (often) dirt cheap.
@@magicmedia.channel Also they don't need to read the source code of a contract. They just need to run it with the current state of the main net, which nothing prevents them from by design (Otherwise nobody would be able to validate transactions)
Thank you for showing this!
Very well explained and demonstrated.. Thanks!
Great video, thank you Scott!
man. this is gold.
How do front-runners know which transactions to front run? Do they also know if a transaction results in money being transferred to the caller?
Great vid, explained in a clear manner!
Great video, straight to the point and with a really good example.
Only critique is what sounds like a door closing in the distance or perhaps footsteps above periodically.
oh probably the kids lol, I just noticed the drawing on the wall. Still great video
How is it that hackers/bots knew that this transaction would result them in getting ETH, without the code ever being released or known?
great video very insightful ! question what do you recommend where to learn solidity and how to write smart contracts
this is wild! I cant believe I am only seeing this video until 2022
Great demonstration, thank you!
amazing video thank you for sharing and spending your money to teach us!!!
For these kind of attacks the first thing that comes to mind is to include the address of the sender in the message to be signed. That way, even if someone steals your transaction, it will end up being invalid as they will have a different address to yours. Is that the way to avoid this? Would be interested to know other approaches!
Telos is solving this problem with their EVM which will release before end of summer
Great video! I'd like to be a solidity auditor one day!
Incredible, loved the video
great demonstrations, thank you.
Best video I have seen well done 🙂👍🌱
Great stuff Scott
Could you explain a bit on how they know copying your transaction would pay them the reward?
I know your comment is 4 months old, but I thought I would answer. Most of these guys are running ganache, which is a program that lets you simulate transactions in a given block. They can then see what the transaction does during the simulation, and then decide if they want to try to front run it. Ganache is not the only such program, there are a few others.
@@thefish2010 Hi, could you explain more please? docs, or courses
@@thefish2010 that is plausible. I was under the impression that transactions also report output.
This is very valuable tutorial, thank you so much sir
great video! thaks
Amazing video, i would like to see how we can combat these attacks .
Thank you very much. I got a question: this mainly affects miners right? I would take it that those mining the eth are the ones validating the contract and getting the reward?
Not necessarily. Miners normally aren't in the game of creating these transactions, they usually let bot operators fight for them and, when multiple bot operators compete, the gas prices paid for taking the opportunity approach the value of the transaction over time
great video! how can we combat front running? id love to see that video! also, if one were to front run, what would be the slippage tolerance?
There are multiple ways to solve this, but a general solution would be to allow only authorised users to execute the "take" function. You could use this by having a custom modifier that checks if the message sender is in a whitelist stored in the smart contract.
Do you deliver trainings?
great video mate
$8 spent them are now $80.
Amazing, thank you!
This is gold!
Thanks for sharing this.
Awesome demo
Love the vids! Plz make more!!
Thank you for this information
Great video!!!
How do they know copying your transaction would pay them the reward?
probably its miner who simulate the tx beforehand, try to mangle it and see if it somehow benefits. must be quite sophisticated
if only he knew what gas was going to become
💸
Excellent job!
Are you interested in having an intro or any channel graphics or animations created? I would love to contribute.
scott brother u rule
How are they able to simulate how much there is to me made, what if you had submitted the transaction with an incorrect value?
Great content!
awesome video bro
great video
We need audits
great video mate, why not make a video on how to frontrun, i hate the front run feeling on bsc when ever we make a big buy the bots buy before us and sell after us, now i wonder how they do it.
A stupid question: Why cant I hard code the withdrawer's address(my own address) and require the msg.sender to be equal to it in the take() function?
I agree. I would think that you would be able to set a constant value that represents your address and put a conditional statement in the smart contract to check..
@@flatheadpolitics1895 yes, there are many ways to prevent front running, the problem he pointed out is that there are bots that simulate if they run the transaction, will it be profitable and if so do it. They pickup your message from the tx pool, check if profitable and then send it from their account.
@@robanmodel Thanks for the feedback! I am still learning- lots of nooks and crannies to explore...
It is possible to do front running with flash loan to use as funds ?
How did they know that will be rewarded by 0.035 ETH?
Thank you so much
Ethereum is really a dark forest
How to deploy large smart contracts to main net binance , error timedout or pollingblocktracker. Can you help me, please
Hello! I've started learning coding to eventually build NFT bots and flashbots. What language do you think I should learn first? Is python any good before I try solidity? Should I change to js? Should I do solidity immediately? Thank you :)
I would learn Python or JavaScript (or TypeScript, a language built on top of JavaScript that makes things friendlier) first. Don't learn solidity first, you need a "local" language to run the bot.
@@epheph33 I appreciate your response a lot! I'll pay this back somehow :)
Hello i am very influenced with this video i need your help can you help me with one of my contract?
crazy
good
Where they able to front run because the secret you passed when calling the function was visible to everyone? Is there any way of encrypting the message call to make it difficult to frontrun?
Exactly, the pending pool is public (just somewhat difficult to see in time, requiring special tools). Encryption won't work, because the tx needs to work on the miner/validator. It can be privately relayed to that party or you could try some tricks using several transactions that work together, but it would still be possible to front-run, just more difficult for the counter-party
@@epheph33 do we have to privately relay to every miner on the blockchain?
@@jessojohn9226 Check out my most recent video
@@epheph33 so flashbots relay can be used to send transactions directly to miners in bundles.but if the block is mined by a validator that does not integrate flashbots, the transactions get failed right?Also flashbots transactions are not visible to anyone?
do front runners try any transaction? what if the transaction does not yield anything in return? it seems like they are taking a lot of risk without knowing they will be rewarded.
They simulate the transactions locally using a program called Ganache, and they get to see what the transaction will do when it is run in the blockchain. They only do this when that test shows that the transaction will result in a profit.
Nice video. Why wen I increase the slippage on the Uniswap the system says "Your transaction may be frontrun", if the the frontrun occurs I could lost the transaction funds? And, the frontrun would be similar to the exemple on this video? Thanks! :)
Not exactly. The front running you are seeing in this video is different than the front running in Uniswap. Your funds couldn't be "lost" per se on a Uniswap transaction. When Uniswap talks about front running, what they mean is that if you allow high slippage, people can insert a transaction in front of yours, that runs up the price up close to your allowed slippage, and then trade those coins back into the pool at a profit (through another separate transaction) after your purchase goes through (because you will have further raised the price when your purchase went through).
They should actually tell you that your transaction may be "sandwiched" because this technique is referred to as a "sandwich attack" - one transaction gets inserted just before yours (to buy the coin) and then another right after yours (to sell it back at a profit). It is called a sandwich because you get stuck in the middle.
@@thefish2010 ^ Exactly
could you potentially get front runned if you are just transferring coins from one account to another? Or is that not a concern because there is no "reward" for copying the transaction and using higher gas fees?
Bryan Breznau the tokens need to be available to everyone to benefit from copying. Your own tokens are locked to your account, so they can’t be front-run. Here’s another article that discusses this: medium.com/@danrobinson/ethereum-is-a-dark-forest-ecc5f0505dff
@@epheph33 could a require statement stop this frontruning?
@@animator7584 require msg.sender == Animatorsaddress
how front-runners know how much they would get from running a transaction?
Check out my other video about Honeypots: th-cam.com/video/DDn5mksOUCc/w-d-xo.html . Ethereum RPC offers simulation endpoints, and an advanced bot can simulate everything it sees
By storing the "secret" in a private state variable, there is no need in front running it. You can just simply read the states from the raw bytecode of the smart contract xd.
The secret wasn't there, the hash of the secret was. Nobody knew what the value that hashed to that state variable until it appeared in a pending transaction
i deployed a contract which pays its content to the msg.sender. i sent a tx to it and submitted it with very low gas, but now its 10 minutes and nobody copied/frontran my TX yet. but i made my function so it costs 0.01 ether, can it be cause of that?
It has to be enticing enough compared to the gas fee required to run the transaction
In addition to Scott's reply, just FYI, very few front runners will run transactions where they have to send ETH to unknown contracts. Also, as he said, there has to be enough value to cover the all transaction costs plus a profit before they'll do it.
Most of front runner not on TH-cam are scams! I
LMAO wild wild west
+++
Portion of DEXs fees should be use to create a bunch of dummy contracts rekting all those bots.... one wins but all the others losses on transaction fees... rince and repeat