SpaceJam

[clearloop]

SpaceJam Fuzzing

release	date	description
all	.	The releases page of spacejam binaries
0.6.7	2025-08-13	the latest spacejam release matched v0.6.7

for shortcut of downloading the latest spacejam binary (2025-08-13)

curl -fsSL https://sh.spacejam.dev | sh

Usage

# running a fuzz target
spacejam fuzz target -v 

# running a fuzzer
spacejam fuzz fuzzer -t jam-test-vectors/traces/storage -v

# running a single trace
spacejam fuzz tx trace.json -v

Note that RUST_LOG is available, feel free to request new logs for spacejam which helps debugging !

Known Issues

• invocations out of storage and preimages are not tested

[clearloop]

sorry for breaking in #11! I was testing our fuzzer format with duna's target and tried their reports then commented on the issue unconsciously, I'm trying others' reports since I want to confirm if our binary is ready enough first

for the current status, we are still working on fixing the traces in other teams' reports

• Guarantee signature verification failed spacejamapp/specjam#11
• Empty pending reports spacejamapp/specjam#12
• Privileges mismatched spacejamapp/specjam#13
• Incorrect order of next validators spacejamapp/specjam#14

[davxy]

sorry for breaking in #11 (comment)! I was testing our fuzzer format with duna's target and tried their reports then commented on the issue unconsciously, I'm trying others' reports since I want to confirm if our binary is ready enough first

No problem

I tried running your target and encountered a failure on your side, apparently related to the order of the assurances, which should be sorted by val index.

❯ ./spacejam fuzz target -vvv
2025-08-13 13:03:12  INFO spacejam::fuzz::target: Listening on "/tmp/jam_target.sock"
2025-08-13 13:03:18 DEBUG  read: spacejam::fuzz: message(length): Info
2025-08-13 13:03:18 DEBUG write: spacejam::fuzz: message(16): Info
2025-08-13 13:03:18 DEBUG  read: spacejam::fuzz: message(length): SetState(len=21)
2025-08-13 13:03:18 DEBUG write: spacejam::fuzz: message(33): StateRoot(0xc2d2a5bf305862ae66218e62bf8d1398388850b95bf62b0c9d30269583399dec)
2025-08-13 13:03:18 DEBUG  read: spacejam::fuzz: message(length): ImportBlock(slot=1, hash=0x8a2c121136c29f2bf588a9f29aad83ba0fb3f64f5e8475e933617bb8591875b7)
2025-08-13 13:03:18 DEBUG write: spacejam::fuzz: message(33): StateRoot(0x5692d3a3929e0e8390e80dcfa838e95f26f72b7f4accd65fa57c1ed6a1e7a9cb)
2025-08-13 13:03:18 DEBUG  read: spacejam::fuzz: message(length): ImportBlock(slot=2, hash=0x3f3fd732f6ba3bee0f533fc13575a0071ed14685bcaa6c18dc9cb65c2e0be050)
2025-08-13 13:03:18 ERROR spacejam::cmd: NotSortedOrUniqueAssurers

As a side note, if the block you receive is invalid - which is not the case for 0x3f3fd732f6ba3bee0f533fc13575a0071ed14685bcaa6c18dc9cb65c2e0be050
but could happen if the fuzzer intentionally sends an incorrect mutation to check behavior - you should
not terminate the target. Instead, simply send back the state root for the last correcly importe block and wait for the next block (which should have the same parent of the incorrect one).

Here is the trace for you to reproduce: https://github.com/davxy/jam-conformance/tree/main/fuzz-reports/spacejam/1755083543

