VITE Q&A

Leo is a general-purpose platform for decentralized applications. It is designed to support industrial-strength applications by offering high throughput, low latency and scalability while also providing security.

The Leo team are dedicated to addressing current performance and scalability issues of infrastructural chains, so that truly practical applications with high-frequency data requirements can be built in a blockchain framework.

Loopring is our strategic investor, and its founder Daniel Wang serves as Leo’s advisor. Loopring’s decentralized exchange function will be offered in a wallet application built on the Leo platform. Loopring will be the first practical use case for the Leo platform.

There will be. Stay tuned for amount and mechanism.

We are in contact with multiple exchanges, but there is no specific timetable. Leo is a long-term, tech-driven project, and we don’t plan to run our operations at an aggressive pace.

Our official account: Leolabs

The biggest innovation is the asynchronous design, which can be understood in three aspects:

First, we are introducing the concept of asynchronous design into smart contracts. The Nano project (one of three well-known chains that use DAG) separates a transfer action into a send and a receive transaction. We are building upon this mechanism, and will separate the call and the response of a smart contract, so they can take place asynchronously.

Second, the writing and verification of a transaction also happen asynchronously in Leo. In traditional blockchain setup (e.g., Bitcoin), the speed of writing transactions into a ledger is limited by the speed of packing. But Leo allows writing of many transactions into the ledger within the constraints of the TPS. Because the asynchronous setup allows the transactions to happen at an even speed, this reduces the peaks and troughs of the speed of transaction writing, thus optimizing usage of resources and increasing system throughput. Also, the transactions of two users will no longer be blocked; that is, we will no longer see a scenario where a user sends a large amount of transactions that prevents the transactions of other users from taking place.

Third, calls between contracts will also happen asynchronously in Leo. The calls between smart contracts in Ethereum are implemented through messaging (aka insider transactions); and the calls either all succeed or all fail, as per an atomic ACID semantic. To solve for this bottleneck in performance, we take a page from well-developed solutions in centralized Internet technologies, and will make use of a message-driven architecture. As such, contracts do not share states and communicate via messages.

Unfortunately, these calls are not compatible with Leo. Synchronous calls need to be changed to asynchronous calls to work in Leo.

On a high level, the differences are similar to those of C and C++. In basic syntax, the two languages are largely compatible. The largest difference is in the synchronous (Ethereum) vs asynchronous (Leo) calls as mentioned earlier.

In addition, a series of standard libraries, such as string manipulation, floating-point operations, basic mathematical operations, containers, and sorting will be provided in Solidity++.

Leo will provide Solidity++ contract language and a complete SDK to reduce the cost of asynchronous programming.

After rigorous research, we find that in practical use cases, strong consistency semantics can be replaced by BASE semantics. Since the HDPoS consensus algorithm of Leo can guarantee transaction confirmation within 1 second, any potential latency increase is still under control.

Leo employs a ledger structure called block-lattice. Each account corresponds to a blockchain and each transaction refers to the hash of the previous transaction in the account. Transactions are divided into two types: "request transactions" and "response transactions.” A response transaction needs to quote the corresponding hash of the request transaction.

The DAG structure has an inherent deficiency in security. This is because transactions are grouped by accounts, and each transaction is only attached to the chain associated with the relevant account. Transactions generated by other accounts do not automatically become the subsequent nodes of the previous transaction. Therefore, for some transactions, the rollback probability will not drop over time. The Snapshot chain technology is meant to address this issue.

Yes. Leo will support value transfers between different chains but not other inter-chain functions such as message transfers or smart contract calls between chains.

Yes, one of Leo’s goals is to reduce the cost of porting over dApps from Ethereum. Leo tries to maximize compatibility with EVM.

Leo won’t support mobile. There are no current plans to support other languages. In the future, we will set up a VM Lab to continue research in smart contract language and virtual machine. We welcome participation from experts in these areas.