diff --git a/proposals/0197-chilli-peppers.md b/proposals/0197-chilli-peppers.md new file mode 100644 index 00000000..dad2f6f8 --- /dev/null +++ b/proposals/0197-chilli-peppers.md @@ -0,0 +1,229 @@ +--- +simd: '0197' +title: Chili Peppers +authors: + - Firedancer Team +category: Standard +type: Core +status: Review +created: 2024-11-19 +feature: (fill in with feature tracking issues once accepted) +--- + + +## Summary + +This proposal adds a new consumable resource governing tiered memory bandwidth +usage similar to the way that Compute Units seek to govern CPU usage. +Tiered memory bandwidth will become a performance bottleneck as transaction +throughput and total state size increase. This proposal serves to outline +changes to the Solana protocol that would enable: + +- Deterministic, easily computable and cluster-wide separation of state into +hot and cold tiers. +- A new transaction level resource requesting the transfer of state from cold +to hot. +- Block level constraints on the total cold to hot state transition. + +These added features will allow for a pricing market for the bandwidth from +cold state to hot state (via priority fees), and allow block producers to more +optimally pack blocks to get the highest possible throughput on already hot +state and constrain access to cold state to be within bounds that the validator +network will be able to keep up with. + + + +## Motivation + +In commodity hardware (for fixed cost), there is a fundamental tradeoff between +the the size of accessible state and the bandwidth of random access to that +state. On-chip caches >> RAM >> SSD >> HDD >> NAS increase by orders of +magnitude in size, while falling by orders of magnitude in bandwidth. +For Solana (or any blockchain), treating all state as equivalent (regardless of + its usage patterns) means that either total state size will +be limited by the size of RAM, or the throughput of the network will be limited +to the bandwidth of disks. Actual usage patterns +(and expectations for future usage patterns as the network grows) show that a +relatively small amount of the total state is accessed +frequently, and most of the state is accessed infrequently. +This usage pattern allows a hot/cold tiered state design to allow the total +state size available from disk, while achieving the throughput available from +RAM. + +## New Terminology + +Chili Peppers (State Units?) - a consumable resource representing the number of +bytes loaded into the "hot store" (active, frequently +accessed memory) for state operations on the Solana blockchain. Each Chili +Pepper corresponds directly to one byte of data loaded, providing +a precise mechanism to quantify and limit the resources consumed by +transactions in terms of state memory usage. +Note that Chili Peppers required for a transaction are not the size of hot +state touched by the transaction, but rather the amount of cold +state made hot or new state allocated. Transactions that are only accessing +already hot state would require 0 Chili Peppers. + +Block Chili Pepper Limit - The maximum number of Chili Peppers that can be +requested in a single block. + +Block Chili Pepper Clock - a cumulative measure of the total Chili Peppers +requested since the genesis of the blockchain. At the beginning of each block, +the Block State Unit Clock is updated to reflect the cumulative total of Chili +Peppers consumed up to that point, ensuring a monotonically increasing record +of state consumption. + +Account Chili Pepper Clock Timestamp - each account in the "hot" state needs to +keep track of the value of the Block Chili Pepper Clock the last time it was +accessed (read or written to). This allows determination of which accounts are + hot and which are cold. + +Hot Cache Size - A new predefined constant, termed "Hot Cache Size" corresponds +approximately to the size of the hot state supported by the validator network. +An account is designated as hot if it was last +accessed within this threshold of the current Block Chili Pepper Clock +(Account Chili Pepper Clock Timestamp > Block Chili Pepper Clock - Hot Cache +Size), otherwise it is designated as cold. + + +## Detailed Design + +### Integration with ComputeBudget Program + +To facilitate the utilization of Chili Peppers, every transaction on the Solana + network will be required to use the ComputeBudget program to request the + maximum number of Chili Peppers they require. Alongside existing + functionalities, a new instruction will be introduced to specify the requested +State Units for the transaction. This ensures that developers have the +flexibility to request resources based on the anticipated needs of their +transactions, within the constraints of the block's Chili Peppers capacity. +The new ComputeBudgetInstruction will be as follows: + +```rust +discriminant: 5 +ComputeBudgetInstruction::SetChiliPepperLimit(u32) +``` + +The 32-bit unsigned integer in the instruction indicates the number of Chili +Peppers requested for the transaction. + +### Block Chili Pepper Clock + +The Block Chili Pepper Clock serves as a cumulative measure of the total Chili +Peppers requested since the genesis of the blockchain. At the beginning of +each block, the Block State Unit Clock is updated to reflect the cumulative +total of Chili Peppers requested up to that point, ensuring a monotonically +increasing record of state consumption. + +Computing the block Chili Pepper clock: + +```python +block_chili_pepper_clock = prev_block_chili_pepper_clock + + sum(txn.requested_chili_peppers for txn in block.txns) +``` + +Implemented as a 64-bit unsigned integer (uint64), this clock is updated at the +beginning of every block to reflect the total Chili Peppers requested since the +chain's genesis. This monotonically increasing value is stored in a dedicated +system variable (sysvar), ensuring that it remains accessible and immutable +throughout the blockchain's operation. +The new sysvar will have identifier: +`SysvarB1ockChiliPepperC1ock111111111111111111` + +```rust +struct SysvarBlockChiliPepperClock { + uint64_t state_unit_clock; +} +``` + + + +### Account Chili Pepper Clock Timestamp + +The Account Chili Pepper Clock Timestamp is an integral component within each +"hot" account, representing the account's interaction with the blockchain's +state management resources. This clock is dynamically set to match the current +Block Chili Pepper Clock at any instance an account is accessed (read or +written to) within a given block. +These clocks are also implemented as 64-bit unsigned integers. Whenever a hot +account is read from or written to within a block, its Account State Unit Clock +is updated to match the current Block State Unit Clock. +All accounts will have a Chili Pepper Clock Timestamp, which will only exist +for accounts which are hot, and is discarded for accounts which are cold. +All implementations should keep track of the current hot accounts. + +#### Hot and Cold Account Designation + +An account is designated as cold when its Account Chili Pepper Clock Timestamp +falls behind the current Block Chili Pepper Clock by more than the Hot Cache +Size parameter. + +An account which has never existed is considered cold. An account that is +deleted is still considered hot until its state unit clock lapses into cold. +Creating an account against a deleted account which is still hot, will create +the hot account again. + +#### Storage and Management + +To manage the Account State Unit Clocks efficiently, Solana employs a table, +associating each hot account with its respective Chili Pepper Clock Timestamp. +This table enables the dynamic tracking and updating of account states, +facilitating the transition of accounts between hot and cold statuses based on +their activity. + +### Error Cases for State Units Implementation + +Here are common error scenarios related to State Units and their respective +handling mechanisms: + +#### Exceeding Block Chili Pepper Limit + +- **Error Description**: This error occurs when a transaction's requested Chili +Peppers exceed the remaining capacity of the Block Chili Pepper Clock for the +current block. +- **Handling**: The block is marked as invalid and cannot be processed. + +#### Invalid Chili Pepper Request + +- **Error Description**: A transaction specifies an invalid number of Chili +Peppers, either by requesting more than a predefined maximum limit per +transaction or by formatting the request improperly. +- **Handling**: The transaction is invalidated, and an "Invalid Chili Pepper +Request" error message is issued. Developers must ensure that Chili Pepper +requests conform to protocol specifications, including proper formatting and +adherence to maximum limits. + +#### Account State Unit Clock Synchronization Failure + +#### Accessing Cold Account + +- **Error Description**: A transaction attempts to interact with an account +that has been designated as "cold" due to its Chili Pepper Clock Timestamp +falling below the "Hot Cache Size" threshold relative to the current Block +Chili Pepper Clock, without requesting sufficient Chili Peppers. +- **Handling**: The transaction is rejected with a "Cold Account Access +Attempted" error. + + +## Alternatives Considered + +What alternative designs were considered and what pros/cons does this feature +have relative to them? + +## Impact + +How will the implemented proposal impacts dapp developers, validators, and +core contributors? + +## Security Considerations + +What security implications/considerations come with implementing this feature? +Are there any implementation-specific guidance or pitfalls? + + +## Backwards Compatibility + +This proposal requires changes to the Solana Runtime Protocol and the +ComputeBudget program. It is not backwards compatible and will require updates +to existing programs and transactions to specify State Unit requirements. A +transition period and comprehensive developer support will be essential to +implement these changes smoothly across the ecosystem. \ No newline at end of file