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

Update 2024-08-23-state-separation.mdx

Browse Source 
Formatting errors addressed as discussed with Moudy
This commit is contained in:
0xbathang
2024-08-26 13:05:25 +02:00
committed by GitHub
parent 2b0bdca7e2
commit 510c8bb0ee
1 changed files with 101 additions and 100 deletions
Download Patch File Download Diff File Expand all files Collapse all files

201
rlog/2024-08-23-state-separation.mdx
View File

@@ -1,5 +1,5 @@
---
title: 'Nescience - A User-Centric State Separation Architecture'
title: 'Nescience: A User-Centric State-Separation Architecture'
date: 2024-08-23 12:00:00
authors: moudy
published: true
@@ -11,7 +11,7 @@ toc_min_heading_level: 2
toc_max_heading_level: 5
---
"Nescience: A user-centric state-separation architecture."
Nescience: A user-centric state-separation architecture.
<!--truncate-->
@@ -21,14 +21,14 @@ _Disclaimer: This content is a work in progress. Some components may be updated,
In blockchain applications, privacy settings are typically predefined by developers, leaving users with limited control. This traditional,
one-size-fits-all approach often leads to inefficiencies and potential privacy concerns as it fails to cater to the diverse needs of individual users.
The Nescience state separation architecture (NSSA) aims to address these issues by shifting privacy control from developers to users. NSSA introduces a flexible,
The Nescience state-separation architecture (NSSA) aims to address these issues by shifting privacy control from developers to users. NSSA introduces a flexible,
user-centric approach that allows for customized privacy settings to better meet individual needs. This blog post will delve into the details of NSSA,
including its different execution types, cryptographic foundations, and unique challenges.
### Introducing NSSA: A user-centric approach
## Introducing NSSA: A user-centric approach
NSSA gives users control over their privacy settings by introducing _shielded_ (which create a layer of privacy for the outputs and only the necessary details are shared)
and _deshielded_ (which reveal private details making them publicly visible) execution types in addition to the traditional public and private modes. This flexibility allows
NSSA gives users control over their privacy settings by introducing _shielded_ (which creates a layer of privacy for the outputs, and only the necessary details are shared)
and _deshielded_ (which reveal private details, making them publicly visible) execution types in addition to the traditional public and private modes. This flexibility allows
users to customize their privacy settings to match their unique needs, whether they require high levels of confidentiality or more transparency. In NSSA, the system is divided
into two states: public and private. The public state uses an account-based model while the private state employs a UTXO-based (unspent transaction output) model. Private executions within NSSA utilize
UTXO exchanges, ensuring that transaction details remain confidential. The sequencer verifies these exchanges without accessing specific details, enhancing privacy by unlinking
@@ -42,7 +42,7 @@ through various solutions such as ZKPs, which ensure transaction validity withou
public verification. By allowing users to customize their privacy settings, NSSA enhances user experience and promotes wider adoption of private execution platforms. As we move towards
a future where user-empowered privacy control is crucial, NSSA provides a flexible and user-centric solution that meets the diverse needs of blockchain users.
### Why NSSA differs from other hybrid execution platforms
## Why NSSA differs from other hybrid execution platforms
In many existing hybrid execution platforms, privacy settings are predefined by developers, often applying a one-size-fits-all approach that does not accommodate the
diverse privacy needs of users. These platforms blend public and private states, but control over privacy remains with the application developers.
@@ -83,14 +83,14 @@ This flexibility sets NSSA apart as a more adaptable and user-centric platform,
By combining selective privacy with a flexible execution model, NSSA offers a more robust and adaptable framework for decentralized applications,
ensuring that users maintain control over their privacy while benefiting from the security and efficiency of blockchain technology.
### How Nescience State Separation Architecture can be used
## How Nescience state-separation architecture can be used
NSSA offers a flexible, privacy-preserving add-on that can be applied to existing dapps.
One of the emerging trends in the blockchain space is that each dapp is expected to have its own rollup for efficiency, and it is estimated that Ethereum could see
the deployment of different rollups in the near future. A key question arises: how many of these rollups will incorporate privacy? For dapp developers who want to offer flexible,
user-centric privacy features, NSSA provides a solution through selective privacy.
**Use Case: Adding privacy to existing dapps**
### Use case: Adding privacy to existing dapps
Consider a dapp running on a transparent network that offers no inherent privacy to its users. Converting this dapp to a privacy-preserving architecture from scratch would
require significant effort, restructuring, and a deep understanding of cryptographic frameworks. However, with NSSA, the dapp does not need to undergo extensive changes.
@@ -100,7 +100,7 @@ This allows the dapp to retain its existing functionality while providing users
With NSSA, the privacy settings are flexible, meaning users can tailor their level of privacy according to their individual needs while the dapp operates on its current infrastructure.
This contrasts sharply with the typical approach, where dapps are either entirely transparent or fully private, with no flexibility for users to select their own privacy preferences.
**Key Advantage: Decoupling from the host chain**
### Key advantage: Decoupling from the host chain
A key feature of NSSA is that it operates independently of the privacy characteristics of the host blockchain. Whether the host chain is fully transparent or fully private,
the Nescience state-separation architecture can be deployed on top of it, offering users the ability to choose their own privacy settings.
@@ -109,7 +109,7 @@ This decoupling from the host chain’s inherent privacy model is critical as it
In **fully private chains**, NSSA allows users to selectively reveal transaction details when compliance with regulations or other requirements is necessary.
In **fully transparent chains**, NSSA allows users to maintain privacy for specific transactions, offering flexibility that would not otherwise be possible.
**Conclusion**
### Conclusion
NSSA provides a powerful tool for dapp developers who want to offer **selective privacy** to their users without the need for a complete overhaul of their existing systems.
By deploying NSSA as an add-on, dapps can give users the ability to choose their own privacy settings whether they are operating on
@@ -132,13 +132,11 @@ These topics will provide a comprehensive understanding of how NSSA enables flex
## 1. Architecture's components
---
NSSA introduces an advanced prototype execution framework designed to enhance privacy and security in blockchain applications.
This framework integrates several essential components: the public state, private state, zkVM, various execution types, Nescience users, and smart contracts.
### a) Public state
---
The public state in the NSSA is a fundamental component designed to hold all publicly accessible information within
the blockchain network. This state is organized as a single Merkle tree structure, a sophisticated data structure that ensures efficient and secure data verification.
The public state includes critical information such as user balances and the public storage data of smart contracts.
@@ -195,9 +193,8 @@ In summary, the private state in NSSA is meticulously designed to provide users
By utilizing a UTXO-based model, individual Merkle trees, ZKPs, and a dual-storage system, NSSA achieves a balance between confidentiality and verifiability,
making it a robust solution for managing private blockchain transactions.
### c) zkVM (Zero-knowledge virtual machine)
### c) ZkVM (zero-knowledge virtual machine)
---
The zkVM is a pivotal component in NSSA, designed to uphold the highest standards
of privacy and security in blockchain transactions. Its primary function is to generate and aggregate ZKPs, enabling users to validate the
correctness of their transactions without disclosing any underlying details. This capability is crucial for maintaining the confidentiality and integrity of sensitive
@@ -227,7 +224,6 @@ By ensuring that all transactions are validated without revealing sensitive info
### d) Execution types in NSSA
---
NSSA incorporates multiple execution types to cater to varying levels of privacy and security requirements.
These execution types—public, private, shielded, and deshielded—are designed to provide users with flexible options for managing their transactions based on their specific privacy needs.
@@ -345,7 +341,7 @@ They can be ideal for managing decentralized autonomous organizations (DAOs), wh
By integrating smart contracts, NSSA offers a highly versatile, secure, and transparent framework that can support a wide range of applications
across various industries, from finance to governance, supply chains, and more.
## 2. General Execution Overview
## 2. General execution overview
---
This section explains the execution process within NSSA, providing an overview of how it works from start to finish.
It outlines the steps involved in each execution type, guiding the reader through the entire process from user interaction to completion.
@@ -358,10 +354,10 @@ to their specific requirements, whether it be full transparency or complete conf
![general](/img/general.png)
#### User actions:
### User actions
---
**Step 1**: **Smart contract selection and input creation**
- **Smart contract xelection**: The user selects a smart contract they wish to invoke.
- **Smart contract selection**: The user selects a smart contract they wish to invoke.
- **Input creation**: The user creates a set of inputs required for the invocation by reading the necessary data from both the public and private states. This includes:
- Public data such as current account balances, public keys, and smart contract states.
- Private data such as private account balances and UTXOs.
@@ -372,11 +368,11 @@ to their specific requirements, whether it be full transparency or complete conf
- **Private execution**: Used when transaction details need to be confidential.
- **Shielded execution**: Hides the receiver's identity.
- **Deshielded execution**: Hides the sender's identity.
- **zkVM requirement**: If the execution involves private, shielded, or deshielded types, the user must call the zkVM to handle these confidential transactions.
- **ZkVM requirement**: If the execution involves private, shielded, or deshielded types, the user must call the zkVM to handle these confidential transactions.
For purely public executions, the zkVM is not needed, and the user can directly transmit the transaction code to the sequencer.
**Step 3**: **Calling zkVM for proof generation**
- **zkVM compilation**: The user calls the zkVM to compile the smart contract with both public and private inputs.
- **ZkVM compilation**: The user calls the zkVM to compile the smart contract with both public and private inputs.
- **Kernel circuit proofs**: The zkVM generates individual proofs for each execution type through kernel circuits.
- **Proof aggregation**: The zkVM aggregates these individual proofs into a single comprehensive proof, combining both private and public inputs.
@@ -391,8 +387,8 @@ For purely public executions, the zkVM is not needed, and the user can directly
After completing these steps, the user's part of the execution is done, and the sequencer takes over the process.
#### Sequencer actions:
### Sequencer actions
---
**Step 5**: **Proof verification**
- **Proof and data reception**: The sequencer receives the proof and public inputs from the user.
- **Verification process**:
@@ -431,7 +427,7 @@ Below, we outline the execution process of the four different execution types wi
## 3. Execution processes and UTXO management
---
In Nescience state separation architecture, UTXOs are key components for managing private data and assets. They serve as private entities that hold both storage and assets,
In Nescience state-separation architecture, UTXOs are key components for managing private data and assets. They serve as private entities that hold both storage and assets,
facilitating secure and confidential transactions. UTXOs are utilized in three of the four execution types within NSSA: private, shielded,
and deshielded executions. This section explores the lifecycle of UTXOs, detailing their generation, transfer, encryption, and eventual consumption within the private execution framework.
@@ -441,39 +437,39 @@ A Nescience UTXO is a critical and versatile component of the private state in t
It carries essential information that ensures its proper functionality within private execution, such as the owner, value, private storage slot, non-fungibles,
and other cryptographic components. Below is a detailed breakdown of each component and its role in maintaining the integrity, security, and privacy of the system:
* Owner
The owner component represents the public key of the entity who controls the UTXO. Only the owner can spend this UTXO, ensuring its security and privacy through public key cryptography.
* **Owner:**
The owner component represents the public key of the entity that controls the UTXO. Only the owner can spend this UTXO, ensuring its security and privacy through public key cryptography.
This means that the UTXO remains secure as only the rightful owner, using their private key, can generate valid signatures to authorize the transaction. For example,
if Alice owns a UTXO linked to her public key, she must sign any transaction to spend it using her private key. This cryptographic protection ensures that only Alice can authorize
spending the UTXO and transfer it to someone else, such as Bob.
* Value
* **Value:**
The value in a UTXO represents the balance or asset contained within it. This could be cryptocurrency, tokens, or other digital assets. The value ensures accurate accounting,
preventing double spending and maintaining the overall integrity of the system. For instance, if Alice's UTXO has a value of 10 tokens, this represents her ownership of that amount
within the network, and when spent, this value will be deducted from her UTXO and transferred accordingly.
* Private storage slot
* **Private storage slot:**
The private storage slot is an arbitrary and flexible storage space within the UTXO for Nescience applications. It allows users and smart contracts to store additional private data
that is only accessible by the owner. This could be used to hold metadata, smart contract states, or user-specific information. For example, if a smart contract is holding private user data,
this information is securely stored in the private storage slot and can only be accessed or modified by the owner, ensuring privacy and security.
* Non-fungibles
* **Non-fungibles:**
Non-fungibles within the UTXO represent unique assets, such as NFTs (Non-Fungible Tokens). Each non-fungible asset is assigned a unique serial number or identifier within the UTXO,
ensuring its distinctiveness and traceability. For example, if Alice owns a digital artwork represented as an NFT, the non-fungible component of the UTXO will store the unique identifier
for this NFT, preventing duplication or forgery of the digital asset.
* Random commitment key
* **Random commitment key:**
The random commitment key (RCK) is a randomly generated number used to create a cryptographic commitment to the contents of the UTXO. This commitment ensures the integrity of the data
without revealing any private information. By generating a random key for the commitment, the system ensures that even if someone observes the commitment, they cannot infer any details
about the underlying UTXO. For example, RCK helps maintain confidentiality in the system while still allowing the verification of transactions.
* Nullifier key
* **Nullifier key:**
The Nullifier key is another randomly generated number, used to ensure that a UTXO is only spent once. When a UTXO is spent, its nullifier key is recorded in a nullifier set to prevent
double spending. This key guarantees that once a UTXO is spent, it cannot be reused in another transaction, effectively nullifying it from future use. This mechanism is crucial for
maintaining the security and integrity of the system, as it ensures that no UTXO can be spent more than once.
### b) UTXO lifecycle: from generation to consumption
### b) UTXO lifecycle: From generation to consumption
---
UTXOs in NSSA are created when a transaction outputs a specific value, asset, or data intended for future use. Once generated, these UTXOs become private entities
owned by specific users, containing sensitive information such as balances, private data, or unique assets like NFTs.
@@ -496,12 +492,12 @@ within the network.
At this point, it's crucial to introduce two key components that will play a significant role in the next section: the ephemeral key and the nillifier.
* Ephemeral key: The ephemeral key is embedded in the transaction message and plays a crucial role in maintaining privacy. It is used by the sender, alongside the receiver's public key,
* **Ephemeral key:** The ephemeral key is embedded in the transaction message and plays a crucial role in maintaining privacy. It is used by the sender, alongside the receiver's public key,
in a key agreement protocol to derive a shared secret. This shared secret is then employed to encrypt the transaction details, ensuring that only those with the receiver's viewing key can
decrypt the transaction. By using the ephemeral key, the receiver can regenerate the shared secret, granting access to the transaction's contents. The sender generates the ephemeral key
using their spending key and the UTXO's nullifier, reinforcing the security of the transaction. (more details in [key management and addresses section](#key))
* Nullifier: A nullifier is a unique value tied to a specific UTXO, ensuring that it has not been spent before. Its uniqueness is essential, as a nullifier must never correspond to more
* **Nullifier:** A nullifier is a unique value tied to a specific UTXO, ensuring that it has not been spent before. Its uniqueness is essential, as a nullifier must never correspond to more
than one UTXO—otherwise, even if both UTXOs are valid, only one could be spent. This would undermine the integrity of the system. To spend a UTXO, a proof must be provided showing that
the nullifier does not already exist in the Nullifier Tree. Once the transaction is confirmed and included in the blockchain, the nullifier is added to the Nullifier Tree, preventing any
future reuse of the same UTXO. A UTXO's nullifier is generated by combining the receiver's nullifier key with the transaction note's commitment, further ensuring its distinctiveness
@@ -513,27 +509,27 @@ In private executions within NSSA, transactions are handled ensuring maximum pri
This approach is particularly useful for confidential payments, where the identities of the sender and receiver, as well as the transaction amounts, must remain hidden.
The process is powered by ZKPs, ensuring that only the involved parties have access to the transaction details while maintaining the integrity of the network.
* Stages of private execution: Private executions operate in two key stages: UTXO consumption and UTXO creation. In the first stage, UTXOs from the private state are used
* **Stages of private execution**: Private executions operate in two key stages: UTXO consumption and UTXO creation. In the first stage, UTXOs from the private state are used
as inputs for the transaction. In the second stage, new UTXOs are generated as outputs and stored back in the private state. Throughout this process, the details of the
transaction are kept confidential and only shared between the sender and receiver.
* Private transaction workflow (transaction initialization): The user initiates a private transaction by selecting the input UTXOs that will be spent and determining the
* **Private transaction workflow (transaction initialization)**: The user initiates a private transaction by selecting the input UTXOs that will be spent and determining the
output UTXOs to be created. This involves specifying the amounts to be transferred and the recipient’s private address (a divestified address that hides the recipient's public
address from the network). The nullifier key and random number for commitments (RCK) are also generated at this stage to define how these UTXOs can be spent or nullified in the
future by the receiver.
* Proof generation and verification: Next, the zkVM generates a ZKP to validate the transaction. This proof includes both a membership proof for the input UTXOs,
* **Proof generation and verification**: Next, the zkVM generates a ZKP to validate the transaction. This proof includes both a membership proof for the input UTXOs,
confirming their presence in the hashed UTXO tree, and a non-membership proof to ensure that the input UTXOs have not already been spent (i.e., they are not in the nullifier tree).
The proof also confirms that the total input value matches the total output value, ensuring no discrepancies. The user then submits the proof, along with the necessary metadata, to the sequencer.
* Shared secret and encryption: To maintain confidentiality, the sender uses the receiver’s divestified address to generate an ephemeral public key.
* **Shared secret and encryption**: To maintain confidentiality, the sender uses the receiver’s divestified address to generate an ephemeral public key.
This allows the creation of a shared secret between the sender and receiver. Using a key derivation function, a symmetric encryption key is generated from the shared secret.
The input and output UTXOs are then encrypted using this symmetric key, ensuring that only the intended recipient can decrypt the data.
* Broadcasting the transaction: The user broadcasts the encrypted UTXOs to the network, along with a commitment to the output UTXOs using Pedersen hashes.
* **Broadcasting the transaction**: The user broadcasts the encrypted UTXOs to the network, along with a commitment to the output UTXOs using Pedersen hashes.
These committed UTXOs are sent to the sequencer, which updates the hashed UTXO tree without knowing the transaction details.
* Decryption by the receiver: After the broadcast, the receiver attempts to decrypt the broadcast UTXOs using their symmetric key, derived from the ephemeral public key.
* **Decryption by the receiver**: After the broadcast, the receiver attempts to decrypt the broadcast UTXOs using their symmetric key, derived from the ephemeral public key.
If the receiver successfully decrypts a UTXO, it confirms ownership of that UTXO. The receiver then computes the nullifier for the UTXO and verifies its presence in the hashed
UTXO tree and its absence from the nullifier tree, ensuring it has not been spent. Finally, the new UTXO is added to the receiver’s locally stored UTXO tree for future transactions.
@@ -548,29 +544,29 @@ This model is suitable for scenarios where the initial step, such as a public tr
need to remain confidential. One common use case is asset conversion—where a public token is converted into a private token. The conversion is visible on the public ledger,
but subsequent transactions remain private.
#### a) How shielded executions work
##### a) How shielded executions work
Shielded executions operate in two distinct stages: first, there is a modification of the public state, and then new UTXOs are created and stored in the private state.
Importantly, shielded executions do not consume UTXOs but instead mint them, as new UTXOs are created to reflect the changes in the private state. This structure demands
ZKPs to ensure that the newly minted UTXOs are consistent with the modifications in the public state. Here’s a step-by-step breakdown of how the shielded
execution process unfolds:
1. Transaction initiation: The user initiates a transaction that modifies the public state, such as converting a public token to a private token.
1. **Transaction initiation:** The user initiates a transaction that modifies the public state, such as converting a public token to a private token.
The transaction alters the public state (e.g., balances or smart contract storage) while simultaneously preparing to mint new UTXOs in the private state.
2. Generating UTXOs: After modifying the public state, the system mints new UTXOs in the private state. These UTXOs must be securely created, ensuring their integrity
2. **Generating UTXOs:** After modifying the public state, the system mints new UTXOs in the private state. These UTXOs must be securely created, ensuring their integrity
and consistency with the initial public state modification. A ZKP is generated by the user to prove that these new UTXOs align with the changes made in the public state.
3. Key setup for privacy: The sender retrieves the receiver's address and uses it to create a shared secret through an ephemeral public key. This shared secret is then used
3. **Key setup for privacy**: The sender retrieves the receiver's address and uses it to create a shared secret through an ephemeral public key. This shared secret is then used
to derive a symmetric key, which encrypts the output UTXOs. This encryption ensures that only the intended receiver can decrypt and access the UTXOs.
4. Broadcasting and verifying UTXOs: After encrypting the UTXOs, the sender broadcasts them to the network. The new hashed UTXOs are sent to the sequencer,
4. **Broadcasting and verifying UTXOs**: After encrypting the UTXOs, the sender broadcasts them to the network. The new hashed UTXOs are sent to the sequencer,
which verifies the validity of the UTXOs and attaches them to the hashed UTXO tree within the private state. The public inputs for the ZKP circuits consist of the
pedersen-hashed UTXOs and the modifications in the public state.
Pedersen-hashed UTXOs and the modifications in the public state.
5. Receiver's role: Once the UTXOs are broadcast, the receiver attempts to decrypt each UTXO using the symmetric key derived from the shared secret. If the decryption is successful,
5. **Receiver's role**: Once the UTXOs are broadcast, the receiver attempts to decrypt each UTXO using the symmetric key derived from the shared secret. If the decryption is successful,
the UTXO belongs to the receiver. The receiver then verifies the UTXO’s validity by checking its inclusion in the hashed UTXO tree and ensuring that its nullifier has not yet been used.
6. Nullifier check and integration: To prevent double spending, the receiver computes the nullifier for the received UTXO and verifies that it is not already present in the nullifier tree.
6. **Nullifier check and integration**: To prevent double spending, the receiver computes the nullifier for the received UTXO and verifies that it is not already present in the nullifier tree.
Once verified, the receiver adds the UTXO to their locally stored UTXO tree for future use in private transactions.
@@ -578,11 +574,11 @@ While shielded executions offer privacy, certain information is still exposed to
the sender can create empty UTXOs—UTXOs that don’t belong to anyone but are included in the transaction to obfuscate the true details of the transaction.
Though this approach increases the size of the data, it adds a layer of privacy by complicating the identification of meaningful transactions.
#### b) Summary of shielded execution flow
* Stage 1 (Public modification): The user modifies public state data, such as converting tokens from public to private. This stage is visible to the public.
* Stage 2 (UTXO minting and privacy): New UTXOs are minted in the private state, encrypted, and broadcast to the network. The transaction remains private from this point forward,
##### b) Summary of shielded execution flow
* **Stage 1 (public modification):** The user modifies public state data, such as converting tokens from public to private. This stage is visible to the public.
* **Stage 2 (UTXO minting and privacy):** New UTXOs are minted in the private state, encrypted, and broadcast to the network. The transaction remains private from this point forward,
secured by ZKPs and cryptographic keys.
* Receiver’s role: The receiver decrypts the UTXOs and verifies their validity, ensuring the UTXOs are not double spent and are ready for future transactions.
* **Receiver’s role:** The receiver decrypts the UTXOs and verifies their validity, ensuring the UTXOs are not double spent and are ready for future transactions.
In summary, shielded executions enable a hybrid privacy model in Nescience, balancing public transparency and private confidentiality. They are well-suited for
transactions requiring initial public visibility, such as asset conversions, while ensuring that subsequent actions remain secure and private within the network.
@@ -594,19 +590,19 @@ information in a controlled and verifiable manner. This type of execution allows
the security and privacy of critical details through cryptographic techniques like ZKPs. Deshielded executions are particularly valuable for use cases
such as regulatory compliance reporting, where specific transaction details must be revealed to meet legal requirements, while other sensitive transactions remain private.
#### a) Stages of deshielded executions
##### a) Stages of deshielded executions
* Stage 1 (UTXO consumption): The process begins in the private state, where UTXOs are consumed as inputs for the transaction. This involves gathering all necessary
* **Stage 1 (UTXO consumption):** The process begins in the private state, where UTXOs are consumed as inputs for the transaction. This involves gathering all necessary
UTXOs that contain the assets or balances to be made public, as well as any associated private data stored in memory slots.
* Stage 2 (Public state modification): After the UTXOs are consumed, the transaction details are made public by modifying the public state. This update includes changes
* **Stage 2 (public state modification):** After the UTXOs are consumed, the transaction details are made public by modifying the public state. This update includes changes
to the public balances, storage data, and any necessary public records. While the public state is updated, the sender’s identity and other sensitive information remain hidden,
thanks to the privacy-preserving properties of ZKPs.
This model ensures that private data can be selectively revealed when needed, offering both flexibility and transparency. It is particularly useful for scenarios requiring
auditing or compliance reporting, where specific details must be made publicly verifiable without exposing the entire history or contents of private transactions.
#### b) How deshielded executions work
##### b) How deshielded executions work
The deshielded execution process starts when a user initiates a transaction using private UTXOs. The Nescience zkVM is called to generate a ZKP,
which validates the transaction without revealing sensitive details such as the sender's identity or the specifics of the Nescience application being executed.
@@ -614,21 +610,21 @@ During the transaction, the UTXOs from the private state are consumed, meaning t
Instead of generating new UTXOs, the transaction modifies the public state, updating the necessary balances or memory slots related to the transaction.
Here’s a step-by-step breakdown of how the deshielded execution process unfolds:
1. Get receiver's public address: The sender first identifies the public address of the receiver, to which the information or assets will be made public.
1. **Get receiver's public address:** The sender first identifies the public address of the receiver, to which the information or assets will be made public.
2. Determine input UTXOs and public state modifications: The sender gathers all the input UTXOs needed for the transaction and determines the public state modifications
2. **Determine input UTXOs and public state modifications:** The sender gathers all the input UTXOs needed for the transaction and determines the public state modifications
necessary for the Nescience applications and token transfers involved.
3. Calculate nullifiers: Nullifiers are generated for each input UTXO, ensuring that these UTXOs cannot be reused or double spent. The nullifiers are derived from the
3. **Calculate nullifiers:** Nullifiers are generated for each input UTXO, ensuring that these UTXOs cannot be reused or double spent. The nullifiers are derived from the
corresponding UTXO commitments.
4. Call zkVM with deshielded circuits: The sender invokes the zkVM with deshielded kernel circuits, which generates the proof. The proof ensures that all input UTXOs
4. **Call zkVM with deshielded circuits:** The sender invokes the zkVM with deshielded kernel circuits, which generates the proof. The proof ensures that all input UTXOs
are valid by verifying their membership in the UTXO tree and their non-membership in the nullifier tree, ensuring they haven’t been spent.
5. Generate and submit proof: The zkVM generates a ZKP that verifies the correctness of the transaction without revealing private details.
5. **Generate and submit proof:** The zkVM generates a ZKP that verifies the correctness of the transaction without revealing private details.
The proof includes the nullifiers and the planned modifications to the public state.
6. Send proof to sequencer: The sender then sends the proof and any relevant public information to the sequencer. The sequencer is responsible for verifying the proof,
6. **Send proof to sequencer:** The sender then sends the proof and any relevant public information to the sequencer. The sequencer is responsible for verifying the proof,
updating the public state accordingly, and adding the nullifiers to the nullifier tree.
Once the proof and public information have been broadcast to the network, the receiver does not need to take any further action.
@@ -638,15 +634,15 @@ This allows participants in the public state to extract information about the tr
While the receiver's identity is revealed, the sender's identity and sensitive transaction details remain hidden, thanks to the use of ZKPs.
This makes deshielded executions ideal for cases where transparency is needed, but complete privacy is still a priority for certain elements of the transaction.
### **Summary of UTXOs consumption in NSSA**
### Summary of UTXO consumption in NSSA
---
In NSSA, consuming UTXOs is a critical step in maintaining the security and integrity of the blockchain by preventing double spending.
When a UTXO is consumed, it is used as an input in a transaction, effectively marking it as spent. This ensures that the UTXO cannot be reused, preserving the integrity of the blockchain.
1. The Process of consuming UTXOs: The process of consuming a UTXO begins when a user selects a UTXO from their private state. The user verifies the UTXO’s existence and
1. **The process of consuming UTXOs:** The process of consuming a UTXO begins when a user selects a UTXO from their private state. The user verifies the UTXO’s existence and
ownership using their viewing key, ensuring that they are the legitimate owner of the UTXO. Once verified, the user generates two key cryptographic proofs:
* Membership proof: This proof confirms that the UTXO exists within the hashed UTXO tree, ensuring its validity within the system.
* Non-membership proof: This proof ensures that the UTXO has not been previously consumed by checking its absence in the nullifier tree, which tracks spent UTXOs.
* **Membership proof:** This proof confirms that the UTXO exists within the hashed UTXO tree, ensuring its validity within the system.
* **Non-membership proof:** This proof ensures that the UTXO has not been previously consumed by checking its absence in the nullifier tree, which tracks spent UTXOs.
To mark the UTXO as spent, a **nullifier** is generated. This nullifier is a unique cryptographic hash derived from the UTXO, which is then added to the nullifier tree in the public state.
Adding the nullifier to the tree prevents the UTXO from being reused in future transactions, thus preventing double spending.
@@ -654,12 +650,12 @@ Adding the nullifier to the tree prevents the UTXO from being reused in future t
After generating the membership and non-membership proofs, the user compiles the transaction using the zkVM. The zkVM is responsible for generating the necessary ZKPs,
which validate the transaction without revealing sensitive details. The compiled transaction, along with the proofs, is then submitted to the sequencer for verification.
2. The Role of the sequencer: Once the transaction is submitted, the sequencer verifies the ZKPs to confirm that the transaction is valid. If the proofs are verified
2. **The role of the sequencer:** Once the transaction is submitted, the sequencer verifies the ZKPs to confirm that the transaction is valid. If the proofs are verified
successfully, the sequencer updates both the private and public states to reflect the transaction. This includes updating the nullifier tree with the newly generated nullifier,
ensuring that the UTXO is marked as spent and cannot be reused.
#### Example: Alice sending tokens to Bob
---
Consider an example where Alice wants to send 5 Nescience tokens to Bob using a private execution. Alice selects a UTXO from her private state that contains 5 Nescience tokens.
She generates the necessary membership and non-membership proofs, ensuring that her UTXO exists in the system and has not been previously spent. Alice then creates a nullifier by
hashing the UTXO and compiles the transaction with the zkVM.
@@ -668,7 +664,7 @@ Once Alice submits the transaction, the sequencer verifies the proofs and update
This ensures that Alice’s UTXO is marked as spent and cannot be used again, while Bob receives the 5 tokens.
#### The importance of nullifiers
---
Nullifiers are a key mechanism in preventing double spending. By marking consumed UTXOs as spent and tracking them in the nullifier tree, NSSA ensures that
once a UTXO is used in a transaction, it cannot be reused in any future transactions. This process is fundamental to maintaining the integrity and security of the blockchain,
as it guarantees that assets are only spent once and prevents potential attacks on the system.
@@ -677,7 +673,7 @@ In conclusion, the process of consuming UTXOs in NSSA combines cryptographic pro
are secure, confidential, and free from the risks of double spending.
# C. Cryptographic Primitives in NSSA
# C. Cryptographic primitives in NSSA
In the NSSA, cryptographic primitives are the foundational elements that ensure the security, privacy, and efficiency of the state separation model.
These cryptographic tools enable private transactions, secure data management, and robust verification processes across both public and private states.
@@ -698,7 +694,8 @@ form the backbone of Nescience’s security architecture, ensuring that users ca
In the following sections, we will explore each of these cryptographic components in detail, beginning with the role of hash functions.
## a) Hash functions in Nescience
## a) Hash functions in Nescience
---
Hash functions are a foundational element of Nescience’s cryptographic framework, serving multiple critical roles that ensure the security, privacy, and efficiency of the system.
One of the primary uses of hash functions in Nescience is to conceal sensitive details of UTXOs by converting them into fixed-size hashes. This process allows UTXO details
to remain private, ensuring that sensitive information is not directly exposed on the blockchain, while still enabling their existence and integrity to be verified. Hashing
@@ -722,9 +719,9 @@ The primary advantage of using hash functions in Nescience is their ability to e
of their validity. Furthermore, by integrating hash functions into Merkle trees, the blockchain data becomes tamper-proof, enabling quick and efficient verification
processes that uphold the system’s security and privacy standards.
### Use case: how to use the Pedersen hash to create the UTXO commitment
### Use case: How to use the Pedersen hash to create the UTXO commitment
---
As mentioned in the [UTXOs in Private Exections section](#pe), the user broadcasts the encrypted UTXOs to the network, along with a commitment to the output UTXOs
As mentioned in the [UTXOs in private exections section](#pe), the user broadcasts the encrypted UTXOs to the network, along with a commitment to the output UTXOs
using **Pedersen hashes**. The Pedersen hash is used to create the UTXO commitment. The Pedersen hash is a homomorphic commitment scheme that allows secure commitments
while maintaining privacy and enabling proofs of correctness in transactions. The commitment formula is as follows:
@@ -736,9 +733,10 @@ and computationally infeasible to reverse or manipulate without knowing the orig
by blinding the UTXO's contents, ensuring that the commitment doesn't leak any information about the underlying data.
**Importance of homomorphic commitments**
It is essential to use a homomorphic commitment like the Pedersen commitment for UTXOs because it allows for the verification of important properties in transactions,
such as ensuring that the total input value of a transaction equals the total output value. This balance is crucial for preventing unauthorized creation of funds or d
iscrepancies in transactions. A homomorphic commitment enables these proofs because of its additive properties. Specifically, the exponents in the commitment formula are additive,
such as ensuring that the total input value of a transaction equals the total output value. This balance is crucial for preventing the unauthorized creation of funds or d
discrepancies in transactions. A homomorphic commitment enables these proofs because of its additive properties. Specifically, the exponents in the commitment formula are additive,
meaning that commitments can be combined and verified without revealing the individual components. For instance, if you have two UTXOs with commitments $C(UTXO_1,RCK_1)$
and $C(UTXO_2,RCK_2)$, you can combine them and verify that the resulting commitment is valid without exposing the actual amounts.
@@ -746,24 +744,26 @@ This capability is leveraged through a modified version of the Schnorr protocol,
The Schnorr protocol allows users to prove, without revealing the actual values, that the sum of inputs equals the sum of outputs, ensuring that no funds are created or lost in the transaction.
**Limitations of standard cryptographic hashes**
Standard cryptographic hash functions, such as SHA-256, are not suitable for this purpose because they lack the algebraic structure needed for homomorphic properties.
In particular, while SHA-256 provides strong security for general hashing purposes, it does not allow the additive properties that are required to perform the type of
ZKPs used in Nescience for UTXO commitments. This is why the Pedersen hash is preferred, as it enables the secure and private execution of transactions
while allowing for balance verification and other critical proofs.
**Conclusion**
By using homomorphic commitments like the Pedersen hash, NSSA ensures that UTXOs can be securely committed and validated without exposing sensitive information.
The random component (RCK) adds an additional layer of security, and the additive properties of the Pedersen commitment enable powerful ZKPs that maintain the
integrity of the system.
## <a id="key"></a> b) Key management and addresses in Nescience
NSSA utilizes difirrent cryptographic schemes, such as public key encryption and digital signatures, to ensure secure private executions through
---
NSSA utilizes different cryptographic schemes, such as public key encryption and digital signatures, to ensure secure private executions through
the exchange of UTXOs. These schemes rely on a structured set of cryptographic keys, each serving a specific purpose in maintaining privacy, security, and control over assets.
Here's a breakdown of the keys used in Nescience:
#### I. Spending key
### I. Spending key
The spending key is the fundamental secret key in NSSA, acting as the primary control mechanism for a user’s UTXOs and other digital assets.
It plays a critical role in the cryptographic security of the system, ensuring that only the rightful owner can authorize and spend their assets.
@@ -794,21 +794,19 @@ In summary, the spending key in Nescience is a powerful and carefully guarded el
are derived, allowing users to spend their UTXOs securely and privately. Its isolation from the public state and its random generation from a secure scalar field ensures
that the spending key remains protected, making it a cornerstone of security in NSSA.
#### II. Private keys
### II. Private keys
In Nescience, the private key is an essential cryptographic element responsible for facilitating various secure operations, such as generating commitments and signing
transactions. While the spending key plays a foundational role in safeguarding access to UTXOs and assets, the private keys handle the operational aspects of transactions
and cryptographic proofs. The private key consists of three critical components: ${private}_{key}.rsd$, ${private}_{key}.rcm$, and ${private}_{key}.sig$, each serving a
distinct purpose within the Nescience cryptographic framework.
1. ${private}_{key}.rsd$: random seed
The random seed (${private}_{key}.rsd$) is the first and foundational component of the private key. It is a value randomly chosen from the scalar field, which ensures
1. **${private}_{key}.rsd$ (random seed)**: The random seed (${private}_{key}.rsd$) is the first and foundational component of the private key. It is a value randomly chosen from the scalar field, which ensures
its cryptographic security and unpredictability. This seed is generated using a random number generator, making it virtually impossible to predict or replicate.
The random seed is essential because it is used to derive the other two components of the private key. By leveraging a secure random seed, Nescience ensures that
the entire private key structure is rooted in randomness, preventing external entities from guessing or deriving the key through brute-force attacks.
The strength of the random seed ensures the overall security of the private key and, consequently, the integrity of the user's transactions and commitments.
2. ${private}_{key}.rcm$: random commitment part
The random commitment component (${private}_{key}.rcm$) is a crucial part of the private key used specifically in the commitment scheme. It acts as a blinding factor,
2. **${private}_{key}.rcm$ (random commitment)**: The random commitment component (${private}_{key}.rcm$) is a crucial part of the private key used specifically in the commitment scheme. It acts as a blinding factor,
adding a layer of security to commitments made by the user. The ${private}_{key}.rcm$ value is also drawn from the scalar field and is used to ensure that the commitment
to any UTXO or other sensitive data remains confidential. The commitment scheme in Nescience requires the use of ${private}_{key}.rcm$ to create cryptographic commitments
that bind the user to specific data (such as UTXO details) without revealing the actual data. The role of ${private}_{key}.rcm$ is to ensure that these commitments are
@@ -816,8 +814,7 @@ non-malleable and secure, preventing anyone from modifying the committed data wi
to generate a Pedersen commitment that ensures the UTXO details are hidden but can still be verified cryptographically. This means that even though the actual UTXO details
are concealed, their existence and integrity can be proven.
3. ${private}_{key}.sig$: signing key for transactions
The signing key (${private}_{key}.sig$) is the third and final component of the private key, used primarily for signing transactions. One possible approach is that
3. **${private}_{key}.sig$ (signing key for transactions)**: The signing key (${private}_{key}.sig$) is the third and final component of the private key, used primarily for signing transactions. One possible approach is that
Nescience employs Schnorr signatures, a cryptographic protocol known for its efficiency and security. In this case, the ${private}_{key}.sig$ component would generate
Schnorr signatures that are used to authenticate transactions, ensuring that only the rightful owner of the private key can authorize the spending of UTXOs. Schnorr
signatures are important as they provide a secure and non-repudiable method of verifying that a transaction was initiated by the legitimate owner of the assets.
@@ -827,6 +824,7 @@ or spending assets they do not control. Even if an attacker gains access to the
the security of Alice's future transactions.
**Robustness of private keys in Nescience**
Despite the critical role of the private key in the operation of NSSA, the system is designed to maintain security even in the event that the
private key is compromised. This resilience is achieved through the integrity of the spending key, which is never exposed in the process of signing or committing.
The spending key acts as the ultimate safeguard, ensuring that even if a private key component is compromised, the attacker cannot access or spend the user's assets
@@ -836,18 +834,19 @@ The architecture’s design, where private keys handle operational tasks but rel
This way, the system can mitigate the damage of a compromised private key by maintaining the inviolability of the user's assets.
**Conclusion**
In summary, the private key in Nescience consists of three interrelated components that together ensure secure transaction signing, commitment creation, and the
protection of user data. The ${private}_{key}.rsd$ serves as the root from which the other key components are derived, ensuring randomness and security.
The ${private}_{key}.rcm$ plays a crucial role in generating commitments, while ${private}_{key}.sig$ provides the signing capability needed for transaction authentication.
Together, these components enable users to engage in private, secure transactions while preserving the integrity of their assets, even in the face of potential key compromise.
#### III. Public keys
### III. Public keys
Public keys in Nescience serve as the user's interface with the network, allowing for secure interaction and verification without exposing the user's private keys.
Derived directly from the user's private keys, public keys play a crucial role in enabling cryptographic operations such as transaction verification, commitment schemes,
and deterministic computations. The public key components correspond to their private key counterparts and ensure that transactions and commitments are securely processed
and validated across the network.
1. ${public}_{key}.sig$: verifying Schnorr signatures
1. **${public}_{key}.sig$ (verifying Schnorr signatures)**:
The ${public}_{key}.sig$ is derived from the signing component of the private key (${private}_{key}.sig$) and is used for verifying **Schnorr signatures**.
Schnorr signatures are used to authenticate transactions, ensuring that they have been signed by the legitimate owner of the private key. This public key is
@@ -857,7 +856,7 @@ needing access to the private key itself. This mechanism prevents forgeries as o
For example, if Alice sends a transaction, she signs it with her private key (${private}_{key}.sig$). Bob, or any other network participant, can use Alice’s ${public}_{key}.sig$
to verify the signature. If the signature is valid, Bob can be confident that the transaction was authorized by Alice and not by an imposter.
2. ${public}_{key}.rcm$: commitment schemes
2. **${public}_{key}.rcm$ (commitment schemes)**
The ${public}_{key}.rcm$ is derived from the commitment component of the private key (${private}_{key}.rcm$). It is used in the **commitment schemes**
that underpin Nescience’s privacy-preserving architecture. Commitments are a crucial cryptographic technique that allows users to commit to a piece of data (such as a UTXO)
@@ -867,7 +866,7 @@ that underpin Nescience’s privacy-preserving architecture. Commitments are a c
are consistent with the original data. For instance, when Alice commits to a UTXO, she uses her private key to generate the commitment, and the ${public}_{key}.rcm$ is available
to others to verify the commitment’s validity without revealing the underlying details.
3. ${public}_{key}.sk(prf)$: pseudorandom function
3. **${public}_{key}.sk(prf)$ (pseudorandom function)**
The ${public}_{key}.sk(prf)$ is derived from a random field element within the private key and is used to generate the **pseudorandom function (PRF)** associated with the user's account.
This PRF is essential for producing deterministic outputs based on the user’s keys and transaction data while ensuring that these outputs are unique to the user and cannot be
@@ -878,13 +877,13 @@ Nescience ensures that certain operations, like generating addresses or computin
role in this process is to maintain consistency in these outputs while preventing unauthorized parties from reverse engineering the associated private keys or transaction data.
**Summary**
Public keys in Nescience are essential for secure interactions within the network. "${public}_{key}.sig$" allows others to verify that transactions were signed by the legitimate owner,
ensuring the authenticity of every operation. "${public}_{key}.rcm$" enables secure and private commitment schemes, allowing participants to commit to transaction details without
revealing sensitive information. Finally, "${public}_{key}.sk(prf)$" powers deterministic outputs through a pseudorandom function, ensuring that user-specific data remains consistent
and secure throughout various transactions. Together, these public key components facilitate privacy, security, and trust within NSSA, enabling seamless interactions while safeguarding user data.
#### IV. Viewing key
### IV. Viewing key
The **viewing key** in NSSA is a specialized cryptographic key that allows a user to decrypt both incoming and outgoing transactions associated with their account.
This key is designed to offer a degree of transparency to the user, enabling them to view the details of their transactions without compromising the security of their assets or granting
control over those assets.
@@ -923,7 +922,7 @@ to decrypt and verify their transaction details, maintaining transparency in the
key must be handled with great care. Proper security measures are necessary to protect the viewing key, ensuring that the unlinkability of private, shielded, and deshielded
transactions remains intact. In this way, the viewing key offers a crucial balance between privacy and transparency within the Nescience ecosystem.
#### <a id="key"></a> V. Ephemeral key
### <a id="key"></a> V. Ephemeral key
The ephemeral key is generated using a combination of the sender’s spending key and the UTXO's nullifier, ensuring that the key is unique to each transaction.
The process can be informally described as follows:
@@ -967,12 +966,13 @@ The end result is an ephemeral key system that provides strong cryptographic gua
cryptographic primitives to prevent unauthorized access to sensitive transaction data.
**Conclusion**
The ephemeral key in Nescience is a critical element for maintaining transaction confidentiality. It facilitates a secure key agreement between the sender and the receiver,
allowing for the encryption of transaction details with a shared secret that can only be derived by the intended recipient. By incorporating the nullifier, receiver's public key,
and diversifier address, the ephemeral key ensures that transaction privacy is preserved while preventing unauthorized access to transaction information, even in a complex,
multi-party blockchain environment.
#### VI. Nescience addresses
### VI. Nescience addresses
Nescience’s dual address system is a core component of its privacy-focused architecture, designed to balance transparency and confidentiality across different types of transactions.
The architecture provides each user or smart contract with both public addresses and private addresses, allowing them to participate in both open and confidential activities on the blockchain.
@@ -1012,6 +1012,7 @@ This functionality is critical for users who want to maintain control over their
The ability to generate multiple private addresses and decrypt them with the viewing key ensures that users can maintain compartmentalized privacy without sacrificing oversight.
**Summary**
Nescience’s dual address system—comprising public and private addresses—provides users with the flexibility to engage in both transparent and confidential transactions.
Public addresses are visible onchain and are used for open, public interactions that require accountability and auditability. In contrast, private addresses are
invisible onchain and are used for confidential transactions, enhancing privacy and security.
@@ -1021,7 +1022,7 @@ key’s ability to decrypt transactions involving private addresses, the system
exposing sensitive information to the public state. This dual-address approach enables users to seamlessly switch between public and private interactions depending on their needs,
providing a robust framework for both privacy and transparency in NSSA.
#### VII. Conclusion
### VII. Conclusion
Key management in NSSA is a carefully designed system that strikes an optimal balance between security, privacy, and flexibility.
The architecture’s hierarchical structure, with distinct roles for the spending key, private keys, and public keys, ensures that users retain full control
over their assets while maintaining the integrity of their transactions. The spending key, as the root of security, provides unassailable control over the
@@ -1045,15 +1046,15 @@ interactions and the security of private transactions, all while maintaining the
## c) Trees in NSSA
Trees in NSSA serve as verifiable databases, essential for maintaining privacy and security. Different types of trees are used for various purposes:
1. Global state tree: The global state tree is a single, public tree that holds all public assets and storage information. It acts as a central repository for all
1. **Global state tree:** The global state tree is a single, public tree that holds all public assets and storage information. It acts as a central repository for all
publicly accessible data on the blockchain. By organizing this data in a Merkle tree structure, the Global State Tree allows for efficient and secure verification of public information.
2. Hashed UTXO tree: The hashed UTXO tree is a public tree that contains hashes of all created UTXOs. When users wish to consume a UTXO, they provide a membership
2. **Hashed UTXO tree:** The hashed UTXO tree is a public tree that contains hashes of all created UTXOs. When users wish to consume a UTXO, they provide a membership
proof to demonstrate that the UTXO exists within this tree. This process ensures that only valid and existing UTXOs can be spent, maintaining the integrity of transactions.
In fact, users generate membership proofs that verify the presence of specific UTXOs in the tree without revealing their actual data. The benefit here is that the Merkle
tree structure allows for quick and efficient verification of UTXO existence.
3. UTXO trees (private states): Each user or smart contract has its private state stored in UTXO trees. These trees are kept as plaintext on the client’s
3. **UTXO trees (private states):** Each user or smart contract has its private state stored in UTXO trees. These trees are kept as plaintext on the client’s
local system (off-chain), ensuring privacy as sensitive information remains confidential. The private state includes all UTXOs owned by the user or the smart contract, and these
are not directly exposed to the public blockchain. For instance, users have full control over their private state, which is not visible to other participants in the network.
@@ -1160,7 +1161,7 @@ this feature is under development and review for potential inclusion depending o
# D. Future Plans for Nescience
# D. Future plans for Nescience
Nescience is committed to continuously evolving its architecture to ensure scalability, privacy, and security in a growing blockchain landscape.
One of the primary goals is to integrate the **zk-zkVM** and the **Nescience state-separation architecture** into a fully functioning node,