1- Overview

In today's digital world, the challenge of keeping data safe while still being able to use it is more critical than ever. With increasing reliance on cloud computing and data sharing, ensuring that sensitive information remains secure throughout its lifecycle is a top priority. This is where Fully Homomorphic Encryption (FHE) comes into play. Introduced by Craig Gentry in 2009, FHE allows computations to be performed on encrypted data without ever needing to decrypt it, significantly enhancing data security. For organizations, this means the ability to fully utilize cloud services without the fear of exposing their most sensitive data. Consider the scenario where confidential financial information or medical records are being processed—FHE ensures that, even if such data were intercepted, it would remain inaccessible to unauthorized individuals. This capability makes FHE not only a powerful tool for security but also essential for maintaining privacy in an increasingly data-driven world.

Before the advent of FHE, Homomorphic Encryption (HE) was already advancing secure data computation. HE was designed to allow specific operations on encrypted data, ensuring that information remained protected even during processing. For example, with a basic HE system, one could perform operations like addition and multiplication directly on ciphertexts, which is encrypted data. The mathematical operations in HE are limited to either addition or multiplication but not both simultaneously. This means, if you encrypt two numbers a and b to get Enc(a) and Enc(b), you can perform operations such as:

• Addition: Enc(a) + Enc(b) = Enc(a + b)

• Multiplication (if the system supports it): Enc(a) x Enc(b) = Enc(a x b) These capabilities ensure that data remains secure and encrypted during computation, making HE valuable for secure computations like aggregating votes or confidential surveys.

FHE extends these capabilities significantly. Unlike basic HE, FHE is not restricted to a single type of operation (addition or multiplication); instead, it supports an unlimited sequence of both, applied in any combination. This allows for the execution of complex algorithms on encrypted data. For example, with FHE, one can compute any function f defined by polynomial expressions, Boolean circuits, or other computational models on encrypted inputs, such that: Dec(Eval(Enc(x), f)) = f(x) for any computable function f, where:

• Enc is the encryption function

• Eval is the evaluation function that performs the computation on encrypted data

• Dec is the decryption function

This means we can take any computable function f, apply it to encrypted data, and then decrypt the result to get the same outcome as if f had been applied to the unencrypted data. Theoretically, FHE changes the way we handle sensitive information by ensuring data remains encrypted throughout its entire processing lifecycle—from analysis to storage, thus protecting it against unauthorized access and potential data breaches.

Given the complexity and breadth of FHE, it's challenging to cover all aspects in a single blog post. For a deeper understanding, we recommend the series TFHE Deep Dive and Homomorphic Encryption 101.

2- Different schemes, different strengths

FHE schemes allow secure, arbitrary computation on encrypted data. Their utility is differentiated by the core operations and mathematical foundation:

• BGV (Brakerski-Gentry-Vaikuntanathan) and BFV (Brakerski-Fan-Vercauteren): Both schemes are structured around the Ring Learning With Errors (RLWE) paradigm. They are particularly robust in handling integer operations and employ techniques like relinearization and noise management to maintain the integrity and size of ciphertexts during calculations.

• CKKS (Cheon-Kim-Kim-Song): This scheme is designed for handling encrypted real or complex numbers and performs approximate arithmetic on ciphertexts. CKKS is distinct in its ability to manage the precision of encrypted computations, which is crucial for applications like statistical analysis and machine learning where handling of real numbers is required.

• FHEW (Fully Homomorphic Encryption from Worse-case assumptions) and TFHE (Fast Fully Homomorphic Encryption over the Torus): These focus on efficient Boolean operations and leverage the Learning With Errors (LWE) framework. Both schemes are optimized for low-latency cryptographic operations crucial for scenarios requiring rapid execution, such as real-time encrypted data processing.

3- Different techniques, different enhancements

Techniques have addressed many of the computational and efficiency barriers historically associated with FHE:

• SIMD batching: Single Instruction, Multiple Data (SIMD) batching is a pivotal performance metric in FHE that impacts its efficiency and scalability. By enabling multiple data points to be encrypted into a single ciphertext, SIMD batching allows simultaneous operations on all these data points. This parallel processing capability is especially beneficial for vector operations common in machine learning and statistical analysis, significantly reducing the computational overhead and latency compared to processing data points individually.

• AVX-512 instructions: Advanced Vector Extensions 512 (AVX-512) are specific CPU instructions that support the execution of 512-bit operations. In the context of FHE, leveraging AVX-512 can improve the performance of polynomial arithmetic, which is fundamental in FHE schemes. These instructions enhance the handling of large data sets and complex calculations by providing the means to execute multiple homomorphic operations in parallel, reducing the time required for computations.

• Vectorized FFT kernels: Fast Fourier Transform (FFT) kernels are essential for the efficient implementation of polynomial multiplication in FHE. The use of vectorized FFT kernels enables these operations to be carried out more swiftly and with greater energy efficiency. By optimizing FFT algorithms to utilize SIMD capabilities and AVX-512 instructions, FHE systems can perform necessary convolutions for polynomial multiplication faster, thereby accelerating the overall encryption and decryption processes.

• Noise management: Effective noise management is crucial for the practical implementation of FHE. Noise accumulates in ciphertexts during homomorphic operations, and if left unchecked, can render the ciphertext undecipherable. FHE schemes employ various techniques to manage and reduce noise:

  • Relinearization and Modulus switching:

    • Modulus switching reduces the size of the modulus and correspondingly scales down the noise in the ciphertext.

    • Scaling down: The ciphertext modulus is progressively reduced. If the original modulus is q, it is scaled down to a smaller modulus q'. The noise in the ciphertext is scaled down proportionally.

    • Polynomial pepresentation: In schemes based on the Ring Learning with Errors (RLWE) problem, ciphertexts are represented as polynomials with coefficients in a ring modulo q. Modulus switching reduces q to q', and scales the polynomial coefficients accordingly.

    • Advantages:

      • Noise control: Helps keep noise growth in check during homomorphic operations.

      • Efficiency: Allows for efficient noise management without resorting to more computationally intensive methods like bootstrapping.

    • Disadvantages:

      • Cumulative errors: Rounding errors can accumulate, affecting the precision of the result.

      • Limited operations: Suitable for a finite number of operations before noise management becomes necessary again.

  • Bootstrapping: Bootstrapping reduces the noise in a ciphertext to its initial level, allowing for unlimited homomorphic operations. Unlike modulus switching, which scales down the noise, bootstrapping effectively resets the noise to its initial level by homomorphically evaluating the decryption circuit on the ciphertext and re-encrypting the result. TFHE (Fast Fully Homomorphic Encryption over the Torus) provides advanced bootstrapping techniques:

    • Fast bootstrapping:

      • Blind rotation: Rotates encrypted data based on another encrypted value, reducing noise without revealing plaintext.

      • External product: Combines ciphertexts to manage noise growth efficiently, crucial for complex computations.

    • Programmable bootstrapping:

      • Lookup Table evaluation: Uses precomputed tables to quickly evaluate functions on encrypted inputs.

      • Controlled Multiplexer (CMux) gate: Selects between different encrypted values based on a control bit, enabling conditional logic in encrypted computations.

4- Application-specific optimizations of FHE

The design of FHE schemes often targets specific types of computational tasks:

• Integer and fixed-point arithmetic: BGV and BFV are highly effective for scenarios that require precise, structured arithmetic operations, such as encrypted financial transactions or algorithmic trading where integer precision is mandatory.

• Real and complex number computations: The CKKS scheme is optimized for fields requiring operations on real or complex numbers, suitable for use cases in scientific computations where approximation is acceptable.

• Boolean logic: FHEW and TFHE are tailored for environments that demand rapid Boolean computations. These schemes support operations like encrypted control systems or secure communications where decision logic needs to be processed in an encrypted state.

Comparison of FHE for arithmetic operations

Comparison of FHE for logic operations

Comparison of FHE for arithmetic and logic operations

Noise management and Bootstrapping

Arithmetic operations

Observations:

• BFV and BGV are preferable for integer arithmetic, with BFV showing better throughput and lower latencies for deep operations.

• CKKS is more efficient for approximate arithmetic and fixed-point computations but has higher latency for decryption at small depths.

Logic operations

Observations:

• TFHE shows superior performance for Boolean logic due to its use of AVX-512 and vectorized FFT kernels, making it the fastest for logic operations.

• FHEW is also efficient but not as optimized as TFHE for fast logic operations.

II- Notable productions

1- FHEnix: FHE-Rollups for confidential smart contracts

FHEnix is an implementation of FHE designed for the blockchain ecosystem, focusing on the scalability and confidentiality of smart contracts. It integrates FHE with rollup technology, specifically optimized for Ethereum, but also applicable to other platforms.

Use cases

• Confidential ERC-20 contracts: Token contracts where transaction amounts and balances remain encrypted and confidential.

• Sealed-bid auction contracts: Auctions where bids are kept confidential until the conclusion, ensuring fairness and privacy.

• Private voting contracts: Contracts that allow votes to be cast privately, ensuring voter anonymity and confidentiality.

Implementation

The core innovation of FHEnix lies in its rollup-based architecture:

• FHE optimistic rollups: FHEnix utilizes optimistic rollups, a Layer-2 solution that processes transactions off the main Ethereum chain but posts transaction data on-chain. This approach reduces the load on the main blockchain, delegating computation to a specialized node or a small set of nodes, thereby handling the computational demands of FHE more efficiently.

• Avoiding verifiable FHE overheads: Traditional verifiable FHE techniques require all nodes to perform complex computations and reach consensus on the encrypted state, imposing significant overheads. FHEnix's optimistic approach uses cryptoeconomic mechanisms to ensure the integrity and correctness of private computations without such computational demands.

Significance

FHEnix introduces FHE into rollups, offering a practical and scalable method to integrate confidentiality into smart contracts. This solution addresses a key limitation of current blockchain infrastructures: the lack of inherent data privacy.

• Scalability and Efficiency: By reducing the need for every node to perform FHE computations, FHEnix enhances the scalability of FHE applications. This makes complex applications like confidential smart contracts feasible on a larger scale without compromising blockchain performance.

• Security and Privacy: FHEnix maintains the security properties of the blockchain while enhancing privacy, ensuring that data remains confidential and secure throughout the transaction process. This is particularly important for applications involving sensitive data that must comply with privacy regulations and security standards.

2- Sunscreen: Integrating FHE and ZKP for enhanced Web3 privacy

Sunscreen is a platform designed to enhance privacy and security within the Web3 ecosystem through the integration of Fully Homomorphic Encryption (FHE) and Zero-Knowledge Proofs (ZKP). Targeted at developers, Sunscreen provides a toolkit to implement FHE in decentralized applications (dApps), addressing key challenges associated with privacy in blockchain environments.

Use cases

• Financial transactions: Sunscreen aims to protect the confidentiality of financial transactions on blockchain networks, preventing front-running and preserving the privacy of trading strategies and asset holdings.

• Voting systems: By leveraging both FHE and ZKP, Sunscreen can facilitate confidential voting mechanisms within decentralized autonomous organizations (DAOs), ensuring that votes are cast anonymously and securely.

