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:

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 , 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 .

2. Derive a 32-byte authentication key Derive a 32-byte authentication key from the pubkey_A:

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 , 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

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.

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

The Endless blockchain account addresses use Base58 encoding and have the following characteristics:

1. The length of most regular account addresses is between 43 and 44 characters.

2. You can quickly differentiate between accounts by checking the first and last few characters of the address.

3. Vanity addresses are supported.

For example, 5SHvmLEaSr76dsKy4XLR5vMht14PRuLzJFx6svJzqorP is an Endless account address.

Currently, addresses in Base58 encoding format are fully supported in both the command line and the block explorer.

Below is an example of how account transactions are displayed on the :

On the backend, Endless addresses are stored as 32-byte arrays. In some cases, you may see this format in the command line or the browser. For instance, the Endless chain has two system account addresses, represented in hexadecimal format:

• 0x0000000000000000000000000000000000000001, which can be simplified to 0x1. Its role is as the system account, responsible for executing system contracts.

• 0x0000000000000000000000000000000000000004, which can be simplified to 0x4. Its role is as the system token account, responsible for managing "Tokens" and "NFTs."

To convert between Base58 format and byte format, you can use the following methods:

• Online Tools: Search for keywords such as "base58 encoder decoder"

• Python Code (requires the base58 library):

Transaction Simulation

Transaction simulation, often referred to as "dry runs," is a method used to predict the outcome of a blockchain transaction before broadcasting it on-chain. This process is especially useful for smart contracts and decentralized applications (dApps) to ensure transactions perform as intended.

Transaction simulation plays a critical role in enhancing security and mitigating malicious activity in the Web3 ecosystem. By simulating a transaction, you can inspect it for unexpected or harmful behavior prior to execution. For instance, when interacting with a new dApp or calling a smart contract function, a simulation may reveal unauthorized token transfers or wallet access that were neither disclosed nor expected. This capability is invaluable for identifying and avoiding scams or malicious contracts designed to compromise user funds.

Sponsored Transactions

Sponsored transactions on the Endless chain refer to transactions where the gas fees are paid by the contract invoked by the transaction.

On the Endless blockchain, executing transactions requires a fee, also known as a gas fee, which is typically paid in the native token of the Endless chain (EDS). Gas fees are paid to the validators of the Endless chain to ensure network security. However, for new users, especially those transitioning from Web 2.0, this requirement can increase the barrier to entry.

Sponsored transactions lower the difficulty of interacting with contracts for users, particularly beginners. By leveraging sponsored transaction technology, contracts can make it easier for users to interact while ensuring the contract itself covers the gas fees, thereby maintaining stable chain operations.

On the Endless chain, all types of tokens adhere to the FungibleAsset(FA) standard. This concept is equivalent to "fungible tokens" on other blockchains, such as Ethereum. For simplicity, in the following sections, "token" and "asset" are used interchangeably.

Digital Assets

In simple terms, every token corresponds to:

1. Token Metadata

1. FungibleStore，the storage location for a specific account's token balance:

1. FungibleAsset(FA), the memory representation of a fungible token in VM enviroment:

FungibleAsset only exists in VM memory; at the end of transaction, any FA needs be merged into FungibleStore of corrsponding Account, otherwise FA is burned or dropped.

Endless provides move functions to handle token operations, such as:

• public entry fun transfer<T: key>(sender: & signer, from: Object<T>, to: Object<T>, amount: u128)

• public fun withdraw<T: key>(owner: & signer, store: Object<T>, amount: u64): FungibleAsset

• public fun deposit<T: key>(store: Object<T>, fa: FungibleAsset)

These functions enable token minting, transferring, and burning between accounts.

EDS Native Token

The metadata for the native token EDS is as follows:

The smallest denomination of EDS is Vein; 1 EDS is equivalent to veins.

Assume Alice has an account on the Endless Chain but does not currently hold any EDS tokens.

If Bob transfers 1 EDS to Alice, the transaction will involve the following steps:

System Function Calls Related

