1

I want to design a proof of concept of a fully decentralized secure asset sharing DApp. Seller uploads the asset they want to share with a price and buyer pays it with ether or a token. Frontend and asset file is hosted on Swarm, and hash address of the Swarm is stored in smart contract. Is it possible to make this buying process synchronous using a symmetric or asymmetric key cryptography?

The problem is:

  • Ethereum transactions and smart contract data/logic are all open.
  • I put the asset file to Swarm encrypted, but since its hash address of Swarm is visible

    • it should be encrypted for buyer

    • buyer should receive decryption key

  • Swarm frontend supports only static web pages with JavaScript and HTML
  • In order to synchronously encrypt the file for a buyer, the unencrypted file should be hosted somewhere.

Is there a scenario i could achieve this? Possible solutions i found are:

  1. use secret stores of Parity
  2. decentralized Oracles?
  3. use Enigma or zk-snarks for ethereum.
  4. asynchronous secret sharing with Whisper
  5. include a centralized party (webserver? this is the last resort)- asynchronous secret sharing with Whisper
Improve this question
0

when you say you want to share a digital asset file, what do you mean? You can swap ethereum assets (tokens) peer to peer in a synchronous manner by trusting an 'atomic swap' smart contract. This is a type of smart contract where both parties put the asset and the ether into the smart contract, then the contract gives both of them the swapped asset (or it times out and returns the asset to the original owner). You don't need a file, but you do need a matching algorithm to match the people that want to swap assets. Maybe something like Airswap is what your are thinking of?

Improve this answer
5
  • For example i want to share/sell the photos i took, like shutterstock.com. so the seller uploads the original file to, lets say Swarm. And buyer will get it over Swarm. In a fully decentralized and public architecture, for example Ethereum Web 3.0 stack, i have to encrypt the file if i want to sell it, because its Swarm hash address is public in blockchain and everybody can download it. (continue below)
    – Serhat
    Jun 7 '19 at 0:04
  • In a scenario where the buying process involves the seller, seller can send a secret key to the buyer over Whisper. But this is not a practical way. if i want to have an instant buying process, - i dont have anywhere to save the secret key for only buyer's access - i dont have anywhere to save the unencrypted file so that it can be encrypt with buyers public key and put in Swarm automatically.
    – Serhat
    Jun 7 '19 at 0:05
  • I think you will have to use onchain privacy solutions to solve this. How about this: - Seller encrypts their file with their own private key(in case someone stumbles across it), and uploads it to swarm/IPFS, then you store the address on swarm to that encrypted content in a smart contract, but with the text encrypted (maybe in a ZK Snarks note?). - Now a buyer purchases the asset, they can resolve the address of the content by opening the note, and can decrypt the product with the sellers public key.
    – Oisin
    Jun 8 '19 at 11:45
  • thats possible, i did not know it was implementable with Ethereum yet, i will check it. But in the end, to keep it all decentralized, it seems i have to use ZK-snarks or Enigma to have something encrypted in the blockchain, such as the secret smart contracts of Enigma. Do you agree?
    – Serhat
    Jun 8 '19 at 14:48
  • Yes I agree, if your smart contract is revealing assets to users after a purchase, how the smart contract operates can't be all in clear text I think, or someone would just go around your smart contract to get at the asset. One way or another I think there will need to be on-chain privacy as part of this build.
    – Oisin
    Jun 11 '19 at 11:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.