Part 4 — Web3 Security 🔒 (Prevention 🛑 Common Post-Smart contract Deployment Attacks)
To view this post in Notion, use this link.
2 ways to do this:
1) MEV / front running related.
- Transactions in the mempool are supposed to be organized by transaction fee, such that the highest fee/byte transactions are executed first. MEV is the problem where miners reorder transactions to extract additional value and profits for themselves. Basically, they can see a profitable transaction in the queue, quickly copy the transaction, and submit their transaction ahead of the original one, stealing all the alpha.
- The Salmonella Contract - baiting front runners with decoy contracts.
- Liquidity Sniper Trap - code that detects malicious back runner activity, then automatically makes them unable to sell their tokens.
- Fair Sequencing - A number of platforms have proposed ways to improve order fairness, including Chainlink’s Fair Sequencing Service, Arbitrum's distributed sequencer plan, and Automata's Conveyor service.
- If you see suspicious activity, you need to get in front of it. And you need to make sure no one else is front running you too.
2) Proxy contract
- It is not possible to upgrade the code of your already deployed smart contract. In web2, engineers are used to deploying code, then updating the code to fix bugs. This is not possible in web3 as you cannot change the source code of your smart contract after it’s been deployed.
- Introduced by proxy contracts: It is possible to set up a proxy contract architecture that will allow you to use new deployed contracts as if your main logic had been upgraded.
- If a user wants to interact with an underlying contract, they have to interact with the proxy contract first. This proxy contract redirects them to the latest deployed contract logic. So if you need to make updates to fix a bug, you can redirect to the new version of your contract by updating the Proxy to reference the new contract address.