⚙️ Low Priority: Move hard-coded values to configuration structs

[quantumshiro]

Problem

The codebase contains numerous hard-coded values that should be configurable for different deployment environments and use cases.

Hard-coded Values Identified

File: src/modular/execution.rs

Lines 176, 472: Hard-coded gas limits

// ❌ Current: Hard-coded values
const DEFAULT_GAS_LIMIT: u64 = 100000;
let max_gas = 500000;

Solution: Create ExecutionConfig struct

#[derive(Debug, Clone)]
pub struct ExecutionConfig {
    pub default_gas_limit: u64,
    pub max_gas_limit: u64,
    pub gas_price_multiplier: f64,
}

File: src/blockchain/block.rs

Lines 42-44: Hard-coded difficulty parameters

// ❌ Current: Magic numbers
if difficulty < 4 { difficulty = 4; }
const MAX_DIFFICULTY: u32 = 32;

Solution: Create DifficultyAdjustmentConfig

#[derive(Debug, Clone)]
pub struct DifficultyAdjustmentConfig {
    pub min_difficulty: u32,
    pub max_difficulty: u32,
    pub adjustment_interval: u32,
    pub target_block_time: Duration,
}

File: src/network/network_manager.rs

Lines 95-103: Hard-coded network timeouts and limits

// ❌ Current: Fixed timeouts
let connection_timeout = Duration::from_secs(30);
let max_peers = 50;
let retry_attempts = 3;

Solution: Create NetworkManagerConfig

#[derive(Debug, Clone)]
pub struct NetworkManagerConfig {
    pub connection_timeout: Duration,
    pub max_peers: usize,
    pub retry_attempts: u32,
    pub heartbeat_interval: Duration,
}

Configuration Management Strategy

1. Create Configuration Structs

• Define clear configuration structures for each module
• Use reasonable defaults with Default trait implementation
• Add validation methods for configuration values

2. Configuration Loading

• Support TOML configuration files (matching existing pattern)
• Environment variable overrides for deployment flexibility
• Command-line argument support for common settings

3. Configuration Validation

• Implement validation methods for each config struct
• Provide clear error messages for invalid configurations
• Add configuration testing in CI/CD pipeline

Example Implementation

// Configuration struct with validation
#[derive(Debug, Clone, Deserialize)]
pub struct ExecutionConfig {
    pub default_gas_limit: u64,
    pub max_gas_limit: u64,
    pub gas_price_multiplier: f64,
}

impl Default for ExecutionConfig {
    fn default() -> Self {
        Self {
            default_gas_limit: 100_000,
            max_gas_limit: 1_000_000,
            gas_price_multiplier: 1.0,
        }
    }
}

impl ExecutionConfig {
    pub fn validate(&self) -> Result<(), ConfigError> {
        if self.default_gas_limit > self.max_gas_limit {
            return Err(ConfigError::InvalidGasLimits);
        }
        if self.gas_price_multiplier <= 0.0 {
            return Err(ConfigError::InvalidGasPrice);
        }
        Ok(())
    }
}

Benefits

• 🔧 Flexibility: Easy deployment configuration changes
• 🧪 Testing: Different configs for testing scenarios
• 🚀 Deployment: Environment-specific optimizations
• 📊 Monitoring: Runtime configuration adjustments
• 🔒 Security: Configurable security parameters

Definition of Done

• All hard-coded values moved to appropriate config structs
• Configuration structs implement Default and validation
• TOML configuration file support added
• Environment variable overrides implemented
• Configuration validation with clear error messages
• Documentation updated with configuration options
• Tests verify configuration loading and validation

Priority: ⚙️ Low

Improves flexibility but doesn't block core functionality development.

Estimated Effort: 3-4 days