NeuroFHE & ENER:
From idea to reference design.

An update on encrypted neural computation, the hardware taking shape around it, and the ENER patent draft.

Much of my recent work has been on a question: how much useful computation can we move off a device while keeping its raw signals local? NeuroFHE Relay is where I am testing that question. ENER—Encrypted Neural Embedding Relay—is the related patent draft, focused on the architecture for privacy-preserving neuroinference.

The recent milestone is a more concrete reference design: a defined split between local processing and encrypted evaluation, an FPGA implementation checked in software, and a coordinated set of circuit drawings and patent figures. There is now more to inspect, reproduce, and challenge.

This is a research progress update. NeuroFHE remains a research alpha; the ENER materials discussed here are a draft being prepared for review and filing.

The idea in plain language

A neural or sensor stream can contain far more information than a particular computation needs. The relay design first turns that stream into a smaller set of features inside a trusted local environment. It then encrypts the selected features before sending them to an external evaluator. Homomorphic encryption lets that evaluator perform supported calculations on encrypted values; the result returns for local decryption and checking.

The neuromorphic part concerns the event representation and local processing. The encryption part concerns what the external service can compute. Giving each a defined role makes the integration easier to reason about. That separation is the starting point in the NeuroFHE Relay research repository.

  1. Prepare locally. Acquire a signal window and encode its events or features.
  2. Check and encrypt. Apply the local export policy and encrypt the approved representation.
  3. Evaluate remotely. Compute supported scores on ciphertexts.
  4. Return locally. Decrypt, validate the result, and apply the permitted local decision.

The local host is part of the trust boundary: it still sees the raw input. Keeping that boundary explicit is essential to explaining what the design protects.

What has moved forward

The software work now includes a runnable JavaScript scaffold, native comparison paths using OpenFHE and TFHE-rs, and an evidence ledger that keeps different kinds of results separate. The lightweight demo uses educational toy encryption. The native runs provide a different class of evidence, with their own measurements and limitations.

The recorded native evidence includes local, single-window runs, with ciphertext-size and memory measurements. An EEG-derived TFHE-rs example records agreement with its plaintext calculation for one window. Those are useful checkpoints for implementation correctness, but they do not establish accuracy across a dataset or predictable performance on a deployed device. The claim evidence ledger carries those distinctions.

The September 5 reference-design package takes the hardware work further. It assigns local hosting and encryption to a Raspberry Pi, and event-processing logic to an iCE40 FPGA. The accompanying work includes synthesizable logic, pin assignments, a component list, circuit schematics, and a specification working copy that matches the new figures.

The package records 74 simulated frames, 14,262 input samples, and 4,736 counter comparisons for the encoder checks. The FPGA place-and-route run also meets its 16 MHz target. These are software simulation and implementation-tool results. The board has not been assembled, and device-specific acquisition and distributed encrypted evaluation still need integration and physical testing.

Where the ENER patent work stands

The ENER work is turning the architecture into a coherent draft package: a specification, proposed claim seeds, drawing descriptions, and a concrete reference embodiment. The latest design package contains 16 patent figures and eight circuit sheets, with matching descriptions and component references.

That effort has practical value beyond the documents themselves. A drawing forces decisions about where data lives, who holds the key, what crosses the network, and what happens when an input or result fails a check. Writing those decisions down also exposes the pieces that still need an experiment.

As of this update, I am describing preparation work, not announcing a filed or granted patent. Prior-art review and the evidence supporting the proposed claims remain work in progress. The public ENER source materials provide background; the September reference-design work described here is a later working package.

The questions that still matter

Smaller representations create an interesting tradeoff. Exposing which positions are active can save work, but those positions may themselves reveal patterns. Padding or encrypting a full window changes the cost and the information exposed. Compactness alone does not establish privacy, and the current synthetic reconstruction probes are not a privacy proof.

The next useful progress is measurable: run the native paths across more windows, compare latency and memory under the different export modes, test reconstruction and identity-linkage risks, and connect the reference design to a real acquisition path. Physical electrical checks and end-to-end validation are still ahead.

For now, the milestone is specificity. NeuroFHE has a clearer experimental path, and ENER has a more concrete design to review. I want the next update to show how those assumptions hold up when the components are tested together.


Follow the work: NeuroFHE Relay, the evidence ledger, and the ENER draft materials. This note reflects the repository documentation and September 5 reference-design package reviewed for this update.

← Back to all writing