Hi AELF team. I was going to write an article describing your project and the project’s goals, but your whitepaper is full of grammar errors.

So instead, here’s your whitepaper, at least the Abstract and Section 1, corrected of errors.

Sorry but correcting the whole thing for free wouldn't be worth my time. 

Between the 12% of your team's funds spent on "marketing" and the 25% spent on "foundation", I'm pretty surprised you couldn't find the effort to properly have your works translated. You should consider hiring a competent editor when you translate your whitepaper from Chinese to English next time, and get a refund on whoever you paid in the meantime.

I want to stress that I'm not trying to be insulting. I don't speak Chinese, and the programmers behind this team are clearly far more intelligent than myself. But the gratuitous use of capitalization for nouns just makes the whole thing hard to read. 

"Blockchain" is not a proper noun anymore than "wireless" is. It should not be capitalized. For example,

"Have you heard about wireless technology?"

"Have you heard about blockchain technology?"

If you don't believe me, look at the writing standards used in this article.

Or, use the COCA to see how words are used in English daily-use.  

Whenever I find an error, my commentary will be beside that error in bold text, or the error itself is in bold.

Abstract

Over the past few years, The Blockchain (why is this capitalized? It is not a proper noun. It is not a brand name (Pepsi, Microsoft). It is referring to a technology. We don't capitalize "electronics". If you are referring to a proprietary blockchain, for example, the Ethereum Blockchain, it can be capitalized, because Ethereum is a brand, and you are referring to a specific proper noun (name) and not just a thing (blockchain technology)) community has seen rapid development. Since Satoshi’s Bitcoin emerged as secured, decentralized Peer-to-Peer (again, why is this capitalized? peer-to-peer) transfer mechanism, the concept of a decentralized crypto-currency became mainstream and changed the world of finance forever. Ethereum then expanded on that idea with the successful implementation of versatile "Smart Contracts,” (yet again, not necessary to capitalize this. It is a technology mechanism, not a proper noun) unleashing the potential of Blockchain (!) into numerous applications and industries. As a result, many alternative crypto assets were built upon these Blockchains (!!). But the boundary between the Blockchain (!!!) community and the business world has yet to be broken. We believe we have reached a turning point in Blockchain (!!!!), with the next phase leading to the integration of Blockchain (!!!!!) and the physical business world, and inevitably bringing in solid digital assets.

In order to enter the new paradigm of Blockchain (!!!!!!), there needs to be a versatile Operating System (no need for capitalization) designed to meet commercial needs. This Chain(capitalization) must address three main challenges:

1. Current Blockchains are not scalable, as the performance of one single node/mining machine determines the performance of the whole system.
2. Current Blockchains do not segregate resources for different Smart Contracts, which causes to interference between (remove "to") Smart Contract (cptl) executions.
3. Current Blockchains do not have pre-defined Consensus Protocol (should be either "do not have a pre-defined consensus protocol" or "do not have pre-defined consensus protocols") to adopt updates or adapt to new technology.

This white paper introduces a highly efficient Blockchain architecture that incorporates State-of-the Art (no need for capitalization) IT design principles and technologies to bring Blockchain up to a commercial standard. We envision it creates a "Linux eco-system" (just "ecosystem") for Blockchain. We focus on defining and providing the most basic, essential and time-consuming to develop components of the system and on making significant improvements for existing Chains in the market. The system allows developers to customize Chains to meet their own needs, particularly commercial requirements for various industries. It will contain the following main features:

1. A Main Chain and multi-layer Side Chains to handle various commercial scenarios. One chain is designed for one use case, distributing different tasks
on multiple chains and improving processing efficiency
2. Communication with external Blockchain systems, such as Bitcoin and Ethereum, via messaging
3. Parallel processing for non-competing transactions and cloud-based service (cloud-based services. This should be plural, as there is more than one service being offered with this technology)
4. Basic components of minimum viable Block and Genesis Smart Contract Collection for each Chain to reduce data complexity and achieve high  customization

(This whole sentence should be rephrased as it is very confusing. Maybe something like, "The basic components of a minimally viable blockchain and genesis smart-contract-collections available to each chain in order to reduce data complexity and achieve high customization." 

5. The permission for stakeholders to approve amendments to the protocol, including redefining the Consensus Protocol; Permission for Side Chains to join or exit from the Main Chain dynamically based on a/the Consensus Protocol, and therefore introduce competition and incentive to improve each Side Chain. (note: as for "Side Chain" and "Main Chain", unless these are specific protocol names, they aren't proper nouns but common nouns and as such, shouldn't be capitalized). 

...

1. Current Blockchain Systems
The Blockchain technology and its applications are developing exponentially. Many industries are migrating from traditional network architecture to a Blockchain-based network architecture. However, current Blockchain systems are not yet capable or efficient enough to function as a versatile operating system and support multiple applications. Bitcoin, the pioneering Blockchain design, is more similar to an application. Ethereum has demonstrated some characteristics of an Operating System (this is arguable, as the abbreviation is capitalized as OS, but I would argue it shouldn't be capitalized because it is a common noun, like 'human' or 'language') – developers can program applications such as Smart Contracts, and the Chain provides programming language and Adaptor (not sure what this means. "...provides an adaptor", maybe?) in the form of Solidity.

However, from the perspective of a modern Operating System, Ethereum still has several drawbacks, such as the lack of decoupling between system components, the lack of customization of most modules, and insufficient system interfaces, among others. This approach lacks the holistic design of aelf (oh come on! If you're going to capitalize everything with gratuity, at least capitalize your own blockchain name! Use Aelf, because it is the titel of a brand/protocol, or AELF if it is an acronym) and is not yet commercially viable for cross-industry application scenarios. It greatly limits the commercial application of Blockchain technology.

1.1. General Blockchain vs. Complex Business Scenarios

The largest challenge facing commercial scale adoption of Blockchain technology is its current inability to meet the requirements of multiple, diverse, and complex business scenarios. Naturally, different scenarios often have different characteristics in terms of process and execution logic, and thus require distinct solutions. Therefore, the "one size fits all" Blockchain approach that is currently utilized by other chains is not viable if Blockchain is to succeed in the future.

For example, ticket issuance (consider "issuing tickets") requires high frequency where a high transaction rate in the system is desirable (consider "requires a high frequency of transactions in a system where a high transaction rate is desirable), while digital legal contracts emphasize high security and reliability over speed. It simply does not make sense for them both to be built around the same Chain.

There are two general solutions to this problem:
i. Use Blockchain as solely a database not deal with business logic. (This sentence is wrong. It should read something like "Use blockchain solely as a database and not deal with business logic.") This approach aims to handle any business scenario and maintain compatibility. Many Chains similar to Bitcoin use this approach. They record business related data and hash into a transaction output "OP_RETURN", which is stored in the Blockchain.

ii. Record various complex Smart Contracts onto one single Blockchain. These Smart Contracts serve pre-defined business models from various scenarios. Ethereum represents this type of Chain. Due to the fact that all Smart Contracts are written on one single Chain, the Blockchain becomes overly complex, requires a high maintenance cost, and lacks an effective structure to execute smart contracts.

1.2. Performance Limitation of Sequential Processing

As Blockchain becomes more and more widely used, especially for handling large scale transactions, its transaction processing capacity faces tremendous pressure when using sequential processing, which results in the bottleneck of network performance. Current Blockchain systems face multiple challenges to improving capacity, sometimes at the expense of transaction efficiency. For example, the Bitcoin transaction fee is getting more expensive as transaction volume increases and a large backlog waits for confirmation. Ethereum faces an increasing number of congestions during token sales. However, in traditional IT architecture, modern techniques such as partitioning, sharding and decentralized architecture have proven highly effective at
improving system performance.

On the other hand, the concept of parallel task processing has not been adopted to increase efficiency. When a Block contains (a) large amount of transaction data and complex Smart Contracts, sequential transaction has hit its efficiency limitation of
Block formation and verification.

1.3. Data Complexity and Redundancy

As described in Section 1.1, one universal Blockchain is used to meet the needs of different business scenarios. The drawbacks of a universal Blockchain system are overly-complex Smart Contracts and Consensus Protocols, lack of tailored solutions
to specific business scenarios, and redundant data.

1.4. Dilemma of Protocol Update
Despite the increasing adoption of Blockchain, it is still in its nascent stage. Many significant improvements and innovations are yet to come. These updates are essential to evolve Blockchains and keep up with an ever-changing environment and
stakeholder's interest. The large variety of stakeholders within the eco-system usually makes it difficult reach consensus without effective governance mechanisms, leading most current Protocol updates into impasse or disputes. One vivid example is Bitcoin, as the community found it difficult to reach agreements for the introduction of many new features in recent years.

1.5. Inflation of Block(s) (should be plural)
The more successful a Blockchain system is, the higher its maintenance cost. Running through a full Current Bitcoin node requires over 130G(b? shouldn't this be Gb?) of space, and Ethereum requires over 180G. This situation will not be improved in the future. As more users adopt Blockchain and conduct more transaction activities, the inflation of Blocks will
accelerate and the maintenance cost will grow even higher. Actions must be taken to alleviate this vicious cycle.

1.6. Inefficient Point-to-Point Communication Support
Existing Blockchains mainly communicate through on a broadcast network where the support for P2P communication is inefficient and insecure. One example is that if certain data only concerns a single group of users, that data should be communicated among finite nodes, not broadcasted to all nodes.

1.7. Pending Breakthrough for Cross-Chain Communication
Existing Blockchain systems have experimented with cross-chain communication to process related business logics. However, the outcomes have been unsatisfactory. Current cross-chain communication includes the centralized mechanism and the
HTLC mechanism. The centralized mechanism deviates from the idea of Blockchain, and leads to lack of trust, single node failure, single node bottleneck, and is only applicable to certain scenarios. The HTLC mechanism can also only deal with specific scenarios, such as asset exchange, and imposes strict requirements on the protocols and Consensus Protocols of communicating chains. And implementation of such a mechanism is usually complex. As a result, it is imperative to address two critical issues: Protocol compatibility and data exchanging format compatibility.

That is it from me! Signing off!