This section constructs the protocol of ePrint 2019/226 in the model of §4, each object before its first use: the header chain commitment and the check applied to one sampled block, two lemmas on forks, the difficulty Merkle mountain range with its node checks, the sampling distribution, the interactive and the non-interactive protocol, the security theorem with its hypotheses and status, and verification after acceptance. Throughout, is the hash function of §3, which is also the proof-of-work oracle of Definition 4.1; is the natural logarithm and the collision advantage of an algorithm (Crypto Guide, Definition “Collision resistance”, §“Security notions: preimage, second-preimage, and collision resistance”), the security parameter left implicit.
Blocks are written (the genesis block), , , …, with the block at height and the header of .
Fix an aggregating range (Definition 3.19) under the bagging (Definition 3.5) whose leaf map sends a block to a node tuple with hash field . Leaf of every range is , so leaf is the block at height . For every height let be the range over the leaves and its root tuple. The producer of obtains from by Construction 3.10 applied to , with the parent map in place of ( is the single leaf ), and records the hash field in the header of . The genesis header records no root. A full node accepts only if its header records .
The construction has the following invariant: the header of commits, through one root, to exactly the blocks strictly before it, and a head commits to leaves, denoting this leaf count below. The root’s fields other than its hash field are not recorded; a verifier recomputes the root tuple from its two children, which the hash field binds (Lemma 3.20). The range of ePrint 2019/226, Section 2, is the instance whose tuples carry the hash field alone; the paper’s difficulty Merkle mountain range is the instance of Definition 5.6. The one further header field is the paper’s only consensus change (Section 4.2). The paper indexes the committing block and its range inconsistently; the invariant fixes one indexing, and the paper’s is not carried. In the classes of Definition 1.3, this commitment from the genesis block is the paper’s design and no Zcash rule specifies it; the specified commitment is the epoch-scoped instance of “The chain-history commitment” (§6), from which nothing is concluded here.
One sample at index against a head must establish three facts: that the sampled block is leaf under the head’s root, that the leaf’s tuple is the one its header determines, and that the root in the sampled header commits to exactly the first of the same leaves.
The inputs are a root tuple with leaf count and an index . The prover sends the header of the block at height , the tuple of leaf , and its inclusion path in (Definition 3.13) with every sibling as a full tuple. The verifier performs the following checks.
Leaf: , and every other field of that the leaf map determines from the header alone equals its value computed from .
Prefix: for , the hash field of (Construction 3.16), run with in place of , equals the root recorded in ; for , equals the genesis header, which the verifier knows.
Proof of work: carries a valid proof of work at the target it declares, (Definition 4.1).
Any failure rejects.
ePrint 2019/226, Algorithm 2, lists checks (b) and (c); checks (a) and (d) come from its Definition 5 and Section 6.1. Check (b) uses the length rule of Definition 3.13, not that of the paper’s Algorithm 4.
Let be any root tuple, possibly chosen by the adversary, with leaf count , and let . There is an explicit reduction such that, for every adversary that outputs samples at position against , the probability that every sample passes Construction 5.2 while one of the following fails is at most :
any two passing samples at position carry the same leaf tuple and the same header, so the header is bound to position of the sequence that commits;
every header-determined field of that leaf tuple is its value computed from that header;
for , the root recorded in that header is the hash field of a prefix-root tuple that is the same for every passing sample at , hence a function of ; if is the root of a consistent labelling over , it is the root of the consistent labelling over .
The reduction runs and inspects two passing samples and at position . (i) If , Lemma 3.20(2), the tuple form of Theorem 3.17 under the prefix-free serialisation of Definition 3.19, yields a collision at the highest step whose inputs differ. If but , check (a) gives , a collision. (ii) is check (a). (iii) Barring the collisions of (i), , so the fold of check (c) over the left siblings of is the same tuple for every passing sample, and check (c) equates its hash field with the recorded root. For a consistent labelling, Lemma 3.15 with Lemma 3.20(3) identifies the fold with the root over , as Theorem 3.14 does for plain values. □
A claimed chain forks from the honest chain at its fork point, the last common block (§4.3). Its head records the root of a range over the leaf tuples of its blocks, and places a block at leaf position when .
Let the head of record the hash field of the root of a consistent labelling over . Let be a block of the honest chain at height above the fork point, whose header records the hash field of the honest root over the honest leaf tuples , and let place at leaf position . Suppose that
the sequences and differ, possibly in length; and
no block header equals for node tuples (leaf–internal separation).
Then from a sample of that passes Construction 5.2 against the head of an explicit reduction computes a collision of , or finds a leaf position of whose tuple has hash field for node tuples . A sample at passes check (a) only on a header hashing to that value, which by hypothesis 2 is a collision. Consequently, barring a collision, either a sample on rejects or leaf does, and that block or leaf belongs, in the analysis of §5.4, to the invalid set of the fork.
By Proposition 5.3(iii) a passing sample makes the root recorded in equal to the hash field of the root of the consistent labelling of over . That value is also the hash field of the honest root of . Descend both labellings from their roots, keeping a pair of nodes with equal hash fields whose leaf subsequences differ in their hash fields. At a pair of internal nodes, equal hash fields with are a collision by unique decoding (proof of Lemma 3.20); otherwise the children agree as tuples, the leaf subsequences of the left children or of the right children differ, and the descent continues there. Two leaves with equal hash fields do not have different hash-field sequences, so the descent ends at a leaf opposite an internal node. If the leaf is honest, its hash field is for the header of an honest block, and with distinct inputs by hypothesis 2 is a collision. If the leaf is a leaf of , , opposite an honest internal node with children , then , which is the second outcome. The descent takes at most steps. □
The lemma is ePrint 2019/226, Section 5.1 with Corollary 4 (here Corollary 3.18), extended to a block placed at a height other than its own, where the two roots have different leaf counts and hypothesis 2 is needed. It concerns honest blocks placed after the fork point and states nothing about blocks the adversary mines; those are the subject of the next lemma.
Model as a random oracle with -bit outputs (Crypto Guide, §“The random oracle model”), and let at most queries to be made in the experiment, by , by the verification of its output, and by the computation of the prefix root at every position of the output fork after its fork point. Call a query reused if is the header of a block of the output fork after its fork point, records the hash field of the prefix root of the fork at ’s position, and the query precedes the first query whose answer is that recorded value. Then
for an explicit reduction . Consequently, except with that probability, only adversarial work done after the fork’s prefix is fixed counts against the honest chain.
By Construction 5.1 the root recorded in a header after the fork point is the hash field of a tuple over the fork’s prefix; by Proposition 5.3(iii) that tuple is a function of the fork’s root, position and leaf count, barring a collision, which accounts for the term . Its hash field is the answer of a query, made at the latest during that computation. A reused query fixes a recorded value before any query has answer . The first query with answer has an input not queried before, since a repeated input returns an earlier answer; its answer is uniform on and independent of all earlier queries, so it equals one of the at most values recorded in earlier query inputs with probability at most . The union bound over the at most queries (Math Guide, §“The union bound and a birthday calculation”) gives . □
The paper asserts the statement in one sentence (ePrint 2019/226, Section 3.2); the proof above is this volume’s. The bound is in the number of oracle queries, not in the mining rate.
A sampling verifier sees few difficulty transitions, so the transitions it does not see must be constrained by committed aggregates.
The difficulty Merkle mountain range (difficulty MMR) is the instance of Definition 3.19 whose node is the tuple
with a serialisation that concatenates injective fixed-width encodings of the six fields, hence prefix-free. For a block whose header declares target , the leaf map sets
;
, the difficulty level of (Definition 4.2);
the number of rounds between the round recorded by the predecessor of and the round recorded by ( for the genesis block);
the level of the target that Definition 4.5 assigns to the block after ;
.
The parent of and has hash field , over both children’s complete tuples; its fields , and are the sums of the children’s; it inherits from and from .
The fields , , and of a leaf are determined by its header alone and are checked by item (a) of Construction 5.2; the fields and depend on neighbouring blocks and are constrained only by Construction 5.8. The definition makes three precisions against ePrint 2019/226, Definition 7. The paper writes without fixing its input; hashing the children’s hash fields alone would leave their other fields unbound. The paper’s “timestamp” is an elapsed time, and its “targets” , and are difficulty levels. The paper’s checks name fields , and that its Definition 7 never declares; the declared aggregate suffices for every timing check below, so the field set is the declared one. The paper’s data field is omitted, since no check uses it. No encoding of the fields is fixed by the paper.
Let a sample at leaf pass Construction 5.2 against a root with leaf count , the shape being fixed by under . Except with probability for an explicit reduction :
the leaf weight is the difficulty level of the target at which the header’s proof of work is valid;
the interval , with the sum of the fields of the left siblings on the path, is a function of .
(1) Check (a) sets for the declared target , check (d) validates the proof of work at that , and Proposition 5.3(i) and (ii) bind the header and its fields to position . (2) Lemma 3.21(1). Whether equals the true prefix weight is part (2) of that lemma, which holds for a consistent labelling only and is not claimed here. □
Assume, with ePrint 2019/226, Section 6.1, that the retarget-epoch length of Definition 4.5 and the leaf count are powers of two, so that the retarget epochs are the perfect subtrees of altitude . For every parent on a sample’s path, with children and (one of them a carried sibling), the verifier checks:
under Definition 5.6;
;
for each of and , internal consistency:
a node of altitude below lies inside one retarget epoch and has , and unless contains the last block of its epoch;
a node of altitude is one retarget epoch, has , and , the level that Definition 4.5 assigns after an epoch of rounds at level ;
At the sampled leaf the checks (a) and (d) of Construction 5.2 apply; their effect on and is Lemma 5.7. Weight-position check: when a leaf is requested at a point of cumulative weight, , the returned leaf satisfies , with the sum of the fields of the left siblings on its path; this interval is bound to by Lemma 3.21(1). Any failure rejects.
The construction is ePrint 2019/226, Section 6.1 (“Difficulty MMR Verification”); the paper states the weight-position check only informally (Section 2).
Let consecutive retarget epochs have levels , and let , where every retarget obeys the clamp of Definition 4.5, so that . Then:
and, for every ,
for integer with even both envelopes are attained by clamped sequences, so the total weight is maximal when the difficulty is raised by per epoch and then lowered by per epoch to , and minimal when it is lowered first and then raised;
an epoch at target that lowers the difficulty maximally (new target ) lasts rounds, and one that raises it maximally (new target ) lasts rounds.
(1) Since , induction on from epoch gives , and from epoch gives ; at the second bound is . (2) For even the pointwise upper envelope has exponent steps up to and after, and the lower envelope steps up to and after; both are clamped, and the weight is increasing in each . (3) The raw retarget is (§4.2); the clamp is reached from above when and from below when . A script checks the sums against brute force over exponent sequences, and the two thresholds. □
Bounds (2) and (3) are the geometric sums of the envelopes of Proposition 5.9(2); at both reduce to . For (4), forces a maximal raise in each of the epochs, each of at most rounds by Proposition 5.9(3). A script confirms that the closed forms equal the brute-force extremes in all cases with , , and even; at , , they give and per unit of . □
The paper states these checks with and in place of and , which here are the catch parameter and the leaf count (ePrint 2019/226, Section 6.1, pp. 18–19). Three departures are made. The printed lower bound has exponent in place of and is then negative, against the corrected at , , . The printed bounds count one level per epoch, whereas the leaf rule sums per block, so both scale by . The printed upper summation overcounts by at , where its closed form is right. The paper further requires that cover the epochs in which the difficulty is lowered, without a formula, and calls the cases of non-integer and negative “similar” without stating them. The conditions above are necessary, not sufficient: the general feasibility predicate that item 3(c) of Construction 5.8 requires is not given by the paper.
In the model of Definition 4.1, for every adversary that with non-negligible probability outputs a chain accepted by the node checks on every sample, some of whose difficulty transitions violate Definition 4.5, there is an adversary that makes the same number of oracle queries, respects the retarget rule, and with probability at least outputs a chain whose validly mined blocks occupy the same positions as those of .
The assumption is the statement of ePrint 2019/226, Lemma 4, taken as a hypothesis because its proof is a sketch. It handles subtrees whose aggregates are inconsistent with their children, which Lemma 3.21(2) does not cover. The paper’s proof strategy is as follows. Let be the highest node on a claimed path at which the node checks fail. Every path through , or carrying it as a sibling, rejects, so barring a collision every leaf of the subtree under the parent of is unsampleable without rejection. The adversary replaces the transitions inside by clamped ones consistent with the aggregates of the root of , which is possible because that node passes the feasibility check and the leaves of , being invalid, need no proof of work; this is repeated until no invalid transition remains. The paper writes “consistency with ” where the parent of is meant.
(1) The feasibility step presumes a complete feasibility predicate, which the paper gives only in the simplified setting of Proposition 5.10. (2) Rewriting the leaves of changes every later root and hence every later header, so must fix the rewrite before it mines the later valid blocks, and must mine them anew; the paper asserts without a simulation argument that this succeeds with probability at least . (3) “The same valid blocks” holds for positions, not for header contents. Assumption 5.11 is therefore the paper’s claim, not a result of this volume.
Uniform sampling fails on forks near the tip: almost every uniform sample lands before a late fork point, where the two chains agree. If the fork point were known, each sample after it would be invalid with probability at least under Assumption 4.8.
At constant difficulty, over a claimed chain of blocks and with samples per interval, the verifier draws, for every integer with , samples uniformly and independently from the last blocks, and checks every one of the last blocks.
The samples do not depend on the prover’s answers, so the protocol is one-shot and public-coin (Crypto Guide, §“Interactive protocols, proofs, and arguments”). The construction is ePrint 2019/226, Section 5.3, with in place of the paper’s .
Under Assumption 4.8, at constant difficulty, for every fork point and every fork from of more than blocks whose total work after is at least that of the honest chain, the probability that the samples of Construction 5.13 include no invalid block of the fork is at most , except with probability negligible in .
Let the fork point be and choose with . The interval of the last blocks then contains in its first half, so the fork length satisfies , and by Assumption 4.8, at constant difficulty, the interval holds at least invalid blocks. Each of its independent uniform samples misses them with probability at most , and the samples of the other intervals are discarded. A script checks the bound for , and intervals of , and blocks. □
The lemma is ePrint 2019/226, Lemma 2. A fork of at most blocks lies in the checked suffix. When , a fork of blocks with is covered by neither clause, since Assumption 4.8 does not constrain it; the construction is sound for , or with the last blocks checked in full.
The claimed chain is the interval in relative cumulative work: a block whose cumulative-work interval is within total committed work occupies ; genesis is at and the head at . A fork point is a point . By Assumption 4.8 in its operative form, the adversary designates an invalid set of Lebesgue measure at least ; every such is admissible. A sampling density is a probability density on (Math Guide, §“Beyond finite spaces: countable additivity, limits, and densities”). When a suffix is checked in full, a set that meets it in positive measure is caught with probability , and any other is caught by one draw with probability . The single-draw catch probability at is the infimum of these probabilities over admissible . For independent draws (Math Guide, §“Conditional probability and independence”) against a set fixed before the draws, all miss with probability . The design problem is to choose to maximise .
Let be non-decreasing on an interval with , and let . Among measurable of measure , the integral is minimal for . Hence against a density non-decreasing on , with checked in full, an adversary forking at places its valid weight last, and its invalid set is .
With , ; the two sets have equal measure, lies right of and left of it, and is non-decreasing, so the difference is non-negative. A set meeting the suffix in positive measure is caught with certainty, so the adversary’s best set lies in and has the least admissible measure ; it ends at . □
Equal catch probability at every fork point, that is constant in for an antiderivative of , gives on differentiation
The function solves it. With every invalid segment has mass , which is at . The equation fixes only up to a factor periodic in with period . The function is not integrable on , its mass on being , so it is not a density there.
The segment mass is ; a script checks it for and , and the divergence. The construction is ePrint 2019/226, Section 5.4, p. 16.
Fix and ; the suffix is checked in full. The FlyClient sampling density is
Both factors of the denominator are negative, so on its support, and is increasing there; is its distribution function, with . For the invalid segment lies in and has catch probability
which is at . For every admissible invalid set meets the checked suffix in positive measure, and the fork is caught with probability .
Normalisation, and the catch probability are direct integrations. For the last clause, has measure exactly when . A script checks normalisation, and the catch probability for and . The density is ePrint 2019/226, Section 5.4, p. 16; Figure 3 shows it.
Let the head’s root tuple carry committed work , with leaf count . The sampling map sends a uniform to the point , the inverse of at , so that has density ; it sends to the point of cumulative work, and to the leaf whose interval contains . That interval is bound to by Lemma 3.21(1) and is checked by the weight-position check of Construction 5.8. The checked suffix is the set of blocks whose interval meets , together with the last blocks and the head.
For every chain output by an adversary respecting Definition 4.5, and for the fork point of against the honest chain, if has more than blocks after and total work after at least that of the honest chain, then one draw of Definition 5.19 returns an invalid block, or a block on which the per-sample check fails, with probability at least of Definition 5.15 minus a function negligible in ; the draws are independent.
The paper asserts that the continuum analysis “still produces a good distribution for the discrete case” (ePrint 2019/226, Section 5.4) and gives no proof; the hypothesis is named here.
Let , let be real and . Suppose that the suffix is checked in full and that the adversary’s valid weight after any fork point is at most a fraction. Then:
if is an integer, for every sampling density , ;
the density of Construction 5.18 attains , against every placement of the invalid weight.
(1) Tiling. At the fork points , , the placement with valid weight last is available to the adversary against every , and leaves the invalid segment , of measure , inside . These segments tile , so . No monotonicity of is used. (2) The density is increasing on , so for Lemma 5.16 makes the adversary’s best set, whose catch probability is by Construction 5.18; later fork points meet the suffix and are caught with probability . A script checks the tiling masses. □
The theorem is ePrint 2019/226, Theorem 2, pp. 16–17. The paper prints , where at and is undefined; the domain here is . The paper’s proof sums over segments, , the last of which lies in the checked suffix; the range is . The paper’s Lemma 3, a monotonicity lemma, is not needed.
Let . Then independent draws from all miss an optimally placed invalid set with probability at most , and
At constant difficulty with the last blocks checked, and the least such is , which is ; for constant it satisfies
Here is the statistical exponent, not the security parameter.
The proposition is ePrint 2019/226, Section 5.4 (“Optimizing the Proof Size”), p. 17.
At , : one draw suffices in the continuum model, and is undefined, so Proposition 5.22 is stated for . For , and the checked suffix catches every adversary; the paper assumes without loss of generality. For non-integer , Construction 5.18 still gives catch probability and hence the sample bound. The tiling of part (1) of Theorem 5.21 needs integral .
Under variable difficulty the suffix checked in full is the weight fraction , and a sound instantiation makes it contain at least the last blocks, as Definition 5.19 does (Remark 4.10). The length is bounded below by the of the assumption in force and trades against : a larger means a larger , a smaller and fewer samples. The asymptotic size bound holds for constant ; within it, may be chosen numerically. Which holds for Zcash is classified in “The deployment boundary” (§7).
At and , with , the least with is as follows.
| bound | ||||
|---|---|---|---|---|
Every here is non-integer, so Remark 5.23 applies: the counts are sufficient, and their optimality is not claimed.
The parties are a verifier in the setting of Definition 4.16, which knows the genesis block , and provers , at least one of them honest. The parameters are , , a real , and . The ranges are difficulty MMRs (Definition 5.6) committed by Construction 5.1.
Each prover sends its head , whose header records over , together with the two children of the root tuple (for , the single leaf tuple). The verifier recomputes the root tuple with , rejects unless equals the recorded value, and reads and the claimed total work , where is the target the head declares.
If all heads are identical, accepts that head.
Otherwise orders the claims by claimed total work, heaviest first, and for each prover draws independent uniforms, maps each to a point of cumulative work by Definition 5.19, and requests the leaf at each point.
For each requested point the prover returns the header, the leaf tuple and its inclusion path with full node tuples. The sample must pass Construction 5.2, whose checks (a) and (d) require a proof of work valid at a target that the difficulty-MMR fields declare, and Construction 5.8 on every node of its path, including the weight-position check that the drawn point lies in the returned leaf’s interval.
The prover sends the checked suffix of Definition 5.19, and checks it in full: every block passes the per-sample and node checks, and consecutive blocks, the head included, satisfy the linkage and target conditions of Definition 4.14, the target of each block being the one that the field of its predecessor’s leaf declares.
Any failure rejects that prover. Among the surviving claims accepts the heaviest, outputting its head and claimed total work; claims equivalent under Definition 4.15 count as one claim.
The construction is ePrint 2019/226, Algorithms 1 and 2 with Definition 5 and Sections 5.3, 5.4 and 6.1. Step 5 belongs to the protocol by Sections 5.3 and 5.4 of the paper, although its Algorithm 1 omits it. For claims of different weight the paper delegates the comparison to the generic verifier of Kiayias, Miller and Zindros (“Non-interactive proofs of proof-of-work”), which checks the longest claim first; under variable difficulty the order is by claimed total work, as in step 3.
Construction 5.26 is public-coin and one-round: the only message of is its sampling coins, which do not depend on the provers’ answers. The non-interactive protocol applies the Fiat–Shamir transform (Crypto Guide, §“The Fiat–Shamir transform: from interactive to non-interactive”), the challenge hashing the instance. Let be a random oracle (Crypto Guide, §“The random oracle model”); the uniforms are , , read as points of , seeded by the proof-of-work output of the head. Through the head commits to the whole claimed chain.
Prover. It computes from its head and the sampled leaves by Definition 5.19, and sends one message: the head with the root’s children, for each the sampled header, leaf tuple and inclusion path with full node tuples, and the checked suffix.
Verifier. For each proof received it recomputes from the head and runs steps 1 and 4 to 6 of Construction 5.26 on the points they determine.
The paper suggests a standard hash (ePrint 2019/226, Section 6.2) and fixes no domain separation, no map from hash outputs to points and no proof encoding. In the classes of Definition 1.3 the construction is designed but unspecified for Zcash.
During one execution the adversary produces at most heads that carry a valid proof of work.
Assumption 4.8 bounds the validly mined weight of a fork, not the number of head recomputations, and does not imply Assumption 5.28. The paper’s budget (“our security assumption gives a concrete bound on the number of PoW puzzles the adversary can solve, which is ”, ePrint 2019/226, Section 6.2) is asserted, not derived.
Assume Assumptions 5.28, 5.20, 5.11 and 4.8, let be a random oracle, let be the random oracle of Definition 4.1, with -bit outputs, and let . Let at most queries to and queries to be made. The probability that an adversary makes Construction 5.27 accept a claimed chain whose fork is not caught is at most
for an explicit reduction . Hence
suffices for failure probability below plus negligible terms. This is and, at constant difficulty with constant , ; it exceeds the interactive count of Proposition 5.22 by the bits of grinding.
Each head with a valid proof of work fixes, through , the claimed chain and its invalid set before its challenge is known, barring a collision of (Proposition 5.3). The challenge of a header cannot be computed before is queried, and that same query decides validity. Since is independent of , the challenges of the at most valid heads are uniform and independent of which heads are valid, except when was queried at a value before it arose as an -output, which has probability at most . So by Assumption 5.20 and Theorem 5.21 the samples of each valid head all miss with probability at most plus a negligible term. A head without a valid proof of work fails step 5 of Construction 5.26. By Assumption 5.28 at most heads qualify, and the union bound (Math Guide, §“The union bound and a birthday calculation”) gives the bound. The threshold follows on taking logarithms, and its order as in the proof of Proposition 5.22. □
The bound is proved here because the Crypto Guide proves Fiat–Shamir security only for Sigma protocols (§“The Fiat–Shamir transform: from interactive to non-interactive”); the argument above uses only that the challenge is a random-oracle image of the proof-of-work output of a header committing to the whole instance. Seeded by the header itself, the challenge could be evaluated before the proof of work is attempted, and an adversary could mine only heads whose samples miss.
A proof of Construction 5.27 is publicly verifiable: its verification uses only the proof, the genesis block and the public oracles, so any party can relay it unchanged, and it convinces every verifier that the original convinces. For a given head the sampled points are deterministic; under a canonical proof encoding there is therefore one proof per head, which one party can compute for every verifier.
The verifier’s decision is a deterministic function of the proof and public data, and the points are a function of the head. □
The paper’s statement that “there only exists a single valid non-interactive proof” (ePrint 2019/226, Section 8.1) holds only under a canonical encoding, which no ZIP specifies. ZIP 221, “Security and Privacy Considerations” records that, because FlyClient proofs are non-interactive and publicly verifiable, “they could be shared among many light clients after the initial server interaction”.
Assume:
, a real and ;
collision resistant and, as in Definition 4.1, a random oracle, and the sampling oracle a random oracle;
a verifier that knows only the genesis block, and at least one honest prover (Definition 4.16);
no block header equals for node tuples (leaf–internal separation, hypothesis 2 of Lemma 5.4).
Then an adversary wins the game of Definition 4.17 against Construction 5.27 with probability at most plus negligible terms, which is at most plus negligible terms when satisfies Proposition 5.29. Proofs have
headers and hashes, where is the number of blocks of the checked suffix. The construction is succinct (Definition 4.18) whenever , and are , in particular at constant difficulty with constant and , where and ; there, with the paper’s , the size is .
The proof composes the obligations O1 to O6 of Remark 5.33, following the five steps of ePrint 2019/226, Section 6.3. (0) The honest prover’s proof passes every check: its labelling is consistent, its transitions are clamped, and Lemma 3.21(2) makes each weight interval its true prefix weight. (1) Assumption 5.11 replaces an adversary with invalid transitions by one that respects the retarget rule, to which Assumption 4.8 applies (O3). (2) O1 pins every sampled answer to one committed chain; O2 makes every block after the fork point adversarial, or places a leaf of the fork in its invalid set, and makes its validly mined weight post-fork; O3 binds each sampled leaf’s weight interval to the root, while the agreement of that interval with the chain’s true prefix weight rests on the node checks and Assumption 5.11. (3) O4: a fork heavier than the honest chain and longer than blocks is caught by one draw with probability at least , and a fork within the checked suffix with certainty. (4) O5: the Fiat–Shamir step with the grinding bound. (5) O6: the size count. Agreement of honest full nodes on the prefix up to the last blocks, the second clause of Definition 4.17, is Assumption 4.4. □
The theorem is ePrint 2019/226, Theorem 1 (p. 10, restated p. 20); ZIP 221, “Security and Privacy Considerations” restates its honest-connection and genesis hypotheses. The paper states the size as . That equals the constant-difficulty bound above with only when , for instance for polynomial in ; under the convention that grows with fixed, the theorem states the form and no stronger bound.
Each obligation is listed with the results that discharge it.
Multiply by the cost of one sample. The suffix blocks form a contiguous run of leaves ending at leaf , so the union of their paths has nodes and is sent once. □
The corollary is ePrint 2019/226, Corollary 2 (Section 5.4), which states ; the matching lower bound is not proved here.
Theorem 5.32 is the paper’s conditional claim, not an independently completed proof. Deriving the assumption from the backbone parameters is open (Remark 4.13); the paper’s Lemma 1 is invalid as printed (Remark 4.11); its Lemma 4 is a sketch with recorded gaps and enters as Assumption 5.11; the step from the continuum to blocks is Assumption 5.20; and the budget is asserted. Proved in this volume are binding (O1), fork structure (O2) under leaf–internal separation, the binding of sampled weight intervals to the root, optimality, the sample count and the grinding bound.
Let a head with root tuple be accepted. Membership of the block at height in the accepted chain is established by one inclusion path of leaf against , and membership of a transaction in that block by one further Merkle path against the transaction root its header carries; no intermediate header is needed. Both are binding barring a collision.
For the block, Proposition 5.3(i); for the transaction path, Crypto Guide, §“Soundness: forging a path implies a collision”. □
The proposition is ePrint 2019/226, Sections 1 and 4.2.
A client may run the protocol against the freshest heads and store one recent block of its previously accepted chain lying more than blocks below that chain’s head. Let the height of be less than that of the newly accepted head minus . Under the hypotheses of Theorem 5.32, except with its soundness error, the accepted head’s committed range contains at its height, which the client checks by one inclusion path (Proposition 5.36); a head is rejected if a sample exposes an invalid block.
By Theorem 5.32 both accepted chains are equivalent up to their last blocks to chains of honest full nodes. A head commits to heights to , so clause (b) of Definition 4.17 at the earlier round places in every honest chain of that round with its last blocks removed, and Assumption 4.4 places it in every later honest chain. The height of is below that of the new head minus , so lies in the part of the new committed chain that clause (b) makes a prefix of an honest chain. □
The paper states without qualification that the range of a fresh head “cannot contain invalid blocks and it must contain all stable blocks” (ePrint 2019/226, Section 4.2, “Unstable Blocks”); that sentence is not carried.
Assume the hypotheses of Theorem 5.32. Suppose a verifier accepted a valid proof for a chain with head when the honest chain had that head, and later, when the honest chain has head , , receives a subproof for the blocks from to , sampled as an instance of the protocol with in place of genesis, together with one inclusion path showing that lies in the range committed by . Then, except with the soundness error of Theorem 5.32 for the instance from , it accepts no chain that a verifier given a full proof for height would reject. The instance from , which samples only leaves after of a range committed from , is the paper’s design (ePrint 2019/226, Section 8.2) and is not constructed here.
This is ePrint 2019/226, Theorem 3 (Section 8.2), with the paper’s proof idea. A fork after faces a fresh instance of the protocol with as genesis. A fork before fails the inclusion path, since the verifier’s is not in the adversary’s range, barring a collision (Proposition 5.36). □
The proposition concerns one commitment range from the genesis block.