• General development of dApp privacy: Sunscreen enables developers to incorporate privacy features into any dApp, promoting broader adoption of privacy-preserving technologies in everyday blockchain applications.

Implementation

Sunscreen has developed several key technologies to make FHE practical and accessible for Web3 developers:

• FHE Compiler: Sunscreen's FHE compiler simplifies the integration of FHE into Web3 applications. This compiler automates the selection of cryptographic parameters, circuit generation, and optimization tasks, enabling developers to focus on application logic rather than cryptographic complexities.

• Integration with ZKP: To enhance privacy capabilities, Sunscreen pairs FHE with ZKP, allowing developers to verify the correctness of computations on encrypted data without revealing the underlying data. This dual approach not only enhances privacy but also expands the types of applications that can securely use encrypted data.

• Developer-friendly SDKs: Sunscreen provides Software Development Kits (SDKs) tailored for Web3, facilitating the integration of privacy technologies into existing blockchain frameworks and applications.

Significance

Sunscreen is significant for its role in addressing the privacy limitations of current blockchain technologies through practical tools and frameworks:

• Enhancing developer accessibility: By reducing the barrier to entry for using advanced cryptographic techniques like FHE and ZKP, Sunscreen empowers developers to build privacy-first applications. This accessibility is crucial for the widespread adoption of privacy technologies in blockchain.

• Practical performance improvements: Sunscreen has addressed the performance challenges of FHE. By optimizing the compiler and integration process, Sunscreen ensures that the added privacy does not come at a prohibitive cost in terms of transaction speed and resource consumption.

3- Mind Network: Leveraging FHE for enhanced web3 privacy and security

Mind Network applies Fully Homomorphic Encryption (FHE) within the Web3 ecosystem, focusing on enhancing privacy and security through advanced cryptographic techniques. It integrates privacy-preserving protocols to address the need for confidentiality and security in decentralized applications and blockchain transactions.

Use cases

• Cross-chain value transfers: Mind Network enables secure and private transfers between different blockchain systems, including CBDCs and public chains, using its FHE-based protocols to ensure data remains encrypted during transit.

• Enhanced transactional privacy: By utilizing dual-key stealth address protocols, Mind Network enhances privacy for transactions on public ledgers, ensuring that details such as transaction amounts and participant identities remain confidential.

• Data protection in AI: Mind Network allows computation on encrypted data, enabling AI applications to process sensitive information without access to raw data, adhering to privacy-by-design principles.

Implementation

Mind Network has developed a technological framework incorporating FHE and other cryptographic technologies:

• FHE dual-key stealth address protocol (DK-SAP): This protocol employs stealth addresses and dual keys to obscure transaction details while maintaining the integrity and security of the transactions.

• Integration with Zero-Knowledge Proofs: Mind Network integrates FHE with ZKP to enhance the privacy of transactions, enabling the verification of encrypted inputs without exposing any sensitive information.

• Decentralized storage solutions: To manage the large ciphertexts produced by FHE, Mind Network incorporates decentralized storage solutions like IPFS and Arweave, ensuring efficient and scalable storage for blockchain applications.

Significance

The technical contributions and impact of Mind Network on the blockchain and cryptographic communities include:

• Advancement in cryptographic privacy: Mind Network integrates FHE with ZKP and decentralized storage, offering a comprehensive solution that addresses multiple aspects of data privacy and security.

• Scalability and efficiency: The use of rollup technologies and efficient cryptographic protocols allows Mind Network to offer solutions that are secure, scalable, and efficient, suitable for high-throughput blockchain networks.

III- Challenges in Fully Homomorphic Encryption

1. Performance bottlenecks

   The computational overhead of FHE is primarily due to the complex arithmetic operations on ciphertexts and the management of noise that accumulates during these operations. Specifically, the multiplication of encrypted data introduces multiplicative noise growth, which can quickly degrade the integrity of the data if not properly managed. This is often mitigated through the process of bootstrapping, which refreshes the ciphertext by reducing noise but at a significant computational cost. Furthermore, FHE operations typically require polynomial arithmetic in a ring, which involves computationally intensive operations like polynomial multiplication under a modular coefficient reduction, often parameterized by large prime numbers to ensure security.

2. Usability and complexity

   FHE's steep learning curve is largely due to its reliance on lattice-based cryptography, which is less intuitive than traditional cryptographic methods. Developers must understand the underlying algebraic structures, choose appropriate lattice parameters, and manage noise growth—all of which require a non-trivial mathematical background. The complexity of implementing FHE is compounded by the need for precise parameter tuning to balance security, correctness, and performance. This often involves selecting the right lattice dimension, noise distribution parameters, and modulus size, which are critical for ensuring the scheme's resistance to lattice-based attacks.

3. Security vulnerabilities

   While FHE schemes are designed to be secure under the assumption of hard lattice problems, such as the Shortest Vector Problem (SVP) and the (Ring) Learning With Errors (RLWE/LWE) problem, practical implementations can introduce vulnerabilities. The integrity of computation is a particular concern, as any error in the encrypted computation directly affects the correctness of the decrypted result. Moreover, side-channel attacks, which exploit information leakage from physical implementations (like power usage or electromagnetic emissions), pose a realistic threat to FHE applications. Ensuring that FHE implementations are resistant to both cryptanalytic and side- channel attacks is crucial for their secure real-world deployment.

4. Storage and data management

   The ciphertext expansion in FHE—where encrypted data can be significantly larger than the corresponding plaintext —is a critical issue for storage and bandwidth. For instance, typical FHE implementations might increase the data size by several orders of magnitude, impacting not only storage costs but also the efficiency of data transmission over networks. This expansion is inherent to the encryption process, which transforms simple data elements into complex polynomial structures to facilitate homomorphic operations.

5. System integration

   Integrating FHE into existing IT infrastructures and applications is non-trivial due to the significant modifications required to handle encrypted data operations. Legacy systems and databases are typically not designed to operate on or store encrypted data, necessitating extensive redesigns or the use of middleware solutions that can handle FHE operations transparently. Moreover, the compatibility of FHE with other cryptographic primitives, such as digital signatures and secure multiparty computation protocols, requires careful alignment to ensure that the composite systems remain secure and functional.

Addressing these challenges involves a multi-faceted approach focusing on algorithmic improvements, optimized implementations, and better abstraction layers for developers. Research into more efficient lattice constructions and noise management techniques could yield significant performance improvements. On the implementation front, leveraging hardware accelerations, such as using GPUs or custom ASICs for polynomial arithmetic, could alleviate computational bottlenecks. Finally, developing higher-level APIs and integration tools that abstract the complexities of FHE can help in making these technologies more accessible to application developers, thereby accelerating the adoption of FHE in practical security solutions.

IV- References

1. Chillotti, I. (2022, May 4). TFHE Deep Dive - Part I - Ciphertext types. Www.zama.ai. https://www.zama.ai/post/tfhe-deep-dive-part-1

2. Dahl, M., Demmler, D., El Kazdadi, Sarah, Meyre, A., Orfila, J.-B., Rotaru, D., Smart, N. P., Tap, S., & Walter, M. (2023). Noah’s ark: Efficient threshold-fhe using noise flooding. 35–46. https://doi.org/10.1145/3605759.3625259

3. Fhenix. (2023, December 26). Fhenix: Pioneering A Blockchain Renaissance With FHE. Medium. https://medium.com/@Fhenix/fhenix-pioneering-a-blockchain-renaissance-with-fhe-a98d72f90fad

4. Gouert, C., Mouris, D., & Tsoutsos, N. (2023). SoK: New Insights into Fully Homomorphic Encryption Libraries via Standardized Benchmarks. Proceedings on Privacy Enhancing Technologies, 2023(3), 154–172. https://doi.org/10.56553/popets-2023-0075

5. Jiang, L., & Ju, L. (2022, March 1). FHEBench: Benchmarking Fully Homomorphic Encryption Schemes. ArXiv.org. https://doi.org/10.48550/arXiv.2203.00728

6. Micciancio, D., & Polyakov, Y. (2020). Bootstrapping in FHEW-like Cryptosystems. Cryptology EPrint Archive (Eprint.iacr.org). https://eprint.iacr.org/2020/086

7. Mind Network. (2024, June 13). Introduction | MindDocs. Mindnetwork.xyz. https://docs.mindnetwork.xyz/minddocs

8. Mouchet, C., Troncoso-Pastoriza, J., Bossuat, J.-P., & Hubaux, J.-P. (2020). Multiparty Homomorphic Encryption from Ring-Learning-With-Errors. Cryptology EPrint Archive (Eprint.iacr.org). https://eprint.iacr.org/2020/304

9. Network, M. (2024, May 10). Mind Network: Revolutionizing Web3 Security and Privacy with Fully Homomorphic Encryption. Medium. https://mindnetwork.medium.com/mind-network-revolutionizing-web3-security-and-privacy-with-fully-homomorphic-encryption-69dbf850e0be

10. Ravital. (2021, August 30). An Intro to Fully Homomorphic Encryption for Engineers. Sunscreen. https://blog.sunscreen.tech/an-intro-to-fully-homomorphic-encryption-for-engineers/

11. Ravital. (2023, May 18). Building an FHE compiler for the real world. Sunscreen. https://blog.sunscreen.tech/from-toy-programs-to-real-life-building-an-fhe-compiler/

12. Zyskind, G., Erez, Y., Langer, T., Grossman, I., & Bondarevsky, L. (n.d.). FHE-Rollups: Scaling confidential smart contracts on ethereum and beyond.

I- A brief overview of zkCoProcessors' core components and architecture

1- Core components

1. ZK Program:

   A ZK program specifies the computations necessary for an application. These programs can be written directly as zk circuits or in higher-level languages (like Rust, or Circom) that compile into ZK circuits. This flexibility enables developers to balance custom optimization and ease of use. Examples include zkVMs like those used by RISC Zero and ORA’s zkWASM.

2. ZKP generation:

   The generation of ZKPs is crucial to ensure computations are performed correctly without exposing sensitive inputs. This process transforms traditional computational logic into arithmetic circuits, encoding variables modulo a large cryptographic prime. Deterministic execution is essential to maintain the correctness of the generated ZKPs.

3. ZKP verification:

   ZKP verification confirms the accuracy of the ZKPs in representing the off-chain computations. Typically performed on-chain, this verification reintegrates the results into the smart contract environment, preserving data integrity and trust.

2- Technical architecture

Data access

Accessing historical on-chain data is fundamental to zkCoProcessors. The primary methods include:

• On-chain storage: This involves storing additional data within the blockchain state for verification purposes. While secure, this method can be very expensive due to high storage costs.

• Trusted oracles: Trusted oracles or signer networks can verify input data for zkCoProcessors. However, this method introduces trust dependencies that can compromise security.

• ZKP for data validity: Utilizing ZKPs to ensure the correctness of historical on-chain data, providing cryptographic guarantees without additional trust assumptions. For example, AxiomV2 uses ZK proofs of Merkle-Patricia trie inclusion and block header hash chains to verify data integrity.

Computation

To handle off-chain computations, zkCoProcessors use several methods, each offering different levels of optimization and developer effort:

