The Case for a Modular SVM

An effort is underway at Anza to extract most of the transaction processing pipeline out of the validator and into what will be known as the Solana Virtual Machine (SVM).

solana-labs/solana#34196

anza-xyz/agave#389

Although the official specification of this standalone SVM is still in development, it's important that we get this right.

An isolated SVM would be a transaction processing pipeline that can operate independent of any validator. Validators would then run some implementation of an SVM, and brand-new services could be built on top of custom SVM-compatible engines.

Why is a Modular SVM Important?

Having a decoupled SVM with its own well-defined interface unlocks the ability for teams to build custom SVM implementations, including:

• SVM rollups
• SVM sidechains
• SVM-based off-chain services

Solutions like these can make Solana more performant and more reliable, as well as expand the landscape of possible products and services that can be built within its ecosystem.

👉 But let's push the envelope. Imagine if we engineered this new isolated SVM to be an assembly of entirely independent modules. Any SVM implementation could simply drive these modules through well-defined interfaces.

This further disintegrates the barriers to SVM-compatible projects by requiring significantly less overhead to architect custom solutions. Teams could simply implement the modules they care about while using already established implementations for the others (such as those from Agave or Firedancer).

How Do We Get There?

We must take this opportunity to break away from library patterns that have plagued both core and protocol developers for a long time. Some of these issues include:

• High-level libraries depending on low-level libraries for simple things such as types.
• Tightly-coupled libraries using each other's objects instead of interfaces and adapters.
• Metrics-capturing strands wired from the highest-level packages all the way to the lowest-level.

The modularity goals outlined in the previous section can be obtained by remedying these issues. Some suggested solutions are as follows:

• Leverage lean, low-level type packages.
• Differentiate between interfaces and implementations.
• Connect implementations using interface adapters.
• Bake metrics into the specification.

About This Repository

This repository seeks to demonstrate the concepts above by offering two groups of crates:

• solana: The specification-based crates for types and interfaces, to be used by implementations.
• agave: Anza's Agave client implementations of the solana specifications.

The solana-runtime specification (grossly over-simplified here) details a runtime that makes use of an SVM. However, notice that this is all done with interfaces.

modular-svm/solana/runtime/src/specification.rs

Lines 10 to 33 in ab1396d

	/// The Solana Validator Runtime.
	pub trait ValidatorRuntime<TB: TransactionBatch, TP: TransactionBatchProcessor> {
	/// Get the batch processor.
	fn batch_processor(&self) -> &TP;
	/// Load and execute a batch of transactions.
	fn load_and_execute_transactions(&self, batch: &TB) -> LoadAndExecuteTransactionsOutput;
	}
	/// A batch of Solana transactions.
	pub trait TransactionBatch {
	/// Get the sanitized transactions.
	fn sanitized_txs(&self) -> &[SanitizedTransaction];
	}
	/// The output of the `load_and_execute_transactions` method.
	pub struct LoadAndExecuteTransactionsOutput {
	pub loaded_transactions: Vec<TransactionLoadResult>,
	pub execution_results: Vec<TransactionExecutionResult>,
	pub retryable_transaction_indexes: Vec<usize>,
	pub executed_transactions_count: usize,
	pub executed_non_vote_transactions_count: usize,
	pub executed_with_successful_result_count: usize,
	pub signature_count: u64,
	}

Meanwhile, the Agave runtime is now an implementation (agave-runtime), and it simply implements the solana-runtime interface, but without specifying a specific SVM implementation.

modular-svm/agave/runtime/src/lib.rs

Lines 11 to 45 in ab1396d

	/// The Agave Validator Runtime.
	pub struct AgaveValidatorRuntime<BP: TransactionBatchProcessor> {
	/// SVM-agnostic batch processor.
	pub batch_processor: BP,
	}
	/// Agave Validator Runtime Base Implementation.
	impl<'a, BP: TransactionBatchProcessor> ValidatorRuntime<AgaveTransactionBatch<'a>, BP>
	for AgaveValidatorRuntime<BP>
	{
	fn batch_processor(&self) -> &BP {
	&self.batch_processor
	}
	/// Load and execute a batch of transactions.
	fn load_and_execute_transactions(
	&self,
	_batch: &AgaveTransactionBatch,
	) -> LoadAndExecuteTransactionsOutput {
	/*
	* MOCK.
	*/
	let _batch_processor = self.batch_processor();
	//
	LoadAndExecuteTransactionsOutput {
	loaded_transactions: vec![],
	execution_results: vec![],
	retryable_transaction_indexes: vec![],
	executed_transactions_count: 0,
	executed_non_vote_transactions_count: 0,
	executed_with_successful_result_count: 0,
	signature_count: 0,
	}
	}
	}

The beautiful thing here is that any SVM could easily be plugged into Agave's runtime implementation. Anyone could configure an Agave node, then write an adapter for some other SVM implementation and plug it in right here.

modular-svm/agave/validator/src/lib.rs

Lines 11 to 21 in ab1396d

	// This is a grossly over-simplified demonstration of an adapter, bridging the
	// SVM-agnostic Agave runtime implementation with the Agave SVM implementation.
	// Ideally, this would instead manifest as some module that could be easily
	// replaced if another SVM implementation were to be used.
	type Svm<FG> =
	AgaveTransactionBatchProcessor<AgaveValidatorRuntimeTransactionProcessingCallback, FG>;
	/// A mock Agave Validator.
	pub struct AgaveValidator<FG: ForkGraph> {
	pub runtime: AgaveValidatorRuntime<Svm<FG>>,
	}

🔑 🔑 A huge advantage with this arrangement is the fact that consensus-breaking changes would reside in the specification-level, guarded by SIMDs, while developers could more freely adjust implementation-level code and ship new versions without worrying about partitioning the network.

Other important notes:

• This demo uses lightweight "leaf node" crates for types (ie. solana-compute-budget).
• Some leaf node crates are specification-wide (ie. solana-compute-budget) while others are implementation-specific (ie. agave-program-cache).
• Although metrics are not demonstrated here (yet), the idea is that they would reside in one's implementation, and be vended back up to the callers.