We hacked Etherscan, but why?
What is Etherscan?
Etherscan is the leading Block Explorer for the Ethereum Blockchain. The platform is most commonly used for looking up, confirming and validating transactions that have taken place on the Ethereum Blockchain.
The main use of Etherscan for developers, however, is to verify their contract by verifying the bytecode of the smart contract (which is stored in the Ethereum network) corresponds to the Solidity code initially available only to the smart contract developer. This means that getting verified on Etherscan is a quality check on your smart contract, and the code is executed accordingly when the smart contract is executed.
The FST Network team believes that it is a good practice to publish your Ethereum Smart Contract code on Etherscan.io under your contract’s address in a main net environment as it represents transparency and signifies readiness of your product. Once deployed, the smart contract will be published on the main net and its code cannot be changed. Because it is no longer a moving target, it becomes easier to audit. However, during our deployment to the main net, we noticed that there are flaws within the etherscan verification framework.
So why did we hack Etherscan?
FST Network provides modularised functions. What exactly does that mean? In layman’s terms, we use smart contracts to generate smart contracts, and this allows our clients to manage and configure their crypto-assets with smart contracts. Because our modules are built upon “Smart Contracts” rather than a “Smart Contract,” we have a powerful objective-orientation structure to support modularization. On top of that, as a rare benefit of modularization, the relationship of each objective of the code is complex such as “call” or “include.” This makes our modules robust for business applications since the core smart contract is lean. This also makes our end-users free from the bug of adopting features from Ethereum.
At FST Network, we take Smart contract security very seriously and formal verification allows us to prove conclusively that certain error states can never occur and our product can deliver what it promised to deliver.
How does Etherscan verify smart contracts and what does it check?
When verifying the contract, there are two factors that are inspected: 1) compiling time should not exceed 30 seconds and 2) the complexity of the contract.
Etherescan will compile the Solidity code and ensure the resulting bytecode exactly matches the bytecode stored in the Ethereum network. With that verification in place, clients who are reading the smart contract will know that the code is being executed accordingly when they execute the smart contract.
Our modules involve multiple contracts, and therefore we cannot get verified when Etherscan reads our modules because the compiling time exceeds 30 seconds. Our contracts take approximately 2 minutes to compile.
In addition, in order to get verified, Etherscan compiler will generate a meta-hash in compile result (bytecode) according to modern solidity’s nature. This is their method to prove the contract promise meets the Blockchain result. The bytecode generated by Etherscan’s compiler is different in the official compiler “solc” if the contract is complex. Our objective-orientation is larger than usual scale (2500–4000 lines with 5–10 contracts compared with the normal single contract at 200–500 lines), therefore our meta hash result is different with Etherscan.
So how we hacked Etherscan?
1. We calculated and replaced the meta hash in the compiled result before deploying to the ethereum chain to make the binary consistent with the compiled version in Etherscan.
2. We rewrote the entire contract to non-inheritance format and simplified the logic of our contract. The more abstract the code, the more stability and robustness are sacrificed. We simplified it because, the less effort that is needed to understand and conduct maintenance, the better the ability to extend and elaborate the business logic. In order to verify our smart contract on the Etherscan, we made changed our contract to compile only in low-quality format.
3. The max optimization runs is limited to 200 (which is not the optimal number for most of the contract). So, we “adjusted” the limit.
What does it mean for Etherscan?
From this whole experience, we noticed that the entire framework of Etherscan is designed to verify simple contracts with simple functionalities and is not compliant with the updated version of solidity. This will only bring harm to big projects, as they need to sacrifice features and quality of their code just to get verified on Etherscan. This cannot remain true if we desire that blockchain technology achieve what it needs to achieve — the revolutionary tech that will redefine the economic and digital structure. Smart contracts will only get more robust, not less. If this problem remains as it is, how can a developer convince others of the execution of the smart contract? We already have too many scams in the market. While open sourcing the code on GitHub is a great idea, it gives no guarantees that the code in the repository is even remotely similar to the one running on-chain.
Formal verification allows programmers greater assurances in developing smart contracts. Naturally, any type of security comes at a cost, and we do not need Etherscan to make it any more difficult for the developers.
Originally published at www.fstk.io on May 12, 2018.
