Does getting a third party audit completely secure the smart contract:
Blockchain and Smart contracts are relatively nascent technologies that are still highly experimental. They are as robust as they are vulnerable to unexplored loopholes. As new bugs and vulnerabilities are discovered almost regularly, one should expect constant changes in the security landscape. It should be noted that developing smart contracts is not similar to developing software applications, as the word ‘contract’ involves legal and financial aspects that cannot be taken for granted. So it requires the programmers to work in tandem with professionals in those areas or so as to achieve a symbiosis.
With that said, smart contract programming requires a different perspective altogether. The cost of failure can be high and might even drag prosecution into picture; the security is given the highest priority. So, it is just not enough to defend against known vulnerabilities.
It is thus recommended to:
· Be prepared for failure: A smart contract code is bound to have errors or loopholes, thus it is important for it to be able to respond to bugs and vulnerabilities in a positive way. To ensure that even in the case of a failure, the smart contract fails gracefully, the developer should be able to:
1. Pause the contract when there is any unusual activity suspected.
2. Manage the finances at risk.
3. Have an effective upgrade-path for bug fixes and improvements. For a more technical insight into upgrade-ability, read
· Keep contracts simple: Complexity increases likelihood of errors. Ensure that the logic followed is simple and not too circuitous.
1) Prefer clarity over performance wherever possible.
2) Optimize code structure to keep functions small.
3) Wherever possible, use already written code that is well audited.
4) Limit the usage of blockchain only for the fragments that require decentralization.
· Rollout carefully in phases: There is more chance of surviving a plane crash than writing a completely bug free code. It is recommended to catch as many bugs as possible before a full- fledged release.
1) Test the contracts rigorously and add more tests whenever new attack vectors are discovered in the space.
2) Encourage bug bounties right from the test-net itself.
3) Rollout in phases, with increased usage along with testing in each phase.
· Have the smart contracts audited from time to time: A security audit is more than securing a code. The real weaknesses run deeper than the surface cracks. Simple syntax errors does not mean the code is flawed, at the same time, a perfectly documented code does not mean the logic holds up. Anything can happen, and without a thorough audit, it often does.
1) It’s okay to get the smart contract audited by more than one auditor. Better safe than sorry!
2) Apart from auditing, a constant surveillance on the activities on the smart contracts is recommended. It ensures the unusual activity is caught as soon as possible, giving an edge to mitigate the damage.
3) Bug bounties are deemed mandatory. It encourages the players to report the bug for a reward, instead of taking advantage of it.
4) Also getting the smart contracts audited every now and then will keep them safe and integrated with the updated security measures.
· Stay up to date:
1) New security developments keep coming every now and then, get updated on new measures from time to time.
2) As soon as any new bug or vulnerability is discovered in the space, test your contracts for the same.
3) Adopt newer techniques pertaining to security that appeal to you.
· Be cautious of blockchain characteristics: While blockchain technology sounds intriguing, we still are not aware of its full potential. Its better to limit its usage to certain aspects which really need decentralization, rather than abusing it.
1) Data on blockchain is accessible to the involved nodes. It could turn out to be risky to leak certain sensitive information which can be taken advantage of. This goes with user data as well.
2) Public functions are truly public, and may be maliciously called. This may lead to user privacy related issues.
3) Usage of blockchain calls for gas costs. Unnecessary usage of blockchain means adding extra cost to the user.
It clearly highlights that transaction cost is higher than the actual transaction value. This is one good way to lose trusted users! Therefore it is suggested to check for gas optimizations from time to time, that is, whenever a new function is added.
These are a few recommendations that try to be as not technical as possible. I really hope this discussion moves forward in the comment section. Alrighty then!
