Inter Blockchain Communication (IBC) involves both chains validating merkle proofs that are 1KB+ in size and involve dozens of cryptographic hash functions and/or 15+ signature verifications. In other words, the cost of validating a message from another chain is about 15x to 30x higher than the cost of validating normal transactions.
Fortunately, validating these proofs is trivial to parallelize as they do not depend upon blockchain state. A blockchain that only processed messages from other chains could easily consume 30 CPU cores while only sustaining a couple thousand transactions per second.
It is our belief that scaling via Inter Blockchain Communication will give almost unlimited scaling potential. This approach scales RAM, network, and CPU at the same time. Considering that signature verification, context-free-action validation and IBC proofs will already saturate most CPUs with high-single-threaded throughput, optimizing for multi-threaded WASM execution will likely be bottlenecked by other resource constraints.
Under EOSIO Dawn 3.0 we made a lot of design decisions around the potential for future multi-threaded WASM execution. Unfortunately, until you actually implement a full multi-threaded implementation it is impossible to know whether we have all the corner cases covered. This means that EOSIO Dawn 3.0 had a lot of architecture complexity that was not giving any immediate benefit.
We now believe that the path of upgrading from single-threaded to multi-threaded execution is to launch a new chain with multi-threaded support run by the same block producers and staking the same native tokens. This gives the new chain complete freedom to make design tweaks as necessary to support multi-threaded operation without risking an in-place upgrade to a live chain.
With this roadmap to parallelism we can simplify EOSIO 1.0 and optimize it for maximum single-threaded performance and ease-of-development. We anticipate that the single-threaded version of EOSIO may one day achieve 5,000–10,000 TPS. We also anticipate that many applications will prefer the many-chain approach to scaling as it will lower overall costs and scale faster.