PIP-15: In-Memory Cache for Stored Items
Authors | B00f (@b00f) |
---|---|
Discussion | View Discussion PIP-15 |
Category | Core |
Created | 2023-12-03 |
Table of Contents
Abstract #
This proposal suggests using in-memory caching systems within the store module to enhance performance and reduce unnecessary decoding of data that is frequently accessed.
Specification #
This proposal suggests implementing different caching mechanisms for the following items within the store module:
Account Cache #
Accounts can be cached by their address using an LRU (Least Recently Used)1 cache.
Validator Cache #
All validators can be stored in a hash table2 (map). Since the number of validators won’t be too large, we can keep them all in memory. We need to create two hash tables: one to find validators by their number and another by their address. It’s important to retain all validators once the store is initialized.
Public Key Cache #
Public keys can be cached by their address using an LRU (Least Recently Used) cache.
Recent Transaction IDs #
The most recent transaction IDs can be stored using the LinkedMap 3. It’s important to retain all transaction IDs up to the Time-to-Live (TTL) interval4 once the store is initialized. Once a new block is committed, the expired transactions can be removed from the LinkedMap.
Recent Sortition Seed #
The most recent sortition seeds can be stored using the PairSlice
5.
A PairSlice
is a slice where each item is a pair of a key and a value.
The first item in the PairSlice
represents the block height, and the second item represents the sortition seed.
It is important to retain all sortition seeds up to the Sortition Interval4 once the store is initialized.
If the slice reaches its maximum size, upon committing a new block,
the oldest item in the slice can be removed to maintain the slice’s fixed size.
References #
Copyright
Copyright and related rights waived via CC0.