Module akd_client::types

This module contains all of the structs which need to be constructed to verify any of the following AKD proofs

1. Lookup 2: Key history 3: Audit (append-only)

Modules

• node_label
  This module contains the specifics for NodeLabel only, other types don’t have the same level of detail and aren’t broken into sub-modules

Structs

• AkdLabel
  The label of a particular entry in the AKD
• AkdValue
  The value of a particular entry in the AKD
• AppendOnlyProof
  Proof that no leaves were deleted from the initial epoch. This is done using a list of SingleAppendOnly proofs, one proof for each epoch between the initial epoch and final epochs which are being audited.
• AzksElement
  Represents an element to be inserted into the AZKS. This is a pair consisting of a label (NodeLabel) and a value. The purpose of the directory publish is to convert an insertion set of (AkdLabel, AkdValue) tuples into a set of AzksElements, which are then inserted into the AZKS.
• AzksValue
  The value associated with an element of the AZKS
• AzksValueWithEpoch
  Used to denote an azks value that has been hashed together with an epoch
• HistoryProof
  This proof is just an array of UpdateProofs.
• LookupProof
  Proof that a given label was at a particular state at the given epoch. This means we need to show that the state and version we are claiming for this node must have been:
• MembershipProof
  Merkle proof of membership of a NodeLabel with a particular hash value in the tree at a given epoch
• NodeLabel
  Represents the label of a AKD node
• NonMembershipProof
  Merkle Patricia proof of non-membership for a NodeLabel in the tree at a given epoch.
• SiblingProof
  Represents a specific level of the tree with the parental sibling and the direction of the parent for use in tree hash calculations
• SingleAppendOnlyProof
  Proof that no leaves were deleted from the initial epoch. This means that unchanged_nodes should hash to the initial root hash and the vec of inserted is the set of leaves inserted between these epochs. If we built the tree using the nodes in inserted and the nodes in unchanged_nodes as the leaves with the correct epoch of insertion, it should result in the final root hash.
• UpdateProof
  A vector of UpdateProofs are sent as the proof to a history query for a particular key. For each version of the value associated with the key, the verifier must check that:
• VerifyResult
  The payload that is outputted as a result of successful verification of a LookupProof or HistoryProof. This includes the fields containing the epoch that the leaf was published in, the version corresponding to the value, and the value itself.

Enums

• Direction
  This type is used to indicate a direction for a particular node relative to its parent. We use 0 to represent “left” and 1 to represent “right”.
• PrefixOrdering
  This type is used to indicate whether or not one label is a prefix of another, and if so, whether the longer string has a 0 after the prefix, or a 1 after the prefix. If the first label is equal to the second, or not a prefix of the second, then it is considered invalid.
• VersionFreshness
  Whether or not a node is marked as stale or fresh Stale nodes are no longer active because a newer version exists to replace them.

Constants

• EMPTY_LABEL
  The label used for an empty node
• EMPTY_VALUE
  The value to be hashed every time an empty node’s hash is to be considered
• TOMBSTONE
  A “tombstone” is a false value in an AKD ValueState denoting that a real value has been removed (e.g. data rentention policies). Should a tombstone be encountered, we have to assume that the hash of the value is correct, and we move forward without being able to verify the raw value. We utilize an empty array to save space in the storage layer

Traits

• SizeOf
  Retrieve the in-memory size of a structure