Today’s smart contracts are complicated. They support more complex applications. Smart contracts need to store, query, and process more complicated and larger data. Smart contracts are highly coupled with data. Thus these complicated data process scenarios make smart contracts complex and hard to maintain. Developers need to add data-related logic to their contracts, like data queries, data updates, and data filtering. For different data structures, developers need to write different functions.

Besides extra complexity, another problem is flexibility. When developers need to query data with complex filters, developers need to add custom query functions to the contracts. Developers cannot directly read and filter the data.

In the Web2 world, the database takes all data-related work. Applications store clean and structured data in the database. Developers can read desired data with SQL. Data are decoupled with applications.

Tableland is born to solve these problems. Tableland call itself, Web3 native database.

Because on-chain data storage is expansive, Tableland uses the off-chain database and on-chain smart contracts for privilege checks and data modification.

1. Dapp smart contracts send data update requests to Tableland smart contracts

2. Tableland smart contracts check the caller’s privilege and emit events with query

3. Tableland off-chain validator network monitor on-chain event and execute SQL

4. Sync Tableland off-chain validator network

⚠  Although developers can use smart contracts to execute SQL, dapp smart contracts cannot get any return values. This hurts composability.

Tableland solves this problem with a dapp frontend, dapp smart contracts, and Tableland three-parties interaction. The dapp frontend reads data and dapp smart contracts update data.

Dapp frontend reads data from Tableland gateway. Tableland gateway can directly interact with Tableland off-chain validator network. The function of the Tableland gateway is similar to the function of blockchain RPC. With the gateway, developers don’t need to build their own network nodes.

If the dapp frontend sends a data update request to the gateway, the gateway will relay the request to the Tableland smart contacts.

As a "Web3 native database", Tableland still has lots of limitations:

• Dapp smart contracts cannot read data and receive execution results. Developers cannot put all data-related logic into smart contracts

• One table is limited to 100k lines row, 24 columns

• One data cell is limited to 1kb

• Only support a subset of SQL, CREATE TABLE, INSERT, UPDATE, DELETE, SELECT, GRANT, REVOKE

• Only support some types, INT, REAL, TEXT, BLOB, ANY

Tableland names itself "Web3 native database". This is a little exaggerated because of the bad composability between contracts and data. Now Tableland can be applied to games and NFT.

Tableland has great support for NFT. After creating the table and inserting NFT metadata, developers get a gateway link. Developers can use this link as URI.

Later developers can use Tableland CLI to update NFT metadata.

Tableland will release its NFT in July. NFT holders can access more development functions. In the future, Tableland will make improvements in the following areas:

• Support more SQL

• Decentralize the validator network

• Release tokens and use tokens to secure the validator network

• Database admin panel

Tableland is not the end of the Web3 native database. A truly Web3 native database should satisfy the following requirements:

• Separate contracts and data

• Composability between contracts and data

• Censorship resistance

• Support Web3 data types, like address and transaction

• Users have data ownership

If your project satisfies the above points, feel free to DM me on Twitter.

Arbitrum 是一个 EVM 兼容的乐观证明 L2。虽然 EVM 兼容，但是在一些变量上会有所区别。例如我们在 L2 获取 block.number 时，我们得到的是 Arbitrum 上的区块高度，而不是以太坊上的区块高度。

下图是 Arbitrum 的框架图。基本分为 L2 和一系列部署在 L1 上的智能合约。

Arbitrum 部署在 L1 上的桥组件负责 L1 和 L2 的沟通。这个组件包含 4 个智能合约：Inbox，Outbox，Rollup 和 Dispute。在这里可以找到这些合约的代码。

在这篇文章中我们将关注 L1 和 L2 的通讯，也就是 Inbox 和 Outbox 两个合约。

L1 和 L2 的通信由桥组件基于消息传递实现。消息分为两种：L1 消息，L2 消息。L1 上的智能合约可以直接读取 L1 消息。L2 消息给 L2 来读取。我们使用包含 L2 消息编码的 L1 消息来将信息从 L1 传递到 L2。目前一共有六种信息：

• ETH_TRANSFER : 以太坊转账

• L2_MSG : L2 上的消息

• L1MessageType_L2FundedByL1 : 包含 L2 信息编码的 L1 信息，由 L1 支付手续费

• L1MessageType_submitRetryableTx: L1 上的 Retryable Ticket

• L2MessageType_unsignedEOATx: L2 上未签名的用户交易

• L2MessageType_unsignedContractTx : L2 上未签名的合约交易L2

有两种方法可以将信息从 L1 发送到 L2。第一种是直接调用 Send 相关的函数。用这种方式发送信息延迟较低，并且使用起来比较简单。

第二种方式是创建 Retryable Ticket。接着用户在 L2 兑换这张 Retryable Ticket。这种方式方式的设计初衷是为了弥补第一种方式会因为 Gas 不够而失败。下图展示了三种具体发送信息的方法。

L1 发送到 L2 的消息会被放在 Inbox，例如将以太坊存入 L2。任何人都可以将消息放入 Inbox 中。但是当信息在 L2 被执行时，用户无法得知具体执行结果。

下图展示了信息如何流动的。 用户将消息发送给桥组件。在未来24小时，只有 Sequencer 可以执行这些消息。24 小时后，任何人都可以执行这些消息，并放到 Main Seqeuncer Inbox。这个机制有效防止 Sequencer 作恶和审查。

如果消息是直接由 Sequencer 提交的，Sequencer 可以立即将消息提交至 Sequencer Inbox。

可以在这找到 Arbitrum Inbox 的源代码。代理合约部署在了 0x4dbd4fc535ac27206064b68ffcf827b0a60bab3f。Inbox 合约部署在了0xc23e3f20340f8ef09c8861a724c29db43ba3eed4。

Inbox 拥有以下 Interfaces：

• sendL2MessageFromOrigin()

• sendL2Message()

• sendL1FundedUnsignedTransaction()

• sendUnsignedTransaction()

• sendContractTransaction()

• depositEth()

• createRetryableTicket()

目前使用最多的函数是 depositETH() 。这个交易就调用了 depositETH() 。这笔交易发送了信息 L1MessageType_submitRetryableTx，并且释放了两个事件：

• MessageDelivered

• InboxMessageDelivered

让我们放大这张图，仔细看看用户的信息是如何被提交到 Bridge 合约的。

消息相关的数据从 Inbox.sol 流到 Bridge.sol。数据最后被存在了 Delayed Inbox Accumulator 的末尾。

在这个生命周期，所有事件中，有两个事件包含了消息状态的转变。一个标志消息被放到 Inbox，另一个标志信息被加入队列。

TL;DR

• ZK technology is primarily applied for enhancing scalability, privacy, and credibility in various projects like Starkware, zkSync, Scroll, Mina, Risc0, Giza, EZKL.

• ZK technology requires significant computational power, leading to 10^4 to 10^6 computation overhead, posing challenges for infrastructure teams.

• The main approaches to generating ZK proofs are Proof Markets and Proof Networks. Proof Markets operate as open markets for trading ZK proofs, while Proof Networks have internal servers, offering a cloud service-like experience for generating proofs.

• The Proof Market approach allows for flexibility and cost-effectiveness, as it facilitates an open market for ZK proof trading without the need for high-end server management.

• The Proof Network approach provides a streamlined and developer-friendly experience, offering a hassle-free solution with less focus on market mechanisms, ideal for quick and reliable proof generation. Theoretically, it provides fast proof generation since order matching in proof market also takes time.

• Challenges include testing and debugging difficulties, new security concerns, potential vendor lock-in, higher costs for certain usage patterns and loss of token utility.

• Leading players are likely to be those with the most internal ZK proof demands, as they can leverage existing infrastructure and specialized teams, maximizing hardware utilization.

• Emerging applications include ZK Coprocessors, ZK Attestation, ZKML (Machine Learning), and ZK bridges, all contributing to an increased demand for ZK proof generation.

• Decentralized proof networks in the ZK space are driven by the blockchain industry's preference for security, censorship resistance, and privacy, although ZK's inherent security means decentralization is not a prerequisite for these benefits. Performance is the major concern for ZK.

After years of research in ZK area, and vast improvement in performance, ZK is finally applied in real-world applications. Talented engineers apply ZK for

• Scalability

• Privacy

• Credible Compute

There are lots of interesting projects relying on ZK, like Starkware, zkSync, Scroll, Mina, Risc0, =nil;Foundation, EZKL, Giza, Polygon, Manta. These projects steadily and continuously generate ZK proof every day. The most popular ZK use case today is ZKRU to solve the Ethereum scalability problems. In the last month, ZK verification costs millions of dollars on Ethereum/Ethereum L2s.

This chart built by Near team illustrates the zkSN(T)ARK gas spending on Ethereum and L2s. It includes popular ZK projects like zkSync, Polygon, Aztec, Tornado Cash, Loopring, Worldcoin, Tailgun, Sismo, StarkNet, ImmutableX and dydx.

zkSnark takes 80% of the total costs on verification, compared to zkStark. Among all these projects, Worldcoin has the highest verification cost, followed by zkSync. Each worldcoin verification cost around $2. Each zkSync verification cost around $30.

ZK can solve the Scalability problems but with some tradeoffs. It requires tons of computation power. ZK brings lots of computation overhead which Rollup teams need to take care of. @_weidai estimated 10^4 to 10^6 computation overhead with today’s ZK technology. Theoretically, we can achieve 10x computation overhead with dedicated circuits. With the abstraction of VMs, there would be 100x computation overhead.

The following graph illustrates the computation power growth based on Koomey's law. The efficiency of chips improves 10x every 10 years after the year 2000. If we treat computation power in the Year 2000 as the base, we reach 784 in the Year 2025. This also indicates that the ZK computation is still not comparable to Year 2000.

https://visualize.graphy.app/view/04f82b27-3654-47eb-83e8-3981f6e258be

Think about that for a while. We are trying to bring 10-100x transactions to ZKRU. With more transactions, we also will have 10^4 - 10^6 computation overhead. These numbers give the ZKRU infra team lots of pressure. Leading ZKRU teams are using really high-end machines with at least 200GB RAM. They have talented operations to take these infra complexities.

What does this mean to a small team that would launch a ZKRU or ZK layer3 with ZK stack? What if an indie developer would like to build a ZK Dapps? How do they buy these high-end servers and correctly operate them?

Nowadays, starting a ZKRU is not hard. You can use the ZK stack and deploy a new ZKRU following the instructions in the documentation. The hardest part is to get the high-end infra work. Taking care of a cluster of servers is much harder than taking care of our daily laptop.

Plus hardware acceleration is not out-of-box, Depending on the ZK proof system they are using, teams will need different configurations for their server setup.

Ensuring high availability is also a hard topic. What if tons of people start to mint ordinals in your ZKRU and you got 1000x throughput? Even an experienced team like Arbitrum has been down for several hours because of surging ordinal transactions.

Generating tons of ZK proof needs high-end servers. Setting up and taking care of clusters of high-end servers would be a heavy burden for small and medium teams. To better help teams adopt ZK smoothly and quickly, emerging projects try to help these teams take care of all computation infra complexity.

Proof markets and proof networks are two main approaches. The proof market is like an open marketplace. To generate a proof, users need to find the counterparty who is willing to sell the proofs at a certain price. The proof network is like traditional could service. Developers submit their circuits and input. The centralized load balance assigns internal servers in the proof network to generate proofs for users.

The proof market is one of the popular approaches for ZK proof infra. The proof market is an open market where buyers and sellers trade ZK Proof. The ZK proof market team does not need to take care of ZK proof hardware or own high-end servers. The ZK proof market teams focus on ZK proof trade and validation mechanisms to onboard third-party hardware providers.

The proof market is a more open approach. It welcomes third-party hardware providers. Buyers buy ZK proof at USD price as long as there is a seller for this kind of proof. When validating the proof, everyone in the market does not need to reach a consensus. Only the market operator takes the responsibility to perform the validation. In the proof market, zkDapp developers submit a ZK proof orders including price, generation time, timeout, and public input. Then third-party hardware providers will take the order and generate the proof.

The economic structure for the proof market is straightforward. Proof producers need some stake. If they produce wrong proof or do not provide proof before DDL, their stake will be slashed. With more stake, proof producers would be able to generate several proofs at the same time.

The main players in the proof market industry are =nil and marlin.

The proof market has sellers and buyers. Buyers are dApp developers. They pay sellers to generate proof. There are lots of factors affecting the proof price. The main factors would be circuit sizes, proof system, generation time, and input size.

Here is the workflow for =nil proof market :

1. A proof requester sends a request with a desired price c_r to the market.

2. Proof Market locks c_r tokens from the buyer's account.

3. Proof producers send proposals to the market with a price c_p <= c_r.

4. Proof Market matches the request with the proposal of the proof producer.

5. The proof producer generates a proof and sends it to the market.

6. Proof Market verifies proof and pays c_r - commission tokens to the producer.

7. The proof requester takes their proof and uses it.

The market design provides a trading-like experience. The proof generation price changes in real-time.

Here is a product screenshot for =nil proof market.

Currently, Proof Market supports a limited number of statements, with Mina statement proof being the most active one. Specifically, Proof Market accepts circuits based on their zkLLVM compiler and Placeholder proof system.

Gevulot tries to bring decentralization into the Proof marketplace. Gevulot operates as a permissionless and programmable layer 1 blockchain designed for the proof marketplace. The layer1 blockchain handles the proof request distribution, proof validation, and incentive distribution. The network of provers leverages lightweight unikernels for high performance. Gevulot uses a Verifiable Random Function (VRF) to distribute proof workloads among a small group of provers, ensuring liveness.

Users can deploy programs seamlessly, and fees are predictable, with users setting a maximum fee based on the number of cycles needed for program execution.

Provers are rewarded both by the Gevulot network and user fees, encouraging efficient and competitive proof generation. The fastest prover will get the most network rewards. User fees will be shared equally with all nodes finishing the proofs.

Gevulot supports a variety of programming languages, including C, C++, Go, Java, Node.js, Python, Rust, Ruby, PHP, and more, for program deployment because Gevulot’s underlying VM Nanos supports x86_64 Linux ELF binaries.

Gevulot is a general-purpose computation platform supporting different languages and proof systems. Gevulots relies on Nanos unikernel to make sure provers can easily run on different machines. All provers need to be compiled into a single unikernel image.

The proof network is a more developer experience-friendly approach. It operates like a Web2 cloud service provider. Developers send the payload through REST API and the proof network will return the proof to you. Developers don't need to care about fluctuating prices and the counterparty who will generate the proof.

Risc Zero leveraging their zkVM launches Bonsai. With the power of zkVM, users can let Bonsai generate all kinds of statements. For example, based on Bonsai and Risc0 VM, Zeth generates the proof for Ethereum blocks.

Recently Succinct also launched their new products. Instead of giving circuits to REST API, Succinct offers a more cloud-function approach.

Here is the user workflow:

1. Connect to GitHub account and deploy circuits

2. Call the API with circuit input via REST or smart contracts

3. Query the result through REST API or smart contracts

Compared to BONSAI, Succinct has the following advantages in developer experience

• Easier to manage the circuit codebase

• No need to send circuits every time

• One-click to deploy smart contracts for on-chain proof generation and validation

• Explore trending ZK proof

• Dashboard to view proof generation status

• Support rustx, gnark, circom, plonky2

The proof market offers greater pricing flexibility for both buyers and sellers of proofs. It invites all hardware providers to participate, which helps to reduce costs for buyers. However, it's worth noting that the savings may vary between individuals and enterprises. Typically, centralized services such as a proof network may offer free services to individuals while charging enterprises a premium, but offering access to VIP customer support. For example, enterprises can reserve some computation power in advance on proof network if enterprises plan to launch new events or features. A decentralized marketplace might present more balanced and competitive pricing across the board.

In today’s market, products based on proof networks seem to provide a much smoother experience to developers. It takes care of all proof generation work and supports major proof systems without introducing any new complex concepts. It offers a consistent user experience. Theoretically, it provides fast proof generation since order matching in the proof market also takes time. If you are familiar with cloud computation, the proof network is more like a stateless cloud function.

We have =nil foundation and Gevulot working on the proof market. Succinct and Risc0 on the proof network. Hardware companies like Ulvetanna and Cystic also make great contributions to increased ZK proof performance on GPU and developed next-generation ZK dedicated chips.

The proof market is relatively easy to bootstrap. For ZK infra projects, proof market design can onboard more hardware providers. With its decentralization design, they can easily scale the network to meet the computation requirements in the future.

In the future, we envision a blend of a proof network and proof market design. The goal is to offer developers a seamless experience, while also integrating a proof market as the backend to facilitate the onboarding of additional computation resources. This is the direction Succinct plans to pursue in the near future. We also see similar transitions in other markets, like Infura. Infura has their own servers but it also plans to onboard permissioned parties infra provider.

Using cloud ZK Infra brings lots of advantages for ZK dApps developers:

• No server management is necessary

• Developers are only charged for the computation resources they use, reducing cost

• Serverless architectures are inherently scalable

• Quick deployments and updates are possible

• Code can run closer to the end user, decreasing latency

Besides these advantages, there are some common drawbacks when moving to a cloud zk infra:

• Testing and debugging become more challenging

• Cloud computing introduces new security concerns

• Cloud architectures are not built for consistent usage, storage-heavy processes

• Performance may be affected

• Vendor lock-in is a risk

• Expensive. We see lots of medium-sized companies moving away from the cloud to save costs.

Aside from these common issues, there are also specific problems in ZK and Web3 areas.

Privacy apps would find it hard to use these cloud ZK Infra since apps would also need to send private input to the cloud ZK Infra. This would destroy the data confidentiality. For privacy applications, generating proof locally or using FHE would be a better solution.

Also, it would be hard for cloud ZK infra to support all kinds of proving systems. Currently, both the proving market from =nil; foundation and Bonsei proof network only support their own ZK stacks. Succinct supports more proving systems. It is also hard for these cloud ZK infra to support interactive ZK-proof schemes.

Using cloud ZK infra weakens the token utility of ZK Dapps. Infra is one of the main utilities of dApps. Users pay fees with native tokens to computation providers in the dApps. Users can also stake tokens to participate in consensus and get some incentivizations. The dApps have the absolute power to design these rules. Relying on cloud zk infra, zk dApps need to pay real money, not tokens to their computation providers.

We believe developers who want to decrease their go-to-market time and build lightweight, flexible applications that can be expanded or updated quickly may benefit greatly from these cloud ZK infra.

Cloud ZK infra will reduce costs for applications that see inconsistent usage, with peak periods alternating with times of little to no traffic. For such applications, purchasing a server or a block of servers that are constantly running and always available, even when unused, maybe a waste of resources. A cloud setup will respond instantly when needed and will not incur costs when at rest.

From learning Web2 cloud industry, we found that companies that have the greatest computation needs can have the leading cloud infra business. They can take advantage of scalability, cost, teams, and innovative products.

This would also work on shared ZK infra. We believe projects that have the most proof generation demands have the potential to own one of the most successful ZK cloud infra businesses.

For these projects generating lots of ZK proof internally, they have already got lots of infra, optimizers and specialized teams ready. By sharing provers across applications, they also maximize hardware utilization; provers can be repurposed whenever one application does not immediately need proof to be generated.

These big projects all somehow have their own proof system. Third-party proof infrastructure often struggles to optimize the various proof systems that different large projects employ. Providing fast and easy-to-use cloud provers, big projects can effectively expand their proving systems ecosystem.

For ZKRU, cloud ZK infra can boost the usage of its forks. Spin up a new layer2 or layer3 based on these ZKRU is not that hard, taking care of the ZK infra would be costly. Providing out-of-box and flexible cloud provers can help onboard more developers. Currently, most developers use OPRU SDKs to build new layer2 or layer3 since the corresponding infra is easy to manage.

If not building their own ZK infra, these giant ZK projects need to pay a lot to third-party computation providers. They also will be limited on development speed since they cannot always customize their infra to further increase performance and reduce proof cost.

Besides ZKRU and Layer1, we have seen more emerging ZK applications recently. These all have vast demands on proof generations.

ZK Coprocessors enables smart contract developers to get past blockchain state trustlessly. ZK coprocessors generate ZK proof for these past blockchain states. It may be the more secure and trustless alternative for the graph.

ZK Attestation helps users bring off-chain data or identity to the blockchain. After verifying the data off-chain, attesters will generate a ZK proof for it and put it on the blockchain.

ZKML makes on-chain inference possible. Computation providers do the ML off-chain, generate a ZK proof for it, and put the proof on the blockchain.

ZK bridge is a more secure version of cross-chain bridges. It generates storage proof or even consensus proof for the source chain and puts it on the destination chain. It may substitute current cross-chain bridges.

Decentralization is the most popular narrative in the blockchain industry. Decentralization brings lots of benefits:

• Security

• Censorship-resistant

• Privacy

ZK is different from other general computations. ZK has security in nature. Anyone can easily and quickly verify the proof to make sure provers is honest. Decentralization is not the prerequisite for security in ZK space.

ZK proofs focus on intricate, low-level details and are structured as circuits. While the content within these circuits is notably difficult to censor, censorship can still be effectively implemented by targeting the requestors.

Privacy would be a problem for proof networks because users send private input to the proof network. The ideal solution would be to generate proof locally to prevent any data leakage. This would pose challenges to local performance. Other solutions would be a new ZK-MPC protocol or generating proofs in TEE. A decentralized proof network can’t bring more privacy.

Besides the narrative, censorship resistance would be the major reason to build a decentralized proof network. ZK technology is still in its infancy, and so far, we haven't observed any censorship in this field. However, the main challenge hindering ZK development is performance. Introducing a decentralized proof network might lead to increased computational demands for generating proofs.

ZK applications are growing rapidly and are applied everywhere. We anticipate seeing ZK integrated into different tech stacks. We have already seen ZK layer1, ZK layer2, ZKML, ZKVM, ZK-Email. Developers are also building ZK Oracle, ZK data feed, and ZK database. We are on the road of ZK everything. The computation overhead brought by ZK forces developers to deploy their circuits on high-end servers. Thus we expected growing demand for cloud ZK proof infra to take developers outside these infra operation complexities. Our insights in this area are:

• Proof markets and proof networks are two main approaches to get ZK dApp developers outside of infra complexities.

• We anticipated a hybrid approach that combines both proof network and proof market mechanisms

• Not all ZK Dapp developers are suitable for cloud ZK infra. Medium-sized projects with consistent traffic can self-host servers to cut costs.

• The leaders of cloud ZK infra would be projects that have tons of ZK-proof generation demands, like leading ZKRU. They got economic incentives to do this business.

• Decentralization is the main narrative in the crypto space because decentralization brings characteristics like privacy, censorship resistance, and security. ZK Proof already has some of these characteristics. The current selling point for a decentralized proof marketplace is censorship resistance.

• The popularity of cloud ZK proof infra is closely tied to the quantity of ZK dApps currently in the market. While some projects initially highlight their cloud ZK proof infra as a key feature, many eventually shift their focus to different new narratives.

• Support more languages

• Lower fee, lower memory consumption

• Custom pre-compilers

• Interoperability with EVM

All these features are brought by the integration of WASM. WASM has lots of advantages and is widely used in the cloud native scenario. We will expand the story of WASM in the later sections.

Arbitrum is not the first one to bring WASM on-chain. Before Arbitrum, Polkadot enabled users to write WASM smart contracts. It provides two languages to write WASM smart contracts, one assembly scripts like embedding DSL and another is Rust-like language ink!.

Cosmos also employs CosmWasm as its smart contract runtime. Developer's can use Rust to write smart contracts.

Before diving deep into why blockchain ❤ WASM, let's see how Cosmos and Polkadot explains their choice to WASM.

Cosmos claims WASM can bring the following benefits:

• Compatible with Rust libraries

• Diverse dev community

• Security, prevent reentrancy attacks

• Easy test

• High performance

Polkadot’s WASM runtime has the following features:

• High performance

• Interoperability with EVM

• Platform agnostic

• Small size

• Support Rust and Assembly Script(Typescript style)

There are some advantages shared across Polkadot, Cosmos and Arbitrum brought by WASM, but there is something unique for Arbitrum. We will cover more details about Arbitrum and Cosmos in the last part.

To understand why blockchain x WASM, we need to understand what is WASM and the initiative behind WASM.

WebAssembly (WASM) is a binary format that allows code to run at near-native speed in web browsers. It's a compilation target for languages like C and Rust, designed to be fast, efficient, and secure. WASM bridges the gap between web and system-level programming, enhancing web performance and capabilities.

WASM get name Web because it can run in JS, commonly browser environment. In JS, developers can access full WASM API. WASM also got full Web API supports. In WASM, developers can control the Web behavior.

WASM is designed with the principle of writing once and running anywhere.

Back in 2016, lots of programs released new functions through Domain Specific Language(DSL). Making a DSL needs to make tradeoff between maintenance, efficiency and safety. However people are looking for a new way to deliver new functions to countless servers which needs maintenance, efficiency and safety.

They examine different solutions from top to bottom. Here are people’s concerns about these solutions:

• System Virtual Machines

  • Too much overhead for spinning up/down frequently

  • Lack visibility into code for ensuring safety

  • Too abstracted/high level for the performance needs

• Containers

  • Lack of visibility into code for ensuring safety

  • Too high level/abstracted for performance needs

  • much overhead for spinning up/down frequently

• Language-level virtual machine

  • Frequent VM modifications required for safety

  • Overhead of embedding VMs like V8

  • Slow to adapt new languages to the VM's security model

  • Still high level

• Instruction set architectures (ISAs)

  • Very difficult to modify ISA code for sandboxing efficiently

  • Prior project at Google moved away from it to WASM

  • Lacked mature implementations to use

This is the background for WASM to be true. People start to develop WASM compiler till 2018. WASM developers expand the idea of write once and run anywhere. They would like to run on different architectures, run in servers and embedded hardware, even other languages. They don’t want to make another Java, which sacrifices safety.

In 2019, the component model was created to wrap WASM modules and raise their interfaces to a higher level, enabling cross-language interoperability between components. For example, this allowed them to write an HTTP library once and share it across languages. The component model solved long-standing problems in a novel way.

Till know, WASM has lots of cool features. WASM now is heavily used in the cloud native scenario. Blockchain somehow is also one use case under cloud native. WASM has following advantages:

• High performance

• Low binary size

• Portability: WASM provides portability at the instruction set level, allowing the same bytecode to run across any WASM runtime.

• Support C/C++, Rust, AssemblyScript, C#, Dart, F#, Go, Kotlin, Swift. D, ascal, Zig, Grain

• Run in JS engine

• Sandbox: WASM provides a much stronger sandbox by default, with limitations on memory, CPU, etc. to prevent access outside of its sandbox.

• WASM has very fast startup, often milliseconds or less.

The WASM community is still working hard to bring more integration and cross-language performance.

After thinking about the initiative of WASM and WASM applications on other blockchains, let’s go back and think about Arbitrum Stylus’s limitation.

1. The developer compiles their smart contract to WASM using an off-the-shelf WASM compiler like Clang or Rustc.

2. The WASM bytecode is uploaded to the Arbitrum chain in compressed form.

3. The contract owner calls the compileProgram method of the ArbWasm precompile, which instruments the WASM for security, meters it for gas costs, and compiles it to native code optimized for the validator's hardware.

4. When the contract is called, it runs on a WASM runtime like Wasmer much faster than the EVM, saving gas costs.

The third steps looks extra, but it is necessary to build for performance and security reason. Compile WASM code to native machine code can speed up the execution. Adding extra compilation step can also avoid compile bomb.

A "compile bomb" is a type of malicious code that is designed to consume excessive resources during the compilation process, causing the compiler to crash or hang. It is a form of denial-of-service attack that can be used to disrupt software development processes.

Stylus can help Arbitrum to expand their dev community to C++ and Rust while it still cannot reach the most popular dev community nowadays. It opens up the door for smart contracts executed in the browser environment, but JS and Python is still not supported.

There are early stage projects bring Python and JS to WASM, but it is not ready for massive adoptions because of garbage collection objects implementation and performance issue.

Stylus current supports C/C++ and Rust SDK. It works well with these languages tools. Developers can also bring some third party libraries, like some native cryptography implementation while building smart contracts. The only limit for these is gas cost.

The Rust SDK is still in the early stage. There are some missing features for Rust and C SDK. C SDK does not support ABI export function. Modifiers are not supported in both SDK.

Local Stylus test environment is not supported yet, but developers can directly run test in SDKs. To run smart contracts in Stylus, testnet is the only way. Smart contract verification is not supported by the testnet yet.

People is bringing differet ERC token and Uniswap V2 to Stylus.

Use DSL, embedding DSL or general programming language is a hard choice. Developers need to make tradeoff between building close to the metal for control or higher level abstractions that are easier to use but limit flexibility.

Building a brand new DSL also takes time to develop toolchains and ecosystem. eDSL is a sublanguage of a general programming language, sharing same semantics and syntax. With eDSL, it can leverage existing language and tools, lower learning curve compared learning a new DSL, good Interoperability between DSL and general purpose code. For example, for reaching the most developers, making a JS, Python eDSL make sense. General programming languages require developers to use SDK to make development. This introduces extra tooling, more verbosity, less expressiveness and length API call and object operations.

Picking a right language and make an eDSL may be a right mix. It attracts people from popular dev community and provide easy-to-use tools. From the data below, we see the top crypto developer community is still Ethereum. Polkadot, Cosmos and Solana, which use Rust for smart contract also attract well amount of people. They also have a really fast growing speed on total developers

WASM can greatly increase the execution speed and decrease the bundle size. Although Stylus is not on mainnet yet, we can see benchmark on other network as reference.

The execution time is shorten 4-8x. The compiled size is reduced by 2x.

There is currently a limit on the size of Stylus contracts, around 128KB uncompressed. It will be difficult to port very large smart contracts from other languages like Solidity. You can find in the Stylus codebase.

// arbos/programs/programs.go const MaxWasmSize = 128 * 1024 const initialFreePages = 2 const initialPageGas = 1000 const initialPageRamp = 620674314 // targets 8MB costing 32 million gas, minus the linear term const initialPageLimit = 128 // reject wasms with memories larger than 8MB const initialInkPrice = 10000 // 1 evm gas buys 10k ink const initialCallScalar = 8

Notice that WASM has some overhead on spinning on and off. If you are coding something really light, EVM may be cheaper than WASM.

EVM and WASM shares the same storage slots and state tire. Stylus has interoperability with EVM because there are EVM API implemented in WASM. This is done through the popular Host I/O mode in WASM. Here is a full supported list for EVM API in WASM. It looks like the interoperability is fully supported.

read_args write_result storage_load_bytes32 storage_store_bytes32 call_contract delegate_call_contract static_call_contract do_call create1 create2 do_create read_return_data return_data_size emit_log account_balance account_codehash evm_gas_left evm_ink_left block_basefee block_coinbase block_gas_limit block_number block_timestamp chainid contract_address msg_reentrant msg_sender msg_value native_keccak256 tx_gas_price tx_ink_price tx_prigin memoery_grow console_log_text console_log console_tee

This one is more exciting. Noone has done this before. We can bring more crypto primitives on-chain with a much lower execution cost. For on-chain ML, we can bring tensor computation as precompiles to lower the inference cost. However, I do not see any relevant code about custom precompiles. We see the precompiles for the EVM part, but is not hot swappable.

I believe these part are stilling implemented with the power of WASM. EVM can call functions written in WASM which can be compiled down to machine code.

Unlike CosmWasm which uses an actor model to provide contract call and does not provide reentrant functionality, Stylus Rust SDK set reentry as a feature flag and it is default set as off. Developers can manually enable the reentry functionality.

Introducing reentrancy with the default feature flags on will change the API a bit, since developers have to be careful to flush the storage cache when making calls, among other safety considerations.

WASM is an emerging technology gaining traction in the cloud-native space. Numerous blockchains are integrating WASM for their smart contract runtimes. While Arbitrum is not the first to do so, it could be the most significant. WASM cannot completely change the blockchain world and substitute EVM, but WASM has the potential to enhance Arbitrum's competitiveness against upcoming zk-rollups. I like how Arbitrum call this EVM+. EVM is the floor for smart contract runtime and WASM can bring some extra power for Arbitrum.

The Nexus of Trust and Intelligence: Transforming Industries through AI + Blockchain Synergy

Blockchain's reputation for sluggish performance and high computational costs has been a roadblock for innovation. Layer 2 technologies have shattered this barrier, offering 100x cost reduction while preserving decentralization and trust. The field is now ripe for computational-intensive activities, making way for an amalgamation of AI and blockchain.

Poor user experience in the blockchain space is often attributed to its lack of intelligence. However, reduced computation costs have paved the way for integrating Machine Learning algorithms on-chain, thereby elevating Dapps from mere transactional entities to intelligent interfaces.

From rudimentary on-chain algorithms to advanced AI capabilities like AIGC, Dapps will soon be on par with traditional applications. This integration will enable Dapps to understand users' intent, automate complex tasks, and ultimately, make the entire on-chain experience seamless and efficient.

Conversely, blockchain brings privacy and trust to AI. Zero-Knowledge Proofs (ZK) and other cryptographic techniques are being employed to ensure transparency in data collection, training, and inference. This will mitigate public distrust and privacy concerns related to AI.

The integration of AI can dramatically improve user experience on blockchain platforms. AI algorithms can guide users through complex tasks, recommend related Dapps, and serve as an effective co-pilot in the blockchain world. Smart contracts, enhanced by AI-driven firewalls, add an extra layer of security, making the Web3 world more accessible and secure for novices and experts alike.

Blockchain provides the ideal framework for a creator economy focused on AI models, data, and even AI-generated content. Technologies such as tokens, NFTs, and decentralized markets enable a secure exchange of these high-value assets. Projects like Giza, NFTPrompt, and SingularityNET are trailblazing in this direction.

Utilizing blockchain's decentralized nature, AI training and inference can be distributed across multiple nodes, significantly reducing costs. This is akin to decentralized storage solutions like Filecoin but for computational tasks. Initiatives like Gensyn, Together, and Bittensor are harnessing decentralized networks for cost-efficient AI operations.

Technologies like Zero-Knowledge Machine Learning (ZKML) and Fully Homomorphic Encryption (FHE) can be integrated into the AI lifecycle to ensure data privacy. These technologies allow for encrypted data inputs, model privacy, and even encrypted outputs, thereby solving a multitude of privacy issues.

AI can provide real-time, transparent, and dynamic risk management in decentralized finance (DeFi). Traditional risk algorithms are either too simplistic or lack transparency when executed off-chain. With AI integrated directly on-chain, protocols like Yearn and Compound can leverage complex algorithms for risk management while maintaining full transparency. Besides that, we can also bring more complex AI powered strategies on-chain. Modulus Labs once has made a demo about this.

AI has the potential to revolutionize on-chain gaming by reducing development costs and enhancing gameplay. AI can automate various aspects of game development including planning, sound design, and testing. Furthermore, AI can bring dynamic and intelligent environments to on-chain games, with features like auto-generated levels and smart enemies. Projects like GiroGiro are pioneering in this space.

By addressing these challenges, the AI and blockchain synergy opens up new horizons for innovation, making a compelling case for investment and development in this converging ecosystem.

This is not a mere speculative future but a transformative era that is unfolding over a span of 10 to 20 years. The integration of AI and blockchain is already reshaping industries, enhancing user experiences, and solving pressing issues like privacy and trust.

Our conviction in this synergistic relationship between AI and blockchain is steadfast. We have been investing in groundbreaking companies in this space, and the potential for impact is monumental. We're beyond excited to be part of this new industrial revolution, one that transforms, empowers, and solves some of our most significant challenges.

Editor: Philip

• We break up PoS staking into three parts: node providers, liquid staking pools, finance derivatives

• The big players have already dominated the market

• New players can enter the market by supporting long-tail assets, and better UX

• There are the following opportunities:

  • Data analysis tool

  • Toolkits for bootstrapping your node provider business

  • Long-term fix rate staking derivatives

  • Better tokenomics design

Ethereum is turning from Proof-of-Work (PoW) to Proof-of-Stake (PoS) for higher transactions-per-second (TPS) and efficiency. Most of the major blockchains that support smart contracts use PoS, such as Solana, Cardano and Avalanche.

Source: Staking Ecosystem Report 2021

Most blockchains turn to PoS because PoS empower them to embrace high performance, faster finality, environmental sustainability, scalability, low cost of security, and flexibility in architecture compared to PoW approach.

Source: Staking Ecosystem Report 2021

PoS gives users a new way to earn stable yields. Delegate the native assets to the staking node, users can earn 10%-20% yields. This is like the treasury bond of countries. It is stable and low-risk and it is much more profitable than stablecoin farming on popular DEXs and lending platforms.

Hopefully, these crypto treasuries can help investors overcome fiat currency inflation. The following chart illustrates the inflation rate around the world. The fiat currency inflation is around 3% to 6%.

Source: Staking Ecosystem Report 2021

Different blockchains have different staking mechanisms, differing in withdrawal period and slashing rules.

Ethereum is turning from PoW to PoS for sustainability and scalability.

Source: Delphi Digital

Ethereum describes staking on Ethereum as “Staking is the act of depositing 32 ETH to activate validator software. As a validator, you’ll be responsible for storing data, processing transactions, and adding new blocks to the blockchain. This will keep Ethereum secure for everyone and earn you new ETH in the process. This process, known as proof-of-stake, is being introduced by the Beacon Chain.”

In short, the user needs to stake 32 ETH and run a validator node to become a staker. Users can withdraw staked ETH at least after the merge.

Currently, users will get around 4.2% APR, not deducting the server cost. After the merge, Kraken expects the APR to increase to 8.5% - 11.5% in the report “The State of Staking Q1 2022”.

Source: The State of Staking Q1 2022

The Ethereum node doesn’t require high-end hardware. The server cost is relatively low. The recommended specifications are:

• 4+ cores CPU

• 16 GB+ RAM

• SSD with at least 500 GB of free space

• 25+ MBit/s bandwidth

Based on the node type, the disk space requirements varies from 400GB to 6TB.

In the ETH2 network, a proposer mints the new block, and the attester vote for this block to be part of the canonical chain.

Slashing means the validator violates rules and is forced to exit. There are three slashing conditions:

• As a proposer, the node sign more than one beacon block for one slot

• As an attester, the node signs more than one attestation on the same target

• As an attester, the node sign an attestation conflict with the history

If any of these behaviors is caught, the node is forced to exit the beacon chain around 36 days in the future. The penalties will continue to incur for around 36 days until the node can exit. The penalty number varies based on the network condition.

Slashing forces validators to exit the network, but penalties don’t. Penalties conditions can be put into the following categories:

• Attester penalties

• Inactive leak penalty

There are a total of 13,310,531 ETH staked and 396,982 total validators. The following charts illustrate the ETH 2.0 staking rate and staked ETH.

Source: CryptoQuant

Source: CryptoQuant

The inflow chart reveals some peak inflow time points. Some big inflow happened in Dec. 2020 and March 2022.

Source: CryptoQuant

Kraken is the 1st staker in ETH 2.0. CEXs still has an advantage in the market. They can turn their existing users into ETH 2.0 stakers.

Source: Ethereum 2.0 Beacon Chain (Phase 0) Block Chain Explorer - Staking Pools Services Overview - beaconcha.in - 2022

For liquid staking, Lido dominates the market. Liquid staking derivatives help user liquid their staking assets and improve capital efficiency.

Source: Delphi Digital

Lots of smart-contract-enabled chains use PoS considering TPS and sustainability.

They have different rules. Some chains allow users to delegate their staking to active validators. These validators run the node and charge commission fees from delegation staking. To withdraw their staking, users need to wait a period of time before undelegating.

Currently, Ethereum 2.0 has the lowest staking ratio.

Source: Staking Rewards

Running own staking nodes has lots of risks and needs a large amount of money to start. It is hard for individuals to maintain a 24/7 online server and not do anything wrong causing penalties. To help individuals easier to stake and earn rewards, there appears staking-as-a-service. Node providers will take care of the infrastructure and users only need to stake their funds.

Node providers provide node operation services. They provide service to individuals and liquid staking derivatives. To individuals, node providers charge a monthly node operation fee or commission fee. To liquid staking derivatives, node providers usually get a percentage of the staking rewards. Lido explains how they choose node operators.

There are lots of node providers in the market. They differ in the following aspects:

• Fee

• Supporting assets

• Reliability and safety

Source: Staking Rewards

Big players have already established large user groups, good reputations, and safe operation records. It is hard for new players to take a large market share. Big market players believe the opportunities for small players are the following:

• Better UX

• Supporting long-tailed assets

• Providing services besides staking, like ecosystem updates, simple financial engineer tools, information websites, and data analysis tools

Though small players are hard to compete with large players, large players do face some challenges:

• Risk of centralization

• Compliance

• Security and operation risk

Decentralization is the key to a network. If several node providers have a major stake in the network, these node providers are a stratum for cartelization. @djrtwo questions this in his passage “The Risks of LSD”.

To build a decentralized and permissionless product, compliance is a big problem. Stake.fish believes that “due to how staking looks like fixed income in some sense, this could invite regulators to consider validators closer to financial entities than miners. If this occurs, then there would be no way for validators to stay compliant without becoming a fully licensed custodian and guarding delegator access (which again, may technically be impossible to enforce)” in the “2021 staking ecosystem report”.

Node operators put safety first because the safety incident can cause asset loss. In Jan 2021, ETH2 validators got slashed due to a bug. Here is the recent slashing history for ETH2 validators.

Source: beaconcha.in

Node providers are trying to increase the stability of the infrastructure with new tech like SSV. The secret shared validator network is a tech that can reach active-active redundancy. All validators in the network actively produce new blocks. The mechanism is like a multi-sig wallet.

Source: OBOL

Other techs used for slashing prevention are the local slashing protection database which records messages causing slashing, and remote slasher which records all attestations and blocks received.

From the Staking Rewards survey, users do care more about reputation than cost, and node providers are trying to improve their reliability in order to build their reputations.

Source: Stake Rewards

After choosing the best staking node providers, the next problem is capital efficiency. Users need to lock assets in the staking node but only yield 10% annually. In the crypto world, there are opportunities everywhere. The opportunity cost of locking assets in the staking pool is huge. Thus users are trying to increase capital efficiency. A liquid staking pool helps users get their liquidity almost instantly.

The liquid staking pool has two functions:

• Lower the staking requirement for users

• Greatly increase the liquidity of staked assets

To increase the liquidity of staked assets, the staking pool mint a new token for users. For example, after staking ETH in Lido, Lido mints stETH for users. Users can exchange stETH with ETH on DEX. Below is the pricing chart for stETH.

Source: Dex Screener

stETH is like a bond. 1 stETH can redeem 1 ETH in the unpredictable future. We are not sure when Ethereum will release staked assets in the staking node because releasing the staked assets needs a hard fork update after the ETH2.0 merge.

The next few charts show that Lido dominates the ETH staking market and secures a large portion of the market share.

Source: Delphi Digital

Source: Delphi Digital

However, Marinade dominates the Solana liquid staking market instead of Lido.

Source: Delphi Digital

Here is a fee breakup for liquid staking on Solana.

Source: Delphi Digital

Besides fee and reputation, utility is another major point. More partnerships mean deeper liquidity for liquid assets in DEXs and lending platforms. Marinade has the most partnership with DeFi projects.

Source: Delphi Digital

Source: Delphi Digital

Most DeFi users are APY addicted. Is there any way to push our staking yields, but still enjoy a low risk? Yes. Leverage farming can do this.

Most leveraged yield farms use 2x - 3x leverages and offer around 7% APY. They do have liquidation risks.

Basically, they deposit stETH on Aave and borrow WETH through Aave. Then they swap WETH for more stETH and repeat the steps above.

Another interesting project is SR20 by Staking Rewards. SR20 is an index containing the top 20 PoS assets weighted by total staked value. The index also accrues staking rewards on a continuous basis. The following charts demonstrate the allocation:

Source: Staking Rewards

The current index price is $304.41 and the reward rate is 6.54%. The staking returns YOY is 9.44%. Below is the price chart of SR20.

Source: Staking Rewards

To avoid slashing risk, there are also insurance products for validators. Lido partnered with Unslashed Finance to cover approximately $200M worth of staked ether from slashing in Feb 2021.

Source: Lido Medium

The ecosystem of staking is established. Big players have already gained a strong position in the market. The total staking market will continue to grow because the ETH staking ratio is still low compared to other PoS assets. We are optimistic about the future of the staking market.

Staking assets is similar to buying treasury. Institutions and big whales are willing to buy these assets. One big difference between treasury and staking is that staking reward is not fixed. Staking rewards vary upon network conditions. To make the APR more stable, we anticipate fixed APR and long-term staking assets.

Source: Staking Rewards

Current tokenomics for liquid staking protocols cannot catch the true value. With rising revenue and TVL, the token price drops. We need a better tokenomics design to support the staking protocol. Currently, the protocol revenue does not share with the token holder. This makes the token a pure governance token.

Two opportunities for new players are better UX and long-tail assets support. Spinning up a node is easy with the help of an official document. The hard part is operation and customer management. To better support these new players, some toolkits are necessary. This is similar to the VPN market. Lost of small players entering the market with lower fees and better UX.

A specific data analysis tool is also necessary. For stakers, they care about the liveness history, staked ratio history, slashing history, etc. These data are different from the common dataset we use. The common dataset we use focuses on transactions. To better support stakers, a new data analysis tool is necessary.

• Rewards and Penalties on Ethereum 2.0 [Phase 0] | ConsenSys

• The Beacon Chain Ethereum 2.0 explainer you need to read first | ethos.dev

• Rewards and Penalties - Ethereum 2.0 Knowledge Base (beaconcha.in)

• The Risks of LSD - HackMD (ethereum.org)

• State of Staking (staked.us)

• 2021 Staking Ecosystem Report (stakingrewards.com)

• Eth2 Slashing Prevention Tips. This post regards information on… | by Raul Jordan | Prysmatic Labs | Medium

• Lido Dominates Liquid Staking - Delphi Digital

• Managing Expectations Heading Into "The Merge" - Delphi Digital

• The Race To Become Solana's Liquid Staking Winner - Delphi Digital

Special thanks to Dominator008@Celer, Outprog.eth@everFinance, Zhixiong Pan.

The multichain ecosystem is booming. cross-chain bridges are the base for the multichain ecosystem. There are lots of opportunities in the cross-chain market. In this report, we will explore the potential of the cross-chain market.

There are generally three kinds of technique approaches:

• Local Verification

• External Verification

• Native Verification

Cross-chain bridges have four functions:

• Asset-specific

• Chain-specific

• Application-specific

• Generalized

When reviewing a bridge, we care about the following characteristics:

• Capital efficiency

• Connectivity

• Security

  • Trustless

  • Insured

  • Trusted

• Speed

• Statefulness

There are lots of players in the cross-chain bridge markets. New players face fierce competition, security risks, and need to collect enough TVL. Following are opportunities in this area:

• Bridges between layer2s, bridges between layer2 and layer1

• Bridges with new tokenomics

• Bridge SDK

• Bridge Aggregator

• ZK Bridge

We are entering a multichain era. The Ethereum dominance decreases. Alt chains take more market dominance. After Ethereum, there are Solana, Avalanche, Polkadot, Terra... These chains are becoming mature and have a complete ecosystem. There are over 115 active blockchains (data from Layer1 Blockchain Protocol). The below chart describes the market dominance of different chains.

Source: https://coin360.com/

Blockchain applications are powerful because of their composability. After entering the multichain era, developers are exploring the possibilities of cross chains.

Developers start with the simplest case, transferring assets between different chains. CEX is the first tool to help people move assets between chains, but this is not an open and crypto native solution.

Now cross-chain bridges have iterated over several generations. Lots of competitors are polishing their products in this area. There are over 80 different bridge projects (data from DecentralizedFinance).

Source: DefiLlama - DeFi Dashboard

The key idea of cross-chain bridges is passing some information from the source chain to the destination chain. It is a simple idea, but how to make it cheap, secure, and extensible is a big problem.

When stepping into cross-chain bridge protocol design, the two main issues for developers are:

1. How to effectively verify the cross-chain transactions?

2. How to judge the data consistency on target and destination chains?

For these two questions, developers have different answers and we will introduce several mainstream solutions.

Based on how developers verify cross-chain transactions, there are three main solutions:

• Local Verification

• External Verification

• Native Verification

In the cross-chain protocol, there are mainly four steps:

1. Monitor: Monitor the state and smart contract function call in the source chain.

2. Consensus (Optional): Relay nodes reach a consensus on the correctness of the relaying message.

3. Signing: Relay nodes sign the message.

4. Relay: Pass the message from the source chain to the destination chain.

Hash Time Lock Contract (HTCL) is the most common method for local verification. The is one of the oldest solutions and the easiest one to implement.

Suppose Alice wants to send assets cross-chain to Bob. Alice generates a random number Ka and Bob generates a random number Kb. Alice sends hash(Ka) to Bob and Bob sends hash(Kb) to Alice. They use the received hash to lock their assets with an expiration time. After the lock expires, Alice and Bob can use the random number to unblock the assets.

HTCL is easy to implement, supports the atomic transaction, and, most important, it is trustless. It does have a few limitations. HTCL faces scalability issues because it is P2P. In real-life, users will be hard to transfer a large number of tokens to another chain, because the user cannot find his/her counterparty. Another problem is that it cannot support complex use cases like cross-chain messages.

The cross-chain protocol relies on external relayers to pass messages from the source chain to the destination chain. To increase the decentralization, robustness, and safety, there is a relayer network to deliver the transactions. After reaching the consensus in the relayer network, the message will be passed to the destination chain. The whole relayer network performs like a multi-sig wallet.

The problem with this approach is decentralization and safety. The users need to trust the relayer network. The nodes in the relayer network are often bonded. However, the slashing condition is hard to calculate. Thus safety is not guaranteed.

In this model, there is a light client running on the destination chain which can validate and read events or states on the source chain. After the block headers and transactions relaying to the destination chain, the light client can verify the validity natively on the destination chain.

This approach is relatively safe and trustless. Users don’t need to trust the intermediary entities, because the light client can verify the validity. However, this approach costs a lot, especially running a light client on Ethereum. Also, it is development intensive. The cross-chain protocols need to build light clients for every supported chain.

Most technique designs can fit into these three approaches. However, there are some novel approaches. ZKLink and ZKCross use a hub and ZKRU to achieve cross-chain function. Users deposit funds from the source chain to the ZKRU and withdraw the fund from ZKRU to the destination chain. This looks like a ZKRU with multiple base layers. The ZKRU node operators generate proofs for batches of txs and put them into ZKRU smart contracts on all these base layers. An oracle network will ensure data consistency among all ZKRU smart contracts on all these base layers.

Another approach is similar to Tornado Cash. The user makes a deposit on the source chain and generates ZK proofs. Then the user withdraws the token on the destination chain with his/her ZK proofs.

There are roughly four types of bridges:

• Asset-specific

• Chain-specific

• Application-specific

• Generalized

This kind of bridge only helps specific assets to be used across all chains. This kind of bridge collects collateral on the source chain and proved wrapped assets on other chains.

Asset-specific bridge is easy to implement and has unlimited liquidity because the bridge mints wrapped tokens. One common example is most bridges for BTC. Users get the wrapped version, like WBTC on other chains.

This kind of bridge is built to cross assets from one chain to the other. The bridge will lock tokens on one side and mint native or wrapped tokens on the other side. This kind of bridge is popular in the bridge ecosystem and it is meaningful for chains. For example, when Secret Network launches, it has multiple chain-specific bridges. Users can easily bridge assets from outside to Secret Network.

This kind of bridge is designed for application expansion to multiple chains. With the application-specific bridge, the developer does not need to deploy the full dapp on every chain. Instead, the developer only deploys a light and modular adapter on each chain. However, it is hard to add more complex functions in the future. Examples are Compound chain and Thorchain.

This kind of bridge can be used to deliver messages between chains. Dapps can use this kind of bridge for cross-chain communication purposes, like calling another smart contract on the other chain. Based on this cross-chain communication protocol, developers can increase the user experience in multi-chain scenarios. Staying on one chain, users can reach anything on other chains. Users will not feel the gap between chains.

LayerZero ignites the generalized bridges market. Some chain-specific bridges are implementing their own cross-chain communication protocols like Celer and Anyswap.

Similar to the trilemma in blockchain, the cross-chain bridge also has its own trilemma. Most projects can only get two out of three.

1. Unified liquidity: This means the bridge has only one pool on chain A. This one pool is tied to all the other chains.

2. Instantly guaranteed finality: Before the transaction resolves on the source chain, the cross-chain tx will resolve on the destination chain.

3. Native assets: The bridge mints native assets to users on the destination chain, not wrapped assets

Besides the cross-chain bridge trilemma, there is interoperability trilemma:

• Trustless

• Extensible

• Generalizable

Most solutions can only get two out of three.

• Local Verification = Trustless + Extensible

• External Verification = Extensible + Generalizable

• Native Verification = Trustless + Generalizable

When reviewing cross-chain bridges, there are five important aspects:

• Security: What is the security assumption of the bridge. Do users need to trust anyone? If the fund is lost, what is the backup plan?

• Speed: How long users will wait to get their funds on the destination chain.

• Connectivity: How many different chains do the bridge support.

• Capital efficiency: The efficiency of the liquidity and tx costs.

• Statefulness: Ability to support cross-chain communication.

Multichain is a generalized bridge with external validation. The SMPC network secures Multichain. Multichain has 32 running nodes with 0 stakings.

Multichain currently supports 44 chains, 2090 bridges, and $5.66B TVL. Multichain supports asset transfer, cross-chain communication, and NFT bridges.

For cross-chain communication, the developer needs to implement the following two interfaces:

function anyCall(address _to, bytes calldata _data, address _fallback, uint256 _toChainID) function anyExec(address _from, address _to, bytes calldata _data, address _fallback, uint256 _fromChainID)

Currently, the anyCall is permissioned. Developers need to contact the Multichain team to whitelist their contracts and deposit some fees in the destination contract. It has poor functionality and docs compared to other competitors.

cBridge is developed by Celer. cBridge is a generalized bridge with external validation. The State Guardian Network (SGN) secures cBridge. There are a total of 18 validators and 1.2B $CELR staked, around $36M to secure $700M TVL. If there are any security problems, the staked $CELR in SGN will be slashed.

Source: The SGN as a cBridge node gateway and Service Level Agreement (SLA) arbitrator - Celer cBridge

cBridge has $45M daily transaction volume and 3k daily txs. It has $700M TVL across 28 chains.

Besides transferring fungible tokens, cBridge also supports NFT cross-chain transfer in two ways:

1. Wrapped NFT

2. Native NFT

For wrapped NFT, cBridge will lock the original NFT and mint a wrapped version on the destination chain. However, for native NFT, cBridge will burn the original NFT on the source chain and mint a new one on the destination chain.

Only NFT following this template can be used as native NFT.

cBridge also offers SDK for developers. Developers only need to care about two steps:

1. Get quote.

2. Send transactions onchain.

Besides cross-chain assets, Celer supports cross-chain communication. The whole workflow with token transfer looks like the following diagram:

Source: Celer IM Design Patterns - Celer Inter-chain Message (IM)

The token transfer will go through cBridge and the message will go through SGN and executor.

Similar to LayerZero, the developer only needs to add two functions to the smart contract. Compared to LayerZero, Celer additionally supports token transfer.

// Send message MessageSenderLib.sendMessageWithTransfer() MessageSenderLib.sendTokenTransfer() // Receive message executeMessageWithTransfer

My colleague Iris wrote a dedicated report for LayerZero.

In short, LayerZero mixes native verification and external verification to achieve a generalized function bridge supporting cross-chain communication.

LayerZero is especially easy to use for developers. Developers only need to implement two functions:

function send( uint16 _dstChainId, bytes calldata _dstContractAddress, bytes calldata _payload, address payable _refundAddress, address _zroPaymentAddress, bytes calldata _adapterParams ) external payable; function lzReceive( uint16 _srcChainId, bytes calldata _srcAddress, uint64 _nonce, bytes calldata _payload ) external;

LayerZero has an active community. The LayerZero team implemented Stargate, a cross-chain asset bridge on top of the LayerZero protocol. The community implemented ERC-721O for the NFT cross-chain.

ChainPort is an external verification, chain-specific bridge. It supports 7 chains and has a $208M TVL. The settlement time is around 2.5 minutes. Listing new tokens on ChainPort is permissionless. In the future, ChainPort will release insurance and use ML to detect unusual activities.

Developers can integrate ChainPort into their smart contracts with the following functions:

function depositTokens( address token, uint256 amount, unit256 networkId ) function burnTokens( address bridgeToken, uint256 amount ) function crossChainTransfer( address bridgeToken, uint256 amount, uint256 networkId )

Nil Foundation recently released one Demo, verifying Mina states on Polygon and Ethereum.

In one word, this infra allows smart contracts on Polygon or Ethereum to verify the validity of Mina state. With this infra, smart contracts have the ability to recognize invalid cross-chain tx.

This infra can generate Mina state proof and smart contracts on Polygon and Ethereum can verify the proof onchain. In the future, cross-chain apps can directly verify the cross-chain tx validity with this infra. For example, apps can use this infra to verify the tx validity passing from the relayers. We are moving from using game theory to math to ensure the validity of cross-chain tx.

In the demo, it takes around 1 min to generate the proof and costs 2.5m gas to verify it. If the gas price is 80, this costs 0.5 ETH for verification on Ethereum.

We can use this infra to build a bridge from Mina to Ethereum with the following steps:

1. The bridge locks $MINA on Mina.

2. The infra generates Mina state proof.

3. The infra put Mina state proof it onto Ethereum.

4. Ethereum checks if the state proof is valid.

5. Ethereum accepts and stores the proof in case it is valid and rejects otherwise.

6. The bridge checks the state and releases WMINA on Ethereum.

In the future, more EVM chains will be able to verify the Mina state proofs onchain. However, it is not feasible to generate Ethereum state proofs and verify on the Mina onchain.

LI.FI is a developer-friendly aggregator for cross-chain bridges and DEXs. Users can exchange one token on the source chain for another token on the destination chain. LI.FI now supports Connext, Hop, cBridge, Multichain, Hyphen, Optimism, Polygon, Arbitrum, and Avalanche cross-chain bridges. For exchanges, LI.FI supports Parawap, 1inch, 0x, Dodo, Uniswap, Sushiswap, Quickswap, Honeyswap, Pancakeswap, Spookyswap, Spiritswap, Solarbeam, Beamswap, and ubeswap.

Based on LI.FI SDK, LI.FI team implements transferto.xyz. Users can customize slippage, which bridge, and DEX to use. Users can find lots of mainstream tokens on transferto.xyz.

For developers, LI.FI provides different ways to integrate LI.FI. If developers don’t need any customizations, developers can use iframe to integrate the trading widget in 5 minutes. Besides iframe, developers can use Node.js API to send cross-chain transactions.

Source: LI.FI

LI.FI has over $250M daily swapped and 186 daily transactions.

Most tokens in the cross-chain bridge are used as governance tokens. Few tokens can be staked to share the whole protocol revenue. These tokens are also used to incentivize the liquidity providers as mining rewards. Plus, the rewards are used to rebalance the liquidity pool, guiding the liquidity to the appropriate pool.

XY Finance, a cross-chain bridge, raises $12m, but its ATH market cap is $8m. Now its market cap is $3m. In most cases, we can treat cross-chain bridge tokens like DEX tokens, which always perform badly because of the emission. Developers are still looking for specialized scenarios for cross-chain tokens. As investors, we need to be cautious about the cross-chain bridge tokenomics.

Source: coingecko

In one year, the total loss of bridge in hack events is around $1.2B. The fee for the bridge is around 5‱. Multi is the big player in the cross-chain bridge. Thirty days volume for Multi is $5B. One year is around $70B volume with $35M fee. It is certain that the whole revenue of the cross-chain bridge market is still less than the loss fund.

It is hard for cross-chain bridges to stay safe. After reviewing major security issues in these hack events, we found that these issues are all different. Hackers are able to find problems in different parts of the system.

In the Polynetwork hack, the hacker utilized privilege-related vulnerabilities:

1. The executer contract doesn’t check the input. The executer contract executes arbitrary cross-chain transactions without verification.

2. The executer contract has the privilege to change the keeper role, which is crucial to the whole system.

The hacker passed the cross-chain transaction which changes the keeper role. Although the hacker didn’t have the permission to change the keeper role, the privileged executer contract helped the hacker to do this. Thus the hacker successfully stole $6B funds.

After the Polynetwork hack, developers remove any privileges of the executer contract and add whitelists for the allowed cross-chain transactions.

In Ronin cross-chain bridge hack, the hacker stole the private keys of admins by hacking the RPC server.

Hackers are discovering different attacking vectors. We don’t know what will be the next security issues of cross-chain bridges. Cross-chain bridges are complex. Thus it is hard to keep them safe. Besides, there are no standards for cross-chain bridges. Developers are implementing their own bridges with their own ideas. It is similar to developers making tokens without using ERC20 library from Openzeppelin. If there is a safe and easy-to-use cross-chain library, the cross-chain bridges will be much more secure.

There are generally three kinds of technique approaches:

• Local Verification

• External Verification

• Native Verification

Cross-chain bridges have four functions:

• Asset-specific

• Chain-specific

• Application-specific

• Generalized

When reviewing a bridge, we care about the following characteristics:

• Capital efficiency

• Connectivity

• Security

  • Trustless

  • Insured

  • Trusted

• Speed

• Statefulness

There are lots of players in the cross-chain bridge markets. New players face fierce competition, security risks, and need to collect enough TVL. Following are opportunities in this area:

• Bridges between layer2s, bridges between layer2 and layer1: There are not as many players in this market as players in the cross-chain bridge markets. This market is still early. In the future, we expect transactions in layer1 to move to layer2. This means more protocol revenues for protocols in this market.

• Bridges with new tokenomics: Nobody knows how to use tokens appropriately in the cross-chain bridge. Most tokens are used as governance tokens and secure the whole network. We often see TVL increases, but the token price decreases. The token price does not reflect the progress of the project.

• Bridge SDK: A toolkit or standard for building bridges. Developers can quickly construct their own bridges to extend their applications over more chains. Multichain is the future. With this toolkit, developers can expand to new chains fast and secure.

• Bridge Aggregator: The aggregator connects with multiple bridges and offers better UX and lower fees. The DeFi market proves the necessity of aggregators. After DEXs, lots of aggregators join the market. This will happen again in the cross-chain bridges market.

• ZK Bridge: ZK bridges can offer a better, cheaper, and safer cross-chain experience. Developers can easily build apps on top of the ZK bridge. Nil Foundation made significant progress in Solana and Mina, but it is hard to expand to other chains.

You can find more cross-chain bridges on decentralized finance.

I am the tech associate in Fundamental Labs. You can find me on Twitter and find FL here.

If you like this report, feel free to like and share this report with your friends. This helps us a lot.

What's wrong with bridges？ - The Anti-Ape (substack.com)

Blockchain Bridges: Building Networks of Cryptonetworks | 1kxnetwork (medium.com)

LayerZero Labs: Building the Future of Cross-chain and Solving the Bridging Trilemma with Stargate (notion.site)

如果你喜欢这篇研报，欢迎点赞收藏，分享给感兴趣的朋友。这对我们有很大帮助。

ZK 的前景是美好的，它可以让一些过去不可能的事情变成现实。近年来，ZK 领域发生了很多突破性的进展，例如更强的性能、可升级性和不需要信任初始化。这些改进都将 ZK 推向了应用阶段。因此，如果我们要看到一个新的 ZK 证明系统，我们可以从以下维度进行评判：

• 一笔交易和十笔交易的证明时间

• 一笔交易和十笔交易的验证时间

• 一笔交易和十笔交易打包后的证明大小

• 可信初始化

• 参考字符串长度

• CRS 支持

• SRS 支持

• 递归证明支持

• 能否抵抗量子计算机

• 安全性基于任何密码学假设

ZKEVM 是 ZKRU 的下一个里程碑，ZKEVM 有三个阶段：

• 共识级

• 字节码级

• 语言级

ZKRU 刚刚进入应用阶段，生态并不完善。开发者们还没有发掘出 ZK 的所有潜力。人们仍不断从这些前沿理论中得到启发，以下是值得关注的方向：

• 充分利用高 TPS 和低手续费的应用程序

• Layer2 之间的通信协议/应用程序

• 聚合流动性

• 开发工具/框架

• 基于云的开发工具

• 具有独特功能的跨 Layer2 Layer1 应用程序

• 不同的 ZKVM

• ZK 桥

• 在其他链上应用 ZK

• 拥有递归功能的 Layer2

• ZK 在 DAO 和社区治理中的应用

• 商业化 ZK 算法

• 芯片和云计算

ZK 的应用聚焦在两个方面：Rollup 和隐私。Rollup 比隐私有更好的前景。隐私在某种程度上和区块链的开放精神相违背。另外，隐私可能有合规问题。在 Web2 时代，我们没有看到隐私应用程序达到龙头的位置。所有应用的隐私保护水平在不断提高，但龙头应用往往不是主打隐私的引用，而是易用性最强的应用。隐私是有代价的，大多数情况下牺牲了用户最关心的易用性。

当我们看 ZK 隐私项目时，以下几点较为重要：

• ZK 只是技术，我们要专注产品力和团队

• ZK 是个复杂的技术，会拖慢开发进度

• ZK 有利于 DAO 治理和身份认证

• ZK 是机构上链的必备技术

一句话介绍 ZK（Zero Knowledge Proof）：证明者（Prover）说服验证者（Verifier）相信某些声明是真的，但除了声明是真的之外，验证者没有获得其他信息。

ZK 是为匿名而设计的。试想我们可以证明我们的身份证号码是有效的，但是验证者并不能获得我们的身份证号码。这在信息过度索取的今天，具有重大意义。

让我们来看一个更加生动的例子。小明和小红在玩数独。小红想向小明证明她找到了数独的答案，但同时又不透露这个答案，因为小明还没解出这个数独。你将如何设计这个证明？

我们把数独写到卡片上。每张卡片上有一个数字。将他们按照答案排列好，正面朝下。小明可以随机选择一列，一行或者一块。小红将拿出小明所选择的那些卡片，随机打乱后，将这些卡牌翻过来，正面朝上。如果这些卡牌是不重复的 1-9，那么小明知道小红解出了数独的某一部分，但也或许是运气。重复以上步骤，如果每次都是正确的。那么就几乎不可能是小红运气好，而是小红真的知道答案。虽然小明得知小红解出了数独，但是小明仍旧不知道数独的答案。

如果你还是有点疑惑，欢迎观看这个视频。UCLA 的计算机教授将以 5 种难度形式，解释什么是 ZK。

在介绍零知识证明流派之前，大家要注意我们常说的 ZK-SNARK 不是一种算法，而是一种流派。ZK-STARK 是一种具体零知识算法的名字。

我们最常见的可能是 ZK-SNARK。SNARK 的缩写是 succinct non-interactive arguments of knowledge。SNARK 最特殊的点在于他的 N，非交互性。

• 简洁性（Succinct）：验证所需要的计算资源远远小于重新跑一遍需要证明的程序。

• 非交互性（Non-interactive）：证明者和验证者不需要每一轮都沟通。他们只需要在一开始完成可信初始化（Trust Setup）。其他验证者也可以在可信初始化之后加入验证。

• Argument：如果证明者有着无比强大的算力，那么他可以生成假证明。如果这种情况发生，主流的公私钥加密模式也不再安全。

• 知识（Knowledge）：证明者需要知道一些其他人不知道的秘密，才能生成证明。

ZK-SNARK 最大的问题在于它需要可信初始化（Truest Setup）。可信初始化会生成参考字符串（Reference String）。如果 RS 被泄露，那么任何人都可以生成虚假证明。此外，如何设计多人参与的可信初始化也很具有挑战性。RS 还只能被用于指定的程序。对于其他的程序，我们需要另外的可信初始化。因此 ZK-SNARK 不可能用于通用计算。另外一点，RS 不能升级。如果我们升级了程序，可信初始化要重新运行。

为了解决这一系列的问题，科学家们找到了两个方向：

• Transparent Setup：可信初始化生成公共参考字符串（Common Reference String）。CRS 是公开的，不需要保密。Fractal，Halo，ZK-STARK，SuperSonic 都是采取了这一条路线。这一条路线的问题是生成的证明占用太多的存储，来到了 kB 的量级。对于区块链来说，存储是非常昂贵的。

• Universal Setup：可信初始化生成了结构化参考字符串（Structure Reference String），但它需要保密。SRS 让可信初始化可以用于不同的程序，这让通用计算的证明可能实现。Marlink，SuperSonic-RSA 和 Plonk 都采用了这条路线。

业界广泛采用以下几种算法：

• Groth16：Zcash 一开始使用了这种算法。它是零知识证明中的跑分对照组，因为它具有证明快，生成的证明小的特点。它的缺点是需要可信初始化，并且一次可信初始化只能针对一个程序。它拥有最完善的工具链。

• Sonic：支持 Universal Setup. SRS 的大小和程序大小成线性关系。生成的证明是固定大小，但是验证需要消耗很多的计算资源。Sonic 让通用计算的零知识证明变为可能。

• Fractal：支持递归（Recursion）。生成的证明占用较多空间。

• Halo： 支持递归，但并不满足简洁性（Succinct）因为证明时间是非线性的。Halo2 是目前主流使用的证明系统。

• SuperSonic：第一个实际的，可以应用的 Transparent ZK-SNARK。

• Marlin：程序可以升级。性能处于 Sonic 和 Groth16 之间。

• Plonk：程序可以升级；参与者按照顺序加入可信初始化。这让进行有很多人参与的可信初始化不那么复杂；Plonk 使用 Kate commitments 而不是多项式承诺（ZK-SNARK 的第一步是将计算问题转化为多项式问题）。许多现代化的零知识证明系统都构建与 Plonk 之上。Plonk 有着非常优秀的工具链。

如果你想挑几个算法仔细研究，Groth16，Halo，Plonk 是最好的选择。

CRS 是 Transparent Setup 路线中生成的公共参考字符串。SRS 是 Universal Setup 路线中生成的结构参考字符串。证明的大小将决定要占用 Layer1 多少的存储空间。证明和验证的时间决定了计算资源的消耗。

下图是零知识证明算法的 Benchmark，基于这个实验。

以下有更多的 Benchmark 和算法对比：

• Benchmarking Zero-Knowledge proofs with isekai | by Guillaume Drevon | Sikoba Network | Medium

• Zero-Knowledge Proofs: STARKs vs SNARKs | ConsenSys

• Community Proposal: A Benchmarking Framework for (Zero-Knowledge) Proof Systems (zkproof.org)

• Comparison of Different zk-SNARKs

总结以下，当我们看到一个新的 ZK 算法时候，以下指标是我们需要在意的：

• 一笔交易和十笔交易的证明时间

• 一笔交易和十笔交易的验证时间

• 一笔交易和十笔交易打包后的证明大小

• 可信初始化

• 参考字符串长度

• CRS 支持

• SRS 支持

• 递归证明支持

• 能否抵抗量子计算机

• 安全性基于任何密码学假设

ZK 在最近几年走出实验室，逐渐步入应用。ZK 两个主要应用方向是 Rollup 和隐私。ZK 对于隐私产品的变革是显而易见的，得益于 ZK 可以让验证者不获得任何额外信息。Rollup 依赖于 ZK 的两大特性：简洁（Succinct）和递归（Recursion）。简明的特性有助于验证者节省大量的计算资源。验证者不需要重新运行整个程序。递归特性有助于节省存储空间。通过递归，区块链可以保持一个固定的大小。这也有利于去中心化，因为这样的区块链节点在什么样的硬件上都可以跑起来。

独立开发一个 ZK 应用非常复杂，开发需要掌握以下技能：

• 算法，底层算数，优化技能。开发者需要这些技巧来解决一些有限域算术、多项式承诺和椭圆曲线问题。

• ZK 证明系统，如 ZK-SNARKs、Plonkish 和如何可信初始化。开发人员需要选择适当的 ZK 证明系统，并对其进行定制。

• 电路编程技能。开发者需要讲常用密码学算法编写成电路，如 Merkle Tree 和 Hash。

• 应用和密码学协议开发。

有效的开发工具可以加速开发过程，也可以降低复杂性。例如，像 Circom 这样的工具可以解决底层代数和证明系统。开发人员可以忽略代数和 ZK 证明系统，专注于电路编程和应用开发。

Rollup 的想法很简单。由于链上计算较为昂贵，因此 Rollup 希望安全地将计算移动到链下，并只在链上存储计算结果。

哈希树的状态根存储在 Rollup 合约中。Rollup 智能合约从 Layer2 提交的信息中更新状态根。

ZK Rollup（ZKRU） 使用零知识证明来确保从 Layer2 提交的新状态根是正确的。验证者只需要验证这个证明就可以确认新状态根的正确性。验证者并不需要一个个重新执行 Layer2 提交的交易。这大大节省了验证者的工作量，提升了 TPS。这节省计算量的部分体现了零知识证明的简洁特性。依赖于零知识证明的简洁性，完备性，合理性，ZKRU 得以安全地提升 TPS。（完备性和合理性是证明系统的必备特性。完备性 Completeness：如果证明是有效的，验证方一定会相信证明方的断言。真的假不了；合理性 Soundness：虚假断言不可能生成有效的证明。假的真不了。）

ZKRU 整体来说优于 Optimistic Rollup（OPRU）。OPRU 的 TPS 略差，并且需要更长的提款周期，因为它依赖于欺诈证明（Fraud Proof）。那么等 ZKRU 全面铺开以后，不就是 ZKRU 碾压 OPRU 了吗？并且 OPRU 目前的生态并不算过于领先。OPRU 并没有坐以待毙，他们尝试将 ZK 融入自家的解决方案来提升 TPS，解决原生提款周期过长的问题。例如，他们将 ZK 应用于状态变化，这样就可以缩短欺诈证明所需要的时间了。

在 Rollup 的体系中，一共有三个角色：

• 用户：用户在 Layer2 提交交易。他们从 Layer1 充值资产至 Layer2

• Rollup 节点：Rollup 节点负责维护 Layer2 网络的正常运行。它们需要生成证明，执行交易，打包交易，参与欺诈证明

• Layer1: Layer1 保证了 Layere2 的安全性，并负责共识的达成。大部分 Layer1 目前都是以太坊。

经济模型中最重要的就是成本和收入。对于 Layer2 来说，支出基本上是以下几个：

• 生成证明的计算成本

• 切换状态的计算成本

• Layer1 交易手续费

• Layer1 数据存储成本

其中 Layer1 数据存储成本最为昂贵。这张图展示了数据的传递。首先用户递交交易给 Rollup 节点。Rollup 打包多笔交易并生成证明，存储在 Layer1 中。

这张图展示了 Rollup 在 Layer1 上的支出已经它们的收入：

Layer2 最常见的收入是手续费和 MEV。手续费基于网络的情况，MEV 则取决于用户的交易。Layer2 也会发行属于自己的代币，并且奖励给 Rollup 节点。

这张图展示了常见 Layer2 以及他们的市场占比。目前 Arbitrum 占据市场半壁江山。

下图展示了不同 Layer2 使用的不同技术：

• 状态验证（State Validation）

  • 欺诈证明（Fraud Proofs）：允许白名单执行者监控链上交易，并指出错误状态。

  • 零知识证明（ZK proofs (ST)）：使用 ZK-STARKs 来证明状态的正确性。

  • SN：ZK-SNARKs

  • 仅在退出验证（Exits Only）：退出网络时，状态会被验证。中间状态并不会被验证。

  • 互动证明（INT）：需要多笔交易来解决纠纷。

  • 一轮（1R）：只需要一轮证明来解决状态纠纷。

• 数据可用性（Data availability）

  • 链上（On chain）：构建证明需要的所有数据都在链上。

  • 外部数据委员会（External DAC）： 构建证明需要的所有数据都不在链上。数据委员会负责保护和提供数据。

  • 外部（External）： 构建证明需要的所有数据都不在链上。

• 升级（Upgradability）

  • 是（Yes）： 可以随时升级，不需要任何公告。

  • 21 天延迟或无延迟（21 day or no delay）： 有 21 天的延迟，除非安全委员会多签通过了立即升级。

• 故障序列（Sequencer Failure）

  • L1 交易（Transact using L1）：用户可以在 L1 提交一笔交易来强制 L2 打包自己的交易。

  • 强制交易/L1 退出（Force trade/ exit to L1）：用户可以在 L1 提交请求来强制 L2 打包自己的提款请求，但这意味着用户需要找在系统之外找到交易对手方。

  • 强制 L1 退出（Force exit to L1）：用户可以在 L1 提交请求来强制 L2 打包自己的提款请求。

  • 构建区块（Propose blocks(ZK)）：用户需要自行运行节点来构建区块。这个区块包含了用户想要打包的交易。这要求用户自行计算 ZK 证明。这对算力有很大要求。

  • L1 退出（Exit to L1）：用户只能在 L1 提交提款请求。

• 验证失败（Validation Failure）

  • 逃生舱（Escape hatch(MP)）：用户可以在无需信任的情况下拿回押金。用户需要提交资金的哈系树证明。押金将会以上一次状态中的平均价格退出。

  • 构建区块（Propose blocks）：用户需要自行运行节点来构建区块。

Ethhub 列出了 ZKRU 的几个主要优缺点：

• 优点

  • 降低用户手续费

  • 优于 OPRU 的性能， 手续费，提款周期

  • 区块可以并行运算，有利于去中心化

  • 更高的 TPS

  • 更短的提款周期，优于欺诈证明

  缺点

  • 计算证明需要大量的资源

  • ZKRU 的可信初始化较为中心化

  • 量子计算可能会损害安全性

  • 安全假设包含不可验证的信任

  目前大部部分 ZKRU 只支持支付和有限的功能。zkSync 是 Gitcoin 的支付层。ZKRU 大多使用自定义虚拟机，并不兼容 EVM。例如，StarkEx + Cairo 和 zkSync 1.0 + Zinc。

  ZKEVM 是 ZKRU 的下一个里程碑。ZKEVM 可以划分为三个等级：

  • 共识级：ZKEVM 和主网上的 EVM 等价。生成的状态根是通用的。以太坊在未来计划实现主网上的 ZKEVM。

  • 字节码级：ZK 证明系统在这个阶段非常重要，需要对 EVM 友好。字节码级的 ZKEVM 生成的状态根与 EVM 的状态跟格式不一样，因为 ZKEVM 采用不一样的密码学算法。EVM 使用的那些对于 ZK 证明系统不友好。Scroll 和 Hermez 采用这个解决方案。

  • 语言级：在这个级别，并没有真正的 ZKEVM。一个转译器将 Solidity 编写的智能合约或者字节码转译成自定义虚拟机可以执行的格式。zkSync 和 Starkware 都是采用这个解决方案。这个方案的缺陷是，并不能兼容 EVM 的所有功能。

  以太坊基金会的 Justine Drake 计划在 2022 年底看到可用的字节码级 ZKEVM，但会有以下限制：

  • 与主网相比，较小的 Gas Limit。

  • 中心化节点由于生成证明需要大量的算力。用户将在 2023 年使用他们的 GPU 生成证明。2024 年，ASIC 将投入使用。节点运营者将从 CPU 到 GPU，FPGA，最后到 ASIC。

  • 由于 ZKEVM 的工程复杂度，ZKEVM 会存在 Bug。

  为了进一步降低手续费，一些 ZKRU 正在实现 Volition，将数据存储的地方从以太坊到链下。

  市场上目前有 16 个 ZKRU，其中 7 个发行了代币，总市值 150 亿美金，占加密货币总市值的 0.67%。

  Polygon

  Polygon 目前在实现 4 个 ZK 产品：

  • Miden：实验性质的 ZKRU 通用计算平台，TPS 1k+ ，15 min 提款，5 秒产出 1 个块，隐私交易。

  • Nightfall：Nightfall 是一个 ORU，集成了 ZK 来实现隐私交易。一笔交易需要 9k Gas，110 TPS，为安永会计师事务所设计。

  • Hermez：EVM 兼容的 ZKRU，2k TPS。目前网络已经上线，几乎没有交易量（数据来自区块浏览器）。

  • Zero：通用 ZKRU 计算平台，支持递归。只需要 0.17s 就可以生成证明。证明大小 45 kB。一个账户只占用 5 bits。

  zkSync

  zkSync 由 Matter Labs 创立于 2019/12 基于 Plonk 开发。目前 zkSync 支持支付功能以及有限的智能合约功能。智能合约需要用 Zinc 进行开发。

  zkSync 2.0 测试网在 2022/2 上线，兼容 EVM。Matter Labs 将大部分 OPCODE 电路化实现在不修改证明系统的前提下，实现 EVM 兼容。目前 zkSync 2.0 并不支持 ADDMOD，SMOD，MULMOD，EXP，CREATE2 和 KECCAK256。在这种解决方案下，Solidity 成为了一等公民。

  zkSync 2.0 的 Gas Price 是根据以太坊主网 Gas Price 和 ZK 证明成本动态变化的。受以太坊主网 Gas Price 影响的原因是 zkSync 会将数据打包存储到以太坊主网。

  为了进一步降低手续费，提高 TPS，zkSync 计划发布 ZKPorter。用户可以选择将他们的账户数据存储在 ZKPorter 上来降低手续费。如果一个账户数据存储在 ZKPorter 上，则它所有的交易都将由 ZKPorter 确保数据可用性，交易不再能提交到以太坊主网上。

  以下是关于 zkSync TVL 和资金种类的图表。大部分 zkSync 上的资金都是稳定币。

Starkware 在 2018/5 由 Zcash 核心团队成员创立。

Starkware 有两个产品：StarkEx，StarkNet。

StarkEx 是一款 SaaS 产品，为项目方提供 ZKRU 解决方案。目前客户包含 dYdX，DeverseFi，Immutable，Sorare。dYdX 每周有 4k 活跃用户。

StarkNet 是更加开放的 ZKRU 相比于 StarkEx，任何人都在可以在上面部署合约。StarkNet 目前不兼容 EVM。StarkNet 使用 Cairo 来编写智能合约。

Starkware 也在推进 ZKEVM。他们用了和 zkSync 不一样的解决方案。他们使用 Warp 来将 Solidity 编写的智能合约转译成 Cairo。这个解决方案并不如 zkSync 的解决方案，对 Solidity 的兼容性较差。

StarkNet Alpha 兼容 ZKEVM 在 2021/11 上线。目前每日交易数量为 1033（数据来自区块浏览器）。

Loopring 是一个基于 ZKRU 的交易所，提供低手续费的交易体验，可以达到 2k TPS。

Loopring 在 2018 发行了代币 $LRC。目前市值为 13 亿美金。Loopring 总共有 65k

用户，每天用户增长数为 167，每日交易量为 10896（数据来自区块浏览器）。

dYdX 是 Loopring 强力的竞争对手。在未来，当 ZKEVM 正式投入应用，会涌现出一大批 DEX，因为 Solidity 的开发速度比开发 Layer2 快很多。新的项目 Fork 也很快。整个交易所的竞争将非常激烈。

在过去，我们经常听到一些高 TPS，低手续费的链标榜自己为以太坊杀手。随着时间的推移，大部分以太坊杀手杀死了自己。剩下的链都找到了自己的发展方向，如 DeFi，GameFi。这些链也有了自己的特色应用和完整的生态。

现在开发一条高 TPS，低手续费的链不难，难就难在生态和特色应用。因此我们不能只关注纸面性能数据，而要注重用户，生态和特色应用。

Layer2 具有的特点是高 TPS，低手续费，完整的生态。虽然不少 Layer2 ZKEVM 主网还没上线，但是已经和很多项目达成了合作。

Moonbeam 目前的状态就很像一条 Layer2。它背靠 Polkadot，和大 DeFi 项目有合作，有完整的 DeFi 生态和跨链桥，但是缺少特色应用。下图是 Moonbeam 的 TVL 图。

因此完整的生态对于 Layer2 是不够的，Layer2 还需要发掘出它的特色。

能够充分利用 Layer2 长处的特色应用将是 Layer2 之间竞争的关键。目前我们发现的是类似 dYdX 的交易所可以充分利用低手续费，高 TPS 。另一个有潜力的应用便是链游，他们的需求与交易所类似，也是低手续费，高 TPS。

Layer2 们共享同一个 Layer1，因此构建跨 Layer2 应用将安全的多。我们期待看见开发者利用这个特性，实现一些具有创新的应用。这些应用将不能被复制到跨链生态中，因为只有 Layer2 才共享同一个 Layer1。例如 Starkware 提出了聚合跨链流动性的构想，所有流动性存储在 Layer1，但是可以在 Layer2 中进行使用。

开发 ZK 应用是复杂的，开发者需要了解代数，证明系统，电路编写和协议开发。因此他们需要一些合适的开发工具来加速开发，做适当的抽象，省去一些底层的开发。

除此之外，定制化 Layer2 也将在未来有绝佳的市场。这类型的开发框架可能类似 Cosmos SDK 和 Polkadot 的 Substrate。

当一个应用变得热门，它不可避免的需要占据更多的计算资源。为了降低手续费，它可以选择做一条自己的链，迁移到 Layer2 和自己定制一条 Layer2.

Axie Infinity 便面临着一样的问题。在那个时候，Layer2 还不成熟，定制 Layer2 的成熟方法也根本不存在。因此 Axie Infinity 只能自己开发一条链，来自定义手续费。这带来了几个问题：

1. 不能和以太坊共用生态

2. 无法享受以太坊的流量

3. 跨链桥安全性

在不远的未来，迁移到 Layer2 或许是一个不错的选择，但是在 Layer2 开发终将面临一样的问题。应用并没有完全的自主性，还是会面临一些限制，所以最有前景的选择是定制化做一条 Layer2。如果那时候跨 Layer2 非常的成熟，Layer2 和以太坊的交互也很方便，定制化的 Layer2 的使用体验将无比丝滑。

Layer2 如何与 Layer1 结合也是一个有意思的方向。只有 Layer2 和 Layer1 良好结合，用户才更容易从 Layer1 迁移到 Layer2。这包含了更好的资产桥和通讯协议。

ZKEVM 是 ZKRU 的下一个里程碑。ZKEVM 分为三个级别：

• 语言级别：在这个级别，其实并不存在 ZKEVM 。我们有一个 ZK 友好的自定义 VM 和一个转译器。转译器将 Solidity 编写的智能合约翻译成这个自定义 VM 可以执行的形式。zkSync 和 Starkware 都采用这个形式。这个形式的好处是开发速度快，但是无法兼容 EVM 的所有功能。

• 字节码级别：在这个级别我们有一个完全兼容的 ZKEVM 。我们的证明系统对于 EVM 非常友好。缺点是这一级别生成的状态根和主网 EVM 的状态根根式不一样。Scroll 和 Hermez 正在实现这一级别的 ZKEVM ，预计在年底可以推出。

• 共识级别：共识级别的 ZKEVM 运行在主网上，这一级别的 ZKEVM 和 EVM 别无二样。

除了 ZKEVM ，我们可能也会看到其他虚拟机，例如 ZKWASM 等。

zkLink 在 Solana 推出了 Groth16。ZKRU 在其他链上或许也有机会。ZKRU 可以赋予项目更大的自由，以及隐私性。对于企业来说，他们有必要保护客户的隐私。因此 Layer2 也是让这些企业上链的一个机会。

目前大家都在努力实现一个无需信任的跨链桥，但所有的桥都需要相信第三方。虽然这些桥都要求参与者抵押资产，但我们很难具体计算作恶的成本和收益。ZK 可以应用在跨链桥中，用来生成交易证明。这样我们就不需要相信预言机所传递的信息，只需要对证明进行验证就好。目前 ZK 跨链桥的问题在于如何生成区块的证明，而且扩展性堪忧。不同的链需要开发不同的电路来生成对应的区块证明。

商业算法广泛出现在专业领域，例如线性求解器，GPT-3等。如果 ZK 始终维持着高入门门槛，开源便不能帮助其降低开发和维护成本，因为没有人有能力来为其做贡献。在这种情况下，便会出现 ZK 商业算法。目前大部分 ZK 从业者拥有 Ph.D. 学位。

随着更多的用户流入 Layer2，Layer2 将捕获更多的价值。矿工们也将进行军备竞赛，购买性能更强大的矿机。在以太坊的路线图中，未来将集成 ZKEVM 。Filecoin 目前也投入了 ZK，矿工需要是生成证明。这也就是说矿工必须需要一枚可以快速生成零知识证明的芯片。

纵览以太坊和比特币矿机，一开始矿工们使用触手可得的 CPU 和 GPU 进行挖矿。在这个阶段，软件开发者需要为算法适配硬件加速。在这之后 FPGA 出现了。FPGA 具有更好的能耗比，更强的性能，并且是可编程的。用户可根据算法的不同，对 FPGA 进行编程，来适应算法。ASIC 最后出现，因为它的设计，量产需要更长的时间。ASIC 具有最好的能耗比，最强的性能，但是缺点是生产周期长，并且不具备可编程性。

未来是属于 ASIC 还是 FPGA 将取决于这些 Layer2 会不会频繁切换证明系统。每年都有更好的证明系统被开发出来。如果 Layer2 频繁进行切换证明系统，只能适用于单一计算任务的 ASIC 将被迫不断推出新产品，但同时 Layer2 切换证明系统也会带来很多工程化上的问题，例如重新适配 ZKEVM。

递归可以使区块链有更小的体积。更小的体积意味着节点可以运行在低端设备中。这非常有利于去中心化。简洁的特性使区块链可以无副作用的提升 TPS。因此递归和简洁将可以打破区块链的不可能三角：安全性，去中心化和 TPS。

ZK 已经被用于很多隐私项目中。例如，Tornado Cash，Zcash，Dark Forest。保护隐私分为三个阶段：

1. 交易隐私：用户可以隐藏他们的交易。

2. 通用计算隐私：目前以太坊上的所有计算过程都是公开的。任何人都可以看到输入，输出，和状态转换。通用计算隐私将隐藏这些计算过程。

3. 函数隐私：有时调用函数的名称会泄露信息。例如，mint() 往往意味着铸造代币。函数隐私将隐藏函数的调用记录。

目前隐私赛道的总市值约为 100 亿美元，约占整个加密货币市场的 0.45%。每日交易量约为 10 亿美元。

Tornado Cash 是一个基于智能合约的隐私交易工具。它可以用来匿名转账，现在支持以太坊， BSC，Polygon，Optimism，Arbitrum，Gnosis 和 Avalanche。

存款，获得凭证，提款。用户就可以完成一笔隐私转账。在新版 Nova 中，用户可以选择任意的提取金额。ZK 用于生成提款凭证。

下图展示了 Tornado Cash 的 TVL 和用户增长。

下图展示了 $TORN 的价格。$TORN 是 Tornado Cash 的治理凭证以及提供流动性的奖励。

Zcash 是一个使用 ZK-SNARK 来实现隐私交易的区块链。与基于智能合约的 Tornado Cash 不同，Zcash 使用了一条链来实现隐私。

下图展示了 Zcash 链上每日交易量。

下图是 $Zcash 的价格走势。

Zecrey 是一个支持以太坊、Polygon、BSC、Near 和 Avalanche 的隐私支付应用。它处于保护隐私的第一层，交易隐私。Zecrey 提供一个浏览器钱包，用户可以用它匿名转账，交易代币。这些匿名性都由 Zecrey Layer2 保证。因此用户需要先将钱存到 Zecrey Layer2 中才可以使用这些匿名功能。 Zecrey Layer2 是 ZKRU 基于 Plonk。Zecrey 还支持资产跨链。目前 Zecrey 每日交易量大约为 10 笔（数据来自区块浏览器）。

Suterusu 是一个支持以太坊、BSC、Fantom 和 Polygon 的隐私支付应用。它使用 Layer2 来保护用户的交易隐私。它还有一个跨链桥，可以在以太坊和 BSC 之间转移 $SUTER。未来它计划推出 NFT 匿名转账以及匿名拍卖。Suterus 采用 ZK-ConSnark，这种算法不需要信任设置。

Suterusu 共有 15k 用户以及 24k 笔转入。目前用户增速非常缓慢。Suterusu 的市值大约 1000 万美金。

Dark Forest 是一款多人网络游戏。玩家需要占领更多的星球，获得更多的资源。玩家可以向其他星球输送能量来占领它们。星球的位置是保密的。玩家需要利用哈希碰撞自己找到这些星球。ZK 被用来证明与位置有关的操作：

• 行星初始化

• 行星资源的转移

在 Dark Forest v0.6 第一轮中，有 1700 名玩家参加。其中 700 人得到了进入下一轮的机会。在第一轮中，玩家们一共提交了 200 万笔交易，花费了大约 1.5 万亿 Gas。假设它是在以太坊上，Gas Price 是 80，那么这些玩家的手续费总共是 120 ETH。

Stealth Airdrop 允许用户匿名地领取空投。用户首先使用他们满足空投领取条件的钱包来生成零知识证明，接着他们可以用其他钱包和这份证明来获得空投代币。

Stealth Airdrop 代表了 ZK 在治理方面的运用。在现实世界的治理中，我们也广泛应用匿名这个特性。例如在投票中，如果你发现有影响力的人物都投了赞成票，你也会受其影响，更有可能投出赞成票。因此匿名投票可以帮助用户独立投票。

在 2021 年，以太坊基金会对于 ZK 的资助主要集中在 ZKEVM 和治理方面。以太坊基金会主要资助了两个项目，其中一个就致力于解决投票贿赂问题。

A16Z 也实现了类似的东西 a16z/zkp-merkle-airdrop-contract。

这个项目在 ETHDanver 上发布。用户可以生成 ZK 证明来展示他们拥有一个 Buffiness，而不透露他们的个人身份信息。这是 ZK 在身份认证相关的应用。

1. 隐私市场较小。隐私项目很早就出现了。Zcash 始于2016 年。然而，整个隐私市场只占加密货币市场的 0.45%。起步晚的 Layer2 也远超隐私市场。

2. 将会受益于更高的隐私标准。在不牺牲易用性的情况下，用户会追求更好的隐私保护。特别是在手机行业，谷歌和苹果正在推动更严格的隐私标准。欧盟也提出保护消费者隐私的法规。像 Let's Encrypt 这样提供 SSL 证书的基础设施公司更严格的意思标准中受益。在未来，当 ZK 因为更好的隐私保护而会被这些巨头公司采用时，ZK 基础设施将有巨大的机会。

3. ZK 是金融机构入驻的必备条件。一些机构在尝试上链，他们有责任保护好客户的隐私。因此 ZK 在这个场景下将成为区块链的标配，来提供隐私功能。

4. 有利于 DAO 治理和身份。匿名在民主治理有着重要应用。ZK 可以实现匿名投票，让投票者独立思考，不被他人的决定所干扰。身份验证也可以从 ZK 中受益。用户可以在不显示其实际地址的情况下展示其资产。

5. 忽略 ZK，专注于产品的易用性。ZK 可以更好地保护隐私，但一个产品并不全是 ZK。ZK 是一种技术，我们更需要强调产品的易用性。通常，更好的隐私保护并不意味着易用性，但易用性是最关键的。因此，要更加关注易用性、市场和团队。

   另一个有趣的项目

   ZKRepel

   ZKRepel 在 GR13 中成功母子 5000 万美金。ZKRepel 是要给在线 Playground，开发者可以快速体验如何编写电路，并生成证明。ZKRepel 比较像早期的 Remix。

   大环境上，我们看到了从本地开发到云开发的范式转变。在这之中有一些著名的产品，如Codesandbox，Codepen，Codespaces。有了这些产品，开发人员可以在任何地方任何时间使用他们的开发环境。开发者也可以快速建立新的开发环境。Github 提出面对日益复杂的软件开发，开发环境作为基础设施是必不可少的。Github 内部开发环境已经迁移到了自家的 Codespaces。

   目前没有关于 ZK 开发者数据的明确统计。从 Github 上的数据来看，ZK 开发者比 Solidity 开发者少了 500 多倍。

