github/vac.dev
1
1
Fork 0
mirror of https://github.com/vacp2p/vac.dev.git synced 2026-01-09 06:38:07 -05:00
Code Issues Packages Projects Releases Wiki Activity

Final version of Nescience

Browse Source
This commit is contained in:
EL LAZ Mohamad
2023-08-30 16:40:54 +02:00
parent 99e513d09a
commit 6df69898bb
1 changed files with 124 additions and 51 deletions
Download Patch File Download Diff File Expand all files Collapse all files

175
rlog/2023-08-28-Nescience.mdx
View File

@@ -17,34 +17,61 @@ 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.
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.
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 execution of the public functions inside the virtual machine can be delegated to an external incentivised prover.
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 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.
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.
# 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 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, notably utilized in Bitcoin, generates novel 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.
The UTXO model, notably utilized in Bitcoin, generates novel 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.
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.
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.
* **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.
* **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>
@@ -52,39 +79,52 @@ Here's a breakdown and a potential strategy for harmonizing these models:
* 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.
* _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.
* _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.
* 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, 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.
* _Deterministic Wallets:_ Use Hierarchical Deterministic (HD) wallets, 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.
* Role: Use cryptographic commitments to commit to the state of both models. This can help in efficiently
validating cross-model transactions.
* _Merkle-Patricia Trees:_ Utilized in Ethereum, this can help maintain the account-based state, ensuring efficient and cryptographically secure storage.
* _Merkle-Patricia Trees:_ Utilized in Ethereum, this can help maintain the account-based state,
ensuring efficient and cryptographically secure storage.
* _Mimblewimble-style Aggregation:_ For UTXOs, techniques similar to those used in Mimblewimble can be used to aggregate transactions, keeping the state compact and enhancing privacy.
* _Mimblewimble-style Aggregation:_ 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.
* 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:_ As seen in Bitcoin, multiple users can combine their UTXO transactions into one, enhancing privacy.
* _CoinJoin Technique:_ As seen in Bitcoin, multiple users can combine their UTXO transactions into one,
enhancing privacy.
* _Tornado Cash Principle:_ For account-based systems wanting to achieve privacy, methods like those used in Tornado Cash can be implemented, providing zk-SNARKs-based private transactions.
* _Tornado Cash Principle:_ 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.
* 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.
* _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.
@@ -95,11 +135,14 @@ Here's a breakdown and a potential strategy for harmonizing these models:
* 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.
* 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.
* 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.
* Checkpointing: Introduce periodic checkpoints where the two systems' states are verified and harmonized.
This can ensure consistency without constant synchronization.
2. Double Spending
@@ -107,7 +150,8 @@ Here's a breakdown and a potential strategy for harmonizing these models:
* 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.
* 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.
@@ -115,21 +159,27 @@ Here's a breakdown and a potential strategy for harmonizing these models:
* 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.
* 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.
* 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.
* 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.
* 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.
* 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.
* 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:
@@ -142,7 +192,8 @@ Here's a breakdown and a potential strategy for harmonizing these models:
* 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.
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 | |
@@ -157,43 +208,60 @@ By addressing these challenges head-on with a detailed and systematic approach,
# 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.
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.
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.
_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).
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 be- tween established options and innovative solutions in pursuit of an architecture harmoniously amalgamating privacy, security, and performance.
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:
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.
* _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.
* _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.
* 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.
* 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.
* 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.
* 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.
* 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>
@@ -208,18 +276,23 @@ The ambition to build a powerful virtual machine tailored to zero-knowledge (ZK)
### <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.
* _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.
* _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.
* _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.
* _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.
* _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.