Accumulate
  • Getting Started
    • Introduction
    • Support
    • Glossary
    • Fees
    • Networks
    • Open source and contribution
    • Frequently Asked Questions
    • Converting FCT to ACME
  • Setup
    • Local DevNet Setup
    • Follower node setup with AccMan
    • Validator node setup with AccMan
    • Retaining validator keys when wiping node data
  • CLI
    • CLI setup
    • CLI reference
      • Flags
    • Import a Factom wallet
  • Nodes
    • Operator onboarding guide
    • Debugging node issues
  • Developer Resources
    • API Reference
    • Factom API support
  • Staking
    • What is staking
    • How to stake your tokens
    • FAQ
  • Tools
    • Explorer
    • Javascript SDK
    • Java SDK
  • Deep Dive
    • Lite accounts
    • Accumulate digital identifiers (ADIs)
    • Key management
    • Identity hierarchies
    • Synthetic transactions
    • Signatures and authorities
  • Integration
    • Ledger Integration
      • How to use the Ledger with the Accumulate CLI
      • CLI Reference
    • Tendermint
  • Tutorials
    • Accumulate Bridge Guides
      • How to convert ACME to WACME
      • How to convert WACME to ACME
      • How to setup a bridge node
    • How to create a Lite Account and Keys on Mainnet / Testnet
    • Sending Tokens from a Lite Token Account via CLI
    • How to create an ADI via CLI
    • How to create a Custom Token/Token Issuer using CLI
    • Querying Accumulate token account with Json RPC API
  • Release Note
    • Release notes
      • Release Note 2.0 RC2
      • Release Note 1.0 RC1
      • Release Note 0.6
      • Release Note 0.5.1
      • Release Note 0.5
  • Blog
  • Hackathon
    • Accumulate web3athon guide
Powered by GitBook
On this page

Was this helpful?

  1. Deep Dive

Key management

An overview of Accumulate's hierarchical key structure

PreviousAccumulate digital identifiers (ADIs)NextIdentity hierarchies

Last updated 2 years ago

Was this helpful?

The Accumulate network is a collection of independent chains. Each chain is managed by a hierarchy of identities known as Accumulate Digital Identifiers (ADIs), and each identity possesses a hierarchy of keys that allow it to participate in the execution of transactions.

A digital signature of a transaction is typically created by using the sender’s private key to encrypt a hash of the transaction output data to be unlocked. The receiver verifies the transaction by decrypting the digital signature with the sender’s public key and comparing the resulting hash to the hash of the transaction data. If the two hashes are identical, then the transaction is considered valid because the public key used to decrypt the digital signature must correspond to the private key used to create it. This is commonly referred to as a single signature transaction. An illustration of the process used to create and validate a digital signature is shown below.

A multisignature (multisig) transaction is similar except that m of n signatures are required to validate the transaction. For example, a withdrawal of funds from an account may be executed in a smart contract if 3 out of 4 account managers sign the transaction with their private keys.

The Accumulate protocol will allow single signature transactions in Testnet 1.0 and multisig in future Testnet releases. Its hierarchical key architecture will also enable key management through the use of keys with different priority levels. Multisig transactions and key management in the Accumulate protocol are illustrated in the example below, where a wallet that is owned by ADI RedWagon creates a token transaction, signs it with its private key, and submits it to a particular chain. The chain specifies what Key Book applies to the transaction, while the transaction specifies what Key Page must be used to validate it.

A Key Page defines the set of keys (m of n) that are required to validate a transaction, where m number of keys are created by hashing m number of public keys. If validation requires a signature from any one key, then m is equal to 1. If validation requires a signature from all keys, then m is equal to n.

A Key Book is a prioritized list of Key Pages, where the first page in the list is the highest priority and the last page is the lowest priority. The first key page can modify any key page, but the last key page can only modify itself. A Key Book is also attached to a chain since the chain ID of a Key Book is specified by the chain's data record.

Every transaction that is processed on the Accumulate network has an actor, which is broadly defined as an entity that performs an action. For example, a Lite account is considered an actor when it creates an ADI, and an ADI is considered an actor when it creates a Key Book. When the protocol receives a transaction, the node loads the actor’s data record, locates the chain ID of the Key Book, and loads that particular Key Book. The transaction also specifies a Key Page priority, which refers to a Key Page within the key book that is associated with the actor. The keys in that Key Page are authorized to sign the transaction. If the transaction is signed by a key that is not in that Key Page, that signature is rejected.

In the example above, RedWagon/Account is governed by a Key Book belonging to RedWagon, and a transaction sent by RedWagon/Account specifies the priority 1 Key Page. This Key Page requires 4 keys out of 4 total keys (m = n = 4) to sign the transaction before it is valid.

An illustration of the process for creating a digital signature (left) and validating a digital signature (right)