GRVT Website: grvt.io

GRVT’s Twitter/X: https://twitter.com/grvt_io

Author: Kit | CatcherVC

“Our ignorance of the unknown, our misunderstanding of randomness, our misreading of probabilities, and our beliefs about risk and decision-making are our weaknesses.” - "The Black Swan" by Nassim Nicholas Taleb

TL;DR

GRVT, a new hybrid exchange (HEX), aims to address the challenges faced by centralized exchanges (CEXs) in terms of security and high-performance trading. By leveraging ZKSync's Layer 2 data availability and Validium solution, GRVT plans to offer users a trustworthy and efficient trading experience. The exchange emphasizes the importance of options trading as a hedging tool and its potential for growth. GRVT's system is built on ZK rollup technology, combining high-performance execution with zero-knowledge proofs for privacy and security. The team also places a strong focus on compliance, AML/KYC procedures, and user fund protection. With their unique approach and experienced team, GRVT aims to establish a new standard in digital asset derivatives trading.

Intro

Black Swan events have always served as a mirror reflecting the blind self-confidence of individual and institutional investors in their over-optimistic interpretation of data and statistical probabilities. Since the publication of the Bitcoin white paper, the crypto market has experienced several Black Swan events, including Mt. Gox, The DAO, bans, exchange crackdowns, and FTX's insolvency. The FTX debacle in 2022 revived the warning, "Not your keys, not your coins," in everyone's ears. As a result, Centralized Exchanges (CEXs) collectively issued nominal Proof of Reserves (PoR), and technologies like Multi-Party Computation (MPC), homomorphic encryption wallets, and zero-knowledge proofs have once again drawn the crypto community's attention to Decentralized Exchanges (DEXs) and self-custody.

GRVT, a Layer 3 exchange offering cross-asset perpetual futures and options contracts. Built upon ZKSync's Layer 2 data availability, and planning to use the Validium solution to provide users with a trustworthy high-performance trading experience, GRVT is the brainchild of Hong Gyu Yea, Matthew Quek, and Aaron Ong. Their aim is to use existing ZK encryption, blockchain technology, and high-performance trading systems to create a new generation of Hybrid Exchange (HEX), addressing the dilemma centralized exchanges face between high-performance trading and user fund security. According to GRVT's founder Hongyea, GRVT is set to develop a Testnet in Q4 2023 and plans to launch the Mainnet in Q1 2024.

1st Witching Factor: State of CEX/DEX

• Spot Trading: From 2017 to 2023, the 7-day average trading volume of cryptocurrency spot trades on CEXs grew from $50 billion to $500 billion. From 2019 to 2023, the emergence of decentralized exchanges like Uniswap allowed DEXs to stand out from centralized exchanges. DEXs have grown from non-existence to now holding a 15% share of the spot market trading ratio, with native Ethereum DApps like Uniswap and Curve establishing an oligopoly effect on chains centred on the Ethereum Virtual Machine (EVM).

• Perpetual Contracts: Since Bitmex introduced perpetual contract trading in 2016, major exchanges have also launched leveraged contract trading systems. The low trading costs and high-performance experience of centralized trading systems provide investors with convenient custodial services, bringing substantial profits to the exchanges. However, centralized services have been criticized for their opaque "spiking" counterparty trading, single-point failure hacker attacks, and illegal misappropriation of user assets. Data from TheBlock show that in 2022, the monthly average trading volume of BTC and ETH perpetual contracts exceeded the total monthly average trading volume of all cryptocurrencies. This highlights that if “Old Money”  institutions and market makers enter the market, their biggest concern should be counterparty trading risk on centralized exchanges. Leverage trading should be a double-edged sword for market funds, not a black hole for counterparties to profit without investment.

• Options: After two cycles of wild growth in cryptocurrency, we see a new trend: "The emergence of professional investors and mature derivative trading tools has led to a decrease in market volatility returns (distribution chart price volatility 123 Sigma), while the activity and trading volume of the options market is rapidly growing." This not only reflects the importance of options as hedging tools but also reveals their enormous growth potential. As of March 2023, TheBlock data show that the trading volume of the BTC and ETH options market reached a monthly trading volume of $45 billion during the bull market from 2020 to 2021, and has already returned to the peak of the last cycle bull market in Q1 2023, maintaining strong trading volume. This understated data fully reflects the activity and growth potential brought to the options market by the entry of professional traders. With changes in the macroeconomic environment and uncertainty about the next halving, the demand for hedging tools by professional traders is also increasing.

• Traditional Options Market: Compared to the traditional Nasdaq and CBOE options markets, the current cryptocurrency options market's hedging degree is relatively low, but its growth rate and potential cannot be overlooked. Especially when the trading volume of spot and perpetual contracts is shrinking, the rise in options trading volume shows its important position in the market. The main crypto options oligarch, Deribit, officially launched collateral asset options and platform hedging exchanges in 2020, quickly capturing the bulk trading market. Subsequently, OKX developed an internal customer options market, with a share of only 1%-5%. The Delta Exchange launched in 2021 reached a peak market share of 10%-15%. In fact, products like Binance's Dual Currency Winning, Amber's Shark Fin, and OKX's options have been launched for a long time, but due to the positive correlation of the volatility returns of cryptocurrencies themselves and the aforementioned counterparty risk, these structured products, which are huge in traditional trading volume and are based on vanilla, heterogeneous options fixed-income, did not receive enough attention in the early stages of the industry. In Q2 2023, Binance officially opened its one-sided options trading section, and OKX launched its snowball product section, proving that centralized exchanges also feel subtle market changes and their determination to seize the high certainty growth derivative track.

Solution One: RFQ + Cross Margin Hedging

The GRVT team believes that an options market without the choice of cross-margin collateral futures or contract trading cannot provide complex trading strategies and has low capital utilization. On the other hand, a derivatives exchange without options trading cannot provide professional traders with sufficient hedging tools. Therefore, they designed the option of full margin hedging in the initial product design. In addition, the RFQ inquiry system on Telegram and API can help traders and institutions conveniently and quickly query the customization and execution of complex structured strategies. The margin system and hedging function within the same platform are key designs to greatly improve the utilization rate of collateral. Therefore, the open ecology of the on-chain derivatives interface and the off-chain order book matching and delivery can provide large traders with a safe, rich, and powerful one-stop comprehensive trading platform while the underlying crypto technology continues to develop.

2nd Witching Factor: Trust Crisis in Centralized Custody

In 2022, the FTX debacle caused a company worth $40 billion to go bankrupt due to insolvency within a week, owing $8 billion in user assets. At this point, investors deeply realized the internal accounting chaos and centralization of centralized exchanges, forcing exchanges like Binance to take the lead in launching a hot wallet deposit proof (Proof of Reserve, "POR") in conjunction with other exchanges. In fact, PoR was first proposed by Kraken in 2014, and later Vitalik Buterin called for the use of zero-knowledge proofs (ZKP) of KZG polynomial commitments to replace the current deposit certificates generated by Merkle trees to ensure higher security and improved privacy.

However, deposit certificates cannot prove whether a CEX has the ability to pay. Customers' assets only represent part of the liabilities and do not include the exchange's credit and other businesses. Although disclosing assets and addresses allows investors to track and analyze suspicious behaviour, when an insolvency run occurs, users' assets still cannot data audit the CEX's asset payment ability, or user assets frozen in the recovery litigation stage. In fact, Mt Gox's liquidation third party has always been stalling applications to unscrupulously seek investors' interests.

Solution Two: High-Performance Engine + ZK

HongYea's original intention in founding GRVT was to protect user assets and allow users to achieve a one-click trading experience and low latency under self-custody accounts no different from centralized exchanges. It is reported that GRVT's off-chain order book matching engine has a high 600,000 TPS and a delay of less than 2 ms. When its trading execution and Validum ZK proof are combined, users can not only ensure the safety of their own assets like DYDX (StarkEx version) through Validum's data committee but also ensure the privacy of trading execution such as position information and liquidation lines, greatly reducing the counterparty risk of the current CEXs solution.

GRVT's system is designed to be compatible with ZK proofs and is built on ZKSync Era Rollup. According to the current proof submission speed of ZKSync, all traders' assets can be credited and settled on the Ethereum main chain within 2 to 24 hours. The speed of asset confirmation is critical for the naturally large collateralized volume of funds in TradeFi. Supposedly, these funds flow into the massive funds of ZKRollup, which need to turn to a "third-party centralized cross-chain bridge" or "wait for a 7-day optimistic solution challenge period". In that case, the risks these large funds bear, such as theft, market instability, time dimension, and settlement rate, are substantial. The faster settlement speed of ZKRollup is precisely one of the essential factors needed by TradeFi Layer 2. Therefore, compared to derivative applications built on optimistic solutions like GMX and Lyra, users using GRVT on the ZK expansion solution need to bear a safer and less lossy 7-day challenge period and third-party cross-chain bridge rights confirmation. The future potential for zero-knowledge expansion is higher.

Although Validum proof cannot preserve all historical transaction execution records, with the evolution of ZK proof algorithms. According to Zhang Ye from Scroll Tech, ZK expansion solutions can force proof recovery, and when a Black Swan event occurs in the market or data is tampered with illegally, users can question the security of funds by forcibly submitting ZK proof and recovering frozen or lost funds. Compared to PoR's "guarantee of total fund correctness," GRVT adheres to Vitalik Buterin's advocacy of using ZK proof to guarantee users' "absolute withdrawal" rights.

3rd Witching Factor: Compliance and Legislation

With the collapse of SBF and FTX, the US's decision to step into the crypto industry was urgently halted. Uncertainties prompted A16Z to announce the establishment of a European office, Coinbase's Brian Armstrong to announce a major development in South America's Coinbase derivative trading platform, the US digital asset deposit and withdrawal channel Silvergate to suffocate, and Binance to be subpoenaed by the SEC. These pieced-together clues form a comprehensive crackdown by the US on the regional, and cultural differences, racial faces, and offshore funds of the crypto industry. Due to regulatory pressure and the crackdown on giants, the start of the new generation of semi-centralized exchanges will be more difficult than the last cycle, and future on-chain regulation and restrictions will become an increasingly severe and centralized hybrid. The arrest of Tornado developers, Consensys Metamask's default IP surveillance RPC, Uniswap's integration of centralized purchase channels, etc., also foreshadows the compromise of on-chain crypto natives to the potential AML/KYC of mass users. In fact, Vitalik Buterin has also called for the provision of partial auditability to law enforcement agencies through ZK proof to face the increasingly severe on-chain audit system that the Tornado project cannot achieve due to the lack of AML.

Solution Three: Team Experience + AML/KYC

