dylan-sutton-chavez/edge-python is a Rust engine that compiles a language subset straight to SSA bytecode and runs it on a register VM with exact memory metering, aimed at professionals building sandboxed, grant-scoped runtimes.
| Tool | dylan-sutton-chavez/edge-python — an engine for building language runtimes in Rust, with a single-pass SSA compiler and a metered register VM |
| Category | Compiler / virtual machine / WebAssembly runtime toolkit |
| Primary Use | Building small domain-specific runtimes and sandboxes whose programs reach no file, network or environment except what edge.json grants |
| Safe Use | For authorized professionals building sandboxed execution environments, language research, fuzzing targets, and safe plugin systems in labs and production defensive engineering |
| Telemetry Note | As an engine rather than an offensive tool, it leaves ordinary host-side artifacts: the metering allocator's byte and op counts, snapshot blobs, and whatever logging the embedding host wires in |
dylan-sutton-chavez/edge-python, repo name aside, presents itself in its README as Edge Lang — not a single language but the engine a language runtime would otherwise have to build for itself. The repository's root crate, edge, bundles the lexer, the parser, the virtual machine and the WebAssembly exports, and everything around it — lib/, cli/, js/, plugin/, abi/, fuzz/ — exists to help a developer compose a complete runtime and its tooling from importable kits. The repo is written in Rust, sits at 265 stars, and carries a dense topic list (ssa, nan-boxing, inline-caching, garbage-collector, no-std, sandbox, wasm) that reads like a design brief for the whole project.
The compiler pipeline is the most distinctive part of the architecture. A state-machine lexer driven by byte-class tables reads source through a token table the embedding runtime itself defines, and a single-pass Pratt parser consumes those tokens with no intermediate AST at all — SSA bytecode is emitted directly as the parse proceeds, with diagnostics reported alongside recovery. The practical consequence is worth dwelling on: there is no tree to allocate, traverse, or garbage-collect, which removes an entire class of memory pressure and compile-time overhead that conventional multi-stage front ends pay for. Runtimes with their own surface syntax can skip the parser entirely and feed the same bytecode through a Builder API, so the SSA layer is a stable contract between front ends and execution.
Execution happens on a register VM rather than a classic stack machine. The README describes bytecode lowering to register code with NaN-boxed values — the trick of packing tagged pointers and immediates into the payload bits of a quiet NaN — plus inline caches to keep property-style accesses fast. Calls that execute frequently are promoted into jumps into a section of the caller's code, an inlining-ish strategy that collapses call overhead without a JIT, and recursion keeps its levels on a single stack instead of opening frames per level. For a sandbox that must run untrusted code without ever generating machine instructions, that design point is the whole ball game: you get some of the flattening benefits of JIT compilation while staying a pure interpreter.
Resource control is handled by an exact memory meter: a metering allocator counts every byte a run holds against a configured limit, sitting beside an op budget and a mark-sweep GC. This is a hard guarantee, not an estimate — the README's word exact matters here, because fuzzers and sandbox evaluators care deeply about whether OOM accounting is advisory or precise. Combined with the no-std topic tag, the engine is clearly built to be embeddable in constrained hosts where allocation failure must be a clean, catchable engine event rather than a process-level abort.
The snapshot subsystem rounds out the runtime story: a parked run freezes to a sealed blob that can be restored later on the same host or a different one. That is a capability usually associated with checkpointing research VMs and live-migration infrastructures, and it opens interesting authorized-use angles — deterministic replay for debugging, shipping a warmed-up interpreter state as data, or moving long-running jobs between a browser host and a CLI host. The wasm export story means the same runtime module runs in browsers, in JavaScript runtimes via the js/ host, and natively through the native example binary that links the engine with no wasm boundary at all.
The security posture the README emphasizes most is capability scoping: a program reaches no file, network or environment unless its host grants it in edge.json. That is a grant-manifest model rather than ambient authority, and for defenders and platform engineers it is the kind of design that makes audit tractable — the edge.json file is the single place where a program's reach is enumerated. The examples/uptime runtime demonstrates the pattern: an uptime-check language whose checks read real status pages only under the grants of their own manifest, with a host module in cli/src/clock.rs reading the clock and the kit's net plugin wired in explicitly.
Building a runtime is, per the README, just a crate: a token table in syntax.rs, a handful of natives from lib in natives.rs, rules and engine answers in language.rs, error classes in names.rs, and the descriptor plus wasm exports in lib.rs. The quoted line counts are striking — 78, 23, 44, 57, 39 lines — meaning a complete domain-specific language with a CLI comes in under 300 lines of glue. make uptime produces cli/target/release/uptime, and the documentation walks every file. Two more runtimes ship in examples/: mini, the reference scripting language that edge.wasm and the edge CLI are built from, and tiny, a YAML-flow language over large data with its own front end and CLI.
The repository layout reads as a well-factored monorepo. lib/ holds optional natives, each module behind its own cargo feature, tested with plain-value native cases. cli/ is a kit of importable commands, each also feature-gated, and the edge binary is just one composition of that kit over mini. plugin/ and abi/ form the toolkit for writing .wasm plugins against the engine. data/ contains the same job written once in mini and once in tiny, with a test holding the two implementations to agreement — a genuinely unusual cross-runtime conformance harness. fuzz/ and bench/ carry the fuzzer and benchmark suites, and tools/spell translates the test corpus between token tables, which is a pragmatic answer to the problem that a multi-front-end engine's syntax cases are spelled in different runtime dialects.
For the security-engineering audience this blog serves, the obvious fit is sandbox research and safe plugin systems. The combination of a non-JIT interpreter, exact metering, capability manifests, and wasm confinement is close to a checklist for running untrusted logic safely — configuration DSLs, policy expression, extension scripting — where you want the guest language to be mathematically incapable of touching anything it was not handed. The sandbox topic tag confirms the author's intent, and the fuzzing tag plus a dedicated fuzz/ tree suggests the engine itself is being hardened continuously, which is what you want to see before embedding any interpreter in a trust boundary.
There are caveats a reviewer should note. The license field in the repo metadata is NOASSERTION, even though the README asserts Apache 2.0 across the tree — worth reconciling before commercial embedding. The tool's GitHub title mentions NaN-boxe (truncated, evidently NaN-boxing) and a Python subset framing, while the README centers Edge Lang generatively; the mismatch suggests the repo is evolving faster than its metadata. And the README contains a line inviting machine learning models to read skill/SKILL.md — an AI-assistance affordance, which we note as a curiosity of the project's documentation style rather than anything operational.
Licensing and sponsor trivia aside, what dylan-sutton-chavez/edge-python offers is a coherent, unusually disciplined take on embeddable language infrastructure: single-pass SSA compilation, a metered register VM with inline caches and NaN boxing, sealed snapshots, and a grants-only capability model. For authorized professionals designing safe execution substrates — or anyone who wants to study how a modern non-JIT engine is put together — it is a repository worth an afternoon of reading, and the book-style documentation that builds a runtime one piece at a time makes it approachable even if you never ship a runtime of your own.
dylan-sutton-chavez/edge-python.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.