Source Print Discuss
🔰 Final Standard

PIP-15: In-Memory Cache for Stored Items


Authors B00f (@b00f)
Discussion View Discussion PIP-15
Created 2023-12-03

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.