Document Missing Dependencies in STF Equations

[sierkov]

Adds missing STF dependencies to Section 4.2.1 for clarity.

Details:

• (4.16) Clarified that accumulation additionally depends on eta_prime (B.11).
• (4.14) Clarified that rho_prime additionally depends on:
  • beta_dagger (11.33)
  • alpha (11.29)
  • delta (11.30)
  • eta_prime (11.22)
• (4.11) Clarified that psi_prime additionally depends on kappa, lambda, and tau for signature verification (10.3), (10.5), (10.6).
• (4.5) Clarified that tau_prime depends on tau to enforce monotonicity (5.7).

[davxy]

alpha (11.23)

Typo in the description. I imagine you refer to [11.29](https://graypaper.fluffylabs.dev/#/1c979cb/155602155602?v=0.7.1

[sierkov]

@davxy Thank you. I've updated the description to reference (11.29).

[zdave-parity]

Including dependencies for signature verification does not make sense to me. These can be verified in parallel.

[davxy]

Including dependencies for signature verification does not make sense to me. These can be verified in parallel.

Indeed, computing the posterior value doesn't require on signature verification.
My point was more about accepting the posterior value and thus proceding with the actual assignment (which I suspect is what @sierkov was also considering).
That said, I agree that signature verification is unnecessary for computing the posterior value.

The same reasoning applies to the timestamp as well.

[zdave-parity]

If signature verification fails the block is invalid and any computed posterior state is irrelevant. The dependencies for a particular value should include only what is necessary to compute that value. Whether the value itself is useful or not is irrelevant.

[sierkov]

@zdave-parity My rationale for explicitly listing all state components — including those used solely for signature verification — is as follows:

1. Scheduling reasoning: Explicitly listing every dependency clarifies which operations can run immediately and which must wait. For example, showing that rho_double_dagger depends on kappa makes it clear that it uses the prior version of kappa, so it can be scheduled right away. Likewise, specifying that rho_prime depends on kappa_prime shows that it must wait until kappa_prime is available.
2. Mutation strategy: Knowing which components’ prior state is referenced elsewhere determines whether they can be updated in-place (when the prior version is unused) or must use copy–mutate–swap (when the prior version is still referenced).

P.S. You’re right — signature verification can run in parallel with state mutation. That said, the same scheduling and mutation principles still apply to the components required for signature verification. Since we don’t list signature verification as a separate step, I think it’s reasonable to include those dependencies as part of the dependencies for the individual components that involve signature verification.

[zdave-parity]

showing that rho_double_dagger depends on kappa makes it clear that it uses the prior version of kappa

rho_double_dagger does not depend on kappa AFAICT?

Likewise, specifying that rho_prime depends on kappa_prime shows that it must wait until kappa_prime is available

AFAICT rho_prime does not depend on kappa_prime and can be computed before this? I'm not sure why it is currently listed as depending on kappa as AFAICT it does not depend on that either. Perhaps the kappa dependency is a leftover from an earlier definition of rho_prime.

Since we don’t list signature verification as a separate step, I think it’s reasonable to include those dependencies as part of the dependencies for the individual components that involve signature verification.

The dependency graph section is purely informative and as such does not need to be comprehensive. If something is not included then it is implicitly left as an exercise for the reader. An argument could be made for including eg signature verification dependencies, but tacking them on to vaguely related terms is completely arbitrary, confusing, and somewhat defeats the purpose of the graph.

[0xjunha]

Since the purpose is to help implementors get ideas for parallelization and keep the deps graph minimal, I agree we can omit state items used only for Xt validations.

Also I think we should add R (newly available reports) or ρ† in (4.20), since π_C' depends on it to get d (DA items size).

If we'd like to add state items used only for Xt validation to the graph, we should add ρ, ω, ξ to (4.14) as well since they're used for WP hash duplicate check - (11.36), (11.37), (11.38)

[zdave-parity]

Also I think we should add R (newly available reports) or ρ† in (4.20), since π_C' depends on it to get d (DA items size).

Agree. If we add R I guess we should also list the dependencies for R and include it as a dependency in eg 4.13.

[sierkov]

@zdave-parity, @0xjunha If there’s consensus that dependencies required for signature verification can be omitted, I won’t insist on including them. This would remove kappa from (4.13), and kappa_prime, lambda_prime, and psi_prime from (4.14) in the proposed changes. I’ve updated the proposed changes and the description accordingly—please let me know if you have further feedback.

P.S. I’m traveling this week, so my responses may be delayed.

[zdave-parity]

I think there is still a misunderstanding about what information the dependency graph is supposed to convey. The dependencies for some value x should include only the values required to actually compute x. That is, the values which (transitively) appear in the expression for x in the GP. Let's take \thetime' as an example, because it's so simple. That is defined like so:

\thetime' \equiv \H_\¬timeslot

It requires only \H_\¬timeslot, which is part of \theheader, hence why only \theheader is listed as a dependency. Where did you get \thetime from?