GP v0.6.7

[davxy]

✅ Please report your success/issues here

---

Protocol version 0.6.7 $^*$

CHANGELOG

(*) WARNING: DEVIATIONS

Changes from version 0.7.0 that have already been incorporated

• Fixed-length validator index serialization for guarantees and preimages extrinsics gavofyork/graypaper#440 (since the beginning)
• PVM Invocations: Tweak chain params gavofyork/graypaper#414 (since v0.6.6)
• PVM Invocations: swap HUH and CORE condition checks in assign hostcall gavofyork/graypaper#433

** Unreleased**

• Assign registers 9 and 10 to *f* and *l* in info host call gavofyork/graypaper#480

[jaymansfield]

Thanks for these.

1. In the json, can these fields be renamed to use an underscore rather then a dash/hyphen for consistency with other elements: deposit-offset, creation-slot, last-accumulation-slot, parent-service

EDIT: Removed second question, figured it out.

---

So far all stf, safrole traces and fallback traces pass for me.

I get a different gas used amount in reports-l0/00000002 but other fields are matching.

[davxy]

1. In the json, can these fields be renamed to use an underscore rather then a dash/hyphen for consistency with other elements: deposit-offset, creation-slot, last-accumulation-slot, parent-service

to what json you refer to?

EDIT: Removed second question, figured it out.

well, the second service code preimage fails to load but perhaps we need to update the accumulate slot anyway? So maybe you were right. I need to check the gp

[jaymansfield]

1. In the json, can these fields be renamed to use an underscore rather then a dash/hyphen for consistency with other elements: deposit-offset, creation-slot, last-accumulation-slot, parent-service

to what json you refer to?

EDIT: Removed second question, figured it out.

well, the second service code preimage fails to load but perhaps we need to update the accumulate slot anyway? So maybe you were right. I need to check the gp

The service accounts. For example stf/accumulate/tiny/accumulate_ready_queued_reports-1.json:

"service": {
"code_hash": "0x24cfba622fa847e2d8c4ead22dfac3e46a71eafde5998a642092536d0e7f3648",
"balance": 141733,
"min_item_gas": 10,
"min_memo_gas": 10,
"bytes": 41666,
"deposit-offset": 0,
"items": 3,
"creation-slot": 0,
"last-accumulation-slot": 43,
"parent-service": 0
},

Old attributes are named like "min_item_gas", "min_memo_gas". New ones use a dash instead: "deposit-offset", "creation-slot". Just mentioning for consistency in naming.

[davxy]

Old attributes are named like "min_item_gas", "min_memo_gas". New ones use a dash instead: "deposit-offset", "creation-slot". Just mentioning for consistency in naming.

Ok

Regarding the accum slot, you were right. We need to update both services last slot. I'll fix it

[sourabhniyogi]

For traces, we are passing fallback + safrole but are dying early on reports-l0/00000002 and reports-l1/00000002 -- can you paste the pvm traces for one or both?

[davxy]

@sourabhniyogi I’ve provided the light variant of the traces related to the reports:

• Normal = up to 6 work items per package
• Light = 1 work item per package max

Since I regenerated all the traces, some parts of the traces may have changed.
Could you please re-run them (starting with the light variant) and let me know if everything looks good now?
If not, just let me know which PVM trace you'd like me to provide you.

[jaymansfield]

A trace for any of these would be really useful as I'm still running into gas discrepancies and I'm assuming its probably the same issue causing my problem in each.

preimages_light/00000003 - Javajam: 14446. Polkajam: 14658
preimages/00000002 - Javajam: 14366. Polkajam: 14578
storage_light/00000003 - javajam: 63606. polkajam: 63818
storage/00000002 - javajam: 159667. polkajam: 159879

Everything else matches in the post states except gas.

Also just realized they all differ from the same amount somehow: 212.

[sourabhniyogi]

After fixing up the fetch protocol specs to be 0.7.0 (no idea why you would need to do this?), we got to the same observation as @jaymansfield .. that we have 212 less gas across the majority of accumulate state transitions for both storage+preimage, light or not.

Our summary is here which shows the 212 mismatch. Do you have a theory of what is going on at the last 212?

We will check what's going on with some statistics count mismatches here and what we may be missing for the > 212 mismatches.

Note that we had to loosen up our memory checks to get to this state and are ignoring it because we assume something will replace SBRK soonish.

[0xjunha]

Same issue here - FastRoll consumes 212 fewer gas units compared to the test vectors, across all test vectors that invoke accumulation. All other fields match.

[davxy]

@jaymansfield @sourabhniyogi @0xjunha

pvm traces for:

• preimages light 3: https://github.com/davxy/jam-stuff/tree/main/pvm-traces/0.6.7/preimages_light_00000003
• storage light 3: https://github.com/davxy/jam-stuff/tree/main/pvm-traces/0.6.7/storage_light_000000003

[jaymansfield]

Thanks @davxy.

2025-08-04 12:01:49 [T] [s=3] service Handling hostcall: log
2025-08-04 12:01:49 [I] [s=3] boot #0 Bootstrap Service Accumulate, 0h @3 $18446744073709551615

