Vite

Questionable project that offers a rather complex solution for dApps. "Vite is an asynchronous solution with a DAG-based ledger." They promise to offer "high throughput, low latency and scalability while also providing security." Their GitHub is currently empty - no product as such; just promises. Their alpha seems far away - and we have a lot of interesting questions for them.

Our verdict as of right now: Questionable!

Overview

Concept

Vite is an asynchronous solution with a DAG-based ledger.

Or as they put it:

"Vite is a next-generation Reactive Blockchain that adopts a message-driven, asynchronous architecture and a DAG-based ledger"

Actual Product

The goal for Vite’s design is to provide a reliable public platform for industrial dApps, with features of ultra-high throughput and scalability. Again, it's too early to tell what they will deliver.

Site

One-pager - no search, registration form, dynamic content, etc. Source code is on the project's GitHub. IP protected by CloudFlare (which is standard at this point).

Social Media

Discord - 478 members
Twitter - 800 followers, 5 posts (2 of which have anything to do with the project)
Medium - just published their first post
Reddit - 3 posts.
Telegram - 8300 members (finally, some activity). The channel is actively growing, and the admins try to reply timely and substantially.

So far, total fiasco in their social accounts (for both the project as a whole and each of its team members). They need to step it up, big time. And their follower counts have been growing rapidly in the past week. Plus they finally published a Medium post. Though after 4 months of the project, we expect more.

Team

Chunming Liu is the project’s founder. His career span included such companies as Meituan, Coinport, and JD Group. His LinkedIn profile shows a connection with Vite Labs Limited, though (oddly), it links to vitelabs.com (which doesn’t even exist) rather than vite.org. (must be hard to remember own company’s URL, right?). His Twitter account was created alongside the project (March 2018), and he even made 3 (!) posts already. GitHub is also registered specifically for this project. He’s the only one from the team making commits to it.

Ming Wu spent his entire career at Microsoft. In his 11 years there, he went from Researcher all the way to Senior Research Manager. In 2007, got his Ph.D. in Computer Architecture. Published several papers about distributed systems and AI. Knows Chunming Liu from them both being students at the University of Science and Technology of China. Doesn't associate himself with the project on social media. His only other link is to his empty profile on GitHub.

Richard Yan is the project's COO. He got his MBA in 2014 at NYU's Stern School of Business, and had a multicompany career in investment banking (the longest stint being at Goldman Sachs). He's a strong expert with serious expertise in his area. Does associate himself with the project on LinkedIn. And yes, another link to an empty GitHub...

Advisors

The project lists 4 advisors. Daniel Wang and Johnston Chen represent the Loopring Foundation. Daniel Wang is promoting the project in his social networks. VITE will have Loopring Protocol Integrated. Daniel Wang invested 1000 ETH into VITE and then sold those VITE tokens in a private sale.

"On May 1st, I’ll create an order on http://loopring.io to sell 1000-2000 ETH worth of VITE for ETH & LRC at the private sale price. If you want to buy their tokens without going though their KYC process, buy VITE from me without trust."