• Custom circuits: These offer the highest performance potential, allowing developers to optimize ZK circuits specifically for their applications. However, this requires significant expertise in circuit design.

• Domain-Specific Languages (DSLs): DSLs simplify some ZK-specific concerns, allowing developers to write circuits in a more intuitive programming language. This provides a better developer experience at the cost of some performance optimization. For instance, DSLs like ZoKrates abstract the complexity of circuit writing.

• zkVMs: zkVMs compile high-level programming languages into ZK circuits, making the development process simpler by abstracting constraint generation. However, this can introduce performance overhead due to differences between traditional computation models and ZK circuit execution. ORA's zkWASM, for instance, compiles AssemblyScript into WASM and then into ZK circuits, enabling developers to write verifiable computations in familiar languages.

3- Future directions:

1. Integration with AI/FHE and big data:

   zkCoProcessors will be increasingly used for verifiable AI/FHE and large-scale data analysis, enabling secure computations in advanced decentralized applications. This integration will allow for complex computations involving large datasets to be done off-chain, with results verified on-chain.

2. Developer tools and ecosystem:

   The expansion of libraries and DSLs will make ZK circuit development more accessible. Comprehensive documentation and community support will encourage adoption and ease the learning curve for new developers. Tools that simplify the development process will be critical for wider adoption, as they reduce the technical barriers to entry.

3. New use cases:

   zkCoProcessors will find broader applications in areas requiring intensive data verification and privacy-preserving computations, such as predictive analytics, DeFi, and user profile management in Web3. These use cases will benefit from the ability to perform complex computations off-chain while ensuring the integrity and privacy of the data involved.

II- Notable products

1- Brevis

Brevis is an advanced zkCoProcessor that uses a hybrid model combining pure-ZK proof systems with an innovative 'propose-challenge' mechanism to optimize cost, performance, and functionality for data-driven dApps.

Brevis App Workflow

Technical features

• Data access:

  • Allows developers to access the full historical on-chain data from supported blockchains, including block headers, account data, storage slots, transactions, and transaction receipts. This capability is essential for applications that need to analyze past blockchain events.

• Computation:

  • Provides a SDK for developers to build and deploy business logic. Brevis handles the computation and generates a ZK proof off-chain. This offloading reduces the computational burden on the blockchain.

• Result utilization:

  • Computation results and ZK proofs are submitted back on-chain for verification and use by smart contracts. This ensures that the results can be trusted and used in subsequent smart contract operations.

• Propose-challenge model: This model involves proposing results optimistically without immediate ZK proofs, subject to a predefined challenge period.

  • Proposing results: Coprocessing requests are handled by generating results optimistically without immediate ZK proofs.

  • Challenge period: Results are subject to a predefined challenge period during which any network participant can challenge them by submitting a ZK proof.

  • Final acceptance: If no challenge is initiated, results are accepted and can be used by dApps without incurring the costs of ZK proof generation.

Details:

1. Data access module:

   Developers specify the required historical blockchain data using Brevis SDK.

   Example: For a DEX trading volume application, the data might include all related swap events.

2. App circuit:

   Developers build the logic to process the specified data.

   Example: Summing up all trade transactions to compute trading volumes.

3. App contract:

   Handles the ZK-verified computation results and integrates them into the application logic.

4. Operational workflow:

   Request submission: dApps submit coprocessing requests specifying the required data and computation logic.

   Result proposal: Validators in Brevis coChain generate coprocessing results and propose them on-chain.

   Challenge mechanism:

   If the results are challenged, a ZK proof is required to verify the correctness. Successful challenges result in penalties for validators and rewards for challengers.

   If unchallenged, the results are accepted and used by the application.

5. Benefits:

   Cost efficiency: The propose-challenge model significantly reduces the costs associated with ZK proof generation.

   Flexibility: Developers can customize the challenge period and security level, adapting to various use cases.

   Scalability: Brevis can handle large-scale data-driven applications with low latency and high performance.

Applications:

1. Uniswap V4 integration

   It allows any V4 hook to read and compute liquidity providers’ (LPs) and traders’ transaction histories trustlessly, helping the development of loyalty programs and other complex data-driven functionalities.

2. Trusta’s UX personalization

   Enhances its MEDIA Score, a machine learning-powered metric for user profiling, enabling personalized user experiences without compromising trust and privacy. By analyzing user behavior, Trusta can offer more relevant content and services.

3. Integration with EigenLayer

   Leveraging its restaking infrastructure to enhance security. This combination allows Brevis to benefit from EigenLayer’s security model while maintaining cost efficiency and scalability.

2- Axiom

Axiom zkCoProcessor offering enhanced capabilities for smart contract developers to perform ZK-verified computations over the entire history of Ethereum. Axiom V2 introduces a new JavaScript interface and supports more extensive on-chain data access.

Technical features:

• Enhanced data access:

  • Supports access to transactions, receipts, and Solidity mappings in addition to block headers, accounts, and contract storage.

  • Allows developers to read any piece of on-chain data that has appeared in the history of Ethereum.

• JavaScript interface:

  • Developers can specify arbitrary ZK-verified computations over historic data using a JavaScript interface.

  • Simplifies integration by allowing the use of Solidity and JavaScript alone, without requiring ZK-specific verifier contracts.

• Universal verifier:

  • A universal verifier contract enables developers to verify results on-chain without deploying new ZK-specific contracts.

  • Results are received through a callback function in the smart contract.

Details

1. Data access:

   Developers can request authenticated on-chain data using the Axiom Client SDK.

   Supported data types include block headers, accounts, contract storage, transactions, receipts, and nested Solidity mappings.

2. ZK Primitives and Computation:

   Axiom SDK provides ZK circuit primitives for computations over the data.

   Developers can write custom queries and computations in JavaScript, which are then verified by Axiom.

3. Integration:

   Developers implement a smart contract callback to receive ZK-verified results.

   The callback interface allows seamless integration with existing smart contracts.

4. Operational workflow

   • Query composition: Developers compose queries using the Axiom Client SDK and specify computations in JavaScript.

   • Proof generation: Axiom generates ZK proofs for the specified queries and computations.

   • Result verification:

     ZK-verified results are forwarded to the smart contract callback.

     The universal verifier contract checks the proof and ensures the integrity of the results.

Benefits

1. Ease of use: The JavaScript interface and simplified integration process make it accessible for developers without extensive ZK knowledge.

2. Comprehensive data access: Full access to Ethereum’s historical data allows for more complex and data-rich applications.

3. Cost efficiency: The use of a universal verifier reduces the need for multiple ZK-specific contracts, lowering integration costs.

3- zCloak network

zCloak Network has developed a chain abstraction-based zkCoProcessor designed to work across multiple blockchain platforms. This zkCoProcessor leverages the Internet Computer (ICP) for efficient off-chain ZK computation and verification.

Technical features:

• Chain abstraction:

  • Enables ZKPs to be executed and recognized across various blockchain systems.

  • Facilitates cross-chain interoperability of ZKP verification outcomes.

• zkCoProcessor:

  • Offloads ZK-intensive computations from conventional public blockchains to high-performance off-chain resources.

Details:

1. ZK program:

   Supports the creation of general-purpose computing programs without manual zk circuit construction.

   Uses zk-STARK-based zkVM (Polygon Miden) integrated with zCloak’s zkID SDK.

2. ZKP generation:

   Executes the logic for ZKP generation in WASM format locally via the Miden zkVM.

   Facilitates ZKP generation within web development workflows.

3. ZKP verification:

   Uses ICP’s decentralized cloud infrastructure for ZKP verification.

   Leverages ICP’s threshold ECDSA signature scheme for secure and efficient verification.

4. Operational workflow:

   • Local ZKP generation:

     Users generate ZKPs locally using the zkID SDK, which runs the zkVM and associated zero-knowledge programs.

     Example: Generating a ZKP for a game’s escape path without revealing the exact path.

   • ZKP submission:

     Users submit the generated ZKP to the ZKP verification module on ICP.

     The verification module processes and verifies the ZKP using ICP’s decentralized infrastructure.

   • Verification results:

     Verified results are signed using ICP’s threshold ECDSA signature.

     Results can be sent to any blockchain supporting ECDSA signature verification.

Benefits:

• Ultra-low costs:

  Verifying ZKPs within ICP is significantly cheaper than on Ethereum.

  The overall cost of using the zkCloak solution is substantially lower.

• High execution efficiency:

  The zCloak ZK coprocessor approach allows for verification of large ZKPs within a single transaction.

  This method is more efficient than the conventional multi-step proof verification process.

• High execution speed:

  The entire ZKP verification process is completed in a few hundred milliseconds.

  This speed rivals off-chain computation times.

Applications

ZK maze game

Players navigate a character through a maze, generating a ZKP for the escape path. The game verifies the ZKP using the zkCloak verification module and awards achievements based on the path.

Integration steps:

1. Generate ZKP: The game front-end uses the zkID SDK to generate the ZKP locally.

2. Submit ZKP: The ZKP is submitted to the ICP-based verification module.

3. Verify and use results: The verification results are checked on-chain using a smart contract. Achievements are awarded based on the verified ZKP.

III- Conclusion

1- Strengths:

• zkCoProcessors like AxiomV2 and Brevis enable access to historical on-chain data with cryptographic guarantees of data integrity through ZKPs.

• Offloading computations off-chain reduces the load on blockchain networks. Brevis’s propose-challenge model optimizes ZK proof generation, enhancing cost-efficiency.

• zCloak Network’s chain abstraction facilitates ZKP execution and verification across different blockchains, promoting seamless interoperability.

• Tools such as Axiom’s JavaScript interface and Brevis's SDK simplify ZKP integration, making it accessible for developers without deep cryptographic expertise.

2- Challenges:

• Complexity: The intricate concepts of ZKPs and zkCoProcessors pose a steep learning curve for developers, potentially hindering adoption.

• Performance overheads: Despite improvements, proof generation and verification can still introduce latency, especially in real-time applications.

• Cost considerations: Initial setup and integration costs can be high, particularly for small projects. External dependencies, such as ICP in zCloak, add potential cost variability.

• Security risks: The security of zkCoProcessors depends on the robustness of ZK algorithms. Vulnerabilities in ZK circuits or integration frameworks could compromise the system.

zkCoProcessors are an important development in technology, addressing key issues like blockchain scalability, security, and interoperability. Although they can be complex and may involve some overhead, their ability to deliver trustless and efficient computations makes them useful for creating advanced decentralized applications. To be successfully integrated and widely adopted in the blockchain world, they need ongoing improvements and strong security practices.

IV- References

• Brevis Team. (2023, November). Uniswap V4 Hook + Brevis ZK Coprocessor = Data-driven DEX Experiences. Brevis Network. https://blog.brevis.network/2023/11/01/uniswap-v4-hook-brevis-zk-coprocessor-data-driven-dex-experiences/

• Brevis Team. (2024a, February 26). Launching Brevis V2: Generalized ZK Coprocessor for Data-driven dApps. Brevis Network. https://blog.brevis.network/2024/02/26/v2launch/

