perf(precompiles): characterize BLS12-381 G1 MSM hotspots

[peter941221]

Background

Nethermind already has a dedicated accelerated path for the Prague-era BLS12-381 G1 MSM precompile.

Relevant code:
src/Nethermind/Nethermind.Evm.Precompiles/zkevm/Bls12381G1MsmPrecompile.cs:22-24
chooses Mul(...) for a single item and Msm(...) for multiple items.

src/Nethermind/Nethermind.Evm.Precompiles/zkevm/Bls12381G1MsmPrecompile.cs:61
calls Accelerators.Bls12381G1Msm(decoded, (nuint)pairCount, output).

src/Nethermind/Nethermind.Precompiles.Benchmark/Bls12381G1MsmBenchmark.cs:9-13
already provides a dedicated benchmark entrypoint for this precompile.

Problem

The current accelerated path does not make it obvious where end-to-end time is actually spent.

The Msm(...) path has three distinct stages:

1. input decode and layout rewrite into the trimmed internal representation
2. Accelerators.Bls12381G1Msm(...)
3. output re-encoding into the EVM return shape

Relevant code:
src/Nethermind/Nethermind.Evm.Precompiles/zkevm/Bls12381G1MsmPrecompile.cs:54-63
src/Nethermind/Nethermind.Evm.Precompiles/zkevm/Bls12381G1MsmPrecompile.cs:84-103
src/Nethermind/Nethermind.Evm.Precompiles/zkevm/Bls12381G1MsmPrecompile.cs:107-115
src/Nethermind/Nethermind.Evm.Precompiles/Eip2537.zkevm.cs:61-69
src/Nethermind/Nethermind.Evm.Precompiles/Eip2537.zkevm.cs:14-18

Without stage-level attribution it is hard to tell whether the next optimization should target:

• decode and buffer preparation
• the accelerator boundary itself
• some batch-size threshold effect between the two

Why this matters

src/Nethermind/Nethermind.Evm.Test/Eip2537Tests.cs:87-98
verifies the G1 MSM precompile is enabled after Prague.

src/Nethermind/Nethermind.Evm.Test/Bls12381G1MsmPrecompileTests.cs:10-19
shows there is already dedicated vector-based coverage for this path.

There is also precedent for performance work in this area:

• 76801d5915 optimisations and cleanup concurrent g1 msm
• 5e87830335 start implementing concurrent decoding for msm
• 9b16f46e01 finish concurrent msm decoding

Desired outcome

Extend the existing benchmark coverage around Bls12381G1MsmBenchmark so that we can measure:

• full precompile runtime
• decode and layout cost
• accelerator compute cost
• encode cost

The useful result here would be a repeatable breakdown across representative pairCount sizes, so the next optimization can target the actual hotspot instead of guessing.

[peter941221]

I took a first pass at the benchmark split for this.

Current state:
I added stage-level benchmark entry points for decode/layout, accelerator compute, encode, plus the existing end-to-end baseline around Bls12381G1MsmBenchmark.

What worked:
the benchmark project builds when EnableZkEvm=true is propagated, and BenchmarkDotNet discovers the G1 MSM cases correctly.

What is still blocked:
the benchmark child process fails when it reaches the accelerated path with DllNotFoundException for "__Internal", so the generated reports are NA rather than usable timings.

Before I turn this into a PR, which direction would you prefer?

1. I can open a draft PR with the benchmark surface and instrumentation changes first, even though the default BenchmarkDotNet process model still cannot collect valid numbers for the accelerated path.
2. I can hold the PR and first solve the host/runtime side so the PR includes actual stage-level measurements.

If there is already a known host model for running the zkevm accelerator path in benchmarks, I can target that next.

[peter941221]

I dug through the host/runtime side before opening a PR for this.

I can make EnableZkEvm=true select the accelerated precompile path in the benchmark project, and the benchmark entrypoints themselves are straightforward. The blocker is the host model behind Accelerators.Bls12381G1Msm(...).

What I verified:

1. The Nethermind benchmark really reaches the zkevm accelerator path.
   src/Nethermind/Directory.Build.targets:5-16 switches to zkevm/ sources when EnableZkEvm=true.
   src/Nethermind/Nethermind.Precompiles.Benchmark/PrecompileBenchmarkBase.cs:87-96 calls the real precompile Run(...).
   src/Nethermind/Nethermind.Evm.Precompiles/zkevm/Bls12381G1MsmPrecompile.cs:61,78 calls Accelerators.Bls12381G1Msm(...).
   src/Nethermind/Nethermind.Benchmark.Runner/Program.cs:24-27,67-81 still uses the normal BenchmarkDotNet process model, not a special zkvm host.

2. Nethermind.Zkvm.Abstractions is only the binding layer.
   Public repo: https://github.com/NethermindEth/zkvm-abstractions
   src/Accelerators.bindings.cs uses LibraryImport("__Internal") for the accelerator calls.
   The local NuGet package for Nethermind.Zkvm.Abstractions 1.0.0-preview.2 only contains the managed assembly and XML docs. I did not find host runtime assets such as win-x64/*.dll, linux-x64/*.so, or osx-*.dylib.

3. I found the public provider side, but it targets the Zisk guest toolchain, not an ordinary desktop/server process.
   Public repo: https://github.com/NethermindEth/bflat-libziskos
   README: libziskos for RISC-V 64-bit
   README: Static library builds ... suitable for Nethermind's bflat compiler
   README lines 11-16 set the target to RISC-V 64-bit, Target OS: zkvm, Vendor: zisk.
   src/runtime/Nethermind.ZiskOS.Runtime.csproj:23-31 only packs runtimes/linux-riscv64/native/libziskos.a and libziskos.bflat.manifest.
   The public release assets I checked are libziskos.a, libziskos.bflat.manifest, and the bindings/runtime packages. I did not find ordinary-host dynamic libraries there either.

4. Nethereum's public Zisk writeup describes the same model in plain terms.
   https://raw.githubusercontent.com/Nethereum/Nethereum/master/zisk/README.md
   Lines 288-333 say that [DllImport("__Internal")] resolves symbols statically from linked .a files and does not use runtime dynamic loading.
   That same section describes the call chain as C# -> NativeAOT P/Invoke thunk -> statically-linked symbol in libziskos.a -> CSR instruction(s) -> prover intercept.

5. I also checked whether __Internal is absolutely unworkable in a normal .NET host.
   It is not. A custom NativeLibrary.SetDllImportResolver(...) shim can intercept __Internal in a regular process.
   That means a compatibility layer is theoretically possible.
   I have not found a public, ready provider that already implements that path for BenchmarkDotNet.

So the current state looks like this:

Within the public repos, packages, and release assets I could verify, I do not see an existing ordinary-host runtime path for the zkvm accelerators. The current public design points at NativeAOT + static libziskos.a + RISC-V/Zisk guest, not at a normal BenchmarkDotNet child process loading a native library at runtime.

That leaves me with two very different follow-ups:

A. I open a draft PR with the benchmark surface changes only, knowing that the default host still reports NA for the accelerated stage.
B. I treat this as a new feature track and build a dedicated ordinary-host compatibility layer or shim before opening the benchmark PR.

Which direction do you want for #11802?

If there is already an internal or unpublished host model for running the accelerator path in ordinary benchmarks, point me at it and I will continue from there.