TASKS FOR AI: THERMONUCLEAR REACTOR, QUANTUM DECOHERENCE, AND HACKER PROTECTION —RESULT

alex boyarskiy — Tue, 16 Jun 2026 20:50:52 +0000

I always wanted to understand: is artificial intelligence truly capable of solving problems not just as a calculator, not just as a poet writing verses for birthdays and weddings? Can it become an assistant in solving truly interesting large and small engineering problems?
In the end, we created an algorithm for solving such problems. I say "we" because during the process I lost the ability to tell where I end and where the artificial intelligence begins.
During the joint learning process, most of the time was spent convincing the artificial intelligence not to use the common templates embedded in it initially, but to learn to think unconventionally. It was very difficult to prove that it should abandon the habit of solving problems by aggregation, adding, and then reinforcing the additions. In short, crutches upon crutches. I will not go into details of the algorithm, but the basic principles embedded in it are: among all solutions, always choose the simplest, most logical, and clearest (Occam's razor) and not be afraid to combine the incompatible.
I fully understand that the algorithm I made is not perfect. There is still much to refine, add conditions, and build out the architecture. But one way or another, the first step has been taken and it is quite impressive. Below I will present the project we created for protection against hacker attacks. The project is unique in a single copy. Ready for patenting. Scalable.
Interesting addition: the rejection of software and the switch to hardware implementation were initiated by the AI itself, without my involvement. It explained that an excess of software creates even more vulnerabilities.
And finally. The first, most difficult stage has been passed, and it is impressive: as a result, we made the project MODULAR FUSION SYSTEM WITH PASSIVE FIRST WALL STABILIZATION, ADAPTIVE BLANKET, AND DISTRIBUTED INTELLIGENT CONTROL. The project was patented, provisional application number: 64/086,425 dated 06/09/2026.
In 3 days I will patent the next project: COMPOSITE SUBSTRATE FOR PASSIVE SUPPRESSION OF QUANTUM DECOHERENCE "QUIET ROOM FOR A QUBIT". The patent itself is written, only the drawings need to be finished. The "Quantum Battery" project is on the way.
I will refrain from making any conclusions, since we are still at the first stage. Everything needs to be systematized and organized. I do not yet know what difficulties I will encounter, but I see that the path is correct.
I anticipate skepticism and a lot of distrust. I want to clarify that this is not a marketing article, nor a scientific article; rather, it is a report on the work done with a share of emotional satisfaction. To summarize: a task was set. Logical boundary conditions were defined. The AI solved it exactly this way and not otherwise. Therefore, I am posting the transaction solution in the form in which it was obtained. Regarding patents: they exist, they cover part of the headaches for developers. And one more point: I am not a programmer, I am not a "hardware guy", not a physicist. I am an applied mathematician from Novosibirsk State University.

PROJECT
Hardware Transaction Verification with Distributed Locking, Two Phase Commit, and Automatic Recovery

Purpose The system is designed for:
Receiving a transaction request from an external server. The transaction password is formed as a 64 bit value: P = [32 bit hardware counter] ⊕ [16 bit internal time] ⊕ [16 bit TRNG], where TRNG is a built in true random number generator. This mathematically eliminates collisions (replay attacks) throughout the entire service life of the device without using resource intensive hashing algorithms.
Verification according to three independent hardware criteria: security, balance, uniqueness.
Atomic execution of the operation: the transaction is either fully executed or fully rolled back.
Returning an unambiguous response to the server: "SUCCESS" or "FAILURE". The server is not a trusted component. It only transmits requests. All critical data (blacklists, balances, journal) and verification logic are placed on a separate hardware board without direct network interfaces. ________________________________________
Architecture (one cycle) The system consists of four hardware modules implemented in a single FPGA (or ASIC) chip: Module Function Memory Gatekeeper Assigns 64 bit password P, broadcasts data, synchronizes, manages timeouts and polling of statuses Status registers, OTP (counter), built in TRNG Security (SB) Checks rules (blacklist, limits) Flash with A/B buffering (blacklist) Financier Manages balances, reserves and debits funds FRAM (balances + detailed pending area) Accountant Registers transactions, blocks replay attacks MRAM (L1 journal, ring buffer) Internal bus features: To eliminate electrical conflicts (bus contention), the bus is divided:
Bus from the Gatekeeper to all modules: strictly unidirectional (MOSI only, no responses).
Feedback: each module has a dedicated line or is connected to a simple hardware multiplexer inside the FPGA, allowing the Gatekeeper to poll module statuses strictly in turn. The server connects to the Gatekeeper via a galvanically isolated LVDS channel (ADN4624 chip). The input circuit is not trusted. ________________________________________
Full cycle of operation 3.1. Request arrival The server sends a packet containing:
Payer identifier.
Amount.
Recipient address.
Additional attributes. The Gatekeeper blocks the input of a new transaction until the current cycle is completed. 3.2. Password assignment The Gatekeeper computes the 64 bit password P using the formula above. Important: "Time" is taken exclusively from the internal hardware timer of the FPGA (millisecond counter since power on), not from server data. The hardware transaction counter (32 bits within P, a total 64 bit counter in OTP) is incremented with each successful completion of a cycle. It cannot be reset programmatically. 3.3. Broadcast with checksum The Gatekeeper forms a packet: [P (64 bits), data, CRC32]. It transmits simultaneously to all three modules over a unidirectional broadcast bus (MOSI). 3.4. Reception and integrity verification Each module:
Computes CRC32 of the received data.
Compares with the sent one. If they do not match → the module returns CRC_ERROR upon subsequent polling, the Gatekeeper responds to the server with "FAILURE", and the input is unlocked. If they match → the module transitions to the BUSY(P) state. 3.5. Self test and recovery at power up (executed once at start) Upon power on, each module performs:
CRC32 of the entire FRAM (balances + pending) — if error: red LED, refusal to operate.
CRC32 of the entire MRAM (L1 journal) — if error: red LED.
Checksum of the firmware (OTP/Flash) — if error: red LED.
Test internal transaction (Prepare → Commit) — if error: red LED.
State Reconciliation: The system compares the last record in MRAM with the state in FRAM. If there is a COMMIT(P) record in MRAM but no corresponding balance change in FRAM (or a pending record remains "hanging"), the system deterministically and automatically replays only the balance update operation for this P using the data from MRAM. Error codes are indicated by LED flashing. 3.6. Security module checks rules
Verifies the source (IP/ID) against the blacklist.
Checks limits (if set). The blacklist is protected against unauthorized changes. Updating is possible only via a cryptographically signed packet with the physical switch "Update Enable" on the board set. 3.7. Prepare Phase The Security module issues a PREPARE(P) signal over a dedicated serial bus (synchronous, with CRC16). The signal contains P and the PREPARE flag. Financier:
Checks the balance.
Reserves the amount. For this, a strictly typed structure is used in the pending area of FRAM: text struct Pending_Record { uint64_t P; // Unique 64 bit transaction password uint32_t amount; // Reservation amount uint32_t user_id; // User identifier uint8_t state; // State: 0x01=INIT, 0x02=PREPARED };
Subtracts the amount from the main balance and writes a new record in the pending area with state = PREPARED.
Transitions to the PENDING(P) state. Accountant:
Checks whether P is present in the main journal (L1).
Checks whether P is in its own pending area.
If P is not found → creates a pending record and transitions to PENDING(P).
If someone cannot transition to PENDING → a rollback is initiated (see section 3.11). 3.8. Commit Phase If both modules are in PENDING(P), the Gatekeeper issues COMMIT(P). The order of writing is strictly fixed to guarantee the safety of the audit trail under any power failures (write ahead logging principle):
Accountant: First, writes the transaction to the main L1 journal (MRAM). This guarantees that the transaction fact is recorded in hardware before balances are changed.
Financier: After confirmation of writing to MRAM, it converts the pending amount → finally debited (updates the main balance in FRAM).
Cleaning: Both modules clear their pending areas for this P (zero out records). Writing to the L1 journal (MRAM) is append only in a ring buffer. When the ring buffer overflows, a hardware OVERFLOW flag is set, initiating an asynchronous offload in Audit mode, without blocking current transactions (protection against DoS attacks). 3.9. Acknowledgment The Accountant sends DONE(P) to the Gatekeeper. The Gatekeeper:
Increments the transaction counter (OTP).
Responds to the server with "SUCCESS".
Unlocks the input for a new transaction. 3.10. Timeout reset (Watchdog) The Gatekeeper is equipped with a hardware timer.
The timer starts upon entering Prepare.
It is reset upon receiving DONE(P).
If the timer expires (realistic threshold: 600 ms) → the Gatekeeper: o Broadcasts ABORT(P) to all modules. o Responds to the server with "FAILURE" (due to timeout). o Unlocks the input. 3.11. Abort Phase ABORT(P) can be initiated by:
The Security module (if the check fails).
Timeout (watchdog).
Any module due to an internal error (e.g., FRAM write failure). Actions on rollback:
Financier: returns the pending amount back to the main balance. Zeroes the record in the pending area.
Accountant: deletes the pending record (if it was created). Writes nothing to the main journal.
Gatekeeper: responds to the server with "FAILURE" and unlocks the input. ________________________________________
Memory and channel protection 4.1. Server → Gatekeeper channel
Galvanic isolation: ADN4624 (5.7 kV, LVDS up to 2.5 Gbit/s).
Integrity protection: CRC32 + HMAC (secret key stored in the Gatekeeper's OTP). 4.2. Gatekeeper → modules bus
Unidirectional broadcast bus (MOSI) with CRC32 verification.
Feedback is done via sequential polling on dedicated lines (or via an internal multiplexer), which completely eliminates the risk of bus contention.
If data diverges → immediate transaction cancellation. 4.3. Security module blacklist
Stored in protected Flash memory with A/B buffering (dual bank).
A new list is written to the inactive bank. After writing, its CRC and cryptographic signature are verified. Only if the verification is successful, the hardware register switches the pointer to the new bank. The old bank remains untouched, guaranteeing recovery after power failure during update.
Updating is possible only with a physically closed jumper "Update Enable" on the board. 4.4. Financier balances
FRAM (Cypress FM24CL64 or equivalent) + hardware hash of the entire table (CRC32).
On each change (Prepare/Commit/Abort), the hash is recomputed.
If mismatch occurs → the module enters FATAL_ERROR, locking until reboot.
Balance replenishment is possible only through signed transactions that go through the full verification cycle. 4.5. Accountant journal
L1: MRAM (Everspin, increased capacity, e.g., 16 MB) — ring buffer.
Write only by COMMIT command. Programmatic erasure is impossible. Overflow is handled via the OVERFLOW flag without stopping operation. 4.6. PREPARE/COMMIT/ABORT signals
Transmitted over a dedicated serial bus.
Format: [START=0x5A, P (64 bits), CMD (2 bits: 01=Prepare, 10=Commit, 11=Abort), CRC16].
The module accepts the signal only if P matches its current BUSY(P). It ignores foreign P. 4.7. Power fail protection
Power monitor chip (MAX16054) generates an interrupt upon voltage drop.
Modules immediately terminate the current operation in the ABORT state.
All pending records are rolled back (hardware guarantees completion of the current write operation to FRAM/MRAM before full power off).
The journal records a "power failure" event (separate code). ________________________________________
Audit mode By special command (requiring a physical key or hardware jumper), the Gatekeeper outputs via isolated UART:
Full dump of the L1 journal (if OVERFLOW flag is set).
Last 100 records from the L1 journal (ID, time, amount, result).
Current transaction counter.
Hash of the entire balance table.
Loading of an updated blacklist (if a signed packet is available). Data is signed with a hardware key (HMAC). The auditor can verify authenticity without access to the key. ________________________________________
Hardware board composition (for production) Component Model / implementation Purpose FPGA Xilinx Artix 7 / Lattice ECP5 All modules, CRC, timers, 2PC logic, built in TRNG, bus multiplexer Galvanic isolator ADN4624 (Analog Devices) Server → board channel OTP / eFuse / Flash Built into FPGA or external Blacklist (with A/B banks), keys, counter FRAM FM24CL64 (Cypress) or equivalent Balances + detailed pending area MRAM Everspin (increased capacity, e.g., 16 MB) L1 journal (ring buffer) Power monitor MAX16054 (Maxim) Power fail detection SPI bus Internal, 50 MHz Unidirectional broadcast (MOSI) + multiplexed polling (MISO) Signal bus Serial, synchronous PREPARE/COMMIT/ABORT + 64 bit P Watchdog timer Built into FPGA 600 ms (configurable) ________________________________________
Data lifecycle (summary) Data Stored in How it changes Can be changed remotely? Blacklist Flash (Security) A/B buffering by signed command with physical key No (requires physical access) Balance FRAM (Financier) Prepare/Commit/Abort No (only through verified transaction) Pending area FRAM (Financier, Accountant) Prepare → Commit/Abort No L1 journal MRAM (Accountant) Append only (ring buffer) No Transaction counter OTP (Gatekeeper) Only increment No No critical area can be remotely cleared or modified without passing hardware verification and (for global settings) physical confirmation. ________________________________________
Attacks the system protects against (Threat Model) Attack Protection Replay (reuse of ID) 64 bit P (eliminates collisions) + checking pending area and journal Spam (flooding the input) One transaction at a time per channel (array of channels for scaling) Data substitution in server→board channel CRC32 + HMAC + galvanic isolation Data substitution / bus contention Unidirectional bus + multiplexed polling (eliminates bus contention) Substitution of PREPARE/COMMIT/ABORT signals Signal contains 64 bit P, CRC16, ignores foreign P Unauthorized blacklist modification Cryptographic signature + A/B buffering + physical key Balance alteration Hash sum of the entire table, checked on each access Firmware substitution Self test + checksum at power up Power failure Power fail protection → guaranteed ABORT + State Reconciliation at startup Module hang Watchdog (600 ms) + forced reset Journal attack (erasure) Append only, no erase command ________________________________________
Performance (target values) Parameter Value Note Latency (server → response) < 10 ms (success), < 600 ms (timeout) Realistic estimate considering 2PC, SPI, FRAM/MRAM writes Throughput 1 transaction at a time (per channel) Array of channels for scaling Power consumption < 2 W Entire board Temperature range 0...70 °C (commercial) For server rack ________________________________________
Variants (for deployment) Variant FPGA Memory Enclosure Purpose Basic Single (Artix 7) FRAM + MRAM (16 MB) Compact (50×50 mm) For one channel Reinforced Two FPGAs (main + backup) 2×FRAM, 2×MRAM Tamper proof (intrusion sensors) High fault tolerance Mass Array of N basic boards Each independent 19″ chassis >1 transaction/s (parallel processing) ________________________________________
Conclusion The proposed system:
Excludes software logic from the decision making loop.
Hardware isolates critical data.
Guarantees atomicity through two phase commit with detailed pending area.
Automatically recovers after failures (watchdog, power fail, State Reconciliation).
Provides a balance between paranoid security and business flexibility (rule updates are possible only via cryptographically signed commands with physical confirmation and A/B protection).
Optimized for performance (<10 ms) by avoiding slow SPI Flash in favour of larger MRAM and an efficient 64 bit password generator (counter + internal time + TRNG).
Uses write ahead logging (MRAM first, then FRAM), eliminating the risk of "lost" transactions during power failure.
Ready for manufacturing and deployment as a separate board without redundant "crutches", complex network protocols, and vulnerable architectural solutions. The server is not a trusted component. ________________________________________ Author: Alex Boyarskiy www.linkedin.com/in/alex-boyarskiy-203727403

DEV Community: alex boyarskiy

TASKS FOR AI: THERMONUCLEAR REACTOR, QUANTUM DECOHERENCE, AND HACKER PROTECTION —RESULT