• Brevis Team. (2024b, March 13). Revolutionizing the Web 3.0 UX with ZKML Powered by Trusta and Brevis. Brevis Network. https://blog.brevis.network/2024/03/13/revolutionizing-the-web-3-0-ux-with-zkml-powered-by-trusta-and-brevis/

• Brevis Team. (2024c, April 11). Brevis coChain AVS Launches on EigenLayer: The Fusion of Crypto-Economics + ZK Proofs. Brevis Network. https://blog.brevis.network/2024/04/11/brevis-cochain-avs-launches-on-eigenlayer-the-fusion-of-crypto-economics-zk-proofs/

• Sledd, L., Lehman, S., & Liu, C. (2024). A Two-Part Approach to Understanding zk Coprocessors. Symbolic.capital. https://www.symbolic.capital/writing/a-two-part-approach-to-understanding-zk-coprocessors

• Sun, Y. (2024, January 22). Announcing Axiom V2 on Mainnet. Axiom; Axiom. https://blog.axiom.xyz/v2-mainnet/

• zCloak Network. (2024, March 7). A Chain Abstraction Based ZK Coprocessor by zCloak Network. Medium; Medium. https://zcloaknetwork.medium.com/a-chain-abstraction-based-zk-coprocessor-by-zcloak-network-aa86c42a9dec

Special thanks to the NEAR team for their valuable review and support in crafting this analysis.

Introduction

The pace of Web3 technology development is impressive, but it is also increasing fragmentation across blockchain networks, complicating the user experience and raising barriers to entry. Chain abstraction has emerged as a key solution, providing a cohesive interface that simplifies navigation across different blockchains, thereby enhancing seamless interaction with decentralized applications (dApps).

Chain abstraction reduces the need to manage multiple wallets, handle different gas fees, or connect assets between chains. It allows users to interact with dApps easily, driving greater accessibility and adoption of Web3 technology. The NEAR protocol leads this innovation front by integrating technologies such as Multi-Party Computation (MPC) for robust key management, decentralized interfaces that deliver a consistent user experience, and multi-chain signatures for flexible cross-chain transactions. This approach not only minimizes current fragmentation but also sets the stage for a more integrated and user-centric blockchain ecosystem.

This article will explore how chain abstraction works, show how the NEAR Protocol is leading this change, and discuss how it could revolutionize the use of decentralized apps in the future.

Chain Abstraction in NEAR protocol

Overview

Chain abstraction in NEAR Protocol aims to simplify the user experience by unifying the functionality of various blockchains. This abstraction layer allows users to interact seamlessly with multiple blockchains through a single NEAR account. This unification not only enhances user experience but also expands the potential demand for dApps, bringing up greater adoption and innovation within the Web3 space.

Imagine a scenario where a user wants to buy a token that is only available on a specific blockchain. Traditionally, this would require setting up a new wallet, acquiring native tokens for transaction fees, and understanding the blockchain's interface. Chain abstraction removes these barriers. Users can perform transactions across different blockchains using their existing NEAR wallet and interface, without worrying about the specific details of each blockchain. This concept is similar to how the Internet works—users can visit many different websites without understanding the underlying infrastructure or protocols.

How it works

Account Aggregation

NEAR's account system is designed to manage multiple keys within a single account, enabling users to transact on various blockchains without having multiple seed phrases or private keys. This feature, known as account aggregation, allows a single NEAR account to hold keys for different blockchains, making cross-chain interactions seamless. Users can rotate keys without changing their account address, enhancing security and convenience.

For example, a NEAR account can store multiple keys, each with specific permissions. If a key is compromised, it can be replaced without affecting other keys or the account itself. This flexibility is a significant improvement over traditional EVM chains, where each new key pair requires a new address and the migration of assets.

Multi-party computation

Multi-party computation is the backbone of NEAR's chain abstraction. It ensures that private keys are never fully exposed by distributing key generation and signing processes across multiple nodes. Each node holds only a part of the key, and they collaboratively sign transactions without any single node knowing the entire key. This approach significantly enhances security and reduces the risk of key compromise.

The MPC network in NEAR supports key generation and transaction signing for multiple blockchains, including EVM chains and Bitcoin. When a user wants to sign a transaction, each MPC node generates a partial signature, which is then combined to form a full signature. This decentralized approach to key management is critical for secure and efficient cross-chain transactions.

MPC is particularly useful for cross-chain transactions where multiple approvals are required before any action is taken. The coordination required to manage signing policies and approve transactions happens off the blockchain, which can introduce risks related to centralization. However, the benefits of MPC, such as flexible signing processes and detailed control over who can access and sign off on transactions, outweigh these risks.

Traditional MPC networks often rely on deposit-based or bridge-based models, where users must lock assets in smart contracts to facilitate cross-chain transactions. These models can introduce additional layers of complexity and risk, such as managing multiple blockchain addresses and navigating through bridging processes. In contrast, NEAR's MPC implementation uses an account-based pattern, reducing the complexity for users. By enabling a single NEAR account to manage multiple blockchain addresses, NEAR's MPC network simplifies the process and enhances security.

Chain Signatures

Chain Signatures is a significant innovation of NEAR’s chain abstraction. They enable NEAR accounts to sign transactions on multiple blockchains using a decentralized MPC network and dual quorum security model. This helps users avoid complex bridging mechanisms when interacting cross-chain. With chain signatures, a NEAR account acts as a master account, which manages transactions across various networks, including Bitcoin, Ethereum, Cosmos, and more. The core mechanism involves NEAR validators or MPC nodes signing a payload, such as a transaction intended for another blockchain. This payload, once signed, is sent to the destination chain, facilitating seamless cross-chain transactions.

Multichain gas relayer

The Multichain gas relayer is another key component of NEAR's chain abstraction. This solution simplifies the process of covering transaction costs across different blockchain networks. Users can utilize NEAR or NEP-141 tokens to pay transaction fees on any blockchain network without needing to own native gas tokens. This feature enhances the user experience by providing a seamless and cost-effective way to interact with multiple blockchains.

Data Availability layer

Ensuring that transaction data is reliably stored and accessible is crucial for maintaining blockchain integrity. NEAR’s data availability layer provides a decentralized infrastructure for data storage, ensuring that all transaction data is available and verifiable. This layer supports fast and efficient data retrieval, which is essential for high-performance blockchain applications.

For instance, NEAR's data availability layer allows Ethereum rollups to transfer their execution layer to NEAR, benefiting from lower costs and faster transactions without compromising security. This integration showcases how NEAR's data availability solutions can enhance the performance and scalability of other blockchain networks.

Decentralized sequencers

Decentralized sequencers play a fundamental role in transaction validation and achieving consensus within the network. They eliminate the need for a central authority, promoting transparency and reducing the risk of manipulation. Sequencers receive, organize, and execute transactions, ensuring they are included in blocks in a decentralized manner.

NEAR’s decentralized sequencers are crucial for maintaining the integrity and reliability of the blockchain, as they handle critical tasks without relying on a single point of failure. This decentralized approach enhances the security and robustness of the network, making it more resilient to attacks and failures.

Differences between Chain Abstraction and Account Abstraction

Account Abstraction (AA) in Ethereum aims to enhance the user experience by simplifying account management and transaction execution. Key features of AA include the use of UserOperation objects, multi-factor authentication, and flexible gas payments. This system is compatible with EVM chains like Arbitrum, Polygon,… and is supported by wallets such as Ambire, Safe,... In contrast, Chain Abstraction (CA) on the NEAR protocol focuses on cross-chain interoperability, enabling seamless interactions across multiple blockchains from a single interface. CA simplifies user interactions by eliminating the need for cross-chain bridges, allowing users to manage assets and transact across different blockchains without understanding the underlying technology. It is crucial to discuss AA when analyzing CA to prevent confusion between these two concepts.

Applications and Use Cases

Potential use cases for Chain abstraction

With the power of Chain Abstraction, we can significantly streamline multi-chain decentralized application development and operations, making complex blockchain interactions user-friendly and efficient more with users.

Trading blockchain assets without transactions:

• Using chain signatures, users can trade assets across different blockchains by swapping the ownership of NEAR accounts that control funds on various blockchains. This method keeps native tokens on their respective blockchains and enables atomic trades across chains with faster settlement times.

• Traditional cross-chain asset trading typically relies on bridges, leading to longer settlement times and higher complexity. Chain signatures simplify this process by allowing NEAR accounts to control assets on different blockchains. When users trade, they swap control of NEAR accounts that hold the assets, ensuring atomicity and reducing the time required for settlement. This approach enhances the efficiency and security of cross-chain trades by leveraging NEAR's MPC network for transaction signing and validation.

Delegated Smart Contract Permissions:

• Chain signatures enable NEAR smart contracts to execute actions on behalf of users, such as recovering keys for an app user or rebalancing pools based on specific conditions.

• Delegated smart contract permissions allow for automated and secure management of user accounts and assets. For instance, a social recovery contract can facilitate key recovery by involving a user’s trusted contacts. Similarly, smart contracts can execute predefined actions, such as rebalancing asset pools, without direct user intervention. This automation enhances the functionality and security of decentralized applications by leveraging NEAR’s chain signatures to manage permissions and execute actions across different blockchain networks.

These features not only simplify operations but also open up numerous possibilities for multi-chain dApps across various areas.

Cross-chain zero-friction onboarding:

• Using the unique features of the NEAR account model, such as Keypom, users can experience zero-friction onboarding and transactions on NEAR, which can then extend to other chains through chain signatures.

• Keypom leverages NEAR’s account model to provide a seamless onboarding experience by creating restricted NEAR accounts and funding them for initial interactions. Users receive keys with limited control, allowing them to engage with decentralized applications without managing complex account setups. This model can be extended to other chains via chain signatures, facilitating easy onboarding across multiple blockchain networks and enhancing user adoption through simplified processes.

DeFi on Bitcoin and other non-VM chains:

• Chain signatures enable NEAR smart contracts to control externally-owned accounts on non-smart contract chains like Bitcoin. This allows developers to build DeFi applications for Bitcoin, utilizing NEAR as a smart contract layer.

• By enabling NEAR smart contracts to manage Bitcoin accounts, chain signatures open up DeFi possibilities for non-smart contract blockchains. For example, a decentralized exchange for Bitcoin Ordinals can be built using NEAR smart contracts to manage deposits and verify trades. This approach leverages NEAR’s MPC and decentralized sequencer infrastructure to ensure secure and efficient cross-chain transactions, extending the functionality of Bitcoin and other similar blockchains.

Multichain Decentralized Exchanges:

• One of the most desired but complex-to-build use cases is a decentralized exchange (DEX) that works across most, if not all, chains. Currently, users must default to centralized exchanges for such a multichain experience due to the complexity of bridging, gas, and handling separate wallets. With Account Aggregation, DEX smart contracts can live on NEAR while having deposit addresses across all chains. This means there is no need to bridge assets to a single chain to swap or for the user to bridge to the chain where assets have liquidity. Instead, they can easily swap BTC on the Bitcoin network for OP on Optimism using such a NEAR smart contract.

Multichain dApps:

• Chain abstraction demonstrates its potential to revolutionize multi-chain dApps, extending its capabilities beyond decentralized exchanges to include lending protocols, staking platforms, and decentralized autonomous organizations (DAOs).

• For instance, a developer could build a lending platform on NEAR that interacts with assets on Ethereum, Bitcoin, and other chains, allowing users to collateralize, lend, or borrow assets across these networks seamlessly. Similarly, a DAO could operate transparent governance mechanisms that integrate voting systems from multiple chains, enhancing participation and security for its members. NEAR’s efficient consensus mechanism and low transaction costs further amplify its suitability for complex, high-frequency trading platforms, and financial instruments, making it a practical and attractive option for developers looking to create next-generation dApps that require robust multi-chain functionality.

• Practical examples:

  • Lending protocols: At present, platforms like Burrow utilize the Rainbow Bridge to enable cross-chain interactions. However, the future lies in Chain Abstraction, which will allow even greater simplification and standardization across blockchain interactions. Users can deposit digital assets as collateral on one blockchain and borrow against them on another due to this advanced feature, promoting smooth capital movement and enhanced financial flexibility. This advanced feature also helps developers by streamlining the incorporation of various blockchain protocols, consensus mechanisms, and smart contract languages. The barrier to creating complex multi-chain applications will be significantly lower, reducing both the potential for errors and the complexity involved.

  • Staking platforms: Chain Abstraction aids in creating staking platforms that can operate over multiple blockchains, enhancing user engagement by allowing staking of various assets from different chains, all managed through a single NEAR-based interface. This not only simplifies the user experience but also maximizes the earning potential across different networks.

  • Decentralized Autonomous Organizations: NEAR enhances DAO functionality by allowing decentralized governance activities to span across blockchains, where decisions made on the NEAR platform can directly influence actions on connected chains. This is crucial for DAOs that manage cross-chain assets or projects that require coordinated decision-making across a decentralized network.

  • Decentralized Exchanges: Ref 2.0, powered by NEAR's Chain Abstraction, is redefining the multi-chain DEX landscape. This advanced platform supports trading between multiple assets across different blockchains, incorporating complex features such as liquidity pooling and yield farming, all optimized through NEAR’s fast and low-cost transactions. NEAR's revolutionary approach allows for trustless signing of transactions across chains, eliminating the need for traditional cross-chain bridges.

Web2 Authentication-Controlled blockchain accounts:

• This use case involves managing Web3 accounts using existing Web2 authentication methods, such as passkeys, OAuth, or similar protocols. Users can interact with blockchain applications on multiple networks (e.g., Ethereum, Polygon) by validating their identity with a secure token, which is then used to sign transactions.

• Web2 authentication-controlled blockchain accounts streamline user onboarding by integrating familiar Web2 authentication methods. By using secure tokens to validate identities, NEAR allows users to manage blockchain accounts without dealing with complex seed phrases or key management. This integration enhances security and user experience, making it easier for users to adopt blockchain technology. The NEAR contract that supports secure token authentication ensures that users can interact with various blockchain networks securely and efficiently.

Real-World Applications

SWEAT Economy:

• This application utilizes NEAR’s multichain gas relayer to enable users to send transactions from NEAR to the BNB chain, with gas fees paid using SWEAT tokens. This integration demonstrates how chain abstraction can simplify the transaction process and enhance user experience by removing the need for managing multiple gas tokens.

• The SWEAT Economy’s use of the multichain gas relayer illustrates the practical application of abstracting gas fees across blockchains. By allowing users to pay gas fees with SWEAT tokens, NEAR Protocol effectively eliminates the barrier of acquiring native gas tokens for each transaction, streamlining the user experience and promoting broader adoption. This approach leverages NEAR’s account aggregation and multichain capabilities to facilitate seamless cross-chain transactions, enhancing the usability of blockchain technology for non-technical users.

East Blue:

• Leveraging NEAR’s chain signatures, East Blue pioneers Bitcoin DeFi use cases, allowing users to extend Bitcoin’s functionality through smart contracts. This approach opens new avenues for Bitcoin applications, such as decentralized finance, without compromising security.

• East Blue’s implementation of chain signatures to facilitate Bitcoin DeFi transactions is a significant advancement in blockchain interoperability. By utilizing NEAR’s MPC key generation and decentralized sequencers, East Blue enables secure and efficient cross-chain transactions. This use case highlights the robustness of NEAR’s chain signatures in extending the capabilities of legacy blockchains like Bitcoin, providing secure access to DeFi applications and expanding the functionality of Bitcoin through seamless interaction with smart contracts.

LiNEAR:

• LiNEAR develops a multichain, multi-asset staking framework on top of EigenLayer, facilitating secure restaking of non-ETH assets, including NEAR, for application security. This framework showcases the versatility of NEAR’s chain abstraction in supporting diverse staking mechanisms.

• The multichain, multi-asset staking framework developed by LiNEAR leverages NEAR’s account aggregation and MPC key management to support the secure restaking of assets across multiple blockchains. By integrating with EigenLayer, LiNEAR ensures that staking and restaking processes are secure and efficient, utilizing NEAR’s robust data availability and decentralized sequencer infrastructure. This enhances the security and scalability of staking mechanisms, making it easier for users to manage and stake diverse assets across different blockchain networks.

Mintbase:

• Mintbase enables NEAR-based wallet holders to purchase Ethereum-based NFTs directly, illustrating the seamless interoperability between NEAR and Ethereum ecosystems. This use case highlights the potential of chain abstraction to bridge different blockchain networks and simplify user interactions.

• By utilizing NEAR’s chain signatures and multichain gas relayer, Mintbase eliminates the need for users to switch between different wallets and manage multiple blockchain accounts. This interoperability enhances the user experience by providing a unified interface for cross-chain transactions, demonstrating the practical benefits of chain abstraction in the NFT market.

Future work and open questions

Potential improvements

Enhanced blockchain support:

• NEAR’s MPC currently works with the ECDSA signing scheme, allowing it to function seamlessly on any blockchain that uses ECDSA. It would be beneficial to explore and add support for additional signing schemes such as EdDSA and Schnorr to further improve its chain abstraction capabilities.

• Expanding support to include these additional signing schemes will provide users with more options and greater flexibility in interacting with different blockchain ecosystems. However, supporting multiple signing schemes presents a challenge in managing the same user addresses across different blockchains, as these addresses will no longer be identical due to the use of different schemes. This expansion will need strong protocols for interoperability and full support for different cryptographic signatures, making NEAR a more flexible and inclusive platform.

Advanced data availability solutions:

• Further development of data availability solutions to ensure even faster and more reliable data access and storage.

• Improving data availability solutions is crucial for maintaining the integrity and performance of blockchain applications. NEAR’s focus on advanced data availability mechanisms can enhance the speed and reliability of data retrieval, supporting high-frequency trading, real-time gaming, and other applications requiring quick and dependable access to blockchain data. This involves optimizing decentralized storage systems and ensuring efficient data replication and retrieval protocols.

Refinement of MPC techniques:

• Enhancing the efficiency and security of MPC techniques used in key generation and transaction signing.

• Continuous refinement of MPC techniques is essential to improve the scalability and security of NEAR’s chain abstraction solutions. By optimizing the computational processes involved in MPC key generation and transaction signing, NEAR can reduce latency and enhance the overall user experience. This involves advancing cryptographic algorithms and implementing more efficient multi-party computation protocols to handle increasing transaction volumes and user demands.

Open questions

• Scalability: How scalable are the current chain abstraction mechanisms as the number of validators or MPC nodes and transactions grows?

  • Addressing scalability is a critical challenge for NEAR’s chain abstraction framework. Ensuring that the system can handle a growing number of validators or MPC nodes and transactions without degrading performance requires innovative scaling solutions, such as sharding, improved consensus algorithms, and optimized network protocols. Future research should focus on evaluating and enhancing the scalability of NEAR’s infrastructure to support widespread adoption.

• Security concerns: Are there potential security vulnerabilities in the MPC network or decentralized sequencers that need addressing?

  • Identifying and mitigating security vulnerabilities in the MPC network and decentralized sequencers is crucial to maintaining trust in NEAR’s chain abstraction solutions. Potential attack vectors, such as collusion between nodes or vulnerabilities in the key generation process, need to be thoroughly analyzed and addressed. Ongoing security audits, advanced cryptographic research, and robust security protocols are essential to ensure the integrity and security of the system.

Final thoughts:

Impact of NEAR Protocol’s Chain Abstraction across the ecosystem

• NEAR Protocol's Chain Abstraction makes blockchain development easier by hiding the complex interactions between different blockchains. Developers can focus on building strong applications without worrying about the complicated details of each blockchain. It also makes transactions across multiple blockchains smooth, simplifying development and cutting costs.

• For users, NEAR’s Chain Abstraction offers a simpler and more unified experience. Users can interact with different blockchain platforms through one easy-to-use interface, making it much easier to learn and use. This user-friendly approach is key to wider adoption, potentially boosting trust and the number of transactions in the NEAR ecosystem.

The future of blockchain usability

• While NEAR Protocol is a major player in chain abstraction, it's not the only one making strides in this area. The blockchain world is full of new developments, with many different platforms working towards a more connected and easy-to-use Web3 experience. From Ethereum's improvements in interoperability to newer players introducing innovative solutions, the dynamics of collaboration and competition in this space are driving the development of technologies designed to reduce fragmentation across the blockchain ecosystem.

• Together, these innovations are building a foundation for a future where the complexity of blockchain is effortlessly hidden from the user. This push for chain abstraction is a major step toward making blockchain technology common and easy to use, preparing for a digital world where technology supports user interaction smoothly without being too complex. Looking ahead, the evolution of chain abstraction will likely play a crucial role in the widespread adoption and practical application of Web3 technologies.

References

• Hub, N. B. (2024, April 17). The Power of Chain Abstraction and Chain Signatures on NEAR Protocol. Medium. https://medium.com/@nearbalkans/the-power-of-chain-abstraction-and-chain-signatures-on-near-protocol-2f95b4338a7f

• NEAR Team. (2024, April 25). NEAR - Your Gateway to an Open Web | NEAR Documentation. Docs.near.org. https://docs.near.org/

• Polosukhin, I. (2024, January 24). Why Chain Abstraction Is the Next Frontier for Web3. NEAR Protocol. https://pages.near.org/blog/why-chain-abstraction-is-the-next-frontier-for-web3/

• Polosukhin, I., Millar-Durrant, D., Ravi, G., Ortega, D., & Anderson, M. (2024, February 15). Unlocking Web3 Usability with Account Aggregation. NEAR Protocol. https://pages.near.org/blog/unlocking-web3-usability-with-account-aggregation/

• Ref Finance. (2023, December 13). A Thesis on Ref 2.0 as a Chain Abstracted DEX. Medium. https://ref-finance.medium.com/a-thesis-on-ref-2-0-as-a-chain-abstracted-dex-e79d14fb0112

Bitcoin's Layer 2 Overview

In the intricate landscape of financial technology, Bitcoin stands as a beacon of innovation, a digital currency that sidesteps the conventional financial mediators, enabling unmediated, peer-to-peer exchanges. However, with its rise comes a series of inherent challenges, most notably those tied to scalability and transaction throughput — important obstacles on the path toward more widely applicable.

These challenges aren't unique to Bitcoin, Ethereum - although also designed with flexible application development capabilities - also has similar problems. And many solutions have been proposed to solve this problem for both, such as side-chains, layer 2, or payment channels networks. With Ethereum, the layer 2 ecosystem is rapidly expanding, with diverse solutions like EVM rollups, sidechains transitioning to rollups, and projects striving for various degrees of decentralization and security. The security implications of layer 2 solutions, particularly focusing on asset guarantees and the ability of these systems to read and adapt to changes in the Ethereum blockchain. It underscores a key trade-off: higher security often comes at the cost of scalability and cost efficiency. [1]

While Bitcoin has made impressive progress in improving its features, it still faces some significant challenges in developing Layer 2 (L2) solutions similar to those found in Ethereum. Bitcoin's design limitation is particularly clear when it comes to ensuring withdrawal security within Bitcoin's Layer 2 solutions. It's scripting language is intentionally limited in functionality, lacking Turing completeness, which restricts its ability to perform complex computations and support advanced functions. This design choice prioritizes Bitcoin's security and efficiency but limits its programmability compared to more flexible blockchain platforms like Ethereum. And the probabilistic finality also can undermine the reliability and speed essential for layer 2 solutions, potentially leading to issues like chain reorganizations that affect transaction permanence. Despite Bitcoin being built on principles that make it reliable and secure, these aspects make it hard for its L2 systems to quickly adapt to new changes.

SegWit and Taproot are game-changers for Bitcoin. SegWit optimized Bitcoin’s infrastructure by segregating signature data, enhancing transaction speed and enabling the Lightning Network’s rapid payment processing. Following this, Taproot introduced efficiencies and privacy enhancements by compacting transaction data and masking transaction complexities. Together, SegWit and Taproot have ignited a new wave of Layer 2 innovations, becoming the backbone for future Layer 2 designs and significantly expanding Bitcoin's functionality beyond its original scope as a digital currency.

Further technical details on SegWit and Taproot can be found in the Appendix.

Understanding Bitcoin's layer 2 solutions

Bitcoin L2 trilemma

In Bitcoin's expanding universe of Layer 2 solutions, we see many different systems emerging, all designed with the intention of enhancing scalability and increasing adoption in various ways. These solutions offer unique approaches to overcome Bitcoin's built-in limitations. One way to categorize these solutions, as introduced by Trevor Owens [2], involves organizing them based on their approach to addressing the Bitcoin L2 trilemma, which segments L2 solutions into Off-Chain Networks, Decentralized Sidechains, and Federated Sidechains, each presenting unique approaches and trade-offs:

• Off-chain networks prioritize scalability and privacy but pose user experience challenges.

  • e.g., Lightning & RGB

• Decentralized sidechains introduce new tokens and consensus mechanisms, expanding functionality but potentially complicating user experience and raising centralization concerns.

  • e.g., Stacks, Babylon, Interlay etc.

• Federated sidechains streamline operations through a trusted consortium, offering efficiency at the possible cost of Bitcoin's foundational trustlessness.

  • e.g., Liquid, Rootstock, Botanix

This trilemma provides a useful way to categorize Bitcoin layer 2 solutions, but it might not fully capture all the complex details of their design. Additionally, it points out the trade-offs of current solutions instead of unresolvable barriers, showing that these elements of the trilemma are part of the decision-making process for developers.

For instance, Decentralized sidechains issue new tokens to increase security and boost network participation, which could make user interactions more complex and might not be welcomed by Bitcoin purists. On the other hand, Federated sidechains choose to skip new tokens, making the user experience smoother and reducing pushback within the Bitcoin community. Another option is to use a full VM/global state, which allows for complex functions, including the creation of new tokens on a smart contract platform. However, this approach makes the system more complicated and typically increases its vulnerability to attacks.

Technical classification

From another technical viewpoint, we group Bitcoin layer 2 solutions based on their main technical features. This different way of categorizing them looks into various technical details and structures, offers a nuanced understanding of how each solution contributes to the overarching goal of enhancing Bitcoin's scalability, security, and functionality. Each approach has its distinct purpose, and these purposes do not conflict with one another, nor do they create a trilemma. However, each approach has its own set of advantages and disadvantages concerning security and scalability. Therefore, some systems may utilize a combination of these approaches. We will discuss this in more detail in the next section of the article. Let's explore these categories:

• Sidechains utilizing 2-Way pegged protocol: These sidechains work like a layer 2 connected to Bitcoin through a method called two-way pegging. This setup enables the transfer of Bitcoins between the main blockchain and the sidechain, enabling both experimentation and the implementation of features not directly supported on the main blockchain. This method improves Bitcoin’s ability to handle more transactions and different types of applications by supporting a wider range of uses. The two-way peg mechanism plays a critical role in transferring BTC value to the sidechain. On these sidechains, developers set up various environments; some choose to use an EVM-compatible ecosystem, while others opt to create a VM environment with their own smart contracts.

  • e.g., Stacks, Rootstock, Liquid, Botanix,…

• Blockchain rollups: This method uses Bitcoin as a data storage layer for rollup techniques, inspired by the Inscription protocol. In this setup, each UTXO acts like a small canvas where more complex information can be written. Think of it as if each Bitcoin could store its own set of detailed data, this not only adds value but also broadens the types of data and assets that Bitcoin can handle. It opens up a wide range of possibilities for digital interactions and representations, making the Bitcoin ecosystem richer and more varied.

  • e.g., B2 network, BitVM

• Payment channels networks: Think of these as a network of express lanes within the broader Bitcoin landscape. They help speed up numerous transactions on Bitcoin's side roads, reducing congestion and ensuring that transactions are both fast and cost-effective.

  • e.g., Lightning & RGB

By breaking it down this way, we get a clearer picture of how each tool helps improve Bitcoin, making it more scalable, secure, and versatile. Let's dive in and get to know these tools a little better:

2-Way Pegged Protocols:

A 2-way peg allows assets to be transferred between two distinct blockchains—often a mainchain and a sidechain. This system enables assets to be locked on one chain and subsequently unlocked or minted on another, maintaining a fixed conversion rate between the original and pegged assets.

Understanding the Peg-In Process

Envision initiating a journey where your assets from the mainchain (like Bitcoin) are to be transferred to a sidechain. The peg-in process is your starting point. Here, your assets are securely locked on the mainchain, akin to depositing them in a vault for safekeeping. Subsequently, a transaction is crafted on the mainchain to solidify this lock. The sidechain, recognizing this transaction, mints an equivalent amount of pegged assets. This process is akin to receiving a voucher of the same value in a foreign land, enabling you to use your wealth in a new context while ensuring that your original assets remain intact and secure.

Navigating the Peg-Out Process

When you decide to revert your assets to the original mainchain, the peg-out process comes into play. This is the return journey where the pegged assets on the sidechain are metaphorically 'burned' or locked away, signifying that they are set aside and no longer in circulation on the sidechain. You then provide proof of this action to the mainchain. Once the mainchain verifies your claim, it releases the equivalent original assets back to you. This mechanism ensures the integrity and balance of asset distribution across both blockchains, safeguarding against duplication or loss.

Implementations of Two-Way Peg Systems:

Rootstock:

RSK's 2-way peg system is an advanced framework designed to seamlessly integrate Bitcoin with smart contract capabilities via RSK's platform. By utilizing SPV for efficient transaction verification, employing a robust federated model for transaction approval, and integrating SegWit and Taproot, RSK not only enhances its transaction efficiency but also closely aligns with Bitcoin’s security model. Moreover, the merge mining approach increases the security level of the system and incentivizes more miner participation.

• RSK federated model:

  Pegnatories, a select group of functionaries, are the guardians of this bridge or the custodians of trust in this federated model, ensuring that every peg-in and peg-out adheres to the agreed protocols. Picture them as a council of guardians, each holding a key to a collective vault. Their role is crucial—they ensure that every transaction crossing the bridge does so with integrity and consensus, maintaining a secure and orderly flow of digital assets across this vital passageway.

• Segwit and Taproot:

  SegWit helps by separating the signature information from the transaction data, which reduces transaction sizes and improves processing times. Additionally, combining the Schnorr signature scheme with MAST (Merkelized Abstract Syntax Trees) and other enhancements from Taproot could make transactions even more efficient and private.

• RSK merge mining:

  In RSK's merge mining approach, miners concurrently secure both the Bitcoin and RSK networks without additional computational demands, thereby boosting RSK's security. This method utilizes Bitcoin's mining strength, offering miners extra rewards and showcasing an innovative use of existing blockchain infrastructure. However, the success of this integration depend on accurately aligning the tags within Bitcoin blocks to correspond with RSK blocks, underlining the necessity for detailed and precise execution to uphold the security and consistency of the interconnected networks.

Botanix:

Botanix integrates a combination of a Proof of Stake (PoS) consensus layered on Bitcoin foundation and a decentralized EVM network Spiderchain multi-signature architecture to manage Turing-complete smart contracts off the main Bitcoin blockchain. While Bitcoin serves as the main settlement layer, Botanix ensures transaction integrity using advanced multi-signature wallets and cryptographic verifications off-chain.

• Spiderchain: A distributed network of multisigs that secures all the actual Bitcoin on Botanix.

  • Architecture: Spiderchain formed by a group of Orchestrator nodes - node runners and liquidity sources for the entire chain. It consists of a sequential array of multi-signature wallets that manage the custody of assets within the network. Each wallet in the series requires multiple Orchestrator approvals for any transaction, ensuring there is no single point of failure.

  • Dynamic operation: For each new Bitcoin block, the corresponding Orchestrators for the upcoming 'epochs' (a term used to define the periods between Bitcoin blocks in the Botanix system) are determined using a verifiable random function based on the Bitcoin block hash. Subsequent slot selections for Orchestrators are calculated by hashing the block hash with SHA256, then applying modulo arithmetic with the number of active Orchestrators (N) to ensure fairness and randomness in Orchestrator selection. This ensures fair and secure distribution of operational tasks, minimizing centralization risks.

• Two-way peg system: Multi-signature wallets play a crucial role here, requiring consensus among selected Orchestrators to execute any transactions.

  • Peg-in process: Users send Bitcoins to a new multi-signature wallet where they are securely locked. This action mints an equivalent amount of synthetic BTC on the Botanix chain. Creating this wallet involves several Orchestrators, they must all agree and sign off, making sure no one can control the wallet independently.

  • Peg-out process: Conversely, for peg-outs, synthetic BTC is burned, and the corresponding Bitcoins are released from the multi-signature wallets back to the user’s Bitcoin address. This process is secured by the same multi-signature protocol, requiring several Orchestrators to approve the transaction.

• PoS consensus and EVM implementation:

  • Consensus: In Botanix’s PoS system, Orchestrators stake their Bitcoin to participate in the network. They are responsible for validating transactions and creating new blocks within the Botanix chain. The selection process for these Orchestrators is based on their stake and is randomized using the method mentioned in the Spiderchain section.

  • EVM implementation: The EVM on Botanix supports all operations compatible with Ethereum, enabling developers to deploy and execute complex smart contracts.

Stacks:

Stacks platform aims to scale Bitcoin's infrastructure by enabling smart contracts and decentralized applications (dApps) through innovative mechanisms such as the sBTC two-way peg, Proof of Transfer and Clarity smart contracts.

• sBTC two-way peg protocol:

  • Threshold signature wallet: This wallet utilizes threshold signature schemes that require a predefined subset of signers (Stackers) to collaboratively sign pegging transactions. These Stackers are chosen using a Verifiable Random Function (VRF) based on the amount of STX they have locked up and rotate every cycle (typically two weeks), ensuring dynamic membership and continual alignment with the network's current state. This significantly enhances the security and robustness of the pegging mechanism by preventing dishonest behaviors and potential collusion among participants, while also ensuring fairness and unpredictability in the selection process.

• Proof of Transfer (PoX):

  • In PoX, instead of burning Bitcoin as in Proof of Burn, miners transfer BTC to participate in the Stack network, contributing to security by leveraging Bitcoin's robust proof of work system. This not only incentivizes participation through BTC rewards but also directly ties Stacks' operational stability to Bitcoin's proven security properties. Stacks transactions anchor to Bitcoin blocks, with each Stacks block recording a hash in a Bitcoin transaction using the OP_RETURN opcode, which allows embedding up to 40 bytes of arbitrary data. This mechanism ensures that any alterations to Stacks' blockchain would require corresponding changes in Bitcoin's blockchain, thus benefiting from Bitcoin's security without necessitating any changes to its protocol.

• Clarity:

  • Clarity, the smart contract programming language used on the Stacks blockchain, ensures predictability and security for developers by enforcing strict rules that guarantee all operations are executed as defined, without unintended outcomes. It offers decidability, where the outcome of every function is known before execution, preventing surprises and enhancing contract reliability. Additionally, Clarity makes direct interactions with Bitcoin transactions, allowing the development of complex applications that leverage Bitcoin's robust security features. It also supports traits for modularity, similar to interfaces in other languages, which aid in code reuse and maintain clean code bases.

Liquid:

The Liquid Network offering a federated sidechain to the Bitcoin protocol that significantly enhances transaction capabilities and asset management. Central to the Liquid Network's architecture is the concept of Strong Federations [6], which consists of a consortium of trusted functionaries responsible for block validation and signing.

• Watchmen: Watchmen manages the peg-out process from Liquid to Bitcoin, ensuring each transaction is authorized and valid.

  • Key management: The Watchmen's hardware security modules safeguard the keys needed for authorizing transactions.

  • Transaction Validation: Watchmen validate transactions through cryptographic proofs that confirm adherence to Liquid’s consensus rules, utilizing multi-signature schemes for enhanced security.

• The Peg mechanism:

  • Peg-Ins: Bitcoins are locked on the Bitcoin blockchain (by using multisig address of Watchmen) and equivalent Liquid Bitcoins (L-BTC) are issued on the Liquid sidechain using cryptographic methods to ensure accuracy and security in the transfer.

  • Peg-Outs: The process involves the burning of L-BTC on the Liquid sidechain, with the corresponding release of actual bitcoins on the Bitcoin blockchain. This mechanism is closely monitored by designated functionaries known as Watchmen to ensure only authorized transactions proceed.

• Proof of Reserve (PoR): a critical tool developed by Blockstream for providing transparency and trust regarding asset holdings on the network. PoR involves creating a Partially Signed Bitcoin Transaction that demonstrates control over funds. This transaction, although not valid for broadcast on the Bitcoin network, proves the existence and control of the reserves claimed. It allows entities to prove possession of funds without moving them.

Babylon:

Babylon is designed to integrate Bitcoin into the Proof-of-Stake (PoS) ecosystem by allowing Bitcoin holders to stake their assets to enhance the security of PoS chains, leveraging Bitcoin's vast market capitalization without the need for direct transaction or smart contract capabilities on the Bitcoin blockchain. Importantly, Babylon avoids the complexities and security risks of bridging by not attempting to move or lock Bitcoin through vulnerable bridges or third-party custodians, thus preserving the integrity and security of staked assets.

• Bitcoin-timestamping:

  • Babylon employs a timestamping mechanism that embeds PoS chain data directly into the Bitcoin blockchain. By anchoring PoS block hashes and critical staking events onto Bitcoin’s immutable ledger, Babylon provides a historical timestamp that is secured by Bitcoin’s extensive proof-of-work. The use of Bitcoin’s blockchain for timestamping not only leverages its security but also its decentralized trust model. This method ensures an additional layer of security against long-range attacks and state corruption across interconnected blockchains.

• Accountable assertions:

  • Babylon utilizes accountable assertions to manage staking contracts directly on the Bitcoin blockchain, allowing the system to expose a staker’s private keys in the event of misbehavior, such as double signing. The design uses chameleon hash functions and Merkle trees to ensure that assertions made by stakers are cryptographically linked to their stakes, enabling automatic slashing. This approach enforces protocol integrity through cryptographic accountability, where any deviation by a staker, such as signing conflicting statements, results in the deterministic exposure of their private key, thus triggering automated penalties.

• Staking protocol:

  • One of the significant innovations in Babylon is its staking protocol, which allows for rapid adjustments in staking allocations based on market conditions and security needs. This protocol supports fast stake unbonding, enabling stakers to quickly move their assets without the long lock-up periods typically associated with PoS chains. Moreover, the protocol is built as a modular plug-in, compatible with various PoS consensus mechanisms. This modular approach allows Babylon to provide staking services to a broad range of PoS chains without requiring significant modifications to their existing protocols.

Payment Channels & Lightning network:

Payment Channels are tools designed to enable multiple transactions between two parties without committing all of them to the blockchain immediately. Here’s how they streamline transactions:

• Initiation*: A channel is opened via a single on-chain transaction, creating a multisig wallet shared by the two parties.*

• Transaction process*: Inside the channel, parties transact privately with instant transfers, adjusting their respective balances without broadcasting to the blockchain.*

• Closure*: The channel is closed by another on-chain transaction that settles the final balances, based on the most recent mutually agreed transaction.*

Exploring the Lightning Network:

Building on the idea of Payment Channels, the Lightning Network extends these concepts into a network, allowing users to send payments across the blockchain through connected paths.

• Routing: Like finding a route through a city using backroads, the network finds a path for your payment, even if you don’t have a direct channel open with the final recipient.

• Efficiency: This interconnected system significantly reduces transaction fees and processing times, making Bitcoin practical for everyday transactions.

• Smart Locks (HTLCs): The network uses advanced contracts called Hashed Timelock Contracts to secure payments across different channels. It’s like making sure your delivery passes through several checkpoints securely before reaching its destination. It also mitigates the risk of intermediary default, making the network reliable.

• Security Protocol: In case of any disagreement, the blockchain acts as a judge to verify the latest agreed-upon balance, ensuring fairness and security.

Taproot and Segwit have turbocharged the Bitcoin network and also particularly benefiting the Lightning Network with enhanced privacy and efficiency:

• Taproot is like an aggregator for Bitcoin transactions—it bundles multiple signatures into one. This not only keeps off-chain transactions tidy but also makes them more private and cheaper.

• Segwit changes how data is stored in Bitcoin transactions, makes a block can contain more transactions. For the Lightning Network, this means opening and closing channels is cheaper and smoother, further reducing fees and improving transaction throughput

Inscription-based Layer 2 Solutions:

Inscriptions have sparked a new wave of innovation in the Bitcoin layer 2 ecosystem. With the advent of two groundbreaking updates (Segwit & Taproot), the Ordinals protocol was introduced, enabling anyone to attach additional data to UTXO's Taproot script, up to 4MB. This development has led the community to realize that Bitcoin can now serve as a Data Availability layer. In terms of security, inscriptions provide a fresh perspective. Data, like digital artifacts, are now stored directly on the Bitcoin network, making them unchangeable and safeguarded against tampering or loss from external server issues. This not only enhances the security of digital assets but also embeds them directly into Bitcoin's blocks, ensuring they are permanent and reliable. Most importantly, Bitcoin rollups have become a reality, with inscriptions providing a mechanism to incorporate extra data or functionalities within transactions. This allows for more complex interactions or state changes to happen off the main chain while still being anchored to the main chain's security model.

Implementations of Inscription-based Layer 2 Solutions:

BitVM:

BitVM utilizing a combination of optimistic rollup technology optimistic rollup technology and cryptographic proofs in it's design. By moving Turing-complete smart contracts off-chain, BitVM significantly enhances transaction efficiency without compromising security. While Bitcoin remains the foundational settlement layer, BitVM ensures transaction data integrity through clever utilization of Bitcoin's scripting capabilities and cryptographic verifications off-chain. Currently, BitVM is being actively developed by the community. [9] Additionally, it has also become the platform for several top-tier projects, such as Bitlayer [7] and Citrea [8].

• Inscription-like storage approach:

  BitVM utilizes Bitcoin's Taproot to embed data within Tapscript, similar to the concept of the Inscription protocol. This data typically includes important computational details such as the virtual machine's state at different checkpoints, the hash of the initial state, and the final computation results. By anchoring this Tapscript in an unspent transaction output (UTXO) stored in a Taproot address, BitVM effectively integrates transaction data directly onto the Bitcoin blockchain. This approach ensures the durability and immutability of the data while benefiting from Bitcoin's security features to protect the integrity of recorded computations.

• Fraud proofs:

  BitVM ensures the security of its transactions using fraud proofs. Here, a prover commits to the output of a computation for specific inputs, and this commitment isn't executed on-chain but rather verified indirectly. If a verifier suspects a commitment to be false, they can challenge it by providing a concise fraud proof that leverages Bitcoin's scripting capabilities to demonstrate the commitment's incorrectness. This system significantly reduces the blockchain's computational load by avoiding full on-chain computation, aligning with Bitcoin's design philosophy of minimal transaction load and maximum efficiency. Central to this mechanism are hashlocks and digital signatures, which secure claims and challenges and link them to the actual off-chain computational work. BitVM adopts an optimistic verification approach—operations are presumed correct unless proven otherwise, which enhances efficiency and scalability. This ensures that only valid computations are accepted, and anyone on the network can independently verify their correctness using the available cryptographic proofs.

• Optimistic rollups:

  BitVM employs optimistic rollup technology to significantly enhance Bitcoin’s scalability by batching multiple off-chain transactions for collective processing and validation. In practical terms, BitVM processes these transactions off-chain and intermittently records their outcomes on the Bitcoin ledger to ensure integrity and availability. The use of optimistic rollups in BitVM represents an approach to overcoming Bitcoin's inherent scalability limitations by leveraging off-chain computation capabilities while ensuring that transaction validity is maintained through periodic on-chain verification. This system effectively balances the load between on-chain and off-chain resources, optimizing both security and efficiency in transaction processing.

Overall, BitVM is not just another Layer 2 technology but represents a potential foundational shift in how Bitcoin could scale and evolve. It offers unique solutions to Bitcoin’s limitations but still requires further development and improvement to fully realize its potential and gain wider adoption within the community.

