Today the network experienced an assault through a transaction spam attack that persistently invoked the EXTCODESIZE opcode (refer to trace sample here), thus generating blocks that require approximately ~20-60 seconds to validate owing to the ~50,000 disk fetches necessary to process the transaction. The consequence of this was an approximate ~2-3x decline in the block creation rate while the attack was underway; there was NO consensus disruption (i.e., network fork) and at no time did the network or any client come to a complete stop. As of the time of this writing, the attack has largely ceased, and the network has temporarily recuperated.
The immediate solution is for users, including miners, enterprise users (such as exchanges), and individuals to operate geth with the flags:
–cache 1024 –targetgaslimit 1500000 –gasprice 20000000000
Or utilize Parity with the flags:
–cache-size-db 1024 –gas-floor-target 1500000 –gasprice 20000000000 –gas-cap 1500000
This (i) enlarges the cache size, minimizing the number of disk reads that nodes must perform, and (ii) reduces the gas limit by roughly 3x, thereby lessening the maximum processing duration of a block by a similar margin.
In the medium term (i.e., several days to a week), we are actively addressing multiple fixes for the Go client that should both supply a more consistent resolution for the current issue and lessen the risk of similar attacks, including:
- An update to miner software that automatically temporarily halves the gas limit target whenever the miner detects a block that requires more than 5 seconds to process, facilitating adjustments akin to what was coordinated today to occur automatically (refer to here for a pull request; please note this is a miner strategy alteration and NOT a soft fork or hard fork)
- Numerical adjustments to cache configurations
- Incorporating additional caches
- Implementing an extra cache specifically for EXTCODESIZE (since it is probable that EXTCODESIZE reads operate at several times slower than other IO-intensive tasks given the contracts being read are approximately ~18 KB long)
- A disk-based cache of state values which enables quicker (i.e., O(log(n)) speedup) access
We are also examining the possibility of substituting the leveldb database with a more efficient and optimized alternative for our use case, though such a modification would not be immediate. The Parity team is pursuing their own enhancements in performance.
In the longer term, there are fundamental protocol modifications that can also be investigated. For instance, it may be prudent to incorporate a feature into Metropolis to raise the gas costs of opcodes that necessitate reading of account state (SLOAD, EXTCODESIZE, CALL, etc.), particularly for read operations involving external accounts; elevating the gas cost of all these functions to at least 500 would likely suffice, though caution should be exercised to prevent disrupting existing contracts (e.g., concurrently implementing EIP 90 would be adequate).
This would impose a significantly lower upper limit on the maximum number of bytes a transaction may read, enhancing safety against all potential attacks of this nature, and diminishing the size of Merkle proofs, thus fortifying security for both light clients and sharding as an ancillary benefit. Currently, our focus is on the more urgent software-level modifications; however, in the long run, such proposals should be deliberated and contract developers need to be informed that alterations of this nature may occur.