# Execution Types ## Execution Types and Privacy Mechanism Design This document offers an in-depth analysis of the specifications and workflows for public, private, shielded, and deshielded executions in the Nescience state separation architecture. ### A. Components --- The prototype execution is defined through the integration of several essential components, namely: a public state, a private state, a ZKvm, a set of executions, Nescience users, and smart contracts. #### 1. Public State **Definition**: The public state is a single Merkle tree structure within the blockchain network that holds all publicly accessible information. This includes user balances and the public storage information of smart contracts. It operates in an account-based model, modifying the tree as transactions occur. **Technical Details**: - **Merkle Tree Structure**: The public state is represented as a Merkle tree, a binary tree structure where each leaf node contains a hash of a block of data, and each non-leaf node contains the hash of its children. This structure provides efficient and secure verification of data integrity. If any change occurs in the data, the hash will change, making it easy to detect tampering. - **Account-Based Model**: The public state follows an account-based model that maintains a global state of accounts and balances. Each account or smart contract's public data is stored as a leaf in the Merkle tree. Transactions modify the state by updating the account balances or smart contract storage directly. - **Data Integrity**: The Merkle root of the public state tree is stored on the blockchain. This root hash provides a cryptographic guarantee of the data's integrity, as any alteration in the underlying data will result in a different root hash. - **Transparency**: All data stored in the public state is openly accessible and verifiable by any network participant. This transparency ensures that all transactions and state changes are visible and auditable, fostering trust and accountability within the network. **Workflow**: 1. **Transaction Initiation**: When a user initiates a transaction that involves modifying public data, the relevant changes are proposed to the public state tree. 2. **Data Update**: The transaction details, such as transferring funds between accounts or updating smart contract storage, are used to update the relevant leaf nodes in the Merkle tree. 3. **Merkle Tree Recalculation**: As leaf nodes are updated, the hashes of affected nodes are recalculated up to the root. This process ensures that the entire tree reflects the most recent state of the network. 4. **Merkle Root Update**: The updated Merkle root is recorded on the blockchain, allowing all participants to verify the integrity of the public state. 5. **Verification**: Network participants can use the Merkle root to verify the integrity of the public state. Any discrepancy in the data will result in a mismatched root hash, signaling potential tampering or errors. **Use Case**: The public state is ideal for storing non-sensitive information that benefits from being publicly accessible and verifiable. Examples include: - **User Balances**: Publicly viewable account balances to ensure transparency and trust in the system. - **Smart Contract Storage**: Publicly accessible storage for smart contracts that require visibility for verification and audit purposes. - **Public Records**: Information that needs to be openly available and verifiable, such as registry data or public logs. #### 2. Private State **Definition**: The private state consists of individual Merkle trees for each user, holding private information such as private balances and private storage information. **Technical Details**: - **List of UTXOs**: Each user's private state is represented as a separate list. - **UTXO Model**: The private state utilizes a UTXO model (a hashed UTXO Merkle tree) where each transaction output is a discrete unit that can be spent in future transactions. Each leaf in the Merkle tree represents a UTXO, ensuring granular control over transaction outputs. - **Privacy and Confidentiality**: The structure of the private state ensures that only parties that possess the user's viewing key can construct the users' list of UTXOs. - **Zero-Knowledge Proofs**: Modifications to the private state require the generation of zero-knowledge proofs (ZKPs). These proofs validate the transaction's correctness without revealing the actual private data, ensuring both security and privacy. - **Data Integrity**: Similar to the public state, the Merkle root of the hashed UTXO Merkle tree is used to verify the integrity of the data. Moreover, the use of nullifiers ensures that a UTXO is only spent one time. **Workflow**: 1. **Transaction Initiation**: A user initiates a transaction involving their private data. This could be a transfer of private balance or an update to private smart contract storage. 2. **UTXO Creation and Spending**: The transaction involves spending existing UTXOs (leaves in the Merkle tree) and creating new UTXOs. These new UTXOs are appended to the user's private list. 3. **Proof Generation**: The zkVM generates a zero-knowledge proof to validate the transaction without revealing the private data. This proof demonstrates that the transaction is valid and adheres to the rules of the system. 4. **Proof Submission and Verification**: The user submits the proof to the sequencer. The sequencer verifies the proof to ensure the transaction's validity. 5. **Nullification Update**: Upon successful verification, the nullifier is added to the nullifier set. **Use Case**: The private state is suitable for storing sensitive information that requires confidentiality and privacy. Examples include: - **Private Balances**: Confidential account balances that should not be publicly accessible. - **Private Smart Contract Storage**: Data associated with smart contracts that need to remain private, such as confidential business logic or sensitive user information. - **Sensitive Records**: Information that needs to be kept private, such as medical records, personal identification data, or proprietary business information. #### 3. zkVM (Zero-Knowledge Virtual Machine) **Definition**: A virtual machine responsible for creating and aggregating zero-knowledge proofs (ZKPs), ensuring the privacy and security of transaction inputs. **Technical Details**: - **Zero-Knowledge Proofs (ZKPs)**: ZKPs are cryptographic protocols that enable one party (the prover) to prove to another party (the verifier) that a statement is true without revealing any additional information. In the context of zkVM, ZKPs ensure that the details of transaction inputs remain confidential while proving their validity. - **Proof Generation**: The zkVM generates ZKPs for transactions. When a user initiates a transaction, the zkVM processes the transaction inputs and generates a proof that the transaction is valid without revealing the actual data. This involves complex mathematical computations and cryptographic algorithms to ensure the integrity and confidentiality of the transaction. - **Proof Aggregation**: To optimize performance, the zkVM can aggregate multiple ZKPs into a single proof. This reduces the overhead for verifying transactions, as the verifier (sequencer) only needs to check a single aggregated proof instead of multiple individual proofs. This aggregation process involves combining individual proofs while maintaining their individual validity. - **Privacy and Security**: By hiding transaction inputs and only revealing the proof of validity, the zkVM ensures that sensitive information remains confidential. This is crucial for maintaining user privacy and preventing unauthorized access to transaction details. - **Performance Optimization**: The zkVM is designed to efficiently handle the computational load of generating and verifying ZKPs. It employs optimization techniques such as parallel processing and efficient data structures to minimize latency and maximize throughput. - **Integration with Blockchain**: The zkVM operates within the blockchain network, interacting with other components like the public and private states. It ensures that all transactions meet the required privacy and security standards before being included in the blockchain. **Workflow**: 1. **Transaction Initiation**: A user initiates a transaction that requires privacy and security. 2. **Proof Request**: The user requests the zkVM to generate a zero-knowledge proof for the transaction. 3. **Proof Generation**: The zkVM processes the transaction inputs and generates a ZKP, proving the transaction’s validity without revealing the actual data. 4. **Proof Aggregation**: If there are multiple proofs to be verified, the zkVM aggregates them into a single proof to optimize verification efficiency. 5. **Proof Submission**: The user submits the proof (or aggregated proof) to the sequencer for verification. 6. **Verification**: The sequencer uses the zkVM to verify the correctness of the proof. If valid, the transaction is accepted and the relevant state (public or private) is updated. **Use Case**: The zkVM is essential for any blockchain transactions that require high levels of privacy and security. Examples include: - **Confidential Financial Transactions**: Ensuring that transaction amounts and participants remain private while proving the transaction is valid. - **Private Smart Contract Execution**: Executing smart contracts without revealing sensitive business logic or user data. - **Secure Data Sharing**: Allowing users to share proof of data possession or compliance without revealing the actual data. #### 4. Executions **Definition**: Different types of transaction executions that dictate how data is read from and written to the public and private states. These execution types provide varying levels of privacy and security, allowing users to choose the appropriate level of confidentiality for their transactions. The execution types include: public executions, private executions, shielded and deshielded executions. - **1. Public Execution**: - **Read from**: Public State - **Write to**: Public State - **ZKP Required**: No - **Use Case**: Non-sensitive transactions requiring transparency, such as public record updates, open financial transactions, or public smart contract interactions. - **Workflow**: 1. **Transaction Creation**: User initiates a transaction that reads from and writes to the public state. 2. **Data Access**: Public data is accessed and modified directly without additional cryptographic proofs. 3. **Transaction Signing**: The transaction is signed by the user and submitted to the sequencer. 4. **Verification**: The sequencer verifies the transaction by executing the smart contract with the provided public inputs. 5. **State Update**: If valid, the public state is updated, and the new Merkle root is recorded on the blockchain. - **2. Private Execution**: - **Read from**: Private State - **Write to**: Private State - **ZKP Required**: Yes - **Use Case**: Confidential transactions needing privacy, such as private financial transactions or private smart contract executions. - **Workflow**: 1. **Transaction Creation**: User initiates a transaction that reads from and writes to their private state. 2. **Data Access**: Private data is accessed, and the transaction details are prepared. 3. **Proof Generation**: The zkVM generates a zero-knowledge proof to validate the transaction without revealing private data. 4. **Proof Submission**: The proof is submitted to the sequencer. 5. **Verification**: The sequencer verifies the proof to ensure the transaction's validity. 6. **State Update**: If valid, the private state is updated, and the new Merkle root is calculated. - **3. Shielded Execution**: - **Read from**: Public State - **Write to**: Private State - **ZKP Required**: Yes - **Use Case**: Transactions where the receiver’s identity needs to be hidden, such as anonymous donations or confidential data storage. - **Workflow**: 1. **Transaction Creation**: User initiates a transaction that reads from the public state and writes to the private state. 2. **Data Access**: Public data is accessed, and the private state is prepared to receive new data. 3. **Proof Generation**: The zkVM generates a zero-knowledge proof to hide the receiver’s identity. 4. **Proof Submission**: The proof is submitted to the sequencer. 5. **Verification**: The sequencer verifies the proof to ensure the transaction's validity. 6. **State Update**: If valid, the private state is updated with the new data, and the public state reflects the change without revealing the private details. - **4. Deshielded Execution**: - **Read from**: Private State - **Write to**: Public State - **ZKP Required**: Yes - **Use Case**: Transactions where the sender’s identity needs to be hidden, such as confidential disbursements or anonymized data publication. - **Workflow**: 1. **Transaction Creation**: User initiates a transaction that reads from the private state and writes to the public state. 2. **Data Access**: Private data is accessed, and the transaction details are prepared. 3. **Proof Generation**: The zkVM generates a zero-knowledge proof to hide the sender’s identity. 4. **Proof Submission**: The proof is submitted to the sequencer. 5. **Verification**: The sequencer verifies the proof to ensure the transaction's validity. 6. **State Update**: If valid, the public state is updated with the new data, reflecting the change while keeping the sender’s details confidential. **Table of Execution Types**: | Type | Read from | Write to | ZKP Required | Use Case | |-------------|--------------|-------------|--------------|-------------------------------------------------------------------------| | Public | Public State | Public State| No | Non-sensitive transactions requiring transparency. | | Private | Private State| Private State| Yes | Confidential transactions needing privacy. | | Shielded | Public State | Private State| Yes | Transactions where the receiver’s identity needs to be hidden. | | Deshielded | Private State| Public State| Yes | Transactions where the sender’s identity needs to be hidden. | *Table 1: Four kinds of transactions* By providing different execution types, the Nescience blockchain architecture allows users to choose the level of privacy and security that best fits their needs, enhancing the flexibility and utility of the blockchain. #### 5. Nescience Users **Definition**: Nescience users are nodes within the blockchain network that hold balances and assets. They possess the capability to invoke arbitrary smart contracts with various privacy options. Users have the freedom to choose the type of execution (public, private, shielded, or deshielded) for each transaction, depending on their privacy and security needs. **Technical Details**: - **1. Balances and Assets**: - **Public Balances**: These are stored in the public state and are visible to all network participants. Public balances can be used for transactions that do not require privacy. - **Private Balances**: These are stored in the private state and are only visible to the user. Private balances are used for transactions that require confidentiality. - **Asset Management**: Users can hold various digital assets, such as tokens, within their public and private balances. These assets can be transferred and managed through smart contracts. - **2. Smart Contract Invocation**: - **Arbitrary Smart Contracts**: Users can deploy and invoke any smart contract, enabling a wide range of decentralized applications (dApps). - **Privacy Options**: When invoking a smart contract, users can select the desired level of privacy by choosing the appropriate execution type (public, private, shielded, or deshielded). - **3. Execution Types**: - **Public Execution**: Used for transparent transactions where privacy is not a concern. - **Private Execution**: Used for confidential transactions where privacy is critical. - **Shielded Execution**: Used to hide the receiver’s identity while performing the transaction. - **Deshielded Execution**: Used to hide the sender’s identity while making the transaction results public. - **4. Key Management**: - **Cryptographic Keys**: Users utilize public and private cryptographic keys to sign transactions, ensuring authenticity and integrity. - **Key Storage**: Keys are securely stored and managed by the user, often using hardware wallets or secure software solutions. - **5. User Interface**: - **Wallets**: Users interact with the Nescience blockchain through digital wallets, which provide an interface for managing balances, assets, and executing transactions. - **Transaction Creation**: The wallet interface allows users to create transactions, select execution types, and submit transactions for processing. **Workflow**: 1. **Initiate Transaction**: The user decides to perform a transaction, selecting the appropriate privacy level by choosing between public, private, shielded, or deshielded execution. 2. **Prepare Inputs**: The user prepares the necessary inputs for the transaction, which may involve accessing public or private balances and generating cryptographic proofs if required. 3. **Smart Contract Interaction**: If the transaction involves a smart contract, the user invokes the contract with the chosen inputs and execution type. 4. **Generate Proof (if needed)**: For private, shielded, and deshielded executions, the user requests proof generation from the zkVM. 5. **Submit Transaction**: The user submits the transaction, including the proof (if applicable), to the sequencer for verification. 6. **Verification and State Update**: The sequencer verifies the transaction and updates the relevant state (public or private) based on the execution type. **Use Cases**: - **Financial Transactions**: Users can perform both public and private financial transactions, choosing the privacy level based on the sensitivity of the transaction. - **Decentralized Applications**: Users can interact with various dApps, such as decentralized finance (DeFi) platforms, games, and marketplaces, utilizing different execution types to meet their privacy needs. - **Data Privacy**: Users can manage and share sensitive data through smart contracts with private or shielded executions, ensuring that the data remains confidential. **Benefits**: - **Flexibility**: Users have the freedom to choose the privacy level of each transaction, enabling a wide range of applications and use cases. - **Security**: The use of cryptographic keys and zero-knowledge proofs ensures the security and integrity of transactions. - **Privacy**: Users can maintain confidentiality for sensitive transactions, protecting their data and identity. By providing users with the ability to manage balances and assets, invoke smart contracts, and select the appropriate execution type for each transaction, the Nescience state separation architecture ensures a versatile and secure environment for a wide range of decentralized applications. #### 6. Smart Contracts **Definition**: Immutable programs deployed on the blockchain, which execute predefined actions based on the terms coded within them. These programs are self-executing and run automatically when certain conditions are met, ensuring trust and transparency in a decentralized environment. **Technical Details**: - **Immutability**: - **Immutable Code**: Once deployed on the blockchain, the code of a smart contract cannot be altered. This ensures that the contract behaves exactly as intended and cannot be tampered with. - **Permanent Storage**: The contract's state and data are stored on the blockchain permanently, providing a transparent and auditable record of all interactions with the contract. - **Self-Executing**: - **Predefined Conditions**: Smart contracts are programmed with specific conditions that trigger their execution. When these conditions are met, the contract automatically executes the coded actions. - **Automation**: This automation reduces the need for intermediaries, enabling direct interactions between parties. - **Deterministic**: - **Consistent Execution**: The outcome of a smart contract is deterministic, meaning it will always produce the same result given the same input. This predictability is crucial for ensuring trust and reliability. - **Isolation**: Smart contracts execute in a sandboxed environment, isolated from other processes on the blockchain. This prevents unintended interactions and ensures security. - **Security**: - **Cryptographic Security**: Smart contracts leverage the underlying cryptographic security of the blockchain, ensuring that interactions are secure and authenticated. - **Verification**: Code can be audited and verified before deployment, and the immutable nature of the contract ensures that once deployed, it cannot be changed. - **Gas Fees**: - **Execution Costs**: Running smart contracts requires computational resources, which are paid for using gas fees. These fees incentivize miners to include the contract execution in the blockchain and help prevent abuse of computational resources. - **Fee Calculation**: Gas fees are calculated based on the complexity of the operations performed by the smart contract. More complex contracts require more computational power and thus incur higher fees. **Workflow**: 1. **Development**: Developers write the smart contract code, typically using a blockchain-specific programming language such as Solidity (for Ethereum). 2. **Compilation**: The code is compiled into bytecode that the blockchain's virtual machine can execute. 3. **Deployment**: The compiled contract is deployed to the blockchain, becoming a permanent part of the blockchain's state. This process includes paying the necessary gas fees for the deployment. 4. **Invocation**: - **Initiation**: Users interact with the deployed smart contract by sending transactions that call specific functions within the contract. - **Condition Checking**: The contract checks if the predefined conditions for execution are met. - **Execution**: If conditions are met, the contract executes its programmed actions, such as transferring tokens, updating state variables, or interacting with other contracts. - **State Update**: The contract's state and the blockchain are updated to reflect the execution of the contract. **Use Cases**: - **Financial Services**: Automating transactions, loans, and payments in a transparent and secure manner. - **Supply Chain Management**: Tracking goods and verifying authenticity throughout the supply chain. - **Voting Systems**: Ensuring secure, transparent, and tamper-proof voting processes. - **Decentralized Autonomous Organizations (DAOs)**: Managing organizations through code, enabling decentralized governance and decision-making. - **Insurance**: Automating claims processing based on predefined conditions, reducing fraud and improving efficiency. **Benefits**: - **Trust**: The immutability and transparency of smart contracts eliminate the need for trust in intermediaries, as the contract's code is the ultimate authority. - **Efficiency**: Automation of processes reduces the time and cost associated with manual interventions and intermediaries. - **Security**: The cryptographic foundations of blockchain and the isolation of smart contracts provide strong security guarantees. - **Transparency**: All interactions with the contract are recorded on the blockchain, providing a transparent and auditable history. By leveraging the capabilities of smart contracts, the Nescience blockchain can facilitate a wide range of decentralized applications, offering automated, secure, and transparent solutions across various industries. ### B. General Execution Overview --- The process begins when a user initiates a transaction by invoking a smart contract (SC). This invocation involves selecting at least one of the four execution types: public, private, shielded, or deshielded. The choice of execution type determines how data will be read from and written to the blockchain, affecting the transaction's privacy and security levels. Each execution type caters to different privacy needs, allowing the user to tailor the transaction according to their specific requirements, whether it be full transparency or complete confidentiality.  #### User Actions: **Step 1**: **Smart Contract Selection and Input Creation** - **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. **Step 2**: **Choosing Execution Type** - **Execution Type Selection**: The user selects the type of execution based on their privacy needs. The options include: - **Public Execution**: Suitable for transactions where transparency is desired. - **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. 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. - **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. **Step 4**: **Transmitting Public Inputs and Retaining Private Inputs** - **Retaining Private Inputs**: The user keeps the private inputs secure and does not transmit them. - **Revealing Public Inputs**: The user transmits the following public inputs to the sequencer: - Public inputs of the recursive proof - Hashes of UTXOs - Updates to the public state - Transaction signature - Nullifiers (to prevent double spending) After completing these steps, the user's part of the execution is done, and the sequencer takes over the process. #### Sequencer Actions: **Step 5**: **Proof Verification** - **Proof and Data Reception**: The sequencer receives the proof and public inputs from the user. - **Verification Process**: - For private, shielded, and deshielded executions, the sequencer verifies the proof using the provided public data. - For public executions, the sequencer reruns the smart contract code with the provided inputs to check the results. - **Validation**: If both the zkVM proofs and public execution results are verified successfully, the sequencer collects the proof and public data to proceed. If verification fails, the process is aborted, and the transaction is rejected. **Step 6**: **Aggregating Proofs and Finalizing the Block** - **Proof Aggregation**: The sequencer calls the zkVM again to aggregate all received proofs into one comprehensive proof to finalize the block. - **Finalizing the Block**: - **Public State Update**: The sequencer updates the public state with the new transaction data. - **Nullifier Tree Update**: Updates the nullifier tree to reflect the new state and prevent double spending. - **Synchronization Mechanism**: Runs synchronization mechanisms to ensure fairness and consistency across the network. - **UTXO Validation**: Validates the exchanged UTXOs to complete the transaction process. This comprehensive process ensures that transactions are executed securely, with the appropriate level of privacy and state updates synchronized across the network.