Crate akd_client

source ·
Expand description


This crate contains a “lean” client to verify AKD proofs which doesn’t depend on any crates other than the native hashing implementations and VRF functionality through the akd_core crate. This makes it suitable for embedded applications, e.g. inside limited clients (Android, iPhone, WebAssembly, etc) which may not have a large dependency library they can pull upon.


The features of this library are

  1. default blake3: Blake3 256-bit hashing
  2. sha256: SHA2 256-bit hashing
  3. sha512: SHA3 512-bit hashing
  4. sha3_256: SHA3 256-bit hashing
  5. sha3_512: SHA3 512-bit hashing

which dictate which hashing function is used by the verification components. Blake3 256-bit hashing is the default implementation and utilizes the blake3 crate. Features sha256 and sha512 both utilize SHA2 cryptographic functions from the sha2 crate. Lastly sha3_256 and sha3_512 features utilize the sha3 crate for their hashing implementations. To utilize a hash implementation other than blake3, you should compile with

//          [disable blake3]      [enable other hash]
cargo build --no-default-features --features sha3_256


  • Functions for performing the core cryptographic operations for AKD
  • This module contains implementations of a verifiable random function (currently only ECVRF). VRFs are used, in the case of this crate, to anonymize the user id <-> node label mapping into a 1-way hash, which is verifyable without being regeneratable without the secret key.
  • This module contains all the hashing utilities needed for the AKD directory and verification operations
  • This module contains all of the structs which need to be constructed to verify any of the following AKD proofs
  • Utility functions
  • This module contains verification calls for different proofs contained in the AKD crate


  • The label of a particular entry in the AKD
  • The value of a particular entry in the AKD
  • 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.
  • 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.
  • The value associated with an element of the AZKS
  • Used to denote an azks value that has been hashed together with an epoch
  • This proof is just an array of UpdateProofs.
  • 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:
  • Merkle proof of membership of a NodeLabel with a particular hash value in the tree at a given epoch
  • Represents the label of a AKD node
  • Merkle Patricia proof of non-membership for a NodeLabel in the tree at a given epoch.
  • Represents a specific level of the tree with the parental sibling and the direction of the parent for use in tree hash calculations
  • 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.
  • 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:
  • 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.


  • 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”.
  • 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.
  • 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.


  • The number of children each non-leaf node has in the tree
  • The label used for an empty node
  • The value to be hashed every time an empty node’s hash is to be considered
  • 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


  • Retrieve the in-memory size of a structure