VITE Whitepaper

Tuesday, June 11, 2019
Download document
Save for later
Add to list is a project of OpenBook

Vite: A High Performance Asynchronous Decentralized Application Platform Chunming Liu Daniel Wang Ming Wu [email protected] [email protected] [email protected] Abstract Vite is a generalised decentralized application platform that meets the requirements of industrial applications for high throughput, low latency and scalability while taking into account security. Vite uses DAG ledger structure, and transactions in ledgers are grouped by accounts. The Snapshot Chain structure in Vite can make up for the lack of security of the DAG ledger. The HDPoS consensus algorithm, through which writing and confirming of transactions are asynchronous, provides high performance and scalability. The Vite VM is compatible with EVM, and the smart contract language extended from Solidity, providing more powerful ability of description. In addition, an important improvement in Vite design is the adoption of a asynchronous Event Driven Architecture, which transmits information through messages between smart contracts, which greatly improves system throughput and scalability. In addition to built-in native tokens, Vite also supports users to issue their own digital assets, and also provides cross chain value transfer and exchange based on Loopring Protocol [1]. Vite realizes resource allocation by quotas, and light users do not have to pay transaction fees. Vite also supports contract scheduling, name service, contract update, block pruning and other features. 1 Introduction application, with large volume and can not be transmitted between nodes. Therefore, nodes need to transfer a set of 1.1 Definition transactions to achieve the consistency of the final state. We organize such a group of transactions into a specific data Vite is a universal dApp platform that can support a set structure, usually referred to as ledgers. of smart contracts, each of which is a state machine with independent state and different operational logic, which can Definition 1.3 (Ledger) Ledger is composed of a set of communicate by message delivery. transactions, with an abstract data type recursively con- In general, the system is a transactional state machine. structed. It is defined as follows: The state of the system s ∈ S, also known as the world state, is composed of the state of each independent account. { l = Γ(Tt ) An event that causes changes in account status is called l = l1 + l2 transactions. The more formalized definition is as follows: Definition 1.1 (Transactional State Machine) a Among them,Tt ∈ 2T ,representing a set of transactions, transactional state machine is a 4-tuple: (T , S, g, δ),where Γ ∈ 2T → L,represents a function of constructing a book T is a set of transactions,S is a set of states,g ∈ S is the through a set of transactions,L is a set of ledgers,+ : L×L → initial state, also known as genesis block, δ : S × T → S L,representing the operation of merging two sub ledgers into is a state transition function. one. The semantics of this transactional state machine is a It should be noted that in such systems, ledgers are discrete transition system, which is defined as follows: usually used to represent a group of transactions, rather than a state. In Bitcoin [2]and Ethereum [3],the ledger Definition 1.2 (Semantics of Transactional State Machine) is a block chain structure, where transactions are globally The semantics of a transactional state machine (T , S, s0 , δ) ordered. To modify a transaction in the ledger, we need is a discrete transition system: (S, s0 , →).→∈ S × S is a to reconstruct a sub ledger in the account book, thereby transition relationship. increasing the cost of tampering with the transaction. At the same time, the decentralized application platform According to the same group of transactions, different is a distributed system with final consistency. Through some valid books can be constructed, but they represent a differ- consensus algorithm, the final state can be reached between ent order of transactions and may cause the system to enter nodes. In realistic scenarios, what is stored in the state of a different state. When this happens, it is usually called smart contracts is a set of completed data in a decentralized ”fork”. 1

Definition 1.4 (Fork) Assume Tt , Tt ′ ∈ 2T ,Tt ⊆ Tt ′ . if is equivalent to defining contract account a receives the l = Γ1 (Tt ),l′ = Γ2 (Tt ′ ),and don’t meet l ⪯ l′ ,we can name lstate transition function δa . EVM is widely used in such and l′ are fork legers. ⪯ represents prefix relitionship. platforms, but there are also some problems. For example, there is a lack of library function support and security According to the semantics of the transactional state problems. machine, we can easily prove that from an initial state, if The ledger structure of the Ethereum is a block chain the ledger is not forked, each node will eventually enter [2]the block chain is made up of blocks, each block contains the same state. So, if a forked ledger is received, will a list of transactions, and the latter block refers to the hash it certainly enter a different state? It depends on the of the previous block to form a chain structure. inherent logic of the transaction in the ledger, and how the ledgers organize partial orders between transactions. In Γ({t1 , t2 , ...|t1 , t2 , ... ∈ T }) = (..., (t1 , t2 , ...)) (1) reality, there are often some transactions that satisfy the commutative laws, but because of the problem of account The greatest advantage of this structure is to effectively design, they frequently cause forks. When the system starts prevent transactions from being tampered with, but because from an initial state, receives two forked ledgers and ends it maintains the full order of all transactions, the exchange of up in the same state, we call these two ledgers a false forked two transaction orders will generate a new ledger, which has ledger. a higher probability of fork. In fact, under this definition, the state space of a transactional state machine is regarded Definition 1.5 (False Fork) Initial state s0 ∈ S,ledger as a tree: the initial state is the root node, the different s2 . if l1 ̸= l2 ,and s1 = s2 ,we transaction order represents different paths, and the leaf l1 l2 l1 , l2 ∈ L,s0 → s1 , s 0 → call these two ledgers l1 , l2 as false fork ledgers. node is the final state. In reality, the state of a large number of leaf nodes is the same, which leads to a large number of A well designed ledger should minimize the probability false forks. of false fork The consensus algorithm Φ is called PoW, which first When the fork occurs, each node needs to choose one proposed in Bitcoin protocol [2].The PoW algorithm relies from multiple forked ledgers. In order to ensure the consis- on a mathematical problem that is easily verifiable but tency of the state, the nodes need to use the same algorithm difficult to solve. For example, based on a hash function to complete the selection. This algorithm is called the h : N → N ,finding the result of x,to meet the requirement consensus algorithm. h(T + x) ≥ d,dis a given number, called the difficulty, T is a binary representation of the trade list contained in the Definition 1.6 (Consensus Algorithm) Consensus al- block. Each block in the block chain contains a solution to gorithm is a function that receives a set of ledgers and returns such problems. Add up the difficulty of all blocks, which is the only ledger: the total difficulty of a block chain ledger: L ∑ ∑ Φ:2 →L D(l) = D( li ) = D(li ) (2) Consensus algorithm is an important part of system i i design. A good consensus algorithm should possess high Therefore, when choosing the correct account from the convergence speed to reduce the sway of consensus in fork, choose the fork with the highest difficulty: different forks, and have a high ability to guard against malicious attacks. Φ(l1 , l2 , ..., ln ) = lm where m = arg max (D(li )) (3) i∈1..n 1.2 Current Progress The PoW consensus algorithm has better security and has been running well in Bitcoin and Ethereum. However, The Ethereum [4]took the lead in realizing such a system. there are two main problems in this algorithm. The first is to In the design of the Ethereum, the definition of the world solve a mathematical problem that requires a large amount state is S = ΣA , a mapping from the account a ∈ A and of computing resources, resulting in a waste of energy. The the state of this account σa ∈ Σ.Therefore, any state in the second is the slow convergence speed of the algorithm, thus state machine of the Ethereum is global, which means that affecting the system’s overall throughput. At present, the a node can achieve the status of any account at any time. TPS of the Ethereum is only about 15, which is totally The state transition function δ of Ethereum is defined unable to meet the needs of decentralized applications. by a set of program codes. Each group of code is called a smart contract. The Ethereum defines a Turing complete 1.3 Direction of Improvement virtual machine, called EVM, whose instruction set is called EVM code. Users can develop smart contracts through a After the birth of the Ethereum, the Ethereum community programming language Solidity similar to JavaScript, and and other similar projects began to improve the system from compile them into EVM code, and deploy them on Ethereum different directions. From the abstract model of the system, [5]. Once the smart contract is successfully deployed, it the following directions can be improved: 2

• Improving the system state S • Improving the state transition function δ • Improving the structure of the ledger Γ • Improving the consensus algorithm Φ 1.3.1 Improve the state of the system The main idea of improving the state of the system is to localize the global state of the world, each node is no longer concerned with all transactions and state transfers, and only maintains a subset of the whole state machine. In this way, Figure 1: False Fork the potentials of the set S and the set T are greatly reduced, thus improving the scalability of the system. Such systems As shown,L is a collection of all possible forked accounts include: Cosmos [6],Aelf[7],PChain and so on. for a set of transactions, and S is a collection of states that In essence, this side chain based scheme sacrifices the can be reached in different orders. According to definition wholeness of the system state in exchange for the scalability. ,1.4, mapping f : L → S is a surjective;And according to This makes the decentralization of each dApp running on it definition 1.5, this mapping is not a injective. Here we is weakened - the transaction history of a smart contract is calculate the probability of the false fork: no longer saved by every node in the whole network, but only Suppose that C users have the right to produce ledgers, by a part of the node. In addition, cross contract interaction M = |L|,N = |S|,Mi = |Li |, where Li = {l|f (l) = si , si ∈ will become the bottleneck of such a system. For example, S}. The probability of false fork is as follows: in Cosmos, interactions in different Zone require a common ∑N ( )C Mi 1 chain Hub to complete [6]. Pf f = − C−1 (4) i=1 M M 1.3.2 Improve state transition function From this formula, we can see that in order to reduce the probability of false fork, there are two ways: Based on improving EVM, some projects provide more • ฀ Establish equivalence relations on the L of the abundant smart contract programming languages. For ledger set, divide equivalence classes into them, and example, a smart contract language Rholang is defined construct fewer forked ledgers. in RChain based on π calculus ; the smart contract in NEO is called NeoContract, which can be developed in the • ฀ Restrict users who have the right to produce ledgers, popular programming languages such as Java,C# etc; EOS thereby reducing C is programmed with C/C++. The first way is the important direction in Vite design. It will be discussed in detail later. The second ways have 1.3.3 Improve the ledger structure been adopted by many algorithms. In the PoW algorithm, any user has the right to produce a block; and the PoS The improvement direction of the ledger structure is the algorithm limits the power of the production block to those construction of the equivalent class. The linear ledger with with system rights; the DPoS algorithm [11] limits the user the global order of multiple transactions is improved to a with the right to produce the block to be further restricted nonlinear ledger that only records partial order relations. within a group of agent nodes. This nonlinear ledger structure is a DAG (Directed Acyclic At present, through improved consensus algorithm, some Graph). At present, Byteball [8],IOTA[9],Nano[10]and other influential projects appeared. For example, Cardano uses a projects have realized the function of encrypting money PoS algorithm called Ouroboros, and literature [12] gives based on DAG’s account structure. Some projects are trying a strict proof of the related characters of the algorithm; to use DAG to implement smart contracts, but so far, BFT-DPOS algorithm used by EOS[13], is a variant of the improvements in this direction are still being explored. DPoS algorithm and improves system throughput by fast producing blocks; Qtum [14]’s consensus algorithm is also a 1.3.4 Improve consensus algorithm PoS algorithm; The Casper algorithm adopted by RChain [15] is one of the PoS algorithms as well. The improvement of consensus algorithm is mostly to im- There are also other projects that put forward their own prove the throughput of the system, and the main direction proposals for improving the consensus algorithm. NEO[16] is to suppress the generation of false fork. Next we will uses a BFT algorithm, called dBFT, and Cosmos[6] uses an discuss what factors are involved in false fork. algorithm called Tendermint [17]. 3

2 Ledgers between transactions as much as possible in order to expand the scope of tampering |T2 |. 2.1 Overview The role of ledgers is to determine the order of transactions, and the order of transactions will affect the following two aspects: • Consistency of status: Since the state of the system is not a CRDT (Conflict-free replicated data types) [18], not all transaction is exchangeable, and the sequence of different transaction execution may lead to the system entering a different state. • Effectiveness of Hash: In the ledger, the trans- action will be packaged into blocks, which contain Figure 3: Ledger structure comparison hash that is referenced each other. The order of Obviously, the above two objectives are contradictory, transactions affects the connectivity of hash quoted and the necessary trade-offs must be made when designing in the ledgers. The greater the scope of this impact, the account structure. Since the account maintenance is a the greater the cost of tampering with transactions. partial order between transactions, it is essentially a partial This is because any change to a transaction must be ordered set (poset) [19], if represented by Hasse diagram rebuilt by hash, which directly or indirectly refers to (Hasse diagram)[20], it is a DAG on the topology. the block of the transaction.. The above picture compares several common ledger The design of the ledger also has two main objectives: structures, and the ledgers near the left are maintained with less partial order. Hasse diagram appears flat and has a lower false fork rate; the ledgers near the right side maintain more partial order relationships, and Hasse diagram is more slender and more tamper resistant. In the picture, the most-left side is a common set based structure in a centralization system without any tamper proofing features; the most right side is a typical blockchain Ledger with the best tamper proof features; between the two, there are two DAG ledgers, the block-lattice account Figure 2: Ledger merge [10] used by Nano on the left; and the right side, the tangle book [9] is used by IOTA . In terms of characteristics, • Reducing the false fork rate: as discussed in blocklattice maintains less partial order relations and is more the previous section, the reduction of the false fork suitable for the accounting structure of high performance rate can be achieved by establishing an equivalent decentralized application platforms. Because of its poor class and combining a group of accounts that lead tampering characteristics, it can expose security risks, so far, the system into the same state into a single account. no other projects adopt this ledger structure except Nano. As shown above, according to the formula of false In order to pursue high performance, Vite adopts the fork rate, the false fork rate of the ledger on the DAG ledger structure. At the same time, by introducing an ( )C ( 2 )C left is Pf f = 53 + 5 − 5C−11 ;after the merge of additional chain structure Snapshot Chain and improving ledger space, the false fork rate of the right graph is the consensus algorithm, the shortcomings of block-lattice ( )C ( )C Pf f ′ = 32 + 13 − 3C−1 1 .It is known that when C > security are successfully made up, and the two improvements 1,Pf f < Pf f . That is to say, we should minimize the will be discussed in detail later. ′ partial ordering relationship between transactions and allow more transactions to be exchanged sequentially. 2.2 Pre Constraint • Tamper proof: when a transaction t is modified First, let’s take a look at the precondition of using this ledger in the ledger l,in the two sub ledgers of the book structure for the state machine model. This structure is l = l1 + l2 , the sub ledger l1 is not affected, and the essentially a combination of the entire state machine as a set hash references in the sub ledger l2 need to be rebuilt of independent state machines, each account corresponding to form a new valid ledger l′ = l1 + l2 ′ . Affected sub to an independent state machine, and each transaction only ledger l2 = Γ(T2 ), T2 = {x|x ∈ T, x > t}.Thus, to affects the state of an account. In the ledger, all transactions increase the cost of tampering with transactions, it is are grouped into accounts and organized into a chain of necessary to maintain the partial order relationship transactions in the same account. Therefore, we have the 4

following restrictions on the state S and transaction T in In this way, from the initial state to the final state Vite: s′ there could be two different paths s0 → t1 s1 → t2 s′ and s0 → s2 → s . These two paths are respectively passed t2 t1 ′ Definition 2.1 (Single degree of freedom constraint) through the intermediate state s1 and s2 , and these two system state s ∈ S,is the vector s = (s1 , s2 , ..., sn ) formed intermediate states are the mapping of the final state s′ in by the state si of each account. For ∀ti ∈ T ,after the two account dimensions.In other words, if you only care performing the transaction ti , the system state transfers about the state of one of the accounts, you only need to as follows: (s1 ′ , ..., si ′ , ..., sn ′ ) = σ(ti , (s1 , ..., si , ..., sn )),need execute all the transactions that correspond to the account, to meet:sj ′ = sj , j ̸= i.This constraint is called a single and do not need to carry out the transactions of other degree of freedom constraint for a transaction. accounts. Next, we will define how to split transactions in Intuitively, a single degree of freedom transaction will Ethereum into the single degree of freedom transactions only change the state of an account without affecting the sta- required by Vite: tus of other accounts in the system. In the multidimensional space where the state space vector is located, a transaction Definition 2.2 (Transaction Decomposition) Dividing is executed, and the state of the system moves only along the a transaction with a degree of freedom greater than 1 direction parallel to a coordinate axis. Please note that this into a set of single degree of freedom transactions, named definition is more stringent than the transaction definition Transaction Decomposition. A transfer transaction can be in Bitcoin, Ethereum and other models. A transaction in split into a sending transaction and a receiving transaction; Bitcoin will change the state of the two accounts of the a contract call transaction can be split into a contract request sender and the recipient; the Ethereum may change the state transaction and a contract response transaction; a message of more than two accounts through a message call. call within each contract can be split into a contract request Under this constraint, the relationship between trans- transaction and a contractual response transaction. actions can be simplified. Any two transaction is either Thus, there would be two different types of transactions orthogonal or parallel. This provides conditions for grouping in the ledgers. They are called ”trading pairs”: transactions according to accounts. Here is an example to illustrate: Definition 2.3 (Trading Pair) a sending transaction or contract request transaction, collectively referred to as a ”request transaction”; a receiving transaction or a contract response transaction, collectively referred to as ”response transaction”. A request transaction and a corresponding response transaction are called transaction pairs. The account for initiating the request for transaction t is recorded as A(t); the corresponding response transaction is recorded as: e t, the account corresponding to the transaction is recorded as A(et). Based on the above definition, we can conclude the possible relationship between any two transactions in Vite: Figure 4: Single degree of freedom trading and intermediate Definition 2.4 (Transaction Relationship) There may state exist for the following relations for two transactions t1 and t2 : As shown in the figure above, suppose Alice and Bob Orthogonality:If A(t1 ) ̸= A(t2 ),the two transactions have 10 USD respectively. The initial state of the system is are orthogonal , recorded ast1 ⊥ t2 ; s0 = (10, 10). When Alice wants to transfer 2 USD to Bob, Parallel:If A(t1 ) = A(t2 ),the two transactions are in the model of Bitcoin and Ethereum, a transactiont′ ,can parallel, recorded as t1 ∥ t2 ; t′ make the system go directly into the final state:s0 → s′ . Causality:If t2 = te1 ,then the two transactions are In the definition of Vite, transaction t′ changed the causal,recorded as t1 ▷ t2 , or t2 ◁ t1 . status of two accounts of Alice and Bob as well, which did not conform to the principle of single degree of freedom. 2.3 Definition of Ledger Therefore, the transaction must be split into two transac- To define a ledger is to define a poset. First, let’s define the tions: partial ordering relationship between transactions in Vite: 1) A transaction t1 that represents transferring of 2 USD by Alice Definition 2.5 (Partial order of transactions) we use 2) A transaction t2 that represents receiving of 2 USD dualistic relationship < to represent the partial order relation by Bob of two transactions: 5

