Block Engine 2.2.6: Design Notes, Runtime Boundaries, and Known Limitations

Block Engine is a Windows-oriented program that parses documents containing multiple language sections. It executes those sections sequentially and transfers selected serializable values between processes.

The project does not implement Python, JavaScript, Lua, PHP, or SQL. Those sections are passed to locally installed runtimes. Block provides the document parser, execution order, state serialization, process control, and error reporting around them.

This article describes the implementation in version 2.2.6. It focuses on the execution model, the changes made in this release, the security boundaries, and the limitations that remain.

Execution model

A Block document is divided into explicit language sections:

<py>
numbers = [1, 2, 3]
total = sum(numbers)
</py>

<js>
console.log("total:", total)
</js>

<json>
{
  "total": {{total}}
}
</json>

The engine performs these stages:

1. Parse the document and identify language boundaries.
2. Validate tags, imports, edition rules, paths, and configured limits.
3. Execute each stage using the corresponding local runtime.
4. Capture output and serializable state.
5. Make the resulting state available to the next stage.

The runtimes do not share memory directly. State crosses the process boundary through a serialized representation. Primitive values, arrays, and dictionaries are the intended interchange types. Open file handles, sockets, callbacks, and live database connections cannot be transferred.

This model makes the boundary visible, but it also makes the boundary real. A failure can belong to the Block parser, the process runner, the host runtime, or the user program inside that runtime.

The native Block layer

Block also contains a small native interpreter. It is separate from the embedded language sections and is used for orchestration logic.

The native layer currently supports variables, expressions, strings, numbers, booleans, lists, maps, conditions, loops, functions, return values, and basic collection operations.

total = 0

for value in range(1, 6):
    total = total + value
block

if total > 10:
    print("result:", total)
else:
    print("result is small")
block

Compound statements use an explicit block terminator. Indentation is for readability; it is not the scope mechanism.

This is enough for control flow around a pipeline, but it is not intended to reproduce the full syntax or standard library of another programming language.

What changed in 2.2.6

Version 2.2.6 is primarily a stability and security release.

Project discovery and relative imports were changed so that a script can be started from outside its project directory while retaining the project and sandbox boundaries. Imported files are checked for:

• Allowed Block source extensions
• Project or configured sandbox membership
• Reparse-point escapes
• Circular imports
• Maximum import depth
• Maximum imported file count
• Aggregate size limits

Process timeout handling was changed to wait on the actual child process and to terminate the process tree when the limit is exceeded. This is important for interpreters that create child processes of their own.

The no-argument CLI path is now bounded. It displays an introduction and help information instead of entering an unbounded startup animation. Console cursor and color state are restored when startup encounters an exception or an unsupported console.

Configuration, project manifests, custom-runtime definitions, and runtime state now have size limits. Writes use a safer replacement sequence and preserve the previous valid file when replacement is interrupted or unavailable.

Installer and supply-chain boundaries

The 2.2.6 installer is a verified bootstrapper for the official GitHub release assets. It:

• Requires TLS 1.2 for GitHub communication
• Restricts download endpoints to the expected GitHub chain
• Checks the final response URI
• Enforces response and asset size limits
• Verifies SHA-256 values
• Rejects unsafe archive paths
• Installs files atomically

The installer does not automatically run Winget, Chocolatey, PowerShell download scripts, or another package manager. Optional runtimes must be installed from their official publishers and made available on PATH.

This choice has a practical consequence: installing Block does not mean that PHP, Ruby, Dart, R, or other optional runtimes are installed. The installer can report that a runtime is missing, but it does not silently modify the host environment.

The release includes checksums and GitHub build-provenance attestations. These provide evidence about artifact consistency and build origin. They do not replace an Authenticode publisher certificate, so an unsigned Windows executable may still receive a new-file reputation warning from Windows or a browser.

Error reporting

The engine uses structured diagnostics for many failures. Messages include an error code, an operation or context, a source location where available, and a repair hint.

Examples include:

• Mismatched or unclosed language tags
• Import paths outside the project boundary
• Circular imports
• Unknown language tags
• Disabled runtimes
• Missing host executables
• Invalid state output
• Runtime timeouts
• Oversized input or output

The distinction between a missing host runtime and a Block syntax error is intentional. Block can report the former, but it cannot provide the runtime or its packages.

What the release does not provide

2.2.6 does not include a general-purpose compiler, an independent virtual machine, or a large standard library. Most language blocks still depend on tools installed on the host operating system.

It also does not include the earlier third-party package marketplace or automatic package installation. Those parts were removed because a package system needs a separate trust model: publisher identity, immutable versioned artifacts, dependency rules, review policy, and a defined installation boundary.

There is no claim here that arbitrary Block files are safe to execute. A language block can invoke a local interpreter, compiler, shell, or other executable. Users should review source files and dependencies before running them.

Verification

The v2.2.6 release workflow builds the Windows artifacts in a clean runner and runs the engine, CLI, path, native-language, server, security, repository-integrity, and release-verification tests.

The tests verify the behavior covered by the repository. They do not prove that every installed version of every external runtime behaves identically, and they do not replace review of the Block program being executed.

Current position

Block is best understood as a native orchestration language with polyglot execution support.

Its own language layer defines document structure and a limited control-flow vocabulary. The embedded sections retain the syntax and capabilities of their respective runtimes. The main design question is therefore not whether Block replaces each language, but whether a visible, bounded process and state boundary is useful for a given workflow.

The source code, tests, release artifacts, and version history are available in the Block_lang repository. The published v2.2.6 files are listed in the GitHub release.