Terence Lam is an expert with experience. He graduated from Harvard Business School and has a lot of experience investing into and working with blockchain projects. The remaining advisor, Frank Deng, is a real ghost - found no info on him (but hey, at least cool pic on the project's homepage).

Overall, the collection of competencies among the team and the advisors should be enough to get the project to succeed (though Frank Deng needs to become a real person soon).

Roadmap

Feb 2018 - Initiation of Project
April 2018 - System design of Vite, completion of white paper
May 2018 - Release the official website / Road show
June 2018 - Beginning of Vite Core's R&D
Oct 2018 - Vite Core alpha
Dec 2018 - Vite Core beta M1: Trading / Issuance of assets / Hierarchical consensus algorithm / Snapshot chain / Release Vite SDK / Vite Blockchain browser
Jan 2019 - Desktop client of Vite
Feb 2019 - Alpha version of Vite mobile app
April 2019 - Vite Core beta M2: Smart Contract / Solidity++ Compiler / Smart Contract API Documentation
May 2019 - Vite Core beta M3: Quota leasing / Contract timing scheduling / VNS naming services / Vite dApplet / support within Mobile app
July 2019 - Vite Core beta M4：Loopring / Ethereum cross-chain gateway
Aug 2019 - Vite integrated decentralized trading function within Mobile app
Oct 2019 - Vite Core beta M5: Contract upgrade / Block pruning / Solidity++ optimization
Nov 2019 - Vite Testnet Release
Jan 2020 - Vite 1.0 Release
Feb 2020 - Kickoff of plan for ecosystem development in Vite

Whitepaper

1. Introduction

Here, they define key concepts, such as Transactional State Machine, Ledger, Fork, False Fork, etc. They do a quick overview of existing solutions and support their definitions with math. Based on this quick overview, they discuss several paths for improving upon existing solutions:

Improving the system state
Improving the state transition function
Improving the structure of the ledger
Improving the consensus algorithm

Improve the state of the system:
Make it so every node doesn't have to store every transaction.

Improve state transition function:
Provide more abundant smart contract programming languages.

Improve the ledger structure:
Change the linear ledger to a nonlinear ledger that only records partial order relations (DAG for example).

Improve consensus algorithm:
Implement an improved consensus algorithm to increase the throughput capacity of the system and decrease the likelihood of a false fork.

Each new project solves these problems in its own way. Some add support for various programming languages to create smart contracts (Java, C#, C/C++, etc.). Some use DAG instead of a linear blockchain. Some research and develop new consensus algorithms or limit the number of users authorized to produce ledgers.

In the next section, they offer their own improvements.

2. Ledgers

Here, they list 4 different ledger structures as examples:

Flat set: typical centralized system without any tamper-proof features.
Block-lattice: DAG ledger used by Nano; maintains less partial order relations with high performance.
Tangle Book: DAG ledger used by IOTA; maintains more partial order relations than Block-lattice, offering better tamper-proof features.
Block chain: Typical blockchain ledger with the best tamper-proof features.

In the meantime, Vite uses a composite approach. They're using DAG ledger structure alongside an additional "Snapshot Chain" chain structure and an improved consensus algorithm. More details below.

For transactions, they use an asynchronous model. So if Alice and Bob have $10 respectively, and Alice wants to transfer $2 to Bob - that transaction splits into two:

A transaction that represents transferring of $2 by Alice
A transaction that represents receiving of $2 by Bob

These two transactions are executed asynchronously and increase the speed of transactions overall. As soon as the platform registers both transactions, the system will correct the balance and Alice will have $8, while Bob will have $12 in his account.

The Vite ledger is structurally similar to a Block-lattice. "Transactions are divided into request and response transactions, each of which corresponds to a separate block, each account corresponds to a chain, a transaction pair, and a response transaction referencing the hash of its corresponding request transaction."

3. Snapshot chain

In case an alternative branch appears in the blockchain, the longer one is selected. All the changes in the short branch are rolled back. In this case, a double spend situation may occur. So, for example, if you pay for a car using the coin, the transaction may wind up in the rolled back block. So, as the transaction is rolled back and the money is refunded to the buyer, the car is still purchased. The seller becomes the victim - no money and no car.

In a linear blockchain, this problem can be solved as follows: the transaction awaits a certain number of confirmations before it is deemed complete.

To solve this problem, DAG-based system scan use a voting based consensus algorithm. And the confirmation of transactions is done via voting. Each node, in turn, has a specific voting weight.

This approach has several problems:

For greater reliability of the confirmation, the minimum threshold of a vote's weight is increased. And if the network at the moment of the voting for the confirmation doesn't have enough voters with enough voting weight, the transaction might not get confirmed at all.
With this approach, the probability of transaction rollback doesn't decrease with time but remains constant.
The given mechanism adds centralization to the system.

Vite solves this problem using a Snapshot chain.

Snapshot chain is a sort of a blockchain on top of the Vite ledger that takes snapshots of the states of the Vite ledger.

I.e., we have the speed of DAG and the security of Linear blockchain.

A transaction is considered confirmed only after it's been confirmed in the Snapshot chain.

To generate a double spending situation, a malicious actor - in addition to rebuilding the hash reference in the Vite ledger - has to rebuild it in the snapshot chain for all the blocks after the first snapshot block of the transaction (and needs to produce a longer snapshot chain) - which significant raises the difficulty and cost of an attack.

There is one drawback here: when two Snapshot chain branches appear, the longer one will be selected.
And that will roll back any changes in the Vite ledger.

Every subsequent snapshot contains only the changes of the previous snapshot. This compresses snapshot chain storage space.

4. Consensus

Basing it on the DPoS algorithm with a bit of modification, they created an HDPoS (Hierarchical Delegated Proof of Stake). The point of this algorithm is to divide the consensus forming functions in to a Local consensus and a Global consensus.

"Local consensus generates the blocks corresponding to request transactions and response transaction in the user account or contract account, and writes to the ledgers."
"Global consensus snapshots the data in the ledger and generates snapshot blocks."

Users can be gathered into various Consensus Groups and selected various consensus parameters with flexibility:

Consensus Group of Snapshot
Private Consensus Group
Delegate Consensus Group

Consensus Group of Snapshot:
The most important Consensus Group in the entire system. Responsible for achieving consensus in the Snapshot chain.

Private Consensus Group:
"The blocks can only be produced by the owner of the private key of the account. By default, all user accounts belong to the private consensus group."

The main merit of this approach is in making the initiation of a double spend situation the exclusive responsibility of the user (worst case scenario, it'll be the responsibility of a program error). This reduces the probability of there appearing a second branch of blocks.

The main drawback is that both users who want to make a transaction between each other must be online. Otherwise, there will be no one to generate a receiving transaction.

Delegate Consensus Group:
Instead of users, they have here proxy nodes. Can add into it both users and contracts.

The network also has a public consensus group, which "helps package transactions for all the other accounts that haven’t established their delegate consensus group individually."

The Priority of the Consensus
"The priority of global consensus is higher than that of local consensus."

Asynchronous Model
The following operations are performed asynchronously:

Requests and responses (Like the Alice/Bob example)
Writing and confirmation of transactions (in the Snapshot chain)
Communications between contracts (Via message-driven architecture)

5. Virtual Machine

They have their own virtual machine for launching smart contracts. With that in mind, it's partially compatible with Ethereum's virtual machine. "Because Vite’s account structure and transaction definition is different from Ethereum, the semantics of some EVM instructions need to be redefined, for example, a set of instructions to get block information." If interested to know more, read the whitepaper's addendum.

They modified Solidity for their own platform, creating Solidity++. This new language is event-driven and works asynchronously. So to communicate between contracts, Contract A sends a message/signal into Contract B, and Contract B needs to point listener to the event that will perform the function listed in the message/signal.

They will also add a number of standard libraries that are so badly needed in Solidity (I'm not even being sarcastic). Unfortunately, no one will add a random number generator because of the idiosynchrasies of the architecture.

Smart contracts use something like gas (more on that below).

6. Economic Model

To maintain the work of computing and storage resources and encourage nodes to run, they use a native token - ViteToken.

Forming new blocks in the Snapshot chain is rewarded in those tokens.

Token inflation will be limited to 3% per year.

Every time someone issues new tokens, places contracts, registers VNS names, or obtains resource quotas, they need to consume or mortgage ViteToken to reduce the liquidity.

The network uses mechanism quotas instead of gas. To perform transactions, user contracts have a limited time cost for transactions. The more often you call on the contract, the higher the time cost of transactions. Users can "increase quotas by paying a one-time fee, or wait for a period of time to quote a higher snapshot in the transaction."

If you have many ite assets but do not need the large quota, you can rent the quota to other users.

To issue your own tokens you simply need to send one correctly formed transaction to a specific address.

Cross Chain Protocol
To perform cross-chain transactions, Vite designed a Vite Crosschain Transfer Protocol (VCTP).

"For each target chain, there is a Gateway Contract on Vite to maintain the mapping relationship between Vite transactions and target chain transactions."

To exchange currencies, a temporary token is generated. It's processed on the gateway node where the exchange also occurs.

However, this reveals a very worrisome drawback: a roll back of both sides will lead to very tragic consequences...

Loopring Protocol
This is "an open protocol to build a decentralized asset trading network (DEX solution)." With this protocol, "users can issue their own digital assets, transfer assets outside the chain through VCTP, and achieve asset exchange."

7. Other Designs

They also offer several other useful features:

Scheduling (Specific tasks could be planned for later execution.)
Name Service (Short and understandable names instead of long smart contract and wallet names.)
Contract Update (Using the Name Service, can renew contract address without changing its domain name.)
Block Pruning (Nodes can chose which information to exclude from storage according to specific limitations. At the same time, a few nodes will keep full information about all transactions.)

8. Governance

To maintain an effective and healthy ecosystem, they use the following governance systems:

On-chain (Voting mechanism. Global voting for Snapshot chain, local voting for smart contracts. The delegated consensus group proxy node has the right to decide whether to allow the contract to be upgraded, for example)
-Off-chain (The community can offer its own ideas for improving the platform; those who have enough voting weight can vote for these changes.)

Whitepaper conclusion

The whitepaper is written in great detail, maybe even too detailed in the beginning. Could've skipped the details about choosing technology based on the analysis of other solutions. Everything is to the point; a lot of scary mathematical formulas, which are clearly written and explained. Everything is well-structured, written in understandable language. The illustrations really do help, mathematically supported, and well explained. The end of the whitepaper has plans for the future, citation links, and the EVM Instruction set.

Distribution

Vite has already completed a financing round. They expect to issue the first token to their investors before June 15th. A total of 400,000,000 Vite was issued, which accounted for 40% of the total circulation. All token issuance is divided into 5 times, 20% each time, one month apart.

Fundraising Allocation:

65% R&D
20% Marketing
5% Infrastructure
10% Other Costs

Token Allocation:

40% Private Sale
25% Ecology Fund
20% Team (2 years lock)
10% Marketing/Promotion
5% Community Airdrop

Smart contract

Typical ERC-20 smart contract. Didn't find any problematic code that could be used to exploit vulnerabilities.
https://etherscan.io/address/0x1b793E49237758dBD8b752AFC9Eb4b329d5Da016#code

Questions for the project

Q: If the target network is rolled back or hard forked, the mapped transactions in the Vite system cannot be rolled back. This provokes a double spending attack. For example, getting 1 ETH from the Ethereum blockchain, this 1 ETH remains in Vite's wallet EVEN IF the transaction for sending 1 ETH from Etherium to Vite is rolled back. Besides setting a delay parameter for the cross-chain Relay consensus group, will they have other defense mechanisms?

Q: Both users always having to be online to perform a transaction is a very annoying requirement. How will they solve this problem in the future?

Q: Using Loopring makes the project reliant on Loopring. What will happen to Vite if Loopring suddenly disappears, breaks, gets hacked, etc.? Do they have some action plan or mechanism to minimize the damage from such a situation?

Q: Will the Name Service be protected from a homograph attack?
[http://www.analyticsedge.com/2016/11/heres-a-secret-%C9%A2oogle-com-is-not-google-com/]
[https://en.wikipedia.org/wiki/IDN_homograph_attack]
If yes, how?
A:

Q: Contract Update. Hackers or malicious owners of the contract (aka, scammers) can change the internal structure of the smart contract - and users will think that everything is ok. How will this problem be solved? (If keyword static is purposefully not used.)

Will the delegation of a consensus group proxy node be mandatory to avoid the falsification of a smart contract?

Q: Block Pruning. Another sign of the centralization of the system. When all transaction data is stored only on certain nodes, knocking out those nodes or infecting them with a virus can have dire consequences. How justified is this decision? How many "full nodes" do they expect to have in the network? (Having enough full nodes in the network would mitigate the problem... though not fully solve it.)

Q: When coins outside of the Vite system are purchased, how will the situation be resolved where the coin's price changes in the time that it takes for a node to process it?

Conclusion

Basically, the team is offering up a layer cake of various technologies and their own developments. It should be noted that these technologies do combine together well, however it's often pretty hard to create and control such complex solutions. For such large ambitions, you need a team bigger than mere 3 people.

Everything in the whitepaper is logical, on point, and with detailed descriptions. Pretty good (albeit, small so far) team. The idea itself has merit. No questions for the Roadmap either.

However! Their GitHub is empty, there is no project itself, no SDK, and some serious questions that we asked above...

So, we're awaiting their Alpha slated for October. In the meantime...

Verdict

Questionable!

Disclaimer: The above audit is not in any way financial advice or a solicitation to buy - it's merely our collective opinion that we are kind enough to share with you. Don't make us regret that.

The report is prepared in partnership with https://t.me/ico_reports

Our links:

Scam or legit? Vite