A response transaction must follow a corresponding a blockchain structure, if a node receives a longer forked request transaction :t1 < t2 ⇔ t1 ▷ t2 ; chain, the new fork will be selected as the consensus result, All transactions in an account must be strictly and and the original fork will be abandoned and the transaction globally ordered:∀t1 ∥ t2 , there must be :t1 < t2 ,or t2 < t1 . on the original fork will be rolled back. In such a system, transaction rollback is a very serious event, which will lead Due to the partial ordering relationship established on to double spend. Just imagine that a business receives a the transaction set T meet the characteristics: payment, provides goods or services, and after that payment is withdrawn, the merchant may face losses. Therefore, • Irreflexive: ∀t ∈ T ,there is no t < t; when a user receives a payment transaction, it needs to wait • Transitive:∀t1 , t2 , t3 ∈ T , if t1 < t2 , t2 < t3 , then for the system to ”confirm” the transaction to ensure that t1 < t 3 ; the probability of rolling back is low enough. • Asymmetric:∀t1 , t2 ∈ T , if t1 < t2 , then it doesn’t exist Definition 3.1 (Transaction Confirmation) when the t2 < t 1 probability of a transaction being rolled back is less than In this way, we can define the Vite account in strict a given threshold ϵ, the transaction is called confirmed. partial order set: Pr (t) < ϵ ⇔ t is conf irmed. Definition 2.6 (Vite Ledger) Vite Ledger is thestrict Confirmation of transactions is a very confusing concept, poset composed by set of T of the given transaction, and because whether a transaction is recognized depends in fact the partial poset < on the implicit confidence level of 1 − ϵ. A merchant selling diamonds and a coffee seller suffered different losses when they were attacked by double spend. As a result, the former needs to set smaller ϵ on the transaction. This is also the essence of the number of confirmations in Bitcoin. In Bitcoin, the confirmation number indicates the depth of a transaction in the block chain. The greater the number of confirmations, the lower the probability of the transaction being rolled back [2]. Therefore, merchants can indirectly set the confidence level of the confirmation by setting the waiting number of confirmation numbers. The probability of transaction rollback decreases with time due to the hash reference relationship in the account structure. As mentioned above, when the design of the ledger has better tampering characteristics, rolling back a transaction needs to reconstruct all subsequent blocks of the exchange in the block. As new transactions are constantly Figure 5: The relationship between the ledger and the being added to ledgers, there are more and more successive transaction in Vite nodes in a transaction, so the probability of being tampered with will decrease. A strict poset can correspond to a DAG structure. As In the block-lattice structure, as the transaction is shown in the figure above, circles represent transactions, and grouped by account, a transaction will only be attached arrows denote dependencies between transactions. a → b to the end of the account chain of its own account, and indicates that a depends on b. the transaction generated by most other accounts will not The Vite ledger defined above is structurally similar automatically become a successor node of the transaction. to block-lattice. Transactions are divided into request Therefore, it is necessary to design a consensus algorithm and response transactions, each of which corresponds to a reasonably to avoid hidden dangers of double spend. separate block, each account Ai corresponds to a chain, a Nano adopts a voting based consensus algorithm, [10], transaction pair, and a response transaction referencing the transaction is signed by a set of representative nodes selected hash of its corresponding request transaction. by a group of users. Each representative node has a weight. When the signature of a transaction has enough weight, it is believed that the transaction is confirmed. There are 3 Snapshot chain following problems in this algorithm: First, if a higher confidence degree of confirmation is 3.1 Transaction Confirmation needed, the threshold of the voting weight needs to be raised. When the account is forked, the result of consensus may If there are not enough representative nodes online, the swing between two forked ledgers. For example, based on intersecting speed can not be guaranteed, and it is possible 6

