SIMD-0105
Maintain Dynamic Set of Reserved Account Keys
Feature Gate Status
8U4skmMVnF6k2kMvrWbQuRUT3qQSiTYpSjqmhmgfthZu
TL;DR
The transaction scheduler and the runtime both demote transaction write locks for builtin programs and sysvars using a static list of reserved IDs. This proposal replaces the currently used static lists of builtin program and sysvar IDs with a dynamic set of reserved account keys that can be updated at epoch boundaries with feature gates.
Summary
The transaction scheduler and the runtime both demote transaction write locks for builtin programs and sysvars using a static list of reserved IDs. This proposal replaces the currently used static lists of builtin program and sysvar IDs with a dynamic set of reserved account keys that can be updated at epoch boundaries with feature gates.
Motivation
The current approach of using static lists of reserved IDs doesn't allow core developers to modify which account write locks should be demoted without breaking consensus. Since the static lists were introduced years ago, a few sysvars and some popular builtin programs have been developed that should not be able to be write locked but their keys cannot be added to the static lists. This demonstrates a need for a set of reserved keys that can be updated safely over time.
Key Changes
- SysvarC1ock11111111111111111111111111111111
- SysvarEpochSchedu1e111111111111111111111111
- SysvarFees111111111111111111111111111111111
- SysvarRecentB1ockHashes11111111111111111111
- SysvarRent111111111111111111111111111111111
- SysvarRewards111111111111111111111111111111
- SysvarS1otHashes111111111111111111111111111
- SysvarS1otHistory11111111111111111111111111
- SysvarStakeHistory1111111111111111111111111
- Sysvar1nstructions1111111111111111111111111
- Config1111111111111111111111111111111111111
- Feature111111111111111111111111111111111111
- NativeLoader1111111111111111111111111111111
- Stake11111111111111111111111111111111111111
- StakeConfig11111111111111111111111111111111
- Vote111111111111111111111111111111111111111
- 11111111111111111111111111111111
- BPFLoader1111111111111111111111111111111111
- BPFLoader2111111111111111111111111111111111
- BPFLoaderUpgradeab1e11111111111111111111111
Impact
Impact should be negligible. dApp developers don't need to change how they build transactions due to the developer friendly nature of the write lock demotion feature.
Security Considerations
The main consideration is making sure that all `is_writable` checks are consistent before and after implementing this proposal to avoid breaking consensus. Additionally, this dynamic set is intended for protecting a small number of core protocol accounts. If the need arises for more larger scale write lock management, a new proposal should be introduced.