Abstract: This paper primarily examines the work of Ulrich Haböck et al. titled "Circle STARKs," interpreting Circle FFT and its implementation aspects. The analysis focuses on three main areas: 1) the foundation for accelerating basic operations with CFFT; 2) the implementation of CFFT calculations; and 3) the coding implementation of CFFT. 1. Introduction In traditional STARKs, Fast Fourier Transform (FFT) is used to efficiently perform interpolation and write adjacent row constraints. To utilize FFT for fundamental polynomial operations, the finite field ${\mathbb{F}_{p}}$ must possess a smooth-order root of unity. Besides the FFT itself, the choice of finite field $p$ directly influences the complexity of arithmetic operations, thereby impacting the efficiency of STARKs. The most effective field for arithmetic operations is the Mersenne prime field, specifically $p = {2}^{e} - 1$. Notably, $p = {2}^{31} - 1$ allows for highly efficient arithmetic operations on 32-bit computers. For these reasons, traditional FFT is inadequate in meeting the efficiency demands of STARKs. In reference [1], the authors continue the ECFFT [2][3] approach, constructing Circle STARKs based on the Mersenne prime $p = {2}^{31} - 1$ on the circle defined by the equation ${x}^{2} + {y}^{2} = 1$. The core innovation lies in the introduction of Circle FFT (CFFT) within STARKs. 2. Circle FFT 2.1 Fundamentals of CFFT The choice of field significantly affects the efficiency of FFT acceleration and the feasibility of using FFT for this purpose. A prime $p$ that is friendly to CFFT possesses the property $p \equiv 3 \bmod 4$. The set of $p+1$ points on the curve $C = C\left( {{\mathbb{F}}{p}} \right)$ forms a group, defined by the group operation $\left( {{x}{0}},{{y}{0}} \right) \centerdot \left( {{x}{1}},{{y}{1}} \right) := \left( {{x}{0}}{{x}{1}} - {{y}{0}}{{y}{1}}, {{x}{0}}{{y}{1}} + {{x}{1}}{{y}{0}} \right)$, where the circular group $C\left( {{\mathbb{F}}{p}} \right)$ is a cyclic group. Additionally, we define the rotation operation ${{T}_{P}}\left( x,y \right) := P \centerdot \left( x,y \right)$, the squaring map $\pi \left( x,y \right) := \left( x,y \right) \centerdot \left( x,y \right)$, and the group inverse $J\left( x,y \right) := \left( x,-y \right)$. When using FFT acceleration, the length of the coefficients to be computed must be ${2}^{n} \left( n \ge 1 \right)$. For CFFT, we define a double coset of size $N = {2}^{n}$ as $D = Q \cdot {{G}{n-1}} \cup {{Q}^{-1}} \cdot {{G}{n-1}}$. Here, ${{G}{n-1}}$ is a subgroup of size ${2}^{n-1}$ of $C\left( {{\mathbb{F}}{p}} \right)$, and $Q \in C\left( {{\mathbb{F}}{p}} \right)$. When the prime $p \equiv 3 \bmod 4$, we have $D = Q \cdot {{G}{n}} = Q \cdot {{G}{n-1}} \cup {{Q}^{-1}} \cdot {{G}{n-1}}$. When $D$ is a coset of the subgroup ${{G}{n}}$, it is the standard position coset of size $N$. Furthermore, under the squaring map, the set $\pi \left( D \right)$ of size $N/2$ shares the same properties as $D$, meaning it is also a double coset or standard coset. The standard position coset is illustrated in Figure 1, where the elements are evenly distributed along the circle, corresponding to the binary size of the set. For $n\ge 1$，${{\pi }^{n-1}}(D)=\left{ ({{x}{D}},{{y}{D}}) \right}$ contains only two elements.

