PROJECT BLOCKCHAIN: From Conventional Blockchain to Reciprocal, Verifiable Computing

Blockchain is an assembly of older technologies: hash functions, Merkle trees, digital signatures, replicated logs, and consensus protocols. Its core guarantee is narrower than its reputation: it establishes agreement about recorded state. It does not establish that the information entering the system was truthful, that a transaction was legitimately authorized, or that the original event was accurately represented. That distinction is the centre of this paper. Two real incidents in October–November 2026 make the distinction concrete. In the Binance theft, digital assets reported at approximately $6.3–6.36 billion (figure unresolved — see §3.2) were transferred in transactions that were cryptographically valid, correctly signed, accepted by the blockchain, and permanently recorded — and still unauthorized by the legitimate owner. In the Chainalysis breach, Chainalysis reported exposure of customer names, usernames, password hashes and live authentication tokens, while stating that it had found no evidence that underlying investigation content had been accessed or attribution data manipulated. Neither incident touched any blockchain's consensus. Both were failures of the identity, authorization, signing, and operational infrastructure around the chain — with one qualification the paper now states explicitly (§3.2): protocol-level authorization features (EIP-7702) sit inside the chain's own semantics and can amplify an external compromise, so the boundary between "the chain" and "the surrounding infrastructure" is not absolute. This paper takes blockchain apart — foundations, cryptography, consensus, networking, execution, identity and authority, economics and governance, privacy and efficiency — and compares each component against established alternatives (replicated logs, PBFT, Raft, Certificate Transparency, Zero Trust, capability security, formal verification). It then proposes a separation-of-authority architecture: eight independently controlled stages (request, identity, authentication, authorization, signing, execution, verification, evidence), tested against common-mode compromise, with Michael Pilaprat's existing technologies (Athena Principle, MAYBE, GateScript, Athena Shield, FSMT, AKASHA, LUMa, Infinite Script / Entropy Metabolism, Hermy / local AI, privilege separation) investigated as research candidates — not assumed to be superior. Testing Round 1 ran: two reported runs of experiments E1–E18 (Helen; Claude), kept separate. They were same-session, self-reported, differently specified, and neither evidence package was received — so they are REPORTED, not OBSERVED, and not independent runs. The results are partial and honest. A reader with only public data verified a complete record bundle with no false accepts (E17, Claude-reported) — a promising pilot observation, and a standard Certificate-Transparency-style design rather than a novelty. Two preregistered hypotheses failed (E3, E11). The direct test of verifier independence (E14) was not run by anyone. The central question — whether blockchain's functions can be achieved through a fundamentally different, more efficient architecture under equivalent security, decentralization, availability, and independence assumptions — remains UNKNOWN. Since v0.2.1, two further rounds ran. First, the corrected E02/T03 experiment: Aphrodite's Rev2 harness, run by Lucy, places verification before execution and blocks the revoked-session, policy-limit, and missing-signature attacks at the fully hardened level — but a compromised verifier alone still moves funds, and dual verifier-plus-policy compromise still moves funds, so pre-execution gating is demonstrated only against the attacks it was built to block, not against verifier compromise. Second, Aphrodite's harness series E04–E10 (Typed MAYBE, FSMT logs, AKASHA provenance, LUMa intent, entropy-aware verification, Athena Shield, contestable coordination): E04's numbers reproduce exactly, but its comparison of the three modes is invalid as designed (each mode was tested on a different transaction set); E05–E10 are reported by Aphrodite with source-level audit notes from Lucy, and several of their headline percentages are properties of how the code was written rather than measured security properties (see §8.7). The paper also now states explicitly, following DeepSeek's review, that its own reference architecture specifies post-execution verification (§6.1 stage 7, §6.3 layer 6) — so the verification-after-execution defect in Grok's code is also an architectural ambiguity in this paper, and whether a pre-execution gate should be added is an open problem (§11). Since v0.2.2, DeepSeek reviewed this draft in Chinese at Michael's request (register item 44) and found three priority corrections, all adopted here: the E05–E10 baselines are strawmen (the results are relabelled illustrative, with fair baselines specified for the next generation); the E02/T03 minimum-winning-set statement contradicted the common-mode finding (now stated per implementation, with configuration); and the Rev2 'cryptographic threshold' wording overstated HMAC signature-presence checks (downgraded). Two of his flagged typos were checked against the text and are not present in v0.2.2 — the paper already reads 'q≥0.8' and 'staking' — and the GateScript terms he flagged as undefined are already marked BLOCKED / not testable at §7.1. The paper's conclusion is a bridge, not a replacement: understand existing infrastructure, introduce read-only observation and independent verification, separate authority, and only then build interoperable reference implementations. The largest opportunity may not be improving blockchain consensus itself. It may be improving the security and verifiability of everything that happens before a transaction reaches consensus and everything that happens after it. Proposed research draft, version 0.2.3 — not validated. No independent human expert review has been conducted. AI-assisted. Evidence labels per the paper section 2.1: ESTABLISHED / OBSERVED / REPORTED / INTERPRETATION / HYPOTHESIS / PROPOSAL / UNKNOWN. E14 (direct test of verifier independence) has not run; E05–E10 results are reported, not independently run.