The GRVT team has rich experience in privacy data development and traditional financial compliance, operation, and practice. Founder HongYea is from South Korea and is based in Hong Kong. He is an experienced trader and has worked as a senior executive in Credit Suisse and Goldman Sachs in Hong Kong for 9 years. Matthew serves as the Chief Operating Officer and has led the blockchain and payment team at DBS Bank in Singapore to study blockchain applications in traditional finance. Aaron is the CTO of GRVT and has served as the technical director of two data privacy frameworks at Meta. According to the GRVT team, the project will focus on AML/KYC compliance, security, and high performance to provide a new generation of one-stop trading platforms for global digital asset derivative trading users.

According to the recently disclosed seed and pre-seed round funding, the seed round is led by Matrix Partner and Delphi Digital, which have cross-industries venture capital experience and a background in American digital asset research-driven media. Other seed round and pre-seed round investment institutions include ABCDE, a team of ex-founding Houbi digital asset exchanges, Darius Sit from QCP Capital (Deribit's seed investor)as an advisor, SIG, HackVC, Folius Ventures, Metalpha, CMS Holdings, Appworks, Fisher8 Capital, Kronos Research, 500 Global, Token Metrics Ventures, Primal Capital, CatcherVC.

Conclusion

Overall, the innovation of the GRVT team lies in their commitment to creating a new and unique digital asset derivatives trading platform. This platform will establish a new hybrid trading standard for existing exchanges, decentralized trading platforms (DEX), and investors, as well as spot, futures, and options. They use existing on-chain encryption blockchain technology and combine it with off-chain high-performance matching engines and off-market RFQ inquiry robots to provide a new type of hybrid trading platform (HEX) for the crypto industry, which is under regulatory pressure, faces centralized opaque risks, and has low trust.

“Solana pushes Layer1 scaling to the extreme by sacrificing capability to reach out the TPS bottleneck of non-sharded chains. However, the multiple downtimes seem to foreshadow the end of sacrificing capability/security for efficiency.”

Author: Web3er Liu, CatcherVC

Technical Advisor: Liu Yang, author of Embedded System Security

Abstract

• Solana scaling is mainly based on three major aspects: efficient use of network bandwidth, reducing the frequency of inter-node communication and speeding up node computing. These measures directly shorten the time for block generation and consensus communication, but also reduce system capability (security).

• Solana discloses the list of Leaders in advance, revealing a single trusted data source to reduce the consensus communication overhead. But this may introduce security risks such as bribery and targeted attacks.

• Solana treats consensus communications (voting messages) as transaction events, with over 70% of the TPS component being consensus messages and around 500-1000 TPS associated with user transactions.

• Solana's Gulf Stream mechanism replaces the global transaction pool, which makes transaction processing quicker while the spam transaction filtering less efficient, potentially leading to downtime of Leader. 

• Solana's Leader nodes publish transaction sequences rather than real blocks. Combined with the Turbine transfer protocol, transaction sequences can be sliced and distributed to different nodes, making the data synchronization extremely fast.

• POH (Proof Of History) is essentially a timing and counting method that stamps different transaction events with serial numbers to generate transaction sequences. The leader essentially publishes a consistent timer (clock) across the network in the transaction sequence. The advancement of the ledger and the time are consistent across different nodes within a very short time window.

• Solana has 132 nodes occupying 67% of the staking share, of which 25 nodes occupy 33% of the staking share, basically constituting an “oligarchy” or “Roman Senate”. If these 25 nodes conspire, it is enough to lead the network into chaos.

• Solana requires a high level of node hardware since it uses huge equipment costs in exchange for vertical scaling. The entities running Solana nodes are mostly whales, institutions or enterprises, which is not in line with the vision of decentralization.

• In summary, Solana pushes Layer1 scaling to the extreme with advanced node equipment, revolutionary consensus mechanism and data transmission protocol, and basically reaches the TPS bottleneck that can be maintained by non-sharded chains. However, the multiple downtimes have already foreshadowed the end of sacrificing capability/security for efficiency.

Introduction

2021 is the turning point for blockchain and Crypto. With concepts like Web3 becoming more and more popular, the public chain world has seen the strongest traffic growth ever. Amid this external environment, Ethereum has become the titan of the Web3 world with its full decentralization and security, but the efficiency issue has become its “Achilles heel”. Ethereum, with only 10 transactions per second, pales in comparison with VISA, whose TPS easily passes 1,000. This scenario is far from its grand vision of a “world-class decentralized application platform”.

In this regard, Solana, Avalanche, Fantom, Near and other new public chains with scaling as their core have once become the main players in Web3, attracting a huge flood of capital. Just take Solana for example, the head public chain called “Ethereum killer” has soared 170 times in market value in 2021, and its influence one that time even surpassed the old public chains like Polkadot and Cardano, making it an eligible competitor for Ethereum. 

But the boom does not last long. On September 14, 2021, Solana was down for the first time for 17 hours due to performance defaults, and the price of SOL token dropped rapidly by 15%; in January 2022, Solana was down again for 30 hours, which triggered extensive discussions; later in May, Solana was down twice then once more in early June. According to Solana's official statement, its main network has experienced at least 8 times of performance degradation or downtime.

Along with the emergence of many problems, critics led by Ethereum supporters took turns to question Solana, and some even gave Solana the title of “SQLana” (SQL is a system for managing centralized databases), with a flood of comments and analyses. To this day, the discussion about the real usability of Solana seems to never stop, attracting countless curious observers. Out of interest and concern for mainstream public chains, in this article, CatcherVC will give a concise explanation of the Solana scaling mechanism and explore some of the reasons for its downtime.

Solana System Architecture, Consensus Mechanism, Block Transfer Process

The efficiency of a public chain mainly refers to its ability to process transactions, that is, TPS (transactions processed per second), which is influenced by the speed of block generation and block capacity, and also affects the transaction fees and user activity. From the popular EOS in 2018 to Optimism, which recently launched a coin offering, all the scaling solutions almost can’t get around the most crucial element of “accelerating block generation”.

To generate blocks quicker, it is often necessary to “do something” in the block generation process, and Solana is no exception. Solana scaling is mainly based on three major aspects: efficient use of network bandwidth, reducing the frequency of inter-node communication and speeding up node computing. Solana's founder, Anatoly Yakovenko, and his teammates have carefully crafted every detail to improve efficiency as much as possible at the cost of system capability (security). They basically reached the real TPS limit of a non-sharded public chain and finally achieved innovation “at a cost”.

Compared with other POS public chains, Solana's biggest innovation lies in its unique consensus protocol and network node communication method, which is based on POS and PBFT (Practical Byzantine Fault Tolerance). It introduces the original POH (Proof of History) to advance the blockchain ledger to create its unique consensus system.

Solana's consensus protocol is presented in a similar way to Cardano's earliest Ouroboros algorithm, which contains two major time units: Epoch and Slot. Each Slot is about 0.4 to 0.8 seconds, which is equivalent to the time interval of a block. Each Epoch cycle contains 432,000 Slots (blocks), which are 2 to 4 days long. 

In Solana's system architecture, the most important roles are divided into two categories: Leader and Validator. Both are actually full nodes staking SOL tokens, whose only difference is that Leaders are different full nodes in different Slots (block generation cycles), and the full nodes not elected as Leaders will become Validators.

At the beginning of each new Epoch, the Solana network selects Leaders based on the stake weights of each node and forms a rotating list of Leaders to decide on Leaders at different times in the future. During the entire Epoch (2-4 days), Leaders are rotated by the order specified in the list, and the Leader node is changed every 4 Slots.

By disclosing the future Leaders in advance, the Solana network essentially obtains a definite and trusted source of new block data, providing great convenience to the consensus process.

A Glance at Solana Block Generation Process

To understand Solana's scaling mechanism more clearly, we can start with the logic of block generation and have a look at the general structure of Solana.

1. After a user initiates a transaction, it will be forwarded directly by the client to Leaders, or first received by ordinary nodes and then immediately forwarded to Leaders.

2. The leader receives all the pending transactions in the network and executes them while sorting the transaction instructions to form transaction sequences (similar to a block). Every once in a while, the Leader sends the sequenced transactions to Validator.

3. The validator executes the transactions in the order given by the transaction sequence (block), generating the corresponding state information (executing a transaction changes the state of the node, for example, changing the balance of some accounts).

4. For every N transaction sequence sent, the Leader will periodically disclose the local state, and the Validator will compare it with its own State and give an affirmative/negative vote. This step is similar to the “checkpoint” in Ethereum 2.0 or other POS public chains.

5. If the Leader collects positive votes from nodes with 2/3 of the stake weights of the whole network within the specified time, the previously released transaction sequence and state can be finalized and the “checkpoint” is passed, which is equivalent to the finality of the block.

6. Generally speaking, Validators that give a positive vote and Leaders share the same transaction execution state and post-transaction state, and in this way, the data will be synchronized.

7. For every 4 Slots, Leaders will make a switch, which means each time Leaders have about 1.6 to 3.2 seconds to master the “supreme power” of the network.

Solana's Scaling Mechanism Explained

On the surface, Solana's block generation logic seems to be generally similar to other public chains using POS mechanism and they all include a process of generating blocks and voting on blocks. However, if we take a look at each step, we will see that Solana is very different from other public chains, and this is the root cause of its high TPS and low capability.

1. The most important point: Solana discloses the Leader of each Slot in advance, which significantly reduces the workload during the consensus process. In other POS public chains, the consensus communication efficiency of the network is extremely low due to the lack of a single, trusted block-generating node. This leads to their time complexity often several orders of magnitude higher than Solana, a bottleneck of most public chains in terms of TPS.

2. Taking the mainstream POS consensus protocol or PBFT algorithm as an example, most of these algorithms adopt the same time unit and role division as Solana, and also have settings similar to Epoch, Slot, Leader, Validator, and Vote, with different parameter settings and names. The biggest difference is that most of these algorithms stress security (capability) without disclosing the list of Leaders in advance.

   For example, Cardano also generates a Leader rotation list in advance but keeps it private. Each selected Leader only knows when to generate blocks without knowing the information from other Leaders. This makes  Leader nodes unpredictable to the outside world.

Since there is no public Leader, nodes will “distrust each other” and “go their own way”. In this case, when a node claims to be the legitimate Leader, and if people don’t trust it and will ask it to present the relevant proof, whose generation, spread and verification may waste bandwidth resources and raise extra workload (it may even be related to Zero-Knowledge). Solana can avoid such troubles by disclosing the Leaders of each Slot.

 More importantly, in most POS consensus protocols or PBFT-type algorithms, the vote for a new block (a block has to be finalized with the affirmative vote of 2/3 nodes in the network) is often sent or collected by each node through a “Gossip protocol” in a manner similar to node-to-node exchange, somewhat similar to the viral random diffusion. It essentially requires communication between every two nodes, which is more complex and time-consuming than Solana's consensus protocol.

In PBFT algorithms such as Tendermint, a single Validator node has to collect single votes sent by at least 2/3 of the nodes in the network. If the number of nodes in the whole network is N, each node receives at least 2/3*N votes and the number of communications generated by the whole network is at least 2/3*N², which is obviously too large an order of magnitude (proportional to the square of N). If there are many nodes, the time spent in the consensus process will soar accordingly.

In response, Solana and Avalanche use ways to improve the node communication process to collect votes so as to reduce time complexity. In layman's terms, Leader centrally aggregates all the votes issued by Validator, then packages them together (written into the transaction sequence) and pushes them into the network at once.

In this way, nodes no longer need to exchange vote information frequently through the “gossip protocol” in a one-by-one manner, and the order of magnitude of communication frequency is reduced to a constant N or even logN, which largely shortens the block generation time and significantly improves TPS. 

Presently, Solana's block generation cycle is basically the same as a Slot: 0.4 to 0.8 seconds, even 4 times as fast as Avalanche. (The block displayed by the Solana browser is essentially a transaction sequence posted by Leader within each Slot.)

However, this also brings another problem: having the Leader publish the nodes' votes within the transaction sequence (block) takes up block space. In Solana's setup, Leader essentially treats consensus voting as a transaction event, and the transaction sequence it publishes contains the node voting, which is the main component of Solana TPS (typically more than 70%).

According to the statistics from the Solana browser, its actual TPS is maintained at about 2000~3000, of which more than 70% are consensus voting messages where ordinary users are not involved, and the actual TPS related to user transactions is maintained at 500~1000. It is one order of magnitude higher than BSC, Polygon, EOS and other high-performance public chains, but still can't reach the tens of thousands of levels as officially advocated.

Meanwhile, if Solana continues to enhance decentralization in the future and allows more nodes to participate in consensus voting (currently there are nearly 2000 Validators), the transaction sequence released by the Leader will definitely contain more voting messages, which will continue to compress the TPS space for user transactions. This means that it is hard for Solana to achieve higher TPS without sharding.

To a certain extent, Solana's transaction processing capacity of 500~1000 transactions per second has already reached the peak of non-sharded public chains. With more nodes, no shards, and smart contracts supporting, new public chains will find it hard to surpass Solana's TPS unless they adopt the “committee” model, where only a small number of nodes can participate in consensus, or degenerate into a centralized server. As long as the number of nodes participating in consensus remains large, it will be difficult to achieve a higher “verifiable TPS” than Solana.

It is particularly noteworthy that Solana's consensus protocol is not fundamentally different from the original Tendermint algorithm, since the list of Leaders in each Epoch (2-4 days) is made public in advance, and there is no unpredictability guaranteed for Leaders. In this way, everyone can predict possible Leaders at a certain time point and this will raise many potential problems on security/usability.

Leaders are vulnerable to premeditated DDOS attacks, and this will increase the failure rate; if several Leaders fail in a row, the network is prone to downtime; users can bribe Leaders in advance, etc.

Gulf Stream and Network Downtime

Solana public Leader list has a more important purpose: with its original Gulf Stream mechanism to improve the speed of network processing transactions.

After a user initiates a transaction, it is often forwarded directly to a designated Leader by the client program, or first received by ordinary nodes and then quickly sent to Leaders. This approach enables Leaders to receive transaction requests as soon as possible and respond faster (this is called the Gulf Stream mechanism, one of the main causes of Solana's downtime.)

This way of submitting transactions is very different from other public chains, as Gulf Stream replaces the “global transaction pool” of Bitcoin and Ethereum, where normal nodes do not run large transaction pools. After a node receives a user’s pending transaction, it simply hands it to Leaders and does not have to send it to other nodes. This approach significantly improves efficiency. However, without the transaction pool, ordinary nodes cannot efficiently intercept spam transactions, which can easily cause the Leader node to go down. 

To fully understand this point, we can compare it with ETH:

• Every full node of ETH has a storage area called a transaction pool (memory pool) for unlisted, pending transaction instructions. 

• When a node receives a new transaction request, it will first filter it to determine whether the transaction instruction is compliant (whether it is a duplicate/spam transaction), and then it stores the transaction in the transaction pool and then forwards it to other nodes (similar to viral proliferation).

• Eventually, a legitimate pending transaction is passed around the network and placed in the pool of all nodes, which allows different nodes to get the same data and show “consistency”.

Ether and Bitcoin adopt this mechanism for a very clear reason: there is no way to know who is the future Leader, and everyone has the probability of picking a new block. So, different nodes must receive the same pending transactions in preparation for packing blocks.

If a mining pool node releases a new block, the node receiving the block will parse and execute the transaction sequence in order, and then clear this part of the transaction instruction from the transaction pool. At this point, a batch of pending transactions can be uploaded to the chain.

Solana replaces the kind of transaction pooling in Ethereum. Pending transactions do not need to be randomly proliferated within the network and they are quickly submitted to a designated Leader and then packaged into transaction sequences to be distributed at once (similar to the way voting is distributed in the previous section). Ultimately, a transaction only needs to be included in a transaction sequence and propagated within the network for 1 turn (2 turns in practice for Ethereum). In the case of high volumes of transactions, this nuanced difference can dramatically improve propagation efficiency.

However, according to the technical note related to the transaction pool TxPool, the transaction pool/memory pool essentially plays the role of a data buffer and filter that can improve public chain capability. All nodes run transaction pools to include all pending transactions in the network so that different nodes can independently filter spam requests, intercept duplicate transactions in the first place, and share the traffic pressure. Although the use of transaction pools slows down the speed of block generation, it can filter out and intercept duplicate transactions (requests already recorded in the transaction pool) or other types of spam requests sent by users. In this way, the filtering is shared by all nodes in the network.

Solana has taken the opposite approach. Under the Gulf Stream mechanism, ordinary nodes do not operate a consistent pool of transactions across the network and cannot efficiently intercept duplicate/spam transactions. All the normal nodes just check whether the transaction data package is in the right format, but are unable to identify malicious duplicate requests. At the same time, because the ordinary nodes push the transaction instructions to the Leader, i.e. dumping the “burden” of filtering transactions to the Leader, in the case of huge traffic and a large number of duplicate transactions, the Leader node will be overstressed and the block generation will be affected.  In the end, the consensus vote will not be propagated smoothly and the network will easily collapse.

In this regard, Anatoly Yakovenko, the founder of Solana, said on January 27 this year that during the public sale hours of certain popular projects, up to nearly 2 million transaction requests per second reached the same Leader node, of which more than 90% were totally duplicate transactions, eventually causing Solana to go down

Reference: In-depth investigation: Why do new public chains have frequent downtime accidents?

To sum up, while Ethereum is essentially sacrificing efficiency for security, Solana is sacrificing security for efficiency, and the problems it faces can be summarized as follows:

As the Leader rotation order is predetermined, it has to be gone through in order. However, due to the imperfect traffic sharing mechanism, the failure rate of Leaders is high. If the user traffic is large in a certain period of time (such as during some hot NFT opening public sales), it may cause multiple Leaders to fail in a row (for example, the Leaders of the next 40 Slots can’t generate block smoothly), so that the consensus process is blocked, the network will fork, the Leader rotation chain will be completely broken and eventually collapse.

Turbine Propagation Protocol Similar to BT Seed:

With the cooperation of the above Gulf Stream mechanism, Leader quickly receives all transaction requests within a period of time, checks their legitimacy, and then executes transactions. At the same time, Leader uses a mechanism called POH (Proof of History) to stamp each transaction with a sequence number to give orders to the transaction events. (Details will be elaborated later)

After Leader sequences the transaction events, it slices the transaction sequence into X different pieces and sends them to each of the X Validators with the most staked assets, who in turn propagate them to other Validators. Validators will exchange the received pieces by themselves and piece together the complete transaction sequence (block) locally.

To make it easier to understand, we can treat each different piece as a small block with a reduced amount of data. Leader distributes X pieces at a time, i.e. sending out X different small blocks for different nodes to receive and further spread.

This special message distribution of Solana is inspired by BT seeds. (The principle is not easy to express in words, the main idea is to use the idle bandwidth of multiple nodes at the same time to transmit data in parallel). Generally speaking, the more pieces are sliced from the transaction sequence, the faster for the node group to spread the pieces and put together the transaction sequence, and as a result the data synchronization efficiency will be significantly improved.

In other public chains, Leader will send the same block to X neighbouring nodes, meaning sending out X copies of a block instead of distributing X different pieces (small blocks), and this practice generates serious data redundancy and bandwidth waste. The root cause of this is that the traditional block-type structure is not divisible and simply cannot be transmitted flexibly, while Solana simply replaces the block-type structure with transaction sequences, combined with Turbine protocol similar to BT seed to achieve high-speed data distribution and better TPS. 

Solana has officially stated that a transaction sequence can be synchronized to all nodes within 0.5 seconds when the network has 40,000 nodes under the Turbine propagation protocol.

Meanwhile, under the Turbine protocol, nodes are divided into different tiers (priorities) according to the weight of their staked assets. Validators with more staked assets are the first to receive the data sent by Leaders, after which the data are passed by nodes to the next tier. Under this mechanism, the group of nodes accounting for 2/3 of the weight of staked assets across the network will be the first to receive transaction sequences issued by Leaders, speeding up the confirmation speed of the ledger (block).

According to the data disclosed by Solana Browser, 2/3 of the stake weight is currently shared by 132 nodes. According to the propagation mechanism mentioned earlier, these nodes are the first to receive the transaction sequences issued by the Leader and to give their votes. As long as they get the votes from these 132 nodes, the transaction sequence issued by the Leader can be finalized. From a certain perspective, these nodes are ahead of other nodes, and if they conspire with each other, that may lead to some detrimental scenarios.

What is more noteworthy is that there are currently 25 nodes in Solana occupying 1/3 of the stake weight. According to Byzantine Fault Tolerance Theory, as long as these 25 nodes collectively collude (e.g., deliberately not sending a vote to a Leader), it is enough to throw the Solana network into chaos. To some extent, the problem of “oligarchy” faced by Solana should be a concern for all public chains adopting the POS voting system.

POH (Proof Of History)

As mentioned before, the Turbine protocol allows Leader to slice the transaction sequences and release the different pieces. This practice should base upon one guarantee: after the transaction sequence is sliced, it should be easy to be pieced together. To solve this problem, Solana deliberately put the error correction code (which prevents data loss) in packages and introduces the original POH (Proof Of History) mechanism for sequencing transaction events.

In Solana White Paper, Yakovenko uses the hash function SHA256 to demonstrate the principle of POH. For ease of understanding, this paper will explain the POH mechanism with the following example.

Since POH and the corresponding time evolution logic are hard to describe in words, it is recommended to read the POH part in Solana Chinese White Paper, and then use the following part as a supplementation.

• The input and output values of the SHA256 function are uniquely mapped (in a one-to-one manner), and after inputting the parameter X, there is only a unique output result SHA256(X) = ? ; different X's will lead to different ? = SHA256(X);

• If SHA256 is computed in a circular, recursive manner, for example:

  Define X2 = SHA256 ( X1 ), then use X2 to compute X3 = SHA256 (X2), then compute X4   SHA256 (X3), and so on continue this iteration, then Xn = SHA256 ( X[n-1] ).

• Iterating this process, we end up with a sequence of X1, X2, X3 ..... Xn, which has a characteristic: Xn = SHA256 ( X[n-1] ), the next Xn is the “descendant” of the previous X[n-1].

• After releasing the sequence to the public, if an outsider wants to verify the correctness of the sequence, for example, he wants to determine whether Xn is really the “legitimate descendant” of X[n-1], he can directly put X[n-1] into the SHA256 function to see whether the result is the same as Xn. 

• In this mode, you can't get X2 without X1, and you can't get X3 without X2 ... Without Xn you can’t get X[n+1] that follows. In this way, the sequence has continuity and uniqueness.

• The most critical point is, transaction events can be inserted into the sequence.

  For example, After the birth of X3 and before the appearance of X4, the transaction event T1 can be used as an external input and added with X3 to obtain X4 = SHA256 (X3+T1). Here, X3 appears slightly before T1 and X4 is the descendant of (T1+X3), while T1 is essentially put between the “birthdays” of X3 and X4.

  By analogy, T2 can be generated after X8, as an external input parameter to obtain X9 = SHA256 (T2 + X8), so that the appearance time of T2 is put between the “birthdays” of X8 and X9.

• In the above scenario, the actual POH sequence is of the following form.

Among them, the transaction events T1 and T2 are data inserted in the sequence by the outside world, and in the time record of the POH sequence, it is later than X3 and earlier than X4.

Just give the order number of T1 in the POH sequence, we will know how many SHA256 calculations occurred before it (T1 is preceded by X1, X2, X3, with three SHA256 calculations occurring). 

The same goes for T2, which is preceded by eight Xs from X1 to X8, and eight calculations have occurred.

The non-technical explanation of the above process is as follows: there is a man with a stopwatch to count the seconds, and whenever he receives a letter, he writes down the time on the envelope according to the reading of the stopwatch. After receiving ten letters, the number of seconds recorded on these ten letters must be different and there is a sequential distinction, which gives letters different orders. According to the records on the letters, we can also know the length of the interval between two letters.

• Leader, when releasing the transaction sequences, as long as puts the value of X3 in the packet of T1 and informs the serial number of X3 (the third one), the Validator receiving the packet then can parse the complete POH sequence before T1; the same goes for T2, as long as the value of X8 and its serial number 8 are given in the packet of T2, then Validator can parse the complete POH sequence before T2

• According to the POH setting, the order of each transaction can be disclosed by marking the serial number (Counter) of each transaction in the POH sequence and giving the X value (Last Valid Hash) immediately next to it. Due to the nature of the SHA256 function itself, the order settled by hash calculation is difficult to be tampered with.

Meanwhile, Validator knows the way Leader comes up with the POH sequence, and it can perform the same operation to restore the complete POH sequence and verify the correctness of the data posted by Leader.

For example, if the Leader publishes the transaction sequence data packet as:

• T1, serial number 3, immediately adjacent to X3.

• T2, serial number 5, immediately adjacent to X5.

• T3, serial number 8, immediately adjacent to X8.

• T4, serial number 10, immediately adjacent to X10.

• POH sequence initial value is X1.

Once Validator receives the above packet, it can take X1 as the initial parameter and loop it into the SHA256 function to calculate it by itself, and parse the complete POH sequence as:

In this way, as long as we know how many Xs are contained in the sequence in total, we can know how many SHA256 calculations have been done by the calculator. By estimating the time taken for each hash computation beforehand, we can know the time interval between different transactions  (e.g., if 2 Xs are separated between T1 and T2, then they are also separated by 2 SHA256 computations, which is about certain milliseconds). After knowing the seconds between different transactions, it is easier to determine when each transaction occurs, saving a lot of troublesome work.

• In general, the Leader will keep executing the SHA256 function all the time to get a new X and move the sequence forward. If there is a transaction event, it is inserted into the sequence as an external input.

• If a node tries to publish a fake sequence in the network to replace the version published by Leader, for example, replacing X2 with X2' in the above, and then the sequence becomes X1, X2', X3 ..... Xn, obviously others just need to compare X3 and SHA256 (X2'), and then they can find that the two can’t match, so the sequence is fake.

Therefore, the counterfeiter must replace all the X's after X2'. But this is very costly and time-consuming especially when there are so many Xs. In this case, the best way is not to fake the sequence and forward it to other nodes after receiving the sequence from the Leader.

Considering that Leader will add its own digital signature to each packet released, the sequence disseminated in the network is actually “unique” and “tamper-proof”.

Network-wide Consistent Time Progression

Yakovenko, the founder of Solana, has emphasized that the biggest role of POH is to provide a “globally consistent single clock” (which can be translated as network-wide consistent time advance).

This statement can be understood as follows:

Leader publishes a unique, tamper-proof transaction sequence within the network. Based on the packets of this transaction sequence, the node can parse out the complete POH sequence. POH is Solana's original timing method and can be used as a time reference.

As mentioned earlier, since the Leader will keep executing SHA256 hash computation all the time to move the POH sequence forward, this sequence records the result of N times of hash computation, which corresponds to N times of computation process and contains the time lags. And Solana treats the number of calculations as a unique timing method.

In the original parameter setting, the default is that 2 million hash calculations correspond to 1 second in reality, and each Slot is 400 ms, meaning that the POH sequence generated by each Slot contains 800,000 hash calculations. Solana also coined a term called Tick, analogous to the ticking sound of a clock hand as it advances. By the setting, each Tick should contain 12,500,000 hash calculations, one Slot cycle contains 64 Ticks, and every 160 Ticks corresponds to one second in reality.

The above is only the ideal state setting, in the actual operation, the number of hash calculations generated per second is often not fixed, so the actual parameters should be dynamically adjusted. However, the above description can explain the general logic of the POH mechanism. This design allows Solana nodes to determine whether a Slot is finished and whether it is time for the next Leader to appear (4 Slots a rotation) based on the number of hash calculations contained in it after receiving the POH sequence. 

Since the starting point of each Slot can be determined, the Validator will divide the transaction sequence intersected between the starting points into a block. Once it is finalized, that means the ledger forwards one block and the system forwards one Slot.

***This can be summed up in one sentence: ***

“The hands of the clock don't turn back, but we can push it forward with our own hands.” New Century Evangelion said.

In other words, as long as the nodes all receive the same transaction sequences, the POH sequence can be parsed out and the corresponding time advancement are the same. This creates a “globally consistent single clock” (consistent time progression across the network).

In the original Tendermint algorithm, each node adds the same blocks to its local ledger, where the blocks are highly consistent and almost never fork, so according to Solana’s interpretation of “time advancement”, the time advancement should be consistent across nodes in Tendermint

In addition, since the number of transaction events in the POH sequence is predetermined, the nodes can know how many hash calculations (separated by several Xs) between different transactions just by their own calculations, and they can roughly estimate the time lag △T between different transactions.

With the approximate △T and some initial TimeStamp 0, it is possible to roughly estimate the moment of occurrence (TimeStamp) of each event, just like dominoes.

For example:

T1 occurs at 01:27:01, T2 is separated from T1 by 10,000 hash calculations (10,000 Xs), and if 10,000 hash calculations take about 1 second, then T2 occurs roughly 1 second after T1, which is 01:27:02. And so on, the time (TimeStamp) of all transaction events can be roughly estimated, which brings great convenience and allows nodes to independently confirm certain data delivery times.

At the same time, the POH mechanism also facilitates the counting of node voting time. Solana White Paper proposes that Validator should offer a vote within 0.5 seconds after each release of the State information by the Leader.

If 0.5 seconds corresponds to 1 million hash calculations (1 million X’s in the previous section), and after the Leader releases the State, 1 million consecutive hash calculations in the later sequence are not included in a node’s vote, everyone can know that the node slacks off and does not fulfill its obligation to vote within the specified time, and then the system can execute the corresponding penalty measures (Tower BFT).

Similarity with Optimism

The above is Solana’s original POH (Proof Of History), similar to Optimism and Arbitrum’s transaction sorting form, depending on hash-function-related calculations to establish a “tamper-proof” and “uniquely determined” transaction sequence, and then Leader/Sequencer publishes this sequence to Validator/Verifier.

A similar role of Leader called Sequencer exits in Optimism, which also replaces the block-structure in data transmission and periodically publishes the transaction sequences in a contract address in Ethereum, and asks Validators to read and execute it by itself. The transaction sequences received by different Validators are the same, so their state after execution must be the same. Comparing their State with Sequencer, each Validator can verify their correctness without communicating with other nodes.

In Optimism’s consensus mechanism, there is no requirement for different Validators to interact with each other or to collect votes, so the “consensus” is actually invisible. If Validator finds the State of Sequencer/Leader wrong after it had executed transaction sequences, it can send a “challenge” to question Sequencer/Leader. However, in this model, Optimism provides a 7-day window for transaction events to be finalized, and after Sequencer releases the transaction sequence, it requires zero challenge for 7 days before it is finally confirmed, which is obviously unacceptable to Solana.

Solana requires Validator to give a vote as soon as possible, to allow the network to reach consensus and finalize the transaction sequence quickly, which can be more efficient than Optimism.

In addition, Solana is more flexible in the way it distributes and validates transaction sequences, allowing a sequence to be sliced and distributed in pieces, creating the perfect ground for the implementation of the Turbine protocol.

At the same time, Solana allows nodes to run multiple computational components at the same time to verify the correctness of different fragments in a parallel manner, splitting the verification work and saving time significantly. This is not allowed in OP and Arbitrum. Optimism directly gives the transaction sequences in the form of Transaction-to-State mapping with one transaction corresponding to one post-execution State. This process can only be computed by one CPU core step by step from beginning to end to verify the correctness of the entire sequence, which will be weightier and more inefficient. In comparison, Solana’s POH sequence can be verified from any position, and multiple computing units can verify different POH pieces simultaneously, providing a basis for a multi-threaded parallel verification model.

Vertical Scaling For the Nodes Themselves

In addition to the above Solana’s improvements on block generation, consensus mechanism and data propagation protocol, Solana also creates mechanisms called Sealevel and Pipeline, and Cloudbreak, which support multi-threaded, parallel and concurrent execution modes, and support GPU as components for performing computations. This greatly increases the speed of node processing instructions and optimizes the efficiency of hardware resource utilization, which belongs to the category of vertical scaling. Since the technical details are complicated and not related to the focus of this paper, we will not elaborate on them here.

Although the vertical scaling of Solana significantly improves the speed of node devices in processing transaction instructions, it also raises the requirement bar for hardware configuration. Currently, Solana’s node configuration requirements are so high that it has been rated by many as “enterprise-class hardware level” and criticized as “the most expensive public chain in terms of node equipment”.

The followings are the hardware requirements for Solana’s Validator nodes:

12-core or 24-core CPU, with a memory of at least 128 GB, hard disk of 2T SSD, network bandwidth of at least 300 MB/s, generally 1GB/s.

Then compare that with the hardware requirements of current Ethereum nodes (before the transition to POS):

4-core (or more cores) CPU, with a memory of at least 16 GB, hard disk of 0.5 T SSD, and network bandwidth of at least 25 MB/s.

Considering that the Ethereum hardware configuration requirements of nodes will be turned down after its transformation to POS, the hardware requirements of Solana for nodes are much higher than it. Some claims that the hardware cost of one Solana node is equivalent to that of several hundred post-transformation POS Ethereum nodes. Due to the high cost of node operation, the operation work of the Solana network has largely become a privilege for whales, professional institutions and enterprises.

In response, Gavin Wood, former CTO of Ethereum and founder of Polkadot, had commented after Solana’s first downtime last year that real decentralization and security are more valuable than high efficiency. If users cannot run full nodes of the network themselves, then such a project will be no different from a traditional bank.

Full Summary

• Solana scaling is mainly based on: efficient use of network bandwidth, reduced frequency of node communication and speeding up node processing transactions. These measures directly shorten the time for block generation and consensus communications, but also reduce system capability (security).

• Solana discloses the list of Leaders in each Slot in advance, which essentially reveals a single trusted data source and thus significantly streamlines the consensus communication process. However, disclosing Leader information brings potential security risks such as bribery and targeted attacks.

• Solana treats consensus communication (voting information) as a transaction event, with often more than 70% of the TPS component being consensus messages, and the real TPS associated with user transactions being around 500–1000.

• Solana’s Gulf Stream mechanism essentially removes the global transaction pool, and although this improves the transaction processing speed, ordinary nodes will not be able to efficiently intercept spam transactions, and Leaders will face tremendous pressure, which can easily cause downtime. If a Leader is down, consensus messages cannot be published as scheduled and the network is prone to fork or even collapse.

• Solana’s Leader publishes transaction sequences instead of real blocks. Combined with the Turbine propagation protocol, transaction sequences can be sliced and distributed to different nodes, and the final data synchronization is extremely fast.

• POH (Proof Of History) is essentially a timing and counting method, which can stamp different transaction events with a tamper-proof serial number to generate a transaction sequence. At the same time, since only a single Leader releases the transaction sequence at the same time, including the POH timing sequence, Leaders essentially release a globally consistent timer/clock. So in a short window, the ledger advancement and time progression for different nodes are the same.

• In Solana, 132 nodes cover 67% of staked assets whereas 25 nodes cover 33% of the staked assets, leading to an oligarchy scenario. If these 25 nodes conspire, this is enough to throw the network into chaos.

• Solana has a high requirement for node hardware, and it achieves vertical scaling by raising equipment costs. But this also means that Solana is more reserved for whales, organizations or enterprises, which is not consistent with the vision of decentralization.

From a certain point, Solana has become a special existence in public chains. With its high-class node hardware, revolutionary consensus mechanism and network propagation protocol, it has pushed the narrative of scaling to an extreme, by reaching the long-maintained bottleneck of non-sharded public chains.

In the long run, decentralization and security will always be the core narrative of the public chain field. Solana, with its momentary TPS value and the push from financial giants such as SBF, became a hit supported by floods of capital. However, the end of EOS has shown that the Web3 world does not need pure marketing and high efficiency and only those with real usability can withstand the test of history.

Shout out to Mr. Liu Yang, author of Embedded System Security, the Rebase community and the W3.Hitchhiker team for their help with this article.

Reference

1. Solana White Paper in Chinese

2. Gulf Stream: Solana's Mempool-less Transaction Forwarding Protocol

3. Turbine Block Propagation

4. Solana Research Report

5. Solana’s Journey

6. How is Solana, a high-performance public chain partnered with Coinwallet, speeding up?

7. Overclock blockchain to 710,000 transactions per second: a review of the Proof of History algorithm

8. Solana's “Cinderella story” - SQLANA

9. PoS and Tendermint Consensus Explained

10. Ether source code analysis: transaction buffer pool txpool

11. Ethernet transaction pool architecture design

12. PBFT basic process

13. Tendermint-2-Consensus Algorithm: Tendermint-BFT Explained

14. Cardano (ADA) consensus algorithm Ouroboros

15. In-depth investigation: why new public chains have frequent downtime accidents?

16. In-depth Interpretation of Optimism: Basic Architecture, Gas Mechanism and Challenges | CatcherVC Research

17. Dissecting the New Version of Metis: The Decentralization of Gas Minimum Layer2 in Progress | CatcherVC Research

Author: Web3er Liu, CatcherVC

Abstract

After Optimism issued cryptocurrency, it solved the official financial problem, making it more motivated to reduce the handling fee; issuing airdrops is equivalent to handing over governance power, which can promote decentralization. 

In recent days, the news that one of the major Layer 2s - Optimism issued its own currency, has caused a stir in the entire crypto market and attracted widespread attention. It is another shot in the arm for the whole market provided by Optimism after it completed the $150 million financings round led by a16z in March. As Optimism officially released its token economic model and governance plan, the FOMO sentiment of many retail and institutional investors was completely ignited. Almost everyone is speculating: what will happen to Optimism after this cryptocurrency issuance?

I will analyze the event of Optimism's cryptocurrency issuance from critical perspectives, such as handling fees and node incentives and interpret the impact of the issuance on its ecological construction.

1. Optimism can solve financial problems after issuing its cryptocurrency, reduce the handling fee, and start a "price war" with other Layer 2s.

It is well known that the core of Layer2's value capture lies in the handling fee. Different L2 schemes rack their brains and do their best to repair the mechanism, almost all of which aim to reduce Gas fees. Not long ago, Metis reduced the Gas fees to the Polygon level by modifying the storage layer structure, which posed a strong price threat to other L2s.

On the other hand, since the Sequencer block-producing nodes are all run by the official, the Gas fee has been Optimism's most important source of income in the past. Therefore, the Optimism official cannot reduce the Gas fees to a few cents like Metis, which has already issued cryptocurrency. However, after Optimism's cryptocurrency issuance, the official has other sources of income, which can solve the financial problem to a large extent, which makes Optimism have a strong motivation to adjust the proportion of the fee structure and reduce the Gas fees.

Specifically, Optimism's fee structure can be divided into Part L1 + Part L2. Part L1 accounts for 99.6%, which covers the total cost of the block-producer Sequencer publishing data from Layer 2 to Layer 1. Its structure can be expressed as:

L1 Gas Price × dynamic coefficient × (Fixed cost + data storage fee)

Among them, the fixed cost, which covers the cost incurred when Sequencer packs data locally and transmits the data packet to the ETH network node across domains; the data storage fee, which mainly involves the Gas consumption generated when the data packet is stored in the specified contract address on ETH. The dynamic coefficient is used by Optimism to prevent the surge of ETH Gas. It is reserved as buffer funds for Optimism so that Sequencer can store data on ETH smoothly at any time.

According to Optimism's official documents, the fixed cost and dynamic coefficient are completely set autonomously by the Optimism official. If Optimism wants to lower it, Optimism can reduce it, and if Optimism wants to raise it, Optimism can raise it. Before the issuance of the cryptocurrency, the fixed cost and dynamic coefficient were the primary source of official income. However, after the issuance, Optimism official and its Ecosystem Foundation obtained nearly 40% of the token share, and 20% of the token share was used for the construction of Optimism’s public facilities, which basically solved the official's financial problem of Optimism and made it unnecessary to get stuck in the matter of reducing Gas. Then it dares to play the "price war" of Gas like Metis.

 (Reference: The Road to Sub-dollar Transactions Part 1: Slashing Fees by 30% https://medium.com/ethereum-optimism/fancy-numbers-how-we-lowered-fees-for-optimism-users-a3bb80cbc65f）

2. After the issuance, the Verifier node can be highly motivated to improve the reliability of the network

In the blockchain system, the incentive mechanism has always been one of the cores of mechanism design. Since the Verifier verification nodes of Layer 2 are to be run autonomously by private institutions other than the official government, the incentives for node operators are very important.

Optimism's important competitor, Metis, has more than 80 running Verifiers, which relies on the advantage of issuing cryptocurrency in advance, high-intensity incentives for Verifier node operators, and rapid expansion of node size. Adding peers in the Sequencer Pool, Metis has even reached the scale of a small public chain.

Without issuing cryptocurrency, Optimism Cannot directly incentivize Verifier node runners with the same high intensity as Metis and community members were not very interested in running verification nodes. Therefore, the Optimism official even complained in the medium document: "Users will almost never actively run a full node (Verifier node)."

With Optimism formally issuing the cryptocurrency, the official can use OP tokens instead of ETH to encourage Verifier node operators to greatly expand the node scale, just like Metis, thereby improving network reliability. In the meantime, the issuance can also enable Sequencer nodes to obtain higher operating incentives. If OP introduces a Sequencer decentralization solution in the future, the high incentives will encourage more private institutions to run Sequencer, which is conducive to decentralization.   3. Optimism's issuance makes its ecological governance more decentralized   We can imagine the following scenarios: if Optimism does not have its own token, what should OP community members do when they pledge their assets if they want to participate in ecological governance? Obviously, the most preferred way at this time is to pledge ETH. If users want to obtain ETH, they must spend funds to buy, or lend ETH assets through a loan agreement and pay interest, which obviously raises the threshold for OP users to obtain voting rights.   After the issuance of OP tokens, many early users can get a lot of airdrops for free, which is equivalent to providing many people with free voting rights and greatly improving the degree of decentralization of governance. As long as users do not sell their OP tokens, they can permanently participate in the OP ecological governance and obtain certain token holding incentives according to future policies, which is of great significance to the development of Layer2.   On the whole, the issuance enables Optimism to have the right to mint, just like the Federal Reserve, and solve its own financial problems. Then OP can adjust the activity intensity of the ecosystem through the token policy. In this regard, the liquidity mining incentive plan can be launched. On the other hand, various hackathon activities and ecological project subsidy programs can achieve. At the same time, the issuance also enables OP to raise large amount of funds through token financing, thereby gaining stronger vitality, just like Terra, Near, Avalanche, and other star projects refinanced long after the issuance of coins. Such benefits in this regard are self-evident.   4. Potential problems Although Optimism's official statement gave a specific token distribution plan, it did not clearly indicate whether OP tokens will be used as the unit of measurement for Layer2 Gas fees. If the OP token is not used as the gas payment method, it will lose one of the most important consumption scenarios, which is not conducive to gaining the market's bullish expectations.   But in general, since the issuance of OP solves the financial problem, the Optimism official has enough motivation to reduce the Gas fees and can quickly expand the scale of the network node, which will inevitably make it not to be outdone by Metis' recently launched "price war" of Gas fee and make it more competitive with Arbitrum Metis and ZK.

Author: Web3er Liu, CatcherVC

Read in Chinese Version

Abstract

• The fundamental problem with OP Rollups like Optimism and Arbitrum is the centralization of Sequencer nodes, which requires a solid solution.

• Metis tried to take the lead in realizing the decentralization of Sequencer. The project party has opened up the Peer Node network and transferred the power of running the Sequencer nodes to community members or other institutions.

• Metis changed the storage layer’s structure and changed the form of publishing data to Ethereum. By integrating Memolabs, the storage cost can be significantly reduced, making Metis one of the lowest Gas bills in mainstream Layer2.

• By introducing a new mechanism, the latest version of Metis, after integrating Memolabs, still has reliable security and data availability. The team judged the potential situation and developed effective measures.

• Metis supports node operators to register in the form of DAC (institutional DAO) to obtain continuous token income. At the same time, it provides a simple one-stop DAO carrying service, reduces the difficulty of DAO operation, opens up community ecosystem governance (CEG), and transfers the authority to maintain the Layer2 network to community members.

Problems with traditional OP Rollup

As concepts such as Web3, Metaverse, and NFT have entered the public eye in the past year, the Crypto industry has officially entered a period of rapid growth. Under the pursuit of various capitals and massive users, Ethereum has become the core of the entire Web3 narrative under its first-mover advantage. After a long evolution, its system architecture has fully realized decentralization and security, becoming a veritable "Stellar Public chain." At the same time, inefficiency severely limits the development of this public chain. Compared with VISA, which processes thousands of transactions per second, with a TPS of less than 20, Ethereum likes an antique of the old times, which is far cry from Vitalik's grand vision of a "world-class decentralized application platform."

In order to meet the massive demand of the Web3 market, different solutions such as Side Chains, new Public Chains, and Rollup have successively entered the stage of history. While star projects such as BSC, Polygon, Solana, Arbitrum, and Optimism are dividing up traffic, their inherent defects are more and more apparent. Since the block generation speed constrains TPS, almost all major Layer2 or new public chains have compressed the number of nodes or unbundled the "consensus" with the block generation process, which directly reduces the block time, but seriously weakens the decentralization and the system security.

Taking Optimism as an example, it uses a single miner node called Sequencer to generate blocks in Layer 2, blocks are generated in seconds. New blocks do not need to be immediately handed over to other nodes for verification but can be finalized locally, which saves a lot of time. Since there is only one block-producing node, the allocation of "bookkeeping rights" is deterministic, so the POW process (the step of randomly assigning bookkeeping rights) can be directly replaced.

By reducing the block generation process, Layer2’s local blocks can go from generation to finalization in 1 second or less. After the user initiates a transaction request, the result can be received in two or three seconds, evenly matched to WeChat Pay.

However, at this time, the new block of Layer 2 has not been audited by the verification node, and there is a possibility of non-compliance. In this regard, Sequencer regularly publishes a local copy of the block on Layer1, including transaction data and StateRoot (associated with the account information on Layer2). The Verifier (verification nodes) on Layer2 will automatically read the content published by the Sequencer and conduct audits to determine whether the Sequencer is suspected of fraud.

Essentially, Optimism uses Ethereum as a "court" for disclosing data and dealing with disputes, and the key point is how often Sequencer publishes data on Layer1. If the Sequencer submits local data for a long time, it will undoubtedly delay the audit progress of the Verifier, and it will take a long time for nodes to reach a consensus, which will seriously weaken the reliability of Layer2.

According to the official browser of Optimism, the time frequency of Sequencer publishing status information on Ethereum can be as slow as 37 minutes, which means that after Sequencer generates a block, Verifier will have to wait 37 minutes before auditing. In contrast, a new block in Ethereum takes only 13 seconds to be audited by nodes on the entire network. The information asymmetry between the Sequencer and Verifier nodes on Optimism is severe, and the reliability of the consensus mechanism is much lower than that of Ethereum.

In this regard, Arbitrum, which is also in the OP Rollup faction, shortens the interval for submitting status information to 2 to 5 minutes once, enabling Verifier nodes to conduct status audits as soon as possible, which significantly reduces the information gap.

However, Arbitrum has the same flaws as Optimism: The Sequencer node responsible for producing blocks is run by the official government, and the "bookkeeping right" is not transferred to the outside world. If the mechanical design is not yet perfect, "procedural justice" cannot be guaranteed. For the sake of insurance, the block producers of Arbitrum and Optimism are endorsed by the official credit to make up for the imperfection of the current system mechanism.

The consequences of this are clear: Arbitrum and Optimism essentially become centralized operators. Although both parties allow users to run Verifier (verification nodes) and challenge Sequencer freely, the official still has the absolute right to speak to the appointment and removal of Sequencer. In this way, even if Verifier points out that the current Sequencer has done evil and forces it to step down, the new Sequencer will still be officially designated.

Essentially, Layer2's block-producing power is concentrated in the hands of Arbitrum and Optimism officials, and its foundation is based on "credit" rather than "procedural justice." At the same time, running Sequencer nodes by officials will bring another big problem: the number of block-producing nodes is small, and the physical location is centralized, which is prone to DDOS attacks or other types of single points of failure.

Taking Arbitrum as an example, its Sequencer node went down twice, which has attracted widespread attention. On September 14, 2021, both Arbitrum and Solana went down due to DDOS attacks, and the block-producing node received too many transaction requests in a brief period, which eventually led to a crash; on January 10, 2022, Arbitrum's Sequencer node, When it went down again, the official said that the node had a hardware failure, and the standby node equipment did not complete the handover in time. Finally, the "single point of failure" caused the shutdown of the entire Arbitrum network.

It is conceivable that the disadvantage of centralized systems such as Arbitrum and Optimism lies in the excessive concentration of resources. Only a tiny number or a single node is responsible for generating blocks, which will make it bear a large amount of access traffic and quickly induce a single point of failure. Block power also makes "fraud-proofs" and "challenge mechanisms" useless, unable to curb the problem of node evil from the root.

Regarding their inherent defects, Arbitrum and Optimism officials have stated that they will gradually improve and implement decentralization in the future. However, the two have not given a reliable solution, and the concrete realization of decentralization is still far away.

In order to comply with the fundamental principles of decentralization, Metis, which is also the OP Rollup scheme, has officially started to reform the system architecture recently, trying to take the lead in realizing the decentralization of Layer 2 in terms of architecture and economy.

• By opening up the peer node network, Metis will transfer the power of running Sequencer’s block-producing nodes to community members or other institutions and promote the rapid synchronization of information between Sequencer and other peer nodes to prevent them from doing evil;

• Metis supports node operators to register in the form of DAC (institutional DAO) to obtain continuous token income.

• Metis officially opened the Community Ecosystem Governance (CEG) and further transferred the authority to maintain the Layer2 network ecology to community members.

Through the above methods, Metis plans to take the lead in realizing the decentralization of Layer 2.

In addition, Metis changed the format of backing up data on Ethereum. On the premise that the peer-to-peer node network can immediately verify the Sequencer's local blocks, and under the premise of preventing it from doing evil in the Layer2 network, Metis backs up the transaction instructions to the off-chain centralized platform, Memolabs, and provides the storage location of the transaction data in Memolabs on Layer1 instead, at the same time, the StateRoot corresponding to each transaction is still published on Layer1.

For the possible "challenge" and "fraud-proofs" scenarios, Metis adds other functions so that when the above scenarios occur, the challenger can restore the original data of each transaction instruction on Layer 1, and complete the "fraud-proofs" without hindrance, Make the existing version and the old version's mechanism equivalent.

By introducing peer nodes and integrating the Memolabs storage layer, Metis shifts the storage task from Ethereum to peer nodes, Ethereum, and Memolabs and introduces new mechanisms to ensure reliability. Since the other two share the storage task, Metis can reduce the data capacity published on Ethereum as appropriate, reducing Gas consumption and significantly reducing the Layer 2 fee.

In the following, the author will interpret essential measures such as Metis' implementation of a peer-to-peer node network and integration of Memolabs storage.

Peer Node: Implement Block Producer---Sequencer Rotation

In conventional OP Rollup schemes such as Optimism and Arbitrum, block producers have uniquely identified: only one Sequencer executes transactions and packing blocks. This directly eliminates the randomness of the block-producing nodes. At the beginning of each block-producing cycle, the system no longer has to waste time selecting block producers-in contrast, before each new block is generated in Ethereum, it has to pass The POW or POS process (after merging) randomly selects the block producing node, which seriously delays the time.

However, the randomness of the block-producing node can significantly reduce the probability of a single point of evil due to the frequent rotation of accounting nodes, the possibility of malicious nodes controlling the right of charging to an account is very low. Even if a malicious node obtains the accounting right of a new block, it will still be rejected by other honest nodes if the block’s publication is not compliant. Finally, the honest nodes will re-elect a new block producer, re-publish a compliant block, and the malicious node will be directly overhead.

In this case, as long as 2/3 of the nodes in the network are honest, the malicious nodes can be effectively restrained, which is the famous PBFT mechanism (Practical Byzantine Fault Tolerance). However, the effectiveness of PBFT is based on enough nodes. PBFT will only take effect when the number of nodes is enormous, it is difficult for malicious nodes to attract a large number of nodes, and it is not easy to form collusion. When the number of nodes participating in the block generation is small, PBFT will no longer be applicable, and at this time, the possibility of a single node of evil is exceptionally high.

Existing OP Rollups, including Optimism and Arbitrum, almost all agree that Sequencer will not do evil by default. If the Sequencer behaves maliciously, the Verified node is allowed to "impeach" it, this process is called "challenge." However, the problem is that the data synchronization between the Verifier node and the Sequencer is not immediately performed, and there will be a delay in the middle.

As mentioned earlier in this article, the data synchronization delay of Optimism nodes can exceed 30 minutes, and it will take half an hour after the Sequencer generates a new block for the verification node to audit, which will cause potential security risks. Although Arbitrum reduces the delay to a few minutes, it does not open the authority to run Sequencer to institutions other than the official government, which is not conducive to economic decentralization. In addition, it is based on the "credit" of the project party, which seriously violates the “procedural justice" principle of blockchain.

In addition, since Optimism and Arbitrum do not issue tokens, they cannot incentivize validator node operators with high intensity, which is not conducive to expanding the number of nodes, making Layer2 more like a consortium chain rather than a public chain.

In order to avoid the above problems, Metis has made many improvements to the original architecture of Optimism, the most important of which is to open the Peer Node.

• Conventional public chains such as Bitcoin and Ethereum are P2P networks composed of peer nodes. These nodes will frequently synchronize information to ensure consistent status; simultaneously, each peer node can voluntarily become a miner and participate in block generation. After a new block is generated, it will be propagated to other peer nodes for auditing purposes.

• Metis has built a peer-to-peer node network called Sequencer Pool, allowing community members to run peer-to-peer nodes. These nodes act as Sequencer through rotation and solve the centralization problem of Sequencer nodes in OP Rollup;

• After the current Sequencer produces a block, it will synchronize the new block to other peer nodes for auditing to prevent a single point of evil. Every once in a while, the Sequencer will be changed to achieve the decentralization of accounting rights.

• Every block generation cycle of ordinary public chains has a process of randomly selecting block producers, which will waste much time. There are not as many peer nodes in the Sequencer Pool as large public chains, and the rotation period of block producers is relatively long. Within each cycle, the Sequencer remains single. In the future, Metis will gradually shorten the rotation cycle and introduce a new timestamp generation mechanism.

• Metis supports community members in running peer-to-peer nodes and provides token incentives for them. Peer-to-peer node operators often register in the name of DAC (institutional DAO). The hardware device is equipped with a minimum of 8-core CPU and 32GB of memory and must pledge a certain number of Metis tokens.

In essence, the Sequencer Pool, which was initially a subnet under the Metis network, has become a "committee." This committee is composed of peer nodes. Its function is to act as or supervise a Sequencer, similar in form to a POS public chain.

According to the scheme being implemented by Metis, the Sequencer Pool has been put into operation with a scale of more than a dozen peer nodes. Under such a network scale, the time complexity of communication between peer nodes is less, and consensus on new blocks can be reached immediately. At the same time, different peer nodes can act as network loads to meet external access requests, and users do not need to accept data provided by a single node unilaterally.

Metis now gets two security layers from the peer-to-peer nodes network and the Verifier nodes. Among them, the peer-to-peer nodes can verify the local data of the Sequencer on Layer2 in real-time, and the Verifier is mainly responsible for verifying the data submitted by the Sequencer to Layer1.

In the future, Metis plans to expand the number of peer nodes in the Sequencer Pool on a large scale to make it more secure, and incorporate the Verifier verifier node into the Sequencer Pool list, so that all peer nodes can act as Sequencer, as well as serving as Verifier. At the same time, Metis plans to introduce a new algorithm and timestamp generation mechanism while maintaining high efficiency to achieve "change the Sequencer every few blocks" to ensure decentralization.

New storage structure - "Don't add entities if you don't have to"

In most public chains or Layer 2, the database that records user information adopts a tree-like structure, called a state tree, and the hash value of the tree root is called the StateRoot. After a transaction instruction is executed, the status of some accounts will inevitably change, and the hash value of the root of the status tree will also change accordingly. It can be said that the execution of each transaction will generate a new StateRoot. From the perspective of time, the two are in a one-to-one correspondence.

If you list each [transaction instruction content] and the corresponding [StateRoot] in chronological order, you can get an accurate ledger. In traditional OP Rollup schemes such as Optimism, this is what Sequencer stores on Ethereum.

The Verifiers read these and check their accuracy. Generally speaking, the Verifier node will execute the transaction instructions in chronological order and obtain a batch of StateRoot through its calculation. After that, the Verifier only needs to compare the StateRoot calculated by itself with the StateRoot submitted by the Sequencer. For example, when a teacher does not know the standard answer in advance, he temporarily uses mental arithmetic to correct students' math homework.

If Verifier finds a problem with a transaction instruction or the corresponding StateRoot submitted by Sequencer, it will initiate a "challenge" and provide a "fraud-proof."

In Optimism and older versions of Metis, Sequencer will publish transaction instructions and corresponding StateRoots to Ethereum, essentially using Ethereum as a storage layer and using the Ethereum network to handle the "challenge" process. Although this can ensure data availability, the Gas consumption is very high.

Take a batch of transactions released by Optimism in Ethereum as an example. The batch contains a total of 204 transaction instructions, and the gas fee consumed exceeds US$211, which is equivalent to the storage fee of a single transaction instruction exceeding US$1; additionally, considering the Gas required to store the corresponding StateRoot for this batch of transactions , Optimism's storage fee for a single transaction can reach $1.50, which is still too high for most users.

In response to this problem, Metis has made essential adjustments recently. Metis does away with the step of directly storing transaction instructions on Ethereum and dumps transaction batches to Memolabs, a platform similar to Filecoin but with lower storage costs and faster data retrieval speed. By integrating the Memolabs storage layer, Sequencer first stores many transaction instructions in Memolabs and then publishes the storage index corresponding to this transaction batch on Ethereum. The Verifier node can read the original transaction data from Memolabs through the index value.

At the same time, since the StateRoot is more critical than transaction data, they are still stored in Ethereum.

To sum up, the philosophy of Metis is: that there is no need to deposit the content of Ethereum, and it can be exchanged for the equivalent in other ways. This can save storage costs and reduce the cost pressure on users. This aligns with Occam's razor: "Do not multiply entities if you do not have to."

Through this storage structure, Metis can significantly reduce storage fees, reducing the transaction fee of a single Layer 2 transaction to a few cents. Metis has become the lowest gas fee in mainstream Layer 2.

However, Metis's approach raises other questions: Does changing the storage structure change security or data availability? In this regard, we will analyze a variety of possible outcomes.

The security and data availability issues of Metis and OP rollup have two aspects. The FIRST ONE is:

When the Sequencer executes the transaction in Layer 2, it will immediately finalize it locally, temporarily possessing "finality." The specific scenario is that after a user initiates a transaction request on the Metis network, the result will be received within seconds. The question here is, is the temporary "finality" given unilaterally by Sequencer reliable?

Since Metis's Sequencer will immediately synchronize the information to the peer nodes of the Sequencer Pool after the block is generated, the nodes can immediately audit the block content, and if it is found that the Sequencer has submitted an illegal block, it can be removed from the Sequencer Pool. Therefore, the security here is equivalent to that of ordinary public chains. At the same time, the outside world can choose information sources among multiple peer nodes without unilaterally trusting a node, and there is no problem with data availability.

The SECOND QUESTION is:

Will the verification process and challenge mechanism be affected after Metis transfers the transaction data to Memolabs? Will the nodes that newly join the Metis network encounter inconvenience when synchronizing historical data?

There are many possible situations involved here that can be classified and discussed. Since Metis still publishes the StateRoot to Ethereum, the availability of the StateRoot will not be affected. The availability of transaction data is targeted at Verifier nodes or nodes newly added to the Metis network.

For the latter, new nodes only need to synchronize historical data through other Verifiers or peer nodes and can also read transaction data on Memolabs and StateRoot records on Ethereum. At present, Metis has more than 80 privately running Verifier nodes, which already have vital data availability. Considering that the number of Verifiers is still expanding, new nodes should not face many problems when synchronizing historical data.

The problem is for the existing Verifier nodes: whether the transaction data can be successfully obtained and the corresponding StateRoot can be checked. If it is found that the content submitted by Sequencer is incorrect, can the "challenge" be successfully carried out on Ethereum?

For this problem, the following scenarios can be analyzed separately:

1. If Sequencer provides the Memolabs index on Ethereum so that Verifier can read the transaction data smoothly. After checking that these transaction instructions are correct (digital signatures, etc., are correct), the remaining checkpoint is the StateRoot stored on Layer1.

• If, after auditing, each transaction can be matched with the corresponding StateRoot, Verifier completes the data synchronization, and there is no need to initiate a "challenge." There is no problem at this time.

• If Verifier finds that a particular transaction instruction and StateRoot cannot match, the StateRoot must be wrong. The Verifier can ask Sequencer to disclose the transaction data corresponding to the Error Status Root to Layer1.

• If the Sequencer agrees, the "challenge" process goes smoothly, and the Sequencer is penalized;

• If Sequencer does not agree, Verifier can write the transaction data read in Memolabs into Ethereum to complete the "challenge," and Sequencer will also be punished;

Obviously, in the above scenario, data availability and "challenge" mechanism are not affected.

2. If the Sequencer stores forged transaction instructions in Memolabs (the digital signature is invalid), Verifier will initiate a "challenge"; in addition, Verifier must obtain the correct Layer2 native transaction instructions to verify the correctness of the StateRoot.

At this time, Verifier can ask Sequencer to publish related transaction batches on Ethereum, which will cause Sequencer to spend a lot of gas fees, which is equivalent to a disguised penalty; If Sequencer refuses, Verifier can disclose the wrong data read from Memolabs to Layer 1 and start a "challenge," Sequencer will be punished more severely.

Under normal circumstances, after the Verifier successfully challenges the Sequencer, the loss it suffers will be much higher than the gas fee consumed when the transaction batch is published on Layer 1. Therefore, if Verifier requires Sequencer to publish transaction data on Layer 1, it must disclose the correct transaction data.

At this point, the Sequencer must release a single transaction batch required by the Verifier, which contains hundreds or thousands of transaction data, and the gas consumed when Layer 1 is released will be very high, even hundreds of dollars, which is equivalent to a disguised penalty.

As seen from the above discussion, data availability and the "challenge" process are not affected.

3. If Sequencer publishes a fake Memolabs storage index on Layer 1, Verifier cannot successfully read the data contained in the transaction batch. At this time, it can request Sequencer to disclose the transaction batch on Layer 1 as described above. If it refuses, the Verifier can obtain the corresponding data from the peer node, continue the subsequent verification work, or initiate a challenge.

Through the above well-designed mechanism, Metis can protect the rights and interests of Verifier nodes. However, in order to prevent Verifier from abusing its power and maliciously requiring Sequencer to write transaction data in Layer 1 and to attack honest Sequencer runners through gas consumption, Metis makes the following requirements:

• If Verifier requires Sequencer to write transaction data on Layer 1, it needs to pledge a certain amount of funds in advance to obtain the whitelist qualification, and every time a similar command is issued to Sequencer, a handling fee will be consumed; the value of this handling fee has been carefully calculated It can prevent Verifier from frequently sending unreasonable requests to Sequencer.

• Any node can initiate "challenges" and "fraud proofs." In theory, these nodes can cooperate to ensure data availability and security.

In conclusion

According to the core arguments put forward above, combined with the recent official developments of Metis, it is concluded here:

The fundamental problem of OP Rollups such as Optimism and Arbitrum is the centralization of Sequencer nodes, which requires a reliable solution; Metis tries to be the first to realize the decentralization of Sequencer.

• Metis opens the Peer Node network, cedes the power of running block-producing Sequencer nodes to community members or other institutions, implements a rotation system, and promotes rapid synchronization of information between Sequencer and other peer nodes to prevent them from doing evil;

• Metis changed the storage layer structure and data backup form on Ethereum. By integrating Memolabs, Metis has significantly reduced storage costs and has become the lowest gas fee in mainstream Layer2.

• Through careful mechanism design, the new version of Metis, after integrating Memolabs, still has robust security and data availability. The Metis team has judged the possible situations and formulated corresponding measures;

• In order to further reduce the power of Sequencer, Metis plans to add the role of Proposers in the future. After Sequencer publishes transaction data, Proposers are responsible for submitting the StateRoot corresponding to each transaction to Ethereum, which can form more vigorous decentralization checks and balances.

• Metis supports node operators to register in the form of DAC (institutional DAO) and provides them with continuous token income. In this regard, issued Metis has an advantage over unissued Optimism and Arbitrum;

• Metis provides a simple one-stop DAO delivery service, reduces the operational difficulty of DAO and DAC organizations, opens up Community Ecosystem Governance (CEG), and transfers the authority to maintain the Layer2 network ecosystem to community members. The Metis ecosystem has 500 DAC organizations with nearly 5,000 members.

• After Metis integrates the Memolabs decentralized storage layer, DAO organizations within the ecosystem can transfer data that does not need to be disclosed to Memolabs. The corresponding storage index can only be accessed by permitted users, which ensures that DAO maintains its privacy.

• Metis will support the Fragment structure of multiple subnets in the future, allowing different DAO organizations to run MVM virtual machines with independent states to achieve a multi-chain fragmented mechanism similar to ETH2.0.

• Recently, Metis has opened the NFT bridging function; combined with ultra-low gas fees, Metis is committed to building the best platform for NFT users;

• In the future, under the condition that the system's fault tolerance is strong enough, Metis will shorten the challenge period as appropriate and become the most convenient cross-chain in Layer2

Arbitrum, Optimism, Metis and ZKSync are the most competitive Layer2 smart contract platforms for their TVL and development momentum.

Author: Web3er Liu, CatcherVC

Read in Chinese Version

Intro

If the financial market represents an iterative history of human behavioural patterns, the Internet and Web3 represent the chronicles of communication system expansion and security optimization. From ARPANET, the originator of the Internet launched in 1969, to the congested Ethereum system due to the NFT frenzy in 2021, the evolution of decentralized networks mainly revolves around speed and security. However, the current development progress for Layer 1 and 2 projects almost entirely becomes technological narratives about gas fees.

Since the explosive growth of the entire crypto industry at the beginning of 2021, the 24-hour transactions volume on Ethereum has remained over one million, and the average transaction fee once soared to $50. For example, during the NFT frenzy and “519 Flash Crash” events, the gas fee for one transaction cost hundreds of dollars. The high gas fee stopped countless users from sending transactions.

(Image Source: The Block)

(Image Source: Etherscan)

In response to the high gas fee, Su Zhu, founder of Three Arrows Capital, said: “Ethereum has abandoned its users, and newcomers can no longer afford to use this chain.” Thereafter, the entire blockchain industry bashed Ethereum’s congestion and took on a prolonged debate.

Related reading: 《The Battle of the Year: Public Blockchain Competition Triggered by the Three Arrows Capital》

Debate: Layer1 versus Layer2

Similar to the history of Christianity in the 16th century, KOLs separate into two schools, which advocate for “New Public Blockchain” and “ETH 2.0 and Layer2”. While Solana and Avalanche were fighting for the top “New Public Blockchain,” Layer 2 networks also gained more traction. Specifically, since the launches of Arbitrum, Optimism and zkSync in 2021, these networks have gradually accelerated the development of the Layer 2 ecosystem. For instance, TVL, the total amount of locked funds in Layer 2, has increased by more than 600% in the past six months, reaching $6 billion US dollars. According to multiple data sources such as ETHTPS.info, on Mar 15, 2022, about 150,000 transactions were processed through Layer 2, weighing more than 12% of Ethereum Mainnet’s.

From TVL and development momentum perspective, Arbitrum, Optimism, Metis and zkSync are currently the four most competitive Layer 2 smart contract networks.

(“Layer 2 Total TVL”, Image Source: L2BEAT)

(“ETH Mainnet vs Layer2 networks’ TPS”, Image Source: ETHTPS.info)

Considering that the Layer2 user scale is much lower than the Ethereum Mainnet, Layer2 user activities are more active than Layer1’s. And, since Layer2 indicators are hard to query, CatcherVC uses “number of transactions per day/number of unique addresses” (the average number of daily transactions per user) and “TVL/number of unique addresses” (the average number of values locked per user) to measure the network activity. By arranging the on-chain data website such as Dune Analytics, L2Beat, and L2Fees, we computed the following chart:

(Collected on March 15, 2022 by CatcherVC)

According to the comparison chart, Layer2 networks, such as Optimism, Arbitrum, and Metis, are more active than ETH Mainnet. However, the Layer2 ecosystem is still in its early stage. The user scale is small, and the TPS of most networks is less than 5% of Ethereum’s. In brief, the utilization rate shows that Layer2 networks have tremendous potential for value-added and traffic capability.

1. Optimism

Optimism **completed a $150 million funding round **on March 17, 2022. Its daily average TPS is about 0.35, only 2.5% of Ethereum’s. In the past week, the net money inflow was $12 million, and **the total value on the chain reached $630 million, with a TVL exceeding $450 million. Thus, Optimism ranked 4th among Layer2 networks. **Optimism developers updated the code and the number of new contracts more than 40 times per day and 30 times a week. Furthermore, DefiLlama is tracking 25 projects on Optimism, including Uniswap, Curve and Synthetix, etc.

(Image Source: Dune Analytics)

Compare the “number of daily transactions” to “number of daily active addresses,” we can see that the **average daily transaction per user for Optimism is 12 to 16, six to eight times more than Ethereum’s. **Because active users can equally share gas fees in Optimism in the same period, the network utilization rate of Optimism will continue to rise with its growing user scale. Thus, the gas fee may further decrease to motivate users to transact actively, creating an echo mechanism for its users in return.

(Image Source: Dune Analytics)

(Active Ethereum Unique Addresses, Image Source: Etherscan)

2. Metis

Metis raised $8 million in the previous funding round. The project adopts an architecture similar to Optimism and “Executes transactions on Layer2, saves transactions, and initiates challenges for validators on Layer1. “ Its design is a branch of the Optimistic Rollup design.

**In the past week, Metis’ net money inflow was $200 million, and the TVL exceeds $740 million, **ranking the 3rd among Layer2 networks. DefiLlama is tracking 13 projects on Metis, such as NetSwap. As its average daily TPS is only about 0.25, less than 2% of Ethereum’s, its adoption rate has more room to grow than Optimism.

(Image Source: L2BEAT)

According to Dex Screener, Metis showed strong Defi activity. Specifically, the main DEX on Metis can reach $30 million in average daily trading volume, with Hermes protocol contributing the largest share of DEX trading volume on Metis. Metis reaches 70% to 80% of Arbitrum and Optimism’s daily trading volume. As major Defi protocols, such as Uniswap and Curve, have not launched on Metis, its number of users is far less than that of Arbitrum and Optimism’sOptimism’s (only 20% of Optimism). Thus, this makes Metis’sMetis’s Defi market has more potential to grow. Recently, Metis announced that it would launch the NFT cross-chain bridge and support IPFS local storage soon.

(Image Source: Dex Screener)

3. Arbitrum

Arbitrum is another leading Layer 2 solution that completed a $120 million Series B funding round in 2021. With a larger capital volume and a more diverse ecosystem, the TVL of Arbitrum exceeds $3 billion, accounting for more than 50% share of the total Layer 2 networks’ TVL. DefiLlama is now tracking 66 projects on Aribitrum, with major Defi projects deployed, such as Uniswap, SushiSwap, Curve, Beefy, and Yearn. Its daily average TPS is 0.7, which equals nearly 5% of Ethereum’s.

(Image Source: The Block)

(Image Source: Nansen)

Arbitrum is not in a good state in terms of net inflows of funds, as it lost $57 million in the last week. In the past six months. The whole chain was down twice due to the failure of a single Sequencer node design, which made the investors question its reliability. In this regard, the founder of Arbitrum said that they would introduce a decentralized form of multiple Sequencer nodes to resolve the problem.

Arbitrum recently released a sidechain plan on about AnyTrust, making its sidechain performance and cost the same as Polygon. Its sidechain will upload the root hash status for each block to Ethereum Layer 1 and switch to Rollup mode when the state of its nodes is underperforming. Overall, AnyTrust will run alongside the Arbitrum network and is expected to come close to Polygon’s performance and fees.

(“TVL of Optimistic Rollup Solutions is much higher than ZK Rollup’s”, Image source: Footprint Analytics)

4. ZKSync

ZKSync is a ZK Rollup Layer 2 solution. It completed a $50 million Series B funding round in November 2021, led by a16z. Because of the difficulties of zero-knowledge proof theory and technology, the progress for ZK projects’ EVM compatibility is plodding. Compared to OP Rollup networks, an EVM-compatible solution, such as Optimism, ZK networks’ ecosystem, TVL, and user activities, are significantly behind.

**ZKSync net money inflow was $23 million in the past week, and its TVL exceeds $1.3 billion. **DefiLlama is only tracking one project on ZKSync, which is ZigZag, while there are currently ten protocols running on ZKSync, according to its official website. Currently, ZKSync’s average daily TPS is about 0.2.

(Image Source: L2BEAT)

While ZKSync’s on-chain metrics are not as strong as other OP Rollups,** its EVM-compatible Testnet, called ZK-EVM, has launched in February 2022** and is generally favoured by KOLs in the industry. Since ZK Rollup can achieve higher TPS and ensure more secure transactions than OP Rollup, with the official launch of ZK EVM, ZKSync might become the leading network among all Layer 2 solutions.

Summary

Overall, the Layer 2 solutions are still in the primitive early stage. Compared with the Layer 1 public blockchains and Defi projects that have been explosive in 2021, the primary Layer 2 projects seem undeveloped and undervalued. As ETH 2.0 rolls out, Layer 2 is on the eve of the outbreak and will surely accelerate its development with VCs’ funding. At last, may Layer 2 refine the current blockchain industry.