Skip to content

FEEDBACK.md

Latest commit

 

History

History
246 lines (168 loc) · 8.23 KB

FEEDBACK.md

File metadata and controls

246 lines (168 loc) · 8.23 KB

iExec Tools Feedback

This document provides feedback on our experience using iExec tools while building ShadowSwap - a confidential batch auction DEX.

📋 Tools Used

Tool Purpose in Our Project
iExec DataProtector Encrypting order data before on-chain submission
iExec SDK Integration with DataProtector APIs

⭐ What We Loved

1. Easy-to-Use SDK

The @iexec/dataprotector SDK has a clean, intuitive API:

import { IExecDataProtector } from '@iexec/dataprotector';

const dataProtector = new IExecDataProtector(provider);
const protectedData = await dataProtector.protectData({
    data: orderData,
    name: 'ShadowSwap Order',
});

Feedback: The SDK abstraction makes it simple to integrate confidential computing without deep knowledge of TEE (Trusted Execution Environment) internals. This significantly reduces the learning curve for developers.

2. Privacy-First Approach

DataProtector's encryption model fits perfectly with our MEV protection use case:

  • Order details (amounts, prices) are encrypted client-side
  • Only authorized parties can decrypt
  • Prevents front-running and sandwich attacks

Feedback: The privacy guarantees are exactly what DeFi needs. Being able to hide transaction details from validators/miners is a game-changer for fair trading.

3. Blockchain-Agnostic Design

The iExec tools work across multiple chains, which aligns with our multi-chain deployment plans.

Feedback: Cross-chain compatibility is essential for modern DeFi. Appreciate that iExec isn't locked to a single ecosystem.

4. Comprehensive Documentation

The iExec documentation covers:

  • Getting started guides
  • API references
  • Use case examples
  • Troubleshooting

Feedback: Documentation quality is above average compared to other Web3 tools. The examples are practical and easy to follow.

🔧 Challenges & Suggestions

1. Initial Setup Complexity

Challenge: Setting up the full iExec environment (sidechain, worker nodes, etc.) for local development requires multiple steps.

Suggestion: A "quick start" Docker container with pre-configured iExec environment would help developers prototype faster.

2. Testnet Availability

Challenge: During development, we occasionally experienced delays when interacting with iExec testnet services.

Suggestion: Consider providing a "dev mode" that simulates iExec functionality locally without network calls, similar to how we implemented our fallback encryption.

3. Gas Fee Handling on L2s (Arbitrum Sepolia)

Challenge: The DataProtector SDK internally calls eth_sendTransaction for protectData() without sufficient maxFeePerGas for Arbitrum Sepolia. This causes "max fee per gas less than block base fee" errors because the base fee fluctuates on L2s.

Our Solution: We built a proxy provider (createGasBoostedProvider) that wraps window.ethereum and intercepts eth_sendTransaction calls to inject proper EIP-1559 gas parameters (baseFee * 2 buffer) before they reach MetaMask.

// Our gas-boosted provider wrapper (frontend/src/lib/encryption.ts)
const boostedProvider = createGasBoostedProvider(window.ethereum);
const dataProtector = new IExecDataProtector(boostedProvider);

Suggestion: The SDK should handle L2 gas estimation internally, or at least provide a configuration option for custom gas parameters. A gasOptions parameter in the constructor would help:

const dataProtector = new IExecDataProtector(provider, {
    gasOptions: { maxFeePerGasMultiplier: 2.0 } // Suggested API
});

4. Debugging Encrypted Data

Challenge: When something goes wrong with encrypted data, debugging is difficult because you can't inspect the payload.

Suggestion: A debug mode that logs encryption/decryption steps (without exposing actual data) would help developers troubleshoot issues.

5. Integration Examples

Challenge: Finding DeFi-specific integration examples took some searching.

Suggestion: A dedicated "DeFi Recipes" section in documentation with examples for:

  • Order book privacy
  • Private auctions
  • Confidential voting (for DAOs)
  • Hidden collateral positions

💡 Feature Requests

1. Batch Encryption API

For DEXs processing many orders, a batch encryption endpoint would reduce API calls:

// Current: Multiple calls
const encrypted1 = await dataProtector.protectData({ data: order1 });
const encrypted2 = await dataProtector.protectData({ data: order2 });

// Requested: Single batch call
const [encrypted1, encrypted2] = await dataProtector.protectDataBatch([
    { data: order1 },
    { data: order2 },
]);

2. Time-Locked Decryption

For auction use cases, time-locked decryption would be powerful:

const protectedData = await dataProtector.protectData({
    data: bidData,
    decryptAfter: auctionEndTimestamp, // New feature
});

This would guarantee no one can decrypt until the auction ends.

3. Threshold Decryption

For multi-party scenarios, requiring N-of-M parties to authorize decryption:

const protectedData = await dataProtector.protectData({
    data: sensitiveData,
    threshold: { required: 3, total: 5 }, // 3 of 5 must approve
});

4. On-Chain Verification

A way to verify on-chain that data was encrypted with DataProtector without decrypting:

function verifyEncryption(bytes memory encryptedData) 
    external view returns (bool isValid);

📊 Our Implementation Details

How We Use DataProtector

┌─────────────┐     ┌─────────────────┐     ┌─────────────────┐
│ User Order  │────▶│  DataProtector  │────▶│   ShadowPool    │
│   (Plain)   │     │   (Encrypt)     │     │   (On-chain)    │
└─────────────┘     └─────────────────┘     └─────────────────┘
      │                     │                       │
      ▼                     ▼                       ▼
  - tokenIn            - encryptedData         - Store encrypted
  - tokenOut           - datasetAddress        - Execute batch
  - amountIn                                   - Settle trades
  - limitPrice

Privacy Guarantees Achieved

Data Visibility
Token addresses Public (needed for routing)
Order amount Encrypted
Limit price Encrypted
Order owner Public (on-chain)
Execution time Public (block timestamp)

Fallback Implementation

For testing without iExec infrastructure:

// frontend/src/lib/encryption.ts
export async function encryptOrderData(orderData: OrderData) {
    try {
        // Try real DataProtector
        return await realEncryption(orderData);
    } catch {
        // Fallback for testing
        return mockEncryption(orderData);
    }
}

🏆 Overall Assessment

Aspect Rating Comments
SDK Usability ⭐⭐⭐⭐ Clean API, easy integration
Documentation ⭐⭐⭐⭐ Comprehensive, could use more DeFi examples
Performance ⭐⭐⭐ Good, batch operations would help
Developer Experience ⭐⭐⭐⭐ Smooth once set up
Use Case Fit ⭐⭐⭐⭐⭐ Perfect for MEV protection

Would We Use iExec Again?

Yes, absolutely. The privacy guarantees are essential for fair DeFi, and iExec DataProtector provides a practical way to achieve confidential computing without building TEE infrastructure from scratch.

🙏 Acknowledgments

Thanks to the iExec team for:

  • Building powerful privacy tools for Web3
  • Responsive community support
  • Comprehensive documentation
  • Hosting this hackathon

📞 Contact

For questions about our iExec integration:

This feedback was written as part of our hackathon submission to help improve the iExec developer experience.