For more details on system functions related to EDS, refer to the

Design Purpose

Due to the comparatively massive volumes sold during early-stage rounds, projects may encounter extreme selling pressure after the IDO and after the token has been posted on Centralized Exchange – CEX / Decentralized Exchange – DEX. It significantly lowers the price of tokens by increasing the total amount of tokens in circulation.

For the Token Economy to stay sustainable & effective, the majority of tokens must be kept by investors rather than being sold on the market. Members can stop the value of its token from sinking by locking up tokens. Additionally, it prevents team members from selling their tokens as soon as trade begins, safeguarding holders’ interests.

Endless's locking_coin_ex

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.

Endless support two method of MultiSig:

• On-Chain K-of-N multisig

• Off-Chain K-of-N multisig

Here we describe the operations the On-Chain K-of-N multisig and compares with Off-Chain at the end.

On-Chain K-of-N multisig

Step 1: Pick an SDK

Install your preferred SDK from the below list:

• TypeScript SDK

Step 2: Run the example

Clone the endless-ts-sdk repo and build it:

Navigate to the Typescript examples directory:

Install the necessary dependencies:

Run the example:

Process flow

Pros and Cons

On-Chain Multisig

On-Chain multisig implement versatile MultiSig based on Move module, which could expand to support different key schemas in one trasaction, and more expandable features, eg. adding Weight to each account to support Weighted-Threashold multisig.

On-Chain multisig account is created on "0x1::multisig_account" module, and dedicated multisig account. it means we cannot convert any pre-exists account with Ed25519 keypair, into an multisig account.

any k-N multisig transaction, go through K transaction committment, K-1 for seperate approve of each owner, 1 transaction is for any owner execute the transaction. the whole process is gas consumption, compared with Off-Chain multisig.

Off-Chain Multisig

Off-Chain is built on the Endless Account authentication key and off-chain multisig service(Dapp). With well-designed Dapp user interface, users can easily collaborate to sign transactions, while the Dapp handles transaction submission to the Endless network, delivering a smoother operational experience.

Compared to on-chain multisig, off-chain multisig significantly reduces gas consumption.

Due to the structural invariance of Endless Account, off-chain multisig is less scalable and less versatile.

For more details, please refer to the following resources:

• : A tutorial demonstrating off-chain multisig.

Randomization is an important feature in blockchain. The application of randomization results, such as generated random numbers, can be achieved similarly to, e.g., the election of block nodes, while trusted random numbers can provide support for numerous DApps, such as lotto, games, etc.

In many other chains, the implementation of trusted random number generation requires the use of off-chain random number generation services, such as Ethereum, which requires off-chain beacons such as Chainlink or drand to provide external randomness.

The disadvantages of relying on external beacons are that the randomness is too expensive or too slow to be generated for DApps that require higher speed random numbers; in addition, the external randomness must be sent to the contract through transactions, which complicates DApp development and user interaction.

Reliable Randomness

If a sequence is to be identified as random, it has to possess the following qualities:

• Unpredictable — The result must be unknowable ahead of time.

• Unbiased — Each outcome must be equally possible.

• Provable — The result must be independently verifiable.

• Tamper-proof — The process of generating randomness must be resistant to manipulation by any entity.

Weighted Threshold VUF Essentials

Here we discuss threshold VUF with an idealized key generation algorithm. The advantages of this approach, rather than immediately considering VUF keying using a DKG, is that it lets us focus on the VUF security and avoid any nuances due to the key generation phase.

An -threshold VUF scheme for a finite message space is a tuple of polynomial time computable algorithms with the following properties:

1. Setup.

   (public parameter) consists of a generator and a random generator . Let be the weights of the participants, be the total weights, and be the threshold.

2. KeyGen, , .

   The key generation algorithm takes the public parameters then outputs:

• Unpredictable depends on below:

  • outcomes aggregated signature, which is the income of VUF output. The procedure takes place in every block's 1st transaction (Block Metadata transaction), which means not any User or Validator could predict randomness in User Transaction of the current block.

