1757423271

[sierkov]

In this trace, I am observing a 1-unit discrepancy in accumulate_gas_used:

expected: 11929
actual: 11930

Only one service is being accumulated in this trace, and its code performs just three host calls (besides log): fetch 0, info, and fetch 14. Because of this, I suspect one of these calls is returning a non-conformant result. However, a code review against GP 0.7.0 did not reveal the cause.

Could anyone share the results of these host calls from your implementation for comparison?
Here are the results from mine:

fetch 0 result (134 bytes):

0A00000000000000010000000000000064000000000000000200200000000C000000809698000000000080F0FA020000000000CA9A3B00000000002D3101000000000800100008000300403800000300080006005000040080000500060000FA0000017CD20000093D0004000000000C00000204000000C0000080000000000C00000A000000

info result (96 bytes):

3F72B36F023E0A26BA5E3BB25DCCD8BC38055B9561F7CA61FECB0C957DE7E577FFFFFFFFFFFFFFFF00000000000000000A000000000000000A00000000000000857802000000000006000000FFFFFFFFFFFFFFFF000000000A00000000000000

fetch 14 result (434 bytes):

013D6F8B6B7DFD4A334D8C51B9006800AB17D61705E569765BAFC54FB0B8D6DD9E0000000000000000000000000000000000000000000000000000000000000000A33FD62C73AA99798665AACB88B9AAD62C82389E49B06838E6FBC2DD04FBD78C36B4ED136F79C2C1CBC40696CC99A1417B6A6695DF5689909D16426E96D15579AE9900812401160009333ADC619129BD8CDAE03B04E7072C5560AB519BEBA06397E8F62890FAE2083D5251FC63D6AD1A0CD5D52734C02BA70F317DFCB2D63614C12835D07AA8F15F4065BAA30419B56FC73AE6454529DFEB3038AF8AC5CE2A57305D85DB4DBF049B940B53EEC90039290096FA08F2B29F79E87A25642AF1E5754A7B44F199FC71B2C7952949D0587E7F263F5AFB8EAA4BDD689E79A37FFF5C505B69AD0FC12B84FF8BA749F5276068983CCFD5DC4CD453187712FA8E678C3929FC1BB307204A6F4B2B13717D587C3A156EFB6892B22C32EFE6569032143BF8456744734672D84DF15F8C43116E5B7E54DB30357A79509B933E70DD36453C23921B2E52E81C3BDF5A8B7CEC52460716AD13C562E01721F90B1DFD924367B268DCE62A093C640ECA1C5307417574683D3C3E

PVM initialization argument (436 bytes):

0B00013D6F8B6B7DFD4A334D8C51B9006800AB17D61705E569765BAFC54FB0B8D6DD9E0000000000000000000000000000000000000000000000000000000000000000A33FD62C73AA99798665AACB88B9AAD62C82389E49B06838E6FBC2DD04FBD78C36B4ED136F79C2C1CBC40696CC99A1417B6A6695DF5689909D16426E96D15579AE9900812401160009333ADC619129BD8CDAE03B04E7072C5560AB519BEBA06397E8F62890FAE2083D5251FC63D6AD1A0CD5D52734C02BA70F317DFCB2D63614C12835D07AA8F15F4065BAA30419B56FC73AE6454529DFEB3038AF8AC5CE2A57305D85DB4DBF049B940B53EEC90039290096FA08F2B29F79E87A25642AF1E5754A7B44F199FC71B2C7952949D0587E7F263F5AFB8EAA4BDD689E79A37FFF5C505B69AD0FC12B84FF8BA749F5276068983CCFD5DC4CD453187712FA8E678C3929FC1BB307204A6F4B2B13717D587C3A156EFB6892B22C32EFE6569032143BF8456744734672D84DF15F8C43116E5B7E54DB30357A79509B933E70DD36453C23921B2E52E81C3BDF5A8B7CEC52460716AD13C562E01721F90B1DFD924367B268DCE62A093C640ECA1C5307417574683D3C3E

[clearloop]

for service 11929:

fetch(0): "0a00000000000000010000000000000064000000000000000200200000000c000000809698000000000080f0fa020000000000ca9a3b00000000002d3101000000000800100008000300403800000300080006005000040080000500060000fa0000017cd20000093d0004000000000c00000204000000c0000080000000000c00000a000000"
fetch(0): "0a00000000000000010000000000000064000000000000000200200000000c000000809698000000000080f0fa020000000000ca9a3b00000000002d3101000000000800100008000300403800000300080006005000040080000500060000fa0000017cd20000093d0004000000000c00000204000000c0000080000000000c00000a000000"
info: "3f72b36f023e0a26ba5e3bb25dccd8bc38055b9561f7ca61fecb0c957de7e577ffffffffffffffff00000000000000000a000000000000000a00000000000000857802000000000006000000ffffffffffffffff000000000a00000000000000"
fetch(14): "013d6f8b6b7dfd4a334d8c51b9006800ab17d61705e569765bafc54fb0b8d6dd9e13fa01c5415b337a70de9014c5092efff3016c4939dc61db47dac6bad5c8059da33fd62c73aa99798665aacb88b9aad62c82389e49b06838e6fbc2dd04fbd78c36b4ed136f79c2c1cbc40696cc99a1417b6a6695df5689909d16426e96d15579ae9900812401160009333adc619129bd8cdae03b04e7072c5560ab519beba06397e8f62890fae2083d5251fc63d6ad1a0cd5d52734c02ba70f317dfcb2d63614c12835d07aa8f15f4065baa30419b56fc73ae6454529dfeb3038af8ac5ce2a57305d85db4dbf049b940b53eec90039290096fa08f2b29f79e87a25642af1e5754a7b44f199fc71b2c7952949d0587e7f263f5afb8eaa4bdd689e79a37fff5c505b69ad0fc12b84ff8ba749f5276068983ccfd5dc4cd453187712fa8e678c3929fc1bb307204a6f4b2b13717d587c3a156efb6892b22c32efe6569032143bf8456744734672d84df15f8c43116e5b7e54db30357a79509b933e70dd36453c23921b2e52e81c3bdf5a8b7cec52460716ad13c562e01721f90b1dfd924367b268dce62a093c640eca1c5307417574683d3c3e"
fetch(14): "013d6f8b6b7dfd4a334d8c51b9006800ab17d61705e569765bafc54fb0b8d6dd9e13fa01c5415b337a70de9014c5092efff3016c4939dc61db47dac6bad5c8059da33fd62c73aa99798665aacb88b9aad62c82389e49b06838e6fbc2dd04fbd78c36b4ed136f79c2c1cbc40696cc99a1417b6a6695df5689909d16426e96d15579ae9900812401160009333adc619129bd8cdae03b04e7072c5560ab519beba06397e8f62890fae2083d5251fc63d6ad1a0cd5d52734c02ba70f317dfcb2d63614c12835d07aa8f15f4065baa30419b56fc73ae6454529dfeb3038af8ac5ce2a57305d85db4dbf049b940b53eec90039290096fa08f2b29f79e87a25642af1e5754a7b44f199fc71b2c7952949d0587e7f263f5afb8eaa4bdd689e79a37fff5c505b69ad0fc12b84ff8ba749f5276068983ccfd5dc4cd453187712fa8e678c3929fc1bb307204a6f4b2b13717d587c3a156efb6892b22c32efe6569032143bf8456744734672d84df15f8c43116e5b7e54db30357a79509b933e70dd36453c23921b2e52e81c3bdf5a8b7cec52460716ad13c562e01721f90b1dfd924367b268dce62a093c640eca1c5307417574683d3c3e"

[sierkov]

@clearloop Thank you!

I’m seeing a single delta in the serialized accumulation operands returned by fetch 14: the second encoded 32-byte hash (starting at byte 33) differs.

yours: 0x13fa01c5415b337a70de9014c5092efff3016c4939dc61db47dac6bad5c8059d
mine:  0x0000000000000000000000000000000000000000000000000000000000000000

My reading of (C.32) is that the second hash should be exports_root

In traces/1757423271/00000011.json report.package_spec.exports_root is:

0x0000000000000000000000000000000000000000000000000000000000000000

Could you share how you derived the following value for your field:

0x13fa01c5415b337a70de9014c5092efff3016c4939dc61db47dac6bad5c8059d

Here is an exerpt from traces/1757423271/00000011.json for reference:

