Endless Account

An account on the Endless blockchain represents access control over a set of assets including on-chain currency and NFTs. In Endless, these assets are represented by a Move language primitive known as a resource that emphasizes both access control and scarcity.

Each account on the Endless blockchain is identified by a 32-byte. More details, refer:

Account Address Format

Different from other blockchains where accounts and addresses are implicit, accounts on Endless are explicit and need to be created before they can execute transactions.

The account can be created explicitly or implicitly by transferring Endless Coin(EDS) there. See the Creating an account section for more details.

In a way, this is similar to other chains where an address needs to be sent funds for gas before it can send transactions.

Explicit accounts support "native" Multisig feature via Authentication key; accounts on Endless support k-of-n multisig using Ed25519 signature schemes when constructing the 32-byte authentication key.

There are three types of accounts on Endless:

• Standard account - This is a typical account corresponding to an address with a corresponding pair of public/private keys.

• Resource account - An autonomous account without a corresponding private key used by developers to store resources or publish modules on-chain.

• Object - A complex set of resources stored within a single address representing a single entity.

Creating an account

When a user requests to create an account, for example by using the Endless SDK, the following steps are executed:

• Generate a new private key, public key pair with Ed25519 authentication scheme.

• Combine the public key with the public key’s authentication scheme to generate a 32-byte authentication key and the account address.

The user should use the private key for signing the transactions associated with this account.

Account sequence number

The sequence number for an account indicates the number of transactions that have been submitted and committed on-chain from that account. Committed transactions either execute with the resulting state changes committed to the blockchain or abort wherein state changes are discarded and only the transaction is stored.

Every transaction submitted must contain a unique sequence number for the given sender’s account. When the Endless blockchain processes the transaction, it looks at the sequence number in the transaction and compares it with the sequence number in the on-chain account. The transaction is processed only if the sequence number is equal to or larger than the current sequence number. Transactions are only forwarded to other mempools or executed if there is a contiguous series of transactions from the current sequence number. Execution rejects out of order sequence numbers preventing replay attacks of older transactions and guarantees ordering of future transactions.

Authentication key

The initial account address is equal to authentication key during account creation. However, the authentication key content may subsequently change, from one authentication key to a list of authentication keys, for example when you upgrade an account to multi-signature account, adding more accounts as individual signer.

The Endless blockchain supports the following authentication schemes:

• Ed25519

• K-of-N multi-signatures

The Endless blockchain defaults to Ed25519 signature.

Ed25519 authentication

To generate an authentication key and the account address for an Ed25519 signature:

1. Generate a key-pair: Generate a fresh key-pair (privkey_A, pubkey_A). The Endless blockchain uses the PureEdDSA scheme over the Ed25519 curve, as defined in RFC 8032.
2. Derive a 32-byte authentication key Derive a 32-byte authentication key from the pubkey_A:

auth_key = sha3-256(pubkey_A | 0x00)

where | denotes concatenation. The 0x00 is the 1-byte single-signature scheme identifier.

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

MultiEd25519 authentication

With K-of-N multisig authentication, there are a total of N signers for the account, and at least K of those N signatures must be used to authenticate a transaction.

To generate a K-of-N multisig account’s authentication key and the account address, we may choose via Endless Multi-Signature, SDK Typescript or Endless CLI.

Here we use Endless CLI to demonstrates:

1. Generate key-pairs: Generate N ed25519 public keys p_1, …, p_n.

2. Decide on the value of K, the threshold number of signatures needed for authenticating the transaction.

3. Fund these accounts to ensure accounts are created on chain.

4. Here we choose p_1 as multisig account, and adding left N-1 accounts into p_1 authentication keys.

$ endless account add-authentication-key \ 
    --private-key ${p1-private-key} \ 
    --new-private-key ${p2-private-key} 

repeat to add all accounts into p_1's authentication key list. Now p_1 account is Multisig account, and Threshold is 1-of-N

1. Update Threshold K of p_1.

$ endless account update-signature-required \ 
    -n ${K} \ 
    --private-key ${anyone-in-the-list-of-private-key} 

Now approve any transaction on behaves of p_1 account, K signatures is required at least.

State of an account

The state of each account comprises both the code (Move modules) and the data (Move resources). An account may contain an arbitrary number of Move modules and Move resources:

• Move modules: Move modules contain code, for example, type and procedure declarations; but they do not contain data. A Move module encodes the rules for updating the Endless blockchain’s global state.

• Move resources: Move resources contain data but no code. Every resource value has a type that is declared in a module published on the Endless blockchain.

Access control with signers

The sender of a transaction is represented by a signer. When a function in a Move module takes signer as an argument, the Endless Move VM translates the identity of the account that signed the transaction into a signer in a Move module entry point. See the below Move example code with signer in the initialize and withdraw functions. When a signer is not specified in a function, for example, the below deposit function, then no signer-based access controls will be provided for this function:

coin.move

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;
  }
}