that a user will never collect the number of tickets necessary In order to support multiple tokens at the same time, to confirm an exchange; the structure of recording the balance information in Vite’s Second, the probability that transactions are rolled back account state is not a uint256, but a mapping from the does not decrease with time. This is because at any time, token ID to the balance. the cost of overthrowing a historical voting is the same. The first snapshot block in the snapshot chain is called Finally, the historical voting results are not persisted into the ”genesis snapshot”, which saves snapshots of the genesis the ledger, and are stored only in the local storage of nodes. block in the account. When a node gets its account from other nodes, there is no way to reliably quantify the probability of a historical transaction being rolled back. In essence, the voting mechanism is a partial centraliza- tion solution. We can regard the voting results as a snapshot of the status of the ledgers. This snapshot will be distributed in the local storage of each node in the network. In order to have the same tamper proof ability with the block chain, we can also organize these snapshots into chain structures, which is one of the kernel of the Vite design - the snapshot chain [21]. 3.2 Definition of snapshot chain Snapshot chain is the most important storage structure in Vite. Its main function is to maintain the consensus of Vite Figure 6: snapshot chain ledgers. First, we give the definition of the snapshot chain: Since each snapshot block in the snapshot chain corre- Definition 3.2 (Snapshot block and snapshot chain) sponds to the only fork of the Vite ledger, it is possible a snapshot block that stores a state snapshot of a Vite ledger, to determine the consensus result of the Vite ledger by the including the balance of the account, the Merkle root of the snapshot block when the snapshot block does not fork in the contract state, and the hash of the last block in each account snapshot block. chain. The snapshot chain is a chain structure composed of snapshot blocks, and the next snapshot block refers to the hash of the previous snapshot block. 3.3 Snapshot chain and transaction confir- The state of a user account contains the balance and the mation hash of the last block of the account chain; in addition to After introducing the snapshot chain, the natural security the above two fields, the state of a contract account contains flaws of block-lattice structure have been remedied. If an the Merkle root hash of it, The structure of the state of an attacker wants to generate a double spend transaction, in account is as follows: addition to rebuilding the hash reference in the Vite ledger, it also needs to be rebuilt in the snapshot chain for all the struct AccountState { blocks after the first snapshot block of the transaction, and // account balance need to produce a longer snapshot chain. In this way, the map<uint32, uint256> balances; cost of attack will be greatly increased. // Merkle root of the contract state In Vite, the confirmation mechanism of transactions is optional uint256 storageRoot; similar to Bitcoin, which is defined as follows: // hash of the last transaction // of the account chain Definition 3.3 (Transaction Confirmation in Vite) uint256 lastTransaction; in Vite,if a transaction is snapshot by snapshot chain, the } transaction is confirmed., the depth of the snapshot block in The structure of the snapshot block is defined as follows: the first snapshot, is called the confirmation number of the transaction. struct SnapshotBlock { // hash of the previous block Under this definition, the number of confirmed trans- uint256 prevHash; actions will increase by 1 when the snapshot chain grows, // snapshot information and the probability of the double spend attack decreases map<address, AccountState> snapshot; with the increase of the snapshot chain. In this way, users // signature can customize the required confirmation number by waiting uint256 signature; for different confirmation numbers according to the specific } scenario. 7

The snapshot chain itself relies on a consensus algorithm. 4 Consensus If the snapshot chain is forked, the longest fork is chosen as a valid fork. When the snapshot chain is switched to a 4.1 Goal of Design new fork, the original snapshot information will be rolled When designing a consensus protocol, we need to take full back, that means the original consensus on the ledger was account of the following factors: overthrown, and replaced by the new consensus. Therefore, snapshot chain is the cornerstone of the whole system • Performance.The primary goal of Vite is fast. To security, and needs to be treated seriously. ensure high throughput and low delay performance of the system, we need to adopt a consensus algorithm 3.4 Compressed storage with higher convergence speed. Because all account states need to be saved in every snapshot • Scalability.Vite is a public platform that is open to block in snapshot chain, the storage space is to be very large, all decentralized applications, so Scalability is also an the compression to the snapshot chains is necessary. important consideration. • Security.The design principle of Vite is not pursuing the ultimate safety, however, it still needs to ensure enough safety base line and effectively guard against all kinds of attacks. Compared with some existing consensus algorithms, the security of PoW is better, and a consensus can be reached if the computing power of malicious nodes are below 50%. However, the intersecting speed of PoW is slow and can not meet the performance requirements; PoS and its variant algorithms remove the steps to solve mathematical prob- lems, improve intersecting speed and single attack cost, and reduce energy consumption. But the Scalability of PoS is still poor, and the “Nothing at Stake” problem [22] is difficult to solve; BFT algorithms has better performance in Figure 7: Snapshot before compression security and performance, but its Scalability is a problem, usually more suitable for private chain or consortium chain; The basic approach of compressing snapshot chain stor- the DPoS [11] series algorithm effectively reduces the proba- age space is to use incremental storage: a snapshot block bility of false fork by limiting the permissions of generating only stores data that is changed compared to the previous blocks. The performance and scalability are good. As a snapshot block. If there is no transaction for one account consequence, DPoS has a slight sacrifice in security, and the between the two snapshots, the latter snapshot block will number of malicious nodes should not be more than 1/3 [23]. not save the data of the account. Generally, the DPoS algorithm has obvious advantages To recover snapshot information, you can traverse the in performance and scalability. Therefore, we choose DPoS snapshot block from the beginning to the end, and cover as the basis of the Vite consensus protocol and expand it the data of every snapshot block by the current data. properly on the basis of it. Through Hierarchical Delegated consensus protocol and asynchronous model, the overall Snapshot#1 A 1 : s1 Snapshot#2 A 1 : s1 ′ Snapshot#3 performance of the platform can be further improved. A 2 : s2 A2 : s2 ′′ A 3 : s3 4.2 Hierarchical Consensus Figure 8: Snapshot after compression The consensus protocol of Vite is HDPoS (Hierarchical Only the final status of each snapshot of an account is Delegated Proof of Stake). The basic idea is to decompose saved when snapshotting, the intermediate state will not the consensus function Φ (functional decomposition): be taken into account, so only one copy of the data in Φ(l1 , l2 , . . . , ln ) = Ψ(Λ1 (l1 , l2 , . . . , ln ), the snapshot will be saved, no matter how many transac- tions generated by an account between the two snapshots. Λ2 (l1 , l2 , . . . , ln ), . . . (5) Therefore, a snapshot block takes up to S ∗ A bytes in Λm (l1 , l2 , . . . , ln )) maximum. Among them, S = sizeof(si ), is the number of bytes occupied for each account state, and A is the total Λi : 2L → L,is called as local consensus function,the number of system accounts. If the average ratio of active returned result is called the local consensus; Ψ : 2L → L, accounts to total accounts is a, the compression rate is 1−a. known as the global consensus function, it selects a unique 8

result from a group of candidate in local consensus as the 4.3.2 Private Consensus Group final consensus result. After this separation, the consensus of the whole system The private consensus group is only applicable to the pro- has become two independent processes: duction of transaction blocks in ledgers, and belongs to the account chain of private consensus group. The blocks can Local consensus generate the blocks corresponding to re- only be produced by the owner of the private key of the quest transactions and response transaction in the account. By default, all user accounts belong to the private user account or contract account, and writes to the consensus group. ledgers. The greatest advantage of the private consensus group is to reduce the probability of fork. Because only one user Global consensus snapshots the data in the ledger and gener- has the right to produce blocks, the only possibility of fork ates snapshot blocks. If the ledger is forked, choose is that the user initiate a double spend attack personally or one of them. a program error. The disadvantage of the private consensus group is that 4.3 Right of Block Generation and Consen- the user nodes must be online before they can pack the sus Group transaction. This is not very suitable for the contract account. Once the owner’s node fails, no other node can Then, who has the right to generate the transaction block replace the response transaction that it produces contracts, in the ledger and snapshot block in the snapshot chain? which is equivalent to reducing the service availability of What consensus algorithm is adopted to reach a consensus? dApp. Since the ledger structure of Vite is organized into multiple account chains according to different accounts, we can conveniently define both the right of production of the blocks 4.3.3 Delegate Consensus Group in the ledger according to the dimension of the account, and the production right of the snapshot block belong to to a In the delegate consensus group, instead of user account ,a single group of users. In this way, we can put a number of set of designated proxy nodes is used to package the trans- account chains or snapshot chains into a consensus group, action through the DPoS algorithm. Both user accounts and in the consensus group, we can use a unified way to and contractual accounts can be added to the consensus produce the block and reach a consensus. group. Users can set up a set of separate agent nodes and establish a new consensus group. There is also a default Definition 4.1 (Consensus Group) Consensus group is consensus group in Vite to help package transactions for all a tuple (L, U, Φ, P ), describing the consensus mechanism of the other accounts that haven’t established their delegate a portion of the account or snapshot chain.,L ∈ A|{As }, consensus group individually, which is also known as the represents one or a number of account chains, or snapshot public consensus group. chains of the consensus group in the ledger; U represents the The delegate consensus group is suitable for most of user with the block production right on the chain specified by the contract accounts, because most of the transactions in the L; Φ specifies the consensus algorithm of the consensus the contract account are contract response transactions, in group; and P specifies the parameters of the consensus which higher availability and lower delays are needed than algorithm. the receivable transactions in the user account. Under this definition, users can set up consensus groups flexibly and select different consensus parameters on their 4.4 The Priority of the Consensus needs. Next, we will elaborate on different consensus groups. In the Vite protocol, the priority of global consensus is higher than that of local consensus. When the local con- 4.3.1 Consensus Group of Snapshot sensus is forked, the result of global consensus selection will The consensus group of snapshot chains is called snapshot prevail. In other words, once the global consensus selected a consensus group, which is the most important consensus fork of the local consensus as the final result, even a longer group in Vite. The consensus algorithm Φ of snapshot con- fork of a certain account chain in the future accounts occurs, sensus group adopts the DPoS algorithm and corresponding it will not cause the roll back of the global consensus results. to Ψ in the hierarchical model. The number of agents and This problem needs more attention when implementing the interval of the block generation are specified by the cross chain protocol. Because a target chain may roll parameter P . back, the corresponding account chain of the relay contract For example, we can specify snapshot consensus groups mapping the chain also needs to roll back accordingly. At with 25 proxy nodes to produce snapshot blocks at intervals this moment, if the local consensus of the relay chain has of 1 second. This ensures that the transaction is confirmed been adopted by the global consensus, it is impossible to to be fast enough. Achieving 10 times transaction confirma- complete the rollback, which may cause the data between tion need to wait 10 seconds in maximum. the relay contract and the target chain to be inconsistent. 9

The way to avoid this problem is to set a parameter delay transaction at a constant rate, so as to fully utilized the in the consensus group parameter P , which specifies the platform resources and improve the system’s throughput. snapshot consensus group to take a snapshot only the local consensus is completed after delay blocks. This will greatly reduce the probability of inconsistency of relay contracts, 5 Virtual Machine but it can’t be avoided completely. In the code logic of relay contracts, it is also necessary to deal with the rollback 5.1 EVM compatibility of the target chain separately. At present, there are many developers in the Ethereum field, and many smart contracts are applied based on Solidity and 4.5 Asynchronous Model EVM. Therefore, we decided to provide EVM compatibility In order to improve system throughput further, we need on the Vite virtual machine, and the original semantics in to support a more perfect asynchronous model on the most of the EVM instruction sets is kept in Vite. Because consensus mechanism. Vite’s account structure and transaction definition is differ- The life cycle of a transaction includes transaction initi- ent from Ethereum, the semantics of some EVM instructions ation, transaction writing and transaction confirmation. In need to be redefined, for example, a set of instructions to get order to improve the performance of the system, we need block information. The detailed semantic differences can be to design these three steps into asynchronous mode. This referred to appendix A.. is because at different times, the quantity of transactions Among them, the biggest difference is the semantics of initiated by users is different, the speed of transaction message calls. Next we will discuss in detail. writing and transaction confirmation processed by system is fixed relatively. Asynchronous mode helps to flatten the 5.2 Event Driven peaks and troughs thus improve the overall throughput of the system. In the protocol of Ethereum, a transaction or message may The asynchronous model of the Bitcoin and the affect the status of multiple accounts. For example, a Ethereum is simple: the transaction initiated by all users contract invocation transaction may cause the status of mul- is placed in an unconfirmed pool. When the miner packages tiple contract accounts to change at the same time through it into a block, the transaction is written and confirmed at message calls. These changes occur either at the same time, the same time. When the block chain continues to grow, or none at all. Therefore, the transaction in the Ethereum the transaction eventually reaches the preset confirmation is actually a kind of rigid transaction that satisfies the confidence level. characteristics of ACID (Atomicity, Consistency, Isolation, There are two problems in this asynchronous model: Durability) [24], which is also an important reason for the lack of expansibility in the Ethereum. • ฀ Transactions are not persisted to ledgers in an uncon- Based on considerations of scalability and performance, firmed state. Unrecognized transactions are unstable, Vite adopted a final consistency scheme satisfying BASE and there is no consensus involved, it can’t prevent (Basically Available, Soft state, Eventual consistency) [25] sending of transactions repeatedly. semantics. Specifically, we design Vite as an Event-Driven Architecture (EDA) [26]. Each smart contract is considered • ฀ There is no asynchronous mechanism for writing to be an independent service, and messages can be commu- and confirming of transactions. Transactions are only nicated between contracts, but no state is shared. written when confirmed, and the speed of writing is Therefore, in the EVM of Vite, we need to cancel the restricted by the confirmation speed. semantics of synchronous function calls across contracts, The Vite protocol establishes a more improved asyn- and only allow message communication between contracts. chronous model: first, the transaction is split into a trans- The EVM instructions affected are mainly CALL and action pair based on a ”request - response” model, whether STATICCALL.In Vite EVM, these two instructions can’t it is a transfer or a contract call, and the transaction is be executed immediately, nor can they return the result of successfully launched when a request transaction is written the call. They only generate a request transaction to write to the ledger. In addition, the written and confirming of to the ledger. Therefore in Vite, the semantics of function a transaction is asynchronous as well. Transactions can calls will not be included in this instruction, but rather sends be written into the DAG account of Vite firstly and will messages to an account. not be blocked by the confirmation process. Transaction confirmation is done through snapshot chain, and snapshot 5.3 Smart Contract Language action is asynchronous too. This is a typical producer - consumer model. In the Ethereum provides a Turing complete programming lan- life cycle of the transaction, no matter how production rate guage Solidity for developing smart contracts. To support changes in the upstream, the downstream can deal with the asynchronous semantics, we extended Solidity and defined 10

a set of syntax for message communication. The extended } Solidity is called Solidity++. Most of the syntax of Solidity are supported by So- contract A { lidity++, but not including the function calls outside the uint total; contract. The developer can define messages through the keyword message and define the message processor (Mes- function invoker(address addr, uint a, sageHandler) through the keyword on to implement the uint b) { cross - contract communication function. // message call to B For example, the contract A needs to call the add () send(addr, Add(a, b)) method in contract B to update its state based on the return // you can do anything after sending value. In Solidity, it can be implemented by function call. // a message other than using the The code is as follows: // return value } pragma solidity ^0.4.0; Sum.on { // get return data from message contract B { uint sum =; function add(uint a, uint b) returns // use the return data (uint ret) { if (sum > 10) { return a + b; total += sum; } } } } } contract A { uint total; In the first line ,code pragma solidity++ 0̂.1.0; in- dicates that the source code is written in Solidity++ but function invoker(address addr, uint a, will not be compiled directly with the Solidity compiler to uint b) { avoid that the compiled EVM code does not conform to the // message call to A.add() expected semantics. Vite will provide a specialized compiler uint sum = B(addr).add(a, b); for compiling Solidity++. This compiler is partially forward // use the return value compatible: if there is no Solidity code that conflict with if (sum > 10) { the Vite semantics, it can be compiled directly, otherwise total += sum; the error will be reported. For example, the syntax of } local function calls, transfers to other accounts will remain } compatible; obtaining the return value of the cross contract } function call, as well as the monetary unit ether, will not be compiled. In Solidity++, the function call codeuint sum = In contract A, when the invoker function is called, B(addr).add(a, b); is no longer valid; instead of that, the Add message will be sent to the contract B, which is contract A and contract B communicate asynchronously by asynchronous and the result will not be returned immedi- sending messages to each other. The code is as follows: ately.Therefore, it is necessary to define a message processor in A by using the keyword on to receive returned result and pragma solidity++ ^0.1.0; update the state. In contract B, the message Add is monitored. After contract B { processing, a Sum message is sent to the sender of the message Add(uint a, uint b); message Add to return the result. message Sum(uint sum); Messages in Solidity++ will be compiled into CALL instructions and a request transaction will be added to Add.on { the ledger. In Vite, ledgers serve as message middleware // read message for asynchronous communication between contracts. It en- uint a =; sures reliable storage of messages and prevents duplication. uint b =; Multiple messages sent to a contract by the same contract address sender = msg.sender; can guarantee FIFO (First In First Out); messages sent by // do things different contracts to the same contract do not guarantee uint sum = a + b; FIFO. // send message to return result It should be noted that the events in Solidity (Event) send(sender, Sum(sum)); and the messages in Solidity++ are not the same concept. } Events are sent indirectly to front through the EVM log. 11

5.4 Standard Library The snapshot chain is the key to the security and performance of the Vite platform. In order to incite node to Developers who develop smart contracts on Ethereum are participate in the transaction verification, the Vite protocol often plagued by the lack of standard libraries in Solidity. sets up the forging reward for the production of the snapshot For example, loop verification in the Loopring protocol must block. be performed outside the chain, one of the important reasons On the contrary, when users issue new tokens, deploy is that floating-point computing function is not provided in contracts, register VNS domain names 1 and obtain resource Solidity, especially the n square root [1][1] for the floating quotas, they need to consume or mortgage ViteToken. numbers. Under the combined action of these two factors, it is In EVM, a pre deployed contract can be called by conducive to optimizing the allocation of system resources. DELEGATECALL command to realize the function of li- brary function. Ethereum also provides several Precompiled Contract, which is mainly a few Hash operations. But these 6.2 Resource Allocation functions are too simple to meet the complex application Since Vite is a common dApp platform, the capabilities of needs. smart contracts deployed on them vary, and each different Therefore, we will provide a series of standard libraries smart contract has different requirements for throughput in Solidity++, such as string processing, floating point oper- and delay. Even for the same smart contract, performance ations, basic mathematical operations, containers, sorting, requirements at different stages are different. and so on. In the design of the Ethereum, each transaction needs Based on performance considerations, these standard to be assigned a gas price when launching, so as to compete libraries will be implemented in a local extension (Native with other transactions to write accounts. This is a typical Extension) way, and most of the operations are built into bidding model, which can effectively control the balance the Vite local code, and the function is called only through between supply and demand in principle. However, user the DELEGATECALL instruction in the EVM code. is difficult to quantify the current supply and demand The standard library can be extended as needed, but situation, and can not predict the price of other com- because the state machine model of the whole system is petitors, therefore market failure occurs easily. Moreover, deterministic, it can not provide functions like random the resources competing for each bid are directed against numbers. Similar to Ethereum, we can simulate pseudo one transaction, and there is no agreement on the rational random numbers through the hash of snapshot chains. allocation of resources according to the account dimension. 5.5 Gas 6.2.1 Quota Calculation There are two main functions for Gas in the Ethereum , the We have adopted a quota based resource allocation protocol first one is to quantify the computing resources and storage in Vite, which allows users to obtain higher resource quotas resources consumed by EVM code execution, and the second in three ways: is to ensure that the EVM code is halted. According to • A PoW is calculated when the transaction is initiated; the computability theory, the Halting Problem on Turing machines is an incomputable problem [27]. That means, it • Mortgage a certain amount of vite in the account; is impossible to determine whether a smart contract can be • To destroy a small amount of vite in one time. stopped after limited execution by analyzing the EVM code. The specific quotas can be calculated through the follow- Therefore, the gas calculation in EVM is also retained in ing formula: Vite. However, there is no Gas Price concept In Vite. Users ( ) do not buy the gas for an exchange by paying the fees, but 2 through a quota based model to obtain computing resources. Q = Qm · −1 (6) 1 + exp (−ρ × ξ ⊤ ) The calculation of quotas will be discussed in detail later in Among them, Qm is a constant, representing the upper the chapter ”economic model”. limit of a single account quota, which is related to the total throughput of the system and the total number of 6 Economic Model accounts.ξ = (ξd , ξs , ξf ) is a vector that represents the cost of a user for obtaining a resource: ξd is the PoW difficulty that the user calculates when generating a transaction, ξs 6.1 Native Token is the vite balance of the mortgage in the account, and ξf In order to quantify platform computing and storage re- is the one-time cost that the user is willing to pay for the sources and encourage nodes to run, Vite has built a native increase of the quota. It should be noted that ,ξf is different token ViteToken. The basic unit of token is vite, the smallest from the handling fee. These vite will be destroyed directly unit is attov„1 vite = 1018 attov. instead of paid to the miners. 1 refer to 7.2 naming service 12

In the formula, the vector ρ = (ρd , ρs , ρf ) represents the the recent k transactions in an account chain with a height weight of the three way of obtaining the quota, that is, the of ”n” is: quota obtained by the destruction of 1 vite is equivalent to the mortgaged ρs /ρf vite. ∑n k · i=n−k+1 gasi It can be seen from this formula that if the user neither Costk (Tn ) = (7) mortgages vite nor pays the one-time cost, it is necessary timestampn − timestampn−k+1 + 1 to calculate a PoW, otherwise there will be no quotas to Among them, for a transaction Tn , timestampn is the initiate a transaction, which can effectively prevent dust timestamp of the transaction, that is, the height of the attacks and protect the system resources from being abused. snapshot block it refers to; gasn is the fuel consumed for At the same time, this formula is a Logistic function. It is the transaction. relatively easy for users to get lower quotas, thereby reducing When verifying a transaction, the node will determine the threshold of low frequency users; and high frequency whether the quota satisfies the condition: Cost(T ) ≤ Q, users need to invest a lot of resources in order to obtain and if it is not satisfied, the transaction will be rejected. higher quotas. The extra costs they pay will increase the In this case, users need to repackage a transaction, increase benefits of all users. quotas by paying a one-time fee, or wait for a period of time to quote a higher snapshot in the transaction. 6.2.2 Resource Quantification Because snapshot chain is equivalent to a global clock, we 6.2.3 Quota Lease can use it to quantify the resource usage of an account If a user holds abundant vite assets, but does not need to accurately. In each transaction, the Hash of a snapshot utilize so many resource quotas, he can choose to rent his block is quoted, the height of the snapshot block is took as quota to other users. the timestamp of the transaction. Therefore, according to The Vite system supports a special type of transaction to the difference between the two transaction timestamps, we transfer the right to use an account resource quota. In this can judge whether the interval between the two transactions transaction, the number of vite that can be mortgaged, the is long enough. address of a transferee, and the duration of a lease can be specified. Once the transaction is confirmed, the resource quota corresponding to the amount of the token will be included in the assignee’s account. Once the lease time is exceeded, the quota will be calculated into the transferor account. The unit of leasing time is second. The system will be converted into the height difference of the snapshot block, so there may be some deviation. The leasing income can be obtained by the user. The Vite system only provides a quota transfer transaction, and the pricing and payment of the leasing can be achieved through a third party smart contract.. 6.3 Asset Issurance In addition to native token ViteToken, Vite also supports users to issue their tokens. The issue of tokens can be done through a special transaction, Mint Transaction. The target address of the mint transaction is 0. In the field data of the transaction, the parameters of the token are specified as follows: Figure 9: snapshot chain as a global clock Mint: { As shown above, account A generated 4 transactions name: "MyToken", in 2 time intervals, while account B generated only 2 totalSupply: 99999999900000000000000000, transactions. Therefore, the average TPS of A in this period decimals: 18, is 2 times that of B. If it’s just a transfer transaction, owner: "0xa3c1f4...fa", the average TPS of the quantified account is enough. For symbol: "MYT" smart contracts, each exchange has a different consumption } of resources, so it is necessary to accumulate gas for each transaction to calculate the average resource consumption Once the request is accepted by the network, the vite for a period of time. The average resource consumption of included in the mint transaction will be deducted from the 13

initiator account as the mint transaction fee. The system The above picture is an example of the cross chain value records the information of the new token and assigns a transmission between the Vite and the Ethereum. When token_id to it. All the balances of the newly generated the Ethereum user E1 wants to transfer the token from tokens will be added to the owner address, that is to say, the Ethereum to the Vite, it can send a transaction to the the owner account is the genesis account of the token. Vite gateway contract address V , while the user’s address A on the Vite is placed in the parameter. The balance of 6.4 Cross Chain Protocol the transfer will be locked in the gateway contract account and become part of the ToT reserve. After listening to the In order to support cross chain value transfer of digital assets transaction, the VCTP relay node generates a corresponding and eliminate ”value island”, Vite designed a Vite Cross- account sending transaction of Vite, sending the same chain Transfer Protocol (VCTP). amount of ToT to the user’s account A in the Vite. In For every asset that needs cross-chain transmission on the picture, ⃝ 1 and ⃝ 2 respectively indicate that E1 and E2 the target chain, a token that corresponds to it is needed in transfer to Vite account A and B. It should be noted that if the Vite as the voucher of the target Token circulating within the user does not specify the Vite address when transferring, the Vite, which is called the ToT (Token of Token). For the contract will reject the transaction. example, if you want to transfer the ether in the Ethereum The reverse flow is shown in ⃝, 3 When the user A account to Vite, you can issue a ToT with an identifier of launches transfering from the Vite account to the Ethereum ETH in Vite, the initial quantity of TOT should be equal account, a transaction will be sent to the Vite gateway to the total quantity of ether. contract, transfers to a certain quantity of ToT, and specifies For each target chain, there is a Gateway Contract on the reception address E1 of the Ethereum in the transaction. Vite to maintain the mapping relationship between Vite The VCTP relay node will generate the corresponding transactions and target chain transactions. In the consensus response block on the Ethereum Gateway contract, and group where the contract is located, the node responsible for package a transaction of the Ethereum to the Vite gateway generating blocks is called VCTP Relay. VCTP Relay needs contract on the Ethereum. In the Ethereum , the Vite gate- to be the Vite node and the full node of the target chain at way contract will verify whether this transaction is initiated the same time, and listen transactions on both sides. On by a trusted VCTP relay, and then the same amount of ether the target chain, we also need to deploy a Vite Gateway is transferred from the Vite gateway contract to the target Contract. account E1. Before VCTP Relay starts to work, the corresponding All cross chain relay nodes will monitor the target ToT in Vite should be transferred to the gateway contract. network, and they can verify whether each cross chain trans- After that, the supply of ToT can only be controlled by the action is correct and reach consensus within the consensus gateway contract, and no one can be added to ensure the 1: group. But snapshot consensus group will not monitor the 1 exchange ratio between the ToT and the target asset. At transaction of the target chain, nor will it verify whether the same time, the assets on the target chain are controlled the mapping between the two chains is correct. If the by the Vite gateway contract, and no user can use it, so as target network is rolled back or hard forked, the mapped to ensure that ToT has a full acceptance reserve. transactions in the Vite system cannot be rolled back; similarly, if the cross chain transactions in the Vite are rolled back, the corresponding transaction of the target network can not be rolled back at the same time. Therefore, when doing cross - chain transactions, it is necessary to deal with transaction rollback in contract logic. At the same time, as described in the 4.4 part, we need to set a delay parameter for the cross chain Relay consensus group. 6.5 Loopring Protocol Loopring protocol [1] is an open protocol to build a decen- tralized asset trading network. Compared to other DEX solutions, the Loopring protocol is based on the multiparty loop matching, which provides a dual authorization technol- ogy to prevent preemptive transactions and is fully open. We build the Loopring protocol into Vite, which is conducive to promoting the circulation of digital assets in Vite, so that the whole value system can be circulated. In this value system, users can issue their own digital assets, Figure 10: Cross Chain Protocol transfer assets outside the chain through VCTP, and use 14

the Loopring protocol to achieve asset exchange. The whole Names are organized in the form of domain names, such as process can be completed within the Vite system and is vite.myname.mycontract. The top-level domain name will completely decentralized. be retained by the system for specific purposes. For example, In Vite, Loopring Protocol Smart contract (LPSC) is a vite.xx represents Vite address, and eth.xx represents an part of the Vite system. Asset transfer authorization and Ethereum address. The second level domain name is open to multi-party atomic protection are all supported in the Vite. all users. Once the user owns the second level domain name, The Loopring relay is still open to fully integrate with its the subdomain can be expanded arbitrarily. The domain own ecosystem. name owner can modify the address directed by the domain Users can use vite to pay for asset exchange transactions, name at any time, so this function can be used for contract so the earned token by miners of Looping who perform loop upgrading. matching in the Vite platform is still vite. The length of the domain name is not restricted. In VNS, the hash of the domain name is actually stored. The target address can be a non Vite address of less than 256 bit, which 7 Other Designs can be used for cross chain interaction. It should be noted that VNS is different from the smart 7.1 Scheduling contract Package specification EIP1903 in Ethereum. VNS In the Ethereum, smart contracts are driven by transactions, is a name resolution service, the name is established at and the execution of contracts can only be triggered by runtime, and the resolution rules can be dynamically modi- users initiating a transaction. In some applications, a timing fied; and EIP190 is a package management specification, the scheduling function is needed to trigger the execution of a namespace is static, and it is established at compile time. contract through a clock. In Ethereum, this function is achieved through third 7.3 Contract Update party contracts.1 , performance and security are not guar- The smart contract of Ethereum is immutable. Once anteed. In Vite, we add the timing scheduling function to deployed, it can not be modified. Even if there is a bug in the built in contract. The users can register their scheduling the contract, it can not be updated. This is very unfriendly logic into the timed scheduling contract. The public consen- to developers and makes dApp’s continuous iteration very sus group will use the snapshot chain as a clock, and send difficult. Therefore, Vite needs to provide a scheme to the request transaction to the target contract according to support smart contract update. the user defined scheduling logic. In Vite, the process of contract updating includes: There is a specialized Timer message in Solidity++. Users can set up their own scheduling logic in the contract A. Deploys a new version of the contract to inherit the code through Timer.on. status of the original contract. B. Points the name of the contract to the new address in 7.2 Name Service VNS. In Ethereum, the contract will generate an address to C. Removes the old contract through the SELFDE- identify a contract when it is deployed. There are two STRUCT instruction problems in identifying contracts with addresses: These three steps need to be completed at the same time, • ฀ An address is an identifier with 20 bytes without and the Vite protocol ensures the atomicity of the operation. meaning. It is unfriendly to users and inconvenient to Developers need to ensure that the old contract data are use. correctly processed in the new version contract. It should be noted that the new contract will not inherit • ฀ Contracts and addresses are one-to-one. They cannot the address of the old contract. If quoted by the address, support contract redirection. the transaction will still be sent to the old contract. This In order to solve these two problems, the developer is because different versions of contracts are essentially two of Ethereum has provided a third party contract ENS 2 . completely different contracts, whether they can be modified However, in the actual scenario, the use of naming services dynamically or not, depending on the semantics of contracts. will be very frequent, and the use of third party contracts In Vite systems, smart contracts are actually divided can not guarantee the global uniqueness of naming, so we into two types, the first one is the background of a dApp, will build a name service VNS (ViteName Service) in Vite. and its business logic is described; and the second is a kind Users can register a set of names which is easy to remem- of contract that maps the real world. The previous one ber and resolve them to the actual address through VNS. is equivalent to an application’s background service, which 1 Ethereum Alarm Clock is a third party contract used to schedule the execution of other contracts, refer to http://www. 2 Ethereum Name Service is a third party contract used for name resoluton, refer to 3 EIP190 Ethereum Smart Contract Packaging Specification,refer to 15

needs to be continuously iterated through an upgrade; the • Inquire about history. If the node needs to query latter is equivalent to a contract, and once it comes into the transaction history, the transaction involved in the effect, no modification can be made, otherwise it is a breach query will not be tailored. of contract. For such a contract that is not allowed to be modified, it can be decorated with keyword static in According to different usage scenarios, each node can Solidity++, for example: choose several combinations from the above clipping strat- egy. It is important to note that clipping involves transac- pragma solidity++ ^0.1.0; tions in ledgers, while snapshot chains need to be kept intact. In addition, what is recorded in the snapshot chain is the static contract Pledge { hash of the contract state. When the account is clipped, the // the contract that will never change corresponding state of the snapshot needs to be kept intact. } In order to ensure the integrity of Vite data, we need to retain some ”Full nodes” in the network to save all transaction data. Snapshot consensus group nodes are full 7.4 Block Pruning nodes, and in addition, important users such as exchanges In a ledger, any transaction is immutable, and users can only may also become full nodes. add new transactions to the ledger without altering or delet- ing historical transactions. Therefore, with the operation of the system, the ledgers will become bigger and bigger. If 8 Governance a new node who joining the network wants to restore the For a decentralized application platform, an efficient gover- latest status, starting from the genesis block and redoing nance system is essential for maintaining a healthy ecosys- all the historical transactions. After running the system tem. Efficiency and fairness should be considered when for a period of time, the space occupied by the account designing governance systems. book and the time consumed for redoing transactions will The governance system of Vite is divided into two parts: become unacceptable. For the high throughput system of on-chain and off-chain. On-chain is a voting mechanism Vite, the rate of growth will be much higher than Bitcoin based on protocol, and off-chain is the iteration of the and Ethereum, so it is necessary to provide a technique for protocol itself. clipping the blocks in the ledgers. On the voting mechanism, it is divided into two types: Block clipping refers to the deletion of historical transac- Global voting and local voting. The global voting is based on tions that cannot be used in the ledgers, and does not affect the vite held by the user to calculate the rights as the voting the operation of the transactional state machine. So, which weight. The global voting is mainly used for the election of transactions can be safely deleted? It depends on which the snapshot consensus group proxy node. The local vote scenario the transaction will be used, including: is aimed at a contract. When the contract is deployed, a token is designated as the basis for voting. It can be used • Recovery.The primary role of a transaction is to to elect the agent nodes of the consensus group in which the recover status. Because in Vite, snapshot chain stores contract is located. snapshot information of account status, nodes can Besides the verification of transactions, the agent node recover state from a snapshot block. All transactions of snapshot consensus group has the right to choose whether before lastTransaction in the snapshot block can be to upgrade the Vite system Incompatibility. The delegated tailored to state recovery. consensus group proxy node has the right to decide whether • Verification of transactions.To verify a new trans- to allow the contract to be upgraded so as to avoid potential action, it needs to verify the exchange’s previous risks arising from the escalation of contracts. The agent transaction in the account chain, and if it is a response node is used to upgrade decision-making power on behalf of transaction, it also needs to verify the corresponding users in order to improve the efficiency of decision-making request transaction. Therefore, in the tailored ac- and avoid the failure of decision-making due to insufficient counting ledgers, at least one last transaction should participation in voting. These proxy nodes themselves are be retained in each account chain. In addition, all also restricted by consensus protocol. Only if most 1 agent open request transactions cannot be tailored because nodes are passed, will the upgrade take effect. If these their hashes may be referenced by subsequent response agents do not fulfill their decision-making power according transactions. to the user’s expectations, users can also cancel their proxy qualification by voting. • Calculate quotas.Whether a transaction meets the The governance of off-chain is realized by the community. quota is calculated by judging the sliding average of Any Vite community participant can propose an improve- the last 10 transaction resources, so at least the last 9 ment plan for the Vite protocol itself or related systems, transactions need to be saved on each account chain. which is called VEP (Vite Enhancement Proposal). VEP 1 according to DPoS protocol, the valid majority is 2/3 of total agent nodes. 16

can be widely discussed in the community and whether • High throughput.Vite uses the DAG ledger struc- to implement the solution is decided by Vite ecological ture, the orthogonal transaction can be written in par- participants. Whether the protocol will be upgraded for allel to the book; in addition, multiple conconsensus the implementation of a VEP will be ultimately decided by groups do not depend on each other in the HDPoS the agent node. Of course, when the differences are large, consensus algorithm, and can work in parallel; the you can also start a round of voting on the chain to collect a most important thing is that the Vite’s inter contract wide range of user opinions, and the proxy node will decide communication is based on the asynchronous model whether to upgrade according to the result of the vote. of the message. All these are helpful to improve the Although some Vite participants may not have enough throughput of the system. vite tokens to vote for their opinions. But they can freely submit VEP and fully express their views. The users who • Low delay.Vite uses the HDPoS consensus algorithm have the right to vote must take full account of the health to collaborate to complete the rotation production of the whole ecology for their own Vite rights, and therefore block through the proxy node, without the need to take the views of all the ecological participants seriously. calculate PoW, the block interval can be reduced to 1 second, which is beneficial to reduce the delay of transaction confirmation. 9 Tasks in future • Scalability.In order to meet the scalability require- ments, Vite makes a single degree of freedom limit on Transaction verification on snapshot chains is a major per- the transaction, grouping the transactions in the ac- formance bottleneck of the system. Because Vite adopts count according to the account dimension, allowing the asynchronous design and DAG account structure, transac- block production of different accounts to be completed tion validation can be executed in parallel. However, due by different nodes, and to remove the ACID semantics to the dependence between the transactions of different of the cross contract calls to BASE semantics based accounts, the degree of parallelism will be greatly restricted. on the message. In this way, nodes no longer need to How to improve the parallelism of transaction verification or save all the state of the world, and the data are saved adopt a distributed verification strategy will be an impor- in the entire distributed network in sharding mode tant direction for future optimization. Some shortcomings exist in the current HDPoS consen- • Usability.The improvements of Vite’s usability in- sus algorithm as well. It is also an optimization direction clude providing standard library support in Solid- to improve the consensus algorithm, or to be compatible ity++, dedicated to processing message syntax, timing with more consensus algorithms in the delegated consensus scheduling of contract, VNS naming services, support group. of contract upgrading, and so on. In addition, the optimization of virtual machine is also very important for reducing system delay and improving sys- • Value circulation.Vite supports digital asset is- tem throughput. Because of the simple design of EVM and suance, cross chain value transfer, token exchange the simplification of the instruction set, it may be necessary based on Loopring protocol, and so on, forming a to design a more powerful virtual machine in the future and complete value system. From the user’s point of view, define a smart contract programming language with more Vite is a fully functional decentralized exchange. ability to describe and less security vulnerabilities. • Economy.Because Vite adopts quota based resource Finally, besides the Vite core agreement, the construc- allocation model, lightweight users who do not trade tion of ancillary facilities supporting ecological development frequently do not have to pay high fees or gas charges. is also an important topic. In addition to SDK support Users can choose a variety of ways to change the for dApp developers, there is much work to do in dApp calculation. Extra quota can also be transferred foreground ecosystem construction. For example, you can to other users through quota leasing agreement to build a dApplet engine based on HTML5 in the mobile improve the efficiency of system resource utilization. wallet application of Vite, allowing developers to develop and publish dApp at low cost. 11 Thanks 10 Summary Sincerely, we would like to thank our consultants for their guidance and assistance to this article. Especially We would Compared with other similar projects, the characteristics of like to appreciate the contribution of Loopring team and Vite include: Loopring community to this project. 17

References [1] Daniel Wang, Jay Zhou, Alex Wang, and Matthew Finestone. Loopring: A decentralized token exchange protocol. URL [2] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system. 2008. [3] Gavin Wood. Ethereum: A secure decentralised generalised transaction ledger. Ethereum Project Yellow Paper, 151, 2014. [4] Vitalik Buterin. Ethereum: a next generation smart contract and decentralized application platform (2013). URL http://ethereum. org/ethereum.html, 2017. [5] Chris Dannen. Introducing Ethereum and Solidity. Springer, 2017. [6] Jae Kwon and Ethan Buchman. Cosmos a network of distributed ledgers. URL [7] Anonymous. aelf - a multi-chain parallel computing blockchain framework. URL, 2018. [8] Anton Churyumov. Byteball: A decentralized system for storage and transfer of value. URL [9] Serguei Popov. The tangle. URL [10] Colin LeMahieu. Raiblocks: A feeless distributed cryptocurrency network. URL [11] Anonymous. Delegated proof-of-stake consensus, a robust and flexible consensus protocol. URL [12] Bernardo David, Peter Gazi, Aggelos Kiayias, and Alexander Russell. Ouroboros praos: An adaptively-secure, semi- synchronous proof-of-stake blockchain. URL, 2017. [13] Anonymous. technical white paper v2. URL [14] Dai Patrick, Neil Mahi, Jordan Earls, and Alex Norta. Smart-contract value-transfer protocols on a distributed mobile application platform. URL, 2017. [15] Ed Eykholt, Lucius Meredith, and Joseph Denman. Rchain platform architecture. URL http://rchain- [16] Anonymous. Neo white paper a distributed network for the smart economy. URL us/index.html. [17] Anonymous. Byzantine consensus algorithm. URL Consensus-Algorithm. [18] Shapiro Marc, Nuno Preguiça, Carlos Baquero, and Marek Zawirski. Conflict-free replicated data types. URL, 2011. [19] Deshpande and Jayant V. On continuity of a partial order. Proc. Amer. Math. Soc. 19 (1968), 383-386, 1968. [20] Weisstein and Eric W. Hasse diagram. URL [21] Chunming Liu. Snapshot chain: An improvement on block-lattice. URL [22] Anonymous. Problems. URL [23] Dantheman. Dpos consensus algorithm - the missing white paper. URL consensus-algorithm-this-missing-white-paper. [24] Theo Haerder and Andreas Reuter. Principles of transaction-oriented database recovery. ACM Comput. Surv., 15(4):287–317, December 1983. 18

[25] Dan Pritchett. Base: An acid alternative. Queue, 6(3):48–55, May 2008. [26] Jeff Hanson. Event-driven services in soa. URL services-in-soa.html. [27] Michael Sipser. Introduction to the Theory of Computation. PWS Publishing, second edition, 2006. Appendices Appendix A EVM Instruction set A.0.1 0s: Stop and algebraic operation instruction set No. Words POP PUSH Semantics in EVM Semantics in Vite 0x00 STOP 0 0 Stop to Excute. Sanme semantics 0x01 ADD 2 1 Add two operands. Same semantics 0x02 MUL 2 1 Multiplying two operands. Same semantics 0x03 SUB 2 1 Subtracting two operands. Same semantics 0x04 DIV 2 1 Divide two operands Same semantics If the divisor is 0 then returns 0 0x05 SDIV 2 1 Divided with symbol. Same semantics 0x06 MOD 2 1 Modulus Operation. Same semantics 0x07 SMOD 2 1 Modulus with symbol. Same semantics 0x08 ADDMOD 3 1 Add the first two Same semantics operands and module with 3rd 0x09 MULMOD 3 1 Mmultiply the first two Same semantics operands and module with 3rd 0x0a EXP 2 1 The square of two operands. Same semantics 0x0b SIGNEXTEND 2 1 Symbol extension. Same semantics 19

A.0.2 10s: Comparison and bit operation instruction set No. Words POP PUSH Semantics in EVM Semantics in Vite 0x10 LT 2 1 less than. Same semantics 0x11 GT 2 1 greater than. Same semantics 0x12 SLT 2 1 less than with symbol. Same semantics 0x13 SGT 2 1 greater than with symbol. Same semantics 0x14 EQ 2 1 equal to. Same semantics 0x15 ISZERO 1 1 if it is 0. Same semantics 0x16 AND 2 1 And by bit. Same semantics 0x17 OR 2 1 Or by bit. Same semantics 0x18 XOR 2 1 Xor by bit. Same semantics 0x19 NOT 1 1 Nor by bit. Same semantics 0x1a BYTE 2 1 Take one of byte Same semantics from the second operands. A.0.3 20s: SHA3 instruction set No. Words PoP PUSH Semantics in EVM Semantics in Vite 0x20 SHA3 2 1 Calculate Keccak-256 hash. Same semantics 20

A.0.4 30s: Environmental information instruction set No. Words POP PUSH Semantics in EVM Semantics in Vite 0x30 ADDRESS 0 1 Obtain address . Same semantics of current account 0x31 BALANCE 1 1 Obtain the balance Same semantics. of an account. returned is the vite balance of account 0x32 ORIGIN 0 1 Obtain the sender Different samantics addresss of original transaction return 0 forever Vite doesn’t maintain the causal relationship between internal transaction and user transaction. 0x33 CALLER 0 1 Obtain the address Same semantics. of direct caller. 0x34 CALLVALUE 0 1 Obtain the transferred Same semantics amount in called transaction. 0x35 CALLDATALOAD 1 1 Obtain the parameter Same semantics in this calling 0x36 CALLDATASIZE 0 1 Obtain size of Same semantics parameter data in this calling. 0x37 CALLDATACOPY 3 0 Copy called parameter Same semantics data into memory. 0x38 CODESIZE 0 1 Obtain the size Same semantics of the running code in current environment. 0x39 CODECOPY 3 0 Copy the running Same semantics code in current environment into memory. 0x3a GASPRICE 0 1 Obtain the gas . Different samantics price in current enviroment ,return 0 forever. 0x3b EXTCODESIZE 1 1 Obtain the code Same semantics size of an account. 0x3c EXTCODECOPY 4 0 Copy the code of. Same semantics an account into memory 0x3d RETURNDATASIZE 0 1 Obtain data size Same semantics of returned from previous calling. 0x3e RETURNDATACOPY 3 0 Copy the returned Same semantics data calling previously into memory into memory. 21

A.0.5 40s: Block info instructions set No. Words POP PUSH Semantics in EVM Semantics in Vite 0x40 BLOCKHASH 1 1 Obtain hash of a block. Different semantic. return Hash of corresponing snapshot block. 0x41 COINBASE 0 1 Obtain the address. Different semantic. of miner beneficiary in current block return 0 forever. 0x42 TIMESTAMP 0 1 Return timestamp Different semantic. of current block. return 0 forever. 0x43 NUMBER 0 1 Return the number Different semantic. or current block. Return the number of responding transaction block in account chain 0x44 DIFFICULTY 0 1 Return the difficulty Different semantic. of the block. return 0 forever. 0x45 GASLIMIT 0 1 Return the gas. Different semantic. limitation of the block return 0 forever. A.0.6 50s: Stach฀Memory฀Storege฀Control stream operation instruction set No. Words POP PUSH Semantics in EVM Semantics in Vite 0x50 POP 1 0 Pop one data Same semantics from top of stack. 0x51 MLOAD 1 1 load a word from memory. Same semantics 0x52 MSTORE 2 0 Save a word to memory Same semantics 0x53 MSTORE8 2 0 Save a byte to memory. Same semantics 0x54 SLOAD 1 1 Load a word from storage. Same semantics 0x55 SSTORE 2 0 Save a word into storage. Same semantics 0x56 JUMP 1 0 Jump instructions. Same semantics 0x57 JUMPI 2 0 Jump instructions with condition. Same semantics 0x58 PC 0 1 Obtain program counter’s value. Same semantics 0x59 MSIZE 0 1 Obtain size of memory. Same semantics 0x5a GAS 0 1 Obtain available gas . Different semantic. return 0 forever. 0x5b JUMPDEST 0 0 Mark a destination of jumping . Same semantics 22

A.0.7 60s and 70s: Stack operation instructions No. Words POP PUSH Semantics in EVM Semantics in Vite 0x60 PUSH1 0 1 Push one byte object. Same semantics into top of stack 0x61 PUSH2 0 1 Push two bytes object Same semantics into top of stack. .. .. .. .. .. . . . . . 0x7f PUSH32 0 1 Push 32 bytes object Same semantics (whole word) into top of stack A.0.8 80s: Duplication operation instructions No. Words POP PUSH Semantics in EVM Semantics in Vite 0x80 DUP1 1 2 Duplicate 1st object and Same semantics push it into top of stack. 0x81 DUP2 2 3 Duplicate 2nd object . Same semantics and push it into top of stack. .. .. .. .. .. . . . . . 0x8f DUP16 16 17 Duplicate 16th object Same semantics and push it into top of stack. A.0.9 90s: Swap operation instructions No. Words POP PUSH Semantics in EVM Semantics in Vite 0x90 SWAP1 2 2 Swap 1st and 2nd Same semantics object in stack. 0x91 SWAP2 3 3 Swap 1st and 3rd Same semantics object in stack. .. .. .. .. .. . . . . . 0x9f SWAP16 17 17 Swap 1st and 17th Same semantics object in stack. A.0.10 a0s: Log operation instructions No. Words POP PUSH Semantics in EVM Semantics in Vite 0xa0 LOG0 2 0 Extend log record, Same semantics no scheme. 0xa1 LOG1 3 0 Extend log record,. Same semantics 1 scheme .. .. .. .. .. . . . . . 0xa4 LOG4 6 0 Extend log record,. Same semantics 4 schemes 23

A.0.11 f0s: System operation instructions No. Words POP PUSH Semantics in EVM Semantics in Vite 0xf0 CREATE 3 1 Create a new contract. Same semantics 0xf1 CALL 7 1 Call another contract. Different semantic. indicate sending a message to an account The returned vale is 0 forever. 0xf2 CALLCODE 7 1 Call the code of Same semantics another contract Change the status of account. 0xf3 RETURN 2 0 Stop execution Same semantics and return value. 0xf4 DELEGATECALL 6 1 Call the code of Same semantics another contract, change contract, change current account status keep original transaction info. 0xfa STATICCALL 6 1 Call another contract, Different semantic. not allow to change status. represents to sending message to a contract, don’t change status of target contract. return 0 forever.needed result Sending another message through target contract and return. 0xfd REVERT 2 0 Stop execution and . Same semantics recover status and return value no semantics of returning left gas. 0xfe INVALID ∅ ∅ invalid instructions. Same semantics 0xff SELFDESTRUCT 1 0 Stop execution, Same semantics set the contract as waiting for deleting return all balance. 24