The problem Dread Pirate Roberts Marketplace solves

Current situation:
For marketplaces involving trust, reputation is used to access the credibility of counterparties. This usually requires revealing the trade history of all users or relying on a trusted third party to attest the reputation score without revealing more data. This is especially problematic for:
Bitcoin P2P exchanges: users need to know that they can trust their counterparty but they don’t want to reveal their transaction history. Centralised solutions are not an option because of regulation (e.g. Localbitcoins being taken down) and because of the decentralised focused audience.
Marketplaces for high value items (e.g. marketplace for second hand jewellery, gold and silver pieces): users need to know that they can trust their counterparty but they don’t want to reveal their transaction history. For very high value items, centralised attestation solutions might not be an option because of the inherent counterparty risk.

Our solution:
Dread Pirate Marketplace provides the smart contract infrastructure and an example frontend enabling sellers to list items of any kind and buyers to review the sellers reputation and to buy the items with the Aleph Zero token.

As the trade will presumably involve some offchain elements (fiat payment for the P2P Bitcoin exchange, shipment of the high value goods etc.), the buyer can rate the seller afterwards within 10 days of the trade.
The paid funds are locked in the contract after the trade. The seller can claim them after the buyer submitted the review but has to at the same time regenerate their reputation score using the submitted review. If the buyer didn’t submit a review in time, the seller can also claim their funds without updating their reputation.

Challenges we ran into

• Risc0 has some std-feature leaks here and there that were tricky to track down.
  Hopefully, https://github.com/risc0/risc0/issues/441 helps with that. Even with cargo resolver v2 and

  default-features = false

  , a sprinkle of

  #![no_std]

  magic was necessary.

• We also ran into some serialisation problems for Risc0 types when integrating with ink!, which uses a custom non-serde serializer (parity-scale-codec).

• Designing a safe zk-protocol is hard if you’re not a cryptographer ;)