August, 2022

This report includes key analysis of research, articles and project updates in zero knowledge proof technology.

1、Research

(1)<Piranha: A GPU Platform for Secure Computation>

Secure multi-party computation (MPC) is an essential tool for privacy-preserving machine learning (ML). However, secure training of large-scale ML models currently requires a prohibitively long time to complete. Given that large ML inference and training tasks in the plaintext setting are significantly accelerated by Graphical Processing Units (GPUs), this raises the natural question: can secure MPC leverage GPU acceleration? A few recent works have studied this question in the context of accelerating specific components or protocols, but do not provide a general-purpose solution. Consequently, MPC developers must be both experts in cryptographic protocol design and proficient at low-level GPU kernel development to achieve good performance on any new protocol implementation.

We present Piranha, a general-purpose, modular platform for accelerating secret sharing-based MPC protocols using GPUs. Piranha allows the MPC community to easily leverage the benefits of a GPU without requiring GPU expertise. Piranha contributes a three-layer architecture: (1) a device layer that can independently accelerate secret-sharing protocols by providing integer-based kernels absent in current general-purpose GPU libraries, (2) a modular protocol layer that allows developers to maximize utility of limited GPU memory with in-place computation and iterator-based support for non-standard memory access patterns, and (3) an application layer that allows applications to remain completely agnostic to the underlying protocols they use.

On the device layer, we contribute low-level GPU kernels accelerating local, integer-based data shares. At the protocol layer, we implement functionality for three different linear secret-sharing (LSSS) MPC protocols at the protocol layer: SecureML [60] (2-party), Falcon [88] (3-party), and FantasticFour [23] (4-party). At Piranha’s application layer, we provide a protocol-agnostic neural network library that can be executed by any of the protocols. Piranha is modular in that it can support additional components beyond what we provide. To demonstrate the benefits of Piranha, we implement 3 state-of-the-art linear secret sharing MPC protocols for secure NN training: 2-party SecureML (IEEE S&P ’17), 3- party Falcon (PETS ’21), and 4-party FantasticFour (USENIX Security ’21). Compared to their CPU-based implementations, the same protocols implemented on top of Piranha’s protocol-agnostic acceleration exhibit a 16−48× decrease in training time. For the first time, Piranha demonstrates the feasibility of training a realistic neural network (e.g. VGG), end-to-end, using MPC in a little over one day. Piranha is open source and available at https://github.com/ucbrise/piranha.

(2) <Nirvana: Instant and Anonymous Payment-Guarantees>

Abstract: Given the high transaction confirmation latencies in public blockchains, cryptocurrencies such as Bitcoin, Ethereum, etc. are not yet suitable to support real-time services such as transactions on retail markets. There are several solutions to address this latency problem, with layer-2 solutions being the most promising ones. Existing layer-2 solutions, however, suffer from privacy and/or collateral issues when applied to retail environments where customer-merchant relationships are usually ephemeral. In this paper, we propose Nirvana, that can be combined with existing cryptocurrencies to provide instant, anonymous and unlinkable payment guarantees. Nirvana does not require any trusted third party. It conceals the identities of honest participants, thus ensuring customer anonymity within the system while only relying on efficient Groth-Sahai proof systems. We introduce a novel randomness-reusable threshold encryption that mitigates double-spending by revealing the identities of malicious users. We formally prove how our scheme provides customer anonymity, unlinkability of transactions and payment guarantees to merchants. Our experiments demonstrate that Nirvana allows for fast (zero-confirmation) global payments in a retail setting with a delay of less than ∼ 1.7 seconds.

1）Protocol overview

In order to explain Nirvana protocol, we assume that the set of authorities is already established and the merchants in the network have registered and formed a consortium. As illustrated in Figure 3, the protocol between a customer and a merchant proceeds as follows:

①In order to avail the services of Nirvana, the new customer begins by registering themselves with the majority of authorities.

②After successfully registering in the network, the customer deposits a collateral in Nirvana’s smart contract.

③Once the deposit is confirmed on the blockchain where Nirvana’s smart contract is deployed, the customer asks for a collateral certification, which is necessary to prove that the customer owns some collateral in Nirvana. This proof is used to generate payment guarantees for merchants.

④Upon receiving the certification request of the customer, the authorities check the smart contract to confirm if the customer deposited a collateral.

⑤Once confirmed, the authorities provide the customer with a signed certificate of their collateral’s existence in the network. Along with this confirmation, the customer is also assigned a signed list of witnesses in charge of tracking the collateral usage.

⑥During a transaction in the retail market, the customer makes a payment to the target merchant using the cryptocurrency of their choice. Once the payment is in pending state on the blockchain, the customer generates a payment guarantee by using the certified collateral and sends this to the target merchant along with the assigned list of witnesses and the transaction hash of their cryptocurrency payment.

⑦ The target merchant forwards this payment guarantee to the assigned witnesses who individually confirm that they have not seen a similar guarantee in the current epoch.

⑧Upon confirmation, each witness returns a signed payment guarantee to the merchant.

⑨On receiving signed payment guarantees from a majority of the witnesses, the merchant aggregates these signatures and accepts the payment guarantee and provides the customer with necessary services/products.

2) Performance Analysis

In this section, we demonstrate the performance of Nirvana. Based on the application, the costs incurred in each phase are divided into two parts, termed “offline phase” and “online phase”. The former includes the parameter generation, key generation and registration functions. The latter is solely responsible for spending and verification and is the main focus of this evaluation.

We implemented Nirvana by using the Charm-Crypto framework [AGM+13], a Python library for Pairing-based Cryptography and obtained the benchmarks on four AWS EC2 instances.

As can be seen in Tab. 1, we ran three sets of experiments, with the following location configurations:

①Nirvana located in Singapore, customer in California, merchant in Frankfurt and witnesses in London.

②Nirvana located in Singapore, customer in Frankfurt, merchant in London and witnesses in California.

③Nirvana located in Frankfurt, customer in London, merchant in California and witnesses in Singapore.

For the sake of convenience, during our implementation, we assumed that all witnesses are located in the same location. However, placing the witnesses in different locations would only add a small delay based on their distance from the merchant; in order to reflect this delay, we do sequential witness verification instead of parallel verification.

All our EC2 instances had the same computational configuration, i.e., an Ubuntu Server 20.04 LTS (HVM) with an Intel (R) Xeon(R) CPU @ 2.50 GHz and 16 GB of memory. We apply the Barreto-Naehrig (BN254) curve (also known as type F groups), 𝑦 2 = 𝑥 3 + 𝑏 with embedding curve degree 12 [BN06]. In this pairing group, the base field order is 256 bits. Based on our Python code¹ , the overhead of the spending and verification algorithm is summarized in Fig. 4.

Latency: Fig. 4 shows the almost constant relationship between the total number of witnesses for each collateral and their spending time. With spending time, we capture the Spend functionality in Algo. 1, where the customer generates the payment ciphertext and NIZK proofs to provide a payment guarantee to the merchant. It also includes the time required to send the payment guarantee to a merchant located in either of the locations in Tab. 1. As can be seen, the time required to generate a payment guarantee in Nirvana for merchants in Scenario 1 and 3 is almost identical because the distance between the customer and merchant in both scenarios is roughly the same (i.e., California to Frankfurt and London to California). The effect of distance is also reflected in Scenario 2 when the customer is in Frankfurt and the merchant is in London, with each payment guarantee only taking 350 ms on average to be spent as compared to ∼ 900 ms in the other two cases.

Fig. 4 shows the linear relationship between the total number of witnesses for each collateral and the verification time required by a merchant and witnesses. With verification time, we capture the 𝑉𝑓 functionality in Algo. 1, where the merchant verifies the NIZK proofs provided by the customer as a payment guarantee and waits for a majority of the witnesses to approve that this guarantee is unique. It also includes the time required to receive these proofs from the customer located in either location in Tab. 1. As can be seen, the time required to verify a payment guarantee in Nirvana for merchants located in all locations grows linearly with a total number of witnesses, with verification only requiring 990 ms on average in Scenario 1 with two witnesses and 1.3 s on average with 6 witnesses. This is due to the requirement of each individual witness to check their local storage for these guarantees, sign the guarantee if it is unique and finally send the signed guarantee to the merchant. Similar to spending, the distance between countries also effects the time taken to verify each payment guarantee. In scenario 1 of Tab. 1, the merchant and witnesses are located nearby, hence the verification only takes 990 ms when each collateral is assigned to two witnesses as compared to ∼ 1.25 s for both scenario 2 and 3. This is because of the latency incurred due to the geographical distance between, e.g., California and London.

Smart contract cost: Tab. 2 provides USD equivalents of the cost of executing functions (such as registration, etc.) on Nirvana’s smart contract. Since our smart contract can be deployed on any Ethereum Virtual Machine (EVM) supporting blockchain, we calculated the costs on both Ethereum (high Gas fees) and Celo (low Gas fees) using the current conversion rates and a Gas price (Gwei) of 27 for Ethereum and 2.42 for Celo.² As can be seen in Tab. 2, one-time registration of a customer costs them 107 400 Gas or $7.37 on Ethereum and $0.67 on Celo. This Gas cost is a bit high due to the requirement for customers to store a secret to enable victim merchants to redeem their collateral on the smart contract. However, this cost goes down for merchant registration since merchants do not need to store a secret to redeem their collaterals, hence only costing 54 317 Gas or $3.73 on Ethereum and $0.34 on Celo. In case a victim merchant wants to claim a malicious customer’s collateral, it costs them 34 972 Gas or $2.40 on Ethereum and $0.22 on Celo. Finally, if a merchant or customer want to withdraw their money from Nirvana’s smart contract, it costs them 22 525 Gas or $1.55 on Ethereum and $0.14 on Celo.

We acknowledge that Nirvana is not cost efficient when used on Ethereum; however, it is important to note that with the current ETH 2.0 roadmap³ , efforts are being made to lower the Gas fees on Ethereum and eventually make it more usable for Nirvana. More information on the functionality of Nirvana’s smart contract can be found in App. D.

(3)< zk-creds: Flexible Anonymous Credentials from zkSNARKs and Existing Identity Infrastructure >

Abstract: Frequently, users on the web need to show that they are, for example, not a robot, old enough to access an age restricted video, or eligible to download an ebook from their local public library without being tracked. Anonymous credentials were developed to address these concerns. However, existing schemes do not handle the realities of deployment or the complexities of real world identity. Instead, they make (often incorrect) assumptions, e.g., that the local department of motor vehicles will issue sophisticated cryptographic tokens to show users are over 18. In reality, there are multiple trust sources for a given identity attribute, their credentials have distinctively different formats, and many, if not all, issuers are unwilling to adopt new protocols.

We present and build zk-creds, a protocol that uses general-purpose zero-knowledge proofs to 1) remove the need for credential issuers to hold signing keys: credentials can be issued via a transparency log, Byzantine system, or even a blockchain; 2) convert existing identity documents into anonymous credentials without modifying documents or coordinating with their issuing authority; 3) allow for flexible, composable, and complex identity statements over multiple credentials. Concretely, identity assertions using zk-creds take less than 300ms in a real-world scenario of using a passport to anonymously access age-restricted videos.

2、Articles

(1) Aleo to test Virtual Machine ahead of mainnet launch

Layer 1 blockchain Aleo will launch the Aleo Virtual Machine (AVM), a computational platform to run privacy-focused apps on its network, as it looks to attract developers to its ecosystem. While Aleo is still in the testnet phase, next week it will introduce the AVM as part of its upcoming “testnet 3” launch scheduled between August and October. According to a note shared with The Block, the team sees the testnet as an opportunity to onboard new Aleo developers ahead of its mainnet launch in the fourth quarter of 2022. “Our focus is to build the absolute best developer framework for decentralized private applications,” Aleo co-founder and CEO Howard Wu said on the testnet 3 plan. The testnet is incentivized and will reward developers with token incentives for running applications. Similarly, it will also allocate bounty rewards for bug hunters during the testnet period.

(2) ZK in Identity

The beauty of ZKPs is that virtually any statement that you can think of can be proved in zero-knowledge (to be precise, any relation that can be verified in polynomial time can also be proved in zero-knowledge; stronger results are also known). While the non-interactive version of ZKPs are most suited to address confidentiality, privacy, state-growth, integrity, etc. issues on L1s, interactive proofs may make a lot of sense for many applications where blockchain-based identity assertions are needed.

The concert admission example above can be used to illustrate the point. There would just be one well-identified verifier for the ZK membership proof of NFT ownership (organizers of the concert who could very well choose to verify off-chain), as opposed to the hundreds or thousands of unidentified verifiers in a typical L1 setting. A prover can actively engage with the verifier and exchange several messages over the course of a session, breaking free of the inherent complexity trade-offs of non-interactive ZK proofs. Indeed, proofs don’t have to be short or the verifier complexity low, so the spectrum of ZK proofs beyond ZK-SNARKs (most popular kind of non-interactive proof system, which also has succinct proofs) can be fully explored. We would be able to make use of proof systems with much better prover complexity, underlying security assumptions, etc.

Please see the table below for a high-level comparison of different proof systems. As we go down the table, prover complexity and security assumptions get better while the proof size gets worse. While MPC-based ZK proof systems offer the best prover complexity and don’t need a trusted set-up, proofs are interactive and work for a specific verifier only (the one a prover interacts with), which may not be a problem when identity assertions have to be made to a specific party off-chain. (Several other characteristics of ZK proof systems like post-quantum security are not captured in the table.)

To conclude, identities in the world don’t have to be either blockchain-based or nonblockchain-based. Going forward, they can certainly be a combination of the two — and that would make privacy-preserving identity assertions even more interesting!

(3) Ethereum’s Rollup Race: What is a ‘True’ zkEVM?

1)EVM-equivalent vs. EVM-compatible

Polygon faced criticism last week when it announced that it would be launching the first EVM-equivalent ZK rollup to market. According to some onlookers, Polygon’s solution would be better described as EVM-compatible, not EVM-equivalent. So what is the difference between compatibility and equivalence?