OlaVM temp (1) 1. Background As of September 21st, the total value locked (TVL) in cryptocurrency was approximately $86 Billion according to DefiLlama data. Bitcoin accounts for over $10 Billion of this, reflecting a strong demand for multi-cryptocurrency staking in the market. According to data from coingecko.com, Bitcoin's current total market capitalization is approximately $1200 Billion (21 million X $62,000 USD/coin), with a circulating supply of 19,757,462 coins, roughly 9.4% of the total supply. Furthermore, data from Coinshares in March last year revealed that 25% of the circulating Bitcoin supply has been idle for over five years, 67% for over a year, and over 66% of the circulating supply remains in its current state. This large volume of idle Bitcoin not only represents a waste of assets but also fails to leverage Bitcoin's powerful security and decentralization advantages, hindering the development of the blockchain ecosystem. Lending or staking Bitcoin is a viable approach to revitalizing these assets, with applications including crypto lending and Bitcoin bridging. The primary concern in revitalizing Bitcoin assets is security, followed by flexibility and yield. The blockchain world, beyond Bitcoin, has witnessed the rise of Ethereum as a valuable public chain. Both have maintained their leading positions due to their core values of security, decentralization, and value consensus. In the Ethereum ecosystem, EigenLayer, a renowned re-staking protocol, leverages unique design and technological innovation to enable application chains to share the security of the Ethereum ecosystem. This security is underpinned by Ethereum assets, and stakers can earn rewards through staking. For Bitcoin, security is primarily based on the massive hash power of Proof-of-Work (PoW) miners. As mining difficulty increases, the world's most secure blockchain becomes even more secure. Compared to the modular approach of re-creating a blockchain with comparable security to Bitcoin and Ethereum while offering superior cost and performance, or relying on a sufficiently secure Layer 1 as the third layer or partial functional layer for Rollups, leveraging the security of the most secure public chain, Bitcoin, to create shared security services is a viable option, exemplified by Babylon. It inherits the security of the Bitcoin chain while granting its assets more value and flexibility. 2. Babylon Protocol PoS (Proof-of-Stack) chains boast high energy efficiency and rapid finality, but they face several security vulnerabilities: susceptibility to unpunishable long-term security attacks, low active elasticity, and difficulty in launching from low token valuations. Without external trusted sources, PoS chains alone cannot resolve these security issues. The Babylon Protocol, a suite of Bitcoin staking protocols, allows Bitcoin holders to stake their Bitcoin without trusting any third party, offering security guarantees for staked assets. The protocol's key lies in sharing the security features of the Bitcoin chain. However, what specific Bitcoin features can be shared by the Babylon Protocol?

1. 引言 区块链技术的迅速发展催生了一个多链世界，每个区块链网络都在追求其独特的功能和应用场景。然而，这种多样性也带来了显著的挑战，尤其是在链与链之间的互操作性方面。Ola 致力于打破区块链之间的壁垒，推动跨链技术的发展，为去中心化应用 (DApps) 和去中心化金融 (DeFi) 提供更广泛的应用场景。 作为 Ola 项目的核心技术，Onis 解决方案不仅解决了现有跨链技术的局限性，还结合了团队在零知识证明 (zk) 方面的深厚技术积累，打造了一个既安全又去中心化的跨链互操作性网络。 2. 市场背景 当前的区块链生态中，跨链互操作性的问题不仅限制了不同链上资产和应用的交互，还带来了巨大的安全风险。跨链桥接作为实现不同链之间资产转移的关键技术，频频出现安全漏洞，导致大量资产被盗。据 Rekt（https://rekt.news/leaderboard/） 数据显示，由于跨链技术的 bug 或错误，已经造成了数十亿美元的资产损失。这种情况下，开发一个安全、去中心化的跨链解决方案变得尤为重要。 Ola 的 Onis 解决方案正是为了应对这一重大挑战而设计，通过其去中心化的架构和先进的 zkP 软验证技术，Onis 旨在提供一个安全、可信的跨链互操作性平台，保护用户资产，为区块链的跨链操作提供了一个更安全、更去中心化的选择。

