APTOS Concepts | Accounts

An Aptos blockchain account contains blockchain assets. These assets, such as coins and NFTs, are inherently scarce and must be controlled. Any such asset is represented as a resource in a blockchain account. A resource is a Move language primitive that emphasizes access control and scarcity in its representation. However, a resource can also be used to represent other blockchain capabilities, identity information and access control.

Each account on the Aptos blockchain is identified by a 32-byte account address. An account can store data, and that data is stored in resources. The initial resource is the account data itself (authentication key and sequence number). Additional resources, such as currencies or NFT, are added after the account is created.

AN EXAMPLE OF AN ACCOUNT ADDRESS
Account addresses consist of 32 bytes. They are usually represented as 64 hexadecimal characters, with each hexadecimal character being a half-byte. For an example of what an account address looks like, see «Your First Transaction» below:

Alice: eeff357ea5c1a4e7bc11b2b17ff2dc2dcca69750bfef1e1ebcaccf8c8018175b
Bob: 19aadeca9388e009d136245b9a67423f3eee242b03142849eb4f81a4a409e59c

Creating an Account

When a user requests to create an account, such as with the Aptos SDK, the following cryptographic steps are performed:

  • Start by generating a new private-key-public-key pair.
  • Find out from the user the preferred signature scheme for the account: Whether the account should use a single signature or whether multiple signatures are required to sign a transaction.
  • Combine the public key with the user’s signature scheme to create a 32-byte authentication key.
  • Initialize the account sequence number to 0. Both the authentication key and the sequence number are stored in the account as the initial resource of the account.
  • Create a 32-byte account address from the initial authentication key.

From this point, the user must use the private key to sign transactions with this account.

Account Sequential Number

The account sequence number indicates the number of transactions that have been sent and logged on the network from that account. It is incremented each time a transaction sent from that account is executed or cancelled and stored on the blockchain.

Each transaction sent must contain the current sequence number of the sender account. When the Aptos blockchain processes the transaction, it looks at the sequence number in the transaction and compares it to the sequence number in the account (as stored in the blockchain in the current version of the ledger). The transaction is executed only if the sequence number in the transaction matches the sequence number of the sender’s account, and is rejected if they do not. Thus, past transactions, which necessarily contain older sequence numbers, cannot be replayed, which prevents replay attacks.

These transactions will be stored in mempool until they become the next sequence number for that account (or until they expire). When a transaction is applied, the account sequence number is incremented by 1. The account has a strictly ascending sequential number.

The address of the account

The process of creating a new account first creates a 32-byte authentication key. This authentication key is then returned unchanged as the 32-byte account address.

However, later on, the authentication key can change, for example, when generating a new private-key-public-key pair for key rotation. But the account address won’t change. Consequently, only the 32-byte authentication key will initially match the 32-byte account address. After the account is created, the account address will remain unchanged, in spite of the fact that the private key, the public key and the authentication keys can change. Changing the address of an existing account is irrelevant.

Signing schemes.

An account can send transactions. Aptos blockchain supports the following signature schemes:

  • Ed25519 for single-signature transactions, and
  • MultiEd25519 for transactions with multiple signatures.

NOTE
Aptos blockchain uses single-signature transactions by default.

Signature scheme identifiers.

Authentication key generation for an account requires you to provide one of the following 1-byte signature scheme identifiers for that account, i.e., whether the account is a single signature or multiple signatures:

  • 1-byte single signature scheme identifier: 0x00.
  • 1-byte multi-signature scheme identifier: 0x01. Be sure to also specify the value K to generate the K-of-N multiple signature authentication key.

Single Signature Authentication

To generate an authentication key and an account address for a single-signature account:

  1. Generate a key pair: Generate a fresh key pair (privkey_A, pubkey_A). The Aptos blockchain uses the PureEdDSA scheme on the Ed25519 curve as defined in RFC 8032.
  2. Design a 32-byte authentication key: Create a 32-byte authentication key from pubkey_A:
auth_key = sha3-256(pubkey_A | 0x00)
Enter fullscreen mode Exit fullscreen mode

Where | denotes union. 0x00 is a 1-byte single-signature circuit identifier.

  1. Use this initial authentication key as the permanent address of the account.

Authentication with multiple signatures

In K-of-N multi-signature authentication, there are a total of N signatures for an account, and at least K of those N signatures must be used to authenticate the transaction.

To generate a K-of-N multi-signature account authentication key and account address, follow these steps:

  1. Generate key pairs: Generate N public keys p_1, ..., p_n.
  2. Define the value of K, the threshold number of signatures needed to authenticate a transaction.
  3. Define the 32-byte authentication key: Calculate the authentication key as described below:
auth_key = sha3-256(p_1 | . . . | p_n | K | 0x01)
Enter fullscreen mode Exit fullscreen mode

0x01 is a 1-byte multi-signature scheme identifier.

  1. Use this initial authentication key as the permanent address of the account.

APTOS TESTNET ACCOUNTS
Creating accounts in the Aptos testnet network requires a public account key and a number of Coin<TestCoin> to top up that account, resulting in the creation of a new account with these two resources.

Signature Access Control

The sender of the transaction is represented by the signer. If a function in the Move module takes signer<###code> as an argument, the Aptos Move VM translates the identifier of the account that signed the transaction into signer at the entry point of the Move module. See the Move code example below with signer in the initialize and withdraw functions. If signer is not specified in a function, such as the following deposit account function, there is no access control for that function:

module Test::Coin {
  struct Coin has key { amount: u64 }

  public fun initialize(account: &signer) {
    move_to(account, Coin { amount: 1000 });
  }

  public fun withdraw(account: &signer, amount: u64): Coin acquires Coin {
    let balance = &mut borrow_global_mut<Coin>(Signer::address_of(account)).amount;
    *balance = *balance - amount;
    Coin { amount }
  }

  public fun deposit(account: address, coin: Coin) acquires Coin {
      let balance = &mut borrow_global_mut<Coin>(account).amount;
      *balance = *balance + coin.amount;
      Coin { amount: _ } = coin;
  }
}
Enter fullscreen mode Exit fullscreen mode

Account State

Each account's state includes both code (Move modules) and data (Move resources). An account can contain any number of Move modules and Move resources:

  • Move modules: Move modules contain code, such as type and procedure declarations, but no data. A Move module encodes rules for updating the global state of the Aptos blockchain.
  • Move resources: Move resources contain data, but not code. Each resource value has a type, which is declared in a module published to the distributed Aptos blockchain database.

Оцените статью
devanswers.ru
Добавить комментарий