The two leading Optimistic rollups for Ethereum, Artbitrum and Optimism, boast that they are EVM-equivalent. This means that the experience of developing on Arbitrum and Optimism is 100% identical to the experience of developing on Ethereum; developers have access to all of the same tools and frameworks that they use to develop on the Ethereum mainnet, and they won’t need to worry about their layer 1 contracts breaking if they are directly ported over to a layer 2 chain.

EVM-equivalence is a massive deal to developers since it means far less overhead when migrating from layer 1 to layer 2.

Users, too, see the benefits of EVM-equivalence. Rather than juggling rollup-specific wallets or other tools, users of EVM-equivalent chains, such as Optimism and Arbitrum, won’t need to abandon familiar apps like Metamask.

EVM-compatibility is a looser definition than EVM-equivalence. Rather than the developer and user experiences being exactly identical to that of Ethereum, EVM-compatible chains might not plug in to all of the same tools and software frameworks that are used on Ethereum.

Developers might need to rewrite their smart contracts in order to port them over to an EVM-compatible blockchain — sometimes in a completely different programming language than Ethereum’s native language, Solidity. Even if developers are still able to write their smart contracts using Solidity, certain operations might not be fully supported by the rollup, which can lead to bugs or other engineering headaches. Although users might be able to send assets back and forth between the EVMcompatible rollup and Ethereum, doing so might require a specialized wallet rather than Metamask.

2) Is Polygon EVM-equivalent?

When Polygon announced that it would be bringing the first EVM-equivalent zkEVM to market last week, some onlookers pointed out that the specifications provided by Polygon would be better described as EVM-compatible, not EVM-equivalent.

In a June Twitter thread, Scroll’s Luozhu Zhang described three different types of zkEVMs: bytecode level, language level and consensus level. All of the applications announced last week fall into the first two categories.

zkSync 2.0 falls into the language-level bucket. Developers can write smart contracts in Solidity, but zkSync will transpile that code into another language called Yul behind the scenes, which it then interprets in order to do all of the fancy cryptography that powers the zero-knowledge rollup under the hood. On the plus side, Matter Labs, the team behind zkSync, says that its system was engineered to provide the rollup certain advantages — particularly around how it generates computation-intensive cryptographic proofs.

On the negative end, zkSync, by most definitions, would be better described as EVM-compatible rather than EVM-equivalent. There’s a chance that zkSync won’t be 1:1 compatible with every single Ethereum tool out there, though Matter Labs insists that this shouldn’t be an issue in the long term.

Scroll and Polygon are both taking a bytecode-level approach to their zkEVMs. These approaches rip out the transpiler step completely, meaning they don’t convert Solidity code into a separate language before it gets compiled and interpreted. This means better compatibility with the EVM. But even here, there are distinctions that may make Scroll more of a “true” zkEVM than Polygon, depending upon who you ask.

As Messari explained in a report released last week, “part of the [‘true’ EVM] debate follows whether the EVM bytecode is being executed directly or interpreted first and then executed. In other words, if a solution does not mirror official EVM specs, it cannot be considered a true zkEVM. Within this definition, Scroll might be considered a ‘true zkEVM’ vs. the others.” According to Messari, “Polygon uses a new set of assembly codes to express each opcode, the human-readable translation of bytecode, which could allow the behavior of the code to be different on the EVM.” In other words, Polygon might be a bit further from EVM equivalence than its main bytecode competitor, Scroll. Yet Polygon will argue that it’s precisely these differences that will allow it to provide a better product than its competitors.

3、Project Updates

(1) Mina Ecosystem Updates — July 2022 | Mina Blog

1)Improving Node Stability

The latest beta release 1.3.2beta1 has been out for almost a month and is being tested on devnet. The last stable release, 1.3.1, has been running smoothly on Mainnet for well over two months. We’ve been focused on shipping performance improvements and addressing outstanding issues. We hope to promote 1.3.2 to stable in the coming weeks.

2) Berkeley QA Network

The Berkeley QA Network is ongoing and the QA task force is diligently participating and helping to address issues that occur. In the past month, we’ve redeployed the Berkeley QA Network and with the help of the community, found an issue. As a result, there has been some operational downtime on the QANet; however, O(1) engineers have identified the root cause and are working to roll out the fix. If you would like to participate in the QA network please chime in on the #devnet channel on Discord. We plan to make a few more redeployments to the QA network in the coming weeks so look out for more enhancements and fixes.

3) zkApp Protocol Readiness

O(1) Labs has worked on implementing key zkApp protocol features such as support for tokens, supporting zkApp events & sequence events, and zkApp composability (one zkApp calling another.) As we near feature completion, we are working on finalizing the acceptance criteria for each aspect of the protocol. The O(1) Labs engineering and testing teams have created a suite of acceptance tests and are writing test cases using sample zkApps.

4) SnarkyJS & zkApps

zkApp proving performance is now 200%-1,000% faster for non-recursive use cases! The O(1) Labs’ engineering team recently added support for preconditions, recursion, and events to SnarkyJS. Preconditions are available now; recursion & events will appear in the next release of SnarkyJS. Developers will be able to make use of these features on Berkeley Testnet. We’re currently writing documentation for these to be published on docs.minaprotocol.com in the coming weeks. Follow the new SnarkyJS changelog to see detailed updates as they occur.

5) Proof Systems

While a draft Rust API for Kimchi was released some time in June via the proofsystems repo, the decision was made to restructure the API to align the interfaces with the proven Snarky (oCaml) circuit writing API, which is used throughout the Mina protocol. While this change will delay the release of an API for Kimchi, it will improve the maintainability and will result in a cleaner transition to future Rust versions of Pickles and Snarky.

6) zkOracles

We’re thrilled to have welcomed a very talented Rust engineer with a background in MPC research who will be leading the implementation on zkOracles. In his first few weeks onboarding and ramping up on the project he has identified a few potential optimizations. We’ll continue to iterate on the design for zkOracles and look forward to beginning implementation work in the near future. In the meantime, the SnarkyJS team is working on an alternative oracle approach for developers to consume data from external sources within a zkApp in the near term.

(2) Announcing the Scroll pre-alpha testnet | Scroll Blog

1)What’s in the pre-alpha testnet?

This initial release will be run on a private PoA fork of Ethereum (the testnet L1) operated by Scroll. On top of this private chain, we will run a testnet Scroll L2 supporting the following features:

⚫ Users will be able to play with a few key demo applications such as a Uniswap fork with familiar web interfaces such as Metamask.

⚫ Users will be able to view the state of the Scroll testnet via block explorers.

⚫ Scroll will run a node that supports unlimited read operations (e.g. getting the state of accounts) and user-initiated transactions involving interactions with the predeployed demo applications (e.g. transfers of ERC-20 tokens or swaps of tokens).

⚫ Rollers will generate and aggregate validity proofs for part of the zkEVM circuits to ensure a stable release. In the next testnet phase, we will ramp up this set of zkEVM circuits.

⚫ Bridging assets between these testnet L1 and L2s will be enabled through a smart contract bridge, though arbitrary message passing will not be supported in this release. Scroll’s pre-alpha testnet will be the first chance for early users and developers to interact with our infrastructure and experience dapp workflows on Scroll. As we scale our node infrastructure, we will relax some of the performance-motivated restrictions and onboard more testers.

2) What’s next for Scroll?

Soon after our pre-alpha testnet, we will be deploying a more open and permissionless alpha testnet. This will be deployed on a public Ethereum testnet and will be open to the public. In particular, our community can expect the following features:

⚫ Allowing developers to deploy smart contracts

⚫ Allowing anyone to run an archival Scroll node

⚫ Generating and aggregating more pieces of the zkEVM proof to be verified on-chain

As we move step by step towards an eventual mainnet release, we will enable successively more pieces of our final architecture, including a decentralized Roller network and integrations with EVM-native developer tools. In the next few weeks, we will release a series of expository articles and posts explaining Scroll’s architecture and the technical vision that has informed Scroll’s development decisions. Stay tuned to learn more about these!

3) Scroll’s Release Philosophy

Scroll’s plan for scaling Ethereum and serving billions of users and developers is a long-term roadmap that requires careful consideration and execution. We firmly believe in the future of the zkEVM as a key to scaling Ethereum, and as such, are committed to releasing it in a way that allows us to work through any challenges in a focused manner and incorporate feedback alongside our roadmap. By giving users, developers and the broader community progressively more functionality to test instead of releasing all features at once, we aim to isolate any bugs and UX difficulties early and often, allowing us to build towards the most robust, scalable solution that will stand the test of time.

(3) 100 Days to Mainnet | Matter Labs

The features of zkSync 2.0:

⚫ zkSync is EVM and web3 compatible.

⚫ We support Solidity and Vyper: no security re-audit required.

⚫ Porting is effortless: 99% of tooling will work out of the box.

⚫ With zkSync your project will inherit the full security of Ethereum.

⚫ You will benefit from more transactions per second and lower gas fees.

⚫ Build on zkSync 2.0 now and be permanently future-proof.

¹ https://github.com/NirvanaPayments/Nirvana.

² https://ethgasstation.info/, https://explorer.bitquery.io/celo_rc1/gas.

³ https://ethereum.org/en/eth2/.

⁴ The table should only be used for some basic guidance and not to make any serious product/business decisions. Within a category itself, ZK systems could have different characteristics and can vary in performance quite a bit. The table is also NOT meant to capture all ZK systems but just some subset of them for illustrative purposes. We apologize for any glaring omissions.

References：

（1）https://eprint.iacr.org/2022/892

（2）https://eprint.iacr.org/2022/872

（3）https://eprint.iacr.org/2022/878

（4）https://www.theblock.co/post/160545/aleo-to-test-virtual-machine-ahead-ofmainnet-launch

（5）https://medium.com/delendum/zk-in-identity-980493401d80

（6）https://www.coindesk.com/tech/2022/07/27/ethereums-rollup-race-what-is-atrue-zkevm/

（7）https://minaprotocol.com/blog/ecosystem-updates-july-2022

（8）https://scroll.mirror.xyz/XQyXDgyxoefag6hcBgGJFz8qrb10rmSU-zUBvY3Q9_A

（9）https://blog.matter-labs.io/100-days-to-mainnet-6f230893bd73

Written by Felix@StratifiedCapital

July, 2022

This report includes key analysis of research, Guides and Resources and project updates in zero knowledge proof technology.

1、Research

(1) <Curve Trees : Practical and Transparent Zero-Knowledge Accumulators>

In this work we propose a new accumulator construction and efficient ways to prove knowledge of some element in a set without leaking anything about the element. This problem arises in several applications including privacy-preserving distributed ledgers (e.g., Zcash) and anonymous credentials. Our approaches do not require a trusted setup and significantly improve on the efficiency state of the of the art.

We introduce new techniques inspired by commit-and-prove techniques and combine shallow Merkle trees, 2-cycles of elliptic curves to obtain constructions that are highly practical. Our basic construction — which we dub — is completely transparent (does not require a trusted setup) and is based on simple standard assumptions (DLOG and Random Oracle Model). It has small proofs and commitments and very efficient proving and verification time.

Curve trees can be instantiated to be efficient in practice: the commitment to a set (accumulator) is 256 bits for any set size; for a set of size a proof is approximately 2KB, a verifier runs inms (easily parallelizable to ms) and a prover in s on an ordinary laptop.

Using our construction as a building block we can construct a simple and concretely efficient anonymous cryptocurrency with full anonymity set.

We estimate the verification time to be ms (and trivially parallelizable to run in ms) or ms when batch-verifying multiple () transactions simultaneously. Transaction sizes are KB. Our timings are competitive with those of the approach in Zcash Sapling and trade slightly larger proofs (proofs in Zcash are 0.2KB) for a completely transparent setup.

(2)< Linear-map Vector Commitments and their Practical Applications>

Abstract: Vector commitments (VC) are a cryptographic primitive that allow one to commit to a vector and then “open” some of its positions efficiently. Vector commitments are increasingly recognized as a central tool to scale highly decentralized networks of large size and whose content is dynamic. In this work, we examine the demands on the properties that an ideal vector commitment should satisfy in the light of the emerging plethora of practical applications and propose new constructions that improve the state-of-the-art in several dimensions and offer new tradeoffs. We also propose a unifying framework that captures several constructions and show how to generically achieve some properties from more basic ones. On the practical side, we focus on building efficient schemes that do not require new trusted setup (we can reuse existing ceremonies for pairing-based “powers of tau” run by real-world systems such as ZCash or Filecoin). Our (in-progress) implementation demonstrates that our work over-performs in efficiency prior schemes with same properties.

1) Our Contributions

①Theoretical Advances

On the theoretical frontier, we unify previous definitions and augment them with additional properties. The basic notion we use is Linear Map Vector Commitments (LVC) and is inspired by the work of Lai and Malavolta. We then define additional properties on top of this definition and explore their relations. Specifically, we augment this notion with updatability and aggregation properties, including a novel notion -unbounded aggregation- capturing the ability to aggregate already aggregated proofs but relaxing incremental aggregation in the sense that the verifier is allowed to do work linear in the number of aggregation hops (i.e. aggregation is “history” dependent), also, disaggregation is not possible. We show that having additional homomorphic properties is highly desirable, by arguing that any LVC that satisfies them:

1. can be augmented with unbounded aggregation as well as updatability.

2. can support general linear map openings (i.e. for any) as long as it supports inner product openings (i.e. for). This allows us to focus on efficient constructions for inner products with homomorphic properties.

②VC Constructions

First, we present two pairing-based LVC constructions for inner products based on the properties of monomial and Lagrange polynomial basis and prove that they satisfy all the relevant homomorphic properties to obtain unbounded aggregation and support general linear maps. In terms of expressivity, these constructions generalize previous work by supporting linear functions instead of position or subvector openings. Vector commitments for this class of functions are core components of important primitives such as arguments of knowledge for Inner Product (IP) relations or aggregation arguments.

Second, we present two novel maintainable constructions by exploiting the tensor structure of multivariate and univariate polynomials. These constructions allow a stronger, more flexible form of maintainability: they support an arbitrary memory/time trade-off for openings, meaning that one can decide how much memory it wants to use to reduce the opening time.

