Crate xand_ledger
source ·Expand description
This crate defines our domain models and logic for the xand ledger. IE: This is the code that determines how transactions are validated/processed, as well as the shape of those transactions. It is free of major dependencies and should remain so to provide a clean environment for concentrating on domain code.
Practically speaking this code is consumed in other places for two purposes:
- Validating transactions (within the substrate runtime)
- Constructing transactions (everywhere else)
The crate has an std
feature that is enabled by default. Disabling the feature allows the
crate to compile in no-std mode. The substrate runtime requires this, and no-std support must
be maintained.
Re-exports
pub use curve25519_dalek;
Modules
- Zero Knowledge Implementation
Structs
- Issued by the trust to confirm a pending create request
- A clear (non-confidential) redeem request transaction
- Compact representation of the verifiable signer encryption. Useful to store the encrypted values after proofs have already been verified.
- Encapsulates all the fields of the create request transaction except the signature.
- Encapsulates all the details of a
ExitingRedeemRequestTransaction
other than the proof with signature. - Encapsulates all the details of a
RedeemRequestTransaction
other than the proof with signature. - The CoreTransaction contains all the details of a Transaction except the signature and proof. A serialized version of the CoreTransaction is then signed as part of the main proof. A Transaction contains a CoreTransaction and a proof cum signature.
- Issued by the trust (or intrinsically) to cancel an outstanding create request
- A collection of repositories that when combined are capable of processing create requests, and implement CreateRequestHandler
- A record of a confidential pending create request - a user does not submit this directly, rather it is created and stored as a result of processing a create request transaction.
- A create request, as issued by a member
- All the (nonrandom) inputs required to construct a CreateRequestTransaction
- A Encryption key representing the public portion of some private key, and hence a (potential) sender or receiver of encrypted messages.
- An exiting redeem request transaction
- An piece of info that identifies an entity as a verified participant. Each (applicable) transaction must include one such valid tag (mixed among decoys).
- There is a unique key-image for every TransactionOutput, but the key-image cannot be efficiently matched with the corresponding TransactionOutput by any polynomial time probabilistic algorithm with a non-negligible probability without using the private key. If a Transaction contains a key-image that has already been used, then the corresponding TransactionOutput has been spent already, which means that the transaction is invalid.
- Milliseconds - often used as millis since epoch to form a timestamp
- Error type specifying that a public key cannot be derived from Identity Tag
- Represents a public key that is specific to an individual txo
- An
OpenedTransactionOutput
represents a UTXO and the information needed to reveal/open it. - Inputs for a participant issuing an exiting redeem request
- Inputs for a participant issuing a redeem request
- A cryptographic public key representing a public identity
- Issued by the trust (or intrinsically) to cancel an outstanding redeem request
- Issued by the trust to confirm a redeem fulfillment
- A redeem request transaction
- Transfer TxO and associated data
- A send claims transaction representing the transfer of value from one registered member to another
- A collection of TransactionOutput(s). The are used in a transaction as a collection of inputs that are summed up to make the total value of the transaction. A transaction includes multiple
TransactionInputSet
s, only one of which is the realTransactionInputSet
being spent. - A transaction output, or TXO, represents a commitment to some value, and information about who owns the right to spend that value (claims).
Enums
- State of banned member
- Expresses reasons a correlation id is already used. Is returned by CorrelationIdRepository::is_used
- The reason a create request was cancelled
- Failures that may occur during transaction validation
- All transactions in
xand_ledger
- The reason a redeem request was cancelled
- The status of a TransactionOutput
Traits
- Provides access to info about the currently executing/processing block
- Implementors are capable of processing cash confirmation transactions
- Implementors are capable of processing clear redeem request transactions
- Provides access to information stored in the ledger regarding ClearTransactionOutputs
- Provides access to information stored in the ledger regarding CorrelationIds
- Implementors are capable of processing create cancellation transactions
- Implementors are capable of processing create request transactions
- Provides access to and storage of info in the ledger about pending create requests in the form of CreateRequestRecords
- A dispatcher is capable of accepting transactions and executing them. This functionality is important because sometimes you would like a transaction to “happen” as a result of processing another transaction, or simply periodically (ex: every block). This mechanism allows us to ensure the other transaction is counted as a proper transaction - and not just an identical modification of state (IE: It shows up as it’s own transaction in the block).
- Provides access to information stored in the ledger regarding IdentityTags
- Provides access to information stored in the ledger regarding KeyImages
- Trait for managing the storage of member data
- Provides access to configurable expiration time for pending create requests
- Implementors are capable of processing redeem cancellation transactions
- Implementors are capable of processing redeem fulfillment transactions
- Implementors are capable of processing redeem request transactions
- Provides access to and storage of info in the ledger about pending unfulfilled redeem requests in the form of RedeemRequestRecords
- Implementors are capable of processing reward transactions
- Implementors are capable of processing send claims transactions
- Trait for tracking the current total number of claims
- Provides access to information stored in the ledger regarding TransactionOutputs
- Provides access to the metadata about the trust. Specifically, it gives access to the public key of the trust.
- Trait for managing the storage of validator data
Functions
- Returns whether the identity tag matches the private key
- Given a TransactionOutput, check whether it is owned by the private key provided.
- Builds a create request
- Determine the PublicKey associated with a given OneTimeKey. The OneTimeKey is derived using the message body, the txo index, and the message sender’s private key to form a random value that is only reproducible for the sender.
- Find row in
inputs
that matches the givenkey_images
andprivate_key
.
Type Definitions
- A block number
- A unique identifier to associate an on-chain transaction with some real-world event, for now, a cash transfer at a Xand-Enabled Bank.
- Some blob of binary data that has been encrypted
- A private key, as held by a transaction signer / creator.
- The result of processing/validating a transaction