Kernel core modules bundle

[vlopes11]

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.

sovereign-sdk/module-system/sov-modules-core/src/runtime/capabilities.rs

Lines 13 to 22 in 9fee11f

	/// The kernel is responsible for managing the inputs to the `apply_blob` method.
	/// A simple implementation will simply process all blobs in the order that they appear,
	/// while a second will support a "preferred sequencer" with some limited power to reorder blobs
	/// in order to give out soft confirmations.
	pub trait Kernel<C: Context, Da: DaSpec>: BlobSelector<Da, Context = C> + Default {
	/// Return the current slot height
	fn true_height(&self) -> u64;
	/// Return the height at which transactions currently *appear* to be executing.
	fn visible_height(&self) -> u64;
	}

[vlopes11]

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.