"report": {
  "package_spec": {
      "hash": "0xe6f55a15c04c6c807a13e453a5e7be058448a4ad38daa07476f23e0b14aa890b",
      "length": 393,
      "erasure_root": "0x2b8b2b2bbd4ea8c1ee710065a04786a86cb10dcb6b0edb4412e58de2bdde9998",
      "exports_root": "0x0000000000000000000000000000000000000000000000000000000000000000",
      "exports_count": 0
  },
  "context": {
      "anchor": "0x4445ec22a59c4a5fb31cd60489426b95a6fd8465c3dca2839bc96119e9b0224b",
      "state_root": "0x0fd50b306b691b05af3702542564b9870bb17aea04bc404a45688bea7edfc357",
      "beefy_root": "0x581f10ddd774befd80936ba02cd8521c6f16e1478e4a25c4d34421470f8f91c3",
      "lookup_anchor": "0x4445ec22a59c4a5fb31cd60489426b95a6fd8465c3dca2839bc96119e9b0224b",
      "lookup_anchor_slot": 10,
      "prerequisites": []
  },
  "core_index": 1,
  "authorizer_hash": "0xa33fd62c73aa99798665aacb88b9aad62c82389e49b06838e6fbc2dd04fbd78c",
  "auth_gas_used": 7021,
  "auth_output": "0x417574683d3c3e",
  "segment_root_lookup": [],
  "results": [
      {
          "service_id": 0,
          "code_hash": "0x3f72b36f023e0a26ba5e3bb25dccd8bc38055b9561f7ca61fecb0c957de7e577",
          "payload_hash": "0xf0787096a4812da5ffabe467eb19b6d291fbc28da123bbe5cca4424b32ea2446",
          "accumulate_gas": 10000000,
          "result": {
              "ok": "0x011600050b53eec90039290096fa08f2b29f79e87a25642af1e5754a7b44f199fc71b2c7333adc619129bd8cdae03b04e7072c5560ab519beba06397e8f62890fae2083d5251fc63d6ad1a0cd5d52734c02ba70f317dfcb2d63614c12835d07aa8f15f4013717d587c3a156efb6892b22c32efe6569032143bf8456744734672d84df15f7cec52460716ad13c562e01721f90b1dfd924367b268dce62a093c640eca1c53"
          },
          "refine_load": {
              "gas_used": 51987,
              "imports": 0,
              "extrinsic_count": 0,
              "extrinsic_size": 0,
              "exports": 0
          }
      }
  ]
}

[clearloop]

we can pass this trace, however, looks like there could be some problems in the encoding order, will re-confirm it after dinner!

[clearloop]

I found that I do have some issues in the encoding, you are correct in the exports_root, but this also confirms that the problem you met is not triggered by the operands (info), after correct the exports root in my implementation, the encoded fetch(14) is

013d6f8b6b7dfd4a334d8c51b9006800ab17d61705e569765bafc54fb0b8d6dd9e0000000000000000000000000000000000000000000000000000000000000000a33fd62c73aa99798665aacb88b9aad62c82389e49b06838e6fbc2dd04fbd78c36b4ed136f79c2c1cbc40696cc99a1417b6a6695df5689909d16426e96d15579ae9900812401160009333adc619129bd8cdae03b04e7072c5560ab519beba06397e8f62890fae2083d5251fc63d6ad1a0cd5d52734c02ba70f317dfcb2d63614c12835d07aa8f15f4065baa30419b56fc73ae6454529dfeb3038af8ac5ce2a57305d85db4dbf049b940b53eec90039290096fa08f2b29f79e87a25642af1e5754a7b44f199fc71b2c7952949d0587e7f263f5afb8eaa4bdd689e79a37fff5c505b69ad0fc12b84ff8ba749f5276068983ccfd5dc4cd453187712fa8e678c3929fc1bb307204a6f4b2b13717d587c3a156efb6892b22c32efe6569032143bf8456744734672d84df15f8c43116e5b7e54db30357a79509b933e70dd36453c23921b2e52e81c3bdf5a8b7cec52460716ad13c562e01721f90b1dfd924367b268dce62a093c640eca1c5307417574683d3c3e

PVM args 0b0001, looks like you haven't upgraded the encoding of PVM args, it should use the length of operands but not the operands themselves now

[sierkov]

@clearloop Thank you for the update—and for the pointer about the legacy format for PVM initialization arguments. You’re right: the root cause appears to be elsewhere. I’ll investigate other possibilities on my side.

[sierkov]

I’ve found the root cause. In this trace, accumulation terminates due to out-of-gas. I misapplied the transformation from (A.44):

u = ϱ − max(ϱ′, 0)

as:

u = ϱ − ϱ′

Per (A.1), out-of-gas occurs when ϱ′ < 0. Here ϱ′ = −1, so the correct computation is:

u = ϱ − max(−1, 0) = ϱ − 0 = ϱ

Whereas my code did:

u = ϱ − (−1) = ϱ + 1

—which inflates u by 1 and explains the one-unit gas discrepancy from the expected value.