Technical Architecture

System Architecture

ArenaPlay will support multiple types of digital assets. Each asset will be identified by an Asset ID, where the Asset ID will be a 256-bit string that distinguishes between different asset types. Based on the Asset_ID of each asset, we can identify the type of asset and relate it to the asset generation process (Asset_Issuance_Program is specifically responsible for generating new asset units), asset manipulation process (Asset_Management_Program controls and manipulates the received set of assets). Asset_Management_Program

There are two types of assets running on ArenaPlay: APC and Assets.

ArenaPlay is designed to integrate and enhance script-based and on-chain proto-protocol concepts to enable third-party service provider developers, merchants, and consumers to create arbitrary consensus-based, scalable, standardized, feature-complete, easy-to-develop, and coordinated applications. --A blockchain with a built-in Turing-complete programming language that enables anyone to create contracts and decentralized applications with their own freely defined ownership rules, transactions, and state transition functions.

In the ArenaPlay system, state is made up of objects called "accounts" (each account consists of a 20-byte address) and groups of state transitions that transfer value and information between two accounts. Similar to Ether, an account in ArenaPlay has four components: a random number, a counter that determines that each transaction can only be processed once; the account balance; the account's contract code (if any); and the account's storage (which is empty by default).

ArenaPlay will have two types of accounts: externally owned accounts (controlled by the private key) and contract accounts (controlled by the contract code). Externally owned accounts have no code and one can send a message from an external account by creating and signing a transaction. Whenever a contract account receives a message, the contract's internal code is activated, allowing it to read and write to internal storage, as well as send other messages or createcontracts.

1) Check if the previous block referenced by the block exists and is valid.

2) Check that the timestamp of the block is larger than the last block referenced and is less than 15 minutes.

3) Check if the block number, difficulty value, transaction root, uncle root and fuel limit (many Ether-specific underlying concepts) are valid.

4) Check if the workload proof of the block is valid.

5) Assign S[0] to the STATE_ROOT of the previous block.

6) Assign TX to the block's transaction list with n transactions in total. For i belonging to 0 ...... n-1, perform the state transition S[i+1] =APPLY(S[i],TX[i]). If an error occurs in any of the transitions, or if the program has spent more fuel (gas) than GASLIMIT to execute here, an error is returned.

7) Assign a value to S_FINAL with S[n] to pay the block reward to the miner.

8) Check if S-FINAL is the same as STATE_ROOT. If it is the same, the block is valid. Otherwise, the block is invalid.