cumulus on jam - scope of work - #12714
Conversation
|
All GitHub workflows were cancelled due to failure one of the required jobs. |
michalkucharczyk
changed the title
michalkucharczyk
added
R0-no-crate-publish-required
| - Drop the relay-state-proof inherent; the PVF reads its inputs in-core. **Open [\[1\]](#ref-1) gap**: | ||
| §4.3 exposes only preimage-by-hash lookups and the refine context — there is no generic | ||
| service-state read (para head, KV) host call; [\[1\]](#ref-1) says state arrives "through the | ||
| validation inputs" without defining the mechanism. Needs resolution on the [\[1\]](#ref-1) side. |
There was a problem hiding this comment.
I think it makes sense to have two extrinsics per para work items:
- Para state Proof
- Service state proof (downward data and proof, like current relay chain state proof)
And the put the metadata into the refine Payload. The extrinsics can be loaded chunked, so for large proofs it could help to not go OOM.
| - AURA remap (runtime + node in lockstep): `can_build_upon`/`AuraUnincludedSegmentApi` and | ||
| aura-ext `FixedVelocityConsensusHook` compare against the relay slot — must compare against | ||
| the JAM timeslot. The AURA pre-digest/seal itself is unchanged (no relay dependency). | ||
| - `RelayParentOffset` (anchor N blocks behind the tip to reduce para forks; used by live |
There was a problem hiding this comment.
Do we still need this with Safrole ? AFAIK forks should be very special occasion.
There was a problem hiding this comment.
Good point. But we would still need to address it somehow. If not in runtime - then on collator side and with JAM backend we should build on recent RC block.
Also "very special occasion" does not mean impossible - so the open question if we want to keep RelayParentOffset feature.
There was a problem hiding this comment.
Forks can still happen from networking issues I assume, but true that from protocol alone it should not.
There was a problem hiding this comment.
Yeah, this RelayParentOffset is now an optimization for an edge case in JAM.
| chain observation (see 3). | ||
| - Guarantor pre-connect (direct-JAMNP phase): the gap is guarantor-identity → JAMNP address | ||
| discovery (today backing-group connections ride authority-discovery DHT). | ||
| - `ApprovedPeer` (para approves its collator peer-id; emitted by parachain-system, carried via |
There was a problem hiding this comment.
This is used in Polkadot for maintaining the reputation of collators. It is mainly a spam protection mechanism. Validators prefer to fetch collations from higher reputation collators. We might want such a system in JAM that applies to all WP.
There was a problem hiding this comment.
well if we have the authorizer check and granted that it'd not possible to have multiple authorities valid for authorship at the same time, we don't need the reputation system I believe.
Moreover, if we have all the valid authorities of a parachain registered on the coretime chain, we can reject connections coming from different peers so we also got connection spam covered.
@bkchr I remember you saying that there are smth like 8 possible valid authors at any given point in time?
I still don't fully understand how that would work.
| weights (opens the benchmarking pandora jar). | ||
|
|
||
| #### 11. **PVM executor & tooling** | ||
| - Soft proposal: keep the WASM executor for block building in phase 1 — technically the PoV |
There was a problem hiding this comment.
Maybe we can start with PVM. We already have a working PoC here.
| advancement, and **resubmission** — anchors expire with the recent-history window, a stuck | ||
| WP must be rebuilt on a fresh anchor; the `Failed` status enumerates the cases (anchor on | ||
| other fork / not reported / not available in time). No cumulus analog today. | ||
| - Decide whether WPs can also be built from imported (not self-authored) blocks — |
There was a problem hiding this comment.
if we want proper resubmissions we do need this. We have a prototype in polkadot that will be merged soonish, which will make use of that proof consumer that is now unused
| 1 = submit via RPC to a (trusted) JAM node; direct JAMNP submission from the collator later. | ||
| - Post-submission tracking: JIP-2 `workPackageStatus` (Reportable → Reported → Ready; no | ||
| Accumulated status by design — accumulation observed via `subscribeServiceValue`) replaces | ||
| the collator-protocol "seconded" signal. Drives: announcement, unincluded-segment |
There was a problem hiding this comment.
the seconded signal is pretty much useless in polkadot now
| the collator key is generated ad hoc by the relay-node builder, not the keystore). | ||
|
|
||
| #### 5. **Parent selection & pipelining** (replaces `find_parent_for_building`) | ||
| - Today: included head from `persisted_validation_data` + pending-availability candidates. |
There was a problem hiding this comment.
plus the longest chain of built blocks even if they weren't yet backed
| building the work report; the collator submits only the bundle. | ||
| - PoV compression: zstd today — decide if the WP extrinsic carries compressed PoV and who | ||
| decompresses (Refine gas cost). | ||
| - Submission: JIP-2 `submitWorkPackage(core, package, extrinsics)`; the node routes to the |
There was a problem hiding this comment.
just pointing out that with the current protocol low latency resubmissions will not be possible IIUC.
on Polkadot (in draft PRs still), we advertise entire portions of the unincluded segment to validators so that they get to fetch whichever blocks they do not have (with some per-core grouping so that we don't have multiple cores validating the same block simulatenously).
This achieves fast resubmissions without periodic polling of the collation status (which IIUC is also not possible on current JAM protocol, if we'll only rely on on-chain data for viewing the WP status).
We can still do resubmissions but not with such a low latency and reliability
| chain observation (see 3). | ||
| - Guarantor pre-connect (direct-JAMNP phase): the gap is guarantor-identity → JAMNP address | ||
| discovery (today backing-group connections ride authority-discovery DHT). | ||
| - `ApprovedPeer` (para approves its collator peer-id; emitted by parachain-system, carried via |
There was a problem hiding this comment.
well if we have the authorizer check and granted that it'd not possible to have multiple authorities valid for authorship at the same time, we don't need the reputation system I believe.
Moreover, if we have all the valid authorities of a parachain registered on the coretime chain, we can reject connections coming from different peers so we also got connection spam covered.
@bkchr I remember you saying that there are smth like 8 possible valid authors at any given point in time?
I still don't fully understand how that would work.
4 participants
rendered