In blockchain technology, reducing computational complexity has always been one of its primary goals. One effective approach to achieving this is by reducing the bit width of the computation field. For example, SNARKs based on elliptic curves perform arithmetic operations in fields with bit widths of 256 or higher, while STARKs have evolved from using the 64-bit Goldilocks field to the 31-bit Mersenne31 and BabyBear fields. Beyond the efficiency of the prime numbers themselves during modular operations, the significant reduction in bit width has led to Plonky2 being hundreds of times faster than its predecessor, Plonky. Following this trajectory, one might wonder: is it possible to set the field width to 1, specifically ${\mathbb{F}}_{2}$? The Ulvetanna (IRREDUCIBLE) team addressed this question in their research paper titled Succinct Arguments over Towers of Binary Fields [1], implemented it in Rust with their project, Binius: a Hardware-Optimized SNARK [2][3]. Since its release, Binius has garnered significant attention in the ZK (Zero-Knowledge) community. The LambdaClass team has provided several technical analyses [4][5][6], and Vitalik Buterin offered a more accessible explanation [7]. In this article, we will explore the foundations of Binius, focusing on the Towers of Binary Fields, from both a technical and implementation perspective. Binary Fields The implementation of Binius is based on Binary Fields. In Binius, Binary Fields are constructed using towers of field extensions. The simplest Binary Field is ${{\mathbb{F}}{2}}$, which contains only two elements ${0,1}$, with operations performed modulo 2: addition corresponds to bitwise XOR, and multiplication corresponds to bitwise AND. By choosing an irreducible polynomial $m(x) = x^{2} + x + 1$ over ${{\mathbb{F}}{2}}$, we can form the field ${{\mathbb{F}}_{{2^{2}}}}$, where the elements are remainders of polynomials of degree at most 1, $r(x) = ax + b$ (with $a, b \in {0, 1}$). While one method to extend fields involves taking remainders using irreducible polynomials, Binius employs a more efficient approach: the use of Multilinear Lagrange polynomials as a basis for tower extensions. This method allows for recursive field extensions, where each extension field is nested within the previous one.

Onis -- Verifiable Bridge Yet another bridge? 以 Bitcoin 和 Ethereum 的跨链挑战为例：从 Bitcoin 到 Ethereum 的跨链相对容易，因为 Ethereum 支持智能合约，只需一个稍微可信的第三方将 Bitcoin 的轻节点数据传递到 Ethereum 上即可。然而，从 Ethereum 到 Bitcoin 的跨链则复杂得多。目前的方式要么是中心化的，要么是多签方案，后者存在私钥丢失或单一实体掌握多个私钥等安全隐患。即使使用轻客户端的方式，也依赖于可信方将数据存入合约，无法完全去中心化。 Onis 旨在解决这些问题，通过利用去中心化的 Massive 用户网络和 zkP 软验证，实现更加安全和去中心化的跨链操作，确保从 Ethereum 到 Bitcoin 的跨链过程也能在无信任的环境中安全进行。这种去中心化的设计不仅提升了安全性，还确保了跨链操作的终局性和可信度，为用户提供了一种更可靠的跨链解决方案。 Onis Architecture Onis 是 Ola 的跨链解决方案，其架构图展示了如何通过去中心化的方式实现不同区块链之间的互操作性。Onis 包括三个主要部分：Onis 服务、Massive 用户（包括 Supervisor 和 Proposor），以及 OlaVM 智能合约系统。 image

