TEE Rollups: Fixing Access Patterns in TEE-based Smart Contracts with Off-chain Computing
Project Description
Our recent paper detailed several attacks on Secret Network that broke user privacy guarantees without doing the hard work of breaking into the TEE hardware. Following the publication of our research on attacks against TEE-based blockchain networks, we concluded that effectively preventing the identified privacy leaks necessitates the use of obfuscation techniques. However, we found that integrating these techniques directly into the “on-chain” execution posed significant challenges due to their high cost and complexity, as the execution would have to be replicated across every node in the network. To address this, we devised a novel approach by implementing these techniques in the “off-chain” environment, with only a single node needed to run it and post results on-chain later, substantially reducing the costs.
Problem
Access pattern leakage in TEE-based smart contracts: breaking token transfer receiver privacy
While Trusted Execution Environments (TEEs) provide a secure enclave for code execution and data protection, it is imperative to consider the broader infrastructure's role in upholding privacy. A meticulously architected system must, for instance, scrutinize the mechanisms by which encrypted data and transactions are imported into the TEE. In our study related to SNIP-20 tokens on the Secret Network, we have identified that the receiver's address may be susceptible to indirect exposure due to potential information leaks when interacting with the external world. Specifically, in the case of SNIP-20 token transfers, by analyzing the historical data of encrypted balances loaded into TEE and correlating them with public sender addresses (sender's address remains public for the purpose of paying transaction fee), the receiver’s address could potentially be deduced.
Challenges in preventing access pattern leakage
Addressing the challenge of access pattern leakage in TEE-based blockchains necessitates the deployment of obfuscation strategies. These can be incorporated at the application layer, specifically within the smart contract code, or integrated into the blockchain's core execution layer. For instance, for a token transfer, instead of loading only the sender’s and receiver’s account balances into TEE, we could do a linear scan over all possible account balances. Such a method is designed to prevent the disclosure of specific addresses accessed by the token transfer. This entails loading and updating all encrypted balances during the scan, yet only altering the sender and receiver’s balances to a new plaintext value. The approach is a basic instance of Oblivious RAM ORAM, a data structure designed explicitly to conceal storage access patterns.
However, the direct implementation of ORAM within smart contracts can be excessively costly. Taking the widely-used SNIP-20 token, sSCRT, as an example: a linear scan approach would necessitate loading and refreshing more than 36,000 records for each token transfer. This becomes increasingly unsustainable as the network's user base grows, leading to soaring associated costs. While advanced ORAM designs may offer more efficiency, the sheer volume of storage operations required still presents a significant hurdle.
Alternatively, embedding ORAM within the execution layer would imply major modifications to the consensus protocol. Moreover, it’s not a one-size-fits-all solution, as not all operations need the same level of privacy protection. Consequently, there is also the task of evolving the smart contract language to accommodate ORAM functionalities, adding another layer of complexity to the solution.
Detailed Product Description
Basic idea: using “FREE” off-chain execution to achieve ORAM
The on-chain implementation of Oblivious RAMs (ORAMs) would substantially increase the gas costs associated with token transfers, particularly as transaction complexity grows. This cost inflation stems from the necessity for every network node to replicate the additional operations designed to obscure the access to specific database entries. To circumvent these prohibitive transaction costs, we propose the adoption of ORAM exclusively in an off-chain 'view-only' mode. This mode is predominantly utilized by users for state queries, which are not disseminated across the network. By delegating the execution of ORAM to a single TEE node, we preserve the intrinsic privacy and integrity that the original TEE-based blockchain network provides. Applications that opt for off-chain ORAM benefit from enhanced access pattern protection, without adding computational overhead to the rest of the network or financial strain on its users.
Different from in public blockchain where anyone can freely read chain state, in TEE-based blockchain, only authenticated enclaves are capable of decrypting private smart contract states and providing query results to authorized users. For instance, when users need to check their SNIP-20 token balance, they send an off-chain query to a TEE node. The TEE node retrieves their encrypted balance from external storage, decrypts the value, and sends back the re-encrypted value, ensuring that only the querier can decrypt it. Such queries are “view-only” as they do not alter the blockchain state and are “off-chain” because the query transactions are not recorded/ordered on the blockchain. The execution of an off-chain query occurs on a single TEE node and is not replicated across the network.
For Secret Network such off-chain queries are currently FREE, but there is a per query gas limit imposed to restrict the number of operations performed in a single query. While off-chain queries do not directly update the blockchain state, there is nothing stopping us from using this infrastructure to conduct useful computations with the privacy and integrity guarantees provided by TEEs.
Truly private token contract
We demonstrate the effectiveness of our approach to solve the recipient address leakage in privacy-preserving token contracts. As previously noted, the main functionality of a privacy-preserving token contract is to enable private transfers, which involves hiding the transfer amount, recipient’s address, and token account balances. The sender’s address is made public as they are responsible for paying the transaction fee using the chain’s public native coin. However, the amounts involved in deposit and withdrawal transactions are not hidden, as these can be inferred by observing changes in the public token account balances.
In our implementation of applications using off-chain queries, we prioritize user experience by hiding the complex underlying processes from them. Users are only required to provide private inputs at the start and receive the private outputs upon computation completion. This ensures a seamless experience for users, maintaining the same interfaces as the existing fully on-chain implementation.
To achieve this, we employ a dedicated worker responsible for submitting off-chain queries to trigger the off-chain computing process. The worker node stores intermediate results until they post the final private output back on-chain. With the use of the worker node, we must ensure two things, 1) privacy — the worker cannot learn anything about the private inputs, intermediate results, and final private output; 2) integrity — the output posted on-chain is indeed obtained from off-chain queries carried out by a TEE. For these purposes, we use an authenticated encryption scheme to encrypt the off-chain queries outputs, ensuring both privacy protection and prevention of forgery.
During the instantiation phase, the smart contract generates a private authenticated (symmetric) encryption (AEAD) key on-chain, accessible only to TEE nodes. This key enables encryption of values, ensuring that data originates from smart contract function invocation within the TEE and can only be decrypted by TEE.
Figure below shows execution in our model. A user posts their input through an on-chain transaction. The worker node calls the view-only function getState() in the smart contract, employing the AEAD key to encrypt the user input into encInput, which can only be decrypted by TEE.
The worker initiates an off-chain query by invoking the view-only function processNext(), passing encInput as the input. The TEE decrypts the value, performs desired data processing functionality, re-encrypts the result as encState0, and returns it to the worker. The processNext() function is iteratively called with the output from the last call until the desired number of user inputs are processed.
The worker sends the final result to the TEE node and creates an on-chain transaction using the commit() function to post the result on-chain. After this the user can get the result as they would in a regular application.
To interact with our access pattern protected token contract, users submit transaction requests (deposit, transfer, or withdraw) much like they would with current privacy-preserving token contracts, while also providing private inputs to the invoked function. However, these transactions are not processed instantly. Instead, they are ordered in a sequence and recorded on-chain for subsequent processing. A worker node then processes these transactions using off-chain queries, in the order dictated by the blockchain. At the end, the worker node posts updated account balances back to the blockchain.
To achieve receiver address privacy, we incorporate the linear scan functionality into a view-only function in our token smart contract. By implementing the linear scan in view-only functions, we allow the costly computations to be performed by a single TEE node. This strategy not only minimizes extra transaction fees incurred from the complex linear scan but also maintains privacy and integrity.
To facilitate the transfer of off-chain computation responsibilities between worker nodes and avoid new workers to sync everything from scratch, we implement a checkpointing mechanism in the token contract. The checkpoint state contains a list of all account balances and a sequence number of last transaction processed to get those balances. The worker node gets the encrypted checkpoint state from the view-only function, getState. Because the checkpoint state is encrypted using authenticated encryption the worker cannot manipulate or read the user balances.
The worker consistently submits off-chain queries to invoke the view-only function, processNext, providing the latest encrypted checkpoint state as function input. The function executes the subsequent user transaction request in the sequence and updates the provided checkpoint state accordingly (updating account balances and incrementing sequence number).
In addition to posting the most recent checkpoint state (including updated account balances and sequence number) on-chain after processing a batch of transactions, the worker also must ensure the “side effects” of transaction execution take effect. In essence, a withdraw request could trigger a token transfer from the token contract to a different account or contract, which must be managed when the worker is posting the checkpoint.
Efficiency Improvement
The linear scan referenced earlier represents a basic instantiation of ORAM. To enhance efficiency and broaden functionality, more sophisticated ORAM architectures should be explored. This may involve either the integration with existing ORAM frameworks or the development of a proprietary implementation. Concurrently, employing complex ORAM structures presents the challenge of ensuring compatibility with existing public external storage solutions.
As the frequency of off-chain queries escalates, we will explore the potential for parallelization of the worker node tasks and employment of multiple network nodes to handle these queries. Coordinating among these nodes to prevent conflicts during state updates presents an additional challenge that must be addressed.
Project Deliverables
Our commitment is to deliver a proof-of-concept implementation of truly private token contracts, developed in Rust, accompanied by an off-chain worker toolkit coded in NodeJs. These components will be seamlessly integrated with the Secret Network's existing infrastructure and will conform to the current SNIP-20 (or SNIP-25) token standards. A key aspect of our plan is to abstract the intricacies of the ORAM and the concurrency control backend, thereby simplifying the development process for programmers.
Value capture for Secret Network ecosystem
This will add essential privacy protection for privacy-preserving tokens on Secret, while ensuring minimal additional overhead to the network's operations.
We will require 6 months to complete this project. Nerla and Yunqi would work on this project as part of their thesis research, which is advised by Andrew. Gabe would help us and give us suggestions on software development. The total cost is $52,000 worth in SCRT.
Milestones and budgets:
Proof-of-Concept for token contract using linear scan (1 month, $12000)
Rust smart contract code
NodeJS worker code
Create a NodeJS API for the worker (1 month, $5000)
Optimize the contract using more efficient ORAM construction (2 months, $20000)
Integrate contract with SNIP-20 (or SNIP-25) standard (1 month, $7500)
Concurrent execution of off-chain queries and coordination between multiple workers (1 month, $7500)
Ideally, we can receive payments in 5 disbursements, at the beginning of each milestone.
Additional Info
As we consider the future evolution of this initiative, our aim is to transition it into an extensive research endeavor. Upon the successful completion of the current project, we are open to exploring deeper collaborative opportunities to further these research directions.
TEE Rollups Programming Model
Within the scope of our proposal, we intend to showcase a prototype application—a private token—to illustrate our concept. Our ultimate ambition extends beyond this example; we envision empowering developers to freely program a wide array of applications. To this end, our objective is to develop a versatile, general-purpose programming framework that enables the crafting of applications with protected access patterns, leveraging the capabilities of TEE Rollups.
For developers, they should be able to seamlessly integrate access pattern protection into their applications, in alignment with the established conventions of the Secret Network infrastructure. This framework will allow developers to designate specific parts of their smart contracts for enhanced access pattern security. Subsequently, the framework will automatically convert the simple source code into sophisticated implementations, leveraging obfuscation techniques and off-chain computations.
The deployment process of these implementations will be streamlined. While the on-chain components will adhere to the Secret Network's existing protocols, the framework will also furnish a straightforward method for instructing off-chain workers about their roles for each application. For instance, workers would monitor designated on-chain events to initiate the related off-chain computations and subsequently publish the results back to the blockchain.
Aiming to prioritize usability, the framework is designed to abstract the complexity from the end-users. They will simply need to input confidential data at the beginning and retrieve private outputs once computations are complete, thus preserving a user experience that is consistent with—or potentially identical to—the current fully on-chain interactions.
Fee mechanism redesign
When TEE-based networks adopt this off-chain query mechanism we introduce, significant elevation in the volume of off-chain queries is expected. This surge underscores the necessity for an effective access control mechanism and a refined fee structure to thwart denial-of-service attacks and to motivate network participants, particularly the workers.
Consequently, this may entail a shift from the current cost-free model of off-chain queries to a nominally charged scheme, ensuring affordability while maintaining a substantial cost advantage over on-chain executions. Additionally, we anticipate a review and potential revision of the gas limits applicable to off-chain queries to align with these changes.
TEE Rollups: Fixing Access Patterns in TEE-based Smart Contracts with Off-chain Computing
Project Description
Our recent paper detailed several attacks on Secret Network that broke user privacy guarantees without doing the hard work of breaking into the TEE hardware. Following the publication of our research on attacks against TEE-based blockchain networks, we concluded that effectively preventing the identified privacy leaks necessitates the use of obfuscation techniques. However, we found that integrating these techniques directly into the “on-chain” execution posed significant challenges due to their high cost and complexity, as the execution would have to be replicated across every node in the network. To address this, we devised a novel approach by implementing these techniques in the “off-chain” environment, with only a single node needed to run it and post results on-chain later, substantially reducing the costs.
Problem
Access pattern leakage in TEE-based smart contracts: breaking token transfer receiver privacy
While Trusted Execution Environments (TEEs) provide a secure enclave for code execution and data protection, it is imperative to consider the broader infrastructure's role in upholding privacy. A meticulously architected system must, for instance, scrutinize the mechanisms by which encrypted data and transactions are imported into the TEE. In our study related to SNIP-20 tokens on the Secret Network, we have identified that the receiver's address may be susceptible to indirect exposure due to potential information leaks when interacting with the external world. Specifically, in the case of SNIP-20 token transfers, by analyzing the historical data of encrypted balances loaded into TEE and correlating them with public sender addresses (sender's address remains public for the purpose of paying transaction fee), the receiver’s address could potentially be deduced.
Challenges in preventing access pattern leakage
Addressing the challenge of access pattern leakage in TEE-based blockchains necessitates the deployment of obfuscation strategies. These can be incorporated at the application layer, specifically within the smart contract code, or integrated into the blockchain's core execution layer. For instance, for a token transfer, instead of loading only the sender’s and receiver’s account balances into TEE, we could do a linear scan over all possible account balances. Such a method is designed to prevent the disclosure of specific addresses accessed by the token transfer. This entails loading and updating all encrypted balances during the scan, yet only altering the sender and receiver’s balances to a new plaintext value. The approach is a basic instance of Oblivious RAM ORAM, a data structure designed explicitly to conceal storage access patterns.
However, the direct implementation of ORAM within smart contracts can be excessively costly. Taking the widely-used SNIP-20 token, sSCRT, as an example: a linear scan approach would necessitate loading and refreshing more than 36,000 records for each token transfer. This becomes increasingly unsustainable as the network's user base grows, leading to soaring associated costs. While advanced ORAM designs may offer more efficiency, the sheer volume of storage operations required still presents a significant hurdle.
Alternatively, embedding ORAM within the execution layer would imply major modifications to the consensus protocol. Moreover, it’s not a one-size-fits-all solution, as not all operations need the same level of privacy protection. Consequently, there is also the task of evolving the smart contract language to accommodate ORAM functionalities, adding another layer of complexity to the solution.
Detailed Product Description
Basic idea: using “FREE” off-chain execution to achieve ORAM
The on-chain implementation of Oblivious RAMs (ORAMs) would substantially increase the gas costs associated with token transfers, particularly as transaction complexity grows. This cost inflation stems from the necessity for every network node to replicate the additional operations designed to obscure the access to specific database entries. To circumvent these prohibitive transaction costs, we propose the adoption of ORAM exclusively in an off-chain 'view-only' mode. This mode is predominantly utilized by users for state queries, which are not disseminated across the network. By delegating the execution of ORAM to a single TEE node, we preserve the intrinsic privacy and integrity that the original TEE-based blockchain network provides. Applications that opt for off-chain ORAM benefit from enhanced access pattern protection, without adding computational overhead to the rest of the network or financial strain on its users.
Different from in public blockchain where anyone can freely read chain state, in TEE-based blockchain, only authenticated enclaves are capable of decrypting private smart contract states and providing query results to authorized users. For instance, when users need to check their SNIP-20 token balance, they send an off-chain query to a TEE node. The TEE node retrieves their encrypted balance from external storage, decrypts the value, and sends back the re-encrypted value, ensuring that only the querier can decrypt it. Such queries are “view-only” as they do not alter the blockchain state and are “off-chain” because the query transactions are not recorded/ordered on the blockchain. The execution of an off-chain query occurs on a single TEE node and is not replicated across the network.
For Secret Network such off-chain queries are currently FREE, but there is a per query gas limit imposed to restrict the number of operations performed in a single query. While off-chain queries do not directly update the blockchain state, there is nothing stopping us from using this infrastructure to conduct useful computations with the privacy and integrity guarantees provided by TEEs.
Truly private token contract
We demonstrate the effectiveness of our approach to solve the recipient address leakage in privacy-preserving token contracts. As previously noted, the main functionality of a privacy-preserving token contract is to enable private transfers, which involves hiding the transfer amount, recipient’s address, and token account balances. The sender’s address is made public as they are responsible for paying the transaction fee using the chain’s public native coin. However, the amounts involved in deposit and withdrawal transactions are not hidden, as these can be inferred by observing changes in the public token account balances.
In our implementation of applications using off-chain queries, we prioritize user experience by hiding the complex underlying processes from them. Users are only required to provide private inputs at the start and receive the private outputs upon computation completion. This ensures a seamless experience for users, maintaining the same interfaces as the existing fully on-chain implementation.
To achieve this, we employ a dedicated worker responsible for submitting off-chain queries to trigger the off-chain computing process. The worker node stores intermediate results until they post the final private output back on-chain. With the use of the worker node, we must ensure two things, 1) privacy — the worker cannot learn anything about the private inputs, intermediate results, and final private output; 2) integrity — the output posted on-chain is indeed obtained from off-chain queries carried out by a TEE. For these purposes, we use an authenticated encryption scheme to encrypt the off-chain queries outputs, ensuring both privacy protection and prevention of forgery.
During the instantiation phase, the smart contract generates a private authenticated (symmetric) encryption (AEAD) key on-chain, accessible only to TEE nodes. This key enables encryption of values, ensuring that data originates from smart contract function invocation within the TEE and can only be decrypted by TEE.
Figure below shows execution in our model. A user posts their input through an on-chain transaction. The worker node calls the view-only function getState() in the smart contract, employing the AEAD key to encrypt the user input into encInput, which can only be decrypted by TEE.
The worker initiates an off-chain query by invoking the view-only function processNext(), passing encInput as the input. The TEE decrypts the value, performs desired data processing functionality, re-encrypts the result as encState0, and returns it to the worker. The processNext() function is iteratively called with the output from the last call until the desired number of user inputs are processed.
The worker sends the final result to the TEE node and creates an on-chain transaction using the commit() function to post the result on-chain. After this the user can get the result as they would in a regular application.
To interact with our access pattern protected token contract, users submit transaction requests (deposit, transfer, or withdraw) much like they would with current privacy-preserving token contracts, while also providing private inputs to the invoked function. However, these transactions are not processed instantly. Instead, they are ordered in a sequence and recorded on-chain for subsequent processing. A worker node then processes these transactions using off-chain queries, in the order dictated by the blockchain. At the end, the worker node posts updated account balances back to the blockchain.
To achieve receiver address privacy, we incorporate the linear scan functionality into a view-only function in our token smart contract. By implementing the linear scan in view-only functions, we allow the costly computations to be performed by a single TEE node. This strategy not only minimizes extra transaction fees incurred from the complex linear scan but also maintains privacy and integrity.
To facilitate the transfer of off-chain computation responsibilities between worker nodes and avoid new workers to sync everything from scratch, we implement a checkpointing mechanism in the token contract. The checkpoint state contains a list of all account balances and a sequence number of last transaction processed to get those balances. The worker node gets the encrypted checkpoint state from the view-only function, getState. Because the checkpoint state is encrypted using authenticated encryption the worker cannot manipulate or read the user balances.
The worker consistently submits off-chain queries to invoke the view-only function, processNext, providing the latest encrypted checkpoint state as function input. The function executes the subsequent user transaction request in the sequence and updates the provided checkpoint state accordingly (updating account balances and incrementing sequence number).
In addition to posting the most recent checkpoint state (including updated account balances and sequence number) on-chain after processing a batch of transactions, the worker also must ensure the “side effects” of transaction execution take effect. In essence, a withdraw request could trigger a token transfer from the token contract to a different account or contract, which must be managed when the worker is posting the checkpoint.
Efficiency Improvement
The linear scan referenced earlier represents a basic instantiation of ORAM. To enhance efficiency and broaden functionality, more sophisticated ORAM architectures should be explored. This may involve either the integration with existing ORAM frameworks or the development of a proprietary implementation. Concurrently, employing complex ORAM structures presents the challenge of ensuring compatibility with existing public external storage solutions.
As the frequency of off-chain queries escalates, we will explore the potential for parallelization of the worker node tasks and employment of multiple network nodes to handle these queries. Coordinating among these nodes to prevent conflicts during state updates presents an additional challenge that must be addressed.
Project Deliverables
Our commitment is to deliver a proof-of-concept implementation of truly private token contracts, developed in Rust, accompanied by an off-chain worker toolkit coded in NodeJs. These components will be seamlessly integrated with the Secret Network's existing infrastructure and will conform to the current SNIP-20 (or SNIP-25) token standards. A key aspect of our plan is to abstract the intricacies of the ORAM and the concurrency control backend, thereby simplifying the development process for programmers.
Value capture for Secret Network ecosystem
This will add essential privacy protection for privacy-preserving tokens on Secret, while ensuring minimal additional overhead to the network's operations.
Team members
Gabriel Arrouye Nerla Jean-Louis @njeans Yunqi Li @lilione Andrew Miller
Team Website
https://decentralize.ece.illinois.edu/
Team Code Repos
https://github.com/initc3/tee-offchain/tree/main/secretnetwork
Development Roadmap
We will require 6 months to complete this project. Nerla and Yunqi would work on this project as part of their thesis research, which is advised by Andrew. Gabe would help us and give us suggestions on software development. The total cost is $52,000 worth in SCRT.
Milestones and budgets: Proof-of-Concept for token contract using linear scan (1 month, $12000) Rust smart contract code NodeJS worker code Create a NodeJS API for the worker (1 month, $5000) Optimize the contract using more efficient ORAM construction (2 months, $20000) Integrate contract with SNIP-20 (or SNIP-25) standard (1 month, $7500) Concurrent execution of off-chain queries and coordination between multiple workers (1 month, $7500)
Ideally, we can receive payments in 5 disbursements, at the beginning of each milestone.
Additional Info
As we consider the future evolution of this initiative, our aim is to transition it into an extensive research endeavor. Upon the successful completion of the current project, we are open to exploring deeper collaborative opportunities to further these research directions.
TEE Rollups Programming Model
Within the scope of our proposal, we intend to showcase a prototype application—a private token—to illustrate our concept. Our ultimate ambition extends beyond this example; we envision empowering developers to freely program a wide array of applications. To this end, our objective is to develop a versatile, general-purpose programming framework that enables the crafting of applications with protected access patterns, leveraging the capabilities of TEE Rollups.
For developers, they should be able to seamlessly integrate access pattern protection into their applications, in alignment with the established conventions of the Secret Network infrastructure. This framework will allow developers to designate specific parts of their smart contracts for enhanced access pattern security. Subsequently, the framework will automatically convert the simple source code into sophisticated implementations, leveraging obfuscation techniques and off-chain computations.
The deployment process of these implementations will be streamlined. While the on-chain components will adhere to the Secret Network's existing protocols, the framework will also furnish a straightforward method for instructing off-chain workers about their roles for each application. For instance, workers would monitor designated on-chain events to initiate the related off-chain computations and subsequently publish the results back to the blockchain.
Aiming to prioritize usability, the framework is designed to abstract the complexity from the end-users. They will simply need to input confidential data at the beginning and retrieve private outputs once computations are complete, thus preserving a user experience that is consistent with—or potentially identical to—the current fully on-chain interactions.
Fee mechanism redesign
When TEE-based networks adopt this off-chain query mechanism we introduce, significant elevation in the volume of off-chain queries is expected. This surge underscores the necessity for an effective access control mechanism and a refined fee structure to thwart denial-of-service attacks and to motivate network participants, particularly the workers. Consequently, this may entail a shift from the current cost-free model of off-chain queries to a nominally charged scheme, ensuring affordability while maintaining a substantial cost advantage over on-chain executions. Additionally, we anticipate a review and potential revision of the gas limits applicable to off-chain queries to align with these changes.