A continuous-state neural virtual machine executing Turing-complete logic via encrypted geometric noise.
Features • Architecture • Installation • Usage • Security
Project Stella is a highly experimental Proof of Concept (PoC) for a fundamentally new paradigm in software execution. Instead of executing discrete, sequential instructions moving through a traditional von Neumann memory space, Stella compiles standard assembly logic into a massive, multi-dimensional neural matrix.
During runtime, the execution state (variables, instruction pointers, and logic branches) exists purely as "activation energy" bouncing around an unhinged linear algebra system. To an outside observer dumping the VM's memory, the program looks like a chaotic mess of floating-point noise. Conceptually, Stella acts as a "Neural Fully Homomorphic Encryption (FHE)" environment, enabling the host processor to perform deterministic logic without ever comprehending the semantics, spatial layout, or sequential flow of the code it is running.
All arithmetic (ADD, SUB), logic (AND, OR, NAND, NOT), and memory (LATCH) operations are superimposed onto a unified weights matrix. The entire Virtual Machine has no traditional CPU loop—it simply multiplies the state vector by the matrix on every tick.
Standard branching (JMP, JEQ) is implemented via continuous attractor dynamics. Execution energy physically drains from one region of the matrix and pulses into another based on neural activation thresholds.
- Instructions on the same matrix row execute simultaneously in superposition via Additive Accumulation.
To prevent the "Vanishing Gradient" problem common in recurrent neural systems, Stella uses a custom Q32.32 Fixed-Point Math Engine. This guarantees 0.000000000 rounding error, allowing infinite loops and stable latches to sustain execution for billions of cycles without floating-point degradation.
Every compiled program is pad-injected with "junk nodes" and cryptographically shuffled using an
The "junk nodes" are not simply zeroed out; they are woven into Irrational Rotational Matrices that force the CPU to compute non-repeating orbital trajectories bounded by the activation function. This boils the runtime state in active entropy, blinding Differential Power Analysis (DPA) and electromagnetic side-channel attacks.
The stella_vm binary contains no parsers or interpreters. It evaluates the entire program simultaneously via a single non-linear mathematical step:
-
$W$ = The dense Weight Matrix (Logic/Routing). -
$B$ = The Bias Vector (Constant loads/Thresholds). -
$S_t$ = The State Vector (Registers + Instruction Pointer). -
$\text{clamp}_{0}^{1}$ = The activation function preventing unbounded energy growth.
When you compile a .asm script, the compile_demo assembler generates the true logic matrices (
This spatial transformation is mathematically isomorphic—the continuous logic executes perfectly inside the encrypted basis, and is only decoded back to physical reality by the legitimate client holding the private .key file.
To generate this permutation matrix, the compiler initializes a Hénon Map Strange Attractor seeded by nanosecond system time, extracting cryptographic entropy from a non-linear chaotic orbit.
Because Stella evaluates all rows simultaneously, it fundamentally behaves like a Field Programmable Gate Array (FPGA) rather than a sequential CPU. Signals experience physical propagation delay (e.g., a NOT gate takes exactly one matrix multiplication cycle to invert its output). As a result, developers must account for real-world electrical race conditions by using "Buffer Nodes" to hold execution energy while logic gates settle.
- Rust 1.70+
- Cargo package manager
# Clone the repository
git clone https://github.com/SSL-ACTX/Stella.git
cd Stella
# Run the test suite to verify the fixed-point math and neural parser
cargo test
Stella operates in a disconnected workflow. You compile the matrix, encode your inputs using a client tool, run the matrix blindly in the VM, and decode the output.
Create a file called program.asm. The first line must define the required logical .SIZE.
.SIZE 4
; Constants
MOV N0, 1.0
MOV N1, 1.0
; Logic
AND N2, N0, N1 ; N2 = 1.0 AND 1.0 = 1.0
; Control Flow / Memory
JEQ N2, N0, N3 ; If N2 is active, pulse N0 into N3
LATCH N3, N3 ; Trap the energy in N3 permanently
This will pad the state size (e.g., to 16 nodes), scramble the matrix geometrically, and output my_app.stella (the binary) and my_app.key (your decoder ring).
cargo run --bin compile_demo -- program.asm my_app
Pass the logical inputs to the stella_client. It maps your logical bits into the physical obfuscated locations within the padded 16-dimensional vector.
cargo run --bin stella_client -- encode my_app.key 1.0 1.0 0.0 0.0
# Output: [0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, ...] (Copy this payload)
Paste the encoded payload directly into the Stella VM. The runtime has no concept of what it is executing; it simply circulates the noise for
cargo run --bin stella_vm -- my_app.stella 0.0 1.0 0.0 0.0 0.0 0.0 1.0 0.0 ...
# Output: Final I/O State: [0.0, 0.0, 1.0, 0.0, 1.0, 0.0, ...] (Copy this output)
Feed the VM's raw output back into the client to collapse the superposition back into readable discrete logic.
cargo run --bin stella_client -- decode my_app.key 0.0 0.0 1.0 0.0 1.0 0.0 ...
# Output: [1.0, 0.0, 1.0, 1.0, 0.0, ...] (N3 Successfully Latched!)
To prove the robustness of the matrix compilation, this repository includes a Known-Plaintext Attack Proof of Concept (stella_dis).
If an attacker captures both your un-padded source.asm and your app.stella binary, they can theoretically brute-force the permutation matrices:
cargo run --bin stella_dis source.asm app.stella
# [!] SUCCESS: Obfuscation key recovered! Mapping: [1, 2, 3, 0]
To defend against this, the production compiler pads the .SIZE to
Warning
Experimental PoC Status: Project Stella is a research endeavor into continuous-state execution and neural obfuscation. It is strictly an alpha-stage Proof of Concept.
- Not for Production: The assembler does not currently implement syntax checking, and the linear constraints mean multi-layer programs require manual "Energy Register" management to prevent matrix row collisions. Furthermore, code must be engineered with hardware-like propagation delays in mind to prevent race conditions.
-
Performance: Simulating sequential logic via
$O(N^2)$ matrix multiplications is inherently slower than standard native execution.