The multivariate case is a generalization of Hyperproofs in several dimensions. Roughly speaking maintanability is achieved in Hyperproofs by constructing a binary tree of proofs where at the leaves there are the values of individual positions. We present a single construction that can be instantiated in several ways (recovering Hyperproofs as a special case) with these features: (i) the tree can be of any arity, so proofs are shorter; (ii) the leaves can be commitments for any LVC and not only individual openings, to achieve a fully flexible trade-off. As a result of (ii), the scheme is more expressive (as it can support openings to linear functions/subvector openins at leaf level if the underlying commitment supports it).

The univariate construction is inspired by this generalization and it has the additional feature that the setup is independent of the trade-off, and can be decided by the prover on the fly.

③ Practical Improvements

As in some applications like Proof of Space, the subset of opened positions is not very meaningful and its distribution is expected to be known in advance, we study how to improve verification efficiency for certain special subsets openings in our inner-product constructions. For some structured sets, we achieve a verifier that performs half of the work it does for arbitrary sets of the same size in the Lagrange construction, and only a constant number of group operations in the one that uses the monomial basis.

Second, we mitigate the challenges of deploying these constructions due to their need of a trusted setup. With the exception of the multivariate variant of the maintainable construction, all our constructions can reuse trusted setups such as “powers of tau” that were run for pairing-based SNARK schemes used in real-world applications, as opposed to for example, in which a certain middle power of needs to be missing in the SRS. In Appendix 7 we demonstrate the practical benets of our special subset construction by providing an implementation and comparisons with current solutions.

2) Implementation and Experimental Evaluation for LVC

We implement our monomial basis construction in Rust on top of the paired library and is available on Github. In this section we experimentally evaluate different features of our monomial-basis construction. In particular we investigate and provide estimates for the following questions:

• For which set sizes can we expect proving time in our construction to be more efficient than that in SNARKs over Merkle Trees?
• How beneficial is for proving time our range opening?
• How much can verification time benefit from special subset opening?

①Comparison with SNARKs over Merkle Trees

We show our comparison in Figure1. We compare to Merkle trees instantiated with both Poseidon hash and with SHA256. The underlying proof system used here is Groth16 in its libsnark implementation.

We estimate our construction to have more efficient proving time for vectors up to approximately, where SNARKs over Poseidon are of similar efficiency. Our construction is more efficient than SNARKs for SHA-based Merkle trees for larger vectors. We point out that while Poseidon is a highly SNARK-friendly hash function it is slower than SHA when executed “natively” and it has received little cryptanalytic scrutiny so far.

Our proving time has a steeper growth than that of the SNARKs. This is a direct consequence of the following: our proving consists of multiexponentiations roughly linear in the size of the vector; SNARKs over Merkle trees, on the other hand, are still Merkle tree openings and thus logarithmic in the vector size despite their larger hidden constants.

The diagram shows proving time for a single opening only. Our scheme performs better than MT+Poseidon hashes for vectors of size up to, while we do better than Merkle Trees with SHA256 for vector of size up to.

②Proving Time for Special Subsets

The results of this comparison are in Figure2. We compare the proving time of our subvector opening for a range of positions of Section 6.1 to range position opening through a SNARK (again Groth16) over Merkle trees with the Poseidon hash function. For the latter, we make use of the fact that a range opening in a Merkle tree can often be significantly optimized by opening an “upper path” only once and then opening a whole subtree stemming from that upper path and corresponding to the whole range.

Except for very small ranges, Merkle trees perform worse. The savings are of a few order of magnitudes even for moderately sized ranges. The reason for this is the virtually constant proving time in our range subset compared to the one for SNARKs which roughly grows linearly with it (our proving time actually decreases with the range size, but in the diagram we just consider the proving time for the most expensive case). We performed similar evaluations for different set sizes and find little difference in the patterns.

③Verification for Any Subsets

The results of this comparison are summarized in Figure3. We compare our verifier for an aggregated subset opening in Section 6.2 with that in Pointproofs. Our estimates indicate that our verifier can be twice as fast as that in Pointproofs for appropriately large opening subsets. See Figure3.

We describe the costs of these verifier reducing all other operations to their corresponding costs in. For this we use the thorough conversions documented in [?, Table 2]. All our costs refer to an instantiation with BLS12–381.

Cost of the Pointproofs verifier opening a subset|:

+c(||)|

Cost of our verifier in Section 6.2:

|

Above and correspond respectively to Miller Loop and Final Exponentiation for the pairing. Field operations refer to multiplications. The constants, are small enough to be ignored in our figure. We estimate the cost of a field operation as approximately of a operation.

Our construction has an initially higher cost which is soon compensated as the subset size increases. This is due to the more expensive operation that dominate in Pointproofs. Our verification achieves a speedup of approximately in this cost model. The maximum subset size we show in the plot is also roughly the parameter at which the ratio between the two verification times converges, i.e., the multiplicative speedup of our construction does not increase for larger subsets.

We stress that our goal here is to give an indication of the fact that our approach can be useful. Concrete speedups would be highly dependent on the implementation of algebraic primitives and on the curve as well as other optimizations we have not considered in the analysis above.

④Further Details on Evaluation

All the curve operations are instantiated over curve BLS12–381 [?]. Our timings for SNARKs over Merkle trees are (generous) lower bounds extrapolated from[?, Figure 5]. All our benchmarks refer to executions run single-threaded on Amazon EC2 using r5.8xlarge instances (248GB of memory).

3) Vector Commitment Applications

Here we describe in more detail some of the applications of our work and their specific requirements.

①Verifiable Databases

Vector commitments are a solution for the problem of outsourcing storage to untrusted parties. In the verifiable database (VDB) setting, a client owns a database D and wishes to outsource the storage of D to a server while keeping the ability to query and update the database. The security goal is to prevent an untrusted server from tampering with the database and cheat on the query outcomes that it provides to the client. A good solution should enable the client to run efficiently once the outsourcing has been performed. Furthermore, the communication and running time of the query and update protocols should not depend on the total size of the database.

The basic problem of integrity of outsourced data can be easily solved by using the celebrated Merkle tree construction. It consists in hashing the data using a tree structure in which the leaves are the blocks of D and every internal node is the hash of its two child nodes; the root of this tree is the so-called Merkle hash (digest) of D. To use Merkle trees to solve the outsourced storage problem, the client can compute the Merkle tree and store only the root. When the client wants to retrieve the record, the server responds with the data and a logarithmic-size path consisting of the nodes from until the root, and the client can then verify the authenticity of in logarithmic time by recomputing a hashed value using the path and check it against the stored digest (Merkle root). The security of this construction can be reduced to the collision resistance of the hash function. In terms of efficiency, the communication complexity of this protocol is.

While Merkle trees solution is asymptotically better than resending the entire database, Vector Commitments allow to improve the communication complexity beyond logarithmic and to add important properties such as updatability or functional openings.

②Stateless Cryptocurrency

One of an important decentralised applications of vector commitments is in distributed ledger-based payment systems, known as cryptocurrencies. The best-known examples of cryptocurrency largely used today are Bitcoin, Ethereum, or Zcash to name a few. Such a system, utilises a blockchain in order to post and record peer-to-peer payment transactions. This translates into an ordered log of transactions, in other words an append-only public ledger, that is replicated across nodes in the network. We will call such nodes that store and check the transactions log validators, as opposed to simple cryptocurrency users who only store their account balances. The validators are essential to reach consensus on what is the current state of the public ledger.

Unfortunately, there is a bottleneck: verifying the validity of a transaction requires querying the entire ledger to obtain the latest state of the account balances. However, maintaining the entire ledger increases the memory requirements and reduces the number of possible validators.

To reduce the amount of storage required of validators, there have been solutions [4, 8] based on vector commitments. Instead of storing the entire ledger state, the validators can keep commitments to vectors representing the state. Using vector commitments properties, validators with a commitment to the ledger state can still validate transactions sent by users by checking opening proofs against the commitment. More concretely, the users will send their account balance values and a proof that this is consistent with respect to the commitments stored by the validators. After the transaction is accepted, the validators should be able to update the commitment to the old state to a commitment to the new state that includes the changes made by the transaction. If the vector commitment scheme has small commitment sizes, short proofs, efficient opening computation and allow for updates, then such a solution provides the best trade-off between storage, bandwidth, and computation.

We call such a solution a stateless cryptocurrency, i.e. a system where neither validators nor cryptocurrency users need to store the full ledger state. While the stateless cryptocurrencies overcome the storage overhead when performing transaction validation, they increase network communication because of extra opening proofs added to each transaction payload. To minimise communication in the transactions, an important feature of vector commitments is aggregation. Using aggregation to “pack” together multiple opening proofs for a batch of transactions into a single constant-size proof allows a significant improvement in the communication.

Another important property for applications to stateless cryptocurrencies is maintainability. This guarantees that re-proving an opening about the new state requires less time than computing it from scratch, which would make all previous computations useless. Instead, the individual proofs are initially computed and stored and efficiently updated after each state transition. Collective updates or maintainability saves computational resources since computing a single proof needs linear time while updating all proofs needs sublinear (e.g. logarithmic time).

To summarize, in order to provide the best trade-off between storage, bandwidth, and computation in stateless cryptocurrency application, the following properties are required from a VC scheme:

Short Commitment: validators store only a commitment to the ledger state.

Short Opening Proofs: to submit a transaction, users will send their account balance values and a proof that this is consistent with respect to the commitments stored by the validators.

Efficient Verification: to validate transactions, validators check opening proofs against the commitment.

Updatability: after the transaction is accepted, the validators should be able to update the commitment to the old state to a commitment to the new state that includes the changes made by the transaction.

Aggregation: to minimise communication in the transactions, some nodes can “pack” together multiple opening proofs for a batch of transactions into a single small proof.

Maintainability: to save proving time at each update, maintaining all the proofs up to date should be possible in sublinear time each time the state changes.

③Proof of Space

Proof-of-Space (PoS) is an eco-friendly alternative to proof-of-work (PoW) in blockchain-based consensus mechanisms that does not consume its resource (space vs. energy), but rather reuses it. A PoS, was introduced in [10] and further studied in [27, 1, 13]. It is an interactive protocol between a prover and a verifier that allows to check if the prover is storing intactly a file (data) that uses a specified amount of disk space. The protocol must have compact communication relative to the prover’s space requirements and efficient verification. A PoS is persistent if repeated audits force the prover to permanently store the file over a period of time.

Proof of Space protocols consist of two main steps:

• Initialization (Setup phase): On public input, an advice a (e.g., vector of random data) of size is created and committed to in. The advice is stored by the prover, while the verifier knows only the commitment to the advice.
• Execution (Audit phase): The verifier sends a challenge, for example asking the prover to open some positions in the advice and the prover responds. The verifier outputs accept if they are convinced that the prover stores the advice. This phase can be repeated many times.

We require that the verifier is highly efficient in both phases, whereas the prover is highly efficient in the execution phase if they are honest and had stored the data as expected. Otherwise, if the prover deleted parts of the file, regenerating the advice in order to pass the audit phase should be more costly (in time or computation cost) than just storing the file. A PoS can be run non-interactively using a public blockchain to perform the Setup and the Audit phase of the protocol described above. Provers and verifiers will post their challenge-response in the blockchain and this should be publicly verifiable.

Publicly Verifiable Proof of Space. A classical publicly verifiable PoS is based on Merkle trees and random spot-checks. A drawback of this construction is that proofs grow with the number of spotchecks (and the size of the tree) and become undesirably large to be stored in a blockchain. While these checks can be compressed through a SNARK (Succinct Non-interactive Argument of Knowledge) , this still require hundreds of GB of RAM and tens of minutes compared to our vector commitment solution.

For a construction of PoS based on vector commitments, the prover (miner) uses a VC to commit to a file (seen as a vector of blocks); then at every audit the verifier chooses a challenge by picking a set of many randomly chosen positions, and the prover responds by sending the subvector and an opening proof. The soundness property of a PoS scheme requires that for any prover that convinces the verifier that it is storing the file, there exists an algorithm called the extractor that interacts with the prover and extracts the file.

A vector commitment construction with openings for subvectors immediately implies a publicly-verifiable proof of storage.

Finally, our tree-based constructions allows reduced proving costs in the audit phase of PoS by instead using some extra memory to store proofs. A prover can efficiently pre-compute and store proofs and simply serve them on demand. Since memory is expensive, however, it is not optimal to store all the proofs. Our construction is flexible: a prover only stores partial proofs to reduce computation. Importantly, the part of the proof that is computed on the fly has constant size and therefore the proof size only depends on the amount of memory dedicated by the prover. Finally, our proofs can be aggregated using standard techniques. The smaller proof size translates to a cheaper aggregation cost.

④Compiling SNARKs from Vector Commitments

Our LVC schemes can be used to construct new efficient Succinct Non-interactive Arguments of Knowledge(SNARKs) with constant-size opening. Following up on the approach pioneered by Kilian and Micali ,recent works [4, 20] show that we can construct SNARKs based on probabilistically checkable proofs (PCPs) or interactive oracle proofs (IOPs) by plugging in vector commitments with subvector openings.

In an IOP the prover sends multiple proof oracles to a verifier. The verifier uses these oracles to query a small subsets of the proof in order to decide acceptance or rejection. Recent practical instantiations of proof systems from IOPs use Merkle trees as a vector commitment. While Merkle trees do not require a trusted setup, these schemes have two significant drawbacks for the two above applications: first, position openings are not constant size, and second, the openings of several positions cannot be compressed into a single constant size proof (i.e. it does not support aggregation or subvector openings). LVC with subvector openings are a perfect candidate to instantiate IOP-based SNARKs.

Replacing Merkle trees with a vector commitment, Lai and Malavolta obtain a SNARK where the proof consists of 3 field elements and 2 group elements. Using the same blueprint, we can use LVC to match the same proof size as theirs and improve the trusted setup by making it compatible with other widely deployed proof systems. On the other hand, the construction in (last row in their Table 2) requires a trusted setup with a “gap” in the powers of exponent.

⑤Applications of Range Openings

One of the features of our monomial-basis construction is to have efficient range openings. These arguably have several natural applications.

In several protocols involving queries, it is common to perform some type of “caching” optimizations. For example, an HTTP client can perform prefetching and receive from a server not only the values of interest but other related values that could potentially be queried in the near future (e.g., values in a neighboring range of the queried values). Our range-based queries can be used in similar setting whenever we need to query a resource whose digest consists of a vector commitment.

(3)< A New Approach to Efficient Non-Malleable Zero-Knowledge>

Non-malleable zero-knowledge, originally introduced in the context of man-in-the-middle attacks, serves as an important building block to protect against concurrent attacks where different protocols may coexist and interleave. While this primitive admits almost optimal constructions in the plain model, they are several orders of magnitude slower in practice than standalone zero-knowledge. This is in sharp contrast to non-malleable commitments where practical constructions (under the DDH assumption) have been known for a while.

We present a new approach for constructing efficient non-malleable zero-knowledge for all languages in NP, based on a new primitive called instance-based non-malleable commitment (IB-NMC). We show how to construct practical IB-NMC by leveraging the fact that simulators of sub-linear zero-knowledge protocols can be much faster than the honest prover algorithm. With an efficient implementation of IB-NMC, our approach yields the first general-purpose non-malleable zero-knowledge protocol that achieves practical efficiency in the plain model.

All of our protocols can be instantiated from symmetric primitives such as block-ciphers and hash functions, have reasonable efficiency in practice, and are general-purpose. Our techniques also yield the first efficient non-malleable commitment scheme without public-key assumptions.

2、Guides and Resources

(1) Some ways to use ZK-SNARKs for privacy | Vitalik Buterin

1) Proof of membership

Suppose that you have an Ethereum wallet, and you want to prove that this wallet has a proof-of-humanity registration, without revealing which registered human you are. We can mathematically describe the function as follows:

• The private input (): your address, and the private key to your address
• The public input (): the set of all addresses with verified proof-of-humanity profiles
• The verification function:

-Interpret as the pair, and as the list of valid profiles

-Verify that is one of the addresses in

-Verify that

-Return if both verifications pass, if either verification fails

The prover generates their address and the associated key, and provides as the private input to. They take the public input, the current set of verified proof-of-humanity profiles, from the chain. They run the ZK-SNARK proving algorithm, which (assuming the inputs are correct) generates the proof. The prover sends the proof to the verifier and they provide the block height at which they obtained the list of verified profiles.

The verifier also reads the chain, gets the list at the height that the prover specified, and checks the proof. If the check passes, the verifier is convinced that the prover has some verified proof-of-humanity profile.

Before we move on to more complicated examples, I highly recommend you go over the above example until you understand every bit of what is going on.

2）Making the proof-of-membership more efficient

One weakness in the above proof system is that the verifier needs to know the whole set of profiles, and they need to spend time “inputting” this set into the ZK-SNARK mechanism.

We can solve this by instead passing in as a public input an on-chain Merkle root containing all profiles (this could just be the state root). We add another private input, a Merkle proof proving that the prover’s account is in the relevant part of the tree.

Advanced readers: A very new and more efficient alternative to Merkle proofs for ZK-proving membership is Caulk. In the future, some of these use cases may migrate to Caulk-like schemes.

3) ZK-SNARKs for coins

Projects like Zcash and Tornado.cash allow you to have privacy-preserving currency. Now, you might think that you can take the “ZK proof-of-humanity” above, but instead of proving access of a proof-of-humanity profile, use it to prove access to a coin. But we have a problem: we have to simultaneously solve privacy and the double spending problem. That is, it should not be possible to spend the coin twice.

Here’s how we solve this. Anyone who has a coin has a private secret. They locally compute the “leaf” (s,1), which gets published on-chain and becomes part of the state, and, which we call the nullifier. The state gets stored in a Merkle tree.

To spend a coin, the sender must make a ZK-SNARK where:

• The public input contains a nullifier, the current or recent Merkle root, and a new leaf(the intent is that recipient has a secret, and passes to the sender)
• The private input contains a secret, a leaf and a Merkle branch
• The verification function checks that:

-is a valid Merkle branch proving that is a leaf in a tree with root, where is the current Merkle root of the state

4) Coins with arbitrary balances

The above can easily be extended to coins of arbitrary balances. We keep the concept of “coins”, except each coin has a (private) balance attached. One simple way to do this is have the chain store for each coin not just the leaf but also an encrypted balance.

Each transaction would consume two coins and create two new coins, and it would add two (leaf, encrypted balance) pairs to the state. The ZK-SNARK would also check that the sum of the balances coming in equals the sum of the balances going out, and that the two output balances are both non-negative.

5) ZK negative reputation

Suppose that we want to build 0chan, an internet forum which provides full anonymity like 4chan (so you don’t even have persistent names), but has a reputation system to encourage more quality content. This could be a system where some moderation DAO can flag posts as violating the rules of the system and institutes a three-strikes-and-you’re-out mechanism, it could be users being able to upvote and downvote posts; there are lots of configurations.

The reputation system could support positive or negative reputation; however, supporting negative reputation requires extra infrastructure to require the user to take into account all reputation messages in their proof, even the negative ones. It’s this harder use case, which is similar to what is being implemented with Unirep Social, that we’ll focus on.

6) Combining ZK-SNARKs with MPC

A more advanced use of ZK-SNARKs involves making proofs over computations where the inputs are split between two or more parties, and we don’t want each party to learn the other parties’ inputs. You can satisfy the privacy requirement with garbled circuits in the 2-party case, and more complicated multi-party computation protocols in the N-party case. ZK-SNARKs can be combined with these protocols to do verifiable multi-party computation.

This could enable more advanced reputation systems where multiple participants can perform joint computations over their private inputs, it could enable privacy-preserving but authenticated data markets, and many other applications. That said, note that the math for doing this efficiently is still relatively in its infancy.

3、Project Updates

(1) zkSync 2.0 Public Testnet is Live | Mattlerabs Blog

1) A Growing Ecosystem of Infrastructure

We’ve received hundreds of requests from developers looking to deploy on zkSync 2.0, and in an effort to help users discover some of these projects we’ve released a new ecosystem hub developers can add their projects to.

We recognize developers need certain infrastructure in place to be successful, and Matter Labs has been working with teams across the ecosystem to ensure these key pillars are available. Here are some of the projects we can talk about working to provide this infrastructure:

• FIAT On & Off Ramps

Banxa, Ramp Network, UTORG, and MoonPay will all provide the ability to purchase crypto directly on zkSync through a variety of payment methods, allowing users to avoid L1 fees altogether. Major exchanges including Crypto.com, Bybit, Huobi, Blockchain.com, OKEx and Ripio are building direct deposit and withdrawal capabilities with zkSync for their users, and LayerSwap is working to support the same functionality for multiple major exchanges.

• Bridges

Celer, Connext, ZigZag, Orbiter, DAI Wormhole, Composable, Hop Exchange, LayerZero, PolyNetwork, deBridge, and Nomad will allow the token transfers quickly and inexpensively between zkSync 2.0 and other L1 and L2 protocols.

• Data Oracles

Chainlink will provide oracle services to developers requiring off-chain data feeds in their applications.

• Protocol Indexing and Search

Graph Protocol and Covalent will both index zkSync 2.0 to make the chain more searchable and accessible to developers.

• Wallets

Users will be able to sign transactions and manage their assets with most Ethereum wallets on zkSync 2.0, including Metamask, Argent, Numio, 1inch Wallet, MyKey, and imToken.

• Block Explorers, Developer Tools, and Voting!

We’ll be pushing to ensure users can easily explore block data through Etherscan and Blockscout, in addition to a block explorer being developed by Matter Labs. Tenderly will integrate zkSync allowing developers to monitor and test smart contracts. Gnosis safe will allow users to safekeep assets and provide multi-sig functionality. Snapshot will allow decentralized voting on zkSync for DAOs, and Hardhat will allow devs to easily compile contracts and run them on a development network.

• Funding

BitDAO has recently funded zkDAO, a $200 million accelerator focused on providing funding and grants to projects inside the zkSync ecosystem. The DAO will also fund ecosystem education, research, and security.

2) The State of the Rollup

The current version of the zkSync 2.0 solves the needs of most applications on Ethereum, and with more features planned for release soon, zkSync 2.0 will provide developers with a design space to experiment with applications not possible on Ethereum today. With this release, we are supporting the following features:

• Native support of ECDSA signatures. Unlike the first version of zkSync and most of the ZK Rollups, no special operation is required to register the user’s private key. Any account can be managed in L2 with the same private key that is used for L1.
• Solidity 0.8.x support. Deploy your existing codebase with little to no changes required.
• Web3 API. With small exceptions, our API is fully compatible with Ethereum. This allows seamless integration with existing indexers, explorers, etc.
• Support for Ethereum cryptographic primitives. zkSync natively supports keccak256, sha256, and ecrecover via precompiles.
• Hardhat plugin. Allows easy testing and development of smart contracts on zkSync.
• L1 → L2 smart contract messaging. Allows developers to pass data from Ethereum L1 to smart contracts on zkSync, providing required information to run various smart contracts.

There are some features that are not included in our current testnet that we’re looking to ship in future upgrades. In estimated chronological order, this includes:

• L2 → L1 smart contract messaging. Will allow developers to pass data from zkSync to L1, once again, allowing developers to build more robust applications.
• Support for Vyper Programming Language.
• Account abstraction. Imagine being able to implement custom logic for signature checking for your account. Or maybe social recovery? Currently, on most of the EVM chains, users need to deploy smart contract wallets for such purposes. All of this would be easily supported with account abstraction.
• Support for older versions of Solidity. We are actively working on supporting different versions of Solidity to enable seamless integration for the existing projects.
• zkPorter. One of the largest and most important features, zkPorter will allow users to choose between a zkRollup account featuring the highest security & 20x fee reduction compared to Ethereum, or a zkPorter account featuring stable transaction fees of just a few cents in a different security model (much higher than that of a sidechain). Both zkPorter accounts, and zkRollup accounts, will be able to interact seamlessly together under the hood.

(2) ZKP in a Browser? You got it! | zClock Blog

The zCloak Network team is very excited to announce we have just achieved the first STARK proof generation in a browser extension.

What is in the demo? In the demo, we have a simple algorithm to judge if a person is over 20 years old. A result of “true” is obtained for Alice who is 26 and a STARK proof is generated to prove the correctness(integrity) of her computation. If Alice sends the result and the proof to a 3rd party, she will be able to prove that she is over 20 years old without disclosing her exact age.

How was it achieved? We have managed to make the Rust ZKP virtual machine into a wasm library and made it accessible to a js/ts front-end such as a web-page or a browser extension. Now users can perform a wide range of computation/analysis on their private data and generate a Zero-Knowledge Proof to attest their computational integrity. Note that, with the ZKP virtual machine, you don’t have to hand-write a circuit/air for each of your algorithms anymore.

Why is it important? This experiment implies a shift of computation paradigm — from cloud computing to cloaked computing. We are getting closer to the goal of Web 3.0 — no need to send your private data to centralized servers anymore. Now you can use your data in your local space and prove your computation is correct with zero-knowledge proof. This is significant for data privacy protection. After all, if you don’t have to share your data with any 3rd parties, there is nothing they can do to misuse/leak your data.

(3) Rollux, L2 ZK-Rollups | Syscoin Blog

Thanks to Rollux, Syscoin’s NEVM will be the first to utilize as pioneered by core developer Jagdeep Sidhu. After Ethereum, NEVM will be one of the first to host Optimistic rollups, yet the only one to anchored to Bitcoin’s gold-standard PoW whilst Ethereum 2.0 moves towards PoS. Rollux remains agnostic regarding rollups and will integrate ZK-Rollups once they are ready. However, Optimistic Rollups’ readiness makes it the perfect place to begin lift-off in the greatest launch forward in Layer 2 scaling solutions the crypto space has seen, without sacrificing the decentralization, security, and affordability at the heart of Syscoin.

One of best aspects of the Rollux Suite is that it will be launched as a not-for-profit product of the Syscoin Foundation. As such, we can forgo enforcing a token model so often seen in competitors. We have found that such token models force unnecessary fees and add extra costs for users, creating friction that inhibits adoption. Since all network fees will be payable with the native SYS coin and the network is operated as a non-profit aligned with the best interests of the Syscoin ecosystem, we are creating the most efficient path towards mass adoption. We are laying the groundwork to reach that point by keeping fees cheap, and by using and our treasury to cover costs. In so doing, we will offer seamless integration with scalable infrastructure that is open-source, permissionless, and self-sufficient once decentralized sequencer processes are integrated.

Syscoin Rollux will be the bleeding edge of scaling tech for Solidity-based smart contracts. Rollux is the Layer 2 suite needed in the blockchain space to usher in widespread adoption and maturity. It will be the boon needed to catapult projects running on the Syscoin Platform to scale well beyond current boundaries. Since our NEVM chain is 100% EVM-compatible, it will also be the perfect tool to onboard projects from Ethereum, all of which can benefit from being secured by Bitcoin’s PoW at scale, along with the miniscule fees inherent to the Syscoin Platform.

(4) On-chain Procedural Generation | 0xPARC Blog

1) Why do we use procgen?

Players often want rich and immersive worlds to interact with. Knowing this, your first instinct as a game developer might be to build your game world block by block — by hand. Off chain, handmade maps are extremely commonplace — games like DayZ and Fortnite carefully engineer detailed towns and hills optimizing for maximum fun.

On-chain, however, we deal with a big constraint — storage cost. Storing a single 32-byte word on Ethereum can cost over 20,000 gas (EVM gas schedule). It would be infeasible to store even a 1000x1000 2D tilemap on chain; larger maps could require thousands (or even millions) of SSTORE operations, which is far more than can be done in a single EVM transaction given the block gas limit. Additionally, in many games, you don’t actually want the whole world to be visible at the outset; for example, perhaps you want players to have to uncover the world through exploration over time.

The use of procedural generation allows you to generate each of these tiles on-demand, only writing to storage when a player first interacts with a particular coordinate. Each individual call to a procedural generation algorithm (Perlin Noise, for instance) can be fairly cheap — in our very unoptimized demo below, initializing an effectively infinite world is “free,” while touching a tile and running the Perlin Noise algorithm for the first time costs about 70,000 gas. By running procedural generation and caching a tile’s attributes when someone first steps on it, you can amortize the cost of storing the map on-chain amongst all the players of your world. In some sense, a procedural generation algorithm is a trick to compress a complex world into an executable.

Procedural generation definitely isn’t a new idea specific to onchain gaming! Almost all your favourite roguelike games use procedural generation in some way or the other, including Minecraft (for landscape generation), No Man’s Sky (for planet generation) and Dwarf Fortress (for creatures, religions, etc.) among many others.

Procedural generation for world building is, unsurprisingly, a technique originally pioneered by games running on 16kb RAM and 1MHz processors back in the 90s (and earlier!). It’s interesting how many similarities there are between the resource-limited personal computers of the 90s and the resource-limited shared computer today that is the Ethereum Virtual Machine. In many ways, we’re in the 90s of crypto-native gaming, and developing an on chain world right now is an exercise in balancing constrained creativity and being resourceful and hacky with what’s possible with on-chain compute.

2)How do we use procgen?

So far, we’ve only described procedural generation in hand wavy terms-“make me a cool looking world.” How do we actually do this efficiently?

①Randomly-generated assets

The simplest strategy is to simply “roll a die” (run a pseudorandom function) for every tile, planet, game asset, etc. Depending on how the roll comes up, you might choose to assign a different property value to the game object in question — for example, if a creature’s hash ID ends in a 0, color it blue; otherwise, color it red. This is the easiest way to level up a game world beyond simply being a blank white slate.

In the earliest versions of Dark Forest, every coordinate had a 1/16384 chance of “spawning” a planet, and each planet would randomly be assigned a color, a level, and various stats. This variety gave players implicit goals — discover the rarest planet types, conquer a top-level planet, etc.

Other early blockchain games like CryptoKitties also used relatively simple random generation methods to generate a large number of image assets cheaply. The properties of each digital cat are determined by an algorithm that is inexpensive to run; however, the number of possible trait combinations that you can roll is effectively infinite. This technique has since been copied by the thousands of speculative NFT clone projects that fueled the latest hype cycle.

While purely random generation is certainly better than nothing1, worlds and game assets generated randomly with no deeper coherence tend to start feeling stale relatively quickly. Without any notions of locality or progression, gameplay quickly degenerates into pulling a slot machine lever. Zooming out in a universe of randomly-generated assets, everything starts to looks like white noise.

②Structure from Randomness

As a next step, what we’d like is a way to convert pure randomness into something with recognizeable “structure” — a source of entropy that feels random, but also isn’t completely chaotic to look at. More formally, our aim is to create a noise function that is variant when looked at globally, but locally consistent zooming in. To understand the intuition to making such a function, let’s start with something fundamental: sine waves! As a quick refresher, a sine wave is an equation that looks like. Amplitude and Frequency parameters allow you to squish or stretch the wave horizontally and vertically.

Another interesting concept is super-position: the ability to add up different wave functions. See what happens when we add up many sine waves with random parameters:

We get a lot more variation in our output globally, while maintaining the local similarity property we desired. This is how procedural generation works! Formally, each of the constituent waves is called an “octave”, each adding more complexity to the surface of the output.

Instead of using a sine wave, Perlin Noise uses a different function. While it follows the same idea, it’s less regular compared to sine waves and its amplitude is more consistent. While it is technically possible to build all the generations we describe below with simple trigonometric functions like sine waves, Perlin noise is easier (and prettier) to use, so we’ll focus on Perlin Noise going forward.

(5) Proof of Stake: Approach, focus, and next steps | Electric Coin Company Blog

1) Proof-of-stake security

While we strongly favor protocols that are proven via real-world production hardening, we additionally require a strong theoretical foundation.

① Incentives and resource cost security

A core concept in security arguments for cryptocurrency protocols is incentive alignment: If it’s in the best interest of independent block producers to follow reinforcing consensus rules, the protocol should be robust against deviations (aka attacks). This is an important departure from earlier work in Byzantine consensus protocols, which typically only distinguished between “honest” or altruistic nodes versus malicious nodes.

If security relies on incentives, then feasibility of an attack depends on the payoff given the cost. So, for example, a proof-of-work attacker with a tiny fraction of mining capacity is unlikely to execute a long rollback within some window. However, as an attacker’s resources scale up, their ability to successfully execute attacks improves (despite the larger cost of the attack).

So, arguments for security in cryptocurrency consensus analyses often rely on the cost to maliciously control a key resource: hashpower for proof-of-work and staked tokens for proof-of-stake. Sites like crypto51.app provide cost estimates for 51 percent attacks against PoW chains, which exemplifies this mode of reasoning about security.

In Ethereum 2.0 Economic Review by Hoban & Borgers, the authors compare the estimated 51 percent attack cost against ETH1 (PoW) to the cost of controlling sufficient validators for a safety attack against ETH2 (PoS) as a heuristic to determine whether the newer protocol is as safe as the previous protocol.

Our preference: We believe the “attack cost comparison” used in the Hoban & Borgers paper is one useful guideline in analyzing the safety of a transition from PoW to PoS, as long as we exercise caution in not relying too heavily on this single heuristic.

A key safety mechanism in PoS protocols is an “unbonding period” during which a staker cannot access their staked funds without some delay. This delay underpins security guarantees, for example, by ensuring a bond may be slashed some time after a slashable behavior occurs.

Our preference: We don’t anticipate deviating from an existing candidate protocol’s design for unbonding period length, while ensuring it is tuned to a conservative value for our security requirements.

② Wrinkles in incentive space

While the notion of relying on participants to follow incentives seems reasonable, we are acutely aware of three big risks in the “cost of resource” attack reasoning from the last section:

• Attack costs may be overestimated
• Pay-offs may be underestimated
• Or more generally, real incentives for participants may not be correctly modeled

Attack costs can be overestimated in the simple “cost of consensus resource” security model due to financial mechanisms, as well as combined attack modalities. For example, Why buy when you can rent? explores how an attacker can use “bribery” to gain temporary control of PoW mining capacity to execute an attack, without incurring the larger and longer term capital cost of acquiring the mining equipment. A similar case could occur in PoS if, for example, an attacker acquires staking capital through a financial mechanism that lowers their direct cost.

Pay-offs may be underestimated, especially because the attack-cost models tend to ignore payoffs altogether. If an attack costs the equivalent of $X billion USD, that may seem reassuring, but what if an attack can net $10X billion in proceeds?

Finally, those two problems are more specific cases of the real incentives of participants being incorrectly modeled. On this more general point, evolving real-world incentives may threaten the security of consensus protocols even when there is no “attacker” with malicious intent. In Competitive equilibria between staking and on-chain lending the researchers analyze how the amount staked in a PoS protocol interacts with a model defi lending platform. In that analysis, staking security may become perilously low through self-interested behavior of participants, none of whom intends to “attack” the network. The meltdown of the Terra staking token Luna, as described by Bloomberg columnist Matt Levine, would seem to be a real-life event related to this research that is likely to become a canonical example of how financialization mechanisms when attached to a proof-of-stake token can lead to security disasters.

So, many kinds of financialization or financial mechanics can impact security, including defi, bridging, multi-asset support, and off-chain custodial financial services impact security.

All of this complexity not only complicates analysis of a protocol, but it also opens the design space to incorporating financialization mechanisms. Existing networks are exploring this area of design space with staking derivatives, such as staking-backed derivative tokens (often simply called “staking derivatives” or “liquid staking”), superfluid staking, and more. On Staking Pools and Staking Derivatives mentions a common argument that liquid staking may lower security and it then presents an argument that for some given assumptions it can actually increase security.

Finally, all of this discussion of incentives has skirted around a core economic design component impacting PoS security, the Issuance Policy, which we discuss separately below.

Our preference: Our preferences around issuance are described in the Issuance policy section. Our belief around financialization is that it generally produces value, is inevitable, and that ZEC can be safely incorporated into it, so long as we understand and mitigate risks as they develop. Our preference for incorporating financialization into the consensus protocol is to be extremely conservative and only consider such mechanisms, such as liquid staking, when there is a strong argument for their benefit versus their risk and complexity. We prefer to propose a simpler “V1” protocol and may consider such mechanisms in later iterations of future PoS protocol improvements.

③ Dynamic availability vs finality

The research literature highlights a fundamental trade-off in consensus protocols between “dynamic availability” vs “finality”. This extends earlier research from distributed computing around a similar trade-off popularized as the CAP theorem.

Dynamically available protocols can continue making progress during network partitions, at the cost of reverting transactions when the partitions later reconnect. Finalizing protocols ensure that once a transaction is final it cannot be reverted, at the cost of halting the network during a partition.

Both transaction reversion (aka “rollbacks”) and network halts cause economic damage to participants. A protocol which allows transaction reversion can lead to “half-executed” economic exchanges, which leave one party harmed. Protocols that can halt will prevent the users from accessing their capital, introducing opportunity costs.

An example of a half-executed exchange in a dynamically available protocol (such as Zcash PoW), is when Alice sends Bob 0.001 ZEC, and Bob makes and gives Alice a latte, then Alice consumes it. If there is subsequently a network rollback that reverts the transfer, Bob will not receive the 0.2 ZEC, thus causing Bob to not be compensated for their work. By contrast, in a finalizing protocol, if Bob receives the payment he has a guarantee it cannot be reverted, and can safely sell the latte. Meanwhile, if a finalizing protocol halts, Alice cannot pay Bob at all. Neither party loses out in direct terms, but they cannot complete an exchange which has opportunity costs. (For example, should Alice wait in the cafe? For how long?)

However, it’s important to note that network halts in finalizing protocols can be particularly damaging for financialized mechanics that should respond in real-time to market conditions, such as collateralized systems that may liquidate positions when real-time prices cross some threshold.

Our preference: We have a strong preference for finalizing protocols. A network halt affects all users consistently whereas a rollback only reverts a portion of transactions (those on one of multiple partitions) and harms one participant in every economic exchange for all reverted transactions. Currently, the Zcash network has minimal programmability enabling use cases such as financial systems that respond to real-time price oracles, so we suspect that class of harm from network halts is lower than other crypto networks. Finally, we believe, separate consensus protocols which provide finality can interoperate more safely with less complexity.

④ Block producer decentralization and resilience

Because permissionlessness is a key property of Zcash, we need to consider how resilient the consensus infrastructure is.

The infrastructure that selects from proposed blocks is critical to censorship resistance and capture resistance, although shielded transactions and the possibility of a community-organized chain split are even more fundamental protections. If entrance to the set of block selectors can be limited outside of freely open, nondiscretionary competition, that presents a capture risk.

Among proof-of-stake protocols with nondiscretionary rules for becoming a block selector, there are several constraints to entry:

• Participation has capital and operational costs beyond staking bond capital itself, such as network connectivity, operations & maintenance, executive functions, etc… We refer to this as “out-of-band costs”.
• Participation has competitive in-band staking bond capital requirements, or “in-band costs”.
• Different protocols may have resource constraints on the number of participants. For example, Ethereum Consensus Layer aims to support thousands of block selector nodes, while Tendermint has a practical limit of hundreds of block selectors.
• If entry is in-band, the existing block selectors must accept in-band transactions that allow new entrants to register. There is a risk that existing block selectors could censor these registrations to prevent their competitors from freely entering the system.

Our preferences: For each of the above constraints, our preferences are:

• We prefer to prioritize permissionless entry and competition into block producer infrastructure.
• We prefer in-band staking bonds to be delegatable with low cost and ease of use by a very large number of users. We believe the ability for users to freely redelegate their stake to different block selectors enables free competition between the selectors.
• We prefer the practical “floor” amount of ZEC for delegating stake to be as low as feasible, ideally less than $1 USD.
• We prefer not to prioritize having a large number of block selectors based on the belief that delegatable stake supports free competition sufficiently. We also believe finalizing protocols tend to have lower limits on the number of block selectors supported, and our preference for finality supersedes the desire for a large number of block selectors.
• We strongly prefer protocols that protect the permissionless entry of new validators in free competition to preserve overall consensus permissionlessness, resist capture, and lower validation fees.
• We believe with this combination of properties, delegator returns should approach block producer returns through open competition.

⑤ Other security risks

There are a multitude of other security risks related to PoS which we anticipate will be shared between Zcash and other PoS networks, including long-range attacks, a variety of network attacks (eclipse attacks, Denial-of-Service, initial node introduction risks), and more.

Our preference: Based on the belief that these risks will not be unique to Zcash, we optimistically anticipate existing PoS protocol designs have been hardened against them. Where we discover weaknesses we intend to collaborate with the broader PoS protocol design ecosystem to address those.

References：

（1）https://eprint.iacr.org/2022/756

（2）https://eprint.iacr.org/2022/705

（3）https://eprint.iacr.org/2022/767

（4）https://vitalik.ca/general/2022/06/15/using_snarks.html

（5）https://blog.matter-labs.io/zksync-2-0-public-testnet-is-live-de870ba9632a

（6）https://zcloaknetwork.medium.com/zkp-in-a-browser-you-got-it-52606bc3c976

（7）https://syscoin.org/news/introducing-rollux-syscoins-rollup-suite-ready-to-take-market-by-storm

（8）https://0xparc.org/blog/procgen

（9）https://electriccoin.co/blog/proof-of-stake-research-overview-1/

June, 2022

Since we mentioned the “MachineFi” track in our April special research report — <Finding the Hotspots of the Next Bull Market from the Perspective of New Assets>, More and more “MachineFi” projects have received financing . Therefore, in this month’s research report, we have dedicated an article to study the project of the MachineFi track, to find out the characteristics of a good MachineFi project.

1.Peaq Network

(1)Financing Information

peaq has raised a $6m funding round, led by Fundamental Labs. The funding will support the ongoing expansion of the peaq network, which empowers individuals and organizations to build, govern, and earn from dApps (decentralized applications) for vehicles, robots, and devices.

We have raised the funding to further expand the peaq network and ensure it is the driving force of a new, sustainable machine economy that enables people and machines to work better together. The funds will primarily be used to grow our stellar development team, with portions also set aside to roll out new products and features to the peaq ecosystem, and to increase awareness around the project in the run up to peaq’s bid for Polkadot parachain. peaq’s layer-1 blockchain is built with Substrate, making it natively compatible with Polkadot. To achieve seamless cross-chain interoperability with the rest of the Polkadot ecosystem, peaq will be running for Polkadot parachain. peaq provides identity, access, and payment capabilities as core functions for developers designing dApps for the EoT. In addition to receiving investment from Fundamental Labs, HashKey, Delta VC, and GSR, peaq has attracted investment from Mulana, Cypher Capital, GravityX, Waterdrip, Ceras Ventures, Masterventures, Moonrock Capital and Wami Capital.

“peaq has created a unique, open, and collaborative model of economic incentives that enables a diverse ecosystem of stakeholders to benefit from advancements in automation, via Machine DeFi and Machine NFTs. peaq provides a vital mechanism as we step closer to fulfilling the vision underpinning Web3. As the infrastructure of the next iteration of the Internet of Things blossoms, and as the benefits of blockchain technology in everyday life become clearer, the need for peaq’s machine-centric network becomes more and more apparent.”

- Eric Yang, Managing Partner at Fundamental Labs

(2)Introduction

In providing the peaq network as a neutral backbone for people to build dApps for machines, peaq aims to solve the societal and economic challenges associated with machine-related job automation, and ensure that anyone can benefit from machines providing goods and services to people and other machines — no matter how intelligent they become.

(3)The peaq Tech Stack

In order to achieve its mission, peaq developed it’s tech stack to provide all essential functions, interfaces, SDKs and financial tools for the stakeholders of the Economy of Things.

For investors it provides an easy way to provide liquidity and receive rewards via the NFT Minting and staking function. For dApp developers it provides a complete set of toolkits such as APIs and SDKs as well as Smart Contracts in order to develop EoT dApps easily and rapidly.

For machine manufacturers or operators and private owners of machines it provides the incentive mechanisms to add machines to the network by subsidising these and their identities when being added to the peaq network, as well as a simple way to receive rewards from their machines. It also provides the interface to add and manage machines.

(4)Feature

(5)The Machine DeFi Model of Peaq Network

How does peaq aim to create a decentralized and self-sustaining Economy of Things? How are we different from other projects in this space? In many ways — but the most important one is the way peaq leverages the full potential of the Web3, using tokens not just for transactions within the Economy of Things, but for ownership of machines too.

Peaq is introducing the concept of Machine NFTs to become the first network to align the incentives of all machine economy stakeholders, while creating an infinite loop of value creation on the peaq network.

(6) Network economics

The machine economy needs a machine centric economic model in order to flourish. Current efforts have only tried to make it work on top of our slow, legacy financial systems. The economy needs to benefit all stakeholders and enable self-sufficiency for machines.

In order to achieve this, the peaq network comes with novel macro- and microeconomic mechanisms, creating a machine-centric, self-sufficient economy that aligns the incentives of all stakeholders. The network is designed to create an infinite loop of value growth for the machine economy and its participants.

(7) The PEAQ Token

The $PEAQ token is much, much more than a means of payment. It enables every core function in the decentralized Economy of Things, including ownership of machines via NFTs and liquidity provision for DeFi mechanisms. It is the first token to power a machine economy that aligns the incentives of all network participants.

1) Machine DeFi

• Liquidity for Liquidity Pools must be provided in PEAQ
• Rewards to the community, machines, validators and nominators are handed out in PEAQ
• Liquidity Mining is performed using PEAQ

2) Machine NFTs

• Machine NFTs are LP tokens representing ownership of Liquidity Pools. Machine NFTs must be minted using PEAQ. Machine NFTs represent proxy partial ownership of machines and/or the machine economy and work to align all stakeholders.

3) Machine Economy Operations

• Transaction fees are paid in PEAQ
• Deployment of smart contracts is paid in PEAQ
• Network governance is performed using PEAQ
• Use of Web3 bridges is paid in PEAQ
• peaq network validators are rewarded in PEAQ

4) Machine Deployment

• The creation of new Machine Identities is paid for in PEAQ
• Subsidization for new devices/machines is received in PEAQ

Official website: https://www.peaq.network/.

2.Circulor

(1) Financing Information

London, 23 June 2022 — Circulor announces that it has raised $25 million (20 million GBP) in Series B funding, signaling growing market demand for more transparent and secure industrial supply chains. Circulor provides the most proven and mature solution for increasing supply chain visibility.

The Westly Group, a venture fund in Menlo Park, is leading the Series B round. HG Ventures of The Heritage Group is a new investor who brings strategic value across their transportation, materials, and environmental services business in North America. Existing investors Volvo Cars Technology Fund, SYSTEMIQ Capital, Jaguar Land Rover’s InMotion Ventures, Future Positive Capital, BHP Ventures, Salesforce Ventures, and 24Haymarket continued to participate in the round.

The new funds will be used to grow Circulor’s global footprint, with a focus on the North American market. Since completing its Series A in June 2021, Circulor has experienced rapid demand. New customers include BHP, Southwire, Trafigura, Jaguar Land Rover, Blackstone Minerals, Urbix Inc, Element 25, and more.

“In times of growing supply chain uncertainty, Circulor’s technology helps provide visibility and ESG analytics into complex supply chains to help companies make better business decisions,” said Steve Westly, Founder and Managing Partner of The Westly Group. “We’re pleased to lead this round and back a technology that provides a critical solution in today’s business environment.”

(2)Introduction

Amidst the many factors contributing to the climate crisis, the significant role of industrial supply chains can no longer be ignored.

Circulor provides the most complete and mature solution to this pressing global problem by enabling companies to gain visibility into their supply chains to demonstrate responsible sourcing, improve their ESG performance, reduce Greenhouse Gas (GHG) emissions and manage the supply chain risks.

We are a global business with growing teams based in EMEA, NA, and APAC, collaborating with clients worldwide to achieve their ESG ambitions.

(3) Solutions

All of Circulor’s solutions are developed on a private, permissioned-based enterprise SaaS platform that includes intuitive user interfaces, embedded business logic, clear dependencies, and integrated operations that are multilingual.

Our user-friendly desktop application can be used for fast manual upload, and our mobile application ensures an inclusive low barrier to entry for upstream participants.

Our technology has been designed for ease of integration with existing enterprise platforms; data can be fed seamlessly to the blockchain via system integration using RESTful Web Service APIs with security and authentication protocols.

Circulor advocates interoperability; we supported the establishment of the RMI Blockchain guidelines and contribute to leading-edge research in this space.

(4) Industry Applications

• Electric Vehicles

The critical energy transition is driving a shift to Electric Vehicles. We are overcoming the environmental and ethical concerns of these complex products by enabling manufacturers to prove the source of raw material. Our supply chain traceability solutions track emissions across the supply chain.

• Extractive Industries

Conflict minerals regulations are a vital way to break the chain between human rights abuses and consumer products.

We enable manufacturers to overcome the challenge of ensuring end-to-end compliance by providing an immutable record of provenance and a digital chain of custody across the supply chain.

• Plastics Recycling

Plastic pollution is a global crisis, as this poorly managed waste significantly affects people and the planet. Circular economy solutions, like ours, are needed to increase the uptake of recycled plastic, reduce the flow of plastics into our oceans and reduce GHG emissions.

• Construction

The Construction industry is having a significant impact on the planet due to unsustainable sourcing, poor waste management and a high carbon footprint; emitting over 10% of global emissions alone. Traceability enables decarbonisation of these GHG intensive materials and tracking of first and second-life to increase circular economy solutions for a sustainable future.

Official website: https://www.circulor.com/

3.MachineFi Lab

(1) Financing Information

Jun 7, 2022,MachineFi Lab, which incentivizes the collection of real-world Internet of Things (IoT) device data through decentralized applications (dapps), has raised $10 million in a seed funding round led by Samsung Next, Draper Dragon Fund and Jump Crypto. The round valued MachineFi at $100 million.

The funding will go toward platform development, hiring and potentially the incubation of early-stage projects building on the platform, MachineFi Lab CEO and founder Dr. Raullen Chai told CoinDesk in an interview.

Other investors in the round included Hashkey Capital, IOSG, Escape Velocity, Goodwater Capital, Xoogler Ventures, Wemade, Hanwha, Alpha Grep, DHVC, Vista Lab, Ribbit Angel Fund and NewBuild VC, among others.

(2)Introduction

MachineFi was launched last year by the team behind IoTeX, a blockchain that connects IoT devices, such as cameras and sensors, to dapps. The connection of real-world devices to blockchain data could have a wide range of use cases, but could prove particularly valuable for bringing the metaverse into the real world, and vice versa.

MachineFi offers a full infrastructure suite, including an Ethereum Virtual Machine (EVM) blockchain, multichain crypto wallet, blockchain bridge, an onboarding platform and software development kits (SDKs). The suite helps developers create dapps and machine networks.

(3)Workflow of MachineFi

IoTex hopes to directly promote the decentralization of the Internet of Things through the MachineFi project. Users can download the MachineFi Portal to apply, and the MachineFi Portal submits the data to the IoTex public chain for retrieval and conversion, and then sends it to the TruStream system to connect the devices. After the device uploads a valid proof of operation and receives a response to TruStream, it will send Meta data to TruSteam, and TruSteam will continuously update and upload the data and information to the IoTex public chain, and finally feedback it to the MachineFi Portal to form rewards and continuously update the latest device Data, users can withdraw the equipment income they own on MachineFi.

(4)Use Cases

• Machine “If This, Then That” (IFTTT)

Utilize machine intelligence (“Proof of Anything”) as inputs to smart contracts to trigger pre-defined business logic, where “If This” is a machine proof and “Then That” is a self-executing smart contract. This concept can be used to settle payments, manage service level agreements (SLAs), trigger notifications, and much more. With IFTTT, there are truly an infinite number of permutations of proofs and smart contracts to create new MachineFi use cases.

• Machine-as-a-Service

With IoTeX 2.0, machines will be able to deliver data, services, and intelligence to humans, businesses, and other machines and receive payment in a peer-to-peer fashion. Each machine can set its own terms and pricing for its unique menu of services, as well as select which counterparties they wish to authorize to use their services. This concept will sprout an army of useful and/or autonomous machines that can service society in a decentralized and transparent fashion.

• Fractional Ownership of Machines

machines that generate cash flows autonomously, such as robo-taxis, solar panels, and satellites, can be tokenized as non-fungible tokens (NFTs) and purchased by investors. NFT holders will own both the principal value of the machine as well as any future cash flows generated. This enables new financing opportunities — Initial Machine Offerings (IMO) — where capital for new machine networks is raised in exchange for future cash flows.

• Machine Intelligence Pools

Fleets of similar machines can band together to create standardized intelligence pools, replicating the massive data pools controlled by centralized organizations but from a bottoms-up, community-owned perspective. Similar to DeFi liquidity pools, those that contribute the most intelligence will receive the most ownership of the pool, as well as the most amount of revenue when third parties query these intelligence pools in a permission-less fashion.

• Machine Resource Marketplaces

A crowdsourcing-based approach that allows an entity to employ any number of machines to complete specific tasks. For instance, an environmental research institute can employ a distributed set of weather stations to monitor weather conditions of a specific geographic region without ever owning a weather station themselves, while weather station owners will be able to receive rewards in crypto for renting out their machine resources.

(5)Roadmap

IoTex has now launched the MachineFi Portal. Currently, 1w+ devices in 63 countries are connected to it, and it has a 50m+ data pool. According to IoTex forecasts, MachineFi will be connected to more than 100 billion devices by 2030. At present, MachineFi Portal can connect to some mainstream wallet applications such as: Metamask, ImToken, Trust, etc.

IoTex plans to release TruStream, an Oracle system for layer 2 machines, in Q1 2022. And in Q2 2022, the DID (identity authentication) system and IAM (access management) framework of machine equipment will be completed. Q3 and Q4 2022 Economicalization of the market platform for casting Machinefi, while providing developer tools. Finally, the cross-data link bridge is completed.

Official website:https://machinefi.com/lab.

4.Hexagon Wireless

(1)Financing Information

May 19, 2022, Hexagon Wireless is thrilled to announce that it has successfully closed a $2 million seed round capital raise, with participation from Hypersphere Ventures, Mechanism Capital, Superfluid Group, Inc., and strategic angel investors including Mahesh Ramakrishnan and Salvador Gala, formerly of Apollo and Ribbit Capital.

This seed round will help Hexagon purchase and deploy DeWi hardware and maintain and expand its team. Hexagon Wireless is working with enterprise partners, including real estate owners and infrastructure companies, to deploy DeWi mining hardware at scale.

“Scaling physical infrastructure for any blockchain (starting with bitcoin) has consistently been a valuable business,” said Brian Fakhoury, Partner, Mechanism Capital. “With decentralized wireless networks, the value is twofold — deployment at scale and professional operation reduces the need to sell rewards and instead allows for participation in the growth of these networks. Hexagon is in a position to capitalize on the expansion of this market perfectly.”

(2)Introduction

Founded by the former President of O’Leary Ventures — Alex Kenjeev — Hexagon Wireless is a company building at the intersection of wireless technology and crypto, in an emerging industry called decentralized wireless (DeWi). DeWi represents a revolutionary new model for building and maintaining wireless networks. By allowing anyone to purchase and deploy hardware that creates wireless coverage, DeWi democratizes ownership of and access to spectrum and internet connectivity. DeWi networks also offer data transfer and connectivity at much cheaper rates than current, centralized networks. This is because the massive costs of labor, rent, and spectrum purchases are distributed to each deployer of a DeWi network rather than one wireless carrier. Individuals and companies are incentivized to buy and deploy DeWi hardware as they are compensated with tokens from various protocols based on the quality of the coverage they provide and the amount of data transferred.

(3) Features

• Cheaper data

DeWi networks offer Internet connectivity for 5–10x cheaper than telecom companies

• Better Coverage

Blockchain-based token rewards fuel network growth exactly where people need it — at a pace that leaves antiquated telcos in the dust

• More privacy

Privacy is built in. DeWi networks don’t know who you are — and don’t need to

Official website:https://www.hexagonwireless.com/

5.Pollen Mobile

(1) Financing Information

April 19, 2022, Pollen Mobile announces the closure of a seed funding round that will accelerate the deployment of the world’s first privacy-focused, user owned and operated mobile carrier.

The investment round, led by Slow Ventures, was targeted at a diverse and strategically selected group of investors representing the telecom, crypto, hardware, entertainment, and traditional venture capital communities. Alongside Slow Ventures, participating investors included DISH Wireless, Delphi Digital, OVN Capital, and Acorn Pacific Ventures, among others.

“The world is long overdue for a genuine alternative to traditional mobile carriers who are known for customer dissatisfaction, high costs, spotty coverage, and a disregard for user privacy,” said Sam Lessin, General Partner at Slow Ventures. “Our belief in Pollen’s vision and the Pollen team has already been validated by the incredibly enthusiastic reception from the rapidly growing Pollen community.”

(2)Introduction

Pollen was started by Pronto, a San Francisco company that develops autonomous driving technology for off-road applications. Our technology requires reliable and affordable mobile connectivity, which we weren’t getting with legacy carriers, so we built our own network. We soon realized we could open up our technology and enable the world’s first decentralized, privacy-focused, affordable mobile network owned and operated by its users.

(3)How it works

Pollen is simple. You provide network coverage through a Flower, which is validated by Bumblebees, and you connect to the network as a Hummingbird with an eSIM– each of which earn you PollenCoin.

• Flowers To The People

Flowers are antennas that wirelessly transfer data between your internet service provider and users of the Pollen network. They range from the size of a pizza box to a six-foot tower and can be placed anywhere, such as your home or office.

• Move like a butterfly, Validate like a Bumblebee

Bumblebees are small, portable devices used to validate Pollen network coverage. They collect data from Flowers, such as signal strength and internet connection speeds. Bumblebees are best used while traveling in your car, on a bike, or other vehicles to validate network coverage while you’re on the go.

• Connect as free as a Hummingbird

Hummingbirds are what your smartphones become after downloading and importing the Pollen eSIM. Once it’s set up, you’re able to connect to the network privately and securely — all while earning you PollenCoin. A Hummingbird’s ability to connect will vary as the community builds the network.

(4)Roadmap

Pollen will be deployed in three phases.

Official website:https://www.pollenmobile.io/.

References：

(1)https://www.peaq.network/blog/peaq-raises-6-million-funding-to-power-the-economy-of-things

(2)https://www.globenewswire.com/news-release/2022/05/19/2447081/0/en/Hexagon-Wireless-Raises-2-Million-To-Build-Decentralized-Wireless-Networks.html

(3)<The Rise of MachineFi>

(4) https://www.globenewswire.com/news-release/2022/04/19/2424680/0/en/Pollen-Mobile-Closes-Seed-Funding-Round-for-Its-Next-Generation-Decentralized-Wireless-Network.html

May, 2022

This report includes key analysis of research, guides and resources and project updates in zero knowledge proof technology.

1. Research

(1)《Lattice-Based Zero-Knowledge Proofs and Applications:

Shorter, Simpler, and More General》

In this paper, the authors propose an improved zero-knowledge proof method Lattice-Based zero-knowledge proofs. This new proof system can be plugged into constructions of various lattice-based privacy primitives in a black-box manner. As example, we instantiate a verifiable encryption scheme and a group signature scheme which are more than twice as compact as the previously best solutions.

(2)《zkKYC in DeFi: An approach for implementing the zkKYC solution concept in Decentralized Finance》

This paper presents a solution concept for where a DeFi protocol is required or finds it desirable to implement KYC policies. zkKYC in DeFi requires no personal identifiable information to be shared with DeFi protocols for the purpose of regulatory transparency. The presented approach extends the zkKYC solution concept (which leverages self-sovereign identity and zero-knowledge proofs) with the introduction of KYC Issuers and Decentralized Oracle Networks (DONs) as key solution components. KYC Issuers verify the identity of an individual, but have no knowledge about their digital asset wallets or DeFi activity. DeFi protocols interact with digital asset wallets, but have no knowledge about the identity of the individual controlling them. If and when deemed necessary, only a designated governance entity is able to reveal the identity of an individual that is under strong suspicion of being a bad actor in a DeFi protocol. The presented solution architecture demonstrates flexibility in being agnostic to blockchain platforms and SSI¹ implementations and extensibility in being forward compatible with on-chain identity and reputation systems. Similar to the original zkKYC solution concept, zkKYC in DeFi breaks the regulatory transparency vs. user privacy trade-off.

1)zkKYC

Overview

zkKYC extends the self-sovereign identity (SSI) model, leveraging verifiable credentials (VC) and decentralized identifiers (DID). The key improvement is that individuals (i.e. Holders) no longer have to provide personal identifiable information to each business (i.e. Verifier) that they create a relationship with. This is achieved using a circular ecosystem design with clear role definitions and modern technologies, including zero-knowledge proofs.

Interactions and Concepts Trustworthy Issuers issue verifiable credentials to Holders. Verifiable credentials provide a mechanism to express traditional credentials digitally, cryptographically secure, privacy respecting and machine-verifiable. The Issuer cryptographically signs verifiable credentials with the secret key associated with their decentralized identifier (DIDI ). Using the publicly available public key associated with the Issuer’s DID, anyone can easily verify the integrity and authenticity of a verifiable credential that Issuer issued. Where a Holder is an individual, they would typically generate a unique DID for each distinct relationship they have. This helps to enhance their privacy, as only they then know and control the link between all these different DIDs. In the diagram above, you can see that Holder has DIDHV for its relationship with Issuer and DIDHI for its relationship with Verifier. In zkKYC, Holders do not present to Verifiers the actual verifiable credentials that were issued to them. This could share personal identifiable information. Rather, Holders use the verifiable credentials in their digital identity wallet to generate and present the following three objects to Verifier:

• Eligibility Proofs: zero-knowledge proof that the Holder meets the (business) criteria set out by the Verifier to be able to provide access to the requested service. These proofs leverage the information in verifiable credentials and their signatures, but without disclosing the actual information itself. Examples include proof that the Holder is above a minimum age, a domestic resident, not on a sanctions list, not a politically exposed person etc.
• zkKYC token: an encrypted data object that contains decentralized identifiers (DIDs) to enable the Holder’s identity to be revealed to parties in Government role only. Specifically, it is a data object encrypted with Government’s public key. The data object contains DIDI , DIDHI , DIDV and DIDHV . DIDV and DIDHV make the token unique and specific to Verifier so they are of no value to others.
• Validity Proofs: zero-knowledge proof that the presented zkKYC token contains the correct information, without disclosing what that information is, and is encrypted using the provided Government public key.Given that Verifier cannot read the content of the zkKYC token, they need proof that the correct information is included, to prevent bad actors from inserting false information.

2) Architectural Overview After introducing the concept of zkKYC, let’s take a look at the architecture overview of zkKYC in DeFi. The diagram below provides an architectural overview for implementing the zkKYC solution concept in DeFi. It overlays the zkKYC ecosystem model with the identified solution components that are particular to the DeFi context and their interactions.These components are described below.

SSI Wallet Holders store the verifiable credential issued by a KYC Issuer in their SSI wallet. It reflects the outcome of their KYC process and serves as a critical element of the zkKYC solution concept. Based on this verifiable credential, the SSI wallet can generate the eligibility proofs requested by the Verifier, as well as the zkKYC token and associated validity proof.

Digital Asset Wallet The private keys associated with the Holder’s digital assets are stored in their digital asset wallet. These private keys enable the Holder to control and transfer digital assets on-chain or prove they do control a particular wallet address associated with the public key. The Digital Asset Wallet may also store the private keys of any micro-credentials (as NFTs) that support the Holder’s on-chain reputation.

User Interface The user interface of the Verifier is a rather abstract component. It represents the interface for a Holder and their wallets to interact with the Verifier. Functionally, this component represents a user interface for zkKYC interactions and a user interface for DeFi protocol interactions:

