Switching To Non-Deterministic Mode

When requesting a non-deterministic execution, a new sub-VM is created. Which of the three modes below applies is fixed for the whole execution: a node runs as leader when it computes the non-deterministic result itself, and as validator or in sync mode when it is handed one.

Leader Mode

Returns the Result Kinds produced by the sub-VM, with one change before it is published and before it enters the execution hash: a VMError’s " # <detail>" suffix is stripped. The non-deterministic result channel carries bare codes only, so what the leader publishes is exactly what an honest validator accepts under Validity Of A Proposed Result.

The leader does not apply that acceptance check to its own result. Doing so could only rewrite an honest result into the Derived-Outcome Namespace, which every validator would replace again — an execution-hash mismatch between two honest nodes.

Sync Mode

The proposed result is accepted or replaced per Validity Of A Proposed Result and returned. There is no vote to cast, so the resulting Result Kinds is simply the call’s result.

Validator Mode

An accepted proposal is handed to the sub-VM for comparison. That sub-VM must Return a bool value: whether the validator accepts the leader’s result. Any other result has the same effect as producing bool(false)

A rejected proposal records a disagreement without running the comparison stage. The contract cannot vote away bytes that no honest leader could have produced

Returns the accepted or replaced result.

Fees

The accepted or replaced result is charged on its own length, not on the length of the proposed bytes: rejected bytes never enter the result or the execution hash.