acid-info/vac.dev
1
0
Fork 0
mirror of https://github.com/acid-info/vac.dev.git synced 2025-02-21 16:18:09 +00:00
Code Issues Packages Projects Releases Wiki Activity

Nescience blog post (#127)

Browse Source
This commit is contained in:
moudyellaz 2023-09-01 10:55:39 -04:00 committed by GitHub
parent 63bf91fba9
commit c23bdff472
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 685 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

685
rlog/2023-08-28-Nescience.mdx Normal file
View File

@ -0,0 +1,685 @@
---
title: 'Nescience - A zkVM leveraging hiding properties'
date: 2023-08-28 12:00:00
authors: Moudy
published: true
slug: Nescience-A-zkVM-leveraging-hiding-properties
categories: research
toc_min_heading_level: 1
toc_max_heading_level: 5
---
Nescience, a privacy-first blockchain zkVM.
<!--truncate-->
# Introduction
Nescience is a privacy-first blockchain project that aims to enable private transactions and provide a general-purpose execution environment for classical applications.
The goals include creating a state separation architecture for public/private computation,
designing a versatile virtual machine based on mainstream instruction sets,
creating proofs for private state updates, implementing a kernel-based architecture for correct execution of private functions,
and implementing core DeFi protocols such as AMMs and staking from a privacy perspective.
It intends to create a user experience that is similar to public blockchains, but with additional privacy features that users can leverage at will.
To achieve this goal, Nescience will implement a versatile virtual machine that can be used to implement existing blockchain applications,
while also enabling the development of privacy-centric protocols such as private staking and private DEXs.
To ensure minimal trust assumptions and prevent information leakage, Nescience proposes a proof system that allows users to create proofs for private state updates,
while the verification of the proofs and the execution of the public functions inside the virtual machine can be delegated to an external incentivised prover.
It also aims to implement a seamless interaction between public and private state, enabling composability between contracts, and private and public functions.
Finally, Nescience intends to implement permissive licensing, which means that the source code will be open-source,
and developers will be able to use and modify the code without any restriction.
Our primary objective is the construction of the Zero-Knowledge Virtual Machine (zkVM). This document serves as a detailed exploration of the multifaceted challenges,
potential solutions, and alternatives that lay ahead. Each step is a testament to our commitment to thoroughness;
we systematically test various possibilities and decisively commit to the one that demonstrates paramount performance and utility.
For instance, as we progress towards achieving Goal 2, we are undertaking a rigorous benchmarking of the Nova proof system against its contemporaries.
Should Nova showcase superior performance metrics, we stand ready to integrate it as our proof system of choice. Through such meticulous approaches,
we not only reinforce the foundation of our project but also ensure its scalability and robustness in the ever-evolving landscape of blockchain technology.
# Goal 1: Create a State Separation Architecture
The initial goal revolves around crafting a distinctive architecture that segregates public and private computations,
employing an account-based framework for the public state and a UTXO-based structure for the private state.
The UTXO model [[1]( https://bitcoin.org/bitcoin.pdf),[2](https://iohk.io/en/blog/posts/2021/03/11/cardanos-extended-utxo-accounting-model/)], notably utilized in Bitcoin, generates new UTXOs to serve future transactions,
while the account-based paradigm assigns balances to accounts that transactions can modify.
Although the UTXO model bolsters privacy by concealing comprehensive balances,
the pursuit of a dual architecture mandates a meticulous synchronization of these state models,
ensuring that private transactions remain inconspicuous in the wider public network state.
This task is further complicated by the divergent transaction processing methods intrinsic to each model,
necessitating a thoughtful and innovative approach to harmonize their functionality.
To seamlessly bring together the dual architecture, harmonizing the account-based model for public state with the UTXO-based model for private state,
a comprehensive strategy is essential.
The concept of blending an account-based structure with a UTXO-based model for differentiating between public and private states is intriguing.
It seeks to leverage the strengths of both models: the simplicity and directness of the account-based model with the privacy enhancements of the UTXO model.
Here's a breakdown and a potential strategy for harmonizing these models:
### <ins> Rationale Behind the Dual Architecture: </ins>
* **Account-Based Model:** This model is intuitive and easy to work with. Every participant has an account,
and transactions directly modify the balances of these accounts. It's conducive for smart contracts and a broad range of applications.
* **UTXO-Based Model:** This model treats every transaction as a new output, which can then be used as an input for future transactions.
By not explicitly associating transaction outputs with user identities, it offers a degree of privacy.
### <ins> Harmonizing the Two Systems: </ins>
1. Translation Layer
* Role: Interface between UTXO and account-based states.
* _UTXO-to-Account Adapter:_ When UTXOs are spent, the adapter can translate these into the corresponding account balance modifications.
This could involve creating a temporary 'pseudo-account' that mirrors the
UTXO's attributes.
* _Account-to-UTXO Adapter:_ When an account wishes to make a private transaction,
it would initiate a process converting a part of its balance to a UTXO, facilitating a privacy transaction.
2. Unified Identity Management
* Role: Maintain a unified identity (or address) system that works across both state models,
allowing users to easily manage their public and private states without requiring separate identities.
* _Deterministic Wallets:_ Use Hierarchical Deterministic (HD) wallets [[3](https://medium.com/mycrypto/the-journey-from-mnemonic-phrase-to-address-6c5e86e11e14),[4](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki)], enabling users to generate multiple addresses (both UTXO and account-based) from a single seed.
This ensures privacy while keeping management centralized for the user.
3. State Commitments
* Role: Use cryptographic commitments to commit to the state of both models. This can help in efficiently validating cross-model transactions.
* _Verkle Trees:_ Verkle Trees combine Vector Commitment and the KZG polynomial commitment scheme to produce a structure that's efficient in terms of both proofs and verification.
Verkle proofs are considerably small in size (less data to store and transmit), where Transaction and state verifications can be faster due to the smaller proof sizes and computational efficiencies.
* _Mimblewimble-style Aggregation_ [[5](https://github.com/mimblewimble/grin/blob/master/doc/intro.md)]: For UTXOs, techniques similar to those used in Mimblewimble can be used to aggregate transactions, keeping the state compact and enhancing privacy.
4. Batch Processing & Anonymity Sets
* Role: Group several UTXO-based private transactions into a single public account-based transaction.
This can provide a level of obfuscation and can make synchronization between the two models more efficient.
* _CoinJoin Technique_ [[6](https://en.bitcoin.it/wiki/CoinJoin)]: As seen in Bitcoin, multiple users can combine their UTXO transactions into one, enhancing privacy.
* _Tornado Cash Principle_ [[7](https://github.com/tornadocash/tornado-classic-ui)]: For account-based systems wanting to achieve privacy, methods like those used in Tornado Cash can be implemented,
providing zk-SNARKs-based private transactions.
5. Event Hooks & Smart Contracts
* Role: Implement event-driven mechanisms that trigger specific actions in one model based on events in the other.
For instance, a private transaction (UTXO-based) can trigger a corresponding public notification or event in the account-based model.
* _Conditional Execution:_ Smart contracts could be set to execute based on events in the UTXO system. For instance,
a smart contract might release funds (account-based) once a specific UTXO is spent.
* _Privacy Smart Contracts:_ Using zk-SNARKs or zk-STARKs to bring privacy to the smart contract layer,
allowing for private logic execution.
### <ins> Challenges and Solutions </ins>
1. Synchronization Overhead
* Challenge: Combining two distinct transaction models creates an inherent synchronization challenge.
* State Channels: By allowing transactions to be conducted off-chain between participants, state channels can alleviate synchronization stresses.
Only the final state needs to be settled on-chain, drastically reducing the amount of data and frequency of updates required.
* Sidechains: These act as auxiliary chains to the main blockchain. Transactions can be processed on the sidechain and then periodically synced with the main chain.
This structure helps reduce the immediate load on the primary system.
* Checkpointing: Introduce periodic checkpoints where the two systems' states are verified and harmonized.
This can ensure consistency without constant synchronization.
2. Double Spending
* Challenge: With two models operating in tandem, there's an increased risk of double-spending attacks.
* Multi-Signature Transactions: Implementing transactions that require signatures from both systems can prevent unauthorized movements.
* Cross-Verification Mechanisms: Before finalizing a transaction, it undergoes verification in both UTXO and account-based systems.
If discrepancies arise, the transaction can be halted.
* Timestamping: By attaching a timestamp to each transaction, it's possible to order them sequentially, making it easier to spot and prevent double spending.
3. Complexity in User Experience
* Challenge: The dual model, while powerful, is inherently complex.
* Abstracted User Interfaces: Design UIs that handle the complexity behind the scenes,
allowing users to make transactions without needing to understand the nuances of the dual model.
* Guided Tutorials: Offer onboarding tutorials to acquaint users with the system's features,
especially emphasizing when and why they might choose one transaction type over the other.
* Feedback Systems: Implement systems where users can provide feedback on any complexities or challenges they encounter.
This real-time feedback can be invaluable for iterative design improvements.
4. Security
* Challenge: Merging two systems can introduce unforeseen vulnerabilities.
* Threat Modeling: Regularly conduct threat modeling exercises to anticipate potential attack vectors,
especially those that might exploit the interaction between the two systems.
* Layered Security Protocols: Beyond regular audits, introduce multiple layers of security checks.
Each layer can act as a fail-safe if a potential threat bypasses another.
* Decentralized Watchtowers: These are third-party services that monitor the network for malicious activities.
If any suspicious activity is detected, they can take corrective measures or raise alerts.
5. Gas & Fee Management:
* Challenge: A dual model can lead to convoluted fee structures.
* Dynamic Fee Adjustment: Implement algorithms that adjust fees based on network congestion and transaction type.
This can ensure fairness and prevent network abuse.
* Fee Estimation Tools: Provide tools that can estimate fees before a transaction is initiated.
This helps users understand potential costs upfront.
* Unified Gas Stations: Design platforms where users can purchase or allocate gas for both transaction types simultaneously,
simplifying the gas acquisition process.
By addressing these challenges head-on with a detailed and systematic approach, it's possible to unlock the full potential of a dual-architecture system,
combining the strengths of both UTXO and account-based models without their standalone limitations.
| Aspect | Details | |
|------------------------ |---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |--- |
| **Harmony** | - **Advanced VM Development:** Design tailored for private smart contracts. - **Leverage Established Architectures:** Use WASM or RISC-V to harness their versatile and encompassing nature suitable for zero-knowledge applications. - **Support for UTXO & Account-Based Models:** Enhance adaptability across various blockchain structures. | |
| **Challenges** | - **Adaptation Concerns:** WASM and RISC-V weren't designed with zero-knowledge proofs as a primary focus, posing integration challenges. - **Complexities with Newer Systems:** Systems like (Super)Nova, STARKs, and Sangria are relatively nascent, adding another layer of intricacy to the integration. - **Optimization Concerns:** Ensuring that these systems are optimized for zero-knowledge proofs. | |
| **Proposed Solutions** | - **Integration of Nova:** Consider Nova's proof system for its potential alignment with project goals. - **Comprehensive Testing:** Rigorously test and benchmark against alternatives like Halo2, Plonky, and Starky to validate choices. - **Poseidon Recursion Technique:** To conduct exhaustive performance tests, providing insights into each system's efficiency and scalability. | |
# Goal 2: Virtual Machine Creation
The second goal entails the creation of an advanced virtual machine by leveraging established mainstream instruction sets like WASM or RISC-V.
Alternatively, the objective involves pioneering a new, specialized instruction set meticulously optimized for Zero-Knowledge applications.
This initiative seeks to foster a versatile and efficient environment for executing computations within the privacy-focused context of the project.
Both WASM and RISC-V exhibit adaptability to both UTXO and account-based models due to their encompassing nature as general-purpose instruction set architectures.
_WASM_, operating as a low-level virtual machine, possesses the capacity to execute code derived from a myriad of high-level programming languages,
and boasts seamless integration across diverse blockchain platforms.
Meanwhile, _RISC-V_ emerges as a versatile option, accommodating both models, and can be seamlessly integrated with secure enclaves like SGX or TEE,
elevating the levels of security and privacy. However, it is crucial to acknowledge that employing WASM or RISC-V might present challenges,
given their original design without specific emphasis on optimizing for Zero-Knowledge Proofs (ZKPs).
Further complexity arises with the consideration of more potent proof systems like (Super)Nova, STARKs, and Sangria, which,
while potentially addressing optimization concerns, necessitate extensive research and testing due to their relatively nascent status within the field.
This accentuates the need for a judicious balance between established options and innovative solutions in pursuit of an architecture harmoniously amalgamating privacy, security, and performance.
The ambition to build a powerful virtual machine tailored to zero-knowledge (ZK) applications is both commendable and intricate.
The combination of two renowned instruction sets, WASM and RISC-V, in tandem with ZK, is an innovation that could redefine privacy standards in blockchain.
Let's dissect the challenges and possibilities inherent in this goal:
1. Established Mainstream Instruction Sets - WASM and RISC-V
* Strengths:
* _WASM_: Rooted in its ability to execute diverse high-level language codes, its potential for cross-chain compatibility makes it a formidable contender.
Serving as a low-level virtual machine, its role in the blockchain realm is analogous to that of the Java Virtual Machine in the traditional computing landscape.
* _RISC-V_: This open-standard instruction set architecture has made waves due to its customizable nature.
Its adaptability to both UTXO and account-based structures coupled with its compatibility with trusted execution environments like SGX and TEE augments its appeal,
especially in domains that prioritize security and privacy.
* Challenges: Neither WASM nor RISC-V was primarily designed with ZKPs in mind. While they offer flexibility,
they might lack the necessary optimizations for ZK-centric tasks. Adjustments to these architectures might demand intensive R&D efforts.
2. Pioneering a New, Specialized Instruction Set
* Strengths: A bespoke instruction set can be meticulously designed from the ground up with ZK in focus,
potentially offering unmatched performance and optimizations tailored to the project's requirements.
* Challenges: Crafting a new instruction set is a monumental task requiring vast resources, including expertise, time, and capital.
It would also need to garner community trust and support over time.
3. Contemporary Proof Systems - (Super)Nova, STARKs, Sangria
* Strengths: These cutting-edge systems, being relatively new, might offer breakthrough cryptographic efficiencies that older systems lack: designed with modern challenges in mind,
they could potentially bridge the gap where WASM and RISC-V might falter in terms of ZKP optimization.
* Challenges: Their nascent nature implies a dearth of exhaustive testing, peer reviews, and potentially limited community support.
The unknowns associated with these systems could introduce unforeseen vulnerabilities or complexities.
While they could offer optimizations that address challenges presented by WASM and RISC-V, their young status demands rigorous vetting and testing.
<center>
| | Mainstream (WASM, RISC-V) | ZK-optimized (New Instruction Set) |
|:------------------:|:-------------------------:|:----------------------------------:|
| Existing Tooling | YES | NO |
| Blockchain-focused | NO | YES |
| Performant | DEPENDS | YES |
</center>
### <ins> Optimization Concerns for WASM and RISC-V: </ins>
* _Cryptography Libraries_: ZKP applications rely heavily on specific cryptographic primitives. Neither WASM nor RISC-V natively supports all of these primitives.
Thus, a comprehensive library of cryptographic functions, optimized for these platforms, needs to be developed.
* _Parallel Execution_: Given the heavy computational demands of ZKPs, leveraging parallel processing capabilities can optimize the time taken.
Both WASM and RISC-V would need modifications to handle parallel execution of ZKP processes efficiently.
* _Memory Management_: ZKP computations can sometimes require significant amounts of memory, especially during the proof generation phase.
Fine-tuned memory management mechanisms are essential to prevent bottlenecks.
### <ins> Emerging ZKP Optimized Systems Considerations: </ins>
* _Proof Size_: Different systems generate proofs of varying sizes. A smaller proof size is preferable for blockchain applications to save on storage and bandwidth.
The trade-offs between proof size, computational efficiency, and security need to be balanced.
* _Universality_: Some systems can support any computational statement (universal), while others might be tailored to specific tasks.
A universal system can be more versatile for diverse applications on the blockchain.
* _Setup Requirements_: Certain ZKP systems, like zk-SNARKs, require a trusted setup, which can be a security concern.
Alternatives like zk-STARKs don't have this requirement but come with other trade-offs.
### <ins> Strategies for Integration: </ins>
* _Iterative Development_: Given the complexities, an iterative development approach can be beneficial.
Start with a basic integration of WASM or RISC-V for general tasks and gradually introduce specialized ZKP functionalities.
* _Benchmarking_: Establish benchmark tests specifically for ZKP operations. This will provide continuous feedback on the performance of the system as modifications are made, ensuring optimization.
* _External Audits & Research_: Regular checks from cryptographic experts and collaboration with academic researchers can help in staying updated and ensuring secure implementations.
# Goal 3: Proofs Creation and Verification
The process of generating proofs for private state updates is vested in the hands of the user, aligning with our commitment to minimizing trust assumptions and enhancing privacy.
Concurrently, the responsibility of verifying these proofs and executing public functions within the virtual machine can be effectively delegated to an external prover,
a role that is incentivized to operate with utmost honesty and integrity. This intricate balance seeks to safeguard against information leakage,
preserving the confidentiality of private transactions. Integral to this mechanism is the establishment of a robust incentivization framework.
To ensure the prover’s steadfast commitment to performing tasks with honesty, we should introduce a mechanism that facilitates both rewards for sincere behavior and penalties for any deviation from the expected standards.
This two-pronged approach serves as a compelling deterrent against dishonest behavior and fosters an environment of accountability.
In addition to incentivization, a crucial consideration is the economic aspect of verification and execution.
The verification process has been intentionally designed to be more cost-effective than execution.
This strategic approach prevents potential malicious actors from exploiting the system by flooding it with spurious proofs, a scenario that could arise when the costs align favorably.
By maintaining a cost balance that favors verification, we bolster the system’s resilience against fraudulent activities while ensuring its efficiency.
In sum, our multifaceted approach endeavors to strike an intricate equilibrium between user-initiated proof creation, external verification, and incentivization.
This delicate interplay of mechanisms ensures a level of trustworthiness that hinges on transparency, accountability, and economic viability.
As a result, we are poised to cultivate an ecosystem where users’ privacy is preserved, incentives are aligned,
and the overall integrity of the system is fortified against potential adversarial actions. To achieve the goals of user-initiated proof creation,
external verification, incentivization, and cost-effective verification over execution, several options and mechanisms can be employed:
1. **User-Initiated Proof Creation:** Users are entrusted with the generation of proofs for private state updates, thus ensuring greater privacy and reducing trust dependencies.
* Challenges:
* Maintaining the quality and integrity of the proofs generated by users.
* Ensuring that users have the tools and knowledge to produce valid proofs.
* Solutions:
* Offer extensive documentation, tutorials, and user-friendly tools to streamline the proof-generation process.
* Implement checks at the verifier's end to ensure the quality of proofs.
2. **External Verification by Provers:** An external prover verifies the proofs and executes public functions within the virtual machine.
* Challenges:
* Ensuring that the external prover acts honestly.
* Avoiding centralized points of failure.
* Solutions:
* Adopt a decentralized verification approach, with multiple provers cross-verifying each other’s work.
* Use reputation systems to rank provers based on their past performances, creating a trust hierarchy.
3. ** Incentivization Framework:** A system that rewards honesty and penalizes dishonest actions, ensuring provers' commitment to the task.
* Challenges:
* Determining the right balance of rewards and penalties.
* Ensuring that the system cannot be gamed for undue advantage.
* Solutions[^1]:
* Implement a dynamic reward system that adjusts based on network metrics and provers' performance.
* Use a staking mechanism where provers need to lock up a certain amount of assets.
Honest behavior earns rewards, while dishonest behavior could lead to loss of staked assets.
4. **Economic Viability through Cost Dynamics:** Making verification more cost-effective than execution to deter spamming and malicious attacks.
* Challenges:
* Setting the right cost metrics for both verification and execution.
* Ensuring that genuine users aren’t priced out of the system.
* Solutions:
* Use a dynamic pricing model, adjusting costs in real-time based on network demand.
* Implement gas-like mechanisms to differentiate operation costs and ensure fairness.
5. ** Maintaining Trustworthiness:** Create a system that's transparent, holds all actors accountable, and is economically sound.
* Challenges:
* Keeping the balance where users feel their privacy is intact, while provers feel incentivized.
* Ensuring the system remains resilient against adversarial attacks.
* Solutions:
* Implement layered checks and balances.
* Foster community involvement, allowing them to participate in decision-making, potentially through a decentralized autonomous organization (DAO).
Each of these options can be combined or customized to suit the specific requirements of your project, striking a balance between user incentives,
cost dynamics, and verification integrity. A thoughtful combination of these mechanisms ensures that the system remains robust, resilient,
and conducive to the objectives of user-initiated proof creation, incentivized verification, and cost- effective validation.
<center>
| Aspect | Details | |
|------------------------------- |------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |--- |
| **Design Principle** | - **User Responsibility:** Generating proofs for private state updates. - **External Prover:** Delegated the task of verifying proofs and executing public VM functions. | |
| **Trust & Privacy** | - **Minimized Trust Assumptions:** Place proof generation in users' hands. - **Enhanced Privacy:** Ensure confidentiality of private transactions and prevent information leakage. | |
| **Incentivization Framework** | - **Rewards:** Compensate honest behavior. - **Penalties:** Deter and penalize dishonest behavior. | |
| **Economic Considerations** | - **Verification vs. Execution:** Make verification more cost-effective than execution to prevent spurious proofs flooding. - **Cost Balance:** Strengthen resilience against fraudulent activities and maintain efficiency. | |
| **Outcome** | An ecosystem where: - Users' privacy is paramount. - Incentives are appropriately aligned. - The system is robust against adversarial actions. | |
</center>
[^1]: Incentive Mechanisms:
* Token Rewards: Design a token-based reward system where honest provers are compensated with tokens for their verification services.
This incentivizes participation and encourages integrity.
* Staking and Slashing: Introduce a staking mechanism where provers deposit tokens as collateral.
Dishonest behavior results in slashing (partial or complete loss) of the staked tokens, while honest actions are rewarded.
* Proof of Work/Proof of Stake: Implement a proof-of-work or proof-of- stake consensus mechanism for verification,
aligning incentives with the blockchain’s broader consensus mechanism.
# Goal 4: Kernel-based Architecture Implementation
This goal centers on the establishment of a kernel-based architecture, akin to the model observed in ZEXE, to facilitate the attestation of accurate private function executions.
This innovative approach employs recursion to construct a call stack, which is then validated through iterative recursive computations.
At its core, this technique harnesses a recursive Succinct Non-Interactive Argument of Knowledge (SNARK) mechanism, where each function call’s proof accumulates within the call stack.
The subsequent verification of this stack’s authenticity leverages recursive SNARK validation.
While this method offers robust verification of private function executions, it’s essential to acknowledge its associated intricacies.
The generation of SNARK proofs necessitates a substantial computational effort, which, in turn, may lead to elevated gas fees for users.
Moreover, the iterative recursive computations could potentially exhibit computational expansion as the depth of recursion increases.
This calls for a meticulous balance between the benefits of recursive verification and the resource implications it may entail.
In essence, Goal 4 embodies a pursuit of enhanced verification accuracy through a kernel-based architecture.
By weaving recursion and iterative recursive computations into the fabric of our system, we aim to establish a mechanism that accentuates the trustworthiness of private function executions,
while conscientiously navigating the computational demands that ensue.
To accomplish the goal of implementing a kernel-based architecture for recursive verification of private function executions,
several strategic steps and considerations can be undertaken: recursion handling and depth management.
<ins> Recursion Handling </ins>
* _Call Stack Management:_
* Implement a data structure to manage the call stack, recording each recursive function call’s details, parameters, and state.
* _Proof Accumulation: _
* Design a mechanism to accumulate proof data for each function call within the call stack.
This includes cryptographic commitments, intermediate results, and cryptographic challenges.
* Ensure that the accumulated proof data remains secure and tamper-resistant throughout the recursion process.
* _Intermediary SNARK Proofs:_
* Develop an intermediary SNARK proof for each function call’s correctness within the call stack.
This proof should demonstrate that the function executed correctly and produced expected outputs.
* Ensure that the intermediary SNARK proof for each recursive call can be aggregated and verified together, maintaining the integrity of the entire call stack.
<ins> Depth management </ins>
* _Depth Limitation:_
* Define a threshold for the maximum allowable recursion depth based on the system’s computational capacity, gas limitations, and performance considerations.
* Implement a mechanism to prevent further recursion beyond the defined depth limit, safeguarding against excessive computational growth.
* _Graceful Degradation:_
* Design a strategy for graceful degradation when the recursion depth approaches or reaches the defined limit.
This may involve transitioning to alternative execution modes or optimization techniques.
* Communicate the degradation strategy to users and ensure that the system gracefully handles scenarios where recursion must be curtailed.
* _Resource Monitoring:_
* Develop tools to monitor resource consumption (such as gas usage and computational time) as recursion progresses.
Provide real-time feedback to users about the cost and impact of recursive execution.
* _Dynamic Depth Adjustment:_
* Consider implementing adaptive depth management that dynamically adjusts the recursion depth based on network conditions, transaction fees, and available resources.
* Utilize algorithms to assess the optimal recursion depth for efficient execution while adhering to gas cost constraints.
* _Fallback Mechanisms:_
* Create fallback mechanisms that activate if the recursion depth limit is reached or if the system encounters resource constraints.
These mechanisms could involve alternative verification methods or delayed execution.
* _User Notifications:_
* Notify users when the recursion depth limit is approaching, enabling them to make informed decisions about the complexity of their transactions and potential resource usage.
Goal 4 underscores the project's ambition to integrate the merits of a kernel-based architecture with recursive verifications to bolster the reliability of private function executions.
While the approach promises robust outcomes, it's pivotal to maneuver through its intricacies with astute strategies, ensuring computational efficiency and economic viability.
By striking this balance, the architecture can realize its full potential in ensuring trustworthy and efficient private function executions.
# Goal 5: Seamless Interaction Design
Goal 5 revolves around the meticulous design of a seamless interaction between public and private states within the blockchain ecosystem.
This objective envisions achieving not only composability between contracts but also the harmonious integration of private and public functions.
A notable challenge in this endeavor lies in the intricate interplay between public and private states,
wherein the potential linkage of a private transaction to a public one raises concerns about unintended information leakage.
The essence of this goal entails crafting an architecture that facilitates the dynamic interaction of different states while ensuring that the privacy and confidentiality of private transactions remain unbreached.
This involves the formulation of mechanisms that enable secure composability between contracts, guaranteeing the integrity of interactions across different layers of functionality.
A key focus of this goal is to surmount the challenge of information leakage by implementing robust safeguards.
The solution involves devising strategies to mitigate the risk of revealing private transaction details when connected to corresponding public actions.
By creating a nuanced framework that com- partmentalizes private and public interactions, the architecture aims to uphold privacy while facilitating seamless interoperability.
Goal 5 encapsulates a multifaceted undertaking, calling for the creation of an intricate yet transparent framework that empowers users to confidently engage in both public and private functions,
without compromising the confidentiality of private transactions. The successful realization of this vision hinges on a delicate blend of architectural ingenuity, cryptographic sophistication, and user-centric design.
To achieve seamless interaction between public and private states, composability, and privacy preservation, a combination of solutions and approaches can be employed.
In the table below, a comprehensive list of solutions that address these objectives:
<center>
| **Solution Category** | **Description** | |
|:-----------------------------------------: |:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: |--- |
| **Layer 2 Solutions** | Employ zk-Rollups, Optimistic Rollups, and state channels to handle private interactions off-chain and settle them on-chain periodically. Boost scalability and cut transaction costs. | |
| **Intermediary Smart Contracts** | Craft smart contracts as intermediaries for secure public-private interactions. Use these to manage data exchange confidentially. | |
| **Decentralized Identity & Pseudonymity** | Implement decentralized identity systems for pseudonymous interactions. Validate identity using cryptographic proofs. | |
| **Confidential Sidechains & Cross-Chain** | Set up confidential sidechains and employ cross-chain protocols to ensure private and composability across blockchains. | |
| **Temporal Data Structures** | Create chronological data structures for secure interactions. Utilize cryptographic methods for data integrity and privacy. | |
| **Homomorphic Encryption & MPC** | Apply homomorphic encryption and MPC for computations on encrypted data and interactions between state layers. | |
| **Commit-Reveal Schemes** | Introduce commit-reveal mechanisms for private transactions, revealing data only post necessary public actions. | |
| **Auditability & Verifiability** | Use on-chain tools for auditing and verifying interactions. Utilize cryptographic commitments for third-party validation. | |
| **Data Fragmentation & Sharding** | Fragment data across shards for private interactions and curtailed data exposure. Bridge shards securely with cryptography. | |
| **Ring Signatures & CoinJoin** | Incorporate ring signatures and CoinJoin protocols to mask transaction details and mix transactions collaboratively. | |
</center>
# Goal 6: Integration of DeFi Protocols with a Privacy-Preserving Framework
The primary aim of Goal 6 is to weave key DeFi protocols, such as AMMs and staking, into a user-centric environment that accentuates privacy.
This endeavor comes with inherent challenges, especially considering the heterogeneity of existing DeFi protocols, predominantly built on Ethereum.
These variations in programming languages and VMs exacerbate the quest for interoperability. Furthermore, the success and functionality of DeFi protocols is closely tied to liquidity,
which in turn is influenced by user engagement and the amount of funds locked into the system.
## <ins> Strategic Roadmap for Goal 6 </ins>
1. _** Pioneering Privacy-Centric DeFi Models: **_ Initiate the development of AMMs and staking solutions that are inherently protective of users' transactional privacy and identity.
2. _** Specialized Smart Contracts with Privacy: **_ Architect distinct smart contracts infused with privacy elements, setting the stage for secure user interactions within this new, confidential DeFi landscape.
3. _** Optimized User Interfaces: **_ Craft interfaces that resonate with user needs, simplifying the journey through the private DeFi space without compromising on security.
4. _** Tackling Interoperability: **_
* Deploy advanced bridge technologies and middleware tools to foster efficient data exchanges and guarantee operational harmony across a spectrum of programming paradigms and virtual environments.
* Design and enforce universal communication guidelines that bridge the privacy-centric DeFi entities with the larger DeFi world seamlessly.
5. _** Enhancing and Sustaining Liquidity: **_
* Unveil innovative liquidity stimuli and yield farming incentives, compelling users to infuse liquidity into the private DeFi space.
* Incorporate adaptive liquidity frameworks that continually adjust based on the evolving market demands, ensuring consistent liquidity.
* Forge robust alliances with other DeFi stalwarts, jointly maximizing liquidity stores and honing sustainable token distribution strategies.
6. _** Amplifying Community Engagement:**_ Design and roll out enticing incentive schemes to rally users behind privacy-focused AMMs and staking systems,
thereby nurturing a vibrant, privacy-advocating DeFi community.
Through the integration of these approaches, we aim to achieve Goal 6, providing users with a privacy-focused platform for engaging effortlessly in core DeFi functions such as AMMs and staking,
all while effectively overcoming the obstacles related to interoperability and liquidity concerns.
# Summary of the Architecture
In our quest to optimize privacy, we're proposing a Zero-Knowledge Virtual Machine (Zkvm) that harnesses the power of Zero-Knowledge Proofs (ZKPs).
These proofs ensure that while private state data remains undisclosed, public state transitions can still be carried out and subsequently verified by third parties.
This blend of public and private state is envisaged to be achieved through a state tree representing the public state, while the encrypted state leaves stand for the private state.
Each user's private state indicates validity through the absence of a corresponding nullifier.
A nullifier is a unique cryptographic value generated in privacy-preserving blockchain transactions to prevent double-spending,
ensuring that each private transaction is spent only once without revealing its details.
Private functions' execution mandates users to offer a proof underscoring the accurate execution of all encapsulated private calls.
For validating a singular private function call, we're leaning into the kernel-based model inspired by the ZEXE protocol.
Defined as kernel circuits, these functions validate the correct execution of each private function call.
Due to their recursive circuit structure, a succession of private function calls can be executed by calculating proofs in an iterative manner.
Execution-relevant data, like private and public call stacks and additions to the state tree, are incorporated as public inputs.
Our method integrates the verification keys for these functions within a merkle tree. Here's the innovation: a user's ZKP showcases the existence of the verification key in this tree, yet keeps the executed function concealed.
The unique function identifier can be presented as the verification key, with all contracts merkleized for hiding functionalities.
We suggest a nuanced shift from the ZEXE protocol's identity function, which crafts an identity for smart contracts delineating its behavior, access timeframes, and other functionalities.
Instead of the ZEXE protocol's structure, our approach pivots to a method anchored in the
security of a secret combined with the uniqueness from hashing with the contract address.
The underlying rationale is straightforward: the sender, equipped with a unique nonce and salt for the transaction, hashes the secret, payload, nonce, and salt.
This result is then hashed with the contract address for the final value. The hash function's unidirectional nature ensures that the input cannot be deduced easily from its output.
A specific concern, however, is the potential repetition of secret and payload values across transactions, which could jeopardize privacy.
Yet, by embedding the function's hash within the hash of the contract address, users can validate a specific function's execution without divulging the function, navigating this limitation.
Alternative routes do exist: We could employ signature schemes like ECDSA, focusing on uniqueness and authenticity, albeit at the cost of complex key management.
Fully Homomorphic Encryption (FHE) offers another pathway, enabling function execution on encrypted data, or Multi-Party Computation (MPC) which guarantees non-disclosure of function or inputs.
Yet, integrating ZKPs with either FHE or MPC presents a challenge. Combining cryptographic functions like SHA-3 and BLAKE2 can also bolster security and uniqueness.
It's imperative to entertain these alternatives, especially when hashing might not serve large input/output functions effectively or might fall short in guaranteeing uniqueness.
# Current State
Our aim is to revolutionize the privacy and security paradigms through Nescience.
As we strive to set milestones and achieve groundbreaking advancements,
our current focus narrows onto the realization of Goal 2 and Goal 3.
Our endeavors to build a powerful virtual machine tailored for Zero-Knowledge applications have led us down the path of rigorous exploration and testing.
We believe that integrating the right proof system is pivotal to our project's success, which brings us to Nova [[8](https://eprint.iacr.org/2021/370)].
In our project journey, we have opted to integrate the Nova proof system, recognizing its potential alignment with our overarching goals.
However, as part of our meticulous approach to innovation and optimization, we acknowledge the need to thoroughly examine Nova’s performance capabilities,
particularly due to its status as a pioneering and relatively unexplored proof system.
This critical evaluation entails a comprehensive process of benchmarking and comparative analysis [[9]](https://github.com/vacp2p/zk-explorations),
pitting Nova against other prominent proof systems in the field, including Halo2 [[10](https://electriccoin.co/blog/explaining-halo-2/)],
Plonky2 [[11](https://polygon.technology/blog/introducing-plonky2)], and Starky [[12](https://eprint.iacr.org/2021/582)].
This ongoing and methodical initiative is designed to ensure a fair and impartial assessment, enabling us to draw meaningful conclusions about Nova’s strengths and limitations in relation to its counterparts.
By leveraging the Poseidon recursion technique, we are poised to conduct an exhaustive performance test that delves into intricate details.
Through this testing framework, we aim to discern whether Nova possesses the potential to outshine its contemporaries in terms of efficiency, scalability, and overall performance.
The outcome of this rigorous evaluation will be pivotal in shaping our strategic decisions moving forward.
Armed with a comprehensive understanding of Nova’s performance metrics vis-à-vis other proof systems,
we can confidently chart a course that maximizes the benefits of our project’s optimization efforts.
Moreover, as we ambitiously pursue the establishment of a robust mechanism for proof creation and verification, our focus remains resolute on preserving user privacy,
incentivizing honest behaviour, and ensuring the cost-effective verification of transactions.
At the heart of this endeavor is our drive to empower users by allowing them the autonomy of generating proofs for private state updates,
thereby reducing dependencies and enhancing privacy.
We would like to actively work on providing comprehensive documentation, user-friendly tools,
and tutorials to aid users in this intricate process.
Parallelly, we're looking into decentralized verification processes, harnessing the strength of multiple external provers that cross-verify each other's work.
Our commitment is further cemented by our efforts to introduce a dynamic reward system that adjusts based on network metrics and prover performance.
This intricate balance, while challenging, aims to fortify our system against potential adversarial actions, aligning incentives, and preserving the overall integrity of the project.
# References
[1] Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System. Retrieved from https://bitcoin.org/bitcoin.pdf
[2] Sanchez, F. (2021). Cardano’s Extended UTXO accounting model. Retrived from https://iohk.io/en/blog/posts/2021/03/11/cardanos-extended-utxo-accounting-model/
[3] Morgan, D. (2020). HD Wallets Explained: From High Level to Nuts and Bolts. Retrieved from https://medium.com/mycrypto/the-journey-from-mnemonic-phrase-to-address-6c5e86e11e14
[4] Wuille, P. (012). Bitcoin Improvement Proposal (BIP) 44. Retrieved from https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki
[5] Jedusor, T. (2020). Introduction to Mimblewimble and Grin. Retrieved from https://github.com/mimblewimble/grin/blob/master/doc/intro.md
[6] Bitcoin's official wiki overview of the CoinJoin method. Retrieved from https://en.bitcoin.it/wiki/CoinJoin
[7] TornadoCash official Github page. Retrieved from https://github.com/tornadocash/tornado-classic-ui
[8] Kothapalli, A., Setty, S., Tzialla, I. (2021). Nova: Recursive Zero-Knowledge Arguments from Folding Schemes. Retrieved from https://eprint.iacr.org/2021/370
[9] ZKvm Github page. Retrieved from https://github.com/vacp2p/zk-explorations
[10] Electric Coin Company (2020). Explaining Halo 2. Retrieved from https://electriccoin.co/blog/explaining-halo-2/
[11] Polygon Labs (2022). Introducing Plonky2. Retrieved from https://polygon.technology/blog/introducing-plonky2
[12] StarkWare (2021). ethSTARK Documentation. Retrieved from https://eprint.iacr.org/2021/582