A Neander program is guaranteed to stop, as we saw ). The meta block of the Reference Response contains the runtime's budget configuration.
It is worth stressing that the budget system is an integral part of the language definition, not merely a bolted-on feature of one particular runtime implementation.
What is runtime-specific are the details of how and in what amount these upper bounds are assigned to a submitted program. The Grotto reference implementation, for example, currently requires a static budget configuration at startup time and applies it to every program submission.
What is normative, however, is the consequence of exceeding one. Either way the program produces a Failure result, but the two kinds of bound fail differently. Overrunning a static cap is a Flaw: the program is rejected outright, before execution. Overspending a budget is an Abort: execution stops immediately. There is exactly one exception to this rule, and we will get to it in a minute.
Computation
Computation is measured in Thalers, Neander's unit of computational work, named after an . It protects against stack overflows during parsing, type checking, and execution, which is a separate attack vector independent of program size: a short program can nest very deeply.
Repeat
Repeat is a unitless positive integer and caps the limit literal that every repeat loop must declare. There are two separate limits at play here, and it is important to distinguish between them. The first is part of the repeat syntax itself and acts as a runtime precondition on the actual repeat count:
repeat pageCount limit 20 as i {
call orders.list(offset: i * 100, limit: 100)
}
If pageCount turned out to be larger than 20 during execution, then a runtime error would prevent the loop from even starting. This construct gives an agent the opportunity to express an expectation and ensure that the loop does not execute if the expectation is not met.
The budget-system repeat limit, on the other hand, is an absolute ceiling on the literal itself, checked at validation time. So limit 1000000000 is valid syntax and per se allowed, but it very likely exceeds the configured cap, and the program would never start running. This prevents an agent from circumventing the bound on loops by declaring an absurdly high number as the limit.
Grotto's take on budgets
Grotto implements a dispatcher-worker pattern where program submission is handled by a dispatcher running in the host thread and the program itself is handled by an isolated worker.
The dispatcher enforces the program size cap upon reception and the overall program execution duration cap by a timeout on the isolated worker followed by worker termination.
The worker does the rest. Parser and validator enforce depth and repeat limits, computation and memory budgets are checked cooperatively at every operation and allocation, and a timeout guards every in-thread API call.
Note the split. Thalers and memory can be counted cooperatively because the interpreter is doing the work and can be trusted to check as it goes. Duration cannot be left to the same mechanism: a program that stops coming back to a checkpoint stops checking its own clock. Grotto does sample the clock inside the worker too, but it does not rely on it. The deadline that actually binds sits on the dispatcher thread, which is a question of isolation rather than budgeting.
Next from the Grotto
That concludes the overview of the Neander budget system, and it ends with a brief visit to Grotto. Since we are here anyway, it makes sense to stay a while and take a closer look under the hood, to better understand how Grotto keeps its embedding host application isolated from the execution of untrusted code.
In the meantime, read the in your own app, and let me know what it cost you.
SOCIAL SHARE CARD GENERATOR