V0.7.0

[davxy]

Protocol version 0.7.0 $^*$

CHANGELOG

(*) WARNING: DEVIATIONS

** Unreleased**

• Assign registers 9 and 10 to *f* and *l* in info host call gavofyork/graypaper#480 (since v0.6.7)

New TINY constant

• $G_T$ ( max per block gas ) for tiny spec fixed to 20_000_000 (ref Define D, G_T, G_R tiny spec params JamBrains/jam-docs#59)

---

• traces vectors
• STF vectors
• ASN.1 syntax update

[jaymansfield]

Did a quick check. All STF, safrole/fallback traces, storage light/full traces, and preimage light traces look okay. I'm seeing a gas difference in preimages/00000008. Will investigate later today.

[ascrivener]

All clear for everything except for preimages, failing ..008 with expected gas 117630, actual 113986. And possibly more preimage failures after 8, looking later

[davxy]

in..008 how many times you call the vm accumulate for service 0? And what packages you end up accumulating?

[jaymansfield]

All clear for everything except for preimages, failing ..008 with expected gas 117630, actual 113986. And possibly more preimage failures after 8, looking later

Same result with 113986.

Service 0 accumulates once with these work packages:
0x30106542a08638f4b03aa444a502e84c5d8c0af2f4e7d78dec6fcf20839ba96c
0x9e93aef22e437721ab38c1e6cde35faee26a67d04d00e3cd68d1b6e6509d12c8
0x59763c52ed98c413c82bdba8f8483dde3d1249bb8330f46cbf5b87b7297a45dc

[davxy]

Ok we call accumulate twice. Please stop investigating, I suppose we need to fix I need to check something here

[sourabhniyogi]

We match on all 0.7.0 traces except 2:

1. preimages/00000008.json [as reported by @jaymansfield and @ascrivener above] where we arrive at 113986 (not 117630) as the only difference
2. preimages/00000089.json where we differ on 0xff000000000000000000000000000000000000000000000000000000000000
   and I imagine its on our side

0.7.0 Traces: 

0x2f46b4ee8c502d0b9e66c78823b4959e22c101d9a3d1b82554b1912cc11f6eb5ffffffffffffffff0a000000000000000a000000000000008a96020000000000ffffffffffffffff77000000000000005900000000000000

0.7.0 Jamduna:   

0x2f46b4ee8c502d0b9e66c78823b4959e22c101d9a3d1b82554b1912cc11f6eb5ffffffffffffffff0a000000000000000a000000000000003996020000000000ffffffffffffffff75000000000000005900000000000000

A trace for 00000008 may help us all diagnose together. We'll study 00000089 closely in the next day.

We posted a 0.7.0 fuzzer target in case thats useful to get started on 0.7.0 this week

[0xjunha]

FastRoll passes all STF / traces except 2: preimages/00000008 & preimages/00000089

For 00000089 I got state diff for key 0xff000000000000000000000000000000000000000000000000000000000000 (exactly same result as @sourabhniyogi):

Traces:
2f46b4ee8c502d0b9e66c78823b4959e22c101d9a3d1b82554b1912cc11f6eb5ffffffffffffffff0a000000000000000a000000000000008a96020000000000ffffffffffffffff77000000000000005900000000000000

FastRoll:
2f46b4ee8c502d0b9e66c78823b4959e22c101d9a3d1b82554b1912cc11f6eb5ffffffffffffffff0a000000000000000a000000000000003996020000000000ffffffffffffffff75000000000000005900000000000000

This gives us ServiceInfo diffs when decoded:

Traces:
- octets_footprint: 169610
- items_footprint: 119

FastRoll (& Jamduna):
- octets_footprint: 169529 (Diff: -81)
- items_footprint: 117 (Diff: -2)

I believe this discrepancy comes from SOLICIT host call. In 00000089 I see SOLICIT does not create a new lookups manifest entry but only pushes a new timeslot value (2 timeslots -> 3 timeslots). I think we shouldn't update footprints in this case. If we add to footprints in this case, we get the test vector state value (given that octets & items footprint diffs are -81 & -2)

(The second case in the image below)

@davxy @jaymansfield @ascrivener

[sourabhniyogi]

I think we shouldn't update footprints in this case.

Agree with @0xjunha assessment on this!

[ascrivener]

+1, seems that polkajam erroneously updating total octets/items in that case would explain the discrepancy

[davxy]

TL;DR

I think the issue might be that GP sets G_T = 3_500_000_000, whereas for the tiny configuration we use just 20_000_000.

Why the difference? Mainly to make things more interesting for fuzzy/testing :-)
Otherwise, certain conditions never are more difficult to trigger, and we want to test those scenarios.
(similarly to how we lowered $D$ to 32 for tiny )

