You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As the size of the Skepticoin blockchain has grown, the scalability bottlenecks have moved around to different parts of the code.
unspent_transaction_outs_by_hash (UTObH) is currently one of the largest contributors to slow start-up times.
Throughout the codebase, unspent_transaction_outs (UTO) is the set of Outputs minus the Inputs that used up those Outputs, aggregated at a given block in the chain, and indexed by Output key. UTObH is the collection of all such UTO maps at every block, indexed by block (i.e. UTO is virtually a Block attribute). Currently the UTObH is pre-computed at every height of every fork of the chain during add_block_no_validation, resulting in a slowdown of both the disk read and the initial block download.
An optimization opportunity exists because once the application is running, it actually doesn't care about all the UTOs that were pre-computed, or even all the O's in a given block's UTO. Only the Outputs that are currently being used as an Input in the next Transaction are important (or Outputs matching a Public Key, if computing balances). Some kind of Linked List might be a better solution.
I started thinking about the code for this but then my head wanted to explode, so I decided to write this ticket instead.
The text was updated successfully, but these errors were encountered:
As the size of the Skepticoin blockchain has grown, the scalability bottlenecks have moved around to different parts of the code.
unspent_transaction_outs_by_hash
(UTObH) is currently one of the largest contributors to slow start-up times.Throughout the codebase,
unspent_transaction_outs
(UTO) is the set of Outputs minus the Inputs that used up those Outputs, aggregated at a given block in the chain, and indexed by Output key. UTObH is the collection of all such UTO maps at every block, indexed by block (i.e. UTO is virtually a Block attribute). Currently the UTObH is pre-computed at every height of every fork of the chain duringadd_block_no_validation
, resulting in a slowdown of both the disk read and the initial block download.An optimization opportunity exists because once the application is running, it actually doesn't care about all the UTOs that were pre-computed, or even all the O's in a given block's UTO. Only the Outputs that are currently being used as an Input in the next Transaction are important (or Outputs matching a Public Key, if computing balances). Some kind of Linked List might be a better solution.
I started thinking about the code for this but then my head wanted to explode, so I decided to write this ticket instead.
The text was updated successfully, but these errors were encountered: