Welcome to the iExec FAQ section. Here you'll find answers to common questions.
Returned data is always a file
The output it's a file and it's always be zipped with its content
It's possible to push the output on a blockchain
Is it possible to have encrypted output?
Yes, this is possible through the SDK options.
Where do the outputs land on IPFS?
The data is dropped decrypted on IPFS, but it is also possible to store it encrypted on IPFS or Dropbox for instance
Does encryption impact data organization and conversion?
Normally, no. The iApp is responsible for handling this.
Reverse lookup from an IPFS CID to the smart contract to find the data protector contract?
Yes, it's possible to find the wallet, task and deal.
Ability to look in the marketplace to add information for IP licensing?
Yes, this is possible.
Datapool processing?
Planned for Q2.
Will processing four megabytes be an issue in the TEE?
It should be possible, we could make some stress test
iExec Sidechain “Bellecour” is a standard EVM-based sidechain dedicated to the iExec protocol. This article lists some of the things that can go wrong when one attempts to deploy smart contracts on IExec Sidechain Bellecour.
Possible causes and fixes :
-
Whitelisting Required
Only whitelisted wallets can deploy contracts.
→ Request whitelisting via support ticket -
Incorrect Wallet
Verify you're using your whitelisted deployment wallet. -
Gas Configuration
- Set gas price to 0 Wei
- Ensure sufficient gas limit (minimum 2M recommended)
Why am I getting the "no workerpool order found" error and how can I fix it?
This error can happen for two main reasons. Here’s how to understand and solve it:
-
You are sending tasks too quickly.
- Problem: If you send multiple tasks back-to-back, the system may temporarily block your requests to prevent spam.
- Solution: You must wait at least 20 seconds between each task you send. If you still get the error, increase the delay and try again later.
-
The workerpool is genuinely unavailable.
- Problem: The worker may simply have no open orders at that moment.
- Solution: Before sending a task, you can check for availability using the
fetchWorkerpoolOrderbookfunction with the iExec SDK. This confirms if the worker is ready to accept your job.
When running a SCONE-based TEE Dapp, you might encounter the following error:
[SCONE|WARN] rust-cache/cargo/registry/src/github.com-1ecc6299db9ec823/rustls-0.19.1/src/session.rs:798:Sending fatal alert BadCertificate
[SCONE|FATAL] src/process/init.c:379:__scone_prepare_secure_config(): Could not initialize enclave state: Attestation failed
Caused by: Failed to establish an encrypted channel to CAS
Caused by: I/O error
Caused by: invalid certificate: UnknownIssuer
This error happens when the image used to build the application does not match the CAS version set-up in the worker. To solve the issue, please make sure that:
- You are building your Dapp using the latest version of the sconifier image
- You are following the instructions provided in the documentation.
You have requested access to the SCONE build tools via email but have not received a response, and the tools are not appearing on GitLab.
Access to the SCONE tools is typically granted within 2 to 24 hours. If you haven't received a reply after this period, it's advisable to contact the Scontain team again.
Guide to cleaning your local Docker environment , no space left on device
docker: Error response from daemon: no space left on device
To clean up Docker and remove unused images, the main command is docker image prune . For a more comprehensive cleanup that also includes unused containers and networks, use docker system prune. If you want to delete all images not associated with a container, not just dangling ones, add the -a flag to these commands.
ReferenceError : "Buffer is not defined" on a vite project .
To solve the issue, configure a polyfill for Buffer by following this guide:
Buffer polyfill on StackOverflow
A common error encountered by users of Macs with an Apple Silicon chip (M1, M2, M3, etc.) when deploying applications with iapp-generator is a failure related to Docker platform compatibility. This issue is not directly linked to the machine's ARM64 architecture itself, but rather to how Docker Desktop handles images designed for different architectures.
Error: failed to get destination image “sha256:eac60eea79d7dcacd94fcf6141e402dd069c0168c4c56ee447a4bee81a21b198”: image with reference sha256:eac60eea79d7dcacd94fcf6141e402dd069c0168c4c56ee447a4bee81a21b198 was found but does not provide the specified platform (linux/amd64)
In short: The error means that the Docker image you are trying to run was built for a linux/amd64 architecture (Intel/AMD processors) and your system, an ARM64 Mac, cannot run it natively.
The proven and effective solution is to replace Docker Desktop with OrbStack.
What is OrbStack: OrbStack is an alternative to Docker Desktop for macOS, designed to be faster, lighter, and more efficient. It offers better integration with macOS and a much more performant and reliable emulation of linux/amd64 images through an optimized approach.
You are holding RLC on a centralized exchange (such as Binance, Kraken or Coinbase) and want to transfer some of your balance to iExec Sidechain “Bellecour” so you can use them with iExec, for example for requesting tasks.
The iExec sidechain “Bellecour” is an EVM-compatible chain that is only bridged to Ethereum Mainnet. iExec does not support direct transfers of funds from any centralized exchange to a wallet on Bellecour. This means that to use your RLC balance on iExec Sidechain “Bellecour” you will need to first use the “Withdraw” feature of your exchange to transfer RLC to a wallet on Ethereum Mainnet, and then you can use the iExec bridge to transfer RLC from that wallet to your wallet on iExec Sidechain “Bellecour”.
The subgraph often responds with a CORS error, even though the actual issue might be something different, such as an invalid query or syntax errors in requests with The Graph.
Access to fetch at "x" from origin "y" has been blocked by CORS policy: Response to preflight request doesn't pass access control check:It does not have http ok status.
The GraphQL net::ERR_FAILED
Verify the syntax before further analysis, such as checking for missing curly braces, you can directly test the query on the following URL: thegraph.bellecour.iex.ec. This will allow you to quickly identify syntax errors.
Users have reported a prolonged task processing time, with a minimum of 5 minutes, when working with the iExec Protocol.
Explaination
- Order Matching : The system needs to meticulously match orders, considering various parameters, to ensure accuracy in task allocation.
- Docker Image Download : Retrieving the necessary Docker image for task execution is a critical step, and the time taken depends on the image size and network conditions.
- SGX Attestation Verification : Security is paramount, and the Dapp verifies the SGX attestation with Intel to ensure the integrity of the execution environment.
- Task Execution : The actual execution of the task involves complex computations, and the time taken is influenced by the nature and complexity of the task.
- Result Uploading : Once the task is executed, the results are uploaded, which can take time based on the size of the data and network conditions. You can learn more about the task statuses in our documentation
Future improvements
We acknowledge the concerns regarding the extended processing time and want our users to know that we are actively working on optimizing the performance of the iExec Protocol. Here are some aspects we are currently addressing :
- PoCo Boost - On-Chain Protocol Optimization : We're optimizing our on-chain protocol with PoCo Boost to reduce transactions and lower gas usage per deal. This aims to significantly improve transaction speed and cost-effectiveness.
- Intel Collaboration and Research : Constant collaboration with Intel includes in-depth research to enhance SGX attestation processes, ensuring a more secure and efficient iExec Protocol.
- Language Benchmarking : We're benchmarking worker processes across different code languages, aiming to identify the most efficient ones for specific tasks. This optimization contributes to overall Protocol performance.
Whitelist Contract Error
Error Message: "This whitelist contract address does not exist in the app whitelist registry"
- Use whitelisted app addresses
- Default whitelisted app address: 0x256bcd881c33bdf9df952f2a0148f27d439f2e64
- For custom apps, they need to be whitelisted by the iExec team
Collection Management Access
Error Message: "This collection can't be managed by you"
- Only collection owners can manage their collections
- Users need proper permissions to add to collections
- Consider implementing a two-step collection management system:
- Users create their own collections
- Main collection owner grants access for adding to the primary collection
Workerpool Order Not Found
Error Message: "Could not find a workerpool order, maybe too many requests?"
- Retry after a few minutes when computing resources become available
- This happens when the workerpool is at 100% capacity
- The error is temporary and related to resource availability
Task Processing Stuck at 0%
- Check if trying to consume the same data multiple times
- Verify data size and format
- Use the task debug feature to see detailed logs:
iexec task debug [taskID]
CORS in Development
Error Message: "Access to fetch at 'https://ipfs-upload.v8-bellecour.iex.ec/api/v0/add' has been blocked by CORS policy"
- Use the recommended IPFS gateway: https://ipfs-gateway.v8-bellecour.iex.ec
- For content creators, use: https://github.com/iExecBlockchainComputing/content-creator-usecase-demo/.env.prod
Error Message: "Module parse failed: Unexpected token (808:63)"
- Ensure proper initialization of DataProtector methods
- Don't just initialize the module, use specific methods like protectData()
- Reference the sandbox implementation: https://codesandbox.io/p/github/iexecblockchaincomputing/dataprotector-sandbox/main
Custom Chain Support
Context: Using DataProtector with different chains
- DataProtector is built specifically for iExec sidechain
- Only supports https://bellecour.iex.ec
- Not compatible with other chains like Citrea
- Requires specific Web3 provider configuration:
const web3Provider = new Web3.providers.HttpProvider('https://bellecour.iex.ec');- Create a collection
- Create Protected Data
- Create AddOnlyAppWhitelist
- Add Protected Data to collection
- Set renting/selling/subscription parameters
- Set Protected Data to renting/sale/subscription
- Rent/Buy/Subscribe to Protected Data
- Consume the Protected Data content
- Renting and subscription models are currently more reliable than purchase for data consumption
- All data added to collections is immutable
- Processing protected data requires proper access rights and available computing resources
- Test with price set to 0 if RLC tokens are not available
Why are there 4 signatures required to create Protected Data?
Creating "Protected Data" is not just a simple upload. It's a process that guarantees on-chain ownership, off-chain security, and data governance.
-
Register On-Chain Create protected data into DataProtector registry smart-contract. This transaction proves your ownership by registering your data on the blockchain.
-
Secure the Key Push protected data encryption key to iExec SMS. This securely stores the decryption key in iExec's off-chain vault, so only authorized apps can use it later.
-
Set Permissions Creation of orders (DatasetOrder). This defines the first usage rule (who can use your data and how).
-
Gateway Authentication Challenge: Sign this message to log into iExec Gateway. This authenticates your current session with iExec services (the Gateway acts as a bridge between your requests and the blockchain/workers).