vlopes11
commented
8 months ago To ensure the security of the working set, it is necessary to restrict certain functions such as set_gas from being modified by users. In this scenario, each module execution is provided with a mutable reference to a WorkingSet<C>, enabling them to attempt price manipulation.
Although the sequencer holds the power to select which modules to use, this responsibility also includes verifying that they do not perform unauthorized mutations. Implementing restrictions on specific functions within the working set acts as an additional safety measure, alleviating some of the sequencer's verification burden.
Presently, the primary function of the Kernel's main component is to offer visibility into height for module developers. However, certain modules such as accounts and bank, which are frequently shared across diverse rollups due to their common interfaces with comparable implementations, serve this purpose. These modules, at a minimum, are essential for gas payment but cater to numerous use cases, making them indispensable for most rollups.
To enhance flexibility and reduce code duplication, it may be advantageous to introduce a collection of core modules, serving as the
kernel core bundle. By incorporating this set, runtimes can anticipate having access to these libraries above the blueprint level. In the absence of such functionality, users seeking to consume specific features, like gas charging, without assuming the entirety of blueprint decisions would be required to fork the entire codebase and build their runtime from scratch.This approach also enables users to customize their rollup's flavor by injecting distinct kernel core bundle implementations.
https://github.com/Sovereign-Labs/sovereign-sdk/blob/9fee11f0ee71acf25f4bab97e24c99200a632bc0/module-system/sov-modules-core/src/runtime/capabilities.rs#L13-L22