TodayThe network experienced a transaction spam attack, which employed the EXTCODESIZE method. (see the example trace). HereThis created blocks that took between 20-60 seconds to validate because of the 50,000 disk fetches needed to process the transaction. The The result was a decrease of 2-3x in the block production rate during the attack; There There was no consensus breakdown (ie network Fork), and the network and clients did not stop at any point. As of today’s writing, the attack has mostly been stopped and the network has recovered.

Users, including miners and corporate users (including exchanges), can use the short-term solution to get around the flags.

–cache 1024 –targetgaslimit 1500000 –gasprice 20000000000

For Parity With the flags

–cache-size-db 1024 –gas-floor-target 1500000 –gasprice 20000000000 –gas-cap 1500000

This (i) Increases the cache size which reduces disk reads nodes have to perform and (ii). Reduces gas limit by 3x which reduces maximum processing time for a block by a similar factor.

In Medium term (i.e. We are currently working on several fixes that will improve the performance of the platform. This client should offer a more secure solution to the issue and minimize the risk of similar attacks.

• An adjustment to the miner’s software that temporarily halves the gas cap target automatically when the miner detects a block that takes more than 5 seconds to be processed. Comparable adjustments can be made today as well (see Here For a pull request, note that this is a change in mining strategy and not a soft fork or hard fork.
• Numerical Changes to cache configuration
• Add Additional caches
• Adding Extra cache for EXTCODESIZE, specifically. EXTCODESIZE is likely to be slower than other IO-heavy operations because the contracts being read are 18KB in length.
• An on-disk cache of state values ​​that allows them to be faster (i.e., OR(record(n)) Acceleration) accessed

We We are exploring the possibility of replacing leveldb with something more efficient for our use, but such a change will not be happening soon. Parity Each member of the team is working towards their own performance improvement.

In In the long-term, it is possible to explore low-level protocol modifications. For For example, you might consider adding a function. Metropolis Increase fuel costs for operations that require account status readings (SLOAD/EXTCODESIZE/CALL, etc.)), and especially read operations that read external accounts. While increasing the gas costs for all of these operations to at most 500 would be sufficient, care must be taken not to break existing contracts (for example, by simultaneously deployment). FOOT 90 It would be sufficient.

This The upper limit for the maximum number of bytes that a transaction may read would be lower, increasing security and decreasing the size of the transaction. Merkle testing and improving security for both thin clients and fragmentation. effect. CurrentlyWhile we are focusing on immediate changes at the software-level, contract developers and contract writers should be aware that these changes could happen in the future.