OlaVM temp (1) 1. Introduction A polynomial commitment scheme is a cryptographic protocol that allows one party (the prover) to commit to a polynomial without revealing its coefficients. Subsequently, the prover can demonstrate to another party (the verifier) that the polynomial evaluates to a specific value at a particular point, without disclosing any other information about the polynomial. Polynomial commitment schemes are an essential component in various zero-knowledge proof systems. The development of these schemes significantly influences the iteration and evolution of zero-knowledge proof systems. Currently, the most common polynomial commitment schemes include FRI [1](based on hash functions), KZG[2] (based on elliptic curves), and Bulletproofs [3] (also based on elliptic curves). Initially, Plonky (2019) used KZG polynomial commitments. Plonky2 (2022) incorporated FRI polynomial commitments inspired by the design of STARK. Plonky3 (2024) further introduced the Brakedown polynomial commitment scheme. KZG polynomial commitments are implemented on elliptic curves. Their advantage is low verification cost when applied to univariate polynomials. However, most of the prover's work involves extensive FFT (to generate polynomials) and MSM (to generate polynomial commitments) calculations, resulting in slow proving speeds. FRI polynomial commitments, based on hash functions, do not require elliptic curve MSM operations. By leveraging recursive computation techniques, FRI enhances efficiency, balancing prover and verifier costs depending on the Reed-Solomon [4] code rate used in the protocol. The Brakedown [5] polynomial commitment scheme also uses hash functions and integrates error-correcting code theory, making it faster than FRI, though the proofs are significantly larger. Compared to KZG, FRI and Brakedown offer faster proving speeds and quantum security, but lack homomorphic hiding properties, limiting their application in certain scenarios. In 2021, Alexander Golovnev and colleagues proposed the Brakedown polynomial commitment scheme, drawing on linear-time encoding from [6] and the Spartan linear-time interactive proof system design from [7]. Brakedown is considered the fastest polynomial commitment scheme currently available. As a result, it has been referenced in both Orion [8] and Binius [9][10], and incorporated into the latest Plonky3. Its main drawback is the larger proof size.

OlaVM temp (1) Written by Malone & Longson pfwang@cee.ecnu.edu.cn Abstract This document provides a simple introduction to the current state of development of polynomial commitments and the application of hash functions in zero-knowledge proofs (zk). We conduct a detailed study and comparison of the two generations of Poseidon hash functions used in Plonky2 and Plonky3, and present benchmark results to verify the computational performance of Poseidon2. Keywords: Plonky3; Polynomial Commitment; Hash; Poseidon2 1. Introduction

Written by @xbinSin7Y During DevConnect Istanbul, I had the privilege of engaging with various project teams and researchers dedicated to privacy-oriented initiatives. We discussed a range of privacy-related topics. To my surprise, I found that the concept of 'privacy' is interpreted quite differently by different people, generally falling into two distinct categories: Prioritizing ultimate individual privacy protection before considering regulatory oversight (including both centralized and decentralized methods). Achieving individual privacy protection within a regulation-friendly framework. These different approaches lead to varied technological solutions. In my opinion, all privacy protection schemes should be regulated to penalize malicious users, thereby protecting the interests of the majority of ordinary users. Concurrently, it is essential that user privacy is not entirely compromised. Privacy and regulation are not inherently contradictory. Humans need privacy, but privacy requires regulation.

Towards the Authentic Web3 World At Ola, we strongly agree with a16z’s statement in their article “Achieving Crypto Privacy and Regulatory Compliance” about web3: The development and regulation of web3 — an evolution of the internet powered by crypto — must achieve two goals that are often in tension. Goal 1: Preserve consumer privacy, despite the default transparent nature of blockchains. Goal 2: Reduce the risk of illicit finance in the interest of national security. This vision aligns with what Ola described in the article “Ola — Shape Your Own Web3 Journey”. Additionally, the emphasis on high-throughput is a feature that Ola is currently working hard to implement.

A comparative study of Aztec, Miden, and Ola In this article, we delve into the concept of "Hybrid Rollup," examining how projects Aztec, Miden, and Ola approach this technology. We investigate their unique smart contract languages, explore state tree designs, and consider the trade-offs in privacy designs. Our objective is to provide a comprehensive overview of Hybrid Rollup technologies, helping you understand their key components and envision their future trajectory. What is Hybrid Rollup? We are delighted to see that our recent initiatives have been garnering an increasing amount of attention in the market. "Hybrid Rollup" is the most accurate summary of what we at Ola have been working on: Rollup: a. It operates at Layer 2, but it also has the flexibility to function at Layer 3, depending on the platform utilized for the verification contract deployment.b. It's a scalability solution.c. It has programmability - "Rollup" doesn't specifically indicate this feature; "Programmable Rollup" is more accurate. Hybrid: a. It supports public, private, and hybrid contract types.b. Developers can freely choose the contract type based on their needs.c. Users can freely choose the transaction type in hybrid contracts.

