Idempotent Proxy: proxy HTTPS Outcalls to any Web2 service

I believe there isn’t sufficient incentive for a malignant replica to steal OpenAI tokens.

If a scenario with enough incentive does arise, it can be addressed by upgrading the proxy_token mechanism, such as:

  1. Regenerating the proxy_token for each proxy service request, without caching it in the canister;
  2. Strictly limiting the resource boundaries that each proxy_token can access;
  3. Ensuring that each proxy_token can only be used once by the proxy service.

The Idempotent Proxy will play a crucial role in the CK-Doge project:

Hey @zensh,

The usage of the idempotent proxy is concerning for a project that controls user funds. Aren’t there no public RPC providers or block explorers that support IPv6?

Or are you doing on-chain light client verification of the data you are fetching via the idempotent proxy?

The currently deployed Idempotent Proxy and Dogecoin node are for local testing only. When deploying the testnet version online, IPv6 will be added to the Idempotent Proxy. For the mainnet deployment, we plan to integrate well-known, trusted public RPC providers for dual verification of the block tip.

The CK-Doge canister will also perform hash chain validation on the block data it fetchs.

Furthermore, CK-Doge could be a highly influential project. It aims to integrate Dogecoin, a cryptocurrency with a market cap of $20 billion, into the third-generation blockchain, ICP. This could bring new vitality to Dogecoin’s consensus, as Dogecoin nodes have not been updated for a long time and seem difficult to update.

But will you still be using the idempotent proxy in between the canister and these RPC providers?
This would still mean that the proxy would need to be trusted.

It doesn’t seem to validate proof of work. This would make it much harder for a malicious proxy or RPC provider to feed invalid blocks.

In the current implementation, trust in the RPC provider is indeed necessary.

The CK-Doge canister maintains tip_height and tip_blockhash. It reads the next block hash from tip_height, and then retrieves block data using the block hash.
The CK-Doge canister verifies that the block’s hash matches the expected value and that its prev_blockhash equals the hash of the previous block (tip_blockhash).

If the RPC provider gives CK-Doge canister forged block data, it would need to consistently provide forged data for continued operation. External observers can detect an attack on the CK-Doge canister by examining the tip_height and tip_blockhash.

Thus, tip_height and tip_blockhash is crucial for verifying the authenticity of the blocks. If CK-Doge canister retrieves block data from multiple RPC providers, it can validate the data by comparing the tip_blockhash from each provider.

I will continue to explore better solutions.