Skip to main content

Runtime Modifications

SphereNet enhances the capabilities of the Solana Virtual Machine (SVM) by implementing targeted modifications that enhance security, performance, and cryptographic efficiency. Each modification is designed to enforce strict node and code authorization, expand computational resources for advanced cryptographic operations, and optimize transaction processing during high load.

Validator Whitelist Enforcement​

The stake program has been modified to only allow delegations to whitelisted validators. This whitelist is maintained via on-chain governance and stored in a dedicated account. While any node can operate as a validator, only whitelisted validators can receive stake delegations, effectively limiting their voting power and undue influence over the network. The whitelist tracks:

  • An identity public key identifying the validator
  • A start epoch indicating when the validator can join the whitelist
  • An end epoch indicating when the validator's authorization expires

The whitelist is represented by the following structure:

pub struct Validator {
    pub identity: Pubkey,       // Validator's identity public key.
    pub start_epoch: u64,       // Epoch when the validator can be added to the whitelist.
    pub end_epoch: u64,         // Epoch until which the validator is authorized.
}

pub struct ValidatorWhitelist {
    pub min_stake: u64,                   // Minimum stake required for validator eligibility.
    pub last_update_epoch: u64,           // Epoch when the whitelist was last updated.
    pub validators: Vec<Validator>,       // List of whitelist entries.
}

During stake delegation, the stake program performs several checks:

  1. Verifies the validator's identity exists in the whitelist
  2. Confirms the current epoch is between the validator's start and end epochs
  3. Ensures the validator meets the minimum stake requirement (will be set to 0 for now) Only when all conditions are met can stake be delegated to the validator.

Program Whitelist Verification​

The BPF loader has been modified to restrict program deployment and management exclusively to a Program Derived Address (PDA) of the governance program. This PDA is the only entity authorized to:

  • Deploy new programs
  • Upgrade existing programs
  • Close programs if needed

This design ensures that all program lifecycle operations must go through the governance process. Any attempt to deploy or modify programs from other addresses will be rejected by the runtime. Through this mechanism, the network maintains strict control over its program environment while enabling upgrades and modifications through decentralized governance decisions.

Expanded Compute Capacity​

To support advanced cryptographic operations such as zero-knowledge proof verifications, the block compute unit limit has been increased to 100 million units. This expansion ensures that resource-intensive computational tasks do not impede overall network performance, enabling efficient processing even under heavy load.

Transaction Prioritization​

Custom prioritization algorithms have been incorporated into the transaction processing pipeline. These algorithms assess transactions based on criteria such as maker/taker roles and system-critical operations, ensuring that high-priority transactions are processed promptly. This dynamic prioritization maintains throughput and responsiveness even during periods of elevated network activity.