This article is the 34th series of the Sin7y Tech Review and will mainly interpret SuperNova, which is a new recursive proof system for incrementally producing succinct proofs of correct execution of programs on a stateful machine with a particular instruction set. These seem to be fantastic features. This article will mainly interpret how these features are implemented. For easy understanding, all interpretations are based on the paper itself. What is folding? First, let's look at the definition in the paper:As shown by the green marker in the figure: input: two (instance, witness) pairs

In August 2022, the Office of Foreign Assets Control (OFAC) announced sanctions against Tornado Cash, which directly cast a shadow on protocols aiming to achieve privacy on public blockchains. This led to discouragement in the market towards privacy and raised regulatory concerns. However, Ola, an Ethereum Layer 2 network that supports programmable privacy utilizing its ZK-ZKVM architecture, still recognizes the urgent need for robust privacy across the blockchain space. Ola is not the first project dedicated to bringing privacy to blockchains, nor will it be the last. As a member of the blockchain community, Ola is committed to interpreting the privacy technologies used in most projects and the regulatory compliance issues involved in privacy transactions, in order to help the market understand privacy on top of public blockchains more comprehensively. 1. Why was Tornado Cash banned? The reason for Tornado Cash's blacklisting by OFAC is obvious: its transactions can not be tracked. This has made Tornado Cash widely used for illegal activities. The principle of privacy in Tornado Cash differs from that of Zcash, which is entirely based on ZK technology. Tornado Cash combines coin mixing and ZK technology, with coin mixing making transactions untraceable. As the coin-mixing pool grows larger, the chances of tracking it approach zero. ZK is only used to realize its own asset proof once the coin mixing is complete. Therefore, Tornado Cash is called a haven for hackers and black money, as it is impossible to track the addresses to which non-performing assets are withdrawn after entering the mixing pool. This is also the underlying reason for Tornado Cash's blacklisting. Many articles interpret the principle of coin-mixing in Tornado Cash, which readers can find for themselves.

TL;DR We are working on building the first ZKVM based on a parallel execution architecture and achieving higher TPS through the improvement of ZK-friendly design and ZK algorithms. The technical features are as follows:Fast proof generationZK-friendly: smaller circuit scale and simplified bottom constraint units Fast ZK: further optimization on Plonky2 Fast execution: Utilizing parallel execution to significantly shorten the proof generation time Current progress: In July 2022, we released the OlaVM Whitepaper. November 2022, completed instruction set design and development, and realized the OlaVM execution module of the virtual machine, you can check the link: https://github.com/Sin7Y/olavm to view our code, continuously updated.

Preface This research compares implementation systems similar to Ethereum and analyzes the difficulties and possibilities of achieving parallel execution of transactions. It's worth noting that the chains analyzed for this research are based on the Account model design scheme, not including the UTXO scheme. Research Objects FISCO-BCOS, one of the consortium blockchains that support parallel execution of transaction verification within blocks. Khipu public chain, scala implementation of the Ethereum protocol. Aptos public chain, Move Virtual Machine. Difficulties with Parallel Execution Let's take a look at the traditional transaction execution process.

TL;DR As mentioned in the previous article Hello, OlaVM!, OlaVM’s vision is to build a high-performance ZKVM, and this article will focus on one of the tools that make OlaVM high-performance, namely, Lookup Arguments. Lookup Arguments play an important role in reducing the size of the circuit, thereby improving Zero Knowledge efficiency, and it's widely used in the circuit design of ZKVMs. Throughout this article you'll learn more about the following: What role do Lookup Arguments play in ZKVM? Plookup protocol principles Lookup Argument protocol principle of Halo 2 The connection between the two Lookup Argument algorithms The roles of a ZKVM The ZKVM utilizes Zero Knowledge to constrain all the execution processes of the VM, and the execution process of the VM can generally be divided into: instruction execution, memory access and built-in function execution. It is somewhat impractical to execute constraints on these operations in one trace. First of all, in a trace, a row represents an operation type, and one operation type corresponds to multiple constraints, and different constraints correspond to different numbers of columns, resulting in different widths. If one of the rows is too wide due to one constraint corresponding to too many columns, then the width of the entire trace is affected, becoming too large. Resource usage of this design is wasteful when the rows corresponding to the remaining constraints do not require so many columns. Then, if there are too many different operation types in a single trace, more selectors will be introduced, increasing not only the number of polynomials, but also the order of the constraint. Finally, due to the order limitation of the group, the number of rows of the trace itself cannot exceed the order of the group, so the number of trace rows occupied by a certain type of operation should be minimized.

