EOS Smart Contract Development Security

According to EOS Smart contract Security guide, today I will share with you some good points that can help you write a security smart contract to avoid attacks from hackers.

• Be prepared for possible mistakes. Any meaningful smart contract is more or less wrong, so your code must be able to properly handle the bugs and vulnerabilities that arise. Always follow these rules:
• stop the smart contract when an error occurs
• manage the risk of the account, such as limit (transfer) rate and set maximum (transfer) limit
• figure out effective ways to fix bugs and improve functionality
• Be prudent of releasing smart contracts.Try your best to find out and fix the potential bugs before the smart contract is officially released.
  • Test smart contracts thoroughly and retest them in time after any new attacks are discovered (testing those contracts that have been issued as well)
  • Invite professional security audit firms for audition and provide Bug Bounty Program from the start of the alpha release on the cryptokylin-testnet, Jungle-testnet, or other public test nets.
  • Release in several phases, at each phrase, ensure adequate testings are provided.
• Keep the smart contracts simply。Increased complexity will increase the risk of error.
  • Ensure the logic of the smart contracts are concise
  • Ensure that contracts and functions are modular
  • Use contracts or tools that are already widely adapted(For example, don’t write a random number generator yourself)
  • Clarity is more important than performance when allows
  • Use blockchain tech only for the decentralized part of your system
• Keep updated. Ensure access to the latest security developments by disclosing resources.
  • Check your smart contract when any new vulnerabilities are discovered
  • Update the library or tool as quickly as possible when possible
  • Use the latest security technologies
• Get clear understanding of blockchain features。Although your previous programming experience is also applicable to smart contract development, there are still pitfalls to keep an eye out for：
  • require_recipient(account_name name) will trigger notification，and call the function with the same name within name contract(if account name already deployed contract)，see official doc here

A check list for known vulnerabilities we need to take care of them

• Numerical overflow by checking the boundaries when doing arithmetic operations.
• Authorization check by use require_auth for authorization check.
• We should to avoid a random number algorithm is written on the EOS smart contract.

Happy coding!