The threadpool used to replay multiple transactions in parallel is
currently global state via a lazy_static definition. Making this pool
owned by ReplayStage will enable subsequent work to make the pool
size configurable on the CLI.
This makes `ReplayStage` create and hold the threadpool which is passed
down to blockstore_processor::confirm_slot().
blockstore_processor::process_blockstore_from_root() now creates its'
own threadpool as well; however, this pool is only alive while for
the scope of that function and does not persist the lifetime of the
process.
In cluster restart scenarios, an important step is scanning the
Blockstore for blocks that occur after the chosen restart slot with an
incorrect shred version. This check ensures that any blocks that
occurred pre-cluster restart and after the chosen restart slot get
deleted. If a node skips this step, the node can encounter problems when
that block is created again, after the cluster has restarted.
This check only occurs if --wait-for-supermajority AND
--expected-shred-version are set; however, --expected-... is currently
optional when using --wait-...
Our restart instructions typically mention that one should specify
--expected-... as well, but we should just enforce it at the CLI level
to prevent mistakes / wasted time debuggging.
* Support min_context_slot field in getBlocksWithLimit input
* Use min_context_slot in get_blocks_with_limit
* Support min_context_slot field in getBlocks input
* Use min_context_slot in get_blocks
ReplayStage owning the pool allows for subsequent work to configure
the size of the pool; configuring the size of the pool inside of the
lazy_static would have been a little messy
In a previous change, we removed the threadpool used to fetch entries
in parallel in favor of combining all fetches into a single rocksdb
multi_get() call.
This change does the same thing, except for a threadpool that was used
to fetch entries when we needed them to purge the transaction status
and address signatures columns.
This reduces the maximum penalty for voting after the grace period by
roughly 50%. This new value was derived from looking at the effects
that TVC at max credits 8 would have for recent epochs (500+) and
noting that the effect was a bit extreme, up to and exceeding 10%
"bonus" for faster voters. This change reduces that maximum bonus by
roughly half.
In addition, the TVC feature key has been changed.
RuntimeConfig doesn't use anything SVM specific and logically belongs
in program runtime rather than SVM. This change moves the definition
of RuntimeConfig struct from the SVM crate to program-runtime and
adjusts `use` statements accordingly.
* Combine builtin and BPF execution cost into programs_execution_cost since VM has started to consume CUs uniformly
* update tests
* apply suggestions from code review
#### Problem
TieredStorage stores account hash as an optional field inside its HotStorage.
However, the field isn't used and we have already decided to deprecate
the account hash.
#### Summary of Changes
Remove account-hash from the tiered-storage.
#### Test Plan
Existing tiered-storage tests.
Running validators w/ tiered-storage in mainnet-beta w/o storing account-hash.
* Add new script to patch spl in anchor downstream
* Only specify major version for token-2022
* Add update for ahash
* Patch spl in anchor
* Remove dex and metadata features for now
Greg Cusack
Brooks
steviez
Yihau Chen
Andrew Fitzgerald
dependabot[bot]
Tyera
Lucas Steuernagel
behzad nouri
Jeff Washington (jwash)
Dmitri Makarov
HaoranYi
Justin Starry
Jon C
Tao Zhu
kirill lykov
bji
Yueh-Hsuan Chiang
Brennan