[ZIP 221] FlyClient - Consensus-Layer Changes #220
Conversation
daira
changed the title
daira
changed the title
daira
changed the title
zip-0311.rst
Outdated
| An event occurs with high probability if it occurs with probability 1-O(1/2^λ), where λ is the security parameter. | ||
|
|
||
| Negligible probability | ||
| An event occurs with negligible probability if it occurs with probability O(1/2^λ), where λ is the security parameter. |
There was a problem hiding this comment.
It isn't clear what the security parameter actually is in the instantiation. I suggest doing a concrete security analysis in the Rationale section. In any case this is enough for a draft.
zip-0311.rst
Outdated
|
|
||
| Verifier | ||
| ````````` | ||
| **Verifying a valid chain**: the hash of the block B_n at the head of the chain specifies a random subset of blocks to sample. If the PoW solution or the MMR proofs of any of the sampled blocks is invalid, then the verifier rejects the proof. Otherwise, it accepts B_n as the last block of the honest chain. |
There was a problem hiding this comment.
This would need to specify the sampled subset. Again, it's enough for a draft.
There was a problem hiding this comment.
Specifying the consensus rule changes is IMO more important than specifying the concrete light client strategy. You certainly need to convince readers that a good light client strategy that is enabled by the consensus rule changes exists, but it's not as important that an exact specific one is fully nailed down, that's a discussion that can easily be done even after the network upgrade.
There was a problem hiding this comment.
@daira and I agree with you, but would like to have more of a discussion about the possible strategies prior to the network upgrade. Not all of those details need to be in the ZIP, but they serve as a valuable sanity check.
|
What are the advantages of this compared to another compression tool such as Coda? |
|
Roughly: It's simpler, but it only provides "SPV" security for the light clients. Coda provides full security for light clients (but needs significant adaptation to be applicable to Zcash; Coda itself depends on account states being public). |
zip-0311.rst
Outdated
|
|
||
| Abstract | ||
| ======== | ||
| A proposed implementation of the probabilistic verification FlyClient protocol [#FlyClient]_ on top of the existing ZCash reference light client protocol [#ZIPXXX]_. This can be implemented with a hard fork to include a MMR proof in each block header. |
There was a problem hiding this comment.
| A proposed implementation of the probabilistic verification FlyClient protocol [#FlyClient]_ on top of the existing ZCash reference light client protocol [#ZIPXXX]_. This can be implemented with a hard fork to include a MMR proof in each block header. | |
| This proposal defines modifications to the Zcash block header format and consensus rules | |
| in order to support the probabilistic verification FlyClient protocol [#FlyClient]_ on top | |
| of the existing Zcash reference light client protocol [#zip-0307]_. |
zip-0311.rst
Outdated
|
|
||
| .. [#ZIPXXX] `ZCash reference light client protocol <https://github.com/gtank/zips/blob/light_payment_detection/zip-XXX-light-payment-detection.rst>` | ||
|
|
||
| .. [#PeterTodd] _`Merkle Mountain Range <https://github.com/proofchains/python-proofmarshal/blob/master/proofmarshal/mmr.py>` |
There was a problem hiding this comment.
| .. [#PeterTodd] _`Merkle Mountain Range <https://github.com/proofchains/python-proofmarshal/blob/master/proofmarshal/mmr.py>` | |
| .. [#MerkleMR] _`Merkle Mountain Ranges <https://github.com/opentimestamps/opentimestamps-server/blob/master/doc/merkle-mountain-range.md>`_ |
zip-0311.rst
Outdated
| An event occurs with negligible probability if it occurs with probability O(1/2^λ), where λ is the security parameter. | ||
|
|
||
| Merkle mountain range (MMR) | ||
| A Merkle mountain range (MMR) is binary hash tree that allows for efficient appends of new leaves without changing the value of existing nodes [#PeterTodd]_. |
There was a problem hiding this comment.
| A Merkle mountain range (MMR) is binary hash tree that allows for efficient appends of new leaves without changing the value of existing nodes [#PeterTodd]_. | |
| A Merkle mountain range (MMR) is binary hash tree that allows for efficient appends of new leaves without changing the value of existing nodes [#MerkleMR]_. |
There was a problem hiding this comment.
Having looked at the Merkle mountain range specification, it is very similar to the incremental Merkle tree that we use for Sprout and Sapling. The primary difference appears to be that the root of our incremental Merkle tree is computed by explicitly filling empty nodes with an unusable value (because we can't have the shape of the tree changing inside the circuit), while the MMR root is constructed almost directly from the roots of its subtrees (which is slightly more efficient, but can't be easily represented within a circuit).
We should think about whether we might want to leverage this new tree of block headers in some future circuit. Would there be a benefit in being able to prove in zero knowledge that some past block contained a particular public value, without revealing which block it was? I'm not sure it's useful without having a circuit-friendly block header construction, and we could probably switch from MMR to a circuit-friendly tree in the future if necessary, but if there's a concrete use case that this could service, we might want to consider replacing the MMR with a circuit-friendly tree from the start.
I haven't confirmed yet whether the FlyClient protocol would still work with an incremental Merkle tree instead of MMR, but it looks like the only change would be an efficiency loss due to the number of empty nodes, which are bounded on log (n) (because like MMR, an incremental Merkle tree is filled densely from the left-hand side).
|
@zmanian Would you be willing to review and provide comments on this ZIP next week? |
|
@vbuterin Would you be willing to review and provide comments on this ZIP sometime this week? |
This comment has been minimized.
This comment has been minimized.
|
@gmaxwell wrote:
The structure now called Merkle Mountain Ranges was not first invented by Peter Todd. It was originally invented in the context of the Certificate Transparency protocol, as Todd's writings correctly acknowledge: https://tools.ietf.org/html/rfc6962 (that RFC in turn references a 2009 paper on "history trees" by Crosby and Wallach describing essentially the same structure, with some minor differences). I agree there should be an acknowledgement to Peter Todd for his subsequent work in implementing and popularising them. The replacement reference that @str4d suggests is still written by Todd; in any case, accurate specification of the precise variant used is what is important here. Note that references in ZIPs are typically named by content and not author(s). In general, the Zcash project has a strong culture of properly acknowledging sources. Any omission in that regard is an oversight that we will correct. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
I'd advocate against prioritizing FlyClient compatibility in the immediate future. Here are my reasons:
|
On the other hand, immaturity means the field is wide open. Zcash has avoided getting locked into Electrum/Stratum like most other chains. FlyClient proofs have the added zcash-specific advantage of giving each validator a sampling of historical headers (and therefore commitment tree anchors) from the chain history.
Has any significant PoW chain adopted a finality gadget? Is there a compelling reason for Zcash to be among the first? Zcash arguably has stronger social finality guarantees than other PoW chains, due to its strong developer influence and the danger of long reorgs to the shielded commitment trees and expiring transactions.
Is there a slashable oracle model for chains that don't support fraud proofs? |
|
For the record, I've read this ZIP and all of the comments up to here. |
zip-0311.rst
Outdated
|
|
||
| Schematic of Merkle mountain range (from [#FlyClient]_). | ||
|
|
||
| The MMR structure allows for subchain proofs. Consider a client who has already received a verified a proof for a chain of n blocks. When it later receives k new blocks, it need only verify that the new section of length k is honest, as well as that the old chain is a prefix of the new chain. |
There was a problem hiding this comment.
Maybe this is an aesthetic difference between the zcash and ethereum communities but it would be nice to see a formal description of exactly what this entails. I don't necessarily mean Latex or Coq, just a python function def get_mmr_values(prev_mmr_values: List[Bytes32], block_hash: Bytes32) -> Bytes32 with the code. Maybe this code that I wrote a few months ago does the same thing? https://github.com/ethereum/research/blob/master/beacon_chain_impl/progressive_merkle_tree.py#L12
There was a problem hiding this comment.
In general: it's only strictly necessary to specify the rules needed for consensus conformance. (Another example of this is that the protocol spec specifies Equihash validation, but not how to construct Equihash proofs.) There's no objection to discussing anything else that is useful, though. Thanks for the code reference.
|
This ZIP has undergone major changes. It now specifies consensus rule changes for the MMR commitment |
daira
force-pushed
the
master
branch
4 times, most recently
from
e5c7413
to
5711fc1
Compare
The pseudocode is Python-esque, so snake_case makes sense for other variables, but as the pseudocode is intended for specification clarity it should defer to the specification's naming scheme.
This addresses finding NCC-1908_Zcash-001.
This addresses finding NCC-1908_Zcash-002.
Figures should be stored in a subdirectory, but the source files for the figures have not been provided, and one of the figures contains an error.
People in the Original-Authors field are not contact points for a ZIP.
"Height" is used elsewhere in the ZIP to refer to block heights.
Co-Authored-By: Daira Hopwood <daira@jacaranda.org>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
A proposed implementation of the probabilistic verification FlyClient protocol on top of the existing ZCash reference light client protocol. This can be implemented with a hard fork to include a Merkle Mountain Range proof in each block header.