Page 48 - FIGI: Security Aspects of Distributed Ledger Technologies

EVM has been criticized as being non-Turing Com- tract invocation and execution of directives. Ineffi-
plete as a result of not having a predictable out- cient programming which can call for unnecessary
put. operations and can result in a substantial amount
352
• Immutable Bugs/Mistakes: If a contract contains of needlessly wasted Gas. Existing tools have been
a bug, there is no way to patch it. As a result, smart criticized for being inadequate at spotting and
contracts must be programmed with an ability suggesting remedies for underoptimized code. 357
to terminate. An attacker using this functionality • Reentrancy: Perhaps the most notorious of all
358
can make Ether stranded or unusable or even sto- Ethereum vulnerabilities, reentrancy is an error
len. And once this happens, there is no recourse in recursive functions (looping activity.) It occurs
except for the rare possibility of a hard fork of when a first smart contract interacts with second
the blockchain to reverse the results of a serious contract and (i) calls for a transfer of Ether to sec-
error. Hard forks are generally shunned (such as ond; and (ii) also transfers control from the first
occurred to correct The DAO bug, which result- contract to the second contract before the con-
ed in miners refusing to do so and which resulted tract is fully executed in its entirety. In essence,
in the creation of Ethereum Classic, an alternate recursive activity can occur without reaching a
blockchain. ) critically important instruction which would end
353
• Ether lost in transfer: Ether which is sent to an the process. The second contract can perform
‘orphan’ address is lost forever, such as to an undesirable activities such as emptying the funds
address that is unable to be used or accessed such held by the first contract prior to its full execution.
as one that doesn’t belong to an existing user or This is the error which was responsible for the
contract. At present, such a condition is unable to DAO exploit which resulted in a loss of over USD
be prior detected. 150 million and resulted in a fork of the Ethereum
• Difficulty of writing correct smart contracts: network.
Development environments should provide pro- • Out-of-gas send: The Ethereum smart contracts
grammers with reasonably good expectations as environment incentivizes miners/validators by
to the outcomes of the code they craft. The sig- compensating them in proportion to the compu-
nificant number of contracts with vulnerabilities tational effort required to execute the instructions
(such as is reflected above in Section 8.1) com- in the smart contract. Ethereum uses a unit of
bined with staggering losses without recourse measure called ‘Gas’ which operates in a similar
suggests to some observers that there is an inher- manner as in the physical world. The amount of
ent difficulty in writing safe, secure smart con- Gas needed to execute tasks such sending a pay-
tracts with a high degree of confidence that they ment of ETH or storing a value on the blockchain,
will act as examples include the DAO attack which etc. can be estimated using the Ethereum Yellow
led to an unauthorized transfer of over USD 60 Paper as well as online tools. Metering’ the prop-
359
million of Ether to an account of a bad actor. The er amount of Gas needed for a contract is a com-
Parity Wallet ‘newbie error’ led to over USD 200 plex, complicated process. A contract must also
360
million of stranded Ether and a vote that almost be initially funded with sufficient Ether (deposit-
had a consensus in favor of justifying a hard fork ed into the contract address) in order to execute,
to right a security oversight. which must be sufficient to ‘purchase’ Gas at the
354
• Inability to modify smart contracts: As stat- current Gas price, which is dynamically generat-
ed above, the aspiration for immutability of the ed. The contract must allow for an appropriate
361
blockchain results in contracts which have easi- deposit of Gas or the contract may not execute as
ly correctible bugs needing to be killed and rec- anticipated or at all. Failure to program correctly
reated with a new address. Modification of the can result in substantial failures, as described in
existing contract is not possible. As there was no greater detail below.
ability to revive killed contracts or modify exist-
ing bugs (and avoid self-destruction), substantial Risks: Potential risks to smart contract
errors cannot be easily remedied such as the Par- technology include:
ity multi-sig wallet where user error (or mischief)
stranded 513,736 ETH worth nearly USD 330 • Flaws in the smart contract code; or the
355
million at the then-current exchange rate. • Reliance on an external ‘off chain’ event or person
356
• Lack of support to identify under-optimised - to integrate with and execute - the embedded
smart contracts: Gas is required for smart con- terms of the smart contract.
362

46 Security Aspects of Distributed Ledger Technologies