B2 network:

The B2 Network stands out as the first zero-knowledge proof verification commitment rollup for Bitcoin, utilizing rollup technology and zero-knowledge proof to enhance transaction speed and minimize costs. This setup allows for Turing-complete smart contract execution for off-chain transactions, significantly boosting efficiency. Bitcoin acts as the fundamental settlement layer for the B2 Network, where B2 rollup data is stored. This setup enables the full retrieval or restoration of B2 rollup transactions using Bitcoin inscriptions. Moreover, the computational validity of B2 rollup transactions is verified through zero-knowledge proof confirmations on Bitcoin.

• Important role of Inscriptions:

  The B2 Network leverages Bitcoin inscriptions to embed additional data within a Tapscript, which includes vital information like the storage path of rollup data, merkle tree root hash of the rollup data, zk proof data, and the parent B2 inscription UTXO hash. By writing this Tapscript into a UTXO and sending it to a Taproot address, B2 effectively embeds rollup data directly onto the Bitcoin blockchain. This approach not only ensures the permanence and immutability of the data but also utilizes Bitcoin's robust security mechanisms to protect the integrity of the rollup data.

• Zero-knowledge proofs for enhanced security:

  B2's commitment to security is further exemplified by its use of zero-knowledge proofs. These proofs enable the network to validate transactions without exposing the details of those transactions, thus preserving privacy and security. In the context of B2, the network breaks down computational units into smaller ones, each represented as a bit value commitment in a tapleaf script. These commitments are linked in a taproot structure, providing a compact, secure method for verifying transaction validity on the Bitcoin and B2 network.

• Rollup Technology for Scalability:

  At the heart of B2's architecture is the rollup technology, specifically ZK-Rollup, which aggregates multiple off-chain transactions into a single one. This method significantly increases throughput and reduces transaction fees, addressing two of Bitcoin's most pressing scalability issues. The B2 Network's rollup layer processes user transactions and generates corresponding proofs, ensuring the transactions are valid and finalized on the Bitcoin blockchain.

• Challenge-response mechanism: In the B2 Network, after transactions are batched and verified using zk-proofs, there's an opportunity for nodes to challenge these batches if suspected of containing invalid transactions. This critical phase leverages the fraud proof mechanism, where challenges must be conclusively resolved before the batch can proceed. This step ensures that only transactions validated as legitimate advance to final confirmation. The batch is confirmed on the Bitcoin blockchain if no challenges arise or existing challenges fail within the specified time lock. On the other hand, if any challenge is validated, the rollup is subsequently reverted.

Final thoughts:

The good:

• Unlocking DeFi markets: By enabling functionalities like smart contracts through EVM-compatible layer 2 solutions, Bitcoin can tap into the multi-billion dollar DeFi market. This is not only about expanding Bitcoin's utility but also about unlocking new financial markets that were previously accessible only through Ethereum and similar programmable blockchains.

• Widening use cases: More than just financial transactions, these Layer 2 platforms support a range of applications in sectors like finance, gaming, NFTs, or identification system,… thus expanding Bitcoin’s use cases far past its original scope as a simple currency [3, 4, 5].

The bad:

• Risk of centralization: Some of the mechanisms involved in some Layer 2 solutions could lead to increased centralization. For instance, in mechanisms that require a value of BTC to be locked up, unlike Ethereum’s Layer 2 solutions, the interaction from Layer 2 back to Bitcoin is not secured by Bitcoin's security model. Instead, it relies on a smaller decentralized network or a federation model, potentially weakening the trust model's security. This structural difference could introduce points of failure not present in decentralized models.

• Increased transaction fees and blockchain bloat: Data-heavy uses like Ordinals and other inscription protocols can lead to blockchain bloat, slowing down the network and increasing transaction costs for all users. This can lead to higher costs and slower transaction validation times, impacting the efficiency of the network.

• Complexity and user experience: The technical complexity of understanding and interacting with Layer 2 solutions can be a significant barrier to adoption. Users need to manage additional elements such as payment channels on the Lightning Network or handle different token types on platforms like Liquid.

The ugly:

• Regulatory and ethical concerns: The immutability of these inscriptions, while a technical strength, also raises potential regulatory and ethical issues. This poses significant challenges if the data is illegal, unethical, or simply erroneous, leading to permanent consequences without recourse.

• Impact on fungibility: If certain Bitcoins are "tagged" with non-financial data, it could affect their fungibility—where each unit is supposed to be indistinguishable from another—potentially leading to a scenario where some Bitcoins are less valuable or acceptable than others.

References

1. Buterin, V. (2023, October 31). Different types of layer 2s. Vitalik.eth.limo. https://vitalik.eth.limo/general/2023/10/31/l2types.html

2. Owens, T. (2023, November 1). Understanding the “Bitcoin L2 Trilemma.” Bitcoin Magazine - Bitcoin News, Articles and Expert Insights. https://bitcoinmagazine.com/technical/understanding-the-bitcoin-l2-trilemma

3. Nelson, J. (2024, April 4). Bitcoin Layer-2 Social Network Offers Rewards for “Touching Grass” in NFT Game. Decrypt. https://decrypt.co/224764/bitcoin-layer-2-social-network-touching-grass-nft-game

4. Crypto.com. (2023, May 3). Bitcoin’s Expanding Ecosystem: Layer-2, DeFi, NFT. Crypto.com. https://crypto.com/research/bitcoin-ecosystem-layer2-defi-nft

5. Nelson, J. (2024, May 2). MicroStrategy Is Building “Decentralized ID” on Bitcoin Using Ordinals-Like Inscriptions. Decrypt. https://decrypt.co/229087/orange-decentralized-identity-ordinals-inscriptions-microstrategy

6. Dilley, J., Poelstra, A., Wilkins, J., Piekarska, M., Gorlick, B., & Friedenbach, M. (2017, January 30). Strong Federations: An Interoperable Blockchain Solution to Centralized Third-Party Risks. ArXiv. https://doi.org/10.48550/arXiv.1612.05491

7. Chainwire. (2024, April 3). BitVM-Based Bitlayer, a Leading Bitcoin L2, Nets $5M in Funding, Unveils $50M “Ready Player One” Program. Chainwire. https://chainwire.org/2024/04/03/bitvm-based-bitlayer-a-leading-bitcoin-l2-nets-5m-in-funding-unveils-50m-ready-player-one-program

8. Citrea Team. (2024, March 21). Unveiling Clementine - Citrea’s BitVM Based Trust-Minimized Two-Way Peg Program. Citrea · Blog. https://www.blog.citrea.xyz/unveiling-clementine/

9. Rsync. (2024, May 9). Rsync25/awesome-bitvm. GitHub. https://github.com/Rsync25/awesome-bitvm

10. Poon, J., & Dryja, T. (2016). The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments. https://lightning.network/lightning-network-paper.pdf

11. Stacks Team. (2024, February 2). Whitepapers | Stacks Documentation. Stacks.co. https://docs.stacks.co/stacks-101/whitepapers

12. Tas, E. N., Tse, D., Gai, F., Kannan, S., Maddah-Ali, M. A., & Yu, F. (2022). Bitcoin-Enhanced Proof-of-Stake Security: Possibilities and Impossibilities. ArXiv:2207.08392 [Cs], 126–145. https://arxiv.org/abs/2207.08392g

13. Lerner, S. D. (2019, January 29). RSK Bitcoin Powered Smart Contracts. Rootstock. https://rootstock.io/rsk-white-paper-updated.pdf

14. Nick, J., Poelstra, A., & Sanders, G. (2020). Liquid: A Bitcoin Sidechain. https://blockstream.com/assets/downloads/pdf/liquid-whitepaper.pdf

15. B2 team. (2023, November 14). B2: The most practical bitcoin layer-2 network. B2 Network. https://www.bsquared.network/B2.pdf

16. Botanix Team. (2023). Botanix protocol: An EVM equivalent Layer 2 on Bitcoin. https://botanixlabs.xyz/en/r/whitepaper

17. Linus, R. (2023). BitVM: Compute Anything on Bitcoin. https://bitvm.org/bitvm.pdf

18. Babylon Team. (2023). Bitcoin Staking: Unlocking 21M Bitcoins to Secure the Proof-of-Stake Economy. https://docs.babylonchain.io/papers/btc_staking_litepaper(EN).pdf

Appendix

Key technical aspects of SegWit and Taproot

SegWit:

• Reduction in txs size: SegWit reduces transaction size by restructuring the transaction data, separating the signature data (witnesses) from the transaction inputs. This results in a smaller transaction size while ensuring that the transaction identifier (TxID) remains unchanged even if the witness data is modified.

• Increased block capacity: SegWit introduces a new concept called "block weight", by calculate 2 seperated part:

  • Non-witness data: This includes all the transaction details except for the signatures. It is counted normally, just like in the old format.

  • Witness data (signatures): This is where SegWit makes a fundamental change. Witness data is given a quarter weight - meaning it only counts as one-fourth of its actual size in the block weight calculation.

The "block weight" system allows a block to carry more data than the nominal 1MB limit would suggest. By reducing the weight of signature data, the total block weight can include up to 4MB of data while still being classified as 1MB under the block size limit. This arrangement significantly increases transaction throughput by fitting more transactions into each block without exceeding the traditional block size limit set by the Bitcoin network.

Taproot:

Taproot is like adding an extra boost to what SegWit already does. It brings in the Schnorr signature scheme and combines it with Merkelized Abstract Syntax Trees (MAST) along with some other improvements to make things even better. But remember, Taproot or Tapscript doesn't introduce Ethereum-style smart contracts because Bitcoin Script has its limits. It sticks to Bitcoin's design of being straightforward and secure at its core.

• Schnorr signature scheme: This scheme is not only shorter than the ECDSA signatures used pre-Taproot but also allow for the aggregation of multiple signatures into one.

• MAST Integration: By using MAST, Taproot allows for the potential conditions of transactions to be hidden unless they are actually triggered. This means that complex script executions can be made indistinguishable from standard transactions on the blockchain, significantly enhancing privacy and reducing transaction sizes.

Role of SegWit and Taproot in Bitcoin's Layer 2s:

The Inscription Protocol on Bitcoin employs a data storage technique called "envelope," which is a non-executable Bitcoin script that utilizes structures like OP_FALSE, OP_IF, and OP_ENDIF to wrap and secure data without triggering script execution. By not executing, envelopes do not consume any computational resources on the blockchain, thus helping to reduce the load and potential congestion on the network.

Based on SegWit and Taproot upgrades, these envelopes can embed up to 4MB of arbitrary data in a single transaction by maximizing the utilization of the witness space. This is achieved through multiple OP_PUSH commands, each capable of carrying up to 520 bytes. Taproot further contributes by simplifying transaction complexity and enhancing privacy through techniques like signature aggregation, which have the ability to combine multiple signatures into one to reduce transaction size and improve privacy.

Overall, these technological integrations in the Inscription Protocol demonstrate Bitcoin’s evolution toward a more scalable and flexible blockchain infrastructure while maintaining network efficiency and stability.