diff --git a/rlog/2023-08-28-Nescience.mdx b/rlog/2023-08-28-Nescience.mdx
new file mode 100644
index 0000000..97426fd
--- /dev/null
+++ b/rlog/2023-08-28-Nescience.mdx
@@ -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.
+
+
+
+# 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:
+
+### Rationale Behind the Dual Architecture:
+
+* **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.
+
+### Harmonizing the Two Systems:
+
+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.
+
+
+### Challenges and Solutions
+
+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.
+
+
+
+
+| | Mainstream (WASM, RISC-V) | ZK-optimized (New Instruction Set) |
+|:------------------:|:-------------------------:|:----------------------------------:|
+| Existing Tooling | YES | NO |
+| Blockchain-focused | NO | YES |
+| Performant | DEPENDS | YES |
+
+
+
+### Optimization Concerns for WASM and RISC-V:
+
+* _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.
+
+
+### Emerging ZKP Optimized Systems Considerations:
+
+* _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.
+
+
+### Strategies for Integration:
+
+* _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.
+
+
+
+| 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. | |
+
+
+
+[^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.
+
+ Recursion Handling
+
+* _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.
+
+ Depth management
+
+* _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:
+
+
+
+| **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. | |
+
+
+
+# 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.
+
+## Strategic Roadmap for Goal 6
+
+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
+