I thought this was already documented, but I’ll make sure to add it to the tiny spec and include it in the test vectors documentation.

Are you fine with this value?

Analysis

In step 00000008 we end up with three reports to accumulate:

w1 = 0x30106542a08638f4b03aa444a502e84c5d8c0af2f4e7d78dec6fcf20839ba96c
w2 = 0x9e93aef22e437721ab38c1e6cde35faee26a67d04d00e3cd68d1b6e6509d12c8
w3 = 0x59763c52ed98c413c82bdba8f8483dde3d1249bb8330f46cbf5b87b7297a45dc

I think there is a misunderstanding about how many times service 0 calls into accumulate.

IIUC you call into accumulate just once with all the reports in one shot.

However, this approach does not account for the fact that each call to
accumulate must be limited by the maximum allowed gas per block
(as per 12.21 and 12.16).

In our case we have:

• $G_A = 10000000$ (max_accumulate_gas_per_core)
• $C = 2$ (cores)
• $G_T = 20000000$ (total gas for all accumulations)

Thus, given 12.21 we have that the max gas that can be used is 20_000_000.

All the three reports have a gas for accumulate set to 10_000_000.

• w1 has 4 work items with 2_500_000 gas each
• w2 has 4 work items with 2_500_000 gas each
• w3 has 2 work items with 5_000_000 gas each

Given that w1_gas + w2_gas hits the max accumulate gas we first call accumulate for w1 and w2 (i.e. $\Delta^*$) as prescribed by $\Delta^{+}$ (12.16).
When $\Delta^*$ returns, we compute the effective gas consumed, we subtract it from $g$ and we call into $\Delta^{+}$ again for w3.
The effective gas consumed by w1+w2 is 91_982. So, since the gas required by w3 + 91_982 <= 20_000_000 we accumulate w3 as well.

In the end the service 0 calls into accumulate twice and not once.
One time for w1+w2 and one for w3

[davxy]

I'll have a look at 00000089 tomorrow :-)

[ascrivener]

8 works for me now after setting G_T = 20M.

related, https://docs.jamcha.in/basics/chain-spec/tiny I think also the documentation should have D = 32 for tiny?

[davxy]

related, https://docs.jamcha.in/basics/chain-spec/tiny I think also the documentation should have D = 32 for tiny?

Yes, I'm editing it :-)

JamBrains/jam-docs#59

[clearloop]

Can confirm G_T=20M works for 8 in SpaceJam, for 89, got the same value as others

[davxy]

@0xjunha @ascrivener @sourabhniyogi @jaymansfield @clearloop 000000089 has been fixed

[clearloop]

SpaceJam now passes all at 536eb7c

[ascrivener]

jamzilla passes all, published 0.7.0 binaries at https://github.com/ascrivener/jamzilla-conformance-releases/releases/tag/v0.7.0.0

[jaymansfield]

JavaJAM now passes all.

[dakk]

I'm passing all the traces expect for preimages/00000095.json and preimages/00000099.json, where I have a discrepancy of 10 gas unit in the service accumulate_gas_used statistics (I have 10 less). I'm still trying to figure what the issue could be

[0xjunha]

FastRoll passes all as well :)

[sourabhniyogi]

Jamduna passes all traces (including the 2 [00000008 + 00000089]). We needed to actually fix a slice input that we didn't ever test until this 00008.json new case -- we would appreciate a new fuzzing wave in 0.7.0 to harden our outeraccumulate!

Our new fuzz target is v0.7.0.1