Edit: If the block is invalid, send back the state root for the last correcly imported block and wait for the next (I added a note about this here:
https://github.com/davxy/jam-conformance/tree/main/fuzz-proto#message-flow)

[clearloop]

We just released SpaceJam 0.6.7-pre.2 with fixes

curl -fsSL https://sh.spacejam.dev | sh

Failed archive tests

1. Privileges mismatched, host call bless from 1754988078/00000010

...

DEBUG program: Decoded instruction: Bless { manager: 0, assign: 0, designate: 324788131, auto_acc: [] } target="boot"

...

ERROR keyval mismatch: Privileges: 0x0c000000000000000000000000000000000000000000000000000000000000
DEBUG polkajam: Privileges { bless: 0, designate: 0, assign: [0, 324788131], always_acc: {} }
DEBUG spacejam: Privileges { bless: 0, designate: 324788131, assign: [0, 0], always_acc: {} }

...

SpaceJam correctly applied the decoded bess instruction however the result in polkajam got some offset

2. Guarantee signature verification failed from 1754725568/00000003

The report is at the same slot as the block, however using current validators from pre-state can not verify the guarantee signatures

[davxy]

I tried to fuzz your target and at some point It logs this:

❯ ./run_target.sh spacejam
Run spacejam on targets/spacejam/0.6.7-pre.2
2025-08-14 16:43:43  INFO Listening on "/tmp/jam_target.sock"
Waiting for target termination (pid=292766)
2025-08-14 16:43:47  INFO No more bytes from the stream(failed to fill whole buffer)! average transit time for 2 blocks: 42ms
2025-08-14 16:47:16  WARN failed to process message: DependencyMissing, waiting for the next message ...
2025-08-14 16:47:20  INFO No more bytes from the stream(failed to fill whole buffer)! average transit time for 13 blocks: 65ms

But it doesn't send back the last successfully imported block state root.

I added this note here: https://github.com/davxy/jam-conformance/tree/main/fuzz-proto#message-flow

---

FYI I created the NEWS page. Please keep an eye on it

[clearloop]

thanks! it is caused by failing on importing blocks, SpaceJam got into stale state and trying to wait for the next message, will get it fixed tmr, I believe with the trace flag it will log everything

RUST_LOG=trace ./run_target.sh spacejam

btw if it is possible sharing some insights on my two failing archive tests, for 1. I have been stuck in it for two days, a PVM trace would be super helpful!

[davxy]

New report for you: https://github.com/davxy/jam-conformance/tree/main/fuzz-reports/spacejam/1755183715

so if failing on importing blocks, shall I return the state root anyway?

Yes. Always return the state root of the last successfully imported block. Some blocks will be intentionally invalid; in those cases, returning the previous state root implicitly signals that the block was not imported, and you then wait for the next block. In short, the protocol is the same as for a successful import, except you return the previous state root instead of a new one.

btw if it is possible sharing some insights on my #13 (comment), for 1. I have been stuck in it for two days, a PVM trace will be super helpful!

I'll have a look

[clearloop]

Just released SpaceJam-v0.0.3 at spacejamapp/specjam@0.6.7-pre.3

• now can pass all archive tests except 1754982087_00000005
• the state root response of failure block importing is fixed

according to NEWs will keep our implementation up to date from the repo updates

[clearloop]

hi @davxy, we just released SpaceJam-v0.0.4 at spacejamapp/specjam@0.6.7-pre.4, the crash is now fixed ...

we can now pass all traces except two that I think they are not compatible with other traces

Test	Reason
1754982087	this test should get retired because it's not using compact encoding for generating service ids, if align our id generator to this test, at least 2 other traces will get broken
1755530300	I propose to delay the accumulate root integration to 0.7.0, because if we support this, all other traces including the test vectors will get broken

also, I noticed tests related to host call new require parent services getting acc_gas charged by the input acc_gas for the newly created service, if I'm not mistaken, this is currently an undefined behavior in GP

[clearloop]

just released spacejamapp/specjam@0.6.7-pre.5 which removed the extra gas charging raised by pvm tests

[clearloop]

SpaceJam binaries for 0.7.0 spacejamapp/specjam@0.7.0

[clearloop]

hi @davxy , just made some optimizations for the performance! see spacejamapp/specjam@0.7.0-pre.1

please do without -vv ^ ^