1. Introduction

The Accumulate network can be thought of as a collection of independent chains. Each chain is managed by a hierarchy of identities, and each identity possesses a hierarchy of keys with user-defined priority levels. High priority keys may be kept in cold storage and used for administrative tasks, for example, while low priority keys may be used for small purchases. If a lower priority key is lost or its security is compromised, a higher priority key can restrict its use or restore it from backup.

The ability to manage keys over time also enables more advanced features that might appeal to enterprise users. Multisignature authorization will allow multiple key holders to participate in transactions and increase security when transferring high value assets or sensitive information. The Accumulate protocol will be backwards compatible with legacy keys, making it easier to merge keys that are owned by different parties into a key group. For example, a real-estate company and property management service may create a key group to co-manage a property. Key security can also be upgraded or downgraded as needed, and keys can be updated to new security protocols without requiring a user to move their assets or expose their keys. 

In this technical guide, we will review the process of using keys to create digital signatures, introduce Accumulate’s key architecture, and explain the underlying technology that makes Accumulate the first blockchain to enable key management.

2. Digital Signatures

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 compares 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. In most blockchains, changes to m or n require the creation of an entirely new account and the transfer of assets. This exposes the assets to risk, and requires coordination among the keyholders. If m < n, the assets may be frozen. In Accumulate, admin keys can make changes to m and n by issuing new keys or revoking access.

3. Key Architecture

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.