Optimality and the Lower Bound
Why We Need a Converse for Polynomial Codes
Section 5.2 established that polynomial codes achieve . The next question is whether any cleverer scheme, at the same storage level , could achieve . A rigorous answer requires a converse: a proof that no such scheme exists, i.e., a lower bound that matches the achievability. If we do not have the converse, we do not know whether polynomial codes are the final word or merely a good construction waiting to be beaten.
This section develops the converse argument. The structure mirrors Chapter 2's cut-set converse: identify the cut, apply an entropy bound, symmetrize, normalize. The point is that the four-step recipe transfers from generic coded shuffling to the specific matrix-multiplication setting β an instance of the golden thread from Chapter 2.
Theorem: Matching Lower Bound:
Consider any distributed matrix-multiplication scheme with per-worker storage and independent, uniform , . Suppose the scheme's decoder must succeed on every size- subset of worker responses. Then The polynomial-code construction of Β§5.2 achieves this bound with equality, so the construction is information-theoretically optimal.
The master must reconstruct matrix blocks; each worker response is a single - valued observation. Without structure, observations are needed. The proof shows that the storage constraint does not enable the scheme to do better β every coding scheme at this storage level has at least -dimensional ambiguity in responses.
Set up the cut
Fix a subset of responses. Let be their joint view and the target output. The cut separates the master (with access to ) from the missing worker.
Apply the output-entropy bound
From Chapter 2's Output-Entropy Bound, any correct scheme must satisfy The storage constraint gives .
Count blocks
and together have entropy (uniform over ). The output has entropy . The per-worker output block has entropy . Hence worker responses are needed to cover the output's entropy.
Conclude
Any scheme with responses has positive error probability in the worst case. Hence .
Key Takeaway
Polynomial codes are information-theoretically optimal at storage . No scheme can simultaneously have smaller recovery threshold and the same storage. The result is tight and matches the cut-set converse. This is a genuine achievability-converse closure β one of the rare instances in the coded-computing literature.
What 'Optimal' Actually Means Here
The optimality statement is subtle. Polynomial codes achieve the minimum at their specific storage level . The tradeoff is two-dimensional: you can buy a smaller by increasing . For instance:
- (fractional storage, each worker stores one block pair): β uncoded minimum storage.
- (full replication): β any single response reconstructs.
Polynomial codes sit between these extremes at . The shape of the tradeoff curve is not fully characterized for all , but piecewise-linear interpolation gives a good upper bound on the achievable . Section 5.4 compares polynomial codes with MDS schemes that occupy different points on this curve.
Example: Converse at
For (so ), show explicitly that any scheme using 3 workers' responses to reconstruct must have error probability bounded away from zero.
Setup
Output has 4 blocks, each with entropy . Total output entropy: .
Bound the reconstructable information
Each response is one matrix of size , so its entropy is at most . With 3 responses, the master can access at most of independent information.
The gap
The output entropy is ; the available information is . The master must guess at least bits worth of "hidden" output blocks. The error probability is bounded below by Fano's inequality: in the large- limit.
Implication
The scheme cannot decode with arbitrarily small error from 3 responses. Hence .
Storage vs. Recovery Threshold: the Frontier
Plot the achievable operating points for three schemes: (i) uncoded disjoint storage, (ii) MDS-coded replication, (iii) polynomial codes with varying . The frontier shows how decreases as increases. Each scheme occupies a specific point; polynomial codes dominate at their specific .
Parameters
Number of workers
Range of partition products to plot
Common Mistake: Optimality Is Per-Storage, Not Global
Mistake:
Claim polynomial codes are "the" optimal coded-computing scheme for matrix multiplication.
Correction:
Polynomial codes are optimal at their specific storage level . At lower storage (e.g., ), different schemes might have different ; at higher storage (e.g., ), MDS-coded replication achieves . The right statement is: polynomial codes achieve the minimum at their per-worker storage level. The full frontier across all is piecewise and requires multiple constructions.
Converse-Matching Achievability in Production
The fact that polynomial codes match the converse is not merely aesthetic β it tells system architects when to stop optimizing. If a hypothetical "better" scheme promises at the same storage, the information-theoretic bound tells us the promise is impossible. Engineering time spent looking for one is wasted. This is perhaps the single most practical consequence of the converse proof: it saves teams from pursuing chimeras. The same lesson will reappear for PIR (Chapter 13 β Sun-Jafar capacity is tight) and secure aggregation (Chapter 10 β Caire et al.'s optimality result).
- β’
At , is tight β no cleverer scheme possible
- β’
Moving to higher storage () can reduce further
- β’
Matching converse means no 'secret' gain at this storage
Historical Note: The Converse Got Cleaner Over Time
2017β2019Yu, Maddah-Ali, and Avestimehr's original 2017 paper established the bound via a counting argument specialized to matrix multiplication. Dutta, Cadambe, and Grover's follow-on work (2019) gave a cleaner cut-set-based proof that generalizes to other linear computations (matrix-vector products, batched linear algebra). The modern treatment β which we present in this section β uses the Chapter 2 output-entropy recipe, making the converse a case study in the "cut, bound, symmetrize, normalize" template.
Why This Matters: The Same Converse Drives Chapters 6, 10, 13
The four-step converse recipe applied here β cut, entropy bound, symmetrize, normalize β drives the converses in multiple later chapters. Chapter 6's gradient-coding converse, Chapter 10's secure-aggregation optimality (the Caire et al. CommIT contribution), and Chapter 13's Sun-Jafar PIR capacity are all instances of the same template, specialized to different computation tasks and threat models. Reading Section 5.3 carefully pays dividends many times over.
Quick Check
Which step of the cut-set recipe introduces the storage constraint in the polynomial-code converse?
Identifying the cut
Applying the output-entropy bound
Symmetrizing over all equivalent cuts
Normalizing by the output size
The conditional entropy depends on the storage β workers with more stored material leave less residual uncertainty.