Key management
An overview of Accumulate's hierarchical key structure
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.
An illustration of the process for creating a digital signature (left) and validating a digital signature (right)
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.