-
Notifications
You must be signed in to change notification settings - Fork 52
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.
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
Corrections on 0.5.2 #160
Corrections on 0.5.2 #160
Conversation
gavofyork
commented
Dec 6, 2024
•
edited
Loading
edited
- Definitions: Update gas limits so that gas = nanoseconds
- WP&WRs: Badly reported exports count doesn't invalidate WP
- R&A: Active removal of expired reports
- PVM Invocations: No need for HIGH gas error, in fact.
- State Merklisation: Clearer definition of pi serialisation
- R&A: Remove superfluous timeout condition
text/reporting_assurance.tex
Outdated
\begin{align} | ||
&\forall a \in \xtassurances, c \in \N_\mathsf{C} :\\ | ||
&\quad a_f[c] \Rightarrow \rho^\dagger[c] \ne \none \wedge \mathbf{H}_t \le \rho^\dagger[c]_t + \mathsf{U} | ||
&\quad a_f[c] \Rightarrow \rho^\dagger[c] \ne \none |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -124,10 +124,10 @@ \subsubsection{The Assurances Extrinsic} | |||
&\mathsf{X}_A \equiv \token{\$jam\_available} | |||
\end{align} | |||
|
|||
A bit may only be set if the corresponding core has a report pending availability on it which has not timed out: | |||
A bit may only be set if the corresponding core has a report pending availability on it: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, according to this change, now a bit can be set even if the pending report has timed out. Thus , if we achieve an availability supermajority for a timed-out report (according to 11.17) it would still be included in W.
This means it will still be considered for accumulation in the next pipeline stage.
Essentially, we're now a bit more lenient with timeouts. In other words, if it's timed out but still available, we no longer consider it an issue.
Given this explicit change, I assume this is an intentional design choice. However, I just wanted to double-check to be sure
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes - if a report is made available on the exact timeout block, we prefer to accumulate than to drop.