Can you confirm what "18446744073709551615" represents in that debug statement in preimages light? Mine is showing "0h @3 $0".

[davxy]

2025-08-04 12:01:49 [T] [s=3] service Handling hostcall: log
2025-08-04 12:01:49 [I] [s=3] boot #0 Bootstrap Service Accumulate, 0h @3 $18446744073709551615

Can you confirm what "18446744073709551615" represents in that debug statement in preimages light? Mine is showing "0h @3 $0".

@jaymansfield is the service 0 balance as returned by the info host call.
In particular the info returned using u64::MAX as service id (aka the current service).

This is the object that is returned encoded from the info hostcall

ServiceInfo { 
    code_hash: 0xd1f8c2ada30847fd..., 
    balance: 18446744073709551615, 
    threshold: 0, min_item_gas: 10, 
    min_memo_gas: 10, 
    bytes: 161253,
    items: 4, 
    deposit_offset: 18446744073709551615, 
    creation_slot: 0, 
    last_accumulation_slot: 0, 
    parent_service: 0 
}

[jaymansfield]

2025-08-04 12:01:49 [T] [s=3] service Handling hostcall: log
2025-08-04 12:01:49 [I] [s=3] boot #0 Bootstrap Service Accumulate, 0h @3 $18446744073709551615

Can you confirm what "18446744073709551615" represents in that debug statement in preimages light? Mine is showing "0h @3 $0".

@jaymansfield is the service 0 balance as returned by the info host call. In particular the info returned using u64::MAX as service id (aka the current service).

This is the object that is returned encoded from the info hostcall

ServiceInfo { 
    code_hash: 0xd1f8c2ada30847fd..., 
    balance: 18446744073709551615, 
    threshold: 0, min_item_gas: 10, 
    min_memo_gas: 10, 
    bytes: 161253,
    items: 4, 
    deposit_offset: 18446744073709551615, 
    creation_slot: 0, 
    last_accumulation_slot: 0, 
    parent_service: 0 
}

Service is matching already. Can you check to see which registers you are using for the info host call here:

I noticed if I set it to W9 & W10 the trace passes.

[davxy]

I noticed if I set it to W9 & W10 the trace passes.

Looks like you found something interesting.
Yeah we're using w9 and w10. That smells like a typo in the GP to me.
I'm not 100% sure, but is there any other instance where we skip registers to pass arguments?
I'm going to propose a fix to the GP anyway

Please use w9 and w10. With this change all the traces are passing?

[jaymansfield]

I noticed if I set it to W9 & W10 the trace passes.

Looks like you found something interesting. Yeah we're using w9 and w10. That smells like a typo in the GP to me. I'm not 100% sure, but is there any other instance where we skip registers to pass arguments? I'm going to propose a fix to the GP anyway

Please use w9 and w10. With this change all the traces are passing?

Yes all tests pass now for JavaJAM 😀

[davxy]

Looks like you found something interesting. Yeah we're using w9 and w10. That smells like a typo in the GP to me. I'm not 100% sure, but is there any other instance where we skip registers to pass arguments? I'm going to propose a fix to the GP anyway
Please use w9 and w10. With this change all the traces are passing?

Yes all tests pass now for JavaJAM 😀

@jaymansfield thank you for reporting this

So perhaps that was the issue for you as well? @sourabhniyogi @0xjunha

[0xjunha]

Looks like you found something interesting. Yeah we're using w9 and w10. That smells like a typo in the GP to me. I'm not 100% sure, but is there any other instance where we skip registers to pass arguments? I'm going to propose a fix to the GP anyway
Please use w9 and w10. With this change all the traces are passing?

Yes all tests pass now for JavaJAM 😀

@jaymansfield thank you for reporting this

So perhaps that was the issue for you as well? @sourabhniyogi @0xjunha

Yes, with w9 & w10 for INFO hostcall f & l FastRoll passes all as well. Thanks @davxy @jaymansfield 😀

[davxy]

FYI : gavofyork/graypaper#480

[sourabhniyogi]

So perhaps that was the issue for you as well? @sourabhniyogi @0xjunha

We have passed storage-light with the info w9/10 "fix" and are working through preimages-light now. Because @jaymansfield and @0xjunha have support, all issues are almost certainly on our side, so we would like 0.7.0 vectors in the v0.7.0 branch so other teams who got through 0.6.6 can "skip" to that this week?

Will confirm when we're 100% done

[arjanz]

PyJAMaz passes all STF en traces tests, with help of comments above 😄

[mkchungs]

JamDuna also passes all v0.6.7 STF trace tests. {preimages_light, preimages, storage_light, storage} -- all passing now.

[qiweiii]

Boka passes all as well

[ascrivener]

Jamzilla passes as well

[danicuki]

@jamixir passing all 0.6.7 traces

[sierkov]

@davxy Could your share PVM traces for the following test cases?

• preimages/00000070
• preimages/00000091
• preimages/00000092

All 0.6.7 conformance tests are currently passing except for these three, where only minor gas consumption discrepancies are observed: 6, 3, and 3 units respectively.