- We propose a first-principles framework for L1 design tradeoffs: the high-performance trilemma. (pictured above)
- Solana’s aggressive low-redundancy design explains both its high performance and its low reliability compared to Ethereum.
- Aptos, a new L1 with a $200 million all-star seed round, is poised to challenge Solana’s monopoly in the high-performance L1 space. Aptos adds more reliability compared to Solana at the cost of higher node hardware requirements.
- We believe that optimizing for specific applications is the future of L1. Considering the trilemma, there is no chain that can achieve a universal design that meets all application scenarios. Building on our previous cross-chain article, we propose a “three questions” Q&A manual for developers of blockchain applications to consider their technology choices.
Space is limited here, but we actually have more ideas.
We cordially invite interested builders and investors for further discussions. Our Twitter is @TheAntiApe and our email is firstname.lastname@example.org.
Items that will be mentioned in the article include:
Solana, Aptos, Ethereum, StarkWare , zkSync , Serum , Meteplex。
Part 1: The Secret to Solana’s High Performance
This section includes:
- Until now, Solana still has a monopoly as the only high-performance blockchain
- Solana’s design DNA is to aggressively optimize optimal network performance: parallel computing, reduced redundancy, and higher block rates.
What Makes Solana Different?
As the only blockchain that comes close to Visa’s 65,000 TPS capacity, Solana has the backing of Wall Street and Silicon Valley to try out blockchain services at scale.
Solana doesn’t implement TPS with some Turing Award magic (unlike zero-knowledge proofs, another important topic we’ll discuss soon).
Instead, Solana makes a series of design tradeoffs between performance and reliability. We’ll discuss Solana’s performance in the first part and the cost of reliability in the second.
Design Choice 1: Parallel Computing.
The Ethereum Virtual Machine (EVM) is single-threaded – the EVM can only utilize one CPU core to process transactions sequentially. Since the heat generated by a single core increases exponentially with speed, physics limits the upper limit of a single core’s performance to a very low level.
What is the solution? More cores! Eight 2GHz cores are much cooler than one 8GHz core, but also more powerful.
In 2007, Intel introduced the dual-core Pentium processor, thus ending the single-core era. Today’s computer consumers have GPUs and CPUs with between 4 and 4096 cores.
Getting more cores to work together better, rather than having a more powerful single core, has been the focus of research in the semiconductor industry for more than a decade.
In order to achieve native multithreading, Solana had to give up EVM compatibility. Solana’s smart contracts can utilize the 4096 cores of Nvidia GPUs to run computations in parallel.
Our opinion: In this binary choice of [EVM vs Multi-thread], we favor multi-threading over EVM compatibility. We think it is ridiculous to think that the DApps of 2027 can only use the semiconductor technology of 2007.
Some may point to developer moat issues related to EVM/Solidity. But it’s actually quite easy for developers to switch programming languages.
Most Web 2 applications and programming languages used by developers today are natively multithreaded. We think future developers will be as frustrated with the EVM’s mysterious single-threaded architecture as the current high GAS. (Also, we’re not fans of EVM-compatible rollups schemes).
Design Choice 2: Reduce Redundancy with Deterministic Leader Rotation
Decentralization requires redundancy. In a centralized cloud service like Google, the computation happens only once—because the user trusts Google to be right.
In blockchain, since we cannot trust anyone, all data needs to be calculated and verified by different nodes. The extra number of times an identical computation is done is what is called overhead/redundancy. To quantify redundancy, we use Big-O notation (big-O notation, asymptotic notation), such as [O(n^2), O(n), O(log n)], where functions represent when they expand to more How complex network computing will become when there are multiple nodes. For example, as the network grows, O(n^3) can mean orders of magnitude more redundancy than O(n^2).
In Bitcoin, Ethereum, and many other simple PoS chains, the redundancy of consensus is at least O(n^2) proportional to the square of the number of nodes: every block must be transmitted, checked, and compared to every other work of a block.
For Solana, only the designated leader node produces the next block. (See Gulf Stream, Leader Rotation). On this basis, Solana divides the block into many small blocks, and then only a small number of node validators validate each small block (See Turbine), instead of all nodes sending and validating all blocks.
Solana’s protocol reduces Solana’s best-case redundancy from O(n^2) to O(log n), the most efficient possible in computational complexity theory.
This result is truly remarkable. Consider an (oversimplified) illustration.
- Networks A and B are otherwise identical, with 100k TPS for 100 nodes.
- An O(n^2) network degrades by a factor of 100 for every 10x increase in node performance.
- An O(log n) network degrades ~3x node performance for every 10x increase in node performance.
- At 100,000 nodes, the performance of the two networks will differ by a factor of 30,000.
This reduction in complexity also has ideological implications.
In this regard, we believe that Vitalik ‘s criticism of Solana is somewhat misleading – Vitalik believes that Solana is not decentralized enough due to its high hardware requirements.
Solana’s $4,000 hardware cost prevents “every user from running a Solana node on their own machine”. This cost is correct.
But computing will get cheaper in the long run, and Solana’s reduced complexity design makes it possible to have 100x more nodes without making the network unbearably slow.
Other design options:
Supporters and critics also debated some of Solana’s other technical features. We consider these features to be less central, so we discuss in general terms:
3.1 Voting transactions are counted in TPS
Some critics have pointed out that Solana artificially increases TPS by including validator votes in transactions. Votes are indeed counted in the transaction, but this is only a cosmetic issue.
Maybe Solana should reiterate that its TPS is 60,000 (excluding vote transactions), not 65,000.
3.2 Throughput—faster block times and larger blocks
Both Vitalik and StarkWare criticized Solana’s performance improvements as being somewhat lazy, as Solana simply made each block larger and block times shorter, accommodating more transactions at the expense of higher hardware requirements.
Simple math will tell you that’s not all.
Both Vitalik and StarkWare criticized Solana’s performance improvements as being somewhat lazy, as Solana simply made each block larger and block times shorter, accommodating more transactions at the expense of higher hardware requirements. Simple math will tell you that’s not all.
- Solana has a maximum block size of 10MB, which is 10 times the ETH target size of 1MB.
- Solana’s block time is 0.4 seconds, 30 times faster than Ethereum’s 12 seconds.
- The combination of the above two gives Solana about 300 times the laziness performance improvement compared to Ethereum.
- But actually Solana’s TPS is 3000 times higher than Ethereum’s usual TPS. This other 90% performance improvement can be better explained by Solana’s parallel operation and reduced redundancy design that we discussed.
3.3 Proof of History (POH)
Solana touts POH as its biggest innovation.
In the long run, Proof of History allows Solana to reduce block times to an extreme 400ms/block, despite the fact that physical network latency tends to be greater than 400ms. The fancy name for this feature is Asynchronous Consensus, see Multicoin’s article for more details.
Summary of Design Choices: Solana High Performance Secrets
Three key metrics together determine the maximum throughput of the blockchain: block rate, parallel computing, and redundancy.
- Redundancy determines how much data and computation are required in total, that is, total computation = effective computation + redundancy;
- Parallel computing allows nodes to compute faster;
- The block rate determines the amount of data that can be stored in the blockchain database in a certain period of time.
Solana made bold design choices in all three areas: from O(n^2) to O(log n) redundancy; from 1 core to 4096 cores in parallel, and from 5MB/min to 1500MB/min output block rate.
These are the main secrets behind Solana’s 65,000TPS. In the next chapter, we will discuss the cost of these options for Solana.
Part II: The Cost of Solana’s Choice: Prioritizing Performance Over Resilience
This section includes:
- Solana’s aggressive performance-optimized DNA makes it more prone to failure than other blockchains.
- We present the redundancy dilemma: given the limited computing power, L1 must make a trade-off between performance and reliability.
- The redundancy dilemma is a subset of the high-performance trilemma in Part 3.
frequent cyber incidents
Solana has experienced at least 4 major cyber incidents in the past year.
September 2021 outage accident, December 2021 downgrade accident, January 2022 downgrade accident, April 2022 outage accident. Any interested stakeholder must have many questions:
- What caused the accident?
- What is the essential reason? One-time system bug? Accidental attack? Or is there some problem in the DNA of blockchain design that we can only alleviate?
Choose best performance over reliability
In the first part, we discussed how Solana can aggressively optimize its best-case performance.
“Best case” is a keyword here. Solana spirals out of control when things don’t quite go their way.
Design cost 1: Aggressive parallelism degenerates when transactions are logically ordered.
NFT mint and IEO transactions often cause disruptions to the Solana network.
The reason: these transactions can’t be done simultaneously on 4096 cores. When minting NFTs, it is not known which ones have been mint, which can lead to duplication and bugs.
All mint transactions in the same collection must be processed in order.
An immediate implication is that Solana’s 65,000 TPS does not mean that users can mint 6 BAYC sets in a second: Solana’s in-order processing power may be closer to or even lower than Ethereum’s, around Between 10 and 100 TPS.
This explains the performance degradation: runaway transaction volume while NFT mint makes Metaplex unusable, but other applications that do not rely on Metaplex (like Serum order books) can still process transactions on one of the other 4095 cores.
But more often, the performance degradation turned into a network outage: waiting for Metaplex’s unprocessed transactions to cause the node to overflow its memory – when the memory overflowed, the node crashed and went offline completely.
Core tradeoff: By using a 4096-core GPU instead of a 16-core CPU, Solana sacrifices single-core performance in favor of aggressive parallelism. Typically, the network works well when transactions are uncorrelated, but once transactions exhibit suboptimal patterns, Solana is more prone to crash than the highly redundant Ethereum.
Design Cost 2: Decisive leader selection becomes ugly when leaders collapse
When Solana is close to crashing, the current block leader is often the first to crash.
Solana’s low-redundancy design relies heavily on whether the leader node is online – none of the other nodes have the same transaction data or network role as the current leader node.
This means that once the leader node goes offline, the rest of the network needs to do a lot of contingency work: agree to skip a block, reorganize transaction data, and forward missing transaction data to the next leader…
Consider the Ethereum network, which has no leader node, each node has an exact and repeated copy of the transaction data that will be put into a block (mempool).
If any Ethereum node goes offline, all other nodes still have everything they need to produce a new block on hand.
This is the double-edged sword of redundancy: in the ideal case, redundancy causes the network to slow down; in the worst case, it can prevent major accidents.
Let’s illustrate with numbers. According to the paper, Solana’s emergency computation overhead can reach O(n^4) in the event of a leader node crash (formally known as “cascading leader failure”).
An O(n^2) network is slow but usable, whereas a network that takes O(n^4) computations all at once is dead.
This is the main reason why Solana struggles to recover on its own once it goes into O(n^4) cascading leadership failure mode.
This is a feature, not a bug
Solana’s genes are radical to prioritize optimal performance. This principle is everywhere in architecture, so it’s hard to change just one place without changing everything else.
(We didn’t discuss this, but to illustrate the interdependence, the core PoH algorithm would be impractical if run on a CPU rather than a GPU.
And Solana’s PoH—a data management system optimized for performance ideally makes it difficult to implement an ETH-like mempool).
Again, this is a trade-off, not the best of both worlds – to fundamentally make Solana more stable requires creating more redundancy at the expense of best-case performance.
Even Solana supporters need to be mentally prepared that network outages and slow performance will happen many times over.
Because today’s Solana network is far from trying all possible mitigations. Mitigation is a game of hide-and-seek that requires iteration.
One day, the hard work of Solana’s lab may make 99.99% network uptime possible.
Yes, it was never meant to be 100% up and running, and today’s mainnet beta is still far from 99.99%.
Part 3: Aptos joins the trilemma of competition and high performance
This section includes:
- Aptos’ design choice is a compromise between reliability and performance, sitting between Solana and Ethereum
- We pose the high performance trilemma between high performance, reliability and efficiency
- For developers, the future trend is to optimize according to specific usage scenarios. We propose a 3-question Q&A manual to help developers choose infrastructure
For over a full year, Solana remains the only name in the high-performance L1 segment.
Now we have Aptos, developed by the ex- Libra team at Facebook and backed by a16z , Tiger, Multicoin, and FTX .
Multicoin and FTX are also clearly heavy investors in Solana.
Aptos has been in the headlines recently as they claim 160k TPS, clearly positioning themselves as a competitor to Solana.
That’s why we spend so much time dissecting Solana: it’s the best angle to understand Aptos in conjunction with practicality:
Recalling the second part, Ethereum has optimized the time for the network to be up and running:
Ethereum spends a lot of data redundancy preparing for the worst, so it is nearly impossible to disrupt the Ethereum network with an attack.
Solana, on the other hand, is optimized for best-case performance and spends less on redundancy, making the network less reliable in extreme cases.
Aptos tries to take a step back from Solana when it comes to solving the redundancy dilemma. Here are some of its key design choices:
Aptos Design Choice 1: 16-Core Server-Class CPU
This is a middle ground between Solana’s 4096 GPU cores and Ethereum’s 1 CPU core.
Aptos may not be as fast as Solana when dealing with highly parallelizable tasks.
Each CPU core of Aptos is much more performant than Solana’s GPU core, so Aptos may handle better than Solana in the case of logically sequential transactions such as NFT mint.
Aptos design choice 2: O(n) redundancy in the best case, O(n^2) in the worst case
Relative to Solana, Aptos attempts to make its network more resilient by adding redundancy. Instead of trying to achieve Solana’s extreme O(log n) linear redundancy, Aptos is set to O(n) redundancy.
In each round of consensus, Aptos requires all non-leader nodes to synchronize additional data in case other nodes need to take over if the current leader node fails.
Aptos also made no attempt to split and validate blocks, as splitting would create extra work in case of errors.
The result of this design is that when the leader node does fail, Aptos’ emergency handling is not as messy as Solana’s.
Compare this: Aptos’ best performance is not as good as Solana’s, but Aptos’ worst-case performance is more acceptable – O(n^2) compared to Solana’s O(n^4).
If we put these five performances together, they happen to be a nice sandwich, sandwiching Aptos (purple) between Ethereum (blue) and Solana (green).
Aptos Design Choice 3: Crazy Hardware Requirements
You may have seen Aptos claiming 160k TPS and wondered why I said its best-case performance is not as good as Solana.
Note the hardware requirements of Aptos: all their tests are run on AWS EC2 instances with 16 core server class CPUs.
Aptos has also publicly suggested running their nodes on Google Cloud Platform instead of PCs.
The 160,000 figure is the result of lab tests on about 100 privileged nodes – in a more complex real production environment, with more nodes, the TPS would definitely be lower.
Aptos’ internal testing has also shown that as the network scales to more nodes, its performance will approach or even fall below Solana’s current 65,000 TPS.
Here is a quick summary of the key technical specifications of Aptos, Solana and Ethereum for reference:
Putting it all together to sum it up: The high-performance trilemma
Extending the problem to the redundancy dilemma, while also taking into account the perverted hardware requirements of Aptos, we propose a replica of Vitalik’s blockchain scalability trilemma: the high-performance trilemma.
In this trilemma, the three first-principles properties that cannot be satisfied at the same time are as follows:
- Reliability: Guarantees network uptime by spending more computation on redundancy
- Performance: Enhances the throughput of the network by spending less computation on redundancy
- Efficiency: The only way to improve reliability and performance is to get more computing resources to spend on both
In Ethereum, Solana, Aptos:
- Ethereum chooses network uptime and efficiency, so it spends a certain amount of computation on redundancy, resulting in slow performance.
- Solana chooses performance and (relative) efficiency, so it spends limited computation on best-case performance, and reliability is negatively impacted by lower redundancy.
- Aptos chose network uptime and high performance, so in order to have enough computing to cover both, Aptos had to choose server-based nodes, giving up efficiency.
Aptos’ design philosophy is quite Web 2: emphasizing user-friendliness rather than decentralization. Early descriptions suggest that Aptos may incorporate a premium user account system with password recovery.
Aptos is certainly not the most decentralized blockchain by any measure. It does not aim at ideological purity.
200 million seed investors from a16z and Tiger put some real money and resources behind this somewhat contrarian vision.
What does all this mean for investors and developers? Use scene optimization.
No Maxis. (non-maximalist)
No Maxis. (non-maximalist)
No Maxis. (non-maximalist)
Optimize according to your usage scenario.
Even AWS (Amazon Cloud Services) offers dozens of database configurations for different usage scenarios because there is no one-size-fits-all solution. A blockchain is a database.
Being a maximalist may help profit by taking short-term risk in a fast-growing speculative market, but tribalism is bad for true value discovery and building.
A good investor and builder should be realistic about the trade-offs and really understand your use case, rather than indulging in sales pitches, bubbles, and PR rhetoric.
Right now we only have a broad outline of what the future will look like. Both Solana and Aptos will go through more bugs, outages, tweaks and patches.
Solana would be paralyzed again, and so would Aptos. But that doesn’t change their status as top contenders for solving the lucrative high-performance L1 problem.
For developers: There are at least three things to know:
- Your use case, what is critical and what is just icing on the cake.
- What are the trade-offs and genetics of the infrastructure you want to use?
- Mix and match costs and benefits. Cross-chain solutions and risks, previous article by The Anti Ape. Great DApps utilize the blockchain, bad DApps are consumed by the blockchain they use.
For investors: Aptos will release a public testnet and token in 2022. This means that Solana’s monopoly in the high-performance blockchain space will soon come to an end.
We expect Solana’s token price to experience some selling pressure as investors have more options in the high-performance blockchain vertical. But it’s too early to say a winner.
Regardless, Aptos looks like a solid challenger to Solana as it tries to balance Solana’s long-term reliability with some other trade-offs.
But we also need to see if the Aptos team can execute well and if they can challenge Solana’s two-year ecosystem lead.
Disclaimer: The above is not investment advice. Technically relevant illustrations are the best expression of the author’s knowledge at the time of publication. For the sake of brevity and clarity, the article must contain some important omissions and approximations.
Observations and assumptions may need to be updated or corrected as projects release more information about their protocols. We appreciate any discussions, suggestions and corrections.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/comprehensive-comparison-of-aptos-and-solana-aptos-will-be-a-strong-opponent-of-solana/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.