Repository navigation
add: RefineBundle (auth-trace + auth-gas-used), GetExports feature - #59
Conversation
|
Good idea with the GetExports. Will be pretty useful for debugging erasure/exports root differences |
Co-authored-by: Davide Galassi <davxy@datawok.net>
| - **Refinement:** If work package bundle refinement is supported by the target, the fuzzer may send a `RefineBundle` and the fuzzer target must send a `WorkReport` in response. The work package `auth-code-host`, `auth-code-hash` for authorization and `service` and `code-hash` for each work item may be found in the previously transmitted states referenced by the Work package `context` by `anchor` or `lookup-anchor` (for historical lookup). For purposes of bounding the number of state, only the last 600 states `SetState` should be considered. | ||
| - **Refinement failures:** If a work package bundle refinement fails, the target must return a work report regardless, and then wait for another block or refine bundle from the target as usual. | ||
| - **Refinement:** If work package bundle refinement is supported by the target (via `feature-bundle-refinement`), the fuzzer may send a `RefineBundle` and the fuzzer target must send a `WorkReport` in response. Only refine should be invoked, however; the core `core-index`, authorization gas used `auth-gas-used` and authorization trace `auth-trace` is provided in the bundle for inclusion in the WorkReport to represent a prior authorization. The `service` and `code-hash` for each work item may be found in the previously transmitted states referenced by the Work package `context` by `anchor` or `lookup-anchor` (for historical lookup). For purposes of bounding the number of states, only the last 600 states `SetState` should be considered. | ||
| - **Refinement failures:** If a work package bundle refinement fails, the target must return a work report regardless, and then wait for another block or refine bundle from the target as usual. If the target supports the retrieval of exported segments (via `feature-exports`), the fuzzer may send a `GetExports` request with either the work package hash or the exported segment root and the target must send `Exports` in response. The `GetExports` request is issued only when a work report mismatch is detected, and will reference only the most recently refined work package bundle. |
There was a problem hiding this comment.
Can you clarify why, in case of a work report mismatch, we may query the Exports?
Also, it's not entirely clear to me why we return a WorkReport in case of failure. Which report do we return in that situation?
I'm not entirely sure, but maybe for this protocol revision it would make sense to introduce a general Error response message.
That is, an Error could be returned as a response to ANY request when something goes wrong (e.g. if ImportBlock or SetState fails). Of course, we need a flag 'fatal'. For unexpected error (e.g. errors due to block import are not fatal).
If we don't want to spend too much time defining a full set of error codes, we could just return a string - some printable message (which may also be empty).
WDYT? Just thinking out loud.
There was a problem hiding this comment.
Can you clarify why, in case of a work report mismatch, we may query the Exports?
Also, it's not entirely clear to me why we return a WorkReport in case of failure. Which report do we return in that situation?
Failures in work report are systematically reported in WorkExecResult within the WorkReport: out-of-gas, panic, bad-exports, bad-code, code-oversize -- and success (ok) has the raw output. Mismatches between WorkReport by the fuzzer and target are reportable by computing the hash of the WorkReport and generating a report detailing the exact mismatch -- fuzzer and target are likely to differ on either:
- their
WorkResultand specifically theWorkExecResult-- most commonly differences in bytes of theokbut also any of the 5 "failures" - their
ExportsRoot - their
ErasureRoot
In the event of a difference in ExportRoot, having each and every one of the segments (done via the export host call) will assist implementers in knowing if its a difference in the raw data vs the erasure encoding of that data. Having just the ExportsRoot is not very informative.
In the event of a difference in ErasureRoot, you could imagine having a fuzzer get a derivation of erasure coding pieces (see jam-duna/coreplay#139 for me trying to explain each step) but it would require a LOT of more description -- availability spec derivation is quite an onion!
In our experience in getting work reports to match between our implementation and polkajam without the fuzzer/target protocol this spring, we first got our WorkReports to match without any exports to confirm we got the same ErasureRoot, then with 1 (with a known export segment root from the erasure coding sample) to confirm we got the same ExportsRoot as well. Then with 2, 3, etc. We imagine implementers getting alignment between the two root with the fuzzer protocol more quickly with a "verbosity" flag turned on from a friendly fuzzer showing these erasure coding derivations... the bundle is in the RefineBundle input itself, but the fuzzer needs visibility to into the exported segments of the target to generate a detailed report analogous to those you provide on state key-value pair mismatches.
I don't think we should to develop strings for Error for the 5 failures, nor a complex string summarizing difference -- but reports can detail that
- work reports differ in 1 or more attributes, which we believe will be either
RefineLoad,ExportsRootandErasureRootmost commonly in practice - exports do not match, and specifically exports {...} do not match and present the difference between fuzzer vs target export, indicating some computational difference
- exports match perfectly, but segment roots differ, indicating an erasure coding problem of these exports
Because segments are 4104 bytes and there may be hundreds to thousands of segments (3K), its not realistic to have a github repo like this to generate mismatch reports since they be MBs each, and instead have fuzzer binaries distributed with like the seed/payload needed to demonstrate aWorkReportdifference.
There was a problem hiding this comment.
Perhaps all this info should go in the readme
There was a problem hiding this comment.
Ok! I made an attempt and also drafted a pvm tracing feature
|
I appreciate the PVM tracing work. However, I think it would be better handled in a separate PR, since it deserves a careful and dedicated discussion. Right now my priority is to get the protocol enacted ASAP without overloading the clean spec we have and too much distractions. Even "Refine" is still experimental, but it is relatively straightforward to include. Could you please wait until this PR is merged, and then open a new one with your PVM trace ideas? |
Sure thing -- done! |
3 participants
No description provided.