Payments for retrieval

Retrieval via fair-exchange

ZKCSP approach (3 on-chain messages)

• Miner send encrypted file, the hash of the key to decrypt and proof that this is the right key
• User places a bounty to receive the pre-image of the hash
• Problems:
• Cumbersome → many interactions on-chain
• Bandwidth is not fair (miner can be dossed to send many encrypted copies)
• Proof generation is expensive

ZKCSP with payment channels

• Same as above but it settles on the payment channel instead

Threshold Network Approach (2 on-chain messages)

• Miner sends the encrypted file and writes a theshold contract to release the key on payment and makes the proof that the right file is encrypted
• User make the payment and this generates a decryption key
• Problems:
• We don't have the network

Retrieval via small payments

Based on trust/reputation building interaction.

Small incremental steps

Payment channel approach:

• Open a channel with each
• Problem:
• Must open payment channel with every retrieval miner (say that there are 1000 you must pay tx fee to open each and lock money on each)

Payment channel network:

• There is a network of payment channels
• Problem:
• There is no real payment channel network
• We should figure out if there are open questions (e.g. liquidity issues?)
• Potential next steps:
Read the Blitz paper
Plan a call with IMDEA folks

Probabilistic payments:

• Send several small payments, however only a few have actual payment (probabilistically)
• Problem:
• They require very large collateral requirement that makes it a no-go

Roll-up:

• Send many payments to aggregator node
• Problem:
• Tx fees today are still very high for many small transactions (see https://l2fees.info/)