This Week’s Focus
The primary focus this week was on implementing a new username-based block producer identity system and establishing deterministic genesis initialization for the upcoming Solar blockchain. This change represents a significant architectural shift in how block producers are defined, initialized, and synchronized across both the execution and consensus layers.
The Challenge
Until now, block producer (BP) identities were address-based, relying on EVM-style account keys. While this design worked for basic BP management, it caused recurring problems at the genesis stage, where BP data needed to exist before the chain started — but the state system responsible for storing that data only activates after genesis.
This created a circular dependency: the network couldn’t start without block producers, and block producers couldn’t exist without network state.
The result was a complex initialization paradox that led to inconsistent validator states, occasional phantom state references, and potential corruption in post-genesis synchronization.
Solving this problem required completely rethinking how block producers identities are represented — not just in the database layer, but across the full architecture of the chain.
Current Approach
To solve this, we introduced a username-based block producer identity system similar to our current blockchain, replacing address-based keys as the canonical identifier for block producers.
Here’s how it works:
- •Each block producer now has a username as its immutable primary key.
- •External NodeIDs are mapped to these usernames, decoupling BP identity from consensus participation.
- •A shared storage layer bridges the execution and consensus layers using snapshot-based BP data flow instead of preallocated state.
- •This architecture ensures that all BP data passes through controlled, post-genesis initialization paths — eliminating the state corruption and “phantom reference” issues observed earlier.
This redesign also standardizes how BP information is represented across both EVM-compatible modules and the Avalanche consensus layer, bringing consistency and predictability to state management.
Status
The username-based block producer identity system is now fully implemented. The ValidatorDB bridge architecture is operational, providing a unified framework for state snapshots and validator synchronization. This marks a major step toward stabilizing validator lifecycle management and ensuring a clean, deterministic genesis process.
Summary
This week’s milestone fundamentally redefines how block producer data is handled within the new Solar blockchain.
By transitioning from address-based to username-based validator keys, Solar eliminates historical state initialization issues and gains a future-proof identity model that supports:
- •Seamless block producer onboarding
- •Modular identity upgrades
- •Tokenization and delegation models without requiring hard forks
The ValidatorDB architecture has also been repaired and optimized to prevent pre-allocated state conflicts for future blocks, relying on a snapshot-based data flow instead. This ensures that state initialization happens cleanly, with deterministic storage slots compatible with both EVM semantics and Avalanche consensus expectations.
With this foundation in place, Solar Core 5.0 is now equipped for the next phase of development — finalizing consensus-layer integration and preparing for internal network testing ahead of the new testnet release.