Specification is Law: Safe Deployment of Ethereum Smart Contracts Fig. 3: Trusted deployer architecture. Specification is Law: Safe Deployment of Ethereum Smart Contracts out by the contract. The function allowance does not change the state of the smart contract so it has only one postcondition (line 9) to ensure that it will re- turn the correct amount of tokens available for withdrawals. The transferFrom function has 4 postconditions; the operation is successful only when the tokens are debited from the source account and credited in the destination account, according to the specifications provided in the ERC20 standard. The first two postconditions (lines 13 to 14) require that the balances are updated as expected, whereas the purpose of the last two (lines 15 to 16) is to ensure that the tokens available for withdrawal have been properly updated. tion. The code of this contract has undergone significant changes. The refac- toring in question is one of the most common and is known as extract method (function, in Solidity). From commit 319740 to 99012f, the new internal func- tion _callonERC1155Received was created, and the extracted code from the _safeTransferFrom was moved into it. Fig. 10: Successful refactoring of the safeTransferFrom function Fig. 11: Buggy ERC1155 safeBatchTransferFrom function The trusted registry (see Figure 13) check whether that a given instance was created by the trusted deployer by calling its get-spec function. Since smart contracts in a blockchain platform cannot rely on external services, such as the trusted deployer, that is, they would have no means to check whether an instance that they want to interact with is safe or not. We create a trusted registry as part of the trusted deployer infrastructure which is essentially a mirror of the trusted deployer’s internal registry implemented as a smart contract. It has a maintainer and mapping verified_addr that associates the proxy instances that have been created by the trusted deployer with the specification they comply to. As an implementation detail, we do not store the specification themselves but rather a small representative as a 32-byte array - it could be, for instance, a cryptographic hash of the specification. We do not allow this representative to be the zeroed array, bytes32(0) in Solidity syntax, as we use this value to represent absence of an association. That is, if the result of a call get_spec(addr) is the value bytes32(0), it means the address addr has not been deployed by the trusted deployed, and hence has no specification associated with it. The proxy pattern as discussed in Section 3.2 separates the logic and the data of a contract. The key concept to understand is that the implementatior contract can be replaced while the trusted proxy (see Figure 14), or the access point is never changed. Both contracts are still immutable in the sense that their code cannot be changed, but the logic contract can simply be swapped by another contract. Every proxy must contain all variables (lines 3 to 5) defined in the implementation contract which will store the state as well as the signatures of all its public functions (lines 7 to 10). If there is any constructor in the implementation contract it will be merged with the default constructor of the proxy (lines 17 to 23). Specification is Law: Safe Deployment of Ethereum Smart Contracts the developer had used our tool the error would have been discovered in the first analysis, these deployments would have been prevented, and an error message containing the specific reason would be returned to the developer forcing him to fix the bug. The results collected from our evolution scenario, one can see that our strategy is effective in identifying error in the early stage of the process. Our tool abstracts many details of the deployment and upgrade process making it simpler for platform users when compared to the manual process.