ZKEVM is a programmable virtual machine based on ZK technology. It can generate a ZK proof for all operations perfwormed by the virtual machine to prove the correctness of the operations performed by the virtual machine. For the introduction of several implementation schemes of ZKEVM and the comparison of advantages and disadvantages, you can refer to the article of Vitalik Buterin: The different types of ZK-EVMs. If you want more design details, you can also read PSE's ZKEVM Scheme (native-level)： privacy-scaling-explorations/zkevm-specs Polygon's ZKEVM Design (bytecode-level)： Polygon zkEVM Documentation. Sin7y’s ZKEVM Design (language-level)：OlaVM: An Ethereum compatible ZKVM. Regardless of the scheme, zk is required to constrain all VM behaviors, including: Executing contract computational logic Executing memory access Executing hash calculation Executing world state updates It is well known that ZK has great application prospect in the field of computing compression. No matter how complex the original computation is, the verification process is very efficient, which is fundamental to all zk algorithms. Therefore, ZK works well for computational parts of VM execution (such as contract logic, hash calculation, etc.). In the process of VM execution, in addition to the computing itself, there are also some memory access operations. We need to place some data in the memory in advance, and then pull it out when the computation is performed.

References Zcash - Zcash protocol specification Aleo - Zexe protocol specification Zcash 1. About Zcash ? A short video to learn about Zcash. Features:

Last month we were pleased to announce the OlaVM Whitepaper, an EVM-compatible ZKVM solution, released the 25th of July, 2022. ZKEVM has been a hot topic itself over the past couple of weeks, and upon the release of OlaVM, the paper managed to receive some honorable attention from prominent people in the industry, amongst them, one being Daira Hopwood (who also is the main author of the Zcash protocol), we would like to thank Daira for her feedback. Daira brought up a few important questions in regards to the design decisions, one of them relating to the choice of hash function in ECDSA and Schnorr signature algorithms. The exact comment can be seen in the tweet attached below. What Daira is referencing can in simple terms be described with the following: The security level of Sinsemilla hash is collision resistant, so it cannot be regarded as a Random Oracle. For the ECDSA and Schnorr signature algorithms, in order to satisfy sufficient security, the choice of hash function needs to be regarded as Random Oracle. In order to understand this better, we need to understand some cryptographic concepts first. 1. Security properties of a cryptographic hash function (CHF) According to the definition in the paper Cryptographic Hash-Function Basics, the security properties corresponding to a CHF are divided into the following three categories: Preimage Resistance - Given H(x), it is computationally difficult to determine x, i.e., it is computationally infeasible to discover any input which created a specific output. Second Preimage Resistance - Given x, it is computationally difficult to find some different value x' such that H(x) == H(x'), i.e., it is computationally infeasible to find any second input which has the same output as any specified input. Collision Resistance - Expanding the concept of Second Preimage Resistance, it is computationally infeasible to find any two arbitrary inputs, x and y such that H(x) == H(y), i.e., different inputs which hash to the same output.

Arkworks for Marlin Marlin Fractal R1CS Zero-knowledge proof algorithm Marlin is a R1CS based proof system, that, given a coefficient matrix parameter $I = (F, n, m, A, B, C)$ and a set of valid assignments $z =(x, w) \in F^n$，among which x is public information, namely Instance and is private information, namely, witness if $Az \circ Bz = Cz$is established, R1CS is established. If we let $z_A = Az, z_B = Bz, z_C = Cz$ the above formula can be transformed into $z_A \circ z_B= z_C$。 Therefore, if we can prove that there are four vectors $z_A, z_B,z_C,z$ that satisfy