Dave Collins 84f6089bc9 Rework and improve async script validation logic. ...

The previous script validation logic entailed starting up a hard-coded
number of goroutines to process the transaction scripts in parallel.  In
particular, one goroutine (up to 8 max) was started per transaction in a
block and another one was started for each input script pair in the
each transaction.  This resulted in 64 goroutines simultaneously running
scripts and verifying cryptographic signatures.  This could easily lead to
the overall system feeling sluggish.

Further the previous design could also result in bursty behavior since the
number of inputs to a transaction as well as its complexity can vary
widely between transactions.  For example, starting 2 goroutines (one to
process the transaction and one for actual script pair validation) to
verify a transaction with a single input was not desirable.

Finally, the previous design validated all transactions and inputs
regardless of a failure in one of the other scripts.  This really didn't
have a big impact since it's quite rare that blocks with invalid
verifications are being processed, but it was a potential way DoS vector.

This commit changes the logic in a few ways to improve things:

- The max number of validation goroutines is now based on the number of
  cores in the system
- All transaction inputs from all transactions in the block are collated
  into a single list which is fed through the aforementioned validation
  goroutines
- The validation CPU usage is much more consistent due to the collation of
  inputs
- A validation error in any goroutine immediately stops validation of all
  remaining inputs
- The errors have been improved to include context about what tx script
  pair failed as opposed to showing the information as a warning

This closes conformal/btcd#59.

2014-01-16 20:02:30 -06:00

6.8 KiB

Raw Blame History

View Raw