• Provable depends on below:

PVSS Process

Endless PVSS procedure, described as below:

1. Public Parameter Setup

   • define groups and , generator , in group and in group ; as numbers of validators, threshold

   • denote pp (public parameter) = , the following functions will take pp as default input parameter.

The Endless chain has built-in provision for trusted random number generation, which can better enhance the security of services based on this type of service. At the implementation level, Endless utilizes the Weighted Publicly Verifiable Secret Sharing (wPVSS) algorithm, which can be run efficiently by each verifying node and which is aggregatable to help reduce communication overhead. Meanwhile, there is a communication-efficient aggregatable weighted distributed key generation (wDKG) generation protocol on Endless. Finally, Endless has a novel Weighted Verifiable Random Function (wVRF), which the verifying node evaluates each round, with a constant amount of communication per verifying node, rather than a linear relationship with the amount pledged by the verifier.

API Usage

Endless framework module provide a series of function randomness APIs:

• randomness::u8_integer() returns a u8 random number, evenly samples an 8-bit from Endless Randomness

• randomness::u16_integer()

• ...

• randomness::u8_range(min_incl: u8, max_excl: u8)

By repeatedly calling these functions, multiple objects can be safely sampled to generate multiple "unbiased" random numbers.

Demonstration

Endless Roll

Here we build a lottery system and pick a random winner from n participants. In the centralized world with a trusted server, the roll algorithm is the backend simply calls a random integer sampling function (random.randint(0, n-1) in Python, or Math.floor(Math.random() * n) in JS).

In Endless chain, we build a lottery move module:

• let winner_idx = endless_framework::randomness::u64_range(0, n); is the randomness API call that returns a u64 integer in range [0, n) uniformly at random.

• #[randomness] enables the move compiler to check the outermost of the call stack of decide_winner is private.

Security Considerations

Test and Abort Attack

If decide_winner() were accidentally marked public, malicious players can deploy their own contract to:

1. call decide_winner();

2. read the lottery result (assuming the lottery module has some getter functions for the result);

3. abort if the result is not in their favor. By repeatedly calling their own contract until a txn succeeds, malicious users can bias the uniform distribution of the winner (dApp developer’s initial design).

Under Gas Attack

Users should also put prevention of Undergassed Attack into security considerations when writing business logic.

Imagine such a dApp. It defines a private entry function for a user to:

1. toss a coin (gas cost: 9), then

2. get a reward (gas cost: 10) if coin=1, or do some cleanup (gas cost: 100) otherwise.

A malicious user can control its account balance, so it covers at most 108 gas units (or set transaction parameter max_gas=108), and the cleanup branch (total gas cost: 110) will always abort with an out-of-gas error. The user then repeatedly calls the entry function until it gets the reward.

Here are some ideas of how to prevent undergassing attacks generally:

• Make your entry function gas independent from the randomness outcome. The simplest example is to not “act” on the randomness outcome, i.e., read it and store it for later. Note that calling any other functions can have variable gas costs. For example, when calling randomness to decide which player should win, and then depositing the winnings to the winner might seem like a fixed gas cost. But, 0x1::coin::transfer / 0x1::fungible_asset::transfer can have a variable cost based on the user’s on-chain state.

• If your dApp involves a trusted admin/admin group, only allow the trusted to execute randomness transactions (i.e., require an admin signer).

• Make the path that is most beneficial have the highest gas (as the attacker can only abort paths with gas above a threshold he chooses). NOTE: that this can be tricky to get right, and the gas schedule can change, and is even harder to get right when there are more than 2 possible outcomes.

Random, but not a secret

Please keep in mind that random returned from calling the randomness API is randomness, but not a secret. The original seed in each block lies in 0x1::randomness::PerBlockRandomness which is public on the Endless chain.

Users should not try to do the following:

• Use the randomness API to generate an asymmetric key pair, discard the private key, then think the public key is safe.

• Use the randomness API to shuffle some opened cards, veil them, and think no one knows the permutation.