protocol (b|t)rainstorm

I'd call it a brainstorm, but it happened on the train (again).

Description of retrust protocol design - trust, reputation primitive, cryptoeconomic interaction design:

Background on reputation protocols

  • retrust is a protocol for the exchange of trust and the calculation of reputation attributes
  • the protocol is essentially a mechanism for reputation
  • reputation that can be used to enable marketplaces that otherwise would not be possible
  • reputation is different to issuing a platform-specific token, as it has different economics of issuance/control

Example use case of protocol: P2P SciHub

  • SciHub allows you to get any academic paper through a search engine like Napster
  • P2P version consists of two elements: paper index and live proxies
  • Paper index: mapping of (DOI, title, ISBN) => PaperSource. Pretty easy to turn into a Token Curated Registry.
  • type PaperSource = (magnet: | ipfs:// | Live Proxy)
  • Live proxies route requests for papers through live academic credentials for institutions
  • Necessary because not all papers are immediately available…
  • Cannot be public because of simple ramifications of takedowns.
  • Cannot be put on .onion network and then listed because of simple ease of correlation + complexity

How would we use reputation mechanisms to build this?

  • Proxies generate reputation for providing correct papers
  • Reputation mechanism operates similarly in Uber/AirBnB - used as gauge of proxy quality (price signalling)
  • If the reputation of a proxy becomes too low, it is pruned/banned from list

What does this look like technically?

  • User is finding paper 420.000.1337.
  • tcr_lookup(paper_index, doi='420.000.1337') == 'NOT_FOUND'
  • So they then query the live proxies:
  • tcr_lookup(live_proxies, doi='420.000.1337') => Proxy[A, B, C]
  • type Proxy = (address: 0xABC123, url_tor, url_ens, url_https)
  • User generates a trust bond, staked in the proxy. Bond(in=proxy, amount=20, signature=x)
  • They send a request to the proxy, with this bond included
  • The proxy either: a) fulfills the request, and sends back a reciprocal trust bond or b) does not fulfill the request
  • If the proxy did not serve the right PDF (ie, breach of trust), the trust bond is rescinded
  • In either case, it is published on-chain, for use in calculaion of global reputation

Protocol mechanics

  • consumers of the protocol create bonds of a personal and dapp-specific ERC20 token

  • users build reputation from interaction with other users through the protocol

  • interaction takes the form of challenge-response staking of trust bonds

  • trust bonds can be revoked, which produces more adverse affect on reputation than simply not reciprocated

  • two-sided marketplaces: supply/demand price can be regulated by the reputation mechanism

  • reputation can be used to improve dapp experience wherein users interact with re-liability (the idea of bonds) without the economic cost of issuing a token

  • reputation convergence algorithm - evidence-based subjecive logic

  • sybil-resistant notions of digital identity can be built on top of this reputation convergence algorithm

  • for this, all trust bonds must be registered to a decentralised ledger.

Select a repo