mirror of https://github.com/zcash/orchard.git
Add skeleton of key structure
This commit is contained in:
parent
eb3013f33d
commit
5285737bf0
|
@ -0,0 +1,9 @@
|
||||||
|
use crate::{keys::Diversifier, Chain};
|
||||||
|
|
||||||
|
/// A shielded payment address.
|
||||||
|
#[derive(Debug)]
|
||||||
|
pub struct Address<C: Chain> {
|
||||||
|
chain: C,
|
||||||
|
d: Diversifier<C>,
|
||||||
|
pk_d: (),
|
||||||
|
}
|
|
@ -0,0 +1,123 @@
|
||||||
|
//! Key structures for Orchard.
|
||||||
|
//!
|
||||||
|
//! TODO: Should we have the concept of a Network here? Or make these standalone without
|
||||||
|
//! defined string encodings, and use newtypes in Zcash?
|
||||||
|
//! - The latter might get messy, but would maintain the crate abstraction.
|
||||||
|
//! - One approach might be to make all these types take a type parameter that provides
|
||||||
|
//! encoding and decoding support, and then instantiate it in Zcash inside newtypes.
|
||||||
|
//! - We will need to encode some decisions here (like the size of the diversifier), which
|
||||||
|
//! depend on the encoding, so another alternative is we just require Bech32 and then
|
||||||
|
//! have the constrained type provide the HRP.
|
||||||
|
|
||||||
|
use std::marker::PhantomData;
|
||||||
|
|
||||||
|
use crate::{address::Address, Chain};
|
||||||
|
|
||||||
|
/// A spending key, from which all key material is derived.
|
||||||
|
///
|
||||||
|
/// TODO: In Sapling we never actually used this, instead deriving everything via ZIP 32,
|
||||||
|
/// so that we could maintain Bitcoin-like HD keys with properties like non-hardened
|
||||||
|
/// derivation. If we decide that we don't actually require non-hardened derivation, then
|
||||||
|
/// we could greatly simplify the HD structure and use this struct directly.
|
||||||
|
#[derive(Debug)]
|
||||||
|
pub struct SpendingKey<C: Chain>(PhantomData<C>);
|
||||||
|
|
||||||
|
#[derive(Debug)]
|
||||||
|
pub(crate) struct SpendAuthorizingKey<C: Chain>(PhantomData<C>);
|
||||||
|
|
||||||
|
impl<C: Chain> From<&SpendingKey<C>> for SpendAuthorizingKey<C> {
|
||||||
|
fn from(_: &SpendingKey<C>) -> Self {
|
||||||
|
todo!()
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
/// TODO: This is its protocol spec name for Sapling, but I'd prefer a different name.
|
||||||
|
#[derive(Debug)]
|
||||||
|
pub(crate) struct AuthorizingKey<C: Chain>(PhantomData<C>);
|
||||||
|
|
||||||
|
impl<C: Chain> From<&SpendAuthorizingKey<C>> for AuthorizingKey<C> {
|
||||||
|
fn from(_: &SpendAuthorizingKey<C>) -> Self {
|
||||||
|
todo!()
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
#[derive(Debug)]
|
||||||
|
pub(crate) struct NullifierDerivingKey<C: Chain>(PhantomData<C>);
|
||||||
|
|
||||||
|
impl<C: Chain> From<&SpendingKey<C>> for NullifierDerivingKey<C> {
|
||||||
|
fn from(_: &SpendingKey<C>) -> Self {
|
||||||
|
todo!()
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
/// A key that provides the capability to recover outgoing transaction information from
|
||||||
|
/// the block chain.
|
||||||
|
#[derive(Debug)]
|
||||||
|
pub struct OutgoingViewingKey<C: Chain>(PhantomData<C>);
|
||||||
|
|
||||||
|
impl<C: Chain> From<&SpendingKey<C>> for OutgoingViewingKey<C> {
|
||||||
|
fn from(_: &SpendingKey<C>) -> Self {
|
||||||
|
todo!()
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
/// A key that provides the capability to view incoming and outgoing transactions.
|
||||||
|
///
|
||||||
|
/// This key is useful in situations where you only need the capability to detect inbound
|
||||||
|
/// payments, such as merchant terminals.
|
||||||
|
///
|
||||||
|
/// This key is not suitable for use in a wallet, as it cannot maintain accurate balance.
|
||||||
|
/// You should use a [`FullViewingKey`] instead.
|
||||||
|
///
|
||||||
|
/// TODO: Should we just define the FVK to include extended stuff like the diversifier key?
|
||||||
|
#[derive(Debug)]
|
||||||
|
pub struct FullViewingKey<C: Chain> {
|
||||||
|
ak: AuthorizingKey<C>,
|
||||||
|
nk: NullifierDerivingKey<C>,
|
||||||
|
ovk: OutgoingViewingKey<C>,
|
||||||
|
}
|
||||||
|
|
||||||
|
impl<C: Chain> From<&SpendingKey<C>> for FullViewingKey<C> {
|
||||||
|
fn from(_: &SpendingKey<C>) -> Self {
|
||||||
|
todo!()
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
impl<C: Chain> FullViewingKey<C> {
|
||||||
|
/// Returns the payment address for this key corresponding to the given diversifier.
|
||||||
|
pub fn address(&self, d: Diversifier<C>) -> Address<C> {
|
||||||
|
IncomingViewingKey::from(self).address(d)
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
/// A diversifier that can be used to derive a specific [`Address`] from a
|
||||||
|
/// [`FullViewingKey`] or [`IncomingViewingKey`].
|
||||||
|
//
|
||||||
|
// This is a newtype around a `u128` for simplicity, and enforces the diversifier size
|
||||||
|
// during all operations.
|
||||||
|
#[derive(Debug)]
|
||||||
|
pub struct Diversifier<C: Chain>(u128, PhantomData<C>);
|
||||||
|
|
||||||
|
/// A key that provides the capability to detect and decrypt incoming notes from the block
|
||||||
|
/// chain, without being able to spend the notes or detect when they are spent.
|
||||||
|
///
|
||||||
|
/// This key is useful in situations where you only need the capability to detect inbound
|
||||||
|
/// payments, such as merchant terminals.
|
||||||
|
///
|
||||||
|
/// This key is not suitable for use in a wallet, as it cannot maintain accurate balance.
|
||||||
|
/// You should use a [`FullViewingKey`] instead.
|
||||||
|
#[derive(Debug)]
|
||||||
|
pub struct IncomingViewingKey<C: Chain>(PhantomData<C>);
|
||||||
|
|
||||||
|
impl<C: Chain> From<&FullViewingKey<C>> for IncomingViewingKey<C> {
|
||||||
|
fn from(_: &FullViewingKey<C>) -> Self {
|
||||||
|
todo!()
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
impl<C: Chain> IncomingViewingKey<C> {
|
||||||
|
/// Returns the payment address for this key corresponding to the given diversifier.
|
||||||
|
pub fn address(&self, _: Diversifier<C>) -> Address<C> {
|
||||||
|
todo!()
|
||||||
|
}
|
||||||
|
}
|
12
src/lib.rs
12
src/lib.rs
|
@ -6,3 +6,15 @@
|
||||||
#![deny(missing_debug_implementations)]
|
#![deny(missing_debug_implementations)]
|
||||||
#![deny(missing_docs)]
|
#![deny(missing_docs)]
|
||||||
#![deny(unsafe_code)]
|
#![deny(unsafe_code)]
|
||||||
|
|
||||||
|
mod address;
|
||||||
|
pub mod keys;
|
||||||
|
|
||||||
|
pub use address::Address;
|
||||||
|
|
||||||
|
/// Chain-specific constants and constraints for Orchard.
|
||||||
|
///
|
||||||
|
/// The purpose of this trait is to encapsulate things like the human-readable prefixes
|
||||||
|
/// for encoded addresses, or the range of allowable values for notes.
|
||||||
|
pub trait Chain {
|
||||||
|
}
|
||||||
|
|
Loading…
Reference in New Issue