zec
/
orchard
mirror of https://github.com/zcash/orchard.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
orchard/src/note.rs

35 lines
746 B
Rust
Raw Normal View History

Remove Chain and value::Constraint traits There was push-back on having this crate require these traits, due to the additional complexity within this crate. My rationale for including them was to make it simpler to reason about what is responsible for enforcing chain-specific constraints, and to reduce duplication (by enabling the wrapping chain implementation to use type definitions and leverage all built-in behaviour, instead of newtypes and needing to add a bunch of wrapping logic and boilerplate, some of which would encode chain-specific logic). We'll try working within the requirement that this crate enforces minimal base constraints and hard-codes any constants, and then have the wrapping chain provide encoding prefixes and additional value constraints where necessary.
2021-01-21 04:16:50 -08:00
use crate::{keys::FullViewingKey, value::NoteValue, Address};
Skeleton for notes and values
2021-01-20 12:09:09 -08:00
/// A discrete amount of funds received by an address.
#[derive(Debug)]
Remove Chain and value::Constraint traits There was push-back on having this crate require these traits, due to the additional complexity within this crate. My rationale for including them was to make it simpler to reason about what is responsible for enforcing chain-specific constraints, and to reduce duplication (by enabling the wrapping chain implementation to use type definitions and leverage all built-in behaviour, instead of newtypes and needing to add a bunch of wrapping logic and boilerplate, some of which would encode chain-specific logic). We'll try working within the requirement that this crate enforces minimal base constraints and hard-codes any constants, and then have the wrapping chain provide encoding prefixes and additional value constraints where necessary.
2021-01-21 04:16:50 -08:00
pub struct Note {
Skeleton for notes and values
2021-01-20 12:09:09 -08:00
/// The recipient of the funds.
Remove Chain and value::Constraint traits There was push-back on having this crate require these traits, due to the additional complexity within this crate. My rationale for including them was to make it simpler to reason about what is responsible for enforcing chain-specific constraints, and to reduce duplication (by enabling the wrapping chain implementation to use type definitions and leverage all built-in behaviour, instead of newtypes and needing to add a bunch of wrapping logic and boilerplate, some of which would encode chain-specific logic). We'll try working within the requirement that this crate enforces minimal base constraints and hard-codes any constants, and then have the wrapping chain provide encoding prefixes and additional value constraints where necessary.
2021-01-21 04:16:50 -08:00
recipient: Address,
Skeleton for notes and values
2021-01-20 12:09:09 -08:00
/// The value of this note.
Remove Chain and value::Constraint traits There was push-back on having this crate require these traits, due to the additional complexity within this crate. My rationale for including them was to make it simpler to reason about what is responsible for enforcing chain-specific constraints, and to reduce duplication (by enabling the wrapping chain implementation to use type definitions and leverage all built-in behaviour, instead of newtypes and needing to add a bunch of wrapping logic and boilerplate, some of which would encode chain-specific logic). We'll try working within the requirement that this crate enforces minimal base constraints and hard-codes any constants, and then have the wrapping chain provide encoding prefixes and additional value constraints where necessary.
2021-01-21 04:16:50 -08:00
value: NoteValue,
Skeleton for notes and values
2021-01-20 12:09:09 -08:00
}
Remove Chain and value::Constraint traits There was push-back on having this crate require these traits, due to the additional complexity within this crate. My rationale for including them was to make it simpler to reason about what is responsible for enforcing chain-specific constraints, and to reduce duplication (by enabling the wrapping chain implementation to use type definitions and leverage all built-in behaviour, instead of newtypes and needing to add a bunch of wrapping logic and boilerplate, some of which would encode chain-specific logic). We'll try working within the requirement that this crate enforces minimal base constraints and hard-codes any constants, and then have the wrapping chain provide encoding prefixes and additional value constraints where necessary.
2021-01-21 04:16:50 -08:00
impl Note {
Skeleton for notes and values
2021-01-20 12:09:09 -08:00
/// Derives the commitment to this note.
pub fn commitment(&self) -> NoteCommitment {
todo!()
}
/// Derives the nullifier for this note.
Remove Chain and value::Constraint traits There was push-back on having this crate require these traits, due to the additional complexity within this crate. My rationale for including them was to make it simpler to reason about what is responsible for enforcing chain-specific constraints, and to reduce duplication (by enabling the wrapping chain implementation to use type definitions and leverage all built-in behaviour, instead of newtypes and needing to add a bunch of wrapping logic and boilerplate, some of which would encode chain-specific logic). We'll try working within the requirement that this crate enforces minimal base constraints and hard-codes any constants, and then have the wrapping chain provide encoding prefixes and additional value constraints where necessary.
2021-01-21 04:16:50 -08:00
pub fn nullifier(&self, _: &FullViewingKey) -> Nullifier {
Skeleton for notes and values
2021-01-20 12:09:09 -08:00
todo!()
}
}
/// An encrypted note.
#[derive(Debug)]
pub struct EncryptedNote;
/// A commitment to a note.
#[derive(Debug)]
pub struct NoteCommitment;
/// A unique nullifier for a note.
#[derive(Debug)]
pub struct Nullifier;