DAG Ledger
The DAG ledger is comprised of multiple user account chains, multiple smart contract chains, a snapshot chain and the inter-relationships among account/contract chains.
For user account chain or smart contract chain, each chain contains request and response blocks. The block of user account chain is generated by the account owner. The block of smart contract chain is generated by the consensus group participants, such as the built-in Snapshot Consensus group which is composed of many super nodes by default. The block of the snapshot chain is produced by the eligible super node during this time.
All response blocks must depend on the relevant request blocks of other account or contract chains. The snapshot block needs to rely on all the account and contract blocks that are packed. This is what forms the ledger structure of Vite.
This ledger structure allows “in parallel” writes of unrelated transactions, reducing the probability of conflict and improving system throughput. However, this DAG structure does have inherent security flaws. Because transactions are grouped by account, one transaction will only be attached to the end of the account chain it belongs to, and the transactions generated by other accounts will not become the successor transactions, so the roll-back probability of some transactions will not decrease over time. Vite introduces a snapshot chain to addresses this issue.
Smart Contract
The development of essential built-in smart contracts is completed, including: super node registration, super node voting, Vite Token pledge, and creation of the Delegated consensus group. User-created smart contract compile and deployment will be supported shortly. Vite VM supports most EVM instructions to maintain maximum compatibility.
Super Node Registration
When a node applies for super node registration, it needs to start a registration transaction to mortgage 1 million Vite Token for 3 months, from the time when the snapshot block confirms the response transaction. After the response transaction is snapshot, the node is eligible for super node election. Repeated registration is not allowed.
Super Node Voting
User accounts can start a transaction to vote for a super node. One user may only vote for one node at a time. After a node has become a super node candidate for 3 months, it can send a transaction to cancel the eligibility and withdraw the deposit.
Vite Token Stake
The staker should designate a beneficial account, the amount of Vite tokens to stake and the expiration time in a stake request transaction. The beneficiary account obtains the corresponding quota during the stake period after the response transaction is snapshot.
A beneficiary account can benefit from multiple staker; a staker can designate multiple beneficiaries. The staker is able to retrieve the deposit after the stake time expires (start time + stake time) by specifying the beneficiary account and the amount of tokens to retrieve, which cannot be greater than the total stake amount by the staker for the beneficiary.
Creating A Delegation Consensus Group
Creating a delegation consensus group requires to mortgage 1000 Vite Tokens for at least 3 months. In this release the rules for super node registration and vote counting are built in the system, but user-defined rules may be supported in future.
HDPoS Consensus Mechanism
User accounts reach consensus through the private consensus group. Smart contract accounts reach consensus through the delegated consensus group. Snapshot chain reaches consensus through the snapshot consensus group.
The multi-layered consensus mechanism ensures that the ledger is written quickly and the Snapshot Chain guarantees the immutability of the ledger. Local consensus is achieved as soon as the request and response blocks are produced and respectively written into the ledger, while global consensus is achieved after the ledger status is snapshot and packed in a snapshot block by a super node.
Asynchronous Communication
The asynchronous design in Vite mainly includes three aspects:
- Asynchronous design of requests and responses
- Asynchronous design of transaction writing and confirmation
- Asynchronous design of communication among smart contracts
Transactions in Vite are separated into request and response transactions. Whether it is a token transfer or a smart contract call, two transactions will be generated on the ledger. The system throughput is effectively improved because sending a transaction or calling a smart contract will not be blocked due to an offline recipient or slow response. In addition, transactions of different accounts can be distributed on different nodes in the network at a certain time, implying higher system scalability.
Ledger writing and transaction confirmation are also asynchronous. Non-related users can write transactions into the ledger in parallel, and the snapshot chain takes a snapshot of the ledger at a fixed rate. Once a transaction is snapshot, it can be considered as confirmed. As the height of the snapshot chain grows, the confirmation number will increase. The asynchronous confirmation mechanism eliminates transaction peaks and process transactions at a relatively stable rate, so as to maximize the utilization of system resources.
Vite inter-contract communication leverages the message-driven architecture that relies on message sending. In this architecture, smart contracts do not share states among each other. Vite’s ledger plays a role as message middleware to guarantee the Exactly Once semantics of the messages. Message-based architecture has the advantage of high throughput and scalability.
However, the cost includes complex programming model, lack of strong consistency, and possible longer delay. After in-depth research, we found that in the actual scenario, strong consistency semantics can be replaced by BASE (final consistency) semantics. Since Vite’s HDPoS consensus algorithm can guarantee that the transaction can be confirmed in one second, the small increase in latency is still an acceptable trade-off.
Snapshot Chain
Super node is responsible for producing snapshot block. Super node will follow the election result to determine the order and the time to produce the next snapshot block. If the permission is granted, the super node will package the latest states of verified account blocks into a snapshot block. New produced snapshot block will be appended to local snapshot chain and broadcast.
According to super node election result, all nodes in the network are able to verify whether a broadcast snapshot block was produced by a legitimate super node in addition to validate block data correctness. Snapshot chain may fork due to factors such as unstable network. In this situation, the longest valid snapshot chain branch will be recognized as legit chain while other branches will be preserved in case that a longer branch appears subsequently.
If a fork does occur, the ledger will switch to the world state represented in the longest snapshot chain branch, with which all user account chains and smart contract chains also will be restored to keep consistency.
Token Forging
Vite TestNet will support native token forging function with a built-in smart contract. Unlike Ethereum users have to write and deploy their own ERC20 contract, all Vite users need to do is to send a certain transaction to the built-in token forging smart contract address, which is in ease of use. The transaction should include new token information and the forging contract address.
After the token forging transaction response block is successful validated, the specified amount of forged tokens will be sent to the user address in a separate request transaction. Token forging process completes after the snapshot chain snapshots all related transactions.
Trading Quota
In order to avoid the high transaction costs experienced with Bitcoin and Ethereum, Vite supports a fee-less quota-based model. The transaction fee was originally set up for system stability and to ensure rational transaction behavior. Vite proposes the concept of trading quota for this purpose. In Vite system there is not necessary to pay fees to send transactions or run smart contracts as long as users have adequate quotas.
Taking into account that users may have different demands of trading frequency, there are two ways to obtain quotas: PoW calculation and Vite Token mortgage. PoW serves as system throttling scheme and Vite will support low trading-frequency user to obtain necessary amount of quota by solving a simple PoW puzzle. However, if user needs to process a large amount of transactions within short period, PoW calculation won’t meet this requirement. Instead, the user should pledge Vite Tokens for the exchange of enough quotas. The more Vite Tokens are pledged, the more quotas are obtained, and the more transactions that can be sent and received per unit time. Retail payment is one scenario of high-frequency transactions.
In addition, considering the hardware restriction of PoW computing in light wallet and mobile wallet, Vite TestNet will provide the mining pool API for light users to calculate PoW in cloud.
Super Node Registration and Election
Vite TestNet will support users mortgage Vite Tokens to register for super node candidates and vote for them, by calling the built-in voting smart contract. The voting result in each round determines the super node sequence list of next round. In Vite TestNet there are 25 super nodes and each is responsible for producing 3 consecutive blocks in 3 seconds, which makes 75 seconds total for one round. When a super node realizes that a new round is about to start, it will query the voting results from the voting contract chain to create the sequence list of the 25 super nodes of the next round.
Transaction Optimization
Vite will be a high-throughput, low-latency, scalable and secure system. Lot of development efforts are input to refine the design of system functional modules and the cross-module interactions. The following technical design diagram shows how a transaction happens insider Vite system:
Module POOL is responsible for determining local ledger state. It receives snapshot block from Producer, transaction request block from Vite-RPC and transaction response block from On-Road Pool, as well as blocks sent from network by other nodes(SYNC).
Transaction request node: In Vite wallet or command line tool request node generates request blocks in module Vite-RPC and sends to POOL, which calls verification module Generator&Verifier to write the verified transaction data into local ledger and broadcasts through P2P-NET.
Transaction response node: Response node pulls request blocks from network when it signs in Vite wallet if it is the transaction recipient. Request blocks are handed over to On-Road Pool to produce relevant response blocks and broadcast to the network.
Mining node: The super node collects all the user blocks to pack all verified transactions into a snapshot block in current producing period and broadcasts it to the network.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Official: https://www.vite.org/
Telegram:
- English: https://t.me/vite_en
- Chinese（中文）: https://t.me/vite_zh
- Russian: https://t.me/vite_russia
- Korean: https://t.me/vite_korean
- Vietnamese: https://t.me/vite_vietnamese
- Thai: https://t.me/vite_thailand
Twitter：https://twitter.com/vitelabs
