Skip to content

CoreJam #31

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
gavofyork wants to merge 50 commits into from
Closed

CoreJam #31

Changes from 1 commit
Commits
Show all changes
50 commits
Select commit Hold shift + click to select a range
006a9ff
Add CoreJam draft
gavofyork Sep 20, 2023
d7ec165
weight and prune
gavofyork Sep 21, 2023
4384db4
Prerequisites, initial checks, migration, a few other bits.
gavofyork Sep 25, 2023
a096282
Rename for proposing.
gavofyork Sep 25, 2023
e97e109
Typos and clarifications
gavofyork Sep 26, 2023
7f9aa0b
Ordering: Soft and Hard
gavofyork Sep 26, 2023
e4a117b
Remove superfluous
gavofyork Sep 26, 2023
c4f2e0d
Correct number
gavofyork Sep 26, 2023
8e99271
Tidy ordering
gavofyork Sep 27, 2023
607963e
More clarity
gavofyork Sep 27, 2023
e71b6ce
Cleanups
gavofyork Sep 27, 2023
3c1d2e5
More cleanups
gavofyork Sep 27, 2023
329e24f
Compatibility
gavofyork Sep 27, 2023
dae162c
More cleanups
gavofyork Sep 27, 2023
b2a05ba
Register becomes Report
gavofyork Sep 28, 2023
6d5a175
UMP/HRMP compat
gavofyork Sep 30, 2023
5fd33ac
More on copmat
gavofyork Sep 30, 2023
eb7dab2
Move para
gavofyork Sep 30, 2023
0b5b7ab
Typo
gavofyork Sep 30, 2023
26fd0ed
Update text/0031-corejam.md
gavofyork Oct 2, 2023
ddbb534
Remove , introduce Beefy and state roots
gavofyork Oct 4, 2023
3d6859d
Update text/0031-corejam.md
gavofyork Oct 4, 2023
e4110e6
Update text/0031-corejam.md
gavofyork Oct 13, 2023
85db6ec
Update text/0031-corejam.md
gavofyork Oct 13, 2023
eb93fda
Update text/0031-corejam.md
gavofyork Oct 13, 2023
d6bb203
Update text/0031-corejam.md
gavofyork Oct 13, 2023
1cb5f0d
Update text/0031-corejam.md
gavofyork Oct 16, 2023
95987d3
Update text/0031-corejam.md
gavofyork Oct 16, 2023
d87f686
Update text/0031-corejam.md
gavofyork Oct 16, 2023
d64f568
Apply suggestions from code review
gavofyork Oct 16, 2023
a1eaff8
tweaks
gavofyork Oct 17, 2023
3a368ac
Merge branch 'gav-corejam' of https://github.com/polkadot-fellows/RFC…
gavofyork Oct 18, 2023
52fa112
Add host function `transfer`
gavofyork Oct 18, 2023
26ed3f2
Smart contract stuff
gavofyork Oct 18, 2023
f0dea5e
Ensure that context is checked prior to is_authorized
gavofyork Oct 18, 2023
62436a6
fix
gavofyork Oct 18, 2023
8b321a7
Update text/0031-corejam.md
gavofyork Oct 18, 2023
e32333d
Update text/0031-corejam.md
gavofyork Oct 18, 2023
e33e467
Update text/0031-corejam.md
gavofyork Oct 18, 2023
4d45769
No more ICT
gavofyork Oct 20, 2023
aaaaae3
Merge branch 'gav-corejam' of https://github.com/polkadot-fellows/RFC…
gavofyork Oct 20, 2023
9360c19
Update 0031-corejam.md
gavofyork Oct 21, 2023
23470a2
Update 0031-corejam.md
gavofyork Oct 21, 2023
7d34d4a
Explanation
gavofyork Oct 23, 2023
259e466
Rename Work Class -> Service
gavofyork Oct 23, 2023
cfea18f
Explanation
gavofyork Oct 27, 2023
6d27b30
Note about lookup
gavofyork Oct 27, 2023
0123124
Merge branch 'gav-corejam' of https://github.com/polkadot-fellows/RFC…
gavofyork Oct 27, 2023
c15ef01
Terminology
gavofyork Oct 27, 2023
9e1b05e
Update text/0031-corejam.md
gavofyork Dec 11, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Update text/0031-corejam.md 
Co-authored-by: gupnik <[email protected]>
  • Loading branch information
@gavofyork @gupnik
gavofyork and gupnik authored Oct 13, 2023
commit eb93fdafd4b8b8c4d5a68c30e9b51ff270cf4792
2 changes: 1 addition & 1 deletion text/0031-corejam.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -173,7 +173,7 @@ The `code_hash` of the Authorizer is assumed to be the hash of some code accessi
fn is_authorized(param: &AuthParam, package: &WorkPackage, core_index: CoreIndex) -> bool;
Copy link
Contributor

@bkchr bkchr Oct 16, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need the core_index? IMO we should not "leak" the CoreIndex here. Tasks/Parachains/Whatever should not care on what Core they are executed.

Copy link
Contributor Author

@gavofyork gavofyork Oct 16, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a good reason not to provide the core index?

Copy link
Contributor

@bkchr bkchr Oct 16, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, not really ;)

Copy link
Contributor

@eskimor eskimor Nov 27, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was very happy to see the CoreIndex here, because I think it is indeed needed. Consider the case of elastic scaling/using multiple cores. By providing a CoreIndex we can ensure that packages are not conflicting, as we can make it so that it is authorized on one core, but not the other.

This works well with bulk, where core time is bought on a specific core. It does less so with on-demand (but no longer provided anyway), where currently the implementation will just pick any core. For bulk this should really work though: Given that we have access to relay chain context, we could abstract away from the actual index and do logic like: This is the third core index, that is assigned to our task -> good. So the exact core index would not matter (and the authorizer would not need to change), all that needs to stay stable is ordering.

Copy link

@burdges burdges Dec 2, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We've previous discussions with @rphmeier in which we all kinda thought relay chain block producers should allocate candidate reciepts to cores right after backing aka during "reporting". As I noted, we could even allocate candidate reciepts to cores after availability during inclusion/integration. It's clear this complicates availability and the bit-core mapping though.

I'd previously favored backers making "work packages" from parachain blocks, with an extra collator layer being another option like corejam implicitly proposes, but these both demand more work from backers, which sounds like a more impenetrable barrier.

```

If the `is_authorized` function overruns the system-wide limit or panicks on some input, it is considered equivalent to returning `false`. While it is mostly stateless (e.g. isolated from any Relay-chain state) it is provided with a `context` parameter in order to give information about a recent Relay-chain block. This allows it to be provided with a concise proof over some recent state Relay-chain state.
If the `is_authorized` function overruns the system-wide limit or panicks on some input, it is considered equivalent to returning `false`. While it is mostly stateless (e.g. isolated from any Relay-chain state) it is provided with a `context` parameter in order to give information about a recent Relay-chain block. This allows it to be provided with a concise proof over some recent Relay-chain state.

A single `Authorizer` value is associated with the index of the Core at a particular Relay-chain block and limits in some way what Work Packages may be legally processed by that Core.

Expand Down