以下项目专门自主或者投资 ZK 项目。

• ZKTech Gitcoin Grants： 第一轮中为 19 个项目中匹配了 10 万美元。

• 0xPARC Grants：支持以太坊和其他去中心化平台在应用层面的创新。

• zkDAO：由 zkSync 和 BitDAO 支持的新推出的 2 亿美元基金，以支持 zkSync 生态。2 亿美元中的 7.5% 将用于Grants。

• Polygon ZK基金

• Aztec Grants：目前的重点是跨链桥、工具和分析。

• Harmony ZK 基金：专注于 ZK 和隐私研究的 1000 万美元基金。

• ZK Validator:：专注于 ZK 的基金。过往投资有 Aztec, Penumbra, Ironfish, Anoma, zkSync, Aleo, Diversfi。

• Aleo 推出的 ZPrice

• Nil Foundation：致力于数据库和密码学方面的项目。

ZK 的前景是美好的，它可以让一些过去不可能的事情变成现实。近年来，ZK 领域发生了很多突破性的进展，例如更强的性能、可升级性和不需要信任初始化。这些改进都将 ZK 推向了应用阶段。因此，如果我们要看到一个新的 ZK 证明系统，我们可以从以下维度进行评判：

• 一笔交易和十笔交易的证明时间

• 一笔交易和十笔交易的验证时间

• 一笔交易和十笔交易打包后的证明大小

• 可信初始化

• 参考字符串长度

• CRS 支持

• SRS 支持

• 递归证明支持

• 能否抵抗量子计算机

• 安全性基于任何密码学假设

ZKEVM 是 ZKRU 的下一个里程碑，ZKEVM 有三个阶段：

• 共识级

• 字节码级

• 语言级

ZKRU 刚刚进入应用阶段，生态并不完善。开发者们还没有发掘出 ZK 的所有潜力。人们仍不断从这些前沿理论中得到启发，以下是值得关注的方向：

• 充分利用高 TPS 和低手续费的应用程序

• Layer2 之间的通信协议/应用程序

• 聚合流动性

• 开发工具/框架

• 基于云的开发工具

• 具有独特功能的跨 Layer2 Layer1 应用程序

• 不同的 ZKVM

• ZK 桥

• 在其他链上应用 ZK

• 拥有递归功能的 Layer2

• ZK 在 DAO 和社区治理中的应用

• 商业化 ZK 算法

• 芯片和云计算

ZK 的应用聚焦在两个方面：Rollup 和隐私。Rollup 比隐私有更好的前景。隐私在某种程度上和区块链的开放精神相违背。另外，隐私可能有合规问题。在 Web2 时代，我们没有看到隐私应用程序达到龙头的位置。所有应用的隐私保护水平在不断提高，但龙头应用往往不是主打隐私的引用，而是易用性最强的应用。隐私是有代价的，大多数情况下牺牲了用户最关心的易用性。

当我们看 ZK 隐私项目时，以下几点较为重要：

• ZK 只是技术，我们要专注产品力和团队

• ZK 是个复杂的技术，会拖慢开发进度

• ZK 有利于 DAO 治理和身份认证

• ZK 是机构上链的必备技术

如果你想要了解更多 ZK，可以阅读这个教程和 https://github.com/ventali/awesome-zk。期待一下这份教程。

我在 Fundamental Labs 担任 Tech Associate。欢迎关注我，我的 Newsletter。你可以在这找到 FL。

An Incomplete Guide to Rollups

The ultimate guide to L2s on Ethereum

Understanding rollup economics from first principles

Ethereum Rollup Call Data Pricing Analysis - Research

How to fund your ZK Project?

zkSNARKs in a nutshell

ZK-STARKs

Understanding PLONK

Introduction to zk-SNARKS

Comparing General Purpose zk-SNARKs

Zero-Knowledge Proofs: STARKs vs SNARKs

Comparison of Different zk-SNARKs

Compare zk-SNARKs in practice

Episode 221: Funding the Next Wave of Zero Knowledge Tech

How Zero Knowledge Proofs Are Changing Blockchain (in non-technical terms)

[AMA] We are the EF's Research Team (Pt. 7: 07 January, 2022) : ethereum

zkSync 2.0: Hello Ethereum!. The Alpha version of zkEVM testnet is… | by Matter Labs | Matter Labs (matter-labs.io)

ZK Tutorial: An Introduction to SNARK Development with arkworks - Pratyush Mishra - YouTube

'Introduction to Zero Knowledge Proofs' - Elena Nadolinski - YouTube

(2) zkSummit6: arkworks: A Rust Ecosystem for zkSNARKs – Pratyush Mishra – UC Berkeley - YouTube

Hardware Acceleration for Zero Knowledge Proofs - Paradigm

One sentence for ZK: ZK is a way for a prover to convince a verifier that some statement is true but reveals no additional information except that the statement is true. ZK is designed for anonymity. Imagine that we can prove we have a valid ID without verifiers knowing our real name or ID.

Here is a more vivid example. Alice and Bob are playing Sudoku. Alice would like to show Bob that she found the answer. However, she did not want to reveal any information about the answer since Bob was still working on it. How will you design this proof?

The answer is simple. We write down the Sudoku into cards, facing down. Bob can randomly choose one column, row, or block. Alice takes that column, row, or block of cards and shuffles it. Bob can verify the correctness by checking cards with 1-9. By constantly performing this step, Bob can say that Alice knows the answer, but Bob does not know the answer after the verification.

If you still can’t get the idea, view this video. The UCLA CS professor will explain ZK on five different levels. You will definitely get it.

Before examining the ZK proof systems comprehensively, notice that ZK-SNARK is a name of a class of schemes, and ZK-STARK is the name of a specific scheme.

Let’s start with ZK-SNARK. SNARK stands for Succinct Non-Interactive Arguments of Knowledge. SNARK is unique from other ZK proof systems because of its trust setup phase, what ‘N’ stands for.

• Succinct: The proof size and verification time are smaller than the original computation (statement).

• Non-interactive: The provers and verifiers do not need to communicate back and forth for each round. Instead, the provers and verifiers need to finish the initial setup phase. Even if they miss the setup phase, public verifiers can also join the verification later.

• Arguments: Provers with extremely large computation power can cheat the verifiers by generating wrong proofs. When this happens, the public/private key encryption is also broken.

• Knowledge: The prover needs to know something secret to make the proof.

The problem with ZK-SNARK is the trust setup phase. The trust setup phase generates a reference string. If the reference string is leaked, anyone can make the fake proof. Also, coordinating such a trust setup phase between multiparty is complex. The reference string can only be used in one program (Circuit). Thus it is impossible to have ZK-SNARK with a single trust setup for general computation. Another problem is that the reference string is not upgradable. If we upgrade the program, we need to rerun the trust setup phase.

To solve the problem, there are two approaches:

• Transparent Setup: The trust setup phase sets a CRS (Common Reference String). If the CRS is leaked, the ZK proof systems will not be hurt. Fractal, Halo, SuperSonic and ZK-STARK use this approach. The problem with this approach is that the size of the proofs may be in kBs. This would be too large for the blockchain area.

• Universal Setup: The setup creates a secret reference string, but it is structured. Thus it can be used in not only one program. Marlin, SuperSonic-RSA, and Plonk use this approach.

The following ZK proof systems are commonly used in the industry:

• Groth16: This is used in Zcash. It is fast and has a small proof size and constant verification time, but the trust setup phase needs to run for every program.

• Sonic: Support universal setup. The SRS(Structured reference string) is linear to the size of supported programs. The proofs size is fixed, but the verification is expensive. On the other hand, it makes general computation possible.

• Fractal: Allow recursion. The proof size is big.

• Halo: Support recursion. It is not succinct because verification time is linear. Most ZK application is based on Halo2.

• SuperSonic: The first practical transparent ZK-SNARK.

• Marlin: Structured reference string (SRS); Universal and updatable; Better prover and varication time than Sonic, but slower than Groth16.

• Plonk: Universal setup; Multiparty joins the setup phase sequentially. This makes it easy for many participants to join the trust setup phase; PLONK uses Kate commitments instead of polynomial commitments ( Recall that the first step in ZK-SNARK is to transform computation into a polynomial problem). Plonk is modern and popular today. Lots of ZK proof systems are based on Plonk and they are named Plonkish.

Here is the benchmark based on this research. CRS is common reference string. SRS is structure reference string generated in the trust setup phase. The proof size determines the storage cost in the base layer—the runtime for the prover and verifier influence the computation resource.

You can find more benchmarks in the following research:

• Benchmarking Zero-Knowledge proofs with isekai

• Zero-Knowledge Proofs: STARKs vs SNARKs

• Community Proposal: A Benchmarking Framework for (Zero-Knowledge) Proof Systems

• Comparison of Different zk-SNARKs

A quick wrap-up, if you see a new ZK proof systems, what number should you care about?

• Prover time for 1tx and 10 txs

• Verifier time for 1tx and 10 txs

• Proof size for 1tx and 10 txs

• Trusted setup phase

• Reference string size

• CRS(common reference string) support

• Upgradable

• SRS(structured reference string) support

• Recursion support

• Post-quantum secure

• Cryptography assumptions

ZK has been applicable in recent years. The two main theses of ZK is a rollup, which improves computation efficiency and privacy. For the private thesis, it is intuitive since ZK shares no knowledge with the verifier except the statement itself. The rollup thesis heavily relies on two characteristics of ZK: succinct and recursion. Succinct characteristic helps verifiers save many computation resources instead of rerunning the whole program. Recursion characteristic helps to save storage space. With recursion, the blockchain can keep a fixed size. This is also beneficial for decentralization since the tiny blockchain node does not require high-end hardware.

To develop a ZK application independently, a developer needs the following research and development skills:

• Algorithm and low-level optimizations of arithmetic skills. Developers need this skill to tackle problems in finite field arithmetic, polynomial commitments, and elliptic curve.

• Cryptography knowledge about ZK proof systems like ZK-SNARKs, Plonkish, and trust setup process. Developers need to choose appropriate ZK proof systems and they may need to customize them.

• Circuit programming skills. Developers need to develop constraints for some cryptography primitives like Merkle Trees, and Hash.

• Application and cryptographic protocols development.

Effective development tools can not only speed up the development process but also reduce the complexity. For example, tools like Circom takes care of the low-level algebra and proof systems. Developers can ignore algebra and ZK proof systems, and focus on circuit programming and application development.

The concept of rollup is simple. Since on-chain computation is expansive, rollup puts computation off-chain and only stores the result on a chain.

The state root of the Merkle tree is stored at the rollup contract. The root can be used to verify the existence of the leaves. The smart contract knows how to update the state with the info in batches, and the state root switches to the new state root.

ZK rollup uses ZK proof in batches to verify that the new state root is correct. The ZK proof can be used to verify that after executing txs in batches, we can get the new state root provided in batches. Verifiers can verify the correctness of computations without having to execute them, and verifiers will not even learn what was executed. The characteristic of succinctness helps the ZKRU (ZK rollup) scale-up.

Optimistic Rollup is not as perfect as ZKRU. For example, ORU has fewer TPS and has a longer withdrawal period since it relies on fraud proof. Therefore, some ORUs are integrating ZK into their solution. In this way, they can improve TPS and shorter the withdrawal period. For example, they can add ZK to state transition to create a short fraud-proof time.

There are three roles in rollup:

• User: Users submit txs on Layer2. They deposit assets to Layer2.

• Rollup operator: Rollup operators keep the network running. They generate proof, execute txs, put txs into batches, and challenge fraud proofs.

• Base layer: This layer ensures the security of Layer2 and is where consensus lies. The most common base layer for Layer2 is Ethereum

The most important things for the economy of Layer2 are costs and revenue.

For Layer2, we can break down the cost into the following:

• Proof Cost (for Layer2)

• State Transition

• Base Layer Tx Cost

• Data cost on the base layer

One main cost for the network is data storage. This chart illustrates how data is stored. First, users send data (txs) to rollup operators. Then rollup operators package lots of data (txs) into batches and publish it to the base layer.

This chart illustrates how much are rollups paying for the base layer and their revenue.

The common revenue for Layer2 is fees and MEV values. Fees vary based on the network status, and MEV varies based on users’ txs. Also, Layer2 may issue new tokens. Tokens will be the reward for rollup operators.

This graph shows the status of different Layer2. Arbitrum dominates the whole market.

This graph illustrates different tech used by different chains. Here is a short explanation:

• State Validation

  • Fraud Proofs: Fraud proofs allow whitelisted actors watching the chain to prove that the state is incorrect.

  • ZK proofs (ST): ZK-STARKS are zero-knowledge proofs that ensure state correctness.

  • INT: Interactive proofs (INT) require multiple transactions over time to resolve.

  • SN: Require trust setupExits only: Exits from the network are subject to a period when they can be challenged. The internet network state is left unchecked.

  • 1R: Single round proofs (1R) only require a single transaction to resolve.

• Data availability

  • On chain: All of the data needed for proof construction is published on chain.

  • External DAC: Proof construction relies fully on data that is NOT published on chain. There exists a data availability committee (DAC) that is tasked with protecting and supplying the data.

  • External: Proof construction relies fully on data that is NOT published on chain.

• Upgradability

  • Yes: The code that secures the system can be changed arbitrarily and without notice.

  • 21 day or no delay: There is a 21 days delay unless it is overridden by the 9/15 Security Council multisig.

• Sequencer Failure

  • Transact using L1: The user is able to submit a transaction through L1 and force its inclusion on L2.

  • Force trade/ exit to L1: The user can force the sequencer to include a trade or withdrawal transaction by submitting a request through L1. The user is required to find a counterparty for the trade by out of system means. If the sequencer is down, the user can use the exit hatch to withdraw funds.

  • Force exit to L1: The user can force the sequencer to include their withdrawal transaction by submitting a request through L1. If the sequencer is down, the user can use the exit hatch to withdraw funds.

  • Propose blocks(ZK): The user needs to run their own node and use it to propose new blocks that include otherwise censored transactions. Proposing new blocks requires creating ZK proofs which are very computationally expensive.

  • Exit to L1: The user is only able to submit an L1 withdrawal request . After that, the user exits the system with their funds.

• Validation Failure:

  • Escape hatch(MP): Users are able to trustlessly exit their collateral by submitting a merkle proof of funds. Positions will be closed using the average price from the last batch state update.

  • Propose blocks: The user needs to run their own node and use it to propose new blocks to replace the validator.

Here are the pros and cons listed on Ethhub for ZKRU:

Pros:

• Reduced fees per user transfer.

• Faster than Optimistic Rollup and Plasma.

• Blocks will be computed in a parallel computing model, which encourages decentralization.

• Fewer data contained in each transaction increases the throughput and scalability of layer 2.

• It does not require a fraud game verification like Optimistic Rollup, which can delay withdrawals by up to two weeks.

Cons:

• The difficulty in computing zero-knowledge proof will require data optimization to get maximum throughput.

• The initial setup of ZK rollups promotes a centralized scheme (see Security Considerations).

• The security scheme assumes a level of unverifiable trust.

• Quantum computing poses a threat to hacking the blockchain.

Currently, most available ZK Layer2 only has limited functionality like payment. ZKSync is one payment layer used by Gitcoin. There is also ZK Layer2 with custom VM enabled. These custom VMs are non-EVM compatible, such as (StarkEx + Cairo, zkSync 1.0 + Zinc).

ZKEVM is the next milestone for all ZKRU. There are three levels for ZKEVM solutions:

• Consensus level: At this stage, the ZKEVM is equivalent to EVM on Ethereum. It generates proofs for state roots on Ethereum.

• Bytecode level: The ZK proof systems play a big role in this ZKEVM. In this stage, state roots generated by ZKEVM are not compatible with the Ethereum EVM. This approach is taken by Scroll, Hermez.

