mirror of https://github.com/zcash/halo2.git
book: Document design rationale for Orchard keys and addresses
This commit is contained in:
parent
6c14880baf
commit
adb377de7d
|
@ -9,6 +9,7 @@
|
|||
- [Spending notes](user/spending-notes.md)
|
||||
- [Integration into an existing chain](user/integration.md)
|
||||
- [Design](design.md)
|
||||
- [Keys and addresses](design/keys.md)
|
||||
- [Actions](design/actions.md)
|
||||
- [Commitments](design/commitments.md)
|
||||
- [Commitment tree](design/commitment-tree.md)
|
||||
|
|
|
@ -20,21 +20,6 @@
|
|||
- Need to consider the privacy issue related to light clients requesting individual
|
||||
memos vs being able to fetch all memos.
|
||||
|
||||
### Key structure
|
||||
|
||||
Provisional proposal: exactly the same key structure as Sapling.
|
||||
|
||||
Group hashing uses the isogeny.
|
||||
|
||||
- nsk goes away; `nk` is now a field element
|
||||
- TODO: ak / nk split enables splitting the security argument, but could consider merging.
|
||||
Merging would help with ivk derivation perf (though as a commitment now it's pretty cheap)
|
||||
|
||||
ZIP 32 integration
|
||||
- Use same Sapling design?
|
||||
- Simpler "hardened-only" derivation structure?
|
||||
- Improve diversifier integration / documentation
|
||||
|
||||
### Note structure
|
||||
|
||||
- TODO: UDAs: arbitrary vs whitelisted
|
||||
|
|
|
@ -0,0 +1,86 @@
|
|||
# Keys and addresses
|
||||
|
||||
Orchard keys and payment addresses are structurally similar to Sapling. The main change is
|
||||
that Orchard keys use the Pallas curve instead of Jubjub, in order to enable the future
|
||||
use of the Pallas-Vesta curve cycle in the Orchard protocol. This involves corresponding
|
||||
changes to the key derivation process (such as using Sinsemilla for Pallas-efficient
|
||||
commitments).
|
||||
|
||||
We also make several structural changes, building on the lessons learned from Sapling:
|
||||
|
||||
- The nullifier private key $\mathsf{nsk}$ is removed. Its purpose in Sapling was as
|
||||
defense-in-depth, in case RedDSA was found to have weaknesses; an adversary who could
|
||||
recover $\mathsf{ask}$ would not be able to spend funds. In practice it has not been
|
||||
feasible to manage $\mathsf{nsk}$ much more securely than a full viewing key, as the
|
||||
computational power required to generate Sapling proofs has made it necessary to perform
|
||||
this step on the same device that is creating the overall transaction (rather than on a
|
||||
more constrained device like a hardware wallet). We are also more confident in RedDSA
|
||||
now.
|
||||
|
||||
- $\mathsf{nk}$ is now a field element instead of a curve point, making it more efficient
|
||||
to generate nullifiers.
|
||||
|
||||
- $\mathsf{ovk}$ is now derived from $\mathsf{fvk}$, instead of being derived in parallel.
|
||||
This places it in a similar position within the key structure to $\mathsf{ivk}$, and
|
||||
also removes an issue where two full viewing keys could be constructed that have the
|
||||
same $\mathsf{ivk}$ but different $\mathsf{ovk}$s. Users still have control over whether
|
||||
$\mathsf{ovk}$ is used when constructing a transaction.
|
||||
|
||||
- All diversifiers now result in valid payment addresses, due to group hashing into Pallas
|
||||
being specified to be infallible. This removes significant complexity from the use cases
|
||||
for diversified addresses.
|
||||
|
||||
Other than the above, Orchard retains the same design rationale for its keys and addresses
|
||||
as Sapling. For example, diversifiers remain at 11 bytes, so that Orchard addresses are
|
||||
the same length as Sapling addresses.
|
||||
|
||||
## Hierarchical deterministic wallets
|
||||
|
||||
When designing Sapling, we defined a [BIP 32]-like mechanism for generating hierarchical
|
||||
deterministic wallets in [ZIP 32]. We decided at the time to stick closely to the design
|
||||
of BIP 32, on the assumption that there were Bitcoin use cases that used both hardened and
|
||||
non-hardened derivation that we might not be aware of. This decision created significant
|
||||
complexity for Sapling: we needed to handle derivation separately for each component of
|
||||
the expanded spending key and full viewing key (whereas for transparent addresses there is
|
||||
only a single component in the spending key).
|
||||
|
||||
Non-hardened derivation enables creating a multi-level path of child addresses below some
|
||||
parent address, without involving the parent spending key. The primary use case for this
|
||||
is HD wallets for transparent addresses, which use the following structure defined in
|
||||
[BIP 44]:
|
||||
|
||||
- (H) BIP 44
|
||||
- (H) Coin type: Zcash
|
||||
- (H) Account 0
|
||||
- (N) Normal addresses
|
||||
- (N) Address 0
|
||||
- (N) Address 1...
|
||||
- (N) Change addresses
|
||||
- (N) Change address 0
|
||||
- (N) Change address 1...
|
||||
- (H) Account 1...
|
||||
|
||||
Shielded accounts do not require separating change addresses from normal addresses, due to
|
||||
addresses not being revealed in transactions. Similarly, there is also no need to generate
|
||||
a fresh spending key for every transaction, and in fact this causes a linear slow-down in
|
||||
wallet scanning. But for users that do want to generate multiple addresses per account,
|
||||
they can generate the following structure, which does not use non-hardened derivation:
|
||||
|
||||
- (H) ZIP 32
|
||||
- (H) Coin type: Zcash
|
||||
- (H) Account 0
|
||||
- Diversified address 0
|
||||
- Diversified address 1...
|
||||
- (H) Account 1...
|
||||
|
||||
Non-hardened derivation is therefore only required for use-cases that require the ability
|
||||
to derive more than one child layer of addresses. However, in the years since Sapling was
|
||||
deployed, we have not seen *any* such use cases appear.
|
||||
|
||||
Therefore, for Orchard we only define hardened derivation, and do so with a much simpler
|
||||
design that ZIP 32. All derivations produce an opaque binary spending key, from which the
|
||||
keys and addresses are then derived.
|
||||
|
||||
[BIP 32]: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki
|
||||
[BIP 44]: https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki
|
||||
[ZIP 32]: https://zips.z.cash/zip-0032
|
Loading…
Reference in New Issue