• zkKYC: a website or app for a Holder’s SSI and digital asset wallets to interact with the DON for the purpose of zkKYC. Alternatively, this interface could also be implemented as APIs in developer SDKs or into the wallets directly.
• DeFi Protocol: a website or app for a Holder’s digital asset wallet to interact with the DeFi protocol smart contracts on the blockchain. It can be implemented to access a DeFi protocol specifically (e.g. https://app.uniswap.org) or as an aggregator service (e.g. https://app.1inch.io). It can also be implemented within a development platform (e.g. Remix2) or block explorer (e.g. Etherscan3) to interact directly with the smart contracts on-chain. Last, this interface could also be implemented as a smart contract developed and deployed by the Holder, which interacts on-chain with the DeFi protocol smart contracts.

Decentralized Oracle Network (DON) The key responsibility of the DON is to provide a reliable and trusted communication bridge between the Holder and the DeFi protocol for the purpose of zkKYC. It serves as a Verifier proxy for the DeFi protocol and allows for trustless KYC verification. Based on a DeFi protocol specific configuration profile and the use case at hand, the DON interacts with the Holder’s SSI wallet and issues a request for authentication or the presentation of zkKYC specific data elements including eligibility proofs, a zkKYC token encrypted with the particular public key of Government and the associated validity proof. Each node of the oracle network will receive and verify zkKYC data from the Holder, come to consensus with the other nodes on the verification outcome and elect one oracle node to submit the outcome to the oracle smart contract on-chain. The elected oracle node is also responsible to store the relevant proofs and zkKYC token on the decentralized storage (see below). Given that the oracle network represents the DeFi protocol towards the Holder for the purpose of zkKYC, its nodes must receive delegation authority by the DeFi protocol to control its DIDV. This is required to establish the underlying SSI interactions with the Holder, which the oracle network is able to do given it runs off-chain.

The DON also requests proof from the Holder that they control a particular digital asset wallet. To do this, it asks the Holder to generate a digital signature using the wallet’s private key that they control. Then, it cryptographically verifies whether that signature matches with the digital asset wallet’s public key. The oracle nodes can perform additional verifications of the digital asset wallet such as verifying it against a black list or watch list, published by trusted authorities.

Decentralized Storage Decentralized storage is used by the DON to store DeFi protocol specific configuration files as well as zkKYC verification proofs and zkKYC tokens. These Holder and DeFi protocol specific data sets must be strongly secured and guaranteed to be only accessible by authorised parties and under strict conditions. The implementation options for this component, along with possible technologies and design trade-offs, are out of scope of this paper. Options can range from a single distributed platform with advanced access rights management to DON and DeFi protocol specific platforms and technologies with standardised interfaces in order to maintain more control and sovereignty.

Oracle Smart Contracts The elected oracle node of the DON submits the outcome of the zkKYC verification to the oracle smart contracts on-chain. These smart contracts connect the DON with the DeFi protocol. The oracle smart contracts keep track via a whitelist for each DeFi protocol which of their users (i.e. DIDHV ) have successfully passed zkKYC verification. Remember that DIDHV is a unique identifier of the Holder, specific towards the DeFi protocol (i.e. Verifier). It is not re-used across Verifiers. For most blockchains, it will be linked to the digital asset wallet address of the Holder. For this reason, using different digital asset wallets across DeFi protocols will further improve user privacy. DeFi Protocol Smart Contracts The DeFi protocol smart contracts constitute the DeFi protocol as such and are responsible for processing DeFi transactions submitted by the Holder.

DeFi Protocol Governance Each DeFi protocol that implements KYC processes is assumed to have some sort of governance entity. This can be decentralized in the form of a Decentralized Autonomous Organization (DAO) or centralized via a traditional legal entity. The governance entity is responsible for interacting with Government and retrieving the necessary data (e.g. DIDHV , zkKYC token, transaction data) from the blockchain or decentralized storage.

(3)《Multi-Party Computation in the GDPR》

This paper aims for a better understanding of the role of MPC in the GDPR. Although MPC is relatively mature, little research was dedicated to its GDPR compliance. First, we try to give an understanding of MPC for legal scholars and policymakers. Then, we examine the GDPR relevant provisions regarding MPC with a technical audience in mind. Finally, we devise a test that can assess the impact of a given MPC solution with regard to the GDPR.

The test consists of several questions, which a controller can answer without the help of a technical or legal expert. Going through the questions will classify the MPC solution as (1) a means of avoiding the GDPR, (2) Data Protection by Design, or (3) having no legal benefits. Two concrete case studies should provide a blueprint on how to apply the test. We hope that this work also contributes to an interdisciplinary discussion of MPC certification and standardization.

2. Guides and Resources

（1）Zero-Knowledge-Proof Mining

This year, Ethereum will switch from PoW to PoS so that the blockchain mining market will shrink significantly. Although storage mining has emerged in recent years, including Filecoin, Chia, and Arweave, it is still unable to meet the market vacancy caused by the exit of Ethereum. On the other hand, ZKP has some early applications in blockchain mining. There is a marketplace in Mina for ZKP workers to submit their generated proofs to earn tokens. In Filecoin, miners need to generate ZKP for every data sector stored off-chain, thus gaining storage power.

We can see that traditional hash mining is surrounded by controversies about energy wasting, meaningless computation. Therefore, the blockchain area is trying to find a meaningful mining method. The properties of ZKP (proving arbitrary statement, complex proving but simple verification) provide more possibilities to the blockchain mining market.

We are focusing on some ZKP mining projects this year：

• L2 transactions: zk-Rollup projects like zkSync, StarkWare
• L1 transactions: Mina
• Off-chain data: Filecoin

（2）Battleship on RISC ZERO — Battleship with Rust and RISC Zero’s ZKVM

In RISC Zero’s Battleship, we apply the power of zero knowledge proofs (ZKPs) using the RISC Zero Zero-Knowledge Virtual Machine (ZKVM) to build a trustless game of Battleship in Rust. The players each maintain their private game state, yet every step of the game is cryptographically checked to prevent cheating. The patterns in this code may be applied to build new secure, decentralized applications in finance, governance, information security, etc.

(3) ZK Machine Learning — A tutorial and demo

1）Introduction

In this tutorial post, together with the associated repo and demo webapp, we explore how zero knowledge proofs can help lift these barriers by performing computations off-chain and providing a proof that this computation was correctly executed, while shielding private data. The proof can then be verified on-chain for a much smaller computational cost, enabling us to implement on-chain, private machine learning.

For this demo, we focused on the implementation of a simple computer vision deep learning convolutional neural network for handwritten digit recognition (MNIST).

2）Demo

To check out the demo, please follow the instructions in this github repo, or play with the webapp demo at: https://zkmnist.netlify.app/

The webapp allows the user to “draw” a digit or to select an image of a digit from examples taken from the MNIST dataset. This handwritten digit can then be classified by the neural network, outputting a predicted digit as well as a zero-knowledge proof that you have an inpu image that is classified by the ML model to yield a specific digit. Finally, this proof can be verified on-chain via a smart contract.

3. Project Updates

（1）Aztec

• Countdown to Aztec Connect: The countdown to Aztec Connect’s mainnet launch has officially begun. It is planned for June 9th, 2022. Ethereum users are about to access the full spectrum of Ethereum DeFi applications with Aztec’s ironclad privacy guarantees, starting with our launch integrations: liquid stake ETH on Lido and get fixed yields on Element with full privacy protection.
• Aztec Network Raises Total Bug Bounty to $2 Million: The team released Aztec Connect’s codebase — and rewards totaling $2 million+ via the Aztec Bug Bounty. For full program details, eligibility requirements, and vulnerabilities included in the bug bounty.
• Aztec Network has crossed 200,000 transactions in production.

（2）Mezcal, A New Vision For Celo

We propose the following architecture for the future of Celo: Celo should become a Layer-2 ecosystem. Furthermore, we think it should be an EVM-compatible and Interoperable L2 that focuses on its core mission without worrying about L1 consensus. We all agree that one of the best networks to help achieve this vision is Celestia. Celestia is the first modular blockchain network, which has created what is known as the data-availability layer, providing the consensus mechanism and ordering of transactions while separating execution to Layer 2. Here, all Celo needs to do as an L2 is data-availability sampling from Celestia for the transactions relevant for Celo’s network. It doesn’t even need to download the entire Celestia block, just the transactions relevant to Celo.

This can help to solve many points highlighted in this article:

• Celo will no longer bear the burden of worry about validators and consensus issues, because it will use the Celestia network for this shared-security and data availability approach.
• Celestia as a modular blockchain provides Celo with a customizations, while still allowing Celo to focus on its mission.
• Celo can better focus on its mission as a network, including using the core contracts as-is, by using them as part of a new L2 Rollup network just for Celo. Core developers need not worry anymore about consensus, and can just focus on improving the EVM on Celo.
• Valora and other future wallets can still resort to using their federated attestation model on the L2 system.
• The attestation service system that both has no incentive system and is costing validators money can be phased out.
• When it comes to light clients — and given the Celestia architecture not requiring the download of entire blocks — the more light nodes that are being run in the network, the larger the block size can be, which provides major scalability improvements.
• Scalability improvements for Celo means transactions stay affordable.

（3）Loopring Quarterly Update (Q1/2022)

Major Milestones in Q1/2022：

• Over $4.6 billion in Trading Volume on Loopring L2
• Over 3 million NFTs minted on Loopring L2 following the official launch of open minting on Layer 2
• Over 65,000 L2 accounts and almost 30,000 Loopring Smart Wallets are now activated — with over 12,000 new wallets added in Q1 alone

More rapid social growth in Q1 (2022):

• 100,000 Lööpers now on Reddit
• Nearing 200,000 followers on Twitter
• A highly active Discord community with almost 30,000 members

¹SSI is the abbreviation of Self-Sovereign Identity.

References：

（1）《Lattice-Based Zero-Knowledge Proofs and Applications:

Shorter, Simpler, and More General》

（2）《zkKYC in DeFi: An approach for implementing the zkKYC solution concept in Decentralized Finance》

（3）《Multi-Party Computation in the GDPR》

（4）https://medium.com/6block/zero-knowledge-proof-mining-9bc12fbbbd55

（5）https://www.risczero.com/docs/tutorial-examples/battleship_rust_tutorial

（6）https://0xparc.org/blog/zk-mnist

（7）https://medium.com/paradigm-fund/l2-report-vol-2-a497fab0aa83

（8）https://mirror.xyz/ocelotlabs.eth/9vtP5Tc-V_zRTMZ907DmmCWxUgIS4g-nKMrsckcZW7A

（9）https://medium.loopring.io/loopring-quarterly-update-q1-2022-cd4b6e229551

zkSync in a sentence

zkSync is a trustless protocol for scalable low-cost payments on Ethereum and is powered by zkRollup technology.

3 takeaways from zkSync:

1. Fast with low fee

2. Trustless to both on/off chain data

3. Secured as mainnet

What are Rollups and what are ZKRollups

Since the zkSync is powered by zkRollup technology, let us first talk about what the Rollups are. Rollups are the scalability solution for Ethereum that is congested at an exponential rate. To tackle this congestion on Ethereum, there are mainly two ways to scale. First, you can make the blockchain itself have a higher transaction capacity. Secondly, you can change the way that you use the blockchain. For the first method, developers can either increase the efficiency of client software or use techniques such as sharding¹ to allow the work of building and verifying the chain to be split up across many nodes; the effort known as “eth2” is currently building this upgrade to Ethereum. For the second method, users perform the bulk of their activity off-chain in a “layer 2” protocol. There is a smart contract on-chain, which only has two tasks: processing deposits and withdrawals, and verifying proofs that everything happening off-chain is following the rules.

Rollups are the layer 2 method to tackle the scalability issue on Ethereum mainnet. Rollups, in brief, move computation off-chain but keep some data per transaction onchain. The result turns out to be costing only about 1/100th the original cost on Ethereum mainnnet.

ZK rollups stand for zero-knowledge, aka trustless, rollups which use validity proofs. Besides, validity proofs make every batch includes a cryptographic proof called a ZKSNARK, which only proves that the post-state root is the correct result of executing the batch, a faster way of proving.

For more information on ZK-Rollups please refer to our January research named ZKrollups 生态与应用场景研究.

The Features of zkSync

How zkSync works?

a. Characters in ecosystem:

1. Validator: Validators are responsible for packing transactions into blocks and generating zero-knowledge proofs for them. They participate in the consensus and must, therefore, contribute a share of the security bond for instant tx receipts. Their nodes must run in a secure environment with good internet bandwidth. Validators are rewarded with transaction fees, which can be paid in any token being transacted. In order to keep the zkSync consensus fast, only a limited number of validators are allowed at any moment, between 30 and 100.

2. Guardian: Guardians comprise the majority of ZK Sync token holders who stake their token share to nominate validators. The purpose of Guardians is to monitor peer-to-peer transaction traffic, detect censorship behavior, and ensure validators caught censoring are not nominated. The motivation of Guardians is to protect the value of their stake by making sure that ZK Sync remains DoS- and censorship-resistant. Guardians are rewarded with fees from the Validators denominated in the zkSync native token. Their earnings and stakes are locked for a prolonged period of time, to incentivize the prioritization of long-term ZK Sync token value over short-term returns.

b. The transaction process in steps:

1. Users sign transactions and submit them to validators.

2. Validators roll up thousands of transactions together in a single block and submit a cryptographic commitment (the root hash) of the new state to the smart contract on mainnet along with a cryptographic proof, a SNARK, which this new state is indeed the result of the application of some correct transactions to the old state.

3. In addition to the proof, the state, a small amount of data for every transaction, is published over the mainchain network. This enables anyone to reconstruct the state at any moment.

4. The proof and the state are verified by the smart contract, thus verifying both the validity of all the transactions included in the block and the block data availability.

In fact, the proof time generation is expected to be about 10 minutes and the is as final as any layer 1 Ethereum transaction included in the same Ethereum block as the transaction with the proof. Theoretically speaking, user need to wait for the block to get filled and don’t acquire the proof immediately. There is instant confirmation mechanism that make transactions submitted to zkSync by users are instantly confirmed. The transaction result instantly displayed to the receiving party in the UI and API, though they are marked as unconfirmed, and the transferred assets can immediately be used to make further transfers. At the moment, instant confirmations are pure promise on the side of zkSync validators to include the transaction in the next block². Users who do not trust the validator should await full finality before considering the assets as received.

In the future, a security bond will be added to zkSync by the validators. This will provide instant economic finality guarantees. Validators elected to participate in the zkSync block production will have to post a significant security bond to the zkSync smart contract on the mainnet. A consensus run by the validators provides a subsecond confirmation to the user that their transaction will be included in the next zkSync block.

c. Fee Costs: In zkSync, the cost of every transaction has two components:

1. Off-chain part (storage + prover costs): About 0.001 USD per transfer, including the cost of the state storage and the SNARK, zero-knowledge proof, generation. This part depends on the use of hardware resources and is therefore invariable.

2. On-chain part (gas costs): For every zkSync block, the validator must pay Ethereum gas to verify the SNARK + about 0.4k gas per transaction to publish the state. Leveraging the rollups technology, this part is still cheaper than the cost of normal ETH/ERC20 transfers.

What make zkSync more convenient is that users pay transaction fees in the tokens being transferred. Thus, for example, if you want to transfer DAI stablecoin, there is no need for you to own ETH or any other tokens. Just pay your fees in a fraction of DAI.

zkSync sounds good but safe?!

Let us analyze the safety of zkSync in following aspects:

a. Validity Proof: If a new zkSync block is produced and submitted to the mainchain, it cannot be reverted. Besides, zkSync is built on zkRollup, every single transaction is verified by a smart contract on the Ethereum mainnet by means of verifying the proof of the validity of the block.

b. Instant Confirmation: If validators fail to do jobs and don’t contain the promised transactions, the security bond of the intersection of the signers of the original receipt and the signers of the new block will be slashed. This intersection is guaranteed to have more than ⅓ of the stake. This guarantees that at least ⅓ of the security bond can be slashed and that only malicious validators will be punished. A portion of the slashed funds will be used to compensate the tx recipient. The rest will be burned.

c. Exit clear: In the ultimate emergency case of all validators being shut down or becoming unresponsive, the emergency exit mechanism ensures that users will keep control of their assets. Exit request can be submitted directly on mainnet into the priority queue. Validators are obliged to process priority queue requests within one week. In case the validators fail to process the requests, the system enters exodus mode and every user can immediately exit all of their assets by making a direct transaction on the Ethereum mainnet.

zkSync Features Summary:

➢ Mainnet-level security with zero reliance on 3rd parties

➢ ETH and ERC20 token transfers with instant confirmations and withdrawals to mainnet in about 10 minutes

➢ Ultra-low transaction fees and conveniently payable in the token being transferred

➢ No registration is required to receive funds and could pay to existing Ethereum addresses

zkPorter: the turbo upgrade brings to zkSync

Rollups are not enough

zkSync built on zkRollups architecture that make on-chain fees manageable. But even with rollups, we’ll probably end up right back where we started. This is because any realistic increase in throughput will quickly get eaten up by induced demand³. In fact, Rollups can only offer a linear increase in throughput, all data still must be propagated to all full nodes. However, to bring true scalability, we need an exponential gain in throughput.

Ethereum is growing at exponential rate. In one year, the number of DeFi Users increased from 150k to 1.8 million, but gas fees grew 16 times faster, fees grew from $0.20 to $36 per Uniswap trade. This is due to any improvement of scalability will be accompanied by an increase in trading. Besides, zkRollups support the EVM compatibility, facilitating a quick and simple migration of applications from layer 1 to layer 2.

The reveal of zkPorter

To recall that zkSync is built on zkRollups architecture that put data on chain with SNARKs proof. zkSync 2.0 with zkPorter that divided architecture into 2 sides: zkRollup with on-chain data availability and zkPorter with off-chain data availability. The introduction of zkPorter enable TPS to grow exponentially and meet the potential surging demand.

The reason that zkPorter is named zkSync 2.0 is because contracts and accounts on the zkRollup side will be able to seamlessly interact with accounts on the zkPorter side, or vice versa. What’s even better is that because zkPorter’s off-chain data characteristics, fees for zkPorter accounts are reduced 100 times. zkPorter accounts require only a single update to be published to Ethereum, the costs of publishing data on Ethereum cut accordingly.

Again, how about security on zkPorter

In brief, the zkPorter is still secured though a little inferior to zkSync full built on zkRollup architecture with on-chain data availability. The data availability of zkPorter accounts will be secured by Guardians, zkSync token holders. They will keep track of state on the zkPorter side by signing blocks to confirm data availability of zkPorter accounts. Guardians participate in proof of stake (PoS) with the zkSync token, so any failure of data availability will cause them to get slashed. This gives cryptoeconomic guarantees of the data availability. Besides, zkSync guardians are essentially powerless and can’t steal funds. They can only freeze the zkPorter state, aka freezing their own stake.

However, users are free to opt into their own security threshold. Any user who wants all data available on-chain can stay completely on the rollup side. But if you are a feesensitive user, you will definitely choose zkPorter.

Summary

The Ethereum mainnet is cramped with more usage and transaction taking place. Rollups, a layer 2 solution, ease the issue temporary. The more affordable the transaction is the more intensive the traffic will be. Finding out the solution with capability of offering TPS exponentially is essential to mainnet scaling or even layer 2 scaling. This is the background that zkSync 2.0 with zkPorter arise. Having part of data on-chain and part of data off-chain, this brings down the cost significantly and increase the capability to handle transaction dramatically. With security level high and protecting mechanism set up for exiting, zkSync is prospective for massive adoption.

¹ sharding is a new mechanism, where only a small subset of nodes verifies each transaction.

² signed by a supermajority of (more than) ⅔ of the consensus participants (weighted by stake).

³ the phenomenon that after supply increases, price declines and more of a good is consumed.

Reference

(1) https://zksync.io/

(2) https://vitalik.ca/general/2021/01/05/rollup.html

(3) https://eth.wiki/sharding/Sharding-FAQs

(4) https://docs.zksync.io/userdocs/tech.html#instant-confirmations

(5) https://twitter.com/zksync

(6) https://blog.matter-labs.io/introducing-zk-sync-the-missing-link-to-mass-adoption-of-ethereum-14c9cea83f58

(7) https://docs.zksync.io/zkevm/#general

(8) https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf