待翻譯:In 2026: we now have a third way between Open Source and Closed Corporations
AI 服務暫時不可用,以下為來源摘要,待恢復後補全翻譯:U — The Intermediate Form — Safebots Safebots · U Language · August 2026 U — The intermediate form. How a structured language inside attested compute creates a third way between open source and closed corporations. Why…
AI 服務暫時不可用,以下為來源正文,待恢復後補全翻譯。
U — The Intermediate Form — Safebots Safebots · U Language · August 2026 U — The intermediate form. How a structured language inside attested compute creates a third way between open source and closed corporations. Why "provably" is a different category of claim from "tested." And what that unlocks. 1. The three-way problem. Open source Trust the code because you can read it. The flaw: nobody does. The xz backdoor sat for two years. The cost of reading scales with codebase size, and nobody pays it. Closed corporation Trust us — reputation, SOC 2, lawyers. The flaw: trust is a promise, not a property. Promises break when incentives change. The third way Trust the seal, the compiler, and the reproducible verdict. The compiler proved what the code can do. The proof is in the artifact. Anyone can verify it. Open source gives you the right to verify but not the ability. Closed corporations give you neither. Safebox proposes a third way: trust the running code because a sealed, attested environment analyzed it — using tools that are themselves pinned, reproducible, and verifiable. The question is: what makes the analysis good enough to trust? 2. The intermediate form. There's a pattern in computer science that shows up everywhere: the trick is finding an intermediate representation structured enough to be processed cheaply in both directions. A B-tree gives O(log n) at write time and O(log n) at read time. A flat array gives O(1) writes but O(n) reads. A fully sorted array gives O(log n) reads but O(n) writes. The B-tree trades a small constant factor for logarithmic performance in both directions. Unstructured code Python, JS, PHP. Easy to write. Hard to analyze. The auditor must infer ownership, mutability, nullability, effects, capabilities from conventions. Cost scales with codebase size. Fully formal specs TLA+, Coq, Isabelle. Easy to analyze. Hard to write. Cost of writing scales with properties. Practitioners are rare. U — the intermediate form Every binding site is a machine-readable declaration. Cost of writing: near zero (auto-filled, safest default). Cost of analyzing: O(1) per binding. The compiler catches 11 categories of bugs at build time — null dereference, use-after-free, data races, injection, missing error handling, off-by-one, SQL injection, float rounding, forgotten await, lost database update, indentation. These are structurally impossible in well-typed U, not merely unlikely. The same declared structure that lets the compiler verify correctness also lets an LLM verify intent — at far higher fidelity than with Python or TypeScript, because the properties it needs to reason about are declared, not inferred. 3. What U declares that other languages don't. annotationdeclareswhat the auditor learns for free -Rvalue never escapes its scopeno aliasing, no UAF, no sharing bugs +Rheap-resident, ARC-managedcheck sharing discipline -Mimmutable through this referenceno TOCTOU, no data race on this path +M(MVCC)mutable with a specific policycheck the policy is appropriate -Nguaranteed non-nullno null dereference — skip it -Eeffect-freesafe to reorder, parallelize, memoize, retry -Ddeterministicsafe to cache; auditor can reproduce any call ! ErrorTypeexact failure surfaceerror surface is enumerated, not guessed o { Network.HTTP }module has network capabilityentire capability surface in one scan In Python, the auditor must infer every one of these from context. In U, they are declared at the binding site and verified by the compiler. The auditor reads facts, not guesses. 4. What a pinned LLM can do with declared structure. A "pinned LLM" inside a Safebox is a specific model version, with specific weights, running a specific prompt, inside an attested environment. Its output is near-deterministic: same code + same prompt = same verdict. Capability surface in one scan. U's o declarations enumerate every external capability. A module without o { Network.HTTP } cannot make HTTP calls — the compiler enforces this, and the LLM can trust that enforcement. Effect boundaries are declared. A function marked -E -D is proven pure and deterministic. The LLM treats it as a mathematical function — verify logic without considering state or timing. Template injection is structurally impossible. html… and sql… reject raw strings at compile time. The LLM doesn't audit for injection — the compiler makes it a type error. The LLM is the only probabilistic layer. Everything beneath it is deterministic. And the LLM's job is vastly easier because the structural noise has been eliminated by the compiler. 5. The attested analysis chain. U source code │ ▼ ┌─────────────────────────────────────────────────────────┐ │ SAFEBOX — attested environment │ │ │ │ 1. U compiler (deterministic, open source) │ │ → 11 structural categories eliminated │ │ → capability surface verified │ │ → .u.meta section emitted into the binary │ │ │ │ 2. Pinned LLM auditor (near-deterministic, attested) │ │ → logic bugs, intent verification, policy review │ │ → reads declared structure in O(1) per function │ │ │ │ 3. Signed verdict — reproducible by anyone │ └─────────────────────────────────────────────────────────┘ │ ▼ signed, reproducible verdict 6. Why this is more trustworthy than human auditors. Consistency. A pinned LLM produces the same verdict on the same code every time. Two human auditors do not. The same human on different days does not. Consistency makes errors testable and calibratable — inconsistency doesn't. Coverage. The LLM processes every function, every binding, every modifier. It doesn't tire, skip the boring parts, or assume a well-named function does what its name says. Uncorrelated failures. The LLM and the U compiler have different failure modes. The compiler doesn't hallucinate. The LLM doesn't miss logic bugs. Neither has the other's blind spots. 7. What this unlocks — by ripeness. Tier 1 — ready now Supply chain verification that actually works. A U package's capability surface is declared and compiler-verified. No o { Network.HTTP } = provably cannot phone home. The LLM checks logic for backdoors. The analysis is reproducible. Together they catch what neither catches alone — uncorrelated failure modes. LLM-generated code you can trust in production. LLM generates U → compiler catches 11 structural categories → second LLM reviews logic. Three independent checks, two deterministic. In Python, if the LLM writes a data race, the compiler has no idea. In U, it's a type error. Plugin marketplaces without trust. A plugin declaring o { Templates } and nothing else provably cannot access the network. The enforcement is at the language level, not the platform level. No sandbox to escape from — the capability isn't there. Tier 2 — one step away Automated compliance regulators accept. The attested chain runs on every commit. The verdict is reproducible by the regulator. "Was this code reviewed?" has a mechanical answer. Decentralized SaaS. Anyone spins up a Safebox, loads attested code, offers the service. Attestation proves they're running the genuine code. Users trust the chain, not the operator. What blockchain tried — trust the code, not the operator — but fast and private. Tier 3 — changes the landscape The oracle problem, solved properly. A Safebox oracle's U source proves it can only call the approved API and only return the approved type. Attested, compiler-proven, on-chain verifiable. Alignment via structure, not training. Don't align the model by surgery on its weights. Install the culture — workflows, policies, scope rules — as an inspectable layer in U. The substrate decides what the model can do. The model can want whatever it wants. 8. What U changes vs PHP/Node — layer by layer. The Safebox enforcement chain we built has 23 test phases and ~643 assertions. Every property is enforced at runtime. U moves the critical properties to compile time. The runtime checks become defence-in-depth. Scope: from runtime matcher to compiler proof. Today (Node) Scope.check() runs on every call. 71 assertions verify the matcher. Correct because we tested it — not because it's structurally impossible to be wrong. With U o { Network.HTTP } is the only import mechanism. Without it, the call doesn't exist in the binary. No runtime check. No bypass. Nothing to test. Sandbox: from sealed box to no box needed. Today (Node) Remove process/require/module from the worker global. BUG #71 found 4 escape routes via new Function("return this"). With U No eval, no Function constructor, no prototype chain. All 8 escape vectors are structurally impossible. The sandbox shrinks to memory/time enforcement. Protocol injection: from validation to type system. Today (Node) BUG #76: live CRLF email injection. BUG #74: credential leak via URL userinfo. Both runtime validation failures. With U Template tags: html…, sql…, smtp… reject raw strings at compile time. Injection is a type error. Provenance: from orchestrator injection to the type system. Today (Node) spec._provenance = {...} injected by the orchestrator. Enforcement at runtime via Scope.check. With U LLM output is type S. SMTP requires Templates.HTML. The only path between them is the template system. The type IS the provenance. Judgments: from "probably deterministic" to provably so. Today (Node) The deterministic gate is intended to be pure. Nothing proves it. A subtle Date.now() would break caching silently. With U -E -D on the gate function. The compiler proves it's deterministic. Adding Time.now() is a compile error. Caching is proven correct. 9. "Provably" is a different category of claim. Tests prove correctness against finitely many shapes. A compiler proves correctness against all possible inputs. That's not a better test. It's a different category of claim, the way a mathematical proof is a different category from an experiment. When the U compiler enforces o declarations, it doesn't check 71 URL shapes. It proves the call cannot exist — the function isn't in the compilation context. No URL of any shape, including shapes nobody imagined, can be constructed or passed. The 71 assertions become defence-in-depth. The primary evidence is a proof. What changes when you pull in source. DIFF ANALYSIS: module Invoice (v2.3.1 → v2.4.0) ADDED: o { Network.HTTP } ← NEW CAPABILITY CHANGED: f process_refund()+E(Email.SMTP) → f process_refund()+E(Email.SMTP, Network.HTTP) ← EFFECT WIDENED UNCHANGED: 47 functions, all -E -D ← still pure and deterministic The auditors vote on a fact, not on their reading of source. The LLM reasons about semantic implications — "why does a refund processor need HTTP?" — not about whether the code hides a fetch(). Compositional reasoning. In PHP, knowing function A is safe tells you nothing about B. In U, if A is -E -D and B is -E -D, their composition is -E -D — the compiler proves this transitively. Reason about 1,000 functions by reading 1,000 annotations, not 1,000 implementations. That's a sound shortcut. Compiled symbols carry the proof. A compiled U module's symbol table says: f send_invoice(invoice: Invoice, recipient: S)+E(Email.SMTP) ! InvoiceError Anyone reading that symbol knows what it can do, what it can't, and what can fail. The source is irrelevant to the safety claim. The claim is in the interface, proven by the compiler. Traditional closed source: "trust us." You can't verify. Traditional open source: "read it yourself." You won't. U: "the compiler proved what the code can do, and the proof is in the artifact." 10. .u.meta — the proof travels with the binary. Every binary the U compiler produces contains a .u.meta ELF section: a structured record of every class, function, modifier, error type, and the module's complete capability surface. Emitted by the compiler, covered by the binary's hash, readable by anyone with the binary and nothing else. Why embedded, not sidecar. A separate [truncated for AI cost control]