Skip to content
LogoLogo

Module Exports

Everything below is exported from src/root.zig, i.e. available as @import("guillotine_mini").<name>.

Types

ExportKindNotes
Evmfn (comptime EvmConfig) typethe EVM type constructor — see Evm
EvmConfigstructcomptime configuration — see EvmConfig
OpcodeOverridestruct{ opcode: u8, handler: *const anyopaque }
PrecompileOverridestructcustom precompile registration
PrecompileOutputstruct{ output, gas_used, success }
Framefn (comptime EvmConfig) typeone call frame: stack, memory, PC, gas
HostInterfacestructpluggable state backend — see host guide
BlockContextstructchain id, block number/timestamp, coinbase, fees, block hashes
StorageKey, StorageSlotKeystructmap keys for storage
Addressstruct20-byte address (from Voltaire), fromHex, .bytes
ZERO_ADDRESSconstthe zero address
HardforkenumFrontier…Osaka, DEFAULT == PRAGUE
ForkTransitionstructblock/timestamp-based fork switch
Logstructvoltaire.logs.Log{ address, topics, data }
SelfDestructRecordstructone SELFDESTRUCT observation
StorageAccessstructone storage touch, for access reporting
TraceStep, ExecutionTracestructstructured trace attached to CallResult
Tracer, TraceEntrystructEIP-3155 capture — see tracing
CallErrorerror setsee Errors
Dispatcherstructinstruction dispatch table

CallParams and CallResult are not top-level types: they are members of the EVM type you construct, because they depend on its config. Reach them as Evm.CallParams / Evm.CallResult. See CallParams / CallResult.

Functions

ExportSignatureNotes
getOpNamefn (u8) []const u8opcode mnemonic, e.g. 0x01"ADD"

Namespaces

The submodules are exported too, for when you need something not re-exported at the top level: evm, frame, host, evm_config, call_params, call_result, errors, trace, opcode, dispatcher.

const guillotine = @import("guillotine_mini");
 
const Evm = guillotine.Evm(guillotine.EvmConfig{});
const MyFrame = guillotine.Frame(guillotine.EvmConfig{});
 
// namespace access
const StorageKey = guillotine.evm.StorageKey;

Versioning

The package is 0.1.0 and pre-1.0: any of the above can change in a minor release. The most likely churn is the opcode-override handler signature (currently type-erased for exactly this reason) and the async callOrContinue surface.