Ethereum Security – Best Practices to Prevent Smart Contract Code Reuse

dapp-developmentSecuritysoliditytruffle

I'm new to smart contract development. I have built a couple of sample projects and deployed those to my private network. So now I am doing some research on best practices in regards to smart contract security and protecting my intellectual property from those that would like to steal it and use it for their own purposes.

From what I have read, smart contract bytecodes are visible in the blockchain, but supposedly it is impossible to turn those bytecodes back into solidity code. Even still, is there anyway to take the bytecodes from the block chain, copy them and use them for your own purposes?

Please give me some best practices to follow when dealing with smart contracts in regards to security and protecting my intellectual property.

Best Answer

Sorry to be a downer...

You can't recover the original code from byte code because information is lost during the compilation. However, disassembly is always possible if the byte code is retrievable. Since the code for the contract must be executed by all full nodes and by miners, the byte code must be readily available to those parties. In practice, since anyone can be a node, that means everyone can get the byte code. As a former assembly programmer, I will assert that it is impossible to protect your IP completely in this case. If it's economically beneficial or just plain interesting, it will probably get reverse engineered.

Unfortunately, I can't offer best practices; legal avenues may be your best bet (but not patenting or copyright; not particularly useful here). At best, I think you can use some anti-disassembler techniques, but those will increase the cost of executing your contracts. As a person who has personally stripped out anti-piracy code from software I own in order to speed it up, I would ask that you try some other method of making your business (I assume) more resilient to reverse engineering.

Given that even with protections like clock-skew detection, instruction timing checks, hardware-based protection, encrypted instructions, and checks that test physical hardware only slow down the best crackers, it's almost certainly a better use of your time/efforts to build a better product/business than it is to try to defend against this scenario on the EVM (which is a much simpler system than a real computer and therefore easier to defeat due to a reduction in things that can be worked into the byte code). If you have to ask this question about best practices, it's almost certain that there are people, individually (let alone as a group) who can break your obfuscation efforts more easily than you can implement obfuscation.

Related Topic