• Language level: In this state, there is no real ZKEVM. A transpiler transforms Solidity into ZK-friendly VM that is totally different from EVM. zkSync and Starkware take this approach.

In the Ethereum roadmap, Ethereum will integrate a consensus level ZKEVM.

Justin Drake from EF expects to see a bytecode level ZKEVM, like Hermez or Scroll to deploy in 2022, but with some limitations:

• Small gas limits compare to the current gas limit on Ethereum.

• Centralized provers due to computation difficulty. Users may start to run their provers in 2023 with GPUs and SNARK proving ASIC by 2024. The development of the hardware will change from CPU, GPU, FPGA to ASIC.

• Due to development complexity, there will exist bugs.

To further reduce the cost, some ZKRUs are implementing Volition, changing their base layer. They plan to store the data off-chain or on their chains.

There are 16 ZKRU in the market and 7 of them have released the token. The total market cap is $15B, around 0.67% of the total crypto market.

Polygon currently works on 4 ZK products:

• Miden: Experiment general computation ZKRU with 1k+ tx/sec; 15min withdraws; 5 secs block time; Privacy enabled.

• Nightfall: Nightfall is an ORU with ZK enabled to provide private transactions. Around 9000 gas/tx and 110 TPS. It is designed for Ernst & Young.

• Hermez: EVM compatible ZKRU; 2k TPS. The network is currently live. The average txs per batch is 1. The daily tx number is nearly zero (data from explorer).

• Zero: General Computation ZKRU with recursion enabled; 0.17s to generate proof; 45kb proof size; one account only occupies 5 bits.

zkSync started in Dec 2019. zkSync is a ZKRU built by Matter Labs. It is based on Plonk and the trusted. Currently, it supports payment function and limited smart contract function with customized programming language Zinc.

zkSync 2.0 testnet is live in Feb featured ZKEVM. Matter Labs makes most OPCODE into circuits to achieve EVM compatibility. For now, it does not support ADDMOD, SMOD, MULMOD, EXP, CREATE2, and KECCAK256. In this approach, Solidity will be the first-class citizens.

The gas in zkSync 2.0 will fluctuate based on the current Layer1 gas price (data storage on Layer1 cost) and ZK proof generation costs.

To further improve the TPS and lower the cost, zkSync will launch ZKPorter. Users can choose to store their account data on ZKPorter, which can cost much less than the base layer. If an account is stored on ZK Porter, all its tx can only be stored on ZKPorter. They can not be stored on Ethereum. ZKPorter will be secured by zkSync token holders.

Starkware was started in May 2018 by core team members of Zcash.

Starkware has two solutions: StarkEx, StarkNet.

StarkEx is a SaaS that designs ZKRU for projects like dYdX, DeverseFi, Immutable, Sorare. dYdX is quite successful. Here are some metrics about dYdX. It has around 4k weekly active traders.

StarkNet is the permissionless version. StarkNet is not EVM compatible. It uses Cairo to write smart contracts.

Starkware is also working on ZKEVM. However, they have a different approach. They use Warp to transpile smart contracts written by solidity to Cairo on StarkNet. This approach is not as good as zkSync.

StarkNet alpha with EVM compatible launched in Nov 2021. Currently, the daily transaction number is 1033 (data from Explorer).

Similarly, Starkware is also working on off-chain storage. Users can choose to process their tx on Ethereum or off-chain.

Loopring is a ZKRU DEX featuring low fees for spot trading with 2k TPS.

Loopring released its tokens LRC in 2018. Currently, the market cap of Loopring is $1.3m. Loopring has total 65k users, 167 unique users increment everyday, and 10896 txs everyday (data from explorer).

dYdX is a strong competitor of Loopring. In the future, when ZKEVM becomes popular, there would be more competitors joining this market, because development on ZKEVM is faster than developing a new Layer2 DEX.

Blockchain space has entered the multichain era. Different chains have different concentrations and have their features, not only look good on paper. We see lots of new chains featured with high TPS in the past. Now, these chains have a strong ecosystem and featured apps. Making a new chain with high TPS is easier than before because of the development tools. Thus now we emphasize more on featured apps, not paper numbers.

Moonbeam is such a good example. It has some kind of similar base layer Polkadot and high TPS. This looks similar to most Layer2. Before launch, moonbeam collaborated with lots of projects, like sushi. It launches with a complete ecosystem like top-tier DEX, Lending, and bridges but lacks concentration and featured apps.

Thus layer2 needs to have features to compete with other chains with high TPS. There would be several potential opportunities in layer2 ecosystems:

1. Apps that utilize high throughput and lower fees of Layer2. One example is dYdX. As a DEX, it offers CEX like experience.

2. Since all Layer2 use the same base layer, it would be safer to construct cross-layer2 apps. For example, aggregate the fragmented liquidity between layer2. Starkware proposes dAMM to solve this. dAMM allows layer1 LPs to expose to layer2 traders.

3. Development kit to help developers quickly construct app-specific layer2. This may look like Cosmos SDK and Substrate from Polkadot. The idea is that if an app grows bigger, it will consume more resources on the base layer. To reduce computation cost, it either builds its chain, moves to layer2, or builds its layer2. We see Axie Infinity face the same problem. At that time, building its chain was the only solution. However, a separated chain is isolated and cannot benefit from the base layer ecosystem. Migrating to layer2 looks good, but it is not flexible. The app faces the same constraint as in the base layer. Thus the most promising solution is having its layer2. If the cross-layer2 is convenient and integrated well with the base layer, the app does not lose anything from moving away from the base layer.

4. Better integration with the base layer. Users don’t feel any difference between layer2 and the base layer. This includes asset bridges and protocol communication.

5. Different kinds of VM. More powerful ZKEVM or ZKWASM.

6. Layer2 on other chains. Different chains have different concentrations. A ZKRU is also promising to them. ZK Link team has implemented Groth16 in Solana. Solana focuses on onboarding traditional finance institutions. These institutions need ZK to protect their customer's privacy.

7. ZK bridge. Almost all the bridges are not trustless. We at least need to trust someone, like an oracle, to network participants. Although network participants have deposits, it is hard to calculate the slashing condition. The ideal trustless bridge is the ZK bridge. The light client captures the block and generates the proof. In this way, we don’t need to trust what the oracle says. We can verify the proof with a small cost due to SNARKs. The current problem is how to build a block verifier in the ZK circuit. Also, the extensibility sucks. The light client is coupled with blockchain consensus. Thus developers need to build different circuits for different chains.

8. Commercialize ZK algorithm. There are many commercialized algorithms for professional problems, like advanced solvers for linear programming and GPT-3 from Microsoft. However, if ZK is highly professional and only selected developers can do this, there is room for a commercialized algorithm. Currently, most ZK practitioners are highly educated and hold a Ph.D. degree in CS, Math, or Cryptography.

9. Chips and cloud computation. If more users move to ZKRU, there would be a growing demand for computation power. Node operators need more computation power to compete for packaging transactions, which is profitable. In the Ethereum roadmap, Ethereum will integrate ZKEVM, which means Ethereum miners also need to compute ZK proofs. Dedicated chips can give node operators more computation power and lower power consumption. Cloud computations can give more users to access ZKRU node operations. This growing demand for dedicated chips and cloud computation may look similar to what we see in the Ethereum mining industry. Miners first use CPU and GPU. Then they change to dedicated FPGA and ASIC. Cloud mining has existed in Ethereum and Bitcoin mining industry for a long time. Another example is AI chips. Now every iPhone has dedicated AI chips. If ZK is the new standard tech for privacy, there will be SNARK ASICs for every iPhone.

10. Recursion enabled ZKRU. Blockchain needs to balance security, decentralization, and TPS. Size plays a big role here. In traditional blockchains, bigger size means centralization, because the node requires advanced hardware. However, smaller size means lower TPS. It is hard to balance TPS and decentralization. Now recursion will change this. Recursion can minimize the blockchain size without harming TPS.

ZK has already been used in lots of privacy projects. For example, Tornado cash, Zcash, dark forest.

There are three stages for privacy projects:

1. Transaction privacy: Users can hide their txs

2. General computation privacy: Currently all the computation process on Ethereum is public. Anyone can see the inputs, outputs, and state transition.

3. Function privacy: Sometimes functions’ names leak info. For example, mint() often means mint tokens.

The total market cap of the private sector is around $10B, around 0.45% of the total crypto market. The daily trading volume is around $1B.

Tornado Cash is a smart contract-based privacy transaction tool. It is used to hide the cash flow. It now supports Ethereum, BSC, Polygon, Optimism, Arbitrum, Gnosis, and Avalanche.

It achieves privacy for the sake of usability. Deposit, wait and withdraw, the user can get the clean money.

ZK is used in users’ deposit and withdrawal processes.

Zcash is a blockchain that use zk-SNARK to achieve private transactions. Unlike Tornado Cash, Zcash customize the blockchain to achieve privacy transaction.

Zecrey is a privacy payment application supporting Ethereum, Polygon, BSC, Near, and Avalanche. It is on the first level of privacy, transaction privacy. Zecrey offers a browser wallet to help users privately transfer and swap tokens. To swap and transfer privately, users need to deposit tokens into Zecrey layer2, powered by Plonk. Everything that happens in layer2 can be private. Zecrey layer2 also supports cross-chain swap.

Currently, Zecrey has around 10 txs everyday (data from explorer)

Suterusu is a private payment application supporint Ethereum, BSC, Fantom, and Polygon. It uses layer2 to protect users’ transaction privacy. It also has a cross-chain bridge, which transfers $SUTER between ETH and BSC.

Suterusu has total 15k users and 24k deposits. The user increment stagnates. Its market cap is around $10m.

Dark Forest is an MMO. Players need to send energy to other planets to occupy them. The location of planets is kept secret. Players need to find these planets themselves (hash collision). The ZK is used to prove locations related operations:

• Planet Initialization

• Planet resources movement

In v0.6 round 1, 1700 players joined the game, and 700 got the next round. During this round, players made 2 million txs, spending around 1.5 trillion gas. Suppose it is on Ethereum, with an 80 gas fee. So the total gas will cost 120 ETH.

The stealth airdrop allows users to get airdrop anonymously. The user first uses their airdrop wallet to generate proof. Then they can use other wallets to get the airdrop token with the proof.

A16z also implements something similar a16z/zkp-merkle-airdrop-contracts (github.com).

This example shows the application of ZK in voting.

This project is on ETHDanver. Users can generate ZK proof to show that they have a buffiness without revealing anything about themselves other than the user’s Buffiness.

This is an application of ZK in Identity.

1. Small privacy market. Privacy projects started very early. Zcash started in 2016. However, the whole privacy market only takes 0.45% of the total crypto market.

2. Benefit from higher privacy standards. Users are pursuing stronger privacy protections without sacrificing usability. Especially in the mobile phone industry, Google and Apple are pushing stricter privacy standards. EU proposes regulations to protect consumers’ privacy. Infrastructure companies like let’s encrypt which offer SSL certificates benefit from this. In the future, ZK may be adopted by these giant companies and there would be huge opportunities for ZK infrastructures.

3. A must for onboard institutions. Big institutions have the responsibility to protect customers’ privacy and some blockchains are trying to onboard these big institutions. ZK will be a must for this scenario.

4. Benefit DAO governance and Identity. Anonymity is an important aspect of democratic governance. ZK can empower privacy preserved governance and let participants make their own decisions without distracting by others’ decisions. Identity can also benefit from privacy. Users can reveal their identity without showing their actual address.

5. Ignore ZK, focus on product usability. ZK can better protect privacy, but a product is not all about ZK. ZK is more tech focus and we need to emphasize the usability of the product. Normally more privacy means bad usability, but usability is the most crucial compatibility. Thus focus more on usability, market, and the team.

ZKRepel appeared in GR13 and got $5k. This is an online playground for ZK circuits. Developers can quickly write and test circuits in ZKRepel without setting local development environments. It is similar to Remix.

We see a paradigm shift from local development to cloud-based development. There are famous products like Codesandbox, Codepen, Codespaces. With these products, developers can continuously work anywhere anytime and set up a new development environment quickly. Development environment as infrastructure is a big trend today. This is proposed by Github, and Github practiced it with Codespaces.

There are no clear statistics about ZK developers. However, from the data on Github, it is over 500x less than solidity developers.

There are VCs or grants there focusing on ZK projects:

• ZKTech Gitcoin Grants: The first round matched $100k among 19 projects.

• 0xPARC Grants: Supporting application level innovation on Ethereum and other decentralized platforms.

• zkDAO: Newly launched $200M backed by zkSync and BitDAO to support zkSync ecosystem. 7.5% of $200M will be used in grants.

• Polygon ZK Fund

• Aztec Grants: Current focus on bridges, tooling, and analytics.

• Harmony ZK Fund: $10M fund for ZK and privacy research.

• ZK Validator: Fund focusing on ZK. Featured investments are Aztec, Penumbra, Ironfish, Anoma, zkSync, Aleo, Diversfi

• ZPrice from Aleo

ZK is a really promising technology that can bring impossible things to possible. In recent years, there have been lots of breakthroughs happening here. These breakthroughs like stronger performance, upgradability and no need for trust setup push ZK to the applied stage. So if we are going to look at a ZK project, we need to care about these theoretical numbers:

• Prover time

• Verifier time

• Proof size

• Trusted setup phase

• Reference String Size

• CRS(common reference string) support

• Upgradable SRS(structured reference string) support

• Recursion Support

• Post-quantum Secure

• Cryptography assumptions

ZKEVM is the next milestone for ZKRU. There are three stages for ZKEVM:

• Consensus level

• Bytecode level

• Language level

ZK just enters the applied stage. The ecosystem is still empty. Not every characteristic of ZK is well used and applied to new products. People can still get inspiration from this cutting-edge theory. The following direction can best be beneficial from ZK tech:

• Apps that need high TPS and lower fee

• Cross Layer2 communication protocol/apps

• Aggregate fragment liquidity in Layer2

• Development kit/framework

• Cloud-based development tools

• Cross Layer2 Layer1 apps with unique features

• Different zkVM

• ZK Bridge

• Applied ZK on other chains

• Layer2 with recursion enabled

• ZK in DAO and community governance

• Commercialize ZK algorithm

• Chips and cloud computation

• Recursion in ZKRU

There are two main theses for applying ZK: Rollup and Privacy. Rollup is more promising than privacy. Privacy does not make sense because it is designed to be transparent. The privacy culture is somewhere against the transparent spirit. Also, privacy may have compliance problems. In Web2 era, we do not see the prosperity of privacy apps. In the same category, the top product does not heavily focus on privacy, although more and more institutions have improved their privacy protections. Privacy does have a tradeoff. Most of the time is availability, which is the key to users.

When looking at ZK applications, the following points are important:

• ZK is a fancy term. Without ZK, is the real product still competitive and has good UX.

• ZK is complex and does an extra burden on the development speed.

• ZK benefits DAO governance and identity

• ZK will help institutions onboard the blockchain

Learn more

If you would like to learn more about building a ZK project, check out this tutorial and Awesome-zk. Also, keep an eye on this.

I worked as a tech associate for Fundamental Lab. You can find me on Twitter here and Fundamental Lab here.

An Incomplete Guide to Rollups

The ultimate guide to L2s on Ethereum

Understanding rollup economics from first principles

Ethereum Rollup Call Data Pricing Analysis - Research

How to fund your ZK Project?

zkSNARKs in a nutshell

ZK-STARKs

Understanding PLONK

Introduction to zk-SNARKS

Comparing General Purpose zk-SNARKs

Zero-Knowledge Proofs: STARKs vs SNARKs

Comparison of Different zk-SNARKs

Compare zk-SNARKs in practice

Episode 221: Funding the Next Wave of Zero Knowledge Tech

How Zero Knowledge Proofs Are Changing Blockchain (in non-technical terms)

[AMA] We are the EF's Research Team (Pt. 7: 07 January, 2022) : ethereum

https://blog.matter-labs.io/zksync-2-0-hello-ethereum-ca48588de179

ZK Tutorial: An Introduction to SNARK Development with arkworks - Pratyush Mishra - YouTube

'Introduction to Zero Knowledge Proofs' - Elena Nadolinski - YouTube